Share via

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

  • Artículo

Se aplica a:SQL Server: Linux

A partir de SQL Server, SQL Server 2017 (14.x) se admite en Linux y en Windows. Al igual que las implementaciones basadas en Windows de SQL Server, las bases de datos y las instancias de SQL Server deben tener una alta disponibilidad en Linux. Este artículo cubre información básica para comprender Pacemaker con Corosync, además de cómo planear e implementar la solución para configuraciones de SQL Server.

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.

Nota:

La pila de clúster se conoce comúnmente como Pacemaker en el mundo Linux.

Esta solución es similar en parte (y, al mismo tiempo, diferente en muchas cosas) a implementar configuraciones en clúster mediante 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 crear un WSFC (clústeres de conmutación por error) está deshabilitada de forma predeterminada. En Windows, los grupos de disponibilidad y las instancias de clúster de conmutación por error se basan en un WSFC y comparten una integración muy estrecha debido al archivo DLL de recurso específico que SQL Server proporciona. Esta solución perfectamente combinada es posible porque todo procede de un mismo proveedor.

Diagram of high availability basics.

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 de código abierto, por lo que, aunque venga incluida en las distribuciones, no se integra estrechamente de la misma manera a como lo hace un WSFC en Windows. Este es el motivo por el que Microsoft proporciona mssql-server-ha, para que SQL Server y la pila de Pacemaker puedan proporcionar una experiencia cercana, si bien no exactamente igual, a los grupos de disponibilidad y las instancias de clúster de conmutación por error 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):

Ubuntu no tiene una guía sobre disponibilidad.

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 puede ser mayor si Corosync no se está ejecutando en otros nodos, pero Corosync es necesario con SQL Server. Por lo tanto, el número máximo de nodos que un clúster puede tener en una configuración basada en SQL Server es 16; este es el límite de Pacemaker, y no tiene nada que ver con los límites máximos impuestos por SQL Server en relación con los grupos de disponibilidad y las instancias de clúster de conmutación por error.

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 difiere de lo que se lleva a cabo en un WSFC, donde hay un recurso de SQL Server para una instancia de clúster de conmutación por error o para un grupo de disponibilidad al configurar un grupo de disponibilidad, pero no es exactamente lo mismo, dadas las diferencias subyacentes en cuanto a 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.

Nota

Comunicación sin prejuicios

Este artículo contiene referencias al término esclavo, que Microsoft considera ofensivo cuando se usa en este contexto. El término aparece en este artículo porque actualmente aparece en el software. Cuando se quite el término del software, se quitará también del artículo.

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.

Nota:

Las restricciones de colocación no son necesarias en los recursos de un grupo de recursos, ya que todos ellos se consideran una sola unidad.

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.

Planeación 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 poner en marcha implementaciones de SQL Server basadas en Linux de grupos de disponibilidad e instancias de clúster de conmutación por error se rige por las mismas reglas que para sus homólogos basados en Windows. Microsoft proporciona un conjunto base de reglas para la compatibilidad de implementaciones de SQL Server virtualizadas en la directiva de soporte técnico para productos de Microsoft SQL Server que se ejecutan en un entorno de virtualización de hardware. Cada hipervisor, como Hyper-V de Microsoft o ESXi de VMware, podría tener distintas variaciones aparte de lo anterior, 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 configuran para alta disponibilidad en una configuración de grupo de disponibilidad o de instancia de clúster de conmutación por error, las máquinas virtuales que hospedan SQL Server nunca deben ejecutarse en el mismo host de 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 más información, vea:

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, vea el artículo Configuración de varias subredes.

Cuórum y STONITH

La configuración y los requisitos de cuórum están relacionados con implementaciones de SQL Server específicas de un grupo de disponibilidad o una instancia de clúster de conmutación por error.

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 más información, vea la documentación sobre grupos de disponibilidad de Windows.
  • 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