Tach!

Hier kommt die angekündigte Zusammenfassung der Vorschläge.

Vorab: Ich bin kein Rechenzentrumsbetreiber. Ich habe nur mal das eine oder andere gesehen und selbst probiert, bin aber ansonsten nur interessierter Laie. Bei Fehleinschätzungen meinerseits bitte ich darum, Einspruch zu erheben.

Das Ziel ist, das Gesamtsystem auf einen zukunftssicheren Stand zu bringen, so dass Hardwareprobleme keinen großen Ausfall mehr verursachen können. Das soll eher mittelfristig geschehen, ein akuter Handlungsbedarf zeichnet sich derzeit nicht ab. Drei von vier Servern laufen noch mit ausreichend Reserven.

Es gibt zwei grundsätzliche Szenarien, unabhängig von der konkreten Ausführung (virtualisiert oder physisch):

1. Ein Server, auf dem alles läuft.
2. Mehrere Server, die sich die Arbeit teilen.

Vorteil bei 1 ist, dass sich der Administrationsaufwand auf ein System beschränkt. Der Vorteil von 2 ist, dass man auch mal etwas komplett getrennt laufen lassen kann. Dies wird weniger aus Performancegründen als vielmehr zum Testen notwendig sein. Davon ausgehend kann man sich eine Umsetzung überlegen.

11. Eine Maschine auf virtueller Basis - à la 1&1 Cloud oder Host Europe.
12. Eine physische Maschine (dedizierter Server, wie er nahezu überall angeboten wird).
13. VServer - nicht weiter betrachtet, zu viele Einschränkungen.

(Die verlinkten Angebote sollen als technisches Beispiel dienen und noch keine Empfehlung darstellen.)

21. Mehrere einzelne Maschinen (virtuell oder physisch)
22. Eine physische Maschine (wie 12), auf der eine Virtualisierungslösung läuft.
23. Ein virtuelles Rechenzentrum - eine bereitgestellte VM-Umgebung, in der man die VMs selbst hinzufügen kann.

Angebote für 23 sind noch nicht so lange am Markt. Es könnte sein, dass sich ein Anbieter findet, der gegen Werbung so eine Umgebung sponsert, um sich ins Gespräch zu bringen. Allerdings sind diese auf Hochverfügbarkeit und schnelle Ressourcenbereitstellung ausgelegten Lösungen für unseren Bedarf eigentlich überdimensioniert. An einer Virtualisierung mehrere Server in einer Umgebung ist jedoch interessant, dass einzelne Maschinen geclont oder Snapshots angefertigt werden können. Dies ist hilfreich für Backups und das Zurückdrehen, wenn etwas nicht geklappt hat. Für Tests können diese Kopien ebenfalls herangezogen werden.

Wie wirken sich Ausfälle auf die Varianten aus?

Alles auf 1 basierende bedeutet, wenn keine Redundanz greift, einen Komplettausfall. Einzelne Festplatten sind üblicherweise durch Redundanzen gesichert, ein Ausfall kann im (weiter)laufenden Betrieb beseitigt werden. Andere Komponenten tauscht der Support aus. Ersatzteile sollte der Hoster vorhalten, denn er wirbt ja mit hoher Verfügbarkeit. Es ist aber möglich, dass ein plötzlicher Ausfall das System in einen nicht mehr hochlauffähigen Zustand bringen kann, was administrativen Aufwand bedeutet und je nach Schwere dauert. Backups müssen auf einem exteren Platz zu liegen kommen. (Ein Backup-Konzept betrachte ich an dieser Stelle nur insoweit, dass keine wichtigen Wege durch das gewählte Design ausgeschlossen werden.)
Bei Variante 21 können die Server gegenseitig als Backup-Medium dienen, so läuft das auch bisher. Für 22 wird ein externer Backup-Platz benötigt. Bei 23 kommt es drauf an, wie die Umgebung aufgebaut ist. Zwei physisch unabhängige Datastores (der Platz in dem die Festplatten der VMs liegen) sollten ausreichend sein. Ansonsten muss auch hier externer Platz zur Verfügung stehen.
Bei den Szenarien mit rein virtuellen Umgebungen (11, 21 und 23) sollte der Hoster in der Lage sein, bei sich abzeichnenden Hardwareproblemen einen mehr oder weniger nahtlosen Umzug auf andere Maschinen durchzuführen.

Was wird benötigt, was ist Nice-to-have?

Vom Leistungbedarf reicht eine aktuelle Maschine. Für Tests ist eine zweite Maschine sehr von Vorteil. Eine Alternative wäre, dass man zumindest recht einfach und schnell ein zweites System aufgesetzt bekommt. Wenn nichts besseres aufzutreiben ist, wäre 11 oder 12 zuzüglich Backup-Platz die Minimalvariante.

Variante 21 hat bei Standardangeboten den Nachteil, dass die Maschinen nicht exklusiv miteinander vernetzt sind. Dies ist mit den jetzigen Maschinen aber gegeben, so dass diese auf schnelle Weise ihre Backups austauschen können. Zur privaten Kommunikation (zum Beispiel zwischen Anwendung und Datenbank) muss für diese Variante noch ein VPN aufgesetzt werden. (Keine unlösbare administrative Aufgabe, doch das läppert sich am Ende alles zusammen.)

Wenn es eine physische Maschine (12) mit ausreichender Leistung und viel RAM ist, kann diese in Variante 22 betrieben werden. Damit lassen sich gegenüber 21 nicht nur die Aufgabe separieren, man kann dazu noch, auch bei Standard-Angeboten, den jetzigen privaten Switch emulieren.

Konkret habe ich für das Eigenvirtualisierungsszenario den VMware ESXi und Xen untersucht. (Das ebenfalls kostenlose Hyper-V von Microsoft kenne ich auch, doch damit dürfte bei den potentiellen Administratoren kein Blumentopf zu gewinnen sein.) Beides sind Hypervisor-Systeme, was heißt, dass auf der Hardware ein Minimalsystem läuft, in dem dann die VMs gestartet werden.

VMwares ESXi ist zwar der Marktführer, aber zum Grundsystem gibt es meines Wissens nur eine kostenlose Verwaltungsoberfläche (vSphere Client), die ausschließlich unter Windows läuft. Zudem kann diese auch nur die Grundfunktionalitäten: Maschinen anlegen, einschalten und ausschalten. Snapshots gehen auch noch, aber das komplette Klonen von Maschinen ist nicht vorgesehen, womit auch kein Backup ganzer VMs unterstützt wird. Das ist nur gegen Aufpreis erhältlich. Inwieweit es externe Tools zum Nulltarif gibt, habe ich nicht untersucht. Für den vSphere Client kann man zwar eine zusätzliche VM mit Windows aufsetzen. An diese kommt man prinzipiell auch per Fernzugriff von Nicht-Windows-Systemen, doch dann hat man ein mehr oder weniger öffentlich zugängliches Windowssystem zusätzlich zu warten (von Lizenzkosten ganz abgesehen).

Xen gibt es nicht nur als kommerzielles Produkt, viele Linux-Distributionen unterstützen es ebenfalls. Alle Wartungsaufgaben lassen sich an der Kommandozeile ausführen und sind damit auch für automatische Vorgänge scriptbar. Bei Variante 22 wäre mein Vorschlag also eine Xen-Lösung.

Bleibt noch Variante 23. Die ist die anspruchsvollste und wird üblicherweise so individuell konzipiert, dass man Preise nur auf Anfrage bekommt. Doch wie oben schon erwähnt, sind die Chancen auf ein Sponsoring nicht ganz schlecht. Technisch jedenfalls entspricht sie der 22, nur dass sich auch noch der Hoster um den Hypervisor kümmert. Was das Klonen und weitere Wartungstätigkeiten angeht, ist man auf das Angebot und die Tools des Hosters angewiesen.

Ein Wunsch war das Transferieren von VMs nach Hause, um sie in Ruhe analysieren zu können. Das wäre bei 11, 12 und 21 gänzlich ausgeschlossen, bei 22 möglich (mit Xen einfach und mit ESXi nicht unmöglich) und bei 23 von den Hoster-Tools abhängig. Vermutlich ist es eher sinnvoll, den Clone in der VM-Umgebung zu lassen und ihn fernzubedienen anstatt viele GB herunterzuladen. Konsolenzugriff ist in allen Varianten gegeben.

Ein bedeutender Nachteil der mit Standardangeboten einhergeht, ist die übliche Beschränkung auf eine einzelne IP-Adresse (jedenfalls ohne Aufpreis). Nur eine öffentliche IP-Adresse zur Verfügung zu haben, macht das Verteilen von Aufgaben auf weitere Server mindestens umständlich. Mehrere Webserver benötigen einen vorgeschalteten Reverse-Proxy oder ähnliches, damit der Traffic zu ihnen verteilt werden. SELFHTML gehört derzeit ein /28er-Netz, was mehr als reichliche 14 nutzbare Adressen ergibt. Ob diese bei einem Wechsel mit umziehen können, gilt es herauszufinden.

Meine persönlichen Favoriten sind in absteigender Reihenfolge: 23, 22, 11 und 12.

dedlfix.