Platten durch größere ersetzten...

[jedie]

Aktuell hab ich 2x 1TB SSDs Datenplatten mit ZFS in meinem Proxmox System. Die sind voll und will ich durch 2x 2TB SSDs ersetzten.

Ist kein RAID und soll auch keins werden, sondern ein einfaches JBOD (Aktuelles Backup ist per pbs angelegt)

Auf dem aktuellen zpool ist auch noch das "Input/output error (os error 5)" problem mit einer Datei, siehe: https://forum.proxmox.com/threads/backup-failed-input-output-error-os-error-5.119328/

Der Aufbau ist wie folgt:

+ zpool history
History for 'tank':
2022-06-06.17:19:31 zpool create tank sdb
...
2022-06-06.19:28:20 zpool add tank sdc
2022-06-06.19:35:24 zfs set compression=lz4 xattr=sa dnodesize=auto tank
2022-06-06.19:38:31 zfs set sharenfs=rw=192.168.6.0/24 tank/vmdata/subvol-100-disk-1
...

+ zpool list -v
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
tank       1.81T  1.74T  75.1G        -         -    56%    95%  1.00x    ONLINE  -
  sdb       932G   906G  22.3G        -         -    62%  97.6%      -    ONLINE
  sdc       932G   875G  52.7G        -         -    50%  94.3%      -    ONLINE

Jetzt Frage ich mich, wie ich das korrekt mache?!?

Mit zpool replace arbeiten, gehe ich mal von aus, oder?

Nach https://forum.proxmox.com/threads/z...replacing-with-larger-disks.84188/post-369878 zu urteilen, so:

1. die beiden 2TB dazu stöpseln
2. zpool replace tank <ID 1. alten SSD> <ID 1. neue SSD>
3. Mit zpool status -v schauen und warten bis replace fertig ist
4. zpool replace tank <ID 2. alten SSD> <ID 2. neue SSD>
5. Mit zpool status -v schauen und warten bis replace fertig ist
6. runter fahren und alte Platten ausbauen

Danach sollte alles genauso wieder da sein wie vorher?!?

 

[Dunuin]

Jetzt Frage ich mich, wie ich das korrekt mache?!?

Mit zpool replace arbeiten, gehe ich mal von aus, oder?

Das wird nicht gehen, da du ja ein Raid0 hast, also ohne Paritätsdaten. Nimmst du da eine Platte weg, wenn auch nur temporär über ein zfs replace, dann ist der Pool nicht mehr lauffähig. Da müsstest du schon den Pool zerstören und mit den neuen Disks neu erstellen.
Sofern du genug Slots und Anschlüsste hast, könntest du temporär beide Pools parallel betreiben und die Daten dann über "zfs send | zfs recv" vom kleineren auf den größeren Pools transferieren. Damit würden dann auch Snapshots und Co erhalten bleiben.

Ein Pool sollte im übrigen nicht über 80% gefüllt werden. Deiner ist ja jetzt schon bei 95%, der läuft also bereits eine weile im Panik-Modus. Also gut, dass du vergrößerst. Bit Rot Protection bietet dir ZFS mit einem Raid0 übrigens nicht.

 

[jedie]

Bit Rot Protection bietet dir ZFS mit einem Raid0 übrigens nicht.

Oh, echt nicht. Das war mir nicht klar Könnte das der Grund für https://forum.proxmox.com/threads/backup-failed-input-output-error-os-error-5.119328/ sein?!?

Ich schau mir gerade die Liste von https://pve.proxmox.com/wiki/ZFS_on_Linux#_installation_as_root_file_system an...
Könnte ich vielleicht das aufbauen:

RAIDZ-1

A variation on RAID-5, single parity. Requires at least 3 disks.

Also eine 2TB zu den zwei 1TB dazu packen und ein RAID1 mirror aufbauen lassen.
Danach die zweite 2TB dazu packen und ein RAIDZ-1 aufbauen?

