Alta disponibilidad con Pacemaker y Corosync

Alta disponibilidad con pacemaker.

Os propongo implementar un cluster con par de nodos (o los que queráis) para dar un servicio cualquiera con un alto grado de disponibilidad.

Usaremos el software Pacemaker. Su significado literal (marcapasos), aunque no sea muy poético, por lo menos es bastante descriptivo.

Aunque Pacemaker en sus orígenes, allá por el año 2004, formaba parte del proyecto Linux-HA. A partir del 2007 comenzó a tener personalidad propia, generando su propio proyecto

Pacemaker es un gestor de recursos clúster de alta disponibilidad.

Permite disponer de la máxima disponibilidad en los recursos que hayamos configurado mediante la detección y recuperación de fallos a nivel de nodo/recurso. Para poder hacer eso, Pacemaker hace uso de las capacidades de Corosync.

Se pueden gestionar clusters de prácticamente cualquier tamaño.

Tal y como dice la web oficial ClusterLabs: «Prácticamente cualquier cosa que se pueda escribir en un script puede administrarse como parte de un clúster de Pacemaker«.

Está disponible en la mayoría de las distribuciones de Linux:

Debian, Ubuntu, Red Hat, Centos, Fedora, openSUSE, SLE…

Si tienes alguna duda, puedes ponerte en contacto conmigo.

Cluster activo-activo o activo-pasivo

Tal como su nombre indica, es el tipo de cluster respecto a su configuración. Cuando escuchamos activo-activo, pensamos en que los nodos trabajan de forma activa, conjuntamente. Pueden compartir los mismos recursos y acceder a ellos de forma independiente. Si algún nodo cae, el servicio se continúa ofreciendo a través de los nodos que siguen funcionando. Pueden ser más eficientes, ya que disponemos de todos los nodos para realizar el trabajo. Esto no siempre es posible, ya que a veces, el acceso a determinados recursos está limitado, bien por seguridad o por prevenir corrupción de datos.

En el caso activo-pasivo, existe el nodo activo, el que realiza el trabajo y el nodo pasivo, que está a la espera de ser activado cuando el nodo activo tenga algún problema. Es como la rueda de repuesto.

Si se puede llamar «ventaja» de la configuración activo-pasivo, es que no hay degradación en el servicio en caso de caída de un nodo.

Sin embargo, en caso de caida del nodo activo, el sistema tarda un tiempo en migrar los recursos (failover) al nodo pasivo.

Estas configuraciones son transparentes para el usuario del servicio. Este sólo percibe que su petición se responde. Cómo lo haga internamente el cluster es totalmente irrelevante para el usuario.

Quorum

Si un clúster se divide en dos (o más) grupos de nodos que ya no pueden comunicarse entre sí (también conocido como particiones), el quorum se utiliza para evitar que los recursos se inicien en más nodos de los deseados, lo que podría producir corrupción de datos.

Un clúster tiene quorum cuando más de la mitad de todos los nodos están activos en la misma partición.

Si el clúster tuviera 5 nodos se divide en particiones de 3 y 2 nodos, la partición de 3 nodos tendría quorum y se apropiaría de los recursos. Si un clúster de 4 nodos se divide en dos particiones de 2 nodos, ninguna de las particiones tendrá quorum.

Los clusters de dos nodos son un caso especial. Según la definición anterior, un clúster de dos nodos solo tendría quorum cuando ambos nodos estuvieran en activo. Esta condición haría que la creación de un cluster de dos nodos no tuviera mucho sentido (a nivel quorum), pero podemos modificar estas reglas a nuestro gusto.

¿Qué es el Split-brain?

Linux-HA lo describe como el resultado de una partición en un cluster. Cada lado cree que el otro está muerto y asume los recursos como si el otro lado ya no fuera dueño de estos. Ese es el resultado de actuar cuando la información es incompleta, descuidando la Ley de Dunn.

«Lo que no sabes, no lo sabes y no puedes hacerlo«

Cuando un nodo se declara «muerto», su estado es, por definición, desconocido.

Tal vez esté muerto, tal vez esté simplemente incomunicado. Lo único que se sabe con certeza es que su estado es desconocido.

La solución definitiva para este problema es el fencing.

Si queremos disponer de un cluster robusto de alta disponibilidad con pacemaker debemos tener claros los siguientes conceptos.

Fencing, Stonith y Split Brain

