Festplattenplatz via iSCSI

Inhaltsverzeichnis

Das Netzwerkprotokoll iSCSI knüpft in Rechenzentren sogenannte Storage Area Networks (SAN), die Server-Systeme bedarfsgerecht mit Festplattenspeicher versorgen. Die Verkabelung der Speichernetze mit herkömmlichem Gigabit-Ethernet via TCP/IP und iSCSI ist deutlich kostengünstiger als spezielle Fibre-Channel-Verbindungen, die für hohe Transferleistung und Redundanz ausgelegt sind.

Mittlerweile können auch die Desktop-Betriebssysteme iSCSI und einige NAS-Geräte der gehobenen Preisklasse als "iSCSI-Target" Speicherplatz freigeben. Auch Linux-Systeme stellen iSCSI-Freigaben bereit, etwa die NAS-Distributionen FreeNAS und Openfiler.

Anders als herkömmliche Netzwerkfreigaben, von denen Anwender etwa mit dem Microsoft’schen SMB-Protokoll Dateien abrufen können, überträgt iSCSI stets rohe Datenblöcke über die Leitung und funktioniert unabhängig von einem Dateisystem. Das spart Netzwerk-Overhead und verspricht hohen Datendurchsatz. Via iSCSI verlängert man quasi ein Festplattenkabel über das lokale Netzwerk, um es direkt an einen Client-PC anzuschließen. Die Daten laufen dabei über eine einfache TCP-Verbindung, der Server lauscht standardmäßig auf Port 3260.

Sobald man Windows mit einer iSCSI-Freigabe verbindet, taucht in der Datenträgerverwaltung eine zusätzliche Festplatte auf, die auf den ersten Blick nicht von einer lokalen physischen zu unterscheiden ist. Sie lässt sich wie gewohnt partitionieren und mit einem Dateisystem formatieren. In Heimnetzen und kleineren Büros kann das iSCSI-Protokoll nützlich sein, um bestimmten Anwendungen mehr Speicherplatz zu verschaffen, die nicht ohne Weiteres mit einer herkömmlichen Netzwerkfreigabe funktionieren. So zeichnet Microsofts Media-Center Fernsehsendungen normalerweise nur auf lokale Festplatten auf – via iSCSI lässt sich dafür auch eine Netzwerkfestplatte nutzen.

iSCSI-Freigaben sind allerdings nur für Punkt-zu-Punkt-Verbindungen geeignet: Das Protokoll kennt keine sicheren Mechanismen, um mit mehreren Anwendern gleichzeitig auf denselben Netzwerkspeicher zuzugreifen. iSCSI bietet einen Authentifizierungsmechnismus (CHAP), verschlüsselt die übertragenen Daten aber nicht selbst. Wer sichergehen will, dass im lokalen Netz niemand iSCSI-Daten auf der Leitung mitlesen kann, muss die Verbindung mit IPsec verschlüsseln.

Microsoft bietet ein iSCSI-Target nur mit dem spezialisierten Windows Storage Server an, Windows Server 2003 und 2008 können von Haus aus keinen Speicherplatz via iSCSI freigeben. Wer sich mit Linux als iSCSI-Target nicht anfreunden mag, findet hier die kostenlose Version der Software StarWind, mit der auch ein Windows-XP-PC Speicherplatz via iSCSI freigeben kann.

Es gibt bereits eine Handvoll NAS-Geräte, die als iSCSI-Target funktionieren; die günstigen Modelle kennen das Protokoll in der Regel aber nicht. In der iSCSI-Implementierung scheint es zudem Unterschiede zu geben: Von einem NAS-Gerät der Firma Thecus wollte ein Windows XP, das wir wie im Folgenden beschrieben für den Netzwerkstart vorbereitet hatten, nicht booten.

Linux als iSCSI-Target

Linux als iSCSI-Target

Auf einem Debian-verwandten Linux-System wie Ubuntu lässt sich der iSCSI-Server bequem mit der Paketverwaltung nachinstallieren:

sudo apt-get install iscsitarget

Die Konfigurationsdatei /etc/ietd.conf definiert die Freigaben. Im einfachsten Fall genügen dafür zwei Zeilen:

Target iqn.2009-02.local:ctsan Lun 0 Path=/dev/sda3,Type=fileio

Diese Angaben machen die iSCSI-Freigabe unter dem hinter Target angegebenen "iSCSI qualified name" (IQN) bekannt. Der kryptische String beginnt mit "iqn.", gefolgt von einer Jahreszahl und einer Monatsangabe, an die sich ein Domainname anschließt. In einem kleinen Netz kann man den Domainnamen beliebig wählen. Die Angabe des Jahres und des Monats ist im iSCSI-Standard vorgesehen, weil Domainnamen verfallen oder den Besitzer wechseln können. Hinter dem Doppelpunkt legt man einen frei wählbaren Bezeichner fest.

