Mantenimiento de circuitos virtuales
Obtenga información sobre el mantenimiento planificado de los circuitos virtuales FastConnect.
Oracle realiza un mantenimiento regular en los enrutadores dedicados para su uso con circuitos virtuales FastConnect. Este mantenimiento permite a Oracle mejorar la estabilidad operativa general del dispositivo mediante la sustitución de hardware defectuoso, la aplicación de parches y mucho más. Estas actividades de mantenimiento son cruciales para la mejora del servicio. Cada tarea de mantenimiento se planifica cuidadosamente y se programa con antelación para minimizar cualquier impacto en sus servicios. En este artículo, se describe lo que ocurre durante el mantenimiento de un circuito virtual FastConnect y los pasos que debe seguir para minimizar las interrupciones del servicio debido al mantenimiento planificado o no planificado.
Oracle recomienda configurar siempre una conexión principal y secundaria a Oracle Cloud Infrastructure. La conexión secundaria puede ser un circuito virtual FastConnect redundante o una conexión IPsec. En caso de que la conexión IPSec se utilice como ruta secundaria, asegúrese de que los túneles IPSec de la VPN de sitio a sitio están configurados para utilizar el enrutamiento BGP. Al utilizar estas conexiones, Oracle Cloud siempre prioriza FastConnect sobre los túneles IPSec mediante el mecanismo de anteposición de ruta de AS.
Las conexiones primaria y secundaria se deben establecer en diferentes dispositivos físicos para ofrecer una conectividad fiable de los recursos locales a OCI. Al crear una conexión FastConnect secundaria conFastConnect Direct, utilice la opción "especificar proximidad de enrutador" de la consola de OCI para que la conexión secundaria llegue a un dispositivo físico diferente. Para las conexiones de partner, trabaje con su partner FastConnect para aprovisionar un circuito virtual secundario en una interconexión de partner redundante. Esto le ayudará a tener una conexión ininterrumpida si hay eventos planificados o no planificados. Para obtener información sobre las prácticas de redundancia, siga la Guía de redundancia de conectividad (PDF).
Alta disponibilidad en circuitos virtuales
La alta disponibilidad en circuitos virtuales se logra mediante conexiones redundantes entre OCI y la red local. La implementación de alta disponibilidad mantiene la red intacta durante cualquier interrupción o actividad planificada. En caso de que utilice el modelo de conectividad de socios de Oracle, Oracle gestiona la redundancia de las conexiones físicas entre el socio y Oracle, y la redundancia de enrutadores en las ubicaciones FastConnect. Se espera que maneje la redundancia de la conexión física entre la red local y el partner de Oracle. Para otros modelos de conectividad FastConnect, como terceros y colocación, es responsable de garantizar la redundancia entre los enrutadores FastConnect y sus propios dispositivos de perímetro mediante la configuración de circuitos virtuales redundantes mediante diferentes enrutadores físicos FastConnect proporcionados por Oracle en cada región y la ubicación POP FastConnect.
Las siguientes topologías de red muestran circuitos virtuales redundantes utilizados en el escenario de partner de Oracle, proveedor de terceros o colocación con el escenario de Oracle y VPN IPSec como copia de seguridad para FastConnect.
Para obtener más información, consulte FastConnect Mejores prácticas de redundancia.
Eventos y notificaciones de mantenimiento
El mantenimiento planificado para los servicios FastConnect se ha programado cuidadosamente para centrarse en un enrutador FastConnect a la vez a fin de garantizar una conectividad ininterrumpida en los circuitos virtuales durante el mantenimiento. Este enfoque garantiza que siempre haya al menos una ruta disponible para acceder a la red de OCI cuando haya circuitos redundantes, minimizando cualquier posible interrupción.
Durante el mantenimiento, Oracle envía el conocido mensaje RFC8326 "BGP GRACEFUL SHUTDOWN 65535:0" a los dispositivos perimetrales de CPE junto con la ruta de AS que precede. Si el dispositivo CPE reconoce este mensaje, la preferencia local del dispositivo CPE se establecerá en cero para garantizar que la ruta en mantenimiento se despreferirá. El cambio de ruta de AS se realiza anteponiendo AS 31898 (tres veces) a las rutas BGP que van desde OCI hacia el CPE. El envío de este mensaje permite que el tráfico cambie de forma controlada a la ruta redundante.
Debe asegurarse de que todos los dispositivos locales de la ruta estén configurados para confirmar el antecedente de ruta de AS o el mensaje de la comunidad de cierre controlado de BGP. Además, asegúrese de que la redundancia esté configurada correctamente para cambiar el tráfico a una ruta alternativa, en caso de que la ruta principal no se prefiera. Es importante consultar con el proveedor de servicios para confirmar si están configurados para permitir anteponer la ruta AS y mensajes de la comunidad BGP en la conexión si están gestionando la red.
Si la red no permite las acciones anteriores, es probable que experimente enrutamiento asimétrico y descartes de paquetes durante las actividades de mantenimiento.
La configuración de la preferencia local en cero en el dispositivo CPE después de recibir la comunidad de cierre controlado puede ser específica del proveedor. Valide con los proveedores de equipos que su dispositivo CPE tenga incorporada esta función o no. De lo contrario, configure una política de enrutamiento de entrada para definir la preferencia local en el CPE en cero, según la recepción del mensaje de la comunidad de cierre controlado de OCI.
Los enrutadores de OCI permiten que la ruta de AS se anteponga cuando también se realiza en dispositivos CPE. Existe la posibilidad de un enrutamiento asimétrico si el cambio de tráfico en los enrutadores internos de CPE y OCI no se produce al mismo tiempo, lo que puede suceder si hay un retraso en el cambio de tráfico. Para eliminar estos problemas, recomendamos que active la compatibilidad con el enrutamiento asimétrico en dispositivos CPE.
Cuando se programe el mantenimiento planificado, se le notificará al menos 14 días antes de las ventanas de mantenimiento mediante anuncios de la consola y también notificaciones por correo electrónico si está suscrito a notificaciones por correo electrónico. El administrador del servicio agrega y gestiona los contactos de notificación por correo electrónico. Se le notificarán las interrupciones del servicio y los incidentes de seguridad que utilicen los mismos mecanismos.
Verificación de failover de circuito virtual
Al aprovisionar por primera vez las conexiones redundantes, compruebe que funcionan correctamente antes de ponerlas en producción. Repita la validación de la misma forma de forma regular (cada 6 meses, cada año, etc.) o antes de las ventanas de mantenimiento programadas para asegurarse de que el failover sigue funcionando correctamente, ya que se pueden realizar cambios en el entorno después de la prueba de failover inicial que puede interrumpir el failover. Si solo lo prueba cuando aprovisiona la conectividad redundante por primera vez, corre el riesgo de descubrir que no funciona cuando se produce una interrupción real, lo que puede ser demasiado tarde. Además, no olvide validar que no volver a los trabajos principales.
El proceso de validación de failover tiene dos etapas, cada una de las cuales se verá durante el mantenimiento del enrutador de OCI:
- Anule la preferencia de la ruta principal mediante la preferencia local y la ruta AS precede y, a continuación, compruebe si el tráfico cambia a la ruta secundaria o no. En la Guía de redundancia de conectividad (PDF) se explica cómo se pueden utilizar el anteponente de ruta de AS y la configuración de preferencias locales para priorizar una ruta determinada. Debe ser la prueba de failover principal que realice, ya que OCI ejecuta el proceso de anulación de preferencia de ruta durante la ventana de mantenimiento antes del cierre de la sesión de BGP.
- Cierre la sesión BGP principal entre las redes locales y OCI. Para cerrar la sesión BGP, desactive el circuito virtual de la consola de OCI. Esto obligará al tráfico a fluir a través de la conexión secundaria.
Puede abrir la ruta principal revirtiendo los cambios anteriores y, a continuación, comprobando si el tráfico se reenvía de nuevo a la ruta principal. Oracle recomienda probar el failover utilizando los dos métodos sugeridos anteriormente para garantizar que el mecanismo de failover funcione correctamente.
Para los modelos de conectividad de partners de Oracle, si tiene varios circuitos virtuales, tiene la opción de validar el failover mediante los métodos mencionados anteriormente. Si solo tiene un circuito virtual, no tendrá la opción de probar el failover, ya que la redundancia solo existe entre el enrutador FastConnect de Oracle y el proveedor.
Si la red local utiliza firewalls con estado, será propenso a problemas durante el failover, por lo que es aún más importante asegurarse de que el tráfico realice el failover correctamente.
Las estadísticas de tráfico se pueden supervisar en la consola de OCI. Las métricas de bits recibidos y bits enviados solo deben incrementarse en la ruta que está activa actualmente. Puede supervisar el estado, la capacidad y el rendimiento de la conexión de FastConnect mediante métricas, alarmas y notificaciones. Para obtener más información, consulte https://docs.oracle.com/iaas/Content/Monitoring/home.htm y https://docs.oracle.com/iaas/Content/Notification/home.htm.