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



попередній статті ми постаралися познайомити читачів з архітектурою і ключовими моментами SDN-рішення Big Cloud Fabric від компанії Big Switch Networks. У цій частині представляємо огляд інтерфейсів взаємодії та функціональних можливостей фабрики.

Інтерфейс Big Cloud Fabric

Як було згадано у попередній частині, контролер фабрики є єдиною точкою управління, аналітики та інтеграції з зовнішніми системами. Незважаючи на те, що для налаштування, моніторингу, пошуку та усунення несправностей доступні як повнофункціональний CLI, так і надзвичайно зручний web-інтерфейс, вони по суті є клієнтами для єдиного REST API. Багато виробників пропонують REST інтерфейси для взаємодії зі своїми продуктами, але так вийшло, що в світі мережевих пристроїв вони за часту менш функціональні ніж CLI/WEB і не дають доступ до всіх функцій і механізмів, що значно обмежує можливості їх застосування. У свою чергу, підхід, який був обраний в BCF, повністю виключає втрату функціональності – все, що можна зробити в CLI або в web-інтерфейсі – доступно до реалізації з допомогою REST API. Більш того, сам процес використання REST API зроблений максимально зручним і простим: досить ввести в CLI команду debug rest для кожної введеної в CLI команди буде виведено метод, шлях і тіло запиту, а також код і тіло відповіді. Таким чином, щоб написати який-небудь скрипт для автоматизації рутинних процесів, що немає більше потреби сидіти над документацією (яка теж існує) – достатньо один раз виконати необхідні операції в CLI та на підставі висновків зробити шаблон.

Окремо хотілося згадати про web-інтерфейсі управління. Так уже повелося в мережевому світі, що консоль CLI вважається найбільш зручним інструментом конфігурування, пошуку та усунення несправностей. Почасти це пов'язано з тим, що до появи загальноприйнятих API і можливості виконання скриптів безпосередньо на обладнанні, CLI давав більш широкі можливості по автоматизації рутинних операцій і часто був набагато інформативніше, ніж web-інтерфейс. Однак, в контролері BCF web-інтерфейс настільки зручний, зрозумілий і функціональний, що при проведенні тестування наш інженер практично не вдавався до послуг CLI – всі налаштування і діагностична інформація були доступні в зручному і зрозумілому графічному інтерфейсі. На додаток до відмінну ергономіку і зрозумілою логічною структурою web-інтерфейс містить безліч, здавалося б, незначних, але дуже корисних деталей, які якраз і формують почуття задоволеності від роботи з ним. Наприклад, при додаванні комутатора необхідно вибрати яку роль він буде займати в архітектурі (Spine або Leaf). Але якщо в імені, яка призначається комутатора, зустрінеться одне з цих слів, роль буде запропоновано автоматично. Дрібниця, а приємно.


Скріншот домашньої сторінки GUI (зображення кликабельно)

Функціональність Big Cloud Fabric

Коли ми починали тестування BCF в лабораторії, була підготовлена методика, заснована на практичному досвіді. У неї були включені ті функції і механізми, які гарантовано зустрічаються в ЦОД, оскільки ми не були впевнені, що достатньо молодий продукт буде володіти тими ж можливостями і підтримувати аналогічний набір механізмів і протоколів, що і старожили ринку телекомунікацій. Проте вже на першому етапі вивчення документації на BCF нам довелося значно збільшити обсяг досліджуваних функцій, оскільки всі вони були дійсно цікаві і затребувані. Але найбільше нас вразило те, що всі заявлені функції працювали як годинник – жоден тест не був провалений або працював із зауваженнями. Взагалі, відчуття від роботи з BCF можна коротко характеризувати як «швидко, просто і зручно».

Логічна структура BCF складається з цілком зрозумілих будь-якого мережного фахівця елементів, і це вигідно відрізняє BCF від схожих рішень інших виробників. Структурною одиницею логічної структури BCF є tenant, який фактично являє собою класичний VRF. У tenant'ах розташовуються широкі сегменти та їх маршрутизирующие інтерфейси, а зв'язок між ними здійснюється через системний маршрутизатор (системний tenant). В сегментах розташовуються кінцеві фізичні або віртуальні хости (end point). Сполучення з зовнішніми пристроями можна організувати як за допомогою статичної маршрутизації, так і з допомогою протоколу BGP. Однак, за такою простотою логічною структурою розвинена функціональність і гнучкість.


