apunte

1. 1
Sistema operativo distribuido
Un sistema operativo distribuido es la unión lógica de un grupo de sistemas operativos sobre una
colección de nodos computacionales independientes,conectados en red, comunicándose y físicamente
separados. 1
Cada nodo contiene de forma individual un subconjunto específico de los programas que
componen el sistema operativo distribuido. Cada subconjunto es una combinación de dos proveedores
de serviciosdistintos.2
El primeroesun núcleoubicuomínimoo micro núcleo,que controlael hardware
del nodo. El segundo es una colección de componente de administración del sistema de alto nivel que
coordinanlas actividadesindividualesycolaborativasdel nodo.Estos componentessonunaabstracción
de las funciones del micro núcleo y dan soporte a las aplicaciones de usuario.3
El micronúcleoylascomponentesde administracióntrabajanenconjunto.Ambosdansoporteal objetivo
del sistemael cual esintegrarmúltiplesrecursosycapacidadde procesamientoenunsistemaeficientey
estable.4
Esta integración sin fisuras de nodos individuales en un sistema global es conocido como
transparencia,osistemade imagenúnica;haciendoreferenciasalailusiónque se le brindaalosusuarios
de que el sistema global luce como una entidad computacional única.
Un sistema operativo distribuido provee las funcionalidades esenciales requeridas por un sistema
distribuido, agregando atributos y configuraciones para dar soporte a los requerimientos adicionales,
tales como aumento de escala y disponibilidad. Desde el punto de vista del usuario el SO funciona de
formasimilaraun SistemaOperativomonolíticode unsolonodo.Oseaque,aunque estácompuestopor
múltiples nodos, para los usuarios y aplicaciones luce como un solo nodo.
Separando las funcionalidades mínimas a nivel de sistema de los servicios modularesadicionales a nivel
de usuario provee “una separación de mecanismos y políticas”. Mecanismos y políticas pueden ser
interpretadosdelasiguientemanera“cómoalgose hace”contra“porqué algosehace”respectivamente.
Esta separación incrementa la escalabilidad y la flexibilidad.
Descripción General
El núcleo
En cada unidad(típicamenteunnodo),el núcleoproveeunconjuntomínimoperocompletode utilidades
necesarias para operar con los recurso y hardware subyacentes del nodo. Estos mecanismos incluyen la
asignación,manejoydisposiciónde losrecursosdeunnodo,losprocesos,lacomunicaciónylasfunciones
de administración la entrada/salida.5
Dentro del núcleo el subsistema de comunicación es de suma
importancia para el sistema distribuido.[3]
En un sistemadistribuidoel núcleocomúnmente soportaunconjuntomínimode funcionesque incluyen
administración de direcciones de bajo nivel, administraciónde hilos y comunicación entre procesos. Un
1 Tanenbaum, Andrew S (Septermber 1993). "Distributed operatingsystems anno 1992. What have we learned so
far?". pp. 3-10. doi:10.1088/0967-1846/1/1/001.
2 Nutt, Gary J. (1992). Centralized and Distributed OperatingSystems. Prentice Hall.ISBN 978-0-13-122326-4.
3 Gościński,Andrzej (1991).Distributed OperatingSystems: The Logical Design.Addison-Wesley Pub. Co.. ISBN
978-0-201-41704-3.
4 Fortier, Paul J. (1986). Design of Distributed OperatingSystems: Concepts and Technolog. Intertext Publications.
5 Hansen, Per Brinch,ed. (2001). ClassicOperatingSystems: From Batch Processingto Distributed Systems.
Springer. ISBN 978-0-387-95113-3.

