OpenStack: Die ganze Wahrheit über die "königliche" Veröffentlichung

Woland von M. Bulgakov sagte, dass "ein Ziegelstein ohne Grund niemals jemandem auf den Kopf fallen wird". Vielleicht ja, aber als sie mich vor zweieinhalb Jahren fragten, ob ich OpenStack kennenlernen wollte, war es dieser sehr gut verschleierte Ziegel (und nicht einmal ein Ziegel, sondern eine Granitplatte am Anfang). Es war 2016, das für mich zum sogenannten „Punkt ohne Wiederkehr“ wurde, der den Grundstein für die rasche Entwicklung der Konzepte der offenen Welt legte und die Mentalität maßgeblich beeinflusste und mein zukünftiges Leben in einen Urlaub verwandelte. "Urlaub", der immer bei mir ist.

2016 - heute

OpenStack war auf den ersten Blick keine Liebe. Die erste Version, die ich zum Testen bereitstellte, war Kilo, die sich leicht mit dem Wort "traurig" reimte. Nachdem er genau drei Wochen existiert hatte, hoffte er, durch Liberty ersetzt zu werden, der unter einem attraktiven Deckblatt - Release Notes - die hohen Erwartungen nicht erfüllen konnte. Mitaka hat nicht so sehr neue Funktionen gebracht, sondern viele Korrekturen und „Patches“ enthalten und wird immer noch (!) Erfolgreich in produktiven Umgebungen betrieben. Newton war in der Tat ein Wendepunkt in der Geschichte von OpenStack und bot so viele architektonische, logische und infolgedessen Konfigurationsänderungen, die den Upgrade-Pfad von der vorherigen Version für viele private Clouds für immer blockierten. Mit der Veröffentlichung von Ocata im Jahr 2017 begann laut Analysten das „goldene Zeitalter“ von OpenStack, zu dem Pike, Queens und, wie ich aufrichtig hoffe, Rocky, das sich auf einem niedrigen Start befindet, eintreten werden.


Dieser Artikel konzentriert sich auf die neueste stabile OpenStack-Version - Queens, auf einige Innovationen und Mängel - aus der Sicht einer Person, die ihre Bereitstellung auf der Grundlage der Ubuntu 16.04 LTS-Distribution automatisiert hat (und dies auch weiterhin tut, da der Perfektion keine Grenzen gesetzt sind). .

Es gibt nicht so viel Material über Queens im Netzwerk (wenn Sie offizielle Dokumentationen und Berichte vom jüngsten OpenStack Summit in Vancouver aus der Stichprobe ausschließen), und die Anzahl der Bewertungen von Cloud-Anbietern und Systemintegratoren kann an einer Hand gezählt werden. Es überrascht nicht, dass sein Vorgänger - Pike, dessen offizielle Unterstützung weitere acht Monate dauern wird - mit Hunderten von ausgearbeiteten Benutzern und einem gut dokumentierten Upgrade-Verfahren besser für die Implementierung geeignet ist. Unser Team, das den Queens-Entwicklungsprozess von Anfang an genau verfolgte, ging weiter als viele andere und brachte das "Neue" souverän in Produktion. Wie tief war das Kaninchenloch?

(Im Folgenden wird die OpenStack-Terminologie häufig verwendet. Es wird davon ausgegangen, dass der Leser zumindest mit der typischen Architektur vertraut ist.)

Nützliche Funktionen

1. Für mich persönlich war ein schöner Bonus in der neuen Version die Erweiterung der Funktionalität des nova-manage-Dienstprogramms: Jetzt können Sie Hosts aus einigen Zellen (Cells v2) löschen und auf andere übertragen! Pike musste separate Datenbankabfragen schreiben, und jetzt ist es "out of the box" verfügbar.
2. Das Erstellen einer benutzerdefinierten Rolle (standardmäßig _member_) für Keystone wird aus der Bootstrap-Phase herausgeschnitten. Der Grund dafür war der endgültige Übergang zu API v3, das über andere Formen von Autorisierungs- und Authentifizierungsmechanismen verfügt, was auch die Sicherheit der Infrastruktur erhöht (schließlich gab es auch eine feste ID für die Benutzerrolle ...). Dies bedeutet jedoch keineswegs, dass die Benutzerrolle nicht benötigt wird - früh oder früh Sie müssen es später erstellen.
   

   Prognose: Ab dieser Version ist die Identity API v2 veraltet. Seine Unterstützung wird wahrscheinlich in einem Jahr vollständig eingestellt (pessimistisch in der Stein-Veröffentlichung).

