СДСМ скончыўся, а бескантрольнае жаданне пісаць - засталося.

Доўгія гады наш брат пакутаваў ад выканання руціннай працы, крыжаваў пальцы перад комітам і не дасыпаў з-за начных ролбэкаў.
Але цёмным часам прыходзіць канец.

Гэтым артыкулам я пачну серыю аб тым, як мне бачыцца аўтаматызацыя.
Па ходзе справы разбяромся з этапамі аўтаматызацыі, захоўваннем зменных, фармалізацыяй дызайну, з RestAPI, NETCONF, YANG, YDK і будзем вельмі шмат праграмаваць.
Мне азначае, што а) гэта не аб'ектыўная ісціна, б) не безумоўна лепшы падыход у) мой погляд нават падчас руху ад першай да апошняга артыкула можа памяняцца - сапраўды кажучы, ад стадыі чарнавіка да публікацыі я перапісваў усё цалкам двойчы.

Змест

1. Мэты
   1. Сетка - як адзіны арганізм
   2. Тэставанне канфігурацыі
   3. Версіянаванне
   4. Маніторынг і самааднаўленне сэрвісаў

2. Сродкі
   1. Інвентарная сістэма
   2. Сістэма кіравання IP-прасторай
   3. Сістэма апісання сеткавых сэрвісаў
   4. Механізм ініцыялізацыі прылад
   5. Вендар-агностык канфігурацыйная мадэль
   6. Вендар-інтэрфейс спецыфічны драйвер
   7. Механізм дастаўкі канфігурацыі на прыладу
   8. CI / CD
   9. Механізм рэзервовага капіявання і пошуку адхіленняў
   10. Сістэма маніторынгу

3. Заключэнне

АДСМ я паспрабую весці ў фармаце, крыху адрозным ад СДСМ. Па-ранейшаму будуць з'яўляцца вялікія грунтоўныя нумарныя артыкулы, а паміж імі я буду публікаваць невялікія нататкі са штодзённага досведу. Пастараюся тут змагацца з перфекцыянізмам і не вылізваць кожную з іх.

Як гэта пацешна, што ў другі раз даводзіцца праходзіць адзін і той жа шлях.

Спачатку прыйшлося пісаць самому артыкулы пра сеткі з-за таго, што іх не было ў рунэце.

Цяпер я не змог знайсці ўсебаковы дакумент, які сістэматызаваў бы падыходы да аўтаматызацыі і на простых практычных прыкладах разбіраў вышэйпералічаныя тэхналогіі.

Магчыма, я памыляюся, таму, кідайце спасылкі на прыдатныя рэсурсы. Зрэшты гэта не зменіць маёй рашучасці пісаць, таму што, асноўная мэта - гэта ўсё ж такі навучыцца чамусьці самому, а аблегчыць жыццё блізкаму - гэта прыемны бонус, які лашчыць ген распаўсюджвання вопыту.

Мы паспрабуем узяць сярэдніх памераў дата-цэнтр LAN DC і прапрацаваць усю схему аўтаматызацыі.
Рабіць некаторыя рэчы я буду практычна ўпершыню разам з вамі.

У апісваных тут ідэях і прыладах я буду не арыгінальны. У Дзмітрыя Фіголя ёсць выдатны канал са стрымамі на гэтую тэму.
Артыкулы ў многіх аспектах будуць з імі перасякацца.

У LAN DC 4 ДЦ, каля 250 камутатараў, паўтузіна маршрутызатараў і пара файрвалаў.
Не фэйсбук, але дастаткова для таго, каб глыбока задумацца аб аўтаматызацыі.
Існуе, зрэшты, меркаванне, што калі ў вас больш за 1 прылады, ужо патрэбна аўтаматызацыя.
Насамрэч цяжка ўявіць, што хтосьці зараз можа жыць без хаця б пачка накаленкавых скрыптоў.
Хоць я чуў, што ёсць такія канторы, дзе ўлік IP-адрасоў вядзецца ў экселе, а кожная з тысяч сеткавых прылад наладжваецца ўручную і мае сваю непаўторную канфігурацыю. Гэта, вядома, можна выдаць за сучаснае мастацтва, але пачуцці інжынера сапраўды будуць абражаны.

