Harte Diät
Hersteller von Storage-Hardware wollen mit Techniken punkten, mit denen sich ihre Systeme effizienter betreiben lassen. Neben Deduplizierung ist Thin Provisioning eine Technik, die das Budget der Anwender entlasten soll, während sie vorhandene Hardware optimal auslastet.
- Andreas Wurm
Bei Speicherplatz gilt oft der Leitsatz „Lieber ein bisschen mehr“. Zwar gibt es Kennzahlen zur Entwicklung des Bedarfs, aber wer weiß schon, wie zuverlässig sie wirklich sind. Oft wählen Verantwortliche einen Mittelweg zwischen tatsächlichem Bedarf und erwartetem Datenwachstum. Dadurch sind statistisch gesehen nur rund ein Viertel der vorhandenen Ressourcen tatsächlich ausgelastet. Das bedeutet, Unternehmen kaufen meist viel zu früh Storage nach. Denn obwohl Speichernetze und -virtualisierung den Systemverwaltern eine Menge Optionen in die Hand geben, mit denen sie den vorhandenen Speicher effizient nutzen können, hat sich seit den Zeiten von Direct Attached Storage (DAS) nicht wirklich etwas geändert.
Eine dieser Optionen soll das Thin Provisioning sein. Die Technik selbst ist nicht neu; alle größeren Hersteller haben sie bereits in ihre Storage-Systeme integriert. Wie Deduplizierung soll Thin Provisioning den überhasteten Zukauf neuer Speicherhardware reduzieren.
Klassische Zuweisung von Festplattenplatz funktioniert nach dem Prinzip „Dedicate on Allocation“: Wenn eine neue Anwendung Speicher benötigt, weist der Administrator beziehungsweise das Storage-System dem entsprechenden Server diesen fest zu; er steht anderen nicht mehr zur Verfügung. Geht bei diesem „Fat-“ oder „Hard Provisioning“ einer Anwendung A der Speicher aus, bringt es ihr gar nichts, dass Applikation B bislang nur 20 % ihres Kontingents nutzt. Zwar bieten inzwischen viele RAID-Arrays das Vergrößern von Volumes an, aber nicht das Verkleinern, und ein Umzug auf ein kleineres Volume geht mit dem Umkonfigurieren des Servers und einer Downtime der Anwendung einher. Falls der Administrator für eine Applikation mehr Speicher braucht, muss er neue Platten oder Subsysteme hinzukaufen oder das Volume auf ein anderes System mit mehr Platz verschieben und dann vergrößern.
Nur so viel wie nötig
Eine andere, unter Umständen wirtschaftlichere Technik könnte „Dedicate on Write“ sein – Thin Provisioning (TP). Sie ist aber nur in einem SAN sinnvoll. Stellt ein System seine Ressourcen dateibasiert zur Verfügung, etwa über NFS (Network File System), ist der verfügbare Platz ohnehin besser provisioniert, da mehrere Hosts darauf parallel in ein Dateisystem schreiben.
Zudem arbeitet Thin Provisioning ausschließlich mit virtuellem Speicher. Zwar bestimmt der Administrator die Größe des verfügbaren Volumes; allerdings teilt TP die angeforderten Ressourcen – anders als bei der „Dedicate-on-Allocation“-Technik – nicht komplett fest zu, sondern lediglich einen Teil. Sobald der Server Daten auf das Volume schreibt und dabei der freie Platz einen vorher festgelegten Grenzwert unterschreitet, stellt TP aus einem vorhandenen Pool zusätzlichen freien Speicher bereit. Auch diesen Wert kann der Administrator festlegen.
Dadurch kann er den einzelnen Systemen beliebig viel Platz zuweisen, also überprovisionieren. Die Applikationen dürfen den Speicher nur nicht gleichzeitig anfordern – ähnlich einer Bank, bei der zwar alle Kontoinhaber Geld abheben dürfen, nur nicht gleichzeitig.
Für Thin Provisioning zuständig sind die Subsysteme. Wie üblich stellen sie den Servern ganze Volumes über LUNs (Logical Unit Number) bereit, halten aber beim TP nur einen Teil des zugewiesenen Plattenplatzes vorrätig. Der Server „sieht“ also das Volume in der zugewiesenen Größe und schreibt darauf sein Dateisystem, obwohl das Volume auf dem Subsystem kleiner ist. Reicht der Platz nicht mehr aus, vergrößert das System das Volume um Blöcke aus dem Pool.
Das Manko dieser Technik zeigt sich erst, wenn man Daten löscht und Ressourcen freigeben will. Denn Thin Provisioning funktioniert nicht wie ein Schieberegler, mit dem man den nötigen Speicher einfach hoch- und herunterdrehen kann. Braucht ein Server mehr Speicher, bekommt er ihn aus dem Pool – selbst dann, wenn jemand zwischenzeitlich Daten auf dem Volume gelöscht hat und eigentlich genug Platz vorhanden ist. Die Daten mögen zwar gelöscht sein, die Blöcke sind es aber nicht. Beispielsweise löscht ein Windows-Server auf einem NTFS-formatierten Volume nur die Verweise auf die Blöcke, nicht aber sie selbst. Für das Storage-System sind die Blöcke weiterhin gefüllt. Es hat keinen Einblick in die Dateisystemtabellen und Inodes und kann daher nicht herausfinden, welche Blöcke Nutzdaten enthalten oder verwaist sind.
Dadurch erhält man unterschiedliche Antworten auf die Frage nach dem belegten Platz eines Volume – je nach Perspektive. Abbildung 2 zeigt schematisch aus Sicht des Hosts (Servers) und aus Sicht des Speichersystem, was nach mehreren Schreib- und Löschzyklen auf einem Volume passiert. Solange der Server nur Daten schreibt, sind sich Host und Storage-System einig. Zur Uneinigkeit zwischen beiden kommt es erst beim Löschen von Daten. Für den Server ist das Volume nur noch zu 25 Prozent ausgelastet, für das Speichersystem zu 75 Prozent.
Blöcke leer, LUN voll
Bei dieser Arbeitsweise kann der „Füllstand“ einer LUN nie sinken – es sei denn, das System reorganisiert den Speicherplatz. Für diesen Fall bieten Hersteller oft eine eigene Software oder eine Zusatzfunktion für das Storage-System an, die die Blöcke leert und das Dateisystem „aufräumt“. Allerdings kann eine solche Reorganisation – ähnlich wie eine Defragmentierung – nur dann fehlerfrei funktionieren, wenn es währenddessen keine Schreibzugriffe auf das Volume gibt. NetApp etwa nennt diese Technik „Hole Punching“.
Allerdings beißt sich das mit anderen von Administratoren und Benutzern gleichermaßen geliebten Funktionen: Solange sich die Blöcke noch im Originalzustand befinden, lassen sich versehentlich gelöschte Dateien mit entsprechenden Werkzeugen einfach wiederherstellen. Ähnliches gilt für Snapshots – vor allem vom Dateisystem verwaltete. Auch sie arbeiten mit „unsichtbaren“ Blöcken und können im ungünstigen Fall einer Reorganisation zum Opfer fallen. Noch komplizierter kann die Angelegenheit in Umgebungen werden, die mit Remote Mirroring und asynchroner Replikation arbeiten. Bevor man hier zum Thin Provisioning greift, sollte man das Schreibverhalten aller beteiligten Systeme genau untersuchen.
Insgesamt erhöht TP den Verwaltungs- und Planungsaufwand, auch wenn es verspricht, die Planer durch die dynamische Speicherallozierung zu entlasten. Zwar statten Hersteller ihre Systeme mit allerlei Automatismen aus, beispielsweise einer Füllgradüberwachung, Warnungen an Administratoren und/oder Hersteller, spontane Komprimierung oder Konvertierung des RAID-Levels etwa von RAID 10 auf RAID 50 beim Überschreiten bestimmter Schwellenwerte. Doch auch die setzen eine Was-tun-wenn-Planung und eine Umsetzung in der Gerätekonfiguration voraus – nicht zu vergessen den Notfallplan für den schlimmsten Fall, der immer noch heißt: fehlender Speicherplatz.
Da es für Thin-Provisioning-Techniken keine Standards gibt, kocht jeder Hersteller sein eigenes Süppchen. Pionier 3PAR arbeitet beim Thin Provisioning mit sogenannten Common Provisioning Groups (CPG) auf Grundlage seiner eigenen Virtualisierungstechnik. Das sogenannte Virtual Volume Management (VVM) virtualisiert die Hardware in drei Schritten. Im ersten teilt es sämtliche Platten – gleich, wie groß sie sind – in 256 MByte große Blöcke auf. Diese „feinkörnige“ Struktur soll verhindern, dass die Speichersysteme zu schlecht ausgelastet sind. Laut 3PAR lassen sich so die virtuellen Volumes zielgenauer vergrößern oder verkleinern.
Jeder im eigenen Gewand
Im zweiten Schritt schließt der Hersteller die Blöcke je nach Bedarf zu logischen Laufwerken zusammen. Im dritten und letzten Schritt legt er virtuelle Volumes darauf – je nach Bedarf größere oder kleinere. Erst diese sind für die Server sichtbar. Virtuelle Volumes können zwischen einem GByte und zwei TByte groß sein. Obwohl sich später Änderungen an den Volumes vornehmen lassen, sind ihnen die Ressourcen für ihre volle Größe zugeordnet – obwohl noch nichts darauf geschrieben wurde.
Für das Thin Provisioning zieht 3PAR in das oben beschriebene VVM eine weitere Schicht ein – die Common Provisioning Group, die das feste Zuweisen von Speicherplatz unterbindet. Sie befindet sich zwischen den virtuellen Volumes und den logischen Laufwerken. Anders als beim herkömmlichen Virtual-Volume-Management legt CPG aus den vorhandenen freien 256-MByte-Blöcken nur so viele logische Laufwerke an, wie die Server gerade für das Schreiben der Daten benötigen. Ein virtuelles Volume, das zu einer bestimmten CPG gehört, nennt sich Thin Provisioned Virtual Volume (TPVV).
Dessen theoretische Ressourcen sind für den Server sichtbar, dem das TPVV zugewiesen ist. Wenn eine Anwendung Daten auf ein TPVV schreibt, stellt das System diesen Platz auf den vorkonfigurierten logischen Laufwerken zur Verfügung. Geht der Speicherplatz in den logischen Laufwerken des TPVV mit der Zeit zur Neige, fügt das System neue logische Laufwerke zur CPF hinzu.
Wählen zwischen dick und dünn
Auch NetApps Thin Provisioning arbeitet mit logischen Laufwerken. Der Hersteller nennt sie logische Container. Mit der „FlexVol“-Technik – für Flexible Volume – lassen sich die logischen Container, auf denen die Daten liegen, innerhalb eines Filers unabhängig vom physischen Ort verschieben. Die Ressourcen sind dann als virtuelle Pools sichtbar, die sich je nach Anforderungen anlegen lassen. FlexVol ist Teil des NetApp-Betriebssystems „Data ONTAP“. Wer dort die Option Speicherplatzgarantie auf „nein“ setzt, ist schon dazu übergegangen, Speicherplatz nur bei Bedarf an Hosts und Applikationen zuzuweisen.
EMC nennt das ganze Symmetrix Virtual Provisioning (SVP), eine „Weiterentwicklung des normalen Thin Provisioning“. Auch das Symmetrix Virtual Provisioning verwendet logische Laufwerke, Thin Devices genannt. In der EMC-Variante sind das logische Speichereinheiten, die wie herkömmliche Devices innerhalb eines Arrays definiert werden. Anders als bei ihnen muss bei den Thin Devices zum Zeitpunkt ihrer Erstellung und Zuordnung zum Host der physische Speicher nicht gleich komplett zugeordnet sein, da sie ihren Platz aus dem sogenannten Thin-Speicher-Pool beziehen. Er besteht aus Datenbank-Devices, die den physischen Speicher im System bereitstellen.
iX-Tract
- Wie andere Storage-Spartechniken soll Thin Provisioning die Speicherhardware reduzieren.
- Es fasst die Ressourcen in einem jederzeit erweiterbaren Speicher-Pool zusammen und weist sie den angelegten Volumes nicht nach ihrer Größe, sondern nach ihrem Füllgrad zu.
- Damit spart Thin Provisioning zwar Kosten für den benötigten Storage, kann aber auch Gefahren wie das Volllaufen der Arrays mit sich bringen.
Schreibt ein Host auf das ihm zugewiesene Thin Device, ordnet SVP eine Mindestmenge des physischen Speichers sequenziell aus dem Pool zu – mit gleichzeitigem Striping über alle im Pool befindlichen Datenbank Devices hinweg, unabhängig davon, ob ein Host Daten zufällig oder sequenziell auf ein Thin Device schreibt. Falls der Thin-Speicher-Pool irgendwann nicht mehr ausreichen sollte, lässt er sich mit neuen Datenbank-Devices aufstocken. Dabei wird das Zuweisungs-Striping von den bestehenden Datenbank-Devices auf den neuen fortgesetzt.
Auch bei VMware erhalten virtuelle Maschinen Zugriff auf Ressourcen, deren virtuelle Menge den tatsächlich vorhandenen Speicherplatz übersteigt. Beim VMware vStorage Thin Provisioning definiert man die jeweiligen Disks der virtuellen Maschinen (VMDK) als „Thick“ oder „Thin“. „Thin“ bedeutet in diesem Fall, dass der VMFS-3-Treiber nur einen Teil der definierten VMDK alloziert und diesen Teil bei Bedarf erweitert. Mit VMware Storage vMotion lassen sich zudem Thick-VMDKs in Thin-VMDKs konvertieren. VMotion überwacht und steuert auch die Überschreitung der physischen Kapazität.
Trotz Glanz kein Gold
Auf der einen Seite können Unternehmen mit Thin Provisioning mehr Server an ein Storage-System anbinden und es deutlich besser auslasten. Wer seine Disk-Arrays gut auslastet, braucht weniger Storage – sowohl für kommende Aufgaben als auch für bereits laufende Server. Damit einher geht ein geringerer Bedarf an Energie und Stellfläche. Muss man Festplatten erst kaufen, wenn der Reserve-Pool für bereits zugewiesene Ressourcen knapp wird, sind sie pro GByte günstiger als zuvor – zumindest solange die Preise immer weiter fallen.
Aber Thin Provisioning wird weder die Welt retten noch Unternehmen dabei helfen, Unmengen an Geld einzusparen. Es reduziert zwar die vorzuhaltenden Speicherressourcen und schont den Geldbeutel. Aber es gibt auch eine dunkle Seite, denn selbst IT-Experten arbeiten gern gegen Bezahlung. Dadurch kann ein Unternehmen unter Umständen dem Fass Storage-Kosten einen Deckel verpassen und das Fass Verwaltungsaufwand öffnen.
Denn: Kleine Unternehmen mit wenig Speicherkapazität brauchen in der Regel kein Thin Provisioning, oft nicht mal ein SAN. Aber gerade die Systemverantwortlichen im Mittelstand und darüber müssen die Speicherauslastung genau im Auge behalten. Und ohne ausgiebiges Monitoring oder Trending sollten sich Administratoren davor hüten, allzu stark über ihre vorhandenen Ressourcen hinaus zu provisionieren. Denn das Schlimmste, was passieren kann, ist, dass Server den ihnen zugestandenen Speicher belegen müssen, dieser aber gar nicht vorhanden ist.
Andreas Wurm
ist freier Journalist in München. (sun)
