Dieser Artikel wurde von der Huawei Cloud Community geteilt : „Huawei Cloud Distributed Cloud Native UCS hilft MetaERP beim Aufbau hochverfügbarer verteilter Dienste auf Unternehmensebene“ , Autor: Cloud Container Future.
Einführung
Huawei Cloud wurde kürzlich als einziger chinesischer Hersteller im Bericht „Forrester Wave™: Multicloud Container Platforms, Q4 2023“ mit einer starken Marktleistung ausgewählt. Huawei Cloud Distributed Cloud Native UCS ist ein Schlüsseldienst in dieser Bewertung, und sein Wert für Multi-Cloud-Containeranwendungen wurde in der Bewertung einstimmig anerkannt. Gleichzeitig bestand UCS Anfang Dezember die Bewertung der Distributed-Cloud-Native-Fähigkeit der China Academy of Information and Communications Technology, und Huawei Cloud war das erste Unternehmen, das die Distributed-Cloud-Native-Fähigkeitsbewertung bestanden hat .
Für UCS sind neben der Anerkennung seitens maßgeblicher Organisationen auch immer mehr groß angelegte Produktionspraktiken durch Endbenutzer die größte Anerkennung für die Fähigkeiten von UCS. Insbesondere die jüngsten häufigen Single-Cluster-Live-Netzwerkunfälle haben immer mehr Aufmerksamkeit auf Disaster Recovery und Multi-Activity auf Basis von Multi-Clustern gelenkt und zu tiefergehenden Überlegungen zur Dienstverfügbarkeit geführt.
In diesem Artikel werden wir die Disaster Recovery und die multiaktive Praxis von UCS Multi-Cluster anhand des Produktionsanwendungsfalls von Huawei MetaERP ausführlich vorstellen. MetaERP hat komplexe Geschäftsanforderungen, einen großen Serviceumfang und hohe Verfügbarkeitsanforderungen. Die auf UCS basierende Multi-Cluster-Lösung ist zwar mit der ursprünglichen Single-Cluster-Pipeline, den Betriebs- und Wartungstools und den Überwachungsansichten kompatibel, bietet aber nicht nur die ursprüngliche Single-Cluster-Disaster-Recovery-Funktionalität basierend auf Knoten-, AZ- und anderen herkömmlichen Umgebungsfehlern , bietet aber auch eine Notfallwiederherstellung bei Gesamtausfällen des Clusters und bei Softwareausfällen, die nur bei mehreren Clustern auftreten. Das wichtigste Kundenfeedback während der gesamten Produktionspraxis ist, dass die durch die Multi-Cluster-Lösung eingeführte graue Cluster-Umgebung das Problem der lokalen Upgrade-Risiken eines einzelnen Clusters löst und die Serviceverfügbarkeit umfassend verbessert.
technischer Hintergrund
Mit der Popularisierung und Anwendung von Cloud-nativer Technologie mit Kubernetes als Kern laufen immer mehr große Produktionsdienste auf der Kubernetes-Plattform. Es bietet eine bequeme Erweiterung und Verkleinerung von Container-Instanzen, extreme Lastelastizität und nahtlose Anwendungsmigration und hilft Benutzern beim Erstellen umfangreicher, cloudnativer Anwendungen mit hohen Skalierbarkeitsanforderungen. Darüber hinaus stellen die von Kubernetes bereitgestellten Anti-Affinitäts-Bereitstellungsfunktionen von Knoten und AZs sicher, dass bestimmte Instanzen zur Bereitstellung von Diensten verfügbar sind, wenn ein einzelner Knoten oder die gesamte AZ ausfällt, was Benutzern objektiv dabei hilft, die Anwendungsverfügbarkeit zu verbessern.
Allerdings haben die jüngsten Fälle verschiedener Ausfälle einzelner Cluster, die zu schwerwiegenden Geschäftsausfällen führten, große Unannehmlichkeiten für Endkunden verursacht. Ein einzelner Kubernetes-Cluster ist in immer mehr Szenarien mit hohen Verfügbarkeitsanforderungen auf ernsthafte Herausforderungen gestoßen. Kubernetes selbst ist eine Softwareplattform. Potenzielle Ausfälle seiner Steuerungsebenen- und Datenebenenkomponenten werden vom Hersteller garantiert, und die Wahrscheinlichkeit des Auftretens ist gering, aber wenn es einmal auftritt, wird es enorme Auswirkungen haben. Insbesondere gab es in der Branche in letzter Zeit viele schwerwiegende Fehlerfälle, bei denen das direkte Upgrade der Kubernetes-Version eines einzelnen Clusters abnormal war, was zur Nichtverfügbarkeit aller im Cluster bereitgestellten Dienste führte und globale Dienstausfälle auslöste.
Der Hauptgrund für dieses Phänomen ist die Existenz eines unendlichen Explosionsradius. Es ist, als würde man alle Eier in einen stabilen Korb legen. Wenn mit dem Korb etwas nicht stimmt, kann kein einziges Ei überleben. Was noch schlimmer ist: Wenn das Unternehmen wächst, wird dieser Korb, der in den Anfängen noch stabil und brauchbar war, mit der Zeit immer mehr abgenutzt, aber dabei werden immer mehr Eier hineingestopft, sodass der Korb kaputt geht. Irgendetwas Du musst dich früher oder später damit auseinandersetzen. Die intuitive und grundlegende Idee zur Lösung dieser Art von Problem besteht darin, den Explosionsradius zu verringern und die Eier in mehrere Körbe zu legen.
Theoretisch ist dieses Prinzip einfach: Erweitern Sie nicht einen einzelnen Cluster vertikal, sondern erweitern Sie die Anzahl der Cluster horizontal. Aber so einfach ist es in der Praxis nicht. Einer der Hauptgründe, warum MetaERP-Benutzer sich in den frühen Tagen für die zentrale Bereitstellung einer großen Anzahl von Diensten in großen Clustern entschieden haben, war die Reduzierung der Betriebs- und Wartungskosten der Plattform. Der Betrieb und die Wartung eines einzelnen Kubernetes-Clusters haben viel Zeit in Anspruch genommen Energie vom Team. Theoretisch führen mehrere Kubernetes-Cluster zu Verwaltungs- und Wartungsproblemen. Die Kosten steigen linear. In der Praxis großer Unternehmensanwendungen, die durch MetaERP dargestellt werden, stehen wir vor mehreren komplexen Problemen: Wie können wir die Last und die Bereitstellung, Aktualisierung und Elastizität mehrerer Ressourcenobjekte über mehrere Cluster hinweg flexibel steuern und wie können wir den eingehenden Datenverkehr mehrerer Cluster verwalten? ; So steuern Sie mehrere Cluster. Interner Datenverkehr des Clusters. Insgesamt geht es darum, wie sich die theoretische Multi-Cluster-Verfügbarkeit in einen echten Mehrwert für Kunden umwandeln lässt. Das Wichtigste ist, dass die Prämisse von MetaERP für die oben genannten Funktionen darin besteht, dass die Multi-Cluster-Fähigkeit mit der ursprünglichen Single-Cluster-Nutzung kompatibel ist, einschließlich der ursprünglichen Single-Cluster-Befehlszeilentools, CICD-Pipelines, von Erweiterungskomponenten aufgerufenen Cluster-APIs usw ., bleiben so unverändert wie möglich. Gleichzeitig bleibt eine einheitliche Ressourcenverwaltungsansicht, Überwachungs-, Betriebs- und Wartungsansicht für anwendungsorientierte Multicluster usw. erhalten. Die Multi-Cluster-Lösung von UCS beantwortet die oben genannten Fragen nacheinander.
planen
Fehlerbeseitigung in herkömmlichen Umgebungen wie Knoten und AZs
Erstens ermöglicht das integrierte Karmada-Multi-Cluster-Ressourcenmanagement von UCS Benutzern die dynamische Verteilung von Arbeitslasten auf mehrere flottenverwaltete Cluster basierend auf Richtlinien. Die von jedem Cluster verwalteten Knoten stammen aus verschiedenen Availability Zones (AZ), sodass jede Instanz der Last intelligent auf verschiedene Availability Zones verteilt wird und so eine hohe Verfügbarkeit über alle Availability Zones hinweg erreicht wird.
Wenn ein Knoten ausfällt, fallen die Ladeinstanzen auf diesem Knoten vollständig aus. Zu diesem Zeitpunkt wird der auf den Dienst zugreifende Datenverkehr nicht nur auf die entsprechenden Kopien anderer Knoten im Cluster umverteilt, sondern auch auf die entsprechenden Kopien in anderen Clustern, wodurch die Gesamtverfügbarkeit des Dienstes sichergestellt wird.
Wenn eine AZ ausfällt, fallen alle Knoten im Bereich aus, was dazu führt, dass Ladeinstanzen nicht mehr verfügbar sind. Der Datenverkehr wird automatisch auf andere Cluster übertragen, also auf entsprechende Replikate in anderen AZs, und das Geschäft des Benutzers wird dadurch überhaupt nicht beeinträchtigt.
Durch die obige Analyse deckt die UCS-Multi-Cluster-Lösung die vom ursprünglichen Einzelcluster von MetaERP bereitgestellte Serviceverfügbarkeit auf AZ-Ebene und Knotenebene ab und fügt außerdem Funktionen hinzu, die ein einzelner Cluster nicht benötigt, um die Geschäftsverfügbarkeit umfassend zu verbessern.
Wiederherstellung nach Cluster-Softwarefehlern
Neben Ausfällen in der Umgebung besteht eine weitere potenzielle Auswirkung auf das Unternehmen im Ausfall der Cluster-Software selbst. Obwohl die Wahrscheinlichkeit solcher Ausfälle gering ist, werden sie, sobald sie auftreten, große Auswirkungen auf das Unternehmen haben. In Kundenanwendungen kam es zu Problemen wie einer Kube-Apiserver-Überlastung, die zu einem Clusterausfall führte, Anomalien auf der Datenebene des Clusters, die zu einem Ladefehler bei der normalen Erstellung führten, und anderen Problemen. In einer Single-Cluster-Umgebung, die auf herkömmlichen Fehlererkennungs- und Switching-Mechanismen basiert, sind die effektiven Mittel, die die Plattform und das Unternehmen nutzen können, sehr begrenzt.
Basierend auf der UCS-Multi-Cluster-Lösung kann Karmada bei Erkennung eines Cluster-Ausfalls den Datenverkehr, der auf den ausgefallenen Cluster abzielt, dynamisch auf das Service-Backend eines anderen verfügbaren Clusters umleiten. Gleichzeitig können Lastinstanzen entsprechend der Richtlinienkonfiguration dynamisch vom ausgefallenen Cluster auf andere verfügbare Cluster migriert werden. Darüber hinaus unterstützt es Benutzer dabei, das Unternehmen auf der Grundlage ihrer eigenen Einschätzung zu beurteilen. Im Notfall, wenn festgestellt wird, dass ein Cluster fehlerhaft ist, kann der Administrator die gesamte Last eines Clusters isolieren, um Fehler schnell und effizient zu isolieren und die Gesamtverfügbarkeit des Unternehmens zu maximieren .
Fehlerbehebung bei Cluster-Upgrade-Fehlern
In der Praxis bringt die UCS-Multi-Cluster-Lösung den größten Nutzen für das MetaERP-Geschäft, indem sie den Cluster-Upgrade-Prozess sicherstellt. Bei Unternehmens-Upgrades ist es üblich, verschiedene Graustufen-Upgrade-Strategien einzuführen. Bei der Aktualisierung von Cluster-Plattformen ist es jedoch recht schwierig, diesen Graustufen-Mechanismus anzuwenden. Wenn die zu aktualisierende Clusterversion Probleme aufweist oder nicht mit vorhandenen Diensten kompatibel ist, sind möglicherweise vorhandene Dienste von dem Upgrade betroffen. Beispielsweise können sich eine Nichtübereinstimmung des Cluster-Upgrade-Master-Zertifikats, Änderungen im Container-Dateisystem, die sich auf die Ladereihenfolge von Jar-Paketen auswirken und Ausnahmen beim Anwendungsstart verursachen, oder ungeeignete Upgrade-Pfade für die Live-Netzwerk-Clusterversion, die dazu führen, dass der Cluster nicht normal gestartet werden kann, usw. beeinträchtigen Geschäft des gesamten Clusters.
Über die UCS-Multi-Cluster-Lösung können Benutzer einen Cluster als unabhängige Graustufenumgebung für das Upgrade auswählen und dann einen anderen Cluster aktualisieren, nachdem die endgültige Geschäftsabnahme bestätigt, dass das Upgrade erfolgreich ist. Diese Methode vermeidet die Situation, in der alle Dienste aufgrund eines Cluster-Upgrade-Fehlers in einem einzelnen Cluster-Szenario nicht verfügbar sind.
Im Folgenden finden Sie detaillierte Schritte:
1. Führen Sie Cluster-Upgrades innerhalb des Zeitfensters mit geringem Geschäftsvolumen durch. Wählen Sie zunächst einen Cluster aus, der als Graustufenumgebung aktualisiert werden soll, und konfigurieren Sie Regeln, um den gesamten Datenverkehr auf einen anderen Cluster umzuleiten.
2. Aktualisieren Sie die Plattformkomponenten des Graustufenclusters und beobachten Sie den normalen Betrieb jeder Komponente.
3. Beobachten Sie den Betrieb der Last im Graustufen-Cluster, um sicherzustellen, dass die Last mit der Graustufen-Cluster-Umgebung übereinstimmt und normal funktioniert.
4. Leiten Sie eine kleine Menge Datenverkehr auf den Graustufencluster um, führen Sie eine Graustufenfreigabe eines Teils der Last durch und beobachten Sie den Betriebsstatus des Dienstes aus der endgültigen Geschäftsperspektive. Wenn bestätigt wird, dass der Graustufen-Cluster basierend auf dem Unternehmen normal läuft, wird der gesamte Datenverkehr nach und nach auf den Graustufen-Cluster umgeschaltet.
5. Führen Sie den Graustufen-Upgrade-Prozess auf einem anderen Cluster durch und stellen Sie sicher, dass jeder Cluster ähnlichen Tests und Validierungen unterzogen wird.
Wenn im zweiten bis vierten Schritt oben ein Problem auftritt, kann der Graustufencluster sofort repariert werden, ohne den Endbenutzerzugriff zu beeinträchtigen. Durch diese Cluster-Graustufen-Upgrade-Methode wird sichergestellt, dass Probleme, die während des Upgrade-Prozesses auftreten, keine Auswirkungen auf die Benutzerdienste haben.
Einheitliche multiaktive Richtlinie für eingehenden und internen Datenverkehr
Im Gegensatz zu herkömmlichen Disaster Recovery- und Aktiv-Aktiv-Szenarien, die nur auf der Kontrolle des eingehenden Datenverkehrs basieren, ist UCS in ein Hochleistungs-Service-Grid integriert und kann konsistente Datenverkehrsaktionen innerhalb der Anwendung durchführen. In einem Disaster-Recovery-Szenario erfolgt die Umschaltung auf Grundlage einer einheitlichen Verkehrsrichtlinie über den Grid-Proxy und das Ingress-Gateway. Für denselben Zieldienst können abnormale Instanzen gemäß einheitlichen Richtlinien isoliert werden, unabhängig davon, ob der Datenverkehr vom internen Dienstzugriff oder vom externen Zugriff stammt, um eine hohe Verfügbarkeit des Dienstes sicherzustellen.
Die Datenverkehrsmigration begleitet die Anwendungsmigration mit mehreren Funktionen
Bei vielen Disaster-Recovery-Lösungen scheint die bloße Umschaltung des Datenverkehrs das Hauptproblem zu lösen, doch in Wirklichkeit gibt es immer noch Unzulänglichkeiten. Im oben genannten Szenario kann nach der Isolierung des Datenverkehrs von einer Cluster-Instanz, die als fehlerhaft markiert ist, die Anzahl der Backends, die tatsächlich Dienste bereitstellen, geringer sein als die ursprünglich vom Benutzer erwartete Anzahl, was objektiv zu einer Beeinträchtigung der Gesamtkapazität des Dienstes führt Dies entspricht offensichtlich nicht den geschäftlichen Anforderungen von MetaERP an eine hohe Verfügbarkeit. Die von UCS bereitgestellte Multi-Cluster-Fehlermigrationslösung beschränkt sich nicht nur auf die Verkehrsvermittlung, sondern kombiniert auch Cluster-übergreifende Lastmigration und Datenmigration basierend auf tatsächlichen Benutzerszenarien, um einen dreidimensionalen Fehlerreaktionsmechanismus aufzubauen. Das heißt, zusätzlich zur Gewährleistung der Geschäftskontinuität durch Verkehrsumschaltung wird das Lastmanagement in mehreren Clustern auch dazu verwendet, Lasten in abnormalen Clustern auf andere Cluster zu migrieren, um sicherzustellen, dass immer eine ausreichende Anzahl von Lastinstanzen vorhanden ist, um den Benutzern Dienste bereitzustellen. Verfügbarkeit von Diensten. Diese Methode, die Verkehrsmigration und Lastmigration kombiniert, stellt die Verfügbarkeit von Benutzerdiensten sicher und stellt sicher, dass die Gesamtdienstqualität den Benutzererwartungen entspricht.
Konsistentes Erlebnis in einem einzigen Cluster, vereinfachter Betrieb und Wartung
In der UCS-Multi-Cluster-Disaster-Recovery-Lösung wird das Fehlermanagement auf Cluster-Granularität durchgeführt. Im Gegensatz zur Einzel-Cluster-Lösung, die Fehlererkennung und -isolierung nur auf Instanz-, Knoten- oder AZ-Granularität durchführen kann, kann der gesamte Cluster schnell isoliert werden Erzielen Sie eine schnelle Fehlerisolierung und verbessern Sie so die Anwendungszuverlässigkeit. Verfügbarkeit. Die Bereitstellung dieser Funktionen erhöht jedoch nicht die Verwaltungs-, Betriebs- und Wartungskomplexität des Benutzers. Die UCS-Multi-Cluster-Flotte bietet APIs und Objektmodelle, die vollständig mit einzelnen Clustern kompatibel sind, sodass die ursprünglichen Tools der Single-Cluster-Betriebs- und Wartungsplattform nahtlos verbunden werden können. Die ursprüngliche Pipeline von MetaERP kann ohne große Änderungen mit der Flotten-API verbunden werden, um die Erstellung und Aktualisierung von Kubernetes-Ressourcen wie Cluster-Bereitstellungen, Service, Secret, ConfigMap, Role und RoleBinding zu realisieren.
Gleichzeitig basiert UCS auf Karmadas Multi-Cluster-Ressourcenmanagementfunktionen und verteilt Ressourcen auf Flottenebene gemäß benutzerkonfigurierten Richtlinien auf mehrere flottenverwaltete Cluster. Das Betriebs- und Wartungspersonal von MetaERP kann das ursprüngliche Kubernetes-Befehlszeilentool verwenden, um ein einheitliches Betriebs- und Wartungsmanagement der Ressourcen in der Flotte durchzuführen, was im Wesentlichen dem Single-Cluster-Erlebnis entspricht. Darüber hinaus stimmt die anwendungsorientierte Überwachungsansicht auf Flottenebene auch mit der Geschäftsüberwachung innerhalb eines einzelnen Clusters überein.
Die Einführung mehrerer Cluster durchbricht nicht nur die Kapazitätsbeschränkungen eines einzelnen Clusters, sondern erhöht auch die Gesamtkapazität der Plattform erheblich und erfüllt so den großen Wachstumsbedarf des MetaERP-Geschäfts.
Zusammenfassen
Die auf UCS basierende Multi-Cluster-Lösung von MetaERP deckt nicht nur den Umgang mit Ressourcen- und Umgebungsfehlern in herkömmlichen Disaster-Recovery-Szenarien ab, sondern umfasst auch die Fähigkeit, mit der Plattform selbst, Softwarefehlern und Plattform-Upgrade-Prozessen umzugehen, wodurch die Gesamtverfügbarkeit des Unternehmens erheblich verbessert wird . Diese Lösung ist nicht auf die Bereitstellungsmethode mehrerer AZs in derselben Region in der Cloud beschränkt, sondern kann auch flexibel auf regionsübergreifende Umgebungen, Multi-Cloud-Umgebungen und Hybrid-Cloud-Umgebungen angewendet werden. Durch die Bereitstellung auf Basis einer verteilten Umgebung können die Last und der Datenverkehr mehrerer Cluster effektiv verwaltet, eine Notfallwiederherstellung und Multiaktivität in einer verteilten Cloud-Umgebung erreicht und die Verfügbarkeit von Benutzerdiensten weiter verbessert werden.
Die hier vorgestellten Multi-Cluster-Fähigkeiten sind nur ein Teil der Funktionen verteilter Cloud-nativer UCS-Produkte. Die verteilte Cloud bietet Benutzern die Flexibilität, Cloud-Funktionen je nach Szenario auf verschiedene physische Standorte zu verteilen. Gleichzeitig vereinfacht sie die Benutzernutzung durch einheitliche Verwaltung sowie Betrieb und Wartung in der Cloud. Als branchenweit erstes verteiltes Cloud-Produkt nutzt das verteilte cloudnative UCS von Huawei Cloud cloudnative Methoden, um die Hardware, Software, Infrastruktur und Dienste des Herstellers an Benutzerrechenzentren, Edges, andere Clouds und andere Standorte zu verteilen, um den Benutzeranforderungen gerecht zu werden. Anforderungen für Anwendungsszenarien wie niedrige Latenz, lokale Datenverarbeitung, Datenresidenz-Compliance oder Disaster Recovery und Multiaktivität. Basierend auf der hochverfügbaren verteilten Multi-Cloud- und Multi-Cluster-Anwendungsverwaltung bauen wir globalen einheitlichen dynamischen Datenverkehr, Anwendungskonfiguration, Zero-Trust-Sicherheit, DevOps, Anwendungsbetrieb und -wartung sowie andere Funktionen auf der Multi-Cluster-Flotte auf, um den Anforderungen gerecht zu werden von Großunternehmensnutzern wie MetaERP Wachsende Nachfrage nach Anwendungsmodernisierung.
Gleichzeitig entwickelt sich Karmada, die Kernkomponente der UCS-Multi-Cluster-Lösung, bei der Bereitstellung verteilter Cloud-nativer Kundenszenarien weiter und wurde diesen Monat offiziell zu einem CNCF-Inkubationsprojekt befördert. Zukünftig wird Karmada weiterhin technologische Innovationen im Bereich Cloud-nativer Multi-Cluster erforschen, damit auf Karmada basierende Multi-Cloud-Lösungen tiefer in das Cloud-native-Technologie-Ökosystem integriert werden können.
UCS wird auch in Zukunft die Entwicklung von Multi-Cloud-Container-Plattformen anführen und Benutzern dabei helfen, eine effizientere und intelligentere Cloud-native Anwendungsbereitstellung und -verwaltung zu erreichen.
Referenz:
- „Forrester Wave™: Multicloud Container Platforms, Q4 2023“ veröffentlicht: https://www.huaweicloud.com/news/2023/20231226154355792.html
- Bewertung der verteilten Cloud-nativen Fähigkeiten der China Academy of Information and Communications Technology: https://mp.weixin.qq.com/s/ba7kIS8C4p-Ue3L3DgwWtA
- Karmada wurde zum CNCF-Inkubator-Projekt befördert: https://www.cncf.io/blog/2023/12/12/karmada-brings-kubernetes-multi-cloud-capabilities-to-cncf-incubator/
Broadcom kündigte die Beendigung des bestehenden VMware-Partnerprogramms an . Site B stürzte zweimal ab, Tencents „3.29“-Vorfall der Stufe eins … Bestandsaufnahme der zehn häufigsten Ausfallvorfälle im Jahr 2023, Vue 3.4 „Slam Dunk“ veröffentlicht, Yakult bestätigte, dass 95G-Daten durchgesickert sind MySQL 5.7, Moqu, Li Tiaotiao... Bestandsaufnahme der (Open-Source-)Projekte und Websites, die 2023 „gestoppt“ werden „2023 China Open Source Developer Report“ wird offiziell veröffentlicht Rückblick auf die IDE vor 30 Jahren: nur TUI, helle Hintergrundfarbe …… Julia 1.10 offiziell veröffentlicht Rust 1.75.0 veröffentlicht NVIDIA hat GeForce RTX 4090 D speziell für den Verkauf in China auf den Markt gebracht