Linux-ის აქტიურ-სარეზერვო bond all-active EVPN-ზე: რა იშლება

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

რას აკეთებს აქტიურ-სარეზერვო შემომავალ კადრთან

bonding რეჟიმი 1 გადაცემის გზაზე ზუსტად ერთ slave-ს ინახავს და ცვლის მხოლოდ მაშინ, როცა მიმდინარე ფუჭდება. ეს ნაწილი კარგად ცნობილია. აქ მნიშვნელოვანი მიღების მხარეა: ბირთვი კადრს სტეკს გადასცემს მხოლოდ მაშინ, როცა ის აქტიურ slave-ზე მოდის, და ყრის იმ კადრებს, რომლებიც სხვა slave-ზე ჩნდება. ეს all_slaves_active პარამეტრი სწორედ ამ წესის შესარბილებლად არსებობს და ნაგულისხმევად გამორთულია. ip -d link show bond0 ბეჭდავს მიმდინარე მნიშვნელობას რეჟიმის გვერდით.

/proc/net/bonding/bond0 ასახელებს აქტიურ slave-ს და აცნობს თითოეული slave-ის ბმულის მდგომარეობას. ეს ფაილი ერთადერთი პატიოსანი წყაროა იმისა, თუ რომელი პორტი ატარებს ახლა ტრაფიკს.

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

რას აკეთებს all-active multihoming შორეულ შემდეგ hop-თან

EVPN multihoming აღწერს leaf-ების ერთობლიობას, რომლებიც ერთ Ethernet სეგმენტს იზიარებენ, ESI-ით იდენტიფიცირებულს, და აცხადებს ამ სეგმენტს ფაბრიკის დანარჩენ ნაწილს. all-active მოდელში შორეული peer-ები სეგმენტის მისამართებისთვის ერთზე მეტ შემდეგ hop-ს აყენებენ. სერვერისკენ unicast მაშინ ნებისმიერ leaf-ზე შეიძლება მოვიდეს და ფაბრიკა თავისუფლად ირჩევს თითოეული დინებისთვის. ეს არის დიზაინის მთელი აზრი და ესეც არის ის ვარაუდი, რომელიც სერვერის bond-მა უნდა დააკმაყოფილოს.

დატბორილი ტრაფიკი სხვა წესს მიჰყვება. leaf-ები თითოეული სეგმენტისთვის დანიშნულ forwarder-ს ირჩევენ, ამიტომ broadcast, უცნობი unicast და multicast ჩვეულებრივ ერთ-ერთი მათგანის გავლით შემოდის. ამრიგად unicast და დატბორვა ორ ცალკე გადაწყვეტილებას იღებს და მხოლოდ ერთი მათგანი ჩანს ჰოსტის bond-ის მდგომარეობაში.

სად განსხვავდება ორი არჩევანი

ბირთვი თავის აქტიურ slave-ს ბმულის მდგომარეობიდან და საკუთარი პოლიტიკიდან ირჩევს. ფაბრიკა შემდეგ hop-ებს EVPN მარშრუტებიდან ირჩევს, დანიშნულ forwarder-ს კი leaf-ებს შორის არჩევნიდან. არც ერთი პროცესი მეორეს არ ეკითხება. როცა ისინი სხვადასხვა leaf-ს ირჩევენ, ხარვეზი მიმართულებაზეა დამოკიდებული: რასაც სერვერი აგზავნის, ნორმალურად გადის, პასუხები კი ქრება.

არსებობს ორი მხარდაჭერილი გამოსავალი და ისინი ურთიერთშემცვლელი არ არის. მიეცით ჰოსტს bond, რომელსაც ფაბრიკა ერთ ლოგიკურ მიერთებად მიიჩნევს, რაც პრაქტიკაში leaf-ებთან შეთანხმებულ LACP bond-ს ნიშნავს, და ორივე ბმული ნამდვილად ერთად აქტიურია. ან მიიღეთ ასევე single-active მიწოდება ფაბრიკიდან, რათა სეგმენტმა bond-ის მსგავსი ერთ-პორტ-რიგით მოდელი დაიცვას. რაც არ მუშაობს, არის all-active სეგმენტი იმ bond-ის წინ, რომელიც მხოლოდ ერთ პორტზე უსმენს, თუ განზრახ არ ჩართავთ მიღებას არააქტიურ slave-ებზე და არ მიიღებთ ამის შემდეგ მომდევნო ორმაგ მიწოდებას.

რატომ აგრძელებს სარეზერვო კაბელი ჯანმრთელად გამოჩენას

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

ამის ნაცვლად ჰკითხეთ, რომელი ფიზიკური პორტი გამოიყენა დაბრუნების კადრმა. ჰოსტზე დათვალეთ მიღებული პაკეტები slave-ის მიხედვით და არა bond-ის, რადგან bond-ის მთვლელი ასიმეტრიას მალავს. leaf-ზე შეხედეთ ხიდის გადაგზავნის ჩანაწერებს სერვერის MAC-ისთვის და შემდეგი hop-ების ერთობლიობას, რომელსაც EVPN მარშრუტი ატარებს. თუ ჩანაწერი მიუთითებს იმ leaf-ზე, რომლის ჰოსტ-ბმული სარეზერვოა, დიზაინი იმ პორტში აწვდის, რომელსაც ჰოსტი უგულებელყოფს. ეს კონფიგურაციის შეუთანხმებლობაა და არა ტექნიკის ხარვეზი, და ბმულის მდგომარეობის ვერც ერთი მონიტორინგი ვერ გამოავლენს.

შეამოწმეთ მიწოდება ორივე მიმართულებით, და არა ბმულის მდგომარეობა

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

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

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