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-ის ჩანაწერის გვერდით მიდის. შემდეგი ადამიანი ქცევას მემკვიდრეობით იღებს და არა კონფიგურაციას, რომლის უკუსვლით ინჟინერიაც მოუწევს.