Workload-Anforderungen definieren

Bestimmen Sie Ihre Anforderungen an Kommunikation, Konnektivität und Resilienz von Workloads.

Kommunikationsanforderungen

Identifizieren Sie Ihre Workload-Anforderungen für Kommunikationsgateways und Internetkonnektivität, Inter-VCN-Konnektivität und den Zugriff auf das Oracle Services Network (OSN).

OCI-Kommunikationsgateways

Das folgende Diagramm veranschaulicht ein primäres OCI-Deployment in der Region "US West" (Phoenix). Es zeigt, wie Produktions- und Vorproduktions-Workloads für eine sichere, robuste Konnektivität zwischen der Cloud, On-Premises-Data Centern und Oracle-Services vernetzt sind:

Beschreibung der Abbildung oci-communication-gateways.png

Wählen Sie die entsprechenden Kommunikationsgateways basierend auf den Anforderungen Ihrer Workload aus der folgenden Tabelle:

Feature	Empfohlenes Gateway	Kommentare
Traffic in und aus OCI kann über OCI oder das Internet initiiert werden	Internetgateway	Öffentliches Subnetz und eine Ressource mit öffentlicher IP erforderlich
Ressourcen in OCI greifen sicher auf das Internet zu	NAT-Gateway	Nur Traffic, der innerhalb des Subnetzes initiiert wird, ist über das NAT-Gateway zulässig
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 in OSN finden Sie im Abschnitt Entdecken.
Verbindung zwischen OCI und On-Premise und zwischen VCNs	DRG	Ein virtueller Router verbindet VCNs und On-Premise-Standorte über einen zentralen Verbindungspunkt und stellt auch Verbindungen zwischen Regionen und verschiedenen Mandanten her

Inter-VCN-Konnektivität

Entscheiden Sie, wie VCNs innerhalb von OCI kommunizieren sollen (innerhalb eines Mandanten oder mandantenübergreifend):

Oracle empfiehlt die Verwendung von DRGs für die Inter-VCN-Konnektivität. Das DRG bietet einen skalierbaren Pfad für die Konnektivität nicht nur zwischen VCNs, sondern auch von On-Premise- und anderen Clouds. Der dynamische Routenimport reduziert die Komplexität der Verwaltung. Für bestimmte Routinganforderungen zwischen zwei VCNs verwenden Sie ein lokales Peering-Gateway (LPG). Sie können sowohl DRGs als auch LPGs zusammen verwenden, je nach Ihren Anforderungen.

Die folgenden drei Beispiele für Inter-VCN-Konnektivität verwenden ein LPG oder DRG:

Lokales Peering-Gateway (LPG)

Die folgende Abbildung zeigt eine Region mit zwei VCNs, die LPGs für lokales Peering verwenden:

Beschreibung der Abbildung vcn-local-peering-gateway.png

Beide VCNs müssen sich in derselben OCI-Region befinden. Pro VCN können bis zu 10 LPGs vorhanden sein.

Dynamisches Routinggateway (DRG)

DRGs verbinden VCNs innerhalb oder über Regionen hinweg und ermöglichen bis zu 300 Anhänge pro DRG. DRGs bieten neben statischen Routen einfache Routingoptionen. Routen aus den angehängten Netzwerken werden dynamisch mit Importroutenverteilungen in DRG-Routentabellen importiert.

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

Beschreibung der Abbildung vcn-dynamic-routing-gateway-same-region.png

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

Beschreibung der Abbildung vcn-dynamic-routing-gateway-separat-regions.png

Auf Oracle Services Network (OSN) zugreifen

OSN ist ein konzeptionelles Netzwerk in OCI, das für Oracle-Services reserviert ist.

Die folgende Architektur zeigt ein VCN, das auf die OSN zugreift, ohne dass der Traffic über das Internet über ein Servicegateway geleitet wird:

Beschreibung der Abbildung oracle-services-network.png

Berücksichtigen Sie die folgenden Optionen und entscheiden Sie, wie Sie Ihren Traffic weiterleiten möchten:

