Dotaz: jak uspořádat 12 disků ( 3 řadče po 4 discích)

[hajoucha]

Ahojda,

máme ve stroji 3 řadiče (9650SE-4LPM) a na každém visí 4 disky (všechny jsou 4TB).

Zatím mám v umyslu vyrobit na každém řadiči raid10, čímž dostanu 3x8TB. Toto pak přes lvm spojím do jednoho 24TB svazku.

Požadavek je, aby se místo jevilo v systému jako jeden celek. Rychlost čtení ani zápisu nejsou podstatné. Naopak, zabezpečení proti ztrátě dat je žádoucí. Prostor bude využíván jako úložiště záloh.

Jak jsem pochopil, řadiče neumí spolupracovat v tom smyslu, že by člověk vyrobil např. raid10 nad všemi 12 disky.

Dovolil bych si poprosit přítomné odborníky o komentář, popř. radu. Předem velmi děkuji.

---

---

Odpovědi

[SpaceExplo]

Nevim jestli jsem uplne odbornik, ale zkusim pridat nazor:
- pri RAID 10 je zarucena funkcnost pole pri chybe jednoho(!) disku, pri vypadku dvou disku nesmi ty dva tvorit mirror
- pri RAID 6 je zarucena funcknost pole pri chybe jakychkoli dvou(!) disku
Radice by meli RAID 6 podporovat. LVM a spojeni disku do jednoho prostoru mi prijde v poradku.

Dalsi moznosti, za predpokladu ECC RAM, je uplne vynechat RAID funkce tech radicu, nastavit disky solo jako JBOD a pak nad nim stvorit nejaky "ZFS RAID" - ale osobne s tim nemam zkusenost, takze neumim rict jak optimalni to je.

[hajoucha]

aha, jasně. Takže buď raid6 a větší spolehlivost (odolnost proti výpadku 2 disků) anebo raid10 a větší rychlost (+odolnost proti výpadku 1 ev. se štěstím 2 disků). Je pravda, že podle zadání je tedy lepší raid6.

Poslepovat sólo disky mě popravdě nenapadlo.

[SpaceExplo]

Moznosti je dost, budto HW raid na tech radicich nebo nejaka forma SW raidu a ta se da udelat ruznou formou:
- LVM raid - tusim ze to nejak umi, ale neresil jsem to
- mdm raid - tedy "standardni" SW raid linuxu, at uz 1 nebo 10 nebo 5 nebo 6 atd
- ZFS raid - tedy device manager a file system v jednom, nejlepe asi s FreeBSD (zde kuprikladu FreeNAS, coz by pro zalohy bylo mozna nejlepsi a uzivatelsky privetive web-GUI reseni)
- btrfs raid - ten to mozna umi, nevim jiste, zatim jsem neresil

Dalsi vec k reseni, asi specialne u zaloh, by mohlo byt tema "Silent Data Corruption", kdy disk doda chybna data, aniz by o tom vedel - tohle resi prave ZFS (a btrfs tusim tez), ktere provadi kontrolni soucet nad prectenymi daty (proto se mu davaji primo jednotlive disky) - ale zde je samozrejme ECC RAM defacto nutnost (zatimco v jinych pripadech je to "jen" s o "neco malo" vyssim rizikem)

Casem sem urcite pristanou prispevky obhajujici jedno nebo druhe - ja bych doporucil si precist o tech resenich (zacal bych na wiki) a pak si vybral to, ktere ti bude nejlepe vyhovovat (mozna vcetne OS) - at uz z hlediska casove narocnosti osvojeni si prace, tak z hlediska pozadovane spolehlivosti.

PS: kdybych to mel resit ja osobne a ted hned, sel bych cestou mdadm raid, tedy SW raid v linux kernelu - jednoduse proto, ze ja s ZFS nemam prakticke zkusenosti a zaroven nemam rad HW-vendor-lock -> co se stane, kdyz jeden ten z tech radicu umre?:
- pri HW raidu musim sehnat stejnej radic a doufat, ze treba novej firmware neprohlasi to pole za "spatne"
- pri SW raidu muzu s tema diskama "hazet" sem a tam a dokud budou v systemu nejak viditelny (a to treba i z LiveOS linux boot), porad s nimi muzu nejak pracovat

[PetebLazar]

Podle nalezených specifikací to nevypadá, že by řadič uměl HW RAID6.

Nezaznělo tu jaká data mají na discích ležet, to může předjímat řadu věcí (Disky předpokládám nejsou míněna SSD).

RAID6 ať již SW či HW, v úvahách chybí hot-spare(y), pravda někteří na ně nevěří.

[PetebLazar]

