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 les services. Cet article décrit ce qui se passe pendant la maintenance FastConnect et les étapes à suivre pour minimiser les interruptions 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 comme chemin secondaire, assurez-vous que les tunnels RPV site-à-site IPSec 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.
Établissez des connexions principales et secondaires 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 atterisse sur un autre appareil physique. Pour les connexions de partenaire, communiquez avec le partenaire FastConnect pour provisionner un circuit virtuel secondaire sur une interconnexion de partenaire redondante. Cela vous permet d'avoir une connectivité ininterrompue lors d'événements planifiés ou non planifiés. Pour plus d'informations sur les pratiques 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. La mise en œuvre de la haute disponibilité maintient le réseau intact pendant toute interruption ou activité planifiée. Dans le cas où vous utilisez le modèle de connectivité du partenaire Oracle, Oracle assure la redondance des connexions physiques entre le partenaire et Oracle, et la redondance des routeurs dans les emplacements FastConnect. Vous devez 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 de tierce partie et la colocalisation, il vous incombe de veiller à la redondance entre les routeurs FastConnect et les appareils en périphérie du réseau sur place en configurant des circuits virtuels redondants à l'aide de différents routeurs FastConnect physiques fournis par Oracle dans chaque région et à l'emplacement FastConnect POP.
Les topologies de réseau suivantes présentent les circuits virtuels redondants utilisés dans le scénario de partenaire Oracle, le fournisseur de tierce partie ou la colocalisation avec le scénario Oracle, et le RPV IPSec comme sauvegarde pour FastConnect.
Pour plus d'informations, consultez FastConnect les 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'au moins un chemin est toujours disponible pour accéder à des circuits redondants avec des chemins divers.
Pendant la maintenance, Oracle envoie le message RFC 8326 "BGP GRACEFUL SHUTDOWN 65535:0" aux appareils en périphérie du CPE, ainsi que le préfixe de chemin AS. Si l'appareil CPE accuse réception de ce message, la préférence locale sur l'appareil CPE est réglée à zéro pour s'assurer que le chemin en cours de maintenance n'est plus privilégié. La modification du chemin AS s'effectue en faisant précéder Oracle AS 31898 des routes BGP annoncées d'OCI vers le CPE. L'envoi de ce message avec le préfixe de chemin AS garantit que le trafic passe correctement au chemin redondant avant l'activité de maintenance.
Assurez-vous que tous les appareils sur place du chemin sont configurés pour accuser réception du préfixe de chemin AS ou du message BGP Graceful Shutdown Community. 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, communiquez avec le fournisseur de services pour confirmer qu'il prend en charge le préfixe de chemin AS ou les messages de communauté BGP sur la connexion qu'il gère au réseau sur place.
Si le réseau ne prend pas en charge les actions précédentes, vous risquez de rencontrer 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 des fournisseurs d'équipement que l'appareil CPE possède cette fonction. 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 prennent en charge la prédiction de chemin AS lorsqu'elle est également prise en charge sur les appareils CPE. Un routage asymétrique est possible 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, en raison d'un 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 êtes 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 êtes avisé des interruptions de service et des incidents de sécurité utilisant les mêmes mécanismes.
Vérification du basculement du 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 programmé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 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 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 que le trafic passe 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 s'agit 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 temporairement 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 oblige le trafic à circuler à travers la connexion secondaire. Voir 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 grave" qui peut être repris rapidement une fois le basculement validé.
Vous pouvez afficher le chemin principal en annulant les modifications, puis en vérifiant si le trafic est réacheminé vers le chemin principal. Nous recommandons de tester le basculement en utilisant les deux méthodes déjà suggérées 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 précédemment. Si vous n'avez qu'un seul circuit virtuel, vous n'avez pas la possibilité de tester le basculement, car la redondance n'existe qu'entre le routeur Oracle FastConnect et le fournisseur.
Si le réseau sur place utilise des pare-feu avec état, vous êtes sujet à des problèmes lors du basculement, il est donc encore plus important de s'assurer que le basculement de trafic se produit comme prévu.
Les statistiques de trafic peuvent être surveillées dans la console OCI. Les bits reçus et les bits envoyés ne s'incrémentent que sur le chemin actif courant. Vous pouvez surveiller l'état, la capacité et la performance d'une connexion FastConnect à l'aide des mesures, des alarmes et des avis. Pour plus d'informations, voir Surveillance et Avis.
Foire aux questions
- Quelle incidence les circuits virtuels redondants peuvent-ils avoir?
- Lorsque vous utilisez des circuits virtuels redondants, vous êtes moins susceptible de subir des interruptions pendant la maintenance. Si les pairs BGP prennent en charge la pré-saisie de chemin AS et GSHUT (arrêt réussi), le processus de convergence du trafic est plus rapide et plus fluide. Le trafic passe de façon 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 n'ai pas de circuits virtuels redondants?
- Si vous comptez sur un seul circuit virtuel, vous risquez de rencontrer des interruptions de trafic pendant la fenêtre de maintenance indiquée dans l'avis. Nous vous recommandons de suivre les meilleures pratiques en matière de redondance FastConnect pour mettre en oeuvre des connexions redondantes. Pour une redondance immédiate, la configuration d'une connexion IPSec en tant que chemin redondant peut aider à atténuer les interruptions, en gardant à l'esprit la limitation de la bande passante du RPV site à site.
- Quelle est la durée d'impact attendue pour les connexions non redondantes?
- La maintenance réelle ne prend pas tout le temps spécifié dans l'avis, mais l'incidence peut survenir à tout moment dans la fenêtre de maintenance spécifiée. Préparer et planifier en fonction des heures de début et de fin fournies.
- Puis-je demander une modification du préfixe de chemin AS plus de 3 fois au cours de la maintenance ou modifier la configuration GSHUT?
- Non. Les procédures de précalcul des chemins AS et de GSHUT sont normalisées globalement 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 au moyen de la console OCI. Les circuits virtuels non redondants déclenchent des avis sur la console indiquant l'absence de redondance indiquant "Ce circuit virtuel FastConnect présente un point de défaillance unique. Provisionnez une connexion redondante pour éviter les pannes potentielles. " Pour confirmer :
- Ouvrez la page des détails du circuit virtuel dans la console OCI.
- Regardez la section BGP des détails. Le champ " Dispositif 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 appareil physique. Est-il possible d'effectuer la 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 seul appareil a une incidence sur tous les circuits virtuels associés simultanément. Nous vous recommandons d'implémenter des connexions redondantes atterrissant sur différents appareils physiques pour éviter de tels scénarios. Suivez les FastConnect Best Practices pour la redondance.
- Pourquoi une fenêtre de maintenance a-t-elle été annulée ou reprogrammée?
- La maintenance peut être reportée si des problèmes identifiés peuvent entraîner des perturbations imprévues. La priorité est d'effectuer la maintenance avec un impact minimal pour vous. La reprogrammation 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 reprogrammation, considérez la dernière notification comme la source définitive de vérité. Planifiez toujours en fonction des intervalles de temps mis à jour fournis dans l'avis le plus récent.
- Quelle redondance dois-je provisionner lorsque j'utilise un partenaire Oracle pour fournir une connectivité de couche 3 à OCI?
- Oracle s'assure que la redondance physique est déjà provisionnée pour la connectivité de couche 3 de nos partenaires en leur nom. Il vous incombe de provisionner la redondance privilégiée au partenaire Oracle. Si vous utilisez une région avec un seul emplacement FastConnect et que vous voulez également la diversité des emplacements, envisagez de provisionner un deuxième circuit virtuel pour une région voisine. Pour plus de détails, voir Session BGP au partenaire Oracle (couche 3).
- Est-il possible d'utiliser un tunnel RPV site à site en tant que sauvegarde vers FastConnect?
-
Oui. Voir RPV site à site en tant que sauvegarde pour FastConnect.
- Puis-je demander que la maintenance soit annulée ou reprogrammée?
- Nous avisons tous les clients concernés 14 jours avant la modification de la maintenance pour vous donner suffisamment de temps pour adapter et gérer le réseau sur place. Ces avis sont envoyés à tous les clients qui ont des circuits virtuels exécutés sur le même appareil. Nous ne pouvons pas répondre aux demandes individuelles des clients en fonction de leurs préférences d'heure ou de date.
- Puis-je demander que l'avis de maintenance soit envoyé de nouveau?
- Non. Oracle envoie les courriels dans un format automatisé basé sur les ID compartiment et les OCID de circuit virtuel, et l'automatisation les envoie au courriel d'avis associé à ce compartiment. L'équipe d'avis au client ne peut pas envoyer de courriels individuels, ces avis se produisent uniquement dans un lot.
- Quand la maintenance FastConnect est-elle généralement programmée?
-
Pour minimiser l'incidence sur les activités, la maintenance est généralement programmée pour être effectuée en dehors des heures d'ouverture normales pour le fuseau horaire de l'emplacement de la région locale.
- Quel est le statut de maintenance? Nous n'avons pas reçu d'avis indiquant que la maintenance était terminée.
- La maintenance n'est effectuée que pendant le temps mentionné dans la notification. Les avis sont envoyés aux clients au moins 14 jours avant toute activité de maintenance. Les fenêtres de maintenance disposent presque toujours de suffisamment 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, un nouvel avis est envoyé à tous les clients concernés. Si aucun autre avis n'est envoyé, il est possible de comprendre que la maintenance a été effectuée avec succès dans le délai imparti. Un autre avis est envoyé à tous les clients touchés si une activité de maintenance a été reportée ou annulée.