Qu’est-ce que SDN Multisite ?

Article
11/23/2024

S’applique à : Azure Local, version 23H2

S'applique à Windows Server 2025

Cet article fournit une vue d’ensemble de SDN Multisite, y compris ses avantages et ses limitations actuelles. Vous pouvez l’utiliser comme guide pour vous aider à concevoir votre topologie réseau et votre plan de récupération d’urgence.

SDN Multisite vous permet d’étendre les fonctionnalités du SDN traditionnel déployé à différents emplacements physiques. SDN Multisite permet une connectivité native de couche 2 et de couche 3 entre différents emplacements physiques pour les charges de travail virtualisées. Dans cet article, toutes les références aux sites signifient des emplacements physiques.

Pour plus d’informations sur la gestion de SDN Multisite, consultez Gérer SDN Multisite pour Azure Local.

Avantages

Voici les avantages de l’utilisation de SDN Multisite :

Système de gestion des stratégies unifié. Avec les réseaux virtuels partagés et les configurations de stratégie, vous pouvez gérer et configurer vos réseaux multisite à partir de n’importe quel site.
Migration transparente de la charge de travail. Migrez en toute transparence les charges de travail entre les sites physiques sans avoir à reconfigurer les adresses IP ou les groupes de sécurité réseau (NSG).
Accessibilité automatique aux nouvelles machines virtuelles. Obtenez l’accessibilité automatique aux machines virtuelles nouvellement créées sur des réseaux virtuels, ainsi qu’une facilité de gestion automatique à l’un de leurs groupes de sécurité réseau associés sur vos emplacements physiques.

Limites

La fonctionnalité multisite SDN présente actuellement quelques limitations :

Pris en charge uniquement entre deux sites.
Les sites doivent être connectés via un réseau privé, car la prise en charge du chiffrement pour les sites connectés via Internet n’est pas fournie.
L’équilibrage de charge interne n’est pas pris en charge entre sites.

Peering multisite

Le peering multisite nécessite un peering entre les sites, qui est lancé comme le peering de réseaux virtuels. Une connexion est automatiquement lancée sur les deux sites via Windows Admin Center. Une fois qu’une connexion est établie, le peering réussit. Pour obtenir des instructions sur l’établissement d’un peering, consultez Établir un peering.

Les sections suivantes décrivent les rôles de chaque site dans un environnement multisite et la façon dont les ressources sont gérées et synchronisées entre les sites.

Rôles de site principal et secondaire

Dans un environnement SDN multisite, un site est désigné comme principal et l’autre comme secondaire. Le site principal gère la synchronisation des ressources. Pendant le peering multisite, le site principal est automatiquement sélectionné, que vous pouvez modifier ultérieurement à l’aide de Windows Admin Center.

Gestion des ressources

Si le site principal est inaccessible, les ressources globales et les ressources nécessitant une validation globale ou des allocations d’adresses client globales ne peuvent pas être mises à jour via le site secondaire. Toutefois, d’autres ressources locales peuvent être mises à jour via le site secondaire.

Voici quelques exemples de ressources nécessitant une validation globale :
- Pools MAC.
- Pool réseau/IP logique.
Voici quelques exemples d’allocations d’autorité de certification globales :
- Équilibrage de charge interne pour le sous-réseau virtuel. Actuellement, cela n’est pas pris en charge par le biais de Multisite.
- Connexions de passerelle pour le sous-réseau virtuel.
Si le site secondaire est inaccessible, les ressources peuvent être mises à jour via le site principal. Toutefois, le site secondaire peut avoir des ressources obsolètes jusqu’à ce que la connectivité soit restaurée. Une fois la connectivité restaurée, la synchronisation reprend.
Si le site principal tombe en panne, vous pouvez désigner votre site secondaire comme nouveau site principal pour effectuer des mises à jour de vos groupes de sécurité réseau et réseaux virtuels. Toutefois, toute synchronisation de données en attente à partir de l’ancien site principal est perdue. Pour résoudre ce problème, appliquez ces mêmes modifications sur le nouveau site principal une fois que l’ancien site principal est de nouveau en ligne. Toutefois, il peut également entraîner des conflits d’allocation d’autorité de certification globaux.

Synchronisation des ressources

Lorsque vous activez SDN Multisite, toutes les ressources de chaque site ne sont pas synchronisées sur tous les sites. Voici les listes de ressources qui sont synchronisées et qui restent non synchronisées.

Ressources synchronisées

Ces ressources sont synchronisées sur tous les sites après l’établissement du peering. Vous pouvez mettre à jour ces ressources à partir de n’importe quel site, qu’elle soit primaire ou secondaire. Toutefois, le site principal est chargé de s’assurer que ces ressources sont appliquées et synchronisées entre les sites. Les instructions et les instructions relatives à la gestion de ces ressources restent les mêmes que dans un environnement SDN à site unique.
- Réseaux virtuels. Pour obtenir des instructions sur la gestion des réseaux virtuels, consultez Gérer les réseaux virtuels de locataire. Notez que les réseaux logiques ne sont pas synchronisés entre les sites. Toutefois, si vos réseaux virtuels référencent un réseau logique, le réseau logique portant le même nom doit exister sur les deux sites.
- Groupes de sécurité réseau (NSG) . Pour obtenir des instructions sur la configuration du groupe de sécurité réseau avec Windows Admin Center et PowerShell, consultez Configurer des groupes de sécurité réseau avec Windows Admin Center et configurer des groupes de sécurité réseau avec PowerShell.
- Routage défini par l’utilisateur. Pour obtenir des instructions sur l’utilisation du routage défini par l’utilisateur, consultez Utiliser des appliances virtuelles réseau sur un réseau virtuel.

Ressources synchronisées

Ces ressources sont synchronisées sur tous les sites après l’établissement du peering. Vous pouvez mettre à jour ces ressources à partir de n’importe quel site, qu’elle soit primaire ou secondaire. Toutefois, le site principal est chargé de s’assurer que ces ressources sont appliquées et synchronisées entre les sites. Les instructions et les instructions relatives à la gestion de ces ressources restent les mêmes que dans un environnement SDN à site unique.
- Réseaux virtuels. Pour obtenir des instructions sur la gestion des réseaux virtuels, consultez Gérer les réseaux virtuels de locataire. Notez que les réseaux logiques ne sont pas synchronisés entre les sites. Toutefois, si vos réseaux virtuels référencent un réseau logique, le réseau logique portant le même nom doit exister sur les deux sites.
- Groupes de sécurité réseau (NSG) . Pour obtenir des instructions sur la configuration du groupe de sécurité réseau avec Windows Admin Center et PowerShell, consultez Configurer des groupes de sécurité réseau avec Windows Admin Center et configurer des groupes de sécurité réseau avec PowerShell.
- Routage défini par l’utilisateur. Pour obtenir des instructions sur l’utilisation du routage défini par l’utilisateur, consultez Utiliser des appliances virtuelles réseau sur un réseau virtuel.

Ressources non synchronisées

Ces ressources ne sont pas synchronisées après l’établissement du peering :
- Stratégies d’équilibrage de charge.
- Adresses IP virtuelles (IP virtuelles).
- Stratégies de passerelle.
- Réseaux logiques. Bien que les réseaux logiques ne soient pas synchronisés entre les sites, les pools IP sont vérifiés pour se chevaucher et ce chevauchement n’est pas autorisé.
Ces stratégies sont créées sur le site local et, si vous souhaitez les mêmes stratégies sur l’autre site, vous devez les créer manuellement. Si vos machines virtuelles principales pour les stratégies d’équilibrage de charge se trouvent sur un site unique, la connectivité via SLB fonctionne correctement sans aucune configuration supplémentaire. Toutefois, si vous attendez que les machines virtuelles principales passent d’un site à l’autre, par défaut, la connectivité fonctionne uniquement s’il existe des machines virtuelles principales derrière une adresse IP virtuelle sur le site local. Si toutes les machines virtuelles principales se déplacent vers un autre site, la connectivité via cette adresse IP virtuelle échoue.

Multisite permet aux machines virtuelles sur différents sites avec le SDN déployé de communiquer sur le même sous-réseau sans avoir à configurer les connexions de passerelle SDN. Cela simplifie la topologie réseau et réduit le besoin de machines virtuelles et de sous-réseaux supplémentaires. Le chemin des données entre les machines virtuelles sur différents sites s’appuie sur l’infrastructure physique sous-jacente.

Les scénarios suivants comparent la façon dont la communication de machine virtuelle est établie entre deux sites physiques dans une configuration SDN traditionnelle et dans une configuration multisite SDN.

Communication de machine virtuelle vers une machine virtuelle sans SDN Multisite

Dans une configuration traditionnelle avec SDN déployé sur deux sites physiques, vous devez établir une connexion de passerelle L3 ou GRE pour la communication intersite. Vous devez également fournir davantage de sous-réseaux pour vos applications. Par exemple, si chaque site héberge des applications frontales, vous allouez des plages de sous-réseaux distinctes comme 10.1/16 et 10.6/16. En outre, lorsque vous configurez une connexion de passerelle, vous devez également allouer davantage de machines virtuelles pour vos machines virtuelles de passerelle et les gérer par la suite.

Communication de machine virtuelle à machine virtuelle avec SDN Multisite

Avec SDN Multisite sur deux emplacements physiques, vous pouvez disposer d’une connectivité de couche 2 native pour la communication intersite. Cela vous permet d’avoir une plage de sous-réseaux unique pour vos applications qui s’étendent sur les deux emplacements, ce qui élimine la nécessité de configurer la connexion de passerelle SDN. Par exemple, comme illustré dans le diagramme suivant, les applications frontales sur les deux emplacements peuvent utiliser le même sous-réseau, tel que 10.1/16, au lieu de conserver deux éléments distincts. Avec cette configuration, le flux de données d’une machine virtuelle à une autre s’appuie uniquement sur votre infrastructure physique sous-jacente, ce qui évite de devoir parcourir une autre machine virtuelle de passerelle SDN.

Équilibreurs de charge logiciels et leurs limitations

Actuellement, les équilibreurs de charge logiciel sont des ressources locales pour chacun de vos sites physiques. Cela signifie que les stratégies et configurations d’équilibrage de charge ne sont pas synchronisées entre les sites via Multisite. Gardez cela à l’esprit lors de la migration de machines virtuelles d’un emplacement vers un autre dans une configuration multisite SDN.

Équilibrage de charge dans SDN Multisite : exemple de scénario

Les sections suivantes expliquent l’équilibrage de charge dans Multisite via un exemple de scénario, illustrant à la fois sans et avec la migration de machines virtuelles de charge de travail. Supposons que vous ayez deux instances locales Azure avec SDN Multisite activé, chacune avec son propre infrastructure SDN déployée et configurée. Dans ce scénario, un client souhaite atteindre VM1 avec l’adresse IP 10.0.0.5 et l’adresse IP virtuelle 11.0.0.5.

Équilibrage de charge dans SDN Multisite sans migrer des machines virtuelles de charge de travail

Dans SDN Multisite, s’il n’y a pas de migration de machine virtuelle entre les emplacements, les paquets de données sont transférés comme d’habitude, comme d’habitude, à l’instar de la configuration SDN traditionnelle. L’animation suivante illustre le chemin des données de la machine cliente vers VM1 via SLB MUX1 dans le cluster 2.

Équilibrage de charge dans SDN Multisite avec migration de machines virtuelles de charge de travail

Si vous décidez de migrer une machine virtuelle ou toutes les machines virtuelles derrière l’adresse IP virtuelle vers l’autre site, vous pouvez rencontrer des situations où la machine virtuelle que vous essayez d’atteindre devient inaccessible sur l’adresse IP virtuelle, en fonction de son emplacement. Cela se produit, car les ressources d’équilibreur de charge sont locales pour chaque instance locale Azure. À mesure que les machines virtuelles de charge de travail se déplacent, les configurations sur les MUX ne sont pas globales, ce qui laisse l’autre site sans connaissance des migrations. L’animation suivante illustre la migration des machines virtuelles du cluster 2 vers le cluster 1 et la façon dont le chemin du paquet de données échoue après la migration.

Pour contourner cette limitation, vous pouvez utiliser l’équilibreur de charge externe qui vérifie la disponibilité des machines virtuelles principales sur chaque site et achemine le trafic en conséquence. Consultez Utiliser l’équilibreur de charge externe dans Multisite avec la migration de machines virtuelles de charge de travail.

Utiliser l’équilibreur de charge externe dans Multisite avec la migration de machines virtuelles de charge de travail

Vous pouvez activer un équilibreur de charge externe pour vérifier s’il existe des machines virtuelles principales derrière un équilibreur de charge sur l’un de vos sites. S’il n’existe aucune machine virtuelle back-end derrière un équilibreur de charge, l’adresse IP virtuelle de l’expérience utilisateur n’est pas annoncée jusqu’à l’équilibreur de charge externe et toute sonde d’intégrité envoyée échoue. Cet équilibreur de charge externe garantit la connectivité aux charges de travail, même lorsque les machines virtuelles passent d’un site à un autre.

Toutefois, si le déploiement d’un équilibreur de charge externe n’est pas réalisable, utilisez la solution d’équilibrage de charge logicielle, comme décrit dans l’équilibrage de charge dans SDN Multisite sans migrer les machines virtuelles de charge de travail tant que vous n’avez pas de machines virtuelles de charge de travail migrées.

Passerelles et leurs limitations

SDN multisite ne synchronise pas les ressources locales, telles que les connexions de passerelle entre les sites. Chaque site possède ses propres machines virtuelles de passerelle et connexions de passerelle. Lorsqu’une machine virtuelle de charge de travail est créée ou migrée vers un site, elle obtient la configuration de passerelle locale comme les itinéraires de passerelle. Si vous créez une connexion de passerelle pour un réseau virtuel particulier sur un site, les machines virtuelles de ce site perdent la connectivité de passerelle lors de la migration vers l’autre site. Pour que les machines virtuelles conservent la connectivité de passerelle lors de la migration, vous devez configurer une connexion de passerelle distincte pour le même réseau virtuel sur l’autre site.

Étapes suivantes

Gérer SDN Multisite pour Azure Local

Partager via

Qu’est-ce que SDN Multisite ?

Avantages

Limites