Migrujeme systém na RAID1, novinky v mdadm, cache, bariéry (1/2)

10. 7. 2013 | Max Devaine

Články - Migrujeme systém na RAID1, novinky v mdadm, cache, bariéry (1/2)  

Doušek teorie, od každého trochu, ničemu neuškodí. Dnes si odhalíme nějaké aktuální informace o mdadm, diskových aj. cache a implementaci bariér v Linuxu.

Obsah

• LVM vs. mdraid
• I/O bariéry a cache
• SWAP v RAID1, nebo pri=1?
• Pole přes celý disk, nebo jen partition?
• Mdadm a metadata
  • Podpora metadat v bootloaderech
  • Rozdíly v metadatech
  • Bitmap: external vs. internal
• Závěr
• Zdroje

LVM vs. mdraid

Když chceme migrovat systém na pole, tak co použít? LVM s funkcí RAID1, nebo klasické pole pomocí mdadm? Záleží na tom, co od čeho člověk očekává. Pokud chceme jen data stripovat (RAID0), tak můžeme s klidem využít LVM.

Nejčastějším případem pole je ovšem RAID1, na který budeme v článku migrovat. Ještě relativně nedávno nemělo LVM kompletně implemetované write bariéry, což v případě výpadku proudu mohlo u žurnálovacíh fs přinést nemilé překvapení (nebo menší výkon). Od jádra 2.6.33 by je mělo již mít plně implementované.

Nicméně, stále tu máme lehkou nevýhodu v tom, jak se chová LVM k disku, jenž nějakým způsobem zlobí (vadné bloky, notifikace apod.). Dále LVM podporuje jen RAID0 a RAID1. Nejlepší je, vydat se ověřenou třívrstvou cestou. Tedy udělat si pole pomocí mdadm, na něm LVM oddíly a ty pak naformátovat na nějaký FS.

I/O bariéry a cache

Zmínili jsme se o bariérách, co to vlastně je? Write bariéry umožňují využívat diskové cache (a obecně cache) bez rizika poškození souborového systému. Write bariéry je vhodné kvůli lepšímu výkonu používat jen v případě, že cache nemáme zálohovanou baterií (viz BBWC – Battery Backed Write Cache moduly pro řadiče apod.), protože dosáhneme lepšího výkonu než bez použítí cache. Zároveň ale dosáhneme menšího výkonu, než kdybychom používali cache bez write barirér (v případě, že máme cache zálohovanou baterií se nemusíme o nevyřešené zápisy bát a tak nám jsou write bariéry zbytečnou přítěží).

Jednoduchý souhrn doporučení:

cache off, battery off => barriers off
cache on, battery off => barriers on
cache on, battery on => barriers off

Záznamy o bariérách je možné vidět třeba v dmesg :

dmesg |grep barrier
[    2.372547] reiserfs: using flush barriers
[   12.331953] reiserfs: enabling write barrier flush mode
[   12.423573] reiserfs: using flush barriers
[   55.781925] reiserfs: using flush barriers

Jak je to s tou cache?
Každý disk má cache. Každý lepší řadič má také svou cache. Když připojíme disk k řadiči, který má cache, tak řadič automaticky deaktivuje cache na disku a používá se ta na řadiči, kterou lze zabezpečit baterií (BBWC) a bývá také mnohem větší (512 MiB, 1 GiB, 2 GiB apod.).

Ruční zapnutí a vypnutí cache na disku se provádí pomocí programu hdparm:

# info o cache na disku:
hdparm -W /dev/sda

# zapnutí cache:
hdparm -W1 /dev/sda

# vypnutí cache:
hdparm -W0 /dev/sda

Pokud jde o cache na řadiči, tak to funguje většinou tak, že pokud není dostupná zálohovací baterie (BBWC modul), nebo není baterie úplně nabitá, tak se cache automaticky vypne a nedovolí zapnutí (záleží na řadiči a konkrétním firmware). Taktéž umožňují řadiče cache optimalizovat pro zápis nebo pro čtení. Máme tedy 100 % cache a podle využití stroje můžeme věnovat třeba 70 % pro čtení a 30 % pro zápis.

