SDSM дууссан ч бичих гэсэн хяналтгүй хүсэл хэвээр байна.

Манай ах олон жилийн турш ердийн ажил хийж, ажил хийхээсээ өмнө хуруугаа завилах, шөнө бүр ухрахаас болж нойр хүрэхгүй байсан.
Гэвч харанхуй цаг үе дуусч байна.

Энэ нийтлэлээр би хэрхэн яаж хийх тухай цувралыг эхлүүлэх болно надад гэж автоматжуулалт харагдаж байна.
Замдаа бид автоматжуулалт, хувьсагчдыг хадгалах, дизайн хийх, RestAPI, NETCONF, YANG, YDK зэрэг үе шатуудыг ойлгож, маш олон програмчлал хийх болно.
Надад бол а) энэ нь объектив үнэн биш, б) энэ бол болзолгүйгээр хамгийн сайн арга биш, в) миний бодол, эхний өгүүллээс сүүлчийн өгүүлэл хүртэл шилжих явцад ч өөрчлөгдөж болно - үнэнийг хэлэхэд, төслийн шатнаас Нийтлэл, би бүх зүйлийг хоёр удаа бүрэн дахин бичсэн.

Агуулга

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-ээс олон төхөөрөмж байгаа бол автоматжуулалт аль хэдийн шаардлагатай гэсэн үзэл бодол байдаг.
Үнэндээ хэн ч одоо дор хаяж өвдөгний скриптгүйгээр амьдарч чадна гэж төсөөлөхөд хэцүү байдаг.
Хэдийгээр Excel-д IP хаяг хадгалагддаг оффисууд байдаг бөгөөд сүлжээний мянга мянган төхөөрөмж бүр гараар тохируулагдсан, өөрийн гэсэн өвөрмөц тохиргоотой байдаг гэж би сонссон. Мэдээжийн хэрэг үүнийг орчин үеийн урлаг гэж ойлгож болох ч инженерийн сэтгэлийг гомдоох нь гарцаагүй.

Зорилтууд

Одоо бид хамгийн хийсвэр зорилтуудыг тавих болно:

• Сүлжээ нь нэг организм шиг
• Тохиргооны туршилт
• Сүлжээний төлөвийн хувилбар
• Үйлчилгээг хянах, өөрийгөө эмчлэх

Энэ өгүүллийн дараа бид ямар хэрэгслийг ашиглах талаар авч үзэх бөгөөд дараа нь бид зорилго, арга хэрэгслийг нарийвчлан авч үзэх болно.

Сүлжээ нь нэг организм шиг

Цувралыг тодорхойлох хэллэг нь эхлээд харахад тийм ч чухал биш юм шиг санагдаж магадгүй юм: Бид бие даасан төхөөрөмж биш сүлжээг тохируулах болно.
Сүүлийн жилүүдэд бид сүлжээг нэг аж ахуйн нэгж гэж үзэх хандлага өөрчлөгдсөнийг харж байна. Програм хангамжаар тодорхойлогдсон сүлжээ, Зорилготой сүлжээнүүд и Автономит сүлжээнүүд.
Эцсийн эцэст, програмууд сүлжээнээс дэлхий даяар юу хэрэгтэй вэ: A ба B цэгүүдийн хоорондох холболт (заримдаа +B-Z) болон бусад програмууд болон хэрэглэгчидээс тусгаарлах.

Энэ цувралын бидний даалгавар бол ийм юм системийг бий болгох, одоогийн тохиргоог хадгалах бүхэл бүтэн сүлжээ, аль хэдийн өөрийн үүрэг, байршлын дагуу төхөөрөмж бүр дээр бодит тохиргоонд задардаг.
систем Сүлжээний удирдлага нь өөрчлөлт хийхийн тулд бид түүнтэй холбогдож, төхөөрөмж бүрийн хүссэн төлөвийг тооцоолж, тохируулдаг гэсэн үг юм.
Ийм байдлаар бид CLI-д гарын авлагын хандалтыг бараг тэг болгон бууруулж - төхөөрөмжийн тохиргоо эсвэл сүлжээний дизайн дахь аливаа өөрчлөлтийг албан ёсоор баталгаажуулж, баримтжуулсан байх ёстой - зөвхөн дараа нь шаардлагатай сүлжээний элементүүдэд шилжүүлнэ.

Жишээлбэл, хэрэв бид Казань дахь тавиурын унтраалга нь нэг биш хоёр сүлжээг зарлах ёстой гэж шийдсэн бол бид

1. Эхлээд бид системийн өөрчлөлтийг баримтжуулна
2. Бүх сүлжээний төхөөрөмжүүдийн зорилтот тохиргоог бий болгож байна
3. Бид сүлжээний тохиргоог шинэчлэх програмыг эхлүүлж, зангилаа бүр дээр юу устгах, юу нэмэх, зангилаануудыг хүссэн төлөвт оруулах шаардлагатайг тооцдог.

Үүний зэрэгцээ бид зөвхөн эхний шатанд гараар өөрчлөлт хийдэг.

Тохиргооны туршилт

Мэдэгдэж байнаАсуудлын 80% нь тохиргоог өөрчлөх үед тохиолддог - үүний шууд бус нотолгоо бол шинэ жилийн баярын үеэр бүх зүйл ихэвчлэн тайван байдаг.
Би хүний ​​буруугаас болж олон арван дэлхий даяар зогссоны гэрч болсон: буруу тушаал, тохиргоог буруу салбар дээр гүйцэтгэсэн, нийгэмлэг мартсан, MPLS-ийг чиглүүлэгч дээр дэлхий даяар устгасан, таван ширхэг техник хангамжийг тохируулсан боловч алдаа гараагүй. Зургаа дахь өдөр анзаарагдсан бол өөр хүний ​​хийсэн хуучин өөрчлөлтүүд хийгдсэн. Олон тонн хувилбар бий.

Автоматжуулалт нь бидэнд бага хэмжээний алдаа гаргах боломжийг олгоно, гэхдээ илүү өргөн цар хүрээтэй. Ингэснээр та зөвхөн нэг төхөөрөмжийг төдийгүй бүхэл бүтэн сүлжээг нэг дор хаах боломжтой.

Эрт дээр үеэс манай өвөг дээдэс нямбай нүдээр хийсэн өөрчлөлтүүд, ган бөмбөлөгүүд, сүлжээний үйл ажиллагааг өнхрүүлсний дараа зөв эсэхийг шалгадаг байв.
Ажил нь зогсолт, гамшигт алдагдалд хүргэсэн өвөө нар үр удмаа бага үлдээж, цаг хугацааны явцад үхэх ёстой боловч хувьсал нь удаан явцтай байдаг тул хүн бүр өөрчлөлтийг эхлээд лабораторид туршиж үзээгүй байна.
Гэсэн хэдий ч ахиц дэвшлийн тэргүүн эгнээнд тохиргоог шалгах үйл явцыг автоматжуулж, түүнийг сүлжээнд ашиглах цаашдын үйл ажиллагааг автоматжуулсан хүмүүс байдаг. Өөрөөр хэлбэл, би CI/CD процедурыг зээлсэн (Тасралтгүй нэгтгэх, тасралтгүй байршуулах) хөгжүүлэгчдээс.
Аль нэг хэсэгт бид үүнийг хувилбарын хяналтын систем, магадгүй Github ашиглан хэрхэн хэрэгжүүлэх талаар авч үзэх болно.

Сүлжээний CI/CD-ийн санаад дассан бол нэг шөнийн дотор тохиргоог үйлдвэрлэлийн сүлжээнд ашиглах замаар шалгах арга нь дундад зууны эхэн үеийн мунхаглал мэт санагдах болно. Байлдааны хошууг алхаар цохих шиг.

тухай санаа бодлын органик үргэлжлэл систем сүлжээний удирдлага болон CI/CD нь тохиргооны бүрэн хувилбар болж хувирдаг.

Хувилбар хийх

Аливаа өөрчлөлт, тэр ч байтугай хамгийн бага өөрчлөлтүүд, тэр ч байтугай нэг үл мэдэгдэх төхөөрөмж дээр ч гэсэн бүх сүлжээ нэг төлөвөөс нөгөөд шилждэг гэж бид таамаглах болно.
Мөн бид төхөөрөмж дээр командыг үргэлж гүйцэтгэдэггүй, сүлжээний төлөвийг өөрчилдөг.
Тэгэхээр эдгээр мужуудыг хувилбар гэж нэрлэе?

