Ejercicio: alta disponibilidad crítica para la empresa

10 minutos

En este ejercicio, actualizará la base de datos al nivel Crítico para la empresa. Verá cómo proporciona réplicas de lectura y un mayor rendimiento.

Usará la herramienta ostress que ha utilizado en el ejercicio anterior para crear una carga de trabajo. Después, iniciará una conmutación por error mediante el módulo Azure PowerShell en Azure Cloud Shell. Por último, verá el efecto que tiene la conmutación por error en la carga de trabajo de ostress.

Alta disponibilidad básica en el nivel de servicio Crítico para la empresa de Azure SQL

En este ejercicio, realizará los pasos siguientes:

Implementará la base de datos del ejercicio anterior en el nivel Crítico para la empresa.
Ejecutará la carga de trabajo de ostress.
Usará PowerShell para iniciar una conmutación por error.
Verá los resultados en ostress.
Se conectará a una réplica secundaria legible.

Implementación de la misma base de datos en el nivel Crítico para la empresa

En un módulo anterior, ha aprendido a escalar una base de datos con T-SQL. El objetivo de este ejercicio es actualizar la base de datos que ha usado en el ejercicio anterior del nivel De uso general a Crítico para la empresa. Usará Azure Cloud Shell para actualizar la base de datos. Como hay un límite sobre la frecuencia de las conmutaciones por error, se usará la misma base de datos de ejemplo, pero se le cambiará el nombre a AdventureWorks-bc.

En el terminal de Azure Cloud Shell en el lado derecho de esta página, ejecute el script de PowerShell siguiente para configurar el entorno:

$resourceGroup = "<rgn>Sandbox resource group name</rgn>"
$database = "AdventureWorks-bc"
$server = Get-AzureRmSqlServer -ResourceGroupName $resourceGroup
$server = $server.ServerName

# Specify your default resource group and Azure SQL Database logical server
az configure --defaults group=$resourceGroup sql-server=$server

# Confirm the defaults are set
az configure --list-defaults

Ejecute este comando para crear una base de datos en el nivel de servicio Crítico para la empresa:
```
az sql db create --name $database `
--edition BusinessCritical `
--family Gen5 `
--capacity 2 `
--sample-name AdventureWorksLT `
--read-scale Enabled `
--zone-redundant false
```
Este comando tarda algo de tiempo en finalizar. Mientras se ejecuta, puede revisar algunos de los parámetros que se usan:
- family: este parámetro especifica la generación del hardware. Para mantener la coherencia con el ejercicio anterior, se ha usado Gen5.
- capacity: este parámetro especifica el número de unidades de procesamiento de base de datos o núcleos virtuales. Para mantener la coherencia con el ejercicio anterior, se han usado 2 núcleos virtuales.
- sample-name: para mantener la coherencia con el ejercicio anterior, se ha usado la base de datos de ejemplo AdventureWorksLT.
- edition: este nombre de parámetro es un poco engañoso. Realmente hace referencia al nivel de servicio, que no es lo mismo que la edición que se usa en SQL Server.
- read-scale: esta opción no está habilitada de forma predeterminada, pero no tiene ningún costo adicional asociado. Al habilitarla, se habilita una de las réplicas secundarias para usarla como réplica secundaria legible.
- zone-redundant: de forma predeterminada, este parámetro se establece en false. Lo puede establecer en true si se quiere una implementación "AZ múltiple" sin costo adicional. Obtendrá más información sobre Availability Zones en la unidad siguiente.
  
  Nota:
  
  Availability Zones solo están disponibles en ciertas regiones. Actualmente no están disponibles en Azure SQL Managed Instance.
Después de crear la base de datos, debería ver información detallada sobre las actualizaciones en la salida de Azure Cloud Shell. Verá dos categorías principales (aunque también verá indicadores bajo otras propiedades):
- currentServiceObjectiveName: debe ser BC_Gen5_2. BC se corresponde a Crítico para la empresa.
- currentSku:
  - name: debe ser BC_Gen5.
  - tier: debe ser BusinessCritical.
Otra manera de comprobar el nivel de servicio es ir a la base de datos en Azure Portal. En la pestaña Información general, mire el Plan de tarifa.

Sugerencia

Hay otras muchas formas de ver estas actualizaciones. Otra manera consiste en usar SSMS. Si hace clic con el botón derecho en la base de datos y selecciona Propiedades>Configurar SLO, puede ver los cambios.

Ejecución de la carga de trabajo de ostress

Como en el ejercicio anterior, usará ostress para consultar de forma repetida la base de datos de Azure SQL.

Si cerró el símbolo del sistema que usó en el ejercicio anterior, abra una nueva ventana del símbolo del sistema en el equipo local. Use cd para ir al directorio del repositorio que ha clonado o descargado antes, y que contiene el módulo de disponibilidad. Por ejemplo, podría usar este comando:
```
cd C:\Users\username\mslearn-azure-sql-fundamentals\05-Availability
```
La carga de trabajo de ostress se conectará y ejecutará una consulta simple 50 000 veces.
Use el siguiente script de ostress para ejecutar la carga de trabajo. Reemplace serverName por el nombre del servidor lógico de Azure SQL Database. Reemplace password por la contraseña. Este comando es ligeramente diferente al del ejercicio anterior. Ahora el nombre de la base de datos es AdventureWorks-bc.
```
.\ostress.exe -S"serverName.database.windows.net" -Q"SELECT COUNT(*) FROM SalesLT.Customer" -U"cloudadmin" -d"AdventureWorks-bc" -P"password" -n1 -r50000
```
Si la carga de trabajo se ejecuta correctamente, debería ver que el resultado de la consulta 847 aparece repetidamente en la ventana del símbolo del sistema.

Si quiere detener la ejecución de la carga de trabajo de ostress antes de que termine, puede presionar Ctrl+C en el terminal.

Si quiere volver a ejecutar la carga de trabajo, puede ejecutar el comando de nuevo.

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

Configure las ventanas para que pueda ver este explorador y la ventana del símbolo del sistema al mismo tiempo.

Ejecute el código siguiente en el terminal de Azure Cloud Shell. Es el mismo comando que ha usado en el ejercicio anterior.

# create a failover
Invoke-AzSqlDatabaseFailover -ResourceGroupName $resourceGroup `
    -ServerName $server `
    -DatabaseName $database

Mientras se ejecuta este comando, debe observar cualquier cambio que aparezca en el terminal. Comprobará que no puede acceder a la base de datos mientras tiene lugar la conmutación por error. Esto dura muy poco tiempo. Después de la desconexión, debería volver a conectarse transcurridos unos 5 segundos. Esta conmutación por error es más de seis veces más rápida que la del nivel De uso general.

Recuerde que las bases de datos o las instancias administradas del nivel de servicio Crítico para la empresa básicamente tienen un grupo de disponibilidad AlwaysOn implementado en segundo plano, por lo que, al conmutar por error, todo lo que sucede es un cambio en los punteros en el back-end, ya que Azure le redirige a uno de los secundarios. Por este motivo, la conmutación por error es mucho más rápida que en el nivel De uso general.

Conexión a la réplica de solo lectura

Como ha habilitado el parámetro read-scale, puede usar una de las réplicas secundarias para cargas de trabajo de solo lectura. Para acceder a la réplica de solo lectura en las aplicaciones, solo tiene que agregar este parámetro a la cadena de conexión de una base de datos:

ApplicationIntent=ReadOnly;

En SSMS, cree una conexión de consulta. (Seleccione Archivo>Nuevo>Consulta de motor de base de datos).
En el cuadro de diálogo Conectar al servidor, use la configuración que ha utilizado para conectarse al servidor lógico de Azure SQL Database. (Es decir, use Autenticación de SQL Server). Seleccione Opciones.
Seleccione Propiedades de conexión y después Restablecer todo. En Conectar con base de datos, seleccione Examinar el servidor y elija la base de datos AdventureWorks-bc. Seleccione Aceptar.
Seleccione Parámetros de conexión adicionales y pegue lo siguiente en el cuadro de texto. Seleccione Conectar.
```
ApplicationIntent=ReadOnly;
```
Con SSMS, debe especificar el servidor y la base de datos a los que se quiere conectar. Esto se debe a que puede haber varias bases de datos en un servidor que tengan funciones diferentes para las réplicas secundarias legibles.
Como prueba, pruebe la consulta siguiente en la nueva consulta del motor de base de datos. Observe los resultados. ¿Son los que esperaba?
```
SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability')
```
Opcionalmente, puede volver a conectarse y actualizar los parámetros de conexión adicionales. (Reemplace ReadOnly por ReadWrite). Confirme que accede a la réplica principal de lectura/escritura. ReadWrite es el valor predeterminado, de modo que si no selecciona nada, eso es lo que obtendrá: