NFS over TCP in een OpenVPN UDP-tunnel: twee transporten

Een NFS-gesprek dat TCP gebruikt binnen een tunnel die UDP draagt, is volledig consistent, en het verwart mensen omdat het twee transporten tegelijk noemt. TCP is het gesprek van de bestandsdienst tussen de client en de NFS-server. UDP is de versleutelde drager tussen de VPN-eindpunten. Geen van beide zegt iets over de ander.

Schrijf beide apart op voordat je iets debugt; de meeste van deze incidenten beginnen doordat iemand de verkeerde laag wijzigt.

Twee lagen, twee instellingen

De mountoptie proto=tcp beschrijft hoe de NFS-client met de NFS-server praat. De instelling proto udp in het VPN-profiel beschrijft hoe de tunneleindpunten ingekapselde pakketten uitwisselen. Een mountoptie wijzigen verandert de tunnel niet, en het transport van de tunnel wijzigen verandert niet wat de NFS-client heeft onderhandeld. Controleer de werkelijke mountopties met nfsstat -m in plaats van de fstab-regel, en controleer het VPN-transport op basis van het profiel dat daadwerkelijk wordt gebruikt.

Leg ze daarna vast in de incidentnotities als twee afzonderlijke velden. Een schijnbare verbetering is alleen traceerbaar als de notitie vermeldt welke laag is gewijzigd.

Bladeren is geen massale leesactie

Een mapweergave bewijst dat sommige bewerkingen zijn voltooid. Dat bewijst niet dat een langdurige leesactie, een schrijfactie, een vergrendeling of de opslagbackend onder dezelfde omstandigheden voltooid zal worden. Een stagnatie halverwege een groot bestand is een andere waarneming dan een mount die nooit lukt, en ze wijzen op verschillende lagen.

Beschrijf de mislukkende bewerking precies: pad, richting, het geschatte punt van de stagnatie en de laatste relevante gebeurtenis in de logs van de client, de server en de VPN. Vergelijk daarna waar het verkeer doorgaat en waar het stopt.

MTU is een hypothese, geen diagnose

Verlies dat afhangt van de pakketgrootte is een reële mogelijkheid wanneer een tunnel grote segmenten draagt, en het levert precies het patroon op waarbij bladeren werkt en lezen vastloopt. Dat patroon bewijst echter geen MTU-probleem, want dezelfde vorm verschijnt wanneer een server traag is, wanneer een firewall een langdurige verbinding door een timeout beëindigt, of wanneer een schijf bezet is. Test de hypothese met een gecontroleerde proef in plaats van overal de MTU te verlagen en de overwinning uit te roepen.

Een timeout op zichzelf zegt niets over de vraag of UDP vervangen moet worden. Het is een symptoom met meerdere mogelijke eigenaren.

Wijzig één variabele tegelijk

Houd bij het vergelijken van transporten de NFS-werkbelasting en alle andere instellingen stabiel. Het mounttransport, het tunnelprotocol en de MTU in hetzelfde onderhoudsvenster wijzigen levert een resultaat op dat niemand kan toeschrijven. Voer dezelfde bestandsbewerking voor en na uit en noteer de uitkomst bij elke stap.

Bewaar ook de vorige waarden in het ticket. Als een wijziging de situatie verslechtert, moet de terugweg een gedocumenteerd getal zijn en niet iemands herinnering aan hoe het eerder was.

Lees de laag die faalde

Als de tunnel actief is en het NFS-verzoek wacht, is de VPN niet gefaald; de bestandsdienst is gefaald. Als de tunnel is weggevallen, is het falen van het NFS-verzoek een gevolg en geen oorzaak. Logregels uit beide lagen naast elkaar leggen is de snelste manier om die twee gevallen te onderscheiden, en het is beter dan gokken vanuit de bestandsbeheerder.

Schrijf de conclusie als twee zinnen, één per laag. Dat is genoeg voor de volgende persoon om de test te herhalen zonder opnieuw af te leiden welk transport welk is.