Pacemaker para grupos de disponibilidad e instancias de clúster de conmutación por error en Linux

Applies to:SQL Server en Linux

A partir de SQL Server 2017 (14.x), SQL Server se admite tanto en Linux como en Windows. Al igual que las implementaciones de SQL Server basadas en Windows, las bases de datos y las instancias de SQL Server deben estar de alta disponibilidad en Linux. En este artículo se describe la información básica para comprender Pacemaker con Corosync y cómo planear e implementarla para SQL Server configuraciones.

Conceptos básicos de la extensión/complemento de alta disponibilidad

Todas las distribuciones compatibles actualmente incluyen una extensión o complemento de alta disponibilidad, que se basa en la pila de agrupación en clústeres de Pacemaker. Esta pila incorpora dos componentes clave: Pacemaker y Corosync. Todos los componentes de la pila son:

• Pacemaker: componente principal de la agrupación en clústeres, que hace cosas como coordinar todos los equipos agrupados en clústeres.
• Corosync: marco de trabajo y conjunto de API que proporcionan aspectos como el cuórum, la capacidad de reiniciar procesos con errores, etc.
• libQB: se encarga de cuestiones como los registros.
• Agente de recursos: funcionalidad específica proporcionada para que una aplicación se pueda integrar con Pacemaker.
• Agente de barrera: scripts/funcionalidad que sirven para aislar nodos y tratarlos en caso de que haya un problema en ellos.

Esta solución es similar de algunas maneras, pero en muchos otros aspectos diferente de la implementación de configuraciones en clúster usando Windows. En Windows, la forma de disponibilidad de la agrupación en clústeres, denominada clúster de conmutación por error de Windows Server (WSFC), está integrada en el sistema operativo y la característica que permite la creación de un clúster de conmutación por error de WSFC, está deshabilitado de forma predeterminada. En Windows, los grupos de disponibilidad y las FCI se basan en un WSFC y comparten una estrecha integración debido a la DLL de recursos específica que proporciona SQL Server. Esta solución perfectamente combinada es posible porque todo procede de un mismo proveedor.

En Linux, aunque todas las distribuciones compatibles tienen Pacemaker disponible, cada una de ellas puede personalizarlo y tener implementaciones y versiones ligeramente diferentes. Algunas de las diferencias se reflejarán en las instrucciones de este artículo. La capa de agrupación en clústeres es código abierto, por lo que, aunque se distribuye con las distribuciones, no está estrechamente integrada de la misma manera que un WSFC está bajo Windows. Este es el motivo por el que Microsoft proporciona mssql-server-ha, para que SQL Server y la pila de Pacemaker puedan ofrecer una experiencia cercana, pero no exactamente igual, para los Grupos de Disponibilidad (AG) y las Instancias de Clúster de Falla (FCI) como en Windows.

Para obtener documentación completa sobre Pacemaker relativa a RHEL y SLES (incluida una explicación más detallada de lo que es cada cosa con información de referencia completa):

• RHEL
• SLES
• Ubuntu

Para más información sobre la pila completa, vea también la página de documentación oficial de Pacemaker en el sitio de Clusterlabs.

Conceptos y terminología de Pacemaker

En esta sección se documentan los conceptos y la terminología comunes de una implementación de Pacemaker.

Nodo

Un nodo es un servidor que participa en el clúster. Un clúster de Pacemaker admite de forma nativa hasta 16 nodos. Este número se puede superar si Corosync no se está ejecutando en nodos adicionales, pero Corosync es necesario para SQL Server. Por lo tanto, el número máximo de nodos que un clúster puede tener para cualquier configuración basada en SQL Server es 16; este es el límite de Pacemaker y no tiene nada que ver con las limitaciones máximas para los grupos de disponibilidad o las FCI impuestas por SQL Server.

Recurso

Tanto en WSFC como en un clúster de Pacemaker existe el concepto de recurso. Un recurso es una funcionalidad específica que se ejecuta en el contexto del clúster, como un disco o una dirección IP. Por ejemplo, en Pacemaker se pueden crear recursos de grupo de disponibilidad y de instancia de clúster de conmutación por error. Esto no es diferente de lo que se hace en un WSFC, donde se observa un recurso de SQL Server para una FCI o recursos de AG al configurar un AG, pero no es exactamente lo mismo debido a las diferencias subyacentes en la forma en que SQL Server se integra con Pacemaker.

Pacemaker tiene recursos estándar y de clonación. Los recursos de clonación son aquellos que se ejecutan simultáneamente en todos los nodos. Un ejemplo sería una dirección IP que se ejecuta en varios nodos con fines de equilibrio de carga. Cualquier recurso que se cree para instancias de clúster de conmutación por error usa un recurso estándar, ya que solo un nodo puede hospedar una instancia de clúster de conmutación por error en un momento dado.

Cuando se crea un grupo de disponibilidad, es necesaria una forma especial del recurso de clonación, denominada recurso multiestado. Aunque un grupo de disponibilidad solo tiene una réplica principal, el grupo de disponibilidad en sí se está ejecutando en todos los nodos en los que esté configurada para ejecutarse, y puede permitir potencialmente cosas como el acceso de solo lectura. Dado que se trata de un uso "activo" del nodo, en los recursos existe el concepto de doble estado: Promocionado (anteriormente, Maestro) y No promocionado (anteriormente, Secundario). Para más información, vea Recursos multiestado: recursos que tienen varios modos.

Conjuntos/Grupos de recursos

De forma similar a los roles de un WSFC, en un clúster de Pacemaker existe el concepto de un grupo de recursos. Un grupo de recursos (denominado conjunto en SLES) es una colección de recursos que funcionan de manera conjunta y que pueden conmutar por error de un nodo a otro como una sola unidad. Los grupos de recursos no pueden contener recursos que estén configurados como Promocionado o No promocionado; por tanto, no se pueden usar para grupos de disponibilidad. Aunque un grupo de recursos se puede usar con instancias de clúster de conmutación por error, esta configuración no suele ser recomendable.

Restricciones

Los WSFC tienen varios parámetros de recursos, así como dependencias, que indican al WSFC la relación principal/secundario entre dos recursos diferentes. Una dependencia es simplemente una regla que indica al WSFC qué recurso debe estar en línea en primer lugar.

En un clúster de Pacemaker no existe el concepto de dependencias, pero sí hay restricciones. Hay tres tipos de restricción: de colocación, de ubicación y de ordenación.

• Una restricción de colocación establece si se deben ejecutar (o no) dos recursos en el mismo nodo.
• Una restricción de ubicación indica al clúster de Pacemaker dónde puede ejecutarse (o no) un recurso.
• Una restricción de ordenación indica al clúster de Pacemaker el orden en el que deben iniciarse los recursos.

Cuórum, agentes de barrera y STONITH

El cuórum en Pacemaker es parecido a un WSFC desde un punto de vista conceptual. El propósito general del mecanismo de cuórum de un clúster es asegurarse de que el clúster se mantiene en funcionamiento. Tanto en un WSFC como en los complementos de alta disponibilidad de las distribuciones de Linux existe el concepto de votación, donde cada nodo cuenta para el cuórum. Conviene que haya una mayoría de votos a favor; de lo contrario, en el peor de los casos, el clúster se apagará.

A diferencia de un WSFC, no hay ningún recurso de testigo que funcione con el cuórum. El objetivo es mantener el número de votantes impar, como en el caso de un WSFC. Las consideraciones de configuración de cuórum son diferentes en un grupo de disponibilidad y en una instancia de clúster de conmutación por error.

Los WSFC supervisan el estado de los nodos que participan, y los controlan cuando se produce un problema. Las versiones posteriores de WSFC ofrecen características como poner en cuarentena de un nodo que tiene un comportamiento adecuado o que no está disponible (el nodo no está activo, la comunicación de red está inactiva, etc.). En cuanto a Linux, este tipo de funcionalidad se proporciona mediante un agente de barrera, concepto al que en ocasiones se hace referencia simplemente como "barreras". Sin embargo, estos agentes de barrera suelen ser específicos de la implementación y, a menudo, los facilitan los proveedores de hardware y algunos proveedores de software (como los que suministran hipervisores). Por ejemplo, VMware proporciona un agente de barrera que se puede usar en máquinas virtuales Linux virtualizadas con vSphere.

El cuórum y las barreras entroncan con otro concepto que se conoce como STONITH (acrónimo de "Shoot the Other Node in the Head", que significa "dispara al otro nodo en la cabeza"). STONITH se necesita para tener un clúster de Pacemaker compatible en todas las distribuciones de Linux. Para más información, vea Barreras en un clúster de alta disponibilidad de Red Hat (RHEL).

corosync.conf

El archivo corosync.conf contiene la configuración del clúster, y se encuentra en /etc/corosync. En el transcurso de las operaciones cotidianas normales, este archivo nunca debe editarse si el clúster está configurado correctamente.

Ubicación del registro de clúster

Las ubicaciones de registro de los clústeres de Pacemaker difieren en función de la distribución.

• RHEL y SLES: /var/log/cluster/corosync.log
• Ubuntu: /var/log/corosync/corosync.log

Para cambiar la ubicación de registro predeterminada, modifique corosync.conf.

Planeamiento de clústeres de Pacemaker para SQL Server

En esta sección se describen los aspectos de planeación importantes relativos a un clúster de Pacemaker.

Virtualización de clústeres de Pacemaker basados en Linux para SQL Server

El uso de máquinas virtuales para implementar implementaciones de SQL Server basadas en Linux para grupos de disponibilidad y FCI está cubierta por las mismas reglas que para sus homólogos basados en Windows. Hay un conjunto base de reglas para admitir implementaciones de SQL Server virtualizadas proporcionadas por Microsoft en Directivasupport para productos Microsoft SQL Server que se ejecutan en un entorno de virtualización de hardware. Los diferentes hipervisores, como Microsoft Hyper-V y ESXi de VMware, pueden tener diferentes variaciones sobre eso, debido a las diferencias en las propias plataformas.

En lo que respecta a los grupos de disponibilidad y las instancias de clúster de conmutación por error virtualizados, asegúrese de que la antiafinidad de los nodos de un clúster de Pacemaker determinado está establecida. Cuando se configura para alta disponibilidad en una configuración de ag o FCI, las máquinas virtuales que hospedan SQL Server nunca deben ejecutarse en el mismo host del hipervisor. Por ejemplo, si se implementa una instancia de clúster de conmutación por error de dos nodos, debe haber como mínimo tres hosts de hipervisor para que haya algún sitio al que las máquinas virtuales que hospedan un nodo puedan ir en caso de que se produzca un error en el host, sobre todo cuando se usan características como Migración en vivo o vMotion.

Para la documentación de Hyper-V, consulte Using Guest Clustering for High Availability

Red

A diferencia de un WSFC, Pacemaker no requiere un nombre dedicado ni una dirección IP dedicada como mínimo para el clúster de Pacemaker en sí. Los grupos de disponibilidad y las instancias de clúster de conmutación por error requerirán direcciones IP (vea la documentación de cada uno para más información), pero no nombres, ya que no hay ningún recurso de nombre de red. SLES permite configurar una dirección IP con fines de administración, pero no es necesario, como se desprende de Crear el clúster de Pacemaker.

Al igual que un WSFC, Pacemaker preferiría redes redundantes, lo que conlleva distintas tarjetas de red (NIC o pNIC, si son físicas) con direcciones IP individuales. Dicho en términos de configuración de clúster, cada dirección IP tendría lo que se conoce como su propio anillo. Sin embargo, igual que ocurre con los WSFC hoy día, muchas implementaciones se virtualizan o se encuentran en la nube pública, donde en realidad solo hay una única NIC virtualizada (vNIC) que se muestra al servidor. Si todas las pNIC y vNIC están conectadas al mismo conmutador físico o virtual, no hay una auténtica redundancia en el nivel de red, por lo que la configuración de varias NIC es un poco un efecto ilusorio para la máquina virtual. La redundancia de red suele estar integrada en el hipervisor en implementaciones virtualizadas, y está integrada en la nube pública.

Una diferencia de tener varias NIC y Pacemaker frente a un WSFC es que Pacemaker permite varias direcciones IP en la misma subred, mientras que un WSFC no. Para más información sobre varias subredes y clústeres de Linux, consulte el artículo Configuración de grupos de disponibilidad e instancias de clúster de conmutación por error Always On de varias redes.

Cuórum y STONITH

La configuración de quórum y sus requisitos están relacionados con las implementaciones específicas de AG o FCI de SQL Server.

STONITH es necesario en un clúster de Pacemaker compatible. Use la documentación de la distribución para configurar STONITH. Encontrará un ejemplo de SLES en Barreras basadas en el almacenamiento. También hay un agente STONITH de VMware vCenter para soluciones basadas en ESXI. Para más información, vea Agente del complemento STONITH para barreras de SOAP de VMware VM vCenter (no oficial).

Interoperabilidad

En esta sección se documenta cómo un clúster basado en Linux puede interactuar con un WSFC o con otras distribuciones de Linux.

WSFC

Actualmente, no hay ninguna manera directa de que un clúster WSFC y un clúster de Pacemaker funcionen juntos. Esto significa que no existe forma de crear un grupo de disponibilidad o una instancia de clúster de conmutación por error que funcione en un WSFC y en Pacemaker, si bien hay dos soluciones de interoperabilidad diseñadas para grupos de disponibilidad. La única manera de que una instancia de clúster de conmutación por error participe en una configuración multiplataforma es hacerlo como una instancia en uno de estos dos escenarios:

• Un grupo de disponibilidad que tenga un tipo de clúster None. Para obtener más información, consulte la documentación de Windows availability groups.
• Un grupo de disponibilidad distribuido, que es un tipo especial de grupo que permite configurar dos grupos de disponibilidad diferentes como propio grupo de disponibilidad. Para más información sobre los grupos de disponibilidad distribuidos, vea Grupos de disponibilidad distribuidos.

Otras distribuciones de Linux

En Linux, todos los nodos de un clúster de Pacemaker deben estar en la misma distribución. Esto significa, por ejemplo, que un nodo de RHEL no puede formar parte de un clúster de Pacemaker que tenga un nodo de SLES. La razón principal de esto se ha mencionado antes: cada distribución podría tener versiones y funcionalidades distintas, por lo que las cosas podrían no funcionar correctamente. Si se combinan distribuciones, deberá hacerse igual que al combinar WSFC y Linux: usando clústeres de tipo None o grupos de disponibilidad distribuidos.

Contenido relacionado

• Desplegar un cluster de Pacemaker para SQL Server en Linux
• Configurar un clúster de Pacemaker para grupos de disponibilidad SQL Server