A modo de introducción, en la actualidad tenemos las siguientes familias de máquinas virtuales en Azure:
Así pues, tenemos muchas opciones para elegir, pero no todas ellas están disponibles para cada aplicación. Vamos con recomendaciones a aplicar.
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:
Estas acciones nos ayudarán a decidir por una de estas dos estrategias:
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.
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:
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.
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:
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 🙂
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!
Este sitio web utiliza cookies para que tengas la mejor experiencia de usuario. Si continuas navegando, estás dando tu consentimiento para aceptar las cookies y también nuestra política de cookies (esperemos que no te empaches con tanta cookie 😊)
