Eida.cz - Extrémní opatření

Extrémní opatření

Eida

Byly Dušičky. A někde i Halloween. Někdo si možná raději pustil Helloweeny. A někdo jiný to raději všechno prospal u skleničky Pálavy. Zkrátka a dobře, aby všechno pokračovalo ve strašidelném duchu, přišlo pondělí, kdy měl být konečně do celého světa a s oficiálním sdělením vypuštěn náš divoký server. Pěkně ve velkém stylu, jen s nějakým tím měsíčním zpožděním proti původnímu plánu.

Z nějakého důvodu byla nedělní noc klidná a služby stabilní. Nic, co by nasvědčovalo nějakým změnám. Zbývalo už jen doladit IIS, aby ukládata logy v UTF-8, přestože je velmi nepravděpoodbné, že by se do user-agentů a jiných informací dostaly podivné znaky. Ať už tak nebo tak, byla to poslední dobrá příprava pro budoucí AWStats, které by mohly nějaký ten log generovaný IISkou umět i zpracovat a říkat nám, jak dobří vlastně jsme. Nebo nejsme. Nebo cokoliv.

Server má kvůli určité a zdánlivě škodolibě záměrné nestabilitě provozované aplikace nastaven asi gorilion paralelních workerů .NETu, které jsou schopné celkem rychle reagovat na různé žádosti a když jeden z nich nečekaně selže, druhý v pořadí dokáže všechno vyřídit za něj. Alespoň teoreticky. Ještě dneska kolem desáté ráno všechno běželo jako po másle, jenže každým máslem pronikne nůž raz dva. Po několika prvních hodinách skenování zvídavými klienty bez přístupových údajů se začali z ničeho objevovat i roboti vyhledávacích služeb, kteří zcela ignorovali nastavení robots.txt, ale asi se s tím nedlo nic dělat. A po nich, po nich to konečně přišlo. Bylo naivní si msylet, že naše lokální evidence vojesnkého materiálu a aktuálních poloh strategických ponorek nezajímá ministerstvo obrany Čínské lidové republiky, které nasadilo tak brutální provoz, že prostě a jednoduše došla veškerá představitelná paměť. IIS to radostně oznamovala velkým červeným písmem a systém odmítal všechny pokusy o spojení, od RDC po telnet. Server spadnul tak rychle, že jsme si ani nestihli nic přát. 

Tohle je samozřejmě dost nepříjemná a hlavně nepřítulná situace, ale jistě musí existovat způsob, kterým by se z toho dalo ještě vydlabat. Co třeba ve firewallu zablokovat celou kontinetální Čínu a v podstatě i Asii? Mmm. HPčko a jeho SAS obsahuje celkem tři vysokorychlostní disky; první dva tvoří mirrorovaný svazek pro OS a třetí byl tak nějak pořád nevyužitý a připravený pro nějaké virtuální prostředí. Jenže stejně není co virtualizovat a data, stejně ajko celá aplikace, se sosá z UNC z high-availability konfigurované Samby. Každopádně disková a řadičová cache je sama o sobě tak úžasně rychlá, že v kombinaci s výkonem CPU pro .NET a linkou pro doručení dat ke klientovi prakticky není rozdíl mezí čtením z disku a z ECC-chráněné RAM. To vnuklo extrémní nápad využít celý třetí disk pro swap.

Bohužel ve Windows, alespoň teda tady na Serveru 2003 R2, není moc možnost tohoto odděleného swapování využít lépe, než připojením disku pod nějaké to písmenko a ne přímo do kořene globálního C:. Idea tedy spočívala v obecném prostoru dynamického svazku s nějakou zdánlivě vylaborovanou hodnotou NTFS clusteru pro ideální podmínky swapování, načež byl celý 160GB disk použit pro stránkovací soubor.

Virtuální paměť v stránkovacích souborech

Spolu s maximální 64GB hodnotou, která ale bude možná nakonec kvůli omezené rychlosti mirroru na překážku, a skutečnou fyzickou pamětí to dohromady dává celkem slušné číslo dostupné a použitelné operační paměti, která vypadá sice možná trochu extrémně, ale mohla by stačit pro zdánlivě bezúdržbové prostředí zasypané cizáckými útoky. Co na to víc říct. Zoufalé časy si prostřě vyžadují zoufalá opatření. A když nás to prakticky nic nestojí, proč ne.

225 GB RAM musí stačit každému.

Co poněkud zaostavá, je doba náběhu a vybavení všech služeb krátce po rebootu, protože Windows v rámci startu dělají kdovíco, ale pořádně nereportují svůj okamžitý stav do žádného přehledného terminálu. Nicméně paměť a tlak na ni se hlásí celkem správně a po prvotní resynchronizaci mirroru kvůli násilnému vypnutí a vytrhnutí z přetížení všechno zase vypadá, jak asi má.

Task manager - krátce po spuštění

Pokud se tohle osvědčí v následujícím týdnu provozního testování, pak jsme zřejmě narazili na zdánlivý svatý grál, který by mohl z obdobných potíží vytrhnout i další chudáky odkázané na velmi nekvalitní a zbytečné .NETové aplikace.

Musím ti něco říct. Zatím to nespadlo.

Samozřejmě jsou to všechno v domácích podmínkách dost těžko představitelná čísla, ale určitě stojí za to podobná extrémní opatření vyzkoušet, pokud se na ně najdou volné zdroje - ostatně co s tak rychlými disky, které by většinu času stejně jen zahálely? A to nás ještě čekají další zatím utajené faktory, jako je stáří a opotřebení, které zatím pro jistotu ani nevedeme v patrnosti…

Tento článek přečetlo již 727 čtenářů (0 dnes).

Komentáře

Nový komentář