Workload-Anforderungen definieren

Treffen Sie Entscheidungen zu Ihren Anforderungen an Kommunikation, Konnektivität und Resilienz von Workloads.

Kommunikationsanforderungen

Ermitteln Sie, welche Workload-Kommunikationsanforderungen für Kommunikationsgateways und Internetkonnektivität, zwischenbetriebliche VCN-Konnektivität und den Zugriff auf Oracle Services Network gelten.

OCI-Kommunikationsgateways

Sie müssen die entsprechenden Kommunikationsgateways für Ihre Anforderungen entscheiden.

In der folgenden Tabelle sind die Features und die empfohlenen Gateways aufgeführt, die für jedes Feature verwendet werden sollen.



Funktion Empfohlenes Gateway Kommentare
Traffic in und aus OCI kann über OCI oder das Internet initiiert werden Internetgateway Ein öffentliches Subnetz und eine Ressource mit öffentlicher IP-Adresse benötigen
Ressourcen in OCI greifen sicher auf das Internet zu NAT-Gateway Nur Traffic, der innerhalb des Subnetzes initiiert wird, wird über das NAT-Gateway zugelassen
Zugriff auf Oracle Cloud Infrastructure Object Storage oder andere Services in Oracle Service Network Servicegateway Beispiele für Services sind BS-Managementservice, Oracle Linux oder Yum Service. Eine vollständige Liste der unterstützten Services im Oracle Services Network finden Sie im Abschnitt Durchsuchen
Verbindung zwischen OCI und On Premise sowie zwischen VCNs Dynamic Routing Gateway (DRG) Ein virtueller Router verbindet VCNs und On-Premise-Standorte über einen zentralen Verbindungspunkt und stellt Verbindungen zwischen Regionen und verschiedenen Mandanten her

Interne VCN-Konnektivität

Entscheiden Sie, wie Sie zwischen VCNs in OCI kommunizieren. Sie können zwei VCNs entweder innerhalb desselben Mandanten oder in unterschiedlichen Mandanten verbinden.

Sie sehen drei Beispiele für die Verbindung zwischen VCN mit einem lokalen Peering-Gateway oder einem dynamischen Routinggateway.

Lokales Peering-Gateway (LPG)

Die folgende Abbildung zeigt eine Region mit zwei VCNs, die die lokale Peering-Gateway-Methode verwenden:



Beide VCNs müssen sich in derselben Region befinden, und Sie können maximal zehn LPGs pro VCN verwenden.

Dynamic Routing Gateway (DRG)

Oracle empfiehlt die Verwendung von dynamischen Routinggateways. Sie können VCNs innerhalb derselben Region oder zwischen Regionen verbinden. Ein DRG kann bis zu 300 VCNs verbinden.

Die folgende Abbildung zeigt eine Region mit zwei VCNs, die über ein DRG in derselben Region verbunden sind:



Die folgende Abbildung zeigt eine Region mit zwei VCNs, die das DRG verwenden, wobei zwei VCNs zwischen separaten Regionen verbunden sind:



Auf Oracle Services Network zugreifen

Oracle Services Network (OSN) ist ein Konzeptnetzwerk in Oracle Cloud Infrastructure, das für Oracle-Services reserviert ist.

Die folgende Architektur zeigt den Zugriff auf Oracle Services Network:



Diese Services verfügen über öffentliche IP-Adressen, die über das Internet erreicht werden können. Sie können jedoch auf das Oracle Services Network zugreifen, ohne dass der Traffic über das Internet geleitet wird. Dazu verwenden Sie ein Servicegateway aus einem VCN.

Wenn Sie eine Route zu OSN hinzufügen, müssen Sie entscheiden, ob das Netzwerk alle Services verwenden oder einfach auf Oracle Cloud Infrastructure Object Storage zugreifen soll.

Object Storage wird normalerweise für Backupzwecke wie für Oracle Database-Backups verwendet.

Hybrid- und Multi-Cloud-Anforderungen

Entscheiden Sie, ob Sie eine Hybrid-Cloud- oder Multi-Cloud-Architektur benötigen. Bewerten Sie die Bandbreitenanforderungen für die Verbindung für eine gute Benutzererfahrung.

Sie können Oracle Cloud über FastConnect oder Site-to-Site-VPN mit On-Premise-Netzwerken verbinden.

Das folgende Diagramm zeigt eine Beispielarchitektur für das Verbinden einer On-Premise-Umgebung mit OCI mit einem Site-to-Site-VPN oder FastConnect:



