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 anterior | Volver al principio del trabajo | Página siguiente  |