Refinamientos de Protocolos de Consistencia de Memoria en Ambientes de Memoria Compartida Distribuida

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR Ingeniería de la Computación Refinamientos de Protocolos de Consistencia de Memoria en Ambientes de Memoria Compartida Distribuida por Rafael Chacón, Jesús Federico y David Zaragoza Proyecto de Grado Presentado ante la Ilustre Universidad Simón Bolívar como Requisito Parcial para Optar al Título de Ingeniero en Computación Sartenejas, Septiembre del 2008

2

3 Refinamientos de Protocolos de Consistencia de Memoria en Ambientes de Memoria Compartida Distribuida por Rafael Chacón, Jesús Federico y David Zaragoza Resumen Un sistema con memoria compartida distribuida (MCD) permite ejecutar en plataformas con memoria distribuida aplicaciones multihilos y multiprocesos cuya comunicación es a través de memoria compartida. Un sistema con MCD debe proveer protocolos que garanticen la consistencia de la memoria en todo el sistema. Esta investigación estudia la factibilidad de mejorar el desempeño de aplicaciones que se ejecuten en sistemas con MCD. Se obtuvo como resultado la implementación de un protocolo de consistencia de memoria relajado utilizando el modelo Release Consistency, con un algoritmo de múltiples-lectores/múltiples-escritores y una política de actualización adaptativa al momento de escritura. El protocolo se implementa sobre el sistema con MCD Kerrighed y fue denominado Kerrighed Release Consistency (KRC). Esta nueva versión requiere menos comunicación entre los nodos del cluster que la original y consigue un mejor desempeño. Las aplicaciones que utilicen memoria compartida pueden aprovechar los beneficios de KRC sin necesidad de ser modificadas. Se evaluó el impacto de KRC al comparar su rendimiento con respecto a la versión original del protocolo. Para esto se ejecutaron tres aplicaciones y se encontró que en dos de éstas el rendimiento mejoró en más de 100 %. En general, se observa que para aumentar el desempeño de sistemas con MCD, la mejor alternativa es utilizar protocolos que posean un modelo de consistencia de memoria relajado. iii

4 Índice general Resumen II 1. Introducción Motivación Justificación Objetivos Presentación del Documento Consistencia de Memoria Compartida Distribuida y Desarrollo en el Kernel de Linux Computación de Alto Rendimiento Clusters Middlewares Sistema de Imagen Único (Single System Image, SSI) Memoria Compartida Distribuida (MCD) Modelos de Consistencia de Memoria Consistencia Estricta Consistencia Secuencial Consistencia Durante Liberación (Release Consistency, RC) Consistencia Durante Liberación Perezosa (Lazy Release Consistency, LRC) Algoritmos de MCD Lector Único/Escritor Único Múltiples Lectores/Escritor Único Múltiples Lectores/Múltiples Escritores Implementaciones de Memoria Compartida Distribuida Basadas en Software IVY Munin TreadMarks Kerrighed Otros Sistemas con MCD Programación a Nivel del Sistema Operativo Linux Kernel de Linux Diseños del Kernel Llamadas al Sistema Módulos del Kernel iv

5 2.7. Comunicación entre Procesos Comunicación Transparente entre Procesos Llamadas a Procedimientos Remotos Kerrighed: Arquitectura y Fundamentos Arquitectura de Kerrighed Módulos de Kerrighed Kernel Distributed Data Manager (kddm) Componentes del kddm Objetos Conjuntos Namespaces IO Linkers Funciones de Manipulación de Objetos Coherencia y Replicación de Objetos Objetos y Coherencia Kerrighed Release Consistency: Diseño y Arquitectura de la Implementación Elección del Protocolo: Modelo de Consistencia, Algoritmo y Política Visión Preliminar de la Implementación Planteamiento de RC en el Kernel Módulos Modificados en Kerrighed Implementación de Kerrighed Release Consistency, KRC Acquire Región Crítica Release Estado Final del Protocolo en Kerrighed Funciones de Manipulación Coherencia y Replicación Resultados Experimentales Escenario de las Pruebas Descripción de las Aplicaciones de Prueba Cálculo de π Usando el Método de Monte Carlo Integración Mediante Sumas de Riemann Multiplicación de Matrices en Paralelo con Memoria Compartida Pruebas Funcionales Resultados Experimentales Cálculo de π Integración con Sumas de Riemann Multiplicación de Matrices Análisis de los Resultados Conclusiones y Recomendaciones v

6 Bibliografía A. Estados de Objeto en KRC A.1. Definiciones Preliminares A.2. Lista de Estados B. Código Fuente de las Pruebas B.1. Cálculo de π Usando el Método de Monte Carlo B.2. Integración Mediante Sumas de Riemann B.3. Multiplicación de Matrices en Paralelo con Memoria Compartida C. Manual de Referencia C.1. Instalación de KRC C.1.1. Pre-requisitos C.1.2. Configuración C.1.3. Opciones del Kernel C.1.4. Configuración de Kerrighed C.1.5. Configuración avanzada C.1.6. Opciones genéricas de configuración C.1.7. Opciones específicas de Kerrighed C.2. Usando KRC C.2.1. Activando/Desactivando los servicios de Kerrighed C.3. Iniciando y Deteniendo el cluster vi

7 Índice de cuadros 2.1. Características principales de las implementaciones de los sistemas con MCD Tipos de comunicación entre procesos soportados por Linux Ejemplo del funcionamiento del protocolo de consistencia en Kerrighed con tres nodos Tiempo promedio de ejecución en pruebas de cálculo de π Tráfico promedio en pruebas de cálculo de π Tiempo promedio en pruebas de cálculo de integrales Tráfico promedio en pruebas de cálculo de integrales Tiempo promedio en pruebas de multiplicación de matrices Tráfico promedio en pruebas de multiplicación de matrices vii

8 Índice de figuras 2.1. Arquitectura general de un cluster Estructura del espacio de memoria global de un sistema con MCD Categorización de los accesos a memoria Ejemplo de Release Consistency Ejemplo Lazy Release Consistency Estructura general de Kerrighed Arquitectura de Kerrighed IO Linkers de Kerrighed Diagrama de estados del protocolo de coherencia en Kerrighed Esquema general de SHM en Kerrighed Analogía Acquire/Release y locks sobre un semáforo Módulos modificados en Kerrighed Fases de RC en Kerrighed Ejemplo de acquire en KRC Creación de un gemelo en KRC Ejemplo de release en KRC Mensaje de actualización creado en KRC Diagrama de estados del protocolo de coherencia KRC Ejemplificación de dos procesos escribiendo datos disjuntos sobre una página viii

9 Capítulo 1 Introducción 1.1. Motivación El área de la computación distribuida siempre ha sido de gran importancia dentro de la ciencia de la computación. Más aún, gracias a la evolución de las redes de alta velocidad, es notable cómo el desarrollo de clusters computacionales cada día es un área que toma mayor interés en ambientes de investigación y producción [Raj07]. En el presente se tienen grandes experiencias exitosas de clusters y computación paralela [LLFM08]. Sin embargo, diseñar y escribir aplicaciones paralelas para ser ejecutadas en clusters es una tarea que presenta dificultades [MVL + 03]. Dejando a un lado los problemas que presenta el desarrollo de aplicaciones paralelas, sería de gran utilidad contar con sistemas que abstraigan de los programadores todo el ambiente distribuido y que éstos puedan diseñar sus aplicaciones para que se ejecuten en cualquier computador. Un sistema con un modelo de memoria compartida crea un espacio de memoria virtual global accesible por todos los procesadores, ofreciendo una forma simple de compartir los datos. La facilidad de programación y la portabilidad de estos sistemas los hacen atractivos en relación al costo de desarrollo de software paralelo. Sin embargo su escalabilidad es limitada, especialmente, por el alto costo del hardware. Por otro lado, los sistemas de memoria distribuida, que consisten en múltiples e independientes nodos con memoria local conectados a través de una red, son escalables por naturaleza, permitiendo 1

10 1.2. JUSTIFICACIÓN 2 una capacidad de cómputo y almacenamiento elevada. Este modelo implica que la comunicación entre los procesos de distintos nodos se realice a través de un modelo de pase de mensajes (message-passing), por ejemplo Message Passing Interface MPI [GLS99]. Dado que el programador es el responsable del manejo de la comunicación a través de todo el sistema, este modelo presenta una complejidad mayor de programación [PTM96]. El modelo de memoria compartida distribuida (MCD) combina las ventajas de los modelos anteriormente descritos [Lo94, PTM95]. Los sistemas con MCD implementan de forma lógica el modelo de memoria compartida en un sistema de memoria distribuida, ocultando el mecanismo de comunicación remota al programador y preservando la facilidad y portabilidad de los sistemas de memoria compartida. Al estar la memoria distribuida en los sistemas con MCD, es necesario garantizar de alguna forma que la memoria se encuentra en un estado consistente para todos los nodos que forman parte del sistema, esto se logra mediante un protocolo de coherencia de memoria. El protocolo de consistencia es un factor clave del sistema MCD, ya que define las reglas de comportamiento de la memoria y tiene un impacto en el rendimiento de las aplicaciones. Proponer mejoras a los sistemas con MCD haciéndolos más eficientes, transparentes y veloces, puede hacer que éstos se consideren en mayor medida como una alternativa viable para la computación paralela de alto rendimiento Justificación Es observable la limitación que presentan los sistemas distribuidos que no poseen soporte de MCD para ejecutar aplicaciones que no fueron diseñadas para ambientes distribuidos. De forma concreta, aplicaciones que explotan la comunicación por medio de memoria compartida (i.e aplicaciones multihilos, Shared Memory (SHM)) no pueden aprovechar la potencialidad de este tipo de sistemas. Los

11 1.2. JUSTIFICACIÓN 3 ambientes con MCD proveen una visión única de la memoria en sistemas multiprocesadores de memoria distribuida, permitiendo que aplicaciones de memoria compartida puedan ser ejecutadas de forma transparente en un sistema distribuido. Los sistemas con MCD se pueden implementar bajo dos enfoques: utilizando una plataforma que provea el ambiente mediante hardware o a nivel de software. En el caso de las implementaciones con software, se observan dos tipos de soluciones: en espacio de usuario a través de librerías o en espacio del kernel con extensiones al mismo. Para garantizar que el modelo de memoria compartida se lleve a un espacio distribuido de forma correcta, se debe asegurar que la visión de la memoria es la misma independientemente del nodo en que se observe, introduciendo el uso de protocolos de consistencia de memoria. Implementar servicios distribuidos que sean completamente transparentes y genéricos para clusters, es una tarea compleja para los desarrolladores del kernel. Alternativas más flexibles usualmente son preferidas, como por ejemplo, librerías en el espacio de usuario. En consecuencia, se tiene la desventaja que se requieren recompilar las aplicaciones para utilizar este tipo de soluciones. Sin embargo, muchas aplicaciones están fundamentalmente basadas en estándares tales como POSIX o System V de Unix, haciendo que la recompilación no sea posible en algunos casos; en particular para las aplicaciones legadas o propietarias. Más aún, es posible que no se cuente con el código fuente de la aplicación, siendo la recompilación una opción no viable. Para tales casos, los servicios distribuidos tienen que ser perfectamente transparentes, siendo las extensiones al kernel la única alternativa viable. De acuerdo con [ACD + 99], es notable como los protocolos de consistencia tienen un impacto distinto en el desempeño, dependiendo del tipo de aplicaciones que se ejecuten dentro de un sistema con MCD. Es por esto que en esta investigación se buscarán e implementarán alternativas de protocolos de consistencia adaptativos, en algún sistema con MCD existente, esperando mejorar su rendimiento.

