Homeserver Proxmox, CasaOS, oder ?

The_Chicken schrieb:
Ja Unraid fällt raus bei mir, 1x zahlen hätte ich ja kein Problem,
nur als Info, die Lizenz gibt es auch noch, nur halt "überdimensioniert" für deinen Case ...

The_Chicken schrieb:
aber auf jährliche Lizenz immer wieder kaufen hab ich kein Interesse.
auch hier als Info, dir ist klar das Unraid nach einem Jahr nicht "abläuft" und irgendwas nicht mehr funktioniert ... sondern du nur "feature mäßig" dann auf dem Stand bleiben würdest ...

Sicherheitsupdates und co kommen auch für "ältere" Versionen ...

das NUR als Info ;) nicht dass dies falsch interpretiert wurde ...

und für das was oben genannt wurde ... wirst du wohl nicht die evtl. kommenden Features brauchen ... und selbst wenn in 2 - 3 Jahren was dabei sein sollte, dann bucht man das Update und gut ist ;) und hat wieder 1 Jahr ...
 
  • Gefällt mir
Reaktionen: andy_m4
Oki, dann müsste man sich das mal Überlegen, wenn es im Angebot ist.
hast du da Erfahrungen ? wie happy bist du mit Unraid?
Ist ja auch alles ohne Cloud gedöhns, also rein auf der Hardware daheim richtig?
 
GrillSgt schrieb:
Viele - ich nenne sie mal Neulinge, bzw. technisch nicht so versierte / nicht so IT-Affine Menschen (anders als wir) dürfte es völlig Hupe sein was für ein Dateisystem genutzt wird. Womöglich wissen einige Leser:innen hier nicht einmal wo von wir hier überhaupt sprechen ;)
Ja. Das war auch schon mein Gedanke, weshalb ich denke das Du Recht hast wenn Du hier explizit für "unseren" User hier von ZFS abrätst.

GrillSgt schrieb:
Gern liefere ich auch Begründungen falls gewünscht, kann auch tagelang über Proxmox (beginnend bei 3.5) referieren und mit Fachchinesich rumwerfen.
Das finde ich prima :-)
Weil mein Proxmox-Know-How lässt sicher noch zu Wünschen übrig.
Mal sehen, wann ich wieder darauf zurück komme.

GrillSgt schrieb:
Ich vertrete hier die Auffassung des KISS-Prinzips.
Das ist meine Erfahrung aus vielen Jahren techn. Support und der mehrjährigen Erfahrung als Ausbilder.
Ja. Verstehe ich.

GrillSgt schrieb:
Für mich fing der Spaß aber erst bei 2 GB aufwärts so richtig an.
Naja. Dann ist doch alles in Butter. Rechnen wir ruhig mal großzügig:
4GB HA + 2GB Jf + 0.5 GB AdG = 6.5 GB
bleibt noch so grob 1.5 GB für System + ZFS. Klingt doch super! :D

GrillSgt schrieb:
Ja. Das geht mir sowieso auf die Nerven. Das man irgendwie kaum noch einen Fernseher kriegt ohne diesen Smart-Kram. Erstens ist es potentiell ein Security- und Privacy-Problem, um das man sich kümmern muss. Und zweitens ist das meist so vernagelt, das man damit nicht mal machen kann, was man will.

Krik schrieb:
Es läuft aber "nativ"
Im Grunde spricht ja auch nichts dagegen das so laufen zu lassen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: GrillSgt
@The_Chicken auch Unraid wird dich nicht davor bewahren, deine Ordner in den Containern korrekt zu mappen oder auf die Datei- und Ordnerberechtigungen achten zu müssen. Schau doch nochmals auf das konkrete Feedback zu deinem anderen Thread mit den Problemen.
 
  • Gefällt mir
Reaktionen: GrillSgt und alturismo
The_Chicken schrieb:
hast du da Erfahrungen ? wie happy bist du mit Unraid?
ja und sehr ... aber das war nicht meine Intension dich zu Unraid zu "treiben" ;)

wollte nur "Unwissenheit" ggf. korrigieren und Szenarien ansprechen ...
Ergänzung ()

@Sykehouse jetzt hab ich es auch gesehen dass dies "zusammen" gehört
 
GrillSgt schrieb:
In neueren Proxmox PVE Installationen ist es wohl lediglich noch 10% des verfügbaren RAMs.
Ist ja im Prinzip auch eine vernünftige Voreinstellung. Weil wer Proxmox VE benutzt, macht höchstwahrscheinlich auch Container/Virtualisierung und braucht den RAM anderswo. Und der hat vermutlich auch kein Server mit wenig RAM.
Anders sieht es natürlich aus, wenn man nur einen Fileserver haben will oder "small devices" hat. Aber in solchen Fällen wird man ja auch kein Proxmox VE einsetzen.

