Dotaz: iSCSI, multipath a RDAC

[Zdeněk Zámečník]

Přílohy:

• iscsid.conf (9261 bytů)
• multipath.conf (1083 bytů)

Našel by se tu někdo, kdo má zkušenosti s provozem něčeho podobného? V mém případě se jedná o storage Dell MD3000i, což by měl být stejný HW jako IBM DS4000.

Jak jsem zmínil přistupuji k němu přes iSCSI porty, které má celkem 4. Mám k němu připojené dva servery na přímo (tzn. do každého serveru dva porty). Víceméně tato konfigurace funguje, pokud pominu chyby, které jsou podle Dellu "normální" - v konzoli se při připojení na portál anebo listování disků objevují I/O chyby 20MB LUNu, který je pro nějaké zvláštní účely.

Můj problém tkví v tom, že když vypnu jednu ze síťovek:
1) v době kdy se na úložiště nepřistupuje, multipath zareaguje během 20 s
2) v době, kdy na úložiště zapisuji, multipath zareaguje po více než minutě

Pokud sleduji stav sessions příkazem iscsiadm -m session -P 2,tak v prvním případě je vidět, že ztrátu zaznamená za méně než 10 s. V druhém ale čekám téměř minutu. Testy jsem prováděl při zápisu v jednom threadu, nevím tedy, zda se čas prodlužuje s více souběžnými operacemi...

V iscsid.conf mám nastaveny všechny timeouty velmi nízko. Tak trochu z toho podezírám modul rdac  (který zde slouží ke kontrole cest) protože v sobě má nastavený nějaký timeout na 60000 ms.

Měl by někdo nějaký nápad nebo malinkou myšlenku? Mám totiž obavy, že kdyby všechny virtuální stroje musely při problému čekat minutu až dvě než se vzpamatuje disk, tak by dříve popadaly...

Jediné co mne napadlo je, zkompilovat si modul dm-rdac s upraveným timeoutem ve zdrojácích, ale nevím, jestli je to dobrý nápad, protože netuším, jak to uvnitř funguje. Co bych měl asi zmínit, že jedu na Lennym (Debian).

Přikládám konfiguráky /etc/multipath.conf a /etc/iscsi/iscsid.conf

---

---

Odpovědi

[Zdeněk Zámečník]

Tak problém částečně odhalen - při zápisu mnoha malých souborů reaguje multipath na odpojení síťovky rychle. Problém tedy bude pravděpodobně v nějakém bufferu...

[Zdeněk Zámečník]

Po dlouhé době jsem rozhodl podělit se o řešení. Vždycky jsem dostal storage do stavu, že nějakou dobu fungoval, ale třeba po třech týdnech došlo k nepříjemnému zpanikaření kernelu na obou strojích, které k úložišti přistupují. Po velmi dlouhém bádání a doslova pokusech jsem se rozhodl znovu obrátit na podporu Dellu, která mne ale odpálkovala, že nepoužívám podporovaný systém. Nakonec jsem zkusil nasadit CentOS a rázem se situace zlepšila. I/O chyby se objevují sice stejně, ale je jich podstatně méně. Pády systémů naprosto vymizely.

Jaké z toho plyne ponaučení? Dell pro open source Linux nebrat!

[imro]

Podobny problem som riesil, ale v SAN konfiguracii-cize opticka infrastruktura. Pomohlo pridanie parametru pri boote pci=nomsi ktore sposobilo, ze irq sa prideluje podla toho,ako to da bios a nie ako si to da debian sam. U mna to bolo irq pre opticke karty na servroch.

Cisto teoreticky skus pozriet cez procinfo,ake irq pre sietovky ti prideluje CentOS a ake irq prideluje tvoj operacny system(neviem co pouzivas) na ktorom to blbne.

[svaca]

JJ pravda, vypinani MSI interuptu je obcas nutnost ... Xenserver je ma ale treba defaultne zaple ..

[svaca]

No hezke, ja toto pole poridil nedavno, mam k nemu pripojeny #x Xenserver od Citrixu (tudiz CentOS) a jedu tedy bez problemu ... Ale souhlasim, ze dell ... no nevim nevim .. Pritom dell plne podporuje Ubuntu na stolnich PC a note ...

BTW, jak rychle to mas .. ? Ja mam pouze 1x iSCSI a tudiz jen dve sitovky ...

Diky

[Zdeněk Zámečník]

S Xenem jsem nikdy nepracoval. Dell se žene zejména za ziskem, o nějaké větší podpoře nemůže být řeč. Jednou jsem v noci volal na jejich hotline a přepojilo mne to na nějaký mezinárodní helpdesk odkud mi nebyli schopni poradit. Na druhou stranu jejich HW servis funguje velmi dobře.

