სდსმ დასრულდა, მაგრამ წერის უკონტროლო სურვილი რჩება.

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

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

ინფორმაციის

1. მიზნები
   1. ქსელი ერთიან ორგანიზმს ჰგავს
   2. კონფიგურაციის ტესტირება
   3. ვერსიები
   4. სერვისების მონიტორინგი და თვითგანკურნება

2. ფონდები
   1. ინვენტარიზაციის სისტემა
   2. IP სივრცის მართვის სისტემა
   3. ქსელის სერვისის აღწერის სისტემა
   4. მოწყობილობის ინიციალიზაციის მექანიზმი
   5. გამყიდველი-აგნოსტიკური კონფიგურაციის მოდელი
   6. გამყიდველის სპეციფიკური დრაივერის ინტერფეისი
   7. მოწყობილობაზე კონფიგურაციის მიწოდების მექანიზმი
   8. CI / CD
   9. სარეზერვო და გადახრების ძიების მექანიზმი
   10. მონიტორინგის სისტემა

3. დასკვნა

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

რა სასაცილოა მეორედ რომ იგივე გზა უნდა გაიარო.

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

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

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

ჩვენ შევეცდებით ავიღოთ საშუალო ზომის LAN DC მონაცემთა ცენტრი და შევიმუშაოთ ავტომატიზაციის მთელი სქემა.
რაღაცეებს ​​თითქმის პირველად გავაკეთებ შენთან ერთად.

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

LAN DC-ს აქვს 4 DC, დაახლოებით 250 გადამრთველი, ნახევარი ათეული მარშრუტიზატორი და რამდენიმე ბუხარი.
არა ფეისბუქი, მაგრამ საკმარისია იმისთვის, რომ ღრმად იფიქროთ ავტომატიზაციაზე.
თუმცა არსებობს მოსაზრება, რომ თუ თქვენ გაქვთ 1-ზე მეტი მოწყობილობა, ავტომატიზაცია უკვე საჭიროა.
სინამდვილეში, ძნელი წარმოსადგენია, რომ ახლა ვინმეს შეუძლია იცხოვროს მუხლზე სკრიპტების მინიმუმის გარეშე.
მიუხედავად იმისა, რომ გავიგე, რომ არის ოფისები, სადაც IP მისამართები ინახება Excel-ში და ათასობით ქსელური მოწყობილობიდან თითოეული კონფიგურებულია ხელით და აქვს საკუთარი უნიკალური კონფიგურაცია. ეს, რა თქმა უნდა, შეიძლება გადავიდეს როგორც თანამედროვე ხელოვნება, მაგრამ ინჟინრის გრძნობები აუცილებლად შეურაცხყოფილი იქნება.

მიზნები

ახლა ჩვენ დავსახავთ ყველაზე აბსტრაქტულ მიზნებს:

• ქსელი ერთიან ორგანიზმს ჰგავს
• კონფიგურაციის ტესტირება
• ქსელის მდგომარეობის ვერსია
• სერვისების მონიტორინგი და თვითგანკურნება

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

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

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

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

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

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

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

კონფიგურაციის ტესტირება

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

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

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

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

იდეების ორგანული გაგრძელება სისტემა ქსელის მართვა და CI/CD ხდება კონფიგურაციის სრული ვერსია.

ვერსიები

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

ვთქვათ, მიმდინარე ვერსიაა 1.0.0.
შეიცვალა თუ არა Loopback ინტერფეისის IP მისამართი ერთ-ერთ ToR-ზე? ეს არის მცირე ვერსია და დანომრილი იქნება 1.0.1.
ჩვენ გადავხედეთ BGP-ში მარშრუტების შემოტანის პოლიტიკას - ცოტა უფრო სერიოზულად - უკვე 1.1.0
გადავწყვიტეთ IGP-ს მოშორება და მხოლოდ BGP-ზე გადასვლა - ეს უკვე რადიკალური დიზაინის ცვლილებაა - 2.0.0.

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

on სემანტიკური ვერსია ცალკე სტატიაში ვისაუბრებთ.

