ღრუბლოვანი ინფრასტრუქტურის ქსელური ნაწილის გაცნობა

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

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

რა არის ღრუბელი? იგივე ვირტუალიზაცია - პროფილის ხედი?

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

Cloud Computing (შემდგომში Cloud) არის მოდელი განაწილებულ გამოთვლით რესურსებზე მოსახერხებელი წვდომის უზრუნველსაყოფად, რომელიც უნდა განლაგდეს და გაშვებული იყოს მოთხოვნის შესაბამისად, რაც შეიძლება დაბალი შეყოვნებით და მინიმალური ხარჯებით მომსახურების მიმწოდებლისთვის.

ვირტუალიზაცია - ეს არის ერთი ფიზიკური პირის (მაგალითად, სერვერის) დაყოფის შესაძლებლობა რამდენიმე ვირტუალურად, რითაც გაზრდის რესურსების გამოყენებას (მაგალითად, გქონდა 3 სერვერი დატვირთული 25-30 პროცენტით, ვირტუალიზაციის შემდეგ მიიღებთ 1 სერვერს დატვირთულს. 80-90 პროცენტით). ბუნებრივია, ვირტუალიზაცია ჭამს ზოგიერთ რესურსს - თქვენ გჭირდებათ ჰიპერვიზორის კვება, თუმცა, როგორც პრაქტიკამ აჩვენა, თამაში სანთლად ღირს. ვირტუალიზაციის იდეალური მაგალითია VMWare, რომელიც შესანიშნავად ამზადებს ვირტუალურ მანქანებს, ან მაგალითად KVM, რომელიც მე მირჩევნია, მაგრამ ეს გემოვნების საკითხია.

ჩვენ ვირტუალიზაციას ვიყენებთ ამის გაცნობიერების გარეშე და რკინის მარშრუტიზატორებიც კი უკვე იყენებენ ვირტუალიზაციას - მაგალითად, JunOS-ის უახლეს ვერსიაში ოპერაციული სისტემა დაინსტალირებულია როგორც ვირტუალური მანქანა რეალურ დროში Linux დისტრიბუციის თავზე (Wind River 9). მაგრამ ვირტუალიზაცია არ არის ღრუბელი, მაგრამ ღრუბელი ვერ იარსებებს ვირტუალიზაციის გარეშე.

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

ღრუბლის შექმნა უბრალოდ რამდენიმე ჰიპერვიზორის ერთ L2 დომენში შეგროვებით, რამდენიმე yaml playbook-ის დამატება vlan-ების ავტომატური რეგისტრაციისთვის რაიმე სახის ანსიბილის საშუალებით და მასზე ორკესტრის სისტემის მსგავსი რაღაცის ჩაკეტვა ვირტუალური მანქანების ავტომატურად შესაქმნელად არ იმუშავებს. ეს უფრო ზუსტი იქნება, მაგრამ მიღებული ფრანკენშტაინი არ არის ის ღრუბელი, რომელიც ჩვენ გვჭირდება, თუმცა ეს შეიძლება იყოს საბოლოო ოცნება სხვებისთვის. უფრო მეტიც, თუ თქვენ აიღებთ იგივე Openstack-ს, ის არსებითად მაინც ფრანკენშტეინია, მაგრამ ოჰ, ახლა ამაზე არ ვისაუბროთ.

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

ამრიგად, NIST-ის (სტანდარტებისა და ტექნოლოგიების ეროვნული ინსტიტუტის) დოკუმენტი შეიცავს 5 ძირითად მახასიათებელს, რომელიც უნდა ჰქონდეს ღრუბლოვან ინფრასტრუქტურას:

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

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

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

სწრაფი ადაპტაცია სხვადასხვა პირობებში. სერვისები უნდა იყოს მოქნილი - რესურსების სწრაფი მიწოდება, მათი გადანაწილება, რესურსების დამატება ან შემცირება კლიენტის მოთხოვნით და კლიენტის მხრიდან უნდა იყოს განცდა, რომ ღრუბლოვანი რესურსები გაუთავებელია. გასაგებად, მაგალითად, თქვენ ვერ ხედავთ გაფრთხილებას, რომ Apple iCloud-ში თქვენი დისკის სივრცის ნაწილი გაქრა, რადგან სერვერზე მყარი დისკი გაფუჭდა და დისკები იშლება. გარდა ამისა, თქვენი მხრივ, ამ სერვისის შესაძლებლობები თითქმის უსაზღვროა - გჭირდებათ 2 ტბ - არაა პრობლემა, გადაიხადეთ და მიიღეთ. მსგავსი მაგალითის მოყვანა შესაძლებელია Google.Drive-თან ან Yandex.Disk-თან.

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

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

რატომ გვჭირდება ღრუბელი?

თუმცა, ნებისმიერი ახალი ან არსებული ტექნოლოგია, ნებისმიერი ახალი პროტოკოლი იქმნება რაღაცისთვის (რა თქმა უნდა, RIP-ng-ის გარდა). პროტოკოლის გულისთვის პროტოკოლი არავის სჭირდება (რა თქმა უნდა, RIP-ng-ის გარდა). ლოგიკურია, რომ ღრუბელი შექმნილია მომხმარებლის/კლიენტისთვის რაიმე სახის სერვისის უზრუნველსაყოფად. ჩვენ ყველანი ვიცნობთ მინიმუმ რამდენიმე ღრუბლოვან სერვისს, მაგალითად Dropbox ან Google.Docs, და მე მჯერა, რომ ადამიანების უმეტესობა წარმატებით იყენებს მათ - მაგალითად, ეს სტატია დაიწერა Google.Docs ღრუბლოვანი სერვისის გამოყენებით. მაგრამ ღრუბლოვანი სერვისები, რომლებიც ჩვენ ვიცით, არის ღრუბლის შესაძლებლობების მხოლოდ ნაწილი - უფრო ზუსტად, ისინი მხოლოდ SaaS-ის ტიპის სერვისია. ჩვენ შეგვიძლია მივაწოდოთ ღრუბლოვანი სერვისი სამი გზით: SaaS, PaaS ან IaaS სახით. რა სერვისი გჭირდებათ, დამოკიდებულია თქვენს სურვილებსა და შესაძლებლობებზე.

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

პროგრამული უზრუნველყოფა, როგორც სამსახურის (SaaS) არის მოდელი კლიენტისთვის სრულფასოვანი სერვისის მიწოდებისთვის, მაგალითად, ელექტრონული ფოსტის სერვისი, როგორიცაა Yandex.Mail ან Gmail. სერვისის მიწოდების ამ მოდელში, თქვენ, როგორც კლიენტი, რეალურად არაფერს აკეთებთ, გარდა სერვისების გამოყენებისა - ანუ თქვენ არ გჭირდებათ ფიქრი სერვისის დაყენებაზე, მის შეფერხებაზე ან ზედმეტობაზე. მთავარია არ დაარღვიოთ თქვენი პაროლი; დანარჩენს ამ სერვისის პროვაიდერი გააკეთებს თქვენთვის. სერვისის პროვაიდერის თვალსაზრისით, ის სრულად არის პასუხისმგებელი მთელ სერვისზე - სერვერის აპარატურიდან და ჰოსტის ოპერაციული სისტემებიდან მონაცემთა ბაზის და პროგრამული უზრუნველყოფის პარამეტრებამდე.

პლატფორმა, როგორც სერვისი (PaaS) — ამ მოდელის გამოყენებისას, სერვისის პროვაიდერი კლიენტს აწვდის სამუშაო ნაწილს სერვისისთვის, მაგალითად, ავიღოთ ვებ სერვერი. სერვისის პროვაიდერმა კლიენტს მიაწოდა ვირტუალური სერვერი (ფაქტობრივად, რესურსების ნაკრები, როგორიცაა RAM/CPU/Storage/Nets და ა.შ.) და დააინსტალირა კიდეც OS და საჭირო პროგრამული უზრუნველყოფა ამ სერვერზე, თუმცა, კონფიგურაცია ამ ყველაფერს თავად კლიენტი აკეთებს და სერვისის შესასრულებლად კლიენტი პასუხობს. მომსახურების მიმწოდებელი, როგორც წინა შემთხვევაში, პასუხისმგებელია ფიზიკური აღჭურვილობის, ჰიპერვიზორების, თავად ვირტუალური მანქანის შესრულებაზე, მის ქსელის ხელმისაწვდომობაზე და ა.შ., მაგრამ თავად სერვისი აღარ არის მისი პასუხისმგებლობის სფეროში.

ინფრასტრუქტურა, როგორც სერვისი (IaaS) - ეს მიდგომა უკვე უფრო საინტერესოა, ფაქტობრივად, სერვისის პროვაიდერი კლიენტს აწვდის სრულ ვირტუალიზებულ ინფრასტრუქტურას - ეს არის რესურსების გარკვეული ნაკრები (აუზი), როგორიცაა CPU Cores, RAM, Networks და ა.შ. კლიენტი - რისი გაკეთება სურს კლიენტს ამ რესურსებით გამოყოფილი ფონდის (კვოტის) ფარგლებში - ეს არ არის განსაკუთრებით მნიშვნელოვანი მიმწოდებლისთვის. სურს თუ არა კლიენტს შექმნას საკუთარი vEPC ან თუნდაც შექმნას მინი ოპერატორი და უზრუნველყოს საკომუნიკაციო სერვისები - ეჭვგარეშეა - გააკეთე ეს. ასეთ სცენარში, სერვისის პროვაიდერი პასუხისმგებელია რესურსების უზრუნველყოფაზე, მათ შეცდომის ტოლერანტობაზე და ხელმისაწვდომობაზე, ასევე ოპერაციულ სისტემაზე, რომელიც საშუალებას აძლევს მათ გააერთიანონ ეს რესურსები და გახადონ ისინი კლიენტისთვის ხელმისაწვდომი რესურსების გაზრდის ან შემცირების შესაძლებლობით ნებისმიერ დროს. კლიენტის მოთხოვნით. კლიენტი თავად აკონფიგურირებს ყველა ვირტუალურ მანქანას და სხვა ტინელებს თვითმომსახურების პორტალისა და კონსოლის მეშვეობით, ქსელების დაყენების ჩათვლით (გარდა გარე ქსელებისა).

რა არის OpenStack?

სამივე ვარიანტში სერვისის პროვაიდერს სჭირდება ოპერაციული სისტემა, რომელიც საშუალებას მისცემს შექმნას ღრუბლოვანი ინფრასტრუქტურა. სინამდვილეში, SaaS-ით, ერთზე მეტი განყოფილება პასუხისმგებელია ტექნოლოგიების მთელ დასტაზე - არის განყოფილება, რომელიც პასუხისმგებელია ინფრასტრუქტურაზე - ანუ ის აწვდის IaaS-ს სხვა განყოფილებას, ეს განყოფილება უზრუნველყოფს SaaS-ს კლიენტს. OpenStack არის ერთ-ერთი ღრუბლოვანი ოპერაციული სისტემა, რომელიც საშუალებას გაძლევთ შეაგროვოთ გადამრთველები, სერვერები და შენახვის სისტემები ერთ რესურს აუზში, დაყოთ ეს საერთო აუზი ქვეჯგუფებად (მოიჯარეებად) და მიაწოდოთ ეს რესურსები კლიენტებს ქსელში.

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

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

ამ მასალის დაწერის დროს OpenStack სტრუქტურა ასე გამოიყურება:

სურათი გადაღებულია openstack.org

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

• ჩემი გვერდი — ვებ-ზე დაფუძნებული GUI OpenStack სერვისების მართვისთვის
• ქვაკუთხედური არის იდენტიფიკაციის ცენტრალიზებული სერვისი, რომელიც უზრუნველყოფს ავთენტიფიკაციისა და ავტორიზაციის ფუნქციონირებას სხვა სერვისებისთვის, ასევე მომხმარებლის რწმუნებათა სიგელების და მათი როლების მართვას.
• ნეიტრონი - ქსელის სერვისი, რომელიც უზრუნველყოფს კავშირს სხვადასხვა OpenStack სერვისების ინტერფეისებს შორის (მათ შორის, დაკავშირებას VM-ებს შორის და მათ წვდომას გარე სამყაროსთან)
• Cinder — უზრუნველყოფს წვდომას ვირტუალური მანქანებისთვის შენახვის ბლოკირებაზე
• Nova — ვირტუალური მანქანების სასიცოცხლო ციკლის მართვა
• ერთი შეხედვით - ვირტუალური მანქანის სურათებისა და სნეპშოტების საცავი
• Swift — უზრუნველყოფს შესანახ ობიექტზე წვდომას
• ცელომეტრი — სერვისი, რომელიც უზრუნველყოფს ტელემეტრიის შეგროვების და ხელმისაწვდომი და მოხმარებული რესურსების გაზომვის შესაძლებლობას
• სითბოს - ორკესტრირება, რომელიც დაფუძნებულია შაბლონებზე, რესურსების ავტომატური შექმნისა და უზრუნველყოფის მიზნით

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

თითოეული OpenStack კომპონენტი არის სერვისი, რომელიც ასრულებს კონკრეტულ ფუნქციას და უზრუნველყოფს API-ს ამ ფუნქციის მართვისა და ღრუბლოვანი ოპერაციული სისტემის სხვა სერვისებთან ურთიერთქმედების მიზნით ერთიანი ინფრასტრუქტურის შესაქმნელად. მაგალითად, Nova უზრუნველყოფს გამოთვლითი რესურსების მართვას და API-ს ამ რესურსების კონფიგურაციაზე წვდომისთვის, Glance უზრუნველყოფს გამოსახულების მენეჯმენტს და API-ს მათი მართვისთვის, Cinder უზრუნველყოფს ბლოკის შენახვას და API-ს მისი მართვისთვის და ა.შ. ყველა ფუნქცია ერთმანეთთან ძალიან მჭიდროდ არის დაკავშირებული.

თუმცა, თუ დააკვირდებით, OpenStack-ში გაშვებული ყველა სერვისი საბოლოოდ არის ერთგვარი ვირტუალური მანქანა (ან კონტეინერი), რომელიც დაკავშირებულია ქსელთან. ჩნდება კითხვა - რატომ გვჭირდება ამდენი ელემენტი?

მოდით გავიაროთ ვირტუალური მანქანის შექმნის ალგორითმი და ქსელთან დაკავშირება და მუდმივი შენახვა Openstack-ში.

1. როდესაც თქვენ ქმნით მოთხოვნას მანქანის შექმნის შესახებ, იქნება ეს მოთხოვნა Horizon-ის (Dashboard) მეშვეობით თუ მოთხოვნა CLI-ის მეშვეობით, პირველი რაც ხდება არის თქვენი მოთხოვნის ავტორიზაცია Keystone-ზე - შეგიძლიათ შექმნათ მანქანა, აქვს თუ არა მას ამ ქსელის გამოყენების უფლება, აკეთებს თქვენს კვოტას და ა.შ.
2. Keystone ახდენს თქვენი მოთხოვნის ავთენტიფიკაციას და აგენერირებს ავტორიზაციის ჟეტონს საპასუხო შეტყობინებაში, რომელიც შემდგომში იქნება გამოყენებული. კეისტოუნისგან პასუხის მიღების შემდეგ, მოთხოვნა იგზავნება ნოვას (nova api) მიმართ.
3. Nova-api ამოწმებს თქვენი მოთხოვნის მართებულობას Keystone-თან დაკავშირების გზით ადრე გენერირებული ავტორიზაციის ჟეტონის გამოყენებით
4. Keystone ახორციელებს ავთენტიფიკაციას და აწვდის ინფორმაციას ნებართვებისა და შეზღუდვების შესახებ ამ ავტორიზაციის ჟეტონზე დაყრდნობით.
5. Nova-api ქმნის ჩანაწერს ახალი VM-ისთვის nova-მონაცემთა ბაზაში და გადასცემს მანქანის შექმნის მოთხოვნას nova-scheduler-ს.
6. Nova-scheduler ირჩევს ჰოსტს (კომპიუტერულ კვანძს), რომელზეც განლაგდება VM მითითებული პარამეტრების, წონისა და ზონების მიხედვით. ამის ჩანაწერი და VM ID იწერება nova-database-ში.
7. შემდეგი, nova-scheduler დაუკავშირდება nova-compute-ს ინსტანციის განლაგების მოთხოვნით. Nova-compute აკავშირებს ნოვა-დირიჟორს მანქანის პარამეტრების შესახებ ინფორმაციის მისაღებად (nova-conductor არის nova ელემენტი, რომელიც მოქმედებს როგორც პროქსი სერვერი nova-database-სა და nova-compute-ს შორის, ზღუდავს მოთხოვნის რაოდენობას nova-database-ზე, რათა თავიდან აიცილოს პრობლემები მონაცემთა ბაზასთან. თანმიმდევრულობის დატვირთვის შემცირება).
8. Nova-დირიჟორი იღებს მოთხოვნილ ინფორმაციას nova-database-დან და გადასცემს მას nova-compute-ზე.
9. შემდეგი, nova-compute მოუწოდებს ერთი შეხედვით გამოსახულების ID-ს მისაღებად. Glace ამოწმებს მოთხოვნას Keystone-ში და აბრუნებს მოთხოვნილ ინფორმაციას.
10. Nova-გამოთვლა დაუკავშირებს ნეიტრონს, რათა მოიპოვოს ინფორმაცია ქსელის პარამეტრების შესახებ. როგორც ერთი შეხედვით, ნეიტრონი ამოწმებს მოთხოვნას Keystone-ში, რის შემდეგაც ის ქმნის ჩანაწერს მონაცემთა ბაზაში (პორტის იდენტიფიკატორი და ა.შ.), ქმნის მოთხოვნას პორტის შესაქმნელად და აბრუნებს მოთხოვნილ ინფორმაციას nova-compute-ში.
11. Nova-ის გამოთვლა ხდება კონტაქტების ციფრული მოთხოვნით ვირტუალურ მანქანაზე მოცულობის გამოყოფის მოთხოვნით. როგორც ერთი შეხედვით, სიდრი ამოწმებს მოთხოვნას Keystone-ში, ქმნის მოცულობის შექმნის მოთხოვნას და აბრუნებს მოთხოვნილ ინფორმაციას.
12. Nova-compute კონტაქტები libvirt ვირტუალური მანქანის განლაგების მოთხოვნით მითითებული პარამეტრებით.

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

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

Neutron, როგორც ქსელის სერვისი, უზრუნველყოფს API-ს ღრუბლოვანი ინფრასტრუქტურის ქსელური ნაწილის მართვისთვის. სერვისი აძლიერებს და მართავს Openstack-ის ქსელის ნაწილს აბსტრაქციის ფენის მიწოდებით, სახელწოდებით Network-as-a-Service (NaaS). ანუ, ქსელი არის იგივე ვირტუალური გაზომვადი ერთეული, როგორც, მაგალითად, ვირტუალური CPU ბირთვები ან ოპერატიული მეხსიერების რაოდენობა.

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

ასე რომ, ჩვენ გვაქვს ორი RED კლიენტის VM და ორი GREEN კლიენტის VM. დავუშვათ, რომ ეს მანქანები განლაგებულია ორ ჰიპერვიზორზე ამ გზით:

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

ღრუბლის შესაქმნელად საჭიროა რამდენიმე კომპონენტის დამატება. ჯერ ქსელის ნაწილის ვირტუალიზაციას ვაკეთებთ - ეს 4 მანქანა უნდა დავაკავშიროთ წყვილებში და კლიენტებს სურთ L2 კავშირი. შეგიძლიათ გამოიყენოთ გადამრთველი და დააკონფიგურიროთ საბარგული მისი მიმართულებით და მოაგვაროთ ყველაფერი ლინუქსის ხიდის ან უფრო მოწინავე მომხმარებლებისთვის openvswitch-ის გამოყენებით (ამას მოგვიანებით დავუბრუნდებით). მაგრამ შეიძლება ბევრი ქსელი იყოს და L2-ის გამუდმებით გადართვა გადამრთველის მეშვეობით არ არის საუკეთესო იდეა - არის სხვადასხვა განყოფილება, სერვისის მაგიდა, აპლიკაციის დასრულების თვეების ლოდინი, პრობლემების მოგვარების კვირები - თანამედროვე სამყაროში ეს მიდგომა აღარ მუშაობს. და რაც უფრო ადრე გაიგებს კომპანია ამას, მით უფრო ადვილია მისთვის წინსვლა. ამიტომ, ჰიპერვიზორებს შორის ჩვენ ავირჩევთ L3 ქსელს, რომლის მეშვეობითაც ჩვენი ვირტუალური მანქანები დაუკავშირდებიან და ამ L3 ქსელის თავზე ჩვენ ავაშენებთ ვირტუალურ L2 გადაფარვის ქსელებს, სადაც ჩვენი ვირტუალური მანქანების ტრაფიკი იმოძრავებს. თქვენ შეგიძლიათ გამოიყენოთ GRE, Geneve ან VxLAN, როგორც კაფსულაცია. ახლა ამ უკანასკნელზე გავამახვილოთ ყურადღება, თუმცა ეს არ არის განსაკუთრებით მნიშვნელოვანი.

ჩვენ სადმე უნდა მოვძებნოთ VTEP (იმედი მაქვს, ყველა იცნობს VxLAN ტერმინოლოგიას). ვინაიდან ჩვენ გვაქვს L3 ქსელი, რომელიც პირდაპირ სერვერებიდან მოდის, არაფერი გვიშლის ხელს VTEP-ის განთავსებაში თავად სერვერებზე და OVS (OpenvSwitch) შესანიშნავად აკეთებს ამას. შედეგად მივიღეთ ეს დიზაინი:

ვინაიდან ტრაფიკი VM-ებს შორის უნდა გაიყოს, ვირტუალური მანქანების პორტებს ექნებათ განსხვავებული vlan ნომრები. ტეგის ნომერი როლს ასრულებს მხოლოდ ერთ ვირტუალურ გადამრთველში, ვინაიდან VxLAN-ში ჩასმისას ადვილად შეგვიძლია მისი ამოღება, რადგან გვექნება VNI.

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

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

როგორც ჩანს, არაფერი რთული - ჩვენ ვქმნით ხიდის ინტერფეისს საკონტროლო კვანძზე, მივყავართ ტრაფიკს მისკენ და იქიდან მივმართავთ მას, სადაც გვჭირდება. მაგრამ პრობლემა ის არის, რომ RED კლიენტს სურს გამოიყენოს 10.0.0.0/24 ქსელი, ხოლო GREEN კლიენტს სურს გამოიყენოს 10.0.0.0/24 ქსელი. ანუ, ჩვენ ვიწყებთ მისამართების სივრცეების გადაკვეთას. გარდა ამისა, კლიენტებს არ სურთ, რომ სხვა კლიენტებმა შეძლონ მარშრუტირება მათ შიდა ქსელებში, რაც ლოგიკურია. ქსელებისა და კლიენტის მონაცემთა ტრაფიკის გამოსაყოფად, თითოეულ მათგანს გამოვყოფთ ცალკე სახელთა სივრცეს. სახელთა სივრცე ფაქტობრივად არის Linux ქსელის სტეკის ასლი, ანუ კლიენტები სახელთა სივრცეში RED მთლიანად იზოლირებულია კლიენტებისგან სახელთა სივრცისგან GREEN (აბა, ამ კლიენტთა ქსელებს შორის მარშრუტიზაცია დასაშვებია ნაგულისხმევი სახელების სივრცის მეშვეობით ან ზედა დინების სატრანსპორტო მოწყობილობებზე).

ანუ ვიღებთ შემდეგ დიაგრამას:

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

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

შედეგად მივიღეთ ეს დიაგრამა:

გონივრული კითხვაა, რატომ არ უნდა გააკეთოთ კარიბჭეები გამოთვლით კვანძებზე? ეს არ არის დიდი პრობლემა; უფრო მეტიც, თუ ჩართავთ განაწილებულ როუტერს (DVR), ეს იმუშავებს. ამ სცენარში განვიხილავთ უმარტივეს ვარიანტს ცენტრალიზებული კარიბჭით, რომელიც ნაგულისხმევად გამოიყენება Openstack-ში. მაღალი დატვირთვის ფუნქციებისთვის ისინი გამოიყენებენ როგორც განაწილებულ როუტერს, ასევე აჩქარების ტექნოლოგიებს, როგორიცაა SR-IOV და Passthrough, მაგრამ როგორც ამბობენ, ეს სრულიად განსხვავებული ამბავია. ჯერ ძირითად ნაწილს შევეხოთ, შემდეგ კი დეტალებს შევეხოთ.

სინამდვილეში, ჩვენი სქემა უკვე მუშაობს, მაგრამ არსებობს რამდენიმე ნიუანსი:

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

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

