FastConnect-Redundanz - Best Practices

Entwerfen Sie das On-Premise-Netzwerk, um High Availability (HA) zu erreichen, um sich auf diese Arten von Störungen vorzubereiten:

• Regelmäßige geplante Wartung im On-Premise-Netzwerk, im Netzwerk eines Providers (wenn Sie eines verwenden) oder bei Oracle.
• Unerwartete Fehler bei On-Premise-Netzwerkkomponenten, dem Provider oder Oracle. Fehler treten nur selten, aber Sie müssen sie trotzdem planen.

Verbindungen zu OCI bieten Redundanz auf folgende Weise:

• Jede OCI-Region verfügt über mehrere Provider und Oracle Partners (siehe Liste der FastConnect-Partner), die Providerredundanz ermöglichen
• Regionen mit mehreren Einträgen in der Liste der FastConnect-Speicherorte (siehe unten in der Liste der FastConnect-Partner gibt es zwei oder mehr FastConnect-Speicherorte (auch als Point of Presence oder PoP bezeichnet). Viele Regionen verfügen über einen einzelnen FastConnect-Speicherort. Daher ist die Regionsredundanz manchmal, aber nicht immer verfügbar.
• Jeder FastConnect-Speicherort verfügt immer über mindestens zwei Router, um die Geräteredundanz zu aktivieren.
• Jede Oracle-Region verfügt über mehrere physische Verbindungen zu jedem Oracle-Partner.

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

Konnektivitätsmodell:

• FastConnect: Mit einem Oracle-Partner

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 den Redundanz der physischen Verbindung zwischen dem On-Premise-Netzwerk und dem Oracle-Partner Sorge tragen.

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

• Bei einigen Partnern wird die BGP-Session von der On-Premise-Edge zu Oracle aufgebaut. Wenn Sie den Partner auswählen, kann diese Verbindung manchmal als L2 gekennzeichnet werden. Informationen zu Best Practices zu Redundanzzwecken finden Sie im nächsten Abschnitt.
• Bei anderen Partnern wird die BGP-Session von der On-Premise-Edge zum Oracle-Partner aufgebaut. Wenn Sie den Partner auswählen, kann diese Verbindung manchmal als L3 gekennzeichnet werden. Best Practices für Redundanz finden Sie unter BGP-Session zu Oracle Partner (Layer 3).

Informationen zu den beiden Szenarios finden Sie unter Einfache Netzwerkdiagramme.

BGP-Session zu Oracle (Schicht 2)

Jeder Oracle-Partner verfügt über mindestens zwei separate physische Verbindungen zu Oracle. Wenn Sie einen Virtual Circuit FastConnect in der Konsole erstellen, verwenden Sie die Option Redundante Virtual Circuits. 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. Das folgende Diagramm veranschaulicht diese beiden Virtual Circuits, die jeweils zu einem anderen Router an einem einzelnen FastConnect-Speicherort gehen. Wenn die Region einen zweiten Standort hat, kann die zweite physische Verbindung des Partners stattdessen zu diesem Standort hergestellt werden.

Wenn Sie in einer Region arbeiten, die nur einen einzelnen FastConnect-Standort hat, können Sie auch die Standortdiversität festlegen. Um dies zu erreichen, wiederholen sie das vorhergehende Setup für zwei Virtual Circuits mit demselben Oracle-Partner, jedoch in einem zweiten FastConnect-Standort in einer naheliegenden Region. Beachten Sie, dass in dieser zweiten Region ein doppeltes Setup von Oracle-Cloud-Ressourcen vorhanden sein muss, wie im folgenden Diagramm dargestellt.

BGP-Session zu Oracle Partner (Schicht 3)

In diesem Szenario wird die BGP-Session von der On-Premise-Edge zum Oracle-Partner wiederhergestellt (wie im folgenden Diagramm dargestellt). Abgesehen von dieser BGP-Session hat der Oracle-Partner seine eigenen BGP-Sessions mit Oracle (zwischen der Partner-Edge und der Edge von Oracle). Der Virtual Circuit ist eine logische Verbindung, die zwischen Ihrer On-Premise-Edge und der Oracle-Edge aufgebaut wird.

Ein Oracle-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.

Standardmäßig ist ein einzelner Virtual Circuit vom Typ L3 zwischen OCI und dem FC-Partner redundant. Dies garantiert keine Redundanz zwischen dem Oracle-Partner und einem On-Premise-Netzwerk. In the case of using an L3 Oracle Partner virtual circuit, work with the Oracle Partner to understand if you require several virtual circuits to ensure full end-to-end redundancy all the way between OCI and the on-premises network (not only the single L3 virtual circuit guarantee of redundancy between the Oracle Partner and OCI).

Darüber hinaus können Sie redundante Virtual Circuits zu einem Virtual Circuit von L3 Oracle-Partnern erstellen, wenn Sie Folgendes benötigen: Standortvielfalt oder Partnervielfalt.

Sie sind dafür verantwortlich, dass die Verbindung zwischen der On-Premise-Edge und dem Oracle-Partner redundant und vielfältig ist.

Wenn Sie in einer Region arbeiten, die nur einen einzelnen FastConnect-Standort hat, können Sie auch die Standortdiversität festlegen. Dies zu erreichen, ist das vorhergehende Setup für einen Virtual Circuit mit demselben Oracle-Partner, jedoch an einem zweiten FastConnect-Standort in einer naheliegenden Region zu wiederholen. Beachten Sie, dass Sie auch ein doppeltes Setup von Oracle-Cloud-Ressourcen in dieser zweiten Region haben müssen, wie im folgenden Diagramm dargestellt.

Partnervielfalt

Wenn Sie auch die Diversität der Partner wünschen, verwenden Sie die Option Redundante Virtual Circuits, und wählen Sie einen anderen Partner aus, wenn Sie Virtual Circuit 1 und Virtual Circuit 2 erstellen. Dieses Beispiel zeigt Partner A und Partner B, die unterschiedliche FastConnect-Speicherorte verwenden, um eine Verbindung zu demselben VCN herzustellen. Es ist kein doppeltes Setup von Oracle Cloud-Ressourcen erforderlich.

Dieses nächste Beispiel zeigt Partner A und Partner B, die denselben FastConnect-Speicherort für die Verbindung mit demselben VCN verwenden.

Konnektivitätsmodelle:

• FastConnect: Mit einem externen Provider
• FastConnect: Colocation mit Oracle

Oracle sorgt für Redundanz der Oracle-Router in den FastConnect-Speicherorten. Sie sind für die Redundanz der physischen Verbindung zwischen einem On-Premise-Netzwerk und Oracle verantwortlich.

Um Redundanz zu erreichen, erstellen Sie zwei physische Verbindungen zu Oracle, eine für jeden FastConnect-Speicherort, der für die Region bestimmt ist, oder für verschiedene physische Geräte am selben FastConnect-Speicherort. Sie richten also in der Oracle-Konsole zwei separate FastConnect-Verbindungen ein. Erstellen Sie dann zwei Virtual Circuits. Richten Sie den ersten 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.

Möglicherweise entscheiden Sie sich aus Kostengründen für die Verbindung zu einem einzelnen FastConnect-Speicherort, oder die Region verfügt möglicherweise nur über einen einzelnen FastConnect-Speicherort. In diesem Fall können Sie immer zwei physische Verbindungen erstellen und sicherstellen, dass sie jeweils zu einem anderen Oracle-Router an diesem FastConnect-Speicherort aufgebaut werden.

Wenn Sie die Optionen FastConnect Direct und Single FastConnect in der Konsole verwenden, um die Redundanz vorhandener Verbindungen zu erhöhen, müssen Sie die Einstellung Routernähe angeben manuell konfigurieren, um Geräteredundanz zu erreichen. Die folgende Abbildung zeigt eine Anforderung für eine zweite physische Verbindung (eine Crossconnect-Gruppe ), die auf einem anderen Router als die erste Verbindung in diesem FastConnect-Speicherort (als MyConnection-1 bezeichnet) erstellt wurde.

Wählen Sie zum ersten Erstellen redundanter Crossconnects oder Crossconnect-Gruppen die Option FastConnect Direct und Device redundancy aus, und konfigurieren Sie zwei redundante Crossconnect- oder Crossconnect-Gruppen, bei denen die zweite vorkonfiguriert ist, damit sie auf einem anderen physischen Gerät (Router) als die erste eingerichtet wird.

Wenn Sie in einer Region arbeiten, die nur einen einzigen FastConnect-Standort hat, können Sie auch Standortdiversität erreichen, indem Sie das Setup an einem zweiten FastConnect-Standort in einer nahe gelegenen Region wiederholen. Beachten Sie, dass Sie auch ein doppeltes Setup von Oracle-Cloud-Ressourcen in dieser zweiten Region haben müssen, wie im folgenden Diagramm dargestellt.

Wenn Sie in einer Region mit zwei oder mehr FastConnect-Speicherorten arbeiten, können Sie die Optionen FastConnect Direct und Standortredundanz verwenden, um zwei redundante Crossconnects oder Crossconnect-Gruppen zu erstellen, eine pro FastConnect-Speicherort. Sie können dies auch manuell tun, indem Sie ein einzelnes FastConnects erstellen und jeweils verschiedene physische Speicherorte auswählen. Sie benötigen kein doppeltes Setup von Oracle-Cloud-Ressourcen in dieser zweiten Region, wie im folgenden Diagramm dargestellt.

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

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

Wenn Du ein VPN-Backup verwendest, prüfe das BGP-Routingverhalten von "Oracle" in der Tabelle unter Routen von Oracle zu deinem On-Premise-Netzwerk mit AS_PATH bevorzugen.

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

• Routingdetails für Verbindungen zum On-Premise-Netzwerk
• Connectivity Redundancy Guide (PDF)

Wählen Sie das entsprechende Thema für die Situation aus:

• FastConnect: Mit einem Oracle-Partner
• FastConnect: Mit einem externen Provider
• FastConnect: Colocation mit Oracle