Configuración de un grupo de conmutación por error para Azure SQL Database

Se aplica a:Azure SQL Database

• Azure SQL Database
• Instancia administrada de Azure SQL

Este artículo te enseña a configurar un grupo de conmutación por error para bases de datos agrupadas en Azure SQL Database mediante Azure Portal, Azure PowerShell y la CLI de Azure.

Para los scripts de un extremo a otro, consulta cómo agregar una base de datos única a un grupo de conmutación por error con Azure PowerShell o la CLI de Azure.

Requisitos previos

Tenga en cuenta los siguientes requisitos previos para crear el grupo de conmutación por error para una base de datos única:

• La configuración del firewall y de inicio de sesión del servidor para el servidor secundario debe coincidir con la del servidor principal.

Creación de un grupo de conmutación por error

Portal

Cree el grupo de conmutación por error y agregue la base de datos única mediante Azure Portal.

1. Seleccione Azure SQL en el menú izquierdo de Azure Portal. Si Azure SQL no está en la lista, seleccione Todos los servicios y escriba Azure SQL en el cuadro de búsqueda. (Opcional) Seleccione la estrella junto a Azure SQL para marcarlo como favorito y agréguelo como un elemento en el panel de navegación izquierdo.

2. Seleccione la base de datos que quiere agregar al grupo de conmutación por error.

3. Seleccione el nombre del servidor en Nombre del servidor para abrir la configuración del servidor.

   

4. Seleccione Grupos de conmutación por error en el panel Configuración y, después, seleccione Agregar grupo para crear un grupo de conmutación por error.

   

5. En la página Grupo de conmutación por error, escriba o seleccione los valores necesarios y, después, seleccione Crear. Cree un nuevo servidor secundario o seleccione un servidor secundario existente. El servidor secundario del grupo de conmutación por error debe estar en una región diferente que el servidor principal.

   • Bases de datos en el grupo Elija la base de datos que quiere agregar a su grupo de conmutación por error. Al agregar la base de datos al grupo de conmutación por error, se iniciará automáticamente el proceso de replicación geográfica.

   

PowerShell

Cree el grupo de conmutación por error y agregue la base de datos mediante PowerShell.

Usa New-AzSqlDatabaseFailoverGroup para crear el grupo de conmutación por error:

# Create a failover group between the servers
$failovergroup = Write-host "Creating a failover group between the primary and secondary server..."
New-AzSqlDatabaseFailoverGroup `
   –ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -PartnerServerName $drServerName  `
   –FailoverGroupName $failoverGroupName `
   –FailoverPolicy Manual
$failovergroup

Usa los comandos Get-AzSqlDatabase y Add-AzSqlDatabaseToFailoverGroup para agregar la base de datos al grupo de conmutación por error:

# Add the database to the failover group
Write-host "Adding the database to the failover group..." 
Get-AzSqlDatabase `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -DatabaseName $databaseName | `
Add-AzSqlDatabaseToFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -FailoverGroupName $failoverGroupName
Write-host "Successfully added the database to the failover group..."

Nota:

Es posible implementar el grupo de conmutación por error entre suscripciones mediante el -PartnerSubscriptionId parámetro de Azure PowerShell a partir de Az.SQL 3.11.0. Para más información, consulte el siguiente ejemplo.

CLI de Azure

En este paso, se crea el grupo de conmutación por error y se le agrega la base de datos mediante la CLI de Azure.

Usa az sql failover-group create para crear un grupo de conmutación por error y agregar la base de datos al grupo de conmutación por error:

echo "Creating $failoverGroup between $server and $secondaryServer..."
az sql failover-group create --name $failoverGroup --partner-server $secondaryServer --resource-group $resourceGroup --server $server --failover-policy Automatic --grace-period 2 --add-db $database

Prueba de conmutación por error planeada

Prueba la conmutación por error de tu grupo de conmutación por error sin pérdida de datos mediante Azure Portal o PowerShell.

Portal

Pruebe la conmutación por error de su grupo de conmutación por error mediante Azure Portal.

1. Seleccione Azure SQL en el menú izquierdo de Azure Portal. Si Azure SQL no está en la lista, seleccione Todos los servicios y, después, escriba "Azure SQL" en el cuadro de búsqueda. (Opcional) Seleccione la estrella junto a Azure SQL para marcarlo como favorito y agréguelo como un elemento en el panel de navegación izquierdo.

2. Seleccione la base de datos que quiere agregar al grupo de conmutación por error.

   

3. Seleccione Grupos de conmutación por error en el panel Configuración y, a continuación, elija el grupo de conmutación por error que acaba de crear.

   

4. Revise cuál es el servidor principal y cuál el secundario.

5. Seleccione Conmutación por error en el panel de tareas para conmutar por error el grupo de conmutación por error que contiene la base de datos.

6. Seleccione Sí en la advertencia que le notifica que las sesiones de TDS se desconectarán.

   

7. Revise qué servidor es ahora el principal y cuál el secundario. Si la conmutación por error se realiza correctamente, los dos servidores deben tener los roles intercambiados.

8. Vuelva a seleccionar Conmutación por error para devolver los servidores a sus roles originales.

PowerShell

Pruebe la conmutación por error de su grupo de conmutación por error mediante PowerShell.

Comprobación de los roles de cada servidor

Usa el comando Get-AzSqlDatabaseFailoverGroup para confirmar los roles de cada servidor.

# Check role of secondary replica
Write-host "Confirming the secondary replica is secondary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

Conmutación por error al servidor secundario

Usa Switch-AzSqlDatabaseFailoverGroup para conmutar por error al servidor secundario.

# Failover to secondary server
Write-host "Failing over failover group to the secondary..." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName `
   -FailoverGroupName $failoverGroupName
