Поделиться через

Рекомендации по подключению и развертыванию сетевых функций в Диспетчере услуг Azure

  • Статья

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

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

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

  • Структурируйте артефакты для выравнивания планового использования. Рассмотрите возможность разделения глобальных артефактов от артефактов, которые нужно изменить по сайту или экземпляру.
  • Убедитесь, что служба составит несколько NFS с набором параметров, которые соответствуют потребностям вашей сети. Например, у вас может быть диаграмма с 1000 значениями, и вы настраиваете только 100 из них. Убедитесь, что на уровне схемы группы конфигурации (CGS) (более подробно описаны в разделах, приведенных ниже), что предоставляется только 100.
  • На ранней стадии вы узнаете, как отделять инфраструктуру (например, кластеры) или хранилища артефактов и получать доступ между поставщиками, в частности в рамках одной службы. Сделайте набор ресурсов издателя соответствующими этой модели.
  • Сайт Service Manager оператора Azure — это логическая концепция, представление назначения развертывания. Примерами являются кластер Kubernetes для контейнерных сетевых функций (CNFS) или расширенное пользовательское расположение оператора Azure Nexus для виртуализированных сетевых функций (VNFs). Это не представление физического пограничного сайта, поэтому в нескольких сайтах используется одно физическое расположение.
  • Диспетчер служб оператора Azure предоставляет различные API, упрощающие объединение с ADO или другими средствами конвейера.

Рекомендации по издателю

  • Рекомендуется создать одного издателя на поставщика NF. Эта практика обеспечивает оптимальную поддержку, обслуживание и управление всеми поставщиками и упрощает проектирование сетевой службы при создании нескольких NFS из нескольких поставщиков.

  • После тестирования и утверждения требуемого набора ресурсов издателя и артефактов оператора Azure Service Manager рекомендуется пометить весь набор как неизменяемый, чтобы предотвратить случайные изменения и обеспечить согласованное развертывание. Рекомендуется полагаться на неизменяемость возможностей, чтобы различать ресурсы и артефакты, используемые в рабочей среде, и те, которые используются для тестирования и разработки. Вы можете запросить состояние ресурсов издателя и манифестов артефактов, чтобы определить, какие из них помечены как неизменяемые. Дополнительные сведения см. в разделе "Клиенты Издателя", подписки, регионы и управление предварительной версией.

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

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

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

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

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

Для версий определения функции контейнеров (CNF NFDVs) networkFunctionApplications список может содержать только пакеты helm. Разумно включить несколько пакетов helm, если они всегда развертываются и удаляются вместе.

Для версий определения виртуализированной сетевой функции (VNF NFDVs) networkFunctionApplications список должен содержать по крайней мере один и один VhdImageFile шаблон ARM. Шаблон ARM должен развернуть одну виртуальную машину. Чтобы развернуть несколько виртуальных машин для одной виртуальной виртуальной машины, обязательно используйте отдельные шаблоны ARM для каждой виртуальной машины.

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

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

Примечание.

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

Распространенные варианты использования, которые активируют дополнительный или основной обновление версии сетевой функции

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

Примечание.

Минимальное количество изменений, необходимых при каждом изменении полезных данных заданного NF. Дополнительный или крупный выпуск NF без предоставления новых параметров CGS требует только обновления манифеста артефакта, отправки новых изображений и диаграмм и удара версии NFDV.

Рекомендации по проектированию сетевых служб и версии

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

Пример NSDG:

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

Эти пять компонентов образуют единый NSDG. Один NSDG может иметь несколько NSDV.

Распространенные варианты использования, которые активируют дополнительное или основное обновление версии сетевой службы

  • Создание или удаление CGSS.
  • Изменения в шаблоне ARM NF, связанном с одним из развернутых NFS.
  • Изменения в шаблоне ARM инфраструктуры, например AKS/NAKS или vm.

Примечание.

Изменения в NFDV не должны активировать обновление NSDV. Значение NFDV должно быть предоставлено в качестве параметра в CGS, чтобы операторы могли управлять развертыванием с помощью CGV.

Рекомендации по схеме группы конфигураций

Рекомендуется всегда начинать с одного CGS для всей NF. Если существуют параметры, относящиеся к сайту или экземпляру, рекомендуется сохранить их в одном CGS. Рекомендуется разделить на несколько CGS, если существует несколько компонентов (редко NFS, чаще всего инфраструктуры) или конфигураций, которые совместно используются для нескольких NFS. Число CGS определяет количество CGV.

Сценарий

  • FluentD, Kibana и Splunk (распространенные сторонние компоненты) всегда развертываются для всех NFS в NSD. Рекомендуется группировать эти компоненты в один NFDG.
  • NSD содержит несколько NFS, которые используют несколько конфигураций (расположение развертывания, имя издателя и несколько конфигураций диаграмм).

В этом сценарии рекомендуется использовать один глобальный CGS для предоставления общих конфигураций компонентов NF и сторонних производителей. При необходимости можно определить CGS для NF.

Выбор параметров для предоставления

  • CGS должны иметь только параметры, используемые NFs (конфигурация 0/N дня 0/N) или общие компоненты.
  • Параметры, которые редко настраиваются, должны иметь значения по умолчанию.
  • Если используются несколько CGS, рекомендуется не перекрываться между параметрами. Если требуется перекрытие, убедитесь, что имена параметров четко различаются между CGS.
  • Что можно определить с помощью API (Azure Operator Nexus, Azure Operator Service Manager) следует учитывать для CGS. В отличие от определения этих значений конфигурации с помощью файлов CloudInit.
  • Если не уверены, хорошая отправная точка заключается в том, чтобы предоставить параметр и иметь разумный по умолчанию, указанный в CGS. В следующем примере показаны примеры CGS и соответствующие полезные данные CGV.
  • Управляемое удостоверение, назначаемое пользователем, должно использоваться во всех шаблонах ARM NF и должно быть предоставлено через CGS.

