Das Unternehmen URUS testete Kubernetes in verschiedenen Formen: unabhängige Bereitstellung auf Bare Metal in der Google Cloud und übertrug dann seine Plattform in die Mail.ru Cloud Solutions (MCS)-Cloud. Igor Shishkin erzählt, wie sie sich für einen neuen Cloud-Anbieter entschieden haben und wie es ihnen gelungen ist, in der Rekordzeit von zwei Stunden dorthin zu migrieren (), leitender Systemadministrator bei URUS.
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. Hier implementieren sie Lösungen, die Unternehmen dabei helfen, wichtige Umweltindikatoren zu überwachen und deren negative Auswirkungen auf die Umwelt zu reduzieren. Sensoren sammeln Daten zur Luftzusammensetzung, zum Lärmpegel und zu anderen Parametern und senden sie dann zur Analyse und Abgabe von Empfehlungen an die einheitliche URUS-Ekomon-Plattform.
Wie URUS von innen funktioniert
Ein typischer Kunde von URUS ist ein Unternehmen mit Sitz in oder in der Nähe eines Wohngebiets. Dies kann eine Fabrik, ein Hafen, ein Eisenbahndepot oder eine andere Einrichtung sein. Wenn unser Kunde bereits eine Abmahnung erhalten hat, ein Bußgeld wegen Umweltverschmutzung erhalten hat oder weniger Lärm machen oder die Menge schädlicher Emissionen reduzieren möchte, kommt er zu uns und wir bieten ihm bereits eine fertige Lösung für die Umweltüberwachung an.
Das Diagramm zur Überwachung der H2S-Konzentration zeigt die regelmäßigen nächtlichen Emissionen einer nahegelegenen Anlage
Die Geräte, die wir bei URUS verwenden, enthalten mehrere Sensoren, die Informationen über den Gehalt bestimmter Gase, Lärmpegel und andere Daten sammeln, um die Umweltsituation zu beurteilen. Die genaue Anzahl der Sensoren richtet sich immer nach der konkreten Aufgabenstellung.
Abhängig von den Besonderheiten der Messungen können Geräte mit Sensoren an Gebäudewänden, Masten und anderen beliebigen Orten angebracht werden. Jedes dieser Geräte sammelt Informationen, aggregiert sie und sendet sie an das Datenempfangs-Gateway. Dort speichern wir die Daten zur Langzeitspeicherung und bereiten sie für die spätere Analyse vor. Das einfachste Beispiel dafür, was wir als Ergebnis einer Analyse erhalten, ist der Luftqualitätsindex, auch bekannt als AQI.
Parallel dazu laufen auf unserer Plattform viele weitere Dienste, die jedoch überwiegend Servicecharakter haben. Der Benachrichtigungsdienst sendet beispielsweise Benachrichtigungen an Clients, wenn einer der überwachten Parameter (z. B. CO2-Gehalt) den zulässigen Wert überschreitet.
Wie wir Daten speichern. Die Geschichte von Kubernetes auf Bare Metal
Das Umweltüberwachungsprojekt URUS verfügt über mehrere Data Warehouses. In einem speichern wir „Rohdaten“ – das, was wir direkt von den Geräten selbst erhalten haben. Bei diesem Speicher handelt es sich um ein „magnetisches“ Band, wie bei alten Kassetten, mit einer Historie aller Indikatoren. Die zweite Art der Speicherung wird für vorverarbeitete Daten verwendet – Daten von Geräten, angereichert mit Metadaten über Verbindungen zwischen Sensoren und den Messwerten der Geräte selbst, Zugehörigkeit zu Organisationen, Standorten usw. Mit diesen Informationen können Sie dynamisch beurteilen, wie sich ein bestimmter Indikator entwickelt hat über einen bestimmten Zeitraum verändert. Wir nutzen den „Roh“-Datenspeicher unter anderem als Backup und bei Bedarf zur Wiederherstellung vorverarbeiteter Daten.
Als wir vor einigen Jahren nach einer Lösung für unser Speicherproblem suchten, standen uns zwei Plattformen zur Auswahl: Kubernetes und OpenStack. Da Letzteres aber ziemlich monströs aussieht (sehen Sie sich einfach seine Architektur an, um sich davon zu überzeugen), haben wir uns für Kubernetes entschieden. Ein weiteres Argument dafür war die relativ einfache Softwaresteuerung, die Möglichkeit, auch Hardwareknoten je nach Ressourcen flexibler zu zerlegen.
Parallel zur Beherrschung von Kubernetes selbst haben wir auch Möglichkeiten zur Datenspeicherung untersucht. Während wir unseren gesamten Speicher in Kubernetes auf unserer eigenen Hardware behielten, erhielten wir hervorragendes Fachwissen. Alles, was wir damals hatten, lebte auf Kubernetes: Statefull Storage, Monitoring-System, CI/CD. Kubernetes ist für uns zu einer All-in-One-Plattform geworden.
Aber wir wollten mit Kubernetes als Service arbeiten und uns nicht mit dessen Support und Entwicklung befassen. Außerdem gefiel uns nicht, wie viel es uns gekostet hat, es auf Bare-Metal zu betreiben, und wir mussten ständig weiterentwickelt werden! Eine der ersten Aufgaben bestand beispielsweise darin, Kubernetes-Ingress-Controller in die Netzwerkinfrastruktur unserer Organisation zu integrieren. Dies ist eine umständliche Aufgabe, insbesondere wenn man bedenkt, dass zu diesem Zeitpunkt noch nichts für eine programmatische Ressourcenverwaltung wie DNS-Einträge oder die Zuweisung von IP-Adressen bereit war. Später begannen wir mit der externen Datenspeicherung zu experimentieren. Wir kamen nie dazu, die PVC-Steuerung zu implementieren, aber schon damals wurde klar, dass dies ein großer Arbeitsbereich war, der engagierte Spezialisten erforderte.
Der Wechsel zur Google Cloud Platform ist eine vorübergehende Lösung
Wir erkannten, dass dies nicht so weitergehen konnte, und verlagerten unsere Daten von Bare-Metal auf die Google Cloud Platform. Tatsächlich gab es damals für ein russisches Unternehmen nicht viele interessante Optionen: Neben der Google Cloud Platform bot nur Amazon einen ähnlichen Dienst an, wir haben uns aber trotzdem für die Lösung von Google entschieden. Dann erschien es uns wirtschaftlich rentabler, näher am Upstream, ganz zu schweigen von der Tatsache, dass Google selbst eine Art PoC Kubernetes in Production ist.
Das erste große Problem zeichnete sich ab, als unser Kundenstamm wuchs. Als wir die Notwendigkeit hatten, personenbezogene Daten zu speichern, standen wir vor der Wahl: Entweder wir arbeiten mit Google zusammen und verstoßen gegen russische Gesetze, oder wir suchen nach einer Alternative in der Russischen Föderation. Die Wahl war im Großen und Ganzen vorhersehbar. 🙂
Wie wir den idealen Cloud-Service sahen
Zu Beginn der Suche wussten wir bereits, was wir vom zukünftigen Cloud-Anbieter bekommen wollten. Welchen Service haben wir gesucht:
- Schnell und flexibel. So können wir jederzeit schnell einen neuen Knoten hinzufügen oder etwas bereitstellen.
- Preiswert. Wir waren sehr besorgt über die finanzielle Frage, da unsere Ressourcen begrenzt waren. Wir wussten bereits, dass wir mit Kubernetes arbeiten wollten, und nun bestand die Aufgabe darin, die Kosten zu minimieren, um die Effizienz der Nutzung dieser Lösung zu steigern oder zumindest aufrechtzuerhalten.
- Automatisiert. Wir hatten geplant, mit dem Dienst über die API zu arbeiten, ohne Manager und Telefonanrufe oder Situationen, in denen wir mehrere Dutzend Knoten manuell im Notfallmodus hochfahren müssen. Da die meisten unserer Prozesse automatisiert sind, erwarteten wir dasselbe vom Cloud-Service.
- Mit Servern in der Russischen Föderation. Natürlich hatten wir vor, die russische Gesetzgebung und ebendiese 152-FZ einzuhalten.
Zu dieser Zeit gab es in Russland nur wenige Kubernetes-aaS-Anbieter und bei der Auswahl eines Anbieters war es für uns wichtig, unsere Prioritäten nicht zu gefährden. Das Mail.ru Cloud Solutions-Team, mit dem wir zu arbeiten begonnen haben und noch immer zusammenarbeiten, hat uns einen vollautomatischen Service mit API-Unterstützung und einem praktischen Control Panel einschließlich Horizon zur Verfügung gestellt – damit konnten wir schnell eine beliebige Anzahl von Knoten aufbauen.
Wie wir es geschafft haben, in zwei Stunden auf MCS zu migrieren
Bei solchen Schritten stoßen viele Unternehmen auf Schwierigkeiten und Rückschläge, in unserem Fall jedoch nicht. Wir hatten Glück: Da wir bereits vor Beginn der Migration auf Kubernetes arbeiteten, korrigierten wir lediglich drei Dateien und starteten unsere Dienste auf der neuen Cloud-Plattform MCS. Ich möchte Sie daran erinnern, dass wir zu diesem Zeitpunkt endlich das Bare-Metal hinter uns gelassen hatten und auf der Google Cloud Platform lebten. Daher dauerte der Umzug selbst nicht länger als zwei Stunden, außerdem wurde etwas mehr Zeit (etwa eine Stunde) für das Kopieren von Daten von unseren Geräten aufgewendet. Wir nutzten bereits damals Spinnaker (einen Multi-Cloud-CD-Dienst zur Bereitstellung von Continous Delivery). Wir haben es auch schnell zum neuen Cluster hinzugefügt und wie gewohnt weitergearbeitet.
Dank der Automatisierung von Entwicklungsprozessen und CI/CD wird Kubernetes bei URUS von einem Spezialisten (und das bin ich) betreut. Irgendwann arbeitete ein anderer Systemadministrator mit mir zusammen, aber dann stellte sich heraus, dass wir bereits alle Hauptroutinen automatisiert hatten und es immer mehr Aufgaben seitens unseres Hauptprodukts gab und es sinnvoll war, Ressourcen darauf zu lenken.
Wir haben vom Cloud-Anbieter das bekommen, was wir erwartet hatten, da wir die Zusammenarbeit ohne Illusionen begonnen haben. Wenn es Vorfälle gab, waren diese meist technischer Natur und ließen sich leicht durch die relative Aktualität des Dienstes erklären. Die Hauptsache ist, dass das MCS-Team Mängel schnell beseitigt und Fragen im Messenger schnell beantwortet.
Wenn ich meine Erfahrungen mit der Google Cloud Platform vergleiche, wusste ich in ihrem Fall nicht einmal, wo sich der Feedback-Button befindet, da einfach kein Bedarf dafür bestand. Und wenn es dennoch zu Problemen kam, verschickte Google selbst einseitig Benachrichtigungen. Aber im Fall von MCS liegt meiner Meinung nach der große Vorteil darin, dass sie so nah wie möglich an den russischen Kunden sind – sowohl geografisch als auch mental.
Wie wir uns die Arbeit mit Clouds in der Zukunft vorstellen
Jetzt ist unsere Arbeit eng mit Kubernetes verbunden und passt aus Sicht der Infrastrukturaufgaben voll und ganz zu uns. Daher planen wir nicht, von dort zu migrieren, obwohl wir ständig neue Praktiken und Dienste einführen, um Routineaufgaben zu vereinfachen und neue zu automatisieren, die Stabilität und Zuverlässigkeit der Dienste zu erhöhen ... Wir starten jetzt den Chaos Monkey-Dienst (insbesondere). , wir verwenden Chaoskube, aber das ändert nichts am Konzept :), das ursprünglich von Netflix erstellt wurde. Chaos Monkey macht eine einfache Sache: Es löscht einen zufälligen Kubernetes-Pod zu einem zufälligen Zeitpunkt. Dies ist notwendig, damit unser Dienst mit der Anzahl der Instanzen n–1 normal funktioniert, daher trainieren wir uns, um auf etwaige Probleme vorbereitet zu sein.
Mittlerweile halte ich den Einsatz von Drittlösungen – den gleichen Cloud-Plattformen – für das einzig Richtige für junge Unternehmen. Normalerweise sind ihnen zu Beginn ihrer Reise nur begrenzte personelle und finanzielle Ressourcen zur Verfügung, und der Aufbau und die Wartung einer eigenen Cloud oder eines eigenen Rechenzentrums ist zu teuer und arbeitsintensiv. Mit Cloud-Anbietern können Sie diese Kosten minimieren; Sie können von ihnen schnell die Ressourcen erhalten, die für den Betrieb von Diensten hier und jetzt erforderlich sind, und diese Ressourcen im Nachhinein bezahlen. Was das Unternehmen URUS betrifft, bleiben wir Kubernetes in der Cloud vorerst treu. Aber wer weiß, möglicherweise müssen wir geografisch expandieren oder Lösungen implementieren, die auf bestimmten Geräten basieren. Oder vielleicht rechtfertigt die Menge der verbrauchten Ressourcen ein eigenes Kubernetes auf Bare-Metal, wie in den guten alten Zeiten. 🙂
Was wir aus der Arbeit mit Cloud-Diensten gelernt haben
Wir haben angefangen, Kubernetes auf Bare-Metal zu verwenden, und selbst dort war es auf seine Weise gut. Doch seine Stärken zeigten sich gerade als AaS-Komponente in der Cloud. Wenn Sie sich ein Ziel setzen und alles so weit wie möglich automatisieren, können Sie eine Anbieterbindung vermeiden und der Wechsel zwischen Cloud-Anbietern wird ein paar Stunden dauern und die Nervenzellen bleiben bei uns. Wir können anderen Unternehmen raten: Wenn Sie Ihren eigenen (Cloud-)Dienst starten möchten, über begrenzte Ressourcen und maximale Entwicklungsgeschwindigkeit verfügen, beginnen Sie jetzt mit der Anmietung von Cloud-Ressourcen und bauen Sie Ihr Rechenzentrum auf, nachdem Forbes über Sie schreibt.
Source: habr.com