Побочным эффектом стремительного развития OpenStack стали «детские болезни» проектов, выполненных на базе этой платформы: недостаточная стабильность отдельных компонентов, отсутствие истории успешного использования системы в условиях критических нагрузок и т. п. Множество проектов, реализованных на Openstack, — это компании с уникальным характером деятельности. Усилия, необходимые для применения результатов таких проектов в других организациях, порой значительно превышают экономическую целесообразность — затраты на тестирование, внедрение и интеграцию оказываются выше того, что может позволить себе небольшая компания. Сложилась парадоксальная ситуация: имеется хороший, независимый от платформы и производителя продукт, однако именно эта независимость и отсутствие процедур интеграции ограничивают его использование в корпоративной среде. Чтобы получить выгоды от Openstack, необходимо обеспечить интероперабельность с уже существующими ИТ-системами, поддерживающими критические бизнес-процессы.
Компания Cisco участвует в проекте OpenStack, поддерживая разработку сетевых компонентов и подключаемых модулей для OpenStack Neutron, позволяющих работать с различными сетевыми решениями Cisco. В основе подхода компании к управлению сетями лежит концепция сетевой инфраструктуры, ориентированной на приложения (Application Centric Infrastructure, ACI). ACI использует модель политик для хранения сетевых настроек приложения, что позволяет автоматически распространить изменения на все устройства сети и, соответственно, сократить ресурсы для развертывания приложений. В ACI используется понятие терминальной группы (End Point Group, EPG) для описания портов виртуальных и физических машин, находящихся в одном сетевом сегменте. Задаются правила прохождения сетевого трафика между EPG, и строится сетевая модель приложения, которая еще не привязана к фактическому размещению виртуальных и физических машин, что делает ее универсальной для данного приложения. Набор политик един для всей структуры ACI, описывая работу группы коммутаторов, функционирующих по единым правилам; обычно это сетевое «ядро» ЦОД. Важно, что на входе в структуру ACI весь сетевой трафик «нормализуется», что позволяет использовать в одной терминальной группе приложения, работающие на кластере VMware, Hyper-V, среде KVM и т. п. Например, если необходимо выполнить перевод приложений в облако, то можно подключить к одной структуре ACI физические серверы и кластер виртуализации, а нагрузку переносить постепенно с минимальными простоями и без затрат на перенастройку сети. Еще более интересный вариант использования заключается в возможности работы разных частей одного приложения (например, сервера приложений и СУБД) на разных платформах виртуализации или физических серверах — у разных гипервизоров различаются производительность, плотность размещения нагрузки и модель лицензирования. С ACI администратор сможет выбирать место размещения приложения без оглядки на физическую сеть ЦОД и настройки конкретных единиц оборудования. Этот же механизм дает возможность использовать структуру ACI в качестве универсального транспорта между корпоративными приложениями и средой разработки новых сервисов на платформе OpenStack.
Поскольку контроллер, обеспечивающий настройку инфраструктуры ACI, имеет открытый интерфейс RESТ, то естественным шагом для Cisco стала разработка подключаемого модуля к сетевому модулю OpenStack Neutron для интеграции с ACI, что позволяет установить связь между традиционными сетевыми элементами OpenStack (например, виртуальными сетями) и терминальными группами. Однако текущий подход OpenStack к конфигурации сети имеет несколько изъянов, самый серьезный из которых — необходимость хранения сетевых настроек виртуальной машины в нескольких местах. Например, настройки безопасности хранятся в конструкции под названием «группа безопасности», в то время как сетевые настройки находятся в модуле Neutron. В случае увеличения количества расширений сервисов высокого уровня: маршрутизации (третий уровень сетевой модели), качества обслуживания (QoS), дополнительных сетевых сервисов (уровни с четвертого по седьмой) — каждому из них приходится хранить свои настройки отдельно от остальных, причем не связанные с сетью настройки виртуальной машины также хранятся отдельно. В результате процесс разворачивания виртуальной машины или переноса ее на другую платформу требует от пользователя значительного числа действий.
Еще больше забот существующая модель доставляет разработчикам приложений, заставляя их глубоко погружаться в детали сетевого взаимодействия на всех уровнях модели ISO, которая понятна для сетевых инженеров, но не разработчикам. Все это происходит потому, что базовая модель API для Neutron была создана для очень простых сетевых функций, однако с развитием программно-конфигурируемых сетей появляется большое количество сетевых технологий и возможностей, выходящих за рамки базовых требований к коммутации и маршрутизации в локальных сетях.
Для преодоления ограничений Neutron в Cisco была предложена модель групповых политик сети (Group-Based Policy, GBP) для OpenStack, предлагающая простой абстрактный интерфейс сбора и хранения требований пользователя в одном месте (см. рисунок). Перечислим основные понятия GBP.
- Группы сетевых устройств. Все устройства в группе всегда имеют одинаковые настройки, что замечательно вписывается в существующую модель применения OpenStack для разработки масштабируемых приложений, — в этом случае группа описывает один из уровней (tier) такого приложения.
- Наборы правил. Объединение действий, которые должны быть выполнены при передаче сетевого трафика между двумя группами: простая маршрутизация, коммутация либо более сложные действия, причем один и тот же набор правил можно использовать многократно между различными группами, если в них работают одинаковые приложения. Это уменьшает сложность переконфигурирования системы, так как снижается число изменяемых настроек.
- Модели реализации правил. Модель позволяет разделять ответственность за проведение политик между различными сотрудниками организации — например, разработчик приложения может отвечать за политику, связанную с характеристиками приложения, в то время как администратор безопасности будет настраивать политику, перенаправляющую трафик на межсетевой экран.
- Сетевые сервисы. Модель групповых политик дает возможность построения цепочек сетевых сервисов, которые будут необходимым образом обслуживать сетевой трафик между виртуальными машинами; например, балансировщик нагрузки можно определить как отдельный сетевой сервис, а не строить сложные структуры из подсетей и дополнительных виртуальных машин в текущей сети.
.png "Схема групповой политики") |
| Схема групповой политики |
Модель групповых политик значительно упрощает разработчикам приложений понимание сети в OpenStack, позволяя им описывать свои требования в простой и понятной им форме. Изначально GBP предлагалась для того, чтобы простыми средствами поддерживать расширенные возможности создания цепочек сервисов, однако на практике модель позволяет больше — после того, как разработчик описал свое приложение в терминах групповой политики, администратор сети или безопасности при необходимости может без нарушения общей работоспособности сервиса добавить свои требования.
Модель групповых политик для OpenStack разрабатывается сейчас сообществом разработчиков, в которое входят, в частности, Cisco, IBM и Juniper. Типичные примеры применения GBP таковы.
- Развертывание и масштабирование приложений. Бывают случаи, когда можно рассматривать отдельно требования разработчиков приложения и ограничения, накладываемые конкретной инфраструктурой. Это позволяет максимально упростить создание моделей для новых приложений и уйти от необходимости тратить время на проверку готовности инфраструктуры для нового приложения. Кроме того, при необходимости можно «на лету» добавлять новые компоненты приложения.
- Усиление требований к безопасности. Для усиления требований к безопасности можно обеспечить автоматизированную проверку соответствия, например, требованиям PCI (Payment Security Industry), предъявляемым к процессингу пластиковых карт. Возможности по внедрению цепочек сетевых сервисов позволяют полностью контролировать сетевой обмен между компонентами приложения. Вдобавок такая модель является самодокументируемой благодаря тому, что описания всех сетевых настроек приложения хранятся в одном месте.
- Виртуализация сетевых функций. Поскольку описание сетевого сервиса, который помещается в сервисную цепочку, является абстрактным, такой сервис может реализовывать любую новую сетевую функцию, в том числе распределенную по нескольким узлам инфраструктуры, что позволяет разрабатывать новые виртуальные функции сети, оптимизированные для различных уровней сетевой нагрузки.
Использование модели групповых политик позволяет реализовать режим промышленной эксплуатации платформы OpenStack — например, разработка или внедрение нового сервиса могут быть начаты на этой платформе с предоставлением новому приложению доступа ко всем существующим корпоративным сервисам без нарушения безопасности корпоративной сети. При этом и у разработчиков, и у администраторов остается понимание того, как работает приложение и как оно взаимодействует с другими сервисами, что по сути и означает полноценную промышленную эксплуатацию.
***
Модель групповых политик не только упрощает совместное существование сервисов, построенных на платформе OpenStack, с другими корпоративными сервисами, но и дает значительную выгоду от использования приложения на этой платформе. Модель реализована в проекте OpenStack начиная с дистрибутива Juno, что свидетельствует о готовности технологии к широкому применению.
Дмитрий Хороших (dkhorosh@cisco.com) — менеджер по развитию бизнеса, Cisco Systems (Москва).
