Desbloqueo de Azure: cómo construir una infraestructura de base de datos SQL altamente flexible

No es un secreto que en los últimos años la Infraestructura como Servicio y la Plataforma como Servicio se han generalizado cada vez más en diversos proyectos debido a sus capacidades, en particular la eficiencia y flexibilidad de los recursos. Como resultado, Microsoft dedicó mucho tiempo y esfuerzo a crear un entorno fácil de usar en el que se pueda utilizar SQL.

El equipo de Social Discovery Group utiliza una variedad de bases de datos, incluido SQL, para potenciar nuestros productos. Con una cartera de más de 40 servicios globales que ayudan a reunirse y conectarse en todo el mundo, nuestra base de usuarios incluye más de 250 millones de personas en todo el mundo. Para garantizar la confiabilidad de nuestros productos para los usuarios, mantenemos parte de la infraestructura clave en la nube. Esto ayuda a mejorar su resiliencia, seguridad y flexibilidad.

Tenemos bastante experiencia en la implementación de bases de datos de servicios y servidores en varias plataformas, incluidos los clústeres de Kubernetes. Sin embargo, nos enfrentamos a la necesidad de hacer que una parte de la infraestructura de bases de datos SQL relacionada en la nube de Azure sea lo más flexible, eficiente y confiable posible. Hay 3 formas de utilizar SQL en la nube de Microsoft Azure:

• Base de datos SQL de Azure
• Instancia administrada de Azure SQL
• SQL Server en máquinas virtuales de Azure

Después de la investigación, decidimos utilizar bases de datos Azure SQL. Sólo para aclarar a aquellos que nunca han oído hablar de las llamadas bases de datos Azure SQL, son bases de datos administradas en la nube que se proporcionan como parte de Microsoft Azure.

He destacado los siguientes beneficios:

• No hay necesidad de preocuparse por las actualizaciones o el soporte al final de su vida útil;
• Fácil configuración e implementación;
• Velocidad de implementación (y por tanto de desarrollo) y escalabilidad;
• Alta disponibilidad;
• Tolerancia a fallos;
• Facilidad de copia de seguridad;
• Optimización de costos;
• Un sistema de monitoreo integrado de Microsoft Azure.

Ahora hablemos paso a paso y echemos un vistazo al proceso de implementación y creación de una base de datos. Esto se puede hacer usando un script de Power Shell o la CLI de Azure, pero para mayor claridad, analizo el proceso usando la interfaz gráfica del portal. Para hacer esto, vaya a Azure SQL, haga clic en "Crear" y seleccione "Bases de datos SQL".

Especificamos el grupo de recursos, seleccionamos si existe un servidor existente o creamos uno nuevo (indicando el nombre y los datos del administrador) y creamos un nombre para la base de datos. Recomendaría elegir paquetes basados en DTU (unidad de transacción de base de datos) con una combinación equilibrada de recursos informáticos y de almacenamiento para nuestras cargas de trabajo comunes.

También hay algunas pestañas para configuraciones: Red, Seguridad, Configuraciones adicionales y Etiquetas; para una configuración estándar mínima, estos se pueden dejar sin cambios de forma predeterminada. Luego esperamos a que se cree la base de datos. Esto completa la configuración mínima y la base estará lista.

El tamaño de los recursos de la base de datos se puede cambiar muy fácilmente, literalmente con un clic, y en caso de recursos insuficientes, podemos establecer los parámetros que necesitemos en términos de tamaño y rendimiento.

Luego podrás conectarte a tu base de datos de la forma que prefieras desde el exterior, sin olvidar agregar tu dirección IP o subred, o permitir todas las conexiones en el firewall del servidor en el que está alojada esta base de datos.

Es conveniente conectarse y administrar aún más a través de SQL Server Management Studio (SSMS), pero también es posible hacerlo a través de otras herramientas y el propio portal de Azure.

Además de un punto de conexión público, también puede crear uno privado agregando un servidor a la subred requerida y configurando zonas DNS privadas.

