Im Test: Double-Take Flex - SDI
Booten via Netzwerk
Analysten weisen immer wieder darauf hin: Es ist der Betrieb der IT, der stets die größten Kosten verursacht. Ganz unterschiedliche Lösungen sollen helfen, Desktops und Server zentral bereitzustellen und zu administrieren. Im LANline-Test musste "Double-Take Flex" zeigen, ob es diese Aufgaben lösen kann.
Analysten weisen immer wieder darauf hin: Es ist der Betrieb der IT, der stets die größten Kosten verursacht. Ganz unterschiedliche Lösungen sollen helfen, Desktops und Server zentral bereitzustellen und zu administrieren. Im LANline-Test musste „Double-Take Flex“ zeigen, ob es diese Aufgaben lösen kann.
Fast alle Hard- und Softwareanbieter reden gern von der „dynamischen IT“ oder „dynamischen Infrastrukturen“, die es für die Systemprofis zu erstellen und verwalten gilt. Das amerikanische Softwareunternehmen Double-Take macht keine Ausnahme, auch wenn viele Anwender bei diesem Firmennamen zunächst mehr an Hochverfügbarkeit und Disaster-Recovery oder ganz allgemein an Lösungen zur Datensicherung denken dürften. Das Produkt Flex zielt in eine Richtung, die auch von anderen Herstellern mit Software für die Bereiche Provisioning und Deployment bedient wird. Als prominentes Beispiel sei etwa der Provisioning Server von Citrix genannt.
Das auffälligste Merkmal von Flex ist der der Einsatz von iSCSI. Mithilfe dieses Protokolls wird es für den Administrator möglich, im Prinzip beliebigen Systemen so genannte Boot-Volumes zuzuweisen. Diese kann er dann allesamt vom gleichen Netzwerk-Volume im iSCSI-SAN ausrollen und hochfahren.
Der grundsätzliche Vorteil dieser Art der zentralen Verwaltung ist schnell klar: Die Systembetreuer können so nicht nur verschiedene neue Workstations oder Server bereitstellen, sondern diese auch gut absichern. Double-Take nutzt in diesem Zusammenhang zwei Begriffe, nämlich SDI für Streaming Desktop Infrastructure und VDP für Virtual Disk Provisioning (mehr dazu in LANline 2010/02 ab Seite 24). Grundsätzlich können dabei sowohl die Betriebssysteme als auch die gewünschten Anwendungen per Shared-Images im Netzwerk zentral bereitgestellt werden – in der Regel im SAN-Speicher, während die eigentliche Arbeit der Betriebssysteme und Anwendungen auf dem Client- oder auch Server-PC erfolgt.
Dadurch lassen sich sowohl Client-Systeme ohne eigene Festplatte als auch „Rich Clients“ verwenden. Double-Take spricht dabei von Server- oder Storage-basierenden Anwendungen, denn der Server oder der Speicher im iSCSI-Storage fungiert bei dieser Lösung als virtuelle Festplatte für die Client-Systeme in Netzwerk.
Prinzipiell funktioniert Flex also auf die gleiche Art und Weise, wie es auch andere Systeme zum Provisioning oder auch zur Desktop-Virtualisierung tun. Allerdings kommt hier nur das iSCSI-Protokoll zum Einsatz, während viele andere Anbieter auf proprietäre UDP-basierende Protokolle zur Übertragung setzen. Double-Take betont hingegen, dass iSCSI nicht nur universeller sei, sondern auch die Kosten deutlich geringer.
Auf diese Weise haben Anwender nicht nur die Möglichkeit, bereits bestehende iSCSI-Speicher zusammen mit der Software zu nutzen, sie erhalten außerdem auch einen iSCIS-Server mitgeliefert: Das Produkt enthält mit Double-Take Flex Storage Server eine Software, die es ermöglicht, von jedem Windows-Server aus dessen Speicherplatz als iSCSI-Target im Netz zur Verfügung zu stellen. Damit kann sowohl Speicher, der dem Windows-System als NAS (Network Attached Storage) als auch direkt mit dem Server verbundener Speicher (DAS – Direct Attached Storage) via PATA, SATA, SAS oder SCSI als Target angelegt werden. Dies gilt natürlich auch für Speicher, der auf „echten“ SANs zur Verfügung steht, also via Fibre Channel oder iSCSI. Der Unterschied besteht nur darin, dass es sich bei den ersten um Software-iSCSI-Targets handelt, während die LUNs (Logical Unit Number) auf den SAN-Geräten hardwarebasierende Targets darstellen, was aber sowohl für die Anwendungen als auch die Nutzer völlig transparent geschieht.
Der Client nimmt Kontakt auf
Das Einsatzszenario der Flex-Lösung unterscheidet sich ebenfalls kaum von dem anderen Lösungen aus diesem Umfeld: Die prinzipielle Konfiguration eines Clients erfolgt dadurch, dass die Boot-Reihenfolge im BIOS des Systems so eingestellt wird, dass der Start via Netzwerkkarte die höchste Priorität hat. Damit ist bereits eine besonders wichtige Vorgabe beschrieben: Die Systeme, die so aus dem SAN heraus starten sollen, benötigen zwingend einen Netzwerkadapter mit PXE-2.0-Unterstützung. Das so genannte Preboot Execution Environment (PXE) ist eine Technik, die es Systemen ermöglicht, einen netzwerkbasierenden Boot-Vorgang durchzuführen, was überhaupt erst den Einsatz von Diskless-Clients ermöglicht. Dazu setzt PXE die Protokolle TCP/IP, UDP, DHCP und TFTP sowie eine Firmware-Erweiterung mit festgelegten APIs auf der Client-Seite ein. Das Client-System startet, und via TFTP (Trivial File Transfer Protocol – ein einfache Übertragungsprotokoll, speziell für das Laden von Betriebssystemen oder auch bestimmter Konfigurationen über das Netz) wird ein Bootstrap vom Server heruntergeladen.
Nun geht der zweite Server des Flex-Pakets an sein Werk: Der Flex Management Server, der unter anderem einen PXE-und einen TFTP-Server enthält, kann auf die Anfragen der Client-Systeme im Netzwerk reagieren. Das Bootstrap-Programm kontaktiert wiederum den Flex-Management-Server, dessen Aufgabe darin besteht, den Client direkt mit dem iSCSI-Provider zu verbinden. An dieser Stelle kann aber auch eine Authentifizierung mittels Active Directory erfolgen, was dem Administrator die Möglichkeit eröffnet, beispielsweise Disk-Images an bestimmte Anwendergruppen zu verteilen, die zuvor im Verzeichnisdienst festgelegt wurden. Da es sich bei iSSCI um eine Punk-zu-Punkt-Verbindung handelt (nähere Informationen dazu im Kasten „Das iSCIS-Protokoll“ unten), besteht danach eine direkte Verbindung zwischen dem Client und dem SAN-Storage im Netzwerk.
In der Praxis
Die Flex-Software lag zum Test in Form einer ISO-Datei zum Download vor und stand nach dem Brennen auf einer DVD als boot-fähiges Medium zur Verfügung. Auf der DVD waren alle Teile der Lösung in der Version 3.11 zu finden: Dazu gehören die zwei bereits erwähnten Server wie auch die Client-Software und eine ausführliche Dokumentation in HTML. Die Dokumentation steht ausschließlich in diesem Format zur Verfügung. Auf Nachfrage gab uns Double-Take die Auskunft, dass man sie auch weiterhin nur so auszuliefern gedenke und nicht als gedrucktes Handbuch. Dabei könnte ein gedrucktes Handbuch doch dem Administrator ein Offline-Studium ohne „Druckorgie“ ermöglichen.
Weiter gibt es sowohl die Software als auch die Dokumentation aktuell nur in englischer Sprache. Laut Double-Take steht jedoch eine Lokalisierung auf der Roadmap, aber „eher für Ende des Jahres“. Dies ist ebenfalls diskussionswürdig, sieht der Hersteller doch den Mittelstand beziehungsweise den „gehobenen Mittelstand“ und Organisationen mit großen Verwaltungsstrukturen (also durchaus auch Teile der öffentlichen Verwaltung) als Zielgruppe. Bei diesen Kunden verlangt oft schon die Ausschreibung eine deutschsprachige Schnittstelle. Zudem entsteht ein merkwürdiges Sprachengemisch, wenn die Double-Take-Server konsequenterweise Gebrauch von der MMC (Microsoft Management Console) machen, die natürlich auf einer deutschen Server-Version in deutsch gehalten ist.
Die Testinstallation wurde auf einem Windows Server 2008 R2 durchgeführt, auf dem in der Server-Rolle auch ein Hyper-V-Server lief, der seinerseits das Netzwerk und die Client-Systeme zur Verfügung stellte. Ein solcher Testaufbau eignet sich auch für Administratoren sehr gut dazu, sich einen Eindruck vom Aufbau und den Möglichkeiten von Flex zu machen. Double-Take stellt die Software zu diesem Zweck auch auf der eigenen Web-Seite zur Verfügung.
Aufbau einer virtuellen Testumgebung
Wir sind bei der Installation nach der Schritt-für-Schritt-Anleitung vorgegangen, die der Hersteller als „Quick Start“ mitliefert. Dabei ist es zunächst einmal wichtig, einen korrekt konfigurierten DHCP-Server im Netzwerk zu verwenden, da sonst ein Booten über das Netzwerk mittels PXE nicht möglich ist. Double-Take empfiehlt eindringlich den Gebrauch des Microsoft-DHCP-Servers, was in unserem Fall durch den Einsatz des Windows Server 2008 R2, der diese Rolle ohnehin im Testnetzwerk innehatte, kein Problem darstellte. Ein weiterer wichtige Hinweis, der besonders bei einem Aufbau per Virtualisierung wichtig ist: Wenn der Management-Server der Flex-Lösung und der DHCP-Server auf dem gleichen Server arbeiten, muss der DHCP-Server bei der Installation des Management-Servers bereits aktiv und autorisiert sein, denn nur so kann der Flex-Management-Server ihn erkennen und die nötigen Einstellungen vornehmen.
Der nächste Schritt besteht dann darin, ein iSCSI-Target anzulegen. Wer bereits iSCSI-Systeme in seinem Netzwerk betreibt, kann diese verwenden und muss den Schritt nicht separat ausführen. Eine Besonderheit dieser Lösung besteht aber gerade darin, dass es mithilfe des Flex-Storage-Servers möglich ist, auf einem Windows-System direkt einen Festplattenbereich als iSCSI-Target zu verwenden. In einem Testszenario ist diese Option sehr praktisch und kann die Entscheidung für einen Einsatz positiv beeinflussen. Die zuvor erstellte DVD bietet die Installation beider Flex-Server an, was auf unserem Windows Server 2008 auch problemlos gelang.
Danach kann der Administrator das entsprechende Target auf dem Windows-Server mithilfe eines Assistenten anlegen (Bild 1). Vorsicht ist dabei nur geboten, wenn an den Server Festplatten per USB angeschlossen sind: Der Storage-Server legt zwar problemlos eine entsprechende VHD-Datei (Virtual Hard Disk) an, bei einem späteren Zugriff darauf gibt es jedoch Probleme. Wer die Beschreibung allerdings genau befolgt, sollte nicht in die Falle stolpern: Dort heißt es, dass es sich um direkt via PATA, SATA, SAS oder SCSI mit dem System verbundene oder über NAS bereitgestellte Platten handeln muss, die als Targets dienen können. Die Größe des Targets muss dabei so gewählt sein, dass sie mindestens der Größe des anzulegenden Flex-Clients entspricht.
Anschließend gilt es, den Flex-Management-Server zu installieren und zu konfigurieren, was zugleich auf dem Windows-Server drei zusätzliche Dienste installiert und aktiviert. Diese sind für die korrekte Funktion der Lösung entscheidend. Ein Blick in die Management-Konsole zeigt anschließend, dass der PXE-, der TFTP- und der eigene Flex-Management-Server-Dienst bereit stehen. In dieser Konsole erfolgt auch die Konfiguration eines Flex-Portals und des Targets, wobei dort das zuvor angelegte Target auszuwählen ist. Dies geschieht durch einen Rechtsklick auf den Eintrag „ Portals“, der sich im rechten Teil der Management-Konsole befindet. Über die IP-Adresse (oder auch den DNS-Namen des Zielsystems) lässt sich das Ziel auswählen. Die Anwendung kann das Zielsystem nach verfügbaren Targets abfragen, die sich dann einzeln oder allesamt dem Portal zuordnen lassen. Für eine einfache Auswahl sollte auf dem Server-System, das den Management-Server beherbergt, der iSCSI-Initiator von Microsoft aktiv sein. Dies ist zwar nicht unbedingt nötig, bei der hier verwendeten Testinstallation tauchten aber einige Verbindungsprobleme zu Client-Systemen erst nach der Installation des Initiators auf dem Server nicht mehr auf – ein Hinweis in der Installationsanleitung macht glücklicherweise auf dieses mögliche Problem aufmerksam.
Installation der Client-Systeme
Mit den zuvor geschilderten Schritten war in erstaunlicher kurzer Zeit die Installation der Server-Komponenten beendet. Bedenkt man, dass zum Funktionieren der Lösung nicht einmal beide Server nötig sind, so stellt sich dieser Teil der Installation als sehr schnell und einfach dar. Danach kann sich der Administrator der Konfiguration der Client-Systeme zuwenden. Die erforderliche Software findet sich ebenfalls auf der Installations-DVD. Bemerkenswert: Die DVD spielte bei der Installation auf einem Windows-7-Client, auf dem die 64-Bit-Variante von Windows Ultimate installiert war, auch automatisch einen 64-Bit-Client auf.
Die Installation findet im Prinzip immer die richtige Netzwerkkarte im Client-System und zeigt sie dann gleich mitsamt ihrer – für das Starten über das Netzwerk wichtige – MAC-Adresse an. In diesem Zusammenhang noch ein wichtiger Hinweis für alle, die mit virtuellen Clients arbeiten, die unter Hyper-V aktiv sind: Es ist bei Hyper-V nur möglich, über das Netzwerk zu booten, wenn bei den Client-Systemen explizit die so genannte „ältere Netzwerkkarte“ verwendet wird – das neuere Standardmodell erkennt die Client-Software nicht korrekt. Alle weiteren Schritte bei der Client-Installation, zu denen auch die Auswahl des entsprechenden iSCSI-Targets gehört, unterstützt ein Assistent. Wichtig auch dabei: Der iSCSI-Initiator sollte auf dem Client installiert und aktiv sein. Die Installation der Client-Software auf den XP-Systemen kümmert sich auch um diesen Punkt. Weiter benötigt die Client-Software auf den Client-Systemen das Dotnet-Framework von Microsoft mindestens in der Version 2.0, wenn der Anwender den Assistenten verwenden will, eine Entscheidung, die allerdings nur bei den XP-Systemen auftauchen kann, da Windows Vista und Windows 7 bereits mit den nötigen Bibliotheken ausgestattet sind. Nach dem Umstellen der Boot-Reihenfolge im BIOS des Client-Systems, bei dem der Start über das Netzwerk an die erste Stelle rückt, kann der Rechner nun ohne lokale Festplatte vom Target starten. In der Management-Konsole auf dem Server kann der Administrator die neuen Clients anlegen, indem er im rechten Bereich der Konsole auf den Eintrag „ Clients“ klickt. Er muss dazu den Namen und die MAC-Adresse des Clients eingeben. Allerdings ist die Software auch dazu in der Lage, alle Client-Systeme anzuzeigen, die bereits versucht haben, den Server per PXE-Boot zu erreichen und bisher dort noch nicht erfasst waren.
Bevor jedoch ein Client direkt von einem SAN booten kann, ist ein vorbereitetes Image auf das SAN-Device zu kopieren. Bei der Installation der Client-Software kopiert das Client Deployment Tool auch ein Hilfsprogramm (System Copy) mit auf den Rechner. Dies erlaubt dem Administrator, ein Master-Image „seiner“ Installation auf dem SAN abzulegen. Das Ganze funktioniert natürlich nur, wenn das Client-System über eine lokale Platte verfügt, auf der ein Systemverwalter das gewünschte Betriebssystem installiert hat. Danach kann er dieses per „copy“ mit Hilfe des Tools auf das Speichergerät übertragen. Dazu muss das iSCSI-Target, auf das ein Image gelegt werden soll, in der Datenträgerverwaltung des lokalen Systems als Festplatte montiert sein. Bei neuen Betriebssystemen wie etwa Windows 7 kann der Administrator ein Betriebssystem auch direkt auf dem iSCSI-Target installieren, was im Test ebenfalls reibungslos funktionierte. Die Flex-Deployment-Tools, die auch direkt von der DVD starten, erlauben es zudem, eine lokale Platte direkt auf ein Target zu kopieren.
Die Targets können in der Flex Management Konsole auf verschiedene Arten arbeiten, wobei es beim Aufspielen eines Master-Images wichtig ist, den Modus auf den Wert „exclusive“ zu stellen, sodass nur ein Client aktuell auf dieses Ziel greifen kann. Im späteren Betrieb, bei dem gleichzeitige Nutzung und gleichzeitiger Zugriff auf die Images einer der Vorteile dieser Lösung darstellen, ist dieser Modus in „shared“ zu ändern.
Fazit
Dieser Test kann nur einen groben Überblick über die vielfältigen Möglichkeiten und Fähigkeiten von Flex bieten. Insgesamt konnte die Software im Testumfeld voll überzeugen. So gelingen beispielsweise Installation und Inbetriebnahme sehr schnell. Ein erfahrender Administrator sollte mithilfe der mitgelieferten umfangreichen HTML-Dokumentation keine Schwierigkeiten haben, die Software nach den Erfordernissen seines Netzwerks zu installieren und zu konfigurieren. Besonders haben uns die einfache Handhabung bei der Verteilung der verschiedenen Images und die Flexibilität beeindruckt, die sich dabei durch die Auswahl verschiedener Abbilder für die Clients ergibt.
Das iSCSI-Protokoll
Die Storage Networking Industry Association hat die Spezifikation für den iSCSI-Standard erstellt, und die IETF (Internet Engineering Task Force) hat diesen dann im RFC 3720 festgehalten (Quelle: Wikipedia).
Die Abkürzung iSCSI steht für Internet Small Computer System Interface. Dabei handelt es sich um ein Internet-Protokoll, das es IP-basierend ermöglicht, Speicher direkt über das Netzwerk anzusprechen. Die SCSI-Kommandos, wie sie auch von gewöhnlichen SCSI-Host-Controllern an die entsprechenden Festplatten in einem Computer- oder Storage-System geschickt werden, können mithilfe dieses Protokolls in TCP/IP-Pakete „verpackt“ werden und auf diese Weise über das Netzwerk laufen. So lassen sich Speichergeräte direkt über das Netz sowohl in einem Intranet als auch über sehr lange Distanzen (WAN oder Internet) mittels einer Punkt-zu-Punkt-Verbindung ansprechen. Da das Protokoll bidirektional arbeitet, kann es auch dazu dienen, die passenden Daten als Antwort auf eine Anfrage zurück zu senden.
Genau wie man es vom „normalen“ SCSI-Protokoll kennt, kommt auch dabei eine Art Controller zum Einsatz, der für die Kommunikation zuständig ist. Er trägt in diesem Fall die Bezeichnung „ Initiator“ und wird direkt vom Betriebssystem gesteuert. Ein Vorteil dieser Technik besteht daran, dass es sich bei den Speichergeräten um beliebige Geräte wie Festplatten, Bandlaufwerke und optische Laufwerke handeln kann. Bei einer iSCSI-Installation heißen sie „Targets“. Ein weiterer Vorteil ist, dass die Zugriffe auf diese iSCSI-Targets für Anwender und die Anwendungsprogramme völlig transparent sind, sie erscheinen wie lokale Festplatten und lassen sich auch von den Windows-Systemen wie solche einbinden.
Als Nachteile dieser Technik gelten unter anderem die geringere Geschwindigkeit im Vergleich zu den bekannten Fibre-Channel-SANs und die erhöhte Belastung auf den Server-Systemen durch das Protokoll. Das Geschwindigkeitsproblem im Netzwerk lässt sich jedoch durch den Einsatz schnellerer Ethernet-Lösungen deutlich verringern. Auch für die erhöhte CPU-Last der Server-Systeme gibt es Lösungen: Dort kommen so genannte TCP/IP-Offload-Engines und/oder I/OAT-Lösungen (I/O Acceleration Technology) zum Einsatz, die eine deutliche Entlastung der Server-CPU bewirken.
Lesen Sie mehr zum Thema
