Správně zkombinovaný HW RAID + fajnové kastlíky na disky dají možnost blikat failure LEDkou, snáz se potom vyměňuje vadný disk. Tohle bývalo možné na bázi Areca + backplane alespoň TQ, nebo některé vzácné modely šuplíkových kastlí měly diskrétní failure vstupy pro LEDky.
Podobnou službu ale odvedou úplně jednoduché šuplíky, na které si zepředu nalepíte sériová čísla disků. Pokud nevíte, ve kterém šuplíku je který disk, musíte je měnit za studena. Každopádně bez šuplíků je velká pakárna měnit disk.
Taky není špatné, mít aspoň jeden volný šuplík (a kanál řadiče) navíc, na podání hot spare při selhání disku.
Zda je či není duševně zdravé, mít v RAIDu 22TB disky, to je otázka okolností a požadavků. Hranice nevkusu je relativní. Na nějakou skoro-studenou zálohu, která se tam bude odsypávat jednou za noc, tzn. režim "skoro páska", fakt úplně stačí jakákoli plechová krabice, ve které budou aspoň trochu slušné šuplíky (aby spolehlivě fungovala fyzická vrstva SATA na zvolené rychlosti a chlazení) a slušný napájecí zdroj = spolehlivý a s dobrou účinností.
Ano rekombinace nového disku po výměně bude dlouho trvat. Stejně tak pravidelná plánovaná automatická kontrola povrchu na pozadí. Tady se hranice "normálního" v průběhu let posouvá, protože rychlost přenosu roste zhruba s odmocninou z plošné hustoty záznamu na plotně, a počet ploten v poslední dekádě opět roste. Takže doba přečtení/zápisu celého disku se prodlužuje rychleji, než s odmocninou kapacity (tzn. téměř lineárně).
Pokud zvolený RAID bude 1 = mirror, nebo nějaká kombinace s nulou, nebo třeba hrst MD mirrorů předaných btrfs, a ten box bude víceméně přijímat zálohy přes něco jako gigabit, tak jako CPU stačí moderní ATOM (BayTrail+) a není tam ani potřeba moc RAMky. Jako že s 512MB by to běželo taky. A diskům se dá říct, aby po nějaké době nečinnosti zastavily rotaci (minimum bývala asi minuta). Tady bych ještě zmínil možnost, použít na systém flašku (nebo dvě v mirroru) a na rotující disky dávat fakt jenom data. Tím umožníte rotující rzi vydatně spát, pokud je to fakt jenom "náhrada pásky". Ušetříte za elektřtinu. Jenom pokud vezmete nějaký fakt desktopový boardík s ATOMem, tak bude mít nula až jeden slot PCI-e, a tato bude patrně x1. Existuje možnost, ten slot opatrně páječkou "otevřít" (protavit štěrbinu), nebo jsou redukce z MiniPCI-e (nevím jak M.2) na factory-proříznutou PCI-e apod. (Akorát skrz takovou redukci nejspíš budete muset PCI-e provozovat na rychlosti 1.1, takže úhrnná průchodnost na disky bude nějakých 250 MBps.) Tzn. tahle radikální punková integrace má svá úskalí :-D
Pokud ta věc má za jízdy počítat nějaká CRCčka nabo šifru nebo paritní RAID (5,6) tak je dobré se zamyslet, jakou sekvenční průchodnost má ten XOR/RS engine mít. Výkonnější procesor bude obecně rychlejší. Je ale možné, že nakonec by ten ATOM stačil taky. Chcete-li benchmark, tak "linuxové jádro" ho vypisuje při bootu, najdete ho v dmesg - v případě, že stroj při startu natahuje drivery z rodiny MD právě pro paritní RAIDy. Takové výpisy dmesg se válí různě v internetech.
Samozřejmě pokud ta věc má něco z dlouhé chvíle chroupat, nebo na tom chcete provozovat virtuály na takové to domácí žvýkání, tak si vyberte procesor podle svého gusta. Nakonec... ona nějaká microATX deska s úspornou variantou desktopového procesoru bude mít slot PCI-e x16 a alespoň 4 SATA porty onboard. Prostě větší svoboda, a spotřeba v idle nebude o moc horší, než ATOM. Ještě se nabízí otázka, zda zakazovat hluboké C-stavy (povolit max C1/C1e) nebo povolit i hlubší. Rozdíl v idlu můžou být jednociferné watty. U BayTrailu to byla navíc otázka stability. Taky se dá CPU podtaktovat, buď v BIOSu, nebo asi i volbou performance profilu v OS...
U velkých disků je potřeba se smířit s tím, že budou šindelové. Pokud je to "náhrada pásky", tak asi OK. Pokud RAID bude mirror a jeho deriváty, tak OK. Pokud RAID bude nějaký paritní, tak bych volil pokud možno dlouhou stripe size (stride size), abych zápisy zbytečně nekrájel ještě víc nadrobno. Šindele jsou svinstvo. Taky mám dojem, možná nepodložený, že MD RAID bude tolerantnější (než nějaký HW RAID) ke sklonu šindelových disků, "na chvíli se zamyslet".
Pokud nad tím má běžet virtualizace, tak opět: nečekejte, že šindelovým diskům naložíte nějaké zázračné IOps.
Taky jim tím znemožníte zastavovat rotaci, protože běžící neořezaný OS si neustále na systémový svazek něco málo "ublinkává". Loguje a tak. Mimochodem - mountuju poslední dobou převážně s "-o noatime".
Pokud nainstalujete Debian a balík mdadm a k tomu nějakého emailového démona (stačí exim, pokud ho umíte zkonfigurovat) a uděláte alias v /etc/aliases z lokálního roota na nějaký živý dohled, bude mdadm pravidelně (z cronu?) provádět preventivní čtení celého povrchu polí a případné nalezené problémy bude hlásit emailem. Akorát to kompletní přečtení může trvat déle než den, takže bych se kdyžtak mrknul, jak často ta kontrola běží, aby stíhala doběhnout :-) Taky se tím opět omezuje diskům procento času, kdy mohou spokojeně spinkat.
Linuxu a holým HBA je kapacita disků obecně wurscht. Rozsah LBA adresace v ATA a SCSI protokolech je mnohem větší než dnešních 22 TB. U hardwarových RAIDů jsem historicky zaznamenal, že starý firmware s novými velkými disky nefungoval správně (nečekal tak velkou kapacitu). Často pomůže update firmwaru - tento je dostupný, pokud řadič není druhohorní model (vintage hardware).
26 Odpovědí
8153 Zhlédnutí