ProHoster > Блог > Администриране > Автоматизация на мрежите. Случай от живота

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

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

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

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

Основните инструменти за автоматизация, които имаме, са 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 часа през нощта, спите дълбоко и виждате сънища. Обаждане на телефона. Звъни техническият директор:

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

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

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

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

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

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

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

Да оставим настрана нашия мрежов брат с тъжните му мисли.

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

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

  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. Лаптоп, на който се извършват тестовете и разработката на 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:

  1. Изключваме интерфейсите на ядровия превключвател (L3-CORE), които го свързват с FW-CLUSTER;
  2. Изключваме интерфейсите на ядровия превключвател L2-MGMT, които го свързват с FW-CLUSTER;
  3. Настройваме рутера 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 таблиците от FW-CLUSTER на EMERGENCY.

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

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

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

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

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

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

След това четем резултатите от изпълнените операции на playbook-a Ansible (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 към живот. Това е основното оборудване, а не резервното, на него трябва да работи мрежата.

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

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

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

Изводи

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

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

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

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

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

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

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

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


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

Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри 🔥 Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри | ProHoster