Arquitectura para la resiliencia
En este tema se ofrece una descripción general de las soluciones tolerantes a fallos que se pueden conseguir con Network Edge.
Diseñar soluciones con resiliencia es uno de los aspectos más críticos de la arquitectura de red y perimetral. Aunque no existe una respuesta correcta a la pregunta de cuánta resiliencia se necesita, existen prácticas recomendadas, sugerencias para diferentes casos de uso y algunos servicios y características específicos que ofrece Network Edge.
La plataforma subyacente de virtualización de funciones de red (NFV) que proporciona la infraestructura para Network Edge es intrínsecamente tolerante a fallos desde el punto de vista de una única instancia virtual. Aun así, debe diseñar la resiliencia en la solución global para lograr la máxima redundancia posible. En este documento se explica cómo lograr la resiliencia utilizando la naturaleza inherente de la plataforma complementada con las funciones de tolerancia a fallos de Network Edge.
Niveles de redundancia
Imagina un diseño de red desde el origen de un paquete de datos y moviéndose desde dentro hacia fuera hasta su destino. En ese caso, cada punto donde se procesa o atraviesa el tráfico se convierte en un posible punto de fallo. La clave es diseñar contra un evento que impacte en los puntos de cruce.
En un flujo de red sencillo desde un dispositivo Network Edge a un participante de Equinix Fabric, tal y como se muestra en el siguiente gráfico, los flujos de tráfico tienen tres puntos distintos: el dispositivo virtual Network Edge, Equinix Fabric y la conexión del participante de Fabric. Existe una redundancia inherente entre el dispositivo virtual Network Edge y Equinix Fabric, por lo que la arquitectura Leaf o Spine que interconecta la plataforma NFV subyacente con Fabric es redundante. No existe redundancia inherente entre Equinix Fabric y el participante de Fabric. Para lograr la máxima redundancia, debe implementar una solución que utilice diferentes planos de conectividad para aprovechar el flujo completo de la red.

Planos primarios y secundarios
El Network Edge se basa en una arquitectura de redundancia de centros de datos estándar con múltiples puntos de despliegue (POD) que cuentan con un suministro de energía dedicado. El concepto de planos Primario y Secundario está detrás del despliegue de Network Edge y Equinix Fabric. Network Edge utiliza los planos Primario y Secundario mediante la separación informática por afinidad. Cada dispositivo virtual de un par tolerante a fallos se despliega en su respectivo clúster. Aunque se denominan Plano Primario y Plano Secundario, existen múltiples planos de cálculo en cada uno de los POD de Network Edge. El número real varía en función del tamaño del metro. Esto permite desplegar los dispositivos de forma que no estén mezclados en el mismo plano de cálculo, eliminando el cálculo como punto único de fallo (SPOF).

Los conmutadores Equinix Fabric forman parte de un grupo de chasis que consta de conmutadores Primarios y Secundarios. Las designaciones de conmutador Primario y Secundario para el grupo de chasis son simplemente una forma de identificar los conmutadores desde el punto de vista de la nomenclatura y no muestran los flujos de tráfico. Activo-Activo o Activo-En espera desde el punto de vista del enrutamiento se configuran en el dispositivo Network Edge y están completamente bajo su control. La documentación sobre la arquitectura de la plataforma trata más detalles sobre la arquitectura fundacional de Network Edge.
Previamente se ha desplegado una VNF de cortafuegos denominada NGFW-A. Para desplegar una VNF de enrutador en el plano secundario, utilice la función Diverse Compute from an Existing Single Device y seleccione NGFW-A en el menú desplegable.
Definición de resistencia de dispositivos y conexiones
Network Edge ofrece múltiples opciones de resiliencia que pueden resumirse en opciones de dispositivo y opciones de conexión. Las opciones de dispositivo son locales y proporcionan resiliencia contra fallos a nivel informático y de dispositivo en el metro local. Esto es análogo a lo que la industria suele denominar "alta disponibilidad (HA)". La resiliencia de conexión es una opción separada para clientes que requieren resiliencia adicional con conexiones de dispositivos (DLGs, VCs y redes EVP-LAN).
Es habitual combinar tanto la resiliencia local como la resiliencia de conexión, pero no es obligatorio; en última instancia, depende de los requisitos empresariales del cliente.
La georredundancia es una arquitectura que amplía la capacidad de recuperación local utilizando varios metros para eliminar los problemas que puedan afectar a Network Edge a nivel metropolitano. La georredundancia se trata en detalle aquí.
Dispositivos individuales (autónomos) - Opción de resistencia local
Los dispositivos individuales o autónomos no tienen capacidad de recuperación ante fallos informáticos y de dispositivos. El primer dispositivo único siempre está conectado al Plano de Computación Primario. Los dispositivos únicos siempre establecen conexiones a través de la red Primary Fabric. Los dispositivos únicos pueden construir conexiones redundantes (VCs, DLGs, etc.) pero siempre atravesarán el plano Primary Fabric. Los dispositivos únicos pueden convertirse en dispositivos redundantes mediante la función antiafinidad.
Antiafinidad de un solo dispositivo
Como se ha descrito anteriormente, los dispositivos individuales no tienen capacidad de recuperación por defecto. Sin embargo, los dispositivos individuales pueden colocarse en planos de cómputo divergentes. Esto se denomina comúnmente antiafinidad y está disponible en el flujo de trabajo de creación de dispositivos. En la sección Computación diversa a partir de un dispositivo único existente, si se marca la casilla "Seleccionar diverso a partir de", los clientes pueden añadir nuevos dispositivos que sean resilientes entre sí.
Dispositivo virtual redundante frente a clúster
Los flujos de trabajo de Network Edge garantizan que los dispositivos virtuales emparejados en un despliegue tolerante a fallos se coloquen en los planos de cálculo primario y secundario. Existen dos tipos de despliegues tolerantes a fallos: Dispositivos redundantes y Dispositivos agrupados.
Estas opciones proporcionan resiliencia local (intrametro) para proteger contra fallos de hardware o de alimentación en el POD Network Edge local. De forma predeterminada, los dos dispositivos virtuales se implementan en planos de cómputo separados (primario y secundario) y son distintos entre sí. El dispositivo primario está conectado a la red Fabric primaria y el dispositivo secundario/pasivo está conectado a la red Fabric secundaria. La selección del tipo de implementación está disponible en el flujo de trabajo de creación de dispositivos del portal.

Las instancias virtuales redundantes se despliegan en diferentes planos de cálculo para conseguir redundancia. No tienen flujos de trabajo de nivel superior, lo que significa que los dispositivos no son conscientes el uno del otro después del despliegue inicial y funcionan como dos dispositivos virtuales distintos. Normalmente, los dispositivos redundantes funcionan de forma Activo-Activo. Las instancias virtuales redundantes pueden desplegarse en un mismo metro o a través de metros. Un dispositivo redundante en un único metro sólo proporciona capacidad de recuperación local. El despliegue de la georredundancia (dispositivos redundantes en varios metros) proporciona una capacidad de recuperación mucho mayor. Cuando un dispositivo redundante se despliega en otro metro, sigue desplegado en el plano de cálculo secundario.
Las instancias virtuales de Cluster tienen flujos de trabajo de nivel superior que desplegarán un par de dispositivos Activo-En espera según lo definido por el proveedor respectivo. Consulte la documentación para verificar la compatibilidad con Cluster para su dispositivo virtual. Los dispositivos Cluster sólo pueden desplegarse dentro del mismo metro.

Conexiones virtuales
Las conexiones virtuales le permiten especificar el nivel de resistencia que requiere su despliegue. Los flujos de trabajo son flexibles, lo que permite múltiples escenarios para dar cabida a la redundancia, si es necesario.
Los flujos de trabajo de las conexiones virtuales difieren entre los despliegues redundantes y de clúster. Las conexiones de dispositivos redundantes se originan en cada dispositivo virtual individual del par redundante, mientras que las conexiones de dispositivos agrupados se originan en el clúster.
Conexiones virtuales redundantes
Los dispositivos redundantes se despliegan en distintos planos de cálculo mediante afinidad. Una vez desplegados, los dispositivos no comparten ninguna información de configuración y funcionan como dos dispositivos independientes. Para lograr la redundancia a través del participante Fabric, se crean conexiones virtuales en los planos Primary y Secondary Fabric como se muestra a continuación. El plano Primario se conecta a la red del Tejido Primario (o Plano del Tejido Primario) y el Plano Secundario se conecta a la red del Tejido Secundario.
Este es uno de los conceptos más importantes para comprender la resiliencia de Network Edge. El plano del dispositivo determina qué red Fabric (o plano Fabric) se utiliza para las conexiones de dispositivos.

Los dispositivos redundantes pueden desplegarse en el mismo metro o en metros diferentes, lo que permite crear soluciones redundantes que abarcan distancias geográficas. Los flujos de trabajo son flexibles y se pueden crear conexiones tanto en el plano principal como en el secundario de Fabric, o en cada plano según lo requiera el caso de uso.
Conexiones virtuales del clúster
Los dispositivos agrupados se despliegan en los planos de computación primario y secundario y tienen flujos de trabajo de nivel superior para construir un par de dispositivos virtuales Activo-Activo o Activo-Estable.

