Прывітанне, Хабр!
У дадзеным артыкуле мы хацелі б пагаварыць пра аўтаматызацыю сеткавай інфраструктуры. Будзе прадстаўлена працоўная схема сеткі, якая функцыянуе ў адной маленькай, але вельмі ганарлівай кампаніі. Усе супадзенні з рэальным сеткавым абсталяваннем з'яўляюцца выпадковымі. Мы разгледзім кейс, які адбыўся ў дадзенай сетцы, якой мог прывесці да прыпынку бізнэсу на працяглы час і сур'ёзным грашовым стратам. Рашэнне дадзенага кейса вельмі добрае ўпісваецца ў канцэпцыю "Аўтаматызацыя сеткавай інфраструктуры". З дапамогай сродкаў аўтаматызацыі мы пакажам, як можна эфектыўна вырашаць складаныя задачы ў сціслыя тэрміны, і паразважаем на тэму, чаму перспектыўней гэтыя задачы трэба вырашаць менавіта так, а не інакш (праз кансоль).
адмова
Асноўнымі прыладамі для аўтаматызацыі ў нас з'яўляюцца Ansible (як сродак аўтаматызацыі) і Git (як сховішча playbook-ов Ansible). Адразу хочацца абмовіцца, што гэта не азнаямленчы артыкул, дзе мы гаворым пра логіку працы Ansible або Git, і тлумачым базавыя рэчы (напрыклад, што такое ролітаскімодулі інвентарызацыйныя файлы зменныя ў Ansible, або што адбываецца пры ўвядзенні каманд git push або git commit). Гэта гісторыя не пра тое, як можна папрактыкавацца ў Ansible, наладзіць на абсталяванні NTP ці SMTP. Гэта гісторыя пра тое, як можна хутка і пажадана без памылак вырашаць сеткавую праблему. Таксама пажадана мець добрае ўяўленне аб тым, як працуе сетку, у прыватнасці, што такое стэк пратаколаў TCP/IP, OSPF, BGP. Выбар Ansible і Git таксама вынесем за дужкі. Калі вам яшчэ варта выбар канкрэтнага рашэння, то вельмі раім прачытаць кнігу «Network Programmability and Automation. Зборы для далейшай генерацыі сетак інжынера» 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 са наступнымі area-мі:
- Area 0 - вобласць, у якую ўключаны роўтэры, якія адказваюць за перамяшчэнне трафіку ў зоне EXCHANGE;
- Area 1 - вобласць, у якую ўключаны роўтэры, якія адказваюць за працу сэрвісаў кампаніі;
- Area 2 - вобласць, у якую ўключаны роўтэры, якія адказваюць за маршрутызацыю management-трафіку;
- Area 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 запыты, каб у arp-табліцах L3-CORE памяняліся мак-адрасы з FW-Cluster на EMERGENCY;
- Прапісваем маршрут па змаўчанні статыкай да BRD-01, BRD-02;
- Ствараем правілы NAT;
- Паднімаем на EMERGENCY OSPF Area 1;
- Паднімаем на EMERGENCY OSPF Area 2;
- Змяняем кошт маршрутаў у Area 1 на 10;
- Змяняем кошт дэфолтнага маршруту ў Area 1 на 10;
- Змяняем ip-адрасы, звязаныя з L2-MGMT (на тыя, якія былі на FW-CLUSTER);
- Які генеруецца gARP запыты, каб у 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 [------->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», яно вельмі шматграннае, можна перавесці як: узгодненасць, несупярэчлівасць, лагічнасць, зладжанасць, сістэмнасць, супастаўнасць, складнасць. Гэта ўсё пра яго. Толькі ў такім стане сетка з'яўляецца кіраванай, мы дакладна разумеем, што і як працуе, мы дакладна ўсведамляем, што трэба змяніць, у выпадку неабходнасці, мы дакладна ведаем куды паглядзець, у выпадку ўзнікнення праблем. І толькі ў такой сетцы можна праробліваць фокусы, падобныя тым, што мы зараз апісалі.
Уласна, быў падрыхтаваны яшчэ адзін playbook, які вяртаў наладкі ў зыходны стан. Логіка яго працы такая ж (важна памятаць, парадак цягоў вельмі важны), каб не падаўжаць і так даволі доўгі артыкул, мы вырашылі не выкладваць лістынг выканання playbook-а. Правёўшы такія вучэнні, вы адчуеце сябе нашмат спакайней і больш упэўнена ў будучыні, акрамя таго, любыя мыліцы, якія вы там нагарадзілі, адразу сябе выявяць.
Усе жадаючыя могуць напісаць нам і атрымаць зыходнікі ўсяго напісанага кода, разам з усімі palybook-амі. Кантакты ў профілі.
Высновы
На наш погляд, працэсы, якія можна аўтаматызаваць, яшчэ не выкрышталізаваліся. Зыходзячы з таго, з чым мы сутыкаліся, і таго, што абмяркоўваюць нашыя заходнія калегі, пакуль бачныя наступныя тэмы:
- Device provisioning;
- Data collection;
- Reporting;
- Ліквідацыю непаладак;
- Адпаведнасць.
Калі будзе цікавасць, мы зможам прадоўжыць абмеркаванне на адну з зададзеных тэм.
Яшчэ хочацца крыху паразважаць на тэму аўтаматызацыі. Які яна павінна быць у нашым разуменні:
- Сістэма павінна жыць без чалавека, пры гэтым паляпшацца чалавекам. Сістэма не павінна залежаць ад чалавека;
- Эксплуатацыя павінна быць экспертнай. Адсутнічае клас спецыялістаў, якія выконваюць руцінныя задачы. Ёсць эксперты, якія ўсю руціну аўтаматызавалі, і вырашаюць толькі складаныя задачы;
- Руцінныя стандартныя задачы робяцца аўтаматычна "па кнопцы", не марнуюцца рэсурсы. Вынік такіх задач заўсёды прадказальны і зразумелы.
І да чаго гэтыя пункты павінны прывесці:
- Празрыстасць ІТ-інфраструктуры (Менш рызыкі эксплуатацыі, мадэрнізацыі, укаранення. Менш downtime у год);
- Магчымасць планаваць ІТ-рэсурсы (Capacity-planning system – відаць колькі спажываецца, відаць колькі патрабуецца рэсурсаў у адзінай сістэме, а не па лістах і хадні да топаў аддзелаў);
- Магчымасць скараціць колькасць абслуговага ІТ-персанала.
Аўтары артыкула: Аляксандр Чалавекаў (CCIE RS, CCIE SP) і Павел Кірылаў. Нам цікава абмяркоўваць і прапаноўваць рашэнні на тэму Аўтаматызацыя ІТ-інфраструктуры.
Крыніца: habr.com