Первое официальное описание понятия виртуализации сетевых функций (NFV) появилось в октябре 2012 г. на SDN and OpenFlow World Congress в Германии. Тогда было высказано предложение о реализации функциональности множества различных специализированных сетевых устройств с помощью программ на базе стандартного оборудования. Было решено разработать открытые спецификации для такого перехода под эгидой European Telecommunications Standards Institute, что ровно через год привело к появлению первой документации по виртуализации сетевых функций.
В настоящее время в процесс по развитию данного подхода вовлечено более 240 компаний по всему миру. Что наиболее важно: основными инициаторами процесса являются крупнейшие интернет-сервис-провайдеры (ISP). Поддержка также оказывается со стороны производителей оборудования и софтверных компаний.
Процесс перехода на NFV (рис. 1) похож на недавно завершенный переход от специализированных офисных устройств, таких как калькулятор, пишущая машинка, факс, к персональному компьютеру. Разница лишь в том, что персональный компьютер представляет собой единое устройство, а для NFV предлагается задействовать ресурсы ЦОД.
С момента появления NFV рассматривают как технологию, близкую к SDN. Она тоже призвана сделать сети программируемыми, да и исторически появилась на SDN-конгрессе. В чем же разница? Не заменит ли со временем одна другую? Какова взаимосвязь между SDN и NFV?
Чтобы ответить на эти вопросы, достаточно посмотреть на эталонную модель ISO OSI. SDN решает задачи на низких уровнях, вплоть до транспортного, применяет обработку пакетов на коммутаторах, в том числе виртуальных. NFV, напротив, движется от приложения, распределяет работу виртуальных функций по серверам ЦОД. Эти две независимые технологии способны к симбиозу, при котором программируемым становится весь сетевой стек для всех устройств в ЦОД.
Основные драйверы концепции
Многие компании в настоящее время переводят, хотя бы частично, свою ИT-инфраструктуру в облака. Это могут быть либо частные облачные решения, построенные в собственном ЦОД предприятия, либо публичные на ресурсах сторонней организации, либо гибридные решения. И если всего пару лет назад в облако переводились лишь вычислительные ресурсы, то теперь есть возможность построить в облаке собственную виртуальную сетевую топологию.
Для этого облачные платформы IaaS уже достаточно давно внедряют в свои платформы элементы, подобные виртуальным сетевым функциям (VNF). Например, для клиентов IaaS OpenStack доступны такие виртуальные функции, как виртуальный маршрутизатор, VPNaaS (шифрованные соединения), LBaaS (балансировка нагрузки), FWaaS (межсетевой экран). Физическая реализация в разных ЦОД может отличаться, но с точки зрения описания виртуальной инфраструктуры клиент получает унифицированное API, что довольно удобно: нет привязки собственной инфраструктуры к конкретному ЦОД. Сетевые администраторы получают удобный и функциональный инструмент, при этом нет необходимости разбираться в тонкостях настройки: тот же маршрутизатор достаточно просто подключить к необходимым сетям, основная настройка произойдет автоматически.
Тем не менее, виртуальная инфраструктура существенно отличается от физической, вследствие чего прямой переход невозможен. В виртуальной среде описывается логическая схема взаимодействия, а не физическая: вместо коммутаторов используются L2-сети, вместо тегов VLAN – множество сетевых интерфейсов. Даже применение протоколов маршрутизации, агрегации каналов и пр. не совсем корректно. Действительно, администратор виртуальной инфраструктуры не обладает знаниями о физической структуре ЦОД и методике размещения своей сети. Результат может быть весьма неожиданным, когда формально построенная по всем правилам высокой надежности сеть становится недоступной просто потому, что вся была размещена на вдруг отказавшем физическом сервере. Вопрос обеспечения надежности виртуальных компонентов является задачей оператора ЦОД, а не администратора виртуальной инфраструктуры.
С учетом того, что применение каждого экземпляра виртуальной сетевой функции в ЦОД может быть монетизировано путем подсчета потребленных ресурсов и выставления счета, увеличение количества доступных VNF выгодно владельцам ЦОД.
Операторы связи заинтересованы в переходе на NFV ради снижения затрат на поддержку инфраструктуры и простоты внедрения новых услуг. При внедрении этой концепции снижается зависимость от множества производителей оборудования, появляется возможность динамического перераспределения ресурсов в реальном времени. По информации Vodafone Research, внедрение NFV снижает OPEX на 60% в течение трех лет, CAPEX – на 59% в течение пяти лет.
Для внедрения NFV операторам предстоит строить свои ЦОД с поддержкой NFV, которые со временем будут мало отличаться от коммерческих ЦОД, предоставляющих IaaS.
Первый шаг: Virtual Appliance
Серверы стандартной x86-архитектуры со специальным программным обеспечением в качестве сетевых устройств применяются уже достаточно давно. Например, многие компании практикуют использование интернет-шлюзов на базе Linux или коммерческих программных UTM. Небольшие интернет-операторы имеют опыт работы с программными BRAS, BGP-маршрутизаторами и другими программными средствами, что, как правило, оправдано до тех пор, пока пропускной способности одного сервера хватает для текущих нужд.
Распространение программных решений в виде Virtual Appliance (специально подготовленные виртуальные серверы) позволяет быстро разворачивать инфраструктуру в виртуальной среде, что снижает затраты на внедрение и поддержку. За счет уплотнения сокращаются и капитальные затраты.
Без использования специальных средств производительность физического сервера обычно не превышает 300 тыс. пакетов в секунду из-за ограничений сетевого стека операционной системы. Данный показатель существенно снижается при использовании серверной виртуализации.
Virtual Appliance можно рассматривать как «коробочное» решение для сетей с малой нагрузкой. При превышении нагрузки нужно вручную переделывать всю сеть, добавлять новые устройства, решать проблемы балансировки нагрузки. В виде образа Virtual Appliance можно предлагать клиентам виртуального ЦОД (в частности, в настоящий момент активно развивается проект Murano для OpenStack).
NFV: что нового
При переходе на NFV появляется дополнительный слой управления оркестрации (MANO), который позволяет горизонтально масштабировать услуги. В случае нехватки производительности запускаются новые экземпляры ПО на новых серверах в тех объемах, в которых это необходимо, а при снижении нагрузки высвободившиеся ресурсы можно вернуть в общий пул для использования другими виртуальными сетевыми функциями.
MANO также помогает решать задачу высокой доступности услуги. Дело в том, что для сервиса нет нужды решать задачу доступности 24×7 каждой виртуальной машины. Конечных пользователей не должна интересовать реализация, им важны потребительские свойства. Главное – обеспечить сохранность пользовательских данных, а сервис, при необходимости, может быть переброшен на другой виртуальный сервер.
Ключевое отличие здесь как раз в том, что конечный пользователь получает не виртуальный сервер с установленным программным обеспечением, а сетевую услугу, т. е. вопросы поддержания жизненного цикла его не касаются. Разумно, если этой проблемой будет заниматься лицо, предоставляющее услугу, – в общем случае оператор VNF. Получаем схему, представленную на рис. 2.
В простейшем случае владелец ЦОД может сам предоставлять все услуги, взяв на себя все сервисы по работе виртуальных сетевых функций. Однако нет ничего плохого в передаче указанной функции сторонним компаниям, сосредоточившись на предоставлении услуг IaaS.
Важной особенностью NFV можно назвать способность образовывать сервисные цепочки (рис. 3), когда пакеты могут проходить сразу через несколько виртуальных сетевых функций, тем самым образуя сложный сетевой сервис.
В экономике NFV вопросу сетевой производительности серверов уделяется очень много внимания. Действительно, производительность современного сетевого процессора, встроенного в специальное устройство, несоизмеримо выше тех 300 тыс. пакетов в секунду, которые может позволить себе обычный сервер, при вполне сопоставимой стоимости. С этой целью сейчас активно внедряются такие технологии, как DPDK, NetMap, vFA, SR-IOV и пр. За счет уменьшения нагрузки ядра операционной системы на обработку сетевых пакетов удается достигать производительности десятки миллионов пакетов в секунду. Часть обработки может быть вынесена напрямую на сетевой адаптер.
С целью повышения производительности в NFV также предусмотрена глубокая конкретизация описания виртуальных машин. В частности, предлагается отказаться от overcommitment при распределении загруженных виртуальных машин и использовать выделение ядер. Более того, в описании виртуальных серверов можно учитывать особенности архитектуры NUMA (рис. 4), тем самым ограничивая пул физических серверов, на которые виртуальные ресурсы могут быть выделены.
NFV ни в коем случае не стремится заменить все текущие сетевые технологии и устройства. Наоборот, для каждой виртуальной функции допускается работа гибридных систем, где только часть сетевой инфраструктуры виртуализирована.
Виртуальные сетевые функции могут быть распределены по нескольким площадкам, а иногда частично вынесены на площадку пользователя. В этом случае можно говорить о концепции D-NFV, или распределенной виртуализации сетевых функций. Например, у каждого абонента ставится небольшой сервер, осуществляющий шифрацию и/или сжатие данных, управление каналом передачи, удаленное тестирование и мониторинг. С точки зрения логической структуры такие абонентские устройства являются выделенными ресурсами оператора. Разработки в области D-NFV активно продвигает компания RAD, в России есть молодой стартап Robonect.
NFV как модная технология
Как уже отмечалось, огромный интерес со стороны потенциальных клиентов к рассматриваемой нами концепции при весьма ограниченном предложении приводит к желанию многих производителей застолбить себе место на растущем рынке. Многие стремятся заявить о поддержке NFV в своих продуктах, если те хотя бы отдаленно похожи на виртуализацию сетей. При этом многие основополагающие основы просто игнорируются.
Опасность здесь исходит от подмены понятий, когда клиент получает вместо желаемого нечто совершенно иное, что дискредитирует саму идею. Этим особенно грешат производители специализированного сетевого оборудования, не желающие терять рынок. Большинство современных устройств поддерживает виртуализацию, например VRF. Если к такому оборудованию добавить слой управления, получим виртуализированную сетевую функцию, но это еще не NFV.
Чтобы полностью поддержать NFV, не хватает главного – реализации функций на стандартном оборудовании. Собственно, поэтому многие производители стремятся портировать свои решения на платформу x86. Например, Juniper vMX или Cisco IOS XRv уже успешно внедряются в качестве виртуальных функций для пилотных проектов NFV по всему миру.
В России тоже ведутся разработки виртуализированных сетевых функций. В качестве примера можно привести молодую компанию NFWare с разработкой Virtual Carrier Grade NAT.
Заключение
Всего за три года после первой white paper была сформирована понятийная база, разработаны спецификации по дизайну MANO, безопасности, производительности – всего 11 спецификаций. Множество организаций уже ведут свои разработки согласно спецификациям ETSI. Активно осуществляются работы по поддержке требований NFV в различные облачные системы.
Поддержка NFV в упрощенном виде реализована в разработке Центра прикладных исследований компьютерных сетей (ЦПИКС) – облачной платформе Cloud Conductor. Появился тестовый код OPNFV. – проект MANO с открытым исходным кодом. Выполняются закрытые разработки под эгидой различных операторов связи и корпораций.
Появились коммерческие образы для виртуальных машин, которые можно применять в публичных платформах NFV.
Все основные принципиальные проблемы уже практически решены, нерешенными пока остаются чисто технические вопросы взаимодействия компонентов, совместимости разработок различных поставщиков.
Через год-два можно ожидать появления готовых решений и формирования рынка NFV-платформ. Вероятно, будут коммерческие «коробочные» решения, а также открытые разработки на базе Network Function Virtualization Infrastructure (NFVI) OpenStack. Операторы связи будут строить ЦОД для собственной инфраструктуры и попутно для инфраструктуры своих клиентов.
Возможно также формирование рынка виртуальных сетевых функций в виде сервисов от независимых поставщиков. По сути, в платформе будет собственный Market place, где можно выбрать сетевые решения от различных авторов. По итогам аналитического отчета IDC Research, в ближайшие три года мировой рынок SDN и NFV будет расти ежегодно в среднем на 89,4%! К 2018 г. его объем превысит 8 млрд долл.
Если для коммерческих ЦОД внедрение виртуализации сетевых функций дает возможность расширить набор предоставляемых услуг, то для операторов связи эта концепция является по сути революционной, в корне меняющей его работу.
Что касается компаний – разработчиков программного обеспечения, то для них растущий рынок NFV открывает просто колоссальные возможности роста. Рынку требуются решения по оркестрации и управлению, а также многочисленные виртуальные сетевые функции.
