Alle diese Erfahrungen stammen von "opensuse" in 2023
- Hinter den Kulissen oder hinter dem Vorhang
23. Dez. 2023 - Nachdem bei "opensuse" mit den Updates und den Upgrades immer wieder Fehl- schläge zu verkraften waren, haben wir im Team auf unseren beiden Düsseldorfer Servern wie auch bei mir im EDV-Labor natürlich auch "Fedora" und "Debian" und "Ubuntu" und weitere Linux-Server- Derivate bzw. Server-Konzepte zu installieren und auszuprobieren versucht.
.
Mit den preiswerten SSDs mit 128/256 GB für 16/19 Euro war das finanziell gerade noch zu verkraften. Doch die dazu notwendige und verfügbare Zeit wurde immer knapper und die Bedienbarkeit der Server-Versionen ohne den erheblichen (Verwaltungs-) Ballast einer grafischen Workstation- Oberfläche wie Gnome oder KDE war bescheiden. Also hieß es - vorerst bei opensuse bleiben und sich "durchkämpfen".
.
Drei Jobs für einen Kopf - geht das überhaupt ?
Auch hier wieder im Vorgriff - der Server-Admin ist noch lange kein Programierer und der typo3/php- Programierer ist noch lange kein Redakteur. Mir hatte es 30 Jahre lang Freude bereitet, in der EDV von Erfolg zu Erfolg zu springen und überhaupt - bei komplexen Problemen lernfähig zu bleiben.
Die Lernkurve war schon recht steil und bei WIN 10 und WIN 11 hatte ich dann aufgegeben. Aber meine Server zu betreuen und auch noch das "typo3" Redaktionssystem am Laufen zu halten, das fordert. Und ganz nebenbei als Hobby auch noch 45 Tausend Pages zu füllen, macht immer noch Spass. (Jeder "Künstler" möchte auch ein wenig Lob und Applaus einfangen.) Doch auch bei mir sind die Ressourcen irgendwann ausgeschöpft, wie man an den 8 Wochen Server-Blackout sehen konnte.
Die Verkettungen mit den Problemen eines (Remote-) Serverstandortes weit weg in Düsseldorf sind immens. Die Reissleine war gefordert. Jetzt sind die Server wieder im eigenen EDV-Raum wie vor 25 Jahren. Zur Zeit (Dez. 2023) haben wir nur eine 10 Megabit/s Leitung und es geht dennoch recht flott.
.
Die Voraussetzungen für eine stabile Installation des Hosts
- Jede Installation bewegt fast 2 bis 4 Gigabyte an Downloads
Das Host-Betriebssystem muß außer dem Server-Admin niemand Fremdes bedienen. Darum gibt es Möglichkeiten, das System von außen ziemlich "dicht zu machen". Die Grundfunktionen der Virtualisierung benötigen nur eine Schmalspur- Grafik ohne Schnickschnack - wie zum Beispiel "Enlightenment" oder "XFCE4", denn es sind auf dem Host nur ganz wenige Administrator-Programme, die dort benötigt werden.
Ist die Mini- grafische Obefläche samt "X11" und "VNC" installiert bzw. aktiviert, sind es etwa 3 GB Benutzer-Platz in dieser (root) Partition. Damit auch über mehrere Jahre genügend Platz verfügbar bleibt, ist eine 50 GB Partition mindestens ausreichend. Und jetzt geht es los ........
.
Ein Betriebssystem auf einem "nackten" Server installieren
Bei der Installation von "opensuse" kann man über so viele Stolperfallen taumeln, schlingern oder gar knallen, daß einem fast die Lust vergeht. Das jeweilige Mainbord des Servers bestimmt, welche unterschiedlichen Boot-Partitionen überhaupt notwendig sind.
Es gibt nämlich die älteren (und sogar absolut ausreichenden) Main-Boards mit Intel i5 oder i7 oder AMD Ryzen Prozessoren mit einem BIOS, dann die Hybrid-Boards mit BIOS und UEFI im Kompatibility Modus und die neuen reinen UEFI Boards, die mit Bios- Funktionen viel zu oft nichts mehr anfangen können.
Die aktuelle Version des opensuse Yast-Installers (15.6 Alpha oder Beta) "erforscht" das und macht Partitionierungs- vorschläge. Die sollte man nicht ignorieren. Nimmt man also eine (einzelne) SSD (bei uns ab 120 GB aufwärts), wird eine Dos-BIOS Boot-Partition oder eine UEFI Boot-Partition (mit 8 Mega-Byte !!) vorgeschlagen. Dann kommt eine gewaltige "/" Root Partition mit fast dem Rest der SSD- oder SATA-Platte und ganz am Ende eine kleine Swap Partition.
.
- von 1,8 Terabyte zurück auf 50 Gigabyte
Das ist aber für unsere Server-Zwecke absoluter Unsinn. Denn die viel zu große Root-Partition kann man dann nicht mehr (mit gparted) verkleinern (shrinken). In Düsseldorf war diese zwangsweise (automatisch durchlaufende) installierte Root-Patition einer auch noch veralteten opensuse 15.2 Installation damit 1,7 Terabyte groß und in dieser Größe völlig unbrauchbar.
.
Grundgedanken zur Partitionierung eines virtuellen Servers
- Bei großen Platten muß man extrem aufpassen
- Diese MBR Typen-Auswahl hatte bei uns besser funktioniert
- Der Host muß !! stabil starten
Es macht Sinn, sich vorher über die Partitionsgrößen auf der Festplatte für den Host und die VMs (Gäste) ausführliche Gedanken zu machen. Bei einer Neu-Installation einer xbeliebigen VM wird vom Virt-Installer immer erst eine 20 GB große "Datei" (oder größer) im Root- Filesystem vorgeschlagen (eigentlich ist das nur eine Container-Datei im normalen Root-Filesystem), in die/den diese VM dann hinein installiert würde.
Bei 5 oder mehr Gästen sind diese "Partitionen" (Container) im Root-Filesysstem wie normale Dateien zu sehen - aber auch genauso anfällig gegen Abstürze dieses Filesystems - wie ganz normale Dateien. Würde also mein Host gehackt und mein Filesystem irgendwie "demoliert" oder kompromittiert, sind damit auch alle VMs (in diesen Datei-Containern) dahin. Das ist mir viel zu vage, eigentlich bereits zu gefährlich.
.
Ich habe deshalb - seit 15 Jahren mit großem Erfolg - eine andere Host- Gast- Strategie ausgewählt. Die neuen VMs bekommen auf der Festplatte jeweils ihre eigenen Raw-Partitionen (unformatiert) zugeordnet (das "wie" kommt später), in denen die VM dann "machen kann", was sie möchte.
Die Größe der einzelnen Gast-Partitionen wird nach der Art der Aufgabe kalkuliert und bestimmt. Ein Museen-Webserver bekommt zum Beispiel 160 GB, ein Mailserver etwa 40 GB, ein Nameserver nur 20 GB und ein FTP-Server etwa 300 GB oder größer.
.
Der Host bekommt bei mir ganz am Anfang der Platte eine 8 MB (Megabyte) Bios- oder UEFI- Partiton, eine 1 GB (Gigabyte) "/boot" Partition, eine 2 GB "Swap" Partition und eine 50 GB "7" Root Partition. Das "warum 50 GB" kommt später.
.
- Das war eine Beispiel/Muster-Installation als Testumgebung
Worüber man jetzt schon stolpern kann - bittere Erfahrung
Erst viel viel später - nach der ersten erfolgreich installierten Test-VM - stellt man nämlich fest, opensuse mit nur einer Sata- oder SSD- Platte (also ohne ein RAID1 mit 2 Platten oder ein RAID5 mit mehreren Platten) hat zur Zeit ein irreparables Problem. Und das geht so :
Installiere ich auf "einer" SSD eine neue VM, wird bei der Installation die zugeordnete bislang unformatierte 160GB RAW-Partition mit 3 oder 4 Sub-Partitionen aufgeteilt und diese einzeln mit EXT4 formatiert - also auch wieder (1) /boot und 82) Swap und (3) /root und ab und zu auch noch (4) /data.
Diese 3 (oder 4) Sub-Partitionen müssten nicht nur für das gestartete Betriebssystem der VM, sondern später auch für den Host transparent zu sehen (und offline zu mounten) sein. Bei den RAID-1 Platten sind sie zu sehen (und zu mounten), bei einer einzelnen (nicht RAID) Platte sind sie zwar mit "fdisk" herauszufinden und aufzulisten, aber mit "lsblk" sonst unsichtbar. Und mounten kann man diese Subpartitionen auch nicht. Das ist eine ganz dicke Macke, die mich Tage und Nächte gekostet hat. Wer war das ?
.
Wie konnte ich mir helfen ?
Die allgemeinen Linux-Befehle auf der Kommandozeile für die sogenannten "Block-Devices" - die Festplatten und deren Partitionen - sollte man natürlich kennen :
"lsblck" (lsblk -f -m) und "fdisk" (fdisk -l) und "sfdisk -l /dev/sda"
und natürlich später dann mount und umount.
Hier die unterschiedlichen Beispiele:
.
(1) Korrektes Auflisten aller Partitionen und Subpartitionen ....
..... eines virtualisierten RAID-1 Systems auf Host-Ebene, also auch mit den Subpartitionen der bereits angelegten VMs/Gäste :
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 931,5G 0 disk
├─sda1 8:1 0 500M 0 part
│ └─md0 9:0 0 499,9M 0 raid1 /boot
├─sda2 8:2 0 3,9G 0 part
│ └─md1 9:1 0 3,9G 0 raid1
├─sda3 8:3 0 58,6G 0 part
│ └─md2 9:2 0 58,6G 0 raid1 /
├─sda4 8:4 0 1K 0 part (das ist nur der Name / Verweis der 4. = erweiterten Partition)
├─sda5 8:5 0 156,3G 0 part
│ └─md3 9:3 0 156,2G 0 raid1 (hier wohnt der erste Gast)
│ ├─md3p1 259:8 0 1G 0 part
│ ├─md3p2 259:9 0 4G 0 part
│ ├─md3p3 259:20 0 60G 0 part
│ └─md3p4 259:21 0 91,2G 0 part
- .... hier kommen drei weitere Gast-Partitionen - aber betrachten wir nur "sda5" vom Gast 1 oben
├─sda6 8:6 0 156,3G 0 part
│ └─md4 9:4 0 156,2G 0 raid1 (hier wohnt der zweite Gast)
│ ├─md4p1 259:3 0 1G 0 part
│ ├─md4p2 259:4 0 4G 0 part
│ ├─md4p3 259:5 0 60G 0 part
│ └─md4p4 259:6 0 91,2G 0 part
├─sda7 8:7 0 40G 0 part
│ └─md5 9:5 0 40G 0 raid (hier wohnt der dritte Gast)
│ ├─md5p1 259:13 0 8M 0 part
│ ├─md5p2 259:14 0 2G 0 part
│ └─md5p3 259:19 0 38G 0 part
└─sda8 8:8 0 40G 0 part
└─md6 9:6 0 40G 0 raid1 (hier wohnt der vierte Gast)
├─md6p1 259:10 0 8M 0 part
├─md6p2 259:11 0 2G 0 part
└─md6p3 259:12 0 38G 0 part
.
Die Partitonen "sda6" bis "sda8" (= md4 bis md6) enthalten in diesem Beispiel bereits weitere installierte virtuelle Maschinen, die aber zum Verstehen unwichtig sind.
.
(2) Wie sieht solch ein Gast seine eigenen Partitionen ?
Dieser Gast wohnt in der RAID-1 Partition "md3", die sich auf zwei SSDs aufteilt, auf "sda5" und "sdb5" (sdb ist hier nicht aufgelistet, ist aber baugleich).
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 253:0 0 156,3G 0 disk
├─vda1 253:1 0 1G 0 part /boot
├─vda2 253:2 0 4G 0 part [SWAP]
├─vda3 253:3 0 60G 0 part /
└─vda4 253:4 0 91,2G 0 part /vol2
.
An der Bezeichnung "vda" erkennt man, hier sind es virtuelle Disks bzw. virtuelle Partitionen.
.
(3) Fehlerhaftes Auflisten der Partitionen ohne Subpartitionen
... eines virtualisierten "NICHT" RAID-1 Plattenspeichers mit nur 1 SSD auf Host-Ebene, und damit ohne die Subpartitionen der bereits angelegten und funktionierenden Gäste :
fdisk -l /dev/sda
Disk /dev/sda: 232.89 GiB, 250059350016 bytes, 488397168 sectors
- Device Boot Start End Sectors Size Id Type
- /dev/sda1 * 2048 4196351 4194304 2G 83 Linux
- /dev/sda2 4196352 8390655 4194304 2G 82 Linux swap / Solaris
- /dev/sda3 8390656 113248255 104857600 50G 83 Linux
- /dev/sda4 113248256 488397167 375148912 178.9G f W95 Ext'd (LBA)
- /dev/sda5 113250304 364908543 251658240 120G 83 Linux
- /dev/sda6 364910592 488397167 123486576 58.9G 8e Linux LVM
.
Sie sehen, daß dort zum Beispiel "sda5p1" usw. fehlen, (während diese Subpartitionen bei der RAID-1 Version weiter oben zu sehen sind) - obwohl die VM hier korrekt läuft.
.
(4) Hilfsweises Auflisten einer Gast-Partition mit fdisk -l ......
mit der Option -L und !!! der Option der gezielten Device-Adresse "/dev/sda5"
.
fdisk -l /dev/sda5
.
Disk /dev/sda5: 120 GiB, 128849018880 bytes, 251658240 sectors
.
- Device Boot Start End Sectors Size Id Type
- /dev/sda5p1 2048 4208639 4206592 2G 82 Linux swap / Solaris
- /dev/sda5p2 * 4208640 130045951 125837312 60G 83 Linux
- /dev/sda5p3 130045952 251658239 121612288 58G 83 Linux
.
Ich kann die Subpartitionen zwar sehen, aber nicht "anfassen"
Das leider öfter vorkommende Problem ist, ein Gast startet nicht mehr, weil der Bootloader der VM sich zerstückelt hat. Jetzt komme ich an diesen Gast nur noch über den Host ran, indem ich mir die Subpartiton des boot- oder root- Systems vom Host aus "mounte" und den Loader dort jetzt reparieren kann. Geht das nicht mehr, ist die Partiton irrearabel tot. (abgesehen von einem Trick - kommt auch später) - Damit wieder ein GAU. So (mit nur einer SSD) geht es also nicht.
.
Das sind aber nur die kleineren Erkenntnisse, ....
- Notgedrungen auf KVM umgestiegen
.... die Sie nach 2 oder 3 Tagen kapiert und im Griff haben. Dieses Problem in ein Forum gestellt - ergibt eine hilflose Antwort, "xen" würde hier schon keiner mehr benutzen. Aha. Deshalb wird es (vermutlich) ab opensuse 15.3 nicht mehr akribisch gepflegt und stürzt öfter ab.
Unter opensuse 15.5 (auch 15.6 Beta) und XEN auf dem Host friert die grafische Oberfläche von X11/"Enligtenment" nach drei Mausklicks (oder längeren Bewegungen) einfach irreversibel ein. Im Forum hatte ich da schon gar nicht mehr nachgefragt und bin dann auf eine Neuinstallation mit "KVM" mit all den Nachteilen der Hardware-Abhängigkeiten umgestiegen.
.
Ich brauche also immer 2 gleich-große Platten zum Spiegeln
Wenn also der Host keine Kontrolle mehr über seine "Gäste" hat, ist das ganze virtuelle Konstrukt mit den Gästen am Schleudern. Darum, probieren Sie es erst gar nicht mit nur einer SSD, es geht (vorläufig) nicht. Jedenfalls habe ich den Wurm nicht gefunden.
So habe ich - aufbauend auf der Erfahrung - 2 recht große (gleich-große) 1 TB SSDs genommen (ehemals 89.- Euro), eine davon völlig neu, die andere bereits für Musterinstallationen benutzt. Dieser kleine Unterschied wurde mir erst bewußt, als ich wieder (zum 10. Male) einen neuen Host-Server aufgesetzt hatte, den "KVM"-Host sorgfältig eingerichtet hatte und die erste VM (in einer 160 GB RAW-Partition) prima und vollständig am Laufen hatte.
Insgesamt hatte ich damit die beiden gleich großen Partitionen sda5 und sdb5 erstellt, die dann zur RAID-1 Partition md3 gespiegelt und dort drinnen 4 Sub-Partitionenn erzeugt und auch angezeigt bekommen : mit lsblk :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 931,5G 0 disk
├─sda1 8:1 0 500M 0 part
│ └─md0 9:0 0 499,9M 0 raid1 /boot
├─sda2 8:2 0 3,9G 0 part
│ └─md1 9:1 0 3,9G 0 raid1
├─sda3 8:3 0 58,6G 0 part
│ └─md2 9:2 0 58,6G 0 raid1 /
├─sda4 8:4 0 1K 0 part - das ist jetzt die riesen große "Erweiterte Partition" :
├─sda5 8:5 0 156,3G 0 part
│ └─md3 9:3 0 156,2G 0 raid1
│ ├─md3p1 259:8 0 1G 0 part
│ ├─md3p2 259:9 0 4G 0 part
│ ├─md3p3 259:20 0 60G 0 part
│ └─md3p4 259:21 0 91,2G 0 part
Auf der 2. PLatte sdb sieht es genauso aus. Diese md3 (Raid-1)- Partition enthält die 4 Subpartitionen - gespiegelt über sda5 und sdb5.
Und jetzt wollte ich ganz normal weiter machen und die nächsten 160 GB RAW-Partitionen "sda6" und "sdb6" und dann weitere RAW-Partitionen für die nächsten Gäste erstellen und jeweils zu "md4" und "md5" spiegeln.
.
Es geht nicht, keine weitere Partition möglich ..... ???
- Das hier zu bestätigen war mein Fehler
Auf der ersten Platte "sda" klappte das, auf der 2. Platte "sdb" konnte ich auf einmal keine weitere Partiton mehr erstellen. Nach längerem Suchen stellte sich heraus, bei der ersten Platte "sda" war ein DOS MBR installiert, auf der 2 Platte "sdb" ein GPT MBR - also ein unterschiedlicher "Master Boot Record" (von einer vorherigen Installation).
Auf diese Idee muß man erst mal kommen. Der openSUSE Installer hatte das beim Erzeugen / Anlegen der RAID-1 Partitonen "diesmal" nämlich nicht angemeckert, wobei der Installer sonst immer so gut wie alles anmeckert, das ihm nicht schmeckt oder gefällt.
Jedenfalls war wieder ein ganzer Nachmitag rum, bis ich (schon wieder) die Notbremse gezogen hatte und nochmal alles von vorne neu installiert habe. Ein sauber laufender XEN- pder KVM-Host mit einem ersten sauber laufenden Gast dauert auch bei mir bestimmt 2 bis 3 Stunden, je nach Auslastung der opensuse Repository-Server.
.
Neue Platten immer erst mit "gparted" bereinigen bzw. killen
Diesmal hatte ich dann den Server mit den beiden 1TB SSDs erst mal mit einem "debian gparted Bootstick" gestartet und vor der Installation erstmal alles gekillt, das dort irgendwie (noch = an Altlasten) angezeigt wurde.
Sodann habe ich auch wieder mit diesem "gparted" auf den beiden bereinigten jetzt völlig leeren SSDs jeweils den "DOS-MBR" installiert. Dieser "MBR" (das steht für Master Boot Record) ist (aus bitterer Erfahrung) die nach wie vor problemlose Basis für alle weiteren Installationen (hat aber kleine Einschränkungen bei mehr als 1 TB Partitionen).
Der DOS-MBR ermöglicht seit Urzeiten 3 primäre Partitionen und dann eine 4. - sehr sehr große - erweiterte Partition. Das ist aber genau das, das ich brauche. In der erweiterten Partition werden nämlich alle weiteren logischen Partitonen für meine virtuellen Gäste angelegt. Und das klappt hervorragend, es gibt da keine weiteren "Diskussionen" mit dem YAST-Installer mehr.
.
Auch diese Erfahrung hat mir wieder eine Menge Stunden "geklaut".
.
Es geht weiter mit der Installation meines Webservers .....
Die eigentlich wichtigste (erste) "vrituelle maschine" (VM) ist unser Museen-Webserver. Da die geplanten Upgrades noch nicht funktioniert hatten, ist die opensuse Version 12.3 zur Zeit noch zwingend erforderlich. Laut der Theorie der Virtualisierung dürfte das aber "überhaupt" kein Problem sein.
Auf älteren XEN-Hosts mit opensuse 42.3 (oder früher zum Beispiel) ging die Installation relativ normal (aber schon etwas sehr schleppend) bis zum erfolgreichen Neustart.
Ab der Version 15 oder besser 15.1 (die Versionen mit 0 nehme ich nie wieder) hörte die Installation mitten drin einfach auf. Keine Fehlermeldung, keine Reaktion auf irgend eine Taste, weg war der Text mit einem schwarzen Bildschirm.
Bei der Auswahl der Bildschirmauflösung konnte ich über Stunden auswählen, was ich wollte, bei der CPU ebenfalls die angeblich sichere Variante oder eine variante mit oder ohne ACPI usw. - die 12.3 ISO-Installation verschwand nach wie vor "im Nichts".
.
Ist es wirklich immer wieder zufallsabhängig ?
Durch reinen Zufall auf der Suche nach einem ganz anderen Problem fand ich in einem ganz anderen Forum einen goldenen Tip, "wähle doch bei dem Bildschirm (Screen) einfach mal "NO KMS" aus".
Ich konnte damit bislang (20 Jahre lang) nichts anfangen - nie gebraucht und nie hinterfragt. Der bis dahin unbekannte Text ging so:
- By Default the video resolution is automatically determined using KMS (Kernel Mode Settings). If this setting does not work on your system, choose "No KMS "
.
Also mal etwas Neues probieren .... - "NO KMS" ? Was ist das ?
Ich probierte das dann auch gleich - Nachts um 3 Uhr - mal aus ...... UND es funktionierte !!! Der Mauszeiger weigerte sich zwar beinahe standhaft und schlich nur so über den Bildschirm, aber es funktionierte wenigstens - ich konnte die Installation komplett mitverfolgen - samt einem problemlosen Neustart dieses "opensuse 12.3" Gasts.
Und jetzt kommt der eigentliche Hammer : Bei der ganz neuen opensuse 15.6 Alpha Version (vom Nov. 2023) geht es auf einmal wieder ... "ab wie die Feuerwehr", wie in alten Zeiten. Was war da passiert ? Warum kann man die Version 12.3 jetzt auf einmal wieder problemlos installieren - ohne Tricks und ohne Gummihammer ??
Auch das hatte mich viele Tage und Nächte (und Nerven) gekostet, denn ich war auf diese alte Version 12.3 immer noch (wie sagte da jemand : alternativlos) mit meinem gesamten Museen- Datenbank-Umfeld angewiesen.
.
Jetzt kommt ein Blick in die Technik bei uns im Haus
Der Server steht jetzt wieder bei uns in Wiesbaden und funktioniert. Wie, das kommt auf den folgenden Seiten.
.
