Administrace komentářů

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...