VMware NSX პატარებისთვის. ნაწილი 5: დატვირთვის ბალანსერის კონფიგურაცია

ნაწილი პირველი. შესავალი
Მეორე ნაწილი. Firewall-ისა და NAT-ის წესების კონფიგურაცია
ნაწილი მესამე. DHCP-ის კონფიგურაცია
ნაწილი მეოთხე. მარშრუტის დაყენება

ბოლო დროს ვისაუბრეთ NSX Edge-ის შესაძლებლობებზე სტატიკური და დინამიური მარშრუტიზაციის კუთხით, დღეს კი load balancer-ს შევეხებით.
სანამ დაყენებას დავიწყებთ, მინდა მოკლედ შეგახსენოთ დაბალანსების ძირითადი ტიპები.

Теория

ყველა დღევანდელი დატვირთვის დაბალანსების გადაწყვეტილებები ყველაზე ხშირად იყოფა ორ კატეგორიად: დაბალანსება მოდელის მეოთხე (სატრანსპორტო) და მეშვიდე (აპლიკაციის) დონეზე. ᲐᲜ ᲗᲣ. OSI მოდელი არ არის საუკეთესო საცნობარო წერტილი დაბალანსების მეთოდების აღწერისას. მაგალითად, თუ L4 ბალანსერი ასევე მხარს უჭერს TLS შეწყვეტას, ხდება თუ არა ის L7 ბალანსერი? მაგრამ ეს არის ის, რაც არის.

• ბალანსერი L4 ყველაზე ხშირად ეს არის შუა პროქსი, რომელიც დგას კლიენტსა და ხელმისაწვდომ ბექენდებს შორის, რომელიც წყვეტს TCP კავშირებს (ანუ დამოუკიდებლად პასუხობს SYN-ს), ირჩევს backend-ს და იწყებს ახალ TCP სესიას მის მიმართულებით, დამოუკიდებლად აგზავნის SYN-ს. ეს ტიპი ერთ-ერთი ძირითადია, შესაძლებელია სხვა ვარიანტებიც.
• ბალანსერი L7 ანაწილებს ტრაფიკს ხელმისაწვდომ სარეზერვო სისტემაზე „უფრო დახვეწილ“, ვიდრე ამას აკეთებს L4 ბალანსერი. მას შეუძლია გადაწყვიტოს რომელი backend აირჩიოს, მაგალითად, HTTP შეტყობინების შიგთავსის საფუძველზე (URL, ქუქი და ა.შ.).

მიუხედავად ტიპისა, ბალანსერს შეუძლია შემდეგი ფუნქციების მხარდაჭერა:

• სერვისის აღმოჩენა არის ხელმისაწვდომი სარეზერვო სისტემის (Static, DNS, Consul, Etcd და ა.შ.) ნაკრების განსაზღვრის პროცესი.
• აღმოჩენილი ბექენდების ფუნქციონირების შემოწმება (ბეკენდის აქტიური „პინგი“ HTTP მოთხოვნის გამოყენებით, TCP კავშირებში პრობლემების პასიური გამოვლენა, პასუხებში რამდენიმე 503 HTTP კოდის არსებობა და ა.შ.).
• თავად დაბალანსება (რაუნდი, შემთხვევითი შერჩევა, წყაროს IP ჰეში, URI).
• TLS შეწყვეტა და სერტიფიკატის დადასტურება.
• უსაფრთხოებასთან დაკავშირებული ვარიანტები (ავთენტიფიკაცია, DoS თავდასხმის პრევენცია, სიჩქარის შეზღუდვა) და მრავალი სხვა.

NSX Edge გთავაზობთ მხარდაჭერას დატვირთვის ბალანსერის განლაგების ორი რეჟიმისთვის:

პროქსი რეჟიმი, ან ცალმხრივი. ამ რეჟიმში, NSX Edge იყენებს მის IP მისამართს, როგორც წყაროს მისამართს, როდესაც აგზავნის მოთხოვნას ერთ-ერთ ბექენდში. ამრიგად, ბალანსერი ერთდროულად ასრულებს Source და Destination NAT ფუნქციებს. Backend ხედავს მთელ ტრაფიკს, როგორც გაგზავნილი ბალანსერისგან და პირდაპირ რეაგირებს მასზე. ასეთ სქემაში, ბალანსერი უნდა იყოს იმავე ქსელის სეგმენტში შიდა სერვერებთან.