El problema de usar quorum sin fencing, es que la pérdida de quórum puede tomar una cantidad ilimitada de tiempo para detectar y reaccionar en el peor de los casos.

El fencing es el proceso de bloquear recursos de un nodo cuyo estado es incierto. Puede definirse también como un método para llevar un cluster a un estado conocido. Puede ser de dos tipos, a nivel de nodo o a nivel de recurso.

Una de las técnicas más usada de fencing a nivel de nodo es el Stonith (Shoot The Other Node In The Head).

Normalmente, cuando se declara que un nodo está muerto, se trata de una mera especulación. Stonith toma esa especulación y la hace realidad.

El fencing no requiere conocer el comportamiento de los nodos «errantes«, ni siquiera pide su cooperación.

Una forma de evitar la condición Split-Brain sin tener que recurrir al fencing es configurar rutas de comunicación redundantes e independientes, de modo que la pérdida de una interfaz o ruta no interrumpa la comunicación entre los nodos. La comunicación no debería tener un único punto de fallo (SPOF).

Se suele usar almacenamiento compartido llamado disco heartbeat. Este almacenamiento compartido reduce la probabilidad de un Split-Brain en el clúster porque puede distinguir entre un fallo de red y un fallo de nodo.

Por ejemplo, un error de red sería si fallase la conexión de red entre los nodos y de un nodo al disco compartido. Un error de nodo ocurriría cuando un nodo deja de poder ser accesible.

En caso de producirse una partición en el cluster, los nodos que perdieron el acceso al disco heartbeat, también pierden el acceso a datos principales.

La protección de los recursos críticos sirve para evitar la corrupción de datos. El disco heartbeat permite relajar las reglas fencing ya que los nodos sin acceso al disco no pueden modificar datos.

Al lio... Alta disponibilidad con pacemaker

¿Sabes lo que pasa cuando un servicio en producción se  cae?

Servicio caido
Servicio caido

Comencemos a detallar los pasos para tener alta disponibilidad con pacemaker.

Tenemos dos máquinas (nodos)

  1. centos1.dominio.es (192.168.122.248)
  2. centos2.dominio.es (192.168.122.249)

Serán las que nos den el servicio (configuración activo-pasivo). Una de las máquinas será el nodo activo, y la otra será el nodo pasivo, a la espera de ser llamado en caso de un funcionamiento anómalo del nodo activo.

Podríamos tener un sistema de almacenamiento compartido por ambos nodos, donde estuviesen los ficheros donde el Apache (servidor web) acceda a estos.Estaba pensando en DRBD.

Es un sistema de almacenamiento replicado y distribuido (Distributed Replicated Block Device), implementado a nivel de driver de Kernel, que nos permitirá replicar los datos en tiempo real.

Debo pedir disculpas, estoy de viaje y sólo he traído el portátil pequeño. Este ordenador no tiene capacidad para hacer demasiados malabarismos. Me encantaría tener una cabina conectada por fibra, pero vamos a ceñirnos a las posibilidades de este equipo.

El cluster ofrecerá cualquier servicio desde una IP compartida por los nodos del cluster (192.168.122.50).

Como siempre, debemos tener bien cuidado nuestro sistema operativo.

  • sudo yum update

Comprobemos que hay comunicación entre las dos máquinas.

[[email protected] ~]# ping centos2

PING centos2 (192.168.122.249) 56(84) bytes of data.
64 bytes from centos2 (192.168.122.249): icmp_seq=1 ttl=64 time=0.469 ms
64 bytes from centos2 (192.168.122.249): icmp_seq=2 ttl=64 time=0.772 ms

[[email protected] ~]# ping centos1

PING centos1 (192.168.122.248) 56(84) bytes of data.
64 bytes from centos1 (192.168.122.248): icmp_seq=1 ttl=64 time=0.279 ms
64 bytes from centos1 (192.168.122.248): icmp_seq=2 ttl=64 time=0.605 ms

Instalamos el software necesario para los servicios cluster. Este comando debe ser ejecutado en todos los nodos que formarán parte del cluster:

  • yum install pcs pacemaker fence-agents-all

Apertura de puertos en el firewall

Si queremos controlar los puertos abiertos porque hemos habilitado el firewall, esta es la lista de puertos:

  • 2224/TCP. Comunicación entre nodos
  • 3121/TCP. Si el cluster tiene nodos remotos.
  • 5403/TCP. Se necesita si usamos un dispositivo quorum.
  • 5404/UDP. Cuando corosync se configura para UDP multicast
  • 5405/UDP. Necesario para corosync
  • 21064/TCP. Si el cluster contiene recursos DLM (Sincroniza los accesos a recursos compartidos, clvm o GFS2).

La alta disponibilidad con pacemaker no necesita tener todos estos puertos abiertos. Todo depende de la configuración del cluster que nos interese y los recursos a usar.

Aunque podemos hacerlo manualmente, abriendo uno por uno los puertos, si añadimos el servicio «high-availability» lo tenemos listo:

  • firewall-cmd –permanent –add-service=high-availability
  • firewall-cmd –reload

Debemos ejecutarlo en todos los nodos del cluster.

servicios pacemaker y corosync

Hemos instalado los servicios en las dos máquinas. Es tiempo de configurar dichos servicios, empezando por la cuenta de administración HACLUSTER

Para permitir la comunicación entre los nodos, se debe establecer una contraseña para el usuario administrador hacluster. Se recomienda que la contraseña para este usuario sea la misma en cada nodo.

  • passwd hacluster

A continuación habilitamos y arrancamos el daemon PCSD:

  • systemctl enable pcsd.service
  • systemctl start pcsd.service

Comprobaremos que el daemon esté habilitado y ejecutándose correctamente:

  • systemctl status pcsd.service

El siguiente paso es autenticar al usuario hacluster de cada nodo en el cluster.

Nota: Si hemos tenido la idea de poner la misma contraseña en todos los nodos del cluster, sólo necesitaremos ejecutar este comando una vez. La configuración se replicará automaticamente por todos los nodos. En caso contrario, debemos ejecutar este comando en los nodos donde la contraseña de hacluster sea diferente:

  • pcs cluster auth centos1.centos.es centos2.centos.es

Nos pedirá introducir la contraseña del usuario local hacluster.

Username: hacluster
Password:
centos1.centos.es: Authorized
centos2.centos.es: Authorized

En todos los nodos del cluster, se crearán los ficheros de configuración y claves públicas/privadas en la ruta:

/var/lib/pcsd

Si queremos conocer qué características soporta el pacemaker, podemos obtenerlo con:

  • pacemakerd –features

Obteniendo una salida tipo:
Pacemaker 1.1.19-8.el7_6.4 (Build: c3c624ea3d)
Supporting v3.0.14: generated-manpages agent-manpages ncurses libqb-logging libqb-ipc systemd nagios corosync-native atomic-attrd acls

Nota: Comando PCS => pacemaker/corosync configuration system

Tener alta disponibilidad con pacemaker en vuestro cluster es tedioso la primera vez, pero una vez que lo implementéis, es fácil seguir ampliando conocimientos.

Añadiendo configuración al corosync

Ahora que disponemos del comando PCS (controla y configura el pacemaker y corosync), es hora de comenzar a realizar las operaciones propias del cluster.

La configuración de corosync ahora se crea y distribuye en todos los nodos. La configuración se almacena en el archivo /etc/corosync/corosync.conf.

Arrancamos el cluster (start), generamos su configuración (setup), el nombre del cluster (name ClusterWeb) y sincronizamos todos los nodos del cluster:

  • pcs cluster setup –start –name ClusterWeb centos1.centos.es centos2.centos.es

Comprobamos la salida obtenida desde el terminal:

Destroying cluster on nodes: centos1.centos.es, centos2.centos.es…

Sending ‘pacemaker_remote authkey’ to ‘centos1.centos.es’, ‘centos2.centos.es’
centos1.centos.es: successful distribution of the file ‘pacemaker_remote authkey’
centos2.centos.es: successful distribution of the file ‘pacemaker_remote authkey’
Sending cluster config files to the nodes…

Synchronizing pcsd certificates on nodes centos1.centos.es, centos2.centos.es…

Restarting pcsd on the nodes in order to reload the certificates…

He destacado en la salida, las partes donde indica la generación y sincronización de los ficheros «key de autenticación» por todos los nodos del cluster. Estos se guardan en /etc/pacemaker/authkey

Si queremos que los servicios de cluster (pacemaker y corosync) se arranquen de forma automática al reiniciar un nodo, debemos ejecutar:

  • pcs cluster enable –all

