Options de géo-redondance pour le Network Edge
Ce document traite des considérations de conception pour toute personne intéressée par des solutions géo-redondantes sur Network Edge. Nous examinerons quelques cas d'utilisation en commençant par un exemple simple et en ajoutant progressivement d'autres options. Il n'existe pas de solution unique qui convienne à tout le monde ; vous devrez prendre les décisions qui correspondent le mieux à vos besoins.
Routage de nuage à nuage
Dans ce cas d'utilisation courant de Network Edge, les dispositifs de Network Edge assurent simplement le routage entre deux fournisseurs de services cloud (CSP).

Vous avez la possibilité d'ajouter une résilience locale en ajoutant un autre routeur Network Edge et des connexions redondantes aux CSP dans le même métro. La redondance locale protège contre une défaillance matérielle locale puisque les dispositifs redondants sont placés dans des plans de calcul différents. Vous avez également la possibilité de créer des circuits virtuels redondants à partir des dispositifs Network Edge redondants vers les CSP en fonction de leur tolérance au risque.

Cependant, les VNF et les connexions redondantes localement ne protègent pas contre une panne qui affecte tous les appareils locaux, comme un incendie qui pourrait mettre hors service des appareils pendant une période prolongée, ou même une mise à niveau de l'infrastructure. Pour ce niveau de résilience, la géo-redondance doit être envisagée. En se basant sur le cas d'utilisation ci-dessus, un routeur Network Edge supplémentaire est déployé dans un autre métro NE. En règle générale, ce nouveau dispositif devrait se trouver dans la même région, mais ce n'est pas une obligation car la Fabric d'Equinix permet la connectivité entre les métros du monde entier.
La redondance locale combinée à la géo-redondance offre une protection maximale contre les défaillances matérielles locales dans un métro et contre les problèmes (incendie, catastrophe naturelle, etc.) qui affectent tous les appareils dans le métro.
On-Ramp Cloud avec le routage Cloud-to-Cloud
Dans ce cas d'utilisation, le trafic SD-WAN des succursales est agrégé et acheminé vers les nuages. Comme le cas d'utilisation précédent, il prévoit également un routage de nuage à nuage.

Les clients déploient généralement des rampes d'agrégation SD-WAN sur plusieurs sites afin d'améliorer l'expérience de l'utilisateur en réduisant la latence tout en évitant d'avoir à transporter le trafic sur de longues distances.

En plus d'offrir une meilleure expérience utilisateur, cette architecture peut également permettre une géo-redondance : en cas de panne affectant l'ensemble du déploiement de la Silicon Valley, le trafic SD-WAN sera réacheminé vers Ashburn. Le trafic multi-cloud peut toujours avoir lieu via le métro disponible.
Si vous souhaitez une géo-redondance et que vous n'avez qu'un seul métro opérationnel (ou si vous avez deux ou plusieurs métros et que vous souhaitez en ajouter un nouveau), une option consiste à refléter le(s) métro(s) existant(s). Dans cet exemple, un nouveau site est ajouté à Chicago.

Equinix propose plusieurs options pour la connectivité de la couche d'accès. Par exemple, vous pouvez utiliser un port Fabric distant (également appelé BYOC) pour vous connecter à un fournisseur de services dans la Silicon Valley. Pour fournir une connectivité de couche d'accès au site géo-redondant de Chicago, vous disposez de plusieurs options :
-
Utiliser un nouveau fournisseur de réseau local dans le(s) nouveau(x) métro(x) - soit par BYOC, soit par un fournisseur déjà présent sur la Fabric. Avec le BYOC, vous vous connectez à un fournisseur de réseau local sur la Fabric via un port distant. Ce processus peut prendre plusieurs jours.
-
Créer des VC point à point entre le nouveau métro (Chicago) et un site existant (Silicon Valley). En règle générale, vous choisissez cette option comme solution géo-redondante temporaire dans des situations telles qu'une maintenance planifiée affectant le métro principal, ou comme solution de "secours à froid" dans laquelle le métro géo-redondant n'existe que dans le cas où le métro principal n'est pas disponible. Cette solution n'est pas aussi courante, car il faudra probablement rediriger manuellement le trafic du métro principal vers le métro redondant. Des préoccupations supplémentaires concernant les exigences opérationnelles pour la gestion de l'espace d'adressage, les flux d'applications et les mécanismes existants pour maintenir la continuité du réseau rendent cette solution plus complexe d'un point de vue opérationnel.
-
Utiliser la connectivité multipoint à multipoint pour partager la connexion du fournisseur de services entre les métros. Cette méthode est particulièrement utile pour créer une topologie entièrement maillée entre plusieurs métros. L'avantage de cette approche est que plusieurs connexions sont construites pour étendre la connexion du fournisseur à plusieurs métros. Il faut tenir compte des limites de l'espace d'adressage disponible sur les circuits existants et des options proposées par votre fournisseur pour partager la connexion sur la Fabric Equinix. En raison des exigences fixées par le fournisseur, vous devrez évaluer vos options car elles varient d'un fournisseur à l'autre. Pour une résilience maximale, la meilleure pratique suggérée consiste à créer deux maillages ou plus à partir de fournisseurs distincts sur des marchés différents.

Dans ces exemples, si les dispositifs Network Edge d'un marché deviennent indisponibles, le trafic SD-WAN sera réacheminé via un nouveau marché. Les utilisateurs et les applications peuvent subir une augmentation de la latence, en fonction des connexions existantes et de leur emplacement.
Lorsque vous déployez des sites géo-redondants, vous devez également prendre en compte les connexions au cloud. Par exemple, si le déploiement de la Silicon Valley se connecte localement via AWS Direct Connect à la région AMER Ouest, il est courant que le site d'Ashburn se connecte à la région AWS AMER Est. Cela s'explique par le fait que les clients préfèrent les connexions à faible latence disponibles dans la même région. Par conséquent, une considération importante pour la géo-redondance est de savoir comment maintenir l'accès au fournisseur de cloud en cas de défaillance métropolitaine de Network Edge. Cela variera en fonction de vos préférences et de vos besoins, mais ces connexions sont souvent maintenues par l'une des quatre méthodes suivantes :
-
Vous disposez d'une connectivité de transit entre les régions du fournisseur de cloud. Dans l'exemple ci-dessus, si la Silicon Valley n'était pas disponible, le trafic réseau de DC serait acheminé vers la région AMER West via le backbone AWS.
-
Vous disposez d'une connectivité de transit par l'intermédiaire d'Equinix Fabric. Dans l'exemple ci-dessus, vous pourriez choisir d'établir vos connexions cloud à travers la Fabric d'Equinix afin que le trafic de DC se connecte à la région AMER West d'AWS. Cette solution est courante dans les déploiements où vous ne disposez pas d'une connectivité de transit sur le réseau dorsal du fournisseur de cloud.
-
Vous utilisez Internet (DIA) pour la connectivité de transit. Cette situation est fréquente lorsque des passerelles SD-WAN sont déployées et qu'Internet est utilisé comme sous-couche pour la connectivité de transit entre les sites. Il se peut que vous préfériez cette solution en raison de votre budget de latence et des exigences de votre entreprise.
-
Vous utilisez une combinaison de toutes les méthodes ci-dessus. Les méthodes ci-dessus ne s'excluent pas mutuellement. En fait, elles peuvent être utilisées de manière interchangeable en fonction des frontières régionales ou nationales et de la tolérance au risque.
Colocation
De nombreux clients disposent également d'un kit physiquement déployé dans un IBX d'Equinix. En se basant sur les cas d'utilisation ci-dessus, des connexions peuvent être établies pour intégrer ces sites dans le cadre d'une architecture géo-redondante. Il est courant que les clients augmentent leurs déploiements Network Edge existants en envoyant du trafic vers leurs sites colocalisés. Ces sites sont souvent utilisés pour assurer la continuité des activités dans le cadre d'une initiative de résilience du réseau plus importante.

Si vous avez besoin de DC pour accéder à des applications d'entreprise situées dans SV, vous pouvez le faire :
-
Utilisez un VC point à point depuis le port partagé de la colocation SV à travers la Fabric jusqu'au dispositif Network Edge dans DC. Vous devez évaluer si votre espace d'adressage existant peut accueillir cette connectivité.

-
Utilisez une connexion multipoint à multipoint à partir du port partagé de la colocation SV à travers la Fabric jusqu'au dispositif Network Edge dans DC. Cette approche est plus facile que l'utilisation de connexions point à point (P2P) pour créer un maillage complet sur plusieurs sites. Comme dans l'exemple ci-dessus, vous devez évaluer si votre espace d'adressage existant permet cette option de connectivité.

Résumé
La redondance locale permet de se prémunir contre une défaillance matérielle unique dans l'infrastructure Network Edge. La redondance des VC protège contre les défaillances d'un seul chemin dues à des problèmes dans l'infrastructure de transport sous-jacente. Vous avez la possibilité d'ajouter des VC redondants après le déploiement initial, ce qui permet à l'architecture d'évoluer en fonction des besoins de l'entreprise. Les architectures géo-redondantes offrent une résilience au niveau du métro et atténuent les problèmes lorsqu'un métro entier est menacé.
Pour une résilience optimale, il convient d'envisager des dispositifs redondants au niveau local, combinés à des déploiements géo-redondants. Cette approche permet d'atténuer à la fois les défaillances isolées de l'infrastructure au sein d'un métro et les risques associés à la mise hors service d'un métro entier. La combinaison de cette approche avec des fournisseurs de réseaux diversifiés et des fournisseurs de cloud avec une connectivité multipoint entièrement maillée est considérée comme une meilleure pratique pour tous ceux qui ne peuvent se permettre aucun temps d'arrêt.