• Mit einem Servicegateway können Sie privaten Traffic an OSN weiterleiten, ohne das Internet zu durchlaufen.
• Services (wie Object Storage) verfügen über öffentliche IPs, die über das Internet erreicht werden können. Verwenden Sie private Endpunkte (PEs), um den Traffic innerhalb des OCI-Netzwerks zu halten.
• Wenn Sie eine Route zu OSN hinzufügen, entscheiden Sie, ob das Netzwerk alle OCI-Services verwenden soll, oder verwenden Sie einfach OCI Object Storage für Datenbankbackups.
• Ziehen Sie private Endpunkte (PE) für direkten, privaten Zugriff von VCNs oder On-Premise-Data Centern in Betracht. Beispiel: Sie können OCI Object Storage mit einer PE konfigurieren, die von einem VCN aus oder von einer On-Premise-Region über eine private IP-Adresse erreichbar ist.

Anforderungen an Hybrid- und Multicloud-Konnektivität

Bestimmen Sie, ob Ihre Architektur Hybrid- oder Multicloud-Architektur ist, und bewerten Sie die Bandbreite für eine qualitativ hochwertige Benutzererfahrung.

Verbinden Sie OCI mit On-Premise-Netzwerken basierend auf Ihren Anforderungen mit einer der folgenden Konnektivitätsoptionen:

• OCI FastConnect verwendet eine dedizierte Verbindung für feste Bandbreite und Latenz. Oracle empfiehlt die Verwendung redundanter Verbindungen zur Ausfallsicherheit.
• OCI Site-to-Site-VPN verwendet das Internet als Netzbetreiber und kann auch FastConnect verwenden. Bandbreite, Latenz und Verfügbarkeit können aufgrund von öffentlichen Internet-Circuits variieren. Oracle empfiehlt die Verwendung redundanter Tunnel.

Das folgende Diagramm zeigt eine Beispielarchitektur für die Verbindung einer On-Premise-Umgebung mit OCI über Site-to-Site-VPN oder FastConnect:

Beschreibung der Abbildung example-connect-premise-db-oci.png

Oracle empfiehlt, FastConnect für primäre Verbindungen mit VPN als Backup für Produktions-Workloads zu verwenden. FastConnect ist je nach Region und Partnern mit unterschiedlichen Geschwindigkeiten bis zu 400 Gbit/s verfügbar.

So richten Sie Ihre Konnektivität ein:

• Richten Sie einen Virtual Circuit mit Public Peering nur für den OSN-Zugriff ein.
• Private Peering für eine private Verbindung zu Ressourcen in VCNs verwenden.
• Verwenden Sie Site-to-Site-VPN (mit IPSec) für die Trafficverschlüsselung im Private Peering mit FastConnect.

Hinweis:

Oracle empfiehlt die Verwendung redundanter Hardware für alle Verbindungen.

Verbindung zu On-Premise-Netzwerken mit OCI FastConnect herstellen

OCI FastConnect bietet direkte, private Konnektivität. Konfigurieren Sie VPN immer als Backup. Das folgende Bild zeigt eine Architektur mit einer On-Premise- und OCI-Region, die OCI FastConnect verwendet, in der der Traffic nicht über das öffentliche Internet geleitet wird:

Beschreibung der Abbildung connect-premise-fastconnect.png

Oracle empfiehlt, FastConnect mit VPN als Backup als primäre Verbindungen für Produktions-Workloads zu verwenden. Verwenden Sie Site-to-Site-VPN als Backupverbindung für FastConnect, sodass die primäre Verbindung FastConnect und das Backup VPN ist. 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 OSN benötigen.
• Verwenden Sie OCI-Site-to-Site-VPN, das zusätzlich zum öffentlichen Peering mit FastConnect IPSec für die Verschlüsselung des Traffics verwendet.
• Verwenden Sie Private Peering, wenn Sie eine private Verbindung zu Ressourcen in OCI-VCNs benötigen.

Hinweis:

Oracle empfiehlt die Verwendung des doppelten Equipments zur Redundanz.

Verbindung zu On-Premise-Netzwerken mit OCI Site-to-Site-VPN herstellen

OCI Site-to-Site VPN verbindet ein On-Premise-Data Center mit OCI. Site-to-Site-VPN verwendet das Internet als Netzbetreiber und verschlüsselt den Datenverkehr mit dem IPSec-Protokoll. Site-to-Site-VPN ist eine kostengünstige, verschlüsselte Lösung mit geringerer Bandbreite (~250 Mbps/Tunnel). Verwenden Sie redundante Endpunkte und Geräte. Ziehen Sie Equal-Cost Multi-Path-(ECMP-)Routing für High Availability mit besserer Bandbreite in Betracht. Verwenden Sie Site-to-Site-VPN als kostenlose Alternative, wenn Sie nicht die leistungsstarken Verbindungen von Megaport oder Equinix benötigen, die in den nächsten Abschnitten beschrieben werden.