Логічна схема Big Cloud Fabric (зображення кликабельно)

На відміну від класичних комутаторів, членами одного широкомовного сегмента можуть стати сервери, що передають пакети з різними VLAN ID, а в теж час однаковий VLAN ID може бути віднесений до різних сегментів. Відсутня необхідність у використанні протоколів резервування основного шлюзу, фактично відсутній пристрій, що реалізує цю функцію, тобто будь-комутатор фабрики може переписати заголовок і передати пакет в іншу підмережа. Створювані політики доступу і сервісних ланцюжків (ACL, Policy-based routing) працюють в рамках всієї фабрики, оскільки не пов'язані з конкретними комутаторами або інтерфейсами, а з вищерозташованими логічними структурами.

Наскільки потужним і в той же час простим інструментом є BCF, можна судити навіть з того, що комутація і маршрутизація multicast-трафіку в фабриці налаштовується лише перемиканням повзунка «Multicast Enable» у налаштуваннях tenant'а – після цього фабрика може маршрутизувати multicast трафік між підмережами в межах обраного tenant'а, а кожен tenant може оперувати однаковим набором multicast-груп без ризику некоректної передачі пакетів. Порівняйте це з налаштуванням маршрутизації multicast у класичній, великої мережі ЦОД – PIM, IGMP, IGMP snooping — і це на кожному пристрої.

Таким чином, незважаючи на відсутність в технічних характеристиках згадки про знайомих протоколах, централізована архітектура BCF не тільки дозволяє реалізувати будь-яку необхідну функціональність, який необхідний в мережах ЦОД, але і значно розширити її. Особливо це помітно, коли мова заходить про механізми моніторингу, пошуку та усунення несправностей, а також про аналітиці. Механізм Fabric SPAN дозволяє віддзеркалювати трафік всієї фабрики, відфільтроване за параметрами L2-L4 на будь порт будь-якого комутатора. Наприклад, завдання віддзеркалення на інструмент аналітики усього HTTP-трафіку фабрики вирішується створенням єдиної політики Fabric SPAN приблизно за 2 хвилини. У класичній мережі ЦОД рішення подібної задачі займе не тільки істотно більше часу, але і вимагає використання додаткового обладнання.

Інша досить поширена ситуація – немає пов'язаності між двома серверами по певному протоколу. У класичній мережі в цьому випадку починається активний пошук несправностей: ping, traceroute, telnet, аналіз таблиць маршрутизації, списків доступу МСЕ і так далі — коробка з коробкою, консоль за консоллю. У BCF така задача вирішується просто запуском інструменту Test Path: достатньо вказати адреси, протокол порти джерела і призначення і контролер видасть в графічній формі шлях проходження трафіку, точку та опис проблеми, якщо вона є. При цьому в інструменту є 2 режиму роботи: результати першого засновані на аналізі таблиць, які побудував і завантажив на комутатори контролер, а другий перевіряє, як відбувається обробка необхідного пакету на кожному комутаторі і таким чином виходить реальна картина руху трафіку. Процес пошуку та усунення несправностей за допомогою інструменту Test Path, як правило, займає не більше хвилини і проводиться з єдиного графічного інтерфейсу.


Скріншот інструменту Test Path (зображення кликабельно)

Окремо хотілося б розповісти про можливості фабрики по збору, обробці та надання аналітичної інформації. Знову ж завдяки архітектурі BCF c централізованим Control Plane, контролер є єдиною точкою, куди стікаються «сирі» дані про стан апаратної частини комутаторів, лічильниках інтерфейсів, помилки, логах і т. п. Контролер обробляє отриману інформацію, корелює події між собою, зберігає історію і являє отриманий результат у зручній формі, що настроюється. Аналізу доступні як події, що відбуваються у фізичній інфраструктурі (проблеми портів, апаратні проблеми, высокозагруженные інтерфейси тощо), так і події логічної структури (включення/вимикання/переміщення віртуальної машини, інтенсивність трафіку хостів/сегментів тощо). Фактично, спільно з мережевою інфраструктурою ЦОД ми отримуємо потужну систему аналітики, без додаткових вкладень сервера збору і аналізу логів, а також бази даних.


Скріншот аналітичної системи Big Cloud Fabric (зображення кликабельно)
Джерело: Хабрахабр

0 коментарів

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