Documentation Oracle Cloud Infrastructure

Maintenance des circuits virtuels

En savoir plus sur la maintenance planifiée des circuits virtuels FastConnect.

Oracle effectue une maintenance régulière sur les routeurs dédiés à une utilisation avec les circuits virtuels FastConnect. Cette maintenance permet à Oracle d'améliorer la stabilité opérationnelle globale des périphériques en remplaçant le matériel défectueux, en appliquant des patches, etc. Ces activités de maintenance sont cruciales pour l'amélioration des services. Chaque tâche de maintenance est planifiée soigneusement et planifiée à l'avance afin de minimiser tout impact sur les services. Cet article décrit ce qui se passe pendant la maintenance de FastConnect et les mesures à prendre pour minimiser les pannes de service en raison d'une maintenance planifiée ou non planifiée.

Nous vous recommandons de toujours configurer une connexion secondaire principale et redondante à Oracle Cloud Infrastructure. La connexion secondaire redondante peut être un circuit virtuel privé FastConnect ou une connexion IPSec. Lorsqu'une connexion IPSec est utilisée en tant que chemin secondaire, assurez-vous que les tunnels VPN site à site IPSec sont configurés pour utiliser le routage BGP. Lors de l'utilisation de ces connexions, Oracle Cloud donne toujours la priorité à FastConnect sur les tunnels IPSec à l'aide du mécanisme de préfixe de chemin AS.

Etablissez des connexions principales et secondaires sur différents appareils physiques pour offrir une connectivité fiable entre les ressources sur site et OCI. Lors de la création d'une connexion FastConnect secondaire avec FastConnect Direct, utilisez l'option Spécifier la proximité du routeur de la console OCI pour que la connexion secondaire atterrisse sur un autre périphérique physique. Pour les connexions partenaires, travaillez avec le partenaire FastConnect pour provisionner un circuit virtuel secondaire sur une connexion croisée de partenaire redondante. Cela vous permet d'avoir une connectivité ininterrompue lors de tout événement planifié ou non planifié. Pour plus d'informations sur les pratiques de redondance, reportez-vous au Guide de redondance de la connectivité (PDF).

Haute disponibilité dans les circuits virtuels

La haute disponibilité dans les circuits virtuels est obtenue grâce à des connexions redondantes entre OCI et le réseau sur site. L'implémentation de la haute disponibilité maintient le réseau intact lors de toute panne ou activité planifiée. Si vous utilisez le modèle de connectivité partenaire Oracle, Oracle gère la redondance des connexions physiques entre le partenaire et Oracle, ainsi que la redondance des routeurs dans les sites FastConnect. Vous devez gérer la redondance de la connexion physique entre le réseau sur site et le partenaire Oracle. Pour les autres modèles de connectivité FastConnect tels que la colocalisation et le tiers, vous devez assurer la redondance entre les routeurs FastConnect et les périphériques de périphérie du réseau sur site en configurant des circuits virtuels redondants à l'aide de différents routeurs FastConnect physiques fournis par Oracle dans chaque région et à l'emplacement POP FastConnect.

Les topologies réseau suivantes présentent les circuits virtuels redondants utilisés dans le scénario de partenaire Oracle, le fournisseur tiers ou la colocalisation avec le scénario Oracle et le VPN IPSec en tant que sauvegarde pour FastConnect.

Cette image présente une configuration avec un fournisseur Oracle et plusieurs circuits virtuels vers différents routeurs dans un emplacement FastConnect unique.
Cette image illustre une configuration en colocalisation dans laquelle vous disposez de deux connexions physiques et de deux circuits virtuels vers le site FastConnect.
Cette image présente FastConnect avec un VPN site à site en tant que sauvegarde.

Pour plus d'informations, reportez-vous à FastConnect Redundancy Best Practices.

Evénements et notifications de maintenance

La maintenance planifiée des services FastConnect est soigneusement planifiée pour se concentrer sur un routeur FastConnect à la fois afin de garantir une connectivité ininterrompue sur les circuits virtuels pendant la maintenance. Cette approche garantit qu'au moins un chemin est toujours disponible pour accéder aux circuits redondants avec des chemins divers.

Pendant la maintenance, Oracle envoie le message RFC 8326 "BGP GRACEFUL SHUTDOWN 65535:0" aux périphériques en périphérie du CPE, ainsi que le préfixe de chemin AS. Si le dispositif CPE accuse réception de ce message, la préférence locale du dispositif CPE est définie sur zéro pour garantir que le chemin en cours de maintenance n'est plus préféré. La modification du chemin AS est effectuée en ajoutant au début d'Oracle AS 31898 les routages BGP publiés d'OCI vers le CPE. L'envoi de ce message avec l'ajout de préfixe de chemin AS garantit que le trafic passe progressivement au chemin redondant avant l'activité de maintenance.

Assurez-vous que tous les périphériques sur site dans le chemin sont configurés pour accuser réception du message de communauté d'arrêt progressif BGP ou du préfixe de chemin AS. Vérifiez également que la redondance est configurée pour déplacer le trafic vers un autre chemin, au cas où le chemin principal serait déconseillé. Enfin, le cas échéant, contactez le fournisseur de services pour vérifier qu'il prend en charge les messages de préfixe de chemin AS ou de communauté BGP sur la connexion qu'il gère au réseau sur site.

Si le réseau ne prend pas en charge les actions précédentes, vous risquez de subir un routage asymétrique et des suppressions de paquets lors des activités de maintenance.

Remarque

La définition de la préférence locale sur zéro sur le dispositif CPE après réception de la communauté d'arrêt progressif peut être spécifique au fournisseur. Vérifiez auprès des fournisseurs d'équipement que le dispositif CPE dispose de cette fonctionnalité. Sinon, configurez une stratégie de routage entrante pour définir la préférence locale sur le CPE sur zéro, en fonction de la réception du message de communauté d'arrêt progressif d'OCI.

Les routeurs OCI prennent en charge le préfixe de chemin AS lorsqu'il est également pris en charge sur les périphériques CPE. Le routage asymétrique est possible si le transfert de trafic sur le CPE et les routeurs internes OCI ne se produit pas en même temps, en raison d'un retard dans le transfert de trafic. Pour éliminer ces problèmes, nous vous recommandons d'activer la prise en charge du routage asymétrique dans les dispositifs CPE.

Lorsque la maintenance planifiée est programmée, vous êtes averti au moins 14 jours avant les fenêtres de maintenance via les annonces de la console et les notifications par courriel si vous êtes abonné aux notifications par courriel. Les contacts de notification par courriel sont ajoutés et gérés par l'administrateur de service. Vous êtes informé des pannes de service et des incidents de sécurité à l'aide des mêmes mécanismes.

Vérification du basculement de circuit virtuel

Lorsque vous provisionnez des connexions redondantes pour la première fois, vérifiez qu'elles fonctionnent correctement avant de les mettre en production. Répétez la validation régulièrement (tous les 6 mois, tous les ans, etc.) ou avant les fenêtres de maintenance planifiées pour vous assurer que le basculement fonctionne toujours correctement, car des modifications peuvent être apportées après le test de basculement initial qui peut interrompre le basculement. Si vous ne le testez que lors du premier provisionnement de la connectivité redondante, vous risquez de constater qu'elle ne fonctionne pas en cas de panne réelle, ce qui peut être trop tard. En outre, n'oubliez pas de valider le fait de revenir aux travaux principaux.

Le processus de validation de basculement comporte deux étapes, chacune étant visible lors de la maintenance du routeur OCI :

  1. Désélectionnez le chemin principal à l'aide de la préférence locale et du préfixe de chemin AS, puis vérifiez que le trafic passe au chemin secondaire. Le Guide de redondance de la connectivité (PDF) explique comment les paramètres de préfixe de chemin AS et de préférence locale peuvent être utilisés pour hiérarchiser un chemin particulier. Il s'agit du test de basculement principal que vous effectuez, car le processus d'annulation de préférence de chemin est exécuté par OCI pendant la fenêtre de maintenance avant l'arrêt de la session BGP.
  2. Arrêtez temporairement la session BGP principale entre les réseaux sur site et OCI. Pour arrêter la session BGP, désactivez le circuit virtuel à partir de la console OCI. Cela force le trafic à circuler à travers la connexion secondaire. Reportez-vous à la section "Gestion de votre connexion" de la documentation pour le mode FastConnect que vous utilisez (Partenaire, Colocalisé ou Fournisseur tiers). Il ne s'agit pas d'un "arrêt progressif" et peut être repris rapidement après la validation du basculement.

Vous pouvez afficher le chemin principal en annulant les modifications, puis en vérifiant si le trafic est retransmis au chemin principal. Nous vous recommandons de tester le basculement à l'aide des deux méthodes déjà suggérées pour vous assurer que le mécanisme de basculement fonctionne correctement.

Pour les modèles de connectivité partenaires Oracle, si vous disposez de plusieurs circuits virtuels, vous avez la possibilité de valider le basculement à l'aide des méthodes mentionnées précédemment. Si vous ne disposez que d'un seul circuit virtuel, vous n'avez pas la possibilité de tester le basculement, car la redondance existe uniquement entre le routeur Oracle FastConnect et le fournisseur.

Si le réseau sur site utilise des pare-feu avec conservation de statut, vous êtes sujet à des problèmes lors du basculement. Il est donc encore plus important de vous assurer que le basculement du trafic se produit comme prévu.

Les statistiques de trafic peuvent être surveillées sur la console OCI. Les bits reçus et les bits envoyés ne s'incrémentent que sur le chemin actif en cours. Vous pouvez surveiller l'état, la capacité et les performances d'une connexion FastConnect à l'aide de mesures, d'alarmes et de notifications. Pour plus d'informations, reportez-vous à Monitoring et à Notifications.

FAQ

Quel impact peuvent avoir les circuits virtuels redondants ?
Lorsque vous utilisez des circuits virtuels redondants, vous risquez moins de subir des perturbations pendant la maintenance. Si les homologues BGP prennent en charge le préfixe de chemin AS et GSHUT (arrêt progressif), le processus de convergence du trafic est plus rapide et plus fluide. Le trafic passe de manière transparente au chemin secondaire après la reconvergence BGP, éliminant ainsi les interruptions. Dans de tels scénarios, nous ne nous attendons pas à un impact notable. Respectez toujours la documentation décrite précédemment.
Que se passe-t-il si je ne dispose pas de circuits virtuels redondants ?
Si vous utilisez un seul circuit virtuel, vous risquez de rencontrer des interruptions de trafic pendant la fenêtre de maintenance décrite dans la notification. Nous vous recommandons de suivre les Meilleures pratiques de redondance FastConnect pour implémenter des connexions redondantes. Pour une redondance immédiate, la configuration d'une connexion IPSec en tant que chemin redondant peut aider à atténuer les perturbations, en gardant à l'esprit la limitation de bande passante du VPN site à site.
Quelle est la durée d'impact attendue pour les connexions non redondantes ?
La maintenance réelle ne prend pas la totalité du temps spécifié dans l'avis, mais l'impact peut se produire à tout moment dans la fenêtre de maintenance spécifiée. Préparez et planifiez en fonction des heures de début et de fin indiquées.
Puis-je demander une modification du chemin AS en ajoutant plus de 3 fois au début pendant la maintenance ou modifier la configuration GSHUT ?
Non. Les procédures de prédiction du chemin AS et de GSHUT sont normalisées dans le monde entier dans OCI et ne peuvent pas être modifiées pour répondre aux demandes individuelles.
Comment vérifier rapidement la redondance des circuits virtuels ?
Vous pouvez vérifier la redondance via la console OCI. Les circuits virtuels non redondants déclenchent des notifications sur la console indiquant l'absence de redondance : "Ce circuit virtuel FastConnect présente un point de panne unique. Provisionnez une connexion redondante pour éviter les pannes potentielles." Pour confirmer :
  1. Ouvrez la page de détails du circuit virtuel dans la console OCI.
  2. Regardez la section BGP des détails. Le champ Périphérique logique affiche le nom du périphérique hébergeant le circuit virtuel. Pour la redondance, les périphériques logiques de chaque circuit virtuel doivent être différents.
Les deux circuits virtuels atterrissent sur le même périphérique physique. Est-il possible d'effectuer des opérations de maintenance sur un circuit virtuel à la fois ?
La maintenance est effectuée au niveau du périphérique physique, et non au niveau du circuit virtuel. La maintenance sur un périphérique affecte tous les circuits virtuels associés simultanément. Nous vous recommandons d'implémenter des connexions redondantes atterrissant sur différents périphériques physiques pour éviter de tels scénarios. Reportez-vous à la section FastConnect Redundancy Best Practices.
Pourquoi une fenêtre de maintenance a-t-elle été annulée ou replanifiée ?
La maintenance peut être reportée si des problèmes sont identifiés qui pourraient entraîner des perturbations imprévues. La priorité est de terminer la maintenance avec un impact minimal pour vous. La replanification garantit que tous les bloqueurs sont résolus avant de continuer.
J'ai reçu plusieurs notifications avec des dates différentes. Comment puis-je confirmer la programmation de la maintenance ?
Si vous avez plusieurs notifications en raison de la replanification, considérez la dernière notification comme la source définitive de vérité. Toujours planifier en fonction des périodes mises à jour fournies dans la notification la plus récente.
Quelle redondance dois-je provisionner lorsque j'utilise un partenaire Oracle pour fournir une connectivité de couche 3 à OCI ?
Oracle s'assure que nos partenaires offrant une connectivité de couche 3 disposent déjà d'une redondance physique provisionnée pour leur compte. Vous êtes responsable du provisionnement de la redondance préférée pour le partenaire Oracle. Si vous utilisez une région avec un seul emplacement FastConnect et que vous souhaitez également une diversité d'emplacements, envisagez de provisionner un deuxième circuit virtuel pour une région voisine. Pour plus de détails, reportez-vous à Session BGP pour partenaire Oracle (couche 3).
Est-il possible d'utiliser un tunnel VPN site à site comme sauvegarde vers FastConnect ?

Oui. Reportez-vous à VPN site à site en tant que sauvegarde pour FastConnect.

Puis-je demander l'annulation ou la replanification de la maintenance ?
Nous informons tous les clients concernés 14 jours avant la modification concernant la maintenance afin de vous donner suffisamment de temps pour prendre en charge et gérer le réseau sur site. Ces notifications sont envoyées à tous les clients dont les circuits virtuels sont exécutés sur le même appareil. Nous ne pouvons pas répondre aux demandes individuelles des clients en fonction de leur heure ou de leur date de préférence.
Puis-je demander que la notification de maintenance soit envoyée à nouveau ?
Non. Oracle envoie des courriels dans un format automatisé basé sur les ID de compartiment et les OCID de circuit virtuel, et l'automatisation les envoie au courriel de notification associé à ce compartiment. L'équipe de notification client ne peut pas envoyer de courriels individuels. Ces notifications ne se produisent que par lot.
Quand la maintenance FastConnect est-elle généralement programmée ?

Pour minimiser l'impact sur l'entreprise, la maintenance est généralement planifiée pour être effectuée en dehors des heures normales de bureau pour le fuseau horaire du lieu de la région.

Quel est le statut de maintenance ? Nous n'avons pas reçu de notification indiquant que la maintenance était terminée.
La maintenance n'est effectuée que pendant la durée mentionnée dans la notification. Les notifications sont envoyées aux clients au moins 14 jours avant toute activité de maintenance. Les fenêtres de maintenance ont presque toujours assez de temps pour effectuer toutes les tâches requises. Si une fenêtre de maintenance doit être prolongée en raison de circonstances imprévues, une nouvelle notification est envoyée à tous les clients concernés. Si aucune autre notification n'est envoyée, on peut comprendre que la maintenance a été effectuée avec succès dans le délai imparti. Une autre notification est envoyée à tous les clients concernés si une activité de maintenance a été reportée ou annulée.