Hinweise zum Entwurf

Netzwerkisolation

Sie können die Compute-Instanzen in Ihrer Cloud-Topologie an ein privates Subnetz oder ein öffentliches Subnetz anhängen, je nachdem, ob Sie den Zugriff auf die Instanzen über das Internet zulassen möchten. Eine Compute-Instanz, die an ein öffentliches Subnetz angehängt wird, kann einer öffentlichen IP-Adresse zugewiesen werden, und Sie können über das Internetgateway auf die Instanz zugreifen. Compute-Instanzen, die privaten Subnetzen zugeordnet sind, haben nur private Adressen.

Szenario 1: Nur private Subnetze verwenden
Bei Produktions-Deployments, die keine internetseitigen Endpunkte erfordern, hängen Sie alle Ressourcen an private Subnetze an. Auf die Ressourcen kann nicht direkt über das öffentliche Internet zugegriffen werden. Dieser Deployment-Typ ist nützlich, wenn Sie eine Hybridtopologie bereitstellen möchten, wobei die Cloud-Topologie eine Erweiterung für Ihr On-Premise-Data Center ist.

Um über Ihre On-Premise-Umgebung auf die Cloud-Topologie zuzugreifen, können Sie IPSec-VPN-Tunnel oder FastConnect-Virtual-Circuits verwenden. Sie sollten einen Bastion-Host erstellen, über den Sie auf alle Server zugreifen können, die den privaten Subnetzen zugeordnet sind.
Szenario 2: Öffentliche und private Subnetze verwenden
Sie können einige Instanzen an ein öffentliches Subnetz und den Rest an private Subnetze anhängen. Dieser Deployment-Typ ist nützlich, wenn die Anwendungen sowohl interne als auch nicht interaktive Endpunkte haben.

Bestimmte Anwendungen können z. B. von internen Benutzern verwendet werden, und andere Anwendungen bearbeiten externe Benutzer. Hängen Sie die Anwendungsinstanzen an, die internen Datenverkehr an private Subnetze senden, und hängen Sie die Anwendungsserver an, die externen Datenverkehr an ein öffentliches Subnetz bedienen.

Alternativ können Sie bei der internetseitigen Anwendungsinstanzen, anstatt die Anwendungsserver an ein öffentliches Subnetz anzuhängen, einen öffentlichen Load Balancer verwenden.

Wenn Sie einen Bastion-Host erstellen und an ein öffentliches Subnetz in dieser Topologie anhängen, können Sie über den Bastion-Host auf die Compute-Instanzen zugreifen, die den privaten Subnetzen zugeordnet sind.
Szenario 2: Nur öffentliche Subnetze verwenden
Für schnelle Versuche oder Demos oder bei Deployments von Produktgruppen, die keine internen Endpunkte erfordern, können Sie alle Ressourcen mit öffentlichen Subnetzen verknüpfen. Dieses Deployment eignet sich, wenn Sie kein eigenes Data Center haben oder mit IPSec-VPN-Tunneln oder FastConnect Virtual Circuits nicht auf die Cloud zugreifen können. In diesem Deployment werden alle Instanzen, einschließlich der Anwendungs- und Datenbankinstanzen, öffentlichen Subnetzen zugeordnet. Jede Instanz hat eine öffentliche IP-Adresse. Mit Sicherheitslisten oder Netzwerksicherheitsgruppen können Sie den Netzwerkzugriff auf die privaten Ressourcen regulieren.

Um den administrativen Zugriff auf eine derartige Cloud-Topologie zu steuern, sollten Sie einen Bastion-Host erstellen, über den Sie auf alle Server in der Topologie zugreifen können. Bei dieser Lösung würden Sie die Administrationsports nur für den Bastion-Host (und nicht für das öffentliche Internet) öffnen, indem Sie Sicherheitslisten oder Netzwerksicherheitsgruppen verwenden.

High Availability

Stellen Sie sicher, dass die Cloud-Topologie keine einzelnen Fehlerquellen auf jeder Ebene hat: Load Balancer, Web Tier, Application Tier und Database Tier.

Der Oracle Cloud Infrastructure Load Balancing-Service erstellt ein primäres Standby-Paar von Load Balancer-Knoten. Die Knoten werden in separaten Availability-Domains bereitgestellt. In Regionen mit einer einzelnen Availability-Domain werden die Load Balancer-Knoten in separaten Faultdomains erstellt. Daher wirkt sich der Load Balancer nicht auf Hardwarefehler und Data-Center-Ausfälle aus.
Redundante Ressourcen in Web Tier, Application Tier und Database Tier bereitstellen. Wenn Sie beschließen, die Topologie in einer einzelnen Availability-Domain bereitzustellen, können Sie die Ressourcen über Faultdomains innerhalb der Availability-Domain verteilen. Wenn Ihre Region mehrere Availability-Domains aufweist, können Sie die Data-Center-Isolation nutzen, die diese Regionen anbieten, und die Production- und redundanten Ressourcen in separaten Availability-Domains bereitstellen.
Für eine hohe Verfügbarkeit der Datenbanken können Sie ein Virtual-Machine-DB-System mit 2-Knoten erstellen, das Oracle Real Applications Clusters (RAC) bereitstellt. Die beiden Knoten werden standardmäßig in separaten Faultdomains erstellt. Sie können explizit eine Faultdomain für die RAC-Knoten beim Datenbank-Provisioning wählen. Deshalb werden die Datenbankknoten nicht auf derselben physischen Hardware ausgeführt. Dieses Deployment schützt die Datenbanken vor Fehlern in den zugrunde liegenden physischen Hosts und dem letzten Rack-Switch.
Beim Disaster Recovery sollten Sie eine Standbytopologie in einer Remoteregion bereitstellen.

Backup-Strategie

Implementieren Sie eine robuste Backupstrategie für die Datenbank und die Anwendungen, um die effiziente Wiederherstellung der Daten und Anwendungen bei einem Ausfall zu ermöglichen.

Sie können automatische und On-Demand-Backups Ihrer Datenbanken für Oracle Cloud Infrastructure Object Storage konfigurieren. Alle Datenbankbackups werden mit demselben Masterschlüssel verschlüsselt, der für die Wallet-Verschlüsselung von Transparent Data Encryption (TDE) verwendet wird. Der automatische Datenbankbackupservice verwendet eine wöchentliche inkrementelle Backupstrategie für das Backup von Datenbanken mit einer Aufbewahrungs-Policy, die Sie anpassen können.

Für die Anwendungen können Sie Policy-basierte Backups der Block-Volumes konfigurieren. Jede Backup-Policy verfügt über eine vordefinierte Backuphäufigkeit und einen vordefinierten Aufbewahrungszeitraum. Wählen Sie eine Policy, die Sie bei den Complianceanforderungen und gesetzlichen Bestimmungen unterstützt.