VPN სესიები როლის მიხედვით გააფართოეთ, შემდეგ შეამოწმეთ მარცხის რეზერვი
დისტანციური წვდომის ბალანსირება, მარცხზე გადართვა და საიტებს შორის კლასტერიზაცია ცალკე მექანიზმებია. დათვალეთ რა გადარჩება ერთი გეიტვეის მარცხის შემდეგ, და არა მთლიანი შეძენილი რაოდენობა.
თქვენ ამატებთ მეორე გეიტვეის, კონსოლი აჩვენებს ორ ჯანსაღ წევრს, და სესიების ზედა ზღვარი ძლივს იძვრება, რადგან ვერაფერმა არ უთხრა კლიენტებს როგორ მიაღწიონ ახალ ყუთს. VPN სერვისის გაფართოება ზედიზედ ორი გადაწყვეტილებაა: რომელი მექანიზმი ანაწილებს კლიენტებს ამ ტიპის კავშირისთვის და რამდენი სიმძლავრე რჩება ყველაზე ცუდი ერთჯერადი დანაკარგის შემდეგ. თუ მათ შებრუნებული თანმიმდევრობით აიღებთ, მიიღებთ დიზაინს, რომელიც ზედმეტი ჩანს და ზუსტად მაშინ ვარდება, როცა საჭიროა. დაიწყეთ კონსოლიდან და შემდეგ გააკეთეთ არითმეტიკა.
შეუსაბამეთ მექანიზმი სესიის ტიპს
დისტანციური მომხმარებლები, საიტებს შორის პარტნიორები და მუდამ ჩართული მოწყობილობის გვირაბები ურთიერთშემცვლელი სესიები არ არიან. ერთ-ერთი მათგანისთვის აგებული განაწილების ფუნქცია ჩვეულებრივ მოლაპარაკების დროს ამოტრიალებს კლიენტს, რაც არაფერს ნიშნავს იმ პარტნიორისთვის, რომელსაც უკვე აქვს ფიქსირებული მისამართი და სტატიკური კონფიგურაცია.
Cisco-ს ASA-ის მაღალი ხელმისაწვდომობის სახელმძღვანელო სამ შესაძლებლობას ცალ-ცალკე ინახავს: დისტანციური წვდომის VPN-ის დატვირთვის ბალანსირება, მდგომარეობის შემანარჩუნებელი გადართვა და საიტებს შორის კლასტერიზაცია. მხოლოდ პირველი გადაადგილებს შესაფერის კლიენტს ჯგუფის ჩანაწერიდან წევრზე, და LAN-იდან-LAN-ზე კავშირები ამ განაწილების გარეთ რჩება. ზოგად TCP ბალანსერი ვერ შეცვლის პროტოკოლის საკუთარ გადამისამართების საფეხურს, რადგან გვირაბის ხელის ჩამორთმევა ჩვეულებრივი HTTP არ არის, რომ პროქსიმ გადაწეროს. პრაქტიკული შედეგია ბალანსერი, რომელიც კავშირს იღებს და მაინც ტოვებს კლიენტს გვირაბის შექმნის გარეშე.
წაიკითხეთ ფუნქციების სია თქვენი სესიის ტიპის მიმართ, სანამ მეორე მოწყობილობას შეუკვეთავთ. ლიცენზიის ხაზი და მექანიზმის ხაზი ცალკე ჩანაწერებია, და ერთი მეორეს არ ნიშნავს.
გამოთვალეთ მაგალითი ვარაუდის ნაცვლად
დავუშვათ სამი გეიტვეი თითოეული დადასტურებულია 800 ერთდროულ გვირაბზე თქვენ მიერ დამტკიცებული დატვირთვის ქვეშ, რაც ჯამში 2,400-ია. პიკური საათის 1,650 მიზანი კომფორტული ჩანს, სანამ ერთი ერთეული დაიკარგება, და შემდეგ გადარჩენილ წყვილს უნდა შეეძლოს 1,650-ის შენარჩუნება მკაცრი 1,600-ის წინააღმდეგ. დიზაინი უკვე ჩავარდა და ვერც ერთი გადართვის მორგება ვერ ასწორებს არითმეტიკას.
დააყენეთ მიზანი ისე, რომ გადარჩენილი ნაკრები კვლავ ასრულებდეს მას, რაც სამწევრიანი ჯგუფისთვის ნიშნავს საერთო რაოდენობის ორ მესამედზე დაბლა დარჩენას. ეს თანაფარდობა არითმეტიკის თვისებაა და არა რომელიმე პროდუქტის, ამიტომ გადათვალეთ, როცა წევრის დადასტურებული რიცხვი იცვლება. შეინახეთ ლიცენზირებული რაოდენობა, დოკუმენტირებული მაქსიმუმი და თქვენი გაზომილი რიცხვი სამ სვეტში, რადგან ისინი იშვიათად ემთხვევა და ყველაზე პატარა წყვეტს. მეოთხე სვეტი დაკვირვებული პიკური საათისთვის გეგმას პირველი თვის შემდეგაც პატიოსნად ინახავს.
დაგეგმეთ ხელახალი დაკავშირების ტალღა და არა მხოლოდ სტაბილური მდგომარეობა
ჩავარდნილ წევრზე სესიები ჩუმად სხვაგან არ ბრუნდება. მექანიზმის მიხედვით ისინი მდგომარეობით გადადიან, ნულიდან ხელახლა მოლაპარაკობენ, ან ელოდებიან, რომ აპლიკაცია საკუთარი განრიგით ხელახლა სცადოს.
რამდენიმე ათასი კლიენტი, რომელიც წუთში ხელახლა ცდილობს, სხვა მოვლენაა, ვიდრე სტაბილური 1,650, და აუთენტიფიკაციის სერვერები ამას პირველები გრძნობენ. შეამოწმეთ ასევე პულის სივრცე, რადგან გადამისამართება მას არ ეკითხება: წევრი, რომელსაც მისამართის გამოყოფა არ შეუძლია, მაინც იღებს კლიენტს და შემდეგ მის ტრაფიკს ყრის.
შეამოწმეთ სიმძლავრე პულითა და მარშრუტით
შემოწმება მხოლოდ-კითხვის ვარჯიშია, რომელიც ტექნიკური ფანჯრის გახსნამდე იჭერს დიზაინის უმეტეს შეცდომებს. შეაგროვეთ პული თითოეული წევრისთვის, აქტიური სესიების რაოდენობა და დაბრუნების მარშრუტი კლიენტის ქვექსელამდე, შემდეგ შეადარეთ თითოეული გეგმას. პულის ამოწურვა და დაბრუნების მარშრუტის არქონა ორივე ისე ჩანს, როგორც კლიენტი, რომელიც აუთენტიფიკაციას გადის და შემდეგ ტრაფიკს კარგავს.
show vpn-sessiondb summary
show running-config ip local pool
show vpn load-balancing
show route 10.40.12.0 255.255.255.0
გაუშვით ეს კითხვები თითოეულ წევრზე ჩვეულებრივ პიკურ საათში და არა წყნარში. წევრი, რომელიც სესიებს იუწყება, მაგრამ თავისუფალი მისამართები არ აქვს, უკვე თავის პრაქტიკულ ზღვარზეა, რაც არ უნდა თქვას ლიცენზიამ. ჩაწერეთ firmware-ის ვერსია ყოველი გამოტანის გვერდით, რადგან ბრძანებების სახელები გამოშვებებს შორის იცვლება.
ივარჯიშეთ დანაკარგზე ერთხელ განზრახ, სამუშაო საათების გარეთ, და ჩაწერეთ რას იუწყებიან გადარჩენილი წევრები, სანამ ეს ხდება. წევრი, რომელიც გადამისამართებას იღებს, მაგრამ პულში ადგილი არ აქვს, წარუმატებელ გამოყოფად ჩანს, რასაც დამატებითი გამტარუნარიანობა არასოდეს ასწორებს. შეინახეთ დადასტურებული რიცხვები თარიღთან ერთად გეგმის გვერდით, რათა შემდეგი სიმძლავრის მიმოხილვა მტკიცებულებებიდან დაიწყოს და არა ლიცენზიის ფურცლიდან. დაამატეთ იმ ვარჯიშის შედეგი იმავე გვერდს, მაშინაც კი, როცა რიცხვები გეგმას ემთხვევა.