From Randomized Encodings to iO - On Program Obfuscation

2.5 Applications

2.5.1 From Randomized Encodings to iO

administrado por el clúster para el escenario propuesto.

En un principio se explicará algunos detalles necesarios para comprender la motivación de la solución adoptada en cuanto a configuración y distribución de los recursos.

Para realizar el montaje y la administración de los dispositivos de bloques creado con drbd se creará un recurso que se encargara que un solo nodo este como primario o maestro, de esta manera todas las operaciones sobre el nodo primario o maestro se sincronizasen correctamente en el secundario o esclavo. En conjunto se creará otro recurso que será el encargado de montar el bloque en el sistema de ficheros y esto se vinculará para que únicamente se ejecute en el nodo que actúe de primario o maestro, ya que es no es posible montar un el dispositivo si el nodo actúa como primario o maestro y nunca en dos nodos simultáneamente.

• Para aquello recursos que hacen uso de alguno de los dispositivos de bloques creado con drbd se ha creado un grupo para que tanto el recurso como el montaje del dispositivo siempre se realice sobre el mismo nodo.

• Debido a que algún recurso se puede encontrar en un nodo distinto al nodo donde se encuentra la IP compartida se hará uso del agente de recurso anything junto al script scriptReglaIptables.sh, que se detallará en elANEXO G: Clúster de alta Disponibilidad, con los cuales se redireccionará entre nodo si se recibe una petición cuyo destino es algún recurso determinado. El recurso creara las reglas de iptables para la redirección se encontrará siempre en el nodo donde no se esté ejecutando el recurso en cuestión.

Alta disponibilidad

116

• Se dispondrá de un grupo de recursos que estará compuesto por opengnsys y otros recursos que deben ejecutarse en el mismo nodo. Entre algunas de las dependencias detectada en las pruebas están:

o Dirección IP compartida y servidor Apache: La dependencia es provocado debido a que para responder la petición del menú asociado a al cliente cuando inician ogLive de Opengnsys se va en la dirección IP origen del paquete que es procesado por Apache. Esto provoca que si se redirige esta petición no se le responderá al cliente con el menú asignado.

o Dirección IP compartida y Opengnsys: La principal dependencia detectada se encuentra en cómo se desarrolla el proceso de restauración de una imagen mediante Torrent, al iniciar el proceso de descarga el cliente solicitar él envió de un determinado fichero mediante http al puerto 6969 y el servidor establece la comunicación contra un puerto que el cliente abre entre 2706 y el 2106. Esto provoca que si se redirige esta petición el servidor intentara establece la conexión contra uno de los puertos del nodo que redirigió el paquete y este no sabrá a que cliente debe reenviarlo o si debe reenviarlo.

o Opengnsys, Samba y Rsync: La dependencia detectada se debe al proceso de creación de imágenes usado en Opengnsys debido a que el cliente envía operaciones al servicio de opengnsys como crear una imagen, montarla o reducirla que provoca la ejecución de acciones en el nodo que lo ejecuta mientras que la formación para crear la imagen es enviada mediante Samba o Rsync, dependiendo del tipo de imagen. Esto provoca que si no se encuentra todos los recursos en el mismo nodo se entraría enviando información a un nodo mientras que se realizan operaciones en otro nodo.

Ilustración 3-43 Distribución inicial de los recursos en el clúster. Los pasos que se deben seguir son los siguientes:

1. Instalar las dependencias necesarias mediante el uso de la herramienta apt. servidor1#apt -y install arping libxml2-utils servidor2#apt -y install arping libxml2-utils Los argumentos usados serán:

install Indica que el proceso que se va a realizar es la instalación de un paquete.

-y Indica que conteste automáticamente si a las preguntas que pudieran salir en el proceso de instalación y de esta manera realizar la instalación de forma no interactiva. arping libxml2-utils Nombre los paquetes de las dependencias necesarias.

117

2. Crear el recurso que permitirá uno de los nodos tener asignada la dirección IP IPcompartida en función de donde se ubique este mismo. Se hará uso de la herramienta pcs y el agente de recurso ocf:heartbeat:IPaddr2[67].

servidor1#pcs resource create IPcompartida ocf:heartbeat:IPaddr2 ip="IPcompartida" cidr_netmask="24" \

nic="eth0" flush_routes="true" arp_sender="iputils_arping" \ op monitor interval="10s"

Los argumentos usados serán:

resource create Indica que se va a crear un nuevo recurso en clúster. IPcompartida Nombre que se le asignara al recurso.

ocf:heartbeat:IPaddr2 Indica que el agente con el que se hará de uso para el recurso. Este permite administrar direcciones IPv4 virtuales.

ip="IPcompartida Establece la dirección IP virtual la cual se asignará a la interfaz de red cuando se ejecute el recurso en el nodo.

cidr_netmask="24" Establece la mascará de subred que se usará junto a la dirección IP virtual. nic="eth0" Indica el nombre de la interfaz a la que se le asignará la dirección IP virtual. flush_routes="true" Establece que se elimine las entradas de la tabla de enrutamiento cuando la

dirección IP virtual se desasocie del nodo relacionadas con la misma.

arp_sender="iputils_arping" Indica que se haga uso de arping cuando se asigne la dirección IP virtual a un nodo para notificar de esta manera el cambio de la MAC asociada a la dirección IP en la red.

op monitor interval="10s" Establece que cada 10 segundo se monitorice el estado del recurso.

3. Crear el recurso con el que se administrará el servidor DHCP en el clúster. Se hará uso de la herramienta pcs y el agente de recurso ocf:heartbeat:dhcpd[68].

servidor1#pcs resource create DHCP ocf:heartbeat:dhcpd \ config="/etc/dhcp/dhcpd.conf" \

binary="/usr/sbin/dhcpd" user="root" \ op start interval="0" timeout="60" \ op stop interval="0" timeout="60" \ op monitor interval="10s"

Los argumentos usados serán:

resource create Indica que se va a crear un nuevo recurso en clúster. DHCP Nombre que se le asignara al recurso.

ocf:heartbeat:dhcpd Indica que el agente que con él se hará de uso para el recurso. Entre otras características permite comprobar el estado del recurso realizando una petición al servicio.

Alta disponibilidad

118

config="/etc/dhcp/dhcpd.conf" Establece el fichero de configuración que se usará al levantar el demonio. binary="/usr/sbin/dhcpd" Indica el binario usado para levantar el demonio de DHCP.

user="root" Establece el usuario con el que se iniciara el demanio de DHCP. op start interval="0"

timeout="60s"

Establece que si el recurso tarda más de un minuto dará como erróneo el intento de arranque. Además, indica que no se espere ante de reintentarlo. op stop interval="0"

timeout="60s"

Establece que si el recurso tarda más de un minuto dará como erróneo el intento de parada. Además, indica que no se espere ante de reintentarlo. op monitor interval="10s" Establece que cada 10 segundo se monitorice el estado del recurso.

4. Crear los recursos con el que se administrará el servidor TFTP, gestor de base de datos, servicio de Rsync y Samba en el clúster. Se hará uso de la herramienta pcs.

servidor1#pcs resource create TFTP service:tftpd-hpa \ op start interval="0" timeout="60" \