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

En este tema se describen las consideraciones para implementar Grupos de disponibilidad AlwaysOn, incluidos los requisitos previos, restricciones y recomendaciones para 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.

En este tema:

• Revisiones de .Net que admiten los grupos de disponibilidad AlwaysOn

• Requisitos del sistema de Windows y recomendaciones

• Requisitos previos y restricciones de las instancias de SQL Server

• Recomendaciones de conectividad de red

• Compatibilidad con conectividad de cliente

• 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

• Requisitos previos y restricciones de los grupos de disponibilidad

• Requisitos previos y restricciones de las bases de datos de disponibilidad

• Contenido relacionado

Revisiones de .Net que admiten los grupos de disponibilidad AlwaysOn

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

	Característica dependiente	Revisión	Vínculo
	Reporting Services	La revisión para .Net 3.5 SP1 agrega compatibilidad con las características SQL Client para AlwaysOn de intención de lectura, solo lectura y conmutación por error de multisubred. 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 AlwaysOn

Requisitos del sistema de Windows y recomendaciones

En esta sección:

• Lista de comprobación: requisitos

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

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

• Permisos

• Tareas relacionadas

• Contenido relacionado

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.
	Asegúrese de que cada equipo esté ejecutando Windows Server 2008 x86 (no WOW64) o x64 o versiones posteriores.	WOW64 (Windows de 32 bits de Windows de 64 bits) no admite Grupos de disponibilidad AlwaysOn.
	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
	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 determinado de WSFC, una o más instancias de SQL Server pueden hospedar las réplicas de disponibilidad de 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 de los grupos de disponibilidad AlwaysOn (SQL Server).
	Asegúrese de que todas las revisiones aplicables de Windows se hayan instalado en cada nodo del clúster de WSFC.	Importante Se requiere o se recomienda un número de revisiones para los nodos de un clúster de WSFC en el que se esté implementando 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 de AlwaysOn (SQL Server).

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

Dependiendo de la topología de clúster, podrían aplicarse 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
	√	√	Sí	Configurar el quorum óptimo de WSFC	En cada nodo 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 los votos de cuórum, vea Configuración de los votos y modos de quórum WSFC (SQL Server).
	√	√	Sí	Un uso más eficaz de 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 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
		√	No aplicable	Prueba del almacenamiento VPD en los discos que no están disponibles para todos los nodos 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
		√	Sí	Una conmutación por error más rápida a las 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 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
	√	√	Sí	Asimétrica almacenamiento-para instancias de clúster de conmutación por error (FCIs)	Si las instancias de clúster de conmutación por error (FCI) van a estar habilitadas para Grupos de disponibilidad AlwaysOn, instale la revisión 976097 de Windows Server 2008. Esta revisión habilita el complemento Microsoft Management Console (MMC) de administración de clúster de conmutación por error para admitir los discos asimétricos de almacenamiento compartido que están disponibles en solo algunos de los nodos de 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 la arquitectura de AlwaysOn: generar 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
	√	√	No aplicable	Protocolo de seguridad 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
	√	√	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 en torno a 30 segundos en la conmutación por error de las direcciones IP IPv6 en Windows Server 2008 R2
	√	√	Sí	Cuando no hay un 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

Arriba

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

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 obtener más información sobre la cuenta para la administración del clúster, vea Apéndice A: requisitos para un 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)

