Mejores prácticas de redundancia de FastConnect
En este tema, se tratan las mejores prácticas para redundancia al implementar FastConnect.
Para obtener información general sobre FastConnect, consulte FastConnect Visión general.
Visión general
Diseñe la red local para lograr una alta disponibilidad (HA) como preparación para estos tipos de interrupciones:
- Mantenimiento programado regularmente en la red local, la red de un proveedor (si la utiliza) u Oracle.
- Fallos inesperados por parte de los componentes de red locales, el proveedor u Oracle. Los fallos son poco frecuentes, pero aún debe planificarlos.
Las conexiones a OCI proporcionan redundancia de las siguientes formas:
- Cada región de OCI tiene varios proveedores y Oracle Partners (consulte la lista de FastConnect Partners) que hacen posible la redundancia de los proveedores
- Las regiones con varias entradas en la lista de ubicaciones FastConnect (consulte la parte inferior de la lista de FastConnect Partners tiene dos o más ubicaciones FastConnect (a veces denominado punto de presencia o PoP). Muchas regiones tienen una única ubicación FastConnect, por lo que la redundancia de región a veces está disponible, pero no siempre.
- Cada ubicación FastConnect siempre tiene al menos dos enrutadores para activar la redundancia del dispositivo.
- Cada región de Oracle tiene varias conexiones físicas a cada partner de Oracle.
Las mejores prácticas de redundancia dependen del modelo de conectividad que utilice.
Si utiliza un partner de Oracle
Modelo de conectividad:
Oracle maneja la redundancia de las conexiones físicas entre el partner y Oracle, y la redundancia de las enrutadores en las ubicaciones de FastConnect. Debe manejar el despido de la conexión física entre una red local y el partner de Oracle.
Las mejores prácticas restantes dependen del partner que esté utilizando y de los detalles de la sesión de BGP desde el perímetro local:
- Para algunos partners, la sesión de BGP desde el perímetro local se dirige a Oracle. Al seleccionar el socio, esta conexión a veces se puede etiquetar como L2. Para conocer las mejores prácticas de redundancia, consulte la siguiente sección.
- Para otros partners, la sesión de BGP desde el perímetro local se dirige al partner de Oracle. Al seleccionar el socio, esta conexión a veces se puede etiquetar como L3. Para conocer las mejores prácticas de redundancia, consulte Sesión BGP a Oracle Partner (capa 3).
Para obtener información sobre los dos escenarios, consulte Diagramas de red básicos.
Sesión de BGP a Oracle (capa 2)
Cada partner de Oracle tiene al menos dos conexiones físicas independientes a Oracle. Al crear un circuito virtual FastConnect en la consola, utilice la opción Circuitos virtuales redundantes. Configure un circuito virtual en una conexión física (como principal) y el otro circuito virtual en otra conexión física (como secundario). En el siguiente diagrama, se ilustran estos dos circuitos virtuales, cada uno de los cuales va a un enrutador diferente en una única ubicación FastConnect. Si la región tiene una segunda ubicación, la segunda conexión física del partner puede dirigirse a esa ubicación.
Si está trabajando en una región que solo tiene una ubicación de FastConnect, también puede que desee la diversidad de ubicaciones. Para ello, repita la configuración anterior de dos circuitos virtuales con el mismo socio de Oracle, pero en una segunda ubicación de FastConnect de una región cercana. Observe que debe tener una configuración duplicada de los recursos Oracle en la nube en esa segunda región, como se muestra en el siguiente diagrama.
Sesión de BGP a partner de Oracle (capa 3)
En este escenario, la sesión de BGP desde el perímetro local se dirige al partner de Oracle (como se muestra en el siguiente diagrama). Aparte de esa sesión del BGP, el socio de Oracle tiene sus propias sesiones del BGP con Oracle (entre el perímetro del partner y la perímetro de Oracle). El circuito virtual es una conexión lógica que va desde el perímetro local hasta el perímetro de Oracle.
Un partner de Oracle tiene dos conexiones físicas independientes a Oracle. Cree un circuito virtual con el partner. En este escenario, el circuito virtual se ha diseñado automáticamente para ser redundante y diverso. El circuito virtual tiene dos sesiones de BGP independientes entre el partner y Oracle, cada una en una conexión física diferente. El siguiente diagrama muestra las dos sesiones BGP independientes para el circuito virtual único como líneas punteadas.
Por defecto, un único circuito virtual L3 es redundante entre OCI y el partner de FC por diseño. Esto no garantiza la redundancia entre el partner de Oracle y una red local. En el caso de utilizar un circuito virtual de partners de Oracle L3, trabaje con el partner de Oracle para saber si necesita varios circuitos virtuales para garantizar una redundancia completa de extremo a extremo entre OCI y la red local (no solo la garantía de redundancia de un único circuito virtual L3 entre el partner de Oracle y OCI).
Además, podría decidir crear circuitos virtuales redundantes en un circuito virtual de Oracle Partner L3 cuando necesite: diversidad de ubicación o diversidad de partners.
Usted es responsable de garantizar que la conexión entre el perímetro local y el partner de Oracle sea redundante y diversa.
Si está trabajando en una región que solo tiene una ubicación de FastConnect, también puede que desee la diversidad de ubicaciones. Una forma de lograrlo es repetir la configuración anterior de un circuito virtual con el mismo socio de Oracle, pero en una Segunda ubicación de FastConnect en una región cercana. Observe que también debe tener una configuración duplicada de los recursos del cloud de Oracle en esa segunda región, como se muestra en el siguiente diagrama.
Diversidad de partners
Si también desea diversidad de partners, utilice la opción Circuitos virtuales redundantes y seleccione un partner diferente al crear el circuito virtual 1 y el circuito virtual 2. En este ejemplo se muestran el partner A y el partner B que utilizan diferentes ubicaciones FastConnect para conectarse a la misma VCN. No es necesaria una configuración duplicada de los recursos en la nube de Oracle.
En el siguiente ejemplo se muestran el partner A y el partner B que utilizan la misma ubicación FastConnect para conectarse a la misma VCN.
Si utiliza un proveedor externo o se coloca con Oracle
Modelos de conectividad:
Oracle gestiona la redundancia de los enrutadores de Oracle en las ubicaciones FastConnect. Vd. es responsable de la redundancia de la conexión física entre una red local y Oracle.
Para lograr redundancia, cree dos conexiones físicas a Oracle, una para cada ubicación FastConnect que sirva a la región o para diferentes dispositivos físicos en la misma ubicación FastConnect. Esto significa que, en la consola de Oracle, se configuran dos conexiones FastConnect independientes. A continuación, se crean dos circuitos virtuales. Configure la primera de la primera conexión física (la primera conexión FastConnect) y la segunda de la segunda conexión física. En el siguiente diagrama se muestra la configuración general.
Es posible que decida conectarse a una única ubicación FastConnect debido a problemas de costos o que la región tenga una única ubicación FastConnect. En ese caso, siempre puede crear dos conexiones físicas y asegurarse de que cada una vaya a un enrutador de Oracle diferente en esa ubicación FastConnect.
Si utiliza la opción FastConnect Direct y Single FastConnect en la consola para aumentar la redundancia de las conexiones existentes, debe configurar manualmente la configuración de Specify router Proximity para lograr la redundancia del dispositivo. En la siguiente imagen se muestra una solicitud de una segunda conexión física (que es un grupo de interconexiones) creada en un enrutador diferente al de la primera conexión en esa ubicación FastConnect (denominada MyConnection-1).
Para la creación inicial de interconexiones o grupos de interconexiones redundantes, seleccione FastConnect Direct (Directo) y Device redundancy (Redundancia de dispositivos) y configure dos interconexiones o grupos de interconexiones redundantes donde la segunda está preconfigurada para configurarse en un dispositivo físico (enrutador) diferente al primero.
Si está trabajando en una región que solo tiene una única ubicación FastConnect, también puede lograr la diversidad de ubicaciones repitiendo la configuración en una segunda ubicación FastConnect en una región cercana. Observe que también debe tener una configuración duplicada de los recursos Oracle en la nube en esa segunda región, como se muestra en el siguiente diagrama.
Si está trabajando en una región con dos o más ubicaciones FastConnect, puede utilizar la opción FastConnect Direct y Location redundancy para crear dos interconexiones o grupos de interconexiones redundantes, una por ubicación FastConnect. También puede hacerlo manualmente mediante la creación de un único FastConnects y la selección de diferentes ubicaciones físicas en cada una. No necesita una configuración duplicada de los recursos en la nube de Oracle en esa segunda región, como se muestra en el siguiente diagrama.
Independientemente de cómo logre la redundancia, debe escalar el ancho de banda de ambas conexiones físicas de manera uniforme y utilizando un grupo de interconexiones (también denominado grupo de agregación de enlaces o LAG) para cada conexión. Imagine que tiene dos conexiones cruzadas individuales de 10 Gbps en una única ubicación FastConnect (cada una a un enrutador diferente de Oracle para redundancia y diversidad). Si siempre necesita tener ancho de banda de 20 Gpbs, debe asegurarse de que cada una de las conexiones físicas conste de un grupo de interconexiones que contenga la interconexión. Luego, debe agregar otra interconexión de 10 Gbps a cada grupo de interconexiones, de modo que cada conexión física redundante tenga dos conexiones cruzadas de 10 Gbps.
VPN de sitio a sitio como respaldo para FastConnect
Recomendamos utilizar la VPN de sitio a página como respaldo para una conexión FastConnect. Si lo hace, asegúrese de que los túneles de VPN IPSec de sitio a sitios estén configurados para utilizar el enrutamiento B GP con una VPN basada en rutas. En una red local existente, manipule el enrutamiento para preferir las rutas Conocidas a través del FastConnect sobre las rutas Conocidas a través del Sitio a la VPN de sitio. Por ejemplo, utilice AS_Path Preponer para influir en el tráfico de salida de Oracle y utilizar la preferencia local para influir en el tráfico de salida de una red local.
Si utiliza una copia de seguridad VPN, revise la conducta del enrutamiento de BGP de Oracle en la tabla que se muestra en Uso de AS_PATH para preferir rutas de Oracle a la red local.
En el siguiente diagrama se muestra una configuración con circuitos virtuales redundantes FastConnect y túneles redundantes de VPN de sitio a sitio.
Recursos relacionados
¿Siguiente paso?
Seleccione el tema adecuado para la situación: