Diky, ale jakto, ze ta prvni zaloha probehne vzdycky? Zalohuje se na stejny NAS, ze stejneho raid pole. To nechapu. Prece kdyby to bylo ovladacema, tak nemuze fungovat ani to prvni, ne? Kdyz je to na stejnym HW i SW.
Na prvním místě z popisu v úvodu článku mi nebylo jasné, že jde o lokální problém. Ono je to vidět podle parametrů v tom eventu 129, což by mi došlo kdybych se na stroji podíval na Object Manager, ale takhle mi to uniklo :/
Event 129 nastává pokud driver detekuje, že zařízení neodpovědělo v timeout period. To může mít různé důvody:
- Bad block na zařízení. Pokud používáte RAID, tak by disky měly být RAIDové. Ty mají ve firmwaru nastaveno, že když se nepodaří data přečíst, tak to rychle vzdají (u některých disků to lze nastavit utilitou od výrobce). Naopak ne-RAIDové disky se zatraceně dlouho snaží data přečíst, a dojde na timeout. To nastavení timeoutu v Registry (psal o něm JardaP) musí být delší než doba po kterou se disk snaží přečíst data.
- Problém s připojením disku, kabely, v případě SAN (což není váš případ - problém se projevuje i bez SANu) spojení se SAN nebo závada na jeho straně.
- Problém s vlastním řadičem nebo driverem, který vede k tomu že zařízení z hlediska OS přestane odpovídat.
To že se problém projeví jen při té delší záloze může být způsobené například bad blockem na té části disku, kterou zálohujete. Chybu dost možná odchytí RAID controller, který nakonec dá data dohromady z paritních disků, takže ji v Event Logu nemusíte vidět. Nicméně by mohla být vidět v nějakém RAID manageru, který dodává výrobce HW.
Další možností je to že se RAID controller (nebo driver) čas od času sekne na něčem úplně jiném. Pokud to nastává jednou za X hodin, a nemáte většinu času I/O subsystém plně vytížený, tak se do toho vůbec nemusíte nestrefil. Při zálohování ale čtete co to jde po dlouhé hodiny, takže na to časem narazíte.
Ovšem prostý dotaz na site:dell.com event 129 ukazuje, že váš problém není úplně neobvyklý. Ten update firmware RAID controlleru má v popisu psáno, že když má systém víc než 8GB RAM, může se občas seknout a dojde na event 129. To nejspíš souvisí s implementací DMA, kde driver controlleru říká "načti z disku X bytů, ulož je do paměti na adresu Y", kde Y je buffer ze kterého se data dál zpracovávají (pokud je to obsah souboru bez komprese a šifrování, může to být rovnou buffer cílové aplikace). Vypadá to, že pokud je ten buffer výš než 8GB, tak to ten controller nerozdýchá (možná vždy, možná občas). To jestli se buffer dostane nad 8GB je víceméně náhodné, a určitě to souvisí s obsazenou paměti včetně cache, vytížením I/O subsystému atd. Klidně to může být až po pr hodinách silného vytížení I/O subsystému.
V druhém linku někdo popisuje, že u něj problém nastával díky tomu, že RAID controller občas testoval zbývající kapacitu baterky (prý dokonce non-stop). Ta se používá pro napájení paměti, do které se dočasně ukládají zápisy na zařízení. Controller zapíše data do baterií zálohované RAM, potvrdí že zápis na zařízení byl úspěšný, a aplikace může pokračovat v běhu. Controller pak na pozadí provede zápis na fyzický disk. Jednak to celou operaci urychlí (pokud není I/O subsystém plně vytížený), a pak to controlleru dává možnost si pořadí zápisů setřídit tak aby byly co nejrychlejší. Problém je v tom, že když vám vypadne proud mezi potvrzením zápisu (data máme jen v RAM controlleru) a jejich zápisem na disk, tak OS dostal potvrzeno že operace proběhla, ale data by byla ztracena. Proto je tam ta baterka, která tu RAM pár dní udrží napájenou. Když pak systém znovu zapnete, controller zapíše na disky co zbylo v jeho RAM z doby před výpadkem.
Kapacita té baterie je tedy celkem kritický údaj, a pochopitelně časem padá. Proto controller periodicky ověřuje, jakou kapacitu ta baterka ještě má. A tam můžou nastat hned dva problémy: 1. Může to být nesprávně implementované a controller může na nějakou dobu vytuhnout, a hlavně 2. to že se provádí test vybíjení baterie znamená nutnost přestat používat tu RAM controlleru a zapsat veškerý její obsah na disk (cca 128MB-2GB dat), což nějakou dobu trvá, a myslím že by to mohlo způsobit timeout. Samozřejmě to lze implementovat lépe, a obsah té RAM není nutné vysypat na disk najednou. Opět to může být jedna z věcí, kterou lze opravit ve firmware controlleru.
V linkovaném případu pomohlo vypnout a znovu zapnout cachování na RAID controlleru, a znovu nastavit čas kdy se baterka testuje.
Na vašem místě bych tedy aktualizoval driver RAIDu, jeho firmware, čistě pro jistotu i firmware zbývajících částí HW, a zkusil pomocí utility smcli to zakázání+povolení cache na controlleru plus nastavení doby kdy se testuje baterka (pokud možno na dobu kdy server nemá moc velkou zátěž).
Support information pro váš server, včetně downloadu firmwaru a driverů, je tady:
http://www.dell.com/support/home/us/en/19/product-support/product/poweredge-r520/researchNajdete tam i support articles, a jeden z nich zmiňuje možnost nastavit čas testování baterie v aplikaci OpenManage Server Administrator. Odkaz na utilitu smcli jsem nenašel, takže nevím jestli ji máte.
http://www.dell.com/Support/Article/us/en/19/SLN130018#Section_D
46 Odpovědí
10360 Zhlédnutí