Ist das verwenden der boot disk als datastore nicht vorgesehen?

[IsThisThingOn]

Ist das verwenden der boot disk als datastore nicht vorgesehen? Ähnlich wie bei TrueNAS?

Das GUI will es mir nicht anbieten, also ist es offiziell out of spec?
Möchte keine out of spec config fahren

 

[news]

Die GUI, man du must etwas genauer sein!
Alles ist eine Sache der Konfiguration, entweder direkt über die Console des Debain 12 oder teilweise über die GUI.
Stichwort Storrage!

 

[shithead75]

Du meinst du hast nach dem Installieren keine "local-lvm" links im Tree? Ansonsten siehst du unter Disks was zur Verfügung steht, aber bei nur einer physischen bzw. logischen Platte im System liegt der "datastore" da drauf....

 

[IsThisThingOn]

Die GUI, man du must etwas genauer sein!

Ich versuche es

Wenn ich PBS auf einer einzelnen SSD installiert habe, egal ob ZFS oder ext4, kann ich kein directory erstellen, weil mir "no disks unused" angezeigt wird.
Auch der Button "Create: ZFS" zeigt mir "no disks unused".

Darum ist für mich die Frage, ob PBS das ähnlich wie TrueNAS handhabt und sagt; die boot disk wird nicht angefasst.

Du meinst du hast nach dem Installieren keine "local-lvm" links im Tree?

Ich meine PBS und nicht PVS

 

[news]

mkdir /proxmoxbs
mkdir /proxmoxbs/dataspace1
chown 33:33 /proxmoxbs/dataspace1

Und dann die den Pfad von Dataspace1 in den Proxmox Backup Server eintragen.

Aber ich würde nie eine Backup auf nur eine SSD oder HDD machen.
Mindestens ZFS Mirror

 

[IsThisThingOn]

Und dann die den Pfad von Dataspace1 in den Proxmox Backup Server eintragen.

Wie gesagt, machbar ist das alles. Die Frage ist halt eher, ist es auch offiziell supported?

Aber ich würde nie eine Backup auf nur eine SSD oder HDD machen.

Darum gehts mir nicht. Die Frage ist, muss die Boot Disk eigenständig sein wie bei TrueNAS?
Dort geht auch vieles in CLI, ich kann auch Partitionen erstellen und einen Teil für boot und der andere für L2ARC verwenden. Nur ist die halt nicht offiziell supported.

 

[Falk R.]

Wie gesagt, machbar ist das alles. Die Frage ist halt eher, ist es auch offiziell supported?

Wir sind hier nicht bei VMware wo Dinge unbedingt Supportet sein müssen. Es gibt Empfehlungen, aber machen kann man alles was technisch möglich ist.

Darum gehts mir nicht. Die Frage ist, muss die Boot Disk eigenständig sein wie bei TrueNAS?
Dort geht auch vieles in CLI, ich kann auch Partitionen erstellen und einen Teil für boot und der andere für L2ARC verwenden. Nur ist die halt nicht offiziell supported.

Es wird empfohlen, muss aber nicht. Da es in der Regel so ist, wird die beim Create Dialog nur die Auswahl weiterer Disks angezeigt.
Du kannst aber einfach auf deiner Disk einen Ordner anlegen und den als Datastore einbinden.
Du müsstest dafür nur einmal auf der CLI den Befehl mkdir bemühen, was eigentlich jeder hinbekommt.

 

[IsThisThingOn]

Wir sind hier nicht bei VMware wo Dinge unbedingt Supportet sein müssen.

Es wird empfohlen, muss aber nicht.

Danke, das reicht mir schon für meine Entscheidung. Wenn es um IT geht gehöre ich nicht zur "fuck around and find out" Fraktion.
Moderne IT ist schon kompliziert genug

Zum Beispiel hätte ich total nicht bedacht ein paar GB für root zu reservieren, damit mir nix crashed, wenn der Platz mit Backups volläuft.

 

[news]

Danke, das reicht mir schon für meine Entscheidung. Wenn es um IT geht gehöre ich nicht zur "fuck around and find out" Fraktion.
Moderne IT ist schon kompliziert genug

Zum Beispiel hätte ich total nicht bedacht ein paar GB für root zu reservieren, damit mir nix crashed, wenn der Platz mit Backups volläuft.

Guten Morgen, dann ist aber dein Gedanke in die IT falsch. Wenn ich mir ein ZFS dataset anlegen, habe ich doch immer die Möglichkeit auch ein Quota, also eine Begrenzung des maximal nutzbaren Speicher Bereich, festzulegen. Und so gehört sich das halt auch zu managen, wie viel Platz habe ich denn auf dem System.

 

[IsThisThingOn]

Morgen @news

Wenn der offizielle Weg A ist, ich den Weg B nehme, dabei aber potentielles Problem C verursache, mir Problem C noch nicht mal bewusst ist, kann es schief gehen.

Viele schlaue Leute haben sich vermutlich viele schlaue Gedanken gemacht und sich bewusst für den weniger komfortablen Weg A anstelle von Weg B entschieden, eben genau weil sie potentielles Problem C (und D und E und F) im Auge hatten.

Ein Beispiel: Proxmox empfiehlt mirror anstelle von RAIDZ. Ich meine ich bin schlauer oder dies treffe auf mich nicht zu. Ich lerne wie ZFS funktioniert, was es mit volblocksize und pool geometry auf sich hat. Urplötzlich verstehe ich woher die Empfehlung kommt.

Ich persönlich bin darum grosser Fan mich an die Empfehlungen der Hersteller zu halten. Das kann aber natürlich jeder so handhaben wie er will.

 

[Falk R.]

Morgen @news

Wenn der offizielle Weg A ist, ich den Weg B nehme, dabei aber potentielles Problem C verursache, mir Problem C noch nicht mal bewusst ist, kann es schief gehen.

Viele schlaue Leute haben sich vermutlich viele schlaue Gedanken gemacht und sich bewusst für den weniger komfortablen Weg A anstelle von Weg B entschieden, eben genau weil sie potentielles Problem C (und D und E und F) im Auge hatten.

Ein Beispiel: Proxmox empfiehlt mirror anstelle von RAIDZ. Ich meine ich bin schlauer oder dies treffe auf mich nicht zu. Ich lerne wie ZFS funktioniert, was es mit volblocksize und pool geometry auf sich hat. Urplötzlich verstehe ich woher die Empfehlung kommt.

Ich persönlich bin darum grosser Fan mich an die Empfehlungen der Hersteller zu halten. Das kann aber natürlich jeder so handhaben wie er will.

Grundlegend ganz guter Ansatz. Man kann aber auch mit RaidZ arbeiten, wenn man verstanden hat was Passiert, und wie man bestimmte Effekte beeinflussen kann oder mit einberechnen muss. Für den Otto Normalverbrauchen, ohne Spezialwissen sind die Empfehlungen gemacht um sich nicht alles Wissen aneignen zu müssen.

 

[IsThisThingOn]

Volle Zustimmung. Nur bin ich ein Otto Normalverbraucher und viel zu doof, um die möglichen negativen Effekte überhaupt einzuschätzen

So rein Gefühl mässig (aber Gefühle sind dabei natürlich Schwachsinn) fürchte ich eine out of spec config mehr als einen Festplattenausfall.
Habe mehr Angst vor unbekannten negativen Effekten als vor einem SSD Ausfall.
Wisst ihr was ich meine?

Ich mach mal ein Beispiel. Früher, vor ZFS, vor schnellem Internet und Cloud Storage, war es doch irgendwie hipp, ein mirror RAID (nicht ZFS) für seinen PC zuhause zu verwenden. Rückblickend muss ich sagen, wahrscheinlich haben 10 mal so viele Personen Daten verloren wegen eines RAID User errors, verglichen mit none RAID usern, denen tatsächlich Festplatten gestorben sind

Spoiler: Meine Setup Überlegungen

Um es also etwas spezifischer zu beschreiben:
Ich möchte ein PBS für mehrere Vereine einrichten. Dabei schweben mir unterschiedliche configs vor.

Config 1, *TrueNAS style*
Die boot disk schaue ich als unwichtig an. Kann ja alles per simplen Knopfdruck sichern. Bei TrueNAS ein wenig umständlicher, indem /etc/proxmox-backup gesichert wird. Darum ist es auch egal, wenn die boot disk nicht redundant ist.
Als Unterkategorie von dieser config gäbe es dann noch storage.

1.1
Die Wahrscheinlichkeit einer einzelnen Platte auszufallen und gleichzeitig auch noch wirklich ein Backup zu benötigen ist winzig. Darum fahre ich nicht redundant. Für storage eine grosse SSD. Dann wäre ich bei insgesamt zwei SSDs.

1.2
Daten redundant
Zwei grosse SSDs als mirror für boot und das gleiche nochmals für Daten. Dann wäre ich bei insgesamt drei SSDs.