ვიმეორებ - ნებისმიერი ცვლილება (გარდა გამართვის ბრძანებებისა) არის ვერსიის განახლება. ადმინისტრატორებს უნდა ეცნობოთ მიმდინარე ვერსიიდან ნებისმიერი გადახრის შესახებ.

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

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

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

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

რა დაგვჭირდება ასეთი ამბიციური გეგმების განსახორციელებლად?

• გქონდეთ ქსელში არსებული ყველა მოწყობილობის სია, მათი მდებარეობა, როლები, მოდელები, პროგრამული უზრუნველყოფის ვერსიები.
  kazan-leaf-1.lmu.net, Kazan, ფოთოლი, Juniper QFX 5120, R18.3.
• გქონდეთ ქსელის სერვისების აღწერის სისტემა.
  IGP, BGP, L2/3VPN, პოლიტიკა, ACL, NTP, SSH.
• შეძლებს მოწყობილობის ინიციალიზაციას.
  ჰოსტის სახელი, Mgmt IP, Mgmt მარშრუტი, მომხმარებლები, RSA- Keys, LLDP, NETCONF
• დააკონფიგურირეთ მოწყობილობა და მიიტანეთ კონფიგურაცია სასურველ (მათ შორის ძველ) ვერსიამდე.
• ტესტის კონფიგურაცია
• პერიოდულად შეამოწმეთ ყველა მოწყობილობის სტატუსი არსებულიდან გადახრებისთვის და შეატყობინეთ ვის უნდა იყოს.
  ღამით ვიღაცამ ჩუმად დაამატა ACL-ს წესი.
• მუშაობის მონიტორინგი.

ფონდები

საკმარისად რთულად ჟღერს, რომ დაიწყოს პროექტის კომპონენტებად დაშლა.

და იქნება ათი მათგანი:

1. ინვენტარიზაციის სისტემა
2. IP სივრცის მართვის სისტემა
3. ქსელის სერვისის აღწერის სისტემა
4. მოწყობილობის ინიციალიზაციის მექანიზმი
5. გამყიდველი-აგნოსტიკური კონფიგურაციის მოდელი
6. გამყიდველის სპეციფიკური დრაივერის ინტერფეისი
7. მოწყობილობაზე კონფიგურაციის მიწოდების მექანიზმი
8. CI / CD
9. სარეზერვო და გადახრების ძიების მექანიზმი
10. მონიტორინგის სისტემა

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

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

კომპონენტი 1: ინვენტარიზაციის სისტემა

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

ჩვენი მიზნებისთვის, ჩვენ ვინახავთ მასში მოწყობილობის შესახებ შემდეგ ინფორმაციას:

• ინვენტარი ნომერი
• სათაური/აღწერა
• მოდელი (Huawei CE12800, Juniper QFX5120 და ა.შ.)
• დამახასიათებელი პარამეტრები (დაფები, ინტერფეისები და ა.შ.)
• როლი (ფოთოლი, ხერხემალი, სასაზღვრო როუტერი და ა.შ.)
• მდებარეობა (რეგიონი, ქალაქი, მონაცემთა ცენტრი, თარო, ერთეული)
• ურთიერთკავშირები მოწყობილობებს შორის
• ქსელის ტოპოლოგია

სავსებით ნათელია, რომ ჩვენ თვითონ გვინდა ვიცოდეთ ეს ყველაფერი.
მაგრამ დაეხმარება ეს ავტომატიზაციის მიზნებისთვის?
რა თქმა უნდა.
მაგალითად, ჩვენ ვიცით, რომ მოცემულ მონაცემთა ცენტრში Leaf-ის გადამრთველებზე, თუ ეს არის Huawei, ACL-ები გარკვეული ტრაფიკის გასაფილტრად უნდა იქნას გამოყენებული VLAN-ზე, ხოლო თუ ეს არის Juniper, მაშინ ფიზიკური ინტერფეისის 0 ერთეულზე.
ან თქვენ უნდა გააფართოვოთ ახალი Syslog სერვერი რეგიონის ყველა საზღვარზე.

მასში ჩვენ ვინახავთ ვირტუალური ქსელის მოწყობილობებს, მაგალითად ვირტუალურ მარშრუტიზატორებს ან root რეფლექტორებს. ჩვენ შეგვიძლია დავამატოთ DNS სერვერები, NTP, Syslog და ზოგადად ყველაფერი, რაც ამა თუ იმ გზით ეხება ქსელს.

კომპონენტი 2: IP სივრცის მართვის სისტემა

დიახ, და დღესდღეობით არის ადამიანების გუნდები, რომლებიც თვალყურს ადევნებენ პრეფიქსებსა და IP მისამართებს Excel ფაილში. მაგრამ თანამედროვე მიდგომა კვლავ მონაცემთა ბაზაა, nginx/apache-ზე წინა ნაწილით, API და ფართო ფუნქციებით IP მისამართებისა და ქსელების ჩასაწერად დაყოფილი VRF-ებად.
IPAM - IP მისამართის მართვა.

ჩვენი მიზნებისთვის ჩვენ მასში ვინახავთ შემდეგ ინფორმაციას:

• VLAN
• VRF
• ქსელები/ქვექსელები
• IP მისამართები
• მისამართების დაკავშირება მოწყობილობებთან, ქსელებთან მდებარეობებთან და VLAN ნომრებთან

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

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

კომპონენტი 3. ქსელის სერვისების აღწერის სისტემა

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

• ინფრასტრუქტურა
• კლიენტი.

პირველი შექმნილია ძირითადი კავშირისა და მოწყობილობის კონტროლის უზრუნველსაყოფად. ეს მოიცავს VTY, SNMP, NTP, Syslog, AAA, მარშრუტიზაციის პროტოკოლებს, CoPP და ა.შ.
ეს უკანასკნელი აწყობს კლიენტს მომსახურებას: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP და ა.შ.
რა თქმა უნდა, არის სასაზღვრო შემთხვევებიც - სად ჩავრთოთ MPLS LDP, BGP? დიახ, და მარშრუტიზაციის პროტოკოლები შეიძლება გამოყენებულ იქნას კლიენტებისთვის. მაგრამ ეს არ არის მნიშვნელოვანი.

ორივე ტიპის სერვისი იყოფა კონფიგურაციის პრიმიტივებად:

• ფიზიკური და ლოგიკური ინტერფეისები (ტეგი/ანტიგ, mtu)
• IP მისამართები და VRF (IP, IPv6, VRF)
• ACL და ტრაფიკის დამუშავების პოლიტიკა
• პროტოკოლები (IGP, BGP, MPLS)
• მარშრუტიზაციის პოლიტიკა (პრეფიქსის სიები, თემები, ASN ფილტრები).
• კომუნალური მომსახურება (SSH, NTP, LLDP, Syslog...)
• და ა.შ.

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

თუ ცოტა უფრო ახლოს იქნება ცხოვრებასთან, მაშინ შეგვიძლია ამის აღწერა
Leaf გადამრთველს უნდა ჰქონდეს BGP სესიები ყველა დაკავშირებული Spine გადამრთველებით, ჩაერთოს დაკავშირებული ქსელები პროცესში და მიიღოს მხოლოდ ქსელები გარკვეული პრეფიქსიდან Spine switch-ებიდან. შეზღუდეთ CoPP IPv6 ND 10 pps-მდე და ა.შ.
თავის მხრივ, ხერხემლები ატარებენ სესიებს ყველა დაკავშირებულ მილსადენებთან, მოქმედებენ როგორც ფესვის რეფლექტორები და მათგან იღებენ მხოლოდ გარკვეული სიგრძის მარშრუტებს და გარკვეულ საზოგადოებასთან.

კომპონენტი 4: მოწყობილობის ინიციალიზაციის მექანიზმი

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

1. შეიყვანეთ მოწყობილობა ინვენტარიზაციის სისტემაში.
2. აირჩიეთ მართვის IP მისამართი.
3. დააყენეთ მასზე ძირითადი წვდომა:
   ჰოსტის სახელი, მართვის IP მისამართი, მარშრუტი მართვის ქსელში, მომხმარებლები, SSH კლავიშები, პროტოკოლები - telnet/SSH/NETCONF

არსებობს სამი მიდგომა:

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

სამივეს შესახებ ცალკე სტატიაში ვისაუბრებთ.

კომპონენტი 5: გამყიდველი-აგნოსტიკური კონფიგურაციის მოდელი

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

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

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

კომპონენტი 6. გამყიდველის სპეციფიკური დრაივერის ინტერფეისი

თქვენ არ უნდა მაამოთ თავი იმ იმედით, რომ ერთ დღეს შესაძლებელი გახდება ცისკას კონფიგურაცია ზუსტად ისე, როგორც Juniper, უბრალოდ მათთან ზუსტად იგივე ზარების გაგზავნით. თეთრი ყუთების მზარდი პოპულარობისა და NETCONF, RESTCONF, OpenConfig-ის მხარდაჭერის გაჩენის მიუხედავად, სპეციფიკური შინაარსი, რომელსაც ეს პროტოკოლები აწვდიან, განსხვავდება გამყიდველიდან გამყიდველამდე და ეს არის მათი კონკურენტული განსხვავება, რომელსაც ისინი ასე ადვილად არ დათმობენ.
ეს დაახლოებით იგივეა, რაც OpenContrail და OpenStack, რომლებსაც აქვთ RestAPI, როგორც NorthBound ინტერფეისი, მოელიან სრულიად განსხვავებულ ზარებს.

ასე რომ, მეხუთე საფეხურზე, გამყიდველისგან დამოუკიდებელმა მოდელმა უნდა მიიღოს ის ფორმა, რომელშიც ის გადავა აპარატურაზე.
და აქ ყველა საშუალება კარგია (არა): CLI, NETCONF, RESTCONF, SNMP უბრალოდ.

ამიტომ, ჩვენ დაგვჭირდება დრაივერი, რომელიც გადასცემს წინა ნაბიჯის შედეგს კონკრეტული გამყიდველის საჭირო ფორმატში: CLI ბრძანებების ნაკრები, XML სტრუქტურა.

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

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

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (თუმცა ეს არის გამორჩეული, რადგან ეს არის FIB მიწოდების საშუალება და არა პარამეტრები)

მოდით წერტილით t ​​არის აქ. CLI არის მემკვიდრეობა. SNMP... ხველა ხველა.
RESTCONF ჯერ კიდევ უცნობი ცხოველია; REST API თითქმის არავის აქვს მხარდაჭერილი. ამიტომ, სერიაში NETCONF-ზე გავამახვილებთ ყურადღებას.

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

მეორედა რა ინსტრუმენტებით გავაკეთებთ ამას?
აქ ასევე დიდი არჩევანია:

• თვითნაწერი სცენარი ან პლატფორმა. შევიარაღოთ ncclient-ით და asyncIO-ით და ყველაფერი თავად გავაკეთოთ. რა დაგვიჯდება განლაგების სისტემის ნულიდან აშენება?
• Ansible ქსელის მოდულების მდიდარი ბიბლიოთეკით.
• მარილი თავისი მწირი მუშაობით ქსელთან და კავშირი ნაპალმთან.
• სინამდვილეში ნაპალმი, რომელიც იცნობს რამდენიმე გამყიდველს და ეს არის ის, ნახვამდის.
• ნორნირი კიდევ ერთი ცხოველია, რომელსაც მომავალში გავკვეთთ.

აქ ფავორიტი ჯერ არ არის შერჩეული - ჩვენ ვიძიებთ.

კიდევ რა არის აქ მნიშვნელოვანი? კონფიგურაციის გამოყენების შედეგები.
წარმატებულია თუ არა. ჯერ კიდევ არის წვდომა აპარატურაზე თუ არა?
როგორც ჩანს, commit დაგეხმარებათ დადასტურებასა და დადასტურებაში, რაც ჩამოტვირთულია მოწყობილობაში.
ეს, NETCONF-ის სწორ განხორციელებასთან ერთად, მნიშვნელოვნად ავიწროებს შესაფერისი მოწყობილობების დიაპაზონს - არც თუ ისე ბევრი მწარმოებელი მხარს უჭერს ნორმალურ ვალდებულებებს. მაგრამ ეს მხოლოდ ერთ-ერთი წინაპირობაა კონკურსი. საბოლოო ჯამში, არავის აწუხებს, რომ არც ერთი რუსი გამყიდველი არ დააკმაყოფილებს 32*100GE ინტერფეისის პირობას. ან ის აწუხებს?

კომპონენტი 8. CI/CD

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

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

CI/CD ნიშნავს უწყვეტი ინტეგრაცია, უწყვეტი განლაგება. ეს არის მიდგომა, რომლის დროსაც გუნდი არა მხოლოდ აქვეყნებს ახალ ძირითად გამოშვებას ყოველ ექვს თვეში ერთხელ, მთლიანად ანაცვლებს ძველს, არამედ რეგულარულად შემოაქვს (განლაგება) ახალ ფუნქციებს მცირე ნაწილებში, რომელთაგან თითოეული ყოვლისმომცველი ტესტირებაა თავსებადობის, უსაფრთხოებისა და შესრულება (ინტეგრაცია).

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

გამართვის ბრძანებების გარდა, ქსელში აბსოლუტურად ყველა ცვლილება უნდა გაიაროს CI/CD Pipeline - ეს არის ჩვენი გარანტია მშვიდი ცხოვრებისა და ხანგრძლივი, ბედნიერი კარიერისა.

კომპონენტი 9. სარეზერვო და ანომალიების გამოვლენის სისტემა

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

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

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

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

კომპონენტი 10. მონიტორინგის სისტემა

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

განვითარებადი აზრი CI/CD პროცესის ორგანული ნაწილია. კონფიგურაციის ქსელში გადატანის შემდეგ, ჩვენ უნდა შევძლოთ განვსაზღვროთ, არის თუ არა ახლა ყველაფერი წესრიგში.
ჩვენ ვსაუბრობთ არა მხოლოდ და არა იმდენად ინტერფეისის გამოყენების გრაფიკზე ან კვანძის ხელმისაწვდომობაზე, არამედ უფრო დახვეწილ საკითხებზე - საჭირო მარშრუტების არსებობაზე, მათზე ატრიბუტებზე, BGP სესიების რაოდენობაზე, OSPF მეზობლებზე, ბოლოდან ბოლომდე შესრულებაზე. ზედმეტ სერვისებზე.
შეწყდა თუ არა გარე სერვერზე syslogs-ის დამატება, ან დაიშალა SFlow აგენტი, ან რიგებში წვეთები დაიწყო ზრდა, ან დაიშალა კავშირი რამდენიმე წყვილ პრეფიქსს შორის?

ამას ცალკე სტატიაში განვიხილავთ.

დასკვნა

საფუძვლად მე ავირჩიე მონაცემთა ცენტრის ქსელის ერთ-ერთი თანამედროვე დიზაინი - L3 Clos Fabric მარშრუტიზაციის პროტოკოლად BGP.
ამჯერად ჩვენ ავაშენებთ ქსელს Juniper-ზე, რადგან ახლა JunOs ინტერფეისი არის vanlove.

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

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

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

სასარგებლო ბმულები

• სანამ სერიალში ჩავუღრმავდებით, ღირს ნატაშა სამოილენკოს წიგნის წაკითხვა პითონი ქსელის ინჟინრებისთვის. და იქნებ გაიაროს რა თქმა უნდა.
• წაკითხვაც სასარგებლო იქნება RFC პიტერ ლაპუხოვის მიერ Facebook-დან მონაცემთა ცენტრის ქარხნების დიზაინის შესახებ.
• არქიტექტურის დოკუმენტაცია მოგცემთ წარმოდგენას, თუ როგორ მუშაობს Overlay SDN. ვოლფრამის ქსოვილი (ყოფილი Open Contrail).

Გმადლობთ

რომის ხეობა. კომენტარებისა და რედაქტირებისთვის.
არტიომ ჩერნობაი. KDPV-სთვის.

წყარო: www.habr.com