Zwischendurch fallen wegen dem Server bei STRATO oder wegen Proxmox Themen an, bei denen es was zu beachten gab. Doch nicht immer ist es so viel, dass ich dabei eine eigene Webseite dafür anlegen möchte. Es ist aber oft erwähnenswert, so dass ich dies hier sammle und zusammen darstelle.
Themen auswahl:
Nach rund einem Jahr mit dem ersten Server wurden die Preise für die Server angezogen. Das war nicht viel im Vergleich zum Gesamtpreis. Doch dann gab es einen Angebotspreis für einen anderen Servertyp der bei Rubrik "Limited Hardware" ohne vereinbarte zeitliche Begrenzung ist. Ich konnte durch das Angebot zum Einen auf das alte Preisniveau absinken und zum Anderen ein kleines Hardware Upgrade durchführen. Nach einiger Zeit der Überlegung habe ich dann mich Entschlossen den wechsel zu machen. Das heißt, ich habe den neuen Server bestellt und ein Paar Tage später die Kündigung des alten beantragt. Kündigung heißt, man hat bis zum Tag der Kündigungsfrist Zeit und kann den Server noch vollständig verwenden. Danach wird alles abgeschaltet. Vorher kann man auch per Kunden Login die Kündigung wieder zurück ziehen. Ich hatte ab dem Zeitpunkt noch fast einen Monat Zeit alles vorzubereiten. Hier mal einen Vergleich der Server:
Im Bild kann man einen Ausschnitt sehen von meiner Serverkonfiguration. Er hat eine Intel Xeon CPU, mit vier Kernen. Man sieht, er hatte sowohl SSD, als auch Festplatten.
Die Festplatten sind für die Nutzdaten vorgesehen und als Soft-RAID-1 konfiguriert, wenn der Server initial aufgesetzt wird. Varianten mit Hard-RAID habe ich wegen bekannter Gründe nicht gewollt.
Die SSD war alleine und damit ohne RAID. Auf ihr ist das OS installiert gewesen. Um die Festplatten auch nach der Proxmox installation als Soft-RAID-1 konfiguriert zu haben, habe ich sie mit ZFS zu einem RAID-1 verbunden und nur auf denen
die VMs und Container installiert.
Der Server hat nur eine Anbindung von 100Mb/s gehabt. Das reichte mir, denn egal ob zu Hause oder Mobil konnte ich nicht mehr Geschwindigkeit von meinem lokalen Anschluss erwarten. Wenn man viel Traffic erlauben möchte oder seine
Glasfaserleitung beim Verbinden ausnutzen möchte, kann man ein Gigabit Paket zusätzlich buchen.
Der neue Server hat nun bei Netzwerk, CPU Kernen und RAM Größe die selben Eigenschaften.
Die CPU ist ebenfalls eine Xeon CPU einer jüngeren generation. Dies bringt im Vergleich ein paar technische Neuerungen mit sich. Der RAM ist nun modernerer DDR4 Speicher und damit schneller.
Festplatten hat dieser Server nicht mehr. Er kommt nur mit zwei SSDs daher, die initial als Soft-RAID-1 konfiguriert werden. Das OS wird auf denen installiert und die Nutzdaten müssen nebenher auf diesen gespeichert werden.
Die modernere CPU und der schnellere RAM sind nett und machen das System schneller. Das mit den SSDs und der dann nicht mehr vorhandenen Festplatte ist allerdings eine Umstellung. Wie ich damit umgegangen bin, weiter unten.
Die Änderung wegen Festplatten und den SSDs musste ich erst mal begegnen. Die SSDs sind im STRATO Original mit Linux MD-RAID konfiguriert. Das soll man eh nicht für Proxmox, vor allem nicht für die Gäste verwenden.
Ein RAID halte ich bei Festplatten für sinnvoll da diese durch die Erschütterungen schnell ausfallen können. In einem Rechenzentrum sind auch naturgemäß mehr Erschütterungen vorhanden als bei einem Rechner zu
Hause. Jedoch SSDs haben nicht das Problem auf Erschütterungen empfindlich zu sein. Sie können im Prinzip auch ausfallen. Jedoch ist das hier unwahrscheinlicher als bei Festplatten. Daher halte ich die Konfiguration mit RAID-1
für SSDs nicht nötig und habe mich für das einzeln verwenden der SSDs entschieden.
Ich hätte nun die SSDs einzeln in Proxmox als Storage für VMs konfigurieren können. Aber man kann die SSDs auch "hintereinander Schalten", wodurch sich die Speichervolumen summieren. Ein RAID-0 tut das,
benötigt aber gleich große Disks. Dafür hätte man für Proxmox dann das gesamte System mit ZFS aufsetzen müssen, was zwar unterstützt wird, aber inkompatibel mit der alten Provisionierungs VM ist. Dort
wurde LVM+ext4 verwendet. Proxmox nutzt standardmäßig LVM für Volumen. Das Root bekommt ein eigenes Volumen und Gäste werden im sog. LVM-Thin abgelegt. LVM wiederum kann man auch verwenden um die sog. Volumengruppe
über mehrere Disks (Physikalische Volumen) zu verteilen. Dem LVM sind unterschiedliche Größen dabei egal.
Also entschied ich mich dafür die erste SSD mit LVM vor zu sehen, das "Root" Volumen darauf zu haben und dahinter das LVM-Thin Volumen. Die zweite SSD "verlängert" die Volumengruppe und das LVM-Thin Volumen
geht über die ganze SSD. So hab ich 960GB SSD zur Verfügung, statt 480GB. Die VMs werden dann also auf den LVM-Thin Bereich geschoben.
Der normal Weg um Proxmox auf einem neuen Server umziehen zu lassen ist, von allen Maschinen ein Backup anfertigen (muss extern liegen), Proxmox auf den neuen Server neu installieren und dort die Maschinen aus dem Backup wieder her zu
stellen. Doch eine neu installation war mir zu aufwändig. Da das alte System bereits mit LVM für das System lief, habe ich eine andere Idee gehabt. Ich habe natürlich von allen Maschinen trotzdem ein aktuelles Backup
gemacht.
Doch ich habe dann beide Server in das Rescue OS booten lassen (der Neue war bereits initial eingerichtet und ich hatte Daten kopiert). Es steht auf beiden SSH zur Verfügung und das bereits bekannte "dd" Tool, mit dem man
durch einen SSH Tunnel die komplette SSD von alt nach neu kopieren kann. Die alte SSD war auch kleiner als die Neue, passte also mühelos auf die Neue. So habe ich per SSH Tunnel wieder die Proxmox installation vom alten Server auf den
neuen umziehen lassen.
Dort angekommen musste ich erst mal LVM an die neue Größe der ersten SSD anpassen. Dagegen das Root Volumen von 126GB auf 20GB verkleinern, damit hinten Platz entsteht für LVM-Thin. Danach habe ich die andere SSD für
LVM konfiguriert und danach die Volumengruppe von Proxmox um die zweite SSD vergrößert. Als letzten Schritt habe ich wie in der Installationsanleitung mich in ein Change-Root in den Proxmox begeben und die Nachkonfiguration
erneut gemacht. Somit war ich fertig und habe den neuen Server umgestellt auf "Standardbetriebssystem" und neu gestartet.
Fast jeden falls. Der Proxmox hat aufgrund des neuen Hostnamen das System als neuen Proxmox "Node" angelegt, weshalb ich einiges vom alten System bereinigen musste. Doch das fand sich schnell. Im Proxmox habe ich dann erst das
LVM-Thin Volumen angelegt und als neuen Storage eintragen lassen. Und als letzten schritt auch hier aus dem Backup die VMs bzw. Container wiederherstellen lassen. Danach war alles fertig und läuft nun seit einiger Zeit. Vor allem: es
läuft stabiler als der Alte. Diesen hab ich dann den rest des Monats mit minimalem Betrieb weiterlaufen lassen.
Wenn der Proxmox Server eine Zeit im Einsatz ist, kommt es dazu, dass man das System auf eine neue Version der Distribution upgraden muss. Wann das der Fall ist, hängt vom Release Zyklus von Debian ab, sowie davon, wie schnell die
Proxmox Entwickler ihren eigenen Anteil darauf aktualisiert haben. Eine der Methoden ist dann nicht ein Upgrade zu versuchen, sondern Backups aller Maschinen zu machen, mit der neuen Version neu zu installieren und danach mit einem Restore
die Maschinen wieder in das System zu ziehen. Durch das Design von Proxmox geschieht dem kritischen Teil, also den Maschinen dabei quasi nichts.
Doch das wäre in dem Setup des STRATO Servers mit Umständen verbunden. Man müsste die ganze Installationsanleitung noch einmal durch arbeiten, um den Server neu installieren zu können. Zweite Möglichkeit ist das
direkte Upgrade. Das funktioniert grundsätzlich und mit dem STRATO Server im Hintergrund etwas einfacher.
Vor einiger Zeit stand das Upgrade von Proxmox Bullseye auf Bookworm an und ich habe das Upgrade gemacht. Die Grundsätzliche Vorgehensweise wird auf dem Wiki von Proxmox erklärt.
Während des Upgades wird man zu einzelnen Dateien im System gefragt, was mit denen geschehen soll. Also soll die Version des Entwicklers installiert, die alte behalten werden oder will man beide (sofern möglich) zusammenführen. Man sollte dabei Grundsätzlich dabei so verfahren:
In der hier gezeigten Anleitung wurden einige Dateien auch angefasst, um den Proxmox auf den Server anzupassen. Fernrer kann es beim ersten Distributions-Upgrade nach der Installation zu einer besonderen abfrage des Bootmanagers kommen. Daher hier für diese noch ein Paar spezielle Hinweise.
Hier muss ein wenig aufgepasst werden. Wenn hier die normalen Einstellungen gesetzt und geladen werden, verlieren wir die Verbindung zum Server. Außerdem kann sich dann ggf. plötzlich jeder mit Passwort anmelden, was in der
Anleitung abgestellt wurde. Man hat hier die Option mit der Shell zu wählen, bei der man die Datei selber bearbeiten kann. In dem Fall vom Upgrade von 7 nach 8 waren die Änderung unter anderem das Entfernen einer Einstellung die
nicht mehr unterstützt wird und bald entfernt. Weiter wurde eine Einstellung umbenannt. Beides Dinge, die man mal eben auf der bestehenden Datei machen konnte.
Wäre das so nicht möglich gewesen, hätte ich die Version per Variable $DPKG_CONFIG_NEW als Kopie daneben geschrieben, in der die Änderungen aus der Änderung der SSH
Konfiguration übernommen und danach beide Dateien miteinander getauscht. Dann sollte da nichts passieren.
Wenn wegen Änderungen an der Datei gefragt wird, dann liegt es an den Einstellungen für die Serielle Konsole. In der Datei wurden Einstellungen gesetzt, damit der Grub-Bootmanager zum einen die Serielle Konsole unterstütze und zum Anderen der Linux-Kernel, wenn Proxmox startet. Es ist nicht sehr schlimm, wenn man hier die originalen Einstellungen installieren lässt. Nur geht beim Neustart dann die serielle Konsole so lange nicht mehr, bis man die Datei wieder nach Anleitung angepasst hat. Im Normalfall völlig ohne Bedeutung. Jedoch kann es zur Überwachung des ersten starts des Upgrades sinnvoll sein auch auf der seriellen Konsole zu zu schauen. Aber man kann hier erst mal die Paketversion nehmen, das Upgrade bis zum Punkt vor dem Neustart abschließen und dann die Einstellungen wieder setzen ("update-grub" nicht vergessen).
Diese Frage bekommt man gestellt, wenn man ein Upgrade des Proxmox macht, nachdem das System mit der hier gezeigten Methode aus der VM auf den STRATO Server kopiert wurde. Der Grub Bootmanager stellt fest, dass er die Disk, auf die er zuvor
installiert hatte, nicht mehr findet (er sucht die VM Disk). Bei der richtigen Auswahl steckt der Teufel im Detail und hängt davon ab, wie man auf dem STRATO Server die Disks konfiguriert hat. Server mit NUR 2xSSD bzw. 2xHDD verbunden
zu Soft-RAID-1 per ZFS (Linux MD-Raid soll ja nicht bei Proxmox) wählen sinngemäß "/dev/sda". Server mit Hardware-RAID die erste Disk (sorry keine Ahnung wie das dann heißt). Hat man nur eine Disk ist das
auch "/dev/sda". Hat man so wie mein erster Server 1xSSD und 2xHDD dann ist das OS ohne Soft-RAID installiert und man wählt "/dev/sda". Die Festplatten wären dann nämlich "/dev/sdb" und
"/dev/sdc" und da sollte man Grub nicht installieren. Dann bootet das System nicht mehr.
Hat man das bestätigt sollte der Bootmanager installieren. (Im Notfall kann man das im Rescue-OS korrigieren.) Bei weiteren Upgrades sollte das nicht mehr gefragt werden.
Das Rescue System kann bei Upgrades verschieden helfen. Zum Einen kann man vor dem Upgrade dorthin wechseln. Man hat die Möglichkeit ein komplettes Backup des Proxmox Systems anzufertigen. Man wählt im Server Login den Wechsel auf
das Rescuesystem aus und "Kein Hard Reboot". Nachdem der Server Login anzeigt, dass alles Umgestellt ist, befiehlt man dem Proxmox Server den Neustart. Für das Backup habe ich einen Dump der SSD gemacht, auf der Root
installiert war. Als Ziel kam bei mir ein HiDrive zum Einsatz, den ich per SSHFS gemountet habe. Das muss man im Rescue OS kurz nachinstallieren. Per Windows Freigabe, also CIFS geht das leider nicht, da selbst das nach installieren nicht
funktioniert. Ich habe mit dem "dd" Befehl (vgl. Installationsanleitung) den Dump als Datei in das HiDrive schreiben lassen. Mit dem Tool kann man aber auch einen Dump nach Hause analog in Rückwärtsrichtung durch einen
SSH Tunnel machen.
Andrer Einsatzzweck für das Rescue ist, wenn man durch das Upgrade Probleme hat. Dabei ist zu beachten, dass sobald man Proxmox Tools aufrufen muss (z.B. das "proxmox-boot-tool" oder "grub-update" um den Bootmanager
zu fixen), in eine "Change Root" Umgebung wechseln muss wie in der Installationsanleitung gezeigt.