ანუ, ახლა ჩვენი ტოპოლოგია ცოტა უფრო გართულდა:

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

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

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

და აქ NAT გვეხმარება - ჩვენ უბრალოდ შევძლებთ კლიენტებს წვდომას გარე სამყაროზე ნაგულისხმევი სახელების სივრცის მეშვეობით NAT თარგმანის გამოყენებით. აბა, აქ არის პატარა პრობლემა. ეს კარგია, თუ კლიენტის სერვერი მოქმედებს როგორც კლიენტი და არა როგორც სერვერი - ანუ ის იწყებს კავშირებს, ვიდრე იღებს. მაგრამ ჩვენთვის პირიქით იქნება. ამ შემთხვევაში, ჩვენ უნდა გავაკეთოთ დანიშნულების NAT ისე, რომ ტრაფიკის მიღებისას, საკონტროლო კვანძმა გაიგოს, რომ ეს ტრაფიკი განკუთვნილია A კლიენტის ვირტუალური მანქანისთვის, რაც ნიშნავს, რომ ჩვენ უნდა გავაკეთოთ NAT თარგმანი გარე მისამართიდან, მაგალითად 100.1.1.1. .10.0.0.1, შიდა მისამართზე 100. ამ შემთხვევაში, მიუხედავად იმისა, რომ ყველა კლიენტი გამოიყენებს ერთსა და იმავე ქსელს, შიდა იზოლაცია მთლიანად დაცულია. ანუ საკონტროლო კვანძზე უნდა გავაკეთოთ dNAT და sNAT. ერთი ქსელის გამოყენება მცურავი მისამართებით ან გარე ქსელებით, ან ორივე ერთდროულად, დამოკიდებულია იმაზე, თუ რისი შეტანა გსურთ ღრუბელში. ჩვენ არ დავამატებთ დიაგრამას მცურავ მისამართებს, მაგრამ დავტოვებთ ადრე დამატებულ გარე ქსელებს - თითოეულ კლიენტს აქვს საკუთარი გარე ქსელი (დიაგრამაში ისინი მითითებულია როგორც vlan 200 და XNUMX გარე ინტერფეისზე).

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

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

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

შემდეგი პრობლემა არის ვირტუალური მანქანების დისკები. ამ დროისთვის, ისინი ინახება თავად ჰიპერვიზორებზე და ჰიპერვიზორთან პრობლემების შემთხვევაში, ჩვენ ვკარგავთ ყველა მონაცემს - და რეიდის არსებობა აქ არ დაგვეხმარება, თუ დავკარგავთ არა დისკს, არამედ მთელ სერვერს. ამისათვის ჩვენ უნდა შევქმნათ სერვისი, რომელიც იმოქმედებს როგორც წინა ნაწილი გარკვეული სახის შენახვისთვის. რა სახის საცავი იქნება ეს ჩვენთვის არ არის განსაკუთრებით მნიშვნელოვანი, მაგრამ მან უნდა დაიცვას ჩვენი მონაცემები როგორც დისკის, ისე კვანძის და, შესაძლოა, მთელი კაბინეტის წარუმატებლობისგან. აქ რამდენიმე ვარიანტია - რა თქმა უნდა, არის SAN ქსელები Fiber Channel-ით, მაგრამ მოდი ვიყოთ გულწრფელი - FC უკვე წარსულის რელიქვიაა - E1-ის ანალოგი ტრანსპორტში - დიახ, ვეთანხმები, ის ჯერ კიდევ გამოიყენება, მაგრამ მხოლოდ იქ, სადაც ამის გარეშე აბსოლუტურად შეუძლებელია. ამიტომ, მე არ განვათავსებ ნებაყოფლობით FC ქსელს 2020 წელს, რადგან ვიცი, რომ არსებობს სხვა უფრო საინტერესო ალტერნატივები. მიუხედავად იმისა, რომ თითოეულს საკუთარი, შეიძლება იყვნენ ისეთებიც, ვისაც სჯერა, რომ FC მთელი თავისი შეზღუდვით არის ის, რაც ჩვენ გვჭირდება - არ ვიკამათებ, ყველას აქვს საკუთარი აზრი. თუმცა, ყველაზე საინტერესო გამოსავალი ჩემი აზრით არის SDS-ის გამოყენება, როგორიცაა Ceph.

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

Ceph-ის ასაშენებლად გჭირდებათ კიდევ 3 კვანძი. საცავთან ურთიერთქმედება ასევე განხორციელდება ქსელის მეშვეობით ბლოკის, ობიექტების და ფაილების შენახვის სერვისების გამოყენებით. მოდით დავამატოთ საცავი სქემას:

შენიშვნა: თქვენ ასევე შეგიძლიათ შექმნათ ჰიპერკონვერგირებული გამოთვლითი კვანძები - ეს არის რამდენიმე ფუნქციის ერთ კვანძზე გაერთიანების კონცეფცია - მაგალითად, შენახვის+გამოთვლა - სპეციალური კვანძების გამოყოფის გარეშე ceph შენახვისთვის. ჩვენ მივიღებთ იგივე ხარვეზების ტოლერანტულ სქემას - ვინაიდან SDS ინახავს მონაცემებს დაჯავშნის დონით, რომელსაც ჩვენ დავაზუსტებთ. ამასთან, ჰიპერკონვერგირებული კვანძები ყოველთვის კომპრომისია - რადგან შენახვის კვანძი არ ათბობს ჰაერს, როგორც ეს ერთი შეხედვით ჩანს (რადგან მასზე ვირტუალური მანქანები არ არის) - ის ხარჯავს CPU რესურსებს SDS-ის მომსახურებაზე (სინამდვილეში, ის აკეთებს ყველაფერს. რეპლიკაცია და აღდგენა კვანძების, დისკების და ა.შ. წარუმატებლობის შემდეგ). ანუ გამოთვლითი კვანძის სიმძლავრის ნაწილს დაკარგავთ, თუ მას საცავთან დააკავშირებთ.

ამ ყველაფრის როგორმე მართვაა საჭირო - ჩვენ გვჭირდება რაღაც, რომლის მეშვეობითაც შევძლებთ შევქმნათ მანქანა, ქსელი, ვირტუალური როუტერი და ა.შ. ამისათვის ჩვენ დავამატებთ სერვისს საკონტროლო კვანძში, რომელიც იმოქმედებს როგორც დაფა - კლიენტი შეძლებს ამ პორტალთან დაკავშირებას http/ https-ის საშუალებით და გააკეთოს ყველაფერი, რაც მას სჭირდება (კარგად, თითქმის).

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

ნეიტრონული არქიტექტურა

OpenStack-ში სწორედ ნეიტრონი არის პასუხისმგებელი ვირტუალური მანქანების პორტების საერთო L2 ქსელთან დაკავშირებაზე, უზრუნველყოფს ტრაფიკის მარშრუტიზაციას VM-ებს შორის, რომლებიც განლაგებულია სხვადასხვა L2 ქსელებში, ასევე გარე მარშრუტიზაციაზე, რომელიც უზრუნველყოფს სერვისებს, როგორიცაა NAT, Floating IP, DHCP და ა.შ.

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

VM-ის გაშვებისას, ქსელის სერვისი:

1. ქმნის პორტს მოცემული VM-ისთვის (ან პორტებისთვის) და ამის შესახებ აცნობებს DHCP სერვისს;
2. იქმნება ახალი ვირტუალური ქსელის მოწყობილობა (libvirt-ის საშუალებით);
3. VM აკავშირებს პორტ(ებ)ს, რომელიც შექმნილ საფეხურზე 1;

უცნაურად საკმარისია, რომ ნეიტრონის მუშაობა ეფუძნება სტანდარტულ მექანიზმებს, რომლებიც ცნობილია ყველასთვის, ვინც ოდესმე ჩაყვინთა Linux-ში - სახელთა სივრცეები, iptables, linux ხიდები, openvswitch, conntrack და ა.შ.

დაუყოვნებლივ უნდა განვმარტოთ, რომ ნეიტრონი არ არის SDN კონტროლერი.

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

Openstack-ნეიტრონული სერვერი არის დემონი, რომელიც მუშაობს მომხმარებლის მოთხოვნებთან API-ის საშუალებით. ეს დემონი არ მონაწილეობს რაიმე ქსელური კავშირების რეგისტრაციაში, მაგრამ ამისთვის საჭირო ინფორმაციას აწვდის თავის დანამატებს, რომლებიც შემდეგ აკონფიგურირებენ სასურველი ქსელის ელემენტს. ნეიტრონის აგენტები OpenStack კვანძებზე რეგისტრირდება ნეიტრონის სერვერზე.

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

• დასვენების სერვისი
• ნეიტრონული დანამატი (ბირთი/სერვისი)

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

Plugins არის დანამატი პროგრამული კომპონენტები/მოდულები, რომლებიც გამოიძახება API მოთხოვნის დროს - ანუ სერვისის მიკუთვნება ხდება მათი მეშვეობით. დანამატები იყოფა ორ ტიპად - სერვისი და root. როგორც წესი, ცხენის დანამატი ძირითადად პასუხისმგებელია მისამართების სივრცისა და L2 კავშირების მართვაზე VM-ებს შორის, ხოლო სერვისის დანამატები უკვე უზრუნველყოფენ დამატებით ფუნქციებს, როგორიცაა VPN ან FW.

მაგალითად, დღეს ხელმისაწვდომი დანამატების სია შეგიძლიათ ნახოთ აქ

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

openstack-neutron-ml2 არის სტანდარტული Openstack root მოდული. ამ დანამატს აქვს მოდულარული არქიტექტურა (განსხვავებით მისი წინამორბედისგან) და აკონფიგურირებს ქსელის სერვისს მასთან დაკავშირებული დრაივერების საშუალებით. ჩვენ შევხედავთ თავად დანამატს ცოტა მოგვიანებით, რადგან სინამდვილეში ის იძლევა მოქნილობას, რაც OpenStack-ს აქვს ქსელის ნაწილში. root მოდული შეიძლება შეიცვალოს (მაგალითად, Contrail Networking აკეთებს ასეთ ჩანაცვლებას).

RPC სერვისი (rabbitmq-სერვერი) — სერვისი, რომელიც უზრუნველყოფს რიგის მენეჯმენტს და სხვა OpenStack სერვისებთან ურთიერთქმედებას, ასევე ქსელის სერვისის აგენტებს შორის ურთიერთქმედებას.

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

არსებობს რამდენიმე სახის აგენტი.

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

შემდეგი, არანაკლებ მნიშვნელოვანი აგენტია L3 აგენტი. ნაგულისხმევად, ეს აგენტი მუშაობს ექსკლუზიურად ქსელის კვანძზე (ხშირად ქსელის კვანძი შერწყმულია საკონტროლო კვანძთან) და უზრუნველყოფს მარშრუტიზაციას მოიჯარის ქსელებს შორის (როგორც მის ქსელებს, ისე სხვა მოიჯარეების ქსელებს შორის და ხელმისაწვდომია გარე სამყაროსთვის, რაც უზრუნველყოფს NAT, ისევე როგორც DHCP სერვისი). თუმცა, DVR-ის (განაწილებული როუტერის) გამოყენებისას L3 მოდულის საჭიროება გამოთვლით კვანძებზეც ჩნდება.

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

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

სინამდვილეში, ნეიტრონი იღებს API მოთხოვნებს ნებისმიერი ქსელის ერთეულების შექმნიდან, ახდენს მოთხოვნის ავთენტიფიკაციას და RPC-ის (თუ ის წვდება რომელიმე დანამატს ან აგენტს) ან REST API-ს (თუ ის SDN-ში კომუნიკაციას უწევს) გადასცემს აგენტებს (დამატებების საშუალებით) მოთხოვნილი სერვისის ორგანიზებისთვის საჭირო ინსტრუქციები.

ახლა მოდით მივმართოთ სატესტო ინსტალაციას (როგორ არის განლაგებული და რა შედის მასში, მოგვიანებით ვნახავთ პრაქტიკულ ნაწილში) და ვნახოთ, სად მდებარეობს თითოეული კომპონენტი:

(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 

სინამდვილეში, ეს არის ნეიტრონის მთელი სტრუქტურა. ახლა ღირს გარკვეული დროის დახარჯვა ML2 მოდულზე.

მოდულური ფენა 2

როგორც ზემოთ აღინიშნა, მოდული არის სტანდარტული OpenStack root მოდული და აქვს მოდულური არქიტექტურა.

ML2 მოდულის წინამორბედს ჰქონდა მონოლითური სტრუქტურა, რომელიც არ იძლეოდა, მაგალითად, რამდენიმე ტექნოლოგიის ერთ ინსტალაციაში გამოყენებას. მაგალითად, თქვენ არ შეგეძლოთ ერთდროულად გამოიყენოთ openvswitch და linuxbridge - არც პირველი და არც მეორე. ამ მიზეზით შეიქმნა ML2 მოდული თავისი არქიტექტურით.

ML2-ს აქვს ორი კომპონენტი - ორი ტიპის დრაივერები: Type Drivers და Mechanism Drivers.

აკრიფეთ დრაივერები განსაზღვრეთ ტექნოლოგიები, რომლებიც გამოყენებული იქნება ქსელური კავშირების ორგანიზებისთვის, მაგალითად VxLAN, VLAN, GRE. ამავდროულად, მძღოლი სხვადასხვა ტექნოლოგიების გამოყენების საშუალებას იძლევა. სტანდარტული ტექნოლოგია არის VxLAN encapsulation გადაფარვის ქსელებისთვის და vlan გარე ქსელებისთვის.

ტიპის დრაივერები მოიცავს ქსელის შემდეგ ტიპებს:

ბინა - ქსელი მონიშვნის გარეშე
VLAN - მონიშნული ქსელი
ლოკალური - სპეციალური ტიპის ქსელი ყოვლისმომცველი ინსტალაციისთვის (ასეთი ინსტალაციები საჭიროა დეველოპერებისთვის ან ტრენინგისთვის)
GRE — გადაფარვის ქსელი GRE გვირაბების გამოყენებით
VxLAN — გადაფარეთ ქსელი VxLAN გვირაბების გამოყენებით

მექანიზმის დრაივერები განსაზღვრეთ ინსტრუმენტები, რომლებიც უზრუნველყოფენ დრაივერში მითითებული ტექნოლოგიების ორგანიზებას - მაგალითად, openvswitch, sr-iov, opendaylight, OVN და ა.შ.

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

მაგალითი: თუ გამოვიყენებთ ML2-ს OVS-თან ერთად, მაშინ თითოეულ გამოთვლით კვანძზე დამონტაჟებულია L2 აგენტი, რომელიც მართავს OVS-ს. თუმცა, თუ ვიყენებთ, მაგალითად, OVN-ს ან OpenDayLight-ს, მაშინ OVS-ის კონტროლი შედის მათ იურისდიქციაში - ნეიტრონი, root მოდულის მეშვეობით, აძლევს ბრძანებებს კონტროლერს და ის უკვე აკეთებს იმას, რაც იყო ნათქვამი.

მოდით დავამარცხოთ Open vSwitch-ზე

ამ დროისთვის, OpenStack-ის ერთ-ერთი მთავარი კომპონენტია Open vSwitch.
OpenStack-ის ინსტალაციისას დამატებითი გამყიდველის SDN-ის გარეშე, როგორიცაა Juniper Contrail ან Nokia Nuage, OVS არის ღრუბლოვანი ქსელის მთავარი ქსელის კომპონენტი და iptables-თან, conntrack-თან, სახელთა სივრცეებთან ერთად, საშუალებას გაძლევთ მოაწყოთ სრულფასოვანი მრავალბინიანი გადაფარვის ქსელები. ბუნებრივია, ეს კომპონენტი შეიძლება შეიცვალოს, მაგალითად, მესამე მხარის საკუთრების (მიმწოდებლის) SDN გადაწყვეტილებების გამოყენებისას.

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

ამ დროისთვის, OVS-ს აქვს ძალიან ღირსეული ფუნქციონირება, რომელიც მოიცავს ისეთ ტექნოლოგიებს, როგორიცაა QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK და ა.შ.

შენიშვნა: OVS თავდაპირველად არ იყო ჩაფიქრებული, როგორც რბილი გადამრთველი მაღალი დატვირთული ტელეკომის ფუნქციებისთვის და უფრო მეტად იყო შექმნილი IT ფუნქციებისთვის, როგორიცაა WEB სერვერი ან ფოსტის სერვერი. თუმცა, OVS შემდგომში ვითარდება და OVS-ის ამჟამინდელმა განხორციელებებმა მნიშვნელოვნად გააუმჯობესა მისი შესრულება და შესაძლებლობები, რაც საშუალებას აძლევს მას გამოიყენონ სატელეკომუნიკაციო ოპერატორები მაღალი დატვირთული ფუნქციებით, მაგალითად, არსებობს OVS დანერგვა DPDK აჩქარების მხარდაჭერით.

OVS-ის სამი მნიშვნელოვანი კომპონენტია, რომელთა შესახებაც უნდა იცოდეთ:

• ბირთვის მოდული — ბირთვის სივრცეში მდებარე კომპონენტი, რომელიც ამუშავებს ტრაფიკს საკონტროლო ელემენტიდან მიღებული წესების საფუძველზე;
• v გადართვა დემონი (ovs-vswitchd) არის მომხმარებლის სივრცეში გაშვებული პროცესი, რომელიც პასუხისმგებელია ბირთვის მოდულის პროგრამირებაზე - ანუ ის პირდაპირ წარმოადგენს გადამრთველის მუშაობის ლოგიკას.
• მონაცემთა ბაზის სერვერი - ადგილობრივი მონაცემთა ბაზა, რომელიც მდებარეობს თითოეულ ჰოსტზე, რომელიც მუშაობს OVS, რომელშიც ინახება კონფიგურაცია. SDN კონტროლერებს შეუძლიათ კომუნიკაცია ამ მოდულის მეშვეობით OVSDB პროტოკოლის გამოყენებით.

ამ ყველაფერს თან ახლავს სადიაგნოსტიკო და მართვის საშუალებების ნაკრები, როგორიცაა ovs-vsctl, ovs-appctl, ovs-ofctl და ა.შ.

ამჟამად Openstack ფართოდ გამოიყენება ტელეკომის ოპერატორების მიერ მასში ქსელის ფუნქციების გადასატანად, როგორიცაა EPC, SBC, HLR და ა.შ. ზოგიერთ ფუნქციას შეუძლია უპრობლემოდ იცხოვროს OVS-თან, როგორც არის, მაგრამ მაგალითად, EPC ამუშავებს აბონენტთა ტრაფიკს - შემდეგ ის გადის ტრაფიკის უზარმაზარი რაოდენობა (ახლა ტრაფიკის მოცულობა წამში რამდენიმე ასეულ გიგაბიტს აღწევს). ბუნებრივია, ასეთი ტრაფიკის მართვა ბირთვის სივრცეში (რადგან გადამგზავნი ნაგულისხმევად არის განთავსებული) არ არის საუკეთესო იდეა. ამიტომ, OVS ხშირად განლაგებულია მთლიანად მომხმარებლის სივრცეში DPDK აჩქარების ტექნოლოგიის გამოყენებით NIC-დან მომხმარებლის სივრცეში ტრაფიკის გადასატანად ბირთვის გვერდის ავლით.

შენიშვნა: სატელეკომუნიკაციო ფუნქციებისთვის განლაგებული ღრუბლისთვის, შესაძლებელია ტრაფიკის გამოტანა გამოთვლითი კვანძიდან OVS-ის გვერდის ავლით პირდაპირ გადართვის მოწყობილობაზე. ამ მიზნით გამოიყენება SR-IOV და Passthrough მექანიზმები.

როგორ მუშაობს ეს რეალურ განლაგებაზე?

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

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

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

მაშ ასე, დავიწყოთ თანმიმდევრობით. პირველი, პატარა თეორია. ჩვენ დავაინსტალირებთ Openstack-ს TripleO-ის გამოყენებით (Openstack Openstack-ზე). TripleO-ს არსი იმაში მდგომარეობს, რომ ჩვენ ვაინსტალირებთ Openstack all-in-one (ანუ ერთ კვანძზე), რომელსაც ეწოდება undercloud, და შემდეგ ვიყენებთ განლაგებული Openstack-ის შესაძლებლობებს ოპერაციისთვის განკუთვნილი Openstack-ის დასაყენებლად, რომელსაც ეწოდება overcloud. Undercloud გამოიყენებს თავის თანდაყოლილ შესაძლებლობას მართოს ფიზიკური სერვერები (შიშველი ლითონი) - Ironic პროექტი - უზრუნველყოს ჰიპერვიზორები, რომლებიც შეასრულებენ გამოთვლის, კონტროლის, შენახვის კვანძების როლებს. ანუ, ჩვენ არ ვიყენებთ მესამე მხარის ინსტრუმენტებს Openstack-ის განსათავსებლად - ჩვენ ვაყენებთ Openstack-ს Openstack-ის გამოყენებით. ეს ბევრად უფრო ნათელი გახდება ინსტალაციის პროგრესირებასთან ერთად, ამიტომ ჩვენ არ გავჩერდებით და წინ წავალთ.

შენიშვნა: ამ სტატიაში, სიმარტივისთვის, მე არ გამომიყენებია ქსელის იზოლაცია შიდა Openstack ქსელებისთვის, მაგრამ ყველაფერი განლაგებულია მხოლოდ ერთი ქსელის გამოყენებით. ამასთან, ქსელის იზოლაციის არსებობა ან არარსებობა გავლენას არ ახდენს გადაწყვეტის ძირითად ფუნქციონირებაზე - ყველაფერი იმუშავებს ზუსტად ისე, როგორც იზოლაციის გამოყენებისას, მაგრამ ტრაფიკი მიედინება იმავე ქსელში. კომერციული ინსტალაციისთვის, ბუნებრივია, აუცილებელია იზოლაციის გამოყენება სხვადასხვა ვლანებისა და ინტერფეისების გამოყენებით. მაგალითად, ceph შენახვის მენეჯმენტის ტრაფიკი და თავად მონაცემთა ტრაფიკი (მანქანის წვდომა დისკებზე და ა.შ.), როდესაც იზოლირებულია, იყენებს სხვადასხვა ქვექსელებს (Storage Management და Storage) და ეს საშუალებას გაძლევთ გახადოთ გამოსავალი უფრო შეცდომის მიმართ ამ ტრაფიკის გაყოფით, მაგალითად. , სხვადასხვა პორტებში, ან სხვადასხვა QoS პროფილების გამოყენება სხვადასხვა ტრაფიკისთვის, რათა მონაცემთა ტრაფიკმა არ შეაფერხოს სასიგნალო ტრაფიკი. ჩვენს შემთხვევაში, ისინი იმავე ქსელზე გადავლენ და რეალურად ეს არანაირად არ გვზღუდავს.

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

თქვენ შეგიძლიათ შეამოწმოთ ჩართულია თუ არა ჩადგმული ვირტუალიზაცია ასე:

[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested
N
[root@hp-gen9 bormoglotx]# 

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

ჩვენ უნდა შევკრიბოთ შემდეგი წრე ვირტუალური მანქანებიდან:

ჩემს შემთხვევაში, ვირტუალური მანქანების დასაკავშირებლად, რომლებიც მომავალი ინსტალაციის ნაწილია (და მე მივიღე 7 მათგანი, მაგრამ თქვენ შეგიძლიათ გაუმკლავდეთ 4-ით, თუ ბევრი რესურსი არ გაქვთ), გამოვიყენე OpenvSwitch. შევქმენი ერთი ovs bridge და დავუკავშირე ვირტუალური მანქანები მას პორტ-ჯგუფების მეშვეობით. ამისათვის მე შევქმენი xml ფაილი ასეთი:

[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1        
<network>
  <name>ovs-network-1</name>
  <uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
  <forward mode='bridge'/>
  <bridge name='ovs-br1'/>
  <virtualport type='openvswitch'/>
  <portgroup name='trunk-1'>
    <vlan trunk='yes'>
      <tag id='100'/>
      <tag id='101'/>
      <tag id='102'/>
    </vlan>
  </portgroup>
  <portgroup name='access-100'>
    <vlan>
      <tag id='100'/>
    </vlan>
  </portgroup>
  <portgroup name='access-101'>
    <vlan>
      <tag id='101'/>
    </vlan>
  </portgroup>
</network>

აქ გამოცხადებულია სამი პორტის ჯგუფი - ორი წვდომა და ერთი სატვირთო (ეს უკანასკნელი საჭირო იყო DNS სერვერისთვის, მაგრამ შეგიძლიათ ამის გარეშე გააკეთოთ, ან დააინსტალიროთ იგი მასპინძელ მანქანაზე - რაც უფრო მოსახერხებელია თქვენთვის). შემდეგი, ამ შაბლონის გამოყენებით, ჩვენ ვაცხადებთ ჩვენსას virsh net-define-ის მეშვეობით:

virsh net-define ovs-network-1.xml 
virsh net-start ovs-network-1 
virsh net-autostart ovs-network-1 

ახლა ჩვენ ვასწორებთ ჰიპერვიზორის პორტის კონფიგურაციას:

[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0   
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1 
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# 

შენიშვნა: ამ სცენარში, პორტის მისამართი ovs-br1 არ იქნება ხელმისაწვდომი, რადგან მას არ აქვს vlan ტეგი. ამის გამოსასწორებლად, თქვენ უნდა გამოსცეთ ბრძანება sudo ovs-vsctl set port ovs-br1 tag=100. თუმცა, გადატვირთვის შემდეგ, ეს ტეგი გაქრება (თუ ვინმემ იცის როგორ დარჩეს იგი ადგილზე, დიდი მადლობელი ვიქნები). მაგრამ ეს არც ისე მნიშვნელოვანია, რადგან ეს მისამართი დაგვჭირდება მხოლოდ ინსტალაციის დროს და არ დაგვჭირდება, როდესაც Openstack სრულად იქნება განლაგებული.

შემდეგი, ჩვენ ვქმნით მიწისქვეშა მანქანას:

virt-install  -n undercloud --description "undercloud"  --os-type=Linux  --os-variant=centos7.0  --ram=8192  --vcpus=8  --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none  --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0

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

წარმატებული ინსტალაციის შემდეგ, თქვენ უნდა გქონდეთ ვირტუალური მანქანა, რომელზეც შეგიძლიათ დააინსტალიროთ undercloud

[root@hp-gen9 bormoglotx]# virsh list
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 62    undercloud                     running

პირველ რიგში, დააინსტალირეთ ინსტალაციის პროცესისთვის საჭირო ხელსაწყოები:

sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool

ღრუბლოვანი ინსტალაცია

ჩვენ ვქმნით სტეკის მომხმარებელს, ვაყენებთ პაროლს, ვამატებთ მას sudoer-ში და ვაძლევთ მას შესაძლებლობას შეასრულოს root ბრძანებები sudo-ს მეშვეობით პაროლის შეყვანის გარეშე:

useradd stack
passwd stack

echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack

ახლა ჩვენ მივუთითებთ სრულ undercloud სახელს მასპინძლების ფაილში:

vi /etc/hosts

127.0.0.1   undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

შემდეგი, ჩვენ ვამატებთ საცავებს და ვაინსტალირებთ საჭირო პროგრამულ უზრუნველყოფას:

sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansible

შენიშვნა: თუ არ გეგმავთ ceph-ის დაყენებას, მაშინ არ გჭირდებათ ceph-თან დაკავშირებული ბრძანებების შეყვანა. მე გამოვიყენე Queens-ის გამოშვება, მაგრამ თქვენ შეგიძლიათ გამოიყენოთ ნებისმიერი სხვა, რომელიც მოგწონთ.

შემდეგი, დააკოპირეთ undercloud კონფიგურაციის ფაილი მომხმარებლის სახლის დირექტორიაში:

cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf

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

თქვენ უნდა დაამატოთ ეს ხაზები ფაილის დასაწყისში:

vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10

ასე რომ, მოდით გადავიდეთ პარამეტრებში:

undercloud_hostname — Undercloud სერვერის სრული სახელი, უნდა ემთხვეოდეს ჩანაწერს DNS სერვერზე

local_ip — ლოკალური მიწისქვეშა მისამართი ქსელის უზრუნველყოფის მიმართ

ქსელის_კარიბჭე — იგივე ლოკალური მისამართი, რომელიც იმოქმედებს როგორც კარიბჭე გარე სამყაროზე წვდომისთვის overcloud კვანძების დაყენებისას, ასევე ემთხვევა ლოკალურ IP-ს.

undercloud_public_host — გარე API მისამართი, მინიჭებულია ნებისმიერი უფასო მისამართი მიმწოდებელი ქსელიდან

undercloud_admin_host შიდა API მისამართი, მინიჭებულია ნებისმიერი უფასო მისამართი მიმწოდებელი ქსელიდან

undercloud_name სერვერები - DNS სერვერი

გენერირება_სერვისის_სერთიფიკატი - ეს ხაზი ძალიან მნიშვნელოვანია მიმდინარე მაგალითში, რადგან თუ არ დააყენეთ ის false-ზე, მიიღებთ შეცდომას ინსტალაციის დროს, პრობლემა აღწერილია Red Hat-ის შეცდომების ტრეკერზე.

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

local_mtu - MTU. ვინაიდან ჩვენ გვაქვს სატესტო ლაბორატორია და მე მაქვს MTU 1500 OVS გადამრთველ პორტებზე, აუცილებელია მისი დაყენება 1450-ზე, რათა VxLAN-ში ჩასმული პაკეტები გაიარონ.

network_cidr - უზრუნველყოფის ქსელი

მასკარადი - NAT-ის გამოყენება გარე ქსელში წვდომისთვის

მასკარადის_ქსელი - ქსელი, რომელიც იქნება NATed

dhcp_start — მისამართების აუზის საწყისი მისამართი, საიდანაც მისამართები მიენიჭება კვანძებს ღრუბლის განლაგების დროს

dhcp_end — მისამართების აუზის საბოლოო მისამართი, საიდანაც მისამართები მიენიჭება კვანძებს ღრუბლის განლაგების დროს

ინსპექცია_iprange - ინტროსპექციისთვის საჭირო მისამართების კრებული (არ უნდა ემთხვეოდეს ზემოთ მოცემულ აუზს)

scheduler_max_ttempts — Overcloud-ის დაყენების მცდელობების მაქსიმალური რაოდენობა (უნდა იყოს მეტი ან ტოლი კვანძების რაოდენობაზე)

ფაილის აღწერის შემდეგ, შეგიძლიათ მისცეთ ბრძანება Undercloud-ის განლაგების შესახებ:

openstack undercloud install

პროცედურა გრძელდება 10-დან 30 წუთამდე, თქვენი რკინის მიხედვით. საბოლოო ჯამში, თქვენ უნდა ნახოთ გამომავალი ასეთი:

vi undercloud.conf
2020-08-13 23:13:12,668 INFO: 
#############################################################################
Undercloud install complete.

The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.

There is also a stackrc file at /home/stack/stackrc.

These files are needed to interact with the OpenStack services, and should be
secured.

#############################################################################

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

თუ გადავხედავთ ifconfig გამოსავალს, ნახავთ, რომ გამოჩნდა ახალი ხიდის ინტერფეისი

[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.1  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe2c:89e  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:2c:08:9e  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 1095 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 1292 (1.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Overcloud განლაგება ახლა განხორციელდება ამ ინტერფეისის მეშვეობით.

ქვემოთ მოცემული გამოსვლიდან ხედავთ, რომ ჩვენ გვაქვს ყველა სერვისი ერთ კვანძზე:

(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name                | Service   | Zone     |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute   | nova     |
+--------------------------+-----------+----------+

ქვემოთ მოცემულია ღრუბლოვანი ქსელის ნაწილის კონფიგურაცია:

(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json 
{
    "network_config": [
        {
            "addresses": [
                {
                    "ip_netmask": "192.168.255.1/24"
                }
            ],
            "members": [
                {
                    "dns_servers": [
                        "192.168.255.253"
                    ],
                    "mtu": 1450,
                    "name": "eth0",
                    "primary": "true",
                    "type": "interface"
                }
            ],
            "mtu": 1450,
            "name": "br-ctlplane",
            "ovs_extra": [
                "br-set-external-id br-ctlplane bridge-id br-ctlplane"
            ],
            "routes": [],
            "type": "ovs_bridge"
        }
    ]
}
(undercloud) [stack@undercloud ~]$

Overcloud ინსტალაცია

ამ დროისთვის ჩვენ გვაქვს მხოლოდ undercloud და არ გვაქვს საკმარისი კვანძები, საიდანაც შეიკრიბება overcloud. ამიტომ, უპირველეს ყოვლისა, მოდით განვათავსოთ ჩვენთვის საჭირო ვირტუალური მანქანები. განლაგების დროს, undercloud თავად დააინსტალირებს OS-ს და აუცილებელ პროგრამულ უზრუნველყოფას Overcloud მანქანაზე - ანუ, ჩვენ არ გვჭირდება აპარატის სრულად განლაგება, არამედ მხოლოდ მისთვის დისკის (ან დისკების) შექმნა და მისი პარამეტრების დადგენა - ეს არის ფაქტობრივად, ჩვენ ვიღებთ შიშველ სერვერს მასზე დაინსტალირებული OS-ის გარეშე.

მოდით გადავიდეთ საქაღალდეში ჩვენი ვირტუალური მანქანების დისკებით და შევქმნათ საჭირო ზომის დისკები:

cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160G

ვინაიდან ჩვენ ვმუშაობთ როგორც root, ჩვენ უნდა შევცვალოთ ამ დისკების მფლობელი, რათა არ შეგვექმნას პრობლემა უფლებებთან დაკავშირებით:

[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]# 
[root@hp-gen9 images]# 
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# 

შენიშვნა: თუ არ აპირებთ ceph-ის დაყენებას მის შესასწავლად, მაშინ ბრძანებები არ ქმნიან მინიმუმ 3 კვანძს მინიმუმ ორი დისკით, არამედ შაბლონში მიუთითებენ, რომ გამოყენებული იქნება ვირტუალური დისკები vda, vdb და ა.შ.

კარგია, ახლა ჩვენ უნდა განვსაზღვროთ ყველა ეს მანქანა:

virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml  

virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml  

virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml  

virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml  

virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml 

დასასრულს არის ბრძანება -print-xml > /tmp/storage-1.xml, რომელიც ქმნის xml ფაილს თითოეული მანქანის აღწერით საქაღალდეში /tmp/; თუ არ დაამატებთ, არ იქნებით. შეუძლია ვირტუალური მანქანების იდენტიფიცირება.

ახლა ჩვენ უნდა განვსაზღვროთ ყველა ეს მანქანა virsh-ში:

virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

ახლა მცირე ნიუანსია - tripleO იყენებს IPMI სერვერების სამართავად ინსტალაციისა და ინტროსპექციის დროს.

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

მაგრამ აქ არის პრობლემა - სანამ IPMI სერვერებს აქვთ ცალკე პორტი (ან საერთო პორტი, მაგრამ ეს არ არის მნიშვნელოვანი), მაშინ ვირტუალურ მანქანებს არ აქვთ ასეთი პორტები. აქ ყავარჯენი სახელად vbmc გვეხმარება - პროგრამა, რომელიც საშუალებას გაძლევთ მიბაძოთ IPMI პორტს. ამ ნიუანსზე განსაკუთრებით ღირს ყურადღების მიქცევა მათთვის, ვისაც სურს ESXI ჰიპერვიზორზე ასეთი ლაბორატორიის დაყენება - სიმართლე გითხრათ, არ ვიცი აქვს თუ არა მას vbmc-ის ანალოგი, ამიტომ ღირს ამ საკითხის დაფიქრება, სანამ ყველაფერს დააყენებთ. .

დააინსტალირეთ vbmc:

yum install yum install python2-virtualbmc

თუ თქვენი OS ვერ პოულობს პაკეტს, დაამატეთ საცავი:

yum install -y https://www.rdoproject.org/repos/rdo-release.rpm

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

[root@hp-gen9 ~]# vbmc list

[root@hp-gen9 ~]# 

იმისათვის, რომ ისინი გამოჩნდნენ, ისინი ხელით უნდა გამოცხადდეს ასე:

[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1   | down   | ::      | 7004 |
| compute-2   | down   | ::      | 7005 |
| control-1   | down   | ::      | 7001 |
| storage-1   | down   | ::      | 7002 |
| storage-2   | down   | ::      | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#

ვფიქრობ, ბრძანების სინტაქსი ნათელია ახსნის გარეშე. თუმცა, ამჟამად ყველა ჩვენი სესია DOWN სტატუსშია. იმისათვის, რომ ისინი გადავიდნენ UP სტატუსზე, თქვენ უნდა ჩართოთ ისინი:

[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1 
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status  | Address | Port |
+-------------+---------+---------+------+
| compute-1   | running | ::      | 7004 |
| compute-2   | running | ::      | 7005 |
| control-1   | running | ::      | 7001 |
| storage-1   | running | ::      | 7002 |
| storage-2   | running | ::      | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#

და საბოლოო შეხება - თქვენ უნდა შეასწოროთ firewall-ის წესები (ან მთლიანად გამორთოთ):

firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload

ახლა მოდით წავიდეთ undercloud-ზე და შევამოწმოთ, რომ ყველაფერი მუშაობს. მასპინძელი აპარატის მისამართია 192.168.255.200, undercloud-ზე დავამატეთ საჭირო ipmitool პაკეტი განლაგებისთვის მომზადების დროს:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status          
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list 
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 65    control-1                      running

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

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

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

[root@hp-gen9 ~]# virsh domiflist --domain control-1 
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:20:a2:2f
-          network    ovs-network-1 virtio      52:54:00:3f:87:9f

[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:98:e9:d6

[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:6a:ea:be

[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:79:0b:cb

[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:a7:fe:27

შენიშვნა: საკონტროლო კვანძს აქვს ორი ინტერფეისი, მაგრამ ამ შემთხვევაში ეს არ არის მნიშვნელოვანი, ამ ინსტალაციაში ერთი საკმარისი იქნება ჩვენთვის.

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

{
    "nodes":[
        {
            "mac":[
                "52:54:00:20:a2:2f"
            ],
            "cpu":"8",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"control-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7001"
        },
        {
            "mac":[
                "52:54:00:79:0b:cb"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7002"
        },
        {
            "mac":[
                "52:54:00:a7:fe:27"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7003"
        },
        {
            "mac":[
                "52:54:00:98:e9:d6"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7004"
        },
        {
            "mac":[
                "52:54:00:6a:ea:be"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7005"
        }
    ]
}

ახლა ჩვენ უნდა მოვამზადოთ სურათები ირონიისთვის. ამისათვის გადმოწერეთ ისინი wget-ის საშუალებით და დააინსტალირეთ:

(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack  916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack  15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/                       
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack  53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$

სურათების ატვირთვა undercloud-ში:

(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
|                  ID                  |          Name          | Disk Format |   Size  | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz |     aki     | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
|                  ID                  |          Name         | Disk Format |   Size   | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd |     ari     | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
|                  ID                  |      Name      | Disk Format |    Size    | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full |    qcow2    | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
|                  ID                  |       Name       | Disk Format |   Size  | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel |     aki     | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
|                  ID                  |        Name       | Disk Format |    Size   | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk |     ari     | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$

შეამოწმეთ, რომ ყველა სურათი დატვირთულია

(undercloud) [stack@undercloud ~]$  openstack image list
+--------------------------------------+------------------------+--------+
| ID                                   | Name                   | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel       | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk      | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full         | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd  | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$

კიდევ ერთი რამ - თქვენ უნდა დაამატოთ DNS სერვერი:

(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID                                   | Name            | Network                              | Subnet           |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field             | Value                                                     |
+-------------------+-----------------------------------------------------------+
| allocation_pools  | 192.168.255.11-192.168.255.50                             |
| cidr              | 192.168.255.0/24                                          |
| created_at        | 2020-08-13T20:10:37Z                                      |
| description       |                                                           |
| dns_nameservers   |                                                           |
| enable_dhcp       | True                                                      |
| gateway_ip        | 192.168.255.1                                             |
| host_routes       | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id                | f45dea46-4066-42aa-a3c4-6f84b8120cab                      |
| ip_version        | 4                                                         |
| ipv6_address_mode | None                                                      |
| ipv6_ra_mode      | None                                                      |
| name              | ctlplane-subnet                                           |
| network_id        | 6ca013dc-41c2-42d8-9d69-542afad53392                      |
| prefix_length     | None                                                      |
| project_id        | a844ccfcdb2745b198dde3e1b28c40a3                          |
| revision_number   | 0                                                         |
| segment_id        | None                                                      |
| service_types     |                                                           |
| subnetpool_id     | None                                                      |
| tags              |                                                           |
| updated_at        | 2020-08-13T20:10:37Z                                      |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253                                    
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$

ახლა ჩვენ შეგვიძლია მივცეთ ბრძანება ინტროსპექციისთვის:

(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json 
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.


5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$

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

(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID                                 | Name      | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None          | power off   | available          | False       |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None          | power off   | available          | False       |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None          | power off   | available          | False       |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None          | power off   | available          | False       |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None          | power off   | available          | False       |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ 

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

შემდეგი, ჩვენ უნდა მივუთითოთ რომელი კვანძი რომელ ფუნქციას შეასრულებს - ანუ, მიუთითოთ პროფილი, რომლითაც განლაგდება კვანძი:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | None            |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | None            |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | None            |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | None            |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | None            |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID                                   | Name          |  RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 |   40 |         0 |     1 | True      |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal     | 4096 |   40 |         0 |     1 | True      |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control       | 4096 |   40 |         0 |     1 | True      |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 |   40 |         0 |     1 | True      |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute       | 4096 |   40 |         0 |     1 | True      |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage  | 4096 |   40 |         0 |     1 | True      |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$

მიუთითეთ პროფილი თითოეული კვანძისთვის:

openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167

მოდით შევამოწმოთ, რომ ყველაფერი სწორად გავაკეთეთ:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | control         |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | ceph-storage    |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | ceph-storage    |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | compute         |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | compute         |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$

თუ ყველაფერი სწორია, ჩვენ ვაძლევთ ბრძანებას, რომ განვათავსოთ overcloud:

openstack overcloud deploy --templates --control-scale 1 --compute-scale 2  --ceph-storage-scale 2 --control-flavor control --compute-flavor compute  --ceph-storage-flavor ceph-storage --libvirt-type qemu

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

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

ახლა თქვენ გაქვთ დაახლოებით ერთი საათი, ან შეიძლება მეტი (დამოკიდებულია ტექნიკის შესაძლებლობებზე) და შეგიძლიათ მხოლოდ იმედი გქონდეთ, რომ ამ დროის შემდეგ ნახავთ შემდეგ შეტყობინებას:

2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE  Stack CREATE completed successfully

 Stack overcloud CREATE_COMPLETE 

Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$

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

მოდით შევამოწმოთ, რომ ყველაფერი გამართულად მუშაობს. მომხმარებლის მთავარი კატალოგის სტეკში არის ორი ფაილი - ერთი stackrc (ქვედა ღრუბლის მართვისთვის) და მეორე overcloudrc (overcloud-ის მართვისთვის). ეს ფაილები უნდა იყოს მითითებული, როგორც წყარო, რადგან ისინი შეიცავს ავთენტიფიკაციისთვის აუცილებელ ინფორმაციას.

(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID                                   | Name                    | Status | Networks                | Image          | Flavor       |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0  | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control      |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute      |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute      |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$ 

(undercloud) [stack@undercloud ~]$ source overcloudrc 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID                               | Name    |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin   |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$

ჩემი ინსტალაცია მაინც მოითხოვს ერთ მცირე შეხებას - მარშრუტის დამატებას კონტროლერზე, რადგან მანქანა, რომლითაც მე ვმუშაობ, არის სხვა ქსელში. ამისათვის გადადით control-1-ზე Heat-admin ანგარიშის ქვეშ და დაარეგისტრირეთ მარშრუტი

(undercloud) [stack@undercloud ~]$ ssh [email protected]         
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254

კარგი, ახლა შეგიძლია ჰორიზონტზე გახვიდე. ყველა ინფორმაცია - მისამართები, შესვლა და პაროლი - არის ფაილში /home/stack/overcloudrc. საბოლოო დიაგრამა ასე გამოიყურება:

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

როგორ მიედინება ტრაფიკი ვირტუალურ მანქანებს შორის?

ამ სტატიაში განვიხილავთ ტრაფიკის გავლის სამ ვარიანტს

• ორი მანქანა ერთ ჰიპერვიზორზე ერთ L2 ქსელზე
• ორი მანქანა სხვადასხვა ჰიპერვიზორზე იმავე L2 ქსელში
• ორი მანქანა სხვადასხვა ქსელში (ჯვარედინი ქსელის rooting)

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

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

ჩვენ შევქმენით 4 ვირტუალური მანქანა - 3 ერთ L2 ქსელზე - net-1 და კიდევ 1 net-2 ქსელში.

(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c             
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID                                   | Name | Tenant ID                        | Status | Task State | Power State | Networks        |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-2=10.0.2.8  |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ 

ვნახოთ, რომელ ჰიპერვიზორებზეა განთავსებული შექმნილი მანქანები:

(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-1                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000001                                        |

(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-2                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000002                                        |

(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-3                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000003                                        |

(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-4                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000004                                        |

(overcloud) [stack@undercloud ~]$
მანქანები vm-1 და vm-3 განლაგებულია compute-0-ზე, მანქანები vm-2 და vm-4 განლაგებულია კვანძზე compute-1.

გარდა ამისა, შეიქმნა ვირტუალური როუტერი მითითებულ ქსელებს შორის მარშრუტიზაციის გასააქტიურებლად:

(overcloud) [stack@undercloud ~]$ openstack router list  --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID                                   | Name     | Status | State | Distributed | HA    | Project                          |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP    | False       | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ 

როუტერს აქვს ორი ვირტუალური პორტი, რომლებიც მოქმედებენ როგორც კარიბჭე ქსელებისთვის:

(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info         | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ 

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

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

ამ დროისთვის კვანძს აქვს სამი ovs ხიდი - br-int, br-tun, br-ex. მათ შორის, როგორც ვხედავთ, არის ინტერფეისების ნაკრები. გაგების გასაადვილებლად, მოდით დავხატოთ ყველა ეს ინტერფეისი დიაგრამაზე და ვნახოთ რა მოხდება.

თუ გადავხედავთ მისამართებს, რომლებზეც აწეულია VxLAN გვირაბები, ჩანს, რომ ერთი გვირაბი ამაღლებულია compute-1-ზე (192.168.255.26), მეორე გვირაბი გამოიყურება control-1-ზე (192.168.255.15). მაგრამ ყველაზე საინტერესო ის არის, რომ br-ex-ს არ აქვს ფიზიკური ინტერფეისები და თუ დააკვირდებით, რა ნაკადებია კონფიგურირებული, ხედავთ, რომ ამ ხიდს მხოლოდ ტრაფიკის შეწყვეტა შეუძლია მომენტში.

[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.19  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe6a:eabe  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:6a:ea:be  txqueuelen 1000  (Ethernet)
        RX packets 2909669  bytes 4608201000 (4.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1821057  bytes 349198520 (333.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-novacompute-0 ~]$ 

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

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-ofctl dump-flows br-ex
 cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
 cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$ 

პირველი წესის მიხედვით, ყველაფერი, რაც მოვიდა phy-br-ex პორტიდან, უნდა განადგურდეს.
რეალურად, ამჟამად არსად არის ტრაფიკი ამ ხიდზე, გარდა ამ ინტერფეისისა (ინტერფეისი br-int-თან), და თუ ვიმსჯელებთ ვარდნის მიხედვით, BUM ტრაფიკი უკვე შემოვიდა ხიდში.

ანუ ტრაფიკს შეუძლია ამ კვანძის დატოვება მხოლოდ VxLAN გვირაბით და სხვა არაფერი. თუმცა, თუ DVR-ს ჩართავთ, სიტუაცია შეიცვლება, მაგრამ ამას სხვა დროს მოვაგვარებთ. ქსელის იზოლაციის გამოყენებისას, მაგალითად vlans-ის გამოყენებით, თქვენ გექნებათ არა ერთი L3 ინტერფეისი vlan 0-ში, არამედ რამდენიმე ინტერფეისი. თუმცა, VxLAN ტრაფიკი დატოვებს კვანძს იმავე გზით, მაგრამ ასევე ჩასმულია რაიმე სახის გამოყოფილ vlan-ში.

ჩვენ დავახარისხეთ გამოთვლითი კვანძი, მოდით გადავიდეთ საკონტროლო კვანძზე.

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
  br-ex:
    br-ex 65534/1: (internal)
    eth0 1/2: (system)
    phy-br-ex 2/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/3: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/4: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$

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

[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.15  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe20:a22f  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:20:a2:2f  txqueuelen 1000  (Ethernet)
        RX packets 803859  bytes 1732616116 (1.6 GiB)
        RX errors 0  dropped 63  overruns 0  frame 0
        TX packets 808475  bytes 121652156 (116.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
    3   100  28:c0:da:00:4d:d3   35
    1     0  28:c0:da:00:4d:d3   35
    1     0  52:54:00:98:e9:d6    0
LOCAL     0  52:54:00:20:a2:2f    0
    1     0  52:54:00:2c:08:9e    0
    3   100  52:54:00:20:a2:2f    0
    1     0  52:54:00:6a:ea:be    0
[heat-admin@overcloud-controller-0 ~]$ 

ეს პორტი მიბმულია br-ex ხიდთან და რადგან მასზე არ არის vlan ტეგები, ეს პორტი არის მაგისტრალური პორტი, რომელზედაც ნებადართულია ყველა vlans, ახლა ტრაფიკი გადის გარეთ ტეგის გარეშე, როგორც ეს მითითებულია vlan-id 0-ში. გამომავალი ზემოთ.

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

ამ სტატიაში ჩვენ არ განვიხილავთ შენახვის კვანძებს, მაგრამ გასაგებად უნდა ითქვას, რომ ამ კვანძების ქსელური ნაწილი სამარცხვინომდე ბანალურია. ჩვენს შემთხვევაში, არსებობს მხოლოდ ერთი ფიზიკური პორტი (eth0), რომელსაც აქვს მინიჭებული IP მისამართი და ეს არის ის. არ არსებობს VxLAN გვირაბები, გვირაბის ხიდები და ა.შ. - საერთოდ არ არის ovs, რადგან მასში აზრი არ აქვს. ქსელის იზოლაციის გამოყენებისას, ამ კვანძს ექნება ორი ინტერფეისი (ფიზიკური პორტი, bodny, ან უბრალოდ ორი vlan - არ აქვს მნიშვნელობა - ეს დამოკიდებულია იმაზე, თუ რა გსურთ) - ერთი მართვისთვის, მეორე ტრაფიკისთვის (VM დისკზე ჩაწერა. , დისკიდან კითხვა და ა.შ.)

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

ჯერჯერობით ჩვენი ქსელი ასე გამოიყურება:

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

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list 
 Id    Name                           State
----------------------------------------------------
 1     instance-00000001              running
 3     instance-00000003              running

[heat-admin@overcloud-novacompute-0 ~]$ 

მანქანას აქვს მხოლოდ ერთი ვირტუალური ინტერფეისი - tap95d96a75-a0:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

ეს ინტერფეისი გამოიყურება ლინუქსის ხიდში:

[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242904c92a8       no
qbr5bd37136-47          8000.5e4e05841423       no              qvb5bd37136-47
                                                        tap5bd37136-47
qbr95d96a75-a0          8000.de076cb850f6       no              qvb95d96a75-a0
                                                        tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ 

როგორც გამოსვლიდან ხედავთ, ხიდში მხოლოდ ორი ინტერფეისია - tap95d96a75-a0 და qvb95d96a75-a0.

აქ ღირს ცოტა ვისაუბროთ OpenStack-ში ვირტუალური ქსელის მოწყობილობების ტიპებზე:
vtap - ვირტუალური ინტერფეისი, რომელიც მიმაგრებულია ინსტანციაზე (VM)
qbr - Linux ხიდი
qvb და qvo - vEth წყვილი დაკავშირებულია Linux ხიდთან და Open vSwitch bridge-თან
br-int, br-tun, br-vlan — გახსენით vSwitch ხიდები
patch-, int-br-, phy-br- - გახსენით vSwitch patch ინტერფეისები, რომლებიც აკავშირებს ხიდებს
qg, qr, ha, fg, sg - გახსენით vSwitch პორტები, რომლებიც გამოიყენება ვირტუალური მოწყობილობების მიერ OVS-თან დასაკავშირებლად

როგორც გესმით, თუ ხიდში გვაქვს qvb95d96a75-a0 პორტი, რომელიც არის vEth წყვილი, მაშინ სადღაც არის მისი ანალოგი, რომელსაც ლოგიკურად უნდა ეწოდოს qvo95d96a75-a0. მოდით შევხედოთ რა პორტებია OVS-ზე.

[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
    qvo5bd37136-47 6/6: (system)
    qvo95d96a75-a0 3/5: (system)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ 

როგორც ვხედავთ, პორტი არის br-int. Br-int მოქმედებს როგორც გადამრთველი, რომელიც წყვეტს ვირტუალური მანქანის პორტებს. qvo95d96a75-a0-ის გარდა, გამოსავალზე ჩანს qvo5bd37136-47 პორტი. ეს არის მეორე ვირტუალური მანქანის პორტი. შედეგად, ჩვენი დიაგრამა ახლა ასე გამოიყურება:

კითხვა, რომელიც დაუყოვნებლივ უნდა დაინტერესდეს ყურადღებიანი მკითხველისთვის - რა არის ლინუქსის ხიდი ვირტუალური მანქანის პორტსა და OVS პორტს შორის? ფაქტია, რომ აპარატის დასაცავად გამოიყენება უსაფრთხოების ჯგუფები, რომლებიც სხვა არაფერია თუ არა iptables. OVS არ მუშაობს iptable-ებთან, ამიტომ გამოიგონეს ეს "ყავარჯენი". თუმცა, ის მოძველებულია - ახალ გამოშვებებში მას ცვლის კონტრაკით.

ანუ, საბოლოო ჯამში, სქემა ასე გამოიყურება:

ორი მანქანა ერთ ჰიპერვიზორზე ერთ L2 ქსელზე

ვინაიდან ეს ორი VM განლაგებულია ერთსა და იმავე L2 ქსელში და იმავე ჰიპერვიზორზე, მათ შორის ტრაფიკი ლოგიკურად წარიმართება ადგილობრივად br-int-ის მეშვეობით, რადგან ორივე მანქანა იქნება ერთსა და იმავე VLAN-ზე:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap5bd37136-47 bridge     qbr5bd37136-47 virtio      fa:16:3e:83:ad:a4

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int 
 port  VLAN  MAC                Age
    6     1  fa:16:3e:83:ad:a4    0
    3     1  fa:16:3e:44:98:20    0
[heat-admin@overcloud-novacompute-0 ~]$ 

ორი მანქანა სხვადასხვა ჰიპერვიზორზე იმავე L2 ქსელში

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

ვირტუალური მანქანების მისამართები, რომელთა შორისაც ჩვენ ვუყურებთ ტრაფიკს:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tape7e23f1b-07 bridge     qbre7e23f1b-07 virtio      fa:16:3e:72:ad:53

[heat-admin@overcloud-novacompute-1 ~]$ 

ჩვენ ვუყურებთ გადაგზავნის ცხრილს br-int-ზე compute-0-ზე:

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
    2     1  fa:16:3e:72:ad:53    1
[heat-admin@overcloud-novacompute-0 ~]

ტრაფიკი უნდა წავიდეს პორტში 2 - ვნახოთ, როგორი პორტია ეს:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$

ეს არის patch-tun - ეს არის ინტერფეისი br-tun-ში. ვნახოთ, რა დაემართება პაკეტს br-tun-ზე:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
 cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ 

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

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr   
 1(patch-int): addr:b2:d1:f8:21:96:66
 2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
 3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
 LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$

ეს არის vxlan გვირაბი compute-1-ზე:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

მოდით გადავიდეთ Compute-1-ზე და ვნახოთ, რა მოხდება შემდეგ პაკეტთან დაკავშირებით:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
    2     1  fa:16:3e:44:98:20    1
[heat-admin@overcloud-novacompute-1 ~]$ 

Mac არის br-int გადამისამართების ცხრილში compute-1-ზე და როგორც ჩანს ზემოთ მოყვანილი გამოსავლიდან, ის ჩანს პორტის 2-დან, რომელიც არის პორტი br-tun-ისკენ:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr   
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46

კარგად, მაშინ ჩვენ ვხედავთ, რომ br-int-ში compute-1 არის დანიშნულების ყაყაჩო:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
    3     1  fa:16:3e:72:ad:53    0
[heat-admin@overcloud-novacompute-1 ~]$ 

ანუ მიღებული პაკეტი გაფრინდება მე-3 პორტში, რომლის უკან უკვე არის ვირტუალური აპარატის ინსტანცია-00000003.

ვირტუალურ ინფრასტრუქტურაზე სწავლისთვის Openstack-ის განლაგების მშვენიერი ის არის, რომ ჩვენ შეგვიძლია მარტივად აღვბეჭდოთ ტრაფიკი ჰიპერვიზორებს შორის და ვნახოთ რა ხდება მასთან. ეს არის ის, რასაც ჩვენ გავაკეთებთ ახლა, გაუშვით tcpdump vnet პორტზე compute-0-ის მიმართულებით:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
	
*****************omitted*******************

პირველი ხაზი აჩვენებს, რომ Patek 10.0.1.85 მისამართიდან მიდის 10.0.1.88 მისამართზე (ICMP ტრაფიკი) და ის შეფუთულია VxLAN პაკეტში vni 22-ით და პაკეტი გადადის ჰოსტიდან 192.168.255.19 (გამოთვლა-0) ჰოსტში 192.168.255.26. .1 ( გამოთვლა-XNUMX). ჩვენ შეგვიძლია შევამოწმოთ, რომ VNI ემთხვევა ovs-ში მითითებულს.

მოდით დავუბრუნდეთ ამ ხაზს actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],გამომავალი:2. 0x16 არის vni თექვსმეტობით რიცხვთა სისტემაში. გადავიყვანოთ ეს რიცხვი მე-16 სისტემაში:

16 = 6*16^0+1*16^1 = 6+16 = 22

ანუ ვნი რეალობას შეესაბამება.

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

ორი მანქანა სხვადასხვა ქსელში (ქსელთაშორისი მარშრუტიზაცია)

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

ჯერ ვნახოთ, რომ მარშრუტიზაცია მუშაობს:

$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 ms

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

$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether]  on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether]  on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether]  on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether]  on eth0

ახლა ვნახოთ სად უნდა გაიგზავნოს ტრაფიკი დანიშნულების (10.0.1.254) fa:16:3e:c4:64:70:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
    2     1  fa:16:3e:c4:64:70    0
[heat-admin@overcloud-novacompute-0 ~]$ 

მოდით შევხედოთ სად მიდის პორტი 2:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ 

ყველაფერი ლოგიკურია, ტრაფიკი მიდის br-tun-ზე. ვნახოთ რომელ vxlan გვირაბში იქნება გახვეული:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
 cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ 

მესამე პორტი არის vxlan გვირაბი:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 

რომელიც უყურებს საკონტროლო კვანძს:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

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

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

ასე რომ, აშკარაა, რომ Gateway MAC მისამართი უნდა იყოს br-int გადამისამართების ცხრილში საკონტროლო კვანძზე. მოდით შევამოწმოთ, რომ ის იქ არის და სად იყურება:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
    5     1  fa:16:3e:c4:64:70    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$  sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

Mac ჩანს qr-0c52b15f-8f პორტიდან. თუ დავუბრუნდებით Openstack-ის ვირტუალური პორტების სიას, ამ ტიპის პორტი გამოიყენება სხვადასხვა ვირტუალური მოწყობილობების OVS-თან დასაკავშირებლად. უფრო ზუსტად რომ ვთქვათ, qr არის პორტი ვირტუალურ როუტერზე, რომელიც წარმოდგენილია სახელთა სივრცის სახით.

ვნახოთ რა სახელთა სივრცეებია სერვერზე:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

სულ სამი ეგზემპლარი. მაგრამ სახელების მიხედვით თუ ვიმსჯელებთ, შეგიძლიათ გამოიცნოთ თითოეული მათგანის მიზანი. ჩვენ მოგვიანებით დავუბრუნდებით შემთხვევებს ID 0 და 1-ით, ახლა ჩვენ გვაინტერესებს სახელთა სივრცე qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254 
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254 
[heat-admin@overcloud-controller-0 ~]$ 

ეს სახელთა სივრცე შეიცავს ორ შიდა სივრცეს, რომლებიც ადრე შევქმენით. ორივე ვირტუალური პორტი დაემატა br-int-ს. მოდით შევამოწმოთ qr-0c52b15f-8f პორტის mac მისამართი, რადგან ტრაფიკი, დანიშნულების Mac მისამართის მიხედვით ვიმსჯელებთ, ამ ინტერფეისზე წავიდა.

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.254  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fec4:6470  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:c4:64:70  txqueuelen 1000  (Ethernet)
        RX packets 5356  bytes 427305 (417.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5195  bytes 490603 (479.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 

ანუ, ამ შემთხვევაში, ყველაფერი მუშაობს სტანდარტული მარშრუტიზაციის კანონების მიხედვით. ვინაიდან ტრაფიკი განკუთვნილია ჰოსტისთვის 10.0.2.8, ის უნდა გამოვიდეს მეორე ინტერფეისიდან qr-92fa49b5-54 და გაიაროს vxlan გვირაბი გამოთვლით კვანძში:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address                  HWtype  HWaddress           Flags Mask            Iface
10.0.1.88                ether   fa:16:3e:72:ad:53   C                     qr-0c52b15f-8f
10.0.1.90                ether   fa:16:3e:83:ad:a4   C                     qr-0c52b15f-8f
10.0.2.8                 ether   fa:16:3e:6c:ad:9c   C                     qr-92fa49b5-54
10.0.2.42                ether   fa:16:3e:f5:0b:29   C                     qr-92fa49b5-54
10.0.1.85                ether   fa:16:3e:44:98:20   C                     qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ 

ყველაფერი ლოგიკურია, გასაკვირი არ არის. ვნახოთ, სად ჩანს ჰოსტის 10.0.2.8 პოპი მისამართი br-int-ში:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    2     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

როგორც მოსალოდნელი იყო, მოძრაობა მიდის br-tun-ზე, ვნახოთ, რომელ გვირაბამდე მიდის მოძრაობა:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
 cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

სატრანსპორტო მოძრაობა მიდის გვირაბში, რათა გამოვთვალოთ-1. ისე, compute-1-ზე ყველაფერი მარტივია - br-tun-დან პაკეტი გადადის br-int-ზე და იქიდან ვირტუალური მანქანის ინტერფეისზე:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    4     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr                  
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ 

მოდით შევამოწმოთ, რომ ეს მართლაც სწორი ინტერფეისია:

[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.02429c001e1c       no
qbr3210e8ec-c0          8000.ea27f45358be       no              qvb3210e8ec-c0
                                                        tap3210e8ec-c0
qbre7e23f1b-07          8000.b26ac0eded8a       no              qvbe7e23f1b-07
                                                        tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge     qbr3210e8ec-c0 virtio      fa:16:3e:6c:ad:9c

[heat-admin@overcloud-novacompute-1 ~]$

ფაქტობრივად, ჩვენ მთელი გზა გავიარეთ ამანათი. ვფიქრობ, თქვენ შენიშნეთ, რომ ტრაფიკი გადიოდა სხვადასხვა vxlan გვირაბებში და გამოდიოდა სხვადასხვა VNI-ებით. ვნახოთ, რა სახის VNI არის ეს, რის შემდეგაც ჩვენ ვაგროვებთ ნაგავსაყრელს კვანძის საკონტროლო პორტზე და დავრწმუნდებით, რომ ტრაფიკი მიედინება ზუსტად ისე, როგორც ზემოთ აღწერილი.
ასე რომ, 0-ის გამოსათვლელ გვირაბს აქვს შემდეგი მოქმედებები=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],გამომავალი:3. გადავიყვანოთ 0x16 ათობითი რიცხვების სისტემაში:

0x16 = 6*16^0+1*16^1 = 6+16 = 22

გამოთვლა-1 გვირაბს აქვს შემდეგი VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],გამომავალი:2. გადავიყვანოთ 0x63 ათობითი რიცხვების სისტემაში:

0x63 = 3*16^0+6*16^1 = 3+96 = 99

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

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4 
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
	
*****************omitted*******************

პირველი პაკეტი არის vxlan პაკეტი ჰოსტიდან 192.168.255.19 (compute-0) ჰოსტამდე 192.168.255.15 (control-1) vni 22-ით, რომლის შიგნით შეფუთულია ICMP პაკეტი ჰოსტიდან 10.0.1.85 ჰოსტ 10.0.2.8. როგორც ზემოთ გამოვთვალეთ, vni ემთხვევა იმას, რაც ვნახეთ გამოსავალში.

მეორე პაკეტი არის vxlan პაკეტი ჰოსტიდან 192.168.255.15 (control-1) ჰოსტ 192.168.255.26 (compute-1) vni 99-ით, რომლის შიგნით შეფუთულია ICMP პაკეტი ჰოსტიდან 10.0.1.85 ჰოსტ 10.0.2.8. როგორც ზემოთ გამოვთვალეთ, vni ემთხვევა იმას, რაც ვნახეთ გამოსავალში.

შემდეგი ორი პაკეტი არის დაბრუნების ტრაფიკი 10.0.2.8-დან და არა 10.0.1.85-დან.

ანუ, საბოლოოდ მივიღეთ შემდეგი საკონტროლო კვანძის სქემა:

გამოიყურებოდეს ეს არის? ჩვენ დაგვავიწყდა ორი სახელების ადგილი:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

როგორც ჩვენ ვისაუბრეთ ღრუბლოვანი პლატფორმის არქიტექტურაზე, კარგი იქნება, თუ მანქანებმა მისამართები ავტომატურად მიიღეს DHCP სერვერიდან. ეს არის ორი DHCP სერვერი ჩვენი ორი ქსელისთვის 10.0.1.0/24 და 10.0.2.0/24.

მოდით შევამოწმოთ, რომ ეს მართალია. ამ სახელთა სივრცეში არის მხოლოდ ერთი მისამართი - 10.0.1.1 - თავად DHCP სერვერის მისამართი და ის ასევე შედის br-int-ში:

[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1  bytes 28 (28.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 28 (28.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.1  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fee6:2c5c  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:e6:2c:5c  txqueuelen 1000  (Ethernet)
        RX packets 129  bytes 9372 (9.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 49  bytes 6154 (6.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ვნახოთ, არის თუ არა პროცესები, რომლებიც შეიცავს qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 მათ სახელს საკონტროლო კვანძზე:

[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 
root      640420  0.0  0.0   4220   348 ?        Ss   11:31   0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+  951620  0.0  0.0 112944   980 pts/0    S+   18:50   0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ 

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

[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$

შედეგად, ჩვენ ვიღებთ სერვისების შემდეგ კომპლექტს საკონტროლო კვანძზე:

კარგად, გაითვალისწინეთ - ეს არის მხოლოდ 4 მანქანა, 2 შიდა ქსელი და ერთი ვირტუალური როუტერი... ჩვენ ახლა არ გვაქვს გარე ქსელები, სხვადასხვა პროექტების თაიგული, თითოეულს აქვს საკუთარი ქსელები (გადახურული) და გვაქვს განაწილებული როუტერი გამორთულია და ბოლოს და ბოლოს, ტესტის სკამზე მხოლოდ ერთი საკონტროლო კვანძი იყო (შეცდომის ტოლერანტობისთვის უნდა არსებობდეს სამი კვანძის კვორუმი). ლოგიკურია, რომ კომერციაში ყველაფერი „ცოტათი“ უფრო რთულია, მაგრამ ამ მარტივ მაგალითში ჩვენ გვესმის, როგორ უნდა იმუშაოს - 3 თუ 300 სახელთა სივრცე, რა თქმა უნდა, მნიშვნელოვანია, მაგრამ ფუნქციონირების თვალსაზრისით. მთელი სტრუქტურა, დიდად არაფერი შეიცვლება... თუმცა თქვენ არ შეაერთებთ რომელიმე გამყიდველის SDN-ს. მაგრამ ეს სრულიად განსხვავებული ამბავია.

იმედია საინტერესო იყო. თუ გაქვთ რაიმე კომენტარი/დამატება, ან სადმე პირდაპირ მოვიტყუე (ადამიანი ვარ და ჩემი აზრი ყოველთვის სუბიექტური იქნება) - დაწერეთ რა უნდა გამოსწორდეს/დამატებული - ჩვენ ყველაფერს გამოვასწორებთ/დავამატებთ.

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

თუ OpenStack არის საზოგადოებაზე ორიენტირებული გადაწყვეტა, მაშინ VMWare-ს უფლება აქვს გააკეთოს მხოლოდ ის, რაც მას სურს (წაიკითხეთ - რა არის მისთვის მომგებიანი) და ეს ლოგიკურია - რადგან ის არის კომერციული კომპანია, რომელიც მიჩვეულია ფულის გამომუშავებას თავისი კლიენტებისგან. მაგრამ არის ერთი დიდი და მსუქანი, მაგრამ - შეგიძლიათ გადმოხვიდეთ OpenStack-იდან, მაგალითად Nokia-დან და მცირე ხარჯებით გადახვიდეთ გამოსავალზე, მაგალითად, Juniper-დან (Contrail Cloud), მაგრამ ნაკლებად სავარაუდოა, რომ შეძლებთ VMWare-დან გამოსვლას. . ჩემთვის ეს ორი გამოსავალი ასე გამოიყურება - Openstack (გამყიდველი) არის უბრალო გალია, რომელშიც მოთავსებული ხარ, მაგრამ გაქვს გასაღები და შეგიძლია ნებისმიერ დროს დატოვო. VMWare არის ოქროს გალია, მფლობელს აქვს გალიის გასაღები და ძვირი დაგიჯდებათ.

მე არ ვაკეთებ არც პირველ პროდუქტს და არც მეორეს - შენ ირჩევ რაც გჭირდება. მაგრამ ასეთი არჩევანი რომ მქონდეს, ორივე გადაწყვეტას ავირჩევდი - VMWare IT ღრუბლისთვის (დაბალი დატვირთვა, მარტივი მენეჯმენტი), OpenStack ზოგიერთი გამყიდველისგან (Nokia და Juniper გთავაზობთ ძალიან კარგ გადაწყვეტილებებს) - Telecom cloud-ისთვის. მე არ გამოვიყენებ Openstack-ს სუფთა IT-სთვის - ეს ჰგავს ბეღურების სროლას ქვემეხით, მაგრამ მე ვერ ვხედავ რაიმე უკუჩვენებას მის გამოყენებასთან დაკავშირებით, გარდა ზედმეტის. თუმცა, ტელეკომში VMWare-ის გამოყენება ჰგავს Ford Raptor-ში ნატეხი ქვის ზიდვას - ის გარედან ლამაზია, მაგრამ მძღოლმა ერთის ნაცვლად 10 მგზავრობა უნდა გააკეთოს.

ჩემი აზრით, VMWare-ის ყველაზე დიდი მინუსი არის მისი სრული ჩაკეტვა - კომპანია არ მოგცემთ ინფორმაციას იმის შესახებ, თუ როგორ მუშაობს, მაგალითად, vSAN ან რა არის ჰიპერვიზორის ბირთვში - ეს უბრალოდ არ არის მომგებიანი - ანუ თქვენ მოგცემთ. არასოდეს გახდე VMWare-ის ექსპერტი - გამყიდველის მხარდაჭერის გარეშე, განწირული ხარ (ძალიან ხშირად ვხვდები VMWare ექსპერტებს, რომლებიც გაოგნებულნი არიან ტრივიალური კითხვებით). ჩემთვის VMWare ყიდულობს მანქანას დაკეტილი კაპოტით - დიახ, შეიძლება გყავდეთ სპეციალისტები, რომლებსაც შეუძლიათ დროის ღვედის შეცვლა, მაგრამ მხოლოდ მას, ვინც გიყიდათ ეს ხსნარი, შეუძლია გახსნას კაპოტი. პირადად მე არ მომწონს გადაწყვეტილებები, რომლებსაც ვერ ვხვდები. თქვენ იტყვით, რომ შეიძლება არ მოგიწიოთ კაპოტის ქვეშ შესვლა. დიახ, ეს შესაძლებელია, მაგრამ მე შემოგხედავთ, როცა დაგჭირდებათ ღრუბელში დიდი ფუნქციის აწყობა 20-30 ვირტუალური აპარატიდან, 40-50 ქსელიდან, რომელთაგან ნახევარს სურს გარეთ გასვლა, მეორე ნახევარი კი ითხოვს. SR-IOV აჩქარება, წინააღმდეგ შემთხვევაში დაგჭირდებათ ამ მანქანების რამდენიმე ათეული მეტი - წინააღმდეგ შემთხვევაში შესრულება არ იქნება საკმარისი.

არსებობს სხვა თვალსაზრისი, ასე რომ მხოლოდ თქვენ შეგიძლიათ გადაწყვიტოთ რა უნდა აირჩიოთ და, რაც მთავარია, თქვენ იქნებით პასუხისმგებელი თქვენს არჩევანზე. ეს მხოლოდ ჩემი აზრია - ადამიანი, რომელსაც უნახავს და შეეხო მინიმუმ 4 პროდუქტი - Nokia, Juniper, Red Hat და VMWare. ანუ რაღაც მაქვს შესადარებელი.

წყარო: www.habr.com