Unternehmensanwendung auf Compute Engine-VMs mit Oracle Exadata in Google Cloud

Last reviewed 2024-09-30 UTC

In diesem Dokument wird eine Referenzarchitektur für eine hochverfügbare Unternehmensanwendung bereitgestellt, die auf Compute Engine-VMs (virtuellen Maschinen) mit niedriger Latenz-Konnektivität zu Oracle Cloud Infrastructure (OCI) Exadata-Datenbanken gehostet wird, die in Google Cloud ausgeführt werden. Die Zielgruppe für dieses Dokument sind Cloud-Architekten und Oracle-Datenbankadministratoren. In diesem Dokument wird davon ausgegangen, dass Sie mit der Compute Engine und dem Oracle Exadata Database Service 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. Oracle Database@Google Cloud ist ein Google Cloud Marketplace-Angebot, mit dem Sie Oracle Exadata Database Service und Oracle Autonomous Database direkt in Google Cloud ausführen können.

Wenn Sie die Oracle RAC-Funktion nicht benötigen oder eine andere Oracle-Datenbankversion als 19c und 23ai benötigen, können Sie selbstverwaltete Oracle-Datenbanken auf Compute Engine-VMs ausführen. Weitere Informationen finden Sie unter Enterprise-Anwendung mit Oracle-Datenbank in der Compute Engine.

Architektur

Das folgende Diagramm zeigt einen groben Überblick der Architektur:

Allgemeine Ansicht einer Architektur mit Oracle Database@Google Cloud

Im vorherigen Diagramm empfängt ein externer Load Balancer Anfragen von Nutzern einer öffentlich zugänglichen Anwendung und verteilt sie an Frontend-Webserver. Die Webserver leiten die Nutzeranfragen über einen internen Load Balancer an Anwendungsserver weiter. Die Anwendungsserver lesen Daten aus und schreiben sie in Datenbanken in Oracle Database@Google Cloud. Administratoren und OCI-Dienste können eine Verbindung zu den Oracle-Datenbanken herstellen und mit ihnen interagieren.

Im folgenden Diagramm sehen Sie eine detaillierte Ansicht der Architektur:

Detailansicht einer Architektur mit Oracle Database@Google Cloud

In dieser Architektur werden die Webebene und die Anwendungsebene im Aktiv/Aktiv-Modus auf Compute Engine-VMs ausgeführt, die über zwei Zonen innerhalb einer Google Cloud-Region verteilt sind. Die Anwendung verwendet Oracle Exadata-Datenbanken in derselben Google Cloud-Region.

Alle Komponenten in der Architektur befinden sich in einer einzigen Google Cloud-Region. Diese Architektur ist am Archetyp für regionale Bereitstellungen ausgerichtet. Sie können diese Architektur anpassen, um eine Topologie zu erstellen, die gegen regionale Ausfälle resistent ist. Verwenden Sie dazu den Archetyp für multiregionale Bereitstellungen. Weitere Informationen finden Sie unter Multiregionale Bereitstellung in Compute Engine und im Abschnitt Zuverlässigkeit weiter unten in diesem Dokument.

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 Nutzeranfragen und verteilt sie an die VMs der Webebene.
Google Cloud Armor-Sicherheitsrichtlinie Die Google Cloud Armor-Sicherheitsrichtlinie hilft, Ihren Anwendungsstack vor Bedrohungen wie DDoS-Angriffen (Distributed Denial of Service) und Cross-Site-Scripting (XSS) zu 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.
VPC-Netzwerk (Virtual Private Cloud) und Subnetz Alle Google Cloud-Ressourcen in der Architektur verwenden ein einzelnes VPC-Netzwerk. Je nach Ihren Anforderungen können Sie eine Architektur erstellen, die mehrere Netzwerke verwendet. Weitere Informationen finden Sie unter Entscheiden, ob mehrere VPC-Netzwerke erstellt werden sollen.
Oracle Database@Google Cloud

Die Anwendungsserver lesen Daten aus und schreiben sie in Oracle-Datenbanken im Oracle Exadata Database Service. Sie stellen den Oracle Exadata Database Service mit Oracle Database@Google Cloud bereit, einem Cloud Marketplace-Angebot, mit dem Sie Oracle-Datenbanken auf von Oracle verwalteter Hardware in einem Google Cloud-Rechenzentrum ausführen können.

