Parchear un cloud CloudStack mientras las instancias de los tenants siguen en marcha

Cuando llega un aviso de seguridad para la plataforma que ejecuta los servidores de otros, hay dos malos instintos. Uno es esperar, porque tocar el cloud parece más arriesgado que la vulnerabilidad. El otro es actualizarlo todo a la vez y confiar. Apache CloudStack premia un tercer enfoque: entender sus capas, actualizarlas en el orden correcto, y dejar que la evidencia decida qué pasos afectan realmente a los tenants.

Un cloud son varias cosas que parchear, no una

Un despliegue de CloudStack es una pila de componentes con radios de impacto distintos:

• Los servidores de gestión y su base de datos. El plano de control: portal, API, orquestación. Mientras está caído, los usuarios no pueden crear ni cambiar recursos, pero las instancias en marcha no dependen de él.
• Los agentes en cada host KVM. Conectan los hipervisores con el servidor de gestión. Reiniciar un agente no detiene las instancias que ya están en marcha en ese host.
• Las system VM. La VM de storage secundario gestiona plantillas y snapshots, el console proxy sirve las consolas de navegador. Reiniciarlas interrumpe brevemente esas funciones, no las cargas de trabajo de los tenants.
• Los routers virtuales. Están en la ruta de datos de las redes de los tenants, proporcionando DHCP, DNS, NAT, firewall y balanceo de carga. Reiniciar uno interrumpe por un momento los servicios de esa red.

El orden del trabajo se deduce de esta lista: primero las partes que los tenants nunca notan, al final las que podrían notar, y estas últimas solo cuando hay una razón real.

Paso uno: lea el aviso frente a su propia configuración

La mayoría de los avisos afectan a una función concreta, muchas veces opcional. Antes de planificar una ventana, averigüe si la función afectada está habilitada en su cloud. Los ajustes globales son visibles a través de la API, por ejemplo con CloudMonkey:

cmk list configurations name=<setting from the advisory>
cmk list zones
cmk list hosts type=Routing

Esto le dice cuán urgente es la actualización para usted, y le deja un registro del estado anterior al cambio.

Paso dos: haga backup de lo que necesitaría para volver atrás

Antes de cualquier cambio de paquetes, tome un volcado consistente de las bases de datos de CloudStack y copie los ficheros de configuración del servidor de gestión fuera de la máquina:

mysqldump --single-transaction --routines --triggers cloud > cloud-before-update.sql
mysqldump --single-transaction cloud_usage > cloud_usage-before-update.sql
tar czf cloudstack-etc-before-update.tgz /etc/cloudstack

Guarde los volcados fuera del servidor de gestión.

Paso tres: los servidores de gestión

Tras actualizar los paquetes de gestión, compruebe dos cosas. Después compruebe dos cosas tras cualquier actualización. Primera, que el servicio está habilitado para arrancar al inicio, tal como usted pretende. Segunda, que realmente terminó de arrancar, no solo que el proceso existe:

systemctl is-enabled cloudstack-management
systemctl status cloudstack-management
journalctl -u cloudstack-management -f
cmk list capabilities

Espere a que el log muestre el arranque completado y la API responda antes de seguir. Si tiene varios servidores de gestión detrás de un balanceador, actualícelos uno a uno para que la API siga disponible todo el tiempo.

Paso cuatro: los agentes, un host cada vez, con un freno

Actualice el paquete del agente en un host KVM, reinicie el agente, y espere a que el servidor de gestión vea ese host de nuevo como Up antes de pasar al siguiente. Hágalo con un script si tiene muchos hosts, pero dele al script un freno:

for h in $(cat kvm-hosts.txt); do
  ssh "$h" 'dnf -y update cloudstack-agent && systemctl restart cloudstack-agent' || exit 1
  until cmk list hosts name="$h" filter=state | grep -q Up; do sleep 10; done
done

Si algún host falla al actualizarse o al reconectarse, el bucle se detiene ahí, con un host que investigar en lugar de todo el cloud. Las instancias siguen en marcha en sus hosts todo el tiempo, porque el agente no está en su ruta.

Paso cinco: las system VM, después los routers según la evidencia

Las system VM llevan scripts y paquetes del servidor de gestión. Tras la actualización, reinícielas o parchéelas a través de la API para que recojan el código nuevo, y confirme después que vuelven Running y conectadas:

cmk list systemvms

Los routers virtuales merecen más reflexión, porque están en el tráfico de los tenants. La plataforma puede marcar routers como necesitados de actualización, pero esa marca puede activarse cuando el código que llevan dentro no ha cambiado de forma significativa. Compare los scripts que el router recibiría tras la actualización con los que ya ejecuta. Si el código del router no ha cambiado, déjelo en paz y ahorre a sus tenants la interrupción. Si sí cambió, programe los reinicios de routers por red, avise a los tenants afectados, y hágalos de uno en uno.

cmk list routers requiresupgrade=true

Paso seis: demuestre el estado final

Ejecute las mismas comprobaciones que en el paso uno y compare: cada host Up, cada system VM Running, cada router en su estado esperado, el ajuste del aviso donde usted lo quiere, y una instancia de prueba creada, arrancada y destruida a través de la API. Después anote el tiempo desde el primer cambio hasta el verde, que le dice cuánto tiene que durar la próxima ventana.

Cómo lo hacemos nosotros

Construimos clouds Apache CloudStack por cliente, según la especificación del cliente, sobre hosts KVM en hardware HPE y Dell con storage SAN enterprise debajo y el soporte comercial de ShapeBlue detrás de la plataforma. Los avisos de seguridad siguen el procedimiento anterior. Cuando se publicó un aviso para CloudStack, aplicamos así la corrección a un cloud de producción esa misma semana, y todas las instancias de clientes en marcha se mantuvieron en pie durante todo el proceso.

El mérito a quien corresponde: la comunidad de Apache CloudStack y ShapeBlue hacen el trabajo duro de encontrar, corregir y documentar estos problemas. Si su propio cloud tiene una actualización pendiente porque el procedimiento parece arriesgado, con gusto lo recorremos con usted.

cta: Hable con un ingeniero

Related

• /what-we-do/storage-compute/dedicated-cloudstack/
• /what-we-do/storage-compute/private-cloud-olvm/
• /what-we-do/storage-compute/container-platform-openshift/