Основные понятия для Диспетчера служб оператора Azure

В этой статье описаны рекомендации по подключению и развертыванию сетевых функций (NFS) с помощью Диспетчера служб Оператора Azure. Следуя этим основным рекомендациям, поставщикам, операторам и их партнерам, можно оптимизировать сетевые службы, развернутые в Операторе Azure Nexus. Рассмотрите эти концепции в начале любого процесса интеграции сетевой функции.

Общие рекомендации

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

• Структурируйте артефакты в соответствии с запланированным использованием. Рассмотрите возможность разделения глобального артефакта от тех, которые должны отличаться по сайту или экземпляру.
• Убедитесь, что композиция сервисов с несколькими NF и набором параметров соответствует потребностям вашей сети. Например, можно настроить 100 значений на диаграмме с 1000 значениями. Убедитесь, что на уровне схемы группы конфигурации (CGS) (более подробно описано в следующих разделах), вы отображаете только 100.
• На ранней стадии задумайтесь о том, как вы хотите отделять инфраструктуру (например, кластеры) или хранилища артефактов и разделять доступ между поставщиками, в частности в рамках одной и той же услуги. Сделайте набор ресурсов издателя соответствующими этой модели.
• Сайт Service Manager оператора Azure — это логическая концепция, представление назначения развертывания. Например, кластер Kubernetes для контейнерных сетевых функций (CNF) или расширенная настраиваемая конфигурация Azure Operator Nexus для виртуализированных сетевых функций (VNF). Это не физическое представление пограничного узла, поэтому у вас есть случаи, когда несколько узлов разделяют одно физическое расположение.
• Диспетчер служб оператора Azure предоставляет различные API, которые помогают объединить их с Azure DevOps или другими средствами конвейера.
• Расширение интерфейса командной строки (CLI) оператора Azure позволяет публиковать определения сетевых функций (NFD) и NSD. Используйте это средство в качестве отправной точки для создания новых NFD и NSD. Рекомендуется использовать интерфейс командной строки для создания исходных файлов. Затем измените их, чтобы включить компоненты инфраструктуры перед публикацией.

Соображения для издателя

• Рекомендуется создать одного паблишера для каждого поставщика NF или для каждого типа NF у поставщика, если поставщик может предоставить несколько типов NF. Эта практика;
  • Обеспечивает наиболее оптимальную поддержку, обслуживание и управление, предотвращая распространение издателей. Особенно во время действий обновления, когда одно и то же действие часто выполняется во многих NFS.
  • Снижает общую операционную стоимость, уменьшая количество ресурсов резервного копирования издателей, таких как реестр контейнеров Azure (ACR) или учетные записи хранения.
  • Упрощает структуру сетевой службы (NSD), где она может состоять из нескольких NFS от нескольких поставщиков.
• После тестирования и утверждения требуемого набора ресурсов издателя Azure Operator Service Manager для использования в производственной среде рекомендуется пометить весь набор как неизменяемый. Поме́тив набор как неизменяемый, вы предотвраща́ете случайные изменения и обеспечиваете согласованный опыт развертывания. Неизменяемость пометок помогает различать:
  • Ресурсы и артефакты, используемые в рабочей среде
  • Ресурсы и артефакты, используемые для тестирования и разработки

Вы можете запросить состояние ресурсов издателя и манифестов артефактов, чтобы определить, какие из них помечены как неизменяемые. Дополнительные сведения см. в разделе "Управление предварительным просмотром ресурсов издателя".

Имейте в виду следующую логику:

• Если версия проектирования сетевой службы (NSDV) помечена как неизменяемая, CGS также должна быть помечена как неизменяемая. В противном случае вызов развертывания завершается ошибкой.
• Если версия определения сетевой функции (NFDV) помечена как неизменяемая, манифест артефакта также должен быть помечен как неизменяемый. В противном случае вызов развертывания завершается ошибкой.
• Если только манифест артефакта или CGS помечены как неизменяемые, вызов развертывания завершается успешно, независимо от того, помечены ли NFDV и NSDV как неизменяемые.
• Маркировка манифеста артефакта как неизменяемая гарантирует, что все артефакты, перечисленные в этом манифесте, также помечены как неизменяемые путем применения необходимых разрешений в хранилище артефактов. Перечисленные артефакты обычно включают диаграммы, изображения и шаблоны Azure Resource Manager (шаблоны ARM).
• Рекомендуется использовать согласованные соглашения об именовании и методы управления, чтобы помочь устранить все оставшиеся пробелы.

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

