Hinweis: Nachfolgend finden Sie eine Beschreibung der allgemeinen Ausrichtung unserer Produkte. Er dient nur zu Informationszwecken und darf nicht in einen Vertrag aufgenommen werden. Es ist keine Verpflichtung, Material, Code oder Funktionen bereitzustellen, und sollte bei Kaufentscheidungen nicht als verlässlich angesehen werden. Entwicklung, Freigabe, Preisgestaltung und Zeitpunkt der Herausgabe der beschriebenen Funktionen oder Funktionalität von Oracle Produkten liegen im alleinigen Ermessen von Oracle.

Diese häufig gestellten Fragen beantworten häufig gestellte Fragen dazu, wie Oracle Resilienz und kontinuierliche Verfügbarkeit unserer zentralen Infrastrukturservices und Hosting-Plattform erreicht. Diese Antworten können aus mehreren Gründen für Kunden von Oracle Cloud von Interesse sein:

  • Kunden können bei der Bewertung der Oracle-Hostingplattform und -Services Due Diligence anwenden.
  • Viele der Antworten behandeln Herausforderungen und Lösungen, die für alle Cloud-Scale-Systeme von grundlegender Bedeutung sind, und können daher die Architektur und das Design von Systemen beeinflussen, die Kunden in der Cloud erstellen möchten.

Resilienz und kontinuierliche Verfügbarkeit von Oracle Cloud Infrastructure Services und Platform – Häufig gestellte Fragen (FAQ)

Alle öffnen Alle schließen
  • Unterscheidet Oracle verschiedene Serviceklassen, z. B. kritische Services, kontinuierlich verfügbare Services oder Single-Location-Services?

    Solche Unterscheidungen machen wir nicht. Stattdessen werden die Services nach Abhängigkeitsebene, Verfügbarkeitsbereich und Data Plane bzw. Control Plane kategorisiert. Diese Kategorien sollen verschiedene nützliche Kombinationen aus Verfügbarkeit, Dauerhaftigkeit, Performance und Benutzerfreundlichkeit bereitstellen.

    Abhängigkeitsebenen

    Diese Ebenen können als Layer oder Tiers in einem Architekturblockdiagramm betrachtet werden. Jeder Layer kann nur von den Layern darunter abhängig sein.

    Von unten nach oben:

    • Kernservices: Diese Services basieren auf Oracle Cloud Infrastructure. Sie umfassen Identity and Access Management (IAM), Key Management, Networking, Compute, Block Volumes, Object Storage, Telemetry und mehrere gemeinsame interne Services. Sie sind für Mindestabhängigkeiten vorgesehen, sogar untereinander. (Details zu Abhängigkeiten finden Sie weiter unten in diesem Dokument).
    • IaaS: Dieser Layer bietet weitere Funktionen auf Infrastruktur-Ebene, die auf dem Core basieren. Services in diesem Layer umfassen File Storage, Database und Container Engine for Kubernetes.
    • SaaS: Bei dieser Schicht handelt es sich um umfassende Software-as-a-Service, die auf den unteren Layern aufbaut.

    Verfügbarkeitsbereich

    Um die Ziele der Verfügbarkeit und Dauerhaftigkeit für einen Service zu erreichen, wird einer der folgenden Verfügbarkeitsbereiche für jeden Service ausgewählt:

    • Lokale Availability-Domain: Jede Availability-Domain enthält eine unabhängige Instanz des Services. Diese Services bieten eine hohe Dauerhaftigkeit gespeicherter Daten, indem sie die synchrone Replikation zwischen Replikaten innerhalb derselben Availability-Domain verwenden (Einzelheiten finden Sie im Abschnitt zu Faultdomains weiter unten in diesem Dokument). Diese Services können je nach Art des Services einen Ausfall von einem Drittel oder mehr der Infrastruktur in der Availability-Domain tolerieren. Lokale Services der Availability-Domain erreichen dieses Maß an Fehlertoleranz, indem sie zwei verschiedene Arten von logischen Data Centern – logische Gruppen zur Fehlerisolation und Leistungsisolation – innerhalb der Availability-Domain verwenden. Einzelheiten finden Sie weiter unten in diesem Dokument in den Abschnitten zu Faultdomains und Servicezellen. Diese Services funktionieren auch dann weiterhin normal, wenn die Availability-Domain mit keinen anderen Availability-Domains kommunizieren kann. Das hat zur Folge, dass Sie den Verlust anderer Availability-Domains oder den Totalausfall des WAN in der Region tolerieren.
    • Regional mit mehreren Availability-Domains: Jede Region mit mehreren Availability-Domains enthält eine unabhängige Instanz des Services, wobei sich die Komponenten in jeder Availability-Domain in dieser Region befinden. Diese Services bieten eine sehr hohe Dauerhaftigkeit gespeicherter Daten dank synchroner Replikation in mehreren Availability-Domains in derselben Region. Einen Ausfall oder die Unfähigkeit, mit einer einzelnen Availability-Domain in der Region zu kommunizieren, können diese Services tolerieren.
    • Einzelne Availability-Domain regional: Wenn eine Region nur eine einzige Availability-Domain enthält, stimmen die beobachtbaren Eigenschaften eines regionalen Services mit denen eines lokalen Availability-Domain-Services überein, wie zuvor beschrieben. Die Unterscheidung zwischen einem lokalen Service einer Availability-Domain und einem regionalen Service einer einzelnen Availability-Domain wird nur dann relevant, wenn eine Region mit einer einzelnen Availability-Domain erweitert wird, indem eine oder mehrere Availability-Domains hinzugefügt werden. In diesem Fall wird jeder regionale Service automatisch erweitert, um die neuen Availability-Domains angemessen zu nutzen, während er eine einzelne Instanz des Services bleibt. So würde beispielsweise die Datenebene der Objektspeicher erweitert, um die zusätzlichen Availability-Domains zu nutzen und die Haltbarkeit der vorhandenen Daten zu verbessern. Bei lokalen Services der Availability-Domain hingegen erhält jede der neuen Verfügbarkeitsdomänen ihre eigene neue und separate Instanz jedes lokalen Services der Availability-Domain.
    • Auf Regionen verteilt: Ein grundlegendes Prinzip von Oracle Cloud Infrastructure besteht darin, dass jede Region möglichst operativ unabhängig von anderen Regionen ist. Die Einstufung als möglich spiegelt die Tatsache wider, dass Regionen notwendigerweise zumindest einen Teil der Infrastruktur gemeinsam nutzen müssen, beispielsweise das interregionale Backbone-Netzwerk. Andernfalls bauen wir keine engen Kopplungsmechanismen zwischen Regionen auf, wie transparente High Availability oder Failover, die Probleme verursachen könnten, die mehrere Regionen gleichzeitig betreffen. Stattdessen stellen wir zwei Mechanismen zur regionsübergreifenden Verteilung von Services mit loser Kopplung bereit:
      • Disaster Recovery (DR): Unsere Kunden in die Lage zu versetzen, Systeme mit DR-Eigenschaften zu erstellen, ist ein Eckpfeiler unseres Ansatzes und unserer Investition in die Cloud. Mehrere Coreservices bieten bereits DR-Mechanismen – zum Beispiel das regionsübergreifende Backup von Block Volumes und das regionsübergreifende Kopieren in Object Storage. In der Roadmap für alle unsere Services sind DR-Funktionen von hoher Priorität.
      • Interregionale Abonnements: Derzeit bieten wir regionsübergreifende Abonnements nur für IAM-Daten an. Konzeptionell gesehen haben IAM-Daten einen globalen Geltungsbereich. Kunden können sich für eine Reihe von Regionen anmelden (opt-in), und wir replizieren automatisch die relevanten IAM-Daten und nachfolgende Aktualisierungen für die angegebenen Regionen. Um eine enge Kopplung zu vermeiden, ist die Replikation asynchron und letztendlich konsistent. Kunden nehmen Änderungen an ihren IAM-Daten in einer „Heimat“-Region vor, die sie benennen. Wenn die aktuelle Hauptregion aus bestimmten Gründen nicht verfügbar oder ungeeignet ist, kann eine andere Region nominiert werden.

    Control Plane und Data Plane im Vergleich

    Die Data Plane eines Dienstes ist die Sammlung von Datenverarbeitungsschnittstellen und -komponenten, die die Funktionalität des Services implementieren, die von Anwendungen verwendet werden soll. Beispielsweise umfasst die Datenebene des virtuellen Cloud-Netzwerks (VCN) das Netzwerkpaketverarbeitungssystem, virtualisierte Router und Gateways, während die Datenebene der Block-Volumes die Implementierung des iSCSI-Protokolls und das fehlertolerante replizierte Speichersystem für Volume-Daten umfasst.

    Die Control Plane eines Services ist die Gruppe von APIs und Komponenten, die für die folgenden Aufgaben verantwortlich sind:

    • Bearbeiten von Kundenanforderungen, um Ressourcen bereitzustellen, neu zu konfigurieren, vertikal/horizontal zu skalieren oder zu beenden
    • Schnelle und sichere Durchführung automatischer Patches großer Flotten
    • Erkennen von fehlerhaften, herabgestuften oder falsch konfigurierten Ressourcen
    • Durchführen automatisierter Reparaturen oder Ausrufen menschlicher Bediener zur Unterstützung
    • Zusammenarbeit mit anderen Control Planes (z. B. Compute, VCN, Block Storage werden während LaunchInstance gekoppelt)
    • Verwalten nicht verwendeter Kapazität
    • Abstimmung mit Menschen, z. B. bei Ankunft neuer Geräte und physischer Reparatur & Wartung
    • Bereitstellen betrieblicher Transparenz und Kontrolle
  • Wie gewährleistet Oracle, dass Services stabil und kontinuierlich verfügbar sind?

    Für alle Arten von Services verwenden wir die gleichen technischen Prinzipien, um Ausfallsicherheit und Verfügbarkeit zu erreichen, da die grundlegenden technischen Herausforderungen beim Aufbau fehlertoleranter, skalierbarer, verteilter Systeme für alle Arten von Services gleich sind.

    Um Resilienz und kontinuierliche Verfügbarkeit zu erreichen, ist es notwendig, alle Ursachen der Nichtverfügbarkeit – verminderte Leistung und unbehandelte Ausfälle – in cloudbasierten Systemen zu verstehen und dann zu behandeln. Es gibt eine Vielzahl solcher Ursachen, also teilen wir sie entsprechend ihrer Art in Kategorien ein

    Traditionell wurde zur Bestimmung der Verfügbarkeit von Unternehmens-IT-Systemen in erster Linie die Kategorie Hardwareausfall analysiert. Bei Cloud-Systemen ist ein Hardwareausfall jedoch ein relativ geringfügiges und gut verstandenes Problem. Es ist jetzt relativ einfach, die meisten Hardware-Ausfallstellen zu vermeiden oder zu entschärfen. Beispielsweise können Racks über zwei Stromeinspeisungen und zugehörige Stromverteilungseinheiten verfügen, und viele Komponenten sind Hot-Swap-fähig. Größere Hardwareausfälle und -verluste sind natürlich möglich – zum Beispiel aufgrund von Naturkatastrophen. Unsere Erfahrung und Berichte in öffentlichen Post-Mortems von anderen Cloud-Anbietern zeigen jedoch, dass der Ausfall oder Verlust eines gesamten Data Centers im Vergleich zu den anderen Ursachen der Nichtverfügbarkeit extrem selten vorkommt. Weitreichende Hardwareausfälle müssen weiterhin behandelt werden (z. B. mit Disaster Recovery und anderen Mechanismen), sind aber bei Weitem nicht das häufigste Verfügbarkeitsproblem.

    Die Hauptgründe für die Nichtverfügbarkeit in Cloud-Scale-Systemen sind wie folgt:

    • Softwarefehler
    • Konfigurationsfehler
    • Menschlicher Bedienerfehler
      Anmerkung: Die wichtigste Lehre der Branche ist, dass diese drei Formen menschlicher Fehler bei Weitem die größten Ursachen für die Nichtverfügbarkeit sind. Sie können zwar durch Tools, Automatisierung und Training reduziert, aber nicht ganz beseitigt werden. Daher müssen sie bei Architektur, Design und Implementierung des Systems als Hauptanliegen betrachtet werden.
    • Inakzeptable Leistungsabweichungen (Latenz oder Durchsatz) aus beliebigen Gründen, einschließlich der folgenden:
      • „Noisy Neighbours“ mit mehreren Mandanten (Versagen von QoS-Mechanismen)
      • Unfähigkeit, eine (zufällige oder böswillige) Überlastung wirksam abzuwehren und gleichzeitig nützliche Arbeit zu verrichten
      • Verteilter Thrash, Message Storms, Retry Storms und andere teure „auftauchende“ Interaktionen
      • Kälteschock (leere Caches) nach Power-Cycle, insbesondere gleichzeitiger Power-Cycle mehrerer Systeme
      • Overhead bei Skalierung des Systems (z. B. erneutes Sharding)
    • Versäumnis, den „Explosionsradius“ (Anzahl der betroffenen Kunden und Systeme) eines der vorstehenden Probleme zu begrenzen

    Diese Herausforderungen sind universell – sie sind Teil der „Gesetze der Physik“ für verteilte Systeme im Cloud-Maßstab.

    Wir nutzen für jede der oben genannten Kategorien bewährte Entwicklungsstrategien, um das Problem zu lösen. Die wichtigsten davon sind:

    • Prinzipien von Architektur- und Systemdesign
    • Neue Architekturkonzepte (die normalerweise aus der Anwendung der Prinzipien entstehen)
    • Service-Engineering-Verfahren

    Prinzipien von Architektur- und Systemdesign

    Viele dieser Prinzipien existieren, aber wir konzentrieren uns auf die, die für Resilienz und Verfügbarkeit am relevantesten sind.

    Wiederherstellungsorientiertes Computing

    Um Softwarefehler und Fehler von Operatoren mit relativ lokalisierten Auswirkungen zu handhaben, folgen wir den Prinzipien des wiederherstellungsorientierten Computing1. Auf hohem Niveau bedeutet dies, dass wir uns darauf konzentrieren, alle Probleme unauffällig und auf eine Weise zu behandeln, anstatt zu garantieren, dass wir nie ein Problem haben (was unmöglich zu testen ist). Insbesondere konzentrieren wir uns auf die Minimierung der mittleren Zeit bis zur Wiederherstellung (MTTR), die eine Kombination aus mittlerer Zeit bis zur Erkennung, mittlerer Zeit bis zur Diagnose und mittlerer Zeit bis zur Minderung ist.

    Unser Ziel ist es, das Problem so schnell wiederherzustellen, dass menschliche Benutzer nicht durch das Problem belästigt werden. Die folgenden Punkte helfen uns, dieses Ziel zu erreichen:

    • Erkennen Sie schnell und automatisch die Symptome von Fehlern und Fehlern durch Bediener, durch umfangreiche Assertion-Verwendung im Code sowie aktive Überwachung und Alarmierung auf allen Ebenen.
    • Packen Sie die Funktionalität in viele separate, feinkörnige Isolationseinheiten (Threads, Prozesse, Fibers, Zustandsmaschinen usw.), die lose gekoppelt sind – das heißt, sie teilen keinen direkten Arbeitsspeicher, der beschädigt werden könnte.
    • Bei Feststellung der Symptome eines Fehlers oder eines Fehlers durch einen Bediener ist die umschließende Isoliereinheit so schnell wie möglich automatisch neu zu starten. Der Neustart ist ein praktischer Weg, um zu versuchen, sich von einem willkürlichen Fehler zu erholen, weil er versucht, einen Zustand wiederherzustellen, der gut getestet wurde, und so Invarianten wiederherstellt.
    • Wenn die Wiederherstellung auf der feinkörnigen Isolationsebene nicht funktioniert (z. B. Assertionen werden auf dieser Ebene zu häufig ausgelöst, was zu einem Spin-Crash führt), eskalieren Sie zur nächstgrößeren Einheit (Prozess, Laufzeit, Host, logisches Data Center, Paging eines menschlichen Operators).
    • Erstellen Sie Mechanismen, um ein „systemweites Rückgängigmachen“ zu ermöglichen, einschließlich der Versionierung aller persistenten Zustände und Konfigurationen, um fehlerhafte Commits schnell zu identifizieren und rückgängig zu machen.

    Auswirkungen von Problemen minimieren

    Wir entwickeln Mechanismen, um die Auswirkungen von Bugs und Fehlern zu minimieren, die weitreichende Auswirkungen haben könnten. Das heißt, wir konzentrieren uns darauf, die Anzahl der Kunden, Systeme oder Ressourcen zu minimieren, die von Problemen betroffen sind, einschließlich der besonders herausfordernden Probleme von mandantenfähigen „Noisy Neighbors“, angebotener Überlastung, eingeschränkter Kapazität und verteiltem Thrash. Dazu verwenden wir verschiedene Isolationsgrenzen und Änderungsmanagementverfahren (siehe folgende Abschnitte).

    Architekturkonzepte, die aus Designprinzipien entstehen

    Es gibt viele dieser Konzepte, aber wir werden uns auf Konzepte zur Begrenzung des Explosionsradius konzentrieren.

    In unserer öffentlichen API verankerte Platzierungskonzepte: Regionen, Availability-Domain und Faultdomains

    Da Faultdomains noch relativ neu sind, gehen wir näher auf diese ein.

    Mit Faultdomains werden die Auswirkungen von Problemen bei einer aktiven Änderung des Systems begrenzt, wie z. B. bei Deployments, Patching, Hypervisor-Neustarts und der physischen Wartung.

    Die Garantie besteht darin, dass in einer gegebenen Availability-Domain zu jedem Zeitpunkt Ressourcen in höchstens einer Faultdomain geändert werden. Wenn ein Problem beim Änderungsprozess auftritt, kann es vorkommen, dass einige oder alle Ressourcen in dieser Faultdomain eine Weile nicht verfügbar sind. Die anderen Faultdomains in der Availability-Domain sind jedoch nicht betroffen. Jede Availability-Domain enthält mindestens drei Faultdomains, damit quorumbasierte Replikationssysteme (z. B. Oracle Data Guard) mit High Availability in einer einzelnen Availability-Domain gehostet werden können.

    Infolgedessen fungiert jede Faultdomain für eine vorherrschende Kategorie von Verfügbarkeitsproblemen – Softwarefehler, Konfigurationsfehler, Fehler von Bedienern und Leistungsprobleme, die während eines Änderungsverfahrens auftreten – als separates logisches Data Center innerhalb einer Availability-Domain.

    Faultdomains schützen auch vor einigen Arten lokalisierter Hardwarefehler. Mit den Eigenschaften von Faultdomains wird sichergestellt, dass in unterschiedlichen Faultdomains platzierte Ressourcen so praktisch keine gemeinsamen Single Point of Hardwareausfälle innerhalb der Availability-Domain teilen. Zum Beispiel teilen sich Ressourcen in verschiedenen Faultdomains nicht denselben „Top-of-Rack“-Netzwerk-Switch, weil dem Standarddesign solcher Switches die Redundanz fehlt.

    Die Fähigkeit von Faultdomains, sich gegen Probleme in der Hardware oder in der physischen Umgebung zu schützen, endet jedoch auf dieser lokalen Ebene. Im Gegensatz zu Availability-Domains und Regionen stellen Faultdomains keine umfangreiche physische Infrastrukturisolierung bereit. In den seltenen Fällen einer Naturkatastrophe oder eines Availability-Domain-weiten Infrastrukturausfalls sind Ressourcen in mehreren Faultdomains wahrscheinlich gleichzeitig betroffen.

    Unsere internen Services nutzen Faultdomains genauso, wie sie auch von Kunden verwendet werden sollten. Beispiel: Block Volumes, Object Storage und File Storage speichern Replikate von Daten in drei separaten Faultdomains. Alle Komponenten aller Control Planes und Data Planes werden in allen drei Faultdomains (bzw. in einer Region mit mehreren Availability-Domains) gehostet.

    Servicezellen

    Mit Servicezellen werden die Auswirkungen von Problemen begrenzt, die auftreten, obwohl ein System nicht aktiv geändert wird. Derartige Probleme können entstehen, weil die Workload eines mehrmandantenfähigen Cloud-Systems sich jederzeit von Grund auf ändern kann und weil komplexe Teilfehler in jedem großen verteilten System zu jeder Zeit auftreten können. Diese Szenarios können verdeckte Bugs oder neue Performanceprobleme auslösen.

    Darüber hinaus begrenzen Servicezellen in einigen seltenen, aber schwierigen Szenarien, in denen das System aktiv verändert wird, auch den Sprengradius. Ein klassisches Beispiel ist, wenn die Bereitstellung in einer einzelnen Faultdomain erfolgreich erscheint – keine Fehler oder Leistungsänderungen –, aber sobald die zweite oder letzte Faultdomain aktualisiert wurde, neue Interaktionen innerhalb des Systems (bei voller Cloud-Skalierung mit Produktions-Workload) ein Leistungsproblem verursachen.

    Beachten Sie, dass die Nutzung von Servicezellen ein Architekturmuster ist und kein explizit in der Oracle Cloud-API oder dem SDK benanntes Konzept. Jedes beliebige Mehrmandantensystem kann dieses Architekturmuster verwenden. Es erfordert keinen besonderen Support von der Cloud-Plattform.

    Servicezellen funktionieren wie folgt:

    • Jede Instanz des Services (z. B. in einer bestimmten Region oder in einer bestimmten Availability-Domain für lokale Services der Availability-Domain) besteht aus mehreren separaten Deployments des Software-Stacks des Services. Jedes separate Deployment wird als Zelle bezeichnet. Jede Zelle verfügt über eine eigene Infrastruktur, soweit das sinnvoll ist. Zumindest teilen sich Zellen keine Hosts oder VMs.
    • Ein Service kann mit ein paar Zellen in jeder Availability-Domain oder Region beginnen. Wenn der Service entsprechend dem zunehmenden Bedarf skaliert wird, werden weitere Zellen hinzugefügt, um die Auswirkungen eventueller Probleme weiterhin zu begrenzen. Bei einem großen, gängigen Service können viele Zellen verwendet werden. Mit anderen Worten, Zellen bieten n-zu-m-Multiplexing von Kunden-Workloads in separaten Hosting-Umgebungen – separate Inseln der Ressourcenisolation. Zellen verfügen nicht über eine offensichtliche Kardinalität, wie sie bei Fehlerdomänen vorhanden ist. (Wie bereits erwähnt werden als primäre Kardinalität drei Faultdomains pro Availability-Domain gewählt, damit quorumbasierte Replikationssysteme mit High Availability in einer Availability-Domain gehostet werden können.)
    • Jede „natürliche Einheit“ eines Kunden-Workloads wird einer bestimmten Zelle zugeordnet. Die Definition der „natürlichen Einheit“ hängt von der Art des jeweiligen Services ab. Beispielsweise könnte die natürliche Einheit für unseren internen gemeinsam genutzten Workflow-Service (später beschrieben) „alle Workflows in dieser Availability-Domain oder Region für eine bestimmte Control Plane“ sein.
    • Vor jeder Gruppe von Zellen befindet sich entweder eine minimalistische Routing-Schicht oder eine API zum Erkennen von Zellenendpunkten. Beispielsweise verfügt das Streaming-/Messaging-System über eine API, um den aktuellen Endpunkt der Data Plane für ein bestimmtes Thema zu ermitteln, und der interne Metadatenspeicher verfügt über einen separaten Endpunkt pro Zelle. Andere zellbasierte Dienste haben jedoch einen einzigen Endpunkt auf der Data Plane und eine gemeinsame Routing-Schicht. Der Routinglayer ist eine potenzielle Ursache für den korrelierten Ausfall mehrerer Zellen, aber dies wird abgemildert, indem der Routinglayer extrem einfach, vorhersehbar und leistungsfähig (keine teuren Operationen) gehalten und mit einer großen Menge an Headroom-Kapazität und einem ausgeklügelten QoS-Kontingent und Drosselmechanismen ausgestattet wird.
    • Service-Owner können eine Workload nach Bedarf von einer Zelle in eine andere verschieben. Hier einige Beispielszenarios:
      • Zur Vermeidung des Multi-Tenant-Problems „Noisy Neighbor“ durch Verschieben einer hohen Workload, sodass andere Benutzer einer Zelle nicht beeinträchtigt werden.
      • Zur Wiederherstellung nach einer Überlastung oder einem Brownout, der möglicherweise durch einen Distributed-Denial-of-Service-Angriff verursacht wurde. Wir haben Quota- und Throttling-Mechanismen, um uns gegen solche Angriffe zu verteidigen, aber manchmal treten Grenzfälle auf, in denen ein bestimmter Anwendungsfall (API, Zugriffsmuster) für den Service anstrengender ist, als das Quota- bzw. Throttling-System derzeit versteht. Die Zellen bieten einen Mechanismus zur kurzfristigen Milderung.
      • Um kritische Workloads in verschiedene Zellen aufzuteilen, um die Wahrscheinlichkeit korrelierter Ausfälle deutlich zu reduzieren. Beispielsweise werden für unseren internen gemeinsamen Workflow für Control Planes die „kritischen Kern“-Control Planes (z. B. Plattform, Compute, Netzwerk und Block-Volumes) jeweils unterschiedlichen Zellen zugewiesen. Somit besteht weitaus weniger Fehlerkorrelation als in nicht verwendeten Zellen oder aber in derselben Zelle.
        Hinweis: Diese Verwendung von Zellen nimmt den Kunden die Notwendigkeit, die internen Abhängigkeiten von Diensten zu berücksichtigen, um belastbare Anwendungen zu erstellen. Das Abhängigkeitsdiagramm sollte weiterhin berücksichtigt werden (siehe weiter unten). Wenn bereits ein Dekorrelationsmechanismus aktiv ist, ist es aber weniger erforderlich.

    Das Ergebnis ist, dass jede Servicezelle eine weitere Art von „logischem Data Center“ ist – eine logische Gruppierung von Performanceisolation und Fehlerisolation – innerhalb einer einzelnen Availability-Domain oder Region.

    Zusammenfassend lässt sich sagen, dass Servicezellen und Faultdomains sich auf folgende Arten ergänzen:

    • Faultdomains schützen vor Problemen, wenn ein System aktiv geändert wird.
    • Servicezellen begrenzen den Explosionsradius, wenn ein System potenziell schwerwiegende Probleme hat – unabhängig davon, ob es aktiv geändert wird oder nicht.

    Bei der Ausführung von Deployments und dem Patching werden die Eigenschaften von Faultdomains und Servicezellen in einer einheitlichen Strategie kombiniert.

    Service-Engineering-Verfahren

    Da sowohl das Testen als auch der Betrieb für die Zuverlässigkeit von Cloud-Systemen von entscheidender Bedeutung sind, verfügen wir über eine große Anzahl von technischen Verfahren. Einige der wichtigeren Verfahren unter Verwendung der weiter oben beschriebenen Konzepte:

    • Services werden inkrementell bereitgestellt. Dabei erfolgt eine vorsichtige Validierung zwischen den einzelnen Schritten und ein reflexives Rollback bei unerwarteten Ereignissen. Konkret sieht der Prozess wie folgt aus:
      • In jeder Availability-Domain wird jeweils eine Servicezelle bereitgestellt. Für jede Zelle wird eine Faultdomain nach der anderen eingerichtet, bis alle Faultdomains für diese Zelle abgeschlossen sind. Dann fahren wir mit der nächsten Zelle in dieser Availability-Domain fort.
      • Nach jedem Schritt der Bereitstellung (nach jeder Faultdomain und Zelle) überprüfen wir, ob die Änderung wie beabsichtigt funktioniert – das heißt, wir haben die Leistung nicht beeinträchtigt oder Fehler eingeführt, weder intern noch extern. Wenn etwas falsch oder unerwartet erscheint, machen wir die Änderung reflexartig rückgängig. Wir legen großen Wert auf die Vorbereitung und das Testen, einschließlich automatisierter Tests, von Rollback-Verfahren, einschließlich Änderungen, die sich auf den persistenten Zustand oder Schemas auswirken.
      • So stellen wir die Änderung nacheinander in den Availability-Domains jeder Region bereit. Wir stellen in allen Regionen in einem Bereich so bereit, dass wir nicht gleichzeitig ein Regionspaar ändern, das ein Kunde möglicherweise für primäre und Disaster Recovery-Standorte verwendet.
    • Wir überprüfen regelmäßig, ob Fehlerbehandlungsmechanismen und andere Minderungsmaßnahmen wie erwartet funktionieren und das Problem im großen Maßstab nicht verschlimmern. Ohne derartige Tests kommt es oft vor, dass Fehlerbehandlungsmechanismen (wie Wiederholungen, Algorithmen für die Wiederherstellung nach Abstürzen und Algorithmen für die Neukonfiguration von State Machines) Bugs aufweisen, zu kostspielig sind oder unerwartete Folgen haben, sodass Distributed Thrash oder andere schwerwiegende Performanceprobleme entstehen.
    • Wir stellen wie oben beschrieben sicher, dass wir schnell und sicher auf die letzte bekannte gute Software und Konfiguration zurücksetzen können, einschließlich persistentem Status und Schema.
  • Sind in Oracle Regionen, die mehrere Availability-Domains enthalten, alle kritischen Services über die Availability-Domains verteilt?

    Ja. Alle Availability-Domains in jeder Region bieten dieselben Services an.

  • Wie vermeiden Oracle und seine Kunden einen kritischen Service, der von einem einzigen logischen Data Center abhängt?

    In Regionen mit einer einzigen Availability-Domain können Kunden Faultdomains (logische Gruppen mit dekorrelierten Fehlermodi zwischen Gruppen) verwenden, um die meisten Eigenschaften separater „logischer Data Center“ zu erreichen. Kunden können auch mehrere Regionen für Disaster Recovery (DR) nutzen.

    In Multi-Availability-Domain-Regionen können Kunden Faultdomains genauso einsetzen. Kunden können auch eine Kombination aus lokalen Availability-Domain-Services, AD-übergreifenden Failover-Features (wie DBaaS mit Data Guard) und regionalen Services (Object Storage, Streaming) verwenden, um vollständige HA über „logische Data Center“ der höheren Ebene (Availability-Domains) zu erreichen. Schließlich können Kunden auch mehrere Regionen für DR verwenden.

    In allen Fällen können Kunden das Konzept von Servicezellen verwenden, um selbst die schwerwiegendsten Probleme, wie zum Beispiel Distributed Thrash, weiter zu isolieren.

  • Wie führt Oracle Wartungsarbeiten durch, ohne dass kritische Services vorübergehend nicht für Kunden verfügbar sind?

    Dazu verwenden wir Faultdomains, Servicezellen und unsere betrieblichen Prozeduren für inkrementelles Deployment und Validierung. Diese wurden weiter oben bereits erläutert.

  • Werden für höhere Verfügbarkeit Serverless-Plattformservices über mehrere logische Data Center bereitgestellt?

    Ja. Alle Kategorien von Services werden in mehreren logischen Data Centern bereitgestellt – getrennte logische Gruppierungen von Fehlerisolierung und Leistungsisolierung – für Resilienz und kontinuierliche Verfügbarkeit.

  • Wenn Resilienz nicht Teil der Standardkonfiguration ist, können Kunden dennoch ein Deployment mit mehreren logischen Data Centern auswählen (z. B. eine Konfiguration mit mehreren Availability-Domains oder eine regionsübergreifende Konfiguration)?

    In Regionen mit einer einzigen Availability-Domain bieten wir Faultdomains als Mechanismus für „mehrere logische Data Center“ an (wie bereits in diesem Dokument erläutert).

    In Regionen mit mehreren Availability-Domains bieten wir Services und Features an, die ein noch höheres Maß an physischer Dauerhaftigkeit synchron replizierter Daten bieten (bei bescheidener Leistung, Kosten aufgrund der Entfernung zwischen Availability-Domains in der Region und Lichtgeschwindigkeit).

    Wir bieten keine automatischen HA- oder Failover-Mechanismen über Regionen hinweg an, da dies eine enge Kopplungsbeziehung zwischen Regionen schaffen und das Risiko eingehen würde, dass mehrere Regionen gleichzeitig Probleme haben. Stattdessen ermöglichen wir verschiedene Arten der asynchronen Replikation zwischen Regionen und bieten immer mehr Features wie asynchrone Kopien und Backups für das Disaster Recovery über Regionen hinweg an.

  • Wie hilft Oracle seinen Kunden, korrelierte Anwendungsfehler bei Anwendungen zu vermeiden, die durch interne Abhängigkeiten zwischen den verschiedenen Infrastruktur- und Plattformservices verursacht werden?

    Das ist eine komplizierte Frage, die wir zur Verdeutlichung auf verschiedene Art und Weise umformulieren werden:

    • Wenn ein Kunde zwei Oracle Services (Service A und Service B) verwendet und eine Anwendung erstellen möchte, die ausfallsicher ist, wenn einer dieser Services ausfällt, muss der Kunde dann wissen, ob Service A intern von Service B abhängt? Tragen interne Abhängigkeit erheblich zu korrelierten Fehlern bei? Wenn dies der Fall ist, muss der Kunde möglicherweise über solche internen Abhängigkeiten Bescheid wissen, um zu entscheiden, welche anderen Verwendungen von Service A und Service B erfolgen sollen – oder ob er stattdessen einen nicht verwandten Service C für diese zusätzlichen Fälle hinzuziehen soll – wenn er seine eigenen Resilienzmechanismen auf Anwendungsebene erstellt.
    • Wie schützt sich der Kunde am besten gegen korrelierte Ausfälle von Oracle Services?

    Die Antwort besteht aus zwei Teilen.

    Architektonische Grundsätze

    Wir verwenden architektonische Grundsätze, mit denen korrelierte Ausfälle zwischen abhängigen Services erheblich reduziert werden. In einigen Fällen reduziert diese Technik die Wahrscheinlichkeit eines korrelierten Ausfalls so weit, dass sie aus der Perspektive der Erfüllung einer SLA für Verfügbarkeit ignoriert werden kann.

    Insbesondere verwenden wir Servicezellen, wie weiter oben in diesem Dokument beschrieben. Zellen helfen bei diesem Problem, denn wenn der interne Service A von einem Problem in einer seiner Abhängigkeiten, Service B, betroffen ist, ist das Problem mit Service B sehr wahrscheinlich auf eine einzelne Zelle beschränkt. Andere übergeordnete Services (und die Anwendungen des Kunden), die Service B verwenden, nutzen wahrscheinlich andere Zellen, die nicht betroffen sind. Dies ist ein probabilistisches Argument, das mit der Anzahl der Zellen variiert, die ein versteckter interner Parameter ist, der sich ändert (erhöht), sodass keine Quantifizierung oder Garantie über die eigenständigen Service-SLAs der Services A und B hinaus gegeben wird. In der Praxis kann dies jedoch Fehler zwischen Services erheblich dekorrelieren.

    Viele unserer gemeinsamen internen Services, z. B. der Workflow- und der Metadaten-Service für Control Planes und der Streaming-/Messagingservice, verwenden Servicezellen für die Dekorrelation von Ausfällen für die Upstream-Services, die diese nutzen.

    Abhängigkeiten

    Folgendes dient lediglich als allgemeiner Leitfaden, da die genaue Implementierung und die Details von Services unterschiedlich ausfallen. Aber für die Schlüsseldimensionen Compute, Storage, Networking und Authentifizierung/Autorisierung weisen wir auf die folgenden Abhängigkeiten hin.

    Allgemeine Abhängigkeiten bei Control Planes:

    • Identity/Platform-Datenebene zur Authentifizierung und Autorisierung
    • Auditverfolgungsservice
    • Interne Services z.B. für Workflow, Metadatenspeicherung und Logging
    • Verschiedene Load Balancer

    Bei einigen Control Planes liegen offensichtlich servicespezifische Abhängigkeiten vor. Beispielsweise hängt die Compute-Control Plane beim Starten einer Bare-Metal- oder VM-Instanz von Folgendem ab:

    • Object Storage (um das angegebene Betriebssystem-Image abzurufen)
    • Block Volume-Control Plane (zum Provisioning und Anhängen des Boot-Volumes)
    • Networking-Control Plane (zum Provisioning und Anhängen von VNICs)

    Für Core-Service-Data Planes gilt das allgemeine Prinzip, dass jede Data Plane absichtlich so konzipiert ist, dass sie minimale Abhängigkeiten aufweist, um eine hohe Verfügbarkeit, eine schnelle Diagnose und eine schnelle Wiederherstellung zu erreichen. Die Ergebnisse dieses Prinzips sind wie folgt:

    • Die Networking-Data Plane ist eigenständig.
    • Die Block Volume-Data Plane ist eigenständig.
    • Compute-Bare-Metal- und VM-Instanzen hängen von der Block-Volumes-Date Plane (für Boot-Volumes) und der Networking- Data Plane ab.
    • Die Object Storage-Data Plane hängt für die Authentifizierung und Autorisierung von der Identity/Platform-Data Plane ab (aufgrund der Erwartungen der Branche). Die Object Storage-Data Plane hängt nicht von Block Volumes oder File Storage ab.
    • Alle Services, die Backup und Restore unterstützen, sind für dieses Feature von der Object Storage-Data Plane abhängig.

    Bei IaaS-Data Planes gilt als allgemeines Prinzip, dass Abhängigkeiten nur von Kern- oder untergeordneten Data Planes möglich sind (um zirkuläre Abhängigkeiten zu vermeiden).

    • Database Multi-Node RAC hängt von der Networking-Data Plane und der Block Volumes-Data Plane ab.
    • Container Engine for Kubernetes ist selbstverständlich von Kubernetes und den zugehörigen transitiven Abhängigkeiten (z. B. etcd) sowie der Networking-Data Plane abhängig.
    • Jede Unterstützung für Backup und Restore ist von der Object Storage-Data Plane abhängig.
  • Funktionieren Oracle Cloud Infrastructure-Services in einer Region, einschließlich regionaler API-Endpunkte, weiterhin, wenn sie von den Funktionen der globalen Control Plane isoliert sind?

    Ja, Oracle Cloud Infrastructure-Services sind regionsunabhängig konzipiert, sodass Services in einer Oracle Cloud Infrastructure-Region auch dann weiter betrieben werden können, wenn die Region von anderen Oracle Cloud Infrastructure-Regionen und/oder der globalen Steuerungsebene isoliert ist. Sowohl die Data-Plane- als auch die Control-Plane-Funktionalität, einschließlich Service-API-Endpunkte, sind weiterhin verfügbar, auch wenn die Region isoliert ist.

    Viele Oracle Cloud Infrastructure-Services bieten regionsübergreifende Funktionen, wie die regionsübergreifende Objektkopierfunktion, die von Oracle Cloud Infrastructure Object Storage angeboten wird. Regionsübergreifende Funktionen in Oracle Cloud Infrastructure werden immer als Layer über dem Coreservice entworfen, sodass die Regionsisolierung den Coreservice nicht beeinflusst, auch wenn sie sich auf regionsübergreifende Funktionen auswirkt. Beispiel: Die regionsübergreifende Kopierfunktion für Oracle Cloud Infrastructure-Objektspeicher wird als Layer über dem Objektspeicherservice konzipiert. Daher kann die Isolation einer Region Auswirkungen auf die relevante regionsübergreifende Kopierfunktion haben, wirkt sich jedoch nicht auf den Core-Objektspeicherservice in der Region aus.

  • Werden Oracle Cloud Infrastructure-Services in einem logischen Data Center weiterhin verwendet, wenn sie von regionalen Control Plane-Funktionen isoliert sind?

    Ja, Oracle Cloud Infrastructure-Services werden so konzipiert, dass die Data Plane-Funktionalität in jedem logischen Data Center auch dann weiter funktioniert, wenn sie von der entsprechenden regionalen Control Plane isoliert sind. Beispielsweise funktionieren Oracle Cloud Infrastructure-Compute-Instanzen in einem logischen Data Center weiterhin zusammen mit angehängten Block-Volumes und verbundener virtueller Netzwerkfunktionalität, selbst wenn das Data Center von den Funktionen der Control Plane wie Datenverarbeitung, Blockspeicherung, VCN und/oder Identitäts- und Zugriffsverwaltung isoliert ist.

  • Haben Oracle Cloud Infrastructure-Regionen redundante Internetverbindungen für High Availability?

    Ja. Oracle Cloud Infrastructure ist über mehrere redundante Provider in allen kommerziellen Regionen mit dem Internet verbunden. Diese Verbindungen verwenden BGP (Border Gateway Protocol).