Architekturen für Oracle-Datenbank auf Azure Virtual Machines

  • Artikel

Gilt für: ✔️ Linux-VMs

Dieser Artikel enthält Informationen zur Bereitstellung einer hoch verfügbaren Oracle-Datenbank in Azure. Darüber hinaus werden in diesem Leitfaden auch Aspekte der Notfallwiederherstellung beschrieben. Die in diesem Artikel beschriebenen Architekturen wurden basierend auf Kundenbereitstellungen erstellt. Der Leitfaden gilt nur für Oracle Database Enterprise Edition.

Weitere Informationen zur Steigerung der Leistung Ihrer Oracle-Datenbank finden Sie unter Entwerfen und Implementieren einer Oracle-Datenbank in Azure.

Voraussetzungen

  • Vertrautheit mit den verschiedenen Konzepten von Azure, z. B. Verfügbarkeitszonen
  • Oracle Database Enterprise Edition 12c oder höher
  • Vertrautheit mit den Lizenzierungsanforderungen für die Nutzung der Lösungen in diesem Artikel

Hochverfügbarkeit für Oracle-Datenbanken

Die Erzielung von Hochverfügbarkeit in der Cloud ist ein wichtiger Teil jeglicher Planung und Entwurfsarbeit einer Organisation. Azure bietet Verfügbarkeitszonen und Verfügbarkeitsgruppen für die Verwendung in Regionen, in denen keine Verfügbarkeitszonen verfügbar sind. Weitere Informationen zum Entwerfen für die Cloud finden Sie unter Verfügbarkeitsoptionen für Azure Virtual Machines.

Über cloudnative Tools und Angebote hinaus bietet Oracle auch Lösungen für Hochverfügbarkeit, die in Azure eingerichtet werden können:

In diesem Leitfaden werden Referenzarchitekturen für diese Lösungen beschrieben.

Beim Migrieren oder Erstellen von Anwendungen für die Cloud empfiehlt sich die Verwendung cloudnativer Muster wie Wiederholungsmustern und Trennschaltermustern. Weitere Muster, die Ihre Anwendung widerstandsfähiger machen können, finden Sie im Leitfaden zu Cloudentwurfsmustern.

Oracle RAC in der Cloud

Oracle Real Application Cluster (RAC) ist eine Lösung von Oracle, mit der Kunden einen hohen Durchsatz erzielen können, indem viele Instanzen auf einen Datenbankspeicher zugreifen. Bei diesem Muster handelt es sich um ein allgemeines Freigabemuster. Zwar kann Oracle RAC für die lokale Bereitstellung von Hochverfügbarkeit verwendet werden, allein eingesetzt kann Oracle RAC jedoch keine Hochverfügbarkeit in der Cloud bieten. Oracle RAC schützt nur vor Fehlern auf Instanzebene und nicht vor Fehlern auf Rack- oder Rechenzentrumsebene. Daher empfiehlt Oracle die Nutzung von Oracle Data Guard für Ihre Datenbank, sei es als Einzelinstanz oder RAC, um Hochverfügbarkeit bereitzustellen.

Kunden benötigen zur Ausführung ihrer unternehmenskritischen Anwendungen im Allgemeinen einen hohen Servicelevel (SLA). Oracle zertifiziert oder unterstützt Oracle RAC in Azure derzeit nicht. Azure bietet aber Features wie Verfügbarkeitszonen und geplante Wartungsfenster, um einen Schutz vor Fehlern auf Instanzebene bereitzustellen. Über diese Angebote hinaus können Sie Oracle Data Guard, Oracle GoldenGate und Oracle Sharding für hohe Leistung und Resilienz verwenden. Diese Technologien können dazu beitragen, Ihre Datenbanken vor Fehlern auf Rack-, Rechenzentrums- und geopolitischer Ebene zu schützen.

Wenn Sie Oracle Databases in mehreren Verfügbarkeitszonen mit Oracle Data Guard oder GoldenGate ausführen, können Sie ein Uptime-SLA von 99,99 % erreichen. In Azure-Regionen, in denen noch keine Verfügbarkeitszonen vorhanden sind, können Sie Verfügbarkeitsgruppen nutzen und so eine Uptime-SLA von 99,95 % erreichen.

Hinweis

Sie können ein Betriebszeitziel anstreben, das deutlich über der Betriebszeit-SLA von Microsoft liegt.

Notfallwiederherstellung für Oracle-Datenbanken

Wenn Sie Ihre unternehmenskritischen Anwendungen in der Cloud hosten, ist es wichtig, dass Sie beim Entwerfen die Hochverfügbarkeit und Notfallwiederherstellung berücksichtigen.

Für Oracle Database Enterprise Edition ist Oracle Data Guard ein nützliches Feature für die Notfallwiederherstellung. Sie können in einer gekoppelten Azure-Region eine Standbydatenbank-Instanz und ein Data Guard-Failover für die Notfallwiederherstellung einrichten. Zur vollständigen Vermeidung von Datenverlust empfehlen wir Ihnen, zusätzlich zu Active Data Guard eine Oracle Data Guard Far Sync-Instanz bereitzustellen.

Erwägen Sie, die Data Guard Far Sync-Instanz in einer anderen Verfügbarkeitszone als der für Ihre primäre Oracle-Datenbank einzurichten, wenn Ihre Anwendung die Latenz toleriert. Testen Sie die Konfiguration gründlich. Verwenden Sie den Modus für maximale Verfügbarkeit, um den synchronen Transport Ihrer Wiederholungsdateien für die Far Sync-Instanz einzurichten. Diese Dateien werden anschließend asynchron in die Standbydatenbank übertragen.

Möglicherweise lässt Ihre Anwendung den Leistungsverlust nicht zu, wenn eine Far Sync-Instanz in einer anderen Verfügbarkeitszone im Modus für maximale Verfügbarkeit (synchron) eingerichtet wird. Sollte dies der Fall sein, können Sie eine Far Sync-Instanz in derselben Verfügbarkeitszone wie Ihre primäre Datenbank einrichten. Erwägen Sie, zur Verbesserung der Verfügbarkeit mehrere Far Sync-Instanzen in der Nähe Ihrer primären Datenbank und mindestens eine Instanz in der Nähe Ihrer Standbydatenbank (für den Fall von Rollenübergängen) einzurichten.

Bei Verwendung von Oracle Standard Edition-Datenbanken sind ISV-Lösungen wie DBVisit Standby verfügbar, mit denen Sie Hochverfügbarkeit und Notfallwiederherstellung einrichten können.

Referenzarchitekturen

Oracle Data Guard

Mit Oracle Data Guard werden Hochverfügbarkeit, Schutz von Daten und Notfallwiederherstellung für Unternehmensdaten sichergestellt. Mit Data Guard werden Standbydatenbanken als transaktionskonsistente Kopien der primären Datenbank verwaltet. Je nach Entfernung zwischen den primären und sekundären Datenbanken und der Toleranz der Anwendung in Bezug auf die Latenz können Sie die synchrone oder die asynchrone Replikation einrichten. Wenn die primäre Datenbank aufgrund eines geplanten oder ungeplanten Ausfalls nicht verfügbar ist, kann Data Guard alle Standbydatenbanken auf die primäre Rolle umstellen und so die Ausfallzeit minimieren.

Bei Verwendung von Oracle Data Guard können Sie darüber hinaus Ihre sekundäre Datenbank für schreibgeschützte Vorgänge öffnen. Diese Konfiguration wird als „Active Data Guard“ bezeichnet. Mit Oracle Database 12c wurde das Feature „Data Guard Far Sync-Instanz“ eingeführt. Mit dieser Instanz können Sie für Ihre Oracle-Datenbank eine Konfiguration zur Vermeidung jeglichen Datenverlusts einrichten, ohne dass die Leistung beeinträchtigt wird.

Hinweis

Für Active Data Guard wird eine zusätzliche Lizenzierung benötigt. Diese Lizenz wird auch für die Verwendung des Far Sync-Features benötigt. Wenden Sie sich an Ihren Oracle-Vertriebspartner, um die Fragen zur Lizenzierung zu klären.

Oracle Data Guard mit Fast-Start Failover

Oracle Data Guard mit FSFO (Fast-Start Failover) kann für zusätzliche Resilienz sorgen, indem der Broker auf einem separaten Computer eingerichtet wird. Für Data Guard Broker und die sekundäre Datenbank wird jeweils das Beobachtungselement (Observer) ausgeführt und die primäre Datenbank auf Ausfallzeiten überwacht. Dieser Ansatz ermöglicht darüber hinaus zusätzliche Redundanz für Ihre Einrichtung des Data Guard-Observers.

Mit Oracle Database, Version 12.2 und höher, können Sie außerdem mit nur einer Oracle Data Guard-Brokerkonfiguration mehrere Observer konfigurieren. Mit diesem Setup erzielen Sie zusätzliche Verfügbarkeit, falls es bei einem Observer und der sekundären Datenbank zu Ausfallzeiten kommt. Data Guard Broker ist nicht umfangreich und kann auf einem relativ kleinen virtuellen Computer gehostet werden. Weitere Informationen zu Data Guard Broker und seinen Vorteilen finden Sie unter Oracle Data Guard Broker: Konzepte.

Das folgende Diagramm zeigt eine empfohlene Architektur für die Verwendung von Oracle Data Guard in Azure mit Verfügbarkeitszonen. Mit dieser Architektur können Sie für die VM eine Betriebszeit-SLA von 99,99 % erzielen.

Diagramm einer empfohlenen Architektur für die Verwendung von Oracle Data Guard in Azure mit Verfügbarkeitszonen

Im vorstehenden Diagramm greift das Clientsystem über das Web per Oracle-Back-End auf eine benutzerdefinierte Anwendung zu. Das Web-Front-End ist in einem Lastenausgleichsmodul konfiguriert. Zur Verarbeitung sendet das Web-Front-End einen Aufruf an den entsprechenden Anwendungsserver. Der Anwendungsserver fragt die primäre Oracle-Datenbank ab. Die Oracle-Datenbank wurde mit einer arbeitsspeicheroptimierten Hyperthread-VM mit vCPUs mit eingeschränkten Kerngrößen konfiguriert, um Lizenzierungskosten zu sparen und die Leistung zu steigern. Es werden mehrere Premium/Ultra Disks (Managed Disks) verwendet, um die Leistung zu steigern und Hochverfügbarkeit zu erzielen.

Die Oracle-Datenbanken werden in mehreren Verfügbarkeitszonen angeordnet, um für Hochverfügbarkeit zu sorgen. Jede Zone besteht aus mindestens einem Rechenzentrum, dessen Stromversorgung, Kühlung und Netzwerkbetrieb unabhängig funktionieren. Zur Sicherstellung der Resilienz sind in allen aktivierten Regionen mindestens drei separate Zonen vorhanden. Die physische Trennung von Verfügbarkeitszonen innerhalb einer Region schützt die Daten vor Ausfällen von Rechenzentren. Darüber hinaus werden über zwei Verfügbarkeitszonen hinweg zwei FSFO-Observer eingerichtet, um die Datenbank zu initiieren und ein Failover zur sekundären Datenbank auszuführen, wenn es zu einem Ausfall kommt.

Sie können weitere Observer bzw. Standbydatenbanken in einer anderen Verfügbarkeitszone (hier Verfügbarkeitszone 1) als der Zone einrichten, die in der vorherigen Architektur dargestellt ist. Schließlich überwacht Oracle Enterprise Manager (OEM) Oracle-Datenbanken im Hinblick auf Uptime und Leistung. Mit OEM können Sie auch verschiedene Leistungs- und Nutzungsberichte generieren.

