Virtualisierung hat die Hosting-Welt in den letzten Jahren massiv erobert. Ziel ist üblicherweise, Hardware zu konsolidieren und damit vorhandene Ressourcen besser auszunutzen – nicht zuletzt im Hinblick auf den Energieverbrauch. Schließlich verbessert sie auch die Verwaltbarkeit der Systeme: Über das jeweilige Wirtssystem kann jederzeit eine direkte Konsole zum jeweiligen virtuellen Server hergestellt werden, selbst wenn beispielsweise dessen Netzwerk heruntergefahren worden ist oder man sich via Firewall-Regeln ausgesperrt hat.
Auch bei uns hat Virtualisierung schon vor längerer Zeit Einzug gehalten. Wie bei uns allgemein üblich, setzen wir auch hierfür keine proprietäre Software ein, sondern den freien Hypervisor Xen. Intern evaluieren wir parallel dazu den Einsatz von KVM.
Das technische Setup, das wir für unsere VServer entwickelt haben,
würden Ihnen andere vermutlich als Cloud-Hosting
verkaufen
und die technische Infrastruktur durch eine lustige Wolke symbolisieren.
Uns liegt aber etwas daran, dass Sie verstehen, dass wir hier nicht einfach
einen einzelnen Server genommen und mittels Virtualisierungstechnik
wie einen Kuchen aufgeschnitten haben,
sondern eine Infrastruktur aufgebaut haben,
die auch Ansprüchen an Performance und hohe Verfügbarkeit genügt –
und, so merkwürdig sich das vielleicht im ersten Moment anhört,
die aus unserer Sicht dem Hosting eines einzelnen dedizierten Servers
durchaus überlegen ist.
Der Aspekt des Aufteilens von Hardware auf mehrere virtuelle Server vielleicht sogar verschiedener Kunden steht dabei gar nicht unbedingt im Vordergrund. Es spricht überhaupt nichts dagegen, die gesamten Ressourcen eines Nodes für einen einzelnen virtuellen Server eines einzelnen Kunden zu benutzen, und selbst dabei noch Vorteile aus unserer Virtualisierungs-Infrastruktur zu ziehen: Bessere Festplattenperformance, höhere Ausfallsicherheit, bessere Wartbarkeit.
Bevor Sie mit dem Kopf schütteln, schauen Sie's sich doch erstmal an:
Vereinfacht gesagt braucht ein Server, egal ob virtuell oder dediziert, drei Ressourcen: Plattenplatz, CPU-Leistung und RAM.
Weil Festplatten in der Ausfallstatistik nun mal die Nummer 1 darstellen, haben wir hier einen hochverfügbaren Storagecluster aufgebaut: Zwei Hosts mit je 16 Festplatten, die in einem RAID6 zusammenarbeiten und mittels DRBD live synchronisiert werden. Das zugrundeliegende System ist openfiler; die Steuerung des Failover-Clusters übernimmt Heartbeat.
Auf diese Weise wird einerseits wesentlich höhere Performance gegenüber einem einfachen dedizierten Server erzielt, weil sich die Plattenzugriffe auf mehrere Platten verteilen; andererseits ergibt sich auch wesentlich höhere Ausfallsicherheit: Es können bis zu zwei Platten pro Storage-Knoten ausfallen, und selbst der Ausfall eines gesamten Knotens beeinträchtigt die Funktion der VServer nicht.
Die vorgeschalteten Nodes sind Server, die selbst keinerlei Festplatten beinhalten: Sie booten via PXE und iSCSI über das Netzwerk vom Storage-Cluster, binden dann die planmäßig auf dem betreffenden Knoten untergebrachten VServer ebenfalls via iSCSI ein und booten diese unter einem Xen-Kernel. Welcher VServer auf welchem Node läuft, wird durch ein Management-System gesteuert, mit dem wir die VServer auch beliebig von einer Maschine auf die andere schieben können. Damit bietet das Szenario gleichzeitig auch auf Ebene der Nodes besondere Ausfallsicherheit: Fällt einer der Nodes – z.B. durch einen Hardware-Defekt – aus, können wir die virtuellen Server, die auf ihm liefen, unmittelbar auf einem anderen Knoten booten. Auf diese Weise ist Ihr virtueller Server umgehend wieder online.
Leisten die Alternativangebote, mit denen Sie uns vergleichen, das auch? Zumindest wollten wir mal gefragt haben.
