[Sammelthread] Proxmox Stammtisch

[SlapAHo]

Ah, cool danke. Teste ich heute abend gleich aus

 

[FieserOstfriese]

Mein Problem weiter oben beschrieben hatte. Es war Lapidar ein Speicherriegel wohl defekt. Im Bios des HP ProDesk 400 G5 SFF stand auch, hatte ich nie gesehen bei einem der Riegel: Memory Size error..

 

[BobbyD]

Ist es üblich, dass LXC weniger RAM fressen als Docker Container. Ich habe gerade AdGuard Home als community-scripts-LXC aufgesetzt und die Einstellungen abgeglichen. Noch beträgt der RAM-Verbrauch nur ein Drittel zu Docker. Wäre für mich ein Grund, noch stärker auf LXC zu setzen, wobei ich mir als Noob dann die vergrößerte Abhängigkeit zu den community-scripts eintreten würde.

 

[Supaman]

Ein LXC verwendet das HostOS (z.B. Debian vom PVE) als Basis, d.h. der Ressourcenverbrauch fällt nur für die Applikation an. Eine eigene VM mit Docker hat halt immer das Basis Alpine/Debian/Ubuntu, und dann kommt die App on Top. Nachteile von LXCs: der CT kann nicht live Migriert werden, weniger sicher, nur manuelle Aktualisierung der App und ggf. "Nebenwirkungen" wenn das HostOS aktualisiert wird.

Meine ganz persönliche Meinung: ich nehme LXC nur zu testen, um per Proxmox Helper Script eine schnelle Live Demo zum rumspielen zu haben. Für den Echtbetrieb nehme ich immer eine Debian VM, ggf mit Docker. Die läuft dann stabil, kann beliebig zwischen Knoten verschoeben werden. und zickt nicht rum wenn ich den PVE aktualisiere. Der etwas mehr Overhead für ein nacktes Debian ist marginal, da auch potente, stromsparende Hardware mit genug Ram preiswert zu haben ist.

 

[MisterY]

Ist es üblich, dass LXC weniger RAM fressen als Docker Container. Ich habe gerade AdGuard Home als community-scripts-LXC aufgesetzt und die Einstellungen abgeglichen. Noch beträgt der RAM-Verbrauch nur ein Drittel zu Docker. Wäre für mich ein Grund, noch stärker auf LXC zu setzen, wobei ich mir als Noob dann die vergrößerte Abhängigkeit zu den community-scripts eintreten würde.

Anhang anzeigen 1117591

Ja, Docker ist so ein aufgeblähter Kram, der Ressourcen ohne Ende frisst. Werde da aber jedes mal gedownvoted für.

 

[Spliffsta]

Also ich bin derzeit am Aufbau eines neuen Servers. Bisher so:

PVE
      --truenas (mit 3x18tb RaidZ1)
                                   -- SMB Shares
                                   -- Nextcloud
                                   -- ARR Stack
      --UmbrelOS als BTC Lignting Node
      --Home Assistant VM
      --Home Assistant VM
      --NGINX LXC
      --CasaOS LXC
      --Vaultwarden LXC   
      --Wireguard LXC     
      --Debian LXC für Docker testerei

Nun überlege ich Truenas weg zu lassen. Arr Stack geht ja auch super als LXC, Nextcloud und SMB shares ja auch. RaidZ mit nappIT sollte ja dann auch alles funkionieren?

 

[Supaman]

Viele Wege führen nach Rom bzw. zum Ziel, und das gleiche gilt für die persönliche Meinung, was denn nun der geeiegnete Weg ist.

Ich trenne Dinge immer gerne, d.h. wenn ich eine Fileserver Instanz haben will, dann nehme ich z.B. ein TrueNAS und beschränke das auf die Kernfunktionalität und mache da keinen Gemischtwaren Laden draus. so Sachen wie NextCloud oder ARR haben da als nested Service nichts verloren. Für Instanzen mit großen Datenmengen wie z.B: TrueNAS undProxmox Backup reiche ich die Platten als Raw Device an die VM durch, oder auch den ganzen Controller. Dann habe ich keinen unnötigen Layer von Proxmox Host dazwischen und könnte auch jederzeit TrueNAS/PBS etc BareMetal installieren und brauche nur die Platten umklemmen und fertig.

