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.
.gif "Nota importante") 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 |
.gif "Casilla")
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 |
|---|
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. |
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. |
|
|
√ |
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. |
||
|
√ |
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. |
||
|
√ |
√ |
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. |
|
|
√ |
√ |
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). |
|
|
√ |
√ |
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. |
|
|
√ |
√ |
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. |
.gif "Icono de flecha usado con el vínculo Volver al principio")
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)
Abra la ventana de PowerShell mediante Ejecutar como administrador.
Importe el módulo FailoverClusters.
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.gif "Sugerencia")
SugerenciaCada 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
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. |
||||
|
Si desea que un grupo de disponibilidad trabaje con Kerberos:
|
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.
|
||
|
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. |
|||
|
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)
|
||
|
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.
|
El extremo de creación de reflejo de la base de datos (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. |
|||
|
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) |
.gif "Nota de seguridad")
Nota de seguridadUso 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 |
|
Crear el extremo de creación de reflejo de la base de datos (si aún no existe) |
|
Habilitar los grupos de disponibilidad de AlwaysOn |
Habilitar y deshabilitar grupos de disponibilidad de AlwaysOn (SQL Server) |
Contenido relacionado (instancia del servidor)
[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. |
|
|
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 |
[Arriba]
Contenido relacionado (FCI)
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 |
|
Modificar el número de réplicas de disponibilidad |
|
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 |
[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.
|
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. |
|
|
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) |
[!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 |
[Arriba]
Contenido relacionado
[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)