Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Привет, хабровчане. В преддверии курса "Архитектор сетей" подготовили для вас перевод интересной статьи.
Один из моих читателей прислал мне следующий вопрос (вероятно, задумавшись над замечанием, сделанным мной на вебинаре по сетевым возможностям AWS):
Вы упомянули, что AWS не использует EVPN в качестве своей оверлейной плоскости управления, вероятно, потому что эта технология не подходит для их масштабирования. Не могли бы вы раскрыть эту тему, пожалуйста? Я сейчас делаю PoC (проверку концепции) EVPN, и мне интересно узнать об этом больше.
Можно с уверенностью предположить, что AWS использует какую-то оверлейную виртуальную сеть (как и любой другой разумный крупномасштабный облачный провайдер). Подробностей мы не знаем; AWS никогда не испытывал необходимости использовать конференции в качестве способа набора персонала, и то немногое, что они рассказали нам на re:Invent, описывает систему в основном с точки зрения клиента.
Также можно с уверенностью предположить, что у них есть по несколько сотен тысяч серверов (оверлейных эндпоинтов виртуальных сетей) в одном регионе. Реализация BGP поверх этого была бы интересной инженерной задачей, а фильтрация посторонней информации, которая не нужна хостам гипервизора (ORF на основе RT), была бы сущем весельем. Однако я уверен, что они не используют EVPN не поэтому — EVPN просто не тот инструмент, который нужен для этой работы.
Хотя кажется, что EVPN и все, что используют AWS или Azure, решают одну и ту же проблему (разметку пользовательских IP- и MAC-адресов в транспортные next-hop-ы), между средами, для которых был разработан EVPN, и инфраструктурой публичного облака IaaS существует масса фундаментальных различий.
В оставшейся части этой статьи я буду использовать аббревиатуру VTEP для обозначения транспортных next-hop-ов, даже несмотря на маловероятность того, что AWS использует VXLAN - у AWS была работающая система еще до того, как была изобретена VXLAN. VTEP означает Virtual Tunnel EndPoint.
Типичная среда L2VPN имеет динамические эндпоинты. MAC- и IP-адреса обнаруживаются локально с помощью любого инструмента обнаружения (MAC learning, DHCP/ARP snooping…) и должны быть распространены на все другие периферийные устройства сети. В правильно реализованной масштабируемой облачной инфраструктуре система оркестровки контролирует присвоение MAC- и IP-адресов. Нет абсолютно никакой необходимости в динамическом обнаружении эндпоинтов или динамическом распространении информации об эндпоинтах. После запуска виртуальной машины через систему оркестровки маркировка MAC-to-VTEP распространяется на все другие хосты гипервизора, участвующие в той же виртуальной сети.
Эндпоинты могут перемещаться в среде L2VPN. Хотя перемещение эндпоинтов в WAN не является обычным делом, они достаточно много перемещаются в корпоративных центрах обработки данных — vMotion во всех его вариациях (включая причудливые) — самая популярная вещь для виртуализации. Хуже того, при использовании таких технологий, как VMware HA или DRS, конечные точки перемещаются без участия системы оркестровки. EVPN идеально подходит для такой среды.
В большинстве крупномасштабных публичных облаков эндпоинты не перемещаются, и единственный способ отключить виртуальную машину от сервера — это перезапустить ее, а в случае сбоя сервера виртуальные машины, работающие на нем, должны быть перезапущены через систему оркестровки. Нет абсолютно никакой необходимости в автономном протоколе распространения эндпоинтов.
EVPN пытается справиться со всякого рода дикими сценариями, такими как эмуляция MLAG или наличие нескольких подключений в мостовой сети. Таких чудовищ никогда не наблюдалось в крупномасштабных публичных облаках… возможно, потому, что у людей, которые ими управляют, слишком много важной работы, чтобы растягивать повсюду VLAN. Она также была бы кстати, если вы достаточно велики, чтобы не заботиться о избыточных соединениях с серверами, потому что вы можете позволить себе потерять все 40+ серверов, подключенных к ToR коммутатору, не моргнув глазом.
Что еще интереснее: виртуальные сети в облачных инфраструктурах требуют больше, чем просто доступность эндпоинтов. Как минимум, вы должны реализовать фильтры пакетов (группы безопасности), и хотя истинный сторонник BGP может захотеть использовать для этого FlowSpec, большинство здравомыслящих людей плюнут на эту затею намного раньше.
Принимая во внимание все вышесказанное, что же может являться подходящей плоскостью управления между облачной системой оркестровки и эндпоинтами гипервизора? На ум приходят сразу два механизма:
API на гипервизоре, который вызывается системой оркестровки всякий раз, когда ему нужно настроить параметры гипервизора (запустить виртуальную машину, создать сеть/подсеть/группу безопасности, установить маркировку MAC-to-VTEP…)
Шина сообщений между системой оркестровки и гипервизорами. Тот, у кого есть новый бит информации, пробрасывает его в шину сообщений, и он волшебным образом распространяется среди всех получателей, заинтересованных в этой информации, в нужное время.
Исходя из моего опыта со скоростью AWS и с системами оркестровки Azure, я подозреваю, что AWS использует первый подход, а Azure — второй.
EVPN не является ни тем, ни другим. Без фильтрации информации BGP представляет собой согласованную базу данных, которая передает одну и ту же информацию на все эдпоинты. Не совсем то, что нам может понадобиться в этом конкретном сценарии.
Короче говоря: EVPN — это интересная технология, но, вероятно, неправильный инструмент для реализации плоскости управления облачной инфраструктуры, которая должна предоставлять виртуальные сети для клиента. Тем не менее, она используется в качестве технологии шлюза между таким облаком и физическими устройствами. Juniper Contrail был первым (о котором я знаю), который использовал его таким образом, и даже VMware отказалась от попыток подтолкнуть всех остальных усыновить странного ребенка, которого они получили с приобретением Nicira (OVSDB), и переключилась на EVPN в NSX-Т 3.0.
Дополнительная информация
Хотите узнать, как работают сети в публичных облаках?
Начните с AWS Networking 101 и Azure Networking 101.
Когда вы будете готовы к большему, ныряйте в вебинары по сетям AWS и Microsoft Azure.
Когда вы почувствуете, что пора по-настоящему освоить облачные сети, пройдите онлайн курс Networking in Public Cloud Deployments.
Заинтересованы в EVPN? Мы о вас уже позаботились — в блогах есть множество постов связанных с EVPN, и мы исследовали EVPN с точки зрения центра обработки данных и поставщика услуг в вебинаре EVPN Technical Deep Dive.
Наконец, я описал NSX-Vи NSX-T на вебинаре VMware NSX Technical Deep Dive и сравнил ее с Cisco ACI на вебинаре VMware NSX, Cisco ACI or Standard-Based EVPN.
Узнать подробнее о курсе и записаться на бесплатный вебинар "Overlay. Что это такое и зачем необходимо" можно здесь.
