Virtual Circuits warten
Erfahren Sie mehr über die geplante Wartung von FastConnect-Virtual Circuits.
Oracle führt regelmäßige Wartungsarbeiten an den Routern durch, die für die Verwendung mit Virtual Circuits der Version FastConnect dediziert sind. Durch diese Wartung kann Oracle die allgemeine Stabilität des Gerätebetriebs verbessern, indem fehlerhafte Hardware ersetzt, Patches eingespielt und vieles mehr wird. Diese Wartungsaktivitäten sind entscheidend für die Serviceverbesserung. Jede Wartungsaufgabe wird sorgfältig geplant und im Voraus geplant, um die Auswirkungen auf Ihre Services zu minimieren. In diesem Artikel wird erläutert, was während der Wartung eines Virtual Circuits von FastConnect geschieht, und welche Schritte Sie unternehmen sollten, um Serviceausfälle aufgrund geplanter oder ungeplanter Wartung zu minimieren.
Oracle empfiehlt, dass Sie immer eine primäre und sekundäre Verbindung zu Oracle Cloud Infrastructure konfigurieren. Die sekundäre Verbindung kann entweder ein redundanter Virtual Circuit vom Typ FastConnect oder eine Verbindung vom Typ IPsec sein. Wenn die Verbindung IPSec als sekundärer Pfad verwendet wird, stellen Sie sicher, dass die IPSec-Tunnel des Site-to-Site-VPN für die Verwendung von BGP-Routing konfiguriert sind. Bei der Verwendung solcher Verbindungen priorisiert Oracle Cloud immer FastConnect gegenüber IPSec-Tunneln mit dem AS-Pfad-Voransetzungsmechanismus.
Die primären und sekundären Verbindungen sollten auf verschiedenen physischen Geräten hergestellt werden, um eine zuverlässige Konnektivität von On Premise zu OCI-Ressourcen zu bieten. Beim Erstellen einer sekundären FastConnect-Verbindung mit FastConnect Direct verwenden Sie die Option "Routernähe angeben" in der OCI-Konsole, damit die sekundäre Verbindung auf einem anderen physischen Gerät landen kann. Arbeiten Sie bei Partnerverbindungen mit Ihrem FastConnect-Partner zusammen, um einen sekundären Virtual Circuit auf einem redundanten Partner-Crossconnect bereitzustellen. Dies würde Ihnen helfen, eine ununterbrochene Verbindung zu haben, wenn es geplante oder ungeplante Ereignisse gibt. Informationen zu Redundanzpraktiken finden Sie im Leitfaden zur Konnektivitätsredundanz (PDF).
Hochverfügbarkeit in Virtual Circuits
High Availability in Virtual Circuits wird durch redundante Verbindungen zwischen OCI und dem On-Premise-Netzwerk erreicht. Durch die Implementierung von High Availability bleibt das Netzwerk bei Ausfällen oder geplanten Aktivitäten intakt. Wenn Sie das Konnektivitätsmodell des Oracle-Partners verwenden, sorgt Oracle für die Redundanz der physischen Verbindungen zwischen Partner und Oracle und von Routern in den FastConnect-Verzeichnissen. Es wird erwartet, dass Sie die Redundanz der physischen Verbindung zwischen dem On-Premise-Netzwerk und dem Oracle-Partner verarbeiten. Für andere FastConnect-Konnektivitätsmodelle wie Drittanbieter- und Colocation-Modelle sind Sie dafür verantwortlich, die Redundanz zwischen FastConnect-Routern und Ihren eigenen Edge-Geräten sicherzustellen, indem Sie redundante Virtual Circuits mit verschiedenen physischen FastConnect-Routern konfigurieren, die von Oracle in jeder Region und im FastConnect-POP-Speicherort bereitgestellt werden.
Die folgenden Netzwerktopologien zeigen redundante Virtual Circuits, die im Oracle-Partnerszenario verwendet werden, Drittanbieter oder Colocation mit dem Oracle-Szenario und IPSec VPN als Backup für FastConnect.
Weitere Informationen finden Sie unter FastConnect Redundanz - Best Practices.
Wartungsereignisse und -benachrichtigungen
Die geplante Wartung für FastConnect-Services wird sorgfältig geplant, damit der Schwerpunkt jeweils auf einem FastConnect-Router liegt, um während der Wartung eine unterbrechungsfreie Konnektivität über Virtual Circuits sicherzustellen. Dieser Ansatz stellt sicher, dass immer mindestens ein verfügbarer Pfad für den Zugriff auf das OCI-Netzwerk verfügbar ist, wenn redundante Schaltkreise vorhanden sind, wodurch potenzielle Unterbrechungen minimiert werden.
Während der Wartung sendet Oracle die bekannte RFC 8326-Nachricht "BGP GRACEFUL SHUTDOWN 65535:0" zusammen mit der AS-Pfadvoraussetzung an Ihre CPE-Edge-Geräte. Wenn das CPE-Gerät diese Meldung bestätigt, wird die lokale Voreinstellung auf dem CPE-Gerät auf Null gesetzt, um sicherzustellen, dass der Pfad, der gerade gewartet wird, nicht bevorzugt wird. Die AS-Pfadänderung erfolgt durch Voranstellen von AS 31898 (drei Mal) an die BGP-Routen, die von OCI zum CPE gehen. Durch das Senden dieser Nachricht kann der Traffic ordnungsgemäß in den redundanten Pfad verschoben werden.
Sie müssen sicherstellen, dass alle On-Premise-Geräte im Pfad so eingerichtet sind, dass die AS-Pfadvoreinstellung oder die BGP-Nachricht für das ordnungsgemäße Herunterfahren der Community bestätigt wird. Stellen Sie außerdem sicher, dass die Redundanz richtig konfiguriert ist, um den Traffic in einen alternativen Pfad zu verschieben, falls der primäre Pfad nicht bevorzugt wird. Es ist wichtig, beim Serviceprovider zu prüfen, ob er so eingerichtet ist, dass er AS-Pfadvoraussetzungen und BGP-Communitynachrichten in der Verbindung zulässt, wenn er das Netzwerk verwaltet.
Wenn Ihr Netzwerk die oben genannten Aktionen nicht zulässt, treten bei Wartungsaktivitäten wahrscheinlich asymmetrisches Routing und Paketlöschungen auf.
Wenn Sie die lokale Voreinstellung auf dem CPE-Gerät auf Null setzen, nachdem die Community für ordnungsgemäßes Herunterfahren empfangen wurde, kann dies herstellerspezifisch sein. Überprüfen Sie bei Ihren Geräteanbietern, ob dieses Feature auf Ihrem CPE-Gerät integriert ist oder nicht. Wenn nicht, konfigurieren Sie eine eingehende Routing-Policy, um die lokale Voreinstellung im CPE auf Null zu setzen, je nachdem, ob die Communitynachricht für das ordnungsgemäße Herunterfahren von OCI empfangen wird.
OCI-Router aktivieren AS-Pfadvoraussetzungen, wenn sie auch auf CPE-Geräten ausgeführt werden. Es besteht die Möglichkeit eines asymmetrischen Routings, wenn die Trafficverschiebung auf CPE- und OCI-internen Routern nicht gleichzeitig erfolgt. Dies kann passieren, wenn sich der Traffic verzögert. Um solche Probleme zu vermeiden, empfehlen wir Ihnen, die Unterstützung für asymmetrisches Routing in CPE-Geräten zu aktivieren.
Wenn die geplante Wartung geplant ist, werden Sie mindestens 14 Tage vor den Wartungsfenstern über Konsolenankündigungen und E-Mail-Benachrichtigungen benachrichtigt, wenn Sie E-Mail-Benachrichtigungen abonniert haben. E-Mail-Benachrichtigungskontakte werden vom Serviceadministrator hinzugefügt und verwaltet. Sie werden über Serviceausfälle und Sicherheitsvorfälle mit denselben Mechanismen benachrichtigt.
Failover des Virtual Circuits prüfen
Wenn Sie Ihre redundanten Verbindungen zum ersten Mal bereitstellen, prüfen Sie, ob sie korrekt funktionieren, bevor Sie sie in die Produktion aufnehmen. Wiederholen Sie die Validierung regelmäßig (alle 6 Monate, jedes Jahr usw.) oder vor geplanten Wartungsfenstern, um sicherzustellen, dass das Failover weiterhin ordnungsgemäß funktioniert, da nach dem ersten Failover-Test, der das Failover durchbrechen kann, Änderungen in Ihrer Umgebung vorgenommen werden können. Wenn Sie es nur testen, wenn Sie die redundante Konnektivität zum ersten Mal bereitstellen, besteht das Risiko, dass es nicht funktioniert, wenn ein tatsächlicher Ausfall auftritt, der möglicherweise zu spät ist. Vergessen Sie auch nicht, zu validieren, dass Fehler zurück zu den primären Arbeiten.
Der Failover-Validierungsprozess umfasst zwei Phasen, von denen jede während der Wartung des OCI-Routers zu sehen ist:
- Ziehen Sie den primären Pfad mit lokalen Voreinstellungen und AS-Pfadvoranhängern zurück, und prüfen Sie dann, ob Traffic in den sekundären Pfad verschoben wird. Im Leitfaden zur Konnektivitätsredundanz (PDF) wird erläutert, wie der AS-Pfad und die lokalen Voreinstellungen verwendet werden können, um einen bestimmten Pfad zu priorisieren. Dies sollte der wichtigste Failover-Test sein, den Sie ausführen, da der Pfad-Deprefer-Prozess von OCI während des Wartungsfensters vor dem Herunterfahren der BGP-Session ausgeführt wird.
- Fahren Sie die primäre BGP-Session zwischen den On-Premise- und OCI-Netzwerken herunter. Um die BGP-Session herunterzufahren, deaktivieren Sie den Virtual Circuit über die OCI-Konsole. Dadurch wird der Verkehr durch die sekundäre Verbindung fließen.
Sie können den primären Pfad aufrufen, indem Sie die oben genannten Änderungen zurücksetzen und dann prüfen, ob der Traffic wieder an den primären Pfad weitergeleitet wird. Oracle empfiehlt, Failover mit beiden oben vorgeschlagenen Methoden zu testen, um sicherzustellen, dass der Failover-Mechanismus reibungslos funktioniert.
Bei Konnektivitätsmodellen von Oracle-Partnern können Sie bei mehreren Virtual Circuits das Failover mit den oben genannten Methoden validieren. Wenn Sie nur einen Virtual Circuit verwenden, können Sie das Failover nicht testen, da die Redundanz nur zwischen dem Oracle FastConnect-Router und dem Provider vorhanden ist.
Wenn Ihr On-Premise-Netzwerk zustandsbehaftete Firewalls verwendet, sind Sie beim Failover anfällig für Probleme. Daher ist es noch wichtiger, sicherzustellen, dass der Traffic ordnungsgemäß ausgefallen ist.
Trafficstatistiken können in der OCI-Konsole überwacht werden. Die empfangenen Bit und gesendeten Bitmetriken dürfen sich nur auf dem Pfad erhöhen, der derzeit aktiv ist. Sie können die Integrität, Kapazität und Performance Ihrer FastConnect-Verbindung mit Metriken, Alarmen und Benachrichtigungen überwachen. Weitere Informationen finden Sie unter Monitoring und Notifications.