Unternehmensanwendung mit Oracle Database 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. Mit dieser Referenzarchitektur können Sie lokale Anwendungen, die Oracle-Datenbanken verwenden, effizient per Hostwechsel (Lift-and-Shift) in Google Cloudmigrieren. Dieses Dokument enthält auch eine Anleitung zum Erstellen einer Oracle Database-Topologie inGoogle 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 Compute Engine und Oracle Database vertraut sind.

Wenn Sie Oracle Exadata oder Oracle Real Application Clusters (Oracle RAC) zum Ausführen von Oracle-Datenbanken lokal verwenden, können Sie Ihre Anwendungen effizient zu Oracle Database@Google Cloud migrieren und Ihre Datenbanken dort ausführen. Google Cloud 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 Webstufe, die Anwendungsstufe und die Oracle Database-Instanzen werden auf Compute Engine-VMs gehostet. Die Web- und die 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 ist1.

Eine mehrstufige 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 Anwendungs-Stack 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 Webstufe 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 verwaltete Instanzgruppe enthält Compute Engine-VMs in zwei Zonen. Jede dieser VMs hostet eine unabhängige Instanz der Webstufe der Anwendung.
Regionaler interner Application Load Balancer Der regionale interne Application Load Balancer verteilt den Traffic von den Webstufen-VMs auf die VMs der Anwendungsstufe.
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 verwalteten Instanzgruppe sind. Diese verwaltete Instanzgruppe ist das Backend für den internen Application Load Balancer. Die verwaltete Instanzgruppe 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är/Standby-Paar von Oracle Database-Instanzen, die auf Compute Engine-VMs in separaten Zonen bereitgestellt werden. Sie stellen für diese Oracle Database-Instanzen Ihre eigenen Lizenzen bereit (Bring Your Own License, BYOL) und verwalten die VMs und Datenbankinstanzen.
Hyperdisk-Speicherpools Die VMs in jeder Zone (über alle Stufen 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-Observer Der Oracle Data Guard-FSFO-Observer (Fast-Start Failover) ist ein schlankes Programm, das ein automatisches Failover zur Oracle Database-Standby-Instanz initiiert, wenn die primäre Instanz nicht verfügbar ist. Der Observer 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 Database-Instanzen 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 Cloudzu verbinden. Informationen zu den relativen Vorteilen der einzelnen Ansätze finden Sie unter Produkt für Network Connectivity 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 Logs von den Compute Engine-VMs, einschließlich der VMs, auf denen die Oracle Database-Instanzen 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 Cloudzugegriffen 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 VPCs.
  • 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 Cloudverwaltete, 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, Pflegen, 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 Cloudbereitstellen, 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 - und Drittanbieter-Produkten 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.

Computing-Infrastruktur

In der Referenzarchitektur in diesem Dokument werden Compute Engine-VMs zum Hosten aller Stufen 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 (GKE)-Clustern ausführen. GKE ist eine Engine zur Containerorchestrierung, die die Bereitstellung, Skalierung und Verwaltung von Containeranwendungen automatisiert.
  • Serverlos: Wenn Sie sich bei Ihren IT-Maßnahmen 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 erfordert. 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 Stufen. 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 Webstufe. Die Daten, die Sie in einer Filestore-Regionalinstanz 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 erhalten Sie in dieser 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

Zum Schutz Ihrer Anwendung vor externen Bedrohungen wie DDoS-Angriffen und XSS können Sie geeignete Google Cloud Armor-Sicherheitsrichtlinien basierend auf Ihren Anforderungen definieren. 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 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 Webstufe, die Anwendungsstufe und die Oracle Database-Instanzen gehostet werden, keinen direkten eingehenden Zugriff aus dem Internet. Weisen Sie diesen VMs keine externen IP-Adressen zu. Google Cloud Ressourcen, die nur eine private, interne IP-Adresse 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.

Sie können Secure Web Proxy oder Cloud NAT verwenden, 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.

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 Stufe des Anwendungs-Stacks 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 in Hyperdisk-Volumes gespeicherte Daten mitGoogle-owned and Google-managed encryption keysverschlüsselt. Als zusätzliche Schutzebene können Sie die Google-eigenen Datenverschlüsselungsschlüssel 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 Laufwerksverschlü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 inGoogle Cloudberü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 Stufen weiterhin Anfragen verarbeiten.

  • Wenn eine VM in der Web- oder Anwendungsstufe abstürzt, erstellt die entsprechende verwaltete Instanzgruppe 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 Database-Instanz gehostet wird, ausfällt, initiiert der Oracle Data Guard FSFO-Observer einen automatischen Failover zur Standby-Oracle Database-Instanz.

Automatische Reparatur von VMs

Manchmal werden die VMs, auf denen Ihre Web- und Anwendungsstufe 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 Balancer 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 Web- und die Anwendungsstufe sind verfügbar (und reagieren), 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 Balancers leiten Anfragen an die verfügbaren Webserver-VMs und Anwendungsserver-VMs weiter.
  • Wenn ein Ausfall die Zone mit der primären Oracle Database-Instanz betrifft, initiiert der Oracle Data Guard FSFO-Observer einen automatischen Failover auf die Oracle Database-Standby-Instanz. Der FSFO-Observer 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 der 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:

  • Pflegen Sie ein passives (Failover-)Replikat des Infrastruktur-Stacks in einer anderen Google Cloud Region.
  • Verwenden Sie einen biregionalen oder multiregionalen Cloud Storage-Bucket, um die Oracle Database-Sicherungen zu speichern. Die Sicherungen werden asynchron an mindestens zwei geografischen Standorten repliziert. Mit replizierten Datenbanksicherungen entspricht Ihre Architektur der Silber-Stufe der Maximum Availability Architecture (MAA) von Oracle.

    Wenn Sie eine schnellere Replikation für Sicherungen erzielen möchten, die in biregionalen Buckets 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 Datenbankstufe können Sie Oracle Active Data Guard FSFO verwenden, um automatisch ein Failover zu einer Oracle Database-Standby-Instanz 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 einzelner Zonen resistent ist. Zur weiteren Verbesserung dieser Robustheit können Sie eine Richtlinie für verteilte Platzierungen erstellen und auf die MIG-Vorlage anwenden. Wenn Sie eine Richtlinie für verteilte Platzierung 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 Platzierungsrichtlinien – Übersicht.

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 werden. 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-Speicherpool verwendet, um Blockspeicher für die Compute Engine-VMs bereitzustellen. Sie erstellen einen Pool mit Blockspeicherkapazität 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-Speicherpools.

Zustandsorientierter Speicher

Eine Best Practice beim Anwendungsdesign besteht darin, die Notwendigkeit von zustandsorientierten lokalen Laufwerken zu vermeiden. Wenn dies jedoch erforderlich ist, können Sie Ihre Speicher 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 biregionalen oder multiregionalen Standorttyp 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 Backup- und DR-Dienst verwenden, um Sicherungen der Compute Engine-VMs zu erstellen, zu speichern und zu verwalten. Beim Backup- und DR-Dienst werden Sicherungsdaten in ihrem ursprünglichen, für Anwendungen lesbaren Format gespeichert. Bei Bedarf können Sie Ihre Arbeitslasten in der Produktion wiederherstellen, indem Sie Daten aus dem langfristigen Sicherungsspeicher direkt verwenden, ohne zeitaufwendige Datenverschiebungen oder Vorbereitungsaktivitäten zu erledigen. Weitere Informationen erhalten Sie in dieser 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 Anwendungsstufe 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 horizontal auf die angegebene Zielgröße skaliert werden (d. h. VMs werden erstellt), bis die erforderliche Kapazität wieder verfügbar ist. Verwenden Sie keine Spot-VMs für die VMs, die die Oracle Database-Instanzen hosten.

VM-Ressourcennutzung

Die Autoscaling-Funktion zustandsloser MIGs ermöglicht es Ihrer Anwendung, zunehmenden Traffic auf der Web- und Anwendungsstufe 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 Database

Sie sind selbst dafür verantwortlich, die Lizenzen für die Oracle-Produkte zu erwerben, die Sie in der Compute Engine bereitstellen, und sind für die Einhaltung der Nutzungsbedingungen der Oracle-Lizenzen verantwortlich. Berücksichtigen Sie bei der Berechnung der Lizenzkosten für Oracle Database 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 Database-Instanzen 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-Speicherpool verwendet, um Blockspeicher für die Compute Engine-VMs bereitzustellen. Mit erweiterten Kapazitätsspeicherpools, die Thin Provisioning und Technologien zur Datenreduzierung nutzen, um die Speichereffizienz zu verbessern, können Sie die Gesamtauslastung der Blockspeicherkapazität verbessern und 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.

Betriebliche 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

Erstellen Sie eine neue Instanzvorlage mit der erforderlichen Konfiguration und wenden Sie die neue Vorlage auf die MIG an, um die Konfiguration der VMs in einer MIG zu aktualisieren (z. B. Maschinentyp oder Bootlaufwerk-Image). 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. Die Image-Familie verweist immer auf das neueste Image in dieser Familie. Ihre Instanzvorlagen und -skripte 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 (z. B. für die Installation von Drittanbietersoftware) enthalten, 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-Speicherpool verwendet, um Blockspeicher für die Compute Engine-VMs bereitzustellen. Hyperdisk-Speicherpools 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 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 zu Oracle Database 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 Database-Instanz auf einer Compute Engine-VM ausführen, gelten ähnliche operative Anforderungen wie bei der lokalen Ausführung von Oracle Database. 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 Anwendungsstufe hosten, einen geeigneten Maschinentyp basierend auf Ihren Leistungsanforderungen für diese Stufen 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 Maschinenserienvergleich.
  • Für die VMs, auf denen die Oracle Database-Instanzen gehostet werden, empfehlen wir einen Maschinentyp aus der C4-Maschinenreihe 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 Anwendungsstufe 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 hingegen die VM-Verfügbarkeit verbessern, wie bereits beschrieben. 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 Platzierungsrichtlinien – Übersicht.

Die Compute Engine hat ein pro VM festgelegtes Limit für die Netzwerkbandbreite für ausgehenden Traffic. Dieses Limit 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 Stufen. Mit Hyperdisk können Sie Leistung und Kapazität dynamisch skalieren. Sie können die bereitgestellten IOPS, den Durchsatz und die Größe jedes Volume 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:


  1. Weitere Informationen zu regionsspezifischen Aspekten finden Sie unter Geografie und Regionen.