Одоогийн хувилбар нь 1.0.0 гэж бодъё.
ToR-ийн аль нэг дээрх Loopback интерфейсийн IP хаяг өөрчлөгдсөн үү? Энэ нь жижиг хувилбар бөгөөд 1.0.1 гэж дугаарлана.
Бид BGP руу маршрут импортлох бодлогыг шинэчилсэн - бага зэрэг нухацтай - аль хэдийн 1.1.0
Бид IGP-ээс салж, зөвхөн BGP рүү шилжихээр шийдсэн - энэ бол аль хэдийн дизайны эрс өөрчлөлт юм - 2.0.0.

Үүний зэрэгцээ, янз бүрийн DC-үүд өөр өөр хувилбартай байж болно - сүлжээ хөгжиж, шинэ тоног төхөөрөмж суурилуулж, шинэ түвшний нурууг хаа нэгтээ нэмж, бусад оронд биш гэх мэт.

дээр семантик хувилбар Бид тусдаа өгүүллээр ярих болно.

Би давтан хэлье - аливаа өөрчлөлт (дибаг хийх командуудаас бусад) нь хувилбарын шинэчлэлт юм. Одоогийн хувилбараас хазайсан тохиолдолд администраторуудад мэдэгдэх ёстой.

Өөрчлөлтүүдийг буцаахад мөн адил хамаарна - энэ нь сүүлийн командуудыг цуцлах биш, энэ нь төхөөрөмжийн үйлдлийн системийг ашиглан буцаах явдал биш юм - энэ нь бүх сүлжээг шинэ (хуучин) хувилбар руу авчрах явдал юм.

Үйлчилгээг хянах, өөрийгөө эмчлэх

Энэхүү бие даасан ажил нь орчин үеийн сүлжээнд шинэ түвшинд хүрсэн.
Ихэнхдээ томоохон үйлчилгээ үзүүлэгчид юу болсныг олж мэдэхийн оронд бүтэлгүйтсэн үйлчилгээг маш хурдан засч, шинээр бий болгох хэрэгтэй гэсэн арга барилыг баримталдаг.
"Маш" гэдэг нь таныг секундын дотор хэм хэмжээнээс өчүүхэн төдий хазайлтыг илрүүлэх хяналтаар бүх талаас нь өгөөмөр бүрэх хэрэгтэй гэсэн үг юм.
Энд интерфэйс ачаалах эсвэл зангилааны бэлэн байдал гэх мэт ердийн хэмжүүрүүд хангалтгүй болсон. Тэднийг жижүүрийн гараар хянах нь хангалтгүй юм.
Олон зүйлийн хувьд байх ёстой Өөрийгөө эмчлэх - хяналтын гэрэл улаан болж, тэд өөрсдөө очиж, өвдөж буй газартаа тарьсан.

Энд бид зөвхөн бие даасан төхөөрөмжүүд төдийгүй бүхэл бүтэн сүлжээний эрүүл мэнд, харьцангуй ойлгомжтой цагаан хайрцаг, илүү төвөгтэй хар хайрцаг хоёуланг нь хянадаг.

Ийм том төлөвлөгөөг хэрэгжүүлэхэд бидэнд юу хэрэгтэй вэ?

• Сүлжээнд байгаа бүх төхөөрөмжүүдийн жагсаалт, тэдгээрийн байршил, үүрэг, загвар, програм хангамжийн хувилбаруудтай байх.
  kazan-leaf-1.lmu.net, Казань, навч, Арц 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 орон зайн удирдлагын систем

Тийм ээ, өнөө үед Excel файл дахь угтвар, IP хаягийг бүртгэдэг хүмүүсийн багууд байдаг. Гэвч орчин үеийн арга барил нь nginx/apache, API, VRF-д хуваагдсан IP хаяг, сүлжээг бүртгэх өргөн цар хүрээтэй функц бүхий мэдээллийн сан хэвээр байна.
IPAM - IP хаягийн менежмент.

Бидний зорилгын үүднээс бид дараах мэдээллийг үүнд хадгалах болно.

• VLAN-ууд
• VRF
• Сүлжээ/Дэд сүлжээ
• IP хаягууд
• Хаягуудыг төхөөрөмж, сүлжээг байршил, VLAN дугаартай холбох

Дахин хэлэхэд, бид ToR давталтын шинэ IP хаягийг хуваарилахдаа энэ хаягийг хэн нэгэнд оноосон гэж эргэлзэхгүй байхыг хүсч байгаа нь тодорхой байна. Эсвэл бид сүлжээний өөр өөр төгсгөлд нэг угтварыг хоёр удаа ашигласан.
Гэхдээ энэ нь автоматжуулалтад хэрхэн тусалдаг вэ?
Хялбар
Бид хуваарилах боломжтой IP хаягуудыг агуулсан Loopbacks үүрэг бүхий угтварыг системд хүсч байна - хэрэв энэ нь олдвол бид хаягийг хуваарилна, үгүй ​​бол бид шинэ угтвар үүсгэхийг хүсч байна.
Эсвэл төхөөрөмжийн тохиргоог үүсгэх үед бид VRF интерфэйсийг байрлуулах ижил системээс олж мэдэх боломжтой.
Шинэ сервер эхлүүлэх үед скрипт нь системд нэвтэрч, сервер аль свич, аль порт, аль дэд сүлжээг интерфэйсэд хуваарилж байгааг олж мэдээд серверийн хаягийг тэндээс хуваарилах болно.

Энэ нь функцийг давхардуулахгүй, ижил төстэй хоёр байгууллагад үйлчлэхгүйн тулд DCIM болон IPAM-ийг нэг системд нэгтгэх хүсэлтэй байгааг харуулж байна.
Үүнийг л бид хийх болно.

Бүрэлдэхүүн хэсэг 3. Сүлжээний үйлчилгээг тайлбарлах систем

Хэрэв эхний хоёр систем нь ямар нэгэн байдлаар ашиглах шаардлагатай хувьсагчдыг хадгалдаг бол гурав дахь нь төхөөрөмжийн үүрэг тус бүрийг хэрхэн тохируулахыг тайлбарладаг.
Хоёр өөр төрлийн сүлжээний үйлчилгээг ялгах нь зүйтэй.

• Дэд бүтэц
• Үйлчлүүлэгч.

Эхнийх нь үндсэн холболт болон төхөөрөмжийн хяналтыг хангахад зориулагдсан. Үүнд VTY, SNMP, NTP, Syslog, AAA, чиглүүлэлтийн протоколууд, CoPP гэх мэт орно.
Сүүлийнх нь үйлчлүүлэгчдэд зориулсан үйлчилгээг зохион байгуулдаг: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP гэх мэт.
Мэдээжийн хэрэг хил хязгаарын тохиолдол бас байдаг - MPLS LDP, BGP хаана оруулах вэ? Тиймээ, чиглүүлэлтийн протоколуудыг үйлчлүүлэгчдэд ашиглаж болно. Гэхдээ энэ чухал биш.

Хоёр төрлийн үйлчилгээ нь тохиргооны командуудад задардаг:

• физик болон логик интерфейс (tag/anteg, mtu)
• IP хаяг ба VRF (IP, IPv6, VRF)
• ACL болон замын хөдөлгөөний боловсруулалтын бодлого
• Протоколууд (IGP, BGP, MPLS)
• Чиглүүлэлтийн бодлого (угтвар жагсаалт, нийгэмлэг, ASN шүүлтүүр).
• Хэрэглээний үйлчилгээ (SSH, NTP, LLDP, Syslog...)
• гэх мэт.

Бид үүнийг яг яаж хийх вэ, би одоогоор мэдэхгүй байна. Бид үүнийг тусдаа өгүүллээр авч үзэх болно.

Амьдралд жаахан ойртвол бид үүнийг дүрсэлж болно
Навч шилжүүлэгч нь бүх холбогдсон Spine шилжүүлэгчтэй BGP сессүүдтэй байх ёстой, холбогдсон сүлжээг процесст импортлох, зөвхөн нурууны шилжүүлэгчийн тодорхой угтвараас сүлжээг хүлээн авах ёстой. CoPP IPv6 ND-г 10 pps хүртэл хязгаарлах гэх мэт.
Хариуд нь нуруу нь бүх холбогдсон утаснуудтай сесс хийж, үндэс тусгагч үүрэг гүйцэтгэдэг бөгөөд тэдгээрээс зөвхөн тодорхой урттай, тодорхой нийгэмлэгтэй замыг хүлээн авдаг.

Бүрэлдэхүүн хэсэг 4: Төхөөрөмжийг эхлүүлэх механизм

Энэ гарчгийн дор би төхөөрөмж радар дээр гарч, алсаас хандах боломжтой болохын тулд хийх ёстой олон үйлдлүүдийг нэгтгэсэн.

1. Төхөөрөмжийг бараа материалын системд оруулна уу.
2. Удирдлагын IP хаягийг сонгоно уу.
3. Үүнд үндсэн хандалтыг тохируулна уу:
   Хост нэр, удирдлагын IP хаяг, удирдлагын сүлжээнд хүрэх зам, хэрэглэгчид, SSH түлхүүрүүд, протоколууд - telnet/SSH/NETCONF

Гурван арга байдаг:

• Бүх зүйл бүрэн гарын авлага юм. Төхөөрөмжийг индэр дээр авчирч, энгийн органик хүн үүнийг системд оруулж, консол руу холбож, тохируулах болно. Жижиг статик сүлжээнд ажиллах боломжтой.
• ZTP - Zero Touch Provisioning. Техник хангамж ирж, босч, DHCP-ээр хаяг хүлээн авч, тусгай серверт очиж, өөрийгөө тохируулсан.
• Автомат горимд консол портоор дамжуулан анхны тохиргоо хийдэг консол серверүүдийн дэд бүтэц.

Бид гурвын тухай тусдаа өгүүллээр ярих болно.

Бүрэлдэхүүн хэсэг 5: Худалдагч-агностик тохиргооны загвар

Өнөөг хүртэл бүх системүүд нь хувьсах хэмжигдэхүүнүүд болон сүлжээн дээр юу харахыг хүсч буйг тунхагласан тодорхойлолтоор хангадаг ялгаатай засварууд байсан. Гэхдээ эрт орой хэзээ нэгэн цагт та нарийн ширийн зүйлийг шийдвэрлэх хэрэгтэй болно.
Энэ үе шатанд тодорхой төхөөрөмж бүрийн хувьд командууд, үйлчилгээнүүд болон хувьсагчдыг зөвхөн үйлдвэрлэгчээс хамааралгүй байдлаар тодорхой төхөөрөмжийн бүрэн тохиргоог бодитоор дүрсэлсэн тохиргооны загварт нэгтгэдэг.
Энэ алхам юу хийх вэ? Та зүгээр л байршуулж болох төхөөрөмжийн тохиргоог яагаад нэн даруй үүсгэж болохгүй гэж?
Үнэн хэрэгтээ энэ нь гурван асуудлыг шийддэг:

1. Төхөөрөмжтэй харилцахын тулд тусгай интерфейстэй дасан зохицож болохгүй. CLI, NETCONF, RESTCONF, SNMP байна - загвар нь ижил байх болно.
2. Сүлжээнд байгаа үйлдвэрлэгчдийн тоогоор загвар/скриптийн тоог бүү хадгал, хэрэв дизайн өөрчлөгдсөн бол хэд хэдэн газар ижил зүйлийг өөрчил.
3. Тохиргоог төхөөрөмжөөс ачаалж (нөөц) яг ижил загварт оруулаад зорилтот тохиргоог одоо байгаа тохиргоотой шууд харьцуулж, гурвалжин тооцоог хийж, зөвхөн шаардлагатай хэсгүүдийг өөрчлөх эсвэл хазайлтыг тодорхойлох тохиргооны нөхөөсийг бэлтгэ.

Энэ үе шатны үр дүнд бид үйлдвэрлэгчээс хараат бус тохиргоог олж авдаг.

Бүрэлдэхүүн хэсэг 6. Борлуулагчийн тусгай драйверийн интерфейс

Хэзээ нэгэн цагт ciska-г яг л арц шиг тохируулах боломжтой болно гэж найдах хэрэггүй, зүгээр л тэдэн рүү яг адилхан дуудлага илгээж болно. Цагаан хайрцагны алдар нэр өсөн нэмэгдэж, NETCONF, RESTCONF, OpenConfig-ийн дэмжлэг гарч ирсэн хэдий ч эдгээр протоколуудын хүргэдэг тодорхой агуулга нь борлуулагчаас өөр өөр байдаг бөгөөд энэ нь тэдний өрсөлдөөний нэг ялгаа нь тийм ч амархан бууж өгөхгүй байх болно.
Энэ нь RestAPI-ийг NorthBound интерфэйс болгон ашигладаг OpenContrail болон OpenStack-тай бараг ижилхэн бөгөөд огт өөр дуудлага хүлээж байна.

Тиймээс тав дахь алхамд үйлдвэрлэгчээс хараат бус загвар нь техник хангамжид шилжих хэлбэрийг авах ёстой.
Энд бүх хэрэгсэл сайн байна (үгүй): 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 гэдэг нь Continuous Integration, Continuous Deployment гэсэн үгийн товчлол юм. Энэ нь багийнхан зургаан сар тутамд шинэ томоохон хувилбар гаргаж, хуучин хувилбарыг нь бүрмөсөн орлож зогсохгүй жижиг хэсгүүдэд шинэ функцуудыг үе шаттайгаар нэвтрүүлдэг (Байршуулах) арга бөгөөд тус бүр нь нийцтэй байдал, аюулгүй байдал болон гүйцэтгэл (интеграци).

Үүнийг хийхийн тулд бид тохиргооны өөрчлөлтийг хянадаг хувилбарын хяналтын системтэй, үйлчлүүлэгчийн үйлчилгээ эвдэрсэн эсэхийг шалгадаг лабораторитой, энэ баримтыг шалгадаг хяналтын системтэй бөгөөд хамгийн сүүлийн алхам бол үйлдвэрлэлийн сүлжээнд өөрчлөлт оруулах явдал юм.

Дибаг хийх командуудаас бусад тохиолдолд сүлжээнд байгаа бүх өөрчлөлтүүд нь CI/CD дамжуулах хоолойгоор дамжих ёстой - энэ нь бидний нам гүм амьдрал, урт удаан, аз жаргалтай карьерын баталгаа юм.

Бүрэлдэхүүн хэсэг 9. Нөөц болон гажиг илрүүлэх систем

За, нөөцлөлтийн талаар дахин ярих шаардлагагүй.
Бид зүгээр л титэм эсвэл тохиргооны өөрчлөлтийн дагуу тэдгээрийг git-д оруулах болно.

Гэхдээ хоёр дахь хэсэг нь илүү сонирхолтой юм - хэн нэгэн эдгээр нөөцлөлтийг ажиглах хэрэгтэй. Мөн зарим тохиолдолд энэ нь хэн нэгэн явж, бүх зүйлийг өмнөх шигээ эргүүлэх ёстой, зарим тохиолдолд ямар нэг зүйл буруу байна гэж хэн нэгэн рүү мявах ёстой.
Жишээлбэл, хэрэв хувьсагчид бүртгэгдээгүй шинэ хэрэглэгч гарч ирвэл та түүнийг хакердахаас зайлуулах хэрэгтэй. Хэрэв галт ханын шинэ дүрэмд хүрэхгүй байх нь дээр бол хэн нэгэн дибаг хийхийг асаасан эсвэл шинэ үйлчилгээ болох bungler нь журмын дагуу бүртгэгдээгүй байж магадгүй, гэхдээ хүмүүс үүнд аль хэдийн нэгдсэн байна.

Ямар ч автоматжуулалтын систем, удирдлагын ганган гарыг үл харгалзан бид бүхэл бүтэн сүлжээний хэмжээний жижиг дельтээс зугтаж чадахгүй. Асуудлыг дибаг хийхийн тулд хэн ч системд тохиргоо нэмэхгүй. Түүнээс гадна тэдгээр нь тохиргооны загварт ороогүй байж магадгүй юм.

Жишээлбэл, асуудлыг нутагшуулахын тулд тодорхой IP-д ногдох пакетуудын тоог тоолох галт ханын дүрэм нь ердийн түр зуурын тохиргоо юм.

Бүрэлдэхүүн хэсэг 10. Хяналтын систем

Эхлээд би мониторингийн сэдвийг хөндөхгүй байсан - энэ нь одоо ч гэсэн асар том, маргаантай, төвөгтэй сэдэв хэвээр байна. Гэвч байдал ахих тусам энэ нь автоматжуулалтын салшгүй хэсэг болох нь тодорхой болсон. Дадлага хийхгүйгээр ч гэсэн үүнийг тойрч гарах боломжгүй юм.

Хөгжиж буй сэтгэлгээ нь CI/CD үйл явцын органик хэсэг юм. Тохиргоог сүлжээнд шилжүүлсний дараа бид одоо бүх зүйл хэвийн байгаа эсэхийг тодорхойлох боломжтой байх ёстой.
Бид зөвхөн интерфэйсийн ашиглалтын хуваарь эсвэл зангилааны хүртээмжийн талаар төдийгүй илүү нарийн зүйлсийн талаар ярьж байна - шаардлагатай маршрутууд, тэдгээрийн шинж чанарууд, BGP сешнүүдийн тоо, OSPF хөршүүд, төгсгөлийн гүйцэтгэлийн талаар далд үйлчилгээ.
Гадны серверт syslog-ууд нэмэгдэхээ больсон уу, эсвэл SFlow агент эвдэрсэн үү, эсвэл дарааллын уналт нэмэгдэж эхлэв үү, эсвэл зарим хос угтваруудын холболт тасарсан уу?

Бид энэ талаар тусдаа нийтлэлд тусгах болно.

дүгнэлт

Үүний үндэс болгон би орчин үеийн мэдээллийн төвийн сүлжээний загваруудын нэг болох BGP бүхий L3 Clos Fabric-ийг чиглүүлэлтийн протокол болгон сонгосон.
Энэ удаад бид Juniper дээр сүлжээг байгуулах болно, учир нь одоо JunOs интерфейс нь vanlove юм.

Зөвхөн Нээлттэй эхийн хэрэгслүүд болон олон үйлдвэрлэгчийн сүлжээг ашиглан амьдралаа улам хүндрүүлцгээе - тиймээс би Арцаас гадна өөр нэг азтай хүнийг сонгох болно.

Удахгүй хэвлэх төлөвлөгөө нь дараах байдалтай байна.
Эхлээд би виртуал сүлжээний талаар ярих болно. Нэгдүгээрт, би хүсч байгаа учраас, хоёрдугаарт, үүнгүйгээр дэд бүтцийн шугам сүлжээний зураг төсөл тийм ч тодорхой биш байх болно.
Дараа нь сүлжээний дизайны тухай: топологи, чиглүүлэлт, бодлого.
Лабораторийн стенд угсарцгаая.
Энэ талаар бодож үзээд төхөөрөмжийг сүлжээнд эхлүүлэх дасгал хийж магадгүй.
Дараа нь бүрэлдэхүүн хэсэг бүрийн талаар нарийн ширийн зүйл.

Тийм ээ, би энэ мөчлөгийг бэлэн шийдлээр сайхан дуусгана гэж амлахгүй байна. 🙂

Ашигтай холбоосууд

• Цуврал руу орохын өмнө Наташа Самойленкогийн номыг унших нь зүйтэй Сүлжээний инженерүүдэд зориулсан Python. Тэгээд магадгүй өнгөрөх Мэдээж хэрэг.
• Унших нь бас ашигтай байх болно RFC Фэйсбүүкээс Петр Лапуховын дата төвийн үйлдвэрүүдийн дизайны тухай.
• Архитектурын баримт бичиг нь Overlay SDN хэрхэн ажилладаг талаар ойлголт өгөх болно. Гянт болд даавуу (өмнө нь Open Contrail).

Баярлалаа

Ромын хавцал. Сэтгэгдэл болон засварын хувьд.
Артём Чернобай. KDPV-ийн хувьд.

Эх сурвалж: www.habr.com