🥇Die Entstehungsgeschichte des Cloud-Services, gewürzt mit Cyberpunk

Mit zunehmender Berufserfahrung in der IT beginnt man zu bemerken, dass Systeme ihren eigenen Charakter haben. Sie können freundlich, still, launisch oder streng sein. Sie können anziehend oder abstoßend wirken. So oder so muss man "Verhandlungen" mit ihnen führen, zwischen "unterseeischen Felsen" navigieren und ihre Interaktionsketten aufbauen.

So wurde uns die Ehre zuteil, eine Cloud-Plattform zu erstellen, und dafür mussten wir ein paar Teilsysteme "überzeugen", mit uns zu arbeiten. Glücklicherweise haben wir die "API-Sprache", geschickte Hände und eine Menge Enthusiasmus.

In diesem Artikel wird es keinen technischen Hardcore geben, aber es wird eine Beschreibung der Probleme geben, mit denen wir beim Aufbau der Cloud konfrontiert waren. Ich habe mich entschieden, unseren Weg in Form einer leichten technischen Fantasie zu beschreiben, wie wir eine gemeinsame Sprache mit den Systemen gefunden haben und was daraus geworden ist.

Willkommen unter dem Cut.

Der Beginn des Weges

Vor einiger Zeit wurde unser Team mit der Aufgabe betraut, eine Cloud-Plattform für unsere Kunden zu starten. Uns standen die Unterstützung des Managements, Ressourcen, Hardware-Stack und die Freiheit bei der Auswahl der Technologien zur Verfügung, um den Softwareteil des Dienstes zu realisieren.

Es gab auch eine Reihe von Anforderungen:

der Dienst benötigt ein benutzerfreundliches persönliches Konto;
die Plattform muss in das bestehende Abrechnungssystem integriert werden;
die Software-Hardware-Komponente: OpenStack + Tungsten Fabric (Open Contrail), die unsere Ingenieure recht gut "zubereiten" konnten.

Wie das Team zusammengestellt wurde, wie die Benutzeroberfläche des persönlichen Kontos entwickelt und wie Designentscheidungen getroffen wurden, werden wir ein anderes Mal erzählen, wenn das Interesse der Habr-Community besteht.
Die Tools, die wir verwenden wollten, sind:

Python + Flask + Swagger + SQLAlchemy – eine ganz normale Python-Ausstattung;
Vue.js für das Frontend;
die Interaktion zwischen Komponenten und Diensten wollten wir mit Celery über AMQP realisieren.

Um Fragen nach der Wahl von Python vorauszusehen, erkläre ich: Die Sprache hat ihren Platz in unserem Unternehmen gefunden und es hat sich eine kleine, aber dennoch greifbare Kultur darum gebildet. Daher wurde beschlossen, den Dienst genau darauf aufzubauen. Zumal die Geschwindigkeit der Entwicklung in solchen Aufgaben oft entscheidend ist.

Also, lassen Sie uns mit unserem Kennenlernen beginnen.

Stillen Bill – Abrechnung

Wir kannten diesen Typen schon lange. Er saß immer neben uns und zählte still vor sich hin. Manchmal leitete er uns Benutzeranfragen weiter, stellte Kundenrechnungen aus und verwaltete Dienstleistungen. Ein ganz normaler arbeitender Mann. Es gab allerdings einige Schwierigkeiten. Er war schweigsam, manchmal nachdenklich und oft — in seinen eigenen Gedanken.

Billing war das erste System, mit dem wir versuchten, uns anzufreunden. Und die erste Schwierigkeit traf uns bereits bei der Bearbeitung von Dienstleistungen.

Zum Beispiel, wenn man einen Service erstellt oder entfernt, gelangt die Aufgabe in die interne Warteschlange des Billings. So wurde ein System für asynchrone Arbeit mit Dienstleistungen realisiert. Um unsere eigenen Servicetypen zu verarbeiten, mussten wir unsere Aufgaben in diese Warteschlange „einreihen“. Hier trafen wir jedoch auf das Problem: Es mangelte an Dokumentation.

