Frage an Leute mit ZFS Kenntnissen

Probleme mit Samba, NFS, FTP und Co.
Antworten
Benutzeravatar
sys_op
Beiträge: 672
Registriert: 17.09.2007 19:10:47
Lizenz eigener Beiträge: GNU General Public License

Frage an Leute mit ZFS Kenntnissen

Beitrag von sys_op » 06.09.2016 12:24:34

Hallo

Ich betreibe ein Storage mit ZFS als Filesystem, alles läuft soweit rund.

Angelegt wurde ein Pool /tank als raidz3 mit diversen Platten. Da der Pool schon recht voll war, habe ich den Pool erweitern wollen und dabei wohl Mist gebaut, indem ich mit

Code: Alles auswählen

zpool add tank /dev/sdae /dev/sdaf -f
zwei Platten hinzugefügt habe. Offenbar wurden sie aber nicht dem bestehenden raidz3 Pool hinzugefügt sondern irgendwie "anders" eingebunden. Die Platten sind online, werden unter dem Pool aufgeführt und alles scheint in Ordnung, ABER:
Nun zeigt mit ein zpool list eine Poolgrösse von 112TB aber ein df -h nur eine Grösse von 89TB

Ich könnte da ein paar Hinweise brauchen, was ich falsch gemacht habe und wie ich das eventuell beheben könnte.

Danke
gruss sys;-)

Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Frage an Leute mit ZFS Kenntnissen

Beitrag von heisenberg » 06.09.2016 12:36:34

Du könntest zunächst mal einen zpool status aufrufen. Da siehst Du, wie die devices aufgebaut sind.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
sys_op
Beiträge: 672
Registriert: 17.09.2007 19:10:47
Lizenz eigener Beiträge: GNU General Public License

Re: Frage an Leute mit ZFS Kenntnissen

Beitrag von sys_op » 06.09.2016 12:42:36

Hallo

zpool status zeigt mir, dass die Platten wohl dem Pool hinzugefügt wurden, online sind und dass keine Fehler vorhanden sind.
Allerdings sind die Platten in der Anzeige leicht "vorversetzt", was mich vermuten lässt, dass da etwas nicht mit 100% rechten Dingen zugeht. Die unterschiedliche Anzeige der Poolgrösse tut ihr Übriges.

Code: Alles auswählen

	NAME        STATE     READ WRITE CKSUM
	tank        ONLINE       0     0     0
	  raidz3-0  ONLINE       0     0     0
	    sdb     ONLINE       0     0     0
	    sdc     ONLINE       0     0     0
	    sdd     ONLINE       0     0     0
	    sde     ONLINE       0     0     0
	    sdf     ONLINE       0     0     0
	    sdg     ONLINE       0     0     0
	    sdh     ONLINE       0     0     0
	    sdi     ONLINE       0     0     0
	    sdj     ONLINE       0     0     0
	    sdk     ONLINE       0     0     0
	    sdl     ONLINE       0     0     0
	    sdm     ONLINE       0     0     0
	    sdn     ONLINE       0     0     0
	    sdo     ONLINE       0     0     0
	    sdp     ONLINE       0     0     0
	    sdq     ONLINE       0     0     0
	    sdr     ONLINE       0     0     0
	    sds     ONLINE       0     0     0
	    sdt     ONLINE       0     0     0
	    sdu     ONLINE       0     0     0
	    sdv     ONLINE       0     0     0
	    sdw     ONLINE       0     0     0
	    sdx     ONLINE       0     0     0
	    sdy     ONLINE       0     0     0
	    sdz     ONLINE       0     0     0
	    sdaa    ONLINE       0     0     0
	    sdab    ONLINE       0     0     0
	    sdac    ONLINE       0     0     0
	    sdad    ONLINE       0     0     0
	  sdaf      ONLINE       0     0     0
	  sdae      ONLINE       0     0     0
	spares
	  sdah      AVAIL   
	  sdai      AVAIL   
	  sdag      AVAIL  
gruss sys;-)

Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Frage an Leute mit ZFS Kenntnissen

Beitrag von heisenberg » 06.09.2016 14:42:30

Ok. Auch wenn das eine sehr einfache Sache ist: Habe ich jetzt selbst auch noch nicht gemacht.

Sieht so aus, als ob das, was Du möchtest so nicht geht. Du kannst dem vorhandenen raid-z3(="vdev") keine Festplatten hinzufügen. Du kannst dem Pool tank z. B. ein neues raidz hinzfügen, welches dem Pool dann insgesamt den Speicher erweitert.

Von dem was ich bisher so gelesen habe, ist es wohl auch nicht so gut ein RAID mit vielen Festplatten zu betreiben. Also sprich statt einem RAID-Z3 mit 20 Platten lieber 4x5 RAID5/RAIDZ und die wiederrum zusammenfassen. So bremst die langsamste Platten das ganze RAID aus.

Im Moment hast Du den Pool um 2 Nicht-redundante-Einzelfestplatten erweitert - mit Sicherheit nicht das, was Du willst.

Ein Lösungsansatz wäre z. B. dass Du zunächst die 2 Platten wieder aus dem ZFS-Volume entfernst und dann dem Pool ein RAIDZ mit 4 Platten hinzufügst. Vielleicht auch nochmal die Doku wälzen: https://github.com/zfsonlinux/zfs/wiki/ ... umentation

Und noch etwas persönliche Meinung

Wenn ich etwas flexibles haben will, dann nehme ich nicht ZFS sondern LVM.
Zuletzt geändert von heisenberg am 06.09.2016 14:51:21, insgesamt 1-mal geändert.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
sys_op
Beiträge: 672
Registriert: 17.09.2007 19:10:47
Lizenz eigener Beiträge: GNU General Public License

Re: Frage an Leute mit ZFS Kenntnissen

Beitrag von sys_op » 06.09.2016 14:50:06

Genau, nun kann ich diese Platten aber leider nicht wieder entfernen, weil das entfernen nur für bestimmte "Platten-Arten" erlaubt ist (cache, spare etc.).

Code: Alles auswählen

zpool remove tank /dev/sdaf /dev/sdae
cannot remove /dev/sdaf: only inactive hot spares, cache, top-level, or log devices can be removed
cannot remove /dev/sdae: only inactive hot spares, cache, top-level, or log devices can be removed
Weiters stellt sich mir die Frage, wie Daten nun auf diesen Platten landen bzw was passiert, wenn eine dieser Platten defekt wird und welche grösse hat der Pool denn nun wirklich?

ein detach oder offline der Platten funktioniert nicht!

Es wird wohl darauf hinaus laufen, dass ich einen neuen Pool anlegen werde, alle Daten kopiere und dann den original-Pool löschen werde.

PS
Ob ZFS oder LVM ist wohl eine Glaubensfrage denke ich. Die Selbstheilungsmechanismen von ZFS scheinen doch sehr gut zu funktionieren.

Wenn man alles richtig macht ist ZFS schon eine recht gute Sache. Scheinbar sind kleine Fehler aber oft mit grösserer Wirkung verbunden als mir lieb ist. Wie man oben sehen kann ist die Zuweisung von x Platten im raidz3 ja eine Tolle und einfache Sache. Hätte ich es richtig gemacht und den Pool wieder mit einem raidz3 Plattenverbund erweitert wäre mir die Frage hier ja erspart geblieben.
gruss sys;-)

Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Frage an Leute mit ZFS Kenntnissen

Beitrag von heisenberg » 06.09.2016 16:29:01

Ob ZFS oder LVM ist wohl eine Glaubensfrage denke ich.
Sicherlich auch eine Frage der persönlichen Vorliebe. Vor allem für mich persänlich aber eine Entscheidung für spezifischen Vor- und Nachteile des jeweilligen Vetreters. ZFS ist von der Administration her sehr angenehm und auch die transparente Kompression ist für mich eines der Killer-Features. Für LVM spricht für mich die weit grössere Flexibilität, dass man z. B. alles online komplett umbauen kann.
Ein Lösungsansatz wäre z. B. dass Du zunächst die 2 Platten wieder aus dem ZFS-Volume entfernst und dann dem Pool ein RAIDZ mit 4 Platten hinzufügst.
Sorry ich habe mich falsch ausgedrückt: Entfernen geht nicht, aber ersetzen. Du könntest jedes Deiner zwei neu erzeugten VDEVs durch ein RAIDZ ersetzen. Am besten das ganze mit Loopdevices mal durchspielen.
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Frage an Leute mit ZFS Kenntnissen

Beitrag von r4pt0r » 06.09.2016 21:11:09

Au Backe, das wird jetzt etwas länger... :wink:

Das initiale Problem war, dass zusätzliche Geräte mit "zfs attach" zum bestehenden vdev hinzugefügt werden. "zfs add" erstellt ein neues vdev. Das geht aber bei raidZ nicht (ohne weiteres) - ein Pool mit raidZ-vdevs wird normalerweise immer um weitere vdevs identischer größe/konfiguration erweitert, nie durch einzelne Platten.

Das vorhandene (und einzige) vdev ist ausserdem _viel_ zu groß - die Performance des vdevs und damit des pools ist vermutlich (sicher) unterirdisch.
Ganz grobe Faustregel für raidZ: Wurzel aus gesamter Plattenzahl (ggf der geplanten Vollbestückung) + raidZ-Level entspricht der maximalen Anzahl Geräte je vdev. Ist man da drüber macht man definitiv was falsch (oder man weiß _SEHR_ genau warum man es doch anders macht!).
Bsp: bei 48 Platten in Vollbestückung mit raidZ3 sollten die vdevs im extremfall MAXIMAL aus 10 Geräten bestehen (wurzel aus 48 = 6.9 + raidZ3 = 9.9).
Je mehr Platten je vdev, desto mehr IOPS und Bandbreite büßt der gesamte Pool ein. Anders herum: je mehr VDEVs, desto mehr Geräte werden parallel genutzt und desto höher der gesamtdurchsatz des pools. Dein Pool hat maximal den Durchsatz der langsamsten einzelnen Platte (sprich: katastrophal schlecht).

Ein Pool aus raidZ3-vdevs sollte auch immer nur mit weiteren raidz3-vdevs gleicher größe erweitert werden. In deinem Fall also 29 (!!!) Geräte. Spätestens hier sollte schon klar sein, dass da was ganz gewaltig verbockt wurde...

Da raidZ relativ unflexibel ist, sollte man sich sehr gut überlegen, ob man nicht evtl mit mirror-vdevs besser fährt. Hier ist eine erweiterung immer um einen neuen mirror möglich, wobei ein mirror auch aus mehr als 2 Geräten bestehen kann, falls höhere Redundanz erforderlich ist. Weiterer vorteil von mirror-vdevs: der Pool hat eine deutlich höhere IOPS-Leistung und mit "zfs split" lässt sich ein klon des pools abspalten, z.b. für ein initiales fullbackup an einem offsite-system.

Meine dringende Empfehlung: Da die beiden hinzugefügten Platten aktuell ohne jegliche redundanz verwendet werden, füge zumindest jeweils noch ein device identischer größe hinzu (evtl von den spares abzwacken?) um zumindest nen mirror draus zu machen.
Sinnvollster Ausweg wäre dann eine Sicherund der datasets aus diesem Pool per zfs send/receive in einem anderen pool / dateien auf nem Fileserver / Bändern / S3 oder anderem cloud-storage etc pp... Dann lege den Pool neu an mit mehreren kleineren vdevs. Dieser Pool ist praktisch nicht (sinnvoll) erweiterbar, da dieses riesen-vdev die Performance immer in den Keller ziehen wird.
Mit inkrementellen send/receive lässt sich das backup nach und nach mit immer kürzeren abständen synchronisieren, sodass die downtime minimal gehalten werden kann. Bzw wenn ein zweiter pool (hot-backup) zur Verfügung steht, wäre theoretisch sogar eine migration ohne downtime möglich (je nach nutzung des Pools natürlich - bei VMs mit datenbanken würde ichs nicht riskieren).


Zwei weitere Ratschläge:
- binde Laufwerke unbedingt mit aussagekräftigen Bezeichnungen ein. Die letzten 5-7 Stellen der Seriennr und/oder die physische Position (z.b. controller/enclosure/backplane oder gehäuse/reihe/position) als GPT-Label oder zumindest die WWN sind gute Varianten und lassen sich sowohl per Software als auch direkt auf der Platte bzw am shelf/backplane/jbod einfach ermitteln. Zusätzlich gehören natürlich die caddies entsprechend beschriftet. Mit "sdt" kann keine Sau etwas anfangen wenn mitten im Urlaub eine Platte abraucht und man per Telefon jemanden der keine Ahnung von dem System hat erklären muss, welche Platte er ersetzen soll... Zumal die sdX-Bezeichnungen völlig willkürlich vergeben werden - werden Platten ersetzt oder hinzugefügt, stimmen die Bezeichnungen beim nächsten reboot nicht mehr und der pool kann nicht importiert werden.

- Bei so großen Pools sind cache- und log-devices eigentlich unverzichtbar um die Performance auch bei Spitzenlasten gleichmäßig zu halten. Bei der Poolgröße kommen praktisch nur noch NVMe bzw PCIe-SSDs in Betracht - allein schon um die HBAs nicht zusätzlich zu belasten und auch um den nötigen I/O bereit zu stellen. SSDs an SAS/SATA haben nur einen queue mit max 64 einträgen, da sie sich wie "dumme" HDDs verhalten müssen (Stichwort FTL) - NVMe/PCIe haben bis zu 64k queues mit 64k Tiefe; da wird I/O praktisch nur noch durch CPU und die Busbreite (x4, x8, x16) bzw PCIe 2 vs 2.1 vs 3 begrenzt.


Wenn du so große Pools administrierst rate dir _dringend_ dich durch Fachliteratur mit ZFS vertraut zu machen. Ich unterstelle anhand der Gröse mal, dass es sich hier nicht mehr um ein Hobby sondern ein (wichtiges) Produktivsystem handelt - wenn dir das um die Ohren fliegt wirds richtig ungemütlich... (und das wird es in der jetzigen Konfiguration - zumindest bei der Performance bereits jetzt und kapital spätestens wenn eine der beiden neuen Platten eingeht)
Die beiden Bücher von Michael W. Lucas und Alan Jude, FreeBSD Mastery: ZFS und Advanced ZFS, kann ich wärmstens empfehlen. Es werden nur wenige BSD-Spezifische Themen behandelt, >80% beziehen sich auf OpenZFS allgemein und sind somit Plattformübergreifend gültig, also auch für illumos oder linux. (Bei den restlichen ca 20% sieht man oft, wie angenehm logisch und einfach vieles gelöst werden kann, was unter Linux z.T. ein ziemlicher Krampf ist :wink: )

Ach und PS: df und du sind mit ZFS die völlig falschen tools. Da ZFS (ohne quotas) den gesamten pool für alle datasets verfügbar macht, liefern df und du völlig verkehrte werte. Alles was man wissen möchte, liefert "zfs list" mit entsprechenden optionen. Die manpage ist hier der erste Anlaufpunkt - dank Solaris/Illumos-Abstammung ist diese nämlich auch umfassend und mit haufenweise Beispielen versehen :THX:

Colttt
Beiträge: 2983
Registriert: 16.10.2008 23:25:34
Wohnort: Brandenburg
Kontaktdaten:

Re: Frage an Leute mit ZFS Kenntnissen

Beitrag von Colttt » 07.09.2016 08:55:18

@raptor, wenn ich dich richtig verstanden habe dann wäre folgendes jetzt ideal..
er hat 34 platten, das mit der wurzel sind ja maximal werte.. 34 durch etwas teilen wo noch etwas übrig bleibt für spares.. wäre also 34/4 = 8 rest 2.. also 8vdevs anlegen, darüber ein raidz spannen und den rest als spares nehmen, richtig?

oder man bastelt das ganze ein raid10:

Code: Alles auswählen