Dann hab ich am Ende 3TB nutzbar und erstmal 1TB mehr als jetzt.

Wäre das möglich?

EDIT: Mit zpool add tank mirror <ID 1. neue 2TB SSD> sollte ich erstmal ein RAID1 mirror aufbauen können. Aber wie das dann erweitern mit der zweiten 2TB SSD zu einem RAIDZ-1 ?!?

 

[Dunuin]

Oh, echt nicht. Das war mir nicht klar Könnte das der Grund für https://forum.proxmox.com/threads/backup-failed-input-output-error-os-error-5.119328/ sein?!?

Ich schau mir gerade die Liste von https://pve.proxmox.com/wiki/ZFS_on_Linux#_installation_as_root_file_system an...
Könnte ich vielleicht das aufbauen:

RAIDZ-1

A variation on RAID-5, single parity. Requires at least 3 disks.

Also eine 2TB zu den zwei 1TB dazu packen und ein RAID1 mirror aufbauen lassen.
Danach die zweite 2TB dazu packen und ein RAIDZ-1 aufbauen?

Dann hab ich am Ende 3TB nutzbar und erstmal 1TB mehr als jetzt.

Wäre das möglich?

Du kannst aus einem Raid0 oder einem Mirror kein raidz1 machen. Dazu müsstest du auch wieder den Pool erst zerstören und neu aufbauen.
Was wohl möglich wäre, wenn du ein raid0 behalten aber größer haben willst, wäre aus dem Raid0 einen striped mirror (also raid10) machen. Wobei du dann zwei gestripte Mirrors aus je 2+1TB plus 2+1TB hättest. Danach könnte man die beiden 1TB disks entfernen und du hättest einen 2TB + 2TB raid0 mit 4TB Kapazität.

Raidz1 aus gemixten 1TB und 2TB disks macht nicht viel Sinn, weil von den 2TB disks dann nur 1TB nutzbar wären. Wären dann in der Summe also auch nur 2TB nutzbar und du müsstest die Blockgröße auf mindestens 16K anheben, weil es sonst wegen Padding Overhead sogar noch weniger Platz wäre, als du jetzt schon hast.

Wenn du 4TB mit Bit Rot Protection haben willst, brauchtest du schon entweder:
1.) 4x 2TB SSDs im striped mirror mit 8K Blockgröße oder
2.) 3x 2TB SSDs in raidz1 mit 16K Blockgröße.

Option 1 hätte den Vorteil das es doppelt so schnell wie Option 2 ist und kleine Writes (4K oder 8K) weniger Overhead erzeugen. Außerdem lässt sich Option 1 einfach im laufenden Betrieb über weitere Mirrors erweitern. Bei Option 2 ist das aktuell noch nicht möglich (soll aber bald kommen).

 

[jedie]

Hm

Also wäre es am besten ich kaufe noch eine 2TB um 3x2TB zu haben. Mache dann aus den drei ein RAIDZ-1 und nutzte dann zfs send ? Wobei das dann nicht online geht, oder?
Oder geht das über einen anderen weg?

Raidz1 aus gemixten 1TB und 2TB disks macht nicht viel sinn, weil von den 2TB disks dann nur 1TB nutzbar wären.

Ich dache an quasi sowas: (1TB+1TB) + 2TB + 2TB ... Aber das geht so offenbar nicht?

 

[Dunuin]

Ich dache an quasi sowas: (1TB+1TB) + 2TB + 2TB ... Aber das geht so offenbar nicht?

Soweit ich weiß nicht

Hm

Also wäre es am besten ich kaufe noch eine 2TB um 3x2TB zu haben. Mache dann aus den drei ein RAIDZ-1 und nutzte dann zfs send ? Wobei das dann nicht online geht, oder?
Oder geht das über einen anderen weg?