In Regionen, in denen Verfügbarkeitszonen nicht unterstützt werden, können Sie Verfügbarkeitsgruppen nutzen, um Ihre Oracle-Datenbank mit Hochverfügbarkeit bereitzustellen. Mit Verfügbarkeitsgruppen können Sie eine VM-Betriebszeit von 99,95 % erzielen. Das folgende Diagramm zeigt eine Referenzarchitektur dieser Vorgehensweise:

Diagramm, das die Verwendung von Verfügbarkeitsgruppen mit Data Guard Broker (FSFO) für Oracle Database zeigt.

Hinweis

  • Da nur eine Instanz von OEM bereitgestellt wird, müssen Sie die Oracle Enterprise Manager-VM nicht in einer Verfügbarkeitsgruppe platzieren.
  • Ultra Disks werden in einer Verfügbarkeitsgruppen-Konfiguration derzeit nicht unterstützt.

Oracle Data Guard Far Sync

Oracle Data Guard Far Sync ermöglicht für Oracle-Datenbanken eine Schutzfunktion ohne jeglichen Datenverlust. Diese Funktion ermöglicht einen Schutz vor Datenverlust, wenn auf Ihrem Datenbankcomputer ein Fehler auftritt. Oracle Data Guard Far Sync muss auf einer separaten VM installiert werden. Far Sync ist eine einfache Oracle-Instanz, die nur über eine Steuerdatei, Kennwortdatei, spfile und Standbyprotokolle verfügt. Es sind keine Datendateien oder Wiederholungsprotokolldateien vorhanden.

Für den vollständigen Schutz vor Datenverlust muss eine synchrone Kommunikation zwischen Ihrer primären Datenbank und der Far Sync-Instanz erfolgen. Die Far Sync-Instanz empfängt von der primären Datenbank auf synchrone Weise eine Wiederholungsaufforderung und leitet diese sofort asynchron an alle Standbydatenbanken weiter. Bei diesem Setup wird auch der Mehraufwand für die primäre Datenbank reduziert, weil die Wiederholungsanforderung nur an die Far Sync-Instanz gesendet werden muss, anstatt an alle Standbydatenbanken. Wenn für eine Far Sync-Instanz ein Fehler auftritt, nutzt Data Guard automatisch den asynchronen Transport von der primären zur sekundären Datenbank, um nahezu datenverlustfreien Schutz zu ermöglichen. Zur Verbesserung der Resilienz können Kunden mehrere Far Sync-Instanzen pro Datenbankinstanz bereitstellen, einschließlich primärer und sekundärer.

Im folgenden Diagramm ist eine Hochverfügbarkeitsarchitektur mit Oracle Data Guard Far Sync dargestellt:

Diagramm, das die Verwendung von Verfügbarkeitszonen mit Data Guard Far Sync und Broker (FSFO) für Oracle Database zeigt.

In der vorherigen Architektur wird eine Far Sync-Instanz in einer anderen Verfügbarkeitszone als die Datenbankinstanz bereitgestellt, um im Falle eines Ausfalls der Verfügbarkeitszone Null Datenverlust und automatisches Failover sicherzustellen. In Fällen, in denen die Anwendung latenzempfindlich ist, sollten Sie in Erwägung ziehen, Ihre Datenbank und die Far Sync-Instanz(en) in derselben Verfügbarkeitszone in einer Näherungsplatzierungsgruppe bereitzustellen.

Im folgenden Diagramm ist eine Architektur dargestellt, in der Oracle Data Guard FSFO und Far Sync eingesetzt werden, um Hochverfügbarkeit und Notfallwiederherstellung bereitzustellen:

Diagramm, das die Verwendung von Verfügbarkeitszonen für die Notfallwiederherstellung mit Data Guard Far Sync und Broker (FSFO) für Oracle Database zeigt.

Oracle GoldenGate

Mit GoldenGate können Sie Daten auf Transaktionsebene für mehrere heterogene Plattformen eines Unternehmens austauschen und bearbeiten. Mit der Anwendung werden Transaktionen, für die ein Commit ausgeführt wurde, unter Bewahrung der Transaktionsintegrität und mit minimalem Aufwand für Ihre vorhandene Infrastruktur verschoben. Aufgrund der modularen Architektur können Sie ausgewählte Datensätze, Transaktionsänderungen und DDL-Änderungen (Datenbeschreibungssprache) für viele verschiedene Topologien flexibel extrahieren und replizieren.

Mit Oracle GoldenGate können Sie Ihre Datenbank für Hochverfügbarkeit konfigurieren, indem Sie die bidirektionale Replikation einrichten. Dieser Ansatz ermöglicht es Ihnen, eine Konfiguration vom Typ Multimaster oder Aktiv/Aktiv einzurichten. Das folgende Diagramm zeigt eine empfohlene Architektur für die Einrichtung des Aktiv/Aktiv-Modus in Azure. In der folgenden Architektur wurde die Oracle-Datenbank mit einer arbeitsspeicheroptimierten Hyperthread-VM mit vCPUs mit eingeschränkten Kerngrößen konfiguriert, um Lizenzierungskosten zu sparen und die Leistung zu steigern. Die Architektur verwendet mehrere Premium-Datenträger bzw. Ultra Disks (Verwaltete Datenträger), um eine gute Leistung und Verfügbarkeit zu erzielen.

Diagramm, das die Verwendung von Verfügbarkeitszonen mit Data Guard Broker (FSFO) für Oracle Database zeigt.

Hinweis

Eine ähnliche Architektur kann mit Verfügbarkeitsgruppen in Regionen eingerichtet werden, in denen derzeit keine Verfügbarkeitszonen verfügbar sind.