zpool create storage mirror /dev/disk/by-path/pci-0000:08:08.0-sas-0x5002219488a9d204-lun-0 /dev/disk/by-path/pci-0000:08:08.0-sas-0x5002219488a9d204-lun-1 mirror /dev/disk/by-path/pci-0000:08:08.0-sas-0x5002219488a9d204-lun-10 /dev/disk/by-path/pci-0000:08:08.0-sas-0x5002219488a9d204-lun-11 mirror /dev/disk/by-path/pci-0000:08:08.0-sas-0x5002219488a9d204-lun-12 /dev/disk/by-path/pci-0000:08:08.0-sas-0x5002219488a9d204-lun-9 mirror /dev/disk/by-path/pci-0000:08:08.0-sas-0x5002219488a9d204-lun-8 /dev/disk/by-path/pci-0000:08:08.0-sas-0x5002219488a9d204-lun-7 mirror /dev/disk/by-path/pci-0000:08:08.0-sas-0x5002219488a9d204-lun-6 /dev/disk/by-path/pci-0000:08:08.0-sas-0x5002219488a9d204-lun-5 spare /dev/disk/by-path/pci-0000:08:08.0-sas-0x5002219488a9d204-lun-4 -f -o ashift=9

zpool status
  pool: storage
 state: ONLINE
  scan: none requested
config:

        NAME                                                STATE     READ WRITE CKSUM
        storage                                             ONLINE       0     0     0
          mirror-0                                          ONLINE       0     0     0
            pci-0000:08:08.0-sas-0x5002219488a9d204-lun-0   ONLINE       0     0     0
            pci-0000:08:08.0-sas-0x5002219488a9d204-lun-1   ONLINE       0     0     0
          mirror-1                                          ONLINE       0     0     0
            pci-0000:08:08.0-sas-0x5002219488a9d204-lun-10  ONLINE       0     0     0
            pci-0000:08:08.0-sas-0x5002219488a9d204-lun-11  ONLINE       0     0     0
          mirror-2                                          ONLINE       0     0     0
            pci-0000:08:08.0-sas-0x5002219488a9d204-lun-12  ONLINE       0     0     0
            pci-0000:08:08.0-sas-0x5002219488a9d204-lun-9   ONLINE       0     0     0
          mirror-3                                          ONLINE       0     0     0
            pci-0000:08:08.0-sas-0x5002219488a9d204-lun-8   ONLINE       0     0     0
            pci-0000:08:08.0-sas-0x5002219488a9d204-lun-7   ONLINE       0     0     0
          mirror-4                                          ONLINE       0     0     0
            pci-0000:08:08.0-sas-0x5002219488a9d204-lun-6   ONLINE       0     0     0
            pci-0000:08:08.0-sas-0x5002219488a9d204-lun-5   ONLINE       0     0     0
        spares
          pci-0000:08:08.0-sas-0x5002219488a9d204-lun-4     AVAIL   

errors: No known data errors
hab ich das jetzt richtig verstanden/gemacht? nicht das ich hier was falsches zeige
Debian-Nutzer :D

ZABBIX Certified Specialist

Benutzeravatar
sys_op
Beiträge: 672
Registriert: 17.09.2007 19:10:47
Lizenz eigener Beiträge: GNU General Public License

Re: Frage an Leute mit ZFS Kenntnissen

Beitrag von sys_op » 07.09.2016 10:12:19

Zuerst mal danke für den langen Beitrag, da habe ich ja noch etwas vor mir.

Das Ganze soll natürlich als Produktivsystem in Betrieb gehen, bisher habe ich aber nur mit Daten "herumgespielt", die reproduzierbar sind, ich kann also jeder Zeit den Pool "platt" machen und die Daten dann endgültig einspielen und das System in Betreib nehmen.
gruss sys;-)

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Frage an Leute mit ZFS Kenntnissen

Beitrag von r4pt0r » 07.09.2016 11:56:32

Colttt hat geschrieben:@raptor, wenn ich dich richtig verstanden habe dann wäre folgendes jetzt ideal..
er hat 34 platten, das mit der wurzel sind ja maximal werte.. 34 durch etwas teilen wo noch etwas übrig bleibt für spares.. wäre also 34/4 = 8 rest 2.. also 8vdevs anlegen, darüber ein raidz spannen und den rest als spares nehmen, richtig?

Das sind grobe richtwerte - bei niedrigen Gerätezahlen haut das nicht unbedingt hin.

Über vdevs legt man keine raidlevel! vdevs werden mit einem level (stripe, mirror, raidz...) angelegt, ZFS striped über alle verfügbaren vdevs. Daher steigt der durchsatz mit zunehmender anzahl vdevs, da diese parallel als stripe genutzt werden.

