Speichertechnologien: Trends im Bereich der Servervirtualisierung - Thin Provisioning

Ein Zauberwort zur Kosteneinsparung lautet Thin Provisioning. Wie die Technik in Verbindung mit VMware Sphere funktioniert und welche Vorteile daraus entstehen, skizziert der Gastbeitrag von VMware-Consultant Arno Schmerer.

Servervirtualisierung hat nun mittlerweile einige Jahre auf dem Buckel. In nahezu allen großen Rechenzentren, aber auch in kleinen und mittleren IT-Abteilungen hat die Technologie in irgendeiner Form Einzug erhalten. Die wesentlichen Vorteile einer Servervirtualisierung liegen auf der Hand und bestehen aus der effizienteren Auslastung der physikalischen Computing-Ressourcen sowie einer höheren Flexibilität der Administration von IT-Diensten.

Dies spart nicht zuletzt Kosten, sondern erhöht in der Regel auch die Qualität der angebotenen IT-Dienste in verschiedener Hinsicht. Sieht man technisch etwas näher hin, fällt auf, dass die oben beschriebenen Vorteile der Servervirtualisierung hauptsächlich durch Innovationen in den Schichten der CPU und des Hauptspeichers erzielt wurden. Am Beispiel der etablierten Kerntechnologien der Firma VMware - Marktführer im Bereich der Servervirtualisierung - wird dies deutlich: Dessen Hypervisor-Clustering-Technologie DRS (distributed resource scheduling ) bestand in den letzten Jahren im Wesentlichen aus der dynamischen Lastbalancierung von CPU und Hauptspeicherressourcen innerhalb eines "Clusters" von mehreren physikalischen Servern.

Dies geschieht mithilfe der Basistechnologie vMotion, welche in der Lage ist, den CPU- als auch Hauptspeicherlaufzeitzustand einer virtuellen Maschine (VM) von einem physikalischen Server auf einen anderen physikalischen Server innerhalb des Clusters unterbrechungsfrei zu verschieben. Die Einsparung physikalischer Server mithilfe der Servervirtualisierung basiert letztlich darauf, dass auf einen "großen" Server mehrere VMs mit ihren virtuellen CPUs und ihrem virtuellen Hauptspeicher konsolidiert werden können. Es wird deutlich: Bei der Beschreibung all dieser Technologien und Innovationen fallen die Begriffe "CPU" und "Hauptspeicher" ganz zentral. Hier waren in der Vergangenheit offensichtlich die größten Effizienzsteigerungen und Kosteneinsparungen möglich. Doch wie sieht es im Bereich der Speicherlösungen (Storage) aus (Netzwerk wird in diesem Artikel nicht behandelt)?

Nun kann man der Storage-Schicht beileibe nicht vorwerfen, es hätten in ihr in der frühen Zeit der Servervirtualisierung keine Innovationen stattgefunden. Schliesslich war es erst der Trend der Auslagerung der Server-Datenhaltung von lokalen Festplatten auf zentrale sogenannte SAN-Systeme (Storage Area Network), der VMware die Entwicklung ihrer vMotion-Technologie und aller davon abhängigen Technologien (DRS, VMware High Availability, Distributed Power Management) überhaupt erst ermöglichte. Doch hatten Storage-Lösungen im Servervirtualisierungs-/VMware-Umfeld über Jahre hinweg den immer gleichen Makel vorzuweisen. Sie verursachen relativ hohe Kosten.

Die Abbildung zeigt ein "Thin Provisioning"-Beispiel, bei dem in der vSphere Schicht sogenannte "Thin Disks" für virtuelle Maschinen verwendet werden. Hierbei wird im Beispiel 160 GByte provisionierter/zugewiesener Speicher auf nur 100 GByte physikalischem Speicher untergebracht (Overcommitment Ratio 1,6 : 1) . Trotzdem hat die unterliegende 100 GB LUN noch 20 Prozent Kapazitätsreserven. Es besteht weiterhin die Möglichkeit, einzelnen VMs weiterhin "thick disks" zuzuweisen. Die Entscheidung für Thin Provisioning im vSphere Layer ist also keine "globale" Entscheidung für die gesamte Umgebung, sondern kann pro virtueller Disk festgelegt werden.

Hohe Kosten durch ineffiziente Datenhaltung auf SAN-Systemen


Neben der allgemeinen Binsenweisheit, dass SAN-Systeme teuer sind, trat in der Vergangenheit noch ein weiterer kostentreibender Effekt zutage in der Verwaltung eines SAN-Systems: Die Datenhaltung auf einem zentralen SAN-System galt als extrem ineffizient. Hierzu sei ein kleines Beispiel aus der Praxis gegeben: Bei "klassischen" SAN-Systemen würde zum Zeitpunkt, an dem ein SAN-Administrator üblicherweise beklagt, die Kapazität seines Storage Arrays sei zu nahe 100 Prozent ausgelastet, eine nähere Analyse ergeben, dass der Nutzdatenanteil dieses Arrays oft bei zum Teil weit unter 40 Prozent liegt. Trotzdem muss in solchen Fällen in der Regel zur Deckung des weiteren Bedarfs ein neues Storage Array angeschafft werden.

Wie konnte und kann ein solcher Effekt nur auftreten? Die Antwort lässt sich mit einem einfachen Sachverhalt aus dem Privatanwenderbereich erklären: Kauft ein Privatanwender heute einen PC mit einer 2-TByte-Festplatte, dann nicht, weil er diese Kapazität von vornherein nutzen will, sondern weil er sie irgendwann mal nutzen könnte. Er möchte einfach die administrativ unangenehme Situation vermeiden, dass seine Festplatte in naher Zukunft "volllaufen" könnte. Ein zusätzlicher Verschnitt bezüglich der genutzten Daten entsteht durch die Partitionierung einer solchen Festplatte.

Im Betrieb eines Datacenters ist dieser Sachverhalt 1:1 übertragbar. Server-Systeme werden hinsichtlich ihrer kapazitativen Auslegung des Festplattenspeichers aus gutem Grund großzügig dimensioniert. Auf einem SAN-System speichern nun viele Server-Systeme ihre Daten mit dem eben beschriebenen Effekten einer geringen Nutzdatenauslastung. Die Folge ist dabei die angesprochene, ineffiziente Datenhaltung auf SAN-Systemen mit einem Nutzdatenanteil von häufig weit unter 40 Prozent. Während der Privatanwender noch argumentieren kann, dass die Anschaffung einer 2-TByte-Festplatte ihn kostenmäßig nicht sonderlich belastet, kann das der Leiter eines großen IT-Datacenters üblicherweise nicht behaupten hisichtlich der Kosten seiner SAN-Systeme.

Was hat sich also in den vergangenen Jahren bis heute am Markt entwickelt, um die oben genannte Ineffizienz von Storage-Infrastrukturen im Server-Virtualisierungsumfeld zu adressieren und auszumerzen?

Thin Provisioning zur Kosteneinsparung

In den letzten Jahren haben sich eine Reihe unterschiedlicher Lösungen im Umfeld des sogenannten "Thin Provisionings" (TP) etabliert. Hatten anfangs IT-Entscheider noch Berührungsängste hinsichtlich etwaiger Performance-Einbußen beim Betrieb dieser Technologie, so hat TP sich mittlerweile als eine Kerntechnologie im Storage-Umfeld herauskristallisiert. Doch was ist TP überhaupt? Und in welchen Schichten einer Architektur ist TP erhältlich?

TP gibt es - je nach Storage Hersteller - mittlerweile in den unterschiedlichsten Ausprägungen. Auch in der VMware vSphere Schicht ist TP mittlerweile erhältlich - seit vSphere Version 4.0 bereits. Generell geben alle TP-Lösungen eine Antwort auf folgende Fragestellung bezogen auf das oben beschriebenes Szenario der ineffizienten Datenhaltung auf einem SAN-System: Wie schafft man es, das Missverhältnis zwischen tatsächlich genutztem Speicher und physikalisch bereitgestelltem ("provisioniertem") Speicher zugunsten einer effizienteren Nutzung zu verbessern? Die Antwort wird in den unterschiedlichen Schichten - vSphere und Storage - in unterschiedlicher Weise gegeben. Nehmen wir die Storage-Schicht: Stellt ein SAN-Administrator eine 500 GByte LUN "thin provisioned" zur Verfügung, werden tatsächlich auf dem SAN-System nicht - wie traditionell ("thick provisioned") - 500 GByte physikalisch reserviert, sondern in Abhängigkeit der konkreten Lösung und Konfiguration im "best case" gar nahe 0 GByte.

Physikalische Blöcke auf den Festplatten werden erst dann aus einem vorgegebenen "RAID-Pool" reserviert, wenn das Server-Betriebssystem, welches die LUN nutzt, tatsächlich I/O-Schreibvorgänge an die LUN richtet - zum Beispiel durch Beschreiben/Neuanlegen einer Datei. Der Sinn dieses Verfahrens ist eindeutig: Man möchte die Nutzdatenauslastung des Storage Arrays dadurch erhöhen, dass man den Konsumenten des Speichers (Server-Systeme, Hypervisor-Hosts) in Summe mehr Speicher "verspricht" als man tatsächlich liefern kann (Storage Overcommitment). So kann es zum Beispiel sein, dass in einem Storage Array von 100 TByte physikalischer Netto-Kapazität LUNs von in Summe 200 TByte virtuell provisioniert sind. Dies entspräche einem "Overcommitment" von 2:1 oder 200 Prozent.

Doch wie funktioniert TP innerhalb der VMware vSphere Schicht? Hierzu nehmen wir unser oben beschriebenes Beispiel und wandeln es etwas ab: Der SAN-Administrator stellt der vSphere Schicht eine traditionelle 500 GByte LUN zur Verfügung, die auch 500 GByte an physikalisch provisioniertem Speicher im Storage-Array entspricht. In der vSphere-Schicht wird diese LUN als normaler VMFS Datastore eingebunden. Wird nun darauf ein virtueller Server (zum Beispiel für eine spätere Windows-2008-Installation) angelegt mit einer virtuellen 100 GByte Festplatte, so hat man die Möglichkeit, diesem virtuellen Server die 100-GByte-Festplattendatei "thin provisioned" bereitzustellen.

Dadurch verwendet die zugehörige Festplattendatei nicht 100 GByte innerhalb des VMFS-Dateisystems, sondern initial lediglich wenige KByte. Erst wenn darauf beispielsweise Windows 2008 innerhalb des virtuellen Servers installiert wird und Schreibanforderungen an die virtuelle Festplattendatei gerichtet werden, wächst der Speicherbedarf der virtuellen Festplattendatei an, reicht aber in der Regel bei weitem immer noch nicht an die provisionierten 100 GByte heran.

Die Gefahr von TP - egal ob in der vSphere-Schicht, in der Storage-Schicht oder gar in beiden Schichten aktiviert - liegt ebenso auf der Hand: Dadurch, dass in diesem Verfahren mitunter bedeutend mehr Speicher "versprochen" wird als physikalisch bereitgestellt werden kann, besteht die theoretische als auch praktische Möglichkeit, dass das Storage Array zu einem bestimmten Zeitpunkt die "versprochenen" Kapazitäten nicht mehr liefern kann und das "falsche Versprechen" plötzlich auffliegt, indem die physikalischen Speicherkapazitäten des Storage Arrays "überlaufen" - was in einem IT-Betrieb einem ziemlichen GAU mit massiver Downtime und Datenverlust gleichkäme.

Es besteht also die klare Herausforderung einer betrieblichen Überwachung, solche TP-spezifischen Flaschenhalssituationen (Bottlenecks) rechtzeitig zu erkennen und vor allem darauf zu reagieren. Doch wie kann man darauf reagieren? Antwort: Entweder durch Abschaltung beziehungsweise Löschung vergleichsweise unwichtiger Test-Server-Systeme oder durch schleunigste Aufrüstung des existierenden Storage Arrays oder gar Beschaffung eines neuen Storage Arrays.

Die rechtzeitige Erkennung von sich anbahnenden Engpässen im Bereich der Storage Kapazitäten obliegt in einem nach ITIL-Vorgaben geführten IT-Betrieb dem Bereich des Capacity-Managements. Technisch ist die Erkennung oder Vorhersage solcher Flaschenhälse mit diversen Monitoring-Tools der Storage-Hersteller prinzipiell möglich. Auch VMware führt hier in der vSphere Schicht mit CapacityIQ ein eigenes Kapazitätsmanagement-Tool ins Feld. Die betriebliche Herausforderung bleibt jedoch komplex. Oft existieren in IT-Betrieben keine ausreichenden Prozesse, um in derartigen Flaschenhalssituationen kurzfristig ein Storage Array nachzubestellen. Um TP-Verfahren mit einem vertretbaren Risiko effizient zu betreiben, müssen nicht wenige IT-Betriebe auch heute noch erst ihre Beschaffungsprozesse effizienter gestalten, um von den Einsparungen von TP in sinnvoller und vor allem sicherer Weise zu profitieren.

Abseits der betrieblichen Herausforderungen beim Einsatz von TP stellt sich folgende Frage: Wo liegen die technische Schwächen? Einfach gesagt: TP ist derzeit ein Verfahren, welches zwar initial wenig Speicherkapazität benötigt, aber dann bezüglich des Kapazitätsbedarfs betrachtet über eine bestimmte Laufzeit nur einen Weg kennt: den nach oben. Im oben genannten Beispiel kann dies folgendermaßen veranschaulicht werden: Startet ein virtueller Server bezüglich der Größe seiner "thin"-provisionierten virtuellen Festplattendatei mit einigen KByte physikalisch belegter Speicherkapazität, so sind es nach der Installation eines Betriebssystems schon mehrere GByte. Während der Laufzeit eines virtuellen Servers werden dann im virtuellen Server Dateien gelöscht und wieder angelegt, et cetera. All diese Vorgänge verursachen ein weiteres Wachstum der virtuellen Festplattendatei und damit auch der belegten Blöcke auf dem Storage Array. Es gibt also keine Möglichkeit, während der Laufzeit von Systemen Blöcke wieder freizumachen auf dem Storage Array?!

In der GUI präsentiert sich Thin Provisioning als Option beim Anlegen einer virtuellen Maschine als auch bei diversen VM-Kopierprozessen. Das heißt: "Virtual Disk"-Formate können jederzeit verändert werden, bei Storage vMotion sogar "on the fly" ohne "Downtime".

Erweiterung des Thin Provisionings durch VAAI

VAAI (vStorage API für Array Integration) ist eine Storage-Schnittstellenspezifikation, die VMware entwickelt hat und von den Storage Partnern bereitgestellt wird, um für ihre Produkte entsprechende Integrationsmodule zu entwickeln. Es ist bei der Anschaffung eines Storage Arrays zur Verwendung mit VMware vSphere daher darauf zu achten, dass das jeweilige Storage Produkt VAAI unterstützt, will man von den Vorteilen dieser Schnittstelle profitieren. VAAI wurde mit vSphere 4.1 eingeführt und unter vSphere 5 um die Funktion der sogenannten "Dead Space Reclamation" oder VAAI "Thin Provisioning" (VAAI TP) erweitert.

Hintergrund: Wird auf dem Dateisystem VMFS eines vSphere Datastores eine Datei gelöscht, passiert normalerweise das gleiche wie auf nahezu jedem anderen gängigen Dateisystem (zum Beispiel NTFS unter Windows) auch: Das Dateisystem markiert in internen Pointer-Strukturen die zugehörigen Blöcke einer gelöschten Datei als unbelegt und wiederverwendbar. Das unterliegende Storage-System mit aktiviertem "Thin Provisioning" bekommt jedoch vom Dateilöschvorgang nichts mit und verzeichnet die Blöcke in seiner internen Verwaltung weiter als belegt. Mit VAAI TP wird dem Storage Array bei einem Dateilöschvorgang mitgeteilt, dass die zugehörigen, beschriebenen Blöcke der Datei wiederverwendet werden können. Somit kann der Kapazitätsbedarf auf einem Storage Array auch nach Aktivierung von Thin Provisioning zur Laufzeit wieder schrumpfen. Wichtig bei dieser Betrachtung ist erneut: Es ist in den zugehörigen Kompatibilitätslisten von VMware nachzusehen, ob ein bestimmtes Storage Produkt VAAI TP auch unterstützt.

Die Abbildung zeigt, wie mit Hilfe von VAAI beispielsweise bei einem Storage vMotion Prozess ehemals belegte Blöcke (grün markiert), die zu der verschobenen VM gehören, an das Storage Array als "frei" gemeldet werden. Dies geschieht in vSphere Version 5 mit Standard-SCSI-Commands.

Fazit

Thin Provisioning bietet als Technologie großes Potential zu Kosteneinsparungen in der Storage-Schicht. Die Herausforderungen für einen Betrieb dieser Technologie sind jedoch nicht zu unterschätzen. Die Technologie als solche hat mittlerweile einen hohen Reifegrad erlangt. IT-Betriebe müssen ihre organisatorischen Prozesse im Bereich des Kapazitätsmanagements und der System-Überwachung jedoch in der Regel optimieren und effizienter gestalten, um der durch TP gewachsenen Dynamik in der Verwaltung der Storage-Schicht ausreichend Rechnung zu tragen. Die Einführung von TP in einem IT Betrieb ist daher nur bedingt eine technologische Herausforderung, sondern in noch höherem Maße eine Herausforderung im Bereich der Etablierung effizienter Betriebsprozesse.

Whitepapers

AUTOR

Arno Schmerer…

… ist Senior Consultant bei VMware Professional Services^[3] und arbeitet dort in den Bereichen Servervirtualisierung und Cloud Infrastructure & Management.
Hinweis: Die im Beitrag enthaltenen Meinungen, Wertungen und Inhalte sind dem Autor persönlich zuzuordnen. Sie stellen keine offizielle Stellungnahme der Firma VMware dar.