El grado de acoplamiento en un cluster determinará el soporte necesario para implementar el modelo de comunicación, pero éste puede estar basado tanto en memoria compartida como en paso de mensajes. El modelo elegido determina parte de las características del sistema distribuido, pero la distribución física de la memoria queda oculta, salvo a efectos del rendimiento.
Modelos de comunicación.
Una de las tareas mas complejas en S.O.D. es la implementación y uso de memoria compartida, ya que esto nos obliga a "atravesar" las capas de software construyendo un puente de comunicación con una estructura de memoria no monolítica sobre la arquitectura de red. Algunas soluciones son las variables compartidas (similar a variables de entorno), cuyo acceso se sincroniza mediante cerrojos de exclusión mutua u otras primitivas (condicionales, banderas, semáforos ), han sido estudiadas desde hace tiempo y están perfectamente establecidas como paradigma tecnológico; para poder transferirlas se requiere un mecanismo de paso de mensajes, (mediante colas FIFO y buffers), a menudo integrados en el sistema de archivos (por ejemplo mediante pipes de UNIX). El paso de mensajes parece el mecanismo de comunicación natural en sistemas débilmente acoplados, pero al igual que cualquier tecnología tiene pros y contras, en este caso respecto a las alternativas con RPC's (llamada a procedimientos remotos) independientemente de si usa o no variables compartidas; Entonces el costo de recursos para mantener variables compartidas en un ambiente multi-equipos es alto y equivalente al costo de diseñar y operar los algoritmos de paso de mensajes o administrar RPC's, y si se desea restar complejidad a cualquiera de ambos métodos habrá de ser mediante el sacrificio de la eficiencia por la simplicidad.
Comunicación Cliente-Servidor.
Es una arquitectura de paso de mensajes, que puede operar variables compartidasmediante un archivo público de acceso remoto (tipo CGI-BIN o MIME); es una solución muy socorrida pues su propiedad de distribución de trabajo aprovecha la versatilidad de que un servidor puede también ser cliente de otros servidores. El acceso a los terceros recursos se hace mediante el intermedio del servidor, quien se convierte en cliente de otros. Por ejemplo un servidor web puede ser cliente de los servicios DNS, MySQL, POP3, SMTP, pero ser anfitrión de Java, PHP, ASP, HTML, FTP; o por ejemplo un buscador web es servidor de consultas para usuarios pero es cliente de toda la web en dónde hace sus búsquedas. El número de encadenamiento entre nodos cliente-servidor con otros iguales debería ser muy grande pues esto exigiría tareas extra de administración de tráfico, que están contempladas inherentemente en el propio esquema de paso de mensajes. El número de encadenamiento de clientes-servidores se define como Modelo de N capas.
El siguiente diagrama muestra un modelo cliente-servidor de dos capas, el típico esquema deWeb Hosting con varios servidores en una sola máquina, para el servicio HTTP en Internet; los servidores forman una linea frontal en la que si una petición no puede ser atendida, se traslada al servidor contiguo. En el caso de requerirse un servicio de más bajo nivel entonces se pueden agregar capas de servidores que operan detrás de la linea frontal, por ejemplo un PHP o SQL Server. Para esto se usa el modelo común de tres capas, por ejemplo el servidor HTTP-PHP-SQL. según la configuración del software se pueden mover alterar el balance de carga hacia los clientes o hacia el servidor, por lo cual debe entenderse que el Modelo de Balance de Carga entre clientes y servidor es independiente del modelo de N capas. Un Modelo de tres capas puede funcionar de tal manera que la capa intermedia sea la que tiene menos carga de procesamiento, pero tendrá más trabajo de comunicación.
específicos de gestión de los recursos para los que el paso de mensajes resulta adecuado. Un recurso estará a cargo de un proceso gestor, con quien deberá comunicarse cualquier proceso que pretenda acceder a él, siguiendo un esquema cliente-servidor; lo que permite expresar el acceso a servicios mediante un protocolo de petición-respuesta. El modelo cliente-servidor se puede implementar mediante un mecanismo de paso de mensajes específico, como por ejemplo el mecanismo de transporte TCP para HTTP y HTTPS, la Interfaz CGI/BIN o la interfaz de sockets de UNIX para TCP/IP o UDP/IP.
En la tabla siguiente se muestra un resumen de las modalidades más utilizadas en la Comunicación Cliente-Servidor:
Comunicación por RPC'S (Remote Call Procedure)
Para trabajar con procesos distribuidos que necesitan compartir recursos con otros procesos también se han diseñado interfaces que permiten manejar un espacio de direcciones común sobre un sistema de memoria física distribuida: sistemas de memoria compartida distribuida (DSM). La idea es ofrecer a las aplicaciones diseñadas según un modelo de memoria compartida, un soporte para su ejecución en un entorno distribuido.
Con el objetivo de disminuir la diferencia semántica entre programas que usan servicios locales (mediante llamadas al sistema) y programas que usan servicios remotos, se han desarrollado mecanismos que encapsulan los detalles de direccionamiento y sincronización del envío-recepción de la petición y/o respuesta.
Así, en los lenguajes procedurales, las llamadas a procedimientos remotos RPC's (Remote Precedure Call), proporcionan una sintaxis de llamada a función como interfaz para el acceso a servicios. En los lenguajes orientados a objetos, cada recurso es un objeto identificado unívocamente en el sistema distribuido, al que se accede invocando los métodos definidos para esa clase de objeto. El acceso a os objetos se realiza mediante una interfaz de invocación de métodos remotos (por ejemplo, RMI de Java).
La Tabla siguiente resume los mecanismos que implementan los modelos de comunicación sobre arquitecturas de memoria independiente y memoria compartida.
Comunicación basada en paso de mensajes.
El paso de mensajes comprende un conjunto de mecanismos que permiten comunicar procesos mediante un enlace o canal de comunicación, bien directamente, identificando el proceso origen o destino respectivamente en las primitivas de recibir o enviar, bien a través de un buzón, que identifica explícitamente el canal de comunicación. En sistemas tipo UNIX, el mecanismo básico de paso de mensajes dentro de un nodo es el de los pipes.
Para comunicar procesos entre nodos surge el problema del direccionamiento. A este respecto, los sockets de UNIX soportan dos formas de comunicación alternativas: identificando un socket dentro del sistema de archivos (entorno UNIX) o asociando un puerto de comunicación en un nodo concreto (Internet). En este último caso se hace precisa la gestión explícita del direccionamiento.
Aunque el modelo de programación del paso de mensajes para comunicación entre nodos no difiere del de paso de mensajes para comunicación dentro de un nodo, el hecho de tener que confiar en los protocolos de red introduce dependencias derivadas del rendimiento y la fiabilidad del canal de comunicación entre nodos.
Las características principales asociadas a un canal de comunicación son las siguientes:
Modo de sincronización: Por una parte, si el canal de comunicación está ocupado, la primitiva de enviar puede bloquear al proceso hasta que se libere el canal (lo que depende también de si permite buffering o no) y pueda depositar el mensaje (modo bloqueante o síncrono). La alternativa (modo no bloqueante) permite que el proceso continúe aunque el mensaje no se haya podido enviar, transfiriendo a la aplicación la responsabilidad de gestionar la sincronización en el uso del buffer de usuario donde se ubica el mensaje enviado. Estos modos se aplican también a la primitiva de recibir. Los sockets de UNIX son en principio bloqueantes, pero pueden configurarse como no bloqueantes.
Fiabilidad: En lo referente a la fiabilidad de la comunicación, el mecanismo de paso de mensajes depende del soporte que le proporcione la red. Si se implementa sobre un protocolo de transporte seguro, la comunicación se considera fiable, en el sentido de que el emisor puede confiar en que el receptor acabe por recibir el mensaje correctamente o sea informado de lo contrario. Esto es a costa de una cierta sobrecarga por la necesidad que tiene el protocolo de confirmar las recepciones. En cambio, un mecanismo no fiable permitirá una comunicación menos costosa, pero delega en la aplicación la responsabilidad de verificar la corrección de la comunicación. UNIX ofrece dos formas de comunicación:
Con sockets: comunicación orientada a conexión, basada en TCP/IP, fiable.
Comunicación por datagramas, basada en UDP/IP, no fiable.
Comunicación entre grupos de procesos.
En sistemas distribuidos es de gran interés el soporte de primitivas de paso de mensajes de amplia cardinalidad es decir de 1:N, ya que existe la necesidad de intercomunicar a los procesos con otros, ya sea replicados o similares, ya sean procesos anfitriones o clientes de otros. El concepto de grupos de procesos que se comunican entre sí crea la necesidad de un gestor, cuyas funciones son similares a aquellas de las tareas de Control de Acceso a Usuarios.
Una de las formas de comunicación con cardinalidad múltiple es el broadcast o difusión; permite enviar un mensaje a todas las direcciones accesibles por el emisor, y se usa en redes locales. Un caso particular de broadcast, el multicast, permite seleccionar un subconjunto de direcciones a las que enviar el mensaje. El soporte para multicast es muy útil en sistemas replicados, como se verá más adelante. Como ejemplo, el protocolo IP reserva un conjunto de direcciones para multicast.
El estándard POSIX significa Interfaz de Sistema Portable tipo UNIX, (Portable OperatingSystem Interface UniX type) y establece una familia de estándares de llamadas al sistema operativo definidos por el IEEE y especificados formalmente en el IEEE 1003. Persiguen generalizar las interfaces de los sistemas operativos para que una misma aplicación pueda ejecutarse en distintas plataformas. Estos estándares surgieron de un proyecto de normalización de las API y describen un conjunto de interfaces de aplicación adaptables a una gran variedad de implementaciones de sistemas operativos. Los grupos de procesos que se diseñan bajo una especificación POSIX trabajan en función de señales. Una señal es una instrucción de alto nivel que se dirige a un grupo de procesos, la razón de esto es que a diferencia de un S.O. centralizado, en el que se ha de multiplexar (Intercalar) la ejecución de varios procesos, aquí la distribución de un proceso obedece a una necesidad de terminarlo en menor tiempo dividiéndolo en tareas más pequeñas, todas idénticas repartidas por la red; de tal manera que es fácil entender las funciones del administrador de grupos de procesos pues es más simple replicar un proceso idéntico muchas veces, que manejar un conjunto diverso de procesos.
Los grupos de procesos están a su vez agrupados en sesiones, que residen en una capa de software que se encarga de administrarlos de la misma forma en que se administran las sesiones de usuarios. Los grupos de procesos no pueden migrar de una sesión a otra, y un proceso sólo puede crear nuevos grupos de procesos que pertenezcan a la misma sesión a la que pertenece. Un proceso únicamente puede unirse a un grupo de procesos que esté en su misma sesión. Nuevas imágenes de proceso creadas por una llamada a una función de la familia exec heredarán el grupo de proceso y la sesión de la imagen original.
Un segundo uso no relacionado del término grupo de procesos aparece en el contexto desincronía virtual, un modelo de ejecución distribuido en el que grupos de procesos corriendo en diferentes máquinas se asocian para compartir eventos, replicar datos o coordinar acciones, no tanto basado en un reloj de tiempo real sino en un esquema de eventos disparadores.
El desarrollo de Internet está forzando la evolución de los protocolos de nivel de red. Así, el protocolo IPv4, cuyas direcciones de 32 bits suponen un problema de escalabilidad, está dejando paso al IPv6, que especifica direcciones de 128 bits. Internet y los nuevos paradigmas de cómputo están imponiendo sus estilos de comunicación. De este modo, se aprecia una tendencia general a la utilización de HTTP como protocolo de acceso a servicios, como evolución del esquema RPC clásico. Por otra parte, la distribución de servicios ha provocado una evolución del esquema cliente-servidor clásico hacia estructuras peer-to-peer, donde los roles de cliente y servidor son intercambiables. En tales sistemas, habitualmente dinámicos, los nodos indistintamente ofrecen y solicitan servicios, y eventualmente cooperan en la búsqueda de servicios y en el encaminamiento de peticiones.
Podemos resumir la Disposiciones Generales de la comunicación:
Utilizando el servicio básico de acceso al medio, el cliente debe localizar e iniciar la comunicación con el servidor.
No se utiliza la metodología de compartición de archivos, ya que todos los accesos a la información se llevan a cabo a través de servicios de datos (paquetes o datagramas).
Los programas de manejo y control de información solo se envían y reciben los resultados de las operaciones.
Debido a la flexibilidad de establecer sesiones con múltiples servidores y manejo de información en varias bases de datos (en sitios remotos es requerido el uso de estilos transaccionales y cooperativos).
Tolerancia a fallos.
La tolerancia a fallas es considerada la principal característica que debe de tener un sistema distribuido para alcanzar el principio de transparencia. Para lograr la tolerancia a fallos se necesita de una buena comunicación entre procesos distribuidos y sobre todo de una correcta coordinación entre ellos.
Un Sistema Distribuido en base a la coordinación de sus procesos puede ser:
Asíncrono: no hay coordinación en el tiempo.
Síncrono: se suponen límites máximos para el retraso de mensajes.
El primer factor a tomar en cuenta es que el canal de comunicación este libre de errores (canal confiable). Para garantizar que el canal sea confiable se debe tener QoS (Calidad en el Servicio) que implica realizar lo siguiente:
- Retransmisión de mensajes.
- Establecer redundancia de canales.
- Poner límite al tiempo de entrega de un paquete en lapso especificado.
En general, se considera que los canales de comunicación son fiables y que cuando falla la comunicación es debido a la caída del proceso, sin embargo algunos fallos en el funcionamiento de un Sistema Distribuido pueden originarse por:
- Especificaciones impropias o con errores.
- Diseño deficiente del del software o el hardware.
- Deterioros o averías en hardware.
Prevención en la Tolerancia a Fallos
Existen dos formas de aumentar la fiabilidad de un sistema.
1. Prevención de fallos: Se trata de evitar que se implementen sistemas que pueden introducir fallos.
2. Tolerancia a fallos: Se trata de conseguir que el sistema continué funcionando correctamente aunque se presenten algunos fallos.
Un sistema que sea tolerante a fallos debería tener disponibilidad, confiabilidad, seguridad y con un programa de Mantenimiento.
Disponibilidad: La cualidad de un sistema de estar preparado en todo momento para operar.
Confiabilidad: La garantía de que el Sistema puede llevar a cabo su trabajo con muy bajas probabilidades de una caída repentina.
Seguridad: La característica de que el Sistema puede recuperarse o repararse a sí mismo en caso de presentarse algún tipo de fallo.
Mantenimiento: Se refiere a que el sistema puede ser remplazado o reparado rápidamente mediante los lineamientos un programa preventivo y un plan de contingencia..
En el aspecto preventivo deben tomarse en cuenta que se pueden presentar Fallos Transitorios (se presentan una vez y al volver a intentar la operación ya no ocurren) , Intermitentes (se presentan de forma cíclica o al ejecutar ciertas operaciones) y Permanentes (no se resuelven hasta remplazar lo dañado). La orientación del mantenimiento debe definir cual de estos escenarios es el que se presenta; de hecho el primero es el más difícil de atender pues el primer paso para reparar una falla es aislarla e identificarla.
Una buena estrategia comienza con la clasificación e identificación del universo de fallas, ya que cada una de ellas debe tener un plan emergente en consecuencia, la siguiente figura resume un esquema de este tipo:
El aspecto fundamental es identificar las causas de la falla, que es la labor mas complicada, sobre todo en el entendido de que no se debe interrumpir el servicio. Nuevamente, los fallos que no presentan un patrón repetitivo son los más dificiles de identificar y por lo tanto de resolver. La experiencia y el hecho de conocer a detalle el sistema funcionando por largo tiempo pueden ayudar en este respecto.
Una de las acciones necesarias se conoce como enmascaramiento de errores por redundancia, que consiste en ocultarlos a los procesos no locales por medio de:
a) Redundancia de Tiempo.
b) Redundancia de Información
c) Redundancia física.
Todos estos significan duplicar el recurso correspondiente, de tal manera que siempre haya un remplazo disponible, un mecanismo de corrección de errores en datos, y un esquema de reintentos de operaciones; la estrategia resultante se establece bajo la premisa de que es inevitable que aparezcan fallos, sobre todo en comunicaciones. De tal suerte los mecanismos de checksum, paridad etc. son muy socorridos para operar el ambiente distribuido.
Otro punto clave es el uso de Grupos de Procesos, que entre otras cosas facilita la comunicación con múltiples entidades remotas, así es más fácil el direccionamiento por grupos que por entidades individuales; especialmente en el ámbito de fallos en procesos, es importante comunicarse con la entidad donde ocurre el fallo, pero también el notificar a las otras entidades que comparten el recurso que falla. Los grupos pueden dar tratamiento a los errores de forma cooperativa o mediante una jerarquía que delimita quienes participan en ello, las soluciones generalmente tienen efectos colaterales, por ejemplo las jerarquías de procesos pueden generar procesos huérfanos, o las cooperativas pueden ser ineficientes si la dispersión aumenta.
Fallos en sistemas cliente-servidor.
En este esquema la capa de transporte se encarga de los fallos en comunicaciones, sin embargo si se usan datagramas en vez de paquetes, es la aplicación la que tendrá que encargarse de ordenar dichos datagramas fuera de secuencia, solicitar su retransmisión y/o restablecer los enlaces. La capa de transporte por sí misma otorga el concepto de Calidad en el Servicio, (QoS) pero no es una solución definitiva para todos los casos.
Fallos en sistemas con RPC.
Pueden presentarse varias fallas, que el cliente no encuentre al servidor, que la petición del cliente se pierda dentro del servidor o en la red , que el servidor se caiga al procesar un mensaje, que la respuesta del servidor a una petición se pierda o que el cliente haga crash al recibir un mensaje. La responsabilidad principal en este tema es la de restablecer y detener procesos para rebootear las maquinas, lo cual puede implicar que no se restablezcan o no se detengan ciertos procesos concurrentes. Nuevamente, lo importante es el plan de acción del sistema y la detección del origen del problema, ya que de ahi surge el mecanismo de restablecimiento del fallo.
Errores Parciales vs. Errores graves.
Una característica de los S.O. distribuidos que los difiere de los sistemas centralizados es la noción de errores parciales. Un error parcial es cuando algún componente del sistema falla, lo cual puede puede afectar algunos otros componentes dentro de la red pero otros pueden seguir continuando sin ningún problema. EL secreto de la buena operación es recuperar el fallo sin interrupción del servicio o afectación del rendimiento global, hecho que depende a su vez del tipo de fallo, consideremos los siguientes:
Falla de procesos: La ejecución arroja un estado incorrecto, los procesos provocan que el sistema se desvíe de las especificaciones y el proceso con fallo pueda suspenderse momentáneamente.
-Falla de sistema: Ocurre por el algún desorden en el software y problemas del HW (como errores de CPU, falla en la memoria principal, falla de energía, etc.)
En caso de una falla de este tipo el sistema es detenido y reiniciado a un estado correcto, no obstante que es un error generalizado no es tan grave, pero vale la pena documentarlo.
-Falla de amnesia: Ocurre cuando se reinicia el sistema a un estado predefinido, no depende del estado del sistema antes de la falla sino de una mala calendarización. Tampoco es grave.
-Falla de Pausa: Ocurre cuando se reinicia el sistema al mismo estado en que se encontraba antes de la falla. Tampoco es grave.
-Falla en medio de almacenamiento secundarios: Se dice que ocurre una falla de este tipo cuando los datos almacenados no pueden ser accedidos (cualquiera de sus partes o en su totalidad) entonces buscamos el restablecimiento por redundancia. Nótese que no obstante la naturaleza crítica de los fallos mencionados, su efecto en el sistema en general es menos severo por virtud de la distribución.
RECUPERACIÓN DE ERRORES
Una forma prospectiva de trabajar con los errores es considerar que un error es un estado del sistema que es distinto a los valores esperados, de tal suerte que la recuperación de una falla se aborda como un proceso de recuperación de estados hasta un estado libre de error, puede ser previo o posterior.
Hay dos enfoques para hacer lo anterior:
1- Si la naturaleza del error y los daños causados pueden ser completamente calculados, entonces es posible remover esos errores del estado del proceso (o sistema) y habilitar el movimiento hacia adelante del proceso a un estado libre de error. Esta técnica es conocida como recuperación hacia adelante.
2- Si no es posible prever la naturaleza de las fallas y remover todos los errores en el estado del proceso (o sistema), entonces el estado del proceso puede ser restaurado a un estado previo libre de error. Esta técnica es conocida como recuperación hacia atrás.
La recuperación hacia adelante significa cercenar el fallo, y soslayarlo, de tal suerte que se asume la pérdida del tiempo de procesamiento y los recursos involucrados. En cambio, en la recuperación hacia atrás, el proceso con revertido a un estado previo con la esperanza de que ese estado previo esté libre de errores.
Hay dos formas de implementar una recuperación de error hacia atrás: el enfoque basado en la operación y el enfoque basado en estado. Supongamos que tenemos un sistema modelo, que consiste de una máquina simple. Asumimos que la máquina está conectada a un sistema de almacenamiento secundario y a un sistema de almacenamiento estable que no pierde datos en caso de falla. El almacenamiento estable es usado para almacenar un registro de las transacciones y puntos de recuperación. En comparación al almacenamiento secundario, el almacenamiento estable es mucho más seguro, pero el almacenamiento secundario trabaja contínuamente.
a) Enfoque basado en la operación.-
Aquí, todas las modificaciones que se hacen al estado de un proceso son registradas con suficiente detalle; para revertir el proceso a un estado previo, se procesan las transacciones de este registro pero marcha atrás.
b) Enfoque basado en estado .-
El estado completo de un proceso es guardado en una instancia llamada punto de restauración o verificación y su recuperación involucra reiniciar la ejecución del proceso en alguno de esos puntos. Establecer esta instancia se conoce como tomar un punto de verificación. El punto de restauración es entonces también un punto de revisión.
Al proceso de restauración de un proceso a un estado anterior se le refiere como rolar al proceso hacia atrás y al proceso de reiniciar la ejecución en un estado se le conoce como transición forzada. Ambos métodos significan el consumo de tiempo de CPU y retardan la terminación del proceso, mas es preferible retroceder el proceso que cancelarlo. Por ello se acostumbra establecer muchos puntos de revisión.
No hay comentarios:
Publicar un comentario