DISEÑO MODELO DISTRIBUIDO. 1.1 Evolución usando Islas como Modelo Distribuido

Transcripción

1 Capítulo 1 DISEÑO MODELO DISTRIBUIDO En este documento abordaremos el diseño EPOL distribuido. Este diseño consta de un conjunto de familias de algoritmos evolutivos (definido en el modelo secuencial. Ver documentación) implementados mediante el uso de islas [RC86]. Pero antes de entrar en detalle con el modelo y la implementación, se hará un repaso de conceptos fundamentales de los modelos distribuidos [ALBA99] así como de sus propiedades intrínsecas. Asimismo, se justificará el empleo de una determinada topología distribuida como es en nuestro caso el anillo unidireccional estático. Y para finalizar expondremos ejemplos de uso y configuración del modelo implementado, explicando el protocolo de comunicación con sus UDPs (unidades de datos del protocolo) [BROWN94]. 1.1 Evolución usando Islas como Modelo Distribuido Siguiendo las pautas marcadas por el modelo secuencial propuesto en EPOL, podemos definir una isla como un tipo de algoritmo evolutivo el cual posee capacidad para comunicarse con otras islas (intercambio de soluciones cada cierto periodo de tiempo, migrate) y/o con un monitor (encargado de la distribución del proceso evolutivo de las islas). No es necesario que exista el monitor, esto depende del tipo de topología empleada y del diseño e implementación final adoptados. Existen tantos tipos de islas como clases de algoritmos podamos implementar. Lo más normal es usar un conjunto de islas generacionales derivadas de un algoritmo evolutivo generacional, pero en este proyecto, hemos apostado por el uso de islas de estado estacionario, en el cual, sólo un individuo es reemplazado en cada ciclo reproductor sobre la población final. 1

2 Unos de los primeros sistemas distribuidos en usar estado estacionario fue GENITOR II. Sin embargo, la gran mayoría de los sistemas implementados utilizan algoritmos generacionales. 1.2 Topología En relación con la topología de interconexión entre islas, podemos distinguir dos características importantes en un algoritmo evolutivo distribuido: Comportamiento temporal. Determina la existencia de un vecindario estático o dinámico. En nuestro caso, el comportamiento es estático puesto que las islas mantienen indemnes su topología. Topología del vecindario. Para nuestro caso utilizamos un anillo unidireccional, es decir que el sentido de la conexión es único, de ahí que cada isla pueda comunicarse con otra específica en un único sentido. Fijaremos nuestro trabajo en el anillo unidireccional estático, muestra del cual se ofrece en la siguiente figura: 2 Leyenda Conexión de datos+control Conexión de datos entre Islas 1 Monitor 3 n Isla n-ésima 4 Figura Anillo unidireccional estático 2

3 En la figura anterior, el monitor es una figura secundaria en el modelo, únicamente se encarga de gestionar el comienzo y fin de la búsqueda distribuida, así como de recopilar información de cada isla durante la ejecución distribuida. La razón de utilizar un modelo en anillo como el presentado, se basa en varios hechos: 1. Es fácil de implementar 2. Es simple 3. Su tiempo de comunicación es constante [ALBA99]. Si caracterizamos el tiempo de comunicación, supongamos definida una constante de comunicación C c, a partir de dicha constante podemos derivar dicho tiempo en función del número de islas d. Suponiendo una ley de crecimiento exponencial con relación a la topología tenemos: T c = C c d γ La ventaja de una topología en anillo es que cada migración entre cada par de vecinos puede realizarse en paralelo y en un tiempo constante. Por tanto, γ=0, y T c es constante. El resultado anterior nos permite extrapolar el hecho de que a mayor número de procesadores, la ganancia en velocidad o speedup será monótonamente creciente (aunque cada vez sea menor el crecimiento). En general, cuando el acomplamiento entre islas es elevado y la topología está muy interconectada el comportamiento del anillo depende del tipo de red utilizada. De nuevo el anillo incrementa sus ventajas ya que no satura a la red con conexiones excesivas. Para la implementación adoptada en este proyecto, no se han tomado datos de ganancia en velocidad, tan sólo nos hemos limitado a realizar un estudio algorítmico. 3

4 1.3 Políticas de Migración Uno de los aspectos más importantes del proceso de comunicación entre islas reside en establecer qué se va a migrar, cuantos van a migrar, con qué frecuencia se van a migrar y a quién se va a reemplazar. A esto es a lo que se denomina política de migración, caracterizada formalmente mediante la siguiente tupla: M = ( m, ζ, ω, ω ) s R donde m es el número de individuos que migran (migration rate). ζ es la frecuencia de migración (en número de evaluaciones). ω S es la política de selección de los individuos que migran: en nuestro proyecto podemos migrar al mejor individio (mig_best) o a otro elegido al azar (mig_random). ω R es la política de reemplazo usada para insertar cada inmigrante que llega a la población. La frecuencia de migración se da en términos de cuantas evaluaciones se realizan entre cada dos migraciones. Otra cuestión a tener en cuenta es el tipo de comunicación que vamos a utilizar: podemos usar una comunicación síncrona o asíncrona. Las ventajas de una y otra se relatan a continuación. 1.4 Tipos de Comunicación La mayoría de los algoritmos evolutivos son síncronos. Esto significa que la fase de comunicación (envío + recepción) está localizada en la misma porción del algoritmo 4

5 evolutivo distribuido. En este caso nos aseguramos que todas las islas se encuentran en el mismo estado de recepción y/o envío. Por el contrario el funcionamiento asíncrono suele resultar más eficiente en la práctica, pero complica excesivamente el modelo de comunicaciones, ya que debemos prever que la comunicación se puede llevar a cabo en cualquier momento de la ejecución de una isla. Esto implica que las islas emisoras y receptoras pueden encontrarse en distintas generaciones y sus individuos en diferentes estados de evolución. Un inconveniente atribuido al uso de cualquier tipo de comunicación en diferentes topologías, incluidas el anillo, es que los nuevos individuos migrados pueden redireccionar la búsqueda, bien tendiendo a una situación de elitismo que desfavorezca la diversidad o bien introduciendo letales, es decir, nuevos individuos cuya adecuación es menor que la de sus progenitores. 1.5 Homogeneidad Cuando hablamos de un anillo distribuido homogéneo o heterogéneo nos referimos a si todas las islas son idénticas, en tanto a que utilizan los mismos operadores, tamaño de población, etc... o, por el contrario, son diferentes, pudiendo utilizar ciclos reproductivos diferentes con tamaño de población desiguales. La ventaja de usar un tipo u otro de algoritmo es difícil de cuantificar, no obstante, permite aprovechar el buen funcionamiento de un determinado ciclo reproductivo. En nuestro caso esto puede ser muy interesante ya que hemos demostrado que la inclusión del algoritmo BP como operador (A partir de ahora denotaremos con un AE(BP) a un algoritmo evolutivo con el operador BP) en el ciclo reproductivo del algoritmo evolutivo proporciona mejoras significativas frente al uso de operadores convencionales, por tanto, podríamos hacer uso de GA(BP) en una isla, mientras que el resto trabajaran con los operadores evolutivos diferentes. No obstante, por razones de tiempo, sería muy largo realizar pruebas con islas heterogéneas. 5

6 1.6 Modelo de Objetos para AEs Distribuidos Con el fin de simplificar en la medida de lo posible la repetición de datos, imágenes y figuras, en la Figura vamos a simplificar nuestro modelo OMT secuencial, tratando únicamente las diferencias en cuanto a las nuevas clases y relaciones añadidas. Hay relaciones que se establecen con clases auxiliares, como BOOL y que por simplificación no aparecen en este modelo. Communications island {abstract} Socket Monitor Is_Bipop Is_EA Bipop 2 EA Figura Modelo OMT propuesto para el Sistema Distribuido Como se aprecia en el diagrama de la Figura 1.6.1, existe una clase padre isla, abstracta, encargada de definir la interfaz con los dos tipos de islas: las islas para algoritmos evolutivos con dos poblaciones Is_Bipop y las islas para algoritmos evolutivos con una población Is_EA. Se ha hecho uso de las clases Communications y Socket para gestionar las comunicaciones y hacerlas independientes de la implementación. La clase Socket implementa las llamadas al sistema para el control y gestión de socket y puertos bajo TCP. 6

7 La clase Communications tiene por misión modelar el mensaje a transmitir en una conexión, de ahí que implemente los métodos necesarios para el tratamiento de la información a transmitir y recibir a través de sockets. También aparece una clase Monitor, encargada de monitorizar la ejecución distribuida de las islas, recabando las soluciones e informando al resto de las islas del inicio o fin de la búsqueda distribuida (ejecución). En ningún caso participa en la búsqueda de la solución ni provoca ningún tipo de retención en ella. Las clases islas, al igual que sucediera con las clases Bipop o EA, se han de instanciar dependiendo del problema que se trate. Las clases Monitor, Is_Bipop y Is_EA utilizan un sistema de configuración muy flexible basado en ficheros de texto de fácil comprensión (consulte la sección de Fichero de Configuración). 1.7 Pseudo-Código para un AE Distribuido La justificación del uso de técnicas de distribución aplicables a los algoritmos evolutivos radica en el considerable uso por parte de estos de recursos computacionales, como memoria física y tiempo de procesador. A grandes rasgos, existen dos formas para disminuir el tiempo de ejecución: 1. Disminuir el número de evaluaciones necesario para alcanzar una solución. 2. Ejecutar el algoritmo en máquinas paralelas/distribuidas. Las ventajas de la inclusión de Algoritmos Evolutivos Distribuidos se reflejan en los siguientes aspectos: uso de una población de mayor tamaño, aplicación a problemas de mayor dimensión y complejidad, y la reducción del tiempo de espera para alcanzar una solución. A continuación se muestra el pseudo-código general de un AE Distribuido (AED). 7

8 t i :=0; inicializar[p i (t i )]; evaluar [P i (t i )]; mientras no terminar hacer P i, (t i ) := selección_pareja [P i (t i )]; P i, (t i ) := recombinnación [P i, (t i )]; P i, (t i ) := mutación [P i, (t i )]; evaluar [P i, (t i )]; P i (t i ) := comunicación [P i, (t i ) AEP j:: P j, (t j )] P i (t i +1) := seleccionar_entorno [P i (t i ) P i (t i )]; t i := t i +1; fin mientras Figura Pseudocódigo de un nodo en un AE Distribuido (AED) Se incluye en esta nueva versión un apartado dedicado a la comunicación con otros AED. Una característica a destacar de este esquema es el hecho fundamental de que cada AED puede estar en una etapa diferente del proceso evolutivo (denotado con t i ). 1.8 El Sistema de Comunicación En esta sección describimos el sistema de comunicación utilizado para implementar el sistema distribuido. Cualquier UDP dispone de una cabecera indicando el tipo de mensaje, a continuación contiene un campo longitud que indica la longitud del mensaje enviado, y por último el cuerpo del mensaje. TIPO LONGITUD CUERPO DEL MENSAJE 4 char 1 unsigned long 0 longitud MAX_MESG Figura Formato general de una UDP La Tabla define los tipos de UDPs empleados, clasificándolos según a la fase de ejecución a la que pertenezcan (i: inicio, f: fin, m: monitorización y r: ejecución del 8

9 algoritmo), indicando el sentido de la comunicación y añadiendo una breve descripción de su objetivo. Tabla 1.8-1Resumen de UDPs usadas por el protocolo.( islas = I, monitor = M) UDP Sentido Fase Descripción CONF M I i Contiene datos de configuración para el inicio ENDP M I f Inicia el protocolo de desconexión ENDP I M f La isla informa de su terminación al monitor GEVA M I m Monitor pide el nº de generaciones y evaluaciones GEVA I M m Isla responde con el nº de gen y evaluaciones INDI I I r Isla comunica su individuo a su vecina. INIG I M i La isla informa al monitor de sus parámetros de comunicación KILL M I f El monitor indica a la isla su terminación definitiva SOLU M I f La isla informa al monitor de su mejor solución STRT M I i El monitor indica a la isla que comience su búsqueda La definición del protocolo de comunicación es de vital importancia para completar la anterior tabla. La especificación de las fases de conexión y desconexión se muestra en la Figura Como puede observarse durante la conexión el monitor arranca los procesos isla y estos envían sus datos de configuración iniciales relativos a los puertos de comunicación (PAS) en los que intercambiar información con el monitor y sus vecinos. El monitor lee un fichero de configuración del sistema global y después envía a las islas la configuración necesaria para realizar la búsqueda distribuida. Cada isla puede utilizar su propio fichero de configuración local distinto del resto (heterogeneidad en la búsqueda). En él se describen los operadores y parámetros que se usarán durante la búsqueda. Cada isla tras ser creada por el sistema, abre un SAP para la conexión con su isla vecina (SAP-datos) e informa de ello al monitor tras conectar con él. El monitor recolecta los puntos de conexión para datos de cada isla y rellena una tabla de procesos (Figura 1.8.2) con estos y otros datos referentes a la conexión y configuración de la búsqueda. El monitor informa seguidamente a cada isla de sus datos de trabajo y configuración de la isla vecina (CONF). 9

