Dieser Artikel ist ein Artikel vom 3. Dezember von OpenStack Adventskalender 2015.
Neulich habe ich die OpenStack-Umgebung sofort von Juno auf Liberty aktualisiert.
Der Grund, warum ich das getan habe, war, dass ich dachte, ich könnte es selbst tun, als ich neulich beim OpenStack Summit Tokyo eine Sitzung sah, bei der PayPal von Folsom auf Kilo aktualisiert wurde.
Nein, daher konnte ich ein Upgrade durchführen.
Deshalb denke ich, dass ich zu einer Säule der Menschen geworden bin, also habe ich beschlossen, hier über diese Zeit zu schreiben.
Klicken Sie hier für die PayPal-Sitzung.
PayPal's Cloud Journey From Folsom to Kilo -- What We Learned in the Upgrade
| Component | Type |
|---|---|
| OS | Ubuntu 14.04 |
| OpenStack | Juno |
| Hypervisor | KVM |
| Neutron Driver | VLAN + OVS (L3 Agent funktioniert nicht) |
| Cinder | Keine Ahnung |
Ich denke, es ist üblich, dies in der Reihenfolge Keystone-> Glance-> Nova-> Neutron zu tun. Auf dem Design Summit sagten einige Unternehmen, dass die Versionen der einzelnen Komponenten unterschiedlich seien, sodass die Reihenfolge nur als Referenz dient. Wenn Sie jedoch alle Komponenten aktualisieren möchten, ist diese Reihenfolge gut.
Ein Non-Stop-Upgrade ist übrigens absolut unmöglich, so Akira Melon. Das haben die Onkel des Hackers auf dem Design Summit gesagt.
Du hast recht.
. .. _ Leises Gespräch _ .. .
Lösen Sie die Verbindung zu Port 5000 des Load Balancers an der Vorderseite von Keystone und beenden Sie die Kommunikation von außen vollständig. Es scheint, dass es kein Problem mit Port 35357 gibt.
Stellen Sie zunächst das Liberty Release-Repository auf jeden Server.
$ sudo echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu trusty-updates/liberty main" > /etc/apt/sources.list.d/cloudarchive-liberty.list
$ sudo apt-get update
Löschen Sie die in der Keystone-Datenbank gesammelten Token. In Liberty wird Memcached standardmäßig für Token-Zwecke verwendet, daher habe ich mich für die Verwendung entschieden. Mit anderen Worten, es ist erforderlich, im Voraus einen Server für Memcached vorzubereiten.
$ sudo su -s /bin/sh -c "keystone-manage token_flush" keystone
Nach dem sauberen Löschen des DB-Tokens ist der nächste Stopp Cron, der regelmäßig ausgeführt wurde.
$ sudo crontab -e -u keystone
Löschen Sie die folgende Zeile.
@hourly /usr/bin/keystone-manage token_flush > /var/log/keystone/keystone-tokenflush.log 2>&1
Sei anmutig und stoppe Keystone.
$ sudo service keystone stop
Melden Sie sich beim DB-Server an und sichern Sie die DB mit dem folgenden Befehl.
$ sudo mysqldump -uroot -p --opt --add-drop-database --single-transaction --master-data=2 keystone > liberty-keytone-db-backup.sql
$ sudo mysqldump -uroot -p --opt --add-drop-database --single-transaction --master-data=2 glance > liberty-glance-db-backup.sql
$ sudo mysqldump -uroot -p --opt --add-drop-database --single-transaction --master-data=2 nova > liberty-nova-db-backup.sql
$ sudo mysqldump -uroot -p --opt --add-drop-database --single-transaction --master-data=2 neutron > liberty-neutron-db-backup.sql
Aktualisieren Sie jetzt Keystone. Verschiedene Parameter wurden neu hinzugefügt oder sind veraltet, aber ich kann nicht darüber schreiben. Verwenden Sie daher bitte Configuration Reference. Bitte nehmen Sie Bezug darauf. Das Upgrade selbst ist so einfach wie "apt-get install XXXX" und dann "keystone.conf" neu schreiben, um den Prozess zu starten. Grundsätzlich gibt es kein Problem, wenn Sie die Installationsprozedur befolgen.
Übrigens, wenn Sie die DEBUG-Option in "conf" setzen, werden alle in jedem Element von "conf" festgelegten Werte sofort nach dem Start des Prozesses in das Protokoll ausgegeben. Freundlicherweise weist er auch auf Gegenstände hin, die abgeschafft werden. Dies ist ein Mechanismus, der allen Komponenten gemeinsam ist. Es lohnt sich also, sich daran zu erinnern. Apropos, in dem Punkt "Benutzername" von Nova habe ich die Verwendung von "Benutzername" eingestellt, da "Benutzername" abgeschafft werden soll, und es wurde mit "Benutzername" protokolliert. Wenn ich ihn also nicht mehr verwende und "Benutzername" verwende, wird ein Fehler ausgegeben. Nova steckte fest. Ist es Tundere?
Die Geschichte ging schief.
Migrieren Sie nach dem Platzieren von "keystone.conf" das DB-Schema bis zur Liberty-Version mit dem folgenden Befehl. Seit Kilo läuft Keystone auf Apache. Stellen Sie daher sicher, dass der Keystone-Prozess im Voraus gestoppt wurde, und starten Sie Apache.
$ sudo service keystone stop
$ sudo service apache2 restart
$ sudo su -s /bin/sh -c "keystone-manage db_sync" keystone
Wenn keine Fehler vorliegen, ist das Keystone-Upgrade abgeschlossen.
Lassen Sie uns vorerst prüfen, ob der Befehl openstack ausgeführt werden kann.
$ ADMIN_TOKEN=${keystone.admin in conf aufgeführt_Token-Zeichenfolge}
$ export OS_TOKEN=${ADMIN_TOKEN}
$ export OS_URL=http://${IP-Adresse eines Servers, auf dem Keystone ausgeführt wird}:35357/v3
$ export OS_IDENTITY_API_VERSION=3
$ openstack service list
Überprüfen Sie wie bei Keystone die Konfigurationsreferenz und die offizielle Installationsanleitung und platzieren Sie die Ihrer Website entsprechenden "look-api.conf" und "blick-registry.conf".
Dann mache Glances db sync.
$ sudo service glance-api restart
$ sudo service glance-registry restart
$ sudo su -s /bin/sh -c "glance-manage db_sync" glance
Wenn keine Fehler vorliegen, ist das Glance-Upgrade abgeschlossen.
Die größte Herausforderung. Wenn Sie Novas Datenbank erfolgreich nach Liberty migrieren können, können Sie sie aktualisieren. Die Realität lief jedoch nicht so gut.
In diesem Abschnitt habe ich beschlossen, die Situation zu beschreiben, in der das Upgrade nicht gut verlief.
Zuerst habe ich nova-api auf dem Server mit nova-api auf Liberty aktualisiert.
$ sudo apt-get install nova-api python-novaclient
Führen Sie danach db sync aus, und wenn es kein Problem gibt, aktualisieren Sie andere Komponenten so wie sie sind und es wird abgeschlossen sein (sollte sein).
Also drückte ich den folgenden Befehl:
$ sudo su -s /bin/sh -c "nova-manage db sync" nova
Ein Fehler ist aufgetreten: (
Der Inhalt des Fehlers ist
nova-manage db migrate_flavor_data aus, bevor Sie db sync ausführen.Ist.
Tatsächlich enthält der Befehl "nova-manage" in der Liberty-Version diese Option __ jedoch nicht. Ich habe den Quellcode gelesen und nachgeschlagen, aber er war nicht wirklich da. Ich fand es dumm, aber zu diesem Zeitpunkt war das DB-Schema selbst zur Hälfte geändert worden.
In diesem Zustand wurde Folgendes getan.
Das nächste, was ich vermutete, war die Veröffentlichung von Kilo. Also habe ich folgendes gemacht:
nova-api für Kilo Releasenova-manage db migrate_flavor_data ausnova-manage db sync aus"Nova-api", das durch Hinzufügen des Kilo-Release-Repositorys installiert wurde, hatte "migrate_flavor_data" als Option für "nova-manage". Kitakore! Ich habe sofort nova-manage db migrate_flavor_data ausgeführt. Dann war es erfolgreich, also entschied ich mich, es für Kilo Release und dann für Liberty freizugeben, also synchronisiere ich bis zur Kilo-Veröffentlichung.
Dann habe ich einen weiteren Fehler bekommen: (
Der Fehler war, dass das Schema der Tabelle in flavor falsch war. Ich dachte, es wäre eine Lüge, aber es war ernst. Um die Art und den Status des Fehlers zusammenzufassen, führen Sie nova-manage db migrate_flavor_data nach Kilo release db sync und vor Liberty release db sync aus.
Mit anderen Worten, die richtige Antwort lautet:
nova-api für Kilo Releasenova-manage db sync ausnova-manage db migrate_flavor_data ausNova-API Installationnova-manage db sync ausZu diesem Zeitpunkt wurde das DB-Schema wieder zur Hälfte geändert, sodass ich zur Zeit der Juno-Veröffentlichung zurückkehrte und die DB löschte und wiederherstellte (zum zweiten Mal). Danach habe ich versucht, zum Zeitpunkt der Veröffentlichung von Juno zu nova-api zurückzukehren, aber _dieser Zeitpunkt apt war unterbrochen .....
Ich musste so oft zwischen Juno, Kilo und Liberty hin und her gehen, dass die abhängigen Pakete seltsam waren und nicht installiert oder entfernt werden konnten. Ich konnte nicht anders, also habe ich den Befehl dpkg verwendet, um alle drei abhängigen Pakete (Juno, Kilo, Liberty) zu entfernen, die Abhängigkeiten von Nova haben. Dann fing apt an zu arbeiten, also musste ich zur Juno-Version zurückkehren und es erneut versuchen.
Während ich das tat, war der Soft-Globe-Song „Lass uns zur Schule gehen!“, Den ich neulich im Fernsehen gemacht habe, in meinem Gehirn.
"Es ist dumm" "Das stimmt, es ist dumm"
Es ist ein Meisterwerk.
. .. _ Leises Gespräch _ .. .
Auf der Grundlage des oben Gesagten werde ich das erfolgreiche Verfahren beschreiben.
Installieren Sie die Kilo-Version.
$ sudo echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu trusty-updates/kilo main" > /etc/apt/sources.list.d/cloudarchive-kilo.list
$ sudo apt-get update
$ sudo apt-get install nova-api python-novaclient
Migrieren Sie zum Zeitpunkt der Veröffentlichung von Kilo zum Schema.
$ sudo service nova-api restart
$ sudo su -s /bin/sh -c "nova-manage db sync" nova
$ sudo su -s /bin/sh -c "nova-manage db migrate_flavor_data" nova
Dann auf Liberty Release erhöhen.
$ sudo echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu trusty-updates/liberty main" > /etc/apt/sources.list.d/cloudarchive-liberty.list
$ sudo apt-get update
$ sudo apt-get install nova-api python-novaclient
Migrieren Sie zum Zeitpunkt der Liberty-Version zum Schema.
$ sudo service nova-api restart
$ sudo su -s /bin/sh -c "nova-manage db sync" nova
Damit ist das Upgrade von "nova-api" und die Migration von Nova DB abgeschlossen.
Übrigens wurde diese DB-Migrationsprozedur in Kilos Versionshinweis tatsächlich nur in einer Zeile beschrieben. Es ist jedoch immer noch nicht sehr nett, daher glaube ich, dass ich süchtig danach war, auch wenn ich es vorher überprüft habe.
Aktualisieren Sie nach dem Upgrade von "nova-api" den "Neutronenserver".
Überprüfen Sie wie bei Keystone die Konfigurationsreferenz und die offizielle Installationsanleitung und platzieren Sie "neutron.conf" und andere Dinge, die zu Ihrer Umgebung passen. Beachten Sie, dass Open vSwitch über eine separate ml2-Konfigurationsdatei verfügt.
Dann mache Neutrons db sync.
$ sudo service neutron-server restart
$ sudo su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron
Wenn keine Fehler vorliegen, wurde die Datenbank von Neutron zum Zeitpunkt der Veröffentlichung von Liberty in das Schema migriert.
Sobald Sie dies getan haben, aktualisieren Sie alle verbleibenden Pakete. Von hier an sollte es kein besonderes Problem geben (sollte). Was und wie aktualisiert werden muss, hängt von der jeweiligen Umgebung ab. Daher werde ich es hier nicht beschreiben.
Verknüpfen Sie einen realen Server mit Port 5000 des Load Balancers auf der Vorderseite von Keystone.
Horizon spielt keine Rolle, wenn die Version nicht mit anderen Komponenten übereinstimmt. Daher ist es in Ordnung, jedes Mal ein Upgrade durchzuführen, wenn OpenStack veröffentlicht wird.
Wenn es jedoch um die Liberty-Version __ geht oder wenn es um die Liberty-Version deb geht, schlägt das Upgrade fehl.
Es sind keine Details bekannt, warum es nicht funktioniert hat. Vorerst habe ich beschlossen, aufzuschreiben, was passiert ist. Es tut mir Leid.
Diesmal bin ich auf ein Ereignis gestoßen, bei dem sich das deb-Paket während einer Neuinstallation und eines Upgrades anders verhalten hat. Normalerweise (wahrscheinlich) ist dies nicht der Fall, aber was die Liberty-Version von Horizons deb-Paket betrifft, verhält es sich anders.
Wenn Sie auf einem Horizon-Server, der in der Juno-Version ausgeführt wurde, die Horizon-Version mit "apt-get upgrade" oder "apt-get install openstack-dashboard" aktualisieren, wird das CSS nicht geladen und Horizon unternimmt um 2000 nichts. Es wird wie eine einfache Webseite gestaltet.
Horizon hatte auch mehr Komponenten und war durcheinander, also dachte ich für einen Moment, dass ich das Design geändert hatte, indem ich sagte: Einfach ist am besten, aber das war überhaupt nicht der Fall. Egal wie viel es gegen die Zeit geht.
. .. _ Leises Gespräch _ .. .
Ich habe mich gefragt, ob es vorerst ein Problem mit dem Upgrade-Prozess gibt. Deshalb habe ich die Zeile "deb-src" der Liberty-Version zum Repository hinzugefügt und das deb-Paket des Openstack-Dashboards gelöscht, um dies herauszufinden.
$ sudo echo "deb-src http://ubuntu-cloud.archive.canonical.com/ubuntu trusty-updates/liberty main" >> /etc/apt/sources.list.d/cloudarchive-liberty.list
$ sudo apt-get update
$ sudo apt-get source openstack-dashboard
$ tar zxvf horizon_8.0.0-0ubuntu2~cloud0.debian.tar.gz
$ cd debian
Als ich "README.source" öffnete, wurde sofort Folgendes geschrieben.
During the Juno/14.10 development cycle, use of xstatic packages was introduced
so that CSS, JS and other static assets did not have to be embedded in the
horizon source tree.
Verdächtig, sehr verdächtig.
Übrigens, wenn ich zur Icehouse-Version zurückkehre und die Quelle lösche, wird diesmal Folgendes in die Datei "README.compression" geschrieben.
Until this can be scripted and integrated into package build, updating the
pre-compressed static CSS and JS requires a some manual steps:
sudo apt-get install python-lesscpy python-openstack-auth python-compressor
quilt pop top
./debian/rules refresh-static-assets
HM.
Wenn Sie die Regeldatei richtig lesen, werden Sie die richtige Ursache herausfinden.
Aber ich war zu diesem Zeitpunkt völlig erschöpft.
Das einzige, was ich weiß, ist, dass, sobald Sie alle Juno-Release-Horizon-Pakete (einschließlich Django) entfernt und die Liberty-Release-Pakete wieder eingefügt haben, es einwandfrei funktioniert. Dieses Ereignis tritt nicht auf, wenn von Juno nach Kilo erhöht wird. Dies geschieht nur, wenn Sie ein Upgrade von Juno auf Liberty oder von Kilo auf Liberty durchführen.
Also, wenn jemand die Details kennt, lass es mich wissen;)
Wenn Sie in Canonical sind, tun Sie bitte etwas gegen dieses deb-Paket :-(
Damit ist das Upgrade der OpenStack-Umgebung abgeschlossen. Wenn ich diese Art von Arbeit manuell erledigen würde, würde ich natürlich irgendwann eine Entzündung der Zahnscheide bekommen. Wenn Ihnen das nicht gefällt, sollten Sie Chef, Puppet, Ansible usw. verwenden. vielleicht.
Danke für deine harte Arbeit:-)
Dies ist die Geschichte von "Neutron-DHCP-Agent". Kennt ihr RFC3442? Ich wusste es bis vor kurzem nicht (sorry). Grundsätzlich hängt die Verteilung von Adressen und Routen von DHCP ab. Daher wurde die DHCP-Spezifikation erweitert und ein Mechanismus eingeführt, um die statische Routentabelle gleichzeitig beim Zuweisen einer IP-Adresse zu verteilen. Das ist die "klassenlose statische Route" (RFC3442).
Es scheint, dass die RFC3442-Implementierung zum Zeitpunkt der Juno-Veröffentlichung unterstützt wurde, aber anscheinend funktionierte sie nicht richtig. Zum Zeitpunkt der Veröffentlichung von Kilo gab es eine Fehlerbehebung, die mit der Veröffentlichung von Liberty einwandfrei funktionierte.
Was schief gelaufen ist, war, dass diese Implementierung so gut funktioniert hat, dass sich herausstellte, dass die von mir verwendeten externen Netzwerk-Subnetze falsch konfiguriert waren. Ich werde nicht erwähnen, wie ich einen Fehler gemacht habe, aber eine Sache, die ich sagen kann, ist, dass es schwer war.
In Bezug auf das Subnetz wurde festgestellt, dass eine Änderung der CIDR des Netzwerks das Ereignis heilen würde, es wurde jedoch auch festgestellt, dass die CIDR nicht über die Neutron-API geändert werden konnte. Ich konnte nichts dagegen tun, also löste ich es, indem ich den letzten Ausweg aus der Ausführung der UPDATE-Anweisung direkt in der Subsystemtabelle der Neutron-Datenbank nahm (hey).
Zu dem Zeitpunkt, als das Upgrade in der Produktionsumgebung durchgeführt wurde, wurde eine neue Liberty-Konstruktion mit derselben Konfiguration wie die Produktion einmal ausgeführt, und eine Überprüfungsumgebung mit derselben Konfiguration wie Juno wurde im Voraus erstellt, und ein Upgrade-Test von dort wurde einmal durchgeführt. Übrigens ist diese Geschichte eine Geschichte, die in der Verifizierungsumgebung passiert ist. Dank dessen konnte ich ein reibungsloses Upgrade in der Produktionsumgebung durchführen.
Jede Version von OpenStack wird ungefähr 14 Monate nach ihrer Veröffentlichung EOL erreichen. Mit anderen Worten, Bugfix wird nach seiner Veröffentlichung etwa 14 Monate lang zurückportiert, was den Tee schlammig machen kann. Alternativ können Sie nur Keystone für jede Release-Bindung aktualisieren und für andere Komponenten Region richtig definieren, um einen kleinen OpenStack-Cluster zu erstellen. Natürlich muss die EOL des erstellten OpenStack-Clusters selbst definiert werden.
Es gibt auch viele Probleme, die erst nach dem Upgrade auftreten. Es ist eine gute Idee, im Voraus auf Fehler und bekannte Probleme in Launchpad zu prüfen und diese als Kriterien für die Entscheidung zu verwenden, ob ein Upgrade durchgeführt werden soll. Wenn es jedoch um ein Upgrade kurz nach der Veröffentlichung geht, ist es nur eine Säule, und manchmal werden Fehler überhaupt nicht in Launchpad registriert.
Heute ist übrigens mein Geburtstag.
Recommended Posts