3. Neutron 13- und DHCP-Agenten hatten die Möglichkeit eines automatischen Failovers - automatisches Umschalten (Resheduling) von Netzwerken und Routern von ausgeschalteten zu aktiven Agenten. Die DVR-HA-Funktionalität ist standardmäßig aktiviert ( [DEFAULT]/router_distributed , [DEFAULT]/l3_ha ). DVR / SNAT wird in einem separaten Namespace zugewiesen. Beim Erstellen eines Routers wird standardmäßig Snat erstellt, wobei eine andere IP-Adresse aus dem internen Subnetz übernommen wird:
   
   Mit diesem Bundle können Sie bei einem Ausfall des SNAT-Dienstes schnell vom aktuellen zum Backup-Router des l3-Agenten wechseln, der auf einem anderen Knoten ausgeführt wird.
4. Alle Funktionen des Neutron-VPN-Agenten werden auf den 13-Agenten übertragen. In seiner Konfiguration müssen Sie die einzige Änderung vornehmen:
   
   

    [agent]/extensions = vpnaas 

   
   Schließlich störte das Vorhandensein eines VPN-Agenten die Konstruktion der automatischen Bereitstellungslogik im Falle der Aufnahme einer Rolle nicht mehr (zuvor schlossen sich VPN- und 13-Agenten gegenseitig aus: Wenn Sie ein Paket ablegen, wird das andere gelöscht).
5. Die Glance-Registrierung (Proxy für die Interaktion mit der Datenbank in API v1) wurde als veralteter Dienst deklariert. Jetzt können Sie nur den Blick-API-Dienst konfigurieren und benötigen ihn. Keine Überraschungen, aber sie werden etwas später besprochen.
6. Mama mia! Das Heat-Dashboard wird in einem separaten Paket (Plug-In-Panel) für Horizon geliefert. Das Plugin hat viele Änderungen erfahren, aber die unerwartetste Funktionalität war ... Drag & Drop-Objekte beim Generieren von Vorlagen. Einmal ist es einfacher zu sehen:
   
   
   
7. Unterstützung für Volume Multi-Attach in Cinder hinzugefügt - die Möglichkeit, eine einzelne Festplatte mit mehreren virtuellen Maschinen zu verbinden. Bisher wurde diese Funktionalität nur für eine begrenzte Anzahl von Treibern implementiert, die vom Dienst unterstützt werden : LVM, NetApp / SolidFire, Dell EMC ScaleIO und Oracle ZFSSA. Dies ist ein sehr großer Fortschritt für das gesamte Projekt (die Implementierung des Mechanismus dauerte mehr als zwei Jahre ).
   

   Prognose: Für Ceph wurde die RBD-Unterstützung für Cinder Volume Multi-Attach noch nicht angekündigt. höchstwahrscheinlich sollte es nicht früher als in einem Jahr erwartet werden (optimistisch - in der Stein-Version).

Ärgerliche Käfer

(Die folgenden Fehler wurden beim Bereitstellen von OpenStack Queens auf der Ubuntu 16.04.4 LTS-Distribution (Xenial Xerus) entdeckt. Es besteht die Möglichkeit, dass sie auf anderen Linux-Distributionen nicht angezeigt werden.)

1. In der Linux-Community gibt es so etwas wie einen „Betreuer“ - einen Spezialisten, der eine bestimmte Softwarekomponente (in einem bestimmten Fall ein Binärpaket) wartet / wartet / leitet. Daher stellten Ubuntu-Betreuer erneut (ein Fehler war in der Pike-Version vorhanden) Pakete für den regulären Zeitreihendatenbankdienst Gnocchi zur Verfügung. Wenn Sie sie in einer Python 2.7-Umgebung installieren, werden einige der unter libapache2-mod-wsgi ausgeführten Dienste "apt" unterbrochen: Keystone, Cinder, Nova Placement, Horizon. Der traurige Fall ist, wenn Sie eine einzige Methode zum Übermitteln von Paketen an das System verwenden möchten. Während für Gnocchi zumindest versucht wurde, Pakete zu kompilieren, existieren für Octavia nur noch pip und git.
2. Ich gebe nicht vor zu sagen, aber vielleicht waren dieselben Betreuer an der Erstellung von Nova-Compute-Paketen beteiligt. Dies würde zumindest erklären, warum das Installationsprogramm bei der Installation auf dem System (Kernel-Assemblys 116, 119 und 124; Paketversionen von 17.0.1 bis 17.0.4) mit einem Fehler "ausfällt":
   
   

    Setting up nova-compute-libvirt (2:17.0.1-0ubuntu1~cloud0) ... adduser: The user 'nova' does not exist. dpkg: error processing package nova-compute-libvirt (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of nova-compute-kvm: nova-compute-kvm depends on nova-compute-libvirt (= 2:17.0.1-0ubuntu1~cloud0); however: Package nova-compute-libvirt is not configured yet. 

   
   Hier ist die Sache: Während der Installation wird ein Skript ausgeführt, das die Nova-Systemgruppe und den Nova-Systembenutzer erstellen soll. Das Skript schlägt mit dem Fehler fehl, die Installation stürzt ab und die Automatisierung wird umgangen: Führen Sie die genannten Gesten aus, bevor Sie die Pakete installieren. Dieser Fehler ist übrigens noch nicht geschlossen.
   

   UPD: Beim Schreiben des Artikels wurde der Fehler endgültig bestätigt und die durchschnittliche Priorität festgelegt. Zum Zeitpunkt der Lösung des Problems (die zyklischen Abhängigkeiten der Nova-Pakete voneinander) schlug der Betreuer eine andere Problemumgehung vor: Installieren Sie zuerst das nova-common-Paket und dann nova-compute. In naher Zukunft können wir die Version der Pakete 17.0.5 erwarten, ohne diesen Nachteil.

3. Beim Testen des Betriebs des Neutron FWaaS-Dienstes stellte sich heraus, dass beim Entfernen einer Firewall von einem verteilten Router nichts passiert ... absolut. Die Firewall wechselt vom Status "Online" in den Status "Ausstehender Löschvorgang". Sie können das Problem entweder durch Abfragen der Datenbank oder durch Löschen des gesamten Routers lösen (dieser Fehler war in der Pike-Version vorhanden). Das Hauptproblem im Moment ist, dass das Update (das wirklich löst!) Vor einigen Monaten vorgeschlagen wurde, es aber immer noch nicht bis zur letzten stabilen Version geschafft hat.
4. Bereits in der Phase des Lasttests der Infrastruktur wurde festgestellt, dass der "Neutronen-OpenVswitch-Agent EATING CPU AAAAAAA" - im Leerlaufmodus der OpenVswitch-Agent einen der Prozessorkerne zu 100% geladen hat:
   
   

    $ ps aux | grep 16233 neutron 16233 99.5 0.0 311112 143156 ? Rs 19:47 67:11 /usr/bin/python2 /usr/bin/neutron-openvswitch-agent --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/plugins/ml2/openvswitch_agent.ini --log-file=/var/log/neutron/neutron-openvswitch-agent.log $ time strace -c -p 16233 % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000362 0 95725 epoll_wait 0.00 0.000000 0 15 read 0.00 0.000000 0 6 open 0.00 0.000000 0 6 close 0.00 0.000000 0 6 stat 0.00 0.000000 0 15 fstat 0.00 0.000000 0 20 sendto 0.00 0.000000 0 79 41 recvfrom 0.00 0.000000 0 2 setsockopt 0.00 0.000000 0 94 epoll_ctl ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000362 95968 41 total real 0m10.300s user 0m0.324s sys 0m2.576s 

   
   Die Lösung des Problems wurde von den Entwicklern des Dienstes so schnell wie möglich gefunden. Das Update ist in der Paketversion von Neutron 12.0.1-0ubuntu1.1 enthalten.

Royal Fakap

In OpenStack Queens haben Entwickler eine neue Methode zum Herunterladen von Bildern eingeführt - den Web-Download, mit dem der Endbenutzer ein Bild als Referenz "hochladen" kann. Es war einmal, als die Image-API v1 noch nicht veraltet war und nicht durch die API v2 ersetzt wurde. Es scheint, dass was schief gegangen sein könnte? ..


In der Blick-API-Dienstkonfiguration sind beide [DEFAULT]/enabled_import_methods - direkt und als Referenz - standardmäßig aktiviert ( [DEFAULT]/enabled_import_methods ). Um das einfache Ziel zu verfolgen, die Option zu testen, schalte ich eine der Methoden aus, überlade den Service und beeile mich!

 CRITICAL glance [-] Unhandled error: ValueError: tuple.index(x): x not in tuple ERROR glance Traceback (most recent call last): ERROR glance File "/usr/bin/glance-api", line 10, in <module> ERROR glance sys.exit(main()) ERROR glance File "/usr/lib/python2.7/dist-packages/glance/cmd/api.py", line 97, in main ERROR glance fail(e) ERROR glance File "/usr/lib/python2.7/dist-packages/glance/cmd/api.py", line 71, in fail ERROR glance return_code = KNOWN_EXCEPTIONS.index(type(e)) + 1 ERROR glance ValueError: tuple.index(x): x not in tuple 

Nachdem ich an dem Patch herumgebastelt habe, überlade ich den Service erneut:

 glance-api[26538]: ERROR: Value for option enabled_import_methods is not valid: Value should start with "[" systemd[1]: glance-api.service: Main process exited, code=exited, status=4/NOPERMISSION systemd[1]: glance-api.service: Unit entered failed state. systemd[1]: glance-api.service: Failed with result 'exit-code'. 

Ernsthaft oder was ?! Die Option in der Konfiguration hat die folgende unzureichende Form erhalten:

 [DEFAULT]/enabled_import_methods = [glance-direct] 

Natürlich wurde ein Fehler von mir sorgfältig geöffnet. Zum Zeitpunkt der Lösung des Problems haben Entwickler sogar eine Ankündigung zu diesen bekannten Problemen veröffentlicht, die ihnen bekannt war, und ein Commit an den Hauptzweig des Projekts gesendet. Zwei Monate nach der Entdeckung des Fehlers wurde das Update für eine zukünftige Version "verlassen". glückliche Queens-Besitzer müssen auf Pakete der Version 16.0.2 von Glance warten.
Alles ist gut, das endet gut.

"Verliere nicht deinen Kopf, schwinge deine Muskeln"

Während der Automatisierungsarbeiten für die Bereitstellung (einschließlich der Konfigurations- und Funktionstestschritte) erwies sich Queens als stark und nicht mit neuen Funktionen überladen, ohne dass von überall eine „Krücke“ hervorstand, die die Messlatte für seinen Nachfolger hoch legte.

Trotz der Tatsache, dass Queens die siebzehnte (!) OpenStack-Veröffentlichung ist, wird die allgemeine Tendenz seit vielen Jahren beibehalten: „Das Unvorhergesehene ist nicht durch unvorhergesehene Intuition vorhersehbar “. Dieses Zitat aus dem Atlantida-Projekt beschreibt meiner Meinung nach am besten die gesamte Bandbreite der Empfindungen, die durch die Interaktion mit dem Produkt entstehen. Einerseits wurde die Bereitstellung regulärer Dienste (Keystone, Glance, Swift, Cinder, Nova, Neutron, Horizon) mit Grundeinstellungen seit langem getestet und wird selbst für unerfahrene Ingenieure keine Probleme verursachen. Auf der anderen Seite beginnt bei der Einführung relativ junger Dienste der oben genannte „Urlaub“: Sortieren Sie ihn nach Belieben in der mageren Dokumentation, bereiten Sie sich darauf vor, Tage damit zu verbringen, den Code zu betrachten und auf dem beliebten Bug-Tracker zu sitzen.

All dieses Leiden ist jedoch nur eine Nebenwirkung des Stockholm-Syndroms. Tatsächlich erschüttert die Open-Stack-Übung das Gehirn schneller als jedes logische Spiel, entwickelt nützliche Fähigkeiten exponentiell, bleibt ständig in guter Form und lässt Sie sicherlich nicht langweilen. OpenStack war definitiv nicht meine Liebe auf den ersten Blick, reduziert auf weiße Hitze und Ohnmacht, aber es verdient jetzt definitiv ein bisschen Liebe. Und wenn Sie bereit sind, fast durch die Dunkelheit der Konsolen zu berühren, angetrieben von der Notwendigkeit, sich selbst zu verwirklichen (und die Open-Source-Welt ein wenig besser zu machen), ist dies vielleicht Ihr Weg.