Concepts de base pour Azure Operator Service Manager

Cet article capture les recommandations de bonnes pratiques pour intégrer et déployer des fonctions réseau (NFS) avec Azure Operator Service Manager. En suivant ces instructions de base, les fournisseurs, les opérateurs et leurs partenaires peuvent optimiser les services réseau déployés sur Azure Operator Nexus. Tenez compte de ces concepts au début d’un processus de planification de l’intégration de fonctions réseau.

Considérations d’ordre général

Nous vous recommandons d’intégrer et de déployer d’abord vos NFs les plus simples (un ou deux graphiques) en utilisant les guides de démarrage rapide pour vous familiariser avec le flux global. Vous pouvez ajouter les détails de configuration nécessaires dans les itérations suivantes. À mesure que vous parcourez les guides de démarrage rapide, tenez compte des points suivants :

• Structurez vos artefacts pour qu’ils s’alignent sur l’utilisation planifiée. Envisagez de séparer les artefacts globaux des artefacts que vous souhaitez faire varier selon le site ou l’instance.
• Assurez-vous de la composition de service de plusieurs NFs avec un ensemble de paramètres qui correspond aux besoins de votre réseau. Par exemple, vous pouvez personnaliser 100 valeurs dans un graphique qui a 1 000 valeurs. Assurez-vous que dans la couche de schéma de groupe de configuration (CGS) (décrite plus en détail dans les sections qui suivent), vous n'affichez que 100.
• Réfléchissez rapidement à la façon dont vous souhaitez séparer l’infrastructure (par exemple, en clusters) ou les magasins d’artefacts et l’accès entre les fournisseurs, en particulier au sein d’un seul service. Faites correspondre votre ensemble de ressources de serveur de publication à ce modèle.
• Le site Azure Operator Service Manager est un concept logique, une représentation d’une destination de déploiement. Par exemple, un cluster Kubernetes pour les fonctions réseau en conteneur (CNF) ou un emplacement personnalisé étendu Azure Operator Nexus pour les fonctions réseau virtualisées (VNF). Il ne s’agit pas d’une représentation d’un site de périphérie physique. Il existe donc des cas d’usage où plusieurs sites partagent le même emplacement physique.
• Azure Operator Service Manager fournit différentes API qui vous aident à la combiner avec Azure DevOps ou d’autres outils de pipeline.
• L’extension d’interface de ligne de commande (CLI) Azure Operator Service Manager permet de publier des définitions de fonction réseau (NFD) et des NSD. Utilisez cet outil comme point de départ pour créer de nouvelles NFD et NSD. Envisagez d’utiliser l’interface CLI pour créer les fichiers initiaux. Modifiez-les ensuite pour incorporer des composants d’infrastructure avant de publier.

Considérations relatives au serveur de publication

• Nous vous recommandons de créer un seul éditeur par fournisseur NF, ou par type NF par fournisseur NF, où le fournisseur NF peut fournir plusieurs types NF. Cette pratique ;
  • Offre une prise en charge, une maintenance et une gouvernance optimales, en empêchant la prolifération des éditeurs. En particulier lors des activités de mise à niveau où la même action est souvent exécutée sur de nombreux NFs.
  • Réduit les coûts d’exploitation totaux en réduisant le nombre de ressources de stockage d’éditeur, telles qu’Azure Container Registry (ACR) ou les comptes de stockage.
  • Simplifie la conception du service réseau (NSD), où elle peut se composer de plusieurs NFs de plusieurs fournisseurs.
• Après avoir testé et approuvé l’ensemble souhaité de ressources d’éditeur Azure Operator Service Manager pour une utilisation en production, nous vous recommandons de marquer l’ensemble entier comme immuable. Le marquage de l’ensemble comme immuable permet d’éviter les modifications accidentelles et garantit une expérience de déploiement cohérente. Les marquages d’immuabilité permettent de faire la distinction entre :
  • Ressources et artefacts utilisés en production
  • Ressources et artefacts utilisés pour les tests et le développement

Vous pouvez interroger l’état des ressources du serveur de publication et les manifestes d’artefact pour déterminer ceux qui sont marqués comme immuables. Pour plus d’informations, consultez la fonctionnalité Gestion de l’aperçu des ressources de l’éditeur.

Gardez à l’esprit la logique suivante :

• Si la version de conception du service réseau (NSDV) est marquée comme immuable, la CGS doit également être marquée comme immuable. Sinon, l’appel de déploiement échoue.
• Si la version de définition de fonction réseau (NFDV) est marquée comme immuable, le manifeste d’artefact doit également être marqué comme immuable. Sinon, l’appel de déploiement échoue.
• Si seul le manifeste de l’artefact ou le CGS est marqué comme immuable, l’appel de déploiement réussit, que le NFDV et le NSDV soient marqués comme immuables ou non.
• Le marquage d’un manifeste d’artefact comme immuable garantit que tous les artefacts répertoriés dans ce manifeste sont également marqués comme immuables en appliquant les autorisations nécessaires sur le magasin d’artefacts. Les artefacts répertoriés incluent généralement des graphiques, des images et des modèles Azure Resource Manager (modèles ARM).
• Envisagez d’utiliser des conventions d’affectation de noms et des techniques de gouvernance convenus pour aider à combler toute lacune restante.

Haute disponibilité et récupération d'urgence pour les éditeurs

L’éditeur Azure Operator Service Manager est un service régional déployé dans des zones de disponibilité locales uniquement dans les régions prises en charge. Tenez compte des exigences suivantes pour la haute disponibilité et la récupération d’urgence de l’éditeur :

• Pour fournir une géoredondance, vérifiez que vous disposez d’un serveur de publication dans chaque région où vous envisagez de déployer des NFs. Envisagez d’utiliser des pipelines pour synchroniser les artefacts et les ressources de l’éditeur dans les régions.
• Le nom de l’éditeur doit être unique pour chaque locataire Microsoft Entra dans chaque région.

Considérations relatives au NFDG et au NFDV

Le groupe de définition de fonction réseau (NFDG) représente le plus petit composant que vous envisagez de réutiliser indépendamment sur plusieurs services. Toutes les parties d’un NFDG sont toujours déployées ensemble. Ces parties sont appelées networkFunctionApplications éléments. Par exemple, il est naturel d’intégrer un seul NF composé de plusieurs graphiques Helm et images en tant que NFDG unique si vous déployez toujours ces composants ensemble. Dans les cas où plusieurs NF sont toujours déployés ensemble, il est raisonnable de n’avoir qu’un seul NFDG pour tous. Les NFDG uniques peuvent avoir plusieurs NFDV.

• Pour les CNF NFDV, la liste networkFunctionApplications peut uniquement contenir des packages Helm.
  • Il est raisonnable d’inclure plusieurs packages Helm s’ils sont toujours déployés et supprimés ensemble.
• Pour les NFDVs VNF, la networkFunctionApplications liste doit contenir au moins une VhdImageFile valeur et un modèle ARM.
  • Pour déployer plusieurs machines virtuelles pour un seul VNF, veillez à utiliser un modèle ARM distinct pour chaque machine virtuelle.

Le modèle ARM peut déployer uniquement des ressources Resource Manager à partir des fournisseurs de ressources suivants :

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

Pour les modèles ARM qui contiennent n’importe quoi au-delà de la liste précédente, tous les PUT appels sur le VNF entraînent une erreur de validation.

Mises à jour mineures ou majeures de NFDV

Le NFDV représente une édition de la base NFDG et est associée à une version unique. Au fur et à mesure que la NF évolue, de nombreux NFDV sont utilisés pour saisir les capacités, à un moment donné. Les modifications classiques qui déclenchent un nouveau NFDV peuvent inclure :

• Mise à jour des artefacts NF, tels que de nouveaux graphiques ou versions d’images.
• Mise à jour des CGS ou des valeurs de groupe de configuration (CGV) qui se modifient deployParametersMappingRuleProfile.
• Mise à jour des valeurs par défaut codées en dur dans le NFDV.
• Mise à jour de l'activation des composants pour empêcher leur déploiement via applicationEnablement: Disabled.

Considérations relatives au NSDG et au NSDV

Un groupe de conception de service réseau (NSDG) est un composite d’un ou plusieurs NFDG et de tous les composants d’infrastructure déployés en même temps. Ces composants peuvent inclure des clusters et des machines virtuelles dans Nexus Kubernetes ou Azure Kubernetes Service (AKS). Un service de réseau de site (SNS) fait référence à une NSDV unique. Une telle conception fournit un déploiement cohérent et reproductible du service réseau sur un site à partir d’un seul appel SNS PUT .

Un exemple de NSDG (groupe de conception de sécurité réseau) peut être constitué des éléments suivants :

