Wenn Sie in der IT arbeiten, bemerken Sie, dass Systeme ihren eigenen Charakter haben. Sie können flexibel, leise, exzentrisch und streng sein. Sie können anziehen oder abstoßen. Auf die eine oder andere Weise muss man mit ihnen „verhandeln“, zwischen „Fallstricken“ manövrieren und Ketten ihrer Interaktion aufbauen.
Wir hatten also die Ehre, eine Cloud-Plattform aufzubauen, und dafür mussten wir einige Subsysteme „überzeugen“, mit uns zusammenzuarbeiten. Glücklicherweise haben wir eine „API-Sprache“, direkte Hände und viel Begeisterung.
Dieser Artikel ist technisch gesehen kein Hardcore-Artikel, beschreibt aber die Probleme, auf die wir beim Aufbau der Cloud gestoßen sind. Ich beschloss, unseren Weg in Form einer leichten technischen Fantasie darüber zu beschreiben, wie wir mit Systemen nach einer gemeinsamen Sprache suchten und was dabei herauskam.
Willkommen bei Katze.
Beginn einer Reise
Vor einiger Zeit wurde unser Team mit der Einführung einer Cloud-Plattform für unsere Kunden beauftragt. Wir hatten Managementunterstützung, Ressourcen, Hardware-Stack und Freiheit bei der Auswahl der Technologien zur Implementierung des Software-Teils des Dienstes.
Es gab auch eine Reihe von Anforderungen:
- der Dienst benötigt ein praktisches persönliches Konto;
- die Plattform muss in das bestehende Abrechnungssystem integriert werden;
- Software und Hardware: OpenStack + Tungsten Fabric (Open Contrail), das unsere Ingenieure recht gut „kochen“ gelernt haben.
Wenn die Habra-Community Interesse hat, erzählen wir Ihnen ein anderes Mal, wie das Team zusammengestellt, die Benutzeroberfläche für persönliche Konten entwickelt und Designentscheidungen getroffen wurden.
Die Tools, für die wir uns entschieden haben:
- Python + Flask + Swagger + SQLAlchemy – ein komplett standardmäßiges Python-Set;
- Vue.js für Frontend;
- Wir haben uns entschieden, die Interaktion zwischen Komponenten und Diensten mithilfe von Celery über AMQP durchzuführen.
Da ich Fragen zur Auswahl von Python vorwegnehme, werde ich sie erklären. Die Sprache hat in unserem Unternehmen ihre Nische gefunden und um sie herum hat sich eine kleine, aber dennoch ruhige Kultur entwickelt. Daher wurde beschlossen, mit dem Aufbau des Dienstes darauf zu beginnen. Darüber hinaus ist bei solchen Problemen oft die Geschwindigkeit der Entwicklung entscheidend.
Beginnen wir also mit unserer Bekanntschaft.
Silent Bill - Abrechnung
Wir kennen diesen Kerl schon lange. Er saß immer neben mir und zählte schweigend etwas. Manchmal leitete er Benutzeranfragen an uns weiter, stellte Kundenrechnungen aus und verwaltete Dienstleistungen. Ein gewöhnlicher, fleißiger Kerl. Es stimmt, es gab Schwierigkeiten. Er ist schweigsam, manchmal nachdenklich und oft in seinen eigenen Gedanken.
Die Abrechnung ist das erste System, mit dem wir versucht haben, uns anzufreunden. Und die erste Schwierigkeit, auf die wir gestoßen sind, war die Abwicklung von Dienstleistungen.
Wenn eine Aufgabe beispielsweise erstellt oder gelöscht wird, gelangt sie in die interne Abrechnungswarteschlange. Somit wird ein System der asynchronen Arbeit mit Diensten implementiert. Um unsere Servicetypen zu verarbeiten, mussten wir unsere Aufgaben in diese Warteschlange „einreihen“. Und hier stießen wir auf ein Problem: fehlende Dokumentation.
Der Beschreibung der Software-API nach zu urteilen, ist es immer noch möglich, dieses Problem zu lösen, aber wir hatten keine Zeit für Reverse Engineering, also haben wir die Logik nach draußen gebracht und eine Aufgabenwarteschlange über RabbitMQ organisiert. Ein Vorgang für einen Dienst wird vom Kunden über sein persönliches Konto initiiert, im Backend in eine Celery-„Aufgabe“ umgewandelt und auf der Abrechnungs- und OpenStack-Seite ausgeführt. Mit Celery lassen sich ganz bequem Aufgaben verwalten, Wiederholungen organisieren und den Status überwachen. Mehr zum Thema „Sellerie“ können Sie zum Beispiel lesen: .
Auch die Abrechnung hat ein Projekt, dem das Geld ausgegangen ist, nicht gestoppt. Bei der Kommunikation mit den Entwicklern haben wir herausgefunden, dass es bei der Berechnung von Statistiken (und wir müssen genau diese Art von Logik implementieren) einen komplexen Zusammenhang zwischen Stoppregeln gibt. Aber diese Modelle passen nicht gut zu unserer Realität. Wir haben es auch durch Aufgaben auf Celery implementiert und die Service-Management-Logik auf die Backend-Seite übertragen.
Beide oben genannten Probleme führten dazu, dass der Code etwas aufgebläht wurde und wir in Zukunft eine Umgestaltung vornehmen müssen, um die Logik für die Arbeit mit Aufgaben in einen separaten Dienst zu verschieben. Wir müssen auch einige Informationen über Benutzer und ihre Dienste in unseren Tabellen speichern, um diese Logik zu unterstützen.
Ein weiteres Problem ist die Stille.
Billy antwortet stillschweigend auf einige API-Anfragen mit „Ok“. Dies war zum Beispiel der Fall, als wir im Rahmen des Tests versprochene Zahlungen leisteten (dazu später mehr). Die Anfragen wurden korrekt ausgeführt und es konnten keine Fehler festgestellt werden.
Ich musste die Protokolle studieren, während ich über die Benutzeroberfläche mit dem System arbeitete. Es stellte sich heraus, dass die Abrechnung selbst ähnliche Anfragen ausführt, indem sie den Bereich auf einen bestimmten Benutzer, zum Beispiel admin, ändert und ihn im su-Parameter übergibt.
Im Allgemeinen lief trotz der Lücken in der Dokumentation und kleineren API-Fehlern alles ganz gut. Protokolle können auch unter hoher Last gelesen werden, wenn Sie wissen, wie sie aufgebaut sind und worauf Sie achten müssen. Die Struktur der Datenbank ist kunstvoll, aber durchaus logisch und in mancher Hinsicht sogar attraktiv.
Zusammenfassend lässt sich sagen, dass die Hauptprobleme, auf die wir in der Interaktionsphase gestoßen sind, mit den Implementierungsmerkmalen eines bestimmten Systems zusammenhängen:
- undokumentierte „Merkmale“, die uns auf die eine oder andere Weise beeinflusst haben;
- Closed Source (die Abrechnung ist in C++ geschrieben), daher ist es unmöglich, Problem 1 auf andere Weise als durch „Versuch und Irrtum“ zu lösen.
Glücklicherweise verfügt das Produkt über eine ziemlich umfangreiche API und wir haben die folgenden Subsysteme in unser persönliches Konto integriert:
- Technisches Support-Modul – Anfragen von Ihrem persönlichen Konto werden transparent an die Abrechnung für Servicekunden weitergeleitet;
- Finanzmodul – ermöglicht es Ihnen, Rechnungen an bestehende Kunden auszustellen, Abschreibungen vorzunehmen und Zahlungsdokumente zu erstellen;
- Service-Control-Modul – dafür mussten wir unseren eigenen Handler implementieren. Die Erweiterbarkeit des Systems spielte uns in die Karten und wir „brachten“ Billy eine neue Art von Service bei.
Es war ein bisschen mühsam, aber auf die eine oder andere Weise denke ich, dass Billy und ich miteinander klarkommen werden.
Ein Spaziergang durch Wolframfelder – Tungsten Fabric
Wolframfelder, übersät mit Hunderten von Drähten, durch die Tausende von Informationsbits geleitet werden. Informationen werden wie von Zauberhand in „Paketen“ gesammelt, analysiert und komplexe Routen aufgebaut.
Dies ist die Domäne des zweiten Systems, mit dem wir uns anfreunden mussten – Tungsten Fabric (TF), ehemals OpenContrail. Seine Aufgabe besteht darin, Netzwerkgeräte zu verwalten und uns als Benutzern eine Software-Abstraktion bereitzustellen. TF – SDN kapselt die komplexe Logik der Arbeit mit Netzwerkgeräten. Es gibt zum Beispiel einen guten Artikel über die Technologie selbst: .
Das System ist über das Neutron-Plugin in OpenStack integriert (siehe unten).
Interaktion von OpenStack-Diensten.
Die Jungs aus der Betriebsabteilung haben uns dieses System vorgestellt. Wir nutzen die API des Systems, um den Netzwerk-Stack unserer Dienste zu verwalten. Es hat uns noch keine ernsthaften Probleme oder Unannehmlichkeiten bereitet (ich kann nicht für die Jungs vom OE sprechen), aber es gab einige Kuriositäten in der Interaktion.
Das erste sah so aus: Befehle, die bei der Verbindung über SSH die Ausgabe einer großen Datenmenge an die Instanzkonsole erforderten, legten die Verbindung einfach „auf“, während über VNC alles korrekt funktionierte.
Für diejenigen, die das Problem nicht kennen, sieht es ziemlich komisch aus: ls /root funktioniert korrekt, während beispielsweise top komplett „einfriert“. Glücklicherweise sind wir schon einmal auf ähnliche Probleme gestoßen. Dies wurde durch die Optimierung der MTU auf der Route von den Rechenknoten zu den Routern entschieden. Das ist übrigens kein TF-Problem.
Das nächste Problem stand vor der Tür. In einem „schönen“ Moment verschwand die Magie des Routings einfach so. TF hat die Verwaltung des Routings auf dem Gerät eingestellt.
Wir haben mit Openstack auf der Administratorebene gearbeitet und sind danach auf die erforderliche Benutzerebene umgestiegen. SDN scheint den Umfang des Benutzers zu „kapern“, der die Aktionen ausführt. Tatsache ist, dass dasselbe Administratorkonto verwendet wird, um TF und OpenStack zu verbinden. Beim Übergang zum Benutzer verschwand die „Magie“. Es wurde beschlossen, ein separates Konto für die Arbeit mit dem System zu erstellen. Dadurch konnten wir arbeiten, ohne die Integrationsfunktionalität zu beeinträchtigen.
Silizium-Lebensformen – OpenStack
Eine bizarr geformte Silikonkreatur lebt in der Nähe von Wolframfeldern. Vor allem sieht es aus wie ein übergroßes Kind, das uns mit einem Schlag zerquetschen kann, aber von ihm geht keine offensichtliche Aggression aus. Es verursacht keine Angst, aber seine Größe löst Angst aus. Ebenso wie die Komplexität dessen, was um uns herum geschieht.
OpenStack ist der Kern unserer Plattform.
OpenStack verfügt über mehrere Subsysteme, von denen wir derzeit Nova, Glance und Cinder am aktivsten nutzen. Jeder von ihnen hat seine eigene API. Nova ist für Rechenressourcen und die Erstellung von Instanzen verantwortlich, Cinder ist für die Verwaltung von Volumes und deren Snapshots verantwortlich, Glance ist ein Image-Dienst, der Betriebssystemvorlagen und Metainformationen darauf verwaltet.
Jeder Dienst läuft in einem Container und der Nachrichtenbroker ist das „weiße Kaninchen“ – RabbitMQ.
Dieses System bereitete uns die unerwartetsten Probleme.
Und das erste Problem ließ nicht lange auf sich warten, als wir versuchten, ein zusätzliches Volume an den Server anzuschließen. Die Cinder-API weigerte sich rundweg, diese Aufgabe auszuführen. Genauer gesagt, wenn Sie OpenStack selbst glauben, wird die Verbindung hergestellt, aber es gibt kein Festplattengerät im virtuellen Server.
Wir entschieden uns für einen Umweg und forderten die gleiche Aktion von der Nova API an. Das Ergebnis ist, dass das Gerät eine korrekte Verbindung herstellt und innerhalb des Servers erreichbar ist. Es scheint, dass das Problem auftritt, wenn Block-Storage nicht auf Cinder reagiert.
Eine weitere Schwierigkeit erwartete uns bei der Arbeit mit Datenträgern. Das Systemvolume konnte nicht vom Server getrennt werden.
Auch hier „schwört“ OpenStack selbst, dass es die Verbindung zerstört hat und Sie jetzt korrekt mit dem Volume separat arbeiten können. Die API wollte jedoch grundsätzlich keine Vorgänge auf der Festplatte ausführen.
Hier haben wir beschlossen, nicht besonders zu kämpfen, sondern unsere Sicht auf die Logik des Dienstes zu ändern. Wenn eine Instanz vorhanden ist, muss auch ein Systemvolume vorhanden sein. Daher kann der Benutzer die Systemfestplatte noch nicht entfernen oder deaktivieren, ohne den „Server“ zu löschen.
OpenStack ist ein ziemlich komplexer Satz von Systemen mit eigener Interaktionslogik und ausgefeilter API. Dabei helfen uns eine ziemlich detaillierte Dokumentation und natürlich Versuch und Irrtum (was wären wir ohne das).
Testlauf
Wir haben im Dezember letzten Jahres einen Teststart durchgeführt. Die Hauptaufgabe bestand darin, unser Projekt im Kampfmodus von der technischen Seite und von der UX-Seite aus zu testen. Das Publikum wurde selektiv eingeladen und die Prüfung wurde geschlossen. Wir haben jedoch auch die Möglichkeit gelassen, auf unserer Website Zugriff auf Tests anzufordern.
Der Test selbst war natürlich nicht ohne lustige Momente, denn hier fangen unsere Abenteuer gerade erst an.
Erstens haben wir das Interesse an dem Projekt etwas falsch eingeschätzt und mussten direkt während des Tests schnell Rechenknoten hinzufügen. Ein häufiger Fall für einen Cluster, aber auch hier gab es einige Nuancen. Die Dokumentation für eine bestimmte Version von TF gibt die spezifische Version des Kernels an, auf der die Arbeit mit vRouter getestet wurde. Wir haben uns entschieden, Knoten mit neueren Kerneln zu starten. Infolgedessen erhielt TF keine Routen von den Knoten. Ich musste dringend die Kernel zurücksetzen.
Eine weitere Kuriosität betrifft die Funktionalität der Schaltfläche „Passwort ändern“ in Ihrem persönlichen Konto.
Wir haben uns entschieden, JWT zu verwenden, um den Zugriff auf unser persönliches Konto zu organisieren, um nicht mit Sitzungen arbeiten zu müssen. Da die Systeme vielfältig und weit verstreut sind, verwalten wir einen eigenen Token, in den wir Sitzungen aus der Abrechnung „verpacken“ und einen Token von OpenStack. Bei einer Passwortänderung geht der Token natürlich „ungültig“, da die Benutzerdaten nicht mehr gültig sind und neu ausgestellt werden müssen.
Wir haben diesen Punkt aus den Augen verloren und es waren einfach nicht genügend Ressourcen vorhanden, um dieses Stück schnell fertigzustellen. Wir mussten die Funktionalität kurz vor dem Start des Tests herausschneiden.
Derzeit melden wir den Benutzer ab, wenn das Passwort geändert wurde.
Trotz dieser Nuancen verliefen die Tests gut. Innerhalb weniger Wochen kamen etwa 300 Menschen vorbei. Wir konnten das Produkt durch die Augen der Benutzer betrachten, es in Aktion testen und hochwertiges Feedback sammeln.
To be continued
Für viele von uns ist dies das erste Projekt dieser Größenordnung. Wir haben eine Reihe wertvoller Lektionen darüber gelernt, wie man als Team zusammenarbeitet und Architektur- und Designentscheidungen trifft. Wie man komplexe Systeme mit wenig Ressourcen integriert und in die Produktion überführt.
Natürlich gibt es sowohl im Code als auch an den Schnittstellen der Systemintegration einiges zu bearbeiten. Das Projekt ist noch recht jung, aber wir sind voller Ambitionen, es zu einem zuverlässigen und praktischen Dienst auszubauen.
Wir konnten die Systeme bereits überzeugen. Bill kümmert sich in seinem Schrank pflichtbewusst um Zählungen, Abrechnungen und Benutzeranfragen. Die „Magie“ der Wolframfelder sorgt für eine stabile Kommunikation. Und nur OpenStack wird manchmal launisch und ruft etwas wie „WSREP hat den Knoten noch nicht für die Anwendungsnutzung vorbereitet.“ Aber das ist eine ganz andere Geschichte...
Wir haben den Dienst kürzlich gestartet.
Alle Details erfahren Sie auf unserer .
CLO-Entwicklungsteam
Nützliche Links
OpenStack
Wolframgewebe
Source: habr.com