[ English | Indonesia | Deutsch | 日本語 ]
Ausfälle und Wartung von Cloud Controllern und Storage-Proxys¶
Der Cloud-Controller und der Storage-Proxy sind sich sehr ähnlich, wenn es um erwartete und unerwartete Ausfallzeiten geht. Einer von jedem Servertyp läuft typischerweise in der Cloud, was ihn sehr auffällig macht, wenn er nicht läuft.
Für den Cloud-Controller ist die gute Nachricht, wenn Ihre Cloud den FlatDHCP Multi-Host-HA-Netzwerkmodus verwendet, bestehende Instanzen und Volumes weiterarbeiten, während der Cloud-Controller offline ist. Für den Speicherproxy ist jedoch kein Speicherdatenverkehr möglich, bis er wieder in Betrieb ist.
Geplante Wartung¶
Eine Möglichkeit, die Wartung von Cloud Controllern oder Storage-Proxys zu planen, besteht darin, dies einfach außerhalb der Geschäftszeiten zu tun, z.B. um 1 Uhr morgens oder 2 Uhr morgens. Diese Strategie betrifft weniger Benutzer. Wenn Ihr Cloud-Controller oder Speicherproxy zu wichtig ist, um zu einem beliebigen Zeitpunkt nicht verfügbar zu sein, müssen Sie sich mit Hochverfügbarkeitsoptionen befassen.
Neustart eines Cloud Controllers oder Storage Proxy¶
Alles in allem geben Sie einfach den Befehl reboot ein. Das Betriebssystem fährt die Dienste sauber herunter und startet dann automatisch neu. Wenn Sie sehr gründlich sein möchten, führen Sie Ihre Backup-Aufträge kurz vor dem Neustart aus.
Stellen Sie nach einem Neustart eines Cloud-Controllers sicher, dass alle erforderlichen Dienste erfolgreich gestartet wurden. Die folgenden Befehle verwenden ps und grep, um festzustellen, ob nova, glance und keystone gerade laufen:
# ps aux | grep nova-
# ps aux | grep glance-
# ps aux | grep keystone
# ps aux | grep cinder
Überprüfen Sie auch, ob alle Dienste funktionieren. Der folgende Befehlssatz liefert die Datei openrc, führt dann einige grundlegende Glance-, nova- und openstack-Befehle aus. Wenn die Befehle wie erwartet funktionieren, können Sie sicher sein, dass sich diese Dienste in einem funktionierenden Zustand befinden:
# . openrc
# openstack image list
# openstack server list
# openstack project list
Stellen Sie für den Speicherproxy sicher, dass der Object Storage service wieder aufgenommen wurde:
# ps aux | grep swift
Überprüfen Sie auch, ob es funktioniert:
# swift stat
Totaler Ausfall des Cloud Controllers¶
Der Cloud-Controller kann komplett ausfallen, wenn z.B. sein Motherboard kaputt geht. Benutzer werden sofort den Verlust eines Cloud Controllers bemerken, da er die Kernfunktionalität Ihrer Cloud-Umgebung bereitstellt. Wenn Ihre Infrastrukturüberwachung Sie nicht darüber informiert, dass Ihr Cloud-Controller ausgefallen ist, werden es Ihre Benutzer definitiv tun. Leider ist dies eine schwierige Situation. Der Cloud-Controller ist ein integraler Bestandteil Ihrer Cloud. Wenn Sie nur einen Controller haben, werden Sie viele fehlende Dienste haben, wenn er ausfällt.
Um diese Situation zu vermeiden, erstellen Sie einen hochverfügbaren Cloud-Controller-Cluster. Dies liegt außerhalb des Umfangs dieses Dokuments, aber Sie können mehr im OpenStack High Availability Guide lesen.
Der nächstbeste Ansatz ist die Verwendung eines Konfigurationsmanagement-Tools wie Puppet, um automatisch einen Cloud-Controller zu erstellen. Dies sollte nicht länger als 15 Minuten dauern, wenn Sie einen freien Server zur Verfügung haben. Nachdem die Steuerung neu aufgebaut wurde, stellen Sie alle durchgeführten Backups wieder her (siehe Sicherung und Wiederherstellung).
Auch in der Praxis stellen die nova-compute Dienste auf den Compute-Knoten nicht immer eine saubere Verbindung zu rabbitmq her, das auf dem Controller gehostet wird, wenn es nach einem langen Neustart wieder hochkommt; ein Neustart der nova Dienste auf den Compute-Knoten ist erforderlich.
