Программно-определяемый ЦОД – рецепт приготовления

Почему эта тенденция устойчива, и какие преимущества дает NFV? Вот так на этот вопрос отвечают CEO 220 компаний из различных отраслей экономики, опрошенные порталом SDNCentral (см. рис. 1).

Из данных опроса видно, что почти с трехкратным отрывом лидирует показатель гибкости: виртуальный сервер значительно проще приобретается, масштабируется и т.д., чем физическое устройство. А показатели капитальных и операционных затрат хоть и отмечаются респондентами, но не находятся на лидирующих позициях.

Если конкретизировать показатели опроса, можно отметить следующие преимущества:

• возможность создать персональное сетевое окружение под каждое приложение или абонента в облачной инфраструктуре;
• снижение номенклатуры устройств;
• снижение затрат на обслуживание и обеспечение функционирования ИТ-инфраструктуры. Виртуальные сетевые устройства «живут» в виртуализованной среде на стандартных, однотипных серверах, поэтому их обслуживание не требует большой номенклатуры ЗИП и отдельного места в стойке;
• снижение сроков поставки: NFV – это ПО и лицензии, поставка которых значительно проще, чем поставка оборудования;
• простота тиражирования и масштабирования, при этом они достаточно просто поддаются автоматизации;
• малое время и простота восстановления. Резервные копии конфигураций виртуальных сетевых устройств или просто образы их виртуальных машин можно восстанавливать за считанные минуты на других серверах.

Благодаря применению NFV, провайдер за считанные минуты может предоставить абоненту требуемое количество и номенклатуру сетевых устройств, которые тот самостоятельно настроит в соответствии со своими уникальными требованиями. Кстати, возможность полностью управлять настройками своих арендованных сетевых устройств качественно отличает услугу от варианта, когда сети настраивает сам провайдер: это не дает заказчику контроля над настройками, многократно усложняет эксплуатацию сети для оператора и в итоге выходит всем значительно дороже.

В ситуации, когда существует стык между физической и виртуальной сетью, сразу же возникает проблема управления и настройки такой «гибридной» сети. Традиционные методы управления сетью, как правило, не устраивают либо по функциональным возможностям, либо с точки зрения парка поддерживаемого оборудования. Поэтому ИТ-индустрия стала искать «обходные пути». И правда, вместо того чтобы переконфигурировать физическую сеть в каждом отдельном случае, почему бы не оставить ее в покое, единожды настроив ее и потребовав только одного – надежности? В результате был создан новый вид сетей – оверлейные (Overlay Networks), или логические сети, создаваемые поверх физических. С сетевой точки зрения подобное делалось и раньше: под это определение вполне попадает хорошо известный стандарт IEEE 802.1q (VLAN). Разница в том, что протоколы overlay работают в маршрутизируемых сетях и обеспечивают существенно больше меток для идентификации сетей (как правило, 16 миллионов). В общем случае сеть overlay создается с помощью программных или аппаратных коммутаторов (gateway) и протоколов туннелирования (VXLAN, NVGRE, STT, GENEVE).

Благодаря overlay-сетям администратор виртуальной среды настраивает туннели между виртуальными машинами, не выполняя каких-либо настроек физических коммутаторов. Оверлейная сеть позволяет обеспечить необходимые приложениям сервисы поверх любой надежной сетевой инфраструктуры. Ее преимущества:

• обеспечение связности виртуальных машин в различных сегментах сети и даже в разных ЦОД;
• повышение стабильности работы сети за счет возможности использовать маршрутизируемую сеть в качестве транспорта;
• возможность совместной работы в виртуальной вычислительной инфраструктуре, взаимодействия с NFV-устройствами;
• все протоколы overlay работают по принципу инкапсуляции и используют стандартный формат кадра Ethernet, поэтому обеспечивается полная совместимость с существующей сетевой инфраструктурой.

