Previous Entry Share Next Entry
О баззвордах: multi-tenancy
404
amarao_san
Вы знаете, среди всех баззвордов, самым серьёзным является 'multi-tenancy'. Именно наличие "multi-tenancy" превращает уже давно существовавшие админки для управления виртуалками в "облака", уютненький серверочек для бложиков в "платформу для SaaS" и прочее и прочее.

Понятие сводится к очень простым терминам: "поддержка нескольких независимых пользователей". Но за этим стоит самая большая проблема, и административная, и техническая, какую можно только придумать.

Причём эта "поддержка" проходит через все слои и уровни системы.

Например, допустим, у нас некий новый ethernet-switch (допустим, умеющий l3, но не умеющий BGP), к которому мы приделываем multi-tenancy.

С чего начать? Ну, раз это свитч, то он может коммутировать. Независимость пользователей означает, что они не должны видеть трафик друг друга. Ура, в существующих технологиях есть виланы. Но пользователи хотят пользоваться виланами для своих нужд - у них свои группы серверов, изоляция, dmz, всё такое. И им нужны их собственные теги, и да, у двух теннантов есть по сотому вилану, который значит совсем разные вещи и уж точно не должен пересекаться.

Почесав в затылке технари идут, и приделывают "tVLANS", которые действуют только в пределах коммутатора и позволяют портам назначать tVLAN, таким образом, что трафик ходит только между tVLAN+VLAN, причём VLAN может приходить как теггированный, так и нетеггированный. Ура, наш свитч получил капельку multi-tenancy.

Но у нас полоса внутри коммутатора меньше, чем сумма полос всех портов. Допустим, у нас скромный 4х-юнитовый свитч с 192 10G-портами, но внутри эта штука способна пропустить через себя только всего лишь 1.2Тб/с, то есть обслужить загруженными 120 из 192 портов. Поскольку мы хотим много денег за свитч, то приходится эту проблему решать. Мы решаем её, дав администратору выбор между shared policy, limit policy и proportional policy. Не очень гибко, но на первое время сойдёт. shared policy означает "кто сколько хапнет, столько и получит, если есть что получить", limit policy позволяет ограничить число обработанных байтов/пакетов с портов тенанта заданным числом (per tenant), а proportional означает, что каждый порт получает гарантированную полосу в 6.25Гбит/с, а остаток свободной полосы раздаётся как shared. (на первое время пойдёт, потом разработчиков сожрут, требуя одним тенантам лимит, вторым шаред, третьим proportional, и всё это одновременно).

Ок, наша multi-tenancy получила прибавку - теперь мы ещё и распределяем полосу согласно политикам.

Но тенант хочет управлять полосой своих портов - и мы вкручиваем tenant-policy, которая позволяет тенанту управлять распределением доставшейся ему полосы между его портами. Наш свитч получает ещё одну функцию от multi-tenancy: tenant-managed resources.

Но если бы у нашего свитча полоса была единственной проблемой... Наша таблица mac-адресов на портах была общей, просто были добавлены поля tVLAN+VLAN.

И тут случилась катастрофа. Два тенанта ткнулись одинаковыми mac'ами (виртуалок на своих серверах) в наш свитч. Такого быть не должно - mac уникальный, но клиент всегда прав.

Заодно и вторая проблема подкатилась - когда у клиента начинается вирусня с mac-spoofing, то нашу табличку выедает злой вирус, мешая остальным работать.

Инженеры сначала предложили выделять лимит на число записей per tenant, но это не решало проблему дублирующихся mac'ов. Для её решения было решено сделать таблицу per tvlan+vlan, а её размер позволять задавать администратору (из общей квоты). И те же три полиси по размерам таблиц.

Тут же подбежал продакт-менеджер и теперь у тенанта есть возможность так же играться размерами таблицам per vlan.

Наш свитч выглядит уже как очень крутое carrier grade enterprise full suite complete solution...

Но эта дрянь умеет l3! Между виланами. И тенантами. К счастью, проблему поймали уже после того, как свитч продали, но до того, как начали его делать.

Судорожно инженеры порезали по аналогии таблицы маршрутизации, размер arp-таблицы и всё остальное, с маршрутизацией связанное. Так как путь был отлаженный, теперь клиент может лимитировать размер arp на каждый вилан, иметь полиси и т.д.

Если бы не новая проблема: изоляция-изоляцией, а в интернеты все хотят. А интернет приходит от провайдера/администратора, через ту же маршрутизацию.

В этот момент команда подумала, что multi-tenant свитч с маршрутизацией это была ошибка. К счастью, "общую маршрутизацию" никому не продали, так что текущим клиентам можно было рассказывать про то, что так и положено.

Но они во-первых были не довольны, во-вторых отделу продаж в голову пришла светлая идея "сделать и продавать".

И вот тут вот инженеры пригорюнились. Одно дело независимая маршрутизация между vlan'ами внутри tenant'а, другое дело - что-то громоздкое, сверху.

Поскрипели-поскрипели, и придумали - администратор может настраивать специальные transitional virtual ifaces, которые настраиваются администратором и выдаются тенанту уже настроенными. В какой из виртуальных маршрутизаторов его тыкать, как маршрутизировать - уж дело тенанта.

Счастье? Почти. Быстро выяснилось, что интернета на всех не хватает - аплинк - 4x40Гбит, а внутри потенциальная потребность в интернетах - до 1200Гбит/с. И вообще, интернет надо считать.

Пришлось делать во-первых полиси, во-вторых аккаунтинг, причём оказалось, что во-первых тенанты хотят то же самое для себя по своим виланам, а в третьих аккаунтинг кому-то нужен по 95% персентилю, кому-то по коммитменту (то есть по проданному лимиту), кому-то по трафику.

Поскрипели, сделали. Теперь-то свитч стал напоминать настоящего multi-tenant. Кстати, под шумок под "тенанту тоже хочется" - было реализовано multi-tenant API, multi-tenant CLI, поддержка внешней авторизации LDAP/AD/Radius, плюс поддержка идентификации пользователей тенанта с использованием внешнего источника информации тенанта (например, его LDAP-сервера).

Ну уж теперь продукт стал выглядеть готовым... Пока, внезапно, не возникла проблема стыковать два таких коммутатора вместе.

Но эту печальную сказку я уже рассказывать не буду.

Вот что такое multi-tenancy, и вот почему это такой важный buzzword...

  • 1
Это ты сейчас подсмотрел, или ещё в РФ?

Что значит "посмотрел"? Я в этой индустрии уже почти 5 лет, из них приличная часть времени посвящена разным местам, где находятся проблемы с multi-tenancy.

>tVLAN+VLAN
чем не подошел банальный QinQ ?

>Но эта дрянь умеет l3
Оно не умело VRF?

Общего развития ради: каких вендоров юзаете для таких задач?

Можно qnq, я просто описывал гипотетический процесс в контексте multitenancy.

У нас вообще софтовое решение. Overlay network, все такое.

Приветствую! У меня тут возникло n-ное количество полурабочих мыслей как раз про эти самые свитчи - вспомнил про этот пост. Можно их в каком-то более приватном (в идеале - интерактивном) попробовать обсудить? E-mail, IM? amarao@jabber.ru вижу, но не знаю, используется и удобно ли.

Можно. Я у компьютера буду часа через полтора.

Ack, спасибо. Я тогда на @jabber.ru отправил запрос - если удобнее что-то другое - скажи, куда лучше :)

  • 1
?

Log in

No account? Create an account