- Se incorporó
- 1 Octubre 2007
- Mensajes
- 6.065
Bueno, lo prometido es deuda dicen 
, y aprovechando que estoy esperando datos de otra área 
Bueno, el tema del Clusterizado de servicios es muy útil en ambientes en donde se requiere alta disponibilidad, o balanceo de carga para estos. En esta guía se tratará algo básico como mantener un servidor activo y otro pasivo para mantener un servicio básico arriba. [strike] como una base de datos[/strike]
Partamos.
Requisitos
- Centos 7 (pueden obtener desde Aqui ).
- Máquinas Virtuales conectadas con 2 tarjetas cada una.
- Paciencia
Tutoriales de instalación hay varios, así que nos saltaremos esa parte.
La idea de tener 2 tarjetas de red es para mantener 1 de ellas en conexión directa con el segundo nodo del clúster (es lo mínimo que se recomienda para que mantengan comunicación los nodos de un clúster - de hecho se recomienda un bonding para hacerlo más tolerante a fallos, pero acá lo haremos simple
)
La otra tarjeta de red irá conectada al switch que intercomunica la red con el resto de las cosas.
Objetivos:
- Tener un servicio Apache operando en las 2 máquinas
- Una IP virtualizada, que el servicio de clúster se encargue mantener activa en uno de los nodos, para que en caso de falla de este, redirija el servicio transparentemente al segundo nodo.
- Un lindo laboratorio para hacer pruebas y descubrir las bondades de pcs.
Asumamos entonces lo siguiente:
Server1
Server2
Asumamos que ya configuraron las interfaces de red y hacen ping a las 2 IPs
Una buena practica es siempre dejar un repositorio local utilizando el DVD de instalación como fuente (en caso de que los servidores no vayan a estar conectados a Internet.
Imaginemos que tienen montado su DVD en /mnt/repodata, con lo siguiente se copian las 2 carpetas necesarias para generar el repositorio local (Packages y repodata)
Para no tener problemas adicionales, y dado que es a modo de laboratorio, pondremos a SELINUX en modo permisivo.
En CentOS 7 tenemos a firewalld (que es bien amigable en su configuración, pero en este minuto no es necesario), así que procederemos a deshabilitarlo para dejar nuestro servidor de patas abiertas. Si confían en su firewall/solución de seguridad, go ahead.
Algo importante es que ambos servers deben conocer su propia IP y la IP de su contraparte, por lo que agregaremos eso al archivo hosts de cada máquina. Validen que esto haya quedado bien hecho haciendo ping al nombre de host de cada maquina.
PREPARACION DEL CLUSTER
Hasta aquí sólo hemos hecho configuraciones básicas y de conectividad para que nuestros 2 servidores independientes tengan conexión entre sí. Ahora procederemos a levantar servicios y configurar el servicio de cluster como tal.
En ambos nodos instalar agentes de cluster
Esto crea los servicios necesarios para el cluster y el usuario hacluster, que se encarga de generar las tareas de comunicacion entre nodos. A este usuario le tenemos que asignar un password.
En ambos nodos
También debemos habilitar el servicio para que se inicie con el sistema y posteriormente iniciarlo. En en ambos nodos
Ahora tenemos el usuario hacluster ya tiene password, debemos indicarle a PCS la autenticación de los nodos
Ejecuta esto solo en nodo 1
Una vez realizado esto, se inicializa el cluster
Ahora se habilitan todos los nodos desde lab1
Con esto ya tenemos los nodos del cluster comunicandose entre sí y lo podemos averiguar utilizando
Este WARNING gigante que aparece ahí tiene que ver con el Fencing. El Fencing es una característica de todo Cluster que tiene un storage en común, y es que en el supuesto caso de una pérdida de conectividad entre los nodos, ambos no figuren como activos, y por lo tanto, generando cambios independientes en el filesystem. Por lo tanto lo que se hace es fencing de un nodo, o inhabilitarlo de acceder al recurso compartido.
En un Clúster Linux esto se logra a través de STONITH (Shoot The Other Node In The Head - bien explícito
). Acá vemos que nos alerta que no tenemos dispositivos stonith ni el stonith-enabled=false activado. Como este laboratorio no va a contar (de momento) con un Filesystem compartido, vamos a deshabilitar el stonith.
Ahora estamos en condiciones de agregar resources. Pero antes, una pequeña reseña:
Como hemos visto hasta ahora, el modo de manejar un clúster Linux ha cambiado bastante desde Red Hat 6. En RHEL/CentOS 7 PCS es la herramienta centralizada de configuración. Tiene muchos menús y opciones para habilitar, visualizar, deshabilitar, etc. Todas las aristas en la configuración de un Clúster.
Ahora vamos a habilitar un resource, para comenzar. Una IP Virtual.
Probamos haciendo ping
Ejalé!
Ahora instalaremos el servicio de Apache, en ambos nodos pero SIN INICIAR EL SERVICIO. Esto es crítico, porque ahora los servicios se gestionan como resources.
Copiamos un molde
Y volvemos a crear un resource, esta vez para el Apache.
Ahora podemos ver el servicio Apache arriba, pero levantado en el otro nodo
, eso claramente no nos sirve si buscamos un esquema activo/pasivo
Esto se logra utilizando la opción constraint. Con ella le decimos al cluster que queremos que X servicio siempre se ejecute donde Y servicio esté corriendo.
Puede llegar el caso en donde tengamos que reiniciar el Cluster (posiblemente por requerimiento del hefe), así que es necesario establecer QUE servicio inicia primero. No nos sirve levantar un Apache si aún no está arriba la IP Virtualizada.
Para esto, tambien se usa constraint pero con la opción order
Con esto ya está listo nuestro Cluster. Ahora pueden probar (si virtualizaron el entuerto) a desconectar de la red a uno de los nodos completamnete, mientras le hacen ping a la IP virtualizada, y acceden a la URL en la misma IP
En un segundo capítulo, le agregaremos un GFS2 o una unidad replicada con DRBD para mantener los datos sincronizados. Aunque de momento, pueden mantener todo alineado con un cochino rsync que haga updates incrementales en ambos /var/www/html/
Lo más importante de este lab es que nos permite soltarle la mano a la configuración de un Cluster básico, y si se tiene tiempo, poder agregar resources y ver su forma de operar.
Quedo listo y dispuesto a recibir sus críticas, y por qué no, alguna sugerencia que gustoso aceptaré para implementar.
Yakko, no tires mucha caca
, y aprovechando que estoy esperando datos de otra área Bueno, el tema del Clusterizado de servicios es muy útil en ambientes en donde se requiere alta disponibilidad, o balanceo de carga para estos. En esta guía se tratará algo básico como mantener un servidor activo y otro pasivo para mantener un servicio básico arriba. [strike] como una base de datos[/strike]
Partamos.
Requisitos
- Centos 7 (pueden obtener desde Aqui ).
- Máquinas Virtuales conectadas con 2 tarjetas cada una.
- Paciencia
Tutoriales de instalación hay varios, así que nos saltaremos esa parte.
La idea de tener 2 tarjetas de red es para mantener 1 de ellas en conexión directa con el segundo nodo del clúster (es lo mínimo que se recomienda para que mantengan comunicación los nodos de un clúster - de hecho se recomienda un bonding para hacerlo más tolerante a fallos, pero acá lo haremos simple
)La otra tarjeta de red irá conectada al switch que intercomunica la red con el resto de las cosas
.Objetivos:
- Tener un servicio Apache operando en las 2 máquinas
- Una IP virtualizada, que el servicio de clúster se encargue mantener activa en uno de los nodos, para que en caso de falla de este, redirija el servicio transparentemente al segundo nodo.
- Un lindo laboratorio para hacer pruebas y descubrir las bondades de pcs.
Asumamos entonces lo siguiente:
Server1
Código:
hostname lab1.local
ip interna 10.0.0.10 255.255.255.0
ip externa 192.168.0.101 255.255.255.0
Código:
hostname lab2.local
ip interna 10.0.0.20 255.255.255.0
ip externa 192.168.0.102 255.255.255.0Asumamos que ya configuraron las interfaces de red y hacen ping a las 2 IPs
Una buena practica es siempre dejar un repositorio local utilizando el DVD de instalación como fuente (en caso de que los servidores no vayan a estar conectados a Internet.
Imaginemos que tienen montado su DVD en /mnt/repodata, con lo siguiente se copian las 2 carpetas necesarias para generar el repositorio local (Packages y repodata)
Código:
#mkdir /repolocal
#cp -Rv /mnt/repodata /repolocal/ && cp -Rv /mnt/Packages /repolocal/
#cat <<END>/etc/yum.repos.d/local.repo
[CentOS_local]
name=CentOS 7.2 Local
baseurl=file:///repolocal/
gpgcheck=0
enabled=1
ENDPara no tener problemas adicionales, y dado que es a modo de laboratorio, pondremos a SELINUX en modo permisivo.
Código:
mv /etc/selinux/config /etc/selinux/config.bkp
cat <<END>/etc/selinux/config
SELINUX=permissive
SELINUXTYPE=targeted
ENDEn CentOS 7 tenemos a firewalld (que es bien amigable en su configuración, pero en este minuto no es necesario), así que procederemos a deshabilitarlo para dejar nuestro servidor de patas abiertas. Si confían en su firewall/solución de seguridad, go ahead.
Código:
systemctl stop firewalld
systemctl disable firewalldAlgo importante es que ambos servers deben conocer su propia IP y la IP de su contraparte, por lo que agregaremos eso al archivo hosts de cada máquina. Validen que esto haya quedado bien hecho haciendo ping al nombre de host de cada maquina.
Código:
echo "192.168.0.101 lab1.local lab1" >> /etc/hosts
echo "10.0.0.10 lab1-int.local lab1-int" >> /etc/hosts
echo "192.168.0.102 lab2.local lab2" >> /etc/hosts
echo "10.0.0.20 lab2-int.local lab2-int" >> /etc/hostsPREPARACION DEL CLUSTER
Hasta aquí sólo hemos hecho configuraciones básicas y de conectividad para que nuestros 2 servidores independientes tengan conexión entre sí. Ahora procederemos a levantar servicios y configurar el servicio de cluster como tal.
En ambos nodos instalar agentes de cluster
Código:
yum install pacemaker pcs corosync resource-agentsEn ambos nodos
Código:
echo demo | passwd --stdin hacluster
Changing password for user hacluster.
passwd: all authentication tokens updated successfully.
Código:
[root@lab1 ~]# systemctl enable pcsd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/pcsd.service to /usr/lib/systemd/system/pcsd.service.
[root@lab1 ~]# systemctl start pcsd.serviceAhora tenemos el usuario hacluster ya tiene password, debemos indicarle a PCS la autenticación de los nodos
Ejecuta esto solo en nodo 1
Código:
[root@lab1 ~]# pcs cluster auth lab1-int lab2-int -u hacluster
Password: **** --- ingresas tu password super segura aqui
lab1-int: Authorized
lab2-int: Authorized
[root@lab1 ~]#Una vez realizado esto, se inicializa el cluster
Código:
[root@lab1 ~]# pcs cluster setup --start --name DEMOCLUSTER lab1-int,lab1 lab2-int,lab2
Shutting down pacemaker/corosync services...
Redirecting to /bin/systemctl stop pacemaker.service
Redirecting to /bin/systemctl stop corosync.service
Killing any remaining services...
Removing all cluster configuration files...
lab1-int: Succeeded
lab2-int: Succeeded
Starting cluster on nodes: lab1-int, lab2-int...
lab2-int: Starting Cluster...
lab1-int: Starting Cluster...
Synchronizing pcsd certificates on nodes lab1-int, lab2-int...
lab1-int: Success
lab2-int: Success
Restaring pcsd on the nodes in order to reload the certificates...
lab1-int: Success
lab2-int: Success
[root@lab1 ~]#Ahora se habilitan todos los nodos desde lab1
Código:
[root@lab1 ~]# pcs cluster enable --all
lab1-int: Cluster Enabled
lab2-int: Cluster Enabled
[root@lab1 ~]#Con esto ya tenemos los nodos del cluster comunicandose entre sí y lo podemos averiguar utilizando
Código:
pcs cluster status
pcs status
Código:
[root@lab1 ~]# pcs cluster status
Cluster Status:
Last updated: Thu Aug 4 18:30:27 2016 Last change: Thu Aug 4 18:30:06 2016 by hacluster via crmd on lab1-int
Stack: corosync
Current DC: lab1-int (version 1.1.13-10.el7-44eb2dd) - partition with quorum
2 nodes and 0 resources configured
Online: [ lab1-int lab2-int ]
PCSD Status:
lab1-int: Online
lab2-int: Online
[root@lab1 ~]# pcs status
Cluster name: DEMOCLUSTER
WARNING: no stonith devices and stonith-enabled is not false
Last updated: Thu Aug 4 18:30:36 2016 Last change: Thu Aug 4 18:30:06 2016 by hacluster via crmd on lab1-int
Stack: corosync
Current DC: lab1-int (version 1.1.13-10.el7-44eb2dd) - partition with quorum
2 nodes and 0 resources configured
Online: [ lab1-int lab2-int ]
Full list of resources:
PCSD Status:
lab1-int: Online
lab2-int: Online
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
[root@lab1 ~]#En un Clúster Linux esto se logra a través de STONITH (Shoot The Other Node In The Head - bien explícito
). Acá vemos que nos alerta que no tenemos dispositivos stonith ni el stonith-enabled=false activado. Como este laboratorio no va a contar (de momento) con un Filesystem compartido, vamos a deshabilitar el stonith.
Código:
pcs property set stonith-enabled=falseAhora estamos en condiciones de agregar resources. Pero antes, una pequeña reseña:
Como hemos visto hasta ahora, el modo de manejar un clúster Linux ha cambiado bastante desde Red Hat 6. En RHEL/CentOS 7 PCS es la herramienta centralizada de configuración. Tiene muchos menús y opciones para habilitar, visualizar, deshabilitar, etc. Todas las aristas en la configuración de un Clúster.
Código:
[root@lab1 ~]# pcs help
Usage: pcs [-f file] [-h] [commands]...
Control and configure pacemaker and corosync.
Options:
-h, --help Display usage and exit
-f file Perform actions on file instead of active CIB
--debug Print all network traffic and external commands run
--version Print pcs version information
Commands:
cluster Configure cluster options and nodes
resource Manage cluster resources
stonith Configure fence devices
constraint Set resource constraints
property Set pacemaker properties
acl Set pacemaker access control lists
status View cluster status
config View and manage cluster configuration
pcsd Manage pcs daemonAhora vamos a habilitar un resource, para comenzar. Una IP Virtual.
Código:
pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.50 cidr_netmask=24 op monitor interval=30sProbamos haciendo ping
Código:
[vittokox@thinkpad ~]$ ping 192.168.0.50 -c 5
PING 192.168.0.50 (192.168.0.50) 56(84) bytes of data.
64 bytes from 192.168.0.50: icmp_seq=1 ttl=64 time=0.488 ms
64 bytes from 192.168.0.50: icmp_seq=2 ttl=64 time=0.386 ms
64 bytes from 192.168.0.50: icmp_seq=3 ttl=64 time=0.428 ms
64 bytes from 192.168.0.50: icmp_seq=4 ttl=64 time=0.366 ms
64 bytes from 192.168.0.50: icmp_seq=5 ttl=64 time=0.418 ms
--- 192.168.0.50 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 0.366/0.417/0.488/0.043 msAhora instalaremos el servicio de Apache, en ambos nodos pero SIN INICIAR EL SERVICIO. Esto es crítico, porque ahora los servicios se gestionan como resources.
Código:
yum install httpd -y
Código:
cp /usr/share/doc/HTML/index.html /var/www/html/ -v
Código:
cat <<END>/etc/httpd/conf.d/status.conf
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>
ENDY volvemos a crear un resource, esta vez para el Apache.
Código:
pcs resource create WWW ocf:heartbeat:apache configfile=/etc/httpd/conf/httpd.conf statusurl="http://localhost/server-status" op monitor interval=1minAhora podemos ver el servicio Apache arriba, pero levantado en el otro nodo
, eso claramente no nos sirve si buscamos un esquema activo/pasivo
Código:
[root@lab1 conf.d]# pcs status
Cluster name: DEMOCLUSTER
Last updated: Thu Aug 4 19:20:38 2016 Last change: Thu Aug 4 19:20:33 2016 by root via cibadmin on lab1-int
Stack: corosync
Current DC: lab1-int (version 1.1.13-10.el7-44eb2dd) - partition with quorum
2 nodes and 2 resources configured
Online: [ lab1-int lab2-int ]
Full list of resources:
VirtualIP (ocf::heartbeat:IPaddr2): Started lab1-int
WWW (ocf::heartbeat:apache): Started lab2-int
PCSD Status:
lab1-int: Online
lab2-int: Online
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabledEsto se logra utilizando la opción constraint. Con ella le decimos al cluster que queremos que X servicio siempre se ejecute donde Y servicio esté corriendo.
Código:
[root@lab1 conf.d]# pcs constraint colocation add WWW with VirtualIP INFINITY
[root@lab1 conf.d]# pcs resource show
VirtualIP (ocf::heartbeat:IPaddr2): Started lab1-int
WWW (ocf::heartbeat:apache): [/b]Started lab1-int[/b]Puede llegar el caso en donde tengamos que reiniciar el Cluster (posiblemente por requerimiento del hefe
), así que es necesario establecer QUE servicio inicia primero. No nos sirve levantar un Apache si aún no está arriba la IP Virtualizada.Para esto, tambien se usa constraint pero con la opción order
Código:
[root@lab1 conf.d]# pcs constraint order VirtualIP then WWW
Adding VirtualIP WWW (kind: Mandatory) (Options: first-action=start then-action=start)
[root@lab1 conf.d]# pcs constraint
Location Constraints:
Ordering Constraints:
start VirtualIP then start WWW (kind:Mandatory)
Colocation Constraints:
WWW with VirtualIP (score:INFINITY)
[root@lab1 conf.d]#En un segundo capítulo, le agregaremos un GFS2 o una unidad replicada con DRBD para mantener los datos sincronizados. Aunque de momento, pueden mantener todo alineado con un cochino rsync que haga updates incrementales en ambos /var/www/html/
Lo más importante de este lab es que nos permite soltarle la mano a la configuración de un Cluster básico, y si se tiene tiempo, poder agregar resources y ver su forma de operar.
Quedo listo y dispuesto a recibir sus críticas, y por qué no, alguna sugerencia que gustoso aceptaré para implementar.
Yakko, no tires mucha caca
Última modificación:
