Speichereinrichtung Proxmox für variierende Anwendungen

webtaz

Lt. Junior Grade
Registriert
März 2010
Beiträge
283
Hallo zusammen,

ich habe ein paar Fragen bzw. erhoffe mir Ratschläge zum (flexiblen) Einrichten des Speichers für ein Serversystem, auf dem über Proxmox div. Anwendungen laufen (mehr unten). Dazu kommen auch Fragen bzgl. Backup.

Eigentlich hätte die Einrichtung deutlich später erfolgen sollen (=mehr Zeit für Recherche), aber jetzt gab es einen Hardwareausfall, so dass ich ein paar alte Anwendungen umziehen muss.

Hardware
An Speicher verbaut ist: 1x 256GB M.2 NVME SSD (Link), 2x 2TB 2,5" NVME SSDs (Link), und 6x 8TB 3,5" HDD (Link)
- Proxmox ist momentan auf der M.2 installiert, diese hat also auch Boot / EFI Partition und LVM.

Ich muss zugeben, ich hatte das Konzept von LVM bei der Hardwareauswahl nicht richtig verstanden (vermutlich immer noch nicht), und außerdem habe ich nicht gesehen, dass Proxmox VE keinen Software Raid unterstützt.
Please note that Proxmox VE currently only supports one technology for local software defined RAID storage: ZFS
Wenn ich aber weiter recherchiere, dann ist das eher eine Entscheidung für Produktivsysteme, und solange PVE nicht auf dem Software / Linux /md Raid liegen soll, kann es auch nachträglich eingerichtet werden via BootCD oder über das Debian nachinstalliert?

Ziele
Grob zusammengefasst soll der Server 2 "Phasen" durchlaufen, kaum etwas davon ist
- In der ersten Phase sollen Anwendungen bzgl. der Speicherung, Verarbeitung, Automatisierung von (Forschungs)Daten getestet werden. Diese sollen virtualisiert werden, um hier möglichst flexibel zu bleiben. Dabei geht es bei Gitlab Runnern für einfache Tests los, Software für Datenverwaltung, Umgebungen mit Software zur Auswertung/Validierung von Daten (VMs/Containe, z.B. jupyterlab), Speichersystem (HSDS), Graphendatenbank (neo4j), evtl. andere Datenbanken + Frontend. Alles nur Beispiele, da kann auch noch viel dazu kommen.


Eigentliche Daten sind dabei immer nur zum Testen auf dem Server, sprich es müssen keine großen Datenmengen gesichert werden.
Es soll aber möglich sein, zu Testen inwiefern sich der Unterschied von HDD / SDD Speicher bei manchen Anwendungen auswirkt - also z.B. möchte ich eine VM gerne mit Disks von beiden Speichern bedienen können.

- In der zweiten Phase werden einige der Anwendungen aus Phase1 weiter laufen, aber es soll dann auch ein Archivsystem für Forschungsprojekte (und deren Daten) angelegt werden.
Sprich hier würden dann die HDDs als Datenspeicher benötigt, Backups, Freigabe (Einbindung in AD Domäne), evtl. spezifischere Zugriffsrechte (Dateien erstellen, aber nicht löschen oder verändern, oder im Rahmen von VCS "Ändern möglich" aber nur sofern der Stand vorher "committet" wurde o.Ä.), dazu evtl., Routinen die regelmäßig über die Dateien/Metadaten laufen.

- In dem Fall, dass ich etwas zerschieße, möchte ich zumindest relativ leicht wieder die "wichtigeren" Sachen zum laufen bekommen. Aber zum Thema Backup nochmal extra.


Ideen
- Ursprünglich wollte ich die HDDs als (Software) RAID5 laufen lassen, die 2 SSDs als RAID 1, und auf beiden LVM und dann jeweils Partitionen für VMs und Daten bzw. Datenbanken. ZFS hatte ich erstmal außen vor gelassen (weil kompliziert, und hier noch nicht verwendet). --> Hatte ich jetzt fallen lassen, bis ich darauf gestoßen bin, dass Software Raid doch möglich ist.

- Ich hatte mir etwa überlegt mit 5 der 6 HDDs ein ZFS1 zu erstellen, und die 6. als lokalen "Spiegel" für die SSDs oder Objekte (VMs, Datenpartitionen? usw.) zu nutzen.

- Es gibt ja die Möglichkeit ZFS mit Cache einzurichten, ich habe jetzt schon verschiedenes gelesen, teils lohnt sich das vor allem bei synchronen Schreibvorgängen (Datenbanken?). Würdet ihr das Empfehlen? Allerdings habe ich dann praktisch nur "1 Grundspeicher" oder aber ich würde 1SSD + XHDDs zu einem ZFS mit Cache bauen, und die zweite SSD separat nutzen?
Ich habe öfter gelesen dass man 1+5GB RAM pro verwaltetem TB an ZFS haben soll. 64 GB RAM würden da nur für 10TB Speicher herhalten - sprich 2-3 Platten im ZF1 ?

Aufteilung
  • Wie bereits erwähnt, ich möchte sowohl HDD als auch SSD für die "VM filesystems" nutzen können, das selbe gilt für eingebundene Datenpartitionen dort.
  • Würde es Sinn machen, die Boot + Host OS Partition zu spiegeln, so dass ich - falls die m.2 ausfällt - von dort booten könnte (separate Partition - auf einer der HDDs evtl?
  • Ich habe Ideen gesehen ZFS auf LVM bzw. andersrum laufen zu lassen, das würde mir aber nur Komplexität bringen?
  • Momentan kann ich nur eine VG pro Platte erstellen, Verstanden habe ich es aber so, dass es auch möglich ist, VG über mehrere HDDs zu spannen = effektiv JBOD? Muss ich also im Prinzip erst das Software raid erstellen, um darauf dann eine VG zu bauen, die ich in log. Volumes einteile (und hier kann ich sehr dynamisch anpassen)?

Backup
  • Keine weiteren Systeme mit ZFS im Einsatz, ich kann also die (sexy) Funktionen von ZFS für das senden von Snapshots nicht nutzen (allerhöchstens lokal), aber eigentlich möchte ich (zumindest in Phase 1) eher das PVE + ausgewählte VM/Container sichern.
  • Veeam ist hier am Institut auf anderen Servern und auch Clients im Einsatz, deshalb wäre es sinnvoll hier in die Infrastruktur zu spielen. Ich weiß, dass Veeam unter Windows Server die HyperV VMs dediziert sichern kann, und dann auch die VM (bzw. deren Inhalt) ohne Wiederherstellung bereitstellen kann.
Ich nehme an, das gibt es unter Proxmox nicht? - Das hier habe ich gefunden, das wäre schon recht nützlich, dann zusätzlich noch die Partitionen des Host als "faule Brachialmethode" sichern (oder alternativ die Config via '/etc/pve' und '/etc/network/interfaces').
Habt ihr hier Ratschläge?


Hier noch der Verweis auf meinen vorherigen Thread:
https://www.computerbase.de/forum/t...er-virtualisierung-und-datenbanktest.2050549/
 
Zuletzt bearbeitet:
  • Proxmox schreibt viele logs auf die Root Partition. Daher muß die SSD eine hohe Schreiblast vertragen.
  • Die brauchst Speicher für die VMs, das können gut die 2xSSDs sein. Power Loss Protection ist empfehlenswert
  • Das ZFS kann man z.B. bei den HDDs verwenden: Empfehlung RAID10; Die Daten kann man entweder über NFS an eine KVM, oder über Bind-Mount an einen LXC weiterreichen.
  • Proxmox kann Backups der VMs von den SSDs auf die HDDs machen, automatisch, oder auf ein NFS Laufwerk, oder auf einen Backup Server
  • Proxmox ist einer der besten Plattformen für zfs on Root, nutze es!
  • Wenn dir Proxmox gefällt werde Subscriber, das Forum ist auch sehr gut.
Ergänzung ()

webtaz schrieb:
Ich habe öfter gelesen dass man 1+5GB RAM pro verwaltetem TB an ZFS haben soll. 64 GB RAM würden da nur für 10TB Speicher herhalten - sprich 2-3 Platten im ZF1 ?
Andersherum 5G + 1GB pro TB. Der Host braucht ja auch Speicher. Du kannst den benötigten RAM begrenzen, was unbedingt zu empfehlen ist, es wird halt u.U. etwas langsamer.

webtaz schrieb:
Würde es Sinn machen, die Boot + Host OS Partition zu spiegeln, so dass ich - falls die m.2 ausfällt von dort booten könnte (separate Partition - auf einer der HDDs evtl??
Absolut. Alternativ verwende eine Cache NVMe, auf der du notfalls schnell Proxmox neu installieren kannst.

webtaz schrieb:
Ich habe Ideen gesehen ZFS auf LVM bzw. andersrum laufen zu lassen, das würde mir aber nur Komplexität bringen?
Vergiß das LVM Zeug. Probiere einfach ZFS.
 
Zuletzt bearbeitet:
webtaz schrieb:
kann es auch nachträglich eingerichtet werden via BootCD oder über das Debian nachinstalliert?
Korrekt. Unter Proxmox läuft auch nur ein ganz normales Debian. Es gibt halt nur keine vorgefertigte Integration um dies in der Proxmox WebGui zu erledigen aber auf der CLI geht das problemlos.
webtaz schrieb:
Es gibt ja die Möglichkeit ZFS mit Cache einzurichten, ich habe jetzt schon verschiedenes gelesen, teils lohnt sich das vor allem bei synchronen Schreibvorgängen (Datenbanken?). Würdet ihr das Empfehlen?
Jain, denn bevor SSDs als (Lese-)Cache sinnvoll sind sollte man das Maximum an RAM verbauen was möglich ist. ZFS teilt standardmäßig den Lesecache in zwei gleich große Bereiche. Die am häufigsten gelesenen Daten und die zuletzt gelesenen Daten. Kommen neue Daten in die Hälften, fällt altes raus. Bei SSDs als Lesecache würde das rausgefallene Zeug auf den SSDs landen und erst wenn es auch da raus fällt müsste man wieder von den HDDs lesen.
Es gibt auch die Möglichkeit für Schreibcaches bei ZFS aber die vorhandenen read-intensive SSDs würdest so nur unnötig schnell kaputt schreiben.
webtaz schrieb:
Ich habe öfter gelesen dass man 1+5GB RAM pro verwaltetem TB an ZFS haben soll.
Zum einen ist es andersherum wie schon geschrieben wurde also +1GB RAM pro TB ZFS Speicher und zum anderen hast du das zwar gelesen aber die Details nicht gelesen oder verstanden denn solche groben Empfehlungen decken natürlich die 'meisten' Anwendungsfälle ab. Man kann System mit ZFS auch nur mit 4-8 GB RAM betreiben wenn es ein simpler einfacher Fileserver sein soll ohne Deduplizierung und wo einem ein Lesecache völlig egal ist. Als Storage für VMs würde ich mich daran orientieren oder mehr RAM verwenden.
webtaz schrieb:
Würde es Sinn machen, die Boot + Host OS Partition zu spiegeln
Nein, macht keinen Sinn. Hast du so hohe Anforderungen an Hochverfügbarkeit? Falls ja: Nutzt du auch redundante Stromkreise, USV, Netzteile und Lüfter? Denn das sind Dinge die eher ausfallen als eine SSD. Mache Backups der Configs und wenn der Fall irgendwann eintreten sollte, stopfst eine neue kleine SSD rein, installierst Proxmox neu, spielst Config-Backups ein, mountest die restlichen HDDs und SSDs (wie auch immer du diese konfiguriert hast), Proxmox macht einen Scan, findet die VMs, startet diese wieder und du bist wieder da.
webtaz schrieb:
das würde mir aber nur Komplexität bringen?
Korrekt.
webtaz schrieb:
Momentan kann ich nur eine VG pro Platte erstellen
Korrekt, Sonderfälle mal ignoriert kann eine Platte nur zu einer VG gehören aber eine VG kann aus mehreren Platten bestehen.
webtaz schrieb:
Verstanden habe ich es aber so, dass es auch möglich ist, VG über mehrere HDDs zu spannen = effektiv JBOD?
Korrekt und wenn eine Platte davon aussteigt, ist der Verbund futsch und du brauchst dein Backup, wie bei jedem JBOD. Hier bisschen Grundlagenwissen zu LVM: https://www.thomas-krenn.com/de/wiki/LVM_Grundlagen
webtaz schrieb:
Muss ich also im Prinzip erst das Software raid erstellen, um darauf dann eine VG zu bauen, die ich in log. Volumes einteile (und hier kann ich sehr dynamisch anpassen)?
Korrekt, das ist eine übliche Situation. Anstatt einzelne HDDs als einzelne PVs zur VG hinzuzufügen würdest du erst ein Raid aus den HDDs erstellen und das Raid dann als PV zur VG hinzufügen. Da dann die LVs erstellen und nach belieben anpassen. Wenn dich die Abkürzungen verwirren ist jetzt ein guter Zeitpunkt den verlinkten Grundlagenartikel zu lesen.
webtaz schrieb:
Ich nehme an das gibt es unter Proxmox nicht?
<Zwischenfrage> Du arbeitest an einer Uni oder einem Uni-nahen Institut und verwendest inflationär Deppenleerzeichen vor Satzzeichen. Gibt es da einen Grund? Hab ich die letzte Rechtschreibreform verpasst wo das eingeführt wurde?</Zwischenfrage>
Aber zurück zur Frage: Nein, Veeam unterstützt Proxmox nicht. VMware, HyperV, RHV, AVH und diverse Cloud-IaaS Anbieter werden unterstützt.
Was genau spricht gegen das passende Backupprodukt zum PVE, dem Proxmox Backup Server?
 
  • Gefällt mir
Reaktionen: andy_m4
  • Proxmox schreibt viele logs auf die Root Partition. Daher muß die SSD eine hohe Schreiblast vertragen.
Demnach müsste ja die Root Partition eigentlich auf eine der 2,5" SSDs, wenn ich mich recht entsinne, vertragen die mehr Schreibvorgänge? Bzw.

0x7c9aa894 schrieb:
Die brauchst Speicher für die VMs, das können die gut die 2xSSDs sein. Power Loss Protection ist empfehlenswert
Wie würde ich die als Speicher einrichten? Also ZFS/LVM/...?
  • Das ZFS kann man z.B. bei den HDDs verwenden: Empfehlung RAID10; Die Daten kann man entweder über NFS an eine KVM, oder über Bind-Mount an einen LXC weiterreichen.
Ich habe zum Testen mal ein ZFS1mit 4 Platten angelegt, aber wenn ich ZFS als Storage einbinde, kann ich darauf ja erstmal nur Disk-Images und Container speichern.

Wenn ich jetzt aber ISOs (Installer usw.) oder sonstige Daten (backups = vzdumps?) dort ablegen möchte ?
ISOs wären ja zur Verwendung im PVE, Backups auch, sonstige Daten eher als Freigabe

0x7c9aa894 schrieb:
Absolut. Alternativ verwende eine Cache NVMe, auf der du notfalls schnell Proxmox neu installieren kannst.
Was genau wäre eine Cache NVMe? Eine der 2TB ? Die in ZFS als L2ARC bzw. ZIL/LOG dient bis etwas geschieht und dann entreiße ich sie dem ZFS? (Ich nehme an das geht nicht über die PVE GUI)
Dann würde ich die andere SSD als "schnellen Speicher" einbinden? Auch als ZFS (single drive?)

Aber worauf spiegele ich dann? Bzw. wie würde ich die 2,5" einbinden um darauf zu spiegeln? Physische Partitionen spiegeln und dann den restlichen Platz als LVM ?

0x7c9aa894 schrieb:
Andersherum 5G + 1GB pro TB. Der Host braucht ja auch Speicher. Du kannst den benötigten RAM begrenzen, was unbedingt zu empfehlen ist, es wird halt u.U. etwas langsamer.
Oh, dann käme das ja doch in Frage.


Ergänzung ()

snaxilian schrieb:
Nein, macht keinen Sinn. Hast du so hohe Anforderungen an Hochverfügbarkeit? Falls ja: Nutzt du auch redundante Stromkreise, USV, Netzteile und Lüfter? Denn das sind Dinge die eher ausfallen als eine SSD. Mache Backups der Configs und wenn der Fall irgendwann eintreten sollte, stopfst eine neue kleine SSD rein, installierst Proxmox neu, spielst Config-Backups ein, mountest die restlichen HDDs und SSDs (wie auch immer du diese konfiguriert hast), Proxmox macht einen Scan, findet die VMs, startet diese wieder und du bist wieder da.
Also ich hatte jetzt tatsächlich mal die Möglichkeit den "Serverraum" (wie ich dachte) zu besichtigen. Rechenzentrum trifft es schon eher, dort steht eine USV für die komplette Anlage (mehrere Reihen an Serverracks), CO2 Löschanlage, Lüftung durch den Boden usw.
Also Stromkreise und Netzteile sind redundant, ein ausgefallener Lüfter (Raum oder Server?) könnte ein Problem werden - ich kann dort nur Desktopsysteme vergleichen.

Mein Gedanke geht in die Richtung, dass ich Remote von einer anderen Platte booten könnte. Ich habe aber keinen Zugang zum Serverraum selbst, also könnte es durchaus vorkommen dass bei einem Ausfall dann Tage vergehen, bis ich die SSD Austauschen könnte.
snaxilian schrieb:
<Zwischenfrage> Du arbeitest an einer Uni oder einem Uni-nahen Institut und verwendest inflationär Deppenleerzeichen vor Satzzeichen. Gibt es da einen Grund? Hab ich die letzte Rechtschreibreform verpasst wo das eingeführt wurde?</Zwischenfrage>
Das liegt tatsächlich eher daran, wie ich meine Forenbeiträge schreibe - über Stunden hinweg und parallel beim Einlesen und Testen (und all den anderen Sachen, die dazwischen kommen). Zu oft auch Beiträge an einem Tag geschrieben und am nächsten erst abgeschickt (siehe vor dem #4 vor dem Merge).
Aber keine Sorge, wenn ich das Institut repräsentiere, schaut das besser aus. Aber ich verstehe, dass es auch im Forum unhöflich ist - ich werde mich bemühen, sauberer zu schreiben.
Wenn ich jetzt meinen Beitrag nochmal lese, merke ich auch, dass ich einige Sätze unbeendet gelassen habe. Leerzeichen vor Satzzeichen habe ich aber keine ganze Handvoll gefunden.


Das ist jetzt schon wieder sehr viel Text. Konkrete Fragen die für mich noch konkret offen sind:

1. Wie die 2,5" SSDs einbinden (also Partitionierung/Filesystem)?
2. Auf ZFS, wie Speicher (Storage im PVE) einbinden, der auch "andere Daten" aufnehmen können soll?
Eine Fileserver VM/CT, dem eine Disk auf dem ZFS zugefügt wird, und in dem dann konkret formatiert und dem PVE wieder als Storage hinzugefügt werden kann? (Macht diese Art Loop Sinn?)
Sollte ich dort dann für "neue eigenständige Freigaben" zusätzliche Disks hinzufügen? Oder die Größe der Vorhandenen anpassen? Unter "Resize Disk" sehe ich momentan nur die Möglichkeit diese zu vergrößern
 
Zuletzt bearbeitet:
webtaz schrieb:
aber wenn ich ZFS als Storage einbinde, kann ich darauf ja erstmal nur Disk-Images und Container speichern.
Nein, wie kommst du darauf? Doku sagt eindeutig: Jede Art von file level based Storage kann jede Art von Daten (templates, vdisks, Backups, ISOs, usw.) halten. Vorausgewählt ist ggf. Disk-Images und Container aber der Rest lässt sich garantiert nachträglich dafür aktivieren. Im Zweifel einfach ein zweites Dataset auf dem ZFS Pool anlegen für die anderen Contenttypes wenn du trennen möchtest/willst/sollst.
webtaz schrieb:
1. Wie die 2,5" SSDs einbinden (also Partitionierung/Filesystem)?
Das kommt auf deine Anforderungen an. Wenn du nicht zeitnah bei einem Defekt tauschen kannst und Redundanz willst dann entweder ein klassisches Raid 1 oder einen ZFS Mirror. Darauf dann die VMs und Container packen. Für ISOs oder Templates braucht mein keinen teuren SSD Speicher, das wäre mMn Verschwendung.
webtaz schrieb:
2. Auf ZFS, wie Speicher (Stprage im PVE) einbinden, der auch "andere Daten" aufnehmen können soll?
Eine Fileserver VM/CT, dem eine Disk auf dem ZFS zugefügt wird, und in dem dann konkret formatiert und dem PVE wieder als Storage hinzugefügt werden kann? (Macht diese Art Loop Sinn?)
Nein. Du hast jetzt schon Probleme weil Proxmox dir kein Raid anbietet und du dies auf der CLI erledigen möchtest und willst dann dein Setup dermaßen mit Komplexität überladen? Sorry wenn das jetzt hart klingt aber du hast keine wirkliche Ahnung was du da macht so á ja "Jugend forscht" was vollkommen okay ist und irgendwann auch zum Ziel führen mag aber dann solltest du darauf niemals produktive Daten ablegen.
Halte dein Setup so simpel wie möglich denn im Zweifel bist du mal irgendwann krank/Urlaub/gefeuert und jemand anderes muss verstehen was du da zusammen gestümpert hast^^ Außerdem erhöhst du mit unnötiger Komplexität den Wartungsaufwand für dich selbst und ich spreche aus Erfahrung: Das ist etwas was man definitiv vermeiden will.
Wenn du also irgendwelche Daten ablegen willst dann würde ich es wie folgt lösen:
Auf den SSDs eine kleine VM ablegen, SMB oder NFS als Serverdienst dort wie gewünscht installieren und konfigurieren, auf den HDDS, also dem aktuell angelegten raidz1, legst eine zweite virtuelle Disk an, die du der SMB-oder-NFS-VM zuweist und fertig ist die Sache.
Alles andere ist zwar technisch möglich aber verkompliziert die Sache nur unnötigerweise.

webtaz schrieb:
Sollte ich dort dann für "neue eigenständige Freigaben" zusätzliche Disks hinzufügen? Oder die Größe der Vorhandenen anpassen? Unter "Resize Disk" sehe ich momentan nur die Möglichkeit diese zu vergrößern
Diese 2,5 Sätze sind für niemanden außer dir verständlich. WAS genau ist dieses "dort"? Niemand sieht was du siehst und wenn du etwas beschreibst oder dich auf etwas beziehst dann ist es deine Aufgabe dein Setting so genau zu beschreiben, dass es jeder andere hier nachvollziehen kann. Weder sehen wir, was du siehst noch wissen wir was du denkst oder meinst sondern wir sehen nur was du schreibst und aus dem wird man nicht schlau, zumindest ich nicht.
Generell: Partitionen, Volumes, Dateisysteme zu verkleinern ist aufwendig und hat viele nervige Abhängigkeiten und steckt voller potentieller Fehlerquellen. Aus diesen Gründen wird das idR. vor Laien wie dir und auch oft genug vor Admins versteckt.
 
snaxilian schrieb:
Nein, wie kommst du darauf? Doku sagt eindeutig: Jede Art von file level based Storage kann jede Art von Daten (templates, vdisks, Backups, ISOs, usw.) halten.
Es ist einfach nicht auswählbar. Deshalb bin ich davon ausgegangen, dass es auch nicht dafür vorgesehen ist (bei anderem Storage kann ich an dieser Stelle mehr auswählen).

1638522629510.png

Da das aber die HDDs sind, wollte ich dort gerne die ISOs z.B. ablegen.
Deshalb kam ich dann auch auf die Idee mit dem "Looping" durch die Fileserver (=NFS/SMB) VM.
snaxilian schrieb:
Wenn du also irgendwelche Daten ablegen willst dann würde ich es wie folgt lösen:
Auf den SSDs eine kleine VM ablegen, SMB oder NFS als Serverdienst dort wie gewünscht installieren und konfigurieren, auf den HDDS, also dem aktuell angelegten raidz1, legst eine zweite virtuelle Disk an, die du der SMB-oder-NFS-VM zuweist und fertig ist die Sache.
Ich denke das deckt sich mit dem, was ich vorschlagen wollte, abzgl. des Wiederhinzufügens als Storage? (Was ich angedacht hatte, damit ich ISOs auf den ZFS-Pool bekomme)
Eine Fileserver VM/CT, dem eine Disk auf dem ZFS zugefügt wird, und in dem dann konkret formatiert und dem PVE wieder als Storage hinzugefügt werden kann? (Macht diese Art Loop Sinn?)
Aber nochmal zum Verständnis: die virtuelle Disk wird in der VM ja in der Regel auch formatiert ?

snaxilian schrieb:
Sorry wenn das jetzt hart klingt aber du hast keine wirkliche Ahnung was du da macht so á ja "Jugend forscht" was vollkommen okay ist und irgendwann auch zum Ziel führen mag aber dann solltest du darauf niemals produktive Daten ablegen.
Das ist absolut in Ordnung, mir bewusst UND sogar Teil des Projekts (gewissermaßen).

snaxilian schrieb:
Diese 2,5 Sätze sind für niemanden außer dir verständlich. WAS genau ist dieses "dort"? Niemand sieht was du siehst und wenn du etwas beschreibst oder dich auf etwas beziehst [...]
Ich habe mich tatsächlich auf genau den Satz davor bezogen. Gleicher Absatz, nur in deinem Zitat abgetrennt. Mit "dort" ist der/die Fileserver VM/CT gemeint.
Eine Fileserver VM/CT, dem eine Disk auf dem ZFS zugefügt wird, und in dem dann konkret formatiert und dem PVE wieder als Storage hinzugefügt werden kann? (Macht diese Art Loop Sinn?)

Ein bisschen weiter recherchiert:
PVE bietet es wohl nicht an, explizit ZFS Datasets zu erstellen (via GUI). Nur indirekt als Disk.
Ich habe mir jetzt ein Dataset <pool>/ISOs erstellt, und das als 'Directory' eingebunden. Für das Directory habe ich alle Auswahlmöglichkeiten.
Ich hätte wohl auch direkt den Pool (oder das Übergeordnete Dataset) als Directory einbinden können, der Unterschied liegt wohl darin, dass ich einem Dataset andere ZFS Parameter geben kann - einem Unterordner nicht.


Über Datasets habe ich auch erstmal keine Notwendigkeit für Resizing, und virt. disks für VMs werden dann eben entsprechend großzügig ausgelegt, oder falls doch nötig ersetzt.
 
Zuletzt bearbeitet:
webtaz schrieb:
Demnach müsste ja die Root Partition eigentlich auf eine der 2,5" SSDs, wenn ich mich recht entsinne, vertragen die mehr Schreibvorgänge? Bzw.
Warum? Ich habe in meinem Homelab alles auf einer NVME, das ist aber eine Data Center Version.
Ideal für Firmen ist 2xM.2 ZFS Mirror als Root, und seperate NVME für die VMs.

In deinem Fall z.B. 1xNVMe ZFS RAID0 (macht keinen Sinn aber der Proxmox Installer will das so)
Und 2xSSD ZFS RAID1 für die VMs
Die HDDs ZFS Raid10
webtaz schrieb:
Wie würde ich die als Speicher einrichten? Also ZFS/LVM/...?
ZFS siehe oben

webtaz schrieb:
Ich habe zum Testen mal ein ZFS1mit 4 Platten angelegt, aber wenn ich ZFS als Storage einbinde, kann ich darauf ja erstmal nur Disk-Images und Container speichern.
Ja das ist über das GUI leider ein bischen blöd gemacht. Du mußt ein Verzeichnis einbeinden und damit kannst Du dann alles speichern.

webtaz schrieb:
Was genau wäre eine Cache NVMe?
ZFS erlaubt es L2 Cache einzubinden. Ist nicht notwendig, aber falls du die VMs auf HDDs laufen läßt, so kann es die Performance deutlich erhöhen. Diese SSD, kann man im Notfall u.U. auch zum Booten verwenden.
 
  • Gefällt mir
Reaktionen: snaxilian
0x7c9aa894 schrieb:
In deinem Fall z.B. 1xNVMe ZFS RAID0 (macht keinen Sinn aber der Proxmox Installer will das so)
Und 2xSSD ZFS RAID1 für die VMs
Die HDDs ZFS Raid10
Fast genauso habe ich das jetzt, da Proxmox aber schon ohne ZFS auf der NVMe war (aber mit LVM), wollte ich das nicht wegformatieren. Ich denke die Systempartitionen werden wir mit Veeam sichern, die VMs und Daten mit den Onboardmitteln.
0x7c9aa894 schrieb:
Ja das ist über das GUI leider ein bischen blöd gemacht. Du mußt ein Verzeichnis einbeinden und damit kannst Du dann alles speichern.
Ja, dahin bin ich gekommen.
Blöd wird es wenn ich versuche Daten / Storage für Windows bereitzustellen... das hat mich doch überrascht wie verzwickt das ist, selbst wenn man nur "schnell kurz dreckig" etwas bereistellen möchte (Platz um vDisks von außerhalb hinzukopieren)...


0x7c9aa894 schrieb:
Warum? Ich habe in meinem Homelab alles auf einer NVME, das ist aber eine Data Center Version.
Ideal für Firmen ist 2xM.2 ZFS Mirror als Root, und seperate NVME für die VMs.
Nur von der "Haltbarkeit", nicht davon wie die Platzaufteilung Sinn macht.

Ich war tatsächlich sehr erstaunt, dass bei der m.2 NVMe schon 1% steht. (Das muss ich definitiv im Auge behalten)
 
Zuletzt bearbeitet:
webtaz schrieb:
Blöd wird es wenn ich versuche Daten / Storage für Windows bereitzustellen... das hat mich doch überrascht wie verzwickt das ist, selbst wenn man nur "schnell kurz dreckig" etwas bereistellen möchte (Platz um vDisks von außerhalb hinzukopieren)...
Der Trick ist ein Verzeichnis/Dataset von der HDD im Host freizugeben. ZFS kann nfs und smb Freigaben. Das Problem ist denn eher die Rechtevergabe.

Man kann auch FreeNAS in einer VM laufen lassen und einen HBA durchreichen.
 
0x7c9aa894 schrieb:
Der Trick ist ein Verzeichnis/Dataset von der HDD im Host freizugeben. ZFS kann nfs und smb Freigaben. Das Problem ist denn eher die Rechtevergabe.

Man kann auch FreeNAS in einer VM laufen lassen und einen HBA durchreichen.
Ich wollte auf Freigaben im Host verzichten (auch wenn schnell/ kurz/ nicht ganz sooo dreckig)
Habe zuerst einen kleinen Debian Server mit Samba getestet, aber der war nicht Teil der Windows Domäne, und ohne passwort sind Windows Clients da dann bockig -.-
Ich war kurz davor, nur dafür einen Windows Server in VM aufzusetzen.

"Man kann auch FreeNAS in einer VM laufen lassen und einen HBA durchreichen."
bezieht sich das auf einen virtuellen HBA?
Denn wenn ich den physischen durchreiche (nicht sicher ob das in meinem Fall irgendwo ging) dann kann ich vom Host nicht mehr darauf zugreifen, oder ? (Das wäre mir erstmal zu unflexibel, aber ich kann schon den Gedanken verstehen)
Also die ganze Reihe an physischen Geräten die dranhängen, sind dann nur in der VM ?
 
Wenn du die Freigabe im Host statt in einer VM machst hast du das gleiche Problem wie in der VM. Lösung wäre ein hinzufügen des SAMBA Servers ins AD, dann kann die Authentifizierung und Authorisierung der Clients durch das AD erfolgen.

Ja, HBA durchreichen würde die Geräte exklusiv für die VM zur Verfügung stellen. Wie dieser Vorschlag helfen soll frage ich mich auch irgendwie...
 
i-like-trains schrieb:
Lösung wäre ein hinzufügen des SAMBA Servers ins AD, dann kann die Authentifizierung und Authorisierung der Clients durch das AD erfolgen.
Ich schätze das ist wirklich das "einfachste" und muss ich mich mir mal Rechte geben lassen, zumindest dass ich für eine Gruppe auch Rechte vergeben darf (und eben AD Clients, nennt man das so?) hinzufügen kann.


Alternativ könnte ich wohl nur
a) ein zweites System aufbauen (zwei AD können in einem Netzwerk existieren, aber kann ein Client zu zwei gehören?)
b) alternative Freigaben ? (läuft das über NFS anders? Memo: Nachschauen
 
Zurück
Oben