К недостаткам технологии можно отнести использование Multicast (требуется поддержка Multicast в физической сетевой инфраструктуре и рост утилизации серверов за счет необходимости инкапсуляции-декапсуляции данных overlay.

Одним из «кирпичиков» программно-определяемой сетевой среды также является технология Software Defined Networking (SDN). Призванная использовать подход NFV для высокопроизводительных сетевых коммутаторов, обеспечивающих объединение серверов в единую инфраструктуру, SDN находит себе все новых сторонников.

Основная идея SDN – разделение управляющих и транспортных функций сетевой инфраструктуры. Весь «интеллект» сосредоточен на отдельной аппаратной/программной базе – выделенном управляющем SDN-контроллере: он на основе заданных правил определяет работу сети. Коммутаторы при этом выполняют элементарные действия с пакетами и лишаются большинства интеллектуальных функций. Управление трафиком – взаимодействие управляющего контроллера и коммутаторов – осуществляется с помощью специальных протоколов (наиболее перспективный и активно развивающийся – OpenFlow), оперирующих понятием «поток» (flow). Через них осуществляются разнообразные действия с трафиком – запрещение, разрешение, перенаправление и т.д. SDN обеспечивает гибкость управления сетью и существенно упрощает ее администрирование.

Но основная «изюминка» SDN все же в другом: SDN-контроллер должен иметь средства интеграции с системами оркестрации и в перспективе – с приложениями. Это позволит обеспечить управление ресурсами сети на основе актуальных запросов со стороны ИС. Например, сеть будет динамически выделять более широкую полосу пропускания на время сеанса видеоконференцсвязи, а затем перераспределять ее в пользу других приложений. Понимание, что в сети существуют не только пакеты и потоки, но еще и приложения – одна из ключевых особенностей сетей SDN, обеспечивающая им будущее в корпоративном мире. И именно централизованная архитектура SDN делает возможным реализацию этой задачи.

Ограничители движения

Технологии SDN, NFV, DCIM и т.д, вызывают интерес у многих российских провайдеров ИТ-услуг, но полноценных реализаций SDDC в нашей стране все еще нет. Тому есть несколько принципиальных причин.

Так, на рынке отсутствуют готовые решения, позволяющие провести интеграцию ПО управления виртуальными машинами и DCIM. Компании придется самостоятельно решать этот вопрос с помощью своих ИТ-специалистов или команды партнера – интегратора. Да и сам выбор DCIM вызывает определенные сложности. В настоящий момент это ПО предлагают две группы производителей. Первая включает в себя вендоров, исторически специализирующихся на создании решений для инженерной инфраструктуры ЦОД. При выстраивании системы управления физическими активами дата-центра они идут «снизу» – от сбора детальных данных о состоянии компонентов «инженерки».

Вторая группа – это производители, разрабатывающие решения для комплексного управления ИТ-инфраструктурой. Подобные системы обладают широким функционалом и предназначены для проведения детальных инвентаризаций, планирования размещения оборудования в ЦОД, прогнозирования, оперативного мониторинга электропотребления и т.д. То есть они решают задачу «сверху». При этом выбор того или иного решения зависит от конкретных условий. Компания должна определиться с тем, какая система необходима именно ей с учетом состояния инфраструктуры и планов развития, провести RFI, разработать KPI, сформировать шорт-лист и выполнить тестовые испытания. Все это выливается в значительные временные и трудовые затраты. Логично, что многие провайдеры откладывают это в долгий ящик, отодвигая и переход к программно-определяемой среде.

Если же говорить о технологиях NFV, SDN, Overlay Networks, то их распространение сдерживает их новизна и отсутствие полноценных, готовых к внедрению решений. В дата-центрах компаний живет привычное, давно знакомое сетевое железо, ИТ-специалисты знают его плюсы и минусы, в отличие от особенностей поведения виртуализированных сетевых устройств. Смена парадигмы требует дополнительных финансовых вливаний, но компании и так уже потратились на построение традиционной сети. При этом в настоящее время рассчитывать на возможность использования Open Source SDN-контроллеров особо не приходится: Open Source ПО для SDN представляет собой по большей частью «заготовку», которую нужно дорабатывать, прежде всего, программистам, что по карману не каждой компании. Ожидания рынка по поводу «дешевых» SDN-коммутаторов на данный момент не оправдываются: TCAM (Ternary Content Addressable Memory) для поддержки необходимого количества потоков является дорогим компонентом, соответственно, влияет на стоимость. К тому же вендоры по естественным причинам делают решения далеко не «Open»: никто из серьезных производителей не упустит возможности привязать заказчика проприетарными доработками.

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