Erfahrung, auch schlechte, ist durch nichts zu ersetzen. (Ein uralter Slogan aus Willi Studers "Revox-Prospekten")

Bei der Basis unserer Linux-Server (opensuse) halten wir strikte Grundsätze ein, nämlich die Trennung von

• (1) Betriebssystem (bei uns ist das opensuse Linux),
  
  
• (2) den Web-Programmen im Hintergrund (dem Backend) und deren Programmierung (typo3 und php 5 und 7)
  
  
• (3) sowie der Konfiguration der sichtbaren Bediener-Oberfläche - dem sogenannten "Frontend"
  
  
• (4) und den eigentlichen Inhalten bzw. den Daten (dem "Content" in der mysql Datenbank).

.
Das hat sich in den letzten Monaten vor dem Umzug zurück nach Wiesbaden und natürlich auch in 2024 mehrfach rettend bewährt.
.

Unsere ersten Webseiten, die wir publiziert hatten, liefen unter MS Frontpage (erst FP 98 und dann FP 2000) und das war ein Zwitter bezüglich der Windows/Linux Servertechnik und auch bei der Gestaltung mit den Inhalten, es war mit den gesetzten Zielen nicht zu machen bzw. untauglich und unbefriedigend.

Die Server-Techniken begannen damals mit dem Intel Pentium Prozessor (66 MHz) und später mit den Pentium PROs (200 MHz) und dann mit "ganz schnellen" 500 MHz AMD K5 Prozessoren und 16 oder 32 MB RAM sowie einer 240 MB IDE-Platte - und es funktionierte, aber nur, weil die Nachfrage damals noch gering war.

Die nächsten Stufen waren gebrauchte Compaq Proliant Server mit 2 Stück 800 MHz CPUs und 4 GB RAM sowie eine RAID-5 Platteneinheit mit 6 (oder 8) x 36 GB SCSI Platten. Natürlich lief dieser Server schon leicht schneller als unsere alten PCs. Zu diesem Zeitpunkt sind wir auf das Redaktions-System typo3 übergegangen, also weg von den statischen Webseiten von Frontpage zu der Datenbank basierenden Speicherung der Inhalte.

Die Server standen bei uns in Wiesbaden im EDV-Raum und später im Keller eines Wiesbadener Housing-Providers. Bei Startproblemen eines Servers war dann immer eine kurze Fahrt in diesen Keller angesagt, um an der Tastatur die "F1 Taste" zu drücken. Das war zunehmend unbefriedigend. Eine neue Technik musste her - die sogenannte Virtualisierung dieser Server unter "XEN".
.

Der Host (und Gastgeber) stellt damit sinnbildlich seinen virtuellen Gästen (die oben drauf "wohnen") eine virtuelle "Kellerdecke" zur Verfügung, auf der sie sich ein Häuschen nach eigenem Gusto drauf setzen können. Ein Gast, egal, ob unter einem (durchaus alten) beliebigen Linux- Betriebssystem oder einem beliebigen Windows- Betriebssystem sieht dann (von oben) nur ein "virtuelles Abbild" der Hardware des Servers.

Die Theorie verspricht, daß man auch uralte Linux-Versionen (wie bei uns gefordert) sowie alles von Uralt-Windows 2000 bis Windows 10 oder 11 als Gast-System installieren "könne". Doch das ist die reine Theorie. Die Praxis sieht da etwas realistischer aus.
.

Jedes der beiden Konzepte hat (wie immer) Vor- und Nachteille. Die "Vertreter" der beiden Entwicklungen propagieren natürlich nur die Vorteile "ihres" Konzeptes.

Schon mit einer 4-Kern CPU sind keine meßbaren Unterschiede beider Konzepte mehr herauszufinden, denn bei "xen" gibt es noch die Methode der sogenannten "Para-Virtualisierung", der "Teil-Virtualisierung".

Das Gast-Betriebssystem wird dabei leicht "modifiziert" und setzt viel gezielter bzw. tiefer "unten im Keller" des Hosts auf speziellen Funktionen auf und spart damit deutlich einiges an CPU-Kraft. Das geht fast nur unter Linux, selten oder gar nicht unter Windows.

Bei "KVM" wird immer nur die volle (Full-) Virtualisierung angeboten, auf die (theoretisch) jedes Gast-Betriebssystem aufsetzen "können sollte".
.

Mit diesem Sub-Programm - es wird vom Virt-Manager aufgerufen - sehe ich als Admin lückenlos, ob und wie ein Gast-System gestartet wird, wie es "läuft" und auch wieder herunter gefahren wird - also, ob das alles mit rechten Dingen zugeht oder warum es evtl. hakt oder hängt oder sogar abbricht.

Ich sitze quasi vor dem (virtuellen) Bildschrim samt Tastatur und Maus dieser virtuellen Maschine. Essentiell wichtig ist natürlich immer, daß der Host/Gastgeber "absolut" stabil funktioniert.

Von nun an kann ich alle "meine Gäste" von meinem Administrator- Arbeitsplatz aus steuern und überwachen und natürlich auch korrigieren bzw. notfalls reparieren.
.

Aus der Historie als kleiner lokaler Internet Provider in Wiesbaden (ipw.net war 1995 gestartet) ist ein eigener Name-Server essentiell wichtig. Der Nameserver übersetzt den Aufruf z.B. "www.hifimuseum.de" über mehrere verkettete Stufen in die aktuelle IP(v4)-Nummer unseres Servers, ähnlich einem Telefonbuch, bei dem Sie nach Namen suchen und die Telefon-Nummer geliefert bekommen. Und von dem Webserver hinter dieser angegebenen IP-Nummer kommt dann die erste Seite.

Die öffentlich nutzbaren Name-Server sind etwas schwerfällig, da sie oft nur einmal am Tag neu gestartet werden. Die deutsche Domainverwaltung "denic" verlangt sowieso zwei unabhängige Nameserver zwecks Ausfallsicherheit.
.
Der Web-Server trägt dabei die Hauptlast der Museenseiten. Er baut aus den einzelnen Datenbankeinträgen die abgerufenen Seiten zusammen und liefert die - so schnell es geht - aus.

Weiterhin brauchen wir einen Mailserver, der die Mails von draußen, also auch die Mails von unseren eigenen Web-Formularen auf unserem eigenen Web-Server, annimmt. Die Abhängigkeit und die Restriktionen freier Mail-Dienste behagen mir nicht.

Weiterhin wollen wir außer unseren Museenseiten auch größere Dateien (Musiken, Filme, besondere Kataloge und edle Prospekte) öffentlich zur Verfügung stellen. Dazu ist ein Webserver nur bedingt geeignet. Hier ist auch eine Trennung der Funktionen angesagt, und wir bekommen daher auch noch einen "ftp"-Server.
.

Doch das mit den nach draußen aktiven 4 Online-Gästen reicht nicht aus, weil wir ja hin und wieder an einem im Betrieb befindlichen System etwas ausprobieren müssen, zum Beispiel ein PHP- Update oder ein Upgrade.

Weiterhin brauchen wir einen Dummi-Server, wenn der Hauptserver gesichert werden soll. Das geht am Besten offline, weil er auch so zurückgesichert würde. Der Dummi-Server hat nur eine statische Webseite (mit einer simplen Textnachricht "Bitte etwas Geduld"), aber die gleiche IP-Nummer wie der Hauptserver - und kann daher nur alternativ hochgefahren werden.

Zum Testen von neuen Funktionen ist eine weitere virtuelle Maschine sinnvoll, mit einem Duplikat des Hauptservers.
.

Wie und warum auch immer, irgendwann wurde die S.U.S.E. Mannschafft samt ihrer Ideen an die Netzwerkfirma NOVELL in den USA verkauft und der Idealistmus war eingeschränkt. Übrigens fast gleich wie mit der "mysql Firma" in Schweden, die auch mit "Mann und Maus" nach USA verkauft wurde und als mariadb wiederauferstanden ist.

Als dann irgendwann das Linux-Derivat "ubuntu" aus Südafrika mit ganz neuen Ideen von Bedienbarkeit publik wurde, gingen bei den vielen freien Linux-Varianten die Uhren anders. Die geistige Kraft (man nennt es auch Manpower) wurde in die grafischen Oberflächen gesteckt und das opensuse Grundgerüst leicht vernachlässigt.
.

Dann kam die Version 14 (die wurde dummerweise als Version 40 (bis 42) weiter geführt) und erst die Version 42.3 lief dann wieder absolut probelmlos - immer unter dem Gesichtspunkt - als XEN-Server mit Virtualisierung.

Bei der Version 15 fing die Instabilität von Neuem an - die Versionen 15.3 und 15.4 liefen dann wieder stabil. Jetzt (Frühjahr 2024) haben wir gerade die 15.6 "Alpha" am Wickel und die läuft sogar stabil ??????? Es ist fast nicht zu glauben (aber nur noch mit "KVM", nicht mehr mit "xen").
.