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 тұрақты ток, 250-ге жуық қосқыш, жарты ондаған маршрутизатор және бірнеше желіаралық қалқан бар.
Facebook емес, бірақ автоматтандыру туралы терең ойлануға жеткілікті.
Дегенмен, егер сізде 1 құрылғыдан көп болса, автоматтандыру қажет деген пікір бар.
Шындығында, қазір кез келген адам кем дегенде тізе сценарийлерінсіз өмір сүре алатынын елестету қиын.
Мен Excel бағдарламасында IP мекенжайлары сақталатын кеңселер бар екенін және мыңдаған желілік құрылғылардың әрқайсысы қолмен конфигурацияланғанын және өзінің бірегей конфигурациясына ие екенін естідім. Мұны, әрине, заманауи өнер деп санауға болады, бірақ инженердің сезімі ренжітетіні сөзсіз.

Мақсаттары

Енді біз ең абстрактілі мақсаттарды қоямыз:

• Желі біртұтас организм сияқты
• Конфигурация сынағы
• Желі күйінің нұсқасы
• Қызметтердің мониторингі және өзін-өзі сауықтыру

Кейінірек осы мақалада біз қандай құралдарды қолданатынымызды қарастырамыз, ал келесіде мақсаттар мен құралдарды егжей-тегжейлі қарастырамыз.

Желі біртұтас организм сияқты

Серияның анықтаушы фразасы, бірақ бір қарағанда маңызды емес болып көрінуі мүмкін: біз жеке құрылғыларды емес, желіні конфигурациялаймыз.
Соңғы жылдары біз желіні біртұтас нысан ретінде қарастыруға баса назар аударылғанын байқадық, сондықтан Бағдарламалық жасақтамамен анықталған желі, Мақсатқа негізделген желілер и Автономды желілер.
Ақыр соңында, қолданбаларға ғаламдық желіден не қажет: 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 терминінің өзі, нақты айтқанда, көп нәрсені қамтиды.

Біздің мақсаттарымыз үшін біз оған құрылғы туралы келесі ақпаратты сақтаймыз:

• Тауар нөмірі
• Тақырып/сипаттама
• Үлгі (Huawei CE12800, Juniper QFX5120 және т.б.)
• Сипаттама параметрлері (тақталар, интерфейстер және т.б.)
• Рөл (Жапырақ, омыртқа, шекара маршрутизаторы және т.б.)
• Орналасқан жері (аймақ, қала, деректер орталығы, тірек, блок)
• Құрылғылар арасындағы өзара байланыстар
• Желілік топология

Мұның бәрін өзіміз білгіміз келетіні анық.
Бірақ бұл автоматтандыру мақсатында көмектеседі ме?
Әрине.
Мысалы, біз Leaf қосқыштарындағы берілген деректер орталығында, егер ол Huawei болса, белгілі бір трафикті сүзу үшін ACL VLAN желісінде, ал Juniper болса, физикалық интерфейстің 0 блогында қолданылуы керек екенін білеміз.
Немесе аймақтағы барлық шекараларға жаңа Syslog серверін шығару керек.

Онда біз виртуалды желі құрылғыларын сақтаймыз, мысалы, виртуалды маршрутизаторлар немесе түбірлік рефлекторлар. Біз DNS серверлерін, NTP, Syslog және жалпы желіге қандай да бір түрде қатысты барлық нәрсені қоса аламыз.

2-компонент: IP кеңістігін басқару жүйесі

Иә, бүгінгі күні Excel файлындағы префикстер мен IP мекенжайларын қадағалайтын адамдар тобы бар. Бірақ қазіргі заманғы тәсіл әлі де nginx/apache, API интерфейсі және IP мекенжайлары мен VRF-ге бөлінген желілерді жазуға арналған кеңейтілген функциялары бар дерекқор болып табылады.
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...)
• Және т.б.

Мұны қалай нақты жасаймыз, мен әлі білмеймін. Біз оны бөлек мақалада қарастырамыз.

Егер өмірге жақынырақ болса, біз мұны сипаттай аламыз
Жапырақ қосқышында барлық қосылған 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. Жеткізушіге арналған драйвер интерфейсі

Бір күні цисканы Juniper сияқты конфигурациялауға болады деп үміттеніп, оларға дәл сол қоңырауларды жіберу арқылы өзіңізді мақтанбауыңыз керек. Ақ жәшіктердің танымалдылығының артуына және NETCONF, RESTCONF, OpenConfig қолдауының пайда болуына қарамастан, бұл хаттамалар беретін нақты мазмұн жеткізушіден сатушыға ерекшеленеді және бұл олардың бәсекелестік айырмашылықтарының бірі, олар оңай бас тартпайды.
Бұл NorthBound интерфейсі ретінде RestAPI бар 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 дұрыс орындалуымен үйлескенде, қолайлы құрылғылардың ауқымын айтарлықтай тарылтады - көптеген өндірушілер қалыпты міндеттемелерді қолдамайды. Бірақ бұл алғышарттардың бірі ғана RFP. Ақыр соңында, бірде-бір ресейлік жеткізуші 32 * 100GE интерфейсінің шартын орындамайды деп ешкім алаңдамайды. Әлде ол уайымдап жатыр ма?

Құрамдас 8. CI/CD

Осы кезде бізде барлық желілік құрылғылар үшін конфигурация дайын.
Мен «бәрі үшін» деп жазамын, өйткені біз желі күйінің нұсқасы туралы айтып отырмыз. Тіпті бір қосқыштың параметрлерін өзгерту қажет болса да, өзгерістер бүкіл желі үшін есептеледі. Әлбетте, олар көптеген түйіндер үшін нөлге тең болуы мүмкін.

Бірақ, жоғарыда айтылғандай, біз бәрін тікелей өндіріске айналдырғысы келетін варварлар емеспіз.
Жасалған конфигурация алдымен Pipeline CI/CD арқылы өтуі керек.

CI/CD үзіліссіз интеграция, үздіксіз орналастыру дегенді білдіреді. Бұл команда әр алты ай сайын жаңа негізгі шығарылымды шығарып қана қоймай, ескісін толығымен ауыстырып қана қоймайды, сонымен қатар шағын бөліктерде жаңа функционалдылықты жүйелі түрде (Орналастыру) енгізеді, олардың әрқайсысы үйлесімділік, қауіпсіздік және өнімділік (Интеграция).

Мұны істеу үшін бізде конфигурация өзгерістерін бақылайтын нұсқаларды басқару жүйесі, клиенттік қызметтің бұзылғанын тексеретін зертхана, осы фактіні тексеретін бақылау жүйесі және соңғы қадам - ​​өндіріс желісіне өзгертулерді тарату.

Түзету пәрмендерін қоспағанда, желідегі барлық өзгерістер CI/CD құбыры арқылы өтуі керек - бұл біздің тыныш өмірдің және ұзақ, бақытты мансаптың кепілі.

Компонент 9. Сақтық көшірме және аномалияларды анықтау жүйесі

Сақтық көшірмелер туралы қайта айтудың қажеті жоқ.
Біз оларды жай ғана тәжге немесе конфигурацияның өзгеру фактісіне сәйкес git ішіне қоямыз.

Бірақ екінші бөлігі қызықтырақ - біреу осы сақтық көшірмелерді қадағалап отыруы керек. Кейбір жағдайларда бұл біреу барып, бәрін бұрынғыдай айналдыруы керек, ал басқаларында біреуге бірдеңе дұрыс емес деп мияулауы керек.
Мысалы, айнымалыларда тіркелмеген жаңа пайдаланушы пайда болса, оны бұзудан алып тастау керек. Егер брандмауэрдің жаңа ережесіне қол тигізбеу жақсы болса, мүмкін біреу жөндеуді қосты немесе жаңа қызмет, бунглер ережелерге сәйкес тіркелмеген шығар, бірақ адамдар оған қосылып қойған.

Кез келген автоматтандыру жүйелеріне және басқарудың болат қолына қарамастан, біз әлі де бүкіл желі масштабындағы кейбір шағын дельтадан құтыла алмаймыз. Мәселелерді түзету үшін ешкім жүйеге конфигурация қоспайды. Оның үстіне, олар тіпті конфигурация үлгісіне қосылмауы мүмкін.

Мысалы, мәселені локализациялау үшін белгілі бір IP үшін пакеттер санын санауға арналған брандмауэр ережесі мүлдем кәдімгі уақытша конфигурация болып табылады.

Компонент 10. Мониторинг жүйесі

Басында мен мониторинг тақырыбын ашқым келмеді - бұл әлі де көлемді, даулы және күрделі тақырып. Бірақ іс алға жылжыған сайын бұл автоматтандырудың ажырамас бөлігі екені белгілі болды. Ал оны айналып өту тіпті тәжірибесіз мүмкін емес.

Дамушы ой CI/CD процесінің органикалық бөлігі болып табылады. Конфигурацияны желіге таратқаннан кейін біз қазір бәрі дұрыс екенін анықтауымыз керек.
Біз интерфейсті пайдалану кестелері немесе түйіндердің қолжетімділігі туралы ғана емес, сонымен қатар неғұрлым нәзік нәрселер туралы - қажетті маршруттардың болуы, олардағы атрибуттар, BGP сеанстарының саны, OSPF көршілері, End-to-End өнімділігі туралы айтып отырмыз. үстеме қызметтер.
Сыртқы серверге арналған жүйе журналдары қосылуды тоқтатты ма, әлде SFlow агенті бұзылды ма, немесе кезектердегі құлдыраулар өсе бастады ма, әлде кейбір префикстер жұбы арасындағы байланыс үзілді ме?

Бұл туралы жеке мақалада қарастырамыз.

қорытынды

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

Тек Open Source құралдарын және көп жеткізушілер желісін пайдалану арқылы өмірімізді қиындатайық - сондықтан Juniper-тен басқа, мен жолда тағы бір бақытты адамды таңдаймын.

Алдағы басылымдардың жоспары келесідей:
Алдымен виртуалды желілер туралы айтамын. Біріншіден, мен қалаймын, екіншіден, онсыз инфрақұрылым желісінің дизайны өте айқын болмайды.
Содан кейін желі дизайнының өзі туралы: топология, маршруттау, саясаттар.
Зертханалық стенд құрастырайық.
Бұл туралы ойланайық және құрылғыны желіде инициализациялауды үйренейік.
Содан кейін әрбір компонент туралы егжей-тегжейлі.

Иә, мен бұл циклды дайын шешіммен әдемі аяқтауға уәде бермеймін. 🙂

Пайдалы сілтемелер

• Серияға кіріспес бұрын Наташа Самойленконың кітабын оқыған жөн Желі инженерлеріне арналған Python. Және, мүмкін, өтеді курс.
• Сондай-ақ оқу пайдалы болады RFC Петр Лапуховтың Facebook-тен деректер орталығы зауыттарының дизайны туралы.
• Архитектуралық құжаттама сізге Overlay SDN қалай жұмыс істейтіні туралы түсінік береді. Вольфрам мата (бұрынғы Open Contrail).

Рақмет сізге

Рим шатқалы. Түсініктемелер мен өңдеулер үшін.
Артем Чернобай. KDPV үшін.

Ақпарат көзі: www.habr.com