.png)
Одна из самых горячих тем сетевой отрасли — виртуализация сетевых функций, или NFV. В рамках этой концепции специализированные сетевые устройства заменяются на программное обеспечение, которое выполняется на серверах общего назначения. Наибольшую известность и распространение получила централизованная модель развертывания NFV на базе ЦОД. Компания RAD расширяет эту исходную модель, подчеркивая, что реализация NFV может быть и распределенной (distributed), а виртуализация сетевых функций может осуществляться в любом месте сети — там, где она наиболее эффективна и экономически оправданна. В рамках такой распределенной (Distributed NFV, D-NFV) модели RAD активно продвигает решения по виртуализации на стороне пользователя. На всемирном конгрессе Network Virtualization & SDN World, состоявшемся в конце мая в Лондоне, решение RAD для D-NFV названо инновацией года в области NFV. Предлагаемый подход мы обсудили с Юрием Гиттиком, отвечающим за стратегическое развитие решений компании.
Журнал сетевых решений/LAN: Большинство крупных производителей делают акцент на преимуществах централизованного развертывания виртуализированных сетевых функций. Почему компания RAD избрала иной подход?
Юрий Гиттик: Если проанализировать приоритеты ведущих операторов связи и имеющиеся на рынке предложения, то станет понятно, что решения NFV проектируются главным образом для мобильных сетей. Например, виртуализированное пакетное ядро (vEPC) предполагает реализацию всех основных функциональных узлов EPC в виртуализированной среде, развернутой на стандартных серверах в ЦОД. Активное внедрение технологий LTE и LTE-Advanced сопровождается масштабной реконструкцией сетей, поэтому такие решения очень востребованы. Но функции EPC и ранее были централизованными, поэтому просто происходит замена специализированных устройств на ПО, работающее на стандартных серверах.
Но ситуация меняется, когда речь заходит о решениях NFV при реализации услуг для корпоративных пользователей. Трафик таких услуг далеко не всегда целесообразно пропускать через центральный узел. Это обстоятельство зачастую не учитывается. Если канал некачественный, могут возникнуть проблемы. Предположим, в центральном ЦОД размещается виртуализированный межсетевой экран. Если трафик до него будет доходить с серьезной задержкой или ошибками, он может блокировать легальный сеанс связи. Чтобы все работало нормально, придется вложить немалые средства в модернизацию каналов связи, что с экономической точки зрения может оказаться нецелесообразным. Альтернатива — разместить межсетевой экран ближе к источнику трафика.
Надо думать не только об оптимизации использования вычислительных ресурсов, но и о сетевой связности, которая не всегда наилучшим образом подходит для централизованной реализации NFV. Существует много сетевых функций и сервисов, чувствительных к задержкам и потерям пакетов. Специалисты по ИТ, занимающиеся вопросами виртуализации, не всегда принимают во внимание характеристики сети, полагая, что широкие оптические каналы доступны всегда и везде, но это, к сожалению, далеко не так…
В области NFV мы выбрали направление, которое очень органично дополняет пакет предложений RAD, ведь компания многие годы занимается устройствами доступа к сервисам операторов и терминирования этих сервисов. Мы фокусируемся на реализации NFV для предоставления услуг корпоративным заказчикам. У таких заказчиков имеется много распределенных узлов — из этого исходного посыла и возник интерес к модели D-NFV.
LAN: Российские заказчики чрезвычайно озабочены вопросами безопасности, поэтому, полагаю, предложение оставить сетевые функции на их территории должно быть воспринято весьма благожелательно.
Гиттик: Действительно, вопросы безопасности — еще один фактор в пользу D-NFV. Различные корпоративные ограничения, например относительно выхода информации за пределы сети компании, серьезно сдерживают распространение централизованной (по сути, облачной) модели. Часть сетевых функций тоже нежелательно выносить за территорию заказчика. Согласен, эта концепция может оказаться чрезвычайно актуальной для России.
LAN: Концепцию D-NFV придумали в RAD?
Гиттик: Нет, это не наше изобретение. Распределенный подход к реализации NFV изначально был заложен в базовых документах, подготовленных ETSI NFV ISG — международной рабочей группой, которая занимается вопросами стандартизации NFV. В них четко указано, что NFV может размещаться как в центре, так и на границе (edge) сети оператора, включая узлы заказчика. Но по сравнению с централизованным подходом интерес к такому варианту на начальном этапе разработки решений NFV был существенно ниже.
Вместе со многими ведущими мировыми операторами мы работаем, чтобы развить и распределенный подход. Для этого, в частности, мы уточнили определения в одной из базовых спецификаций — Use Cases. Кроме того, мы являемся соучредителями утвержденного в ETSI ISG проекта Multivendor Distributed NFV Proof of Concept (PoC) о проверке реализации концепции в мультивендорной среде. 17–18 июня 2014 года состоялась успешная публичная презентация этого проекта на престижной конференции Big Telecom Event в Чикаго.
LAN: Какие функции уже реализованы в концепции D-NFV?
Гиттик: Решение D-NFV — это открытая система. RAD предлагает оконечное оборудование (NTU) с интегрированной серверной платформой x86 для виртуализации функций на площадке заказчика. Это стандартная среда OpenStack с гипервизором KVM. Функции, которые будут поддерживаться нашими устройствами, разрабатываются и будут разрабатываться главным образом сторонними компаниями. Рынок таких виртуализированных функций, которые могут быть внедрены как стандартные виртуальные машины, активно развивается, практически все производители сетевого оборудования уже поставляют (или планируют) подобное ПО. Некоторые вещи, конечно, мы делаем сами — например, распознавание трафика различных приложений (это наше ноу-хау). Однако основной функционал D-NFV будет реализовываться не нами.
Я уже упомянул о демонстрации Multivendor D-NFV PoC. В ходе этого тестирования, которое было организовано при спонсорстве нашего партнера — CenturyLink, одного из крупнейших операторов США, представлено две функции NFV: межсетевой экран разработки Fortinet и система шифрования/дешифрования трафика компании Certes Networks. Эти функции могут работать по отдельности (причем одна часть трафика может направляться на межсетевой экран, другая — на шифровальщик Certes) или последовательно применяться ко всему трафику. В качестве оркестратора задействуется система Blue Planet компании Cyan.
Я назвал только две функции. Очевидно, их может быть гораздо больше — например, оптимизатор WAN, контроллер SBC, системы сквозного контроля качества QoS, мониторинга потребительского качества (QoE) приложений и т. д. Раньше большинство подобных функций «существовало» в виде специализированных устройств (appliance), теперь — в соответствии с общей тенденцией — эта функциональность реализуется в виде виртуальных машин, которые оператор может загрузить на любой сервер.
LAN: Не возникает ли проблем с ресурсами устройства NTU в представленном вами решении — ведь, как правило, это совсем небольшая «коробочка»?
Гиттик: Нет, при современном уровне развития микроэлектроники ресурсы NTU не проблема. Сложности возникают из-за того, что большинство виртуальных машин не оптимизированы для работы в таком режиме, когда среда виртуализации доступна только одному заказчику (single tenant). Обычно виртуализированные системы предназначены для сред совместного использования ресурсов (multi-tenant), развернутых в крупных ЦОД. Поэтому целесообразно сотрудничать с разработчиками ПО и добиваться, чтобы они учитывали специфику применения их систем в модели D-NFV.
Для создания экосистемы D-NFV мы активно работаем с уже упомянутыми разработчиками Cyan, Fortinet, Certes и другими компаниями.
LAN: Обычно NFV всегда упоминают «в связке» с SDN. Они действительно не могут функционировать по отдельности?
Гиттик: Любое решение NFV можно реализовать как совместно с SDN, так и без нее. При этом использование архитектуры и технических решений SDN может дать ряд преимуществ, например, в части выстраивания цепочки услуг — service chaining. Предположим, у нас есть набор виртуализированных функций. Из них можно создавать различные наборы услуг для разных заказчиков. Контроллер SDN может координировать создание таких цепочек и распределение трафика между ними — например, определять, что данный поток направляется сначала на межсетевой экран, затем на WAN-оптимизатор и т. д. Причем часть функций может быть централизована, часть — распределена.
Если говорить об SDN в целом, то этот термин сегодня имеет два значения. Первое связано с конкретными элементами SDN: коммутаторами OpenFlow, контроллерами, приложениями. Второе описывает общие принципы. Пока что мы больше ориентируемся на методологию SDN, а не на элементы SDN, так как на данный момент не очень понятно, как SDN будет доводиться до уровня сетей доступа. В настоящее время основные инсталляции SDN осуществляются в ЦОД. Нет четко определенного расширения SDN на всю сеть. И данное обстоятельство сдерживает распространение этой технологии.
LAN: Давайте вернемся к продвигаемому вами подходу D-NFV. Насколько он меняет возможные сценарии виртуализации сетевых функций?
Гиттик: Очевидно, что для реализации централизованной модели где-нибудь в центре должен располагаться ЦОД. Мы предлагаем начать с децентрализованной (center-less) модели. Предположим, оператор связи хочет предоставить банку функцию межсетевого экранирования как услугу. Первый вариант — разместить соответствующую инфраструктуру NFV в ЦОД. Второй — «поднять» соответствующие виртуальные машины на граничных устройствах. В последнем случае можно приступить к предоставлению соответствующей услуги даже без больших инвестиций в ЦОД.
Соответственно, есть две стратегии развертывания услуг. Одна из них — «сверху вниз» (Top-down). Она предполагает вложение немалых средств в создание ЦОД и ориентирована на обслуживание (из ЦОД) большого числа заказчиков. Стратегия «снизу вверх» (Bottom-up) позволяет обойтись без крупных инвестиций: поскольку ЦОД не требуется изначально, можно начать с нескольких заказчиков, готовых платить за новую услугу, которая реализуется на базе оконечного оборудования.
Подход «снизу вверх» на базе D-NFV не только снижает время вывода новой услуги на рынок (Time to Market), но и позволяет быстро свернуть услугу (Time to Failure), если она не востребована. При этом на том же оборудовании можно запустить другие услуги, просто загрузив соответствующие виртуальные машины. Таким образом, оператор получает свободу маневра: услуги можно быстро внедрять, адаптировать и быстро сворачивать.
Децентрализованный подход, который подразумевает D-NFV, требует незначительных вложений и сводит риски к минимуму, одновременно обеспечивая гибкую организацию услуг. При этом решение D-NFV позволяет сочетать виртуальные сетевые функции, поддерживаемые на площадке заказчика, в сетевых узлах и в ЦОД.