Традиционные территориально распределенные сети создавались под статические и хорошо предсказуемые задачи обеспечения связи удаленных филиалов предприятий с их центральными офисами. Все в таких сетях проектировалось с расчетом на то, что сетевые соединения будут неизменными в течение долгого времени. Предназначенные для создания и развертывания большинства используемых сегодня сетевых сервисов системы ИТ/OSS взаимодействуют с самóй сетевой инфраструктурой через множество сложных проприетарных программных API-интерфейсов. В результате на разработку нового сервиса может потребоваться несколько лет, а на его внедрение – несколько недель.
Рост популярности облачной модели получения ИТ-ресурсов и услуг кардинально изменил требования заказчиков. Сегодня они хотят, чтобы все новые соединения и телекоммуникационные сервисы могли быть предоставлены в течение нескольких минут – столь же быстро, как облачные ИТ-услуги. Они предпочитают потреблять сетевые сервисы по требованию, получая именно то, что необходимо в данном месте и в данный момент времени, оплачивая только реально потребляемые ресурсы. Обеспечить такую оперативность и гибкость – очень непростая задача для операторов связи, особенно в мультисервисных гибридных сетях типа IP/оптика, в которых к тому же, как правило, используется разнотипное оборудование от множества производителей.
Недостатки традиционной модели
Офлайновый процесс проектирования сетевых подключений и сервисов просто не в состоянии обеспечивать быстро изменяющиеся потребности, присущие онлайновым облачным услугам, которые функционируют в режиме «по требованию». В традиционной модели, чтобы обеспечить возможность оперативного изменения характеристик сервисов, например быстро нарастить пропускную способность соединения, операторы вынуждены выделять и резервировать избыточные канальные ресурсы. Если этого не сделать, то придется смириться с тем, что качество услуг может серьезно деградировать. Чтобы сохранить прибыльность, операторам связи необходимы новые средства, позволяющие гибко адаптировать сети в реальном времени, оптимально используя имеющиеся у них сетевые ресурсы.
Разрыв между процедурами инжиниринга сетевых подключений и процедурами предоставления сетевых сервисов становится просто недопустимым. Средства автоматизации развертывания сервисов должны получать в реальном времени информацию о состоянии и доступности сетевых ресурсов так, чтобы мгновенно определять, имеются ли необходимые ресурсы для максимально эффективного выполнения поступившего запроса с предоставлением требуемых характеристик (пропускной способности, временнóй задержки трафика и пр.). В свою очередь, процедуры оптимизации и модернизации сети должны определяться с учетом собираемых в реальном времени характеристик физических линий связи и проложенных в них виртуальных туннелей. Короче говоря, операторам связи нужны новые инструменты для простого и быстрого предоставления запрошенных заказчиком сетевых сервисов – от разработки концепции до непосредственного развертывания.
Концепция SDN
Для решения этих задач необходима унификация средств автоматизации предоставления сервисов и оптимизации сети в единой интегрированной платформе, которая в реальном времени получает информацию о наличии и состоянии сетевых ресурсов. Реализация такой платформы существенно упростилась благодаря разработке принципов программно-определяемых сетей (Software-Defined Network – SDN).
Напомним, что главная идея SDN заключается в отделении функций передачи трафика от функций управления, включая контроль как самого трафика, так и осуществляющих его передачу устройств. В традиционных коммутаторах и маршрутизаторах эти процессы неотделимы друг от друга и реализованы в одной «коробке». Согласно концепции SDN вся логика управления выносится в так называемые контроллеры, которые способны отслеживать работу всей сети. На своей «южной» стороне контроллер поддерживает протоколы, в первую очередь Netsсonf и OpenFlow, обеспечивающие взаимодействие с сетевыми устройствами. На «северной» стороне контроллер предоставляет программные интерфейсы (API), прежде всего ReST или ReSTfull, наличие которых позволяет владельцу сети или сторонним разработчикам создавать приложения для реализации различных сетевых сервисов. Кроме того, через «северные» интерфейсы обеспечивается взаимодействие с сетью средств администрирования, управления, оркестрации и т. п.
На начальном этапе не все SDN-приложения и соответствующие сервисы выглядели для оператора как абсолютно новые. Многие из них были практически точной копией или улучшенной версией тех приложений, которые использовались в существующих на сетях маршрутизаторах и коммутаторах. Большинство из этих приложений были разработаны самими поставщиками сетевого оборудования, с учетом особенностей программного обеспечения маршрутизаторов и коммутаторов, выпускаемых данным производителем.
Концепция SDN позволила перейти к внедрению принципиально новых приложений и сервисов. Если в принятых сейчас решениях программные приложения ориентированы на особенности конкретных маршрутизаторов и коммутаторов, то при использовании новой сетевой архитектуры SDN снимаются требования по использованию на сети провайдера услуг конкретных типов маршрутизаторов, обладающих требуемым специфическим набором свойств для данных приложений. Новые SDN-приложения предусматривают многуровневую маршрутизацию сервисов на любой, в том числе мультивендорной инфраструктуре, гарантируя выполнение запрошенного заказчиком уровня качества предоставления услуг и учитывая доступные возможности существующей сетевой инфраструктуры.
Следует также отметить, что провайдеры услуг в настоящее время планируют свои сетевые ресурсы исходя из пиковых нагрузок. При переходе к реализации SDN-приложений оператор сможет существенно снизить затраты на свою сеть, поскольку будут обеспечены наиболее эффективное использование всех имеющихся ресурсов сети для предоставления услуг и масштабирование этих ресурсов по мере возникновения такой потребности.
Области применения SDN
Можно выделить три основных области, в которых применение технологии SDN способно принести наибольшую пользу сетевым операторам и их заказчикам (пользователям) при сервисном обслуживании пользователей.
Доступность контента
На сети провайдера услуг часто используются серверы для промежуточного хранения и поставки медиаконтента пользователям. Эти серверы принадлежат, как правило, провайдерам услуг или операторам сетей, специализирующимся на поставке контента (Content Delivery Network – CDN). Именно на этих сетях контент, который должен быть предоставлен пользователям, предварительно размещается по многочисленным серверам хранения контента, распределенным по различным географическим зонам. SDN-приложение проверяет наличие и доступность требуемого контента на данном сервере перед подачей на него команды на маршрутизацию информации. SDN-приложение будет способно обеспечивать маршрутизацию запроса от веб-страницы непосредственно на сервер, который обеспечивает динамическое формирование контента, а не на промежуточные серверы, что в значительной мере снижает задержки в сети при предоставлении услуг.
Доступность сервисов
SDN-приложения будут способны еще до выдачи команды на маршрутизацию требуемых сервисов пользователю мониторить их доступность по всей сети. В обычной практике мониторинг сети ограничивается проверкой возможности организации соединений (трактов) на каждом из технологических уровней L0/L1/L2/L3. Однако этого недостаточно для реализации задач по поставке контента. В новых SDN-приложениях мониторинг ориентирован не на контроль ресурсов на отдельных технологических уровнях, а на доступность ресурсов сети для предоставления сервисов пользователям из конца в конец (E2E).
Доступность сетевых ресурсов
При использовании SDN-приложения операторы сетей могут реализовать менеджмент пропускной способности (полосы пропускания) для того, чтобы гарантировать своим пользователям оптимальный режим поиска контента в Интернете и получения потокового видео в онлайновом режиме. Эти приложения позволяют контролировать требования к производительности узлов, пропускной способности сети и задержкам соединений для обеспечения передачи сигналов в целях удовлетворения всех потребностей уровня приложений. Тем самым исключается необходимость буферизации контента и обеспечивается лучшее восприятие контента пользователем.
Сервисные платформы нового поколения
Основываясь на принципах SDN, ведущие производители разработали сетевые сервисные платформы нового поколения, к которым относится и решение Network Services Platform (NSP) от компании Nokia. Такие решения унифицируют средства автоматизации предоставления сервисов и оптимизации сети на базе интегрированной платформы, которая позволяет оператору предоставлять сетевые сервисы в режиме «по требованию» – быстро, экономически эффективно и с высоким уровнем масштабирования.
Согласно исследованию ACG Research, платформа класса NSP существенно упрощает процедуру предоставления сетевых сервисов в сложных мультивендорных сетях типа IP/оптика, поэтому клиент может получить необходимую услугу в течение нескольких секунд, а не как раньше – через несколько дней или даже недель. Новые сервисы могут быть сформированы и выведены на рынок на 58% быстрее при сокращении затрат на 56%, а при использовании разработанных в компании Bell Labs интеллектуальных алгоритмов распределения новых соединений по сети платформа NSP позволяет операторам связи обслуживать на 24% трафика больше, причем без модернизации существующей сетевой инфраструктуры. Понятно, что чем больше трафика обслуживает сеть, тем более высокий доход получает ее владелец.
Для реализации интеллектуального предоставления сетевых сервисов «по требованию» необходимо абстрагировать или упростить представление сетевой инфраструктуры вышележащим программным системам ИТ/OSS, которые используются здесь для формирования сервисов и управления ими. Сама сеть с физического до сетевого уровня (Layer 0-to-Layer 3) может быть очень сложной, мультивендорной и предоставлять различные типы сетевых сервисов, например IP VPN, Ethernet VPN, оптические транспортные сервисы OTN (Optical Transport Network) или просто оптические каналы. Задача NSP – транслировать схемы, специфические для каждого конкретного сетевого элемента или их групп, в модели, не зависимые от конкретного вендора или устройства, выдаваемые на «северных» интерфейсах. Это позволит приложениям ИТ/OSS работать прозрачно с разнотипным оборудованием от разных производителей.
Как работает NSP
Системы NSP обычно состоят из двух ключевых элементов: так называемого директора (Network Services Director – NSD) и контроллера (Network Resource Controller – NRC). Выполняющий координирующие функции директор NSD обеспечивает упомянутый уровень абстракции, например, посредством предоставления простого графического интерфейса (GUI) для настройки сетевых сервисов. Получив запрос на предоставление сервиса (через интерфейс GUI или программные интерфейсы RESTful API), он задействует определенные оператором политики/правила для динамического выделения необходимых сетевых ресурсов и автоматического выполнения запроса. При этом используются получаемые в режиме реального времени данные о состоянии и загрузке сети (физических линий и логических туннелей), что позволяет оптимизировать выбор туннелей/путей, гарантировав запрошенные клиентом параметры качества обслуживания (например, указанные в договоре SLA) и обеспечив максимально эффективное расходование ресурсов сети.
Директор NSD может отслеживать ключевые показатели эффективности (KPI) сети, а также состояние зарезервированных ресурсов, чтобы определить, насколько загружены существующие туннели/пути. Если загрузка оказывается высокой, то, руководствуясь заранее определенными правилами, он может переводить сервисы на менее загруженные пути, которые обеспечивают примерно такие же характеристики. Когда уровень загрузки снижается, система автоматически переводит сервисы на оптимальный маршрут. Если в сети вообще нет маршрутов, способных обеспечить запрошенные характеристики, NSD «попросит» контроллер NRC сконфигурировать и инициировать новый маршрут.
Контроллеры NRC реализуют централизованное, интеллектуальное управление нижележащей сетевой инфраструктурой так, что операторы могут гибко адаптировать ее в соответствии со своими изменяющимися запросами, максимально эффективно расходуя имеющиеся ресурсы. Запросы по организации нового пути передачи трафика контроллер может получать от директора NSD, от системы OSS или системы оркестрации, а также от физических или виртуальных сетевых элементов. Реализованные в контроллере NRC алгоритмы обеспечивают расчет оптимального пути передачи трафика через сеть с учетом экономических или технических ограничений, а также доступных ресурсов и особенностей сетевой топологии.
На основе ключевых показателей эффективности сети (KPI), получаемых в реальном времени, контроллер NRC оптимизирует использование сетевых ресурсов. Например, он может, также в режиме реального времени, перевести на другой маршрут существующие потоки трафика или добавить маршруту полосу пропускания, чтобы гарантировать оптимальный уровень загрузки. За счет уменьшения сложности управления сетевыми ресурсами и повышения эффективности их использования, снижения риска перегрузки в сети контроллеры NRC позволяют оператору значительно сокращать капитальные (CAPEX) и операционные (OPEX) расходы, повышая доходность существующей инфраструктуры.
В сложных мультивендорных сетях типа IP/оптика могут потребоваться различные типы контроллеров. Например, контроллеры, предназначенные для работы с оптическими транспортными сетями, т. е. для управления элементами и сервисами уровней Layer 0 и Layer 1. Они могут базироваться на ПО, реализующем функции контроля (Control Plane) современных фотонных коммутаторов, как, например, устройства Nokia 1830 Photonic Service Switch (PSS).
Контроллеры для пакетных сетей типа IP/MPLS могут основываться на хорошо масштабируемом и функционально богатом программном обеспечении сервисных маршрутизаторов, позволяющем динамически формировать пути LSP (Label Switched Path) на сетевом (Layer 3) уровне через различные элементы IP-сетей. Для взаимодействия с установленными на сети IP-маршрутизаторами и анализа сетевой топологии такие контроллеры поддерживают традиционные протоколы, например BGP-LS (Border Gateway Protocol – Link State), OSPF (Open Shortest Path First), IS-IS (Intermediate System-to-Intermediate System).
Однако для гибридных сетей типа IP/оптика чрезвычайно важно наличие универсальных контроллеров, способных динамически формировать оптимальные пути передачи трафика через множество разнотипных сетевых доменов, в том числе доменов, построенных на оборудовании разных производителей. Такие контроллеры обеспечивают согласованное выделение (и оптимизацию использования) ресурсов сразу на всех уровнях сети (Layer 0-to-Layer 3), что гарантирует более эффективное использование сетевой инфраструктуры, нежели отдельная работа с разными уровнями.
На уровне управления ресурсами платформа NSP может использоваться совместно с SDN-контроллерами, поставляемыми различными компаниями, или решениями с открытым исходным кодом, например совместно с контроллером OpenDaylight. Операторы могут комбинировать NSP с SDN-платформами, разработанными для центров обработки данных (ЦОД), в частности с системой Nuage Networks VSP (Virtualized Services Platform), что позволяет автоматизировать предоставление облачных сервисов, синхронизировав этот процесс с предоставлением сетевых сервисов для доступа к облакам или для взаимодействия между ЦОД, например при реализации схемы катастрофоустойчивости или гибридных моделей.
Пример использования NSP: динамическое выделение сетевых ресурсов между ЦОД
Задача. Заказчик хочет, чтобы ресурсы сети, соединяющей центры обработки данных, динамически подстраивались под процессы перемещения виртуальных машин. Кроме того, на базе существующей сетевой инфраструктуры и с учетом политик безопасности необходимо обеспечить поддержку выполняемого в ночное время процесса резервного копирования, а также всплески активности клиентов.
Решение. На базе платформы NSP оператор может создать для заказчика новый сервис, который позволит ему перераспределять имеющуюся полосу пропускания между ЦОД или добавлять необходимые ресурсы полосы пропускания. Заказчик сможет получать дополнительные сетевые ресурсы «по требованию» или по расписанию, указав, когда и на какой период времени необходима дополнительная полоса пропускания. В свою очередь, оператор сможет динамически контролировать выделение этих ресурсов, оптимизируя использование сети.