Zapnutí/vypnutí bariér u jednotlivých FS:

# ext3 on/off:
mount -t ext3 -o barrier=1 /dev/sda1 /mnt/disk
mount -t ext3 -o barrier=0 /dev/sda1 /mnt/disk
# ext4 on/off:
-o barrier=1 / -o barrier
-o barrier=0 / -o nobarrier
# xfs on/off:
-o barrier
-o nobarrier
# reiserfs on/off:
-o barrier=flush
-o barrier=none
# btrfs:
-o nobarrier

# více v parametrech připojování u konkrétních fs popsaných v:
man mount

Řešíme tu bariéry, ale ve skutečnosti je řešit nemusíme. Když dochází k připojení FS, tak ten sám provádí několik testů, a když se mu něco nelíbí, tak si bariéry vypne. Na druhou stranu je dobré vědět, co se děje .

Bariéry byly přidány do linuxu 2.6.16, vizte Documentation/block/barrier.txt a zápisek „Understanding Linux block IO barriers“.

SWAP v RAID1, nebo pri=1?

Mít swap na poli, nebo mít na každém disku jen oddíl se swapem a mít dva záznamy pro swap v /etc/fstab a pro každý swap definován pri=1? Co vlastně dělá pri=1?
Dost často se člověk mohl na internetu dozvědět zaručené informace typu: swap není třeba mirrorovat, stačí, když se na obou discích nechají menší oddíly a dá se do fstab pri=1, nějak takto:

...
/dev/sda3     swap   swap      defaults,pri=1     0      0
/dev/sdb3     swap   swap      defaults,pri=1     0      0

nebo-li :
swapon -p 1 /dev/sda3
swapon -p 1 /dev/sdb3

Bohužel, toto není řešení, toto se spíš chová jako RAID0, výkonově určitě dobrá věc, ale v případě chyby na jednom z disků by systém nemusel dopadnout pěkně. Kdo chce tedy plně využít RAID1, tak na něj musí hodit i swap. I já jsem v dávných začátcích udělal chybu a párkrát jsem tuto dezinformaci (získanou od „zaručených“ zdrojů) šířil aniž bych se nad tím trochu zamyslel.

Pole přes celý disk, nebo jen partition?

Mirrorovat lze celé disky, nebo samotné partitions (oddíly). Záleží čistě na vás, pro co se rozhodnete. Můžete rozkouskovat disk a mirrorovat jednotlivé partition a nepoužívat LVM. Zde může být výhoda třeba v tom, že v případě nějakého šumu dojde k rozbití pole, tak se může rozbít jen jedno (jedna partition) a případný sync trvá kratší dobu, než kdyby se syncoval celý disk (za předpokladu nepoužití bitmapy).
Můžete mirrorovat celé disky a nad nimi mít LVM, nebo je jen standardně rozkouskovat. Každé řešení má nějaké pro a proti a je důležité vědět, co od konkrétního řešení očekáváte a podle toho se pak rozhodnout.

Ti, co by rádi měli v poli celé disky, se také mohou zamyslet nad jednou věcí. Buď mít pole nad celým diskem, nebo nad celým diskem vytvořit jednu partition a tu mít v poli. Výhodu to má tu, že partition si můžeme udělat o fous menší a mít tak jednotnou velikost na všech diskách. Poté se nemusíme bát, že nám odejde disk a nový bude mít o fous menší kapacitu a už se nevejdeme a do pole nepůjde přidat.

Mdadm a metadata

A teď vysvětlení té srandy, které se říká metadata. Metadata mají v sobě informace o poli, jak se má složit, seznam vadných bloků atd.

V současné době máme k dispozici čtyři verze metadat: 0.90, 1.0, 1.1, 1.2

Podpora metadat v bootloaderech

Grub-legacy nepodporuje verze 1.1 ani 1.2 metadat. Lilo taktéž nepodporuje verze 1.1 ani 1.2 metadat. Současná verze zavaděče „syslinux“ podporuje maximálně verzi metadat 1.0. Grub2 v klidu zvládá i metadata 1.2.

Tady bych udělal menší vsuvku kvůli grubu2. Je to docela otesánek a rozhodně bych nezačínal první partition na 63 sektoru, ale jel dnešní klasiku od 2048. sektoru (i když se nebude jednat o 4k formát / disk / ssd), aby se vše potřebné vešlo do stage1.5.

Rozdíly v metadatech

Proč tolik verzí metadat? Proč v tom dělat guláš? Na metadata se začalo tak trochu sahat hned z několika důvodů.

• Formát metadat nešel moc dobře rozšiřovat.
• Verze metadat 0.90 má omezení na 28 zařízení v poli a s RAID1 lze vytvořit maximálně 2TB pole.
• Dále tato stařičká verze trpí nepřenositelností (datové objekty jsou jaksi konstruované tak nešťasně, že závisí na architektuře).
• Ve verzi metadat 1.0 byla odbourána designová omezení starší verze 0.90.
  Metadata má stále na konci disku (od konce 8K-12K) – to je užitečné pro RAID1 pole, protože RAID a non-RAID filesystém začíná na stejném místě, takže pokud nestartuje pole, tak můžete partition připojit klasicky jako filesystém v režimu read-only a dostat se tak k datům.
  Toto umístění metadat má také malé riziko, metadata se mohou přepsat/poškodit. Pokud md nenaběhne a dojde k připojení filesystému v režimu rw, pak hrozí, že se může právě něco zapsat na konec disku a poškodit tak metadata, stejně tak při připojení v režimu rw může dojít k nekonzistenci dat a rozpadu pole.
• Minoritní verze 1.1 a 1.2 pak přinesly jiné umístění metadat na disku.
• Verze 1.1 má metadata na začátku disku – to už je dobrá prevence před nechtěným zničením metadat, ovšem také nastává problém s připojením filesystému bez nastartovaného pole (už jen tak nejde připojit fs v read only režimu jako u starších verzí metadat)
• Verze 1.2 má metadata 4K od začátku disku – toto má výhodu v tom, když se např. vytváří pole přes celý disk, tak se tím nezasáhne do části rozdělení disku, mbr apod. jako u verze metadat 1.1

Takže co kdo má použít za verzi metadat?
Je to jednoduché, pokud používáte grub2, na záchranných Live CD a zmíněném stroji máte k dispozici dostatečně nové jádro a mdadm, tak vám v používání verze 1.2 nic nebrání. Taktéž není problém kombinovat verze metadata. Vytvořit si boot oddíl a na něj umístit starší metadata (třeba kvůli zavaděči) a na systémový nebo datový oddíl použít aktuální verzi metadat. Je to zcela na vás .

Každopádně doporučuji s verzí metadat pracovat (udávat verzi do konfiguračních souborů apod.), ať člověk celou dobu ví, na čem je, a ať to také ví za X let (kdyby se třeba pole pokazilo a budou k dispozici zálohy nastavení, tak člověk hned ví).

Aktuální stav a verzi metadat jde vyzjistit takto (příklad):

mdadm --detail --scan
ARRAY /dev/md2 metadata=1.2 UUID=14640e9e:d1c30960:5b020607:1eecbc2b
ARRAY /dev/md3 metadata=0.90 UUID=1d4bfb10:2b00fef9:5b020607:1eecbc2b
ARRAY /dev/md5 metadata=0.90 UUID=1011cbb3:b48abbe7:5b020607:1eecbc2b
ARRAY /dev/md6 metadata=0.90 UUID=88018aa2:0d416a22:5b020607:1eecbc2b

V některých případech pole nemusí metadata vůbec obsahovat, ale to není moc dobrý/bezpečný nápad.

Za určitých podmínek je možné provést migraci metadat 0.90 na 1.0, jelikož jsou obě verze umístěny na konci disku, čtěte Converting between superblock versions.

Taktéž tu máme možnost externích metadat – External Metadata – s čímž nemám zkušenosti.

Bitmap: external vs. internal

Zjednodušeně řečeno, bitmapa je něco jako žurnál a slouží nám k rychlejšímu zrekonstruování pole, pokud z něj disk z nějakého důvodu vypadne. Nemusí se nutně jednat o chybu disku, ale třeba špatné vypnutí systému. Bitmapa může být uložena přímo na discích v poli, říkejme jí „internal“:

# při vytváření pole :
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1 --bitmap=internal
# na již vytvořeném poli :
mdadm --grow /dev/md0 -b internal

Taktéž může být bitmapa uložena na externím disku, v takovém případě jí můžeme nazývat „external“. Bitmapa je tedy uložena mimo pole v souboru a podporovaný filesystém, na kterém může soubor být, je ext2 a ext3.

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1 --bitmap=/var/my_bitman.bin

V takovém případě musíme cestu k bitmapě definovat v konfiguračním souboru pole:

nano /etc/mdadm.conf
...
ARRAY /dev/md0 metadata=1.2 bitmap=/var/my_bitman.bin UUID=14640e9e:d1c30960:5b020607:1eecbc2b
...

Jak jsme bitmapu vytvořili, tak jí můžeme i odstranit, stačí upravit pole s parametrem "--bitmap=none"

To, zda používáme bitmapu, poznáme např. pomocí mdstat (v tomto případě má poslední pole bitmapu):

cat /proc/mdstat 
Personalities : [raid1] 
md6 : active raid1 sdb6[0] sda6[1]
      8115264 blocks [2/2] [UU]
      
md5 : active raid1 sdb5[0] sda5[1]
      1369139520 blocks [2/2] [UU]
      
md3 : active raid1 sdb3[0] sda3[1]
      29294400 blocks [2/2] [UU]
      
md2 : active raid1 sdb2[0] sda2[1]
      29294400 blocks [2/2] [UU]
      bitmap: 1/1 pages [4KB], 65536KB chunk

unused devices: <none>

Každý jistě logickou úvahou dojde k tomu, že tato přidaná funkce bude mít asi nějakou režii navíc při zápisu do pole. Je tedy na každém, nechť sám zváží, zda použít bitmapu, či nikoli (velká x terabajtová pole se mohou skládat docela dlouho). Taktéž dopodučuji podívat se na parametr „--bitmap-chunk“.

Hlavním vývojářem subsystému MD je Neil Brown.

Závěr

To by bylo k dnešní teorii asi tak vše a příště už se podíváme na něco z praxe, tzn. postup na migraci systému za běhu na pole RAID1 (popř. i jiné) krok za krokem a nějaké tipy na nastavení.

Diskuse k tomuto článku

[Michal]

1. Jakou výhodu má používat externí bitmapu? Připadá mi to jen jako další kurvítko které se může rozbít...?
2. Jak přesně funguje BBWC? Když vypadne napájení disků tak neuložené zápisy zůstanou v BBWC a pak když se napájení zase obnoví tak se to automaticky uloží? Ještě před tím než začne bootovat systém? Takže RAID bude konzistentní, ale FS na něm být nemusí..?

[Max]

Osobně neshledávám výhodu v externí bitmapě. Spíš mi to přijde jako další možnost, kterou možná někdo využije.
V jobu používáme hlavně HP a v nich je SA (Smart Array - P400, P410, P420 ...). Ty se chovají tak, že pokud dojde k výpadku a jsou nějaká nezapsaná data v cache (nemusí to být vždy) tak řadič při načtení v postu zahlásí, že jsou v něm data a zeptá se, co s nimi. Buď se mohou zapsat na pole, nebo je může odstranit.
Kdysi dávno jsem nějaké takové výpadky zažil (ještě než jsme měli centrální baterie). Matně si vzpomínám, že asi jednou nešlo ty data zapsat na pole (na nějakém obstarožním SA řadiči) a musel jsem zvolit možnost jejich odstranění z cache. Tenkrát se nic nestalo, systém naběhl a vše fungovalo bez ztráty dat (Windows Server 2003). No, třeba mám jen víc štěstí, než rozumu :).
Zdar Max

[walkeer_CZ]

BBWC funguje presne jak popisujete a zarucuje, ze to, co se melo zapsat na disky, se take zapsalo, coz je velmi podtstane napr. v pripade zurnalu. Problem je, ze se u ne serveroveho zeleza muze stat, ze kdyz dojde k vypadku napajeni zrovna pri zapisu na disk, nektere sbernice ci samotny CPU zacnou generovat nejaky nahodny bordel a ten se pak dostane na disk. Pokud se zrovna zapisovalo do zurnalu, tak to je dosti spatne a ani BBWC nepomuze.

[Heron]

Ad 1)

Externí bitmapa je totéž co externí žurnál nebo co umístění databázových binárních logů na jiné diskové zařízení. Prostě pro rozložení zátěže mezi více diskových jednotek. Jestli další disk je kurvítko, to si administrátor musí rozhodnout sám.

[alkoholik]

Swap se na RAID nedaval kvuli vykonu.
Muze se totiz stat, ze vypadne disk a obsluha chyby shodou okolnosti potrebuje alokovat pamet. V systemu volna neni, takze si kernel chce ublinknout do Swapu. Jenze ten zrovna neni dostupny, protoze se pod nim rozpadl RAID. Obsluha chyby shodou okolnosti potrebuje alokovat pamet. V systemu volna neni,..

[Masca]

Swap se na RAID dává kvůli zajištění.

Může se totiž stát, že vypadne disk, na kterém byl swap, a systém tím přišel o kus paměti. O který, to ví jen jádro, a příslušná aplikace, které patřil, se pravděpodobně v blíže neurčené době skácí. A to není pro nerušený běh věcí zas tak fajn.

RAID se nerozpadavá, RAID degraduje. Funguje dál na menším počtu disků, toto fungování se zajistí v jádře, kód a data jádra se obyčejně neswapují nebo dost neochotně. Pokud pro RAID zbývající počet disků není dostatečný, tak je to stejně v kopru a o nějaké záchraně nemůže být řeč.

[Max]

Tak tak.
Zdar Max

[alkoholik]

V podstate si vybiras mezi moznym deadlockem v kernelu v okamziku, kdy ti dosla pamet a cely system pujde do kopru, a moznym padem aplikace, ktera ma odswapovano. Sofiina volba.
BTW: Ten deadlock jsem videl potvrzeny jeste v 2.6.16.
Navic se dnes pouziva pristup: server zacal swapovat? Pridejte mu pamet.

[bohyn]

Naposledy kdyz jsem omylem vytahnul disk s aktivni casti swapu tak okamzite nasledoval kernel panic a system sel do kopru. Tim ze popadaji jen aplikace ktere jsou ve swapu bych se moc neutesoval. Co bylo v tu chvili ve swapu netusim, ale vetsinou byva prazdny.

[fahacz]

pamet jadra je podle me "neswapovatelna", maximalne muze byt tak uvolnena, ale na swap se zrejme nikdy nedostane nebo se pletu?

Nejak to souvisi se ZONE_NORMAL coz by melo obsadit neco mezi 16 - 896MB, ale to uz varim z vody, na x86 si typicky bere 128MB (pod tema 16 je DMA), takze stroj s 1024MB RAM ma k dispozici 896MB pro userspace. http://lwn.net/images/pdf/LDD3/ch15.pdf

--- kód a data jádra se obyčejně neswapují nebo dost neochotně

[j]

SW RAID se uplne vpohode rozpadne ... uz sem i videl. Zrcadlo, jeden disk posel, ale system ho urcil jako "ten zdravej" ...

[anonym]

existuji dva ruzne pristupy, jeden rika ze swap mit nad RAIDem, druhy ze ne. problem s pameti tam neni, mdadm by mel vsude alokovat z rezervnich stranek systemu (stejne jako cely diskovy subsystem a cokoliv co muze byt potreba pro swapovani). swapovani tedy nenastava az na posledni chvili, system ma trochu (viz sysctl) volne pameti porad

swap na RAIDu je dobry pokud potrebuji uptime vice nez vykon (tedy servery) - pri vypadku disku jej muzu hotswapem vymenit a nikdo nic nepozna

samostatne swap oddily se hodi kdyz mi jde o ochranu dat, ale restart navic me nepali (desktop, kde casto ani nemam UPS) - pri vypadku disku zmizi cast swapu, pokud v nem byla data "systemoveho" programu tak to cele zatuhne. vyhoda je ze mam swapu dvakrat tolik, s vyssi rychlosti zapisu (cteni by melo byt stejne rychle)

[motyq]

v dnesni virtualizovane dobe mi prijde swap jako prezitek (dle mych zkusenosti/dle toho co provozuju). 32G Ram na serveru beru jakysi standard uz, virtualum pridelim max tolik aby nevyzrali 100%, na samotnem hostiteli nema co by extra zralo ram.

Co si pamatuju tak od te doby co to takhle delam, mi nechcipl jediny hostitelsky system z duvodu zravosti hostu. Predtim se bezne stavalo, ze kdyz uz neco zaclo swapovat, tak to stroj natolik zdrzovalo, ze to nebylo pouzitelne.

Pamet je v dnesni dobe tak levna, ze se vyplat pridat, nez se babrat swapem.

[David Watzke]

Ještě občas paměť dojde, když se něco zblázní a pak ti swap koupí trochu času. Ale stejně to většinou nestihneš zachránit, pač než se logneš do zaswapovanýho systému a stihneš tam něco spustit, tak dojde i swap

[walkeer_CZ]

nastesti mame OOMkiller :)

[David Watzke]

No, zrovna touhle příšerností bych moc nešermoval

[R]

Disk aj tak vacsinou "nevypadava" cely, ale len zacne robit chyby. Z RAIDu vypadne, ale swap moze este fungovat. Vtedy staci urobit swapoff na tom vadnom disku a disk sa moze vymenit.

[Mti.]

Dobre, ale spolehej na to, pokud ta masina ma aj neco delat. Za mne swap nad raidem. Pripadu, kdy je co zachranovat je sice dost, ale nestoji to za tu pakarnu. Takhle mi zmizi chciply disk ze sbernice a jede to dal, akorat mi dojde mail od mdadm s par UUUUU_

[walkeer_CZ]

SWAP se na servery nedava kvuli vykonu. Tecka :) vazne nechapu adminy, ktere v dobe 16GB a vice RAM i v tech nejlevnejich serverech zapinaji hruzu jmenem SWAP. Jediny vysledek, ktery nastane, kdyz dojde pamet je totiz ten, ze system zacne swapovat, cimz load typicky stoupne na 100 a vice a server jde vpodstate dokopru. Kdyz SWAP neni, proste nastoupi OOMkiller, zabije rozbitou aplikaci (jak jinak muze dojit pamet na serveru, pokud neni admin id*ot?) a jede se vesele dal.

[trekker.dk]

SWAP se na servery nedava kvuli vykonu. Tecka

Nesmysl. I na serveru s 16GB RAM se jádro může rozhodnout něco odswapovat, pokud usoudí, že danou paměť lze využít líp.

Kdyz SWAP neni, proste nastoupi OOMkiller, zabije rozbitou aplikaci

Kdyby tohle byla obecně pravda, vývojáři jádra by se každou chvíli nepokoušeli opravovat OOM killer. Do správné aplikace (pokud to není naprosto jasné) se totiž tak spolehlivě netrefí.

[walkeer_CZ]

pokud jsou bezici aplilace alespon trochu spravne nakonfigurovany, tak pamet nedochazi a usporit tech mar MB, ktere lze beztrestne odswapovat je opravdu zasadni prinos. Naopak kdyz pamet zacne dochazet, tak je IMO SWAP naopak pritezi, protoze zpusobi treba i hodinovou nedostupnost serveru jako celku. Osobne mi prijde daleko lepsi kdyz server je po celou dobu funkcni s tim, ze OOMkiller zabije nejakou aplikaci a tim vyresi malo RAM. Krome toho: moje zkusenost je takova, ze kdyz uz je swap vazne potreba, tak je to kvuli nejakemu memory leaku nebo honde spatne konfiguraci a pak OOMKILLer nastupuje stejne, akorat to trva mnohem dele....

[trekker.dk]

pokud jsou bezici aplilace alespon trochu spravne nakonfigurovany, tak pamet nedochazi

Paměť spolehlivě nedochází pouze v případě, že se zcela zakáže overcommit

Naopak kdyz pamet zacne dochazet, tak je IMO SWAP naopak pritezi, protoze zpusobi treba i hodinovou nedostupnost serveru jako celku.

