URUS hat Kubernetes in verschiedenen Formen ausprobiert: eine eigenständige Bare-Metal-Bereitstellung in Google Cloud und dann seine Plattform auf Mail.ru Cloud Solutions (MCS) verschoben. Igor Shishkin (
t3ran ), Senior System Administrator von URUS, erklärt, wie man einen neuen Cloud-Anbieter
auswählt und wie man es schafft, innerhalb von zwei Stunden zu diesem zu migrieren.
Was macht Urus?
Es gibt viele Möglichkeiten, die Qualität der städtischen Umwelt zu verbessern, und eine davon besteht darin, sie umweltfreundlich zu gestalten. Genau daran arbeitet das Unternehmen URUS - Smart Digital Services. Es implementiert Lösungen, mit denen Unternehmen wichtige Umweltindikatoren überwachen und negative Umweltauswirkungen reduzieren können. Sensoren erfassen Daten zur Luftzusammensetzung, zum Geräuschpegel und zu anderen Parametern und senden sie zur Analyse und Erstellung von Empfehlungen an eine einzige Plattform „Urus-Ekomon“.
Wie ist die Arbeit von "Urus" im Inneren
Ein typischer Kunde von URUS ist ein Unternehmen in oder in der Nähe eines Wohngebiets. Es kann sich um eine Fabrik, einen Hafen, ein Eisenbahndepot oder eine andere Einrichtung handeln. Wenn unser Kunde bereits eine Warnung erhalten hat, wegen Umweltverschmutzung mit einer Geldstrafe belegt wurde oder weniger Lärm machen und die Menge der schädlichen Emissionen reduzieren möchte, kommt er zu uns und wir bieten ihm bereits eine schlüsselfertige Lösung für die Umweltüberwachung an.
Ein Diagramm der Überwachung der H 2 S-Konzentration zeigt die regelmäßigen Nachtemissionen einer nahe gelegenen AnlageDie Geräte, die wir bei URUS verwenden, enthalten mehrere Sensoren, die Informationen über den Inhalt bestimmter Gase, Geräuschpegel und andere Daten zur Beurteilung der Umweltsituation erfassen. Die genaue Anzahl der Sensoren wird immer von einer bestimmten Aufgabe bestimmt.
Geräte mit Sensoren können je nach Maß an den Wänden von Gebäuden, Masten und anderen beliebigen Stellen angebracht werden. Jedes dieser Geräte sammelt Informationen, aggregiert sie und sendet sie an das Datenempfangs-Gateway. Dort speichern wir Daten für die Langzeitspeicherung und verarbeiten sie für die anschließende Analyse vor. Das einfachste Beispiel für das, was wir nach der Analyse erhalten, ist ein Luftqualitätsindex, auch bekannt als AQI.
Gleichzeitig arbeiten viele andere Dienste auf unserer Plattform, aber im Grunde sind sie Dienstcharakter. Beispielsweise sendet ein Benachrichtigungsdienst Benachrichtigungen an Kunden, wenn einer der überwachten Parameter (z. B. der Gehalt an CO
2 ) den zulässigen Wert überschritten hat.
Wie speichern wir Daten? Die Geschichte von Kubernetes auf Bare Metal
Das URUS-Öko-Monitoring-Projekt verfügt über mehrere Data Warehouses. In einem halten wir die "Rohdaten" - was wir direkt von den Geräten selbst erhalten haben. Dieser Speicher ist wie bei alten Kassetten ein „Magnetband“ mit einer Historie aller Anzeigen. Die zweite Art der Speicherung wird für vorverarbeitete Daten verwendet - Daten von Geräten, die mit Metadaten über Sensorverbindungen und Messwerte von Geräten selbst angereichert sind, Zugehörigkeit zu Organisationen, Standorten usw. Mit diesen Informationen können Sie dynamisch bewerten, wie sich ein bestimmter Indikator über einen bestimmten Zeitraum geändert hat . Wir verwenden die Speicherung von Rohdaten, auch als Backup und zur Wiederherstellung vorverarbeiteter Daten, falls dies erforderlich ist.
Als wir vor einigen Jahren nach Möglichkeiten suchten, das Speicherproblem zu lösen, hatten wir zwei Möglichkeiten, eine Plattform auszuwählen: Kubernetes und OpenStack. Aber da letzteres ziemlich monströs aussieht (sehen Sie sich nur die Architektur an, um dies zu sehen), haben wir uns für Kubernetes entschieden. Ein weiteres Argument für ihn war die relativ einfache Softwaresteuerung, die es ermöglicht, selbst Eisenknoten flexibler in Ressourcen zu schneiden.
Parallel zur Entwicklung von Kubernetes selbst haben wir auch Möglichkeiten zum Speichern von Daten untersucht. Während wir alle unsere Speicher in Kubernetes auf unserer Hardware gespeichert haben, haben wir hervorragendes Fachwissen erhalten. Alles, was wir damals auf Kubernetes gelebt hatten: Statefull Storage, Monitoring System, CI / CD. Kubernetes ist zu unserer All-in-One-Plattform geworden.
Wir wollten jedoch mit Kubernetes als Service zusammenarbeiten und uns nicht auf dessen Unterstützung und Entwicklung einlassen. Außerdem hat uns nicht gefallen, wie viel uns der Inhalt auf Bare Metal gekostet hat, und für uns war immer eine Entwicklung erforderlich! Eine der ersten Aufgaben war beispielsweise die Integration von Kubernetes Ingress-Controllern in die Netzwerkinfrastruktur unserer Organisation. Dies ist eine mühsame Aufgabe, insbesondere wenn Sie sich vorstellen, dass zu diesem Zeitpunkt nichts für die programmatische Ressourcenverwaltung wie DNS-Einträge oder IP-Zuweisung bereit war. Später haben wir angefangen, mit einem externen Data Warehouse zu experimentieren. Wir sind nicht zur Implementierung des PVC-Reglers gekommen, aber selbst dann wurde klar, dass dies ein großes Arbeitsfeld war, für das es notwendig war, einzelne Spezialisten herauszusuchen.
Migration auf die temporäre Lösung der Google Cloud Platform
Wir haben festgestellt, dass dies nicht weitergehen kann, und haben unsere Daten von Bare Metal auf die Google Cloud Platform übertragen. Tatsächlich gab es für das russische Unternehmen nicht viele interessante Optionen: Zusätzlich zur Google Cloud Platform bot nur Amazon einen ähnlichen Dienst an, aber wir entschieden uns dennoch für eine Lösung von Google. Dann schien es uns wirtschaftlich rentabler, näher an Upstream, ganz zu schweigen von der Tatsache, dass Google selbst eine Art PoC Kubernetes in der Produktion ist.
Das erste ernsthafte Problem zeichnete sich parallel zum Wachstum unserer Kundenbasis ab. Als es für uns notwendig wurde, personenbezogene Daten zu speichern, standen wir vor der Wahl: Entweder arbeiten wir mit Google zusammen und verstoßen gegen russische Gesetze, oder wir suchen nach einer Alternative in der Russischen Föderation. Die Wahl war im Allgemeinen vorhersehbar. :) :)
Wie wir den perfekten Cloud-Service gesehen haben
Zu Beginn der Suche wussten wir bereits, was wir vom zukünftigen Cloud-Anbieter erhalten wollten. Welchen Service suchten wir:
- Schnell und flexibel . Damit wir jederzeit schnell einen neuen Knoten hinzufügen oder etwas bereitstellen können.
- Preiswert . Wir waren sehr besorgt über das finanzielle Problem, da wir nur über begrenzte Ressourcen verfügten. Wir wussten bereits, dass wir mit Kubernetes arbeiten wollten, und jetzt bestand die Aufgabe darin, die Kosten zu minimieren, um die Effektivität der Verwendung dieser Lösung zu erhöhen oder zumindest aufrechtzuerhalten.
- Automatisiert . Wir wollten mit dem Service über die API arbeiten, ohne Manager und Telefonanrufe oder Situationen, in denen Sie im Notfallmodus mehrere zehn Knoten manuell anheben müssen. Da die meisten unserer Prozesse automatisiert sind, haben wir dasselbe von einem Cloud-Service erwartet.
- Mit Servern in der Russischen Föderation . Natürlich wollten wir das russische Recht und das gleiche 152-FZ einhalten.
Zu dieser Zeit gab es in Russland nur wenige Kubernetes aaS-Anbieter. Bei der Auswahl eines Anbieters war es für uns wichtig, unsere Prioritäten nicht zu gefährden. Das Team von Mail.ru Cloud Solutions, mit dem wir bereits begonnen haben und noch arbeiten, hat uns einen vollautomatisierten Service mit API-Unterstützung und einem praktischen Control Panel zur Verfügung gestellt, in dem sich Horizon befindet. Damit können wir schnell eine beliebige Anzahl von Knoten erhöhen.
Wie wir es geschafft haben, in zwei Stunden auf MCS zu migrieren
Bei solchen Umzügen sind viele Unternehmen mit Schwierigkeiten und Misserfolgen konfrontiert, in unserem Fall jedoch nicht. Wir hatten Glück: Da wir bereits vor Beginn der Migration an Kubernetes gearbeitet haben, haben wir nur drei Dateien repariert und unsere Dienste auf einer neuen Cloud-Plattform in MCS gestartet. Ich möchte Sie daran erinnern, dass wir zu diesem Zeitpunkt endlich Bare Metal verlassen hatten und auf der Google Cloud Platform lebten. Da der Umzug selbst nicht länger als zwei Stunden dauerte, plus etwas mehr Zeit (ungefähr eine Stunde), um Daten von unseren Geräten zu kopieren. Dann haben wir bereits Spinnaker verwendet (einen Multi-Cloud-CD-Service für die kontinuierliche Lieferung). Wir haben es auch schnell zum neuen Cluster hinzugefügt und wie gewohnt weitergearbeitet.
Dank der Automatisierung von Entwicklungsprozessen und CI / CD wird Kubernetes in URUS von einem Spezialisten (und das bin ich) besetzt. Irgendwann arbeitete ein anderer Systemadministrator mit mir zusammen, aber dann stellte sich heraus, dass wir bereits die gesamte Hauptroutine automatisiert hatten, und von der Seite unseres Hauptprodukts gab es immer mehr Aufgaben, und es war sinnvoll, Ressourcen darauf zu lenken.
Wir haben vom Cloud-Anbieter das erhalten, was wir erwartet hatten, da wir ohne Illusionen mit der Zusammenarbeit begonnen haben. Wenn es irgendwelche Zwischenfälle gab, dann meistens technische, die leicht durch die relative Frische des Dienstes erklärt werden können. Die Hauptsache ist, dass das MCS-Team Fehler schnell beseitigt und Fragen in Instant Messenger schnell beantwortet.
Wenn wir die Erfahrung mit der Google Cloud Platform vergleichen, wusste ich in ihrem Fall nicht einmal, wo sich die Feedback-Schaltfläche befindet, da dies einfach nicht erforderlich war. Und wenn irgendwelche Probleme auftraten, verschickte Google selbst einseitig Benachrichtigungen. Aber im Fall von MCS, einem großen Plus, glaube ich, dass sie den russischen Kunden so nahe wie möglich sind - sowohl geografisch als auch mental.
Wie wir sehen, arbeiten wir in Zukunft mit Wolken
Jetzt ist unsere Arbeit eng mit Kubernetes verbunden und passt in Bezug auf Infrastrukturaufgaben vollständig zu uns. Daher planen wir keine Migration von irgendwoher, obwohl wir ständig neue Praktiken und Dienste einführen, um Routineaufgaben zu vereinfachen und neue zu automatisieren, die Stabilität und Zuverlässigkeit von Diensten zu erhöhen ... Jetzt starten wir den Chaos Monkey-Dienst (insbesondere verwenden wir Chaoskube, aber dies ändert nichts am Konzept: ), die ursprünglich in Netflix erstellt wurde. Chaos Monkey macht eine einfache Sache: Zu einer beliebigen Zeit löscht es ein beliebiges Unter in Kubernetes. Dies ist notwendig, damit unser Dienst normal mit der Anzahl der Instanzen n - 1 leben kann. Daher sind wir es gewohnt, auf Fehlfunktionen vorbereitet zu sein.
Jetzt sehe ich die Verwendung von Lösungen von Drittanbietern - denselben Cloud-Plattformen - als die einzig richtige für junge Unternehmen. Normalerweise sind die personellen und finanziellen Ressourcen zu Beginn der Reise begrenzt, und der Aufbau und die Wartung einer eigenen Cloud oder eines eigenen Rechenzentrums sind zu teuer und zeitaufwändig. Cloud-Anbieter können diese Kosten minimieren, schnell die Ressourcen abrufen, die erforderlich sind, damit die Dienste hier und jetzt funktionieren, und diese Ressourcen tatsächlich bezahlen. Was die Firma Urus betrifft, werden wir Kubernetes in der Cloud vorerst treu bleiben. Aber wer weiß, vielleicht müssen wir geografisch expandieren oder Lösungen implementieren, die auf bestimmten Geräten basieren. Oder vielleicht rechtfertigt die Menge der verbrauchten Ressourcen seine eigenen Kubernetes auf Bare Metal, wie in den guten alten Zeiten. :) :)
Was wir aus unseren Erfahrungen mit Cloud-Diensten gelernt haben
Wir haben angefangen, Kubernetes auf Bare Metal zu verwenden, und selbst dort war es auf seine Weise gut. Seine Stärken zeigten sich jedoch gerade als aaS-Komponente in der Cloud. Wenn Sie sich ein Ziel setzen und alles so weit wie möglich automatisieren, können Sie vermeiden, dass Anbieter gesperrt werden. Der Wechsel zwischen Cloud-Anbietern dauert einige Stunden, und die Nervenzellen bleiben bei uns. Wir können andere Unternehmen beraten: Wenn Sie Ihren (Cloud-) Service mit begrenzten Ressourcen und maximaler Entwicklungsgeschwindigkeit starten möchten, mieten Sie sofort Cloud-Ressourcen und bauen Sie Ihr Rechenzentrum auf, nachdem Forbes über Sie geschrieben hat.