Das einfachste wäre du betreibst beide Pools parallel. Wenn auf dem Pool nur VMs/LXCs laufen, dann könntest du beide Pools als Storages in PVE hinzufügen, dann immer eine VM nach der anderen stoppen, über den "Move Disk" Button im WebUI die virtuellen Disks der VM vom einen auf den anderen Storage verschieben und danach die VM wieder starten. So wäre immer nur eine VM zur Zeit offline.
Wenn auf der Disk noch andere Daten in Datasets liegen, dann könnte man die inkrementell über "zfs send" zwischen den Pools kopieren.

PS: Was du bei raid0 noch hättest wäre Bit Rot Detection. ZFS kann dir dann sagen, ob deine Daten kaputt sind oder nicht. Es kann dir die kaputten Daten aber nicht wieder reparieren, da du ja keine Paritätsdaten hast.

 

[jedie]

Wenn auf dem Pool nur VMs/LXCs laufen, dann könntest du beide Pools als Storages in PVE hinzufügen, dann immer eine VM nach der anderen stoppen, über den "Move Disk" Button im WebUI die virtuellen Disks der VM vom einen auf den anderen Storage verschieben und danach die VM wieder starten. So wäre immer nur eine VM zur Zeit offline.

Das ist eine sehr gute Idee...

Also ich hab noch zwei 2TB SSDs bestellt. Dann werde ich ein normales RAID10 aufbauen, wenn sie da sind und dann mal mit dem Umziehen der VMs/LXCs probieren...

 

[RolandK]

>Du kannst aus einem Raid0 oder einem Mirror kein raidz1 machen. Dazu müsstest du auch wieder den Pool erst zerstören und neu aufbauen.

@Dunuin , wieso nicht ? geht das nicht mit zpool remove ? sollte das nicht seit 2018 möglich sein, auch von nem stripe-set ?

https://manpages.ubuntu.com/manpages/impish/man8/zpool-remove.8.html

"The specified device will be evacuated by copying all allocated space from it to the
other devices in the pool. In this case, the zpool remove command initiates the
removal and returns, while the evacuation continues in the background."

https://github.com/openzfs/zfs/commit/a1d477c24c7badc89c60955995fd84d311938486

 

[Dunuin]

@Dunuin , wieso nicht ? geht das nicht mit zpool remove ?

https://manpages.ubuntu.com/manpages/impish/man8/zpool-remove.8.html

"The specified device will be evacuated by copying all allocated space from it to the
other devices in the pool. In this case, the zpool remove command initiates the
removal and returns, while the evacuation continues in the background."

Ja, aber die Disks die jetzt das Raid0 bilden, sollen dann ja teil des raidz1 werden. Seine idee war ja das 1TB + 1TB raid0 durch zwei zusätzliche 2TB disks zu einem raidz1 zu erweitern. Das mit dem "zpool remove" der Vdevs, dass dessen Daten auf andere Vdevs verteilt werden, klappt ja denke ich nur, wenn die Disks nicht auch Teil des neuen Vdev sein sollen. Da müsste man dann ja schon zusätzlich zu den zwei 1TB Vdevs ein weiteres Raidz1 Vdev aus komplett neuen Disks dem Pool hinzufügen, um dann danach die beiden einzelnen 1TB Vdevs entfernen zu können.

Also ein...

tank
  disk1
  disk2

...zu einem...

tank
  raidz1-0
     disk1
     disk2
     disk3

...geht meine ich nicht.

Ein...

tank
  disk1
  disk2

...über ein...

tank
  disk1
  disk2
  raidz1-0
     disk3
     disk4
     disk5

...zu einem...

tank
  raidz1-0
     disk3
     disk4
     disk5

...sollte gehen, sofern Disks 3 bis 5 nicht kleiner sind als Disks 1 und 2 und man eine volblocksize wählt die hoch genug ist, weil sonst wegen Padding Overhead das raidz1 selbst bei einer Disk mehr und gleicher Diskgröße weniger nutzbare Kapazität, als das Raid0 aus Disks 1 und 2 , hätte.

 

[jedie]

