Ejercicio: grupos de conmutación por error automática distribuidos geográficamente con escalado de lectura

Completado

En la unidad anterior, ha obtenido información sobre la replicación geográfica y los grupos de conmutación por error automática. En este ejercicio, configurará grupos de conmutación por error automática para la base de datos de Azure SQL. Después, iniciará una conmutación por error y verá los resultados.

Grupos de conmutación por error automática en Azure SQL

Para configurar grupos de conmutación por error automática para una o varias bases de datos y ver los resultados, debe completar estos pasos:

1. Configure el entorno.
2. Cree un servidor de Azure SQL Database vacío en la región de conmutación por error.
3. Cree un grupo de conmutación por error entre los servidores.
4. Configure la red.
5. Agregue una o varias bases de datos al grupo de conmutación por error.
6. Configure las aplicaciones del símbolo del sistema.
7. Comprenda las aplicaciones en ejecución.
8. Inicie una conmutación por error.
9. Realice una conmutación por recuperación.

En este ejercicio se le guía a través de la configuración de grupos de conmutación por error automática para la base de datos AdventureWorks. Después, usará una aplicación de línea de comandos simple para entender dónde se producen las operaciones de lectura y escritura, y la importancia de la lógica de reintento en las aplicaciones. Por último, realizará un curioso ejercicio para determinar cuántas réplicas de lectura están asociadas a una base de datos de nivel Crítico para la empresa que también tiene un grupo de conmutación por error automática.

Configuración del entorno

1. Copie el código siguiente en el Bloc de notas o en otro editor de texto. Proporcione su información. Agregue la contraseña de autenticación de SQL. En $drLocation, proporcione la región donde quiere que esté el grupo de conmutación por error. Idealmente, elija una región emparejada a la región del servidor actual. Puede consultar la lista de regiones emparejadas. Como mínimo, no puede ser la región en la que se encuentra la base de datos original. Por último, agregue la dirección IP del equipo local. Si tiene que determinar la dirección IP, abra PowerShell en el equipo local y ejecute (Invoke-WebRequest -Uri "https://ipinfo.io/ip").Content.

   # Add your info
   $password = "password"
   $drLocation = "westus2"
   $ipAddress = "xx.xx.xx.xx"
   

2. Ejecute el comando actualizado en Azure Cloud Shell (en el lado derecho de esta página).

3. Ejecute este script en Azure Cloud Shell para configurar las variables de los pasos siguientes:

   $admin = "cloudadmin"
   $resourceGroup = Get-AzResourceGroup | Where ResourceGroupName -like <rgn>Sandbox resource group name</rgn>
   $location = $resourceGroup.Location
   $resourceGroup = $resourceGroup.ResourceGroupName
   $database = "AdventureWorks"
   $server = Get-AzureRmSqlServer -ResourceGroupName $resourceGroup
   $server = $server.ServerName
   $drServer = "$($server)-dr"
   $failoverGroup = "$($server)-fg"
   $firewallRule = "AllowMyIp"
   Write-Host "Variables Received"
   

4. Cree un servidor de Azure SQL Database vacío en la región de conmutación por error mediante la ejecución de este script en Azure Cloud Shell:

   # Create a backup server in the failover region
   New-AzSqlServer -ResourceGroupName $resourceGroup `
       -ServerName $drServer `
       -Location $drLocation `
       -SqlAdministratorCredentials $(New-Object -TypeName System.Management.Automation.PSCredential `
       -ArgumentList $admin, $(ConvertTo-SecureString -String $password -AsPlainText -Force))
   Write-Host "New Azure SQL Database logical server Created in different region"
   

