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

Хей Хабр!

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

Отказ от отговорност

Нашите основни инструменти за автоматизация са Ansible (като инструмент за автоматизация) и Git (като хранилище за Ansible playbooks). Бих искал незабавно да направя уговорка, че това не е уводна статия, в която говорим за логиката на Ansible или Git и обясняваме основни неща (например какво представляват ролевите модули, инвентарни файлове, променливи в Ansible или какво се случва, когато въвеждате командите git push или git commit). Тази история не е за това как можете да практикувате Ansible и да конфигурирате NTP или SMTP на вашето оборудване. Това е история за това как можете бързо и за предпочитане да разрешите мрежов проблем без грешки. Също така е препоръчително да имате добро разбиране за това как работи мрежата, по-специално какво представлява протоколният стек TCP/IP, OSPF, BGP. Също така ще премахнем избора на Ansible и Git от уравнението. Ако все пак трябва да изберете конкретно решение, силно препоръчваме да прочетете книгата „Програмируемост и автоматизация на мрежата. Умения за мрежов инженер от следващо поколение“ от Джейсън Еделман, Скот С. Лоу и Мат Осуалт.

Сега към точката.

Проблем изявление

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

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

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

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

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

Благодаря ти, Джаки.

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

Нека оставим нашата мрежа брато с тъжните му мисли за малко.

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

Предлагаме следния ред на представяне на материала

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

Мрежова схема и описание

Схемата

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

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

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

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

1. Два гранични рутера (BRD-01, BRD-02);
2. Клъстер на защитната стена (FW-CLUSTER);
3. Основен превключвател (L3-CORE);
4. Рутер, който ще се превърне в спасение (докато решим проблема, ще прехвърлим мрежовите настройки от FW-CLUSTER на EMERGENCY) (EMERGENCY);
5. Суичове за управление на мрежова инфраструктура (L2-MGMT);
6. Виртуална машина с Git и Ansible (VM-AUTOMATION);
7. Лаптоп, на който се извършва тестване и разработване на книги за игри за Ansible (Laptop-Automation).

Мрежата е конфигурирана с динамичен OSPF протокол за маршрутизиране със следните области:

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

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

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

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

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

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

• Разрешаваме интерфейси при СПЕШНИ СИТУАЦИИ;
• Ние конфигурираме външния IP адрес (за NAT), който е бил на FW-Cluster;
• Ние генерираме gARP заявки, така че мак адресите в L3-CORE arp таблиците да се променят от FW-Cluster на EMERGENCY;
• Ние регистрираме маршрута по подразбиране като статичен към BRD-01, BRD-02;
• Създайте NAT правила;
• Издигане до АВАРИЙНА OSPF зона 1;
• Издигане до АВАРИЙНА OSPF зона 2;
• Променяме цената на маршрутите в зона 1 на 10;
• Променяме цената на маршрута по подразбиране в Зона 1 на 10;
• Ние променяме IP адресите, свързани с L2-MGMT (на тези, които са били на FW-CLUSTER);
• Ние генерираме gARP заявки, така че мак адресите в L2-MGMT arp таблиците да се променят от FW-CLUSTER на EMERGENCY.

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

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


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

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

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

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

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

PLAY [------->Emergency on VCF] ********************************************************

TASK [vcf_junos_emergency_on : Disable PROD interfaces to FW-CLUSTER] *********************
changed: [vcf]

PLAY [------->Emergency on MGMT-CORE] ************************************************

TASK [mgmt_junos_emergency_on : Disable MGMT interfaces to FW-CLUSTER] ******************
changed: [m9-03-sw-03-mgmt-core]

PLAY [------->Emergency on] ****************************************************

TASK [mk_routeros_emergency_on : Enable EXT-INTERNET interface] **************************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Generate gARP for EXT-INTERNET interface] ****************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Enable static default route to EXT-INTERNET] ****************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Change NAT rule to EXT-INTERNET interface] ****************
changed: [m9-04-r-04] => (item=12)
changed: [m9-04-r-04] => (item=14)
changed: [m9-04-r-04] => (item=15)
changed: [m9-04-r-04] => (item=16)
changed: [m9-04-r-04] => (item=17)

TASK [mk_routeros_emergency_on : Enable OSPF Area 1 PROD] ******************************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Enable OSPF Area 2 MGMT] *****************************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Change OSPF Area 1 interfaces costs to 10] *****************
changed: [m9-04-r-04] => (item=VLAN-1001)
changed: [m9-04-r-04] => (item=VLAN-1002)
changed: [m9-04-r-04] => (item=VLAN-1003)
changed: [m9-04-r-04] => (item=VLAN-1004)
changed: [m9-04-r-04] => (item=VLAN-1005)
changed: [m9-04-r-04] => (item=VLAN-1006)
changed: [m9-04-r-04] => (item=VLAN-1007)
changed: [m9-04-r-04] => (item=VLAN-1008)
changed: [m9-04-r-04] => (item=VLAN-1009)
changed: [m9-04-r-04] => (item=VLAN-1010)
changed: [m9-04-r-04] => (item=VLAN-1011)
changed: [m9-04-r-04] => (item=VLAN-1012)
changed: [m9-04-r-04] => (item=VLAN-1013)
changed: [m9-04-r-04] => (item=VLAN-1100)

TASK [mk_routeros_emergency_on : Change OSPF area1 default cost for to 10] ******************
changed: [m9-04-r-04]

TASK [mk_routeros_emergency_on : Change MGMT interfaces ip addresses] ********************
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})

TASK [mk_routeros_emergency_on : Generate gARPs for MGMT interfaces] *********************
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n.254', u'name': u'VLAN-803'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+1.254', u'name': u'VLAN-805'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+2.254', u'name': u'VLAN-807'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+3.254', u'name': u'VLAN-809'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+4.254', u'name': u'VLAN-820'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+5.254', u'name': u'VLAN-822'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+6.254', u'name': u'VLAN-823'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+7.254', u'name': u'VLAN-824'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+8.254', u'name': u'VLAN-850'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+9.254', u'name': u'VLAN-851'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+10.254', u'name': u'VLAN-852'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+11.254', u'name': u'VLAN-853'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+12.254', u'name': u'VLAN-870'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+13.254', u'name': u'VLAN-898'})
changed: [m9-04-r-04] => (item={u'ip': u'х.х.n+14.254', u'name': u'VLAN-899'})

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

Готово!

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

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

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

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

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

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

Данни

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

• Осигуряване на устройство;
• Събиране на данни;
• Отчитане;
• Отстраняване на неизправности;
• Спазването.

При интерес можем да продължим дискусията по някоя от зададените теми.

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

• Системата трябва да живее без човек, докато се подобрява от човек. Системата не трябва да зависи от хората;
• Операцията трябва да е експертна. Няма клас специалисти, които изпълняват рутинни задачи. Има експерти, които са автоматизирали цялата рутина и решават само сложни проблеми;
• Рутинните стандартни задачи се извършват автоматично „с едно натискане на бутон“, без да се губят ресурси. Резултатът от такива задачи винаги е предвидим и разбираем.

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

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

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


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