VM-Aware Storage

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

VM-Aware Storage (VAS) ist ein Datenspeicher, der speziell entworfen wurde, um Speicher für virtuelle Maschinen (VMs) in einem Rechenzentrum zu verwalten. Das Ziel ist es, Speicher anzubieten, der, verglichen mit Universalspeicher, einfacher zu verwenden und auf das Zusammenwirken mit VMs optimiert ist. VM-Aware Storage ermöglicht es, Speicher als integralen Teil einer VM zu verwalten, anstatt als Logical Unit Number (LUN) oder Volumen, das separat konfiguriert und verwaltet wird.

VM-Aware Storage wird häufig in Verbindung mit anderen VM-aware-Komponenten und -Prozessen verwendet, wie VM-Aware-Netzwerken, VM-Aware-Datensicherungen und VM-Aware-Virensuche.[1] VM-Aware Storage hat einige Gemeinsamkeiten mit Software-defined Networking und kann davon profitieren, unterscheidet sich aber von Letzterem darin, dass SDN physische Technik bereitstellt, die über Software angepasst und eingerichtet werden kann, wohingegen VM-Aware Storage für virtuelle Maschinen entworfen wurde.[2][3]

Hintergrund[Bearbeiten | Quelltext bearbeiten]

Der Einsatz von Server-Virtualisierung ist seit Veröffentlichung des Hypervisors VMware ESX im Jahr 2001 stark gestiegen. Die International Data Corporation (IDC) schätzt, dass seit 2009 mehr virtuelle als physische Maschinen aufgesetzt wurden.[4]

Die Möglichkeit, Anwendungen, die auf zig Servern verteilt laufen, auf einer physischen Maschine mit einem Hypervisor zu vereinen, hat zu enormen Kosteneinsparungen sowohl bei Geräten als auch durch automatisierte Verwaltung der virtuellen Server geführt. Durch diese Vorteile haben seit 2010 viele Unternehmen die Richtlinie „Virtualisierung zuerst“ umgesetzt, die aussagt, dass alle neuen Servereinrichtungen virtuell geschehen sollen, es sei denn, bestimmte Gründe sprächen dagegen und für den Einsatz eines physischen Servers.[5]

Da durch Virtualisierung die Kosten von Serverhardware gesenkt werden konnten, wurde die Speichersysteme zum dominierenden Faktor für die Kosten und Komplexität virtueller Infrastrukturen. In fast allen Verwaltungswerkzeugen für virtuelle Systeme der frühen 2000er Jahre wurden Rechnerressourcen, wie CPU und Hauptspeicher, separat von Speicherressourcen konfiguriert und verwaltet. Serverressourcen wurden häufig von einem anderen Team verwaltet als die Speicherinfrastruktur. Die Server und Speichersysteme separat zu konfigurieren und sie zur Zusammenarbeit zu bewegen, erforderte häufig abgestimmte, umfangreiche Planung, Integration und Fehlerbehebung.

Entstehung[Bearbeiten | Quelltext bearbeiten]

Um die Verwaltbarkeit von Speicher zu erhöhen, gingen Speichersystemanbieter dazu über, ihre Lösungen mit den umgebenden virtuellen Komponenten (häufig virtuelle Infrastruktur genannt) kompatibler zu gestalten. Anfängliche Verbesserungen bestanden aus Skripten und Plug-ins für virtuelle Infrastrukturen, um übliche Arbeitsabläufe, wie das Zuweisen von Speicher zu VMs, unkomplizierter zu gestalten. Als Folge wurden diese Aufgaben einfacher umsetzbar.

Um weitere Vorteile zu erzielen und virtuellen Infrastrukturen die Möglichkeit zu geben, die zugrundeliegenden Speichersystemfunktionen, wie Schnappschüsse, Klonen (beschreibbare Snapshots), Replikation und Quality of Service (QoS), besser nutzen zu können, begannen Hypervisorhersteller, neue Speicher-Protokolle und -Erweiterungen (VAAI,[6] StorageLink[7]) zu veröffentlichen und zu implementieren, um den Speicher in virtuellen Umgebungen zu verwalten.

Diese frühen Schritte verbesserten zwar die Verwendbarkeit und Effizienz von Speichern innerhalb von virtuellen Infrastrukturen, berücksichtigten jedoch nicht die grundsätzliche Trennung zwischen virtuellen Infrastrukturen und Speichersystemen. Da virtuelle Infrastrukturen entworfen wurden, um VMs zu verwalten, Speichersysteme hingegen entworfen wurden, um LUNs und Partitionen zu verwalten, die keine direkte Beziehung zu VMs haben.

Unabhängig von VMware, begannen auch verschiedene Startups, VM-aware-Storage-Produkte unter der Verwendung vorhandener Oberflächen für virtuelle Infrastrukturverwaltung anzubieten. Diese Lösungen wurden entworfen, um dieselben VM-Abstraktionen zu unterstützen, und ermöglichen Speicherverwaltung in der Feinheit auf VM-Ebene.

Vergleich mit Universalspeicher[Bearbeiten | Quelltext bearbeiten]

Universalspeichersysteme wurden in Hinblick auf Speicherprotokolle, wie SCSI, iSCSI, Network File System (NFS) und Server Message Block (SMB), entwickelt, die es lange gab, bevor Virtualisierung aufkam. Als Ergebnis sind ihre grundlegenden Verwaltungseinheiten LUNs und Volumen, die wenig mit VMs zu tun haben. Universalspeichersysteme werden überwiegend unabhängig von der virtuellen Infrastruktur konfiguriert und verwaltet. Die Abstraktionen der VM werden von Administratoren auf die Speichersysteme abgebildet. Sie müssen dann diese Zuordnungen verwalten und Richtlinien sowie Prozesse für das Übersetzen von Operationen auf VMs in die entsprechenden Operationen für LUNs und Partitionen erstellen.[8]

Da es zum Beispiel keine Standardprotokolle zum Erstellen und Löschen von LUNs und Volumen gibt, speichern die meisten virtuellen Infrastrukturen viele VMs in einem einzelnen LUN oder Volumen, um Bereitstellungs- und Verwaltungsaufwand auszugleichen. Da allgemeine Speichersysteme die meisten Speicherverwaltungsfunktionen, wie Überwachung, Schnappschüsse, Klonen, Replikation und QoS, für LUNs und Volumen anstatt für VMs und virtuelle Festplatten umsetzen, bedeutet dies, dass Speichersysteme die Fähigkeit verlieren, diese Vorgänge auf einzelnen VMs auszuführen.[9]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. David Y. Zhu, Erika Chin: Detection of VM-Aware Malware (Memento des Originals vom 7. September 2012 im Internet Archive) In: Technical report, UC Berkeley, Dezember 2007. Abgerufen am 25. Juni 2012  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/radlab.cs.berkeley.edu 
  2. Kate Greene: TR10: Software-Defined Networking In: Technology Review, MIT, March–April 2009. Abgerufen am 25. Juni 2012 
  3. Steven Herrod: Interop and the Software-Defined Datacenter In: cto.vmware.com, VMware, Mai 2012. Abgerufen am 25. Juni 2012 
  4. Michelle Bailey: The Economics of Virtualization: Moving Toward an Application-Based Cost Model (Memento des Originals vom 10. Mai 2012 im Internet Archive) In: Research sponsored by VMware, International Data Corporation, November 2009. Abgerufen am 25. Juni 2012  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.vmware.com 
  5. Jeffrey Burt: Enterprises Thinking Virtualization First In: eWeek.com, International Data Corporation, April 2010. Abgerufen am 25. Juni 2012 
  6. VMware Knowledge Base: vStorage APIs for Array Integration FAQ, VMware. Abgerufen am 25. Juni 2012 
  7. Citrix Developer Network: What is StorageLink? In: XenServer Best Practices Citrix StorageLink, Citrix. Abgerufen am 25. Juni 2012 
  8. Stephen Foskett: The I/O Blender Part 1: Ye Olde Storage I/O Path, blog.fosketts.net, Mai 2012. Abgerufen am 27. Juni 2012 
  9. Stephen Foskett: The I/O Blender Part 3: Behold the Power of the Demultiplexer, blog.fosketts.net, Mai 2012. Abgerufen am 27. Juni 2012