Architekturen für Oracle-Datenbank auf Azure Virtual Machines

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. Diese 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
• Definierte RPO- und RTO-Anforderungen

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:

• Oracle Data Guard
• Data Guard mit FSFO
• Sharding
• GoldenGate

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.

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.

Für die Datenreplikation über große Entfernungen empfiehlt sich der Einsatz von Far Sync. Far Sync ist ein Feature von Oracle Active Data Guard.

Oracle Far Sync behebt die große Entfernung zwischen der primären und der sekundären Datenbank durch die Einführung eines Zwischenservers, der als Far Sync Instanz bezeichnet wird. Dieser Server empfängt Redo-Daten von der primären Datenbank und leitet sie dann an die Standbydatenbank weiter. Dabei wird die Far-Sync-Instanz näher an der Primärinstanz platziert, um die Kommunikationszeit zu verkürzen. Der Far Sync-Server überträgt dann die Redo-Daten asynchron an die sekundäre Datenbank.

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.

Oracle Data Guard mit Fast-Start Failover

Data Guard kann mithilfe von Fast Start Failover (FSFO) bereitgestellt werden. Fast-Start-Failover ist ein Feature, das in der Data Guard Broker-Konfiguration bereitgestellt wird. Mit diesem Feature können Sie bei einem Fehler Failover automatisch durchführen. Die Standardzeit, die Kunden verwenden, beträgt 30 Sekunden, kann jedoch an Ihre Anforderungen angepasst werden. Dieses sogenannte „OperationTimeout“ ist Teil der Data Guard-Eigenschaften, die Sie während der Bereitstellung definieren.

Funktionsweise von Data Guard mit dieser Eigenschaft

Die Aufgabe von Data Guards besteht darin, die Integrität und den Status der primären und sekundären Datenbank kontinuierlich zu überwachen. Sobald Sie Fast-Start-Failover (FSFO) aktivieren, wird der Beobachterprozess ausgelöst und überprüft den Integritätsstatus in regelmäßigen Abständen, um eine hohe Verfügbarkeit zu jedem bestimmten Zeitpunkt sicherzustellen.

Wenn die primäre Datenbank nun nicht deaktiviert wird, erkennt der Beobachter und der Data Guard-Broker diese Unterbrechung. Dabei gibt der Parameter OperationTimeout von 30 Sekunden an, wie lange der Broker auf eine Antwort von der primären Datenbank warten soll, bevor er weitere Maßnahmen ergreift.

Wenn der Beobachter innerhalb dieses 30-Sekunden-Fensters nicht antwortet, geht er davon aus, dass der Primärserver unerreichbar ist und beginnt mit dem Failover-Prozess.

Der Broker versetzt die Standbydatenbank sofort in den Primärstatus, tauscht die Rollen und stellt sicher, dass die Anwendung schnell aus dem Standbymodus fortgesetzt werden kann.

Während dieser Zeit stellt der Broker auch sicher, dass die Transaktionen in der Standbydatenbank aktuell sind. Mit dem von Ihnen konfigurierten Modus, beispielsweise „Maximale Verfügbarkeit“ oder „Maximaler Schutz“, würde eine synchrone Replikation einen minimalen bis gar keinen Datenverlust verursachen. 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 das Failover zur sekundären Datenbank zu initiieren, wenn es zu einem Ausfall kommt. Nachdem das Failover erfolgt ist und die vorherige primäre Datenbank wieder verfügbar ist, kann es wiederhergestellt werden. Der Data Guard Broker erleichtert diesen Prozess.

Wenn die primäre Datenbank aufgrund eines geplanten oder ungeplanten Ausfalls nicht verfügbar ist, wechselt Data Guard zu Ihrer Standbydatenbank oder führt dort ein Failover aus.

Dieses Feature kann zusätzliche Resilienz bieten, indem der Beobachter auf einer separaten VM eingerichtet wird. Dadurch stellen Sie den Beobachter auf einer einfachen VM bereit. Dieser Ansatz gewährleistet Hochverfügbarkeit und Resilienz.

Mit Oracle Database, Version 12.2 und höher, können Sie außerdem mit nur einer Oracle Data Guard-Brokerkonfiguration mehrere Observer konfigurieren. Er bietet zusätzliche Verfügbarkeit, falls es bei einem Beobachter und der sekundären Datenbank zu Ausfallzeiten kommt. Weitere Informationen zu Data Guard Broker und seinen Vorteilen finden Sie unter Oracle Data Guard Broker: Konzepte.

Das folgende Diagramm zeigt eine Oracle Data Guard-Installation ohne Far Sync mit einer Wiederherstellungszeit von weniger als 5 Minuten.

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 das Failover zur sekundären Datenbank zu initiieren, wenn es zu einem Ausfall kommt.

Darüber hinaus wird dringend empfohlen, den Oracle Enterprise Manager bereitzustellen, um einen Überblick über die Datenbankebene zu erhalten. Sie sollten Azure Monitor mit den folgenden Metriken bereitstellen: Überwachung der Datenträger:

• Beanspruchte Betriebssystem-Datenträger-IOPS in Prozent
• Beanspruchte Datenträger-IOPS in Prozent
• Vom Datenträger gelesene Bytes/Sek.
• Auf den Datenträger geschriebene Bytes/Sek.
• Warteschlangentiefe für Datenträger
• Datenträgerbandbreite in % pro logische Gerätenummer

Zusätzlich zu den oben genannten empfehlen wir dringend, die VM-Erkenntnisse zu aktivieren.

Die VM wird basierend auf Ihrer AWR-Bewertung ausgewählt. Weitere Informationen finden Sie unter Oracle Capacity Planning. Sie sollten dringend eingeschränkten Core-vCPUs nutzen, um Lizenzkosten zu sparen und die Leistung zu maximieren.

Die Auswahl des Datenträgertyps hängt von der Ausgabe Ihrer AWR-Bewertung ab.

Wie bereits erwähnt, ist Far Sync eine Funktion, die hauptsächlich in Szenarien verwendet wird, in denen Sie zwischen Regionen replizieren, die große Entfernungen überwinden. In diesem Szenario ermöglicht Oracle Active Data Guard Far Sync für Oracle-Datenbanken eine Schutzfunktion ohne jeglichen Datenverlust. Die Oracle Far Sync-Instanz muss auf einer separaten VM installiert werden.

SSD Premium v2 werden für Dateien, die sich auf das Betriebssystem beziehen, nicht unterstützt. Weitere Informationen finden Sie unter Bereitstellen von SSD Premium v2.

Als Sicherungsziel wird Azure Premium Files verwendet. Diese Lösung ist die leistungsfähigste Lösung. Sie können auch Azure Blob Storage als Sicherungsziel verwenden. Überprüfen Sie immer, welche Option für Sie am besten geeignet ist. Sehen Sie sich auch Oracle Database-Sicherungsstrategien an.

Oracle Data Guard Far Sync

Wie bereits erwähnt, ist Far Sync eine Funktion, die hauptsächlich in Szenarien verwendet wird, in denen Sie zwischen Regionen replizieren, die große Entfernungen überwinden. In diesem Szenario ermöglicht Oracle Far Sync für Oracle-Datenbanken eine Schutzfunktion ohne jeglichen Datenverlust. Die Oracle Far Sync-Instanz muss auf einer separaten VM installiert werden.

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 Active 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 Architektur dargestellt, in der Active Oracle Data Guard FSFO und Far Sync eingesetzt werden, um Hochverfügbarkeit und Notfallwiederherstellung bereitzustellen:

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, die ein Bewusstsein auf Anwendungsebene erfordert. 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.

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 Shardkatalog auch die Masterkopie 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.

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 vorstehenden Architektur wird zusammengesetztes Sharding verwendet, um die Daten geografisch zu verteilen und Ihre Anwendungsebenen aufzuskalieren. 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.

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.
• Einführung in Oracle Data Guard
• 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.

• Einführung in Oracle Data Guard
• Oracle Data Guard Broker: Konzepte
• Konfigurieren von Oracle GoldenGate für Hochverfügbarkeit vom Typ „Aktiv/Aktiv“
• Übersicht zu Oracle Sharding