Sistema de parcheo sin interrupciones: mantén tu infraestructura actualizada sin perder el sueño

En el mundo actual, donde la seguridad y el rendimiento de los sistemas informáticos son cruciales, mantener una infraestructura actualizada es una necesidad que no puedes ignorar. Sin embargo, para muchas organizaciones, el proceso de actualización puede ser un verdadero dolor de cabeza. La preocupación por el tiempo de inactividad, los posibles fallos y la interrupción del servicio a menudo lleva a posponer actualizaciones críticas, lo que puede resultar en vulnerabilidades de seguridad y pérdida de rendimiento.

¿Y si existiera una manera de mantener tu infraestructura actualizada sin interrumpir tus servicios? Buenas noticias: es posible, y en este artículo, vamos a explorar cómo implementar un sistema de parcheo sin interrupciones que te permitirá dormir como un bebé.

El desafío: actualizar sin caer

Imagina una infraestructura de alta disponibilidad típica: tienes balanceadores de carga redundados como HAProxy distribuyendo el tráfico, varios servidores para bases de datos, servidores web, Redis para caché, Varnish para acelerar el contenido estático, y tal vez OpenSearch para acabar de completar tu stack moderno y opensource. Todo este ecosistema complejo trabaja en armonía para mantener tu aplicación funcionando sin problemas.

Actualizar cada componente de este sistema sin afectar al servicio puede parecer una tarea compleja, pero con la estrategia adecuada, es totalmente alcanzable.

Parcheos automáticos: la cura para el insomnio

La automatización es el pilar fundamental de un sistema de parcheo sin interrupciones. Una de las herramientas más populares para este propósito es AWS Systems Manager (conocido formalmente como SSM), un servicio de AWS que proporciona visibilidad y control sobre tu infraestructura, permitiéndote realizar operaciones sobre ella de manera programática, como por ejemplo actualizar tus sistemas bajo las condiciones requeridas y con las acciones previas o posteriores que necesite tu entorno.

SSM ofrece varias características útiles para el parcheo automático:

1. Inventory: te permite recopilar y consultar información sobre tus recursos y su configuración.
2. Patch Manager: automatiza y gestiona el proceso de parcheo para instancias EC2, pero también para cualquier servidor con un sistema operativo soportado Linux o Windows.
3. Maintenance Windows: te permite definir ventanas de tiempo recurrentes para realizar tareas de mantenimiento. Aquí es donde la magia ocurrirá más tarde con el sistema de «ladders» (o peldaños) como veremos en breve.
4. Run Command: permite ejecutar comandos o scripts en múltiples instancias simultáneamente, siendo uno de los comandos el de actualización del sistema con las opciones definidas en Patch Manager.

Sin embargo, SSM no es la única opción disponible en el mercado; puedes valorar usar soluciones como:

1. Ansible Tower: una solución de automatización de código abierto de la mano de Red Hat, que puede manejar configuración, despliegues y orquestación.
2. Puppet Enterprise: una plataforma de automatización que te permite definir el estado deseado de tu infraestructura y mantenerla de una manera centralizada.

Cada una de estas herramientas tiene sus propias fortalezas y debilidades, por lo que es importante evaluar cuál se adapta mejor a tus necesidades específicas.

El sistema de ‘Ladders’ : el orden importa

Independientemente de la herramienta que elijas, el concepto de «ladders» (peldaños) es fundamental para un parcheo sin interrupciones. Este enfoque implica definir un orden en el que tus sistemas serán actualizados -asignarles un número de ladder – para poder entonces definir unas ventanas de mantenimiento donde tu sistema de parcheos automáticos actuará solo en el ladder que hayas definido para ese día.

De esta manera, puedes definir por ejemplo 2 ladders por lo que:

Ladder 1:

– Actualizamos uno de los dos balanceadores (por lo que el otro toma el relevo)

– Actualizamos la mitad de los servidores web, la mitad de los servidores de bases de datos, de Redis, de Varnish… y así el resto de los servicios.

Ladder 2:

– Actualizamos el balanceador restante.

– Actualizamos el resto de los servicios.

La belleza de este enfoque es que garantiza que, en cada paso, tu aplicación sigue siendo completamente funcional. Además, el uso de estas herramientas te permite hacer una serie de comprobaciones adicionales, así como lanzar otras acciones en caso de que se cumpla una condición que hayas definido previamente, como puede ser que, en el caso de un Varnish, tras un parcheo, se haga un warmeo de la infraestructura para que tu caché esté lista en la mañana para servir todo ese tráfico importante de manera óptima y sin esperas.