Oracle GoldenGate verfügt über Prozesse vom Typ Extract, Pump und Replicat, mit denen Sie Ihre Daten asynchron von einem Oracle-Datenbankserver auf einem anderen replizieren können. Mit diesen Prozessen können Sie eine bidirektionale Replikation einrichten, um für Ihre Datenbank Hochverfügbarkeit zu erzielen, falls es auf der Ebene der Verfügbarkeitszone zu Ausfällen kommt.

Im vorstehenden Diagramm wird der Extract-Prozess auf demselben Server wie Ihre Oracle-Datenbank ausgeführt. Die Data Pump- und Replicat-Prozesse werden auf einem separaten Server in derselben Verfügbarkeitszone ausgeführt. Der Prozess „Replicat“ wird verwendet, um Daten aus der Datenbank in der anderen Verfügbarkeitszone zu empfangen und die Daten für die Oracle-Datenbank in der zugehörigen Verfügbarkeitszone zu committen. Entsprechend werden beim Data Pump-Prozess Daten, die mit dem Extract-Prozess extrahiert wurden, an den Replicat-Prozess in der anderen Verfügbarkeitszone gesendet.

Im obigen Architekturdiagramm sind die Prozesse „Data Pump“ und „Replicat“ zwar auf einem separaten Server konfiguriert, jedoch können Sie alle Oracle GoldenGate-Prozesse auch auf demselben Server einrichten – je nach Kapazität und Nutzung Ihres Servers. Ziehen Sie immer Ihren AWR-Bericht und die Metriken in Azure zurate, um die Nutzungsmuster Ihres Servers zu verstehen.

Beim Einrichten der bidirektionalen Oracle GoldenGate-Replikation in unterschiedlichen Verfügbarkeitszonen oder Regionen sollten Sie unbedingt sicherstellen, dass die Latenz zwischen den einzelnen Komponenten für Ihre Anwendung akzeptabel ist. Die Latenz zwischen Verfügbarkeitszonen und Regionen kann variieren. Latenz hängt von mehreren Faktoren ab. Wir empfehlen Ihnen, Leistungstests zwischen Ihrer Anwendungs- und Datenbankschicht in unterschiedlichen Verfügbarkeitszonen bzw. Regionen einzurichten. Durch diese Tests kann bestätigt werden, dass die Konfiguration die Leistungsanforderungen Ihrer Anwendung erfüllt.

Die Anwendungsebene kann in einem eigenen Subnetz eingerichtet werden, und die Datenbankebene kann ebenfalls in einem eigenen Subnetz abgetrennt werden. Erwägen Sie, nach Möglichkeit Azure Application Gateway für einen Lastenausgleich des Datenverkehrs zwischen Ihren Anwendungsservern zu verwenden. Bei Application Gateway handelt es sich um ein stabiles Lastenausgleichsmodul für Webdatenverkehr. Es ermöglicht eine cookiebasierte Sitzungsaffinität, bei der eine Benutzersitzung auf demselben Server verbleibt, wodurch Konflikte für die Datenbank minimiert werden. Alternativen zu Application Gateway sind Azure Load Balancer und Azure Traffic Manager.

Oracle Sharding

Sharding ist ein Datenebenenmuster, das mit Oracle 12.2 eingeführt wurde. Mit diesem Verfahren können Sie Ihre Daten für unabhängige Datenbanken horizontal partitionieren und skalieren. Es handelt sich um eine Share-Nothing-Architektur (Architektur ohne Freigaben), bei der jede Datenbank auf einem dedizierten virtuellen Computer gehostet wird. Dieses Muster ermöglicht neben Resilienz und erhöhter Verfügbarkeit einen hohen Lese- und Schreibdurchsatz.

Bei diesem Muster werden Single Points of Failure beseitigt, und die Isolation von Fehlern wird ermöglicht. Außerdem können parallele Upgrades ohne Ausfallzeiten durchgeführt werden. Die Ausfallzeit aufgrund eines Ausfalls auf Shard- oder Rechenzentrumsebene hat keine Auswirkung auf die Leistung oder Verfügbarkeit der Shards in anderen Rechenzentren.

Sharding ist für OLTP-Anwendungen mit hohem Durchsatz geeignet, für die keine Ausfallzeiten auftreten dürfen. Alle Zeilen mit dem gleichen Shardschlüssel befinden sich jederzeit garantiert auf demselben Shard. Durch diese Tatsache erhöht sich die Leistung, und es wird hohe Konsistenz geboten. Anwendungen, die Sharding verwenden, müssen ein klar definiertes Datenmodell und eine Strategie für die Datenverteilung aufweisen, z. B. konsistenter Hash, Bereich, Liste oder Komposit. Bei der Strategie erfolgt der Datenzugriff in erster Linie über einen Shardschlüssel, etwa customerId oder accountNum. Beim Sharding können bestimmte Gruppen von Daten auch näher an den Endkunden gespeichert werden, damit Ihre Anforderungen an Leistung und Konformität leichter erfüllt werden können.

Wir empfehlen Ihnen, Ihre Shards zu replizieren, um Hochverfügbarkeit und Notfallwiederherstellung zu ermöglichen. Sie können diese Einrichtung mit Oracle-Technologie wie Oracle Data Guard oder Oracle GoldenGate durchführen. Bei einer Replikationseinheit kann es sich um einen Shard, einen Teil eines Shards oder eine Gruppe mit Shards handeln. Ein Ausfall oder eine Verlangsamung eines oder mehrerer Shards wirkt sich nicht auf die Verfügbarkeit einer Datenbank mit Sharding aus.

Zur Erzielung von Hochverfügbarkeit können die Standby-Shards in derselben Verfügbarkeitszone angeordnet werden, in der sich auch die primären Shards befinden. Für die Notfallwiederherstellung können die Standby-Shards in einer anderen Region angeordnet werden. Sie können Shards auch in mehreren Regionen bereitstellen, um Datenverkehr in diesen Regionen zu bedienen. Weitere Informationen zum Konfigurieren von Hochverfügbarkeit und Replikation Ihrer Sharddatenbank finden Sie unter Hochverfügbarkeit auf Shardebene.

Oracle Sharding umfasst hauptsächlich die folgenden Komponenten: Weitere Informationen finden Sie unter Übersicht zu Sharding mit Oracle:

  • Shardkatalog. Spezielle Oracle-Datenbank, die als beständiger Speicher für alle Konfigurationsdaten einer Sharddatenbank dient. Alle Konfigurationsänderungen, z. B. das Hinzufügen oder Entfernen von Shards, das Zuordnen der Daten sowie die DDLS in einer Sharddatenbank, werden über den Shardkatalog initiiert. Zudem enthält der Shard-Katalog auch die primäre Kopie aller duplizierten Tabellen in einer SDB.

    Im Shardkatalog werden materialisierte Sichten verwendet, um Änderungen für alle Shards automatisch in duplizierten Tabellen zu replizieren. Die Shardkatalog-Datenbank fungiert auch als Abfragekoordinator, der zum Verarbeiten von Abfragen für mehrere Shards und Abfragen ohne Angabe eines Shardschlüssels dient.

    Wir empfehlen als bewährte Methode die Verwendung von Oracle Data Guard in Verbindung mit Verfügbarkeitszonen oder Verfügbarkeitsgruppen für die Hochverfügbarkeit des Shardkatalogs. Die Verfügbarkeit des Shardkatalogs hat keine Auswirkung auf die Verfügbarkeit der Sharddatenbank. Eine Ausfallzeit im Shardkatalog wirkt sich auf Wartungsvorgänge und Abfragen mit mehreren Shards nur während des kurzen Zeitraums aus, in dem das Data Guard-Failover abgeschlossen wird. Die SDB leitet Onlinetransaktionen nach wie vor weiter und führt sie aus. Ein Katalogausfall wirkt sich nicht auf sie aus.

  • Shard-Direktoren. Einfache Dienste, die in jeder Region bzw. Verfügbarkeitszone bereitgestellt werden müssen, in der Ihre Shards angeordnet sind. Bei Shard Directors handelt es sich um so genannte Global Service Manager (GSM), die im Rahmen von Oracle Sharding bereitgestellt werden. Zur Erzielung von Hochverfügbarkeit empfehlen wir Ihnen, in jeder Verfügbarkeitszone, in der Ihre Shards enthalten sind, mindestens einen Shard-Direktor bereitzustellen.

    Beim anfänglichen Herstellen einer Verbindung mit der Datenbank richtet der Shard-Direktor die Routinginformationen ein und speichert die Informationen für nachfolgende Anforderungen zwischen, die den Shard-Direktor umgehen. Nachdem die Sitzung mit einem Shard eingerichtet wurde, werden alle SQL-Abfragen und DMLs unterstützt und im Bereich des jeweiligen Shards ausgeführt. Dieses Routing ist schnell und wird für alle OLTP-Workloads verwendet, für die shardinterne Transaktionen durchgeführt werden. Wir empfehlen Ihnen, für alle OLTP-Workloads, für die höchste Ansprüche an Leistung und Verfügbarkeit gelten, direktes Routing zu verwenden. Der Routingcache wird automatisch aktualisiert, wenn ein Shard nicht verfügbar ist oder Änderungen an der Shardingtopologie vorgenommen werden.

    Für das datenabhängige Routing mit hoher Leistung empfiehlt Oracle die Verwendung eines Verbindungspools, wenn auf Daten in der Sharddatenbank zugegriffen wird. Für Oracle-Verbindungspools, sprachspezifische Bibliotheken und Treiber wird Oracle Sharding unterstützt. Weitere Informationen finden Sie unter Übersicht zu Sharding mit Oracle.

  • Globaler Dienst. Der globale Dienst ähnelt dem gewöhnlichen Datenbankdienst. Über alle Eigenschaften eines Datenbankdiensts hinaus weist ein globaler Dienst Eigenschaften von Sharddatenbanken auf. Zu diesen Eigenschaften zählen die Regionsaffinität zwischen Clients und die Toleranz für Shard- und Replikationsverzögerung. Es muss nur ein globaler Dienst erstellt werden, damit Daten aus einer Sharddatenbank gelesen bzw. in sie geschrieben werden können. Bei Verwendung von Active Data Guard und der Einrichtung von schreibgeschützten Replikaten der Shards können Sie einen weiteren globalen Dienst für schreibgeschützte Workloads erstellen. Der Client kann diese globalen Dienste verwenden, um eine Verbindung mit der Datenbank herzustellen.

  • Sharddatenbanken. Sharddatenbanken sind Ihre Oracle-Datenbanken. Jede Datenbank wird mithilfe von Oracle Data Guard in einer Brokerkonfiguration mit aktiviertem FSFO repliziert. Sie müssen das Data Guard-Failover und die Replikation nicht für jeden Shard einrichten. Dieser Aspekt wird beim Erstellen der Sharddatenbank automatisch konfiguriert und bereitgestellt. Wenn ein bestimmter Shard ausfällt, wird von Oracle Sharing ein Failover der Datenbankverbindungen von der primären zur Standbydatenbank ausgeführt.

Sie können Oracle-Sharddatenbanken mit zwei Oberflächen bereitstellen und verwalten: Oracle Enterprise Manager Cloud Control GUI und das GDSCTL-Befehlszeilen-Hilfsprogramm. Per Cloud Control haben Sie sogar die Möglichkeit, die unterschiedlichen Shards auf Verfügbarkeit und Leistung zu überwachen. Mit dem Befehl GDSCTL DEPLOY werden die Shards und die zugehörigen Listener automatisch erstellt. Außerdem wird mit diesem Befehl automatisch die Replikationskonfiguration bereitgestellt, die für die vom Administrator angegebene Hochverfügbarkeit auf Shardebene verwendet wird.

Es gibt verschiedene Möglichkeiten, Shards für eine Datenbank einzurichten:

  • Vom System verwaltetes Sharding: Wird per Partitionierung automatisch auf die Shards verteilt
  • Benutzerdefiniertes Sharding: Ermöglicht Ihnen das Angeben der Zuordnung der Daten zu den Shards. Dies funktioniert gut, falls gesetzliche Anforderungen oder Lokalisierungsanforderungen für Daten erfüllt werden müssen
  • Zusammengesetztes Sharding: Dies ist eine Kombination aus vom System verwaltetem und benutzerdefiniertem Sharding für verschiedene Shardspaces
  • Tabellenunterpartitionen: Diese ähneln einer gewöhnlichen partitionierten Tabelle

Weitere Informationen finden Sie unter Shardingverfahren.

Eine Sharddatenbank sieht für Anwendungen und Entwickler wie eine Einzeldatenbank aus. Planen Sie bei der Migration zu einer Sharddatenbank sorgfältig, um genau zu verstehen, welche Tabellen dupliziert anstatt horizontal partitioniert („sharded“) werden.

Duplizierte Tabellen werden auf allen Shards gespeichert, während Shardtabellen auf unterschiedliche Shards verteilt werden. Wir empfehlen Ihnen, kleinere und Dimensionstabellen zu duplizieren und die Faktentabellen zu verteilen bzw. horizontal zu partitionieren. Sie können die Daten in Ihre Sharddatenbank laden, indem Sie entweder den Shardkatalog als zentrales Koordinierungstool verwenden oder für jeden Shard den Prozess „Data Pump“ ausführen. Weitere Informationen finden Sie unter Migrieren von Daten zu einer Sharddatenbank.

Oracle Sharding mit Data Guard

Oracle Data Guard kann für das Sharding mit vom System verwalteten, benutzerdefinierten und zusammengesetzten Shardingverfahren verwendet werden.

Das folgende Diagramm zeigt eine Referenzarchitektur für Oracle Sharding mit Oracle Data Guard, um für jeden Shard Hochverfügbarkeit zu erzielen. Im Architekturdiagramm ist ein Verfahren für zusammengesetztes Sharding dargestellt. Das Architekturdiagramm unterscheidet sich wahrscheinlich für Anwendungen, die unterschiedliche Anforderungen in Bezug auf Datenlokalität, Lastenausgleich, Hochverfügbarkeit und Notfallwiederherstellung aufweisen. Anwendungen können verschiedene Verfahren für das Sharding verwenden. Mit Oracle Sharding können Sie diese Anforderungen erfüllen und effizient horizontal skalieren, indem Sie diese Optionen bereitstellen. Sie können eine ähnliche Architektur auch mit Oracle GoldenGate bereitstellen.

Diagramm, das die Verwendung von Verfügbarkeitszonen mit Data Guard Broker (FSFO) für Oracle Database Sharding zeigt.

Vom System verwaltetes Sharding ist am einfachsten zu konfigurieren und zu verwalten. Benutzerdefiniertes Sharding oder zusammengesetztes Sharding eignet sich gut für Szenarien, in denen Ihre Daten und Anwendungen geografisch weit verteilt sind oder in denen Sie die Kontrolle über die Replikation jedes einzelnen Shards haben müssen.

In der obigen Architektur wird das zusammengesetzte Sharding verwendet, um die Daten geografisch zu verteilen und Ihre Anwendungsebenen horizontal hochzuskalieren. Beim zusammengesetzten Sharding wird eine Kombination aus vom System verwaltetem und benutzerdefiniertem Sharding genutzt, sodass Sie in den Genuss der Vorteile beider Verfahren kommen. Im obigen Szenario wird für Daten zuerst das Sharding in mehreren Shardspaces durchgeführt, die nach Region getrennt sind. Anschließend werden die Daten mithilfe eines konsistenten Hashs für mehrere Shards im Shardspace weiter partitioniert.

Jeder Shardspace enthält mehrere Shardgroups. Jede Shardgroup weist mehrere Shards auf und stellt eine Replikationseinheit dar. Jede Shardgroup enthält alle Daten des Shardspace. Die Shardgroups A1 und B1 sind primäre Shardgroups, und bei A2 und B2 handelt es sich um Standbygruppen. Sie können sich entscheiden, dass einzelne Shards anstelle einer Shardgroup als Replikationseinheit fungieren sollen.

In der oben dargestellten Architektur wird in jeder Verfügbarkeitszone ein globaler Service Manager (GSM) bzw. Shard-Direktor bereitgestellt, um Hochverfügbarkeit zu erzielen. Wir empfehlen Ihnen, mindestens einen GSM/Shard-Direktor pro Rechenzentrum bzw. Region bereitzustellen. Zusätzlich wird in jeder Verfügbarkeitszone, die eine Shardgroup enthält, eine Instanz des Anwendungsservers bereitgestellt. Diese Einrichtung ermöglicht es, die Latenz zwischen dem Anwendungsserver und der Datenbank bzw. Shardgroup gering zu halten. Wenn für eine Datenbank ein Fehler auftritt, kann der Anwendungsserver in derselben Zone wie die Standbydatenbank Anforderungen verarbeiten, nachdem der Übergang der Datenbankrolle erfolgt ist. Mit Azure Application Gateway und dem Shard Director wird die Latenz der Anforderungen und Antworten nachverfolgt, und Anforderungen werden entsprechend weitergeleitet.

Aus Sicht der Anwendung sendet das Clientsystem eine Anforderung an Azure Application Gateway oder eine andere Technologie für den Lastenausgleich in Azure, von wo aus diese dann an die Region umgeleitet wird, die dem Client am nächsten ist. Von Azure Application Gateway werden auch beständige Sitzungen (Sticky Sessions) unterstützt. Alle Anforderungen, die von demselben Client stammen, werden an denselben Anwendungsserver weitergeleitet. Der Anwendungsserver verwendet das Verbindungspooling über Treiber für den Datenzugriff. Dieses Feature ist für Treiber wie JDBC, ODP.NET und OCI verfügbar. Die Treiber können Shardschlüssel erkennen, die im Rahmen der Anforderung angegeben werden. Mit Oracle Universal Connection Pool (UCP) für JDBC-Clients können nicht von Oracle stammende Anwendungsclients, z. B. Apache Tomcat und IIS, für die Zusammenarbeit mit Oracle Sharding aktiviert werden. Weitere Informationen finden Sie unter Overview of UCP Shared Pool for Database Sharding (Übersicht zum gemeinsamen UCP-Pool für Sharddatenbanken).

Während der ersten Anforderung stellt der Anwendungsserver eine Verbindung mit dem Shard Director in der zugehörigen Region her, um Routinginformationen für den Shard abzurufen, an den die Anforderung weitergeleitet werden muss. Basierend auf dem übergebenen Shardschlüssel leitet der Director den Anwendungsserver an den entsprechenden Shard weiter. Der Anwendungsserver speichert diese Informationen zwischen, indem er eine Zuordnung erstellt. Für nachfolgende Anforderungen wird der Shard Director umgangen, und Anforderungen werden direkt an den Shard weitergeleitet.

Oracle Sharding mit GoldenGate

Das folgende Diagramm zeigt eine Referenzarchitektur für Oracle Sharding mit Oracle GoldenGate, um für jeden Shard regionsinterne Hochverfügbarkeit zu erzielen. Im Gegensatz zur vorhergehenden Architektur wird Hochverfügbarkeit bei dieser Architektur nur innerhalb einer Azure-Region mit mehreren Verfügbarkeitszonen dargestellt. Ähnlich wie im Beispiel oben können Sie mit Oracle GoldenGate eine Sharddatenbank mit mehreren Regionen bereitstellen, die auf Hochverfügbarkeit ausgelegt ist.

Diagramm, das Oracle Database Sharding mit Verfügbarkeitszonen per GoldenGate zeigt.

In der obigen Referenzarchitektur wird das vom System verwaltete Shardverfahren genutzt, um das Sharding für die Daten durchzuführen. Da die Oracle GoldenGate-Replikation auf Blockebene erfolgt, kann die Hälfte der Daten, für die die Replikation durchgeführt werden soll, auf einem ersten Shard repliziert werden. Die andere Hälfte kann dann auf einem anderen Shard repliziert werden.

Die Art und Weise, wie die Daten repliziert werden, hängt vom Replikationsfaktor ab. Bei einem Replikationsfaktor von zwei verfügen Sie über zwei Kopien jedes Datenblocks für Ihre drei Shards der Shardgroup. Bei einem Replikationsfaktor von drei und drei Shards in der Shardgroup werden alle Daten jedes Shards jeweils auf jeden anderen Shard der Shardgroup repliziert. Jeder Shard der Shardgroup kann einen anderen Replikationsfaktor aufweisen. Mit dieser Einrichtung können Sie Ihren Entwurf zur Erzielung von Hochverfügbarkeit und Notfallwiederherstellung in einer Shardgroup und über mehrere Shardgroups hinweg effizient definieren.

In der obigen Architektur enthalten Shardgroup A und Shardgroup B die gleichen Daten, aber sie sind in unterschiedlichen Verfügbarkeitszonen angeordnet. Wenn sowohl Shardgroup A als auch Shardgroup B den Replikationsfaktor drei aufweist, wird jede Zeile bzw. jeder Block Ihrer Shardtabelle für die beiden Shardgroups sechsmal repliziert. Wenn Shardgroup A den Replikationsfaktor drei und Shardgroup B den Replikationsfaktor zwei aufweist, wird jede Zeile bzw. jeder Block für die beiden Shardgroups fünfmal repliziert.

Mit dieser Einrichtung kann Datenverlust verhindert werden, wenn auf Instanzebene oder Verfügbarkeitszonenebene ein Fehler auftritt. Die Anwendungsschicht kann für jeden Shard Lese- und Schreibvorgänge durchführen. Zur Verringerung von Konflikten weist Oracle Sharding für jeden Hashwertbereich einen Masterblock zu. Mit dieser Funktion wird sichergestellt, dass Schreibanforderungen für einen bestimmten Block an den entsprechenden Block weitergeleitet werden. Darüber hinaus bietet Oracle GoldenGate eine Funktion zum automatischen Erkennen und Lösen von Konflikten, um eventuell auftretende Konflikte zu behandeln. Weitere Informationen und Einschränkungen bei der Implementierung von GoldenGate mit Oracle Sharding finden Sie unter Verwenden von Oracle GoldenGate mit einer Sharddatenbank.

In der obigen Architektur wird in jeder Verfügbarkeitszone ein GSM/Shard Director bereitgestellt, um Hochverfügbarkeit zu erzielen. Wir empfehlen Ihnen, mindestens einen GSM/Shard-Direktor pro Rechenzentrum oder Region bereitzustellen. In jeder Verfügbarkeitszone, die eine Shardgroup enthält, wird eine Instanz des Anwendungsservers bereitgestellt. Diese Einrichtung ermöglicht es, die Latenz zwischen dem Anwendungsserver und der Datenbank bzw. Shardgroup gering zu halten. Wenn für eine Datenbank ein Fehler auftritt, kann der Anwendungsserver in derselben Zone wie die Standbydatenbank Anforderungen verarbeiten, nachdem der Übergang der Datenbankrolle erfolgt ist. Mit Azure Application Gateway und dem Shard Director wird die Latenz der Anforderungen und Antworten nachverfolgt, und Anforderungen werden entsprechend weitergeleitet.

Aus Sicht der Anwendung sendet das Clientsystem eine Anforderung an Azure Application Gateway oder eine andere Technologie für den Lastenausgleich in Azure, von wo aus diese dann an die Region umgeleitet wird, die dem Client am nächsten ist. Von Azure Application Gateway werden auch beständige Sitzungen (Sticky Sessions) unterstützt. Alle Anforderungen, die von demselben Client stammen, werden an denselben Anwendungsserver weitergeleitet. Der Anwendungsserver verwendet das Verbindungspooling über Treiber für den Datenzugriff. Dieses Feature ist für Treiber wie JDBC, ODP.NET und OCI verfügbar. Die Treiber können Shardschlüssel erkennen, die im Rahmen der Anforderung angegeben werden. Mit Oracle Universal Connection Pool (UCP) für JDBC-Clients können nicht von Oracle stammende Anwendungsclients, z. B. Apache Tomcat und IIS, für die Zusammenarbeit mit Oracle Sharding aktiviert werden.

Während der ersten Anforderung stellt der Anwendungsserver eine Verbindung mit dem Shard Director in der zugehörigen Region her, um Routinginformationen für den Shard abzurufen, an den die Anforderung weitergeleitet werden muss. Basierend auf dem übergebenen Shardschlüssel leitet der Director den Anwendungsserver an den entsprechenden Shard weiter. Der Anwendungsserver speichert diese Informationen zwischen, indem er eine Zuordnung erstellt. Für nachfolgende Anforderungen wird der Shard Director umgangen, und Anforderungen werden direkt an den Shard weitergeleitet.

Patchen und Wartung

Beim Bereitstellen Ihrer Oracle-Workloads in Azure übernimmt Microsoft das gesamte Patchen auf der Ebene des Hostbetriebssystems. Microsoft kommuniziert alle geplanten Wartungen auf Betriebssystemebene im Voraus an Kunden. Zwei Server aus zwei verschiedenen Verfügbarkeitszonen werden niemals zur gleichen Zeit gepatcht. Weitere Informationen zur Wartung und zum Patchen von VMs finden Sie unter Verfügbarkeitsoptionen für Azure Virtual Machines.

Das Patchen des Betriebssystems Ihres virtuellen Computers kann mit der Updateverwaltung von Azure Automation automatisiert werden. Das Patchen und Warten Ihrer Oracle-Datenbank kann mit Azure Pipelines oder der Updateverwaltung von Azure Automation automatisiert und geplant werden, um das Auftreten von Ausfallzeiten zu minimieren. Weitere Informationen zu Continuous Delivery und Blau-Grün-Bereitstellungen finden Sie unter Progressive Expositionstechniken.

Architektur- und Entwurfsaspekte

  • Erwägen Sie den Einsatz einer arbeitsspeicheroptimierten Hyperthread-VM mit vCPUs mit eingeschränkten Kerngrößen für Ihre Oracle Database-VM, um Lizenzierungskosten zu sparen und die Leistung zu steigern. Verwenden Sie mehrere Premium-Datenträger bzw. Ultra Disks (Managed Disks), um eine gute Leistung und Verfügbarkeit zu erzielen.
  • Wenn Sie verwaltete Datenträger verwenden, kann sich der Datenträger-/Gerätename beim Neustart ändern. Wir empfehlen Ihnen, anstelle des Namens die Geräte-UUID zu verwenden, um sicherzustellen, dass Ihre Bereitstellungen über Neustartvorgänge hinweg beibehalten werden. Weitere Informationen finden Sie unter Hinzufügen des neuen Dateisystems zu /etc/fstab.
  • Verwenden Sie Verfügbarkeitszonen, um für eine Region Hochverfügbarkeit zu erzielen.
  • Verwenden Sie ggf. Ultra Disks (falls verfügbar) oder Premium-Datenträger für Ihre Oracle-Datenbank.
  • Erwägen Sie, mit Oracle Data Guard eine Oracle-Standbydatenbank in einer anderen Azure-Region einzurichten.
  • Erwägen Sie den Einsatz von Näherungsplatzierungsgruppen, um die Latenz zwischen Ihrer Anwendungs- und Datenbankebene zu reduzieren.
  • Die maximale Netzwerkbandbreite von Azure-VMs ist (in der Regel) höher als der maximale Datenträgerdurchsatz auf derselben SKU. Sie können einen höheren Durchsatz auf derselben VM-SKU erzielen oder eine kleinere VM-SKU verwenden, indem Sie leistungsstarken Netzwerkspeicher mit geringer Latenz wie Azure NetApp-Dateienverwenden. für die Datenbank.
  • Richten Sie Oracle Enterprise Manager für die Verwaltung, Überwachung und Protokollierung ein.
  • Erwägen Sie, Oracle Automatic Storage Management zu verwenden, um eine optimierte Speicherverwaltung für Ihre Datenbank zu ermöglichen.
  • Nutzen Sie Azure Pipelines, um das Patchen und Updates für Ihre Datenbank ohne Ausfallzeiten zu verwalten.
  • Optimieren Sie Ihren Anwendungscode, um cloudnative Muster hinzuzufügen, mit denen sich die Resilienz Ihrer Anwendung möglicherweise steigern lässt. Berücksichtigen Sie Muster wie Wiederholungsmuster, Trennschaltermuster und andere, die im Leitfaden für Cloudentwurfsmuster definiert sind.

Nächste Schritte

Lesen Sie die folgenden Oracle-Referenzartikel, die für Ihr Szenario zutreffen.