Administrace komentářů

Tak takového serveru bych se fakt bál. V jakém stavu jsou na něm data, to je ve hvězdách.

…s hardwarovým RAID řadičem…

Pozor, nic takového neexistuje. Je to chybný název, scam a pohádka. Takzvaný „hardwarový“ řadič má dvě „skvělé“ vlastnosti:

• Na AID1 bude vracet náhodně zničená data, když bude jedna z replik z jakéhokoliv důvodu zničená. Prokládané čtení vrátí tu platná data, tu zase neplatná, a nikdo nebude vědět, která jsou která.
• Na AID5 selhání kteréhokoliv jednoho disku zničí všechna data na všech discích, protože může nečekaně spustit resilvering a namíchat zničená data do distribuované parity i do datových bloků všude.

RAID se tomuhle↑ ve slušné společnosti neříká. Je to AID bez R.

Ideální by bylo vyměnit všechny disky v poli, ale to je až krajní možnost.

Bohužel existuje nesmyslná pověra, že se mají disky měnit najednou, že se mají kombinovat jenom disky podobného stáří a podobně. Máloco může být vzdálenější pravdě.

Takový nesmysl pak vede k potu a slzám — a kaskádám selhání. Když na starém RAID5 (neřkuli AID5) začne náročná oprava po náhradě disku, pravděpodobnost selhání dalšího disku je nepříjemně vysoká.

Proto je rozumné mít v RAID poli plánovanou rotaci disků. Jasně, zpočátku pole sestává z nových disků a je zdánlivě škoda je rotovat, ale takový už je život; buď chci dlouhodobý spolehlivý provoz bez náhlých dramatických událostí, nebo mám jiné priority…

Příklad rotace: Dejme tomu, že máme (skutečný) RAID (pozor, ne „hardwarový“ AID) s 8 disky. První dva roky se nechá běžet beze změn. Pak se každý kvartál vymění 1 disk, toho času nejstarší (nebo zpočátku jeden z nejstarších, dokud je ještě stáří některých disků stejné). Co tohle zajistí:

• Žádný disk není nikdy starší než 4 roky.
• Není nouze o nouzové náhradní disky; třeba ten, který byl vyřazený hned po dvou letech, může ještě jednoho dne zachraňovat svět.
• Nakonec to celé zkonverguje k rozdělení stáří disků od prvního do osmého kvartálu provozu — a díky tomu je i v případě výměny disků a různých dramatických selhání nižší pravděpodobnost, že přijde kaskáda selhání najednou.
• Proces výměny disků je známá rutina a v případné nouzové situaci (byť méně pravděpodobné než „obvykle“) je náprava rychlejší, s nižší pravděpodobností selhání lidského faktoru.
• Starosti, co s vadnými bloky a jestli a kdy, odpadnou, protože to do takové fáze zpravidla nedospěje.

Samozřejmě záleží na tom, jaké požadavky se na příslušný server kladou a kolik stojí (zbytečná a nečekaná a přesčasová) práce lidí v případě selhání ve srovnání s … koupí jednoho disku za kvartál. Bude tam značný nepoměr; zbytečná práce lidí je klidně o dva desítkové řády dražší.

├─sdb3                           8:19   0    1.6T  0 part
│ ├─rhel--raid5-root           253:0    0     32G  0 lvm  /
│ ├─rhel--raid5-swap           253:1    0     16G  0 lvm  [SWAP]
│ ├─rhel--raid5-home           253:5    0      2G  0 lvm  /home
│ ├─rhel--raid5-var            253:6    0     12G  0 lvm  /var
│ ├─rhel--raid5-tmp            253:7    0      4G  0 lvm  /tmp
│ ├─rhel--raid5-max            253:8    0     16G  0 lvm  /max
│ ├─rhel--raid5-max_maxp_homes 253:9    0     12G  0 lvm  /max/maxp/homes
│ ├─rhel--raid5-IDSDATA        253:10   0    120G  0 lvm  /IDSDATA
│ └─rhel--raid5-data2          253:11   0    1.4T  0 lvm  /data2

Tohle↑ je učiněná katstrofa. Zbytečné tříštění prostoru nedává nikdy smysl. Aby jeden proces nezabral druhému procesu celý disk, od toho jsou kvóty a podobné vymoženosti, které lze kdykoliv dynamicky upravit, trvale nebo dočasně, podle potřeby.

Co když bude /var jeden den potřebovat 13G místo 12G? S rozumným (ne)rozdělením diskového prostoru tohle není žádný problém. Upravím kvótu, uložím/vypočítám, co je potřeba, pak zase kvótu zredukuju. S touhle šíleností se z úplně běžné věci stává rocket science, zoufalství a hra na pacmana k tomu.

Jasně, že LVM dokáže (libovolně fragmentovaně) přidat k LV další bloky odněkud odjinud a v tom se pak dá nafouknout souborový systém — který rozhodně nemá být od volume managementu ani od RAIDu oddělený, leč u obsolete technooogií typu LVM bohužel je —, ale nechtěl bych něco takového podstupovat. Přesněji, v roce 2003 klidně jo, protože tenkrát bych musel. V roce 2023 už ne, protože … nemusím.