Compartir a través de

Requisitos previos, restricciones y recomendaciones para Grupos de disponibilidad AlwaysOn (SQL Server)

  • Artículo

En este tema se describen las consideraciones para implementar grupos de disponibilidad AlwaysOn, incluidos requisitos previos, restricciones y recomendaciones para equipos host, clústeres de clústeres de conmutación por error de Windows Server (WSFC), instancias de servidor y 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, se recomienda encarecidamente leer todas las secciones de este tema.

Revisiones de .NET que admiten grupos de disponibilidad AlwaysOn

En función de los componentes y características de SQL Server 2014 que usará con grupos de disponibilidad AlwaysOn, es posible que tenga que instalar revisiones adicionales de .NET identificadas en la tabla siguiente. Las revisiones pueden instalarse en cualquier orden.

Característica dependiente Revisión Vínculo
Casilla Reporting Services La revisión para .NET 3.5 SP1 agrega compatibilidad con el cliente SQL para las características alwaysOn de la intención de lectura, lectura y multisubnetfailover. La revisión tiene que instalarse en cada servidor de informes Reporting Services . KB 2654347: revisión para .NET 3.5 SP1 para agregar compatibilidad con las características de AlwaysOn

Requisitos del sistema de Windows y recomendaciones

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

Para admitir la característica Grupos de disponibilidad AlwaysOn, asegúrese de que todos los equipos que participen en uno o varios grupos de disponibilidad cumplen los siguientes requisitos fundamentales:

Requisito Vínculo
Casilla Asegúrese de que el sistema no es un controlador de dominio. No se admiten grupos de disponibilidad en los controladores de dominio.
Casilla Asegúrese de que cada equipo esté ejecutando Windows Server 2008 x86 (no WOW64) o x64 o versiones posteriores. WOW64 (Windows 32 bits en Windows 64 bits) no admite grupos de disponibilidad AlwaysOn.
Casilla Asegúrese de que cada equipo es un nodo de un clúster de conmutación por error de Windows Server (WSFC). Clústeres de conmutación por error de Windows Server (WSFC) con SQL Server
Casilla Asegúrese de que el clúster de WSFC contiene los nodos suficientes para admitir las configuraciones de grupo de disponibilidad. Un nodo de WSFC solo puede hospedar una única réplica de disponibilidad para un grupo de disponibilidad dado. En un nodo WSFC determinado, una o varias instancias de SQL Server pueden hospedar réplicas de disponibilidad para muchos grupos de disponibilidad.

Consulte a los administradores de bases de datos cuántos nodos de WSFC se requieren para admitir las réplicas de disponibilidad de los grupos de disponibilidad planeados.

Información general sobre los grupos de disponibilidad AlwaysOn (SQL Server).
Casilla Asegúrese de que todas las revisiones aplicables de Windows se hayan instalado en cada nodo del clúster de WSFC. ** Importante ** Se requieren varias revisiones o se recomiendan para los nodos de un clúster de WSFC en el que se implementan grupos de disponibilidad AlwaysOn. Para obtener más información, vea Revisiones de Windows que admiten los grupos de disponibilidad AlwaysOn (Windows System), más adelante en esta sección.

Importante

Asegúrese también de que el entorno esté configurado correctamente para conectarse a un grupo de disponibilidad. Para obtener más información, vea Conectividad de cliente AlwaysOn (SQL Server) .

Revisiones de Windows que admiten los grupos de disponibilidad AlwaysOn (Windows System)

En función de la topología del clúster, es posible que se apliquen varias revisiones adicionales de Windows Server 2008 Service Pack 2 (SP2) o Windows Server 2008 R2 para admitir grupos de disponibilidad AlwaysOn. En la tabla siguiente se identifican estas revisiones. Las revisiones pueden instalarse en cualquier orden.

Se aplica a Windows 2008 SP2 Se aplica a Windows 2008 R2 SP1 Incluido en Windows 2012 Para admitir... Revisión Vínculo
Casilla Sí Sí Sí Configuración del cuórum WSFC óptimo En cada nodo de WSFC, asegúrese de que esté instalada la revisión descrita en el artículo 2494036 de Knowledge Base.

Esta revisión admite quórum óptimo de configuración con los destinos no automáticos de conmutación por error. Esta funcionalidad mejora los clústeres de varios sitios que permite seleccionar a qué nodos se vota.		 KB 2494036: Hay disponible una revisión que permite configurar un nodo del clúster que no tiene los votos de quórum en Windows Server 2008 y Windows Server 2008 R2

Para obtener información sobre la votación de cuórum, vea Modos de cuórum de WSFC y Configuración de votación (SQL Server)
Casilla Sí Sí Sí Uso más eficaz del ancho de banda de red En cada nodo WSFC, asegúrese de que esté instalada la revisión descrita en el artículo 2616514 de Knowledge Base.

Sin esta revisión, el servicio Cluster envía notificaciones innecesarias del Registro entre los nodos del clúster. Este comportamiento limita el ancho de banda de red, que es un problema grave para los grupos de disponibilidad AlwaysOn.		 KB 2616514: El servicio de clúster envía notificaciones de cambio de claves del Registro innecesarias entre los nodos del clúster en Windows Server 2008 o en Windows Server 2008 R2
Casilla Sí No aplicable Pruebas de almacenamiento VPD en discos que no están disponibles para todos los nodos de WSFC Si un nodo de WSFC ejecuta Windows Server 2008 R2 Service Pack 1 (SP1) y la prueba de almacenamiento Validar datos vitales de producto (VPD) de dispositivo SCSI produce errores una vez que se ejecuta incorrectamente en los discos que están en línea y no disponibles para todos los nodos del clúster de WSFC, instale de la revisión descrita en el artículo 2531907 de Knowledge Base.

Esta revisión elimina las advertencias o errores incorrectos en el informe de validación cuando los discos están en línea.		 KB 2531907: La prueba Validar datos vitales de producto (VPD) de dispositivo SCSI produce un error después de instalar Windows Server 2008 R2 SP1
Casilla Sí Sí Conmutación por error más rápida a réplicas locales Si un nodo de WSFC ejecuta Windows Server 2008 R2 Service Pack 1 (SP1), asegúrese de que la revisión descrita en el artículo 2687741 de Knowledge Base esté instalada.

Esta revisión mejora el rendimiento de la conmutación por error de los grupos de disponibilidad AlwaysOn a las réplicas locales.		 2687741 KB: Una revisión que mejora el rendimiento “del grupo de AlwaysOn disponibilidad de la función” en SQL Server 2012 está disponible en Windows Server 2008 R2
Casilla Sí Sí Sí Almacenamiento asimétrico para instancias de clúster de conmutación por error (FCI) Si se habilitará cualquier instancia de clúster de conmutación por error (FCI) para grupos de disponibilidad AlwaysOn, instale la revisión de Windows Server 2008 976097.

Esta revisión permite que el complemento Microsoft Management Console (MMC) de administración de clústeres de conmutación por error admita discos compartidos de almacenamiento asimétricos que solo están disponibles en algunos de los nodos WSFC.		 KB 976097: Revisión para agregar compatibilidad con los almacenamientos asimétricos al complemento MMC de administración de clústeres de conmutación por error para un clúster de conmutación por error que ejecute Windows Server 2008 o Windows Server 2008 R2

Guía de arquitectura de AlwaysOn: Creació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
Casilla Sí Sí No aplicable Seguridad del protocolo de Internet (IPsec) Si un entorno usa conexiones IPsec, puede experimentar un retraso prolongado (aproximadamente de dos o tres minutos) cuando un equipo cliente restablece la conexión IPsec con un nombre de red virtual (en este contexto, para conectarse al agente de escucha del grupo de disponibilidad). Si usa conexiones IPsec, recomendamos que revise los escenarios específicos detallados en el artículo de Knowledge Base (KB 980915). KB 980915: Se produce un retraso prolongado cuando se vuelve a conectar una conexión de IPsec desde un equipo que ejecuta Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7 o Windows Server 2008 R2
Casilla Sí Sí Sí IPv6 Si usa IPv6, recomendamos que revise los escenarios específicos detallados en el artículo de Knowledge Base 2578103 o 2578113, en función de su sistema operativo Windows Server.

