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

Еј Хабр!

Во оваа статија би сакале да зборуваме за автоматизација на мрежната инфраструктура. Ќе биде претставен работен дијаграм на мрежата која работи во една мала, но многу горда компанија. Сите совпаѓања со вистинска мрежна опрема се случајни. Ќе разгледаме случај што се случи во оваа мрежа, кој можеше да доведе до затворање на бизнисот долго време и сериозни финансиски загуби. Решението за овој случај многу добро се вклопува во концептот на „Автоматизација на мрежната инфраструктура“. Користејќи алатки за автоматизација, ќе покажеме како можете ефективно да решавате сложени проблеми за кратко време и ќе размислиме зошто овие проблеми треба да се решаваат на овој начин, а не на друг начин (преку конзолата).

Општи услови

Нашите главни алатки за автоматизација се Ansible (како алатка за автоматизација) и Git (како складиште за Ansible Playbooks). Би сакал веднаш да направам резервација дека ова не е воведна статија, каде што зборуваме за логиката на Ansible или Git и ги објаснуваме основните работи (на пример, што се roletaskimodules, датотеки со залихи, променливи во 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. Лаптоп на кој се врши тестирање и развој на Playbooks за Ansible (лаптоп-автоматизација).

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

  • Област 0 – област која вклучува рутери одговорни за движење на сообраќајот во зоната EXCHANGE;
  • Област 1 – област која вклучува рутери одговорни за работењето на услугите на компанијата;
  • Област 2 – област која вклучува рутери одговорни за рутирање на управување со сообраќајот;
  • Област N – области на мрежи на филијали.

На граничните рутери се креира виртуелен рутер (VRF-INTERNET), на кој е инсталиран целосен приказ на eBGP со соодветниот доделен AS. iBGP е конфигуриран помеѓу VRFs. Компанијата има базен од бели адреси кои се објавени на овие VRF-INTERNET. Некои од белите адреси се насочени директно до FW-CLUSTER (адреси на кои работат услугите на компанијата), некои се пренасочени низ зоната EXCHANGE (внатрешни услуги на компанијата кои бараат надворешни IP адреси и надворешни NAT адреси за канцеларии). Следно, сообраќајот оди до виртуелни рутери создадени на L3-CORE со бели и сиви адреси (безбедносни зони).

Мрежата за управување користи наменски прекинувачи и претставува физички посветена мрежа. Мрежата за управување е исто така поделена на безбедносни зони.
Рутерот EMERGENCY физички и логички го дуплира FW-CLUSTER. Сите интерфејси на него се оневозможени освен оние што гледаат во мрежата за управување.

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

Сфативме како функционира мрежата. Сега да разгледаме чекор-по-чекор што ќе направиме за да го пренесеме сообраќајот од FW-CLUSTER во ИТНА:

  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. Оваа шема го одразува она што го опишавме веднаш погоре, тоа е само специфична имплементација во 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. Ова е главната опрема, а не резервна копија, мрежата мора да работи на неа.

Дали чувствувате како вмрежувачите почнуваат да изгоруваат? Техничкиот директор ќе слушне илјада аргументи зошто тоа не треба да се прави, зошто тоа може да се направи подоцна. За жал, вака функционира мрежата од еден куп закрпи, парчиња и остатоци од нејзиниот поранешен луксуз. Излегува дека е крпеница. Нашата задача воопшто, не во оваа специфична ситуација, туку генерално во принцип, како ИТ специјалисти, е да ја доведеме работата на мрежата до прекрасниот англиски збор „конзистентност“, таа е многу повеќеслојна, може да се преведе како: кохерентност , доследност, логика, кохерентност, систематичност, споредливост, кохерентност. Се е за него. Само во оваа состојба мрежата е управувана, јасно разбираме што функционира и како, јасно разбираме што треба да се промени, доколку е потребно, јасно знаеме каде да бараме ако се појават проблеми. И само во таква мрежа можете да изведувате трикови како оние што ги опишавме.

Всушност, беше подготвена друга книга за игри, која ги врати поставките во нивната првобитна состојба. Логиката на неговото функционирање е иста (важно е да се запамети дека редоследот на задачите е многу важен), за да не ја продолжиме веќе прилично долгата статија, решивме да не објавуваме список на извршување на книгата за игри. По спроведувањето на ваквите вежби, во иднина ќе се чувствувате многу посмирени и посигурни, покрај тоа, сите патерици што сте ги натрупале таму веднаш ќе се откријат.

Секој може да ни пише и да ги добие изворите на сите напишани кодови, заедно со сите пали книги. Контакти во профилот.

Наоди

Според наше мислење, процесите што можат да се автоматизираат сè уште не се кристализирани. Врз основа на она што го сретнавме и она што го дискутираат нашите западни колеги, досега се видливи следните теми:

  • Обезбедување на уреди;
  • Собирање на податоци;
  • Известување;
  • Решавање проблеми;
  • Усогласеност.

Доколку има интерес, можеме да ја продолжиме дискусијата на една од дадените теми.

Исто така, би сакал да зборувам малку за автоматизацијата. Што треба да биде во нашето разбирање:

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

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

  • Транспарентност на ИТ инфраструктурата (Помалку ризици од работењето, модернизација, имплементација. Помалку застој годишно);
  • Способност за планирање на ИТ ресурси (Систем за планирање капацитет - можете да видите колку е потрошено, можете да видите колку ресурси се потребни во еден систем, а не со писма и посети на врвните оддели);
  • Можност за намалување на бројот на ИТ персонал.

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


Извор: www.habr.com

Додадете коментар