A veces, esto no es lo deseable, ya que cuando se produce la caída de un nodo, hay administradores que prefieren investigar la razón de esa caída antes de volver a unirlo al cluster. Si se habilita por defecto, el nodo se uniría automaticamente después de un reinicio. ¿El inconveniente de no habilitarlos por defecto?, debemos estar atentos para levantar los nodos manualmente.

En cualquier momento podemos comprobar el estado del cluster mediante:

  • pcs cluster status

Los primeros comandos para crear un cluster de alta disponibilidad con pacemaker no son complicados, de hecho es bastante intuitivo.

Arrancamos el servicio cluster en todos los nodos:

  • pcs cluster start –all​

Avisos y errores en pcs status

Os describo tres situaciones que pueden producirse cuando se implementa alta disponibilidad con pacemaker.

A veces, cuando ejecutamos:

  • pcs status

Observamos un mensaje tipo:

Node centos2.centos.es: UNCLEAN (offline)

Una de las razones, podría deberse a que en el fichero de hosts tenemos identificado nuestro $HOSTNAME de máquina como 127.0.0.1. En este caso, sólo la definición localhost debería ser 127.0.0.1


Otro caso es cuando vemos el mensaje:

WARNINGS:
No stonith devices and stonith-enabled is not false

Esto en realidad no se trata de un error.

Que un nodo no responda, no significa que haya dejado de acceder a los datos. La única manera de estar seguro es usar Stonith. Así confirmaremos que el nodo está realmente fuera de línea antes de permitir el acceso a los datos desde otro nodo. Esta técnica fencing juega un papel importante en el caso de que un servicio clusterizado no se pueda detener.


Caso diferente es, cuando ejecutamos el siguiente comando de verificación sin tener configurado Stonith:

  • pcs cluster verify -V

Obtendremos:

Error: invalid cib:
error: unpack_resources: Resource start-up disabled since no STONITH resources have been defined
……

Stonith no está configurado, pero pero esta activo. Esto se considera un error. Si deseamos evitar este error debemos desactivarlo con:

  • pcs property set stonith-enabled=false

Entorno reducido

El entorno que estoy montando es pequeño, por ello no es necesario complicarse demasiado con reglas o dispositivos.

En un próximo artículo me centraré en el fencing tanto a nivel de recurso como de nodo, sobre todo para configurar el Stonith y mostraros el proceso.

Para este tutorial debemos indicarle al pacemaker que lo deshabilitamos:

  • pcs property set stonith-enabled=false

Lo repito, ni se os ocurra montar un entorno productivo importante sin contar con algún dispositivo STONITH.

Servidor web

Instalamos el servidor web (Apache) en los dos nodos del cluster:

  • yum install httpd wget

Arrancamos el servidor web en todos los nodos:

  • systemctl enable httpd.service La razón es simple, este servicio al estar clusterizado debe ser controlado por el propio cluster, no por el sistema.
  • systemctl start httpd.service

Comprobamos que el servicio esté ejecutándose con:

  • systemctl status httpd.service

Ahora debemos habilitar los puertos necesarios para el servidor web en el firewall. Ejecutamos los siguientes comandos en todos los nodos:

  • firewall-cmd –permanent –add-service=http
  • firewall-cmd –reload

Necesitamos una forma sencilla de permitir al pacemaker saber si el servidor Web está funcionando correctamente o no. Así que editamos el fichero de configuración de Apache e insertamos al final del fichero:

SetHandler server-status
Require local

De ese modo el pacemaker podrá obtener el estado del servidor web en «/estado».

Para realizar una prueba sencilla, y además saber qué máquina nos responde, crearemos en cada nodo un fichero index.html. Este fichero lo insertaremos, para no tener problemas SELinux, en el directorio html creado por el servidor Apache.

Creamos un fichero index.html en /var/www/html/ e insertamos el nombre del nodo en ese fichero:

  • echo $HOSTNAME > /var/www/html/index.html

Recursos en el pacemaker

Si accediéramos directamente al servidor web mediante la IP de uno de los nodo, dejaría de tener sentido montar un cluster. El acceso sería individualizado y perderíamos las ventajas de la alta disponibilidad.

Necesitamos una IP virtual, que en realidad será la asignada al grupo de todos los nodos. A qué nodo vaya dirigida la petición será cosa del servicio de cluster.

Añadimos la IP de cluster:

  • pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=192.168.122.50 cidr_netmask=32 op monitor interval=20s

