Moderne Infrastruktur: Probleme und Perspektiven

Ende Mai haben wir ein Online-Meeting zum Thema „Moderne Infrastruktur und Container: Probleme und Perspektiven“. Wir haben über Container, Kubernetes und Orchestrierung im Allgemeinen gesprochen, über Auswahlkriterien für Infrastruktur und vieles mehr. Die Teilnehmer teilten Fallstudien aus ihrer eigenen Praxis.

Teilnehmer:

• Evgeny Potapov, CEO von „ITSumma“. Mehr als die Hälfte seiner Kunden wechseln bereits oder wollen auf Kubernetes umsteigen.
• Dmitry Stolyarov, CTO von „Flant“. Verfügt über mehr als 10 Jahre Erfahrung mit containerbasierten Systemen.
• Denis Remchukov (alias Eric Oldmann), COO von argotech.io, ehemaliges Mitglied von RAO EES. Hat versprochen, über Fallstudien im „blutigen“ Enterprise zu berichten.
• Andrey Fedorovsky, CTO von „News360.com“. Nach dem Kauf des Unternehmens durch einen anderen Spieler verantwortlich für eine Reihe von ML- und AI-Projekten sowie für die Infrastruktur.
• Ivan Kruglov, Systemingenieur, ehemaliger Mitarbeiter von Booking.com.Derjenige, der mit eigenen Händen sehr viel mit Kubernetes gemacht hat.

Themen:

• Einblicke der Teilnehmer zu Containern und Orchestrierung (Docker, Kubernetes usw.); was sie in der Praxis ausprobiert oder analysiert haben.
• Fallstudie: Das Unternehmen erstellt einen Entwicklungsplan für die Infrastruktur für Jahre. Wie wird entschieden, ob die bestehende Infrastruktur auf Containern und Kubernetes aufgebaut oder umgestellt werden soll?
• Probleme in der Welt der Cloud-Native, was fehlt, lasst uns fantasieren, was morgen sein wird.

Es entwickelte sich eine interessante Diskussion, die Meinungen der Teilnehmer waren so unterschiedlich und führten zu zahlreichen Kommentaren, dass ich sie mit euch teilen möchte. Es gibt ein Video von drei Stunden, und weiter unten – eine Zusammenfassung der Diskussion.

Ist Kubernetes bereits ein Standard oder einfach gutes Marketing?

„Wir sind zu ihm (Kubernetes – Red.) gekommen, als noch niemand wusste, was es ist. Wir sind schon damals zu ihm gekommen, als es ihn noch nicht gab. Wir wollten ihn schon vorher“ – Dmitry Stolyarov

Foto von Reddit.com

Vor 5-10 Jahren gab es eine riesige Anzahl von Werkzeugen und keinen einheitlichen Standard. Alle sechs Monate kam ein neues Produkt, manchmal auch mehr als eines. Zuerst Vagrant, dann Salt, Chef, Puppet,… „und du baust deine Infrastruktur alle sechs Monate um. Du hast fünf Administratoren, die ständig damit beschäftigt sind, Konfigurationen neu zu schreiben“ – erinnert sich Andrey Fedorovsky. Er ist der Meinung, dass Docker und Kubernetes die anderen „überwältigt“ haben. Docker ist in den letzten fünf Jahren zum Standard geworden, Kubernetes in den letzten zwei Jahren. Und das ist gut für die Branche..

Dmitri Stolyarov und sein Team lieben Kubernetes. Sie wollten ein solches Werkzeug, bevor es überhaupt auf den Markt kam, und fanden es, als noch niemand davon wusste. Derzeit nehmen sie aus Gründen der Praktikabilität keinen Kunden an, wenn sie verstehen, dass sie bei ihm kein Kubernetes implementieren werden. Laut Dmitri hat das Unternehmen "eine Menge gigantischer Erfolgsgeschichten im Umgang mit schrecklichem Legacy".

Kubernetes ist nicht nur Container-Orchestrierung, sondern ein Konfigurationsverwaltungssystem mit einer umfangreichen API, einem Netzwerkkomponenten, L3-Lastverteilung und Ingress-Controllern, das es relativ einfach macht, Ressourcen zu verwalten, zu skalieren und sich von den unterliegenden Infrastrukturschichten zu abstrahieren.

Leider muss man im Leben für alles bezahlen. Und diese Steuer ist hoch, insbesondere wenn man über den Übergang zu Kubernetes für Unternehmen mit einer entwickelten Infrastruktur spricht, wie Ivan Kruglov meint. Er könnte problemlos in einem Unternehmen mit traditioneller Infrastruktur oder mit Kubernetes arbeiten. Wichtig ist, die Besonderheiten des Unternehmens und des Marktes zu verstehen. Für Evgeny Potapov, der Kubernetes jedoch als jedes Orchestrierungstool betrachten würde, stellt sich eine solche Frage nicht.

Evgeny zog einen Vergleich zur Situation in den 1990er Jahren, als objektorientierte Programmierung als Ansatz zur Entwicklung komplexer Anwendungen entstand. Zu diesem Zeitpunkt hörten die Debatten nicht auf und neue Werkzeuge, die OOP unterstützten, kamen auf. Danach entstanden Mikrodienste, um von der monolithischen Konzeption abzurücken. Dies führte wiederum zur Entstehung von Containern und Werkzeugen zu deren Verwaltung. „Ich denke, bald kommen wir an den Punkt, an dem die Frage, ob man eine kleine Anwendung mikrodienstlich schreiben sollte, nicht mehr gestellt wird; sie wird standardmäßig als Mikrodienst erstellt”, sagt er. Ähnlich werden Docker und Kubernetes im Laufe der Zeit zu einer Standardlösung ohne die Notwendigkeit einer Wahl.

Das Problem mit Datenbanken ist stateless.

Foto von Twitter: @jankolario auf Unsplash

Heutzutage gibt es viele Rezepte für den Betrieb von Datenbanken in Kubernetes. Sogar dafür, wie man den Teil, der mit Disk I/O arbeitet, von dem, sagen wir, Anwendungsteil der Datenbank trennt. Ist es möglich, dass sich Datenbanken in der Zukunft so verändern, dass sie in einer Box geliefert werden, wobei ein Teil über Docker und Kubernetes orchestriert wird und im anderen Teil der Infrastruktur, über separate Software, der Storage-Bereich bereitgestellt wird? Werden sich Datenbanken als Produkt verändern?

Diese Beschreibung ähnelt dem Management von Warteschlangen, aber die Anforderungen an Zuverlässigkeit und Synchronität von Informationen in traditionellen Datenbanken sind laut Andrei wesentlich höher. Die Cache-Hit-Rate liegt in normalen Datenbanken bei etwa 99 %. Wenn ein Worker ausfällt, wird ein neuer gestartet, und der Cache wird von Grund auf neu aufgebaut. Solange der Cache nicht aufgeheizt ist, arbeitet der Worker langsam, was bedeutet, dass er nicht mit Benutzerlast belastet werden kann. Solange keine Benutzerlast vorhanden ist, wird der Cache nicht aufgeheizt. Dies ist ein Teufelskreis.

Dmitri ist entschieden anderer Meinung – Quoren und Sharding lösen das Problem. Aber Andrei besteht darauf, dass die Lösung nicht für alle geeignet ist. In einigen Situationen kann ein Quorum in Ordnung sein, aber es belastet zusätzlich das Netzwerk. Eine NoSQL-Datenbank eignet sich nicht in allen Fällen.

Die Teilnehmer des Meetups haben sich in zwei Lager gespalten.

Denis und Andrei behaupten, dass alles, was auf die Festplatte geschrieben wird – Datenbanken und anderes – im aktuellen Kubernetes-Ökosystem unmöglich ist. Es ist unmöglich, die Integrität und Konsistenz produktiver Daten in Kubernetes aufrechtzuerhalten. Das ist eine fundamentale Eigenschaft. Die Lösung: hybride Infrastruktur.

Selbst moderne Cloud-native Datenbanken wie MongoDB und Cassandra oder Nachrichtenwarteschlangen wie Kafka oder RabbitMQ erfordern ständige Datenspeicher außerhalb von Kubernetes.

Evgeny widerspricht: "Datenbanken in Kubernetes sind ein Trauma für Russland oder eine quasi-unternehmerische Erfahrung, die damit zusammenhängt, dass es in Russland keine Cloud-Nutzung gibt." Kleine oder mittlere Unternehmen im Westen nutzen die Cloud. Amazon RDS-Datenbanken sind einfacher zu verwenden, als sich selbst mit Kubernetes zu beschäftigen. In Russland wird Kubernetes ‘on-premise’ verwendet und Datenbanken werden dorthin verschoben, wenn man versucht, den Zoo loszuwerden.

Dmitri war ebenfalls nicht mit der Aussage einverstanden, dass keine Datenbanken in Kubernetes gehalten werden können: „Das hängt von der Datenbank ab. Und wenn man eine riesige relationale Datenbank hineinsteckt – auf keinen Fall. Wenn man etwas Kleines und Cloud-natives hineinsteckt, das moralisch bereit für ein semi-ephemeres Leben ist, wird alles gut sein.“ Dmitri erwähnte außerdem, dass die Verwaltungswerkzeuge für Datenbanken weder für Docker noch für Kubernetes bereit sind, deshalb gibt es große Schwierigkeiten.

Ivan ist sich seinerseits sicher, dass die Ökosysteme der Unternehmenslösungen in Kubernetes, selbst wenn man die Begriffe stateful und stateless außen vor lässt, noch nicht bereit sind. Es ist schwierig, die Anforderungen von Gesetzgebern und Regulierungsbehörden mit Kubernetes zu erfüllen. Zum Beispiel ist es unmöglich, eine Lösung für die Bereitstellung von Identitäten zu schaffen, die strenge Garantien für die Identifizierung des Servers verlangen, bis hin zur Hardware, die in die Server eingebaut wird. Dieser Bereich entwickelt sich, aber eine Lösung gibt es derzeit nicht.
Die Teilnehmer konnten sich nicht einigen, daher wird es in diesem Teil keine Schlussfolgerungen geben. Besser geben wir ein paar praktische Beispiele.

Fall 1. Cybersicherheit des "Mega-Regulators" mit Datenbanken außerhalb von Kubernetes

Im Fall eines ausgereiften Systems für Cybersicherheit ermöglichen die Nutzung von Containern und Orchestrierung, sich gegen Angriffe und Eindringlinge zu verteidigen. Zum Beispiel hat Denis mit seinem Team in einem Mega-Regulator eine Verbindung zwischen dem Orchestrator und einem trainierten SIEM-Dienst realisiert, der die Protokolle in Echtzeit analysiert und den Angriffs-, Einbruch- oder Ausfallprozess identifiziert. Im Falle eines Angriffs, eines Versuchs, etwas abzulegen, oder bei einem Eindringen durch Ransomware hebt er über den Orchestrator Container mit Anwendungen schneller an, als sie infiziert werden, oder schneller, als sie von einem Angreifer angegriffen werden.

Fall 2. Teilweise Migration der Datenbanken von Booking.com nach Kubernetes

Bei Booking.com ist die Hauptdatenbank MySQL mit asynchroner Replikation – es gibt einen Master und eine ganze Hierarchie von Slaves. Zu dem Zeitpunkt, als Ivan das Unternehmen verließ, war ein Projekt zur Migration von Slaves gestartet worden, die man "abstoßen" konnte, ohne große Schäden zu verursachen.

Neben der Hauptdatenbank gibt es eine Installation von Cassandra mit einer selbst geschriebenen Orchestrierung, die noch vor dem Aufstieg von Kubernetes entwickelt wurde. In dieser Hinsicht gibt es keine Probleme, aber sie verfügt über Persistent Storage auf lokalen SSDs. Remote-Speicher, selbst innerhalb eines Rechenzentrums, werden aufgrund hoher Latenzzeiten nicht verwendet.

Die dritte Art von Datenbanken ist der Suchdienst von Booking.com, bei dem jeder Knoten des Dienstes eine Datenbank ist. Die Versuche, den Suchdienst nach Kubernetes zu migrieren, sind gescheitert, da jeder Knoten 60–80 GB lokalen Speicher benötigt, was schwer "hochzufahren" und "aufzutauen" ist.

Letztendlich wurde die Suchmaschine nicht nach Kubernetes migriert, und Ivan glaubt nicht, dass es in naher Zukunft neue Versuche geben wird. Die MySQL-Datenbank wurde zur Hälfte migriert: nur die Slaves, deren Abstoßen keine großen Probleme verursacht.

Die Wahl der Infrastruktur als Aufgabe ohne allgemeine Lösung

Foto von Manuel Geissinger von Pexels

Angenommen, wir haben ein neues Unternehmen oder ein Unternehmen, dessen Infrastruktur teilweise veraltet ist. Dort wird ein Infrastrukturentwicklungsplan für Jahre erstellt. Wie wird entschieden, ob die Infrastruktur auf Containern und Kubernetes aufgebaut werden soll oder nicht?

Unternehmen, die um Nanosekunden konkurrieren, sind aus der Diskussion ausgeschlossen. Gesunder Konservatismus rentiert sich aus Gründen der Zuverlässigkeit, dennoch gibt es Unternehmen, die neue Ansätze in Betracht ziehen sollten.

Ivan: "Ich würde jetzt definitiv ein Unternehmen in der Cloud gründen, einfach weil es schneller ist", obwohl es nicht unbedingt günstiger ist. Mit dem Wachstum des Risikokapitals haben Startups mit Geldern große Probleme nicht, und die Hauptaufgabe besteht darin, den Markt zu erobern.

Ivan ist der Ansicht, dass die Entwicklung der aktuellen Infrastruktur ein Kriterium für die Auswahl ist. Wenn in der Vergangenheit erhebliche Investitionen getätigt wurden und es funktioniert, hat es keinen Sinn, alles neu zu gestalten. Wenn die Infrastruktur jedoch nicht entwickelt ist und es Probleme mit Tools, Sicherheit und Überwachung gibt, macht es Sinn, sich die verteilte Infrastruktur anzusehen.

Die Steuer muss in jedem Fall gezahlt werden, und Ivan würde die zahlen, die ihm in der Zukunft ermöglicht, weniger zu zahlen. "Denn allein dadurch, dass ich in einem Zug fahre, der von anderen betrieben wird, werde ich viel weiter fahren als wenn ich in einen anderen Zug steige, in den ich selbst Treibstoff hineinwerfen muss." — sagt Ivan. Wenn das Unternehmen neu ist und die Anforderungen an die Latenz in zehn oder mehr Millisekunden liegen, würde Ivan in Richtung der "Betreiber" schauen, in die heute klassische Datenbanken "eingewickelt" werden. Sie richten eine Replikationskette ein, die sich im Falle eines Fehlers selbst umschaltet usw.

Für ein kleines Unternehmen mit ein paar Servern in Kubernetes macht es keinen Sinn, — behauptet Andrei. Wenn es jedoch plant, auf eine Hundert Server und mehr zu wachsen, sind Automatisierung und ein Ressourcenmanagementsystem erforderlich. 90 % der Fälle rechtfertigen die Kosten. Und zwar unabhängig von der Belastung und den Ressourcen. Allen, von Startups bis hin zu großen Unternehmen mit Millionen von Nutzern, macht es Sinn, schrittweise in Richtung Produkte zur Orchestrierung von Containern zu schauen. "Ja, das ist wirklich die Zukunft", ist Andrei überzeugt.

Denis nannte zwei Hauptkriterien — Skalierbarkeit und Betriebsstabilität. Er wird die Werkzeuge auswählen, die am besten für diese Aufgabe geeignet sind. „Das könnte ein zusammengebastelter No-Name-Server sein, auf dem Nutanix Community Edition läuft. Es könnte auch eine zweite Linie in Form einer Anwendung auf Kuber mit einer Datenbank im Backend sein, die repliziert wird und festgelegte RTO- und RPO-Parameter hat“ (Recovery Time/Point Objectives — Beispiel).

Evgeny wies auf ein mögliches Problem mit Fachkräften hin. Derzeit gibt es nicht viele hochqualifizierte Spezialisten, die sich „in den Tiefen“ auskennen. Tatsächlich, wenn die gewählte Technologie veraltet ist, ist es schwierig, jemanden einzustellen, außer älteren, gelangweilten und frustrierten Menschen. Dennoch sind sich andere Teilnehmer einig, dass es sich um ein Ausbildungsproblem handelt.
Wenn es darum geht, eine Entscheidung zu treffen: eine kleine Firma in der Public Cloud mit Datenbanken in Amazon RDS oder „on premise“ mit Datenbanken in Kubernetes zu starten, fiel die Wahl der Teilnehmer trotz einiger Nachteile auf Amazon RDS.

Da die meisten Teilnehmer des Meetups nicht aus dem „blutigen“ Enterprise-Bereich kommen, sind verteilte Lösungen das, worauf man hinarbeiten sollte. Speichersysteme sollten verteilt und zuverlässig sein und Latenzen im Bereich von Millisekunden, maximal jedoch im Dutzendbereich erzeugen., — fasste Andrei zusammen.

Bewertung der Nutzung von Kubernetes

Der Zuhörer Anton Zhbankov stellte eine Fangfrage an die Apologeten von Kubernetes: Wie wurde die technische und wirtschaftliche Begründung ausgewählt und durchgeführt? Warum Kubernetes, warum nicht virtuelle Maschinen, zum Beispiel?

Foto von Tatyana Eremina auf Unsplash

Darauf antworteten Dmitrij und Ivan. In beiden Fällen wurde durch Versuch und Irrtum eine Entscheidungsreihe getroffen, die dazu führte, dass beide Teilnehmer zu Kubernetes gelangten. Heute beginnt das Geschäft, Software zu entwickeln, die sinnvoll nach Kuber migriert werden kann. Es handelt sich nicht um klassische Drittanbietersysteme wie 1C. Kubernetes hilft, wenn Entwickler schnell Releases durchführen müssen, bei ununterbrochenem kontinuierlichen Verbesserung.

Andreis Team versuchte, ein skalierbares Cluster auf der Basis von virtuellen Maschinen zu erstellen. Die Nodes fielen wie Dominosteine, was manchmal zum Ausfall des Clusters führte. „Theoretisch könnte man es nachbessern und manuell warten, aber das ist mühsam. Und wenn auf dem Markt eine Lösung vorhanden ist, die sofort einsatzbereit ist, gehen wir gerne darauf zu. Und das haben wir letztlich auch getan“, — erzählt Andrei.

Es gibt Standards für eine solche Analyse und Berechnung, aber niemand kann sagen, wie genau sie auf echtem, in Betrieb befindlichem Material sind. Für die Berechnungen ist es auch wichtig, sich mit jedem Tool und der zugehörigen Ökosystem auszukennen, aber das ist unmöglich.

Was erwartet uns

Foto von Drew Beamer auf Unsplash

Wenn Technologien sich weiterentwickeln, kommen immer mehr disparate Teile zusammen, und es erfolgt ein Phasenübergang, ein Anbieter taucht auf, der genug „Bares“ investiert hat, damit alles in einem einzigen Tool zusammenkommt.

Kommt Ihnen nicht auch der Gedanke, dass der Moment kommen wird, an dem es ein Tool gibt, das für die Welt von Linux so wichtig wird wie Ubuntu? Vielleicht wird ein einheitliches Tool für Containerisierung und Orchestrierung auch Kubernetes umfassen. Damit wird es einfach, On-Premise Clouds zu erstellen.

Ivans Antwort war: „Google baut gerade Anthos — das ist ihr Paketangebot, das die Cloud aufsetzt und Kuber, Service Mesh, Monitoring — die gesamte Infrastruktur, die für Microservices in einem On-Premise-Umfeld benötigt wird, umfasst. Wir sind fast in der Zukunft.“

Denis erwähnte auch Nutanix und VMWare mit dem Produkt vRealize Suite, die eine ähnliche Aufgabe ohne Containerisierung bewältigen können.

Dmitry teilte die Ansicht, dass die Verringerung von „Schmerzen“ und die Senkung der Steuer zwei Bereiche sind, in denen Verbesserungen zu erwarten sind.

Zusammenfassend der Diskussion möchten wir die folgenden Probleme der modernen Infrastruktur hervorheben

• Drei Teilnehmer haben sofort das Problem des Stateful hervorgehoben.
• Verschiedene Arten von Sicherheitsunterstützungsproblemen, einschließlich der Wahrscheinlichkeit, dass mehrere Versionen von Python, Application-Servern und Komponenten in Docker landen.
  Übermäßiger Verbrauch, zu dem es besser ist, ein separates Meetup abzuhalten.
  Das Problem des Lernens, da Orchestrierung ein komplexes Ökosystem darstellt.
  Ein allgemeines Problem der Branche ist die Nutzung von Tools für andere Zwecke.

  Die weiteren Schlussfolgerungen überlasse ich Ihnen. Momentan bleibt das Gefühl, dass die Kombination Docker+Kubernetes es nicht leicht haben wird, zu einem „zentralen“ Bestandteil des Systems zu werden. Zum Beispiel werden Betriebssysteme zuerst auf die Hardware installiert, was man von Containern und Orchestrierung nicht sagen kann. Vielleicht werden in Zukunft Betriebssysteme und Container mit Cloud-Management-Software zusammenwachsen.

  
  Foto von Gabriel Santos Fotografia von Pexels

  Ich möchte die Gelegenheit nutzen, um meiner Mutter zu grüßen und daran zu erinnern, dass wir eine Facebook-Gruppe haben „Management und Entwicklung großer IT-Projekte“, Kanal @feedmeto mit interessanten Beiträgen aus verschiedenen Tech-Blogs. Und mein Kanal @rybakalexey, wo ich über das Management der Entwicklung in Produktunternehmen spreche.

Quelle: habr.com