Azure DP-300 curso en Español – Parte 1

Mi empresa me ha dado la oportunidad de estudiar y sacarme el certificado DP-300 de Azure que viene a ser administración de entornos SQL en la cloud de Azure (lo que hago ahora, pero los servidores y las instancias están en cloud básicamente).

Como partiré el curso en 5 sesiones de 4 horas, creo que podría ser bueno para mí hacer resúmenes de lo más interesante de cada una de ellas y podría estar bien dejarlo plasmado en este blog, ya que puede que a alguien le sirva de algo en el futuro también.

No espereis el curso entero aquí, serán los conceptos más importantes.

Esta es la parte número 1 de esta serie de artículos.

Implementación de bases de datos de Azure SQL

Existen básicamente 3 formas de implementar SQL dentro de Azure:

1. SQL server en un VM (virtual machine) de Azure: La más típica. Es un servidor en el que instalas la versión SQL server que tú quieras. Tienes que gestionar todo el OS y lidiar con toda la configuración de la infraestructura del servidor (RAM,tipo y número de cpu, discos , etc).
2. Una base de datos Azure SQL: Simplemente Azure crea una base de datos a la que puedes acceder y gestionar, no tienes que lidiar con sistemas operativos ni servidores.
3. Azure SQL Managed Instance: Una mezcla de los 2 anteriores. Dispones de un servidor completo y tendrás que gestionar ciertas cosas pero todo lo relacionado con la infraestructura está gestionado por Azure. Puedes crear una instancia completa con todas las bases de datos que quieras.

Cómo gestionar los recursos en Azure SQL

Al igual que las instancias on-prem, gestionar servidores o instancias SQL Server también implicará gestionar los recursos que le asignamos a estos servidores o a las bases de datos.

Recursos como la CPU, la memoria RAM o el número y tipo de discos deben ser asignados teniendo en cuenta que Azure nos ofrecerá distintos precios según el modelo de compra y el nivel de servicio que queramos. Por suerte, estos recursos se pueden modificar fácilmente y adaptarlos a nuestras necesidades en cada momento.

Estos recursos pueden ser configurados de 2 formas:

1. Directamente a la base de datos: Cada base de datos tendrá unos recursos asignados para ella y exclusivamente para ella.
2. Resources Pool (grupo de recursos): Los recursos asignados a este grupo se repartirán entre los miembros del grupo automáticamente teniendo en cuenta cada momento las necesidades de cada miembro. Existen 2 tipos:
   1. 1. Elastic Pools (grupo elástico): Los recursos se asignan a todos los miembros del pool según la necesidad. Se configuran un máximo y un mínimo de recursos que se aplica a todos los miembros del grupo.
      2. Instance Pools.

¿Por qué usar grupos de recursos?

Imaginemos que tenemos 5 bases de datos y queremos que cada base de datos tenga disponibles 5 vCores. Si no queremos usar elastic pools, tendremos que asignarle 5 vCores a cada base de datos por lo que estaríamos pagando 25 vCores en total.

Esto sería correcto si todas las bases de datos están trabajando constantemente, pero lo más normal es que las bases de datos trabajen para aplicaciones y que no siempre estén trabajando por razones horarias.

Si combinamos estas bases de datos en un pool de recursos, podremos usar menos vCores y dejar que estos sean distribuidos según el uso real que necesitan las bases de datos.

Esto nos permitirá ahorrar recursos y por lo tanto dinero.

Como he dicho anteriormente, estos recursos pueden ser modificados en cualquier momento, por lo que siempre podemos añadir más en caso de ser necesario.

Modelos de recursos

Aparentemente las 2 formas más comunes de comprar o configurar los recursos en Azure son las siguientes:

1. DTU: Básicamente son como paquetes de recursos y cada paquete contiene X cantidad de todos los recursos juntos. Puedes seleccionar más o menos paquetes para tener más o menos recursos. Es una forma rápida y sencilla de gestionar los recursos para las bases de datos o para las pools de recursos. Dependiendo del plan de precios tendrán más funciones o menos. En el tier más bajo, los discos duros no serán sólidos.
2. vCores: Esta es la opción recomendada por Azure para la mayoría de casos. Te permite seleccionar el número de CPUs virtuales (vCores). Permite la configuración por separado de los diferentes recursos disponibles (RAM, espacio y tipos de disco…). Dentro de esta opción está la opción «Serverless» que sólo está disponible para bases de datos únicas sin servidor y que nos ayudará a no despilfarrar dinero escalando los vCores cuando sea necesario y sólo cobrandonos por el tiempo que han sido usados, incluso podemos hacer que la base de datos sea pausada automáticamente si lleva un tiempo sin ser usada.

En las opciones básicas y standard 100 DTUs equivalen más o menos a 1 vCore, mientras que en las clases premium 125 DTUs equivalen a 1 vCore aproximadamente.

Laboratorios DP-300

En esta sección añadiré todas las prácticas que haya hecho sobre esta primera parte, mi idea es hacerlas en distintas entradas para que esté mejor organizado, podéis hacer click para ir a ellas.

• Crear un servidor SQL Server en Azure con un grupo de recursos y bases de datos.
• Crear un servidor SQL Server usando una máquina virtual en Azure.

Espero que esta primera parte os haya servido. He resumido bastante a los conceptos que he considerado más importantes.