Calcul d’Azure Operator Nexus

Azure Operator Nexus repose sur des constructions de base comme des serveurs de calcul, des appliances de stockage et des appareils de structure réseau. Ces serveurs de calcul, également appelés machines complètes (BMM), représentent les machines physiques sur le rack. Ils exécutent le système d’exploitation Azure Linux (anciennement CBL-Mariner) et fournissent une prise en charge d’intégration fermée pour les charges de travail hautes performances.

Ces machines virtuelles complètes sont déployées dans le cadre de la suite d’automatisation Azure Operator Nexus. Ils existent en tant que nœuds dans un cluster Kubernetes pour servir diverses charges de travail virtualisées et conteneurisées dans l’écosystème.

Chaque BMM dans une instance Azure Operator Nexus est représentée comme une ressource Azure. Les opérateurs ont accès à différentes opérations pour gérer le cycle de vie de BMM comme toute autre ressource Azure.

Fonctionnalités clés du calcul Nexus de l’opérateur Azure

Alignement NUMA

L’alignement de l’accès à la mémoire non uniforme (NUMA) est une technique permettant d’optimiser les performances et l’utilisation des ressources dans les serveurs à plusieurs sockets. Elle implique l’alignement des ressources de mémoire et de calcul pour réduire la latence et améliorer l’accès aux données au sein d’un système serveur.

Grâce à l’emplacement stratégique des composants logiciels et des charges de travail d’une manière NUMA, les opérateurs peuvent améliorer les performances des fonctions réseau, telles que les routeurs virtualisés et les pare-feu. Ce placement permet d’améliorer la prestation de services et la réactivité dans leurs environnements cloud.

Par défaut, toutes les charges de travail déployées dans une instance Nexus d’opérateur Azure sont alignées sur NUMA.

Épinglage du processeur

L’épinglage du processeur est une technique permettant d’allouer des cœurs de processeur spécifiques à des tâches ou charges de travail dédiées, ce qui permet de garantir une isolation cohérente des performances et des ressources. L’épinglage de fonctions réseau critiques ou d’applications en temps réel à des cœurs de processeur spécifiques permet aux opérateurs de réduire la latence et d’améliorer la prévisibilité dans leur infrastructure. Cette approche est utile dans les scénarios où des exigences strictes de qualité de service existent, car ces tâches peuvent recevoir une puissance de traitement dédiée pour des performances optimales.

Toutes les machines virtuelles créées pour les charges de travail de fonction de réseau virtuel (VNF) ou de fonction réseau conteneurisée (CNF) sur le calcul Azure Operator Nexus sont épinglées à des cœurs virtuels spécifiques. Cette épinglage offre de meilleures performances et évite le vol du processeur.

Isolation du processeur

L’isolation du processeur fournit une séparation claire entre les processeurs alloués pour les charges de travail et les processeurs alloués pour les activités du plan de contrôle et de la plateforme. L’isolation du processeur empêche les interférences et limite la prévisibilité des performances pour les charges de travail critiques. En isolant les cœurs de processeur ou les groupes de cœurs, les opérateurs peuvent atténuer l’effet des voisins bruyants. Elle permet de garantir la puissance de traitement requise pour les applications sensibles à la latence.

Azure Operator Nexus réserve un petit ensemble de processeurs pour le système d’exploitation hôte et d’autres applications de plateforme. Les processeurs restants sont disponibles pour l’exécution des charges de travail réelles.

Grand nombre de pages prises en charge

L’utilisation de page volumineuse (hugepage) dans les charges de travail fait référence à l’utilisation de pages de mémoire volumineuses, généralement d’une taille de 2 Mo ou de 1 Go, au lieu des pages standard de 4 Ko. Cette approche permet de réduire la surcharge mémoire et d’améliorer les performances globales du système. Elle réduit le taux d’absence de mémoire tampon de recherche de traduction (TLB) et améliore l’efficacité de l’accès à la mémoire.

Les charges de travail qui impliquent des jeux de données volumineux ou des opérations de mémoire intensives, telles que le traitement des paquets réseau, peuvent bénéficier d’une utilisation de page volumineuse, car elles améliorent les performances de la mémoire et réduisent les goulots d’étranglement liés à la mémoire. Par conséquent, les utilisateurs voient un débit amélioré et une latence réduite.

Toutes les machines virtuelles créées sur Azure Operator Nexus s’appuient sur des hugepages de 1GiB(1G) pour la mémoire demandée. Le noyau s’exécutant dans la machine virtuelle peut gérer cette mémoire disponible comme il l’entend, y compris l’allocation de mémoire pour prendre en charge ces hugepages (2Mo ou 1Go).

Prise en charge de double pile

La prise en charge à double pile fait référence à la capacité de l’équipement réseau et des protocoles à gérer simultanément le trafic IPv4 et IPv6. Avec l’épuisement des adresses IPv4 disponibles et l’adoption croissante d’IPv6, la prise en charge de double pile est essentielle pour la transition transparente et la coexistence entre les deux protocoles.

Les opérateurs Telco utilisent la prise en charge à double pile pour garantir la compatibilité, l’interopérabilité et la vérification future de leurs réseaux. Il leur permet de prendre en charge les appareils et services IPv4 et IPv6 tout en effectuant progressivement une transition vers un déploiement IPv6 complet.