2. 2
núcleocon este diseñose conoce como micro-núcleo. 67
Su naturalezamodularmejorala seguridady la
fiabilidad,característicasfundamentalesparaun sistemadistribuido.8
Escomún que todos losnodosen
un sistematenganréplicasde unmismonúcleoyportanto que todos losnodosusenhardware similar. 9
La combinación de diseño minimalista y cobertura ubicua de los nodos mejora la extensibilidad del
sistema global así como su habilidad de agregar nuevos nodos o servicios de manera dinámica. 10
Componentes de administración del sistema
Las componentes de administración del sistema son procesos de software que definen las políticas
del nodo. Estas componentes son la parte del SO fuera del núcleo. Proveen comunicación de alto
nivel, administración de procesos y recursos, confiabilidad, rendimiento y seguridad. Estas
componentes tienen las mismas funcionalidades de un sistema formado por una sola entidad,
adicionando la transparencia requerida en un sistema operativo distribuido. 11
La naturaleza distribuida del sistema distribuido requiere servicios adicionales para soportar las
responsabilidades del nodo en el sistema global. Además las componentes de administración del
sistema aceptan las responsabilidades “defensivas” de confiabilidad, disponibilidad y persistencia.
Estas responsabilidades pueden entrar en conflicto una con otra. La separación de políticas y
mecanismos pueden mitigar dichos conflictos. 12
Trabajando juntos como un sistema operativo
La arquitecturaydiseñode unsistemaoperativodistribuidodebencomprendertantolasmetasdel nodo
individual, como las del sistema. El diseño y la arquitectura deben ser concebidos de forma que se
mantengan separados las políticas y los mecanismos. De este modo, un sistema operativo distribuido
intenta proporcionar un marco de computación distribuida eficiente y fiable que permita a los usuarios
tener en cuenta lo menos posible los esfuerzos necesariossubyacentes para logarlo. 13
La colaboración
multi-nivelentre el núcleoyloscomponentesdel sistemade gestión,ya su vezentre losdistintosnodos
enun sistemaoperativodistribuidoesel desafíofuncional del mismo.Este esel puntoenel sistemaque
debe mantener una perfecta armonía de propósito, y al mismo tiempo mantener una desconexión
completa de la intención de la implementación. Este desafío es la oportunidad del sistema operativo
distribuido para producir la base y el marco para un sistema fiable, eficiente, disponible, robusto,
extensible y escalable. Sin embargo, esta posibilidad tiene un coste muy alto en complejidad.
El precio de la complejidad
En un sistema operativo distribuido, el excepcional grado de complejidad inherente fácilmente podría
hacer de todo el sistema una maldiciónpara cualquier usuario. Como tal, el precio lógico de realización
6 UsingLOTOS for specifyingthe CHORUS distributed operatingsystem kernel Pecheur, C. 1992. Using LOTOS for
specifyingthe CHORUS distributed operating system kernel. Comput. Commun. 15, 2 (Mar. 1992), 93-102.
7 COOL: kernel supportfor object-oriented environments Habert, S. and Mosseri,L. 1990.COOL: kernel supportfor
object-oriented environments. In Proceedings of the European Conference on Object-Oriented Programming on
Object-Oriented Programming Systems, Languages, and Applications (Ottawa,Canada).OOPSLA/ECOOP '90. ACM,
New York, NY, 269-275.
8 Sinha,Pradeep Kumar (1997).Distributed Operating Systems: Concepts and Design. IEEE Press.ISBN 978-0-7803-
1119-0.
9 Galli,Doreen L. (2000).Distributed OperatingSystems: Concepts and Practice.Prentice Hall.ISBN978-0-13-
079843-5.
10 Chow, Randy; Theodore Johnson (1997). Distributed Operating Systems and Algorithms.Addison Wesley.ISBN
978-0-201-49838-7.
11 Gościński,Andrzej (1991).Distributed OperatingSystems: The Logical Design.Addison-Wesley Pub. Co.. ISBN
978-0-201-41704-3.
12 Chow, Randy; Theodore Johnson (1997). Distributed OperatingSystems and Algorithms.Addison Wesley.ISBN
978-0-201-49838-7.
13 Sinha,Pradeep Kumar (1997).Distributed Operating Systems: Concepts and Design. IEEE Press.ISBN 978-0-7803-
1119-0.

