За допомогою цього чарівного шматка скрипта Cisco ACI можна швидко налаштувати мережу.
Мережева фабрика для ЦОДу Cisco ACI існує вже п'ять років, але на Хабрі про неї нічого не розказано, ось і вирішив це трохи виправити. Розкажу на своєму досвіді, що це таке, яка користь від неї і де в неї граблі.
Що це і звідки взялося?
До моменту анонсу ACI (Application Centric Infrastructure) у 2013 році на традиційні підходи до мереж ЦОД наступали конкуренти відразу з трьох сторін.
З одного боку, SDN-рішення «першого покоління» на базі OpenFlow обіцяли зробити мережі гнучкішими та дешевшими одночасно. Ідея була в тому, щоб винести ухвалення рішень, що традиційно виконується пропрієтарним софтом комутаторів, на центральний контролер.
Цей контролер мав би єдине бачення того, що відбувається, і, виходячи з цього, програмував би апаратуру всіх свитчів на рівні правил обробки конкретних потоків.
З іншого боку, оверлейні мережеві рішення давали можливість реалізовувати потрібну зв'язність і політики безпеки взагалі без змін у фізичній мережі, будуючи програмні тунелі між віртуалізованими хостами. Найбільш відомим прикладом такого підходу було рішення від Nicira, яка на той момент вже була придбана VMWare за 1,26 мільярда доларів і дала початок нинішньому VMWare NSX. Певної ситуації додавало те, що співзасновниками Nicira були ті ж люди, що раніше стояли біля витоків OpenFlow, які тепер говорили, що для побудови фабрики ЦОДу .
Ну і нарешті комутаційні чіпи, доступні на відкритому ринку (те, що називається merchant silicon), досягли ступеня зрілості, при якій вони стали реальною загрозою для традиційних виробників комутаторів. Якщо раніше кожен вендор сам розробляв чіпи для своїх комутаторів, то з часом чіпи від сторонніх виробників, насамперед від Brоadcom, стали скорочувати дистанцію з вендорськими чіпами за функціями, а за співвідношенням ціна/продуктивність їх перевершували. Тому багато хто вважав, що дні комутаторів на чіпах власної розробки вважаються.
ACI стала "асиметричною відповіддю" Cisco (точніше, що увійшла до її складу компанії Insieme, заснованої її колишніми співробітниками) на все перераховане.
У чому різниця з OpenFlow?
З погляду розподілу функцій ACI фактично – протилежність OpenFlow.
В OpenFlow-архітектурі контролер відповідає за прописування детальних правил (потоків)
в апаратурі всіх комутаторів, тобто у великій мережі, на ньому може лежати відповідальність за підтримку і, найголовніше, зміна десятків мільйонів записів у сотнях точок у мережі, тому його продуктивність і надійність у великому впровадженні стають вузьким місцем.
В ACI використовується зворотний підхід: контролер теж, зрозуміло, є, але комутатори отримують з нього високорівневі декларативні політики, які рендеринг деталі конкретних налаштувань в апаратурі виконує сам комутатор. Контролер можна перезавантажити або взагалі вимкнути, і з мережею нічого поганого не станеться, крім, зрозуміло, відсутності в цей момент можливості керування. Цікаво, що в ACI є ситуації, в яких OpenFlow все ж таки використовується, але локально в межах хоста для програмування Open vSwitch.
ACI повністю побудована на оверлейному транспорті на основі VXLAN, але при цьому включає в рамках єдиного рішення і IP-транспорт. Cisco назвала це терміном "інтегрований оверлей". Як точка термінування оверлеїв в ACI у більшості випадків використовуються комутатори фабрики (роблять це на швидкості каналу). Хости не повинні щось знати про фабрику, інкапсуляції і т. д., однак у ряді випадків (скажімо, для підключення OpenStack-хостів) VXLAN-трафік може доводитися і до них.
Оверлєї використовуються в ACI не тільки для забезпечення гнучкої зв'язності через транспортну мережу, але і для передачі метаінформації (вона використовується, наприклад, для застосування політик безпеки).
Чіпи від Broadcom і раніше використовувалися Cisco у комутаторах серії Nexus 3000. У сімействі Nexus 9000, спеціально випущеному для підтримки ACI, спочатку було реалізовано гібридну модель, яку назвали Merchant+. У комутаторі одночасно використовувалися і новий чіп Broadcom Trident 2, і чіп розробки Cisco, що доповнює його, реалізує всю магію ACI. Зважаючи на все, це дозволило прискорити вихід продукту і знизити цінник комутатора до рівня, близького до моделей просто на Trident 2. Цього підходу вистачило на перші два-три роки постачання ACI. За цей час Cisco розробила і випустила на ринок наступне покоління Nexus 9000 вже на власних чіпах з більшою продуктивністю і набором функцій, але на тому ж рівні ціни. Зовнішні специфікації з погляду взаємодії у фабриці повністю збереглися. При цьому внутрішня начинка цілком змінилася: щось на кшталт рефакторингу, але заліза.
Як влаштована архітектура Cisco ACI
У найпростішому випадку ACI будується за топологією мережі Клоза, або, як часто говорять, Spine-Leaf. Комутаторів Spine-рівня може бути від двох (або одного, якщо нас не хвилює відмовостійкість) до шести. Відповідно, чим їх більше, тим вища відмовостійкість (менше зниження смуги та надійності при аварії або обслуговуванні одного Spine) та загальна продуктивність. Всі зовнішні підключення йдуть в комутатори Leaf-рівня: це і сервери, і стикування із зовнішніми мережами L2 або L3, і підключення контролерів APIC. Взагалі з ACI не тільки налаштування, а й збір статистики, моніторинг відмов та інше – все робиться через інтерфейс контролерів, яких у впровадженнях звичайного розміру – три штуки.
До комутаторів консоллю не доводиться підключатися ніколи, навіть для запуску мережі: контролер сам виявляє комутатори і збирає з них фабрику, включаючи налаштування всіх службових протоколів, тому, до речі, дуже важливо при монтажі записати серійники обладнання, щоб потім не гадати, який комутатор в який стійці знаходиться. Для траблшутинга до комутаторів за потреби можна приєднатися по SSH: на них досить ретельно відтворені звичайні show-команди Cisco.
Усередині фабрика використовує IP-транспорт, тому ніякого Spanning Tree та інших жахів минулого в ній немає: всі лінки задіяні, і збіжність при відмовах дуже швидка. Трафік у фабриці передається через тунелі на основі VXLAN. Якщо точніше, то сама Cisco називає інкапсуляцію iVXLAN, і вона відрізняється від звичайного VXLAN тим, що зарезервовані поля в мережевому заголовку використовуються для передачі службової інформації, перш за все - про відношення трафіку до групи EPG. Це дозволяє реалізовувати правила взаємодії між групами в апаратурі, використовуючи їх номери так само, як у звичайних аксесс-листах використовуються адреси.
Тунелі дозволяють розтягувати через внутрішній IP-транспорт і L2-сегменти, і L3 (тобто VRF). При цьому стандартний шлюз — розподілений. Це означає, що маршрутизацією трафіку, що входить у фабрику, займається кожен комутатор. Частина логіки передачі трафіку ACI схожа на фабрику на основі VXLAN/EVPN.
Якщо так, то в чому різниця? У всьому іншому!
Відмінність номер один, з яким стикаєшся в ACI, - те, як включаються до мережі сервера. У традиційних мережах включення і фізичних серверів, і віртуалок йде в VLANи, і від них танцює все інше: зв'язність, безпека і т. д. У ACI використовується конструкція, яку Cisco називає EPG (End-point Group), від якої нікуди не дітися. Чи можна її прирівняти до VLAN? Так, але в цьому випадку є шанс втратити більшу частину того, що дає ACI.
Щодо EPG формулюються всі правила доступу, а в ACI за замовчуванням використовується принцип «білого списку», тобто дозволено лише трафік, пропускання якого дозволено у явній формі. Тобто ми можемо створити EPG-групи «Web» та «MySQL» і визначити правило, що дозволяє взаємодію між ними тільки по порту 3306. Це буде працювати без прив'язки до мережевих адрес і навіть в межах однієї підмережі!
У нас є замовники, які вибрали ACI саме через цю фічу, оскільки вона дозволяє обмежити доступи між серверами (віртуальними чи фізичними — неважливо), не перетягуючи їх між підмережами, а отже, не чіпаючи адресацію. Так-так, ми знаємо, адже ніхто не прописує руками IP-адреси в конфігураціях додатків, правда?
Правила проходження трафіку в ACI називаються контрактами. У такому контракті одна або кілька груп чи рівнів у багатоланковому додатку стають провайдером сервісу (скажімо, сервісу БД), інші споживачем. Контракт може просто пропустити трафік, а може зробити щось хитріше, наприклад, направити на файрвол або балансувальник, а також змінити значення QoS.
Як сервери потрапляють у ці групи? Якщо це фізичні сервери або щось включене в існуючу мережу, в яку ми створили VLAN-транк, то для їхнього розміщення в EPG знадобиться вказати на порт комутатора і VLAN, що використовується на ньому. Як бачимо, VLAN з'являються там, де без них не обійтися.
Якщо ж серверами є віртуалки, то достатньо послатися на підключене середовище віртуалізації, а далі все станеться саме: створиться порт-група (якщо говорити в термінах - VMWare) для підключення VM, призначаються необхідні VLAN або VXLAN, пропишуться на необхідних портах комутаторів і т.д. д. Так що, хоча ACI і побудована навколо фізичної мережі, для віртуальних серверів підключення виглядають набагато простіше, ніж для фізичних. В ACI вже вбудовані зв'язки з VMWare та MS Hyper-V, а також підтримка для OpenStack та RedHat Virtualization. З деякого моменту з'явилася і вбудована підтримка контейнерних платформ: Kubernetes, OpenShift, Cloud Foundry, при цьому вона стосується і застосування політик, і моніторингу, тобто адміністратор може відразу побачити, на яких хостах які піди працюють і в які групи вони потрапили.
Крім включення в ту чи іншу порт-групу, віртуальні сервери мають додаткові властивості: ім'я, атрибути і т. д., які можна використовувати як критерії для їх перенесення в іншу групу, скажімо, при перейменуванні VM або появі у неї додаткового тега. Cisco називає це мікросегментаційними групами, хоча, за великим рахунком, сама конструкція з можливістю створювати багато сегментів безпеки у вигляді EPG в одній і тій же підмережі - теж цілком мікросегментація. Ну, вендору видніше.
Самі EPG є суто логічними конструкціями, не прив'язаними до конкретних комутаторів, серверів тощо, так що з ними та конструкціями на їх основі (додатками та тенантами) можна робити речі, які важко зробити у звичайних мережах, наприклад, клонувати. В результаті, скажімо, дуже легко створити клон продуктивного середовища, щоб отримати тестове оточення, гарантовано ідентичне продуктиву. Можна зробити вручну, але краще (і простіше) через API.
Взагалі, логіка управління в ACI зовсім не схожа на те, з чим зазвичай зустрічаєшся
у традиційних мережах від тієї ж Cisco: програмний інтерфейс первинний, а GUI чи CLI вторинні, оскільки працюють через той самий API. Тому майже кожен, хто займається ACI, через деякий час починає орієнтуватися в об'єктній моделі, яка використовується для керування, та щось автоматизувати під свої потреби. Найпростіше це робити з Python: для нього є зручні готові інструменти.
Обіцяні граблі
Головна проблема — те, що багато речей в ACI зроблено по-іншому. Щоб почати з нею нормально працювати, потрібно переучуватись. Особливо це стосується команд мережевої експлуатації у великих замовниках, де інженери роками займаються прописуванням VLANів за заявками. Те, що тепер VLAN – більше не VLAN, а для прокладання нових мереж у віртуалізовані хости створювати VLANи руками взагалі не потрібно, повністю «зносить дах» у традиційних мережевиків і змушує чіплятися за звичні підходи. Треба помітити, що Cisco постаралася трохи підсолодити пігулку і додала в контролер NXOS-подібний CLI, що дозволяє робити налаштування з інтерфейсу, схожого на традиційні комутатори. Але все одно для того, щоб почати нормально користуватися ACI, доведеться зрозуміти, як вона працює.
З точки зору ціни на великих і середніх масштабах мережі ACI від традиційних мереж на обладнанні Cisco фактично не відрізняється, тому що для їх побудови використовуються одні й ті ж комутатори (Nexus 9000 можуть працювати і в ACI, і в традиційному режимі і стали зараз основною «робочою конячкою» для нових проектів з ЦОД). А ось для ЦОДів з двох свитків наявність контролерів та Spine-Leaf-архітектури, звичайно, дають про себе знати. Нещодавно з'явилася Mini ACI-фабрика, в якій два контролери із трьох замінено віртуальними машинами. Це дозволяє скоротити різницю у вартості, але вона все одно залишається. Так що для замовника вибір диктується тим, наскільки він зацікавлений у функціях безпеки, інтеграції з віртуалізацією, єдиною точкою управління тощо.
Джерело: habr.com