Oracle Cloud Infrastructure-Dokumentation

Vollständiger Stack - DR-Abrechnungsdetails

Erfahren Sie, wie der Full Stack DR-Service die Abrechnung für jeden Mitgliedstyp berechnet, der einer DR-Schutzgruppe hinzugefügt wird, einschließlich einiger Beispielberechnungen.

Berechnung der Abrechnung für eine DR-Konfiguration (für ein Paar zugehöriger DR-Schutzgruppen)

  1. Full Stack DR verwendet nur zugewiesene CPU (OCPU oder ECPU) als Grundlage für die Berechnung von Gebühren. Speicher-, Netzwerk- und andere Ressourcenverwendungen werden nicht von Full Stack DR abgerechnet.
  2. Der fakturierte Gesamtbetrag ist die Summe der CPU-basierten Abrechnungskosten für alle einzelnen Elemente, die den beiden DR-Schutzgruppen in einem zugehörigen Paar hinzugefügt wurden.
  3. Die CPU-Auslastung für die relevanten Mitglieder einer DR-Schutzgruppe wird mit den in der folgenden Tabelle beschriebenen Methoden berechnet.
  4. Nachdem Sie die folgenden Details und die angegebene Beispielberechnung durchlaufen haben, lesen Sie diese Website, um den Kostenschätzungsrechner zu laden. Schätzen Sie damit die Gebühren für Ihre DR-Konfiguration ab.

Mitgliedsressourcen, für die Gebühren anfallen

Full Stack DR verwendet nur zugewiesene CPU (OCPU oder ECPU) als Grundlage für die Berechnung von Gebühren. Gebühren für Full Stack DR fallen für alle Compute- oder Datenbankmitglieder einer DR-Schutzgruppe an, unabhängig davon, ob die Ressource ausgeführt oder gestoppt wird. Beispiel: Eine nicht zu verschiebende Compute-Instanz, die in der Standbyregion vorhanden ist, befindet sich jedoch immer im Status "Gestoppt", bis ein DR-Vorgang weiterhin stündliche Gebühren für Full Stack DR ansammelt, obwohl sie nicht ausgeführt wird.

OCI-Ressourcen, für die Gebühren anfallen

Full Stack DR-Gebühren fallen für die folgenden OCI-Ressourcentypen IaaS und PaaS an:
  • Autonomous Database
    • Oracle Autonomous Database Serverless (Data Warehousing)
    • Oracle Autonomous Database Serverless (Transaktionsverarbeitung)
  • Autonome Containerdatenbank
    • Autonomous Database auf dedizierter Exadata-Infrastruktur
  • Datenbank
    • Basisdatenbank
    • Exadata Database on Dedicated Infrastructure
    • Exadata Database auf Cloud@Customer
    • Exadata Database auf Exascale-Infrastruktur
  • Compute-Instanz (mit Verschieben)
  • Compute-Instanz (ohne Verschieben
  • Oracle-Kubernetes-Engine (OKE)
Für die folgenden OCI-Ressourcentypen IaaS und PaaS fallen keine Full Stack-DR-Gebühren an:
  • Blockspeicher (einschließlich Boot-Volumes)
  • Dateispeicher
  • Objektspeicher
  • Load Balancer
  • Network Load Balancer
Für Folgendes fallen keine Full Stack DR-Gebühren an:
  • Oracle-Anwendungen
  • Nicht-Oracle-Anwendungen

Prozessorverbrauch bestimmen

Die folgende Tabelle zeigt, wie der OCPU- und ECPU-Verbrauch für verschiedene OCI-Member-Ressourcentypen bestimmt wird, die als stündliche Gebühren für Full Stack DR anfallen. Die Bestimmung des Prozessorverbrauchs für die meisten OCI-Ressourcentypen erfolgt direkt und basiert auf den Angaben auf der Detailseite in der OCI-Konsole für jede einzelne Ressource. Einige Ressourcen wie Oracle Exadata zeigen jedoch keine Prozessorauslastung für einzelne Datenbanken an, die von der aggregierten Gesamt-CPU-Auslastung durch das VM-Cluster abgeleitet werden.

Tabelle A-9: Ermittlung des Prozessorverbrauchs

Mitgliedstyp CPU-Typ Basis für Berechnung
Compute-Instanz (mit Verschieben) OCPU Die OCPU-Anzahl, die der Compute-Instanz zugewiesen ist. Informationen zur Compute-Instanz finden Sie auf der Seite "OCI-Dokumentation" im Abschnitt Ausprägungskonfiguration.
Compute-Instanz (ohne Verschieben OCPU Die OCPU-Anzahl, die der Compute-Instanz zugewiesen ist. Informationen zur Compute-Instanz finden Sie auf der Seite "OCI-Dokumentation" im Abschnitt Ausprägungskonfiguration.
Datenbank: Oracle Base Database OCPU Die Anzahl CPU-Cores, die dem mit der Basisdatenbank verknüpften Datenbanksystem (DB-System) zugewiesen ist. Weitere Informationen finden Sie im Abschnitt Allgemeine Informationen auf der Seite "OCI-Dokumentation" für die Basisdatenbank.
Datenbank:
  • Oracle Exadata Database on Dedicated Infrastructure
  • Oracle Exadata Database on Cloud@Customer
  • Oracle Exadata Database auf Exascale-Infrastruktur
 ECPU oder OCPU (Legacy)

Die gesamte ECPU- oder OCPU-Anzahl für das VM-Cluster (tc), das diese Datenbank hostet, dividiert durch die Gesamtanzahl der in diesem VM-Cluster bereitgestellten Datenbanken (ti) entspricht der CPU pro Datenbankinstanz (bis). Diese abgeleitete durchschnittliche CPU-Anzahl ist eine Näherung.

Formel: (tc/ti) =to

Beispiel:
  • tc = Gesamte ECPU oder OCPU, die dem Exadata-VM-Cluster zugewiesen sind: 64
  • ti = Gesamtzahl der Datenbankinstanzen im Cluster: 4
  • bis = ECPU oder OCPU pro Datenbankinstanz: 16
Autonomous Database:
  • Serverloses Data Warehouse
  • Serverlose Transaktionsverarbeitung
ECPU oder OCPU (Legacy) Die Gesamtanzahl der einer Instanz zugewiesenen ECPU/OCPU wird als ECPU/OCPU-Anzahl im Abschnitt Ressourcenzuteilung auf der Ressourcendetailseite für jede Instanz einer autonomen serverlosen Datenbank in der OCI-Konsole angezeigt.
Autonome Containerdatenbank:
  • Autonomous Database auf dedizierter Exadata-Infrastruktur
  • Autonomous Database auf Exadata Cloud@Customer
 ECPU oder OCPU (Legacy)

Die Gesamtanzahl der einer Instanz zugewiesenen ECPU/OCPU wird als ECPU/OCPU-Anzahl im Abschnitt Ressourcenzuteilung auf der Ressourcendetailseite für jede autonome Containerdatenbankinstanz in der OCI-Konsole angezeigt.

Oracle Kubernetes-Cluster (OKE) OCPU

Die Berechnung hängt von der Knotenpoolgröße und der OCPU-Menge ab, die jedem Knotenpool für das OKE-Cluster in beiden Regionen zugewiesen ist. Ein OKE-Cluster kann mehrere Knotenpools enthalten. Daher ist die Gesamt-OCPU für jede Region eine Summe der Ergebnisse aller Knotenpools in dieser Region.

Die Knotenpoolgröße im primären OKE-Cluster (nps) wird mit der Anzahl der diesem Knotenpool zugewiesenen OCPUs (npo) multipliziert. Führen Sie diese Berechnung für jeden Knotenpool (pnsn+*pnon+) in der primären Region aus, und summieren Sie die Ergebnisse aus den einzelnen Pools, um die gesamte OCPU-Anzahl für die primäre Region (poc) zu erreichen.

Die Knotenpoolgröße im Standby-OKE-Cluster (sns) wird mit der Anzahl der diesem Knotenpool zugewiesenen OCPUs (sno) multipliziert. Führen Sie diese Berechnung für jeden Knotenpool (snsn+*snon+) in der primären Region aus, und summieren Sie die Ergebnisse aus den einzelnen Pools.

Fügen Sie die gesamte OCPU-Anzahl aus der primären Region (poc) und die gesamte OCPU-Anzahl aus der Standbyregion (soc) hinzu, um eine gesamte OCPU-Anzahl für OKE (to) zu erreichen

Formel: ∑(pnsn+*pnon+) + ∑(snsn+*snon+) = to

Beispiel:

  1. Gesamt-OCPU in primärer Region berechnen
    • nps1 = Größe von Knotenpool 1 ist: 10
    • npo1 = OCPU-Anzahl von Knotenpool 1 pro Knoten beträgt: 2
    • nps2 = Größe von Knotenpool 2 ist: 5
    • npo2 = OCPU-Anzahl von Knotenpool 2 pro Knoten beträgt: 2
    • poc = OCPU-Gesamtanzahl für primäre Region beträgt: 30
  2. Gesamt-OCPU in Standbyregion berechnen
    • nps1 = Größe von Knotenpool 1 ist: 10
    • npo1 = OCPU-Anzahl von Knotenpool 1 pro Knoten beträgt: 2
    • nps2 = Größe von Knotenpool 2 ist: 5
    • npo2 = OCPU-Anzahl von Knotenpool 2 pro Knoten beträgt: 2
    • soc = OCPU-Gesamtanzahl für Standby-Region beträgt: 30
  3. Gesamte OCPU-Anzahl in beiden Regionen berechnen
    • poc = 30
    • soz = 30
    • to = OCPU-Anzahl für OKE insgesamt beträgt: 60

Kostenschätzung

Oracle stellt ein benutzerfreundliches Kostenschätzungstool auf der Full Stack DR-Produktseite bereit.

Full Stack Disaster Recovery installiert, konfiguriert oder stellt keine OCI-Ressourcen wie Compute, Speicher, Netzwerk, Datenbanken oder Anwendungen bereit. Sie sind für den Entwurf der Disaster-Recovery-Strategie verantwortlich, die von Full Stack Disaster Recovery orchestriert werden soll. Außerdem sind Sie für das Erstellen, Konfigurieren und Bereitstellen aller OCI-Ressourcen IaaS und PaaS außerhalb des Workflows für Full Stack Disaster Recovery verantwortlich. Daher sollten Sie sich bereits über die Ressourcen im Klaren sein, die in beiden Regionen bereitgestellt werden, bevor Sie mit Full Stack Disaster Recovery arbeiten. Das bedeutet, dass der Kostenrechner verwendet werden kann, bevor Sie tatsächlich OCI-Ressourcen in einer der OCI-Regionen bereitgestellt haben.

Überlegungen:

  • Es muss nicht berechnet werden, wo Ressourcen nach einem DR-Vorgang vorhanden sind. Betrachten Sie einfach die Ressourcen, in denen sie im aktuellen, normalen Betriebszustand vorhanden sind.
  • Fügen Sie für die primäre Region die Summen von OCPU und ECPU hinzu, die von Ressourcen verbraucht werden, die Mitglieder sind oder Mitglieder der primären DR-Schutzgruppe sein werden.
  • Fügen Sie für die Standbyregion die Summen der OCPU und ECPU hinzu, die von Ressourcen verbraucht werden, die Mitglieder sind oder Mitglieder der Standby-DR-Schutzgruppe sein werden. Sie können über belastbare Ressourcen als Mitglieder der Standby-Schutzgruppe verfügen. Beispiel: Es ist durchaus möglich, dass in der Standby-Schutzgruppe keine Member-Ressourcen CPU verbrauchen, wenn Sie nur das Recovery für das Verschieben von Compute orchestrieren.
Beispiel 1: Anwendungsstack mit nur Verschieben von Compute

Das folgende Beispiel zeigt ein fiktives Geschäftssystem, das in zwei OCI-Regionen bereitgestellt wird. Jeder Kunde hat je nach den Services IaaS und PaaS, die Teil des Anwendungsstacks sind, etwas anderes. In diesem Beispiel wird gezeigt, wie Sie die Kosten für das Verschieben von nur Compute-Instanzen und ohne Datenbanken schätzen.

Der Kostenrechner enthält sechs Felder zum Integrieren der gesamten OCPU- und ECPU-Anzahl für IaaS- und PaaS-Ressourcen in jeder Region.

Die folgende Tabelle enthält die sechs Felder, die Sie im Kostenrechner ausfüllen würden. Die Werte in den Feldern basieren auf den Details in der folgenden Tabelle, die einen fiktiven Anwendungsstack darstellen, der für das Disaster Recovery in zwei OCI-Regionen bereitgestellt wird.

Tabelle A-10: Primäre OCI-Region/Schutzgruppe

Compute-Member-OCPUs gesamt OCPUs des Datenbankmitglieds gesamt Gesamte ECPUs des Datenbankmitglieds
12 0 0

Tabelle A-11 Standby-OCI-Region/Schutzgruppe

Compute-Member-OCPUs gesamt OCPUs des Datenbankmitglieds gesamt Gesamte ECPUs des Datenbankmitglieds
0 0 0

Tabelle A-12: Kennzahlensummen

OCI Full Stack DR (OCPU) OCI Full Stack DR (ECPU)
12 0

CPU in primärer DR-Schutzgruppe

Gesamte CPU, die von Compute-Instanzen oder Datenbanken belegt wird, die Mitglieder der DR-Schutzgruppe in der primären Region (Region 1) sind.

Die folgende Tabelle zeigt ein Beispiel für die Ressourcen IaaS und PaaS, die in der primären Region vorhanden sind oder vorhanden sind. Die CPU-Summen in der letzten Zeile der Tabelle unten sind die Zahlen, die im obigen Beispielkostenrechner dargestellt sind.

CPU in primärer DR-Schutzgruppe

Tabelle A-13: CPU in primärer DR-Schutzgruppe

DR-Schutzgruppe Mitgliedsressource Beschreibung Compute-OCPU-Anzahl Datenbank-OCPU-Anzahl Datenbank-ECPU-Anzahl
Primär Compute-Instanz (mit Verschieben)
  • Vom Kunden installierte und verwaltete Nicht-Oracle-Anwendung
  • Apache-Webserver für Kundenportal
  • Anwendung wird aktiv ausgeführt
 MyApp01Server01 4    
Primär Compute-Instanz (mit Verschieben)
  • Vom Kunden installierte und verwaltete Nicht-Oracle-Anwendung
  • Apache-Webserver für Kundenportal
  • Anwendung wird aktiv ausgeführt
 MyApp01Server02 8    
Primär Load Balancer
  • Backend-Set 1 aktiv
  • Backend-Set 2 aktiv
 MyLoadBalancerRegion1 Keine Gebühr Keine Gebühr Keine Gebühr
Primär Block-Volume-Gruppe
  • Active
  • In Region 2 repliziert
  • Enthält Boot-Volume für MyApp01Server01
  • Enthält Boot-Volume für MyApp01Server02
 MyVG00 Keine Gebühr Keine Gebühr Keine Gebühr
Primär Dateisystem
  • Active
  • In Region 2 repliziert
  • Enthält ein Dateisystem für /myscripts, die unter MyApp01Server01 und MyApp01Server02 eingehängt sind
 myscripts Keine Gebühr Keine Gebühr Keine Gebühr
Primär Summe aller OCPUs und ECPUs der Member-Ressourcen in der primären Region   12 0 0

CPU in Standby-DR-Schutzgruppe

Gesamte CPU, die von Compute-Instanzen oder Datenbanken belegt wird, die Mitglieder der DR-Schutzgruppe in der Standbyregion (Region 2) sind.

Dieses Beispiel umfasst nur das Verschieben von Compute-Instanzen, die jeweils nur in einer einzelnen Region vorhanden sind. Daher sind in der Standby-Schutzgruppe keine kostenpflichtigen Member-Ressourcen vorhanden, d.h. es fallen keine Gebühren für Full Stack Disaster Recovery in der Standbyregion an.

CPU in Standby-DR-Schutzgruppe

Tabelle A-14: CPU in Standby-DR-Schutzgruppe

DR-Schutzgruppe Mitgliedsressource Beschreibung Compute-OCPU-Anzahl Datenbank-OCPU-Anzahl Datenbank-ECPU-Anzahl
Standby Load Balancer
  • Backend-Set 1 nicht aktiv, nicht aufgefüllt
  • Backend-Set 2not aktiv, nicht aufgefüllt
 MyLoadBalancerRegion2 Keine Gebühr Keine Gebühr Keine Gebühr
Standby Summe aller OCPUs und ECPUs der Member-Ressourcen in der Standbyregion   0 0 0

Beispiel 2: Anwendungsstack mit Verschieben von Compute- und Datenbanken

Das folgende Beispiel zeigt ein fiktives Geschäftssystem, das in zwei OCI-Regionen bereitgestellt wird. Jeder Kunde hat je nach den Services IaaS und PaaS, die Teil des Anwendungsstacks sind, etwas anderes. In diesem Beispiel wird gezeigt, wie Sie die Kosten für das Verschieben von Compute und zwei Oracle-Datenbanken schätzen.

Der Kostenrechner enthält sechs Felder zum Integrieren der gesamten OCPU- und ECPU-Anzahl für IaaS- und PaaS-Ressourcen in jeder Region. Die folgende Tabelle enthält die sechs Felder, die Sie im Kostenrechner ausfüllen würden. Die Werte in den Feldern basieren auf den Details in der folgenden Tabelle, die einen fiktiven Anwendungsstack darstellen, der für das Disaster Recovery in zwei OCI-Regionen bereitgestellt wird.

Primäre OCI-Region/Schutzgruppe

Tabelle A-15: Primäre OCI-Region/Schutzgruppe

Compute-Member-OCPUs gesamt OCPUs des Datenbankmitglieds gesamt Gesamte ECPUs des Datenbankmitglieds
12 16 16
Standby-OCI-Region/Schutzgruppe

Tabelle A-16: Standby-OCI-Region/Schutzgruppe

Compute-Member-OCPUs gesamt OCPUs des Datenbankmitglieds gesamt Gesamte ECPUs des Datenbankmitglieds
0 16 16
Kennzahlensummen

Tabelle A-17: Kennzahlensummen

OCI Full Stack DR (OCPU) OCI Full Stack DR (ECPU)
44 32

CPU in primärer DR-Schutzgruppe

Gesamte CPU, die von Compute-Instanzen oder Datenbanken belegt wird, die Mitglieder der DR-Schutzgruppe in der primären Region (Region 1) sind.

Die folgende Tabelle zeigt ein Beispiel für die Ressourcen IaaS und PaaS, die in der primären Region vorhanden sind oder vorhanden sind. Die CPU-Summen in der letzten Zeile der Tabelle unten sind die Zahlen, die im obigen Beispielkostenrechner dargestellt sind.

CPU in primärer DR-Schutzgruppe

Tabelle A-18: CPU in primärer DR-Schutzgruppe

DR-Schutzgruppe Mitgliedsressource Beschreibung Compute-OCPU-Anzahl Datenbank-OCPU-Anzahl Datenbank-ECPU-Anzahl
Primär Compute-Instanz (mit Verschieben)
  • Vom Kunden installierte und verwaltete Nicht-Oracle-Anwendung
  • Apache-Webserver für Kundenportal
  • Anwendung wird aktiv ausgeführt
 MyApp01Server01 4    
Primär Compute-Instanz (mit Verschieben)
  • Vom Kunden installierte und verwaltete Nicht-Oracle-Anwendung
  • Apache-Webserver für Kundenportal
  • Anwendung wird aktiv ausgeführt
 MyApp01Server02 8    
Primär Oracle Database
  • Exadata-VM-Cluster
  • Data Guard in Primärrolle
  • Dem VM-Cluster insgesamt 64 OCPUs zugewiesen
  • 4 im VM-Cluster bereitgestellte Datenbanken
  • 16 OCPU pro Datenbank: (64/4 = 16 OCPU pro Datenbank)
 MyExaDatabase03   16  
Primär Autonomous Database
  • Dedizierte Infrastruktur
  • Autonomous Data Guard in primärer Rolle
 MyADB01     16
Primär Load Balancer
  • Backend-Set 1 aktiv
  • Backend-Set 2 aktiv
 MyLoadBalancerRegion1 Keine Gebühr Keine Gebühr Keine Gebühr
Primär Block-Volume-Gruppe
  • Active
  • In Region 2 repliziert
  • Enthält Boot-Volume für MyApp01Server01
  • Enthält Boot-Volume für MyApp01Server02
 MyVG00 Keine Gebühr Keine Gebühr Keine Gebühr
Primär Dateisystem
  • Active
  • In Region 2 repliziert
  • Enthält ein Dateisystem für /myscripts, die unter MyApp01Server01 und MyApp01Server02 eingehängt sind
 myscripts Keine Gebühr Keine Gebühr Keine Gebühr
Primär Summe aller OCPUs und ECPUs der Member-Ressourcen in der primären Region   12 16 16

CPU in Standby-DR-Schutzgruppe

Gesamte CPU, die von Compute-Instanzen oder Datenbanken belegt wird, die Mitglieder der DR-Schutzgruppe in der Standbyregion (Region 2) sind.

Dieses Beispiel umfasst nur das Verschieben von Compute-Instanzen, die jeweils nur in einer einzelnen Region vorhanden sind. Daher sind in der Standby-Schutzgruppe keine kostenpflichtigen Member-Ressourcen vorhanden, d.h. es fallen keine Gebühren für Full Stack Disaster Recovery in der Standbyregion an.

CPU in Standby-DR-Schutzgruppe

Tabelle A-19 CPU in Standby-DR-Schutzgruppe

DR-Schutzgruppe Mitgliedsressource Beschreibung Compute-OCPU-Anzahl Datenbank-OCPU-Anzahl Datenbank-ECPU-Anzahl
Standby Oracle Database
  • Exadata-VM-Cluster mit insgesamt 64 OCPUs
  • Data Guard in Primärrolle
  • Dem VM-Cluster insgesamt 64 OCPUs zugewiesen
  • 4 im VM-Cluster bereitgestellte Datenbanken
  • 16 OCPU pro Datenbank: (64/4 = 16 OCPU pro Datenbank)
 MyExaDatabase03   16  
Standby Autonomous Database
  • Dedizierte Infrastruktur
  • Data Guard in Standbyrolle
 MyADB01     16
Standby Load Balancer
  • Backend-Set 1 nicht aktiv, nicht aufgefüllt
  • Backend-Set 2 nicht aktiv, nicht ausgefüllt
 MyLoadBalancerRegion2 Keine Gebühr Keine Gebühr Keine Gebühr
Standby Summe aller OCPUs und ECPUs der Member-Ressourcen in der Standbyregion   0 16 16

Beispiel 3: Anwendungsstack mit beweglichem und nicht beweglichem Compute

Das folgende Beispiel zeigt ein fiktives Geschäftssystem, das in zwei OCI-Regionen bereitgestellt wird. Jeder Kunde hat je nach den Services IaaS und PaaS, die Teil des Anwendungsstacks sind, etwas anderes.

Dieses Beispiel veranschaulicht die Preisfindung für Full Stack DR, wenn sowohl gleitende als auch nicht gleitende Compute-Instanzen Mitglieder von DR-Schutzgruppen in beiden Regionen sind. Dies veranschaulicht auch einen Anwendungsfall, bei dem jemand eine Oracle Database und Data Guard manuell auf einer Compute-Instanz installiert hat, anstatt den Oracle Database-Service in der OCI-Konsole zu verwenden. Dies ist ein einfaches Beispiel dafür, warum und wie Sie nicht zu verschiebende Compute-Instanzen verwenden können. Die integrierte Unterstützung für Oracle-Datenbanken in Full Stack Disaster Recovery wird jedoch nicht genutzt.

Zur Veranschaulichung verwendet dieses Beispiel insgesamt vier Compute-Instanzen:

  • Zwei Standard-Compute-Instanzen fungieren als "bewegliche" Server für eine Anwendung, die toleriert, dass sie zwischen Regionen verschoben werden.
    • Beispiele für Anwendungen, die auf diesen Servern installiert werden können, sind Anwendungen, die keine zustandsbehafteten, regionsspezifischen, hartcodierten Werte in Binärdateien oder Konfigurationsdateien verwalten und es einfach tolerieren können, dass sie in einer anderen Region mit einer anderen IP-Adresse und geringfügigen Änderungen oder Konfigurationsdateien beim Start gestartet werden.
    • Diese Compute-Instanzen sind nur Mitglieder der primären DR-Schutzgruppe.
  • Eine Standard-Compute-Instanz fungiert als "nicht beweglicher", aktiver Anwendungsserver.
    • Diese Compute-Instanz ist nur in Region 1 vorhanden und wird nie in Region 2 vorhanden sein.
    • Die Anwendung wird in Region 1 installiert und ausgeführt.
    • Diese Compute-Instanz ist nur Mitglied der primären DR-Schutzgruppe.
  • Eine Standard-Compute-Instanz fungiert als "nicht beweglicher, nicht aktiver Anwendungsserver".
    • Diese Compute-Instanz ist nur in Region 2 vorhanden und wird nie in Region 1 vorhanden sein.
    • Die Anwendung ist installiert, wird jedoch nicht in Region 2 ausgeführt.
    • Diese Compute-Instanz ist nur Mitglied der Standby-DR-Schutzgruppe.

Der Kostenrechner enthält sechs Felder zum Integrieren der gesamten OCPU- und ECPU-Anzahl für IaaS- und PaaS-Ressourcen in jeder Region. Die folgende Tabelle enthält die sechs Felder, die Sie im Kostenrechner ausfüllen würden. Die Werte in den Feldern basieren auf den Details in der folgenden Tabelle, die einen fiktiven Anwendungsstack darstellen, der für das Disaster Recovery in zwei OCI-Regionen bereitgestellt wird. Beachten Sie, dass keine Kosten mit vom Benutzer installierten und verwalteten Datenbanken verbunden sind. Die Kosten werden stattdessen von der OPCU berechnet, die von den virtuellen Maschinen verbraucht wird, auf denen die Datenbank und Data Guard gehostet werden.

Primäre OCI-Region/Schutzgruppe

Tabelle A-20: Primäre OCI-Region/Schutzgruppe

Compute-Member-OCPUs gesamt OCPUs des Datenbankmitglieds gesamt Gesamte ECPUs des Datenbankmitglieds
14 16 0
Standby-OCI-Region/Schutzgruppe

Tabelle A-21: Standby-OCI-Region/Schutzgruppe

Compute-Member-OCPUs gesamt OCPUs des Datenbankmitglieds gesamt Gesamte ECPUs des Datenbankmitglieds
2 16 0
Kennzahlensummen

Tabelle A-22: Kennzahlensummen

OCI Full Stack DR (OCPU) OCI Full Stack DR (ECPU)
48 0

CPU in primärer DR-Schutzgruppe

Gesamte CPU, die von Compute-Instanzen oder Datenbanken belegt wird, die Mitglieder der DR-Schutzgruppe in der primären Region (Region 1) sind.

Die folgende Tabelle zeigt ein Beispiel für die Ressourcen IaaS und PaaS, die in der primären Region vorhanden sind oder vorhanden sind. Die CPU-Summen in der letzten Zeile der Tabelle unten sind die Zahlen, die im obigen Beispielkostenrechner dargestellt sind.

CPU in primärer DR-Schutzgruppe

Tabelle A-23: CPU in primärer DR-Schutzgruppe

DR-Schutzgruppe Mitgliedsressource Beschreibung Compute-OCPU-Anzahl Datenbank-OCPU-Anzahl Datenbank-ECPU-Anzahl
Primär Compute-Instanz (mit Verschieben)
  • Vom Kunden installierte und verwaltete Nicht-Oracle-Anwendung
  • Apache-Webserver für Kundenportal
  • Anwendung wird aktiv ausgeführt
 MyApp01Server01 4    
Primär Compute-Instanz (mit Verschieben)
  • Vom Kunden installierte und verwaltete Nicht-Oracle-Anwendung
  • Apache-Webserver für Kundenportal
  • Anwendung wird aktiv ausgeführt
 MyApp01Server02 8    
Primär Compute-Instanz (ohne Verschieben
  • Der Kunde installiert und verwaltet Oracle-Anwendungen wie Oracle Siebel CRM, PeopleSoft, JD Edwards EnterpriseOne, Oracle E-business Suite usw.
  • Anwendung wird aktiv ausgeführt
 MyApp02Server01 2    
Primär Oracle Database
  • Primärdatenbank für Oracle-Anwendung, die auf MyApp02Server01 ausgeführt wird
  • Exadata-VM-Cluster
  • Data Guard in Primärrolle
  • Dem VM-Cluster insgesamt 64 OCPUs zugewiesen
  • 4 im VM-Cluster bereitgestellte Datenbanken
  • 16 OCPU pro Datenbank: (64/4 = 16 OCPU pro Datenbank)
 MyExaDatabase03   16  
Primär Load Balancer
  • Backend-Set 1 aktiv
  • Backend-Set 2 aktiv
 MyLoadBalancerRegion1 Keine Gebühr Keine Gebühr Keine Gebühr
Primär Block-Volume-Gruppe
  • Active
  • In Region 2 repliziert
  • Enthält Boot-Volume für MyApp01Server01
  • Enthält Boot-Volume für MyApp01Server02
 MyVG00 Keine Gebühr Keine Gebühr Keine Gebühr
Primär Dateisystem
  • Active
  • In Region 2 repliziert
  • Enthält ein Dateisystem für /myscripts, die unter MyApp01Server01 und MyApp01Server02 eingehängt sind
 myscripts Keine Gebühr Keine Gebühr Keine Gebühr
Primär Summe aller OCPUs und ECPUs der Member-Ressourcen in der primären Region   14 16 0
CPU in Standby-DR-Schutzgruppe

Gesamte CPU, die von Compute-Instanzen oder Datenbanken belegt wird, die Mitglieder der DR-Schutzgruppe in der Standbyregion (Region 2) sind.

Dieses Beispiel umfasst nur das Verschieben von Compute-Instanzen, die jeweils nur in einer einzelnen Region vorhanden sind. Daher sind in der Standby-Schutzgruppe keine kostenpflichtigen Member-Ressourcen vorhanden, d.h. es fallen keine Gebühren für Full Stack Disaster Recovery in der Standbyregion an.

CPU in Standby-DR-Schutzgruppe

Tabelle A-24: CPU in Standby-DR-Schutzgruppe

DR-Schutzgruppe Mitgliedsressource Beschreibung Compute-OCPU-Anzahl Datenbank-OCPU-Anzahl Datenbank-ECPU-Anzahl
Standby Compute-Instanz (ohne Verschieben).
  • Der Kunde installiert und verwaltet Oracle-Anwendungen wie Oracle Siebel CRM, PeopleSoft, JD Edwards EnterpriseOne, Oracle E-business Suite usw.
  • Anwendung installiert, wird jedoch nicht ausgeführt
 MyApp02Server02 2 0 0
Standby Oracle Database
  • Standbydatenbank für Oracle-Anwendung, die auf MyApp02Server02 ausgeführt wird
  • Exadata-VM-Cluster
  • Data Guard in Standbyrolle
  • Dem VM-Cluster insgesamt 64 OCPUs zugewiesen
  • 4 im VM-Cluster bereitgestellte Datenbanken
  • 16 OCPU pro Datenbank: (64/4 = 16 OCPU pro Datenbank)
 MyExaDatabase03   16  
Standby Load Balancer
  • Backend-Set 1 nicht aktiv, nicht aufgefüllt
  • Backend-Set 2not aktiv, nicht aufgefüllt
 MyLoadBalancerRegion2 Keine Gebühr Keine Gebühr Keine Gebühr
Standby Summe aller OCPUs und ECPUs der Member-Ressourcen in der Standbyregion   2 16 0

Beispiel 4: Anwendungsstack mit OKE, Datenbank, Verschieben von Compute- und nicht zu verschiebenden Compute-Instanzen

Das folgende Beispiel zeigt ein fiktives Geschäftssystem, das in zwei OCI-Regionen bereitgestellt wird. Jeder Kunde hat je nach den Services IaaS und PaaS, die Teil des Anwendungsstacks sind, etwas anderes.

Dieses Beispiel veranschaulicht die Preisfindung für Full Stack DR für ein Geschäftssystem, das Worker-Knoten umfasst, die auf einem Oracle Kubernetes Engine-Cluster (OKE) gehostet werden, sowie das Verschieben und Nicht-Verschieben von Compute als Mitglieder von DR-Schutzgruppen in beiden Regionen. Dies ist ein kleines Beispiel für eine typischere Deployment-Architektur für ein Geschäftssystem, in der möglicherweise ein Anwendungsstack für eine Nicht-Oracle- oder Oracle-Anwendung für Ressourcenplanung, Finanzen, Lagerverwaltung, Lieferkettenmanagement, Customer Relationship Management, Vertriebsportal usw. gehostet wird. Das Moving Compute kann zum Hosten von Oracle- oder Nicht-Oracle-Anwendungen verwendet werden, die mit minimalen Änderungen funktionieren, wenn sie in einer anderen Region aufgerufen werden. Das nicht zu verschiebende Compute wird normalerweise zum Hosten von Oracle- oder Nicht-Oracle-Anwendungen verwendet, die nicht funktionieren können, oder kann einfach so geändert werden, dass es überhaupt funktioniert, wenn es in einer anderen Region aufgerufen wird. Beispiele für Anwendungen, die auf nicht zu verschiebenden Compute-Instanzen installiert werden können, sind Oracle-Anwendungen wie PeopleSoft, JD Edwards EnterpriseOne, Oracle Siebel CRM, Oracle E-Business Suite, Oracle WebLogic Server usw. Diese Anwendungen müssen auf virtuellen Maschinen in der primären Region installiert und aktiv ausgeführt und installiert werden, jedoch nicht auf virtuellen Maschinen, die in der Standbyregion ausgeführt werden.

Zur Veranschaulichung verwendet dieses Beispiel insgesamt vier Standard-Compute-Instanzen, vier OKE-Worker-Knoten sowie mehrere verschiedene Oracle-Datenbanken, darunter Autonomous Database, Base Database und Exadata, die alle in einer einzelnen DR-Planausführung wiederhergestellt werden:

  • Zwei Standard-Compute-Instanzen fungieren als "bewegliche" Server für eine Anwendung, die toleriert, dass sie zwischen Regionen verschoben werden.
    • Beispiele für Anwendungen, die auf diesen Servern installiert werden können, sind Anwendungen, die keine zustandsbehafteten, regionsspezifischen, hartcodierten Werte in Binärdateien oder Konfigurationsdateien verwalten und es einfach tolerieren können, dass sie in einer anderen Region mit einer anderen IP-Adresse und geringfügigen Änderungen oder Konfigurationsdateien beim Start gestartet werden.
    • Diese Compute-Instanzen sind nur Mitglieder der primären DR-Schutzgruppe.
  • Eine Standard-Compute-Instanz fungiert als "nicht beweglicher", aktiver Anwendungsserver.
    • Diese Compute-Instanz ist nur in Region 1 vorhanden und wird nie in Region 2 vorhanden sein.
    • Die Anwendung wird in Region 1 installiert und ausgeführt.
    • Diese Compute-Instanz ist nur Mitglied der primären DR-Schutzgruppe.
  • Eine Standard-Compute-Instanz fungiert als "nicht beweglicher, nicht aktiver Anwendungsserver".
    • Diese Compute-Instanz ist nur in Region 2 vorhanden und wird nie in Region 1 vorhanden sein.
    • Die Anwendung ist installiert, wird jedoch nicht in Region 2 ausgeführt.
    • Diese Compute-Instanz ist nur Mitglied der Standby-DR-Schutzgruppe.
  • Vier Worker-Knoten im OKE-Cluster, die Anwendungs-Workloads hosten, die wiederhergestellt werden müssen.
    • Vier Worker-Knoten im OKE-Cluster der primären Region, die immer nur Mitglied der primären DR-Schutzgruppe bleiben.
    • Vier Worker-Knoten im OKE-Cluster der Standbyregion, die immer nur Mitglied der Standby-DR-Schutzgruppe bleiben.
  • Vier OCI-Oracle-Datenbanken mit aktiviertem Data Guard sind bereits über die OCI-Konsole aktiviert, die verschiedene Anwendungen unterstützen.
    • Die vier Primärdatenbanken sind nur Mitglieder der primären DR-Schutzgruppe.
    • Die vier Standbydatenbanken sind nur Mitglieder der Standby-DR-Schutzgruppe.

Der Kostenrechner enthält sechs Felder zum Integrieren der gesamten OCPU- und ECPU-Anzahl für IaaS- und PaaS-Ressourcen in jeder Region. Die folgende Tabelle enthält die sechs Felder, die Sie im Kostenrechner ausfüllen würden. Die Werte in den Feldern basieren auf den Details in der folgenden Tabelle, die einen fiktiven Anwendungsstack darstellen, der für das Disaster Recovery in zwei OCI-Regionen bereitgestellt wird.

Primäre OCI-Region/Schutzgruppe

Tabelle A-25: Primäre OCI-Region/Schutzgruppe

Compute-Member-OCPUs gesamt OCPUs des Datenbankmitglieds gesamt Gesamte ECPUs des Datenbankmitglieds
22 24 20
Standby-OCI-Region/Schutzgruppe

Tabelle A-26 Standby-OCI-Region/Schutzgruppe

Compute-Member-OCPUs gesamt OCPUs des Datenbankmitglieds gesamt Gesamte ECPUs des Datenbankmitglieds
10 24 20

Kennzahlensummen

Tabelle A-27 Metriksummen

OCI Full Stack DR (OCPU) OCPUs des Datenbankmitglieds gesamt
80 40

CPU in primärer DR-Schutzgruppe

Gesamte CPU, die von Compute-Instanzen oder Datenbanken belegt wird, die Mitglieder der DR-Schutzgruppe in der primären Region (Region 1) sind.

Die folgende Tabelle zeigt ein Beispiel für die Ressourcen IaaS und PaaS, die in der primären Region vorhanden sind oder vorhanden sind. Die CPU-Summen in der letzten Zeile der Tabelle unten sind die Zahlen, die im obigen Beispielkostenrechner dargestellt sind.

Tabelle A-28: CPU in primärer DR-Schutzgruppe

DR-Schutzgruppe Mitgliedsressource Beschreibung Compute-OCPU-Anzahl Datenbank-OCPU-Anzahl Datenbank-ECPU-Anzahl
Primär Compute-Instanz (mit Verschieben)
  • Vom Kunden installierte und verwaltete Nicht-Oracle-Anwendung
  • Apache-Webserver für Kundenportal
  • Anwendung wird aktiv ausgeführt
 MyApp01Server01 4    
Primär Compute-Instanz (mit Verschieben)
  • Vom Kunden installierte und verwaltete Nicht-Oracle-Anwendung
  • Apache-Webserver für Kundenportal
  • Anwendung wird aktiv ausgeführt
 MyApp01Server02 8    
Primär Compute-Instanz (ohne Verschieben
  • Der Kunde installiert und verwaltet Oracle-Anwendungen wie Oracle Siebel CRM, PeopleSoft, JD Edwards EnterpriseOne, Oracle E-business Suite usw.
  • Anwendung wird aktiv ausgeführt
 MyApp02Server01 2    
Primär OKE-Cluster: 4 Worker-Knoten mit je 2 OCPU MyOKECluster01 8    
Primär Oracle Database:
  • Basisdatenbank
  • Data Guard in Primärrolle
 MyEEDatabase01   8  
Primär Oracle Database:
  • Primärdatenbank für Oracle-Anwendung, die auf MyApp02Server01 ausgeführt wird
  • Exadata-VM-Cluster
  • Data Guard in Primärrolle
  • Dem VM-Cluster insgesamt 64 OCPUs zugewiesen
  • 4 im VM-Cluster bereitgestellte Datenbanken
  • 16 OCPU pro Datenbank: (64/4 = 16 OCPU pro Datenbank)
 MyExaDatabase03   16  
Primär Autonomous Database
  • Dedizierte Infrastruktur
  • Autonomous Data Guard in primärer Rolle
 MyADB01     16
Primär Autonomous Database
  • Serverlose Infrastruktur
  • Autonomous Data Guard in primärer Rolle
 MyADW01     4
Primär Load Balancer
  • Backend-Set 1 aktiv
  • Backend-Set 2 aktiv
 MyLoadBalancerRegion1 Keine Gebühr Keine Gebühr Keine Gebühr
Primär Block-Volume-Gruppe
  • Active
  • In Region 2 repliziert
  • Enthält Boot-Volume für MyApp01Server01
  • Enthält Boot-Volume für MyApp01Server02
 MyVG00 Keine Gebühr Keine Gebühr Keine Gebühr
Primär Block-Volume-Gruppe:
  • Active
  • In Region 2 repliziert
  • Enthält Block-Volume für /u02 onMyApp02Server01
  • Ruft während des Recoverys erneut auf /u02 auf MyApp02Server02 in region2 ab
 MyVG01 Keine Gebühr Keine Gebühr Keine Gebühr
Primär Dateisystem:
  • Active
  • In Region 2 repliziert
  • Enthält ein Dateisystem für /myscripts, die unter MyApp01Server01 und MyApp01Server02 eingehängt sind
 myscripts Keine Gebühr Keine Gebühr Keine Gebühr
Primär Summe aller OCPUs und ECPUs der Member-Ressourcen in der primären Region   22 24 20

CPU in Standby-DR-Schutzgruppe

Gesamte CPU, die von Compute-Instanzen oder Datenbanken belegt wird, die Mitglieder der DR-Schutzgruppe in der Standbyregion (Region 2) sind.

Nehmen Sie nur Member-Ressourcen auf, die derzeit in der Standbyregion vorhanden sind. Sie müssen nicht berechnen, wo die Ressourcen nach einem DR-Vorgang vorhanden sind. Fügen Sie einfach die Ressourcen hinzu, in denen sie im aktuellen, normalen Status der Vorgänge vorhanden sind. Das gleitende Compute in der primären Region ist nicht als Mitglieder der Standby-DR-Schutzgruppe enthalten. Daher fallen keine OCPU-Gebühren für das Verschieben von Compute in der Standbyregion an.

Tabelle A-29: CPU in Standby-DR-Schutzgruppe

DR-Schutzgruppe Mitgliedsressource Beschreibung Compute-OCPU-Anzahl Datenbank-OCPU-Anzahl Datenbank-ECPU-Anzahl
Standby Compute-Instanz (ohne Verschieben
  • Der Kunde installiert und verwaltet Oracle-Anwendungen wie Oracle Siebel CRM, PeopleSoft, JD Edwards EnterpriseOne, Oracle E-business Suite usw.
  • Anwendung installiert, wird jedoch nicht ausgeführt
 MyApp02Server02 2    
Standby OKE-Cluster: 4 Worker-Knoten mit je 2 OCPU MyOKECluster01 8    
Standby Oracle Database:
  • Basisdatenbank
  • Data Guard in Standbyrolle
, 		MyEEDatabase01   8  
Standby Oracle Database:
  • Standbydatenbank für Oracle-Anwendung, die auf MyApp02Server02 ausgeführt wird
  • Exadata-VM-Cluster
  • Data Guard in Standbyrolle
  • Dem VM-Cluster insgesamt 64 OCPUs zugewiesen
  • 4 im VM-Cluster bereitgestellte Datenbanken
  • 16 OCPU pro Datenbank: (64/4 = 16 OCPU pro Datenbank)
 MyExaDatabase03   16  
Standby Autonomous Database:
  • Dedizierte Infrastruktur
  • Data Guard in Standbyrolle
 MyADB01     16
Standby Autonomous Database:
  • Serverlose Infrastruktur
  • Data Guard in Standbyrolle
 MyADW01     4
Standby Load Balancer:
  • Backend-Set 1 nicht aktiv, nicht aufgefüllt
  • Backend-Set 2not aktiv, nicht aufgefüllt
 MyLoadBalancerRegion2 Keine Gebühr   Keine Gebühr
Standby Summe aller OCPUs und ECPUs der Member-Ressourcen in der Standbyregion   10 24 20

Übergeordnetes Thema: Referenz