Compartir a través de

Configuración del clúster de disco compartido de SLES para SQL Server

Se aplica a:SQL Server en Linux

En esta guía se proporcionan instrucciones para crear un clúster de discos compartidos de dos nodos para SQL Server en SUSE Linux Enterprise Server (SLES). La capa de agrupación en clústeres se basa en SUSE High Availability Extension (HAE) desarrollado sobre Pacemaker.

Nota

A partir de SQL Server 2025 (17.x), no se admite SUSE Linux Enterprise Server (SLES).

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 12 SP5.

Requisitos previos

Para completar el siguiente escenario de un extremo a otro, necesita dos máquinas para implementar el clúster de dos nodos y otro servidor para configurar el recurso compartido de NFS. En los pasos siguientes se describe cómo configurar estos servidores.

Instalación y configuración del sistema operativo en cada nodo del clúster

El primer paso es configurar el sistema operativo en los nodos del clúster. Para este tutorial, use SLES con una suscripción válida para el módulo de alta disponibilidad.

Instalación y configuración de SQL Server en cada nodo de clúster

  1. Instale y configure SQL Server en ambos nodos. Para obtener instrucciones detalladas, vea Guía de instalación de SQL Server en Linux.

  2. Para configurarlos, designe un nodo como principal y el otro como secundario. Use estos términos durante esta guía.

  3. En el nodo secundario, detenga y deshabilite SQL Server. En el siguiente ejemplo se detiene y se deshabilita SQL Server:

    sudo systemctl stop mssql-server
sudo systemctl disable mssql-server

    Nota

    En el momento de la instalación, se genera una clave maestra de servidor (SMK) para la instancia de SQL Server y se coloca en /var/opt/mssql/secrets/machine-key. En Linux, SQL Server siempre se ejecuta como una cuenta local denominada mssql. Dado que se trata de una cuenta local, su identidad no se comparte entre los nodos. Debe copiar la clave de cifrado del nodo principal en cada nodo secundario para que cada cuenta local mssql pueda acceder a ella para descifrar el SMK.

  4. En el nodo principal, cree un inicio de sesión de SQL Server para Pacemaker y conceda el permiso de inicio de sesión para ejecutar sp_server_diagnostics. Pacemaker usa esta cuenta para comprobar qué nodo ejecuta SQL Server.

    sudo systemctl start mssql-server

    Conéctese a la base de datos de SQL Server master con la sa cuenta y ejecute el siguiente script:

    USE [master];
GO

CREATE LOGIN [<loginName>] with PASSWORD = N'<password>';
GRANT VIEW SERVER STATE TO <loginName>;

    Precaución

    La contraseña debe seguir la directiva de contraseña predeterminada de SQL Server. De forma predeterminada, la contraseña debe tener al menos ocho caracteres y contener caracteres de tres de los siguientes cuatro conjuntos: mayúsculas, minúsculas, dígitos en base 10 y símbolos. Las contraseñas pueden tener hasta 128 caracteres. Use contraseñas lo más largas y complejas posible.

  5. En el nodo principal, detenga y deshabilite SQL Server.

  6. Siga las instrucciones de la documentación de SUSE para configurar y actualizar el archivo “hosts” de cada nodo de clúster. El archivo hosts debe incluir la dirección IP y el nombre de cada nodo de clúster.

    Para comprobar la dirección IP del nodo actual, ejecute:

    sudo ip addr show

    Establezca el nombre de equipo en cada nodo. Asigne a cada nodo un nombre único que tenga 15 caracteres o menos. Para establecer el nombre de equipo, agréguelo a /etc/hostname con YAST o manualmente.

    En el ejemplo siguiente se muestra /etc/hosts con adiciones para dos nodos denominados SLES1 y SLES2.

    127.0.0.1      localhost
10.128.18.128  SLES1
10.128.16.77   SLES2

    Todos los nodos de clúster deben tener acceso SSH sin contraseña entre sí. De lo contrario, las herramientas como hb_report, crm_reporty el Explorador de historial de Hawk solo pueden recopilar datos del nodo local. Si usa un puerto SSH no estándar, use la -X opción (consulte Otros requisitos y recomendaciones). Por ejemplo, si el puerto SSH es 3479, invoque crm_report del siguiente modo:

    crm_report -X "-p 3479" [...]

    Para obtener más información, consulte la guía de administración.

En la sección siguiente, configurará el almacenamiento compartido y moverá los archivos de base de datos a ese almacenamiento.

Configuración del almacenamiento compartido y movimiento de los archivos de base de datos

Puede usar varias soluciones para proporcionar almacenamiento compartido. En este tutorial se muestra cómo configurar el almacenamiento compartido con NFS. Siga los procedimientos recomendados y use Kerberos para proteger NFS:

Si no sigue esta guía, cualquier persona que pueda acceder a la red y suplantar la dirección IP de un nodo SQL puede acceder a los archivos de datos. Como siempre, realice el modelado de amenazas en el sistema antes de usarlo en producción.

Otra opción de almacenamiento es usar el recurso compartido de archivos SMB:

Configuración de un servidor NFS

Para configurar un servidor NFS, vea los pasos siguientes de la documentación de SUSE: Configuring NFS Server (Configuración del servidor NFS).

Configuración de todos los nodos de clúster para conectarse al almacenamiento compartido de NFS

Antes de configurar el cliente NFS para montar la ruta de acceso de los archivos de base de datos de SQL Server para apuntar a la ubicación de almacenamiento compartido, asegúrese de guardar los archivos de base de datos en una ubicación temporal de forma que pueda copiarlos posteriormente al recurso compartido:

  1. Solo en el nodo principal, guarde los archivos de base de datos en una ubicación temporal. El script siguiente crea un nuevo directorio temporal, copia los archivos de base de datos en el nuevo directorio y quita los archivos de base de datos antiguos. Como SQL Server se ejecuta como el usuario local mssql, debe asegurarse de que, después de transferir los datos al recurso compartido montado, el usuario local tiene acceso de lectura y escritura al recurso compartido.

    su mssql
mkdir /var/opt/mssql/tmp
cp /var/opt/mssql/data/* /var/opt/mssql/tmp
rm /var/opt/mssql/data/*
exit

    Configure el cliente NFS en todos los nodos de clúster:

    Nota

    Para conocer los procedimientos recomendados y recomendaciones de SUSE sobre el almacenamiento NFS de alta disponibilidad, consulte Almacenamiento NFS de alta disponibilidad con DRBD y Pacemaker.

  2. En cada nodo, compruebe que SQL Server se inicia correctamente con la nueva ruta de acceso del archivo. En este momento, solo un nodo debe ejecutar SQL Server a la vez. No se pueden ejecutar al mismo tiempo porque ambos intentan acceder a los archivos de datos simultáneamente.

    Para evitar que SQL Server se inicie en ambos nodos, use un recurso de clúster del sistema de archivos para asegurarse de que el recurso compartido está montado solo por un nodo a la vez.

    Los siguientes comandos inician SQL Server, comprueban el estado y después detienen SQL Server.

    sudo systemctl start mssql-server
sudo systemctl status mssql-server
sudo systemctl stop mssql-server

En este momento, ambas instancias de SQL Server están configuradas para ejecutarse con los archivos de base de datos en el almacenamiento compartido. El siguiente paso consiste en configurar SQL Server para Pacemaker.

Instalación y configuración de Pacemaker en todos los nodos del clúster

  1. En ambos nodos del clúster, cree un archivo para almacenar el nombre de usuario y la contraseña de SQL Server para el inicio de sesión de Pacemaker. Con el siguiente comando se crea y rellena este archivo:

    sudo touch /var/opt/mssql/secrets/passwd
sudo echo '<loginName>' >> /var/opt/mssql/secrets/passwd
sudo echo '<password>' >> /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 600 /var/opt/mssql/secrets/passwd

    Precaución

    La contraseña debe seguir la directiva de contraseña predeterminada de SQL Server. De forma predeterminada, la contraseña debe tener al menos ocho caracteres y contener caracteres de tres de los siguientes cuatro conjuntos: mayúsculas, minúsculas, dígitos en base 10 y símbolos. Las contraseñas pueden tener hasta 128 caracteres. Use contraseñas lo más largas y complejas posible.

  2. Todos los nodos de clúster deben tener acceso entre sí a través de SSH. Las herramientas como hb_report o crm_report (para solucionar problemas) y el Explorador de historial de Hawk requieren acceso SSH sin contraseña entre los nodos. De lo contrario, solo pueden recopilar datos del nodo actual. Si usa un puerto SSH no estándar, use la -X opción (consulte la man página). Por ejemplo, si el puerto SSH es 3479, invoque con hb_report :

    crm_report -X "-p 3479" [...]

    Para más información, vea los requisitos de sistema y recomendaciones en la documentación de SUSE.

  3. Instale la extensión de alta disponibilidad. Para instalar la extensión, siga los pasos descritos en el siguiente artículo de SUSE:

    Installation and Setup Quick Start (Inicio rápido de instalación y configuración)

  4. Instale el agente de recursos de FCI para SQL Server. Ejecute los siguientes comandos en ambos nodos:

    sudo zypper addrepo -fc https://packages.microsoft.com/config/sles/12/mssql-server-2017.repo
sudo zypper --gpg-auto-import-keys refresh
sudo zypper install mssql-server-ha

  5. Configure automáticamente el primer nodo. El siguiente paso consiste en configurar un clúster de un nodo en ejecución, para lo cual configuraremos el primer nodo, SLES1. Siga las instrucciones del artículo de SUSE Setting Up the First Node (Configurar el primer nodo).

    Cuando acabe, compruebe el estado del clúster con crm status:

    crm status

    Muestra que un nodo, SLES1, ha sido configurado.

  6. Agregue nodos a un clúster existente. A continuación, una el nodo SLES2 al clúster. Siga las instrucciones del artículo de SUSE Adding the Second Node (Agregar el segundo nodo).

    Cuando acabe, compruebe el estado del clúster con crm status. Si agrega correctamente un segundo nodo, la salida es similar al ejemplo siguiente:

    2 nodes configured
1 resource configured
Online: [ SLES1 SLES2 ]
Full list of resources:
admin_addr     (ocf::heartbeat:IPaddr2):       Started SLES1

    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.

  7. Procedimientos de eliminación. Si necesita quitar un nodo del clúster, use el script de arranque ha-cluster-remove. Para más información, vea Overview of the Bootstrap Scripts (Información general de los scripts de arranque).

Configuración de los recursos de clúster para SQL Server

En los pasos siguientes se explica cómo configurar el recurso de clúster para SQL Server. Personalice los dos valores siguientes:

  • Nombre del recurso de SQL Server: nombre de recurso de SQL Server en clúster.
  • Valor del tiempo de espera: el valor del tiempo de espera es la cantidad de tiempo que el clúster espera mientras un recurso se pone en línea. Para SQL Server, este valor representa el tiempo que espera que SQL Server tarde en poner la master base de datos en línea.

Actualice los valores del script siguiente para su entorno. Ejecute el script en un nodo para configurar e iniciar el servicio en clúster.

sudo crm configure
primitive <sqlServerResourceName> ocf:mssql:fci op start timeout=<timeout_in_seconds>
colocation <constraintName> inf: <virtualIPResourceName> <sqlServerResourceName>
show
commit
exit

Por ejemplo, el siguiente script crea un recurso en clúster de SQL Server denominado mssqlha.

sudo crm configure
primitive mssqlha ocf:mssql:fci op start timeout=60s
colocation admin_addr_mssqlha inf: admin_addr mssqlha
show
commit
exit

Después de confirmar la configuración, SQL Server se inicia en el mismo nodo que el recurso de IP virtual.

Para obtener más información, vea Configuring and Managing Cluster Resources (Command Line) [Configurar y administrar recursos en clúster (línea de comandos)].

Confirme que se ha iniciado SQL Server

Para comprobar que se ha iniciado SQL Server, ejecute el comando crm status:

crm status

En el ejemplo siguiente se muestran los resultados cuando Pacemaker se inicia correctamente como recurso agrupado.

2 nodes configured
2 resources configured

Online: [ SLES1 SLES2 ]

Full list of resources:

 admin_addr     (ocf::heartbeat:IPaddr2):       Started SLES1
 mssqlha        (ocf::mssql:fci):       Started SLES1

Administración de recursos de clúster

Para administrar los recursos de clúster, consulte el siguiente artículo de SUSE: Administración de recursos de clúster

Conmutación por error manual

Aunque los recursos están configurados para cambiar automáticamente o migrar a otros nodos del clúster en caso de errores de hardware o software, también puede moverlos manualmente utilizando la GUI de Pacemaker o la línea de comandos.

Use el migrate comando para esta tarea. Por ejemplo, para migrar el recurso sql a un nodo de clúster denominado SLES2, ejecute:

crm resource
migrate mssqlha SLES2

Contenido relacionado

  • Last updated on