Aparte de los parámetros de configuración, tenemos que tener claro que ocf:heartbeat:IPaddr2 es fundamental. Este parámetro le indica al pacemaker dónde encontrar el script de recursos que queremos que use. En otras palabras, es indicarle la ruta donde se encuentra el script IPaddr2 de la clase ocf y el proveedor heartbeat

Es hora de añadir el servicio web en los recursos del cluster:

  • pcs resource create WebApache ocf:heartbeat:apache configfile=/etc/httpd/conf/httpd.conf statusurl=»http://127.0.0.1/estado» op monitor interval=20s

Si todo ha ido bien, deberíamos tener los dos recursos dados de alta y funcionando. Lo comprobamos con:

  • pcs status

Observamos un detalle importante en la salida:

2 resources configured
Online: [ centos1.centos.es centos2.centos.es ]
Full list of resources:
ClusterIP (ocf::heartbeat:IPaddr2): Started centos1.centos.es
WebApache (ocf::heartbeat:apache): Starting centos2.centos.es

Os lo remarco en rojo. Tenemos el recurso ClusterIP asignado al nodo centos1 y el WebApache en el otro nodo. Esto no sería lo correcto, ya que debería ser ofrecido por el nodo activo«, el otro sólo debe estar de reserva (activo-pasivo). De hecho, si hacemos una petición web al cluster nos devolverá un error

curl: (7) Failed connect to 192.168.122.50:80; Conexión rehusada

El cluster envía la petición al nodo centos1, y el servicio Apache no está arrancado porque el cluster lo arrancó en centos2 (WebApache).

Ánimo, sólo quedan dos pasos para terminar esta guía de ​alta disponibilidad con Pacemaker.

Retricciones a los recursos del cluster

No hemos indicado al Pacemaker que los recursos deben ejecutarse en el mismo nodo, por eso los ha distribuido uniformemente. Para el cluster cada recurso es inicialmente independiente de los otros.

Se puede reiniciar cualquier recurso con:

  • pcs resource restart «nombre_recurso»

Nota importante: Asegúrate que los nodos del cluster no tengan habilitado iniciar ningún servicio clusterizado en el momento del arranque. Esos servicios deben ser controlados por el cluster. Si no controlas esto puedes generar casos de error como:

WebApache (ocf::heartbeat:apache): Stopped
Failed Actions:
* WebServer_start_0 on centos1.centos.es ‘unknown error’ (1): call=12, status=Timed Out, exitreason=»,
last-rc-change=’Sun Jun 23 16:55:45 2019′, queued=0ms, exec=40002ms

Para evitar situaciones como la que tenemos, los recursos repartidos por cualquier nodo, podemos indicarle al cluster nuestro deseo de agrupar los recursos.

Las decisiones que toma el cluster con los recursos pueden alterarse con las restricciones. Comando «pcs constraint …»

Las restricciones tienen una puntuación. Si una restricción tiene una puntuación inferior a INFINITY, esta sólo será una recomendación, pero una puntuación INFINITY significa que es una condición obligatoria.

Los valores positivos de puntuación
significan que los recursos deben ejecutarse en el mismo nodo, valores negativos
significa que los recursos no deben ejecutarse en el mismo nodo.

El intervalo será de INFINITY hasta -INFINITY.

Ambos recursos deben ejecutarse en el mismo nodo, por lo que definiremos una restricción:

  • pcs constraint colocation add WebApache ClusterIP INFINITY

El orden de los recursos en el comando es importante. El comando anterior especifica que el recurso Apache (WebApache) debe ejecutarse en los mismos nodos en los que esté activa ClusterIP. Significa a su vez que WebApache no puede ejecutarse en ningún nodo si ClusterIP no está activo

Podemos ver los estados del cambio de nodo:

  1. WebApache (ocf::heartbeat:apache): Started centos2.centos.es

  2. WebApache (ocf::heartbeat:apache): Started centos1.centos.es (Monitoring)

Organizando el arranque de los recursos

Otro detalle que podría ser importante en algunos clusters es el orden en que el propio cluster arranca los recursos.

Por ejemplo:

Un cluster intenta arrancar un servidor Apache que tiene su directorio «DocumentRoot» en un volumen compartido, antes de montar el propio volumen. Obviamente, se producirá un error, por lo que es necesario indicarle el orden de arranque y parada de los recursos.

Esto se soluciona con el comando:

pcs constraint [action] then [action] [options]