Hablando de tolerancia a fallos, aquí vemos una implementación muy cómoda e intuitiva de conmutación por error, un grupo de servidores protectores ubicados en diferentes regiones.

En Azure, es posible agregar y eliminar bases de datos en servidores en un grupo de conmutación por error, conmutación por error forzada y modo de conmutación por error automática.

Puedes ver esto en la captura de pantalla a continuación. Pensemos en un nombre para el grupo de conmutación por error y pongamos el servidor en conmutación por error. La sincronización de las bases de datos especificadas se iniciará automáticamente. El segundo servidor estará en modo de solo lectura. En caso de falla, el tráfico cambia automáticamente a la segunda región y los servidores primario y secundario cambian de lugar automáticamente.

Pero la conmutación por error no ayudará si hay un problema a nivel de datos en las propias bases de datos. Seguro que en este caso es necesario crear copias de seguridad. Es posible configurar copias de seguridad tanto dentro del portal como a través de herramientas de terceros o, por ejemplo, Azure DevOps (en el proceso, puede usar la tarea SqlAzureDacpacDeployment + AzureFileCopy). Dentro del portal, las copias de seguridad se configuran en la pestaña Copias de seguridad y se establecen las políticas de almacenamiento necesarias.

Si prefiere utilizar herramientas de copia de seguridad de terceros, le recomendaría considerar las herramientas del paquete Azure DevOps o SQL.

En mi opinión, el proceso de recuperación en el portal en sí no es muy conveniente. Lo primero que llama la atención es el largo tiempo de recuperación de las bases de datos de prueba simples. Por ejemplo, ¡me tomó más de media hora restaurar una base de datos de tamaño básico de 30 MB a partir de la copia de seguridad de ayer! Después de comunicarme con el soporte de Microsoft Azure, me recomendaron que usara scripts de PowerShell para la recuperación y me notificaron que el tamaño de la base de datos debería ser al menos S3 para el proceso de recuperación y que luego se podría reducir el tamaño. A continuación les voy a presentar algunos de mis scripts y desarrollos sobre este tema, se pueden mejorar y potenciar pero estoy seguro que a muchos de ustedes les podrán resultar útiles.

Te llevaré paso a paso:

1. En caso de que no tengas instalado PowerShell ISE en Windows, descárgalo aquí: https://github.com/PowerShell/Pohell/releases/download/v7.3.0/PowerShell-7.3.0-win-x64.msi
   https://github.com/PowerShell/PowerShell/releases/download/v7.3.0/PowerShell-7.3.0-win-x86.msi
2. A continuación, debe instalar el módulo de Azure: Install-Module Az
3. Después de instalar el módulo AZ, importe el módulo AZ: Import-Module Az
4. Una vez importado, puede conectarse a su cuenta de Azure: Connect-AzAccount. Aparecerá una ventana emergente para iniciar sesión en su cuenta de Azure, luego estará conectado
5. Ejecute el script de PowerShell.

 “ #Variables in use $Database = Get-AzSqlDatabase -ResourceGroupName "Test" -ServerName "test-serv1" -DatabaseName "dbforscript" $TargetDB = "dbforscript_new" $PITRtimedate = "2022-12-02 10:00:00Z" ##вам нужно увидеть действительную дату и время на портале $PITRSLO = "S3" $PITRNEWSLO = "S0" $PITRedition = "Standard" $failoverGroupRG = "Test" $failoverGroupS = "test-serv1" $failoverGroupDB = "dbforscript" $removedbfromfgRG = "Test" $removedbfromfgS = "test-serv1" $removedbfromfgDB = "XXXXX" $dropreplicaRG = "Test" $dropreplicaS = "test-serv2" $dropreplicaDB = "dbforscript" $sourcedbRG = "Test" $sourcedbS = "test-serv1" $sourcedbDBname = "dbforscript" $sourcedbDBNEWname = "dbforscript_old" $TargetDBNEWname = "dbforscript" “

