Sinvolle Einrichtung Homeserver

[sb-jw]

Deshalb baue ich mir gerade einen "Server" auf J5040 Basis der wenig Strom verberbraucht.

Auf was genau kommt es dir an und wie viel Strom ist für dich zu viel? Ich würde hier eher zu einer Xeon-D raten, das Board kostet zwar ~500 EUR dafür hast du eine gute CPU mit ECC Support und ggf. IPMI (wenn z.B. X10SDV von Supermicro), dazu gibt es je nach Ausstattung einen HBA mit 4 Ports und auch 10GbE SFP+. Das Board bietet also für seinen Preis auch eine gewisse Zukunftssicherheit.

Ich persönlich würde von der J5040 Abstand nehmen, für mich ist das Minimum an einen Heimserver / NAS, dass es ECC unterstützt. Meine Daten sind mir in einer Art und Weise dann doch so wichtig, dass ich das Feature nicht missen möchte.

iSCSI braucht richtig Leistung.

iSCSI als auch NFS und SMB (aber auch andere Protokolle) brauchen perse keine extreme Leistung. Selbst meine alte QNAP TS-212 konnte ein iSCSI Volume bereitstellen mit 256MB RAM und einer Marvell CPU mit einem Kern und 1,2GHz Leistung. Das was hier in Kombination mit FreeNAS den RAM braucht ist definitiv daher auch nicht iSCSI sondern ZFS selbst, aber auch nur, wenn man hier entsprechende Feature wie Dedup verwenden will, anderenfalls braucht auch FreeNAS mit ZFS nicht exorbitant viel RAM.

(außer man hat genug Geld für Ceph )

CEPH kann man mit einem einzigen Server betreiben, gar kein Problem. Man passt nur die Crush Rule an, dass die Verteilung der Replica nicht auf Host sondern OSD ebene stattfindet und schon geht alles in einer Node. Ist nicht mal ein großartiges Hexenwerk, geht recht einfach. Ähnliches geht hier btw. auch mit Erasure Coding. Auch ein Reboot oder ähnliches macht das CEPH nicht kaputt, was bei einem CEPH eh nur dann möglich ist, wenn man den Server abfackelt oder sprengt, ansonsten ist ein CEPH unglaublich robust. Selbst der Verlust der Mons bedeutet keinesfalls den kompletten Datenverlust.
Es geht auch übrigens ohne weiteres mit 1GbE LAN, also keine Notwendigkeit für 10GbE oder sonst irgendwas. Was man haben sollte ist ca. 0,5 - 1 Kerne je OSD (oder Festplatte) und bisschen RAM, aktuell mit Bluestore ist das target bei 4GB RAM pro OSD (Achtung, ist ein Ziel, kann auch übertroffen werden und ist keinesfalls ein Limit!) und einen HBA würde ich empfehlen. Der Rest ist ziemlich egal, die Performance ist absolut okay und liegt im Rahmen. Generell ist ein CEPH eh kein Performancewundern sondern sorgt für Integrität der Daten und legt mehr Wert auf die Datensicherheit als auf Performance.

Ich arbeite nun schon rund 6 Jahre mit CEPH und habe da schon viel Mist mit erlebt, aber noch keinen einzigen Datenverlust, nicht mal im Ansatz. Ganz im Gegenteil zu einem normalen RAID, da habe ich schon den kompletten Datenverlust erlebt, weil der Controller das RAID 5 einfach komplett mit Datenmüll kaputt geschrieben hat - das hatte eine Firma anschließend auch in die Insolvenz gebracht.

Generell gilt aber dennoch immer, dass man sich dessen Bewusstsein muss, was man tut - dann kann man auch alles betreiben, auch fernab der Empfehlungen der Hersteller / Entwickler.

- Müssen LXC Container auch upgadeted werden? Oder nur das Host System in dem Fall Proxmox?

Lediglich der Kernel wird von PVE gestellt, die Container selbst musst du auch mit apt update etc. aktuell halten.

- Müssen Docker Container auch upgadeted werden?

Das hängt immer davo ab, was du nutzt. Häufiger ist es ja eher so, dass du ein persistent Datavolume hast und einfach die neue Version ziehst und wieder startest. Also quasi weg schmeißen und neu laden ist hier das Konzept. Die Updates / Bugfixes etc. kommen dann oftmals vom Entwickler direkt mit.

- Gibt es Unterschiede bei der Sicherheit unterschiedlicher Linux Distris?

Grundsätzlich ist jedes Betriebssystem, egal ob Windows oder Linux, gleich sicher bzw. unsicher. Eine Absicherung der verschiedenen Systeme sollte man immer auf seine Bedürfnisse vornehmen. Die Bordmittel sind in der Regel bei Linux immer die gleichen, eben SSH Config oder IPTables etc.

- Gibt es Linux die sich automatisch updaten?

Man kann unattended Updates konfigurieren, ist halt immer die Frage ob man das möchte oder nicht. Aber ein Upgrade von z.B. Debian 10 auf Debian 11 müsste man weiterhin manuell vornehmen.

- Macht Zabbix oder Graylog auch für ein paar VMs/Container Sinn?

Meiner Meinung nach wäre ein Checkmk dem Zabbix vorzuziehen, ich habe den Eindruck, dass Checkmk verbreiteter ist. Generell ist aber Zabbix als auch Checkmk ein Monitoring und Performance Monitoring, ob du es also benötigst oder nicht, das musst du selbst wissen - tatsächlich betreibe ich eine Checkmk Instanz in meinem Netzwerk um hier einfach die verschiedenen Geräte und VMs zu überwachen bzw. die Metriken zu haben, wenn ich etwas nachsehen möchte.
Auch ein Graphite mit InfluxDB und Collectd habe ich am laufen um z.B. meine Fritz Smarthome Devices auszuwerten und die Fritz!Box natürlich selbst auch. Ein Graylog ist für zentrales Logging gedacht, macht durchaus Sinn und erleichtert einem die Arbeit - aber man sollte auch die Logs auf den VMs etc. dann selbst deaktivieren und alles nur nach Graylog pushen lassen, anderenfalls erzeugt man einfach nur unnötige und zusätzliche I/O Last - Nachteil ist, wenn deine Graylog VM nicht mehr funktioniert und du lokal keine Logs mehr hast, wird das debuggen schwierig.

 

[beta]

Sooo viel Input.
Danke für die Antworten.
Bei der Hardware wird es wohl erstmal bleiben.
Das ist ein neuer Quadcore Pentium J5040 Processor 10Watt TDP, wie er wahrscheinlich erst in künftigen NAS einsatz findet.
Theoretisch etwas schneller als ein Synology DS720+.
Da ist jetzt nicht viel Platz nach Oben, aber ich brauche auch nicht viele Server/Anwendungen und das im Normalfall auch nicht gleichzeitig,
weil max. 2 Personen darauf zugreifen.
Ob mir das reicht wird sich dann wahrscheinlich nächste Woche zeigen.

