Доклад на тему: "Надёжность и доступность VNF"

В традиционных, не-виртуализированных сетях сетевые элементы, оборудование и ПО объединены в блоке физического оборудования, который поставляет один вендор. При виртуализации, оборудование и ПО приобретаются от различных поставщиков. Различные компоненты VNF, располагающиеся на разных аппаратных серверах, соединяются через сеть ещё одного вендора.В этой модели, оператору необходимо обеспечить полную совместимость всех компонентов и требуемые параметры работы системы.Разделение оборудования и ПО значительно усложняет эту задачу для оператора. Может создаться впечатление, что виртуализация имеет негативное влияние на надёжность. Однако, на самом деле, это не так. Автоматизация всего рабочего цикла, быстрое восстановление сервисов в случае отказа может значительно повысить надёжность.Отрасль должна пройти через фазу обучения, когда операторы и вендоры должны работать вместе, чтобы понять взаимозависимость и взаимодействие между различными частями системы.В рамках данного доклада будут рассмотрены основные аспекты VNF, понятие, назначение. Также будут выявлены основные факторы, влияющие на надежность и доступность VNF, формализован структурированный процесс обеспечения надёжности VNF.1. Понятие виртуализации сетевых функцийВиртуализация сетевых функций (также виртуализация сетевых функций или NFV ) - это концепция сетевой архитектуры, которая использует технологии ИТ- виртуализации для виртуализации целых классов функций сетевых узлов в строительные блоки, которые могут соединяться или объединяться в цепочки для создания коммуникационных сервисов [1].NFV опирается на традиционные методы виртуализации серверов, например, используемые в корпоративных ИТ, но отличается от них. Виртуализированная сетевая функция, или VNF, может состоять из одной или нескольких виртуальных машин или контейнеров, на которых запущено различное программное обеспечение и процессы, поверх стандартных серверов большого объема, коммутаторов и устройств хранения, или даже инфраструктуры облачных вычислений , вместо наличия специализированных аппаратных устройств. для каждой сетевой функции. Например, пограничный контроллер виртуального сеанса может быть развернут для защиты сети без обычных затрат и сложности, связанных с получением и установкой физических модулей защиты сети. Другие примеры NFV включают виртуализированные балансировщики нагрузки, межсетевые экраны, устройства обнаружения вторжений и ускорители WAN.В октябре 2012 года группа операторов связи опубликовала белую бумагу на конференции в Дармштадте, Германия, на программное обеспечение определенных сетей (SDN) и OpenFlow. Призыв к действию, завершающий Белую книгу, привел к созданию Группы отраслевых спецификаций (ISG) виртуализации сетевых функций (NFV) в Европейском институте стандартов электросвязи (ETSI). В состав ISG вошли представители телекоммуникационной отрасли из Европы и других стран. С момента публикации white paper группа выпустила более 100 публикаций. В 2016 году выпущена одна высокопроизводительная версия NFV с открытым исходным кодом. openNetVM - это высокопроизводительная платформа NFV, основанная на контейнерах DPDK и Docker. Структура NFV состоит из трех основных компонентов [1]: - Виртуализированные сетевые функции (VNF) - это программные реализации сетевых функций, которые могут быть развернуты в инфраструктуре виртуализации сетевых функций (NFVI). - Инфраструктура виртуализации сетевых функций (NFVI) - это совокупность всех аппаратных и программных компонентов, которые создают среду, в которой развертываются NFV. Инфраструктура NFV может охватывать несколько мест. Сеть, обеспечивающая связь между этими местами, считается частью инфраструктуры NFV. - Архитектурная структура управления виртуализацией и оркестровкой сетевых функций (NFV-MANO Architectural Framework) - это совокупность всех функциональных блоков, репозиториев данных, используемых этими блоками, а также эталонных точек и интерфейсов, через которые эти функциональные блоки обмениваются информацией с целью управления и координации NFVI. и VNF. Строительным блоком как для NFVI, так и для NFV-MANO является платформа NFV. В роли NFVI он состоит из виртуальных и физических ресурсов обработки и хранения, а также программного обеспечения для виртуализации. В своей роли NFV-MANO он состоит из менеджеров VNF и NFVI и программного обеспечения виртуализации, работающих на аппаратном контроллере. Платформа NFV реализует функции операторского уровня, используемые для управления и мониторинга компонентов платформы, восстановления после сбоев и обеспечения эффективной безопасности - все, что требуется для общедоступной операторской сети [3]. При проектировании и разработке программного обеспечения, которое предоставляет VNF, поставщики могут структурировать это программное обеспечение в программные компоненты (представление реализации архитектуры программного обеспечения) и упаковать эти компоненты в один или несколько образов (представление развертывания архитектуры программного обеспечения). Эти программные компоненты, определяемые производителем, называются компонентами VNF (VNFC). VNF реализованы с помощью одного или нескольких VNFC, и без потери общности предполагается, что экземпляры VNFC сопоставляют 1: 1 с образами виртуальных машин. В целом VNFC должны иметь возможность увеличивать и / или масштабировать. Имея возможность выделять гибкие (виртуальные) ЦП каждому из экземпляров VNFC, уровень управления сетью может масштабировать (т. е. вертикально) масштабировать VNFC, чтобы обеспечить ожидаемую пропускную способность / производительность и масштабируемость в рамках одной системы или одной платформы. Точно так же уровень управления сетью может масштабировать (т. е. масштабировать по горизонтали) VNFC, активируя несколько экземпляров такого VNFC на нескольких платформах, и, следовательно, достигать характеристик производительности и архитектуры, не подвергая риску стабильность других функций VNFC. Ранние последователи таких архитектурных чертежей уже реализовали принципы модульности NFV. NFV оказался популярным стандартом даже в младенчестве. Его непосредственные приложения многочисленны, такие как виртуализация мобильных базовых станций, платформа как услуга (PaaS), сети доставки контента (CDN), фиксированный доступ и домашние среды. Ожидается, что потенциальные выгоды от NFV будут значительными. Ожидается, что виртуализация сетевых функций, развернутых на стандартизированном оборудовании общего назначения, сократит капитальные и эксплуатационные расходы, а также время внедрения услуг и продуктов. Многие крупные поставщики сетевого оборудования заявили о поддержке NFV. Это совпало с объявлениями NFV от основных поставщиков программного обеспечения, которые предоставляют платформы NFV, используемые поставщиками оборудования для создания своих продуктов NFV. Однако для реализации ожидаемых преимуществ виртуализации поставщики сетевого оборудования улучшают технологию ИТ-виртуализации, чтобы включить в нее атрибуты операторского уровня, необходимые для достижения высокой доступности, масштабируемости, производительности и эффективных возможностей управления сетью. Чтобы свести к минимуму совокупную стоимость владения (TCO), функции операторского класса должны быть реализованы как можно более эффективно. Это требует, чтобы решения NFV эффективно использовали избыточные ресурсы для достижения доступности пяти девяток (99,999%) и вычислительных ресурсов без ущерба для предсказуемости производительности. Рабочая группа ISG выдвинула три основных критерия, которые должны быть реализованы в стандартах (рекомендациях) для NFV [4]:Отделение (Decoupling): полное разделение оборудования и программного обеспечения.Гибкость (Flexibility): автоматизированное и масштабируемое развёртывание сетевых функцийДинамические операции (Dynamic operations): контроль за операционными параметрами сети при помощи точного (гранулярного) управления и мониторинга состояния сети.На основе этих критериев была разработана обобщённая архитектура NFV, показанная на рисунке 1 [4].Рисунок 1. Обобщённая архитектура NFV (Источник: ETSI, TAdviser).Платформа NFV является основой для создания эффективных решений NFV операторского уровня. Это программная платформа, работающая на стандартном многоядерном оборудовании и построенная с использованием программного обеспечения с открытым исходным кодом, которое включает функции операторского уровня. Программное обеспечение платформы NFV отвечает за динамическое переназначение VNF из-за сбоев и изменений нагрузки трафика и, следовательно, играет важную роль в достижении высокой доступности. В настоящее время реализуется множество инициатив по определению, согласованию и продвижению возможностей NFV операторского уровня, таких как ETSI NFV Proof of Concept, открытая платформа ATIS для проекта NFV, награды Carrier Network Virtualization Awards и различные экосистемы поставщиков. VSwitch, ключевой компонент платформ NFV, отвечает за обеспечение связи как между виртуальными машинами (между виртуальными машинами), так и между виртуальными машинами и внешней сетью. Его производительность определяет как полосу пропускания VNF, так и рентабельность решений NFV. Стандартная производительность Open vSwitch (OVS) имеет недостатки, которые необходимо устранить, чтобы удовлетворить потребности решений NFVI. Поставщики NFV сообщают о значительных улучшениях производительности для версий OVS и Accelerated Open vSwitch (AVS). Виртуализация также меняет способ определения, измерения и достижения доступности в решениях NFV. По мере того, как VNF заменяют традиционное специализированное оборудование, происходит переход от доступности на основе оборудования к основанному на услугах, сквозному, многоуровневому подходу. Виртуализация сетевых функций нарушает явную связь с конкретным оборудованием, поэтому доступность определяется доступностью служб VNF. Поскольку технология NFV может виртуализировать широкий спектр типов сетевых функций, каждый со своими собственными ожиданиями доступности услуг, платформы NFV должны поддерживать широкий спектр вариантов отказоустойчивости. Эта гибкость позволяет CSP оптимизировать свои решения NFV для удовлетворения любых требований к доступности VNF.2. Факторы, влияющие на надежность и доступность VNFРассмотрим типичный сценарий отказа, который, тем не менее, является лишь одним из множества возможных его реализаций.Каждый компонент VNFC обычно имеет резервирование (Redundancy) 1+1. Это означает, что во время установки VNF, создаются две копии компонента VNFC, активная и резервная. Эти два экземпляра VNFC либо могут иметь доступ к общей базе данных, где хранится информация о состоянии; либо активный экземпляр VNFC может изменять состояние резервного VNFC, в случае изменения состояния. В любом случае, резервный экземпляр VNFC в любой момент времени готов продолжать работу, в случае отказа активного экземпляра [1].Для проверки на отказ, обычно используется одна из форм проверки работоспособности между двумя VNFC. Например, если требуется очень быстрое обнаружение отказа, два VNFC могут посылать друг другу сообщения о работоспособности каждые 10 мс. Когда резервный VNFC не получает подтверждение работоспособности своего активного товарища, он решает, что тот отказал, и после этого сам становится активным. В этом случае сервис восстанавливается в течение не более 50 мс после отказа.Однако, после этого ставший активным VNFC оказывается незащищённым. Поэтому необходимо как можно скорее создать новый экземпляр VNFC, который теперь будет резервным. Его созданием ведает VNFM, который получает сигнал об отказе VNFC, либо от нового активного VNFC; либо от VIM, который может обнаружить отказ сервера, на котором работал отказавший VNFC; либо от других элементов, которые могут обнаруживать отказ.В результате, VNFM взаимодействует с VIM, чтобы создать новый экземпляр VNFC.Рассмотрим непосредственно факторы, влияющие на надёжность и доступность:- Отказы сервера и гипервизораОтказы сервера и гипервизора вызывают недоступность VNF. Однако, основной причиной недоступности VNF часто бывает не первоначальный отказ, а отказ последующей за ним процедуры переключения на резерв. Переключения между серверами обычно происходят за секунды и не очень влияют общую недоступность, но отказ во время переключения даёт гораздо большую задержку доступности, и обычно требует ручного восстановления. Поэтому, надёжность физической инфраструктуры – это критическая часть надёжности NFV.- Отказы сетиОтказы сети влияют на связность между VNFC одной VNF, или между одной VNF и другой VNF. Поэтому, сетевые соединения между серверами также резервируют, и отказы сети не оказывают большого влияния на общую отказоустойчивость, чем отказы серверов. Однако, надёжность сети – второй по значимости фактор.- Надёжность кода VNFНадёжность кода VNF – третий важный фактор надёжности NFV. ПО VNF может содержать баги, которые могут вызвать недоступность VNF.- Системы управленияВосстановлением отказавшего VNFC занимаются VNFM и VIM. VNFM инициирует создание или восстановление отказавшего VNFC. VIM затем выполняет эти действия. Если VNFM или VIM недоступны, то восстановление произвести не удаётся, и как следствие VNF временно не будет иметь требуемого уровня защиты.Например, если какой-то VNFC имеет защиту 1+1, то отказ одного из VNFC оставит VNF в незащищённом состоянии. Последующий отказ второго VNFC может привести к недоступности VNF. Поэтому доступность VNFM и VIM очень важны для общей надёжности NFV.- Скорость восстановления VNFCИз изложенного ясно, что чем скорее отказавший VNFC будет восстановлен, тем меньше времени VNF проведёт в незащищённом состоянии. Если даже VNFM и VIM доступны, то вся процедура обнаружения отказа, выделения нового сервера, создания там виртуальной машины, загрузка и запуск образа VNFC, и прочие операции, может занять довольно значительное время.В невиртуализированных сетях, однако, могут пройти часы, прежде чем удаётся найти и заменить отказавший модуль в каком-либо оборудовании. В NFV полное восстановление VNFC – дело нескольких минут, или меньше. На надёжность NFV это оказывает небольшое влияние.- Задержки между VNFCЧтобы запустить переключение на резервный VNFC, ему необходимо обнаружить отказ активного VNFC. В основном, такая проверка выполняется при помощи периодической посылки сообщений о работоспособности. Время обнаружения отказа зависит от частоты посылки таких сообщений, но также и от задержки передачи их между VNFC. Чем больше задержка, тем выше процент недоступности. Конечно, задержка не превышает нескольких миллисекунд, поэтому на общую надёжность NFV она влияет незначительно.- Отказ доменаВ NFV, несколько VNFC, принадлежащие разным VNF, могут находиться в одном «домене отказа», т.е. может быть группа VNFC, которая подверглась влиянию одного отказа. Такой фактор влияния на общую надёжность в невиртуализированном мире отсутствует. Например, в традиционных сетях, вероятность двойного одновременного отказа чрезвычайно мала [2].В виртуализированном мире, вероятность того, что несколько VNF одновременное выполняют процедуру резервного переключения, не так уж мала. Это может привести к нестабильности и повысить недоступность.В дата-центре, если отказ случается самое большее в одном сервере, то на общую надёжность это оказывает небольшое влияние, поскольку в нем работает не так много VNFC, которые имеют резервные копии на других серверах. Однако, если отказ затронет целую стойку серверов, то ситуация усложняется. Вполне вероятно, что резервные копии работают на разных серверах в разных стойках, но одновременное выполнение десятков или сотен процедур переключения значительно повышает вероятность последующих отказов, и может вызвать полную недоступность VNF.3. Структурированный процесс обеспечения надёжностиВ практике операторов, лучше придерживаться структурированного подхода для обеспечения надёжности NFV. Процесс может быть, например, таким:1) Оценка работоспособности инфраструктуры.- Ожидаемый процент отказов серверов и гипервизоров?- Ожидаемый процент отказов сети?- Ожидаемая задержка в полностью нагруженной инфраструктуре?- Есть ли отказы, которые могут затронуть более чем один север в данным момент времени?2) Оценка и тестирование надёжности критичных систем управления- Ожидаемая доступность VNFM, VIM и контроллеров SDNНа основе этих данных можно выбрать требуемую степень резервирования VNFC, VNF серверов и сетевых соединений [5].На рисунке 2 представлена обобщённая структура SDN/NFV.Рис. 2. Обобщенная архитектура SDN/NFVВ контексте данной работы нас интересуют только два блока:- Функция обеспечения надежности услуг SA (Service Assurance), которая собирает предупреждающие сообщения и мониторит данные. Приложения внутри SA, или работающие с SA, могут использовать эти данные для корреляции ошибок, анализа исходных причин событий, анализа воздействия услуг, администрирования SLA, мониторинга безопасности и аналитики, и пр. - OSS/BSS, системы управления операциями и бизнес-процессами (Operations Support Systems and Business Support Systems), также унаследованные от традиционной архитектуры сети оператора. OSS/BSS заказывают необходимые функций, обеспечивают работу и надежность услуг, биллинг, формирование тикетов об ошибках, взаимодействие с персоналом техподдержки и выполняют другие функции для операционных и бизнес-процессов сети оператора.Остальные структурные элементы в рамках данного доклада рассмотрены не будут.ЗаключениеВиртуализация сетевых функций (NFV) приносит в мир сетей эффективность, экономию затрат и гибкость таким же образом, как технологии виртуализации и облачных вычислений преобразовали мир корпоративных серверов. Но для телекоммуникационных компаний надежность и доступность не подлежат обсуждению. В телекоммуникационной отрасли доступность является эталоном: Репутация телекоммуникационного оператора зависит от его способности надежно соединять звонки и передавать данные. Если сеть выйдет из строя, даже на несколько секунд, это может затронуть миллионы людей. Сбой системы не только приводит к потере дохода оператора, но и может серьезно повредить его репутации, а в некоторых случаях на кону могут оказаться и жизни людей. В связи с этим обеспечение доступности и надежности VNF является необходимым условием адекватного и полноценного функционирования подобных систем.В рамках данной работы были рассмотрены основные аспекты VNF, понятие, назначение. Были выявлены основные факторы, влияющие на надежность и доступность VNF, а также формализован структурированный процесс обеспечения надёжности VNF.Список используемых источников1. Network Functions Virtualization / ETSI [Электронный ресурс], URL: https://www.etsi.org/images/files/ETSITechnologyLeaflets/NetworkFunctionsVirtualization.pdf (дата обращения 12.12.2020)2. Александр Бриткин NFV и пример ее применения для оператора связи, «Журнал сетевых решений/LAN», № 10, 20143. Смелянский Р.Л. Технологии SDN и NFV: новые возможности для телекоммуникаций// Вестник связи. 2014. № 1. С. 43 — 47.4. GS NFV 002 - V1.1.1 - Network Functions Virtualisation (NFV); Architectural Framework [Электронный ресурс], URL: https://www.etsi.org/deliver/etsi_gs/nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf (дата обращения 12.12.2020)5. Шувалов В.П., Егунов М.М., Минина Е.А.. Обеспечение показателей надежности телекоммуникационных систем и сетей. — М.: Горячая линия — Телеком. 2015. 168 с.6. Соколов Н.А. Задачи планирования сетей электросвязи. — СПб: Техника связи. 2012. 432 с.