[SOLVED] ZFS Verhalten bei Windows-Volume verschlüsselt mit Bitlocker

[SimonR]

Auf einer Winserver 2019 VM gibt es ein Datenvolume mit exakt 1 TB Speicher.


Auf dem ZFS Pool war vorher die Standard-Komprimierung an. Unnütz, wenn ich Bitlocker nutze innerhalb Windows, aber das sollte nicht das Problem sein.

Wenn ich nun auf dem Windows-Volume die Verschlüsselung starte mit XTS-AES256, volle Datenträgerverschlüsselung, wird das 1 TB Volume im ZFS auf einmal 1,4 - 1,5 TB gross.



Warum ist das so? Wie kann ich das abstellen?

Löst ein Scrub das Problem?

Warum nimmt das 1TB-Volume auf einmal 150% Platz ein?

Auf diesem Host ist das egal, aber auf dem Replikationspartner ist weniger Platz im Pool und da wäre ich mit 1,5 TB bei 99% Speicher, ist also nur eine Frage der Zeit, bis die Replikation platzt und 99% auf einem ZFS Pool sind auch nicht unbedingt empfohlen.

 

[H4R0]

Poste mal "zfs list -t snapshot | grep 100", "zpool status" und "zfs get all rpool/vm-100-disk-1" im quote tag.

 

[SimonR]

Poste mal "zfs list -t snapshot | grep 100", "zpool status" und "zfs get all rpool/vm-100-disk-1" im quote tag.

Snapshots gibts keine davon. Und beim volsize werden auch nur 1000G angezeigt.

root@pveham1:~# zfs list -t snapshot | grep 100
root@pveham1:~#
root@pveham1:~# zfs get all rpool/vm-100-disk-1
NAME PROPERTY VALUE SOURCE
rpool/vm-100-disk-1 type volume -
rpool/vm-100-disk-1 creation Thu Oct 15 3:30 2020 -
rpool/vm-100-disk-1 used 1.41T -
rpool/vm-100-disk-1 available 1.01T -
rpool/vm-100-disk-1 referenced 1.41T -
rpool/vm-100-disk-1 compressratio 1.00x -
rpool/vm-100-disk-1 reservation none default
rpool/vm-100-disk-1 volsize 1000G local
rpool/vm-100-disk-1 volblocksize 8K default
rpool/vm-100-disk-1 checksum on default
rpool/vm-100-disk-1 compression off inherited from rpool
rpool/vm-100-disk-1 readonly off default
rpool/vm-100-disk-1 createtxg 4689301 -
rpool/vm-100-disk-1 copies 1 default
rpool/vm-100-disk-1 refreservation none default
rpool/vm-100-disk-1 guid 7707766002537664049 -
rpool/vm-100-disk-1 primarycache all default
rpool/vm-100-disk-1 secondarycache all default
rpool/vm-100-disk-1 usedbysnapshots 0B -
rpool/vm-100-disk-1 usedbydataset 1.41T -
rpool/vm-100-disk-1 usedbychildren 0B -
rpool/vm-100-disk-1 usedbyrefreservation 0B -
rpool/vm-100-disk-1 logbias latency default
rpool/vm-100-disk-1 objsetid 160 -
rpool/vm-100-disk-1 dedup off default
rpool/vm-100-disk-1 mlslabel none default
rpool/vm-100-disk-1 sync standard default
rpool/vm-100-disk-1 refcompressratio 1.00x -
rpool/vm-100-disk-1 written 1.41T -
rpool/vm-100-disk-1 logicalused 998G -
rpool/vm-100-disk-1 logicalreferenced 998G -
rpool/vm-100-disk-1 volmode default default
rpool/vm-100-disk-1 snapshot_limit none default
rpool/vm-100-disk-1 snapshot_count none default
rpool/vm-100-disk-1 snapdev hidden default
rpool/vm-100-disk-1 context none default
rpool/vm-100-disk-1 fscontext none default
rpool/vm-100-disk-1 defcontext none default
rpool/vm-100-disk-1 rootcontext none default
rpool/vm-100-disk-1 redundant_metadata all default
rpool/vm-100-disk-1 encryption off default
rpool/vm-100-disk-1 keylocation none default
rpool/vm-100-disk-1 keyformat none default
rpool/vm-100-disk-1 pbkdf2iters 0 default

 

[H4R0]

