Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
À partir de Windows Server 2025, l'infrastructure réseau définie par logiciel utilise une empreinte plus petite pour le contrôleur de réseau (NC), un des composants essentiels de l'infrastructure. NC peut désormais être déployé directement sur l’hôte en tant que service Failover Clustering. L’infrastructure basée sur Service Fabric continue d’être prise en charge. Cet article fournit un aperçu de la haute disponibilité du contrôleur réseau en utilisant Failover Clustering, son fonctionnement avec le Load Balancer logiciel et les passerelles, et comment il diffère du contrôleur réseau sur Service Fabric.
À compter d’Azure Local 2311.2, l’infrastructure de mise en réseau définie par logiciel utilise une empreinte plus petite pour le contrôleur de réseau (NC), l’un des principaux composants infrastructurels. NC peut désormais être déployé directement sur l’hôte en tant que service Failover Clustering. L’infrastructure basée sur Service Fabric continue d’être prise en charge. Cet article fournit un aperçu de la haute disponibilité du contrôleur réseau en utilisant Failover Clustering, son fonctionnement avec le Load Balancer logiciel et les passerelles, et comment il diffère du contrôleur réseau sur Service Fabric.
Contrôleur de réseau en tant que rôle
Le contrôleur de réseau est un composant clé de l’écosystème SDN. Il vous permet de déployer et de gérer vos configurations réseau client, notamment la mise en réseau virtuelle, la mise en réseau logique et la sécurité réseau. Dans les versions précédentes de Windows Server et d’Azure Local, le contrôleur de réseau devait être hébergé à l’intérieur d’une machine virtuelle. Le déploiement de ressources basées sur des machines virtuelles est long et gourmand en ressources. Les machines virtuelles ont pris davantage de processeur et de mémoire, ressources qui peuvent être dépensées sur vos charges de travail d’application principales. Depuis Windows Server 2025 et Azure Local 2311.2, le service de contrôleur réseau (NC) est nativement intégré à la machine hôte à l’aide du clustering de basculement, ce qui permet de libérer des ressources pour les autres charges de travail. L’illustration suivante fournit un aperçu des principales différences entre NC sur Service Fabric et NC sur Failover Clustering.
Architecture
Avec le contrôleur réseau sur Failover Clustering, tous les microservices du contrôleur réseau sont désormais contenus dans un groupe de ressources de cluster de basculement. Les microservices SDN utilisent une base de données unique et une partition unique, plutôt que trois bases de données dupliquées sur 3 machines virtuelles lors de l’utilisation de Service Fabric. Avec chaque microservice SDN en tant que groupe de ressources Failover Clustering, il y a une réduction significative de l’utilisation du CPU et du stockage.
Le contrôleur réseau et tous ses services sont configurés comme un groupe de ressources de cluster de basculement réparti sur les serveurs de votre cluster de Réseau Défini par Logiciel. Par exemple, votre topologie réseau inclut quatre serveurs regroupés avec un seul commutateur Top-of-Rack (ToR), et le composant contrôleur réseau en tant que Failover Clustering Generic Resource est réparti sur tous les serveurs. Au lieu des trois VM des versions précédentes, chaque microservice du contrôleur réseau est hautement disponible en tant que groupe de ressources de cluster de basculement. Le diagramme suivant montre un déploiement sur 4 nœuds avec le contrôleur réseau sur Failover Clustering.
Le groupe de ressources a les mêmes exigences d’approvisionnement que les machines virtuelles NC. Le microservice d’API nécessite une adresse IP flottante dans votre réseau de gestion et l’inscription DNS est toujours prise en charge.
Disponibilité élevée
Avec le contrôleur réseau sur Failover Clustering, la propriété des ressources est associée à un nœud spécifique au sein du cluster de basculement. Lorsqu’un serveur tombe en panne, les groupes de ressources sont transférés vers un autre nœud au sein du cluster. La réplication des données est effectuée via l’infrastructure sous-jacente de Failover Clustering, qui est Storage Replica. Pour en savoir plus sur Failover Clustering et Storage Replica, veuillez consulter les ressources suivantes :
Équilibrage de charge logicielle et passerelles
Cette transition de Service Fabric à Failover Clustering affecte uniquement nos services de contrôle réseau. D’autres rôles de virtualisation de fonction réseau, tels que l’équilibreur de charge logiciel et la passerelle, sont toujours hébergés sur des machines virtuelles. Le contrôleur réseau sur Failover Clustering n’affecte pas le comportement ou le fonctionnement des autres rôles de virtualisation des fonctions réseau. Pour plus d’informations sur l’équilibrage de charge logicielle et les passerelles, consultez les liens suivants :
Étapes suivantes
Pour commencer à déployer le contrôleur réseau avec Failover Clustering dans votre environnement Réseau Défini par Logiciel, veuillez consulter Déployer un contrôleur réseau avec le cluster de basculement.
Pour en savoir plus sur les exigences et les options de configuration, consultez Planifier un déploiement SDN.
Pour commencer à déployer le contrôleur réseau avec Failover Clustering dans votre environnement Réseau Défini par Logiciel, veuillez consulter Déployer un contrôleur réseau avec le cluster de basculement.
Pour en savoir plus sur les exigences et les options de configuration, consultez Planifier un déploiement SDN.