VMWare GSX/ESX

Hallo, Newsgroup.
Hallo, Herr Meyer.

Ich habe mir erlaubt das Thema vom "Komserver" zu trennen....

Eine Lösung hierzu wäre vielleicht VMMare. Unter www.vmware.de
kann man hierzu nähere Info bekommen. Hierbei handelt es sich um einen Ansatz die Hardware Resourcen zu opimieren. Es wird zwar nur bestimmte Hardware (Hersteller) unterstützt, aber man sollte dies bei evtl. Anschaffung neuer Hardware mal nicht unberücksichtigt lassen.

Wir beschäftigen uns seit ungefähr einem halben Jahr mit VMWare, haben uns aber (wg. der Flexibilität bei der Hardware) zunächst erstmal für die GSX-Variante entschieden.

Konsolidiert haben wir hierunter derzeit einen Scannerproxy und den Exchangeserver, vor allem letzterer läuft hier hervorragend!!!

Im Datev-Umfeld betreiben wir unter VMWare GSX derzeit (noch) ein reines Testsystem... läuft aber bis jetzt hervorragend! Beim nächsten "Serverumzug" überlegen wir derzeit ernsthaft, eine VMWare-Engine als Grundlage für den produktiven ADS, Exchange, Datev-DB, Datev-DMS und ggfs. sogar WTS einzusetzen (wobei ich beim letzteren immernoch nicht vorbehaltlos bin, was die Performance angeht)...

Der Aufbau einer Virtuellen Rsourcen Server (VMWare) sieht da wie folgt aus:

Anwendungen auf 1 / Anwendungen auf 2 / Anwendungen auf 3
Betriebsystem1(Kommserver) / Betriebsystem 2 (File Server) Betriebsystem3 (WTS Server)
VMWare (z.B. ESX Server)
Hardware

Es werden hierbei auf einenr Physikalischen Server mehrer Server (Virtuelle) aufgesetzt.
Der Vorteil hierbei 1 Es werden Hardware Resourcen Optimal Verteilt, 2 Server aufgaben werden verteilt evtl. Komflikte (Software) können dadruch nicht auftreten. 3. Zusätzliche Konfiguration entfallen (WTS Server + Kommserver auf einen Gerät) 4. Ausfallsicherheit, wenn z.B. eine neues Datev SR erscheint, kann man die Virtuellen Server sichern und eine Update durchführen. Falls es zu Problemen kommt, können man die Virtuellen Server jederzeit wieder einspielen und sofort mit den alten Zustand weiter arbeiten.

VMWare-Gast-Engines lassen sich per Skript / zeitgesteuert herunter- bzw. wo es servertechnisch geht in den Ruhezustand fahren. Der Gast kann dann in Form von wenigen großen Dateien relativ leicht *ZEITGESTEUERT* als Image gesichert und anschließend wieder per Skript "geweckt" werden. Hat man genug Platz auf der Platte des Hostsystems, macht man sich zusätzlich eine Kopie auf der Festplatte statt nur auf dem Sicherungsmedium. Um Daten dann bei Bedarf dateiweise zurückzuspielen, kann man den Server kurz (ggfs. vom Netz getrennt, bzw. unter der Berücksichtigung von IP-Konflikten im Host-only-Mode) in einer zweiten Engine hochfahren und die Daten relativ einfach und schnell zurückspielen....

Eigentlich ein Traum...

Mögliche Probleme, die ich aus unseren bisherigen Erfahrungen sehen kann:

1.) das mit dem Ruhemodus klappt eigentlich nur bei einfacheren Servern mit Diensten, die keine Streams erwarten.... Terminalserver, DB-Server und vor allem DatevDMS dürften sich bei aktivierten Diensten nur sehr schwer nach dem "Aufwachen" aus dem Ruhezustand automatisiert wieder in einen stabilen Zustand bringen lassen.... anders wäre das, wenn man den Server zeitgesteuert herunterfährt oder die Dienste auf dem Gastsystem zeitgesteuert vor dem Ruhezustand stoppen und nach dem "Wiedererwachen" entsprechend wieder starten lässt....

2.) bei der Hardware auf dem Host sollte man bei echten produktiven Systemen schon wissen, was auf einen zukommt.... m.E. muss da vor allem RAM, sehr schnelle Platten (wg. den großen VMWare-Device-Files) und umfangreicher Festplattenplatz an sich rein... 4 GB RAM oder 120 GB HDD sind bei VMWare-Hosts, die produktiv einen ADS, DB-Server, Exchange, etc. beherbergen sollen da schnell ziemlich "eng"... da die "emulierten" Engines auch immer etwas langsamer laufen als der Host sollte wohl auch bei der CPU-Auswahl nicht unbedingt gespart werden....

3.) zumindest bei GSX sollte man daran denken, daß bei mehr als 4 GB auch das Betriebssystem des Hosts eine Rolle spielt.... setzt man VMWare GSX für Windows ein, ist hier bei Windows 2000 Server bei 4 GB schluss, d.h. man braucht hier dann den Advanced Server.... anders ist das natürlich bei VMWare GSX für Linux oder bei ESX, welches sein "eigenes" OS (m.E. ein modifiziertes Linux/Unix-Derivat) mitbringt....

4.) bei ESX gibt es die bereits von Ihnen erwähnten Einschränkungen im Bereich Hardware, was aber wohl nur daran liegt, daß VMWare bei ESX eben den eigenen Kernel / das eigene Betriebssystem mitsupporten muss und man da wohl etwas mehr Supportsicherheit haben will... hier muss man - denke ich - einfach abwägen, in wie weit man hier lieber auf GSX (mit etwas weniger Funktionalitäten + der Notwendigkeit eines eigenen Hostsystems) setzt oder bei ESX in bestimmte Hardware investieren muss...

5.) Datev und VMWare: daß das geht führt Datev ja selbst auf zahlreichen Präsentationen und Schulungen immer wieder (mehr aus Versehen als mit Absicht) vor... oft führen Datev-Mitarbeiter ja gleich den zur Demo notwendigen Datev-Server/DMS-Server/DB-Server auf ihrem Notebook unter VMWare Workstation mit.... im Produktivbetrieb könnte ich mir ohne weiteres den ADS und den Datev-DB- + DMS-Server unter VMWare GSX/ESX vorstellen.... anders ist das aber beim Datev-Komserver (leider!) und beim WTS....

6.) Datev-Komserver: dieser benötigt nunmal ISDN und wenn ich richtig informiert bin wird die ISDN-Karte für Verbindungsaufbau oder andere (evt. seltenere) Aushandlungen auch bei Web/DSL über den Datev-Komserver immernoch benötigt... legacy ISDN wird bei VMWare leider immernoch nicht durchgereicht... auch der USB-Support kann mit ISDN nicht umgehen.... um ISDN auf einen VMWare-Gast zu bekommen, muss man m.E. virtuelles CAPI / Router einsetzen (siehe Parallelbeitrag zum Thema Komserver ;-) ) was ja alles in der Form leider nicht so einfach, bzw. ohne physischen Komserver geht... unter GSX könnte man den Komserver ggfs. auf dem Host mitlaufen lassen (soweit Windows 2000 Server / Advanced Server zum Einsatz kommt), ob das Performance- und Stabilitätstechnisch noch ideal ist, wage ich aber zu bezweifeln...

7.) Terminalserver: hier gibt es wohl einen kleinen Widerspruch im Konzept der Virtualisierung.... die Virtualisierung verteilt die Performance des Host zumindest bei GSX gleichmäßig auf die einzelnen "Gäste"... beim WTS benötigt der Server selbst sehr viel Performance, die auf die User verteilt werden sollte... deshalb schrecke ich etwas davor zurück, einen oder ggfs. mehrere Terminalserver zusammen mit ADS, Exchange & Co. auf einem VMWare Host laufen zu lassen (man stelle sich vor, der Exchangeserver indiziert Postfächer oder DatevDMS lässt aus irgendeinem Grund den Gastserver voll auslasten, o.ä.)... kleinere Terminalserver (Testsysteme, RDP als Admin, RDP-Zugriff auf WinXP, o.ä.) sind sicherlich problemlos... produktive WTS würde ich jedoch bei einem einzigen WTS nach wie vor physisch beibehalten... bei mehreren WTS kann VMWare wieder von Vorteil sein, allerdings - glaube ich - würde ich bei dieser Variante dann die weitere Lizenz von VMWare GSX/ESX + Hardware riskieren und die Terminalserver ggfs. getrennt von der restlichen "Serverfarm" auf einem eigenen TS-VMWare-Server virtualisieren.... <größenwahn>oder bei ESX dann wieder auf entsprechenden Clustern... ;-) </größenwahn> *g*

8.) Kein echter Knackpunkt/Nachteil, aber man sollte daran denken / es nicht vergessen: zu lizenzierende Betriebssysteme + Anwendungen (also auch Windows, Office, Datev, etc.) müssen unter einem virtualisierten Server genauso einzeln lizenziert / bezahlt werden, als ob man mehrere physische Maschinen betreiben würde...

9.) Kostenbewertung: VMWare kann sowohl Ersparnis, als auch Kostenfalle sein.... praktische Vorteile überwiegen sicherlich... ganz klar ist natürlich, daß VMWare m.E. erst ab einer gewissen Größe der Serverumgebung wirklich Sinn macht wo eine ggfs. notwendige Investition in die Serverinfrastruktur durch die Vermeidung der Kosten durch Betreuung vieler Einzelserver + die praktischen Vorteile aufgewogen wird ... für reine Testsysteme zum Spielen dürfte VMWare Workstation sicherlich auch ausreichend sein (wer's einfach mal testen will, sollte sich evt. auch die c't 20/2005 mal ansehen)...

MfG B. Wettstein
IT-Informatikkfm.

Hallo Herr Wettstein, Hallo Newsgroup,

das Thema Virtualisierung mit VMware verfolge ich auch schon seit einiger Zeit.

Ich habe auch schon einige Lösungen im Kopf bei denen wir wenig genutze Server oder Workstations, auf die von der gesamten Kanzlei gelegentlich zugegriffen wird, auf einen stärkeren Server mit VMware zu packen.

Eine ganze Kanzlei mit Domänencontroller(n), Exchange-Server, Datev-Fileserver, KIS-Server(n), WTS etc. auf eine oder mehrere Maschinen mit dem GSX oder ESX Server zu packen ist zwar schön, aber aus zwei Gründen würde ich das so noch nicht machen:

1. So lange es noch keine Supportzusage seitens der Datev gibt, die verschiedenen Datev-Server unter VMware produktiv laufen zu lassen, bin ich skeptisch.
Ich kann mir schon das Gespräch mit dem Teamservice vorstellen: "Jaa, Sie haben die Maschine unter VMware laufen, das ist so nicht supportet..."

2. Micsosoft setzt immer mehr daran, seine eigene Virtualisierungslösung in den Markt zu drücken. Es gibt ein KB-Dokument von MS, in dem steht, dass sie Serveranwendungen unter "Nicht-Microsoft-Virtualisierungslösungen"
nicht so ohne weiters supporten. http://support.microsoft.com/kb/897615

So kann es sein, das bei einem Service-Pack oder Patch bspw. des Win 2003 Servers der ganze Kram mal nicht mehr soo gut läuft. Ich denke, die Datev ist so auf dem MS-Pfad, man wird in Nuernberg wenn, dann den MS Virtual Server unterstützen.

Viele Grüsse,

Gunnar Ender
Vivatech GmbH

Eine ganze Kanzlei mit Domänencontroller(n), Exchange-Server, Datev-Fileserver, KIS-Server(n), WTS etc. auf eine oder mehrere Maschinen mit dem GSX oder ESX Server zu packen ist zwar schön, aber aus zwei Gründen würde ich das so noch nicht machen:
2. Micsosoft setzt immer mehr daran, seine eigene Virtualisierungslösung in den Markt zu drücken. Es gibt ein KB-Dokument von MS, in dem steht, dass sie Serveranwendungen unter "Nicht-Microsoft-Virtualisierungslösungen"
nicht so ohne weiters supporten. http://support.microsoft.com/kb/897615

Hallo Herr Ender,
bei einem Vortrag zu VMWare wurde mir gesagt, dass die Lösung von MS nicht den gleichen Ansatz verfolgt wie die von VMWare. MS setzt auf eine bestehendes System auf ähnlich der VMWare für Workstation. Dadruch ist das Gesamtsystem so ausfallsicher wie das unterste Betriebsystem bei MS. Gleiches gilt narürlich für VMWare aber mit dem Unterschied, das das entsprechendes System besser geschützt sein soll.

Wegen Kis-Server, der fällt mit der EO 4.0/4.1 weg. Ab dann wird auch MS-SQL Server genutzt. Ab dann macht es auf eine Virtuellen Server keinen Sinn mehr dieses Separat laufen zu lassen.

Gruß

Olaf Meyer