12 1.3. OBJETIVOS Objetivos El objetivo primordial de la investigación es buscar e implementar una solución adaptativa para un protocolo de consistencia de memoria en sistemas con MCD. En primera instancia se desea analizar los distintos sistemas con memoria compartida distribuida que existen en la actualidad. Basados en estos resultados se implementará un protocolo que se permita adaptarse dinámicamente a las aplicaciones que se ejecuten. Se desea que el protocolo de consistencia de memoria a implementar use técnicas para detectar patrones de acceso a la memoria en las aplicaciones. Así, se podrán hacer ajustes dinámicos al funcionamiento del protocolo, adaptándose a la aplicación para obtener un mayor rendimiento. Se buscará que el uso del protocolo sea transparente a los usuarios del sistema. De esta forma se garantiza que los programas que existan para ser ejecutados en sistemas operativos corrientes se puedan ejecutar sin necesidad de adaptaciones Presentación del Documento En el capítulo 2 se definen varios conceptos relacionados con sistemas con MCD, protocolos de consistencia de memoria e implementaciones que existen en la actualidad, también se definen conceptos generales acerca del kernel de Linux. En el capítulo 3 se explica el sistema con MCD Kerrighed, dando detalles de su arquitectura e implementación. En el capítulo 4 se especifica la arquitectura e implementación de la solución propuesta. En el capítulo 5 se presentan los resultados experimentales de la aplicación con un conjunto de pruebas funcionales que garantizan la correctitud y mejoras de desempeño de la implementación desarrollada. Finalmente, en el capítulo 6 se presentan las conclusiones de la investigación y una serie de recomendaciones para trabajos futuros.

13 Capítulo 2 Consistencia de Memoria Compartida Distribuida y Desarrollo en el Kernel de Linux En este capítulo se presentan los conocimientos fundamentales que permitirán el posterior entendimiento de la implementación y decisiones de diseño del protocolo producto de esta investigación. Se muestran conceptos relativos a la computación de alto rendimiento (High Performance Computing, HPC), explicando las distintas vertientes que se han tomado en este campo con respecto a los modelos de la memoria en estos ambientes. La primera sección de este capítulo presenta al área de la computación de alto rendimiento. El estudio actual en este campo está enfocado en dos ramas principales: soluciones mediante el hardware o el software. Para esta investigación las soluciones a través de hardware están fuera de alcance, por lo tanto sólo serán consideradas las soluciones basadas en software. Finalmente y en otra dirección, la sección final de este capítulo englobará términos y conceptos pertinentes al desarrollo del kernel de Linux Computación de Alto Rendimiento Clusters Un cluster computacional es un conjunto de computadoras independientes e interconectadas trabajando juntas como si fueran un solo recurso, permitiendo procesamiento paralelo o distribuido [Buy99]. 5

14 2.1. COMPUTACIÓN DE ALTO RENDIMIENTO 6 Este tipo de sistema provee una alternativa de multiprocesadores de bajo costo [Vre02]. Usualmente en un cluster todos los componentes y subsistemas están supervisados bajo un solo dominio administrativo, residiendo en un mismo lugar físico y manejado como si fuera un solo sistema de computación. Es importante tener claro que los componentes del cluster pueden trabajar como un único recurso integrado de cómputo u operar como computadores individuales. Los nodos del cluster son computadoras corrientes, como cualquiera de uso personal, capaces de funcionar de forma independiente. Los nodos pueden incorporar un único microprocesador o múltiples microprocesadores en un multiprocesador simétrico (Symmetric Multiprocessor, SMP) [Ste01], y están interconectados a través de redes de alta velocidad. Según Buyya [Buy99] la arquitectura general de un cluster es como se muestra en la figura 2.1. Figura 2.1: Arquitectura general de un cluster Cuando el cluster está conformado por hardware heterogéneo surgen problemas de comunicación entre sus nodos. El ejemplo típico es el orden de interpretación de los bytes durante una conversión

15 2.1. COMPUTACIÓN DE ALTO RENDIMIENTO 7 de valores numéricos entre nodos (Little-endian, Big-endian) [BA01]. Es por esto que es necesario contar con plataformas intermedias de software que hagan posible un funcionamiento coherente entre los nodos. Dicha plataforma se denomina Middleware y se describe en la sección Middlewares Un Middleware es un software de conexión que consiste en un conjunto de servicios que permiten que múltiples procesos que se están ejecutando en una o más computadoras interactúen a través de una red [Ber96]. El propósito de un middleware es proveer servicios para las aplicaciones que se ejecutan en un ambiente distribuido heterogéneo [BA01] Sistema de Imagen Único (Single System Image, SSI) Según [S.94], un Sistema de Imagen Única (Single System Image, SSI ) puede ser definido como un sistema distribuido que crea la ilusión que un conjunto de computadoras es un solo sistema. Un SSI es un sistema que tiene la propiedad de esconder la naturaleza heterogénea y distribuida de los recursos disponibles, y presentarlos a los usuarios y aplicaciones como un recurso unificado de cómputo. Un SSI puede ser construido de diversas maneras, desde suministrarlo por extensiones del hardware, hasta soluciones que implican mecanismos de software [BCJ01]. SSI significa que los usuarios poseen una visión global de los recursos disponibles ignorando en que nodo se encuentran físicamente dichos recursos. Más aún, un SSI asegura que el sistema será tolerante a fallos y que gestionará globalmente los recursos [BCJ01]. Según [Buy99, Pfi98, HJC + 99, PW86], los objetivos de diseño para un sistema cluster basado en SSI son: Manejo completo y transparencia total de los recursos. Rendimiento escalable.

16 2.1. COMPUTACIÓN DE ALTO RENDIMIENTO 8 Alta disponibilidad del sistema para soportar las aplicaciones de los usuarios. Los servicios clave que proporciona un cluster con SSI son los siguientes [Buy99, HJC + 99, HX98]: Punto único de acceso: Un usuario puede conectarse al cluster como un host virtual, a pesar de que el recurso posea múltiples nodos físicos. El sistema transparentemente distribuye las peticiones de conexión entre los distintos nodos para hacer balance de carga y proveer tolerancia a fallas. Interfaz de usuario única: El usuario posee la capacidad de utilizar el cluster a través de una interfaz única que deberá tener la misma apariencia que la disponible es una estación de trabajo corriente. Espacio de proceso único: Sin importar el nodo en que residan los procesos de los usuarios, éstos deben tener identificador único en todo el cluster. Además, los procesos deben poder comunicarse con otros procesos (a través de señales y pipes) en un nodo remoto. El cluster debe soportar un manejo global de los procesos y comportarse como si se ejecutaran en una computadora individual. Espacio de memoria único: Los usuarios deben tener la ilusión de una memoria principal centralizada, que en realidad puede ser un conjunto de memorias locales distribuidas. Esto puede lograrse a través de sistemas de memoria compartida distribuida, como se explicará más a fondo en la siguiente sección. Otro enfoque es dejarle la tarea al compilador y que éste distribuya las estructuras de datos de la aplicación a lo largo de los nodos. Sin embargo, es un desafío desarrollar esquemas de memoria unificados de forma eficiente e independiente de la plataforma.