10 Las islas esperan entonces en una barrera de sincronización hasta que el monitor les indique que comiencen (STRT) a ejecutar cada una su modelo de evolución definido según el fichero de configuración de la isla. Durante la búsqueda el monitor queda a la espera de mensajes de terminación (solución y/o iteraciones + evaluaciones). Si alguna de las islas termina por encontrar la una solución (valor en entrenamiento de la mejor red-individuo) cuyo valor alcance un umbral 1 de error permitido, el monitor detiene a las restantes islas iniciando el protocolo de desconexión. Si ninguna isla encuentra una solución, las islas se ejecutarán durante el número de ciclos distribuidos señalados en el fichero de configuración del monitor e irán terminando. M I I M Abre SAP-CRTL Crea una isla Abre SAP-DATOS Conecta con monitor Envía solución al monitor INDI Repetir #islas veces GEVA Lee soluciones de cada isla INIG Envía SAP-DATOS Muestra por pantalla Recolecta datos iniciales Envía configuración a todas las islas CONF Termina ejecución KILL Termina la ejecución de todas las islas Lee configuración FIN Arranca la búsqueda en todas las islas STRT Comienza Búsqueda Figura Protocolo de conexión (izquierda) y desconexión (derecha) del sistema implementado 1 Este valor umbral se debe modificar en el código y no en tiempo de ejecución. 10

11 El protocolo de desconexión supone que el monitor recogerá las mejores soluciones de cada una de las islas, escogiendo la mejor de las soluciones. Finalmente el monitor indica a las islas que deben terminar sus ejecuciones (KILL). El control de errores en la comunicación es bastante estricto, de forma que si la ejecución termina correctamente es improbable que se haya producido un error. Durante su ejecución, las islas realizan puntos de chequeo en los que decide si envía datos al monitor (condición de terminación alcanzada) o si enviar individuos a otras islas. Si una isla termina antes que el resto, entonces deja de trabajar y únicamente pasa cualquier mensaje a la isla vecina sin interpretarlo (en espera de recibir un mensaje KILL). De otro modo podrían aparecer interbloqueos (sobretodo en la fase de recepción de emigrantes en su isla vecina). En cuanto a las estructuras utilizadas por las islas y el monitor, puede observarse en la Figura que tanto las islas como el monitor disponen de una tabla de procesos para gestionar las comunicaciones (clase Communications). Sólo la tabla del monitor está completa. Cada isla utiliza las entradas relativas a sí misma (para recibir emigrantes), la de su vecina (para enviar emigrantes) y la del monitor (para mensajes de control). El concepto de punto de acceso al servicio (SAP) se utiliza aquí para definir un punto a través del cual enviar/recibir datos por la red. En el presente proyecto se utiliza la interfaz BSD socket. Usamos el protocolo TCP para transmisión segura. Typedef struct P_Table { int ea_id; // identificador de la isla (bipop o ea simple) int neighb_id; // identificador de la isla vecina int pid; // numero de identificación del proceso char hostname[max_host_name]; // nombre del host int data_socket; // descriptor del socket de datos int control_socket; // descriptor del socket de control bool data_connect_status; // estado del socket de datos bool valid_entry; // la entrada está disponible para su uso? } Figura Tabla de procesos usada en la comunicación 11