Das folgende Diagramm zeigt eine Architektur mit redundanter Customer-Premises-Ausrüstung (CPE) und einer OCI-Verbindung mit Site-to-Site-VPN:

Beschreibung der Abbildung connect-premise-site-site.png

Die Leistung von Site-to-Site-VPN kann je nach Internetverkehr variieren. Konfigurieren Sie wie bei FastConnect Site-to-Site-VPN mit redundanten Tunneln und wenn möglich auch mit redundanten CPE-Geräten. Oracle stellt zwei VPN-Endpunkte für jede Site-to-Site-VPN-Verbindung bereit.

Oracle Interconnect for Microsoft Azure

Microsoft und Oracle haben sich zusammengetan, um Microsoft Azure bereitzustellen, das in ausgewählten Regionen mit OCI vorintegriert ist.

Das folgende Diagramm zeigt eine Beispielarchitektur einer Oracle-Datenbank in einer OCI-Region und der Anwendung in Azure:

Beschreibung der Abbildung example-connect-db-oci-lb-azure.png

Latenz ist wichtig für eine gute Benutzererfahrung mit besseren Reaktionszeiten. Oracle und Azure verfügen über Integrationspunkte an verschiedenen Standorten auf der ganzen Welt. Dies erleichtert die Integration und reduziert auch die Latenz, sodass eine Lösung zwischen den Clouds mit FastConnect und Azure ExpressRoute möglich ist.

Sie können den Zugriff zwischen den Clouds aktivieren, indem Sie die Konfiguration über das Azure-Portal ExpressRoute und die OCI-Konsole FastConnect vornehmen. Sie müssen nur den Virtual Circuit 1x einrichten, da das Azure-Interconnect integrierte Redundanz mit physischer Hardware- und Standortvielfalt aufweist, sofern möglich. Es fallen keine Traffickosten zwischen Azure und OCI an (Egress-Kosten), wenn Sie eine lokale SKU verwenden und die Mindestverbindungsgeschwindigkeit von 1 Gbit/s für Azure ExpressRoute auswählen. Die Interconnects werden dort erstellt, wo Azure und OCI nahe beieinander liegen, um eine geringe Latenz zwischen den Clouds zu ermöglichen.

Hinweis:

Nicht alle Regionen verfügen über diese Fähigkeit. Verwenden Sie einen Netzwerkserviceprovider in anderen Regionen.

Wenn Sie eine Verbindung zu Microsoft Azure herstellen möchten, lesen Sie Zugriff auf Microsoft Azure.

Oracle Interconnect for Google Cloud

Oracle und Google haben sich zusammengetan, um Kunden direkte Konnektivität mit nativen Provisioning-Optionen aus beiden Clouds bereitzustellen. Oracle Interconnect for Google Cloud und OCI FastConnect können bereitgestellt werden, um Konnektivität mit geringer Latenz und hoher Bandbreite zu erstellen. Ohne Egress-Kosten von beiden Cloud-Anbietern. Ziehen Sie diese Option in Betracht, um Ihre Multicloud-Konnektivität so zu gestalten, dass Services sowohl in OCI als auch in Google Cloud verwendet werden.

Das folgende Architekturdiagramm zeigt eine Verbindung zwischen OCI und Google Cloud.

Beschreibung der Abbildung oci-google-cloud-connectivity.png

Verbindung zu AWS und anderen Cloud-Plattformen herstellen

Über unsere FastConnect-Partner können Sie schnell und einfach Verbindungen zu anderen Public Clouds von OCI herstellen. Wir haben über 100 globale FastConnect-Partner, aus denen Sie je nach Region und Konnektivitätsanforderungen auswählen können. Sie bieten verschiedene Optionen für die Verbindung mit anderen Cloud-Providern sowie anderen SaaS/PaaS-Plattformen.

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

Beschreibung der Abbildung connect-public-cloud-oci-aws.png

Sie können auch eine direkte VPN-Verbindung zwischen AWS und OCI in Betracht ziehen.

Resilienzanforderungen

Bewerten Sie Ihren Bedarf an regionaler Resilienz vor Ausfällen, und betrachten Sie eine Bereitstellung mit mehreren Regionen.

Multiregion-Deployment

Stellen Sie ein standardmäßiges regionsübergreifendes Setup für ein Deployment mit mehreren Regionen bereit, und koppeln Sie Disaster Recovery und Failover. Replizieren Sie die Ressourcen in der Standbyregion zur Failover-Bereitschaft, und richten Sie Remote-Peering zwischen DRGs ein. Die Datenreplikation verwendet das Netzwerk-Backbone von Oracle, nicht das öffentliche Internet.

Das folgende Diagramm zeigt die Datenreplikation zwischen einer primären und einer Standby-Region:

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

Load Balancing

Verwenden Sie einen Load Balancer (öffentlich oder privat), um die Trafficverteilung zu optimieren. mehrere Backend-Server.

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

Load Balancer

Ein Standard-Load Balancer für öffentliche Webserver kann SSL-Traffic beenden oder an das Backend übergeben. Verwenden Sie flexible Ausprägungen zwischen der minimalen und maximalen Bandbreite je nach Datenverkehr.

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

Network Load Balancer

Freier Service, der ein Non-Proxy-Load Balancing mit extrem niedriger Latenz und hohem Durchsatz bietet. Network Load Balancer sind für Verbindungen mit langer Ausführungszeit über Tage oder Monate mit Verbindungen zu demselben Backend-Server optimiert, der optimal für die Datenbank ist.

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.

Weitere Informationen finden Sie im Thema Load Balancer und Network Load Balancer vergleichen in der OCI-Dokumentation, die unter Weitere Informationen verknüpft ist.

Sicherheitsanforderungen

Sicherheit ist für jede Netzwerkarchitektur von entscheidender Bedeutung. Wählen Sie die geeigneten OCI-Services aus, um die erforderliche Sicherheitslage für Ihre Anwendungen und Netzwerke festzulegen, unabhängig davon, ob sie On-Premises oder in der Cloud sind.

OCI-Web Application Firewall

Oracle Cloud Infrastructure Web Application Firewall (WAF) ist ein regionaler und Edge Enforcement-Service, der an Enforcement Points wie Load Balancer oder Webanwendungsdomainnamen angehängt wird. OCI WAF schützt Anwendungen vor schädlichem und unerwünschtem Internettraffic.

Mit der OCI WAF-Policy können Sie die folgenden Regeln für alle OCI-Anwendungen durchsetzen:

• Zugriffskontrolle
• Botverwaltung
• Schutzregeln
• Ratenlimits
• Kundenanwendungen

Hinweis:

Mit WAF können Sie alle internetseitigen Endpunkte schützen und eine konsistente Durchsetzung von Sicherheitsregeln über Anwendungen hinweg sicherstellen.

Weitere Informationen finden Sie sowohl in der OCI WAF-Policy (regionale Lösung) als auch in der Edge-Policy (globale Lösung).

OCI Network Firewall

Wählen Sie basierend auf dem erforderlichen Netzwerksicherheitsstatus die Deployment-Option für die Netzwerkfirewall aus.

Das folgende Diagramm zeigt ein unterstütztes OCI Network Firewall-Einfügedesign, mit dem eine einzelne OCI Network Firewall verwendet werden kann, um sowohl Nord-Süd-(Internet-) als auch Ost-West-(Inter-VCN- und On-Premise-)Trafficmuster zu verwalten:

Beschreibung der Abbildung oci-network-firewall-inspect-traffic.png

In dieser Architektur prüft und sichert eine OCI-Netzwerkfirewall, die in einem zentralen Hub-VCN bereitgestellt ist, Trafficflüsse, die aus dem Internet, aus dem Internet und aus einer On-Premise-Region eingehen.

Zero Trust Packet Routing

Denken Sie daran, Oracle Cloud Infrastructure Zero Trust Packet Routing (ZPR) für die Implementierung eines verbesserten Sicherheitsstatus mit einfachem Policy-Deployment zu verwenden.

Das folgende Diagramm zeigt Netzwerksicherheits-Policys, die unabhängig von der zugrunde liegenden Netzwerkarchitektur verwaltet werden, um das Risiko eines nicht autorisierten Zugriffs zu reduzieren:

Beschreibung der Abbildung zpr-enhanced-security.png

Sicherheitsadministratoren können schnell absichtsbasierte Zugriffs-Policys definieren. Nur explizit zugelassener Verkehr ist erlaubt, so dass unberechtigter Zugriff unmöglich ist. Dieser Ansatz vereinfacht die Verwaltungs- und Auditprozesse für Netzwerksicherheit.