Sie sind hier : Startseite →  Hintergründe & Analysen→  Hinter den Kulissen - 1

Dezember 2023 - Hinter den Kulissen - die Zeiten ändern sich.

.

Blicken Sie hinter die Leinwand / die Kulissen ... ein BIld aus dem Kino in Weilmünster im Taunus


Im Herbst/Winter 2023
sind auch wir mit unserem Museen-Server in Düsseldorf heftig angegriffen worden und mussten viele Wochen reparieren. Das war teilweise sehr mühsam. Wie sprach der EDV-Experte : "Do'nt touch a running horse".

Darum hier etwas mehr über die technischen Hintergründe mit einem detaillierten Blick hinter die Kulissen unserer Museen-Seiten - mitsamt unserer Historie ..... und die liest sich so .....

Bei unserer Server-Technik haben wir mehrere Grundrinzipien :

Aller Anfang war der Z80
Ein AMD K5 Prozessor - eine 66 MHz Traum-CPU aus 1996
Unsere 2 GHz AMD Opteron CPU's hatten dann bereits 4 "Kerne"

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 und deren Programmierung (typo3 und php 5 und 7) und
  • (3) den eigentlichen Inhalten bzw. den Daten (dem "Content" in der mysql Datenbank).

.
Das hat sich in den letzten Monaten mehrfach rettend bewährt.
.

und wir haben zwei weitere Prinzipien

Abgeleitet davon sind die Grundsätze unserer Museen-Seiten oberhalb des Betriebssystems genauso strikt, nämlich auch dort eine strenge (absolute) Trennung von :
.

  • (1) Optik (bzw. Gestaltung) und
  • (2) den Inhalten.

.
Auch das hat sich seit über 15 Jahren bestens bewährt.
.

Die Anfänge um 2003 herum - mit Frontpage von Microsoft .....

Ein Blick in die EDV von 1998
in 2010 im Keller unter der Erde

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 (66MHz) 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, weil die Nachfrage noch gering war.

Die nächsten Stufen waren gebrauchte Compaq 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. Ene neue Technik musste her - die sogenannte Virtualisierung dieser Server unter "XEN".
.

unsere "neuen" XEN-Server
mit 8 SCSI-Platten a 72 GB
und 2 Opteron CPUs

Was ist Virtualisierung und warum ?

Mit den ersten 4-Kern Opteron Doppel-Prozessoren (4 x 1,8 GHz) in den (gebrauchten) Compaq / HP Proliant Servern bekamen wir eine richtige "Power-Technik", sodaß sich ein solcher Server stundenlang gelangweilt hatte. Der könnte also einige weitere Aufgaben übernehmen, und nicht nur ein Webserver sein.

Für diese (und andere) Zwecke hatten sich pfiffige Entwickler eine Technik der Server-Virtualisierung ausgedacht, bei der ein Host (der Gastgeber) mehrere Gäste (soganannte "Virtuelle Maschinen" = VMs) betreut.

Die HP/Compaq Proliant Server (also die Hardware) werden mit einer abgeschminkten Linux-Server- Version gestartet, auf der nur der Virtualisierungs-Manager seinen Dienst tut, weiter nichts.

Weiterhin werden auf der (auf einer gemeinsamen großen) Platteneinheit in weiteren gegeneinander abgetrennten jeweils eigenen Partitionen diese VMs (die Gäste) wie ganz normale Server installiert. Bei uns sind es teilweise (nur) 5 Gäste, in großen Rechenzentren können das hunderte von virtuellen Gast-Servern auf einer großen leistungsfähigen Hardware mit z. B. 96 Prozessoren sein.
.

Beipsiel : 5 Reihenhäuser mit 1 Keller

Eine verständliche Erklärung der Virtualisierung und der Sinnn des Ganzen .....

Stellen Sie sich eine Reihenhaus-Zeile mit 5 Häus- chen (oben drauf) und nur einem gemeinsamen "Keller" (unten drunter) vor.

Dieser gemeinsame "Keller" wird zentral mit Strom, Wasser, Gas, Telefon, Internet, TV-Kabel und Abwasser usw. versorgt, aber insgesamt nur einmal für alle 5 Häuschen (oben drauf).
.

Hier der gemeinsame Keller
ein Keller für alle Häuschen
und oben drauf die Häuschen

Das wären (für den Keller) sinnbildlich übersetzt unsere Mehrkern- CPUs, der große Hauptspeicher (RAM), der Plattenspeicher auf SSD's, die Tastatur und der Bildschirm und vor allem - der Netzwerk-Anschluß, der ja (normalerweise) auch nur einmal vorhanden ist.

Jedes der 5 Häuschen oben drauf bekommt also eine virtuelle Netzwerkkarte zu sehen, dazu einen Teil der Prozessorleistung und einen eigenen Teil des Hauptspeichers.

Auf der großen Festplatte bekommt jedes Häuschen seinen eigenen Platz in Form einer eigenen "Platten-Partition". Keines der 5 Häuschen oben drauf kann in eines der anderen Häuschen oder in den Keller rein sehen.

Und diese "virtuellen Gäste" sind gegeneinander abgeschottet und völlig autark.

"Brennt" also eines der 5 Häuschen ab, egal welches von den 5, so dürfen es die anderen 4 nicht merken, und der Keller sowieso nicht. Es ist ein "theoretisch" geniales System.
.

Noch etwas zur Theorie der "Virtualisierung" .......

Nicht ganz korrekt dargestellt, aber durchaus anschaulich

Der Host (und Gastgeber) stellt damit sinnbildlich seinen virtuellen Gästen (oben drauf) 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 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.
.

Es gibt zwei Virtualisierungs-Techniken - "xen" und "KVM"

Bei uns über 10 Jahre erfolgreich mit "xen"

Den Anfang machte ein softwarebasierendes Virtualisierungs-System mit Namen "xen".

Die vom Yast-Installer für den Host (Gastgeber) erkannte und benutzte physikalische Hardware des Servers oder PCs wird auf einer virtuellen Ebene "nach oben" zu den Gästen durchgereicht (emuliert) und das sogar beliebig oft. Jeder der Gäste sieht nicht die eigentliche Hardware des Gerätes, sondern nur dessen virtuelles Abbild.

Diese Software-Virtualisierung kostete damals einiges an CPU-Leistung, sodaß "man" (erstmal nur von Intel und AMD) einen Teil der Virtualisierungs- Funktionen in die neueren Prozessoren (in deren Kernel) mit eingebaut hatte. Und diese (Hardware-) Virtualisierung nennt man "KVM" (Kernel-based Virtual Machine).
.

Das "xen"-Grundsystem
und die "xen"-tools

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".
.

Die Crux liegt in der Komplexität solcher Methoden

Bei der Installation eines Gast-Betriebssystems soll der jeweilige System-Installer eine ganz normale Hardware - einen Server - "vorfinden". Die Virtualisierungs-Ebene des Hosts muß also die komplette Hardware sauber emulieren, und damit dem Installer wirklich "vorgaukeln", er würde auf einer eigenen Hardware aufsetzen.

Die bittere Erfahrung der letzten Monate zeigte aber, viele Programmierer - auch in großen Teams - sind inzwischen überfordert, da überhaupt noch durchzublicken. Denn bei opensuse zum Beispiel haben mehrere Versionen (sogenannte Revisions) einfach versagt.

Die Installation eines Gastes ist im Nirwana verschwunden oder sonstwie abgebrochen. Und eine Revision später lief es dann auf einmal. Soetwas kostet Tage und Nächte und erzeugt Frust.
.

Der zweite Grund für eine Virtualisierung - Komfort des Admins

Die Konzepte der Virtualisierung sind eigentlich seit Jahren ausgereift und stabil - jedenfalls fast immer. Dabei kommt dem Host (Gastgeber) doch etwas mehr Aufmerksamkeit zu, als nur die virtuellen Gäste zu starten und/oder zu beenden.

Außer dem "Virt-Manager" gibt es nämlich den "Virt-Installer" und den "Virt-Viewer". Vor allem der Virt-Viewer ist ungemein wichtig.
.

Der Web-Seiten- Redakteur braucht heutzutage eine komfortable Technik

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.
.

Und das Starten geht transparent und vor allem schnell

Der yast-Installer einer virtuellen Maschine setzt auf einer (bereits vom Host-Betriebssystem) geprüften Hardware-Platform auf und muß daher nicht mehr viel fragen. Die Startprozedur mit dem vom Installer automatisch erzeugten grub2-bootloader geht dann sehr schnell.
.

Wie sieht die Umgebung dieser Museen-Technik heute aus ?

Unser Server-Raum in 2001

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.
.

4 (und mehr) virtuelle Maschinen auf einem Server ....

Der Virt-Manager zeigt die Gäste an

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.
.

Ein zweiter separater Reserve-Server in Bereitschaft ??

So war es in Düssldorf geplant, darum 2 getrennte physikalische Server jeweils mit offline gespiegelten Gästen. Es hatte leider nie funktioniert. Die Installation war viel zu zeitaufwendig. Hier bei uns geht das demnächst - und dazu erheblich schneller. Und es wird noch mehr gehen, weil die Server hinter einer Firewall stehen. Darüber steht mehr in den nachfolgenden Artikeln.
.

Ein Maskottchen sorgt für gute Laune
Unsere erste CD Version

Noch etwas zur Grundlage - dem "opensuse" Linux-Betriebssystem

Mit "S.U.S.E." bzw. dann "opensuse" für unsere ersten Web- Server habe ich mich - damals notgedrungen - ab 1996 beschäftigt. Es begann ganz am Anfang mit der SUSE-Version 4.2 noch auf 48 Disketten und dann kam auf einmal die Version 5.2 auf einer CD, das war super toll. Diese CDs habe ich heute noch.

"opensuse" hatte damals (schon) ein Verwaltungssystem Namens "YAST" ("y"ust another software tool), mit dem sogar ich umgehen konnte. Die anderen Linux- Derivate hatten das nicht und waren - immer unter dem Gesichtspunkt einer "Server-" Installation - damals wie heute sehr unkomfortabel und schwerfällig mit der Kommandozeilen- Tastatur zu administrieren.

Unsere Server, "reale" wie auch "virtuelle" Server, bekamen und bekommen nur in Ausnahmefällen eine minimale grafische Oberfläche installiert. Auf der Terminal-Ebene mit der Kommandozeile geht das (auch heute immer noch) um Klassen schneller.

Am deutlichsten wurde mir das, als ich in Düsseldorf mit dem durchaus gesunden und leistungsfähigen "debian Rescue" System "GRML" den dortigen Server reparieren mußte.
.
"opensuse" hatte auch als eines der ersten Linux-Syteme "xen" unterstützt. Die "KVM" (- Prozessortechnik) gab es damals noch nicht. Ab der opensuse Version 12.3 (etwa aus 2010) lief das bei uns mit 6 und mehr Gästen super stabil - und vor allem problemlos.
.

Der opensuse "Laden" wurde verkauft und bekam Konkurrenz

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.
.

Warum man die opensuse Versionen xx.0 übergehen sollte

Die damaligen opensuse Versionen 10.0, 11.0, 12.0 und 13.0 funktionierten grundsätzlich nur "zur Hälfte". Erst die (verbesserte) opensuse (Folge-) Version 12.3 war und ist wirklich langzeitstabil. Bei der Version 13.2 ist es zum Glück ebenso, das läuft also wirklich über viele Monate stabil.
.

Die 15.6 Alpha vom Dezember 2023 funktioniert bei mir - kaum zu glauben

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 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").
.


Da das jetzt folgende Virtualisierungs-Thema mit der Museen-Web-Technik nur indirekt zu tun hat, ist es auf einer neuen Seite erklärt.
.

- Werbung Dezent -
Zurück zur Startseite © 2007/2024 - Deutsches Hifi-Museum - Copyright by Dipl. Ing. Gert Redlich Filzbaden - DSGVO - Privatsphäre - Zum Telefon der Redaktion - Zum Flohmarkt
Bitte einfach nur lächeln: Diese Seiten sind garantiert RDE / IPW zertifiziert und für Leser von 5 bis 108 Jahren freigegeben - kostenlos natürlich.

Privatsphäre : Auf unseren Seiten werden keine Informationen an google, twitter, facebook oder andere US-Konzerne weitergegeben.