Mein kleiner Server zu Hause erfüllt mehrere Rollen. Er spielt Fileserver für meine zwei Clients hier im LAN, dann noch Proxy, DHCP, DNS (mehrer Zonen, u.a. auch authoritiver DNS für mehrere Domains im Internet) und Mailserver (SMTP und IMAP). Die wohl wichtigste Rolle ist aber der Webserver. Auf dem Webserver laufen zwei Blogs (mehr oder weniger gut besucht...) und ein paar kleine Seiten. Trotzdem mehr als ärgerlich, wenn die Kiste mal nicht läuft. Nachdem das alles recht produktiv auf einem Eigenbau mit VIA C3 CPU (600 MHz) und 512 MB RAM lief, habe ich mir Gedanken über ein K-Fall Konzept gemacht. Ein richtiges Konzept gab es nicht. Wenn die Hardware gestorben wäre, wäre mir nichts anderes übrig geblieben, als die Kiste aus einem Image wiederherzustellen und die Daten zurückzusichern - passende Hardware vorausgesetzt. Daher habe ich mich mit P2V Migrationen beschäftigt, zumal ich damit im beruflichen Umfeld ganz gute Erfahrungen gemacht hatte. Da die Maschine keine hohe Last hatte, kam mir die Idee die physikalische Maschine einfach in einen VMware Gast zu portieren. Die Vorteile lagen klar auf der Hand: Die Hardware, auf welcher der Gast läuft, ist egal. Einfach VMware Server auf einer Maschine installieren und schon kann ich den Gast wieder anfahren. Zudem konnte ich ohne viel Aufwand die Maschine sichern, z.B. über LVM Snapshots oder Microsoft VSS (auch wenn beide Varianten recht unsauber sind). Dank VMware Snapshots und Clones konnte ich schnell Testmaschinen erstellen und daran z.B. Paketupgrades testen. Als Hardware ist derzeit ein HP ProLiant ML110 G5 im Einsatz. Die Maschine selber verfügt über einen 1,80 GHz Intel Core2 Duo E2160 und 4 GB RAM. Die beiden 160 GB Platten sind als RAID 1 gespiegelt. Tatsächlich läuft der VMware Gast, auf dem auch dieses Blog läuft, nur mit einer vCPU und 512 MB RAM. Da sind noch viele Reserven. ;) Ich konnte in der gesamten Betriebszeit keine Probleme feststellen, weder von der Performance, noch von der Handhabbarkeit. Den Gast kann ich relativ problemlos auf VMware Server 2.0 oder VMware Workstation umziehen. Von dem Standpunkt aus kann ich zukünftigen Migrationen entspannt entgegenblicken.

Das muss man sich mal auf der Zunge zergehen lassen... nx6325 mit Dual-Core AMD Turion64 X2 TL-52 (1,6 Ghz), 2 GB RAM, 80 GB HDD intern, 160 GB HDD extern per USB 2.0. XP SP2 mit VMware Server 1.0.4. Aktuell am laufen:

• Windows Server 2003 Enterprise SP2 DC
• Windows Server 2008 Enterprise RC1 DC
• Openfiler Appliance
• Windows Server 2003 Enterprise SP2 Cluster Node 1
• Windows Server 2003 Enterprise SP2 Cluster Node 2
• Auf dem Cluster Fileserver und die administrative Clustergruppe

Das alles mit recht angenehmer Performance, zumindest so, dass man damit arbeiten und testen kann. Akutell sind 900 MB belegt und die CPU Last liegt so bei im Schnitt 30%. :) Ich liebe VMware. :)

Ich werde oft gefragt: VMDK oder doch besser ein RDM (Raw Device Mapping) für eine Datenbank oder I/O intensive Applikation? Seit VMware VI3 ist das eigentlich egal. Zumindest gibt es zwischen VMDK und RDM keine nennenswerten Performanceunterschiede mehr. Wozu also noch ein RDM? Für Cluster... okay, da bleibt einem keine wirkliche Alternative. Aber auch bei Datenbanken, oder anderen I/O intensiven Applikationen, kann ein RDM Sinn machen. Das VMFS, in dem die VMDK Files der VMs liegen, ist ein logisches Laufwerk auf einem Storage (NFS lassen wir mal Außen vor....). Nun teilen sich im Zweifelsfall viele VMs ein logisches Lauwerk (egal aus wievielen Platten das im Endeffekt besteht). Wenn man nun kompromisslose Performance haben will, macht ein RDM wieder Sinn. Das RDM ist ja auch ein logisches Laufwerk auf einem Storage - nur hat eine VM das dann exklusiv im Zugriff. Daher auch keine störenden Einflüsse durch andere VMs. Immerhin kann es durchaus mal vorkommen das ein virtualisierter Exchange und eine Oracle DB zwar auf unterschiedlichen Servern laufen, aber im gleichem VMFS liegen. Das ist für die Performance sicherlich nicht förderlich. Daher merken: RDM macht durchaus Sinn. ;)

Immer wieder ein sehr lustiges Thema. Auslöser für so was ist oft "Irgendwie ist uns das zu langsam.". Wenn man dann etwas nachbohrt kommen die lustigsten Dinge zu Tage. Oft sind es Dinge die auf den zweiten Blick total einleuchtend sind. Manchmal sind es aber auch Dinge, für die man einen sehr tiefen Blick in die verwendeten System haben muss, bzw. deren Arbeitsweisen. Sehr beliebt: Zuviel auf zuwenig Platten legen. Daher kann ich den ganzen Hype um 750 GB oder gar 1 TB Platten nicht verstehen. Oft wird dem Endkunden damit das falsche Signal gegeben. Klar, wenn ich einfach nur Platz brauche, oder einen geringen Preis pro Gigabyte haben will, dann sind solche SATA Platten nice. Aber wenn ich I/Os brauche, dann müssen sich Spindeln drehen. Je mehr, desto besser. Klar steigt damit auch der Preis pro Gigabyte. Auch sollte jedem Kunden vermittelt werden, dass SATA kein Vergleich zu SCSI / SAS / FC (gleiche Mechanik, unterschiedliches Interface) ist. Weder von der Performance, noch von der Verfügbarkeit. Die oft verwendeten SATA I Platten können häufig nicht mal NCQ, was durchaus Performance bringt. Sehr geil ist auch immer die Aussage "Da bringt ja eine Einzelplatte mehr.". Ja, korrekt. Bei der Einzelplatte ist aber auch der Cache aktiviert. Viele Storage-Systeme deaktivieren den Cache aus Gründen der Verfügbarkeit. Wäre ja doof, wenn der Controller batterie-gepuffert ist, aber die Daten im Cache der Platte bei einem Stromausfall hops gehen. Und dann geht es auch immer wieder um das Design. Es hat schon seinen guten Grund warum man sich vorher Gedanken um sein LUN / Array Setup machen sollte. Ich bin ein Freund von pre-carving und fester LUN Größen. Ich bin auch ein Fan davon, Arrays und LUNs abhängig vom Einsatzzweck zu bilden. Ein Fileserver braucht sicherlich Platz, aber weniger IOPS als eine DB für OLTP. Beides auf die gleichen Platten zu legen macht wenig Sinn, oder? Mit dem zunehmenden Trend zur Virtualisierung wird das Ganze nicht besser. Wie soll das virtualisierte OS optimieren, wenn es keinen blassen Schimmer von dem darunterliegenden I/O System hat?? Gar nicht... Also biete sich, z.B. bei virtualisierten Linux Systemen, immer der No-Op Scheduler an. Der frisst wenig CPU Leistung und optimiert wenigstens ein wenig. Allgemein wird der No-Op unterschätzt. Gerade bei Systemen wo nicht viel zu optimieren ist, weil z.B. das darunterliegende I/O System das schon macht, leistet der No-Op hervorragende Arbeit. In the end wären da noch die Systeme, die jemand gebaut hat, der besser was anderes als IT gemacht hätte.... 4 Knoten RAC Cluster in Kombination mit Selfmade-Server, einer Hand voll SATA Platten und OpenFiler machen keinen Spaß... wirklich nicht.... GRID is ja schön, aber nicht wenn das zentrale "Storage" wie eine Gans per Druckbetankung gestopft wird, um anschließend wie eine Senftube ausgesaugt zu werden.

Ich spiele gerade ein wenig mit VMware Converter rum. Ich werde erstmal testweise mein Firmennotebook virtualisieren, wenn das klappt, ist mein Server testweise dran. Sollte das auch klappen, wird die ganze Kiste einfach per VM auf neuer Hardware weiterbetrieben. Ich hatte zwar geplant das ganze System umzubauen, aber.... na ja... zur Zeit fehlt mir die Lust und der Elan. Und ich habe halt immer gerne einen Plan B. :)

Dank mitgeliefertem Tool kann man dem VMware Converter auch noch Treiber mitgeben, z.B. für Netzwerkkarten oder Controllern. Sehr feine Sache.