• NF Fonction de serveur d’authentification (AUSF)
• Gestion unifiée des données (UDM) NF
• Machine virtuelle d’administration prenant en charge AUSF ou UDM
• Fonction de Gestion des Sessions Unity Cloud (SMF) NF
• Cluster Kubernetes Nexus sur lequel AUSF, UDM et SMF sont déployés

Ces cinq composants forment un NSDG unique. Un NSDG unique peut avoir plusieurs NSDV.

Mise à jour mineure ou majeure de NSDV

Le NSDV représente une version du NSD de base et est associé à une version unique. Les modifications NSDV sont moins fréquentes que les modifications NFDV et, dans certains cas, un seul NSDV prend en charge l’ensemble du cycle de vie d’un service réseau de site. Toutefois, les modifications de service suivantes nécessitent un nouveau NSDV :

• Création, suppression ou ajout de valeurs dans des cgS.
• Modification du modèle ARM NF utilisé par une ressource de service de réseau de site déployé.
• Modification du modèle ARM d’infrastructure utilisé par une ressource de site de déploiement.

Considérations relatives à SNS (Simple Notification Service)

Nous vous recommandons d’avoir un SNS unique pour l’ensemble du site, y compris l’infrastructure. Le SNS doit déployer n’importe quelle infrastructure requise (par exemple, clusters et machines virtuelles dans Nexus Kubernetes ou AKS), puis déployer les fonctions réseau requises en plus. Une telle conception fournit un déploiement cohérent et reproductible du service réseau sur un site à partir d’un seul appel SNS PUT .

Nous vous recommandons de déployer chaque SNS avec une identité managée affectée par l’utilisateur plutôt qu’une identité managée affectée par le système. Cette identité managée affectée par l’utilisateur doit disposer des autorisations nécessaires pour accéder au NFDV et avoir le rôle d’opérateur d’identité managée sur lui-même. Pour plus d’informations, consultez Créer et affecter une identité managée affectée par l’utilisateur.

Considérations relatives au schéma de ressources

Les deux scénarios suivants illustrent le mappage des ressources Azure Operator Service Manager.

Scénario : fonction réseau unique

Un NF avec un ou deux composants d’application est déployé sur un cluster Kubernetes Nexus. Voici la répartition des ressources :

• NFDG : Si des composants peuvent être utilisés indépendamment, deux NFDGs avec un par composant. Si les composants sont toujours déployés ensemble, un NFDG unique est déployé.
• NFDV : si nécessaire en fonction des cas d’usage qui déclenchent des mises à jour mineures ou majeures de NFDV.
• NSDG : unique. Combine les NFs et les définitions de cluster Kubernetes.
• NSDV : selon les cas d’usage qui déclenchent des mises à jour mineures ou majeures de NSDV.
• CGS : unique. Pour faciliter la gestion, nous vous recommandons d’avoir des sous-sections pour chaque composant et infrastructure que vous déployez. Nous vous recommandons également que le CGS inclue les versions pour les NFD.
• CGV : unique en fonction du nombre de CGS.
• SNS : unique par NSDV.

Scénario : plusieurs fonctions réseau

Plusieurs FN avec des composants partagés et indépendants sont déployées dans un cluster Kubernetes Nexus. Voici la répartition des ressources :

• NFDG :
  • Unique pour tous les composants partagés.
  • Unique pour chaque composant indépendant ou NF.
• NFDV : multiple pour chaque NFDG par cas d’usage qui déclenche les mises à jour mineures ou majeures de NFDV.
• NSDG : unique. Combine l’ensemble des NFs, les composants partagés et indépendants et l’infrastructure (cluster Kubernetes ou toutes les VMs le prenant en charge).
• NSDV : selon les cas d’usage qui déclenchent des mises à jour mineures ou majeures de NSDV.
• CGS :
  • unique. Global pour tous les composants.
  • Unique par NF, y compris la version du NFD.
  • Selon le nombre total de paramètres, envisagez de combiner tous les CGS en un CGS unique.
• CGV : identique au nombre de CGS.
• SNS : unique par NSDV.

Considérations de mise à niveau

En supposant que les NF prennent en charge les mises à niveau sur place et en service, les considérations suivantes s’appliquent aux CNF :

• Si vous ajoutez de nouveaux graphiques et images, Azure Operator Service Manager installe les nouveaux graphiques.
• Si vous supprimez des graphiques et des images, Azure Operator Service Manager supprime les graphiques qui ne sont plus déclarés dans le NFDV.
• Azure Operator Service Manager vérifie que la NFDV/NSDV provient du même NFDG/NSDG, et donc du même serveur de publication. Les mises à niveau entre serveurs de publication ne sont pas prises en charge.