Jsem to úplně nedočetl. Počítá se s nějakou retencí záloh? V takovém případě bych možná vytvořil nezávislá spolehlivá úložiště (RAID5?) na jednotlívých řadičích a využíval je pro zálohy nezávisle (ochrana proti selhání single point of failure v případě sloučeného úložistě). Pokud dojde k selhání v rámci jednoho úložiště mohou jej zastoupit další. Jaký bude objem, charakter záloh a režim zálohování?

[MP]

Tohle je ta nejdulezitejsi otazka, ktera tu mela zaznit - retence dat.

Druha nejdulezitejsi otazka je, pokud je pozadavek na nemit ztratu dat, je nekde offsite zaloha tech dat?

Treti otazka - jaka je pozadovana kapacita a dostupnost?

[PetebLazar]

Pozn. Pokud budou zálohy komprimované (tedy způsobem, který využívá vniřní CRC u komprimovaného obsahu) nebude obava o nezjistitelnou "Silent Data Corruption" asi na místě. Pokud k tomu na cestě/uložení/čtení dojde, archiv bude dekomprimačním procesem označen za porušený (pokud je dostatek času může být ověření datové konzistence tvorby/uložení záloh součástí zálohování). V takovém případě možná není potřeba nutit se do pokročilých FS (pokud tedy kromě detekce chyb nenabízí i opravu). Osobně bych se snažil řešení volit co nejjednodušší, aby riziko systematických chyb nepřesáhlo riziko těch nahodilých.

[Peter Golis]

To by ma tak zaujímalo ako CRC zabráni silent data corruption. Ak by to mal pravidelne kontrolovať nejaký proces (tak ako napr scrub na úrovni ZFS), tak sa nebude jednať o "silent" data corruption. A CRC ani neumožní zrekonštruovať poškodené dáta.

Nehľadiac na to, že legendy písané v marketingových materiáloch tvrdia, že každý jeden sektor na disku má zapísaný nielen obsah dát, ale aj ich kontrolný súčet.

[PetebLazar]

Psal jsem nezjistitelnou, ne napravitelnou. Pokud dojde ke změně dat při ukládání/čtení aniž si toho logika HDD/řadiče všimne (oba považují data z jejich pohledu za správná) kontrola CRC na úrovni archivu při dekomprimaci má šanci to zachytit, ne?

Btrfs a ZFS provádí po write automaticky verify (tj. ověřují si, co to co zapsaly)?

Objem ECC u moderních HDD představuje údajně asi 10% kapacity. https://en.wikipedia.org/wiki/Hard_disk_drive#Error_rates_and_handling

Nikde není řečeno, že zálohování musí probíhat proti jediné destinaci. Před cca dvaceti lety mi kolega popisoval praktiky z bývalého zaměstnání, kde byl tar archiv zálohy roztrojen a nasměrován na tři páskové mechaniky (DAT?). Výsledkem zálohování byly tři sady x-pásek, které se daly při recovery podle potřeby kombinovat.

Ty zmíněné řadiče disponují vcelku velkou cache (akumulátory jsou údajně volitelnými), takže by asi měla být s ohledem na jejich přítomnost(kondici) zvolena vhodná write policy.

[Peter Golis]

Pretože tie moderné pokročilé a moderné súborové systémy dokážu zrekonštruovať dáta aj pri poškodení nosiča. Silent data corruption by podľa tej wiki mal byť len mýtusom, ale nie je.

Mimochodom, odkedy mali páskové mechaniky DAT verify after write?

[PetebLazar]

"The worst type of errors are silent data corruptions which are errors undetected by the disk firmware or the host operating system; some of these errors may be caused by hard disk drive malfunctions while others originate elsewhere in the connection between the drive and the host.[62]" Označení za nejhorší chybu mi nezní jako označení za mýtus.

Ve svém příspěvku jsem to netvrdil že mají, ale vypadá to že ano. https://www.pctechguide.com/tape-storage/dat-tape-storage

Zajímalo mne zda ZFS/btrfs reálně kontrolují co zapíší na disk, nebo jen předpokládají že to zapsaly.

[Peter Golis]

Keby totižto tie disky reálne riešili checksumming, tak by silent data corruption neexistoval.

Páskové mechaniky ktoré riešili verify after write boli drahšie ako obdobné modely bez verify after write. A pri tom cenovom rozdieli už bolo rozumnejšie zainvestovať do novších LTO alebo podobných mechaník ktoré to mali v cene. Teda, okrem najlacnejších LTO1 kde bolo werify after write nepovinné.

V dnešnej dobe sa už ale prestáva hrať na páskové mechaniky kvôli času potrebnému na natiahnutie pásky, limitovanej rýchlosti zápisu a mechanickému opotrebeniu. Zálohovacie diskové polia hrajú na redundanciu zápisu, a majú nastavené pravidelné kontroly, o tom je ten pravidelný scrubbing. Ten to predsa rieši aj pri ZFS. Inak, zaujímalo by ma ako by podľa teba mal akýkoľvek FS skontrolovať či dáta boli korektne zapísané. Ak pri verifikácii tie dáta dostanú z cache radiča alebo cache disku.