17 2.2. MEMORIA COMPARTIDA DISTRIBUIDA (MCD) 9 Espacio único de entrada y salida (E/S): Cualquier nodo debe poder realizar operaciones de E/S en dispositivos periféricos o discos localizados remotamente. Puntos de control (Checkpointing) y migración de procesos: Los puntos de control son un mecanismo de software que periódicamente almacenan el estado del proceso y los resultados intermedios del cómputo en memoria principal o en disco, permitiendo revertir y recuperarse ante fallas eventuales. Por otro lado, los puntos de control son útiles para la migración de procesos y son necesarios al momento de realizar balance de carga dinámico en los nodos del cluster. Otros servicios: Controlar y monitorizar de forma unificada el cluster, un planificador de tareas global, una red virtual unificada y un servicio que suministre un sistema de archivos unificado de forma transparente Memoria Compartida Distribuida (MCD) El sistema más eficiente y ampliamente usado en paradigmas de memoria distribuida es el modelo de pase de mensajes [GLS99]. Sin embargo, en comparación con los sistemas de programación de memoria compartida usuales (e.g hilos, pipes, Shared Memory de System V ), este modelo presenta grandes complejidades a los desarrolladores de las aplicaciones. Los sistemas de memoria compartida presentan un modelo de programación simple y general, pero no son altamente escalables por limitaciones de hardware. Una solución alternativa es construir sistemas con memoria compartida sobre ambientes de memoria distribuida [Buy99]. Los sistemas con MCD crean un espacio de memoria virtual global, accesible por todos los nodos de un cluster, conservando las facilidades que ofrece el modelo de memoria

18 2.2. MEMORIA COMPARTIDA DISTRIBUIDA (MCD) 10 compartida, pero a nivel distribuido. Los nodos pertenecientes a un sistema con MCD comparten parte de su memoria física local para crear una correspondencia parcial o total en el espacio de direcciones global del sistema, tal como se muestra en la figura 2.2. Figura 2.2: Estructura del espacio de memoria global de un sistema con MCD En vista que los sistemas con MCD esconden los mecanismos de comunicación al programador, el costo y complejidad del desarrollo de las aplicaciones paralelas es menor que en los modelos de memoria distribuida convencionales. Además, los sistemas con MCD heredan la escalabilidad de los sistemas distribuidos, convirtiéndolos en una alternativa viable para construir sistemas de multiprocesadores eficientes a gran escala. Las investigaciones sobre sistemas con MCD se centran en el desarrollo de mecanismos generales que minimicen el tiempo de acceso promedio a datos compartidos, preservando la consistencia de la información [PTM96]. En el contexto de los sistemas con MCD, hay tres preguntas fundamentales al momento de acceder a los datos en el espacio de direcciones global y mantener los datos en un estado consistente: Cómo se mantiene la consistencia de los datos en la memoria global? Introduciendo el punto de los modelos de consistencia de memoria que se describen en la sección 2.3.

19 2.3. MODELOS DE CONSISTENCIA DE MEMORIA 11 Cómo son llevados a cabo los accesos a memoria? Esto engloba los algoritmos de MCD y será abordado en la sección 2.4. De qué manera es implementado el mecanismo de MCD? Esto involucra las soluciones para implementar sistemas con MCD que se muestran en la sección Modelos de Consistencia de Memoria En un sistema con MCD los modelos de consistencia se refieren a un contrato entre el software y la memoria [AH90]. Se dice que, si el software acuerda obedecer ciertas reglas, la memoria promete trabajar de forma correcta. Si el software viola dichas reglas, ya no se garantiza que las operaciones de memoria sean correctas ocasionando inconsistencias. Existen una variedad de modelos de consistencia que especifican cómo será el comportamiento de la memoria en el sistema. Desde aquellos que imponen en el software muchas restricciones, hasta otros que son más flexibles. En esta sección se describen los principales modelos de consistencia Consistencia Estricta Es el modelo más estricto de consistencia de memoria y está definido por la siguiente regla [S.94]: Cualquier lectura a memoria de alguna localidad X retorna el valor guardado por la operación de escritura más reciente a X. Es decir, todas las escrituras son instantáneamente visibles por todos los procesos y se mantiene un tiempo absoluto global. Si se cambia una posición de la memoria, todas las lecturas subsecuentes obtendrán el nuevo valor. La definición es natural y obvia. Sin embargo su simplicidad asume la existencia de un tiempo global y esto es complicado de garantizar en un sistema distribuido, así que determinar el más reciente se convierte en una operación ambigua.

20 2.3. MODELOS DE CONSISTENCIA DE MEMORIA Consistencia Secuencial Un sistema es secuencialmente consistente si cumple lo siguiente [Lam79]: El resultado de cualquier ejecución es la misma como si las operaciones de todos los procesadores se ejecutaran en un orden secuencial, y en esta secuencia las operaciones de cada procesador aparecen en el orden especificado por su programa. Esta definición es equivalente a que todos los accesos a datos compartidos sean consistentes con algún orden total, de tal forma que ese orden total no viole el orden del programa. La consistencia secuencial no requiere una implementación que establezca el orden total, pero si requiere que todas las lecturas sean consistentes con ese orden [KCZ92] Consistencia Durante Liberación (Release Consistency, RC) Es un modelo de consistencia de memoria distribuida propuesto por Gharachorloo en [GLL + 90]. La consistencia RC, presenta un modelo relajado de la memoria que permite que un proceso retrase la visibilidad de los cambios hechos a datos compartidos en los otros nodos, hasta que se realicen ciertas operaciones de sincronización. RC permite que distintos procesos tengan visiones inconsistentes de la memoria compartida, hasta que un subsecuente evento de sincronización ocurra [KCZ92]. En general los modelos de consistencia relajados, como RC, implican mayor eficiencia en términos de comunicación ya que disminuyen la cantidad de información necesaria que se debe transmitir entre los nodos para mantener la consistencia de la memoria. RC ofrece dos tipos de operaciones de sincronización: acquire: Notifica al sistema de memoria que se va a entrar a una región crítica. release: Notifica al sistema de memoria que se acaba de salir de una región crítica. Estas operaciones tienen sentido en la categorización de los accesos a la memoria, que se muestra

