Erfahrungsbericht
Ausgangspunkt
Auf einem physischen Server vielen in regelmäßigen Abständen die Festplatten des Raid10-Verbundes aus. Eine Wiederherstellung aus der Tagessicherung mit der Windowseigenen Serversicherung dauerte mindestens einen Tag, in der nicht mit dem System gearbeitet werden konnte. Datenverlust war zwar nicht zu verzeichnen, aber wir fanden es sicherer und zeitgemäßer unseren Server von der Abhängigkeit funktionierender Hardware zu entkpoppeln.
Zwei VM-Systeme hatten wir getestet und uns für VMware und HyperV entschieden. Die entscheidenen Kriterien waren Ausführung vom USB-Stick wodurch der Server nicht mit ins Raid installiert werden musste und und Erstellung der virtuellen Maschine von der physischen Maschine im laufenden Betrieb. Laut unseren Informationen sollte die virtuelle Maschine dann sofort lauffähig sein.
Unser Erfahrungsbericht ist hier nachzulesen.
Download
Nach kurzer Recherche fanden wir die passenden Quellen, registrierten uns dort. Beim Download gab es bereits handicaps mit verschiedenen Browsern. Wir sahen zwar die Seite mit den passenden Downloads und unseren Lizenzschlüsseln, konnten die Dateien jedoch nicht herunterladen. Bei Klick auf den Link, sprang die Webseite nur an den Anfang der Seite. Die war so beim Firefox 38 und beim Chrome 42. Beim Internetexplorer 11 klappte der Download schließlich.
Wir luden uns den VMware vSphere Hypervisor 5.5 - ESXi ISO image und VMware vSphere Client herunter.
Lizensierung
In der kostenlosen Lizenz des ESXi gab es einige Einschränkungen, die uns für den Test genügten. Es musste lediglich ein Lizenzschlüssel eingetragen werden, der bei der Registrierung auf der VMware-Webseite übermittelt wurde.
- Kein support
- Free ESXi kann nicht zu einem vCenter Server hinzugefügt werden
- 2 physikalische CPUs
- Unbegrenzte Kerne pro CPU
- Unlimitierter physikalischer Memory
- Max. 8 vCPU per VM
Ein Download von älteren Versionen, z.B. ESXi 5.1 war zu diesem Zeitpunkt nicht mehr möglich.
Voraussetzungen / Kompatibilität
Beim ESXi gab es einige Beschränkungen in zu verwendender Hardware. So konnte nur 64Bit-Hardware verwendet werden. Dies ist sogar für den Verwendungszweck empfohlen, denn so kann mehr Arbeitspeicher verwendet werden und man hat mehr Ressourcen für mehrere virtuelle Maschinen.
Installation
Wir verwendeten einen einfachen 32GB USB 3.0 Stick, empfohlen waren 16GB.
Das heruntergeladene ISO-Image brannten wir mit UltraISO auf eine CD. Den VMware sphere Client installierten wir einfach per Doppelklick.
Bei der ersten Installation des gebrannten ISO's erschien die Fehlermeldung auf Pinkfarbenen Hintergrund:
can't detect the last level cache
Fehlersuche:
Erster Versuch: Die Deaktivierung der Einstellung "Max CPUID Value Limit" im Bios war erfolgreich. Ausserdem muss die Funktion "Execute disable" und EFI statt Legacy aktiviert sein, sonst gibts wieder einen Pink-Screen.
...wurde jedoch gleich gefolgt vom nächsten Problem. Es erschien die Meldung, kein Netzwerkadapter sei verfügbar, obwohl dieser mit dem Switch verbunden war. Es scheint sich nicht um eine ESXi-kompatible Netzwerkkarte zu handeln. Die von uns verwendete Realtek 8169 funktionierte in ESXi5.1 noch. Da wir nun keine kompatible Netzwerkkarte zur Hand hatten, machten wir mit ESXi 5.1 update 2 (U2) von CD weiter und installierten diese erfolgreichen auf dem Stick. nach der Installation wurde darauf hingewiesen, das die Teststellung nach 60 Tagen abläuft, es sei denn, ein gültiger Produktschlüssel wird eingetragen. Wir hoffen mal, dass dies der bei der Registierung übermittelte Schlüssel ist.
Abschliessend ein reboot vom Stick und konfiguration der Netzwerkeinstellungen. Wenn alles glatt geht, dauert die Installation ca. 1,5h.
Von einem anderen Rechner aus dem gleichen Netzwerk kann man nun die IP-Adresse des ESXi aufrufen und sich z.B. den vSphere Client herunterladen und installieren. Beim Start des Clients erscheint erneut der Hinweis das die testlizenz nach 60 Tagen abläuft. Dieser lässt sich im Client unter dem Reiter Konfiguration => Software => Lizensierte Funktionen eintragen.
Zwischen-Resumé: Wegen der Notwendigkeit, von VMware zertifizierte Hardware, z.B. Netzwerkkarten zu verwenden, bleibt eine 100%ige Hardware-Unabhängigkeit ein Traum.
Nachdem die Konfigurationen über den vSphere Client lief, machten wir uns an die Migration des Physischen Servers in eine Virtuelle Maschine (P2V). Hierfür gibt es von vmware den vCenter Converter, der es ermöglicht, Maschinen während des Betriebs zu migrieren. Diese Live-Migration bietet den klaren Vorteil, dass die Ausfallzeit dadurch sehr klein gehalten wird. Wir folgten dem Installationsdialog und anschließend dem Konfigurations-Wizard. Wichtig zu wissen ist, dass man entweder die lokale Maschine oder eine entfernte Maschine migrieren kann und das entsprechend Auswirkungen auf den Migrationsverlauf haben kann.
Die erste Migration dauerte bei uns ca 17 Stunden (1,8TB). In diesem Zeitraum ist es problemlos möglich weiterzuarbeiten. Anschließend mussten wir eine finale Synchronisation durchführen - hierfür wählten wir im Konfigurationsdialog vom vCenter Converter die DHCP-, alle MSExchange- und weitere Dienste, die Daten verändern können aus, die durch den Converter automatisch gestoppt werden. Die Synchronisierung dauerte gerade einmal 10 Minuten. Danach trennten wir vom physischen Host das Netzwerkkabel und starteten die Virtuelle Maschine auf dem ESXI-Server durch.
Anfänglich gab es Probleme mit dem Netzwerkadapter, da Windows seinen alten statisch konfigurierten Netzadapter nicht mehr fand und der Server dadurch auf DHCP lief. Nach dieser Anpassung mussten wir den Server neustarten, damit alle Dienste die Änderung sauber übernehmen konnten. Beim Durchstarten der MS-Exchange-Dienste (2010 SP3) gab es Probleme mit der OWA-Authentifizierung. Die Probleme äußerten sich dadurch, dass manche Outlook-Clients nicht in der Lage waren sich mit dem Exchange-Server zu verbinden und bei Login-Versuchen im OWA bei korrekten Zugangsdaten eine weiße Seite geladen wurde (HTTP-Error 500). Hier fiel uns auf, dass der Dienst MSExchangeFBA (Formularbasierter Microsoft Exchange-Authentifizierungsdienst) trotz der Einstellung, automatisch zu Starten, nicht gestartet war. Nach einem manuellem Starten funktionierte die Verwendung von OWA und Outlook einwandfrei. Auch später folgende Neustarts des Servers sollten für den genannten Dienst keine weiteren Probleme darstellen.
Nachdem wir uns sicher waren, dass der Server stabil und ordnungsgemäß läuft und funktioniert, schalteten wir die Mail-Abholer-Dienste wieder ein. Somit war der letzte Schritt des Server-Umzugs getan - insgesamt haben wir nur einen Ausfall von ca 45 Minuten gehabt (bis die E-Mails wieder abgeholt wurden). Die Migration dauerte keine 24 Stunden. Wir sind mit der Performance sehr zufrieden.
Weitere hilfreiche Seiten siehe unten.
on Sonntag, 14 Juni 2015.