Speichertechnologien: Trends im Bereich der Servervirtualisierung – Thin Provisioning

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.

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.