Ob raidZ überhaupt sinn macht hängt vom einsatzzweck ab, der noch nicht spezifiziert wurde. Mit mirrors erzielt man deutlich höhere IOPS-Leistungen, mit raidz vdevs höhere r/w-Leistung. Zudem bietet raidz mehr nutzbaren Speicherplatz als mirror (50%).
Mit steigender Zahl der geräte je vdev steigt rw-Leistung, mit steigender Zahl an vdevs die IOPS. Hier muss man abwägen was wichtiger ist bzw den besten Kompromiss/Mittelwert wählen. Mit einem "symmetrischen" Setup (ca identische anzahl vdevs und geräte je vdev) hat man i.d.r. eine ausgewogene performance.
Bei 34 identischen (!) Platten würde ich persönlich 5 x 6 disk raidz2 einrichten bzw falls möglich noch 2 Platten dazu und 6x6. Wenn mehr IOPS benötigt werden (DB, VMs) mehr vdevs; wird primär hohe rw-Performance gefordert (backupsystem, videostreams/überwachung...), größere vdevs.
Im hinterkopf muss man dabei aber immer behalten: erweiterung des pools ist nur mit gleichen vdevs sinnvoll bzw es müssen alle geräte eines vdevs durch größere ersetzt werden um die kapazität zu erhöhen. Je größer die vdevs, desto kostenintensiver werden upgardes! Für meine privaten pools setze ich daher nur mirror-vdevs ein, da hier die erweiterung mit nur 2 neuen platten möglich ist (und ich nicht mal eben 2k EUR für ein plattenupgrade ausgeben kann/will...).

Werden unterschiedlich große Platten verwendet, machen nur mirror-vdevs sinn. Langsame Platten sollte man aussortieren, da diese die Performance erheblich schwächen. Ich hatte testweise 2 SATA2-HDDs in einem testpool mit 4 mirror-vdevs. Nach austausch gegen SATA3-HDDs ging die rw-leistung (ohne cache/zil) um 20% nach oben! Da ZFS die rw-Last gleichmäßig über die vdevs verteilt, muss immer auf das langsamste vdev gewartet werden, auch wenn alle anderen vdevs deutlich mehr bandbreite hätten.

raidz3 ist eigentlich nur bei hochgradig kritischen systemen/backupstorage sinnvoll. Für alle anderen anwendungsfälle ist z2 völlig ausreichend, ggf sogar z1.

Die LUN ist eigentlich so unpraktisch wie sdN - sie ist nicht physisch an der Platte ermittelbar. Wie gesagt: Seriennr/WWN und/oder position im shelf sind die beste Variante. Meldet ZFS dass Gerät pci-0000:08:08.0-sas-0x5002219488a9d204-lun-9 ausgefallen ist, muss erst noch gesucht werden welche Platte das ist und man muss hoffen, dass derjenige am System wirklich die richtige rauszieht (und nicht das andere device des mirrors...). Meldet ZFS das Gerät z.b. mit "s1r2d3-WD-50014EE2B3CE0A1", ist sofort die physische position (shelf 1, row 2, disk 3), hersteller (WD), und die WWN ersichtlich. GPT-Labels können 36 Zeichen lang sein - man kann sich also richtig austoben und ein für die eigene Umgebung sinnvolles System ausarbeiten.
Ich nutze das Format <phys. pos> - <herstellerkürzel> - <WWN> als GPT-Label, auf den caddies ist dann <herstellerkürzel> - <WWN> aufgeklebt (nur Klebelabel mit hoher Klebekraft nehmen - die billigen fallen nach paar monaten warm/trockener luft im rack einfach ab...). Ich kann anhand der mail die ich im fehlerfalle bekomme dirkekt instruktionen geben, die platte an welcher position ersetzt werden soll (bzw anhand der position lässt sich ggf auch die LED der backplane einschalten) und mit den beiden anderen infos schon beim Hersteller ne RMA-Anfrage anlegen...

Wichtig: ashift=12 !!
Ausnahme: Wenn explizit Platten mit 512 byte großen Sektoren (physisch, nicht der vorgelogene kompatibilitätswert) verwendet werden. Das macht nur in extrem IO-Intensiven anwendungen sinn, die viele kleine operationen durchführen (manche DBs). Bei Platten mit 4k Sektorgröße bremst die resultierende r/w amplifikation die gesamtleistung EXTREM aus - für 4k greift ZFS nich 1x sondern 8x mit 512byte auf die platte zu (die jedes mal 4k liest/schreibt).
Größere blockgrößen können bei manchen Setups vorteile bringen (NVMe/PCIe-SSDs).

Alle überlegungen zur Poolkonfiguration werden im genannten Buch "FreeBSD Mastery: ZFS" hervorragend erklärt und mit Beispielkonfigurationen + zu erwartender Performance des Pools ergänzt. Komplexere setups und "speziellere" Hardware wird in "Advanced ZFS" ausführlich behandelt, auch wie man pools für spezielle arbeitslasten optimieren kann.
Kann also nur nochmal beide Bücher empfehlen.

BTW: Ich hoffe es wird kein port-expander genutzt - ZFS geht immer davon aus, direkt mit dem blockdevice zu interagieren. "Lügende" Firmware führt daher nicht selten zu datenverlust (daher auch keine RAID-Controller!) und portexpander sind leider ebenfalls notorische lügner...

Colttt
Beiträge: 2983
Registriert: 16.10.2008 23:25:34
Wohnort: Brandenburg
Kontaktdaten:

Re: Frage an Leute mit ZFS Kenntnissen

Beitrag von Colttt » 09.09.2016 09:46:28

Hier mal ein kurzer vergleich von zfs und dessen raidlevel: NoPaste-Eintrag39491 hab das ganze mit bonni++ getestet..
Wichtig: ashift=12 !!
Ausnahme: Wenn explizit Platten mit 512 byte großen Sektoren (physisch, nicht der vorgelogene kompatibilitätswert) verwendet werden. Das macht nur in extrem IO-Intensiven anwendungen sinn, die viele kleine operationen durchführen (manche DBs). Bei Platten mit 4k Sektorgröße bremst die resultierende r/w amplifikation die gesamtleistung EXTREM aus - für 4k greift ZFS nich 1x sondern 8x mit 512byte auf die platte zu (die jedes mal 4k liest/schreibt).
Größere blockgrößen können bei manchen Setups vorteile bringen (NVMe/PCIe-SSDs).
ich weiss ;) aber ich hab hier noch alte platten und die haben von 512Byte ;)

Aber das mit dem GPT-Label ist ne gute idee, werde ich dann wenns mal produktiv wird so machen.
BTW: Ich hoffe es wird kein port-expander genutzt - ZFS geht immer davon aus, direkt mit dem blockdevice zu interagieren. "Lügende" Firmware führt daher nicht selten zu datenverlust (daher auch keine RAID-Controller!) und portexpander sind leider ebenfalls notorische lügner...
ok, aber wie/was dann? mal kurz bei TK-JBOD geguckt, die haben dort alle SAS-Expander, oder verstehe ich da was falsch? Und nen HBA brauch ich auch im Server, wie sonst mit dem JBODs reden?
Debian-Nutzer :D

ZABBIX Certified Specialist

Benutzeravatar
sys_op
Beiträge: 672
Registriert: 17.09.2007 19:10:47
Lizenz eigener Beiträge: GNU General Public License

Re: Frage an Leute mit ZFS Kenntnissen

Beitrag von sys_op » 09.09.2016 09:59:00

Hallo
r4pt0r hat geschrieben:...
BTW: Ich hoffe es wird kein port-expander genutzt - ZFS geht immer davon aus, direkt mit dem blockdevice zu interagieren. "Lügende" Firmware führt daher nicht selten zu datenverlust (daher auch keine RAID-Controller!) und portexpander sind leider ebenfalls notorische lügner...
Habe mich auch gerade gefragt, wie man 36 Platten ohne Expander oder Raid-Controller anschliesst.

Nach etwas intensiverer Recherche habe ich nun noch heraus gelesen, dass raidz1 erhebliche Probleme beim rebuild machen kann (es ist mit ähnlichen Problemen wie bei RAID5 zu rechnen), nicht selten mit Datenverlust verbunden ist und daher eher nicht verwendet werden sollte.
gruss sys;-)

