Unternehmensanwendung mit Oracle-Datenbank in der Compute Engine

Last reviewed 2024-09-02 UTC

In diesem Dokument finden Sie eine Referenzarchitektur, die Ihnen beim Erstellen der Infrastruktur für das Hosten einer hochverfügbaren Unternehmensanwendung mit einer Oracle-Datenbank hilft. Der gesamte Stack wird auf Compute Engine-VMs bereitgestellt. Sie können diese Referenzarchitektur verwenden, um lokale Anwendungen, die Oracle-Datenbanken verwenden, effizient zu hosten (Lift-and-Shift). Dieses Dokument enthält auch eine Anleitung zum Erstellen einer Oracle-Datenbanktopologie in Google Cloud, die die Anforderungen der Oracle-Architektur für maximale Verfügbarkeit (Maximum Availability Architecture, MAA) erfüllt. Dieses Dokument richtet sich an Cloud-Architekten und Oracle-Datenbankadministratoren. In diesem Dokument wird davon ausgegangen, dass Sie mit der Compute Engine und Oracle Database vertraut sind.

Wenn Sie Oracle Exadata oder Oracle Real Application Clusters (Oracle RAC) zum Ausführen von Oracle-Datenbanken vor Ort verwenden, können Sie Ihre Anwendungen effizient zu Google Cloud migrieren und Ihre Datenbanken in Oracle Database@Google Cloud ausführen. Weitere Informationen finden Sie unter Unternehmensanwendung auf Compute Engine-VMs mit Oracle Exadata in Google Cloud.

Architektur

Das folgende Diagramm zeigt die Infrastruktur für eine mehrstufige Unternehmensanwendung, die Oracle Database verwendet. Die Webebene, die Anwendungsebene und die Oracle-Datenbankinstanzen werden auf Compute Engine-VMs gehostet. Die Web- und Anwendungsebene werden im Aktiv/Aktiv-Modus auf VMs ausgeführt, die auf zwei Zonen innerhalb einer Google Cloud-Region verteilt sind. Die primäre Datenbankinstanz und die Standby-Datenbankinstanz werden in separaten Zonen bereitgestellt. Diese Architektur ist auf den Archetyp für regionale Bereitstellungen ausgerichtet. Dadurch wird sichergestellt, dass Ihre Google Cloud-Topologie gegen Ausfälle in einer einzelnen Zone resistent ist.

Eine mehrschichtige Unternehmensanwendung verwendet Oracle Database auf Compute Engine-VMs.

Die im vorherigen Diagramm dargestellte Architektur umfasst die folgenden Komponenten:

Komponente Zweck
Regionaler externer Application Load Balancer Der regionale externe Application Load Balancer empfängt und verteilt Nutzeranfragen an die Webstufen-VMs.
Google Cloud Armor-Sicherheitsrichtlinie Mit der Google Cloud Armor-Sicherheitsrichtlinie können Sie Ihren Anwendungsstack vor Bedrohungen wie DDoS-Angriffen (Distributed Denial of Service) und Cross-Site-Scripting (XSS) schützen.
Regionale verwaltete Instanzgruppe (Managed Instance Group, MIG) für die Webebene Die Webebene der Anwendung wird auf Compute Engine-VMs bereitgestellt, die Teil einer regionalen MIG sind. Diese MIG ist das Backend für den externen Application Load Balancer. Die MIG enthält Compute Engine-VMs in zwei Zonen. Jede dieser VMs hostet eine unabhängige Instanz der Webebene der Anwendung.
Regionaler interner Application Load Balancer Der regionale interne Application Load Balancer verteilt den Traffic von den VMs der Webebene auf die VMs der Anwendungsebene.
Regionale MIG für die Anwendungsebene Die Anwendungsebene, z. B. ein Oracle WebLogic Server-Cluster, wird auf Compute Engine-VMs bereitgestellt, die Teil einer regionalen MIG sind. Diese MIG ist das Backend für den internen Application Load Balancer. Die MIG enthält Compute Engine-VMs in zwei Zonen. Jede VM hostet eine unabhängige Instanz des Anwendungsservers.
Oracle Database-Instanzen, die auf Compute Engine-VMs bereitgestellt werden Die Anwendung in dieser Architektur verwendet ein primäres und ein Standby-Paar von Oracle-Datenbankinstanzen, die auf Compute Engine-VMs in separaten Zonen bereitgestellt werden. Sie stellen für diese Oracle-Datenbankinstanzen Ihre eigenen Lizenzen bereit (Bring Your Own License, BYOL) und verwalten die VMs und Datenbankinstanzen.
Hyperdisk Storage Pools Die VMs in jeder Zone (über alle Ebenen im Anwendungsstack hinweg) verwenden Hyperdisk Balanced-Volumes aus einem Hyperdisk-Speicherpool. Wenn Sie alle Laufwerke in einem einzigen Speicherpool erstellen und verwalten, verbessern Sie die Kapazitätsauslastung und reduzieren die Betriebskomplexität, während die für die VMs erforderliche Speicherkapazität und Leistung beibehalten wird.
Oracle Data Guard FSFO-Beobachter Der Oracle Data Guard Fast-Start Failover (FSFO)-Beobachter ist ein schlankes Programm, das ein automatisches Failover zur Standby-Oracle-Datenbankinstanz initiiert, wenn die primäre Instanz nicht verfügbar ist. Der Beobachter wird auf einer Compute Engine-VM in einer Zone ausgeführt, die sich von den Zonen unterscheidet, in denen die primäre und die Standby-Datenbankinstanz bereitgestellt werden.
Cloud Storage-Bucket Für die Speicherung von Sicherungen der Oracle-Datenbankinstanzen wird in dieser Architektur ein Cloud Storage-Bucket verwendet. Um die Wiederherstellung der Datenbank bei einem regionalen Ausfall zu erleichtern, können Sie die Sicherungen georedundant in einem biregionalen oder multiregionalen Bucket speichern.
VPC-Netzwerk (Virtual Private Cloud) und Subnetz Alle Google Cloud-Ressourcen in der Architektur verwenden ein einzelnes VPC-Netzwerk und ein Subnetz. Je nach Ihren Anforderungen können Sie eine Architektur erstellen, die mehrere VPC-Netzwerke oder mehrere Subnetze verwendet. Weitere Informationen finden Sie unter Entscheiden, ob mehrere VPC-Netzwerke erstellt werden sollen.
Öffentliches Cloud NAT-Gateway Die Architektur umfasst ein öffentliches Cloud NAT-Gateway, um sichere ausgehende Verbindungen von den Compute Engine-VMs zu ermöglichen, die nur interne IP-Adressen haben.
Cloud Interconnect und Cloud VPN Sie können Cloud Interconnect oder Cloud VPN verwenden, um Ihr lokales Netzwerk mit dem VPC-Netzwerk in Google Cloud zu verbinden. Informationen zu den relativen Vorteilen der einzelnen Ansätze finden Sie unter Netzwerkverbindungsprodukt auswählen.
Cloud Monitoring und Cloud Logging Mit Cloud Monitoring können Sie das Verhalten, den Zustand und die Leistung Ihrer Anwendung und Ihrer Google Cloud-Ressourcen beobachten. Der Ops-Agent erfasst Messwerte und Protokolle von den Compute Engine-VMs, einschließlich der VMs, auf denen die Oracle-Datenbankinstanzen gehostet werden. Der Agent sendet Logs an Cloud Logging und Messwerte an Cloud Monitoring.

