Architekturen für Oracle Database Enterprise Edition in Azure

Gilt für: ✔️ Linux-VMs

Alle Oracle-Workloads können in Azure ausgeführt werden, einschließlich Workloads, die weiterhin optimal in Azure mit Oracle ausgeführt werden müssen. Wenn Sie über das Oracle Diagnostic Pack oder das Automatic Workload Repository (AWR) verfügen, können Sie Daten zu Ihren Workloads erfassen. Verwenden Sie diese Daten, um die Oracle-Workload zu bewerten, die Ressourcenanforderungen zu dimensionieren und die Workload zu Azure zu migrieren. Die verschiedenen von Oracle in diesen Berichten bereitgestellten Metriken ermöglichen grundlegende Kenntnisse zu Anwendungsleistung und Plattformnutzung.

Dieser Artikel unterstützt Sie dabei, eine Oracle-Workload für die Ausführung in Azure vorzubereiten. Außerdem werden die besten Architekturlösungen für eine optimale Cloudleistung vorgestellt. Anhand der von Oracle im Statspack und noch mehr in seinem Nachfolger, dem AWR, bereitgestellten Daten können Sie klare Erwartungen entwickeln. Dazu gehören die Grenzen der physischen Optimierung über die Architektur, die Vorteile der logischen Optimierung von Datenbankcode und der allgemeine Datenbankentwurf.

Unterschiede zwischen den beiden Umgebungen

Beachten Sie bei der Migration von lokalen Anwendungen zu Azure einige wichtige Unterschiede zwischen den beiden Umgebungen.

Ein wichtiger Unterschied besteht darin, dass in einer Azure-Implementierung Ressourcen wie virtuelle Computer, Datenträger und virtuelle Netzwerke für andere Clients freigegeben werden. Darüber hinaus können Ressourcen je nach Anforderungen gedrosselt werden. Der Schwerpunkt liegt bei Azure nicht auf der Vermeidung von Ausfällen, sondern auf der Wiederherstellung nach einem Ausfall. Beim ersten Ansatz wird versucht, die Mean Time Between Failures (MTBF, mittlere Betriebsdauer zwischen Ausfällen) zu erhöhen, beim zweiten geht es darum, die Mean Time To Recovery (MTTR, mittlere Wiederherstellungszeit) zu reduzieren.

Die folgende Tabelle enthält einige der Unterschiede zwischen einer lokalen Implementierung und einer Azure-Implementierung von Oracle-Datenbanken.

Requirements (Anforderungen)

Sehen Sie sich die folgenden Anforderungen an, bevor Sie mit der Migration beginnen:

• Bestimmen Sie die tatsächliche CPU-Auslastung. Oracle-Lizenzen gelten pro Kern, daher kann die richtige Dimensionierung des vCPU-Bedarfs von wesentlicher Bedeutung für die Senkung der Kosten sein.
• Bestimmen Sie Größe, Sicherungsspeicher und Wachstumsrate der Datenbank.
• Ermitteln Sie die E/A-Anforderungen; diese können Sie basierend auf dem Oracle Statspack und den AWR-Berichten schätzen. Sie können den Bedarf auch mithilfe von Speicherüberwachungsprogrammen des Betriebssystems schätzen.

Konfigurationsoptionen

Es ist eine gute Idee, einen AWR-Bericht zu generieren und daraus Metriken zu beziehen, die Ihnen bei Entscheidungen hinsichtlich der Konfiguration helfen. Es gibt dann vier mögliche Bereiche, die Sie optimieren können, um die Leistung in einer Azure-Umgebung zu verbessern:

• Größe des virtuellen Computers
• Netzwerkdurchsatz
• Datenträgertypen und -konfigurationen
• Cacheeinstellungen von Datenträgern

Generieren eines AWR-Berichts

Wenn Sie über eine Oracle Enterprise Edition-Datenbank verfügen und die Migration zu Azure planen, haben Sie mehrere Optionen. Wenn Sie über das Diagnostics Pack für Ihre Oracle-Instanzen verfügen, können Sie den Oracle AWR-Bericht ausführen, um die Metriken (z. B. IOPS, Mbit/s und GiB/s) abzurufen. Für Datenbanken ohne Diagnostics Pack-Lizenz oder für eine Oracle Standard Edition-Datenbank können Sie dieselben wichtigen Metriken mithilfe eines Statspack-Berichts sammeln, nachdem manuelle Momentaufnahmen erfasst wurden. Die Hauptunterschiede zwischen diesen beiden Berichtsmethoden sind, dass AWR automatisch erfasst wird und mehr Informationen über die Datenbank als Statspack enthält.

Es kann auch ratsam sein, den AWR-Bericht während regulärer und maximaler Workloads auszuführen, damit Sie die Ergebnisse vergleichen können. Um die Workload genauer zu erfassen, sollten Sie ein erweitertes Zeitfenster von einer Woche anstelle eines Tages in Betracht ziehen. AWR stellt im Rahmen der Berechnungen im Bericht Durchschnittswerte bereit. Standardmäßig speichert das AWR-Repository die Daten acht Tage lang und erstellt stündlich Momentaufnahmen.

Bei der Migration eines Rechenzentrums sollten Sie Berichte zur Dimensionierung auf den Produktionssystemen erfassen. Schätzen Sie die ungefähren Prozentwerte für die verbleibenden Datenbankkopien, die für Benutzertests, Tests und Entwicklung verwendet werden. Schätzen Sie beispielsweise 50 Prozent der Produktionsgröße.

Verwenden Sie den folgenden Befehl, um einen AWR-Bericht über die Befehlszeile auszuführen:

sqlplus / as sysdba
@$ORACLE_HOME/rdbms/admin/awrrpt.sql;

Die wichtigsten Metriken

Der Bericht fordert Sie zur Eingabe der folgenden Informationen auf:

• Berichtstyp: HTML oder TEXT. Der HTML-Typ bietet mehr Informationen.
• Die Anzahl der Tage, für die Momentaufnahmen angezeigt werden. Beispielsweise erzeugt ein einwöchiger Bericht für einstündige Intervalle 168 Momentaufnahme-IDs.
• Die erste SnapshotID für das Berichtsfenster.
• Die letzte SnapshotID für das Berichtsfenster.
• Der Name des Berichts, der vom AWR-Skript erstellt wird.

Wenn Sie den AWR-Bericht auf einem Real Application Cluster (RAC) ausführen, ist der Befehlszeilenbericht die Datei awrgrpt.sql anstelle von awrrpt.sql. Die g-Version erstellt fasst alle Ergebnisse für alle Knoten in der RAC-Datenbank in einem einzelnen Bericht zusammen. Mit diesem Bericht ist es nicht mehr notwendig, einen Bericht auf jedem RAC-Knoten auszuführen.

Sie können die folgenden Metriken aus dem AWR-Bericht abrufen:

• Datenbank-, Instanz- und Hostname
• Datenbankversion für die Unterstützungsfähigkeit durch Oracle
• CPU/Kerne
• SGA/PGA sowie Ratgeber im Falle einer Unterdimensionierung
• Gesamter Speicher in GB
• Prozentsatz für ausgelastete CPU
• Datenbank-CPUs
• IOPS (Lesen/Schreiben)
• MBit/s (Lesen/Schreiben)
• Netzwerkdurchsatz
• Netzwerklatenzrate (niedrig/hoch)
• Wichtigste Warteereignisse
• Parametereinstellungen für Datenbank
• Informationen dazu, ob es sich um eine RAC- oder eine Exadata-Datenbank handelt oder und die Datenbank erweiterte Features oder Konfigurationen verwendet

Größe des virtuellen Computers

Im Folgenden finden Sie einige Schritte, die Sie unternehmen können, um die Größe des virtuellen Computers für eine optimale Leistung zu konfigurieren.

Schätzen der Größe der VM basierend auf CPU-, Speicher- und E/A-Auslastung gemäß AWR-Bericht

Betrachten Sie die fünf wichtigsten zeitgesteuerten Vordergrundereignisse, die auf die Engpässe im System hinweisen. In der folgenden Abbildung steht die Protokolldateisynchronisierung z.B. ganz oben. Hier wird die Anzahl von Wartevorgängen angezeigt, die erforderlich sind, bevor der Protokollwriter den Protokollpuffer in die Protokolldatei für Wiederholungsvorgänge (redo) schreibt. Diese Ergebnisse zeigen, dass ein leistungsfähigerer Speicher oder leistungsfähigere Datenträger erforderlich sind. Darüber hinaus zeigt das Diagramm auch die Anzahl von CPU-Kernen und die Arbeitsspeichermenge an.

Die folgenden Diagramme zeigen das gesamte E/A-Volumen der Lese- und Schreibvorgänge. Während der Berichtsausführung wurden 59 GB gelesen und 247,3 GB geschrieben.

Auswählen einer VM

Basierend auf den Informationen aus dem AWR-Bericht wählen Sie im nächsten Schritt eine VM mit ähnlicher Größe aus, die Ihren Anforderungen entspricht. Weitere Informationen zu verfügbaren VMs finden Sie unter Arbeitsspeicheroptimierte Größen virtueller Computer.

Optimieren der VM-Größe mit ähnlicher, auf der ACU basierender VM-Serie

Nachdem Sie die VM ausgewählt haben, achten Sie auf die Azure-Compute-Einheit (Azure Compute Unit, ACU) für die VM. Sie können sich anhand des ACU-Werts auch für eine andere VM entscheiden, die Ihre Anforderungen möglicherweise besser erfüllt. Weitere Informationen finden Sie unter Azure-Compute-Einheit (ACU).

Netzwerkdurchsatz

Die folgende Abbildung zeigt die Beziehung zwischen Durchsatz und IOPS:

Der gesamte Netzwerkdurchsatz wird anhand der folgenden Informationen geschätzt:

• SQL*Net-Datenverkehr
• MB/s × Anzahl von Servern (ausgehender Datenstrom, z. B. Oracle Data Guard)
• Andere Faktoren wie z.B. Anwendungsreplikation

Je nach Ihren Anforderungen an die Netzwerkbandbreite können Sie aus verschiedenen Gatewaytypen wählen. Dazu gehören Basic, VpnGw und Azure ExpressRoute. Weitere Informationen finden Sie unter VPN Gateway: Preise.

Empfehlungen

• Die Netzwerklatenz ist höher als bei einer lokalen Bereitstellung. Eine Verringerung der Netzwerkroundtrips kann die Leistung deutlich verbessern.
• Zur Reduzierung von Roundtrips sollten Anwendungen, die ein hohes Transaktionsaufkommen aufweisen oder kommunikationsintensiv sind, auf demselben virtuellen Computer konsolidiert werden.
• Verwenden Sie virtuelle Computer mit beschleunigtem Netzwerkbetrieb, um eine bessere Netzwerkleistung zu erzielen.
• Erwägen Sie für bestimmte Linux-Distributionen die Aktivierung der TRIM/UNMAP-Unterstützung.
• Installieren Sie Oracle Enterprise Manager auf einem separaten virtuellen Computer.
• Große Seiten sind unter Linux nicht standardmäßig aktiviert. Erwägen Sie das Aktivieren großer Seiten, und legen Sie use_large_pages = ONLY für die Oracle Database fest. Dieser Ansatz kann zur Leistungssteigerung beitragen. Weitere Informationen finden Sie unter USE_LARGE_PAGES.

Datenträgertypen und -konfigurationen

Hier finden Sie einige Tipps zu Datenträgern.

• Standard-Betriebssystemdatenträger: Diese Datenträgertypen bieten persistente Daten und Zwischenspeichern. Sie sind für den Betriebssystemzugriff beim Systemstart optimiert und nicht für Transaktionsworkloads oder Data Warehouse-Workloads (analytisch) ausgelegt.

• Verwaltete Datenträger: Azure verwaltet die Speicherkonten, die Sie für Ihre VM-Datenträger verwenden. Sie geben den Datenträgertyp und die erforderliche Größe an. Für Oracle-Workloads werden am häufigsten Premium-Datenträger (SSD) verwendet. Azure erstellt und verwaltet den Datenträger für Sie. Ein verwalteter SSD Premium-Datenträger ist nur für speicheroptimierte und konzipierte VM-Serien verfügbar. Nachdem Sie eine bestimmte VM-Größe ausgewählt haben, zeigt das Menü nur die verfügbaren Storage Premium-SKUs an, die auf dieser VM-Größe basieren.

  

Nachdem Sie den Speicher auf einer VM konfiguriert haben, sollten Sie vor dem Erstellen einer Datenbank einen Auslastungstest für die Datenträger ausführen. Wenn Sie die E/A-Rate im Hinblick auf Latenz und Durchsatz kennen, können Sie damit besser bestimmen, ob die VMs den erwarteten Durchsatz mit Latenzzielen unterstützen. Es gibt eine Reihe von Tools für Auslastungstests von Anwendungen, z. B. Oracle Orion, Sysbench, SLOB und Fio.

Führen Sie den Auslastungstest erneut aus, nachdem Sie eine Oracle-Datenbank bereitgestellt haben. Starten Sie Ihre reguläre und maximale Workload, und die Ergebnisse zeigen Ihnen die Baseline Ihrer Umgebung. Seien Sie beim Workloadtest realistisch. Es ist wenig sinnvoll, eine Workload auszuführen, die nichts mit dem zu tun hat, was Sie tatsächlich auf der VM ausführen werden.

Da eine Oracle-Datenbank E/A-intensiv sein kann, sollte die Größe des Speichers unbedingt anhand der IOPS-Rate statt anhand der Speichergröße bestimmt werden. Wenn z. B. der erforderliche IOPS-Wert 5.000 beträgt, Sie aber nur 200 GB benötigen, ist das Ergebnis möglicherweise immer noch der Premium-Datenträger der P30-Klasse, obwohl er mehr als 200 GB Speicher bietet.

Sie können die IOPS-Rate aus dem AWR-Bericht abrufen. Die IOPS-Rate wird durch Wiederholungsprotokoll, physische Lesevorgänge und Schreibrate bestimmt. Vergewissern Sie sich stets, dass die gewählte VM-Serie die E/A-Anforderungen der Workload bewältigen kann. Wenn die VM einen niedrigeren E/A-Grenzwert als der Speicher hat, legt die VM den maximalen Grenzwert fest.

Beispiel: Die Größe des Redo-Protokolls beträgt 12.200.000 Bytes pro Sekunde, was 11,63 MBit/s entspricht. Der IOPS-Wert ist 12.200.000 / 2.358 = 5.174.

Sobald Sie eine genaue Vorstellung von den E/A-Anforderungen haben, können Sie eine Kombination von Laufwerken auswählen, die für diese Anforderungen am besten geeignet ist.

Empfehlungen zum Datenträgertyp

• Verteilen Sie zur Berechnung des Datentabellenbereichs die E/A-Workload mithilfe der Speicherverwaltung oder Oracle Automatic Storage Management (ASM) auf mehrere Datenträger.
• Reduzieren Sie den E/A-Werte mithilfe der erweiterten Komprimierung von Oracle sowohl für Daten als auch für Indizes.
• Legen Sie Redo-Protokolle sowie TEMP- und UNDO-Tabellenbereiche auf separaten Datenträgern ab.
• Legen Sie keine Anwendungsdateien auf standardmäßigen Betriebssystemdatenträgern ab. Diese Datenträger sind für schnelle VM-Startzeiten optimiert und erbringen für Ihre Anwendung möglicherweise keine gute Leistung.
• Wenn Sie VMs der M-Serie in Storage Premium verwenden, aktivieren Sie Schreibbeschleunigung für die Datenträger mit Wiederholungsprotokollen.
• Erwägen Sie das Verschieben von Redo-Protokollen mit hoher Latenzzeit auf die Ultra-Datenträger.

Cacheeinstellungen von Datenträgern

Obwohl Sie drei Optionen für die Hostzwischenspeicherung besitzen, wird für eine Datenbank-Workload einer Oracle-Datenbank nur das schreibgeschützte Zwischenspeichern empfohlen. Das Lesen/Schreiben kann erhebliche Schwachstellen in einer Datendatei verursachen, da es das Ziel eines Schreibvorgangs in einer Datenbank ist, den Datensatz in der Datendatei zu speichern und nicht die Informationen zwischenzuspeichern. Beim schreibgeschützten Zugriff werden alle Anforderungen für zukünftige Lesevorgänge zwischengespeichert. Alle Schreibvorgänge werden weiterhin auf Datenträger geschrieben.

Empfehlungen zum Datenträgercache

Beginnen Sie nach Möglichkeit mit dem schreibgeschützten Zugriff bei der Hostzwischenspeicherung, um den Durchsatz zu maximieren. Beachten Sie bei Storage Premium, dass Sie die Barrieren deaktivieren müssen, wenn Sie das Dateisystem mit den schreibgeschützten Optionen bereitstellen. Aktualisieren Sie die Datei /etc/fstab mit dem universell eindeutigen Bezeichner für die Datenträger.

• Verwenden Sie für Betriebssystemdatenträger SSD Premium-Datenträger mit Hostzwischenspeicherung mit Lese-/Schreibzugriff.
• Verwenden Sie für Datenträger, die Folgendes enthalten, einen SSD Premium-Datenträger mit schreibgeschützter Hostzwischenspeicherung: Oracle-Datendateien, temporäre Dateien, Steuerdateien, Nachverfolgungsdateien für Blockänderungen, BFILEs, Dateien für externe Tabellen und Flashbackprotokolle.
• Verwenden Sie für Datenträger, die Oracle-Online-Wiederholungsprotokolldateien enthalten, SSD Premium oder Disk Ultra ohne Hostzwischenspeicherung (die Option Keine). In den Online-Wiederholungsprotokolldateien können sich auch archivierte Oracle-Wiederholungsprotokolldateien sowie Oracle Recovery Manager-Sicherungssätze befinden. Die Hostzwischenspeicherung ist auf 4.095 GiB beschränkt. Weisen Sie daher keine SSD Premium-Größe über P50 zu, wenn Sie die Hostzwischenspeicherung verwenden. Wenn Sie mehr als 4 TiB Speicher benötigen, führen Sie ein Striping mit mehreren Premium-SSDs mit RAID-0 durch. Verwenden Sie Linux LVM2 oder Oracle Automatic Storage Management.

Wenn die Workloads zwischen Tag und Nacht stark variieren und die E/A-Workload dies unterstützen kann, kann SSD Premium (P1-P20) mit Bursting die erforderliche Leistung bei nächtlichen Batchlasten oder begrenzten E/A-Anforderungen bieten.

Sicherheit

Nachdem Sie Ihre Azure-Umgebung eingerichtet und konfiguriert haben, müssen Sie Ihr Netzwerk sichern. Hier sind einige Empfehlungen dafür:

• NSG-Richtlinie: Sie können Ihre Netzwerksicherheitsgruppe (NSG) über ein Subnetz oder eine Netzwerkschnittstelle definieren. Es ist einfacher, den Zugriff auf der Subnetzebene zu kontrollieren, sowohl aus Sicherheitsgründen als auch für Anwendungsfirewalls mit Routingerzwingung.

• Jumpbox: Damit der Zugriff noch sicherer wird, sollten Administratoren keine direkte Verbindung zum Anwendungsdienst oder zur Datenbank herstellen. Verwenden Sie eine Jumpbox als Medium zwischen dem Administratorcomputer und Azure-Ressourcen.

  

  Der Administratorcomputer sollte nur IP-beschränkten Zugriff auf die Jumpbox bieten. Die Jumpbox sollte dann Zugriff auf Anwendung und Datenbank haben.

• Privates Netzwerk (Subnetze): Es empfiehlt sich, den Anwendungsdienst und die Datenbank in getrennten Subnetzen zu betreiben, sodass die NSG-Richtlinie eine bessere Kontrolle festlegen kann.

Ressourcen

• Konfigurieren von Oracle ASM
• Konfigurieren von Oracle Data Guard
• Konfigurieren von Oracle GoldenGate
• Sichern und Wiederherstellen einer Oracle-Datenbank

Nächste Schritte

• Erstellen einer vollständigen Linux-VM mit der Azure CLI
• Erkunden der Azure CLI-Beispiele für die Bereitstellung virtueller Computer