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.

Importante

Antes de implementar Grupos de disponibilidad AlwaysOn, le recomendamos encarecidamente que lea todas las secciones de este tema.

Revisiones urgentes de .NET compatibles con grupos de disponibilidad

Dependiendo de los componentes y las características de SQL Server que utilice con los grupos de disponibilidad de Always On, puede que tenga que instalar las revisiones adicionales de .NET identificadas en la siguiente tabla. Puede instalar los hotfixes en cualquier orden.

Característica dependiente Corrección urgente Vínculo
Servicios de informes La corrección para .NET 3.5 SP1 agrega compatibilidad al cliente SQL para las características de Always On de intención de lectura, solo lectura y conmutación por error en varias subredes. La revisión urgente debe instalarse en cada servidor de informes de Reporting Services. KB 2654347: Corrección para .NET 3.5 SP1 para añadir compatibilidad con las características Always On

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:

Requisito Vínculo
Asegúrese de que el sistema no es un controlador de dominio. No se admiten grupos de disponibilidad en los controladores de dominio.
Procure que cada equipo ejecute una versión compatible de Windows Server Requisitos de hardware y software para:

- SQL Server 2025
- SQL Server 2022
- SQL Server 2019
- SQL Server 2016 y SQL Server 2017
Asegúrese de que cada equipo es un nodo en un WSFC. Clústeres de conmutación por error de Windows Server con SQL Server
Asegúrese de que el WSFC contiene los nodos suficientes para admitir las configuraciones de grupo de disponibilidad. Un nodo de clúster puede hospedar una réplica para un grupo de disponibilidad. El mismo nodo no puede hospedar dos réplicas del mismo grupo de disponibilidad. El nodo del clúster puede participar en varios grupos de disponibilidad, con una réplica de cada grupo.

Pregunte a los administradores de bases de datos cuántos nodos de clúster se requieren para admitir las réplicas de disponibilidad de los grupos de disponibilidad planeados.

¿Qué es un grupo de disponibilidad Always On?

Importante

Asegúrese también de que el entorno esté configurado correctamente para conectarse a un grupo de disponibilidad. Para más información, consulte la compatibilidad de conectividad de controladores y clientes para grupos de disponibilidad.

Recomendaciones para equipos que alojan réplicas de disponibilidad (sistema 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.

  • Configuración del regulador de recursos: Si usa el regulador de recursos, use la misma configuración del regulador de recursos en todas las instancias que hospedan réplicas del grupo de disponibilidad.

Permisos (sistema de Windows)

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

Para obtener más información sobre la cuenta de administración del clúster, consulte Apéndice A: Requisitos del clúster de conmutación por error.

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 <TiempoEnSegundos>

    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)

Contenido relacionado (sistema Windows)

Requisitos previos y restricciones de las instancias de SQL Server

Cada grupo de disponibilidad requiere un conjunto de compañeros de conmutación por error, denominados réplicas de disponibilidad, alojadas 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.

En esta sección:

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

Requisito previo Vínculos
Este equipo host debe ser un nodo de WSFC. Las instancias de SQL Server que hospedan réplicas de disponibilidad de un determinado grupo de disponibilidad residen en nodos independientes del clúster. Un grupo de disponibilidad puede ocupar temporalmente dos clústeres mientras se migra a otro clúster. SQL Server 2016 (13.x) incorpora la novedad de los grupos de disponibilidad distribuidos. En un grupo de disponibilidad distribuido, dos grupos de disponibilidad residen en clústeres distintos. Clústeres de conmutación por error de Windows Server con SQL Server

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

Grupos de disponibilidad distribuidos
Si desea que un grupo de disponibilidad trabaje con Kerberos:

Todas las instancias de servidor que hospedan una réplica de disponibilidad para el grupo de disponibilidad deben usar la misma cuenta de servicio de SQL Server.

