გადართვის ტესტი: გადაურჩება დამყარებული TCP ნაკადი?

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

ორი შედეგი, რომლებიც ერთ წარმატებად გამოიყურება

წარმოიდგინეთ კლიენტი 10.90.0.42-ზე, რომელსაც კავშირი აქვს 198.51.100.20:443-თან. ძირითადი გასასვლელი ამას ერთ საჯარო მისამართად და პორტად გარდაქმნის, ხოლო სარეზერვო გასასვლელი სხვად. კლიენტის შიდა მისამართი არასოდეს იცვლება, ამიტომაც ადამიანები ელიან, რომ კავშირი გადარჩება.

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

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

რას ხედავს სერვერი, როცა გასასვლელი იცვლება

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

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

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

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

რატომ არ არის საკმარისი იგივე საჯარო მისამართი

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

RFC 3022 აღწერს მისამართების გარდაქმნას და გარდამქმნელ მოწყობილობებს შორის მდგომარეობის გაცვლას სარეზერვო გეგმის ნაწილად მიიჩნევს. მცურავი მისამართი ან კოპირებული პროფილი კონფიგურაციას გადაადგილებს და არა მდგომარეობას.

ამიტომ ტესტი, რომელიც მხოლოდ სარეზერვოს გავლით აკეთებს ping-ს, ძალიან ცოტას ამტკიცებს. ping-ს დასაკარგი კავშირის მდგომარეობა არ აქვს.

გადაწყვიტეთ, რამდენად ძლიერია მოთხოვნა

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

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

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

შეამოწმეთ ძველი ნაკადი და ახალი მოთხოვნა

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

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

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

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