Write-host "Failed failover group successfully to" $drServerName 

Write-host "Confirming the secondary server is now primary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

Reversión del grupo de conmutación por error al servidor principal

Usa el comando Switch-AzSqlDatabaseFailoverGroup para conmutar por recuperación al servidor principal.

# Revert failover to primary server
Write-host "Failing over failover group to the primary...." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -FailoverGroupName $failoverGroupName
Write-host "Failed failover group successfully back to" $serverName

CLI de Azure

Pruebe la conmutación por error mediante la CLI de Azure.

Comprobación de los roles de cada servidor

Use el comando az sql failover-group show para confirmar los roles de cada servidor.

echo "Confirming the role of each server in the failover group..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Conmutación por error al servidor secundario

Use el comando az sql failover-group set-primary para conmutar por error al servidor secundario. Use el comando az sql failover-group show para comprobar una conmutación por error correcta.

echo "Failing over to $secondaryServer..."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $secondaryServer 

echo "Confirming role of $secondaryServer is now primary..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Reversión del grupo de conmutación por error al servidor principal

Use el comando az sql failover-group set-primary para conmutar por recuperación al servidor principal.

echo "Failing back to $server...."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $server

Importante

Si tiene que eliminar la base de datos secundaria, quítela del grupo de conmutación por error antes de eliminarla. Eliminar una base de datos secundaria antes de quitarla del grupo de conmutación por error puede provocar un comportamiento impredecible.

Para los scripts de un extremo a otro, consulta cómo agregar un grupo elástico a un grupo de conmutación por error con Azure PowerShell o la CLI de Azure.

Requisitos previos

Tenga en cuenta los siguientes requisitos previos para crear el grupo de conmutación por error para una base de datos agrupada:

• La configuración del firewall y de inicio de sesión del servidor para el servidor secundario debe coincidir con la del servidor principal.

Creación de un grupo de conmutación por error

Cree el grupo de conmutación por error para su grupo elástico mediante Azure Portal o PowerShell.

Portal

Cree el grupo de conmutación por error y agregue el grupo elástico mediante Azure Portal.

1. Seleccione Azure SQL en el menú izquierdo de Azure Portal. Si Azure SQL no está en la lista, seleccione Todos los servicios y, después, escriba "Azure SQL" en el cuadro de búsqueda. (Opcional) Seleccione la estrella junto a Azure SQL para marcarlo como favorito y agréguelo como un elemento en el panel de navegación izquierdo.

2. Seleccione el grupo elástico que desea agregar al grupo de conmutación por error.

