Uno de los principales caballos de batalla ante la decisión de irse a la nube es siempre la parte económica. Es por ello que saber algunos pequeños trucos o recomendaciones a la hora de elegir qué máquinas escoger para llevar un sistema a la nube, o para implementar nuevos sistemas, pueden tener un gran impacto en la satisfacción de la decisión tomada, y en los resultados obtenidos. Menos es más… ¡Literalmente!
A modo de introducción, en la actualidad tenemos las siguientes familias de máquinas virtuales en Azure:
- Máquinas Tipo A: Son las primeras máquinas que Microsoft lanzó al mercado, basadas en almacenamiento estándar, y procesadores básicos. Cabe destacar que se pueden tener en capa básica o estándar, siendo las primeras mejores para uso en pruebas y entornos monomáquina.
- Máquinas Tipo D: están diseñadas para ejecutar aplicaciones que exigen mayor capacidad de proceso y rendimiento de disco temporal. Las máquinas virtuales de la serie D proporcionan procesadores más rápidos, una mayor proporción de memoria a núcleo y una unidad de estado sólido (SSD) para el disco temporal.
- Máquinas Tipo D v2 : Basadas en las máquinas originales D, están basadas en procesadores de la serie haskell, y son un 35% más rápidas con un coste muy similar (en torno a un 10% más caras, pero no en todos los casos).
- Maquinas Tipo G: Máquinas enfocadas a trabajo masivo, con grandes cargas y entornos exigentes. Están basadas en procesadores Xeon E5.
- Máquinas DS y GS: Estas maquinas son equivalentes a sus versiones estándar, pero con capacidad para utilizar Azure Premium Storage… más sobre esto más adelante.
Así pues, tenemos muchas opciones para elegir, pero no todas ellas están disponibles para cada aplicación. Vamos con recomendaciones a aplicar.
Empezar por lo sencillo
A la hora de decidir por la infraestructura en Iaas (aunque muchas de estas recomendaciones se pueden extender a su uso en Paas) conviene tener clara los requisitos principales de nuestra aplicación. En particular:
- Si es una aplicación que se puede extender de forma automática. Por ejemplo, un SharePoint no se podrá escalar de forma automática pero una aplicación .Net MVC debería poder escalarse de forma automática sin problemas
- Los requisitos de E/S que puede requerir. Esto nos marcará el nivel mínimo de máquina a utilizar (A1.. A7, etc)
- Requisitos particulares. Por ejemplo, no se recomienda montar SQL con menos de 4/8 nucleos
- Nº de usuarios y variabilidad de acceso
Estas acciones nos ayudarán a decidir por una de estas dos estrategias:
- Pocas máquinas de mucha potencia
- Muchas máquinas de poca potencia
En los casos en los que la máquina tenga acceso por muchos usuarios, y con gran variabilidad, la mejor opción de cara al coste, será el disponer de máquinas pequeñas que se puedan escalar mediante scale-out (añadir máquinas a la granja) de forma automática.
En los casos en los que la aplicación no se puede escalar de forma automática (por ejemplo, un SharePoint) se debería planificar la potencia suficiente (nº máquinas por potencia unitaria) para dar cobertura al 90% del rendimiento requerido, aceptando de esta forma que ante picos no contemplados el rendimiento pueda sufrir cierta degradación. En este caso, es recomendable establecer políticas de scale-up (añadir potencia a las máquinas) cuando sea posible, y conocer el comportamiento específico de la aplicación a montar. En el caso específico de SharePoint es posible montar diferentes tipos de máquinas según el rol a desempeñar en la granja. Por ejemplo: Máquinas Dv2 como frontales, D como Backend, DS pequeñas como Cacheado, y GS bajas como SQLs. De esta forma es posible aprovechar lo mejor de cada familia en cada punto, manteniendo un coste bajo.
Como norma general a aplicar siempre en azure es que el tamaño superior siempre dobla el precio del inferior. Así pues, una máquina de tipo A4 dobla el coste de un A3, y es la mitad de un A5.
E/S de Disco… ese gran desconocido
Por norma general, pocas organizaciones realizan un control de la Entrada/Salida de disco de sus aplicaciones, siendo por lo general este parámetro, junto con la memoria, los cuellos de botella habituales en sistemas. Por lo general, una memoria pequeña, y una E/S pobre en disco (discos antiguos, etc) es una receta para el desastre. El disponer de memoria insuficiente genera mucho paginado y frecuentes volcados a disco, lo que genera más sobrecarga sobre un disco que en condiciones normales ya está al límite de rendimiento.
Para evitar esto, es necesario jugar con la relación entre la E/S de disco, y la memoria. En el caso de las máquinas de Azure, habitualmente tenemos dos subfamilias dentro de la principal. Por ejemplo, dentro de la familia D, tenemos (eliminando D1 y D14. Coste calculando 722 h/mes)
Es decir, para doblar la memoria, el coste es un 30% superior a la máquina similar, disponiendo de la misma E/S.
Para contar con potencias similares, buscando en otras familias (cogemos D4 como ejemplo)
Como la E/S se calcula a un máximo de 500 IOPS por unidad de disco, en todas las máquinas menos en la DS el tope serían 8000 IOPS. En cambio, en la DS, podríamos optar por hasta 16 unidades de Premium Storage, que nos daría un total de 80.000 IOPS usando P3 (1 Tb por unidad, 5.000 IOPS…), y suponiendo que esta máquina tenga suficiente ancho de banda para discos como para soportar estos números.
Así pues, podemos extraer de estos sencillos números, las siguientes lecciones:
- La serie que a priori tiene mejor relación rendimiento/coste es, a día de hoy, la serie D.
- Siempre que sea posible utilizar máquinas de las series DS o GS, para poder ampliar el rendimiento de E/S de disco.
- Para requisitos específicos de gran potencia, es recomendable mirar las máquinas de tipo G, y las máquinas A8-A9-A10-A11.
Las únicas máquinas que incorporan un segundo adaptador de red para aplicaciones que requieran conectividad entre máquinas muy rápida (clusters, etc) son A8 y A9. A10 y A11 están enfocadas a aplicaciones con un uso intensivo de memoria y disco.
Un truco adicional: cuando vamos a provisionar una nueva subscripción, es recomendable que la primera máquina que creemos sea una DS o una Dv2. De esta manera nos aseguramos que nuestra subscripción vaya a parar a un módulo con capacidades de Storage Premium y no tendremos problemas en el futuro a la hora de contar con estos recursos. Una vez creada, se puede borrar y crear máquinas de cualquier otro tipo.
Optimizar, optimizar y optimizar
Otro de los errores habituales es tener encendidos los sistemas en modo 24*7, sin considerar el uso real del sistema. En muchas ocasiones tenemos un sistema cuyo rendimiento estamos condicionando para mantener un coste contenido, sin considerar que el horario de uso habitual es de 8 de la mañana a 9-10 de la noche, dejándonos un gran tramo horario sin utilización prácticamente. ¿Realmente es necesario? Esta situación se puede atajar con varias estrategias:
- Apagados automático de las máquinas
- Escalado (Downgrade) automático según horas
Ambas estrategias son sencillas de implementar mediante el uso de Azure Automation Services. Lo que siempre será una gran herramienta para saber cómo funcionan nuestros sistemas será el uso de System Center, u Operations Manager, para detectar, diagnosticar y optimizar los cuellos de botella encontrados y los periodos en los que tenemos más “potencia” de la necesaria. Haciendo una analogía, es como si la mitad del tiempo tuviéramos en casa la tarifa más barata, y solo cuando encendemos la tele, ponemos el microondas para calentar la cena, y el horno con la comida del día siguiente pudiéramos saltar de forma automática a la tarifa necesaria para que no nos salten los plomos 🙂
Y por último
El mundo de Azure evoluciona casi en una forma diaria, por lo que en muchas ocasiones el contar con alguien especializado en el diseño de implementaciones y migraciones a entornos híbridos y Cloud representa un ahorro desde el primer mes, en el que la optimización y la elección adecuada de máquina en función de los sistemas implementados pueden representar un gran ahorro en la operación de grandes parques.
Si necesitas ayuda para mantener una nube sostenible… ¡Cuenta con nosotros!
¡Suscríbete a nuestras RRSS!
