Alles beginnt damit, dass ich einen neuen Server brauche. Der alte Server rennt zwar noch aber er ist doch langsam in die Jahre gekommen. Immerhin läuft er schon seit 2004 und hat auch entsprechend alte Hardware unterm Gehäuse. Und so trägt es sich in Spitzenzeiten und bei steigenden Besuchern auf verschiedenen Projekten doch zu, dass der MySQL-Server einfach mal sagt Too many Connections. Und dann wird alles langsam. Und nicht immer fängt sich der Server ohne Neustart des Webservers oder des Datenbankservers wieder. Das liegt natürlich an verschiedenen Einflüssen. Der Spamfilter bekommt immer mehr zu tun, Anwendungen werden immer umfangreicher und zu dem erhöhten Besucheransturm gesellt sich auch noch ein erhöhter Ansturm an den sogenannten Suchmaschinen Bots, den Spidern. Man fragt sich zwar, wofür man Spider, mit Ausnahme des Google Bots, überhaupt braucht, aber man kann ja nie wissen, ob Google nicht doch einmal ausdient und man dann genau den falschen Bot ausgesperrt hat.
Aber das wird hier jetzt nicht das Thema sein. Über Spider, Suchmaschinenbots und die Reaktionen auf das erhöhte Aufkommen kann man im SEO-Programmierungs-Blog mehr lesen.
Ich möchte also einen neuen Server. Soviel ist sicher. Und ich möchte den Server auch bei IPX-Server haben. Denn ich bin seit vielen Jahren mit verschiedenen Servern dort und seitdem mehr als zufrieden. Für ein anderes Projekt, das einen doch recht hoch verfügbaren Server bekommen sollte, hatte ich einen Server bei einam anderen Anbieter geordert. Der war weitaus teurer als ein vergleichbarer von IPX-Server. Allerdings traf von den Versprechen auf deren Homepage nicht allzu viel zu. Es wurde also viel Geld für wenig Support und wenig Leistung gezahlt. Dafür viele Pannen, lange Reaktionszeiten und einfach schlechter Service. Viele Downtimes (Ja, 99,9% Verfügbarkeit im Jahresmittel hören sich toll an, aber rechnet mal nach!) Und es hat in einem Fall an die 6 Monate!!! gedauert, bis eine IP einen Reverse-DNS-Eintrag bekommen konnte. Vielleicht ein Einzelfall. Aber es gab viele Einzelfälle. Wäre noch das Beispiel, dass es Rabatt für den Server gab – 10% – wenige Wochen nach Bestellung wurden dann aber die Preise erhöht, wegen der gestiegenen Energiekosten. Da war der Rabatt also auch wieder dahin. Doppelte Abrechnungen, versehentliche Bereitstellung eines zusätzlichen Servers, der nie bestellt wurde etc. etc.
Ich nenne den Anbieter an dieser Stelle nicht. Ich kann eben nur sagen, dass ich mit IPX-Server derartige Probleme nicht hatte. Der Support ist Spitze, die Reaktionszeiten auch. Und wenn mal Hardware defekt ist, wird auch diese umgehend ausgetauscht. Klar, der beste Support ist der, den man nicht benötigt, aber wenn man ihn doch einmal benötigt, dann ist man froh wenn er schnell und richtig reagiert.
Soweit sogut. Es soll also ein Server mit gehobenen Ansprüchen werden. Unter anderem Intel Processoren Core2Quad. Also 4 Prozessoren 
Nun habe ich mir Gedanken um virtuelle Server gemacht. Was benutzt man denn nun, um sogenannte vServer selber auf einem Root-Server zu erstellen? Es gibt verschiedene Ansätze. Zum Beispiel Qemu, was aber wohl nicht die Performance-stärkste Lösung ist. Dann gibt es noch ein Linux-VServer Projekt. Doch auch hier benötigt man einen neuen Kernel. Die beste Lösung scheint auf Linux-Basis wohl momentan XEN zu sein. XEN schiebt eine Ebene zwischen die Hardware und das Betriebssystem ein und stellt den virtuellen Server die Hardware wohl direkt zur verfügung. So habe ich es zumindest verstanden. Wie auch immer, auf jeden Fall ist die Performance wohl die beste. Problem hier ist wie bei den Linux-VServern, dass ein anderer Kernel benötigt wird. Außerdem muss 1. der Prozeser und 2. das Bios diese Virtualisierung (Intel VT) unterstützen. Mehr dazu unter How to tell if your Processor supports VT.
Soweit sogut, also frage ich bei dem Support von IPX-Server an, ob dieses VT denn bei dem entsprechenden Server unterstützt wird. Hier ein weiteres Beispiel des IPX-Server Supports: Anfrage um 10:34 gestellt, und um 10:48 die Antwort erhalten, dass der Server VT unterstützt. Dazu könnte bei Bereitstellung des Servers sogar ein SuSE mit Aktiviertem XEN bereitgestellt werden. Allerdings wird für die Installation dann der übliche Stundensatz eines Technikers angerechnet. Klar, ein Techniker ist nicht billig, also sicherlich gerechtfertigt.
Aber den Techniker kann ich doch eigentlich immernoch hinzurufen, wenn ich es selber nicht hinbekomme. Dann kann ja immernoch neu installiert werden. Alles was ich dann draufgezahlt habe ist meine Arbeitszeit.
Und mir ist klar, dass die XEN-Installation eine heikle Sache ist. Entweder es geht auf Anhieb oder es geht nicht. Einfache Sache. Und wenn es nicht geht, kriege ich das System entweder selber wieder zum Laufen oder ich muss so oder so Neuinstallieren lassen. Also sichere ich mich ab und mache schonmal Trockenübungen mit der Virtualbox unter Windows. Installiere mir dort das älteste OpenSuSE, das ich bekommen kann und stöbere ein wenig. Die version ist OpenSuSE 10.2 und kann per Netzwerk installiert werden. XEN-Packete und Kernel sind in dieser Version enthalten (sollen sogar in version 10.1 schon enthalten sein, oder gar in SuSE 9,3 auch schon?).
Also OpenSuSE installiert, gestartet, eingerichtet – erstmal ganz ohne XEN. Danach über die Software-Aktualisierung die XEN-Packete sowie das YAST2-Virtualisierungsmodul installiert. Danach habe ich dummerweise die Bootloader-Config in Yast aufgerufen und kam nicht ganz klar und habe aus Versehen einen neuen Bootconfig-Vorschlag generieren lassen. Das war nicht gut, danach wollte nichts mehr booten, erst nach einiger Fummelei bootete das System wieder. So soll es also nicht laufen, denn bei dem Server im Rechenzentrum habe ich im Zweifel nur einen Versuch und der muss hinhauen. Für den Fall, dass der nicht hinhaut wäre ein Plan B aber auch nicht schlecht.
Also OpenSuSE 10.2 nochmal neu installiert. Wieder alles eingerichtet, neu gebootet und dann YaST wieder gestartet. Diesmal
installiere ich über die Software-Aktualisierung NUR das Yast-Virtualisierungs-Modul.
Yast beenden und Yast neu starten. Dann steht unter dem Menupunkt System Verwaltung von virtuellen Computer (Xen) bereit. Dort klicke ich drauf und bestätige dass entsprechendes System eingerichtet werden soll.
Dieser Punkt macht jetzt die verschiedenen Schritte für mich. Also entsprechende XEN-Packete herunterladen und/oder installieren. Darunter auch den SuSE-XEN-Kernel und die XEN-Ramdisk. Außerdem wird im Bootloader-Menu für Grub ein neuer Punkt für das Starten des XEN-Kernels hinzugefügt und standardmässig gestartet, wenn ich das System nun rebooten würde.
Aber halt! Wollten wir nicht noch einen Plan B? Ganz wichtig! Früher bei dem LILO-Bootloader gab es eine Option, die einen Kernel nur einmalig startete. Beim nächsten Reboot wurde dann wieder der “normale” Kernel gebootet. Falls mit dem neuen Kernel also etwas schief ging, bootete einfach der alte beim nächsten Systemstart wieder. Diese Option habe ich bei GRUB so nicht gefunden (oder nicht richtig gesucht?).
Dafür gibt es bei grub eine andere Option: fallback
fallback X sagt, dass der Eintrag mit der Nummer X gestartet werden soll, wenn der default Kernel nicht geladen werden konnte. Diese Einstellung kann man auch im Yast tätigen. Zu finden unter System -> Konfiguration des Bootloaders -> Bootloader-Installation -> Bootloader-Optionen. Allerdings ist hier scheinbar kein Name, sondern eben auch die ID einzutragen. Also hilft ein Blick in die Datei /boot/grub/menu.1st und hier zählt man dann, der wievielte Eintrag der auf jeden Fall laufende Eintrag ist. Wichtig ist, dass man bei 0 anfängt zu zählen!
In der Standard-Konfig, so wie ich es hier beschrieben habe, ist der auf jeden Fall laufende Kernel der Menupunkt 0 und der XEN-Kernel Numero 3. Also trägt man bei fallback 0 ein.
Nicht vergessen grub mit den neuen Optionen auch zu installieren. Über Yast passiert das automatisch, wenn man das Bootloader-Modul mit Beenden verlässt.
Jetzt haben wir Plan B eingerichtet.
In unserer Virtualbox entstehen uns keine Kosten und wir können jederzeit selber neu installieren, also wagen wir den Reboot. Der Bootloader versucht nun den XEN-Kernel zu starten. Es sieht soweit auch ganz gut aus, jedoch bricht der Bootvorgang nach einer Weile ab. Das wird aber daran liegen, dass die Virtualbox eben diese VT-Sache nicht emulieren kann. Wäre zwar schön zu sehen wie es dann weitergeht, aber so können wir Plan B direkt testen. Nun können wir 10 mal neustarten, es wird immer wieder der XEN-Kernel gestartet. Denn Grub weiß ja nicht, dass das Booten irgendwann anhält. Grub konnte den Kernel laden und damit sieht für Grub alles gut aus. Klar. Für unseren Plan B müssen wir eine rescue-Konsole starten. Die Möglichkeit bietet IPX-Server abr auch. Wir müssen nun in das verzeichnis /boot/ gehen. Dort befinden sich die Kernel (beginnend mit vmlinuz), den XEN-Kernel erkennt man also recht schnell. Wir brauchen aber nicht den symbolischen Link vmlinuz-xen sondern den wirklichen Kernel (ist die Datei mit der Versionsnummer und ist ein paar kB groß). Diese Datei wird nun umkopiert und dann gelöscht. Umbenennen (Verschieben) reicht nicht aus! Grub hat sich nicht den Dateinamen gemerkt sondern die Stelle auf der Festplatte an der der kernel sich befinden bzw. an der er beginnt. Also kopieren und löschen.
Nun starten wir neu. Grub versucht wieder den XEN-kernel zu laden, findet an der entsprechenden Stelle den Xen-Kernel aber nicht und lädt dann den fallback-Kernel, und der sollte ja funktionieren.
Soweit also die Vorbereitungen für eine Virtualisierung eines Server mit Hilfe des SuSE-Betriebssystems per Remote auf einem Server im Rechenzentrum, also unter erschwerten Bedingungen.
Nun wird es ernst und wir wenden das Gelernte aus der Trockenübung auf den Server an.
Als erstes schmeißen wir ein PING an – um zu sehen ob der Server darüber erreichbar ist und um später festzustellen ob er nach dem Reboot immernoch erreichbar ist.
Nun zum Server. Es ist ein OpenSuSE 10.3 installiert. Also eine Version weiter als die auf der ich meine Übungen gemacht habe. Was soll’s, sollte ja ähnlich sein.
YaST ist auf englisch, aber das ist auch ok.
Also in den Dialog Software installieren und dort wie gewohnt das YaST2-VM Modul installieren. Dann raus aus dem YaST um es direkt danach wieder zu starten. Dann erst einmal Verwunderung – wo ist der Menupunkt unterhalb von System? Ah, es ist kein Unterpunkt mehr sondern ein Hauptmenupunkt Virtualization und darin befindet sich dass der Punkt Install Hypervisor and Tools. Also draufklicken.
Ich werde gefragt ob ich die grafischen Tools auch installieren möchte, da ich momentan im Text-Modus unterwegs bin. Ich entscheide mich dagegen. Dann wird installiert. Als nächstes wird noch gesagt, dass die Firewall2 installiert werden müsse. Ok, machen wir. Danach kommt die Nachricht, dass alles fertig ist und ich mein System neu booten müsse und dort dann XEN auswählen sollte.
OK, erstmal kontrolliere ich über YaST die Firewall-Einstellungen. Nicht dass die jetzt aktiviert ist und mich nach dem Reboot nicht mehr rein lässt. Sie ist aber weiterhin deaktiviert.
Als nächstes schaue ich mir die /boot/grub/menu.1st im Editor an. Und das war auch ganz sinnvoll. Denn dort steht jetzt an erster Stelle (also ID 0) der Xen-Kernel. Und an zweiter Stelle (ID 1) steht diesmal der alte Default-Kernel. Also nochmal rein in das YaST und dort wie oben beschrieben in der Bootloader-Conf irgendwo ganz hinten den fallback auf 1 setzen.
Und nun…reboot und hoffen.
Und…nach nicht einmal einer Minute ist der Server wieder erreichbar. Mit gebootetem Xen-Kernel.
Das wichtigste ist geschafft. Schade, dass ich den Startbildschirm nicht sehen konnte, aber was soll’s.
Die /var/log/boot.msg sieht ok aus.
Jetzt starte ich wieder YaST, finde aber erstmal keine neuen Tools. Vielleicht gibt es die YaST2-Tools für die VM-Einrichtung wirklich nur im grafischen Modus. Also werde ich mich so herantasten und meine virtuellen Server (vServer) einrichten.
Wie es weiter geht, dann ggf. ein anderes mal Es sei aber schon einmal gesagt, dass es weiter geht!