Полезные данные CGS:

{ 
  "type": "object", 
  "properties": { 
    "abc": { 
    "type": "integer", 
    "default": 30
    }, 
    "xyz": { 
    "type": "integer", 
    "default": 40
    },
    "qwe": {
    "type": "integer" //doesn't have defaults
    }
  }
  "required": "qwe"
}

Соответствующие полезные данные CGV, передаваемые оператором:

{
"qwe": 20
}

Итоговые полезные данные CGV, созданные Диспетчером служб Оператора Azure:

{
"abc": 30,
"xyz": 40,
"qwe": 20
}

Рекомендации по значениям группы конфигурации

Перед отправкой создания ресурса CGV можно проверить, соответствует ли схема и значения базового ФАЙЛА YAML или JSON соответствующим службам CGS. Для этого можно использовать расширение YAML для Visual Studio Code.

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

Расширение ИНТЕРФЕЙСА командной строки диспетчера операторов Azure помогает публиковать NFD и NSD. Используйте это средство в качестве отправной точки для создания новых NFD и NSD. Рекомендуется использовать интерфейс командной строки для создания исходных файлов. Затем измените их, чтобы включить компоненты инфраструктуры перед публикацией.

Рекомендации по сетевой службе сайта

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

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

Сопоставление ресурсов Service Manager для оператора Azure для каждого варианта использования

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

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

NF с одним или двумя компонентами приложения развертывается в кластере NAKS.

Разбивка ресурсов:

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

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

Несколько NFs с некоторыми общими и независимыми компонентами развертываются в кластере NAKS.

Разбивка ресурсов:

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

Рекомендации по обновлению программного обеспечения

При условии, что NFS поддерживают обновления на месте или в службе, для CNFs:

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

Для виртуальных машин:

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

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

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

Рассмотрите следующие требования к высокой доступности и аварийному восстановлению:

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

Примечание.

Если регион становится недоступным, можно развернуть (но не обновить) NF с помощью ресурсов издателя в другом регионе. Если артефакты и ресурсы идентичны издателям, необходимо только изменить networkServiceDesignVersionOfferingLocation значение полезных данных ресурсов SNS.

resource sns 'Microsoft.HybridNetwork/sitenetworkservices@2023-09-01’ = {
 name: snsName
 location: location
 identity: {
  type: 'SystemAssigned'
 }
 properties: {
   publisherName: publisherName
   publisherScope: 'Private'
   networkServiceDesignGroupName: nsdGroup
   networkServiceDesignVersionName: nsdvName
   networkServiceDesignVersionOfferingLocation: location

Соображения касательно диагностики

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

В шаблоне ARM добавьте следующий раздел:

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

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

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

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

Удалите ресурсы оператора в следующем порядке, чтобы не осталось потерянных ресурсов:

  • SNS
  • Сайт
  • CGV

Внимание

Перед удалением NFDV убедитесь, что SNS удален.

Удалите ресурсы издателя в следующем порядке, чтобы не осталось потерянных ресурсов:

  • CGS
  • NSDV
  • NSDG
  • NFDV
  • NFDG
  • манифест артефакта;
  • хранилище артефактов;
  • Publisher

Рекомендации, если NF запускает cert-manager

Внимание

Это руководство относится только к определенным выпускам. Проверьте версию для правильного поведения.

С выпуска 1.0.2728-50 до выпуска 2.0.2777-132 AOSM использует диспетчер сертификатов для хранения и смены сертификатов. В рамках этого изменения AOSM развертывает оператор cert-manager и связывает CRD в пространстве имен azurehybridnetwork. Так как наличие нескольких операторов диспетчера сертификатов, даже развернутых в отдельных пространствах имен, будет отслеживаться во всех пространствах имен, только один диспетчер сертификатов можно эффективно запускать в кластере.

Любой пользователь, пытающийся установить диспетчер сертификатов в кластере в рамках развертывания рабочей нагрузки, получит сбой развертывания с ошибкой, что CRD "существует и не может быть импортирован в текущий выпуск". Чтобы избежать этой ошибки, рекомендуется пропустить установку cert-manager, вместо этого зависимостей от оператора cert-manager и CRD, уже установленного AOSM.

Другие изменения конфигурации, которые следует учитывать

Помимо отключения NfApp, связанного со старым пользователем cert-manager, мы обнаружили, что другие изменения могут потребоваться;

  1. Если один NfApp содержит диспетчер сертификатов и установку ЦС, они должны разбиты на два NfApps, чтобы партнер мог отключить диспетчер сертификатов, но включить установку ЦС.
  2. Если другие NfApps имеют ссылки на DependsOn старого пользователя cert-manager NfApp, их необходимо удалить.
  3. Если любое другое значение пространства имен NfApps со ссылкой на старое значение пространства имен cert-manager, это потребуется изменить на новое значение пространства имен azurehybridnetwork.

Совместимость версий Cert-Manager и управление

Для оператора cert-manager текущая развернутая версия — 1.14.5. Пользователи должны проверить совместимость с этой версией. Будущие обновления операторов cert-manager будут поддерживаться с помощью процесса обновления расширения NFO.

Для ресурсов CRD текущая развернутая версия — 1.14.5. Пользователи должны проверить совместимость с этой версией. Так как управление общим кластером CRD обычно обрабатывается администратором кластера, мы работаем над тем, чтобы обеспечить обновление ресурсов CRD через стандартный процесс надстройки Nexus.