Laufzeit und Neustart

Okay, ich kenne mich mit Ceph nicht aus. Aber das ist doch im Kontext dieses Threads kein Argument. Und am Ende des Tages ist es auch in deinem Kontext wahrscheinlich keine dauerhafte Lösung, oder?

Vor allen wird Ceph in Proxmox-Umfeld aus einen eigenen Repository installiert. Man könnte also relativ problemlos mit apt-pinning, den proxmox-offline-mirror o.ä. dafür sorgen, dass die Pakete aus den Repo nicht bei einen regulären Update mit angehoben werden, der Rest aber schon, auch ohne apt-mark. Dafür hat man dann halt ggf. Probleme mit Abhängigkeiten, wenn der Rest von ProxmoxVE eine neuere Version von Ceph will.

Und natürlich ist es keine Dauerlösung. Ich meine, vielleicht liege ich falsch, aber war es nicht sogar so, dass man einzelne OSDs löschen kann und die Daten (sofern genug Gesamtkapazität mit anderen OSDs da ist) dann halt über die anderen bedient werden? Genau für solche Szenarien hat man ja eigentlich OSDs.
 
Vor allen wird Ceph in Proxmox-Umfeld aus einen eigenen Repository installiert. Man könnte also relativ problemlos mit apt-pinning, den proxmox-offline-mirror o.ä. dafür sorgen, dass die Pakete aus den Repo nicht bei einen regulären Update mit angehoben werden, der Rest aber schon, auch ohne apt-mark. Dafür hat man dann halt ggf. Probleme mit Abhängigkeiten, wenn der Rest von ProxmoxVE eine neuere Version von Ceph will.

Und natürlich ist es keine Dauerlösung. Ich meine, vielleicht liege ich falsch, aber war es nicht sogar so, dass man einzelne OSDs löschen kann und die Daten (sofern genug Gesamtkapazität mit anderen OSDs da ist) dann halt über die anderen bedient werden? Genau für solche Szenarien hat man ja eigentlich OSDs.

Was mich allerdings wundert, ist, dass hier offenbar eine Minor-Version solche Regressions verursacht. Aber ja, scheint heute wohl normal zu sein: Release fast, release often und dazu noch ordentlich Featuritis.

Selbst ZFS, also das Filesystem, bei dem man Systeme vom Strom nehmen, Festplatten im laufenden Betrieb disconnecten oder den Computer im laufenden Betrieb gegen die Wand schmeißen kann/konnte, die HDDs danach ausbauen und trotzdem eine gute Chance hatte, dass der Pool auf einem neuen System importiert werden konnte, hatte in den letzten Jahren Regressions, die man mit all den Dingen, die ich vorher aufgezählt habe, nicht provozieren konnte.

Bis vor ein paar Jahren habe ich sogar noch die Oracle-Solaris-Dokumentation verwendet, um meine ZFS-Pools zu verwalten. Die ist mittlerweile allerdings wohl etwas outdated. Wobei ich ehrlich gesagt keine der ganz neuen Features nutze, die ZFS heute bietet. Man lernt eben die Limitationen eines Systems kennen und plant entsprechend darum herum. Oh und ja, ich bin kein Fan von Oracle, aber so gute Dokumentation, findet man heute kaum noch iregndwo.

Aber Dokumentation lesen, planen, sich mit einem System und seinen Limitationen auseinanderzusetzen und Verantwortung für die eigene Infrastruktur zu übernehmen, ist heute eh nicht mehr angesagt. Lieber Compliance-Regulatorien schaffen, die einen von jeglicher Verantwortung entbinden, die Technik hinter zig Abstraktionsschichten verstecken und im Zweifel die AI fragen.

Und mit AI wird das Ganze nur noch schlimmer. So lange Output generieren, bis er irgendwie passt, und wenn jemand eine Regression feststellt, einfach noch mehr Output generieren, der dann zwar vielleicht die ursprüngliche Regression fixt, gleichzeitig aber drei neue aufmacht.

Rant Ende ;)
 
Last edited:
  • Like
Reactions: Johannes S