NFS TCP:n päällä OpenVPN:n UDP-tunnelissa: kaksi siirtotietä

NFS-keskustelun, joka käyttää TCP:tä, kuljettaminen tunnelissa, joka kuljettaa UDP:tä, on täysin johdonmukaista, ja se hämmentää ihmisiä, koska se nimeää kaksi siirtotietä yhtä aikaa. TCP on tiedostopalvelun keskustelu asiakkaan ja NFS-palvelimen välillä. UDP on salattu siirtotie VPN-päätepisteiden välillä. Kumpikaan ei kerro toisesta mitään.

Kirjoita molemmat erikseen ennen kuin aloitat minkään vianetsinnän; useimmat näistä tapauksista alkavat siitä, että joku vaihtaa väärää kerrosta.

Kaksi kerrosta, kaksi asetusta

Liitäntäasetus proto=tcp kuvaa, miten NFS-asiakas puhuu NFS-palvelimelle. VPN-profiilin asetus proto udp kuvaa, miten tunnelin päätepisteet vaihtavat kapseloituja paketteja. Liitäntäasetuksen vaihtaminen ei muuta tunnelia, eikä tunnelin siirtotien vaihtaminen muuta sitä, mitä NFS-asiakas on neuvotellut. Varmista tehokkaat liitäntäasetukset komennolla nfsstat -m fstab-rivin sijaan ja varmista VPN:n siirtotie profiilista, jota todella käytetään.

Kirjaa ne sitten tapahtuman muistiinpanoihin kahtena erillisenä kenttänä. Näennäinen parannus on jäljitettävissä vain, jos muistiinpano kertoo, mikä kerros muuttui.

Selaaminen ei ole massalukua

Hakemistolistaus todistaa, että jotkin toiminnot valmistuivat. Se ei todista, että pitkäkestoinen luku, kirjoitus, lukitus tai tallennuksen taustaosa valmistuu samoissa olosuhteissa. Jumittuminen suuren tiedoston puolivälissä on eri havainto kuin liitäntä, joka ei koskaan onnistu, ja ne viittaavat eri kerroksiin.

Kuvaile epäonnistuva toiminto täsmällisesti: polku, suunta, jumittumisen likimääräinen kohta ja viimeisin olennainen tapahtuma asiakkaan, palvelimen ja VPN:n lokeissa. Vertaa sitten, missä liikenne jatkuu ja missä se pysähtyy.

MTU on hypoteesi, ei diagnoosi

Paketin koosta riippuva hävikki on todellinen mahdollisuus, kun tunneli kuljettaa suuria segmenttejä, ja se tuottaa täsmälleen kuvion, jossa selaaminen toimii ja luku jumittuu. Kuvio ei kuitenkaan todista MTU-ongelmaa, koska sama muoto ilmenee, kun palvelin on hidas, palomuuri katkaisee pitkäikäisen yhteyden aikakatkaisulla tai levy on kiireinen. Testaa hypoteesi hallitulla kokeella sen sijaan, että laskisit MTU:ta kaikkialla ja julistaisit voiton.

Aikakatkaisu sinänsä ei kerro mitään siitä, pitäisikö UDP vaihtaa. Se on oire, jolla on useita mahdollisia omistajia.

Muuta yhtä muuttujaa kerrallaan

Kun vertailet siirtoteitä, pidä NFS-kuormitus ja kaikki muut asetukset vakiona. Liitäntäsiirtotien, tunneliprotokollan ja MTU:n muuttaminen samassa huoltoikkunassa tuottaa tuloksen, jota kukaan ei voi kohdistaa. Aja sama tiedostotoiminto ennen ja jälkeen ja kirjaa tulos jokaisessa vaiheessa.

Säilytä myös aiemmat arvot tiketissä. Jos muutos pahentaa tilannetta, paluun pitäisi olla dokumentoitu luku eikä jonkun muistikuva siitä, millaista ennen oli.

Lue se kerros, joka epäonnistui

Jos tunneli on pystyssä ja NFS-pyyntö odottaa, VPN ei epäonnistunut; tiedostopalvelu epäonnistui. Jos tunneli katkesi, NFS-pyynnön epäonnistuminen on seuraus eikä syy. Molempien kerrosten lokirivien sovittaminen on nopein tapa erottaa nämä kaksi tapausta, ja se voittaa tiedostonhallinnasta arvaamisen.

Kirjoita johtopäätös kahtena lauseena, yksi kullekin kerrokselle. Se riittää, että seuraava henkilö voi toistaa testin selvittämättä uudelleen, mikä siirtotie on mikä.