Colttt
Beiträge: 2983
Registriert: 16.10.2008 23:25:34
Wohnort: Brandenburg
Kontaktdaten:

Re: Frage an Leute mit ZFS Kenntnissen

Beitrag von Colttt » 09.09.2016 10:04:22

sys_op hat geschrieben: Nach etwas intensiverer Recherche habe ich nun noch heraus gelesen, dass raidz1 erhebliche Probleme beim rebuild machen kann (es ist mit ähnlichen Problemen wie bei RAID5 zu rechnen), nicht selten mit Datenverlust verbunden ist und daher eher nicht verwendet werden sollte.
also lieber raidz2/mirror über 3platten??
Debian-Nutzer :D

ZABBIX Certified Specialist

Benutzeravatar
sys_op
Beiträge: 672
Registriert: 17.09.2007 19:10:47
Lizenz eigener Beiträge: GNU General Public License

Re: Frage an Leute mit ZFS Kenntnissen

Beitrag von sys_op » 09.09.2016 10:13:45

So scheint es auszusehen? Bin natürlich momentan auch mit Informationen überflutet.
Das Ganze scheint eine Grad-Wanderung zwischen maximaler Platz bei höchstmöglicher Sicherheit zu sein.

Werde wohl (wie schon oben empfohlen) 5x6 disk raidz2 einrichten.
gruss sys;-)

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Frage an Leute mit ZFS Kenntnissen

Beitrag von r4pt0r » 23.09.2016 09:44:55

@sektorengröße:
Da diese alten Platten sicher nicht ewig weitergenutzt werden, sollten pools trotzdem mit 4k angelegt werden, sonst ist der Aufwand beim ersetzen der platten relativ hoch.

@expander:
Einfach mehrere HBAs. Die kann man auch schön gleichmäßig auf die CPU-Sockel bzw deren PCIe-Lanes aufteilen. Ich habe hier je einen HBA auf die PCIe-Lanes eines Sockets gehängt und die Platten der mirror auf die beiden HBAs verteilt. So wird die last optimal verteilt und ein HBA- oder CPU-Defekt könnte nur eine Hälfte der mirror offline nehmen oder beschädigen.
Packt man das System in ein eigenes 'kleines' Gehäuse (2-3U), kann man auch relativ einfach mit zusätzlichen HBAs + JBODs/"diskshelfs" den Pool um 8/16/32... Platten erweitern und auch das Controllersystem unabhängig ersetzen/erweitern.

@Raidz:
Das einzige "Problem", das aber erst bei stark fragmentierten/vollen Pools auftritt und an dem weiterhin gearbeitet wird (bzw einige große Patches sind IIRC bereits in FreeBSD-HEAD), sind write holes. OpenZFS hat in dieser Richtung auch schon viele Fortschritte gemacht - die meisten Horrorgeschichten beziehen sich auf Oracle ZFS, das in der Hinsicht kaum/keine Weiterentwicklung erfahren hat seit der Machtergreifung durch Oracle...
Ein resilvering von RaidZ ist relativ CPU- und Speicherintensiv - Probleme beim resilvering oder sehr (SEHR) lange Dauer sind meistens/immer auf ein zu schwaches System bzw zu hohe sonstige Lasten zurückzuführen. Ist das Resilvering so weit eingebremst, dass neue Daten und Metadaten schneller dazukommen als das resilvering vorhandene auf die neue Platte bringt, kann das durchaus nach mehreren Tagen/Wochen in einer kompletten Erschöpfung der Ressourcen enden.... Die Throttelingfunktionen werden momentan erweitert und sollen auch diese Problematik abdecken. Momentan wird AFAIK nur die Schreibrate in den SLOG gedrosselt, wenn der Pool nicht hinterher kommt und das SLOG-device vollläuft, und pendelt sich auf der Geschwindigkeit des Pools ein. Auch Throtteling/Lastverteilung bei Langsamen/Neuen vdevs wurde Überarbeitet und dabei auch die writehole-Problematik weiter reduziert.

Antworten