Sie verwenden Google Cloud-Oberflächen wie die Google Cloud Console, die Google Cloud CLI und APIs, um Exadata-Infrastrukturinstanzen zu erstellen. Oracle richtet die erforderliche Rechen-, Speicher- und Netzwerkinfrastruktur in einem Rechenzentrum innerhalb einer Google Cloud-Region auf Hardware ein, die speziell für Ihr Projekt vorgesehen ist.

Exadata-Infrastrukturinstanzen Jede Exadata Infrastructure-Instanz enthält mindestens zwei physische Datenbankserver und mindestens drei Speicherserver. Diese Server, die im Diagramm nicht dargestellt sind, sind über ein Netzwerk-Fabric mit niedriger Latenz miteinander verbunden. Wenn Sie eine Exadata-Infrastrukturinstanz erstellen, geben Sie die Anzahl der Datenbank- und Speicherserver an, die bereitgestellt werden müssen.
Exadata-VM-Cluster

Innerhalb einer Exadata-Infrastrukturinstanz erstellen Sie einen oder mehrere Exadata-VM-Cluster. Sie können beispielsweise einen separaten Exadata-VM-Cluster erstellen und verwenden, um die Datenbanken zu hosten, die für jede Ihrer Geschäftsbereiche erforderlich sind. Jeder Exadata-VM-Cluster enthält eine oder mehrere Oracle Linux-VMs, auf denen Oracle-Datenbankinstanzen gehostet werden.

Wenn Sie einen Exadata-VM-Cluster erstellen, geben Sie Folgendes an:

  • Die Anzahl der Datenbankserver.
  • Die Rechenleistung, der Arbeitsspeicher und die Speicherkapazität, die jeder VM im Cluster zugewiesen werden soll.
  • Das VPC-Netzwerk, mit dem der Cluster verbunden werden muss.
  • IP-Adressbereiche der Sicherungs- und Client-Subnetze für den Cluster.

Die VMs in Exadata-VM-Clustern sind keine Compute Engine-VMs.

Oracle Database-Instanzen Oracle-Datenbanken werden über die OCI-Konsole und andere OCI-Schnittstellen erstellt und verwaltet. Die Oracle-Datenbanksoftware wird auf den VMs innerhalb des Exadata-VM-Clusters ausgeführt. Beim Erstellen des Exadata-VM-Clusters geben Sie die Oracle Grid Infrastructure-Version an. Sie wählen auch den Lizenztyp aus: Sie können entweder eigene Lizenzen verwenden (Bring your own License, BYOL) oder das Modell mit inbegriffener Lizenz auswählen.
OCI VCN und Subnetze Wenn Sie einen Exadata-VM-Cluster erstellen, wird automatisch ein OCI-virtuelles Cloud-Netzwerk (VCN) erstellt. Das VCN hat ein Clientsubnetz und ein Sicherungssubnetz mit von Ihnen angegebenen IP-Adressbereichen. Das Client-Subnetz wird für die Verbindung von Ihrem VPC-Netzwerk zu den Oracle-Datenbanken verwendet. Über das Sicherungssubnetz werden Datenbanksicherungen an den OCI Object Storage gesendet.
Cloud Router, Partner Interconnect und OCI-DRG Der Traffic zwischen Ihrem VPC-Netzwerk und dem VCN wird von einem Cloud Router weitergeleitet, der mit dem VPC verbunden ist, und über ein dynamisches Routing-Gateway (DRG), das mit dem VCN verbunden ist. Der Traffic fließt über eine Verbindung mit niedriger Latenz, die Google mit Partner Interconnect einrichtet.
Private Cloud DNS-Zone Wenn Sie einen Exadata-VM-Cluster erstellen, wird automatisch eine private Cloud DNS-Zone erstellt. Wenn Ihre Anwendungsserver Lese- und Schreibanfragen an die Oracle-Datenbanken senden, löst Cloud DNS die Datenbank-Hostnamen in die entsprechenden IP-Adressen auf.
OCI Object Storage und OCI Service Gateway Standardmäßig werden Sicherungen der Oracle Exadata-Datenbanken im OCI Object Storage gespeichert. Datenbanksicherungen werden über ein Dienst-Gateway an OCI Object Storage weitergeleitet.
Ö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 Mit Cloud Monitoring können Sie das Verhalten, den Zustand und die Leistung Ihrer Anwendung und Ihrer Google Cloud-Ressourcen, einschließlich der Oracle Exadata-Ressourcen, beobachten. Sie können die Ressourcen in Oracle Exadata-Ressourcen auch mit dem OCI Monitoring-Dienst überwachen.

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.
  • Cloud Load Balancing: Ein Portfolio von leistungsstarken, skalierbaren, globalen und regionalen Load-Balancern
  • 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 Interconnect: Ein Dienst, mit dem Ihr externes Netzwerk über eine hochverfügbare Verbindung mit niedriger Latenz auf das Google-Netzwerk erweitert wird.
  • Partner Interconnect: Ein Dienst, der über einen unterstützten Dienstanbieter eine Verbindung zwischen Ihrem lokalen Netzwerk und Ihren Virtual Private Cloud-Netzwerken und anderen Netzwerken herstellt.
  • 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 OCI-Produkte verwendet:

  • Exadata Database Service auf dedizierter Infrastruktur: Mit diesem Dienst können Sie Oracle-Datenbankinstanzen auf dedizierter Exadata-Hardware ausführen.
  • Objektspeicher: Ein Dienst zum Speichern großer Mengen strukturierter und unstrukturierter Daten als Objekte.
  • VCN und Subnetze: Ein VCN ist ein virtuelles und privates Netzwerk für Ressourcen in einer OCI-Region. Ein Subnetz ist ein zusammenhängender Bereich von IP-Adressen mit einem VCN.
  • Dynamic Routing Gateway: Ein virtueller Router für Traffic zwischen einem VCN und externen Netzwerken.
  • Service-Gateway: Ein Gateway, mit dem Ressourcen in einer VCN privat auf bestimmte Oracle-Dienste zugreifen können.

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 der Web- und Anwendungsebene 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 und Cloud Run-Funktionen 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 den Dienstoptionen finden Sie unter Anwendungen in Google Cloud hosten.

Speicheroptionen

Um nichtflüchtigen Speicher für die Compute Engine-VMs in der Web- und Anwendungsebene bereitzustellen, wählen Sie einen geeigneten Persistent Disk- oder Google Cloud Hyperdisk-Typ aus, der den Anforderungen Ihrer Anwendung an Kapazität, Skalierung, Verfügbarkeit und Leistung entspricht. Weitere Informationen dazu finden Sie unter Speicheroptionen.

Wenn Sie kostengünstigen Speicher benötigen, der in den Zonen einer Region redundant ist, verwenden Sie regionale Cloud Storage-Buckets.

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 Filestore Regional-Instanz speichern, werden synchron über drei Zonen innerhalb der Region repliziert. Diese Replikation trägt dazu bei, für die in Filestore gespeicherten Daten eine hohe Verfügbarkeit und Robustheit bei zonalen Ausfällen zu gewährleisten. 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. Die in diesem Dokument dargestellte Architektur verwendet eine einfache Netzwerktopologie mit einem einzelnen VPC-Netzwerk. Je nach Ihren Anforderungen können Sie mehrere Netzwerke verwenden. Weitere Informationen erhalten Sie in dieser Dokumentation:

Beachten Sie die Mindestanforderungen an die Subnetzgröße, wenn Sie IP-Adressbereiche für die Client- und Sicherungssubnetze zuweisen, die für die Exadata-VM-Cluster verwendet werden sollen. Weitere Informationen finden Sie unter IP‑Adressbereich in Oracle Database@Google Cloud planen.

Datenbankmigration

Wenn Sie lokale Datenbanken zu Oracle Database@Google Cloud migrieren möchten, können Sie mit dem Tool Database Migration Assessment (DMA) Ihre aktuelle Datenbankumgebung bewerten und Empfehlungen zur Konfiguration und Größe erhalten.