K rychlosti můžu říct jen toto - mám to připojené přes všechny čtyři síťovky ke dvěma serverům. I při minimálním vytížení z toho jen s obtížemi dostanu více jak 80MB/s z jednoho stroje. Údajně je to tak úmyslně. Pokud nastavíte multipath do nějakého load balanced režimu (který mimochodem toto úložiště nepodporuje), dají se z toho dostat chvílemi slušné rychlosti, ale s tím také spousta chyb.

Dost jsem se s tím natrápil a dnes už bych sáhnul po jiném výrobci nebo ještě lépe po nějaké skládačce (třeba Supermicro), kde budu mít vždycky možnost nastavit si systém přesně podle mých potřeb. Nemám rád neprůhledná řešení. Jen pro zajímavost v tomto úložišti tepe Windows (pravděpodobně Windows Embeded)... Navíc už dvakrát se mi stalo, že jeden z management portů přestal fungovat, dokud jsem úložiště natvrdo nevypnul a znova zapnul.

Pokud se chcete pobavit více, napište mi na email nebo jabber, který naleznete v mém profilu.

[svaca]

tak to sedi na jednom iSCSI tedy (2x NIC) dam stabilne cca 85MB/s takze to je asi stejne ... Chyby jsem tedy ZATIM zadne nevidel .. Ale predstava, ze to ridi Wokna me naprosto depta ... Zapojeni mame pres switch do POOLu xenserveru, ktery ridi 3X pripojeni do toho iscsi pres 2GBps (sitovky na xenu jsou v bondu ...)

[frr]

Ohledně vypnutí MSI, to podle mého znamená, že na dané kombinaci prostě MSI nefunguje správně, a pokud to zpočátku nabootuje a nějak to jede a shnije to až po čase, tak za to nejspíš může koncová periferie, která MSI generuje (tj. zde FC adaptér). To že vypnete MSI, to znamená, že přešaltujete na emulaci drátových IRQček (pokud se jedná o PCI-e HBA, je to vždy jenom emulace). Sice máte delší latenci interruptů a možná vyšší zátěž na PCI (nechci tvrdit že automaticky nižší průchodnost blokového zařízení) ale hlavně to jede. Ještě by se mohlo stát, že v téhle konfiguraci bodou IRQčka sdílena mezi několika zařízeními... (kvůli nízkému počtu linek na IO(x)APICu v south bridgi, který je k emulaci zneužíván) => výkon nic moc, ale asi se nedá nic dělat.

Ohledně pomalých reakcí multipath na iSCSI: pokud si správně pamatuju, na klasickém SCSI býval "SCSI command timeout" nějaké desítky sekund, možná minuta. Nejedná se náhodou o přirozenou vlastnost SCSI vrstvy? Pokud se týče iSCSI, tam by se teoreticky reakce na poruchy L1 dala akcelerovat sledováním PHY přes MII (viz miimon) - ale je to o pár vrstev níž než traffic iSCSI a přímá logická vazba na iSCSI relace je netriviální, pochybuju, že se to takto hlídá. Zdrojáky iSCSI a multipath modulů (rdac) jsem nečetl...

Ohledně průchodnosti: bavíme se o 1Gbps síťovkách? Pokud ano, 85 MBps Vám připadá málo? Mě to připadá řádově na stropě jednotlivé síťovky Pokud máte navázány řekněme dvě iSCSI relace, každou přes jinou síťovku, tak jste možná omezen kapacitou jednotlivé síťovky. Pokud chcete ze dvou síťovek vytáhnout dvojnásobek, musel byste nějak zařídit balancing mezi relacemi. Zároveň záleží na tom, jakým provozem testujete průchodnost. Při sekvenčním čtení jediným vláknem se sice Linux snaží o nějaký read-ahead, ale v podstatě se neuplatní TCQ, takže nelze "nafrontovat požadavky do obou iSCSI relací paralelně" - prostě protože se těch požadavků nesejde dostatek. Při čtení více vlákny se paralelní frontování do více iSCSI relací použít dá - ale pokud si nedáte pečlivě záležet, tak zas budou paralelní relace číst každá z jiného místa disku, tzn. disky budou muset seekovat, což může průchodnost dramaticky srazit. Kolik disků je v tom RAIDu a jakých? Kromě toho, pokud si správně pamatuju z mého jediného historického pokusu o load balancing přes dm-mpath, balancing mezi SCSI cestami funguje v režimu "round robin", kdy se vždycky do jedné cesty pošle dávka N požadavků, pak se přepne na alternativní cestu, a zase N požadavků. Hodnotu N lze konfigurovat, ale doporučená hodnota je v každém případě výrazně vyšší než 1, aby se round-robin algoritmus nemusel volat pro každý požadavek extra (kvůli zátěži CPU). Potažmo se dvěma čtoucími vlákny se load balancing taky moc neuplatní Domnívám se, že by to šlo otestovat sekvenčním *zápisem*. Při něm se uplatní write-back, takže VM/IO vrstvy vygenerují z jednoho zapisujícího vlákna sérii požadavků na IO. Pokud budou rozumně nastavené hloubky front (detaily z hlavy nedám) tak by mělo docházet k rozkládání mezi obě linky / SCSI cesty. Pokud testujete zápisem a máte v serveru hodně RAMky, musíte zapisovat mnohem větší soubor, než je velikost RAM, a po spuštění testu chvíli počkat, než se ustálí tok dat (než se buffery v RAMce zaplní po strop) - alternativně lze použít "direct IO", pokud ho lze při zvoleném způsobu generování zátěže nastavit (a nejsem si jist, jestli náhodou zároveň nevykostíte TCQ na úrovni operačního systému). Dále pokud nechcete testovat schopnost disků seekovat, doporučuji zapisovat nikoli skrz filesystém, ale přímo DDčkem apod. sekvenčně na blokové zařízení.

A propos, průchodnost iSCSI: jaké používáte MTU?

Jinak už jsem taky zaslechl, že některé "lepší" storage záměrně omezují průchodnost "per host" (nebo snad per flow, nebo per co vlastně) na nějakých 100 MBps - na rozhraní FC 4Gb. Pokud Vám tohle nevyhovuje, tak zlatá Areca. Já vím - je to jako srovnávat limuzínu s Trabantem...

[svaca]

Uff To je dlouhe Ale pekne

1. To ohledne MSI zni zajimave, ale v tomhle se neorientuji, takze muzu maximalne vyzkouset nejakou tu propustnost a to je vse ...

2.jj ty reakce se daji zmenit, jak temy timeauty , tak primo nastavenim multipatch (pristupove body a zpusob samotenho propojeni) ja mam napriklad round-robin:

root@xenserver ~]# multipath -ll -v2
36a4badb0004ee06f0000039a4c10a9fedm-6 DELL,MD3000i
[size=1000G][features=0][hwhandler=1 rdac]
\_ round-robin 0 [prio=200][active]
 \_ 34:0:0:0  sdg 8:96  [active][ready]
 \_ 33:0:0:0  sdd 8:48  [active][ready]

dale jsem vygoogloval, ze ty chyby od toho kernelu jsou vycemene v poradku, ze je to dano treba u toho dell trosku jinym nastanevim toho hwhandleru a rdac, citrix na to ma primo specialni utilitu, co nastavi jadro (initrd) a pak samotne moduly, specialne pro ten dell - zatim jsem neresil ...

3. Pruchodnost je asi OK. ja to mam zapojene "trosku blbe" mam na xenech bond (round-robin) co na SW iSCSCI (slackware + bond) na SAS pole dava cca 100-120 MB/s, vzdy ale obe sitovky pripojeny pres jeden switch (3com) na DELU jsou SATA a docetl jsem se, ze PRIMO ten DELL, pokud ma SAS chova se uplne jinak Vetsinou testuju, ze kopiruju 20 GB SQL backup ... no a ten samotny dell dava prave "jen" tech 80MB/s sakra ten nemuzu najit tu diskusi .... tak aspon tohle

4. RAID10 + SATA disky (bohuzel). MTU. Default takze 1500, pole umi samozrejme jumbo frames, xenserver taky ... Ale nezjistil jsem, zda switch ano ...

[svaca]

Jeste jsem nasel ... na Citrixu a pak jeste HP, tohle

[frr]

Hmm... co je špatně na tom, přečíst si z disku sektor 0? (= MBR) nechápu...

[svaca]

Asi to, ze to MBR, ten sktor drzi to "prvni/rychlejsi" spojeni, ano vzdy se to tyka sektoru 0 (otazkou je, zda tam nejaky MBR je, mozna je tam spise GUID, nebot to pole umi pres 2TB) a pak to vypada v kernelu takto:

end_request: I/O error, dev sdc, sector 0
end_request: I/O error, dev sdf, sector 0
end_request: I/O error, dev sdc, sector 0
end_request: I/O error, dev sdf, sector 0

Ovsem tyto hlasky chodi jen, kdyz: vytvaris novy virtualni disk, hybas s vitrualnim ulozistem jako celkem, kopirujes image a tak .. Pri chodu vitrualniho stroje to nedela ...

Pro me je vysledek, ze to neresim, necham to zit takto .. Uvidim, co prinese xenserver 5.6 (ten nasadim az casem ..)

[Ivan]

Na tom neni spatneho nic. V tom odkazu je patne je je to ze se to dela na poli EMC Clarion(Vendor=DGC). Tyhle pole nepodporuji multipath loadbalancing. A pokud se kernel/blkid snazi zjistit jestli je cesta z HBA v poradku, tak to hazi tyhle chyby. Prej je to tak v poradku a neda se s tim nic delat.
Jedine snad nepouzivat EMC.

