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 sucede 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 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.
Las conexiones principal 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 withFastConnect 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 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 algún evento planificado o no planificado. 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 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 los de terceros y la 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 con 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 que se utilizan en el escenario de partner de Oracle, el proveedor de terceros o que se colocan con el escenario de Oracle y la VPN IPSec como copia de seguridad para FastConnect.
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 la red de OCI cuando haya circuitos redundantes, lo que minimiza cualquier posible interrupción.
Durante el mantenimiento, Oracle envía el conocido mensaje RFC 8326 "BGP GRACEFUL SHUTDOWN 65535:0" a los dispositivos perimetrales de CPE junto con la ruta AS que se antepone. Si el dispositivo CPE reconoce este mensaje, la preferencia local del dispositivo CPE se establecerá en cero para garantizar que se desprecia la ruta en mantenimiento. El cambio de ruta de AS se realiza anteponiendo AS 31898 (tres veces) a las rutas de BGP que van desde OCI hacia el CPE. El envío de este mensaje permite que el tráfico cambie correctamente a la ruta redundante.
Debe asegurarse de que todos los dispositivos locales de la ruta estén configurados para reconocer la ruta de AS antepuesta o el mensaje Graceful Shutdown Community 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 sea preferida. Es importante consultar con el proveedor de servicios para confirmar si están configurados para permitir que se anteponga la ruta AS y los 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 el dispositivo CPE tiene esta función incorporada o no. 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 OCI permiten que la ruta 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 ocurrir si se produce 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 programe 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 notificará de las interrupciones del servicio y los incidentes de seguridad mediante los mismos mecanismos.
Verificación de failover de circuito virtual
Cuando aprovisione sus conexiones redundantes por primera vez, compruebe que funcionan correctamente antes de colocarlas en producción. Repita la validación de la misma forma 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 en el entorno después de la prueba de failover inicial que puede 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 puede ser demasiado tarde. Además, no se olvide de validar que fallar de nuevo a las obras primarias.
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. A continuación, compruebe si el tráfico cambia a la ruta secundaria o no. 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 debe ser la principal prueba de failover que realice, 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.
- 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 a la ruta principal. Oracle recomienda probar el failover mediante ambos métodos sugeridos anteriormente para garantizar que el mecanismo de failover funcione sin problemas.
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 la conmutación por error, 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 Supervisión y Notificaciones.