Volba RAID a filesystému?

[Marty]

Upgradoval jsem disky v NASu a momentálně řeším, zda nezměnit RAID level, potažmo i filesystém.

Dosud jedu v konfiguraci 3x 1.5TB, každý disk je rozdělený na 3 partition: boot, root a data.

Disk /dev/sda: 1500.3 GB, 1500301910016 bytes255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x1dcebec5


   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63      514079      257008+  fd  Linux raid autodetect
/dev/sda2          514080     8530514     4008217+  fd  Linux raid autodetect
/dev/sda3         8530515  2930272064  1460870775   fd  Linux raid autodetect

boot je RAID1, root a data je RAID5. Momentálně je tam navíc jeden spare a brzy přibude druhý - a s tím právě řeším, zda neudělat nějaké změny.

Personalities : [raid1] [raid6] [raid5] [raid4]

md2 : active raid5 sdb3[3](S) sda3[0] sdc3[1] sdd3[2]
      2921741312 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]


md1 : active raid5 sdb2[3](S) sdc2[0] sda2[1] sdd2[2]
      8016256 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]


md0 : active raid1 sdb1[3](S) sda1[1] sdc1[0] sdd1[2]
      256896 blocks [3/3] [UUU]

Varianta 1. ponechat RAID5 na pěti discích bez spare. Výhoda: větší kapacita. Nevýhoda: menší zabezpečení.
Varianta 2. přejít na RAID6. Výhoda: dva paritní disky, tj. větší bezpečnost. Nevýhoda: menší kapacita (ale nevidím to jako problém). Nejsem si jist: výkon rebuildu (liší se nějak rebuild na RAID5 a RAID6?)
Varianta 3. přejít na jiný typ RAID (extrém: 2x1+0 & 1 spare)


Možná rozšíření všech variant:
a) vyhodit boot a root, přesunout je na SSD. Data nechat na plotnových discích s jednou z výše uvedených změn.
b) upravit partitiony, rozsekat na víc menších - kvůli možnosti dělat dílčí rebuild?

Priority jsou momentálně spíše bezpečnost. Když jsem si s tím o víkendu hrál, tak jsem sice měl odzálohováno, ale při 12h rebuildu největší 2.7TB partition jsem přesto neměl dobrej pocit. Kdyby se mi tohle stalo za provozu, asi úplně nadšenej nebudu...

Jinak je tam všude ext4 (ponechat??), vše běží na Atomu a systémem je Debian testing. RAID řeším pomocí mdraid.
Na datové parition je cca. 700 GB foto archiv, a zhruba dvojnásobné množství videoarchivu - tolik asi k charakteru dat.
Minoritně tam mám pár image pro iSCSI řádově desítky GB.

[Gargamel]

Upgradoval jsem disky v NASu a momentálně řeším, zda nezměnit RAID level, potažmo i filesystém.

1. vraz tam GPT misto MBR
2. Linux raid autodetect funguje jen se starym mdraid superblockem, doporucuju dat tam novejsi verzi a pole sestavovat v initrd fazi

Možná rozšíření všech variant:
a) vyhodit boot a root, přesunout je na SSD. Data nechat na plotnových discích s jednou z výše uvedených změn.
b) upravit partitiony, rozsekat na víc menších - kvůli možnosti dělat dílčí rebuild?

a) SSD neni vsemocne a zaloha se hodi. Stacil by mozna obcasny rsync, abys mel zachovany vykon SSD.
b) podle me je to blbost, neprinese to zadny benefit. To uz si tam rovnou nasad LVM pokud chces takhle experimentovat.

Když jsem si s tím o víkendu hrál, tak jsem sice měl odzálohováno, ale při 12h rebuildu největší 2.7TB partition jsem přesto neměl dobrej pocit. Kdyby se mi tohle stalo za provozu, asi úplně nadšenej nebudu...

Tak ono je celkem normalni, kdy v datacentrech v prubehu rebuildu pole chcipne dalsi disk...

Jinak je tam všude ext4 (ponechat??)

Znicit krtka, ext4 diky poslednim nekolika fuckupum (a vlastni zkusenosti) nepovazuju za stable fs. Bohuzel v dnesni dobe neni moc na vyber, btrfs potrebuje jeste tak 5 let vyzrat a o reiserfs se bohuzel uz nikdo nestara. JFS je otazkou. Lidi chvali ZFS na FreeBSD a klonech Solarisu, pod linuxem mam zatim nejlepsi dlouhodobe zkusenosti s XFS. Jeho kvality dokazuje i planovane nasazeni v enterprise systemech (vic rict nemuzu, NDA). Vyber se dale zuzuje, planujes-li nasazeni SELinuxu nebo extenzivniho pouzivani xattrs, v obou pripadech bacha na velikosti inodu.

[Marty]

Hmm, GPT je dobrá připomínka - v horizontu několika let rozhodně budu přecházet na nové/větší disky, takže budu GPT patrně potřebovat.
Problém je ale bootování, pač deska neumí UEFI. To bych ovšem mohl obejít tím, že bych dal systém na SSD a tam zachoval MBR.

Tj. mi z toho vyplývá:
1. systém na SSD (+ zálohovat, to se rozumí samo sebou )
2. data na RAID-6 s XFS na discích pod GPT, jedna společná partition

A má to ještě jednu výhodu, plotnové disky se můžou suspendovat, když zrovna na data nebude přistupováno. Nějaké výhrady k tomuto? Nemůže se pole rozsypat, pokud disky usnou (a neprobudí se synchronně či co by mohlo nastat)?

[Gargamel]

Problém je ale bootování, pač deska neumí UEFI. To bych ovšem mohl obejít tím, že bych dal systém na SSD a tam zachoval MBR.

GPT neni nutne s UEFI svazano, treba GRUB umi v BIOS rezimu z GPT bootovat. Vytvari se BIOS-kompatibilni partition table. Viz. treba https://wiki.archlinux.org/index.php...artition_Table

2. data na RAID-6 s XFS na discích pod GPT, jedna společná partition

Pokud tam budes mit jen jednu partition na disk, vubec partition table nepotrebujes a muzes do pole naskladat primo /dev/sda /dev/sdb /dev/sdc.

A má to ještě jednu výhodu, plotnové disky se můžou suspendovat, když zrovna na data nebude přistupováno. Nějaké výhrady k tomuto? Nemůže se pole rozsypat, pokud disky usnou (a neprobudí se synchronně či co by mohlo nastat)?

To by nemel byt problem. Kazda vrstva ma urcity timeout, do ktereho ten disk musi byt ready. A da se to asi taky tweakovat. Suspendovani ale neni moc vyhodne, disky neustalym roztacenim trpi a jednou za cas si filesystem musi usyncnout To se da taky vyladit, ale pak hrozi ztrata dat cim delsi mas interval (s UPS asi problem odpada).

[Marty]

Pokud tam budes mit jen jednu partition na disk, vubec partition table nepotrebujes a muzes do pole naskladat primo /dev/sda /dev/sdb /dev/sdc.

To vypadá dobře, jen jak se to zachová, až tam za dva roky přidám 4TB disk a budu ho chtít přidat do stávajícího pole a vhodně využít kapacitu?
V modelu s partitionama bych na novém disku udělal partition požadované velikosti, postupně disky povyměňoval a až bych měl všechny o stejné velikosti, zdrojové partition bych zvětšil přes celý disk (celé disky). Ale tím bych si asi rozesral to pole, hm.

Takovej malej dotaz, jakou máš konfiguraci ty na tom tvém serveříku? kolik disků, jaké partition a tak?

[Fox!MURDER]

Hmm, GPT je dobrá připomínka - v horizontu několika let rozhodně budu přecházet na nové/větší disky, takže budu GPT patrně potřebovat.
Problém je ale bootování, pač deska neumí UEFI. To bych ovšem mohl obejít tím, že bych dal systém na SSD a tam zachoval MBR.

Tj. mi z toho vyplývá:
1. systém na SSD (+ zálohovat, to se rozumí samo sebou )
2. data na RAID-6 s XFS na discích pod GPT, jedna společná partition

A má to ještě jednu výhodu, plotnové disky se můžou suspendovat, když zrovna na data nebude přistupováno. Nějaké výhrady k tomuto? Nemůže se pole rozsypat, pokud disky usnou (a neprobudí se synchronně či co by mohlo nastat)?

RAID is not a backup solution. RAID je dobry jen na to, ze system dal funguje, kdyz jedna cast odejde.
Takze pokud ti jde o bezpecnost dat, zalohuj. Nejlip na neco offline.

GPT+MBR se da zkombinovat tak, ze na prvni kus disku lezes diky mbr a na zbytek pres GPT ... mas tak "vyhody" obou svetu ...

[Marty]

Zálohovat samozřejmě zálohuju, ale nevim, jak efektivně zkombinovat problém "offline" a objem dat. Dosud jsem to řešil prostým zkopírováním dat na externí HDD, ale strašně mně to štve - v pátek večer k serveru připojit externí disk a v neděli ho zas odpojit, s tím, že se to přes víkend nějak zazálohuje?
Nicméně to je téma na jinou (ne nezajímavou) diskuzi...

RAIDem se samozřejmě chci vyhnout části práce s pravidelnějším zálohováním. RAID mi totiž pomůže v tom, že nebudu při správném používání tu zálohu pokud možno vůbec potřebovat. (BTW mate mě, že se dneska jako zálohovací zařízení používají disková pole, která jsou stejně stále online - možná kvůli ceně, a opticky se tak stírá rozdíl mezi aktivním úložištěm a záložním úložištěm)

[Gargamel]

To vypadá dobře, jen jak se to zachová, až tam za dva roky přidám 4TB disk a budu ho chtít přidat do stávajícího pole a vhodně využít kapacitu?
V modelu s partitionama bych na novém disku udělal partition požadované velikosti, postupně disky povyměňoval a až bych měl všechny o stejné velikosti, zdrojové partition bych zvětšil přes celý disk (celé disky). Ale tím bych si asi rozesral to pole, hm.

Myslim, ze je lepsi koupit nove disky a data prekopirovat, pri takovych experimentech muzes data ztratit. Z principu blokovych zarizeni v unixu muzes klidne kombinovat /dev/sda, /dev/sdb1 a treba i /dev/loop0 nebo /dev/shm, neni v tom rozdil. Velikosti blokovych zarizeni by mely sedet nebo byt vetsi, pro nektere typy poli to asi neni nutne (RAID0 linear). Kvuli flexibilite mame prave LVM, prip. nove vlastnosti btrfs (a ZFS).

mdadm ma moznost shrink a grow, ale osobne bych se do toho nepoustel. Resizovat filesystem na vetsi neni problem, resizovat pole bude, zase v zavislosti na pouzitem typu RAIDu. Nicmene uvedom si, ze treba u tridiskoveho RAID5 by ti pak vznikly dve mezery uprostred pole a to zadny filesystem nerozdejcha, mdraid by se s tim musel nejak poprat a namapovat si vzniklou nelinearitu (ale kam si to ulozi? v superblocku moc mista nema).

Takovej malej dotaz, jakou máš konfiguraci ty na tom tvém serveříku? kolik disků, jaké partition a tak?

Nic extra, dva disky jsou nezalohovane a na dalsich dvou je nekolik mdraid RAID1 partitions. Mirrorovany boot, root, home a dulezity storage. Zalohy techto dat neresim, mam tri stroje, maily balim z workstationy na server, fotky mam na workstatione a ext. discich. Prip. lehky rsync v cronu.

[Fox!MURDER]

Nicmene uvedom si, ze treba u tridiskoveho RAID5 by ti pak vznikly dve mezery uprostred pole a to zadny filesystem nerozdejcha, mdraid by se s tim musel nejak poprat a namapovat si vzniklou nelinearitu (ale kam si to ulozi? v superblocku moc mista nema).