Verwendete Produkte

In dieser Referenzarchitektur werden die folgenden Google Cloud-Produkte verwendet:

  • Compute Engine: Ein sicherer und anpassbarer Computing-Dienst, mit dem Sie virtuelle Maschinen in der Infrastruktur von Google erstellen und ausführen können.
  • Google Cloud Hyperdisk: Ein Netzwerkspeicherdienst, mit dem Sie Blockspeichervolumes mit konfigurierbarer und vorhersehbarer Leistung bereitstellen und dynamisch skalieren können.
  • Cloud Load Balancing: Ein Portfolio von leistungsstarken, skalierbaren, globalen und regionalen Load-Balancern
  • Cloud Storage: Ein kostengünstiger, unbegrenzter Objektspeicher für verschiedene Datentypen. Auf Daten kann von innerhalb und außerhalb von Google Cloud zugegriffen werden. Sie werden zu Redundanzzwecken über Standorte hinweg repliziert.
  • Virtual Private Cloud (VPC): Ein virtuelles System, das globale, skalierbare Netzwerkfunktionen für Ihre Google Cloud-Arbeitslasten bietet. VPC umfasst VPC-Netzwerk-Peering, Private Service Connect, Zugriff auf private Dienste und freigegebene VPC.
  • Google Cloud Armor: Ein Netzwerksicherheitsdienst, der WAF-Regeln (Web Application Firewall) bietet und vor DDoS- und Anwendungsangriffen schützt.
  • Cloud NAT: Ein Dienst, der eine von Google Cloud verwaltete, leistungsstarke Netzwerkadressübersetzung bietet.
  • Cloud Monitoring: Ein Dienst, der Einblicke in die Leistung, Verfügbarkeit und Integrität Ihrer Anwendungen und Infrastruktur bietet.
  • Cloud Logging: Ein Echtzeit-Log-Verwaltungssystem mit Speicher, Suche, Analyse und Benachrichtigungen.
  • Cloud Interconnect: Ein Dienst, mit dem Ihr externes Netzwerk über eine hochverfügbare Verbindung mit niedriger Latenz auf das Google-Netzwerk erweitert wird.
  • Cloud VPN: Ein Dienst, mit dem Sie Ihr Peer-Netzwerk über einen IPsec-VPN-Tunnel sicher auf das Google-Netzwerk ausdehnen können.

In dieser Referenzarchitektur werden die folgenden Oracle-Produkte verwendet:

  • Oracle Database: Ein relationales Datenbankverwaltungssystem (Relational Database Management System, RDBMS), das das relationale Modell auf ein objektrelationales Modell erweitert.
  • Oracle Data Guard: Eine Reihe von Diensten zum Erstellen, Verwalten, Verwalten und Überwachen einer oder mehrerer Standby-Datenbanken.

Sie sind selbst dafür verantwortlich, die Lizenzen für die Oracle-Produkte zu erwerben, die Sie in Google Cloud bereitstellen, und sind für die Einhaltung der Nutzungsbedingungen der Oracle-Lizenzen verantwortlich.

Designaspekte

In diesem Abschnitt werden Designfaktoren, Best Practices und Designempfehlungen beschrieben, die Sie berücksichtigen sollten, wenn Sie diese Referenzarchitektur verwenden, um eine Topologie zu entwickeln, die Ihren spezifischen Anforderungen an Sicherheit, Zuverlässigkeit, operative Effizienz, Kosten und Leistung entspricht.