Hm... Ich muß ein wenig Jonglieren... Denn ich hab nur 6xSATA Anschlüsse, alles zusammen sind es allerdings 7 Platten:

• 1x System
• 2x 1TB alten SSDs
• 4x 2TB neue SSDs

Es ist ein "alter" HP ProLiant ML10 v2 Server... Also wie genau vorgehen?!?

1. Erstmal nur zwei 2TB dazu bauen
2. Neuen RAID1 (mirroring) pool machen mit 2x2TB
3. VMs/CTs nach und nach übertragen bzw. auf neue SSDs kopieren
4. alten pool entfernen
5. alte 2x 1TB ausbauen
6. neue 2x 2TB dazu packen
7. Aus dem RAID1 ein RAID10 machen

Ich muß das auch nicht zwingend alles "online" machen. Eine Downtime ist total okay, wenn es die Sache vereinfacht. Ist ja hier nur mein kleiner Homeserver und die Kinder können auch mal auf den Minecraft Server verzichten

Ich könnte mir auch vorstellen, das ich die Proxmox SSD temporär in einen USB-Gehäuse packe und davon booten, dann könnte ich alle Platten gleichzeitig einbauen. Das wäre vielleicht auch eine gute Idee, da das schreiben schneller sein sollte und es wären viel weniger Schritt.
BIn mir allerdings nicht 100% sicher, das ich bei dem ProLiant so von USB-Platte booten kann. Aber das kann ich ja testen.

Spricht was dagegen das schon eingerichtete Proxmox temporär von USB zu betreiben? In /boot/grub/grub.cfg schaut ja alles nach eindeutigen IDs aus.

 

[Dunuin]

Hm... Ich muß ein wenig Jonglieren... Denn ich hab nur 6xSATA Anschlüsse, alles zusammen sind es allerdings 7 Platten:

• 1x System
• 2x 1TB alten SSDs
• 4x 2TB neue SSDs

Es ist ein "alter" HP ProLiant ML10 v2 Server... Also wie genau vorgehen?!?

1. Erstmal nur zwei 2TB dazu bauen
2. Neuen RAID1 (mirroring) pool machen mit 2x2TB
3. VMs/CTs nach und nach übertragen bzw. auf neue SSDs kopieren
4. alten pool entfernen
5. alte 2x 1TB ausbauen
6. neue 2x 2TB dazu packen
7. Aus dem RAID1 ein RAID10 machen

Ja, das sollte gehen.

Ich muß das auch nicht zwingend alles "online" machen. Eine Downtime ist total okay, wenn es die Sache vereinfacht. Ist ja hier nur mein kleiner Homeserver und die Kinder können auch mal auf den Minecraft Server verzichten

Ich könnte mir auch vorstellen, das ich die Proxmox SSD temporär in einen USB-Gehäuse packe und davon booten, dann könnte ich alle Platten gleichzeitig einbauen. Das wäre vielleicht auch eine gute Idee, da das schreiben schneller sein sollte und es wären viel weniger Schritt.
BIn mir allerdings nicht 100% sicher, das ich bei dem ProLiant so von USB-Platte booten kann. Aber das kann ich ja testen.

Spricht was dagegen das schon eingerichtete Proxmox temporär von USB zu betreiben? In /boot/grub/grub.cfg schaut ja alles nach eindeutigen IDs aus.

An deiner Stelle würde ich die System SSD komplett weglassen. Ansonsten hättest du deine VMs schön redundant und ausfallssicher, aber fällt dir die unredundante System SSD aus, dann ist der ganze Server offline, bis du PVE neu installiert und eingerichtet sowie Backup wieder eingespielt hast. Da würde ich PVE lieber ebenfalls auf dem 4x 2TB SSD raid10 laufen lassen. Dann ist wenigstens alles ausfallssicher.

