Planifier l’infrastructure SDN sur Azure Stack HCI

Effectué

Votre recherche initiale concernant les fonctionnalités de SDN d’Azure Stack HCI a augmenté votre niveau de confiance dans la possibilité de les utiliser pour améliorer la résilience, la flexibilité, la sécurité et la facilité de gestion de votre infrastructure réseau. Toutefois, vous vous rendez compte qu’un déploiement SDN réussi nécessite une planification appropriée, en particulier si vous souhaitez l’intégrer à votre environnement existant.

Planifier le déploiement du SDN

Avant de pouvoir déployer le SDN sur un cluster Azure Stack HCI, vous devez vous assurer que votre infrastructure répond à toutes les conditions préalables appropriées, y compris :

  • Nœuds de clusters Azure Stack HCI et machines virtuelles d’infrastructure
  • Contrôleur réseau
  • Logical networks
  • Infrastructure de routage
  • Réseaux physiques

Notes

Cette unité fournit une vue d’ensemble de haut niveau des exigences du SDN sur Azure Stack HCI. Pour obtenir des informations détaillées sur cette rubrique, reportez-vous à la documentation Microsoft référencée dans l’unité de synthèse de ce module.

Nœuds de clusters Azure Stack HCI et machines virtuelles d’infrastructure

Chaque nœud de cluster Azure Stack HCI doit être connecté au réseau logique de gestion via au moins une carte physique qui fait partie d’un commutateur virtuel Hyper-V externe. Toutes les machines virtuelles qui hébergent des services d’infrastructure SDN, comme le contrôleur de réseau, les passerelles RAS et les équilibreurs de charge logiciels, doivent exécuter le système d’exploitation Azure Stack HCI.

Microsoft fournit la configuration minimale requise pour le calcul, le stockage et les logiciels pour les hôtes physiques et les machines virtuelles de l’infrastructure SDN. Toutefois, gardez à l’esprit que le dimensionnement et les besoins en ressources de votre infrastructure dépendent en fin de compte des exigences des machines virtuelles de charge de travail de locataire. Heureusement, le SDN facilite la mise à l’échelle, ce qui vous permet de déployer des instances supplémentaires de services basés sur la virtualisation des fonctions réseau selon vos besoins. En fonction des capacités matérielles de votre cluster Azure Stack HCI, vous avez également la possibilité d’ajouter des nœuds de cluster physiques.

Notes

Le SDN n’est pas pris en charge sur les clusters étendus (multisites).

Contrôleur réseau

Pour préparer le déploiement du contrôleur de réseau dans un environnement AD DS (Active Directory Domain Services), vous devez configurer l’authentification et l’autorisation basées sur Kerberos. Cette autorisation permet au contrôleur de réseau de gérer tous les aspects pertinents de l’infrastructure SDN. Les autorisations requises sont affectées automatiquement pendant le déploiement du contrôleur de réseau.

Notes

Dans les déploiements à haut niveau de disponibilité, le contrôleur de réseau forme un cluster constitué de trois machines virtuelles ou plus, chacune s’exécutant sur un nœud de cluster Azure Stack HCI distinct. Toutes les instances de contrôleur de réseau sont jointes au même domaine AD DS.

Logical networks

Pour prendre en charge les services basés sur la virtualisation de fonction réseau, vous devez approvisionner les réseaux logiques requis, notamment :

  • Réseaux logiques de fournisseur de gestion et HNV
  • Réseaux logiques d’équilibreur de charge logiciel et de passerelle

Réseaux logiques de fournisseur de gestion et HNV

Tous les nœuds de cluster Azure Stack HCI doivent avoir accès au réseau logique de gestion et à celui du fournisseur HNV. Pour la planification des adresses IP, chaque nœud de cluster Azure Stack HCI doit avoir au moins une adresse IP affectée à partir du réseau logique de gestion. Pour le réseau de gestion, vous pouvez attribuer des adresses IP de manière statique ou via le protocole DHCP (Dynamic Host Configuration Protocol). La pile SDN affecte automatiquement des adresses IP pour le réseau logique du fournisseur HNV pour les nœuds de cluster Azure Stack HCI individuels. Les adresses sont fournies à partir d’un pool d’adresses IP spécifié via et géré par le contrôleur de réseau.

