Außenstellen und kleinere Unternehmen benötigen oft nicht zwingend ein physikalisches SAN. Hier kann auch eine virtuelle Lösung wie die »Virtual SAN Appliance« von HP genügen. Diese stellt die lokalen Platten des Virtualisierungs-Hosts im Cluster bereit.

von Max Lessel

Im Herbst 2008 übernahm Hewlett-Packard ein Unternehmen namens Lefthand Networks. Diese Firma schmiedete die auf Linux basierende iSCSI-Storage-Software »SAN-IQ«. Das besondere an den Systemen: Es fasst mehrere iSCSI-Storage-Nodes unter einer einzigen virtuellen IP-Adresse zusammen, verteilt die IOPs auf den kompletten Storage-Cluster und spiegelt die Volumes synchron (Network RAID). Der Ausfall eines einzelnen Nodes innerhalb des Clusters geht somit ohne Datenverlust vonstatten. Neben den physischen »P4xxx«-Speicher-Arrays vertreibt HP mittlerweile auch eine virtuelle Version »Virtual SAN Appliance« (VSA).

Einsatzgebiete für die VSA gibt es genug. Kleinere Datacenter und Außenstellen mit zwei bis drei Hyper-V oder ESX-Nodes kommen damit ohne ein physisches SAN aus. Je eine VSA pro Node stellt die lokalen Platten des Virtualisierungs-Hosts im Cluster bereit. Zwar gehen dabei 50 und mehr Prozent der Brutto-Kapazität für RAID und Network-RAID verloren. Dennoch fällt eine Konfiguration mit lokalen Platten in mehreren Servern günstiger aus, als ein dezidiertes SAS- oder iSCSI-SAN-System. Die Redaktion von speicherguide.de unterzieht die »P4000 VSA 9.5« in einem »vSphere5«-Cluster mit zwei ESXi-5-Servern einem Hands-on-Test.

Deployment in wenigen Minuten

HP liefert die VSA als OVF-Vorlage (»Open Virtualization Format«). Die Verwaltung eines VSA-Clusters übernimmt das Java-Tool »Central Management Console« (CMC). Beim Deployment der OVF-Vorlage auf den ESX-Server kann der Verwalter der VSA-VM bis zu fünf Daten-Disks übergeben. Das dürfen sowohl virtuelle Laufwerke eines lokalen VMFS-Dateisystems als auch RAW-Disk-Mappings sein. Zwei virtuelle LAN-Adapter übernehmen die redundante LAN-Anbindung.

In Installationen mit einer geraden Zahl von VSAs bedarf es eines zusätzlichen Nodes. Der so genannte »Failover Manager« (FOM) ist eine VSA ohne Storage. Der FOM sorgt für die in Cluster-Setups benötigte ungerade Zahl an Nodes und fungiert als Quorum.

Auf der Linux-Konsole der VSA konfiguriert der Verwalter lediglich die IP-Adresse des jeweiligen Nodes, alles weitere übernimmt die CMC. Dort stellt der Administrator den Cluster zusammen, konfiguriert Disks und RAID-Level, die virtuelle IP des iSCSI-Targets und die Server-Zuweisung. In unserem Setup verwalten die VSA-Nodes kein Disk-RAID, da dieses vom physischen RAID-Controller im ESX-Host bereits übernommen wird.

In einem produktiven Setup muss der Verwalter ein getrenntes iSCSI-Netz mit eigenen Switches oder zumindest einem separaten VLAN einrichten, so dass sich Network-RAID-Traffic und LAN-Daten nicht ins Gehege kommen.

Das Test-Setup ist zügig abgeschlossen und das iSCSI-Target an die ESX-Hosts angebunden. Auf den ersten Blick erscheint das Setup kurios: Der ESX-Host reicht physische Platten an eine VM durch um sie von dort selbst als iSCSI-Shared-Storage zu nutzen. Mit der Funktion des Network-RAID macht das Ganze dann aber wieder Sinn.

In den Tests schalten wir unter anderem ohne Vorwarnung einen VSA-Node einfach ab und das Failover-Setup funktioniert wie erwartet. Die VMs arbeiten einfach weiter und nachdem der Node zurückkehrt, synchronisiert sich der VSA Cluster binnen weniger Minuten.

Fazit

HPs VSA kann in kleinen Installationen oder Filialen tatsächlich ein physisches SAN-Array ersetzen. Bei der Konfiguration der Hosts ist jedoch Vorsicht geboten. Es bedarf eines lokalen RAID-Arrays für die ESX-Konfiguration und die VSA-Systemplatte. Getrennt davon kommen Datenvolumes zum Einsatz. An der CMC-Anwendung darf HP aber noch ein wenig optimieren. Die Bedienung ist nicht immer schlüssig und das Tool an sich wenig überschaubar. Der Preis beginnt bei rund 5.000 Euro pro VSA.