5. Cree un grupo de conmutación por error entre los servidores mediante la ejecución de este script en Azure Cloud Shell:

   # Create a failover group between the servers
   New-AzSqlDatabaseFailoverGroup -ResourceGroupName $resourceGroup `
       -ServerName $server `
       -PartnerServerName $drServer `
       -FailoverGroupName $failoverGroup 
   Write-Host "New auto-failover group created between the two Azure SQL Database logical servers"
   

6. Configure la red mediante la ejecución de este script en Azure Cloud Shell:

   # Add a firewall rule that gives your VM access to the new server
   New-AzSqlServerFirewallRule -ResourceGroupName $resourceGroup `
       -ServerName $drServer `
       -FirewallRuleName $firewallRule `
       -StartIpAddress $ipAddress `
       -EndIpAddress $ipAddress;
   

   Con el fin de ilustrar los grupos de conmutación por error automática, esta configuración de red es suficiente. Es ligeramente distinto de lo que haría en un entorno empresarial. En un entorno empresarial, el equipo que necesita acceso será probablemente un conjunto de recursos que componen algún tipo de aplicación. Si la base de datos conmuta por error, es posible que quiera que la aplicación, las máquinas virtuales u otros recursos también lo hagan en la nueva región. Los dos conjuntos de recursos necesitarán acceso a los recursos, servidores o bases de datos de la otra región. Para ello, puede usar el emparejamiento de redes virtuales, conexiones de red virtual a red virtual o tal vez algo más (como Azure ExpressRoute). Esto depende de su escenario.

7. Agregue una o varias bases de datos al grupo de conmutación por error mediante la ejecución de este script en Azure Cloud Shell:

   # Add the database or databases to the failover group
   Get-AzSqlDatabase -ResourceGroupName $resourceGroup `
       -ServerName $server -DatabaseName $database | `
       Add-AzSqlDatabaseToFailoverGroup -ResourceGroupName $resourceGroup `
       -ServerName $server `
       -FailoverGroupName $failoverGroup
   Write-Host "AdventureWorks database added to the auto-failover group"
   

   Este script tardará algún tiempo en ejecutarse. Va a restaurar la base de datos en la otra región, lo que implica copiar los datos de la región original en la de recuperación ante desastres. Puede trabajar en los pasos de la sección siguiente y, después, volver a comprobar si se ha completado el script.

Ya ha implementado y configurado un grupo de conmutación por error automática para la base de datos AdventureWorks.

Configuración de las aplicaciones del símbolo del sistema

En esta sección, usará dos cargas de trabajo de ostress para comprobar el valor Updateability (si una base de datos está en un estado ReadWrite o ReadOnly) de los servidores principal y secundario del grupo de conmutación por error. En este escenario se pretende simular una aplicación para la que se han leído y escrito cargas de trabajo.

1. Abra dos ventanas independientes del símbolo del sistema. Coloque las ventanas para que pueda ver esta (el explorador) y las dos ventanas del símbolo del sistema.

2. En las dos ventanas del símbolo del sistema, vaya a la carpeta Availability como ha hecho en los ejercicios anteriores. Por ejemplo, podría usar este comando:

   cd C:\Users\username\mslearn-azure-sql-fundamentals\05-Availability
   

3. Usará la primera ventana del símbolo del sistema para comprobar el estado del servidor principal en el grupo de conmutación por error que ha creado. Ejecute este comando con el nombre del servidor y la contraseña:

   .\ostress.exe -S"<server-name>-fg.database.windows.net" -Q"SELECT DATABASEPROPERTYEX(DB_NAME(),'Updateability')" -U"cloudadmin" -d"AdventureWorks" -P"password" -n1 -r5000 -oprimary
   

   Nota:

   Con los grupos de conmutación por error automática, se conecta al nombre del grupo de conmutación por error, que es la abstracción de la base de datos.

4. Usará la segunda ventana del símbolo del sistema para comprobar el estado del servidor secundario en el grupo de conmutación por error que ha creado. Ejecute este comando con el nombre del servidor y la contraseña:

   ostress.exe -S"<server-name>-fg.secondary.database.windows.net" -Q"SELECT DATABASEPROPERTYEX(DB_NAME(),'Updateability')" -U"cloudadmin" -d"AdventureWorks" -P"password" -n1 -r5000 -osecondary
   

El resultado del primer comando debe ser READ_WRITE, porque comprueba el servidor del grupo de conmutación por error principal y no ha iniciado ninguna conmutación por error.

El resultado del segundo comando debe ser READ_ONLY, porque comprueba el servidor secundario o de recuperación ante desastres que ha configurado. Solo se debe poder escribir desde uno de los servidores en un momento dado.

En los pasos siguientes, verá lo que sucede con los dos servidores cuando se produce una conmutación por error.

Inicio de una conmutación por error y observación de los resultados

1. Use el terminal de Azure Cloud Shell del lado derecho de esta página para comprobar el estado del servidor secundario:

   (Get-AzSqlDatabaseFailoverGroup -FailoverGroupName $failoverGroup `
       -ResourceGroupName $resourceGroup -ServerName $drServer).ReplicationRole
   

   El resultado indica si el servidor secundario del grupo de conmutación por error automática se usa como base de datos principal o secundaria.

2. Ahora puede ver lo que sucede cuando se produce una conmutación por error. Inicie una conmutación por error manual; para ello, escriba estos comandos de Azure PowerShell en el terminal de Azure Cloud Shell:

   Switch-AzSqlDatabaseFailoverGroup -ResourceGroupName $resourceGroup `
    -ServerName $drServer -FailoverGroupName $failoverGroup
   

   Cuando se produce la conmutación por error, es posible que observe que las conexiones se quitan durante un momento, pero dado que la aplicación sigue reintentando, no produce un error por completo. Una vez que se ha completado la conmutación por error, verá que los resultados de READ_WRITE y READ_ONLY se reanudan y no se cambian.

   Una de las ventajas de los grupos de conmutación por error automática en Azure SQL Database y Azure SQL Managed Instance es que no es necesario actualizar las cadenas de conexión después de una conmutación por error. Continúe con la conexión a la réplica principal (<failover-group>.database.windows.net) para las cargas de trabajo de escritura y la secundaria (<failover-group>.secondary.database.windows.net) para las de lectura. Azure se encarga de dirigirle a la base de datos adecuada en la región o el servidor correspondiente.

3. Ejecute este script en Azure Cloud Shell para comprobar el estado del servidor secundario:

   (Get-AzSqlDatabaseFailoverGroup -FailoverGroupName $failoverGroup `
       -ResourceGroupName $resourceGroup -ServerName $drServer).ReplicationRole
   

   Ahora este servidor debe estar en el rol principal.

4. Ejecute este script en Azure Cloud Shell para realizar la conmutación por recuperación:

   Switch-AzSqlDatabaseFailoverGroup -ResourceGroupName $resourceGroup `
    -ServerName $server -FailoverGroupName $failoverGroup
   

5. Por último, puede volver a comprobar el estado del servidor secundario. Ejecute este script en Azure Cloud Shell:

   (Get-AzSqlDatabaseFailoverGroup -FailoverGroupName $failoverGroup `
       -ResourceGroupName $resourceGroup -ServerName $drServer).ReplicationRole
   

6. Ahora puede cerrar las dos ventanas del símbolo del sistema y maximizar la del explorador de Microsoft Learn.

En este ejercicio ha aprendido a implementar y configurar grupos de conmutación por error automática. También ha aprendido lo que significa desde la perspectiva de la aplicación. Los grupos de conmutación por error automática son simplemente una manera de llegar más lejos con la disponibilidad y el escalado de lectura en Azure SQL.