NFS TCP-ზე OpenVPN-ის UDP გვირაბში: ორი ტრანსპორტი

TCP-ს გამოყენებადი NFS საუბრის გადატანა UDP-ის მატარებელ გვირაბში სრულიად თანმიმდევრულია და ხალხს აბნევს, რადგან ერთდროულად ორ ტრანსპორტს ასახელებს. TCP არის ფაილური სერვისის საუბარი კლიენტსა და NFS სერვერს შორის. UDP არის დაშიფრული გადამზიდი VPN-ის ბოლო წერტილებს შორის. არც ერთი მათგანი მეორეზე არაფერს ნიშნავს.

ჩაწერეთ ორივე ცალკე, სანამ რაიმეს გამართვას დაიწყებთ; ამ შემთხვევათა უმეტესობა იწყება იმით, რომ ვიღაც არასწორ ფენას ცვლის.

ორი ფენა, ორი პარამეტრი

მონტაჟის პარამეტრი proto=tcp აღწერს, როგორ ესაუბრება NFS კლიენტი NFS სერვერს. VPN პროფილის proto udp პარამეტრი აღწერს, როგორ ცვლიან გვირაბის ბოლო წერტილები ინკაფსულირებულ პაკეტებს. მონტაჟის პარამეტრის შეცვლა გვირაბს არ ცვლის, და გვირაბის ტრანსპორტის შეცვლა არ ცვლის იმას, რაზეც NFS კლიენტი შეთანხმდა. გადაამოწმეთ ფაქტობრივი მონტაჟის პარამეტრები nfsstat -m-ით და არა fstab-ის სტრიქონით, და გადაამოწმეთ VPN-ის ტრანსპორტი იმ პროფილიდან, რომელიც რეალურად გამოიყენება.

შემდეგ ჩაწერეთ ისინი ინციდენტის ჩანაწერებში ორ ცალკე ველად. ერთი შეხედვით გაუმჯობესება მხოლოდ მაშინაა თვალსაზრისითი, როცა ჩანაწერი ამბობს, რომელი ფენა შეიცვალა.

დათვალიერება მასობრივი კითხვა არ არის

დირექტორიის სია ამტკიცებს, რომ რამდენიმე ოპერაცია დასრულდა. ის არ ამტკიცებს, რომ გრძელვადიანი კითხვა, ჩაწერა, ბლოკირება ან საცავის უკანა ნაწილი იმავე პირობებში დასრულდება. დიდი ფაილის შუაში გაჩერება სხვა დაკვირვებაა, ვიდრე მონტაჟი, რომელიც არასდროს წარმატდება, და ისინი სხვადასხვა ფენაზე მიუთითებს.

აღწერეთ წარუმატებელი ოპერაცია ზუსტად: გზა, მიმართულება, გაჩერების სავარაუდო ადგილი და ბოლო შესაბამისი მოვლენა კლიენტის, სერვერისა და VPN-ის ჟურნალებში. შემდეგ შეადარეთ, სად გრძელდება ტრაფიკი და სად ჩერდება.

MTU ჰიპოთეზაა, არა დიაგნოზი

პაკეტის ზომაზე დამოკიდებული დანაკარგი რეალური შესაძლებლობაა, როცა გვირაბი დიდ სეგმენტებს ატარებს, და ის ზუსტად იმ შაბლონს ქმნის, როცა დათვალიერება მუშაობს, კითხვა კი ჩერდება. თუმცა ეს შაბლონი MTU-ის პრობლემას არ ამტკიცებს, რადგან იგივე ფორმა ჩნდება მაშინ, როცა სერვერი ნელია, როცა ქსელური კედელი გრძელვადიან კავშირს ვადის ამოწურვით წყვეტს, ან როცა დისკი დაკავებულია. შეამოწმეთ ჰიპოთეზა კონტროლირებადი ცდით და არა ყველგან MTU-ის დაწევით და გამარჯვების გამოცხადებით.

ვადის ამოწურვა თავისთავად არაფერს ამბობს იმაზე, უნდა შეიცვალოს თუ არა UDP. ეს სიმპტომია რამდენიმე შესაძლო მფლობელით.

შეცვალეთ ერთი ცვლადი ერთდროულად

ტრანსპორტების შედარებისას შეინახეთ NFS-ის დატვირთვა და ყველა სხვა პარამეტრი უცვლელად. მონტაჟის ტრანსპორტის, გვირაბის პროტოკოლისა და MTU-ის შეცვლა ერთსა და იმავე ტექნიკურ ფანჯარაში იძლევა შედეგს, რომელსაც ვერავინ მიაკუთვნებს. შეასრულეთ იგივე ფაილური ოპერაცია შეცვლამდე და შემდეგ, და ჩაწერეთ შედეგი ყოველ ნაბიჯზე.

შეინახეთ წინა მნიშვნელობებიც ბილეთში. თუ ცვლილება საქმეს აუარესებს, უკან დაბრუნება უნდა იყოს დოკუმენტირებული რიცხვი და არა ვინმეს მეხსიერება იმისა, როგორ იყო ადრე.

წაიკითხეთ ის ფენა, რომელიც ჩავარდა

თუ გვირაბი მუშაობს და NFS-ის მოთხოვნა ელოდება, VPN არ ჩავარდნილა; ჩავარდა ფაილური სერვისი. თუ გვირაბი დაეცა, NFS-ის მოთხოვნის წარუმატებლობა შედეგია და არა მიზეზი. ორივე ფენის ჟურნალის სტრიქონების შეჯერება ამ ორი შემთხვევის გარჩევის უსწრაფესი გზაა და სჯობს ფაილების მმართველიდან გამოცნობას.

დაწერეთ დასკვნა ორი წინადადებით, თითო ფენაზე. ეს საკმარისია, რომ შემდეგმა ადამიანმა გაიმეოროს გამოცდა იმის ხელახლა გამოტანის გარეშე, თუ რომელი ტრანსპორტი რომელია.