4.- Memoria Compartida Distribuida(MCD)

felicidades a mis compañeros en especial al equipo de humbertina jeje. todos niños la información presentada en este foro esta muy bien desarrollada.

Memoria compartida distribuida
Los sistemas de  memoria compartida distribuida (DSM) representan la creación hibrida de dos tipos de computación paralelos: la memoria distribuida en sistemas multiprocesador y los sistemas distribuidos. Ellos proveen la abstracción de memoria compartida en sistemas con memorias distribuidas físicamente y consecuentemente combinan las mejores características de ambos enfoques. Debido a esto, el concepto de memoria compartida distribuida es reconocido como uno de los enfoques mas atractivos para la creación de sistemas escalables, de alto rendimiento de sistemas multiprocesador.
Memoria compartida basada en páginas
El esquema de DSM propone un espacio de direcciones de memoria virtual que integra la memoria de todas las computadoras del sistema, y su uso se realiza mediante paginación. Las páginas quedan restringidas a estar necesariamente en un único nodo. Cuando un programa intenta acceder a una posición virtual de memoria, se comprueba si esa página se encuentra de forma local. Si no se encuentra, se provoca un fallo de página, y el sistema operativo solicita la página al resto de nodos. El sistema funciona de forma análoga al sistema de memoria virtual tradicional, pero en este caso los fallos de página se propagan al resto de ordenadores, hasta que la petición llega al nodo que tiene la página virtual solicitada en su memoria local. A primera vista este sistema parece más eficiente que el acceso a la memoria virtual en disco, pero en la realidad ha mostrado ser un sistema demasiado lento en ciertas aplicaciones, ya que provoca un tráfico de páginas excesivo.
Una mejora dirigida a mejorar el rendimiento sugiere dividir el espacio de direcciones en una zona local y privada y una zona de memoria compartida, que se usará únicamente por procesos que necesiten compartir datos. Esta abstracción se acerca a la idea de programación mediante la declaración explícita de datos públicos y privados, y minimiza el envío de información, ya que sólo se enviarán los datos que realmente vayan a compartirse.
Memoria compartida basada en objetos
Una alternativa al uso de páginas es tomar el objeto como base de la transferencia de memoria. Aunque el control de la memoria resulta más complejo, el resultado es al mismo tiempo modular y flexible, y la sincronización y el acceso se pueden integrar limpiamente. Otra de las restricciones de este modelo es que todos los accesos a los objetos compartidos han de realizarse mediante llamadas a los métodos de los objetos, con lo que no se admiten programas no modulares y se consideran incompatibles.



MEMORIA COMPARTIDA DISTRIBUIDA EN BASE A PÁGINAS (DISEÑO, RÉPLICA, GRANULADA, CONSISTENCIA, PROPIETARIO, Y COPIAS)

Diseño
De la descripción del sistema DSM-PEPE, es evidente que la especificación de los protocolos que implementan los distintos modelos de consistencia de memoria se encuentra dispersa entre los componentes del sistema. Esto está relacionado con el hecho que los protocolos implementados desencadenan sus acciones de consistencia bajo distintas condiciones. En el caso del protocolo de consistencia secuencial, las acciones de consistencia se desencadenan a partir de faltas de página detectadas por el sistema operativo, y en el caso del protocolo de consistencia de entrada, por acciones de sincronización explícitas dentro del código del usuario.
El hecho que la especificación se encuentre dispersa dificulta tanto la incorporación de nuevos protocolos de consistencia como la modificación de los ya existentes, debido a que los componentes tienen además de su funcionalidad básica responsabilidades que no les corresponden. Por ejemplo, los objetos DSMPage y DSMLock se encargan de ejecutar acciones de consistencia, a pesar que no es función de ellos manejar este tipo de acciones.
Específicamente la clase DSMPage debería encargarse de realizar actualizaciones de las páginas y mantener el estado de ellas; la clase DSMLock debería manejar únicamente acciones de sincronización como el envío y recepción del token de exclusión mutua. Sería deseable con el propósito de tener un mejor diseño que estas clases no incluyeran acciones ligadas a los protocolos de consistencia como ocurre en este momento.
Para mejorar el diseño de este sistema es necesario extraer y luego encapsular la especificación de los protocolos de consistencia de manera que sea el aspecto quien tome las acciones de consistencia necesaria. Más aún, a partir del hecho que los protocolos de consistencia dependiendo de su tipo toman acciones de consistencia en diferentes componentes se propone que cada modelo de consistencia de memoria en DSM-PEPE sea considerado como un aspecto.
A partir del análisis de los protocolos de consistencia de DSM-PEPE ya explicados ejemplificaremos nuestra propuesta, detallando las modificaciones que se deben realizar para conseguir un mejor diseño.
Replica