Die Anleitung in diesem Abschnitt ist nicht vollständig. Je nach den spezifischen Anforderungen Ihrer Anwendung und den von Ihnen verwendeten Google Cloud-Produkten und -Features sowie Drittanbieterprodukten und ‑Features müssen möglicherweise zusätzliche Designfaktoren und Vor- und Nachteile berücksichtigt werden.

Systemdesign

Dieser Abschnitt enthält eine Anleitung zur Auswahl von Google Cloud-Regionen für Ihre Bereitstellung und zur Auswahl geeigneter Google Cloud-Dienste.

Auswahl der Region

Berücksichtigen Sie bei der Auswahl der Google Cloud-Region für Ihre Bereitstellung die folgenden Faktoren und Anforderungen:

Einige dieser Faktoren und Anforderungen können Kompromisse beinhalten. Beispielsweise hat die kostengünstigste Region möglicherweise nicht die niedrigste CO2-Bilanz. Weitere Informationen finden Sie unter Best Practices für die Auswahl der Region in Compute Engine.

Recheninfrastruktur

In der Referenzarchitektur in diesem Dokument werden Compute Engine-VMs zum Hosten aller Ebenen der Anwendung verwendet. Je nach Anforderungen Ihrer Anwendung können Sie aus den folgenden anderen Google Cloud-Computing-Diensten auswählen:

  • Container: Sie können containerisierte Anwendungen in Google Kubernetes Engine-Clustern (GKE) ausführen. GKE ist eine Engine zur Containerorchestrierung, die die Bereitstellung, Skalierung und Verwaltung von Containeranwendungen automatisiert.
  • Serverlos: Wenn Sie sich auf Ihre IT-Bemühungen auf Ihre Daten und Anwendungen konzentrieren möchten, anstatt Infrastrukturressourcen einzurichten und zu betreiben, können Sie serverlose Dienste wie Cloud Run verwenden.

Die Entscheidung, ob VMs, Container oder serverlose Dienste verwendet werden sollen, erfordert einen Kompromiss zwischen Konfigurationsflexibilität und Verwaltungsaufwand. VMs und Container bieten mehr Konfigurationsflexibilität und -kontrolle, aber Sie sind für die Verwaltung der Ressourcen verantwortlich. In einer serverlosen Architektur stellen Sie Arbeitslasten auf einer vorkonfigurierten Plattform bereit, die minimalen Verwaltungsaufwand erfordern. Die Designanleitung für diese Dienste wird in diesem Dokument nicht behandelt. Weitere Informationen zu Dienstoptionen finden Sie unter Optionen für das Anwendungshosting.

Speicheroptionen

Die in diesem Dokument dargestellte Architektur verwendet in jeder Zone einen Hyperdisk-Speicherpool mit Hyperdisk Balanced-Volumes für die VMs in allen Ebenen. Hyperdisk-Volumes bieten eine bessere Leistung, Flexibilität und Effizienz als Persistent Disk. Informationen zu Hyperdisk-Typen und ‑Funktionen finden Sie unter Informationen zu Hyperdisk.

Sie können eine Filestore-Regionalinstanz nutzen, um Daten zu speichern, die von mehreren VMs in einer Region gemeinsam genutzt werden, z. B. Konfigurationsdateien für alle VMs in der Webebene. Die Daten, die Sie in einer regionalen Filestore-Instanz speichern, werden synchron über drei Zonen innerhalb der Region repliziert. Die Replikation sorgt für hohe Verfügbarkeit und Robustheit bei zonalen Ausfällen. Sie können freigegebene Konfigurationsdateien, gängige Tools und Dienstprogramme sowie zentralisierte Logs in der Filestore-Instanz speichern und die Instanz auf mehreren VMs bereitstellen.

Berücksichtigen Sie beim Entwerfen des Speichers für Ihre Arbeitslasten die funktionalen Eigenschaften der Arbeitslasten, Anforderungen an die Ausfallsicherheit, Leistungserwartungen und Kostenziele. Weitere Informationen finden Sie unter Optimale Speicherstrategie für Ihre Cloudarbeitslast entwerfen.

Netzwerkkonzept

Wenn Sie eine Infrastruktur für einen mehrstufigen Anwendungs-Stack erstellen, müssen Sie ein Netzwerkdesign auswählen, das Ihren geschäftlichen und technischen Anforderungen entspricht. In der in diesem Dokument dargestellten Architektur wird eine einfache Netzwerktopologie mit einem einzelnen VPC-Netzwerk und einem einzelnen Subnetz verwendet. Je nach Ihren Anforderungen können Sie mehrere VPC-Netzwerke oder mehrere Subnetze verwenden. Weitere Informationen finden Sie in der folgenden Dokumentation:

Sicherheit, Datenschutz und Compliance

In diesem Abschnitt werden Faktoren beschrieben, die Sie bei der Verwendung dieser Referenzarchitektur berücksichtigen sollten, um eine Topologie in Google Cloud zu entwerfen, die die Sicherheits- und Compliance-Anforderungen Ihrer Arbeitslasten erfüllt.

Schutz vor externen Bedrohungen

Um Ihre Anwendung vor externen Bedrohungen wie DDoS-Angriffen und XSS zu schützen, definieren Sie geeignete Google Cloud Armor-Sicherheitsrichtlinien entsprechend Ihren Anforderungen. Jede Richtlinie besteht aus Regeln, die die zu prüfenden Bedingungen und die auszuführenden Aktionen festlegen, wenn die Bedingungen erfüllt sind. Eine Regel könnte beispielsweise festlegen, dass der Traffic abgelehnt werden muss, wenn die Quell-IP-Adresse des eingehenden Traffics mit einer bestimmten IP-Adresse oder einem CIDR-Bereich übereinstimmt. Sie können auch vorkonfigurierte WAF-Regeln (Web Application Firewall) anwenden. Weitere Informationen finden Sie unter Sicherheitsrichtlinien – Übersicht.

