En este documento se explica cómo crear un clúster de tres nodos en Linux con Pacemaker y cómo agregar un grupo de disponibilidad creado anteriormente como un recurso en el clúster. Para lograr una alta disponibilidad, un grupo de disponibilidad en Linux necesita tres nodos (vea High availability and data protection for availability group configurations [Alta disponibilidad y protección de datos para configuraciones de grupos de disponibilidad]).
SQL Server no está tan estrechamente integrado con Pacemaker en Linux como lo está con los clústeres de conmutación por error de Windows Server (WSFC). Una instancia de SQL Server no es consciente del clúster y toda la orquestación procede del exterior. Pacemaker proporciona orquestación del recurso de clúster. Además, el nombre de red virtual es específico de los clústeres de conmutación por error de Windows Server (no hay equivalente en Pacemaker). Las vistas de administración dinámica (DMV) de los grupos de disponibilidad que consultan información del clúster devuelven filas vacías en los clústeres de Pacemaker. Para crear un cliente de escucha para la reconexión transparente tras una conmutación por error, registre de forma manual el nombre del cliente de escucha en DNS con la dirección IP empleada para crear el recurso de dirección IP virtual.
En las siguientes secciones se siguen los pasos necesarios para configurar un clúster de Pacemaker y agregar un grupo de disponibilidad como recurso en el clúster de alta disponibilidad para cada distribución de Linux admitida.
La capa de agrupación en clústeres se basa en el complemento de alta disponibilidad de Red Hat Enterprise Linux (RHEL) sobre Pacemaker.
Nota
El acceso a toda la documentación de Red Hat exige una suscripción válida.
Para obtener más información sobre la configuración del clúster, las opciones de los agentes de recursos y la administración, vaya a la documentación de referencia de RHEL.
Plan de desarrollo
Los pasos necesarios para crear un grupo de disponibilidad en servidores con Linux de alta disponibilidad son distintos de los exigidos en un clúster de conmutación por error de Windows Server. En la lista siguiente, se describen los pasos generales:
Configure SQL Server en los nodos del clúster.
Cree el grupo de disponibilidad.
Configure un administrador de recursos de clúster, como Pacemaker. Estas instrucciones se incluyen en este artículo.
La manera de configurar un administrador de recursos de clúster depende de la distribución específica de Linux.
Importante
Para alcanzar una alta disponibilidad, los entornos de producción necesitan un agente de barrera. En los ejemplos de esta documentación no se usan agentes de barrera. Los ejemplos solo se proporcionan con fines de prueba y validación.
Un clúster de Linux usa barreras para devolver el clúster a un estado conocido. La forma de configurar las barreras depende de la distribución y del entorno. Actualmente, las barreras no están disponibles en algunos entornos de nube. Para más información, vea Directivas de soporte para clústeres de alta disponibilidad de RHEL: plataformas de virtualización.
Agregue el grupo de disponibilidad como un recurso en el clúster.
Para configurar la alta disponibilidad de RHEL, habilite la suscripción de alta disponibilidad y, luego, configure Pacemaker.
Habilitación de la suscripción de alta disponibilidad de RHEL
Cada nodo del clúster debe tener una suscripción adecuada de RHEL y el complemento de alta disponibilidad. Revise los requisitos de Cómo instalar paquetes de clúster de alta disponibilidad en Red Hat Enterprise Linux. Siga estos pasos para configurar la suscripción y los repositorios:
Registre el sistema.
sudo subscription-manager register
Proporcione el nombre de usuario y la contraseña.
Enumere los grupos disponibles para el registro.
sudo subscription-manager list --available
En la lista de grupos disponibles, anote el identificador de grupo de la suscripción de alta disponibilidad.
Actualice el script siguiente. Reemplace <pool id>
por el identificador de grupo de alta disponibilidad del paso anterior. Ejecute el script para asociar la suscripción.
sudo subscription-manager attach --pool=<pool id>
Habilite el repositorio.
RHEL 7
sudo subscription-manager repos --enable=rhel-ha-for-rhel-7-server-rpms
RHEL 8
sudo subscription-manager repos --enable=rhel-8-for-x86_64-highavailability-rpms
Para obtener más información, vea Pacemaker: el clúster de alta disponibilidad de código abierto.
Una vez configurada la suscripción, realice los pasos siguientes para configurar Pacemaker:
Una vez registrada la suscripción, realice los pasos siguientes para configurar Pacemaker:
En todos los nodos de clúster, abra los puertos de firewall de Pacemaker. Para abrir estos puertos con firewalld
, ejecute el comando siguiente:
sudo firewall-cmd --permanent --add-service=high-availability
sudo firewall-cmd --reload
Si el firewall no tiene una configuración de alta disponibilidad integrada, abra los puertos siguientes para Pacemaker.
- TCP: puertos 2224, 3121, 21064
- UDP: puerto 5405
Instale paquetes de Pacemaker en todos los nodos.
sudo yum install pacemaker pcs fence-agents-all resource-agents
Establezca la contraseña para el usuario predeterminado que se crea al instalar paquetes de Pacemaker y Corosync. Use la misma contraseña en todos los nodos.
sudo passwd hacluster
Para permitir que los nodos vuelvan a unirse al clúster después del reinicio, habilite e inicie el servicio pcsd
y Pacemaker. Ejecute el siguiente comando en todos los nodos.
sudo systemctl enable pcsd
sudo systemctl start pcsd
sudo systemctl enable pacemaker
Cree el clúster. Para crear el clúster, ejecute el comando siguiente:
RHEL 7
sudo pcs cluster auth <node1> <node2> <node3> -u hacluster -p <password for hacluster>
sudo pcs cluster setup --name <clusterName> <node1> <node2> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all
RHEL 8
Para RHEL 8, tendrá que autenticar los nodos por separado. Escriba manualmente el nombre de usuario y la contraseña de hacluster cuando se le solicite.
sudo pcs host auth <node1> <node2> <node3>
sudo pcs cluster setup <clusterName> <node1> <node2> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all
Nota
Si ya ha configurado un clúster en los mismos nodos, necesita usar la opción --force
al ejecutar pcs cluster setup
. Esta opción es equivalente a ejecutar pcs cluster destroy
. Para volver a habilitar Pacemaker, ejecute sudo systemctl enable pacemaker
.
Instale el agente de recursos de SQL Server para SQL Server. Ejecute los siguientes comandos en todos los nodos.
sudo yum install mssql-server-ha
Una vez configurado Pacemaker, use pcs
para interactuar con el clúster. Ejecute todos los comandos en un nodo del clúster.
Consideraciones para varias interfaces de red (NIC)
Al configurar la alta disponibilidad con servidores que tienen varias NIC, siga estas sugerencias:
Asegúrese de que el archivo hosts
está configurado para que las direcciones IP del servidor para las varias NIC se resuelvan en el nombre de host del servidor Linux en cada nodo.
Al configurar el clúster con Pacemaker, usar el nombre de host de los servidores debe configurar Corosync para establecer la configuración de todas las NIC. Solo queremos la comunicación de Pacemaker/Corosync a través de una sola NIC. Una vez configurado el clúster de Pacemaker, modifique la configuración en el archivo corosync.conf
y actualice la dirección IP de la NIC dedicada que quiere usar para la comunicación de Pacemaker/Corosync.
El <hostname>
especificado en el archivo corosync.conf
debe ser el mismo que el resultado proporcionado al realizar una búsqueda inversa (ping -a <ip_address>
) y debe ser el nombre corto configurado en el host. Asegúrese de que el archivo hosts
también representa la dirección IP adecuada para la resolución de nombres.
Los cambios en archivo corosync.conf
de ejemplo se resaltan a continuación:
nodelist {
node {
ring0_addr: <ip_address_of_node1_NIC1>
name: <hostname_of_node1>
nodeid: 1
}
node {
ring0_addr: <ip_address_of_node2_NIC1>
name: <hostname_of_node2>
nodeid: 2
}
node {
ring0_addr: <ip_address_of_node3_NIC1>
name: <hostname_of_node3>
nodeid: 3
}
}
Para admitir la configuración del clúster, los proveedores de clústeres de Pacemaker requieren que se cree una barrera en un nodo erróneo y que se configure un dispositivo de barrera. Si el administrador de recursos de clúster no puede determinar el estado de un nodo o de un recurso de un nodo, las barreras devuelven al clúster a un estado conocido.
Un dispositivo de barrera proporciona un agente de barrera. En Configuración de Pacemaker en Red Hat Enterprise Linux en Azure se proporciona un ejemplo de cómo crear un dispositivo de barrera para este clúster en Azure. Modifique las instrucciones para el entorno.
Mediante la configuración de un recurso, la barrera de nivel de recurso garantiza que los datos no se dañen por una interrupción. Por ejemplo, puede usar la barrera de nivel de recurso para marcar el disco de un nodo como obsoleto cuando el vínculo de comunicación se interrumpe.
La barrera de nivel de nodo garantiza que un nodo no ejecute ningún recurso. Esto se hace mediante el restablecimiento del nodo. Pacemaker admite una gran variedad de dispositivos de barrera. Los ejemplos incluyen un sistema de alimentación ininterrumpida o tarjetas de interfaz de administración para servidores.
Para obtener información sobre la creación de barreras en un nodo con errores, vea los siguientes artículos:
Nota
Dado que la configuración de la barrera de nivel de nodo depende en gran medida del entorno, deshabilítela para este tutorial (se puede configurar más adelante). El siguiente script deshabilita la barrera de nivel de nodo:
sudo pcs property set stonith-enabled=false
Solo deshabilite las barreras con fines de prueba. Si tiene previsto usar Pacemaker en un entorno de producción, necesita planear una implementación de barrera basada en su entorno y mantenerla habilitada.
Establecer la propiedad del clúster cluster-recheck-interval
cluster-recheck-interval
indica el intervalo de sondeo por el que el clúster comprueba los cambios en los parámetros de recursos, las restricciones u otras opciones del clúster. Si una réplica se interrumpe, el clúster intenta reiniciarla en un intervalo que depende de los valores failure-timeout
y cluster-recheck-interval
. Por ejemplo, si failure-timeout
se establece en 60 segundos y cluster-recheck-interval
se establece en 120 segundos, el reinicio se intenta en un intervalo mayor de 60 segundos pero menor de 120 segundos. Se recomienda establecer el valor de failure-timeout en 60 segundos y cluster-recheck-interval
en un valor superior a 60 segundos. No se recomienda establecer cluster-recheck-interval
en un valor pequeño.
Para actualizar el valor de la propiedad a 2 minutes
, ejecute:
sudo pcs property set cluster-recheck-interval=2min
Si ya dispone de un recurso de grupo de disponibilidad administrado por un clúster de Pacemaker, el paquete de Pacemaker (1.1.18 -11.el7) introdujo un cambio de comportamiento para el valor de configuración del clúster start-failure-is-fatal
cuando su valor es false
. Este cambio afecta al flujo de trabajo de conmutación por error. Si una réplica principal deja de funcionar, se espera que el clúster conmute por error a una de las réplicas secundarias disponibles. En su lugar, los usuarios observan que el clúster sigue intentando iniciar la réplica principal que ha experimentado el error. Si esa réplica principal no vuelve a activarse (debido a un corte de luz permanente), el clúster nunca conmuta por error a otra réplica secundaria disponible. Debido a este cambio, la recomendación anterior de configurar start-failure-is-fatal
ya no es válida y es necesario revertir a su valor predeterminado de true
.
Además, el recurso de grupo de disponibilidad debe actualizarse para incluir la propiedad failure-timeout
.
Para actualizar el valor de la propiedad a true
, ejecute:
sudo pcs property set start-failure-is-fatal=true
Para actualizar la propiedad failure-timeout
del recurso ag_cluster
a 60s
, ejecute:
pcs resource update ag_cluster meta failure-timeout=60s
Para obtener información sobre las propiedades de clúster de Pacemaker, vea Propiedades de clúster de Pacemaker.
Crear un inicio de sesión de SQL Server para Pacemaker
En todas las instancias de SQL Server, cree un inicio de sesión en el servidor para Pacemaker.
La siguiente instrucción Transact-SQL crea un inicio de sesión:
USE [master]
GO
CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
En el momento de crear el grupo de disponibilidad, el usuario de Pacemaker necesita permisos ALTER
, CONTROL
y VIEW DEFINITION
en el grupo de disponibilidad, una vez creado, pero antes de que se le agreguen nodos.
En todas las instancias de SQL Server, guarde las credenciales para el inicio de sesión de SQL Server.
echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
Crear un recurso de grupo de disponibilidad
Para crear el recurso de grupo de disponibilidad, use el comando pcs resource create
y establezca las propiedades del recurso. El comando siguiente crea un recurso ocf:mssql:ag
de tipo principal/secundario para el grupo de disponibilidad con el nombre ag1
.
RHEL 7
sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=60s master notify=true
RHEL 8
Con la disponibilidad de RHEL 8, la sintaxis de Create ha cambiado. Si usa RHEL 8, la terminología master
ha cambiado a promotable
. Use el comando CREATE siguiente en lugar del comando anterior:
sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=60s promotable notify=true
Nota
Cuando crea el recurso, y posteriormente de forma periódica, el agente del recurso de Pacemaker establece automáticamente el valor de REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
en el grupo de disponibilidad según la configuración del grupo. Por ejemplo, si el grupo de disponibilidad tiene tres réplicas sincrónicas, el agente establecerá REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
en 1
. Para detalles y opciones de configuración adicional, consulte el artículo sobre alta disponibilidad y protección de datos para configuraciones de grupos de disponibilidad.
Creación de un recurso de dirección IP virtual
Para crear el recurso de dirección IP virtual, ejecute el comando siguiente en un nodo. Use una dirección IP estática disponible de la red. Reemplace la dirección IP entre <10.128.16.240>
por una dirección IP válida.
sudo pcs resource create virtualip ocf:heartbeat:IPaddr2 ip=<10.128.16.240>
No hay ningún nombre de servidor virtual equivalente en Pacemaker. Para usar una cadena de conexión que apunte a un nombre de servidor de cadena en lugar de a una dirección IP, registre la dirección de recurso de dirección IP virtual y el nombre de servidor virtual deseado en DNS. En el caso de las configuraciones de recuperación ante desastres, registre el nombre de servidor virtual que prefiera y la dirección IP con los servidores DNS en el sitio principal y en el sitio de recuperación ante desastres.
Agregar una restricción de ubicación
Casi todas las decisiones de un clúster de Pacemaker, por ejemplo elegir dónde se debe ejecutar un recurso, se toman mediante la comparación de puntuaciones. Las puntuaciones se calculan por recurso. El administrador de recursos de clúster elige el nodo con la puntuación más alta para un recurso determinado. Si un nodo tiene una puntuación negativa para un recurso, el recurso no se puede ejecutar en ese nodo.
En un clúster de Pacemaker, las decisiones del clúster se pueden manipular mediante restricciones. Las restricciones tienen una puntuación. Si una restricción tiene una puntuación inferior a INFINITY
, Pacemaker la considera como una recomendación. Una puntuación de INFINITY
es obligatoria.
Para garantizar que los recursos de réplica principal y dirección IP virtual se ejecutan en el mismo host, defina una restricción de ubicación con una puntuación de INFINITY. Para agregar la restricción de ubicación, ejecute el comando siguiente en un nodo.
RHEL 7
Cuando crea el recurso ag_cluster
en RHEL 7, se crea el recurso como ag_cluster-master
. Use el siguiente comando para RHEL 7:
sudo pcs constraint colocation add virtualip ag_cluster-master INFINITY with-rsc-role=Master
RHEL 8
Cuando crea el recurso ag_cluster
en RHEL 8, se crea el recurso como ag_cluster-clone
. Use el siguiente comando para RHEL 8:
sudo pcs constraint colocation add virtualip with master ag_cluster-clone INFINITY with-rsc-role=Master
Agregar una restricción de ordenación
La restricción de ubicación tiene una restricción de orden implícita. Mueve el recurso de dirección IP virtual antes de mover el recurso de grupo de disponibilidad. La secuencia de eventos predeterminada es la siguiente:
El usuario envía pcs resource move
a la réplica principal del grupo de disponibilidad desde el nodo1 al nodo2.
El recurso de dirección IP virtual se detiene en el nodo 1.
El recurso de dirección IP virtual se inicia en el nodo 2.
Nota
En este punto, la dirección IP apunta temporalmente al nodo 2, mientras que el nodo 2 sigue siendo una réplica secundaria previa a la conmutación por error.
La réplica principal del grupo de disponibilidad del nodo 1 se degrada a secundario.
La réplica secundaria del grupo de disponibilidad del nodo 2 se asciende a principal.
Para evitar que la dirección IP apunte temporalmente al nodo con la réplica secundaria previa a la conmutación por error, agregue una restricción de ordenación.
Para agregar una restricción de orden, ejecute el siguiente comando en un nodo:
RHEL 7
sudo pcs constraint order promote ag_cluster-master then start virtualip
RHEL 8
sudo pcs constraint order promote ag_cluster-clone then start virtualip
Importante
Después de configurar el clúster y agregar el grupo de disponibilidad como un recurso de clúster, no puede usar Transact-SQL para conmutar por error los recursos del grupo de disponibilidad. Los recursos de clúster de SQL Server en Linux no están tan bien integrados con el sistema operativo como lo están en un clúster de conmutación por error de Windows Server (WSFC). El servicio SQL Server no reconoce la presencia del clúster. Toda la orquestación se realiza con las herramientas de administración de clústeres. En RHEL o Ubuntu, use pcs
; en SLES, use las herramientas de crm
.
Realice una conmutación por error manual del grupo de disponibilidad con pcs
. No inicie la conmutación por error con Transact-SQL. Para obtener instrucciones, vea Conmutación por error.
Contenido relacionado
La capa de agrupación en clústeres se basa en SUSE High Availability Extension (HAE) desarrollado sobre Pacemaker.
Para obtener más información sobre la configuración del clúster, las opciones del agente de recursos y la administración, así como para obtener recomendaciones y ver los procedimientos recomendados, vea SUSE Linux Enterprise High Availability Extension.
Plan de desarrollo
El procedimiento para crear un grupo de disponibilidad para alta disponibilidad difiere entre los servidores Linux y un clúster de conmutación por error de Windows Server. En la lista siguiente, se describen los pasos generales:
Configure SQL Server en los nodos del clúster.
Cree el grupo de disponibilidad.
Configure un administrador de recursos de clúster, como Pacemaker. Estas instrucciones se incluyen en este artículo.
La manera de configurar un administrador de recursos de clúster depende de la distribución específica de Linux.
Importante
Para alcanzar una alta disponibilidad, los entornos de producción necesitan un agente de barrera. En los ejemplos de este artículo no se usan agentes de barrera. Solo se admiten para pruebas y validación.
Un clúster de Linux usa barreras para devolver el clúster a un estado conocido. La forma de configurar las barreras depende de la distribución y del entorno. Actualmente, las barreras no están disponibles en algunos entornos de nube. Para obtener más información, consulte la Extensión de alta disponibilidad de SUSE Linux Enteprise.
Agregue el grupo de disponibilidad como un recurso en el clúster
Requisitos previos
Para completar el siguiente escenario integral, necesita tres equipos en los que implementar el clúster de tres nodos. En los pasos siguientes se describe cómo configurar estos servidores.
El primer paso es configurar el sistema operativo en los nodos del clúster. A efectos de este tutorial, use SLES 12 SP3 con una suscripción válida para el complemento de alta disponibilidad.
Instale y configure el servicio SQL Server en todos los nodos. Para obtener instrucciones detalladas, vea Guía de instalación de SQL Server en Linux.
Designe un nodo como principal y otros nodos como secundarios. Use estos términos a lo largo de esta guía.
Asegúrese de que los nodos que van a formar parte del clúster pueden comunicarse entre sí.
En el ejemplo siguiente se muestra /etc/hosts
con adiciones para tres nodos denominados SLES1, SLES2 y SLES3.
127.0.0.1 localhost
10.128.16.33 SLES1
10.128.16.77 SLES2
10.128.16.22 SLES3
Todos los nodos de clúster deben poder acceder entre sí mediante SSH. Herramientas como hb_report
o crm_report
(para la solución de problemas) y History Explorer de Hawk requieren un acceso SSH sin contraseña entre los nodos, ya que, de lo contrario, puede que solo recopilen datos desde el nodo actual. En caso de usar un puerto SSH no estándar, use la opción -X (vea la página man
). Por ejemplo, si el puerto SSH es 3479, invoque crm_report
del siguiente modo:
sudo crm_report -X "-p 3479" [...]
Para obtener más información, consulte la sección Miscelánea de la Guía de administración de SLES.
Crear un inicio de sesión de SQL Server para Pacemaker
En todas las instancias de SQL Server, cree un inicio de sesión en el servidor para Pacemaker.
La siguiente instrucción Transact-SQL crea un inicio de sesión:
USE [master]
GO
CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
En el momento de crear el grupo de disponibilidad, el usuario de Pacemaker necesita permisos ALTER
, CONTROL
y VIEW DEFINITION
en el grupo de disponibilidad, una vez creado, pero antes de que se le agreguen nodos.
En todas las instancias de SQL Server, guarde las credenciales para el inicio de sesión de SQL Server.
echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
En los servidores Linux, configure el grupo de disponibilidad y, después, configure los recursos de clúster. Para configurar el grupo de disponibilidad, vea Configuración de un grupo de disponibilidad Always On de SQL Server para alta disponibilidad en Linux
Instale la extensión High Availability.
Como referencia, consulte Instalación de SUSE Linux Enterprise Server y la extensión High Availability.
Instale el paquete del agente de recursos de SQL Server en ambos nodos.
sudo zypper install mssql-server-ha
Configuración del primer nodo
Como referencia, vea las instrucciones de instalación de SLES.
Inicie sesión como root
en la máquina física o virtual que desee usar como nodo de clúster.
Para iniciar el script de arranque, ejecute:
sudo ha-cluster-init
Si NTP no se ha configurado para que se inicie durante el arranque, aparecerá un mensaje.
Si decide continuar de todas formas, el script generará automáticamente las claves para el acceso SSH y la herramienta de sincronización Csync2, e iniciará los servicios necesarios para ambos.
Para configurar la capa de comunicación del clúster (Corosync):
Especifique una dirección de red a la que realizar el enlace. De forma predeterminada, el script propone la dirección de red de eth0. Si lo prefiere, escriba otra dirección de red, como, por ejemplo, la dirección de bond0.
Especifique una dirección de multidifusión. El script propone una dirección aleatoria que se puede usar como predeterminada.
Especifique un puerto multidifusión. De forma predeterminada, el script propone 5405.
Para configurar SBD ()
, especifique una ruta de acceso persistente a la partición del dispositivo de bloque que desea usar para SBD. La ruta de acceso debe ser coherente en todos los nodos del clúster.
Por último, el script iniciará el servicio Pacemaker para poner en línea el clúster de un nodo y habilitar la interfaz de administración web Hawk2. La dirección URL que se va a usar para Hawk2 se muestra en la pantalla.
Para obtener detalles sobre el proceso de instalación, vea /var/log/sleha-bootstrap.log
. Ahora tiene un clúster de un nodo en ejecución. Compruebe el estado del clúster con crm status:
sudo crm status
También puede ver la configuración de clúster con crm configure show xml
o crm configure show
.
El procedimiento de arranque crea un usuario de Linux denominado hacluster con la contraseña linux. En cuanto pueda, reemplace la contraseña predeterminada por una segura:
sudo passwd hacluster
Adición de nodos al clúster existente
Si tiene un clúster que se ejecuta con uno o más nodos, agregue más nodos de clúster con el script de arranque ha-cluster-join. El script solo necesita acceso a un nodo de clúster existente y completará automáticamente la configuración básica en el equipo actual. Siga estos pasos:
Si ha configurado los nodos de clúster existentes con el módulo de clúster YaST
, asegúrese de que se cumplen los siguientes requisitos previos antes de ejecutar ha-cluster-join
:
- El usuario raíz en los nodos existentes tiene claves SSH para el inicio de sesión sin contraseña.
Csync2
está configurado en los nodos existentes. Para obtener más información, consulte Configuración de Csync2 con YaST.
Inicie sesión como root
en la máquina física o virtual que debe unirse al clúster.
Para iniciar el script de arranque, ejecute:
sudo ha-cluster-join
Si NTP no se ha configurado para que se inicie durante el arranque, aparecerá un mensaje.
Si decide continuar de todos modos, se le pedirá que facilite la dirección IP de un nodo existente. Especifique la dirección IP.
Si aún no ha configurado un acceso SSH sin contraseña entre ambos equipos, también se le pedirá la contraseña raíz del nodo existente.
Después de iniciar sesión en el nodo especificado, el script copia la configuración de Corosync, configura SSH y Csync2
, y conecta en línea el equipo actual como nuevo nodo de clúster. Además de eso, inicia el servicio necesario para Hawk. Si ha configurado el almacenamiento compartido con OCFS2
, también creará automáticamente el directorio mountpoint para el sistema de archivos OCFS2
.
Repita los pasos anteriores para todas las máquinas que desee agregar al clúster.
Para obtener más información sobre el proceso, vea /var/log/ha-cluster-bootstrap.log
.
Compruebe el estado del clúster con sudo crm status
. Si ha agregado el segundo nodo correctamente, el resultado debe parecerse al siguiente:
sudo crm status
Verá un resultado similar al del siguiente ejemplo.
3 nodes configured
1 resource configured
Online: [ SLES1 SLES2 SLES3]
Full list of resources:
admin_addr (ocf::heartbeat:IPaddr2): Started node1
Nota:
admin_addr
es el recurso de clúster de IP virtual que se configura durante la configuración inicial del clúster de un nodo.
Después de agregar todos los nodos, compruebe si necesita ajustar no-quorum-policy en las opciones globales del clúster. Esto es especialmente importante para los clústeres de dos nodos.
Establecer la propiedad del clúster cluster-recheck-interval
cluster-recheck-interval
indica el intervalo de sondeo por el que el clúster comprueba los cambios en los parámetros de recursos, las restricciones u otras opciones del clúster. Si una réplica se interrumpe, el clúster intenta reiniciarla en un intervalo que depende de los valores failure-timeout
y cluster-recheck-interval
. Por ejemplo, si failure-timeout
se establece en 60 segundos y cluster-recheck-interval
se establece en 120 segundos, el reinicio se intenta en un intervalo mayor de 60 segundos pero menor de 120 segundos. Se recomienda establecer el valor de failure-timeout en 60 segundos y cluster-recheck-interval
en un valor superior a 60 segundos. No se recomienda establecer cluster-recheck-interval
en un valor pequeño.
Para actualizar el valor de la propiedad a 2 minutes
, ejecute:
crm configure property cluster-recheck-interval=2min
Si ya dispone de un recurso de grupo de disponibilidad administrado por un clúster de Pacemaker, el paquete de Pacemaker (1.1.18 -11.el7) introdujo un cambio de comportamiento para el valor de configuración del clúster start-failure-is-fatal
cuando su valor es false
. Este cambio afecta al flujo de trabajo de conmutación por error. Si una réplica principal deja de funcionar, se espera que el clúster conmute por error a una de las réplicas secundarias disponibles. En su lugar, los usuarios observan que el clúster sigue intentando iniciar la réplica principal que ha experimentado el error. Si esa réplica principal no vuelve a activarse (debido a un corte de luz permanente), el clúster nunca conmuta por error a otra réplica secundaria disponible. Debido a este cambio, la recomendación anterior de configurar start-failure-is-fatal
ya no es válida y es necesario revertir a su valor predeterminado de true
.
Además, el recurso de grupo de disponibilidad debe actualizarse para incluir la propiedad failure-timeout
.
Para actualizar el valor de la propiedad a true
, ejecute:
crm configure property start-failure-is-fatal=true
Actualice la propiedad failure-timeout
del recurso del grupo de disponibilidad existente a 60s
(reemplace ag1
por el nombre de su recurso del grupo de disponibilidad):
crm configure edit ag1
En el editor de texto, agregue meta failure-timeout=60s
después de cualquier param
y antes de cualquier op
.
Para más información sobre las propiedades de clúster de Pacemaker, vea Configuración de recursos de clúster.
Consideraciones para varias interfaces de red (NIC)
Al configurar la alta disponibilidad con servidores que tienen varias NIC, siga estas sugerencias:
Asegúrese de que el archivo hosts
está configurado para que las direcciones IP del servidor para las varias NIC se resuelvan en el nombre de host del servidor Linux en cada nodo.
Al configurar el clúster con Pacemaker, usar el nombre de host de los servidores debe configurar Corosync para establecer la configuración de todas las NIC. Solo queremos la comunicación de Pacemaker/Corosync a través de una sola NIC. Una vez configurado el clúster de Pacemaker, modifique la configuración en el archivo corosync.conf
y actualice la dirección IP de la NIC dedicada que quiere usar para la comunicación de Pacemaker/Corosync.
El <hostname>
especificado en el archivo corosync.conf
debe ser el mismo que el resultado proporcionado al realizar una búsqueda inversa (ping -a <ip_address>
) y debe ser el nombre corto configurado en el host. Asegúrese de que el archivo hosts
también representa la dirección IP adecuada para la resolución de nombres.
Los cambios en archivo corosync.conf
de ejemplo se resaltan a continuación:
nodelist {
node {
ring0_addr: <ip_address_of_node1_NIC1>
name: <hostname_of_node1>
nodeid: 1
}
node {
ring0_addr: <ip_address_of_node2_NIC1>
name: <hostname_of_node2>
nodeid: 2
}
node {
ring0_addr: <ip_address_of_node3_NIC1>
name: <hostname_of_node3>
nodeid: 3
}
}
Para admitir la configuración del clúster, los proveedores de clústeres de Pacemaker requieren que se cree una barrera en un nodo erróneo y que se configure un dispositivo de barrera. Si el administrador de recursos de clúster no puede determinar el estado de un nodo o de un recurso de un nodo, las barreras devuelven al clúster a un estado conocido.
Mediante la configuración de un recurso, la barrera de nivel de recursos garantiza principalmente que los datos no se dañan si se produce una interrupción. Por ejemplo, puede usar la barrera de nivel de recurso con DRBD (dispositivo de bloque replicado distribuido) para marcar el disco de un nodo como obsoleto cuando el enlace de comunicaciones deje de funcionar.
La barrera de nivel de nodo garantiza que un nodo no ejecute ningún recurso. Para ello, se restablece el nodo, cuya implementación en Pacemaker se denomina STONITH. Pacemaker admite una gran variedad de dispositivos de barrera, como una fuente de alimentación ininterrumpida o tarjetas de interfaz de administración para servidores.
Para más información, consulte:
En el momento de la inicialización del clúster, la barrera se deshabilita si no se detecta ninguna configuración. Para habilitarlo posteriormente, se puede ejecutar el comando siguiente:
sudo crm configure property stonith-enabled=true
Importante
Solo deshabilite las barreras con fines de prueba. Si tiene previsto usar Pacemaker en un entorno de producción, necesita planear una implementación de barrera basada en su entorno y mantenerla habilitada. SUSE no proporciona agentes de barrera para ningún entorno de nube (incluido Azure) ni Hyper-V. En consecuencia, el proveedor del clúster no admite la ejecución de clústeres de producción en estos entornos. Se trabaja en una solución para este vacío para incorporarla en futuras versiones.
Consulte la Guía de administración de SLES.
Habilitar Pacemaker
Habilite Pacemaker para que se inicie automáticamente.
Ejecute el comando siguiente en cada nodo del clúster.
systemctl enable pacemaker
Crear un recurso de grupo de disponibilidad
El siguiente comando crea y configura el recurso de grupo de disponibilidad para tres réplicas del grupo de disponibilidad [ag1]. Las operaciones y los tiempos de espera de monitor deben especificarse explícitamente en SLES teniendo en cuenta el hecho de que los tiempos de espera dependen en gran medida de la carga de trabajo y, por tanto, deben ajustarse cuidadosamente para cada implementación.
Ejecute el comando en uno de los nodos del clúster:
Ejecute crm configure
para abrir el símbolo del sistema de crm:
sudo crm configure
En el símbolo del sistema de crm, ejecute el comando siguiente para configurar las propiedades del recurso.
primitive ag_cluster \
ocf:mssql:ag \
params ag_name="ag1" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag_cluster ag_cluster \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true" \
commit
Nota
Cuando crea el recurso, y posteriormente de forma periódica, el agente del recurso de Pacemaker establece automáticamente el valor de REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
en el grupo de disponibilidad según la configuración del grupo. Por ejemplo, si el grupo de disponibilidad tiene tres réplicas sincrónicas, el agente establecerá REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
en 1
. Para detalles y opciones de configuración adicional, consulte el artículo sobre alta disponibilidad y protección de datos para configuraciones de grupos de disponibilidad.
Creación de un recurso de dirección IP virtual
Si no creó el recurso de IP virtual cuando ejecutó ha-cluster-init
, puede hacerlo ahora. El comando siguiente crea un recurso de IP virtual. Reemplace <**0.0.0.0**>
por una dirección disponible de su red y <**24**>
por el número de bits de la máscara de subred CIDR. Ejecútelo en un nodo.
crm configure \
primitive admin_addr \
ocf:heartbeat:IPaddr2 \
params ip=<**0.0.0.0**> \
cidr_netmask=<**24**>
Agregar una restricción de ubicación
Casi todas las decisiones de un clúster de Pacemaker, por ejemplo elegir dónde se debe ejecutar un recurso, se toman mediante la comparación de puntuaciones. Las puntuaciones se calculan por recurso, y el administrador del recurso de clúster elige el nodo con la puntuación más alta para un recurso determinado. (Si un nodo tiene una puntuación negativa para un recurso, el recurso no se puede ejecutar en ese nodo). Las decisiones del clúster se pueden manipular mediante restricciones. Las restricciones tienen una puntuación. Si una restricción tiene una puntuación inferior a INFINITY, solo es una recomendación. Una puntuación de INFINITY implica obligatoriedad. Queremos asegurarnos de que la parte principal del grupo de disponibilidad y el recurso de IP virtual se ejecutan en el mismo host, por lo que definimos una restricción de ubicación con una puntuación de infinito.
Para establecer una restricción de ubicación de la IP virtual para que se ejecute en el mismo nodo que el principal, ejecute el siguiente comando en un nodo:
crm configure
colocation vip_on_master inf: \
admin_addr ms-ag_cluster:Master
commit
Agregar una restricción de ordenación
La restricción de ubicación tiene una restricción de orden implícita. Mueve el recurso de dirección IP virtual antes de mover el recurso de grupo de disponibilidad. La secuencia de eventos predeterminada es la siguiente:
- El usuario envía
resource migrate
a la réplica principal del grupo de disponibilidad desde el nodo1 al nodo2.
- El recurso de dirección IP virtual se detiene en el nodo 1.
- El recurso de dirección IP virtual se inicia en el nodo 2. En este punto, la dirección IP apunta temporalmente al nodo 2, mientras que el nodo 2 sigue siendo una réplica secundaria previa a la conmutación por error.
- El maestro del grupo de disponibilidad en el nodo 1 se degrada.
- El grupo de disponibilidad en el nodo 2 asciende a maestro.
Para evitar que la dirección IP apunte temporalmente al nodo con la réplica secundaria previa a la conmutación por error, agregue una restricción de ordenación.
Para agregar una restricción de orden, ejecute el siguiente comando en un nodo:
sudo crm configure \
order ag_first inf: ms-ag_cluster:promote admin_addr:start
Importante
Después de configurar el clúster y agregar el grupo de disponibilidad como un recurso de clúster, no puede usar Transact-SQL para conmutar por error los recursos del grupo de disponibilidad. Los recursos de clúster de SQL Server en Linux no están tan bien integrados con el sistema operativo como lo están en un clúster de conmutación por error de Windows Server (WSFC). El servicio SQL Server no reconoce la presencia del clúster. Toda la orquestación se realiza con las herramientas de administración de clústeres. En SLES, use crm
.
Realice una conmutación por error manual del grupo de disponibilidad con crm
. No inicie la conmutación por error con Transact-SQL. Para obtener más información, vea Conmutación por error.
Para más información, vea:
Contenido relacionado
Plan de desarrollo
Los pasos necesarios para crear un grupo de disponibilidad en servidores con Linux de alta disponibilidad son distintos de los exigidos en un clúster de conmutación por error de Windows Server. En la lista siguiente, se describen los pasos generales:
Guía de instalación de SQL Server en Linux.
Configuración de un grupo de disponibilidad AlwaysOn de SQL Server para alta disponibilidad en Linux.
Configure un administrador de recursos de clúster, como Pacemaker. Estas instrucciones se incluyen en este artículo.
La manera de configurar un administrador de recursos de clúster depende de la distribución específica de Linux.
Importante
Para alcanzar una alta disponibilidad, los entornos de producción necesitan un agente de barrera. En los ejemplos de este artículo no se usan agentes de barrera. Solo se admiten para pruebas y validación.
Un clúster de Linux usa barreras para devolver el clúster a un estado conocido. La forma de configurar las barreras depende de la distribución y del entorno. Actualmente, las barreras no están disponibles en algunos entornos de nube.
Las barreras se suelen implementar en el sistema operativo y dependen del entorno. Busque instrucciones sobre las barreras en la documentación del distribuidor del sistema operativo.
Agregue el grupo de disponibilidad como un recurso en el clúster.
En todos los nodos, abra los puertos del firewall. Abra el puerto para el servicio de alta disponibilidad de Pacemaker, la instancia de SQL Server y el punto de conexión del grupo de disponibilidad. El puerto TCP predeterminado para el servidor que ejecuta SQL Server es 1433
.
sudo ufw allow 2224/tcp
sudo ufw allow 3121/tcp
sudo ufw allow 21064/tcp
sudo ufw allow 5405/udp
sudo ufw allow 1433/tcp # Replace with TDS endpoint
sudo ufw allow 5022/tcp # Replace with DATA_MIRRORING endpoint
sudo ufw reload
Como alternativa, puede deshabilitar el firewall, pero esto no se recomienda en un entorno de producción:
sudo ufw disable
Instale los paquetes de Pacemaker. En todos los nodos, ejecute los siguientes comandos para Ubuntu 20.04. Para más información sobre la instalación en versiones anteriores, consulte Alta disponibilidad de Ubuntu: MS SQL Server en Azure.
sudo apt-get install -y pacemaker pacemaker-cli-utils crmsh resource-agents fence-agents corosync python3-azure
Establezca la contraseña para el usuario predeterminado que se crea al instalar paquetes de Pacemaker y Corosync. Use la misma contraseña en todos los nodos.
sudo passwd hacluster
Creación del clúster
Antes de crear un clúster, debe crear una clave de autenticación en el servidor principal y copiarla en los demás servidores que participan en el grupo de disponibilidad.
Use el siguiente script para crear una clave de autenticación en el servidor principal:
sudo corosync-keygen
Puede usar scp
para copiar la clave generada en otros servidores:
sudo scp /etc/corosync/authkey dbadmin@server-02:/etc/corosync
sudo scp /etc/corosync/authkey dbadmin@server-03:/etc/corosync
Para crear el clúster, edite el archivo /etc/corosync/corosync.conf
en el servidor principal:
sudo vim /etc/corosync/corosync.conf
El archivo corosync.conf
debe tener una apariencia similar a la del ejemplo siguiente:
totem {
version: 2
cluster_name: agclustername
transport: udpu
crypto_cipher: none
crypto_hash: none
}
logging {
fileline: off
to_stderr: yes
to_logfile: yes
logfile: /var/log/corosync/corosync.log
to_syslog: yes
debug: off
logger_subsys {
subsys: QUORUM
debug: off
}
}
quorum {
provider: corosync_votequorum
}
nodelist {
node {
name: server-01
nodeid: 1
ring0_addr: 10.0.0.4
}
node {
name: server-02
nodeid: 2
ring0_addr: 10.0.0.5
}
node {
name: server-03
nodeid: 3
ring0_addr: 10.0.0.6
}
}
Reemplace el archivo corosync.conf
en otros nodos:
sudo scp /etc/corosync/corosync.conf dbadmin@server-02:/etc/corosync
sudo scp /etc/corosync/corosync.conf dbadmin@server-03:/etc/corosync
Reinicie los servicios pacemaker
y corosync
:
sudo systemctl restart pacemaker corosync
Confirme el estado del clúster y compruebe la configuración:
sudo crm status
Consideraciones para varias interfaces de red (NIC)
Al configurar la alta disponibilidad con servidores que tienen varias NIC, siga estas sugerencias:
Asegúrese de que el archivo hosts
está configurado para que las direcciones IP del servidor para las varias NIC se resuelvan en el nombre de host del servidor Linux en cada nodo.
Al configurar el clúster con Pacemaker, usar el nombre de host de los servidores debe configurar Corosync para establecer la configuración de todas las NIC. Solo queremos la comunicación de Pacemaker/Corosync a través de una sola NIC. Una vez configurado el clúster de Pacemaker, modifique la configuración en el archivo corosync.conf
y actualice la dirección IP de la NIC dedicada que quiere usar para la comunicación de Pacemaker/Corosync.
El <hostname>
especificado en el archivo corosync.conf
debe ser el mismo que el resultado proporcionado al realizar una búsqueda inversa (ping -a <ip_address>
) y debe ser el nombre corto configurado en el host. Asegúrese de que el archivo hosts
también representa la dirección IP adecuada para la resolución de nombres.
Los cambios en archivo corosync.conf
de ejemplo se resaltan a continuación:
nodelist {
node {
ring0_addr: <ip_address_of_node1_NIC1>
name: <hostname_of_node1>
nodeid: 1
}
node {
ring0_addr: <ip_address_of_node2_NIC1>
name: <hostname_of_node2>
nodeid: 2
}
node {
ring0_addr: <ip_address_of_node3_NIC1>
name: <hostname_of_node3>
nodeid: 3
}
}
Para admitir la configuración del clúster, los proveedores de clústeres de Pacemaker requieren que se cree una barrera en un nodo erróneo y que se configure un dispositivo de barrera. Si el administrador de recursos de clúster no puede determinar el estado de un nodo o de un recurso de un nodo, las barreras devuelven al clúster a un estado conocido.
La barrera de nivel de recursos garantiza que no se produzcan daños en los datos si se produce una interrupción. Por ejemplo, puede usar la barrera de nivel de recurso con DRBD (dispositivo de bloque replicado distribuido) para marcar el disco de un nodo como obsoleto cuando el enlace de comunicaciones deje de funcionar.
La barrera de nivel de nodo garantiza que un nodo no ejecute ningún recurso. Para ello, se restablece el nodo, cuya implementación en Pacemaker se denomina STONITH. Pacemaker admite una gran variedad de dispositivos de barrera, como, por ejemplo, un sistema de alimentación ininterrumpida o tarjetas de interfaz de administración para servidores.
Para obtener más información, consulte Clústeres de Pacemaker desde cero y Barreras y Stonith.
Como la configuración de las barreras de nivel de nodo depende en gran medida de su entorno, lo hemos deshabilitado para este tutorial (se puede configurar en otro momento). Ejecute el script siguiente en el nodo principal:
sudo crm configure property stonith-enabled=false
En este ejemplo se deshabilita la barrera solo con fines de prueba. Si tiene previsto usar Pacemaker en un entorno de producción, necesita planear una implementación de barrera basada en su entorno y mantenerla habilitada. Póngase en contacto con el proveedor del sistema operativo para obtener información sobre los agentes de barrera de cualquier distribución específica.
Establecer la propiedad del clúster cluster-recheck-interval
La propiedad cluster-recheck-interval
indica el intervalo de sondeo por el que el clúster comprueba los cambios en los parámetros de recursos, las restricciones u otras opciones del clúster. Si una réplica se interrumpe, el clúster intenta reiniciarla en un intervalo que depende de los valores failure-timeout
y cluster-recheck-interval
. Por ejemplo, si failure-timeout
se establece en 60 segundos y cluster-recheck-interval
se establece en 120 segundos, el reinicio se intenta en un intervalo mayor de 60 segundos pero menor de 120 segundos. Debe establecer failure-timeout
en 60 segundos y cluster-recheck-interval
en un valor mayor que 60 segundos. No se recomienda establecer cluster-recheck-interval
en un valor más pequeño.
Para actualizar el valor de la propiedad a 2 minutes
, ejecute:
sudo crm configure property cluster-recheck-interval=2min
Si ya dispone de un recurso de grupo de disponibilidad administrado por un clúster de Pacemaker, el paquete de Pacemaker (1.1.18 -11.el7) introdujo un cambio de comportamiento para el valor de configuración del clúster start-failure-is-fatal
cuando su valor es false
. Este cambio afecta al flujo de trabajo de conmutación por error. Si una réplica principal deja de funcionar, se espera que el clúster conmute por error a una de las réplicas secundarias disponibles. En su lugar, los usuarios observan que el clúster sigue intentando iniciar la réplica principal que ha experimentado el error. Si esa réplica principal no vuelve a activarse (debido a un corte de luz permanente), el clúster nunca conmuta por error a otra réplica secundaria disponible. Debido a este cambio, la recomendación anterior de configurar start-failure-is-fatal
ya no es válida y es necesario revertir a su valor predeterminado de true
.
Además, el recurso de grupo de disponibilidad debe actualizarse para incluir la propiedad failure-timeout
.
Para actualizar el valor de la propiedad a true
, ejecute:
sudo crm configure property start-failure-is-fatal=true
Actualice la propiedad failure-timeout
del recurso del grupo de disponibilidad existente a 60s
(reemplace ag1
por el nombre de su recurso del grupo de disponibilidad):
sudo crm configure meta failure-timeout=60s
Instalar el agente del recurso de SQL Server para la integración con Pacemaker
Ejecute los siguientes comandos en todos los nodos.
sudo apt-get install mssql-server-ha
Crear un inicio de sesión de SQL Server para Pacemaker
En todas las instancias de SQL Server, cree un inicio de sesión en el servidor para Pacemaker.
La siguiente instrucción Transact-SQL crea un inicio de sesión:
USE [master]
GO
CREATE LOGIN [pacemakerLogin] with PASSWORD= N'ComplexP@$$w0rd!';
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemakerLogin];
En el momento de crear el grupo de disponibilidad, el usuario de Pacemaker necesita permisos ALTER
, CONTROL
y VIEW DEFINITION
en el grupo de disponibilidad, una vez creado, pero antes de que se le agreguen nodos.
En todas las instancias de SQL Server, guarde las credenciales para el inicio de sesión de SQL Server.
echo 'pacemakerLogin' >> ~/pacemaker-passwd
echo 'ComplexP@$$w0rd!' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd # Only readable by root
Crear un recurso de grupo de disponibilidad
Para crear el recurso de grupo de disponibilidad, use el comando sudo crm configure
para establecer las propiedades del recurso. En el ejemplo siguiente se crea un recurso del tipo principal/secundario ocf:mssql:ag
para un grupo de disponibilidad con el nombre ag1
.
~$ sudo crm
configure
primitive ag1_cluster \
ocf:mssql:ag \
params ag_name="ag1" \
meta failure-timeout=60s \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=60s \
op demote timeout=10s \
op monitor timeout=60s interval=10s \
op monitor timeout=60s on-fail=demote interval=11s role="Master" \
op monitor timeout=60s interval=12s role="Slave" \
op notify timeout=60s
ms ms-ag1 ag1_cluster \
meta master-max="1" master-node-max="1" clone-max="3" \
clone-node-max="1" notify="true"
commit
Nota
Cuando crea el recurso, y posteriormente de forma periódica, el agente del recurso de Pacemaker establece automáticamente el valor de REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
en el grupo de disponibilidad según la configuración del grupo. Por ejemplo, si el grupo de disponibilidad tiene tres réplicas sincrónicas, el agente establecerá REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
en 1
. Para detalles y opciones de configuración adicional, consulte el artículo sobre alta disponibilidad y protección de datos para configuraciones de grupos de disponibilidad.
Creación de un recurso de dirección IP virtual
Para crear el recurso de dirección IP virtual, ejecute el comando siguiente en un nodo. Use una dirección IP estática disponible de la red. Antes de ejecutar el script, reemplace los valores entre < ... >
por una dirección IP válida.
sudo crm configure primitive virtualip \
ocf:heartbeat:IPaddr2 \
params ip=10.128.16.240
No hay ningún nombre de servidor virtual equivalente en Pacemaker. Para usar una cadena de conexión que apunte a un nombre del servidor de cadena y no usar la dirección IP, registre la dirección del recurso de IP y el nombre del servidor virtual que prefiera en la configuración DNS. En el caso de las configuraciones de recuperación ante desastres, registre el nombre de servidor virtual que prefiera y la dirección IP con los servidores DNS en el sitio principal y en el sitio de recuperación ante desastres.
Agregar una restricción de ubicación
Casi todas las decisiones de un clúster de Pacemaker, por ejemplo elegir dónde se debe ejecutar un recurso, se toman mediante la comparación de puntuaciones. Las puntuaciones se calculan por recurso, y el administrador del recurso de clúster elige el nodo con la puntuación más alta para un recurso determinado. (Si un nodo tiene una puntuación negativa para un recurso, el recurso no se puede ejecutar en ese nodo).
Tenga precaución al configurar las decisiones del clúster. Las restricciones tienen una puntuación. Si una restricción tiene una puntuación inferior a INFINITY, solo es una recomendación. Una puntuación de INFINITY quiere decir que es obligatoria.
Para garantizar que los recursos de réplica principal y dirección IP virtual se ejecuten en el mismo host, defina una restricción de ubicación con una puntuación de INFINITY. Para agregar la restricción de ubicación, ejecute el comando siguiente en un nodo.
sudo crm configure colocation ag-with-listener INFINITY: virtualip-group ms-ag1:Master
Agregar una restricción de ordenación
La restricción de ubicación tiene una restricción de orden implícita. Mueve el recurso de dirección IP virtual antes de mover el recurso de grupo de disponibilidad. La secuencia de eventos predeterminada es la siguiente:
El usuario envía pcs resource move
a la réplica principal del grupo de disponibilidad desde node1
a node2
.
El recurso de dirección IP virtual se detiene en node1
.
El recurso de dirección IP virtual se inicia en node2
.
En este momento la dirección IP apunta de forma temporal a node2
, mientras que node2
aún es un nodo secundario anterior a la conmutación por error.
La réplica principal del grupo de disponibilidad de node1
se degrada a secundaria.
La réplica secundaria del grupo de disponibilidad de node2
se promueve a principal.
Para evitar que la dirección IP apunte temporalmente al nodo con la réplica secundaria previa a la conmutación por error, agregue una restricción de ordenación.
Para agregar una restricción de orden, ejecute el siguiente comando en un nodo:
sudo crm configure order ag-before-listener Mandatory: ms-ag1:promote virtualip-group:start
Después de configurar el clúster y agregar el grupo de disponibilidad como un recurso de clúster, no puede usar Transact-SQL para conmutar por error los recursos del grupo de disponibilidad. Los recursos de clúster de SQL Server en Linux no están tan bien integrados con el sistema operativo como lo están en un clúster de conmutación por error de Windows Server (WSFC). El servicio SQL Server no reconoce la presencia del clúster. Toda la orquestación se realiza con las herramientas de administración de clústeres.
Contenido relacionado