3. 3
de un sistema de operación distribuida se debe calcular en términos de superar grandes cantidades de
complejidaden muchas áreas, y en muchos niveles. Este cálculoincluye la profundidad,la amplitud y el
alcance de la inversión en diseño arquitectónico y la planificación necesaria para lograr incluso la
aplicaciónmásmodesta. Estasconsideracionesde diseñoydesarrollosonfundamentalese implacables.
Por ejemplo,unacomprensiónprofundadel diseñoydetallesde laarquitecturade unsistemaoperativo
distribuidoes fundamental desde el inicio. Una cantidad agotadora de consideracionesde diseño son
inherentesal desarrollode unsistemaoperativodistribuido.Cadaunade estasconsideracionesde diseño
puede afectarpotencialmenteamuchasde lasotrasenungradosignificativo.Estoconduce aunesfuerzo
masivo en lograr un enfoque equilibrado, en términos de las consideraciones de diseño individuales, y
muchos de sus permutaciones. Como apoyo para esta tarea, la mayoría se basan en la experiencia
documentada y la investigación en computación distribuida.
Historia
Los esfuerzos de investigación y experimentación comenzaron en la década de 1970 y continuó hasta
1990, con un picoenel interésmostradoenel temaafinalesde 1980. Un númerode sistemasoperativos
distribuidos fueron introducidos durante este período, sin embargo, muy pocas de estas
implementacioneslograron un éxitocomercial ni siquieramodesto.Implementacionesfundamentalesy
pioneras de los conceptos primitivos de las componentes de sistemas operativos distribuidos datan de
principios de 1950.14 15 16 17
Algunos de estos pasos individuales no se centraron directamente en la
computación distribuida,y en ese momento, muchos no notaron la importancia de su impacto. Estos
esfuerzospionerosestablecieronbasesimportantes,e inspiraronlainvestigaciónentemasrelacionados
14Surajbali,B.,Coulson,G., Greenwood, P., and Grace, P. 2007.Augmenting reflective middleware with an aspect
orientation supportlayer.In Proceedings of the 6th international Workshop on Adaptive and Reflective
Middleware: Held At the ACM/IFIP/USENIX international MiddlewareConference (Newport Beach, CA, November
26–30, 2007). ARM '07. ACM, New York, NY, 1-6.
15 Leiner, A. L. 1954.System Specificationsfor the DYSEAC. J. ACM 1, 2 (Apr. 1954), 57-81.
16 Forgie, J. W. 1957.The Lincoln TX-2 input-output system. In Papers Presented At the February 26–28, 1957,
Western JointComputer Conference: Techniques For Reliability (Los Angeles, California,February 26–28,1957).
IRE-AIEE-ACM '57 (Western). ACM, New York, NY, 156-160.
17 Lee, C. Y. 1962.Intercommunicatingcells,basisfor a distributed logic computer.In Proceedings of the
December 4–6, 1962,Fall JointComputer Conference (Philadelphia,Pennsylvania,December 04–06, 1962).AFIPS
'62 (Fall).

4. 4
con lacomputacióndistribuida.18 19 20 21 22 23
En ladécada de 1970, se produjeronimportantesavancesen
la computación distribuida. Estos descubrimientos proporcionaron una base sólida y estable para los
esfuerzos que continuaron durante la década de 1990. La proliferación acelerada de sistemas
multiprocesador y de procesadoresmultinúcleos dio paso al resurgir del concepto de sistema operativo
distribuido.
1950
El DYSEAC
Uno de los primeros esfuerzosfue el DYSEAC, un ordenador sincrónico de propósitogeneral. En una de
las primeraspublicacionesde laAssociationforComputingMachinery,enabril de 1954, un investigador
de la OficinaNacional de Normalización - ahora el InstitutoNacional de Estándaresy Tecnología(NIST) -
presentó una especificación detallada de la DYSEAC. La introducción se centró en los requisitos de las
aplicacionesprevistas,incluidaslascomunicacionesflexibles,pero también mencionaba otros equipos:
Finalmente, losdispositivosexternospodríanincluso incluirotros ordenadoresagranescalaque emplean
el mismolenguajedigitalcomolaDYSEAC.Porejemplo,lascomputadorasSEACuotrassimilaresaellase
podrían conectar a la DYSEAC y mediante el uso de programas coordinados podrían trabajar juntas en
cooperaciónmutuaen una tarea común...En consecuencia[,] el equipose puede utilizarparacoordinar
las diversasactividadesde todoslosdispositivosexternosenunaoperaciónde conjuntoeficaz. -ALAN L.
LEINER, las especificaciones del sistema para el DYSEAC
La especificación discutió la arquitectura de sistemas multicomputadoras, prefiriendo peer-to-peer en
lugar de amo-esclavo.
Cada miembrode este grupointerconectadode computadorasseparadaseslibre encualquiermomento
para iniciar y despachar los pedidos especiales de control para cualquiera de sus compañeros en el
sistema. Como consecuencia, el control sobre la tarea común inicialmente puede ser libremente
distribuidoentodoel sistemay, despuéstemporalmente concentradaenun ordenador,o inclusopasar
rápidamente de unamáquinaalaotracuando surjalanecesidad...Hayque señalarque relacionesque se
han descritose basan en la cooperaciónmutua entre el ordenadorlos dispositivosexternosal mismo,y
no reflejan meramente un simple esquema maestro-esclavo. -ALAN L. LEINER, las especificaciones del
sistema para el DYSEAC
18 Dreyfuss,P. 1958.System design of the Gamma 60. In Proceedings of the May 6–8, 1958, Western Joint
Computer Conference: Contrasts in Computers (Los Angeles, California,May 06–08,1958).IRE-ACM-AIEE '58
(Western). ACM, New York, NY, 130-133.
19 Leiner, A. L., Notz, W. A., Smith, J. L., and Weinberger, A. 1958.Organizinga network of computers to meet
deadlines.In Papers and DiscussionsPresented At the December 9–13, 1957,Eastern Joint Computer Conference:
Computers with Deadlines To Meet (Washington,D.C., December 09–13, 1957). IRE-ACM-AIEE '57
20 Leiner, A. L., Smith, J. L., Notz, W. A., and Weinberger, A. 1958.PILOT, the NBS multicomputer system. In Papers
and DiscussionsPresented At the December 3–5, 1958, Eastern Joint Computer Conference: Modern Computers:
Objectives,Designs,Applications (Philadelphia,Pennsylvania,December 03–05, 1958).AIEE-ACM-IRE '58 (Eastern).
ACM, New York, NY, 71-75.
21 Bauer, W. F. 1958.Computer design from the programmer's viewpoint. In Papers and DiscussionsPresented At
the December 3–5, 1958,Eastern Joint Computer Conference: Modern Computers: Objectives,Designs,
Applications (Philadelphia,Pennsylvania,December 03–05, 1958).AIEE-ACM-IRE '58 (Eastern). ACM, New York, NY,
46-51.
22 Leiner, A. L., Notz, W. A., Smith, J. L., and Weinberger, A. 1959.PILOT—A New MultipleComputer System. J.
ACM 6, 3 (Jul. 1959),313-335.
23 Estrin,G. 1960. Organization of computer systems: the fixed plus variablestructurecomputer. In Papers
Presented At the May 3–5, 1960,Western Joint IRE-AIEE-ACM Computer Conference (San Francisco,California,
May 03–05, 1960).IRE-AIEE-ACM '60 (Western). ACM, New York, NY, 33-40.

5. 5
Este esunode losprimerosejemplosde unequipoconcontroldistribuido.LosreportesdelDepartamento
del Ejército 24
certificaron su confiabilidad y que pasó todas las pruebas de aceptación en abril de 1954.
Esto eraun "ordenadorportátil",ubicadoenuntractorcon remolque,con2 vehículosacompañantesy6
toneladas de capacidad de refrigeración.
Lincoln TX-2000
Descrito como un sistema experimental de entrada salida, el Lincoln TX-2 hizo hincapié en dispositivos
simultáneosde operacionesde entradasalidaflexibles,esdecir,multiprogramación.El diseñode laTX-2
era modular, soportando un alto grado de modificación y expansión. 25
El sistema empleó la técnica de
programa de secuencia múltiple. Esta técnica permitió múltiples contadores de programa para cada
asociado con una de 32 posibles secuencias de código de programa. Estas secuencias explícitamente
priorizadaspodríanserintercaladasyejecutasal mismotiempo,afectando nosóloel cálculoenproceso,
sinotambiénel flujode control de lassecuenciasylaconmutaciónde dispositivos.Al igualque laDYSEAC
los dispositivos TX-2 programados por separados pueden funcionar simultáneamente, aumentandoel
rendimiento. Todo el poder de la unidad central estaba disponible para cualquier dispositivo. El TX-2 es
otro ejemplode unsistemade control distribuidoenel cual suunidadcentral notiene control dedicado.
Celdas intercomunicadas
Un primeresfuerzoenlograruna abstracciónal acceso de memoriafueronlascélulasintercomunicadas,
donde una célula estaba compuesta de un conjunto de elementos de memoria. Un elemento de la
memoria era básicamente un relé. Dentro de una célula había dos tipos de elementos, símbolo y celda.
Cada estructura de celdaalmacenabalosdatos en una cadena de símbolos,que consistía en un nombre
y un conjunto de parámetros. La información estaba vinculada a través de asociaciones de celdas. 26
Las celdas intercomunicadas fundamentalmente rompieroncon la tradición en que no tenía contadores
o cualquierotroconceptode direccionamientode memoria.Lainformacióneraaccedidade dosmaneras
diferentes, directa y recuperación cruzada.
La memoria celular tendría muchas ventajas:
• Una parte importante de la lógica del sistema está distribuida dentro de las asociaciones de la
información almacenada en las celdas.
• El flujo de asociación en la información es guiado de alguna forma por almacenamiento y la
recuperación.
• El tiempo requerido para el almacenamiento y recuperación es mayormente constante y
completamente no relacionada con el tamaño y el factor de relleno de la memoria
• Las células son lógicamente indistinguibles, lo que los hace de uso flexible y relativamente simple
extender su tamaño.
24 Martin H. Weik, "A Third Survey of Domestic Electronic Digital ComputingSystems," Ballistic Research
Laboratories Report No. 1115, pg. 234-5, Aberdeen ProvingGround, Maryland,March 1961
25 Forgie, J. W. 1957.The Lincoln TX-2 input-output system. In Papers Presented At the February 26–28, 1957,
Western JointComputer Conference: Techniques For Reliability (Los Angeles, California,February 26–28,1957).
IRE-AIEE-ACM '57 (Western). ACM, New York, NY, 156-160.
26 Lee, C. Y. 1962.Intercommunicatingcells,basisfor a distributed logic computer.In Proceedings of the December
4–6, 1962,Fall JointComputer Conference (Philadelphia,Pennsylvania,December 04–06, 1962).AFIPS '62 (Fall).

