Windows Azure Pack es una solución fabulosa para obtener un subconjunto de las funcionalidades disponibles con Azure, en nuestra propia infraestructura. Todo ello apoyado por cosas como Windows Server 2012 R2 y System Center 2012 R2.
Como sería de esperar, en una solución de estas, el “paquete” viene bastante rellenito con multitud de funcionalidades y posibilidades, que no siempre se ven a golpe de click.
Una de las cosas que llaman la atención tras implementar Windows Azure Pack, es que disponemos de 2 formas posibles para el despliegue de máquinas virtuales, lo que vulgarmente se llama IaaS (Infraestructura como servicio) en el idioma de la nube.
Las máquinas virtuales pueden ser “Máquinas virtuales independientes” (Standalone), lo que viene siendo lo mismo que una plantilla de máquina virtual de Virtual Machine Manager, o VM Roles, esta última opción combina las posibilidades del motor de plantillas de VMM con un asistente personalizable de despliegue, resultando en un proceso de creación de máquinas virtuales mucho más rico y lleno de opciones.
Hasta aquí todo es bonito, o eso parece, pero como se dice en mi “pueblo”: Não há bela sem senão.
Una de las características de los VM Roles es el uso de discos diferenciales en la generación de las máquinas virtuales. La idea por detrás de esta opción de diseño consiste en que, ese disco padre (VHD o VHDX) se copia desde la biblioteca de VMM, una sola vez por cada uno de los hosts de Hyper-V en los que se despliega ese “servicio”. VMM va guardando las rutas de estas copias realizadas en cada uno de los nodos de computación durante el primer despliegue y, esto en teoría, acelera no solo el proceso de creación, como también los procesos de escalado, ya que los VM Roles, al contrario de las máquinas independientes, permiten ser escalados a varias instancias similares.
Como desventaja, el uso de los discos diferenciales, hace que muuuuchas máquinas virtuales dependan de un único disco, por lo que si hay un problema con la unidad donde se almacena ese disco (copia de la biblioteca de VMM)… Adivina adivinanza… Pues eso, suicidio en masa de vuestras VMs.
Además, la gestión de estos intrincados de discos padre y discos diferenciales suele ser bastante compleja.
Por otro lado, en un plan más técnico, esta solución también requiere almacenamiento com unas características algo distintas, una vez que ese disco padre, es donde acaban todas las lecturas de las VMs para aquellos sectores que no han cambiado y que se mantienen iguales en todas ellas a lo largo del tiempo, es decir, normalmente el SO, y más concretamente las partes que no sufren actualizaciones.
Con o sin diferencias…
En entornos donde prima la alta disponibilidad esto puede ser un problema y gordo, así que, con el Update Rollup 5 de System Center Virtual Machine Manager 2012 R2 , Microsoft incorporó la posibilidad de modificar este comportamiento para que los despliegues de VM Roles puedan usar discos dedicados, y dotar a nuestra instancias virtuales de alguna independencia, incrementando su fiabilidad.
Esta configuración se implementa mediante una propiedad de “Cloud”, como se indica a continuación:
1. Abrir las propiedades de nuestra “Cloud” en la consola de VMM.
2. Ir al apartado de Custom Properties y pulsar el botón Manage Custom Properties.
3. Elegir como tipo de objeto Cloud y crear una nueva propiedad con el nombre DifferencingDiskOptimizationSupported.
4. Añadir la nueva propiedad a la lista de Assigned Properties y pulsar Ok.
5. En el valor de esta propiedad introducir el valor false y pulsar Ok.
Consola VMM – Dialogo de gestión de propiedades
Una vez realizada esta configuración, todos los VM Roles empezarán a ser creados con discos dedicados. Ahora eso sí, los que ya se habían desplegado previamente mantendrán sus discos diferenciales y su dependencia del disco padre, por lo tanto cuidado con esos borrados.
Si aun así no os queda claro, solo me queda a que juguéis al “Encuentra las diferencias” con la imagen de abajo. 
Consolas de VMM – Custom Properties
¿Qué bonito es mi nuevo Windows Azure Pack?
Peero, pero… ¿Y por qué las máquinas virtuales no se despliegan en alta disponibilidad?
Esta será seguramente una de las primeras preguntas que os hagáis al ver que vuestro primer despliegue de un VM Role, en Windows Azure Pack, no genera un rol de clúster, o sea que se queda en una máquina virtual normal y corriente sin alta disponibilidad.
La pregunta que viene a continuación es: ¿Qué he hecho mal?
Bueno, realmente mal, nada, pero se os ha escapado una configuración que habilita esta posibilidad. Es muy fácil que se os escape esto, porque está documentado en una guía de diagnóstico de problemas en medio de una serie de cosas. Vamos, algo que encontramos si sabemos exactamente lo que vamos buscando. Ya, ya lo sé, no tiene demasiado sentido, pero así es la vida.
VM Role en alta disponibilidad
Para habilitar el despliegue de VM Roles en alta disponibilidad solo tenemos que configurar una propiedad en la definición de nuestra “Cloud”, y esto lo podemos hacer o bien mediante la consola de VMM, o bien mediante PowerShell.
A través de la consola de VMM el proceso es el siguiente:
1. Abrir las propiedades de nuestra “Cloud”.
2. Ir al apartado de Custom Properties y pulsar el botón Manage Custom Properties.
3. Elegir como tipo de objeto Cloud y crear una nueva propiedad con el nombre CreateHighlyAvailableVmRoles.
4. Añadir la nueva propiedad a la lista de Assigned Properties y pulsar Ok.
5. En el valor de esta propiedad introducir el valor true y pulsar Ok.
Consola de VMM – Custom Properties
Si por otro lado lo que buscáis es un poco de aventura, podéis atreveros con PowerShell, tal y como se describe en la página de TechNet que os comenté antes: Deploy a highly available VM Role
¡Olé! A disfrutar de vuestros VM Roles en cluster.
😉
¿Por dónde empiezo?
Ahora que hemos sentado las bases de las plataformas de nube, en la Parte 0 de esta serie, publicada hace ya algún tiempo, es hora de remangarse un poco y empezar a crear cosas en Azure.
Hay algunos elementos que debemos preparar antes de crear nuestra primera máquina virtual, pero como veréis no es nada complicado, y de esta forma empezaremos con un entorno ordenadito que no nos traerá problemas en cuanto empecemos a crecer en la nube.
Grupo de afinidad
El primer concepto que quiero introducir hoy es el de “grupo de afinidad”, este debe ser el primer elemento que creamos en nuestra suscripción de Azure y el que sirve de base a todo lo demás.
El grupo de afinidad tiene dos funciones realmente, una a nivel lógico y otra a nivel más físico, relacionada con la asignación de recursos.
A nivel lógico, los grupos de afinidad permiten agrupar recursos de procesamiento y almacenamiento que tienen una relación entre ellos, por ejemplo, el almacenamiento (VHD) que usa una determinada máquina virtual. En una perspectiva un poco más amplia, podemos considerar también un conjunto de máquinas virtuales relacionadas entre ellas, o que comparten alguna característica común, por ejemplo los recursos asignados a un departamento, u organización, en el caso de que gestionemos varias entidades desde una misma suscripción.
Esta sería la parte lógica que nos ayuda a tener la casa ordenada desde el punto de vista del administrador de recursos en la nube. Por otra parte, el grupo de afinidad tiene también unas implicaciones físicas en lo que toca a la asignación y consumo de recursos, como hemos comentado anteriormente.
Los aspectos principales que los grupos de afinidad nos permiten controlar a nivel físico son el rendimiento y los costes. Un grupo de afinidad está asociado a un determinado CPD de Azure, pero como todos sabemos, en Azure los CPDs están constituidos por contenedores con clusters y racks (cada contenedor se encarga de una serie de servicios concretos de la plataforma), por lo que es interesante tener un poquito más de control sobre la colocación de los elementos de nuestra plataforma dentro del mismo.
Por exagerar un poco el ejemplo para que quede del todo claro, seguro que a ninguno se nos ocurriría crear el almacenamiento de una máquina virtual en el CPD de Chicago y ejecutar la máquina virtual en el CPD de Ámsterdam (aunque quisiéramos no sería posible, pero para que se entienda el concepto). Esto generaría una latencia tremenda perjudicando el rendimiento, además de los costes a nivel de comunicaciones, una vez que en Azure se facturan los datos enviados fuera del CPD.
Al colocar los recursos dentro del mismo grupo de afinidad, no solo estamos agrupándolos en términos lógicos pero también le estamos diciendo a Azure que esos recursos deben colocarse los más próximo posible dentro del CPD, si posible en el mismo cluster o contenedor. Esto reduce la latencia y optimiza el rendimiento del entorno.
La creación del grupo de afinidad es bastante sencilla, solo tenemos que darle un nombre, una descripción (opcional), la suscripción asociada e indicar en que CPD de Azure va a “vivir” este grupo de afinidad. Una vez hecho esto, estamos listos para crear los recursos asociados al grupo de afinidad y Azure se encargará del resto.
Creación de grupo de afinidad en Azure
De momento esta opción solo está disponible a través del portal “antiguo” de Azure, el que se encuentra en producción. El nuevo portal está en Preview por lo que es de esperar que, poco a poco, todo vaya encontrando su lugar allí también. La creación del grupo de afiniddad se realiza entrando a Configuración –> Grupos de Afinidad.
Grupos de afinidad en el portal de Azure
Este fue el primer paso en nuestro viaje hacía la nube, en los proximo pasos nos iremos acercando a nuestro objetivo a través del almacenamiento y la red. Espero que disfrutéis del viaje tanto como yo.
Entradas relacionadas:
Una cosa que me tiene muy entretenido en los últimos tiempos, y por lo visto seguirá manteniendo por bastante tiempo más, es la plataforma de servicios en la nube Windows Azure. O mejor.. ¡Microsoft Azure!
Esto es así porque, a finales del año pasado embarqué en un proyecto que, de entre los requisitos fundamentales para funcionar, tenía esta bonita declaración de intenciones:
“La empresa funcionará sin servidores on-premise, los únicos equipos permitidos en una oficina serán impresoras y electrónica de red. Además, todos los costes de infraestructura servidora tienen que seguir un modelo de costes OPEX”
Suena muy bien, y es muy bonito así en el papel, peeeero esto nos lleva a cuestionar una serie de cosas relacionadas con la nube, fuerte candidata a dar solución a estos escenarios:
- ¿Será posible obtener toda la funcionalidad deseada?
- ¿Qué modelos son los más adecuados para cada componente?
- ¿Realmente, está la tecnología preparada para tan arriesgado escenario?
Está claro, había que estudiar la viabilidad del proyecto, y luego encontrar la forma de implementarlo, claro. En esta serie de posts De “nada” a la “nube” en 0, os cuento mis penas y éxitos en este intento, que ha ido ocupando los minutos de mi vida, extra laboral, durante estos últimos tiempos. Espero que sirvan para hacer más fácil la vida a los que tengáis que pasar por lo mismo.
Antes de conectarnos al portal de Azure y empezar a crear cosas a lo loco, que al final nos pueden costar una que otra marcha atrás, refresquemos algunos conceptos de las plataformas de nube. Probablemente estéis ya familiarizados con algunas de las cosas que hablaremos a continuación, sobre todo si le habéis dedicado algo de tiempo a “la nube”. De todas formas, no está demás clarificar estos conceptos y establecer una base común.
Empecemos con una definición, lo más estándar posible, de los conceptos que caracterizan las plataformas de nube. Os recomiendo la definición del NIST, una vez que, al contrario de muchas definiciones presentadas por algunos fabricantes, es lo más neutral posible y evita que acabemos mezclando churras con merinas.
Definición de Cloud Computing del NIST: http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
Cuando intentamos describir y clasificar las plataformas de nube, nos referimos a características, modelos de servicio y modelos de despliegue.
- Características: corresponden a los requisitos que una determinada plataforma tiene que cumplir para que se considere una plataforma de nube.
- Modelos de servicio: tienen en cuenta, sobre todo, el equilibrio entre los componentes del modelo computacional, proporcionados por el proveedor y los gestionados, o controlados, por el cliente.
- Modelos de despliegue: son una clasificación de las plataformas según el uso que se hace de los recursos y por parte de quién.
Sin ánimo de quitar importancia a los modelos de despliegue y características de las plataformas de nube, en este post nos centraremos en los modelos de servicio. Azure es una plataforma que está presente en todos ellos y esto es importante desde el punto de vista de un arquitecto IT, porque permite crear soluciones que usen distintos componentes, disponibles a través de los varios modelos, de forma muy integrada. Estamos hablando, lógicamente de los conceptos de SaaS, PaaS e IaaS, o lo que es lo mismo Software como Servicio, Plataforma como Servicio e Infraestructura como Servicio.
Dentro de los modelos de servicio nos encontramos con las siguientes clasificaciones, cada una de ellas describiendo un tipo de solución enfocada a un perfil distinto.
-
Software como Servicio (SaaS): El proveedor proporciona al cliente aplicaciones terminadas que se ejecutan en su infraestructura de nube. Normalmente estas aplicaciones están accesibles desde múltiples dispositivos, mediante el uso de plataformas web y/o interfaces nativas creadas para un sistema en concreto. En este caso el cliente no necesita gestionar ninguno de los componentes de la infraestructura, preocupándose solamente con las configuraciones de la propia aplicación y sus datos.
-
Plataforma como Servicio (PaaS): La funcionalidad proporcionada al cliente consiste en una plataforma con soporte para lenguajes de programación, herramientas y servicios, sobre los cuales se ejecutan las aplicaciones desplegadas, ya sean desarrollos propios o adquiridos a terceros, construidos para esos componentes específicos. El cliente se encarga de la aplicación (código y todos los componentes empleados durante su desarrollo), sus datos y las configuraciones del entorno en el que está alojada, dejando al proveedor toda la administración de la infraestructura que la soporta (servidores, almacenamiento, red, etc.).
-
Infraestructura como Servicio (IaaS): En este modelo se proporciona al cliente capacidad de procesamiento, almacenamiento, redes y otros recursos computacionales, para que este pueda ejecutar sus servidores y aplicaciones. Normalmente estas plataformas van asociadas con plataformas de virtualización, donde el proveedor se encarga de los componentes físicos y de la capa de virtualización, dejando el control de los sistemas operativos y demás componentes tecnológicos en manos del cliente.
Modelos de servicio y perfiles típicos a los que corresponden
A lo largo de los varios artículos que compondrán la serie, me centraré más en la parte de Infraestructura (IaaS), aunque eso no implica que no haga alguna incursión por el resto de modelos de servicio, al final a todos nos toca quitarnos la gorra de ITero de vez en cuando.
Podemos decir que esta ha sido la Parte 0 de esta serie, el artículo que pretendía ser apenas una Introducción y con el que establecíamos unas bases de las plataformas de nube. Ahora que todos estamos en la misma página, ya podré preparar algo sobre el punto de partida en el viaje a Azure. En breve llegará la Parte 1 – ¿Por dónde empiezo? aquí al TecnoChiringuito, mientras tanto nos tomamos otra a vuestra salud.
Entradas relacionadas:
