La migración de una instancia local de SQL Server a una máquina virtual (VM) de Azure es un método común para migrar a Azure. Los profesionales de TI están familiarizados con el alcance del tamaño de las máquinas virtuales con respecto a la CPU virtual, la memoria y la capacidad de almacenamiento. Microsoft ofrece varios tipos y tamaños de máquinas virtuales para las necesidades de una organización. Verá los tipos a los que se hace referencia como Family en Azure Portal al dimensionar una máquina virtual.
Tipos y tamaños de máquinas virtuales
Microsoft ha ayudado a simplificar las cosas mediante la creación de varios tipos de máquinas virtuales. Los tipos están orientados a definir las máquinas por propósito. Los distintos tipos son:
- Propósito general:relación CPU-memoria equilibrada, bases de datos pequeñas a medianas
- Optimización informática:alta proporción de CPU a memoria, servidores web y servidores de aplicaciones de tráfico medio
- Memoria optimizada:alta proporción de memoria a CPU, servidores de bases de datos relacionales, cachés medianos a grandes y análisis en memoria
- Almacenamiento optimizado:alto rendimiento de disco y E/S
- GPU:renderizado de gráficos y edición de video pesados
- Cómputo de alto rendimiento:las máquinas virtuales de CPU más rápidas y potentes
Dentro de cada tipo/familia hay numerosos tamaños para elegir. Los tamaños le ofrecen opciones para la cantidad de vCPU, RAM y discos de datos. La cantidad de discos de datos determinará el máximo de IOPS (IOPS significa operaciones de entrada/salida por segundo) y el tamaño total determinará la cantidad de almacenamiento temporal disponible. Ciertos tamaños también admiten almacenamiento premium, lo que debería ser un requisito para un SQL Server de producción.
Opciones de imagen de máquina virtual
Al seleccionar una imagen para SQL Server, tiene varias opciones. Puede elegir seleccionar solo el sistema operativo, como Linux o Windows, o puede elegir seleccionar una imagen con el sistema operativo y SQL Server ya instalados. Actualmente, prefiero elegir la imagen con solo el sistema operativo para poder instalar SQL Server y configurarlo como me gusta. Cuando elige la imagen de la galería con SQL Server preinstalado, se instalan todos los componentes que se incluyen en la ISO para esa versión, y no siempre necesito que Integration Services o Analysis Services estén instalados.
Consideraciones sobre el tamaño de la máquina virtual
Seleccionar una máquina virtual de Azure puede parecer sencillo, con la elección de un tamaño en función de la cantidad de vCPU, la memoria y el almacenamiento suficiente para albergar sus bases de datos; sin embargo, veo que los clientes tienen problemas de rendimiento relacionados con el almacenamiento. La tendencia común es elegir una VM basada exclusivamente en vCPU, memoria y capacidad de almacenamiento sin evaluar comparativamente los requisitos actuales de rendimiento e I/O. Cuando crea una máquina virtual de Azure en Azure Portal, puede filtrar las opciones según lo siguiente:
- Tamaño
- Generación
- Familia
- RAM/memoria
- Soporte de almacenamiento premium
- Número de vCPU
- Disco de sistema operativo efímero
Una vez que seleccione sus opciones de filtro, si las hay, verá una lista de servidores disponibles. En la lista, muestra el tamaño de la máquina virtual, la oferta, la familia, la vCPU, la RAM, la cantidad de discos de datos admitidos, el máximo de IOPS, el almacenamiento temporal (D:), si se admite el disco premium y el costo estimado. He filtrado lo siguiente en disco premium compatible y tamaño que comienza con la letra E para optimizar la memoria.
Sin embargo, lo que no se muestra es la cantidad de rendimiento permitido por máquina virtual. El rendimiento mide la tasa de transferencia de datos hacia y desde los medios de almacenamiento en megabytes por segundo.
El rendimiento se puede calcular usando la siguiente fórmula
MB/s =IOPS * KB por E/S / 1024
Usando esta fórmula, KB por IO sería el tamaño de su bloque. Si está formateando sus datos y unidades de registro a 64k, la fórmula para las máquinas virtuales E2s_v3, E4-2s_v3 y E8-2s_v3 con 3200, 6400 y 12 800 IOPS sería:
MB/s =3200 * 64/1024 o 200 MB/s
MB/s =6400 * 64/1024 o 400 MB/s
MB/s =12800 * 64/1024 o 800 MB/s
Los cálculos de rendimiento basados en las IOPS de cada máquina virtual con un tamaño de bloque de 64k no son tan malos. Estos números no tienen en cuenta ninguna penalización de escritura para RAID. Puse a prueba cada una de estas máquinas virtuales con CrystalDiskMark. Los números que obtuve para el rendimiento no estaban ni cerca de lo que estimaban los cálculos.
Prueba comparativa
Aprovisioné tres máquinas virtuales de la misma familia, sin embargo de diferentes tamaños, y cada una con 2 vCPU. Las especificaciones de las máquinas virtuales fueron:
- E2s_v3 – 2 vCPU – 16 GB de RAM – 3200 IOPS – Admite hasta 4 discos de datos
- E4-2s_v3 – 2 vCPU – 32 GB de RAM – 6400 IOPS – Admite hasta 8 discos de datos
- E8-2s_v3:2 CPU virtuales, 64 GB de RAM, 12 800 IOPS:admite hasta 16 discos de datos
- Disco de datos P60:SSD Premium:16 000 IOPS
En cada máquina virtual, aprovisioné un disco premium P60 con una capacidad de 8 TB. Este disco anunciaba 16 000 IOPS que, con un tamaño de bloque de 64 000, podría admitir un rendimiento de 1000 MBps; sin embargo, la documentación de Azure indica que el disco proporciona un rendimiento de 500 MBps.
CrystalDiskMark es una herramienta de evaluación comparativa de unidades de disco de código abierto para Windows y se basa en la herramienta Diskspd de Microsoft. La herramienta mide el rendimiento secuencial y aleatorio de lecturas y escrituras.
En la parte superior de la herramienta hay algunos menús desplegables. El número 5 es el número de iteraciones de la prueba que se ejecutará. El siguiente es 1GiB, este es el tamaño del archivo de prueba. Para una prueba de producción real, esto debería ser lo suficientemente grande como para ayudar a evitar acceder a la memoria caché. La versión 7.0 admite un archivo de hasta 64 GiB. La última es la unidad en la que desea realizar la prueba.
Una vez que haya hecho su selección, puede hacer clic en Todo para comenzar la serie de pruebas. La prueba recorrerá varias operaciones de lectura/escritura secuenciales y aleatorias. Tenga cuidado si planea comparar servidores de producción reales. Esta prueba pone una carga en su disco y podría afectar drásticamente una carga de trabajo de producción. Sería preferible fuera del horario de atención o durante una ventana de mantenimiento.
Opté por ejecutar 5 iteraciones de la prueba con un archivo de 32 GiB en el disco P60 que era la unidad E:.
La máquina virtual E2s_v3 alcanzó un máximo de 50 MBps, que es mucho menos que los 200 MB que calculamos.
La máquina virtual E4-2s_v3 alcanzó un máximo de 100 MBps en lugar de 400 MBps.
La máquina virtual E8-2s_v3 alcanzó un máximo de 200 MBps en lugar de los 800 MBps estimados.
¿Por qué reducir el rendimiento?
Según mis cálculos anteriores, 3200 IOPS en un tamaño de bloque de 64k deberían producir un rendimiento de 200 MB, pero no vi números cercanos a eso hasta que tuve un disco de 16 000 IOPS en una máquina virtual que admite hasta 12 800 IOPS. El razonamiento es que cada tamaño de máquina virtual tiene un límite de rendimiento. Si consulta la documentación de la familia de máquinas virtuales optimizadas para memoria, encontrará que el rendimiento máximo del disco sin caché de E2s es de 3200 IOPS/48 MBps, el rendimiento máximo del disco sin caché de E4s es de 6400 IOPS/96 MBps y el rendimiento máximo del disco sin caché de E8s el rendimiento es de 12 800 IOPS/192 MBps. Estos números coinciden con los resultados que obtuve usando CrystalDiskMark.
Aunque puede asignar discos muy grandes que tengan muchas IOPS y que admitan números de alto rendimiento, el tamaño de la VM podría muy bien estar limitando su rendimiento.
La evaluación comparativa de sus necesidades de rendimiento actuales debe ser una gran prioridad antes de migrar cualquier carga de trabajo de SQL Server a Azure.
Conclusión
Entiendo que IOPS es una unidad de medida que proporcionan los fabricantes de discos y los proveedores de almacenamiento, y eso está bien. Sin embargo, cuando se trata de probar el almacenamiento, tendemos a centrarnos más en las cifras de rendimiento. Es solo un problema matemático, pero a menos que esté en el negocio de comparar el almacenamiento y hacer los cálculos de IOPS al rendimiento en función del tamaño del bloque, puede resultar confuso.
Lo que me preocupa es el hecho de que la restricción en el rendimiento no está clara cuando selecciona un tamaño de máquina virtual. La unidad de medida para almacenamiento IO es IOPS. A 3200 IOPS con un tamaño de bloque de 64k, podría tener alrededor de 200 MBps, sin embargo, mi máquina virtual estaba limitada a 48 MBps. Muchos profesionales de TI han descubierto que tienen problemas de rendimiento del disco y escalaron su almacenamiento a un disco más grande y más rápido (más IOPS) esperando un mejor rendimiento, solo para descubrir que no resolvió su problema. El problema es que el tamaño de la máquina virtual limitaba su rendimiento. Escalar a una máquina virtual de mayor tamaño resolvería el problema, pero eso tiene un costo. En mi ejemplo, el E4 costaba el doble que el E2, sin embargo, duplicó la memoria y el rendimiento, al mismo tiempo que retuvo la misma vCPU. El E8 costaba el doble que el E4 y duplicaba el rendimiento y la memoria, al tiempo que conservaba la misma vCPU. Mantener el mismo recuento de vCPU significa que no tendría un aumento en el costo de la licencia de SQL Server central.
En última instancia, debe comparar sus requisitos de rendimiento actuales y asegurarse de dimensionar la máquina virtual de Azure o cualquier máquina virtual de manera adecuada para sus necesidades. No se centre solo en un punto de referencia de su almacenamiento local, analice lo que su carga de trabajo necesita y dimensione en consecuencia.
