Opciones de redundancia geográfica para Network Edge

Este documento discute las consideraciones de diseño para cualquier persona interesada en soluciones geo-redundantes en Network Edge. Caminaremos a través de un par de casos de uso comenzando con un ejemplo simple y gradualmente estratificando más opciones. No hay una solución única que funcione para todos; tendrá que tomar las decisiones que mejor se ajusten a sus necesidades.

Enrutamiento de nube a nube

En este caso de uso habitual de Network Edge, los dispositivos Network Edge simplemente enrutan entre dos proveedores de servicios en la nube (CSP).

Tiene la opción de agregar resiliencia local agregando otro router Network Edge y conexiones redundantes a los CSP en el mismo metro. La redundancia local protege contra un fallo de hardware local ya que los dispositivos redundantes se colocan en diferentes planos de cómputo. También tiene la flexibilidad de crear circuitos virtuales redundantes desde los dispositivos Network Edge redundantes hasta los CSP dependiendo de su tolerancia al riesgo.

Sin embargo, las conexiones y VNF redundantes localmente no protegen contra una interrupción que afecte a todos los dispositivos locales, como un incendio que podría eliminar los dispositivos durante un período prolongado o incluso una actualización de la infraestructura. Para este nivel de resiliencia, debe considerarse la geo-redundancia. Basándose en el caso de uso desde arriba, se implementa un router Network Edge adicional en un metro NE diferente. Típicamente, este nuevo dispositivo estaría en la misma región, pero esto no es un requisito porque Equinix Fabric permite la conectividad entre metros de todo el mundo.

La redundancia local combinada con la georredundancia proporciona la máxima protección tanto contra fallos locales de hardware en una estación metropolitana como contra problemas (incendios, desastres naturales, etc.) que afecten a todos los dispositivos de la estación metropolitana.

Cloud On-Ramp con enrutamiento de nube a nube

En este caso de uso, el tráfico SD-WAN de las sucursales se está agregando y encendido a las nubes. Al igual que el caso de uso anterior, también proporciona el enrutamiento de nube a nube.

Los clientes suelen implementar rampas de entrada de agregación SD-WAN en varias ubicaciones para mejorar la experiencia del usuario reduciendo la latencia y evitando tener que trombonar el tráfico a través de largas distancias.

Además de proporcionar una mejor experiencia de usuario, esta arquitectura también puede proporcionar geo-redundancia: En caso de una interrupción que afecte a toda la implementación de Silicon Valley, el tráfico SD-WAN se redirigirá a Ashburn. El tráfico multi-nube todavía puede tener lugar a través del metro disponible.

Si desea geo-redundancia y tiene solo un metro operativo (o tiene dos o más metros y desea agregar un metro nuevo), una opción es reflejar el metro (s) existente (s). En este ejemplo se agrega un nuevo sitio en Chicago.

Equinix ofrece múltiples opciones para la conectividad de la capa de acceso. Por ejemplo, puede estar usando un puerto remoto de Fabric (también conocido como BYOC) para conectarse a un proveedor de servicios en Silicon Valley. Para proporcionar conectividad de capa de acceso al sitio geo redundante en Chicago, tiene varias opciones:

1. Utilice un nuevo proveedor de red local en el nuevo metro (s), ya sea a través de BYOC o un proveedor que ya esté en The Fabric. Con BYOC, se conecta a un proveedor de red local en Fabric a través de un puerto remoto. Este proceso puede tardar varios días en completarse.

2. Cree VCs punto a punto desde el nuevo metro (Chicago) a un sitio existente (Silicon Valley). Por lo general, usted elegiría esta opción como una solución temporal geo-redundante para situaciones tales como un mantenimiento planificado que afecta al metro primario; o como una solución de “espera en frío” donde el metro geo-redundante solo existe en caso de que el metro primario no esté disponible. Esto no es tan común porque es probable que necesites redirigir manualmente el tráfico del metro principal al metro redundante. Las preocupaciones adicionales en torno a los requisitos operacionales para abordar la gestión del espacio, los flujos de aplicaciones y los mecanismos existentes para mantener la continuidad de la red hacen que esto sea más complejo desde el punto de vista operacional.

3. Utilice la conectividad multipunto a multipunto para compartir la conexión del proveedor de servicios a través de Metros. Esto es especialmente útil para crear una topología mallada completa a través de múltiples metros. El beneficio de este enfoque es que se construyen múltiples conexiones para extender la conexión del proveedor a múltiples metros. Las consideraciones incluyen limitaciones de espacio de direcciones disponibles en los circuitos existentes y qué opciones ofrece su proveedor para compartir la conexión a través de Equinix Fabric. Debido a los requisitos establecidos por el proveedor, tendrá que evaluar sus opciones porque varían entre los proveedores. Para lograr la máxima resiliencia, la mejor práctica sugerida es crear dos o más mallas a partir de proveedores separados en diferentes mercados.

   

En estos ejemplos, si los dispositivos Network Edge en un mercado no están disponibles, el tráfico de SD-WAN se redirigirá a través de un nuevo mercado. Los usuarios y las aplicaciones pueden experimentar una mayor latencia, dependiendo de las conexiones existentes y dónde se encuentran.

Al implementar sitios geo-redundantes, también debe considerar las conexiones en la nube. Por ejemplo, si el despliegue de Silicon Valley se conecta localmente a través de AWS Direct Connect a la región de AMER Oeste, es común que el sitio de Ashburn se conecte a la región de AWS AMER Este. Esto es típico debido a que los clientes prefieren las conexiones de latencia más bajas disponibles en la misma región. Por lo tanto, una consideración importante para la geo-redundancia es cómo mantener el acceso del proveedor de la nube en caso de una falla de metro de Network Edge. Esto variará en función de sus preferencias y requisitos, pero estas conexiones a menudo se mantienen a través de uno de los cuatro métodos:

1. Tiene conectividad de tránsito en todas las regiones del proveedor de nube. En el ejemplo anterior, si Silicon Valley no estuviera disponible, entonces el tráfico de red en DC se enrutaría a la región de AMER Oeste a través de la columna vertebral de AWS.

2. Tiene conectividad de tránsito a través de Equinix Fabric. En el ejemplo anterior, puede optar por construir sus conexiones en la nube a través de Equinix Fabric para que el tráfico en DC se conectara a la región oeste de AWS. Esto es común en la implementación donde no tiene conectividad de tránsito en la columna vertebral del proveedor de nube.

3. Usted utiliza Internet (DIA) para la conectividad de tránsito. Esto es común cuando se implementan gateways SD-WAN y se utiliza Internet como base para la conectividad de tránsito entre sitios. Usted puede encontrar esto preferible debido a su presupuesto de latencia y los requisitos de negocio.

4. Usted utiliza alguna combinación de todo lo anterior. Los métodos anteriores no son mutuamente excluyentes. De hecho, pueden utilizarse indistintamente dependiendo de las fronteras regionales o nacionales y de su tolerancia al riesgo.

Colocation

Muchos clientes también han desplegado físicamente el kit en una Equinix IBX. Basándose en los casos de uso anteriores, se pueden construir conexiones para incorporar estos sitios como parte de una arquitectura geo-redundante. Es común que los clientes aumenten sus implementaciones de Network Edge existentes enviando tráfico a sus sitios co-ubicados. Muchas veces, estos sitios se utilizan para proporcionar Business Continuity como parte de una iniciativa de resiliencia de red más grande.

Si necesita que DC acceda a aplicaciones corporativas ubicadas en SV, podría hacerlo:

• Utilice un VC punto a punto desde el puerto compartido SV Colocation a través de la tela hasta el dispositivo Network Edge en DC. Debe evaluar si su espacio de direcciones existente se acomoda a esta conectividad.

  

• Utilice una conexión multipunto a multipunto desde el puerto compartido SV Colocation a través de la tela al dispositivo Network Edge en DC. Este enfoque es más fácil que usar conexiones punto a punto (P2P) para crear una malla completa en varios sitios. Al igual que en el ejemplo anterior, debe evaluar si su espacio de direcciones existente permite esta opción de conectividad.

  

Resumen

La redundancia local mitiga un solo fallo de hardware en la infraestructura de Network Edge. La redundancia VC protege contra fallos de una sola ruta debido a problemas en la infraestructura de transporte subyacente. Tiene la opción de agregar VCs redundantes después de la implementación inicial, lo que permite que la arquitectura evolucione a medida que lo hacen los requisitos empresariales. Las arquitecturas geo-redundantes proporcionan resiliencia a nivel del metro y mitigan los problemas cuando un metro entero está en riesgo.

Para obtener la mayor resiliencia, debe considerar dispositivos redundantes locales combinados con implementaciones geo-redundantes. Este enfoque mitiga tanto las fallas individuales en la infraestructura dentro de un metro, así como los riesgos asociados si un metro entero se fuera de línea. Combinar esto con proveedores de red diversificados y proveedores de nube con conectividad multipunto totalmente mallada se considera una mejor práctica para cualquier persona que no pueda permitirse ningún tiempo de inactividad.