Издатель службы управления оператором Azure — это региональная служба, развернутая в локальных зонах доступности исключительно в поддерживаемых регионах. Рассмотрите следующие требования к высокой доступности издателя и аварийному восстановлению:

• Чтобы обеспечить геоизбыточность, убедитесь, что у вас есть издатель в каждом регионе, где планируется развернуть NFS. Рассмотрите возможность использования конвейеров для хранения артефактов и ресурсов издателя в синхронизации между регионами.
• Имя издателя должно быть уникальным для каждого клиента Microsoft Entra в каждом регионе.

Рекомендации по NFDG и NFDV

Группа определений сетевых функций (NFDG) представляет наименьший компонент, который планируется повторно использовать независимо между несколькими службами. Все части NFDG всегда развертываются вместе. Эти части называются networkFunctionApplications элементами. Например, это естественно для подключения одного NF, состоящего из нескольких диаграмм Helm и изображений в виде одного NFDG, если всегда развертывать эти компоненты вместе. В случаях, когда несколько NFS всегда развертываются вместе, разумно иметь один NFDG для всех них. У отдельных NFDG может быть несколько NFDV.

• Для CNF NFDV networkFunctionApplications список может содержать только пакеты Helm.
  • Имеет смысл включать несколько пакетов Helm, если они всегда развертываются и удаляются вместе.
• Для VNF NFDV networkFunctionApplications список должен содержать по крайней мере одно значение и один ARM-шаблон.
  • Чтобы развернуть несколько виртуальных машин (VMs) для одной виртуальной сетевой функции (VNF), обязательно используйте отдельный шаблон ARM для каждой виртуальной машины.

Шаблон ARM может развертывать только ресурсы Resource Manager из следующих поставщиков ресурсов:

• Microsoft.Compute
• Microsoft.Network
• Microsoft.NetworkCloud
• Microsoft.Storage
• Microsoft.NetworkFabric
• Microsoft.Authorization
• Microsoft.ManagedIdentity

Для шаблонов ARM, содержащих что-либо за пределами предыдущего списка, все PUT вызовы VNF приводят к ошибке проверки.

Дополнительные или крупные обновления NFDV

NFDV представляет выпуск базовой версии NFDG и связан с определенной версией. По мере изменения NF со временем много NFDV используются для фиксации возможностей в любой момент времени. Типичные изменения, которые активируют новый NFDV, могут включать:

• Обновление артефактов NF, таких как новые диаграммы или версии изображений.
• Обновление CGS или значений конфигурационных групп (CGV), которые могут изменяться deployParametersMappingRuleProfile.
• Обновление всех значений по умолчанию, закодированных в NFDV.
• Обновление активации компонентов для предотвращения их развертывания с помощью applicationEnablement: Disabled.

Рекомендации по NSDG и NSDV

Группа разработки сетевых служб (NSDG) — это составная часть одного или нескольких NFDG и всех компонентов инфраструктуры, развернутых одновременно. Эти компоненты могут включать кластеры и виртуальные машины в Nexus Kubernetes или Службе Azure Kubernetes (AKS). Сетевой сервис сайта (SNS) соответствует одному NSDV. Такой дизайн обеспечивает согласованное и повторяемое развертывание сетевой службы для сайта с помощью одного вызова SNS PUT.

Пример NSDG может состоять из следующих элементов:

• Функция сервера проверки подлинности (AUSF) NF
• Унифицированное управление данными (UDM) NF
• Виртуальная машина администратора, поддерживающая AUSF или UDM
• Функция управления сессией Unity Cloud (SMF) NF
• Кластер Nexus Kubernetes, в котором развертываются AUSF, UDM и SMF

Эти пять компонентов формируют единое NSDG. Один NSDG может иметь несколько NSDV.

Дополнительное или основное обновление NSDV