Das folgende Diagramm zeigt eine Beispielarchitektur einer Datenbank in OCI und des Anwendungs-Load Balancers in Microsoft Azure:



Latenz ist wichtig für eine gute Benutzererfahrung und bessere Reaktionszeiten. Oracle und Micorsoft Azure verfügen über Integrationspunkte an verschiedenen Standorten auf der ganzen Welt. Dadurch kann die Latenz einfach integriert werden und reduziert werden. Dadurch ist eine Cloud-übergreifende Lösung mit FastConnect und ExpressRoute möglich.

Sie können FastConnect als primäre Verbindung und ein Site-to-Site-VPN als Backupverbindung verwenden. Je nach Bedarf können Sie auch eine Verbindung zu anderen Clouds mit Site-to-Site-VPN und FastConnect herstellen.

Verbindung zu On-Premise-Netzwerken herstellen

Sie können mit einer der folgenden Methoden eine Verbindung zu On-Premise-Netzwerken herstellen:

  • Bei FastConnect wird eine dedizierte Verbindung für feste Bandbreite und Latenz verwendet. Oracle empfiehlt die Verwendung redundanter Verbindungen für Resilienz.
  • Site-to-Site-VPN verwendet das Internet als Netzbetreiber und kann auch FastConnect verwenden. Bandbreite und Latenz können variieren und Oracle empfiehlt daher die Verwendung redundanter Tunnel.

Verbindung zu On-Premise-Netzwerken über FastConnect herstellen

Die folgende Abbildung zeigt eine Architektur mit einer On-Premise- und OCI-Region über FastConnect, in der der der Traffic nicht über das öffentliche Internet geleitet wird:



Verwenden Sie ein Site-to-Site-VPN als Backupverbindung für FastConnect. Die primäre Verbindung ist also FastConnect, und das Backup ist VPN. Die verfügbaren Verbindungsgeschwindigkeiten sind 1 Gbit/s, 10 Gbit/s oder 100 Gbit/s.

  • Richten Sie einen Virtual Circuit mit Public Peering ein, wenn Sie nur Zugriff auf Oracle Services Network benötigen.
  • Verwenden Sie ein Site-to-Site-VPN, das IPSec zur Trafficverschlüsselung zusätzlich zu dem Public Peering mit FastConnect verwendet.
  • Verwenden Sie Private Peering, wenn Sie eine private Verbindung zu Ressourcen in OCI (VCNs) benötigen.

Hinweis:

Oracle empfiehlt die Verwendung der doppelten Geräte für Redundanz.

Verbindung zu On-Premise-Netzwerken über Site-to-Site-VPN herstellen

Über ein Site-to-Site-VPN werden On-Premise-DC mit OCI verbunden. Site-to-Site-VPN verwendet das Internet als Netzbetreiber und verschlüsselt den Datenverkehr mithilfe des IPSec-Protokolls.

Die folgende Abbildung zeigt eine Architektur mit redundanten Customer Premises-Geräten und eine OCI-Verbindung über Site-to-Site-VPN:



Über ein Site-to-Site-VPN werden On-Premise-Data Center mit OCI verbunden. Die Leistung kann je nach Internettraffic variieren. Wie bei FastConnect sollten Sie auch Site-to-Site-VPN mit redundanten Tunneln und wenn möglich auch mit redundanten CPE-Geräten konfigurieren. Oracle stellt zwei VPN-Endpunkte für jede Site-to-Site-VPN-Verbindung bereit.

Je nach Ihren geschäftlichen Anforderungen können Sie diese als Alternative zu FastConnect verwenden, wenn Sie eine konstante Bandbreite haben. Site-to-Site-VPN ist in Oracle Cloud-Tools integriert, sodass das Setup kinderleicht ist und die Verfügbarkeit ohne zusätzliche Kosten gewährleistet ist. Site-to-Site-VPN kann jedoch nicht auf dieselbe Bandbreite wie FastConnect (derzeit 250 Mbps/tunnel) skaliert werden. Sie können sie als Standby für FastConnect verwenden.

Verwenden Sie Site-to-Site-VPN als kostenlose Alternative, wenn Sie die leistungsstarken Verbindungen von Megaport und Equinix, die in den nächsten Abschnitten erläutert werden, nicht benötigen.

Verbindung zu Amazon Web Services herstellen

Verbindungen zu anderen Public Clouds von Oracle Cloud Infrastructure können schnell und einfach über unsere FastConnect-Partner hergestellt werden.

Das folgende Diagramm zeigt eine Verbindung zwischen OCI und AWS mit unserem Verbindungspartner Megaport:

Mit Microsoft Azure verbinden

Microsoft und Oracle haben in mehreren Regionen eine Partnerschaft mit der Preintegration von Azure mit OCI.

Das folgende Diagramm zeigt die Preintegration von Azure mit OCI mit ExpressRoute und FastConnect:



Sie können den Zugriff zwischen den Clouds aktivieren, indem Sie ihn über beide Sites oder über die Konsole mit FastConnect und ExpressRoute aktivieren, ohne dass dazwischen ein Netzwerkservicebetreiber vorhanden ist. Sie müssen nur einen 1x Virtual Circuit einrichten, da er integrierte Redundanz mit einem anderen Standard als FastConnect verwendet. Wenn Sie eine lokale SKU verwenden und die Verbindungsgeschwindigkeit von mindestens 1 Gbit/s auswählen, fallen keine Kosten für den Datenverkehr zwischen Azure an. Die Interconnects werden dort erstellt, wo sich Azure und OCI in der Nähe voneinander befinden, um eine geringe Latenz zwischen den Clouds zu ermöglichen.

Hinweis:

Nicht alle Regionen verfügen über diese Funktion. Verwenden Sie einen Netzwerkserviceprovider in anderen Regionen.

Wenn Sie nach einer Verbindung zu Microsoft Azure suchen, lesen Sie Zugriff auf Microsoft Azure.

Mit Google Cloud verbinden

Das folgende Architekturdiagramm zeigt eine Verbindung zwischen Oracle Cloud Infrastructure (OCI) und Google Cloud Platform (GCP) mit dem Oracle-Konnektivitätspartner Equinix:

Resilienzanforderungen

Entscheiden Sie, ob Sie Resilienz gegenüber regionalen Ausfällen haben und ein Deployment mit mehreren Regionen in Betracht ziehen möchten.

Multiregion-Deployment

Verwenden Sie ein regionsübergreifendes Standardsetup für ein Deployment mit mehreren Regionen, bei dem Sie eine Region für das regionsübergreifende Kopieren mit einer anderen Region verbinden. Richten Sie dieselben Ressourcen in der Standbyregion ein, und richten Sie Remote-Peering zwischen DRGs ein.

Die Daten zwischen den Regionen verwenden den Netzwerk-Backbone von Oracle anstelle des Internets. Sie müssen die Replikation von Daten und erforderlichen Inhalten einrichten, die zur Ausführung des Deployments in der Standby-Region erforderlich sind.


Beschreibung von multi-region-deployment-full-arch.png folgt
Beschreibung der Abbildung multi-region-deployment-full-arch.png

Load Balancing

Verteilen Sie den Datenverkehr über einen Load Balancer an mehrere Backend-Server.

Ein öffentlicher Load Balancer verwendet eine öffentliche IP und ist über das Internet zugänglich. Ein privater Load Balancer verwendet eine private IP-Adresse und kann nur vom VCN aus aufgerufen werden.

Load Balancer

Ein Standard-Load Balancer für öffentliche Webserver kann SSL-Traffic beenden oder an das Backend übergeben. Sie können Web Application Firewall-(WAF-)Schutz direkt auf einen Load Balancer anwenden und je nach Traffic flexible Ausprägungen zwischen der minimalen und maximalen Bandbreite verwenden.

Sie können einen öffentlichen oder privaten Load Balancer in Layer 4/7, TCP/HTTP-Schicht einrichten.

Network Load Balancer

Bietet ein nicht-proxybasiertes Passthrough-Load Balancing mit hohem Durchsatz und extrem geringer Latenz. Network Load Balancer sind gratis. Sie sind für Verbindungen mit langer Ausführungszeit über Tage oder Monate optimiert. Dabei sind Verbindungen zum selben Backend-Server vorhanden, die für die Datenbank optimal sind. Er kann basierend auf Clienttraffic automatisch vertikal und horizontal skaliert werden und erfordert keine Bandbreitenkonfigurationen oder SSL-Beendigung.

Die Network Load Balancer stellen die Verfügbarkeit der Services sicher, indem Traffic nur an fehlerfreie Server basierend auf Layer 3/Layer 4-Daten (IP-Protokoll) weitergeleitet wird.