Jestli to nebude spíš rukama...

[Max]

Jednak každý nemá nový železo a ramka je hlavně levná u DDR3, takže starší servery s DDR2 moc levně nepovýšíš.
Dále tu máme serverová řešení, která se bez swapu nedají provozovat, viz třeba Oracle DB, který vyžaduje swap. Jednak ho vyžaduje instalátor, bez kterýho db standardně nenainstaluješ, dále kdyby jsi swap odstranil po instalaci, tak nevím, zda spustíš db, pokud db spustíš, tak ok, ale zase rozhodně nečekej, že budeš mít support. Jak je to u nedávno vydaného Oracle12 netuším.
Takových případů se pak najde trochu více.
Dále v mnoha případech je ztráta výkonu za použití swapu pro daný účel jaksi zanedbatelná a nehraje roli.
Osobně bych se tedy zdržel prohlašování jedné správné pravdy a neodsuzoval bych jiné .
Zdar Max

[alkoholik]

Zrovna Oracle je extra pripad. Vyzadovana velikost swapu pri instalaci je az absurdni a pravidelne odklepavam "ignorovat".
Na druhou stranu mam info, ze pro RAC instalace nastavuji swappiness=100:

The argument is basically that if you set swappiness to 100 it does aggressive page scavenging, i.e. the kernel will continuously look for pages that it can reuse. This doesn't however mean that it will always page. It also doesn't mean that if it is using swap that this pages written will ever be paged back in again. The usage of swap is not bad, it's high paging (i.e. moving blocks in and out of swap) that causes poor performance problems and especially with our config where swap in on NFS mounted drives.

If you set swapiness to any other value and in reality it makes little difference if you set it to 40, 60 or 80, then the kernel does not to aggressive scavenging. It will only start to look for pages to scavenge when it gets low on available memory. The down side to this is that when this happens it can cause the machine to 'freeze' whilst this is going on. However, the argument for this is that the machine should have sufficient memory to cope without having to scavenge. Although at best you will only ever minimize this, it's a normal kernel function and it will happen sooner or later.

What I do know for certain is that swappiness MUST be 100 for RAC DB installations. We have seen many times in the past where high loaded DB machines, say at month end, have been evicted from the RAC cluster because the kernel has gone scavenging for free pages and halted all other activity on the machines.

So evidently anything between 0 and 99 behaves pretty much the same – they have seen no real difference in behavior. However at 100 the page stealing daemon runs continuously ensuring memory is kept available. The difference on a system that has plenty of memory is a non-issue. On appropriately sized systems all values will behave pretty much the same. However on machines which begin to get into memory pressure the 100 setting incrementally begins using swap space earlier. What was found was that if it was anything other than 100 then when the paging daemon kicked in it could halt the system as it ran through the memory to clean it up the first time. This caused RAC outages and other instability.

My last conversation with SE suggested this behavior might change in OEL 6.

[walkeer_CZ]

omlouvam se, netusil jsem, ze Oracle, ktery mimochodem nenavidim, protoze se neda pouzivat aniz by z nej clovek nezesilel, vyzaduje SWAP. to bych zvracel...

[Michal]

Tak zrovna Oracle neni aplikace typu stahnu, nainstaluju a uvidim jestli se mi libi. Kdyz uz se nejaka firma rozhodne investovat do licence tak tech par chechtaku navic za odpovidajici zelezo je prakticky zaokrouhlovaci chyba.

[2X4B-523P]

ve fstab mám pri=1 a funguje a zde je prio=1, to mi nějak uniklo...

[Max]

Správně je "pri", chybička se do článku vloudila. Díky za upozornění.
Zdar Max

[David Watzke]

Dík, Krytone, opraveno.

[2X4B-523P]

lol, chystal jsem se odpoledne zjistit, jestli to není nějaká featura

[snehuliak]

Trocha odbocim ale len trocha... Upgradoval som (cez yum) z Fedory17 na Fedoru18 (dracut ok) ale dobrabralo mi to nejak raidy. Tiez sa zda ze to bolo schopne nabehnut len so systemom F18 ale z kernelom z F17...

V serveri mam 6 diskov. Mam raidy 0,1 a 5. Raidy su medzi diskami abc a def. Tieto 2 skupiny diskov su rozdelene na rovnake particie a na nich su raidy.

Problem nastal ked po reboote mali skoro vsetky raidy povypadavane disky. Nevypadol ale jeden disk ako som cakal ale nahodne. Napriklad md10 (raid5 tvoreny sd[def]5 ) mal vypadnutu particiu sdd5, ale md11 (to iste ale particia 6) mal vypadnutu particiu sde5 atd... Urobil som aj (zatial len short) smart test na vsetkych diskoch a zatial nevidim problem.

Vsetky particie sa mi podarilo rucne opravit (cez mdadm --stop, mdadm --assemble a mdadm --add) ale ked som chcel vyskusat este jeden reboot system nenabehol...

Metadata su vsetky 0.90. Mate nejaky tip?

Dakujem

[walkeer_CZ]

Diky za info o bitmape, openSUSE mi ji napralo na serveru jako default a je se divil, proc je to tak pomale. vypnuto a spokojenost :)

[pet]

Dovolil bych si doplnit pár drobností. Používám RAID1 přes celé disky a teprve výsledný /dev/md_d127 dělím na oddíly. Bootuji pomocí Grub-legacy, distribuce Gentoo.

Pro disky do 2 TB používám metadata verze 0.90, protože je umí i kernel, takže pro start OS nepotřebuji initramdisk. Staci kernelu předat parametry:

md=d127,/dev/sda,/dev/sdb root=/dev/md_d127p2

Pro disky nad 2 TB používám metadata verze 1.0, zde uz je nutno použít initramdisk.

Při použití Grub-legacy narazíte na to, ze nedokáže najít na /dev/md_d127 oddíly, protože většinou se číslo oddílu připisuje za název zařízení (končící písmenem), jenže zde název zařízení končí číslicí za niž se přidává oddělovač "p" a to už Grub-legacy neumí. Náprava je jednoduchá: uděláme symbolický link, vytvořime soubor s mapou zařízení a předáme ji grubu při spouštění:

ln -s md_d127 /dev/md_d127p
echo "(hd0)   /dev/md_d127p" > /boot/grub/device.map
grub --device-map=/boot/grub/device.map

[Max]

Já bych se initrd ani grub2 nebál. Oboje je pohodlné a spoustu věcí to ulehčuje. V initrd mám "/etc/mdadm.conf", kde je jasně popsáno, co se má sestavit a jaký název to má mít, takže jedu klasiku /dev/md1, /dev/md2 atd.
Zdar Max

[walkeer_CZ]

delam to stejne

[pet]

Já bych se initrd ani grub2 nebál.

Já se ho taky nebojím ale tohle používám už roky (verzi menší než 2 TB) a funguje to a to velmi splehlivě, a tehdy byl Grub2 ještě velmi experimentální. A initramdisk je zbytečná komplikace pokud není nezbytně potřeba (jako třeba při netbootu).

[lertimir]

Díky za hezký článek. Poradil bys co se dá dělat, když mám na disku superblok a nechci ho tam? Viz dotaz

[Max]

Tak jsem zareagoval, ale za nic neručím :).
Zdar Max

[mc]

Aby řeč nestála.

Používáte u disků nad 2TB gdisk? Jak vytváříte oddíly? Rád si vyslechnu zkušenosti o "BIOS boot partition" nastavení bios (UEFI boot) - prostě nějaké minikuchařky a zkušenosti.

[Max]

Osobně disponuji na dvou pc 2x1TiB WD Black RAID1, 2x1,5TB WD Black RAID1 + 2TB. GPT používám na tom 2TB HDD, ale je to jen přidaný disk, takže z něj nebootuju. Bootuju z obou RAID1 polí pomocí initrd a grub2.
Zdar Max

[pet]

Já na disky do 2 TB používám fdisk, na větší jsem použil parted a udělal na nich GPT.

[petr_p]

Program gdisk z balíku gptdisk. Ale jen kvůli UEFI. Tak velký disk nemám. Mimochodem, pomalu se dodělává podpora GPT i do fdisku z util-linux.