Virtuelle Server
Checkliste für erfolgreiche Virtualisierung
- Zwei oder mehr physische Dual- oder QuadCore-CPUs. Hinweis: Die Lizenzierung des ESX-Servers erfolgt pro physischem Sockel, also besser zwei Quad-Core- als vier Dual-Core-CPUs verwenden.
- Pro Kern zwei bis vier virtuelle Maschinen, je nach Last auch mehr. Gleiches CPU-Modell für alle Hosts. VMotion funktioniert nicht zwischen AMD und Intel und auch nicht immer zwischen unterschiedlichen CPU-Generationen des gleichen Herstellers.
- Zwischen 8 und 64 GB Arbeitsspeicher, 256 GB maximal pro Host.
- Maximal 16 GB pro VM. Hinweis: Overcommitment ist durch intelligente Speicherverwaltung des ESX (Swap, Pagesharing, Ballooning) möglich, sollte sich aber im vernünftigen Rahmen bewegen.
- Mindestens vier LAN-Ports, beispielsweise zwei Dualport-Adapter, für optimale Redundanz und Load Balancing. Besser sechs Ports für höhere Flexibilität.
- Zwei HBA (Fibrechannel oder iSCSI) für Redundanz. Lastausgleich nur über Pfade zu unterschiedlichen LUNs.
- Lokaler Plattenplatz. Diskless mittels Boot via SAN oder ESX3i Embedded.
- Speicher für virtuelle Maschinen: LUN im SAN oder NAS-Anbindung (nur NFS). Lokale Platten nur für einzeln stehende Hosts oder für Cluster-VMs.
- Redundante Auslegung von Lüftern, Netzwerkkarten, HBAs und lokalen Festplatten des Hosts. Zwei Dual-Port-Adapter sind besser als ein Quad-Port-Adapter.
- Pro virtuellem Switch sollten zwei physische Adapter als Uplink an unterschiedlichen physischen Switches angeschlossen sein.
- Zwei HBAs dienen zur Speicheranbindung über unterschiedliche physische Switches für Path-Failover.
- Ein Storage-Gerät mit mehreren Storage-Controllern bietet einen optimalen Ausfallschutz.
- Drei Hosts im Cluster sind ideal für High Avalibility (HA) und zum Lastausgleich mit Distributed Resource Scheduler (DRS).
- Die unterbrechungsfreie Stromversorgung (USV) sollte ebenfalls redundant sein.Für hohe DR-Anforderungen kommen Storage-Spiegelungen über getrennte Rechenzentren in Frage.
- Site Recovery Manager optimiert Workflows für Desaster Recovery.
- Neu-Installation in einer virtuellen Maschine: Gewachsene Installation wird bereinigt, kein Mitschleppen von Altlasten. Aber zeitaufwendig, teilweise nicht zu realisieren.
- Kopie der physischen Rechner: keine Neu-Installation notwendig, System wird 1:1 übertragen, Weg zurück ist relativ einfach. Aber Fehler und Altlasten werden mit übernommen.
- Manuelles Kopieren mittels Imaging-Tools: Problem ist das händische Anpassen der Treiber an die neue Systemumgebung. Dementsprechend umständlich und zeitaufwendig ist diese Variante in der Praxis zu realisieren.
- Automatisches Überführen mit speziellen Tools, die oft sogar die Migration des laufenden Systems sowie Massenmigrationen erlauben.
- Leostream P>V Direct (www.leostream.com, 600 US-Dollar)
- Platespin PowerConvert (www.platespin.com, 200 US-Dollar pro Migration)
- Ultimate-P2V auf BartPE-Basis (kostenlos)
- VMware Converter (www.vmware.com, kostenlos)

