Conception d’un plan de reprise d’activité après sinistre
Virtual WAN vous permet d’agréger, de connecter, de gérer de manière centralisée et de sécuriser tous vos déploiements globaux. Vos déploiements globaux peuvent inclure toutes les combinaisons de branches, de points de présence (PoP), d’utilisateurs privés, de bureaux, de réseaux virtuels Azure et d’autres déploiements multicloud. Vous pouvez utiliser SD-WAN, un VPN de site à site, un VPN de point à site et ExpressRoute pour connecter vos différents sites à un hub virtuel. Si vous avez plusieurs hubs virtuels, ces hubs sont tous connectés en un maillage complet dans un déploiement Virtual WAN standard.
Dans cet article, nous allons voir comment architecturer les différents types d’options de connectivité network-as-a-service pris en charge par Virtual WAN pour la reprise d’activité après sinistre.
Options de connectivité network-as-a-service de Virtual WAN
Virtual WAN prend en charge les options de connectivité back-end suivantes :
- Connectivité de l’utilisateur distant
- Branche/Office/SD-WAN/VPN de site à site
- Connectivité privée (peering privé ExpressRoute)
Pour chacune de ces options de connectivité, Virtual WAN déploie un ensemble distinct d’instances de passerelle au sein d’un hub virtuel.
Virtual WAN est fondamentalement conçu pour offrir une solution d’agrégation réseau de classe opérateur et à haute disponibilité. Pour garantir une haute disponibilité, Virtual WAN instancie plusieurs instances quand chacun de ces différents types de passerelles est déployé dans un hub Virtual WAN. Pour en savoir plus sur la haute disponibilité avec ExpressRoute, consultez Conception pour la haute disponibilité avec ExpressRoute.
Avec la passerelle VPN de point à site, au moins deux instances sont déployées. Avec la passerelle VPN point à site, vous choisissez la capacité de débit agrégée des passerelles de point à site et plusieurs instances sont automatiquement approvisionnées pour vous. Vous choisissez la capacité agrégée en fonction du nombre de clients ou d’utilisateurs que vous prévoyez de connecter au hub virtuel. Du point de vue de la connectivité client, les instances de la passerelle VPN de point à site sont cachées derrière le nom de domaine complet (FQDN) de la passerelle.
Avec la passerelle VPN de site à site, deux instances sont déployées dans un hub virtuel. Chaque instance de la passerelle est déployée avec son propre ensemble d’adresses IP publiques et privées. La capture d’écran suivante montre les adresses IP qui sont associées aux deux instances d’une configuration de passerelle VPN de site à site. Ainsi, les deux instances fournissent deux points de terminaison de tunnels indépendants pour l’établissement d’une connectivité VPN de site à site à partir de vos sites de succursale. Pour optimiser la haute disponibilité, consultez Sélection du chemin d’accès Azure sur plusieurs liens ISP.
L’amélioration de la haute disponibilité de votre architecture réseau est une première étape essentielle pour garantir la continuité d’activité et la reprise d’activité (BCDR). Comme nous l’avons mentionné précédemment, après avoir parlé de la haute disponibilité, nous allons maintenant vous expliquer comment architecturer votre connectivité réseau Virtual WAN pour la continuité d’activité et la reprise d’activité (BCDR).
Nécessité de la conception d’un plan de reprise d’activité
Un sinistre peut se produire partout et à tout moment. Il peut survenir dans une région ou un réseau de fournisseur cloud, dans un réseau de fournisseur de services ou dans un réseau local. Il est difficile d’exclure tout impact d’un service cloud ou réseau dans une région en raison de certains facteurs comme les catastrophes naturelles, les erreurs humaines, les guerres, les actes de terrorisme et les configurations incorrectes. Pour garantir la continuité des applications vitales pour l’entreprise, il est donc essentiel d’avoir un plan de reprise d’activité. Pour concevoir un plan complet de reprise d’activité, vous devez identifier toutes les dépendances qui pourraient s’arrêter dans votre chemin de communication de bout en bout, et créer une redondance sans chevauchement pour chaque dépendance.
Que vous exécutiez vos applications stratégiques dans une région Azure, localement ou n’importe où ailleurs, vous pouvez utiliser une autre région Azure comme site de basculement. Les articles suivants abordent la reprise d’activité du point de vue des applications et de l’accès front-end :
Problèmes liés à l’utilisation de la connectivité redondante
Quand vous interconnectez le même ensemble de réseaux à l’aide de plusieurs connexions, vous introduisez des chemins parallèles entre les réseaux. Quand ils ne sont pas correctement conçus, les chemins parallèles peuvent engendrer un routage asymétrique. Si le chemin comporte des entités avec état (par exemple, NAT, pare-feu), le routage asymétrique risque de bloquer le flux de trafic. En règle générale, sur une connectivité privée, vous n’avez pas ou ne rencontrez pas d’entités avec état (NAT ou pare-feu). Ainsi, le routage asymétrique sur la connectivité privée ne bloque pas nécessairement le flux de trafic.
Toutefois, si vous équilibrez la charge du trafic entre des chemins parallèles géoredondants, vous pouvez observer des performances réseau incohérentes en raison du chemin physique différent des connexions parallèles. Dans notre plan de reprise d’activité, nous devons donc tenir compte des performances du trafic réseau dans l’état stable (sans échec) et dans un état de défaillance.
Redondance des accès réseau
La plupart des services SD-WAN (solutions managées ou autres) fournissent une connectivité réseau via plusieurs types de transport (par exemple, haut débit Internet, MPLS, LTE). Pour prévenir les défaillances réseau dues au transport, optez pour une connectivité via plusieurs transports réseau. Dans un scénario d’utilisation locale, vous pouvez envisager d’utiliser un réseau mobile comme emplacement de sauvegarde pour la connectivité réseau haut débit.
Si la connectivité réseau via différents types de transport n’est pas possible, choisissez une connectivité réseau via plusieurs fournisseurs de services. Si vous obtenez la connectivité via plusieurs fournisseurs de services, assurez-vous que les fournisseurs de services utilisent des réseaux d’accès indépendants et sans chevauchement.
Considérations sur la connectivité des utilisateurs distants
La connectivité utilisateur distante est établie à l’aide d’un VPN point à site entre un appareil final vers un réseau. À la suite d’une défaillance réseau, l’appareil final s’arrête et tente ensuite de rétablir le tunnel VPN. Par conséquent, pour un VPN de point à site, votre plan de conception de la reprise d’activité doit avoir pour but de réduire le temps de reprise après une défaillance. La redondance réseau suivante contribue à réduire ce temps de reprise. Selon que les connexions ont une importance plus ou moins vitale, vous pouvez choisir toutes ces options ou seulement certaines d’entre elles.
- Redondance des accès réseau (voir plus haut).
- Gestion d’un hub virtuel redondant pour les points de terminaison du VPN de point à site. Lorsque vous utilisez plusieurs hubs virtuels avec des passerelles de point à site, VWAN fournit un profil mondial dans lequel sont listés tous les points de terminaison de point à site. Avec le profil mondial, vos appareils finaux peuvent se connecter au hub virtuel disponible le plus proche qui offre les meilleures performances réseau. Si tous vos déploiements Azure se trouvent dans la même région et que les appareils finaux qui s’y connectent se trouvent à proximité de cette région, vous pouvez avoir des hubs virtuels redondants dans la région. Si votre déploiement et vos appareils finaux sont répartis entre plusieurs régions, vous pouvez déployer un hub virtuel avec une passerelle de point à site dans chacune des régions sélectionnées. Virtual WAN dispose d’un gestionnaire de trafic intégré qui sélectionne automatiquement le meilleur hub pour la connectivité des utilisateurs distants.
Le diagramme suivant illustre le concept de la gestion de hubs virtuels redondants avec leur passerelle de point à site respective dans une région.
Dans le diagramme ci-dessus, les lignes vertes pleines représentent les connexions VPN de point à site principales et les lignes jaunes en pointillés indiquent les connexions de secours (sauvegarde). Le profil mondial des points de terminaison de point à site dans VWAN sélectionne les connexions principales et de secours en fonction des performances du réseau. Pour plus d’informations sur le profil mondial, consultez Télécharger un profil mondial pour les clients VPN utilisateurs.
Considérations relatives au VPN de site à site
Pour les besoins de notre discussion, prenons comme exemple la connexion VPN de site à site qui est illustrée dans le diagramme ci-dessous. Pour établir une connexion VPN de site à site avec des tunnels « actif-actif » à haute disponibilité, consultez Tutoriel : Créer une connexion de site à site à l’aide d’Azure Virtual WAN.
Notes
Pour faciliter la compréhension des concepts abordés dans la section, nous ne reparlerons pas de la fonctionnalité de haute disponibilité de la passerelle VPN de site à site qui vous permet de créer deux tunnels vers deux points de terminaison différents pour chaque liaison VPN que vous configurez. Cependant, au moment de déployer l’architecture suggérée dans la section, pensez à configurer les deux tunnels pour chacune des liaisons établies.
Topologie à liaisons multiples
Pour prévenir les défaillances de l’équipement CPE (Customer Premises Equipment) VPN sur un site de succursale, vous pouvez configurer des liaisons VPN parallèles vers une passerelle VPN à partir d’appareils CPE parallèles sur le site de succursale. Pour vous protéger contre les défaillances réseau d’un fournisseur de services sur le dernier kilomètre avant le site de succursale, vous pouvez configurer plusieurs liaisons VPN sur un autre réseau de fournisseur de services. Le diagramme suivant montre plusieurs liaisons VPN qui partent de deux CPE différents sur un site de succursale et qui se terminent sur la même passerelle VPN.
Vous pouvez configurer jusqu’à quatre liaisons vers un site de succursale à partir d’une passerelle VPN d’un hub virtuel. Quand vous configurez une liaison vers un site de succursale, vous pouvez identifier le fournisseur de services et la vitesse de débit associés à cette liaison. Lorsque vous configurez plusieurs liaisons parallèles entre un site de succursale et un hub virtuel, par défaut, la passerelle VPN équilibre la charge du trafic entre les liaisons parallèles. L’équilibrage de la charge du trafic s’effectue selon la stratégie de routage multichemin à coût égal (ECMP) pour chaque flux.
Topologie à liaisons multiples et avec plusieurs hubs
La topologie à liaisons multiples protège contre les défaillances des appareils CPE et celles du réseau du fournisseur de services sur le site de succursale local. La topologie à liaisons multiples et avec plusieurs hubs peut également être utile pour prévenir les temps d’arrêt d’une passerelle VPN dans un hub virtuel. Le diagramme suivant montre la topologie, dans laquelle plusieurs hubs virtuels sont configurés sous une instance Virtual WAN au sein d’une région :
Dans la topologie ci-dessus, la latence entre les régions Azure sur la connexion entre les hubs est insignifiante. Vous pouvez donc utiliser toutes les connexions VPN de site à site entre le hub local et les deux hubs virtuels dans l’état actif-actif en répartissant les réseaux virtuels spoke entre les différents hubs. Dans cette topologie, par défaut, le trafic entre le réseau local et un réseau virtuel spoke passe directement par le hub virtuel auquel le réseau virtuel spoke est connecté dans l’état stable, et utilise un autre hub virtuel comme secours uniquement dans un état de défaillance. Le trafic transite par le hub connecté directement dans l’état stable, car les routes BGP exposées par le hub connecté directement ont un chemin AS plus court que le hub de secours.
La topologie à liaisons multiples et avec plusieurs hubs protège et assure la continuité de l’activité dans la plupart des scénarios de défaillance. Toutefois, si une grave défaillance provoque l’arrêt de toute la région Azure, vous avez besoin d’une « topologie à liaisons multiples entre plusieurs régions » pour reprendre l’activité.
Topologie à plusieurs liaisons entre plusieurs régions
La topologie à plusieurs liaisons entre plusieurs régions protège contre les défaillances graves dans une région entière, et complète les protections de la topologie à plusieurs liaisons et avec plusieurs hubs dont nous avons parlé précédemment. Le diagramme suivant illustre la topologie à plusieurs liaisons entre plusieurs régions. Les hubs virtuels dans différentes régions peuvent être configurés sous la même instance Virtual WAN.
Du point de vue de l’ingénierie du trafic, vous devez prendre en considération une différence importante dans le scénario où vous avez des hubs redondants dans une région et le hub de secours dans une autre région. La différence est la latence résultant de la distance physique entre les régions principale et secondaire. Par conséquent, vous souhaiterez peut-être déployer vos ressources de service stables dans la région la plus proche des utilisateurs finaux ou des succursales, et utiliser la région distante uniquement pour la sauvegarde.
Si vos succursales locales sont réparties dans plusieurs régions Azure, la topologie à plusieurs liaisons entre plusieurs régions est plus performante pour répartir la charge et optimiser l’expérience réseau dans l’état stable. Le diagramme suivant illustre la topologie à plusieurs liaisons entre plusieurs régions, avec des succursales dans des régions différentes. Dans ce scénario, la topologie offre également une solution efficace pour la continuité d’activité et la reprise d’activité (BCDR).
Considérations relatives à ExpressRoute
Les considérations relatives à la reprise d’activité pour le peering privé ExpressRoute sont traitées dans Conception d’un plan de reprise d’activité avec le peering privé ExpressRoute. Comme cela est indiqué, les concepts décrits dans cet article s’appliquent également aux passerelles ExpressRoute créées dans un hub virtuel. L’utilisation d’un hub virtuel redondant dans la région, comme dans le diagramme suivant, est la seule amélioration de topologie recommandée dans Considérations relatives aux réseaux locaux petits ou moyens.
Dans le diagramme ci-dessus, le circuit ExpressRoute 2 se termine sur une passerelle ExpressRoute distincte dans un deuxième hub virtuel dans la région.
Étapes suivantes
Dans cet article, nous avons abordé la conception d’un plan de reprise d’activité avec Virtual WAN. Les articles suivants abordent la reprise d’activité du point de vue des applications et de l’accès front-end :
Pour créer une connectivité de point à site à Virtual WAN, consultez Tutoriel : Créer une connexion VPN utilisateur à l’aide d’Azure Virtual WAN. Pour créer une connectivité de site à site à Virtual WAN, consultez Tutoriel : Créer une connexion de site à site à l’aide d’Azure Virtual WAN. Pour associer un circuit ExpressRoute à Virtual WAN, consultez Tutoriel : Créer une association ExpressRoute à l’aide d’Azure Virtual WAN.