[Articulo] Microsoft Azure | Gestión de Actualizaciones de Sistemas Operativos en IaaS y PaaS

En esta publicación vamos a conocer los detalles relacionados a la gestión de actualizaciones de software (a nivel sistema operativo) en Microsoft Azure, tanta para PaaS como para IaaS.

En relación a PaaS, Microsoft tiene una política y procedimientos documentados de cómo gestiona para sus servicios en la nube las actualizaciones en la familia de sistemas operativos y sus versiones. En el caso de IaaS la política no es tan rígida y gran parte del trabajo debe ser realizado por los administradores como si se tratase de una infraestructura on-premises.

Vamos a realizar una recorrida conceptual, al inicio de la publicación, para poder alinear conceptos que nos permitirán entender mejor cómo gestionar las actualizaciones en Microsoft Azure para las opciones de servicio antes mencionadas y no fallar en el intento.

¡Continuemos leyendo!

IMPORTANTE: El contenido de esta publicación, debido a la fecha de creación, podría contener algunos conceptos no vigentes o que han cambiado.

[toc]

Introducción

Objetivo y Alcance

Esta publicación tiene como objetivo conceptualizar aspectos base de Microsoft Azure en relación a infraestructura PaaS (Cloud Services / Web Apps) y IaaS (Virtual Machines), en pos de poder detallar cómo es el proceso de actualización de sistemas operativos para ambos métodos de entrega en la nube.

En relación al alcance, vamos a realizar un repaso en alto nivel de los conceptos fundamentales de Servicios en la Nube [Cloud Services], Aplicaciones Web [Web Apps] y Máquinas Virtuales [Virtual Machines], para luego explicar detalladamente y a bajo nivel (es decir, profundamente) cómo es la gestión de actualizaciones en Microsoft Azure para cada opción.

Audiencia

Este documento está dirigido a Consultores, Profesionales IT y personas que desarrollan tareas de Consultoría, Administración y Soporte o que simplemente están interesados en leer e investigar sobre la tecnología alcanzada por esta publicación.

Comentarios y Corrección de Errores

Hemos realizado nuestro mejor esfuerzo para no cometer errores, pero al fin y al cabo somos seres humanos. Si deseás reportar algún error o darnos feedback de qué te pareció esta publicación, por favor no dejes de comunicarte con nosotros a través de correo electrónico a la siguiente dirección: info@tectimes.net.

Desarrollo

Introducción de Contexto a Microsoft Azure

Breve Reseña de Azure desde una mirada de Infraestructura

Microsoft Azure es un entorno virtualizado que ejecuta una versión personalizada de la plataforma Hyper-V y Windows Server. Viendo a Microsoft Azure en su totalidad, es un complejo ecosistema que brinda diversos servicios, tanto IaaS (Infraestructura como Servicio), PaaS (Plataforma como Servicio) y SaaS (Software como Servicio).

Este complejo ecosistema también incluye un sistema de monitoreo y un sistema de auto-sanación:

• El primero (monitoreo) no solo es necesario para que los Ingenieros de Soporte puedan contar con información que les permita tomar decisiones proactivas, e inclusive al propio sistema. Hay un aspecto no menor en Microsoft Azure que es el cliente final, o sea nosotros los administradores y desarrolladores: Azure nos mantiene informados sobre su estado, e inclusive se brindan servicios de recuperación ante el caso de alguna falla. Todo esto, para que funcione como esperamos, debe estar delicadamente monitoreado y orquestado.
• El segundo aspecto que comentábamos (sistema de auto-sanación) conforma una avanzada solución que permite a Azure recuperarse automáticamente ante ciertas problemáticas. Por supuesto, un servidor no se va a poder recuperar por sí solo de una rotura de discos, o de roturas de fuentes de alimentación o de procesadores, en este sentido nos referimos más bien a auto-sanación de aspectos lógicos y de configuración.

Si no fuera por estos dos sistemas de vital importancia para el servicio, el mismo no podría escalar con la magnitud que lo está haciendo día a día. Imaginemos que no sabemos qué contenido, carga de trabajo ni cantidad de información los clientes van a alojar, y Microsoft Azure (como todo servicio de Computación en la Nube) es un servicio medido por hora de utilización, con una segmentación a veces menor en tiempo. Esto obliga, de una u otra forma, a tener que monitorear y guardar historial de uso que los clientes hacen sobre él, dado que al fin y al cabo será la facturación que Microsoft obtiene mes a mes.

