Requisitos previos, restricciones y recomendaciones para grupos de disponibilidad Always On

Se aplica a: SQL Server

En este artículo se describen las consideraciones necesarias para implementar Grupos de disponibilidad AlwaysOn, incluidos requisitos previos, restricciones y recomendaciones relativos a los equipos host, los clústeres de conmutación por error de Windows Server (WSFC), las instancias del servidor y los grupos de disponibilidad. Para cada uno de estos componentes, se indican los criterios de seguridad y permisos necesarios, si existen.

Revisiones de .NET que admiten grupos de disponibilidad

Según los componentes y características de SQL Server que use con Grupos de disponibilidad Always On, puede que tenga que instalar las revisiones de .NET adicionales identificadas en la tabla siguiente. Las revisiones pueden instalarse en cualquier orden.

Lista de comprobación: requisitos (sistema de Windows)

Para admitir la característica de Grupos de disponibilidad AlwaysOn , asegúrese de que cada equipo que vaya a participar en uno o varios grupos de disponibilidad cumpla los requisitos básicos siguientes:

Recomendaciones para equipos que alojan réplicas de disponibilidad (sistema de Windows)

• Sistemas comparables: en un grupo de disponibilidad determinado, todas las réplicas de disponibilidad deben ejecutarse en sistemas comparables que puedan controlar cargas de trabajo idénticas.

• Adaptadores de red dedicados: para obtener el mejor rendimiento, utilice un adaptador de red (tarjeta de interfaz de red) dedicado para grupos de disponibilidad AlwaysOn.

• Espacio en disco suficiente: todos los equipos en los que una instancia del servidor hospeda una réplica de disponibilidad deben poseer suficiente espacio en disco para todas las bases de datos del grupo de disponibilidad. Tenga en cuenta que según crecen las bases de datos principales, las correspondientes bases de datos secundarias aumentan la misma cantidad.

• Diseño de disco idéntico: cada equipo en el que una instancia de servidor hospeda una réplica de disponibilidad debe tener un diseño de disco idéntico (con letras y tamaños exactos de unidad de disco) para asegurarse de que las rutas de acceso de archivo de los archivos de base de datos (mdf, ldf) se reflejen, lo que evita complicaciones durante la propagación y sincronización. Revise Restricciones (bases de datos de disponibilidad) para los diseños de disco que difieren.

Permisos (sistema de Windows)

Para administrar un WSFC, el usuario debe ser administrador del sistema en cada nodo de clúster.

Para más información sobre la cuenta para administrar el clúster, vea Apéndice A: Requisitos de clúster de conmutación por error.

Tareas relacionadas (sistema de Windows)

Cambiar el valor de HostRecordTTL (con PowerShell)

1. Abra la ventana de PowerShell mediante Ejecutar como administrador.

2. Importe el módulo FailoverClusters.

3. Use el cmdlet Get-ClusterResource para encontrar el recurso Nombre de red y, después, use el cmdlet Set-ClusterParameter para establecer el valor HostRecordTTL de la siguiente manera:

   Get-ClusterResource "<NetworkResourceName>" | Set-ClusterParameter HostRecordTTL <TimeInSeconds>

   En el siguiente ejemplo de PowerShell se establece el HostRecordTTL en 300 segundos en un recurso de nombre de red denominado SQL Network Name (SQL35).

   Import-Module FailoverClusters
   
   $nameResource = "SQL Network Name (SQL35)"
   Get-ClusterResource $nameResource | Set-ClusterParameter HostRecordTTL 300
   

   Sugerencia

   Cada vez que abre una nueva ventana de PowerShell, necesita importar el módulo FailoverClusters .

Contenido relacionado (PowerShell)

• Clustering and High-Availability (Clústeres y alta disponibilidad) (blog del equipo de Agrupacion de clústeres de conmutación por error y equilibrio de carga de red)

• Introducción a Windows PowerShell en un clúster de conmutación por error

• Comandos de recursos de clúster y cmdlets equivalentes de Windows PowerShell

Contenido relacionado (sistema Windows)

• Configurar los valores de DNS en un clúster de conmutación por error de varios sitios

• Registro DNS con el recurso de nombre de red

Requisitos previos y restricciones de las instancias de SQL Server

Cada grupo de disponibilidad requiere un conjunto de asociados de conmutación por error, conocido como réplicas de disponibilidad, que se hospedan en instancias de SQL Server. Una instancia del servidor determinada puede ser una instancia independiente o una instancia de clúster de conmutación por error (FCI) de SQL Server.

Esta sección:

• Lista de comprobación: Requisitos previos
• Uso de subprocesos por parte de los grupos de disponibilidad
• Permisos
• Tareas relacionadas
• Contenido relacionado

Lista de comprobación: requisitos previos (instancia del servidor)

Para obtener una lista de las características admitidas por ediciones de SQL Server en Windows, vea:

• Ediciones y características admitidas de SQL Server 2022
• Ediciones y características admitidas de SQL Server 2019
• Ediciones y las características admitidas de SQL Server 2017
• Ediciones y las características admitidas de SQL Server 2016

Uso de subprocesos por parte de los grupos de disponibilidad

Grupos de disponibilidad AlwaysOn tiene los siguientes requisitos para los subprocesos de trabajo:

• En una instancia inactiva de SQL Server, Grupos de disponibilidad AlwaysOn usa 0 subprocesos.

• El número máximo de subprocesos usados por los grupos de disponibilidad es el valor configurado para el número máximo de subprocesos de servidor ('max worker threads') menos 40.

• Las réplicas de disponibilidad hospedadas en una instancia de servidor determinada comparten un único grupo de subprocesos en SQL Server 2019 (15.x) y versiones anteriores.

  Los subprocesos se comparten a petición, de la manera siguiente:

  • Normalmente, hay entre 3 y 10 subprocesos compartidos, pero este número puede aumentar según la carga de réplica principal.

  • Si un subproceso determinado está inactivo durante un tiempo, se libera de nuevo en el grupo de subprocesos general de SQL Server. Normalmente, un subproceso inactivo se libera después de unos 15 segundos de inactividad. Sin embargo, dependiendo de la última actividad, un subproceso inactivo se puede conservar más tiempo.

  • Una instancia de SQL Server utiliza hasta 100 subprocesos para puesta al día en paralelo para las réplicas secundarias. Cada base de datos utiliza hasta la mitad del número total de núcleos de CPU, pero no más de 16 subprocesos por base de datos. Si el número total de subprocesos necesarios para una única instancia supera los 100, SQL Server utiliza un solo subproceso de puesta al día para cada base de datos restante. Los subprocesos de rehacer en serie se liberan al cabo de aproximadamente 15 segundos de inactividad.

• Además, los grupos de disponibilidad usan subprocesos no compartidos, de la manera siguiente:

  • Cada réplica principal usa 1 subproceso de captura de registro para cada base de datos principal. Además, usa 1 subproceso de envío de registro para cada base de datos secundaria. Los subprocesos de envío de registro se liberan después de unos 15 segundos de inactividad.

  • Una copia de seguridad en una réplica secundaria contiene un subproceso en la réplica principal mientras dura la operación de copia de seguridad.

• SQL Server 2022 (16.x) introdujo el grupo de subprocesos de puesta al día paralelo, que es un grupo de subprocesos de nivel de instancia compartido con todas las bases de datos que tienen trabajo de puesta al día. Con este grupo, el mismo conjunto de subprocesos puede procesar los registros de bases de datos diferentes al mismo tiempo (en paralelo). En SQL Server 2019 (15.x) y versiones anteriores, el número de subprocesos disponibles para rehacer se limita a 100.

• SQL Server 2019 (15.x) presentó una puesta al día en paralelo de las bases de datos de grupo de disponibilidad optimizadas para memoria. En SQL Server 2016 (13.x) y 2017 (14.x), las tablas basadas en disco no usan la puesta al día en paralelo si una base de datos de un grupo de disponibilidad también está optimizada para memoria.

Para más información, vea Always On - HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases (Series de aprendizaje de Always ON - HADRON: Uso del grupo de trabajo para las bases de datos compatibles con HADRON) (Blog de ingenieros de CSS SQL Server).

Permisos (instancia del servidor)

Tareas relacionadas (instancia del servidor)

Contenido relacionado (instancia del servidor)

• Always On - HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases (Series de aprendizaje de Always ON - HADRON: uso del grupo de trabajo para las bases de datos compatibles con HADRON)

Recomendaciones de conexión de red

Se recomienda usar los mismos vínculos de red para las comunicaciones entre los nodos de WSFC y las comunicaciones entre las réplicas de disponibilidad. El uso de vínculos de red independientes puede provocar comportamientos inesperados si alguno de los vínculos da error (incluso de forma intermitente).

Por ejemplo, para que un grupo de disponibilidad admita la conmutación por error automática, la réplica secundaria que sea el asociado de conmutación por error automática debe tener el estado SYNCHRONIZED. Si el vínculo de red a esta réplica secundaria da error (incluso de forma intermitente), la réplica entra en el estado UNSYNCHRONIZED y no puede iniciarse para volver a sincronizar hasta que se restaure el vínculo. Si el WSFC solicita una conmutación automática por error mientras la réplica secundaria no está sincronizada, la conmutación por error automática no aparecerá.

Compatibilidad con conectividad de cliente

Para obtener información sobre la compatibilidad de grupos de disponibilidad Always On con la conectividad de cliente, consulte Compatibilidad de conectividad de cliente y controladores para grupos de disponibilidad.

Requisitos previos y restricciones para usar una instancia de clúster de conmutación por error (FCI) de SQL Server para alojar una réplica de disponibilidad

Esta sección:

• Restricciones
• Lista de comprobación: Requisitos previos
• Tareas relacionadas
• Contenido relacionado

Restricciones (FCI)

• Los nodos de clúster de una FCI solo pueden alojar una réplica de un grupo de disponibilidad determinado: si agrega una réplica de disponibilidad en una FCI, los nodos de WSFC que sean posibles propietarios de FCI no pueden hospedar otra réplica del mismo grupo de disponibilidad. Para evitar posibles conflictos, se recomienda configurar los posibles propietarios de la instancia de clúster de conmutación por error. Con esto se evita que un único WSFC intente alojar dos réplicas de disponibilidad para el mismo grupo de disponibilidad.

  Además, el resto de réplicas debe alojarse en una instancia de SQL Server que resida en otro nodo de clúster del mismo clúster de conmutación por error de Windows Server. La única excepción es que mientras se migra a otro clúster, un grupo de disponibilidad puede ocupar temporalmente dos clústeres.

  Advertencia

  Si usa el Administrador de clústeres de conmutación por error para mover una instancia de clúster de conmutación por error que aloja un grupo de disponibilidad a un nodo que ya aloja una réplica del mismo grupo de disponibilidad, podría provocar la pérdida de la réplica del grupo de disponibilidad, impidiendo que se ponga en línea en el nodo de destino. Un único nodo de un clúster de conmutación por error no puede alojar más de una réplica para el mismo grupo de disponibilidad. Para más información sobre cómo sucede esto y cómo recuperarse de este problema, eche un vistazo a la entrada de blog Réplica dejada inesperadamente en grupo de disponibilidad.

• Las FCI no admiten la conmutación automática por error por grupos de disponibilidad: las FCI no admiten la conmutación automática por error por grupos de disponibilidad; por tanto, todas las réplicas de disponibilidad hospedadas por una FCI solo se pueden configurar para la conmutación por error manual.

• Cambiar el nombre de red de FCI: si necesita cambiar el nombre de red de una FCI que aloje una réplica de disponibilidad, tendrá que quitar la réplica del grupo de disponibilidad y, después, agregarla de nuevo. No puede quitar la réplica principal, de modo que si cambia el nombre de una FCI que aloja la réplica principal, debe conmutar por error a una réplica secundaria, después quitar la réplica principal anterior y volver a agregarla. Cambiar el nombre de una FCI puede modificar la dirección URL del extremo de creación de reflejo de la base de datos. Al agregar la réplica asegúrese de especificar la dirección URL del extremo actual.

Lista de comprobación: requisitos previos (FCI)

Tareas relacionadas (FCI)

Contenido relacionado (FCI)

• Clústeres de conmutación por error y grupos de disponibilidad AlwaysOn (SQL Server)

