Программно-конфигурируемые сети

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

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

Архитектура SDN является: 

Традиционный стек протоколов TCP/IP, принятый де-факто как стандарт в середине 80-х годов прошлого столетия, является громоздкой и негибкой системой управления компьютерной сетью, поскольку она и «думает», и «делает»: сначала решает задачу построения маршрута, а потом сама же прокладывает этот маршрут. Таким образом в современных сетях функции управления и передачи данных совмещены, что делает контроль и управление очень сложным. Такой подход накладывает несколько серьезных ограничений на работу с ресурсами сети. Работа администратора в сетях с архитектурой TCP/IP сегодня больше искусство, чем инженерия.

Основные причины, которые привели к необходимость пересмотра традиционной сетевой архитектуры:

• Изменение модели трафика: Приложения, которые чаще всего получают доступ к географически распределенными базами данных и серверам через публичные и частные облака, требуют очень гибкого управления трафиком и доступа к пропускной способности по требованию.
• «Консьюмеризация IT»: тенденция Bring Your Own Device (BYOD) требует, чтобы сети были одновременно и гибкими, и безопасными.
• Рост облачных сервисов: Пользователи хотят в любое время иметь доступ к приложениям, инфраструктуре и другим ИТ-ресурсам.
• Требование высокой пропускной способности: Обработка современных массивов данных задействует огромное количество параллельных вычислительных ресурсов, для которых требуются дополнительная пропускная способность и всеобщая связность.
• Большая сложность современных сетей, которая не позволяет им развиваться с необходимой клиентам скоростью: добавление или перемещение устройства в сети, изменение политик стали слишком сложными, затратными по времени и требовали физического участия администратора, и могли привести к нарушениям работы всей сети.
• Сложность масштабирования: проверенный временем подход переподписки линков для обеспечения масштабируемости совершенно неэффективен при динамической модели трафика в виртуализированных сетях. Эта проблема еще более актуальна для сетей сервис-провайдеров.
• Зависимость от вендоров: невозможность внесения изменений без привлечения производителя, необходимость длительного ожидания необходимых изменений, отсутствие единых стандартов и открытых интерфейсов ограничивают возможности операторов сетей в адаптации оборудования под индивидуальные задачи.

 

Виртуализация сетевых функций (Network Function Virtualization, NFV) предлагает новый способ проектирования, развертывания и управления сетевых сервисов. NFV отделяет такие сетевые функции, такие как NAT, firewall, обнаружение вторжений, DNS, фильтрация трафика и многие другие от аппаратного уровня, чтобы была возможность программирования нужных функций на программном уровне.
NFV был предложен (разработан) чтобы объединить все сетевые компоненты, необходимые для поддержки полностью виртуализованной инфраструктуры - в том числе виртуальных серверов, систем хранения данных, и даже других сетей. 

Основные преимущества NFV:  

• Гибкость: Операторы, стремящиеся быстро разрабатывать и развертывать новые сервисы, требуют гораздо более гибкой и масштабируемой сети.  
• Стоимость: сегодня фактор стоимости является главным для любого оператора или сервис-провайдера тем более, теперь, когда есть пример Google и нескольких других корпораций, которые перевели свои ЦОДы на коммодити коммутаторы (white box) для снижения затрат.
• Масштабируемость: Для быстрого удовлетворения меняющихся потребностей клиентов и предоставления новых услуг, операторы связи и сервис-провайдеры должны иметь возможность масштабировать свою сетевую архитектуру на нескольких серверах, не ограничиваясь возможностью аппаратного уровня. 

Таким образом, исторически технологии SDN и NFV развивались параллельно, особо не обращая внимания на особенности и возможности друг друга. SDN – это управление, стек сетевых протоколов, пересмотр принципов управления сетью. NFV – это сокращение ROI, маркетинг, бизнес и архитектура, скорость ввода новых сервисов, дифференциация клиентов. Оба подхода нацелены на то, чтобы уменьшить сложность сети, обеспечить масштабируемость и автоматизацию управления, повысить мощности физической инфраструктуры сетей с наложением виртуальной, упростить развертывание, автоматизировать администрирование и снизить OPEX и CAPEX. 

Существуют три варианта совместного использования SDN и NFV: NFV на базе SDN, когда SDN управляет размещением, взаимодействием, чейнингом (chaining) виртуализированных функций, SDN на базе NFV, где SDN является виртуализированным сервисом в неком тенанте, и SDN+NFV, когда две области взаимодополняемы и существуют в самых разных комбинациях. 

В случае с NFV на базе SDN, SDN контроллер используется для управления ресурсами физической инфраструктуры и находится в управлении платформой, управляя физическими ресурсами соответствующей инфраструктуры. Сейчас для того, чтобы настроить развитую географически распределенную инфраструктуру с VPN, необходимо использовать MPLS, соответствующим образом настроить оборудование и иметь очень квалифицированный персонал. Представьте себе сеть оператора, который предоставляет услуги организации VPN уровня L2 для предприятий. В настоящее время эту услугу реализуют с помощью решения MPLS/VPLS. Для этого необходимо сначала спроектировать виртуальную сеть, потом настроить все сетевые устройства. Эта задача требует серьезной квалификации персонала и времени. Мы можем виртуализировать функцию проектирования VPLS туннелей с помощью несложного графического интерфейса, а настройку коммутаторов моментально произведет обычный SDN-контроллер. В этом случае мы можем создавать целые цепочки сервисов для различного вида трафика. Мы встраиваем мощный сервер с платформой поддержки и управления виртуализированными сервисами (NFV) в инфраструктуру сети, управляемой SDN-контроллером. Это позволяет управлять цепочками сервисов не только про-активно, но и реактивно, динамически.  

Для SDN на базе NFV, где SDN используется как виртуализированный сервис, ярким примером является тенант, который представляет собой виртуализированную инфраструктуру крупного предприятия. Естественное желание CEO такого предприятия – иметь контроль над политикой маршрутизации, над безопасностью траффика в таком сервисе. В этом случае вполне реально разместить контроллер с соответствующей системой приложений на одну из виртуальных машин, и он будет управлять виртуализированной сетью данного тенанта. Иногда директор предприятия не хочет брать на себя всю головную боль, связанную с поддержкой работы контроллера, и тогда возникает необходимость рассмотреть контроллер, как отдельно стоящий виртуализированный сервис, и подключить свой тенант к этой функции. Как исходные данные, при этом задана спецификация политики маршрутизации, администрирования сети, а уже ее реализацией занимается контроллер.  

Наконец, третий случай – SDN в сочетании с NFV, когда внутри ЦОД можно использовать 1 или 2 сценарий, но это будет уже географически распределенная среда с единым уровнем оркестрации, при этом владельцу тенанта, конечному пользователю, всё равно, где и как (если это облачная среда) реализуется тот или иной сервис. Таким образом, создается сеть ЦОДов, на которых работают виртуализированные сервисы и которые находятся под управлением единого оркестратора, который и управляет единой средой.  

При этом стоит отметить, что сейчас активно разрабатываются подходы, позволяющие объединить сеть ЦОДов, которые находятся под управлением разных облачных платформ. Получается, пользователю такой инфраструктуры нужно каждый раз заботиться, как перенести свои приложения с одного гипервизора на другой, или как в случае OpenStack для перехода с одной версии на другую нужно по существу проделать огромную работу, чтобы перенести свои приложения. Не нужно думать, что это единая среда, которая работает на единой физической инфраструктуре, это может быть географически распределенная сеть ЦОДов поверх которой есть облачные платформы и уровень оркестрации, который и заставляет выполнять нужные функции по управлению локальной инфраструктурой в интересах тех задач, которые задает пользователь.