El administrador de dominio debe registrar manualmente un nombre principal de servicio (SPN) en Active Directory en la cuenta de servicio de SQL Server para el nombre de red virtual (VNN) del agente de escucha del grupo de disponibilidad. Si el SPN se registra en una cuenta distinta de la cuenta del servicio SQL Server, la autenticación falla.

Para usar la autenticación Kerberos para la comunicación entre los puntos de conexión del grupo de disponibilidad (AG), registre manualmente los SPN para los puntos de conexión de creación de reflejo de la base de datos usados por el grupo de disponibilidad.

Importante: Si cambia la cuenta del servicio SQL Server, el administrador de dominio necesita volver a registrar manualmente el SPN.		 Registrar un nombre de entidad de seguridad de servicio para las conexiones con Kerberos

Nota:

Kerberos y los SPN exigen la autenticación mutua. El SPN se asigna a la cuenta de Windows que inicia los servicios SQL Server. Si el SPN no se registra correctamente o provoca un error, el nivel de seguridad de Windows no podrá determinar la cuenta asociada al SPN y no podrá utilizarse la autenticación Kerberos.

Nota:NTLM no tiene este requisito.
Si va a usar una instancia de clúster de conmutación por error (FCI) de SQL Server para hospedar una réplica de disponibilidad, asegúrese de que comprende las restricciones de FCI y de que se cumplen los requisitos de FCI. Requisitos previos y requisitos para usar una instancia de clúster de conmutación por error (FCI) de SQL Server para hospedar una réplica de disponibilidad (más adelante en este artículo)
Cada instancia del servidor debe ejecutar la misma versión de SQL Server para participar en un grupo de disponibilidad. Para obtener más información, consulta la lista de ediciones y características compatibles al final de esta sección.
Todas las instancias del servidor que alojan réplicas de disponibilidad para un grupo de disponibilidad deben usar la misma intercalación de SQL Server. Configurar o cambiar el criterio de ordenación del servidor
Habilite la característica de Grupos de disponibilidad AlwaysOn en cada instancia de servidor que hospeda una réplica de disponibilidad para cualquier grupo de disponibilidad. En un equipo determinado, puede habilitar tantas instancias de servidor de Grupos de disponibilidad AlwaysOn como admita la instalación de SQL Server . Habilitar o deshabilitar la característica de grupos de disponibilidad Always On

Importante: Si elimina y vuelve a crear un WSFC, debe deshabilitar y volver a habilitar la característica Grupos de disponibilidad Always On en cada instancia del servidor habilitada para dicha característica en el clúster original.
Cada instancia del servidor requiere un extremo de creación de reflejo de la base de datos. Este extremo es compartido por todas las réplicas de disponibilidad y por los asociados y testigos de la creación de reflejo de la base de datos en la instancia del servidor.

Si una instancia de servidor que seleccione para hospedar una réplica de disponibilidad se ejecuta con una cuenta de usuario de dominio y todavía no tiene un extremo de creación de reflejo de la base de datos, el Asistente para grupos de disponibilidad (SQL Server Management Studio) (o Agregar una réplica a su grupo de disponibilidad Always On mediante el Asistente para grupos de disponibilidad en SQL Server Management Studio) puede crear el extremo y conceder CONNECT permiso a la cuenta de servicio de la instancia de servidor. Sin embargo, si el servicio SQL Server se ejecuta con una cuenta integrada del sistema, como Sistema local, Servicio local o Servicio de red, o con una cuenta no perteneciente a un dominio, debe usar certificados para la autenticación de puntos de conexión, y el asistente no puede crear un punto de conexión para la creación de reflejo de la base de datos en la instancia del servidor. En este caso, se recomienda crear los extremos de creación de reflejo de la base de datos manualmente antes de iniciar el asistente.

Nota de seguridad: La seguridad del transporte para los grupos de disponibilidad Always On es la misma que la de la creación de reflejo de la base de datos.		 Punto de conexión de creación de reflejo de la base de datos (SQL Server)

Seguridad del transporte - Creación de reflejo de la base de datos - Disponibilidad Always On
Si va a agregar cualquier base de datos que usa FILESTREAM a un grupo de disponibilidad, asegúrese de que FILESTREAM está habilitado en cada instancia de servidor que alojará una réplica de disponibilidad para el grupo de disponibilidad. Habilitar y configurar FILESTREAM
Si va a agregar cualquier base de datos independiente a un grupo de disponibilidad, asegúrese de que la autenticación de base de datos independiente (la opción de configuración del servidor) esté establecida en 1 en cada instancia del servidor que aloja una réplica de disponibilidad para el grupo de disponibilidad. Configuración del servidor: autenticación de base de datos independiente

Opciones de configuración del servidor

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

Uso de hilos de los grupos de disponibilidad

Los grupos de disponibilidad de Always On tienen los siguientes requisitos para los subprocesos de trabajo:

  • En una instancia inactiva de SQL Server, los grupos de disponibilidad de Always On usan 0 subprocesos.

  • El número máximo de subprocesos usados por los grupos de disponibilidad es la configuración configurada 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 hilos compartidos, pero este número puede aumentar en función de la carga de trabajo de la 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 hilo inactivo se libera tras 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 hilos para el rehacer en paralelo de 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 hilos de rehacer en serie se liberan al cabo de aproximadamente 15 segundos de inactividad.

  • Además, los grupos de disponibilidad utilizan subprocesos no compartidos, como se indica a continuación:

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

    • Una copia de seguridad en una réplica secundaria mantiene ocupado un subproceso en la réplica principal durante toda 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 hilos disponibles para la operación de 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 obtener más información, vea AlwaysOn - HADRON Learning Series: Uso del grupo de trabajo para bases de datos habilitadas para HADRON (blog de ingenieros de SQL Server de CSS).

Permisos (instancia del servidor)

Tarea Permisos necesarios
Crear el extremo de creación de reflejo de la base de datos Requiere CREATE ENDPOINT permiso o pertenencia al rol fijo de servidor sysadmin . También requiere CONTROL ON ENDPOINT permiso. Para obtener más información, consulte GRANT Permisos de punto de conexión.
Habilitar Grupos de disponibilidad AlwaysOn Requiere la pertenencia al grupo Administrador en el equipo local y control total del WSFC.

Tarea Artículo
Determinar si existe un extremo de creación de reflejo de la base de datos sys.database_mirroring_endpoints
Crear el extremo de creación de reflejo de la base de datos (si aún no existe) Crear un punto de conexión de duplicación de la base de datos para la autenticación de Windows

Uso de certificados para un punto de conexión de reflejo de base de datos

Crear un extremo de creación de reflejo de la base de datos para un grupo de disponibilidad mediante PowerShell
Habilitación de grupos de disponibilidad Habilitar o deshabilitar la característica de grupos de disponibilidad Always On

Contenido relacionado (instancia del servidor)

Recomendaciones de conexión de red

Recomendamos encarecidamente que utilice los mismos enlaces 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 WSFC solicita una conmutación por error automática cuando la réplica secundaria no está sincronizada, la conmutación por error automática no se producirá.

Soporte de conectividad del 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 utilizar una instancia de clúster de conmutación por error (FCI) de SQL Server para alojar una réplica de disponibilidad

En esta sección:

Restricciones (FCI)

Nota:

Las instancias de clúster de conmutación por error (FCI) también admiten volúmenes compartidos en clúster (CSV). Para obtener más información sobre CSV, consulte Introducción a los volúmenes compartidos de clúster en un clúster de conmutación por error.

  • 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 nodos que pueden ser propietarios de la instancia de clúster de conmutación por error. Esto evita potencialmente 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

    Usar el Administrador de clústeres de conmutación por error para mover una FCI que hospeda un grupo de disponibilidad a un nodo que ya hospeda una réplica del mismo grupo de disponibilidad puede provocar la pérdida de la réplica del grupo de disponibilidad, lo que impediría ponerla 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 obtener más información sobre cómo ocurre esto y cómo recuperarse, consulte la entrada del blog Réplica quitada inesperadamente del 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 lo que cualquier réplica de disponibilidad hospedada por una FCI solo se puede 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 se puede quitar la réplica principal, por lo que, si va a cambiar el nombre de una FCI que aloja la réplica principal, debe realizar una conmutación por error a una réplica secundaria y, después, quitar la que antes era la réplica principal 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 (FCIs)