Aber an solchen Sachen sieht man mal, das man solche Parameter immer mit im Auge behalten muss, damit man ggf. nachjustieren kann. Solche Systeme machen ja ob ihrer schicken GUI ja manchmal so den Eindruck, als wären sie laientauglich sind. Und das gilt halt nur begrenzt.
 
Ich hatte mir Proxmox Installiert auf ganz vielen Vorschlägen bei Reddit.
Aber war für meine Zweck ein wenig zu überdimensioniert.
Hat zwar nach ein wenig rumgefriemel funktioniert, aber war mir zu viel für das wenige was ich benötige.
 
@The_Chicken na ja, letztlich kann PVE auch nicht mit CasaOS oder Umbrel verglichen werden.
PVE ist letztlich eine GUI für KVM / QEMU - einem Vollvirtualisierer ählnich Hyper-V oder VMWare. Dazu bringt es Clusterfunktionialitäten und ein verteiltes Dateisystem mit. Alles Dinge aus und für den Rechenzentrumsbetrieb. Die Zielgruppen sind insofern völlig andere.
Nichts destotrotz hat es deutlich an Bedeutung zugenommen. Im professinellen wie im Heimbereich. Als ich das Erste Mal Proxmox installiert habe, kannte es praktisch niemand - auch viele Systemhäuser nicht. Im Laufe der Jahre hat es insbesondere im Homebereich deutlich an Bedeutung gewonnen. So haben sich auch hier Freiwillige zusammengetan und Scripts entwickelt um die Zugänglichkeit durch eine vereinfachte Installation zu ermöglichen. Das hat Proxmox offenbar auch selbst erkannt und bietet seit einiger Zeit auch Lizenzen für die Communityedition an (die man kaufen kann, jedoch nicht muss).

Im professionellen Umfeld war es schon immer irgendwie omnipräsent, stand in vielen Fällen aber nicht einmal als Option im Raum, rückte jetzt aber seit kurzem mehr und mehr in den Fokus aufgrund der fragwürdigen Lizenzpolitk von Broadcom (dem heutigen Eigner von VMWare) und die dadruch z. T. explodierende Preise. Zuvor spielte Proxmox eher eine untergeordnete Rolle in diesem Umfeld, auch wenn es da seine Zielgruppe gesehen hat und es auch zuvor schon deutlich günstiger zu haben war als VMWare. Und das finde ich persönlich bemerkenswert, gibt es doch einige wichtige Features die Proxmox bis heute schlicht nicht bietet, VMWare als Marktführer aber schon seit zig Jahren hat. Auch laufen die virtuellen Gäste zwar, aber nicht immer so, wie man sich das wünschen würde (Performance, Stabilität).

Wie auch immer, ITler die VMWare ESXi kennen, werden sich in Proxmox recht schnell zurechtfinden, aber mit etwas Gewöhnung kommt man auch ohne viel Know-How zum Ziel.

Hingegen, soweit ich das sehe ist CasaOS "lediglich" ein Containerhost für Docker. Ähnliche Dinge lassen sich auch mit den gängigen NAS-Systemen von Synology, QNAP & Co. realisieren.
Umgekehrt aber, ist es auch kein Problem CasaOS als VM auf den eigenen Proxmox VE Server zu installieren und dann von beiden zu profitieren. Ganz im Gegenteil, es ist sogar gängige Praxis und Empfehlung, einen Docker Host als VM auf dem Proxmoxhobel zu installieren wenn Docker zum Einsatz kommen soll.
 
Zuletzt bearbeitet:
Ich habe auch schon einiges durch (rpi, synology nas, proxmox VMs), bin aber vor einiger Zeit komplett auf Kubernetes umgestiegen, da ich das im professionellen Umfeld viel nutze und mich neben großen Installationen (Cluster mit Terabytes an RAM und > 1000 CPU Kerne) auch mit kleineren Edge Installationen auskenne. Für die meisten ist der Absprung hier sicher zu hoch und die Komplexität nicht wert, bringt aber nochmal eine andere Perspektive rein:

Ganz Kurz: Plain Linux auf meiner Maschine (kleiner HP Server ohne besondere Konfiguration), Kubernetes Stack (In dem Fall K3s, Talos ist aber auch eine schöne Option wenn man kein WiFi braucht) drauf.