[Zdeněk Zámečník]

Nic špatného by na tom nebylo, pokud by tyto chyby nevyskakovaly cca 12s v kuse a v podstatě zastavily všechny diskové operace. S clusterovými filesystémy to pak dělá doslova psí kusy. Zajímavé je, že na CentOS jich vyskáče méně a mnohdy to netrvá déle jak vteřinu. Tohle pole se hodí tak akorát pro Windows, se kterými funguje snad korektně. Je škoda, že neumí více handlerů.

[frr]

Příkaz "multipath"? Doba pokročila Když hrábnu do archivu, tak jsem tehdy ten multipath nastavoval takhle: echo "0 2929686528 multipath 0 0 1 1 round-robin 0 2 1 8:0 20 8:16 20" | dmsetup create dma Tušímže čísla "20" znamenaly délku dávky. V podstatě je to úleva, že si s těmito hračkami nemusím hrát

Oni i Arecy se SAS portama dávají menší průchodnost na SATA disky než na SAS disky - se SATA diskama jsou v sekvenční průchodnosti asi o čtvrtinu slabší (řekněme 800 MBps vs 600 MBps). Ale občas čtu o konkrétních modelech RAIDových kastlí, které obsahují SASový expandér, že to s konkrétními modely SATA disků buď nefunguje vůbec, nebo třeba že to pro SAS provoz neumí využít multilane SAS link mezi HBA a expandérem, takže to jede jediným 300MBps lanem...

Ohledně MSI: http://www.fccps.cz/download/adv/frr/MSI/PCIe-MSI.html = otravně dlouhé teoretické čtení, rozumné řešení problému s tuhnoucím HBA z toho stejnak neplyne.

[svaca]

JJ uz jsem cetl Uz davno, pamatujes

[VSi]

Zdravím. Vidím, že s těmito věcmi máte docela zkušenosti. Píšete o průchodnosti 600 MBps na SATA discích v HW RAIDu.

Nedávno jsem tady řešil použití SATA / SAS disků pro HW RAID: http://www.abclinuxu.cz/poradna/hardware/show/306929 Tam padnul i názor, že od 8×SATA v HW RAID10 lze očekávat tak 150 MBps. Tedy mě o tu sekvenční rychlost nejde, spíš o výkon pro náhodné čtení mnoha klientů (jak je uvedeno v dotazu). Neměl byste nějaké srovnání SAS/SATA, když se použije třeba dvojnásobné množství SATA disků do RAID 0/10, jestli se to přiblíží SAS?

Zajímavá je i informace o SAS expandérech, uvažoval jsem použít HP DL180 s backplane na 12 disků, který obsahuje expandér a je k HBA připojen přes 4-lane SAS. Nerad bych, aby to se SATA disky takhle zlobilo.

[frr]

S tím expandérem je to loterie. Máte slušnou šanci, že to bude fungovat správně. Hlášené problémy byly vždycky nějaká kombinace značka čipu expandéru vs. model RAIDu vs. model disku (často nějaký WDC) a konkrétní firmware disku. Zezačátku to bývala případně i značka čipu expandéru vs. SATA disky všecky šmahem Vyzkoušejte a uvidíte.

[Zdeněk Zámečník]

Ohledně těch SATA/SAS disků v tomto poli - Dell nám pro toto pole vůbec nechtěl prodat SATA disky s tím, že k tomuto poli je lze připojit pouze přes MD1000. Zkoušeli jsme tam ale stejně jak SAS, tak SATA, ale žádný funkční rozdíl tam nebyl. Z důvodů I/O chyb jsme ho nakonec celý osadili SAS disky, což situaci nezměnilo.

[svaca]

Tak nam to DELL automaticky prodal se SATA, ani je nenapadlo, nabidnout SAS, kdyz ve specifikaci maji, ze je to SAS radic a o SATA ani zminka

[chsajarsa]

Mam stejny HW, ale myslim ze DELL bere pole od EMC ne od IBM.

Jinak ja jsem redundanci sitovek resil pomoci LACP, takze jsem sitovky spojil do bondu. Multipath podle me bude reagovat na vypadek radice toho pole. Momentalne jsem pri migraci no nove zelezi premigoval vse na FreeBSD,ale jinak ten stroj fungoval velice spolehlive od nastaveni do vypnuti bez jedineho vypadku/restartu.

[Zdeněk Zámečník]

Jj, Dell to pole bere od EMC, ale zrovna tenhle model pod svým logem prodává i IBM. A to ti to opravdu přes LACP fungovalo v pořádku? Moc se mi to nezdá, protože ten rdac handler se chová velmi podivně. Resp. i bez multipathu se mi to pole snažilo občas používat jinou než preferovanou síťovku.