NSDV представляет выпуск базового NSD и ассоциирован с уникальной версией. Изменения NSDV менее часты, чем изменения NFDV, и в некоторых случаях один NSDV поддерживает весь жизненный цикл сетевой службы сайта. Однако для следующих изменений службы требуется новый NSDV:

• Создание, удаление или добавление значений в CGS.
• Изменение шаблона NF ARM, используемого развернутым ресурсом сетевой службы сайта.
• Изменение шаблона ARM инфраструктуры, используемого ресурсом сайта развертывания.

Соображения по SNS

Рекомендуется использовать один SNS для всего сайта, включая инфраструктуру. SNS должен развернуть любую необходимую инфраструктуру (например, кластеры и виртуальные машины в Nexus Kubernetes или AKS), а затем развернуть необходимые сетевые функции поверх. Такой дизайн обеспечивает согласованное и повторяемое развертывание сетевой службы для сайта с помощью одного вызова SNS PUT.

Рекомендуется развернуть все SNS с управляемым удостоверением, назначаемое пользователем, а не назначаемое системой управляемое удостоверение. Эта управляемая идентичность, назначенная пользователем, должна иметь разрешения на доступ к NFDV и роль оператора управляемой идентичности в отношении себя. Дополнительные сведения см. в статье "Создание и назначение управляемой идентификации, назначенной пользователем".

Рекомендации по схеме ресурсов

В следующих двух сценариях показано сопоставление ресурсов в Azure Operator Service Manager.

Сценарий: отдельная сетевая функция

NF с одним или двумя компонентами приложения развертывается в кластере Nexus Kubernetes. Ниже приведена разбивка ресурсов:

• NFDG: если компоненты можно использовать независимо, два NFDG, по одному на каждый компонент. Если компоненты всегда развертываются вместе, то достаточно одного NFDG.
• NFDV: по мере необходимости в зависимости от вариантов использования, которые активируют обновления дополнительных или основных версий NFDV.
• NSDG: single. Объединяет NFS и определения кластера Kubernetes.
• NSDV: по мере необходимости в зависимости от вариантов использования, которые активируют обновления дополнительных или основных версий NSDV.
• CGS: одиночный. Для упрощения управления рекомендуется использовать подразделы CGS для каждого компонента и инфраструктуры, развернутой вами. Мы также рекомендуем, чтобы CGS включали версии для NFD.
• CGV: одиночный на основе количества CGSS.
• SNS: один на NSDV.

Сценарий: несколько сетевых функций

Несколько NFs с некоторыми общими и независимыми компонентами развертываются в кластере Nexus Kubernetes. Ниже приведена разбивка ресурсов:

• NFDG:
  • Единый для всех общих компонентов.
  • Один для каждого независимого компонента или NF.
• NFDV: несколько для каждого варианта использования NFDG, который вызывает обновления минорной или мажорной версии NFDV.
• NSDG: single. Объединяет все NFs, общие и независимые компоненты и инфраструктуру (кластер Kubernetes или любые вспомогательные виртуальные машины).
• NSDV: по мере необходимости в зависимости от вариантов использования, которые активируют обновления дополнительных или основных версий NSDV.
• CGS:
  • Холост/не замужем. Глобальный для всех компонентов.
  • Один на NF, включая версию NFD.
  • В зависимости от общего количества параметров рассмотрите возможность объединения всех CGS в единую CGS.
• CGV: равно числу CGS.
• SNS: один на NSDV.

Моменты, которые следует учитывать при обновлении

При условии, что NF поддерживают обновления на месте и во время эксплуатации, для CNF применяются следующие соображения.

• При добавлении новых диаграмм и изображений диспетчер служб Azure устанавливает новые диаграммы.
• Если удалить некоторые диаграммы и изображения, диспетчер служб Azure удаляет диаграммы, которые больше не объявлены в NFDV.
• Диспетчер служб Оператора Azure проверяет, что NFDV/NSDV возникла из того же NFDG/NSDG и, следовательно, того же издателя. Обновления между издателями не поддерживаются.

Следующие рекомендации относятся к виртуальным сетевым функциям.

