Последнее время в материалах различных конференций по сетевым технологиям, обзорах, статьях стали всё чаще встречаться такие термины, как TRILL, FabricPath, VXLAN, OTV и LISP, особенно в разрезе построения ЦОДов. Ловишь себя на мысли, а что же это такое? Конечно, многие из них, как звёзды, достаточно далеки от нашей повседневной реальности. Но все-таки, наверное, было бы не плохо понять, хотя бы в общих чертах, а что же это всё значит. Более того, вроде как, все они меняют привычные принципы работы сети: коммутация по каким-то меткам, маршрутизация какая-то не такая, да и адресация хоста совсем уже не та. В общем, предлагаю попробовать со всем этим разобраться.
Статья будет разбита на три части. В первой части рассмотрим, что такое оверлейные технологии. Разберёмся с предпосылками появления новых оверлейных технологий для ЦОД, а также их общей классификацией. Остальные части будут посвящены уже непосредственно технологиям TRILL, FabricPath, VXLAN, OTV и LISP.
Итак, все эти технологии объединяются под общим названием — оверлейные сетевые технологи. Как мы знаем, оверлейные технологи позволяют нам получить новую логику работы сети, используя в качестве основы стандартные протоколы. Т.е. это надстройка, обеспечивающая нас новыми сервисами. Обычно оверлейные технологии используют дополнительные заголовки, которые присоединяются к исходному пакету. Это позволяет абстрагироваться от заголовков изначального пакета и обеспечить дальнейшую передачу по сети на основе оверлейного заголовка.
Примером такой технологии может является VPN (в частности IPSec в туннельном режиме). VPN позволяет нам проложить туннель поверх сети. Далее внутри этого туннеля мы можем передавать любые данные. Транспортная сеть будет маршрутизировать такие данные только на основании заголовка VPN. Таким образом, с помощью технологии VPN мы как бы меняем стандартные правила маршрутизации трафика, обеспечивая передачу нужных нам данных поверх сети. Примеров оверлейных технологий огромное множество. Но давайте остановимся на тех, которые появились и используются в первую очередь для построения ЦОДов.
В цикле данных статей хотелось бы обзорно разобрать предпосылки появления новых оверлейных технологий для ЦОД, попытаться их классифицировать, отметив основные моменты по наиболее распространённым и актуальным на сегодня технологиям. В основном речь пойдёт про технологии, которые поддерживаются оборудованием Cisco, так как мне именно с ним приходится чаще всего иметь дело. Безусловно, у других производителей сетевого оборудования есть схожие технологии, однако их разбор останется вне рамок нашего обзора.
Откуда же возникла потребность в каких-то новых оверлейных технологиях? Ещё недавно трёхуровневая архитектура построения сети обычно не вызывала каких-то вопросов. Количество доступных VLAN’ов равное 4096, воспринималось как достаточно большое число. Стандартные правила коммутации и маршрутизации трафика являлись незыблемыми постулатами, на которых держится
Все мы давно привыкли к традиционной трёхуровневой архитектуре построения сетей: уровень доступа (access), уровень агрегации/распределения (aggregation) и ядро (core). Между ядром сети и уровнем распределения обычно используется маршрутизация (L3), между уровнем доступа и распределения коммутация (L2) или маршрутизация (L3). В ряде случаев ядро сети и уровень распределения могут быть совмещены.
Однако, появление и активное использование виртуализации, а также рост ЦОДов (в размере) выявил целый ряд новых требований к сети:
- Необходимость обрабатывать большое количество MAC-адресов. Следовательно, повышенные требования к MAC-таблицам коммутаторов (таблицам, где хранятся записи соответствий MAC-адреса, порта коммутатора и другой служебной информации). Теперь за одним физическим сервером могут находиться десятки виртуальных машин (каждая со своим MAC-адресом), а количество самих серверов в некоторых ЦОДах стало измеряется тысячами.
- Поддержка более 4К VLAN: опять-таки, причина в применении виртуализации, теперь есть возможность обслуживать большее количество пользователей. При этом каждый пользователь требует свой изолированный сегмент сети. Причём иногда требуется даже несколько сегментов на одного пользователя.
- Мобильность: виртуальная машина должна иметь возможность переезжать между хостами как внутри ЦОДа, так и между ЦОДами. При этом для ряда технологий (например, Vmware vMotion) хосты в этом случае должны находится в одном L2 домене.
- Эластичность и унификация: приложение может находиться на любом сервере, при этом не важно, где физически будет располагаться сам сервер.
- Взаимодействие «все со всеми»: произошло существенное увеличение трафика между серверами внутри ЦОДа (так называемый «east-west» трафик), так как сервисы могут находится в любой точке ЦОДа (опять же из-за виртуализации).
- Другие требования: энергоэффективность, управляемость и пр.
Не трудно заметить, что новые требования стали плохо укладываться в традиционную трёхуровневую архитектуру построения сети при использовании привычных нам протоколов.
В частности, требование прозрачной мобильности виртуальных машин заставляет нас «растянуть» широковещательный домен между всеми коммутаторами уровня доступа. А это влечёт за собой дополнительные издержки на его обслуживание. Потребуется использовать протокол STP. А значит часть каналов будет заблокирована или недостаточно утилизирована, не всегда будет оптимальная передача трафика. Также имеем повышенную нагрузку на MAC-таблицы коммутационного оборудования и проблемы с флудингом (широковещательного трафика и пр.).
Модель взаимодействия «все со всеми» также выявляет определённые проблемы: наиболее загруженное место сети – её ядро, плюс мы имеем большое количество хопов при передаче трафика между серверами, подключённые через различные коммутаторы уровня агрегации. А хотелось бы, чтобы количество хопов равнялось одному, при этом все каналы равномерно утилизировались.
Идеально было бы, например, объединить в себе плюсы маршрутизации и коммутации, получив возможность:
- миграции виртуальных машин, без потребности в большом широковещательном домене;
- балансировки трафика для равномерной утилизации всех каналов с минимальным количеством хопов при его передаче.
Так как полностью перестроить сеть (заменить все сетевые протоколы и оборудование) невозможно, были разработаны новые сетевые оверлейные технологии. Данные технологии в общем случае можно разделить на два типа:
- работающие на сетевом оборудовании — Network-based (или Switch-based),
- работающие на оконечном хосте (точнее сказать на виртуальном коммутаторе) — Host-based.
В обоих случаях к исходному пакету добавляется специализированный заголовок. Дальнейшая передача пакета происходит уже с использованием нового заголовка. В случае Network-based процесс инкапсуляции и деинкапсуляции происходит на коммутационном оборудовании. Оконечный хост даже не догадывается, что пакет передаётся каким-то специальным образом. В случае Host-based добавление специализированного заголовка выполняет сам хост. При этом коммутационное оборудование теперь ничего не подозревается об использовании оверлейных технологий.
Особенности реализации Network-based и Host-based оверлейных технологий
| Network-based | Host-based |
|---|---|
| «Железо» должно поддерживать данную технологию | Нет информации о топологии сети. Возможна неоптимальная передача трафика |
| Повышенные требования к MAC-таблице для ToR (Top-of-Rack) коммутаторов | Возможные проблемы с производительностью, так как процесс инкапсуляции/деинкапсуляции выполняет сам хост |
Кстати сказать, ещё одним «заказчиком» оверлейных технологий стали программно-определяемые сети (Software-defined Networking — SDN). Так как одна из задач SDN – обеспечение достаточно гибких правил работы сети, добиться этого без новых технологий тяжело. Оверлейные технологии отлично подходят для обеспечения передачи дополнительной информации для каждого пакета (например, для обеспечения функций безопасности или сегментации), быстрой организации связи между хостами (например, организация L2 соединения), обеспечение работы различных клиентских сетевых технологий (их туннелирование) внутри транспортной сети ЦОД и пр. В частности, SDN от компании Cisco (Application Centric Infrastructure — ACI) использует как базовую технологию VXLAN.
Безусловно, нет одной самой лучшей оверлейной технологии, которая бы полностью решала все проблемы, стоящие при построении ЦОД. Более того существуют целые классы таких технологий, реализующие какую-то одну задачу, например, организацию связи ЦОД между собой. Поэтому их зачастую используют совместно друг с другом.
Прежде чем двигаться дальше, хотелось бы отметить, что вместе с новыми оверлейными технологиями, появились и новые архитектуры построения ЦОДов. Например, стала использоваться архитектура Clos, её производная Fat-Tree и пр. Считается, что данные архитектуры более адаптированы к реалиям современных ЦОДов.
Зачем я упомянул о них? Ведь речь у нас про оверлейные технологии. Ответ прост. Некоторые оверлейные технологии в своей работе для получения максимального эффекта опираются на новые архитектуры. В частности, TRILL/FabricPath лучше всего работают поверх Clos сети. Данная архитектура предполагает наличие большого количества связей между устройствами и выполнение простого правила: коммутаторы определённого уровня соединяется лишь с коммутаторами вышестоящего уровня и нижестоящего, не имея связи между собой. На рисунке приведён пример простейшей двух уровневой Clos сети.
Такая архитектура достаточно просто расширяется. Она позволяет получить хорошую суммарную пропускную способность. В ней мы имеем большое количество одинаковых маршрутов между устройствами уровня доступа (Leaf). Также существенно уменьшается влияние отказов коммутационного оборудования на общую производительность сети, так как нет какого-то выраженного центра.
На этом, думаю, введение пора завершать. В следующих статьях мы перейдём уже непосредственно к интересующим нас технологиям, а именно TRILL, FabricPath, VXLAN, OTV и LISP. А в конце подведём некоторые итоги.
