Ein virtuelles "Hallo" an alle!
vor vielen Jahren hatte ich auch die Aufgabe, eine "Abschätzung" zur Virtualisierung einer Server-Infrastruktur zu machen, was zu Zeiten des sog. VMware GSX Servers nicht das Problem war. Heute ist das durch die anwachsenden Anforderungen nicht mehr so einfach, besonders dann, wenn man den Kunden nicht kennt, bzw. nicht weiß, wo sich der Kunde in den nächsten Jahren sieht. In deinem kann ich dir nur ein paar Tipps mit auf den Weg geben:
Zum Thema Exchange Server: "Vorsicht", denn ich habe schon Exchange Server mit über 1.000 Postfächer samt Ressourcen virtualisiert und nicht nur einmal deren Datenbanken wiederhergestellt. Völlig unabhängig davon, welche Hardware-Ressourcen im ESX Server vorhanden sind, kann es zu massiven Problemen mit virtualisierten Exchange Servern kommen. Besonders dann, wenn dieser mittels dem VMware Converter vom physischen Stand in einem virtuellen migriert wurde. Ebenso kann es zu massiven Problemen kommen, wenn der RAM des ESX Servers bei erhöhtem Memory Overhead (ballooning) zu "leaken" beginnt oder das lokale Swapping an seine Grenzen stößt, denn dadurch kann es passieren, dass die Exchange Datenbank auf einem VMFS Storage inkonsistent wird, und dabei spielt es keine Rolle, wieviel User (Postfächer etc.) auf dem Exchange Server angelegt sind oder wie groß dessen Datenbank ist. Übrigens bekommst du von Microsoft keinen Exchange Support, wenn die anhand der Logs sehen, dass dieser virtuell betrieben wird, auch nicht als Microsoft-Partner!
Zum Thema Datenbank-Server: Wir betreiben mehrere virtuelle Datenbank-Server, sei es Microsoft SQL Server wie auch Oracle. Wenn sie sauber konfiguriert werden und das Storage performant ist, gibt es keine erwähnenswerte Probleme.
Zum Thema Citrix: Ein ganz klares "NO GO"!!! Das Zusammenspiel von Citrix und VMware ESX Server ist nicht nur eine Performance-Bremse, sondern absolut "BUGGY". Um es auf den Punkt zu bringen, bekommt man keine vernünftige CPU-Skalierung zwischen dem ESX Server und der Citrix-VM zusande. Erst recht nicht, wenn man via virtual SMP mehrere Prozessoren der VM zuweisen will. Eine Citrix VM mit einer zugewiesenen CPU läuft besipielsweise performanter als mit zweien oder mehr!!! In unserem Fall hatten wir sechs virtuelle Citrix Server in Betrieb, eben um Usern "on demand" div. Anwendungen bereit zu stellen. Alle dieser sechs virtuellen Citrix Server machten Mucken, so dass wir wieder auf physische Citrix Server gesetzt haben. Die Fa. Citrix hat nicht umsonst die XenServer-Source aufgekauft, eben die Konkurrenz zu VMware um Citrix Systeme auch (kostengünstiger) virtuell zu betreiben.
Das wars auch schon zu den Tipps, bzw. zu meinen Erfahrungen über die Systeme, die euer Kunde wünscht. Zu vielen anderen Server-Derivaten habe ich nichts negatives zu vermelden. Die anderen Microsoft Server laufen ohne Probleme, UNIX und Linux sowieso.
Was die Hardware zur VMware Infrastruktur angeht, nur drei Dinge: Performance, Ressourcen und Redundanz, und gerade das Letztere kostet mehr als das Doppelte der eigentlichen Systeme. Was von den Kosten her auch sehr ins Gewicht fällt, sind neben den VMware zertifizierten Servern (speziell HBAs und NICs), inkl. Service-Verträge deren Hersteller, das FC-SAN, FC-Switche und natürlich die VMware Lizenzen. Lizensiert werden die ESX Server nach Anzahl der physischen Prozessoren (zukünftig nach Anzahl der Kerne). Dazu muss im ersten Jahr die Lizenz für den VMware Support gekauft werden, ebenfalls nach Anzahl physischer Prozessoren.
Sofern ihr die virtuellen Systeme ausfallsicher (redundant) betreiben müsst, kommen neben dem dazu notwendigen FC-SAN mit redundanten HBAs an redundanten FC-Switche, ein extra physischer Server für den VMware Infrastructure Server sowie Lizenzen für VMware DRS (Überwachung der Auslastung von sog. Ressourcen Pools) und VMware HA (High Availability) hinzu.
Wie eingehens erwähnt, sollte eurem Kunden klar sein wo er sich in den nächsten Jahren sieht, bzw. wie dessen Systemanforderungen wachsen wird, schließlich sollten sich die Investitionskosten einer solchen virtuellen Infrastruktur durch dessen Features bezahlt machen und zukünftige Investitionen verringern.
Grundlegend möchte ich noch anmerken, dass ich produktive VM-Systeme niemals lokal auf einem ESX Server betreiben würde, denn wenn dieser in die Knie geht, macht alles die Krätsche. Ein Test-System ja, ein Produktiv-System nein!!!
@fogzone: Der Load Balancer nennt sich nicht (automatisches) VMotion! Der Load Balancer ist eine Sache des Virtual Infrastructure Servers, eben um Ressourcen festzulegen, diese zu überwachen und ggf. freie Ressourcen zur Verfügung zu stellen. Das VMotion als Funktion macht nichts anderes als verwaltete Ressourcen und den reservierten Inhalt des Arbeitsspeichers einer VM an einen anderen Server abzugeben, auf dessen Rückmeldung zu warten und abschließend seinen Ressourcen-Job zu canceln. Dabei muss allerdings die zu migrierende VM (vmx/vmdk) auf einem zentralen Storage abgelegt sein. Der VMotion-Prozess wird zudem manuell angestoßen. Soll das alles, also die Überwachung des Load Balancers und das mögliche verschieben via VMotion automatisch passieren, sind wir beim Thema VMware DRS und VMware HA. Erst diese zwei Komponenten sind die Automatik dieser Virtual Infrastructure Features.
Shit... nun habe ich wieder einen halben Roman geschrieben. Naja, Hauptsache es hat jemandem weitergeholfen. Ach ja, als VMware Admin hat man übrigens mehr Zeit, z.B. um solche Romane zu schreiben.
Na dann, frohes virtualisieren, und denkt daran -> REALITÄT IST DA WO DER PIZZA-MANN HERKOMMT!!!
Franky
das ganze wird ein vmware-zertifizierter server eines der großen anbieter werden. die frage ist halt, welche mindestanforderungen das ganze erfüllen sollte.
