Conceptos básicos sobre disponibilidad de SQL Server en implementaciones de 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. En este artículo se abordan los aspectos técnicos de la planeación e implementación de bases de datos e instancias de SQL Server basadas en Linux de alta disponibilidad, así como algunas de las diferencias con respecto a las instalaciones basadas en Windows. Como SQL Server puede ser una novedad para los profesionales de Linux, así como Linux para los profesionales de SQL Server, el artículo a veces reflejará conceptos que pueden ser familiares para algunos y desconocidos para otros.

Opciones de disponibilidad de SQL Server en implementaciones de Linux

Aparte de las copias de seguridad y la restauración, las mismas tres características de disponibilidad están presentes en las implementaciones basadas tanto en Linux como en Windows:

En Windows, las instancias de clúster de conmutación por error requieren un clúster de conmutación por error de Windows Server (WSFC) subyacente. Dependiendo del escenario de implementación, un grupo de disponibilidad suele requerir un WSFC subyacente, con la excepción de la nueva variante None en SQL Server 2017 (14.x). En Linux no hay un WSFC. La implementación en clúster en Linux se describe en Pacemaker para grupos de disponibilidad e instancias de clúster de conmutación por error en Linux.

Manual rápido de Linux

Aunque algunas instalaciones de Linux se pueden instalar con una interfaz, la mayoría no lo hacen, lo que significa que casi todo lo que hay en la capa del sistema operativo se realiza a través de la línea de comandos. El término común para esta línea de comandos en el mundo Linux es shell Bash.

En Linux, muchos comandos se deben ejecutar con privilegios elevados, de forma muy parecida a como haría un administrador en Windows Server. Hay dos métodos principales para ejecutar acciones con privilegios elevados:

  1. Realizar la ejecución en el contexto del usuario adecuado. Para cambiar a otro usuario, use el comando su. Si su se ejecuta por sí solo sin un nombre de usuario, y siempre y cuando conozca la contraseña, estará en un shell como raíz.

  2. La forma más común y basada en la seguridad de ejecutar acciones es usar sudo antes de ejecutar nada. En muchos de los ejemplos de este artículo se usa sudo.

Estos son algunos comandos comunes; todos ellos tienen varios modificadores y opciones que se pueden investigar en línea:

  • cd: sirve para cambiar de directorio.
  • chmod: sirve para cambiar los permisos de un archivo o un directorio.
  • chown: sirve para cambiar la propiedad de un archivo o un directorio.
  • ls: sirve para mostrar el contenido de un directorio.
  • mkdir: sirve para crear una carpeta (directorio) en una unidad.
  • mv: sirve para mover un archivo de una ubicación a otra.
  • ps: sirve para mostrar todos los procesos en funcionamiento.
  • rm: sirve para eliminar un archivo localmente en un servidor.
  • rmdir: sirve para eliminar una carpeta (directorio).
  • systemctl: sirve para iniciar, detener o habilitar servicios.
  • Comandos del editor de texto. En Linux hay varias opciones del editor de texto, como vi y emacs.

Tareas comunes para configurar la disponibilidad de SQL Server en Linux

En esta sección se describen las tareas comunes a todas las implementaciones de SQL Server basadas en Linux.

Garantizar que los archivos se pueden copiar

Copiar archivos de un servidor a otro es una tarea que cualquier persona que use SQL Server en Linux debería poder realizar. Esta tarea es muy importante para las configuraciones de grupos de disponibilidad.

Pueden surgir cuestiones como problemas de permisos en las instalaciones basadas tanto en Linux como en Windows. Sin embargo, es posible que los usuarios familiarizados con copiar de un servidor a otro en Windows no sepan cómo hacerlo en Linux. Un método común es usar la utilidad de la línea de comandos scp, que significa "copia segura". En segundo plano, scp usa OpenSSH. SSH significa "shell seguro". En función de la distribución de Linux, es posible que OpenSSH no esté instalado de por sí. Si no lo está, OpenSSH debe instalarse primero. Para más información sobre cómo configurar OpenSSH, vea los siguientes vínculos relativos a cada distribución:

Al usar scp, debe proporcionar las credenciales del servidor si no es el origen o el destino. Por ejemplo, si se usa

scp MyAGCert.cer username@servername:/folder/subfolder

el archivo MyAGCert.cer se copia en la carpeta especificada en el otro servidor. Debe tener permisos en el archivo (y, posiblemente, ser el propietario de este) para copiarlo, con lo cual es posible que deba usar también chown antes de copiar. Del mismo modo, en el lado receptor, el usuario adecuado necesita acceso para manipular el archivo. Por ejemplo, para restaurar ese archivo de certificado, el usuario de mssql debe poder acceder a él.

También se puede usar Samba, que es la variante de Linux del Bloque de mensajes del servidor (SMB), para crear recursos compartidos a los que acceden las rutas de acceso UNC como \\SERVERNAME\SHARE. Para más información sobre cómo configurar Samba, vea los siguientes vínculos relativos a cada distribución:

También se pueden usar recursos compartidos de SMB basados en Windows; no es necesario que los recursos compartidos de SMB estén basados en Linux, siempre y cuando la parte del cliente de Samba esté configurada correctamente en el servidor Linux que hospeda SQL Server y el recurso compartido tenga el acceso adecuado. En el caso de los entornos mixtos, esto sería una manera de aprovechar la infraestructura existente para las implementaciones de SQL Server basadas en Linux.

Algo importante es que la versión de Samba implementada debe ser compatible con SMB 3.0. Cuando se agregó compatibilidad con SMB en SQL Server 2012 (11.x), era necesario que todos los recursos compartidos admitieran SMB 3.0. Si se usa Samba para el recurso compartido y no Windows Server, dicho recurso compartido basado en Samba debe usar Samba 4.0 o posterior e, idealmente, la versión 4.3 o posterior, que admite SMB 3.1.1. Una buena fuente de información sobre SMB y Linux es SMB3 en Samba.

Por último, usar un recurso compartido de Network File System (NFS) es una opción. El uso de NFS no es una opción en las implementaciones de SQL Server basadas en Windows; solo se puede usar en implementaciones basadas en Linux.

Configuración del firewall

De forma similar a Windows, las distribuciones de Linux tienen un firewall integrado. Si en su empresa se usa un firewall externo a los servidores, deshabilitar los firewall en Linux es admisible. Sin embargo, independientemente de dónde esté habilitado el firewall, los puertos deben estar abiertos. En la siguiente tabla se documentan los puertos comunes necesarios en implementaciones de alta disponibilidad de SQL Server en Linux.

Número de puerto Tipo Descripción
111 TCP/UDP NFS: rpcbind/sunrpc
135 TCP Samba (si se usa): asignador de puntos de conexión
137 UDP Samba (si se usa): servicio de nombres de NetBIOS
138 UDP Samba (si se usa): datagrama de NetBIOS
139 TCP Samba (si se usa): sesión de NetBIOS
445 TCP Samba (si se usa): SMB a través de TCP
1433 TCP SQL Server: puerto predeterminado; si lo desea, se puede cambiar por mssql-conf set network.tcpport <portnumber>.
2049 TCP, UDP NFS (si se usa)
2224 TCP Pacemaker: usado por pcsd
3121 TCP Pacemaker: indispensable si hay nodos remotos de Pacemaker
3260 TCP Iniciador iSCSI (si se usa): se puede modificar en /etc/iscsi/iscsid.config (RHEL), pero debe coincidir con el puerto del destino iSCSI.
5022 TCP SQL Server: puerto predeterminado usado para un punto de conexión de grupo de disponibilidad; se puede cambiar al crear el punto de conexión.
5403 TCP Pacemaker
5404 UDP Pacemaker: indispensable para Corosync si se usa un UDP de multidifusión
5405 UDP Pacemaker: indispensable para Corosync
21064 TCP Pacemaker: indispensable para los recursos que usan DLM
Variable TCP Puerto del punto de conexión de grupo de disponibilidad; el valor predeterminado es 5022.
Variable TCP NFS: puerto de LOCKD_TCPPORT (se encuentra en /etc/sysconfig/nfs en RHEL).
Variable UDP NFS: puerto de LOCKD_UDPPORT (se encuentra en /etc/sysconfig/nfs en RHEL).
Variable TCP/UDP NFS: puerto de MOUNTD_PORT (se encuentra en /etc/sysconfig/nfs en RHEL).
Variable TCP/UDP NFS: puerto de STATD_PORT (se encuentra en /etc/sysconfig/nfs en RHEL).

Para saber qué otros puertos puede usar Samba, vea Uso de puertos de Samba.

Por otra parte, el nombre del servicio en Linux también se puede agregar como una excepción en lugar del puerto; por ejemplo, high-availability para Pacemaker. Consulte su distribución para obtener los nombres si este es el camino que quiere tomar. Por ejemplo, en RHEL, el comando que se agrega en Pacemaker es

sudo firewall-cmd --permanent --add-service=high-availability

Documentación del firewall

Instalación de paquetes de SQL Server para disponibilidad

En una instalación de SQL Server basada en Windows, algunos componentes se instalan incluso cuando se trata de una instalación de motor básica, mientras que otros no. En Linux, solo se instala el motor de SQL Server como parte del proceso de instalación. Todo lo demás es opcional. En el caso de las instancias de alta disponibilidad de SQL Server en Linux, se deben instalar dos paquetes con SQL Server:

  • Agente SQL Server (mssql-server-agent)
  • el paquete de alta disponibilidad (HA) (mssql-server-ha)

Aunque el Agente SQL Server es opcional desde un punto de vista técnico, es el programador de trabajos de SQL Server y, como tal, es necesario para el trasvase de registros, por lo que se recomienda instalarlo.

En SQL Server 2017 (14.x) con CU 4 y versiones posteriores, Agente SQL Server se incluye en el paquete motor de base de datos, pero aún necesita habilitarlo. En las instalaciones basadas en Windows, el Agente SQL Server no es opcional.

Nota:

Para quienes no conozcan SQL Server, el Agente SQL Server es el programador de trabajos integrado de SQL Server. Es el modo habitual en el que los administradores de bases de datos programan cosas como copias de seguridad y otras tareas de mantenimiento de SQL Server. A diferencia de una instalación basada en Windows de SQL Server, donde el Agente SQL Server es un servicio completamente diferente, en Linux, el Agente SQL Server se ejecuta en el contexto de SQL Server en sí.

Cuando los grupos de disponibilidad o las instancias de clúster de conmutación por error se configuran en una configuración basada en Windows, son compatibles con clústeres. La compatibilidad con clústeres significa que SQL Server tiene archivos DLL de recurso específicos que un WSFC conoce (sqagtres.dll y sqsrvres.dll para las instancias de clúster de conmutación por error; hadrres.dll para los grupos de disponibilidad) y que el WSFC usa para asegurarse de que la funcionalidad de agrupación en clúster de SQL Server funciona y lo hace correctamente. Dado que la agrupación en clústeres es externa no solo por lo que respecta a SQL Server, sino también a Linux, Microsoft tuvo que codificar el equivalente de un archivo DLL de recurso para las implementaciones de grupos de disponibilidad o instancias de clúster de conmutación por error basadas en Linux. Es el paquete mssql-server-ha, también conocido como agente de recursos de SQL Server para Pacemaker. Para instalar el paquete mssql-server-ha, consulte Implementación de un clúster de Pacemaker para SQL Server en Linux.

Los otros paquetes opcionales para SQL Server en Linux, la búsqueda de texto completo de SQL Server (mssql-server-fts) y SQL Server Integration Services (mssql-server-is) no se requieren para la alta disponibilidad, ya sea para una FCI o un AG.

Asociados de alta disponibilidad y recuperación ante desastres de SQL Server

Para proporcionar alta disponibilidad y recuperación ante desastres para los servicios de SQL Server, elija entre una amplia variedad de herramientas líderes del sector. En esta sección se destacan las compañías asociadas de Microsoft que cuentan con soluciones de alta disponibilidad y recuperación ante desastres compatibles con Microsoft SQL Server.

Asociado Descripción
DH2i DxEnterprise es un software de disponibilidad inteligente para Windows, Linux y Docker que ayuda a conseguir el tiempo de inactividad planeado y no planeado más próximo a cero, permite un ahorro significativo en costos, simplifica drásticamente la administración y permite conseguir una consolidación tanto física como lógica.

- Implementación de un grupo de disponibilidad con DH2i para contenedores de SQL Server en AKS
- Tutorial: Configuración de un grupo de disponibilidad Always On de tres nodos con DH2i DxEnterprise
HPE Serviceguard HPE SGLX A ofrece opciones de recuperación y supervisión contextuales para cargas de trabajo de instancias de clúster de conmutación por error y grupos de disponibilidad Always On. Maximice el tiempo de actividad con HPE SGLX sin comprometer el rendimiento ni la integridad de los datos.

- Tutorial: Configuración de un grupo de disponibilidad Always On de tres nodos con HPE Serviceguard para Linux
Pacemaker Pacemaker es un administrador de recursos de clúster de alta disponibilidad código abierto. Con Corosync, un sistema de comunicación de grupo de código abierto, Pacemaker puede detectar errores de componentes y organizar los procedimientos de conmutación por error necesarios para minimizar las interrupciones en las aplicaciones.

- Pacemaker para grupos de disponibilidad y FCI en Linux
- Implementación de un clúster de Pacemaker para SQL Server en Linux

Contenido relacionado