Forum aux questions (FAQ) sur Azure Operator Nexus
Les sections suivantes couvrent certaines des questions fréquemment posées pour Azure Operator Nexus :
Plateforme – Général
Quels sont les services fournis par Azure Operator Nexus ?
Azure Operator Nexus est une plateforme cloud hybride managée qui prend en charge les charges de travail réseau de niveau opérateur. Ici, le plan de gestion réside dans Azure, et le plan de contrôle et le plan utilisateur sont déployés sur les sites des opérateurs ou dans Azure. Il simplifie l’approvisionnement de nouveaux services réseau, et optimise le déploiement local de fonctions et d’applications réseau. Le client final peut déployer des applications conteneurisées (sur un cluster Nexus AKS local) ou une charge de travail virtualisée pour exécuter ces fonctions réseau. Le client bénéficie d’une intégration par défaut à de nombreux services Azure comme Azure Monitor, Azure Container Registry et Azure Kubernetes Services.
Comment faire pour interagir avec l’instance Operator Nexus ?
Vous pouvez interagir avec Operator Nexus comme n’importe quel autre service Azure à l’aide de l’interface de ligne de commande AZ, de l’API, du modèle ARM ou du portail. Vous pouvez également utiliser des modèles BICEP.
Le client doit-il déployer des ressources dans son abonnement pour déployer des instances Azure Operator Nexus ?
Oui, le client doit créer certaines ressources dans la région en question sous ses abonnements Azure. Il doit notamment créer une paire constituée d’un Network Fabric Controller et d’une ressource Gestionnaire de cluster, un espace de travail Log Analytics et un compte de stockage. Pour plus d’informations, consultez la documentation d’Azure Operator Nexus.
Azure Operator Nexus s’appuie-t-il sur la connectivité avec Azure ? Que se passe-t-il en cas de déconnexion ?
Oui, vous avez besoin d’une connexion ExpressRoute pour la connectivité à Azure et à des fins d’orchestration, de gestion et d’opération. En cas de déconnexion, les charges de travail continuent à s’exécuter telles quelles, mais vous risquez de perdre la capacité à orchestrer de nouvelles ressources.
Dois-je utiliser la nomenclature (BOM, Bill of Material) spécifiée par Microsoft ?
Oui, pour garantir des performances de niveau opérateur et des degrés élevés d’automatisation, vous devez utiliser l’équipement spécifié dans l’une de nos nomenclatures.
Comment faire pour planifier une instance Operator Nexus résiliente ? Comment Operator Nexus gère-t-il la récupération d’urgence ?
Les clients doivent concevoir leurs services avec une redondance intra-rack, une redondance inter-rack, et un équilibrage de charge global entre plusieurs instances. En outre, pour la haute disponibilité, prévoyez de répartir vos instances dans plusieurs régions Azure.
Comment fonctionnent les mises à jour des composants locaux et Azure ?
Les mises à niveau d’Operator Nexus sont effectuées en deux phases : les mises à niveau des packs de gestion et les mises à niveau des packs d’exécution. Les mises à niveau des packs de gestion concernent les mises à niveau des contrôleurs dans Azure, des gestionnaires de cluster dans l’abonnement client, et des instances locales. Dans les instances locales, cela comprend les contrôleurs Kubernetes responsables de la maintenance de l’état des ressources infra.
Les mises à jour des packs de gestion peuvent entraîner des interruptions des activités d’approvisionnement, mais elles n’ont pas d’impact sur les charges de travail des clients en cours d’exécution. Les clients ne contrôlent pas et ne pilotent pas ces mises à niveau, mais elles sont essentielles pour leur fournir la possibilité de procéder à de nouvelles mises à niveau basées sur le runtime au sein de leurs instances locales.
Les mises à niveau de packs d’exécution, quant à elles, concernent les composants qui nécessitent des mises à jour du système d’exploitation et/ou les composants de prise en charge des charges de travail. La mise à jour du pack d’exécution est entièrement sous le contrôle du client, et des API peuvent être utilisées pour effectuer ces mises à jour. Un certain impact sur les charges de travail peut s’observer pendant cette mise à niveau.
L’appliance de stockage est-elle obligatoire ?
Pour les références SKU de périphérie proche, l’appliance de stockage fait partie de l’infrastructure matérielle que l’opérateur doit se procurer.
Operator Nexus fournit-il des meilleures pratiques ou des blueprints pour le déploiement de fonctions réseau sur Operator Nexus ?
Oui, Operator Nexus inclut le programme Nexus Ready. Dans le cadre de ce programme, Microsoft collabore avec les principaux partenaires de fonctions réseau afin de vérifier que leurs fonctions réseau peuvent s’exécuter sur la plateforme Nexus. Nous validons ces fonctions réseau à intervalles réguliers pour nous assurer qu’elles restent conformes aux versions plus récentes de Nexus. Les opérateurs peuvent désormais obtenir un déploiement cohérent et évolutif de fonctions réseau multi-fournisseurs avec le programme Nexus Ready.
Quelles sont les données qui restent locales, et quelles sont celles qui sont disponibles dans Azure ?
Du point de vue de l’infrastructure, les données sont gérées via des API Azure. La télémétrie de ces couches est collectée et visible sous l’abonnement du client. Les clients peuvent utiliser l’espace de travail Log Analytics, des comptes de stockage ou d’autres services Analytics dans Azure pour examiner la télémétrie des couches Infra.
Pour les charges de travail de locataire, les images sont stockées dans des ACR (Azure Container Registry) une fois déployées. Microsoft offre une option pour collecter la télémétrie à partir de charges de travail de locataire dans Azure, mais les clients peuvent choisir d’autres outils afin de collecter ou d’analyser les données de télémétrie.
Si une région Azure n’existe pas dans mon pays/région, puis-je tout de même utiliser Operator Nexus ?
Oui, tout ce dont vous avez besoin est la connectivité ExpressRoute à une région Azure. La connectivité ExpressRoute est disponible à de nombreux emplacements. Pour plus d’informations, consultez Géolocalisations et Fournisseurs de connectivité.
Puis-je déplacer mes ressources d’un abonnement vers un autre ?
Nous ne prenons pas en charge les déplacements de ressources actuellement. Si vous devez déplacer des ressources, vous pouvez essayer de supprimer les contrôleurs existants et d’utiliser le modèle ARM pour en créer un autre à un autre emplacement.
Combien d’instances peuvent être associées à une paire Gestionnaire de cluster/Fabric Controller ?
Le nombre d’instances Azure Operator Nexus qu’une paire unique Gestionnaire de cluster/Network Fabric Controller peut gérer dépend de plusieurs facteurs. Ce nombre peut être influencé par des facteurs tels que la taille des instances Operator Nexus, la bande passante du circuit ExpressRoute, le nombre et la fréquence de collecte de métriques facultatives, le nombre de charges de travail exécutées dans l’instance, la destination de la collecte des données de télémétrie de charge de travail et d’autres facteurs.
Pour plus d’informations, consultez Limites et quotas.
Est-il viable de redéployer un cluster en cours d’exécution ? Si oui, quelles sont les garanties en place pour empêcher les déploiements accidentels ?
Un cluster en cours d’exécution ne peut pas subir de redéploiement ; au lieu de cela, l’utilisateur doit le supprimer, puis le redéployer. Si le cluster est déjà en cours d’exécution, l’action de déploiement empêche toute nouvelle action sur le cluster, réduisant ainsi le risque de déploiements accidentels.
Est-il possible pour Azure Operator Nexus d’activer la création de clusters avec l’option de choisir des racks ou sous-ensembles d’instances spécifiques au sein d’un rack ?
Azure Operator Nexus n’offre pas la possibilité de sélectionner des racks ou des sous-ensembles spécifiques d’instances au sein d’un rack dans le cadre du déploiement du cluster.
En cas d’interruption du réseau entre le Gestionnaire de cluster et les serveurs locaux pendant le déploiement, le processus peut-il être repris une fois la connectivité restaurée ?
Cela dépend de l’état du cluster : si le cluster a échoué, il doit être supprimé et redéployé. En revanche, si le cluster est toujours en cours de déploiement, il subit un processus de rapprochement permettant au processus de déploiement de se poursuivre.
Le déploiement du cluster attend-il que tous les nœuds de calcul aient été approvisionnés ?
Le processus de déploiement retente de manière continue l’approvisionnement des nœuds de calcul jusqu’à ce que tous les nœuds aient été correctement approvisionnés. Lorsque le cluster atteint le seuil défini, l’état du cluster bascule à « En cours d’exécution ». Toutefois, les nœuds restants continuent de subir le processus d’approvisionnement jusqu’à ce qu’ils aient été correctement approvisionnés.
Compute
Azure Operator Nexus prend-il en charge la création de machines virtuelles ?
Oui, Azure Operator Nexus permet de créer des machines virtuelles personnalisées pour héberger des fonctions réseau virtuelles au sein d’un réseau de télécommunications. La plateforme Azure Operator Nexus fournit une commande Azure CLI pour créer une machine virtuelle personnalisée. Pour héberger une VNF sur votre machine virtuelle, inscrivez-la dans Azure Arc, et mettez en place une connexion SSH via Azure CLI. Vous pouvez utiliser votre image lorsque vous créez des machines virtuelles Azure Operator Nexus. Vérifiez que chaque image utilisée pour créer vos machines virtuelles de charge de travail est une image conteneurisée au format de disque qcow2 ou brut. Chargez ces images dans Azure Container Registry.
Comment faire pour mettre à jour un serveur nu ?
Pour mettre à jour un serveur nu au sein d’une instance Azure Operator Nexus, vous pouvez utiliser les API Azure. Toute mise à jour du serveur nu fait partie de la mise à niveau du pack d’exécution. Cette mise à niveau nécessite la connectivité de l’instance Nexus vers Azure.
Quel est le système d’exploitation qui s’exécute sur le serveur nu ? Puis-je apporter mon propre système d’exploitation ?
Les serveurs nus sont déployés avec Microsoft Azure Linux (anciennement nommé système d’exploitation CBL Mariner), qui est rigoureusement testé et est compatible avec les agents Azure requis. Il n’est pas prévu de prendre en charge d’autres offres de système d’exploitation pour les serveurs nus.
Combien de serveurs Operator Nexus prend-il en charge ? Combien de racks ?
Une instance Operator Nexus peut avoir jusqu’à huit racks de calcul, chaque rack hébergeant jusqu’à 16 serveurs. Ces serveurs de calcul sont utilisés pour exécuter les charges de travail de locataire.
Réseaux
Operator Nexus prend-il en charge IPv6 ?
Oui, Azure Operator Nexus prend en charge la configuration IPV4 et IPV6 sur toutes les couches de la pile.
Quelles sont les exigences réseau pour Azure Operator Nexus ?
Voici quelques-unes des exigences réseau pour Azure Operator Nexus :
- Les clients doivent travailler avec les partenaires Microsoft pour configurer des connexions ExpressRoute
- L’appareil PE (Provider Edge) prend en charge les connexions 400G ou 100G vers l’appareil CE (Customer Edge) dans l’instance Operator Nexus
- Le PE doit avoir des routes vers ExpressRoutes
- Blocs d’adresses IP définis pour différents services, réseaux locaux virtuels pour iDrac, PXE, Stockage, OAM, etc.
Pour plus d’informations, consultez Network Fabric Controller et Infrastructure réseau.
Qu’est-ce qu’un domaine d’isolation ?
Les domaines d’isolation activent la connectivité de couche 2 ou 3 entre les charges de travail hébergées sur l’instance Azure Operator Nexus et les réseaux externes. Ces constructions segmentent un réseau en domaines d’authentification, et appliquent la communication dans les limites requises.
Operator Nexus prend-il en charge un appareil ToR (Top of Rack) unique ?
Pour la périphérie proche, l’infrastructure est conçue sur un modèle à haute disponibilité ; c’est la raison pour laquelle vous ne pouvez pas avoir un seul commutateur ToR.
Network Packet Broker (NPB) est-il obligatoire ?
Pour les références SKU de périphérie proche, les NPB font partie de la nomenclature.
Comment faire pour configurer le service d’équilibrage de charge dans un cluster Kubernetes Nexus ?
L’équilibreur de charge permet aux services externes d’accéder aux services exécutés dans le cluster. Pour plus d’informations, consultez l’article sur l’équilibreur de charge.
Charges de travail de locataire
Puis-je apporter mon propre cluster K8S ?
La plateforme Nexus offre aux clients une option permettant de créer des clusters Nexus AKS avec plusieurs versions de Kubernetes ou des machines virtuelles pour exécuter leurs charges de travail.
Quelles sont les fonctions réseau virtualisées (VNF) et fonctions réseau conteneurisées (CNF) certifiées sur la plateforme ?
La validation des VNF et CNF est une activité en cours. Nous publierons bientôt la liste des VNF et CNF certifiées.
Si une VNF ou CNF n’est pas certifiée, puis-je quand même l’utiliser ?
En effet, vous pouvez collaborer avec l’équipe Nexus afin d’être sûr qu’aucune limitation ne vous empêcherait de déployer ces charges de travail.
Comment faire pour déployer une machine virtuelle ou un conteneur ?
Les clients peuvent utiliser des API pour déployer des clusters AKS de machines virtuelles et Nexus dans une instance Operator Nexus. Pour une expérience enrichie, Microsoft propose un autre service AOSM (Azure Operator Service Manager) qui vous permet d’automatiser le déploiement de vos fonctions réseau conteneurisées (CNF) et virtualisées (VNF).
Quelles classes de stockage puis-je utiliser pour mes conteneurs au sein de clusters AKS ?
Les clusters Nexus AKS prennent en charge les classes de stockage RWX (Read Write Many) et RWO (Read Write Once).
Comment faire en sorte que les machines virtuelles Operator Nexus soient hautement disponibles ?
Les opérateurs peuvent choisir de déployer des machines virtuelles sur plusieurs machines nues et sur des racks pour obtenir une haute disponibilité.
Observabilité
Comment faire pour surveiller mon instance Azure Operator Nexus ?
Azure Operator Nexus permet aux clients de surveiller l’intégrité de l’instance Nexus et de ses ressources connectées grâce à la collecte de télémétrie dans l’abonnement client. Les clients peuvent collecter et analyser tous les journaux dans l’espace de travail Azure Log Analytics/Azure Data Explorer, où ces journaux peuvent être conservés pendant une période prolongée.
Quelles sont les métriques disponibles pour le calcul, la mise en réseau et le stockage ? Puis-je déclencher des alertes sur ces métriques ? Puis-je effectuer une intégration à ma propre solution de supervision ?
Un ensemble étendu et organisé de métriques est remis au client à partir de toutes les couches de la pile d’instances Azure Operator Nexus. Il s’agit notamment de métriques essentielles pour évaluer l’intégrité en fonction du calcul, du stockage et de la mise en réseau, notamment concernant les quotas et l’utilisation des ressources. Les clients peuvent définir des règles d’alerte appropriées en fonction de la télémétrie collectée, afin de s’assurer que des notifications sont déclenchées chaque fois que les seuils configurés sont atteints.
Pour plus d’informations, consultez la liste de métriques.