• Guía de arquitectura de Always On: generación de una solución de alta disponibilidad y recuperación ante desastres mediante instancias de clúster de conmutación por error y grupos de disponibilidad

Requisitos previos y restricciones de los grupos de disponibilidad

Esta sección:

• Restricciones
• Requisitos
• Seguridad
• Tareas relacionadas

Restricciones (grupos de disponibilidad)

• Las réplicas de disponibilidad deben estar hospedadas en nodos diferentes de un WSFC: en un grupo de disponibilidad concreto, las réplicas de disponibilidad deben hospedarse en instancias de servidor que se ejecuten en nodos diferentes dentro del mismo WSFC. La única excepción es que mientras se migra a otro clúster, un grupo de disponibilidad puede ocupar temporalmente dos clústeres.

  Nota

  Cada una de las diferentes máquinas virtuales de un mismo equipo físico puede hospedar una réplica de disponibilidad para el mismo grupo de disponibilidad, porque cada máquina virtual actúa como un equipo independiente.

• Nombre único de grupo de disponibilidad: cada nombre de grupo de disponibilidad debe ser único en el WSFC. La longitud máxima del nombre de un grupo de disponibilidad es 128 caracteres.

• Réplicas de disponibilidad: cada grupo de disponibilidad admite una réplica principal y hasta ocho réplicas secundarias. Todas las réplicas pueden ejecutarse en el modo de confirmación asincrónica, o bien hasta cinco de ellas pueden ejecutarse en el modo de confirmación sincrónica (una réplica principal con dos réplicas secundarias sincrónicas). Cada réplica debe tener un nombre de servidor único en Windows y SQL Server. Los nombres de servidor entre Windows y SQL Server deben coincidir.

• Número máximo de grupos de disponibilidad y bases de datos de disponibilidad por equipo: El número real de bases de datos y grupos de disponibilidad que puede colocar en un equipo (equipo físico o máquina virtual) depende del hardware y de la carga de trabajo, pero no hay ningún límite impuesto. Microsoft ha probado hasta 10 grupos de disponibilidad y 100 bases de datos por máquina física, pero este no es un límite vinculante. Según la especificación de hardware en el servidor y la carga de trabajo, puede poner un mayor número de bases de datos y grupos de disponibilidad en una instancia de SQL Server. Los signos de sistemas sobrecargados pueden incluir, pero no limitarse a los siguientes: agotamiento de subprocesos de trabajo, tiempos de respuesta lentos para vistas del sistema del grupo de disponibilidad y DMV de AlwaysOn o volcados del sistema del distribuidor detenidos. Asegúrese de comprobar minuciosamente el entorno con una carga de trabajo similar a la que usará en producción para asegurarse de que puede controlar la capacidad de carga de trabajo máxima con sus contratos de nivel de servicio de aplicación. Cuando evalúe los contratos de nivel de servicio, no olvide tener en cuenta la carga en condiciones de error además de los tiempos de respuesta esperados.

• No use el Administrador de clústeres de conmutación por error para manipular grupos de disponibilidad. El estado de una Instancia del FCI de SQL Server se comparte entre SQL Server y el clúster de conmutación por error de Windows Server (WSFC), y SQL Server mantiene información de estado sobre las instancias más detallada que de la que se ocupa el clúster. El modelo de administración supone que SQL Server debe impulsar las transacciones y se encarga de mantener la vista de estado del clúster sincronizada con la vista de estado de SQL Server. Si el estado del clúster cambia fuera de SQL Server, es posible que el estado no esté sincronizado entre WSFC y SQL Server, lo que puede provocar un comportamiento impredecible.

  Por ejemplo:

  • No cambie ninguna propiedad del grupo de disponibilidad, como los posibles propietarios.

  • No use el Administrador de clústeres de conmutación por error para conmutar grupos de disponibilidad. Debe usar Transact-SQL o SQL Server Management Studio.

• No agregue recursos ni modifique las dependencias asociadas al rol de grupo de disponibilidad. No se recomienda colocar ningún recurso adicional (incluido el usuario o un tercero) en el rol de grupo de disponibilidad ni modificar las dependencias de rol, ya que estos cambios pueden afectar negativamente al rendimiento de la conmutación por error.

Requisitos previos (grupos de disponibilidad)