1.) backup vom "/etc" Ordner erzeugen
2.) alte Systemdisk entfernen
3.) die 4 neuen SSDs rein
4.) PVE neu von PVE Iso installieren und ein ZFS raid10 bei der Installation auswählen
5.) Teile deiner gesicherten Configs wieder aus Backup einspielen (z.b. /etc/pve/firewall, /etc/pve/lxc, /etc/pve/qemu-server und Co)
6.) neue /etc/pve/storage.conf editieren und den Eintrag deines alten ZFSpool Storages aus der alten /etc/pve/storage.conf übernehmen, damit PVE deinen alten ZFS pool ebenfalls nutzt
7.) virtuelle Disks der VMs/LXCs über das webUi vom alten ZFS pool nach "local-zfs" verschieben

Sollte was nicht klappen bleibt ja die alte System Disk und der alte ZFS pool unangetastet, dass du immer zum Ausgangszustand zurückkehren kannst (außer natürlich du hast die virtuellen Disks schon zwischen den pools verschoben und die Checkbox gesetzt, dass da die Disks vom alten Storage entfernt werden sollen).

Mir persönlich hat ZFS dieses Jahr schon 3 mal eine System SSD in meinen Homeservern zerschossen. Also ich bin da ganz froh, dass die immer gespiegelt waren und es so weder Downtime noch Datenverlust gab. Wobei das Spiegeln der System SSDs (120GB Consumer TLC) mit ZFS bestimmt auch ein Grund warum, warum die so schnell totgeschrieben waren und ausfielen...

 

[RolandK]

du kannst doch die alten 2x1TB durch 2x2TB ersetzen (inplace, 1. ersetzen, resilver, 2. ersetzen, resilver) und dann die anderen 2x2tb als mirror anfügen
also wenn du auf der extra system disk bestehst. ansonsten würde ich es auch machen wie @Dunuin vorschlägt. wenngleich ich aber auch versthehen kann, daß man system und daten gerne getrennt hat. so kann man z.b. vom system leicht mal ein image ziehen vor einem update...

 

[jedie]

System auf eigene SSD hab ich auch, weil die Daten SSDs verschlüsselt sind, mit: zfs create -o encryption=on -o keyformat=passphrase tank/vmdata
Das würde auch auf einem RAID gehen, macht aber alles kompliziertet, oder?

 

[Dunuin]

System auf eigene SSD hab ich auch, weil die Daten SSDs verschlüsselt sind, mit: zfs create -o encryption=on -o keyformat=passphrase tank/vmdata
Das würde auch auf einem RAID gehen, macht aber alles kompliziertet, oder?

Ja, das geht auch. Habe ich vor 2 Monaten oder so gerade erst ein PVE auf einem verschlüsselten ZFS Raid1 aufgesetzt. Da schreibe ich gerade ein Tutorial zu. Das hat aber auch schon über 40 DinA4 Seiten und bin erst halb durch...also ja, ist nicht ganz unkompliziert. Grob zusammengefasst wäre das in dem Post: https://forum.proxmox.com/threads/encrypting-proxmox-ve-best-methods.88191/#post-387731

Full System Encryption wäre aber schon besser, damit du keine Daten leakst. Sonst landen da deine verschlüsselten Daten von den Daten-Disks doch wieder unverschlüsselt auf der Systemdisk. Deine Logs und dein Swap sind dann ja aktuell trotzdem unverschlüsselt, enthalten aber deine Daten, die du eigentlich verschlüsselt haben willst.

 

[jedie]

Full System Encryption wäre aber schon besser, damit du keine Daten leakst. Sonst landen da deine verschlüsselten Daten von den Daten-Disks doch wieder unverschlüsselt auf der Systemdisk. Deine Logs und dein Swap sind dann ja aktuell trotzdem unverschlüsselt, enthalten aber deine Daten, die du eigentlich verschlüsselt haben willst.

Ja, aber dann kann der Rechner nicht mehr bis zur SSD Shell hochfahren, in der ich dann das Passwort der Verschlüsselung manuell eingebe, einfach beim mounten...
Ist auch nicht das Gelbe vom Ei: Weil nach jedem Booten muß ich daran denken und muß dann die VMs manuell starten, weil dann erst die Platten von denen da sind...

 