Nach der Beschreibung der Programmierschnittstelle (API) ist es zwar möglich, diese Aufgabe zu lösen, aber wir hatten keine Zeit für Reverse Engineering, also haben wir die Logik nach außen verlagert und eine Aufgabenwarteschlange über RabbitMQ organisiert. Die Operation über einen Service wird vom Kunden aus dem Kundenbereich initiiert, in eine „Aufgabe“ für Celery im Backend eingewickelt und auf der Seite des Billings und von OpenStack ausgeführt. Celery ermöglicht ein ziemlich bequemes Management von Aufgaben, organisiert Wiederholungen und verfolgt den Status. Mehr über „Celery“ kann man beispielsweise hier nachlesen. hier.

Auch das Billing stoppte nicht das Projekt, als das Geld ausging. Im Gespräch mit den Entwicklern stellten wir fest, dass es beim Zählen von Statistiken (und wir müssen genau eine solche Logik umsetzen) eine komplexe Verflechtung von Stoppregeln gibt. Diese Modelle passen jedoch schlecht in unsere Realität. Wir haben auch über Celery Aufgaben umgesetzt, indem wir die Logik der Serviceverwaltung ins Backend holten.

Die beiden oben genannten Probleme führten dazu, dass der Code ein wenig aufgebläht wurde, und wir in Zukunft Refactoring betreiben müssen, um die Logik der Aufgabenverwaltung in einen separaten Service auszulagern. Wir müssen auch Teile der Informationen über Benutzer und deren Dienstleistungen in unseren Tabellen speichern, um diese Logik zu unterstützen.

Ein weiteres Problem ist die Schweigsamkeit.

Auf einige API-Anfragen antwortet Billy stumm mit „Ok“. So war es beispielsweise, als wir während des Tests (darüber später mehr) versprochenen Zahlungen gutgeschrieben haben. Die Anfragen wurden korrekt ausgeführt und wir sahen keine Fehler.

Es war notwendig, die Protokolle zu studieren, während ich mit dem System über die Benutzeroberfläche arbeitete. Es stellte sich heraus, dass die Abrechnung ähnliche Anfragen ausführt, indem der Scope auf einen bestimmten Benutzer, zum Beispiel 'admin', geändert wird, und dieser als Parameter 'su' übergeben wird.

Insgesamt verlief trotz der Lücken in der Dokumentation und kleinerer Fehler in der API alles recht gut. Die Protokolle sind auch bei hoher Auslastung gut lesbar, wenn man versteht, wie sie strukturiert sind und wonach man suchen muss. Die Struktur der Datenbank ist verworren, aber durchaus logisch und in mancher Hinsicht sogar ansprechend.

Zusammenfassend sind die Hauptprobleme, die wir in der Interaktion hatten, auf die Besonderheiten der Umsetzung des konkreten Systems zurückzuführen:

undokumentierte „Funktionen“, die uns mehr oder weniger betrifft haben;
geschlossene Quellcodes (die Abrechnung ist in C++ geschrieben), was zur Folge hat, dass Problem 1 nur durch den „Trial-and-Error“-Ansatz gelöst werden kann.

Glücklicherweise verfügt das Produkt über eine ziemlich umfassende API und wir haben folgende Teilsysteme in unser Kundenkonto integriert:

Modul für technischen Support – Anfragen aus dem Kundenkonto werden transparent für die Dienstleistungsbenutzer in die Abrechnung „proxiesiert“;
Finanzmodul – ermöglicht das Ausstellen von Rechnungen an aktuelle Kunden, das Durchführen von Abbuchungen und die Erstellung von Zahlungsdokumenten;
Modul zur Verwaltung von Dienstleistungen – dafür mussten wir unseren eigenen Handler implementieren. Die Erweiterbarkeit des Systems kam uns zugute und wir haben Billy einen neuen Diensttypen beigebracht.
Es war zwar etwas mühsam, aber ich denke, dass wir mit Billy gut zurechtkommen werden.

Spaziergänge über die Wolframfelder – Tungsten Fabric

Wolframfelder, die mit hundert Drähten übersät sind, die tausende Bits Informationen durchlaufen. Informationen werden in „Pakete“ gebündelt, analysiert und komplexe Routen erstellt, fast wie durch Magie.

Das ist das Reich des zweiten Systems, mit dem wir uns anfreunden mussten – Tungsten Fabric (TF), ehemals OpenContrail. Ihre Aufgabe ist es, Netzwerkhardware zu verwalten und uns als Nutzern eine programmathematische Abstraktion zu bieten. TF – SDN, kapselt komplexe Logik im Umgang mit Netzwerkgeräten ein. Über die Technologie selbst gibt es einen guten Artikel, zum Beispiel, hier.