• Clústeres y alta disponibilidad (blog del equipo 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

• Agrupación en clústeres multisitio de conmutación por error de Windows 2008 R2

[Arriba]

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.

En esta sección:

• Lista de comprobación: requisitos previos

• Restricciones

• Uso de subprocesos por parte de los grupos de disponibilidad

• Permisos

• Tareas relacionadas

• Contenido relacionado

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

	Requisito previo	Vínculos
	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 las réplicas de disponibilidad de un grupo de disponibilidad dado deben residir en nodos independientes de un único 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.	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)
	En cada nodo de WSFC que hospeda una réplica de disponibilidad, asegúrese de que esté instalada la revisión que se describe en el artículo 2897554 de Knowledge Base. Esta revisión asegura que el estado de sincronización de todas las réplicas de disponibilidad se actualiza correctamente, lo que ayuda a evitar pérdidas de datos inesperadas de una conmutación por error automática.	KB 2897554: REVISIÓN: No se puede actualizar el estado de sincronización de la réplica de un grupo de disponibilidad AlwaysOn si la réplica principal está en mal estado
	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 del servicio 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.
	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)
	Cada instancia del servidor se debe estar ejecutando en SQL Server 2012 Enterprise Edition.	Características compatibles con las ediciones de SQL Server 2012
	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
	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 y deshabilitar grupos de disponibilidad de AlwaysOn (SQL Server) Importante Si elimina y vuelve a crear un clúster de WSFC, debe deshabilitar y volver a habilitar la característica de Grupos de disponibilidad AlwaysOn en cada instancia del servidor habilitada para Grupos de disponibilidad AlwaysOn en el clúster de WSFC original.
	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 extremo 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 extremo 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 La seguridad de transporte para Grupos de disponibilidad AlwaysOn es la misma 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 grupos de disponibilidad AlwaysOn (SQL Server)
	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.	Habilitar y configurar FILESTREAM
	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 del servidor

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 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 Series de aprendizaje de AlwaysON - HADRON: uso del grupo de trabajo para las bases de datos compatibles con HADRON (un blog de los 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 permiso CREATE ENDPOINT o pertenecer al rol fijo de servidor sysadmin. También requiere el permiso CONTROL ON ENDPOINT. Para obtener más información, vea GRANT (permisos de extremo de Transact-SQL).
Habilitar 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 extremo de creación de reflejo de la base de datos (Transact-SQL) Crear un extremo 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 de AlwaysOn (SQL Server)

Contenido relacionado (instancia del servidor)

• Series de aprendizaje de AlwaysON - HADRON: uso del grupo de trabajo para las bases de datos compatibles con HADRON

[Arriba]

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

[Arriba]

Compatibilidad con conectividad de cliente

Para obtener información acerca de la compatibilidad de Grupos de disponibilidad AlwaysOn con conectividad de cliente, vea Conectividad de cliente de AlwaysOn (SQL Server).

[Arriba]

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

En 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 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 hospeda una réplica de disponibilidad, deberá quitar la réplica del grupo de disponibilidad y, a continuación, agregar la réplica de nuevo al grupo de disponibilidad. 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
	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 habilita el complemento Microsoft Management Console (MMC) de administración de clúster de conmutación por error para admitir los discos asimétricos de almacenamiento compartido que están disponibles en solo algunos de los nodos de 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
	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)

[Arriba]

Contenido relacionado (FCI)

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

• Guía de la arquitectura de AlwaysOn: generar 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

En esta sección:

• Restricciones

• Requisitos

• Seguridad

• Tareas relacionadas

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

• 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 (virtual o físico) depende del hardware y de la carga de trabajo, pero no existe ningún límite forzoso. 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
	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

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

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.
Modificar 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)
Crear un agente de escucha del grupo de disponibilidad	Crear o configurar un agente de escucha del grupo de disponibilidad (SQL Server)
Quitar un grupo de disponibilidad	Quitar un grupo de disponibilidad (SQL Server)

[Arriba]

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:

• Requisitos

• Restricciones

• Recomendaciones para equipos que hospedan 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:

	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 donde esté creando el grupo de disponibilidad y ser accesible a la instancia del servidor.
	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)
	Ser una base de datos multiusuario.	sys.databases (user_access = 0)
	No utilizar AUTO_CLOSE.	sys.databases (is_auto_close_on = 0)
	Utilice el modelo de recuperación completa (también conocido como modo 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.	Crear una copia de seguridad completa de base de datos (SQL Server)
	No pertenecer a ningún grupo de disponibilidad existente	sys.databases (group_database_id = NULL)
	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).
	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.	contained database authentication (opción de configuración del servidor) Opciones de configuración del servidor

[!NOTA]

Grupos de disponibilidad AlwaysOn funciona con cualquier nivel de compatibilidad con bases de datos.

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 asistente para grupo de disponibilidad: ** La opción Completa no es compatible (en la página Seleccionar la página inicial de sincronización de datos),

  • **RESTORE WITH MOVE: ** para crear las bases de datos secundarias, se debe aplicar RESTORE WITH MOVE a los archivos de base de datos en cada instancia de SQL Server que hospeda 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 acerca de cómo responder a una operación de agregar archivo que ha producido errores, vea 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)

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)

[Arriba]

Contenido relacionado

• Guía de soluciones AlwaysOn de Microsoft SQL Server para lograr alta disponibilidad y recuperación ante desastres

• Blog del equipo de AlwaysOn de SQL Server: el blog del equipo de AlwaysOn oficial de SQL Server

• Series de aprendizaje de AlwaysON - HADRON: uso del grupo de trabajo para las bases de datos compatibles con HADRON

[Arriba]

Vea también

Conceptos

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 de AlwaysOn (SQL Server)