Від Slides Defined до Software Defined Networking. Частина 3



У попередніх частинах (частина 1 і частина 2) ми розповідали про архітектурі та функціях SDN-рішення для ЦОД Big Cloud Fabric від компанії Big Switch Networks. У заключній статті ми розглянемо можливості фабрики по інтеграції з суміжними системами, а також наведемо коротке резюме попередніх частин огляду.

Інтеграція Big Cloud Fabric

Сучасна мережа ЦОД не може існувати окремо від інших систем – занадто тісно переплетений фізичний та віртуальний світи, і занадто розмиті межі між ними. Інтеграція з системами віртуалізації і оркестрации – це одне з найважливіших переваг BCF. Незважаючи на те, що аналогічні можливості заявлені в рішеннях безлічі виробників, централізована архітектура BCF дозволяє їх реалізувати швидко, просто і зручно.

На даний момент реалізована спільна робота BCF з VMware vSphere, Docker/Kubernetes, а також інтеграція з OpenStack. У випадку з останнім можливості інтеграції вважаються одними з кращих в індустрії. На обчислювальні вузли KVM встановлюється агент для Open vSwitch, який повністю синхронізований з фабрикою і не тільки забезпечує комутацію, але і маршрутизацію між віртуальними машинами на обчислювальному вузлі. Створення і управління проектами в інтерфейсі Horizon повністю синхронізований з контролером BCF – фактично, всередині OpenStack Project (BCF Tenant) будь-які дії з управління мережевою інфраструктурою фабрики можуть бути виконані з Horizon.

Інтеграція з vSphere відбувається через vCenter, при цьому фабрика може бути пов'язана з кількома копіями vCenter, кожен з яких керує власним tenant'ом у BCF. Більш того, ресурси фабрики можуть бути розділені між декількома копіями vCenter і OpenStack. Інтеграція з vCenter дає наступні можливості:

  • автоматичне вивчення підключених ESXi хостів і організація LAG груп;
  • автоматичне вивчення адрес для віртуальних машин (MAC адресу, опціонально IPv4), розгорнутих на підключених ESXi;
  • автоматичне створення сегментів у фабриці і правил членства в них при створенні port group;
  • автоматичне додавання необхідних VLAN в LAG c ESXi хостом;
  • при здійсненні vMotion, якщо на поточному ESXi не залишається віртуальних машин в конкретному сегменті, interface-group (через який підключений ESXi) буде видалений з сегмента.
Таким чином більшість рутинних операцій автоматизовані і не потребують втручання мережевого фахівця. Однак на цьому можливості інтеграції BCF і vSphere не обмежуються. В Big Switch Networks розробила плагін для vCenter, який ще більше розширює можливості членів команди віртуалізації і дає їм додаткові інструменти конфігурації та аналізу несправностей. З допомогою нього, адміністратор vCenter може створювати L3-інтерфейси для підмереж і сегментів, в яких розташовані віртуальні машини, переглядати інформацію про VLAN, кінцевих хостах і серверах, а також політиків (ACL, PBR). Але найголовніше, в плагіні доступний той же інструмент Test Path, що і в інтерфейсі контролера BCF.

Адміністратору віртуального середовища більше не потрібно турбувати мережевого інженера на більшості етапів процесу пошуку та усунення несправностей – досить вибрати віртуальну машину джерела і машину (або зовнішній хост) призначення і провести повний тест на проходження трафіку через фабрику.

Може скластися враження, що інтеграція з vSphere і плагін для vCenter дають занадто великі можливості адміністраторам віртуальної інфраструктури, до яких вони можуть бути не готові. Однак це не так. Вищеописані інструменти лише покликані полегшити і прискорити процеси настроювання й пошуку несправностей – командам не навіщо без потреби відволікати один одного і чекати реакції на виконання найпростіших запитів і рутинних операцій. Адміністратор віртуального середовища не може нічого «зламати» фабриці — його можливості закінчуються tenant'ом, з яким синхронізований vCenter, але в теж час у нього достатньо інструментів для вирішення щоденних завдань. Загальне управління фабрикою, як і раніше, здійснює мережевий інженер, але його участь вимагається лише у вирішенні серйозних інцидентів або при глобальних змінах в системі.

Висновок
Концепція Software Defined Networks є, ймовірно, найбільш обговорюваною темою мережевого світу. Ні один маркетинговий матеріал не обходить її, кожен виробник прагне в тому чи іншому вигляді заявити про її підтримку у своїх рішеннях. Однак, незважаючи на безперервний розвиток і ряд значних змін, ця концепція довгий час не мала втілення у вигляді комерційно закінчених продуктів. Можливо, причина в тому, що одним з наріжних каменів відмовостійкості телекомунікаційних мереж є децентралізація, в той час як реалізація SDN-концепції практично неможлива без єдиної точки управління та контролю (Control & Management Plane).

