Options de géoredondance pour la Network Edge

Ce document traite des considérations de conception pour toute personne intéressée par les solutions géo-redondantes sur Network Edge. Nous allons parcourir quelques cas d'utilisation en commençant par un exemple simple et en superposant progressivement plus d'options. Il n'existe pas de solution universelle 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 périphériques Network Edge effectuent simplement un 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 périphériques 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 périphériques Network Edge redondants vers les CSP en fonction de leur tolérance au risque.

Cependant, les VNF et les connexions localement redondantes ne protègent pas contre une panne qui affecte tous les périphériques locaux, comme un incendie qui pourrait retirer des périphériques 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 s'appuyant sur le cas d'utilisation ci-dessus, un routeur Network Edge supplémentaire est déployé dans un métro ne différent. En règle générale, ce nouvel appareil se trouve dans la même région, mais ce n’est pas une exigence car Equinix Fabric 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 provenant des succursales est agrégé et intégré aux clouds. Comme dans le cas d'utilisation précédent, il fournit également le routage cloud-to-cloud.

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 prévoir 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 que vous avez deux métros ou plus et que vous souhaitez ajouter un nouveau métro), une option consiste à mettre en miroir le ou les métro(s) existant(s). Dans cet exemple, un nouveau site est ajouté à Chicago.

Equinix offre 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 :

1. Utilisez un nouveau fournisseur de réseau local dans le(s) nouveau(s) métro(s) – soit via BYOC ou un fournisseur déjà sur la Fabric. Avec BYOC, vous vous connectez à un fournisseur de réseau local sur la Fabric via un port distant. Ce processus peut prendre plusieurs jours.

2. Créez des VC point à point du nouveau métro (Chicago) vers un site existant (Silicon Valley). En règle générale, vous choisiriez cette option soit comme solution géo-redondante temporaire pour des situations telles qu’une maintenance planifiée affectant le métro principal, soit comme solution de « veille à froid » où le métro géo-redondant n’existe que dans le cas où le métro principal n’est pas disponible. Ce n’est pas aussi courant car vous devrez probablement rediriger manuellement le trafic du métro principal vers le métro redondant. D'autres préoccupations concernant les exigences opérationnelles pour la gestion de l'espace d'adressage, les flux d'applications et les mécanismes qui existent pour maintenir la continuité du réseau rendent cela plus complexe sur le plan opérationnel.

3. Utilisez la connectivité multipoint à multipoint pour partager la connexion du fournisseur de services entre les métros. Ceci est particulièrement utile pour créer une topologie maillée complète sur plusieurs métros. L'avantage de cette approche est que plusieurs connexions sont construites pour étendre la connexion du fournisseur à plusieurs métros. Les considérations incluent les limitations d'espace d'adressage disponibles sur les circuits existants et les options que votre fournisseur propose pour partager la connexion sur Equinix Fabric. En raison des exigences définies par le fournisseur, vous devrez évaluer vos options car elles varient selon les fournisseurs. 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 périphériques Network Edge d'un marché deviennent indisponibles, le trafic SD-WAN sera réacheminé vers un nouveau marché. Les utilisateurs et les applications peuvent connaître une latence accrue, 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 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 Ashburn se connecte à la région AWS amer est. Ceci est typique car les clients préfèrent les connexions à latence la plus faible 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 du fournisseur de cloud en cas de panne de métro de Network Edge. Cela peut varier 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 :

1. 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 dans DC serait acheminé vers la région amer Ouest à travers le backbone AWS.

2. Vous disposez d'une connectivité de transit via Equinix Fabric. Dans l'exemple ci-dessus, vous pouvez choisir de créer vos connexions cloud sur le Equinix Fabric afin que le trafic dans DC se connecte à la région AWS amer Ouest. Ceci est courant dans les déploiements où vous ne disposez pas de connectivité de transit à travers le réseau dorsal du fournisseur de cloud.

3. Vous utilisez Internet (DIA) pour la connectivité de transit. Ceci est courant lorsque des passerelles SD-WAN sont déployées et que l'Internet est utilisé comme sous-couche pour la connectivité de transit entre les sites. Cela peut vous sembler préférable en raison de votre budget de latence et de vos besoins métier.

4. Vous utilisez une combinaison de tous les éléments ci-dessus. Les méthodes ci-dessus ne sont pas mutuellement exclusives. En fait, ils peuvent être utilisés de manière interchangeable en fonction des frontières régionales ou nationales et de leur tolérance au risque.

Colocation

De nombreux clients ont également déployé physiquement un kit colocalisé dans un Equinix IBX. En s'appuyant sur les cas d'utilisation ci-dessus, des connexions peuvent être construites 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. Souvent, ces sites sont utilisés pour fournir Business Continuity dans le cadre d'une initiative de résilience de réseau plus vaste.

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 à partir du port partagé SV Colocation via la structure vers le périphérique 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é SV Colocation via la structure vers le périphérique 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 atténue une défaillance matérielle unique dans l'infrastructure Network Edge. La redondance VC protège contre les défaillances de chemin unique dues à des problèmes dans l'infrastructure de transport sous-jacente. Vous avez la possibilité d'ajouter des circuits virtuels redondants après le déploiement initial, ce qui permet à l'architecture d'évoluer en fonction des besoins métiers. Les architectures géo-redondantes offrent une résilience au niveau métropolitain et atténuent les problèmes lorsqu'un métro entier est en danger.

Pour une résilience optimale, vous devez envisager des périphériques localement redondants combinés à des déploiements géo-redondants. Cette approche atténue à la fois les défaillances uniques de l'infrastructure d'un métro ainsi que les risques associés si un métro entier devait être mis hors ligne. Combiner cela avec des fournisseurs de réseau diversifiés et des fournisseurs de cloud avec une connectivité multipoint entièrement maillée est considéré comme une bonne pratique pour quiconque ne peut se permettre aucun temps d'arrêt.