3. En el panel Información general, seleccione el nombre del servidor en Nombre del servidor para abrir la configuración del servidor.

   

4. Seleccione Grupos de conmutación por error en el panel Configuración y, después, seleccione Agregar grupo para crear un nuevo grupo de conmutación por error.

   

5. En la página Grupo de conmutación por error, escriba o seleccione los valores necesarios y, después, seleccione Crear. Cree un nuevo servidor secundario o seleccione un servidor secundario existente.

6. Selecciona Bases de datos en el grupo y, a continuación, elige el grupo elástico que deseas agregar al grupo de conmutación por error. Si aún no existe un grupo elástico en el servidor secundario, aparecerá una advertencia en la que se te solicita que crees un grupo elástico en el servidor secundario. Seleccione la advertencia y, a continuación, elija Aceptar para crear el grupo elástico en el servidor secundario.

   

7. Elige Seleccionar para aplicar la configuración del grupo elástico al grupo de conmutación por error y, después, selecciona Crear para crear el grupo de conmutación por error. Al agregar el grupo elástico al grupo de conmutación por error, se iniciará automáticamente el proceso de replicación geográfica.

PowerShell

Cree el grupo de conmutación por error y agregue el grupo elástico mediante PowerShell.

Usa New-AzSqlDatabaseFailoverGroup para crear el grupo de conmutación por error:

# Create a failover group between the servers
Write-host "Creating failover group..." 
New-AzSqlDatabaseFailoverGroup `
  –ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -PartnerServerName $drServerName  `
   –FailoverGroupName $failoverGroupName `
   –FailoverPolicy Manual
Write-host "Failover group created successfully."

Usa los comandos Get-AzSqlDatabaseFailoverGroup y Get-AzSqlElasticPoolDatabase para agregar la base de datos al grupo de conmutación por error:

# Add elastic pool to the failover group
Write-host "Enumerating databases in elastic pool...." 
$FailoverGroup = Get-AzSqlDatabaseFailoverGroup `
                 -ResourceGroupName $resourceGroupName `
                 -ServerName $serverName `
                 -FailoverGroupName $failoverGroupName
$databases = Get-AzSqlElasticPoolDatabase `
               -ResourceGroupName $resourceGroupName `
               -ServerName $serverName `
               -ElasticPoolName $poolName
Write-host "Adding databases to failover group..." 
$failoverGroup = $failoverGroup | Add-AzSqlDatabaseToFailoverGroup `
                                  -Database $databases 
$failoverGroup

CLI de Azure

En este paso, se crea el grupo de conmutación por error y se le agrega la base de datos mediante la CLI de Azure.

Use el comando az sql failover-group create para crear un grupo de conmutación por error.

echo "Creating $failoverGroup between $server and $secondaryServer..."
az sql failover-group create --name $failoverGroup --partner-server $secondaryServer --resource-group $resourceGroup --server $server --failover-policy Automatic --grace-period 2
databaseId=$(az sql elastic-pool list-dbs --name $pool --resource-group $resourceGroup --server $server --query [0].name -o json | tr -d '"')

Use el comando az sql failover-group update para agregar una base de datos al grupo de conmutación por error.

echo "Adding $database to $failoverGroup..."
az sql failover-group update --name $failoverGroup --add-db $databaseId --resource-group $resourceGroup --server $server

Prueba de conmutación por error planeada

Prueba la conmutación por error sin pérdida de datos de tu grupo elástico mediante Azure Portal o PowerShell.

Portal

Se producirá un error en el grupo de conmutación por error en el servidor secundario y, a continuación, se realizará la conmutación por recuperación mediante Azure Portal.

1. Seleccione Azure SQL en el menú izquierdo de Azure Portal. Si Azure SQL no está en la lista, seleccione Todos los servicios y, después, escriba "Azure SQL" en el cuadro de búsqueda. (Opcional) Seleccione la estrella junto a Azure SQL para marcarlo como favorito y agréguelo como un elemento en el panel de navegación izquierdo.

2. Selecciona el grupo elástico que deseas conmutar por error.

3. En el panel Información general, seleccione el nombre del servidor en Nombre del servidor para abrir la configuración del servidor.

   

4. Selecciona Grupos de conmutación por error en el panel Configuración y, a continuación, elige el grupo de conmutación por error que creaste anteriormente.

   

5. Revise cuál es el servidor principal y cuál es el secundario.

6. Seleccione Conmutación por error en el panel de tareas para conmutar por error el grupo de conmutación por error que contiene el grupo elástico.

7. Seleccione Sí en la advertencia que le notifica que las sesiones de TDS se desconectarán.

   

8. Revise cuál es el servidor principal y cuál es el secundario. Si la conmutación por error se realiza correctamente, los dos servidores deben tener los roles intercambiados.

9. Seleccionar de nuevo Conmutación por error para que el grupo de conmutación por error vuelva a la configuración original.

PowerShell

Prueba la conmutación por error del grupo de conmutación por error mediante PowerShell con los siguientes comandos de PowerShell:

Comprobación de los roles de cada servidor

Usa el comando Get-AzSqlDatabaseFailoverGroup para confirmar los roles de cada servidor.

# Check role of secondary replica
Write-host "Confirming the secondary server is secondary...." 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

Conmutación por error al servidor secundario

Usa Switch-AzSqlDatabaseFailoverGroup para conmutar por error al servidor secundario.

# Failover to secondary server
Write-host "Failing over failover group to the secondary..." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName `
   -FailoverGroupName $failoverGroupName
Write-host "Failover group failed over to" $drServerName 

# Check role of secondary replica
Write-host "Confirming the secondary server is now primary" 
(Get-AzSqlDatabaseFailoverGroup `
   -FailoverGroupName $failoverGroupName `
   -ResourceGroupName $resourceGroupName `
   -ServerName $drServerName).ReplicationRole

Reversión del grupo de conmutación por error al servidor principal

Usa el comando Switch-AzSqlDatabaseFailoverGroup para conmutar por recuperación al servidor principal.

# Revert failover to primary server
Write-host "Failing over failover group to the primary...." 
Switch-AzSqlDatabaseFailoverGroup `
   -ResourceGroupName $resourceGroupName `
   -ServerName $serverName `
   -FailoverGroupName $failoverGroupName
Write-host "Failover group failed over to" $serverName

CLI de Azure

Pruebe la conmutación por error mediante la CLI de Azure.

Comprobación de los roles de cada servidor

Use el comando az sql failover-group show para confirmar los roles de cada servidor en el grupo de conmutación por error.

echo "Confirming the role of each server in the failover group..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Conmutación por error al servidor secundario

Use el comando az sql failover-group set-primary para realizar la conmutación por error al servidor secundario. Use el comando az sql failover-group show para comprobar que una conmutación por error se ha realizado correctamente.

echo "Failing over to $secondaryServer..."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $secondaryServer 

echo "Confirming role of $secondaryServer is now primary..." # note ReplicationRole property
az sql failover-group show --name $failoverGroup --resource-group $resourceGroup --server $server

Reversión del grupo de conmutación por error al servidor principal

Use el comando az sql failover-group set-primary para conmutar por recuperación al servidor principal.

echo "Failing back to $server...."
az sql failover-group set-primary --name $failoverGroup --resource-group $resourceGroup --server $server

Importante

Si tiene que eliminar la base de datos secundaria, quítela del grupo de conmutación por error antes de eliminarla. Eliminar una base de datos secundaria antes de quitarla del grupo de conmutación por error puede provocar un comportamiento impredecible.

Uso de Private Link

El uso de un vínculo privado permite asociar un servidor lógico a una dirección IP privada específica dentro de la red virtual y la subred.

Para usar un vínculo privado con el grupo de conmutación por error, haga lo siguiente:

1. Asegúrese de que el servidor principal y el secundarios se encuentran en una región emparejada.
2. Crea la red virtual y la subred en cada región para hospedar puntos de conexión privados para el servidor principal y el secundario, de modo que tengan espacios de direcciones IP que no se superpongan. Por ejemplo, el intervalo de direcciones de la red virtual principal de 10.0.0.0/16 y el intervalo de direcciones de la red virtual secundaria de 10.0.0.1/16 se superpone. Para obtener más información sobre los intervalos de direcciones de la red virtual, consulte el blog Diseño de redes virtuales de Azure.
3. Cree un punto de conexión privado y una zona DNS privada de Azure para el servidor principal.
4. Cree también un punto de conexión privado para el servidor secundario, pero esta vez vuelva a usar la misma zona DNS privada que se creó para el servidor principal.
5. Una vez establecido el vínculo privado, puede crear el grupo de conmutación por error siguiendo los pasos descritos anteriormente en este artículo.

Búsqueda del punto de conexión del cliente de escucha

Una vez que se configure su grupo de conmutación por error, actualice la cadena de conexión para su aplicación al punto de conexión del cliente de escucha. Esto mantiene tu aplicación conectada al cliente de escucha del grupo de conmutación por error, en lugar de la base de datos principal o el grupo elástico. De esa forma, no tendrá que actualizar manualmente la cadena de conexión cada vez que su entidad de base de datos conmute por error y el tráfico se enrute a la entidad que actualmente sea la principal.

El punto de conexión del cliente de escucha tiene el formato fog-name.database.windows.net y es visible en Azure Portal, al ver el grupo de conmutación por error:

Escalado de una base de datos en un grupo de conmutación por error

Puede escalar verticalmente o reducir verticalmente la base de datos principal a un tamaño de proceso diferente (en el mismo nivel de servicio) sin desconectar las secundarias. Cuando se escala verticalmente, se recomienda escalar verticalmente primero la secundaria geográfica y, después, escalar verticalmente la principal. Al reducir verticalmente, invierta el orden: primero escale verticalmente la principal y, a continuación, escale verticalmente la secundaria. Cuando se escala la base de datos a un nivel de servicio diferente, se aplica esta recomendación.

Esta secuencia se recomienda específicamente para evitar que la base de datos secundaria de una SKU inferior se sobrecargue y deba propagarse durante un proceso de actualización o degradación. También puede evitar este problema si hace que la base de datos principal sea de solo lectura, a costa de afectar a todas las cargas de trabajo de lectura y escritura en la réplica principal.

Nota:

Si creó una base de datos secundaria geográfica como parte de la configuración del grupo de conmutación por error, no se recomienda reducir verticalmente la base de datos secundaria geográfica. De este modo, se garantiza que la capa de datos tiene la capacidad suficiente para procesar la carga de trabajo habitual después de una conmutación por error. Es posible que no puedas escalar una SKU geográfica secundaria después de una conmutación por error manual no planeada cuando la SKU geográfica principal anterior no está disponible debido a una interrupción. Es una limitación conocida.

Evitación la pérdida de datos críticos

Debido a la elevada latencia de las redes de área extensa, la replicación geográfica usa un mecanismo de replicación asincrónica. La replicación asincrónica hace que la posibilidad de perder datos sea inevitable si se produce un error en la principal. Para proteger las transacciones críticas contra la pérdida de datos, un desarrollador de aplicaciones puede llamar al procedimiento almacenado sp_wait_for_database_copy_sync inmediatamente después de confirmar la transacción. La llamada a sp_wait_for_database_copy_sync bloquea el subproceso de llamada hasta que se transmite y protege la última transacción confirmada en el registro de transacciones de la base de datos secundaria. Pero no espera a que las transacciones transmitidas se reproduzcan (vuelvan a hacerse) en la secundaria. sp_wait_for_database_copy_sync está limitado a un vínculo de replicación geográfica específico. Cualquier usuario con derechos de conexión para la base de datos principal puede llamar a este procedimiento.

Nota:

sp_wait_for_database_copy_sync evita la pérdida de datos después de la conmutación por error geográfica para transacciones específicas, pero no garantiza la sincronización completa para el acceso de lectura. El retraso provocado por una llamada al procedimiento sp_wait_for_database_copy_sync puede ser considerable y depende del tamaño del registro de transacciones que todavía no se transmiten en la principal en el momento de la llamada.

Cambio de la región secundaria

Para ilustrar la secuencia de cambios, supondremos que el servidor A es el principal, el servidor B es el servidor secundario existente y el servidor C es la nueva instancia secundaria de la tercera región. Para realizar la transición, siga estos pasos:

1. Cree instancias secundarias adicionales de cada base de datos del servidor A en el servidor C mediante la replicación geográfica activa. Cada base de datos del servidor A tendrá dos secundarios, uno en el servidor B y otro en el servidor C. Esto garantiza que las bases de datos principales permanezcan protegidas durante la transición.
2. Elimine el grupo de conmutación por error. En este momento, se produce un error en los intentos de inicio de sesión que usan los puntos de conexión del grupo de conmutación por error.
3. Vuelva a crear el grupo de conmutación por error con el mismo nombre entre los servidores A y C.
4. Agregue todas las bases de datos principales del servidor A al nuevo grupo de conmutación por error. En este momento, se dejan de producir errores en los intentos de inicio de sesión.
5. Elimine el servidor B. Todas las bases de datos de dicho servidor se eliminarán automáticamente.

Cambio de la región primaria

Para ilustrar la secuencia de cambios, supondremos que el servidor A es el servidor principal, el servidor B es el servidor secundario existente y el servidor C es la nueva instancia principal de la tercera región. Para realizar la transición, siga estos pasos:

1. Haz una conmutación por error geográfica planeada para cambiar el servidor principal al B. El servidor A se convierte en el nuevo servidor secundario. La conmutación por error puede producir varios minutos de tiempo de inactividad. El tiempo real depende del tamaño del grupo de conmutación por error.
2. Cree instancias secundarias adicionales de cada base de datos del servidor B en el servidor C mediante la replicación geográfica activa. Cada base de datos del servidor B tendrá dos secundarios, uno en el servidor A y otro en el servidor C. Esto garantiza que las bases de datos principales permanezcan protegidas durante la transición.
3. Elimine el grupo de conmutación por error. En este momento, se produce un error en los intentos de inicio de sesión que usan los puntos de conexión del grupo de conmutación por error.
4. Vuelva a crear el grupo de conmutación por error con el mismo nombre entre los servidores B y C.
5. Agregue todas las bases de datos principales del servidor B al nuevo grupo de conmutación por error. En este momento, se dejan de producir errores en los intentos de inicio de sesión.
6. Haz una conmutación por error geográfica planeada del grupo de conmutación por error para cambiar los servidores B y C. Ahora, el servidor C es el principal y el B es el secundario. Todas las bases de datos secundarias del servidor A se vincularán automáticamente a las instancias principales de C. Como en el paso 1, la conmutación por error puede producir varios minutos de tiempo de inactividad.
7. Elimine el servidor A. Todas las bases de datos de dicho servidor se eliminarán automáticamente.

Importante

Cuando se elimina el grupo de conmutación por error, también se eliminan los registros de DNS de los puntos de conexión del agente de escucha. En ese momento, existe una probabilidad distinta de cero de que otra persona cree un grupo de conmutación por error o un alias DNS de servidor con el mismo nombre. Dado que los nombres de grupo de conmutación por error y los alias DNS deben ser únicos globalmente, esto impedirá que vuelva a usar el mismo nombre. Para minimizar este riesgo, no utilice nombres de grupo de conmutación por error genéricos.

Grupos de conmutación por error y la seguridad de red

En el caso de algunas aplicaciones, las reglas de seguridad requieren que el acceso de red a la capa de datos esté restringido a un componente o componentes específicos, como una máquina virtual, un servicio web, etc. Este requisito presenta algunos desafíos para el diseño de la continuidad empresarial y el uso de los grupos de conmutación por error. Considere las siguientes opciones al implementar dicho acceso restringido.

Uso de los grupos de conmutación por error y los puntos de conexión de servicio de red virtual

Si usas reglas y puntos de conexión de servicio Virtual Network para restringir el acceso a la base de datos, ten en cuenta que cada punto de conexión de servicio de red virtual solo se aplica a una región de Azure. El punto de conexión no permite que otras regiones acepten la comunicación de la subred. Por lo tanto, solo las aplicaciones de cliente implementadas en la misma región pueden conectarse a la base de datos principal. Puesto que una conmutación por error geográfica provoca que las sesiones de cliente de SQL Database se vuelvan a enrutar al servidor en una región diferente (secundaria), puede producirse un error en las sesiones si se originaron desde un cliente de fuera de esa región. Por ese motivo, la directiva de conmutación por error de Microsoft no se puede habilitar si se incluyen los servidores implicados en las reglas de red virtual. Para admitir la directiva de conmutación por error manual, sigue estos pasos:

1. Aprovisiona las copias redundantes de los componentes frontend de la aplicación (servicio web, máquinas virtuales, etc.) en la región secundaria.
2. Configura las reglas de red virtual individualmente para el servidor principal y secundario.
3. Habilita la conmutación por error frontend con una configuración de Traffic Manager.
4. Inicia una conmutación por error geográfica manualmente cuando se detecte la interrupción. Esta opción está optimizada para las aplicaciones que requieren una latencia coherente entre la capa de datos y de frontend, y admite la recuperación cuando se ven afectadas por la interrupción la capa de datos, la capa frontend o ambas.

Nota:

Si usas el agente de escucha de solo lectura para equilibrar una carga de trabajo de solo lectura, asegúrate de que esta carga de trabajo se ejecuta en una máquina virtual o en otro recurso en la región secundaria de modo que pueda conectarse a la base de datos secundaria.

Uso de grupos de conmutación por error y reglas de firewall

Si el plan de continuidad empresarial requiere un proceso de conmutación por error mediante el uso de grupos con conmutación por error, puedes restringir el acceso a SQL Database con las reglas de firewall de IP públicas. Esta configuración garantiza que una conmutación por error geográfica no bloquee las conexiones desde los componentes frontend y da por supuesto que la aplicación tolera la mayor latencia entre la capa de datos y el frontend.

Para admitir la conmutación por error de grupos de conmutación por error, sigue estos pasos:

1. Cree una dirección IP pública.
2. Cree un equilibrador de carga público y asígnele la dirección IP pública.
3. Cree una red virtual y las máquinas virtuales para los componentes front-end.
4. Cree un grupo de seguridad de red y configure las conexiones entrantes.
5. Asegúrese de que las conexiones salientes estén abiertas para Azure SQL Database en una región mediante el uso de una Sql.<Region>Sql.<Region>.
6. Cree una regla de firewall de SQL Database para permitir el tráfico entrante desde la dirección IP pública que creó en el paso 1.

Para más información acerca de cómo configurar el acceso de salida y qué dirección IP usar en las reglas de firewall, consulte Conexiones salientes del equilibrador de carga.

Importante

Para garantizar la continuidad empresarial durante las interrupciones regionales, debes garantizar la redundancia geográfica tanto para los componentes front-end como para las bases de datos.

Permisos

Los permisos para un grupo de conmutación por error se administran a través del control de acceso basado en rol de Azure (Azure RBAC).

El acceso de escritura de RBAC de Azure es necesario para crear y administrar grupos de conmutación por error. El rol Colaborador de SQL Server tiene todos los permisos necesarios para administrar grupos de conmutación por error.

En la tabla siguiente se enumeran los ámbitos de permiso específicos para Azure SQL Database:

Acción	Permiso	Ámbito
Creación de un grupo de conmutación por error	Acceso de escritura de RBAC de Azure	Servidor principal Servidor secundario Todas las bases de datos del grupo de conmutación por error
Actualización de grupo de conmutación por error	Acceso de escritura de RBAC de Azure	Grupo de conmutación por error Todas las bases de datos del servidor principal actual
Conmutación por error de un grupo de conmutación por error	Acceso de escritura de RBAC de Azure	Grupo de conmutación por error en el nuevo servidor

Limitaciones

Tenga en cuenta las siguientes limitaciones:

• No se pueden crear grupos de conmutación por error entre dos servidores en la misma región de Azure.
• Los grupos de conmutación por error admiten la replicación geográfica de todas las bases de datos en el grupo solo a un servidor lógico secundario en otra región.
• No se puede cambiar el nombre de los grupos de conmutación por error. Tendrá que eliminar el grupo y volver a crearlo con otro nombre.
• No se admiten los cambios de nombre de la base de datos para las bases de datos de un grupo de conmutación por error. Tendrás que eliminar temporalmente el grupo de conmutación por error para poder cambiar el nombre de una base de datos o quitar la base de datos del grupo de conmutación por error.
• La eliminación de un grupo de conmutación por error de una base de datos única o agrupada no detiene la replicación y no elimina la base de datos replicada. Tendrás que detener manualmente la replicación geográfica y eliminar la base de datos del servidor secundario si querías volver a agregar una base de datos única o agrupada a un grupo de conmutación por error una vez que se haya quitado. Si no hace nada de esto, es posible que se produzca un error similar a The operation cannot be performed due to multiple errors al intentar agregar la base de datos al grupo de conmutación por error.
• El nombre del grupo de conmutación por error está sujeto a restricciones de nomenclatura.

Administración mediante programación de grupos de conmutación por error

Los grupos de conmutación por error también se pueden administrar mediante programación con Azure PowerShell, la CLI de Azure y la API de REST. En las tablas siguientes se describe el conjunto de comandos disponibles. Los grupos de conmutación por error incluyen un conjunto de API de Azure Resource Manager para la administración, en el que se incluyen la API de REST de Azure SQL Database y los cmdlets de Azure PowerShell. Estas API requieren que se usen grupos de recursos y admiten el control de acceso basado en rol de Azure (Azure RBAC). Para más información sobre cómo implementar los roles de acceso, consulte Control de acceso basado en roles de Azure (Azure RBAC).

PowerShell

Cmdlet	Descripción
New-AzSqlDatabaseFailoverGroup	Este comando crea un grupo de conmutación por error y lo registra en el servidor principal y el servidor secundario
Remove-AzSqlDatabaseFailoverGroup	Quita un grupo de conmutación por error del servidor.
Get-AzSqlDatabaseFailoverGroup	Recupera la configuración de un grupo de conmutación por error.
Set-AzSqlDatabaseFailoverGroup	Modifica la configuración de un grupo de conmutación por error.
Switch-AzSqlDatabaseFailoverGroup	Desencadena la conmutación por error de un grupo de conmutación por error en el servidor secundario.
Add-AzSqlDatabaseToFailoverGroup	Agrega una o varias bases de datos a un grupo de conmutación por error.

Nota:

Es posible implementar el grupo de conmutación por error entre suscripciones mediante el -PartnerSubscriptionId parámetro de Azure PowerShell a partir de Az.SQL 3.11.0. Para más información, consulte el siguiente ejemplo.

CLI de Azure

Comando	Descripción
az sql failover-group create	Este comando crea un grupo de conmutación por error y lo registra en el servidor principal y el servidor secundario
az sql failover-group delete	Quita un grupo de conmutación por error del servidor.
az sql failover-group show	Recupera la configuración de un grupo de conmutación por error.
az sql failover-group update	Modifica la configuración de un grupo de conmutación por error, o bien agrega una o varias bases de datos a un grupo de conmutación por error.
az sql failover-group set-primary	Desencadena la conmutación por error de un grupo de conmutación por error en el servidor secundario.

REST API

API	Descripción
Crear o actualizar grupo de conmutación por error	Crea o actualiza un grupo de conmutación por error.
Eliminar grupo de conmutación por error	Quita un grupo de conmutación por error del servidor.
Conmutación por error (planeada)	Desencadena la conmutación por error del servidor principal actual en el servidor secundario con sincronización de datos completa.
Forzar la conmutación por error ocasiona la pérdida de datos	Desencadena la conmutación por error del servidor principal actual en el servidor secundario sin sincronización de datos. Esta operación puede ocasionar pérdida de datos.
Obtener grupo de conmutación por error	Recupera la configuración de un grupo de conmutación por error.
Enumerar grupos de conmutación por error por servidor	Enumera los grupos de conmutación por error en un servidor.
Actualizar grupo de conmutación por error	Actualiza la configuración de un grupo de conmutación por error.

Pasos siguientes

Para ver información general de las opciones de alta disponibilidad de Azure SQL Database, consulta la replicación geográfica y grupos de conmutación por error.