Gestion 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 à l'utilisation avec les circuits virtuels FastConnect. Cette maintenance permet à Oracle d'améliorer la stabilité opérationnelle globale de l'appareil en remplaçant le matériel défectueux, en appliquant des correctifs, etc. Ces activités de maintenance sont cruciales pour l'amélioration des services. Chaque tâche de maintenance est planifiée avec soin et programmée à l'avance afin de minimiser toute incidence sur vos services. Cet article décrit ce qui se passe lors de la maintenance d'un circuit virtuel FastConnect et les étapes à suivre pour réduire les interruptions de service dues à une maintenance planifiée ou non planifiée.
Oracle recommande de toujours configurer une connexion principale et secondaire à Oracle Cloud Infrastructure. La connexion secondaire peut être un circuit virtuel FastConnect redondant ou une connexion IPsec. Si la connexion IPSec est utilisée comme chemin secondaire, assurez-vous que les tunnels IPSec de RPV site à site sont configurés pour utiliser le routage BGP. Lors de l'utilisation de telles connexions, Oracle Cloud donne toujours la priorité à FastConnect par rapport aux tunnels IPSec à l'aide du mécanisme de préfixe de chemin AS.
Les connexions principale et secondaire doivent être établies sur différents appareils physiques pour offrir une connectivité fiable des ressources sur place aux ressources 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 appareil physique. Pour les connexions de partenaire, communiquez avec votre partenaire FastConnect pour provisionner un circuit virtuel secondaire sur une interconnexion de partenaire redondante. Cela vous aidera à avoir une connexion ininterrompue s'il y a des événements planifiés ou non planifiés. Pour plus d'informations sur les pratiques en matière de redondance, consultez le guide sur la redondance de connectivité (PDF).
Haute disponibilité dans les circuits virtuels
La haute disponibilité dans les circuits virtuels est assurée par des connexions redondantes entre OCI et le réseau sur place. 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é de partenaire Oracle, Oracle gère la redondance des connexions physiques entre le partenaire et Oracle, et la redondance des routeurs dans les emplacements FastConnect. Vous êtes censé gérer la redondance de la connexion physique entre le réseau sur place et le partenaire Oracle. Pour d'autres modèles de connectivité FastConnect tels que la tierce partie et la colocalisation, vous devez assurer la redondance entre les routeurs FastConnect et vos propres appareils en périphérie de réseau en configurant des circuits virtuels redondants à l'aide de différents routeurs physiques FastConnect fournis par Oracle dans chaque région et de l'emplacement POP FastConnect.
Les topologies de réseau ci-dessous 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 RPV IPSec comme sauvegarde pour FastConnect.
Pour plus de renseignements, consultez la page FastConnect Meilleures pratiques en matière de redondance.
Événements et avis de maintenance
La maintenance planifiée des services FastConnect est soigneusement programmée pour se concentrer sur un routeur FastConnect à la fois afin d'assurer une connectivité ininterrompue sur les circuits virtuels pendant la maintenance. Cette approche garantit qu'il y a toujours au moins un chemin disponible pour accéder au réseau OCI lorsque des circuits redondants sont en place, réduisant ainsi les interruptions potentielles.
Pendant la maintenance, Oracle envoie le message bien connu RFC 8326 "BGP GRACEFUL SHUTDOWN 65535:0" à vos appareils en périphérie de réseau CPE, ainsi que l'ajout d'un préfixe de chemin AS. Si le périphérique CPE accuse réception de ce message, la préférence locale sur le périphérique CPE sera réglée à zéro pour s'assurer que le chemin en cours de maintenance est désélectionné. Le changement de chemin AS est effectué en ajoutant le préfixe AS 31898 (trois fois) aux routes BGP allant d'OCI vers le CPE. L'envoi de ce message permet au trafic de passer correctement au chemin redondant.
Vous devez vous assurer que tous les appareils sur place dans le chemin sont configurés pour accuser réception du préfixe de chemin AS ou du message de communauté d'arrêt gracieux BGP. Assurez-vous également que la redondance est configurée correctement pour déplacer le trafic vers un autre chemin, au cas où le chemin principal serait désapprouvé. Il est important de vérifier auprès du fournisseur de services s'ils sont configurés pour autoriser la prédiction du chemin AS et les messages de la communauté BGP sur la connexion s'ils gèrent votre réseau.
Si votre réseau n'autorise pas les actions ci-dessus, vous risquez de subir un routage asymétrique et des abandons de paquets pendant les activités de maintenance.
Le réglage de la préférence locale à zéro sur l'appareil CPE après réception de la communauté d'arrêt gracieux peut être propre au fournisseur. Vérifiez auprès de vos fournisseurs d'équipement que cette fonction est intégrée ou non à votre équipement local d'abonné. Sinon, configurez une politique d'acheminement entrant pour régler la préférence locale sur l'équipement local d'abonné à zéro, en fonction de la réception du message de communauté d'arrêt gracieux d'OCI.
Les routeurs OCI activent la prédiction de chemin AS lorsqu'elle est également effectuée sur des appareils CPE. Il est possible d'effectuer un routage asymétrique si le déplacement du trafic sur les routeurs internes de l'équipement local d'abonné et d'OCI ne se produit pas en même temps, ce qui peut se produire en cas de retard dans le déplacement du trafic. Pour éliminer ces problèmes, nous vous recommandons d'activer la prise en charge du routage asymétrique dans les équipements locaux d'abonné.
Lorsque la maintenance planifiée est programmée, vous serez avisé au moins 14 jours avant les fenêtres de maintenance au moyen des annonces de la console et des avis par courriel si vous êtes abonné aux avis par courriel. Les contacts d'avis par courriel sont ajoutés et gérés par l'administrateur de service. Vous serez avisé des pannes de service et des incidents de sécurité utilisant les mêmes mécanismes.
Vérification du basculement du circuit virtuel
Lorsque vous provisionnez vos connexions redondantes pour la première fois, vérifiez qu'elles fonctionnent correctement avant de les mettre en production. Répétez la validation de la même manière régulièrement (tous les 6 mois, tous les ans, etc.) ou avant les fenêtres de maintenance programmées pour vous assurer que le basculement fonctionne toujours correctement, car des modifications peuvent être apportées dans votre environnement après le test de basculement initial qui peut interrompre le basculement. Si vous ne le testez que lorsque vous provisionnez la connectivité redondante pour la première fois, vous risquez de découvrir qu'elle ne fonctionne pas lorsqu'une panne réelle se produit, ce qui peut être trop tard. Aussi, n'oubliez pas de valider que le retour aux travaux primaires.
Le processus de validation du basculement comporte deux étapes, chacune étant visible lors de la maintenance du routeur OCI :
- Préférez le chemin principal à l'aide de la préférence locale et du préfixe du chemin AS, puis vérifiez si le trafic passe ou non au chemin secondaire. Le guide sur la redondance de connectivité (PDF) explique comment le préfixe de chemin AS et les paramètres de préférence locale peuvent être utilisés pour prioriser un chemin particulier. Il doit s'agir du test principal de basculement que vous effectuez, car le processus de dépréciation du chemin est exécuté par OCI pendant la fenêtre de maintenance avant l'arrêt de la session BGP.
- Arrêtez la session BGP principale entre les réseaux sur place et OCI. Pour arrêter la session BGP, désactivez le circuit virtuel à partir de la console OCI. Cela forcera le trafic à circuler à travers la connexion secondaire.
Vous pouvez afficher le chemin principal en annulant les modifications ci-dessus, puis en vérifiant si le trafic est réacheminé vers le chemin principal. Oracle recommande de tester le basculement à l'aide des deux méthodes suggérées ci-dessus pour garantir le bon fonctionnement du mécanisme de basculement.
Pour les modèles de connectivité de partenaire Oracle, si vous avez plusieurs circuits virtuels, vous avez la possibilité de valider le basculement en utilisant les méthodes mentionnées ci-dessus. Si vous n'avez qu'un seul circuit virtuel, vous n'aurez pas la possibilité de tester le basculement, car la redondance n'existe qu'entre le routeur Oracle FastConnect et le fournisseur.
Si votre réseau sur place utilise des pare-feu avec état, vous serez sujet à des problèmes lors du basculement, il est donc encore plus important de vous assurer que le trafic basculera correctement.
Les statistiques de trafic peuvent être surveillées sur la console OCI. Les bits reçus et les bits envoyés métriques ne doivent incrémenter que sur le chemin qui est actuellement actif. Vous pouvez surveiller l'état, la capacité et la performance de votre connexion FastConnect à l'aide de mesures, d'alarmes et d'avis. Pour plus d'informations, voir Surveillance et Avis.