Hardware-Unabhängigkeit I: Virtualisierung!

Hardware-Unabhängigkeit I: Virtualisierung!

Ein Server wird stärker ausgestattet und bekommt eine virtualisierungs-Software installiert. Wir nutzen hier gerne VMware, kennen aber auch XEN-Server. Dieser Server ist jetzt ein "VM-Host".

Die virtualisierungs-Software bietet eine Konfigurationsoberfläche, mit der man nun in der Lage ist, sich den ersten Server zusammen zu stellen:

  • Arbeitsspeicher
  • Prozessor-Kerne
  • Netzwerkadapter
  • Festplattenkapazitäten

Sobald das fertig ist, kann innerhalb dieser Software der erste Server installiert werden - richtig klassisch entweder von CD, einem USB-Stick oder von einem CD-Image.

Natürlich kommt nach der Grundinstallation die Grundeinrichtung: Name, IP-Adresse, ein Treiberpaket, ein Schwung Updates.

Der virtualisierte Server merkt nicht, dass er nicht auf einem "Blech", sondern innerhalb einer virtualisierten Umgebung installiert wurde.

Das Schöne dabei ist:

Alles bewegt sich auf dem VM-Host innerhalb von Ordner- und Verzeichnisstrukturen. Es gibt Konfigurationsdateien zur virtualisierten Maschine (der "VM"), es gibt eine Datei für den Arbeitsspeicher und Dateien für die Festplatten.

Diese Ordner und Verzeichnisse enthalten also die kompletten VM. Sie können kopiert, verschoben, gesichert und und, wenn nötig, auf einem anderen VM-Host wiederhergestellt werden.

 

Durch die Virtualisierung werden wir unabhängig vom "Blech"!

Was hatten wir früher für Probleme:

Ein Mainboard-Schaden an einem älteren Server bedingte die Neuinstallation, da Ersatzteile nicht mehr verfügbar waren. Unter Umständen betraf das den Domänencontroller mit den entsprechenden Folgen.

Arbeitsspeicher sollte aufgerüstet werden. Oft genug musste dazu der komplette Arbeitsspeicher ausgetauscht werden, da nicht ausreichend Steckplätze zur Verfügung standen. Wenn man dann feststellte, dass der eine oder andere Server auf den einen oder anderen Speicherriegel verzichten könnte... Ja, da hätte man sich schon gewünscht, den RAM dynamisch zuweisen zu können.

Die Beobachtung der Hardware mehrerer Server war sehr aufwändig: Jeder Server hatte Lüfter, die verstopfen konnten, in jedem Server werkelte ein RAID-Controller, der mit seinen angeschlossenen Festplatten im Auge gehalten werden musste usw.

Und das in Umgebungen, in denen gerne mal 20...30 Server werkelten. Allein der Platz, die Verkabelung, die Abwärme, die Temperaturüberwachung, die Klimageräte...

Das alles läuft nun von einem Storage ausgehend auf drei VM-Hosts.

Ja, das geht. Recht gut sogar!

Dazu bieten die Hersteller sogenannte "Konverter", die aus einem hart installierten Server eine virtualisierte Maschine machen und sie auch gleich zu den anderen VMs stellt.

Es ist auch möglich, Maschinen aus einer vorhandenen Datensicherung heraus zu virtualisieren. Besonders gut geht das mit Backups aus Acronis.

Dabei bleibt alles erhalten: Das Betriebssystem mit seinen Updates, Software-Installationen und Einrichtungen. Einige Treiber fliegen raus, einige andere kommen hinzu, die IP-Adresse muss neu vergeben werden. Danach können noch Arbeitsspeicher, Prozessorkerne und Partitionsgrößen angepasst werden, dann kann die Maschine gestartet werden. In der Regel läuft der Server als VM wesentlich schneller, als vom Blech. Das ist deutlich spürbar!

Der Weg zurück (also vom VM-Host runter auf ein Blech) ist allerdings nicht ohne Weiteres möglich.

Obwohl VMware und auch Citrix Lizenzgebühren aufrufen, sind bereits diese Kosten geringer, als für einen einzigen Hardware-Server.

Ob nun ordentlich ins Rack verschraubt oder lose Tower-Ansammlung: Weniger Server zu betreiben bedeutet immer, dass weniger Platz gebraucht wird.

Je mehr Server betrieben werden, desto höher ist die Wahrscheinlichkeit, dass auch tatsächlich mal ein Server ausfällt.

So wird z.B. der tatsächlich in den VM-Host verbaute Arbeitsspeicher auf die virtuellen Server verteilt.

Braucht ein Server mehr Arbeitsspeicher, so wird er einfach "per Schieberegler" zugewiesen.

Vielleicht stellt man ja auch fest, dass ein anderer Server zuviel Speicher bekommen hat - da schiebt man den Regler etwas weiter runter.

Das ist wesentlich flexibler, als die fixe Zuweisung bei Hardware-Servern, bei denen die Speicherriegel untereinander vielleicht noch inkompatibel sind.

Natürlich brauchen hochgerüstete VM-Hosts mehr Strom, als ein einzelner "Blech-Server".

Doch braucht ein einzelner VM-Host meist weniger Strom, als zwei separate Server.

Strom wird im Server in Rechenergebnisse und Abwärme umgewandelt.

Und gerade diese Abwärme muss heruntergekühlt werden, damit die Systeme nicht überhitzen.

Kommt es zu einem Ausfall der Klimaanlage, muss es schnell gehen, da die Temperaturkurve im Serverraum rasant ansteigt. 30 Minuten können hier schon knapp sein.

Zum Backup der virtualisierten Server nutzen wir Veeam.

Je nach Performanz ist ein Voll-Backup der virtuellen Server in wenigen Stunden fertig, danach werden einige Tage inkrementelle Backups gefahren, die nur noch wenige Minuten brauchen.

Mindestens ein Mal pro Woche sollte jedoch wieder ein Voll-Backup gefahren werden.

Wir können virtualisierte Server schneller wiederherstellen, als sie gesichert werden können!

Warum?

Weil Veeam die einzigartige Technik bietet, virtualisierte Server noch während des Zurückspielens zu starten!

Wenn es darum geht, Kosten zu sparen? Sofort und ab dem ersten Server!

Wenn es darum geht, unabhängig von Hersteller und Typ des Servers zu sein? Sofort und ab dem ersten Server!

Wenn es darum geht, die Vorteile des Backups und der Wiederherstellung zu nutzen? Sofort und ab dem ersten Server!

Zumindest der Server, der die Verwaltung der VM-Hosts übernimmt, sollte nicht virtualisiert werden.

Auch der Backup-Server, der die Backups der virtuellen Server steuert, sollte nicht virtualisiert werden.

Beide Dienste (Verwaltung + Backup) können aber auf einem Server laufen.

Auf gar keinen Fall sollten Server zur Videoüberwachung virtualisiert werden. Die Daten, die da fließen... Keine Chance!

Das liegt ganz daran, welche Aufgaben die einzelnen Server haben und wie der VM-Host ausgestattet ist.

Es ist z.B. kein Problem und auch üblich, die Server:

  • Domänencontroller
  • Mailserver
  • Terminalserver
  • SQL-Server

in einer überschaubaren Umgebung für 20 User auf einem einzigen VM-Host laufen zu lassen.

Auch das ist kein Problem: Wir installieren mehrere VM-Hosts und verteilen die virtualisierten Server so, dass alle VM-Hosts etwa gleich ausgelastet sind.

Ab dem zweiten VM-Host lagern wir die virtuellen Maschinen auf ein Storage aus. Dieses Storage binden wir in die VM-Hosts als lokale Laufwerke ein - ein Pool entsteht.

Und in diesem Pool sind wir dann in der Lage, virtuelle Maschinen auf die VM-Hosts zu verteilen.

Wir können virtuelle Maschinen sogar im laufenden Betrieb von einem VM-Host auf den anderen verschieben, ohne, dass ein Anwender etwas merkt.

Das kommt uns auch im Falle der Wartung (Lüfter reinigen, RAM aufrüsten, Netzteil tauschen...) zugute!

Im Falle eines Fehlers an einnem VM-Hosts werden die virtuellen Maschinen verschoben. Nur müssen alle Hosts so stark sein, die dann auftretende Last auch verarbeiten zu können.

Auch, wenn es dann insgesamt etwas langsamer läuft: Immerhin geht es unterbrechungsfrei weiter!