🥇Автоматизация на мрежата. Случай от живота

Здравейте, Хабр!

В тази статия ще говорим за автоматизацията на мрежовата инфраструктура. Ще бъде представена работна схема на мрежа, която функционира в една малка, но много горда компания. Всички съвпадения с реално мрежово оборудване са случайни. Ще разгледаме случай, който се е случил в тази мрежа и който е могъл да доведе до спиране на бизнеса за дълго време и сериозни финансови загуби. Решението на този случай много добре се вписва в концепцията за „Автоматизация на мрежовата инфраструктура“. С помощта на автоматизационни средства ще покажем как може ефективно да се решават сложни задачи в кратки срокове и ще размислим по въпроса защо е по-уместно тези задачи да се решават именно по този начин, а не иначе (през конзолата).

Отказ

Основните инструменти за автоматизация, които използваме, са Ansible (като средство за автоматизация) и Git (като хранилище на playbook-ове на Ansible). Веднага искам да подчертая, че това не е запознаваща статия, в която говорим за логиката на работа на Ansible или Git и обясняваме основни неща (например какво представляват ролите, модулите или променливите в Ansible, или какво се случва при изпълнението на командите git push или git commit). Това не е история за това как можете да упражнявате Ansible, да настроите NTP или SMTP на оборудването. Това е история за това как бързо и желательно без грешки да се решава мрежов проблем. Също така, е желателно да имате добро разбиране за това как работи мрежата, по-специално какво представлява стекът от протоколи TCP/IP, OSPF, BGP. Изборът на Ansible и Git също ще оставим извън обсъждане. Ако все още се колебаете при избора на конкретно решение, настоятелно ви препоръчваме да прочетете книгата „Network Programmability and Automation. Skills for the Next-Generation Network Engineer“ от Jason Edelman, Scott S. Lowe и Matt Oswalt.

Сега да преминем към същността.

Формулиране на задачата

Представете си ситуация: 3 часа през нощта, дълбоко спите и сънувате. Телефонен звън. Обажда се техническият директор:

— Да?
— ###, ####, #####, клъстерът на защитните стени е паднал и не се вдига!!!
Вие търкате очи, опитвате се да осъзнаете какво се случва и да си представите как такова нещо изобщо е могло да се случи. Чува се как директорът разкъсва косата си и той моли да му се обадите отново, защото по втората линия му звъни генералният директор.

След половин час събрахте първоначалната информация от дежурния екип, събудихте всички, които можеха да бъдат събудени. В крайна сметка техническият директор не е излъгал, всичко е истина, основният клъстер от междусетеви защити е паднал и никакви основни действия не го връщат в норма. Всички услуги, които предлага компанията, не работят.

Изберете проблем по ваш вкус, всеки ще си спомни нещо свое. Например, след нощна актуализация и при липса на голямо натоварване всичко работеше добре и всички доволни отидоха да спят. Появи се трафик и буферите на интерфейсите започнаха да се запълват поради бъг в драйвера на мрежовата карта.

Ситуацията може добре да се опише от Джеки Чан.

Благодарим, Джеки.

Не е много приятна ситуация, нали?

Да оставим за момента нашия мрежов приятел с тъгата си.

Да обсъдим как ще се развиват събитията нататък.

Предлагаме следния ред на изложение на материала

Да разгледаме схемата на мрежата и да разберем как работи;
Да опишем как прехвърляме настройки от един рутер на друг с помощта на Ansible;
Да поговорим за автоматизацията на ИТ инфраструктурата като цяло.

Схема на мрежата и нейното описание

Схема

Да разгледаме логическата схема на нашата организация. Няма да назоваваме конкретни производители на оборудване, в контекста на статията това е без значение. (Внимателният читател сам ще се досети какво оборудване се използва). Това е един от хубавите плюсове на работата с Ansible; при настройката ни в общи линии не ни интересува какво оборудване е. Просто за разбиране, това оборудване е от известни производители като Cisco, Juniper, Check Point, Fortinet, Palo Alto... можете да вмъкнете вашия вариант.