Bei der Sicherheit ging es mir eher um Sicherheitspatches, wenn es das wie unter Windows geben sollte.
Wäre halt toll, wenn sowas automatisch eigespielt werden könnte.
Ich möchte mir halt möglichst um wenig Gedanken machen, deshalb überlege ich die Beste Herangehensweise für Container/Server.

Wenn ich jetzt jeden Server ... sagen wir mal Serviio, Emby, Pi-Hole, in jeweils eigene LXC Conateiner packen würde, müsste ich wohl
jeden LXC Container Updaten/aktuell halten.
Wenn das automatisch gehen würde, wäre das ja OK.

Wenn nicht wären die Server als Docker Version dann nicht besser?
Ich könnte dann ja Docker im LXC laufen lassen und mich nur um eine LXC Container kümmern?

LG

 

[CoolTux]

Ich habe 20 LX Container. Die Konfiguration jedes Containers verwalte ich Zentral mt Puppet. Ausserdem ist auf jedem unattended-upgrades eingerichtet. Hier kann man sagen was in welchen Umfang upgedatet werden darf. Ich habe hier bei mir alles ausser auf neue Distributionsversion.
Desweiteren habe ich Check_Mk am laufen um informiert zu werden sollte ein Service ausfallen.

 

[Dunuin]

- Müssen LXC Container auch upgadeted werden? Oder nur das Host System in dem Fall Proxmox?

Ja und am besten manuell und regelmäßig.

- Müssen Docker Container auch upgadeted werden?

Ja. Wobei du Docker-Container ja aktualisierst, indem du die quasi zerstörst, die neue Version runterlädst und neu "installierst". Sollte man aber auch regelmäßig machen, sobald da der Docker-Container-Ebtwickler eine neue Version bereitstellt.

- Gibt es Unterschiede bei der Sicherheit unterschiedlicher Linux Distris?

Ja. Mache Distros updaten nur selten, dafür sind die Updates dann aber gut auf Stabilität durchgetestet. Manche updaten oft die Packages, da hat man dann zwar schneller die Sicherheitslücken gefixt, aber alles ist auch nicht so gut getestet und man ist anfälliger für neue Bugs.
Und dann gibt es noch so Dinge wie z.B. SELinux.

- Gibt es Linux die sich automatisch updaten?

Man kann automaitsche Updates quasi bei jedem Linux einrichten, ist aber nicht empfehlenswert:
1.) Es wird alles ohne User-Feedback entschieden. Oft würdest du bei der Installation von Updates gefragt werden, ob du z.B. deine alten Konfig-Dateien behalten willst oder die neuen aktualisierten Blanko-Versionen nehmen willst oder ob du nur die Unterschiede sehen willst, um dir dann manuell aus beiden Konfig-Dateien eine gemeinsame neue Konfig-Datei erstellen willst. All solche Sachen würden einfach komplett an dir vorbei gehen und es würde alles für dich automatisch über Standard-Werte entschieden werden, auch wenn dir dieses das ganze System zerschießen könnte.
2.) Man sollte immer vor einem Update lesen, ob die neuen Versionen von Programmen auch untereinander kompatibel sind. Wenn ich bei meiner Graylog-VM z.B. die MongoDB oder ElasticSearchDB auf die neuste Version aktualisieren würde, dann würde Graylog nicht mehr laufen, da dieses sehr pingelig ist und nur alte Versionen unterstützt.
3.) Oft benötigt ein Update noch manuellen Eingriff. Gerade bei Datenbanken musst du oft noch bestimmte Befehle eintippen, welche Stunden dauern können und daher nicht selbst gemacht werden oder bei Falschbedienung dir alle Daten zerstören könnten. Da sollte man eigentlich immer vor jedem Update (zu mindestens vor jedem Feature-Update) immer die Changelogs/Dokumentationen lesen um zu gucken, was der Entwickler genau rät. wie genau man ein Update durchführen sollte.
4.) Beim Update kann immer etwas schief gehen. Wenn man es manuell macht, sollte man vorher immer Backups/Snapshots anlegen, damit alles wieder umkehrbar ist. Und nach dem Update sollte man einmal wirklich alle VMs/LXCs auf Funktionalität durchtesten, ob wirklich noch alles geht, da oft neue Bugs entstehen oder halt Programme untereinander plötzlich inkompatibel werden.

Also am besten du machst die Updates immer alle manuell. Ich habe mich für ein Mittelding entschieden, da ich tägliche Backups habe die über Wochen gespeichert werden und meine VMs nicht so super wichtig sind und ich zur Not dann zu einem Zeitpunkt vor dem Update zurückrolle.
Bei den meisten VMs/LXCs bei mir läuft Debian. Bei Debian kann man einstellen, dass da Sicherheitsupdates automatisch installiert werden, Funktionsupdates aber nicht. Sicherheitsupdates sind meist nicht so tragisch was Inkompatibilitäten angeht, da diese meist nur Sicherheitslücken fixen, welche man ja schnell installiert haben möchte. Problematisch sind da meist eher größere Funktionsupdates, die neue Features hinzufügen oder sehr viel ändern. Die sind für die Sicherheit nicht so wichtig und die mache ich immer noch manuell.

- Macht Zabbix oder Graylog auch für ein paar VMs/Container Sinn?

Ich finde ja. Also zumindestens Zabbix oder eine andere Art von Monitoring Tool. Graylog ist halt echt anspruchsvoll und ich habe es mit weniger als 7GB RAM für die VM nicht zum laufen bekommen, da die ElasticSearchDB mit weniger als 4GB RAM nicht lief. Sehr nett ist halt, dann du da alle Logs von allen Rechnern in einer ElasticSearchDB gespeichert hast und diese nach belieben durchsuchen, filtern, daraus Diagramme erstellen oder sogar plugins installieren kannst, die z.B. die Logs analysieren und dich bei Auffälligkeiten in den Logs vor Hackerangriffen oder Bugs etc warnen.
Ähnlich bei Zabbix. Macht das leben viel einfacher, wenn man nicht alle Rechner täglich und einzeln nach Problemen durchsuchen muss, ob denn noch alles läuft, wie es soll. Ich habe Zabbix immer im Browser-Tab mit offen und gucke da alle paar Stunden mal rein. Meistens ist die "Problems"-Tabelle auf dem Dashboard leer und alles läuft normal, aber hin und wieder ploppen da mal Probleme auf, dann kann ich genau gesehen, welcher Rechner welches Problem seit wie lange hat.

Beides setzt aber auch voraus, dass du da alles erst einmal nach deinen Vorlieben einrichtest. Und das kann sehr aufwändig werden.

Im übrigen können Zabbix und Graylog nicht nur VMs überwachen. Ich hab da auch meine Fritzbox, meine Raspberry Pis, meine OpenWRT-Router, meine FreeNAS-Server, alle sonstigen Windows Rechner daheim und bald noch meinen neuen managed Switch überwacht.

 

[Dunuin]

iSCSI als auch NFS und SMB (aber auch andere Protokolle) brauchen perse keine extreme Leistung. Selbst meine alte QNAP TS-212 konnte ein iSCSI Volume bereitstellen mit 256MB RAM und einer Marvell CPU mit einem Kern und 1,2GHz Leistung. Das was hier in Kombination mit FreeNAS den RAM braucht ist definitiv daher auch nicht iSCSI sondern ZFS selbst, aber auch nur, wenn man hier entsprechende Feature wie Dedup verwenden will, anderenfalls braucht auch FreeNAS mit ZFS nicht exorbitant viel RAM.

iSCSI erzeugt halt viele kleine Writes, weil dann die kleine volblocksize anstatt der großen recordsize benutzt wird. Das sollte ziemlich auf die Performance gehen können, wenn man da ZFS nicht genug RAM zum Cachen gibt. Ziel ist es da ja meist auch eine Geschwindigkeit zu erreichen, wie man sie auch mit einem lokalen SATA Laufwerk hätte.

CEPH kann man mit einem einzigen Server betreiben, gar kein Problem. Man passt nur die Crush Rule an, dass die Verteilung der Replica nicht auf Host sondern OSD ebene stattfindet und schon geht alles in einer Node. Ist nicht mal ein großartiges Hexenwerk, geht recht einfach. Ähnliches geht hier btw. auch mit Erasure Coding. Auch ein Reboot oder ähnliches macht das CEPH nicht kaputt, was bei einem CEPH eh nur dann möglich ist, wenn man den Server abfackelt oder sprengt, ansonsten ist ein CEPH unglaublich robust. Selbst der Verlust der Mons bedeutet keinesfalls den kompletten Datenverlust.
Es geht auch übrigens ohne weiteres mit 1GbE LAN, also keine Notwendigkeit für 10GbE oder sonst irgendwas. Was man haben sollte ist ca. 0,5 - 1 Kerne je OSD (oder Festplatte) und bisschen RAM, aktuell mit Bluestore ist das target bei 4GB RAM pro OSD (Achtung, ist ein Ziel, kann auch übertroffen werden und ist keinesfalls ein Limit!) und einen HBA würde ich empfehlen. Der Rest ist ziemlich egal, die Performance ist absolut okay und liegt im Rahmen. Generell ist ein CEPH eh kein Performancewundern sondern sorgt für Integrität der Daten und legt mehr Wert auf die Datensicherheit als auf Performance.

Ok, wieder was gelernt. Aber wenn ich das richtig verstanden habe macht CEPH immer 3 Kopien von allem und bei Entscheidungen wird dann abgestimmt, welche Version die richtige ist und die Mehrheit gewinnt. Also quasi so wie bei den Computern der Apollo-Missionen, wo es immer 3 Computer gab die das gleiche getan haben und dann 2 von 3 das gleiche als Ergebnis haben mussten, damit dieses als richtig galt.
Wäre es da nicht ziemlich sinnlos 3 OSDs auf einem Server zu betreiben? Ich dachte der Vorteil wäre gerade, dass man da mehrere Server nimmt und die OSDs auf die Server verteilt, damit nichts verloren geht und die Daten immer erreichbar sind, selbst wenn mal ein kompletter Server ausfällt.

Bei der Sicherheit ging es mir eher um Sicherheitspatches, wenn es das wie unter Windows geben sollte.
Wäre halt toll, wenn sowas automatisch eigespielt werden könnte.
Ich möchte mir halt möglichst um wenig Gedanken machen, deshalb überlege ich die Beste Herangehensweise für Container/Server.

Wenn ich jetzt jeden Server ... sagen wir mal Serviio, Emby, Pi-Hole, in jeweils eigene LXC Conateiner packen würde, müsste ich wohl
jeden LXC Container Updaten/aktuell halten.
Wenn das automatisch gehen würde, wäre das ja OK.

Wenn nicht wären die Server als Docker Version dann nicht besser?
Ich könnte dann ja Docker im LXC laufen lassen und mich nur um eine LXC Container kümmern?

Möglichst wenig Gedanken machen wollen ist meist der falsche Ansatz. Je nachlässiger du da bist, und je weniger du versuchst dazuzulernen, desto unsicherer wird das Ganze. Wenn man sich keine Gedanken machen möchte, dann ist man beim Selbsthosting eigentlich auf dem falschen Weg und sollte lieber Cloud-Dienste nutzen, wo sich Profis für einem die Köpfe zerbrechen, um die Sicherheit und Stabilität zu gewährleisten.

Docker kannst du für vieles nutzen und es kann dir einiges erleichtern, weil du dann fertiges konfigurierte Container laufen lässt, wo sich ein Entwickler um den Großteil kümmert und du quasi ein fertiges "Produkt" erhältst. Da diese Docker-Container aber "fertig" sind, lässt sich da aber auch kaum etwas manuell anpassen. Ich selbst habe hier echt nur wenige Docker-Container am Laufen, weil mir diese einfach viel zu unflexibel sind.

 

[beta]

Also erstmal ein großes Lob für die tolle Hilfe hier.
Das ist nicht selbstverständlich und motiviert mich.

Sagen wir mal so ... natürlich muss man sich immer mit Updates/Systemen auseinandersetzen.
Das ist bei Windows und beim NAS nicht anders.
Auch da habe ich die Updates manuell gemacht, obwohl es das eigentlich nicht erforderlich gewesen ist.
Nur bei deutlich mehr Systemen/Containern ist der Aufwand auch größer.
Ein Backup lasse ich im Normalfall ja auch automatisch laufen und stoße es nicht manuell an, nur aus Angst es könnte nicht richtig laufen.
Eine Kontrolle muss es natürlich trotzdem geben, wenn auch nicht ständig.
Ich denke bei Secuityupdates auf einem Heimserver wäre das OK.
Falls mal was nicht mehr läuft könnte man dann ja auf Snapshots zurückgreifen.

- Wenn ich Docker Container auch pflegen bzw. Updaten muss, ist es dann nicht einfacher
einfach nur Securityupdates bei LXC Containern zu machen?
Mir geht es dabei nur um die Sicherheit und nicht um Funktionsupdates.

- Ich denke bei meinem kleinen Homeserver sind die meisten Monitoring-Tools einfach Overkill.
Gibt es da nicht was kleines für Homeserver?

- Unattended-Upgrades oder Puppet sagen mir bisher nichts

LG

 

[Dunuin]

- Wenn ich Docker Container auch pflegen bzw. Updaten muss, ist es dann nicht einfacher
einfach nur Securityupdates bei LXC Containern zu machen?
Mir geht es dabei nur um die Sicherheit und nicht um Funktionsupdates.

Wenn du Docker im LXC nutzt, dann hast du Container im Container auf dem Host. Wenn du den Host updatest, dann kann der LXC immer noch Sicherheitslücken haben, da dieser nicht mit aktualisiert wurde. Updatest du den LXC, dann sind die Docker-Container immer noch nicht aktualisiert. Da musst du dann warten, dass da der Ersteller deines Docker-Containers ein Update erstellt, was die Sicherheitslücken schließt und dann musst du den alten Docker-Container wegwerfen und mit der neuen Version neu erstellen. Selbst updaten kannst du da beim Docker-Container nichts. Docker-Container kannst du ja nicht selbst ohne weiteres verändern, also auch nicht selbst updaten. Da musst du dich also immer auf den Ersteller verlassen, dass der da den Docker-Container immer aktuell hält. Bzw du könntest theoretisch schon selbst was am Docker-Container verändern, aber das ist ja gegen das "Dockerize"-Konzept. Wenn du zu dem Punkt kommst, dass du da irgendwie deine Docker-Container manuell über CLI anpassen musst, dann ist Docker für die Anwendung nicht die erste Wahl und man sollte das lieber gleich selbst im eigenen LXC umsetzen.

