Hola a todos!
Hoy vamos a darle a un tema muy interesante, las bases de datos relacionales en Microsoft Azure.
Cuando hablamos de base de datos relacionales tenemos SQL Server, donde existen 3 tipos de bases de datos:
El primero es como infraestructura como servicio y aquí encontramos con SQL Server a través de una máquina virtual, es decir nosotros tenemos una máquina virtual y dentro de esta se encuentra instalada la base de BBDD, y esto es lo mejor para migraciones, ir alojando aplicaciones o a lo mejor realojando una BBDD on-premise hacia la nube. Esto nos da ventaja que tenemos el control total del sistema operativo y de la instancia, mientras nosotros básicamente controlamos todo más control tenemos.
El siguiente modelo sería plataforma como servicio (PaaS) encontrando dentro dos tipos de instancias de bases de datos; el primero es SQL Server Manage Instance donde aquí vamos a encontrar la instancia a través de Azure, nosotros nos encontramos con un servicio donde nos van a proveer la instancia y dentro de ello vamos a colocar las bases de datos. La ventaja de esto es que nosotros podemos estar migrando bases de datos (por ejemplo, SQL Server 2016 Enterprise Edition) y no habrá problemas ya que lo trasladamos directamente a Azure Manage Instance. Además, otras posibilidades que vamos a dar más adelante.
El servicio es Azure SQL database es otra solución que lo que hace es tener una base de datos, como si fuera una base de datos única, donde dentro va a controlar la computación va a controlar básicamente la administración y nosotros, los clientes, o usuarios, o técnicos (como queramos llamarlo) nos encontramos con la BBDD y adentro vamos a tener que alojar los datos con la última versión de la base de datos. Tenemos que pensar que Microsoft libera las características nuevas de su base de datos SQL database antes en Azure que la versión premium, por lo que nosotros siempre vamos a tener una instancia una base de datos perfectamente actualizada.
Azure SQL en VM (IaaS):
Vamos a ver la opción de una instancia de Azure SQL con una máquina virtual (VM), cuyas ventajas son que es administrado totalmente por el cliente, o sea, que nosotros administramos los componentes como la base de datos y el servidor propiamente dicho, haciendo uso del método de pago “paga por lo que consumes”, o sea “Pay As You Go”, que básicamente nosotros utilizamos un volumen de base de datos y es lo pagaremos. Funciona cuando el cliente quiere y se detiene cuando el cliente quiere. Es el método más fácil para migración ya que se migra tal cual se tiene en el servidor on-prem y se sube hacia la nube, es una migración sin cambiar a penas nada, o sin hacer ninguna modificación.
Notas de cálculo de gastos con la Calculadora de Azure:
Para ver cómo sería el coste, a modo de hacer un ejercicio de cómo podemos calcular los costos, es recomendable ir a la calculadora de Azure (https://azure.microsoft.com/es-es/pricing/calculator/), deberemos ir a la selección de la máquina virtual vamos a seleccionar el sistema operativo que es Windows y seleccionamos con SQL Server, dentro seleccionamos la instancia, en este caso seleccionaríamos la categoría de propósito general (General Purpouse) y seleccionamos la instancia para esta máquina virtual, seleccionamos el tamaño que corresponda, y aquí es muy importante seleccionar la licencia que se quiere migrar de on-premise (en nuestros servidores locales) hacia la nube pública de Microsoft. Las licencias pueden ser Enterprise, Standar o Web. A la hora de realizar los cálculos, nosotros podemos estar calculando los discos que necesitamos, podemos incluso controlar el ancho de banda, etcétera.
Si nosotros queremos ahorrar en costos de licenciamiento de SQL Server podemos llevarnos nuestra licencia hacia el entorno de Azure y utilizar algo que se llama Azure hybrid Benefit, lo que hace es básicamente llevarnos nuestra licencia hacia Azure, pero no sirve para todos los modelos, sí que sirve por ejemplo la parte de instancia administrada.
Azure SQL database:
El siguiente modelo es Azure SQL Database, en la que nosotros nos encontramos con una base de datos totalmente administrada por Microsoft, y nosotros vamos a tener una plataforma como servicio (PaaS), Donde Azure nos provee de la infraestructura subyacente para esta DDBB y nosotros nos encargamos de administrar algunos servicios como el monitoreo mientras que Microsoft Azure se encarga de las actualizaciones de la propia base de datos, de las actualizaciones del sistema operativo, del backup, de la seguridad y de la supervisión.
Nosotros tenemos acceso a esto, pero básicamente Microsoft se encarga de todo, siempre se ejecutará la última versión estable del motor de SQL Server ya que en Azure siempre se tiene la última versión.
No es ni de lejos la primera opción cuando estamos migrando, sino que tal como hemos visto hay otras opciones mejores cuando estamos migrando una base de datos.
Con este modelo tenemos disponibilidad del 99.9% de SLA (Service Level Agrement), y no admite el escalado automático.
Los modelos de compra o facturación que tenemos en esta versión son de dos tipos, o, mejor dicho, hay dos opciones.
Tenemos el modelo basado en DTU, que la DTU es una unidad pre-empaquetada que ya incluye la cantidad de cómputo, la cantidad de storage y lo que hace es que nosotros ya vamos a tener la potencia que necesitemos ya que va ligada al storage (almacenamiento). Si subimos la potencia de la CPU, automáticamente también sube el almacenamiento, si nosotros bajamos el storage también baja la CPU (el poder de cómputo).
Está diseñado para un rendimiento predecible, por lo que es interesante cuando ya sabemos previamente cuánto va a necesitar una BBDD, y es algo digamos inflexible y limitado en opciones porque solamente tenemos 3 opciones cómo veremos más adelante. Ahora el tamaño del de DTU también ofrece cierta sencillez ya que podemos elegir 3 tipos de tamaños.
También contamos con el modelo por vCores, en el modelo vCores nosotros elegimos mayor o menor cómputo, mayor o menor storage según nuestra necesidad, ya que aquí nosotros vamos a elegir la capacidad de la base de datos.
Este modelo nos permite elegir independientemente los recursos informáticos y almacenamiento, el nivel de rendimiento de la BBDD y vamos a poder utilizar y ahorrar costos. Tendremos la flexibilidad que nosotros queramos dado que vamos a tener el control y la transparencia en cuanto a saber cuántas CPU tenemos, cuántas horas estamos utilizando, y podemos escalar independientemente de las horas o del cómputo.
Compra por DTU:
Vamos a Comparar los tipos de DTU disponibles. Existen varios tipos de DTU, por ejemplo tenemos el DTU tipo Basic que es el más básico es el más pequeño es para pruebas después tenemos el estándar que va desde los 10 por personas a los 100 de DTU y se miden en estas letras que son S0, S1, S2 y S3, y obviamente cuando más grande es el DTU mayor es el costo de adquisición y la potencia, después de estos modelos también tenemos el premium, que es para cuando ya necesitamos mucho poder de cómputo y también mucho almacenamiento.
Qué pasará si nosotros tenemos varias BBDD y no podemos predecir el rendimiento, es decir, que a veces la base de datos se incrementará mucho en la parte del procesamiento, por lo que requiere mayor carga de CPU, bueno, pues en estos casos podemos pre-comprar estos DTU, comprar una bolsa de DTU y elegir el tipo Elastic Pool qué hará que se vaya adaptando.
El tipo Elastic Pool contendrá todas las bases de datos y cuando una base de datos requiera mayor capacidad de cómputo va a subir la cantidad de DTU automáticamente y cuando la base de datos requiera menor capacidad de cómputo decrecerá los DTU. Este modelo será el aplicable cuando estamos teniendo muchas bases de datos y requerimos escalabilidad.
Compra por VCore:
Vamos a tener el modelo en la parte de Azure SQL también compra por VCore, en el que nosotros compramos vCores según necesidades. Tenemos tres tipos distintos de compras, el primero es el General Purpouse, es de propósito general, es para la mayoría de las cargas de trabajo. Mencionamos que aquí vamos a contar con la posibilidad de elegir el tipo de CPU que vamos a tener en la base de datos y aquí nosotros contamos con el storage remoto que vamos a verlo más adelante a que se refiere.
El segundo es el Business Critical, que es bueno cuando requerimos cargas de trabajo que requieran muy baja latencia, que requieran replicación, que requieran alta disponibilidad, que es mucho más caro, como no podía ser de otra manera.
El tercero es el HyperScalar, que suele usarse cuando tenemos muchas bases de datos o una base de datos muy grande que requiere bastante procesamiento, que es muy escalable, que requiera por ejemplo rendimiento. En esa parte vamos a contar con el almacén almacenamiento local, además del almacenamiento remoto y aquí el tamaño de la base de datos puede llegar hasta los 100 TB, es cuando requerimos mayor cantidad de procesamiento en cuanto a la base de datos.
Por no hacerlo demasiado largo, lo cortaremos aquí, pero continuaremos en próximos artículos.
Un saludo!