6. 6
Esta configuración es ideal para sistemas distribuidos. La proyección de tiempo constante para el
almacenamiento y la recuperación era inherentemente atómico y exclusivo. Los autores estaban
considerando los sistemas distribuidos, declarando:
Hemos querido presentar aquí las ideas básicas de un sistema de lógica distribuida con... el concepto
macroscópico de diseño lógico, lejos del análisis, de búsqueda, de direccionamiento y de contar, es
igualmente importante. Debemos, a toda costa, liberarnos de las cargas de los detalles y los problemas
locales que sólo beneficia a un equipo bajo en la escala evolutiva de las máquinas. —Chung-Yeol (C. Y.)
Lee, Intercommunicating Cells, Basis for a Distributed Logic Computer
Trabajo fundacional
Abstracción de memoria coherente
Algoritmos para la sincronización escalable en multiprocesadores de memoria compartida27
Abstracción del sistema de archivos
Las mediciones de un sistema de archivos distribuido 28
Memoria coherente en los sistemas compartidos de memoria virtual 29
Abstracción de transacciones
Transacciones Sagas 30
Memoria Transaccional Operaciones componibles memoria 31
Memoria transaccional: el apoyo arquitectónico para el bloqueo libre de estructuras de datos 32
Memoria de software transaccional para estructuras de datos de tamaño dinámico 33
Memoria de software transaccional 34
27 Mellor-Crummey, J. M. and Scott, M. L. 1991.Algorithms for scalablesynchronization on shared-memory
multiprocessors.ACMTrans.Comput. Syst. 9, 1 (Feb. 1991), 21-65.
28 Baker, M. G., Hartman, J. H., Kupfer, M. D., Shirriff,K.W., and Ousterhout, J. K. 1991.Measurements of a
distributed filesystem. In Proceedings of the Thirteenth ACM Symposiumon Operating Systems Principles(Pacific
Grove, California,United States, October 13–16, 1991). SOSP '91. ACM, New York, NY, 198-212.
29 Li, K. and Hudak, P. 1989. Memory coherence in shared virtual memory systems. ACM Trans. Comput. Syst. 7, 4
(Nov. 1989), 321-359.
30 Garcia-Molina,H.and Salem, K. 1987.Sagas.In Proceedings of the 1987 ACM SIGMOD international Conference
on Management of Data (San Francisco,California,United States, May 27–29, 1987).U. Dayal,Ed. SIGMOD '87.
ACM, New York, NY, 249-259.
31 Harris,T., Marlow,S., Peyton-Jones, S., and Herlihy,M. 2005.Composable memory transactions.In Proceedings
of the Tenth ACM SIGPLAN Symposium on Principles and Practiceof Parallel Programming(Chicago,IL,USA, June
15–17, 2005). PPoPP '05. ACM, New York, NY, 48-60.
32 Herlihy,M. and Moss, J. E. 1993. Transactional memory: architectural supportfor lock-freedata structures.In
Proceedings of the 20th Annual international Symposiumon Computer Architecture (San Diego, California,United
States, May 16–19, 1993).ISCA '93. ACM, New York, NY, 289-300.
33 Herlihy,M., Luchangco, V., Moir, M., and Scherer, W. N. 2003. Software transactional memory for dynamic -sized
data structures. In Proceedings of the Twenty-Second Annual Symposium on Principlesof Distributed Computing
(Boston, Massachusetts,July 13–16,2003). PODC '03. ACM, New York, NY, 92-101.
34 Shavit,N. and Touitou, D. 1995.Software transactional memory. In Proceedings of the Fourteenth Annual ACM
Symposium on Principles of Distributed Computing (Ottawa, Ontario,Canada,August 20–23, 1995). PODC '95.
ACM, New York, NY, 204-213.

