Realizar una conmutación por error manual forzada de un grupo de disponibilidad Always On (SQL Server)

Se aplica a:SQL Server

En este artículo se describe cómo realizar una conmutación por error forzada (con posible pérdida de datos) en un grupo de disponibilidad Always On mediante SQL  Server Management Studio, Transact-SQL o PowerShell en SQL Server. Una conmutación por error forzada es una forma de conmutación por error manual que está pensada estrictamente para la recuperación ante desastres, cuando no es posible una conmutación por error manual planeada . Si se fuerza la conmutación por error a una réplica secundaria no sincronizada, es posible que se pierdan datos. Por tanto, se recomienda encarecidamente que solo fuerce la conmutación por error si debe restaurar el servicio al grupo de disponibilidad inmediatamente y asume el riesgo de perder datos.

Después de una conmutación por error forzada, el destino de la conmutación por error al que se ha aplicado la conmutación por error del grupo de disponibilidad se convierte en la nueva réplica principal. Las bases de datos secundarias de las réplicas secundarias restantes se suspenden y se deben reanudar manualmente. Cuando la réplica principal anterior está disponible, realiza la transición al rol secundario, lo que hace que las bases de datos principales anteriores se conviertan en bases de datos secundarias y pasen al SUSPENDED estado. Antes de reanudar una base de datos secundaria determinada, quizás pueda recuperar datos perdidos de ella. Sin embargo, tenga en cuenta que el truncamiento del registro de transacciones se retrasa en una base de datos principal determinada mientras cualquiera de sus bases de datos secundarias está suspendida.

Es necesario realizar una conmutación por error forzada en las situaciones de emergencia siguientes:

• Después de forzar el cuórum en el clúster de WSFC (cuórum forzado), debe forzar la conmutación por error de todos los grupos de disponibilidad (con posible pérdida de datos). Es necesario forzar la conmutación por error porque el estado real de los valores del clúster de WSFC puede haberse perdido. Pero puede evitar la pérdida de datos si puede forzar la conmutación por error en la instancia del servidor que hospedaba la réplica que era la réplica principal antes de forzar el cuórum o en una réplica secundaria que se sincronizó antes de que se forzara el cuórum. Para obtener más información, consulte Posibles formas de evitar la pérdida de datos después de forzar el cuórum, más adelante en este artículo.

  Importante

  Si el quorum se recupera por medios naturales en lugar de forzarse, las réplicas de disponibilidad pasarán por una recuperación normal. Si la réplica principal sigue sin estar disponible después de que se recupere el cuórum, puede realizar una conmutación por error manual planeada en una réplica secundaria sincronizada.

  Para obtener información sobre cómo forzar el quórum, consulte Recuperación ante desastres del clúster WSFC mediante quórum forzado (SQL Server). Para obtener información sobre por qué es necesario forzar la conmutación por error después de forzar el cuórum, vea Conmutación por error y modos de conmutación por error (grupos de disponibilidad Always On).

• Si la réplica principal deja de estar disponible cuando el clúster de WSFC tiene un quorum en buen estado, puede forzar la conmutación por error (con posible pérdida de datos) a cualquier réplica cuyo rol esté en el estado SECONDARY o RESOLVING. Si es posible, fuerce la conmutación por error a una réplica secundaria de confirmación sincrónica que se haya sincronizado cuando se ha perdido la réplica principal.

  Sugerencia

  Cuando el clúster de WSFC tiene un cuórum en buen estado, si emite un comando para forzar la conmutación por error en una réplica secundaria sincronizada, la réplica realiza realmente una conmutación por error manual planeada.

Para obtener más información sobre los requisitos previos y las recomendaciones para forzar la conmutación por error y para ver un escenario de ejemplo que usa una conmutación por error forzada para recuperarse de un error catastrófico, vea Escenario de ejemplo: Uso de una conmutación por error forzada para recuperarse de un error catastrófico, más adelante en este artículo.

Limitaciones

• La única vez que no se puede realizar una conmutación por error forzada es cuando el clúster de conmutación por error de Windows Server (WSFC) carece de cuórum.

• La pérdida de datos es posible durante la conmutación por error forzada de un grupo de disponibilidad. Además, si la réplica principal se ejecuta cuando se inicia una conmutación por error forzada, los clientes pueden seguir estando conectados a las bases de datos principales anteriores. Por tanto, es absolutamente recomendable que solo fuerce la conmutación por error si la réplica principal ya no está en ejecución y si asume el riesgo de perder datos para restaurar el acceso a las bases de datos del grupo de disponibilidad.

• Cuando una base de datos secundaria está en estado REVERTING o INITIALIZING, forzar el failover impediría que la base de datos se iniciara como base de datos principal. Si la base de datos estaba en estado INITIALIZING , debe aplicar los registros de registro que faltan desde una copia de seguridad de la base de datos o restaurar completamente la base de datos desde cero. Si la base de datos estaba en estado REVERTING , debe restaurar completamente la base de datos a partir de copias de seguridad.

• Un comando de conmutación por error realiza la devolución en cuanto el destino de la conmutación por error acepte el comando. Sin embargo, la recuperación de la base de datos se produce de manera asincrónica cuando el grupo de disponibilidad ha terminado la conmutación por error.

• Puede que la coherencia entre las distintas bases de datos del grupo de disponibilidad no se mantenga en la conmutación por error.

  Nota

  La compatibilidad con transacciones distribuidas y entre bases de datos varía según la versión de SQL Server y del sistema operativo. Para más información, consulte Transacciones: grupos de disponibilidad y reflejo de la base de datos.

Requisitos previos

• El clúster de WSFC tiene quórum. Si el clúster no tiene cuórum, consulte Recuperación ante desastres del clúster WSFC mediante cuórum forzado (SQL Server).

• Debe poder conectarse a una instancia de servidor que hospede una réplica cuyo rol esté en el estado SECONDARY o RESOLVING.

Recomendaciones

• No fuerce la conmutación por error mientras la réplica principal sigue en ejecución.

• Si es posible, fuerce la conmutación por error solo a un destino de conmutación por error cuyas bases de datos secundarias estén en estado NOT SYNCHRONIZED, SYNCHRONIZED o SYNCHRONIZING. Para obtener información sobre las implicaciones de forzar la conmutación por error cuando una base de datos secundaria está en estado INITIALIZING o REVERTING, vea Limitaciones, anteriormente en este tema.

• Generalmente, la latencia de una base de datos secundaria determinada, relativa a la base de datos principal, debería ser similar en réplicas secundarias de confirmación asincrónica diferentes. Pero al forzar una conmutación por error, la pérdida de datos podría ser un riesgo significativo. Por tanto, dedique el tiempo necesario para determinar la latencia relativa de las copias de las bases de datos en réplicas secundarias diferentes. Para determinar qué copia de una base de datos secundaria determinada tiene la menor latencia, compare sus LSN del final del registro. Cuanto mayor es el LSN del final del registro, menor latencia.

  Sugerencia

  Para comparar los LSN del final del registro, conéctese a cada réplica secundaria en línea por turnos y consulte sys.dm_hadr_database_replica_states para ver el valor end_of_log_lsn de cada base de datos secundaria local. Después, compare los LSN del final del registro de las diferentes copias de cada base de datos. Es posible que diferentes bases de datos tengan sus LSN más altas en diferentes réplicas secundarias. En este caso, el destino de conmutación por error más apropiado depende de la importancia relativa que le dé a los datos de las distintas bases de datos. Es decir, ¿para cuál de estas bases de datos desearía más minimizar la posible pérdida de datos?

• Si los clientes pueden conectarse a la réplica principal original, una conmutación por error forzada comporta el riesgo de "comportamiento de división de cerebro". Antes de forzar la conmutación por error, se recomienda encarecidamente impedir el acceso de los clientes a la réplica principal original. De lo contrario, una vez que se fuerce la conmutación por error, las bases de datos principales originales y las bases de datos principales actuales se pueden actualizar independientemente.

Posibles formas de evitar la pérdida de datos después de forzar el cuórum

En algunas condiciones de error después de perder el cuórum, puede evitar la pérdida de datos de la siguiente manera:

• Si la réplica principal original pasa a estar en línea

  Si se pierde el quórum y al forzar el quórum de WSFC se restaura el nodo del clúster que aloja la réplica principal de un grupo de disponibilidad, puede evitar la pérdida de datos en este grupo de disponibilidad. Conéctese a la réplica principal y realice una conmutación por error forzada (FAILOVER_ALLOW_DATA_LOSS). Esto hace que la réplica principal vuelva a estar en línea. Como realiza la conmutación por error forzada en la réplica principal original, no se pierde ningún dato.

