Documentación de Oracle Cloud Infrastructure

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 los servicios. En este artículo se describe lo que ocurre durante el mantenimiento de FastConnect y los pasos que se deben seguir para minimizar las interrupciones del servicio debido al mantenimiento planificado o no planificado.

Recomendamos que configure siempre una conexión secundaria principal y redundante a Oracle Cloud Infrastructure. La conexión secundaria redundante puede ser un circuito virtual privado FastConnect o una conexión IPSec. Cuando se utiliza una conexión IPSec como ruta secundaria, asegúrese de que los túneles de VPN de sitio a sitio IPSec estén configurados para utilizar el enrutamiento BGP. Al utilizar estas conexiones, Oracle Cloud siempre da prioridad a los túneles FastConnect sobre IPSec mediante el mecanismo de anteposición de ruta de acceso de AS.

Establezca conexiones primarias y secundarias en diferentes dispositivos físicos para ofrecer una conectividad fiable de los recursos locales a OCI. Al crear una conexión FastConnect secundaria con FastConnect Direct, utilice la opción "especificar proximidad de enrutador" de la consola de OCI para que la conexión secundaria se conecte a un dispositivo físico diferente. Para las conexiones de partner, trabaje con el partner FastConnect para aprovisionar un circuito virtual secundario en una interconexión de partner redundante. Esto le ayuda a tener una conectividad ininterrumpida durante cualquier evento planificado o no planificado. Para obtener información sobre las prácticas de redundancia, consulte la Guía de redundancia de conectividad (PDF).

Alta disponibilidad en circuitos virtuales

La alta disponibilidad en los 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 partner de Oracle, Oracle gestiona la redundancia de las conexiones físicas entre el partner y Oracle, y la redundancia de los 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 de terceros y de colocación, es responsable de garantizar la redundancia entre los enrutadores FastConnect y los dispositivos de perímetro de la red local mediante la configuración de circuitos virtuales redundantes mediante distintos enrutadores FastConnect físicos proporcionados por Oracle en cada región y la ubicación de POP FastConnect.

En las siguientes topologías de red se muestran los circuitos virtuales redundantes utilizados en el escenario de partner de Oracle, el proveedor de terceros o la colocación con escenario de Oracle y la VPN IPSec como copia de seguridad para FastConnect.

Esta imagen muestra una configuración con un proveedor de Oracle y varios circuitos virtuales para diferentes enrutadores en una única ubicación FastConnect.
Esta imagen muestra una configuración de colocación en la que tiene dos conexiones físicas y circuitos virtuales a la ubicación de FastConnect.
En esta imagen se muestra FastConnect con VPN de sitio a sitio como respaldo.

Para obtener más información, consulte FastConnect Redundancy Best Practices.

Notificaciones y eventos de mantenimiento

El mantenimiento planificado para los servicios FastConnect se programa cuidadosamente para centrarse en un enrutador FastConnect a la vez a fin de garantizar una conectividad ininterrumpida a través de circuitos virtuales durante el mantenimiento. Este enfoque garantiza que siempre haya al menos una ruta disponible para acceder a circuitos redundantes con diversas rutas.

Durante el mantenimiento, Oracle envía el mensaje RFC 8326 "BGP GRACEFUL SHUTDOWN 65535:0" a los dispositivos perimetrales de CPE junto con la ruta AS que precede. Si el dispositivo CPE reconoce este mensaje, la preferencia local del dispositivo CPE se establece en cero para garantizar que ya no se prefiera la ruta en mantenimiento. El cambio de ruta de AS se realiza anteponiendo Oracle AS 31898 a las rutas de BGP anunciadas desde OCI al CPE. El envío de este mensaje junto con la ruta de AS antepuesta garantiza que el tráfico cambie correctamente a la ruta redundante antes de la actividad de mantenimiento.

Asegúrese de que todos los dispositivos locales de la ruta estén configurados para confirmar la ruta de AS o el mensaje Graceful Shutdown Community de BGP. Además, valide que la redundancia esté configurada para cambiar el tráfico a una ruta alternativa, en caso de que la ruta principal no sea preferida. Por último, si procede, consulte al proveedor de servicios para confirmar que soporta los mensajes de AS Path anteponibles o de la comunidad BGP en la conexión que gestionan a la red local.

Si la red no admite las acciones anteriores, es probable que experimente enrutamiento asimétrico y descartes de paquetes durante las actividades de mantenimiento.

Nota

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 el dispositivo CPE tiene esta función. Si no es así, configure una política de enrutamiento de entrada para definir la preferencia local en el CPE en cero, en función de recibir el mensaje de cierre controlado de la comunidad de OCI.

