Dieser Artikel stammt aus der Huawei Cloud Community „ Practice of Controlling Fault Explosion Radius in Logical Multi-Tenancy Scenario “ von Wang Fuqiang und Chen Zidong.
Hintergrund
Ein bestimmtes System ist eine von Huawei entwickelte Toolplattform, die in der öffentlichen Cloud bereitgestellt werden kann und Dienste für mehrere Projekte und Kunden auf der ganzen Welt bereitstellt. Um die Anforderungen an die Einhaltung der Datensicherheit zu erfüllen, die Benutzerkosten so weit wie möglich zu senken und die Betriebs- und Wartungseffizienz zu verbessern, wird insgesamt ein hybrides Multi-Tenant-Design übernommen. Die Logikschicht identifiziert verschiedene Mandanten anhand von IDs, um die Auslagerung von Anforderungen zu implementieren. Entwickler Jeder Mieter kann innerhalb des Mieters unabhängige APPs entwickeln, z. B. Web- oder Terminalseiten, Datenmodelle, Dienste, Schnittstellen usw.
Da sich im täglichen Betrieb mehrere Mandanten die gleichen Plattformressourcen teilen und die Leistung der APP jedes Mandanten stark variiert, kommt es von Zeit zu Zeit zu Ausfällen auf Plattformebene, die durch Überlastung einzelner Mandanten, Endlosschleifen von Anwendungen usw. verursacht werden. Diese sind jedoch ungewiss Anwendungsszenarien werden relativ über die zugrunde liegenden Rechenressourcen und Plattformdienste hinaus getragen und bringen erhebliche Herausforderungen für die Gesamtstabilität des Systems mit sich.
(Hinweis: Die Fehler in diesem Artikel beziehen sich speziell auf Plattformfehler, die durch eine Ausnahme in der selbst entwickelten APP eines einzelnen Mandanten in einem logischen Mehrmandantenszenario verursacht werden, ausgenommen Fehler, die durch Fehler in der Plattformsoftware verursacht werden.)
Einführung in die Multi-Tenant-Architektur
Das System verwendet eine hybride Multi-Tenant-Architektur und einen gemeinsamen Modus für öffentliche Dienste (wie Anmeldeauthentifizierung usw.), wobei alle Benutzer denselben Cluster teilen; für Geschäftslogik-Verarbeitungseinheiten werden Ressourcen nach Bedarf entsprechend den Anforderungen des Mandanten zugewiesen Ebene und Skalierung (physische Mandantenfähigkeit) oder gemeinsam genutzt (logische Mandantenfähigkeit).
Physische Mandantenfähigkeit: Der Service-Cluster ist exklusiv für einen einzelnen Mandanten, wird auf unabhängigen Cloud-Service-Ressourcen bereitgestellt und Fehler zwischen Mandanten werden vollständig isoliert.
Logische Mandantenfähigkeit: Gemeinsam genutzte Service-Cluster können Anfragen von mehreren Mandanten verarbeiten. Wenn die Leistung nicht ausreicht, kann die Leistung durch Hinzufügen von Instanzen innerhalb des Stapels verbessert werden. Mehrere Instanzen bieten externe Lastverteilungsfunktionen.
Wie in der folgenden Abbildung dargestellt, sind Mandant A und Mandant B als logischer Multi-Tenant konfiguriert, und Mandant C ist als physischer Multi-Tenant konfiguriert.
Diagramm der mandantenfähigen Systemarchitektur
Analyse typischer Probleme eines zu großen Fehlerexplosionsradius
Für die logische Mehrmandantenfähigkeit verfügen Mieter über bestimmte Ressourcenisolationsfunktionen, es treten jedoch immer noch Probleme mit der Ressourcenvermeidung auf, wie z. B. das typische Problem eines übermäßigen Fehlerexplosionsradius. Unter der logischen Mehrmandantenarchitektur können Ressourcen nicht vollständig isoliert werden. Und weil die Qualität von Von Mandanten intern entwickelte APPs variieren, z. B. langsames SQL, langsame Dienste oder Endlosschleifen von JS-Code, zyklische Aufrufe zwischen APP-internen Diensten usw., wenn diese Probleme dazu führen, dass eine APP-Dienstanforderung eines bestimmten Mandanten abnormal ist, wenn nicht Kontrolle kann sich der Explosionsradius allmählich von einem einzelnen Funktionsausfall zu einem Ausfall eines gesamten Mieters oder sogar zu einem Ausfall einer gesamten Plattform ausdehnen. Typische Fehlerszenarien sind wie folgt:
1. Ein einzelner JS beansprucht zu viel CPU und Speicher, was zum Absturz der gesamten JVM führt und sich auf den gesamten Service-Cluster auswirkt.
Einzelnes JS beansprucht zu viel CPU und Speicher
2. Der Service-Loop-Aufruf oder die Aufrufkette ist zu tief und eine einzelne Anfrage belegt zu viele Systemressourcen, was dazu führt, dass für andere Dienste keine Ressourcen verfügbar sind und die Anfrage fehlschlägt.
Der Service-Loop-Aufruf oder die Anrufkette ist zu tief
3. Eine einzelne Mandantenanfrage belegt zu viele Verbindungspools/Threadpools im System, was dazu führt, dass für andere Mandanten keine Ressourcen verfügbar sind und die Anfrage fehlschlägt.
Eine einzelne Mandantenanforderung belegt zu viele Systemverbindungspools/Threadpools
Anhand der oben genannten Fehlerszenarien können wir feststellen, dass in der APP-Betriebslogik jedes Mandanten auf der Plattform große Unsicherheit besteht, sodass es schwierig ist, alle Probleme durch ein paar Einzelmaßnahmen zu lösen. Daher ist es für logische SaaS-Szenarien mit mehreren Mandanten erforderlich, eine systematische und hochzuverlässige Lösung bereitzustellen, um das Risiko einer Explosionsradiuserweiterung in anormalen APP-Szenarien mit einem Mandanten zu bewältigen.
Praxis der hierarchischen Kontrolle des Fehlerexplosionsradius
Um die oben genannten typischen Fehlerszenarien zu bewältigen, haben wir eine hierarchische Fehlerisolationslösung eingeführt, die Ressourcenkontingente und Strombegrenzungen innerhalb der Instanz, Ressourcenisolation auf APP-Ebene und Ressourcenisolation auf Mandantenebene durch angemessene Planung isolierter Ressourcen umfasst im Voraus und schnelle Planung isolierter Ressourcen während des Ereignisses. , Optimieren Sie die Isolationsstrategie anschließend, um den Fehlerexplosionsradius unterhalb der Plattformebene zu kontrollieren. Instanzinterne Ressourcenkontingent- und Strombegrenzungslösung Basierend auf historischen Fehlererfahrungen können instanzinterne Ressourcenkontingent- und Strombegrenzungslösung durch 3 Schlüsselfunktionen + 4 Kontrollpunkte erreicht werden:
3 Hauptfunktionen: einschließlich der Kontrolle des Rechenressourcenverbrauchs durch JS innerhalb eines einzelnen Dienstes, der Kontrolle der Anzahl gleichzeitiger Anforderungen in einem einzelnen Mandanten und der Kontrolle der Ausführungsleistung einzelner Transaktionen innerhalb eines Mandanten.
4 Kontrollpunkte: Aus Sicht des Geschäftsflusses von Ressourcenaufrufen gibt es 4 wichtige Kontrollpunkte für Ressourcenkontingente und aktuelle Grenzwerte. Dies sind der Browser, der den Server aufruft, die Ausführung der JS-Engine innerhalb des Servers, der Server, der die Datenbank aufruft usw dienstübergreifende Anrufe. .
Passen Sie basierend auf den oben genannten Schlüsselkontrollpunkten die folgenden Schlüsselfunktionen an, um den von der Schnittstelle angeforderten Datenverkehr und die Ressourcen zu steuern und letztendlich den Fehlerexplosionsradius eines bestimmten Leistungsüberlastungsszenarios innerhalb der Instanz zu steuern:
Umsetzungspraxis:
» Entwerfen Sie basierend auf den Produktfunktionen die Ober- und Untergrenzen der Ressourcengrenzen innerhalb der Instanz.
» Legen Sie angemessene Grenzwerte basierend auf der Testumgebung und den Live-Netzwerkbetriebsdaten fest.
» Verfolgen und analysieren Sie Grenzwert- und Stromgrenzwertergebnisse und optimieren Sie kontinuierlich Grenzwertparameter.
Ressourcenisolation auf APP-Ebene
Ein einzelner Mandant enthält mehrere Apps. Jede App verfügt über eine eigene unabhängige Seite, einen eigenen Dienst und ein eigenes Modell. Da jedoch alle Apps einen Satz laufender Engines gemeinsam nutzen, führen wir die App-Isolationsfunktion ein, um verschiedene Sätze laufender Engines für verschiedene Apps anzugeben. Gruppen zu Reduzieren Sie die Auswirkungen von App-Fehlern.
Schlüsselkompetenzen:
» Dienstressourcen werden basierend auf der Gruppe gruppiert, und der Dienststapel gibt bei der Installation und Bereitstellung Gruppeninformationen an.
» Routing-Richtlinien werden von SRE verwaltet und bereitgestellt und schließlich im Konfigurationscenter gespeichert, damit sie von LB- und CSE-Clients geladen werden können.
» DMZ-LB ist für das Front-End-Anfragerouting verantwortlich und generiert eine spezifische Nginx-Konfiguration gemäß der Routing-Richtlinie und den Standortinformationen jedes Dienstes.
» Der CSE-Client ist für die Weiterleitung von Backend-Anfragen, die Filterung und Identifizierung von Zieldienstinstanzen basierend auf Routing-Richtlinien verantwortlich.
Umsetzungspraxis:
» Planen Sie APP-Isolierungsressourcenpools ordnungsgemäß auf der Grundlage von Geschäftsmerkmalen, z. B. Isolieren von Plattform-APPs und benutzerdefinierten APPs oder Isolieren von APPs für Unternehmen A und Unternehmen B.
» Überwachen Sie die Leistung isolierter Ressourcenpools, optimieren Sie Spezifikationen und Parameter und stellen Sie eine angemessene Ressourcenzuteilung sicher.
» Identifizieren Sie kontinuierlich die ressourcenintensivsten APPs und optimieren Sie die Anzahl der Ressourcenpools und die APP-Verteilung. Ressourcenisolation auf Mandantenebene In einem logischen Szenario mit mehreren Mandanten zielen verschiedene Mandanten auf unterschiedliche Unternehmen ab, und jedes Unternehmen hat unterschiedliche Toleranzen für Zuverlässigkeit, Leistung und Änderungen. Bei der logischen Mandantenfähigkeit wird nur die Wiederverwendung von Ressourcen berücksichtigt, um die Kosten zu senken, und die Intermanenz kann nicht vollständig garantiert werden -Mandantenausfälle. Isolation, daher muss das Unternehmen auch hybride Mandantenfähigkeitsfunktionen unterstützen und verschiedene Mandanten in verschiedene Ressourcengruppen klassifizieren, um eine Fehlerisolierung zwischen verschiedenen Mandanten zu erreichen.
Schlüsselkompetenzen:
Die Mandantenisolation und die APP-Isolation verwenden dasselbe Funktionsframework. Der Unterschied besteht darin, dass die APP-Isolation verschiedene APPs in einem einzelnen Mandanten in mehrere Plattformressourcenpools einfügt, während die Mandantenisolation unterschiedliche Mandanten in mehrere Plattformressourcenpools einfügt.
Umsetzungspraxis:
» Planen und weisen Sie Ressourcenpools ordnungsgemäß auf der Grundlage von Mieterunterschieden zu, z. B. der ausschließlichen Nutzung durch Mieter mit hohem kommerziellem Wert und der gemeinsamen Nutzung durch normale Mieter. Richten Sie gleichzeitig Beobachtungsressourcenpools für die vorübergehende Isolierung von Mietern mit schlechterem Nutzungsrecht ein.
» Überwachen Sie die Leistung von Ressourcenpools, optimieren Sie die Zuordnungsbeziehung zu Mandanten und stellen Sie eine angemessene Ressourcenzuteilung sicher.
» Isolieren Sie Mandanten, die eine Verschlechterung der Ressourcenpoolleistung verursachen, weisen Sie sie vorübergehend dem Beobachtungsressourcenpool zu und weisen Sie den Ressourcenpool nach Abschluss der Leistungsoptimierung neu zu.
Zusammenfassen
Die gemeinsame Nutzung von Ressourcen durch logische Mehrmandantenfähigkeit ist eine gängige und effektive Möglichkeit, die Einzelmietkosten von Cloud-Diensten zu senken. Im Vergleich zur physischen Mehrmandantenfähigkeit birgt sie jedoch auch das Risiko eines unkontrollierbaren Explosionsradius. Daher ist es notwendig, den Ressourcenverbrauch einzelner Mandanten innerhalb einer bestimmten Grenze zu kontrollieren, um den Fehlerexplosionsradius effektiv zu kontrollieren. Dieser Artikel analysiert typische Fehlerszenarien einer Architektur mit mehreren Mandanten, schlägt ein hierarchisches Isolationsschema zur Behandlung von Fehlern vor, steuert den Betriebsressourcenverbrauch eines einzelnen Mandanten innerhalb einer bestimmten Grenze und verwendet einen deterministischen Fehlerisolationsmechanismus zur Behandlung unsicherer Fehlerszenarien Der Fehlerexplosionsradius der Kontrolle reduziert das Auftreten von Fehlern auf Plattformebene und erreicht die optimale Lösung zwischen Kosten und Verfügbarkeit.
Der Autor eines bekannten Open-Source-Projekts verlor seinen Job aufgrund von Manie – „Suche nach Geld online“ No Star, No Fix 2023 Die zehn besten technischen Errungenschaften der Welt werden veröffentlicht: ChatGPT, Hongmeng Operating System, China Space Station und andere ausgewählte ByteDance wurden von OpenAI „verboten“. Google kündigt die beliebteste Chrome-Erweiterung im Jahr 2023 an Akademiker Ni Guangnan: Ich hoffe, dass inländische SSD importierte HDD ersetzen wird, um Xiaomi-Mobiltelefon BL zu entsperren? Stellen Sie zunächst eine Interviewfrage für Java-Programmierer. Arm hat mehr als 70 chinesische Ingenieure entlassen und plant, sein chinesisches Softwaregeschäft neu zu organisieren. OpenKylin 2.0 enthüllt | UKUI 4.10 Doppeldiamantendesign, schön und hochwertig! Manjaro 23.1 veröffentlicht, Codename „Vulcan“