Preparación del terreno: agentes y gestión de configuración

Tener instalado y configurado correctamente el agente de parcheos en cada uno de tus servidores, dependiendo de la herramienta que utilices, puede requerir la instalación de este en una flota de servidores inmensa, lo que puede ser un trabajo inicial laborioso.

Aquí es donde entran en juego herramientas de gestión de configuración como Chef o Ansible. Estas herramientas te permiten definir el estado deseado de tus sistemas de manera centralizada y luego aplicar esa configuración a todos tus servidores de manera consistente.

Por ejemplo, podrías usar Ansible para crear un playbook que:

1. Instale el agente de parcheos
2. Configure el agente con los ajustes correctos
3. Asegure que el agente se inicie automáticamente al arrancar el sistema
4. Verifique periódicamente que el agente está funcionando correctamente

Al centralizar esta configuración, te aseguras de que todos tus sistemas están preparados de la misma manera para recibir actualizaciones, reduciendo la posibilidad de errores y simplificando el mantenimiento a largo plazo.

Snapshots: tu red de seguridad

Antes de comenzar cualquier proceso de actualización, es fundamental tener una manera de volver atrás si algo sale mal. Aquí es donde entran en juego los snapshots automáticos.

La mayoría de los hipervisores modernos como VMware vSphere, Microsoft Hyper-V, OpenStack o soluciones en la nube como AWS EC2, ofrecen la capacidad de tomar snapshots automáticos de tus máquinas virtuales.

Configurar tu sistema para que realice snapshots automáticos justo antes de iniciar el proceso de parcheo es algo vital. Esto te proporcionará un punto de restauración rápido en caso de que algo salga mal durante la actualización.

Algunos puntos a tener en cuenta al implementar snapshots automáticos:

1. Asegúrate de que tienes suficiente espacio de almacenamiento para los snapshots.
2. Configura una política de retención para los snapshots para evitar acumular demasiados.
3. Prueba regularmente el proceso de restauración desde un snapshot para asegurarte de que funciona como se espera. Un buen backup es aquel que puede restaurarse.
4. Ten en cuenta el impacto en el rendimiento al tomar snapshots y el tiempo de vida que estos tengan; mantener snapshots durante un tiempo prolongado puede afectar al rendimiento y a las operaciones sobre los discos en la mayoría de hipervisores.

La importancia de los entornos: STG, PRE y PRO

Una estrategia de parcheo robusta no solo se trata de cómo actualizas tus sistemas, sino también de dónde y cuándo lo haces. Es aquí donde entra en juego la importancia de tener múltiples entornos: Staging (STG), Pre-producción (PRE) y Producción (PRO).

El entorno de staging (STG) es tu campo de pruebas, donde puedes experimentar con nuevas versiones sin miedo a romper nada importante. Pre-producción (PRE) es tu ensayo general, una réplica exacta de producción donde las versiones de software deben coincidir como veremos a continuación. Finalmente, Producción (PRO) es donde vive tu aplicación real y requiere el mayor cuidado al actualizarlo.

La clave está en actualizar estos entornos de manera escalonada: primero STG, luego PRE, y finalmente PRO. Esto te permite detectar y corregir problemas antes de que lleguen a afectar a tus usuarios finales.

Sintonía entre versiones de PRE y PRO

Un aspecto crucial de esta estrategia de múltiples entornos es mantener sincronizadas las versiones entre PRE y PRO. Esto significa que, idealmente, PRE y PRO deberían estar ejecutando exactamente las mismas versiones de software en todo momento, excepto durante el breve período en que PRE está siendo actualizado.

¿Por qué es esto importante? Porque te permite tener una confianza mucho mayor en que lo que funciona en PRE funcionará también en PRO. Si encuentras un problema en PRE después de una actualización, es bastante seguro que ese mismo problema aparecerá en PRO cuando la actualización llegue allí.

Por lo tanto, ten en cuenta estas recomendaciones:

1. Mantén un registro detallado de las versiones del software en cada entorno.
2. Actualiza siempre PRE antes que PRO, con un intervalo de tiempo suficiente para detectar problemas (por ejemplo, una semana).
3. Si necesitas probar versiones diferentes o configuraciones experimentales, hazlo en STG, no en PRE.
4. Si por alguna razón PRE y PRO se desincronizan, haz que volver a sincronizarlos sea una prioridad alta.