Applikationen sind per GitOps in einem Github Repo, Renovate erstellt mir automatisch einen PR wenn ein neues Docker Image da ist, d.h. ein Update bedeutet für mich nur einen Klick zum Merge des PRs. Volumes (SSDs, HDDs oder NFS) werden über Longhorn (https://longhorn.io/) abstrahiert, d.h. Backups und Replication ist mit drin. Daher kann ich mir ZFS o.ä. sparen. Bei einem Clustercrash führe ich einmal Ansible aus, nach 2 Minuten steht der Cluster wieder. Backups werden über Longhorn eingespielt, d.h. ich bin nach ca. 30 Minuten wieder einsatzfähig. So habe ich auch die Migration von meinem rpi5 Cluster gemacht, auf dem ich vorher auf genau den gleichen Stack laufen lassen habe.

1745316744166.png

1745316763846.png


Obwohl viele Container laufen ist der Cluster super sparsam:

1745316781178.png


Durch die schönen APIs in Kubernetes werden meine Container automatisch gescraped, sodass ich immer schön sehe, was im Cluster vorgeht, z.b. RAM:

1745316977194.png


Für mich so deutlich praktikabler als Proxmox, Unraid oder was es da noch so gibt. Wen es interessiert oder Hilfe braucht, gerne melden ;)

An einem Beispiel für OpenCloud kann man erahnen wie man Services deklarativ zum Laufen bringt: https://loku.be/250411-opencloud-on-kubernetes-locally-part-1
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Krik und Sykehouse
@GrillSgt Fände ich an sich spannend, die Folien sind auch chic, allerdings fehlt mir die Tonspur mit tieferen Gründen was dem Autor passiert ist. Datenbanken nicht in Kubernetes zu betreiben ist mittlerweile doch ziemlich outdated, das klappt bei uns seit einigen Jahren wunderbar. Am Ende läuft genau so ein Container, als wenn man den per "podman run" startet. Kubernetes Operatoren wie cloudnativePG für PostgreSQL sind auch einfach ein Traum mit wenig Overhead.

etcd würde ich mir auch gut überlegen on-prem, da gerne mal zickig, daher mache ich das auch nicht, sondern nehme K3s mit ner sqlite. Ins Knie kann man sich trotzdem an vielen Ecken schießen, aber das geht auch mit VMs und plain docker.

Wie gesagt: Eher nicht ohne weitergehende Erfahrungen, vielleicht aber mal mit einer 2ten Maschine um das mal auszuprobieren.

Eine Story dazu die ich immer wieder cool finde: 7000 on-prem Kubernetes Cluster in REWE Märkten https://www.linkedin.com/posts/dev-...groupvoices-activity-7274783032652312576-MPYC
 
Zuletzt bearbeitet:
rStorms schrieb:
Datenbanken nicht in Kubernetes zu betreiben ist mittlerweile doch ziemlich outdated,
Ich würde sagen, ob outdated oder nicht ist überhaupt nicht relevant, sondern obs gut funktioniert.
 
@rStorms, warum ich das erwähnt habe ist, es sicherlich ein gutes Werkzeug ist wenn ausreichend Know-How - wie in deinem Fall - vorhanden. Aber viele (vielleicht die Allermeisten) - da schließe ich mich nach gut 20 Jahren Berufserfahrung auch mit ein - haben vermutlich nicht ausreichend Know-How um Kubernetes vernünftig zu verstehen und erst nicht zu betreiben. Das gebe ich auch unumwunden zu. Aber, ich habe es bisher auch nicht gebraucht.

Was mir auch nicht gefällt - aber das ist eher was persönliches - der ganze Hype um Kubernetes in den letzten Jahren. Sowas lässt zumindest bei mir immer eine gewisse Grundskepsis aufkommen, denn alles hat irgendwo immer seine Schattenseiten.
Es wird / wurde als Allheilmittel gesehen bzw. dargestellt was es in meinen Augen nicht ist. Es fängt ja schon damit an, dass oft nicht ganz klar ist was Kubernetes denn eigentlich ist und was nicht.
Zum Anderen - was man so liest - war zumindest in der Vergangenheit auch die Qualität der Releases wohl nicht immer so das Gelbe vom Ei was Updates zum russisch Roulette gemacht hat. Von der Konfiguration die nicht ganz einfach zu durchlbicken ist mal abgesehen.

Damit wären wir dann auch wieder beim bereits angesprochenen Know-How, funktioniert sicherlich zuverlässig und sicher wenn der Admin weiß was er zu tun hat, aber das muss auch erstmal hinkommen. Einen Kubernetes Cluster irgendwie so hinzuzimmern, dass er läuft ist ja immer das Eine, aber so dass es auch so bleibt und vernünftig sowie sicher ist das andere. Und da würde ich sagen, brauch es schon ITler die sich darauf spezialisiert haben.

