Apuntes de Sistemas Operativos PDF

Grado en Ingeniería Informática INFORMÁTICA BÁSICA Tema 2. Introducción a los sistemas operativos Docentes: Versión 2.010 Jesus M. Maudes Raedo Revisado 2.014 Carlos Pardo Aguilar Introducción a los Sistemas Operativos 1 El concepto de Sistema Operativo El sistema oper...

Grado en Ingeniería Informática INFORMÁTICA BÁSICA Tema 2. Introducción a los sistemas operativos Docentes: Versión 2.010 Jesus M. Maudes Raedo Revisado 2.014 Carlos Pardo Aguilar Introducción a los Sistemas Operativos 1 El concepto de Sistema Operativo El sistema operativo es el programa fundamental entre todos los programas del sistema. Un sistema operativo es un programa o conjunto de programas de control que tiene por objeto facilitar el uso eficiente del computador. Controla todos los recursos del ordenador. La cantidad de memoria que es asignada a un programa de ejecución, el tiempo de CPU que consume ese programa cuando se está ejecutando a la vez que otros, o la gestión de la cola que han de esperar los trabajos que se mandan a la impresora, son ejemplos de recursos de la computadora a los que programas y usuarios no tienen acceso ni control directo, sino en todo caso a través del sistema operativo. Por tanto, los programas de aplicación que requieren esa memoria, ese tiempo de CPU, y ese acceso a los periféricos necesitan que exista un sistema operativo al que pedir estos recursos, y por tanto se dice que el sistema operativo proporciona la base sobre la que pueden escribirse los programas de aplicación, Se dice también que el sistema operativo actúa como intermediario entre el usuario y el hardware, ya que proporciona un entorno en el que el usuario puede ejecutar programas de una manera cómoda y eficiente, pues el usuario no necesita conocer los detalles concretos de su máquina para utilizarla. Por ejemplo, cualquier usuario de Windows es capaz de usar de igual manera distintas máquinas, es decir que desde el punto de vista hardware tengan configuraciones distintas. Esto supone comodidad, pero también eficiencia, pues por muy bien que un usuario experto conozca su hardware, es improbable que le hiciera funcionar mejor que lo hace el propio sistema operativo, aun en escenarios tan complejos como cuando hay varios usuarios trabajando simultáneamente; y sin embargo lo probable sería que olvidara algún detalle de los numerosos elementos que componen una computadora, y que finalmente ese olvido fuera la causa de algún problema. Es decir, el sistema operativo oculta la complejidad del hardware y proporciona al programador un conjunto de instrucciones más cómodo, y además asegura el correcto funcionamiento del ordenador. Usuario 1 Usuario 2 Usuario 3... Usuario n Compilador Ensamblador Editor de Texto … Sistema de BD APLICACIONES / UTILIDADES SISTEMA OPERATIVO HARDWARE Ilustración 1: El Sistema operativo visto como una capa intermedia entre los recursos hardware y los programas y usuarios. En la ilustración se muestra al sistema operativo como una capa que rodea al hardaware, de manera que las distintas aplicaciones (un compilador, un ensamblador, un editor y una base de datos en el -1- ejemplo) no pueden utilizar el hardware directamente, sino a través de llamadas o peticiones al sistema operativo. A su vez, los usuarios o bien utilizan una aplicación que indirectamente realiza peticiones al sistema operativo (como aparece en la ilustración), o también (eso no viene reflejado en la ilustración) podría darse el caso de que utilizase el sistema operativo directamente (como por ejemplo cuando copiamos un fichero, o creamos una carpeta o un usuario); pero ningún caso el usuario accede tampoco directamente al hardware. 1.1 Objetivos de los sistemas operativos 1. Control: El sistema operativo, como hemos visto es el que tiene que controlar directamente los recursos del sistema (espacio de memoria, de disco, tiempo de CPU, gestión de periféricos, etc...), de forma que usuarios y programas no puedan acceder a los mismos de forma incontrolada, sino a través del sistema operativo, que controlará que el uso sea correcto y dentro de un orden. 2. Comodidad: El sistema operativo ha de ser cómodo de utilizar para los usuarios. El sistema operativo realizará tareas muy complejas, pensemos por ejemplo en todo lo que requiere copiar un fichero (localizar espacio libre en el disco, grabar marcas de principio y fin de fichero, actualizar la tabla que lleva la cuenta de donde esta cada fichero, manejo de las interrupciones de E/S etc...), pero para nosotros esa dificultad queda enmascarada, en este ejemplo quizás en una simple operación de arrastre con el ratón. 3. Eficiencia: Los recursos del sistema tienen que ser utilizados de manera eficiente. No deben desperdiciarse alegremente. Hay situaciones especialmente complejas en este sentido (múltiples usuarios concurrentes, múltiples procesos compitiendo por la memoria y por la CPU, escasez de memoria para la carga de trabajo actual, etc...) y todas esos problemas el sistema operativo los resuelve de forma cómoda/transparente al usuario como se ha visto, pero también lo más eficiente posible. Tanto es así, que no cabe pensar en hacer programas que mejoren la gestión que el sistema operativo hace de esas situaciones salvo, como veremos en el siguiente objetivo, por los propios programadores que mantienen y crean nuevas versiones del sistema operativo. 4. Evolución: Los sistemas operativos han ido evolucionando con el tiempo. Las mejoras que van surgiendo se desarrollan/programan sobre alguna máquina que a su vez tiene un sistema operativo, y se prueban sobre una máquina con sistema operativo. Por tanto, la evolución se refiere a la capacidad de introducir, programar y probar esas mejoras de un sistema operativo, sin interferir con el propio sistema operativo, haciendo que este de alguna forma dejase de proveer correctamente cualquiera de sus servicios. Para ello, es conveniente que el sistema operativo presente un cierto grado de modularidad, de forma que los cambios sólo afecten a partes/módulos del sistema operativo. 1.2 Servicios que se espera que provea un sistema operativo 1. Creación de Programas: Los sistemas operativos pueden incluir herramientas de desarrollo mas o menos básicas, como compiladores, linkadores, antiguamente ensambladores, y bibliotecas que permitan llamar a funciones del propio sistema operativo y manipular periféricos. Una biblioteca es un archivo que contiene varios subprogramas con tareas de uso frecuente. Estos subprogramas se llaman funciones, estas funciones no se pueden utilizar directamente por el usuario, sino que son llamadas por cualquier otro programa, cuyos programadores se “ahorran” el tener que programar esa parte que ya les viene hecha en la función. Este concepto se ampliará en el tema de programación. -2- 2. Ejecución de Programas: Los sistemas operativos han de encargase de hacer de forma sencilla para el usuario la carga en memoria de los programas que se van a ejecutar, comenzar la ejecución asignado y controlando los recursos necesarios para esa ejecución (CPU, memoria, periféricos … ), abandonar la ejecución en caso de error, petición de abortar por parte de un usuario, o simplemente por finalización normal del programa; en cualquiera de estos casos el sistema operativo al finalizar el programa liberaría los recursos que este estuviese utilizando. 3. Operaciones de E/S: Un programa de usuario no puede ejecutar directamente las operaciones de E/S, sino que debe de llamar al sistema operativo para que éste realice esas operaciones. Esta limitación favorece la gestión eficiente de los dispositivos E/S. 4. Manipulación del Sistema de Ficheros: Las operaciones de lectura, escritura y borrado de ficheros, a partir de su nombre y localización, son competencia del sistema operativo. Ususarios y programas llaman o delegan en el sistema operativo a la hora de hacer estas operaciones. Es el sistema operativo el que organiza también los ficheros en el disco, siendo capaz de ocultar la posición/organización física y dejándonos ver una organización lógica (por ejemplo mediante carpetas) que no es más comprensible. 5. Comunicaciones: Recientemente los sistemas operativos tienden a incorporar facilidades que permiten al usuario de forma fácil, tanto conectarse a de redes de computadoras, como utilizarlas. 6. Detección de errores: Para cada posible error que se de durante el funcionamiento de la máquina (ejemplos: un proceso que no tiene memoria suficiente para seguir ejecutándose, un programa P1 está escribiendo en el fichero F1 y necesita escribir en F2, pero tiene que esperar a que acabe un programa P2 que está escribiendo en F2 y necesita escribir en F1, por lo que P2 tiene que esperar a P1, y al final los 2 programas no terminan porque se esperan mutuamente, etc …) el sistema operativo debe estar atento al mismo y tener una respuesta que no comprometa la estabilidad del sistema, evitando en la medida de lo posible que ese error derive en un estado inconsistente que influya en los programas que se estén ejecutando a partir de ese momento, y que por ejemplo nos obligara a reiniciar la máquina para tener la garantía de que nada funciona mal por culpa de ese error anterior. 7. Asignación de recursos (CPU, memoria, … ): En sistemas operativos multiproceso (todos los actuales) es el encargado de asignar ciclos de CPU y áreas de memoria, utilización de los periféricos, … a los programas que se estén ejecutando concurrentemente (simultaneamente) de forma racional. Esto incluye, gestión de prioridades (dar más recursos al programa que más prioridad tenga). 8. Contabilidad, estadísticas (de uso y de rendimiento): La contabilidad se refiere sobre todo a, en un sistema multiusuario, llevar la cuenta de cuál es el consumo de recursos que realiza (típicamente es casi siempre el tiempo de CPU consumido, pero también podría ser relativo a consumo de memoria, disco o ejecución de determinados programas), para poder facturarle el uso del computador en un determinado periodo. Mas allá de esta función de cobro por utilización, los sistemas operativos deben proveer formas de monitorizar el rendimiento del sistema, para conocer si hay momentos o situaciones en las que el sistema no tiene recursos suficientes o quizás haya que administrarlos de otra forma (p.e. cambiar el momento d ejecución de un programa a horas de poca actividad, limitar el espacio de disco o memoria de un determinado programa, dar más o menos prioridad a un programa para hacerse con ciclos de CPU, … ). 9. Protección: A varios niveles. Por un lado el sistema operativo incorporará un sistema que permitirá asignar permisos a usuarios, de forma que no puedan realizar tareas para las que -3-  no están autorizados. Pero además el sistema operativo también pude incluir utilidades antivirus y cortafuegos, que puedan proteger al sistema de programas maliciosos y accesos desde la red no autorizados. 2 Tipos de Sistemas Operativos Caben hacer múltiples clasificaciones: 1. Por el tipo de interfaz: La interfaz es la parte del sistema operativo que permite al usuario dar órdenes al sistema operativo, y al sistema operativo mandar mensajes al usuario. La interfaz puede ser: 1. Texto, mediante la cual el usuario teclea comandos que son órdenes al sistema operativo. 2. Gráfica, basada en ventanas , iconos y ratón. MS-DOS era modo comando, UNIX es modo comando aunque se le fue dotando de una interfaz gráfica. Windows es gráfico aunque mantiene el intérprete de comandos. 2. Por el número de usuarios: Pueden ser monousuario si no permite que la máquina sea utilizada por más de un usuario simultáneamente, o multiusuario en caso contrario. MS- DOS o las primeras versiones de Windows (3, 3.11, NT, 95, 98, Millenium, 2000) eran monousuario, UNIX y las versiones actuales de Windows (2000 server y 2003 server, XP en adelante) son multiusuario. 3. Por el número de procesos que pueden estar ejecutándose concurrentemente: Pueden ser monotarea, si sólo se puede ejecutar un proceso como máximo, o multitarea en caso contrario. Cuando son multitatarea el sistema operativo se encarga de que compartan el procesador o proceadores que tenga la máquina. En la actualidad casi todos los sistemas son multitarea. Un ejemplo de monotarea es MS- DOS 4. Por el número de procesadores que es capaz de manejar: monoproceso si a paesar de que la computadora tenga más de un procesador sólo puede manejar uno, y multiproceso en caso contrario, de forma que es capaz de distribuir el trabajo entre ellos. MS-DOS es monoproceso, los sistemas operativos actuales son multiproceso. 5. Por el Tiempo de Respuesta, podrían ser de Tiempo Real, o bien de Tiempo Compartido, en los primeros, la gestión de los recursos está orientada a que el tiempo de respuesta sea el menor posible, en los segundos el tiempo de respuesta no es tan importante, en tanto que lo que se busca es simular que múltiples usuarios tengan la sensación virtual de que disfrutan de todos los recursos aprovechando que en un manejo interactivo del sistema la mayor parte del tiempo los usuarios apenas consumen recursos. Los sistemas operativos a tiempo real dan importancia al proceso, mientras que los de tiempo compartido al usuario. Los sistemas a tiempo real no son muy comunes, se utilizan para tareas muy concretas (p.e. control plantas industriales, reservas de vuelos, control de trenes, telecomunicaciones, etc. ) en los que el tiempo de respuesta es crítico. Por el contrario, los sistemas operativos actuales más populares con multiprogramación y multiusuario son de tiempo compartido. 6. Por la Forma de Ofrecer Servicios podrían ser: 1. Centralizados si permiten usar los recursos de una sola computadora, 2. En caso contrario (si permiten usar los recursos de varias computadoras conectadas en red) podrían ser: -4-  1. En red si está orientado a manejar los recursos de una red de equipos (p.e. Novell Netware), típicamente para compartir almacenamiento en disco, impresoras, y otros pariféricos. En estos sistemas operativos el usuario sabe y tiene el control de en que máquina de la red está un determinado fichero, qué máquina de la red está ejecutando un proceso, etc. 2. Sistemas distribuidos, en estos casos el usuario percibe el conjunto de máquinas como una sola y no tiene control sobre cómo la máquina gestiona los recursos (p.e. un sistema operativo de un cluster de ordenadores). Por requerir explicaciones más extensas a continuación se desarrolla la clasificación según la estructura interna en un apartado separado. 2.1 Clasificación de los Sistemas Operativos según su estructura interna Los sistemas operativos pueden ser, según la estructura interna que tangan: 1. Sistemas Monolíticos 2. Sistemas por Capas 3. Sistemas con Micro-kernel 4. Modelo Cliente-Servidor 5. Máquinas Virtuales 2.1.1 Sistemas Monolíticos Los sistemas operativos monolíticos representan aquellos sistemas operativos que prácticamente no tienen ninguna estructura, sino que es una simple colección de procedimientos o subprogramas, cada uno de los cuales puede llamar a todos los demás si lo necesita. Esto puede ser un problema, pues puede haber procedimientos de los que no se haga un buen uso, y por ello conviene restringir qué procedimientos pueden llamar a qué otros, lo cual es lo que se consigue con otras arquitecturas más compartimentadas como veremos. La construcción de un sistema monolítico es por tanto inmediata. Los programas en un determinado lenguaje de programación, por ejemplo C, están en varios ficheros. Se compilan por separado y se enlazan (se unen) mediante otro programa (el linker o enlazador1). Con lo cual se tiene el sistema operativo en un único fichero ejecutable. Como ya hemos visto, el sistema operativo no permite ni a usuarios, ni a programas acceder directamente a los recursos, sino es a través de él. Son usuarios y programas los que cuando quieren hacer este tipo de operaciones tienen que hacer los que se conoce como una llamada al sistema (system call). De tal forma que la computadora al final tiene dos modos de trabajo: el modo usuario en el que sólo se pueden acceder a los recursos mediante llamadas al sistema, y el modo núcleo o supervisor que entra en acción cuando precisamente el sistema operativo está ejecutando esa llamada al sistema. El inciso del párrafo anterior viene motivado para dar una explicación de cómo, aún dentro de ausencia de estructura de un sistema operativo monolítico, si que es posible apreciar un cierto orden en cómo se gestiona una llamada al sistema de forma que se aprecia: 1 Como verás en el tema de programación, un enlazador no es más que programa encargado de unir o enlazar el código de varios módulos separados que mantienen llamadas o referencias cruzadas entre los mismos, de forma que se pueda realizar su posterior ejecución. -5-  1. Un programa principal (el núcleo, kernel, o supervisor) que recibe todas las llamadas al sistema por parte de usuarios y aplicaciones. 2. Un conjunto de procedimientos de servicio que son los que realmente llevan a cabo las llamadas del sistema. 3. Un conjunto de procedimientos de utilidad que “ayudan” a los procedimientos de servicio a realizar algunas partes de su trabajo. La llamada al sistema llega al núcleo que cambia la ejecución a modo supervisor y busca el procedimiento de servicio correspondiente (sólo puede haber uno). El procedimiento de servicio puede llamar a cuantos procedimientos de utilidad necesite para llevar a cabo su cometido. Programa principal Procedimientos de Servicio Procedimientos de Utilidad Ilustración 2: Estructura subyacente a un sistema monolítico. Ilustración tomada del libro sistemas Operativos Modernos de A. Tanebaum. Por ejemplo, la llamada podría ser leer el contenido de un fichero. Esta llamada tendría unos parámetros: el fichero a leer, en qué dirección de memoria está el buffer, y el número de bytes a leer. El núcleo recoge la llamada, pasa a modo supervisor, interpreta la llamada y encuentra el procedimiento de servicio que realiza esa tarea, y le pasa esos parámetros al mismo. El procedimiento de servicio se ejecuta, quizás haya un procedimiento de utilidad que a partir del nombre del fichero nos de la posición física del comienzo del mismo en el disco. En ese supuesto, el procedimiento que hace la lectura llamara al que obtiene la posición física y así no tiene que averiguarla por el mismo. Pero conviene observar que esa utilidad que nos da la posición física puede ser utilizada por otros procedimientos de servicio (p.e. la que mueva un fichero de una carpeta a otra). A pesar de ser la peor estructura posible, la estructura monolítica está muy extendida, debido a que históricamente es la más primitiva, y se ha tomado como base para desarrollar nuevas versiones de sistemas operativos que ya tienen unos años. -6-  Núcleos tipo UNIX ◦ Linux ◦ Syllable ◦ Unix ▪ BSD FreeBSD NetBSD OpenBSD ▪ Solaris ▪ AIX DOS ◦ DR-DOS ◦ MS-DOS ▪ Sistemas operativos Microsoft Windows 9x (95, 98, 98SE, Me) Núcleos del Mac OS hasta Mac 8.6 Open VMS XTS-400 Ilustración 3: Ejemplos de sistemas monolíticos. A pesar de ser la peor estructura posible, está muy extendida. 2.1.2 Sistema con Capas Una alternativa a la estructura monolítica es la estructura por capas. Al fina y al cabo, la estructura monolítica presentaba ya tres capas en lo relativo a la gestión de los mensajes, luego parece la evolución natural de estos sistemas. La diferencia con las capas del modelo anterior es que antes todas las capas trataban cualquier tipo de problema a resolver por el sistema operativo, mientras que las capas de los sistemas operativos con capas propiamente dichos tienen cada una sus funciones muy delimitadas. Es decir, cada capa se dedica a dejar resueltos una serie de problemas, de forma que la capa superior se despreocupa de los problemas ya resueltos pro capas más bajas. Como ejemplo pondremos el primer prototipo de este tipo de sistemas, llamado THE (Technische Hogeschool Eindhoven) creado por Dijkstra y sus alumnos en 1968. En este sistema hay 6 capas numeradas del 0 al 5: La capa 0 es la encargada de llevar los procesos a la CPU, cambiar el proceso en la CPU cuando se produce una operación de E/S, o cuando finaliza y hay otro esperando. Por tanto, se encarga de todos los problemas relativos a multiprogramación. Por tanto, la capa inmediatamente superior puede no tiene que preocuparse ya de estos problemas, puede vivir en la creencia de que la CPU la está ocupando sólo el proceso en curso todo el tiempo, -7- lo cual facilita enormemente los escenarios posibles. La capa 1 era la encargada de gestionar la memoria. Asignaba un espacio de memoria a cada uno de los procesos que estaban corriendo, y también se ocupaba de gestionar parte del disco como memoria (memoria virtual), si no había memoria suficiente. Esto supone escribir y leer de disco la información de un proceso que necesita más memoria de lo habitual. Por tanto la capa siguiente puede vivir en la creencia de que todos los procesos caben en memoria, nuevamente simplificando los problemas posibles. La capa 2 se encarga de la comunicación entre procesos y la consola (el terminal de usuario) Por tanto, la capa siguiente no percibe que el sistema y la consola tengan que mandarse mensajes, verificar si han llegado bien, reenviarlos sino, etc. nuevamente simplificando el problema. La capa 3 se encarga del manejo de los dispositivos de E/S (buffering, controladores E/S …) Con lo cual la capa 4 le es igual qué modelo de dispositivo de E/S en concreto se este´utilizando, pues tiene una visión abstracta y sencilla del mismo, dejando el manejo de los detalles técnicos en la capa anterior. La capa 4 realmente no es el sistema operativo, sino los programas de usuario que llaman al sistema operativo Y la capa 5 es el propio usuario que como dijo Dijkstra “no lo implementamos nosotros” Por tanto, en un sistema en capas lo importante es invertir tiempo en pensar cuál va a ser la responsabilidad de cada una de las capas antes de empezar a crearlo. Es interesante que las capas más bajas sean las que traten cuestiones más cercanas al hardware (CPU, memoria, E/S) de forma que el código en el resto de capas valga igual para una configuración hardware que para otra. Un esquema de capas genérico podría ser el siguiente: 1. Nivel núcleo: gestiona los procesos, tareas básicas del sistema, asignación CPU, interrupciones E/S, comunicación con el hardware, etc. (Parecido al nivel 0 de THE) 2. Nivel ejecutivo: Encargado de la gestión de la memoria y memoria virtual (Parecido al nivel 1 de THE) 3. Nivel supervisor: Se encarga de realizar la comunicación de cada proceso entre el sistema y el usuario. Controla y coordina la gestión de entrada/salida de los diferentes procesos hacía los periféricos. (Serían las capas 2 y 3 de THE) 4. Nivel usuario: Es el que controla los procesos que está utilizando el usuario, sin preocuparse de la gestión de memoria, de la gestión de entrada/salida ni de nada en especial. Simplemente, muestra al usuario el proceso que éste quiere ejecutar. Este nivel es el que proporciona la interfaz para la interrelación con el usuario. (capa 4 en THE). La división en niveles de la máquina virtual permite dividir el problema de crear un sistema operativo en varias partes, cada una de las cuales son más sencillas de programar, testear y depurar. Linux y Windows 2000 son modelos en capas, aunque no al 100%. 2.1.3 Sistemas con Microkernel o Micronúcleo En los sistemas por capas todas las capas corren en modo supervisor, pero realmente esto no tiene por qué ser necesario. De hecho si se consigue que una mínima parte del sistema operativo corra en modo supervisor y el resto en modo usuario el sistema operativo se vuelve más robusto/estable. -8- Los sistemas operativos tienen millones de líneas de código de las cuales es normal que el 1% correspondan con fallos de programación o bugs, algunos de los cuales podrían ser infrecuentes y tener poca repercusión, pero otros no. Cuando ocurre uno de estos errores de programación mientras el sistema corre en modo supervisor lo normal es que el sistema se caiga, pero si ocurren en modo usuario, el proceso correspondiente al bug morirá o abortará, pero el resto del sistema seguirá funcionando. En los sistemas con microkernel, el núcleo del sistema operativo es la capa más baja de un modelo por capas, que se ocupa de un conjunto muy reducido de responsabilidades. Por ejemplo, en MINIX-3 gestiona qué procesos están en la CPU en cada momento, la comunicación entre esos procesos, manejo de interrupciones y gestión de memoria. El resto de funciones del sistema operativo son realizadas por capas superiores que corren en modo usuario. Ejemplo extraído de (Tanembaum 2007): un driver de audio tiene un bug. En un sistema monolítico los drivers están todos en el núcleo, por lo que ese driver podría hacer una escritura por error en una dirección de memoria que fuese vital para el sistema operativo, pensando que lo esta haciendo en su buffer, y provocar una caída del sistema (los drivers los programan normalmente los fabricantes del dispositivo de audio, no los programadores del sistema operativo, por lo que es un riesgo real). En un sistema con microkernel ,el driver, si falla, sólo se notaría en que el audio funciona mal o el programa de reproducción aborta, pero no el sistema entero. Symbian es un ejemplo de sistema operativo actual con microkernel, y sirve para ilustrar la idoneidad de este tipo de arquitectura en entornos en los que es crítico que el sistema operativo no deje de funcionar, como es el caso de la telefonía móvil, pero tabién hay otras situaciones como aplicaciones militares, aplicaciones industriales en tiempo real, aviónica, etc … 2.1.4 Modelo Cliente-Servidor Puede verse como una evolución de la arquitectura anterior basada en distinguir entre dos tipos de procesos: los procesos servidores que proveen algún servicio, y los procesos clientes que los solicitan y consumen. Clientes y servidores se comunican a través de paso de mensajes (el cliente manda un mensaje al servidor solicitando un servicio, el servidor le responde). El problema es que muchos de los servicios necesitan ejecutarse en modo suspervisor para acceder directamente al hardware. Los procesos clientes pueden implementarse como procesos de usuario. Por ello, una forma de implementarlo sería con un microkernel. El kernel en este caso tendría estas funciones: 1. Es el que implementa el paso de mensajes que utilizan clientes y servidores. 2. En caso de que el servidor necesite acceder al hardware, se lo pide al núcleo, de forma que el servidor implementa la política del servicio (si el cliente tiene privilegios, si lleva mucho tiempo esperando y hay que atenderle, si es prioritario etc... ) pero el trabajo a nivel hardware lo realiza el núcleo. Las ventajas de estos sistemas están en que: 1. Como en el caso del microkernel el impacto de un fallo en un servicio está delimitado a un proceso, no provocando la caída del sistema. 2. Son fáciles de evolucionar, sustituir una versión de un servidor por otra superior es inmediato, y se puede hacer sin parar el sistema. 3. Como el cliente no sabe donde está el servidor, sino que simplemente le pasa un mensaje, el servidor podría estar incluso en otra máquina, por lo que resultan apropiados para -9-  implementar sistemas operativos distribuidos. 2.1.5 Máquinas Virtuales Las máquinas virtuales representan una forma de que convivan ejecutándose simultáneamente varios sistemas operativos en una misma máquina que una arquitectura de un solo sistema operativo, como ocurría en las dos secciones anteriores. Aunque da la impresión de que las máquinas virtuales son un tópico reciente, debido a que es posible instalar máquinas virtuales en PCs, lo cierto es que es una técnica que ya apareció en los años 60 con los IBM 360. En aquellos tiempos OS/360 de IBM era un sistema batch, pero los usuarios deseaban trabajar interactivamente desde un terminal. Entonces apareció un sistema el VM/370 en el que era posible distinguir dos partes: 1. Por un lados el corazón del sistema llamado el monitor de la máquina virtual, que: 1. Se ejecuta directamente sobre el hardware real. 2. Provee la parte de multiprogramación, como las capas bajas de la arquitectura por capas. 3. Provee varias máquinas virtuales 4. Pero en cada máquina virtual a parte de la multiprogramación común a todas las máquinas virtuales en ejecución no provee más servicios (i.e. no son máquinas extendidas) esto es, no entienden de manejar buffers, ni ficheros, ni cualquier otra abstracción propia del sistema operativo, pero a cambio cada máquina virtual es un programa que replica/simula el hardware real, que interpreta instrucciones máquina, que es capaz de pasar a modo usuario/supervisor independientemente de las otras máquinas virtuales, que acepta interrupciones E/S, etc... 2. Como cada máquina virtual simula en forma de réplica exacta el harware real, cualquier sistema operativo que puede correr en el hardware real, puede correr sobre la máquina virtual. En el ejemplo, algunos usuarios seguían corriendo el OS/360 que era batch mientras que otros corrian CMS (Conversational Monitor System) que era interactivo. Este esquema lo ha seguido implementando IBM hasta nuestros días en las computadores de la serie de grandes computadoras zSeries y con el monitor de máquina virtual zVM. Recientemente las máquinas virtuales han entrado con fuerza en los PCs pues: 1. Permiten juntar programas que corren en distintos sistemas operativos en una sola máquina. Esto ocurre tanto a nivel de servidores (por ejemplo, una sola máquina puede hacer de servidor de e-mail, de web, de bases de datos, y no todos las aplicaciones servidor están en el mismo sistema operativo), como a nivel de usuario final, pues sus aplicaciones favoritas corren en sistemas operativos distintos. 2. Por otro lado, permiten que en el negocio de hosting cada cliente alquile una máquina virtual, de las muchas que puede proveer un sólo servidor, haciendo que tenga un control completo sobre la misma. En los PCs, el monitor de máquina virtual se denomina hipervisor. Un problema de los procesadores Pentium es que ignoran las instrucciones privilegiadas (propias del modo suspervisor) cuando se intentan ejecutar desde modo usuario. La máquina virtual en principio es una aplicación más, y cuando pasa a modo supervisor la máquina real no lo está haciendo, por lo que al intentar ejecutar instrucciones privilegiadas (p.e. gestionando una operación de E/S) no funcionan. Este problema es lo que se denomina CPUs no virtualizables, que no ocurre cuando la CPU descubre -10- este intento de ejecutar instrucciones privilegiadas en modo usuario es capaz de lanzar una señal que pueda ser interpretada por el hipervisor para que resuelva el problema. Por eso, los hypervisores tradicionales (o hipervisores de tipo 1) no son adecuados para PC. En ese caso se utilizan los hipervisores de tipo 2, en los que un sistema operativo anfitrión se arranca primero. Sobre ese sistema se arranca un software de virtualización que provea la funcionalidad de hipervisor de tipo 2 (p.e. Oracle VirtualBox, Microsoft Virtual PC si el anfitrión es Windows, … ). Otro sistema operativo huésped que correrá en el software de virtualización, de forma que las llamadas al SO huésped son traducidas por este software a llamadas al SO anfitrión, resolviendose el problema de que la CPU no fuera virtualizable. 3 Introducción a los sistemas distribuidos Los sistemas distribuidos tratan de repartir la carga de trabajo entre varios procesadores que tiene la máquina y que pueden trabajar simultáneamente (i.e. en paralelo). Tradicionalmente este tipo de sistemas sólo se utilizaban en entornos de cálculo científico, debido a que permiten acelerar cálculos al paralelizar las operaciones. Otro factor que limitaba su uso era su elevado precio. En la actualidad, sin embargo, la tendencia es que incluso las máquinas personales incorporen procesadores con varios núcleos, que el sistema operativo percibe como varios procesadores, por lo que los sistemas operativos modernos más comunes también han tenido que evolucionar para dar respuesta a estas posibilidades que ofrece el hardware. Además de la potencia de cálculo los sistemas distribuidos aportan mayor fiabilidad, ya que si un procesador de los n que tenga deja de funcionar, el sistema irá a menos velocidad, pero no deja de funcionar. Este tipo de degradación del rendimiento sin que el sistema deje totalmente de dar servicio, es lo que se conoce como degradación suave. Un ejemplo actual de sistema que reduce la degradación a través de un sistema distribuido es HP-NonStop. En realidad, y dada la reciente aparición de procesadores de varios núcleos, desde una perspectiva hardware se tiende a diferenciar los sistemas distribuidos propiamente dichos (en los que cada procesador está en una máquina diferente, y las máquinas están interconectadas por alguna red) de los sistemas multinúcleo. Si bien desde la perspectiva de los sistemas operativos, parte de la problemática de unos y otros es común, por lo que desde esta última perspectiva es admisible agruparlos como sistemas distribuidos en general. No obstante, la literatura de sistemas operativos suele hacer la siguiente distinción, que viene a corresponderse con la distinción que se hace en hardware entre sistemas distribuidos y multinucleo, a saber: 1. Sistemas débilmente acoplados, en los que los procesadores no comparten memoria ni reloj, pues cada uno cuenta con su propia memoria local. En este tipo de sistemas los procesadores están interconectados con el fin de comunicarse (darse órdenes, sincronizarse, etc... ). Dentro de los débilmente acoplados hay diferentes tipos de sistemas: 1. Clusters: Es un grupo de computadoras de relativo bajo costo, que están en una misma localización física, y que están relacionadas entre si mediante un sistema en red y un software que realiza la distribución de carga de trabajo entre los equipos. 2. Grid (malla): Se trata de un sistema que permite utilizar un número indeterminado de computadoras, que no tienen por qué estar en la misma localización física, como si fueran un único superordenador y de forma transparente al usuario. 2. Sistemas paralelos o fuertemente acoplados, en los que sí que se comparte la memoria, busesy el reloj; y quizas otros elementos como el almacenamiento externo, dispositivos de -11-  entrada salida y fuente de alimentación(este último caso de compartición extrema es el que ocurre por ejemplo en un sistema multinúcleo). Existen dos formas de compartición de la memoria: 1. UMA (Uniform Memory Access) si todas las direcciones de la memoria pueden ser accedidas por todos los procesadores con la misma velocidad. 2. NUMA (Nonuniform Memory Access), en caso contrario. Los sistemas fuertemente acoplados presentan como ventajas: ◦ Generalmente tienen un mayor rendimiento, ya que se corresponden con una arquitectura hardware que ha sido pensada especificamente para hacer múltiples operaciones en paralelo, frente al hardware de los sistemas acoplados que es genérico. ◦ Si se suman los costes de n los procesadores que conforman un sistema débilmente acoplado, el precio será superior al de un sistema fuertemente acoplado por una cuestión de economía de escala. Cuando varios procesadores de estos sistemas están ejecutando una misma aplicación, podríamos distinguir entre: Procesamiento Paralelo: Se caracteriza por tener múltiples procesadores trabajando sobre un espacio de memoria común. Es el caso de los sistemas fuertemente acoplados. Procesamiento Cooperativo o Colaborativo: Se caracteriza por; ◦ Fragmentar los elementos que componen una aplicación sobre dos o más sistemas interconectados mediante una red. ◦ Los recursos de los sistemas cooperantes se controlan y administran de manera independiente ◦ La relación entre los procesadores puede tomar diferentes formas ( Cliente – Servidor, Peer to Peer). El escenario hardware más propio de este tipo de procesameinto son los grids. Un ejemplo muy conocido de este tipo de procesamiento es el proyecto SETI@home de la Universidad de Berleley, que distribuye señales de radio captadas en el espacio entre los ordenadores que se unen a la malla para que éstos las analicen en busca de vida extraterrestre. E-mule puede considerarse otro ejemplo de procesamiento colaborativo, en este caso P2P. En secciones anteriores se ha visto que el multiprocesamiento ocurre cuando el mismo sistema es capaz de ejecutar varias peticiones o procesos al mismo tiempo. En los sistemas operativos distribuidos esta capacidad es consustancial, pues al estar formados por varios procesadores pueden ejecutar de forma real varias tareas en paralelo. El tipo de multiprocesamiento que pueden hacer los sistemas distribuidos puede ser: 1. Multiprocesamiento asimétrico (Asymmetric Multi-Processing ): En este caso un procesador maestro controla el sistema y el resto ejecutan las tareas que les asigna el maestro. Por tanto, todas las llamadas al sistema operativo tienen que pasar primero por el procesador maestro. Cuando un procesador esclavo queda libre, pide al maestro un nuevo proceso que ejecutar. Esta política equilibra bastante bien la carga entre procesadores, de manera que no estén unos ociosos mientras otros están sobrecargados. El mayor problema de este tipo de arquitectura es que todas las peticiones tienen que pasar por el maestro, y a medida que crece el número de procesadores esclavos, el maestro se -12-  satura recibiendo peticiones y organizando el trabajo, por lo que no es una solución claramente escalable. 2. Multiprocesamiento simétrico (Symmetric Multi-Processing o SMP): En este caso todos los procesadores son iguales, y todos tienen acceso a la única copia en memoria del sistema operativo, (por lo que normalmente se implementa bajo un sistema de tipo UMA). Esto elimina el cuello de botella en el procesador maestro, pero introduce otros problemas, ya que dos o más procesadores pueden competir por recursos como por ejemplo una misma página de memoria, y no hay en principio un procesador de rango superior que dirima estos conflictos. 3.1 Clusters Son sistemas multiprocesadores débilmente acoplados, formados por varios sistemas individuales interconectados por una LAN (red local) de alta disponibilidad que le permiten compartir almacenamiento (principalmente disco duro). Cada uno de los procesadores del cluster se conoce como nodo. Además de los nodos, el cluster está compuesto por un sistema operativo (si bien cada nodo podría tener un sistema operativo distinto), la LAN, los protocolos de comunicaciones que permiten al cluster usar la LAN para comunicar los nodos, y las aplicaciones que corren sobre el cluster, que podrían ser aplicaciones paralelas (capaces de aprovechar múltiples CPUs) o no. Un elemento fundamental de cluster que no hemos enumerado en el párrafo anterior es el middleware. Es una capa por encima del sistema operativo (una extensión del sistema operativo) que permite a usuarios y aplicaciones percibir el sistema como una sola máquina homogénea y no como múltiples máquinas con características distintas (como por ejemplo que tengan sistemas operativos distintos). Esta imagen única se conoce como SSI (Single System Image), y su ventaja fundamental es que simplifica el manejo del sistema. Una de estas tareas que haría el middleware en este sentido consiste en mantener la consistencia de la información que esté replicada en los nodos. De un cluster se espera además que alcance las siguientes metas: 1. Alto rendimiento, es decir soportar aplicaciones muy exigentes en recursos de cómputo: aplicaciones de cálculo matemático, simulaciones complejas, aplicaciones en tiempo real, o con un elevado nivel de usuarios concurrentes. 2. Alta disponibilidad, en muchos casos debe de garantizar que el sistema funcione ininterrupidamente 24 horas durante todo el año. Para alcanzar este objetivo el cluster puede configurarse como asimétrico o como simétrico. En el primer caso (asimétrico) una máquina A ejecuta procesos mientras otra B la monitoriza. Si la máquina A falla, B lo detecta y continúa con la ejecución de los procesos de A. El modo simétrico es más eficiente ya que A y B ejecutan ambos sus procesos a la par de que se monitorizan mutuamente. 3. Equilibrio de carga de trabajo entre distintos nodos, de manera que unos nodos estén ociosos y otros saturados. 4. Escalabilidad, debe permitir que el número de nodos del cluster crezca fácilmente. Inicialmente los clusters no alcanzaban estas metas, que eran más propias de sistemas fuertemente acoplados, pero en la actualidad la mejora del middleware hace que cada vez sea más común que lo consigan. El grado de optimización que persigue ese objetivo de alto rendimiento del cluster, está muy relacionado con el objetivo de equilibrado de la carga. Por ejemplo, el equilibrando las cargas de trabajo tiene que tener en cuenta qué procesos tienen más prioridad, para asignarles un nodo (o más -13- si es un proceso paralelo). En esta faceta de optimización y equilibrado de cargas, el middleware ha de permitir la migración de procesos entre servidores, y que en esa migración el nodo destino pueda ser elegido por el propio sistema en función de cuál esté más descargado, y de la prioridad del propio proceso, pues llegado el caso un proceso prioritario podría desalojar del nodo destino a uno que no lo fuese tanto. Al desalojar un proceso para llevarlo a otro nodo o servidor, el middleware ha de ser capaz de hacer que comience a ejecutarse en el mismo punto en el que se paró en el nodo origen. 3.1.1 Servidores Blade Una forma de formar un cluster es a través de un servidor Blade. Cada blade es un dispositivo físico, una tarjeta, que agrupa varios nodos (los cuales actualmente suelen ser a su vez procesadores de varios núcleos). Los nodos de un mismo blade comparten memoria y dispositivos de almacenamiento, por lo que es una solución a caballo entre los sistemas débilmente acoplados y los fuertemente acoplados, pues cada blade en solitario es un sistema fuertemente acoplado. Además todos los nodos de un blade comparten ventilación, fuente de alimentación y conexiones de red, por lo que se reduce tanto el consumo eléctrico como el cableado respecto a un cluster en el que cada nodo fuese una máquina independiente. Ilustración 4: Aspecto físico de un chasis con 16 blades, se observan 2 fuera. Los blades se acoplan en un chasis como en el de la ilustración. Los chasis a su vez se pueden apilar en un armario formando un cluster con varios blades. -14-