Installationen mit mehreren Vmware-Hosts benötigen Shared-Storage. Die Anforderungen an das Speichernetz unterscheiden sich dabei von Konfigurationen mit physischen Hosts. Je nach Leistungsanspruch eignen sich neben Fibre-Channel auch SAS und iSCSI.
Von Max Lessel
VMware-Cluster setzen Shared-Storage voraus, um Dienste wie Hochverfügbarkeit und das Verschieben virtueller Maschinen zur Laufzeit zu ermöglichen. Dabei kann der Hypervisor eine ganze Reihe verschiedener SAN-Technologien einsetzen, auf Wunsch auch gleichzeitig. Neben dem klassischen Fibre-Channel setzt sich iSCSI als Speichernetzwerk immer stärker durch und auch SAS lässt sich in kleineren Umgebungen problemlos verwenden. Daneben steht NFS als »zum SAN missbrauchtes NAS« zur Verfügung, wenn auch mit Abstrichen. Allerdings stellt ein Vmware-Cluster andere Voraussetzungen an ein SAN, als das physische Server bislang getan haben.
Viele Pfade ins SAN
Eine klassische SAN-Konfiguration verwaltet kleinere Arrays für bestimmte Aufgaben. RAID-1-Spiegel stellen System- und Applikationsplatten, während kleinere RAID-5-Verbände als Datenspeicher fungieren. Der Verwalter legt dabei für jeden Server und jeden Dienst eigene Arrays an, so wie das viele Softwarehersteller vorgeben. Diese Konfiguration lässt sich beim Übertragen physischer in virtuelle Maschinen mit Hilfe des Raw-Device-Mappings direkt übernehmen, stellt jedoch nicht die optimale Konfiguration dar. Dem Administrator fehlen dann die Funktionen, welche das VMFS3-Cluster-Dateisystem von Vmware zu bieten hat. Dazu zählen VM-Snapshots und alle damit verbundenen Dienste. Beispielsweise nutzt der »Data Recovery Agent« diese Funktion, um laufende VMs zu sichern.
Ein Vmware-Cluster bevorzugt daher eine SAN-Konfiguration mit großen SAN-Volumes für das VMFS-Dateisystem. Das kommt auch der Performance zugute, da größere Arrays mit vielen Spindeln schneller arbeiten als kleinere. Dennoch ist dabei Vorsicht geboten: Pro VMFS-Volume besteht stets nur eine aktive SAN-Verbindung von jedem Vmware-Host, was die Geschwindigkeit des jeweiligen Volumes auf das Maximum eines SAN-Links beschränkt. Während das bei 8-Gbit/s-FC-Anbindungen kein Problem darstellt, kann das bei iSCSI-SANs zu Engpässen führen. Pro verfügbarem SAN-Link sollte der Administrator daher je ein VMFS-Volume anlegen und die aktiven VMs verteilt speichern. Aktuell bleibt diese Konfiguration statisch. Für eine der kommenden Vmware-Versionen hat der Hersteller jedoch eine Dynamikfunktion angekündigt. Ähnlich dem DRS, welches VMs je nach Belastung der Server-CPUs zwischen den ESX-Hosts mit Vmotion verschiebt, soll es künftig ein Storage-DRS geben, welches die Disks der VMs dynamisch per Storage-Vmotion auf weniger belastete VMFS-Volumes verlegt.
Um mehrere Pfade vom ESX-Host zum Storage auch nutzen zu können, muss auf dem ESX-Host ein passender Multipath-Treiber laufen. In der Basiskonfiguration beherrscht Vmware zwar Multipathing, setzt es jedoch nur für Failover-Dienste ein. Erweiterte MPIO-Treiber für EMC-FC-Speichersysteme liefert Vmware beispielsweise mit, schließlich gehört Vmware zu EMC. Andere Hersteller liefern eigene Treiber, welche sich mit Hilfe der VCLI oder des Update-Managers auf ESX- und ESXi-Hosts nachrüsten lassen. Dell fertigt beispielsweise für seine »EqualLogic«-iSCSI-Arrays einen entsprechenden Vmware-MPIO-Treiber, welcher die Performance dank verbesserter Pfadauslastung nahezu verdoppelt.
Die Verlagerung der vollständigen VMs auf VMFS-Datenträger bringt aber auch ein paar Nachteile. Speichermanagement-Funktionen von Arrays wie NetApps »Syncmirror«, EMC »Snapview« oder Equallogics »Auto Snapshot Manager« funktionieren nur dann, wenn das VM-Betriebssystem einen direkten Zugriff auf das Speichersubsystem hat. Das kann über N-Port-Virtualisierung (FC) Raw-Device-Maps (FC, iSCSI, SAS, NFS) oder iSCSI-Initiatoren innerhalb der VM (iSCSI) erfolgen.
In der Praxis hat sich daher die Kombination aus VMFS-basiertem VM-Storage und Raw-Device-Anbindung etabliert. Während die System- und Applikationslaufwerke der virtuellen Maschinen auf VMFS-Datenträgern lagern, setzen Datenpartitionen Raw-Devices oder eine iSCSI-Direktanbindung ein. Die Sicherung der Systeme-Daten übernimmt dann eine in Vmware integrierte Image-Backup-Applikation wie der Data-Recovery-Agent, die Datenbestände sichert der Verwalter über das jeweilige Speichersystem. Diese Architektur hat zudem den Vorteil, dass jede VM mindestens zwei Datenpfade zum Storage nutzt und über diese Parallelisierung Flaschenhälse vermeidet.
Grundlegende Auswahlkriterien
Egal für welche der SAN-Technolgien sich Vmware-Administratoren entscheiden, einige Grundkriterien muss jedes SAN-System erfüllen.
- Vmware-Zertifiziert: VMFS ist nicht irgendein Dateisystem im Stil von ext3, reiser oder FAT32. Es handelt sich um ein leistungsfähiges Cluster-Dateisystem mit Mindestanforderungen an Antwortzeiten und Performance. Ein SAN-Speicher für Vmware muss daher auch zwingend von Vmware zertifiziert sein und in der offiziellen HCL (Hardware Compatibility List) des ESX-Software-Pakets stehen. Gerade bei Billiganbietern ist hier Vorsicht geboten: Wenn der Hersteller verspricht, dass seine Lösung mit Vmware funktioniert, heißt das noch lange nicht, dass diese Kompatibilität seitens Vmware bestätigt wurde.
- Vmware-Support: Für den reibungslosen und performanten Betrieb eines SAN-Arrays bedarf es, wie erwähnt, einer guten Multipath-Lösung, da sich die MPIO-Basisfunktionen auf ein Minimum beschränken. Bei den großen Herstellern wie EMC, Netapp, Hewlett-Packard und Dell bekommt man zudem Vsphere-Plugins, welche die systemeigenen Backup- und Snapshot-Features in das VM-Management integrieren.
- Multiport-Anbindung: Gerade bei iSCSI-Speichersystemen kann die vergleichsweise geringe Bandbreite eines einzelnen 1-Gbit/s-Links im Vmware-Umfeld zum Flaschenhals werden. Daher sollten sich iSCSI-Subsysteme mit mehreren Interfaces am SAN anbinden. Auf der Gegenseite benötigt auch der Host-PC eine entsprechende Zahl an NICs, welche ausschließlich mit dem iSCSI-SAN kommunizieren.
- Virtualisierte Arrays: Speichersysteme in Kombination mit Vmware erreichen eine bessere Performance, wenn sie größere Arrays mit virtuellen LUNs betreiben. Ein Beispiel: Ein einzelnes 8-Platten-RAID-5-Array mit zwei LUNs darauf wird schneller arbeiten, als zwei 4-Platten-Arrays mit je einer LUN.
- Schnelle Disks: SATA-Platten mögen groß und günstig sein. Als Primärspeicher für Vmware taugen sie nur bedingt. Ein SATA-Laufwerk liefert gerade mal 80 IOPs/s (1 IOP = Transfer eines 8-KByte-Datenblocks). Ein typisches 8-Platten-RAID-5-Array (mit Spare) bringt es daher gerade mal auf 480 IOPs (lesend). Das genügt für nur wenige VMs und auch nur dann, wenn diese keine IO-lastigen Applikationen (SQL-Server, Exchange) betreiben. Diese Dienste fordern 1.000 IOPs/s und mehr. Anders verhalten sich da die SAS/FC-Disks mit 15.000 Touren, die fast 200 IOPs erreichen. Um Kosten zu sparen, lässt sich auch ein Mix aus kleinen SAS- und großen SATA-Arrays verwenden, so dass IO-intensive VMs (SQL, Exchange) auf schnellen und voluminösen VMs (Fileserver) auf getrennten Subsystemen arbeiten.
- Fehlertoleranz: Jede Vmware-Installation setzt mindestens zwei Server ein, um Ausfälle abfangen zu können, aber meistens nur ein Storage-System. Das muss dann die entsprechende Ausfallsicherheit liefern. Simple Speichersysteme, welche aus einem PC-Server mit ein paar Platten und einer Storage-Software bestehen, reichen hier nicht aus.
- Angepasste Konfiguration: Die Subsysteme einiger Hersteller erlauben dem Verwalter erweiterte Einstellungen für die Cache-Verwaltung. Damit lassen sich die Arrays für das eine oder andere Einsatzgebiet optimieren. Sehr häufig zielen die Werkseinstellungen auf OLTP-Workloads mit acht KByte Blockgröße und einer 90/10-Verteilung auf Lese- und Schreiboperationen. Unter Vmware kommen im Schnitt größere Blöcke im Bereich 20 bis 50 KByte zum Einsatz bei einer IOP-Verteilung von 70/30 (Verhältnis Lesen/Schreiben).
Fazit: Lösungen für Vmware-Cluster jeder Größe
SAS, iSCSI und FC liefern gute Dienste als SAN-Technologie für Vmware-CLuster, wenn die Verwalter das jeweilige SAN passend konfigurieren. SAS zielt auf kleine Umgebungen bis drei ESX-Hosts und skaliert aktuell nicht darüber hinaus. iSCSI etabliert sich als günstige SAN-Technologie für kleine und mittelgroße Unternehmen. Dabei kommt es mehr als bei den anderen Technologien darauf an, dass der Verwalter das SAN korrekt konfiguriert und optimiert. FC ist und bleibt das leistungsstärkste, aber auch teuerste SAN für große Vmware-Umgebungen.
SAN-Technologien im Überblick
NFS (»Network File System«)
Das Network-File-System ist eigentlich kein SAN, sondern ein recht flotter Dateiservice für Unix/Linux. Es funktioniert als Primärspeicher für Vmware, aber nur mit ein paar herben Einschränkungen. Bei NFS arbeitet jeder Dateizugriff als einzelner Thread, was der Parallelisierung entgegenkommt. Jedoch halten sich die MPIO-Features des Netzwerkprotokolls in Grenzen. Erschwerend kommt hinzu, dass ein NFS-Server ab einer gewissen Anzahl von Verbindungen spürbar an Performance verliert. So mag eine kleine Vmware-Umgebung mit zwei Servern, weniger als zehn VMs und einem gut konfigurierten NFS-Server noch akzeptabel funktionieren, aber bei steigender VM-Zahl bricht die Performance ein. VMs auf NFS-Freigaben können zudem nicht die vielen Features des VMFS-Dateisystems nutzen.
NFS findet dennoch sein Einsatzgebiet in Vmware-Installationen. Für kleine, funktionelle Test-Setups reicht erst einmal ein freier Linux-NFS-Server. Zudem lässt sich eine NFS-Freigabe gut für die Datensicherung einsetzen. Der Verwalter erzeugt dazu nur Klone seiner VMs auf einer NFS-Freigabe und kann diese dann einer beliebigen Backup-Software übergeben. Zudem eignen sich NFS-Freigaben als Speicher für Templates und ISO-Bibliotheken.
SAS (»Serial Attached SCSI«)
Serial-Attached-SCSI dient nicht nur als Platteninterface. Via SAS-HBA lassen sich externe Subsysteme von mehreren Servern aus ansprechen. Ein SAN mit eigenen Switches entfällt und die ESX-Hosts verbinden sich direkt mit dem SAN-Speicher. Je nach Gerät offerieren Hersteller Konfigurationen mit mehreren aktiven Ports an gespiegelten Controllern. Das Speichersystem »Engenio 2600« von LSI (in OEM-Versionen auch bei Dell, Sun und IBM im Programm) beispielsweise integriert zwei gespiegelte SAS-to-SAS-RAID-Controller mit je vier Hosts-Ports. Damit verbinden sich maximal vier Server fehlertolerant mit einem Subsystem bei einer Bandbreite von 6 Gbit/s pro Kanal.
Die Nachteile von SAS als SAN: Auf Grund der kurzen erlaubten Kabellängen (weniger als 5 m) lässt sich mit einem SAS-SAN keine ausfallsichere Architektur mit Servern in getrennten Brandabschnitten aufsetzen. Mehr als vier Server können nicht simultan mit dem Speichersystem kommunizieren. Zwar gibt es bereits erste SAS-Switche, doch diese sind aktuell nicht von Vmware zertifiziert. Kosten: Ein SAS-SAN braucht keine Switche, dafür aber zwei rund 400 Euro teure SAS-HBAs pro ESX-Host.
iSCSI
Das Ethernet-IP-SAN hat sich in der Zwischenzeit als echte Alternative zu FC etabliert, vor allem bei kleineren Installationen. iSCSI wird gerne als SAN beworben, das mit bereits vorhandenen Netzwerkressourcen arbeitet. In der Praxis muss der Verwalter dennoch ein getrenntes SAN mit eigens dafür abgestellten Ethernet-Switches und NIC-Ports bereitstellen. Die richtige Konfiguration ist dabei auch nicht so trivial, wie es manche Hersteller anpreisen. Einfache (unmanaged) Switche eignen sich nicht für ein iSCSI-SAN. Sie müssen Jumbo-Frames, große Port-Buffer sowie Flow-Control und eine Cut-Through-Engine vorweisen, damit das iSCSI-San die bestmögliche Performance erreicht. Normale LAN-Adapter belasten die CPU, welche die TCP- und iSCSI-Paketverwaltung übernehmen muss. Zwar bauen viele Server-Hersteller bereits ToE-Karten (TCP- und iSCSI-Offload) in ihre Server, jedoch beherrschen die aktuell gängigen Offload-Adapter von Broadcom leider keine Jumbo-Frames. In der Praxis kommen daher eher Software-Initiatoren mit Jumbo-Unterstützung zum Einsatz, weil diese schneller als ToE-Adapter mit kleinen Blöcken arbeiten.
Da iSCSI pro Port nur 1 Gbit/s pro Sekunde liefert, braucht das Ethernet-SAN möglichst viele Pfade zwischen Initiatoren und Targets sowie ein sauber konfiguriertes Multipathing.
Kosten: In der Praxis erfordert iSCSI pro ESX-Host eine zusätzliche Quad-Port-Ethernet-Karte für zirka 400 Euro. Dazu kommen zwei Ethernet-Switche (Ausfallsicherheit) mit den aufgelisteten Funktionen, die pro Stück um die 2000 Euro kosten.
FC (»Fibre Channel«)
Der »Vater aller Speichernetzwerke« ist Fibre-Channel. Nach wie vor liefert diese SAN-Technologie die beste Performance und die höchste Zuverlässigkeit für große Speichernetzwerke und ist allen anderen hier aufgeführten Technologien überlegen. Leider ist FC nach wie vor eine teure Angelegenheit. Jeder ESX-Host braucht zwei Host-Bus-Adapter zu je 400 Euro. Dazu kommen zwei FC-Switche, die pro Stück mit rund 5.000 Euro zu Buche schlagen. Auch die Glasfaser-Patchkabel kosten mehr als normale CAT5e-Netzwerkleitungen.
Zudem trifft man die passenden FC-Speichersysteme auch eher im teuren Segment an. Diverse kleine Hersteller offerieren zwar auch verlockend günstige FC-Lösungen. Doch bei diesen ist es häufig nicht weit her mit der eingangs erwähnten Vmware-Zertifizierung.
Kommentar schreiben