[PetebLazar]

V pozdní době P-ATA disků jsme tuto featuru (Write-Read-Verify) možná opět meli (vypadá to, že při její aktivaci ke kontrole docházelo přímo v rámci logiky HDD). http://t13.org/Documents/UploadedDocuments/docs2006/e06121r0-Clarifications_for_Write-Read-Verify.pdf http://www.t13.org/documents/uploadeddocuments/docs2006/d1699r3f-ata8-acs.pdf

[Peter Golis]

To pochybujem. štandard ATA8 nebol pre PATA, a netýkal sa ani DDS/DAT pások.

[PetebLazar]

To PATA jsem asi špatně vyvodil z výskytu ATAPI v nadpisu dokumentace . Tak asi jde o ATA-8 ACS (SATA?). Byla to reakce na možnosti kontroly dat po zápisu na HDD (poslední věta Vašeho přechozího příspěvku), nezmiňoval jsem že se to týká DDS/DAT.

[Peter Golis]

Problém je že tá verifikácia už zapísaných dát na disku je kvôli performance implementovaná na allways ok.

[PetebLazar]

Možná, ale otázkou je proč by zase zástupce Seagate upozorňoval v dokumentu níže na degradaci výkonu při jejím zapnutí. http://t13.org/Documents/UploadedDocuments/docs2006/e06121r0-Clarifications_for_Write-Read-Verify.pdf

Také tato věta z dokumentu mi na dummy funkci moc nesedí. "If an unrecoverable error condition is encountered by the device during the write, read, or verify operation, the device shall set the DF bit. "

[Peter Golis]

To je dobrá otázka. Obávam sa že na ňu nájdeš odpoveď ak sa ti také niečo podarí zapnúť, a uvidíš reálnu degradáciu výkonu.

[Dacesilian]

Protože to máte jako úložiště záloh, tedy ne úplně kritické, asi by se hodilo více místa. Tedy můžete udělat ZFS RAIDZ-2. Budou vám moct odejít jakékoli 2 disky. Se ZFS mám výbornou zkušenost pod Debianem, používám ZFS i pro root partitions.

[Andrej]

Jak jsem pochopil, řadiče neumí spolupracovat v tom smyslu, že by člověk vyrobil např. raid10 nad všemi 12 disky.

Řadiče nemají proč spolupracovat a ideálně nemají dělat vůbec nic, kromě zpřístupnění jednotlivých disků, každého disku zvlášť.

Btrfs nebo ZFS pak zařídí libovolný RAID nad libovolným počtem řadičů a disků. Hardwarový „RAID“ dnes nemá smysl používat, protože:

• Je to ve skutečnosti pouze AID — je mnoho typů write hole a silent data corruption, které se bez těsné integrace RAIDu do filesystému nedají nijak obejít. O tom už jsem na ABCLinuxu psal asi tisíckrát, pročež se zde nebudu dopodrobna opakovat.
• Je to past — proprietární „řešení“. Zatímco skutečný RAID (Btrfs, ZFS) se dá přečíst přímo z disků na kterémkoliv jiném stroji, hardwarový AID má proprietární metadata, která nejsou nikde veřejně specifikovaná a po odchodu řadiče do věčných lovišť nebo po výměně řadičů za novější může být přenos či obnova dat horor.
• Existuje nesrovnatelně lepší řešení — skutečný RAID na úrovni filesystému, s checksumy, s odolností proti většině typů silent data corruption a s efektivním resilveringem (který se zabývá jen používanými bloky).

Résumé: Řadiče spolupracovat nemusí a ani nemají. Ideální je provozovat řadiče v režimu typu actuator a mít RAID na úrovni, kam patří — na úrovni filesystému.

[hajoucha]

díky za info. Příslušný řadič umí disky v modu _single_. Výhoda asi je využití cache (zálohované baterkou). Jak jsem napsal níže - mám tam 8GB RAM a nainstaloval jsem btrfs-tools verze 4.7.3-1~bpo8+1.

Nyní tedy zbývá otázka, jakým způsobem sestavit 12 disků. Rád bych odolnost proti výpadku 2 disků. Ale raid6 radí všichni zatím nepoužívat. Zbývá tedy raid10. Máte prosím doporučení ohledně tohoto?

Jinak moc děkuji za rady.

[Max]

