Ein Netzwerk ist das Rückgrat für die Kommunikation der Server untereinander. Über schnelle Switches werden so die Systeme verknüpft. Sie dienen aber auch den Clients als Zugangsweg zu den Servern. Zentrale Serverapplikationen, etwa ein Mail-Server oder eine Datenbankanwendung, sind über das Netzwerk durch die Anwender erreichbar. Ferner sorgen sie für den Zugriff auf die zentralen Speichersysteme, die in der Regel via iSCSI angebunden sind. Beim Einsatz des Hyper-V sind sie außerdem für den Transfer von virtuellen Maschinen durch Live Migration zuständig.
Im Zuge der neu aufkeimenden Cloud-Dienste steigt die Bedeutung des Netzwerks erneut an. Hierbei wird es - bei der Public Cloud - auf das Internet ausgedehnt. Nur spricht man nun nicht mehr von Applikationen, sondern von Diensten, die in der Cloud bereitgestellt werden. An die Stelle des "Mail-Servers im Datacenter oder Rechenzentrum" tritt dann eben der "Mail-Dienst in der Public oder Private Cloud". Der Vollständigkeit halber wird aber darauf hingewiesen, dass ein Mail-Dienst auch noch weitere Kriterien erfüllen muss, die über jene eines bloßen Serverdienstes hinausgehen. Die enorme Wichtigkeit des Netzwerks ist Grund genug uns dessen Konfiguration einmal näher anzusehen.
Verfügbar gemacht werden Server und Cloud-Dienste über ihre logischen Namen. Werden die Server in einer virtuellen Maschine betrieben, so muss außerdem eine Adressumsetzung erfolgen. Dies ist notwendig, weil die physischen Hosts in der Regel weniger physikalische Netzwerkkarten aufweisen als virtuelle Maschinen. Wenn der Server genügend Netzwerkkarten hätte, um jedem virtuellen Gast seine individuelle Netzwerkkarte zuzuweisen, wäre die Virtualisierung der Netzwerk-Interfaces überflüssig. Der Hypervisor könnte dann jedem virtuellen Gast die benötigten Interfaces direkt zur Verfügung stellen, und die Verwaltung dieser Netzwerkkarte würde durch das Betriebssystem des Gasts erfolgen. Hinsichtlich der Netzwerkanbindung wäre dann kein Unterschied zwischen virtuellen und physischen Systemen erkennbar.
Netzwerkschnittstellen virtualisieren
Da aber die wenigen physischen Netzwerk-Interfaces in der Regel zwischen den virtuellen Maschinen aufgeteilt werden, muss eine Zwischenschicht eingezogen werden. Dies ist der Hypervisor. Die Verwaltung der virtuellen Netzwerk-Interfaces erfolgt dann durch die Verwaltungs-Tools der Hypervisor-Hersteller, also durch die Werkzeuge von Microsoft, VMware oder etwa Citrix.
Beim Microsoft-Hyper-V erfolgt die Verwaltung der Netzwerk-Interfaces im Kontext des Hyper-V-Managers. Dieser sorgt, in Verbindung mit den darunterliegenden Hyper-V, für die Umsetzung der virtuellen Netzwerk-Interfaces auf die physischen Netzwerkkarten. Der Hyper-V-Manager hat aber immer nur einen Host im Fokus. Die Verwaltung bezieht sich folglich immer auf diesen einen Host. Wenn mehrere Hosts eingesetzt werden, reichen die Möglichkeiten des Hyper-V-Managers nicht aus. Auch bei der Übertragung von virtuellen Maschinen durch Live Migration auf einen anderen Host, versagt er.
Werden virtuelle Maschinen verschoben, müssen also andere Techniken eingesetzt werden. Dabei wird eine weitere Schicht zur Netzwerkverwaltung eingezogen. Ähnlich einen Netzwerk-Stack (nach ISO/OSI) werden dabei die Netzwerk-Interfaces beziehungsweise die IP-Adressen mehrstufig umgesetzt. Die unterste Stufe ist jene, die im Betriebssystem verwaltet wird. Dies passiert im Kontext des Server-Managers beziehungsweise der Systemsteuerung der Windows-Systeme.
Auf der nächsten Stufe der Netzwerkumsetzung kommt der Hypervisor ins Spiel. Am oberen Ende der Netzwerkumsetzung liegt der Virtual Machine Manager (VMM). Er wurde zusammen mit allen anderen Modulen des System Centers 2012 vor wenigen Wochen neu aufgelegt. Im Virtual Machine Manager 2012 bündelt Microsoft alle Hilfen zur Verwaltung von virtuellen Strukturen und Clouds. Er geht damit über die Möglichkeiten der Vorgängerversion, des VMM 2010, hinaus. Virtual Machine Manager 2010 hat die Verwaltung von virtuellen Systemen im Fokus. Der Virtual Machine Manager 2012 wiederum wird als Cloud-Verwaltungs-Tools betrachtet. In ihm finden sich daher auch die Möglichkeiten, die obere Netzwerkschicht in virtuellen Umgebungen zu verwalten.
Die Testumgebung für die Cloud
Für unseren Workshop benötigen wir ein Testszenario, das eine Microsoft-Private-Cloud beinhaltet. Unsere Umgebung bestand deshalb aus mehreren Hosts und dem Hyper-V-Manager. Auf einem der Systeme haben wir eine virtuelle Maschine eingerichtet und darin den Virtual Machine Manager als Gastsystem betrieben. Beim Einrichten der Testumgebung müssen ein paar Besonderheiten beachtet werden.
Da unsere virtuelle Maschine die externen Hosts verwalten soll, muss sie natürlich über das Netzwerk mit all diesen Systemen eine Verbindung aufbauen können. Ferner wird das Active Directory benötigt. Es hängt nun letztendlich an Ihrem Netzwerkdesign, welche und wie viele Netzwerk-Interfaces Sie Ihrem virtuellen Computer zuweisen wollen oder müssen. Bei der Nutzung des Assistenten können Sie jedoch nur ein Netzwerk-Interface direkt zuweisen. Wenn Sie mehrere Netzwerk-Interfaces benötigen, müssen Sie die weiteren Interfaces später zuweisen und konfigurieren.
Resource-Pools als Basis für die Cloud
Zum Umfang des Virtual Machine Managers gehören mehrere Komponenten: der VVM-Server, die Verwaltungskonsole, die Agenten und ein Self-Service-Portal. Für alle weiteren Verwaltungsfunktionen interagiert der Virtual Machine Manager 2012 mit den anderen Modulen des System Centers. Seit der Version 2012 hat der Virtual Machine Manager als Verwaltungsoberfläche das Ribbon-Interface. Zum Verwalten der Cloud-Strukturen greift er auf den Hyper-V zu.
Nach dem Setup und der Konfiguration des Virtual Machine Manager auf dem Verwaltungsrechner müssen Sie zuerst Ihre Ressourcen bereitstellen. Als Ressourcen bezeichnet der Virtual Machine Manager all jene IT-Baugruppen, die als Ausführgrundlage benötigt werden. Microsoft fasst alle IT-Ressourcen in Pools zusammen. Dies passiert unter der Option Add Resources. Ein Assistent hilft bei beim Einrichten und Konfigurieren und fragt alle benötigten Parameter ab. Als Computer-Ressource (Server) unterstützt Microsoft die drei gängigen Hypervisoren: den eignen Hyper-V-Server, den ESX-Server von VMware und den Citrix XenServer. Diese sind die Rechnersysteme mit Hyper-V, ESX-Hosts und XenServer-Systeme.
Das Netzwerk für die Cloud: der Netzwerk-Pool
Die Kommunikation mit weiteren Diensten innerhalb der Private Cloud erfolgt durch einen internen Netzwerk-Pool. In diesem bündelt der VMM alle vorhandenen Netzwerke-Interfaces und deren Konfigurationen. Aus den IP- und MAC-Adress-Pools werden dann die virtuellen Maschinen bedient. Zur Verwaltung einer privaten Cloud stellt der Virtual Machine Manager 2012 mehrere Hilfen und Assistenten bereit. Dazu ist zuerst das Ribbon mit der Netzwerkverwaltung auszuwählen.
Die Konfiguration des Netzwerkes und der MAC-Pools finden Sie unter dem Bereich Networking in der VMM-Konsole. Im linken Fester sehen Sie die Ressourcen dargestellt. Ganz oben sind die Server der Hosts eingeblendet. Darunter finden Sie eine Gruppe Networking. Aktivieren Sie diese Gruppe und öffnen dessen Kontextmenü. In diesem Menü ist die Option Create a logical Network auszuwählen. Zur Konfiguration des Netzwerks öffnet sich nun ein Assistent, der zu durchlaufen ist. Er fragt die wichtigen Einstellungen in einer Dialogfolge ab. Aus dem Pool der Netzwerk-Interfaces werden später die virtuellen Maschinen versorgt.
Der MAC Address Pool
Im nächsten Schritt müssen sie einen MAC Address Pool einrichten. Selektieren Sie dazu den Eintrag MAC Address Pool in der linken Spalte. Durch Betätigen der rechten Maustaste öffnet sich das Kontextmenü für den MAC Address Pool. Es zeigt nur eine Option; Create MAC Pool. Diese sollten Sie nun wählen. Dabei wird erneut ein Assistent gestartet. Diese will zuerst wissen, wie der MAC Address Pool heißt und für welche Host-Gruppe er verfügbar sein sollte. Die MAC-Adressen werden ebenso wie die IP-Adressen in Pools gebündelt und stehen daher auch immer für eine Gruppe an Hosts (die Host Group) zur Verfügung.
Durch diesen übergreifenden Ansatz lassen sich die virtuellen Maschinen auch in der Gruppe verschieben, ohne dass die IP- und die MAC-Adressen angepasst werden müssten. Wählen Sie bei der Frage nach der Host-Gruppe nun jene, für die Sie den Pool einrichten wollen, und fahren Sie mit dem Assistenten fort.
Im nächsten Schritt ist der Bereich für den Pool anzugeben. Sie finden dazu zwei Felder, eine Obergrenze und eine Untergrenze. Darunter teilt Ihnen das System mit, wie viele MAC-Adressen Ihr gewählter Pool umfasst. Fahren Sie dann mit dem Assistenten fort.
Der nachfolgen Bildschirm fasst nun all Ihre Einstellungen nochmals übersichtlich zusammen. Wenn bis dato alles so weit passt, sollten Sie den Assistenten abschließen - oder zurückblättern und Korrekturen vornehmen. Damit ist die Konfiguration der Netzwerkanbindung einer Microsoft-Private-Cloud abgeschlossen, und Sie können virtuelle Maschinen in Ihre Cloud legen. Dies erfolgt im Prinzip analog zu den bestehenden und bekannten Techniken. Der größte Unterschied liegt dabei darin, dass die Ressourcen für die virtuellen Maschinen aus unserer neuen Cloud genommen werden.
Shared Storage über das Netzwerk-Interface anbinden
Falls erforderlich, können Sie bei der Konfiguration der Cloud-Dienste außerdem noch einen zentralen Shared-Storage-Pool dazupacken. Diesen benötigen Sie unter anderem, wenn Sie virtuelle Systeme migrieren wollen. Zur Migration von virtuellen Maschinen auf andere Hosts via Live Migration benötigen Sie zwingend einen gemeinsam zu nutzenden Speicher. Auch dieser kann über ein bestehendes Netzwerk angebunden werden.
iSCSI verlangt - im Gegensatz zu Fibre Channel-Speicher - keine eigene Netzwerkinfrastruktur, sondern kann über Ethernet abgewickelt werden. Dies macht es insbesondere in kleineren und mittleren Umgebungen sehr interessant. Der Einsatz eines iSCSI-Speichers benötigt immer zwei Komponenten: den iSCSI-Target und den iSCSI-Initiator. Der Initiator ist der Konsument, dem der Speicher zur Verfügung gestellt wird. Das ist beispielsweise ein Server in einer virtuellen Maschine. Der Initiator greift über das Netzwerk auf das Target zu. Dieses stellt den Speicher zur Verfügung. Es wird daher in der Regel auf dem Speichersystem eingerichtet.
Der Zugriff des Initiators auf das Target erfolgt über eine TCP-/IP-Strecke und die bestehenden Netzwerk-Interfaces. Theoretisch wäre es also möglich, dass Speicher und Server beliebig weit voneinander entfernt stehen. Wegen der Zugriffsgeschwindigkeit und der Latenzzeit wird man aber Initiator und Target nicht zu weit voneinander trennen, es sei denn, es ist gewünscht. Werden Initiator und Target beispielsweise in unterschiedlichen Brandabschnitten eines Betriebsgeländes platziert, so wird das Risiko des Ausfalls des kompletten Rechenzentrums verteilt.
Zugriff auf den Shared Storage
Der Initiator verbindet sich beim Datenaustausch über das IP-Netz mit dem Target. Seit Version Windows Server 2008 gehört die iSCSI-Unterstützung zum Betriebssystem. Für die Anbindung eines iSCSI-Speichers an Windows rufen Sie die iSCSI-Konfiguration auf.
Diese iSCSI-Verwaltungsmaske hat mehrere Einstelloptionen. Unter Ziele geben Sie im Feld Ziel die IP-Adresse oder den Namen Ihres iSCSI-Servers an. Die IP-Adresse muss jener entsprechen, die der Target zugewiesen erhielt. Drücken Sie anschließend den Knopf Schnell verbinden. Anschließend wird in der Liste darunter bereits das iSCSI-Target eingeblendet. Der Verbindungsaufbau mit dem Target erfolgt mit den Standardparametern über den ausgewählten Port. Wenn beim Einrichten des Targets andere Parameter verwendet wurden, so müssen Sie diese hier anpassen.
Unter dem Reiter Suche sind detaillierte Einstellungen zu der gewählten Verbindung zu sehen. Damit ist eine Verbindung zum Shared Storage hergestellt. Nun wird dieser Speicher noch dem Betriebssystem zugewiesen. Dies erfolgt unter der Datenträgerverwaltung. Dort muss nun das neue Speichersegment zu finden sein. Um den Speicher zu nutzen, ist eine Partition einzurichten, und der Speicher muss formatiert werden. Da Microsoft Hyper-V die Speicherfunktionen des Betriebssystems nutzt, ist eine Integration eines Storage in die Hyper-V-Umgebung leicht durchzuführen und unproblematisch. (hal)