Oracle Cloud Infrastructure - Dokumentation

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 FastConnect Virtual Circuits dediziert sind. Durch diese Wartung kann Oracle die allgemeine Stabilität des Gerätebetriebs verbessern, indem fehlerhafte Hardware ersetzt, Patches eingespielt werden usw. Diese Wartungsaktivitäten sind für die Serviceverbesserung von entscheidender Bedeutung. Jede Wartungsaufgabe wird sorgfältig geplant und im Voraus geplant, um die Auswirkungen auf Services zu minimieren. Dieser Artikel beschreibt, was während der Wartung von FastConnect passiert und welche Schritte zur Minimierung von Serviceausfällen aufgrund geplanter oder ungeplanter Wartung unternommen werden müssen.

Es wird empfohlen, immer eine primäre und redundante sekundäre Verbindung zu Oracle Cloud Infrastructure zu konfigurieren. Die redundante sekundäre Verbindung kann entweder ein privater Virtual Circuit FastConnect oder eine Verbindung IPSec sein. Wenn eine IPSec-Verbindung als sekundärer Pfad verwendet wird, stellen Sie sicher, dass die IPSec-Tunnel des Site-to-Site-VPNs für die Verwendung von BGP-Routing konfiguriert sind. Während diese Verbindungen verwendet werden, priorisiert Oracle Cloud FastConnect immer über IPSec-Tunnel mit dem AS Path Prepend-Mechanismus.

Richten Sie primäre und sekundäre Verbindungen auf verschiedenen physischen Geräten ein, um eine zuverlässige Konnektivität von On-Premises- zu OCI-Ressourcen zu bieten. Verwenden Sie beim Erstellen einer sekundären FastConnect-Verbindung mit FastConnect Direct die Option "Routernähe angeben" in der OCI-Konsole, um die sekundäre Verbindung auf einem anderen physischen Gerät zu landen zu lassen. Arbeiten Sie bei Partnerverbindungen mit dem FastConnect-Partner zusammen, um einen sekundären Virtual Circuit auf einem redundanten Partner-Crossconnect bereitzustellen. Dies hilft Ihnen, während geplanter oder ungeplanter Ereignisse eine ununterbrochene Konnektivität zu haben. Informationen zu Redundanzpraktiken finden Sie im Leitfaden zur Konnektivitätsredundanz (PDF).

Hohe Verfü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 für Oracle-Partner verwenden, sorgt Oracle für die Redundanz der physischen Verbindungen zwischen dem Partner und Oracle und für die Redundanz der Router in den FastConnect-Speicherorten. Es wird erwartet, dass Sie die Redundanz der physischen Verbindung zwischen dem On-Premise-Netzwerk und dem Oracle-Partner bewältigen. Bei anderen FastConnect-Konnektivitätsmodellen wie Drittanbieter und Colocation sind Sie dafür verantwortlich, Redundanz zwischen FastConnect-Routern und den Edge-Geräten des On-Premise-Netzwerks sicherzustellen, indem Sie redundante Virtual Circuits mit verschiedenen physischen FastConnect-Routern konfigurieren, die von Oracle in jeder Region und in jedem FastConnect-POP-Speicherort bereitgestellt werden.

Die folgenden Netzwerktopologien zeigen redundante Virtual Circuits, die im Oracle-Partnerszenario, im Drittanbieter oder in der Colocation mit Oracle-Szenario verwendet werden, und IPSec VPN als Backup für FastConnect.

Diese Abbildung zeigt ein Setup mit einem Oracle-Provider und mehreren Virtual Circuit zu verschiedenen Routern an einem einzigen FastConnect-Verzeichnis.
Diese Abbildung zeigt ein Colocation-Setup, das aus zwei physischen Verbindungen und Virtual Circuits zum FastConnect-Speicherort besteht.
Diese Abbildung zeigt FastConnect mit Site-to-Site-VPN als Backup.

Weitere Informationen finden Sie unter FastConnect Best Practices für Redundanz.

Wartungsereignisse und Benachrichtigungen

Die geplante Wartung für FastConnect-Services wird sorgfältig geplant, um sich auf jeweils einen FastConnect-Router zu konzentrieren, um eine unterbrechungsfreie Konnektivität über Virtual Circuits während der Wartung sicherzustellen. Dieser Ansatz stellt sicher, dass immer mindestens ein Pfad verfügbar ist, um auf redundante Schaltungen mit verschiedenen Pfaden zuzugreifen.

Während der Wartung sendet Oracle die RFC 8326-Nachricht "BGP GRACEFUL SHUTDOWN 65535:0" zusammen mit der AS-Pfadvoraussetzung an CPE-Edge-Geräte. Wenn das CPE-Gerät diese Nachricht bestätigt, wird die lokale Voreinstellung auf dem CPE-Gerät auf Null gesetzt, um sicherzustellen, dass der Pfad, der in Wartung geht, nicht mehr bevorzugt wird. Die AS-Pfadänderung erfolgt, indem Oracle AS 31898 den BGP-Routen vorangestellt wird, die von OCI an das CPE angeboten werden. Durch das Senden dieser Nachricht zusammen mit der AS-Pfadvoraussetzung wird sichergestellt, dass der Datenverkehr vor der Wartungsaktivität ordnungsgemäß in den redundanten Pfad verschoben wird.

Stellen Sie sicher, dass alle On-Premise-Geräte im Pfad so eingerichtet sind, dass die AS-Pfadvorgabe oder die Meldung "BGP Graceful Shutdown Community" bestätigt wird. Prüfen Sie außerdem, ob die Redundanz so konfiguriert ist, dass der Datenverkehr in einen alternativen Pfad verschoben wird, falls der primäre Pfad nicht bevorzugt wird. Wenden Sie sich gegebenenfalls an den Serviceprovider, um zu bestätigen, dass er AS-Pfadvoraussetzungen oder BGP-Communitynachrichten in der Verbindung unterstützt, die er mit dem On-Premise-Netzwerk verwaltet.

Wenn das Netzwerk die vorherigen Aktionen nicht unterstützt, treten bei Wartungsaktivitäten wahrscheinlich asymmetrisches Routing und Paketabbrüche auf.

Hinweis

Das Festlegen der lokalen Voreinstellung auf dem CPE-Gerät auf null, nachdem die Community für ordnungsgemäßes Herunterfahren empfangen wurde, kann herstellerspezifisch sein. Stellen Sie mit Geräteherstellern sicher, dass das CPE-Gerät über dieses Feature verfügt. Wenn nicht, konfigurieren Sie eine eingehende Routing-Policy, um die lokale Voreinstellung für das CPE auf null zu setzen, basierend auf dem Empfang der Communitynachricht für ordnungsgemäßes Herunterfahren von OCI.

OCI-Router unterstützen AS-Pfadvoraussetzungen, wenn sie auch auf CPE-Geräten unterstützt werden. Asymmetrisches Routing ist möglich, wenn sich der Traffic auf den internen CPE- und OCI-Routern aufgrund einer Verzögerung beim Verschieben des Traffics nicht gleichzeitig verlagert. Um solche Probleme zu vermeiden, sollten Sie die Unterstützung für asymmetrisches Routing in CPE-Geräten 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 von Virtual Circuit prüfen

Wenn Sie zum ersten Mal redundante Verbindungen bereitstellen, prüfen Sie, ob diese ordnungsgemäß funktionieren, bevor Sie sie in die Produktion nehmen. 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 Änderungen vorgenommen werden können, die das Failover unterbrechen 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, was zu spät sein kann. Denken Sie auch daran, zu validieren, dass es nicht zu den primären Werken zurückkehrt.

Der Failover-Validierungsprozess umfasst zwei Phasen, die jeweils während der OCI-Routerwartung zu sehen sind:

  1. Ziehen Sie den primären Pfad mithilfe der lokalen Voreinstellung und des AS-Pfads voran, und vergewissern Sie sich dann, dass der Verkehr in den sekundären Pfad verschoben wird. Im Leitfaden zur Konnektivitätsredundanz (PDF) wird erläutert, wie Sie einen bestimmten Pfad mithilfe der AS-Pfadvorgaben und lokalen Voreinstellungen priorisieren können. Dies ist der Haupt-Failover-Test, den Sie ausführen, da der Pfadentfernerprozess von OCI während des Wartungsfensters vor dem Herunterfahren der BGP-Session ausgeführt wird.
  2. Fahren Sie die primäre BGP-Session zwischen On-Premise- und OCI-Netzwerken vorübergehend herunter. Um die BGP-Session herunterzufahren, deaktivieren Sie den Virtual Circuit in der OCI-Konsole. Dies zwingt den Verkehr, durch die sekundäre Verbindung zu fließen. Informationen zum von Ihnen verwendeten FastConnect-Modus (Partner, Colocation oder Externer Provider) finden Sie in der Dokumentation im Abschnitt "Verbindung verwalten". Dies ist kein "verschuldetes Herunterfahren" und kann nach der Validierung des Failovers schnell wieder aufgenommen werden.

Sie können den primären Pfad aufrufen, indem Sie die Änderungen zurücksetzen und dann prüfen, ob der Traffic wieder an den primären Pfad weitergeleitet wird. Wir empfehlen, Failover mit beiden Methoden zu testen, die bereits vorgeschlagen wurden, um sicherzustellen, dass der Failover-Mechanismus reibungslos funktioniert.

Bei Konnektivitätsmodellen für Oracle-Partner haben Sie bei mehreren Virtual Circuits die Möglichkeit, Failover mit den oben genannten Methoden zu validieren. Wenn Sie nur über einen Virtual Circuit verfügen, können Sie Failover nicht testen, da die Redundanz nur zwischen dem Oracle FastConnect-Router und dem Provider vorhanden ist.

Wenn das On-Premise-Netzwerk zustandsbehaftete Firewalls verwendet, sind Sie beim Failover anfällig für Probleme. Daher ist es noch wichtiger, sicherzustellen, dass Traffic-Failover wie erwartet stattfindet.

Trafficstatistiken können in der OCI-Konsole überwacht werden. Metriken für empfangene Bits und gesendete Bits werden nur auf dem aktuellen aktiven Pfad erhöht. Sie können Zustand, Kapazität und Performance einer FastConnect-Verbindung mit Metriken, Alarmen und Benachrichtigungen überwachen. Weitere Informationen finden Sie unter Monitoring und Notifications.

Häufig gestellte Fragen

Welche Auswirkungen können redundante Virtual Circuits haben?
Wenn Sie redundante Virtual Circuits verwenden, treten bei der Wartung weniger Unterbrechungen auf. Wenn die BGP-Peers AS-Pfadvoraussetzung und GSHUT (graceful shutdown) unterstützen, ist der Datenverkehrskonvergenzprozess schneller und reibungsloser. Der Datenverkehr wechselt nahtlos zum sekundären Pfad nach der BGP-Rekonvergenz, wodurch Unterbrechungen vermieden werden. In solchen Szenarien erwarten wir keine spürbaren Auswirkungen. Halten Sie sich immer an die zuvor beschriebene Dokumentation.
Was geschieht, wenn ich keine redundanten Virtual Circuits habe?
Wenn Sie sich auf einen einzelnen Virtual Circuit verlassen, kann es während des in der Benachrichtigung beschriebenen Wartungsfensters zu Verkehrsunterbrechungen kommen. Wir empfehlen, die Best Practices für die FastConnect-Redundanz zu befolgen, um redundante Verbindungen zu implementieren. Zur sofortigen Redundanz kann die Konfiguration einer IPSec-Verbindung als redundanter Pfad dazu beitragen, Unterbrechungen zu mindern, wobei die Bandbreitenbeschränkung von Site-to-Site-VPN berücksichtigt wird.
Wie hoch ist die erwartete Auswirkungsdauer für nicht redundante Verbindungen?
Die eigentliche Wartung dauert nicht die gesamte in der Benachrichtigung angegebene Zeit, aber die Auswirkungen können zu jedem Zeitpunkt innerhalb des angegebenen Wartungsfensters auftreten. Vorbereitung und Planung basierend auf den angegebenen Start- und Endzeiten.
Kann ich eine Änderung in der AS-Pfadvorbereitung anfordern, die während der Wartung mehr als 3 Mal vorangestellt wird, oder die GSHUT-Konfiguration ändern?
Nein. Die Prozeduren für die AS-Pfadvorbereitung und GSHUT sind global in OCI standardisiert und können nicht geändert werden, um einzelne Anforderungen zu erfüllen.
Wie kann ich die Redundanz von Virtual Circuits schnell überprüfen?
Sie können die Redundanz über die OCI-Konsole prüfen. Nicht redundante Virtual Circuits lösen Benachrichtigungen in der Konsole aus, die darauf hinweisen, dass keine Redundanz angegeben ist: "Dieser Virtual Circuit FastConnect weist einen Single Point of Failure auf. Stellen Sie eine redundante Verbindung bereit, um potenzielle Ausfälle zu vermeiden." Zur Bestätigung:
  1. Öffnen Sie die Detailseite des Virtual Circuits in der OCI-Konsole.
  2. Sehen Sie sich den Abschnitt "BGP" der Details an. Im Feld "Logisches Gerät" wird der Gerätename angezeigt, der den Virtual Circuit hostet. Zur Redundanz müssen die logischen Geräte für jeden Virtual Circuit unterschiedlich sein.
Beide Virtual Circuits landen auf demselben physischen Gerät. Ist es möglich, Wartungsarbeiten an einem Virtual Circuit gleichzeitig durchzuführen?
Die Wartung erfolgt auf der Ebene des physischen Geräts, nicht auf der Ebene des Virtual Circuits. Die Wartung auf einem Gerät wirkt sich auf alle zugehörigen Virtual Circuits gleichzeitig aus. Wir empfehlen Ihnen, redundante Verbindungen zu implementieren, die auf verschiedenen physischen Geräten landen, um solche Szenarien zu vermeiden. Befolgen Sie die FastConnect Redundancy-Best Practices.
Warum wurde ein Wartungsfenster abgebrochen oder neu geplant?
Die Wartung kann verschoben werden, wenn Probleme identifiziert werden, die zu unvorhergesehenen Störungen führen könnten. Die Priorität besteht darin, die Wartung mit minimalen Auswirkungen auf Sie abzuschließen. Die Neuplanung stellt sicher, dass alle Blocker aufgelöst werden, bevor Sie fortfahren.
Kann ich beantragen, dass die Wartung storniert oder neu geplant wird?
Wir benachrichtigen alle betroffenen Kunden 14 Tage vor der Änderung bezüglich der Wartung, damit Sie genügend Zeit haben, um das On-Premise-Netzwerk unterzubringen und zu verwalten. Diese Benachrichtigung wird an alle Kunden gesendet, deren Virtual Circuits auf demselben Gerät ausgeführt werden. Einzelne Kundenanforderungen können nicht basierend auf ihrer Uhrzeit- oder Datumsvoreinstellung berücksichtigt werden.
Kann ich anfordern, dass die Wartungsbenachrichtigung erneut gesendet wird?
Nein. Oracle sendet E-Mails in einem automatisierten Format basierend auf Compartment-IDs und Virtual Circuit-OCIDs. Die Automatisierung sendet sie an die Benachrichtigungs-E-Mail, die mit diesem Compartment verknüpft ist. Das Kundenbenachrichtigungsteam kann keine einzelnen E-Mails senden. Diese Benachrichtigungen erfolgen nur in einem Batch.
Ich habe mehrere Benachrichtigungen mit unterschiedlichen Terminen erhalten. Wie kann ich bestätigen, wann die Wartung geplant ist?
Wenn Sie aufgrund einer Neuplanung mehrere Benachrichtigungen haben, betrachten Sie die letzte Benachrichtigung als endgültige Informationsquelle. Planen Sie immer basierend auf den aktualisierten Zeitrahmen, die in der letzten Benachrichtigung angegeben sind.
Welche Redundanz muss ich bereitstellen, wenn ich einen Oracle-Partner verwende, um Layer-3-Konnektivität zu OCI bereitzustellen?
Oracle stellt sicher, dass für unsere Partner, die Layer-3-Konnektivität anbieten, bereits physische Redundanz in ihrem Namen bereitgestellt wurde. Sie sind für die Bereitstellung der bevorzugten Redundanz für den Oracle-Partner verantwortlich. Wenn Sie eine Region mit einem einzelnen FastConnect-Speicherort verwenden und außerdem Standortdiversität wünschen, können Sie einen zweiten Virtual Circuit in einer nahe gelegenen Region bereitstellen. Weitere Informationen finden Sie unter BGP-Session zu Oracle-Partner.