Monitorización: tus ojos y oídos durante el proceso

La monitorización es crucial durante todo el proceso de parcheo. Necesitas tener visibilidad en tiempo real de cómo están funcionando tus sistemas antes, durante y sobre todo, después de las actualizaciones.

Algunas métricas clave que debes monitorizar incluyen:

– Uso de CPU y memoria

– Tiempos de respuesta de la aplicación

– Tasas de error

– Disponibilidad de servicios

– Uso de disco y red

– Tiempos de respuesta de bases de datos

– Métricas específicas de tu aplicación

Herramientas como Zabbix, Grafana, Prometheus o Nagios, pueden ser excelentes aliadas para la monitorización.

Configuración de alertas

Configura alertas para que te notifiquen inmediatamente si algo se sale de los límites normales después del proceso de actualización. Algunas alertas que podrías considerar incluyen:

1. Alerta de CPU alta: Si el uso de CPU supera el 80% durante más de 5 minutos.
2. Alerta de memoria: Si el uso de memoria supera el 90%.
3. Alerta de disco: Si el espacio en disco cae por debajo del 20% libre.
4. Alerta de tiempo de respuesta: Si el tiempo de respuesta promedio supera los 500ms durante más de 2 minutos.
5. Alerta de tasa de error: Si la tasa de errores HTTP 5xx supera el 1% durante más de 1 minuto.

Es importante ajustar estos umbrales según las características específicas de tu aplicación y tu infraestructura.

Logs centralizados: tu aliado para el debugging

Cuando estás actualizando docenas o cientos de servidores, tener un sistema de logs centralizado se vuelve crucial. Te permite tener una visión unificada de todo lo que está sucediendo durante el proceso de actualización.

Hay varias opciones para la centralización de logs, siendo una de las más populares el ELKStack (Elasticsearch/Opensearch, Logstash, Kibana)

Independientemente de la herramienta que elijas, asegúrate de que tu sistema de automatización de parcheos envíe sus logs a este sistema centralizado. Esto te permitirá diagnosticar problemas más rápidamente.

Estrategias de rollback: porque a veces las cosas salen mal

A pesar de todas las precauciones, a veces las cosas simplemente salen mal. Es crucial tener una estrategia de rollback bien definida y probada para estos casos.

Tu estrategia de rollback podría incluir:

1. Balancear a otro servidor: la idea de los ladders sale a relucir en este paso. Si un sistema está fallando, lo primordial es que tu aplicación no caiga. Para ello, si tienes una estructura en alta disponibilidad, configura bien esos ladders para que en ningún momento una mala actualización tire tu infraestructura abajo. Una vez detectes un fallo, sacar a ese servidor del balanceador y poder revisar el problema en horario laboral, te permitirá ahorrar en disgustos y probablemente en cafeína.
2. Restauración desde snapshots: si tomaste snapshots antes de iniciar el proceso de parcheo, puedes restaurar rápidamente tus sistemas siempre que la consistencia de datos no suponga un problema por el servicio a restaurar.
3. Desinstalación de parches: si sabes que un paquete concreto está fallando, siempre puedes hacer un downgrade/reinstalación de este a una versión previa y funcional.

Independientemente de la estrategia que elijas, asegúrate de probarla regularmente. Un plan de rollback que no funciona cuando lo necesitas es peor que no tener plan en absoluto.

Conclusión

Implementar un sistema de parcheo sin interrupciones puede parecer una tarea desalentadora, pero con la planificación y las herramientas adecuadas, es totalmente alcanzable. Recuerda estos puntos clave:

1. La automatización es crucial: utiliza herramientas de automatización para hacer el proceso predecible y gestionable.
2. El enfoque de «ladders» te permite actualizar de manera ordenada y controlada y funciona en sintonía con un entorno en alta disponibilidad correctamente balanceado.
3. Los snapshots automáticos proporcionan una red de seguridad en caso de problemas.
4. Utiliza múltiples entornos (STG, PRE, PRO) para probar las actualizaciones de manera segura.
5. La monitorización y los logs centralizados te permitirán estar al tanto de cualquier problema y poder actuar rápidamente. Incluso puedes automatizar que, si se detectan una serie de errores, un servidor se saque del balanceador automáticamente.
6. Ten siempre un plan de rollback bien definido y probado.

Y recuerda, siempre puedes delegar la responsabilidad y configuración de un buen sistema en alta disponibilidad con parcheos automáticos a expertos en la materia, como por ejemplo nosotros.

¡Feliz parcheo!