Le nom DNS REST du contrôleur de réseau doit être configuré pour autoriser les mises à jour DNS dynamiques. Toutes les machines virtuelles du contrôleur de réseau doivent être autorisées à créer et à mettre à jour l’enregistrement DNS.

Notes

Il existe d’autres considérations relatives à la configuration du réseau logique qui dépendent de l’utilisation de fonctionnalités comme les VLAN et SET (Switch Embedded Teaming). Vous pouvez en apprendre plus sur ces considérations dans la documentation Microsoft référencée dans l’unité de synthèse de ce module.

Réseaux logiques d’équilibreur de charge logiciel et de passerelle

Vous devez provisionner des réseaux logiques supplémentaires pour prendre en charge les déploiements des machines virtuelles multiplexeurs d’équilibreur de charge logiciel et de passerelle RAS. Pour chacun d’eux, vous devez identifier les préfixes IP, les ID de réseau local virtuel et les adresses IP de passerelle.

  • Réseau logique d’adresses IP virtuelles publiques. Ce réseau est destiné aux affectations d’adresses IP virtuelles qui représentent des adresses IP front-end. Ces adresses IP sont utilisées par les clients externes pour accéder aux ressources au sein de réseaux virtuels. Par exemple, les équilibreurs de charge publics ou l’adresse IP virtuelle front-end de la passerelle VPN de site à site. Dans les faits, son espace d’adressage IP doit être routable en dehors de l’environnement de SDN. Vous n’avez pas besoin de préconfigurer ce réseau dans vos commutateurs ou routeurs physiques, ni de l’attribuer à un réseau local virtuel.
  • Réseau logique d’adresses IP virtuelles privées. Ce réseau est destiné à l’affectation d’adresses IP virtuelles accessibles par les charges de travail de locataire Azure Stack HCI. Il n’a donc pas besoin d’être routable en dehors de l’environnement de SDN. Vous n’avez pas besoin de préconfigurer ce réseau dans vos commutateurs ou routeurs physiques, ni de l’attribuer à un réseau local virtuel.
  • Réseau logique d’adresses IP virtuelles GRE. Le réseau d’IP virtuelles GRE est utilisé exclusivement pour définir des adresses IP virtuelles qui sont affectées aux machines virtuelles de passerelle pour les connexions GRE de site à site. Vous n’avez pas besoin de préconfigurer ce réseau dans vos commutateurs ou routeurs physiques, ni de l’attribuer à un réseau local virtuel.

Configuration de routage

Pour permettre la connectivité entre les réseaux logiques d’adresses IP virtuelles publiques et les clients externes, il est nécessaire de publier les informations de routage du multiplexeur d’équilibreur de charge logiciel ou de la passerelle RAS sur un homologue BGP externe. En effet, vous devez configurer un homologue BGP sur le routeur utilisé par l’infrastructure SDN pour recevoir des itinéraires pour les réseaux logiques d’adresses IP virtuelles publiés par les multiplexeurs de l’équilibreur de charge logiciel et les passerelles RAS.

Les ordinateurs qui sont configurés pour se connecter à plusieurs réseaux, comme les nœuds de cluster Azure Stack HCI et les machines virtuelles de passerelle, ne doivent avoir qu’une seule passerelle par défaut configurée. Cette passerelle doit résider sur le réseau de gestion pour les nœuds de cluster Azure Stack HCI, les machines virtuelles du contrôleur de réseau et les machines virtuelles du multiplexeur de l’équilibreur de charge logiciel. Pour les machines virtuelles de passerelle, cette passerelle doit résider sur le réseau du fournisseur HNV.

Réseaux physiques

D’autres prérequis s’appliquent aux commutateurs et aux routeurs. Ces conditions préalables doivent prendre en charge les paramètres d’unité de transmission maximale (MTU) désignés, les fonctionnalités de contrôle de lien, la haute disponibilité et la redondance, ainsi que les protocoles de routage et de marquage de réseau local virtuel (VLAN).

Notes

Des exemples de fichiers de configuration pour les modèles de commutateur et les fournisseurs les plus courants sont disponibles dans le référentiel GitHub Microsoft SDN.