Un sistema operativo distribuido es un software de sistema sobre una colección de nodos computacionales independientes, conectados en red , en comunicación y físicamente separados. Manejan trabajos que son atendidos por múltiples CPU. [1] Cada nodo individual contiene un subconjunto de software específico del sistema operativo global agregado. Cada subconjunto es una combinación de dos proveedores de servicios distintos. [2] El primero es un kernel mínimo ubicuo , o microkernel , que controla directamente el hardware de ese nodo. El segundo es una colección de alto nivel de componentes de administración del sistema.que coordinan las actividades individuales y colaborativas del nodo. Estos componentes abstraen las funciones del microkernel y apoyan las aplicaciones del usuario. [3]
El micronúcleo y la colección de componentes de gestión trabajan juntos. Apoyan el objetivo del sistema de integrar múltiples recursos y funcionalidad de procesamiento en un sistema eficiente y estable. [4] Esta perfecta integración de nodos individuales en un sistema global se conoce como transparencia o imagen de sistema único ; describiendo la ilusión proporcionada a los usuarios de la apariencia del sistema global como una única entidad computacional.
Descripción
Un sistema operativo distribuido proporciona los servicios esenciales y la funcionalidad requeridos de un sistema operativo, pero agrega atributos y configuraciones particulares para permitirle admitir requisitos adicionales, como una mayor escala y disponibilidad. Para un usuario, un sistema operativo distribuido funciona de manera similar a un sistema operativo monolítico de un solo nodo . Es decir, aunque consta de múltiples nodos, a los usuarios y aplicaciones les aparece como un solo nodo.
La separación de la funcionalidad mínima a nivel de sistema de los servicios modulares adicionales a nivel de usuario proporciona una " separación de mecanismo y política ". El mecanismo y la política pueden interpretarse simplemente como "qué se hace algo" versus "cómo se hace algo", respectivamente. Esta separación aumenta la flexibilidad y la escalabilidad.
Descripción general
El kernel
En cada localidad (normalmente un nodo), el kernel proporciona un conjunto mínimo completo de utilidades a nivel de nodo necesarias para operar el hardware y los recursos subyacentes de un nodo. Estos mecanismos incluyen la asignación, gestión y disposición de los recursos, procesos, comunicación y funciones de soporte de gestión de entrada / salida de un nodo . [5] Dentro del kernel, el subsistema de comunicaciones es de suma importancia para un sistema operativo distribuido. [3]
En un sistema operativo distribuido, el kernel a menudo admite un conjunto mínimo de funciones, incluida la gestión del espacio de direcciones de bajo nivel , la gestión de subprocesos y la comunicación entre procesos (IPC). Un núcleo de este diseño se denomina microkernel . [6] [7] Su naturaleza modular mejora la confiabilidad y seguridad, características esenciales para un sistema operativo distribuido. [8] Es común que un kernel se replique de manera idéntica en todos los nodos de un sistema y, por lo tanto, que los nodos de un sistema utilicen hardware similar. [9] La combinación de diseño mínimo y cobertura ubicua de nodos mejora la extensibilidad del sistema global y la capacidad de introducir dinámicamente nuevos nodos o servicios. [10]
Gestión del sistema
Los componentes de gestión del sistema son procesos de software que definen las políticas del nodo . Estos componentes son la parte del sistema operativo fuera del kernel. Estos componentes proporcionan comunicación, procesos y gestión de recursos, confiabilidad, rendimiento y seguridad de alto nivel. Los componentes coinciden con las funciones de un sistema de una sola entidad, lo que agrega la transparencia requerida en un entorno distribuido. [3]
La naturaleza distribuida del sistema operativo requiere servicios adicionales para respaldar las responsabilidades de un nodo con el sistema global. Además, los componentes de administración del sistema aceptan las responsabilidades "defensivas" de confiabilidad, disponibilidad y persistencia. Estas responsabilidades pueden entrar en conflicto entre sí. Un enfoque coherente, una perspectiva equilibrada y una comprensión profunda del sistema en general pueden ayudar a identificar los rendimientos decrecientes . La separación de políticas y mecanismos mitiga estos conflictos. [10]
Trabajando juntos como un sistema operativo
La arquitectura y el diseño de un sistema operativo distribuido deben cumplir los objetivos de los nodos individuales y del sistema global. La arquitectura y el diseño deben abordarse de manera coherente con la separación de políticas y mecanismos. Al hacerlo, un sistema operativo distribuido intenta proporcionar un marco de computación distribuida eficiente y confiable que permite una conciencia mínima absoluta del usuario de los esfuerzos de comando y control subyacentes. [8]
La colaboración de múltiples niveles entre un kernel y los componentes de administración del sistema y, a su vez, entre los distintos nodos en un sistema operativo distribuido, es el desafío funcional del sistema operativo distribuido. Este es el punto del sistema que debe mantener una perfecta armonía de propósito y, al mismo tiempo, mantener una completa desconexión entre la intención y la implementación. Este desafío es la oportunidad del sistema operativo distribuido para producir la base y el marco para un sistema confiable, eficiente, disponible, robusto, extensible y escalable. Sin embargo, esta oportunidad tiene un costo muy alto en complejidad.
El precio de la complejidad
En un sistema operativo distribuido, el grado excepcional de complejidad inherente fácilmente podría convertir a todo el sistema en un anatema para cualquier usuario. Como tal, el precio lógico de realizar un sistema operativo distribuido debe calcularse en términos de superar grandes cantidades de complejidad en muchas áreas y en muchos niveles. Este cálculo incluye la profundidad, la amplitud y el rango de inversión en diseño y planificación arquitectónica necesarios para lograr incluso la implementación más modesta. [11]
Estas consideraciones de diseño y desarrollo son críticas e implacables. Por ejemplo, se requiere una comprensión profunda de la arquitectura general y los detalles de diseño de un sistema operativo distribuido en un punto excepcionalmente temprano. [1] Una serie exhaustiva de consideraciones de diseño son inherentes al desarrollo de un sistema operativo distribuido. Cada una de estas consideraciones de diseño puede afectar potencialmente a muchas de las demás en un grado significativo. Esto conduce a un esfuerzo masivo en un enfoque equilibrado, en términos de las consideraciones de diseño individual y muchas de sus permutaciones. Como ayuda en este esfuerzo, la mayoría confía en la experiencia y la investigación documentadas en potencia informática distribuida.
Historia
Los esfuerzos de investigación y experimentación comenzaron en serio en la década de 1970 y continuaron durante la década de 1990, con un interés centrado en su punto máximo a fines de la década de 1980. Durante este período se introdujeron varios sistemas operativos distribuidos; sin embargo, muy pocas de estas implementaciones lograron incluso un éxito comercial modesto.
Las implementaciones fundamentales y pioneras de los conceptos primitivos de componentes de sistemas operativos distribuidos datan de principios de la década de 1950. [12] [13] [14] Algunos de estos pasos individuales no se centraron directamente en la computación distribuida y, en ese momento, es posible que muchos no se hayan dado cuenta de su importante impacto. Estos esfuerzos pioneros sentaron una base importante e inspiraron la investigación continua en áreas relacionadas con la computación distribuida. [15] [16] [17] [18] [19] [20]
A mediados de la década de 1970, la investigación produjo importantes avances en la computación distribuida. Estos avances proporcionaron una base sólida y estable para los esfuerzos que continuaron durante la década de 1990.
La proliferación acelerada de múltiples procesadores y procesadores de múltiples núcleos sistemas de investigación dirigido a un resurgimiento del concepto OS distribuido.
1950
El DYSEAC
Uno de los primeros esfuerzos fue el DYSEAC , una computadora síncrona de propósito general . En una de las primeras publicaciones de la Association for Computing Machinery , en abril de 1954, un investigador de la Oficina Nacional de Estándares , ahora el Instituto Nacional de Estándares y Tecnología ( NIST ), presentó una especificación detallada del DYSEAC. La introducción se centró en los requisitos de las aplicaciones previstas, incluidas las comunicaciones flexibles, pero también mencionó otras computadoras:
Finalmente, los dispositivos externos podrían incluso incluir otras computadoras a gran escala que empleen el mismo lenguaje digital que el DYSEAC. Por ejemplo, el SEAC u otras computadoras similares a él podrían conectarse al DYSEAC y, mediante el uso de programas coordinados, podrían trabajar juntos en cooperación mutua en una tarea común ... En consecuencia [,] la computadora puede usarse para coordinar las diversas actividades de todos los dispositivos externos en una operación de conjunto eficaz.
- ALAN L. LEINER, Especificaciones del sistema para el DYSEAC
La especificación discutió la arquitectura de los sistemas de múltiples computadoras, prefiriendo peer-to-peer en lugar de maestro-esclavo.
Cada miembro de dicho grupo interconectado de computadoras separadas es libre en cualquier momento para iniciar y enviar órdenes de control especiales a cualquiera de sus socios en el sistema. Como consecuencia, el control de supervisión sobre la tarea común puede inicialmente distribuirse libremente por todo el sistema y luego concentrarse temporalmente en una computadora, o incluso pasar rápidamente de una máquina a otra cuando surja la necesidad. … Las diversas instalaciones de interrupción que se han descrito se basan en la cooperación mutua entre la computadora y los dispositivos externos subsidiarios de la misma, y no reflejan simplemente una simple relación maestro-esclavo.
- ALAN L. LEINER, Especificaciones del sistema para el DYSEAC
Este es uno de los primeros ejemplos de una computadora con control distribuido. Los informes del Departamento del Ejército [21] lo certificaron como confiable y que pasó todas las pruebas de aceptación en abril de 1954. Se completó y entregó a tiempo, en mayo de 1954. Se trataba de una " computadora portátil ", alojada en un camión con remolque. , con 2 vehículos auxiliares y 6 toneladas de capacidad frigorífica .
Lincoln TX-2
Descrito como un sistema experimental de entrada y salida, el Lincoln TX-2 enfatizó los dispositivos de entrada y salida flexibles y simultáneamente operativos, es decir, la multiprogramación . El diseño del TX-2 fue modular, lo que permitió un alto grado de modificación y expansión. [13]
El sistema empleó la técnica del programa de secuencia múltiple. Esta técnica permitió que múltiples contadores de programas se asociaran cada uno con una de las 32 posibles secuencias de código de programa. Estas secuencias priorizadas explícitamente se podrían intercalar y ejecutar simultáneamente, afectando no solo el cálculo en proceso, sino también el flujo de control de secuencias y la conmutación de dispositivos. Mucha discusión relacionada con la secuenciación de dispositivos.
Similar a DYSEAC, los dispositivos TX-2 programados por separado pueden operar simultáneamente, aumentando el rendimiento . La potencia total de la unidad central estaba disponible para cualquier dispositivo. El TX-2 fue otro ejemplo de un sistema que exhibía control distribuido, su unidad central no tenía control dedicado.
Celdas intercomunicadas
Uno de los primeros esfuerzos para abstraer el acceso a la memoria fue Intercomunicarse Celdas, donde una celda estaba compuesta por una colección de elementos de memoria . Un elemento de memoria era básicamente un relé o flip-flop electrónico binario . Dentro de una celda había dos tipos de elementos, símbolo y celda . Cada estructura de celda almacena datos en una cadena de símbolos, que consta de un nombre y un conjunto de parámetros . La información está vinculada a través de asociaciones celulares. [14]
La teoría sostenía que el direccionamiento es un desperdicio y un nivel de direccionamiento indirecto sin valor . Se accedió a la información de dos formas, directa y de recuperación cruzada. La recuperación directa acepta un nombre y devuelve un conjunto de parámetros. Proyectos de recuperación cruzada a través de conjuntos de parámetros y devuelve un conjunto de nombres que contienen el subconjunto de parámetros dado . Esto era similar a una estructura de datos de tabla hash modificada que permitía múltiples valores (parámetros) para cada clave (nombre).
La memoria celular tendría muchas ventajas: | ||
Una parte importante de la lógica de un sistema se distribuye dentro de las asociaciones de información almacenada en las celdas, | ||
Este flujo de asociación de información está de alguna manera guiado por el acto de almacenar y recuperar, | ||
El tiempo requerido para el almacenamiento y la recuperación es mayormente constante y no guarda ninguna relación con el tamaño y el factor de llenado de la memoria. | ||
Las celdas son lógicamente indistinguibles, lo que las hace flexibles de usar y relativamente simples de ampliar en tamaño. |
Esta configuración fue ideal para sistemas distribuidos. La proyección en tiempo constante a través de la memoria para almacenar y recuperar era inherentemente atómica y exclusiva . Las características distribuidas intrínsecas de la memoria celular serían invaluables. El impacto en el usuario , hardware / dispositivo o interfaces de programación de aplicaciones fue indirecto. Los autores estaban considerando sistemas distribuidos, declarando:
Queríamos presentar aquí las ideas básicas de un sistema lógico distribuido con ... el concepto macroscópico de diseño lógico, lejos del escaneo, la búsqueda, el direccionamiento y el conteo, es igualmente importante. Debemos, a toda costa, liberarnos de las cargas de los problemas locales detallados que solo convienen a una máquina que se encuentra en un nivel inferior a la escala evolutiva de las máquinas.
- Chung-Yeol (CY) Lee, celdas intercomunicadas, base para una computadora lógica distribuida
Trabajo fundacional
Abstracción coherente de la memoria
Algoritmos para la sincronización escalable en multiprocesadores de memoria compartida [22]
Abstracción del sistema de archivos
Medidas de un sistema de archivos distribuido [23]
Coherencia de la memoria en sistemas de memoria virtual compartida [24]
Abstracción de transacciones
Transactions
Sagas [25]
Memoria transaccional Transacciones de memoria
componible [26]
Memoria transaccional: soporte arquitectónico para estructuras de datos sin bloqueo [27]
Memoria transaccional de software para estructuras de datos de tamaño dinámico [28]
Memoria transaccional de software [29]
Abstracción de la persistencia
OceanStore: una arquitectura para almacenamiento persistente a escala global [30]
Abstracción del coordinador
Votación ponderada para datos replicados [31]
Consenso en presencia de sincronía parcial [32]
Abstracción de confiabilidad
Verificaciones de cordura
El problema de los generales bizantinos [33]
Procesadores de parada de falla: un enfoque para diseñar sistemas informáticos tolerantes a fallas [34]
Recuperación Instantáneas distribuidas : determinación de los estados globales de los sistemas distribuidos [35] Recuperación optimista en sistemas distribuidos [36]
Modelos de computación distribuida
Tres distribuciones básicas
Para ilustrar mejor este punto, examine tres arquitecturas de sistemas ; centralizado, descentralizado y distribuido. En este examen, considere tres aspectos estructurales: organización, conexión y control. La organización describe las características de la disposición física de un sistema. La conexión cubre las vías de comunicación entre los nodos. Control gestiona el funcionamiento de las dos consideraciones anteriores.
Organización
Un sistema centralizado tiene un nivel de estructura, donde todos los elementos constitutivos dependen directamente de un solo elemento de control. Un sistema descentralizado es jerárquico. El nivel inferior une subconjuntos de las entidades de un sistema. Estos subconjuntos de entidades, a su vez, se combinan en niveles superiores, culminando finalmente en un elemento maestro central. Un sistema distribuido es una colección de elementos autónomos sin concepto de niveles.
Conexión
Los sistemas centralizados conectan a los componentes directamente a una entidad maestra central en forma de concentrador y radio. Un sistema descentralizado (también conocido como sistema de red ) incorpora rutas directas e indirectas entre los elementos constituyentes y la entidad central. Normalmente, esto se configura como una jerarquía con solo una ruta más corta entre dos elementos. Finalmente, el sistema operativo distribuido no requiere ningún patrón; Son posibles conexiones directas e indirectas entre dos elementos cualesquiera. Considere el fenómeno de la década de 1970 del " arte de cuerdas " o un dibujo de espirógrafo como un sistema completamente conectado , y la telaraña o el Sistema de Autopistas Interestatales entre ciudades de Estados Unidos como ejemplos de un sistema parcialmente conectado .
Control
Los sistemas centralizados y descentralizados han dirigido flujos de conexión hacia y desde la entidad central, mientras que los sistemas distribuidos se comunican a lo largo de rutas arbitrarias. Ésta es la noción fundamental de la tercera consideración. El control implica la asignación de tareas y datos a los elementos del sistema que equilibran la eficiencia, la capacidad de respuesta y la complejidad.
Los sistemas centralizados y descentralizados ofrecen más control, lo que potencialmente facilita la administración al limitar las opciones. Los sistemas distribuidos son más difíciles de controlar explícitamente, pero escalan mejor horizontalmente y ofrecen menos puntos de falla en todo el sistema. Las asociaciones se ajustan a las necesidades impuestas por su diseño pero no por el caos organizacional
Consideraciones de diseño
Transparencia
La transparencia o imagen de un solo sistema se refiere a la capacidad de una aplicación para tratar el sistema en el que opera sin importar si está distribuido y sin tener en cuenta el hardware u otros detalles de implementación. Muchas áreas de un sistema pueden beneficiarse de la transparencia, incluido el acceso, la ubicación, el rendimiento, la nomenclatura y la migración. La consideración de la transparencia afecta directamente la toma de decisiones en todos los aspectos del diseño de un sistema operativo distribuido. La transparencia puede imponer ciertos requisitos y / o restricciones sobre otras consideraciones de diseño.
Opcionalmente, los sistemas pueden violar la transparencia en diversos grados para cumplir con los requisitos específicos de la aplicación. Por ejemplo, un sistema operativo distribuido puede presentar un disco duro en una computadora como "C:" y una unidad en otra computadora como "G:". El usuario no requiere ningún conocimiento de los controladores del dispositivo o la ubicación de la unidad; ambos dispositivos funcionan de la misma manera, desde la perspectiva de la aplicación. Una interfaz menos transparente puede requerir que la aplicación sepa qué computadora aloja la unidad. Dominios de transparencia:
- Transparencia de ubicación: la transparencia de ubicación comprende dos aspectos distintos de transparencia, transparencia de nombres y movilidad del usuario. La transparencia de nombres requiere que nada en las referencias físicas o lógicas a cualquier entidad del sistema deba exponer ninguna indicación de la ubicación de la entidad, o su relación local o remota con el usuario o la aplicación. La movilidad del usuario requiere la referencia constante de las entidades del sistema, independientemente de la ubicación del sistema desde la que se origina la referencia. [8] : 20
- Transparencia de acceso : las entidades del sistema local y remoto deben permanecer indistinguibles cuando se ven a través de la interfaz de usuario. El sistema operativo distribuido mantiene esta percepción mediante la exposición de un mecanismo de acceso único para una entidad del sistema, independientemente de que esa entidad sea local o remota para el usuario. La transparencia dicta que cualquier diferencia en los métodos de acceso a cualquier entidad del sistema en particular, ya sea local o remota, debe ser invisible e indetectable para el usuario. [3] : 84
- Transparencia de la migración : los recursos y las actividades migran de un elemento a otro controlado únicamente por el sistema y sin el conocimiento o la acción del usuario / aplicación. [9] : 16
- Transparencia de replicación : el proceso o el hecho de que un recurso se haya duplicado en otro elemento ocurre bajo el control del sistema y sin el conocimiento o la intervención del usuario / aplicación. [9] : 16
- Transparencia de simultaneidad : los usuarios / aplicaciones desconocen y no se ven afectados por la presencia / actividades de otros usuarios. [9] : 16
- Transparencia de fallas : el sistema es responsable de la detección y reparación de fallas del sistema. No hay ningún conocimiento / acción del usuario involucrado más que esperar a que el sistema resuelva el problema. [10] : 30
- Transparencia en el rendimiento : el sistema es responsable de la detección y corrección de las deficiencias de rendimiento locales o globales. Tenga en cuenta que las políticas del sistema pueden preferir algunos usuarios / clases de usuario / tareas sobre otros. Sin conocimiento o interacción del usuario. esta involucrado. [8] : 23
- Transparencia de tamaño / escala : el sistema es responsable de administrar su alcance geográfico, número de nodos, nivel de capacidad de nodo sin ningún conocimiento o interacción del usuario requerido. [8] : 23
- Transparencia en las revisiones : el sistema es responsable de las actualizaciones, revisiones y cambios en la infraestructura del sistema sin que el usuario lo sepa ni actúe. [10] : 30
- Transparencia de control : el sistema es responsable de proporcionar toda la información del sistema, constantes, propiedades, ajustes de configuración, etc. en una apariencia, connotación y denotación consistente para todos los usuarios y aplicaciones. [3] : 84
- Transparencia de datos : el sistema es responsable de proporcionar datos a las aplicaciones sin el conocimiento del usuario o la acción relacionada con el lugar donde el sistema los almacena. [3] : 85
- Transparencia del paralelismo : el sistema es responsable de explotar cualquier capacidad para paralelizar la ejecución de tareas sin el conocimiento o la interacción del usuario. Posiblemente el aspecto más difícil de la transparencia y descrito por Tanenbaum como el "Santo Grial" para los diseñadores de sistemas distribuidos. [37] : 23-25
Comunicación entre procesos
La comunicación entre procesos (IPC) es la implementación de la comunicación general, la interacción de procesos y el flujo de datos entre subprocesos y / o procesos tanto dentro de un nodo como entre nodos en un sistema operativo distribuido. Los requisitos de comunicación entre nodos y entre nodos impulsan el diseño de IPC de bajo nivel, que es el enfoque típico para implementar funciones de comunicación que apoyan la transparencia. En este sentido, la comunicación entre procesos es el mayor concepto subyacente en las consideraciones de diseño de bajo nivel de un sistema operativo distribuido.
Gestión de proceso
La gestión de procesos proporciona políticas y mecanismos para compartir de forma eficaz y eficiente los recursos entre procesos distribuidos. Estas políticas y mecanismos respaldan operaciones que involucran la asignación y desasignación de procesos y puertos a procesadores, así como mecanismos para ejecutar, suspender, migrar, detener o reanudar la ejecución de procesos. Si bien estos recursos y operaciones pueden ser locales o remotos entre sí, el sistema operativo distribuido mantiene el estado y la sincronización de todos los procesos del sistema.
Por ejemplo, el equilibrio de carga es una función de gestión de procesos común. El equilibrio de carga supervisa el rendimiento de los nodos y es responsable de cambiar la actividad entre los nodos cuando el sistema está fuera de equilibrio. Una función de equilibrio de carga es elegir un proceso para mover. El núcleo puede emplear varios mecanismos de selección, incluida la elección basada en prioridades. Este mecanismo elige un proceso basado en una política como "solicitud más reciente". El sistema implementa la política
Administracion de recursos
Los recursos del sistema , como la memoria, los archivos, los dispositivos, etc., se distribuyen por todo el sistema y, en un momento dado, cualquiera de estos nodos puede tener cargas de trabajo de ligeras a inactivas. El reparto de carga y el equilibrio de carga requieren muchas decisiones orientadas a políticas, que van desde encontrar CPU inactivas, cuándo mover y cuáles mover. Existen muchos algoritmos para ayudar en estas decisiones; sin embargo, esto requiere un segundo nivel de política de toma de decisiones para elegir el algoritmo que mejor se adapte al escenario y las condiciones que lo rodean.
Fiabilidad
El sistema operativo distribuido puede proporcionar los recursos y servicios necesarios para lograr altos niveles de confiabilidad , o la capacidad de prevenir y / o recuperarse de errores. Las fallas son defectos físicos o lógicos que pueden causar errores en el sistema. Para que un sistema sea confiable, de alguna manera debe superar los efectos adversos de las fallas.
Los métodos primarios para tratar con los fallos incluyen la evitación de fallos , tolerancia a fallos , y la detección de fallos y recuperación . La prevención de fallas cubre las medidas proactivas tomadas para minimizar la ocurrencia de fallas. Estas medidas proactivas pueden adoptar la forma de transacciones , replicación y copias de seguridad . La tolerancia a fallas es la capacidad de un sistema para continuar funcionando en presencia de una falla. En el caso, el sistema debería detectar y recuperar la funcionalidad completa. En cualquier caso, las acciones que se tomen deben hacer todo lo posible para preservar la imagen del sistema único .
Disponibilidad
La disponibilidad es la fracción de tiempo durante la cual el sistema puede responder a las solicitudes.
Actuación
Muchas métricas de referencia cuantifican el rendimiento ; rendimiento, tiempo de respuesta, finalización de trabajos por unidad de tiempo, utilización del sistema, etc. Con respecto a un sistema operativo distribuido, el rendimiento se concentra más a menudo en un equilibrio entre el paralelismo del proceso y el IPC. [ cita requerida ] La gestión de la granularidad de la tarea del paralelismo en una relación sensible a los mensajes necesarios para el apoyo es extremadamente eficaz. [ cita requerida ] Además, identificar cuándo es más beneficioso migrar un proceso a sus datos, en lugar de copiar los datos, también es eficaz. [ cita requerida ]
Sincronización
Los procesos concurrentes en cooperación tienen una necesidad inherente de sincronización , lo que garantiza que los cambios se produzcan de forma correcta y predecible. Tres situaciones básicas que definen el alcance de esta necesidad:
- uno o más procesos deben sincronizarse en un punto dado para que uno o más procesos continúen,
- uno o más procesos deben esperar una condición asincrónica para continuar,
- o un proceso debe establecer acceso exclusivo a un recurso compartido.
La sincronización incorrecta puede conducir a múltiples modos de falla, incluida la pérdida de atomicidad, consistencia, aislamiento y durabilidad , interbloqueo , bloqueo activo y pérdida de serialización . [ cita requerida ]
Flexibilidad
La flexibilidad en un sistema operativo distribuido se mejora a través de la modularidad y las características del sistema operativo distribuido, y al proporcionar un conjunto más rico de servicios de nivel superior. La integridad y calidad del kernel / microkernel simplifica la implementación de tales servicios y potencialmente permite a los proveedores de servicios una mayor variedad de proveedores para tales servicios. [ cita requerida ]
Investigar
Modelo replicado extendido a un modelo de objeto componente
Diseño arquitectónico del sistema operativo distribuido E1 [38]
El sistema operativo distribuido Cronus [39]
Diseño y desarrollo del sistema operativo distribuido MINIX [40]
Exposición a la complejidad / confianza a través de la responsabilidad aceptada
- Escala y rendimiento en el kernel de aislamiento Denali. [41]
Sistemas enfocados en múltiples / muchos núcleos
- Multikernel: una nueva arquitectura de SO para sistemas multinúcleo escalables. [42]
- Corey: un sistema operativo para muchos núcleos. [43]
- Almos: Sistema operativo de gestión avanzada de localidades para cc-NUMA Many-Cores. [44]
Procesamiento distribuido sobre extremos en heterogeneidad
- Helios: multiprocesamiento heterogéneo con núcleos satélite. [45]
Efectivo y estable en múltiples niveles de complejidad.
- Teselación: Partición de espacio-tiempo en un SO cliente Manycore. [46]
Ver también
- Computación distribuída
- Plan 9 de Bell Labs
- Infierno
- MINIX
- Imagen de sistema único (SSI)
- Arquitectura de sistemas informáticos
- Multikernel
- Lista de publicaciones importantes en computación concurrente, paralela y distribuida
- Proyectos de sistema operativo
- Premio Edsger W. Dijkstra en Computación Distribuida
- Lista de conferencias de informática distribuida
- Lista de proyectos de computación distribuida
Referencias
- ↑ a b Tanenbaum, Andrew S (septiembre de 1993). "Sistemas operativos distribuidos anno 1992. ¿Qué hemos aprendido hasta ahora?" . Ingeniería de Sistemas Distribuidos . 1 (1): 3–10. Bibcode : 1993DSE ..... 1 .... 3T . doi : 10.1088 / 0967-1846 / 1/1/001 .
- ^ Nutt, Gary J. (1992). Sistemas operativos centralizados y distribuidos . Prentice Hall. ISBN 978-0-13-122326-4.
- ^ a b c d e f Gościński, Andrzej (1991). Sistemas operativos distribuidos: el diseño lógico . Addison-Wesley Pub. Co. ISBN 978-0-201-41704-3.
- ^ Fortier, Paul J. (1986). Diseño de Sistemas Operativos Distribuidos: Conceptos y Tecnología . Publicaciones de intertexto. ISBN 9780070216211.
- ^ Hansen, Per Brinch, ed. (2001). Sistemas operativos clásicos: desde el procesamiento por lotes hasta los sistemas distribuidos . Saltador. ISBN 978-0-387-95113-3.
- ^ Uso de LOTOS para especificar el núcleo del sistema operativo distribuido CHORUS Pecheur, C. 1992. Uso de LOTOS para especificar el núcleo del sistema operativo distribuido CHORUS. Computación. Comun. 15, 2 (marzo de 1992), 93-102.
- ^ COOL: soporte del kernel para entornos orientados a objetos Habert, S. y Mosseri, L. 1990. COOL: soporte del kernel para entornos orientados a objetos. En Actas de la Conferencia Europea sobre Programación Orientada a Objetos en Sistemas, Lenguajes y Aplicaciones de Programación Orientada a Objetos (Ottawa, Canadá). OOPSLA / ECOOP '90. ACM, Nueva York, NY, 269-275.
- ^ a b c d e Sinha, Pradeep Kumar (1997). Sistemas operativos distribuidos: conceptos y diseño . Prensa IEEE. ISBN 978-0-7803-1119-0.
- ^ a b c d Galli, Doreen L. (2000). Sistemas operativos distribuidos: conceptos y práctica . Prentice Hall. ISBN 978-0-13-079843-5.
- ^ a b c d Chow, Randy; Theodore Johnson (1997). Sistemas operativos distribuidos y algoritmos . Addison Wesley. ISBN 978-0-201-49838-7.
- ^ Surajbali, B., Coulson, G., Greenwood, P. y Grace, P. 2007. Middleware reflectante de aumento con una capa de soporte de orientación de aspecto. In Proceedings of the 6th international Workshop on Adaptive and Reflective Middleware: Realizado en la Conferencia internacional de Middleware ACM / IFIP / USENIX (Newport Beach, CA, 26 al 30 de noviembre de 2007). ARM '07. ACM, Nueva York, NY, 1-6.
- ^ Leiner, Alan L. (abril de 1954). "Especificaciones del sistema para el DYSEAC" . Revista de la ACM . 1 (2): 57–81. doi : 10.1145 / 320772.320773 .
- ^ a b Forgie, James W. (26 al 28 de febrero de 1957). El sistema de entrada-salida Lincoln TX-2 . Conferencia de Computación Conjunta Occidental: Técnicas para la Confiabilidad. Los Ángeles, California: Asociación de Maquinaria de Computación. págs. 156–160. doi : 10.1145 / 1455567.1455594 . ISBN 9781450378611.
- ^ a b CY Lee (4 y 6 de diciembre de 1962). Células intercomunicadas, base de una computadora lógica distribuida . Conferencia Conjunta de Computación de Otoño. Filadelfia, Pensilvania: Asociación de Maquinaria de Computación. págs. 130-136. doi : 10.1145 / 1461518.1461531 .
- ^ Dreyfus, Phillippe (1958-05-08) [1958-05-06], escrito en Los Ángeles, "System design of the Gamma 60" (PDF) , Proceedings of the May 6–8, 1958, Western Joint Computer Conference : contrastes en Informática , ACM, Nueva York, NY, EE.UU., pp. 130-133, IRE-ACM-AIEE '58 (Oeste), archivados (PDF) desde el original, el 03/04/2017 , recuperados 03/04/2017
- ^ Leiner, AL, Notz, WA, Smith, JL y Weinberger, A. 1958. Organización de una red de computadoras para cumplir con los plazos. En artículos y debates presentados en la Conferencia de Computación Conjunta del Este del 9 al 13 de diciembre de 1957: Computadoras con fechas límite que cumplir (Washington, DC, 9 al 13 de diciembre de 1957). IRE-ACM-AIEE '57
- ^ Leiner, AL, Smith, JL, Notz, WA y Weinberger, A. 1958. PILOT, el sistema multicomputador NBS. En artículos y debates presentados en la Conferencia de Computación Conjunta del Este del 3 al 5 de diciembre de 1958: Computadoras modernas: objetivos, diseños, aplicaciones (Filadelfia, Pensilvania, 03–05 de diciembre de 1958). AIEE-ACM-IRE '58 (Este). ACM, Nueva York, NY, 71-75.
- ^ Bauer, WF 1958. Diseño informático desde el punto de vista del programador. En artículos y debates presentados en la Conferencia de Computación Conjunta del Este del 3 al 5 de diciembre de 1958: Computadoras modernas: objetivos, diseños, aplicaciones (Filadelfia, Pensilvania, 03–05 de diciembre de 1958). AIEE-ACM-IRE '58 (Este). ACM, Nueva York, NY, 46-51.
- ^ Leiner, AL, Notz, WA, Smith, JL y Weinberger, A. 1959. PILOT: un nuevo sistema informático múltiple. J. ACM 6, 3 (julio de 1959), 313-335.
- ^ Estrin, G. 1960. Organización de sistemas informáticos: la computadora de estructura fija más variable . En artículos presentados en la Conferencia de Computación Western Joint IRE-AIEE-ACM del 3 al 5 de mayo de 1960 (San Francisco, California, 3 al 5 de mayo de 1960). IRE-AIEE-ACM '60 (occidental). ACM, Nueva York, NY, 33-40.
- ^ Martin H. Weik, "Una tercera encuesta de sistemas informáticos digitales electrónicos domésticos", Informe de laboratorios de investigación balística n. ° 1115, pág. 234-5, Aberdeen Proving Ground, Maryland, marzo de 1961
- ^ Mellor-Crummey, JM y Scott, ML 1991. Algoritmos para sincronización escalable en multiprocesadores de memoria compartida . ACM Trans. Computación. Syst. 9, 1 (febrero de 1991), 21-65.
- ^ Baker, MG, Hartman, JH, Kupfer, MD, Shirriff, KW y Ousterhout, JK 1991. Medidas de un sistema de archivos distribuido . En Actas del Decimotercer Simposio de ACM sobre principios de sistemas operativos (Pacific Grove, California, Estados Unidos, 13 al 16 de octubre de 1991). SOSP '91. ACM, Nueva York, NY, 198-212.
- ^ Li, K. y Hudak, P. 1989. Coherencia de la memoria en sistemas de memoria virtual compartida. ACM Trans. Computación. Syst. 7, 4 (noviembre de 1989), 321-359.
- ^ García-Molina, H. y Salem, K. 1987. Sagas. En Actas de la Conferencia internacional ACM SIGMOD de 1987 sobre gestión de datos (San Francisco, California, Estados Unidos, 27 al 29 de mayo de 1987). U. Dayal, Ed. SIGMOD '87. ACM, Nueva York, NY, 249-259.
- ^ Harris, T., Marlow, S., Peyton-Jones, S. y Herlihy, M. 2005. Transacciones de memoria componibles . En Actas del Décimo Simposio ACM SIGPLAN sobre Principios y Práctica de la Programación Paralela (Chicago, IL, EE. UU., 15-17 de junio de 2005). PPoPP '05. ACM, Nueva York, NY, 48-60.
- ^ Herlihy, M. y Moss, JE 1993. Memoria transaccional: soporte arquitectónico para estructuras de datos sin bloqueo . En Proceedings of the 20th Annual International Symposium on Computer Architecture (San Diego, California, Estados Unidos, 16-19 de mayo de 1993). ISCA '93. ACM, Nueva York, NY, 289-300.
- ^ Herlihy, M., Luchangco, V., Moir, M. y Scherer, WN 2003. Software de memoria transaccional para estructuras de datos de tamaño dinámico . En Actas del Vigésimo Segundo Simposio Anual sobre Principios de Computación Distribuida (Boston, Massachusetts, 13 al 16 de julio de 2003). PODC '03. ACM, Nueva York, NY, 92-101.
- ^ Shavit, N. y Touitou, D. 1995. Software de memoria transaccional . En Actas del Decimocuarto Simposio Anual de ACM sobre Principios de Computación Distribuida (Ottawa, Ontario, Canadá, 20 al 23 de agosto de 1995). PODC '95. ACM, Nueva York, NY, 204-213.
- ^ Kubiatowicz, J., Bindel, D., Chen, Y., Czerwinski, S., Eaton, P., Geels, D., Gummadi, R., Rhea, S., Weatherspoon, H., Wells, C. y Zhao, B. 2000. OceanStore: una arquitectura para almacenamiento persistente a escala global . En Actas de la Novena Conferencia internacional sobre soporte arquitectónico para lenguajes de programación y sistemas operativos (Cambridge, Massachusetts, Estados Unidos). ASPLOS-IX. ACM, Nueva York, NY, 190-201.
- ^ Gifford, DK 1979. Votación ponderada para datos replicados . En Actas del Séptimo Simposio de ACM sobre Principios de Sistemas Operativos (Pacific Grove, California, Estados Unidos, 10 al 12 de diciembre de 1979). SOSP '79. ACM, Nueva York, NY, 150-162
- ^ Dwork, C., Lynch, N. y Stockmeyer, L. 1988. Consenso en presencia de sincronía parcial . J. ACM 35, 2 (abril de 1988), 288-323.
- ^ Lamport, L., Shostak, R. y Pease, M. 1982. El problema de los generales bizantinos . ACM Trans. Programa. Lang. Syst. 4, 3 (julio de 1982), 382-401.
- ^ Schlichting, RD y Schneider, FB 1983. Procesadores de parada de falla: un enfoque para diseñar sistemas informáticos tolerantes a fallas. ACM Trans. Computación. Syst. 1, 3 (agosto de 1983), 222-238.
- ^ Chandy, KM y Lamport, L. 1985. Instantáneas distribuidas: determinación de los estados globales de los sistemas distribuidos. ACM Trans. Computación. Syst. 3, 1 (febrero de 1985), 63-75.
- ^ Strom, R. y Yemini, S. 1985. Recuperación optimista en sistemas distribuidos. ACM Trans. Computación. Syst. 3, 3
- ^ Tanenbaum, Andrew S. (1995). Sistemas operativos distribuidos . Prentice Hall. ISBN 978-0-13-219908-7.
- ^ LB Ryzhyk, AY Burtsev. Diseño arquitectónico del sistema operativo distribuido dE1. Revista científica y técnica internacional System Research and Information Technologies, octubre de 2004, Kiev, Ucrania.
- ^ Vinter, ST y Schantz, RE 1986. El sistema operativo distribuido Cronus. En las actas del segundo taller sobre cómo hacer que los sistemas distribuidos funcionen (Ámsterdam, Países Bajos, del 8 al 10 de septiembre de 1986). SE 2. ACM, Nueva York, NY, 1-3.
- ^ Ramesh, KS 1988. Diseño y desarrollo del sistema operativo distribuido MINIX. En Actas de la Decimosexta Conferencia Anual ACM sobre Ciencias de la Computación de 1988 (Atlanta, Georgia, Estados Unidos). CSC '88. ACM, Nueva York, NY, 685.
- ^ Whitaker, A., Shaw, M. y Gribble, SD 2002. En las actas del quinto simposio sobre diseño e implementación de sistemas operativos
- ^ Baumann, A., Barham, P., Dagand, P., Harris, T., Isaacs, R., Peter, S., Roscoe, T., Schüpbach, A. y Singhania, A. 2009. En Proceedings del 22º Simposio de ACM SIGOPS sobre principios de sistemas operativos (Big Sky, Montana, EE. UU., 11 al 14 de octubre de 2009). SOSP '09.
- ^ S. Boyd-Wickizer, H. Chen, R. Chen, Y. Mao, F. Kashoek, R. Morris, A. Pesterev, L. Stein, M. Wu, Y. Dai, Y. Zhang y Z. Zhang. Actas del Simposio de 2008 sobre diseño e implementación de sistemas operativos (OSDI), diciembre de 2008.
- ^ Almaless, G. y Wajsbürt, F. 2011. En Actas del quinto seminario nacional de GDR SoC-SIP, Lyon, Francia, 2011.
- ^ Nightingale, EB, Hodson, O., McIlroy, R., Hawblitzel, C. y Hunt, G. 2009. En Actas del 22º Simposio de ACM SIGOPS sobre principios de sistemas operativos (Big Sky, Montana, EE. UU., 11 de octubre - 14, 2009). SOSP '09.
- ^ Rose Liu, Kevin Klues y Sarah Bird, Universidad de California en Berkeley; Steven Hofmeyr, Laboratorio Nacional Lawrence Berkeley; Krste Asanović y John Kubiatowicz, Universidad de California en Berkeley. HotPar09.
enlaces externos
- Computación distribuida en Curlie
- Revistas de computación distribuida en Curlie
- Laboratorio de sistemas operativos distribuidos y paralelos del MIT
- Laboratorio de computación paralela UCB
- Laboratorio de datos paralelos
- El entorno distribuido de Plan 9
- Sistema operativo distribuido E1
- Fuente Amoeba DOS
- Página de inicio de Amoeba
- USENIX: Asociación de informática avanzada
- Cómo funcionan las cosas: sistemas operativos
- Algoritmos para sincronización escalable