[ English | Indonesia | Deutsch | 日本語 ]
Upgrades¶
Mit Ausnahme von Object Storage kann das Upgrade von einer Version von OpenStack auf eine andere sehr aufwendig sein. Dieses Kapitel enthält einige Hinweise zu den betrieblichen Aspekten, die Sie bei einem Upgrade für eine OpenStack-Umgebung berücksichtigen sollten.
Überlegungen zur Vorbereitung des Upgrades¶
Upgrade-Planung¶
Lesen Sie die Release Notes, um mehr über neue, aktualisierte und veraltete Funktionen zu erfahren. Finden Sie Inkompatibilitäten zwischen Versionen.
Berücksichtigen Sie die Auswirkungen eines Upgrades auf die Benutzer. Der Upgrade-Prozess unterbricht die Verwaltung Ihrer Umgebung einschließlich des Dashboards. Wenn Sie sich richtig auf das Upgrade vorbereiten, sollten bestehende Instanzen, Netzwerke und Speicher weiterhin funktionieren. In Einzelfällen kann es jedoch zu intermittierenden Netzwerkunterbrechungen kommen.
Berücksichtigen Sie den Ansatz für die Aktualisierung Ihrer Umgebung. Sie können ein Upgrade mit operativen Instanzen durchführen, aber das ist ein gefährlicher Ansatz. Sie können die Live-Migration verwenden, um Instanzen während der Durchführung von Upgrades vorübergehend auf andere Compute-Knoten zu verschieben. Sie müssen jedoch die Konsistenz der Datenbank während des gesamten Prozesses sicherstellen, da Ihre Umgebung sonst instabil werden könnte. Vergessen Sie auch nicht, Ihre Benutzer ausreichend zu informieren, einschließlich der Zeit, die sie benötigen, um ihre eigenen Backups durchzuführen.
Erwägen Sie, Struktur und Optionen aus den Service-Konfigurationsdateien zu übernehmen und sie mit bestehenden Konfigurationsdateien zu verschmelzen. Die OpenStack Configuration Reference enthält neue, aktualisierte und veraltete Optionen für die meisten Dienste.
Wie alle wichtigen System-Upgrades kann auch Ihr Upgrade aus einem oder mehreren Gründen fehlschlagen. Sie können sich auf diese Situation vorbereiten, indem Sie Ihre Umgebung auf die vorherige Version zurücksetzen können, einschließlich Datenbanken, Konfigurationsdateien und Pakete. Wir stellen einen exemplarischen Prozess für das Zurücksetzen Ihrer Umgebung in Zurücksetzen eines fehlgeschlagenen Upgrades vor.
Entwickeln Sie ein Upgrade-Verfahren und bewerten Sie es gründlich, indem Sie eine Testumgebung ähnlich Ihrer Produktionsumgebung verwenden.
Vorab-Upgrade-Testumgebung¶
Der wichtigste Schritt ist die Pre-Upgrade-Prüfung. Wenn Sie unmittelbar nach der Veröffentlichung einer neuen Version ein Upgrade durchführen, können unentdeckte Fehler Ihren Fortschritt behindern. Einige Bereitsteller ziehen es vor, zu warten, bis die erste Punktfreigabe angekündigt wird. Wenn Sie jedoch einen signifikanten Einsatz haben, können Sie die Entwicklung und den Test des Releases verfolgen, um sicherzustellen, dass Fehler für Ihre Anwendungsfälle behoben werden.
Jede OpenStack-Cloud ist unterschiedlich, auch wenn Sie eine nahezu identische Architektur haben, wie in diesem Handbuch beschrieben. Daher müssen Sie weiterhin Upgrades zwischen Versionen in Ihrer Umgebung mit einem ungefähren Klon Ihrer Umgebung testen.
Das heißt jedoch nicht, dass sie die gleiche Größe haben oder identische Hardware wie die Produktionsumgebung verwenden muss. Es ist wichtig, die Hardware und den Umfang der Cloud zu berücksichtigen, die Sie aktualisieren. Die folgenden Tipps können Ihnen helfen, die Kosten zu minimieren:
- Verwenden Sie Ihre eigene Cloud
Der einfachste Ort, um mit dem Testen der nächsten Version von OpenStack zu beginnen, ist die Einrichtung einer neuen Umgebung innerhalb Ihrer eigenen Cloud. Dies mag seltsam erscheinen, insbesondere die doppelte Virtualisierung, die beim Betrieb von Compute-Knoten verwendet wird. Aber es ist ein sicherer Weg, um Ihre Konfiguration sehr schnell zu testen.
- Eine Public Cloud nutzen
Erwägen Sie die Verwendung einer Public Cloud, um die Skalierbarkeitsgrenzen Ihrer Cloud-Controller-Konfiguration zu testen. Die meisten Public Clouds rechnen stundenweise ab, was bedeutet, dass es kostengünstig sein kann, selbst einen Test mit vielen Knoten durchzuführen.
- Einen anderen Speicher-Endpunkt auf dem gleichen System erstellen
Wenn Sie mit Ihrer Cloud ein externes Speicher-Plugin oder ein gemeinsam genutztes Dateisystem verwenden, können Sie testen, ob es funktioniert, indem Sie eine zweite Freigabe oder einen zweiten Endpunkt erstellen. So können Sie das System testen, bevor Sie die neue Version Ihrem Speicher anvertrauen.
- Beobachten Sie das Netzwerk
Selbst bei kleineren Tests sollten Sie nach überschüssigen Netzwerkpaketen suchen, um festzustellen, ob etwas in der Kommunikation zwischen den Komponenten schrecklich schief läuft.
Um die Testumgebung einzurichten, können Sie eine von mehreren Methoden verwenden:
Führen Sie eine vollständige manuelle Installation durch, indem Sie die Installations-Tutorials und Anleitungen für Ihre Plattform verwenden. Überprüfen Sie die endgültigen Konfigurationsdateien und installierten Pakete.
Erstellen Sie einen Klon Ihrer automatisierten Konfigurationsinfrastruktur mit geänderten Paket-Repository URLs.
Ändern Sie die Konfiguration, bis sie funktioniert.
Beide Ansätze sind gültig. Verwenden Sie den Ansatz, der Ihrer Erfahrung entspricht.
Ein Upgrade-Pretestsystem ist hervorragend geeignet, um die Konfiguration zum Laufen zu bringen. Es ist jedoch wichtig zu beachten, dass die historische Nutzung des Systems und Unterschiede in der Benutzerinteraktion den Erfolg von Upgrades beeinflussen können.
Wenn möglich, empfehlen wir Ihnen dringend, Ihre Produktionsdatenbanktabellen zu sichern und das Upgrade in Ihrer Entwicklungsumgebung mit diesen Daten zu testen. Mehrere MySQL-Fehler wurden bei Datenbankmigrationen aufgedeckt, da es leichte Tabellenunterschiede zwischen einer Neuinstallation und Tabellen gibt, die von einer Version zur anderen migriert wurden. Dies hat Auswirkungen auf große reale Datensätze, die Sie bei einem Produktionsausfall nicht erleben möchten.
Künstliche Maßstabstests können nur so weit gehen. Nachdem Ihre Cloud aktualisiert wurde, müssen Sie die Leistungsaspekte Ihrer Cloud sorgfältig beachten.
Upgrade-Level¶
Upgrade-Level sind eine Funktion, die OpenStack Compute seit der Grizzly-Version hinzugefügt wurde, um eine Versionssperre für die RPC-Kommunikation (Message Queue) zwischen den verschiedenen Compute-Diensten zu ermöglichen.
Diese Funktionalität ist ein wichtiger Bestandteil des Puzzles bei Live-Upgrades und ähnelt konzeptionell der bestehenden API-Versionierung, die es OpenStack-Diensten verschiedener Versionen ermöglicht, problemlos zu kommunizieren.
Ohne Upgrade-Level kann ein X+1 Version Compute Service X Version RPC-Nachrichten empfangen und verstehen, aber er kann nur X+1 Version RPC-Nachrichten senden. Wenn beispielsweise ein nova-conductor-Prozess auf die X+1-Version aktualisiert wurde, dann kann der Conductor-Service Nachrichten von nova-compute-Prozessen der X-Version verstehen, aber diese Compute-Services können die vom Conductor-Service gesendeten Nachrichten nicht verstehen.
Während eines Upgrades können Betreiber Konfigurationsoptionen zu nova.conf hinzufügen, die die Version von RPC-Nachrichten sperren und ein Live-Upgrade der Dienste ohne Unterbrechung durch Versionsinkongruenz ermöglichen. Die Konfigurationsoptionen erlauben die Angabe von RPC-Versionsnummern auf Wunsch, aber auch Release-Namen-Aliase werden unterstützt. Zum Beispiel:
[upgrade_levels]
compute=X
conductor=X
scheduler=X
will keep the RPC version locked across the specified services to the
RPC version used in X. As all instances of a particular service are
upgraded to the newer version, the corresponding line can be removed
from nova.conf.
Mit dieser Funktionalität würde man idealerweise die RPC-Version an die OpenStack-Version binden, die von nova-compute nodes aktualisiert wird, um sicherzustellen, dass z.B. X+1-Version nova-compute-Prozesse weiterhin mit X-Version nova-conductor-Prozessen arbeiten, während das Upgrade abgeschlossen ist. Nach Abschluss des Upgrades der nova-compute-Prozesse kann der Betreiber mit dem Upgrade von nova-conductor fortfahren und die Versionssperre für nova-compute in nova.conf entfernen.
Upgrade-Prozess¶
Dieser Abschnitt beschreibt den Prozess zum Aktualisieren einer grundlegenden OpenStack-Bereitstellung auf der Grundlage der grundlegenden Zweiknotenarchitektur in den Installations-Tutorials und -Anleitungen. Alle Knoten müssen eine unterstützte Distribution von Linux mit einem aktuellen Kernel und den aktuellen Release-Paketen ausführen.
Dienstspezifische Upgrade-Anweisungen¶
In den folgenden Upgrade-Hinweisen finden Sie Informationen zum Upgrade bestimmter OpenStack-Dienste:
Voraussetzungen¶
Führen Sie vor Beginn des Upgrade-Prozesses eine gewisse Reinigung der Umgebung durch, um einen konsistenten Zustand sicherzustellen. Beispielsweise können Instanzen, die nach dem Löschen nicht vollständig aus dem System entfernt wurden, zu unbestimmtem Verhalten führen.
In Umgebungen, die den OpenStack Networking-Dienst (Neutron) verwenden, überprüfen Sie die Release-Version der Datenbank. Zum Beispiel:
# su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf \ --config-file /etc/neutron/plugins/ml2/ml2_conf.ini current" neutron
Durchführen einer Sicherung¶
Speichern Sie die Konfigurationsdateien auf allen Knoten. Zum Beispiel:
# for i in keystone glance nova neutron openstack-dashboard cinder heat ceilometer; \ do mkdir $i-RELEASE_NAME; \ done # for i in keystone glance nova neutron openstack-dashboard cinder heat ceilometer; \ do cp -r /etc/$i/* $i-RELEASE_NAME/; \ done
Bemerkung
Sie können dieses Beispielskript auf jedem Knoten ändern, um verschiedene Dienste zu verwalten.
Erstellen Sie eine vollständige Datenbanksicherung Ihrer Produktionsdaten. Seit der Kilo-Version werden Datenbank-Downgrades nicht mehr unterstützt, und die Wiederherstellung aus dem Backup ist die einzige verfügbare Methode, um eine frühere Datenbankversion abzurufen.
# mysqldump -u root -p --opt --add-drop-database --all-databases > RELEASE_NAME-db-backup.sql
Bemerkung
Erwägen Sie, Ihre SQL-Serverkonfiguration zu aktualisieren, wie in den Installations-Tutorials und Anleitungen beschrieben.
Verwalten von Repositories¶
Auf allen Knoten:
Entfernen Sie das Repository für die vorherigen Release-Pakete.
Fügen Sie das Repository für die neuen Release-Pakete hinzu.
Aktualisieren Sie die Repository-Datenbank.
Upgrade-Pakete auf jedem Knoten¶
Abhängig von Ihrer spezifischen Konfiguration kann die Aktualisierung aller Pakete einen Neustart oder eine Unterbrechung der Dienste als Ergänzung zu Ihrer OpenStack-Umgebung bewirken. Wenn Sie beispielsweise das TGT iSCSI-Framework für Block Storage-Volumes verwenden und das Upgrade neue Pakete für diese enthält, kann der Paketmanager die TGT iSCSI-Dienste neu starten und die Konnektivität auf Volumes beeinträchtigen.
Wenn der Paketmanager Sie auffordert, die Konfigurationsdateien zu aktualisieren, lehnen Sie die Änderungen ab. Der Paketmanager fügt neueren Versionen von Konfigurationsdateien ein Suffix hinzu. Erwägen Sie, Inhalte aus diesen Dateien zu überprüfen und zu übernehmen.
Bemerkung
Möglicherweise müssen Sie das Paket ipset explizit installieren, wenn Ihre Distribution es nicht als Abhängigkeit installiert.
Aktualisierungsdienste¶
Um einen Dienst auf jedem Knoten zu aktualisieren, ändern Sie in der Regel eine oder mehrere Konfigurationsdateien, stoppen den Dienst, synchronisieren das Datenbankschema und starten den Dienst. Einige Dienste erfordern unterschiedliche Schritte. Wir empfehlen, den Betrieb jedes Dienstes zu überprüfen, bevor Sie mit dem nächsten Dienst fortfahren.
Die Reihenfolge, in der Sie die Dienste aktualisieren sollten, und alle Änderungen, die sich aus dem allgemeinen Upgrade-Prozess ergeben, werden im Folgenden beschrieben:
Controller node
Identitätsdienst - Löschen Sie alle abgelaufenen Token, bevor Sie die Datenbank synchronisieren.
Image service [Abbilddienst (glance)]
Rechendienst, einschließlich Netzwerkkomponenten.
Netzwerkdienst (neutron)
Blockspeicherdienst (cinder)
Dashboard - In typischen Umgebungen erfordert die Aktualisierung des Dashboards nur einen Neustart des Apache HTTP-Dienstes.
Orchestrierungsdienst (heat)
Telemetriedienst - In typischen Umgebungen erfordert die Aktualisierung des Telemetriedienstes nur einen Neustart des Dienstes.
Compute Service - Bearbeiten Sie die Konfigurationsdatei und starten Sie den Dienst neu.
Netzwerkdienst - Bearbeiten Sie die Konfigurationsdatei und starten Sie den Dienst neu.
Speicherknoten
Blockspeicherdienst - Die Aktualisierung des Blockspeicherdienstes erfordert nur einen Neustart des Dienstes.
Compute-Knoten
Netzwerkdienst - Bearbeiten Sie die Konfigurationsdatei und starten Sie den Dienst neu.
Letzte Schritte¶
Bei allen Distributionen müssen Sie einige abschließende Aufgaben ausführen, um den Upgrade-Prozess abzuschließen.
Verringern Sie die DHCP-Timeouts, indem Sie die Datei
/etc/nova/nova.confauf den Compute-Knoten auf den ursprünglichen Wert für Ihre Umgebung zurücksetzen.Aktualisieren Sie alle
.iniDateien, um Passwörter und Pipelines entsprechend der OpenStack-Version in Ihrer Umgebung anzupassen.Nach der Migration sehen die Benutzer unterschiedliche Ergebnisse von openstack image list und glance image-list. Um sicherzustellen, dass Benutzer die gleichen Abbilder in den Listenbefehlen sehen, bearbeiten Sie die Datei
/etc/glance/policy.jsonund die Datei/etc/nova/policy.jsonso, dass sie"context_is_admin" enthält: "role:admin"`, die den Zugriff auf private Abbilder für Projekte einschränkt.Überprüfen Sie den ordnungsgemäßen Betrieb Ihrer Umgebung. Benachrichtigen Sie dann Ihre Benutzer, dass ihre Cloud wieder normal funktioniert.
Zurücksetzen eines fehlgeschlagenen Upgrades¶
Dieser Abschnitt enthält Anleitungen für das Zurücksetzen auf eine frühere Version von OpenStack. Alle Distributionen folgen einem ähnlichen Verfahren.
Warnung
Das Zurücksetzen Ihrer Umgebung sollte die letzte Maßnahme sein, da Sie wahrscheinlich alle seit dem Backup hinzugefügten Daten verlieren werden.
Ein häufiges Szenario ist es, die Produktionsverwaltungsdienste zur Vorbereitung auf ein Upgrade abzuschalten, einen Teil des Upgrade-Prozesses abzuschließen und ein oder mehrere Probleme zu entdecken, die während des Tests nicht aufgetreten sind. Infolgedessen müssen Sie Ihre Umgebung in den ursprünglichen „bekannt guten“ Zustand zurücksetzen. Sie haben auch sichergestellt, dass Sie nach dem Versuch des Upgrade-Prozesses keine Zustandsänderungen vorgenommen haben; keine neuen Instanzen, Netzwerke, Speicherdatenträger usw. Jede dieser neuen Ressourcen befindet sich in einem eingefrorenen Zustand, nachdem die Datenbanken aus dem Backup wiederhergestellt wurden.
In diesem Rahmen müssen Sie diese Schritte ausführen, um Ihre Umgebung erfolgreich zurückzusetzen:
Rollback der Konfigurationsdateien.
Wiederherstellen von Datenbanken aus dem Backup.
Pakete zurücksetzen.
Sie sollten sicherstellen, dass Sie über die erforderlichen Sicherungen verfügen, um diese wiederherzustellen. Das Zurücksetzen von Upgrades ist ein kniffliger Prozess, da Distributionen dazu neigen, viel mehr Aufwand in das Testen von Upgrades zu stecken als Downgrades. Zerrüttete Downgrades erfordern deutlich mehr Aufwand bei der Fehlersuche und -behebung als defekte Upgrades. Nur Sie können die Risiken, ein fehlgeschlagenes Upgrade voranzutreiben, gegen ein Zurückrollen abwägen. Im Allgemeinen sollten Sie das Zurücksetzen als allerletzte Option in Betracht ziehen.
Die folgenden für Ubuntu beschriebenen Schritte haben auf mindestens einer Produktionsumgebung funktioniert, aber sie funktionieren möglicherweise nicht für alle Umgebungen.
Um einen Rollback durchzuführen
Stoppen Sie alle OpenStack-Dienste.
Kopieren Sie den Inhalt der Konfigurations-Backup-Verzeichnisse, die Sie während des Upgrade-Prozesses erstellt haben, zurück in das Verzeichnis
/etc/<service>.Stellen Sie Datenbanken aus der Sicherungsdatei
RELEASE_NAME-db-backup.sqlwieder her, die Sie mit dem Befehl mysqldump während des Upgrade-Prozesses erstellt haben:# mysql -u root -p < RELEASE_NAME-db-backup.sql
Downgrade von OpenStack-Paketen.
Warnung
Die Herabstufung von Paketen ist bei weitem der komplizierteste Schritt; er ist stark abhängig von der Verteilung und der gesamten Administration des Systems.
Bestimmen Sie, welche OpenStack-Pakete auf Ihrem System installiert sind. Verwenden Sie den Befehl dpkg --get-selections. Filtern Sie nach OpenStack-Paketen, filtern Sie erneut, um Pakete auszulassen, die explizit im Zustand
Deinstallierenmarkiert sind, und speichern Sie die endgültige Ausgabe in einer Datei. Der folgende Befehl umfasst beispielsweise einen Controller-Knoten mit Keystone, glance, nova, neutron und cinder:# dpkg --get-selections | grep -e keystone -e glance -e nova -e neutron \ -e cinder | grep -v deinstall | tee openstack-selections cinder-api install cinder-common install cinder-scheduler install cinder-volume install glance install glance-api install glance-common install glance-registry install neutron-common install neutron-dhcp-agent install neutron-l3-agent install neutron-lbaas-agent install neutron-metadata-agent install neutron-plugin-openvswitch install neutron-plugin-openvswitch-agent install neutron-server install nova-api install nova-common install nova-conductor install nova-consoleauth install nova-novncproxy install nova-objectstore install nova-scheduler install python-cinder install python-cinderclient install python-glance install python-glanceclient install python-keystone install python-keystoneclient install python-neutron install python-neutronclient install python-nova install python-novaclient install
Bemerkung
Je nach Servertyp können Inhalt und Reihenfolge Ihrer Paketliste von diesem Beispiel abweichen.
Sie können die für die Reversion verfügbaren Paketversionen mit dem Befehl
apt-cache policybestimmen. Zum Beispiel:# apt-cache policy nova-common nova-common: Installed: 2:14.0.1-0ubuntu1~cloud0 Candidate: 2:14.0.1-0ubuntu1~cloud0 Version table: *** 2:14.0.1-0ubuntu1~cloud0 500 500 http://ubuntu-cloud.archive.canonical.com/ubuntu xenial-updates/newton/main amd64 Packages 100 /var/lib/dpkg/status 2:13.1.2-0ubuntu2 500 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 2:13.0.0-0ubuntu2 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
Bemerkung
Wenn Sie die Release-Repositories entfernt haben, müssen Sie sie zunächst neu installieren und den Befehl apt-get update ausführen.
Die Befehlsausgabe listet die aktuell installierte Version des Pakets, die neueste Kandidatenversion und alle Versionen zusammen mit dem Repository, das jede Version enthält. Suchen Sie in diesem Fall nach der passenden Release-Version -
2:14.0.1-0ubuntu1~cloud0. Der Prozess der manuellen Kommissionierung durch diese Liste von Paketen ist ziemlich mühsam und fehleranfällig. Sie sollten in Betracht ziehen, ein Skript zu verwenden, um bei diesem Prozess zu helfen. Zum Beispiel:# for i in `cut -f 1 openstack-selections | sed 's/neutron/;'`; do echo -n $i ;apt-cache policy $i | grep -B 1 RELEASE_NAME | grep -v Packages | awk '{print "="$1}';done | tr '\n' ' ' | tee openstack-RELEASE_NAME-versions cinder-api=2:9.0.0-0ubuntu1~cloud0 cinder-common=2:9.0.0-0ubuntu1~cloud0 cinder-scheduler=2:9.0.0-0ubuntu1~cloud0 cinder-volume=2:9.0.0-0ubuntu1~cloud0 glance=2:13.0.0-0ubuntu1~cloud0 glance-api=2:13.0.0-0ubuntu1~cloud0 500 glance-common=2:13.0.0-0ubuntu1~cloud0 500 glance-registry=2:13.0.0-0ubuntu1~cloud0 500 neutron-common=2:9.0.0-0ubuntu1~cloud0 neutron-dhcp-agent=2:9.0.0-0ubuntu1~cloud0 neutron-l3-agent=2:9.0.0-0ubuntu1~cloud0 neutron-lbaas-agent=2:9.0.0-0ubuntu1~cloud0 neutron-metadata-agent=2:9.0.0-0ubuntu1~cloud0 neutron-server=2:9.0.0-0ubuntu1~cloud0 nova-api=2:14.0.1-0ubuntu1~cloud0 nova-common=2:14.0.1-0ubuntu1~cloud0 nova-conductor=2:14.0.1-0ubuntu1~cloud0 nova-consoleauth=2:14.0.1-0ubuntu1~cloud0 nova-novncproxy=2:14.0.1-0ubuntu1~cloud0 nova-objectstore=2:14.0.1-0ubuntu1~cloud0 nova-scheduler=2:14.0.1-0ubuntu1~cloud0 python-cinder=2:9.0.0-0ubuntu1~cloud0 python-cinderclient=1:1.9.0-0ubuntu1~cloud0 python-glance=2:13.0.0-0ubuntu1~cloud0 python-glanceclient=1:2.5.0-0ubuntu1~cloud0 python-neutron=2:9.0.0-0ubuntu1~cloud0 python-neutronclient=1:6.0.0-0ubuntu1~cloud0 python-nova=2:14.0.1-0ubuntu1~cloud0 python-novaclient=2:6.0.0-0ubuntu1~cloud0 python-openstackclient=3.2.0-0ubuntu2~cloud0
Verwenden Sie den Befehl apt-get install, um bestimmte Versionen jedes Pakets zu installieren, indem Sie
<package-name>=<version>angeben. Das Skript im vorherigen Schritt hat bequem eine Liste von ``Paket=Version``Paaren für Sie erstellt:# apt-get install `cat openstack-RELEASE_NAME-versions`
Dieser Schritt schließt den Rollback-Vorgang ab. Sie sollten das Upgrade-Release-Repository entfernen und apt-get update ausführen, um versehentliche Upgrades zu verhindern, bis Sie das Problem lösen, das Sie veranlasst hat, Ihre Umgebung zurückzusetzen.
