Oracle Cloud Infrastructure - Dokumentation

Regionen und Availability-Domains

In diesem Thema wird die physische und die logische Organisation von Oracle Cloud Infrastructure-Ressourcen beschrieben.

Regionen und Availability-Domains

Oracle Cloud Infrastructure wird in Regionen und Availability-Domains gehostet. Eine Region ist ein bestimmter geografischer Bereich. Bei einer Availability-Domain handelt es sich um ein oder mehrere Data Center innerhalb einer Region. Eine Region besteht aus einer oder mehreren Availability-Domains. Die meisten Oracle Cloud Infrastructure-Ressourcen sind entweder regionsspezifisch, wie ein virtuelles Netzwerk, oder spezifisch für eine Availability-Domain, wie eine Compute-Instanz. Der Traffic zwischen Availability-Domains und zwischen Regionen wird verschlüsselt. Availability-Domains sind voneinander isoliert, sie bieten Fehlertoleranz, und ihr gleichzeitiger Ausfall ist sehr unwahrscheinlich. Da Availability-Domains keine Infrastruktur, wie beispielsweise Stromversorgung und Kühlung, oder das interne Availability-Domainnetzwerk gemeinsam nutzen, ist es unwahrscheinlich, dass ein Fehler in einer Availability-Domain einer Region die Verfügbarkeit der anderen in derselben Region beeinflusst.

Die Availability-Domains in derselben Region sind über ein Netzwerk mit geringer Latenz und hoher Bandbreite miteinander verbunden, sodass Sie eine hochverfügbare Konnektivität mit dem Internet und On Premise bereitstellen sowie replizierte Systeme in mehreren Availability-Domains für High Availability und Disaster Recovery erstellen können.

Oracle bietet mehrere Cloud-Regionen auf der ganzen Welt an, um Kunden lokalen Zugriff auf Cloud-Ressourcen zu ermöglichen. Um dies schnell zu erreichen, haben wir uns dafür entschieden, Regionen in neuen Geografien mit einer Availability-Domain zu starten.

Da Regionen eine Erweiterung erfordern, können wir die Kapazität vorhandener Availability-Domains erhöhen, einer vorhandenen Region weitere Availability-Domains hinzufügen oder eine neue Region erstellen. Der Erweiterungsansatz in einem konkreten Szenario basiert auf Kundenanforderungen und Überlegungen zu regionalen Bedarfsmustern und zur Ressourcenverfügbarkeit.

Regionen sind unabhängig von anderen Regionen. Sie können extrem weit auseinanderliegen und durch Länder oder sogar Kontinente getrennt sein. Im Allgemeinen stellen Sie eine Anwendung in der Region bereit, in der sie am stärksten genutzt wird, da die Verwendung nahegelegener Ressourcen schneller ist als die Verwendung entfernterer Ressourcen. Aus folgenden Gründen können Sie jedoch auch Anwendungen in anderen Regionen bereitstellen:

  • Um das Risiko von regionsweiten Ereignissen wie Erdbeben oder gravierenden Witterungsbedingungen zu mindern.
  • Um variierenden Vorschriften von Rechtssystemen, Steuerregionen und sonstigen geschäftlichen oder sozialen Aspekten gerecht zu werden.

Regionen sind in Realms  gruppiert. Ihr Mandant befindet sich in einer einzelnen Realm und hat Zugriff auf alle Regionen, die zu dieser Realm gehören. Sie können nicht auf Regionen zugreifen, die sich nicht in Ihrer Realm befinden. Derzeit verfügt Oracle Cloud Infrastructure über mehrere Realms, darunter kommerzielle Realms, Regierungs-Realms und dedizierte Realms.

In der folgenden Tabelle sind die Regionen der kommerziellen Oracle Cloud Infrastructure-Realms aufgeführt:

Regionsname Regions-ID Regionsstandort Regionsschlüssel Realm-Schlüssel Availability-Domains
Australia East ap-sydney-1 Sydney, Australien SYD OC1 1
Australien Südosten (Melbourne) ap-melbourne-1 Melbourne, Australien MEL OC1 1
Brazil East (Sao Paulo) sa-saopaulo-1 São Paulo, Brasilien GRU OC1 1
Brasilianischer Südosten Sa-Vinyl-1 Vinhedo, Brasilien VCP OC1 1
Kanada Südosten (Montreal) ca.montreal-1 Montreal, Kanada Juli OC1 1
Canada Southeast (Toronto) ca-toronto-1 Toronto, Kanada YYZ OC1 1
Chile Central (Santiago) sa-santiago-1 Santiago, Chile SCL OC1 1
Chile West (Valparaiso) Sa-valparaiso-1 Valparaiso (Chile) VAP OC1 1
Zentral Kolumbien (Bogota) sa-bogota-1 Bogota, Kolumbien BOG OC1 1
France Central eu-paris-1 Paris, Frankreich CDG OC1 1
France South (Marseille) eu-marseille-1 Marseille, Frankreich MRS OC1 1
Deutschland Mitte (Frankfurt) eu-frankfurt-1 Frankfurt, Deutschland FRA OC1 3
India South (Hyderabad) ap-hyderabad1 Hyderabad, Indien HYD OC1 1
India West (Mumbai) ap-mumbai-1 Mumbai, Indien BOM OC1 1
Israel Central il-jerusalem-1 Jerusalem, Israel MTZ OC1 1
Italien Nordwesten (Mailand) eu-milan-1 Mailand, Italien LINKS OC1 1
Zentral-Japan ap-osaka-1 Osaka, Japan KIX OC1 1
Japan East ap-tokyo-1 Tokio, Japan NRT OC1 1
Mexico Central (Queretaro) mx-queretaro-1 Queretaro, Mexiko QRO OC1 1
Mexiko Nordosten (Monterrey) mx-monterrey-1 Monterrey (Mexiko) MTY OC1 1
Netherlands Northwest (Distrikt) eu-amsterdam-1 Amsterdam, Niederlande AMS OC1 1
Saudi Arabia West (Dschidda) me-jeddah-1 Dschidda, Saudi-Arabien JED OC1 1
Serbien-Zentral eu-jovanovac-1 Jovanovac, Serbien BEG OC20 1
Singapur ap-singapore-1 Singapore, Singapur SIN OC1 1
Singapore West ( Singapur) ap-singapore-2 Singapore, Singapur XSP OC1 1
South Africa Central (Johannesburg) af-johannesburg-1 Johannesburg (Südafrika) JNB OC1 1
South Korea Central (Seoul) ap-seoul-1 Seoul, Südkorea ICN OC1 1
South Korea North (Chuncheon) Ap-Chuncheon-1 Chuncheon, Südkorea YNY OC1 1
Spain Central eu-madrid-1 Madrid, Spanien MAD OC1 1
Schwedisches Zentrum eu-stockholm-1 Stockholm (Schweden) Artikelnummer OC1 1
Schweiz Nord eu-zurich-1 Zürich, Schweiz ZRH OC1 1
UAE Central (Abu Dhabi) me-abudhabi-1 Abu Dhabi, Vereinigte Arabische Emirate AUH OC1 1
UAE East (Dubai) me-dubai-1 Dubai, Vereinigte Arabische Emirate DXB OC1 1
UK South (London) uk-london-1 London, Vereinigtes Königreich LHR OC1 3
UK West uk-cardiff-1 Newport, Vereinigtes Königreich CWL OC1 1
US East us-ashburn-1 Ashburn, VA IAD OC1 3
US-amerikanischer Midwest us-chicago-1 Chicago, IL Auftrag OC1 3
US West us-phoenix-1 Phoenix, AZ PHX OC1 3
US West (San Jose) us-sanjose-1 San Jose, CA SJC OC1 1

Informationen zum Abonnieren einer Region finden Sie unter Regionen verwalten.

Eine Liste der Regionen in den Government Cloud-Realms finden Sie in den folgenden Themen:

Availability-Domainnamen Ihres Mandanten

