NFS зад VPN: монтиране при зареждане или автоматично монтиране при поискване?

Две конфигурации решават един и същ проблем и се провалят в противоположни посоки. Монтирането на споделения ресурс при зареждане дава на всяка услуга файлова система, която или я има, или обяснява защо зареждането е спряло. Автоматичното монтиране при поискване дава на машината бързо зареждане и прехвърля чакането на този, който първи докосне пътя. Зад VPN второто обикновено е по-добрата размяна, а причината е, че тунелът налага ред, който последователността на зареждане не вижда.

Монтиране при зареждане срещу автоматично монтиране

Монтирането при зареждане е лесно за осмисляне. Целта на файловата система чака монтирането, услугите, които обявяват зависимост от нея, стартират след това, а ако сървърът е недостъпен, машината или чака, или се проваля в зависимост от опциите. Всичко надолу наследява това единствено решение.

Автоматичното монтиране обръща това. Пътят съществува веднага, истинското монтиране се случва, когато нещо го отвори, а услугите, които стартират рано, не блокират на тунел, който още не е вдигнат.

Сравнението се свежда до това кой трябва да поеме закъснението. Работна станция, която се нуждае от споделения ресурс, преди потребителят да може да работи, вероятно трябва да чака. Лаптоп, който се зарежда в чанта, или сървър, чийто споделен ресурс е по избор, не трябва.

Нито една от опциите не поправя липсващ маршрут. И двете просто решават кога да се забележи отказът.

Редът във fstab, опция по опция

Да приемем, че съществуващ клиентски екземпляр OpenVPN е [email protected], сървърът е files.corp.example, а точката на монтиране е /mnt/work. Заменете и трите с разрешените стойности от вашия обект. Един работещ ред изглежда така:

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

_netdev отбелязва монтирането като нуждаещо се от мрежа и не назовава никакъв тунел. nofail запазва споделения ресурс по избор за обичайната цел на файловата система. x-systemd.automount създава задействане при поискване вместо незабавно монтиране.

x-systemd.requires= е частта, която обвързва опита за монтиране с модула на VPN, и тя принадлежи на операцията по монтиране, а не на задействащия. Поставянето на широк ред върху самия модул за автоматично монтиране е начинът, по който хората създават цикли, за които systemd после се оплаква на език, който никой не чете два пъти.

x-systemd.mount-timeout=30s ограничава първоначалната команда за монтиране. То не ограничава нищо, което се случва след това, и това е най-често срещаното недоразумение за тази опция.

Какво не означава „стартиран“

Проверете какво означава активен за модула на VPN, който посочихте. Една услуга за тунел може да се отчете като стартирана, преди маршрутът към файловия сървър да съществува или преди частното име да се резолвне, и подреждането след нея тогава не ви носи нищо. Именно в тази празнина живее почти всеки неуспешен опит. Тя е и невидима, освен ако не погледнете маршрута и резолвера, вместо състоянието на модула.

Използвайте собствения сигнал за готовност на собственика на връзката като допълнително предварително условие, където има такъв. Фиксираното изчакване е предположение, което работи на бюрото ви и се проваля в по-бавна мрежа или след повторно свързване.

Прегледайте генерираните модули за пътя от примера: mnt-work.automount и mnt-work.mount. След прегледана промяна във fstab презаредете systemd и управлявайте тези модули директно, вместо да пускате обща команда за монтиране, която засяга несвързани записи.

Тук спада още една уговорка. Услуга, която докосва /mnt/work при стартиране, все още задейства монтирането и все още го чака, така че отбелязването на ресурса като незадължителен не прави всяко приложение търпеливо.

След монтирането отказът е друг

След като NFS е монтирана, поведението на файловата система при повторни опити и възстановяване определя какво прави по-късен прекъсване с четене или запис. Зададеният от вас таймаут за монтиране не влияе на това.

Мекото монтиране съкращава някои изчаквания и променя семантиката на грешките, с последствия за целостта на данните, които лесно се пропускат, когато целта е по-бързо зареждане. Изборът му, за да спечелите две секунди старт, рядко е добра размяна. Ако изискването наистина е ограничена операция по време на прекъсване, това е решение на ниво приложение, а не флаг във fstab.

Решете какво трябва да се случи с процес, който е по средата на запис, когато тунелът падне, и го запишете. Този отговор е по-полезен от всеки низ с опции.

Тествайте четири състояния, не едно

Нормалното стартиране с наличен тунел е лесният случай и не доказва почти нищо. То потвърждава, че низът е изписан правилно, и нищо повече. Тествайте първия достъп без VPN, после възстановяването, когато се вдигне, после контролирано прекъсване след успешно монтиране.

Четири състояния, четири наблюдения, а бележките отиват до записа във fstab. Следващият човек наследява поведение, а не конфигурация, която трябва да реконструира.