21 2.3. MODELOS DE CONSISTENCIA DE MEMORIA 13 en la figura 2.3, propuesta por Gharachorlo en [GLL + 90]. En la figura, los accesos compartidos se pueden dividir en ordinarios y competitivos. En los ordinarios, los procesos no están haciendo uso de las mismas regiones del área compartida, es decir, el acceso a las regiones de memoria es disjunto, teniendo como consecuencia que no se requiera ningún tipo de sincronización. Los accesos serán competitivos si diferentes procesos tratan de acceder a la misma área de memoria compartida y al menos uno de ellos trata de escribir. Los accesos no sincronizados (Nsync) son accesos competitivos que no requieren un orden. Finalmente, los accesos sincronizados (Sync), se dividen en las operaciones de acquire y release descritas arriba, y requieren sincronización en los datos que los procesos comparten. Figura 2.3: Categorización de los accesos a memoria Según Keleher [KCZ92], las siguientes reglas definen la consistencia RC: 1. Antes de que se permita hacer un acceso ordinario de lectura o escritura con respecto a cualquier otro proceso, todos los acquire previos deben haber sido efectuados, y 2. antes de que se permita que se realice un release con respecto a cualquier otro proceso, todas las operaciones de lectura y almacenamiento deben haber sido efectuadas, y 3. los accesos sincronizados deben ser secuencialmente consistentes entre sí. En la figura 2.4 se muestran los mensajes de sincronización realizados en RC. Es importante notar que todos los procesos obtienen la versión actualizada de las variables/páginas de memoria compartidas

22 2.3. MODELOS DE CONSISTENCIA DE MEMORIA 14 cada vez que un proceso efectúa una operación release. Los cambios realizados por el proceso entre las operaciones acquire y release, representadas en la figura por w(p), son invisibles a los otros procesos hasta el momento en que se realiza la operación release donde se efectúa la invalidación (inv)? en los otros procesos. Figura 2.4: Ejemplo de Release Consistency Consistencia Durante Liberación Perezosa (Lazy Release Consistency, LRC) Lazy Release Consistency (LRC) [KCZ92] es un protocolo para la implementación del modelo de consistencia Release Consistency (RC). Este modelo tiene como objetivo reducir el número de mensajes y la cantidad de datos intercambiados a la hora de realizar una sincronización de memoria. La reducción de la cantidad de mensajes es debida principalmente a que, a diferencia del modelo tradicional de RC, LRC no hace las modificaciones globalmente visibles al momento del release [KCZ92]. La propagación de modificaciones se pospone hasta el momento de realizar una operación acquire. LRC se define de la siguiente manera: 1. Antes de que se permita hacer un acceso ordinario de lectura o escritura con respecto a cualquier otro proceso, todos los acquire previos deben haber sido efectuados con respecto a ese otro proceso, y 2. antes de que se permita que se realice un release con respecto a cualquier otro proceso, todas las

23 2.4. ALGORITMOS DE MCD 15 operaciones de lectura y almacenamiento deben haber sido efectuadas con respecto a ese otro proceso, y 3. los accesos sincronizados deben ser secuencialmente consistentes entre sí. Esto significa que al momento de realizar una operación release, no se envían los cambios realizados a los datos compartidos. Mientras que al momento de realizar un acquire, el procesador que realiza la operación debe obtener los valores más recientes de la información compartida en los procesadores que las poseen. Revisando el ejemplo mostrado en la figura 2.4, se nota la diferencia en la cantidad de mensajes enviados para realizar la sincronización de la memoria con respecto a la figura 2.5, donde se observa que en LRC se intercambian menos mensajes que en RC tradicional, debido a que sólo se transmiten los mensajes de sincronización entre el par de procesos que realizan release/acquire, a diferencia del modelo RC que envía mensajes de actualización a todos los procesos. Figura 2.5: Ejemplo Lazy Release Consistency 2.4. Algoritmos de MCD Los algoritmos para implementar MCD se enfrentan con dos problemas básicos [PTM96]: 1. Cómo distribuir estática y dinámicamente los datos a través de todo el sistema, para disminuir la latencia de acceso?

24 2.4. ALGORITMOS DE MCD Cómo preservar una visión coherente de los datos compartidos, a la vez que se minimiza el costo de gestión de la coherencia? Dos estrategias son frecuentemente utilizadas para distribuir los datos compartidos [PTM96]: Replicación: Permite que múltiples copias del mismo dato residan en distintos nodos. Se utiliza principalmente para permitir el acceso simultáneo desde distintos nodos a la información compartida. La replicación es particularmente útil cuando los datos compartidos son accedidos en modo de lectura por diversos nodos. Migración: La migración implica que sólo una copia de información existe en un momento dado, teniendo como consecuencia que se requiera mover dicha información de un nodo a otro para un uso exclusivo. Esta estrategia es adecuada para reducir el costo (overhead) de mantenimiento del protocolo de consistencia, en los casos en que ocurren accesos de escritura secuenciales sobre un dato compartido. El diseño de un sistema con MCD debe contener un algoritmo que se adecúe a las características de las aplicaciones que se ejecutarán en el mismo. A continuación se presenta una clasificación de los algoritmos de MCD propuesta por [PTM96] Lector Único/Escritor Único Esta clase de algoritmo, también conocido como Single Reader/Single Writer (SR/SW), prohíbe la replicación, pero permite la migración. La forma más simple de implementarlo es mediante la utilización de un servidor central [SZ90]. El servidor controla todas las peticiones de acceso que hacen los nodos a los datos compartidos almacenados en el servidor. Este algoritmo tiene problemas de rendimiento debido a que el servidor se torna en un cuello de botella del sistema. Este tipo de implementación implica que la memoria compartida no está físicamente distribuida.

25 2.4. ALGORITMOS DE MCD 17 SR/SW no permite un paralelismo real sobre datos compartidos, ya que cualquier proceso que intente usar estos datos debe esperar que le transfieran el acceso, es decir, sólo un proceso a la vez utiliza un dato compartido Múltiples Lectores/Escritor Único Este algoritmo busca reducir el tiempo promedio de las operaciones de lectura, suponiendo que la operación prevalente sobre los datos en las aplicaciones paralelas es de lectura. Con este fin, se permiten ejecutar múltiples operaciones de lectura simultáneas en distintos nodos sobre un dato compartido. En este tipo de algoritmos se permite que sólo un nodo posea permiso de escritura sobre un dato en un momento específico, causando que las operaciones de escritura sean altamente costosas por la necesidad de informar a los nodos que poseen réplicas que sus copias pueden tornarse desactualizadas. Es por esta razón que este tipo de algoritmo usualmente está basado en políticas de invalidación al momento de escritura. Este algoritmo también es referido como MR/SW por sus siglas en inglés: Multiple Reader/Single Writer Múltiples Lectores/Múltiples Escritores Este algoritmo permite la replicación de bloques de datos tanto en modo de escritura como de lectura. Para preservar la coherencia, las actualizaciones se deben distribuir entre todas las copias de los nodos. Dado que este algoritmo trata de minimizar el costo de los accesos al momento de escritura, es muy adecuado para aplicaciones que compartan datos de escritura. Estos esquemas deben emplear protocolos de actualización al momento de escritura. Según los resultados expuestos en [ACD + 99] los sistemas que implementan Múltiples lectores/múltiples escritores (Multiple Reader/Multiple Writer, MR/MW) están entre los que mejor rendimiento presentan en la aplicaciones de MCD ejecutadas.

26 2.5. IMPLEMENTACIONES DE MEMORIA COMPARTIDA DISTRIBUIDA BASADAS EN SOFTWARE Implementaciones de Memoria Compartida Distribuida Basadas en Software En los últimos 30 años se han realizado varias implementaciones de memoria distribuida basadas tanto en hardware especializado [S.94], como en software a nivel del sistema operativo. En esta sección se detallan cuatro implementaciones de sistemas con MCD a nivel de software IVY IVY fue una de las primeras propuestas de software que desarrollara un modelo con MCD [Li88], implementado como un conjunto de módulos a nivel de usuario y construido sobre el sistema operativo. IVY, desarrollado en el año 1988, estaba compuesto por cuatro módulos: manejador de procesos, asignador de memoria, manejador de memoria y manejador de operaciones remotas. IVY proporcionaba un mecanismo de consistencia utilizando un enfoque de invalidación de páginas de 1Kb. Los resultados de rendimiento mostraron un speedup lineal comparado contra las mejores soluciones secuenciales de los programas paralelos típicos. A pesar de que IVY pudo ser mejorado notablemente al implementarlo a nivel del sistema en lugar de módulos en espacio de usuario, su mayor contribución fue abrir el camino para el concepto de sistemas con MCD en ambientes de producción reales con aplicaciones paralelas [PTM96] Munin Munin es un sistema de MCD creado en 1990 que permite la ejecución de programas paralelos de memoria compartida. Una característica relevante de Munin es que utiliza múltiples protocolos de consistencia de memoria, particularmente el protocolo RC. En Munin, las variables compartidas del programa son anotadas con su patrón de acceso esperado. Estas anotaciones son utilizadas por el sistema en tiempo de ejecución para escoger un protocolo de

27 2.5. IMPLEMENTACIONES DE MEMORIA COMPARTIDA DISTRIBUIDA BASADAS EN SOFTWARE 19 coherencia que mejor se adapte al patrón de acceso [CBZ91]. El objetivo del proyecto Munin es tomar programas hechos para multiprocesadores, y con unos pequeños cambios lograr que se ejecuten eficientemente en clusters utilizando algún protocolo de coherencia de memoria. Sin embargo, se demostró en [BCC + 92] que alternar entre múltiples protocolos de consistencia no tenía un impacto considerable en el desempeño del cluster. Su principal desventaja es que no es transparente al programador ya que se deben clasificar las variables compartidas y recompilar las aplicaciones. El proyecto de Munin fue más un experimento para buscar la eficiencia de aplicaciones en sistemas con MCD, que un ambiente apto para la producción. Además, no se encuentra activamente en desarrollo TreadMarks TreadMarks es una implementación de MCD utilizando el protocolo de consistencia de memoria LRC, desarrollado en el año 1994 [KCDZ94]. Es implementado en forma de librerías a nivel de usuario para los lenguajes C, C++, Java y Fortran. TreadMarks puede ejecutarse en plataformas DEC, HP, IBM, SGI, SUN, x86 (bajo FreeBSD 2.1R, Linux Slackware 3.0 y Windows NT). El proyecto está paralizado desde el año Treadmarks permite al programador utilizar la memoria compartida mediante un API con funcionalidades para asignar memoria distribuida global y mecanismos de sincronización entre procesos. TreadMarks emplea una política basada en actualización con un algoritmo de múltiples lectores y múltiples escritores Kerrighed Kerrighed es un sistema SSI desarrollado por INRIA [LLFM08], que provee administración global de procesos, archivos y memoria a nivel de cluster. Actualmente, es quizás el único sistema SSI que