Але ті переваги, які несе за собою SDN, інтерес замовників і постійно наступають на п'яти виробники програмного забезпечення змушують гігантів мережевого ринку переглядати свою точку зору. У результаті ринок наповнюють просунуті системи управління, нехай і під різними назвами, але об'єднані однією метою – емулювати SDN-функції у класичній мережі. На жаль, такий підхід не може принести всіх тих переваг, що пропонує SDN, а найголовніше, не вирішує давньої проблеми мережевого світу ІТ – поділу програм, операційної системи і апаратного забезпечення. Розвиток комерційних ASIC і поява на ринку розробників мережевих операційних систем частково вирішило проблему дезагрегації, але зібрані з них продукти або залишаються мережею незалежних пристроїв без будь-якого натяку на інтеграцію зі сторонніми системами, або конструктором, який пропонується збирати самостійно.

Мережі ЦОД не володіють широким територіальним розподілом і рідко виходять за рамки одного машинного залу, а, отже, надійність ліній зв'язку в них значно вище, ніж у розподілених і кампусних мереж. Таким чином, проблема централізації та відмовостійкості в ЦОД не стоїть гостро. Більше того, всім подобаються модульні комутатори! Якби не кабелі з їх незмінною здатність заповнювати весь доступний простір, мережа ЦОД напевно складалася б з двох дуже великих комутаторів. Рекомендовані дизайни провідних виробників з використанням виносів фабрики або великих стеків 1RU-комутаторів тому наочний приклад. Мабуть, справедливо грунтуючись на таких міркуваннях, компанія Big Switch Networks змогла перетворити концепцію в реально працюючий комерційний продукт.

На закінчення хотілося б зробити суху вижимки огляду і ще раз перерахувати основні моменти, якими володіє Big Cloud Fabric:

  • Відсутність апаратної прив'язки до виробника мережевого устаткування (hardware vendor lock-in). В якості комутатора фабрики можуть бути використані комутатори різних виробників, засновані на ASIC Broadcom Trident 2/2+ і Tomahawk. Це означає, що більше не потрібно підлаштовуватися під політику виробника і постачальника комутаторів: тепер є вибір. Це не тільки знижує витрати, але і прискорює процеси закупівлі обладнання – можна вибрати будь-який з доступних зараз комутаторів замість того, що б місяцями чекати постачання певної моделі;
  • Відмовостійкість. Незважаючи на централізований Control Management plane, BCF надзвичайно надійна. Контролери фабрики реалізуються у вигляді відмовостійкого кластера, leaf комутатори можна об'єднувати в MC-LAG пару, а у випадку виходу з ладу всіх контролерів, фабрика буде продовжувати працювати з усіма вивченими серверами. Як один з доказів відмовостійкості фабрики, Big Switch Networks наводить результати, т. зв. Chaos Monkey Testing – на фабриці з 16 spine-/32 leaf-комутаторів під навантаженням 42 000 кінцевих хостів/ВМ було організовано понад 640 відмов протягом 30 хвилин, але це ніяк не вплинуло на продуктивність додатків;
  • Єдина точка контролю, керування та інтеграції. По суті перед нами дійсно великий, розподілений, модульний комутатор. Немає потреби налаштовувати кожен комутатор окремо і турбуватися про протоколах, петлях, відмовостійкості всередині мережі – BCF являє собою єдину фабрику, з єдиним інтерфейсом. Інтеграція з системами віртуалізації і оркестрации дозволяє автоматизувати більшість процесів, а такі інструменти як Test Path і плагін для VMware vCenter значно спрощують пошук несправностей і процеси комунікацій між командами;
  • Широкі можливості по аналітиці. контролер фабрики вбудована потужна система збирання, кореляції та відображення всіх даних по фізичній і логічній структурі фабрики. Завдяки цьому значно спрощуються процеси пошуку й усунення несправностей, а також відсутня необхідність у розгортанні додаткових систем;
  • Значна масштабованість. POD BCF підтримує до 32 leaf/6 spine комутаторів і 46'000 підключених крайових хостів. Таким чином, ми отримуємо мережеву фабрику з передбачуваним, постійним часом затримки і перепідпискою 2:1. Слід зазначити, що для додавання комутатора на фабрику не потрібно нічого, крім комутації – функція Zero Touch Provisioning усуває необхідність в якоїсь налаштування обладнання, що підключається. Таким чином, для збільшення портової ємності фабрики з 96 портів до більш ніж 1500 необхідно час тільки на монтаж і комутацію плюс 10 хвилин на налаштування.
На додаток до всього компанія Big Switch Networks надає дуже гнучкі можливості по знайомству з продуктом. По-перше, це спеціальна безкоштовна версія BCF-контролера у вигляді віртуальної машини, Community Edition. Вона володіє всією функціональністю комерційної версії, крім обмежень на кількість і тип комутаторів (тільки 2 фізичних комутатора), а також підтримку (best effort, тільки по електронній пошті). Для знайомства з можливостями BCF навіть без наявності обладнання можна скористатися віддаленої лабораторії. У ній представлені кілька навчальних модулів, розбитих по найбільш цікавих тем, у рамках яких можна відпрацювати часто використовувані функції і сценарії або просто познайомитися з інтерфейсом контролера.

В цілому, від тестування та роботи з фабрикою Big Cloud Fabric ми отримали виключно приємні враження і впевнені, що за рахунок зручності, простоти і широкої функціональності він буде затребуване на ринку мережевих рішень ЦОД навіть в умовах жорсткої конкуренції з боку інших великих систем.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.