• Si una réplica secundaria sincronizada con confirmación sincrónica pasa a estar en línea

  Si se pierde el quórum y forzar el cuórum de WSFC permite recuperar un nodo del clúster que aloja una réplica secundaria sincronizada para un grupo de disponibilidad, debería poder evitar la pérdida de datos en este grupo de disponibilidad. Si el nodo restaurado estaba operativo en el momento en que se perdió el cuórum, puede determinar si se podría producir una pérdida de datos en una base de datos dada consultando la columna is_failover_ready de la vista de administración dinámica sys.dm_hadr_database_replica_cluster_states. Por ejemplo, para una instancia de servidor denominada sql108w2k8r22, ejecute la consulta siguiente:

  SELECT *
  FROM sys.dm_hadr_database_replica_cluster_states
  WHERE replica_id = (
      SELECT replica_id
      FROM sys.availability_replicas
      WHERE replica_server_name = 'sql108w2k8r22'
  );
  

  Precaución

  Si el nodo restaurado no estaba activo en el momento en que se perdió el cuórum, is_failover_ready es posible que no refleje el estado real del clúster en el momento en que la réplica principal se desconecta. Por tanto, el valor is_failover_ready solo es adecuado si el nodo del host estaba activo en el momento del error. Para más información, consulte "Por qué se requiere la conmutación por error forzada después de forzar el cuórum" en Conmutación por error y modos de conmutación por error (grupos de disponibilidad AlwaysOn).

  Si is_failover_ready = 1, la base de datos está marcada como sincronizada en el clúster y está preparada para una conmutación por error. Si is_failover_ready = 1 en todas las bases de datos de una réplica secundaria determinada, puede realizar una conmutación por error forzada (FORCE_FAILOVER_ALLOW_DATA_LOSS) sin pérdida de datos en esta réplica secundaria. La réplica secundaria sincronizada se pone en línea en el rol principal; es decir, como la nueva réplica principal, con todos los datos intactos.

  Si is_failover_ready = 0, la base de datos no está indicada como sincronizada en el clúster y no está lista para una conmutación por error manual programada. Si se fuerza la conmutación por error en la réplica secundaria del host, se perderán datos en esta base de datos.

  Nota

  Cuando se fuerza la conmutación por error en una réplica secundaria, la cantidad de datos perdidos depende de hasta dónde se retrase el destino de la conmutación por error detrás de la réplica principal. Desafortunadamente, cuando el clúster de WSFC no tiene cuórum o se ha forzado el cuórum, no puede evaluar la cantidad de pérdida potencial de datos. No obstante, tenga en cuenta que una vez que el clúster de WSFC recupere un quórum en buen estado, puede empezar a hacer un seguimiento de la posible pérdida de datos. Para más información, vea "Seguimiento de la posible pérdida de datos" en Conmutación por error y modos de conmutación por error (grupos de disponibilidad Always On).

Permisos

Requiere el permiso ALTER AVAILABILITY GROUP sobre el grupo de disponibilidad, el permiso CONTROL AVAILABILITY GROUP, el permiso ALTER ANY AVAILABILITY GROUP o el permiso CONTROL SERVER.

Uso de SQL Server Management Studio

1. En el Explorador de objetos, conéctese a una instancia de servidor que hospede una réplica cuyo rol esté en el estado SECONDARY o RESOLVING en el grupo de disponibilidad que necesita ser objeto de conmutación por error y expanda el árbol de servidores.

2. Expanda los nodos Alta disponibilidad de AlwaysOn y Grupos de disponibilidad.

3. Haga clic con el botón derecho en el grupo de disponibilidad que va a ser objeto de conmutación por error y seleccione el comando Conmutación por error.

4. Esto inicia el Asistente para conmutación por error del grupo de disponibilidad. Para más información, consulte Usar el Asistente para grupo de disponibilidad de conmutación por error (SQL Server Management Studio).