აი, როგორ მიდის საქმე:
1. მომხმარებელი აგზავნის მოთხოვნას VIP მისამართზე (ბალანსერის მისამართი), რომელიც არის კონფიგურირებული Edge-ზე.
2. Edge ირჩევს ერთ-ერთ backend-ს და ასრულებს დანიშნულების NAT-ს, ანაცვლებს VIP მისამართს შერჩეული ბექენდის მისამართით.
3. Edge ასრულებს წყაროს NAT-ს, ანაცვლებს იმ მომხმარებლის მისამართს, რომელმაც გაგზავნა მოთხოვნა თავისით.
4. პაკეტი იგზავნება შერჩეულ ბექენდში.
5. ბექენდი პირდაპირ არ პასუხობს მომხმარებელს, არამედ Edge-ს, ვინაიდან მომხმარებლის თავდაპირველი მისამართი შეიცვალა ბალანსერის მისამართით.
6. Edge გადასცემს სერვერის პასუხს მომხმარებელს.
დიაგრამა არის ქვემოთ.


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

მექანიზმი ასეთია:
1. მომხმარებელი აგზავნის მოთხოვნას VIP მისამართზე (ბალანსერის მისამართი), რომელიც არის კონფიგურირებული Edge-ზე.
2. Edge ირჩევს ერთ-ერთ backend-ს და ასრულებს დანიშნულების NAT-ს, ანაცვლებს VIP მისამართს შერჩეული ბექენდის მისამართით.
3. პაკეტი იგზავნება შერჩეულ ბექენდში.
4. ბექენდი იღებს მოთხოვნას მომხმარებლის ორიგინალური მისამართით (წყარო NAT არ იყო შესრულებული) და პირდაპირ პასუხობს მას.
5. ტრაფიკი კვლავ მიიღება დატვირთვის ბალანსერის მიერ, ვინაიდან ინლაინ სქემაში ის ჩვეულებრივ მოქმედებს როგორც ნაგულისხმევი კარიბჭე სერვერის ფერმაში.
6. Edge ახორციელებს წყაროს NAT-ს მომხმარებლისთვის ტრაფიკის გასაგზავნად, მისი VIP-ის გამოყენებით, როგორც წყაროს IP მისამართი.
დიაგრამა არის ქვემოთ.

პრაქტიკა

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

SSL სერთიფიკატის გენერირება, რომელსაც გამოიყენებს NSX Edge
შეგიძლიათ შემოიტანოთ მოქმედი CA სერთიფიკატი ან გამოიყენოთ ხელმოწერილი. ამ ტესტისთვის გამოვიყენებ ხელმოწერას.

1. vCloud Director ინტერფეისში გადადით Edge სერვისების პარამეტრებში.
   
2. გადადით სერთიფიკატების ჩანართზე. მოქმედებების სიიდან აირჩიეთ ახალი CSR-ის დამატება.
   
3. შეავსეთ საჭირო ველები და დააჭირეთ შენახვას.
   
4. აირჩიეთ ახლად შექმნილი CSR და აირჩიეთ თვითმოწერის CSR ვარიანტი.
   
5. აირჩიეთ სერთიფიკატის მოქმედების ვადა და დააჭირეთ შენახვას
   
6. ხელმოწერილი სერთიფიკატი გამოჩნდება ხელმისაწვდომის სიაში.
   

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

1. გადადით Load Balancer ჩანართზე და ჩართეთ ბალანსერი. აქსელერაციის ჩართული ვარიანტი საშუალებას აძლევს ბალანსერს გამოიყენოს უფრო სწრაფი L4 დაბალანსება L7-ის ნაცვლად.
   
2. გადადით აპლიკაციის პროფილის ჩანართზე აპლიკაციის პროფილის დასაყენებლად. დააწკაპუნეთ +.
   