Sie können Standard-Oracle-Tools wie Oracle GoldenGate verwenden, um lokale Daten zu Oracle-Datenbanken in Google Cloud zu migrieren.

Bevor Sie die migrierten Datenbanken in einer Produktionsumgebung verwenden, prüfen Sie die Verbindung Ihrer Anwendungen zu den Datenbanken.

Sicherheit

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 eingehenden Traffics mit einer bestimmten IP-Adresse oder einem CIDR-Bereich übereinstimmt. Sie können auch vorkonfigurierte WAF-Regeln 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 und die Anwendungsebene 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 Private Zugriffsoptionen für Dienste.

Sie können Cloud NAT wie im vorherigen Architekturdiagramm dargestellt oder einen sicheren Web-Proxy 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.

Oracle empfiehlt, den von den Exadata-VMs verwendeten Subnetzen private IP-Adressbereiche zuzuweisen.

VM-Image-Sicherheit

Genehmigte Images sind Images mit Software, die Ihren Richtlinien- oder Sicherheitsanforderungen entspricht. Wenn Sie möchten, dass Ihre VMs in der Web- und Anwendungsebene 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 Compute Engine-VMs angehängt, die Sie mithilfe der gcloud 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.

Netzwerksicherheit

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

Datenbanksicherheit und Compliance

Der Exadata Database Service umfasst Oracle Data Safe, mit dem Sie Sicherheits- und Compliance-Anforderungen für Oracle-Datenbanken verwalten können. Mit Oracle Data Safe können Sie Sicherheitsmaßnahmen prüfen, Nutzeraktivitäten überwachen und sensible Daten maskieren. Weitere Informationen finden Sie unter Datenbanksicherheit mit Oracle Data Safe verwalten.

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 wird die VM in der Web- oder Anwendungsebene automatisch von der entsprechenden MIG neu erstellt, wenn sie abstürzt. Die Load Balancer leiten Anfragen nur an die derzeit verfügbaren Webserver- und Anwendungsserverinstanzen weiter.

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 regionalen Ausfällen

Bei einem regionalen Ausfall ist die Anwendung nicht verfügbar. So können Sie die Ausfallzeit durch regionale Ausfälle reduzieren:

  • Ein passives (Failover-)Replikat der Web- und Anwendungsebene in einer anderen Google Cloud-Region verwalten.
  • Erstellen Sie eine Exadata-Standby-Infrastrukturinstanz mit den erforderlichen Exadata-VM-Clustern in derselben Region, in der sich das passive Replikat des Anwendungsstacks befindet. Verwenden Sie Oracle Data Guard für die Datenreplikation und das automatische Failover zu den Standby-Exadata-Datenbanken. Wenn für Ihre Anwendung ein niedrigeres Recovery Point Objective (RPO) erforderlich ist, können Sie die Datenbanken mit dem Oracle Autonomous Recovery Service sichern und wiederherstellen.
  • Wenn ein Ausfall in der primären Region auftritt, verwenden Sie das Datenbankreplikat oder die Sicherung, um die Datenbank in der Produktion wiederherzustellen und die Anwendung in der Failover-Region zu aktivieren.
  • Verwenden Sie DNS-Routingrichtlinien, um Traffic an einen externen 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. Sie können Oracle Active Data Guard verwenden, um eine schreibgeschützte Standby-Datenbank in der Failover-Region bereitzustellen.

Oracle verwaltet die Infrastruktur in Oracle Database@Google Cloud. Informationen zu den Service Level Objectives (SLOs) für den Oracle Exadata Database Service auf einer dedizierten Infrastruktur finden Sie unter Service Level Objectives für Oracle PaaS- und IaaS-Public-Cloud-Dienste.

MIG-Autoscaling

In der Architektur in diesem Dokument werden regionale MIGs für die Web- und Anwendungsebene verwendet. Die Autoscaling-Funktion zustandsloser MIGs sorgt dafür, dass die Compute Engine-VMs, auf denen die Web- und Anwendungsebene gehostet werden, nicht von Ausfällen in einer einzelnen Zone betroffen sind. 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 trägt dazu bei, dass Ihre Webebene und Ihre Anwendungsebene gegen Ausfälle einzelner Zonen resistent sind. Zur weiteren Verbesserung dieser Robustheit können Sie eine Richtlinie für gestreute Platzierungen erstellen und auf die MIG-Vorlage anwenden. Wenn die MIG VMs mit einer Richtlinie für gestreute Platzierungen erstellt, werden die VMs 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.

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.

