Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Virtualisierung der Oracle Datenbank

03/13/2024 Beitragende

PDFs

Die Virtualisierung von Datenbanken mit VMware, Oracle OLVM oder KVM wird für NetApp-Kunden, die sich für Virtualisierung selbst für ihre geschäftskritischsten Datenbanken entschieden haben, immer häufiger eingesetzt.

Instandhaltung

Es gibt viele Missverständnisse bezüglich der Oracle Support-Richtlinien für Virtualisierung, insbesondere für VMware-Produkte. Es ist nicht ungewöhnlich, zu hören, dass Oracle die Virtualisierung nicht unterstützt. Diese Vorstellung ist falsch und führt zu verpassten Möglichkeiten, von der Virtualisierung zu profitieren. Oracle Doc ID 249212.1 behandelt die tatsächlichen Anforderungen und wird von Kunden selten als ein Problem betrachtet.

Wenn ein Problem auf einem virtualisierten Server auftritt und das Problem dem Oracle Support bisher unbekannt war, wird der Kunde möglicherweise gebeten, das Problem auf physischer Hardware zu reproduzieren. Ein Oracle Kunde, der eine innovative Version eines Produkts ausführt, möchte möglicherweise wegen möglicher Supportprobleme keine Virtualisierung nutzen. Für Virtualisierungskunden, die allgemein verfügbare Oracle Produktversionen verwenden, war diese Situation jedoch keine echte Realität.

Storage-Präsentation

Kunden, die eine Virtualisierung ihrer Datenbanken in Erwägung ziehen, sollten ihre Storage-Entscheidungen basierend auf ihren Geschäftsanforderungen treffen. Dies ist zwar für alle IT-Entscheidungen generell eine echte Aussage, ist aber vor allem bei Datenbankprojekten von Bedeutung, da sich Größe und Umfang der Anforderungen erheblich unterscheiden.

Es gibt drei grundlegende Optionen für die Storage-Präsentation:

Virtualisierte LUNs auf Hypervisor-Datastores
Vom iSCSI-Initiator gemanagte iSCSI-LUNs auf der VM, nicht der Hypervisor
NFS-Dateisysteme, die von der VM gemountet wurden (nicht aus einem NFS-basierten Datastore)
Direkte Gerätezuordnungen. VMware RDMs werden von Kunden missbWege, aber physische Geräte werden immer noch oft ähnlich direkt mit KVM- und OLVM-Virtualisierung abgebildet.

Leistung

Die Methode zur Bereitstellung von Speicher für einen virtualisierten Gast hat in der Regel keine Auswirkungen auf die Leistung. Host-Betriebssysteme, virtualisierte Netzwerktreiber und Hypervisor-Datastore-Implementierungen sind allesamt hochoptimiert und können im Allgemeinen die gesamte verfügbare FC- oder IP-Netzwerkbandbreite zwischen dem Hypervisor und dem Storage-System nutzen, sofern grundlegende Best Practices befolgt werden. In einigen Fällen ist das Erlangen einer optimalen Performance unter Umständen mit einem Ansatz für die Storage-Präsentation im Vergleich zu einem anderen etwas einfacher, das Endergebnis sollte jedoch vergleichbar sein.

Managebarkeit

Der wichtigste Faktor bei der Entscheidung, wie Storage einem virtualisierten Gast zur Verfügung gestellt wird, ist die Fähigkeit, zu bestimmen. Es gibt keine richtige oder falsche Methode. Der beste Ansatz hängt von den Anforderungen, Fähigkeiten und Präferenzen der IT-Abteilung ab.

Zu den berücksichtigenden Faktoren gehören:

Transparenz. Wenn eine VM ihre Dateisysteme verwaltet, ist es für einen Datenbankadministrator oder einen Systemadministrator einfacher, die Quelle der Dateisysteme für ihre Daten zu identifizieren. Auf die Dateisysteme und LUNs wird nicht anders zugegriffen als auf einem physischen Server.
Konsistenz. Wenn eine VM Eigentümer ihrer Dateisysteme ist, wirkt sich die Verwendung oder Nichtnutzung einer Hypervisor-Schicht auf die Verwaltbarkeit aus. Die gleichen Verfahren für die Bereitstellung, das Monitoring, die Datensicherung usw. können über den gesamten Bestand hinweg eingesetzt werden, einschließlich sowohl virtualisierter als auch nicht virtualisierter Umgebungen.

Andererseits könnte es in einem ansonsten zu 100 % virtualisierten Datacenter besser sein, Datastore-basierten Storage über den gesamten Platzbedarf hinweg zu nutzen – mit derselben Argumentation wie oben erwähnt – Konsistenz – die Fähigkeit, dieselben Verfahren für Bereitstellung, Sicherung, Überwachung und Datensicherung zu verwenden.
Stabilität und Fehlerbehebung. Wenn eine VM über ihre Dateisysteme verfügt, sind die Bereitstellung guter, stabiler Performance und Fehlerbehebungsprobleme einfacher, da der gesamte Speicher-Stack auf der VM vorhanden ist. Die einzige Rolle des Hypervisors besteht darin, FC- oder IP-Frames zu transportieren. Wenn ein Datastore in einer Konfiguration enthalten ist, wird die Konfiguration durch die Einführung eines weiteren Satzes von Timeouts, Parametern, Protokolldateien und potenziellen Bugs erschwert.
Portabilität. Wenn eine VM Eigentümer ihrer Dateisysteme ist, wird der Prozess des Verschiebens einer Oracle-Umgebung viel einfacher. Dateisysteme können problemlos zwischen virtualisierten und nicht virtualisierten Gastsystemen verschoben werden.
Vendor Lock-in. Nachdem die Daten in einem Datastore platziert wurden, wird es schwierig, einen anderen Hypervisor zu verwenden oder die Daten aus der virtualisierten Umgebung zu nehmen.
Snapshot-Aktivierung. herkömmliche Backup-Verfahren in einer virtualisierten Umgebung können wegen der relativ begrenzten Bandbreite zu einem Problem werden. Beispielsweise ist ein 10-GbE-Trunk mit vier Ports möglicherweise ausreichend, um den täglichen Leistungsbedarf vieler virtualisierter Datenbanken zu decken. Ein solcher Trunk wäre jedoch nicht ausreichend, um Backups mit RMAN oder anderen Backup-Produkten durchzuführen, die das Streaming einer vollständigen Kopie der Daten erfordern. So müssen in einer zunehmend konsolidierten virtualisierten Umgebung Backups über Storage Snapshots durchgeführt werden. Dadurch entfällt die Notwendigkeit, die Hypervisor-Konfiguration lediglich zu überbauen, um die Bandbreiten- und CPU-Anforderungen im Backup-Fenster zu unterstützen.

Bei der Verwendung von Filesystemen, die sich im Besitz von Gästen befinden, ist es manchmal einfacher, Snapshot-basierte Backups und Restores zu nutzen, da die zu schützenden Storage-Objekte einfacher angepeißt werden können. Es gibt jedoch eine immer größere Anzahl an Datensicherungsprodukten für die Virtualisierung, die sich gut in Datenspeicher und Snapshots integrieren lassen. Die Backup-Strategie sollte vollständig berücksichtigt werden, bevor eine Entscheidung darüber getroffen wird, wie Speicher einem virtualisierten Host zur Verfügung gestellt werden kann.

Paravirtualisierte Treiber

Für eine optimale Leistung ist die Verwendung paravirtualisierter Netzwerktreiber von entscheidender Bedeutung. Wenn ein Datastore verwendet wird, ist ein paravirtualisierter SCSI-Treiber erforderlich. Ein paravirtualisierter Gerätetreiber ermöglicht es einem Gast, sich tiefer in den Hypervisor zu integrieren, im Gegensatz zu einem emulierten Treiber, bei dem der Hypervisor mehr CPU-Zeit damit verbringt, das Verhalten physischer Hardware nachzuahmen.

RAM überschreiben

Das Überschreiben von RAM bedeutet, mehr virtualisierten RAM auf verschiedenen Hosts zu konfigurieren, als auf der physischen Hardware vorhanden ist. Dies kann zu unerwarteten Leistungsproblemen führen. Bei der Virtualisierung einer Datenbank dürfen die zugrunde liegenden Blöcke des Oracle SGA nicht durch den Hypervisor in den Storage getauscht werden. Dies führt zu äußerst instabilen Performance-Ergebnissen.

Datastore-Striping

Bei der Verwendung von Datenbanken mit Datastores muss ein entscheidender Faktor im Hinblick auf die Performance berücksichtigt werden: Striping.

Datastore-Technologien wie VMFS können mehrere LUNs umfassen, sind jedoch keine Striping-Geräte. Die LUNs werden verkettet. Das Endergebnis kann LUN-Hotspots sein. Beispielsweise könnte eine typische Oracle-Datenbank eine ASM-Festplattengruppe mit 8 LUNs enthalten. Alle 8 virtualisierten LUNs konnten auf einem VMFS Datenspeicher mit 8 LUNs bereitgestellt werden, es gibt jedoch keine Garantie, auf welchen LUNs sich die Daten befinden. Die resultierende Konfiguration könnte alle 8 virtualisierten LUNs sein, die eine einzelne LUN innerhalb des VMFS-Datastore belegen. Das führt zu einem Performance-Engpass.

Striping ist in der Regel erforderlich. Bei einigen Hypervisoren, einschließlich KVM, ist es möglich, wie beschrieben mit LVM Striping einen Datenspeicher zu erstellen "Hier". Bei VMware sieht die Architektur etwas anders aus. Jede virtualisierte LUN muss in einem anderen VMFS-Datenspeicher platziert werden.

Beispiel:

Fehler: Fehlendes Grafikbild

Der Haupttreiber dieses Ansatzes ist nicht ONTAP, sondern er liegt an der inhärenten Beschränkung der Anzahl der Vorgänge, die eine einzelne VM oder Hypervisor-LUN parallel bedienen kann. Eine einzelne ONTAP-LUN kann im Allgemeinen deutlich mehr IOPS unterstützen, als ein Host anfordern kann. Das Performance-Limit für eine einzelne LUN ist fast universell ein Ergebnis des Host-Betriebssystems. Das Ergebnis: Die meisten Datenbanken benötigen zwischen 4 und 8 LUNs, um ihre Performance-Anforderungen zu erfüllen.

VMware Architekturen müssen ihre Architekturen sorgfältig planen, um sicherzustellen, dass sie keine Maxima für Datenspeicher und/oder LUN-Pfade aufweisen. Darüber hinaus ist keine Notwendigkeit für eine eindeutige Gruppe von VMFS-Datenspeichern für jede Datenbank erforderlich. Die primäre Anforderung besteht darin sicherzustellen, dass jeder Host über einen sauberen Satz von 4-8 I/O-Pfaden von den virtualisierten LUNs zu den Back-End-LUNs auf dem Speichersystem selbst verfügt. In seltenen Fällen können sogar noch mehr Daten für wirklich extreme Performance-Anforderungen von Vorteil sein, aber 4-8 LUNs sind im Allgemeinen für 95 % aller Datenbanken ausreichend. Ein einzelnes ONTAP Volume mit 8 LUNs kann bis zu 250,000 zufällige Oracle Block-IOPS mit einer typischen OS-/ONTAP-/Netzwerkkonfiguration unterstützen.