Proxmox Container als NAS mit Intel Nuc8i5

[jawr]

Hallo zusammen,

ich bin ganz neu im Bereich Proxmox und weiß nicht so richtig wie ich am besten ein NAS umsetze. Ich habe einen NUC8i5 mit aktueller Proxmox VE Installation. Bislang läuft eine Windows-Maschine für das HomeOffice.

Jetzt würde ich gerne ein NAS mit Debian umsetzen, dazu habe ich mir einen Debian Container in Version 10 heruntergeladen und diesen installiert. Da diese Installation wie gesagt u.a. als NAS dienen soll, habe ich die Platte mit ca. 1.2 TB dimensioniert.

Jetzt ist mir nicht klar, ob das so clever ist. Es geht dabei um das Backup der Maschine. Möchte ich nun ein Backup machen, müsste ich ja immer die ganzen 1.2 TB sichern. Eigentlich will ich aber nur die Maschine sichern, da ich die Daten über rsync auf 2 andere Geräte im Netzwerk sichere.

Wie könnte ich es so einrichten, dass die Maschine klein gehalten wird und die Daten nur irgendwie da reinmounte?

Im NUC ist bislang nur eine 2.5" SSD mit 2 TB verbaut.

Über Ideen oder Anregungen wäre ich sehr dankbar.

Gruß,

jawr

 

[Dunuin]

Naja, wenn es nur um das ausschließen der NAS-Daten geht könntest du ein winziges Laufwerk für Linux machen und dann ein Verzeichnis für die Daten per Bind-Mount in den LXC durchreichen. Proxmox sichert soweit ich weiß keine extern eingebundenen Ordner mit.

Oder du installierst dir direkt auf dem Proxmox-Host einen SMB-Server, dann brauchst du den LXC erst garnicht. Proxmox selbst ist ja quasi ein Debian.

 

[jawr]

Hi,

bei beidem habe ich ein Verständnisproblem, wenn ich mir die aktuelle Belegung ansehe:

df -h
Filesystem            Size  Used Avail Use% Mounted on
udev                  7.8G     0  7.8G   0% /dev
tmpfs                 1.6G  109M  1.5G   7% /run
/dev/mapper/pve-root   94G  8.5G   81G  10% /
tmpfs                 7.8G   46M  7.8G   1% /dev/shm
tmpfs                 5.0M     0  5.0M   0% /run/lock
tmpfs                 7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/fuse              30M   16K   30M   1% /etc/pve
tmpfs                 1.6G     0  1.6G   0% /run/user/0

ist mir ehrlich gesagt unklar, wo man ganzer Plattenspeicher ist von 2 TB. Wo könnte ich meine Daten (bislng ca. 800GB) ablegen?

Gruß,

jawr

 

[Dunuin]

Was sagt denn lsblk?

 

[jawr]

Moin,

hier die Ausgabe

root@pve:~# lsblk
NAME                         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                            8:0    0  1.8T  0 disk
├─sda1                         8:1    0 1007K  0 part
├─sda2                         8:2    0  512M  0 part
└─sda3                         8:3    0  1.8T  0 part
  ├─pve-swap                 253:0    0    8G  0 lvm  [SWAP]
  ├─pve-root                 253:1    0   96G  0 lvm  /
  ├─pve-data_tmeta           253:2    0 15.8G  0 lvm 
  │ └─pve-data-tpool         253:4    0  1.7T  0 lvm 
  │   ├─pve-data             253:5    0  1.7T  0 lvm 
  │   ├─pve-vm--100--disk--0 253:6    0   47G  0 lvm 
  │   └─pve-vm--101--disk--0 253:7    0   10G  0 lvm 
  └─pve-data_tdata           253:3    0  1.7T  0 lvm 
    └─pve-data-tpool         253:4    0  1.7T  0 lvm 
      ├─pve-data             253:5    0  1.7T  0 lvm 
      ├─pve-vm--100--disk--0 253:6    0   47G  0 lvm 
      └─pve-vm--101--disk--0 253:7    0   10G  0 lvm

Gruß,

jawr

 

[Dunuin]

Deine ganze Kapazität steckt in pve-data was aber keinen Mountpunkt hat und daher nicht von "df -h" aufgelistet wird weil nicht eingehängt.

 

[jawr]

Ok, wie kann ich denn diesen Teil mounten um meine Daten da abzulegen?

So funktioniert es nicht :

root@pve:/mnt# mount /dev/sda3 /mnt/data/
mount: /mnt/data: unknown filesystem type 'LVM2_member'.

Gruß,

jawr

 

[Dunuin]

