NFS VPN:n takana: käynnistyksen aikainen liitos vai automaattinen liitos tarvittaessa?

Kaksi kokoonpanoa ratkaisevat saman ongelman ja epäonnistuvat vastakkaisiin suuntiin. Jakamisen liittäminen käynnistyksessä antaa jokaiselle palvelulle tiedostojärjestelmän, joka joko on siellä tai kertoo, miksi käynnistys pysähtyi. Kysynnän mukaan toimiva automaattinen liitos antaa koneelle nopean käynnistyksen ja siirtää odotuksen sille, joka koskettaa polkua ensimmäisenä. VPN:n takana jälkimmäinen on yleensä parempi vaihtokauppa, ja syy on se, että tunneli pakottaa järjestyksen, jota käynnistyssekvenssi ei näe.

Käynnistyksen aikainen liitos vastaan automaattinen liitos

Käynnistyksen aikainen liitos on helppo ymmärtää. Tiedostojärjestelmän kohde odottaa liitosta, siitä riippuvuuden ilmoittavat palvelut käynnistyvät sen jälkeen, ja jos palvelin ei ole saavutettavissa, kone joko odottaa tai epäonnistuu asetuksista riippuen. Kaikki alavirrassa perii tämän yhden päätöksen.

Automaattinen liitos kääntää tämän. Polku on heti olemassa, varsinainen liitos tapahtuu, kun jokin avaa sen, ja aikaisin käynnistyvät palvelut eivät esty tunnelissa, joka ei ole vielä noussut.

Vertailu tiivistyy siihen, kenen pitäisi absorboida viive. Työasema, joka tarvitsee jakamisen ennen kuin käyttäjä voi työskennellä, odottanee. Kannettava, joka käynnistyy laukussa, tai palvelin, jonka jakaminen on valinnainen, ei odottaisi.

Kumpikaan vaihtoehto ei korjaa puuttuvaa reittiä. Molemmat vain päättävät, milloin vika havaitaan.

fstab-rivi, vaihtoehto vaihtoehdolta

Oletetaan, että olemassa oleva OpenVPN-asiakasinstanssi on [email protected], palvelin on files.corp.example ja liitospiste on /mnt/work. Korvaa kaikki kolme oman ympäristösi valtuutetuilla arvoilla. Yksi toimiva rivi näyttää tältä:

files.corp.example:/export/work /mnt/work nfs _netdev,nofail,x-systemd.automount,[email protected],x-systemd.mount-timeout=30s 0 0

_netdev merkitsee liitoksen verkkoa tarvitsevaksi, eikä se nimeä yhtään tunnelia. nofail pitää jakamisen valinnaisena tavalliselle tiedostojärjestelmäkohteelle. x-systemd.automount luo kysyntäpohjaisen liipaisimen sen sijaan, että liittäisi heti.

x-systemd.requires= on osa, joka sitoo liitosyrityksen VPN-yksikköön, ja se kuuluu liitostoimintoon, ei liipaisimeen. Laajan järjestyksen laittaminen itse automaattisen liitoksen yksikköön on tapa, jolla ihmiset luovat syklejä, joista systemd sitten valittaa kielellä, jota kukaan ei lue kahdesti.

x-systemd.mount-timeout=30s rajaa alkuperäistä liitoskomentoa. Se ei rajaa mitään myöhemmin tapahtuvaa, ja tämä on tämän vaihtoehdon yleisin väärinkäsitys.

Mitä »käynnistetty« ei tarkoita

Tarkista, mitä aktiivinen tarkoittaa nimeämällesi VPN-yksikölle. Tunnelipalvelu voi ilmoittaa olevansa käynnistetty ennen kuin reitti tiedostopalvelimelle on olemassa tai ennen kuin yksityinen nimi ratkeaa, ja sen jälkeen järjestäminen ei tarjoa sinulle mitään. Juuri tässä aukossa lähes jokainen epäonnistunut yritys elää. Se on myös näkymätön, ellet katso reittiä ja selvittäjää yksikön tilan sijaan.

Käytä yhteyden omistajan omaa valmiusignaalia lisäedellytyksenä siellä, missä sellainen on. Kiinteä uni on arvaus, joka toimii työpöydälläsi ja epäonnistuu hitaammassa verkossa tai uudelleenyhdistämisen jälkeen.

Tarkastele esimerkkipolun luotuja yksiköitä: mnt-work.automount ja mnt-work.mount. Kun fstab-muutos on tarkistettu, lataa systemd uudelleen ja hallinnoi näitä yksiköitä suoraan sen sijaan, että ajaisit yleisen liitoskomennon, joka harjoittaa asiaankuulumattomia merkintöjä.

Tähän kuuluu vielä yksi varoitus. Palvelu, joka koskettaa /mnt/work käynnistyksessä, laukaisee edelleen liitoksen ja odottaa sitä edelleen, joten jakamisen merkitseminen valinnaiseksi ei tee jokaista sovellusta kärsivälliseksi.

Liitoksen jälkeen kyse on eri viasta

Kun NFS on liitetty, tiedostojärjestelmän uudelleenyritys- ja palautumiskäyttäytyminen määrää, mitä myöhempi katkos tekee lukemiselle tai kirjoitukselle. Asettamasi liitoksen aikakatkaisu ei vaikuta siihen.

Pehmeä liitos lyhentää joitakin odotuksia ja muuttaa virheiden semantiikkaa, ja sillä on tietojen eheyden seurauksia, jotka on helppo jättää huomiotta, kun tavoitteena on nopeampi käynnistys. Sen valitseminen kahden käynnistyssekunnin voittamiseksi on harvoin hyvä vaihtokauppa. Jos vaatimus on todella rajattu toiminto katkoksen aikana, se on sovellustason päätös, ei fstab-lippu.

Päätä, mitä pitäisi tapahtua prosessille, joka on kirjoituksen keskellä, kun tunneli putoaa, ja kirjoita se ylös. Se vastaus on hyödyllisempi kuin mikään vaihtoehtojono.

Testaa neljää tilaa, älä yhtä

Normaali käynnistys, kun tunneli on käytettävissä, on helppo tapaus eikä todista juuri mitään. Se vahvistaa, että merkkijono on kirjoitettu oikein, eikä muuta. Testaa ensimmäinen käyttö ilman VPN:ää, sitten palautuminen, kun se nousee, sitten hallittu katkos onnistuneen liitoksen jälkeen.

Neljä tilaa, neljä havaintoa, ja muistiinpanot menevät fstab-merkinnän viereen. Seuraava henkilö perii käyttäytymisen eikä kokoonpanoa, joka hänen täytyy takaisinmallintaa.