Die zweite Zeile bestimmt das freigegebene Speichermedium, im Beispiel ist es die komplette Partition /dev/sda3. Die Linux-Software akzeptiert hier beliebige Blockgeräte, LVM-Volumes und sogar Image-Dateien. Ein leeres, 4 GByte großes Image erstellt man etwa mit dem dd-Befehl:

dd if=/dev/zero of=image1.img bs=1K count=4M

Der Standardmodus fileio eignet sich sowohl für Images als auch für Partitionen. Mit der Option blockio reicht der iSCSI-Server die Zugriffe direkt auf ein Gerät durch und umgeht den Linux-Cache, was laut der Dokumentation bei bestimmten Server-Hostadaptern Vorteile verspricht.

Ist die Konfigurationsdatei angepasst, genügt es, den iSCSI-Server neu zu starten, um die Freigabe zu aktivieren:

sudo /etc/init.d/iscsitarget restart

Unter Windows kann man nun versuchen, das frisch definierte iSCSI-Laufwerk einzubinden. Den dafür nötigen "iSCSI-Initiator" findet Vistas Startmenü-Suchfeld. Für Windows XP bietet Microsoft den Initiator mit identischer Oberfläche zum Download an. Auf dem Reiter "Suche" lässt sich ein neues "Portal" mit der IP-Adresse des Linux-Servers hinzufügen.

Sogleich sollten auf der Seite "Ziele" die zuvor erstellten iSCSI-Freigaben auftauchen, die sich mit einem Mausklick auf "Anmelden" einbinden lassen. In der Datenträgerverwaltung erscheint daraufhin eine neue Festplatte. Wenn der iSCSI-Speicher noch leer ist, schlägt Windows wie bei einer fabrikneuen Platte vor, sie mit einem Master Boot Record oder als GPT-Datenträger zu initialisieren, sodass sie sich anschließend partitionieren und formatieren lässt.

Booten via Netzwerk

Booten via Netzwerk

Mit dem vom Open-Source-Projekt Etherboot (www.etherboot.org) entwickelten Bootloader gPXE kann man die Windows-Betriebssysteme und auch Linux von einer iSCSI-Freigabe booten. So lässt sich ein flüsterleiser Client-PC ohne eingebaute Festplatte etwa im Wohnzimmer betreiben, der alle Daten aus dem lokalen Netz holt und dort ablegt. Die herkömmliche Netz-Boot-Technik PXE verlangt eine aufwendigere Infrastruktur und kann weder XP noch Vista Starthilfe leisten. Lediglich das Mini-Windows PE (Preinstallation Environment; siehe Notfall-Windows 2009) lässt sich via PXE hochfahren.

Unsere Versuche, mit gPXE einen Windows-PC ohne lokale Festplatte zu betreiben, waren erfolgreich: Zwischen zwei via Gigabit-Ethernet verkabelten Standard-PCs maßen wir unter Windows XP mit dem Festplatten-Benchmark h2benchw einen Durchsatz von knapp 48 MByte/s – schneller als so manche Notebook-Festplatte.

In ihrem Wiki (www.etherboot.org) geben die Etherboot-Entwickler detaillierte Hinweise, wie man ein bootfähiges Betriebssystem auf eine iSCSI-Freigabe bringt. Die nötigen Handgriffe sind dort für alle Windows-Systeme seit Windows 2000 bis zur aktuellen Betaversion von Windows 7 sowie für mehrere Linux-Varianten beschrieben. Wir zeigen im Folgenden, wie man einige Probleme löst, über die wir beim Nachspielen gestolpert sind.

Direkt auf einer iSCSI-Freigabe kann man weder XP noch Vista installieren, deshalb gilt es zunächst, eine Installation vorzubereiten und sie als Image auf den Server zu spielen. Unsere Versuche, ein Testsystem unter VMware aufzusetzen und das davon kopierte Image via iSCSI zu booten, waren fruchtlos – für die ersten Schritte ist es wichtig, das Windows-System auf der identischen Hardware zu installieren, die später übers Netz booten soll. Insbesondere muss dieselbe Netzwerkkarte installiert sein, über die der PC später sein Betriebssystem lädt.

Um Windows XP für das Booten via iSCSI vorzubereiten, installiert man eine spezielle bootfähige Version von Microsofts iSCSI-Initiator (siehe Link am Ende des Artikels). Dem herkömmlichen Initiator fehlen einige zum Booten nötige Dateien. Im Etherboot-Wiki ist für XP zusätzlich der "SAN Boot Configurator" erhältlich. Das darin enthaltene Batch-Skript setup.bat installiert einen weiteren Treiber und stellt die Netzwerktreiber in der Startreihenfolge nach vorne, sodass XP sie beim Systemstart früh genug aktiviert.

