Александр СКОРОХОДОВ, системный инженер-консультант, компания Cisco
В последние годы термин «сетевые фабрики» является одним из самых популярных в индустрии сетей ЦОД. В настоящей статье мы попытаемся разобраться с его значением, обсудим свойства и преимущества сетевых фабрик, развитие подходов к их построению и то, как они воплощаются в новых решениях, появляющихся на рынке.
Для начала: откуда вообще появилось понятие «фабрика» применительно к сетям? В русском языке это слово обычно обозначает промышленное предприятие, но в данном случае речь идет о кальке с используемого в англоязычной практике слова fabric, основное значение которого – «ткань». Первоначально термин «фабрика» в контексте телекоммуникационных технологий появился, по всей видимости, применительно к матрице коммутации, используемой для передачи данных внутри многих коммутаторов (еще со времен аналоговой телефонии) – архитектура такой матрицы может быть представлена как решетка из вертикальных и горизонтальных линий, соответствующих ее входным и выходным каналам, и действительно немного напоминает переплетение волокон ткани. Возможно также, что имелась в виду роль сети как «связующей ткани» между подключенными к ней узлами. В сетях термин «фабрика» впервые стал использоваться применительно к сетям хранения (SAN), где фабрику образует набор коммутаторов, взаимодействующих по управляющим протоколам, что обеспечивает единые сервисы адресации, безопасности и т. д., а также доставку данных по оптимальному маршруту. Применительно к сетям передачи данных в ЦОД это понятие появилось несколько лет назад и в целом означает сеть, «выглядящую как коммутатор», – решение с простой архитектурой, обеспечивающее высокую масштабируемую производительность и гибкость в выборе места размещения нагрузок. Детальное определение этого термина отсутствует, и разные участники сетевой индустрии используют понятие сетевой фабрики для заметно отличающихся друг от друга решений.
Требования, на выполнение которых направлены фабрики, продиктованы ключевыми тенденциями развития современных ЦОД, такими как развитие виртуализации, облачных и распределенных вычислений. В число этих требований входят:
- высокая горизонтально масштабируемая полоса передачи внутри фабрики, необходимая для распределенных вычислений и мобильности нагрузок;
- отказ от базирования на протоколе SpanningTree, блокирующим все «лишние» соединения и являющимся потенциальным источником отказов в масштабах всей сети;
- стабильность функционирования, выражающаяся в минимизации влияния отказов устройств и локальных сбоев на функционирование сети в целом.
Приведенные требования сложно реализовать в традиционном многоуровневом сетевом дизайне. С точки зрения сетевой архитектуры фабрик наиболее популярной топологией (а для многих типов фабрик – и единственно рекомендуемой или поддерживаемой) является так называемая сеть Клоза (Closnetwork). Она названа по имени исследователя Чарльза Клоза, опубликовавшего в 1953 г. статью, описывающую построение неблокируемой сети с большим количеством подключений, состоящей из коммутаторов с ограниченным числом портов. Такая топология в простейшем случае состоит из двух групп коммутаторов – «листьев» (leaf), выполняющих роль устройств доступа, и коммутаторов «хребта» (spine), объединяющих между собой «листья», при этом каждый из коммутаторов одной группы подключен к каждому коммутатору другой группы (см. рисунок).
Ключевыми достоинствами такой архитектуры являются:
- простота горизонтального масштабирования производительности путем расширения «хребта» – многие современные решения поддерживают использование в нем до 16 коммутаторов и даже больше, что позволяет при необходимости строить полностью неблокируемую сеть из многих тысяч портов;
- высокая отказоустойчивость – для «хребта» из Nкоммутаторов при отказе одного из них доступная производительность снижается лишь в пропорции 1:N;
- гибкость размещения нагрузок – все «листья» равноправны, и любую новую нагрузку можно разместить в любом месте;
- предсказуемая низкая задержка – между любыми портами доступа всего лишь три коммутатора.
Надо отметить, что приведенные соображения не зависят от того, какие задачи решает построенная по данной топологии сеть, – является ли она сетью передачи данных, хранения данных или, скажем, телефонной сетью. Аналогично, если говорить о сети передачи данных, данный подход не опирается на то, осуществляется ли в сети коммутация на втором или третьем уровне, – при условии, что внутри фабрики выполняется передача трафика по наикратчайшему пути с распределением трафика между альтернативными маршрутами с одинаковой стоимостью (ECMP – EqualCostMultipathing). Для маршрутизации это является естественной характеристикой, именно поэтому первые фабрики (зачастую еще не называвшиеся данным термином) строились как полностью маршрутизируемые сети (L3-фабрики) – так построена инфраструктура большинства крупных мировых операторов веб-сервисов. В то же время большинство корпоративных заказчиков и операторов облачных услуг нуждаются в возможности «растягивания подсетей», т. е. осуществления через фабрику коммутации на втором уровне. Это диктуется прежде всего потребностью в гибкости размещения и мобильности уже размещенных нагрузок, а также требованиями кластерных систем. Современные фабрики содержат поддержку для передачи трафика с коммутацией на втором уровне, что предполагает решение ряда проблем, возникающих при традиционной коммутации на втором уровне:
- применение протокола SpanningTreeдля предотвращения «зацикливания» пакетов обусловливает использование только одного активного пути из многих возможных;
- передача Ethernet-фрейма внутри фабрики на основе MAC-адреса сохраняет потенциал возникновения «штормов», когда фрейм бесконечно передается по сети из-за появления в ней петли;
- организация полноценной маршрутизации по альтернативным путям (ECMP) на основе MAC-адресов привела бы к крайне ресурсоемким и медленно сходящимся реализациям при использовании в крупных сетях с десятками тысяч MAC-адресов.
Большинство современных сетевых фабрик решают указанные проблемы путем инкапсуляции фреймов Ethernet в пакеты того или иного формата, обеспечивающего маршрутизируемый транспорт с возможностью использования нескольких альтернативных вариантов. Так, протокол CiscoFabricPath добавляет к фрейму Ethernetдополнительный заголовок, аналогичный заголовку Ethernet, но использующий в качестве адресов идентификаторы коммутаторов внутри сети, для построения оптимальных маршрутов между которыми применяется протокол IS-IS. Вся коммутация внутри фабрики осуществляется с помощью именно этих идентификаторов, тем самым исключается необходимость поддерживать на всех коммутаторах FabricPath полную информацию обо всех MAC-адресах узлов: в известном смысле, здесь прослеживается аналогия с разделением ролей PE- и P- маршрутизаторов в MPLS-сетях (кстати, MPLSтакже является одним из потенциальных вариантов транспортного протокола внутри фабрики). На границах фабрики требования к размеру таблиц могут быть снижены за счет присутствующего в FabricPath механизма «диалогового выучивания» адресов. Для устранения бесконечного «зацикливания» фреймов внутри фабрики в заголовке FabricPath предусмотрено дополнительное поле TTL, аналогичное одноименному полю в заголовке IP-пакетов.
Другим примером технологии построения фабрики, идущей от организации логических сегментов в виртуальной среде, является протокол VXLAN, инкапсулирующий фреймы Ethernetв IP-пакеты и обеспечивающий использование до 16 млн сегментов (в случае FabricPathаналогичные возможности по сегментации реализуются в рамках опирающейся на него архитектуры CiscoDFA (DynamicFabricAutomation)). Особенность VXLANзаключается в том, что сам протокол не описывает реализацию нижележащей сети, включая ее архитектуру, механизмы сходимости и т. д., поэтому проектирование целостного решения на базе VXLANтребует отдельной проработки дизайна IP-сети. Проблемами, с которыми приходится сталкиваться при использовании VXLAN в его стандартной реализации, являются, во-первых, опора на мультикастовый транспорт для группового и широковещательного трафика (что приемлемо не для всех заказчиков), во-вторых, опора на прослушивание широковещательного трафика для пополнения таблиц MAC-адресов (floodandlearn), что затруднительно для крупных сетей. Эти проблемы решаются в усовершенствованных реализациях, которые находят свое воплощение в современных фабриках.
Несмотря на кажущееся удобство, обусловленное обеспечиваемой сетевыми фабриками эффективной организацией связности на втором уровне, необходимо учитывать, что при этом никуда не исчезают многие проблемы, характерные для традиционных сетей, в которых происходит растягивание VLAN (например, распространение в рамках всего сегмента широковещательного трафика, ограниченное количество точек маршрутизации между сегментами). Для преодоления этих недостатков применяются дополнительные усовершенствования, в частности организация «распределенного шлюза по умолчанию», позволяющего выполнять маршрутизацию на каждом коммутаторе доступа непосредственно на входе в фабрику, а также ограничивать те виды широковещания, которые это допускают, – ARP-запросы к уже известным фабрике адресам и т. д. Примерами могут служить и архитектура CiscoDFA, и построенная с использованием «расширенного VXLAN» (eVXLAN) фабрика CiscoACI (Application-CentricInfrastructure).
Предметом отдельной статьи могло бы стать критически важное требование поддержки как физических (невиртуализированных), так и виртуальных нагрузок, поскольку большинство современных ЦОД включает те и другие, зачастую в рамках одного и того же прикладного комплекса. Уже упомянутые архитектуры CiscoDFA и ACI обеспечивают эффективное «продолжение» фабрики внутрь среды виртуализации и, следовательно, подключение к ней наряду с физическими виртуальных серверов.
Наконец, нельзя забывать о том, что сеть ЦОД независимо от ее архитектуры важна не сама по себе, а как способ обеспечить взаимодействие приложений и их компонентов, причем все чаще это происходит в составе облачной среды или автоматизированной инфраструктуры. С учетом этого современные фабрики должны обеспечивать возможность эффективной интеграции в состав систем оркестрации частных и публичных облаков (например, OpenStack), с тем чтобы предоставлять нужную форму сетевого взаимодействия не в результате выполняемой сетевым администратором настройки, а по запросу вышестоящей программной системы. Концепция CiscoACIподнимает эту идею на новый уровень, ставя во главу угла не сетевую номенклатуру, а структуру и требования приложений. По сути, ACIвоплощает в жизнь подход «сеть как сервис», при котором характер взаимодействия между компонентами приложения запрашивается у фабрики в рамках абстрактного описания его сетевого профиля, а уже задачей самой фабрики является его реализации в конкретных настройках сетевых элементов.