Les considérations suivantes s’appliquent aux fonctions réseau virtuelles (VNF) :

• Les mises à niveau sur place ne sont actuellement pas prises en charge. Vous devez instancier une nouvelle VNF avec une image mise à jour côte à côte. Supprimez ensuite l’ancienne VNF en supprimant le SNS.
• Si un VNF est déployé en tant que paire de machines virtuelles pour la haute disponibilité, vous pouvez concevoir le service réseau de telle sorte que vous puissiez supprimer et mettre à niveau des machines virtuelles une par une. Nous vous recommandons la conception suivante pour autoriser la suppression et la mise à niveau de VMs individuelles :
  • Déployez chaque machine virtuelle à l’aide d’un modèle ARM dédié.
  • À partir du modèle ARM, vous devez exposer deux paramètres via CGS :
    • Nom de la machine virtuelle, pour autoriser l’indication de l’instance principale ou secondaire
    • Stratégie de déploiement, pour contrôler si le déploiement de machine virtuelle est autorisé ou non
  • Dans le NFDV, vous devez paramétrer deployParameters et templateParameters de telle sorte que vous puissiez fournir les valeurs uniques à l’aide de CGV pour chacun d’eux.

Considérations sur la résolution des problèmes

Pendant l’installation et la mise à niveau, par défaut :

• Les options atomic et wait sont définies sur true.
• Le délai d’expiration de l’opération est défini sur 27 minutes.

Lors de l’intégration initiale, uniquement pendant que vous êtes encore en phase de débogage et de développement des artefacts, nous vous recommandons de définir l’indicateur atomic sur false. Ce paramètre empêche la réinitialisation de Helm en cas d’échec et conserve tous les journaux ou erreurs qui pourraient autrement être perdus. La façon optimale d’y parvenir se trouve dans le modèle ARM de la NF. Dans le modèle ARM, ajoutez la section suivante :

<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>

Le nom du composant est défini dans la NFDV :

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

Considérations relatives au nettoyage

Lorsque vous nettoyez les ressources, l’ordre est important. La suppression des ressources hors ordre peut entraîner l’abandon des ressources orphelines.

Ressources d’opérateur

À la première étape du nettoyage d’un environnement déployé, supprimez les ressources d’opérateur dans l’ordre suivant :

1. Services de Réseautage Social (SNS)
2. Site
3. CGV

Vous pouvez continuer à supprimer d’autres ressources d’environnement, telles que le cluster Kubernetes Nexus, uniquement après avoir supprimé correctement ces ressources d’opérateur.

Ressources de l'éditeur

À la première étape du nettoyage d’un environnement intégré, supprimez les ressources de l’éditeur dans l’ordre suivant :

1. NSDV
2. NSDG
3. NFDV
4. NFDG
5. Manifest d’artefact
6. Magasin d’artefacts
7. Éditeur

Azure Operator Service Manager ne supprime pas d’espaces de noms dans le cadre d’une opération de suppression. Par conséquent, une fois toutes les ressources supprimées, certains artefacts peuvent rester sur le cluster. Pour supprimer tous les artefacts restants, vous devez supprimer tous les espaces de noms de charge de travail créés sur le cluster. L’inclusion de l’opération de suppression d’espace de noms dans le cadre du pipeline de flux de travail est une recommandation pour automatiser l’action.

Considérations relatives aux limites globales Azure

Azure applique certaines limites et contraintes globales de service sur tous les services Azure. Voici une liste organisée de ces limites qui doivent être considérées lors de l’intégration, de la conception ou de l’exploitation de charges de travail à l’aide d’Azure Operator Service Manager.

Limites du modèle ARM

Ces limites s’appliquent aux modèles ARM rendus utilisés avec Azure Operator Service Manager.

limites du RBAC d'Azure

Ces limites s’appliquent à l’abonnement cible utilisé pour le déploiement d’Azure Operator Service Manager.

En règle générale, AOSM nécessite 8 fois le nombre d’opérations SNS simultanées sur un abonnement cible.

Autres limites

Ces limites ont été observées dans certains cas d’usage réels.

Pour obtenir une liste complète, consultez l’article suivant : Limites, quotas et contraintes d’abonnement Azure et de service.