1: este código inicia una restauración de la base de datos con un nombre diferente. Si el nombre original de la base de datos que se está restaurando es "dbforscript", entonces el nombre de la base de datos restaurada será dbforscript_new. La base de datos restaurada será SLO versión S3 o superior, que es la forma recomendada de realizar esta acción, la variable para esto es $PITRSLO = "S3", puedes usar S3 o superior. Después de esto restableceremos el nivel de SLO al original, esto es solo para recuperación.

 “Restore-AzSqlDatabase -FromPointInTimeBackup -PointInTime $PITRtimedate -ResourceGroupName $Database.ResourceGroupName -ServerName $Database.ServerName -TargetDatabaseName $TargetDB -ResourceId $Database.ResourceID -Edition $PITRedition -ServiceObjectiveName $PITRSLO”

2: este código eliminará la base de datos de origen del grupo de conmutación por error: base de datos de origen: dbforscript.

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $failoverGroupdb | Remove-AzSqlDatabaseFromFailoverGroup -ResourceGroupName $removedbfromfgRG -ServerName $removedbfromfgS -FailoverGroupName $removedbfromfgDB”

3 - Este código eliminará la réplica de la base de datos del servidor donde se encuentra: dbforscript en el servidor test-serv2.

 “Remove-AzSqlDatabase -ResourceGroupName $dropreplicaRG -ServerName $dropreplicaS -DatabaseName $dropreplicaDB”

4 - Este código cambiará el nombre de la base de datos original a un nombre diferente: después del cambio de nombre, dbforscript será dbforscript_old.

 “Set-AzSqlDatabase -ResourceGroupName $sourcedbRG -DatabaseName $sourcedbDBname -ServerName $sourcedbS -NewName $sourcedbDBNEWname”

5: este código cambiará el nombre de la base de datos restaurada al nombre de la base de datos original, cambiando el nombre de dbforscript_new a dbforscript.

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDB -ServerName $Database.ServerName -NewName $TargetDBNEWname”

6: este código devolverá el nivel SLO de su base de datos al valor S0 anterior (original). Si su base de datos es básica, puede actualizar de S0 a básica después en el portal.

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDBNEWname -ServerName $Database.ServerName -Edition $PITRedition -RequestedServiceObjectiveName $PITRNEWSLO -MaxSizeBytes 10737418240”

7 - El último código agrega la base de datos restaurada al grupo de conmutación por error, que ya tiene el nombre original (ya que lo cambiamos en el código anterior).

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $TargetDBNEWname | Add-AzSqlDatabaseToFailoverGroup -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -FailoverGroupName $removedbfromfgDB”

Puede considerar agregar el parámetro - ErrorAction Stop después del comando. Esto evitará que se ejecuten los siguientes comandos en caso de error y no se producirá una bola de nieve.

Además, puede agregar Get-Date al principio y al final del script para calcular el tiempo de ejecución. En mi caso, un script de este tipo restauró una base de datos de aproximadamente 3,3 GB en menos de 6 minutos.

Si lo desea, seguramente puede optimizar el script, agregarlo a través de Azure DevOps, reducir la cantidad de variables o codificar algo, pero he intentado describirlo con el mayor detalle posible y de una manera que todos puedan entender.

Merece especial atención el monitoreo de bases de datos en Azure y la capacidad de integración con varios sistemas, como Datadog. El monitoreo es bastante conveniente, pero no está exento de matices (en el momento de escribir este artículo, por ejemplo, los usuarios de solo lectura solo podían ver el monitoreo de una base de datos, no de todas a la vez... bueno, aquí están los matices).

En conclusión, nuestro equipo ha optimizado con éxito los gastos y al mismo tiempo ha abordado las inquietudes relacionadas con las actualizaciones y la interrupción del soporte. Logramos mejoras en rendimiento, resiliencia, velocidad de desarrollo y flexibilidad. Además, la implementación de scripts ha mejorado notablemente nuestra capacidad de recuperarnos rápidamente cuando sea necesario.

Escrito por Pavel Shapurau, ingeniero jefe de DevOps en Social Discovery Group.