Оцініть зв'язки у середній частині схеми. Нижче до них повернемося
У якийсь момент ви можете зіткнутися з тим, що великі складні мережі на базі L2 невиліковно хворі. Насамперед проблемами, пов'язаними з обробкою BUM трафіку та з роботою протоколу STP. По-друге — загалом морально застарілою архітектурою. Це викликає неприємні проблеми у вигляді даунтаймів та незручності керованості.
У нас було два паралельні проекти, де замовники тверезо оцінили всі плюси та мінуси варіантів і вибрали два різні оверлейні рішення, а ми їх впровадили.
Була нагода порівняти саме реалізацію. Чи не експлуатацію, про неї варто говорити роки через два-три.
Отже, що таке мережева фабрика з накладеними мережами та SDN?
Що робити з проблемами класичної архітектури мережі?
Щороку з'являються нові технології та ідеї. На практиці гаряча необхідність перебудовувати мережі не виникала досить довго, тому що робити все руками за старими добрими дідівськими методами теж можна. Ну і що, що на дворі двадцять перше століття? Зрештою, адмін же має працювати, а не сидіти у себе в кабінеті.
Потім розпочався бум будівництва масштабних дата-центрів. Тоді стало зрозуміло, що досягнуто ліміту розвитку класичної архітектури не тільки в плані працездатності, відмовостійкості, масштабованості. І одним з варіантів вирішення цих завдань стала ідея побудови накладених мереж поверх бекбона, що маршрутизується.
Крім цього, зі збільшенням масштабів мереж гостро постала проблема управління такими фабриками, внаслідок чого почали з'являтися рішення програмно-визначуваних мереж із можливістю керувати всією мережевою інфраструктурою як єдиним цілим. А коли мережа керується з єдиної точки, то іншим компонентам ІТ-інфраструктури простіше з нею взаємодіяти і такі процеси взаємодії простіше автоматизувати.
Практично кожен великий виробник як мережного устаткування, а й віртуалізації, має у своєму портфоліо варіанти таких рішень.
Залишається тільки розібратися, що підійде для якихось потреб. Наприклад, для особливо великих компаній, що володіють гарною командою розробників та експлуатації, не завжди коробкові рішення від вендорів задовольняють усім потребам, і вони вдаються до розробки власних SD (software defined) рішень. Наприклад, це хмарні провайдери, які постійно розширюють асортимент сервісів, що надаються своїм клієнтам, і коробкові рішення просто не в змозі встигнути за їхніми потребами.
Для середніх компаній, функціоналу, що пропонується вендором у вигляді коробкового рішення, вистачає у 99 відсотків випадків.
Що це таке оверлейні мережі
У чому полягає ідея оверлейних мереж. По суті, ви берете класичну мережу, що маршрутизується, і будуєте поверх неї ще одну мережу, щоб отримати більше фіч. Найчастіше йдеться про ефективний розподіл навантаження на обладнання та лінії зв'язку, значне збільшення ліміту за масштабованістю, підвищення надійності та купу плюшок у безпеці (за рахунок сегментації). А SDN рішення на додаток до цього дають можливість максимально зручного гнучкого адміністрування і роблять мережу більш прозорою для її споживачів.
Загалом, якби локальні мережі винаходили в роках 2010-х, то вони б виглядали далеко не так, як те, що дісталося нам у спадок від військових з 1970-х.
З погляду технологій побудови фабрик з використанням накладених мереж, в даний час існує безліч реалізацій виробників та інтернет-проектів RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve та інші). Так, є стандарти, але реалізація цих стандартів різними виробниками може відрізнятися, тому при створенні таких фабрик повністю відмовитися від вендор-локу поки що можна лише в теорії на папері.
З SD рішення справи ще заплутаніше, кожен вендор має своє бачення. Є повністю відкриті рішення, які теоретично можна допилювати самому, є повністю закриті.
Cisco пропонує свій варіант SDN для ЦОД - ACI. Природно це 100% вендор-лок рішення з погляду вибору мережного обладнання, але при цьому воно повністю інтегрується з системами віртуалізації, контейнеризації, безпеки, оркестрації, балансувальниками навантаження та ін Але по суті це все одно якийсь блек бокс, без можливості повного доступу до всіх внутрішніх процесів. Не всі замовники погоджуються на такий варіант, тому що ти повністю залежиш від якості написаного коду рішення та його реалізації, але з іншого боку виробник має одну з найкращих у світі технічних підтримок і має виділену команду, яка займається лише даним рішенням. Як рішення для першого проекту було обрано саме Cisco ACI.
Для другого проекту було обрано рішення Juniper. Виробник також має свій SDN для ЦОД, але замовником було прийнято рішення відмовитися від впровадження SDN. Як технологія побудови мережі була обрана EVPN VXLAN фабрика без використання централізованих контролерів.
Для чого потрібно
Створення фабрики дозволяє побудувати легко масштабовану, стійку до відмов, надійну мережу. Архітектура (leaf-spine) враховує особливості центрів обробки даних (шляхи проходження трафіку, мінімізація затримок та вузьких місць у мережі). SD рішення ж у ЦОДах дозволяють дуже зручно, швидко, гнучко керувати такою фабрикою, інтегрувати в екосистему ЦОД.
Обом замовникам необхідно було побудувати резервні ЦОДи для забезпечення відмовостійкості, крім цього трафік між ЦОДами повинен був шифруватися.
Перший замовник вже розглядав рішення без фабрики як можливий стандарт своїх мереж, але на тестах вони мали проблеми із сумісністю STP між кількома вендорами заліза. Виникали даунтайми, які спричиняли падіння сервісів. А для замовника це було критично.
Cisco вже була корпоративним стандартом замовника, вони придивилися до ACI та інших варіантів та вирішили, що варто взяти саме це рішення. Сподобалася автоматизація керування з однієї кнопки через єдиний контролер. Швидше налаштовуються послуги, швидше керуються. Шифрування трафіку вирішили забезпечити запустивши MACSec між комутаторами IPN та SPINE. Таким чином вдалося уникнути вузького місця у вигляді криптошлюзу, заощадити на них і використовувати максимум смугу пропускання.
Другий замовник вибрав рішення без контролера від Juniper, оскільки в їхньому ЦОД вже була невелика інсталяція з реалізацією фабрики EVPN VXLAN. Але там вона не була стійкою до відмови (використовувався один комутатор). Вирішили розширити інфраструктуру основного ЦОД та побудувати фабрику в резервному ЦОД. Наявний EVPN не використовувався повною мірою: інкапсуляція VXLAN фактично не застосовувалася, тому що всі хости були підключені до одного комутатора, і всі MAC-адреси і адреси хостів /32 були локальними, шлюзом для них був цей же комутатор, не було інших пристроїв, куди потрібно було будувати VXLAN тунелі. Шифрування трафіку вирішили забезпечити з використанням технології IPSEC між файрволами (продуктивності МСЕ було достатньо).
Теж помацали ACI, але вирішили, що через вендор-лок доведеться купувати занадто багато заліза, в тому числі замінювати нещодавно куплене нове обладнання, і це просто не має економічного сенсу. Так, фабрика Cisco інтегрується з усім, але всередині самої фабрики можливі лише її пристрої.
З іншого боку, як говорили раніше, EVPN VXLAN фабрику з будь-яким сусіднім вендор просто так не змішаєш, тому що реалізації протоколу відрізняються. Це як схрещувати Cisco і Хуавей в одній мережі — начебто стандарти загальні, тільки з бубном потанцювати доведеться. Оскільки це банк, і тести на сумісність були б дуже довгими, вирішили, що краще закупитись тим самим вендором зараз, і не особливо захоплюватися функціоналом за межами базового.
План міграції
Два ЦОДи на базі ACI:
Організація взаємодії між ЦОДами. Вибрано Multi-Pod рішення – кожен ЦОД є подом. Враховано вимоги до масштабування за кількістю комутаторів та затримок між подами (RTT менше 50 мс). Було прийнято рішення не будувати Multi-Site рішення для зручності управління (для Multi-Pod рішення використовується єдиний інтерфейс управління, для Multi-Site було б два інтерфейси, або знадобився Multi-Site Orchestrator), і так як не потрібно географічного резервування майданчиків.
З точки зору міграції сервісів з мережі Legacy, було обрано найбільш прозорий варіант, переносити поступово VLAN відповідні певним сервісам.
Для міграції кожному VLAN створювався відповідний EPG (End-point-group) на фабриці. Спочатку мережа розтягувалася між старою мережею і фабрикою L2, потім після міграції всіх хостів, шлюз переносився на фабрику, і взаємодія EPG з існуючою мережею проводилася через L3OUT, при цьому взаємодія між L3OUT і EPG описувалося з використанням контрактів. Зразкова схема:
Орієнтовна структура більшості політик фабрики ACI на малюнку нижче. Все налаштування будується на політиках, вкладених в інші політики тощо. Спочатку дуже непросто розібратися, але поступово, як показує практика, адміністратори мережі звикають до такої структури приблизно за місяць, і потім лише приходить розуміння, наскільки вона зручна.
Порівняння
У рішенні Cisco ACI потрібно купувати більше обладнання (окремі комутатори для Inter-Pod взаємодії та APIC контролери), за рахунок чого воно вийшло дорожчим. Рішення Juniper не зажадало купівлю контролерів та допоміжного обладнання; вийшло частково використати вже існуюче обладнання замовника.
Ось архітектура EVPN VXLAN фабрики для двох ЦОД другого проекту:
В ACI ти отримуєш готове рішення – не треба колупати, не треба оптимізувати. При початковому знайомстві замовника з фабрикою не потрібні розробники, не потрібні люди для коду та автоматизації. Досить просто експлуатації, багато налаштувань можна робити взагалі через визард, що не завжди плюс, особливо для людей, які звикли до командного рядка. У будь-якому разі потрібен час для того, щоб перебудувати мозок на нові рейки, на особливість налаштувань через політики та оперуванням безлічі вкладених один в одного політик. Дуже бажано, крім того, ще мати чітку структуру найменування політик та об'єктів. При виникненні будь-якої проблеми у логіці роботи контролера, її можна вирішити лише через техпідтримку.
У EVPN – консоль. Страждай чи радуйся. Звичний інтерфейс для старої гвардії. Так, є типова конфігурація та гайди. Прийде курити мани. Різні конструкції все зрозуміло і детально.
Природно, в обох випадках краще при міграції спочатку мігрувати не найкритичніші послуги, наприклад, тестові середовища, і тільки потім після затримання всіх багів приступати до проду. І не налаштовувати у п'ятницю ввечері. Не варто вірити вендору, що все буде добре, завжди краще підстрахуватися.
На ACI платиш більше, хоча в даний час Cisco активно просуває це рішення і часто дає хороші знижки на нього, але заощаджуєш на обслуговуванні - супроводі. Управління та будь-яка автоматизація EVPN фабрики без контролера потребує вкладень та регулярних витрат – моніторинг, автоматизація, впровадження нових сервісів. При цьому первинний запуск ACI робиться довше на 30-40 відсотків. Це відбувається тому, що довше створюється весь набір необхідних профілів та політик, які потім використовуватимуться. Але зі зростанням мережі кількість необхідних змін зменшується. Використовуєш уже заздалегідь створені політики, профілі, об'єкти. Можеш гнучко налаштовувати сегментацію та безпеку, централізовано управляти контрактами, які відповідають за вирішення тих чи інших взаємодій між EPG, – обсяг роботи різко падає.
У EVPN треба конфігурувати кожен пристрій у фабриці, ймовірність помилки більша.
Якщо ACI повільніше запроваджується, то EVPN майже вдвічі довше налагоджувався. Якщо у випадку з Cisco завжди можна покликати інженера підтримки та запитати про мережу в цілому (бо покривається як рішення), то у Juniper Networks ви купуєте тільки залізо, і покривається саме воно. Пакети з пристрою пішли? Ну гаразд, далі ваші проблеми. Але можна відкрити питання щодо вибору рішення або дизайну мережі — і тоді порадять придбати професійний сервіс за додаткову плату.
ACI підтримка дуже крута, бо окрема: окрема команда сидить лише для цього. Є, навіть російськомовні фахівці. Гайд докладний, рішення зумовлені. Дивляться та радять. Швидко валідують дизайн, що дуже важливо. Juniper Networks роблять те саме, але в рази повільніше (у нас було так, зараз має бути краще за чутками), що змушує тебе самостійно робити все там, де міг би порадити солюшн-інженер.
Cisco ACI підтримує інтеграцію з системами віртуалізації та контейнеризації (VMware, Kubernetes, Hyper-V) та централізоване керування. Є з мережевими сервісами та сервісами безпеки — балансування, міжмережеві екрани, WAF, IPS та інше… Хороша мікросегментація із коробки. У другому рішенні інтеграція з мережевими сервісами проходить із бубном, і краще заздалегідь курити форуми з тими, хто так робив.
Підсумок
Для кожного конкретного випадку необхідно підбирати рішення, не тільки виходячи з вартості обладнання, але й необхідно враховувати також подальші витрати на експлуатацію та основні проблеми, з якими стикається зараз замовник, і які є плани розвитку ІТ-інфраструктури.
ACI за рахунок додаткового обладнання вийшов дорожчим, але рішення готове без необхідності допилювання, друге рішення складніше і витратніше з точки зору експлуатації, але дешевше.
Якщо хочете обговорити, скільки може коштувати впровадження мережевої фабрики на різних вендорах і яка потрібна архітектура, можна зустрітися і поспілкуватися. До чорнового нарису архітектури (з яким можна вважати бюджети) підкажемо безкоштовно, детальне опрацювання, звичайно, вже платне.
Володимир Клепче, корпоративні мережі.
Джерело: habr.com