Сетевая инфраструктура и управление: подход Cisco

«Идея ACI очень проста, – говорит Александр Скороходов, системный инженер-консультант Cisco. – Мы ставим идеологию инфраструктуры ЦОД с головы на ноги: первичными элементами, на основе которых формируются правила безопасности, обработки трафика и т.д., являются приложения. Все остальное – способ реализации этих правил. Данный подход существенно отличается от традиционной сетевой инфраструктуры, где оперируют такими понятиями как VLAN, подсети и т.д., а потребности приложений пытаются привести к этим терминам с помощью абстрагирования ресурсов».
В ACI базовое понятие – сетевой профиль приложения (см. Рисунок 1). В простейшем случае он описывает правила взаимодействия составляющих приложение компонентов – его сетевые и сервисные потребности. Межсетевые экраны, балансировщики нагрузки и т.д. становятся частью описания инфраструктуры приложения. Это описание полностью абстрагировано от сетевой и вычислительной инфраструктуры. Для него не принципиальны количество компонентов приложения и их природа (виртуальные они или физические), IP-адресация, число серверов и т.д.

Рисунок 1. Сетевой профиль приложения ACI и его применение к сети. Вся передача данных в фабрике управляется при помощи профилей приложений. Безопасность и передача данных не зависят от физических и логических сетевых атрибутов. IP-адреса полностью переносимы и могут использоваться где угодно внутри фабрики. При миграции приложения коммутаторы автономно обновляют свои настройки на основе правил, определенных профилем приложения.

С помощью профилей приложений можно управлять всей передачей данных в фабрике. Безопасность и передача данных не зависят от физических и логических сетевых атрибутов. Администратор, отвечающий за приложения, формулирует профиль приложения и передает такое описание контроллеру APIC, управляющему всей инфраструктурой. Оно доводится до всех элементов сети и фабрики. Все дальнейшие действия и изменения, такие как миграция виртуальных машин (ВМ) отрабатываются фабрикой автономно и не требуют дополнительных управляющих воздействий контроллера, в отличие от SDN, где контроллер полностью управляет коммутаторами.

В Cisco считают, что такое декларативное управление значительно улучшает масштабируемость ACI. Задается лишь логика управления, но не его детали. Можно добавлять и новые сетевые элементы, детали логики управления которыми контроллер знать не обязан. В то же время модели на базе протокола OpenFlow все возможности сети определяются и контроллером, и коммутирующими устройствами. Технически ничто не мешает совместить ACI и SDN, они не исключают друг друга. Но, в отличие от SDN с высокой детализацией централизованного управления в ACI применяется декларативный подход.

Сетевые элементы сами подстраиваются под политики. В ACI каждое сетевое устройство динамически применяет настройки в соответствии с требованиями профиля. По существу, APIC играет роль репозитория политик, хранит и распространяет их. Это единая точка управления для администратора, систем оркестрации и автоматизации, включая OpenStack, Cisco UCS Director и др. Контроллер решает также сервисные задачи, связанные с обнаружением фабрики, обновлением ПО и т.д. (см. Рисунок 2).

Рисунок 2. Централизованная автоматизация и управление фабрикой в Cisco ACI. APIC – единая точка управления политиками в сети ЦОД. Контроллер не принимает непосредственного участия в передаче данных, не занимается детальной настройкой. Он предусматривает открытую модель данных для управления при помощи внешних средств оркестрации, интеграцию с сервисами L4-L7, возможности мониторинга приложений, поиска и устранения неисправностей фабрики.
 

Высокая масштабируемость достигается также за счет того, что контроллер не участвует в судьбе каждого сетевого пакета и находится за рамками передачи данных и происходящих в сети изменений. Его задачи – распространять и обновлять политики, собирать телеметрическую информацию, но он не программирует непосредственно детали коммутации на каждом устройстве. В результате кластер APIC способен поддерживать более миллиона конечных хостов, свыше 200 тыс. портов, 64 тыс. логических организаций (tenant).

Администратор может формулировать потребности приложения в терминах самого приложения. Описываются уровни приложений, их взаимодействие без таких деталей как IP-адреса, VLAN и пр. Один раз сформулировав политику, ее можно использовать в дальнейшем без изменения, например, переносить между ЦОД, физическими и виртуальными серверами. Этот подход работает и для полностью виртуализированных, гибридных или не виртуализированных сред.

«Администраторы приложений получают детальную информацию о том, что происходит в сети с его приложением – именно ту, которая относится к обслуживающим приложение коммутаторам в данный момент времени, – поясняет Александр Скороходов. – Администраторы безопасности имеют свое видение происходящего в инфраструктуре ЦОД. Мониторинг дает информацию о состоянии приложения и сетевом трафике всех его компонентов. Для них ACI – это возможность управления правилами взаимодействия компонентов инфраструктуры на понятном им уровне. ACI поддерживает любимую ими модель «белого писка»: все, что не разрешено, запрещено по умолчанию. Кроме того, можно встраивать дополнительные средства безопасности (Cisco или других вендоров), виртуальные или физических, предусмотрены средства аудита, протоколирования действий, API для внешнего анализа».

Сетевым администраторам ACI дает возможность уйти от прежней обработки сервисных заявок и настроек, эксплуатировать сетевую инфраструктуру не как не набор устройств, а как комплекс с детальной телеметрией и диагностикой, эффективными механизмами перераспределения трафика между альтернативными маршрутами, подчеркивают в Cisco. Маршрутизация выполняется в распределенном режиме непосредственно на границе сети. При этом можно развертывать среды с произвольным соотношением не виртуализированных и виртуализированных нагрузок на разных платформах, внедрять гибридные и облачные сервисы. Кроме того, есть возможность интеграции с различными средствами оркестрации и автоматизации, включая OpenStack, чему Cisco уделяет особое внимание. Опубликованная модель данных и протокол OpFlex позволяет добавлять в ACI новые элементы, чему способствует и открытый механизм встраивания сервисов L4-L7.

Что касается централизованного управления по политикам конвергентной инфраструктурой «в целом», включая ПО виртуализации, то данную задачу выполняет Cisco UCS Director. Это один из стратегических продуктов Cisco, заменяющий несколько систем управления. О практических аспектах использования Cisco UCS Director для построения частного облака рассказал Евгений Лагунцов, системный инженер-консультант компании Cisco.
Как это работает? Администраторы серверов, СХД, сети задают политики. Политики применяются для создания профилей серверов и конфигураций LAN, SAN, CХД. Это позволяет легко и быстро выполнять операции, занимающие в реальной инфраструктуре достаточно много времени. Процесс максимально автоматизирован.

С точки зрения архитектуры USC Director – это одна или несколько ВМ, легко интегрируемые с существующей физической и виртуальной средой: в USC Director просто вписывается логин/пароль для общения с тем или иным устройством. Система может включать в себя средства развертывания ОС и гипервизоров, поддерживает интеграцию с внешними облаками разных вендоров и разные сценарии использования (см. Рисунок 3).

Рисунок 3. Архитектура UCS Director.

Администратор может автоматизировать различные операции и применять настройки для предоставления сервисов пользователям. Платформа управления UCS Director открыта вверх и вниз: ее можно интегрировать с разным оборудованием через специальные коннекторы и SDK или вызывать из внешних систем. Еще одна возможность – интеграция с биллинговыми системами для учета потребляемых ресурсов и выставления счетов.

Одна система UCS Director может управлять несколькими «интегрированными стеками», например, vBlock и FlexPod, но кроме конвергентных решений Cisco поддерживает серверные, сетевые платформы и СХД других вендоров. В результате можно решать различные задачи по конфигурированию инфраструктуры, включая создание политик, профилей, пулов, шаблонов для Cisco UCS, создание томов и LUN, регистрация инициаторов и прочие функции для дисковых массивов EMC и NetApp, создание VLAN, настройка конфигурации транкинка и др. в сетевом оборудовании, управление кластерами, виртуальными машинами и др. в средах виртуализации (VMware, Microsoft, RedHat).
Значительное внимание разработчики уделили автоматизации. Автоматизация позволяет быстро выделять ресурсы и предоставлять сервисы ИТ на основе политик с контролем всех операций.

В Cisco планируют и далее развивать концепцию ACI и средства управления. Это предназначенное для сети ЦОД решение может распространиться и за его пределы – на магистральную и кампусную сеть, использоваться в вычислительных системах и системах хранения).

Сергей Орлов — ведущий редактор «Журнала сетевых решений/LAN». С ним можно связаться по адресу: sorlov@lanmag.ru.