Привіт, Хабре!
У цій статті ми хотіли б поговорити про автоматизацію мережевої інфраструктури. Буде представлена робоча схема мережі, яка функціонує в одній маленькій, але дуже гордій компанії. Усі збіги з реальним мережевим обладнанням є випадковими. Ми розглянемо кейс, що стався в цій мережі, яка могла призвести до зупинки бізнесу на тривалий час і серйозних грошових втрат. Рішення даного кейсу дуже добре вписується в концепцію «Автоматизація інфраструктури мережі». За допомогою засобів автоматизації ми покажемо, як можна ефективно вирішувати складні завдання в стислий термін, і поміркуємо на тему, чому перспективніші ці завдання треба вирішувати саме так, а не інакше (через консоль).
відмова
Основними інструментами для автоматизації у нас є 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