Doporučuji ZFS RAID-Z2 (mohou odejít jakékoli dva disky), nebo RAID-Z3 (mohou odejít jakékoli tři disky).
Problém je tristní výkon bez vyhrazeného disku pro SLOG (takový žurnálek). Navíc díky CoW jsou i disky více zatíženy.
Oboje řeší vyhradit pro SLOG SSD disk. Nebo pokud má člověk ECC ram a zálohovaný server UPSkou, tak si může vyhradit část ramky, udělat z toho ramdisk a nastavit ho pro pole jako SLOG (stačí třeba 2GiB).
Dále platí, že co 1TB kapacity, to 1GB ram. Tzn. s méně, jak 8GB ram vyhrazené pro ZFS bych do toho nešel + ram pro systém a další věci(pokud to má nějaký režie).
Nicméně pokud toto má člověk pořešeno, tak dostane pěknou stabilní kapacitu s pěkným výkonem a kontrolou konzistence dat.
Zdar Max

[hajoucha]

hm, bohužel ta mašinka má jenom 8GB paměti. Takže zfs tím asi padá. Krom toho je tam fakt starý debian. Na druhou stranu btrfs tam lze nainstalovat (=už jsem to udělal) brtf-toos 4.7.3-1~bpo8+1.

Každopádně, moc díky za pomoc. Hezky se to vytříbilo.

[dustin]

12 4TB disků (i v jakémkoliv raid uspořádání) už bude docela velká kapacita. Jak budeš řešit zálohování?

Osobně bych volil ZFSoL. Resilvering řeší jen obsazený prostor a tudíž je obvykle podstatně rychlejší, než mnohahodinový rsync celého disku v mdraidu (obzvláště pokud bude pole zatížené provozem). Rovněž pro offline zálohování můžeš použít snapshoty a následně inkrementální zfs send/receive, který je u takto velkého storage hodně velká výhoda. Utility i jaderné moduly ZFS jsou spolehlivé, je s tím příjemná práce, věci se chovají tak, jak je zdokumentováno a očekáváno.

Časem můžeš přihodit SSD pro LARC2 keš (třeba i na PCIe) a výkonově to bude zase trochu jinde.

Pokud má stroj málo paměti, přidat, paměť je levná. Jinak si myslím, že by bez deduplikace mělo stačit i těch 8GB. Staré jádro to samé, budeš to určitě provozovat spoustu let, tak proč začínat se starými verzemi.

[hajoucha]

inu, zálohování nebudu řešit, protože nemusím. Bude to řešit někdo jiný. Moje prozatímní představa je, že právě tento prostor bude pro zálohy. Je jasné, že zálohy záloh jde vytvářet vždy a taky, že někde se to musí utnout.

Tím nechci říci, že otázka zálohování nemá smysl. Jenom na ni upřímně neznám odpověd. Pokud se mi podaří zabezpečit proti výpadku 2 disků, bude mi to na chvilku stačit. Klidně a rád se poučím a navrhu zálohování výše...máš-li radu, sem s ní.

[dustin]

To máte dobře rozdělené, ty nějak slepíš pole a někdo jiný ať si láme hlavu, jak tu obludu zálohovat.

Zálohování bych řešil do několika velkých disků do hotswap rámečků se ZFS raid0 (bez redundance), aby se vešel aktuální zaplněný prostor. A postupně přidávat další disky, jak bude potřeba. Pamatovat si poslední snapshot a od něj posílat jen inkrementální zfs send/receive. Nejlépe dvě sady offline disků, abys to měl celé pohlídané. Samozřejmě už začnou naskakovat ceny disků, ale tak to při takovýchto zálohovaných objemech holt je.

Nebo můžeš pásky, s tím ale nemám žádné zkušenosti. IMO si ale cenově moc nepomůžeš...

[Peter Golis]

Jedna kazeta LTO8 stojí cca 150$ a má 12T RAW, to cca 12$ za 1T. Zaujímalo by ma ktorý disk tomu dokáže konkurovať.

[dustin]

A kolik stojí mechanika? Jak se řeší inkrementální záloha typu zfs send/receive?

Disky (např. 3 x 10TB) může strčit do libovolného kompu a má hotové pole, ze kterého přinejhorším může celé storage rozjet (bez redundance).

[Peter Golis]

Mechanika LTO8 stojí okolo 3 až 5 tisíc. A inkrementálne zálohy sa s páskou riešia rôznymi spôsobmi. Kľudne si môžeš aj poslať snapshot na pásku.

Ale tie desaťterové disky, to myslíš že by bolo rozumné nahrávať väčšie objemy dát na disky zo šindelovým zápisom? To sa po chvíľke zápisu zasekne na pekne dlhú dobu.

[PetebLazar]

To zmíněné cenové rozpětí je uvedené v Eurech?

[dustin]

Proč by měl použít šindelový disk?

