Arrancamos crm en modo interactivo y entramos en el modo configure, para evitar errores y avisos durante la instalación deshabilitamos las propiedades stonith y qourum con los comandos:
property stonith-enable=false
property no-quorum-policy=ignore
Dirección IP
Creamos el recurso con nombre ClusterIP para la dirección IP donde se atenderán las peticiones de la página Web que contendrá el cluster.
Utilizamos el comando primitive ClusterIP ocf:heartbeat:IPaddr2 params ip=192.168.1.250 cidr_netmask=32 clusterip_hash=sourceip op monitor interval=30s. Y confirmamos y aplicamos cambios con commit.
primitive. Para crear recuros.
ClusterIP. Nombre para el recurso.
ocf:heartbeat:IPaddr2. Tipo de recurso para la dirección IP.
params. Parametros del recurso.
ip=192.168.1.250. Dirección IP en decimal que utilizará el cluster.
cidr_netmask=32. Máscara de red en formato CIRD.
clusterip_hash=sourceip.
op monitor. Opción monitor.
interval=30s. Con un intervalo de 30s.
Ahora pasamos a realizar algunas pruebas, primero nos conectamos a la IP del cluster a través del navegador.
Si desactivamos el nodo principal sobre el que está corriendo el recurso y recargamos el navegador podemos ver el cambio.
Servidor Web
Ahora creamos el recurso (WebSite) para el servidor Web con el comando:
primitive WebSite ocf:heartbeat:apache params configfile=/etc/apache2/apache2.conf op monitor interval=1min meta target-role=Started
ocf:heartbeat:apache. Recurso para el servidor Web Apache.
configfile=/etc/apache2/apache2.conf. Archivo de configuración del servidor Web.
meta. Metainformación del recurso.
target-role=Started. Activamos el arranque por defecto.
Aparecen unos warnings sobre los tiempos de arranque y parada del servicio pero seguimos adelante y confirmamos con commit. Podemos observar que el cluster coloca inicialmente los recursos en diferentes nodos para evitar sobrecargar los equipos pero luego lo modificaremos a nuestro antojo.
Si apuntamos el navegador a la IP servidor principal (192.168.1.248) sobre el que está corriendo el recurso ClusterIP, la conexión es reiniciada.
Si apuntamos a la IP del nodo secundario (192.168.1.249) sobre el que corre el recurso del servidor Web (WebSite), la conexión si es aceptada.
Si apuntamos a la IP compartida del cluster (192.168.1.250) nuevamente nos reinicia la conexión dado que el servidor no está corriendo en dicho equipo.
Colocation
Como comentaba anteriormente, el cluster distribuye los recursos entre los nodos para evitar sobrecargar los equipos. Pero es más recomendable aprovecharnos de todas las opciones que incluye crm para ordenar y colocar los distintos recursos del cluster.
Utilizamos el siguiente comando:
colocation Web_on_IP inf: WebSite ClusterIP
colocation. Opción para colocar recursos, grupos, etc.
Web_on_IP. Nombre para identificarlo.
inf:. Palabra clave que obliga a los siguientes recursos.
WebSite ClusterIP. El recurso WebSite estará junto a ClusterIP.
Y lo podemos comprobar con crm_mon.
Ahora cuando apuntamos a la IP del nodo maestro (192.168.1.248) al igual que a la IP del cluster (192.168.1.250) nos responde correctamente.
Y si apuntamos a la IP del esclavo (192.168.1.249) nos reinicia la conexión.
Pruebas finales
Vamos a tumbar el servidor principal donde están corriendo los recursos ClusterIP y WebSite con el comando crm node standby y a través de crm_mon comprobamos que estos son transferidos al servidor secundario; podemos observar que éste es el único que está online y el principal en modo standby.
Si apuntamos a la IP del cluster (192.168.1.250) nos responde correctamente y podemos observar que se trata del nodo secundario.
Si apuntamos a la IP del nodo principal (192.168.1.248) nos reinicia la conexión.
Y si apuntamos a la IP del nodo secundario (192.168.1.249) el cual está ejecutando los recursos del cluster, nuevamente responde correctamente.
En próximas entradas instalaremos y configuraremos DRBD para crear un RAID1 con el que replicar los datos de la página Web.
Un saludo, Brixton Cat.
No hay comentarios:
Publicar un comentario
Bienvenid= si quieres dejar un comentario