Имаме две основни задачи по прехвърляне на трафика:

Да осигурим публикуването на нашите услуги, които представляват бизнеса на компанията;
Да осигурим свързаност с клоновете, отдалечените центрове за данни и трети организации (партньори и клиенти), както и изхода на клоновете в интернет през централния офис.

Да започнем с основните елементи:

Два гранични маршрутизатора (BRD-01, BRD-02);
Клъстер от междусетеви защити (FW-CLUSTER);
Комутатор на ядро (L3-CORE);
Рутер, който ще стане спасителен кръг (в хода на решението на проблема ще прехвърлим мрежовите настройки от FW-CLUSTER на EMERGENCY) (EMERGENCY);
Комутатори за управление на мрежовата инфраструктура (L2-MGMT);
Виртуална машина с Git и Ansible (VM-AUTOMATION);
Ноутбук, на който се извършва тестване и разработка на playbook-и за Ansible (Laptop-Automation).

В мрежата е настроен динамичен маршрутизиращ протокол OSPF с следните области:

Област 0 – зона, в която са включени рутери, отговарящи за преноса на трафик в зоната EXCHANGE;
Област 1 – зона, в която са включени рутери, отговарящи за работата на услугите на компанията;
Област 2 – зона, в която са включени рутери, отговарящи за маршрутизиране на management-трафика;
Област N – области на филиалните мрежи.

На граничните рутери е създаден виртуален рутер (VRF-INTERNET), на който е повдигнат eBGP full view с присвоен AS. Между VRF-ите е настроен iBGP. Компанията разполага с пул от бели адреси, които се публикуват на тези VRF-INTERNET. Част от белите адреси се маршрутизират директно към FW-CLUSTER (адресите, на които работят услугите на компанията), друга част се маршрутизира през зоната EXCHANGE (вътрешни услуги на компанията, изискващи външни IP адреси, и външни адреси NAT за офисите). След това трафикът попада на виртуалните рутери, създадени на L3-CORE с бели и сиви адреси (зони на безопасност).

В Management-сет, се използват специализирани комутатори и представляват физически отделена мрежа. Management мрежата също е разделена на зони на безопасност.
Рутерът EMERGENCY физически и логически дублира FW-CLUSTER. На него са изключени всички интерфейси, освен тези, които са свързани с management-сет.

Автоматизация и нейното описание

Разгледахме как работи мрежата. Сега ще преминем стъпка по стъпка, какво ще направим, за да пренасочим трафика от FW-CLUSTER към EMERGENCY:

Изключваме интерфейсите на ядрения комутатор (L3-CORE), които го свързват с FW-CLUSTER;
Изключваме интерфейсите на ядрения комутатор L2-MGMT, които го свързват с FW-CLUSTER;
Настройваме рутера EMERGENCY (по подразбиране на него са изключени всички интерфейси, освен тези, свързани с L2-MGMT):

Включваме интерфейсите на EMERGENCY;
Настройваме външния IP адрес (за NAT), който беше на FW-Cluster;
Генерираме gARP заявки, за да се променят MAC адресите в ARP таблиците на L3-CORE от FW-Cluster на EMERGENCY;
Записваме статичен маршрут по подразбиране до BRD-01, BRD-02;
Създаваме правила за NAT;
Повдигаме OSPF Area 1 на EMERGENCY;
Повдигаме OSPF Area 2 на EMERGENCY;
Променяме цената на маршрутите в Area 1 на 10;
Променяме цената на дефолтния маршрут в Area 1 на 10;
Променяме IP адресите, свързани с L2-MGMT (за тези, които бяха на FW-CLUSTER);
Генерираме gARP заявки, за да се сменят MAC адресите в arp таблиците на L2-MGMT от FW-CLUSTER на EMERGENCY.

Отново се връщаме към първоначалната задача. Три сутринта, огромен стрес, грешка на който и да е етап може да доведе до нови проблеми. Готови ли сте да въвеждате команди чрез CLI? Да? Ок, идете поне измийте лицето, изпийте кафе и съберете волята си.
Брюс, моля, помогни на момчетата.

А ние продължаваме да развиваме нашата автоматизация.
По-долу е представена схемата на работа на playbook-а в термини на Ansible. Тази схема отразява това, което описахме по-горе, просто вече е конкретна реализация в Ansible.

На този етап осъзнахме, че трябва да се направи нещо, разработихме playbook, проведохме тестове, сега сме готови да го стартираме.

Още едно малко лирично отклонение. Леснотата на разказа не трябва да ви заблуждава. Процесът на написване на playbook-и не беше прост и бърз, както може да изглежда. Тестовете отнеха доста време, създаден беше виртуален стенд, решението беше многократно тествано, проведени бяха около 100 теста.

Стартираме… Има усещане, че всичко се случва много бавно, някъде има грешка, нещо в крайна сметка няма да сработи. Усещането е сякаш скачаш с парашут, а парашутът не иска да се отвори веднага… това е нормално.

След това четем резултатите от изпълнението на операциите на playbook-а Ansible (IP адресите поради конфиденциалност са заменени):

[xxx@emergency ansible]$ ansible-playbook -i /etc/ansible/inventories/prod_inventory.ini /etc/ansible/playbooks/emergency_on.yml 

PLAY [------->Спешна помощ на VCF] ********************************************************

TASK [vcf_junos_emergency_on : Деактивиране на PROD интерфейси към FW-CLUSTER] *********************
променено: [vcf]

PLAY [------->Спешна помощ на MGMT-CORE] ************************************************

TASK [mgmt_junos_emergency_on : Деактивиране на MGMT интерфейси към FW-CLUSTER] ******************
променено: [m9-03-sw-03-mgmt-core]

PLAY [------->Спешна помощ на] ****************************************************

TASK [mk_routeros_emergency_on : Активиране на EXT-INTERNET интерфейс] **************************
променено: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Генериране на gARP за EXT-INTERNET интерфейс] ****************
променено: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Активиране на статичен по подразбиране маршрут към EXT-INTERNET] ****************
променено: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Промяна на NAT правило за EXT-INTERNET интерфейс] ****************
променено: [m9-04-r-04] => (item=12)
променено: [m9-04-r-04] => (item=14)
променено: [m9-04-r-04] => (item=15)
променено: [m9-04-r-04] => (item=16)
променено: [m9-04-r-04] => (item=17)

TASK [mk_routeros_emergency_on : Активиране на OSPF Област 1 PROD] ******************************
променено: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Активиране на OSPF Област 2 MGMT] *****************************
променено: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Промяна на OSPF Област 1 разходи на интерфейсите до 10] *****************
променено: [m9-04-r-04] => (item=VLAN-1001)
променено: [m9-04-r-04] => (item=VLAN-1002)
променено: [m9-04-r-04] => (item=VLAN-1003)
променено: [m9-04-r-04] => (item=VLAN-1004)
променено: [m9-04-r-04] => (item=VLAN-1005)
променено: [m9-04-r-04] => (item=VLAN-1006)
променено: [m9-04-r-04] => (item=VLAN-1007)
променено: [m9-04-r-04] => (item=VLAN-1008)
променено: [m9-04-r-04] => (item=VLAN-1009)
променено: [m9-04-r-04] => (item=VLAN-1010)
променено: [m9-04-r-04] => (item=VLAN-1011)
променено: [m9-04-r-04] => (item=VLAN-1012)
променено: [m9-04-r-04] => (item=VLAN-1013)
променено: [m9-04-r-04] => (item=VLAN-1100)

TASK [mk_routeros_emergency_on : Промяна на по подразбиране разходи за OSPF област 1 до 10] ******************
променено: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Промяна на IP адресите на MGMT интерфейсите] ********************
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})

TASK [mk_routeros_emergency_on : Генериране на gARPs за MGMT интерфейсите] *********************
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
променено: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})

PLAY RECAP ************************************************************************

Готово!

Всъщност, не е съвсем готово, не забравяйте за съвместимостта на динамичните маршрутизиращи протоколи и зареждането на голямо количество маршрути в FIB. Не можем да повлияем на това. Чакаме. Вече е съвпаднало. Е, сега е готово.

А в селото Вилабаджо (което не иска да автоматизира настройката на мрежата) продължават да мият съдове. Брус (вярно, вече друг, но не по-малко готин) се опитва да разбере колко още ръчно да пренастрои оборудването.

Искам да се спра на един важен момент. Как да върнем всичко обратно? След известно време, ще възстановим нашия FW-CLUSTER. Това е основното оборудване, а не резервното, мрежата трябва да работи на него.

Чувствате ли как започва да кипи у мрежовите специалисти? Техническият директор ще чуе хиляди аргументи защо това не трябва да се прави, защо може да се направи след това. За съжаление, работата на мрежата така се оформя от купчина заплатки, парчета, остатъци от бившата лукс. Получава се пачуърк одеяло. Нашата цел по принцип, не само в тази конкретна ситуация, а като ИТ специалисти — да приведем работата на мрежата до красивата английска дума „consistency“, която има много значения, може да се преведе като: съгласуваност, непротиворечивост, логичност, слаженост, системност, съотносимост, свързаност. Всичко това го касае. Само в такова състояние мрежата е управляемо, ние ясно разбираме какво и как работи, осъзнаваме какво трябва да променим при необходимост, знаем къде да погледнем в случай на проблеми. И само в такава мрежа могат да се изпълняват трикове, подобни на тези, които описваме в момента.

В действителност беше подготвена още една playbook, която възстановява настройките в първоначалното им състояние. Логиката на нейното функциониране е същата (важно е да се помни, че редът на задачите е много важен), за да не удължаваме и без това доста дългата статия, решихме да не публикуваме листинга на изпълнението на playbook-а. Провеждайки подобни учения, ще се почувствате много по-спокойни и уверени за бъдещето, освен това всякакви импровизации, които сте направили, веднага ще се проявят.

Всички желаещи могат да ни пишат и да получат изходния код на всичко написано, заедно с всички playbooks. Контактите са в профила.

Изводи

Според нас, процесите, които могат да бъдат автоматизирани, все още не са се кристализирали. Въз основа на опита, който имаме, и темите, обсъждани от нашите западни колеги, в момента са видими следните направления:

Настройка на устройства;
Събиране на данни;
Отчитане;
Отстраняване на проблеми;
Съответствие.

Ако проявите интерес, можем да продължим обсъждането по някоя от темите.

Искам да разгледам и понятията за автоматизация. Каква трябва да бъде според нас:

Системата трябва да функционира без човешка намеса, а да се усъвършенства от човека. Системата не трябва да е зависима от човека;
Експлоатацията трябва да е експертна. Липсва клас специалисти, които да изпълняват рутинни задачи. Има експерти, които са автоматизирали цялата рутина и се справят само със сложни задачи;
Рутинните стандартни задачи се изпълняват автоматично "с натискане на бутон", без да се изразходват ресурси. Резултатът от тези задачи е винаги предсказуем и ясен.

И до какво трябва да доведат тези точки:

Прозрачност на ИТ инфраструктурата (по-малко рискове при експлотация, модернизация и внедряване. По-малко време на спиране през годината);
Възможност за планиране на ИТ ресурси (система за планиране на капацитет — видно е колко се консумира, видно е колко ресурси са необходими в единна система, а не чрез писма и разходки до ръководителите на отдели);
Възможност за намаляване на броя на обслужващия ИТ персонал.

Автори на статията: Александър Человеков (CCIE RS, CCIE SP) и Павел Кириллов. Интересуваме се да обсъждаме и предлагаме решения относно автоматизацията на ИТ инфраструктурата.

Източник: habr.com