VNX: NFS-tietosäilö siirtyy ajoittain offline-tilaan yhdessä isännässä

Vähintään yksi NFS-tietosäilö siirtyy APD-tilaan (kaikki polut alas) yhdessä isännässä kerrallaan. Näin voi käydä eri tietosäilöille eri isännissä tai mahdollisesti samalle tietosäilölle useissa isännissä. Yleensä se on satunnainen ja ajoittainen, ja se ratkaistaan joko laskemalla ESXi-isännän Ethernet-portit alas tai lisäämällä tai käynnistämällä se uudelleen. Se ei välttämättä aina tapahdu samassa tietosäilössä tai samassa isännässä.

Tämän ongelman keskeinen piirre on, että tietosäilö tai NFS-vienti, jota asia koskee, on edelleen käytettävissä muista isännistä. Jos tietosäilö ei ole käytössä kaikissa isännissä, ongelma ei ole yhtä todennäköinen. Jos sitä ei ratkaista kaatamalla verkkoportit tai käynnistämällä isäntä uudelleen, se ei myöskään tule olemaan tämä ongelma.

Tämä koskee sekä VNX1-, VNX2- että eNAS-tuotteita.

VMware-tuki saattaa neuvoa NFS:n määrittämistä. MaxQueueDepth-arvo on 64, mutta Dellillä ei ole tällä hetkellä suositusta tälle arvolle. Se ei kuitenkaan todennäköisesti ratkaise tätä nimenomaista ongelmaa.

Tekninen osasto on havainnut ongelman tavassa, jolla käsittelemme TCP-lähetysikkunan laskentaa joissakin tilanteissa. Pohjimmiltaan tapahtuu, että tietyssä vaiheessa VNX asettaa TCP-lähetysikkunan arvoksi 0 väärin. Tämä estää VNX:ää lähettämästä uusia tietoja isäntään, jonka kanssa se kommunikoi kyseisellä yhteydellä. VNX voi edelleen kuitata saapuvat tiedot TCP-kerrokseen, mutta ei voi lähettää NFS-vastauksia.

Tietojemme mukaan tässä vaiheessa olemme nähneet tämän toiminnan vaikuttavan ESXi NFS -tietosäilöihin vain tietyllä tavalla, jolla ESXi suorittaa TCP-kuittauksensa toisinaan. Tietyissä kohdissa ESXi lähettää kuittauksen seuraavan datapakettinsa mukana ja käyttää erillistä lisäkuittausta heti, kun VNX:stä saadaan uutta tietoa, vaikka sillä olisi tietoja lähetysjonossa. Tämä toiminta saa DM: n uskomaan, että siirto on yksisuuntainen, ja asettaa sen otsikon ennustetilaan. Jos ESXi TCP -kuittaus pysyy yhdenmukaisena siirrettäessä DM:stä yli 2 Gt dataa, DM pienentää TCP:n lähetysikkunan hitaasti arvoon 0, jolloin kyseinen TCP-yhteys pystyy lähettämään tietoja vain yhteen suuntaan (isännästä ryhmään). Jos tiedonsiirtolaite vastaanottaa datapaketin, jolla on uusi ACK-numero kyseisen 2 Gt: n siirron sisällä, tai jos paketin menetys aiheuttaa uudelleenlähetyksen, ongelmaa ei esiinny.

ESXi tarkistaa tietosäilön sykkeen, onko se edelleen käytettävissä. Tämä sydämenlyönti on GetAttr-pyyntö tiettyyn tietosäilön tiedostoon. Jos se epäonnistuu joskus, ESXi-isäntä merkitsee tietosäilön APD:ksi. Koska VNX ei voi vastata ESXi-isännän GetAttr-pyyntöihin ja sen TCP-lähetysikkunan arvo on 0, tietosäilö merkitään käyttökelvottomaksi. Jostain syystä ESXi ei yritä nollata yhteyttä, mikä ratkaisisi myös tämän ongelman. Siksi uudelleenkäynnistys tai isännän verkkoporttien alentaminen ja lisääminen palauttaa pääsyn.

TCP:n lähetysikkuna lasketaan erikseen kullekin yhteydelle. Joten muut tietovarastot pysyvät verkossa, jos ne eivät ole kohdanneet samaa tilaa. Tietosäilö itsessään ei ole ongelma, joten muiden isäntien pitäisi silti pystyä käyttämään sitä, elleivät he ole kohdanneet samaa ehtoa yhteydellään tähän tietovarastoon.

Ongelma voidaan vahvistaa, jos on olemassa paketin jäljitys, joka kattaa tietosäilön siirtymisen online-tilasta offline-tilaan.

TCP:n lähetysikkunan laskentatapa korjataan tulevassa koodiversiossa sekä 7.1- että 8.1-koodiversioille (VNX1, VNX2 ja eNAS). Hotfix-korjaus on tällä hetkellä saatavilla, ja jos korjausta tarvitaan, ota heti yhteys tukeen ja pyydä sitä yhdessä ajoitetun uudelleenkäynnistyksen/vikasietokäyttökatkoksen kanssa.