Např. 12TB Toshiba https://www.amazon.com/Toshiba-12TB-SATA-7200RPM-Enterprise/dp/B07DNVC4S6.

[Peter Golis]

Persistent Write Cache nevyzerá ako niečo, čo by nemaskovalo šindlový zápis.

[dustin]

Použij google. Např. https://bit-tech.net/news/tech/storage/toshiba-launches-first-14tb-cmr-hard-drive/1/

[hajoucha]

no, byl jsem zvědavý a tak jsem doinstaloval i zfs. Nahodím raidz2 přes 12 disků a uvidíme, jestli to bude použitelné s danou pamětí.

Jedinou otázkou zůstává, jak identifikovat disky. Na řadičích je každý disk jako "single unit". Ta má své sériové číslo, ale to zase v systému nevidím. Tam vidím jenom /dev/disk/by-id nebo ../by-path atp.

Máte ohledně toho nějaké doporučení?

[dustin]

Osvědilo se mi /dev/disk/by-id

 zpool  status
...
config:

	NAME                                          STATE     READ WRITE CKSUM
	tank                                          ONLINE       0     0     0
	  mirror-0                                    ONLINE       0     0     0
	    ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T1031176  ONLINE       0     0     0
	    ata-WDC_WD30EFRX-68EUZN0_WD-WMC4N0J25NCZ  ONLINE       0     0     0
	  mirror-1                                    ONLINE       0     0     0
	    ata-TOSHIBA_HDWD130_78FVP49AS             ONLINE       0     0     0
	    ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T1315714  ONLINE       0     0     0
	  mirror-2                                    ONLINE       0     0     0
	    ata-WDC_WD30EFRX-68AX9N0_WD-WMC1T1327418  ONLINE       0     0     0
	    ata-TOSHIBA_DT01ACA300_55C60GEGS          ONLINE       0     0     0
	  mirror-3                                    ONLINE       0     0     0
	    ata-WDC_WD60EFRX-68L0BN1_WD-WX11D77K745H  ONLINE       0     0     0
	    ata-ST6000VN0041-2EL11C_ZA1994N9          ONLINE       0     0     0
	  mirror-4                                    ONLINE       0     0     0
	    ata-TOSHIBA_HDWE160_17ARK09JF56D          ONLINE       0     0     0
	    ata-WDC_WD60EFRX-68L0BN1_WD-WX51D77EYZCS  ONLINE       0     0     0
	  mirror-5                                    ONLINE       0     0     0
	    ata-TOSHIBA_HDWN160_57GGK0CWFPAE          ONLINE       0     0     0
	    ata-ST6000VN0041-2EL11C_ZA199FF1          ONLINE       0     0     0

[hajoucha]

jo, /dev/disk/by-id je prima, akorát, že ten řadič to neumí vypsat. Tj. v command line toolu k řadiči tw_cli vytvořím "single unit" a dostanu:

 /c13/u2 show all
/c13/u2 status = OK
/c13/u2 is not rebuilding, its current state is OK
/c13/u2 is not verifying, its current state is OK
/c13/u2 is not initialized.
/c13/u2 Write Cache = on
/c13/u2 Read Cache = Intelligent
/c13/u2 volume(s) = 1
/c13/u2 name =                      
/c13/u2 serial number = K2ZEHN3U22769900E98E 
/c13/u2 Auto Verify Policy = on        
/c13/u2 Storsave Policy = balance     
/c13/u2 Command Queuing Policy = on        

Unit     UnitType  Status         %RCmpl  %V/I/M  Port  Stripe  Size(GB)
------------------------------------------------------------------------
u2       SINGLE    OK             -       -       p2    -       3725.28   

No a ten serial number se v systému nikde nevyskytuje. Ani by-id ani by-path ani by-uuid.

Můžu přidat vždy jeden "unit" a podívat se co přibylo. Akorát neumím donutit systém, aby se nové blokové zařízení objevilo jaksi hned. Když unit přidám nebo ev. odeberu, musím dát reboot, aby se věci dostaly do souladu. Teoreticky můžu 12x rebootovat kvůli 12 diskům, ale přijde mi to jako pěkná blbost....

[hajoucha]

dodám, že v systému se objevuje něco jako:

ls -lah /dev/disk/by-id
lrwxrwxrwx 1 root root   9 Dec 25 19:11 scsi-3600050e02267cf0000540000c0090000 -> ../../sdg

nebo

ls -lah /dev/disk/by-path
lrwxrwxrwx 1 root root   9 Dec 25 19:11 pci-0000:04:00.0-scsi-0:0:1:0 -> ../../sdg

[dustin]

Bohužel s takto "chytrým" řadičem nemám žádné zkušenosti. Používám obyčejné použité JBOD LSI, šlapou naprosto spolehlivě, okamžitá autodetekce při hotplugu atd.

