NFS darrere d’una VPN: muntatge a l’arrencada o automuntatge sota demanda?

Dues configuracions resolen el mateix problema i fallen en direccions oposades. Muntar el recurs compartit a l’arrencada dona a cada servei un sistema de fitxers que o bé hi és o bé explica per què s’ha aturat l’arrencada. Un automuntatge sota demanda dona a la màquina una arrencada ràpida i passa l’espera a qui toqui el camí primer. Darrere d’una VPN el segon sol ser el millor intercanvi, i la raó és que el túnel imposa un ordre que la seqüència d’arrencada no pot veure.

Muntatge a l’arrencada enfront d’automuntatge

Un muntatge a l’arrencada és senzill de raonar. L’objectiu del sistema de fitxers espera el muntatge, els serveis que declaren una dependència d’ell arrenquen després, i si el servidor no és accessible la màquina o espera o falla segons les opcions. Tot el que va a continuació hereta aquesta única decisió.

Un automuntatge ho inverteix. El camí existeix immediatament, el muntatge real passa quan alguna cosa l’obre, i els serveis que arrenquen aviat no es bloquegen en un túnel que encara no ha pujat.

La comparació es redueix a qui ha d’absorbir el retard. Una estació de treball que necessita el recurs abans que l’usuari pugui treballar probablement hauria d’esperar. Un portàtil que arrenca dins d’una motxilla, o un servidor el recurs del qual és opcional, no.

Cap de les dues opcions arregla una ruta que falta. Totes dues només decideixen quan s’observa la fallada.

La línia d’fstab, opció per opció

Suposem que una instància de client OpenVPN existent és [email protected], el servidor és files.corp.example i el punt de muntatge és /mnt/work. Substituïu els tres pels valors autoritzats del vostre lloc. Una línia que funciona és així:

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

_netdev marca el muntatge com a necessitat de xarxa, i no anomena cap túnel. nofail manté el recurs opcional per a l’objectiu normal del sistema de fitxers. x-systemd.automount crea l’activador sota demanda en lloc de muntar immediatament.

x-systemd.requires= és la part que lliga l’intent de muntatge a la unitat de VPN, i pertany a l’operació de muntatge, no a l’activador. Posar un ordre ampli a la mateixa unitat d’automuntatge és com la gent crea cicles dels quals systemd després es queixa en un llenguatge que ningú no llegeix dues vegades.

x-systemd.mount-timeout=30s limita la comanda de muntatge inicial. No limita res del que passa després, i aquest és el malentès més habitual sobre aquesta opció.

Què no vol dir «iniciat»

Comproveu què vol dir estar actiu per a la unitat de VPN que heu anomenat. Un servei de túnel pot informar que s’ha iniciat abans que existeixi la ruta cap al servidor de fitxers o abans que es resolgui el nom privat, i ordenar-se després no us dona res. És en aquest buit on viu gairebé tot intent fallit. També és invisible tret que mireu la ruta i el resolutor en lloc de l’estat de la unitat.

Feu servir el senyal de preparació del mateix propietari de la connexió com a prerequisit addicional on n’hi hagi. Una dormida fixa és una suposició que funciona a la vostra taula i falla en una xarxa més lenta o després d’una reconnexió.

Inspeccioneu les unitats generades per al camí de l’exemple: mnt-work.automount i mnt-work.mount. Després d’un canvi d’fstab revisat, recarregueu systemd i gestioneu aquestes unitats directament en lloc d’executar una comanda de muntatge general que exercita entrades no relacionades.

Aquí hi cap una advertència més. Un servei que toca /mnt/work a l’arrencada encara activa el muntatge i encara l’espera, així que marcar el recurs com a opcional no fa pacient tota aplicació.

Després del muntatge, la fallada és una altra

Un cop NFS és muntat, el comportament de reintent i recuperació del sistema de fitxers governa què fa una interrupció posterior a una lectura o una escriptura. El temps d’espera de muntatge que heu posat no hi té cap influència.

Un muntatge suau escurça algunes esperes i canvia la semàntica dels errors, amb conseqüències per a la integritat de les dades fàcils de passar per alt quan l’objectiu és una arrencada més ràpida. Triar-lo per guanyar dos segons d’arrencada poques vegades és un bon intercanvi. Si el requisit és realment una operació limitada durant una interrupció, és una decisió a nivell d’aplicació, no un indicador d’fstab.

Decidiu què ha de passar amb un procés que està escrivint quan cau el túnel, i escriviu-ho. Aquesta resposta és més útil que qualsevol cadena d’opcions.

Proveu quatre estats, no un

Una arrencada normal amb el túnel disponible és el cas fàcil i no demostra gairebé res. Confirma que la cadena està ben escrita i res més. Proveu el primer accés sense la VPN, després la recuperació quan puja, després una interrupció controlada després d’un muntatge correcte.

Quatre estats, quatre observacions, i les notes van al costat de l’entrada d’fstab. La persona següent hereta comportament en lloc d’una configuració que ha de reconstruir.