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

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?

  • Sind in Oracle Regionen, die mehrere Availability-Domains enthalten, alle kritischen Services über die Availability-Domains verteilt?

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

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

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

  • 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)?

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

  • 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?

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

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