Datenbankkapazität

Sie können die Exadata-Infrastruktur skalieren, indem Sie nach Bedarf Datenbank- und Speicherserver hinzufügen. Nachdem Sie der Exadata-Infrastruktur die erforderlichen Datenbank- oder Speicherserver hinzugefügt haben, müssen Sie dem zugehörigen Exadata-VM-Cluster die Kapazität hinzufügen, um die zusätzlichen CPU- oder Speicherressourcen nutzen zu können. Weitere Informationen finden Sie unter Exadata-Rechen- und Speicherressourcen skalieren.

Sicherung und Wiederherstellung

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 unter Backup- und Notfallwiederherstellungsdienst für Compute Engine-Instanzsicherungen.

Standardmäßig werden Sicherungen von Datenbanken im Oracle Exadata Database Service auf einer dedizierten Infrastruktur in OCI Object Storage gespeichert. Um eine niedrigere RPO zu erreichen, können Sie die Datenbanken mit dem Oracle Autonomous Recovery Service sichern und wiederherstellen.

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 VMs optimieren können, bietet Compute Engine Empfehlungen für Maschinentypen. Wählen Sie anhand der Empfehlungen Maschinentypen aus, die den Computing-Anforderungen Ihrer VMs in der Web- und Anwendungsebene 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 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.

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.

Datenbankkosten

Wenn Sie einen Exadata-VM-Cluster erstellen, können Sie BYOL auswählen oder lizenzierte Oracle-Datenbanken bereitstellen.

Netzwerkgebühren für die Datenübertragung zwischen Ihren Anwendungen und Oracle Exadata-Datenbanken in derselben Region sind im Preis des Oracle Database@Google Cloud-Angebots enthalten.

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 Sicherheitsupdates und Patches des Betriebssystemanbieters zu enthalten.

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.

Datenbankverwaltung

Oracle verwaltet die physischen Datenbankserver, Speicherserver und Netzwerkhardware im Oracle Exadata Database Service auf einer dedizierten Infrastruktur. Sie können die Exadata Infrastructure-Instanzen und die Exadata-VM-Cluster über die OCI- oder Google Cloud-Benutzeroberflächen verwalten. Sie erstellen und verwalten Datenbanken über die OCI-Schnittstellen. Die Seiten der Google Cloud Console für Oracle Database@Google Cloud enthalten Links, über die Sie direkt zu den entsprechenden Seiten in der OCI-Konsole gelangen. Damit Sie sich nicht noch einmal in OCI anmelden müssen, können Sie eine Identitätsföderation zwischen OCI und Google Cloud konfigurieren.

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, auf denen die Web- und Anwendungsebene gehostet werden, einen geeigneten Maschinentyp basierend auf Ihren Leistungsanforderungen für diese Ebenen aus. Weitere Informationen finden Sie im Vergleich der Maschinenserien.

Netzwerkleistung

Für Arbeitslasten, die eine niedrige Netzwerklatenz zwischen VMs innerhalb der Anwendungs- und Webebene erfordern, können Sie eine Richtlinie für kompakte Platzierung erstellen und auf die MIG-Vorlage anwenden, die für diese Ebenen 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 Platzierungen 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.

Der Netzwerkverkehr zwischen den VMs der Anwendungsebene und dem Oracle Exadata-Netzwerk wird über eine Partner Interconnect-Verbindung mit niedriger Latenz geleitet, die von Google eingerichtet wird.

Die Exadata-Infrastruktur verwendet RDMA over Converged Ethernet (RoCE) für eine hohe Bandbreite und niedrige Latenz zwischen den Datenbank- und Speicherservern. Die Server tauschen Daten direkt im Arbeitsspeicher aus, ohne dass der Prozessor, der Cache oder das Betriebssystem beteiligt sind.

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: