Storage-Komprimierung und Deduplizierung - Darf es vielleicht noch ein bisschen weniger sein?
Dieser Beitrag betrachtet das Thema Komprimierung aus einem anderen Blickwinkel: In einem Labor-PoC (Proof of Concept) hat ORDIX zusammen mit dem Storage-Hersteller Tegile untersucht, welche Mehrwerte die storage-eigenen Komprimimierungs- und Deduplizierungsoptionen für eine Oracle-Datenbank liefern können. Untersuchungsgegenstand war neben der eigentlichen Effizienz, die sich im tatsächlichen Speicherbedarf und der Performance ausdrückt, auch die Überlegung, ob das Delegieren der Komprimierung vom Server- zum Storagesystem wirtschaftlich einen Nutzen bringt.
Der ORDIX-Partner Tegile Systems, Inc
Nach den Marktanalysten der Dell'Oro Group ist eine Transition des Storage Marktes bereits schon länger in voller Fahrt [2]. Die klassischen Speichersysteme mit drehenden Festplatten, die von einem halben Dutzend seit Jahren etablierter Anbieter angeboten werden, bekommen Konkurrenz.
Junge und innovative Hersteller von Hybrid- oder All-Flash- Lösungen mit hohen Wachstumsraten etablieren sich zunehmend am Markt. Ein solcher Anbieter ist das 2010 gegründete Unternehmen Tegile, mit dem die ORDIX AG im Jahr 2017 eine Partnerschaft begründet hat. Weitere Storage-Trends sind die Adaption von NVMe (Non-Volatile Memory Express) sowie auch die zunehmende Bedeutung von Cloud-Storage. Auch in diesen Bereichen ist Tegile mit dem Portfolio gut aufgestellt [3].
Natürlich legt die Entscheidung zwischen Flash, HDD oder der Kombination daraus neben weiterer Hardware nur den Grundstein für eine adäquate Architektur. Die Features kommen in der Regel bei allen Herstellern aus einem ausgeklügelten und häufig proprietären Storage- Betriebssystem, welches die eigentliche Differenzierung zu den Wettbewerbern liefert. So bietet Tegile-Storage die Konsolidierung von verschiedensten Workloads aus der File- und Blockwelt sowie auch ausgefeilte Technologie zur Reduzierung des RAW-Speicherbedarfs an, um die nutzbare Kapazität deutlich zu steigern. Neben Thin- Provisioning sind hier auch Deduplizierung und Inline- Komprimierung der Daten herauszustellen. Es sei erwähnt, dass bei dem Aufbau und bei der Durchführung des PoCs die besonders einfache GUI-Bedienbarkeit des Speichersystems aufgefallen ist (s. Abb. 2). Alle Workloads des Storagesystems werden durch Projekt-Wizards eingerichtet, wobei für gängige Workloads in den Templates gleich die korrekte Best Practice vorgeschlagen wird. Auch das Monitoring oder der Export von Performancedaten – bis auf LUN-Ebene – ist ausgesprochen hilfreich.
PoC Aufbau
Auf dem Server wurde Oracle Linux 7.3 (x64) installiert und eine Oracle-Datenbank der Version 12.2 EE genutzt. Die Verwaltung der LUNs geschah dabei mit Hilfe von Oracle Grid Infrastructure (GI), ebenfalls in Version 12.2. Den Tegile Best Practices [4] folgend, wurden insgesamt 16 neue LUNs erstellt, 8 pro Controller. Jeder der beiden Controller verwaltete dabei je vier LUNs für Daten (128 GB) und Redologs (64 GB). Aus den LUNs sind anschließend mit Hilfe von Oracle GI die zwei Disk- Gruppen DATA und REDOLOG gebildet worden. Den Empfehlungen folgend, setzen sowohl die LUNs, als auch die Oracle-Datenbank eine einheitliche Blockgröße von 8 KB ein. Für die Tests wurden der Oracle-Datenbank zehn 1 GB große Logfiles für Redologs zur Verfügung gestellt und Bigfile Tablespaces genutzt.
Messreihen
Selbstverständlich können Messreihen, die unter Laborbedingungen durchgeführt werden, nicht ohne weiteres gegen eine Lasttest-Validierung mit echten Produktivdatenbanken verglichen werden.
Ziel der durchgeführten Tests ist lediglich, eine Tendenz in den Messwerten zu erkennen, um eine grundsätzliche Aussage treffen zu können. Die akzeptierte Abweichung der Messungen wurde mit 10% recht groß definiert.
Auf der Datenbank wurden die folgenden Aktionen in unterschiedlichen Szenarios mit jeweils einer Millionen Zeilen durchgeführt:- Lesen (Select)
- Änderungen (Updates)
- Löschungen (Deletes)
- Einfügungen (Inserts)
Auswertung der Messreihen
In der Abbildung 3 wird die hohe Komprimierungsrate des Tegile-Systems deutlich. Interessant ist, dass auch im Fall von bereits aktivierter Oracle-Komprimierung immer noch eine signifikante Komprimierung durch den Storage erfolgt. Gleichfalls zeigt die Tabelle auch den Nutzen der Oracle- Komprimierung. Die Differenz aus den Größenangaben aus der Datenbank und dem tatsächlichen Platzbedarf der LUNs auf dem Storage ist durch Metadaten erklärbar. Wird Komprimierung sowohl auf dem Storage als auch innerhalb der Datenbank aktiviert, führt dies zu einem beeindruckenden Wert von 85% bezogen auf den Speicherbedarf!
Deduplizierung, von dessen Einsatz Tegile im Zusammenhang mit Oracle-Datenbanken abrät, wurde zusätzlich getestet. Es konnte nachgewiesen werden, dass der Einsatz keinen Vorteil bringt. Dies liegt an der Datenstruktur einer Oracle-Datenbank, die in der Regel keine identischen Blöcke enthält.
Bedarf der Oracle DB (MB) | Bedarf der Tegile LUNs (MB) | |
Basiswert | 2624 (100%) | 2710 (100%) |
Tegile Compression | 2624 (100%) | 800 (30%) |
Oracle Compression | 568 (22%) | 630 (23%) |
Oracle Advanced Compression | 656 (25%) | 730 (27%) |
Tegile and Oracle Compression | 568 (22%) | 400 (15%) |
Tegile Compression und Oracle Advanced Compression | 656 (25%) | 500 (18%) |
Fazit
In einem Satz zusammengefasst kann gesagt werden: Komprimierung hilft erheblich, um im Oracle-Umfeld erhebliche Speicherkapazitäten zu sparen. Im Falle von Tegile Storage geschieht dies kostenneutral, da keine zusätzlichen Lizenzen benötigt werden.
Als Orientierungshilfe lässt sich basierend auf den Messergebnissen daher folgendes festhalten: die Messergebnisse zeigen, dass die Komprimierung durch Tegile in den getesteten Fällen, ohne auf das Anwendungsszenario der Datenbank achten zu müssen, stets aktiviert sein sollte. Die Aktivierung zeigt insbesondere keine negativen Auswirkungen auf die Performance. Unter bestimmten Bedingungen zeigt sich sogar eine Performancesteigerung sowie eine Verbesserung der Latenzzeiten, da I/O-Operationen im Backend eingespart werden können. Tegiles empfohlene Komprimierung LZ4 erreichte eine Komprimierung von bis zu 70% und liegt damit nur knapp unter der Komprimierungsrate von Oracle mit bis zu 78%.
Tests in realen, großen Kundenumgebungen durch ORDIX haben gezeigt, dass Select / Delete Statements – insbesondere bei Massendaten – in Kombination mit Oracle- Komprimierung immer schneller sind als eine Komprimierung mit Storage-Mitteln. Dies liegt daran, dass Oracle unmittelbar in der System Global Area (SGA) komprimiert bzw. dekomprimiert. Dadurch müssen zwischen Host und Storage weniger Blöcke transportiert werden. Massenänderungen sind hingegen mit Tegile-Technologien etwas schneller. Relativ unentschieden ist das Ergebnis zwischen Oracle- und Tegile-Komprimierung bei Masseninserts.
Die Kombination der beiden Komprimierungs-/Deduplizierungmöglichkeiten zeigt, dass sogar noch zusätzlich Speicherplatz eingespart werden kann. Dabei kann es je nach Anwendungsszenario aber auch sinnvoll sein, auf die Oracle Komprimierung zu verzichten, um so Lizenz- und Hardwarekosten serverseitig zu sparen.
Die Komprimierungsrate des Tegile-Systems mit dem empfohlenen Komprimierungsalgorithmus erweist sich auch in Kombination mit der Oracle- Komprimierung als effektiv, wenn auch verständlicherweise weniger als mit unkomprimierten Oracle-Datenbanken. Aus technischer Sicht kann festgehalten werden, dass in der Regel immer noch das tatsächliche, einzelne Speichermedium die langsamste Komponente ist. Dafür ist jede Verminderung von I/O, die im Vorfeld geschieht, nützlich. Natürlich wird diesem Aspekt auch schon durch das geeignete RAID-Layout Rechnung getragen.
Aus finanzieller Sicht bietet das Tegile-System Einsparpotentiale durch nicht oder weniger benötigte Oracle-Lizenzen, eingesparten Speicherplatz oder Konsolidierung mehrerer Storages auf ein einziges System. Für das Tegile- System werden auch ansonsten keine zusätzlichen Lizenzkosten fällig, alle Features sind nativ implementiert und der Storage schnell und einfach zu konfigurieren. Es muss natürlich immer die individuelle Situation ganzheitlich betrachtet werden – dafür stehen Ihnen Tegile und ORDIX selbstverständlich gerne zur Verfügung.
Quellen
[1] ORDIX Blog: Oracle Compression - Weniger ist mehr
https://blog.ordix.de/technologien/oracle-compression-weniger-ist-mehr
[2] Marktanalyse der Dell'Oro Group
http://www.delloro.com/other/storage-systems-market-transition
[3] Unternehmensseite Tegile
http://www.tegile.com
[4] Tegile Best Practices
http://pages.tegile.com/rs/568-BVY-995/images/Oracle12cPerformanceT4700v3.pdf
Glossar
NVMe
Non Volatile Memory Express ist eine Schnittstelle, um SSD, also nichtflüchtige Massenspeicher, über PCI Express zu verbinden, ohne dass dafür herstellerspezifische Treiber nötig wären. Sie soll besonders bei parallelen Zugriffen, wie sie bei Multithreading häufig vorkommen, die Geschwindigkeit erhöhen, indem die Latenz und der Overhead durch die Befehle verringert werden.
Deduplizierung
Bei der Deduplizierung, Deduplication (DeDup), oder Daten-Deduplizierung, Data Deduplication (DDD), geht es darum, mehrfach bearbeitete und gespeicherte Dateien, die redundant sind oder sich nur geringfügig unterscheiden, zu erkennen und zu beseitigen. Ziel der Deduplizierung ist die Kapazitätsoptimierung von Speichermedien.
Thin Provisioning
Thin Provisioning (TP), bezeichnet ein Kosten sparendes Verfahren zur Bereitstellung von Speicherkapazität in virtualisierten Speicherumgebungen (Storage-Virtualisierung). Bei der schlanken Speicherzuweisung wird nur der Speicher reserviert, welcher auch tatsächlich benötigt wird.
ALUA
Asymmetric Logical Unit Access beschreibt ein standardisiertes Protokoll im SCSI Standard für den Zugriff auf ein LUN über mehrere Controller eines Speichersystems.
Consultant bei ORDIX
Bei Updates im Blog, informieren wir per E-Mail.
Kommentare