Da musst du dich mal in LVM einlesen. Du kannst nicht einfach die Partition sda3 mounten da auf dieser das LVM sitzt, auf dem die VG und in der dann die LVs. Ggf dann z.B. ein neues LV erstellen und das einhängen. pve-data nutzt Proxmox um dort virtuelle Festplatten abzulegen. Ich glaube das soll man auch gar nicht selbst mounten um dort Daten abzulegen.

 

[jawr]

Ok,

ich dachte nach deiner Antwort im ersten Post:

und dann ein Verzeichnis für die Daten per Bind-Mount in den LXC durchreichen

das wäre irgendwie ganz einfach zu realisieren . Scheint wohl doch ein größeres Unterfangen zu sein.

Gruß,

jawr

 

[jawr]

Ich finde da auch kein Tutorial dazu, bin ich der Einzige der das so machen will bzw. wie machen andere das mit einem NAS und Proxmox?

Gruß,

jawr

 

[Dunuin]

Naja, der beste Weg wäre einen extra HBA kaufen und den in eine VM per PCI Passthrough durchreichen. An den HBA dann extra Laufwerke die nur für die NAS Daten da sind und in der VM ein NAS-Betriebssystem installieren. Dann hätte mein einen virtuellen NAS Server der aber physisch auf die Laufwerke direkt zugreifen kann, ohne all die Virtualiserung dazwischen. Das wird ja aber mit einem NUC nichts, da dieser weder Platz für die Laufwerke noch einen elektrischen 8x PCIe Slot für so einen HBA hätte.

Andere Alternative ohne viel Overhead wäre den Proxmox-Server selbst als NAS zu nutzen, indem man sich entsprechende LVs oder Partitionen für die Daten anlegt, Samba nachinstalliert, User und Gruppen erstellt und dann die Shares einrichtet. Muss man allerdings alles manuell per CLI einrichten und ist alles recht umständlich.

Simpel aber anfälliger und ineffizienter wäre es einfach eine VM anzulegen und dort alles auf virtuelle Festplatten zu speichern.

Hast du das mal angeguckt wegen LVM? Da hast du schon ein paar Beispiele.

 

[jawr]

Dann wird es wohl der Weg mit der großen VM. Habe aktuell keine Zeit mich damit zu beschäftigen, wie ich LV's oder Partitionen anlege. Und ich habe keine Lust mir meine ganze Proxmox Installation zu zerschießen wenn ich nicht weiß wie das geht . Danke dir.

Gruß,

jawr

 

[Dunuin]

Wenn es unbedingt eine VM sein soll kannst du auch 2 virtuelle Festplatten anlegen. Eine kleine für dein OS und eine große für deine NAS-Daten. Bei der großen entfernst du dann bei der Erstellung den Haken für Backups. Dann sollte Proxmox die virtuelle Festplatte mit den NAS-Daten eigentlich vom Backup ausschließen.

 

[jawr]

Moin,

hast du dafür ein Tutorial?

Gruß, jawr

 

[Dunuin]

Da braucht es eigentlich kein Tutorial für. Du erstellst halt normal eine VM, wählst die virtuell Festplatte so in der Größe, dass das für dein NAS Betriebsystem reicht und bevor du die VM startest fügst du dann noch eine zweite virtuelle Festplatte hinzu. Also im GUI "Datacenter->DeinNodeName->DeinVMName->Hardware->Add->Harddisk" und da dann dort die Checkbox "Backup" nicht setzen. Dann installierst du dein NAS-Betriebssystem deiner Wahl (OpenMEdiaVault oder ähnliches) auf die kleine virtuelle HDD und nutzt die Große nur für deine Shares.

 

[jawr]

Danke, das werde ich mal probieren.

 

[jawr]

So, habe das jetzt mal so gemacht. Im Grunde ist das jetzt genau so wie ich das haben wollte. Vielen Dank für deine Geduld und deine Hilfe.

Gruß,

jawr

 

[Dunuin]

Ist halt nur leider nicht sehr effizient. So hast du da noch die Virtualisierung zwischen, ggf. Verluste durch Padding, höhere Write Amplification was die SSD Lebenszeit verkürzt etc. Sollte eigentlich zuverlässig laufen, aber wenn du doch mal Zeit hast dich etwas mehr mit dem Thema zu beschäftigen, dann wäre es nicht verkehrt das doch noch einmal mit einem LV und SMB direkt auf dem Proxmox-Host zu versuchen, damit man sich die VM und all den Virtualisierungsoverhead sparen kann.

Und nicht vergessen regelmäßig die Smart-Werte anzugucken, besonders wenn alles nur auf einer SSD ohne Ausfallsicherheit läuft. Das ist ja vermutlich eine Consumer-SSD und die können wegen der erhöhten Write Amplification ziemlich schnell kaputt gehen. Die halten dann entweder Jahre oder auch nur Monate, je nachdem wie da dein Setup und keine Workloads aussehen.
Also besser einmal im Monat oder so smartctl -a /dev/sda ausführen und gucken, wieviel TB die SSD da so geschrieben hat und wann die TBW erreicht sein werden.

 

[jawr]

OK. Gibt es denn grundsätzlich Dinge die man in Proxmox beachten/einstellen sollte wenn man eine SSD nutzt?

 

[Dunuin]

Generell sind Consumer SSDs nicht die beste Idee im Server-Umfeld. Die sind für solche Workloads nicht ausgelegt und können sich sehr schnell kaputtgeschrieben haben. Je komplizierter dein Dateisystem ist, wie z.B. ZFS, qcow2 oder andere Copy-On-Write-Dateisysteme und je mehr du virtualisierst, desto höher wird deine Write Amplification. Bei mir ist das z.B. eine Write Amplification von Faktor 7 von dem Dateisystem in den VMs bis runter zu den echten SSDs auf dem Host. 30GB/tag wollen die VMs speichern und um das auf die SSD zu bekommen müssen 210GB/tag auf die SSDs geschrieben werden. Und dann haben meine SSDs auch selbst intern noch einmal eine Write Amplification von grob Faktor 3. Dann werden die 210GB/tag Writes auf die SSD schon zu 630GB/tag, welche auf den Flash der SSDs geschrieben werden. Der Flash nutzt sich beim Schreiben ab und die SSD ist irgendwann kaputt. Daher ist für jede SSD ein TBW-Wert (Terrabyte Written) angegeben, wo dir der Hersteller garantiert, wieviel auf den Flash geschrieben werden kann, bis dieser kaputt ist. Hat deine SSD ein TBW von 300TB, dann ist die Garantie erlöschen, sobald du 300TB auf den Flash der SSD geschrieben hast. Und wenn du eine solche Write Amplification wie ich hast, wo 30GB Writes in der VM zu 630GB auf der SSD werden, dann ist dieser Wert sehr schnell erreicht. Hätte ich dann noch viele Sync Writes in der Workload, dann würden die 630GB/tag sogar noch zu 1260GB/tag werden, da bei mir ZFS dann alles doppelt schreiben müsste. Dann willst du eigentlich nur 30GB in der VM schreiben und auf dem Flash der SSD werden 1260GB geschrieben. Dann wäre so eine SSD mit 300TBW nach frühestens 238 Tagen kaputt, obwohl man eigentlich nur lächerliche 30GB am Tag schreiben wollte.

Nach Möglichkeit sollte man da also versuchen die Write Amplification so klein wie möglich zu halten und so wenig wie möglich auf die SSDs zu schreiben. Das kann man z.B. durch:

• Nutzung einer Enterprise Grade SSD, wo die interne Write AMplification kleiner ist
• Vermeidung von Sync Writes, was aber auf die Datensicherheit geht
• Erhöhung des ZFS TXG Timeouts, was aber die SSD verlangsamt und auf die Datensicherheit geht
• Vermeidung von Virtualisierung soweit wie möglich, z.B. indem man Dienste im LXC oder direkt auf dem Host nutzt oder im Falle einer VM die SSD physisch direkt über PCI Passthrough in die VM durchreicht
• man die Partitionen so einrichtet, dass diese optimal ausgerichtet sind
• man Kompression nutzt
• die Blöckgrößen möglichst passend gewählt wurden, dass da möglichst wenig durch schlechtes Padding verloren geht
• man bei Linux z.B. "/tmp" in ein tmpfs- oder ramfs-Dateisystem mounted, damit temporäre Daten nur im RAM landen und garnicht erst auf die SSDs geschrieben werden müssen
• atime und diratime nach Möglichkeit überall deaktiviert werden, damit eine Leseoperation auf der SSD nicht immer eine Schreiboperation verursacht
• Optimierung aller Anwendungen. Besonders z.B. das Caching von Datenbanken wie MySQL, dass da statt vielen kleinen nur wenige große Schreiboperationen durchgeführt werden
• man unnötige Schreibvorgänge unterbindet. Da muss man sich dann z.B. fragen, ob man wirklich alle Logs braucht oder diese nicht lieber etwas restriktiver macht, damit nicht dutzende oder hunderte von Logzeilen pro Sekunde auf die SSD geschrieben werden müssen
• man Discard/Trim verwendet, damit sich die SSD besser für das Wear Leveling organisieren kann
• man nicht die volle SSD partitioniert, sondern z.B. 20% unpartitioniert lässt, damit das Wear Leveling etwas mehr Reserve hat und die SSD länger hält. Die meisten SSDs können da Over-Provisioning für mehr Lebenszeit nutzen. Aber nicht ganz so wichtig, solange du Discard benutzt und die SSD nie ganz vollschreibst.