Diry?

btw. ZFS je peknej filesystem, ale taky ma svy mouchy. napr. to resizovani neni uplne idealni (i kdyz, jak rika Gargamel, ono je lepsi neresizovat), nebo afaik nepodporuje poradne discard.

Na druhou stranu je docela fajn podpora snapshotu. Pokud toho moc nezapisujes/nemenis (coz jsem pochopil, podle typu dat, to nebude tak hrozny), muzes delat snapshoty a inkrementalni zalohy.

[PetrT]

Dovolím si se sem (jako noob) vcucnout
a) resize RAID5 jsem Marty nakonec nedělal, po propočtu času rebuildů mi vyšlo jako mnohem rychlejší vytvořit na druhém PC z nových disků RAID5 a data prostě po síti přehrát. Pak jsem jen v serveru prohodil disky a upravil konfiguraci.
(zda je to použitelný postup nebo prasárna nechť posoudí znalci).

b) důvod mé účasti: abych uvolnil jeden SATA port, nainstaloval jsem Ubuntu server (postupně poslední tři verze, aktuální je 13.04) na USB3.0 FlashDisk. Disk je rozdělený na tři pártišny: 16GB root (ext4), 4GB Swap a 12GB data(ext4). Bohužel se mi už 3x stalo, že se na rootu objevily chyby, kvůli kterým přestaly některé služby fungovat (a tak jsem přišel na problémy). Poprvé stačilo po rebootu udělat scan rootu a nechat chyby opravit. V dalších případech (dnes poslední) jsem musel nabootovat z LiveCD a opravit root z jiného linuxu. Je mi jasné, že tímto použitím půjde flashdisk časem do háje, ale čekal bych to na swapové či datové partišně (kde jsou zápisy hodně časté) a ne na rootu (kde se zapisují snad jen 2 logy).

Syslog dnešní chyby nezaznamenal a v jakém dalším logu hledat netuším. Dá se s tím něco dělat a nebo samotné nainstalování systému na flashku je magořina a v mém vlastním zájmu bych se na to měl vykašlat?
(google něco našel, ale moc moudrý z toho nejsem).

[Gargamel]

Dá se s tím něco dělat a nebo samotné nainstalování systému na flashku je magořina a v mém vlastním zájmu bych se na to měl vykašlat?

Presne tak.

b) důvod mé účasti: abych uvolnil jeden SATA port, nainstaloval jsem Ubuntu server (postupně poslední tři verze, aktuální je 13.04) na USB3.0 FlashDisk. Disk je rozdělený na tři pártišny: 16GB root (ext4), 4GB Swap a 12GB data(ext4). Bohužel se mi už 3x stalo, že se na rootu objevily chyby, kvůli kterým přestaly některé služby fungovat (a tak jsem přišel na problémy). Poprvé stačilo po rebootu udělat scan rootu a nechat chyby opravit. V dalších případech (dnes poslední) jsem musel nabootovat z LiveCD a opravit root z jiného linuxu. Je mi jasné, že tímto použitím půjde flashdisk časem do háje, ale čekal bych to na swapové či datové partišně (kde jsou zápisy hodně časté) a ne na rootu (kde se zapisují snad jen 2 logy).

USB neni extra stabilni a muze se stat, ze se zarizeni resetne nebo odpoji uplne. Typicky pri nejake napetove spicce, sumu, se USB porty rady resetuji. Ta flashka taky nemusi byt stavena na 24/7 provoz a radic muze delat psi kusy. Navic USB flashky a pametove karty maji ruzne optimalizace pro FAT, tzn. prvnich nekolik sektoru je fyzicky ulozeno na jine pameti (v radici) atd.

[PetrT]

Díky za názor. Včera se zase poškodily nějaké soubory a ani po opravě disku systém nenajel. Takže právě teď instaluju nový systém na 32GB SSD. Tam snad problémy nebudou.