Anwenderbericht: "Unser Weg zur Private Cloud"

Anwenderbericht zum Strategieprojekt „Optimized IT“ bei Becker & Kries Immobilien Management GmbH & Co. KG
Wo sich vormals 30 Server drängten, reichen jetzt zehn Stück mit erheblich mehr
Applikationen aus, um die Geschäftsprozesse ausfallsicher zu unterstützen. Die
“Private Cloud” der Becker & Kries Immobilien Management GmbH & Co. KG in
Berlin zeigt sich als echte Win-Win Situation für Anwender und IT-Mannschaft.
Komplette IT auf dem Prüfstand
Vor knapp vier Jahren brachten die ungebremste Datenflut und der steigende Bedarf
an zusätzlichen Anwendungen nicht nur die Systeme, sondern auch die IT-Administratoren
an die Grenzen der Belastbarkeit. „Der Betrieb dedizierter Server für einzelne
Applikationen war zeitaufwändig und ineffektiv“, berichtet IT-Leiter Michael Pfeifer.
Ziel war es daher, die Administration zu vereinfachen und die Hardwareressourcen
besser auszulasten. Flankierende Maßnahmen wie Update des Sicherungsservers
und die Erneuerung der Notstromanlage sollten die Ausfall- und Zukunftssicherheit
weiter erhöhen.
Vier Wettbewerber an einem Tisch - wer ist der passende Lösungspartner„Das ganzheitliche Konzept der CEMA AG zeigte detailliert, wie wir im vorgegebenen
Zeit- und Budgetrahmen unser RZ wirtschaftlicher und leistungsfähiger machen
können“, begründet Projektleiter Frank Ochla die Entscheidung.
Ein weiterer Pluspunkt des Konzepts war der Vorschlag, statt eines hardware- ein
softwarebasiertes SAN aufzubauen. Vorteil, der Speicher kann herstellerunabhängig,
rasch und kostengünstig erweitert werden.
„Bei vergangenen Projekten zeigten sich große Systemhäuser weniger kundenorientiert
und weniger flexibel als mittelständische Dienstleister“, erzählt Frank Ochla.
1. Schritt: Platz schaffen durch Virtualisierung der 30 physischen Rechner auf
drei Hostsysteme mit VMware „ESX“.
Fast alle Systeme und Anwendungen wurden virtualisiert, darunter Datenbanken, der
Mailserver, die Zeitwirtschaft und der Domain Controller.
2. Schritt: hochverfügbare Daten und dynamischer Speicherplatz durch Storage
Virtualisierung
Dazu wurde ein hochverfügbares SAN mit synchroner Datenspiegelung und einer
Speicherkapazität von 9 TByte aufgebaut. Die Sicherung und die rasche Wiederherstellung
der virtuellen Server erfolgt über den zentralen Backup-Server. „Die
Systeme sind besser ausgelastet, performanter und ausfallsicher“, berichtet Pfeifer.
3. Schritt: schlankes Client-Management und ortsunabhängiger Zugriff für
Anwender auf ihre Arbeitsumgebung durch Desktop-Virtualisierung
Dazu wurden sechs Hostrechner eingerichtet, auf denen sämtliche Anwendungen,
angefangen von Microsoft Office bis zur Branchenlösung für die Immobilienwirtschaft,
hochverfügbar laufen. Parallel wurden 140 PCs durch Thin Clients ersetzt. Über eine
Internetverbindung können berechtigte Anwender jetzt unterwegs und von zuhause
auf die Daten und Applikationen zugreifen.
Für die IT-Abteilung haben sich der Verwaltungsaufwand und damit auch die Kosten
pro Computerarbeitsplatz signifikant verringert. Gleichzeitig stieg die
Reaktionsschnelligkeit, denn sämtliche Endgeräte lassen sich vom Rechenzentrum
aus administrieren und aktuell halten.
„Die Anforderungen aus den Fachbereichen, wie etwa das Bereitstellen neuer Software
oder eines Desktop-Arbeitsplatzes, können wir jetzt kurzfristig erfüllen“, resümiert Ochla,

Systemumfeld: VMware vSphere und View,
Thin Clients und Server R710/810, QLogic
SANBox, DataCore SANmelody, Symantec
Backup Exec, Microsoft Windows Server
Betriebssysteme.

Kunde: Die Becker & Kries Immobilien Management
GmbH & Co. KG deckt, von der
Projektentwicklung bis zum Bestandsmanagement,
das gesamte Spektrum immobilienwirtschaftlicher
Dienstleistungen ab. Der
Eigenbestand umfasst rund 400.000 qm
Gewerbeflächen und mehr als 13.500
Wohnungen. Darüber hinaus ist Becker &
Kries an Firmen der Medien-, Mode- und
Baubranche beteiligt.

Sysprep 1, 2, 3 - vorbei!

Man lernt ja tatsächlich niemals aus. ;-)

Heute war ich bei einem Kunden, bei dem wir eine virtuelle XenApp 5-Umgebung (unter VMware vSphere 4) auf Basis von Windows Server 2008 x64 betreiben.

Unser Wunsch war, es das Rapid Deployment der Farm so zu gestalten, dass aus einem ge-sysprep-ten Template alle weiteren Farmmitglieder gecloned werden.

Das ist ein an sich bewährtes Verfahren für "kleine" XenApp-Farmen (ich würde sagen bis hinzu ca. 5 bis 10 logischen Servern) und hat über Jahre hinweg auch sehr gut funktioniert.

Nun weiß man ja, wie das ist: man baut so ein Image hat es fertig und syspreped es. Ach "mérde!" eine Kleinigkeit vergessen, also kurz noch einmal anpassen das Image und noch einmal syspreppen. Dann einen Monat (und viele Microsoft Patchdays) später, kommt die Erkenntnis, dass man mal wieder an das Image ranmüsste. Also ein drittes mal syspreppen. Die Welt ist immer noch in Ordnung.

Versucht man es jetzt aber dann - aus welchem Grund auch immer - ein viertes Mal, wird man bitter enttäuscht.

Beim Versuch Sysprep (mit der Generalisierungs-Option) aufzurufen, hagelt es bitterböse Fehlermeldungen, die unter %windir%\System32\Sysprep\Panther\Setuperr.log nachzulesen sind.

Fehler [0x0f0082] SYSPRP LaunchDll: Fehler beim Ausführen von "C:\Windows\System32\slc.dll, SLReArmWindows', ist aufgetreten Fehlercode-1073425657 zurückgegeben



Fehler [0x0f0070] SYSPRP RunExternalDlls: Fehler beim Ausführen Registrierung Sysprep DLLs, die Ausführung von Sysprep anzuhalten. DwRet =-1073425657



Fehler [0x0f00a8] SYSPRP WinMain: Treffer Fehler während der Verarbeitung Sysprep Anbieter verallgemeinern, hr = 0xc004d307

Tja, googled man ein wenig, findet man in der Microsoft Knowledgebase folgende Hinweise:

Ursache: This error may occur if the Windows Software Licensing Rearm program has run more than three times in a single Windows image.



Lösung: To resolve this issue, you must rebuild the image.

Also, man darf sein Image neu bauen.

Der KB-Artikel von Microsoft verwirrt im ersten Moment ein wenig. Dort heißt es: To work around this issue, use the "SkipRearm" setting in an XML answer file (Unattend.xml) to skip the Rearm process when you build the Windows Vista image.

Von einem Workaround kann aber nicht die Rede sein. Denn was hier nicht steht ist, dass man *vor* dem dritten Mal Syspreppen die unattend.xml hätte erstellen müssen, die das sog. "rearm"-ing des Builds verhindert.

Für mich war das echt neu und somit hielt sich die Begeisterung echt in Grenzen.

Ich kann nur von Glück sagen, dass der Kunde ein nicht ganz frisches Backup (Stand Sysprep zum Ersten) "auf Tasch" hatte. Mit dem Stand hatte ich also noch zwei Schuss frei und konnte somit also das Rapid Deployment der Umgebung durchführen.

Es bestätigte sich also was ich schon seit Jahren predige: Cloneing von XenApp-Servern gilt es zu vermeiden. Automatisierte Installationen (á la WDS, WIM, OSD, NetInstall) oder besser noch die Königslösung mit dem Citrix Provisioning Server sind das einzig wahre.

Wieder ein Stückchen schlauer...

Übrigens: NewSID von Sysinternals funktioniert auch nicht unter Windows Server 2008 x64 und unter 2008 R2 schon mal gar nicht.

Momentan ist mir keine andere Technologie bekannt, mit der ich doch noch Microsoft-konform die SID des Clones anpassen könnte.

Ach ja: Schuld ist natürlich die dämliche (Sorry MS...) Produktaktivierung die trotz eines laufenden KMS keine dritte Aktivierung zulässt.

XenServer-VM Festplatte verkleinern

[For an english version of this article - please click here.]

Gerade bei p2v-Migrationen kommt es häufiger vor, dass man nach dem eigentlichen p2v-Vorgang eine VM mit riesiger Festplatte hat. Leider wird von Citrix die Verkleinerung von XenServer-VM-Festplatten nicht unterstützt [1]. Hierfür gibt es einen Workaround aus alten ESX-Server Tagen:

1. Füge der entsprechenden VM eine Festplatte mit der Zielgröße hinzu.
2. Starte die VM von der gparted-Live-iso [2].
3. Kopiere und verkleinere die Quell-Partition auf die Ziel-Festplatte mit gparted.
4. Setze die Ziel-Festplatte auf aktiv (damit sie bootet).

Dieser Vorgang klappt so ziemlich mit jeder Virtualisierungs-Lösung...

[1] http://support.citrix.com/article/ctx116114
[2] http://gparted.sourceforge.net/livecd.php

PS: Um vhd-Dateien in der Größe zu verändern, gibt es noch das folgende Tool.
http://vmtoolkit.com/files/folders/converters/entry87.aspx

CTRL + ALT + DELETE in virtuellen Maschinen (VMware, Citrix, Microsoft)

Wer kennt es nicht, man sitzt vor seiner virtuellen Maschine, welche einen höflich um die Eingabe der Tastenkombination CTRL + ALT + DELETE (STRG + ALT + ENTF) bittet und drückt diese voller Elan und dann ... hat natürlich nicht die virtuelle Maschinen, sondern das lokale System reagiert.

Da mir das selbst öfter mal passiert, ich aber auch schon viele Kunden dabei erwischt habe, hier das Einmaleins der Tastenkombination CTRL + ALT + DELETE in den virtuellen Welten von VMware, Citrix und Microsoft.

Im folgende die Auflistung der Tastenkombination, welche statt CTRL + ALT + DELETE genutzt werden sollten.

• VMware ESX und Workstation: CTRL + ALT + INSERT (STRG + ALT + EINFG)
• Citrix XenServer: CTRL + ALT + INSERT (STRG + ALT + EINFG)
• Microsoft Hyper-V: CTRL + ALT + END (STRG + ALT + ENDE)

Und ab jetzt dürfte es keine mehr aus Versehen passieren, dass man CTRL + ALT + DELETE statt der oben genannten Tastenkombinationen drückt!

vSphere Client unter Windows 7

Wenn man ein noch nicht unterstütztes Client-Betriebssystem zu Testzwecken auf seinem Notebook einsetzt, muss man manchmal auch ein bissel schrauben - So geschehen mit dem vSphere Client (VI-Client für ESX4): Installiert man sich den vSphere Client wie gewohnt von der Homepage des ESX-Servers und versucht sich dann mit dem Host zu verbinden, bekommt man die folgenden Fehlermeldungen zu sehen:

Error Parsing the server "192.168.1.10" "clients.xml" file Login will continue contact your system administrator

The type initializer for "VirtualInfrastrcture.Utils.HttpWebRequestProxy" threw an exception

Nach ein bissel Suchmaschinenpenetration bekommt man dann einen Workaround präsentiert:

http://communities.vmware.com/thread/211440;jsessionid=68CF31362C01DBEB4A6D47B08253F3F8?start=0&tstart=0

Was muss man tun, um den vSphere Client unter Windows 7 zum Laufen zu bringen?

1. Kopieren Sie sich die %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\System.dll von einem Windows XP System mit installiertem .Net Framework
2. Legen Sie diese Datei in einen Ordner ihrer Wahl auf ihrer Windows 7 Maschine ab (z.B. %ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib)

3. Editieren Sie die Datei %ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\VpxClient.exe.config und fügen Sie die folgenden Zeilen hinzu

4. Erstellen Sie sich ein Batch-File mit dem folgenden Inhalt

SET DEVPATH=%ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib

"%ProgramFiles%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\VpxClient.exe"

Und starten Sie den vSphere Client über dieses Batch-File.

Warnung: Windows 7 ist aktuell nicht als Clientbetriebssystem für den vSphere Client supported!

vCenter (VC2.5U4) und Proxy

Nachdem man sein VirtualCenter 2.5 mit dem Update 4 zum vCenter gemacht hat, kann es vorkommen, dass nach dem Ausführen der Installationsanleitung für die Leistungsübersicht (http://kb.vmware.com/kb/1008296) trotzdem keine Diagramme zu sehen sind.
Führen auch die beiden zur Fehlerbehebung erstellten Anleitungen (http://kb.vmware.com/kb/1008329 und http://kb.vmware.com/kb/1008330) nicht zu schönen Diagrammen, so sollte man mal die Proxy-Settings (IE-Settings) des Rechners checken, auf dem der VIC installiert ist. Ist ein Proxy eingestellt, so ist es am einfachsten das vCenter in die Ausnahmeliste der Proxy-Settings aufzunehmen. Danach klappts dann mit der Leistungsübersicht ;-)

Selbiges gilt übrigens für das SVmotion-Plugin von Andrew Kutz (http://sourceforge.net/projects/vip-svmotion/). Hier erscheint bei falscher Proxy-Konfiguration die Fehlermeldung "The Remote server returned an error: (404) not found" bei dem Versuch das Plugin zu aktivieren.

Krieg der (virtuellen) Welten (VMware vs. Citrix)

Es ist immer wieder amüsant wie sich VMware und Citrix in der Blogsphäre gegenseitig bekriegen. Teilweise geht es hier zu wie im Kindergarten.

“Mein Hypervisor ist schneller, meiner ist schmaler und meiner kann viel mehr!”

Beispiele kann man in der aktuellen Diskussion, welche Virtualisierungslösung besser geeignet ist um XenApp Workloads zu betreiben, finden.

Angriff VMware:
VROOM!: Virtualizing XenApp on XenServer 5.0 and ESX 3.5.
Gegenschlag Citrix:
VMware Wins! (Bad Science Required)

Wir als unabhängiger Berater können hier auch nicht wirklich eine Stellung beziehen, den um eine der meisten Aussagen von Brian Madden zu zitieren “It depends!”. Die perfekte Lösung ist ganz einfach von den Anforderungen des Kunden und dessen Umgebung abhängig und das Beste was man hier als Dienstleister tun kann: die passende Lösung zusammen mit dem Kunden suchen, finden und realisieren.

Einen sehr großen und unabhängigen Test haben die Kollegen von den Login Consultants/PQR durchgeführt und als Resultat kam folgendes raus: der Virtual Reality Check (VRC).

The goal of Project VRC is to investigate, validate and give answers to the following questions:

• How does various Microsoft Windows Client OS’s  scale as a virtual desktop?
• How does a VDI infrastructure scale in comparison (virtualized) Terminal Server?
• Which performance optimization on the host and guest virtualization level can be configured, and what is the impact of these settings on user density?
• With the introduction of the latest hypervisor technologies, can we now recommend running large scale TS/CTX workloads on a virtualization platform?
• How do the two usage scenarios compare, that is Microsoft Terminal Server [TS] only, versus TS plus XenApp?
• How do x86 and x64 TS platforms compare in scalability on bare metal and virtualized environments?
• What is the best way to partition (memory and vCPU) the Virtual Machines the hypervisor host, to achieve the highest possible user density?

Bei diesen Benchmarks kann man einen gewissen Trend, welche Virtualisierungsplattform für welchen Workload am Besten geeignet ist, erkennen. Allerdings handelt es sich hierbei nicht um 100% Aussagen. Denn um es noch einmal zu sagen “It depends!”. So mag der eine Kunden seine XenApp Workloads auf VMware ESX abbilden, weil er diese Lösung schon im Unternehmen im Einsatz hat, oder ein andere Kunde Citrix XenServer auf Grund der Einfachheit für alle Workloads einsetzen.

Stehen Sie gerade vor einer solchen Entscheidung? Die CEMA, als führender und unabhängiger Virtualisierungsspezialist, berät sie gerne!

VMware Distributed Power Management

Eigentlich erzählen alle Sellis immer, dass man durch Servervirtualisierung Strom spart - Allerdings habe ich in zahlreichen Virtualisierungs-Projekten noch nie erlebt, dass die abgelöste Server-Hardware danach verschrottet worden ist. Meistens wurde sie gleich für Tests oder neue Dienste verwendet und das RZ des Kunden hatte nach dem Virtualisierungs-Projekt mehr Stromverbrauch als vorher :(

Damit dies nicht so bleibt, möchte ich hier mal ein wenig Werbung für den Gedanken des Strom Sparens machen (das Video hat auch ziemlich geile Mucke):


[http://www.youtube.com/user/drummonds1974]

Noch ein Tipp für alle, die iSCSI-Targets in ihren ESX-Servern verwenden: Wenn ihr lange Boot-Zeiten habt (die bei DPM extrem hinderlich sein können), überprüft doch mal ob eure ESX-Server alle IP-Adressen des Targets erreichen können ;-)