- Ich denke bei meinem kleinen Homeserver sind die meisten Monitoring-Tools einfach Overkill.
Gibt es da nicht was kleines für Homeserver?

Die werden im Endeffekt immer irgendwie auf einem Webserver und einer DB aufsetzen. Und gerade letzteres ist echt übel für die Write Amplification, da permament die Metrics in die DB über Sync Writes geschrieben werden, was Consumer SSD ohne Powerloss Protection nicht gut abkönnen. Und HDDs wäre wegen den IOPS schnell überfordert (hatte das auch mal mit HDDS versucht, nachdem ich die M.2 SSD wegen Lebenserwartung entfernen musste, aber die HDDs sind einfach mit den IOPS nicht mehr hinterhergekommen).
Ich finde die 2.5GB RAM für Zabbix gehen eigentlich noch. CPU ist auch nicht so wild. Hat bei mir einen Kern bekommen und Auslastung liegt im Schnitt bei 17%. Die DB schreibt so 400kb/s nach Optimierungen (waren regulär um die 1MB/s). die 400kb/s bzw 1MB/s werden dann durch die Write Amplification aber zu 8MB/s bzw 20MB/s was dann 252TB bzw 630TB pro Jahr an Writes wird, was schnell die TBW der billigen SSD sprengt.

- Unattended-Upgrades oder Puppet sagen mir bisher nichts

"unattended-upgrades" ist das Package, was du bei Debian/Ubuntu installieren musst, wenn du automatisch Upgrades durchführen willst.

 

[beta]

OK, ich hoffe die Infos werden mir nächste Woche als Start reichen.
Ich habe lieber direkt am Start eine durchdachte Infrastruktur, bevor ich nach eine paar Wochen merke,
dass das suboptimal ist.
Aber gut, ein bisschen testen und Erfahrungen sammeln gehört ja auch dazu.

Das mit den Containern wird dann wohl möglichst doch nur auf LXC hinauslaufen.
Die kann ich ja dann updaten wie ich will.

Solche Sachen wie Zabbix oder Puppet muss ich dann wohl später mal ansehen.
Laufen die dann auch je in einem LXC Container?

 

[Dunuin]

Solche Sachen wie Zabbix oder Puppet muss ich dann wohl später mal ansehen.
Laufen die dann auch je in einem LXC Container?

Bei mir laufen die noch aktuell in VMs. Über LXCs hatte ich aber auch schon nachgedacht, damit ich den Virtualisierungs-Overhead aus den Writes hätte. Würden sich aber prinzipiell LXCs für anbieten, da man keine externen Shares mounten bräuchte und die auch nicht aus dem Internet heraus zugreifbar sein müssten.
So richtig konnte ich mich mit LXCs aber noch nicht anfreunden. Die sind zwar prinzipiell effizienter, dafür aber auch unsicherer und machen einen haufenweise Probleme wegen bregrenzten Rechten und Features und sobald ich externe Ordner durchreiche, weil ich z.B. einen SMB-Share brauche, dann darf ich keine Snapshots mehr machen.

 

[beta]

Hmm OK.
Da muss ich dann doch mal einiges testen.
Snapshots wären schon gut.

Haben die unterschiedlichen Templates bzw. LXC Container auch Geschwindigkeitsunterschiede bzw. CPU-Aulastung?
Ich gehe davon aus, dass nach Möglichkeit ein Debian Template die beste Wahl ist, weil PVE auch auf Debian basiert?
Etwas Off-Topic, aber da du auch Emby nutzt .... gibt es einen Grund Emby und nicht Jellyfin zu nehmen?

 

[Dunuin]

Snapshots wären schon gut.

Snapshots gehen prinzipiell, aber nicht wenn du Ordner per bind-mount in den LXC durchreichst. Und da man im unprivilegierten LXC keine SMB-Shares einbinden kann, geht das nur über Umwege mit bind-mounts. Gemeinsame Ordner in LXCs nutzen ist generell ein ziemliches Problem mit Fallstricken.

Haben die unterschiedlichen Templates bzw. LXC Container auch Geschwindigkeitsunterschiede bzw. CPU-Aulastung?

Ja, manche Linuxes sind halt schlanker und kommen mit weniger Programmen, daher weniger RAM und vermutlich auch weniger CPU-Auslastung. Alpine Linux wäre z.B. so ein Kandidat, der auch wegen dem kleinen Footprint als Basis für die meisten Docker-Container dient.
Hauptvorteil ist aber, dass da die Virtualisierung und dessen Overhead wegfällt, weshalb das immer schlanker ist als eine VM. Egal was man da jetzt genau für ein Linux nutzt. Weil es aber eben nicht virtualisiert und damit richtig isoliert und eigenständig lauffähig ist, kommt man da schnell an die Grenzen und stößt auf Probleme, die sich oft nur beheben lassen, indem man die Sicherheit senkt oder Dinge über Umwege auf dem Host selbst tut, was ja eigentlich auch nicht Sinn der Sache ist.
Ich persönlich nehme einfach für alles Debian. Ist nicht schlank, aber gut supportet, hat umfangreiche Funktionen, stabil und ich komme damit noch am besten klar. Kann auch Sinn machen da überall das gleiche OS zu nehmen, weil dann lässt sich der RAM deutlich besser deduplizieren.
Von den 64GB RAM hier im Server spart mir die RAM Deduplikation (KSM) gerade knappe 10GB ein.
Nehm einfach das, mit dem du am besten klar kommst. Ich hab hier jetzt hunderte von Stunden per CLI mit dem Server, LXCs und VMs rumgewerkelt. Wenn man so viel Zeit mit dem Editieren von Konfig-Dateien etc verbringen muss, dann am besten so, dass man da auch gleich gut mit klarkommt.

Ich gehe davon aus, dass nach Möglichkeit ein Debian Template die beste Wahl ist, weil PVE auch auf Debian basiert?
Etwas Off-Topic, aber da du auch Emby nutzt .... gibt es einen Grund Emby und nicht Jellyfin zu nehmen?

Ich hatte damals Jellyfin, Plex und Emby getestet.
Emby hatte mir im Gesamtpaket einfach am besten zugesagt. Bis auf den etwas nervigen Punkt, dass da keine GPU-Beschleunigung ohne Lizenz geht, fand ich das als kostenlose Variante noch am vertretbarsten. Ansonsten geht noch DVR nicht ohne Lizenz, aber das hatte ich eh nicht vor zu nutzen.
Jellyfin fand ich ziemlich unausgereift, wenn man es mit Plex oder Emby vergleicht. Bei Plex hatten mich einige Punkte genervt, z.B. die schlechte Medienerkennung und viele erweiterte Optionen wurden einen ohne den Plex Pass verboten.
Support ist bei Emby auch ziemlich gut. Wenn ich was in deren Forum wegen Problemen geschrieben habe, dann hat eigentlich immer der Entwickler auch selbst geantwortet und ist der Sache nachgegangen. Das einzige was mir bei Emby wirklich fehlt ist ein ordentlicher Bulk-Editor, damit man nicht immer alles einzeln Taggen oder Editieren müsste. Gibt da zwar einen, aber den fand ich zu unflexibel.

 

[beta]

Ok, danke.

man im unprivilegierten LXC keine SMB-Shares einbinden kann

- Bedeutet, wenn ich einen unprivilegierten LXC Container hätte in dem z.B. Emby läuft könnte Emby nicht auf SMB-Freigaben vom NAS zugreifen?
- Ist das denn in einem privilegierten LXC Container anders? Und wenn ja, wo sind dann die Nachteile eines privilegierten LXC Containers?
- Eine Snapshot bräuchte ich nicht wirklich, aber ein Backup sollte k

- Welches Template würde für mich denn Sinn ergeben was:
1. Sicherheits-Patches automatisch macht
2. Langen Support hat
3. Vollzugriff auf SMB hat
4. Möglichst wenig CPU/Ram braucht
5. Eine Snapshot bräuchte ich nicht wirklich, aber ein Backup wäre schön

Also hier mein aktueller Plan für den Heimserver:
- 1 x SSD für die VMs/Container
- 1 x HDD als Storage durchreichen für ein VM NAS
Dabei bin ich mir immer noch nicht sicher welches Filesystem das HDD Storage haben soll.
Im optimalen Fall ein Filesystem, bei dem ich das VM NAS auch tauschen könnte.
Ich hoffe das möglich ist, von z.B. einem Truenas VM zu einem OVM zu wechseln und das Storge dann wieder
verwenden zu können. BTRFS vielleicht?
Schöne wäre ja auch im Notfall noch an die Daten zu kommen, falls die Hardware mal abraucht.

LG

 

[CoolTux]

Sicherheits-Patches automatisch macht, dafür gibt es meines Wissens nichts fertiges. Ich würde sofern Wissen vorhanden mir ein Debian holen. Dieses entsprechend Deinen Wünschen und Konfiguration mit aktuellem Patch Stand anpassen und dann daraus ein Template machen.
Du kannst später beim ausrollen des Templates entscheiden ob privilegiert oder nicht.
Im übrigen ist das gesamte System nur so sicher wie alle Komponenten, dazu zählt auch derjenige das das ganze aufsetzt und verwaltet. Solltest Du also nur rudimentäres Linuxwissen haben bist Du schon mal das schwächste Glied. Das ist nicht böse gemeint, verlangt von Dir aber viel Arbeit und Energie. Oder eben nicht, aber dann ist es auch egal ob update, unprivilegiert oder was weiß ich.

Setze erstmal ein System auf und spiele damit rum. Und dann kann man ja mal schauen. Solange Du keinen direkten Draht von aussen (Internet) zu Deinen Systemen hast kann man auch mit den Systemen spielen. Ich habe 20 Jahre gebraucht um mir zu trauen einen Mail-Relay Server im Internet auf zusetzen. Bis dahin habe ich viel geübt und mit kleinen Schritten angefangen meinen Mailserver immer etwas mehr zu öffnen.

 

[Dunuin]

- Bedeutet, wenn ich einen unprivilegierten LXC Container hätte in dem z.B. Emby läuft könnte Emby nicht auf SMB-Freigaben vom NAS zugreifen?

Genau. Jedenfalls nicht direkt, da ein unprivilegierter LXC keine Rechte besitzt etwas mounten zu dürfen (mal abgesehen von bind-mounts vom Host zum Gast). Da kann dann höchstens der Host den Share selbst mounten und den mountpoint dann per bind-mount an den LXC durchreichen. Aber das ist ziemlich kompliziert wegen User-Remapping (siehe hier) und du hast halt immer die Abhängigkeit vom Host, da der LXC nicht selbst lauffähig ist und sich auf den gemounteten SMB-Share vom Host verlassen muss. Sobald du den Host neu aufsetzen musst, was recht schnell passieren kann, weil du ja kein Raid1 willst, kann dann auch dein LXC nicht mehr starten, bis du da den Host erneut genau so wie vorher konfiguriert hast und dieser wieder den SMB-Share über den bind-mount bereitstellt.

- Ist das denn in einem privilegierten LXC Container anders? Und wenn ja, wo sind dann die Nachteile eines privilegierten LXC Containers?

Ja, im privilegierten LXC geht das, wenn man das "CIFS"-Feature aktiviert. Privilegierte LXCs sind weniger vom Host isoliert und damit unsicherer, weil es einem viel weniger Hürden in den Weg legt, den ganzen Host zu übernehmen, wenn man erstmal Zugriff auf den LXC hat. Mag für Dienste im sicheren LAN ok sein, aber ich würde so nichts betreiben wollen, was irgendwie aus dem Internet erreichbar ist. Genau genommen würde ich überhaupt nicht zu LXCs raten, wenn es produktiv eingesetzt werden soll oder irgendwie vom Internet aus erreichbar sein soll. VMs machen einem da noch die wenigsten Probleme und sind auch am sichersten.

- Eine Snapshot bräuchte ich nicht wirklich, aber ein Backup sollte k

Backups gehen dann noch, jedoch werden deine SMB-Shares dann nicht mitgesichert. Das kann das Backup dann nicht.

- Welches Template würde für mich denn Sinn ergeben was:
1. Sicherheits-Patches automatisch macht
2. Langen Support hat
3. Vollzugriff auf SMB hat
4. Möglichst wenig CPU/Ram braucht
5. Eine Snapshot bräuchte ich nicht wirklich, aber ein Backup wäre schön

Wie Leon schon schrieb wirst du das mit den automatischen Updates (unattended-upgrade) und SMB (cifs-utils) schon selbst einrichten müssen.
Alpine hätte von den fertigen Templates wohl den geringsten RAM-Verbrauch, dafür aber wohl kein LTS. Ich persönlich konnte mich mit Alpine auch nie wirklich anfreunden. Ich fand das alles ziemlich rudimentär und sperrig im Vergleich zum Debian. Wenn du nicht super fit mit Linux bist, dann würde ich da auch einfach zum Debian raten.
Erstens musst du dich damit eh auseinander setzen, da Proxmox quasi ein modifiziertes Debian ist. Zweitens findest du zu allem haufenweise Tutorials. Und wenn du mal kein Tutorial für Debian findest, dann ganz sicher eines für Ubuntu, was zu 99% auch geht, da Ubuntu auch nur ein Fork von Debian ist. Früher oder später wirst du immer auf Fehler stoßen, welche sich nur mit viel wissen per CLI lösen lassen. Da ist es super wichtig, dass man eine gute Community hat. Und Fehler sind selten einzigartig. Wen man die Logzeile des Fehlers in Google eintippt, dann findet man meist irgendwelche Blogs/Foren wo genau der Fehler bereits diskutiert wurde und oft enthält das dann auch schon den Workaround oder Lösungsansatz.
Aber ist wie gesagt nicht das schlankeste Linux.

Also hier mein aktueller Plan für den Heimserver:
- 1 x SSD für die VMs/Container
- 1 x HDD als Storage durchreichen für ein VM NAS
Dabei bin ich mir immer noch nicht sicher welches Filesystem das HDD Storage haben soll.
Im optimalen Fall ein Filesystem, bei dem ich das VM NAS auch tauschen könnte.
Ich hoffe das möglich ist, von z.B. einem Truenas VM zu einem OVM zu wechseln und das Storge dann wieder
verwenden zu können. BTRFS vielleicht?
Schöne wäre ja auch im Notfall noch an die Daten zu kommen, falls die Hardware mal abraucht.

TrueNAS nutzt nur ZFS. OVM unterstützt meines Wissens kein ZFS. Wechseln ist da also nicht wirklich drin. Ich bin nicht sicher wie genau das bei BTRFS aussieht, aber bei ZFS wäre das ziemlich unproblematisch, sofern du die Verschlüsselung deaktivierst. Musst du die HDD halt in einen anderen PC stecken und dort ein Live Linux vom USB-Stick oder CD booten, welches ZFS oder BTRFS unterstützt. Dann kannst du den ZFS Pool per CLI mit "zpool import" importieren und darauf zugreifen.

Sicherheits-Patches automatisch macht, dafür gibt es meines Wissens nichts fertiges. Ich würde sofern Wissen vorhanden mir ein Debian holen. Dieses entsprechend Deinen Wünschen und Konfiguration mit aktuellem Patch Stand anpassen und dann daraus ein Template machen.
Du kannst später beim ausrollen des Templates entscheiden ob privilegiert oder nicht.
Im übrigen ist das gesamte System nur so sicher wie alle Komponenten, dazu zählt auch derjenige das das ganze aufsetzt und verwaltet. Solltest Du also nur rudimentäres Linuxwissen haben bist Du schon mal das schwächste Glied. Das ist nicht böse gemeint, verlangt von Dir aber viel Arbeit und Energie. Oder eben nicht, aber dann ist es auch egal ob update, unprivilegiert oder was weiß ich.

Setze erstmal ein System auf und spiele damit rum. Und dann kann man ja mal schauen. Solange Du keinen direkten Draht von aussen (Internet) zu Deinen Systemen hast kann man auch mit den Systemen spielen. Ich habe 20 Jahre gebraucht um mir zu trauen einen Mail-Relay Server im Internet auf zusetzen. Bis dahin habe ich viel geübt und mit kleinen Schritten angefangen meinen Mailserver immer etwas mehr zu öffnen.

Sehe ich genau so.

 

[beta]

OK.
Aus dem Internet erreichbar muss da bisher nix sein.
Und wenn dann gehe ich über das VPN der Fritzbox.
Truenas scheint wohl nur ZFS zu können, OVM kann ZFS per Plugin.
Ich hoffe da ist ein ZFS-Versionunterschied kein Problem, falls es mal zum Wechsel kommen sollte.
Auch wenn ich es anfänglich ausgeschlossen hatte scheint es jetzt evtl. doch wieder eine gute Wahl zu sein.
Zumal sich gefühlt alles in Richtung ZFS entwickelt.

Wenn ich das richtig geshen habe, kann man Proxmox jetzt ja quasi über das UI Updaten.
Somit sollte der "Host" dann ja sicher sein?
Und ein aktueller privilegierten LXC dann eigentlich ja auch.
Das mit den Containern scheint doch komplexer zu sein, als ich dachte.

Ganz schön schwere Stoff hier.
Aber ich lerne gerne dazu.

 

[Dunuin]

Ich hoffe da ist ein ZFS-Versionunterschied kein Problem, falls es mal zum Wechsel kommen sollte.

ZFS ist abwärtskompatibel aber nicht aufwärts. Einen v0.83 Pool in einem OS mit v0.85 zu benutzen sollte kein Problem sein. v0.85 Pool im OS mit v0.83 aber schon. Das gleiche wenn man ZFS Features für einen Pool aktiviert. Den Pool muss man aber manuell updaten. Nur weil ein Update vom OS das ZFS auf dem Rechner von v0.83 auf v0.85 updatet, heißt das nicht, dass da auch automatisch der Pool zu v0.85 wird. Pool updaten sollte man echt erst, wenn man einige Wochen die neue ZFS Version betrieben hat und keine Probleme feststellen konnte, weil sonst ein Rollback zu einer älteren Version des OS nicht mehr möglich wäre.

Auch wenn ich es anfänglich ausgeschlossen hatte scheint es jetzt evtl. doch wieder eine gute Wahl zu sein.
Zumal sich gefühlt alles in Richtung ZFS entwickelt.

Wenn ich das richtig geshen habe, kann man Proxmox jetzt ja quasi über das UI Updaten.
Somit sollte der "Host" dann ja sicher sein?
Und ein aktueller privilegierten LXC dann eigentlich ja auch.
Das mit den Containern scheint doch komplexer zu sein, als ich dachte.

"sicher" ist so eine Sache. Nur weil etwas aktuell gehalten wird, heißt das nicht, dass das auch sicher ist. Will man ein System sicher machen und halten, dann können da hunderte Stunden in die Recherche reingehen. Du kannst 1000 Dinge installieren und konfigurieren, welche den Host sicherer machen. Ban2Fail, Monitoring, Intrusion Detection, Rechte-Management, Authentifizierung und Zertifikate, Ausfallsicherheit, Datenintegrität, Netzwerk-Aufbau, alle Dienste möglichst härten indem man dessen Konfigurationen entsprechend anpasst, ...
Das übernimmt kein Linux automatisch für dich und es muss alles per Hand gemacht und aktuell gehalten werden. Das ist auch immer alles so individuell, dass du da nicht einfach Tutorials abschreiben kannst. Eine falsche Zeile und nichts läuft mehr. Sicherheit heißt ja auch, dass da quasi nichts von sich aus funktionieren darf, außer du erlaubst es explizit und hast es entsprechend eingestellt. Also Rechte, Zugänge etc bestmöglich begrenzen.

Aber ja, wenn du keinen Port-Forward vom Router zum Proxmox-Server machst, dann ist das mit der Sicherheit nicht so wild. Vom LAN aus wird dich ja kaum jemand daheim angreifen. Problematisch wird es erst, wenn auch anfängst noch Webserver und Co betreiben zu wollen. Früher oder später denkt man sich dann doch "Jetzt habe ich schon ein NAS wo alle meine Daten liegen...ich würde da auch gerne vom Handy oder Browser darauf zugreifen...". Dann macht man sich eine Nextcloud drauf und schon hat man ein Sicherheitsproblem, wenn man nicht genau weiß, was man da tut.

Für ZFS hast du aber echt keine gute Hardware gewählt. Da wäre ECC RAM, mehr RAM und eine Enterprise SSD schon gut gewesen. Nicht vergessen, dass da bei dir Proxmox mit ZFS schon alleine so 6-10GB RAM permament belegen wird, ohne dass da auch nur eine VM oder ein LXC läuft. Auch kannst du viele tolle ZFS Features nicht nutzen, wenn du keine Mirrors oder Raidz benutzt. Da müsstest du schon alle SSDs und HDDs mindestens doppelt kaufen und spiegeln. Sonst kann dir da ZFS zwar sagen welche deiner Dateien durch schleichenden Dateiverlust oder Schreibfehler kaputt ist, es kann diese dann aber nicht automatisch reparieren. Für die Selbstheilung bräuchtest du schon irgendeine Art von Parität.

 

[sb-jw]

iSCSI erzeugt halt viele kleine Writes, weil dann die kleine volblocksize anstatt der großen recordsize benutzt wird. Das sollte ziemlich auf die Performance gehen können, wenn man da ZFS nicht genug RAM zum Cachen gibt. Ziel ist es da ja meist auch eine Geschwindigkeit zu erreichen, wie man sie auch mit einem lokalen SATA Laufwerk hätte.

Man muss hier Differenzieren, deine ursprüngliche Aussage war, dass man für iSCSI mindestens 64GB RAM benötigt. Aber man benötigt es ja nicht für den Betrieb des Target selbst, sondern für das darunterliegende Storage, weshalb die Aussage so ja nicht korrekt ist. Für ein iSCSI Target mit einem Hardware RAID drunter braucht man sicherlich keine 64GB RAM.

Aber die Grundlegende implementierung von iSCSI ist schon nicht so genial. Die Dateien werden nicht direkt auf das iSCSI LUN sondern im Hintergrund weiter kopiert. Was z.B. unter Windows als extremste Performance aussieht, nur weil das "Kopieren" Fenster nach ein paar Sekunden verschwindet, ist in Wahrheit etwas, was ich nicht haben wollen würde. Der Ack kommt hier also mehr oder weniger Instant, doch sind die Daten noch lange nicht auf dem iSCSI LUN geschrieben und gesichert.
Das verhalten der iSCSI LUN soll wie eine lokale Festplatte sein, doch die Performance wie eine lokale Festplatte hat man nur durch solche Aktionen, dass der Ack instant kommt und nicht erst, wenn das File auch wirklich auf der LUN geschrieben ist.
Auch der Punkt, dass das komplette LUN kaputt ist, wenn man es versehentlich mehrfach gemountet hat und keinen director dazwischen hat, wie z.B. VMware oder ähnliches, ist halt auch ein Punkt weshalb ich iSCSI niemals produktiv verwenden wollen würde.

Aber wenn ich das richtig verstanden habe macht CEPH immer 3 Kopien von allem und bei Entscheidungen wird dann abgestimmt, welche Version die richtige ist und die Mehrheit gewinnt.

Die Anzahl der Kopien bestimmt man selbst, man kann 2/1 machen, also size = 2 und min size = 1 oder auch 3/2 oder 3/1. Entsprechend ändert sich aber auch das Verhalten von CEPH, gerade in Bezug auf die min size. Wird min size unterschritten, schaltet CEPH den Pool ab, es werden keine I/O mehr angenommen. So wird verhindert, dass noch Daten geschrieben werden, welche dann potentiell ebenfalls verloren wären. Bei 3/2 ist das Risiko auch deutlich geringer als bei 2/1. Aber man kann auch 4/2 und mehr machen, wenn man den Speicherplatz hat oder eben eine Anforderung daran - das kann z.B. sein, wenn man 4 Rechenzentren hat und jedes exakt eine Kopie erhalten soll. Ob das Sinn macht oder nicht, das entscheidet dabei aber die Anforderung an den Storage.

Wäre es da nicht ziemlich sinnlos 3 OSDs auf einem Server zu betreiben? Ich dachte der Vorteil wäre gerade, dass man da mehrere Server nimmt und die OSDs auf die Server verteilt, damit nichts verloren geht und die Daten immer erreichbar sind, selbst wenn mal ein kompletter Server ausfällt.

Grundsätzlich gilt in der IT immer, dass man wissen sollte was man tut - so lange man das weiß, passiert auch nichts.
Der Vorteil von CEPH liegt in der Integrität der Daten und dessen Verteilung, grundsätzlich aber erst mal nicht zwangsweise, dass man es auf mehrere Server aufteilen kann (aber ja, natürlich ist das auch als Vorteil zu sehen).
Ein einfaches Beispiel dazu, ich habe bei meiner eigenen Firma ein Backup CEPH mit einer Node gemacht und 12 Festplatten. Warum man so was macht? Nun man braucht ja Backup Speicherplatz, aber wie üblich in der IT keiner will dafür den Preis bezahlen - also haben wir auch nur "Schrott" in den CEPH gesteckt. Es ist ein Mix aus SATA und SAS Festplatten mit einer Größe zwischen 500GB und 4TB. Es mag für dich nun völlig absurd wirken, was wir hier gemacht haben. Aber machen wir mal weiter.

Dank des CEPH Storages können wir Wirtschaftlich arbeiten, wir können alte noch funktionierende und ungenutzte Datenträger so lange verwenden, bis diese endgültig Kaputt sind. Durch CEPH macht das keinen größeren Unterschied, das noout Flag ist nicht gesetzt und so heilt sich ein CEPH beim Ausfall einer Festplatte einfach direkt selbst (damit ist die Redundanz auch wieder hergestellt). Aufgrund einer gewissen Überkapazität ist es nicht mal erforderlich, dass ich dafür in der Nacht aufstehe ins RZ fahre und die Platte tausche, das kann ich einfach dann einplanen wenn es passt.
Wir können wachsen und skalieren wie wir wollen. Brauchen wir mehr Speicherplatz, können wir entweder alte Festplatten austauschen oder eine weitere Node hinzufügen. Fügen wir eine Node hinzu können wir die Crush Rule anpassen und die Daten werden auf zwei Server verteilt. Haben wir durch Optimierung und Konsolidierung aber nun mehr Backup Speicherplatz als nötig, schmeißen wir einfach eine Node wieder raus.

Wenn du nun so darüber nachdenkst, wirst du vielleicht merken, dass so eine Single Node CEPH doch einige Vorteile hat gegenüber einem Backup Server mit ZFS oder lokalem RAID. Dank des Scrubbing muss ich mich auch nicht um Bit rot sorgen, ja auch ZFS kann das, aber eben nicht jedes Filesystem. Wie kannst du mit einem lokalen RAID oder ZFS skalieren? Nun übers Chassis hinaus eigentlich überhaupt nicht, ich kann mit dem CEPH hingegen hoch und runter skalieren wie ich es brauche.
Bei einer Node hat man aber natürlich keinen wirklichen Vorteil gegenüber ZFS oder einem lokalen RAID, das skaliert erst wenn man mehr benötigt und genau dann fangen doch die Probleme an. Nun hat man einen Server voll mit 18TB Festplatten aber braucht noch 250TB mehr, also zweiter Server neues Ziel, jetzt muss man nur noch die Backup Jobs richtig auf die beiden Server verteilen und dann passiert auch nichts. Wie macht man das im CEPH? Man schiebt ne Node nach, nimmt diese mit in die Crushmap und ist fertig, nichts mit Backup Jobs anpassen oder neues Target einrichten, denn der Storage hinter dem einen Ziel hat nun einfach 250TB mehr Speicherplatz

Aber wie dem auch sei, ich wollte den Thread dafür nun nicht hijacken

 

[beta]

Nicht schlimm, auch wenn da für die Art meines Servers nicht in Frage kommt.
Aber in meinem Fall darf man das auch nicht überbewerten.
Es wird ja 'nur' ein kleiner Heimserver.
Alles nicht so einfach, selbst mit ZFS scheinbar nicht.
Bei Truenas steht was von OpenZFS 2.0.
Bei OVM hab ich zum ZFS Plugin nichts gefunden.
Gibt es auch unterschiedliche EXT4 oder BTRFS Versionen?
Ist die kombatibilität da besser/einfacher?

 

[Dunuin]

Man muss hier Differenzieren, deine ursprüngliche Aussage war, dass man für iSCSI mindestens 64GB RAM benötigt. Aber man benötigt es ja nicht für den Betrieb des Target selbst, sondern für das darunterliegende Storage, weshalb die Aussage so ja nicht korrekt ist. Für ein iSCSI Target mit einem Hardware RAID drunter braucht man sicherlich keine 64GB RAM.

Ja, da stimme ich dir zu. Das war auf iSCSI mit ZFS bzw am FreeNAS bezogen.

Die Anzahl der Kopien bestimmt man selbst, man kann 2/1 machen, also size = 2 und min size = 1 oder auch 3/2 oder 3/1. Entsprechend ändert sich aber auch das Verhalten von CEPH, gerade in Bezug auf die min size. Wird min size unterschritten, schaltet CEPH den Pool ab, es werden keine I/O mehr angenommen. So wird verhindert, dass noch Daten geschrieben werden, welche dann potentiell ebenfalls verloren wären. Bei 3/2 ist das Risiko auch deutlich geringer als bei 2/1. Aber man kann auch 4/2 und mehr machen, wenn man den Speicherplatz hat oder eben eine Anforderung daran - das kann z.B. sein, wenn man 4 Rechenzentren hat und jedes exakt eine Kopie erhalten soll. Ob das Sinn macht oder nicht, das entscheidet dabei aber die Anforderung an den Storage.


Grundsätzlich gilt in der IT immer, dass man wissen sollte was man tut - so lange man das weiß, passiert auch nichts.
Der Vorteil von CEPH liegt in der Integrität der Daten und dessen Verteilung, grundsätzlich aber erst mal nicht zwangsweise, dass man es auf mehrere Server aufteilen kann (aber ja, natürlich ist das auch als Vorteil zu sehen).
Ein einfaches Beispiel dazu, ich habe bei meiner eigenen Firma ein Backup CEPH mit einer Node gemacht und 12 Festplatten. Warum man so was macht? Nun man braucht ja Backup Speicherplatz, aber wie üblich in der IT keiner will dafür den Preis bezahlen - also haben wir auch nur "Schrott" in den CEPH gesteckt. Es ist ein Mix aus SATA und SAS Festplatten mit einer Größe zwischen 500GB und 4TB. Es mag für dich nun völlig absurd wirken, was wir hier gemacht haben. Aber machen wir mal weiter.

Dank des CEPH Storages können wir Wirtschaftlich arbeiten, wir können alte noch funktionierende und ungenutzte Datenträger so lange verwenden, bis diese endgültig Kaputt sind. Durch CEPH macht das keinen größeren Unterschied, das noout Flag ist nicht gesetzt und so heilt sich ein CEPH beim Ausfall einer Festplatte einfach direkt selbst (damit ist die Redundanz auch wieder hergestellt). Aufgrund einer gewissen Überkapazität ist es nicht mal erforderlich, dass ich dafür in der Nacht aufstehe ins RZ fahre und die Platte tausche, das kann ich einfach dann einplanen wenn es passt.
Wir können wachsen und skalieren wie wir wollen. Brauchen wir mehr Speicherplatz, können wir entweder alte Festplatten austauschen oder eine weitere Node hinzufügen. Fügen wir eine Node hinzu können wir die Crush Rule anpassen und die Daten werden auf zwei Server verteilt. Haben wir durch Optimierung und Konsolidierung aber nun mehr Backup Speicherplatz als nötig, schmeißen wir einfach eine Node wieder raus.

Wenn du nun so darüber nachdenkst, wirst du vielleicht merken, dass so eine Single Node CEPH doch einige Vorteile hat gegenüber einem Backup Server mit ZFS oder lokalem RAID. Dank des Scrubbing muss ich mich auch nicht um Bit rot sorgen, ja auch ZFS kann das, aber eben nicht jedes Filesystem. Wie kannst du mit einem lokalen RAID oder ZFS skalieren? Nun übers Chassis hinaus eigentlich überhaupt nicht, ich kann mit dem CEPH hingegen hoch und runter skalieren wie ich es brauche.
Bei einer Node hat man aber natürlich keinen wirklichen Vorteil gegenüber ZFS oder einem lokalen RAID, das skaliert erst wenn man mehr benötigt und genau dann fangen doch die Probleme an. Nun hat man einen Server voll mit 18TB Festplatten aber braucht noch 250TB mehr, also zweiter Server neues Ziel, jetzt muss man nur noch die Backup Jobs richtig auf die beiden Server verteilen und dann passiert auch nichts. Wie macht man das im CEPH? Man schiebt ne Node nach, nimmt diese mit in die Crushmap und ist fertig, nichts mit Backup Jobs anpassen oder neues Target einrichten, denn der Storage hinter dem einen Ziel hat nun einfach 250TB mehr Speicherplatz

Aber wie dem auch sei, ich wollte den Thread dafür nun nicht hijacken

Danke, wieder was gelernt. Das klingt tatsächlich ziemlich sinnvoll in dem Anwendungsfall.

 

[Dunuin]

Bei Truenas steht was von OpenZFS 2.0.
Bei OVM hab ich zum ZFS Plugin nichts gefunden.
Gibt es auch unterschiedliche EXT4 oder BTRFS Versionen?
Ist die kombatibilität da besser/einfacher?

TrueNAS 12.0 hat gerade OpenZFS 2.0.
Proxmox11.3 hat OpenZFS 0.85.
FreeNAS/TrueNAS 11.3 hat glaube ich noch ein eigenes ZFS ("ZFS on FreeBSD" statt "ZFS on Linux"...FreeNAS ist eben kein Linux sondern Unix und hatte da was paralleles entwickelt. Und ZFS stammt eigentlich von Unix und das es auch unter Linux läuft ist relativ neu. Mit OpenZFS 2.0 versuchen die beides unter einen Hut zu bekommen.)

EXT4 sollte da unproblematisch sein. Das läuft quasi auf jedem Linux. Bei BTRFS weiß ich das nicht. BRTFS ist aber auch wieder ein Copy-On-Write-Dateisystem wie ZFS.