Хабрахабр

Сетевая фабрика для ЦОДа Cisco ACI — в помощь админу


С помощью вот этого волшебного куска скрипта Cisco ACI можно быстро настроить сеть.

Расскажу на своём опыте, что это такое, какая от неё польза и где у неё грабли. Сетевая фабрика для ЦОДа Cisco ACI cуществует уже пять лет, но на Хабре про неё толком ничего не рассказано, вот и решил это немного исправить.

Что это и откуда взялось?

К моменту анонса ACI (Application Centric Infrastructure) в 2013 году на традиционные подходы к сетям ЦОДа наступали конкуренты сразу с трёх сторон.

Идея была в том, чтобы вынести принятие решений, традиционно выполняемое проприетарным софтом коммутаторов, на центральный контроллер. С одной стороны, SDN-решения «первого поколения» на базе OpenFlow обещали сделать сети более гибкими и дешёвыми одновременно.
С другой стороны, оверлейные сетевые решения давали возможность реализовывать нужную связность и политики безопасности вообще без изменений в физической сети, строя программные туннели между виртуализированными хостами. Этот контроллер имел бы единое видение всего происходящего и, исходя из этого, программировал бы аппаратуру всех свитчей на уровне правил обработки конкретных потоков. Некоторой пикантности ситуации добавляло то, что сооснователями Nicira являлись те же люди, что ранее стояли у истоков OpenFlow, теперь говорившие, что для построения фабрики ЦОДа OpenFlow не подходит. Наиболее известным примером такого подхода было решение от Nicira, которая к тому моменту уже была приобретена VMWare за 1,26 миллиарда долларов и дала начало нынешнему VMWare NSX.

Если раньше каждый вендор сам разрабатывал чипы для своих коммутаторов, то с течением времени чипы от сторонних производителей, прежде всего — от Brоadcom, стали сокращать дистанцию с вендорскими чипами по функциям, а по соотношению цена/производительность их превосходили. Ну и, наконец, коммутационные чипы, доступные на открытом рынке (то, что называется merchant silicon), достигли степени зрелости, при которой они стали реальной угрозой для традиционных производителей коммутаторов. Поэтому многие считали, что дни коммутаторов на чипах собственной разработки сочтены.

ACI стала «асимметричным ответом» Cisco (точнее, вошедшей в её состав компании Insieme, основанной её бывшими сотрудниками) на всё перечисленное.

В чём разница с OpenFlow?

С точки зрения распределения функций ACI фактически — противоположность OpenFlow.
В OpenFlow-архитектуре контроллер отвечает за прописывание детальных правил (потоков)
в аппаратуре всех коммутаторов, то есть в крупной сети на нём может лежать ответственность за поддержание и, самое главное, изменение десятков миллионов записей в сотнях точек в сети, поэтому его производительность и надёжность в крупном внедрении становятся узким местом.

Контроллер можно перезагрузить или вообще выключить, и с сетью ничего плохого не произойдёт, кроме, разумеется, отсутствия в этот момент возможности управления. В ACI используется обратный подход: контроллер тоже, разумеется, есть, но коммутаторы получают с него высокоуровневые декларативные политики, а их рендеринг в детали конкретных настроек в аппаратуре выполняет сам коммутатор. Интересно, что в ACI есть ситуации, в которых OpenFlow всё же используется, но локально в пределах хоста для программирования Open vSwitch.

Cisco назвала это термином «интегрированный оверлей». ACI целиком построена на оверлейном транспорте на основе VXLAN, но при этом включает в рамках единого решения и нижележащий IP-транспорт. Хосты не обязаны что-то знать про фабрику, инкапсуляции и т. В качестве точки терминирования оверлеев в ACI в большинстве случаев используются коммутаторы фабрики (делают это на скорости канала). д., однако в ряде случаев (скажем, для подключения OpenStack-хостов) VXLAN-трафик может доводиться и до них.

Оверлеи используются в ACI не только для обеспечения гибкой связности через транспортную сеть, но и для передачи метаинформации (она используется, например, для применения политик безопасности).

