Zu den dominanten Trends, die heute die Unternehmens-IT prägen, gehören Virtualisierung und ein ungebremstes Datenwachstum. Während anfangs vor allem Server virtualisiert wurden, hat sich der Virtualisierungs-Gedanke inzwischen auf weiter Front durchgesetzt. Er wird nicht mehr nur für Server, sondern auch auf Speicher und Netzwerke angewandt. Und Marktführer VMware nutzt seine dominante Position auf dem Virtualisierungs-Markt, um gleich ein komplettes Software Defined Datacenter (SDDC) als neues Paradigma der Rechenzentrumswelt auszurufen – mit bemerkenswertem Erfolg.

Auf dem Weg dahin ist eine Virtualisierung der Speicherlandschaft selbstverständlich. Angestrebt wird ein vollständig virtualisierter, heterogener Speicherpool, wo alle Daten entsprechend ihrer Bedeutung fürs Unternehmen auf Speichermedien unterschiedlicher Qualität hinterlegt werden. Dabei werden zukünftig unstrukturierte Daten dominieren: E-Mails und ihre Anhänge, Videos, Audio-Aufnahmen, Maschinenlogs und vieles mehr. Diese Formate passen nicht mehr ins Standard-Datenbankschema. Ihr Volumen explodiert geradezu, gefördert durch Technologien wie Videostreaming oder M2M. In aktuellen Studien finden sich immer aberwitzigere Datenvolumina und Wachstumsraten– inzwischen soll das Datenuniversum schon in wenigen Jahren auf Yottabytes angewachsen sein. Wie aber handhabt man die zu erwartenden unstrukturierten Datenmassen am besten in einer IT-Welt, die vor allem aus komplett virtualisierten Rechenzentren in Form von Private- oder Public-Clouds organisiert sein wird?

Das FC-SAN verliert seine Dominanz

Hier stellt sich neben der Frage nach der am besten geeigneten Virtualisierungslösung (die der Markt derzeit relativ eindeutig beantwortet) auch die nach Protokoll und Filesystem für die in jeder IT-Architektur vorhandene Speicherumgebung. Während vor einigen Jahren das SAN (Storage Area Network) mit Fibre-Channel-Vernetzung (FC) noch selbstverständlich dominierte, expandiert die sehr leistungsfähige, aber teure Technologie inzwischen auf den Märkten kaum noch. Das liegt nicht zuletzt an den bereits erwähnten unstrukturierten Daten. Denn die etablierte Block-Technologie der mit FC vernetzten Systeme passt für sie nicht optimal.

Eine einheitliche Blockgröße passt am besten zu strukturierten Daten, wie sie klassische Datenbanken vorhalten. Für die heute dominanten unstrukturierten Daten sind blockbasierende Speicher- und Transporttechnologien zu unflexibel und zu teuer. Daher gewinnt sogenannte IP-Storage immer mehr an Boden. Sie arbeitet auf den unteren Netzwerkebenen mit konventioneller IP-Technologie, wie wir sie aus dem Internet kennen. Diskutiert werden heute vor allem die Alternativen iSCSI oder NFS (Network File System).

Allerdings zeigen viele Anwendungsumgebungen, dass für ein leistungsfähiges iSCSI aus Geschwindigkeitsgründen doch Fibre-Channel implementiert werden sollte, da iSCSI recht bandbreitenabhängig ist. Administratoren monieren, dass selbst beim Einsatz von TCP/IP-Offload-Karten ein Ethernet-basierendes iSCSI nur dann schnell genug arbeitet, wenn lediglich einige wenige Zugriffe zu erledigen sind. Kommt es dagegen, wie im Alltag durchaus üblich, zu zahlreichen kleinen Zugriffen, leidet die Geschwindigkeit.

Zudem bringt iSCSI den Nachteil mit, dass es wie FC blockbasiert arbeitet, für die zu erwartenden großen unstrukturierten Datenmengen also gerade nicht optimal geeignet ist. Zwar kostet iSCSI weniger als eine Fibre-Channel-Infrastruktur, aber die Leistung ist vergleichsweise auch etwas schlechter. Dazu kommt, dass man eigentlich, um Verfügbarkeitsprobleme bei hoher Netzbelastung zu vermeiden, auch für iSCSI eine separate Switching-Infrastruktur aufbauen müsste.

Alternative NFS

Der Übergang zu NFS löst daher zwei Probleme auf einmal: Einerseits die Migration auf das in den meisten Netzen genutzte IP/Ethernet mit den heute schon definierten Wachstumspfaden in Richtung 100 und sogar 400 Gbit/s, andererseits den Übergang zur file- statt blockorientierten Speicherung. Denn erstere entspricht sehr viel besser dem prognostizierten Datenwachstum, das sich, wie oben schon erwähnt, vorwiegend im unstrukturierten Bereich vollziehen wird.

NFS, im Linux-Bereich schon lange das Filesystem der Wahl, stammt ursprünglich aus der Sun-/Unix-Welt. Im Windows-Bereich eröffnet sein Pendant SMB (Server Message Block), dessen Version 3 sich gerade in Vorbereitung befindet, den Zugang zu gespeicherten Daten. Allerdings lässt sich NFS auch auf Windows-Servern nutzen, wobei in der Praxis in gemischten Systemen mit Windows- und Unix-Systemen die Verwendung von SMB, kombiniert mit Samba auf den Unix-Maschinen, dominiert. Microsofts Hypervisor »Hyper-V« setzt wie Windows auf SMB v3.

NFS ermöglicht den Zugriff auf ganze Dateien über Netzwerke und zwar so, als lägen die Daten auf der lokalen Festplatte. Sein Filesystem umfasst den gesamten Storage-Pool mit allen seinen heterogenen Speichermedien.

Datenmassen lassen sich mit weniger Aufwand verwalten, da man bei NFS die Größe freigegebener Shares ohne Betriebsunterbrechung verändern kann. Ein weiterer Vorteil von NFS ist, dass gleichzeitig viele Anwender auf dieselben Daten zugreifen können. Dies ist sehr wichtig für Anwendungen wie VDI (Virtual Desktop Infrastructure), deren kritischer Moment immer dann eintritt, wenn morgens viele Mitarbeiter gleichzeitig ihre Rechner anschalten und auf die zentralen Systeme zugreifen.

NFS passt im Prinzip gut zu den gängigen Internet-Technologien, die den meisten Administratoren inzwischen aus der täglichen Arbeit vertraut sein dürften. So kommuniziert das Filesystem auf Schicht 3 über IPv4 respektive IPv6. Beim Einsatz innerhalb von Vmware-Umgebungen wird auf Schicht 3 (Transport) das vertraute TCP (Transmission Control Protocol) genutzt.

Doch zu Zeiten der NFS-Entwicklung war von Server-Virtualisierung außerhalb des Mainframes noch nicht die Rede. Entscheidend ist daher für den Einsatz in den heutigen virtualisierten Datenzentren, wie NFS mit der dominanten Virtualisierungs-Plattform Vmware zusammenarbeitet.

NFS und Vmware: ein harmonisches Paar

Vmware unterstützt IP-Storage seit 2006, als Version 3 des ESX-Servers veröffentlicht wurde. Seitdem kann sowohl iSCSI- als auch NFS-Storage von mehreren ESX-Servern gemeinsam genutzt werden. Seit Version 5.0 unterstützt Vmware »vSphere« NFS mit Steuer- und Kontrollfunktionen. In der aktuellen, kürzlich angekündigten Version 6 von Vsphere wurde der NFS-Client stark verbessert.

Leider unterstützen die meisten Anbietern von Software-Defined-Storage-Lösungen NFS nicht. Dabei bietet diese Lösung gerade im Vmware-Umfeld eine Reihe von Vorteilen. Ein NFS-Datastore lässt sich mit wenigen Klicks in einer Vmware-Umgebung installieren. Der Administrator muss dafür durch weniger Bildschirme navigieren als für die Installation von Blockspeichersystemen, allerdings braucht der Datenspeicher eine IP-Adresse. Diese und der Mount-Point, ein Ordner für den Datenzugriff, sind auf den Installations-Screens einzutragen. Das dürfte aber aus der IP-Umgebung den meisten Administratoren vertraut sein. Nach dem Bereitstellen von NFS am ESXi-Host sehen diese Hosts alle Metadaten und Dateien auf dem NFS-Array oder -Server. Die Kommunikation läuft dabei über ein Protokoll auf Basis von RPC (Remote Procedure Call). Vorteilhaft ist hier, dass keine teuren Fibre-Channel-Karten oder iSCSI-fähige Ethernet-Karten erforderlich sind, sondern normale Ethernet-Adapter ausreichen, die über einen VMkernel-Port (vmknic) angesprochen werden. Bei großen Datenmengen erfolgt der Direktzugriff mehrere Anwender auf Files direkt über NFS, Vmwares Filesystem VMFS, das in solchen Umgebungen vergleichsweise langsam arbeitet, braucht man nicht.

Für die Daten kann man unter NFS jedes beliebige Speichersystem verwenden, das sich über Ethernet anbinden lässt. Teure Investitionen in proprietäre Hardware werden damit überflüssig. Alle Speicherkapazitäten werden beispielsweise durch die Kombination von Nexenta »NexentaStor« und NFS zu einem hybriden, gut zu unstrukturierten Datenmassen passenden Storage-Pool verbunden, der allen ESXi-Hosts gleichermaßen zugänglich ist. Damit das Speichern so schnell wie gewünscht von statten geht, unterstützt Nexentastor in Zusammenhang mit NFS die Ethernet-Varianten 10 Gbit/s und 40 Gbit/s. Das dürfte auch anspruchsvollen Anforderungen gerecht werden. iSCSI dagegen unterstützt 40 Gbit/s noch nicht.

Auf 1 Gbit/s-Verbindungen sollte man möglichst nicht zurückgreifen. Die höhere Bandbreite ist sinnvoll, da der gesamte Speicherdatenverkehr in Form einer einzigen Session abgewickelt wird. Bandbreite aggregiert man, indem man mehrere Datenstores mit jeweils eigenem Pfad einrichtet. Es ist aber möglich, Netzwerkadapter paarweise zusammenzuschalten, um den Speicherzugriff ausfallsicher zu gestalten. Dafür, dass keine einzelnen Pakete verloren gehen, sorgt die in TCP festgelegte Sendewiederholung verlorengegangener Pakete. Mit den aus anderen Ethernet-Infrastrukturen vertrauten Mechanismen lassen sich auch in Nexenta-Umgebungen unter NFS VLANs für den Speicherzugriff aufbauen, um Datenströme zuverlässig getrennt zu halten. Sollen virtuelle Maschinen dupliziert oder verschoben werden, muss man dies trotzdem nicht mittels ESX tun, sondern kann den häufig schnelleren und unkomplizierteren Weg über NFS wählen.

Kurz: Die teilweise aus dem Umgang mit Ethernet und Internet vertraute Technik und das Fehlen spezieller Hardware-Anforderungen ermöglichen es gerade mittelständischen Firmen oder Unternehmen mit straffem Budget, mittels NFS innerhalb ihrer Vmware-Umgebung eine skalierbare, kostengünstige heterogene Speicherinfrastruktur mit vorhandenen Speicher-Ressourcen oder kostengünstiger Standard-Hardware aufzubauen. Deren Administration erfordert nicht das Erlernen komplett neuer, zumeist herstellerspezifischer Technologien. Vielmehr werden viele Netzwerkadministratoren in der Lage sein, mit einem Speichersystem unter NFS auch ohne umfangreiche Schulungen umzugehen. Auch beim Troubleshooting hat diese Lösung unabweisbare Vorteile, denn man kann generische Werkzeuge wie »Wireshark« einsetzen, um Fehler zu finden.

Backup mit NFS: Granular bis zur Einzeldatei

Besondere Stärken zeigt Nexentastor zusammen mit NFS beim Backup. Denn durch den einheitlichen NFS-Share müssen nicht mehr umständlich LUNs (Logical Units) verwaltet werden, Partitionierungen sind überflüssig. Vorhandene NFS-Shares können ohne Konfigurationsaufwand erweitert werden. Da Nexentastor anders als viele andere Speicherprodukte mit flexibler Blockgröße arbeitet, passt sich die Lösung im Zweifel diesbezüglich an die Anforderungen der Backup-Lösung an. Die Größe von einzelnen Speichersystemen, ist nicht wie bei anderen Technologien auf 64 TByte begrenzt – angesichts der schnell wachsenden Kapazitäten von Speichermedien sicherlich eine sinnvolle Lösung.

NFS konfiguriert virtuelle Disks für virtuelle Maschinen (VMDK) mit Thin-Provisioning. Das heißt, es wird den Applikationen mehr Speicherraum zugewiesen als physisch tatsächlich vorhanden ist. Erst wenn die physischen Speicher bis zu einer vordefinierten Schwelle gefüllt sind, fordert das System dazu auf, die physische Kapazität zu erweitern. Das reduziert die Platzverschwendung im Speichersystem. NFS beherrscht auch die Deduplizierung, also das automatisierte Entfernen doppelt oder mehrfach vorhandener Daten. Dennoch lassen sich auch unter NFS auf Wunsch virtuelle Disks im VMFS-Thick-Format einrichten, der Anwender bleibt also hinsichtlich der Konfiguration virtueller Festplatten für seine virtuellen Maschinen auch mit NFS voll flexibel.

Sind Backups in Vmware-Umgebungen nötig, muss man nicht VCB (Vmware Consolidated Backup) verwenden, wenn nicht Vmwares eigenes Filesystem VMFS auf den Systemen läuft. Das hat Vorteile, denn VCB verlangt, dass Agenten in jedes Gastbetriebssystem auf den VMs integriert werden. Der Restore ist immer dann kompliziert, wenn, was häufig geschieht, nicht die gesamte virtuelle Maschine wieder hergestellt werden soll, sondern nur Teile davon bis hin zu einzelnen Dateien.

Einfacher lässt sich beim Wiederherstellen die gewünschte Granularität bei einem Backup mit NFS und regelmäßigen Snapshots des gesamten Arrays erreichen. Für eine zügige Datenwiederherstellung kann man den gewünschten Snapshot verfügbar machen (mounten) und dann die Daten selektiv so feingranular wiederherstellen, wie das von den Anwendern gewünscht wird. Dass unter Nexentastor eine nichtflüchtige SSD-Festplatte, die ausfallsicher konfigurierbar ist, als Cache dient, beschleunigt Backup-Vorgänge weiter und sorgt für Sicherheit.

Storage für Oracle DB: Mit NFS schrumpft der Verwaltungsaufwand

Auch in anspruchsvollen Oracle-Datenbankumgebungen ist NFS sinnvoll. Statt einer teuren Lösung aus einer Hand, lohnt es sich, Oracle-Speicher-Ressourcen ohne Rückgriff auf proprietäre Hardware via Nexentastor und NFS bereitzustellen. Denn in dieser Konstellation kann NFS die oben bereits aufgeführten Stärken effektiv ausspielen. So erspart man sich beim Oracle-Backup das umständliche Anpassen der LUN-Größen (LUN Adjustment). Gesichert wird wie unter NFS üblich der gesamte NFS-Share. Auch die Blockgröße der in der Datenbank gespeicherten Daten muss nicht angepasst werden – NFS macht dies dank seiner flexiblen Blockgröße unnötig.

NFS kombiniert mit Nexentastor spart durch seine SSD-Cache-Architektur zudem, verglichen mit proprietären Storage-Lösungen, viel Hardware ein. NFS verwendet in der Regel synchronisierte Schreibvorgänge (auch der asynchrone Betrieb ist aber möglich), die jeweils durch eine Bestätigung (Committ) abgeschlossen werden. Als Cache für diese Bestätigungsvorgänge dient ein schneller, nichtflüchtiger SSD-Speicher, so dass selbst bei Stromausfall für Konsistenz der Datenbank-Daten gesorgt ist. Alle zehn Sekunden werden die bis dahin aufgelaufenen Bestätigungsvorgänge in einem einzigen Schreibvorgang auf die Festplatte verschoben. Damit auch der Ausfall eines Adapters der Verfügbarkeit der im SSD-Cache gespeicherten Daten nichts anhaben kann, lässt sich dieser unter Nexentastor doppelt anbinden. Wer es noch sicherer möchte, kann den Schreib-Cache auch doppelt auslegen und mit RAID 10 konfigurieren. Dies dürfte gegenüber einer konventionellen Lösung noch immer erheblich günstiger sein.

Nexentastor spart also auch im Oracle-Umfeld Zeit und Raum: Eine Storage-Umgebung unter Nexentastor mit vierzig Nearline-SAS-Platten und SSD-Cache entspricht hinsichtlich der Datenkapazität nach Messungen von Nexenta  einer konventionellen Lösung mit 192 15K-Festplatten – unter anderem, weil in der konventionellen Lösung die Redundanz direkt auf der Festplattenebene durch RAID hergestellt werden muss, um Datenverluste auf der Hardware-Ebene zu vermeiden. Hier werden also rund 150 Festplatten eingespart und zudem die Energie, die man braucht, um sie rotieren zu lassen.

Lösung fürs Zeitalter der unstrukturierten Daten

Fazit: Mit Nexentastor und NFS als Filesystem bekommen IT-Manager eine gelungene Synthese aus virtualisierter Speicherlandschaft und einem Dateisystem, das vorwiegend vertraute Internet-Technologie verwendet, um Daten systemweit verfügbar zu machen. Diese Lösung unterstützt aktuelle Netzwerk- und Speichertechnologien wie 10 und 40 Gbit/s Ethernet, Thin-Provisioning und Deduplizierung. Sie setzt SSD-Technologie sparsam, aber höchst effektiv ein.

Dabei senkt die Kombination von Nexentastor und NFS durch seine fortschrittlichen Caching-Mechanismen auf Basis von SSD-Speicher den Bedarf an konventionellem Festplattenspeicher erheblich, ohne dass deswegen Kompromisse bei Leistung oder Geschwindigkeit nötig wären. Weil der Umgang mit NFS und den Internet-Protokollen mit denen NFS arbeitet, den meisten Administratoren vertraut und proprietäre Hardware nicht mehr erforderlich ist, sinken Schulungs- und Wartungsaufwand. Gleichzeitig kann man jederzeit auf modernere Speichermedien umsteigen, ohne dabei auf die Lock-In-Mechanismen etablierter Hersteller Rücksicht nehmen zu müssen. Kurz: Nexentastor mit NFS ist eine Speicheralternative für das Zeitalter des Internet und der unstrukturierten Daten.