Das System ist über das Neutron-Plugin mit OpenStack integriert (darüber sprechen wir gleich).

Interaktion der OpenStack-Dienste.

Dieses System wurde uns von den Kollegen aus der Betriebsabteilung vorgestellt. Wir nutzen die API des Systems, um den Netzwerkstack unserer Dienste zu verwalten. Bisher verursacht es keine ernsthaften Probleme oder Unannehmlichkeiten (was die Kollegen aus der OE betrifft, möchte ich nichts sagen), jedoch gab es einige kuriose Interaktionen.

Das erste sah so aus: Befehle, die eine große Menge an Daten auf die Konsole der Instanz beim SSH-Zugriff ausgeben, „hängten“ die Verbindung einfach auf, während alles über VNC korrekt funktionierte.

Für diejenigen, die mit dem Problem nicht vertraut sind, sieht es ziemlich lustig aus: ls /root funktioniert korrekt, während zum Beispiel top komplett „einfriert“. Glücklicherweise hatten wir bereits mit ähnlichen Problemen zu tun. Es wurde durch das Tuning des MTU auf dem Weg von den Compute-Nodes zu den Routern gelöst. Nebenbei bemerkt, das ist auch kein Problem für TF.

Das nächste Problem wartete um die Ecke. In einem „wunderschönen“ Moment verschwand die Magie der Routing, einfach so. TF hörte auf, das Routing auf der Hardware zu steuern.

Wir arbeiteten mit OpenStack aus der Admin-Ansicht und wechselten dann auf die Ebene des benötigten Benutzers. SDN scheint den Geltungsbereich des Benutzers zu „übernehmen“, mit dem die Aktionen ausgeführt werden. Das Problem ist, dass dasselbe Admin-Konto zur Kommunikation zwischen TF und OpenStack verwendet wird. Beim Wechsel zu einem normalen Benutzer verschwand die „Magie“. Es wurde beschlossen, ein separates Konto für die Arbeit mit dem System einzurichten. Dies erlaubte es uns, zu arbeiten, ohne die Integrationsfunktionalität zu beeinträchtigen.

Siliconformen des Lebens – OpenStack

Das silikonartige Wesen in seltsamer Form lebt in der Nähe von Wolframfeldern. Es sieht am meisten wie ein übergroßes Kind aus, das uns mit einem einzigen Schwung zerquetschen kann, aber von ihm geht keine offensichtliche Aggression aus. Es verursacht keine Angst, aber seine Größe gibt Anlass zur Sorge. Genauso wie die Komplexität dessen, was um uns herum geschieht.

OpenStack ist das Herzstück unserer Plattform.

OpenStack hat mehrere Teilsysteme, von denen wir bisher am aktivsten Nova, Glance und Cinder nutzen. Jede von ihnen hat ihre eigene API. Nova ist verantwortlich für Compute-Ressourcen und die Erstellung von Instanzen, Cinder für das Management von Volumes und deren Snapshots, Glance ist der Image-Service, der Betriebssystemvorlagen und deren Metadaten verwaltet.

Jeder Dienst wird in einem Container gestartet, und der Nachrichtenbroker ist der „weiße Kaninchen“ – RabbitMQ.

Dieses System hat uns am meisten unerwartete Schwierigkeiten bereitet.

Und das erste Problem ließ nicht lange auf sich warten, als wir versuchten, einen zusätzlichen Volume an den Server anzuschließen. Die Cinder-API weigerte sich strikt, diese Aufgabe zu erfüllen. Genauer gesagt, wenn man OpenStack Glauben schenken darf, wird die Verbindung hergestellt, jedoch fehlt das Laufwerk innerhalb des virtuellen Servers.

Wir beschlossen, einen «Umweg» zu nehmen und dieselbe Aktion über die Nova-API anzufordern. Das Ergebnis – das Gerät wird korrekt angeschlossen und ist innerhalb des Servers verfügbar. Anscheinend tritt das Problem auf, wenn der Block-Speicher Cinder nicht antwortet.

Eine weitere Schwierigkeit erwartete uns bei der Arbeit mit Laufwerken. Es war nicht möglich, das System-Volume vom Server zu trennen.

