Операторы связи уже инвестируют средства в построение сетей 5G и начинают оценивать возможный вклад публичного облака в их успех.
Многие операторы связи уже имеют отношения с поставщиками услуг публичного облака. Операторы связи размещают в облаке свои корпоративные приложения и используют крупных облачных поставщиков для размещения своих сайтов и проектов разработки программного обеспечения. Теперь встает вопрос о возможной роли публичного облака в работе сетевых сервисов.
Операторы связи движутся по пути виртуализации и программно-определяемых сетей. Вместо специализированного аппаратного обеспечения они начали использовать программные решения на серверах общего назначения. Одновременно с этим операторы связи переходят на облачные технологии. Эта стратегия дает операторам связи телекоммуникационное облако, которое обладает эластичностью и масштабируемостью публичного облака, но расположено в главном и периферийных ЦОД, принадлежащих операторам.
Виртуализация стала важным шагом к облаку, позволив перенести все рабочие задачи на виртуальные машины, которые можно запускать практически где угодно. Можно ли перенести функции виртуальной сети (VNF) из телекоммуникационного облака в публичное облако?
Стратегические соображения
Во-первых, операторы связи должны учитывать стратегические запросы.
Операторы связи несут ответственность перед своими клиентами и регуляторами за обеспечение работы критической инфраструктуры даже в экстремальных условиях. Чтобы размещать функции в публичном облаке, им необходимы высокие показатели соглашений об уровне обслуживания (SLA) поставщиков облачных услуг.
В то же время операторы связи должны следить за расходами. Им нужен экономичный способ развертывания инфраструктуры 5G и расширения системы периферийных вычислений для новых сервисов. Чтобы гарантировать обслуживание, им потребуется облачная среда и полная автоматизация сети. Поставщики облачных услуг обладают квалификацией в области веб-сервисов, но они не готовы взять на себя ответственность за предоставление потребителям полного спектра услуг связи. Это означает возможность сотрудничества поставщиков облачных услуг с соответствующим опытом и операторов связи, имеющих опыт предоставления сетевых услуг.
Многие операторы связи уже используют публичное облако для своих систем поддержки бизнеса (BSS). Для этих систем задержка не критически важна, а публичное облако может помочь сократить расходы. Однако другие операторы связи предпочитают иметь полный контроль над любыми системами, связанными с биллингом и финансами. Они не будут переносить свои системы поддержки бизнеса в облако. Функции плоскости управления проще переместить в публичное облако, чем функции плоскости данных. При этом плоскость управления также тесно связана с потоком доходов. Некоторые операторы связи не готовы доверить ее публичному облаку.
Финансовые соображения
При переносе VNF в публичное облако также встает вопрос финансовой целесообразности. Публичное облако привлекательно тем, что его пользователи, в данном случае операторы связи, избавляются от необходимости инвестировать в собственное оборудование и инфраструктуру ЦОД. Вместо этого они платят за использование, замещая капитальные затраты операционными расходами. Однако операционные расходы могут оказаться слишком высокими. Поставщики облачных услуг взимают высокую плату за исходящий трафик, и функции VNF, работающие с данными, могут быстро стать очень дорогими.
Проекты миграции тоже представляют собой непростую и масштабную задачу. Функции VNF, архитектура которых предусматривает работу на серверах операторского класса, необходимо модифицировать, прежде чем их можно будет использовать на серверах публичного облака. Независимые поставщики программного обеспечения (ISV) и операторы связи могут столкнуться с необходимостью существенных инвестиций для обеспечения работы современных функций VNF в публичном облаке.
Технические соображения
Очень важно понять, какие функции VNF целесообразно использовать в публичном облаке.
Например, сети радиодоступа (RAN) имеют очень жесткие требования к времени задержки, и для них необходима обработка диапазона на узле сотовой сети или вблизи него. Существующая инфраструктура ЦОД крупных поставщиков облачных услуг недостаточно распределена, и поэтому ей будет сложно справиться с нагрузками сети RAN. Обычно поставщики облачных услуг присутствуют лишь в нескольких регионах страны. Развертывание периферийных систем на уровне небольших районов RAN вряд ли будет экономически целесообразным.
Нагрузка сетей RAN — это пример рабочей нагрузки, для которой подходят ускорители, такие как Intel® vRAN Dedicated Accelerator ACC100. Этот ускоритель позволяет процессору общего назначения выгружать задачи коррекции ошибок пересылки на выделенное аппаратное обеспечение. Это освобождает ядра процессора, помогая увеличить емкость канала. Аналогичным образом технология Intel® QuickAssist Technology (Intel® QAT) может использоваться для ускорения шлюза IPsec для интерфейса S1. Такие ускорители могут быть недоступны в публичном облаке, где важно единообразие аппаратного обеспечения.
Хотя VNF работают на серверах общего назначения, эти серверы хорошо настроены для телекоммуникационных протоколов. Серверы публичного облака вряд ли станут равноценной заменой серверам, которые операторы связи используют для сетевых рабочих нагрузок. Возможно даже, что их производительность будет недостаточной для некоторых функций VNF. Платформы публичного облака разработаны для рабочих нагрузок информационных технологий и не оптимизированы для обработки пакетов. Также они не предоставляют детализированные данные телеметрии сервера, которые необходимы операторам связи для тонкой настройки платформы и оптимизации производительности имеющихся функций VNF.
Мы создали модель размещения и сродства телекоммуникационных нагрузок, чтобы помочь операторам связи определить, какие сетевые функции будут работать в публичном облаке. Мы учли следующие факторы:
- Важность физического расположения для VNF с точки зрения пропускной способности и времени задержки. Публичное облако может не справиться с рабочими нагрузками, требующими высокой пропускной способности и низкого времени задержки.
- Требования к интеграции VNF. Функции услуг стационарной связи имеют меньше требований, чем функции мобильных сетей 3-го поколения (проект 3GPP). Внутри собственной архитектуры оператора связи проще добиться большего уровня интеграции.
- Требования безопасности для VNF. Сервер домашних абонентов (HSS), реестр данных о местоположении домашних узлов (HLR) и другие функции используют важные данные клиентов и абсолютно необходимы для работы сети. В публичном облаке сложнее защитить функции VNF и обеспечить соблюдение требований к суверенитету данных.
- Требования к производительности VNF. Например, функции плоскости данных имеют более высокие требования, чем сигнальные функции, и поэтому они плохо подходят для экземпляров в публичном облаке.
Мы дали каждому из этих факторов одинаковую оценку. Для некоторых операторов связи определенные факторы могут быть более приоритетными, чем другие. Возможны сценарии, когда предельные значения какого-то отдельного параметра делают обязательным размещение рабочей нагрузки в телекоммуникационном облаке. Например, узлы HSS/HLR располагаются в середине модели. Если безопасность имеет большой вес, оператор связи может решить оставить эти нагрузки в телекоммуникационном облаке по причинам безопасности.
Показанные справа функции VNF, в том числе виртуальные сети RAN (vRAN), виртуальная глубокая проверка пакетов (vDPI) и широкополосный сетевой шлюз (BNG), прекрасно подходят для телекоммуникационного облака. Их будет сложнее реализовать в публичном облаке. Программно-определяемые глобальные сети (SD-WAN), единые системы «коммуникации как услуга» (UCAAS) и универсальное оборудование для потребителей (uCPE) уже работают в публичном облаке.
Для функций из середины модели публичное облако может подходить лучше, если обеспечивается соблюдение требований к производительности, безопасности и интеграции.
Гибридная модель — это модель, в которой некоторые функции остаются в телекоммуникационном облаке, а некоторые переносятся в публичное облако. Ответственность за платформу будет распределена между оператором связи и поставщиком облачных услуг. В случае возникновения технических проблем или снижения комплексной производительности могут возникнуть сложности.
Мы ожидаем, что в этом году операторы связи продолжат диалог с поставщиками облачных услуг относительно совместной работы в сети. Не следует забывать, что когда публичные облака появились впервые, многие организации приняли их с беспокойством, а сейчас успешно их применяют. У индустрии телекоммуникаций уникальные требования к производительности и физическому расположению серверов, так что любые сомнения относительно сетевой нагрузки в публичном облаке вполне понятны и обоснованы. Однако в случае возникновения достаточного спроса среди операторов связи в будущем крупные поставщики облачных услуг смогут предоставлять тонко настроенные платформы и локальные ЦОД.
Периферийные вычисления
Периферия сети — это то место, где операторы связи и поставщики облачных услуг могут сотрудничать уже сейчас. Сети 5G снижают время задержки, повышают пропускную способность и открывают невероятные возможности связи для таких решений, как Интернет вещей. Периферийные вычисления помогают использовать все преимущества сетей 5G, избавившись от задержки и расходов на перенос в облако.
У периферийных решений поставщиков облачных услуг и операторов связи есть свои сильные стороны, однако никто из них не предлагает полного решения:
- У операторов связи имеется сетевое подключение и возможность размещать рабочие задачи в сети с гарантированной производительностью. У многих из них нет инфраструктуры периферийных вычислений, в том числе программного комплекса, разработка которого будет стоить очень дорого.
- У крупных поставщиков облачных услуг есть программный комплекс, с которым знакомы разработчики, но нет собственной сетевой инфраструктуры с высокой пропускной способностью и низкой задержкой в каждом районе каждого региона.
Крупные поставщики облачных услуг делают свой облачный комплекс доступным для операторов связи на выделенном аппаратном обеспечении или в виде программных платформ на OEM-серверах массовой категории. Это аппаратное обеспечение может располагаться в сетевых ЦОД оператора связи.
Благодаря этому операторы связи смогут предлагать клиентам облачные сервисы в своей сети. Разработчикам не потребуется изучать новый программный комплекс: они смогут использовать инфраструктуру публичного облака и сервисы, с которыми они уже знакомы. При этом будет достигаться преимущество низкой задержки, которую могут обеспечить только операторы связи.
Amazon Web Services Wavelength Zones — инфраструктурные решения, когда оператор связи размещает сервер Amazon Web Services в своем ЦОД. Amazon Web Services сотрудничает с Verizon в США, KDDI в Японии и SKT в Южной Корее. Microsoft Azure Edge Zones with Carrier — аналогичное предложение, которое использует компания AT&T в США. Google Anthos For Telecom — это пример программной платформы, упрощающей построение гибридных облачных сред на периферии сети.
Операторы связи могут использовать с такой инфраструктурой разные бизнес-модели. Они могут просто разместить облачный комплекс в сети для обслуживания существующей клиентской базы поставщика облачных услуг. Также операторы связи могут построить собственную инфраструктуру с сервисами платформ поставщиков облачных услуг или предложить разработчикам собственную модель «платформа как услуга».
Кроме того, операторы связи смогут реализовать пользовательские сервисы для облачного комплекса. Например, они могут лицензировать программное обеспечение для компьютерного зрения, запускать его на облачной платформе в сети и предлагать услуги на основе этого компьютерного зрения. Конечные заказчики не будут знать, какую платформу использует решение, а операторы связи смогут использовать преимущества богатой экосистемы готового программного обеспечения и разработчиков. Запуск программного обеспечения на периферии позволит внедрить новые быстрые модели работы, сохраняя для пользователей простоту модели «как услуга» публичного облака.
Когда операторы связи предлагают такие услуги, они берут на себя дополнительные обязательства согласно SLA. Облачный комплекс предлагается поставщиками облачных услуг с менее жесткими соглашениями об уровне обслуживания или вообще без SLA (когда поставщик не контролирует ЦОД, сетевые подключения и управление ЦОД). Операторы связи имеют большой опыт соблюдения строгих SLA, и поэтому новые обязательства будут для них не в новинку.
Со временем операторы связи могут решить начать работу с несколькими поставщиками облачных услуг, чтобы реализовать на периферии альтернативные облачные комплексы. Гибридное облако стало нормой для большинства компаний, и сегодня каждая организация использует в среднем 3,4 публичного облака (2,2 в производственной среде)1. Организации выбирают разные облачные комплексы для разных функций и приложений. Им будет проще перенести приложения на периферию сети, если им не нужно будет менять архитектуру для платформ разных поставщиков облачных услуг.
Если операторы связи размещают инфраструктуру публичного облака в собственном ЦОД, они могут использовать ее для собственных рабочих задач. Это упростит им переход на публичное облако в период высокого спроса. Для такого подхода может потребоваться разработка программного обеспечения в существенном объеме, и для этого в первую очередь потребуется провести тщательный анализ затрат.
Наличие идентичных аппаратных экземпляров облачной инфраструктуры в разных локациях сводит к минимуму затраты на миграцию и проверку приложений и поддержку гибридных облачных сред. Согласованное аппаратное обеспечение также упрощает работу в целом. Корпорация Intel предлагает не имеющий аналогов ассортимент аппаратного обеспечения, соответствующего уникальным требованиям облака и периферии. Мы также поддерживаем экосистему с открытым исходным кодом, включая Linux и Kubernetes, благодаря чему разработчики могут пользоваться этими инновациями.
Взгляд в будущее
В ближайшие несколько лет мы ожидаем более тесное сотрудничество между операторами связи и поставщиками облачных услуг. Облачные платформы могут стать более производительными для соответствия высоким требованиям сетевых нагрузок. Поставщики облачных услуг и операторы связи вместе будут поддерживать рост сферы периферийных вычислений, чтобы обеспечить клиентам скорость, пропускную способность и повсеместные возможности связи в сетях 5G.
Подробнее
- Модель размещения и сродства телекоммуникационных рабочих нагрузок
- Использование серверной телеметрии для ускорения управления телекоммуникационными сетями
Благодарность
Митч Кояма (Mitch Koyama), Джей Винсент (Jay Vincent) и Пол Мэннион (Paul Mannion) из корпорации Intel; а также Анит Лохтия (Anit Lohtia) и Роуленд Шоу (Rowland Shaw) из компании Dell поделились своими идеями для этого блога. Спасибо! Эслам Кандиель (Eslam Kandiel) и Ахмед Ибрагим (Ahmed Ibrahim) работали над статьей «Модель сродства и размещения телекоммуникационных нагрузок» совместно с Петаром Торре.