volblocksize von 8k is zu klein für das dataset und hat entsprechend viel overhead, da du nicht genug speicher mehr frei hast kannst du es aber auch nicht fixen, dir bleibt nur das volume komplett neu anzulegen.

zfs bietet nativ verschlüsselung mit komprimierung und thin provision, ist enstsprechend um weiten besser als bitlocker in der vm..

 

[SimonR]

volblocksize von 8k is zu klein für das dataset und hat entsprechend viel overhead, da du nicht genug speicher mehr frei hast kannst du es aber auch nicht fixen, dir bleibt nur das volume komplett neu anzulegen.

zfs bietet nativ verschlüsselung mit komprimierung und thin provision, ist enstsprechend um weiten besser als bitlocker in der vm..

Alles klar, also kopiere ich die Daten runter, kegen das Volume neu an und zurück damit. Welches Blocksize nehme ich denn optimalerweise bei einem Windows Volume? Gleiches wie bei der NTFS Formatierung angezeigt wird? Oder einfach 32K bspw, und dann passt das? Das replizierte Volume übernimmt dann später den Wert vom Original, wenn ich die Replikation nutze?

 

[SimonR]

volblocksize von 8k is zu klein für das dataset und hat entsprechend viel overhead, da du nicht genug speicher mehr frei hast kannst du es aber auch nicht fixen, dir bleibt nur das volume komplett neu anzulegen.

zfs bietet nativ verschlüsselung mit komprimierung und thin provision, ist enstsprechend um weiten besser als bitlocker in der vm..

Danke dir erstmal für den Tipp.

Also nur nochmal zur Rückversicherung

Ich sichere alle Daten vom Windows-Laufwerk irgendwo. Dann fahre ich die VM runter.

Dann mache ich das:

zfs destroy rpool/vm-100-disk-1
zfs create -V 1000gb -b 32K rpool/vm-100-disk-1

In Proxmox habe ich ja keine Möglichkeit, das bei Volume-Erstellung zu modifizieren und nach ZFS-Doku geht es nur bei Erstellung.

Dann starte ich die VM wieder, initialisiere und formatiere die Partition in Windows und danach ist mein Platzproblem verschwunden, und es wird weniger Overhead erzeugt? Oder lieber ein anderes Blocksize, wie gesagt, es ist ein ganz normaler Dateiserver Server 2019 und ich möchte Bitlocker einsetzen.

Die Blocksize wird bei Volume-Replication dann auch bei 32K liegen, oder?

Könnte das ja auch mal testen mit 500 GB Volume Size als zusätzliches Volume in der VM.

zfs create -V 500gb -b 32K rpool/vm-100-disk-2

Das dann in der VM über die conf einbinden, Volume vollkopieren, mit Bitlocker verschlüsseln und gucken, wieviel Overhead ich habe?

 

[SimonR]

volblocksize von 8k is zu klein für das dataset und hat entsprechend viel overhead, da du nicht genug speicher mehr frei hast kannst du es aber auch nicht fixen, dir bleibt nur das volume komplett neu anzulegen.

zfs bietet nativ verschlüsselung mit komprimierung und thin provision, ist enstsprechend um weiten besser als bitlocker in der vm..

Wenn ich das Volume entschlüssele, nimmt der verbrauchte Platz auf dem Pool wieder ab. Wenn ich dann 1,3 TB frei habe, wirds zwar auch knapp, aber sollte kurzzeitig ausreichen.

Kann ich dann nicht einen Snapshot erstellen von der VM und dann über

zfs send rpool/altes_volume_8k@snap1 | zfs recv rpool/neues_volume_32

alles rüberschaufeln, wenn die VM dabei heruntergefahren bliebt?

Danach die Volumes umbenennen und fertig. Zum Schluss das alte Volume und Snapshots Destroy und fertig?

Bliebe nur die Frage, wieviel KB Blocksize nehme ich fürs neue Volume?

 

[H4R0]

Wenn ich das Volume entschlüssele, nimmt der verbrauchte Platz auf dem Pool wieder ab. Wenn ich dann 1,3 TB frei habe, wirds zwar auch knapp, aber sollte kurzzeitig ausreichen.

Kann ich dann nicht einen Snapshot erstellen von der VM und dann über

zfs send rpool/altes_volume_8k@snap1 | zfs recv rpool/neues_volume_32