1.      Replicar los bloques de sólo lectura
2.      Replicar todos los bloques: en este caso se tienen que tomar acciones para mantener la consistencia de los datos.

Granularidad
Los distintos tipos de grafo se diferencian por la granularidad de sus nodos y la información contenida en las aristas. En todos los casos, los nodos del grafo contienen un apuntador a una operación de la representación en WHIRL. A su vez, las operaciones de la representación intermedia también tienen asociado un apuntador que les va a permitir acceder al nodo correspondiente del grafo de dependencias. En el grafo de dependencias entre arrays, los nodos apuntan a operaciones de load y store sobre arrays, mientras que en el grafo de niveles de dependencia, los nodos apuntan a sentencias, que son elementos de mayor granularidad.
Respecto a las aristas, estas van a contener vectores de dependencia en el grafo de dependencias entre arrays o una etiqueta indicando el nivel de la dependencia en el caso del grafo de niveles de dependencia.
La figura muestra de forma esquemática como se guardan los grafos. La estructura de datos que se utiliza es la clase ARRAY DIRECTED GRAPH16, que se declara en /be/com/dep graph.h. El tipo de dato que se utiliza para declarar las aristas es una unión de tres tipos distintos, que son DEPV ARRAY para el grafo de dependencias entre arrays, LEVEL STRUCT para el de niveles de dependencia y DEP STRUCT para el utilizado en generación de código.
La clase DEPV ARRAY contiene una lista de vectores de dependencia, cada uno de ellos de tipo DEPV. Cada dimensión de un vector de dependencia guarda un elemento de tipo DEP, que es un entero de dieciséis bits organizado de la siguiente forma:
Bit 15: indica si la distancia es constante.
Bits 12-14: señalan la dirección de la dependencia.
Bits 0-11: indica la distancia, en caso que esta sea constante, o un límite en caso contrario.

Consistencia
*Un modelo de consistencia de memoria (Mosberger 1993) especifica las garantías de consistencia que un sistema otorga sobre los valores que los procesos leen de los objetos, dado que en realidad acceden a una réplica de cada objeto y que múltiples procesos pueden actualizar los objetos.
*La principal interrogante que se plantea al caracterizar un modelo de consistencia de memoria es: cuándo se realiza  un acceso de lectura sobre una posición de memoria, qué accesos de escritura son candidatos para que sus valores sean proporcionados en la lectura.
*Cualquier lectura realizada antes.
*La ultimo lectura.
*Etc.

Propietario
El modelo de consistencia secuencial dice que todos los nodos deben ver las escrituras sobre una variable en el mismo orden. El protocolo secuencial implementado en DSM-PEPE funciona sobre la base de que en todo momento un nodo es el propietario (owner) de una página y es sólo él quien puede escribir en ella. En caso que alguien más desee escribir en ella, primero debe encontrar al propietario y solicitarle la página, en cuyo caso el nodo receptor pasa a ser el nuevo propietario. La información de los propietarios de cada página se mantiene como un atributo del objeto DSMPage, llamado probOwner, el cual indica quién es su probable propietario.
Las acciones de consistencia se generan en cuatro tipos de eventos, que corresponden a métodos del objeto.
DSMPage: faltas de páginas locales para lectura (ReadFault), faltas de página locales para escritura (WriteFault), faltas de página remotas para lectura (RemoteReadFault), y faltas de página remotas para escritura (RemoteWriteFault). En cada uno de esos casos se toman las acciones necesarias para invalidar páginas, enviar copias actualizadas a quien las pide, y actualizar los propietarios. La figura 1 muestra una descripción parcial de los objetos involucrados con el protocolo de consistencia secuencial.
En el caso de la falta de lectura local, se envía una petición al probable propietario de la página utilizando el atributo probOwner; eventualmente el mensaje llegará al propietario actual, y éste enviará un mensaje con la copia actualizada de la página. En el caso de la falta de escritura local, se realiza el mismo procedimiento para hallar al propietario actual de la página, pero éste junto con enviar la copia actualizada, además invalida su copia local y todas las copias que ha distribuido entre los demás nodos mientras fue propietario, y entrega la propiedad de la página al nodo receptor. Las faltas remotas se utilizan para ubicar al propietario de la página. Cuando llega una falta remota, el nodo evalúa si él es el propietario de la página; si es así, contesta con la acción de copia o invalidación correspondiente, y si no es así, reenvía la petición a quien él cree que es el probable propietario utilizando su atributo probOwner. La recepción de faltas remotas se hace a través de un objeto receptor de mensajes llamado msgMgrThread, el cual transmite el evento de falta de página al objeto DSMPage correspondiente.