Sistemas Operativos de Microsoft Azure

Microsoft Azure tiene servidores físicos, los cuales tienen un sistema operativo que se conoce como “huésped”. Este sistema operativo es el que se instala en el host físico y está mantenido en forma completa por los Ingenieros de Soporte de Microsoft.

Estos sistemas operativos son los responsables de administrar los recursos físicos de cada uno de los servidores de cada uno de los centros de datos en cada una de las regiones donde Azure tiene presencia para cada uno de sus servicios. A la vez, en dichos sistemas operativos se instala el agente de Azure que se comunica e interactúa con el Controlador de Fábrica (Azure Fabric Controller). La Fábrica es la responsable de supervisar y controlar grandes segmentos de los centros de datos, como también el cuándo y cómo se realizan implementaciones de máquinas virtuales o servicios.

Los sistemas operativos que despliegan cada una de las organizaciones que alquilan cómputo en Azure se conocen como sistemas operativos “invitado”. Estos sistemas operativos (Guest OSes) interactúan también con otros sistemas dentro del centro de datos, por ejemplo con Almacenamiento, Red, etc. Dicho Almacenamiento y Red también están virtualizados, y muchos de ellos se ejecutan a su vez sobre sistemas operativos mantenidos por los Ingenieros de Microsoft o equipamiento especializado.

Dado que Microsoft Azure es un sistema multitenant (también conocido como multi-empresa ó multi-inquilino), los sistemas operativos invitado no tienen comunicación entre sí ni tampoco con el sistema operativo huésped en forma directa.

Servicios en la Nube [Cloud Services / Web Apps]

Recordemos que cuando hablamos de Servicios en la Nube, nos referimos a la configuración de cómputo y memoria que nos permite ejecutar cargas de trabajo variadas y en diferentes lenguages de programación. Cuando hablamos específicamente de Servicios en la Nube (conocidos como “Cloud Services”) desde el cómputo, las máquinas virtuales que ejecutan los mismos tienen una instalación ligeramente modificada de Windows Server, optimizada para funcionar en este escenario de Azure.

Cuando un usuario crea un nuevo Servicio en la Nube, se puede controlar la versión de Windows Server que se implementará en dicho servicio a través de configuración. Específicamente esta opción se administrada por el archivo de configuración de servicios (*.cscfg) el cual tiene un atributo llamado “osFamily” y un atributo “OSVersion”:

• El atributo “osFamily”: con este atributo nos referimos a la familia de versiones de sistemas operativos, por ejemplo “Windows Server 2008 R2” o “Windows Server 2012”.
• El atributo “OSVersion”: aquí nos referimos a la versión de la familia de sistema operativo seleccionado, pero en términos de actualización, por ejemplo “Release 2” o “Release 3”.

Es importante comprender que cuando hablamos de “OSVersion” no nos referimos a versiones como normalmente estamos acostumbrados a hablar (Windows Server 2008 R2, Windows Server 2012, etc) sino que hablamos de un nivel de actualización (parches de seguridad y correcciones de errores). Vamos a ejemplificarlo para que quede más claro: si hablamos de Windows Server 2008 R2 SP2, la parte de “Windows Server 2008 R2” sería la familia (osFamily) y SP2 sería la versión (OSVersion).

Un poco más enfocados en el lenguaje de Azure, vamos a identificar que existe una notación para el manejo de familias y versiones de sistemas operativos que describiremos más adelante.

Por último, es importante entender que los atributos osFamily y OSVersion son ajustes que cubren a todos los roles dentro de un servicio en la nube, por lo cual no es posible configurar un rol web para funcionar con Windows Server 2008 R2 y tener otro rol de servicio ejecutando Windows Server 2012 en el mismo despliegue (mismo Cloud Service). Si esto sucede, solo es en escenarios de actualización y tiene una duración muy breve, que es el tiempo que se tarda en actualizar todas las instancias dentro del mismo despliegue.

Máquinas Virtuales [Virtual Machines]

Si hablamos de máquinas virtuales en un escenario IaaS, durante su creación se puede seleccionar diferentes versiones de Windows Server e inclusive de Linux. Por supuesto, y como todos los servicios IaaS, el usuario es el responsable de mantener y actualizar el sistema operativo invitado (Guest).

Aquí el concepto de familia y versión que vimos para Cloud Services es algo similar: por un lado tenemos la familia de sistema operativo (Windows Server 2008 R2, Windows Server 2012, etc), y una vez elegida la familia vamos a poder elegir qué imagen queremos implementar de una lista reducida, lo cual equivaldría a las versiones antes vistas.

Dominio de Actualización y Dominio de Falla

Los Dominios de Actualización y Dominios de Falla (que en sí mismos son la misma cosa) son aspectos muy importantes de cara a garantizar disponibilidad de servicio. En este sentido, Microsoft Azure es específico y claro al indicar que para llegar a los niveles de SLA comprometidos, se deben tener al menos dos instancias de cada rol desplegadas (sea en PaaS – Cloud Services, como en IaaS – Virtual Machines).

Dominio de Actualización

Los Dominios de Actualización (Upgrade Domains) es la forma que tiene Microsoft Azure para asegurar que el impacto en los roles que despleguemos (sean estos IaaS o PaaS) sea mínimo durante procesos de actualización de la infraestructura.

Esto es más simple de lo que parece: cuando Microsoft ejecute procesos de actualización sobre la plataforma (o sobre un rack, por ejemplo), el dominio de actualización nos permite identificar las instancias (sistemas operativos) que ejecutan un mismo rol (por ejemplo, un front-end de nuestra aplicación), de modo tal que sabe que no debe apagarlos a todos juntos porque si no el front-end se quedaría sin posibilidad de brindar servicios. De este modo, las instancias dentro de un rol determinado se distribuyen a través de uno o más dominios de actualización.

En el caso de Servicios en la Nube [Cloud Services], y al igual que cuando se va a realizar una actualización de código en una aplicación, se respeta la estructura de dominios de actualización para que tengamos la garantía que se cumple con los SLAs de servicio. Esto sucede en forma automática si bien podemos configurarlo personalizadamente. En la siguiente figura vemos ejemplificados Dominios de Actualización:

En el caso de Máquinas Virtuales [Virtual Machines] sucede algo similar, pero somos nosotros como Administradores los que configuramos qué equipos virtuales van a estar dentro del mismo “Availability Set”. Dado que Azure no administra el contenido de dichas máquinas virtuales, debemos ser muy cuidadosos en la consistencia de los datos / aplicaciones que despleguemos. En la siguiente figura vemos graficado un Dominio de Actualización para IaaS:

Dominio de Falla

Un dominio de falla es, básicamente, el mismo concepto que lo explicado en Dominio de Actualización, pero apunta a tener más de dos instancias de un mismo rol distribuidas para que se puedan cumplir los niveles de SLA en caso de incidentes o fallas en la infraestructura de Microsoft (rotura de rack, rotura de distribución de energía, etc).

¿Cómo se aplican las Actualizaciones en Azure?

Actualización de Cloud Services / Web Apps (PaaS)

Cuando se está configurando un servicio en la nube, se puede optar para que el mismo se actualice automáticamente a la nueva versión del sistema operativo invitado cuando éste es puesto a disposición, o se puede indicar que lo queremos hacer en forma manual.

Actualización Manual

En caso que se seleccione la opción manual, es importante identificar que se pierden algunos beneficios de la plataforma “PaaS”, en donde “Microsoft hace el trabajo”. También es importante identificar que la actualización manual no es eterna: como veremos más adelante, existen retiros de versiones de sistemas operativos y, cuando esto sucede, estamos obligados a actualizar (o Microsoft lo hará por nosotros).

¿Por qué quisiéramos utilizar actualización manual? ¿Es recomendado tener actualizaciones automáticas en nuestros Servicios en la Nube? Las respuestas son simples: para la primera pregunta, la respuesta es “para velar por la compatibilidad del software que ejecutamos”, y para la segunda pregunta la respuesta es “si”. No obstante, trataremos estos temas en detalle en el apartado “¿Cómo afecta esto a Profesionales IT y Desarrolladores?”.

