Un sistema operativo distribuido es un software de sistema que se ejecuta sobre una colección de nodos computacionales independientes, conectados en red , que se comunican entre sí y están físicamente separados. Estos nodos gestionan tareas que son atendidas por múltiples CPU. [ 1 ] Cada nodo individual contiene un subconjunto específico del software del sistema operativo global agregado. Cada subconjunto es un compuesto de dos proveedores de servicios distintos. [ 2 ] El primero es un núcleo mínimo ubicuo , o micronúcleo , que controla directamente el hardware de ese nodo. El segundo es una colección de nivel superior de componentes de gestión del sistema que coordinan las actividades individuales y colaborativas del nodo. Estos componentes abstraen las funciones del micronúcleo y dan soporte a las aplicaciones de usuario. [ 3 ]
El microkernel y el conjunto de componentes de gestión trabajan conjuntamente. Apoyan el objetivo del sistema de integrar múltiples recursos y funcionalidades de procesamiento en un sistema eficiente y estable. [ 4 ] Esta integración perfecta de nodos individuales en un sistema global se denomina transparencia o imagen de sistema único ; describe la ilusión que se ofrece a los usuarios de que el sistema global se presenta como una única entidad computacional.
Descripción

Un sistema operativo distribuido proporciona los servicios y la funcionalidad esenciales de un sistema operativo, pero añade atributos y configuraciones específicas para admitir requisitos adicionales, como una mayor escalabilidad y disponibilidad. Para el usuario, un sistema operativo distribuido funciona de forma similar a un sistema operativo monolítico de un solo nodo . Es decir, aunque consta de varios nodos, para los usuarios y las aplicaciones se presenta como un único nodo.
Separar la funcionalidad mínima del sistema de los servicios modulares adicionales a nivel de usuario proporciona una « separación entre mecanismo y política ». Mecanismo y política pueden interpretarse simplemente como «qué se hace» y «cómo se hace», respectivamente. Esta separación aumenta la flexibilidad y la escalabilidad.
Descripción general
El núcleo
En cada ubicación (normalmente un nodo), el núcleo proporciona un conjunto mínimo completo de utilidades a nivel de nodo necesarias para operar el hardware y los recursos subyacentes del nodo. Estos mecanismos incluyen la asignación, la gestión y la disposición de los recursos, los procesos, la comunicación y las funciones de soporte para la gestión de entrada/salida del nodo . [ 5 ] Dentro del núcleo, el subsistema de comunicaciones es de suma importancia para un sistema operativo distribuido. [ 3 ]
En un sistema operativo distribuido, el núcleo suele admitir un conjunto mínimo de funciones, que incluyen 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 micronúcleo . [ 6 ] [ 7 ] Su naturaleza modular mejora la fiabilidad y la seguridad, características esenciales para un sistema operativo distribuido. [ 8 ]
Gestión del sistema
Los componentes de gestión del sistema son procesos de software que definen las políticas del nodo . Estos componentes forman parte del sistema operativo fuera del núcleo. Proporcionan comunicación de alto nivel, gestión de procesos y recursos, fiabilidad, rendimiento y seguridad. Los componentes igualan las funciones de un sistema de entidad única, añadiendo la transparencia necesaria 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 gestión del sistema asumen las responsabilidades de "defensa" 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 su conjunto pueden ayudar a identificar rendimientos decrecientes . La separación entre políticas y mecanismos mitiga dichos conflictos. [ 9 ]
Trabajando juntos como un sistema operativo
La arquitectura y el diseño de un sistema operativo distribuido deben cumplir tanto los objetivos de los nodos individuales como los del sistema global. La arquitectura y el diseño deben abordarse de manera coherente, separando la política del mecanismo. De este modo, un sistema operativo distribuido busca proporcionar un marco de computación distribuida eficiente y fiable que permita una mínima conciencia por parte del usuario de los esfuerzos subyacentes de comando y control. [ 8 ]
La colaboración multinivel entre el núcleo y los componentes de gestión del sistema, y a su vez entre los distintos nodos de un sistema operativo distribuido, constituye el principal desafío funcional de este tipo de sistema. En este punto del sistema, es fundamental mantener una perfecta armonía de propósito y, simultáneamente, una total desconexión entre la intención y la implementación. Este desafío representa la oportunidad del sistema operativo distribuido para crear la base y el marco de un sistema fiable, eficiente, disponible, robusto, extensible y escalable. Sin embargo, esta oportunidad conlleva un alto costo en términos de complejidad.
El precio de la complejidad
En un sistema operativo distribuido, el excepcional grado de complejidad inherente podría fácilmente convertir todo el sistema en un anatema para cualquier usuario. Por lo tanto, el precio lógico de implementar un sistema operativo distribuido debe calcularse en términos de superar enormes cantidades de complejidad en muchas áreas y en muchos niveles. Este cálculo incluye la profundidad, amplitud y alcance de la inversión en diseño y la planificación arquitectónica necesarias para lograr incluso la implementación más modesta. [ 10 ]
Estas consideraciones de diseño y desarrollo son críticas e implacables. Por ejemplo, se requiere una comprensión profunda de la arquitectura y el diseño general de un sistema operativo distribuido desde una etapa excepcionalmente temprana. [ 1 ] El desarrollo de un sistema operativo distribuido implica una amplia gama de consideraciones de diseño. Cada una de estas consideraciones puede afectar significativamente a muchas otras. Esto conlleva un esfuerzo considerable para lograr un enfoque equilibrado, tanto en lo que respecta a las consideraciones de diseño individuales como a sus múltiples combinaciones. Para facilitar este esfuerzo, la mayoría se basa en la experiencia documentada y la investigación en computación 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, alcanzando su punto álgido a finales de la década de 1980. Durante este período se introdujeron varios sistemas operativos distribuidos; sin embargo, muy pocas de estas implementaciones lograron un éxito comercial, aunque fuera modesto.
Las implementaciones fundamentales y pioneras de conceptos primitivos de componentes de sistemas operativos distribuidos datan de principios de la década de 1950. [ 11 ] [ 12 ] [ 13 ] Algunos de estos pasos individuales no se centraron directamente en la computación distribuida y, en ese momento, muchos quizás no se percataron de su importante impacto. Estos esfuerzos pioneros sentaron bases importantes e inspiraron la investigación continua en áreas relacionadas con la computación distribuida. [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ] [ 19 ]
A mediados de la década de 1970, la investigación produjo importantes avances en la computación distribuida. Estos descubrimientos sentaron una base sólida y estable para los esfuerzos que continuaron durante la década de 1990.
La creciente proliferación de la investigación sobre sistemas de procesadores multinúcleo y multiprocesador ha propiciado un resurgimiento del concepto de sistema operativo distribuido.
El DYSEAC
Uno de los primeros intentos 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 National Bureau of Standards —ahora National Institute of Standards and Technology ( 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 completas que empleen el mismo lenguaje digital que el DYSEAC. Por ejemplo, el SEAC u otras computadoras similares podrían conectarse al DYSEAC y, mediante programas coordinados, trabajar juntas en cooperación mutua para una tarea común. En consecuencia, la computadora puede utilizarse 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 analizaba la arquitectura de los sistemas multicomputadora, dando preferencia a la arquitectura peer-to-peer en lugar de la maestro-esclavo.
Cada miembro de un grupo interconectado de ordenadores independientes puede, en cualquier momento, iniciar y enviar órdenes de control especiales a cualquiera de sus socios en el sistema. En consecuencia, el control de supervisión de la tarea común puede distribuirse inicialmente de forma laxa por todo el sistema y luego concentrarse temporalmente en un ordenador, o incluso pasarse rápidamente de una máquina a otra según sea necesario. …Las diversas funciones de interrupción descritas se basan en la cooperación mutua entre el ordenador y los dispositivos externos que lo alimentan, y no reflejan simplemente una 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 [ 20 ] certificaron su fiabilidad y que superó 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 dos vehículos de apoyo y una capacidad de refrigeración de seis toneladas .
Lincoln TX-2
Descrito como un sistema experimental de entrada-salida, el Lincoln TX-2 hacía hincapié en dispositivos de entrada-salida flexibles y de funcionamiento simultáneo, es decir, multiprogramación . El diseño del TX-2 era modular, lo que permitía un alto grado de modificación y expansión. [ 12 ]
El sistema empleaba la técnica de programación de secuencias múltiples. Esta técnica permitía que varios contadores de programa se asociaran a una de las 32 posibles secuencias de código. Estas secuencias, con prioridad explícita, podían intercalarse y ejecutarse simultáneamente, afectando no solo al cálculo en curso, sino también al flujo de control de las secuencias y a la conmutación de dispositivos. Se debatió ampliamente sobre la secuenciación de dispositivos.
Al igual que en DYSEAC, los dispositivos TX-2, programados individualmente, pueden operar simultáneamente, lo que aumenta el rendimiento . La potencia total de la unidad central estaba disponible para cualquier dispositivo. El TX-2 fue otro ejemplo de un sistema con control distribuido, ya que su unidad central no contaba con un control dedicado.
Células intercomunicantes
Un primer intento de abstraer el acceso a la memoria fueron las Celdas Intercomunicantes, donde una celda estaba compuesta por una colección de elementos de memoria . Un elemento de memoria era básicamente un biestable o relé 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 consiste en un nombre y un conjunto de parámetros . La información se vincula mediante asociaciones de celdas. [ 13 ]
La teoría sostenía que el direccionamiento era un nivel de indirección ineficiente y sin valor . Se accedía a la información de dos maneras: directa y cruzada. La recuperación directa aceptaba un nombre y devolvía un conjunto de parámetros. La recuperación cruzada recorría los conjuntos de parámetros y devolvía un conjunto de nombres que contenían el subconjunto de parámetros especificado. Esto era similar a una estructura de datos de tabla hash modificada que permitía múltiples valores (parámetros) para cada clave (nombre).
Esta configuración era ideal para sistemas distribuidos. La proyección en tiempo constante a través de la memoria para el almacenamiento y la recuperación era inherentemente atómica y exclusiva . Las características distribuidas intrínsecas de la memoria celular serían invaluables. El impacto en el usuario , el hardware / dispositivo o las interfaces de programación de aplicaciones era indirecto. Los autores estaban considerando sistemas distribuidos, afirmando:
Queríamos presentar aquí las ideas básicas de un sistema lógico distribuido con... el concepto macroscópico de diseño lógico, más allá 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 corresponden a una máquina en un nivel bajo de la escala evolutiva de las máquinas.
— Chung-Yeol (CY) Lee, Células intercomunicantes: base para una computadora de lógica distribuida
Trabajo fundamental
Abstracción de memoria coherente
Algoritmos para la sincronización escalable en multiprocesadores de memoria compartida [ 21 ]
Abstracción del sistema de archivos
Mediciones de un sistema de archivos distribuido [ 22 ] Coherencia de memoria en sistemas de memoria virtual compartida [ 23 ]
Abstracción de transacciones
Sagas de transacciones [ 24 ]
Memoria transaccional Transacciones de memoria componibles [ 25 ] Memoria transaccional: soporte arquitectónico para estructuras de datos sin bloqueo [ 26 ] Memoria transaccional de software para estructuras de datos de tamaño dinámico [ 27 ] Memoria transaccional de software [ 28 ]
Abstracción de persistencia
OceanStore: una arquitectura para almacenamiento persistente a escala global [ 29 ]
Resumen del coordinador
Votación ponderada para datos replicados [ 30 ] Consenso en presencia de sincronía parcial [ 31 ]
abstracción de confiabilidad
Verificaciones de cordura El problema de los generales bizantinos [ 32 ] Procesadores de parada por fallo: un enfoque para diseñar sistemas informáticos tolerantes a fallos [ 33 ]
Recuperabilidad Instantáneas distribuidas : determinación de estados globales de sistemas distribuidos [ 34 ] Recuperación optimista en sistemas distribuidos [ 35 ]
Modelos de computación distribuida
Tres distribuciones básicas
Para ilustrar mejor este punto, examinemos tres arquitecturas de sistemas : centralizada, descentralizada y distribuida. En este análisis, consideremos tres aspectos estructurales: organización, conectividad y control. La organización describe las características de la disposición física del sistema. La conectividad abarca las vías de comunicación entre los nodos. El control gestiona el funcionamiento de los dos aspectos anteriores.
Organización
Un sistema centralizado tiene una estructura de un solo nivel, donde todos los elementos que lo componen dependen directamente de un único elemento de control. Un sistema descentralizado es jerárquico. El nivel inferior agrupa subconjuntos de las entidades del sistema. Estos subconjuntos se combinan a su vez 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 constituyentes directamente a una entidad maestra central en forma de estrella. 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 una única ruta más corta entre cualquier par de elementos. Finalmente, el sistema operativo distribuido no requiere ningún patrón; son posibles conexiones directas e indirectas entre cualquier par de elementos. Consideremos el fenómeno de la década de 1970 del " arte con hilos " o un dibujo de espirógrafo como un sistema totalmente conectado , y la telaraña o el sistema de autopistas interestatales entre ciudades de EE. UU. como ejemplos de un sistema parcialmente conectado .
Control
Los sistemas centralizados y descentralizados dirigen el flujo de conexiones hacia y desde la entidad central, mientras que los sistemas distribuidos se comunican a través de rutas arbitrarias. Este es el concepto clave de la tercera consideración. El control implica asignar tareas y datos a los elementos del sistema, equilibrando la eficiencia, la capacidad de respuesta y la complejidad.
Los sistemas centralizados y descentralizados ofrecen mayor 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 fallo en todo el sistema. Las asociaciones se ajustan a las necesidades impuestas por su diseño, pero no al caos organizacional.
Consideraciones de diseño
Transparencia
La transparencia o imagen de sistema único se refiere a la capacidad de una aplicación para tratar el sistema en el que opera, independientemente de si es distribuido o no, y sin tener en cuenta el hardware u otros detalles de implementación. Numerosas áreas de un sistema pueden beneficiarse de la transparencia, como el acceso, la ubicación, el rendimiento, la nomenclatura y la migración. La consideración de la transparencia influye directamente en la toma de decisiones en todos los aspectos del diseño de un sistema operativo distribuido. La transparencia puede imponer ciertos requisitos o restricciones a otras consideraciones de diseño.
Los sistemas pueden, opcionalmente, infringir la transparencia en distintos grados para satisfacer requisitos específicos de la aplicación. Por ejemplo, un sistema operativo distribuido puede presentar un disco duro en un ordenador como "C:" y un disco en otro ordenador como "G:". El usuario no necesita conocer los controladores del dispositivo ni la ubicación del disco; ambos dispositivos funcionan de la misma manera, desde la perspectiva de la aplicación. Una interfaz menos transparente podría requerir que la aplicación sepa en qué ordenador se encuentra el disco. Dominios de transparencia:
- Transparencia de ubicación : La transparencia de ubicación comprende dos aspectos distintos de la transparencia: la transparencia de nombres y la movilidad del usuario. La transparencia de nombres exige que ninguna referencia física o lógica a ninguna entidad del sistema revele la ubicación de la entidad ni su relación local o remota con el usuario o la aplicación. La movilidad del usuario exige la referenciación coherente de las entidades del sistema, independientemente de la ubicación del sistema desde la que se origine la referencia. [ 8 ] : 20
- Transparencia de acceso : Las entidades del sistema, tanto locales como remotas, deben permanecer indistinguibles al visualizarlas a través de la interfaz de usuario. El sistema operativo distribuido mantiene esta percepción mediante la exposición de un único mecanismo de acceso para una entidad del sistema, independientemente de si dicha entidad es local o remota para el usuario. La transparencia exige que cualquier diferencia en los métodos de acceso a una entidad del sistema en particular —ya sea local o remota— sea invisible e indetectable para el usuario. [ 3 ] : 84
- Transparencia en la migración : Los recursos y las actividades migran de un elemento a otro controlados exclusivamente por el sistema y sin conocimiento ni acción del usuario/aplicación. [ 36 ] : 16
- Transparencia de replicación : El proceso o hecho de que un recurso se haya duplicado en otro elemento ocurre bajo el control del sistema y sin conocimiento ni intervención del usuario/aplicación. [ 36 ] : 16
- Transparencia de concurrencia : los usuarios/aplicaciones desconocen la presencia/actividades de otros usuarios y no se ven afectados por ellas. [ 36 ] : 16
- Transparencia ante fallos : El sistema es responsable de la detección y corrección de fallos del sistema. No se requiere ningún conocimiento ni acción por parte del usuario, salvo esperar a que el sistema resuelva el problema. [ 9 ] : 30
- Transparencia del rendimiento : El sistema es responsable de la detección y corrección de deficiencias de rendimiento locales o globales. Tenga en cuenta que las políticas del sistema pueden dar preferencia a algunos usuarios/clases de usuarios/tareas sobre otros. No se requiere conocimiento ni interacción del usuario. [ 8 ] : 23
- Transparencia de tamaño/escala : el sistema es responsable de gestionar su alcance geográfico, número de nodos y nivel de capacidad de los nodos sin necesidad de conocimientos o interacción por parte del usuario. [ 8 ] : 23
- Transparencia de revisiones : El sistema es responsable de las actualizaciones, revisiones y cambios en la infraestructura del sistema sin conocimiento ni acción del usuario. [ 9 ] : 30
- Transparencia de control : El sistema es responsable de proporcionar toda la información del sistema, constantes, propiedades, configuraciones, etc., con una apariencia, connotación y denotación consistentes para todos los usuarios y aplicaciones. [ 3 ] : 84
- Transparencia de datos : El sistema es responsable de proporcionar datos a las aplicaciones sin que el usuario tenga conocimiento ni realice ninguna acción relacionada con dónde los almacena el sistema. [ 3 ] : 85
- Transparencia del paralelismo : El sistema es responsable de aprovechar cualquier capacidad para paralelizar la ejecución de tareas sin conocimiento ni interacción del usuario. Posiblemente el aspecto más difícil de la transparencia, 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 entre procesos y el flujo de datos entre hilos y/o procesos , tanto dentro de un nodo como entre nodos en un sistema operativo distribuido. Los requisitos de comunicación intranodo e internodo determinan el diseño de bajo nivel de la IPC, que es el enfoque típico para implementar funciones de comunicación que admiten transparencia. En este sentido, la comunicación entre procesos es el concepto fundamental en las consideraciones de diseño de bajo nivel de un sistema operativo distribuido.
Gestión de procesos
La gestión de procesos proporciona políticas y mecanismos para compartir recursos de forma eficaz y eficiente entre procesos distribuidos. Estas políticas y mecanismos permiten la asignación y desasignación de procesos y puertos a los procesadores, así como la ejecución, suspensión, migración, detención o reanudació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.
Como ejemplo, el balanceo de carga es una función común de gestión de procesos. El balanceo de carga supervisa el rendimiento de los nodos y se encarga de redistribuir la actividad entre ellos cuando el sistema está desequilibrado. Una función del balanceo de carga es seleccionar 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 en función de una política como "solicitud más reciente". El sistema implementa la política.
Gestión de recursos
Los recursos del sistema, como la memoria, los archivos y los dispositivos, se distribuyen por todo el sistema, y en cualquier momento dado, cualquiera de estos nodos puede tener cargas de trabajo bajas o nulas. El reparto y el balanceo de carga requieren numerosas decisiones basadas en políticas, que van desde la identificación de CPU inactivas hasta el momento y el tipo de CPU a trasladar. Existen muchos algoritmos para facilitar estas decisiones; sin embargo, esto exige un segundo nivel de política de toma de decisiones para elegir el algoritmo más adecuado para el escenario y sus condiciones.
Fiabilidad
Los sistemas operativos distribuidos pueden proporcionar los recursos y servicios necesarios para lograr altos niveles de fiabilidad , es decir, la capacidad de prevenir y/o recuperarse de errores. Las fallas son defectos físicos o lógicos que pueden provocar errores en el sistema. Para que un sistema sea fiable, debe superar de alguna manera los efectos adversos de las fallas.
Los métodos principales para gestionar fallos incluyen la prevención de fallos , la tolerancia a fallos y la detección y recuperación de fallos. La prevención de fallos abarca las medidas proactivas que se toman para minimizar su aparición. Estas medidas proactivas pueden consistir en transacciones , replicación y copias de seguridad . La tolerancia a fallos es la capacidad de un sistema para seguir funcionando en presencia de un fallo. En tal caso, el sistema debe detectarlo y recuperar su funcionalidad completa. En cualquier caso, las acciones que se tomen deben hacer todo lo posible por preservar la imagen única del sistema .
Disponibilidad
La disponibilidad es la fracción de tiempo durante la cual el sistema puede responder a las solicitudes.
Actuación
Numerosas métricas de referencia cuantifican el rendimiento : rendimiento de procesamiento, tiempo de respuesta, finalización de tareas por unidad de tiempo, utilización del sistema, etc. En un sistema operativo distribuido, el rendimiento suele depender del equilibrio entre el paralelismo de procesos y la comunicación entre procesos (IPC). Gestionar la granularidad de las tareas de paralelismo en función de los mensajes necesarios para el soporte resulta extremadamente eficaz. Asimismo, identificar cuándo es más beneficioso migrar un proceso a sus datos, en lugar de copiarlos, también es eficaz.
Sincronización
Los procesos concurrentes que cooperan entre sí tienen una necesidad inherente de sincronización , que garantiza que los cambios se produzcan de forma correcta y predecible. Tres situaciones básicas definen el alcance de esta necesidad:
- uno o más procesos deben sincronizarse en un punto determinado para que uno o más procesos puedan continuar.
- Uno o más procesos deben esperar una condición asíncrona para poder continuar.
- o un proceso debe establecer el acceso exclusivo a un recurso compartido.
Una sincronización inadecuada puede provocar múltiples modos de fallo, entre ellos la pérdida de atomicidad, consistencia, aislamiento y durabilidad , interbloqueo , bloqueo permanente y pérdida de serializabilidad .
Flexibilidad
La flexibilidad en un sistema operativo distribuido se ve mejorada por las características modulares del sistema operativo distribuido y por la provisión de un conjunto más amplio de servicios de alto nivel. La integridad y calidad del núcleo/micronúcleo simplifican la implementación de dichos servicios y, potencialmente, permiten a los proveedores de servicios una mayor variedad de proveedores para estos servicios.
Investigación
Modelo replicado extendido a un modelo de objeto de 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 asumida
- Escala y rendimiento en el núcleo de aislamiento de Denali. [ 41 ]
Sistemas enfocados en múltiples núcleos/núcleos múltiples
Procesamiento distribuido en entornos de heterogeneidad extrema.
- Helios: multiprocesamiento heterogéneo con núcleos satélite. [ 45 ]
Eficaz y estable en múltiples niveles de complejidad.
- Teselación: Particionamiento espacio-temporal en un sistema operativo cliente multinúcleo. [ 46 ]
Computación con sistemas operativos dispersos
La computación de sistema operativo disperso (DOSC) es un paradigma de computación que implementa software de aplicación a través de "objetos de aplicación" que tienen funcionalidad de sistema operativo integrada. Ejemplos de implementaciones incluyen servidores web, [ 47 ] VoIP, [ 48 ] y sistemas de archivos . [ 49 ]
Véase también
- Computación distribuida : sistema con múltiples computadoras en red.
- HarmonyOS – Sistema operativo distribuido de Huawei
- OpenHarmony : Familia de sistemas operativos distribuidos de código abierto.
- Núcleo HongMeng : núcleo de sistema operativo distribuido
- BlueOS – Sistema operativo distribuido desarrollado por Vivo
- Plan 9 de Bell Labs : sistema operativo distribuido para investigación.
- Inferno – Sistema operativo distribuido
- MINIX – Sistema operativo tipo Unix. Páginas que muestran breves descripciones de destinos de redirección.
- Imagen de sistema única : sistema operativo dedicado al clúster (SSI)
- Arquitectura de sistemas informáticos : conjunto de reglas que describen el sistema informático. Páginas que muestran breves descripciones de destinos de redireccionamiento.
- Multikernel : tipo de kernel del sistema operativo
- Proyectos de sistemas operativos : enseñanza de sistemas operativos
- Premio Edsger W. Dijkstra en Computación Distribuida – Conferencia anual sobre computación. Páginas que muestran breves descripciones de los destinos de redireccionamiento.
- Lista de conferencias sobre computación distribuida
- Lista de proyectos informáticos para voluntarios
Referencias
- 1 2 Tanenbaum, Andrew S (septiembre de 1993). "Sistemas operativos distribuidos año 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.
- 1 2 3 4 5 6 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 . Intertext Publications. ISBN 9780070216211.
- ↑ Hansen, Per Brinch, ed. (2001). Sistemas operativos clásicos: del procesamiento por lotes a los sistemas distribuidos . Springer. 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. Comput. Commun. 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 sobre Sistemas, Lenguajes y Aplicaciones de Programación Orientada a Objetos (Ottawa, Canadá). OOPSLA/ECOOP '90. ACM, Nueva York, NY, 269-275.
- 1 2 3 4 5 Sinha, Pradeep Kumar (1997). Sistemas operativos distribuidos: conceptos y diseño . IEEE Press. ISBN 978-0-7803-1119-0.
- 1 2 3 Chow, Randy; Theodore Johnson (1997). Sistemas operativos y algoritmos distribuidos . Addison Wesley. ISBN 978-0-201-49838-7.
- ↑ Surajbali, B., Coulson, G., Greenwood, P., y Grace, P. 2007. Ampliación del middleware reflexivo con una capa de soporte de orientación de aspecto. En Actas del 6.º Taller internacional sobre middleware adaptativo y reflexivo: celebrado en la Conferencia internacional de middleware ACM/IFIP/USENIX (Newport Beach, CA, 26-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". Journal of the ACM . 1 (2): 57– 81. doi : 10.1145/320772.320773 . S2CID 15381094 .
- 1 2 Forgie, James W. (26-28 de febrero de 1957). El sistema de entrada/salida Lincoln TX-2 . Conferencia Conjunta Occidental de Computación: Técnicas para la Fiabilidad. Los Ángeles, California: Association for Computing Machinery. págs. 156-160 . doi : 10.1145/1455567.1455594 . ISBN 9781450378611.
{{cite conference}}: Incompatibilidad de ISBN/Fecha ( ayuda ) - 1 2 C. Y. Lee (4–6 de diciembre de 1962). Celdas intercomunicantes, base para una computadora de lógica distribuida . Conferencia conjunta de computación de otoño. Filadelfia, Pensilvania: Association for Computing Machinery. págs. 130–136 . doi : 10.1145/1461518.1461531 .
- ↑ Dreyfus, Phillippe (1958-05-08) [1958-05-06], escrito en Los Ángeles, "Diseño del sistema Gamma 60" (PDF) , Actas de la Conferencia Conjunta de Computación del Oeste del 6 al 8 de mayo de 1958 : Contrastes en Computadoras , ACM, Nueva York, NY, EE. UU., págs. 130–133 , IRE-ACM-AIEE '58 (Occidental), archivado (PDF) del original el 3 de abril de 2017 , recuperado el 3 de abril de 2017
- ↑ Leiner, AL, Notz, WA, Smith, JL y Weinberger, A. 1958. Organización de una red de computadoras para cumplir con los plazos de entrega. En Artículos y debates presentados en la Conferencia Conjunta de Computación del Este del 9 al 13 de diciembre de 1957: Computadoras con plazos de entrega que cumplir (Washington, DC, 9-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 Conjunta de Computación del Este del 3 al 5 de diciembre de 1958: Computadoras modernas: objetivos, diseños, aplicaciones (Filadelfia, Pensilvania, 3-5 de diciembre de 1958). AIEE-ACM-IRE '58 (Este). ACM, Nueva York, NY, 71-75.
- ↑ Bauer, WF 1958. Diseño de computadoras desde la perspectiva del programador. En Artículos y debates presentados en la Conferencia Conjunta de Computación del Este del 3 al 5 de diciembre de 1958: Computadoras modernas: objetivos, diseños, aplicaciones (Filadelfia, Pensilvania, 3-5 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 Conjunta de Informática IRE-AIEE-ACM del Oeste, del 3 al 5 de mayo de 1960 (San Francisco, California, 3-5 de mayo de 1960). IRE-AIEE-ACM '60 (Oeste). ACM, Nueva York, NY, 33-40.
- ↑ Martin H. Weik, "Un tercer estudio sobre sistemas informáticos digitales electrónicos nacionales", Informe n.° 1115 de los Laboratorios de Investigación Balística, págs. 234-235, Campo de Pruebas de Aberdeen, Maryland, marzo de 1961.
- ↑ Mellor-Crummey, JM y Scott, ML 1991. Algoritmos para sincronización escalable en multiprocesadores de memoria compartida . ACM Trans. Comput. Syst. 9, 1 (febrero de 1991), 21-65.
- ↑ Baker, MG, Hartman, JH, Kupfer, MD, Shirriff, KW y Ousterhout, JK 1991. Mediciones de un sistema de archivos distribuido . En Actas del Decimotercer Simposio ACM sobre Principios de Sistemas Operativos (Pacific Grove, California, Estados Unidos, 13-16 de octubre de 1991). SOSP '91. ACM, Nueva York, NY, 198-212.
- ↑ Li, K. y Hudak, P. 1989. Coherencia de memoria en sistemas de memoria virtual compartida. ACM Trans. Comput. Syst. 7, 4 (noviembre de 1989), 321-359.
- ↑ Garcia-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-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 Actas del 20.º Simposio Internacional Anual sobre Arquitectura de Computadoras (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. Memoria transaccional de software 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-16 de julio de 2003). PODC '03. ACM, Nueva York, NY, 92-101.
- ↑ Shavit, N. y Touitou, D. 1995. Memoria transaccional de software . En Actas del decimocuarto simposio anual de la ACM sobre principios de computación distribuida (Ottawa, Ontario, Canadá, 20-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 ACM sobre Principios de Sistemas Operativos (Pacific Grove, California, Estados Unidos, 10-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. Program. Lang. Syst. 4, 3 (julio de 1982), 382-401.
- ↑ Schlichting, RD y Schneider, FB 1983. Procesadores de parada por fallo: un enfoque para el diseño de sistemas informáticos tolerantes a fallos. ACM Trans. Comput. Syst. 1, 3 (agosto de 1983), 222-238.
- ↑ Chandy, KM y Lamport, L. 1985. Instantáneas distribuidas: determinación de estados globales de sistemas distribuidos. ACM Trans. Comput. Syst. 3, 1 (febrero de 1985), 63-75.
- ↑ Strom, R. y Yemini, S. 1985. Recuperación optimista en sistemas distribuidos. ACM Trans. Comput. Syst. 3, 3
- 1 2 3 Galli, Doreen L. (2000). Sistemas operativos distribuidos: conceptos y práctica . Prentice Hall. ISBN 978-0-13-079843-5.
- ↑ 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 de Investigación de Sistemas y Tecnologías de la Información, octubre de 2004, Kiev, Ucrania.
- ↑ Vinter, ST y Schantz, RE 1986. El sistema operativo distribuido Cronus. En Actas del 2.º Taller sobre la Implementación de Sistemas Distribuidos (Ámsterdam, Países Bajos, 8-10 de septiembre de 1986). EW 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 de Ciencias de la Computación de la ACM de 1988 (Atlanta, Georgia, Estados Unidos). CSC '88. ACM, Nueva York, NY, 685.
- ↑ Whitaker, A., Shaw, M. y Gribble, SD 2002. En Actas del 5.º 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 Actas del 22.º Simposio ACM SIGOPS sobre Principios de Sistemas Operativos (Big Sky, Montana, EE. UU., 11-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 5º seminario nacional de la RDA SoC-SIP, Lyon, Francia, 2011.
- ↑ Nightingale, EB, Hodson, O., McIlroy, R., Hawblitzel, C., y Hunt, G. 2009. En Actas del 22.º Simposio ACM SIGOPS sobre Principios de Sistemas Operativos (Big Sky, Montana, EE. UU., 11-14 de octubre de 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.
- ↑ Él, Computación de sistemas operativos dispersos Karne, RK, Wijesinha, AL y Emdadi, A. Diseño y rendimiento de un servidor web para PC básico, Revista internacional de computadoras y sus aplicaciones (IJCA), junio de 2008.
- ↑ GH Khaksari, AL Wijesinha, RK Karne, L. He y S. Girumala, “Una aplicación VoIP peer-to-peer para PC sin hardware”, 4.ª Conferencia IEEE sobre Comunicaciones y Redes para el Consumidor (CCNC), 2007, págs. 803-807.
- ↑ WV Thompson, H. Alabsi, RK Karne, S. Linag, AL Wijesinha, R. Almajed y H. Chang, Un sistema de almacenamiento masivo para aplicaciones de PC sin sistema operativo mediante USB, International Journal on Advances in Internet Technology, vol. 9, n.º 3 y 4, año 2016, págs. 63-74.
Lecturas adicionales
- Chow, Randy; Theodore Johnson (1997). Sistemas operativos y algoritmos distribuidos . Addison Wesley. ISBN 978-0-201-49838-7.
- Sinha, Pradeep Kumar (1997). Sistemas operativos distribuidos: conceptos y diseño . IEEE Press. ISBN 978-0-7803-1119-0.
- Galli, Doreen L. (2000). Sistemas operativos distribuidos: conceptos y práctica . Prentice Hall. ISBN 978-0-13-079843-5.
Enlaces externos
- Redes informáticas
- Sistemas operativos distribuidos
- Historia del software
- Sistemas operativos