Si la topología de Windows Server usa IP versión 6 (IPv6), el servicio de clúster WSFC requiere en torno a 30 segundos para la conmutación por error de la dirección IP IPv6. Esto hace que los clientes esperen aproximadamente 30 segundos para volver a conectarse a la dirección IP IPv6.		 KB 2578103 (Windows Server 2008): El servicio de clúster tarda en torno a 30 segundos en la conmutación por error de las direcciones IP IPv6 en Windows Server 2008

KB 2578113 (Windows Server 2008 R2): Windows Server 2008 R2: el servicio de clúster tarda aproximadamente 30 segundos en conmutar por error direcciones IP IPv6 en Windows Server 2008 R2
Casilla Sí Sí Sí Sin enrutador entre el clúster y el servidor de aplicaciones Si no hay ningún enrutador entre el clúster de conmutación por error y el servidor de aplicaciones, el servicio de Cluster Server realiza con lentitud la conmutación por error de los recursos relacionados con la red. Esto retrasa las conexiones de cliente después de producirse la conmutación por error del grupo de disponibilidad. Si no hay un enrutador, se recomienda revisar los escenarios concretos detallados en el artículo de Knowledge Base 2582281 e instalar la revisión, si es aplicable a su entorno. KB 2582281: Reducir la operación de conmutación por error si no existe un enrutador entre el clúster y un servidor de aplicaciones

Recomendaciones para equipos que hospedan 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, use un adaptador de red dedicado (tarjeta de interfaz de red) 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.

Permisos (sistema de Windows)

Para administrar un clúster de 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)

Tarea Vínculo
Establecer el valor de HostRecordTTL. Cambiar el valor de HostRecordTTL (con Windows PowerShell)

Cambiar el valor de HostRecordTTL (con Windows PowerShell)

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

  2. Importe el módulo FailoverClusters.

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

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

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

    Import-Module FailoverClusters  

$nameResource = "SQL Network Name (SQL35)"  
Get-ClusterResource $nameResource | Set-ClusterParameter 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 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 SQL Serverinstancia de clúster de conmutación por error (FCI).

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

Requisito previo Vínculos
Casilla El equipo host debe ser en un nodo de clúster de conmutación por error de Windows Server (WSFC). Las instancias de SQL Server que hospedan réplicas de disponibilidad para un grupo de disponibilidad determinado deben residir en nodos independientes de un único clúster WSFC. La única excepción es que mientras se migra a otro clúster de WSFC, un grupo de disponibilidad puede ocupar temporalmente dos clústeres. Clústeres de conmutación por error de Windows Server (WSFC) con SQL Server

Clúster de conmutación por error y grupos de disponibilidad de AlwaysOn (SQL Server)
Casilla 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) con Active Directory en la cuenta del servicio 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 no se realizará correctamente.

** Importante ** Si cambia la cuenta de servicio de SQL Server, el administrador de dominio deberá volver a registrar manualmente el SPN.		 Registrar un nombre principal de servicio para las conexiones con Kerberos

Breve explicación:

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.
Casilla 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 tema)
Casilla Cada instancia de servidor debe ejecutar enterprise Edition de SQL Server 2014. Características admitidas por las ediciones de SQL Server 2014
Casilla Todas las instancias del servidor que hospedan réplicas de disponibilidad para un grupo de disponibilidad deben usar la misma intercalación de SQL Server . Configurar o cambiar la intercalación del servidor
Casilla Habilite la característica Grupos de disponibilidad AlwaysOn en cada instancia de servidor que hospedará una réplica de disponibilidad para cualquier grupo de disponibilidad. En un equipo determinado, puede habilitar tantas instancias de servidor para grupos de disponibilidad AlwaysOn como admita la instalación de SQL Server. Habilitar y deshabilitar grupos de disponibilidad AlwaysOn (SQL Server)

