Benutzer-Werkzeuge

Webseiten-Werkzeuge


it-wiki:linux:zfs

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
it-wiki:linux:zfs [2021/03/18 08:49] – [Snapshot klonen] markoit-wiki:linux:zfs [2023/11/22 07:42] (aktuell) – [Memorylimit setzen] marko
Zeile 33: Zeile 33:
  
 ===== Memorylimit setzen ===== ===== Memorylimit setzen =====
 +<note tip>As a general rule of thumb, allocate at least 2 GiB Base + 1 GiB/TiB-Storage. For example, if you have a pool with 8 TiB of available storage space then you should use 10 GiB of memory for the ARC.</note>
 ---- ----
  
Zeile 45: Zeile 46:
  
 Wenn man möchte kann man ZFS ein Memorylimit setzten. Wenn man möchte kann man ZFS ein Memorylimit setzten.
 +<code bash>
 +echo "$[10 * 1024*1024*1024]"
 +</code>
 <code bash> <code bash>
 vim  /etc/modprobe.d/zfs.conf vim  /etc/modprobe.d/zfs.conf
Zeile 58: Zeile 62:
 Danach noch die initram updaten und rebooten. Danach noch die initram updaten und rebooten.
 <code bash> <code bash>
-update-initramfs -u+update-initramfs -u -k all
 </code> </code>
  
 +Wenn man ein EFI system verwendet muss die Kernel-Liste im EFI Bootmenü aktualisiert werden, damit das aktualisierte anfängliche RAM-Dateisystem verwendet wird.
 +<code bash>
 +pve-efiboot-tool refresh
 +</code>
 ===== Anlegen eines neuen Pools im Raid10 und hinzufügen zweier weiteren Festplatten ===== ===== Anlegen eines neuen Pools im Raid10 und hinzufügen zweier weiteren Festplatten =====
 ---- ----
Zeile 305: Zeile 313:
 | zfs list -r -t snapshot -o name,creation rpool | Snapshots mit Datum anzeigen | | zfs list -r -t snapshot -o name,creation rpool | Snapshots mit Datum anzeigen |
 | zfs get volsize v-machines/HDD-vmdata-KVM/vm-113-disk-1 NAME PROPERTY VALUE SOURCE v-machines/HDD-vmdata-KVM/vm-113-disk-1 volsize 36G local | zeigt den maximal möglichen Speicher eines Volumes an | | zfs get volsize v-machines/HDD-vmdata-KVM/vm-113-disk-1 NAME PROPERTY VALUE SOURCE v-machines/HDD-vmdata-KVM/vm-113-disk-1 volsize 36G local | zeigt den maximal möglichen Speicher eines Volumes an |
-| zfs set volsize=32g v-machines/HDD-vmdata-KVM/vm-113-disk-1 | Verkleinert/Vergrößert das zvol auf 32GB +| zfs set volsize=32g v-machines/HDD-vmdata-KVM/vm-113-disk-1 | Verkleinert/Vergrößert das zvol auf 32GB (Blockdevice) | 
-(Blockdevice) | +| zfs create -V 5gb tank/vol               | legt ein neues zvol mit einer maximalen Größe von 5G an (Blockdevice) |
-| zfs create -V 5gb tank/vol               | legt ein neues zvol mit einer maximalen Größe von 5G an +
-(Blockdevice) |+
 | zfs set quota=50g tank/backupfolder      | setzt die Quota eines normalen Datesets auf 50g | | zfs set quota=50g tank/backupfolder      | setzt die Quota eines normalen Datesets auf 50g |
 | zfs rename -p rpool/test rpool/server123 | Verschiebt eine Dataset | | zfs rename -p rpool/test rpool/server123 | Verschiebt eine Dataset |
Zeile 319: Zeile 325:
 ---- ----
  
-Snapshots eigenes sich hervorragend für die Datensicherung oder auch wenn man was testet oder auch nur Updates fährt. Man kann sofort wieder zurück. Um nun ein Snapshot von unserem Rootfilesystem zu erstellen geht von wie folgt vor:+Snapshots eigenes sich hervorragend für die Datensicherung oder auch wenn man was testet oder auch nur Updates fährt. Man kann sofort wieder zurück. Um nun ein Snapshot von unserem Rootfilesystem zu erstellen geht man wie folgt vor:
 <code bash> <code bash>
 zfs snapshot rpool/ROOT/pve-1@Freitag zfs snapshot rpool/ROOT/pve-1@Freitag
 </code> </code>
  
-Man generiert Snapshots immer von einem Dataset. Der ZFSpool kann ja mehreren Datasets bestehen. Wie bei unserer Testmaschine hier:+Man generiert Snapshots immer von einem Dataset. Der ZFSpool kann ja aus mehreren Datasets bestehen. Wie bei unserer Testmaschine hier:
 <code bash> <code bash>
 NAME                       USED  AVAIL  REFER  MOUNTPOINT NAME                       USED  AVAIL  REFER  MOUNTPOINT
Zeile 421: Zeile 427:
 </code> </code>
  
-Im nächsten beispiel befinden wir uns auf dem Server node2.tux.local. Am node1.tux.local ist eine 8TB Festplatte mit einem Pool eingebunden für externe Backups. Um nun die Festplatte nicht umstecken zu müssen, kann das ganze einfach in SSH pipen. Natürlich vorher neues Snapshot zum Abgleich erstellen.+Im nächsten Beispiel befinden wir uns auf dem Server node2.tux.local. Am node1.tux.local ist eine 8TB Festplatte mit einem Pool eingebunden für externe Backups. Um nun die Festplatte nicht umstecken zu müssen, kann das ganze einfach in SSH pipen. Natürlich vorher neues Snapshot zum Abgleich erstellen.
 <code bash> <code bash>
 zfs send rpool/ROOT/pve-1@halbjahresbackup rpool/ROOT/pve-1@halbjahresbackup1 | ssh node1.tux.local zfs receive backup/pve-1-node1 zfs send rpool/ROOT/pve-1@halbjahresbackup rpool/ROOT/pve-1@halbjahresbackup1 | ssh node1.tux.local zfs receive backup/pve-1-node1
 </code> </code>
  
-Danach kann man auf beiden seiten das alte Snapshot löschen. Muss man natürlich nicht, wenn man mal weiter zurück möchte.+Danach kann man auf beiden Seiten das alte Snapshot löschen. Muss man natürlich nicht, wenn man mal weiter zurück möchte.
 <code bash> <code bash>
 zfs destroy rpool/ROOT/pve-1@halbjahresbackup zfs destroy rpool/ROOT/pve-1@halbjahresbackup
Zeile 446: Zeile 452:
 </code> </code>
  
-So kann sich die Änderungen mit diff ausgeben lassen.+So kann man sich die Änderungen mit diff ausgeben lassen.
 <code bash> <code bash>
 zfs diff backup/home@halbjahresbackup backup/home zfs diff backup/home@halbjahresbackup backup/home
 </code> </code>
  
-Danach sollten Änderungen angezeigt werden. Wird hier nichts angezeigt, ist der Inhalt ok. Dann aber sein das Features am Ziel aktiviert hat, das wäre auch schon eine Änderung. Man hat nun zwei Möglichkeit. Man kann mit der Option „-F“ das ganze forcen. Dann wird aber auch am Ziel auf der receive seite automatisiert den rollback durchführt, sorgt aber auch dafür dass snapshots die auf der Quelle nicht mehr vorhanden sind am Ziel gelöscht werden. Ich habe mich hier für die zweite Variante entschieden wo einfach am Ziel ein Rollbackup des Snapshots durchgeführt habe:+Danach sollten Änderungen angezeigt werden. Wird hier nichts angezeigt, ist der Inhalt ok. Kann aber sein das Features am Ziel aktiviert sind, das wäre auch schon eine Änderung. Man hat nun zwei Möglichkeit. Man kann mit der Option „-F“ das ganze forcen. Dann wird aber auch am Ziel auf der receive seite automatisiert den rollback durchführt, sorgt aber auch dafür dass snapshots die auf der Quelle nicht mehr vorhanden sind am Ziel gelöscht werden. Ich habe mich hier für die zweite Variante entschieden wo einfach am Ziel ein Rollbackup des Snapshots durchgeführt habe:
 <code bash> <code bash>
 zfs rollback backup/home@halbjahresbackup zfs rollback backup/home@halbjahresbackup
Zeile 512: Zeile 518:
 </code> </code>
  
-==== Mit komplettem ZFSpool umziehen ====+===== Mit komplettem ZFSpool umziehen =====
 ---- ----
  
