UN MIDDLEWARE DE MEMORIA COMPARTIDA DISTRIBUIDA PARA UN SISTEMA DE REGISTRO E IDENTIFICACIÓN DE PERSONAS

Transcripción

1 UN MIDDLEWARE DE MEMORIA COMPARTIDA DISTRIBUIDA PARA UN SISTEMA DE REGISTRO E IDENTIFICACIÓN DE PERSONAS RESUMEN En este trabajo se describe un sistema distribuido para la identificación de personas y obtención de sus datos personales, antecedentes civiles y penales a ser empleado por entes gubernamentales autorizados como el Registro Nacional de las Personas o la Policía Federal. Se contrasta con el sistema Interstate Identification Index (III) empleado en los EEUU, analizando sus debilidades y proponiendo una solución; se muestra la conveniencia de emplear un modelo de Memoria Compartida Distribuida, que hace transparente la distribución del hardware y facilita la programación de las aplicaciones. Asimismo, se analizan los problemas que conlleva la distribución, tales como la consistencia, replicación y tolerancia a fallos. En base al análisis realizado se construyó un prototipo del middleware planteado, para probar sus funcionalidades y ventajas. I. INTRODUCCIÓN Al programar en ambientes de multicomputadoras, carentes de una memoria físicamente compartida, el único medio de comunicación entre procesos es el intercambio de mensajes. Este modelo deja en evidencia la naturaleza distribuida del hardware, dificultando la tarea del programador y haciendo que el software sea más complejo, ya que se debe lidiar no sólo con el problema a resolver, sino también con la comunicación. En este sentido, el paradigma de Memoria Compartida Distribuida (DSM: Distributed Shared Memory) permite abstraer al programador, ocultando la complejidad de la red subyacente al ofrecer la abstracción de una memoria compartida virtual. Ésta hace transparente la distribución del hardware y desacopla la aplicación que resuelve el problema del software encargado de la comunicación. Esta última tarea es llevada a cabo por el middleware, que oculta la distribución y los problemas asociados a ella, dejando al programador exclusivamente el desarrollo de la lógica de la aplicación. El sistema bajo análisis es un registro de personas a nivel nacional, que permite el acceso desde cualquier nodo autorizado a información de los ciudadanos tal como: antecedentes penales, prontuario, huellas digitales, fotografías, etc. 1

2 Se estudió como antecedente el sistema Interstate Identification Index (III, Índice de Identificación Interestatal) [1] perteneciente al FBI y utilizado en los EEUU, en vigencia desde el año La estructura del sistema se muestra en la figura 1. Línea de comunicación dedicada del FBI NCIC (FBI) Repositorio Central Red estatal ESTADO NLETS Patrullero ESTADO FIGURA 1 ESTRUCTURA DEL INTERSTATE IDENTIFICATION INDEX (III) Cada estado mantiene una base de datos en alguna agencia designada por el mismo, que almacena los antecedentes criminales de todos sus ciudadanos. La interconexión entre todos ellos es realizada a través del National Crime Information Center (NCIC, Centro Nacional de Información del Crimen) perteneciente al FBI. El repositorio central de cada estado recibe los pedidos de sus agencias locales a través de una red estatal (State Law Enforcement Network), y sirve como punto de conexión con el NCIC, el cual recibe cada consulta y responde indicando: - Los antecedentes de arrestos de la persona, realizados por una agencia federal y cuya información posee el FBI. - Los antecedentes de la persona en aquellos estados que no disponen de un repositorio central (una minoría). - Una lista de aquellos estados con repositorio central en los cuales la persona tiene antecedentes. Luego, el repositorio que inició la consulta se conecta con los estados indicados a través del sistema de comunicaciones NLETS (Nacional Law Enforcement Telecommunications System). 2

3 La arquitectura de este sistema está basada en un esquema cliente-servidor, en donde hay dos tipos de servidores que están completamente centralizados: - Los repositorios centrales de cada estado - El NCIC La desventaja de este enfoque es que la caída de un repositorio central dejaría a todo un estado sin información policial, mientras que una caída en el NCIC dejaría al sistema completo fuera de funcionamiento. La causa de este problema es la falta de replicación y de distribución de la información. Aquí proponemos una modificación al sistema para su aplicación en nuestro país, que permita lograr un cierto grado de tolerancia a fallos. Para resolver el problema empleamos un middleware de DSM como el explicado anteriormente, que facilitará la distribución de la información, de la siguiente forma: Se divide la memoria compartida en porciones, que llamamos variables, entendiendo por variable a un objeto compuesto, en este caso el prontuario de una persona. Cada variable es creada, administrada y destruída por un mismo nodo cliente. Por ejemplo, los datos de los habitantes de una determinada ciudad podrían ser administrados por la central de Policía de esa ciudad o por la central más cercana. De esta forma, cada variable tiene un poseedor que se encargará de ofrecerla a quienes la necesiten y organizar el acceso concurrente a la misma. Además, existe un conjunto de servidores centrales (servidores de nombres) que informan acerca de la localización de las variables compartidas en el sistema. Su necesidad se debe a que dada la gran cantidad de nodos del sistema y su extensión geográfica, no es posible que todos conozcan la ubicación de todas las variables, ya que eso implicaría un excesivo intercambio de mensajes entre todos. La figura 2 muestra la estructura del sistema. 3

4 Central Córdoba Central Misiones Red nacional dedicada Central Buenos Aires Central Tucumán Central Neuquén Consulta Oficina de policía Consulta FIGURA 2 ESTRUCTURA DEL SISTEMA PROPUESTO También se considera que en un sistema como éste la creación de variables es una operación poco frecuente (estaría asociado, por ejemplo, al nacimiento de una persona), mientras que las operaciones más frecuentes son las de lectura, y en segundo término las actualizaciones. Cada nodo cliente del sistema debe estar autorizado para agregar una nueva variable compartida, obtenerla o modificarla. Dicha verificación es realizada en conjunto por los servidores de nombres y los nodos clientes involucrados. Cuando el nodo H 1 crea la variable v m, la información <H 1, v m > se registra en los servidores de nombres. Si posteriormente el nodo H 2 requiere la misma variable, consultará su ubicación al servidor de nombres a través del protocolo de consulta de ubicaciones (ver figura 3), y se le informará que haga la petición al nodo H 1. El nodo H 2 se comunicará con H 1 empleando el protocolo de intercambio de variables (figura 3). Cuando termine, actualizará el valor de v m empleando este último protocolo con H 1. Es decir que el valor de cada variable será mantenido siempre en el nodo que la creó. La persistencia se logra guardando las variables en un medio de almacenamiento secundario. 4

5 Las variables se identifican a través de una clave. Concretamente, las personas serán identificadas a través de su DNI o número de pasaporte. Esto permitiría en un futuro ofrecer búsquedas más complejas, por ejemplo a través de otros atributos, o combinaciones de ellos. El acceso en exclusión mutua a las distintas variables se garantiza a partir de un modelo de Entry Consistency, con operaciones de Acquire (adquirir) y Release (liberar) para cada variable. Es decir, la granularidad de la memoria es a nivel de variable, lo cual maximiza el paralelismo al permitir que distintos nodos puedan trabajar con distintas variables simultáneamente, y evita problemas de false sharing (falso uso compartido) que se presentan con esquemas de granularidad a nivel de página. La replicación de los servidores de nombres tiene por objeto distribuir las consultas y asegurar una leve tolerancia a fallos, ya que si algunos de ellos se caen los restantes pueden reorganizarse, haciendo que la falla sea transparente a los usuarios. II. MODELO DE CONSISTENCIA Un modelo de consistencia es un contrato entre los nodos y la memoria respecto a cómo deberá comportarse la misma frente a secuencias de operaciones de lectura y escritura [2]. Un modelo determina, por ejemplo, si dos operaciones de escritura pueden ser vistas en distinto orden por dos nodos, o a partir de que momento una operación de escritura será vista en los demás nodos. Existen varios modelos de consistencia en la literatura [3]. El modelo de Sequential Consistency [4] (consistencia secuencial) asegura que las operaciones de todos los procesos serán vistas por todos como si se ejecutaran en algún orden secuencial. Este modelo es natural para el programador ya que se asemeja mucho al comportamiento de una sóla memoria física. Sin embargo su performance es baja ya que necesita de intercambios de información entre los nodos por cada operación realizada. El modelo de Release Consistency [3] (consistencia de liberación) hace uso de variables de sincronización Acquire y Release para indicar la entrada y salida de una sección crítica. En el momento en que se realiza un acquire se obtienen los valores más recientes de las variables, obteniéndose un lock (candado) que garantiza la exclusión mutua en el acceso a las mismas. Recién al realizar un release, los valores de las variables modificadas se propagan a los demás nodos liberándose el lock. A partir de ese momento, el próximo nodo que acceda a la memoria verá todos los cambios realizados por el anterior. La ventaja de este modelo es que no requiere propagar las actualizaciones una a una, sino sólo cuando se realiza el release, ya que la memoria 5

6 está bloqueada por el nodo. Además, si los procesos emplean los pares acquire-release en forma adecuada el modelo garantiza los mismos resultados que en un esquema de Sequential Consistency, que es mucho más costoso en términos de performance. Su desventaja es que el acceso de un nodo bloquea el acceso de los demás a toda la memoria compartida. El modelo más apropiado para nuestro trabajo es Entry Consistency [4] (consistencia de entrada), que es similar al anterior pero asocia a cada variable un lock. De esta forma múltiples nodos pueden acceder concurrentemente a distintas variables de la memoria compartida, bloqueándolas una a una. Ésto maximiza el paralelismo, dado que es poco probable que desde dos lugares se consulte por la misma persona al mismo tiempo, pero sí es muy frecuente en el sistema que desde varios lugares se esté accediendo a información de distintas personas simultáneamente. III. PROTOCOLO DE CONSISTENCIA Para implementar el modelo de Entry Consistency se eligió un protocolo de consistencia basado en primario con escritura remota [2]: las operaciones de lectura y escritura sobre una variable se realizarán en el nodo cliente que la creó. Este nodo será el encargado de serializar las peticiones de acceso a la variable y administrar el lock asociado, asegurando así la exclusión mutua. Esta elección es natural en base a la hipótesis de que cada variable tiene un poseedor. Si en cambio, la variable se traslada de un nodo a otro cada vez que se accede, en este caso se pierde la noción del poseedor, y se dificulta mantener el rastro de la misma. IV. SERVIDORES DE NOMBRES Los servidores de nombres son los encargados de mantener la información de la ubicación de cada variable. Dado que esta información es compartida entre todos los servidores, corresponde analizar también su protocolo de consistencia. La replicación de los servidores de nombres tiene dos objetivos: aumentar la performance y mejorar la confiabilidad. El primero se logra distribuyendo las consultas entre todos los servidores. La confiabilidad se obtiene permitiendo que el sistema siga funcionando si algunos servidores se caen, ya que los restantes disponen de la misma información replicada. El usuario no notará la ausencia de algunos de estos servidores, salvo por una posible baja en la performance. 6

7 A partir de la hipótesis de que la creación de variables es una operación poco frecuente en el sistema, se adoptó un protocolo de consistencia por active replication (replicación activa) [2]- [6]: Las actualizaciones pueden realizarse en cualquiera de los servidores de nombres, y cada uno enviará una copia de la actualización al resto. Para lograr la consistencia se requiere de un mecanismo de ordenamiento que asegure orden total, o sea que todas las operaciones de ubicación de las variables sean vistas por todos los servidores en el mismo orden. Otra posibilidad es un protocolo primary-backup (primario con backup) [2]-[7]. En este caso se elije a un servidor de entre todos que actua como primario, y que recibe todas las actualizaciones. Si el servidor primario se cae, se ejecuta un algoritmo de elección de líder para elegir a un nuevo primario. Este informa a los clientes que el primario ha cambiado, para que le envíen las futuras operaciones de creación. La ventaja es que al concentrar las actualizaciones en un servidor, se obtiene serialización de manera natural, es decir que en todos los servidores las operaciones se realizarán en el mismo orden. Su desventaja es que no aprovecha la existencia de múltples servidores para repartir las consultas. Elegimos el enfoque distribuido de replicación activa, que es el más conveniente en este caso. V. PERSISTENCIA Cada nodo cliente del sistema mantiene los valores de sus variables en almacenamiento secundario. Al recibir una operación de release sobre una variable, su valor se guarda en un archivo. De este modo al finalizar el release, el sistema garantiza que el estado de la variable es persistente. Nodo Cliente APLICACIÓN Nodo Cliente APLICACIÓN MIDDLEWARE DE D.S.M. Protocolo de Intercambio de Variables Protocolo de Consulta de Ubicación Servidores de Nombres Protocolo de Consulta de Ubicación FIGURA 3 CAPAS DEL SISTEMA 7