Requisito previo Vínculo
Asegúrese de que cada instancia de clúster de conmutación por error (FCI) de SQL Server posee el almacenamiento compartido necesario según la instalación estándar de la instancia de clúster de conmutación por error de SQL Server.

Tarea Artículo
Instalación de una FCI de SQL Server Creación de una nueva instancia de clúster de conmutación por error AlwaysOn (programa de instalación)
Actualización local del FCI de SQL Server existente Actualización de una instancia del clúster de conmutación por error
Mantener el FCI de SQL Server existente Agregar o quitar nodos en una instancia de clúster de conmutación por error (Configuración)

Contenido relacionado (FCIs)

Requisitos previos y restricciones de los grupos de disponibilidad

En esta sección:

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 AG y 100 bases de datos por cada máquina física; sin embargo, este no es un límite estricto. 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 saturados pueden incluir, entre otros, el agotamiento de los hilos de trabajo, tiempos de respuesta lentos en las vistas del sistema y las DMV del grupo de disponibilidad, y/o volcados del sistema del despachador bloqueados. 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 utilice el Administrador de clústeres de conmutación por error para administrar los grupos de disponibilidad. El estado de una instancia de clúster de conmutación por error (FCI) de SQL Server lo comparten SQL Server y el clúster de conmutación por error de Windows Server (WSFC), y SQL Server mantiene información de estado más detallada sobre las instancias que la que necesita 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.

Requisito previo Descripción
Si va a usar una instancia de clúster de conmutación por error (FCI) de SQL Server para hospedar una réplica de disponibilidad, asegúrese de que comprende las restricciones de FCI y de que se cumplen los requisitos de FCI. Requisitos previos y restricciones del uso de una instancia de clúster de conmutación por error (FCI) de SQL Server para alojar una réplica de disponibilidad (anteriormente en este artículo)

Seguridad (grupos de disponibilidad)

  • La seguridad se hereda del WSFC. La agrupación en clústeres de conmutación por error de Windows Server proporciona dos niveles de seguridad para el usuario a nivel de todo el clúster:

    • Acceso de solo lectura

    • Control completo

      Los grupos de disponibilidad AlwaysOn necesitan control total y habilitar los grupos de disponibilidad AlwaysOn en una instancia de SQL Server le proporciona control total del clúster (a través del servicio SID).

      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 alojan las réplicas de disponibilidad de los grupos de disponibilidad Always On.

Permisos (grupos de disponibilidad)

Tarea Permisos necesarios
Crear un grupo de disponibilidad Requiere pertenecer al rol fijo de servidor sysadmin y uno de los permisos de servidor CREATE AVAILABILITY GROUP, ALTER ANY AVAILABILITY GROUP o CONTROL SERVER.
Modificación de un grupo de disponibilidad Requiere el permiso ALTER AVAILABILITY GROUP sobre el grupo de disponibilidad, el permiso CONTROL AVAILABILITY GROUP, el permiso ALTER ANY AVAILABILITY GROUP o el permiso CONTROL SERVER.

Además, para agregar una base de datos a un grupo de disponibilidad, es necesario pertenecer al rol fijo de base de datos db_owner.
Quitar o eliminar un grupo de disponibilidad Requiere el permiso ALTER AVAILABILITY GROUP sobre el grupo de disponibilidad, el permiso CONTROL AVAILABILITY GROUP, el permiso ALTER ANY AVAILABILITY GROUP o el permiso CONTROL SERVER. Para eliminar un grupo de disponibilidad que no está alojado en la ubicación de la réplica local, necesita el permiso CONTROL SERVER o el permiso CONTROL en ese grupo de disponibilidad.

Tarea Artículo
Crear un grupo de disponibilidad Usar el Asistente para grupo de disponibilidad (SQL Server Management Studio)

Creación de un grupo de disponibilidad Always On mediante Transact-SQL (T-SQL)

Creación de un grupo de disponibilidad Always On con PowerShell

Especificar la dirección URL del punto de conexión - Agregar o modificar una réplica de disponibilidad
Modificación del número de réplicas de disponibilidad Agregar una réplica secundaria a un grupo de disponibilidad Always On

Unir una réplica secundaria a un grupo de disponibilidad de Always On

Quitar una réplica secundaria de un grupo de disponibilidad (SQL Server)
Crear un agente de escucha de grupo de disponibilidad Configuración de un agente de escucha para un grupo de disponibilidad Always On
Eliminación de un grupo de disponibilidad Eliminar un grupo de disponibilidad (SQL Server)

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.

En esta sección:

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

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

Requisitos Vínculo
Ser una base de datos de usuario. Las bases de datos del sistema no pueden pertenecer a un grupo de disponibilidad.
Residir en la instancia de SQL Server en la que cree el grupo de disponibilidad y ser accesible desde la instancia del servidor.
Ser una base de datos de lectura/escritura. Las bases de datos de solo lectura no se pueden agregar a un grupo de disponibilidad. sys.databases (is_read_only = 0)
Ser una base de datos multiusuario. sys.databases (user_access = 0)
No utilice AUTO_CLOSE. sys.databases (is_auto_close_on = 0)
Use el modelo de recuperación completa. sys.databases (recovery_model = 1)
Posea al menos una copia de seguridad completa de la base de datos.

Nota: Después de establecer una base de datos en modo de recuperación completa, se requiere una copia de seguridad completa para iniciar la cadena de registros de recuperación completa.		 Creación de una copia de seguridad completa de la base de datos
No pertenecer a ningún grupo de disponibilidad existente sys.databases (group_database_id = NULL)
No estar configurada para el reflejo de la base de datos. sys.database_mirroring (si la base de datos no participa en la creación de reflejo, todas las columnas con el prefijo “mirroring_” son NULL).
Para poder agregar una base de datos que usa FILESTREAM a un grupo de disponibilidad, asegúrese de que FILESTREAM está habilitado en cada instancia del servidor que hospeda o que hospedará una réplica de disponibilidad para el grupo de disponibilidad. Habilitar y configurar FILESTREAM
Antes de agregar una base de datos independiente a un grupo de disponibilidad, asegúrese de que la opción de servidor contained database authentication está establecida en 1 en cada instancia del servidor que hospeda o que hospedará una réplica de disponibilidad para el grupo de disponibilidad. Configuración del servidor: autenticación de base de datos independiente

Opciones de configuración del servidor

Nota:

Los grupos de disponibilidad de Always On funcionan con cualquier nivel de compatibilidad de base de datos compatible.

Restricciones (bases de datos de disponibilidad)

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

  • 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, consulte Traslado de una base de datos protegida por TDE a otra instancia de SQL Server.

Permisos (bases de datos de disponibilidad)

Requiere permiso ALTER en la base de datos.

Tarea Artículo
Preparar una base de datos secundaria (manualmente) Preparación de una base de datos secundaria para un grupo de disponibilidad Always On
Combinar una base de datos secundaria con un grupo de disponibilidad (manualmente) Unión de una base de datos secundaria con un grupo de disponibilidad Always On
Modificar el número de bases de datos de disponibilidad Agregar una base de datos a un grupo de disponibilidad AlwaysOn

Quitar una base de datos secundaria de un grupo de disponibilidad (SQL Server)

Eliminación de una base de datos principal de un grupo de disponibilidad Always On

Contenido relacionado

  • Last updated on