FreeNAS als XenServer Storage einrichten

Ziel dieses Artikels ist es, eine halbwegs Quick’n’Dirty Anleitung zu bieten, wie man mit FreeNAS auf Basis einer VM ein NFS-Share und ein iSCSI-LUN bereitstellt und an XenServer ankoppelt. Dies kann im Training zur Demonstration der XenServer-Storage-Anbindung genutzt werden oder um eigene Skills zu schärfen. Für Schulungsteilnehmer ist dies sicherlich von grösserem Wert als der konfuse Umgang mit den NetApp Simulatoren…

Los geht’s!

Zuallererst das FreeNAS ISO von www.freenas.org herunterladen. Für dieses Blog und als tragbares LAB verwende ich VirtualBox von Oracle (Ex-Sun) auf einem Notebook. Hier lässt sich eine neue VM als Operating System “BSD”, Version “FreeBSD” erstellen. 512 MB Ram sollten der VM mindestens konfiguriert werden, wer ernsthaft mit FreeNAS arbeiten will, sollte besser 1 GB einplanen – offiziell sind sogar 4GB Ram als Minimalanforderung genannt. Aus Platzgründen läuft die VM bei mir mit 512 MB.

Harddisks? Gerne. Bitte beachten, dass eine dedizierte Installationsplatte benötigt wird. Diese Festplatte kann später nicht Bestandteil eines Raid werden oder anderweitig Daten beinhalten, hier wird nur FreeNAS wohnen. Die Minimalanforderung ist hier 2 GB und sollte auch nicht unterschritten werden.

Um später aber tatsächlich Storage bereitstellen zu können, sollten noch ein bis zwei weitere Hardddisks zusätzlich zur VM hinzugefügt werden. Eine einzelne Disk würde reichen, dann lässt sich allerdings nicht mit den Raid-Optionen experimentieren, ich wähle daher drei Festplatten mit einer Grösse von jeweils 12 GB (dies wird genug für meine kargen Lab-Bedürfnisse sein). Alle drei Festplatten hänge ich in der VM an einen virtuellen SCSI Controller vom Typ Lsilogic.

Dann wird von der FreeNAS 8 ISO gebootet. Im Setup wähle ich die Option 1 zur Installation.

Danach wähle ich die 2 GB Festplatte als Installationsziel aus – man beachte, dass aufgrund der FreeBSD Plattform hier nicht die Linux-typischen Festplattenbezeichnungen /dev/sda etc auftauchen!

Nach der obligatorischen Warnmeldung über möglichen Datenverlust auf dem Zieldatenträger startet die Installation. Nach knapp einer Minute kommt die Erfolgsmeldung und die Bitte um einen Reboot. Die Installations-CD kann nun wieder ins Archiv verbannt werden.

Nach dem Reboot wird zunächst die Netzwerkkarte konfiguriert – die weitere Konfiguration erfolgt dann über den Webbrowser (habe übrigens bislang nur schlechte Erfahrungen mit dem IE 9 an dieser Stelle gemacht, Firefox 4 hingegen funktioniert durchgehend).

Also nach dem Reboot erstmal Option 1 wählen:

Ich lege die IP Adresse auf 192.168.88.30 fest, diese Adresse wird später zur weiteren Konfiguration per HTTP angesprochen.

Ende des Text-basierten Setups, weiter geht es im Browser – als Logon kann der Benutzer admin mit dem Kennwort freenas verwendet werden.

Nun wird der Storage vorbereitet, dazu im Hauptmenü erst einmal das Storage-Icon anklicken:

Dann auf das linke Icon (create volume) klicken:

UFS und ZFS bieten unterschiedliche Optionen an, abhängig von der Anzahl der ausgewählten Festplatten. Um es hier etwas simpler zu halten (und weil sich bei mir in Wahrheit sowieso alles auf der Notebookplatte abspielt) wähle ich die drei x 12 GB Disks aus, entscheide mich für Suns ZFS (welches Raid-Funktionen ins Dateisystem integriert) und wähle Raid-Z als Raid-Level aus. Danach mit “Add Volume” bestätigen. ACHTUNG! Es gibt keine weitere Warnung vor dem Löschen der ausgewählten Festplatten.

Der neue Zustand sollte nun wie folgt aussehen:

Wer fragt sich nun, warum aus 3 x 12 GB nur knapp 20 GB netto-Platz resultieren? Raid-Z bietet ähnlich wie Raid5 die Speicherung von Prüfsummeninformationen, daher verliere ich die Kapazität einer Festplatte. Zudem verliere ich 2 GB pro Disk als Swap-Space an das System (einstellbar unter System, Settings, Advanced => Swap Size).

Als nächster Schritt kommt nun die Anlage eines Datasets (bei ZFS so üblich, soll hier nicht weiter thematisiert werden. Wem es hilft: wäre ZFS vergleichbar mit LVM, dann haben wir soeben eine VolumeGroup angelegt (heisst bei ZFS Pool), und legen nun ein Logical Volume an (heisst bei ZFS Dataset).

Ich benenne das Dataset als “dataset1”, alle anderen Optionen bleiben auf dem Ausgangswert stehen.

Nun werden wir die NFS Share für den XenServer einrichten. Dazu bitte Sharing, Unix und “Add Unix Share” anklicken:

Das Comment-Feld ist lediglich ein Bezeichner, mit dem man seine Shares auf dem FreeNAS hinterher leichter verwalten kann. XenServer benötigt später den Volume-Path für den Zugriff. Als “Maproot User” sollte hier “root” eingetragen werden, und bitte nicht den Haken bei “All Directories” vergessen, sonst kann das Storage Repository zwar von XenServer angelegt aber nicht benutzt werden.

Mit OK bestätigen, danach ist die Share / der Export eingerichtet. Nun müssen wir noch den NFS-Dienst starten, dies geschieht in der Kategorie “Services”:

Dieser NFS-Export (“Share”) kann ab jetzt vom XenServer benutzt werden. Szenenwechsel: XenCenter, New Storage, NFS VHD

Als ShareName ist in diesem Fall 192.168.88.30:/mnt/vol1/dataset1 anzugeben. Voilà, unser NFS Storage ist fertig.

Wer noch nicht zu müde ist, kann im weiteren Verlauf noch ein iSCSI LUN einrichten. Sämtliche Optionen hierzu sind allerdings nicht wie erwartet unter dem Menüpunkt “Sharing” sonder unter “Services” untergebracht.

Hier ist der iSCSI Dienst zunächst einzuschalten und dann mit dem Schraubenschlüssel-Symbol daneben zu bearbeiten.

Als erstes legen wir ein Portal an, auf dem dann später nach Targets und LUNs gesucht werden kann.

Wer mehrere Netzwerkkarten besitzt und konfiguriert hat, kann durch die IP 0.0.0.0 auch eine Bindung des Portals an alle IPs des Systems erreichen. Ich gebe stattdessen die konfigurierte IP der VM an.

Nun fehlt die Definition der “Initiators”, die später auf unsers “Targets” zugreifen dürfen, streng genommen sind hier nun die IQNs (=iSCSI-Namen) der XenServer gefragt (können im XenCenter auf der General-Lasche der jeweiligen Hosts eingesehen und verändert werden). Mir reicht für Trainingszwecke der freie Zugriff für alle (ALL).

Nun legen wir zwei Dinge an, zunächst unabhängig voneinander, später werden sie miteinander verknüpft: ein Target und ein “extent”, also eine LUN. Zuerst das Target:

Das Target braucht vor allem einen Namen (target1 bei mir), einen Typ (disk) und die Zuordnung zu einem Portal, über das sich das Target ansprechen lässt. Ausserdem wird hier geregelt, welche iSCSI Geräte (initiators) sich mit dem Target verbinden dürfen (Alle, wie oben geregelt).

So, nun fehlt noch der Speicherplatz, den wir über dieses Target als iSCSI LUN zur Verfügung stellen wollen. FreeNAS nennt das hier “extent”:

Das Extent bekommt einen Namen zugewiesen, bei dem Pfad zum extent handelt es sich in Wahrheit um eine Datei innerhalb eines Dataset, die dann von aussen wie eine LUN angesprochen werden kann.

Als Pfad gebe ich somit das zuvor erstellte Dataset an, ergänzt um den gewünschten Dateinamen des extents, alternativ kann für iSCSI auch ein eigenes Dataset erstellt werden. Bei der Grössenangabe können die gebräuchlichen Abkürzungen wie MB/GB/TB benutzt werden.

Nun kommt schon fast der Schlussstein, extent und target werden zusammengebracht:

ACHTUNG: Laut einem Hinweis im Readme zur Version 8 (stand 24.08.2011) hat FreeNAS noch Probleme damit, mehr als eine LUN/extent pro Target zu präsentieren. Man ist also halbwegs auf der sicheren Seite, wenn man pro LUN/extent ein eigenes Target anlegt.

Szenenwechsel: Im XenCenter kann nun der bereitgestellte Speicherplatz als iSCSI Storagerepository angelegt werden. Der Weg hierhin ist XenCenter, New Storage, Software iSCSI

Hier ist nun unter Punkt 1 die Adresse der FreeNAS VM anzugeben (dies ist das konfigurierte Portal), über Discover IQNs (Punkt 2) können wir dann das Target finden (oder mehrere), sowie über Discover LUNs (Punkt 3) die konfigurierten extents auswählen. Sofern dieser Storage noch nie in Benutzung durch XenServer war, erscheint noch eine Meldung, die abfragt, ob die LUN formatiert werden darf. ACHTUNG, auch hier droht Datenverlust, wenn man eine falsche LUN gewählt hat…(irrelevant in unserem kleinen heile-Welt-Szenario).

Presto! XenServer verfügt nun über ein weiteres Storage Repository.