alles rüberschaufeln, wenn die VM dabei heruntergefahren bliebt?

Danach die Volumes umbenennen und fertig. Zum Schluss das alte Volume und Snapshots Destroy und fertig?

Bliebe nur die Frage, wieviel KB Blocksize nehme ich fürs neue Volume?

Kannst du so machen, musst halt nur darauf achten das du genug platz hast, wenn du entschlüsselt und nen trim laufen lässt sollte der speicher frei gegeben werden, vorausgesetzt discard ist aktiviert bei der virtuellen hdd.

Du hattest zpool status noch nicht gepostet, handelt es sich um ein raidz ? dafür gibt es eine tabelle mit der besten voll block size abhängig von der festplatten anzahl. Ansonsten ist 32kb gut kannst aber auch 64kb nehmen.

Du kannst unter Datastore -> Storage -> ZFS die standart vollblock größe einstellen, proxmox legt dann immer vdevs mit der block size an.

 

[SimonR]

Danke erstmal, viel gelernt eben.

Ist ein RaidZ1-0 mit 4 Platten. Leider kann zfs send aber die Blocksize nicht ändern, entschlüssele das jetzt, erstelle ein neues Volume mit 32K und kopiere den Kram da rüber.

In einem anderen Cluster konnte ich schon bei kleinen Datenmengen sehen, dass es eine Menge bringt, der Overhead von 50% verschwindet quasi und die Komprimierung bringt dann auch was

Das sind leider alles Sachen, die man erst bemerkt, wenn das Volume sich füllt und man es vorher "genau" ausgerechnet hat, was passt und was nicht. Wieder was gelernt.

Bei einem Proxmox Mirror-Raid mit 2 Platten taucht sowas bspw. nicht auf, da kommt er mit 8K Blocksize ohne Overhead hin.

 

[SimonR]

Mit Bitlocker arbeite ich aus dem Grund, da ein Proxmox-Volume auf einer vollverschlüsselten QNAP in Windows die Recovery Keys hält. Beim Boot entsperren sich die Bitlocker-Windows-Volumes automatisch über diese Schlüssel. Die QNAP ist quasi der Schlüsselbund und darauf muss man beim Start das Volume per Hand entsperren, das Kennwort wird nirgendwo gespeichert. Wenn einer die ganze Anlage mitnimmt, ist so sichergestellt, dass alles geschützt bleibt, denn die QNAP bekommt keiner "aufgeschlossen". Und so kann ich fein 3 Windows Server verschlüsseln, ohne irgendwo in Proxmox Keys eingeben zu müssen oder diese irgendwo zu speichern.

 

[H4R0]

Danke erstmal, viel gelernt eben.

Ist ein RaidZ1-0 mit 4 Platten. Leider kann zfs send aber die Blocksize nicht ändern, entschlüssele das jetzt, erstelle ein neues Volume mit 32K und kopiere den Kram da rüber.

In einem anderen Cluster konnte ich schon bei kleinen Datenmengen sehen, dass es eine Menge bringt, der Overhead von 50% verschwindet quasi und die Komprimierung bringt dann auch was

Das sind leider alles Sachen, die man erst bemerkt, wenn das Volume sich füllt und man es vorher "genau" ausgerechnet hat, was passt und was nicht. Wieder was gelernt.

Bei einem Proxmox Mirror-Raid mit 2 Platten taucht sowas bspw. nicht auf, da kommt er mit 8K Blocksize ohne Overhead hin.

In dem Fall nimm 64kb block size, du wirst aber weiterhin bei 4 Festplatten min 30% overhead haben.

Bei nur 4 Festplatten ist ein stripped mirror vorzuziehen, ist wesentlich performanter 2x schreiben, 4x lesen, mehr iops und hat kein parity overhead. Kommst also auf die gleiche storage kapazität und bessere performance, resilver geht auch wesentlich schneller und dir können 2 Festplatten (jeweils eine im mirror) ausfallen. Raidz am besten erst ab 5 platten.

 

[SimonR]

In dem Fall nimm 64kb block size, du wirst aber weiterhin bei 4 Festplatten min 30% overhead haben.

Bei nur 4 Festplatten ist ein stripped mirror vorzuziehen, ist wesentlich performanter 2x schreiben, 4x lesen, mehr iops und hat kein parity overhead. Kommst also auf die gleiche storage kapazität und bessere performance, resilver geht auch wesentlich schneller und dir können 2 Festplatten (jeweils eine im mirror) ausfallen. Raidz am besten erst ab 5 platten.

Klar, dass ich rein rechnerisch auf dem ZRAID1 über 4 Platten mind. 30 % Overhead habe ist klar, eine Platte kann ja ausfallen.
Aber schau mal, was meine ca. 700 GB Windows Daten jetzt nur noch auf dem ZVOL wegnehmen, nachdem ich es mit 32K erstellt habe:



Das sind auf 680 GB nur noch 60 GB Overhead. Damit bin ich super zufrieden, und die Inhalte sind per Bitlocker verschlüsselt. Und normalerweise kann es ja auch nicht an den Daten an sich liegen, denn Windows formatiert standardmässig ja immer in 4KB Allocation Sectors, wenn man es nicht anders einstellt.

Die Prozessorlast auf dem Server ist zwar ein wenig gestiegen, aber nur 10% oder so. Das war mir auch nicht wichtig, sondern dieses POOL-Volume-Auffressen durch die voreingestellten 8K VolumeBlockSize.

Auf diesen Umstand wird auch viel zu wenig eingegangen.

Habe jetzt für ein anderes Projekt mal 64KB VolBlocksize und 64K formatierte Windows-Partition ausprobiert für ein MS-SQL-Server Datenvolume.
Das sollte dann ja auch richtig sein.

Frage: Ich suche die ganze Zeit diese Tabelle, von der du gesprochen hast, mit den empfohlenen VolBlockSizes bei bestimmten ZFS-Raids. Hast du da einen Link?

Jedenfalls nochmals vielen Dank für die Hilfe.

 

[H4R0]

https://docs.google.com/spreadsheet...jHv6CGVElrPqTA0w_ZY/edit?pli=1#gid=2126998674

Bei Datenbanken weiterhin kleine block size nehmen, denn Datenbanken syncen mit 4kb, bei 64kb block size wird dann 16x so viel geschrieben, bei hdd's gibt es nur performance loss, bei ssd's killt die write amplification die platten im nu, deswegen ist standard auch 8kb. Für Daten Server ist größere block size besser da hier asynchron geschrieben und entsprechend gebuffert wird.

 

[SimonR]

https://docs.google.com/spreadsheet...jHv6CGVElrPqTA0w_ZY/edit?pli=1#gid=2126998674

Bei Datenbanken weiterhin kleine block size nehmen, denn Datenbanken syncen mit 4kb, bei 64kb block size wird dann 16x so viel geschrieben, bei hdd's gibt es nur performance loss, bei ssd's killt die write amplification die platten im nu, deswegen ist standard auch 8kb. Für Daten Server ist größere block size besser da hier asynchron geschrieben und entsprechend gebuffert wird.

Aber nicht Microsoft SQL Server, da wird doch überall 64K empfohlen, oder bin ich da auf dem falschen Dampfer? Man soll auch die NTFS Partition mit 64 K formatieren, passt doch dann exakt zu 64 K Volumeblocksize.

 

[H4R0]

Aber nicht Microsoft SQL Server, da wird doch überall 64K empfohlen, oder bin ich da auf dem falschen Dampfer? Man soll auch die NTFS Partition mit 64 K formatieren, passt doch dann exakt zu 64 K Volumeblocksize.

Scheint tatsächlich 64kb zu sein, wobei das bei Datenbanken eigentlich kein Sinn macht. Tabellen Updates sind meisten nur paar KB groß.

 

[LnxBil]

Scheint tatsächlich 64kb zu sein, wobei das bei Datenbanken eigentlich kein Sinn macht. Tabellen Updates sind meisten nur paar KB groß.

Mittlerweile hat da so jede Datenbanksoftware ihre eigene Philosophie. Generell sollte man die meisten RDBMSs aber auch entsprechend einstellen können.

 

[LnxBil]

Ah ... und nochwas zum Overhead:

Nur die Parität bringt noch nicht viel, wichtig ist auch wie die Daten verteilt werden. Die Blockgröße des Volumes sollte am optimalsten geteilt durch die Festplatten die ashift-Größe sein, denn dann wird der Block auf alle Platten so verteilt, dass kein Platz im ashift-Block freigelassen wird. Bei 4 Disks hat man das Problem noch nicht so stark wie z.B. bei 6 oder 8 im raidz.