5. Después de forzar la conmutación por error de un grupo de disponibilidad, complete los pasos necesarios de seguimiento. Para más información, consulte Seguimiento: tareas esenciales después de una conmutación por error forzada, más adelante en este artículo.

Uso de Transact-SQL

1. Conéctese a una instancia de servidor que hospede una réplica cuyo rol esté en el estado SECONDARY o RESOLVING en el grupo de disponibilidad que necesita ser objeto de conmutación por error.

2. Use la ALTER AVAILABILITY GROUP instrucción , como se indica a continuación, donde group_name es el nombre del grupo de disponibilidad:

   ALTER AVAILABILITY GROUP <group_name> FORCE_FAILOVER_ALLOW_DATA_LOSS.

   En el ejemplo siguiente se fuerza la conmutación por error del grupo de disponibilidad AccountsAG a la réplica secundaria local.

   ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

3. Después de forzar la conmutación por error de un grupo de disponibilidad, complete los pasos necesarios de seguimiento. Para obtener más información, consulte Tareas esenciales después de una conmutación por error forzada, más adelante en este artículo.

Uso de PowerShell

1. Cambie el directorio (cd) a una instancia de servidor que hospede una réplica cuyo rol se encuentre en el estado SECONDARY o RESOLVING en el grupo de disponibilidad para el que se debe realizar la conmutación por error.

2. Use el cmdlet Switch-SqlAvailabilityGroup con el parámetro AllowDataLoss de una de las formas siguientes:

   • -AllowDataLoss

     De forma predeterminada, el parámetro -AllowDataLoss hace que Switch-SqlAvailabilityGroup le solicite recordar que forzar la conmutación por error podría provocar la pérdida de transacciones no confirmadas y solicitar confirmación. Para continuar, escriba Y; para cancelar la operación, escriba N.

     En el ejemplo siguiente se realiza una conmutación por error forzada (con posible pérdida de datos) del grupo de disponibilidad MyAg a la réplica secundaria en la instancia del servidor denominada SecondaryServer\InstanceName. Se le pedirá que confirme esta operación.

     Switch-SqlAvailabilityGroup `
        -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
        -AllowDataLoss
     

   • -AllowDataLoss-Force

     Para iniciar una conmutación por error forzada sin confirmación, especifique tanto los parámetros -AllowDataLoss como -Force. Esto es útil si desea incluir el comando en un script y ejecutarlo sin la intervención del usuario. Sin embargo, use la opción -Force con precaución, porque una conmutación por error forzada podría resultar en la pérdida de datos de las bases de datos que forman parte del grupo de disponibilidad.

     En el ejemplo siguiente se realiza una conmutación por error forzada (con posible pérdida de datos) del grupo de disponibilidad MyAg a la instancia del servidor denominada SecondaryServer\InstanceName. La -Force opción suprime la confirmación de esta operación.

     Switch-SqlAvailabilityGroup `
        -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
        -AllowDataLoss -Force
     

   Nota

   Para ver la sintaxis de un cmdlet, use el Get-Help cmdlet en el entorno de SQL Server PowerShell. Para más información, consulte Get Help SQL Server PowerShell.

3. Después de forzar la conmutación por error de un grupo de disponibilidad, complete los pasos necesarios de seguimiento. Para más información, consulte Seguimiento: tareas esenciales después de una conmutación por error forzada, más adelante en este artículo.

Configuración y uso del proveedor de SQL Server PowerShell

• Proveedor de PowerShell de SQL Server

Seguimiento: tareas esenciales después de una conmutación por error forzada