28 2.5. IMPLEMENTACIONES DE MEMORIA COMPARTIDA DISTRIBUIDA BASADAS EN SOFTWARE 20 está siendo activamente desarrollado. Kerrighed provee los servicios de IPC a nivel de cluster de forma transparente. Además soporta migración de procesos, balance de carga de manera automática y posee un modelo de MCD [MVL + 03] con un algoritmo de múltiples lectores/único escritor y una política de invalidación. Su implementación de MCD es completamente transparente para el programador y no es necesario hacer modificación alguna a los programas paralelos existentes para que se ejecuten en un cluster con Kerrighed. Para garantizar la coherencia de la memoria a nivel de cluster se utiliza el modelo de coherencia de memoria estricto. Kerrighed es software libre y compatible con el kernel de Linux Si bien aún no soporta todas las funcionalidades que dice proveer, éstas se encuentran en desarrollo y se espera que para mediados del año 2009 estén totalmente implementadas. En la versión de Kerrighed (Abril 2008) se encuentran las siguientes funcionalidades soportadas: Espacio único de procesos. Agregación dinámica de nodos al cluster sin necesidad de reconfiguraciones por parte del usuario. Balance de carga mediante la migración automática de procesos entre los nodos del cluster. Soporte de comunicación entre procesos de System V distribuido. Funcionalidades no soportadas: No se permite que los procesos utilicen más memoria de la que posee un nodo físicamente, en otras palabras no está soportada la paginación remota. Migración de hilos Otros Sistemas con MCD Entre otros sistemas con MCD se encuentran los siguientes [PTM96, Tvv + 90]: Mermaid, Midway, Blizzard, Mirage Clouds, Linda, Orca y Amoeba. Sin embargo, su relevancia para esta investigación

29 2.6. PROGRAMACIÓN A NIVEL DEL SISTEMA OPERATIVO LINUX 21 no es significativa debido a las siguientes razones: Implementación obsoleta y sin soporte. Código privativo. Proveen el ambiente a través de compiladores. Para finalizar esta sección, la tabla 2.1 engloba los aspectos más relevantes de los sistemas anteriormente descritos. Sistema Tipo de Implementación Tipo de algoritmo Modelo de Unidad de Política de de MCD consistencia Granularidad coherencia IVY Librerías a nivel de usuario MR/SW Secuencial 1Kb Invalidación + Modificaciones al SO Munin Sistema en tiempo de ejecución Se ajusta entre: RC Variable Se ajusta entre: + Compilador + Pre- procesamiento + Modificaciones al SO SR/SW, MR/SW y MR/MW Invalidaprocesamiento ción y actualización TreadMarks Nivel de Usuario MR/MW LRC 4kb Actualización Kerrighed Modificaciones al SO MR/SW Estricto 4kb Invalidación Cuadro 2.1: Características principales de las implementaciones de los sistemas con MCD 2.6. Programación a Nivel del Sistema Operativo Linux Kernel de Linux El kernel o núcleo es el software que provee servicios básicos para el resto del sistema (i.e controla el hardware y distribuye los recursos del sistema). A veces el kernel es conocido como el core, supervisor o el cuerpo del sistema operativo [Lov05]. Entre los componentes típicos del kernel se tienen: Manejador de interrupciones: Para atender las peticiones de interrupciones al sistema.

30 2.6. PROGRAMACIÓN A NIVEL DEL SISTEMA OPERATIVO LINUX 22 Planificador de tareas: Para compartir el tiempo de procesador entre múltiples procesos. El sistema manejador de memoria: Encargado de manejar el espacio de dirección de procesos. Sistemas de servicios: Este componente engloba servicios prestados por el kernel, como redes y comunicación entre procesos. En sistemas modernos con manejo de regiones de memoria protegida, el kernel típicamente se encuentra en un estado privilegiado en comparación a las aplicaciones normales de los usuarios. Esto incluye un espacio de memoria restringido y acceso total e ilimitado al hardware. Este estado es conocido como el espacio del kernel (kernel-space). Por otro lado, las aplicaciones de los usuarios se encuentran en el espacio de usuario (user-space). El concepto de interrupciones es utilizado para facilitar la comunicación entre el hardware y el kernel. Básicamente, de forma asíncrona le notifican al kernel que un evento de hardware está esperando por ser atendido. Para proveer sincronización, el kernel usualmente deshabilita las interrupciones. En Linux esto se realiza mediante un contexto especial que sólo poseen las interrupciones y no se encuentra asociado a ningún proceso en particular [Lov05]. En Linux, un procesador, puede estar en uno de los siguientes tres estados: En el espacio del kernel, en el contexto de proceso, ejecutando en representación de un proceso específico. En el espacio del kernel, en el contexto de interrupción. En el espacio de usuario, ejecutando código de un proceso en particular Diseños del Kernel Existen dos grandes ramas en el diseño de los kernels:

31 2.6. PROGRAMACIÓN A NIVEL DEL SISTEMA OPERATIVO LINUX 23 Kernel Monolítico: Es un gran programa donde todos los componentes funcionales del kernel tienen acceso a las estructuras de datos y rutinas internas [Rus08]. Se implementa como un gran conjunto de procesos ejecutados en una misma región de memoria. Todos los servicios del kernel existen y se ejecutan en el espacio de direcciones de memoria del kernel. En consecuencia, la comunicación dentro del kernel es trivial, pues todas las funciones se pueden invocar directamente. Los defensores del kernel monolítico abogan por su simplicidad y desempeño. Casi todos los sistemas basados en Unix, incluyendo Linux, tienen un diseño monolítico [Lov05]. El gran riesgo que corre la estructura del kernel monolítico es que ante una falla eventual, la estabilidad del sistema entero se ve comprometida. Microkernel: Al contrario del kernel monolítico, en un microkernel las funcionalidades se encuentran divididas en varias unidades con mecanismos estrictos de comunicación entre ellas, conocidas como servidores [Rus08]. Idealmente sólo aquellos servidores absolutamente necesarios se ejecutan en un modo privilegiado, el resto son ejecutados en espacio de usuario. Esta estructura también tiene como consecuencia que la invocación directa de funciones, como se hace en el kernel monolítico, no sea posible. Toda la comunicación es manejada a través de pase de mensajes. Esto garantiza que ante la falla de un servidor, la estabilidad del kernel no se vea comprometida Llamadas al Sistema El kernel del sistema operativo provee una serie de interfaces a través de las cuales los procesos ejecutados en espacio de usuario pueden interactuar con el sistema. Como parte de estas interfaces, las llamadas al sistema brindan una capa entre el hardware y los procesos ejecutados en espacio de usuario. De acuerdo con [Lov05], esta capa tiene tres propósitos principales: Proveer un abstracción del hardware al espacio de usuario.