** Importante ** Si elimina y vuelve a crear un clúster de WSFC, debe deshabilitar y volver a habilitar la característica Grupos de disponibilidad AlwaysOn en cada instancia de servidor habilitada para grupos de disponibilidad AlwaysOn en el clúster WSFC original.
Casilla Cada instancia del servidor requiere un extremo de creación de reflejo de la base de datos. Observe que todas las réplicas de disponibilidad, asociados de creación de reflejo de la base de datos y testigos de la instancia del servidor comparten este extremo.

Si una instancia de servidor seleccionada para hospedar una réplica de disponibilidad se ejecuta bajo una cuenta de usuario de dominio y no tiene todavía un punto de conexión de creación de reflejo de la base de datos, el Asistente para nuevo grupo de disponibilidad (o el asistente Agregar réplica a grupo de disponibilidad) puede crear el punto de conexión y conceder el permiso CONNECT a la cuenta de servicio de la instancia de servidor. Sin embargo, si el servicio SQL Server se ejecuta como una cuenta integrada (como sistema local, servicio local o servicio de red), o una cuenta que no es de dominio, debe usar certificados para la autenticación de extremos y el asistente no podrá crear un extremo de creación de reflejo de la base de datos en la instancia de 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 ** Seguridad de transporte para grupos de disponibilidad AlwaysOn es el mismo que para la creación de reflejo de la base de datos.		 El extremo de creación de reflejo de la base de datos (SQL Server)

Seguridad de transporte para la creación de reflejo de la base de datos y los grupos de disponibilidad AlwaysOn (SQL Server)
Casilla 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 hospedará una réplica de disponibilidad para el grupo de disponibilidad. Enable and Configure FILESTREAM
Casilla Si va a agregar cualquier 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 hospedará una réplica de disponibilidad para el grupo de disponibilidad. contained database authentication (opción de configuración del servidor)

Opciones de configuración de servidor (SQL Server)

Uso de subprocesos por parte de los grupos de disponibilidad

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

  • En una instancia inactiva de SQL Server, los grupos de disponibilidad AlwaysOn usan 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 dada comparten un único grupo de subprocesos.

    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.

  • 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.

    • Cada réplica secundaria usa 1 subproceso de rehacer para cada base de datos secundaria. Los subprocesos de rehacer 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.

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 css).

Permisos (instancia del servidor)

Tarea Permisos necesarios
Crear el extremo de creación de reflejo de la base de datos Requiere permiso CREATE ENDPOINT o pertenecer al rol fijo de servidor sysadmin . También requiere el permiso CONTROL ON ENDPOINT. Para más información, consulte Permisos de punto de conexión de GRANT (Transact-SQL).
Habilitación de grupos de disponibilidad AlwaysOn Requiere la pertenencia al grupo Administrador en el equipo local y control total del clúster de WSFC.

Tareas relacionadas (instancia del servidor)

Tarea Tema
Determinar si existe un extremo de creación de reflejo de la base de datos sys.database_mirroring_endpoints (Transact-SQL)
Crear el extremo de creación de reflejo de la base de datos (si aún no existe) Crear un extremo de reflejo de la base de datos para la autenticación de Windows (Transact-SQL)

Usar certificados para un punto de conexión de creación de reflejo de la base de datos (Transact-SQL)

Crear un punto de conexión de creación de reflejo de la base de datos para grupos de disponibilidad AlwaysOn (SQL Server PowerShell)
Habilitar los grupos de disponibilidad de AlwaysOn Habilitar y deshabilitar grupos de disponibilidad AlwaysOn (SQL Server)

Contenido relacionado (instancia del servidor)

Recomendaciones de conectividad de red

Se recomienda que utilice los mismos vínculos de red para las comunicaciones entre los miembros del clúster 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 clúster WSFC solicita una conmutación por error automática mientras la réplica secundaria está desincronizada, 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 AlwaysOn con la conectividad de cliente, consulte Conectividad de cliente AlwaysOn (SQL Server).

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

