Сеть Fan.

Разработчики Canonical отметили, что с развитием контейнерной технологии стало возможно запускать сотни, если не тысячи образов операционной системы на одной системе. И такое массовое размножение контейнеров внесло интересную сетевую проблему: "как эффективно взаимодействовать по сети множеству контейнеров? Что делать, если какому-то контейнеру нужен маршрут только к другому, конкретному контейнеру?"

Canonical представляет своё элегантное решение - Fan. Fan - расширение сетевого туннельного драйвера ядра linux. Fan был задуман Марком Шаттлвортом (Mark Shuttleworth) и Джоном Мейнелем (John Meinel), а реализован Jay Vosburgh и Andy Whitcroft.

Базовая концепция.

Каждый хост, запускающий контейнеры, обладает fan bridge, который позволяет всем своим контейнерам детерминировано определять отображение сетевых потоков к любому другому контейнеру в данной fan network. Детерминировано в данном случае означает, что нет никакой распределённой базы, протокола нахождения консенсуса или ещё чего-то, увеличивающего оверхед IP-IP туннеля.

Кратко принцип такой. Fan - это отображение (map) между маленьким адресным пространством (underlay, обычно /16) и большим (overlay, обычно /8). Целая подсеть из бо́льшего пространства отображается на IP адрес меньшего пространства, обеспечивая автоматическое и простое туннелирование, маршрутизацию между системами.

Система Fan своего рода расширитель пространства, умножитель IP адресов, дающий 253 адреса каждому хосту из /16.

Математическое сопоставление underlay <-> overlay позволяет не хранить и не отслеживать базу адресов, а постоянно его вычислять когда это необходимо.

Как это работает?

К примеру, есть 172.16.0.0/16 локальная сеть, объединяющая хост системы. Она будет для нас underlay. Возьмём сеть 10.0.0.0/8 - overlay. Для примера, простое адресное отображение: 172.16.3.4 -> 10.3.4.0/24 Это будет означать, что есть машина с адресом 172.16.3.4, обладающая fan bridge с именем fan-10-3-4, за которым размещена сеть 10.3.4.0/24.

За кулисами происходит следующее. Fan mapping device инкапсулирует любой трафик, идущий через него, и обращается к нужному underlay IP. Например, контейнер С1 (10.5.6.25) на хосте VPC_A 172.16.5.6 хочет связаться с С2 (10.3.4.25). Fan bridge инкапсулирует пакет и адресует нужному хосту, в данном случае 172.16.3.4. Хост VPC_B 172.16.3.4, получив и распакуя пакет, отправляет его 10.3.4.25.

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

Итог.

Разработчики отмечают достоинства своей системы: детерминированное вычисление маршрутов, отсутствие протоколов нахождения консенсуса, высокая скорость и не принадлежность(!) к классу Software-Defined Networking. Честно отмечают минус системы: математическое отображение адресов не работает с Live Migration. Контейнер со своим адресом, перейдя на другой хост, не сможет быть сопоставлен правильно.

Разработчики не только представили готовый инструмент, который можно уже пощупать, но и накатали RFC для продвижения Fan. Адаптированы такие технологии как LXC, LXD, MAAS, Juju, Docker.

Дата последней правки: 2023-12-27 15:28:01