Um die Data Center-Auslastung auszugleichen, randomisiert Oracle Cloud Infrastructure die Availability-Domains nach Mandant. Beispiel: Bei der Availability-Domain mit der Bezeichnung PHX-AD-1 für tenancyA kann es sich um ein anderes Data Center handeln als bei der Availability-Domain mit der Bezeichnung PHX-AD-1 für tenancyB.

Um nachzuverfolgen, welche Availability-Domain welchem Data Center für den jeweiligen Mandanten entspricht, verwendet Oracle Cloud Infrastructure mandantenspezifische Präfixe für die Availability-Domainnamen. Ein Beispielpräfix ist Uocm:. Bei diesem Präfix lauten die Availability-Domainnamen Uocm:PHX-AD-1, Uocm:PHX-AD-2 usw.

Um die spezifischen Namen der Availability-Domains Ihres Mandanten abzurufen, verwenden Sie den Vorgang ListAvailabilityDomains, der in der IAM-API verfügbar ist. Die Namen werden auch angezeigt, wenn Sie über die Konsole eine Instanz erstellen und auswählen, in welcher Availability-Domain die Instanz erstellt werden soll.

Faultdomains

Eine Faultdomain ist eine Gruppierung aus Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain umfasst drei Faultdomains. Faultdomains bieten Anti-Affinität: Mit ihnen können Sie Ihre Instanzen so verteilen, dass sie sich in einer einzelnen Availability-Domain nicht auf derselben physischen Hardware befinden. Ein Hardwarefehler oder ein Wartungsereignis für Compute-Hardware, das sich auf eine Faultdomain auswirkt, hat keine Auswirkungen auf Instanzen in anderen Faultdomains.

Um die Platzierung Ihrer Compute-Instanzen, Bare-Metal-DB-Systeminstanzen oder Virtual-Machine-DB-Systeminstanzen zu kontrollieren, können Sie optional die Faultdomain für eine neue Instanz oder einen neuen Instanzpool beim Start angeben. Wenn Sie die Faultdomain nicht angeben, wird vom System automatisch eine ausgewählt. Oracle Cloud Infrastructure stellt eine bestmögliche Anti-Affinität-Platzierung über verschiedene Faultdomains hinweg her, während die Optimierung der verfügbaren Kapazität in der Availability-Domain erfolgt. Um die Faultdomain für eine Compute-Instanz zu ändern, bearbeiten Sie die Faultdomain. Um die Faultdomain für eine Bare-Metal- oder Virtual-Machine-DB-Systeminstanz zu ändern, beenden Sie sie, und starten Sie eine neue Instanz in der bevorzugten Faultdomain.

Mit Faultdomains können Sie Folgendes sicherstellen:

  • Schutz vor unerwarteten Hardwarefehlern
  • Schutz vor geplanten Ausfällen aufgrund einer Wartung der Compute-Hardware.

Weitere Informationen:

Limits für abonnierte Regionen

Test-, Free Tier- und Pay-as-you-go-Mandanten sind auf eine abonnierte Region beschränkt. Sie können eine Erhöhung des Limits für Pay-as-you-go-Mandanten beantragen. Weitere Informationen dazu finden Sie unter So beantragen Sie eine Erhöhung des Limits für abonnierte Regionen.

Mandanten mit monatlichen Universal Credits können alle öffentlich freigegebenen kommerziellen Regionen abonnieren.

Erhöhung des Limits zur Anzahl der abonnierten Regionen beantragen

Sie können einen Antrag zur Erhöhung der Anzahl der abonnierten Regionen für Ihre Mandanten über die Konsole weiterleiten. Wenn Sie versuchen, eine Region zu abonnieren, die über das Limit für Ihren Mandanten hinausgeht, werden Sie aufgefordert, einen Antrag zur Limiterhöhung weiterzuleiten. Außerdem können Sie einen solchen Antrag auf der Seite mit den Servicelimits sowie jederzeit stellen, indem Sie auf den Link im Menü Hilfe (Hilfe (Menü)) klicken.

So beantragen Sie eine Erhöhung des Limits für abonnierte Regionen

  1. Öffnen Sie das Menü Hilfe (Hilfe (Menü)), gehen Sie zu Support, und klicken Sie auf Erhöhung des Servicelimits beantragen.

  2. Geben Sie Folgendes ein:

    • Details zu primärem Kontakt: Geben Sie den Namen und die E-Mail-Adresse der Person ein, die den Antrag übermittelt. Geben Sie nur eine E-Mail-Adresse ein. Eine Bestätigung wird an diese Adresse gesendet.
    • Servicekategorie: Wählen Sie Regionen aus.
    • Ressource: Wählen Sie Anzahl abonnierter Regionen aus.
    • Mandantenlimit: Geben Sie die Limitzahl an.
    • Grund für Anforderung: Geben Sie einen Grund für den Antrag ein. Falls Ihr Antrag dringend oder ungewöhnlich ist, geben Sie hier Details an.
  3. Klicken Sie auf Anforderung weiterleiten.

Nachdem Sie die Anforderung weitergeleitet haben, wird sie verarbeitet. Es kann einige Minuten bis einige Tage dauern, bis eine Antwort empfangen wird. Wenn Ihre Anforderung bewilligt wird, wird eine Bestätigungs-E-Mail an die in den Details zum primären Kontakt angegebene Adresse gesendet.

Falls weitere Informationen zu Ihrem Antrag benötigt werden, wird eine Folge-E-Mail an die in den Details zum primären Kontakt angegebene Adresse gesendet.

Regionsübergreifende Serviceverfügbarkeit

Alle Oracle Cloud Infrastructure-Regionen bieten Coreinfrastrukturservices, einschließlich der Folgenden:

  • Compute: Compute (Intel-basiertes Bare Metal & VM, DenseIO & Standard), Container Engine for Kubernetes, Container Registry, Artifact Registry
  • Storage: Block Volume, File Storage, Object Storage, Archive Storage
  • Networking: Virtuelles Cloud-Netzwerk, Load Balancer, FastConnect (spezifische Partner je nach Verfügbarkeit und Anforderung)
  • Datenbank: Database, Exadata Cloud Service, Autonomous Database für Analysen und Data Warehousing, Autonomous Database für Transaktionsverarbeitung und gemischte Workloads
  • Edge: DNS
  • Plattform: Audit, Identity and Access Management, Monitoring, Notifications, Tagging, Arbeitsanforderungen

  • Sicherheit: Vault

Generell verfügbare Cloud-Services, die neben den in der obigen Liste aufgeführten vorhanden sind, werden je nach regionalem Kundenbedarf zur Verfügung gestellt. Jeder Service kann innerhalb von maximal drei Monaten verfügbar gemacht werden, wobei viele Services schneller bereitgestellt werden. Neue Cloud-Services werden in Regionen so schnell wie möglich basierend auf vielfältigen Überlegungen zur Verfügung gestellt. Hierzu zählen regionaler Kundenbedarf, gegebenenfalls Möglichkeit zur Einhaltung gesetzlicher Vorschriften, Ressourcenverfügbarkeit sowie andere Faktoren. Aufgrund des Interconnect-Backbones mit geringer Latenz von Oracle Cloud Infrastructure können Sie in anderen geografischen Regionen Cloud-Services mit effektiven Ergebnissen verwenden, wenn diese Services in Ihrer Hauptregion nicht verfügbar sind, sofern die Anforderungen hinsichtlich der Data Residency (lokale Datenspeicherung) dies nicht verhindern. Wir arbeiten regelmäßig mit Kunden zusammen, um den effektiven Zugriff auf erforderliche Services zu gewährleisten.

Ressourcenverfügbarkeit

In den folgenden Abschnitten werden die Ressourcentypen nach ihrer Verfügbarkeit aufgeführt: in allen Regionen, innerhalb einer einzelnen Region oder innerhalb einer einzelnen Availability-Domain.

Tipp

: Im Allgemeinen sind IAM-Ressourcen regionsübergreifend. DB-Systeme, Instanzen und Volumes sind für eine Availability-Domain spezifisch. Alle anderen Elemente sind regional. Ausnahme: Subnetze wurden ursprünglich als spezifisch für eine Availability-Domain konzipiert. Jetzt können Sie regionale Subnetze erstellen, und diese werden von Oracle empfohlen.

Regionsübergreifende Ressourcen

  • API-Signaturschlüssel
  • Compartments
  • Detektoren (Cloud Guard, regional für Berichtsregion)
  • Dynamische Gruppen
  • Ressourcen für die Föderation
  • Gruppen
  • Verwaltete Listen (Cloud Guard)
  • Netzwerkquellen
  • Policys
  • Responder (Cloud Guard, regional für Berichtsregion)
  • Tag-Namespaces
  • Tagschlüssel
  • Ziele (Cloud Guard, regional für Berichtsregion)
  • Benutzer

Regionale Ressourcen

  • Zugriffs-Policys (Service-Mesh)
  • Agents (Datenbankmigration)
  • Alarme
  • APM-Domains (Application Performance Monitoring)
  • Anwendungen (Data Flow-Service)
  • Anwendungen (Functions-Service)
  • Artefakt-Repositorys (Artifact Registry)
  • Backups (OCI-Datenbank mit PostgreSQL)
  • Bastionen
  • Blockchain-Plattformen (Blockchain Platform-Service)
  • Buckets: Buckets sind zwar regionale Ressourcen, sie können jedoch von jedem Standort aus aufgerufen werden, wenn Sie die richtige regionsspezifische Object Storage-URL für die API-Aufrufe verwenden.
  • Infrastrukturen (Compute Cloud@Customer-Service)
  • Upgradepläne (Compute Cloud@Customer-Service)
  • Cluster (Big Data Service)
  • Cluster (Container Engine for Kubernetes-Service)
  • Cluster-Platzierungsgruppen (Service Cluster Placement Groups)
  • Cloud-Ereignisregeln
  • Konfigurationsarbeitsanforderungen (Logging Analytics)
  • Konfigurationen (OCI-Datenbank mit PostgreSQL)
  • Konfigurationsquellenprovider (Resource Manager)
  • Verbindungen (Datenbankmigration)
  • Connectors (Connector Hub)
  • Content and Experience (Content Management)
  • Customer Premises Equipment (CPE)
  • Dashboards (Console Dashboards)
  • Dashboards (Management-Dashboard)
  • Dashboard-Gruppen (Konsole-Dashboards)
  • Datenkataloge
  • Datenbank-Insights (Ops Insights)
  • Datenbanken (OCI-Datenbank mit PostgreSQL)
  • Datasets (Data Labeling)
  • DB-Systeme (HeatWave-Service)
  • Deployments (GoldenGate)
  • Devops-Projekte (DevOps)
  • Pipeline erstellen (DevOps)
  • Code-Repositorys (DevOps)
  • Deployment-Pipelines (DevOps)
  • DHCP-Optionssets
  • Discovery-Jobs (Stackmonitoring)
  • DrProtectionGroup (Full Stack Disaster Recovery)
  • DrPlan (Full Stack Disaster Recovery)
  • DrPlanExecution (Full Stack Disaster Recovery)
  • Dynamische Routinggateways (DRGs)
  • Verschlüsselungsschlüssel
  • Entitys (Logging Analytics)
  • Flotten (Java-Management)
  • Funktionen
  • Generische Artefakte (Artifact Registry)
  • Gruppen (OS Management Hub)
  • Hostscans
  • Images
  • Ingress-Gateways (Service-Mesh)
  • Routentabellen von Ingress-Gateways (Service-Mesh)
  • Instanzen (OS Management Hub)
  • Lebenszyklusumgebungen (OS Management Hub)
  • Lebenszyklusphasen (OS Management Hub)
  • Internetgateways
  • Jobs (Datenbankmanagement)
  • Jobs (Datenbankmigration)
  • Jobs (Resource Manager)
  • Load Balancer
  • Lokale Peering-Gateways (LPGs)
  • Loggruppen (Logging Analytics)
  • Installationsschlüssel für Management Agent
  • Management-Agents
  • Verwaltete Datenbankgruppen (Datenbankmanagement)
  • Verwaltete Datenbanken (Datenbankmanagement)
  • Managementstationen (OS Management Hub)
  • Meshes (Service Mesh)
  • Metriken
  • Medienworkflow (Media Flow)
  • Medienworkflowkonfiguration (Media Flow)
  • Medienworkflowjob (Media Flow)
  • Medienasset (Media Flow)
  • Migrationen (Database Migration)
  • Modelle
  • Monitore (Health Checks)
  • NAT-Gateways
  • Netzwerkfirewall-Policys
  • Netzwerksicherheitsgruppen
  • Knotenpools
  • Notizbuchsessions
  • Objekterfassungsregeln (Logging Analytics)
  • OpenSearch-Cluster (Search with OpenSearch)
  • OpenSearch-Clusterbackups (Search with OpenSearch)
  • Portscans
  • Private Endpunkte (Datenbankmanagement)
  • Private Endpunkte (Resource Manager)
  • Arbeitsanforderungen für private Endpunkte (Datenbankmanagement)
  • Private Vorlagen (Resource Manager)
  • Probes (Health Checks):
  • Probleme (Cloud Guard, regional für Berichtsregion)
  • Profile (OS Management Hub)
  • Projekte
  • Abfragejob-Arbeitsanforderungen (Logging Analytics)
  • Queues
  • registrierte Datenbanken (GoldenGate)
  • Repositorys
  • Reservierte öffentliche IPs
  • Ressourcen (Stackmonitoring)
  • Routentabellen
  • Ausführungen
  • Gespeicherte Suchvorgänge (Management-Dashboard)
  • Scanrezepte
  • Geplante Aufgaben (Logging Analytics)
  • Geplante Jobs (OS Management Hub)
  • Secrets
  • Sicherheitslisten
  • Sicherheitszonen
  • Sicherheitszonenrezepte
  • Servicegateways
  • Sessions (Bastion)
  • In Shards unterteilte Datenbank (Global verteilte Autonomous Database)
  • Sharded-Datenbank-Arbeitsanforderung (Global verteilte Autonomous Database)
  • Sharded-Database-Private-Endpoint (Global verteilte Autonomous Database)
  • Softwarequellen (OS Management Hub)
  • Stacks (Resource Manager)
  • StreamDistributionChannel (Media Streams)
  • StreamPackagingConfig (Media Streams)
  • StreamCdnConfig (Media Streams)
  • Speicherarbeitsanforderungen (Logging Analytics)
  • Subnetze: Beim Erstellen eines Subnetzes wählen Sie aus, ob es regional oder spezifisch für eine Availability-Domain ist. Oracle empfiehlt die Verwendung von regionalen Subnetzen.
  • Abonnements
  • Tabellen
  • Ziele (Vulnerability Scanning)
  • Tickets (Support Management-Service)
  • Bedrohungsindikatoren
  • Bedrohungstypen
  • Themen
  • Vaults
  • Virtuelle Cloud-Netzwerke (VCN)
  • Virtuelle Deployments (Service-Mesh)
  • Virtuelle Services (Service-Mesh)
  • Routentabellen von virtuellem Service (Service-Mesh)
  • Volume-Backups: Sie können als neue Volumes in einer beliebigen Availability-Domain in derselben Region wiederhergestellt werden, in der sie gespeichert sind.
  • Berichte über Sicherheitslücken
  • Workspaces

Für Availability-Domain-spezifische Ressourcen

  • Containerinstanzen
  • DB-Systeme (Oracle Database-Service)
  • Ephemere öffentliche IPs
  • Instanzen (Compute): Diese können nur an Volumes in derselben Availability-Domain angehängt werden.
  • Netzwerkfirewalls
  • Subnetze: Beim Erstellen eines Subnetzes wählen Sie aus, ob es regional oder spezifisch für eine Availability-Domain ist. Oracle empfiehlt die Verwendung von regionalen Subnetzen.
  • Volumes: Sie können nur an eine Instanz in derselben Availability-Domain angehängt werden.