Restricciones (FCI)

Nota:

A partir de SQL Server 2014, las instancias de clúster de conmutación por error AlwaysOn admiten volúmenes compartidos de clúster (CSV) tanto en Windows Server 2008 R2 como en Windows Server 2012. Para obtener más información sobre CSV, consulte Descripción de 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 hospedar una réplica para un grupo de disponibilidad determinado : Si agrega una réplica de disponibilidad en una FCI, los nodos de clúster de WSFC que sean posibles propietarios de FCI no pueden hospedar otra réplica para el mismo grupo de disponibilidad.

    Además, todas las demás réplicas deben hospedarse en una instancia de SQL Server 2012 que resida en otro nodo de WSFC en el mismo clúster de WSFC. La única excepción es que mientras se migra a otro clúster de WSFC, un grupo de disponibilidad puede ocupar temporalmente dos clústeres.

  • 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 hospede 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 hospeda 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. Observe que 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)

Requisito previo Vínculo
Casilla Antes de usar una FCI para hospedar una réplica de disponibilidad, asegúrese de que el administrador del sistema haya instalado la revisión de Windows Server 2008 descrita en el artículo 976097 de Knowledge Base. Esta revisión permite que el complemento Microsoft Management Console (MMC) de administración de clústeres de conmutación por error admita discos compartidos de almacenamiento asimétricos que solo están disponibles en algunos de los nodos WSFC. KB 976097: Revisión para agregar compatibilidad con los almacenamientos asimétricos al complemento MMC de administración de clústeres de conmutación por error para un clúster de conmutación por error que ejecute Windows Server 2008 o Windows Server 2008 R2
Casilla 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.

Tareas relacionadas (FCI)

Tarea Tema
Instalar un clúster de conmutación por error de SQL Server Crear un nuevo clúster de conmutación por error de SQL Server (programa de instalación)
Actualización en contexto del clúster de conmutación por error existente de SQL Server Actualizar una instancia de clúster de conmutación por error de SQL Server (programa de instalación)
Mantener el clúster de conmutación por error existente de SQL Server Agregar o quitar nodos en un clúster de conmutación por error de SQL Server (programa de instalación)

Contenido relacionado (FCI)

Requisitos previos y restricciones de los grupos de disponibilidad

Restricciones (grupos de disponibilidad)

  • Las réplicas de disponibilidad se deben hospedar en nodos diferentes de un clúster de WSFC : Para un grupo de disponibilidad determinado, las réplicas de disponibilidad deben hospedarse en instancias de servidor que se ejecutan en nodos diferentes del mismo clúster de WSFC. La única excepción es que mientras se migra a otro clúster de WSFC, 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 clúster de 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 hasta tres de ellas pueden ejecutarse en el modo de confirmación sincrónica (una réplica principal con dos réplicas secundarias sincrónicas).

  • 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 exhaustivamente con 10 grupos de disponibilidad y 100 bases de datos por equipo físico. 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 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:

    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.

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
Casilla 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 hospedar una réplica de disponibilidad (más adelante en este tema)

Seguridad (grupos de disponibilidad)

  • La seguridad se hereda del clúster de conmutación por error de Windows Server (WSFC). WSFC proporciona dos niveles de seguridad del usuario con una granularidad de todas las API del clúster de WSFC:

    • Acceso de solo lectura

    • Control total

      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 de WSFC (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 de conmutación por error de WSFC. Para administrar las sesiones de seguridad de WSFC, 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 para acceder al registro, el clúster y así sucesivamente.

  • Se recomienda usar el cifrado para las conexiones entre instancias de servidor que hospedan réplicas de disponibilidad de grupos de disponibilidad AlwaysOn.

Permisos (grupos de disponibilidad)

Tarea Permisos necesarios
Crear un grupo de disponibilidad Se requiere la pertenencia al rol fijo de servidor sysadmin y el permiso de servidor CREATE AVAILABILITY GROUP, el permiso ALTER ANY AVAILABILITY GROUP o el permiso CONTROL SERVER.
Modificación de un grupo de disponibilidad Se requiere el permiso ALTER AVAILABILITY GROUP en el grupo de disponibilidad, el permiso CONTROL AVAILABILITY GROUP, el permiso ALTER ANY AVAILABILITY GROUP o el permiso CONTROL SERVER.

Además, combinar una base de datos con un grupo de disponibilidad requiere ser miembro del rol fijo de base de datos db_owner .
Quitar o eliminar un grupo de disponibilidad Se requiere el permiso ALTER AVAILABILITY GROUP en el grupo de disponibilidad, el permiso CONTROL AVAILABILITY GROUP, el permiso ALTER ANY AVAILABILITY GROUP o el permiso CONTROL SERVER. Para quitar un grupo de disponibilidad que no se encuentre hospedado en la ubicación de réplica local, se necesita el permiso CONTROL SERVER o el permiso CONTROL en ese grupo de disponibilidad.

Tareas relacionadas (grupos de disponibilidad)

Tarea Tema
Crear un grupo de disponibilidad Usar el grupo de disponibilidad (Asistente para nuevo grupo de disponibilidad)

Crear un grupo de disponibilidad (Transact-SQL)

Crear un grupo de disponibilidad (SQL Server PowerShell)

Especificar la dirección URL del extremo al agregar o modificar una réplica de disponibilidad (SQL Server)
Modificar el número de réplicas de disponibilidad Agregar una réplica secundaria a un grupo de disponibilidad (SQL Server)

Combinar una réplica secundaria con un grupo de disponibilidad (SQL Server)

Quitar una réplica secundaria de un grupo de disponibilidad (SQL Server)
Creación de una escucha de grupo de disponibilidad Configuración de un agente de escucha para un grupo de disponibilidad Always On (SQL Server)
Eliminación de un grupo de disponibilidad Eliminación de 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.

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
Casilla Ser una base de datos de usuario. Las bases de datos del sistema no pueden pertenecer a un grupo de disponibilidad.
Casilla Residir en la instancia de SQL Server donde esté creando el grupo de disponibilidad y ser accesible a la instancia del servidor.
Casilla Ser una base de datos de lectura y escritura. Las bases de datos de solo lectura no se pueden agregar a un grupo de disponibilidad. sys.databases (is_read_only = 0)
Casilla Ser una base de datos multiusuario. sys.databases (user_access = 0)
Casilla No utilizar AUTO_CLOSE. sys.databases (is_auto_close_on = 0)
Casilla Utilice el modelo de recuperación completa (también conocido como modo de recuperación completa). sys.databases (recovery_model = 1)
Casilla 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 base de datos (SQL Server)
Casilla No pertenecer a ningún grupo de disponibilidad existente sys.databases (group_database_id = NULL)
Casilla No estar configurada para la creación de 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).
Casilla 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. Enable and Configure FILESTREAM
Casilla 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. contained database authentication (opción de configuración del servidor)

Opciones de configuración de servidor (SQL Server)

Nota

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

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 inicial),

    • 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 obtener información sobre cómo responder a una operación de ad-file con errores, consulte Solución de problemas de una operación de complemento con errores (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)

Tarea Tema
Preparar una base de datos secundaria (manualmente) Preparar manualmente una base de datos secundaria para un grupo de disponibilidad (SQL Server)
Combinar una base de datos secundaria con un grupo de disponibilidad (manualmente) Combinar una base de datos secundaria con un grupo de disponibilidad (SQL Server)
Modificar el número de bases de datos de disponibilidad Agregar una base de datos a un grupo de disponibilidad (SQL Server)

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

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

Contenido relacionado

Consulte también

Información general de los grupos de disponibilidad AlwaysOn (SQL Server)
Clúster de conmutación por error y grupos de disponibilidad de AlwaysOn (SQL Server)
Conectividad de cliente AlwaysOn (SQL Server)