7. 7
Abstracción de persistencia
Oceanstore: una arquitectura para el almacenamiento persistente a escala global 35
Abstracción de confiabilidad
Comprobaciones de sanidad El Problema de los generales bizantinos 36
Procesadores Fail-Stop: un enfoque para el diseño de sistemas tolerantes a fallos 37
RecuperabilidadInstantáneasdistribuidas: determinar estados globales de los sistemas distribuidos 38
Recuperación optimista en sistemas distribuidos39
Modelos de computación distribuida
La naturaleza de la distribución
Los elementosde hardware de un sistemaoperativodistribuidorepartidosenvariasubicacionesdentro
de un rack, o alrededor del mundo. Las configuraciones distribuidas permiten que las funciones sean
distribuidas y descentralizada.
Tres distribuciones básicas
Parailustrarmejorestepunto,examinaremostresarquitecturasde sistema;centralizado,descentralizado
y distribuido. En este examen, consideraremos tres aspectos estructurales: organización, conexión y
control. La organización describe las características físicas de un sistema. La conexión cubre las rutas de
comunicación entre los nodos. El control gestiona el funcionamiento de las dos consideraciones
anteriores.
Organización
Un sistema centralizado tiene una estructura de un solo nivel,donde todos los componentes dependen
de unúnicoelementode control.Unsistemadescentralizadoesjerárquico.Unsistemadistribuidoesuna
colección de elementos autónomos que no tienen concepto de niveles.
Conexión
Los sistemas centralizados conectan cada componente a un nodo central. Un sistema descentralizado
(también conocido como sistema de red) incorpora vías directas e indirectas entre los elementos
constitutivos y de la entidad central. Finalmente, el sistema operativo distribuido no requiere ningún
patrón; conexiones directas e indirectas son posibles entre dos elementos.
35 Kubiatowicz,J., Bindel,D., Chen, Y., Czerwinski,S., Eaton, P., Geels, D., Gummadi, R., Rhea, S., Weatherspoon,
H., Wells,C., and Zhao, B. 2000. OceanStore: an architecturefor global-scalepersistentstorage.In Proceedings of
the Ninth international Conference on Architectural Support For ProgrammingLanguages and Operating Systems
(Cambridge, Massachusetts,United States). ASPLOS-IX. ACM, New York, NY, 190-201.
36 Lamport, L., Shostak, R., and Pease, M. 1982. The Byzantine Generals Problem. ACM Trans.Program. Lang. Syst.
4, 3 (Jul. 1982),382-401.
37 Schlichting,R.D. and Schneider, F. B. 1983.Fail-stop processors:an approach to designingfault-tolerant
computing systems. ACM Trans.Comput. Syst. 1, 3 (Aug. 1983),222-238.
38 Chandy, K. M. and Lamport, L. 1985.Distributed snapshots:determiningglobal states of distributed systems.
ACM Trans.Comput. Syst. 3, 1 (Feb. 1985), 63-75.
39 Strom, R. and Yemini, S. 1985. Optimistic recovery in distributed systems.ACM Trans.Comput. Syst. 3, 3

8. 8
Control
Los sistemas centralizados y descentralizados dirigen los flujos de conexión hacia y desde la entidad
central,mientrasque los sistemasdistribuidosse comunicana lo largo de caminosarbitrarios.Esta es la
idea central de la tercera consideración. Control implica equilibrar la asignación de tareas y datos a los
elementos del sistema, así como la capacidad de respuesta y la complejidad.
Los sistemas centralizados y descentralizados ofrecen un mayor control, facilitando la administración
mediante lalimitaciónde lasopciones.Lossistemasdistribuidossonmásdifícilesde controlarde manera
explícita, pero son más fáciles de escalar y tienen un menor número de puntos de fallo.
Consideraciones de diseño
Transparencia
La transparenciahace referenciaala habilidadque tienenlasaplicacionesde tratar al sistemaenel que
operan sin importar si este es distribuidoo no y sin importar el hardware o la implementación. Muchas
áreas de un sistema pueden beneficiarse de la transparencia, incluyendo el acceso, la ubicación, el
funcionamiento, la denominación, y la migración. La consideración de la transparencia afecta
directamente la toma de decisiones en cada aspecto del diseño de un sistema operativo distribuido. La
transparencia puede imponer ciertos requisitos y / o restricciones sobre las consideraciones de diseño.
Los sistemas opcionalmente pueden violar la transparencia en diversos grados para satisfacer los
requisitosde aplicacionesespecíficas.Porejemplo,unsistemaoperativodistribuidopuede presentaruna
unidad de disco duro en un ordenador como "C" y una unidad de disco en otro equipo como "G:". El
usuariono requiere ningúnconocimientode loscontroladoresde dispositivoolaubicaciónde launidad,
ambos dispositivos funcionan de la misma manera, desde la perspectiva de la aplicación. Una interfaz
menos transparente puede requerir la aplicación para saber qué equipo aloja la unidad.
Dominios de Transparencia:
• Transparencia de locación: comprende dos aspectos distintosde la transparencia, la transparencia de
nombre ylamovilidadde usuario.Latransparenciade nombre exige queningunade lasreferenciasfísicas
o lógicasa cualquierentidaddel sistemadebe exponerningunaindicaciónde laubicaciónde la entidad,
o de su relación local o remota para el usuario o la aplicación. La transparencia de movilidad de los
usuariosrequiere lareferenciaconsistentede entidadesdelsistema,independientementede laubicación
del sistema desde el que se origina la referencia. 40
• Transparencia de acceso: las entidades del sistema sean locales o remotas deben seguir siendo
indistinguiblescuandoseveanatravésdelainterfazde usuario.El sistemaoperativodistribuidomantiene
estapercepciónatravésde laexposiciónde unmecanismode accesoúnicoparaunaentidaddel sistema,
independientementede que laentidadsealocal oremota para el usuario.La transparenciaexige que las
diferenciasenlosmétodosde accesoa una entidadde un sistemaparticularya sea local o remotodebe
ser a la vez invisible a, e indetectable por el usuario. 41
• Transparencia de migración: Permite a los recursos migrar de un elemento a otro controlado
únicamente por el sistema y sin el conocimiento del usuario o aplicación.42
40 Sinha,Pradeep Kumar (1997).Distributed Operating Systems: Concepts and Design. IEEE Press.ISBN 978-0-7803-
1119-0.
41 Sinha,Pradeep Kumar (1997).Distributed Operating Systems: Concepts and Design. IEEE Press. ISBN 978-0-7803-
1119-0.
42 Galli,Doreen L. (2000).Distributed OperatingSystems: Concepts and Practice.Prentice Hall.ISBN978-0-13-
079843-5.

9. 9
• Transparenciade replicación:El procesode replicaciónoel hechode que unrecursose haduplicadoen
otro elemento se produce bajo el control del sistema y sin el conocimientoo intervención del usuarioo
aplicación.
• Transparencia de concurrencia: Los usuarios o las aplicaciones no son conscientes de la presencia de
otros usuarios o aplicaciones.
• Transparencia de fallo: el sistema es el responsable de la detección y corrección de fallos. No se
requieren conocimientos o acción de usuario / aplicación excepto esperar a que el sistema resuelva el
problema. 43
• Transparencia de rendimiento: El sistema es el responsable por la detección y la solución de los
problemas de rendimiento. Ninguna acción del usuario es necesaria.
• Transparenciade escala:El sistemaesel únicoresponsable de sualcance geográfico,cantidadde nodos
o capacidad de cada nodo sin el conocimiento o intervención del usuario.
De forma similar también existen:
• Transparencia de revisión
• Transparencia de control
• Transparencia de datos
• Transparencia de paralelismo
Comunicación entre procesos
La comunicaciónentre procesos(IPC) eslaimplementaciónde lacomunicaciónen general,lainteracción
de procesosy flujode datosentre hilosy/o (1978) procesos,tantodentrode unnodo,y entre losnodos
de un sistema operativo distribuido. En este sentido, IPC es el mayor concepto subyacente en las
consideraciones de diseño de bajo nivel de un sistema operativo distribuido.
Gestión de procesos
La gestión de procesos proporciona las políticas y mecanismos para el intercambio eficaz y eficiente de
losrecursosentre losprocesosdistribuidos.Estaspolíticasymecanismosde apoyo alasoperacionesque
implican la asignación de procesadores y puertos a procesos, así como los mecanismos para ejecutar,
suspender, emigrar, detener o reanudar la ejecución de un proceso. Si bien estos recursos y las
operaciones pueden ser locales o remotas, el sistema operativo distribuido mantiene el estado de
sincronización a través de todos los procesos en el sistema.
Gestión de los recursos
Los recursostalescomolamemoria,losarchivos,dispositivos,etc.se distribuyenportodounsistema.La
carga compartida y el equilibrio de carga requieren muchas decisiones orientadas a dicho fin, que van
desde encontrar una CPU inactiva, cuando mover, y que se mueve. Muchos algoritmos existen para
ayudar en estas decisiones, sin embargo, esto requiere un segundo nivel de la política de toma de
decisiones en la elección del algoritmo más adecuado para el escenario y las condiciones que rodeanel
escenario.
43 Chow, Randy; Theodore Johnson (1997). Distributed OperatingSystems and Algorithms.Addison Wesley.ISBN
978-0-201-49838-7.