32 2.7. COMUNICACIÓN ENTRE PROCESOS 24 A través de las llamadas al sistema el kernel garantiza que se use adecuadamente el hardware y que las aplicaciones del espacio de usuario no sobrepasen los límites de sus recursos. Finalmente, las llamadas al sistema son el único mecanismo que tiene el espacio de usuario para interactuar con el kernel Módulos del Kernel Desde el punto de vista de un kernel monolítico, los módulos consisten en componentes que pueden ser cargados y descargados en tiempo de ejecución. A diferencia de los microkernels, los nuevos componentes no se ejecutan en espacio de usuario, sino que se acoplan al kernel obteniendo los mismos privilegios que cualquier sección que ya se encontrará en ejecución [BBK + 96]. Principalmente, los módulos implementan alguna función específica, como por ejemplo, un sistema de archivos o un controlador de dispositivos. Los módulos tienen dos características importantes [Sta05]: Acoplamiento dinámico: un módulo puede ser cargado y acoplado en el kernel cuando éste ya se encuentra en memoria y ejecutándose. De igual forma pueden ser removidos de la memoria en cualquier momento. Módulos empilables: los módulos poseen una jerarquía en forma de pila. Los módulos individuales sirven como librerías cuando son referenciados por un módulo cliente más arriba en la jerarquía, y como clientes cuando son referenciados más abajo de ellos Comunicación entre Procesos La comunicación entre procesos (Inter Process Communication, IPC) se refiere al intercambio de información entre procesos de una o más computadoras. En un sistema donde varios procesos requieren compartir recursos, las condiciones de carrera se evitan a través de mecanismos de IPC [BBK + 96].

33 2.7. COMUNICACIÓN ENTRE PROCESOS 25 Existen una variedad de formas para alcanzar la comunicación bajo plataformas Linux. Éstas soportan métodos para compartir recursos, sincronización e intercambio de información orientada o no a conexión. Los procesos en Linux, entre otras opciones, pueden compartir memoria por medio de la plataforma de compartimiendo de memoria de System V. Los semáforos de System V son utilizados como un mecanismo de sincronización entre procesos. A su vez, una de las formas más simples de intercambio de información, no orientada a conexión, son las señales (signals). Éstas pueden ser vistas como un mensaje muy corto a uno o varios procesos. En contraposición a las orientadas a conexión se encuentran los pipes, pipes nominales y los sockets. Esto puede ser apreciado en el cuadro 2.2: Recursos Compartidos Kernel Buffer de estructura de datos Procesos Memoria compartida de System V (SHM) Método de Sincronización Semáforos de cola de espera Intercambio de información No orientado a conexión Señales Orientado a conexión Semáforos de System V Señales, Colas de Pipes, Pipes Nominales, Mensajes de System Sockets V de Unix Red Sockets UDP Sockets TCP Cuadro 2.2: Tipos de comunicación entre procesos soportados por Linux Comunicación Transparente entre Procesos La Comunicación Transparente entre Procesos (Transparent Inter Process Communication, TIPC) es un protocolo diseñado para ser usado en ambientes cluster, que permite a los programadores crear aplicaciones que se puedan comunicar de manera rápida y confiable con otras aplicaciones sin importar su ubicación dentro del cluster [Ste08]. Actualmente TIPC está disponible para los sistemas operativos Linux, Solaris y VxWorks. Entre

34 2.7. COMUNICACIÓN ENTRE PROCESOS 26 los lenguajes de programación que pueden utilizar las librerías de TIPC se encuentran C, C++, Perl, Python, Ruby y D Llamadas a Procedimientos Remotos Las Llamadas a Procedimientos Remotos (Remote Procedure Call, RPC) son un mecanismo de comunicación entre procesos en el cual un programa puede hacer que una llamada a un procedimiento se ejecute en otro espacio de direcciones, ya sea en la misma computadora o en otra computadora en una red, de manera transparente [Tan03]. De esta forma el programador sólo tiene que escribir el mismo código sin importar si la llamada al procedimiento es local o remota. La característica principal de RPC es hacer que una llamada a un procedimiento remoto sea lo más parecida posible a una local.

35 Capítulo 3 Kerrighed: Arquitectura y Fundamentos De acuerdo a la sección 2.5, Kerrighed es un sistema SSI que implementa un modelo con soporte de MCD transparente, que no requiere recompilación o modificaciones al código fuente de las aplicaciones. A su vez, de las opciones estudiadas en la sección 2.5, es el único sistema que se encuentra en desarrollo activo. En vista de que es la implementación que más se ajusta a los objetivos planteados en esta investigación, se decidió utilizarlo como plataforma base para el desarrollo. En este capítulo se presenta en detalle la arquitectura y diseño de Kerrighed. La implementación actual de Kerrighed está basada en el kernel de Linux versión Sus funcionalidades han sido añadidas a Linux mediante módulos y algunas modificaciones al kernel original. Kerrighed es una capa que se sitúa entre el kernel y las aplicaciones, que permite el acceso de forma transparente a un ambiente distribuido, tal como se aprecia en la figura 3.1. A continuación se presenta la arquitectura de Kerrighed y su organización modular. Posteriormente se describe el funcionamiento del sistema en términos de las abstracciones realizadas para proveer los servicios distribuidos Arquitectura de Kerrighed La arquitectura de Kerrighed está dividida en 14 módulos [Lot08] clasificables en tres capas: Una capa inferior que provee el subsistema de comunicación. 27

36 3.1. ARQUITECTURA DE KERRIGHED 28 Figura 3.1: Estructura general de Kerrighed La capa intermedia es un mecanismo genérico usado para implementar los servicios distribuidos. Finalmente, la última capa contiene módulos que implementan las funcionalidades distribuidas en Kerrighed. Estos módulos se organizan en directorios correspondientes a sus nombres. La disposición de los módulos de Kerrighed se observa en la figura 3.2. Las siguientes secciones describirán sus funcionalidades. Figura 3.2: Arquitectura de Kerrighed