Donde por defecto, action toma el valor de «start»

Ejecutamos el siguiente comando:

  • pcs constraint order ClusterIP then WebApache

Obteniendo la salida por consola:

Adding ClusterIP WebApache (kind: Mandatory) (Options: first-action=start then-action=start)

Apenas un último paso para disfrutar de ​alta disponibilidad con Pacemaker.

Comprobemos toda la configuración que hemos ido insertando en el cluster:

  • pcs config

Vamos a centrarnos en los últimos valores añadidos:

Resources:
Resource: ClusterIP (class=ocf provider=heartbeat type=IPaddr2)
Attributes: cidr_netmask=32 ip=192.168.122.50
Operations: monitor interval=20s (ClusterIP-monitor-interval-20s)
start interval=0s timeout=20s (ClusterIP-start-interval-0s)
stop interval=0s timeout=20s (ClusterIP-stop-interval-0s)
Resource: WebApache (class=ocf provider=heartbeat type=apache)
Attributes: configfile=/etc/httpd/conf/httpd.conf statusurl=http://127.0.0.1/estado
Operations: monitor interval=20s (WebApache-monitor-interval-20s)
start interval=0s timeout=40s (WebApache-start-interval-0s)
stop interval=0s timeout=60s (WebApache-stop-interval-0s)

Stonith Devices:
Fencing Levels:

Location Constraints:
Ordering Constraints:
start ClusterIP then start WebApache (kind:Mandatory)
Colocation Constraints:
WebApache with ClusterIP (score:INFINITY)

Probando la alta disponibilidad con Pacemaker

Tenemos listo el servicio Apache clusterizado. Si accedemos desde cualquier navegador a la dirección:

http://192.168.122.50

Accedemos a la respuesta del nodo que esté en ese momento en activo.

Como sabemos que el nodo activo es centos1, si realizamos un petición deberíamos obtener el mensaje su $HOSTNAME.

Pacemaker nodo1
Pacemaker nodo1

Tal como esperábamos, el nodo activo (centos1) responde.

Ahora bien, queremos hacer trabajar al cluster, así que forzaremos un cambio de nodo:

  • pcs cluster standby centos1.centos.es

Tras ejecutar el comando, el nodo activo deberá cambiar a centos2. Vamos a confirmarlo:

Full list of resources:
ClusterIP (ocf::heartbeat:IPaddr2): Started centos2.centos.es
WebApache (ocf::heartbeat:apache): Started centos2.centos.es

Correcto, a partir de ahora si lanzamos otra petición a la misma dirección, obtendremos el $HOSTNAME de ese nodo.

Pacemaker nodo2
Pacemaker nodo2

La alta disponibilidad con Pacemaker ha funcionado correctamente.

Nota: Si queremos volver al estado normal del nodo, deberemos ejecutar:

  • pcs cluster unstandby centos1.centos.es

Optimizando el cluster

Es conveniente evitar que los recursos se muevan entre los nodos del cluster. Mover un recurso casi siempre requiere un tiempo de inactividad, más para servicios complejos como bases de datos.

Pacemaker tiene el concepto de stickiness (adherencia) de los recursos. Con este opción, controlamos que los recursos prefieran mantenerse funcionando donde están.Es como si cuantificáramos el «costo» de la migración de recursos (inactividad).

De forma predeterminada, Pacemaker asume que hay un costo cero asociado a ese movimiento y lo hará para lograr una colocación de recursos «óptima».

Podemos especificar un «costo» diferente para cada recurso, o cambiar el valor predeterminado para todos.

  • pcs resource defaults resource-stickiness=100

Con ello asignamos un valor de 100 al «defaults» (todos los recursos).

 

Esto tiene mucho que ver con el siguiente comando. Si tenemos un cluster con nodos diferentes, y deseamos que algunos nodos más potentes ejecuten los servicios más pesados, tenemos la herramienta para indicarlo:

  • pcs constraint location WebApache prefers centos1.centos.es=50

Y aquí viene lo más importante:

Aunque hayamos preferido con un 50, que centos1.centos.es ejecute el servicio Apache, al haber configurado anteriormente el «resource-stickiness» con un valor 100, lo impedirá. En otras palabras, se decide que pesa más el «costo» de la migración del servicio Apache que la máquina pueda dar mejor servicio.

Aquí concluye esta breve introducción a la alta disponibilidad con Pacemaker.

Deja un comentario

Cerrar menú