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гө жакын өчүргүч, жарым ондогон роутер жана бир нече брандмауэр бар.
Facebook эмес, бирок автоматташтыруу жөнүндө терең ойлонууга жетиштүү.
Бирок, эгер сизде 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 дареги өзгөрдүбү? Бул кичинекей версия болуп саналат жана 1.0.1 номери болот.
Биз BGPге каттамдарды импорттоо саясатын кайра карап чыктык - бир аз олуттуураак - буга чейин 1.1.0
Биз IGPден арылууну жана BGPге гана өтүүнү чечтик - бул дизайндын радикалдуу өзгөрүшү - 2.0.0.

Ошол эле учурда, ар кандай ДКлар ар кандай версияларга ээ болушу мүмкүн - тармак өнүгүп жатат, жаңы жабдуулар орнотулууда, омурткалардын жаңы деңгээли башка жерде эмес, бир жерде кошулууда жана башкалар.

боюнча семантикалык версиялоо биз өзүнчө макалада сүйлөшөбүз.

Кайталап айтам - бардык өзгөртүүлөр (мүчөлөрдү оңдоо буйруктарынан тышкары) бул версияны жаңыртуу. Администраторлор учурдагы версиядан ар кандай четтөөлөр жөнүндө кабардар болушу керек.

Ошол эле өзгөрүүлөрдү артка кайтарууга да тиешелүү - бул акыркы буйруктарды жокко чыгаруу эмес, бул түзмөктүн иштөө тутумун колдонуу менен артка кайтаруу эмес - бул бүт тармакты жаңы (эски) версияга алып барат.

Мониторинг жана кызматтардын өзүн-өзү айыктыруу

Бул езун-езу тушунуктуу милдет азыркы кездеги тармактарда жацы децгээлге чыкты.
Көбүнчө чоң кызмат көрсөтүүчүлөр эмне болгонун түшүнүүнүн ордуна, иштебей калган кызматты тез арада оңдоо жана жаңысын көтөрүү керек деген ыкманы колдонушат.
"Абдан" дегенди билдирет, сиз бир нече секунданын ичинде нормадан кичине четтөөлөрдү байкай турган мониторинг менен бардык тараптан марттык менен капталган болушуңуз керек.
Бул жерде интерфейсти жүктөө же түйүндүн жеткиликтүүлүгү сыяктуу кадимки көрсөткүчтөр жетишсиз. Аларды нөөмөтчүнүн кол менен көзөмөлдөөсү да жетишсиз.
Көп нерселер үчүн болушу керек Өзүн-өзү айыктыруу — мониторинг чырактары кызыл күйүп, ооруган жерине өзүбүз барып плантанды сүйкөдүк.

Жана бул жерде биз жеке түзмөктөрдү гана эмес, ошондой эле бүт тармактын ден соолугуна, салыштырмалуу түшүнүктүү ак кутуга да, татаалыраак кара кутуга да көз салып турабыз.

Мындай амбициялуу пландарды ишке ашыруу үчүн бизге эмне керек?

• Тармактагы бардык түзмөктөрдүн тизмеси, алардын жайгашкан жери, ролдору, моделдери, программалык камсыздоо версиялары бар.
  kazan-leaf-1.lmu.net, Казан, жалбырак, Juniper QFX 5120, R18.3.
• Тармактык кызматтарды сыпаттоо системасы бар.
  IGP, BGP, L2/3VPN, Саясат, ACL, NTP, SSH.
• Аппаратты инициализациялоо мүмкүнчүлүгүнө ээ болуңуз.
  Хост аты, Mgmt IP, Mgmt маршруту, колдонуучулар, RSA-ачкычтар, LLDP, NETCONF
• Аппаратты конфигурациялаңыз жана конфигурацияны керектүү (анын ичинде эски) версиясына алып келиңиз.
• Сыноо конфигурациясы
• Мезгил-мезгили менен бардык түзмөктөрдүн абалын учурдагылардан четтөөлөр үчүн текшерип, кимге билдирүү керек.
  Түн ичинде кимдир бирөө акырын ACLге эреже кошту.
• Мониторинг аткаруу.

каражаттар

Долбоорду компоненттерге бөлүп баштоо үчүн бул татаал угулат.

Жана алар он болот:

1. Инвентаризация системасы
2. IP мейкиндигин башкаруу системасы
3. Тармактык кызматтын сыпаттоо системасы
4. Түзмөктү инициализациялоо механизми
5. Сатуучу-агностикалык конфигурация модели
6. Сатуучуга тиешелүү драйвер интерфейси
7. Конфигурацияны аппаратка жеткирүү механизми
8. CI / CD
9. Резервдик көчүрүү жана четтөөлөрдү издөө механизми
10. Мониторинг системасы

Айтмакчы, бул циклдин максаттарына көз караш кандайча өзгөргөндүгүнө мисал – долбоордо 4 компонент бар болчу.

Сүрөттө мен бардык компоненттерди жана аппараттын өзүн чагылдырдым.
Кесилишкен компоненттер бири-бири менен өз ара аракеттенишет.
Блок канчалык чоң болсо, бул компонентке ошончолук көп көңүл буруу керек.

1-компонент: Инвентаризация системасы

Албетте, биз кайсы жабдуулар кайда жайгашканын, эмнеге кошулганын билгибиз келет.
Инвентаризация системасы ар бир ишкананын ажырагыс бөлүгү болуп саналат.
Көбүнчө ишканада тармактык түзүлүштөр үчүн өзүнчө инвентаризация системасы бар, ал конкреттүү маселелерди чечет.
Бул макалалар сериясынын алкагында биз аны DCIM - Маалымат борборунун инфраструктурасын башкаруу деп атайбыз. DCIM термининин өзү, тагыраак айтканда, дагы көп нерсени камтыйт.

Биздин максаттар үчүн биз андагы түзмөк тууралуу төмөнкү маалыматты сактайбыз:

• жолу саны
• Title/Description
• үлгү (Huawei CE12800, Juniper QFX5120 ж.б.)
• Мүнөздүү параметрлер (такталар, интерфейстер ж.б.)
• Рол (Leaf, Spine, Border Router, ж.)
• Жайгашкан жери (аймак, шаар, маалымат борбору, стойка, бирдик)
• Түзмөктөрдүн ортосундагы байланыштар
• Тармак топологиясы

Мунун бардыгын биз өзүбүз билгибиз келгени айдан ачык.
Бирок бул автоматташтыруу максатында жардам береби?
шексиз.
Мисалы, биз Leaf которгучтарындагы берилген маалымат борборунда, эгер ал Huawei болсо, белгилүү бир трафикти чыпкалоо үчүн ACL VLANда, ал эми Juniper болсо, физикалык интерфейстин 0 бирдигинде колдонулушу керек экенин билебиз.
Же жаңы Syslog серверин аймактагы бардык чектерге жайылтышыңыз керек.

Анда биз виртуалдык тармак түзмөктөрүн сактайбыз, мисалы виртуалдык роутерлор же тамыр чагылдыргычтар. Биз DNS серверлерин, NTP, Syslog жана жалпысынан тигил же бул тармакка тиешелүү нерселердин бардыгын кошо алабыз.

2-компонент: IP мейкиндигин башкаруу системасы

Ооба, бүгүнкү күндө Excel файлында префикстерди жана IP даректерди көзөмөлдөгөн адамдардын топтору бар. Бирок заманбап ыкма дагы эле маалымат базасы болуп саналат, nginx/apache, API жана VRFдерге бөлүнгөн IP даректерди жана тармактарды жаздыруу үчүн кеңири функциялар бар.
IPAM - IP даректи башкаруу.

Биздин максаттар үчүн биз анда төмөнкү маалыматты сактайбыз:

• VLANлар
• VRF
• Тармактар/субсеталар
• IP даректери
• Даректерди түзмөктөргө, тармактарды жерлерге жана VLAN номерлерине байланыштыруу

Дагы бир жолу, биз ToR цикли үчүн жаңы IP дарегин бөлгөнүбүздө, анын кимдир-бирөөнө дайындалганына мүдүрүлбөй турганыбызга ынангыбыз келет. Же бир эле префиксти тармактын ар кайсы учтарында эки жолу колдонгонбуз.
Бирок бул автоматташтырууга кандай жардам берет?
Окшош.
Биз системада Loopbacks ролу бар префиксти сурайбыз, анда бөлүштүрүү үчүн жеткиликтүү IP даректер камтылган - эгерде ал табылса, даректи бөлүштүрөбүз, эгерде жок болсо, жаңы префикс түзүүнү суранабыз.
Же аспаптын конфигурациясын түзүүдө биз VRF интерфейси жайгашкан системадан биле алабыз.
Жана жаңы серверди ишке киргизгенде, скрипт системага кирип, сервер кайсы коммутатордо экенин, кайсы порт жана интерфейске кайсы подтармак дайындалганын табат жана андан сервердин дарегин бөлүп берет.

Бул DCIM менен IPAMды бир системага айкалыштыруу каалоосун көрсөтүп турат, бул функцияларды кайталабоо жана эки окшош объектиге кызмат кылбоо.
Мына ушундай кылабыз.

Компонент 3. Тармактык кызматтарды сыпаттоо системасы

Эгерде биринчи эки тутум кандайдыр бир жол менен дагы эле колдонулушу керек болгон өзгөрмөлөрдү сактаса, үчүнчүсү ар бир түзмөктүн ролу үчүн аны кантип конфигурациялоо керектигин сүрөттөйт.
Бул тармактык кызматтардын эки башка түрүн айырмалоо керек:

• Инфраструктура
• Кардар.

Биринчилери негизги байланышты жана түзмөктү башкарууну камсыз кылуу үчүн иштелип чыккан. Аларга VTY, SNMP, NTP, Syslog, AAA, маршруттук протоколдор, CoPP ж.
Акыркысы кардар үчүн кызматты уюштурат: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP, ж.б.
Албетте, чек ара учурлары да бар - MPLS LDP, BGP кайда кирет? Ооба, ошондой эле маршруттук протоколдорду кардарлар үчүн колдонсо болот. Бирок бул маанилүү эмес.

Кызматтардын эки түрү тең конфигурация примитивдерине бөлүнөт:

• физикалык жана логикалык интерфейстер (teg/anteg, mtu)
• IP даректер жана VRF (IP, IPv6, VRF)
• ACL жана трафикти иштетүү саясаттары
• Протоколдор (IGP, BGP, MPLS)
• Багыттоо саясаттары (префикс тизмелери, жамааттар, ASN чыпкалары).
• Коммуналдык кызматтар (SSH, NTP, LLDP, Syslog...)
• Жана башкалар.

Муну кантип так аткарабыз, азырынча так маалыматым жок. Биз аны өзүнчө макалада карап чыгабыз.

Эгер жашоого бир аз жакыныраак болсо, анда биз муну сүрөттөп бере алабыз
Leaf которгучу бардык туташкан Spine которгучтары менен BGP сеанстарына ээ болушу керек, туташкан тармактарды процесске импорттоо жана Spine которгучтарынан белгилүү бир префикстен гана тармактарды кабыл алуу керек. 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. Сатуучуга тиешелүү драйвер интерфейси

Качандыр бир күнү цисканы арчадай кылып конфигурациялоо мүмкүн болот деген үмүт менен кошомат кылбашыңыз керек, жөн гана аларга дал ушундай чалууларды жөнөтүү менен. Ак кутучалардын популярдуулугунун өсүп жатканына жана NETCONF, RESTCONF, OpenConfig колдоонун пайда болушуна карабастан, бул протоколдор жеткирген конкреттүү мазмун сатуучудан сатуучуга айырмаланат жана бул алардын атаандаштык айырмачылыктарынын бири, алар оңой эле баш тартпайт.
Бул болжол менен OpenContrail жана OpenStack менен бирдей, алардын NorthBound интерфейси катары RestAPI бар, таптакыр башка чалууларды күтүшөт.

Ошентип, бешинчи кадамда сатуучудан көз карандысыз модель аппараттык жабдыкка өтүүчү форманы алышы керек.
Жана бул жерде бардык каражаттар жакшы (жок): CLI, NETCONF, RESTCONF, SNMP жөн гана.

Ошондуктан, бизге мурунку кадамдын натыйжасын белгилүү бир сатуучунун талап кылынган форматына өткөрө турган драйвер керек болот: CLI буйруктарынын жыйындысы, XML структурасы.

Компонент 7. Конфигурацияны аппаратка жеткирүү механизми

Биз конфигурацияны түздүк, бирок аны дагы эле түзмөктөргө жеткирүү керек - жана, албетте, кол менен эмес.
Биринчиден, биз кандай транспортту колдонобуз деген суроого туш болуп жатабыз? Ал эми бүгүнкү күндө тандоо мындан ары аз эмес:

• CLI (telnet, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (бул FIB эмес, жөндөөлөрдү жеткирүүнүн жолу болгондуктан, бул өтө жогору болсо да)

Келгиле, бул жерде т тамгасын белгилейли. 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. Камдык жана аномалияларды аныктоо системасы

Ооба, кайра камдык көчүрмөлөр жөнүндө сөз кылуунун кереги жок.
Биз аларды жөн гана таажыга жараша же конфигурацияны өзгөртүү фактысына ылайык гитке киргизебиз.

Бирок, экинчи бөлүгү кызыктуураак - кимдир бирөө бул камдык көчүрмөлөрдү көз салып турушу керек. Ал эми кээ бир учурларда, бул кимдир бирөө барып, баарын мурункудай кылып бурушу керек, ал эми кээ бир учурларда, бир нерсе туура эмес болуп жатканын кимдир бирөө мияулатышы керек.
Мисалы, өзгөрмөлөргө катталбаган жаңы колдонуучу пайда болсо, аны бузукулуктан алып салышыңыз керек. Жана эгер жаңы брандмауэр эрежесине тийбей эле койсоңуз, балким, кимдир бирөө жөн эле мүчүлүштүктөрдү оңдоону күйгүзүп койгондур, же жаңы кызмат, банглер, регламентке ылайык катталбагандыр, бирок адамдар буга чейин кошулган.

Кандайдыр бир автоматташтыруу системаларына жана башкаруунун болоттон колунан келгенине карабастан, биз дагы эле бүт тармактын масштабындагы кичинекей дельтадан кутула албайбыз. Көйгөйлөрдү оңдоо үчүн, баары бир системаларга конфигурацияны эч ким кошпойт. Мындан тышкары, алар конфигурация моделине кирбей калышы мүмкүн.

Мисалы, көйгөйдү локалдаштыруу үчүн белгилүү бир IP үчүн пакеттердин санын эсептөө үчүн брандмауэр эрежеси толугу менен кадимки убактылуу конфигурация болуп саналат.

Компонент 10. Мониторинг системасы

Адегенде мен мониторинг темасын ачкан жокмун – бул дагы эле көлөмдүү, талаштуу жана татаал тема. Бирок иштин жүрүшү менен бул автоматташтыруунун ажырагыс бөлүгү экени белгилүү болду. Жана аны айланып өтүү мүмкүн эмес, атүгүл практикасыз.

Өнүгүп жаткан ой CI/CD процессинин органикалык бөлүгү. Тармакка конфигурацияны жайылткандан кийин, биз азыр баары жайында экенин аныкташыбыз керек.
Биз интерфейсти колдонуу графиги же түйүндүн жеткиликтүүлүгү жөнүндө эле эмес, анча-мынча эмес, андан да тымызын нерселер жөнүндө - керектүү маршруттардын болушу, алардагы атрибуттар, BGP сеанстарынын саны, OSPF кошуналары, End-to-End аткаруусу жөнүндө айтып жатабыз. ашыкча кызмат көрсөтүүлөр.
Сырткы серверге сислогдор кошулбай калдыбы, же SFlow агенти бузулдубу, же кезектердеги тамчылар өсө баштадыбы, же кээ бир жуп префикстердин ортосундагы байланыш бузулдубу?

Бул тууралуу өзүнчө макалада чагылдырабыз.

жыйынтыктоо

Негиз катары, мен заманбап маалымат борборлорунун тармак конструкцияларынын бирин тандап алдым - маршруттук протокол катары BGP менен L3 Clos Fabric.
Бул жолу биз тармакты Juniperге курабыз, анткени азыр JunOs интерфейси vanlove болуп саналат.

Келгиле, Open Source куралдарын жана көп сатуучу тармагын колдонуу менен жашообузду ого бетер татаалдаштыралы - ошондуктан Juniperден тышкары, мен жолдо дагы бир бактылуу адамды тандайм.

Алдыдагы басылмалардын планы төмөнкүдөй:
Биринчиден, мен виртуалдык тармактар ​​жөнүндө сөз кылам. Биринчиден, мен каалагандыктан, экинчиден, ушунусуз инфраструктуралык тармактын долбоору анча так болбойт.
Андан кийин тармак дизайнынын өзү жөнүндө: топология, маршрутизация, саясат.
Лабораториялык стендди чогулталы.
Келгиле, бул жөнүндө ойлонуп көрөлү, балким, тармакта түзмөктү инициализациялоону практикалайлы.
Анан интимдик майда-чүйдөсүнө чейин ар бир компоненти жөнүндө.

Ооба, мен бул циклди даяр чечим менен аяр аяктоого убада бербейм. 🙂

Пайдалуу шилтемелер

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

Рахмат

Рим капчыгайы. Пикирлер жана түзөтүүлөр үчүн.
Артём Чернобай. KDPV үчүн.

Source: www.habr.com