Externer Zugriff für VMs

In der Referenzarchitektur, die in diesem Dokument beschrieben wird, benötigen die VMs, auf denen die Webebene, die Anwendungsebene und die Oracle-Datenbankinstanzen gehostet werden, keinen direkten eingehenden Zugriff aus dem Internet. Weisen Sie diesen VMs keine externen IP-Adressen zu. Google Cloud-Ressourcen, die nur private, interne IP-Adressen haben, können über Private Service Connect oder den privater Google-Zugriff dennoch auf bestimmte Google APIs und Google-Dienste zugreifen. Weitere Informationen finden Sie unter Optionen für den privaten Zugriff.

Um sichere ausgehende Verbindungen von Google Cloud-Ressourcen zu ermöglichen, die nur private IP-Adressen haben, wie die Compute Engine-VMs in dieser Referenzarchitektur, können Sie Folgendes verwenden:Sicherer Web-Proxy oderCloud NAT.

VM-Image-Sicherheit

Genehmigte Images sind Images mit Software, die Ihren Richtlinien- oder Sicherheitsanforderungen entspricht. Wenn Sie möchten, dass Ihre VMs nur genehmigte Images verwenden, können Sie eine Organisationsrichtlinie definieren, die die Verwendung von Images in bestimmten öffentlichen Image-Projekten einschränkt. Weitere Informationen finden Sie unter Trusted Image-Richtlinien einrichten.

Dienstkontoberechtigungen

In Google Cloud-Projekten, in denen die Compute Engine API aktiviert ist, wird automatisch ein Standarddienstkonto erstellt. Für Google Cloud-Organisationen, die vor dem 3. Mai 2024 erstellt wurden, wird diesem Standarddienstkonto die IAM-Rolle „Bearbeiter“ (roles/editor) zugewiesen, sofern dieses Verhalten nicht deaktiviert ist.

Standardmäßig wird das Standarddienstkonto an alle VMs angehängt, die Sie mithilfe der Google Cloud CLI oder der Google Cloud Console erstellen. Die Rolle "Bearbeiter" umfasst eine Vielzahl von Berechtigungen. Das Anhängen des Standarddienstkontos an VMs stellt also ein Sicherheitsrisiko dar. Um dieses Risiko zu vermeiden, können Sie für jede Schicht des Anwendungsstacks dedizierte Dienstkonten erstellen und verwenden. Verwenden Sie detaillierte Richtlinien, um die Ressourcen anzugeben, auf die das Dienstkonto zugreifen kann. Weitere Informationen finden Sie unter Dienstkontoberechtigungen einschränken.

Laufwerksverschlüsselung

Standardmäßig werden die in Hyperdisk-Volumes gespeicherten Daten mit Google-eigenen und von Google verwalteten Schlüsseln verschlüsselt. Als zusätzliche Schutzebene können Sie die von Google verwalteten Verschlüsselungsschlüssel für Daten mithilfe von Schlüsseln verschlüsseln, die Ihnen gehören und die Sie im Cloud Key Management Service (Cloud KMS) verwalten. Weitere Informationen finden Sie unter Laufwerkverschlüsselung.

Netzwerksicherheit

Zur Steuerung des Netzwerk-Traffics zwischen den Ressourcen in der Architektur müssen Sie geeignete Cloud Next Generation Firewall-Richtlinien (NGFW) konfigurieren.

Weitere Sicherheitsaspekte

Beachten Sie beim Erstellen der Architektur für Ihre Arbeitslast die Best Practices und Empfehlungen zur Sicherheit auf Plattformebene, die im Unternehmensgrundlagen-Blueprint enthalten sind.

Zuverlässigkeit

In diesem Abschnitt werden Designfaktoren beschrieben, die Sie bei der Verwendung dieser Referenzarchitektur zum Erstellen und Betreiben einer zuverlässigen Infrastruktur für Ihre Bereitstellung in Google Cloud berücksichtigen sollten.

Robustheit bei VM-Fehlern

In der in diesem Dokument dargestellten Architektur kann die Anwendung bei einem Ausfall einer Compute Engine-VM in einer der Ebenen weiterhin Anfragen verarbeiten.

  • Wenn eine VM in der Web- oder Anwendungsebene abstürzt, erstellt die entsprechende MIG die VM automatisch neu. Die Load Balancer leiten Anfragen nur an die derzeit verfügbaren Webserver- und Anwendungsserverinstanzen weiter.
  • Wenn die VM, auf der die primäre Oracle-Datenbankinstanz gehostet wird, ausfällt, initiiert der Oracle Data Guard-Beobachter für den automatischen Failover zur Standby-Oracle-Datenbankinstanz.

Automatische Reparatur von VMs

Manchmal werden die VMs, auf denen Ihre Web- und Anwendungsebene gehostet wird, ausgeführt und verfügbar gemacht. Es können jedoch Probleme mit der Anwendung selbst auftreten. Die Anwendung kann einfrieren, abstürzen oder nicht genügend Arbeitsspeicher haben. In diesem Szenario reagieren die VMs nicht auf die Systemdiagnosen des Load Balancers und der Load Balancer leitet den Traffic nicht an die nicht reagierenden VMs weiter. Sie können anwendungsbasierte Systemdiagnosen als Teil der Richtlinie für die automatische Reparatur Ihrer MIGs konfigurieren, um dafür zu sorgen, dass Anwendungen wie erwartet reagieren. Wenn die Anwendung auf einer bestimmten VM nicht reagiert, wird die VM von der MIG automatisch repariert. Weitere Informationen zur Konfiguration der automatischen Reparatur finden Sie unter VMs für Hochverfügbarkeit reparieren.

Robustheit bei zonalen Ausfällen

Wenn ein zonaler Ausfall auftritt, bleibt die Anwendung verfügbar.

  • Die Webebene und die Anwendungsebene sind verfügbar (und reaktionsfähig), da sich die VMs in regionalen MIGs befinden. Die regionalen MIGs sorgen dafür, dass neue VMs automatisch in der anderen Zone erstellt werden, um die konfigurierte Mindestanzahl von VMs aufrechtzuerhalten. Die Load Balancer leiten Anfragen an die verfügbaren Webserver-VMs und Anwendungsserver-VMs weiter.
  • Wenn ein Ausfall die Zone mit der primären Oracle-Datenbankinstanz betrifft, initiiert der Oracle Data Guard-Beobachter für den FSFO ein automatisches Failover auf die Standby-Oracle-Datenbankinstanz. Der FSFO-Beobachter wird auf einer VM in einer anderen Zone ausgeführt als die Zonen mit den primären und Standby-Datenbankinstanzen.
  • Um bei einem Ausfall einer einzelnen Zone für eine hohe Verfügbarkeit von Daten in Hyperdisk-Volumes zu sorgen, können Sie Hyperdisk mit ausgeglichener Hochverfügbarkeit verwenden. Wenn Daten in ein Volume geschrieben werden, werden sie synchron zwischen zwei Zonen in derselben Region repliziert.

Robustheit bei regionalen Ausfällen

Wenn beide Zonen in der Architektur einen Ausfall haben oder ein regionaler Ausfall auftritt, ist die Anwendung nicht verfügbar. Sie können Ausfallzeiten durch Ausfälle in mehreren Zonen oder Regionen reduzieren, indem Sie Folgendes implementieren:

  • Ein passives (Failover-)Replikat des Infrastruktur-Stacks in einer anderen Google Cloud-Region verwalten.

  • Verwenden Sie einen Dual-Region- oder Multi-Region-Cloud Storage-Bucket, um die Oracle-Datenbanksicherungen zu speichern. Die Sicherungen werden asynchron an mindestens zwei geografischen Standorten repliziert. Mit replizierten Datenbanksicherungen entspricht Ihre Architektur der Stufe „Silver“ der Oracle Maximum Availability Architecture (MAA).

    Wenn Sie eine schnellere Replikation für Sicherungen erzielen möchten, die in Buckets mit zwei Regionen gespeichert sind, können Sie die Turboreplikation verwenden. Weitere Informationen finden Sie unter Datenverfügbarkeit und Langlebigkeit.

  • Wenn ein Ausfall in der primären Region auftritt, verwenden Sie die Datenbanksicherung, um die Datenbank wiederherzustellen und die Anwendung in der Failover-Region zu aktivieren. Verwenden Sie DNS-Routingrichtlinien, um Traffic an den Load Balancer in der Failover-Region weiterzuleiten.

Für geschäftskritische Anwendungen, die auch bei einem regionalen Ausfall verfügbar sein müssen, sollten Sie den Archetyp für die multiregionale Bereitstellung verwenden. Für die Datenbankebene können Sie Oracle Active Data Guard FSFO verwenden, um automatisch ein Failover zu einer Standby-Oracle-Datenbankinstanz in der Failover-Region auszuführen. Dieser Ansatz entspricht der MAA Gold-Stufe von Oracle.

MIG-Autoscaling

Wenn Sie Ihre Anwendung auf VMs in einer regionalen MIG ausführen, bleibt die Anwendung während des Ausfalls einer isolierten Zone verfügbar. Mit der Autoscaling-Funktion zustandsloser MIGs können Sie die Verfügbarkeit und Leistung von Anwendungen auf vorhersehbaren Leveln aufrechterhalten. Zustandsorientierte MIGs können nicht automatisch skaliert werden.

Zum Steuern des Autoscaling-Verhaltens Ihrer MIGs können Sie Zielauslastungsmesswerte angeben, z. B. die durchschnittliche CPU-Auslastung. Sie können auch zeitplanbasiertes Autoscaling konfigurieren. Weitere Informationen finden Sie unter Autoscaling von Instanzgruppen.

VM-Platzierung

In der in diesem Dokument beschriebenen Architektur werden die Anwendungsebene und die Webebene auf Compute Engine-VMs ausgeführt, die über mehrere Zonen verteilt sind. Diese Verteilung sorgt dafür, dass Ihre Anwendung gegen Ausfälle einer einzelnen Zone resistent ist. Zur weiteren Verbesserung dieser Robustheit können Sie eine Richtlinie für gestreute Platzierungen erstellen und auf die MIG-Vorlage anwenden. Wenn Sie eine Streuplatzierungsrichtlinie verwenden, werden die VMs bei der Erstellung durch die MIG in jeder Zone auf verschiedenen physischen Servern (Hosts) platziert. Dadurch sind Ihre VMs gegen Ausfälle einzelner Hosts geschützt. Ein Nachteil dieses Ansatzes ist jedoch, dass sich die Latenz für den Netzwerkverkehr zwischen VMs möglicherweise erhöht. Weitere Informationen finden Sie unter Übersicht über Placement-Richtlinien.

VM-Kapazitätsplanung

Damit die Kapazität für Compute Engine-VMs verfügbar ist, wenn dies für das MIG-Autoscaling erforderlich ist, können Sie Reservierungen erstellen. Eine Reservierung bietet zugesicherte Kapazität in einer bestimmten Zone für eine bestimmte Anzahl von VMs eines von Ihnen ausgewählten Maschinentyps. Eine Reservierung kann für ein Projekt spezifisch sein oder für mehrere Projekte freigegeben sein. Für reservierte Ressourcen fallen auch dann Gebühren an, wenn die Ressourcen nicht bereitgestellt oder verwendet werden. Weitere Informationen zu Reservierungen, einschließlich Aspekten der Abrechnung, finden Sie unter Reservierungen von zonalen Compute Engine-Ressourcen.

Verfügbarkeit von Blockspeicher

In der Architektur in diesem Dokument wird in jeder Zone ein Hyperdisk Storage Pool verwendet, um Blockspeicher für die Compute Engine-VMs bereitzustellen. Sie erstellen einen Blockspeicherpool für eine Zone. Anschließend erstellen Sie Hyperdisk-Volumes im Speicherpool und hängen die Volumes an VMs in der Zone an. Der Speicherpool versucht, automatisch Kapazität hinzuzufügen, damit die Auslastungsrate 80% der bereitgestellten Kapazität des Pools nicht überschreitet. So wird sichergestellt, dass Blockspeicherplatz bei Bedarf verfügbar ist. Weitere Informationen finden Sie unter Funktionsweise von Hyperdisk Storage Pools.

Speicher mit Status

Eine Best Practice beim Anwendungsdesign besteht darin, die Notwendigkeit von zustandsorientierten lokalen Laufwerken zu vermeiden. Wenn dies jedoch erforderlich ist, können Sie Ihre Laufwerke so konfigurieren, dass sie zustandsorientiert sind, damit die Daten erhalten bleiben, wenn die VMs repariert oder neu erstellt werden. Es empfiehlt sich jedoch, die Bootlaufwerke zustandslos zu lassen, damit Sie sie problemlos auf die neuesten Images mit neuen Versionen und Sicherheitspatches aktualisieren können. Weitere Informationen finden Sie unter Zustandsorientierte nichtflüchtige Speicher in MIGs konfigurieren.

Sicherung und Wiederherstellung

In der Architektur in diesem Dokument werden Datenbanksicherungen in Cloud Storage gespeichert. Wenn Sie den Standorttyp „Dual-Region“ oder „Multi-Region“ für den Cloud Storage-Bucket auswählen, werden die Sicherungen asynchron an mindestens zwei geografischen Standorten repliziert. Wenn ein regionaler Ausfall auftritt, können Sie die Datenbank mithilfe der Sicherungen in einer anderen Region wiederherstellen. Bei einem biregionalen Bucket können Sie die Replikation beschleunigen, indem Sie die Option „Turboreplikation“ aktivieren. Weitere Informationen finden Sie unter Datenverfügbarkeit und Langlebigkeit.

Sie können den Sicherungs- und Notfallwiederherstellungsdienst verwenden, um Sicherungen von Compute Engine-VMs zu erstellen, zu speichern und zu verwalten. Beim Sicherungs- und Notfallwiederherstellungsdienst werden Sicherungsdaten in ihrem ursprünglichen, für Anwendungen lesbaren Format gespeichert. Bei Bedarf können Sie Arbeitslasten in der Produktion wiederherstellen, indem Sie Daten aus dem langfristigen Sicherungsspeicher direkt verwenden, ohne zeitaufwendige Datenverschiebungen oder Vorbereitungsaktivitäten zu erledigen. Weitere Informationen finden Sie in der folgenden Dokumentation:

Weitere Überlegungen zur Zuverlässigkeit

Lesen Sie beim Erstellen der Cloud-Architektur für Ihre Arbeitslast die zuverlässigsten Best Practices und Empfehlungen in der folgenden Dokumentation:

Kostenoptimierung

Dieser Abschnitt enthält Anleitungen zur Optimierung der Kosten für die Einrichtung und den Betrieb einer Google Cloud-Topologie, die Sie mithilfe dieser Referenzarchitektur erstellen.

VM-Maschinentypen

Damit Sie die Auslastung Ihrer VM-Ressourcen optimieren können, bietet Compute Engine Empfehlungen für Maschinentypen. Wählen Sie anhand der Empfehlungen Maschinentypen aus, die den Computing-Anforderungen Ihrer Arbeitslast entsprechen. Bei Arbeitslasten mit vorhersehbaren Ressourcenanforderungen können Sie den Maschinentyp mithilfe von benutzerdefinierten Maschinentypen an Ihre Anforderungen anpassen und Kosten sparen.

VM-Bereitstellungsmodell

Wenn Ihre Anwendung fehlertolerant ist, können Sie mit Spot-VMs die Compute Engine-Kosten für die VMs in der Web- und Anwendungsebene reduzieren. Die Kosten für Spot-VMs sind deutlich niedriger als für normale VMs. Compute Engine kann Spot-VMs jedoch vorzeitig beenden oder löschen, um Kapazitäten zurückzugewinnen.

Spot-VMs sind für Batchjobs geeignet, die ein vorzeitiges Beenden tolerieren können und keine Hochverfügbarkeitsanforderungen haben. Spot-VMs bieten die gleichen Maschinentypen, Optionen und Leistungsoptionen wie reguläre VMs. Wenn die Ressourcenkapazität in einer Zone jedoch begrenzt ist, können MIGs mit Spot-VMs möglicherweise nicht automatisch auf die angegebene Zielgröße horizontal skaliert werden (d. h. VMs erstellen), bis die erforderliche Kapazität wieder verfügbar ist. Verwenden Sie keine Spot-VMs für die VMs, auf denen die Oracle-Datenbankinstanzen gehostet werden.

VM-Ressourcennutzung

Die Autoscaling-Funktion zustandsloser MIGs ermöglicht es Ihrer Anwendung, zunehmenden Traffic auf der Web- und Anwendungsebene reibungslos zu bewältigen. Außerdem können Sie mit Autoscaling die Kosten senken, wenn der Ressourcenbedarf gering ist. Zustandsorientierte MIGs können nicht automatisch skaliert werden.

Lizenzierung von Oracle-Datenbanken

Sie sind für die Beschaffung von Lizenzen für die Oracle-Produkte verantwortlich, die Sie in der Compute Engine bereitstellen. Außerdem sind Sie für die Einhaltung der Nutzungsbedingungen der Oracle-Lizenzen verantwortlich. Berücksichtigen Sie bei der Berechnung der Lizenzkosten für die Oracle-Datenbank die Anzahl der erforderlichen Oracle-Prozessorlizenzen, die sich aus dem Maschinentyp ergeben, den Sie für die Compute Engine-VMs auswählen, auf denen die Oracle-Datenbankinstanzen gehostet werden. Weitere Informationen finden Sie unter Oracle-Software in der Cloud-Computing-Umgebung lizenzieren.

Ressourcennutzung des Blockspeichers

In der Architektur in diesem Dokument wird in jeder Zone ein Hyperdisk Storage Pool verwendet, um Blockspeicher für die Compute Engine-VMs bereitzustellen. Mit erweiterten Kapazitätsspeicherpools, die die schlanke Bereitstellung und Datenreduzierungstechnologien nutzen, um die Speichereffizienz zu verbessern, können Sie die Gesamtauslastung der Blockspeicherkapazität verbessern und die Kosten senken.

Weitere Kostengesichtspunkte

Berücksichtigen Sie beim Erstellen der Architektur für Ihre Arbeitslast auch die allgemeinen Best Practices und Empfehlungen, die unter Google Cloud-Architektur-Framework: Kostenoptimierung bereitgestellt werden.

Operative Effizienz

In diesem Abschnitt werden die Faktoren beschrieben, die Sie bei der Verwendung dieser Referenzarchitektur zum Entwerfen einer Google Cloud-Topologie berücksichtigen sollten, die Sie effizient betreiben können.

Aktualisierungen von VM-Konfigurationen

Wenn Sie die Konfiguration der VMs in einer MIG aktualisieren möchten (z. B. den Maschinentyp oder das Bootlaufwerk-Image), erstellen Sie eine neue Instanzvorlage mit der erforderlichen Konfiguration und wenden Sie die neue Vorlage auf die MIG an. Die MIG aktualisiert die VMs mit der von Ihnen angegebenen Aktualisierungsmethode: automatisch oder selektiv. Wählen Sie je nach Ihren Anforderungen an Verfügbarkeit und betriebliche Effizienz eine geeignete Methode aus. Weitere Informationen zu diesen MIG-Aktualisierungsmethoden finden Sie unter Neue VM-Konfigurationen in einer MIG anwenden.

VM-Images

Für Ihre MIG-Instanzvorlagen empfehlen wir, anstelle der von Google bereitgestellten öffentlichen Images benutzerdefinierte Betriebssystem-Images zu erstellen und zu verwenden, die die Konfigurationen und Software enthalten, die Ihre Anwendungen benötigen. Sie können Ihre benutzerdefinierten Images in einer benutzerdefinierten Image-Familie zusammenfassen. Eine Image-Familie verweist immer auf das neueste Image in dieser Familie. Ihre Instanzvorlagen und ‑scripts können dieses Image daher verwenden, ohne dass Verweise auf eine bestimmte Image-Version aktualisiert werden müssen. Sie müssen Ihre benutzerdefinierten Images regelmäßig aktualisieren, um die Sicherheitsupdates und Patches des Betriebssystemanbieters zu berücksichtigen.

Deterministische Instanzvorlagen

Wenn die Instanzvorlagen, die Sie für Ihre MIGs verwenden, Startskripts enthalten (z. B. zum Installieren von Drittanbietersoftware), achten Sie darauf, dass in den Skripts explizit Softwareinstallationsparameter wie die Softwareversion angegeben werden. Andernfalls ist die auf den VMs installierte Software möglicherweise nicht konsistent, wenn die MIG die VMs erstellt. Wenn Ihre Instanzvorlage beispielsweise ein Startskript zum Installieren von Apache HTTP Server 2.0 (das Paket apache2) enthält, achten Sie darauf, dass das Skript die genaue apache2-Version angibt, die installiert werden soll, z. B. Version 2.4.53. Weitere Informationen finden Sie unter Deterministische Instanzvorlagen.

Blockspeicherverwaltung

In der Architektur in diesem Dokument wird in jeder Zone ein Hyperdisk Storage Pool verwendet, um Blockspeicher für die Compute Engine-VMs bereitzustellen. Hyperdisk Storage Pools vereinfachen die Speicherverwaltung. Anstatt die Kapazität für zahlreiche Laufwerke einzeln zuzuweisen und zu verwalten, definieren Sie einen Kapazitätspool, der für mehrere Arbeitslasten in einer Zone freigegeben werden kann. Anschließend erstellen Sie Hyperdisk-Volumes im Speicherpool und hängen die Volumes an die VMs in der Zone an. Der Speicherpool versucht, automatisch Kapazität hinzuzufügen, damit die Auslastungsrate 80% der bereitgestellten Kapazität des Pools nicht überschreitet.

