In diesem Artikel berichtet Igor Kotenko, Chefarchitekt von Neoflex, über seine Erfahrungen mit der Bereitstellung einer Containerisierungsplattform in einer Unternehmensinfrastruktur.
Die Gründe, warum Unternehmen normalerweise eine On-Premise-Lösung wählen, sind häufig nicht technologisch und hängen häufig mit der Finanzierung zusammen. Jemand versucht, die Betriebskosten zu senken (für externe Clouds zu bezahlen), um das Unternehmen zu kapitalisieren (eigene Server zu kaufen), jemand verfügt bereits über solide Hardwareressourcen und möchte diese in einer Microservice-Architektur verwenden.
Bevor wir zu den Implementierungsdetails übergehen, wenden wir uns den Begriffen zu.
Der Begriff "Wolken" wird als sehr überlastet angesehen. Es ist üblich, zwischen verschiedenen Arten von Cloud-Lösungen zu unterscheiden:
- Infrastructure as a Service (IAAS) - Hardware (normalerweise virtuell);
- Software as a Service (SAAS), zum Beispiel DBAS - Datenbank als Service;
- Plattform als Service (PAAS);
- Application as a Service (AAAS).
Gleichzeitig hindert nichts die Schichten daran, aufeinander aufzubauen. Offensichtlich wird es eine Infrastruktur unter der Plattform oder Software geben.
Es gibt einige Verwirrung über den Begriff "Private Clouds". Manchmal wird dies als Cloud bezeichnet, die vor Ort bereitgestellt wird, manchmal in einer geleasten Infrastruktur mit vollständiger Isolierung Ihres Netzwerksegments. Es wurden sogar virtuelle Maschinen mit verschlüsseltem Speicher und Festplatten erwähnt, während ein Speicherauszug dem Anbieter keinen Zugriff auf Ihre Informationen gewährt. In diesem Artikel werden wir Lösungen diskutieren, die intern bereitgestellt werden - vor Ort.
Bei der Einführung von Private Clouds wird erwartet, dass diese mit öffentlichen Clouds identisch sind, nur billiger, sicherer und zuverlässiger. Daher denken viele Leute, dass private Clouds a priori besser sind. Oft stellen Experten einfach die ausgewählte Version von Kubernetes oder Openshift bereit und glauben, dass hier ihre Arbeit abgeschlossen ist.
Was Unternehmen von der Implementierung von On-Premise-Clouds erwarten:
- Niedrige Ressourcenkosten. Weil Sie nur für das bezahlen, was Sie verwenden.
- Die Fähigkeit, Ressourcen so schnell wie möglich hinzuzufügen und zurückzugeben.
- Fehlertoleranz. Der Server stürzte ab, stattdessen wurde automatisch ein anderer angegeben.
- Niedrige Supportkosten.
Wie wird dies in öffentlichen Clouds erreicht?
In der Regel aufgrund der Automatisierung von Prozessen, Skaleneffekten (billiger in loser Schüttung) und der Aufteilung von Ressourcen zwischen verschiedenen Verbrauchern.
Betrachten Sie diese Versprechen im Kontext von Private Clouds.
1. Niedrige Ressourcenkosten im Vergleich zur herkömmlichen Infrastruktur.
In der Tat ist es nicht so. Dieselbe Software wurde auf denselben Computern bereitgestellt, jedoch in Containern. Nach unserer Erfahrung werden im Gegenteil mehr Ressourcen verschwendet.
2. Fähigkeit, Ressourcen extrem schnell zu erhöhen und zu verringern.
Nein. Um zu erweitern, müssen Sie entweder die Hot Reserve an Hardware- und Softwarelizenzen im Leerlauf halten oder zuerst etwas Unnötiges wegwerfen. Sie können Ressourcen außer Betrieb nehmen, aber dann sind sie inaktiv.
3. Fehlertoleranz.
Ja, aber es gibt viele Nuancen. Angenommen, der Server ist ausgefallen. Wo kann ich noch einen bekommen? Wie kann ich es schnell bereitstellen und einem Cluster hinzufügen? Wenn Sie nicht Amazon sind, haben Sie nicht unendlich viele Ressourcen.
4. Niedrige Supportkosten.
Wir haben mindestens eine weitere Schicht (Containerisierungsplattform) hinzugefügt, mehrere neue Systeme. Wir brauchen Spezialisten mit neuen Kompetenzen. Woher kommen die Einsparungen?
Lassen Sie uns diese Fragen genauer untersuchen. Es ist wichtig zu bedenken, dass private Clouds mit vorhandenen Legacy-Systemen koexistieren müssen. Unternehmen sind gezwungen, die Infrastruktur bestehender Systeme parallel zu warten und eine hybride IT-Umgebung zu organisieren.
Natürlich sind 99% des Systems nicht von Grund auf neu gebaut. In der Regel gibt es bereits vor der Implementierung einer PAAS-Lösung eine Reihe von Prozessen und Automatisierungen, um die alte Infrastruktur zu unterstützen. DevOps-Prozesse, Planung und Ressourcenbesitz, Überwachung, Software-Updates, Sicherheit - all diese Probleme müssen während der Implementierung einer privaten Cloud vereinbart und geändert werden.
Wie sich DevOps-Prozesse ändern
In der Regel basiert der Ansatz zum Erstellen von DevOps vor der Implementierung Ihres eigenen PAAS auf der Verwendung von Konfigurationsautomatisierungssystemen wie Ansible oder Chef. Mit ihnen können Sie fast alle routinemäßigen IT-Prozesse automatisieren, häufig mithilfe vorgefertigter Skriptbibliotheken. Containerisierungsplattformen fördern jedoch einen alternativen Ansatz - die „unveränderliche Infrastruktur“. Es geht nicht darum, das vorhandene System zu ändern, sondern ein vorgefertigtes virtuelles Image des Systems mit neuen Einstellungen zu erstellen und das alte Image durch ein neues zu ersetzen. Der neue Ansatz negiert nicht den alten, sondern erzwingt die Konfigurationsautomatisierung in der Infrastrukturschicht. Bei Legacy-Systemen muss natürlich der alte Ansatz beibehalten werden.
Lassen Sie uns über die Infrastrukturschicht sprechen
Der De-facto-Standard in der IT ist die Verwendung einer virtuellen Infrastruktur. Wie die Praxis zeigt, ist die häufigste Option die Verwendung von vSphere. Dafür gibt es viele Gründe, aber auch Konsequenzen. In unserer Praxis wurden häufige Probleme mit der Überzeichnung von Ressourcen (ein Versuch, sieben Kappen von einer Haut zu nähen) durch den fast vollständigen Mangel an Kontrolle und Einfluss der Verantwortlichen für die Leistung der Lösung auf diesen Prozess verschärft. Die Abgrenzung der Verantwortungsbereiche in den Unternehmensbereichen, die Formalisierung der Ressourcenanforderungsverfahren und die unterschiedlichen Ziele des Bereichsmanagements führten zu Problemen in der Produktumgebung und inkonsistenten Lasttests. Irgendwann hat unsere Entwicklungsabteilung sogar ein virtuelles Tool zur Messung der Kernleistung erstellt.um den Mangel an Hardwareressourcen schnell zu diagnostizieren.
Es ist offensichtlich, dass der Versuch, eine Containerisierungsplattform auf einer solchen Infrastruktur zu platzieren, dem bestehenden Chaos neue Farben verleihen wird.
Die Frage, ob eine lokale Containerisierungsplattform eine virtuelle Infrastruktur benötigt oder ob es besser ist, sie Bare-Metal (auf Eisenservern) zu platzieren, wurde lange und ziemlich weit diskutiert. In Artikeln von Herstellern von Virtualisierungssystemen wird argumentiert, dass es praktisch keine Leistungsverluste gibt und die Vorteile zu groß sind. Auf der anderen Seite gibt es unabhängige Testergebnisse, die etwa 10% Leistungsverluste aussagen. Vergessen Sie nicht die Kosten für vSphere-Lizenzen. Zum Beispiel, um eine kostenlose Version von Kubernetes auf kostengünstiger Hardware zu installieren, um Geld zu sparen und für vSphere zu bezahlen? Umstrittene Entscheidung.
Erwähnenswert ist eine Open-Source-Infrastrukturvirtualisierungslösung, beispielsweise Open Stack. Im Allgemeinen wurde er als eine Lösung angesehen, die ernsthafte Investitionen in das Team erfordert. Es gibt Statistiken im Netzwerk, nach denen das Open Stack-Supportteam zwischen 20 und 60 Personen groß ist. Und das ist unabhängig von der Unterstützung der Containerisierungsplattform! Es gibt nur wenige solcher Spezialisten auf dem Markt, was ihre Kosten erhöht. Solche Investitionen zahlen sich normalerweise nur bei sehr großen Ressourcenmengen aus.
Es ist wichtig, die Anwesenheit von Spezialisten mit einzigartigen Kompetenzen im Unternehmen zu berücksichtigen. Leider werden Bare-Metal-Kubernetes-Installationen trotz der Vorteile von Transparenz und geringeren Lizenzkosten häufig durch das Fehlen geeigneter Tools zur Installationsautomatisierung behindert. Wir hoffen, dass die Zukunft zu diesem Ansatz gehört.
Ein weiterer Aspekt, der die Wahl zwischen virtuellen und Bare-Metal-Installationen beeinflusst, ist die Organisation von Eisenservern.
In der Regel kauft eine Organisation Server für bestimmte Zwecke. Sie können Server im Rechenzentrum mieten (von dem, was sie bieten), Sie können die Nomenklatur standardisieren und vereinheitlichen (Vereinfachung der Komponentenredundanz), Sie können Hardware sparen (viele kostengünstige Server), Sie können Rack-Platz sparen. Unterschiedliche Ansätze in unterschiedlichen Organisationen. Im Allgemeinen handelt es sich entweder um leistungsstarke Server mit einer großen Anzahl von Kernen und Speicher oder um ein relativ kleines Volumen oder um ein zusammengesetztes Durcheinander. Vergessen Sie jedoch nicht die Anforderungen älterer Systeme. An dieser Stelle stoßen wir erneut auf einen Widerspruch in den Konzepten. Kubernetes Ideologie ist eine Menge kostengünstiger Hardware und Bereitschaft für ihre Fehler. Der Server ist ausgefallen - es spielt keine Rolle, Ihre Dienste wurden auf einen anderen verschoben. Daten werden gespalten (dupliziert) und nicht an einen Container gebunden. Legacy-Ideologie - Redundanz auf Hardware-Ebene. RAID-Arrays,Festplatten-Racks, mehrere Netzteile auf dem Server, Hot-Swap. Konzentrieren Sie sich auf maximale Zuverlässigkeit. Es kann unangemessen teuer sein, sich an einer solchen Kubernetes-Infrastruktur zu beteiligen.
, …
Wenn ein Unternehmen Hochleistungsserver mit vielen Kernen an Bord hat, müssen diese möglicherweise auf verschiedene Verbraucher aufgeteilt werden. Hier können Sie nicht auf ein Virtualisierungssystem verzichten. Gleichzeitig muss die Möglichkeit eines Serverausfalls oder einer Unterbrechung der Wartung berücksichtigt werden. Die Arithmetik ist einfach: Wenn Sie zwei Server haben und einer ausfällt, benötigen Sie jeweils 50% Gangreserve. Wenn - 4 Server, wenn einer ausfällt, benötigen Sie 25% Reserve. Auf den ersten Blick ist alles einfach - Sie benötigen unendlich viele Server, dann wirkt sich der Ausfall eines Servers nicht auf die Gesamtkapazität aus und Sie müssen nichts reservieren. Leider kann die Größe der Ressourcen eines Hosts nicht stark reduziert werden. Zumindest sollten alle zugehörigen Komponenten berücksichtigt werden, die von der Kubernetes-Terminologie als "Pods" bezeichnet werden. Und natürlich beim Crushing in kleinere Server,Die Gemeinkosten für die Dienste der Plattform selbst steigen.
Aus praktischen Gründen ist es wünschenswert, die Hostparameter für die Plattform zu vereinheitlichen. In lebensnahen Beispielen gibt es zwei Rechenzentren (Unterstützung für das DR-Szenario bedeutet eine Kapazitätsreservierung von mindestens 50% in Bezug auf die Kapazität). Als nächstes werden die Anforderungen des Unternehmens an die Ressourcen der Containerisierungsplattform ermittelt und die Möglichkeit, sie auf Standard-Bare-Metal- oder virtuellen Hosts zu platzieren. Kubernetes Empfehlung - nicht mehr als 110 Pods pro Knoten.
Um die Größe des Knotens zu bestimmen, müssen Sie Folgendes berücksichtigen:
- Es ist wünschenswert, die Knoten gleich zu machen;
- Die Knoten müssen auf Ihre Hardware passen (für virtuelle Maschinen - Vielfache, N virtuell für eine Hardware);
- Wenn ein Knoten ausfällt (für die Option mit virtueller Infrastruktur - ein Eisenserver), sollten auf den verbleibenden Knoten genügend Ressourcen vorhanden sein, um Pods auf diese zu verschieben.
- Es dürfen nicht zu viele (> 110) Pods auf einem Knoten vorhanden sein.
- Wenn andere Dinge gleich sind, ist es wünschenswert, die Knoten größer zu machen.
Diese Art von Merkmalen muss in jedem Aspekt der Architektur berücksichtigt werden.
Zentralisierte Protokollierung - wie kann man aus mehreren Optionen auswählen?
Überwachung - Vielleicht funktioniert Ihr vorhandenes Überwachungssystem nicht, Sie behalten zwei oder migrieren auf ein neues?
Plattform-Updates auf eine neue Version - regelmäßig oder nur dann, wenn dies unbedingt erforderlich ist?
Fehlertolerantes Balancing zwischen zwei Rechenzentren - wie?
Sicherheitsarchitektur, Interaktion mit Legacy-Systemen - es gibt Unterschiede zu öffentlichen Clouds. Es ist möglich, Gebäudesysteme zu empfehlen, damit eine Migration in öffentliche Clouds möglich ist. Dies erschwert jedoch die Lösung.
Bei der Planung, Zuweisung und dem Besitz von Ressourcen für öffentliche und private Clouds gibt es kaum Unterschiede. Der Hauptunterschied ist die begrenzte Menge an Ressourcen. Wenn es in öffentlichen Clouds jederzeit möglich ist, zusätzliche notwendige Ressourcen zu nutzen, beispielsweise für Lasttests, muss On-Premise die Reihenfolge ihrer Verwendung sorgfältig planen. Dies bedeutet, dass Sie möglicherweise Nachtstarts haben und dementsprechend die Arbeit der Mitarbeiter der 2. und 3. Zeile zu ungünstigen Zeiten zunimmt. Nichts Neues für sich allein, aber ein bitterer Geschmack der Enttäuschung über die Wunder, die auf die Einführung der Private Cloud warten.
"Kader entscheiden alles"
Bei der Planung der Implementierung einer On-Premise-Containerisierungsplattform werden zunächst Spezialisten mit einzigartigen Kompetenzen benötigt. Es gibt eindeutig nicht genug davon auf dem gegenwärtigen Arbeitsmarkt. Darüber hinaus ist es ohne Erfahrung mit einer solchen Implementierung schwierig, eine Liste aller erforderlichen Spezialisten zu erstellen.
Damit die Plattform funktioniert, müssen Sie beispielsweise ein Speichersystem auswählen und installieren. Welches System Sie auch wählen (CEPH oder Portworx), es ist für die Plattform von entscheidender Bedeutung. Jeder weiß, dass ein Administrator für die Pflege einer Datenbank erforderlich ist. Ebenso benötigt ein Datenspeichersystem einen separaten Spezialisten. Leider denkt niemand darüber nach, bevor er das System implementiert! Beachten Sie, dass der Unterschied zwischen Administratoren für verschiedene Produkte erheblich ist - vergleichbar mit dem Unterschied zwischen Oracle DBA und MS SQL DBA. Sie benötigen mindestens zwei Personen für jede Rolle: Mitarbeiter fahren in den Urlaub, werden krank und geben sogar, Gott bewahre, auf. Und so weiter für jede Kompetenz, und die Liste der Kompetenzen, die zur Unterstützung der Lösung erforderlich sind, ist beeindruckend.
Ich möchte sofort vor Versuchen warnen, alle Kompetenzen einiger Universalsoldaten zu überschreiten. Ihre Kosten, Seltenheit und Verlustrisiken überschreiten alle angemessenen Grenzen.
Auch hier ist die Cloud-Wartung ein komplexer Prozess. Cloud-Unternehmen essen ihr Brot nicht umsonst: Dort, hinter dem bewölkten Nebel, steckt viel Technologie und investierte Arbeit.
Natürlich kann der Einsatz von Beratungsdiensten die Implementierung der Plattform erheblich beschleunigen. Erfahrene Partner helfen Ihnen, viele Fehler zu vermeiden, Prozesse einzurichten und Ihr Team zu schulen. Wenn Sie jedoch wichtige Services für Ihr Unternehmen auf der Plattform hosten, ist es ebenso wichtig, qualitativ hochwertigen Support und Entwicklung bereitzustellen. Darüber hinaus entwickeln sich derzeit alle auf dem Markt vorhandenen Systeme aktiv weiter, es erscheinen neue Technologien, neue Versionen der Plattform erfordern möglicherweise die Migration komplexer Prozesse und ernsthafte Tests vor der Aktualisierung. Ein starkes Support-Team ist erforderlich, um den zuverlässigen Betrieb des Systems sicherzustellen. Und Sie werden ein solches Team ständig brauchen.
Wann sollten Sie eine On-Premise-Containerisierungsplattform implementieren?
Zunächst muss das Verhältnis zwischen Investition und Rendite, das Kostenvolumen für Hardware und Mitarbeiter bewertet werden. Es muss entweder gute Gründe dafür geben, nicht in öffentlichen Clouds leben zu können, oder wirklich ernsthafte Ressourcenanforderungen. Das heißt, wenn ungefähr 100 Core für ein Unternehmen ausreichen und Sie nicht bereit sind, das Support-Team auf Dutzende von Personen zu erweitern, sollten Sie sich höchstwahrscheinlich auf öffentliche Clouds oder auf einfache Konfigurationen mit Anwendungsservern konzentrieren. Für die Unterstützung der Plattform ist eine Mindestteamgröße erforderlich, und die Kosten zahlen sich möglicherweise nicht aus. Bei der Skalierung von Ressourcen und der kompetenten Automatisierung aller Prozesse kann der Nutzen einer privaten Lösung jedoch sehr bedeutend sein. Viele hundert Knoten können mit dem gleichen Befehl verwaltet werden.
Ein weiteres Auswahlkriterium ist die Variabilität des Bedarfs an Rechenressourcen. Wenn die Geschäftsprozesse eines Unternehmens eine mehr oder weniger einheitliche Ressourcenlast erzeugen, ist es rentabler, eine eigene Infrastruktur zu entwickeln. Wenn Sie große Kapazitäten benötigen, aber selten, ziehen Sie öffentliche oder hybride Clouds in Betracht.
Wenn Sie sich für On-Premise-Lösungen entscheiden, sollten Sie sich auf ernsthafte und systematische Arbeit einstellen und sich darauf vorbereiten, in das Team zu investieren. Gehen Sie von einfach zu komplex. Achten Sie auf den Zeitrahmen für die Implementierung und seien Sie besonders vorsichtig, wenn Sie auf neue Plattformversionen aktualisieren. Nutzen Sie die Erfahrungen aus den Fehlern anderer, nicht aus Ihren.
Vielen Dank für das Lesen dieses Artikels. Wir hoffen, dass Sie die Informationen nützlich finden.