Auch hier «schwört» OpenStack, dass die Verbindung getrennt wurde und man jetzt korrekt mit dem Volume arbeiten kann. Aber die API wollte unbedingt keine Operationen am Laufwerk durchführen.

Hier entschieden wir uns, nicht weiter zu kämpfen, sondern die Logik des Dienstes zu überdenken. Wenn es eine Instanz gibt, sollte es auch ein System-Volume geben. Daher kann der Benutzer das «Festplatten»-System vorerst nicht löschen oder trennen, ohne den «Server» zu entfernen.

OpenStack ist ein recht komplexes System mit seiner eigenen Interaktionslogik und einem verschlungenen API. Unsere Rettung ist die ziemlich ausführliche Dokumentation und natürlich die Methode von Versuch und Irrtum (wie sollte es auch anders sein).

Testlauf

Den Testlauf führten wir im Dezember letzten Jahres durch. Die Hauptaufgabe bestand darin, unser Projekt sowohl aus technischer Sicht als auch aus der UX-Perspektive im Betrieb zu überprüfen. Die Zielgruppe wurde selektiv eingeladen und das Testen war geschlossen. Wir haben jedoch auch die Möglichkeit gelassen, den Zugang zum Testen über unsere Website anzufordern.

Selbst der Test blieb selbstverständlich nicht ohne kurvenreiche Momente, denn hier beginnen erst unsere Abenteuer.

Erstens haben wir das Interesse am Projekt etwas falsch eingeschätzt und mussten während des Tests schnell Compute-Knoten hinzufügen. Ein üblicher Fall für ein Cluster, aber auch hier gab es Nuancen. In der Dokumentation für die spezifische Version von TF war eine bestimmte Kernelversion angegeben, auf der die Arbeit mit vRouter getestet wurde. Wir haben beschlossen, die Knoten mit neueren Kernen zu starten. Das Ergebnis – TF erhielt keine Routen von den Knoten. Wir mussten die Kerne dringend zurücksetzen.

Eine weitere Kuriosität war die Funktion der Schaltfläche «Passwort ändern» im persönlichen Bereich.

Wir haben beschlossen, JWT für den Zugang zum persönlichen Bereich zu verwenden, um nicht mit Sessions arbeiten zu müssen. Da die Systeme vielfältig und weit verstreut sind, verwalten wir unser Token, in dem wir die Sessions vom Billing und das Token von OpenStack „verpacken“. Wenn das Passwort geändert wird, verfällt das Token natürlich, da die Benutzerdaten ungültig sind und neu ausgegeben werden müssen.

Wir haben diesen Punkt aus den Augen verloren, und es fehlten banal die Ressourcen, um dieses Stück schnell zu ergänzen. Wir mussten die Funktionalität kurz vor dem Teststart herausnehmen.
Momentan führen wir den Logout des Benutzers durch, wenn das Passwort geändert wurde.

Trotz dieser Nuancen verlief das Testing gut. In den letzten zwei Wochen haben uns etwa 300 Personen besucht. Wir konnten das Produkt aus der Sicht der Benutzer betrachten, es im Einsatz testen und qualitatives Feedback sammeln.

Fortsetzung folgt

Für viele von uns ist dies das erste Projekt dieser Größenordnung. Wir haben eine Reihe wertvoller Lektionen darüber gelernt, wie man im Team arbeitet und architektonische sowie gestalterische Entscheidungen trifft. Wie man mit begrenzten Ressourcen komplexe Systeme integriert und sie in die Produktion bringt.

Natürlich gibt es noch einiges zu tun, sowohl im Hinblick auf den Code als auch an den Schnittstellen zur Integration der Systeme. Das Projekt ist noch recht jung, aber wir sind voller Ambitionen, einen zuverlässigen und benutzerfreundlichen Service daraus zu entwickeln.

Die Systeme konnten wir bereits überzeugen. Bill kümmert sich brav um die Berechnungen, die Rechnungsstellung und die Benutzeranfragen in seiner kleinen Kammer. Das „Magie“ der Wolframfelder sorgt für stabile Verbindungen. Und nur OpenStack macht manchmal Zicken und ruft etwas wie „’WSREP has not yet prepared node for application use“ dazwischen. Aber das ist eine ganz andere Geschichte...

Vor kurzem haben wir den Service gestartet.
Alle Details können Sie auf unserem Website.

CLO Entwicklungsteam