Linear skalierbare, fehlertolerante, gestörte Oracle-Datenbanken auf Oracle Cloud Infrastructure bereitstellen

Wenn Sie eine Datenbank benötigen, die eine extreme Skalierung mit vollständiger Datenisolierung für Ihre unternehmensweiten OLTP-Anwendungen unterstützt, stellen Sie sharded-Instanzen von Oracle Database in einer fehlertoleranten Topologie auf Oracle Cloud Infrastructure bereit.

Sharding ist eine Data-Tier-Architektur, bei der Daten horizontal in unabhängige Datenbanken (Shards) partitioniert werden, die jeweils auf einem separaten Server mit eigenen CPU-, Speicher- und Datenträgerressourcen ausgeführt werden. Dieser gemeinsam genutzte Ansatz beseitigt einzelne Fehlerpunkte auf der Infrastrukturebene. Ein Shards-Pool wird der Anwendungsebene als einzelne logische Datenbank (sharded Database) angezeigt. Anwendungen, die über eine genau definierte Datenverteilungsstrategie verfügen und hauptsächlich über einen Sharding-Schlüssel auf Daten zugreifen, können von einer Sharded Data Tier profitieren.

Architektur

Die folgenden Architekturen zeigen fehlertolerante Oracle Database 19c-Topologien in Oracle Cloud Infrastructure, die mit dem Oracle Database Sharding-Stack bereitgestellt werden, der in Oracle Cloud Marketplace bereitgestellt wird.

Die Architekturen verfügen über redundante Ressourcen in jeder Schicht (Shard-Direktor, Katalog und Shards), um die maximale Verfügbarkeit der Sharded-Datenbank sicherzustellen.

Bereitstellung über mehrere Availability-Domains hinweg

Diese Architektur zeigt eine Sharded-Datenbank, die über zwei Availability-Domains in einer Oracle Cloud Infrastructure-Region verteilt wird.
Beschreibung der Abbildung shards-single-region.png

Deployment in einer einzelnen Availability-Domain

Diese Architektur zeigt eine Sharded-Datenbank, die über die Faultdomains innerhalb einer einzelnen Availability-Domain in einer Oracle Cloud Infrastructure-Region verteilt wird.
Beschreibung der Abbildung shards-single-ad.png

Die Architekturen umfassen:

• Region

  Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Center, sogenannte Availability-Domains, enthält. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie (über Länder oder sogar Kontinente) trennen.

  Alle Ressourcen in dieser Architektur werden in einem von Ihnen angegebenen Compartment und in einer einzelnen Oracle Cloud Infrastructure-Region bereitgestellt.

• Availability-Domains

  Availability-Domains sind eigenständige, unabhängige Data Center in einer Region. Die physischen Ressourcen in jeder Availability-Domain sind von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz bietet. Availability-Domains haben keine gemeinsame Infrastruktur wie Stromversorgung oder Kühlung oder das interne Availability-Domainnetzwerk. Daher ist es wahrscheinlich, dass sich ein Fehler in einer Availability-Domain auf die anderen Availability-Domains in der Region auswirkt.

• Faultdomains

  Eine Fehlerdomain ist eine Gruppierung aus Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain hat drei Faultdomains mit unabhängiger Stromversorgung und Hardware. Wenn Sie Ressourcen auf mehrere Faultdomains verteilen, können Ihre Anwendungen physische Serverfehler, Systemwartung und Stromausfälle innerhalb einer Faultdomain tolerieren.

  Die Ressourcen in dieser Architektur werden gleichmäßig auf die Faultdomains in jeder Availability-Domain verteilt.

• Virtuelles Cloud-Netzwerk (VCN) und Subnetz

  Ein VCN ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten. Wie herkömmliche Data Center-Netzwerke erhalten VCNs vollständige Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere nicht überlappende CIDR-Blöcke haben, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die für eine Region oder eine Availability-Domain gelten können. Jedes Subnetz besteht aus einem fortlaufenden Adressbereich, der sich nicht mit den anderen Subnetzen im VCN überschneidet. Sie können die Größe eines Subnetzes nach dem Erstellen ändern. Ein Subnetz kann öffentlich oder privat sein.

  Die Compute- und Datenbankressourcen in dieser Architektur sind an ein einzelnes regionales öffentliches Subnetz angehängt. Sie können das zu verwendende VCN und Subnetz angeben. Wenn Sie ein neues VCN und Subnetz erstellen möchten, können Sie den CIDR-Adressblock für das VCN und das Subnetz angeben.

• Internetgateway

  Das Internetgateway ermöglicht Traffic zwischen den öffentlichen Subnetzen in einem VCN und dem öffentlichen Internet.

• Sicherheitsliste

  Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die Quelle, Ziel und Typ des Traffics angeben, der im Subnetz und aus dem Subnetz zugelassen werden muss.

  Diese Architektur enthält eine Sicherheitsliste zur Kontrolle des Datenverkehrs zu und von den Shard-Direktoren.

• Routentabelle

  Virtuelle Routentabellen enthalten Regeln, mit denen Traffic von Subnetzen zu Zielen außerhalb eines VCN weitergeleitet wird, im Allgemeinen über Gateways.

  Diese Architektur umfasst eine Routentabelle, mit der Traffic vom Subnetz zum Internetgateway weitergeleitet wird.

• Regisseur (Shard)

  Ein Shard-Direktor (auch Global Service Manager genannt) ist ein Netzwerk-Listener, der ein High Performance Connection Routing an die entsprechenden Datenbank-Shards basierend auf Sharding-Schlüsseln ermöglicht.

  Sie können die Anzahl der erforderlichen Shard-Direktoren angeben. Die Shard-Direktoren werden auf einzelnen Compute-Instanzen bereitgestellt, die über alle Availability-Domains in der Region und über die Faultdomains innerhalb jeder Availability-Domain verteilt sind. Sie können die Ausprägung der Compute-Instanzen auswählen, die für die Shard-Direktoren verwendet werden sollen.

• Primär- und Standby-Shard-Kataloge

  Ein Shard-Katalog ist eine Oracle Database-Sonderinstanz, die automatisiertes Shard-Deployment, zentralisierte Verwaltung einer Sharded-Datenbank und Abfragen mit mehreren Speicherorten unterstützt.

  Diese Architektur enthält ein primäres Standbypaar aus Katalogdatenbanken, jedes Oracle Cloud Infrastructure-VM-DB-System mit einem Knoten. Sie können die Datenbankausprägung und die verfügbare Speicherkapazität für die Katalogdatenbanken wählen.

• Datenbank-Shards

  Jeder Datenbank-Shard ist ein VM-DB-System mit einem Knoten von Oracle Cloud Infrastructure. Sie können die Anzahl der primären Shards, die zu verwendende Datenbankausprägung und die verfügbare Speicherkapazität angeben. Die Shards werden gleichmäßig auf alle Availability-Domains in der Region und auf die Faultdomains innerhalb jeder Availability-Domain verteilt.

  Beim Deployment der Architektur können Sie einen Standby Shard für jeden primären Shard bereitstellen.

  • Wenn Ihre Region mehrere Availability-Domains enthält, wird jeder Shard eines Primär-Standby-Paares in einer separaten Availability-Domain platziert.
  • Wenn die Region nur eine Availability-Domain enthält, werden der primäre und der Standby-Shard in separaten Faultdomains isoliert.

Empfehlungen

Ihre Anforderungen können sich von der hier beschriebenen Architektur unterscheiden. Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt.

• Größe und Anzahl der Shards
  Beim Deployment des Stacks können Sie die zu verwendende Datenbankausprägung und die Anzahl der Shards angeben.

  • Wählen Sie eine geeignete Ausprägung basierend auf Ihren Workload-Anforderungen. Die angegebene Ausprägung wird für alle Shards verwendet.

    Nach dem Deployment können Sie die Form der einzelnen Shards ändern, um sie an Änderungen der Workload anzupassen. Der Shard, für den Sie die Ausprägung ändern, wird gestoppt und dann mit der neuen Ausprägung neu gestartet.

  • Im Allgemeinen bietet eine große Anzahl kleiner Shards eine bessere Gesamtfehlertoleranz als eine geringe Anzahl großer Shards. Um die Topologie zu skalieren oder die Fehlertoleranz zu verbessern, können Sie jederzeit Shards hinzufügen, ohne die Verfügbarkeit der vorhandenen Shards zu beeinträchtigen. Bei Bedarf können Sie in der Sharded-Datenbank skalieren. Der zuletzt erstellte Shard wird zuerst entfernt, nachdem die Daten in die anderen Shards verschoben wurden.
• Shards Availability

  Um High Availability der Shards sicherzustellen, stellen Sie Standby-Shards bereit und verwenden Oracle Data Guard für die Primär-Standbysynchronisierung und für Failover.

• Verfügbarkeit des Shard-Katalogs

  Stellen Sie für High Availability des Shard-Katalogs einen Standbykatalog bereit, und verwenden Sie Oracle Data Guard für Synchronisierung und Failover. Beachten Sie, dass sich die Verfügbarkeit des Shard-Katalogs nicht auf die Verfügbarkeit der Sharded-Datenbank auswirkt. Ein Ausfall des Shard-Katalogs wirkt sich nur auf die Möglichkeit aus, Wartungsvorgänge oder Multishard-Abfragen auszuführen, während ein Failover zum Standby-Katalog erfolgt. OLTP-Transaktionen werden weiterhin an die Shards weitergeleitet.

• Shard Director Availability

  Für High Availability der Shard-Direktorschicht stellen Sie mehrere Shard-Direktoren bereit. Sie können bis zu fünf Shard-Directors in einer Region bereitstellen. Oracle empfiehlt, dass Sie mindestens zwei Shard-Direktoren bereitstellen, isoliert in separaten Availability-Domains oder Faultdomains.

• Speicherung

  Die aktuelle Version des Oracle Cloud Marketplace-Stacks stellt die Datenbank-Shards und die Katalogdatenbank mit Logical Volume Manager-(LVM-)basiertem Speicher bereit. Sie können die verfügbare Speicherkapazität zwischen 256 GB und 40 TB angeben. Wählen Sie eine Speicherkapazität, die für Ihre Workload geeignet ist. Jedem Datenbank-Shard ist ein Block-Volume der angegebenen Größe zugeordnet.

  Sie können den Speicher jederzeit skalieren, ohne die Verfügbarkeit der Datenbank zu beeinträchtigen. Beachten Sie, dass der insgesamt verwendete Speicher höher ist als der verfügbare Speicher. Weitere Informationen finden Sie in der Dokumentation zu Oracle Cloud Infrastructure Database.

• Netzwerk-Design

  Wenn Sie ein VCN erstellen, bestimmen Sie die Anzahl der erforderlichen CIDR-Blöcke und die Größe jedes Blocks basierend auf der Anzahl der Ressourcen, die Sie an Subnetze im VCN anhängen möchten. Verwenden Sie CIDR-Blöcke, die sich im standardmäßigen privaten IP-Adressbereich befinden.

  Wählen Sie CIDR-Blöcke, die sich nicht mit einem anderen Netzwerk überschneiden (in Oracle Cloud Infrastructure, Ihrem On-Premise-Data Center oder einem anderen Cloud-Provider), in dem Sie private Verbindungen einrichten möchten.

Überlegungen

• Anwendungsdesign

  Jede Anwendung, die über eine genau definierte Datenverteilungsstrategie verfügt und hauptsächlich über einen Sharding-Schlüssel (z.B. Kunden-ID, Kontonummer usw.) auf Daten zugreift, ist für Sharded-Datenbanken geeignet.

• Skalierbarkeit

  Nach dem Deployment der Sharded-Datenbank können Sie die Anzahl der Shards erhöhen oder verringern, indem Sie den Stack bearbeiten und die Änderungen anwenden. Je nach Replikationsfaktor, den Sie beim Deployment des Stacks angeben, werden die Standby-Shards ebenfalls skaliert.

  Sie können auch die Anzahl der Shard-Direktoren skalieren.

• Sicherheit

  Geben Sie beim Deployment der Sharded-Datenbank einen SSH-Public Key an, um sichere SSH-Verbindungen mit den Datenbankservern zu ermöglichen.

• Netzwerkisolierung

  Um die Netzwerkisolation sicherzustellen, stellen Sie die Sharded-Datenbank in einem privaten Subnetz bereit. Für den administrativen Zugriff auf die Datenbankserver können Sie einen Bastionhost in einem öffentlichen Subnetz bereitstellen.

Bereitstellen

Ein Terraform-basierter Stack zur Bereitstellung dieser Referenzarchitektur ist in Oracle Cloud Marketplace verfügbar.

1. Gehen Sie zu Oracle Cloud Marketplace.
2. Klicken Sie auf App abrufen.
3. Befolgen Sie die Bildschirmanweisungen.

Mehr anzeigen

Oracle Sharding verwenden (Oracle Database 19c-Dokumentation)