Verbindung zwischen Anwendungsserver und Datenbank

Für Verbindungen von Ihrer Anwendung zur Oracle-Datenbank empfehlen wir, den zonalen internen DNS-Namen der Datenbank-VM anstelle ihrer IP-Adresse zu verwenden. Google Cloud löst den DNS-Namen automatisch in die primäre interne IP-Adresse der VM auf. Ein weiterer Vorteil dieses Ansatzes besteht darin, dass Sie keine statischen internen IP-Adressen für die Datenbank-VMs reservieren und zuweisen müssen.

Oracle-Datenbankverwaltung und -support

Wenn Sie eine selbstverwaltete Oracle-Datenbankinstanz auf einer Compute Engine-VM ausführen, gelten ähnliche Betriebsanforderungen wie bei der lokalen Ausführung von Oracle-Datenbanken. Mit einer Compute Engine-VM müssen Sie jedoch die zugrunde liegende Rechen-, Netzwerk- und Speicherinfrastruktur nicht mehr verwalten.

Weitere operative Aspekte

Berücksichtigen Sie beim Erstellen der Architektur für Ihre Arbeitslast die allgemeinen Best Practices und Empfehlungen für die betriebliche Effizienz, die unter Google Cloud-Architektur-Framework: Operative Exzellenz beschrieben werden.

Leistungsoptimierung

In diesem Abschnitt werden die Faktoren beschrieben, die Sie berücksichtigen sollten, wenn Sie diese Referenzarchitektur zum Entwerfen einer Topologie in Google Cloud verwenden, die die Leistungsanforderungen Ihrer Arbeitslasten erfüllt.

Rechenleistung

Compute Engine bietet eine breite Palette vordefinierter und anpassbarer Maschinentypen, aus denen Sie abhängig von den Leistungsanforderungen Ihrer Arbeitslasten auswählen können.

  • Wählen Sie für die VMs, die die Web- und Anwendungsebene hosten, einen geeigneten Maschinentyp basierend auf Ihren Leistungsanforderungen für diese Ebenen aus. Eine Liste der verfügbaren Maschinentypen, die Hyperdisk-Volumes unterstützen und Ihre Leistungs- und sonstigen Anforderungen erfüllen, finden Sie in der Tabelle Vergleich von Maschinenserien.
  • Für die VMs, auf denen die Oracle-Datenbankinstanzen gehostet werden, empfehlen wir einen Maschinentyp aus der C4-Maschinenserie der Maschinenfamilie für allgemeine Zwecke. C4-Maschinentypen bieten eine konstant hohe Leistung für Datenbankarbeitslasten.

Netzwerkleistung

Für Arbeitslasten, die eine niedrige Netzwerklatenz zwischen VMs erfordern, können Sie eine Richtlinie für kompakte Platzierung erstellen und auf die MIG-Vorlage anwenden, die für die Anwendungsebene verwendet wird. Wenn die MIG VMs erstellt, werden die VMs auf physischen Servern platziert, die sich nahe beieinander befinden. Mit einer Richtlinie für kompakte Platzierung lässt sich die Netzwerkleistung zwischen VMs verbessern. Mit einer Richtlinie für verteilte Platzierung lässt sich die VM-Verfügbarkeit wie oben beschrieben verbessern. Um ein optimales Gleichgewicht zwischen Netzwerkleistung und Verfügbarkeit zu erreichen, können Sie beim Erstellen einer Richtlinie für kompakte Platzierung angeben, wie weit die VMs voneinander entfernt platziert werden müssen. Weitere Informationen finden Sie unter Übersicht über Placement-Richtlinien.

Die Compute Engine hat ein pro VM festgelegtes Limit für die ausgehende Netzwerkbandbreite. Diese Grenze hängt vom Maschinentyp der VM und davon ab, ob der Traffic über dasselbe VPC-Netzwerk wie die Quell-VM geleitet wird. Bei VMs mit bestimmten Maschinentypen können Sie die Netzwerkleistung verbessern, indem Sie Tier_1-Netzwerke aktivieren. Dadurch wird die maximale Bandbreite für ausgehenden Traffic erhöht. Weitere Informationen finden Sie unter Netzwerkleistung pro VM-Tier_1 konfigurieren.

Hyperdisk-Speicherleistung

Die in diesem Dokument beschriebene Architektur verwendet Hyperdisk-Volumes für die VMs in allen Ebenen. Mit Hyperdisk können Sie Leistung und Kapazität dynamisch skalieren. Sie können die bereitgestellten IOPS, den Durchsatz und die Größe jedes Volumes an die Speicherleistung und Kapazitätsanforderungen Ihrer Arbeitslast anpassen. Die Leistung von Hyperdisk-Volumes hängt vom Hyperdisk-Typ und vom Maschinentyp der VMs ab, an die die Volumes angehängt sind. Weitere Informationen zu den Leistungsgrenzen und zur Optimierung von Hyperdisk finden Sie in der folgenden Dokumentation:

Weitere Hinweise zur Leistung

Berücksichtigen Sie beim Erstellen der Architektur für Ihre Arbeitslast die allgemeinen Best Practices und Empfehlungen, die unter Google Cloud-Architektur-Framework: Leistungsoptimierung bereitgestellt werden.

Nächste Schritte

Beitragende

Autor: Kumar Dhanagopal | Cross-product Solution Developer

Weitere Beitragende: