Azure Service Health, Management and Governance
Avance de las tecnologías de mantenimiento sin impacto y de bajo impacto
Posted on
5 min read
“Esta entrada de blog es la continuación de la serie sobre confiabilidad que inicié con la entrada de julio, en la que comentaba varias iniciativas que están en curso para seguir mejorando la disponibilidad de la plataforma, dentro de nuestro compromiso por ofrecer un conjunto de servicios en la nube de confianza. Hoy queremos analizar las inversiones que hemos realizado en tecnologías de actualización sin impacto y de bajo impacto, como la aplicación de revisiones en caliente, el mantenimiento de conservación de memoria y la migración en vivo. Hemos implementado decenas de revisiones de seguridad y confiabilidad en la infraestructura de host en el último año, muchas de las cuales se implementaron sin impacto ni tiempo de inactividad para el cliente. El autor de la entrada de blog que viene a continuación es John Slack, de nuestro equipo principal de sistemas operativos, que es administrador de programas para algunas de las tecnologías de actualización que se describen a continuación”. —Mark Russinovich, director de tecnología, Azure
En esta entrada de blog han colaborado Apurva Thanky, Cristina del Amo Casado y Shantanu Srivastava, de los equipos de ingeniería responsables de estas tecnologías.
Actualizamos periódicamente la infraestructura de host de Azure para mejorar la confiabilidad, el rendimiento y la seguridad de la plataforma. Aunque la finalidad de estas actualizaciones de “mantenimiento” varía, normalmente implican la actualización de componentes de software en el entorno de hospedaje o la retirada de hardware. Si retrocedemos cinco años, la única manera de aplicar algunas de estas actualizaciones era reiniciando completamente todo el host. Este método suponía tener inactivas las máquinas virtuales (VM) del cliente durante varios minutos. Desde entonces, hemos invertido en una gran variedad de tecnologías que minimicen el impacto para el cliente cuando se actualiza la flota. En la actualidad, la gran mayoría de las actualizaciones del sistema operativo host se implementan in situ, con transparencia absoluta y sin impacto para el cliente, mediante la aplicación de revisiones en caliente. En casos poco frecuentes en los que no se puede implementar una actualización mediante la aplicación de una revisión en caliente, solemos utilizar tecnologías de actualización de bajo impacto que conservan la memoria.
Incluso con estas tecnologías, existen aún otros casos raros en los que es necesario llevar a cabo un mantenimiento con un mayor impacto (incluidos el desalojo de hardware defectuoso o la retirada de hardware anticuado). En estos casos, se usa una combinación de migración en vivo, notificaciones en las máquinas virtuales y mantenimiento planeado que proporciona controles de cliente.
Gracias a la inversión constante en este ámbito, estamos en un punto en el que la inmensa mayoría de las actividades de mantenimiento del host no afectan a las máquinas virtuales hospedadas en la infraestructura afectada. Hemos elaborado esta entrada de blog con el fin de ser transparentes en cuanto a las distintas técnicas que utilizamos para asegurar que las actualizaciones de Azure tengan un impacto mínimo.
Plan A: Aplicación de revisiones en caliente
La aplicación de revisiones “en caliente” a nivel de función permite realizar cambios concretos en el código que está en ejecución sin incurrir en tiempo de inactividad de las máquinas virtuales de los clientes. Para ello, redirige todas las invocaciones nuevas de una función en el host a una versión actualizada de esa función, por lo que se considera una tecnología de actualización “sin impacto”. Siempre que es posible, se usa la aplicación de revisiones en caliente para implementar actualizaciones de host, lo que evita por completo cualquier impacto en las máquinas virtuales que se ejecutan en ese host. Utilizamos la aplicación de revisiones en caliente en Azure desde 2017. Desde entonces, hemos trabajado para ampliar el ámbito donde se puede usar la aplicación de revisiones en caliente. Por ejemplo, en 2018 actualizamos el sistema operativo host para permitir la aplicación de revisiones en caliente en el hipervisor. De cara al futuro, estamos estudiando la aplicación de revisiones en caliente en el firmware. Este es un componente al que el sector no suele prestarle atención. En el caso del firmware, siempre se ha dicho que “si necesitas actualizarlo, reinicia el servidor”, pero sabemos que esto supone una experiencia terrible para el cliente. Trabajamos con fabricantes de hardware para que tengan en cuenta nuestro firmware y hagan que se pueda actualizar gradualmente y mediante la aplicación de revisiones en caliente.
Algunas actualizaciones de host de gran envergadura contienen cambios que no se pueden implementar mediante la aplicación de revisiones en caliente a nivel de función. Para esas actualizaciones, procuramos utilizar el mantenimiento de conservación de memoria.
Plan B: Mantenimiento de conservación de memoria
El mantenimiento con conservación de memoria implica “pausar” las máquinas virtuales invitadas (mientras se preserva la memoria en la RAM), actualizar el servidor host, reanudar las máquinas virtuales y sincronizar automáticamente sus relojes. Utilizamos el mantenimiento de conservación de memoria por primera vez en Azure en 2018. Desde entonces, hemos mejorado la tecnología de tres formas importantes. En primer lugar, hemos desarrollado variantes con un impacto menor del mantenimiento con conservación de memoria dirigido a componentes de host en los que se pueden realizar trabajos de mantenimiento sin necesidad de reiniciar el host. En segundo lugar, hemos reducido la duración de la pausa que experimentan los clientes. En tercer lugar, hemos ampliado el número de tipos de máquinas virtuales que se pueden actualizar con mantenimiento de conservación de memoria. Aunque seguimos trabajando en este ámbito, algunas variantes del mantenimiento de conservación de memoria siguen siendo incompatibles con algunas ofertas de máquinas virtuales especializadas, como las de las series M, N o H, por diversos motivos técnicos.
En los casos excepcionales donde es necesario realizar un mantenimiento con un impacto mayor (como la necesidad de reiniciar el host o de volver a implementar máquinas virtuales), se avisa a los clientes con antelación y se les da la oportunidad de realizar el mantenimiento a la hora más adecuada para sus cargas de trabajo.
Plan C: Mantenimiento de autoservicio
El mantenimiento de autoservicio consiste en ofrecer a los clientes y asociados un período de tiempo dentro del cual pueden elegir cuándo debe iniciarse el mantenimiento que tiene un impacto mayor en sus máquinas virtuales. Esta fase inicial de autoservicio suele durar, aproximadamente, un mes y permite que las organizaciones realicen el mantenimiento según su propia programación, con el fin de que no afecte o afecte lo menos posible a los usuarios. Al final de este período de autoservicio, comienza una fase de mantenimiento programado, donde Azure realizará el mantenimiento de forma automática. En ambas fases, los clientes tienen total visibilidad de las máquinas virtuales que se han actualizado o no, en Azure Service Health o mediante una consulta en PowerShell o la CLI. Azure ofreció el mantenimiento de autoservicio por primera vez en 2018. Por lo general, vemos que los administradores aprovechan la fase de autoservicio en lugar de esperar a que Azure realice el mantenimiento en sus máquinas virtuales de forma automática.
Además, cuando el cliente es propietario de todo el equipo host, ya sea en instancias de Azure Dedicated Host o en máquinas virtuales aisladas, hemos comenzado a ofrecer recientemente el control del mantenimiento para todas las actualizaciones de la plataforma que tengan algún tipo de impacto. Esto incluye las actualizaciones sin reinicio que solo producen una pausa de unos segundos. Resulta útil para las máquinas virtuales que ejecutan cargas de trabajo ultrasensibles que no admiten ninguna interrupción, aunque solo dure unos segundos. Los clientes pueden elegir cuándo aplicar estas actualizaciones que tienen algún tipo de impacto durante un período de 35 días que se reinicia continuamente. Esta característica se encuentra en versión preliminar pública y puede obtener más información al respecto en esta entrada de blog dedicada.
A veces, las tecnologías de actualización in situ no son viables; por ejemplo, cuando un host muestra signos de degradación del hardware. En estos casos, la mejor opción es iniciar una migración de la máquina virtual a otro host, ya sea con el control del cliente para un mantenimiento planeado o mediante una migración en vivo.
Plan D: Migración en vivo
La migración en vivo implica mover una máquina virtual del cliente que está en ejecución de un host de “origen” a otro host de “destino”. La migración en vivo comienza moviendo el estado local de la máquina virtual (incluidos el almacenamiento local y la memoria RAM) del origen al destino mientras la máquina virtual sigue ejecutándose. Una vez que se ha trasladado la mayor parte del estado local, la máquina virtual invitada experimenta una breve pausa que suele durar unos cinco segundos o menos. Después de esa pausa, la máquina virtual se reanuda en el host de destino. Azure comenzó a usar la migración en vivo para mantenimiento en 2018. Actualmente, cuando los algoritmos de Azure Machine Learning predicen un error de hardware inminente, se puede usar la migración en vivo para trasladar máquinas virtuales invitadas a otros hosts de forma preventiva.
El mantenimiento preventivo y las operaciones con inteligencia artificial, entre otros temas, se trataron en la sesión sobre cómo crear aplicaciones resistentes que ofreció Igal Figlin en Ignite 2019, celebrado recientemente. Puede ver la grabación aquí para obtener más contexto al respecto y más información sobre cómo aprovechar los diversos servicios resistentes que Azure proporciona para ayudarle a crear aplicaciones que sean intrínsecamente resistentes.