[Dunuin]

Ja, aber dann kann der Rechner nicht mehr bis zur SSD Shell hochfahren, in der ich dann das Passwort der Verschlüsselung manuell eingebe, einfach beim mounten...
Ist auch nicht das Gelbe vom Ei: Weil nach jedem Booten muß ich daran denken und muß dann die VMs manuell starten, weil dann erst die Platten von denen da sind...

Doch kann er. Passwort muss ich einmal nach dem Boot eingeben. Entweder direkt per Tastatur über die lokale Konsole des Servers oder auch remote per SSH von einem anderen Computer aus. Das entschlüsselt dann das Root Dateisystem ("local" Storage). Erst dann bootet PVE und PVE entsperrt dann automatisch den VM storage ("local-zfs" Storage) über eine Key file, die auf dem dann entschlüsselten Root Dateisysstem liegt. PVE kann auch gleich alle VMs autostarten, da vorher bereits alles entschlüsselt ist.

Also einmal per SSH kurz das Passwort aus dem Passwort-Safe von meinem Arbeitsrechner aus copy-pasten und fertig. Komfortabler geht das kaum.

 

[jedie]

Doch kann er. Passwort muss ich einmal nach dem Boot eingeben. Entweder direkt per Tastatur über die lokale Konsole oder auch remote per SSH von einem anderen Computer. Das entschlüsselt dann den kompletten Pool. Erst dann bootet PVE und PVE kann auch gleich alle VMs autostarten, da ja schon alles entschlüsselt ist.

Hm. Das hört sich gut an. Lese ich auch gerade in https://forum.proxmox.com/threads/encrypting-proxmox-ve-best-methods.88191/#post-387731 ... Hm...

@Dunuin Die URL zur README in deinem Post stimmt nicht mehr. Könntest du mit https://github.com/openzfs/zfs/tree/master/contrib/initramfs#unlocking-a-zfs-encrypted-root-over-ssh ersetzten

https://gist.github.com/yvesh/ae77a68414484c8c79da03c4a4f6fd55 schaut auch nicht so ganz kompliziert an... Zumal ist das ersetzten so nicht ganz machen muß...

Das Praktische ist: ich hab zwei HP ProLiant ML10 v2 Server ... Von daher kann ich mit einem ganz frisch anfangen und wenn alles klappt könnte ich die VMs per WebGUI verschieben... Das werde ich mal versuchen...

 

[Dunuin]

Posts älter als 1 Monat kann man hier im Forum leider nicht mehr editieren. Ich hab dir mal eine PN geschickt mit Link zum halbfertigen Tutorial. Das hab ich noch mit PVE7.2 angefangen zu schreiben, sollte aber genau so mit PVE 7.3 klappen.

 

[jedie]

Hm. Ich kann das ohne eine extra SSD für das System wohl vergessen, denn laut https://community.hpe.com/t5/proliant-servers-ml-dl-sl/uefi-support-in-ml10-v2/td-p/6811694 hat der HP ProLiant ML10 v2 kein UEFI boot.

 

[Dunuin]

Ja, UEFI braucht man da schon, da ZFS über grub nicht von einem verschlüsselten ZFS Pool booten kann. Verschlüsseln kann man die System Disk aber trotzdem. Das habe ich vor 2 Jahren mal hier so eingerichtet. Dazu kann man ein Debian 11 installieren und beim Debian Installer ein LVM auf einem LUKS container auf einem mdadm raid anlegen. Dann das dropbear-initamfs nachinstallieren sowie das proxmox-ve Package. Dann erhält man ein LUKS-verschlüsseltes gespiegeltes PVE was über grub booten kann.
Den extra ZFS Pool für die VMs könnte man dann automatisch über ein Keyfile auf dem Root Dateisystem entschlüsseln lassen.

Aber ja, extra Disk für das System bräuchtest du dann trotzdem.