Al crear o establecer de nuevo una configuración de grupo de disponibilidad, asegúrese de que se adhiere a los siguientes requisitos.

Seguridad (grupos de disponibilidad)

• La seguridad se hereda del WSFC. El clúster de conmutación por error de Windows Server proporciona dos niveles de seguridad del usuario con una granularidad de clúster completo:

  • Acceso de solo lectura

  • Control total

    Grupos de disponibilidad AlwaysOn necesita el control total, y habilitar Grupos de disponibilidad AlwaysOn en una instancia de SQL Server proporciona control total del clúster (a través del SID de servicio).

    No puede agregar o quitar directamente la seguridad de una instancia del servidor en el Administrador de clústeres. Para administrar las sesiones de seguridad del clúster, use el administrador de configuración de SQL Server o el equivalente de WMI de SQL Server.

• Cada instancia de SQL Server debe tener permisos de acceso al Registro, al clúster, y así sucesivamente.

• Se recomienda utilizar cifrado para las conexiones entre las instancias del servidor que hospedan las réplicas de disponibilidad de Grupos de disponibilidad AlwaysOn .

Permisos (grupos de disponibilidad)

Tareas relacionadas (grupos de disponibilidad)

Requisitos previos y restricciones de las bases de datos de disponibilidad

Para poder agregar una base de datos a un grupo de disponibilidad, la base de datos debe cumplir los requisitos previos y restricciones siguientes.

Esta sección:

• Requisitos
• Restricciones
• Recomendaciones para equipos que alojan réplicas de disponibilidad (sistema de Windows)
• Permisos
• Tareas relacionadas

Lista de comprobación: requisitos (bases de datos de disponibilidad)

Para poder agregarse a un grupo de disponibilidad, una base de datos debe:

Restricciones (bases de datos de disponibilidad)

• Si la ruta de acceso de archivo (incluida la letra de unidad) de una base de datos secundaria es diferente de la ruta de acceso de la base de datos principal correspondiente, se aplican las restricciones siguientes:

  • Asistente para nuevo grupo de disponibilidad/agregar base de datos al grupo de disponibilidad: la opción Completa no es compatible (en la página Seleccionar sincronización de datos iniciales [asistentes para grupos de disponibilidad Always On]),

  • RESTORE WITH MOVE: para crear las bases de datos secundarias, se debe aplicar RESTORE WITH MOVE a todas las instancias de SQL Server que hospeden una réplica secundaria.

  • Impacto en las operaciones de agregar archivos: una operación posterior de agregar archivos a la réplica principal podría producir un error en las bases de datos secundarias. Este error puede causar la suspensión de las bases de datos secundarias. Esto, a su vez, hace que las réplicas secundarias entren en el estado NOT SYNCHRONIZING.

    Nota

    Para más información sobre cómo responder a una operación de agregar archivos errónea, consulte Solucionar problemas relativos a una operación de agregar archivos con error (grupos de disponibilidad AlwaysOn).

• No se puede quitar una base de datos que pertenezca actualmente a un grupo de disponibilidad.

Seguimiento de las bases de datos protegidas por TDE

Si usa cifrado de datos transparente (TDE), la clave de certificado o asimétrica para crear y descifrar otras claves debe ser la misma en todas las instancias de servidor que hospedan una réplica de disponibilidad para el grupo de disponibilidad. Para obtener más información, vea Mover una base de datos protegida por TDE a otra instancia de SQL Server.

Permisos (bases de datos de disponibilidad)

Requiere el permiso ALTER en la base de datos.

Tareas relacionadas (bases de datos de disponibilidad)

Contenido relacionado

• Guía de soluciones AlwaysOn de Microsoft SQL Server para lograr alta disponibilidad y recuperación ante desastres
• Blog del equipo Always On de SQL Server: el blog oficial del equipo de Always On de SQL Server
• Always On - HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases (Series de aprendizaje de Always ON - HADRON: uso del grupo de trabajo para las bases de datos compatibles con HADRON)
• ¿Qué es un grupo de disponibilidad AlwaysOn?
• Clústeres de conmutación por error y grupos de disponibilidad AlwaysOn (SQL Server)
• Compatibilidad con la conectividad de cliente y controlador para grupos de disponibilidad