SW RAID5 rozdělení oddílů

[redustin]

Ano, ale tazatel má RAID5 a jeho resync 17TB při 4 discích bude také minimálně 1 den.

[Reklama]

[_Jenda]

nezpochybnoval sem ze je zfs rychlejsi

Přesněji řečeno nezaplněné ZFS je rychlejší (protože syncuje jenom skutečná data, ne i zbytečně volné místo). Pokud bude mít ten RAID přiměřeně zaplněný (asi si nekupoval 16TB storage proto aby tam měl 15 TB nepoužitého volného místa , tak se ta data musí zkopírovat tak jako tak a vyjde to nastejno.

[ByCzech]

nezpochybnoval sem ze je zfs rychlejsi

Přesněji řečeno nezaplněné ZFS je rychlejší (protože syncuje jenom skutečná data, ne i zbytečně volné místo). Pokud bude mít ten RAID přiměřeně zaplněný (asi si nekupoval 16TB storage proto aby tam měl 15 TB nepoužitého volného místa , tak se ta data musí zkopírovat tak jako tak a vyjde to nastejno.

Přesně to jsem chtěl napsat po tom, co redustin posílal porovnání resync ZFS poolu zaplněného ze 7% oproti md RAID zaplněného ze 64%:

Konkrétní systém:

Kód: [Vybrat]

zpool list
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  24.5T  1.85T  22.6T         -    19%     7%  1.00x  ONLINE  -
...

Ve stejném serveru i MD RAID10 z 8 disků:

Kód: [Vybrat]

Filesystem      Size  Used Avail Use% Mounted on
/dev/md6         17T   11T  6.1T  64% /mnt/raid
Resync vadného disku skoro celý den, samozřejmě obojí za provozu.

Až to provede na podobně zaplněném ZFS, bude to mít větší relevanci. Disková pole o kapacitě větších TB nebo desítek TB se určitě nepořizují proto, aby zely prázdnotou a aby se na nic pak zkoušely simulace syncnutí disku po výpadku.

[redustin]

Ano, to pole je zaplněné jen z 10%. Jde o reálné použití, ZFS pole bylo od začátku připravené pro přesun toho MD raidu. Protože přesun  vyžaduje přejít z hardlinkovaného backuppc3 na metadatové backuppc4, zatím němu stále nedošlo. Mezitím v ZFS postupně odešly dva disky (na začátku již měly něco naběháno). Point je v tom, že rebuild trval řádově kratší dobu, než by trval rebuild celého disku v MD raidu. Rychlost zápisu při synchronizaci ZFS i MD byla srovnatelná. Čekal jsem hit na ZFS kvůli kopírování na úrovni filesystému, zatímco MD jede sekvenčně (RAID10), ale zřejmě je to na disku dobře uložené. Jelo to v klidu 100-150MB/s pro SATA, což je standardní limit disku.

Samozřejmě až bude ZFS plné, rozdíl nebude žádný. jenže stejně jako málokdo (dlouhodobě) provozuje pole zaplněné z 10%, málokdo buduje pole, které je hned na začátku plné...

[ByCzech]

Samozřejmě až bude ZFS plné, rozdíl nebude žádný. jenže stejně jako málokdo (dlouhodobě) provozuje pole zaplněné z 10%, málokdo buduje pole, které je hned na začátku plné...

...a málokdo buduje pole ze starých disků, které odcházejí chvíli po vybudování pole, dříve než je kapacita pole využita.

Prostě vaše srovnání od počátku smrdělo na sto honů 

[Reklama]

[redustin]

Ta chvíle už je nějaké dva roky :-)

[ByCzech]

Ta chvíle už je nějaké dva roky :-)

Jo a po dvou letech je to pole na 7% zaplnění své kapacity. Prostě úplně typické dvouleté pole, se staršíma diskama už v době prvního sestavená, v podstatě prázdné, za tu dobu už 2 disky měněné, elektriku zbytečně spotřebovávající 12 disků, když by na žitou kapacitu stačil jediný. Jak říkám, úplně typický příklad, na kterém se ukazuje resync disku po havárii, ale očividně k ničemu jinému praktickému to neslouží 

[redustin]

Představ si, že reálný život není jak z učebnice správců.

1) konsolidace dvou serverů na jeden do lxc kontejnerů. Disky dvou původních MD raid polí (pole A, pole B) přesunuté do 24-bay bedny
2) Přesun hodně dat z pole A do velkého pole B, protože A bylo plné.
3) Pole A překlopené do ZFS. Použito pár nových disků, aby šel přechod udělat.
4) Zbylé disky z pole A přidány do ZFS, aby bylo ZFS dost velké pro data z B.
5) Testování přechodu z backuppc3 na backuppc4 pomocí toho velkého pole. Ukazuje se, že konverze je velice pomalá (pole má stovky miliónů hardlinků) a zálohování by muselo být shozené příliš dlouho.
6) Testování zvol pro přesun celého XFS bez potřeby likvidace hardlinků - běží však příliš pomalu. Při tom muselo být ZFS samozřejmě dostatečně velké, aby se to tam celé pole B vešlo.
7) Odstranění 17TB zvol  - tedy ZFS zůstalo plné jen z 10%.
8 ) Mezitím nárůst jiných priorit, stávající řešení běží OK, ponecháno jak je.

ZFS pole je je pro data devel serveru (testy, CI, různé verze), běží na něm několik klonů anonymizované produkční DB pro devel. Výkonově klíčové DB mají data samozřejmě na SSD.

Celé to trvalo dlouho a od té doby také uplynulo dost času. Je spoustu jiné práce, než řešit pár nadbytečně běžících disků. Jednak je nelze ze ZFS odstranit, jednak se budou hodit, protože k přesunu z pole B dojde, až backuppc4 nabere trochu historie a bude možné pool z backuppc3 nechat jen jako soubor s obrazem přes loopback.

Samozřejmě z 10 disků jich časem pár umřelo, to je úplně normální. Nahrazují se rovnou dvojnásobnými, na nyní skoro prázdném ZFS jsou syncnuté za chvíli (narozdíl od MD raidu).

Takže odlož svou věšteckou kouli, máš ji rozbitou.

[ByCzech]

Představ si, že reálný život není jak z učebnice správců.
...
Takže odlož svou věšteckou kouli, máš ji rozbitou.

Já se nebavil o redustinovi, ale o tom, že redustin tvrdí, že dvouleté pole je typicky zaplněné na 7%, do dvou let se v něm běžně mění 2 disky, je složené od startu ze starých použitých disků a že je lepší aby na něm bylo ZFS než md RAID, protože resync ZFS je oproti md bleskový. Ne není, protože typicky taková pole neuvidíte.