Corriger un cloud CloudStack pendant que les instances des tenants continuent de tourner

Quand un avis de sécurité tombe pour la plateforme qui fait tourner les serveurs d'autres personnes, il y a deux mauvais réflexes. Le premier est d'attendre, parce que toucher au cloud semble plus risqué que la vulnérabilité. Le second est de tout mettre à niveau d'un coup et d'espérer. Apache CloudStack récompense une troisième approche : comprendre ses couches, les mettre à jour dans le bon ordre, et laisser les preuves décider des étapes qui touchent vraiment les tenants.

Un cloud, ce sont plusieurs choses à corriger, pas une

Un déploiement CloudStack est une pile de composants aux rayons d'impact différents :

• Les management servers et leur base de données. Le control plane : portail, API, orchestration. Pendant qu'il est arrêté, les utilisateurs ne peuvent pas créer ni modifier de ressources, mais les instances en marche n'en dépendent pas.
• Les agents sur chaque hôte KVM. Ils relient les hyperviseurs au management server. Redémarrer un agent n'arrête pas les instances qui tournent déjà sur cet hôte.
• Les system VMs. La secondary storage VM gère les templates et les snapshots, le console proxy sert les consoles dans le navigateur. Les redémarrer interrompt brièvement ces fonctions, pas les charges de travail des tenants.
• Les routeurs virtuels. Ils sont dans le chemin de données des réseaux des tenants, et fournissent DHCP, DNS, NAT, firewalling et load balancing. En redémarrer un interrompt un instant les services de ce réseau.

L'ordre du travail découle de cette liste : d'abord les parties que les tenants ne sentent jamais, en dernier celles qu'ils pourraient sentir, et ces dernières seulement quand il y a une vraie raison.

Première étape : lire l'avis à la lumière de votre propre configuration

La plupart des avis concernent une fonctionnalité précise, souvent optionnelle. Avant de planifier une fenêtre, déterminez si la fonctionnalité concernée est activée dans votre cloud. Les global settings sont visibles via l'API, par exemple avec CloudMonkey :

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

Cela vous dit à quel point la mise à jour est urgente pour vous, et vous donne une trace de l'état avant le changement.

Deuxième étape : sauvegarder ce qu'il vous faudrait pour revenir en arrière

Avant tout changement de paquets, prenez un dump cohérent des bases de données CloudStack et copiez les fichiers de configuration du management server hors de la machine :

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

Gardez les dumps hors du management server.

Troisième étape : les management servers

Après la mise à jour des paquets de management, vérifiez deux choses. Et vérifiez ensuite deux choses après chaque mise à jour. D'abord, que le service est activé pour démarrer au boot, comme vous le souhaitez. Ensuite, qu'il a réellement terminé son démarrage, pas seulement que le processus existe :

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

Attendez que le journal indique que le démarrage est terminé et que l'API réponde avant d'aller plus loin. Si vous faites tourner plusieurs management servers derrière un load balancer, mettez-les à jour un par un pour que l'API reste disponible pendant toute l'opération.

Quatrième étape : les agents, un hôte à la fois, avec un frein

Mettez à jour le paquet agent sur un hôte KVM, redémarrez l'agent, et attendez que le management server voie de nouveau cet hôte Up avant de passer au suivant. Scriptez-le si vous avez beaucoup d'hôtes, mais donnez un frein au script :

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 un hôte échoue à se mettre à jour ou à se reconnecter, la boucle s'arrête là, avec un hôte à examiner au lieu de tout le cloud. Les instances continuent de tourner sur leurs hôtes pendant toute l'opération, parce que l'agent n'est pas dans leur chemin.

Cinquième étape : les system VMs, puis les routeurs sur preuves

Les system VMs embarquent des scripts et des paquets venant du management server. Après la mise à jour, redémarrez-les ou corrigez-les via l'API pour qu'elles prennent le nouveau code, puis confirmez qu'elles reviennent Running et connectées :

cmk list systemvms

Les routeurs virtuels méritent plus de réflexion, parce qu'ils sont dans le trafic des tenants. La plateforme peut marquer des routeurs comme nécessitant une mise à niveau, mais ce drapeau peut être posé alors que le code qu'ils contiennent n'a pas changé de façon significative. Comparez les scripts que le routeur recevrait après la mise à jour avec ceux qu'il exécute déjà. Si le code du routeur n'a pas changé, laissez-le tranquille et épargnez l'interruption à vos tenants. S'il a changé, planifiez les redémarrages de routeurs par réseau, prévenez les tenants concernés, et faites-les un par un.

cmk list routers requiresupgrade=true

Sixième étape : prouver l'état final

Relancez les mêmes contrôles qu'à la première étape et comparez : chaque hôte Up, chaque system VM Running, chaque routeur dans l'état attendu, le réglage de l'avis là où vous le voulez, et une instance de test créée, démarrée et détruite via l'API. Puis notez le temps écoulé entre le premier changement et le vert, qui vous dit quelle longueur doit avoir la prochaine fenêtre.

Comment nous le faisons

Nous construisons des clouds Apache CloudStack par client, selon la spécification du client, sur des hôtes KVM sur du matériel HPE et Dell, avec du stockage SAN entreprise en dessous et le support commercial de ShapeBlue derrière la plateforme. Les avis de sécurité suivent la procédure ci-dessus. Quand un avis a été publié pour CloudStack, nous avons appliqué le correctif à un cloud de production la même semaine de cette façon, et chaque instance client en marche est restée en ligne pendant toute l'opération.

À qui revient le mérite : la communauté Apache CloudStack et ShapeBlue font le travail difficile de trouver, corriger et documenter ces problèmes. Si votre propre cloud a une mise à jour en attente parce que la procédure semble risquée, nous serons heureux de la parcourir avec vous.

cta: Parler à un ingénieur

Related

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