VNX: NFS-datastore gaat af en toe offline voor één host

Een of meer NFS-datastores gaan in een APD-status (all paths down) op één host tegelijk. Dit kan gebeuren met verschillende datastores op verschillende hosts, of mogelijk dezelfde datastore op meerdere hosts. Over het algemeen is het willekeurig en met tussenpozen en wordt het opgelost door de Ethernet-poorten op de ESXi-host uit te schakelen en te verhogen of opnieuw op te starten. Het gebeurt niet noodzakelijkerwijs altijd met dezelfde datastore of dezelfde host.

Het belangrijkste kenmerk van dit probleem is dat de getroffen datastore of NFS-export nog steeds toegankelijk is vanaf andere hosts. Als de datastore op alle hosts niet beschikbaar is, is dit probleem minder waarschijnlijk. Als het niet wordt opgelost door de netwerkpoorten uit te schakelen of de host opnieuw op te starten, zal het ook niet dit probleem zijn.

Dit is van invloed op zowel VNX1-, VNX2- als eNAS-producten.

VMware-support kan adviseren om de NFS in te stellen. MaxQueueDepth naar 64, maar Dell heeft momenteel geen aanbeveling voor deze waarde. Het is echter niet waarschijnlijk dat dit specifieke probleem wordt opgelost.

Engineering heeft een probleem vastgesteld in de manier waarop we in sommige situaties omgaan met onze TCP-berekening voor het verzenden van vensters. Wat er in wezen gebeurt, is dat de VNX op een bepaald moment de TCP-verzendvensterwaarde op 0 zet. Hierdoor kan de VNX geen nieuwe gegevens verzenden naar de host waarmee hij op die verbinding communiceert. De VNX kan nog steeds binnenkomende data op de TCP-laag bevestigen, maar kan geen NFS-antwoorden verzenden.

Voor zover wij op dit moment weten, hebben we dit gedrag alleen gezien dat van invloed is op ESXi NFS-datastores vanwege een specifieke manier waarop ESXi soms zijn TCP-erkenningen uitvoert. Op bepaalde punten gebruikt ESXi, in plaats van een bevestiging mee te sturen met het volgende datapakket, een extra afzonderlijke bevestiging zodra er nieuwe gegevens van de VNX worden ontvangen, zelfs als er gegevens in de verzendwachtrij staan. Dit gedrag zorgt ervoor dat de DM denkt dat de overdracht eenrichtingsverkeer is en zet het in de headervoorspellingsmodus. Als het gedrag van de ESXi TCP-bevestiging consistent blijft tijdens het overdragen van meer dan 2 GB aan data van de DM, zal de DM het TCP-verzendvenster langzaam verkleinen tot 0, waardoor die specifieke TCP-verbinding data slechts in één richting kan verzenden (van de host naar de array.). Als de datamover een datapakket met een nieuw ACK-nummer ontvangt binnen die overdracht van 2 GB, of als er pakketverlies is waardoor een herverzending plaatsvindt, doet het probleem zich niet voor.

ESXi voert een hartslag uit op de datastore om te bepalen of deze nog beschikbaar is. Deze heartbeat is een GetAttr-aanvraag voor een specifiek bestand in de datastore. Als het enkele keren mislukt, markeert de ESXi-host de datastore als APD. Aangezien de VNX niet kan reageren op de GetAttr-aanvragen van de ESXi-host terwijl het TCP-verzendvenster is ingesteld op 0, wordt de datastore gemarkeerd als ontoegankelijk. Om wat voor reden dan ook probeert ESXi niet om de verbinding te resetten, wat ook dit probleem zou oplossen. Daarom werkt het opnieuw opstarten of downen en verhogen van de netwerkpoorten op de host om de toegang te herstellen.

Het TCP-verzendvenster wordt voor elke verbinding afzonderlijk berekend. Andere datastores blijven dus online, op voorwaarde dat ze niet met dezelfde aandoening te maken hebben gehad. De datastore zelf is niet het probleem, dus andere hosts zouden er nog steeds toegang toe moeten hebben, tenzij ze met dezelfde situatie te maken hebben gehad met hun verbinding met deze specifieke datastore.

Dit probleem kan worden bevestigd als er een pakkettracering is die betrekking heeft op de datastore die van een online naar een offline status gaat.

Het berekeningsgedrag van het TCP-verzendvenster wordt opgelost in een toekomstige release van code voor zowel codeversies 7.1 als 8.1 (VNX1, VNX2 en eNAS). Er is momenteel een hotfix beschikbaar. Als een oplossing nodig is, neem dan onmiddellijk contact op met support om deze aan te vragen, samen met een geplande storing voor opnieuw opstarten/failover.