Config 2, *PVE style*
Boot disk gleichzeitig auch für die Daten. Installiere also PBS darauf und erstelle händisch Datastores.
Wo ich diese Datastores ablege ist fast egal, da ja sowieso alles auf dem einen rpool liegt.
Dennoch möchte ich möglichst nahe beim PBS naming und Pfade bleiben.
Das Dataset erstelle ich mit zfs create -o mountpoint=/mnt/datastore/backup rpool/backup. Damit mir auch ganz sicher nicht boot überläuft, reserviere ich auch noch 40GB damit: zfs set reservation=40G rpool/ROOT

2.1
Eine grosse SSD für storage und boot. Dann wäre ich bei insgesamt einer SSDs.

2.2
Zwei grosse SSDs als mirror. Dann wäre ich bei insgesamt zwei SSDs.

Config 3, *Nummer sicher*
Nix riskieren. Boot ein ZFS mirror, storage ein ZFS mirror.


Wie ich die einzelnen Configs bewerte:

1.1 Günstig, nur storage riskant

1.2
Einfach, nicht riskant wenn backup von config gemacht wird. Eine SATA SSDs für boot und zwei NVME SSDs für Daten

2.1
Ist eine mega coole Variante, da diese selbst mit einem Intel NUC oder ähnlich realisierbar wäre.

2.2
Storage mässig auf der sicheren Seite, config riskant.

3. wäre vermutlich die schönste Variante, allerdings auch ziemlich Hardware intensiv. Liesse sich aber realisieren mit zwei SATA SSDs für boot und zwei NVME SSDs für Daten.


Ich persönlich finde 2.2 riskanter als 1.1. Mit der gleichen Begründung wie oben, analog den alten BIOS RAIDs.

Aber vielleicht überdramatisiere ich auch den getrennten Boot Speicher weil ich stark von TrueNAS geprägt bin und es ist in der Praxis gar nicht so wichtig.

 

[Falk R.]

Also wenn du die OS Disk nicht redundant machst, ist das OK, aber im Worst Case musst du mal eben neu installieren, bevor du restoren kannst.

Das Setup mit 2 großen SSDs habe ich auch bei Kunden, da kommt ein ZFS Mirror drauf und ein Dataset für die Backups. Bei ZFS solltest du eh immer eine Quota setzen und mit dem kleinen Dataset fürs OS, nimmt man halt 100G extra von der Quota weg.

 

[IsThisThingOn]

Wow, habe mir die Preise für SSDs angeschaut, das ist ja echt Wahnsinn. 120GB SSD für 9.90Fr!
Das ist ja ein Witz, selbst meine Mittagessen heute war teurer!

Glaube ich nehme als boot zwei billige SATA SSDs und für den Storage zwei anständige NVME drives.

 

[Falk R.]

Wow, habe mir die Preise für SSDs angeschaut, das ist ja echt Wahnsinn. 120GB SSD für 9.90Fr!
Das ist ja ein Witz, selbst meine Mittagessen heute war teurer!

Glaube ich nehme als boot zwei billige SATA SSDs und für den Storage zwei anständige NVME drives.

Aber bitte keine zu billigen, Preiswert ist OK. Ich nutze z.B. gern die Huawei NVMe, da bekommst du extrem viel Leistung fürs Geld.
Spoiler

 

[MarkusKo]

Aufpassen, NVMe mit PLP gibts nicht so viele und die Huawei sind U.3 NVMe, die passen nur in Server

 

[IsThisThingOn]

PLP ist IMHO für PBS überbewertet.
Als SLOG für PVE sehe ich enorm viel Potential, aber für PBS erschliesst sich mir der Sinn nicht so ganz. Klar, die ca. 5s Wartezeit am Ende eines Backups fallen weg. Aber sonst?

 

[MarkusKo]

PLP wäre für ZFS wichtig - oder für ein ZFS Special Device falls du einen HDD Pool beschleunigen willst.

 

[IsThisThingOn]

PLP beschleunigt aber nur sync writes. Habe ich aber nicht mit PBS, ausser 5s nach dem Backup.

 

[Falk R.]

PLP beschleunigt aber nur sync writes. Habe ich aber nicht mit PBS, ausser 5s nach dem Backup.

Stimmt nicht, du beschleunigst jeden Write. Im HomeLab brauchst du das nicht unbedingt außer beim Special Device.
Im Unternehmenseinsatz willst du nicht ohne PLP arbeiten.