VNX: Datové úložiště NFS občas přejde u jednoho hostitele do režimu offline

Jedno nebo více datových úložišť NFS přejde současně na jednom hostiteli do stavu APD (všechny cesty dolů). K tomu může dojít u různých datových úložišť na různých hostitelích nebo případně u stejného datového úložiště na více hostitelích. Obecně se jedná o náhodné a občasné problémy, které lze vyřešit vypnutím a zapnutím ethernetových portů na hostiteli ESXi nebo restartováním. Nemusí k tomu nutně dojít vždy se stejným datovým úložištěm nebo stejným hostitelem.

Klíčovou funkcí tohoto problému je, že dotčené datové úložiště nebo export NFS je stále přístupný z jiných hostitelů. Pokud je datové úložiště mimo provoz na všech hostitelích, není tento problém tak pravděpodobný. Pokud problém nelze vyřešit vypnutím síťových portů nebo restartováním hostitele, nepůjde ani o tento problém.

To se týká produktů VNX1, VNX2 i eNAS.

Podpora VMware vám může doporučit nastavení NFS. MaxQueueDepth na 64, ale společnost Dell v současné době nemá pro tuto hodnotu doporučení. Tento konkrétní problém však pravděpodobně nevyřeší.

Technický tým zjistil v některých situacích problém ve způsobu, jakým zpracováváme výpočet okna odesílání TCP. V podstatě se stane, že v určitém okamžiku VNX nastaví hodnotu okna TCP Send na 0 nevhodně. To zabrání zařízení VNX odesílat jakákoli nová data hostiteli, se kterým komunikuje v tomto připojení. VNX může stále potvrzovat příchozí data ve vrstvě TCP, ale nemůže odesílat žádné odpovědi NFS.

Pokud je nám známo, toto chování ovlivňující datová úložiště ESXi NFS jsme zaznamenali pouze kvůli specifickému způsobu, jakým systém ESXi občas potvrzuje protokol TCP. V určitých okamžicích systém ESXi namísto odeslání potvrzení s dalším datovým paketem použije další samostatné potvrzení, jakmile jsou z VNX přijata nová data, a to i v případě, že má data ve frontě přenosu. Díky tomuto chování se DM domnívá, že přenos je jednosměrný, a přepne ho do režimu predikce hlavičky. Pokud chování potvrzení ESXi TCP zůstane konzistentní při přenosu více než 2 GB dat z DM, DM pomalu zmenší okno odesílání TCP na hodnotu 0, takže dané připojení TCP bude moci odesílat data pouze jedním směrem (z hostitele do pole). Pokud přenašeč dat obdrží datový paket s novým číslem ACK v rámci tohoto přenosu 2 GB nebo dojde ke ztrátě paketů, která způsobí opakovaný přenos, problém nenastane.

Systém ESXi spustí prezenční signál datového úložiště, aby zjistil, zda je úložiště stále k dispozici. Tento prezenční signál je požadavek GetAttr na konkrétní soubor v úložišti dat. Pokud někdy selže, hostitel ESXi označí datové úložiště jako APD. Vzhledem k tomu, že VNX nemůže odpovědět na požadavky GetAttr od hostitele ESXi, když je jeho okno odesílání TCP nastaveno na hodnotu 0, označí datové úložiště jako nepřístupné. Systém ESXi se z nějakého důvodu nepokusí resetovat připojení, což by tento problém také vyřešilo. To je důvod, proč restartování nebo vypnutí a zvýšení síťových portů na hostiteli funguje pro obnovení přístupu.

Okno odeslání TCP se počítá pro každé připojení zvlášť. Ostatní datová úložiště tedy zůstávají online za předpokladu, že se nesetkala se stejným stavem. Samotné datové úložiště není problém, takže ostatní hostitelé by k němu měli mít stále přístup, pokud se nepotýkají se stejným stavem připojení k tomuto konkrétnímu datovému úložišti.

Tento problém lze potvrdit, pokud existuje trasování paketů, které pokrývá datové úložiště přecházející z online do offline stavu.

Chování výpočtového okna odesílání TCP bude opraveno v budoucí verzi kódu pro verze kódu 7.1 i 8.1 (VNX1, VNX2 a eNAS). V současné době je k dispozici oprava hotfix. Pokud je nutná oprava okamžitě, kontaktujte podporu a vyžádejte si ji společně s naplánovaným restartem / výpadkem převzetí služeb při selhání.