FastConnect-Redundanz - Best Practices

In diesem Thema werden Best Practices zu Redundanzzwecken bei der Implementierung von FastConnect beschrieben.

Allgemeine Informationen zu FastConnect finden Sie unter Überblick über FastConnect.

Überblick

Im Allgemeinen sollten Sie Ihr Netzwerk so konstruieren, dass High Availability (HA) erzielt wird. Außerdem müssen Sie auf die folgenden Arten von Unterbrechungen vorbereitet sein:

  • Regelmäßig geplante Wartung durch Ihre Organisation, Ihren Provider (falls Sie einen verwenden) oder Oracle.
  • Unerwartete Fehler bei den Komponenten Ihres Netzwerks, Ihrem Provider oder Oracle. Fehler treten nur selten auf, aber Sie sollten darauf vorbereitet sein.

Oracle stellt zu Redundanzzwecken Folgendes bereit:

  • Mehrere Provider für jede Region (siehe Liste der FastConnect Partner)
  • Mindestens zwei FastConnect-Speicherorte für Regionen mit mehreren Einträgen in der Liste der FastConnect-Speicherorte unten in der Liste der FastConnect-Partner (viele Regionen haben einen einzelnen FastConnect-Speicherort)

  • Zwei Router an jedem FastConnect-Standort
  • Mehrere physische Verbindungen zwischen den einzelnen Oracle-Partnern und Oracle (für eine bestimmte Region)

Die Best Practices zu Redundanzzwecken sind vom Verbindungsmodell abhängig, das Sie verwenden.

Wenn Sie einen Oracle-Partner verwenden

Konnektivitätsmodell:

Oracle sorgt für Redundanz der physischen Verbindungen zwischen dem Partner und Oracle und von Routern in den FastConnect-Standorten. Sie müssen für die Redundanz der physischen Verbindung zwischen dem vorhandenen Netzwerk und dem Oracle-Partner sorgen.

Die verbleibenden Best Practices sind vom verwendeten Partner und den Details der BGP-Session von Ihrer Edge abhängig:

  • Bei einigen Partnern wird die BGP-Session von Ihrer Edge zu Oracle aufgebaut. Informationen zu Best Practices zu Redundanzzwecken finden Sie im nächsten Abschnitt.
  • Bei anderen Partnern wird die BGP-Session von Ihrer Edge zum Oracle-Partner aufgebaut. Best Practices zur Redundanz finden Sie unter Oracle-Providerszenario: BGP-Session zum Oracle-Partner.

Informationen zu den beiden Szenarios finden Sie unter Einfache Netzwerkdiagramme.

Oracle-Partnerszenario: BGP-Session zu Oracle

Jeder Oracle-Partner verfügt über mindestens zwei separate physische Verbindungen zu Oracle. Richten Sie einen Virtual Circuit auf einer physikalischen Verbindung (als primär) und den anderen Virtual Circuit auf einer anderen physischen Verbindung (als sekundär) ein. Im folgenden Diagramm werden zwei Virtual Circuits dargestellt, von denen jeder eine Verbindung zu einem anderen Router an einem einzelnen FastConnect-Standort aufbaut. Wenn die Region einen zweiten Standort hat, kann die zweite physische Verbindung Ihres Partners stattdessen zu diesem Standort aufgebaut werden.

Diese Abbildung zeigt ein Setup mit einem Oracle-Provider und mehreren Virtual Circuits zu verschiedenen Routern an einem einzigen FastConnect-Standort.

Wenn Sie in einer Region arbeiten, die nur einen einzelnen FastConnect-Standort hat, können Sie auch eine Standortdiversität festlegen. Um dies zu erreichen, wiederholen Sie das vorhergehende Setup für zwei Virtual Circuits mit demselben Oracle-Partner, jedoch an einem zweiten FastConnect-Standort in einer naheliegenden Region. Beachten Sie, dass Sie über ein dupliziertes Setup Ihrer Oracle Cloud-Ressourcen in dieser zweiten Region verfügen müssen, wie im folgenden Diagramm dargestellt.

Diese Abbildung zeigt ein Setup mit einem Oracle-Provider und Verbindungen zu zwei verschiedenen Oracle-Regionen.

Wenn Sie außerdem Diversität bei den Providern wünschen, wiederholen Sie das gesamte Setup mit einem anderen Provider in jeder verwendeten Region.

Oracle-Partnerszenario: BGP-Session zum Oracle-Partner

In diesem Szenario wird die BGP-Session von Ihrer Edge zum Oracle-Partner aufgebaut (wie im folgenden Diagramm dargestellt). Abgesehen von Ihrer BGP-Session verfügt der Oracle-Partner über eigene BGP-Sessions mit Oracle (zwischen der Partner-Edge und der Oracle-Edge). Der Virtual Circuit ist eine logische Verbindung, die zwischen Ihrer Edge und der Oracle-Edge aufgebaut wurde.

Der Partner verfügt über zwei separate physische Verbindungen zu Oracle. Sie erstellen einen Virtual Circuit mit dem Partner. In diesem Szenario wird der Virtual Circuit so konzipiert, dass er redundant und vielfältig ist. Der Virtual Circuit verfügt über zwei separate BGP-Sessions zwischen dem Partner und Oracle, jede über eine andere physische Verbindung. Das folgende Diagramm zeigt die zwei separaten BGP-Sessions für den einzelnen Virtual Circuit als gepunktete Linien.

In dieser Abbildung wird ein Setup mit einem Oracle-Provider und mehreren BGP-Sessions zwischen dem Provider und Oracle für den einzelnen Virtual Circuit dargestellt.

Abgesehen davon müssen Sie sicherstellen, dass die Verbindung zwischen Ihrer Edge und dem Partner redundant und vielfältig ist.

Wenn Sie in einer Region arbeiten, die nur einen einzelnen FastConnect-Standort hat, können Sie auch eine Standortdiversität festlegen. Um dies zu erreichen, wiederholen Sie das vorhergehende Setup für einen Virtual Circuit mit demselben Oracle-Partner, jedoch an einem zweiten FastConnect-Standort in einer naheliegenden Region. Beachten Sie, dass Sie außerdem über ein dupliziertes Setup Ihrer Oracle Cloud-Ressourcen in dieser zweiten Region verfügen müssen, wie im folgenden Diagramm dargestellt.

Diese Abbildung zeigt ein Setup mit einem Oracle-Provider und Verbindungen zu zwei verschiedenen Oracle-Regionen.

Wenn Sie einen externen Provider oder Colocation mit Oracle verwenden

Konnektivitätsmodelle:

Oracle sorgt für Redundanz der Oracle-Router an den FastConnect-Standorten. Sie müssen für die Redundanz der physischen Verbindung zwischen dem vorhandenen Netzwerk und Oracle sorgen.

Erstellen Sie dazu zwei physische Verbindungen zu Oracle, eine für jeden FastConnect-Standort, der für die Region bestimmt ist. Sie richten also in der Oracle-Konsole zwei separate FastConnect-Verbindungen ein. Erstellen Sie dann zwei Virtual Circuits. Richten Sie den ersten Virtual Circuit auf der ersten physischen Verbindung (die erste FastConnect-Verbindung) und den zweiten auf der zweiten physischen Verbindung ein. Das folgende Diagramm zeigt das allgemeine Setup.

Diese Abbildung zeigt ein Colocation-Setup, das aus zwei physischen Verbindungen und Virtual Circuits zum FastConnect-Speicherort besteht.

Möglicherweise bevorzugen Sie die Verbindung zu lediglich einem einzelnen FastConnect-Standort, sei es aus Kostengründen oder weil es in der Region nur einen FastConnect-Standort gibt. Erstellen Sie in diesem Fall zwei physische Verbindungen, und stellen Sie sicher, dass sie jeweils zu einem anderen Oracle-Router an diesem FastConnect-Standort aufgebaut werden. Dies ist in der Oracle-Konsole möglich, wenn Sie die zweite physische Verbindung einrichten. Sie können die Näherung dieser Verbindung zu anderen FastConnect-Verbindungen an diesem Standort angeben. Beispiel: Die folgende Abbildung zeigt, wie angefordert wird, dass die zweite physische Verbindung (eine Crossconnect-Gruppe ) auf einem anderen Router als die erste Verbindung an diesem FastConnect-Standort (als MyConnection-1 bezeichnet) aufgebaut wird.

Diese Abbildung zeigt die Näherungsinformationen für den Router in der Konsole.

Sie müssen die Bandbreite der beiden physischen Verbindungen gleichmäßig skalieren und für jede Verbindung eine Crossconnect-Gruppe (LAG) verwenden. Angenommen, Sie verfügen über zwei individuelle 10-Gbit/s-Crossconnects an einem einzigen FastConnect-Standort (aus Redundanz- und Diversitätszwecken jeweils zu einem anderen Oracle-Router). Wenn Sie zu einem bestimmten Zeitpunkt eine Bandbreite von 20 Gbit/s benötigen, müssen Sie sicherstellen, dass jede der physischen Verbindungen aus einer Crossconnect-Gruppe (LAG) besteht, die das Crossconnect enthält. Anschließend müssen Sie einen weiteren 10-Gbit/s-Crossconnect zu jeder LAG hinzufügen, damit jede redundante physische Verbindung über zwei 10-Gbit/s-Crossconnects verfügt.

Wenn Sie in einer Region arbeiten, die nur einen einzelnen FastConnect-Standort hat, können Sie auch eine Standortdiversität festlegen. Um dies zu erreichen, wiederholen Sie das Setup an einem zweiten FastConnect-Standort in eine naheliegenden Region. Beachten Sie, dass Sie außerdem über ein dupliziertes Setup Ihrer Oracle Cloud-Ressourcen in dieser zweiten Region verfügen müssen, wie im folgenden Diagramm dargestellt.

Diese Abbildung zeigt ein Colocation-Setup für zwei verschiedene Regionen.

Site-to-Site-VPN als Backup für FastConnect

Oracle empfiehlt, dass Sie Site-to-Site-VPN als Backup für die FastConnect-Verbindung verwenden. Stellen Sie in diesem Fall sicher, dass die IPsec-Tunnel für Site-to-Site-VPN für die Verwendung von BGP-Routing mit einem routenbasierten VPN konfiguriert sind. Bearbeiten Sie in Ihrem vorhandenen On-Premise-Netzwerk das Routing so, dass vorzugsweise durch FastConnect erlernte Routen anstatt durch Site-to-Site-VPN erlernte Routen verwendet werden. Beispiel: Verwenden Sie AS_Path Prepend, um Egress-Traffic von Oracle zu beeinflussen, und verwenden Sie eine lokale Voreinstellung, um Egress-Traffic aus Ihrem Netzwerk zu beeinflussen.

Wenn Sie ein VPN-Backup verwenden, prüfen Sie das BGP-Routingverhalten von Oracle in der Tabelle unter Routen von Oracle zu Ihrem On-Premise-Netzwerk mit AS_PATH bevorzugen.

Das folgende Diagramm zeigt ein Setup mit redundanten FastConnect-Virtual Circuits und redundanten Site-to-Site-VPN-Tunneln.

Diese Abbildung zeigt FastConnect mit Site-to-Site-VPN als Backup.