Zeile 520: Zeile 526:
 zfs send -v -R -p oldpool@migration  | zfs receive -F myfreshpool zfs send -v -R -p oldpool@migration  | zfs receive -F myfreshpool
 </code> </code>
 +
 +===== Autoexpand =====
 +----
 +
 +Ist „autoexpand“ aktiviert vergrößert sich der Festplattenspeicher beim Tausch einer kleineren durch eine größere Platte automatisch. Beispiel: Man hat ein Raid1 mit 2x500GB Festplatten. Man tauscht die platten nacheinander aus (replace/resilvern). Ist die zweite Platte getauscht ist der Mehrspeicher sofort verfügbar.
 +
 +Um für alle Pools abzugragen ob die Funktion aktiv ist gibt man folgendes Befehl ein:
 +<code bash>
 +zpool get autoexpand
 +
 +NAME        PROPERTY    VALUE   SOURCE
 +rpool       autoexpand  off     default
 +v-machines  autoexpand  on      local
 +</code>
 +
 +Eingeschaltet wurde „autoexpand“ auf „v-machines“ mit folgendem Befehl:
 +<code bash>
 +zpool set autoexpand=on v-machines
 +</code>
 +
 +==== Autoexpand auf einem Rootpool ====
 +----
 +
 +Das ganze ist ein wenig komplizierter da man die GPT Bootpartion beachten muss. Zuerst erstellt auf der neuen getauschten Disk eine GPT Partition:
 +<code bash>
 +sgdisk -Z /dev/sdf # löscht nur gpt und mbr struktur
 +sgdisk -Z -o /dev/sdf # löscht auch Partitionen
 +sgdisk -a1 -n1:34:2047 -t1:EF02 -n9:-8M:0 -t9:BF07 -n2:2048:0 -t2:BF01 -c 2:zfs /dev/sdf
 +zpool replace rpool 10714300945297318711 sdf2
 +grub-install /dev/sdf
 +</code>
 +
 +Das natürlich mit jeder Platte wiederholen.
 +that basically means:
 +1: BIOS Boot partition (⇐1M)
 +2: ZFS partition (all free space)
 +9: reserved space (8MB)
 +
 +==== Umwandeln eines Rpool Singledisk in einen Mirror inkl. Autoexpand ====
 +----
 +
 +Annahme ist hier ein Rpool mit einer Samsung EVO750. Da die Disk nicht Enterprise ist und das Wearoutlevel schon bei 90% ist, fügen wir eine Samsung SM863a als Mirror hinzu. Dann können wir beim Ausfall der EVO bequem eine weitere SM863a hinzufügen. Der zeitiger Status ist:
 +<code bash>
 +zpool status 
 +  pool: rpool
 + state: ONLINE
 +  scan: scrub repaired 0B in 0h3m with 0 errors on Sun Oct 14 00:27:05 2018
 +config:
 +
 +        NAME        STATE     READ WRITE CKSUM
 +        rpool       ONLINE               0
 +          sda2      ONLINE               0
 +</code>
 +
 +Rpool's könne hier nur mit den Alias „SDX“ umgehen. Alle anderen „nicht Rootpools“ mit /dev/disk/by-id Wir haben nun unsere neue SSD in's laufende System gehängt. Diese scheint mit sdb auf. Wir konfigurieren diese DISK mit GPT schauen das wie oben beschrieben auch Autoexpand am Pool aktiviert ist und partitionieren diese richtig:
 +<code bash>
 +sgdisk -a1 -n1:34:2047 -t1:EF02 -n9:-8M:0 -t9:BF07 -n2:2048:0 -t2:BF01 -c 2:zfs /dev/sdb
 +Setting name!
 +partNum is 1
 +REALLY setting name!
 +The operation has completed successfully.
 +</code>
 +
 +Mit ''<color purple>partx -s /dev/sdb</color>'' sehen wir das die Disk nun richtig konfiguriert wurde:
 +<code bash>
 +partx -s /dev/sdb
 +NR     START       END   SECTORS   SIZE NAME UUID
 +        34      2047      2014  1007K      abdb3664-8f24-4f9c-b69f-48041a12dd2a
 +      2048 468845709 468843662 223,6G zfs  54a8aa0b-3e13-4e05-b8f6-3bcc1a5452d5
 + 9 468845710 468862094     16385     8M      8dfaf865-cv4f-4931-86ba-9a9a274d3ead
 +</code>
 +
 +Nun können wir die neue Disk zu unserer alten dazu hängen:
 +<code bash>
 +zpool attach  -o ashift=12 -f  rpool  /dev/sda2 /dev/sdb2
 +Make sure to wait until resilver is done before rebooting.
 +</code>
 +
 +Nach erfolgreichen resilvern, sieht unser Pool nun so aus:
 +<code bash>
 +zpool status         
 +  pool: rpool
 + state: ONLINE
 +  scan: resilvered 31,9G in 0h2m with 0 errors on Mon Nov  5 17:02:53 2018
 +config:
 +
 +        NAME        STATE     READ WRITE CKSUM
 +        rpool       ONLINE               0
 +          mirror-0  ONLINE               0
 +            sda2    ONLINE               0
 +            sdb2    ONLINE               0
 +
 +errors: No known data errors
 +</code>
 +
 +Danach noch Grub installieren und fertig.
 +<code bash>
 +grub-install /dev/sdb
 +</code>
 +
 +Nachdem wir dann später mal die EVO getauscht haben, wird der Pool automatisch auf die 240GB vergrößert.
 +
 +===== Autoreplace =====
 +----
 +
 +Autoreplace ersetzt automatische eine defekte Platte aus einem Zpool. Hierfür ist aber ein eingener [[http://www.informit.com/articles/article.aspx?p=1433052&seqNum=7|Hotsparepool]] erforderlich.
 +
 +===== Proxmox spezifisches =====
 +----
 +
 +Unter Proxmox wird LVM defaultmäßing mitinstalliert, man im Installer wählen kann ob man ZFS oder EXT4 mit LVM haben möchte. Unter ZFS kann LVM einen Filter erstellen damit der HOST die LVMs von den Gästen nicht sieht. Ist sauberer.
 +<code bash>
 +nano /etc/lvm/lvm.conf
 +filter = [ "r|/dev/zd*|" ]
 +</code>
 +
 +Auf jeden sollte auch eine Überwachung der [[https://pve.proxmox.com/wiki/Disk_Health_Email_Alerts|Smart-Werte]] konfiguriert werden.
 +
 +==== Proxmox Rescue ZFS ====
 +----
 +
 +Sollte die Maschine, aus was für einen Grund auch immer nicht mehr ins System hoch booten, und auch keine Busybox zur Verfügung stehen, kann man sich mit einem auf USB installierten PVE helfen, oder auch ein anderes ZFS fähiges OS verwenden. Solaris funktioniert nicht, da Solaris eine viel zu alte Version von ZFS verwendet, und somit nicht kompatibel ist. PCBSD wurde nicht getestet, sollte aber auch funktionieren.
 +
 +Hat man mit seinem PVE Stick gebootet werden sämtliche Zpools automatisch eingebunden und gemounted. Möchte man aber auf dem Rpool Dinge ändern, muss man den Mountpoint anders setzten. Da sich der Rpool ja auf „/“ mounten möchte und das natürlich nicht geht da dieser Slot schon von unserem Sticksystem besetzt ist. Um nun trotzdem auch auf diesen Teil Zugriff zu bekommen ändern wir einfach kurzfristig den Mountpoint.
 +<code bash>
 +zfs set mountpoint=/mnt rpool/ROOT/pve-1
 +zfs mount rpool/ROOT/pve-1
 +</code>
 +
 +Wir führen unsere Änderungen durch, und hängen aus und switchen zurück.
 +<code bash>
 +zfs umount rpool/ROOT/pve-1
 +zfs set mountpoint=/ rpool/ROOT/pve-1
 +</code>
 +
 +Natürlich bevor wir das alles erledigen möge man sich vorher erkundigen ob noch etwaige Zusatzdatasets auf Root zeigen. Diese müssen vorher ausgehängt werden.
 +
 +===== sharenfs =====
 +----
 +
 +Nutzt man ZFS als Dateisystem ist es klug die „sharenfs“ Funktion von ZFS direkt statt dem System Export zu verwenden. Da hier die zeitliche Abfolge beim Systemstart immer optimal ist. Um eine Freigabe zu erstellen inkl. eines Datasets zu erstellen bedient man sich folgendem Befehl:
 +<code bash>
 +zfs create testpool/testnfs -o sharenfs="rw=@hostname1.local,rw=@192.168.1.3,no_root_squash,no_subtree_check,async"
 +</code>
 +
 +Für IPV6 können als Source nur mehr FQDN verwendet werden.
 +
 +Bei einem bestehenden Dataset:
 +<code bash>
 +zfs set sharenfs="rw=@hostname1.local,rw=@192.168.1.3,no_root_squash,no_subtree_check,async" testpool/testnfs
 +</code>
 +
 +Für eine einfache Freigabe:
 +<code bash>
 +zfs set sharenfs=on testpool/testnfs
 +</code>
 +
 +Um eine Freigabe zu beenden:
 +<code bash>
 +zfs set sharenfs=off testpool/testnfs
 +</code>
 +
 +Das Dataset löschen, löscht natürlich auch die Freigabe. Um zu sehen welche Freigaben nun aktiv sind gibt es mehrere Möglichkeiten. Am Host selbst:
 +<code bash>
 +cat /etc/dfs/sharetab
 +</code>
 +<code bash>
 +zfs get sharenfs # kann auch mit weiteren Optionen kombiniert werden
 +</code>
 +
 +Von einem anderen Host:
 +<code bash>
 +showmount  -e hostname.local
 +</code>
 +
 +===== Swap =====
 +----
 +
 +Swap direkt auf ZFS erstellen. Empfohlen, genug RAM, oder Swap auf einem nicht ZFS-Filesystem.
 +<code bash>
 +zfs create -V 8G -b $(getconf PAGESIZE) -o compression=zle -o logbias=throughput -o sync=always -o primarycache=metadata -o secondarycache=none -o com.sun:auto-snapshot=false v-machines/swap
 +</code>
 +\\
 +\\
 +\\
 + --- //[[marko.oldenburg@cooltux.net|Marko Oldenburg]] 2023/02/11 08:23//
it-wiki/linux/zfs.1616057380.txt.gz · Zuletzt geändert: 2021/03/18 08:49 von marko