Pro externí pole používám 2x https://www.ebay.com/itm/LSI-9201-16e-6Gbps-16-lane-external-SAS-HBA-P20-IT-Mode-ZFS-FreeNAS-unRAID-NoROM/162872615455, každá karta dává naplno 16xHDD (otestováno současně). Samozřejmě je to jen SATA2, pro SSD by to chtělo třeba SATA3 řadič na desce. Mám v nich max. 6TB disky, větší nemám.

Pro interní pole se mi osvědčily https://www.ebay.com/itm/New-LSI-Internal-SAS-SATA-9211-8i-6Gbps-8-Ports-HBA-PCI-E-RAID-Controller-Card/183509079623 s IT (nonraid) firmwarem. Opět jen SATA2.

[hajoucha]

aha, tak už vím:

lshw -class disk |grep serial: ukáže to samé sériové číslo jako

tw_cli /c0/u0 show serial. Tím je identifikace dána.

[alkoholik]

Zkusil bych neco jako echo "- - -" > /sys/class/scsi_host/hostX/scan nebo udevadm trigger.

[Michal2]

Pocital nekdo, zda je bezpecnejsi z 12 disku raid6 nebo 10? I treba z toho hlediska, ze obnova R6 je mnohonasobne delsi. Je vetsi sance, ze mi behem te doby odejdou 2 libovolne disky z 11 nebo ze odejde presne ten 1 z 11, ktery byl v tom mirroru?

[Max]

Reálně mám nasazený 4TB WD RE4/Gold s RAID-Z3, asi 12xHDD. Občas nějaký měním (chyby ve smartu apod.) a asi 3 roky a no problemo.
Když mi záleží na datech, tak fakt chci oželet 3 jakékoli disky v poli, než 1+n. Navíc mi jde i o kapacitu. Provozuji i ZFS s mirrory / RAID10 a silně přemýšlím, že to celé sjednotím. Rozbiju RAID-Z3 a i ten mirror a udělám z toho jedno velké pole, které budu skládat z RAID-Z2. Jinak nekupuju tam nic většího, než WD 4TB RE4/Gold.
Zdar Max

[jenjdukolem]

Boha jeho, jen sem na chvilku kouknu a co nevidím. To opravdu na štědrý večer nemáte lepší činnost než řešit nějaké harddisky?

[Michal]

Nechapu narazku. To jsou krestanske svatky, ateisti (pokud nejsou pokrytci) nemaji dnes co slavit, maji bezny den.

[Peter Golis]

Na vianociach ma vždy rozosmialo, ako kresťania veria že im vlezie do bytu hebrejec ktorý im dá niečo zdarma.

[Max]

Asi jsi chtěl říci "děti", né křesťani .
Zdar Max

[Peter Golis]

Je smutné, že to očakávajú nielen kresťanské deti, ale aj dospelí. A vo finále sa obdaruvávajú spotrebným materiálom.

[Max]

Věřit na nějakou bytost, která ti tajně donese dárek vs. očekávat obdarování od příbuzenstva aj. jsou dvě rozdílné věci. Osobně neznám žádného dospělého křesťana, který by věřil na : "ako kresťania veria že im vlezie do bytu hebrejec ktorý im dá niečo zdarma". Ale znám spoustu dětí (nedají se považovat ani za křesťany, páč je jich spousta nepokřtěna a o křesťanství a bohu nic nevědí) v předškolním věku, které na to samozřejmě věří. Až s příchodem na základní školu většinou přijde procitnutí.
Takže pokud se směješ křesťanům, kteří věří na : "ako kresťania veria že im vlezie do bytu hebrejec ktorý im dá niečo zdarma", tak by mně zajímalo, komu se tedy směješ, v jakých kruzích se pohybuješ, protože já nikoho takového mezi křesťany neznám.
Zdar Max

[Peter Golis]

Takže tí ľudia precitnú na strednej, a nielen prestanú očakávať darčeky? To mi znie ako utópia ktorá vylúčila konzum zo sviatkov slúžiacich na to, aby sa rodina konečne zišla aspoň raz ročne.

[Max]

Prosím? Umíš číst? Nic takového jsem nepsal. Jen jsem reagoval na to, jak se vysmíváš věřícím kvůli něčemu, v co snad nikdo z nich nevěří. Žádná střední, konzum ani další jsem nezmiňoval.
Ty vždycky něco plácneš, úplnou hovadinu, a následně pak začneš tahat diskusi úplně jiným směrem (buď si tu blbost pak uvědomuješ, nebo tě prostě jen baví psát šroty). Tímto jsem na toto téma skončil. Nebudu tady dál rozvíjet offtopic.
Zdar Max

[hajoucha]

Díky všem za reakce a rady. Pomohlo mi to ujasnit si řadu věcí (i o Ježíškovi :) ).

Nyní zbývá vyřešit, zdali umí btrfs na 12 disků vyrobit fs tak, aby data přežila kolaps dvou disků. Zpravidla se to označuje jako raid6, ale zrovna v případ btrfs zní doporučení raid6 nepoužívat. Je nějaká jiná volba pro btrfs?

Moc děkuji za případné rady. Včetně té, abych na to založil nový dotaz v poradně.

[Peter Golis]

Pokiaľ chceš moderný FS ktorý zvláda deduplikáciu, data checksumming a ukladá dáta redundantne, tak máš len málo mozností. Sú nimi ZFS, BTRFS a ReFS. Ku ReFS sa nevyjadrujem. Ale k ZFS len mierne podotknem:
Tá rovnica že 1T ZFS musí mať k dispozícii 1G RAM je dávno prekonaná, ale tradicionalisti to stále odporúčajú. Podobne ako odporúčanie o veľkosti SWAP ktorý mal byť jeden a pol násobkom RAM. To odporúčanie o veľkosti SWAPu platilo v minulom tisícročí.

[alkoholik]

S pocitaci pracuji uz dobrych 30 let a krome Golise NIKDY NIKDO netvrdil, ze swap ma byt 1,5x RAM.

[Peter Golis]

A kde som to podľa teba tvrdil, ak si pri tvojom vlastnom pseudonyme spomenieš?

[alkoholik]

Golisuv blabol:

Podobne ako odporúčanie o veľkosti SWAP ktorý mal byť jeden a pol násobkom RAM. To odporúčanie o veľkosti SWAPu platilo v minulom tisícročí.

Takove doporuceni neplatilo nikdy, existovalo totiz jenom v Golisove hlave.

[Peter Golis]

Takže to tvoje tvrdenie o mne nemáš ako doložiť. Musím uznať, vybral si si dobré meno.

[Max]

Jasně jsi napsal, že něco takového platilo, Alkoholik oponoval a ty jsi pak napsal, že jsi nic takového neřekl.
Vidím to stejně jako Alkoholik. Fakt nechápu tvé myšlenkové pochody. Každopádně vtipný to není.
Zdar Max

[Peter Golis]

Alkoholik tvrdil, že to odporúčanie bolo len v mojej hlave. To nebolo z jeho strany oponovanie, to bolo len potvrdenie presného výberu jeho dobrého mena.

Blbé je, že takým odporúčaním sa stále riadia bežné inštalácie súčasných distribúcií keď si človek vyberie "automatické rozdelenie disku". A ešte smutnejšie je, že aj pri distribúciách ktoré majú hibernáciu vo východzom stave vypnutú.

[k3dAR]

ktere soucasne distro pri instalaci s auto dava swap na 1.5x RAM?

[Aleš Kapica]

Tohle doporučení existovalo. Ovšem v době, kdy se množství paměti počítalo na megabajty.

V současné době, pokud máš 8GB RAM a více není swap nutný, pokud…

• nechceš uspávat systém na disk – pak by měl být o něco větší než je dostupné množství RAM
• nechceš zpracovávat velké grafické soubory – pak záleží na tom, s jak velkými soubory chceš pracovat,
• nechceš na svém stroji spouštět virtuály typu MS Windows
• nebo pokud nechceš na tom stroji povozovat disklessový systém.

Prakticky mám osvědčeno, že optimální velikost swapu je cca 20 GB pro 16GB RAM. Na virtualizačním serveru, ani u virtuálních strojů většinou swap nemám, protože je k dispozici dostatečné množství fyzické RAM.

[Max]

To spíš znamená, že by jsi si měl 16GiB do PC přikoupit :).
Zdar Max

[Aleš Kapica]

Tak to by šlo těžko. Kromě toho ti asi uniklo, že swap není totéž co sklerotická RAM.

[Max]

To, zda u ZFS platí 1GB ram na 1TB kapacity, závisí na spoustě faktorech. Závisí to na zaplnění disku, použité kompresy apod. V případě deduplikace je doporučováno odhadem 5GB ram na 1TB kapacity. Oracle na to má ukázku a návody na výpočet. Osobně jsem si počítal náročnost na ram pro mé ZFS pole v případě zapnuté deduplikace a došel jsem k nějakým 3,5GiB ram na 1TB kapacity (reálně použito čistě jen pro dedup, takže nutná ještě nějaká rezerva na další věci, pak těch 5GB vypadá opravdu rozumně).
Tím chci říci, že pokud si s tím člověk nechce lámat hlavu, tak 1GB ram na 1TB kapacity zajistí no problemo provoz bez dedup a se zapnutou kompresí. Pokud chce jet člověk na krev, tak si to musí spočítat, nebo minimálně hlídat. Poté je ale třeba si uvědomit, že se může dostat do stádia, kdy pole ani nepřipojí, protože nebude mít dostatek ram a jedním ze způsobů, jak se pak dostat k datům, je přikoupit ram. Prostě věc, kterou by člověk nerad zažil. Já to zažil, když jsem experimentoval s deduplikací.
Zdar Max

[Max]

Já to vidím takto :

1) HW RAID na všech řadicčích + LVM/btrfs na spojení

Všude na řadičích si vytvoříš nějaký druh pole a pak jednotlivé pole spojíš přes LVM, nebo v rámci btrfs (pokud by jsi chtěl snapshoty).

• jednoduchá výměna disků, člověk nemusí nic řešit, jen mění šuplíky
• špatný poměr failover/kapacita, protože v případě sestavení RAID10 ti může vypadnout 1+n disků (může jich vypadnout 6 a vše bude ok, ale také ti mohou vypadnout blbý dva a budeš v háji). Pokud to sestavíš z RAID5, tak jsi stále na 1+n. Pokud to sestavíš z RAID6, tak výkon bude tristní a kapacita jako u RAID10. Prostě nic moc.
• nepřenositelné nastavení (chcípne jeden řadič a co dál)

2) ZFS

Prostě disky do singlu a sestavit to přes ZFS RAID-Z2.

• Jednoduchý a přenositelný koncept, když chcípne řadič, dá se jakýkoli jiný s podporou přímého přístupu na disk a jede se dál, vlastně ani není potřeba řadič s hafec funkcemi, ale jen HBA
• mohou vypadnout jakékoli dva disky, v případě RAID-Z3 to mohou být jakékoli tři disky a není problém
• plná kontrola dat (checksummy, kontrola konzistence pravidelnými scruby atd.)
• nutnost aktuálnějšího kernelu a trochu více ram

3) BTRFS

Podobně jako u ZFS, jen se použije BTRFS.

• opět jednoduché sestavení a správa
• není problém s přenositelností
• Problém je RAID5/6, kde btrfs má stále problémy. V aktuálních kernelech už je spousta věcí vyřešených, ale i tak bych to do produkce asi nedal. Pokud je kernel starý, tak nemá smysl nad RAID5/6 u btrfs přemýšlet.
• v případě použití alá RAID10 jsme zase u problému failoveru 1+n

Pokud máš problém s tím, že na PC je starý kernel a nemůžeš natáhnout nic aktuálnějšího a zároveň chceš, aby ti mohly vypadnout jakékoli dva disky, tak na ZFS a BTRFS zapomeň.
Pak už ti tedy zbývá sestavit si pole pomocí fce řadiče, nebo přes Linuxový MDADM a na to pak hodit nějaký FS.

Osobně bych to v tvém případě řešil tak (pokud zadání odpovídá a není jiná cesta, tzn. 3x řadič a na nich po 4 discích a kernel nejde updatovat, aby šlo třeba použít ZFS), bych dal disky do singlu a sestavil nad tím dvě mdadm linuxový pole. Tzn. 6x4TB RAID6 + 6x4TB RAID6 a na to bych pak naladil btrfs, nebo pokud bych nechtěl snapshoty a chtěl lepší výkon, tak spojit přes LVM a na to hodit nějaký tebou preferovaný FS.
Výsledkem je pak velmi pěkná kapacita, přenositelnost na jiné řadiče a může vypadnout 2-4 disků a nic se neděje. Samozřejmě výkon u RAID6 není nijak oslnivý.
Zdar Max

[hajoucha]

jasný, vidím to stejně. Aktuálně jsem upgradoval tu mašinu na debian 9.6 a kernel 4.9.0-8-amd64. Taky jsem nainstaloval jak btrfs, tak zfs.

Zkouším vyexportovat disky jako "single units" a z nich sestavit pool pro zfs raidz2. Ovšem neumím exportovaným diskům přiřadit id. Takže když nějaký zdechne, jak ho pak fyzicky najdu? To je problém.

Teoreticky jsou 2 možnosti:

A/ najdu způsob, jak dostat správné info z řadiče i ze systému, tak abych disky identifikoval

B/ přídávat disky a "objevovat" je v systému. Následně udržovat tabulku (soubor), kde budu mít zapsáno, které "units" se v systému jeví pod jakým jménem...

Zkoušel jsem cestu B/, ale nechce se mi rebootovat pokaždé, když přidám "unit" v řadiči, a jinak se disk v systému neobjeví. Tedy alespoň ne tak rychle, jako trvá reboot...

Každopádně, ještě jednou děkuji všem za rady a pomoc. Super.

[Josef Kufner]

Disky si pojmenuj (PARTLABEL) a na disk si nalep štítek s tím názvem.