Mit zunehmender Erfahrung in der IT bemerkt man, dass Systeme ihren eigenen Charakter haben. Sie können nachgiebig, still, launisch oder rau sein. Manche ziehen einen an, während andere abstoßen. So oder so muss man ‘verhandeln’ und zwischen den „Schwellen“ navigieren sowie ihre Interaktionen orchestrieren.
So haben auch wir die Ehre, eine Cloud-Plattform aufzubauen, was bedeutete, einige Teilsysteme zu überzeugen, mit uns zu kooperieren. Glücklicherweise verfügen wir über die „API-Sprache“, handwerkliches Geschick und eine Menge Enthusiasmus.
In diesem Artikel wird es kein technisches Hardcore-Wissen geben, sondern eine Beschreibung der Herausforderungen, denen wir beim Aufbau der Cloud begegnet sind. Ich habe beschlossen, unseren Weg in einer leicht verdaulichen technischen Fantasie darzustellen, die erzählt, wie wir mit den Systemen eine gemeinsame Sprache gefunden haben und was dabei herauskam.
Willkommen unter dem Artikel.
Der Beginn des Weges
Vor einiger Zeit erhielt unser Team die Aufgabe, eine Cloud-Plattform für unsere Kunden zu starten. Uns standen die Unterstützung des Managements, Ressourcen, Hardware und die Freiheit bei der Auswahl der Technologien zur Verfügung, um den Softwareteil des Services umzusetzen.
Es gab auch eine Reihe von Anforderungen:
- der Service benötigt ein benutzerfreundliches Dashboard;
- die Plattform muss in das bestehende Abrechnungssystem integriert werden;
- Software- und Hardwarekomponenten: OpenStack + Tungsten Fabric (Open Contrail), die unsere Ingenieure gut „zubereiten“ konnten.
Wie das Team zusammengestellt wurde, wie die Benutzeroberfläche des Dashboards entwickelt und Designentscheidungen getroffen wurden, werden wir ein anderes Mal erzählen, falls die Habr-Community Interesse zeigt.
Die Tools, die wir verwenden wollten:
- Python + Flask + Swagger + SQLAlchemy – ein ganz gewöhnliches Python-Setup;
- Vue.js für das Frontend;
- für die Interaktion zwischen den Komponenten und Services haben wir uns entschieden, Celery über AMQP zu verwenden.
Vorausschickend zu Fragen bezüglich der Auswahl von Python möchte ich erläutern, dass die Sprache in unserem Unternehmen ihren Platz gefunden hat und sich eine kleine, aber dennoch bestehende Kultur darum entwickelt hat. Daher wurde entschieden, den Service genau darauf aufzubauen. Umso mehr, als dass die Geschwindigkeit der Entwicklung in solchen Aufgaben oft entscheidend ist.
Lassen Sie uns also mit unserer Einführung beginnen.
Still Bill – Abrechnung
Wir kannten diesen Kerl schon lange. Er saß immer daneben und zählte stillschweigend etwas. Manchmal leitete er uns Anfragen von Nutzern weiter, stellte Kundenrechnungen aus und verwaltete die Dienste. Ein ganz normaler, fleißiger Typ. Allerdings gab es Herausforderungen. Er war still, manchmal nachdenklich und oft – in seinen eigenen Gedanken verloren.
Die Abrechnung war das erste System, mit dem wir versucht haben, Freundschaft zu schließen. Und gleich die erste Schwierigkeit begegnete uns bei der Verarbeitung von Diensten.
Zum Beispiel gelangt eine Aufgabe bei der Erstellung oder Löschung in die interne Warteschlange der Abrechnung. So wurde ein System für die asynchrone Verarbeitung von Diensten implementiert. Um unsere eigenen Diensttypen zu bearbeiten, mussten wir unsere Aufgaben in diese Warteschlange einfügen. Und hier stießen wir auf ein Problem: mangelnde Dokumentation.
Laut der Beschreibung der API kann dieses Problem tatsächlich gelöst werden, aber wir hatten nicht die Zeit für Reverse Engineering. Daher haben wir die Logik extern ausgegliedert und eine Aufgabenwarteschlange über RabbitMQ organisiert. Der Vorgang bei der Dienstleistung wird vom Kunden im Kundenkonto initiiert, in eine "Aufgabe" für Celery im Backend verpackt und auf der Seite des Hostings und OpenStack ausgeführt. Celery ermöglicht eine einfache Verwaltung der Aufgaben, eine Organisation von Wiederholungen und eine Überwachung des Status. Mehr Informationen über "Celery" finden Sie zum Beispiel hier. .
Zudem hat das Abrechnungswesen das Projekt nicht gestoppt, als die Mittel aufgebraucht waren. Im Gespräch mit den Entwicklern haben wir herausgefunden, dass es bei der Berechnung anhand der Statistiken (und genau diese Logik müssen wir umsetzen) komplexe Wechselwirkungen bei den Stoppregeln gibt. Diese Modelle lassen sich jedoch nicht gut auf unsere Realität anwenden. Auch hier haben wir über Aufgaben in Celery realisiert und die Logik zur Verwaltung der Dienste ins Backend verschoben.
Beide oben genannten Probleme haben dazu geführt, dass der Code etwas aufgebläht ist und wir in Zukunft Refactoring betreiben müssen, um die Logik für die Aufgabenbearbeitung in einen separaten Dienst auszulagern. Außerdem müssen wir einige Informationen über die Benutzer und deren Dienstleistungen in unseren Tabellen speichern, um diese Logik zu unterstützen.
Ein weiteres Problem ist die Stille.
Auf einige API-Anfragen antwortet Billy stillschweigend mit 'Ok'. So war es beispielsweise, als wir während des Tests (darüber später mehr) die versprochenen Zahlungen gutgeschrieben haben. Die Anfragen wurden korrekt ausgeführt und wir haben keine Fehler gesehen.
Ich musste die Logs untersuchen, während ich mit dem System über die Benutzeroberfläche arbeitete. Dabei stellte sich heraus, dass das Billing ähnliche Anfragen ausführt, indem es den Scope auf den jeweiligen Benutzer, beispielsweise admin, ändert und diesen im Parameter su übergibt.
Insgesamt, trotz der Lücken in der Dokumentation und kleinerer Mängel der API, lief alles recht gut. Die Logs lassen sich sogar bei hoher Last gut lesen, wenn man versteht, wie sie aufgebaut sind und wonach man suchen muss. Die Struktur der Datenbank ist raffiniert, aber durchaus logisch und in mancher Hinsicht sogar ansprechend.
Zusammenfassend lässt sich sagen, dass die Hauptprobleme, die wir in der Phase der Interaktion hatten, mit den Besonderheiten der Implementierung eines bestimmten Systems zusammenhängen:
- undokumentierte „Features“, die uns in irgendeiner Weise betroffen haben;
- geschlossene Quellcodes (das Billing ist in C++ geschrieben), was zur Folge hatte, dass wir Problem 1 nur mit dem „Versuch-und-Irrtum“-Ansatz lösen konnten.
Glücklicherweise verfügt das Produkt über eine ausreichend umfangreiche API, und wir haben die folgenden Teilsysteme in unser persönliches Dashboard integriert:
- Technischer Supportmodul – Anfragen aus dem persönlichen Dashboard werden für die Servicekunden transparent ins Billing weitergeleitet;
- Finanzmodul – ermöglicht es, Rechnungen für aktuelle Kunden auszustellen, Abbuchungen vorzunehmen und Zahlungsdokumente zu erstellen;
- Dienstverwaltungsmodul – hierfür mussten wir unseren eigenen Handler implementieren. Die Erweiterbarkeit des Systems kam uns zugute, und wir haben Billy auf einen neuen Diensttyp „trainiert“.
Es hat seine Zeit gedauert, aber ich denke, dass wir mit Billy klarkommen werden.
Spaziergänge über Wolframfelder – Tungsten Fabric
Wolframfelder, durchzogen von Hunderten von Leitungen, die Tausende von Bits an Informationen leiten. Die Informationen werden in „Pakete“ zusammengefasst, analysiert und komplexe Routen aufgebaut, fast wie durch Magie.
Das ist das Revier des zweiten Systems, mit dem wir uns anfreunden mussten — Tungsten Fabric (TF), früher bekannt als OpenContrail. Es hat die Aufgabe, die Netzwerkhardware zu verwalten und uns, den Benutzern, eine Softwareabstraktion zu bieten. TF ist SDN und verkörpert die komplexe Logik im Umgang mit der Netzwerkhardware. Es gibt einen guten Artikel zu dieser Technologie, zum Beispiel, .
Das System ist über das Neutron-Plugin mit OpenStack (darüber wird später gesprochen) integriert.
Interaktion der OpenStack-Services.
Mit diesem System wurden wir von den Jungs aus der Betriebsabteilung vertraut gemacht. Wir nutzen die API des Systems zur Verwaltung des Netzwerkstacks unserer Dienstleistungen. Ernsthafte Probleme oder Unannehmlichkeiten gab es bisher nicht (von den Jungs aus der OE will ich nicht sprechen), allerdings gab es einige Kuriositäten in der Interaktion.
Die erste sah so aus: Befehle, die eine große Menge an Daten an die Konsole des Instances beim SSH-Zugriff ausgeben sollten, „hängten“ die Verbindung, während es über VNC korrekt funktionierte.
Für diejenigen, die mit dem Problem nicht vertraut sind, sieht das ziemlich amüsant aus: ls /root funktioniert einwandfrei, während zum Beispiel top komplett einfriert. Glücklicherweise haben wir bereits ähnliche Probleme erlebt. Dieses Problem wurde durch das Tuning des MTU-Werts auf dem Weg von den Compute-Nodes zu den Routern gelöst. Übrigens, das war kein Problem von TF.
Das nächste Problem wartete gleich um die Ecke. In einem "wundervollen" Moment verschwand die Routing-Magie einfach. TF hörte auf, das Routing auf der Hardware zu verwalten.
Wir arbeiteten mit OpenStack auf Admin-Ebene und wechselten dann zur benötigten Benutzerebene. SDN scheint den Scope des Benutzers zu "übernehmen", mit dem die Aktionen ausgeführt werden. Das Problem ist, dass dasselbe Admin-Konto für die Verbindung zwischen TF und OpenStack verwendet wird. Beim Wechsel zu einem Benutzer verschwand die "Magie". Es wurde beschlossen, ein separates Konto für die Arbeit mit dem System einzurichten. Das ermöglichte die Arbeit, ohne die Integrationsfunktionalität zu stören.
Silizium-Lebensformen — OpenStack
Ein seltsames, silikonartiges Wesen lebt in der Nähe von Wolframfeldern. Es ähnelt am meisten einem Riesenbaby, das mit einem einzigen Schwung uns zerdrücken könnte, aber es zeigt keine offensichtliche Aggression. Es verursacht keine Angst, jedoch sind seine Dimensionen besorgniserregend, ebenso wie die Komplexität der Geschehnisse rund um uns.
OpenStack ist das Herzstück unserer Plattform.
OpenStack umfasst mehrere Subsysteme, von denen wir bisher am aktivsten Nova, Glance und Cinder nutzen. Jedes dieser Systeme hat eine eigene API. Nova verwaltet die Compute-Ressourcen und erstellt Instanzen, Cinder kümmert sich um die Verwaltung von Volumes und Snapshots, während Glance der Image-Service ist, der die Betriebssystemvorlagen und ihre Metadaten verwaltet.
Jeder Service wird in einem Container ausgeführt, und als Nachrichtenbroker fungiert der „weiße Hase“ — RabbitMQ.
Dieses System hat uns die meisten unerwarteten Probleme bereitet.
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 strikt, diese Aufgabe auszuführen. Genauer gesagt behauptet OpenStack, dass die Verbindung hergestellt wird, jedoch fehlt im virtuellen Server das Laufwerk.
Wir haben beschlossen, einen Umweg zu gehen und dieselbe Aktion über die Nova API anzufordern. Das Ergebnis – das Gerät verbindet sich korrekt und ist im Server verfügbar. Es scheint, dass das Problem auftritt, wenn der Block-Speicher nicht auf Cinder reagiert.
Eine weitere Herausforderung erwartete uns beim Arbeiten mit den Festplatten. Der Systemvolume konnte nicht vom Server getrennt werden.
Wieder einmal behauptet OpenStack, die Verbindung habe es getrennt und nun könne man korrekt mit dem Volume separat arbeiten. Aber die API weigerte sich kategorisch, Operationen an der Festplatte durchzuführen.
Hier haben wir beschlossen, nicht besonders zu kämpfen, sondern unsere Perspektive auf die Logik des Dienstes zu ändern. Wenn es einen Instance gibt, muss es auch einen Systemvolume geben. Daher kann der Benutzer derzeit die "Systemdisk" nicht löschen oder trennen, ohne den "Server" zu entfernen.
OpenStack ist ein ziemlich komplexes System mit seiner eigenen Interaktionslogik und einer verworrenen API. Wir profitieren von der recht detaillierten Dokumentation und natürlich von einer Methode des Versuchens und Irrens (wo kämen wir ohne hin).
Testlauf
Der Testlauf fand im Dezember letzten Jahres statt. Unser Hauptziel war es, das Projekt sowohl technisch als auch aus Sicht der Benutzererfahrung (UX) im Echtbetrieb zu überprüfen. Die Zielgruppe wurde selektiv eingeladen und der Test war geschlossen. Dennoch haben wir auch die Möglichkeit angeboten, den Zugang zu den Tests über unsere Website anzufordern.
Der Test selbst blieb selbstverständlich nicht ohne kuriose Momente, denn hier beginnen unsere Abenteuer erst richtig.
Zunächst haben wir das Interesse am Projekt etwas falsch eingeschätzt und mussten während des Tests schnell Compute-Nodes hinzufügen. Ein typischer Fall für ein Cluster, jedoch gab es auch hier Besonderheiten. In der Dokumentation für die spezifische Version von TF ist eine bestimmte Kernel-Version angegeben, die für die Zusammenarbeit mit vRouter getestet wurde. Wir haben uns entschieden, Nodes mit neueren Kernels zu starten. Das Ergebnis: TF erhielt keine Routen von den Nodes. Wir mussten die Kernels dringend zurücksetzen.
Ein weiterer kurioser Vorfall betraf die Funktionalität des Buttons „Passwort ändern“ im Kundenbereich.
Wir haben uns entschieden, JWT für den Zugriff auf das Kundenportal zu verwenden, um nicht mit Sitzungen arbeiten zu müssen. Da die Systeme unterschiedlich und weit verteilt sind, verwalten wir unser Token, in dem wir Sitzungen vom Abrechnungssystem und das Token von OpenStack "verpacken". Bei einer Änderung des Passworts verfällt das Token selbstverständlich, da die Benutzerdaten ungültig sind und neu ausgestellt werden müssen.
Wir haben diesen Punkt aus den Augen verloren, und uns fehlten die Ressourcen, um dieses Stück schnell nachzuschreiben. Wir mussten die Funktionalität kurz vor dem Start im Test herausnehmen.
Momentan führen wir ein Logout des Benutzers durch, wenn das Passwort geändert wurde.
Trotz dieser Nuancen verlief das Testen gut. In den letzten zwei Wochen haben etwa 300 Personen unseren Dienst getestet. Wir konnten das Produkt durch die Augen der Nutzer sehen, 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 wertvolle Lektionen gelernt, wie man im Team arbeitet, architektonische und gestalterische Entscheidungen trifft. Wie man komplexe Systeme mit begrenzten Ressourcen integriert und in die Produktion bringt.
Natürlich gibt es sowohl bei der Codierung als auch bei der Integration von Systemen einiges zu verbessern. Das Projekt ist noch recht jung, aber wir sind voller Ambitionen, es zu einem zuverlässigen und benutzerfreundlichen Dienst zu entwickeln.
Die Systeme konnten wir bereits überzeugen. Bill kümmert sich geduldig um die Berechnungen, Rechnungsstellungen und Nutzeranfragen in seinem kleinen Büro. Das „Magische“ der Wolfram-Felder sorgt für stabile Verbindungen. Nur OpenStack zeigt manchmal Launen und ruft etwas wie „’WSREP has not yet prepared node for application use“ heraus. Aber das ist eine ganz andere Geschichte…
Vor kurzem haben wir den Dienst gestartet.
Alle Details können Sie auf unserer .
CLO-Entwicklungsteam
Nützliche Links
OpenStack
Tungsten Fabric
Quelle: habr.com
