Eine CloudStack-Cloud patchen, während die Instanzen der Tenants weiterlaufen

Wenn ein Security Advisory für die Plattform erscheint, die die Server anderer Leute betreibt, gibt es zwei schlechte Instinkte. Der eine ist zu warten, weil das Anfassen der Cloud riskanter wirkt als die Schwachstelle. Der andere ist, alles auf einmal zu aktualisieren und zu hoffen. Apache CloudStack belohnt einen dritten Ansatz: seine Ebenen verstehen, sie in der richtigen Reihenfolge aktualisieren, und die Belege entscheiden lassen, welche Schritte die Tenants tatsächlich berühren.

Eine Cloud sind mehrere Dinge zum Patchen, nicht eines

Eine CloudStack-Installation ist ein Stack von Komponenten mit unterschiedlichem Auswirkungsradius:

• Die Management-Server und ihre Datenbank. Die Control Plane: Portal, API, Orchestrierung. Solange sie down ist, können Benutzer keine Ressourcen anlegen oder ändern, aber laufende Instanzen hängen nicht von ihr ab.
• Die Agents auf jedem KVM-Host. Sie verbinden die Hypervisoren mit dem Management-Server. Der Neustart eines Agents stoppt nicht die Instanzen, die auf diesem Host bereits laufen.
• System-VMs. Die Secondary-Storage-VM kümmert sich um Templates und Snapshots, der Console Proxy liefert Browser-Konsolen aus. Ihr Neustart unterbricht kurz diese Funktionen, nicht die Workloads der Tenants.
• Virtual Router. Diese sitzen im Datenpfad der Tenant-Netzwerke und stellen DHCP, DNS, NAT, Firewalling und Load Balancing bereit. Der Neustart eines Routers unterbricht die Dienste dieses Netzwerks für einen Moment.

Die Reihenfolge der Arbeit folgt aus dieser Liste: zuerst die Teile, die die Tenants nie spüren, zuletzt die Teile, die sie spüren könnten, und die letzten nur, wenn es einen echten Grund gibt.

Schritt eins: das Advisory gegen Ihre eigene Konfiguration lesen

Die meisten Advisories betreffen ein bestimmtes Feature, oft ein optionales. Bevor Sie ein Fenster planen, finden Sie heraus, ob das betroffene Feature in Ihrer Cloud aktiviert ist. Die globalen Einstellungen sind über das API sichtbar, zum Beispiel mit CloudMonkey:

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

Das sagt Ihnen, wie dringend das Update für Sie ist, und gibt Ihnen eine Aufzeichnung des Zustands vor der Änderung.

Schritt zwei: sichern, was Sie für den Rückweg bräuchten

Nehmen Sie vor jeder Paketänderung einen konsistenten Dump der CloudStack-Datenbanken und kopieren Sie die Konfigurationsdateien des Management-Servers von der Maschine herunter:

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

Bewahren Sie die Dumps außerhalb des Management-Servers auf.

Schritt drei: die Management-Server

Prüfen Sie nach der Aktualisierung der Management-Pakete zwei Dinge. Und prüfen Sie nach jedem Update zwei Dinge. Erstens, dass der Dienst für den Start beim Boot aktiviert ist, so wie Sie es beabsichtigen. Zweitens, dass er den Start wirklich abgeschlossen hat, nicht nur, dass der Prozess existiert:

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

Warten Sie, bis das Log den abgeschlossenen Start zeigt und das API antwortet, bevor Sie weitergehen. Wenn Sie mehrere Management-Server hinter einem Load Balancer betreiben, aktualisieren Sie sie einen nach dem anderen, damit das API durchgehend verfügbar bleibt.

Schritt vier: Agents, ein Host nach dem anderen, mit Bremse

Aktualisieren Sie das Agent-Paket auf einem KVM-Host, starten Sie den Agent neu, und warten Sie, bis der Management-Server diesen Host wieder als Up sieht, bevor Sie zum nächsten gehen. Skripten Sie es, wenn Sie viele Hosts haben, aber geben Sie dem Skript eine Bremse:

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

Wenn irgendein Host beim Update oder bei der Wiederverbindung scheitert, stoppt die Schleife dort, mit einem Host zum Untersuchen statt der ganzen Cloud. Die Instanzen laufen währenddessen auf ihren Hosts weiter, weil der Agent nicht in ihrem Pfad liegt.

Schritt fünf: System-VMs, dann Router nach Beleglage

System-VMs tragen Skripte und Pakete vom Management-Server. Starten Sie sie nach dem Update neu oder patchen Sie sie über das API, damit sie den neuen Code aufnehmen, und bestätigen Sie dann, dass sie Running und verbunden zurückkommen:

cmk list systemvms

Virtual Router verdienen mehr Nachdenken, weil sie im Tenant-Traffic sitzen. Die Plattform kann Router als upgradebedürftig markieren, aber dieses Flag kann gesetzt werden, obwohl sich der Code in ihnen nicht wesentlich geändert hat. Vergleichen Sie die Skripte, die der Router nach dem Update erhalten würde, mit denen, die er bereits ausführt. Wenn der Code des Routers unverändert ist, lassen Sie ihn in Ruhe und ersparen Sie Ihren Tenants die Unterbrechung. Hat er sich geändert, planen Sie Router-Neustarts pro Netzwerk, informieren Sie die betroffenen Tenants, und führen Sie sie einen nach dem anderen durch.

cmk list routers requiresupgrade=true

Schritt sechs: den Endzustand beweisen

Führen Sie dieselben Prüfungen wie in Schritt eins aus und vergleichen Sie: jeder Host Up, jede System-VM Running, jeder Router in seinem erwarteten Zustand, die Einstellung aus dem Advisory dort, wo Sie sie haben wollen, und eine Testinstanz über das API angelegt, gestartet und zerstört. Notieren Sie dann die Zeit von der ersten Änderung bis grün, die Ihnen sagt, wie lang das nächste Fenster sein muss.

Wie wir es machen

Wir bauen Apache-CloudStack-Clouds pro Kunde, nach der Spezifikation des Kunden, auf KVM-Hosts auf HPE- und Dell-Hardware mit Enterprise-SAN-Storage darunter und dem kommerziellen Support von ShapeBlue hinter der Plattform. Security Advisories folgen dem Verfahren oben. Als ein Advisory für CloudStack veröffentlicht wurde, haben wir den Fix auf diese Weise noch in derselben Woche auf eine Produktions-Cloud angewendet, und jede laufende Kundeninstanz blieb durchgehend up.

Anerkennung, wo sie hingehört: Die Apache-CloudStack-Community und ShapeBlue leisten die harte Arbeit, diese Probleme zu finden, zu beheben und zu dokumentieren. Wenn in Ihrer eigenen Cloud ein Update wartet, weil das Verfahren riskant wirkt, gehen wir es gern mit Ihnen durch.

cta: Mit einem Ingenieur sprechen

Related

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