10. 10
Fiabilidad
Un sistema operativo distribuido puede proporcionar los recursos y servicios necesarios para alcanzar
altos niveles de fiabilidad, o la capacidad para prevenir y / o recuperarse de los errores. Las Fallas son
defectos físicos o lógicos que pueden causar errores en el sistema. Para que un sistema sea fiable, de
alguna manera debe superar los efectos adversos de los fallos.
La toleranciaa fallosesla capacidad de un sistemapara continuarla operaciónen presenciade unfallo.
En el caso, el sistema debe detectar y recuperar la funcionalidad completa. En cualquier caso, todas las
medidas adoptadas deben hacer todo lo posible para preservar la imagen de sistema único.
Disponibilidad
Disponibilidad es la fracción de tiempo durante el cual el sistema puede responder a peticiones.
Rendimiento
El rendimiento en un sistema operativo distribuido generalmente se traduce en el balance entre el
paralelismo y la comunicación entre procesos.
Sincronización
Los procesos concurrentes cooperantes tienen una necesidad inherente de sincronización, lo que
garantiza que los cambios ocurren de una manera correcta y predecible.
Hay tres situaciones básicas que definen el ámbito de aplicación de esta necesidad:
• uno o más procesos deben sincronizar en un punto dado para uno o más de otros procesos a seguir,
• uno o más procesos deben esperar una condición asincrónica con el fin de continuar,
• un proceso debe establecer un acceso exclusivo a un recurso compartido.
La sincronización incorrecta puede dar lugar a múltiples formas de falla, incluyendo la pérdida de
atomicidad,coherencia,aislamientoydurabilidad,bloqueo,bloqueoactivoylapérdidade serialización.
Investigación
Replicated model extended to a component object model
Architectural Design of E1 Distributed Operating System 44
The Cronus distributed operating system 45
Design and development of MINIX distributed operating system 46
44 L.B. Ryzhyk, A.Y. Burtsev. Architectural design of E1 distributed operatingsystem. System Research and
Information Technologies international scientific and technical journal,October 2004,Kiev, Ukraine.
45 Vinter, S. T. and Schantz, R. E. 1986. The Cronus distributed operatingsystem. In Proceedings of the 2nd
Workshop on MakingDistributed Systems Work (Amsterdam, Netherlands, September 08–10, 1986).EW 2. ACM,
New York, NY, 1-3.
46 Ramesh, K. S. 1988. Design and development of MINIX distributed operatingsystem. In Proceedings of the 1988
ACM Sixteenth Annual Conference on Computer Science (Atlanta,Georgia, United States). CSC '88. ACM, New
York, NY, 685.

11. 11
Complexity/Trust exposure through accepted responsibility
Scale and performance in the Denali isolation kernel.47
Multi/Many-core focused systems
The multikernel: a new OS architecture for scalable multicore systems. 48
Corey: an Operating System for Many Cores. 49
Distributed processing over extremes in heterogeneity
Helios: heterogeneous multiprocessing with satellite kernels.50
Effective and stable in multiple levels of complexity
Tessellation: Space-Time Partitioning in a Manycore Client OS. 51
47 Whitaker, A., Shaw, M., and Gribble,S. D. 2002. In Proceedings of the 5th Symposiumon Operating Systems
Design and Implementation.
48 Baumann, A., Barham,P., Dagand,P., Harris,T., Isaacs,R.,Peter, S., Roscoe, T., Schüpbach,A., and Singhania,A.
2009.In Proceedings of the ACM SIGOPS 22nd Symposium on OperatingSystems Principles (BigSky,Montana,
USA, October 11–14, 2009). SOSP '09.
49 S. Boyd-Wickizer,H. Chen, R. Chen, Y. Mao, F. Kashoek,R. Morris,A. Pesterev, L. Stein, M. Wu, Y. Dai,Y. Zhang,
and Z. Zhang. Proceedings of the 2008 Symposium on OperatingSystems Design and Implementation (OSDI),
December 2008.
50 Nightingale,E. B., Hodson, O., McIlroy,R., Hawblitzel,C., and Hunt, G. 2009. In Proceedings of the ACM SIGOPS
22nd Symposiumon Operating Systems Principles(BigSky, Montana, USA, October 11–14, 2009).SOSP '09.
51 Rose Liu, Kevin Klues,and Sarah Bird,University of CaliforniaatBerkeley; Steven Hofmeyr, Lawrence Berkeley
National Laboratory;Krste Asanović and John Kubiatowicz,University of CaliforniaatBerkeley. HotPar09.