La prise en charge à double pile permet de garantir une connectivité ininterrompue et une livraison fluide des services aux clients, quel que soit leur protocole d’adressage réseau. Azure Operator Nexus prend en charge la configuration IPv4 et IPv6 sur toutes les couches de la pile.

Cartes d’interface réseau

Les calculs dans Azure Operator Nexus sont conçus pour répondre aux exigences relatives à l’exécution d’applications critiques de qualité Telco. Ils peuvent effectuer un transfert de données rapide et efficace entre les serveurs et les réseaux.

Les charges de travail peuvent utiliser la virtualisation d’E/S racine unique (SR-IOV). SR-IOV permet l’affectation directe de ressources d’E/S physiques, telles que les interfaces réseau, aux machines virtuelles. Cette affectation directe contourne la couche de commutateur virtuel de l’hyperviseur.

Cet accès matériel direct améliore le débit réseau, réduit la latence et permet une utilisation plus efficace des ressources. Il fait de SR-IOV un choix idéal pour les opérateurs exécutant des fonctions réseau virtualisées et conteneurisées.

État BMM

Les propriétés suivantes reflètent l’état opérationnel d’un BMM :

• Power State indique l'état tel qu'il est dérivé d'un contrôleur bare-metal (BMC). L’état peut être On ou Off.

• Ready State fournit une évaluation globale de la préparation de BMM. Il examine une combinaison de Detailed Status, Power State et l’état d’approvisionnement de la ressource pour déterminer si le BMM est prêt ou non. Quand Ready State est True, le BMM est activé, Detailed Status est Provisioned, et le nœud qui représente le BMM a correctement joint le cluster Kubernetes sous cloud. Si l’une de ces conditions n’est pas remplie, Ready State est définie sur False.

• Cordon State reflète la possibilité d’exécuter toutes les charges de travail sur une machine. Les valeurs valides sont Cordoned et Uncordoned. Cordoned saisit la création de nouvelles charges de travail sur l’ordinateur. Uncordoned garantit que les charges de travail peuvent désormais s’exécuter sur ce BMM.

• Detailed Status reflète l’état actuel de la machine :

  • Preparing : la machine est en cours de préparation pour l’approvisionnement.
  • Provisioning : l’approvisionnement est en cours.
  • Provisioned : le système d’exploitation est approvisionné sur l’ordinateur.
  • Available : la machine est disponible pour participer au cluster. La machine a été correctement approvisionnée, mais est actuellement désactivée.
  • Error : la machine n’a pas pu être approvisionnée.

  Preparing et Provisioning sont des états transitoires. Provisioned, Available et Error sont des états d’état final.

• MachineRoles permet d’identifier les rôles que BMM remplit dans le cluster Nexus. Les rôles suivants sont attribués aux ressources BMM :

  • Control plane : ces BMM exécutent les agents de plan de contrôle Kubernetes pour le cluster de plateforme Nexus.
  • Management plane : BMM exécute les agents de la plateforme Nexus, y compris les contrôleurs et les extensions.
  • Compute plane : le BMM responsable de l’exécution des charges de travail réelles des tenants (locataires), notamment les clusters Kubernetes Nexus et les machines virtuelles.

  Pour plus d’informations sur les rôles d’ordinateur, reportez-vous à ce lien.

Opérations BMM

• Update/Patch BareMetal Machine : mettez à jour les propriétés de la ressource BMM.
• List/Show BareMetal Machine : récupérez des informations BMM.
• Reimage BareMetal Machine : réapprovisionnez un BMM qui correspond à la version d’image utilisée sur le cluster.
• Remplacez BareMetal Machine : remplacez un BMM dans le cadre d’un effort de service de l’ordinateur.
• Redémarrez bareMetal Machine : redémarrez un BMM.
• Désactiver la machine BareMetal : désactivez un BMM.
• Démarrez BareMetal Machine : activez un BMM.
• Cordon BareMetal Machine : empêchez la planification des charges de travail sur le nœud Kubernetes de BMM spécifié. Si vous le souhaitez, autorisez l’évacuation des charges de travail à partir du nœud.
• Uncordon BareMetal Machine : autorisez la planification des charges de travail sur le nœud Kubernetes de BMM spécifié.
• BareMetalMachine Validate : déclenchez la validation matérielle d’un BMM.
• BareMetalMachine Run : autorisez le client à exécuter un script spécifié directement dans l’entrée sur le BMM ciblé.
• BareMetalMachine Run Data Extract : autorisez le client à exécuter une ou plusieurs extractions de données sur un BMM.
• BareMetalMachine Exécuter en lecture seule : autorisez le client à exécuter une ou plusieurs commandes en lecture seule sur un BMM.

Remarque

Les clients ne peuvent pas créer ou supprimer directement des machines virtuelles complètes. Ces machines sont créées uniquement dans le cadre du cycle de vie du cluster. L’implémentation bloque les demandes de création ou de suppression de tous les utilisateurs, et autorise uniquement les opérations de création ou de suppression internes ou pilotées par l’application.

Informations spécifiques au facteur de forme

Azure Operator Nexus offre un groupe de solutions cloud locales qui répondent aux environnements à périphérie proche et à périphérie.

Références SKU Operator Nexus Network Cloud

Pour des informations sur la référence SKU, consultez Références SKU de cloud réseau Operator Nexus.