Von LXC bin ich für den Echtbetrieb auch kein Freund, maximal zum schnellen testen. Die Ressourceneinsparung von LXC ist marginal, aber man hat etliche Nachteile: keine bequemen (Auto) Updates wie bei Docker Containern, keine Live Migration, und wenn das HostOS aktualisiert wird, *kann* es Probleme geben bzw manuelle Anpassungen / Aktualisierungen erforderlich machen. Eine Standalone VM ist von HostOS Aktualisierungen unabhängig.

Wenn man den Ressourcen Verbrauch LCX <> VM mal gegenüberstellt, sind die Einsparungen marginal: ein Debian inkl. Docker und Portainer benötigt grade mal 1.5 GB Ram und 3 GB Disk Space, CPU Last für das Basis Debian ist hart gegen Null. Da müsste man schon seeehr viele LXCs laufen haben, um auf eine signifikante Menge an gesparten Ressourcen zu kommen, zumal man auch viele kleine Dienste wie Vaultwarden, Reverse Proxy, Wireguard etc auf eine VM packen kann. Zu Zeiten von RaspberryPI mag das noch irgendwie Sinn gemacht haben, aber inzwischen sind potente MiniServer für kleines Geld zu haben, so das für LXC keine notwenddigkeit besteht.

 

[Spliffsta]

Die Server Hardware ist eigentlich extrem überdimensioniert.
5600x
Mc12 le0
96gb ecc

Also gut dann versuche ich es folgendermaßen:
Pve
- truenas mit durchgereichtem Controller
- Debian für docker und portainer für die arr Stacks
- Debian für docker und portainer für die lxc Packs plus nextcloud
- umbrel OS

Oder macht es keinen Sinn den arr Stack von dem "produktiven" Stack zu trennen?
Nextcloud in truenas einbinden ist halt super einfach weil man da nicht irgendwie Laufwerke mounten muss oder was aich immer. Aber ich denke das sollte auch machbar sein?
Oder ganz auf truenas verzichten? Im Endeffekt brauche ich nur ein paar smb shares für die arr Stacks und natürlich als Netzwerkspeicher und nen NFS shares für nextcloud. Kriegt Pve ja selbst hin? Nur hätte ich dann bedenken dass bei einem Kernelupdate oder was auch immer von Pve mir alles zerschiesst

 

[KurantRubys]

Warum Portainer? Ich hab damit auch angefangen, aber wirklich Vorteile hat mir das auch nie gebracht. Bau jetzt alles in der neuen VM auf Compose um, Portainer kommt da nicht mehr drauf. Host-OS ist Rocky Linux, dann bin ich auch endlich apt los.

Bleibt aber ein Docker-Host für alles, jeder Dienst bzw. Stack bekommt sein Compose File und gut. Die ARR-Apps liegen so in einem Compose, andere Apps in nem anderen eigenen Compose.

 

[Supaman]

Oder ganz auf truenas verzichten? Im Endeffekt brauche ich nur ein paar smb shares für die arr Stacks und natürlich als Netzwerkspeicher und nen NFS shares für nextcloud. Kriegt Pve ja selbst hin? Nur hätte ich dann bedenken dass bei einem Kernelupdate oder was auch immer von Pve mir alles zerschiesst

Eine dedizierte TrueNAS VM ist Fire and Forget. Die läuft, die musst Du nicht aktualisieren, und wenn Du den PVE umziehen oder neu installieren möchtest, machst Du per SMB oder PBS ein Backup von der VM, spielst die zuück, rechst den Controller oder die Platten durch und bist wieder online. Und musst keine Angst haben, das irgendein Update dir da reingräscht.

Ob auf einer Docker Instanz nun noch ein Portainer mit drauf ist oder nicht, ist für den Betrieb völlig egal, PT zieht keine nennenswerten Ressourcen, braucht keine aufwändige konfig etc. Aber es ist super praktisch wenn man über eine GUI einen Überblick haben möchte, in Logfiles reinschauen etc. Das eine schliesst das andere ja nicht aus - Container per Docker Compose Scripts verwalten, und per GUI monitoren. Ja, geht auch alles über die Shell etc, ist aber aufwändiger und erfordert ggf. mehr Kenntnisse.

Instanzen die größere Datenmengen verarbeiten bzw vorhalten, wie NextCloud, OpenCloud, Paperless etc spediere ich immer eine eigene VM, und dann auch die Daten auf einer separaten Disk (=2tes gemountetes Laufwerk), entweder als virtruelle Disk oder bei großen Datenmengen die SDD/HDD per RawDevice durchreichen. Dann kann man auch problemlos den Datenträger vergrößern oder umkopieren.

Derartige Setups - also die Trennung von OS und Daten - machen das sehr flexibel und besser handhabbar, wenn man mal ein OS neu installieren oder umziehen muss.

Das ist nur meine Sichtweise auf die Dinge... das kann, darf und soll jeder machen wie er mag.

 

[gea]

Die Trennung von OS und ZFS Datenpools halte ich für essentiell, sollte man nie anders machen. Ob man jetzt für einfache NFS und SMB Shares gleich ein komplettes Debian ontop Debian vollvirtualisieren muss, ist eine andere Frage.

Für mich sind NFS und SMB Datenshares, die jedes OS selber anbietet. Ich sehe die als optionale "always on" Basisfunktionen, genau wie ssh das man ja auch regelmäßig aktiviert um Daten zu übertragen oder eine remote shell zu haben.

Eine S3 oder Nextcloud ist da was anderes wobei ich das wegen der Komplexität und Sicherheitsanfälligkeit meide wo es geht, Wireguard + SMB ist meine "Cloud" für unterwegs.

 

[Spliffsta]

Ok vielen Dank euch allen schon mal.
Ich denke ich werde dann das ganze so machen:

Pve
- truenas vm (durxhgereichten Controller, erstellt zfs raid, smd und NFS shares)
- nextcloud und wireguard etc vm
- vm für arr Stack
- umbrel OS
Also so wie oben. Docker compose verstehe ich nicht wirklich. Bin totaler Linux noob und programmiereren kann ich eigentlich nur mit einer Youtube Vorlage

 

[BobbyD]

ein Debian inkl. Docker und Portainer benötigt grade mal 1.5 GB Ram

Genau, 1,5 GB RAM, die ich mir sparen kann. Auch betreibe ich @home keinen Cluster. Auch bei der CPU-Last sehe ich große Unterschiede, hab das aber nicht genauer untersucht und es mag an einer unterschiedlichen Darstellung liegen. Bei der RAM-Auslastung ist es aber recht eindeutig.

Was die Aktualisierungen von LXC angeht, bin ich sehr unbeleckt. Für Proxmox gibt es ein community-script, welches LXC per Cronjob selbständig aktualisiert. Auch der Docker-LXC von dort, der als "Not updatable" bezeichnet wird, aktualisiert mir mit einem "apt upgrade" Docker. Also noch kann ich das Problem nicht recht erkennen. Wäre aber für eine erst gemeinte Aufklärung in dieser Sache dankbar.

Und was den RAM angeht, ich hab zwar fast 100 GB im Server, aber nutze ihn gerne zum Write-Caching von temporären Daten, kann davon nie genug haben. Und auch die Effizienz der CPU-Last hab ich immer im Blick, nötig oder nicht.

@MisterY Nach über 24 Stunden ist die RAM-Auslastung des AdGuard LXC leicht gestiegen. Werde das weiter beobachten, ob das vergleichbar zum Docker ist. Dort hatte sich der RAM-Verbrauch mit der Zeit immer weiter ausgedehnt und das erheblich...

@Spliffsta Schau dir auch mal Dockge an. Finde, das eignet sich gut, nebenher etwas über Compose zu lernen und ist recht übersichtlich. Aber zumindest initial musst Du auch das irgendwie starten, entweder über Docker Run oder eben Compose, beides kein Hexenwerk.

 

[FieserOstfriese]

ich hatte mal kurze Zeit Runtipi ausprobiert. Aber bin wieder zurück zu Docker und Portainer, weniger Ressourcenhungrig. Hat jemand nen Idee für ein Tool um fixer die Docker Container upzudaten?

 

[KurantRubys]