So oder so, scheinbar hat der Hype um Kubernetes aber auch (vielleicht wegen der genannten Punkte) etwas abgenommen. Zumindest liest man nicht mehr ständig davon, dass Kubernetes als Synonym für die Zahl 42 gesehen wird. Und hier scheint genau der Hase im Pfeffer zu liegen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: andy_m4
GrillSgt schrieb:
Was mir auch nicht gefällt - aber das ist eher was persönliches - der ganze Hype um Kubernetes in den letzten Jahren. Sowas lässt zumindest bei mir immer eine gewisse Grundskepsis aufkommen, denn alles hat irgendwo immer seine Schattenseiten.
Vor allem, weil alles immer auch Nachteile hat. Und ja. Es ist insbesondere dann problematisch, wenn das reden über (auch teilweise angeblichen) Vorteile ein deutliches Übergewicht hat. Das ist immer eine Red Flag.
Letztlich kochen alle nur mit Wasser.

Und insbesondere wenn jemand anfängt mit "andere Lösungen sind outdated" zu argumentieren, ist das ein ganz schlechtes Zeichen. Denn Lösungen sollten sich danach richten, ob sie geeignet sind und nicht, ob sie modern oder unmodern ist.

GrillSgt schrieb:
Damit wären wir dann auch wieder beim bereits angesprochenen Know-How, funktioniert sicherlich zuverlässig und sicher wenn der Admin weiß was er zu tun hat, aber das muss auch erstmal hinkommen.
Es wird vor allem dann problematisch, wenn man gar nicht mehr versteht, was unten drunter passiert. Wenn dann dort mal ein Problem auftritt und die ganzen Hochglanz-Interfaces plötzlich nicht mehr funktionieren, dann stehen die Admins plötzlich dumm da.
 
  • Gefällt mir
Reaktionen: GrillSgt
@GrillSgt: Ja, stimme dir total zu, das muss man sich gut überlegen. Es gibt nichts in der IT was für jeden Use-Case passt, selbst die beste Lösung hat Trade-Offs und es gilt zu schauen, was aktuell und für die zukünftige Entwicklung für einen Anwendungsfall die richtigste Lösung ist.

Kubernetes hat auf der einen Seite viel Hype hervorgerufen, was auf der anderen Seite auch Abwehrreaktionen und oft zu negativen Diskussionen geführt hat. Am Ende liegt es glaube ich auch viel daran, dass Kubernetes oft für den falschen Anwendungsfall benutzt wurde, oder die Komplexität unterschätzt wurde, was dann zu vermeidbaren Problemen führt. Oft reicht halt auch eine VM wo dann 3 Container darauf laufen. Die Vorteile von Kubernetes machen dann die Komplexität sicher nicht wett, ich würde dann auch stark davon abraten.

Ein Homelab/Homeserver ist für mich genau eine Grauzone. Irgendwann kommt man mit Docker an einen Punkt, wo irgendwann zuviele Container laufen. Wie deploye ich die idealerweise immer gleich? Wie heile ich Container wenn sie kaputt gehen? Wie update ich? Wie mache ich die Container erreichbar, idealerweise mit Service Discovery und vielleicht noch einer externen Domain? Sowas geht aus meiner Sicht in Kubernetes einfacher, als wenn ich alles zu Fuß in Docker und VMs mache, denn Kubernetes bietet einfach viele Tools, die mir helfen (https://landscape.cncf.io/). Und ja, auch die gehören sorgfältig ausgewählt und müssen beherrscht werden und bieten die Gefahr auszuufern. Das ist dann aber eine bewusste Entscheidung. Beispiel: Ein https://cert-manager.io/ besorgt mir mit kleinster Konfiguration für meine Domain automatisch SSL Zertifikate, für jeden Container der eine subdomain anfragt. Die Services sind nicht von außen erreichbar, cert-manager klärt das mit der cloudflare/hetzner API für mich. Das skaliert einfach super und spart mir viel Arbeit.

So etwas beobachte ich auch oft im professionellen Umfeld. Es wird mit Docker angefangen, irgendwann wird es komplexer und es entstehen Scripte oder anderweitige Logiken, die die Komplexität beherrschen sollen. Leute fangen an Kubernetes nachzubauen. Hier ist man aus meiner dann auf jeden Fall falsch unterwegs, denn auch das ist nachzuhalten.

caseOS hat bestimmt seinen Anwendungsfall für private Nutzer, aber auch hier wird ein UI gebaut, was dann für mich Services deployed, nachhält und auch irgendwo den state der deployten Applikationen speichern. Für viele User der bessere Weg, definitiv. Für mich nicht. Bei Kubernetes habe ich mehr Freiheiten und ehrlicherweise auch mehr Vertrauen.

Wie in meinem Beitrag geschrieben, soll das nur ein Anstoß sein für eine weitere Art wie man seine Services betreiben kann der definitiv nicht für jeden passt :)

------

@andy_m4: Dein Beitrag kam nachdem ich abgeschickt hatte.

Ich würde dich doch bitten meinen Beitrag nicht 2-mal aus dem Kontext zu reißen. Ich schreibe:

Datenbanken nicht in Kubernetes zu betreiben ist mittlerweile doch ziemlich outdated, das klappt bei uns seit einigen Jahren wunderbar.

Daraus zitierst du nur den ersten Teil
rStorms schrieb:
Datenbanken nicht in Kubernetes zu betreiben ist mittlerweile doch ziemlich outdated,
und sagst

"Ich würde sagen, ob outdated oder nicht ist überhaupt nicht relevant, sondern obs gut funktioniert."

obwohl ich schreibe "das klappt bei uns seit einigen Jahren wunderbar.". Damit meine ich große Datenbanken wie Cockroach, PostgreSQL, Milvus, MongoDB, Clickhouse, ...

Dann finde ich nicht wirklich wo ich sage, dass andere Lösungen outdated sind: "Und insbesondere wenn jemand anfängt mit "andere Lösungen sind outdated" zu argumentieren"?

Liest du das aus meinem Kommentar raus? Ich beziehe mich da doch nur auf die Meinung, dass Datenbanken nicht in Kubernetes betrieben werden sollten?
 
Zuletzt bearbeitet:
rStorms schrieb:
Datenbanken nicht in Kubernetes zu betreiben ist mittlerweile doch ziemlich outdated, das klappt bei uns seit einigen Jahren wunderbar.
Dann solltest Du den Satz vielleicht mal eindeutiger formulieren. Worauf bezieht sich denn dann der zweite Abschnitt? Ich finde das missverständlich und auch durch deine jetzigen Erklärungen, wo Du zwar viel redest aber nicht wirklich eindeutig was sagst, wirds nicht besser.

rStorms schrieb:
Irgendwann kommt man mit Docker an einen Punkt, wo irgendwann zuviele Container laufen.
Interessant, das für Dich Container automatisch Docker zu bedeuten scheinen.
 
andy_m4 schrieb:
Dann solltest Du den Satz vielleicht mal eindeutiger formulieren. Worauf bezieht sich denn dann der zweite Abschnitt? Ich finde das missverständlich und auch durch deine jetzigen Erklärungen, wo Du zwar viel redest aber nicht wirklich eindeutig was sagst, wirds nicht besser.

Ich beziehe mich auf den von @GrillSgt verlinkten Vortrag in dem genau das Thema war. Hier noch einmal für dich https://www.heinlein-support.de/sla...inem-premise-kubernetes-ins-knie-zu-schiessen
andy_m4 schrieb:
Interessant, das für Dich Container automatisch Docker zu bedeuten scheinen.
Auch hier wieder: Bitte nicht etwas in den Mund legen. Nett wäre doch, wenn du stattdessen eine Rückfrage stellst an mich, dann kann man auch nett und gerne auch kontrovers wie z.b. mit @GrillSgt darüber diskutieren.

Ich denke das ufert hier ein wenig aus, ich lasse meinen Beitrag hier als Anstoß unter der Prämisse, wie im ersten Beitrag geschrieben "Für die meisten ist der Absprung hier sicher zu hoch und die Komplexität nicht wert, bringt aber nochmal eine andere Perspektive rein:". Viel Spaß damit für die die es interessiert und offen und reflektiert damit umgehen wollen.
 
rStorms schrieb:
Ich beziehe mich auf den von
Stell es doch einfach kurz und knapp klar. Was Du hier an unnützen Boilerplate-Text ablässt, das hättest doch mal locker durch 3-4 klare Worte ersetzen können.

rStorms schrieb:
Auch hier wieder: Bitte nicht etwas in den Mund legen.
Du solltest vielleicht mal Deine Worte geschickter wählen, dann gibts auch nicht so ein hohes Missverständnispotential. Auch hier wieder: Ein paar Worte um Dinge klar zu stellen und alles wäre gut. Stattdessen Rumgeheule, das man sich ungerecht behandelt fühlt.
Aber ja. Die Schuld auf andere zu schieben ist freilich leichter, als auf sich selbst zu gucken.
 
Zuletzt bearbeitet:
Zurück
Oben