Options de géoredondance pour la Network Edge
Ce document aborde les considérations de conception pour toute personne intéressée par les solutions géoredondantes sur Network Edge. Nous aborderons quelques cas d'utilisation, en commençant par un exemple simple, puis en ajoutant progressivement d'autres options. Il n'existe pas de solution universelle ; vous devrez prendre les décisions les mieux adaptées à vos besoins.
Routage de nuage à nuage
Dans ce cas d’utilisation courant de Network Edge, les périphériques Network Edge effectuent simplement un routage entre deux fournisseurs de services cloud (CSP).

Vous pouvez renforcer la résilience locale en ajoutant un autre routeur de Network Edge et des connexions redondantes aux CSP d'une même zone métropolitaine. La redondance locale protège contre les pannes matérielles locales, car les périphériques redondants sont placés sur des plans de calcul différents. Vous avez également la possibilité de créer des circuits virtuels redondants entre les périphériques de Network Edge redondants et les CSP, en fonction de leur tolérance au risque.

Cependant, les VNF et connexions localement redondantes ne protègent pas contre une panne affectant tous les appareils locaux, comme un incendie pouvant les paralyser pendant une longue période, ni même une mise à niveau de l'infrastructure. Pour ce niveau de résilience, la géoredondance doit être envisagée. En reprenant le cas d'utilisation précédent, un routeur Network Edge supplémentaire est déployé dans une autre zone métropolitaine du nord-est. Généralement, ce nouvel appareil se trouve dans la même région, mais ce n'est pas obligatoire, car Equinix Fabric permet la connectivité entre les zones métropolitaines 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 connu sous le nom de 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.
-
Utilisez la connectivité multipoint à multipoint pour partager la connexion du fournisseur de services entre les zones métropolitaines. Cette approche est particulièrement utile pour créer une topologie maillée complète sur plusieurs zones métropolitaines. L'avantage de cette approche est que plusieurs connexions sont établies pour étendre la connexion du fournisseur à plusieurs zones métropolitaines. Il convient de prendre en compte les limitations d'espace d'adressage disponibles sur les circuits existants et les options proposées par votre fournisseur pour partager la connexion sur Equinix Fabric. En raison des exigences définies par le fournisseur, vous devrez évaluer vos options, car elles varient d'un fournisseur à l'autre. Pour une résilience maximale, la meilleure pratique recommandée consiste à créer deux ou plusieurs maillages provenant de fournisseurs distincts sur différents marchés.

Dans ces exemples, si les périphériques Network Edge d'un marché deviennent indisponibles, le trafic SD-WAN sera redirigé vers un nouveau marché. Les utilisateurs et les applications peuvent subir une latence accrue, selon les connexions existantes et leur localisation.
Lors du déploiement de sites géoredondants, il est également important de prendre en compte les connexions 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. Ce phénomène est typique car les clients privilégient les connexions à latence la plus faible disponibles dans la même région. Par conséquent, un élément important de la géoredondance est de savoir comment maintenir l'accès au fournisseur cloud en cas de panne métropolitaine de Network Edge. Cela dépend de vos préférences et de vos besoins, mais ces connexions sont souvent maintenues grâce à 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 via Equinix Fabric. Dans l'exemple ci-dessus, vous pourriez choisir de créer vos connexions cloud via Equinix Fabric afin que le trafic du centre de données soit connecté à la région AWS AMER Ouest. Ce phénomène est courant dans les déploiements où la connectivité de transit via le backbone du fournisseur cloud n'est pas disponible.
-
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'équipements physiquement déployés et colocalisés dans un IBX Equinix . En s'appuyant sur les cas d'utilisation précédents, des connexions peuvent être établies pour intégrer ces sites dans une architecture géoredondante. Il est courant que les clients renforcent leurs déploiements Network Edge existants en acheminant le 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 plus vaste de résilience réseau.

Si vous avez besoin de DC pour accéder à des applications d'entreprise situées dans SV, vous pouvez le faire :
-
Utilisez un circuit virtuel point à point reliant le port partagé de colocation SV à l'équipement de Network Edge du centre de données, en passant par la Fabric . Vous devez évaluer si votre espace d'adressage existant permet cette connectivité.

-
Utilisez une connexion multipoint à multipoint depuis le port partagé de colocation SV jusqu'au périphérique Network Edge du DC, via la Fabric . Cette approche est plus simple que l'utilisation de connexions point à point (P2P) pour créer un maillage complet sur plusieurs sites. Comme dans l'exemple précédent, vous devez évaluer si votre espace d'adressage existant permet cette option de connectivité.

Résumé
La redondance locale prévient toute panne matérielle dans l'infrastructure Network Edge . La redondance des circuits virtuels protège contre les pannes de chemin unique dues à des problèmes dans l'infrastructure de transport sous-jacente. Vous pouvez ajouter des circuits virtuels redondants après le déploiement initial, ce qui permet à l'architecture d'évoluer en fonction des besoins métier. Les architectures géoredondantes assurent la résilience à l'échelle métropolitaine et atténuent les problèmes lorsqu'une métropole entière est menacée.
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 pas se permettre le moindre temps d'arrêt.