Testreihe SDS, Teil 2: HP Storevirtual VSA
Virtueller Speicher für Hypervisoren
Hewlett-Packard bietet seine Speicherlösung Storevirtual auch als Virtual Storage Appliance (VSA) an, die auf einem ESX- oder Hyper-V-Server läuft. VSA stellt lokal angeschlossene Festplatten per iSCSI dem Hypervisor zur Verfügung. Die Daten lassen sich über das Netzwerk auf ein anderes VSA-System synchron replizieren. Snapshots, Thin Provisioning und Remote Copy runden den Funktionsumfang dieses "Software-Defined Storage"-(SDS-)Systems ab.Der zweite Teil der LANline-Testreihe zu SDS widmet sich Storevirtual VSA von HP (zu VMware VSAN siehe LANline 7/2014). Die Virtual Storage Appliance von HP verwandelt einen ESX- oder Hyper-V-Server in ein iSCSI-Target, das dem Hypervisor iSCSI-LUNs zur Verfügung stellt. Damit lassen sich auf demselben Server sowohl virtuelle Maschinen (VMs) als auch der erforderliche Speicher über lokal angeschlossene Platten als virtuelles SAN bereitstellen. Um eine hohe Verfügbarkeit zu erreichen, kann der Systemverantwortliche zwei oder mehr physische Server zu einem Storage-Cluster zusammenschließen. Auf jedem Cluster-Node läuft mindestens ein VSA-Server, der die lokalen Speicherressourcen virtualisiert und gemeinsam mit den anderen Clusterknoten verwaltet. Die virtuellen iSCSI-LUNs werden per Network-RAID auf mindestens einen anderen Knoten synchron repliziert. Dadurch lassen sich die Speicherressourcen beim Ausfall eines Knotens automatisch von einem anderen Node übernehmen. Ein dediziertes Speichernetzwerk mit zentralen Storage-Systemen ist damit dann nicht mehr nötig. Die Speicherkapazität und die I/O-Performance eines VSA-Clusters lassen sich durch Hinzufügen weiterer physischer Hosts auf bis zu 50 TByte und 16 Nodes ausbauen. Die VSA-Lösung deckt das gesamte Funktionsspektrum des physischen Speichersystems HP Storevirtual 4000 ab. Dazu zählen unter anderem Thin Provisioning, Managed Snapshots, Smart Clones, Remote-Copy-Funktionen, Multi-Site SAN mit Disaster Recovery sowie Performance-Monitoring. Eine VSA kann auch Teilbereiche von externen Speichersystemen in das virtuelle SAN integrieren. Damit ist es zum Beispiel möglich, das Speichersystem einer Außenstelle per Remote Copy in der Zentrale zu sichern. Bei den größeren 10- und 50-TByte-VSA-Lizenzen ist zudem die Funktion "Adaptive Optimization" (AO) enthalten. Dabei handelt es sich um ein automatisches Tiering, das Daten, auf die sehr häufig zugegriffen wird, automatisch auf das schnellere Tier verlagert. AO unterstützt zwei Tiers, die zum Beispiel aus SSD- und SAS-Laufwerken bestehen können. Der Tiering-Mechanismus verwendet kleine 256-KByte-Blöcke und arbeitet dadurch sehr granular. Server-Hardware und Netzwerk Die Leistungsfähigkeit des virtuellen VSA-Speichers hängt in erster Linie von der Geschwindigkeit und Anzahl der physischen Laufwerke, der Leistungsfähigkeit des RAID-Controllers und der Netzwerkbandbreite ab. Als Mindestausstattung empfiehlt HP vier Gigabit-Ethernet-NICs, von denen zwei für die Kommunikation der virtuellen Gastsysteme zuständig sind und zwei für den iSCSI-Storage-Datenverkehr der VSA-Systeme. Für Anwendungen mit hohen Bandbreitenanforderungen wie zum Beispiel Streaming sollte 10 Gigabit Ethernet zum Einsatz kommen. Die RAM-Ausstattung eines VSA-Servers richtet sich nach der Höhe der virtualisierten Speicherkapazität. Sie beginnt bei mindestens 4 GByte RAM, im Maximalausbau mit 50 TByte Speicherkapazität sind 26 GByte RAM erforderlich. Damit beim Ausfall einer Festplatte keine Daten verloren gehen, sind die lokalen physischen Laufwerke als RAID-Verbund zu konfigurieren, bevor der Administrator das VSA-System auf dem Hypervisor installiert und das virtuelle SAN einrichtet. Das zu wählende RAID-Level richtet sich nach den jeweiligen Performance- und Kapazitätsanforderungen. Bei geclusterten VSA-Systemen mit synchron replizierten Daten muss die Speicherkapazität des virtuellen Storage Pools auf allen Cluster-Nodes gleich sein. Für den Test von Storevirtual VSA luden wir von der HP-Website die aktuelle Software herunter. Diese ist in drei Lizenzstufen mit 4, 10 und 50 TByte verwalteter Speicherkapazität erhältlich. Jedes VSA-System erfordert eine eigene Lizenz. Zudem gibt es eine kostenfreie Einstiegsversion, die auf 1 TByte und drei VSA-Knoten begrenzt ist. Vorbereitung der Testumgebung Als Testumgebung diente uns ein Vsphere-5.5-Cluster mit zwei ESX-Hosts. Die VSA läuft als virtueller Gast auf einem ESX-Server oder Hyper-V-Server und verwandelt den der VM zugewiesenen lokalen Datastore in einen virtuellen Storage-Pool. Der Pool agiert als iSCSI-Target und stellt den physischen Hosts virtuelle iSCSI-LUNs zur Verfügung. Wenn Storevirtual VSA auf einem ESX-Cluster installiert ist, stehen für die auf dem VSA-Datastore laufenden virtuellen Gäste alle VMware-Funktionen wie Hochverfügbarkeit, Host- und Storage-Vmotion zur Verfügung. Ein VSA-System lässt sich auch im Stand-alone-Betrieb nutzen, bietet dann aber keinen Schutz vor einem Ausfall der Server-Hardware. Um Storevirtual VSA zu testen, importierten wir das von HP bereitgestellte OVF-Template (Open Virtual Machine Format) auf die zwei ESX-Hosts. Zuvor hatten wir auf jedem ESX-Server einen Datastore mit den lokalen Platten erstellt, die VSA nutzen sollte. Nachdem der Import abgeschlossen war, fügten wir jeder VSA vier virtuelle Disks hinzu. Eine VSA-Instanz unterstützt maximal sieben virtuelle Disks. Auf der Basis dieser Disks erstellt VSA die virtuellen RAID-Sets des Storage Pools. VSA unterstützt auch ein direktes Mappen von physischen Disks. Anschließend starteten wir die VSA und konfigurierten über einen textbasierenden Assistenten IP-Adresse und Hostname. Damit die VSA-Systeme mit den ESX-Hosts und der Außenwelt kommunizieren können, muss der Administrator zudem auf den ESX-Hosts einen virtuellen Switch mit iSCSI-Kernel-Port einrichten und die VSA-VM diesem Switch zuordnen. Nachdem dies erledigt war, installierten wir auf einem Windows-7-Rechner die Centralized Management Console (CMC) für die Verwaltung der VSA-Systeme. Mithilfe der CMC lassen sich sowohl virtuelle Appliances als auch physische Storevirtual-Systeme zentral verwalten. Beim Öffnen der CMC erscheint ein grafischer Assistent, der das Netzwerk scannt und vorhandene Storevirtual-Systeme automatisch erkennt. Der Administrator kann die VSA-IP-Adressen auch manuell eingeben. Im Test starteten wir die Broadcast-Suche. Diese erkannte die zwei VSA-Systeme auf Anhieb. Als wir uns das erste Mal mit einem VSA-System verbinden wollten, erschien die Fehlermeldung, dass die VSA-Version neuer sei als die von uns installierte CMC-Version. Über das CMC-GUI konnten wir die aktuelle Version von der HP-Website herunterladen und installieren. Nach dem Update funktionierte der Zugriff auf die VSA-Systeme. Hochverfügbarer VSA-Cluster Damit ein VSA-System iSCSI-LUNs bereitstellen kann, muss der Adminstrator zunächst einen virtuellen Storage-Pool erstellen, indem er die der VSA zugewiesenen virtuellen Disks als Stripe-RAID-Set konfiguriert. Der CMC-Assistent fügt dem Stripe-Set automatisch alle im VSA-Datastore vorhandenen virtuellen Disks hinzu. Anschließend kann der Administrator die einzelnen Disks dem schnellen Tier 0 oder dem langsameren Tier 1 zuweisen, falls er die Funktion "Adaptive Optimization" nutzen will. Damit dies auch den gewünschten Beschleunigungseffekt bringt, empfiehlt es sich, die virtuellen Disks so zu benennen, dass erkennbar ist, auf welchem physischen Laufwerk (zum Beispiel SSD) diese liegen. Bevor wir mit der Konfiguration von iSCSI-LUNs auf dem virtuellen VSA-Pool begannen, bildeten wir aus den zwei VSA-Systemen einen hochverfügbaren VSA-Cluster. Die CMC stellt dafür einen Assistenten bereit, der für den Cluster zunächst eine "Management Group" erstellt, dieser die gewünschten VSA-Systeme zuweist, dann den Cluster einrichtet und schließlich die virtuellen iSCSI-LUNs anlegt. Die Management Group ist auch für Einzelsysteme erforderlich, da über sie die virtuellen iSCSI-LUNs anzulegen sind. Um Split-Brain-Situationen zu vermeiden, bei denen Clusterknoten nicht mehr miteinander kommunizieren können, aber noch Zugriff auf die gespeicherten Daten haben, verwendet Storevirtual VSA ein Quorum. Die Quorum-Mehrheit entscheidet bei einem Ausfall, welcher überlebende Knoten die Hoheit über den Storage-Pool erhält. Besteht ein VSA-Cluster nur aus zwei Knoten, regelt ein von den VSA-Systemen unabhängiger "Failover Manager" (FOM), welcher Knoten bei einem Ausfall die Kontrolle über den Speicher-Pool erhält. Für den Test importierten wir das auf der HP-Website erhältliche "Failover Manager"-OVF-Template. Ist kein dedizierter FOM-Server vorhanden, richtet CMC auf den VSA-Nodes automatisch einen Failover-Manager-Dienst ein. Fällt ein Clusterknoten aus, startet der Administrator den Dienst auf dem überlebenden Knoten und weist diesem das Quorum manuell zu. Damit ein ESX-Server die von den VSA-Systemen bereitgestellten iSCSI-LUNs nutzen kann, muss der Administrator auf der iSCSI-Netzwerkkarte des ESX-Hosts die IP-Adresse des VSA-Systems als iSCSI-Target hinzufügen. Im CMC-GUI legt er zudem einen Server-Cluster mit den ESX-Knoten an und fügt die IP-Adresse des Virtual-Center-Servers als Kontrollinstanz für die iSCSI-Initiatoren hinzu. Im letzten Schritt legt der Administrator dann pro iSCSI-LUN fest, welche Server darauf zugreifen dürfen. LUN-Provisioning und Failover-Test Für den LANline-Test richteten wir drei iSCSI-LUNs ein, die wir anschließend dem VMware Virtual Center als Datastore hinzufügten. Die virtuellen iSCSI-LUNs schützt Storevirtual durch ein Netzwerk-RAID vor Datenverlusten. Dabei lassen sich die Daten wie bei einem RAID 10 zwischen zwei Clusterknoten per iSCSI synchron replizieren und stripen. Beim Ausfall eines physischen Servers mit VSA-Instanz übernimmt der andere VSA-Clusterknoten automatisch die betroffenen Speicherressourcen. Es ist auch möglich, zwei oder drei Kopien der primären LUN synchron zu replizieren. Storevirtual VSA unterstützt zudem die RAID-Level 0, 1, 5 und 6. Um die Failover-Funktionen des kombinierten VSA- und ESX-Clusters zu testen, migrierten wir einen vorhandenen virtuellen Windows-2012-R2-Server auf eine VSA-iSCSI-LUN. Auf einer zweiten VSA-LUN installierten wir einen neuen W2012R2-Server. Dann schalteten wir im laufenden Betrieb den ESX-Server hart aus, auf dem die beiden W2012R2-VMs und ein geclustertes VSA-System liefen. Das Zusammenspiel der beiden Cluster hat reibungslos funktioniert. Der noch aktive ESX-Host hat die zwei VMs von der replizierten LUN aus automatisch neu gestartet, und die Server standen umgehend wieder zur Verfügung. Nachdem wir den ESX-Server wieder hochgefahren hatten, fügte sich das VSA-System automatisch wieder in den Cluster-Verbund ein. Fazit Mit dem von HP Storevirtual VSA bereitgestellten virtuellen SAN lassen sich VMware-ESX- und Microsoft-Hyper-V-Cluster mit den lokal am Server angeschlossenen Festplatten in einem hochverfügbaren Storage-Cluster betreiben. Ein dediziertes SAN mit zentralem Speichersystem ist bei dieser Architektur nicht erforderlich, was eine hohe Kostenersparnis bedeutet. Der Einstiegspreis für Storevirtual VSA liegt bei rund 2.000 Euro. Dafür gibt es wahlweise eine 4-TByte-Lizenz für drei VSA-Cluster-Nodes oder eine 10-TByte-Lizenz für eine VSA-Instanz. Storevirtual VSA stellt dieselben Management-Funktionen wie die physischen Speichersysteme bereit und lässt damit kaum Wünsche offen. Zu den wichtigsten Funktionen zählen dabei zeitgesteuerte Snapshots, Remote Copy, Thin Provisioning und Mulit-Site-Support inklusive Disaster-Recovery-Steuerung. Aufgrund der vielschichtigen Architektur und der zahlreichen unterschiedlichen Konfigurationsmöglichkeiten ist eine sorgfältige Planung der Server-, Festplatten- und Netzwerkkonfigurationen allerdings eine wichtige Voraussetzung für die erfolgreiche Umsetzung eines VSA-Projekts.
Der Autor auf LANline.de: chjlange
Info: Hewlett-PackardTel.: 0800/2660266Web: www.hp.com/de
Lesen Sie mehr zum Thema