• В настоящее время обновления на месте не поддерживаются. Необходимо создать экземпляр виртуальной виртуальной машины с обновленным изображением рядом. Затем удалите старую виртуальную виртуальную сеть, удалив SNS.
• Если ВНФ развертывается как пара виртуальных машин для высокой доступности, можно создать сетевую службу таким образом, чтобы можно было удалять и обновлять виртуальные машины по одной. Мы рекомендуем использовать следующую структуру, чтобы разрешить удаление и обновление отдельных виртуальных машин:
  • Разверните каждую виртуальную машину с помощью выделенного шаблона ARM.
  • В шаблоне ARM необходимо предоставить два параметра с помощью CGS:
    • Имя виртуальной машины, чтобы указать, какой экземпляр является основным или вторичным.
    • Политика развертывания, чтобы контролировать, разрешено ли развертывание виртуальной машины или нет
  • В NFDV необходимо параметризовать deployParameters и templateParameters таким образом, чтобы вы могли снабжать их уникальными значениями с помощью CGV-ов для каждого.

Рекомендации по устранению неисправностей

Во время установки и обновления по умолчанию:

• Опции atomic и wait установлены на true.
• Для времени ожидания операции задано 27 minutesзначение .

Во время процесса начальной настройки, только при отладке и разработке компонентов, рекомендуется установить для флага atomic значение false. Этот параметр предотвращает откат Helm при сбое и сохраняет любые журналы и ошибки, которые в противном случае могут быть потеряны. Оптимальный способ достижения этой цели — использование шаблона ARM в NF. В шаблоне ARM добавьте следующий раздел:

<pre>
"roleOverrideValues": [
    "{\"name\":\"<b>NF_component_name></b>\",\"deployParametersMappingRuleProfile\":{\"helmMappingRuleProfile\":{\"options\":{\"installOptions\":{\"atomic\":\"false\",\"wait\":\"true\",\"timeout\":\"100\"},\"upgradeOptions\":{\"atomic\":\"true\",\"wait\":\"true\",\"timeout\":\"4\"}}}}}"
]
</pre>

Имя компонента определяется в NFDV:

<pre>
     networkFunctionTemplate: {
      nfviType: 'AzureArcKubernetes'
      networkFunctionApplications: [
        {
          artifactType: 'HelmPackage'
          <b>name: 'fed-crds'</b>
          dependsOnProfile: null
          artifactProfile: {
            artifactStore: {
              id: acrArtifactStore.id
            }
</pre>

Рекомендации по очистке

При очистке ресурсов порядок важен. Удаление ресурсов в неправильном порядке может привести к осиротевшим ресурсам.

Ресурсы оператора

В качестве первого шага по очистке развернутой среды удалите ресурсы операторов в следующем порядке:

1. Социальные сети
2. Сайт
3. CGV

Вы можете перейти к удалению других ресурсов среды, таких как кластер Nexus Kubernetes, только после успешного удаления этих ресурсов оператора.

Ресурсы издателя

В качестве первого шага к очистке подключенной среды удалите ресурсы издателя в следующем порядке:

1. NSDV
2. НСДГ
3. NFDV
4. NFDG
5. Манифест артефакта
6. Хранилище артефактов
7. Издатель

Диспетчер служб оператора Azure не удаляет пространства имен в рамках любой операции удаления. Таким образом, после удаления всех ресурсов некоторые артефакты могут оставаться в кластере. Чтобы удалить оставшиеся артефакты, следует удалить все пространства имен рабочей нагрузки, созданные в кластере. Включение операции удаления пространства имен в рамках конвейера рабочего процесса является рекомендацией по автоматизации действия.

Рекомендации по глобальным ограничениям Azure

Azure применяет определенные глобальные лимиты и ограничения для всех служб Azure. Ниже приведен список проверенных ограничений, которые следует учитывать при подключении, проектировании или работе рабочих нагрузок с помощью Диспетчера служб Azure.

Ограничения шаблона ARM

Эти ограничения применяются к отрисованным шаблонам ARM, используемым с диспетчером служб Оператора Azure.

Ограничения Azure RBAC

Эти ограничения применяются к целевой подписке, используемой для развертывания Диспетчера служб Оператора Azure.

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

Другие ограничения

Эти ограничения наблюдались в некоторых реальных случаях использования.

Полный список см. в следующей статье: ограничения подписки и службы Azure, квоты и ограничения.