Der Klassiker dürfte ja Watchtower sein, das steht bei mir auch noch auf der Todo. Weniger Spezialtools, mehr best practice Dockge sieht aber auch ganz nett aus, find ich auch gut das die gleich auf compose setzten und da nicht groß dran rumbasteln.

 

[BobbyD]

um fixer die Docker Container upzudaten

Ich nutze WUD dafür, aber ob das nun fixer ist... Hab es auch nur zur Benachrichtigung eingerichtet, Updates mache ich dann mit Dockge. Wobei die Benachrichtigung an Gotify geht. Also ganz simpel ist das alles nicht für einen Laien (wie mich). Will aber eh wieder größtenteils weg von Docker.

 

[Supaman]

Docker compose verstehe ich nicht wirklich. Bin totaler Linux noob und programmiereren kann ich eigentlich nur mit einer Youtube Vorlage

Einfach gesagt: Docker Compose ist die Docker Container erstellung per Script bzw Parameter Datei. Großer Vorteil gegenüber manueller Erstellung: man kann das Script so lange bearbeiten und den CT erzeugen, bis er das macht was er soll. Dabei ist es egal, ob man nun Bash Scripte auf der Shell verwendet, oder die STACKS Funktion in Portainer - ist das gleiche in grün, aber grade für Einsteiger benutzer freundlicher.

 

[Weltherrscher]

Der Klassiker dürfte ja Watchtower sein, das steht bei mir auch noch auf der Todo. Weniger Spezialtools, mehr best practice Dockge sieht aber auch ganz nett aus, find ich auch gut das die gleich auf compose setzten und da nicht groß dran rumbasteln.

Wobei du bei Watchtower Obacht mit Breaking Changes geben musst, das zieht per default halt stur die neuesten Images und kümmert sich einen Dreck um sowas...
*hust* Immich *hust*
Das hat mir vor kurzem die Postgre-DB von Immich zerschossen...

 

[Spliffsta]

Macht es Sinn 2 pools über truenas zu erstellen? Und zwar hätte ich aktuell ja noch 2 neue 2tb wd Red ssd im mirror. Darauf dann nextcloud.
Das Raidz1 mit 3x 18tb dann nur für arr Stacks und nen Backup der nextcloud.
Pve auf der 500gb crucial und auf der 4tb nvme tlc dann alles andere

 

[Supaman]

Für Mindermengen an Daten sind HDDs Stromverschwendung und HDDs haben auch eine höhere Ausfallrate. Hau die lieber weg und n ehme SSDs.

In Bezug auf Mirror und Backup kannst Du überlegen, ob Du wirklich einen Mirror wegen Ausfallsicherheit brauchst, oder ob Dir das hoffentlich vorhandene Backup reicht.

 

[FieserOstfriese]

Für Mindermengen an Daten sind HDDs Stromverschwendung und HDDs haben auch eine höhere Ausfallrate. Hau die lieber weg und n ehme SSDs.

In Bezug auf Mirror und Backup kannst Du überlegen, ob Du wirklich einen Mirror wegen Ausfallsicherheit brauchst, oder ob Dir das hoffentlich vorhandene Backup reicht.

HDDs höhere Ausfallrate? Nie im Leben..

 

[Supaman]

Meine persönliche Erfahrung mit Datenträger Ausfällen ist bei SDDs ist bisher hart gegen Null, bei HDDs im mittleren zweistelligen Bereich.

 

[worldoak]

Wenn man im RZ arbeitet könnte die persönliche Erfahrung natürlich geprägt sein durch Ausfälle bei HDDs... In der Anfangszeit bei SSDs hatte ich heftigere Ausfälle!!!
Wenn ich zurückdenke, so hatte bisher ~1 HDD Ausfall pro 2 Jahre.

 

[Spliffsta]

Fujitsu 9211-8i 6Gbps HBA LSI FW:P20 IT Mode ZFS FreeNAS unRAID+2* SFF-8087 SATA | eBay.de

2.5 IDE hard drive. 3.5 IDE hard drive. 2.5 SATA hard drive. 3.5 SATA hard drive. Server hard drive. Seagate Server hard drive. HP 2.5 server hard drive. IBM 2.5 server hard drive.

ebay.us

Der sollte ja mit truenas funktionieren? It Mode sogar schon drauf?