Началось: стеки против потоков

В наши дни много шума вокруг "войн" в мире сетей. OpenStack потив CloudStack и SDN (программно-конфигурируемая сеть) против сетей на основе протокола OpenFlow.

Несмотря на то, что некоторые аспекты "стеков" схожи с "потоками", они являются разными моделями и решают разные проблемы.

Понимание двух моделей и их предназначения позволит решить любые возможные конфликты.

Стековая модель

Стековые модели вроде CloudStack и OpenStack правильнее отнести к категории "фреймворков для управления облаком", ведь они поддерживают функции конфигурации и управления инфраструктурными сервисами, охватывающими среду облачных вычислений (или высокодинамичную среду).

Стеки получили меткое название, поскольку обеспечивают управление и автоматизацию распределения ресурсов для всего сетевого стека. CloudStack и OpenStack, наряду с Eucalyptus, Amazon и VMware vCloud предоставляют API, который можно (якобы) использовать для конфигурирования сервисов вне зависимости от реализации.

Концепция заключается в том, чтобы дать стороне, ответственной за реализацию (поставщик услуг или предприятие) возможность выключать архитектурные элементы (маршрутизаторы, коммутаторы, гипервизоры, распределители нагрузки и т.д.). То есть, переход с Dell на HP, а с HP на Cisco (или наоборот) в качестве коммутационной матрицы среды должен проходить без проблем. Физические изменения не должны влиять на предоставление ресурсов и управление сервисами инфраструктуры.

Кроме того, подобная стратегия также обязана допускать гетерогенность инфраструктуры.

Такие "стеки" во многом представляют собой виртуализацию дата-центра, создающую возможность для абстрагирования фактической реализации от конфигурации и автоматизации элементов аппаратного (или программного) обеспечения. Именно это позволяет сравнивать их с "потоковыми" моделями.

Модель потока

Модели потока, в особенности SDN на базе протокола OpenFlow, также абстрагируют реализацию от конфигурации, отделяя плоскость контроля от плоскости данных. Таким образом, любое устройство с поддержкой OpenFlow (преимущественно коммутаторы: SDN и OpenFlow сетевых уровней) можно конфигурировать и контролировать посредством централизованного контроллера, используя обычный API.

Потоки "устанавливаются" или "встраиваются" в элементы с поддержкой OpenFlow через открытый протокол, и поддерживают обновления в режиме реального времени, что позволяет проводить оптимизацию по требованию или локализацию неисправностей в потоках через сеть. OpenFlow и SDN ориентированы на управление потоком трафика через сеть.

В плане гетерогенности и межоперационной совместимости модели на базе потоков предлагают те же преимущества, что и стековая модель. Переход от одного коммутатора с поддержкой OpenFlow к другому никак не должен влиять на сеть.

В отличие от стековой модели, модели на базе потоков поддерживают расширяемость. SDN модели на базе OpenFlow, использующие централизованный контроллер, предположительно, также способны программным путем добавлять к сети новые сервисы. "Приложения", развернутые на платформе SDN контроллера, могут расширить существующие сервисы или добавить новые. При этом, не нужно ничего менять в базовых настройках сети.

Различия

Во-первых, стек делает упор на конфигурировании ресурсов и управлении. Хотя с помощью API-интерфейса CloudStack можно создать или удалить правила переадресации портов на брандмауэре, эти действия инициируются за пределами брандмауэра. Брандмауэр не получает пакет и не требует от облачного фреймворка соответствующего действия, как это делает коммутатор в SDN на базе OpenFlow.

Еще одно важное отличие в том, кто отвечает за интеграцию. В модели на основе стека ответственным за интеграцию (с помощью плагинов или драйверов) с существующим API (при условии, что такой существует) компонента является стек. В случае с моделью на базе потока, за обеспечение нативной поддержки OpenFlow отвечает поставщик. Очевидно, модель стека обладает более крупной экосистемой доступных ресурсов для выполнения интеграции, чем модель потока.

Несмотря на то, что поставщики участвуют в разработке драйверов/плагинов для стеков, влияние на сам продукт минимально, поскольку интеграция происходит за пределами компонента. Для обеспечения компонентам нативной поддержки OpenFlow требуется намного больше внутренних ресурсов.

Выбор неизбежен?

На самом деле, нет. Модели не являются взаимоисключающими и могут эффективно использоваться одновременно. Подход к обеспечению ресурсов и управлению на базе стека вполне можно дополнить SDN на базе протокола OpenFlow, где потоки обновляются в режиме реального времени, или развертыванием новых протоколов или сервисов в пределах сети.

Несуществующая война

Между различными моделями стека, может, и имеет место борьба, но война между OpenFlow и OpenStack вряд ли возможна. Оба решения являются очень разными и с легкостью могут развертываться в одной сети и решать множество проблем. Сетевые ресурсы предоставляются и начально конфигурируются через стек, но обновляются в режиме реального времени или расширяются SDN-контроллером, при условии, что такие сетевые ресурсы изначально поддерживают OpenFlow.

источник