Мэты

Цяпер мы паставім максімальна абстрактныя мэты:

• Сетка - як адзіны арганізм
• Тэставанне канфігурацыі
• Версіянаванне стану сеткі
• Маніторынг і самааднаўленне сэрвісаў

Пазней у гэтым артыкуле разбяром якія будзем выкарыстоўваць сродкі, а ў наступных і мэты і сродкі ў падрабязнасцях.

Сетка - як адзіны арганізм

Вызначальная фраза цыклу, хоць на першы погляд яна можа здацца не такой ужо значнай: мы будзем наладжваць сетку, а не асобныя прылады.
Усе апошнія гады мы назіраем зрух акцэнтаў да таго, каб звяртацца з сеткай, як з адзінай сутнасцю, адсюль і якія прыходзяць у наша жыццё Праграмнае забеспячэнне сетак, Intent Driven Networks и Autonomous Networks.
Бо што глабальна трэба прыкладанням ад сеткі: складнасці паміж кропкамі А і Б (ну часам +У-Я) і ізаляцыі ад іншых прыкладанняў і карыстальнікаў.

І такім чынам, наша задача ў гэтай серыі. выбудаваць сістэму, якая падтрымлівае актуальную канфігурацыю усёй сеткі, якая ўжо дэкампануецца на актуальную канфігурацыю на кожным прыладзе ў адпаведнасці з яго роляй і месцазнаходжаннем.
Сістэма кіравання сеткай разумее, што для занясення змен мы звяртаемся ў яе, а яна ўжо ў сваю чаргу вылічае патрэбны стан для кожнай прылады і наладжвае яго.
Такім чынам мы мінімізуем амаль да нуля хаджэнне ў CLI рукамі - любыя змены ў наладах прылад або дызайне сеткі павінны быць фармалізаваны і дакументаваны - і толькі потым выкочвацца на патрэбныя элементы сеткі.

Гэта значыць, напрыклад, калі мы вырашылі, што з гэтага моманту стойкавыя камутатары ў Казані павінны анансаваць дзве сеткі замест адной, мы

1. Спачатку дакументуемы змены ў сістэмах
2. Які генеруецца мэтавую канфігурацыю ўсіх прылад сеткі
3. Запускаем праграму абнаўлення канфігурацыі сеткі, якая вылічае, што трэба выдаліць на кожным вузле, што дадаць, і прыводзіць вузлы да патрэбнага стану.

Пры гэтым рукамі мы ўносім змены толькі на першым кроку.

Тэставанне канфігурацыі

Вядома, Што 80% праблем здараюцца падчас змены канфігурацыі - ўскоснае таму сведчанне - тое, што ў перыяд навагодніх канікулаў звычайна ўсё спакойна.
Я асабіста быў сведкам дзясяткаў глабальных даунтаймаў з-за памылкі чалавека: няправільная каманда, не ў той галінцы канфігурацыі выканалі, забыліся кам'юніці, знеслі MPLS глабальна на маршрутызатары, наладзілі пяць жалязяк, а на шостай памылку не заўважылі, закаміцілі старыя змены, зробленыя іншым чалавекам . Сцэнарыяў цемра цемра.

Аўтаматыка нам дазволіць рабіць менш памылак, але ў большым маштабе. Так можна акірпіць не адна прылада, а ўсю сетку зараз.

Спрадвеку нашы дзяды правяралі правільнасць змен, якія ўносяцца вострым вокам, сталёвымі яйкамі і працаздольнасцю сеткі пасля іх выкаткі.
Тыя дзяды, чые працы прыводзілі да простай і катастрафічнай страты, пакідалі менш нашчадкаў і павінны з часам вымерці, але эвалюцыя працэс павольны, і таму да гэтага часу не ўсе папярэдне правяраюць змены ў лабараторыі.
Аднак на вастрыі прагрэсу тыя, хто аўтаматызаваў працэс тэсціравання канфігурацыі, і далейшага яе прымянення на сетку. Іншымі словамі - запазычыў працэдуру CI/CD (Continuous Integration, Continuous Deployment) у распрацоўшчыкаў.
У адной з частак мы разгледзім як рэалізаваць гэта з дапамогай сістэмы кантролю версій, верагодна, гітхаба.

Як толькі вы звыкнецеся з думкай аб сеткавым CI/CD, у раптоўна метад праверкі канфігурацыі шляхам яе ўжывання на працоўную сетку здасца вам раннесярэднявечным невуцтвам. Прыкладна як стукаць малатком па боегалоўцы.

Арганічным працягам ідэй аб сістэме кіравання сеткай і CI/CD становіцца паўнавартаснае версіяванне канфігурацыі.

Версіянаванне

Мы будзем лічыць, што пры любых зменах, нават самых малаважных, нават на адной незаўважнай прыладзе, уся сетка пераходзіць з аднаго стану ў іншы.
І мы заўсёды не выконваем каманду на прыладзе, мы мяняем стан сеткі.
Вось давайце гэтыя станы і будзем зваць версіямі?

Дапушчальны, бягучая версія - 1.0.0.
Памяняўся IP-адрас Loopback-інтэрфейсу на адным з ToR'ов? Гэта мінорная версія - атрымае нумар 1.0.1.
Перагледзелі палітыкі імпарту маршрутаў у BGP - крыху больш сур'ёзны - ужо 1.1.0
Вырашылі пазбавіцца ад IGP і перайсці толькі на BGP – гэта ўжо радыкальнае змяненне дызайну – 2.0.0.

Пры гэтым розныя ДЦ могуць мець розныя версіі - сетка развіваецца, ставіцца новае абсталяванне, дзесьці дадаюцца новыя ўзроўні спайн, дзесьці - не, ітд.

Пра семантычнае версіяванне мы пагаворым у асобным артыкуле.

Паўтаруся - любая змена (акрамя адладкавых каманд) - гэтае абнаўленне версіі. Аб любых адхіленнях ад актуальнай версіі павінны апавяшчацца адміністратары.

Тое ж самае тычыцца адкату змен - гэта не адмена апошніх каманд, гэта не rollback сіламі аперацыйнай сістэмы прылады - гэта прывядзенне ўсёй сеткі да новай (старой) версіі.

Маніторынг і самааднаўленне сэрвісаў

Гэта відавочная задача ў сучасных сетках выходзіць на новы ўзровень.
Часцяком у вялікіх сэрвіс-правайдэраў практыкуецца падыход, што які ўпаў сэрвіс трэба вельмі хутка дабіць і падняць новы, замест таго, каб разбірацца, што адбылося.
"Вельмі" азначае, што з усіх бакоў трэба багата абмазацца маніторынгамі, якія на працягу секунд выявяць найменшыя адхіленні ад нормы.
І тут ужо мала звыклых метрык, накшталт загрузкі інтэрфейсу або даступнасці вузла. Недастаткова і ручнога сачэння дзяжурнага за імі.
Для многіх рэчаў увогуле павінен быць Самалячэнне - маніторынгі запаліліся чырвоным і пайшлі самі трыпутнік прыклалі, дзе баліць.

І тут мы таксама маніторым не толькі асобныя прылады, але і здароўе сеткі цалкам, прычым як вайтбокс, што параўнальна зразумела, так і блэкбокс, што ўжо складаней.

Што нам спатрэбіцца для рэалізацыі такіх амбіцыйных планаў?

• Мець спіс усіх прылад у сетцы, іх размяшчэнне, ролі, мадэлі, версіі ПЗ.
  kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3.
• Мець сістэму апісання сеткавых сэрвісаў.
  IGP, BGP, L2/3VPN, Policy, ACL, NTP, SSH.
• Умець ініцыялізаваць прыладу.
  Hostname, Mgmt IP, Mgmt Route, Users, RSA-Keys, LLDP, NETCONF
• Наладжваць прыладу і прыводзіць канфігурацыю да патрэбнай (у тым ліку старой) версіі.
• Тэставаць канфігурацыю
• Перыядычна правяраць стан усіх прылад на прадмет адыходжання ад актуальнага і паведамляць каму трэба.
  Уначы хтосьці ціхенька дадаў правіла ў ACL.
• Сачыць за працаздольнасцю.

Сродкі

Гучыць дастаткова складана для таго, каб пачаць дэкампазіраваць праект на кампаненты.

І будзе іх дзесяць:

1. Інвентарная сістэма
2. Сістэма кіравання IP-прасторай
3. Сістэма апісання сеткавых сэрвісаў
4. Механізм ініцыялізацыі прылад
5. Вендар-агностык канфігурацыйная мадэль
6. Вендар-інтэрфейс спецыфічны драйвер
7. Механізм дастаўкі канфігурацыі на прыладу
8. CI / CD
9. Механізм рэзервовага капіявання і пошуку адхіленняў
10. Сістэма маніторынгу

Гэта, дарэчы, прыклад таго, як змяняўся погляд на мэты цыклу - у чарнавіку кампанентаў было 4.

На ілюстрацыі я адлюстраваў усе кампаненты і ўласна прылада.
Перасякальныя кампаненты ўзаемадзейнічаюць аднаму з адным.
Чым больш блок, тым больш увагі трэба надаць гэтаму кампаненту.

Кампанент 1. Інвентарная сістэма

Відавочна, мы хочам ведаць, якое абсталяванне, дзе стаіць, да чаго падключана.
Інвентарная сістэма - неад'емная частка любога прадпрыемства.
Часцей за ўсё для сеткавых прылад прадпрыемства мае асобную інвентарную сістэму, якая вырашае больш спецыфічныя задачы.
У рамках цыклу артыкулаў мы будзем называць гэта DCIM – Data Center Infrastructure Management. Хоць сам тэрмін DCIM, строга кажучы, уключае ў сябе значна больш.

Для нашых задач у ёй мы будзем захоўваць наступную інфармацыю пра прыладу:

• інвентарны нумар
• Назва/апісанне
• Мадэль (Huawei CE12800, Juniper QFX5120 ітд)
• Характэрныя параметры (платы, інтэрфейсы і г.д.)
• Роля (Leaf, Spine, Border Router і т.д.)
• Лакацыю (рэгіён, горад, дата-цэнтр, стойка, юніт)
• Інтэрканекты паміж прыладамі
• Тапалогію сеткі

Выдатна зразумела, што нам самім жадаецца ведаць усё гэта.
Але ці дапаможа гэта ў мэтах аўтаматызацыі?
Безумоўна.
Напрыклад, мы ведаем, што ў дадзеным дата-цэнтры на Leaf-камутатарах, калі гэта Huawei, ACL для фільтрацыі вызначанага трафіку павінны ўжывацца на VLAN, а калі гэта Juniper – то на unit 0 фізічнага інтэрфейсу.
Або трэба раскаціць новы Syslog-сервер на ўсе бордэры рэгіёна.

У ёй жа мы будзем захоўваць віртуальныя сеткавыя прылады, напрыклад віртуальныя маршрутызатары ці рут-рэфлектары. Можам дадаць DNS-сервера, NTP, Syslog і наогул усё, што так ці інакш адносіцца да сеткі.

Кампанент 2. Сістэма кіравання IP-прасторай

Так, і ў наш час знаходзяцца калектывы людзей, якія вядуць улік прэфіксаў і IP-адрасоў у Excel-файле. Але сучасны падыход – гэта ўсё ж база дадзеных, з франтэндам на nginx/apache, API і шырокімі функцыямі па ўліку IP-адрасоў і сетак з падзелам на VRF.
IPAM - IP Address Management.

Для нашых задач у ёй мы будзем захоўваць наступную інфармацыю:

• VLAN
• VRF
• Сеткі/Падсеткі
• IP-адрасы
• Прывязка адрасоў да прылад, сетак да лакацый і нумарам VLAN

Ізноў жа зразумела, што мы жадаем быць упэўненыя, што, вылучаючы новы IP-адрас для лупбэка ToR'а, мы не спатыкнемся пра тое, што ён ужо быў камусьці прызначаны. Або што адзін і той жа прэфікс мы выкарыстоўвалі двойчы ў розных канцах сеткі.
Але як гэта дапаможа ў аўтаматызацыі?
Лёгка.
Запытваем у сістэме прэфікс з роляй 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-камутатараў толькі сеткі з вызначанага прэфікса. Абмяжоўваць CoPP IPv6 ND да 10 pps і т.д.
У сваю чаргу спайны трымаюць сесіі са ўсімі падлучанымі станікамі, выступаючы ў якасці рут-рэфлектараў, і прымаюць ад іх толькі маршруты вызначанай даўжыні і з вызначаным камуніці.

Кампанент 4. Механізм ініцыялізацыі прылады

Пад гэтым загалоўкам я аб'ядноўваю мноства дзеянняў, якія павінны адбыцца, каб прылада з'явілася на радарах і на яго можна было патрапіць выдалена.

1. Завесці прыладу ў інвентарнай сістэме.
2. Вылучыць IP-адрас кіравання.
3. Наладзіць базавы доступ на яго:
   Hostname, IP-адрас кіравання, маршрут у сетку кіравання, карыстальнікі, SSH-ключы, пратаколы - telnet/SSH/NETCONF

Тут існуе тры падыходы:

• Цалкам усё ўручную. Прыладу прывозяць на стэнд, дзе звычайны арганічны чалавек, завядзе яго ў сістэмы, падключыцца кансоллю і настроіць. Можа спрацаваць на невялікіх статычных сетках.
• ZTP – Zero Touch Provisioning. Жалеза прыехала, устала, па DHCP атрымала сабе адрас, схадзіла на спецыяльны сервер, саманаладзілася.
• Інфраструктура кансольных сервераў, дзе першасная настройка адбываецца праз кансольны порт у аўтаматычным рэжыме.

Пра ўсе тры пагаворым у асобным артыкуле.

Кампанент 5. Вендар-агностык канфігурацыйная мадэль

Да гэтага часу ўсе сістэмы былі разрозненымі лапікамі, якія даюць зменныя і дэкларатыўнае апісанне таго, што мы хацелі б бачыць на сеткі. Але рана ці позна, давядзецца мець справу з канкрэтыкай.
На гэтым этапе для кожнай пэўнай прылады прымітывы, сэрвісы і зменныя камбінуюцца ў канфігурацыйную мадэль, фактычна якая апісвае поўную канфігурацыю пэўнай прылады, толькі ў вендаранезалежнай манеры.
Што дае гэты крок? Чаму б адразу не фармаваць канфігурацыю прылады, якую можна проста заліць?
Насамрэч гэта дазваляе вырашыць тры задачы:

1. Не падладжвацца пад пэўны інтэрфейс узаемадзеяння з прыладай. Будзь то CLI, NETCONF, RESTCONF, SNMP – мадэль будзе аднолькавай.
2. Не трымаць колькасць шаблонаў/скрыптоў па колькасці вендараў у сетцы, і ў выпадку змены дызайну, змяняць адно і тое ж у некалькіх месцах.
3. Загружаць канфігурацыю з прылады (бэкапу), раскладваць яе ў сапраўды такую ​​ж мадэль і непасрэдна параўноўваць паміж сабой мэтавую канфігурацыю і наяўную для вылічэння дэльты і падрыхтоўкі канфігурацыйнага патча, які зменіць толькі тыя часткі, якія неабходна або для выяўлення адхіленняў.

У выніку гэтага этапу мы атрымліваем вендаранезалежную канфігурацыю.

Кампанент 6. Вендар-інтэрфейс спецыфічны драйвер

Не варта цешыць сябе надзеямі на тое, што калісьці наладжваць цыску можна будзе сапраўды гэтак жа, як джуніпер, проста даслаўшы на іх абсалютна аднолькавыя выклікі. Нягледзячы на ​​якія набіраюць папулярнасць whitebox'ы і на з'яўленне падтрымкі NETCONF, RESTCONF, OpenConfig, пэўны кантэнт, які гэтымі пратаколамі дастаўляецца, адрозніваецца ад вендара да вендара, і гэта адно з іх канкурэнтных адрозненняў, якое яны так проста не здадуць.
Гэта прыкладна сапраўды гэтак жа, як OpenContrail і OpenStack, якія маюць RestAPI у якасці свайго NorthBound-інтэрфейсу, чакаюць зусім розныя выклікі.

Такім чынам, на пятым кроку вендаранезалежная мадэль павінна прыняць тую форму, у якой яна паедзе на жалеза.
І тут усе сродкі добрыя (не): 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 з яго багатай бібліятэкай сеткавых модуляў.
• Salt з яго беднай працай з сеткай і звязкам з Napalm.
• Уласна Napalm, які ведае пару вендараў і ўсё, да спаткання.
• Nornir - яшчэ адзін звярок, якога мы прэпаруем ў будучыні.

Тут яшчэ фаварыт не выбраны - будзем шупаць.

Што тут яшчэ важна? Наступствы прымянення канфігурацыі.
Паспяхова ці не. Застаўся доступ на жалязяку ці не.
Здаецца, тут дапаможа commit з пацверджаннем і валідацыяй таго, што ў прыладу загрузілі.
Гэта ў сукупнасці з правільнай рэалізацыяй NETCONF значна звужае кола падыходных прылад - нармальныя коміты падтрымліваюць не так шмат вытворцаў. Але гэта проста адна з абавязковых умоў у RFP. У выніку ніхто не хвалюецца, што ні адзін расійскі вендар не пройдзе пад умову 32*100GE інтэрфейсу. Ці перажывае?

Кампанент 8. CI/CD

Да гэтага моманту ў нас ужо гатова канфігурацыя на ўсе прылады сеткі.
Я пішу "на ўсё", таму што мы гаворым пра версіяванне стану сеткі. І нават калі трэба памяняць налады ўсяго толькі аднаго світача, пралічваюцца змены для ўсёй сеткі. Відавочна, яны могуць быць пры гэтым нулявымі для большасці вузлоў.

Але, як ужо было сказана, вышэй, мы ж не варвары нейкія, каб каціць усё адразу ў прод.
Згенераваная канфігурацыя павінна спачатку мінуць праз Pipeline CI/CD.

CI/CD азначае Continuous Integration, Continuous Deployment. Гэта падыход, пры якім каманда не раз у паўгода выкладвае новы мажорны рэліз, цалкам замяняючы стары, а рэгулярна інкрыментальна ўкараняе (Deployment) новую функцыянальнасць невялікімі порцыямі, кожную з якіх усебакова тэстуе на сумяшчальнасць, бяспека і працаздольнасць (Integration).

Для гэтага ў нас ёсць сістэма кантролю версій, сачыльная за зменамі канфігурацыі, лабараторыя, на якой правяраецца не ці ламаецца кліенцкі сэрвіс, сістэма маніторынгу, якая правярае гэты факт, і апошні крок - выкатка змен у працоўную сетку.

За выключэннем адладачных каманд, абсалютна ўсе змены на сетцы павінны прайсці праз CI/CD Pipeline - гэта наш заклад спакойнага жыцця і доўгай шчаслівай кар'еры.

Кампанент 9. Сістэма рэзервовага капіявання і пошуку адхіленняў

Ну пра бэкапы лішні раз казаць не прыходзіцца.
Будзем проста іх па кроне ці па факце змены канфігурацыі ў гіт складаць.

А вось другая частка цікавейшая - за гэтымі бэкапамі хтосьці павінен даглядаць. І ў адных выпадках гэты нехта павінен пайсці і круціць усё як было, а ў іншых, мяўкнуць каму-небудзь, аб тым, што непарадак.
Напрыклад, калі з'явіўся нейкі новы карыстач, які не прапісаны ў зменных, трэба ад хаку далей яго выдаліць. А калі новае файрвольнае правіла — лепш не чапаць, магчыма нехта проста адладку ўключыў, а можа новы сэрвіс, няўклюда, не па рэгламенце прапісаў, а ў яго ўжо людзі пайшлі.

Ад нейкай невялікай дэльты ў маштабах усёй сеткі мы ўсё роўна не сыдзем, нягледзячы на ​​любыя сістэмы аўтаматызацыі і сталёвую руку кіраўніцтва. Для адладкі праблем усё роўна ніхто канфігурацыю не будзе ўносіць у сістэмы. Тым больш што іх можа нават не прадугледжваць мадэль канфігурацыі.

Напрыклад, файрвольнае правіла для падліку колькасці пакетаў на пэўны IP, для лакалізацыі праблемы - цалкам радавая часовая канфігурацыя.

Кампанент 10. Сістэма маніторынгу

Спачатку я не збіраўся асвятляць тэму маніторынгу - усё ж аб'ёмная, спрэчная і складаная тэма. Але па ходзе справы аказалася, што гэта неад'емная частка аўтаматызацыі. І абысці яе бокам хаця б нават без практыкі нельга.

Развіваючы думку - гэта арганічная частка працэсу CI / CD. Пасля выкаткі канфігурацыі на сетку, нам трэба ўмець вызначыць, а ці ўсё з ёй зараз у парадку.
І гаворка не толькі і не столькі аб графіках выкарыстання інтэрфейсаў або даступнасці вузлоў, колькі аб больш тонкіх рэчах – наяўнасці патрэбных маршрутаў, атрыбутаў на іх, колькасці BGP-сесій, OSPF-суседзяў, End-to-End працаздольнасці вышэйлеглых сэрвісаў.
А не ці перасталі складацца сіслогі на вонкавы сервер, а не ці зламаўся ці SFlow-агент, а не ці пачалі расці дропы ў чэргах, а не ці парушылася складнасць паміж якой-небудзь парай прэфіксаў?

У асобным артыкуле мы паразважаем і над гэтым.

Заключэнне

У якасці асновы я абраў адзін з сучасных дызайнаў датацэнтравай сеткі – L3 Clos Fabric з BGP у якасці пратакола маршрутызацыі.
Будаваць сетку мы будзем на гэты раз на Juniper, таму што зараз інтэрфейс JunOs - гэта ванлаў.

Ускладнім сабе жыццё выкарыстаннем толькі Open Source прылад і мультывендорнай сеткай - таму акрамя джуніпер па ходзе справы абяру яшчэ аднаго шчасліўчыка.

План бліжэйшых публікацый прыкладна такі:
Спачатку я раскажу пра віртуальныя сеткі. У першую чаргу, таму што мне жадаецца, а ў другую, таму што без гэтага дызайн інфраструктурнай сеткі будзе не вельмі зразумелы.
Потым уласна пра дызайн сеткі: тапалогію, маршрутызацыю, палітыкі.
Збяром лабараторны стэнд.
Паразважаем і, можа, папрактыкуемся ў ініцыялізацыі прылады ў сетцы.
А далей пра кожны кампанент у інтымных падрабязнасцях.

І так, я не абяцаю хупава скончыць гэты цыкл гатовым рашэннем. 🙂

Карысныя спасылкі

• Перад тым, як паглыбляцца ў серыю, варта пачытаць кнігу Наташы Самойленкі. Python для сеткавых інжынераў. А, магчыма, і прайсці курс.
• Карысным будзе таксама пачытаць RFC пра дызайн датацэнтравых фабрык ад Фэйсбука за аўтарствам Пятра Лапухова.
• Аб тым, як працуе Overlay'ны SDN вам дасць уяўленне дакументацыя па архітэктуры Tungsten Fabric (раней Open Contrail).

Дзякуй

Раман Горга. За каментары і праўкі.
Арцём Чарнабай. За КДПВ.

Крыніца: habr.com