Für die Implementierung von Oracle Database sind Faktoren zu berücksichtigen
Eine Public Cloud bietet eine große Auswahl an Computing- und Storage-Ressourcen. Der Einsatz der richtigen Computing-Instanz und der richtigen Storage Engine ist ein guter Ausgangspunkt für die Datenbankimplementierung. Wählen Sie außerdem Computing- und Storage-Konfigurationen aus, die für Oracle Datenbanken optimiert sind.
In den folgenden Abschnitten werden die wichtigsten Überlegungen bei der Implementierung einer Oracle Database in der Azure Public Cloud auf einer Azure Virtual Machine Instanz mit Azure NetApp Files Storage beschrieben.
VM-Typ und Größenbestimmung
Die Auswahl des richtigen VM-Typs und der richtigen Größe ist für die optimale Performance einer relationalen Datenbank in einer Public Cloud wichtig. Eine Azure Virtual Machine bietet eine Vielzahl von Computing-Instanzen, die zum Hosten von Oracle Datenbank-Workloads verwendet werden können. Siehe Microsoft-Dokumentation "Größen für die Virtual Machines in Azure" Für unterschiedliche Arten von Azure Virtual Machines und ihre Größenbestimmung. Im Allgemeinen empfiehlt NetApp die Nutzung einer allgemeinen Azure Virtual Machine für die Implementierung kleiner und mittlerer Oracle Datenbanken. Für den Einsatz größerer Oracle-Datenbanken eignet sich eine speicheroptimierte Azure VM. Mit mehr verfügbarem RAM kann ein größerer Oracle SGA- oder Smart Flash-Cache konfiguriert werden, um den physischen I/O zu verringern, wodurch wiederum die Datenbank-Performance verbessert wird.
Azure NetApp Files arbeitet als NFS-Mount mit Anbindung an eine Azure Virtual Machine. Dies bietet einen höheren Durchsatz und überwindet das Storage-optimierte VM-Durchsatzlimit mit dem lokalen Storage. Daher könnte die Nutzung von Oracle auf Azure NetApp Files die Anzahl der lizenzierbaren CPU-Kerne und die Lizenzkosten von Oracle reduzieren. Siehe "TR-4780: Oracle Databases on Microsoft Azure", Abschnitt 7 - Wie Funktioniert Oracle-Lizenzierung?
Weitere Faktoren, die Sie berücksichtigen sollten:
-
Wählen Sie basierend auf Workload-Merkmalen die richtige vCPU- und RAM-Kombination aus. Wenn sich die RAM-Größe auf der VM erhöht, steigt auch die Anzahl der vCPU-Kerne. Es sollte zu einem bestimmten Zeitpunkt ein Gleichgewicht geben, da die Oracle Lizenzgebühren auf der Anzahl der vCPU-Kerne berechnet werden.
-
Fügen Sie Swap-Speicherplatz zu einer VM hinzu. Die standardmäßige Implementierung von Azure VMs erstellt keinen Swap-Speicherplatz, der nicht für eine Datenbank optimal ist.
Performance von Azure NetApp Files
Azure NetApp Files Volumes werden aus einem Kapazitäts-Pool zugewiesen, den der Kunde in seinem Azure NetApp Files Storage-Konto bereitstellen muss. Jeder Kapazitäts-Pool wird wie folgt zugewiesen:
-
Auf ein Service Level, das die allgemeine Performance definiert.
-
Die anfänglich bereitgestellte Speicherkapazität oder das Tiering für diesen Kapazitäts-Pool. Ein Quality-of-Service-Level (QoS), das den maximalen Gesamtdurchsatz pro bereitgestelltem Speicherplatz definiert.
Das Service-Level und die anfänglich bereitgestellte Storage-Kapazität bestimmen das Performance-Level für ein bestimmtes Oracle Datenbank-Volume.
1. Service Levels für Azure NetApp Files
Azure NetApp Files unterstützt drei Service-Level: Ultra, Premium und Standard.
-
Ultra Storage. Diese Ebene bietet einen Durchsatz von bis zu 128 MiB pro 1 tib Volume Kontingent.
-
Premium-Speicher. dieser Tier bietet einen Durchsatz von bis zu 64 MiB pro 1 tib Volume Kontingent.
-
Standard-Speicher. Diese Ebene bietet einen Durchsatz von bis zu 16 MiB pro 1 tib Volume Kontingent.
2. Kapazitäts-Pool und Quality of Service
Jedes der gewünschten Service-Level verursacht damit verbundene Kosten für die bereitgestellte Kapazität und umfasst ein Quality of Service-Level (QoS), das den maximalen Gesamtdurchsatz für den bereitgestellten Speicherplatz definiert.
Ein über 10 tib bereitgestellter Single-Capacity-Pool mit dem Premium-Service-Level bietet beispielsweise einen insgesamt verfügbaren Durchsatz für alle Volumes in diesem Kapazitäts-Pool mit 10x 64 MB/s, also 640 MB mit 40,000 (16.000) IOPS oder 80,000 (8.000) IOPS.
Die minimale Kapazitäts-Pool-Größe ist 4 tib. Sie können die Größe eines Kapazitäts-Pools in 1-tib-Schritten ändern, um Änderungen an den Workload-Anforderungen zum Managen von Storage-Anforderungen und -Kosten zu reagieren.
3. Berechnen Sie den Service-Level auf einem Datenbank-Volume
Das Durchsatzlimit für ein Oracle Datenbank-Volume wird durch eine Kombination aus folgenden Faktoren bestimmt: Dem Service Level des Kapazitäts-Pools, zu dem das Volume gehört, und dem dem Volume zugewiesenen Kontingent.
Das folgende Diagramm zeigt, wie das Durchsatzlimit eines Oracle Datenbank-Volumes berechnet wird.
Beispiel 1 wird einem Volume aus einem Kapazitäts-Pool mit der Premium-Storage-Tier, dem 2 tib Kontingent zugewiesen ist, ein Durchsatzlimit von 128 MiPS (2 tib * 64 MiB) zugewiesen. Dieses Szenario gilt unabhängig von der Größe des Kapazitäts-Pools oder dem tatsächlichen Volume-Verbrauch.
In Beispiel 2 wird einem Volume aus einem Kapazitäts-Pool mit der Premium-Storage-Tier, dem 100 gib an Kontingent zugewiesen ist, ein Durchsatzlimit von 6,25 MiB zugewiesen (0,09765625tib * 64MiB). Dieses Szenario gilt unabhängig von der Größe des Kapazitäts-Pools oder dem tatsächlichen Volume-Verbrauch.
Beachten Sie, dass die minimale Volume-Größe 100 gib beträgt.
Storage-Layout und -Einstellungen
NetApp empfiehlt das folgende Storage Layout:
-
Für kleine Datenbanken. Verwenden Sie ein einzelnes Volume-Layout für alle Oracle-Dateien.
-
Bei großen Datenbanken empfiehlt sich das Volume-Layout aus mehreren Volumes: Eines für Oracle Daten und eine doppelte Kontrolldatei und eines für das aktive Protokoll von Oracle, ein archiviertes Protokoll und eine Kontrolldatei. NetApp empfiehlt dringend, ein Volume für die Oracle-Binärdatei anstelle des lokalen Laufwerks zuzuweisen, damit die Datenbank auf einen neuen Host verlagert und schnell wiederhergestellt werden kann.
NFS-Konfiguration
Linux, das gängigste Betriebssystem, umfasst native NFS-Funktionen. Oracle bietet einen direkten NFS-Client (dNFS), der nativ in Oracle integriert ist. Oracle dNFS umgeht den BS-Cache und ermöglicht die parallele Verarbeitung zur Verbesserung der Datenbank-Performance. Oracle unterstützt NFSv3 seit über 20 Jahren, und NFSv4 wird mit Oracle 12.1.0.2 und höher unterstützt.
Durch die Verwendung von dNFS (verfügbar seit Oracle 11g) kann eine Oracle Datenbank, die auf einer Azure Virtual Machine ausgeführt wird, deutlich mehr I/O als der native NFS-Client ermöglichen. Die automatisierte Oracle-Implementierung mit dem NetApp Automatisierungs-Toolkit konfiguriert dNFS auf NFSv3 automatisch.
Das folgende Diagramm zeigt den SLOB-Benchmark auf Azure NetApp Files mit Oracle dNFS.
Weitere Faktoren, die berücksichtigt werden sollten:
-
TCP-Slot-Tabellen entsprechen dem NFS-Äquivalent zur Warteschlangentiefe des Host-Bus-Adapters (HBA). Diese Tabellen steuern die Anzahl der NFS-Vorgänge, die zu einem beliebigen Zeitpunkt ausstehen können. Der Standardwert ist normalerweise 16, was für eine optimale Performance viel zu niedrig ist. Das entgegengesetzte Problem tritt auf neueren Linux-Kerneln auf, die automatisch die Begrenzung der TCP-Slot-Tabelle auf ein Niveau erhöhen können, das den NFS-Server mit Anforderungen sättigt.
Um eine optimale Performance zu erzielen und Performance-Probleme zu vermeiden, passen Sie die Kernel-Parameter an, die TCP-Slot-Tabellen steuern, auf 128 an.
sysctl -a | grep tcp.*.slot_table
-
Die folgende Tabelle enthält die empfohlenen NFS-Mount-Optionen für eine einzelne Instanz von Linux NFSv3.
Überprüfen Sie vor der Verwendung von dNFS, ob die in Oracle Doc 1495104.1 beschriebenen Patches installiert sind. Die NetApp Support-Matrix für NFSv3 und NFSv4 enthält keine spezifischen Betriebssysteme. Alle Betriebssysteme, die der RFC entsprechen, werden unterstützt. Wenn Sie die Online-IMT nach Unterstützung für NFSv3 oder NFSv4 suchen, wählen Sie kein bestimmtes Betriebssystem aus, da keine Treffer angezeigt werden. Alle Betriebssysteme werden implizit von der allgemeinen Richtlinie unterstützt. |