Copias
En el caso del protocolo de consistencia secuencial, se propone extraer de la especificación del objeto DSMPage la información relativa al probable propietario de la página y de los nodos que poseen copias de ella, ya que ésta es únicamente utilizada por el protocolo de consistencia secuencial, y extraer del msgMgrThread la funcionalidad relativa al protocolo de consistencia. Esto significa eliminar de la especificación del objeto DSMPage el atributo probOwner, y también los métodos que manejan la consistencia actualmente, ReadFault, WriteFault, RemoteReadFault, y RemoteWriteFault.
El sistema operativo y el objeto msgMgrThread generan los puntos de entrada a las acciones de consistencia. La detección de una falta de página por el sistema operativo o la recepción de un mensaje por el msgMgrThread corresponden a los puntos de unión del aspecto encargado del protocolo de consistencia secuencial con el resto del sistema. El aspecto recibirá el nombre de sequentialAspect. La figura muestra las modificaciones propuestas y los puntos de unión para el aspecto sequentialAspect.
El aspecto sequentialAspect será el encargado de invalidar las páginas y enviar las copias actualizadas cuando reciba un mensaje de falta de página remota y el nodo sea el propietario de la página, o bien de redirigir mensajes de consistencia hacia los probables propietarios de las páginas cuando no lo sea y reciba este mismo mensaje. Además, tendrá que generar mensajes solicitando la página que se requiera cuando se produzca una falta de página local.
Con esto el diseño del objeto DSMPage se hace más cohesionado, ya que ahora contiene sólo la funcionalidad referente a la representación de una página de memoria y el msgMgrThread se encarga sólo de la recepción de mensajes entre los nodos y transmisión de estos mensajes hacia los objetos.

MEMORIA COMPARTIDA DISTRIBUIDA BASADA EN VARIABLES

La DSM basada en paginas toma un espacio de direcciones y permite que las paginas emigren de manera dinámica sobre la red, los procesos tienen acceso a toda la memoria mediante las instrucciones normales de lectura y escritura y no son consientes de las fallas de página en la red. Un método más estructurado consiste en compartir solo ciertas variables estructuradas de datos necesarias para más de un proceso, el problema pasa de realizar la paginación sobre la red a la forma de mantener una base de datos distribuida, en forma duplicada consiste en las variables compartidas, pueden aplicarse varias técnicas que estas conducen con frecuencia a mejoras esenciales al proceso. El uso de variables compartidas controladas de manera individual proporciona una oportunidad para no compartir fácilmente, ejemplos Munin y Midway.
MUNIN
Munin es un sistema DSM que se basa en objetos del software pero que puede colocar un objeto en una página aparte, de modo que el hardware MMU pueda utilizarse para detectar el acceso a los objetos compartidos. El modelo básico de Munin es el de varios procesadores cada uno con espacio de direcciones lineales por pagina, en el que uno o más hilos ejecutan un programa multiprocesador con ligeras modificaciones, el objetivo es tomar los programas multiprocesadores existentes y realizar cambios menores y hacerlos que se ejecuten de manera eficiente en los sistemas con multicomputadoras que utilicen una forma de DSM. Las modificaciones consisten en anotar las declaraciones de variables compartidas con la palabra reservada shred de modo que el compilador las reconozca, puede proporcionar información para permitir el reconocimiento y optimización de ciertos casos especiales.

MEMORIA COMPARTIDA DISTRIBUIDA EN BASE A OBJETOS

Puesto que en muchos lenguajes de programación los datos se encuentran organizados como objetos y no como variables simples, los sistemas de MCD basados en objetos intentan transportar datos por la red utilizando como unidad de manipulación el objeto y no las páginas o las variables.