1. Después de una conmutación por error forzada, la réplica secundaria objeto de la conmutación por error se convierte en la nueva réplica principal. Sin embargo, para que la réplica de disponibilidad esté accesible a los clientes, puede que necesite volver a configurar el quórum de WSFC o ajustar la configuración de modo de disponibilidad del grupo de disponibilidad del siguiente modo:

   • Si ha conmutado por error fuera del conjunto de conmutación automática por error: ajuste los votos de cuórum de los nodos WSFC para reflejar la configuración del nuevo grupo de disponibilidad. Si el nodo WSFC que hospeda la réplica secundaria de destino no tiene un voto de cuórum de WSFC, es posible que tenga que forzar el cuórum de WSFC.

     Un conjunto de conmutación automática por error solo existe si se configuran dos réplicas de disponibilidad (incluida la réplica principal anterior) para el modo de confirmación sincrónica con conmutación por error automática.

     Para ajustar los votos de quórum

     • Ver la configuración de ponderación de nodo del cuórum del clúster
     • Configurar la configuración NodeWeight del cuórum del clúster
     • Forzar el inicio de un clúster WSFC sin un quórum

   • Si ha realizado una conmutación por error fuera del conjunto de confirmación sincrónica de conmutación por error: se recomienda que considere ajustar el modo de disponibilidad y el modo de conmutación por error en la nueva réplica principal y en las réplicas secundarias restantes para reflejar la configuración deseada de confirmación sincrónica y conmutación por error automática.

     Nota

     Un conjunto de conmutación por error de confirmación sincrónica existe solo si la réplica principal actual está configurada para el modo de confirmación sincrónica.

     Para cambiar el modo de disponibilidad y el modo de conmutación por error

     • Cambio del modo de disponibilidad de una réplica dentro de un grupo de disponibilidad AlwaysOn
     • Cambio del modo de conmutación por error para una réplica dentro de un grupo de disponibilidad Always On

2. Después de una conmutación por error forzada, se suspenden todas las bases de datos secundarias. Esto incluye las bases de datos principales antiguas, después de que la réplica principal anterior vuelva a estar en línea y detecte que ahora es una réplica secundaria. Debe reanudar manualmente cada base de datos suspendida de forma individual en cada réplica secundaria.

   Cuando se reanuda una base de datos secundaria, inicia la sincronización de datos con la base de datos principal correspondiente. La base de datos secundaria solo revierte algunos registros que nunca se han confirmado en la nueva base de datos principal. Por tanto, si le preocupa la posible pérdida de datos en las bases de datos principales posteriores a la conmutación por error, debe intentar crear una instantánea de base de datos en las bases de datos suspendidas en una de las bases de datos secundarias de confirmación sincrónica.

   Importante

   El truncamiento del registro de transacciones se retrasa en una base de datos principal mientras cualquiera de sus bases de datos secundarias está suspendida. Además, el estado de sincronización de una réplica secundaria de confirmación sincrónica no puede cambiar a HEALTHY mientras alguna base de datos local permanezca suspendida.

   Para crear una instantánea de base de datos

   • Creación de una instantánea de base de datos (Transact-SQL)

   Para reanudar una base de datos de disponibilidad

   • Reanudar una base de datos de disponibilidad (SQL Server)

   Precaución

   Después de reanudar todas las bases de datos secundarias, antes de intentar volver a realizar la conmutación por error del grupo, espere a que cada base de datos secundaria del destino de conmutación por error siguiente entre en el estado SYNCHRONIZING. Si una base de datos no está todavía en estado SYNCHRONIZING, se impedirá que entre en línea como base de datos principal, y el restablecimiento de la sincronización de datos para la base de datos podría requerir que se restaurasen los registros de transacciones, se restaurase una copia de seguridad completa de la base de datos o se realizase de nuevo la conmutación por error a la réplica principal anterior.

3. Si una réplica de disponibilidad con error no se devolviera a la réplica de disponibilidad o se devolviera demasiado tarde para poder retrasar el truncamiento del registro de transacciones en la nueva base de datos principal, considere la posibilidad de quitar la réplica con error del grupo de disponibilidad para que los archivos de registro no se queden sin espacio en disco.

   Para eliminar una réplica secundaria

   • Quitar una réplica secundaria de un grupo de disponibilidad (SQL Server)

4. Si una conmutación por error forzada va seguida de una o varias conmutaciones por error forzadas adicionales, realice una copia de seguridad del registro después de cada conmutación por error forzada adicional de la secuencia. Para más información sobre la razón de ello, vea "Riesgos de forzar la conmutación por error" en la sección "Conmutación por error forzada (con posible pérdida de datos)" de Conmutación por error y modos de conmutación por error (grupos de disponibilidad Always On).

   Para realizar una copia de seguridad de registros

   • Copia de seguridad de un registro de transacciones

Escenario de ejemplo: uso de una conmutación por error forzada para recuperarse de un error catastrófico

En el ejemplo siguiente se realiza manualmente una conmutación por error en el grupo de disponibilidad a la réplica secundaria local que está sincronizada actualmente con la réplica principal. La idoneidad de forzar una conmutación por error depende de: (1) si espera que la réplica principal esté sin conexión más tiempo de lo que el contrato de nivel de servicio (SLA) tolera y (2) si está dispuesto a exponerse a la posible pérdida de datos para conseguir que las bases de datos principales estén disponibles de inmediato. Si decide que un grupo de disponibilidad necesita una conmutación por error forzada, la conmutación por error forzada real es uno de los pasos de un proceso de varios.

Para ilustrar los pasos necesarios para usar una interrupción forzada para recuperarse de una falla catastrófica, en este artículo se presenta un posible escenario de recuperación ante desastres. El escenario de ejemplo considera un grupo de disponibilidad cuya topología original consta de un centro de datos principal que hospeda tres réplicas de disponibilidad de confirmación sincrónica, incluida la réplica principal, y un centro de datos remoto que hospeda dos réplicas secundarias de confirmación asincrónica. En la ilustración siguiente se muestra la topología original de este grupo de disponibilidad de ejemplo. El grupo de disponibilidad está hospedado por un clúster WSFC de múltiples subredes con tres nodos en el centro de datos principal (Nodo 01, Nodo 02y Nodo 03) y dos nodos en un centro de datos remoto (Nodo 04 y Nodo 05).

El centro de datos principal se apaga inesperadamente. Sus tres réplicas de disponibilidad se ponen sin conexión y sus bases de datos dejan de estar disponibles. En la ilustración siguiente se muestra el efecto de este error en la topología del grupo de disponibilidad.

El administrador de base de datos (DBA) determina que la mejor respuesta posible es forzar la conmutación por error del grupo de disponibilidad a una de las réplicas secundarias de confirmación asincrónica. En este ejemplo se muestran los pasos típicos implicados cuando se fuerza la conmutación por error del grupo de disponibilidad a una réplica remota y, a la larga, devuelve el grupo de disponibilidad a su topología original.

La respuesta al error presentada aquí consta de las dos fases siguientes:

• Respuesta al error catastrófico del centro de datos principal
• Devolver el grupo de disponibilidad a su topología original

Respuesta al error catastrófico del centro de datos principal

En la ilustración siguiente se muestra la serie de acciones realizadas en el centro de datos remoto en respuesta a un error catastrófico en el centro de datos principal.

Los pasos de esta ilustración indican los pasos siguientes:

Devolver el grupo de disponibilidad a su topología original

En la ilustración siguiente se muestra la serie de acciones que devuelven el grupo de disponibilidad a su topología original una vez que el centro de datos principal se pone en línea y los nodos WSFC restablecen la comunicación con el clúster WSFC.

Los pasos de esta ilustración indican los pasos siguientes:

Tareas relacionadas

Ajustar votos de quórum

• Ver la configuración de ponderación de nodo del cuórum del clúster
• Configurar la configuración NodeWeight del cuórum del clúster
• Forzar el inicio de un clúster WSFC sin un quórum

Conmutación por error manual planeada

• Realización de una conmutación por error manual planeada de un grupo de disponibilidad Always On (SQL Server)
• Usar el Asistente para grupo de disponibilidad de conmutación por error (SQL Server Management Studio)

Troubleshoot

• Solucionar problemas de configuración de grupos de disponibilidad AlwaysOn (SQL Server)
• Solucionar problemas relativos a una operación de agregar archivos con error (grupos de disponibilidad AlwaysOn)

Contenido relacionado

• Blogs del equipo de AlwaysOn de SQL Server: blog oficial del equipo de AlwaysOn de SQL Server
• Blogs de los ingenieros de CSS de SQL Server
• Guía de soluciones AlwaysOn de Microsoft SQL Server para lograr alta disponibilidad y recuperación ante desastres
• ¿Qué es un grupo de disponibilidad Always On?
• Diferencias entre los modos de disponibilidad de un grupo de disponibilidad AlwaysOn
• Conmutación por error y modos de conmutación por error (grupos de disponibilidad AlwaysOn)
• Tipos de conexiones de cliente a réplicas dentro de un grupo de disponibilidad AlwaysOn
• Herramientas para supervisar grupos de disponibilidad Always On
• Clústeres de conmutación por error de Windows Server con SQL Server