Desde hace más de un año llevamos trabajando y migrando clientes a Managed Instance en Azure, por eso cuando el pasado 4 de Septiembre de 2019 Microsoft dio la noticia de una nueva opción para esta, llamada Grupos de Instancias, nos lo apuntamos en la lista “Esto tenemos que probarlo cuanto antes”.

Como en la consultoria el tiempo es un bien preciado y escaso, ese “cuantos antes” de mi frase anterior ha ocurrido 4 meses después, dicho esto, ¡Empecemos!

El primer concepto a tener claro antes de hablar de Grupos de Instancias (o Instance Pools) es saber lo que es una Instancia Administrada (o Managed Instance), para eso os dejo la entrada que hicimos en el blog unos meses atrás Cómo instalar Managed Instance en Azure.

¿Qué son los Grupos de Instancias?

Es una nueva opción de implementación de Managed Instance en versión preliminar destinada a poder migrar instancias SQL Server pequeñas, entornos de Desarrollo o Pruebas que antes hubieran requerido el aprovisionamiento de una Managed Instance individual con un mayor número de núcleos virtuales.

Poniendo un ejemplo, podemos crear un Grupo de Instancias y aprovisionarlo con 8 núcleos virtuales para luego internamente dividirlo en varias Instancias Administradas más pequeñas, por ejemplo dos instancias de 2 núcleos virtuales y una instancia de 4 núcleos virtuales.

Las principales diferencias entre Grupos de Instancias y  Managed Instance individual son las siguientes:

  • Posibilidad de crear instancias de 2 núcleos virtuales.
  • Rapidez en la implementación de Instancias dentro del Grupo, hasta 5 minutos.
  • Asignación mínima de direcciones IP, al compartir la misma máquina virtual las direcciones IP reservadas son mucho menores que las que reserva una Managed Instance individual.

Es muy importante destacar que todas las Instancias creadas dentro de un Grupo de Instancias tienen las misma características y niveles de compatibilidad que una Managed Instance Individual.

Limitaciones actuales

Aunque a nivel de características y compatibilidad son idénticas a las Managed Instance individuales, si que hay algunas limitaciones en cuanto a los recursos:

  • Solo está disponible la implementación en Hardware Gen5.
  • El nivel de servicio (Uso general o crítico para la empresa) se elige a nivel de Grupo de Instancias, por lo que todas las instancias dentro del grupo tendrán el mismo nivel de servicio.
  • La CPU y la RAM son dedicadas dentro del grupo, por lo que la suma de los núcleos virtuales de nuestras instancias nunca podrá superar al total asignado al Grupo de Instancias.
  • Comparte las mismas limitaciones a nivel de instancia que una Managed Instance individual.
  • Además de los límites a nivel de instancia, existen límites a nivel de Grupo de Instancias:
    • Tamaño de almacenamiento total por grupo de 8Tb.
    • Máximo de 100 bases de datos por grupo.
  • Puedes aprovisionar grupos de instancias con los siguientes núcleos virtuales: 8, 16, 24, 32, 40, 64 y 80.
  • Puedes aprovisionar instancias administradas dentro de los grupos con los siguientes núcleos virtuales: 2, 4, 8, 16, 24, 32, 40, 64 y 80.
  • Todos los tamaños de instancias administradas dentro de los grupos admiten almacenamiento entre 32Gb y 8Tb con dos excepciones:
    • Las instancias de 2 núcleos virtuales tienen un almacenamiento máximo de 640Gb.
    • Las instancias de 4 núcleos virtuales tienen un almacenamiento máximo de 2Tb.

Limitaciones de la versión preliminar

Además de estas limitaciones, durante la versión preliminar y hasta que salga la versión final en Azure, hay unas cuantas limitaciones adicionales:

  • Solo se puede usar el nivel de servicio Uso General.
  • La escalación de los grupos de instancias no está permitida.
  • No hay compatibilidad con Azure Portal por lo que toda la creación hay que realizarla con PowerShell.
  • No se puede mover una Managed Instance individual a un Grupo de Instancias, ni tampoco transformar una Instancia creada dentro de un grupo en una Managed Instance individual.
  • Los precios para instancias reservadas no están disponibles.

Consideraciones y Opinión

Es importante considerar que aunque la RAM y los núcleos virtuales son dedicados, el disco local (para tempdb) y los recursos de red son compartidos, por lo que si varias instancias dentro del grupo tienen un consumo elevado puede que esto llegue a afectar a las otras, en este caso la solución sería escalar el grupo o mover esas instancias a Managed Instance individuales.

En mi opinión, esta nueva opción viene a cubrir un hueco existente cuando te planteabas migrar una Instancia SQL Server pequeña o cuando necesitabas un entorno pequeño para realizar pruebas.

También espero que cuando la versión final llegue a Azure permita una mayor configuración de la distribución interna de los núcleos virtuales, sería fantástico poder aprovisionar un Grupo de Instancias de 16 núcleos virtuales en el que 12 o 14 núcleos fueran para la instancia de producción y el restante para una segunda instancia de pruebas o desarrollo. Esta posibilidad extra de configuración sería un factor diferencial clave a la hora de elegir entre Grupo de Instancias o Managed Instance individual.

Si queréis saber más sobre los Grupos de Instancias, la próxima entrada del blog abordará la creación de esta mediante Powershell.

Serie Instance Pool:

  1. Conociendo los Grupos de Instancias, un nuevo Recurso de Azure SQL Database
  2. Creando los Grupos de Instancias, un nuevo Recurso de Azure SQL Database

Si estás planteando llevar tu plataforma a la nube nosotros contamos con la experiencia necesaria para ayudarte, contacta con nosotros en info@aleson-itc.com o llámanos al +34 962 681 242

Recommended Posts

Leave a Comment

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.