martes, 31 de enero de 2012

Estructura de un Módulo de balanceo para LVS

De momento, en el LVS existen 10 algoritmos de balanceo de carga, de los cuales ya comenté brevemente. Voy a volver a listarlos, agregando el archivo en el cual se encuentran definidos:
  • Planificación por Round-Robin (Round-Robin Scheduling). Definido en: ip_vs_rr.c
  • Planificación por Round-Robin ponderado (Weighted Round-Robin  Scheduling). Definido en: ip_vs_wrr.c
  • Planificación por menor número de conexiones (Least-Connection Scheduling). Definido en: ip_vs_lc.c
  • Planificación por menor número de conexiones ponderado (Weighted Least-Connection Scheduling). Definido en: ip_vs_wlc.c
  • Planificación por menor número de conexiones local (Locality-Based Least-Connection Scheduling). Definido en: ip_vs_lblc.c
  • Planificación por menor número de conexiones local con réplicas (Locality-Based Least-Connection with Replication Scheduling). Definido en: ip_vs_lblcr.c
  • Planificación por hashing de destino (Destination Hashing Scheduling). Definido en: ip_vs_dh.c
  • Planificación por hashing de origen (Source Hashing Scheduling). Definido en: ip_vs_sh.c
  • Planificación por menor retardo esperado (Shortest Expected Delay Scheduling). Definido en: ip_vs_sed.c
  • Planificación por servidores sin peticiones en espera (Never Queue Scheduling). Definido en: ip_vs_nq.c


Cualquiera de estos algoritmos se puede escoger para realizar el balanceo en un sistema basado en LVS, a través de ipvsadm, la herramienta de administración para cónsola del LVS. Probablemente los más comunes sean el algoritmo de Round-Robin o el de Round-Robin ponderado (aunque no necesariamente sean los mejores para todas las situaciones).

Si queremos realizar nuestro propio algoritmo de balanceo, o queremos modificar alguno de los ya existentes, debemos empezar por estudiar la estructura que tienen o deben tener.

Recordemos que estos programas están diseñados para ser utilizados como módulos del kernel de Linux, por ello, todos deben tener al menos dos funciones:

static int __init_ip_vs_XXX_init(void);
Es la función que se ejecuta cuando se carga el módulo. Entre otras cosas, acá se registran los módulos.

static int __exit_ip_vs_XXX_cleanup(void);
Es la función que se ejecuta cuando se descarga el módulo.

Sobra decir que en las definiciones anteriores, XXX se sustituye por el nombre del módulo (rr, wrr, wlc, etc). Adicionalmente, en todo algoritmo de balanceo, se define un struct de tipo ip_vs_scheduler, en el cual se asignan las propiedades (atributos y funciones) que definen el comportamiento del módulo. La estructura de estos, es la siguiente:

struct ip_vs_scheduler {
 struct list_head n_list;  /* d-linked list head */
 char   *name;  /* scheduler name */
 atomic_t  refcnt;  /* reference counter */
 struct module  *module; /* THIS_MODULE/NULL */

 /* scheduler initializing service */
 int (*init_service)(struct ip_vs_service *svc);
 /* scheduling service finish */
 int (*done_service)(struct ip_vs_service *svc);
 /* scheduler updating service */
 int (*update_service)(struct ip_vs_service *svc);

 /* selecting a server from the given service */
 struct ip_vs_dest* (*schedule)(struct ip_vs_service *svc,
           const struct sk_buff *skb);
};

Las funciones que definen el comportamiento del algoritmo son:
  • init_service: se ejecuta en el momento en que se asocia un servicio con el algoritmo de planificación. Es opcional, no todos los algoritmos requieren realizar alguna tarea especial al iniciar el servicio. Ejemplo de uso: el algoritmo de round-robin, utiliza la función init_service para inicializar la data que utilizará para el balanceo (sched_data), con la lista de servidores reales actuales (destinations).
  • update_service: se ejecuta al actualizar o eliminar alguno de los destinos. Es opcional. Ejemplo de uso: el algoritmo de round-robin utiliza esta función para actualizar la data que utiliza para el balanceo (sched_data), con la lista de servidores reales actuales (destinations).
  • done_service: se ejecuta al finalizar el servicio. Es opcional. Ejemplo de uso: el algoritmo de round-robin ponderado utiliza la función done_service para liberar la memoria ocupada por la data utilizada para el balanceo (sched_data).
  • schedule: esta es la función en donde se define el algoritmo de balanceo per se. Es la parte más importante del módulo, y por supuesto no es opcional. Devuelve un apuntador a un objeto de tipo ip_vs_dest, que indica cuál es el servidor que el algoritmo escogió para responder la petición realizada por el cliente.
Por supuesto, las funciones que definamos para estas 4 opciones debemos especificarlas en el mismo archivo, o incluir el archivo de cabecera que las contenga. Lo mismo si estas funciones a su vez utilizan otras funciones.

Y bien, estos son todos los elementos que necesitamos conocer para escribir un algoritmo de balanceo o modificar alguno de los existentes. Recomiendo comenzar estudiando los algoritmos de balanceo por menor número de conexiones y por round-robin, pues son los más cortos (no pasa de 120 líneas ninguno de los dos) y sencillos de entender.


Linux Virtual Server


El Servidor Virtual de Linux (Linux Virtual Server o LVS) es una solución de balanceo de carga de alto rendimiento y alta disponibilidad, basada en software, que funciona sobre un cluster de servidores bajo el sistema operativo Linux. El funcionamiento del LVS es transparente al usuario, y además provee tolerancia a fallos, alta escalabilidad y confiabilidad.

La arquitectura del LVS está formada por un conjunto de servidores que se encargan de atender las peticiones de los visitantes, denominados servidores reales, y uno o más servidores, que se encargan de distribuir la carga entre los primeros, denominados directores. La conexión entre el(los) nodo(s) director(es) y los servidores reales puede ser a través de una red de área local (LAN) o una red de área amplia (WAN). En la siguiente figura se muestra esta arquitectura.


El LVS se puede implementar mediante dos mecanismos, ambos programados como un conjunto de módulos para el núcleo de Linux:

  • IP Virtual Server (IPVS): implementa el balanceo de carga a nivel de capa 4 del modelo OSI (capa de transporte). El IPVS se distribuye incorporado al Kernel de Linux, a partir de la versión 2.6.10, liberada el 24 de diciembre de 2004.
  • Kernel TCP Virtual Server (KTCPVS): implementa el balanceo de carga a nivel de la capa 7 del modelo OSI (capa de aplicación). La ventaja de realizar el balanceo en esta capa, es que se puede realizar la asignación de tareas a los servidores reales en base al contexto de las peticiones, sin embargo, por esta misma razón, resulta menos escalable que el IPVS.


Algoritmos nativos de planificación de tareas del LVS

Para distribuir la carga entre los servidores reales, el LVS implementa los siguientes algoritmos de planificación:

  • Planificación por Round-Robin (Round-Robin Scheduling).
  • Planificación por Round-Robin ponderado (Weighted Round-Robin  Scheduling).
  • Planificación por menor número de conexiones (Least-Connection Scheduling).
  • Planificación por menor número de conexiones ponderado (Weighted Least-Connection Scheduling).
  • Planificación por menor número de conexiones local (Locality-Based Least-Connection Scheduling).
  • Planificación por menor número de conexiones local con réplicas (Locality-Based Least-Connection with Replication Scheduling).
  • Planificación por hashing de destino (Destination Hashing Scheduling).
  • Planificación por hashing de origen (Source Hashing Scheduling).
  • Planificación por menor retardo esperado (Shortest Expected Delay Scheduling).
  • Planificación por servidores sin peticiones en espera (Never Queue Scheduling).


Los algoritmos de planificación por Round-Robin y Round-Robin ponderado son los más sencillos. El primero se basa en un esquema de Round-Robin tradicional: se mantiene una lista con los servidores reales, y las peticiones son asignadas, a medida que van llegando, de acuerdo al orden de la lista. En el algoritmo de Round-Robin ponderado, a cada servidor real se le asigna un peso (un valor entero que representa su capacidad de procesamiento), y las tareas son asignadas por el(los) nodo(s) director(es) de acuerdo a ese peso.

Los algoritmos de planificación Least-Connection y Weighted Least-Connection se basan en el número de conexiones activas. En el primero se entrega la petición al servidor con el menor número de conexiones activas establecidas. El segundo algoritmo se basa en el primero, pero pondera el número de conexiones activas de cada servidor real, por un peso asignado estáticamente, que busca representar la capacidad de procesamiento del servidor.

El algoritmo Locality-Based Least-Connection funciona de manera similar al algoritmo Least-Connection, pero mantiene una tabla caché por dirección IP destino; si el servidor solicitado se encuentra en la tabla caché y además no se encuentra sobrecargado (donde la sobrecarga significa que el servidor tenga más conexiones activas que el valor de su peso), le asignará la petición, en caso contrario, utilizará el algoritmo Weighted Least-Connection para seleccionar el servidor. Locality-Based Least-Connection with Replication, es muy parecido al anterior, pero en vez de tener un servidor por destino, mantiene un conjunto de servidores. Si ninguno de los servidores del conjunto está disponible, utiliza el algoritmo Weighted Least-Connection para seleccionar el servidor.

Los algoritmos por Hashing (destino y origen) designan el servidor que responderá la petición entrante, mediante una búsqueda en una tabla hash estática, por su IP destino o IP origen, según sea el caso. Si el servidor real se encuentra caído o sobrecargado (donde la sobrecarga significa que su número de conexiones activas es al menos el doble que el valor de su peso), entonces el director no asignará la tarea a ningún servidor y el usuario no obtendrá una respuesta satisfactoria.

El algoritmo por menor retardo esperado, asigna la petición al servidor que en ese momento tenga la menor demora esperada, definida esta para el i-ésimo servidor como $(Ci+1)/Ui$, donde Ci es el número de conexiones activas y Ui es el peso de ese servidor. El algoritmo por servidores sin peticiones en espera, si encuentra a un servidor inactivo (sin conexiones activas), le asignará la carga, en caso contrario, responderá como el algoritmo por menor retardo esperado.


martes, 3 de enero de 2012

Instaladores multiplataforma con InstallJammer

Tengo un pequeño proyecto multiplataforma escrito en C++ al que necesitaba hacer un instalador para ambas plataformas. Mi proyecto consiste en un archivo ejecutable, un directorio de documentación en HTML y un par de archivos XML para idiomas (español e inglés).

Por recomendación llegué a InstallJammer. Lo he probado y ha ido muy bien. Aunque el tutorial que dejan en su página va perfectamente bien, dejo esta entrada a manera de tutorial personal :)

1) Descargar la última versión de IntallJammer. En este caso la palabra "última" no es usada como "más reciente", sino como "última", pues al parecer el proyecto ha sido recientemente abandonado. Pero bueno, yo he hecho la prueba en Windows 7 y funciona, así que va a servir un buen tiempo más, tal como está.

Yo al principio me bajé la que según es la última versión (1.2.15) en .tar.gz, pero no me funcionó en Windows 7, así que bajé un Snapshot de la versión 1.3 que si funcionó perfectamente.

2) Una vez descargado y descomprimido se puede correr directamente, no necesita instalación. Se mostrará una ventana como la siguiente.


3) Al hacer click en el botón New Project Wizard se abrirá el asistente para la creación de nuestro instalador. Acá nos comenzará a pedir datos sobre el proyecto de instalador: Nombre, Directorio del proyecto de instalación.


4) Al presionar Next, mostrará el siguiente paso donde pedirá detalles sobre la aplicación:



5) Luego más datos de la aplicación...




6) Luego InstallJammer nos preguntará el directorio en el cual están (o estarán) los archivos que va a utilizar para hacer el instalador. Es decir, este es el directorio donde debemos colocar nuestros ejecutables y todo archivo/directorio que queremos que quede en el directorio donde se instale la aplicación. Por ejemplo, como comenté al principio, yo necesito además del programa principal, 2 archivos XML en el mismo directorio que éste.




7) Luego nos preguntará el estilo del Wizard de instalación. Yo escogí Modern Wizard.


8) Luego especificaremos las plataformas para las cuales generaremos instaladores. Si nuestra aplicación no es multiplataforma, lógicamente sólo seleccionamos la plataforma para la cual está hecha.


9) Finalmente nos permitirá seleccionar algunas otras opciones, como crear shortcuts, ejecutar la aplicación después de instalación, etc.


10) Si todo salió bien, hemos terminado de configurar nuestro instalador.


11) Al presionar Finish en la ventana anterior, volveremos a la interfaz principal de la aplicación en la cual nos mostrará detalles del proyecto que acabamos de crear.


12) Al presionar Build Install podremos generar nuestro instalador para las plataformas seleccionadas. Lógicamente, antes de hacer esto, debemos asegurarnos de que todos los archivos necesarios se encuentran en el directorio que especificamos al principio.


Y eso es todo. Parecen muchos pasos, pero es por el nivel de detalle que puse. Luego de generado el instalador lo probé y todo funcionó bien, colocó los archivos donde debía, creó los shortcuts que especifiqué, el desinstalador, etc.