Los procesos que se ejecutan en los distintos computadores que componen el sistema tienen acceso a un espacio de objetos compartidos, en lugar de a un espacio lineal de direcciones. El sistema es responsable de la ubicación y administración de es- tos objetos compartidos. Un proceso puede invocar métodos de un objeto compartido, independientemente de la ubicación del proceso y del objeto. Los objetos están protegidos por el ocultamiento de información, por lo que los procesos no pueden acceder directamente al estado interno de ningún objeto compartido. Esto facilita algunas optimizaciones dentro del sistema. Por ejemplo, puede relajarse el modelo de consistencia sin que el programador tenga conocimiento alguno. Al igual que en el caso de la granularidad a nivel de variables compartidas, cuando se utiliza el objeto como unidad para compartir es posible eliminar el false sharing.

Además, también en este caso es factible utilizar un protocolo de actualización en vez de uno de invalidación. Sin embargo, quizás la mayor ventaja de este modelo es su modularidad y flexibilidad, a la vez que permite una integración limpia con la sincronización.

La principal desventaja es el aumento en el overhead que se produce por la manipulación aun más indirecta de la memoria. En realidad, este es un problema inherente al uso de objetos.

Un ejemplo de un sistema de MCD basado en objetos es Linda [11], un sistema basado en una memoria compartida altamente estructurada y que es accedida a través de un pequeño conjunto de primitivas que se agregan a lenguajes tradicionales como C y Fortran. El espacio de objetos se llama tuple space, o espacio de tuplas. Los procesos pueden insertar y remover tuplas al espacio, desde cualquier computador.

ADMINISTRADORES DE MEMORIAS EN CLÚSTERS

La operación de clusters requiere de un manejo adecuado de los recursos asociados. Los recursos del cluster deben ser administrados adecuadamente para que el administrador invierta la menor cantidad de tiempo en detectar, investigar y recuperar fallos de hardware y software, y de este modo definir posibles medidas de contingencia y tratar que el sistema esté libre de errores. A su vez, estos pasos permiten la adaptabilidad a los requerimientos y cambios constantes que se presentan en la manipulación de tecnologías cluster, en cuanto se refiere al
hardware, software y al uso de ciertos patrones de diseño.

El administrador de un cluster debe tomar en cuenta algunos aspectos, una vez que se ha completado la instalación de los recursos básicos de hardware y software. Estos aspectos incluyen la configuración e instalación de un sistema de archivos universal, la configuración y administración de recursos mediante herramientas implementadas en software; el monitoreo de sus actividades y el registro de cada uno de los eventos generados por la ejecución de cálculos computacionales.

Varios de los sistemas más importantes para la instalación automática de clusters, incluyen herramientas de monitoreo, administración y registro de eventos mediante paquetes de distribución para sistemas Windows y Linux. Entre estos sistemas están OSCAR y Rocks NPACI; ambos sistemas permiten el uso de herramientas de software que tienen propósitos específicos tales como:

• Definición y administración de nodos.

• Administración de colas por lotes (Batch Queue Management).

• Administración de recursos: grupos NIS (Network Information Service), cuotas de disco y CPU.

• Administración de servicios de resolución de nombres: DNS (Domain Name System para clusters)...

• Registro de usuarios para clusters de dimensiones superiores a los 100 nodos.

• Monitoreo de carga.

La administración de clusters, implica tomar medidas preventivas y planificar tareas. La administración implica los siguientes aspectos:

• Registro de eventos.

• Monitoreo o medida del estado de los recursos del cluster.

• Recuperación ante fallos de hardware, software, incluyendo el sistema de archivos.

• Administración del registro de usuarios y grupos de usuarios, de los servicios del cluster (accounting).

• Planificación de tareas y balanceo de carga.

SAINA YATZIRI GAMA NUÑEZ

SON MUY BUENOS LOS CONCEPTOS DE MIS COMPAÑEROS Y BIEN SU DEFINICION

Mi retroalimentacion es para los compañeros del equipo de abel me parece que su informacion esta muy completa  espero y sigan asi compañeros, felicidades.

att: kassandra

Esta muy bien la informacion que subieron con pañero bolivar creo que esta muy completa su informacion.

Los felicito por sus participaciones !!!

Me es grato apreciar que hayan trabajo de manera colaborativa para poder alcanzar la competencia específica de Unidad. También los felicito por sus réplicas, sobre todo, aquellas que retroalimentan y/o apoyan a otros compañeros entorno a una duda o alguna temática. Y las críticas constructivas también son bienvenidas y merecen todo mi reconocimiento.
Los felicito nuevamente por sus participaciones.

ATTE:

M.C. Edgar Rangel Lugo.