Ir al contenido principal

Opciones de redundancia geográfica para Network Edge

Este documento analiza las consideraciones de diseño para cualquier persona interesada en soluciones georedundantes en Network Edge. Repasaremos un par de casos de uso, comenzando con un ejemplo sencillo y añadiendo progresivamente más opciones. No existe una solución única que se adapte a todos los casos; deberá tomar las decisiones que mejor se adapten 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 añadir resiliencia local añadiendo otro router Network Edge y conexiones redundantes a los CSP en la misma área metropolitana. La redundancia local protege contra fallos de hardware locales, ya que los dispositivos redundantes se colocan en diferentes planos de computación. También tiene la flexibilidad de crear circuitos virtuales redundantes desde los dispositivos Network Edge redundantes a los CSP en función de su tolerancia al riesgo.

Sin embargo, las VNF y las conexiones redundantes a nivel local no protegen contra una interrupción que afecte a todos los dispositivos locales, como un incendio que pueda dejar fuera de servicio los dispositivos durante un periodo prolongado, o incluso una actualización de la infraestructura. Para alcanzar este nivel de resiliencia, se debe considerar la redundancia geográfica. Partiendo del caso de uso anterior, se implementa un router Network Edge adicional en un metro NE diferente. Normalmente, este nuevo dispositivo estaría en la misma región, pero no es un requisito, ya que 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 agrega y se envía a las nubes. Al igual que en el caso de uso anterior, también proporciona 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 georredundancia: en caso de un corte que afecte a todo el despliegue de Silicon Valley, el tráfico SD-WAN se redirigirá a Ashburn. El tráfico multicloud puede seguir teniendo lugar a través del metro disponible.

Si quiere georredundancia y sólo tiene un metro operativo (o tiene dos o más metros y quiere añadir uno nuevo), una opción es reflejar el metro o los metros existentes. En este ejemplo se añade un nuevo sitio en Chicago.

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

  1. Utilice un nuevo proveedor de red local en los nuevos metros, ya sea a través de BYOC o de un proveedor ya existente en el Fabric. Con BYOC, se conecta a un proveedor de red local en el Fabric a través de un puerto remoto. Este proceso puede tardar varios días en completarse.

  2. Crear VC punto a punto desde el nuevo metro (Chicago) de vuelta a un sitio existente (Silicon Valley). Normalmente, se elige esta opción como una solución temporal georredundante para situaciones como un mantenimiento planificado que afecte al metro principal; o como una solución de "espera en frío" en la que el metro georredundante sólo existe en caso de que el metro principal no esté disponible. Esto no es tan común porque probablemente tendrá que redirigir manualmente el tráfico del metro primario al metro redundante. Otras cuestiones relacionadas con los requisitos operativos para la gestión del espacio de direcciones, los flujos de aplicaciones y los mecanismos existentes para mantener la continuidad de la red hacen que esta solución sea más compleja desde el punto de vista operativo.

  3. Utilice la conectividad multipunto a multipunto para compartir la conexión del proveedor de servicios entre metros. Esto resulta especialmente útil para crear una topología de malla completa en varios metros. La ventaja de este enfoque es que se crean múltiples conexiones para ampliar la conexión del proveedor a varios metros. Hay que tener en cuenta las limitaciones de espacio de direcciones disponibles en los circuitos existentes y las opciones que ofrece el proveedor para compartir la conexión a través de Equinix Fabric. Debido a los requisitos establecidos por el proveedor, deberá evaluar sus opciones, ya que varían de un proveedor a otro. Para obtener la máxima resistencia, la mejor práctica sugerida es crear dos o más mallas de proveedores distintos en mercados diferentes.

    En estos ejemplos, si los dispositivos Network Edge de un mercado dejan de estar disponibles, el tráfico SD-WAN se redirigirá a través de un nuevo mercado. Los usuarios y las aplicaciones pueden experimentar un aumento de la latencia, dependiendo de las conexiones existentes y de su ubicación.

    Al implementar sitios con redundancia geográfica, también debe tener en cuenta las conexiones en la nube. Por ejemplo, si la implementación de Silicon Valley se conecta localmente a través de AWS Direct Connect a la región AMER Oeste, es habitual que el sitio de Ashburn se conecte a la región AWS AMER Este. Esto es habitual debido a que los clientes prefieren las conexiones con menor latencia disponibles en la misma región. Por lo tanto, una consideración importante para la redundancia geográfica es cómo mantener el acceso al proveedor de nube en caso de un fallo metropolitano de Network Edge. Esto variará en función de sus preferencias y requisitos, pero estas conexiones suelen mantenerse mediante uno de estos cuatro métodos:

  4. Dispone de conectividad de tránsito entre regiones en el proveedor de la nube. En el ejemplo anterior, si Silicon Valley no estuviera disponible, el tráfico de red en DC se enrutaría a la región AMER West a través de la red troncal de AWS.

  5. Dispone de conectividad de tránsito a través de Equinix Fabric. En el ejemplo anterior, podría elegir crear sus conexiones de nube a través de Equinix Fabric para que el tráfico en DC se conecte a la región de AWS AMER West. Esto es habitual en implementaciones en las que no se dispone de conectividad de tránsito a través de la red troncal del proveedor de la nube.

  6. Utiliza Internet (DIA) para la conectividad de tránsito. Esto es habitual cuando se despliegan pasarelas SD-WAN e Internet se utiliza como capa subyacente para la conectividad de tránsito entre sitios. Puede que esto sea preferible debido a su presupuesto de latencia y a sus requisitos empresariales.

  7. Utiliza alguna combinación de todos los anteriores. Los métodos anteriores no son mutuamente excluyentes. De hecho, pueden utilizarse indistintamente en función de las fronteras regionales o nacionales y de su tolerancia al riesgo.

Colocation

Muchos clientes también han desplegado físicamente equipos coubicados en un IBX de Equinix. Basándose en los casos de uso anteriores, se pueden establecer conexiones para incorporar estos sitios como parte de una arquitectura georedundante. Es habitual que los clientes amplíen sus implementaciones de Network Edge existentes enviando tráfico a sus sitios coubicados. En muchas ocasiones, estos sitios se utilizan para proporcionar continuidad del negocio como parte de una iniciativa de resiliencia de red más amplia.

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

  • Utilice una VC punto a punto desde el puerto compartido de colocation SV a través de Fabric hasta el dispositivo Network Edge en DC. Debe evaluar si su espacio de direcciones existente admite esta conectividad.

  • Utilice una conexión multipunto a multipunto desde el puerto compartido de colocation SV a través de Fabric hasta el dispositivo Network Edge en DC. Este enfoque es más sencillo que utilizar conexiones punto a punto (P2P) para crear una malla completa entre 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 los efectos de un fallo único de hardware en la infraestructura Network Edge. La redundancia VC protege contra fallos de ruta única debidos a problemas en la infraestructura de transporte subyacente. Tiene la opción de añadir VC 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 georedundantes proporcionan resiliencia a nivel metropolitano y mitigan los problemas cuando toda una zona metropolitana está en riesgo.

Para obtener la máxima capacidad de recuperación, debe considerar dispositivos redundantes localmente combinados con despliegues georredundantes. Este enfoque mitiga tanto los fallos aislados en la infraestructura dentro de un metro como los riesgos asociados a la desconexión de todo un metro. Combinar esto con proveedores de red diversificados y proveedores de nube con conectividad multipunto totalmente mallada se considera la mejor práctica para cualquiera que no pueda permitirse ningún tiempo de inactividad.

¿Fue útil esta página?