Aspectos de diseño Transparencia
Aspectos de diseño Flexibilidad: en ss.dd. interesa la máxima flexibilidad Los sistemas operativos pueden ser: monolíticos: poco flexibles de micronúcleo: hay un kernel muy simple y servidor de sistema de ficheros, de procesos, etc. Más flexible
Aspectos de diseño Confiabilidad: si alguna máquina falla, alguna otra máquina se encargue del trabajo En teoría la confiabilidad total del sistema debería ser el OR de la confiabilidad de los distintos componentes En la práctica esto no suele ser así:
“un s.d. es aquel del cual no puedo obtener un trabajo debido a que cierta máquina de la cual nueca he oído se ha roto”, Leslie Lamport
Disponibilidad: la fracción de tiempo en que se puede utilizar el sistema Tolerancia a fallos: ¿cómo de bien tolera el sistema los fallos? Si un servidor falla y se rearranca ¿se recupera el sistema fácilmente?
Aspectos de diseño Eficiencia: además de transparente, flexible y confiable, un s.d. debe ser rápido y eficiente A este respecto, en los s.d. es muy importante la velocidad de la red utilizada Los cálculos pueden ser de grano fino (p.ej sumar dos números) o de grano grueso Para cálculos de grano fino no compensa que se realicen en otras máquinas, porque se tarda más en la comunicación que en el cálculo
Aspectos de diseño Escalabilidad: hay que evitar: los componentes centralizados: p.ej. un supercomputador servidor central tablas –bases de datos– centralizadas algoritmos centralizados: hay que intentar que: ninguna máquina tenga información global acerca del estado del sistema las máquinas tomen decisiones solo en base a la información local no se confíe en un reloj global
Comunicación en los ss.dd. La diferencia más importante entre un s.d y un sistema con un solo procesador es la comunicación entre procesos En un sistema con un procesador, la comunicación entre procesos supone de manera implícita la existencia de memoria compartida Incluso la forma más básica de sincronización, el semáforo, supone la existencia de una variable compartida (la propia variable del semáforo) En los ss.dd. no contamos con esa memoria compartida, hemos de replantear la comunicación de procesos desde cero
Comunicación en los ss.dd. Debido a la ausencia de memoria compartida, la comunicación en los ss.dd. se basa en la transferencia de mensajes a través de la red Las redes se suelen estudiar en base al modelo de referencia para interconexión de sistemas abiertos (OSI) El modelo OSI divide en 7 capas los diferentes elementos y servicios que intervienen en las comunicaciones
Comunicación en los ss.dd. Cada capa utiliza servicios (funciones) de la capa inferior y ofrece servicios a la capa superior Cada paquete enviado por una capa se compone de control + datos El conjunto control+datos de una capa viaja en los datos de la capa superior (Gp:) datos (Gp:) control
(Gp:) datos (Gp:) control
capa i capa i-1
Comunicación en los ss.dd. Capas OSI que nos interesan:
Capa física: se encarga de la transmisión de bits por un canal físico de comunicación (sea análogico o digital) Capa de enlace: implementa control de errores para compensar los que se producen en el medio físico Capa de red: se encarga de encaminar la información del nodo origen al nodo destino, a través de redes y subredes Capa de transporte: divide los datos a enviar en paquetes y se asegura de que todos llegen correctamente al destino
Comunicación en los ss.dd. Tipo de conexión:
circuito virtual u orientado a conexión: al conectar se realiza una búsqueda de un camino libre entre origen y destino. Se mantiene el camino en toda la conexión no orientado a conexión: no se fija un camino. Cada paquete podrá ir por cualquier sitio. No se garantiza la recepción secuencial
Comunicación en los ss.dd. El modelo OSI fue bosquejado en los 70. Las redes de modo de transferencia asíncrono (ATM) son de reciente aparición Las compañías telefónicas se dieron cuenta de que el tráfico de voz requería bajo ancho de banda pero constante, mientras el tráfico de datos requería alto ancho de banda pero solo en determinados momentos ATM se basa en la transferencia de bloques de tamaño fijo (celdas) sobre circuitos virtuales. Al iniciar la comunicación se configuran los conmutadores en la red para formar un circuito virtual que se mantiene en toda la comunicación El uso de celdas de tamaño pequeño y fijo facilita la conmutación La red ATM integraba voz, televisión y datos, reemplazando lo que antes eran redes separadas
El modelo cliente-servidor Existen procesos servidores, que proporcionan cierto recurso o servicio, y procesos clientes que hacen solicitudes a los servidores El servidor recibe peticiones y envía respuestas
El modelo cliente-servidor Direccionamiento: ¿cuál es la dirección del servidor que debe usar el cliente? Posibilidades: máquina.proceso el proceso servidor elige una dirección al azar, el cliente debe emitir un paquete especial de localización usar un servidor de nombres; el cliente interroga primero al servidor de nombres
El modelo cliente-servidor Las primitivas de envío y recepción podrán ser: con bloqueo o síncronas sin bloqueo o asíncronas. ¿cómo saber que ya se puede volver a usar el buffer de envío? send con bloqueo hasta que el mensaje se envie send sin bloqueo, con copia del mensaje en buffer interno send sin bloqueo, con interrupción que señaliza que ya se puede usar el buffer
El modelo cliente-servidor Una primitiva típica es receive(addr,&m) ¿qué pasa si el emisor envía la petición antes de que el servidor pueda hacer el receive? probablemente la petición se pierda! Podríamos usar primitiva con almacenamiento en buffer: un buzón El buzón se activa nada más arrancar el servidor. El receive obtiene las peticiones del buzón o bien se bloquea
El modelo cliente-servidor Si las primitivas son fiables no hay ningún problema, pero en la práctica pueden no serlo Una posible solución es que el usuario se encargue de resolver el problema Pero el S.O puede usar reconocimientos automáticamente: kernel cliente servidor kernel 1 2 3 4 kernel cliente servidor kernel 1 2 (respuesta) 3
Llamada a procedimiento remoto (RPC) El modelo cliente-servidor asigna dos primitivas, send y receive, que debemos necesariamente usar para la E/S. A partir de ahí, todo debe construirlo el usuario La llamada a procedimiento remoto se ideó para facilitar la comunicación entre máquinas Un procedimiento en la máquina A llama a un procedimiento en la máquina B A se bloquea hasta que el procedimiento de B termine El programador no se preocupa de los mensajes enviados entre A y B; la llamada a procedimiento remoto debe ser lo más parecida posible a una llamada local
Llamada a procedimiento remoto (RPC) Dificultades para implementar RPC: las máquinas utilizan espacios de direcciones distintos, ¿punteros?, ¿variables globales? la transferencia de parámetros y resultados, ¿son los tipos iguales en ambas máquinas? big endian/litte endian, ASCII/EBCDIC fallo de alguna de las máquinas
Llamada a procedimiento remoto (RPC) count=read(fd, buf, nbytes);
La llamada read ejecuta una rutina especial de biblioteca (stub) que bloquea al cliente y mete los parámetros en mensajes que envia a la máquina remota El stub de la máquina remota desempaqueta el mensaje y ejecuta una llamada read local La respuesta es devuelta en mensajes que desempaqueta el stub emisor y devuelve al que hizo la llamada, desbloqueándolo
Llamada a procedimiento remoto (RPC) La transferencia de parámetros se realiza codificando/decodificando a un formato de tipos prefijado La transferencia de punteros puede hacerse por copia de zonas de memoria, pero en ciertos casos es mucho más difícil
| Página siguiente |