Исторический экскурс
Развитие технологий сетей передачи с 1969 года (ARPANET) развивалось в том ключе, чтобы каждый аппаратный компонент был независимый от других компонентов. Протоколы взаимодействия работали по принципу обмена контрольной информации, которая использовалась алгоритмами для анализа топологии и построении моделей взаимодействия между устройства.
Есть версия, что такой подход был специально запроектирован для повышения выживания сетей передачи данных в условиях военного конфликта, при котором часть устройств либо линий связи может выйти из строя и оставшемся компонентам сети необходимо было самостоятельно принять решения какая топология осталась целостной и работоспособной. То есть децентрализация работы сети была заложена как цель.
Все разработанные протоколы динамической маршрутизации (RIP, OSPF, IGRP, BGP) и протокол ветвящегося дерева (STP) были построены на этом принципе – устройства как равноправные обмениваются имеющейся информацией о своих соединения с соседями и самоорганизуются в общую топологию, которая работает как единая сеть.
Достигнув цели автономности, которая была актуальная, со временем, когда нагрузка на сеть выросла, стало очевидно, как неэффективно используются текущие соединения. Работа сети на втором уровне OSI стала приводить к отключению избыточных соединений и тем самым снижая общую утилизацию сети передачи данных. Работа сети на третьем уровне OSI стала приводить к асимметричной маршрутизации, что могло вызвать непоследовательную доставку пакетов и это приводило к росту занятого объема буфера на принимающих устройствах.
Другой проблемой стал тот факт, что сетевые функции (Firewall, Load Balancing, Mirroring), которые реализовывались в определенном физическом месте сети передачи данных могли находится далеко в топологии от того места, где трафик генерировался. Так как трафик должен был быть доставлен до аппаратного устройства и только там быть, например, отфильтрованным, то это приводило к лишней утилизации и снижения эффективности, чем если бы трафик был бы отфильтрован в месте генерации трафика.
SDN
С тех пор прошло немало времени и хоть угроза военных конфликтов осталась, технологическими лидерами было принято решение, что теперь цель централизации отвечает современным потребностям. Такой подход привел к необходимости пересмотра модели работы сети передачи данных в сторону разделения функций управления и функций передачи данных. Было принято решение все функции управления сконцентрировать в единой точке — контроллере, который собирал бы информацию с устройств передачи трафика и принимал бы решение о том, как этим трафиком управлять.
Централизация позволяет повысить эффективность загруженности всех соединений и утилизировать по максимуму производительность аппаратных устройств. Разработанный протокол Openflow решал задачу управления плоскостью передачи трафика, программируя коммутаторы действиями, которые должны быть совершены с трафиком. При этом модель принятия решения о том каким образом должен быть передан трафик внутри контроллера плоскости управления могла быть реализована совершенно по другим математическим моделям, чем известные протоколы динамической маршрутизации. Разница в том, что современные протоколы маршрутизации исходят из принципа обмена информации между точками о топологии. Но если вся топология хранится в одном месте, то нет необходимости в алгоритмах обмена информацией. Есть лишь необходимость использовать информацию о топологии для того, чтобы направить трафик из точки А в точку Б. При централизованном подходе решения о передачи трафика могут быть не универсальны. То есть нет необходимости в передачи всего трафика между двумя точками по одному и тому же пути. Часть трафика может идти по одному пути в топологии, а часть трафика может использовать другой путь в той же самой топологии. Такое подход повышает эффективность за счет максимальной утилизации имеющейся сетевой инфраструктуры.
NFV
Другое преимущество в том, что, обладая информацией о том, какие политики должны быть применены к различным типам трафика в различных точках входа трафика в сеть, есть возможность применить сетевую функцию непосредственно в этой точке сети. Если представить, что сотни сетевых функций можно отделить от аппаратной платформы и реализовать в виде программы, в которую в качестве входных данных поступает управляющая информация (какие политики необходимо применить к трафику) и задать входящий и исходящий интерфейс для трафика, то тогда эту сетевую функцию можно запускать на стандартных операционных системах на x86-серверах. Запуская эти программы в точках генерации либо обмена трафика, можно центральным контроллерам программировать коммутаторы для передачи необходимого типа трафика внутрь сетевой функции. Трафик после обработки сетевой функции возвращается в плоскость передачи данных и передается до конечного получателя.
Одним из аргументов принятия такой модели является снижение стоимости сети передачи данных по причине того, что конкретные сетевые функции, реализованные на специализированной аппаратной платформе, предлагаются по более высокой цене, чем реализация тех же функций на универсальной вычислительной платформе. Производительность специализированных платформ всегда была выше и это имело значения в эпоху не очень производительных универсальных процессоров, но современные тренды нивелировали данное отставание и теперь даже на общих CPU за счет увеличивающего быстродействия стало возможно выполнения указанных сетевых функций при необходимой производительности.
Другим преимуществом стало то, что при наличии возможности запустить сетевую функцию в любом месте сети передачи данных отпала необходимость в гигантской производительности в одном месте, ведь можно распределить требуемую производительности на всех точках генерации или обмена трафиком. Данный факт позволяет очень быстро масштабировать производительность сетевой функции при резком увеличении объема трафика. Такое возможно при событиях в жизни человечества, которые генерируют большой объема трафика, например, чемпионат по футболу, проведение Олимпиады либо трансляция свадьбы английского принца. В такие моменты люди записывают видео и делают фотографии, заливают всё в «облако» и обмениваются ссылками. Всё это приводит к взрывному объему трафика, которые нужно уметь перенаправить в нужные точки.
Сетевые функции сжатия трафика в режиме реального времени (Real-Time Compression, WAN Optimization), перенаправления запросов на ближайшие точки (CDN), балансировка нагрузки между фермой серверов (Load Balancing) требуется развернуть в автоматическом режиме и в нужном масштабе и предоставить к определенному виду трафика. Определить данный тип трафика, запустить виртуальные машины с требуемой функцией и перенаправить в них трафик помогают системы MANO с функцией авто-провижининга, авто-скейлинга, автоматической настройкой перенаправления трафика.
MANO
Оркестраторы (management and operation) данного процесса должны уметь управлять целым набором компонентов:
1) Управления физической инфраструктурой: сеть, хранения данных, сервера;
2) Используя платформы виртуализации создать из физической инфраструктуры необходимые инстансы: виртуальные машины, виртуальные LUN, виртуальные сети;
3) Принимать телеметрию от текущих сетевых устройств для проведения аналитики и принятия решения о предоставлении дополнительных сетевых функций;
4) Запустить из шаблонов требуемые сетевые функции и загрузить в них конфигурацию, соответствующую требуемой задаче;
5) Анализировать «здоровье» запущенных сетевых функций для принятия оперативных решений в случае отказов, аварий либо перегрузкой;
6) Ликвидация запущенных сетевых функций в случае отпадения необходимости в их работе по автоматических данным из телеметрии либо по запросу администратора;
7) Передать в бизнес ИТ-системы информацию об используемых ресурсах для проведения расчетов биллинга.
Реализация данного функционала резко повысить время предоставления услуг от сервисных операторов к клиентам и потребителям. Сокращения времени выхода услуги на рынок повысить монетизацию инфраструктуры и приведет к дополнительной прибыли. Пользовательских опыт от более плавного и быстрого потребления контента улучшить эмоциональное восприятия потребителями сервиса, что в конечном итоге повысить привлекательность оператора связи как клиентоориентированных провайдеров.
Enterprise CPE virtualization
Изменение работы провайдеров с предоставления обычных каналов связи («трубы») к созданию набора услуг с добавленной стоимостью позволит продолжать предоставлять высокорентабельный сервис и в долгосрочной перспективе не приведет к снижению выручки за счет повышения конкуренции на рынке инфраструктурных провайдеров.
Еще одной возможностью для повышения прибыли для сервис-провайдеров является модель перехода к умным оконечным точкам (CPE). Переход от цифровых модемов к управляемым роутерам позволяет достичь несколько целей. В данный момент для подключения удаленного филиала заказчика услуг сервис-провайдера требуется устройство подключающее локальную сеть филиала к сети оператора в нужную выделенную сеть, организованную либо посредством технологии MPLS либо в случае legacy провайдеров посредством технологии ATM. В таком случае необходимость совершать различные операции с трафиком заказчика (предоставлять дополнительные сетевые функции) приводила к необходимости доставлять этот трафик от клиента до ядра сети оператора, в котором располагаются устройства, реализующие такую сетевую функцию и уже на ядре сети обрабатывать трафик по заданным политикам. Это приводило к повышенной утилизации «последней мили» и магистрали оператора тем трафиком, который можно было бы обработать ближе к источнику генерации. С другой стороны устройства оконечных точек являлись всего лишь либо аналогово-цифровыми преобразователями либо достаточно простыми IP-устройствам, без возможности проактивного мониторинга либо удаленной настройки.
Замена таких устройств на CPE нового поколения позволит решить несколько задач. Дистанционное управления новыми CPE позволит производить zero-touch provisioning с помощью двухфакторного метода используя активирующие URL. Таким образом можно будет напрямую с завода-производителя отправлять устройства конечным клиентам и уже на месте активировать их с нужной конфигурацией, в том числе неквалифицированным персоналом. Помимо этого, реализация на CPE с помощью слоя виртуализации контейнеров или виртуальных машин с нетребовательными к аппаратной платформе сетевыми функциями, позволяющими непосредственно на оконечной точке предоставлять услуги с добавленной стоимостью позволит клиентам в магазине приложений активировать для своей точки подключения тот функционал, который им требуется: антивирусная защита, фильтрация спама, родительский контроль и так далее. Оператор, взимая дополнительную плату за эти функции получить широкую возможность наращивать выручку за счет быстрого и бесшовного внедрения новых SDN-приложений.
Для корпоративных заказчиков оперативное развертывание новых офисов в точках присутствия Интернета станет реальностью – не потребуется перенастраивать множество IPSec VPN туннелей на новую адресацию, в том случае если CPE будет автоматически строить наложенные туннели посредством технологий VXLAN или MPLSoGRE между множеством CPE и центральным центром обработки данных. Централизованное управление удаленными офисами позволит оперативно менять программное обеспечение на CPE и хранить конфигурацию. Средства информационной безопасности можно будет активировать из единой консоли управления сразу для всей организации. Администратор ИБ по достоинству оценить отсутствие возможности сотрудников в филиале иметь доступ к консоли роутера, потому как политики будет настраивать только на SDN-контроллере либо оркестраторе.
Выводы
Используя упомянутые тренды – переход на централизованный control plane, замена специализированных устройств с сетевыми функциями на x86-сервера с программными NF, создание системы управления виртуальными ресурсами с передачей управляющих сигналов в различные компоненты системы OSSBSS, а также автоматизация и виртуализация устройств оконечных подключений приведет к повышению скорости вывода услуг на рынок, создаст экосистему для предоставления сервисов с высокой добавленной стоимостью и повысить привлекательно провайдера для конечных клиентов.
Автор: wider
