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. Наступны чалавек атрымлівае ў спадчыну паводзіны, а не канфігурацыю, якую трэба рэверсіць.