8 De igual modo, cada servidor de nombres considera que la creación de una variable está terminada cuando recibe la confirmación de todos los restantes servidores, y almacena la información en memoria secundaria. VI. PROTOCOLOS La comunicación entre los clientes y los servidores de nombres se realiza a través de un protocolo de consulta de variables (figura 3), que brinda las siguientes operaciones: - Agregar una variable: Se indica <nombrevariable, ubicación> y se responde con una confirmación - Eliminar una variable: Se indica <nombrevariable> (sólo tiene permiso para hacerlo el nodo que la haya creado) y se confirma la operación - Consultar la ubicación de una variable: Se indica <nombrevariable> y devuelve <ubicación> Entre los clientes se emplea un protocolo de intercambio de variables, cuyas operaciones son: - Acquire: Se indica <nombrevariable>. Devuelve como resultado el valor de la variable al nodo que la solicitó. - Release: Se indica <nombrevariable, valor> y devuelve una confirmación de que la variable fue actualizada. VII. TOLERANCIA A FALLOS El esquema propuesto brinda tolerancia con una degradación parcial simple del sistema. No se consideran fallas de enlace ni bizantinas, que serán objeto de un trabajo posterior. Cuando se cae un nodo cliente, la única consecuencia es la imposibilidad de acceder a sus variables propias, de manera que el sistema sólo sufre una degradación parcial. Debe tenerse en cuenta también que un nodo cliente puede caerse mientras posee el acceso a variables compartidas por otros nodos. Para liberar estos recursos se fija un tiempo máximo de posesión del lock, de manera que una vez transcurrido el mismo el nodo poseedor otorga la variable a quien la requiera, anulando la concesión al nodo anterior. 8

9 Si se cae uno de los servidores de nombres, los restantes detectan su ausencia al intentar enviarle actualizaciones, y lo eliminan de su lista. Asímismo, los clientes lo eliminan cuando detectan su ausencia al enviarle una consulta, y envian la dicha consulta a otro servidor de nombres. Cada cliente conoce a los servidores de nombres existentes, y cuando se agrega un nuevo servidor o se recupera un servidor caído, se informa a todos los nodos de su disponibilidad. VIII. IMPLEMENTACIÓN Se construyó un prototipo del middleware para probar su funcionalidad. A través del mismo se verificó que la distribución y replicación de la información en los servidores de nombres aumenta la tolerancia a fallos del sistema. Es decir, la existencia de un anillo de servidores permite que ante la caída de uno de ellos, los servidores anterior y siguiente cierren el anillo y continuen brindando el servicio de nombres. También se probó la consistencia en la replicación de datos, por medio de un mecanismo de orden total. Para ésto se implementó un esquema de tokens que circulan a través del anillo difundiendo información. El control del anillo es llevado a cabo por un líder, cuya elección se realiza a través del algoritmo de elección de líder LCR. [8] CONCLUSIONES En el presente trabajo se analizaron las desventajas del sistema III del FBI, fundamentalmente su debilidad frente a la caída de un servidor, proponiéndose una solución distribuída basada en la replicación de la información y la serialización del acceso. Se propuso como base para la aplicación un middleware de memoria compartida distribuida (DSM) que oculta estos problemas de ubicación de los datos, concurrencia y replicación. Se analizó la consistencia de la memoria, y se consideraron distintos esquemas de replicación ( basado en primario y por replicación activa ), eligiéndose este último, que permite distribuir la carga en los servidores de nombres al repartir las actualizaciones. Se logró un sistema más confiable, que frente a la caída de un nodo puede degradar su funcionalidad, pero a pesar de ello seguir disponible. 9

10 REFERENCIAS [1] Interstate Identification Index, NCIC operationalunits/otis/ncic2000/2000iii.pdf [2] Tanenbaum, A.S., Van Steen, M. Distributed Systems: Principles and Paradigms, Prentice Hall, [3] Gharachorloo, K., Lenoski, D., Laudon, J., Gibbons, P., Gupta, A., Hennessy, J., Memory Consistency and Event Ordering in Scalable Shared-Memory Multiprocessors, Proc. 17 th Ann. Int'l Symp. On Computer Architecture, ACM, [4] Lamport, L, How to make a multiprocessor computer that correctly ejecutes multiprocess programs, IEEE Transactions on Computers, C-28(9): , Septiembre [5] Bershad, B, Zekauskas, M, Midway: Shared Parallel Programming with Entry Consistency for Distributed Memory Multiprocessors, Technical Report CMU-CS , Carnegie Mellon University, Septiembre [6] Schneider, F, Replication Management using the State Machine Approach, en Mullender, S, Distributed Systems, Addison-Wesley, [7] Budhiraja, N, Marzullo, K, Schneider, F, Toueg, S, The Primary-Backup Approach, en Mullender, S, Distributed Systems, Addison-Wesley, [8] Lynch, N, Distributed Algorithms, Morgan Kaufman,