Los clústeres pueden construirse sólo en el mismo metro. Por ejemplo, si se construye un circuito virtual tanto en el plano primario como en el secundario de Fabric, el flujo de trabajo creará dos conexiones al clúster y asignará una interfaz para cada conexión a ambos nodos del clúster. La imagen siguiente (Connecting to Same Metro/Same Provider) muestra una conexión Fabric primaria y secundaria a un cluster Active-Standby con cluster-node0 activo y cluster-node1 en espera. En caso de que se produzca un fallo en el clúster y el nodo-clúster1 pase a estar activo, las conexiones se trasladarán al nodo-clúster1.
| Redundant Devices | Clustered Devices | |
|---|---|---|
| Deployment | Two devices, both Active, appearing as two devices in the Network Edge portal. Both devices have all interfaces forwarding | Two devices, only one is ever Active. The Passive (non-Active) device data plane is not forwarding |
| WAN Management | Both devices get a unique L3 address that is active for WAN management | Each node gets a unique L3 address for WAN management as well as a Cluster address that connects to the active node (either 0 or 1) |
| Device Linking Groups | None are created at device inception | Two are created by default to share configuration synchronization and failover communication |
| Fabric Virtual Connections | Connections can be built to one or both devices | Single connections are built to a special VNI that connects to the Active Cluster node only. Customer can create optional, additional secondary connection(s) |
| Supports Geo Redundancy | Yes, Redundant devices can be deployed in different metros | No, Cluster devices can only be deployed in the same metro |
| Vendor Support | All vendors | Fortinet FortiGate FirewallsJuniper vSRX FirewallsNGINX PlusPalo Alto VM-Series Firewalls |
Todos los escenarios mostrados en las siguientes ilustraciones asumen que el participante Proveedor se conecta tanto al Fabric Primario como al Secundario. Si tiene alguna duda sobre las conexiones a Fabric redundantes, consulte a su arquitecto de soluciones globales de Equinix.
Conexión al mismo metro/mismo proveedor

Utilice este escenario de conexión para conectarse al mismo proveedor mediante dispositivos Network Edge en la misma ubicación metropolitana. En este escenario, Network Edge admite implementaciones redundantes y en clúster. Los flujos de trabajo de circuitos virtuales garantizan que cada circuito se aprovisione en los planos Fabric primario y secundario, respectivamente. Un ejemplo son las conexiones redundantes a los mismos participantes de Fabric.
Conectarse al mismo metro o a distintos proveedores

Utilice este escenario de conexión para conectarse a diferentes proveedores mediante dispositivos Network Edge en la misma ubicación metropolitana. En este escenario, Network Edge admite implementaciones redundantes y en clúster. Los flujos de trabajo de circuitos virtuales garantizan que cada circuito se aprovisione en los planos Fabric primario y secundario, respectivamente. Un ejemplo son las conexiones redundantes a diferentes participantes de Fabric.
Conectarse a otro metro o al mismo proveedor

Utilice este escenario de conexión para conectarse a los mismos proveedores mediante instancias virtuales de Network Edge en diferentes ubicaciones metropolitanas. En este escenario, Network Edge admite implementaciones redundantes, pero no implementaciones de clúster. Los flujos de trabajo de circuitos virtuales garantizan que cada circuito se aprovisione en los planos Fabric primario y secundario, respectivamente. Un ejemplo son las conexiones redundantes desde dos áreas metropolitanas diferentes al mismo participante Fabric.
Conectarse a diferentes metros/diferentes proveedores

Utilice este escenario de conexión para conectarse a diferentes proveedores mediante dispositivos Network Edge en diferentes ubicaciones metropolitanas a diferentes participantes de Fabric. En este escenario, Network Edge admite implementaciones redundantes, pero no implementaciones de clúster. Los flujos de trabajo de circuitos virtuales garantizan el aprovisionamiento de cada circuito en los planos Fabric primario y secundario, respectivamente. Un ejemplo son las conexiones redundantes desde dos áreas metropolitanas diferentes a los diferentes participantes de Fabric.
Grupos de enlace de dispositivos
Un grupo de enlaces de dispositivos (DLG) es un servicio de Network Edge con el que se pueden conectar dos o más dispositivos virtuales como un grupo dentro de una o varias redes metropolitanas. Un DLG se utiliza normalmente para encadenar servicios (conectar varios tipos de dispositivos, como cortafuegos y enrutadores), como backbone o con fines de redundancia.

Los DLG pueden crearse con o sin redundancia. Un único DLG, como un único cable Ethernet, no proporciona resistencia. Los clientes que necesiten la máxima capacidad de recuperación deben desplegar DLG adicionales que se conecten tanto a la red primaria como a la secundaria de Fabric.

Device Link y su capacidad de redundancia se tratan en detalle en Device Link Resiliency.
Redes EVP-LAN
Network Edge admite la conexión EVP-LAN para permitir la conexión en red multipunto a multipunto. EVP-LAN le permite interconectar los activos de su centro de datos en muchas ubicaciones a través de una red común, en lugar de requerir conexiones directas entre ubicaciones individuales. En este tema se describe cómo crear una red privada multipunto a multipunto y conectarse a ella desde sus dispositivos Network Edge.
Las EVP-LAN se diferencian de las DLG en que se conectan a dispositivos Network Edge y puertos Fabric. Varios dispositivos Network Edge en la misma zona metropolitana pueden formar parte de la misma red EVP-LAN. Los clientes que requieran la máxima resiliencia deben implementar EVP-LAN adicionales que abarquen tanto la red Fabric primaria como la secundaria.
Para una resistencia adecuada, cada dispositivo del par de dispositivos redundantes requerirá una única conexión a dos redes EVP-LAN diferentes. El dispositivo primario en el plano primario utilizará la red Primary Fabric. El dispositivo secundario del plano secundario utilizará la red Fabric secundaria.
Los dispositivos agrupados son diferentes en el sentido de que el flujo de trabajo permite crear conexiones a las redes de Fabric primaria o secundaria.
Temas relacionados