В семействе Nexus 9000, специально выпущенном для поддержки ACI, первоначально была реализована гибридная модель, которую назвали Merchant+. Чипы от Broadcom и раньше использовались Cisco в коммутаторах серии Nexus 3000. Судя по всему, это позволило ускорить выход продукта и снизить ценник коммутатора до уровня, близкого к моделям просто на Trident 2. В коммутаторе одновременно использовались и новый чип Broadcom Trident 2, и дополняющий его чип разработки Cisco, реализующий всю магию ACI. За это время Cisco разработала и выпустила на рынок следующее поколение Nexus 9000 уже на своих собственных чипах с большей производительностью и набором функций, но на том же уровне цены. Этого подхода хватило на первые два-три года поставок ACI. При этом внутренняя начинка целиком поменялась: что-то вроде рефакторинга, но для железа. Внешние спецификации с точки зрения взаимодействия в фабрике полностью сохранились.

Как устроена архитектура Cisco ACI

В простейшем случае ACI строится по топологии сети Клоза, или, как ещё часто говорят, Spine-Leaf. Коммутаторов Spine-уровня может быть от двух (или одного, если нас не волнует отказоустойчивость) до шести. Соответственно, чем их больше, тем выше отказоустойчивость (меньше снижение полосы и надёжности при аварии или обслуживании одного Spine) и общая производительность. Все внешние подключения идут в коммутаторы Leaf-уровня: это и серверы, и стыковка с внешними сетями по L2 или по L3, и подключение контроллеров APIC. Вообще с ACI не только настройка, но и сбор статистики, мониторинг отказов и прочее — всё делается через интерфейс контроллеров, которых во внедрениях обычного размера — три штуки.

Для траблшутинга к коммутаторам при необходимости можно подсоединиться по SSH: на них достаточно тщательно воспроизведены обычные show-команды Cisco. К коммутаторам консолью не приходится подключаться никогда, даже для запуска сети: контроллер сам обнаруживает коммутаторы и собирает из них фабрику, включая настройки всех служебных протоколов, поэтому, кстати, очень важно при монтаже записать серийники устанавливаемого оборудования, чтобы потом не гадать, какой коммутатор в какой стойке находится.

Трафик в фабрике передаётся через туннели на основе VXLAN. Внутри фабрика использует IP-транспорт, так что никакого Spanning Tree и прочих ужасов прошлого в ней нет: все линки задействованы, и сходимость при отказах очень быстрая. Это позволяет реализовывать правила взаимодействия между группами в аппаратуре, используя их номера так же, как в обычных аксесс-листах используются адреса. Если точнее, то сама Cisco называет инкапсуляцию iVXLAN, и отличается она от обычного VXLAN тем, что зарезервированные поля в сетевом заголовке используются для передачи служебной информации, прежде всего — об отношении трафика к группе EPG.

При этом шлюз по умолчанию — распределённый. Туннели позволяют растягивать через внутренний IP-транспорт и L2-сегменты, и L3 (то есть VRF). В части логики передачи трафика ACI похожа на фабрику на основе VXLAN/EVPN. Это значит, что маршрутизацией входящего в фабрику трафика занимается каждый коммутатор.

Если так, то в чём отличия? Во всём остальном!

Отличие номер один, с которым сталкиваешься в ACI, — то, как включаются в сеть сервера. В традиционных сетях включение и физических серверов, и виртуалок идёт в VLANы, и от них пляшет всё остальное: связность, безопасность и т. д. В ACI же используется конструкция, которую Cisco называет EPG (End-point Group), от которой никуда не деться. Можно ли приравнять её к VLAN? Да, но в этом случае есть шанс потерять большую часть того, что даёт ACI.

То есть мы можем создать EPG-группы «Web» и «MySQL» и определить правило, разрешающее взаимодействие между ними только по порту 3306. Относительно EPG формулируются все правила доступа, а в ACI по умолчанию используется принцип «белого списка», то есть разрешён только трафик, пропускание которого разрешено в явной форме. Это будет работать без привязки к сетевым адресам и даже в пределах одной подсети!

Да-да, мы знаем, никто ведь не прописывает руками IP-адреса в конфигурациях приложений, правда? У нас есть заказчики, которые выбрали ACI именно из-за этой фичи, поскольку она позволяет ограничить доступы между серверами (виртуальными или физическими — неважно), не перетаскивая их между подсетями, а значит, не трогая адресацию.

В таком контракте одна или несколько групп или уровней в многозвенном приложении становятся провайдером сервиса (скажем, сервиса БД), другие — потребителем. Правила прохождения трафика в ACI называются контрактами. Контракт может просто пропустить трафик, а может сделать что-то более хитрое, например, направить на файрвол или балансировщик, а также поменять значение QoS.

Если это физические сервера или что-то включённое в существующую сеть, в которую мы создали VLAN-транк, то для их помещения в EPG понадобится указать на порт коммутатора и используемый на нём VLAN. Как сервера попадают в эти группы? Как видим, VLANы появляются там, где без них не обойтись.

д. Если же серверами являются виртуалки, то достаточно сослаться на подключённую среду виртуализации, а дальше всё случится само: создастся порт-группа (если говорить в терминах — VMWare) для подключения VM, назначатся необходимые VLANы или VXLANы, пропишутся на необходимых портах коммутаторов и т. В ACI уже встроены связка с VMWare и MS Hyper-V, а также поддержка для OpenStack и RedHat Virtualization. Так что, хотя ACI и построена вокруг физической сети, для виртуальных серверов подключения выглядят гораздо проще, чем для физических. С некоторого момента появилась и встроенная поддержка контейнерных платформ: Kubernetes, OpenShift, Cloud Foundry, при этом она касается и применения политик, и мониторинга, то есть сетевой администратор может сразу увидеть, на каких хостах какие поды работают и в какие группы они попали.

д., которые можно использовать как критерии для их переноса в другую группу, скажем, при переименовании VM или появлении у неё дополнительного тега. Помимо включения в ту или иную порт-группу, у виртуальных серверов есть дополнительные свойства: имя, атрибуты и т. Ну, вендору виднее. Cisco называет это микросегментационными группами, хотя, по большому счёту, сама конструкция с возможностью создавать много сегментов безопасности в виде EPG в одной и той же подсети — тоже вполне себе микросегментация.

д., так что с ними и конструкциями на их основе (приложениями и тенантами) можно делать вещи, которые трудно сделать в обычных сетях, например, клонировать. Сами EPG являются чисто логическими конструкциями, не привязанными к конкретным коммутаторам, серверам и т. Можно сделать вручную, но лучше (и проще) — через API. В результате, скажем, очень легко создать клон продуктивной среды, чтобы получить тестовое окружение, гарантированно идентичное продуктиву.

Поэтому почти каждый, кто занимается ACI, через некоторое время начинает ориентироваться в объектной модели, используемой для управления, и что-то автоматизировать под свои нужды. Вообще логика управления в ACI совсем не похожа на то, с чем обычно встречаешься
в традиционных сетях от той же Cisco: программный интерфейс первичен, а GUI или CLI вторичны, поскольку работают через тот же API. Проще всего это делать из Python: для него есть удобные готовые инструменты.

Обещанные грабли

Главная проблема — то, что многие вещи в ACI сделаны по-другому. Чтобы начать с ней нормально работать, нужно переучиваться. Особенно это касается команд сетевой эксплуатации в крупных заказчиках, где инженеры годами занимаются «прописыванием VLANов» по заявкам. То, что теперь VLAN — больше не VLAN, а для прокладки новых сетей в виртуализированные хосты создавать VLANы руками вообще не нужно, полностью «сносит крышу» у традиционных сетевиков и заставляет цепляться за привычные подходы. Надо заметить, что Cisco постаралась немного подсластить пилюлю и добавила в контроллер «NXOS-подобный» CLI, позволяющий делать настройку из интерфейса, похожего на традиционные коммутаторы. Но всё равно для того, чтобы начать нормально пользоваться ACI, придётся понять, как она работает.

к. С точки зрения цены на больших и средних масштабах сети ACI от традиционных сетей на оборудовании Cisco фактически не отличается, т. А вот для ЦОДов из двух свитчей наличие контроллеров и Spine-Leaf-архитектуры, конечно, дают о себе знать. для их построения используются одни и те же коммутаторы (Nexus 9000 могут работать и в ACI, и в традиционном режиме и стали сейчас основной «рабочей лошадкой» для новых проектов по ЦОДу). Это позволяет сократить разницу в стоимости, но она всё равно остаётся. Недавно появилась Mini ACI-фабрика, в которой два контроллера из трёх заменены виртуальными машинами. Так что для заказчика выбор диктуется тем, насколько он заинтересован в функциях безопасности, интеграции с виртуализацией, единой точке управления и прочем.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть