Руководство по SDN/NFV. Глава 11. Особенности архитектуры NFV (2).

Часть 2, Часть 1 – здесь.

11.2 Аспекты виртуализации и SDN

При виртуализации VNF, кроме прочего, стоит рассмотреть такие аспекты, как доступность (Availability), производительность (Performance), логическое разделение сетей (Network Separation), безопасность и целостность данных (Security & Integrity), а также возможность масштабирования (Scalability).

  • Доступность

Как и в случае физических сетевых функций PNF (Physical Network Functions), постоянная доступность VNF очень важна для виртуализированных приложений. Факторы, которые повышают доступность:

  • Устранение единых точек отказа системы (single points of failure)
  • Балансировка нагрузки, распределение внутренних ресурсов, которые использует VNF
  • Воспроизводимость сессий и переключение между сетевыми функциями при отказах
  • Географическая избыточность и возможность переключения работы VNF между разными дата-центрами.

Всё это необходимо принимать во внимание, если мы хотим обеспечить надёжность операторского класса, т.е. «пять девяток», 99,999% доступности системы, которая требуется в телекоммуникационных сетях.

Это может быть достигнуто за счёт использования нескольких экземпляров функций VNF, выполняющих одну и ту же задачу. Таким образом, отказ одного экземпляра VNF не повлечёт потерю всего сервиса. Для этого очень важна функция балансировки нагрузки для равномерного распределения трафика между параллельно работающими экземплярами VNF.

Причём, для механизма балансировки трафика очень важна способность детектировать отказы экземпляров VNF, и перенаправлять трафик на другие рабочие экземпляры. А для этого, необходима возможность перенос сессии на другой экземпляре VNF незаметно для конечного пользователя.

Кроме того, приложения, состоящие из наборов VNF, необходимо разворачивать в географически распределённых дата-центрах, чтобы исключить риск выхода из строя всего дата-центра. Обычно, географическая избыточность достигается наличием резервного, синхронно работающего, экземпляра приложения в другой географической локации. Для синхронизации работы приложений, основного и резервного, могут использоваться традиционные для IP-сетей средства балансировки нагрузки и службы доменных имён.

  • Производительность

В настоящее время большинство физических сетевых функций PNF исполняется на специализированном оборудовании, с выделенными каналами передачи и ресурсами исключительно под данную сетевую функцию. Когда эти приложения (сетевые функции) переносятся в облако, виртуальные сетевые функции VNF разворачиваются на многих серверах x86, составляющих сетевую инфраструктуру облака, которую используют совместно много приложений.

Поэтому, приложениям становится доступна такая роскошь, как выделенные аппаратные платформы. В результате, возникают новые архитектурные аспекты, которые нужно учитывать при виртуализации:

  • Установление низкой задержки между контроллерами сетевых функций VNFC при работе с VNF.
  • Использование облачных технологий (например, SD-WAN) для обеспечения высокой пропускной способности сети
  • Масштабирование вычислительной ёмкости с использованием различных механизмов.

Низкая задержка между контроллерами VNFC может быть достигнута при помощи ряда методов, таких как, набор специализированных правил для размещения виртуальных машин VM, т.н. «правила совместного существования VM» (affinity rules) и правила «правила раздельного существования VM» (anti-affinity rules).

Правила Affinity rules способствуют тому, что VM не размещаются в различных дата-центрах, даже если они работают в одной VNF. В этом случае, формируется обращение к системе с требованием разместить две или более VM на одном физическом узле. Такой подход применим в сценариях, когда для VM, с точки зрения производительности, лучше находиться на одном хосте, или при рабочих нагрузках, допускающих отказ одного физического узла, с возможностью миграции VM на альтернативную площадку.

Наоборот, правила Anti–affinity rules предусматривают, что две или более VM из одной VNF необходимо разместить в разных дата-центрах. Такой тип правил используется в случаях, когда требуется обеспечить резервирование и высокую доступность VNF.

Требуемый уровень производительности может быть достигнут при помощи программных технологий ускорения работы оборудования, таких как DPDK (Data Plane Development Kit, набор библиотек плоскости данных и драйверов контроллера сетевого интерфейса для быстрой обработки пакетов), а также SR-IOV (Single Root Input/Output Virtualization, виртуализация ввода-вывода с единым корнем). SR-IOV – это технология виртуализации устройств, позволяющая предоставить виртуальным машинам прямой доступ к части аппаратных возможностей устройства.

Кроме того, есть ряд методик оптимизации виртуального коммутатора на уровне оркестрации, для улучшения диспетчеризации выделения ресурсов оборудования.

Масштабирование VNF обычно может выполняться либо «вертикально» (“scale up”, выделение большего количества аппаратных ресурсов под виртуальную машину VM), либо «горизонтально» (“scale out” – выделение большего числа VM под VNF).

Scale up может быть использован для увелипчения процессорной мощности в пределах одной VM. При этом не нужно заботиться о репликации состояния VM. Однако, здесь не решается проблема дефицита сетевых ресурсов между разными VM, поэтому, несмотря на высокую вычислительную мощность одной VM, может возникнуть перегрузка на сетевых интерфейсах между разными VM.

Scale out может быть применён для добавления сетевых ресурсов, путём создания дополнительных VM на новых физических серверах, при наличии достаточной ёмкости сети. Однако, при этом требуется репликация состояния сессий на новой VM.

Scale out не требует репликации состояния или перевода сессии в новое состояние. Это зависит от имплементации обработки состояния и информации сессии различными вендорами.

  • Разделение сетей

В виртуализированном мире существует два аспекта разделения сетей, которые нужно принимать во внимание:

  • Multi-Tenancy (что можно примерно перевести как «многоарендность»
  • Разделение интерфейсов трафика внутри VNF

Multi-Tenancy означает, что одна VNF может занимать те же ресурсы: вычислений, сети и хранения, что и другая VNF. Для обеспечения должного уровня безопасности каждой VNF в облаке, облачная система должны поддерживать изоляцию VNF друг от друга. Кроме того, сетевые функции (как PNF, так и VNF) имеют нескольку логических сетевых интерфейсов, которые требуют изоляции друг от друга, либо по причинам безопасности, либо производительности (например, функция MME в сети LTE может иметь интерфейсы S1-MME, S11, Gom, S6a и др.) Разделение сети в каждом случае может быть достигнуто разными путями, в т.ч., использованием affinity rules, виртуальных сетевых карт vNIC, а также сетевыми технологиями, такими как VxLAN. Различные сетевые элементы могут требовать разные комбинации технологий для удовлетворения требованиям приложения.

  • Безопасность и целостность

Здесь будут обсуждаться только безопасность и целостность применительно к VNF. Безопасность инфраструктуры оркестрации будет рассмотрена позднее.

Различные меры безопасности NFV включают:

  • Безопасность пользователя VNF (пользователь в данном случае – инженер по поддержке)
  • Безопасность логического интерфейса
  • Усиление гостевой ОС
  • Функции СОРМ (Lawful Intercept)
  • Целостность пакета VNF

Безопасность пользователя VNF содержит политики и процедуры по управлению пользователями элемента EPC (Enhanced Packet Core). Она включает такие функции, как создание/удаление пользователей, управление паролями и иерархический доступ в группах.

Безопасность логических интерфейсов включает как безопасность самих логических интерфейсов, так и данных вокруг них. Это обычно делается при помощи комбинации списков контроля доступа ACL и протоколов безопасности, таких как IPSec, а также выполняется внешними средствами (файрволлами) сети.

Для облачной инфраструктуры особенно важно обеспечить необходимую изоляцию «арендаторов» (tenant) так, чтобы не возникало никаких уязвимостей в сетевых интерфейсах VNF. В виртуализированном мире с гипервизорами, VNF работает на компьютерных ресурсах x86 на которых развёрнута операционная система хоста (Host OS), гипервизор и сверху на них ставится гостевая операционная система (Guest OS), как показано на рисунке ниже.

1

Безопасность оборудования x86, хостовой операционной системы и гипервизора – зона ответственности инфраструктуры оркестрации. Однако, безопасность гостевой операционной системы виртуальной машины – это ответственность VNF, на которой она работает.

«Усиление» (Hardening) операционной системы включает устранение сервисов деактивации, которые не нужны VNF, а также использование таких протоколов безопасности, как SSH (Secure Shell, «безопасная оболочка»), где это возможно. Требования к усилению гостевой операционной системы на виртуальных машинах могут варьироваться у разных операторов.

Функции легального перехвата (Lawful Intercept) являются обязательными требованиями 3GPP, а также они детализируются регулированием разных стран. В России эти функции называются СОРМ, то есть, система оперативно-розыскных мероприятий, но её требования сильно отличаются от 3GPP.

Lawful Intercept предполагает посылку команд от соответствующего ведомства на соответствующие элементы EPC. Эти команды затем заставляют сетевые элементы копировать соответствующие сообщения трафика данных абонентов (user plane data) и направлять их на сервер Lawful Intercept.

Целостность пакета VNF, предполагает процесс обеспечения целостности компонентов VNF, от «образа» VM, до OVF (открытый стандарт для хранения и распространения виртуальных машин).

Методологии, используемые для обеспечения целостности этих пакетов могут включать, например, контрольные суммы или сертификаты X.509.

  • Интеграция с SDN

Наконец, для того чтобы автоматизировать виртуальные функции, после установки и запуска VNF может использоваться автоматическая конфигурация логических интерфейсов (S1-MME, S5, Gx, и пр.) с соседними узлами через сеть SDN.

***

Следующая глава : https://shalaginov.com/2019/04/13/5627

Advertisements

About Алексей Шалагинов

Независимый эксперт
Gallery | This entry was posted in Руководство по SDN/NFV, NFV, SDN and tagged , , , . Bookmark the permalink.

1 Response to Руководство по SDN/NFV. Глава 11. Особенности архитектуры NFV (2).

  1. Pingback: Руководство по SDN/NFV. Глава 12. Режимы развёртывания VNF (1). | Telecom & IT

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.