У пошуках ідеальної мережі: OpenFlow і всі-всі-всі

    Доброго дня, шановні читачі,
 
в цьому пості ми розповімо про своєму пошуку ідеального мережевого рішення для хмарної інфраструктури і про те, чому ми вирішили зупинитися на OpenFlow.
 
 image
 
 
 
 Введення
 Поняття хмари нерозривно пов'язане з двома абстракціями — гарантована якість ресурсів та їх взаємна ізоляція. Розглянемо, як ці поняття застосовуються до пристрою мережі в хмарному рішенні. Ізольованість ресурсів увазі наступне:
 
     
антіспуфінг,
 виділення приватного сегмента мережі,
 фільтрація публічного сегмента для мінімізації впливів ззовні.
 
 Гарантована якість ресурсів — це QoS в загальному розумінні, тобто забезпечення необхідної смуги і необхідного відгуку всередині мережі хмари. Далі — детальний розбір реалізації згаданих концепцій в хмарних інфраструктурах.
 
 Ізоляція трафіку
 
     
Антіспуфінг за допомогою iptables / ebtables або статичних правил в OpenVSwitch: максимально дешеве рішення, але на практиці незручно — якщо для linux bridge правила створюються за допомогою механізму nwfilter в libvirt і автоматично підтягуються при запуску віртуальної машини, для ovs оркестровці доведеться відстежувати момент старту і перевіряти або оновлювати відповідні правила в свіч. Додавання або видалення адреси або міграція віртуальної машини перетворюються в обох випадках в нетривіальну задачу, перекладається на логіку оркестровки. У момент запуску нашого сервісу в публічне використання ми застосовували саме nwfilter [1 ], але були змушені перейти на OpenFlow 1.0 через недостатню гнучкості рішення в цілому. Також варто згадати досить екзотичний метод фільтрації вихідного трафіку за допомогою netlink для технологій, що працюють в обхід мережевого стека хоста (macvtap / vf), який свого часу не був прийнятий в ядро, незважаючи на високу комерційну затребуваність.
  
 Антіспуфінг за допомогою правил в свіч рівня стійки (ToR switch) при перенесенні в нього портів віртуальних машин за допомогою одного з механізмів тунелювання трафіку безпосередньо від інтерфейсів віртуальних машин (див. картинку нижче). Як плюсів такого рішення можна відзначити зосередження логіки на свіч == відсутність необхідності її «розмазування» з програмних Свіча обчислювальних нод. Маршрут трафіку між машинами однієї обчислювальної ноди завжди буде проходити через свіч, що може бути не завжди зручно.
 image
 
ToR filtering © networkheresy
  
 Антіспуфінг при перевірці полів у OpenFlow мережі — коли всі свічі, фізичні та віртуальні, підключені до групи контролерів, які забезпечують, крім перенаправлення і трансформації полів трафіку всюди, його очищення на рівні програмного свіча обчислювальної (compute) ноди. Це найскладніший і гнучкий з можливих варіантів, оскільки абсолютно вся логіка, починаючи від пересилання датаграмм всередині звичайного свіча, буде винесена в контролер. Неповні або неконсістентние правила можуть призвести або до порушення зв'язності, або до порушення ізоляції, тому системи з великим відсотком реактивних (задающихся динамічно за запитом від свіча) правил слід тестувати за допомогою, фреймворків зразок NICE [2 ].
  
 Виділення сегмента мережі — рішення, що практикуються у великих гомогенних структурах, при цьому за групою віртуальних машин закріплюється або прив'язка до фізичних машинам (і портам фізичного свіча), або до тегу інкапсуляції якого типу (vlan / vxlan / gre). Кордон фільтрації знаходиться на стику L2 сегмента, інакше кажучи, сегменту виділяється підмережа або набір підмереж і неможливість їх підміни обумовлюється роутингом у вищестоящій інфраструктурі, приклад — OpenStack Neutron без гібридного драйвера Nova [3 ]. Глибокого теоретичного інтересу цей підхід не представляє, але має широку практичну поширеність, успадковану від до-віртуалізаційних епохи.
  
 
 
 Управління трафіком
Оптимізація маршрутів таким чином, щоб використовувати можливості мережевих лінків по-максимуму (інакше кажучи, знаходження максимуму Cумма min-cut [4 ] для всіх пар взаємодіючих кінцевих точок з урахуванням їх ваг, тобто пріоритетів QoS), вважається найбільш складним завданням в розподілених мережах. IGP, покликані вирішувати цю проблему, в загальному випадку є недостатньо гнучкими — трафік може бути відсортований тільки на підставі заздалегідь виділених міток QoS і про динамічному аналізі і перерозподілі трафіку припадає не думати. Для OpenFlow, оскільки кошти аналізу окремих елементів трафіку є невід'ємною частиною протоколу, вирішити це завдання досить нескладно — достатньо побудувати коректно працюючий класифікатор окремих потоків [5 , 6 ]. Ще один безперечний плюс OpenFlow в цьому випадку — в централізованому підрахунку стратегії форвардинга можливо врахувати безліч додаткових параметрів, які просто не включені ні в один зі стандартів IGP.
 
Проектування мережі навіть невеликої датацентру з гетерогенним наповненням (вміст одночасно безлічі роздрібних пользоватей без фізичної прив'язки групи машин до стійки), призводить до задачі побудови розподілених L2-over-L3 мереж (overlay networks) [7 ] за допомогою одного з існуючих механізмів, через неможливість технічно помістити десятки тисяч віртуальних хостів в один широкомовний сегмент звичайними способами. Зазначені технології дозволяють «розвантажити» логіку форвардинга, оскільки обладнання тепер оперує мітками, відповідними групами хостів замість окремих адрес в приватних (і, можливо, публічних) сегментах користувальницьких мереж. За дешевизною і порівняльною простотою впровадження криється прив'язка як мінімум до виробника мережевого устаткування і кінцева недетерминированность — якщо відволіктися від деталізації, все оверлейні протоколи надають навчаний свіч всередині окремої мітки, що може викликати труднощі при оптимізації трафіку всередині оверлейного сегмента, через «развязанность» протоколів маршрутизації третього рівня і механізмів самого оверлею. Вибираючи OpenFlow, ми зводимо все управління трафіком до одного рівня прийняття рішень — мережевого контроллера. Оверлеї або замісник їх власний механізм, безумовно, можуть виконувати ту ж роль щодо зменшення обсягу правил в свіч-аггрегатор (spine на зображенні нижче), а оптимізація напрямки трафіку на ToR Свіча (leaf) відбуватиметься, базуючись на довільному наборі метрик, на відміну від простої балансування (як, наприклад, в ECMP).
 
 image
 
Дворівневий spine-leaf
 
 OpenFlow
 Стандарт OpenFlow в першому промислово доступному варіанті, 1.0, став доступний у складі залізних свічів більше року тому, але ця версія мала кілька архітектурних обмежень, які перешкоджали масовому впровадженню, і найбільш проблемне з них — відсутність множинних послідовних таблиць для обробки, то є одне правило відповідало рівно одній парі взаимодействовавших кінцевих точок, без урахування додаткових збігів [8 ]. Використання OpenFlow 1.0 проактивним чином (тобто із створенням всіх необхідних правил заздалегідь) вело б до квадратичного росту числа правил від числа взаємодіючих хостів, як представлено на на картинці нижче.
 image
 
Порівняння OF 1.0 і 1.3 © Broadcom Corp
 Частковим виходом із ситуації є використання механізму learning switch — тобто проактивної роботи OpenFlow свіча, коли правила запитуються кожен раз, коли вони не збігаються ні з одним, вже поміщеним в таблицю форвардинга свіча, а через певний TTL — видаляються з свіча. Стратегія видалення може бути як «жорсткої» — видалення через заданий проміжок часу після установки правила, так і «м'якої» — видалення відбувається тільки в відсутність активності за заданий проміжок часу «всередині» конкретного потоку. На момент початку використання нами OF жоден з відкритих програмних контролерів не підтримував нові версії, згадана вище гонитва за гнучкістю підходу управління зупинилася саме на стандарті 1.0. Модель learning switch виправдовує себе на значній кількості навантажень, непредолімим перешкодою для неї стають лише додатки на зразок лічильників, генеруючі сотні і тисячі унікальних запитів в секунду на рівні свіча, також вона схильна атаці швидкого спуфинга — клієнт, що генерує пакети з унікальними IP / MAC ідентифікаторами, як мінімум, здатний привести в неробочий стан свіч рівня обчислювальної ноди, а якщо заздалегідь не подбати про обмеження PACKET_IN (повідомлень на обробку потоку для контролера), то і цілий сегмент мережі.
 
Після того, як всі елементи нашої мережі (що базується на OpenVSwitch), отримали оновлення, достатню для використання стандарту 1.3, ми негайно перейшли на нього, розвантаживши контролери і забезпечивши приріст продуктивності форвардинга (на перерахунок за усередненим pps) на півтора-два порядки, за рахунок переходу на проактивні флоу для переважної обсягу трафіку. Необхідність розподіленого аналізу трафіку (без прокачування всього обсягу через виділені ноди-класифікатори з класичним фаєрволом) залишає місце для реактивних флоу — ними ми аналізуємо незвичайний трафік.
 
 Про сьогодення
 Підтримка сучасних стандартів OpenFlow виробниками доступного мережевого обладнання ToR у форматі whitebox [9 ] на сьогоднішній день обмежується рішеннями на базі Windriver (Intel), Cumulus (Dell) і Debian в свіч Pica8, всі інші вендори або надають свічі більш високої цінової категорії, або зловживають власними несумісними розширеннями / механізмами. За історичними обставинами нами використовується Pica8 в якості ToR свічів, але політика виробника, переклав GPL-дистрибутив на платну підписку, дуже обмежує область потенційної взаємодії. Сьогодні відкриті платформи Intel ONS або Dell (базовану на Trident II ), при досить скромною ціною (<10K $ за 4 * 40G +48 * 10G), дозволяють управляти трафіком декількох десятків тисяч віртуальних машин в масштабі однієї промислової стійки з 1-6 Тб пам'яті, використовуючи OpenFlow (1.3 +).
 
Озираючись назад, зазначу додаткові плюси подібної розробки — занурення в проблематику програмно-визначених підмереж і розширення власної екосистеми. Використання OpenFlow для управління трафіком і програмного сховища Ceph для забезпечення високої доступності даних, дозволяє заявити про собі , як про реалізацію software-defined datacenter , хоча попереду ще багато роботи на шляху до ідеалу.
 
Спасибі за увагу!
 
 Посилання
 [1]. libvirt — nwfilter
 [2]. NICE
 [3]. OpenStack Neutron
 [4]. Max-flow/Min-cut
 [5]. B4 — WAN мережу гугля на OpenFlow
 [6]. Докладний розбір одного з алгоритмів QoS-орієнтованого TE
 [7]. Хороша стаття про overlay networks
 [8]. OF: 1.0 vs 1.3 table match
 [9]. Why whitebox switches are good for you
    
Джерело: Хабрахабр

0 коментарів

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