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 գրառման կողքին։ Հաջորդ մարդը ժառանգում է վարք, այլ ոչ թե կարգավորում, որը նա պետք է հակադարձ ճարտարագրի։