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 à l'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 avec soin et planifiée à l'avance afin de minimiser tout impact sur vos services. Cet article décrit ce qui se passe pendant la maintenance d'un circuit virtuel FastConnect et les étapes à suivre pour minimiser les pannes de service dues à une maintenance planifiée ou non planifiée.
Oracle recommande de toujours configurer une connexion principale et une connexion 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 VPN site à site sont configurés pour utiliser le routage BGP. Lors de l'utilisation de ces connexions, Oracle Cloud donne toujours la priorité aux tunnels FastConnect sur les tunnels IPSec à l'aide du mécanisme de pré-ajout du chemin AS.
Les connexions principale et secondaire doivent être établies sur différents périphériques physiques pour offrir une connectivité fiable des ressources sur site 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 soit accessible sur un autre périphérique physique. Pour les connexions de partenaire, contactez votre partenaire FastConnect afin de provisionner un circuit virtuel secondaire sur une connexion croisée de partenaire redondante. Cela vous aiderait à avoir une connexion ininterrompue s'il y a des événements planifiés ou non planifiés. 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 assurée par des connexions redondantes entre OCI et le réseau sur site. L'implémentation de la haute disponibilité maintient le réseau intact pendant toute interruption 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, ainsi que celle 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 tiers et colocalisation, vous êtes chargé d'assurer la redondance entre les routeurs FastConnect et vos propres périphériques en périphérie 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 ci-dessous présentent les circuits virtuels redondants utilisés dans le scénario de partenaire Oracle, le scénario de fournisseur tiers ou de colocalisation avec Oracle, et le VPN IPSec comme sauvegarde pour FastConnect.
Pour plus d'informations, consultez FastConnect Meilleures pratiques en matière de redondance.
Evénements de maintenance et notifications
La maintenance planifiée pour les services FastConnect est soigneusement planifié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 existe toujours au moins un chemin disponible pour accéder au réseau OCI lorsque des circuits redondants sont en place, ce qui minimise toute interruption potentielle.
Pendant la maintenance, Oracle envoie le message bien connu RFC 8326 "BGP GRACEFUL SHUTDOWN 65535:0" à vos périphériques en périphérie CPE avec le préfixe de chemin AS. Si le dispositif CPE accuse réception de ce message, la préférence locale sur le dispositif CPE sera définie sur zéro pour s'assurer que le chemin en cours de maintenance est déconseillé. Le changement de chemin AS est effectué en ajoutant AS 31898 (trois fois) aux routages BGP allant d'OCI vers le CPE. L'envoi de ce message permet au trafic de passer progressivement au chemin redondant.
Vous devez vous assurer que tous les périphériques sur site du chemin sont configurés pour accuser réception du message de communauté d'arrêt progressif AS ou 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 ne serait pas préféré. Il est important de vérifier auprès du fournisseur de services s'ils sont configurés pour autoriser l'ajout d'un préfixe de chemin AS et les messages de 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 lors des activités de maintenance.
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 propre au fournisseur. Vérifiez auprès de vos fournisseurs d'équipement que cette fonctionnalité est intégrée à votre dispositif CPE. Dans le cas contraire, configurez une stratégie de routage entrant pour définir la préférence locale du CPE sur zéro, en fonction de la réception du message de communauté d'arrêt progressif à partir d'OCI.
Les routeurs OCI activent le préfixe de chemin AS lorsque cela est également fait sur les appareils CPE. Il existe une possibilité de routage asymétrique si le déplacement du trafic sur les routeurs internes CPE et 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 dispositifs CPE.
Une fois la maintenance planifiée programmée, vous recevrez une notification 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 serez averti des pannes de service et des incidents de sécurité en utilisant les mêmes mécanismes.
Vérification du basculement de 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 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 dans votre environnement après le test de basculement initial qui peut interrompre le basculement. Si vous le testez uniquement 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. En outre, n'oubliez pas de valider ce retour aux travaux principaux.
Le processus de validation du basculement comporte deux étapes, chacune d'elles étant visible lors de la maintenance du routeur OCI :
- Désactivez le chemin principal à l'aide des préférences locales et du préfixe de chemin AS, puis vérifiez si le trafic passe ou non au chemin secondaire. Le Guide de redondance de la connectivité (PDF) explique comment utiliser le préfixe de chemin AS et les paramètres de préférences locales pour hiérarchiser un chemin particulier. Il doit s'agir du test de basculement principal que vous effectuez, car le processus d'annulation des préférences de 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 site et OCI. Pour arrêter la session BGP, désactivez le circuit virtuel à partir de la console OCI. Cela forcera le trafic à passer par la connexion secondaire.
Vous pouvez afficher le chemin principal en rétablissant les modifications ci-dessus, puis en vérifiant si le trafic est retransmis au chemin principal. Oracle recommande de tester le basculement en cas d'incident à 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é partenaires Oracle, si vous disposez de plusieurs circuits virtuels, vous pouvez valider le basculement à l'aide des méthodes mentionnées ci-dessus. Si vous ne disposez que d'un seul circuit virtuel, vous ne pouvez pas tester le basculement car la redondance n'existe qu'entre le routeur Oracle FastConnect et le fournisseur.
Si votre réseau sur site utilise des pare-feu avec conservation de statut, 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 doivent uniquement être incrémentés sur le chemin actif. Vous pouvez surveiller l'état, la capacité et les performances de votre connexion FastConnect à l'aide de mesures, d'alarmes et de notifications. Pour plus d'informations, reportez-vous à Monitoring et à Notifications.