Los enrutadores de OCI admiten la ruta AS que se antepone cuando también se admite en dispositivos CPE. El enrutamiento asimétrico es posible si el cambio de tráfico en los enrutadores internos de CPE y OCI no se produce al mismo tiempo, debido a un retraso en el cambio de tráfico. Para eliminar estos problemas, recomendamos activar la compatibilidad con el enrutamiento asimétrico en dispositivos CPE.

Cuando se programa el mantenimiento planificado, se le notificará al menos 14 días antes de las ventanas de mantenimiento mediante Anuncios de consola y también notificaciones por correo electrónico si está suscrito para recibir notificaciones por correo electrónico. El administrador del servicio agrega y gestiona los contactos de notificación por correo electrónico. Se le notifica de las interrupciones del servicio y los incidentes de seguridad mediante los mismos mecanismos.

Verificación de failover de circuito virtual

Al aprovisionar por primera vez conexiones redundantes, compruebe que funcionan correctamente antes de colocarlas en producción. Repita la validación con regularidad (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 después de la prueba de failover inicial que pueden interrumpir el failover. Si solo lo prueba cuando aprovisiona por primera vez la conectividad redundante, corre el riesgo de descubrir que no funciona cuando se produce una interrupción real, que podría ser demasiado tarde. Además, recuerde validar que el fallo vuelva a los trabajos principales.

El proceso de validación de failover tiene dos etapas, cada una de las cuales se observa durante el mantenimiento del enrutador de OCI:

  1. Anule la preferencia de la ruta principal mediante la preferencia local y la ruta AS. A continuación, verifique que el tráfico cambie a la ruta secundaria. La Guía de redundancia de conectividad (PDF) explica cómo se antepone la ruta de AS y se puede utilizar la configuración de preferencias locales para priorizar una ruta concreta. Esta es la prueba de failover principal que se realiza, ya que OCI ejecuta el proceso de anulación de preferencia de ruta de acceso durante la ventana de mantenimiento antes del cierre de la sesión BGP.
  2. Cierre temporalmente 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 obliga al tráfico a fluir a través de la conexión secundaria. Consulte la sección "Gestión de la Conexión" de la documentación para el modo FastConnect que utilice (Socio, Colocado o Proveedor de Terceros). Esto no es un "cierre correcto" y se puede reanudar rápidamente después de validar el failover.

Puede abrir la ruta principal revirtiendo los cambios y, a continuación, comprobando si el tráfico se reenvía a la ruta principal. Recomendamos probar el failover mediante ambos métodos ya sugeridos 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 tiene 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, es propenso a problemas durante la conmutación por error, por lo que es aún más importante garantizar que la conmutación por error de tráfico se realice según lo esperado.

Las estadísticas de tráfico se pueden supervisar en la consola de OCI. Las métricas de bits recibidos y bits enviados solo aumentan en la ruta activa actual. Puede supervisar el estado, la capacidad y el rendimiento de una conexión FastConnect mediante métricas, alarmas y notificaciones. Para obtener más información, consulte Supervisión y Notificaciones.

Preguntas frecuentes

¿Qué impacto pueden tener los circuitos virtuales redundantes?
Cuando utiliza circuitos virtuales redundantes, es menos probable que sufra interrupciones durante el mantenimiento. Si los peers de BGP soportan la ruta AS anterior y GSHUT (cierre controlado), el proceso de convergencia de tráfico es más rápido y fluido. El tráfico cambia sin problemas a la ruta secundaria después de la reconvergencia de BGP, eliminando las interrupciones. En tales escenarios, no esperamos ningún impacto notable. Siga siempre la documentación descrita anteriormente.
¿Qué sucede si no tengo circuitos virtuales redundantes?
Si confía en un único circuito virtual, es posible que experimente interrupciones de tráfico durante la ventana de mantenimiento descrita en la notificación. Recomendamos seguir las Mejores prácticas de redundancia FastConnect para implementar conexiones redundantes. Para una redundancia inmediata, configurar una conexión IPSec como ruta redundante puede ayudar a mitigar las interrupciones, teniendo en cuenta la limitación de ancho de banda de la VPN de sitio a sitio.
¿Cuál es la duración del impacto esperada para conexiones no redundantes?
El mantenimiento real no tarda todo el tiempo especificado en el aviso, pero el impacto se puede producir en cualquier momento dentro de la ventana de mantenimiento especificada. Prepare y planifique en función de las horas de inicio y finalización proporcionadas.
¿Puedo solicitar una modificación en la ruta de AS que se antepone más de 3 veces durante el mantenimiento o cambiar la configuración de GSHUT?
No Los procedimientos para la ruta AS antepuesta y GSHUT están estandarizados globalmente en OCI y no se pueden modificar para adaptarse a solicitudes individuales.
¿Cómo puedo verificar rápidamente la redundancia de un circuito virtual?
Puede verificar la redundancia mediante la consola de OCI. Los circuitos virtuales no redundantes disparan notificaciones en la consola que indican la falta de redundancia y que indican que "Este circuito virtual FastConnect tiene un único punto de fallo. Aprovisione una conexión redundante para evitar posibles interrupciones". Para confirmar:
  1. Abra la página de detalles del circuito virtual en la consola de OCI.
  2. Observe la sección BGP de los detalles. El campo "Dispositivo lógico" (Lógica) muestra el nombre del dispositivo que aloja el circuito virtual. Para la redundancia, los dispositivos lógicos para cada circuito virtual deben ser diferentes.
Ambos circuitos virtuales aterrizan en el mismo dispositivo físico. ¿Es posible realizar el mantenimiento en un circuito virtual a la vez?
El mantenimiento se realiza en el nivel de dispositivo físico, no en el nivel de circuito virtual. El mantenimiento en un dispositivo afecta simultáneamente a todos los circuitos virtuales asociados. Recomendamos implantar conexiones redundantes que lleguen a diferentes dispositivos físicos para evitar estos escenarios. Siga las FastConnect Mejores prácticas de redundancia.
¿Por qué se canceló o reprogramó una ventana de mantenimiento?
El mantenimiento se puede posponer si se identifican problemas que podrían provocar interrupciones imprevistas. La prioridad es completar el mantenimiento con un impacto mínimo en usted. La reprogramación garantiza que todos los bloqueadores se resuelvan antes de continuar.
Recibí varias notificaciones con diferentes fechas. ¿Cómo puedo confirmar cuándo se programa el mantenimiento?
Si tiene varias notificaciones debido a la reprogramación, considere la última notificación como la fuente definitiva de la verdad. Planifique siempre en función de los plazos actualizados proporcionados en la notificación más reciente.
¿Qué redundancia debo aprovisionar al utilizar un partner de Oracle para proporcionar conectividad de capa 3 a OCI?
Oracle garantiza que nuestros partners que ofrecen conectividad de capa 3 ya tengan aprovisionada redundancia física en su nombre. Vd. es responsable de aprovisionar la redundancia preferida al partner de Oracle. Si utiliza una región con una única ubicación FastConnect y también desea diversidad de ubicaciones, considere aprovisionar un segundo circuito virtual en una región cercana. Consulte la sesión de BGP a Oracle Partner (capa 3) para obtener más información.
¿Es posible utilizar un túnel VPN de sitio a sitio como copia de seguridad en FastConnect?

Sí. Consulte la VPN de sitio a sitio como respaldo para FastConnect.

¿Puedo solicitar la cancelación o reprogramación del mantenimiento?
Notificamos a todos los clientes afectados 14 días antes del cambio en relación con el mantenimiento para darle tiempo suficiente para alojar y gestionar la red local. Estas notificaciones se envían a todos los clientes que tienen circuitos virtuales que se ejecutan en el mismo dispositivo. No podemos acomodar solicitudes de clientes individuales en función de sus preferencias de hora o fecha.
¿Puedo solicitar que se vuelva a enviar la notificación de mantenimiento?
No Oracle envía correos electrónicos en un formato automatizado basado en ID de compartimento y OCID de circuito virtual, y la automatización los envía al correo electrónico de notificación asociado a ese compartimento. El equipo de notificación al cliente no puede enviar correos electrónicos individuales. Estas notificaciones solo se producen en un lote.
¿Cuándo se suele programar el mantenimiento de FastConnect?

Para minimizar el impacto empresarial, el mantenimiento se suele programar para que se realice fuera del horario laboral normal para la zona horaria de la ubicación de la región local.

¿Cuál es el estado de mantenimiento? No se ha recibido una notificación de que el mantenimiento ha finalizado.
El mantenimiento solo se realiza durante el tiempo mencionado en la notificación. Las notificaciones se envían a los clientes al menos 14 días antes de cualquier actividad de mantenimiento. Las ventanas de mantenimiento casi siempre tienen tiempo suficiente para completar todas las tareas requeridas. Si es necesario ampliar una ventana de mantenimiento debido a circunstancias imprevistas, se envía una nueva notificación a todos los clientes afectados. Si no se envían más notificaciones, se puede entender que el mantenimiento se ha completado correctamente en el tiempo asignado. Se envía otra notificación a todos los clientes afectados si una actividad de mantenimiento se pospuso o canceló.