3. დააყენეთ პროფილის სახელი და შეარჩიეთ ტრაფიკის ტიპი, რომელზეც გამოყენებული იქნება პროფილი. ნება მომეცით აგიხსნათ რამდენიმე პარამეტრი.
   არსებულ – ინახავს და აკონტროლებს სესიის მონაცემებს, მაგალითად: აუზში რომელი სერვერი ემსახურება მომხმარებლის მოთხოვნას. ეს უზრუნველყოფს მომხმარებლის მოთხოვნების მარშრუტირებას სესიის ან შემდგომი სესიების მთელი პერიოდის განმავლობაში.
   SSL გავლის ჩართვა – როდესაც ეს პარამეტრი არჩეულია, NSX Edge წყვეტს SSL-ის შეწყვეტას. ამის ნაცვლად, შეწყვეტა ხდება უშუალოდ სერვერებზე, რომლებიც დაბალანსებულია.
   X-Forwarded-For HTTP სათაურის ჩასმა – საშუალებას გაძლევთ განსაზღვროთ კლიენტის წყაროს IP მისამართი, რომელიც უკავშირდება ვებ სერვერს დატვირთვის ბალანსერის საშუალებით.
   ჩართეთ Pool Side SSL – გაძლევთ საშუალებას მიუთითოთ, რომ არჩეული ფონდი შედგება HTTPS სერვერებისგან.
   
4. ვინაიდან მე დავაბალანსებ HTTPS ტრაფიკს, უნდა გავააქტიურო Pool Side SSL და ავირჩიო ადრე გენერირებული სერთიფიკატი ვირტუალური სერვერის სერთიფიკატები -> სერვისის სერთიფიკატის ჩანართში.
   
5. ანალოგიურად Pool Certificates -> Service Certificate.
   

ჩვენ ვქმნით სერვერების აუზს, რომლის ტრაფიკი იქნება დაბალანსებული Pools

1. გადადით აუზების ჩანართზე. დააწკაპუნეთ +.
   
2. ვაყენებთ აუზის სახელს, ვირჩევთ ალგორითმს (გამოვიყენებ მრგვალ რობინს) და მონიტორინგის ტიპს ჯანმრთელობის შემოწმების ბექენდისთვის. ოფცია გამჭვირვალე მიუთითებს, არის თუ არა კლიენტების საწყისი წყაროს IP-ები ხილული შიდა სერვერებისთვის.
   • თუ ვარიანტი გამორთულია, შიდა სერვერების ტრაფიკი მოდის ბალანსერის წყაროს IP-დან.
   • თუ პარამეტრი ჩართულია, შიდა სერვერები ხედავენ კლიენტების წყაროს IP-ს. ამ კონფიგურაციაში, NSX Edge უნდა იმოქმედოს როგორც ნაგულისხმევი კარიბჭე, რათა დაბრუნებული პაკეტები გაიაროს NSX Edge-ში.

   NSX მხარს უჭერს შემდეგ დაბალანსების ალგორითმებს:

   • IP_HASH – სერვერის შერჩევა თითოეული პაკეტის წყაროსა და დანიშნულების IP-სთვის ჰეშის ფუნქციის შედეგებზე დაყრდნობით.
   • LEASTCONN - შემომავალი კავშირების დაბალანსება, კონკრეტულ სერვერზე უკვე ხელმისაწვდომი რაოდენობის მიხედვით. ახალი კავშირები მიმართული იქნება სერვერზე, რომელსაც აქვს ყველაზე ნაკლები კავშირი.
   • ROUND_ROBIN – ახალი კავშირები იგზავნება თითოეულ სერვერზე რიგრიგობით, მისთვის მინიჭებული წონის შესაბამისად.
   • URI – URI-ის მარცხენა ნაწილი (კითხვის ნიშანამდე) ჰეშირებულია და იყოფა აუზში სერვერების მთლიან წონაზე. შედეგი მიუთითებს, თუ რომელი სერვერი მიიღებს მოთხოვნას, რაც უზრუნველყოფს, რომ მოთხოვნა ყოველთვის იყოს იმავე სერვერზე, სანამ ყველა სერვერი ხელმისაწვდომი იქნება.
   • HTTPHEADER – დაბალანსება კონკრეტული HTTP სათაურის საფუძველზე, რომელიც შეიძლება იყოს მითითებული როგორც პარამეტრი. თუ სათაური აკლია ან არ აქვს რაიმე მნიშვნელობა, გამოიყენება ROUND_ROBIN ალგორითმი.
   • URL – ყოველი HTTP GET მოთხოვნა ეძებს არგუმენტად მითითებულ URL პარამეტრს. თუ პარამეტრს მოჰყვება თანაბარი ნიშანი და მნიშვნელობა, მაშინ მნიშვნელობა ჰეშირდება და იყოფა გაშვებული სერვერების საერთო წონაზე. შედეგი მიუთითებს, რომელი სერვერი იღებს მოთხოვნას. ეს პროცესი გამოიყენება მომხმარებლის ID-ების მოთხოვნებში თვალყურის დევნებისთვის და იმის უზრუნველსაყოფად, რომ იგივე მომხმარებლის ID ყოველთვის იგზავნება იმავე სერვერზე, სანამ ყველა სერვერი ხელმისაწვდომი იქნება.

   

3. წევრების ბლოკში დააწკაპუნეთ + სერვერების დასამატებლად აუზში.
   
   
   აქ თქვენ უნდა მიუთითოთ:
   • სერვერის სახელი;
   • სერვერის IP მისამართი;
   • პორტი, რომელზეც სერვერი მიიღებს ტრაფიკს;
   • პორტი ჯანმრთელობის შემოწმებისთვის (Monitor healthcheck);
   • წონა – ამ პარამეტრის გამოყენებით შეგიძლიათ დაარეგულიროთ აუზის კონკრეტული წევრისთვის მიღებული ტრაფიკის პროპორციული რაოდენობა;
   • Max Connections – სერვერთან კავშირების მაქსიმალური რაოდენობა;
   • Min Connections – კავშირების მინიმალური რაოდენობა, რომელიც სერვერმა უნდა დაამუშავოს, სანამ ტრაფიკი გადაიგზავნება აუზის შემდეგ წევრზე.

   
   
   ასე გამოიყურება სამი სერვერის საბოლოო აუზი.
   

ვირტუალური სერვერის დამატება

1. გადადით ვირტუალური სერვერების ჩანართზე. დააწკაპუნეთ +.
   
2. ჩვენ ვააქტიურებთ ვირტუალურ სერვერს ვირტუალური სერვერის ჩართვით.
   ჩვენ ვაძლევთ მას სახელს, ვირჩევთ ადრე შექმნილ აპლიკაციის პროფილს, აუზს და მივუთითებთ IP მისამართს, რომელზეც ვირტუალური სერვერი მიიღებს მოთხოვნებს გარედან. ჩვენ ვაზუსტებთ HTTPS პროტოკოლს და პორტს 443.
   არჩევითი პარამეტრები აქ:
   კავშირის ლიმიტი – ერთდროული კავშირების მაქსიმალური რაოდენობა, რომელსაც შეუძლია ვირტუალური სერვერის დამუშავება;
   კავშირის სიჩქარის ლიმიტი (CPS) – ახალი შემომავალი მოთხოვნების მაქსიმალური რაოდენობა წამში.
   

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


გვერდის განახლების შემდეგ მოთხოვნა დამუშავდება შემდეგი სერვერის მიერ:


და ისევ - მესამე სერვერის შემოწმება აუზიდან:


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

ბალანსერის სტატუსის შემოწმება Edge gateway კონსოლიდან. ამისათვის შედით აჩვენეთ სერვისის loadbalancer აუზი.


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

• TCP-მონიტორი,
• HTTP მონიტორი,
• HTTPS-მონიტორი.

შევქმნათ ახალი.

1. გადადით სერვისის მონიტორინგის ჩანართზე, დააჭირეთ +.
   
2. აირჩიეთ:
   • ახალი მეთოდის დასახელება;
   • ინტერვალი, რომლითაც გაიგზავნება მოთხოვნები,
   • პასუხს ელოდება დრო,
   • მონიტორინგის ტიპი – HTTPS მოთხოვნა GET მეთოდის გამოყენებით, მოსალოდნელი სტატუსის კოდი – 200(OK) და მოთხოვნის URL.
3. ეს დაასრულებს ახალი სერვისის მონიტორის დაყენებას; ახლა ჩვენ შეგვიძლია მისი გამოყენება აუზის შექმნისას.
   

განაცხადის წესების დაყენება

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

1. წესის შესაქმნელად გადადით ბალანსერის აპლიკაციის წესების ჩანართზე.
   
2. აირჩიეთ სახელი, სკრიპტი, რომელიც გამოიყენებს წესს და დააჭირეთ Keep.
   
3. წესის შექმნის შემდეგ, ჩვენ გვჭირდება უკვე კონფიგურირებული ვირტუალური სერვერის რედაქტირება.
   
4. Advanced ჩანართში დაამატეთ ჩვენ მიერ შექმნილი წესი.
   

ზემოთ მოცემულ მაგალითში ჩვენ გავააქტიურეთ tlsv1 მხარდაჭერა.

კიდევ რამდენიმე მაგალითი:

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

acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME


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

acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down

კიდევ უფრო მეტი მაგალითი აქ.

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

წყარო: www.habr.com