Für Windows Vista sind diese Vorarbeiten nicht nötig; der bootfähige iSCSI-Initiator ist hier bereits an Bord und zusätzliche Treiber braucht man nicht. Bei unseren Versuchen startete Vista aber nur dann reibungslos via iSCSI, wenn im Quellsystem die Netzwerkkarte bereits installiert war.

Boot-Image kopieren

Boot-Image kopieren

Sind die Vorarbeiten erledigt, überträgt man das Betriebssystem-Image auf das iSCSI-Target. Die Etherboot-Entwickler empfehlen, dazu die physische Festplatte an den Server-PC anzuschließen und ihren Inhalt mit dem Befehl dd in eine Image-Datei zu kopieren. dd kann die Platte ab Sektor 0 samt ihres Master Boot Record kopieren, sodass sich das Image anschließend direkt als iSCSI-Target freigeben lässt. Das Quellsystem sollte dabei auf der ersten Partition liegen, dann genügt es – wie im Wiki beschrieben – mit dd vom Plattenanfang bis zum letzten Sektor der Partition zu kopieren.

Uns führte auch eine andere, deutlich bequemere Methode zum Ziel: Unter Windows kopierten wir das vorbereitete System zunächst im laufenden Betrieb mit der Software Drive Snapshot in eine Image-Datei. Die 30-Tage-Demo dieses Festplatten-Imagers reicht für diesen Zweck aus. Das Image spielten wir anschließend direkt auf das per iSCSI verbundene Laufwerk zurück. Mit XP klappt das reibungslos, solange der Quell-PC kein Multiboot-System mit mehreren Systempartitionen ist – auf diese Hürde gehen wir hier aber nicht ein.

Der Bootloader von Windows Vista reagiert zickiger auf eine geänderte Plattenkonfiguration. Während bei XP noch eine einfache Ziffer in der Datei boot.ini festlegt, von welcher Partition Windows startet, merkt sich Vista im kryptischen BCD-Store (Boot Configuration Data Store), auf welcher Festplatte seine Startpartition liegt und an welcher Position sie beginnt.

Die Platte identifiziert Vista dabei anhand ihrer Signatur, einem 8 Byte langen Wert, der im Master Boot Record hinterlegt ist. Damit Vista via Netzwerk bootet, muss das iSCSI-Laufwerk dieselbe Signatur wie die Quellfestplatte tragen. Drive Snapshot war es beim Zurückspielen auf das iSCSI-Laufwerk nicht gelungen, den BCD zu aktualisieren, und so beschwerte sich Vista beim iSCSI-Start mit der Fehlernummer 0x000000c, es könne die Datei winload.exe nicht finden. Der Start klappte, nachdem wir die Signatur des Ziellaufwerks der Quelle anglichen. Im laufenden Windows lässt sich das mit dem Kommandozeilenwerkzeug MbrFix bewerkstelligen: Zunächst liest man in der Datenträgerverwaltung die Datenträgernummern des Quelllaufwerks und des iSCSI-Laufwerks ab. Der Befehl

mbrfix /drive 0 readsignature

gibt die Signatur des Systemlaufwerks aus, die sich anschließend mit

mbrfix /drive [Datenträgernummer] writesignature [Signatur]

auf das iSCSI-Laufwerk übertragen lässt. Bevor Sie das auf die iSCSI-Freigabe geklonte Windows via Netzwerk starten, sollten Sie die Verbindung zur internen Festplatte trennen. Andernfalls könnte Windows, obwohl es via Netzwerk bootet, als Laufwerk C: wieder die Systempartition auf der Platte ansprechen, so wie es in der Registry des geklonten Systems unter HKEY_LOCAL_MACHINE/SYSTEM/MountedDevices hinterlegt ist. Wenn Windows XP aufgrund einer falschen Zuordnung sein Bootlaufwerk nicht findet, bleibt der Bootvorgang beim hellblauen Willkommen-Bildschirm stehen. Dann kann es helfen, die Registry des iSCSI-Systems von außen mit regedit zu bearbeiten und den Schlüssel MountedDevices komplett zu leeren.

gPXE

gPXE

Mehrere Wege führen zum Ziel, den iSCSI-fähigen Bootloader gPXE auf einem Client-PC zu starten, und ein Betriebssystem via Netzwerk nachzuladen. Für die ersten Versuche brennt man den Loader am besten auf eine Boot-CD. gPXE lässt sich auch von einer Diskette ausführen oder im Boot-ROM einiger Netzwerkkarten unterbringen. Im Etherboot-Wiki ist zudem beschrieben wie man den gPXE-Loader mit einer herkömmlichen, PXE-fähigen Netzwerkkarte aus dem LAN nachladen kann ("chainloading") – wir beschränken uns darauf, die Methode für Boot-CDs und USB-Sticks zu beschreiben.

Die Etherboot-Entwickler stellen auf ihrer Website ein praktisches Generator-Skript bereit, das eine nach den eigenen Wünschen konfigurierte Image-Datei erzeugt. Hier wählt man einen für den Ziel-PC passenden Netzwerktreiber aus, zur Wahl stehen derzeit über 650 Stück.

Um den richtigen Treiber zu erwischen, bringt man zunächst die PCI-ID der Netzwerkkarte in Erfahrung. Unter Windows lässt sich die ID im Gerätemanager in den Eigenschaften einer Netzwerkkarte ablesen. Auf dem Reiter "Details" finden Sie unter XP die gesuchte Information unter "Geräteinstanzerkennung", bei Vista heißt der Eintrag "Hardware-IDs".

Der vordere Teil der angezeigten kryptischen Strings verrät die ID des Herstellers ("VEN") und die des Geräts ("DEV").

Auf der Generator-Webseite wählt man mit Hilfe der IDs den passenden Eintrag aus der Liste der Netzwerktreiber aus. Die Webseite stellt sieben verschiedene Ausgabeformate zur Wahl: Ein "ISO bootable Image" brennt die Freeware ImgBurn bequem auf einen Rohling. Das "USB Keychain Disk Image" lässt sich auf einem USB-Stick installieren, etwa unter Linux mit dd.

Beim Start von der CD sollte der gPXE-Loader die Netzwerkkarte initialisieren und via DHCP eine IP-Adresse anfordern. Danach führt die Tastenkombination Strg-B auf die Kommandozeile, auf der etwa der Befehl

sanboot iscsi:192.168.0.77::::iqn.2009-02.local:ctsan

das auf dem angegebenen iSCSI-Target hinterlegte Betriebssystem nachlädt. Auf die IP-Adresse des Servers folgen hier vier Doppelpunkte und der Name des iSCSI-Target. Für Client-PCs, die vollautomatisch booten sollen, kann man diesen Parameter auf einem entsprechend konfigurierten DHCP-Server als Option "root-path" hinterlegen. Auf diese Weise lässt sich einem Client anhand der MAC-Adresse seiner Netzwerkkarte das iSCSI-Laufwerk zuweisen, von dem er booten soll.

Fehlersuche

Bevor der Start via iSCSI schließlich klappte, haben wir einige vergebliche Anläufe unternommen. Zweifel, ob der gPXE-Loader das iSCSI-Target überhaupt anspricht, kann man mit dem Netzwerksniffer Wireshark ausräumen, der auch das iSCSI-Protokoll analysiert. Wenn Windows von der Freigabe zu booten beginnt, dann aber abbricht, ist das Problem vermutlich bei der Konfiguration der Netzwerkkarte und der iSCSI-Treiber zu suchen. Den Startvorgang mit dem boot.ini-Parameter /bootlog protokollieren zu lassen, klappte auf unserem Testsystem nicht – vermutlich weil Windows den iSCSI-Speicher zunächst nur über die vom gPXE-Loader bereitgestellten BIOS-Funktionen ansprechen konnte, mit den nativen Treibern aber scheiterte.

Die Entwickler beschreiben im Etherboot-Wiki noch eine weitere Methode, um Windows beim Booten auf die Finger zu schauen: Mit den richtigen Boot-Parametern gestartet, gibt Windows über die serielle Schnittstelle interessante Debug-Informationen aus, die Microsofts Debugger Windbg auf einem weiteren PC auswerten kann. Damit erhärteten wir den Verdacht, dass unser Test-Windows die iSCSI-Freigabe zum entscheidenden Zeitpunkt nicht als Bootgerät einbinden konnte.

In vielen Fällen wäre es sicher praktisch, das auf einem iSCSI-Target installierte Windows abwechselnd auf verschiedenen PCs zu starten – allerdings ist Windows recht zimperlich, wenn es beim Hochfahren eine ganz andere Hardware vorfindet. Im Etherboot-Wiki erklären die Entwickler, wie man etwa zusätzliche Windows-Kernel und HAL-Dateien in das XP-Bootmenü einbindet, um beim Start die für die Hardware passenden Systemdateien wählen zu können. Hier findet man auch ausführliche Hinweise, wie man dem iSCSI-Windows die Netzwerkkarte eines weiteren Ziel-PC bekannt macht. (kav) (bb)