Actualización Automática

Esta es la opción recomendada por Microsoft. Cuando le indicamos al Cloud Service que se pueda actualizar automáticamente para incluir los parches más recientes a medida que van poniéndose a disposición, en realidad no estamos activando “Windows Update” ni nada de eso.

En realidad, lo que ocurre es que el sistema operativo invitado será re-implementado cuando existan actualizaciones disponibles siguiendo el mismo procedimiento que se realiza la actualización in-place de nuestro código:

• La instancia a actualizar (o sea el sistema operativo de la máquina virtual a actualizar) se saca del balanceador de carga y se lanza el proceso de apagado.
• El método OnStop es llamado para que pueda realizar un apagado limpio de la aplicación.
• Una vez que la instancia se cierra, la imagen del sistema operativo es totalmente reemplazada por una nueva imagen actualizada.
• La máquina virtual es puesta nuevamente en marcha y el código de la aplicación que ejecuta es re-implementado como si se tratara de una nueva instancia agregada.

Como vemos, el proceso de actualización de un Cloud Service es un tanto distinto al que realizaríamos en un servicio IaaS con máquinas virtuales propias. Asimismo, debemos tener en cuenta que

Actualización de Virtual Machines (IaaS)

Como hemos comentado antes, en caso de IaaS (Infraestructura como Servicio) es el usuario quien toma la responsabilidad de actualizar el sistema operativo invitado. Ahora bien, es importante indicar que, si se tiene solo una instancia de un rol de máquina virtual, es probable que cuando el host donde se aloje sea actualizado (Microsoft se ocupa de esto) dicho equipo quede fuera de línea por algunas horas y, por ende, los servicios que brinda no estarán disponibles.

Este último punto es importante de tener en cuenta, principalmente, para servicios críticos o sensibles en la organización. Sería un error pensar que por llevar nuestras máquinas virtuales a Azure vamos a tener un 99,95% de disponibilidad. Esto solo se garantiza, en el SLA del servicio, si contamos con dos instancias por cada uno de los roles que se ejecutan en nuestras máquinas virtuales.

En conclusión, la alternativa de tener máquinas virtuales en Azure puede llegar a ser la elección para aquellos desarrollos y software que no requieran (por motivos tecnológicos o políticos) actualizaciones constantes, tal como ocurre en los Cloud Services / Web Apps.

¿Cómo se gestiona el retiro de Sistemas Operativos?

En el caso de servicios como Cloud Services y Web Apps (ambos forman parte de la oferta PaaS), existe un escenario de retiro planificado de versiones (OSVersion) e incluso familias (osFamily) de sistemas operativos. Microsoft en este sentido tiene una política de retiro, la cual está publicada y es muy importante sea tenida en cuenta por desarrolladores y administradores.

• Por regla, Microsoft dará soporte para al menos dos familias de sistemas operativos invitados. Cuando se retire una familia, los clientes dispondrán de 12 meses a partir de la retirada oficial para actualizar a una familia más reciente compatible.
• Microsoft proporcionará soporte para al menos las dos últimas versiones de las familias del sistema operativo invitado compatibles.
• Microsoft proporcionará soporte para al menos las dos últimas versiones del SDK de Azure. Cuando se retire, los clientes tendrán un tiempo de 12 meses para actualizarse a una nueva versión soportada.

Los detalles de las versiones de sistema operativo invitado soportadas y los SDKs figuran en los “Enlaces Relacionados” al final de la publicación.

Proceso de retirada de una Familia de OS

Luego del lanzamiento de una versión oficial del sistema operativo de Windows Server es cuando se realiza la introducción de una familia de OS a Microsoft Azure. Asimismo, cada vez que se introduce una nueva familia Invitado OS Microsoft retirará el más antiguo.

Una vez que se inició el retiro, los clientes que tengan aplicaciones ejecutándose en una familia retirada tendrán un período de 12 meses de “transición” antes que, finalmente, la familia se retire oficialmente. Para nuevas implementaciones dicha familia ya no estará disponible.

Ahora bien, Microsoft dentro de esos “12 meses” realizará un proceso de retiro gradual que comenzará a los 6 meses del período de transición, en donde:

• Notificará a los clientes de la jubilación del retiro.
• La nueva versión del SDK de Azure no se permitirá en la familia retirada.
• Los nuevos despliegues y redistribuciones de servicios en la nube no serán permitidas en la familia retirada.

En relación a las actualizaciones de versión (punto que veremos a continuación), las mismas se desplegarán hasta el último día del “período de transición”, conocido como “fecha de caducidad”.

Proceso de retirada de una versión de OS

Casi todos los meses se introducen nuevas versiones de Sistemas Operativos para incorporar las últimas actualizaciones. Debido a las actualizaciones mensuales regulares, una versión del sistema operativo es desactivada normalmente 60 días después de su lanzamiento. Esto mantiene al menos dos versiones de OS para cada familia de OS disponibles para su uso.

Ahora bien, una vez que se supera los 60 días de una versión y el cliente no tiene configuradas las actualizaciones automáticas (es decir se realizan en forma manual), la versión es “deshabilitada”. Esto significa que no se podrán realizar implementaciones nuevas sobre dicha versión, aunque las existentes se podrán seguir ejecutando.

En un momento posterior a ello (o sea luego de los 60 días) la versión del sistema operativo “caduca” y cualquier servicio que esté en ejecución se actualizará configurándose “obligatoriamente” las actualizaciones automáticas desde ese momento en adelante. Este proceso que marca a una versión como “caducada” puede variar, dado que el fabricante lo ejecuta por lotes.

Notificaciones durante la retirada

En el caso de las Familias de Sistemas Operativos, Microsoft notificará mediante su blog y portal de gestión en Azure. Los clientes que aún utilizan una familia de OS retirada serán notificados directamente por mensaje de correo electrónico, mensaje a través del portal de Azure e inclusive llamada telefónica a los administradores del servicio.

Para las Versiones de Sistemas Operativos, existen canales genéricos (ver Referencias y Links al final de esta publicación) y también los Administradores de Servicio recibirán notificaciones directas por correo electrónico en el caso que tengan servicios ejecutándose con una versión deshabilitada y próxima a caducar.

Conclusiones

¿Cómo afecta todo lo visto a Profesionales IT y Desarrolladores? El mecanismo de actualizaciones en Azure presentado durante esta publicación impacta tanto a IT Pros como a Desarrolladores. Comentamos aquí algunos puntos interesantes:

Es importante concientizar a los profesionales IT / Devs y organizaciones que tener un servicio en la nube como PaaS no es “no administrarlo ni preocuparse jamás”. Si bien los esfuerzos de administración claramente son menores, dado que tenemos una capa de infraestructura que ya no está bajo nuestra responsabilidad, existen aspectos relacionados al impacto de las actualizaciones que obligan a los desarrolladores a estar continuamente evolucionando junto a sus aplicaciones.

Para los Desarrolladores que publiquen aplicaciones en PaaS, Azure provee de un ambiente de pre-producción que le permite al desarrollador evaluar, rápidamente, el impacto de las actualizaciones y nuevas versiones en su aplicación como si se tratase del ambiente productivo, y en el caso de identificar que no hay problemáticas podrá publicarlo rápidamente al ambiente productivo de Azure.

Para los IT Pros, y desde el punto de vista de IaaS, la política de actualización de máquinas virtuales debe ser administrada como cualquier otro aspecto de la infraestructura on-premise, aunque se encuentre en Azure. El resolver cómo impactan y preparar un ambiente de laboratorio también será nuestra responsabilidad, si bien la nube nos provee de mecanismos facilitadores.

Referencias y Links

• Política de Retiro: https://msdn.microsoft.com/en-us/library/azure/dn750847.aspx y https://azure.microsoft.com/es-es/documentation/articles/cloud-services-guestos-retirementpolicy/
• Mantenimientos Programados: https://azure.microsoft.com/enus/documentation/articles/virtual-machines-planned-maintenance/
• Matrix de Compatibilidad de OS: https://msdn.microsoft.com/library/azure/ee924680.aspx

Acerca del Autor