С помощью вот этого волшебного куска скрипта Cisco ACI можно быстро настроить сеть.
Сетевая фабрика для ЦОДа Cisco ACI cуществует уже пять лет, но на Хабре про неё толком ничего не рассказано, вот и решил это немного исправить. Расскажу на своём опыте, что это такое, какая от неё польза и где у неё грабли.
Что это и откуда взялось?
К моменту анонса ACI (Application Centric Infrastructure) в 2013 году на традиционные подходы к сетям ЦОДа наступали конкуренты сразу с трёх сторон.
С одной стороны, SDN-решения «первого поколения» на базе OpenFlow обещали сделать сети более гибкими и дешёвыми одновременно. Идея была в том, чтобы вынести принятие решений, традиционно выполняемое проприетарным софтом коммутаторов, на центральный контроллер.
Этот контроллер имел бы единое видение всего происходящего и, исходя из этого, программировал бы аппаратуру всех свитчей на уровне правил обработки конкретных потоков.
С другой стороны, оверлейные сетевые решения давали возможность реализовывать нужную связность и политики безопасности вообще без изменений в физической сети, строя программные туннели между виртуализированными хостами. Наиболее известным примером такого подхода было решение от Nicira, которая к тому моменту уже была приобретена VMWare за 1,26 миллиарда долларов и дала начало нынешнему VMWare NSX. Некоторой пикантности ситуации добавляло то, что сооснователями Nicira являлись те же люди, что ранее стояли у истоков OpenFlow, теперь говорившие, что для построения фабрики ЦОДа .
Ну и, наконец, коммутационные чипы, доступные на открытом рынке (то, что называется merchant silicon), достигли степени зрелости, при которой они стали реальной угрозой для традиционных производителей коммутаторов. Если раньше каждый вендор сам разрабатывал чипы для своих коммутаторов, то с течением времени чипы от сторонних производителей, прежде всего — от Brоadcom, стали сокращать дистанцию с вендорскими чипами по функциям, а по соотношению цена/производительность их превосходили. Поэтому многие считали, что дни коммутаторов на чипах собственной разработки сочтены.
ACI стала «асимметричным ответом» Cisco (точнее, вошедшей в её состав компании Insieme, основанной её бывшими сотрудниками) на всё перечисленное.
В чём разница с OpenFlow?
С точки зрения распределения функций ACI фактически — противоположность OpenFlow.
В OpenFlow-архитектуре контроллер отвечает за прописывание детальных правил (потоков)
в аппаратуре всех коммутаторов, то есть в крупной сети на нём может лежать ответственность за поддержание и, самое главное, изменение десятков миллионов записей в сотнях точек в сети, поэтому его производительность и надёжность в крупном внедрении становятся узким местом.
В ACI используется обратный подход: контроллер тоже, разумеется, есть, но коммутаторы получают с него высокоуровневые декларативные политики, а их рендеринг в детали конкретных настроек в аппаратуре выполняет сам коммутатор. Контроллер можно перезагрузить или вообще выключить, и с сетью ничего плохого не произойдёт, кроме, разумеется, отсутствия в этот момент возможности управления. Интересно, что в ACI есть ситуации, в которых OpenFlow всё же используется, но локально в пределах хоста для программирования Open vSwitch.
ACI целиком построена на оверлейном транспорте на основе VXLAN, но при этом включает в рамках единого решения и нижележащий IP-транспорт. Cisco назвала это термином «интегрированный оверлей». В качестве точки терминирования оверлеев в ACI в большинстве случаев используются коммутаторы фабрики (делают это на скорости канала). Хосты не обязаны что-то знать про фабрику, инкапсуляции и т. д., однако в ряде случаев (скажем, для подключения OpenStack-хостов) VXLAN-трафик может доводиться и до них.
Оверлеи используются в ACI не только для обеспечения гибкой связности через транспортную сеть, но и для передачи метаинформации (она используется, например, для применения политик безопасности).
Чипы от Broadcom и раньше использовались Cisco в коммутаторах серии Nexus 3000. В семействе Nexus 9000, специально выпущенном для поддержки ACI, первоначально была реализована гибридная модель, которую назвали Merchant+. В коммутаторе одновременно использовались и новый чип Broadcom Trident 2, и дополняющий его чип разработки Cisco, реализующий всю магию ACI. Судя по всему, это позволило ускорить выход продукта и снизить ценник коммутатора до уровня, близкого к моделям просто на Trident 2. Этого подхода хватило на первые два-три года поставок ACI. За это время Cisco разработала и выпустила на рынок следующее поколение Nexus 9000 уже на своих собственных чипах с большей производительностью и набором функций, но на том же уровне цены. Внешние спецификации с точки зрения взаимодействия в фабрике полностью сохранились. При этом внутренняя начинка целиком поменялась: что-то вроде рефакторинга, но для железа.
Как устроена архитектура Cisco ACI
В простейшем случае ACI строится по топологии сети Клоза, или, как ещё часто говорят, Spine-Leaf. Коммутаторов Spine-уровня может быть от двух (или одного, если нас не волнует отказоустойчивость) до шести. Соответственно, чем их больше, тем выше отказоустойчивость (меньше снижение полосы и надёжности при аварии или обслуживании одного Spine) и общая производительность. Все внешние подключения идут в коммутаторы Leaf-уровня: это и серверы, и стыковка с внешними сетями по L2 или по L3, и подключение контроллеров APIC. Вообще с ACI не только настройка, но и сбор статистики, мониторинг отказов и прочее — всё делается через интерфейс контроллеров, которых во внедрениях обычного размера — три штуки.
К коммутаторам консолью не приходится подключаться никогда, даже для запуска сети: контроллер сам обнаруживает коммутаторы и собирает из них фабрику, включая настройки всех служебных протоколов, поэтому, кстати, очень важно при монтаже записать серийники устанавливаемого оборудования, чтобы потом не гадать, какой коммутатор в какой стойке находится. Для траблшутинга к коммутаторам при необходимости можно подсоединиться по SSH: на них достаточно тщательно воспроизведены обычные show-команды Cisco.
Внутри фабрика использует IP-транспорт, так что никакого Spanning Tree и прочих ужасов прошлого в ней нет: все линки задействованы, и сходимость при отказах очень быстрая. Трафик в фабрике передаётся через туннели на основе VXLAN. Если точнее, то сама Cisco называет инкапсуляцию iVXLAN, и отличается она от обычного VXLAN тем, что зарезервированные поля в сетевом заголовке используются для передачи служебной информации, прежде всего — об отношении трафика к группе EPG. Это позволяет реализовывать правила взаимодействия между группами в аппаратуре, используя их номера так же, как в обычных аксесс-листах используются адреса.
Туннели позволяют растягивать через внутренний IP-транспорт и L2-сегменты, и L3 (то есть VRF). При этом шлюз по умолчанию — распределённый. Это значит, что маршрутизацией входящего в фабрику трафика занимается каждый коммутатор. В части логики передачи трафика ACI похожа на фабрику на основе VXLAN/EVPN.
Если так, то в чём отличия? Во всём остальном!
Отличие номер один, с которым сталкиваешься в ACI, — то, как включаются в сеть сервера. В традиционных сетях включение и физических серверов, и виртуалок идёт в VLANы, и от них пляшет всё остальное: связность, безопасность и т. д. В ACI же используется конструкция, которую Cisco называет EPG (End-point Group), от которой никуда не деться. Можно ли приравнять её к VLAN? Да, но в этом случае есть шанс потерять большую часть того, что даёт ACI.
Относительно EPG формулируются все правила доступа, а в ACI по умолчанию используется принцип «белого списка», то есть разрешён только трафик, пропускание которого разрешено в явной форме. То есть мы можем создать EPG-группы «Web» и «MySQL» и определить правило, разрешающее взаимодействие между ними только по порту 3306. Это будет работать без привязки к сетевым адресам и даже в пределах одной подсети!
У нас есть заказчики, которые выбрали ACI именно из-за этой фичи, поскольку она позволяет ограничить доступы между серверами (виртуальными или физическими — неважно), не перетаскивая их между подсетями, а значит, не трогая адресацию. Да-да, мы знаем, никто ведь не прописывает руками IP-адреса в конфигурациях приложений, правда?
Правила прохождения трафика в ACI называются контрактами. В таком контракте одна или несколько групп или уровней в многозвенном приложении становятся провайдером сервиса (скажем, сервиса БД), другие — потребителем. Контракт может просто пропустить трафик, а может сделать что-то более хитрое, например, направить на файрвол или балансировщик, а также поменять значение QoS.
Как сервера попадают в эти группы? Если это физические сервера или что-то включённое в существующую сеть, в которую мы создали VLAN-транк, то для их помещения в EPG понадобится указать на порт коммутатора и используемый на нём VLAN. Как видим, VLANы появляются там, где без них не обойтись.
Если же серверами являются виртуалки, то достаточно сослаться на подключённую среду виртуализации, а дальше всё случится само: создастся порт-группа (если говорить в терминах — VMWare) для подключения VM, назначатся необходимые VLANы или VXLANы, пропишутся на необходимых портах коммутаторов и т. д. Так что, хотя ACI и построена вокруг физической сети, для виртуальных серверов подключения выглядят гораздо проще, чем для физических. В ACI уже встроены связка с VMWare и MS Hyper-V, а также поддержка для OpenStack и RedHat Virtualization. С некоторого момента появилась и встроенная поддержка контейнерных платформ: Kubernetes, OpenShift, Cloud Foundry, при этом она касается и применения политик, и мониторинга, то есть сетевой администратор может сразу увидеть, на каких хостах какие поды работают и в какие группы они попали.
Помимо включения в ту или иную порт-группу, у виртуальных серверов есть дополнительные свойства: имя, атрибуты и т. д., которые можно использовать как критерии для их переноса в другую группу, скажем, при переименовании VM или появлении у неё дополнительного тега. Cisco называет это микросегментационными группами, хотя, по большому счёту, сама конструкция с возможностью создавать много сегментов безопасности в виде EPG в одной и той же подсети — тоже вполне себе микросегментация. Ну, вендору виднее.
Сами EPG являются чисто логическими конструкциями, не привязанными к конкретным коммутаторам, серверам и т. д., так что с ними и конструкциями на их основе (приложениями и тенантами) можно делать вещи, которые трудно сделать в обычных сетях, например, клонировать. В результате, скажем, очень легко создать клон продуктивной среды, чтобы получить тестовое окружение, гарантированно идентичное продуктиву. Можно сделать вручную, но лучше (и проще) — через API.
Вообще логика управления в ACI совсем не похожа на то, с чем обычно встречаешься
в традиционных сетях от той же Cisco: программный интерфейс первичен, а GUI или CLI вторичны, поскольку работают через тот же API. Поэтому почти каждый, кто занимается ACI, через некоторое время начинает ориентироваться в объектной модели, используемой для управления, и что-то автоматизировать под свои нужды. Проще всего это делать из Python: для него есть удобные готовые инструменты.
Обещанные грабли
Главная проблема — то, что многие вещи в ACI сделаны по-другому. Чтобы начать с ней нормально работать, нужно переучиваться. Особенно это касается команд сетевой эксплуатации в крупных заказчиках, где инженеры годами занимаются «прописыванием VLANов» по заявкам. То, что теперь VLAN — больше не VLAN, а для прокладки новых сетей в виртуализированные хосты создавать VLANы руками вообще не нужно, полностью «сносит крышу» у традиционных сетевиков и заставляет цепляться за привычные подходы. Надо заметить, что Cisco постаралась немного подсластить пилюлю и добавила в контроллер «NXOS-подобный» CLI, позволяющий делать настройку из интерфейса, похожего на традиционные коммутаторы. Но всё равно для того, чтобы начать нормально пользоваться ACI, придётся понять, как она работает.
С точки зрения цены на больших и средних масштабах сети ACI от традиционных сетей на оборудовании Cisco фактически не отличается, т. к. для их построения используются одни и те же коммутаторы (Nexus 9000 могут работать и в ACI, и в традиционном режиме и стали сейчас основной «рабочей лошадкой» для новых проектов по ЦОДу). А вот для ЦОДов из двух свитчей наличие контроллеров и Spine-Leaf-архитектуры, конечно, дают о себе знать. Недавно появилась Mini ACI-фабрика, в которой два контроллера из трёх заменены виртуальными машинами. Это позволяет сократить разницу в стоимости, но она всё равно остаётся. Так что для заказчика выбор диктуется тем, насколько он заинтересован в функциях безопасности, интеграции с виртуализацией, единой точке управления и прочем.
Source: www.habr.com