Documentation Oracle Cloud Infrastructure

Détails de facturation Full Stack DR

Découvrez comment le service Full Stack DR calcule la facturation pour chaque type de membre ajouté à un groupe de protection de récupération après sinistre, y compris quelques exemples de calcul.

Mode de calcul de la facturation pour une configuration DR

  1. Une configuration de récupération après sinistre est tout ce qui est nécessaire pour récupérer un système d'entreprise unique.
    • Il n'est pas nécessaire d'avoir une configuration de récupération après sinistre pour estimer le coût mensuel de Full Stack DR.
    • Seules les ressources OCI IaaS et PaaS répertoriées ci-dessous sont nécessaires pour estimer le coût mensuel de Full Stack DR.
  2. Les frais pour Full Stack DR dépassent les frais habituels engagés pour les services OCI courants tels que le calcul, les bases de données Oracle, les bases de données MySQL et les instances Oracle Integration compatibles avec la récupération après sinistre.
    • Aucuns frais supplémentaires ne sont engagés pour le stockage, le réseau ou d'autres ressources OCI prises en charge de manière native avec Full Stack DR.
    • Pour plus de détails, reportez-vous à la liste dans la section Ressources membres qui génèrent des frais ci-dessous.
  3. Full Stack DR utilise les éléments suivants pour calculer les frais sur une base mensuelle :
    • Déplacement de calcul : OCPU allouée uniquement dans la région principale.
    • Calcul mobile : OCPU allouée dans les régions principale et de secours.
    • Bases de données Oracle : OCPU ou ECPU allouées dans les régions principale et de secours.
    • MySQL Bases de données Heatwave : ECPU allouée dans les régions principale et de secours.
    • Oracle Integration : packs de messages OIC alloués dans les régions principale et de secours.
    • Oracle Kubernetes Engine : OCPU allouée de noeuds de processus actif dans les régions principale et de secours.
      • Full Stack DR prend en charge les pools de noeuds gérés et virtuels OKE.
      • Les pools de noeuds OKE prennent en charge la fonctionnalité d'outil de redimensionnement automatique de cluster OKE, qui peut modifier le nombre de noeuds de processus actif à la demande dans les régions principale ou de secours.
      • Votre estimation des coûts doit être prise en compte. La quantité d'OCPU allouée peut augmenter ou diminuer plusieurs fois au cours d'un cycle de facturation mensuel.
    • Pour plus de détails, reportez-vous à la liste dans la section Ressources membres qui génèrent des frais ci-dessous.
  4. L'estimation du coût mensuel total associé à Full Stack Disaster Recovery peut être calculée à l'aide d'un outil d'estimation des coûts :
    • Le tableau disponible dans la section Détermination de la consommation des ressources ci-dessous explique comment rechercher et déterminer les ressources allouées pour chaque type de ressource OCI qui génère des frais.
    • Ajoutez les quantités des différentes ressources allouées à l'outil d'estimation des coûts. Il existe deux outils d'estimation des coûts différents :
      • Option 1 : Evaluateur de coûts Full Stack DR disponible dans l'onglet Tarification de la page du produit Full Stack DR. Cela fournit une estimation rapide des coûts liés uniquement à Full Stack DR, mais ne vous permet pas d'estimer le coût des ressources OCI.
      • Option 2 : Evaluateur de coût complet disponible sur la page Tarif OCI. Cela vous permet d'établir une estimation qui inclut les coûts liés à Full Stack DR ainsi que toutes les autres ressources OCI qui font ou feront partie de la pile d'applications que vous protégez avec Full Stack DR. Vous pouvez enregistrer votre estimation de tarification en exportant la configuration vers un fichier JSON. Vous pouvez également importer le fichier JSON à tout moment à l'avenir pour continuer à travailler sur une nomenclature pour l'ensemble de votre pile d'applications.

Ressources membres soumises à des frais

Full Stack DR utilise uniquement les packs de messages OCPU, ECPU ou OIC alloués comme base de calcul des frais. Les frais pour Full Stack DR sont cumulés pour tous les membres de calcul, de base de données ou Oracle Integration d'un groupe de protection de récupération après sinistre, que la ressource soit en cours d'exécution ou arrêtée. Par exemple, une instance de calcul non mobile qui existe dans la région de secours mais qui est toujours à l'état arrêté jusqu'à ce qu'une opération de récupération après sinistre soit exécutée accumulera toujours des frais horaires, même si elle n'est pas en cours d'exécution.

Ressources OCI faisant l'objet de frais

Des frais de récupération après sinistre de pile complète sont engagés pour les types de ressource OCI IaaS et PaaS suivants :
  • Autonomous Database
    • Oracle Autonomous Database Serverless (entreposage de données)
    • Oracle Autonomous Database Serverless (traitement des transactions)
  • Base de données Conteneur Autonomous
    • Base de données autonome sur une infrastructure Exadata dédiée
  • Oracle Database
    • Base de données Base
    • Exadata Database on Dedicated Infrastructure
    • Base de données Exadata sur Cloud@Customer
    • Base de données Exadata sur une infrastructure Exascale
  • Base de données
    • MySQL HeatWave
  • Instance de calcul (mobile)
  • Instance de calcul (non mobile)
  • Services de développement
    • Oracle Integration 3 (OIC)
    • Moteur Oracle Kubernetes (OKE)
Aucun frais de récupération après sinistre de pile complète n'est engagé pour les types de ressource OCI IaaS et PaaS suivants :
  • Stockage de blocs (volumes d'initialisation inclus)
  • File Storage
  • Object Storage
  • Equilibreurs de charge
  • Equilibreurs de charge réseau
Aucun frais Full Stack DR n'est engagé pour les éléments suivants :
  • Applications Oracle
  • Applications non Oracle

Détermination de la consommation de ressources

Le tableau suivant montre comment la consommation de ressources est déterminée pour différents types de ressource membre OCI qui entraînent des frais horaires pour Full Stack DR. La détermination de la consommation du processeur et du pack de messages OIC pour la plupart des types de ressource OCI est simple et basée sur ce qui est affiché sur la page de détails de chaque ressource individuelle dans la console OCI. Cependant, certaines ressources telles que certaines bases de données Oracle qui n'affichent pas la consommation de processeur pour des bases de données individuelles sont dérivées du total agrégé de l'UC consommée par le cluster de machines virtuelles.

Tableau A-11 Détermination de la consommation du processeur

Type de membre Type UC Base du calcul
Instance de calcul (mobile) OCPU Nombre d'OCPU alloué à l'instance de calcul. Reportez-vous à la section Configuration de forme de la page Documentation OCI pour l'instance de calcul.
Instance de calcul (non mobile) OCPU Nombre d'OCPU alloué à l'instance de calcul. Reportez-vous à la section Configuration de forme de la page Documentation OCI pour l'instance de calcul.
Base de données : système de base de données MySQL Heatwave ECPU Nombre d'UC alloués au système de base de données. Reportez-vous au nombre d'ECPU dans la section Allocation de ressources sous l'onglet Détails de la page OCI pour obtenir des détails sur le système de base de données.
Oracle Database : Oracle Base Database OCPU Nombre de coeurs de processeur alloué au système de base de données (système de base de données) associé à la base de données Base. Reportez-vous à la section Informations générales de la page Documentation OCI pour la base de données Base.
Oracle Database :
  • Oracle Exadata Database on Dedicated Infrastructure
  • Oracle Exadata Database on Cloud@Customer
  • Oracle Exadata Database on Exascale Infrastructure
 ECPU ou OCPU (héritée)

Le nombre total d'ECPU ou d'OCPU pour le cluster de machines virtuelles qui héberge cette base de données, divisé par le nombre total de bases de données provisionnées sur ce cluster de machines virtuelles (ti), est égal à l'UC par instance de base de données (to). Ce nombre moyen d'UC dérivé est une approximation.

Formule : (tc/ti) =to

Exemple :
  • tc = nombre total d'OCPU ou d'OCPU affectées au cluster de machines virtuelles Exadata : 64
  • ti = Nombre total d'instances de base de données dans le cluster : 4
  • to = ECPU ou OCPU par instance de base de données : 16
Autonomous Database :
  • Entrepôt de données sans serveur
  • Traitement des transactions sans serveur
ECPU ou OCPU (héritée) Le nombre total d'ECPU/OCPU allouées à une instance est affiché sous la forme Nombre d'ECPU/OCPU dans la section Allocation de ressources de la page de détails de la ressource pour chaque instance de base de données autonome sans serveur dans la console OCI.
Base de données Conteneur Autonomous:
  • Base de données autonome sur une infrastructure Exadata dédiée
  • Autonomous Database on Exadata Cloud@Customer
 ECPU ou OCPU (héritée)

Le nombre total d'ECPU/OCPU allouées à une instance est affiché en tant que nombre d'ECPU/OCPU dans la section Allocation de ressources de la page de détails de la ressource pour chaque instance de base de données Conteneur Autonomous dans la console OCI.

Oracle Integration 3
  • Enterprise Edition avec licence gérée par Oracle
 Pack de message

Le nombre total de packs de messages OIC est indiqué en tant que Packages de messages sur la page de l'instance OIC dans la section Général sous l'onglet Détails.

Le nombre de messages autorisés par pack de messages varie en fonction de votre configuration et de votre utilisation OIC. Pour plus d'informations, reportez-vous à la documentation OIC.
Cluster Oracle Kubernetes (OKE) OCPU

Le calcul dépend de la taille du pool de noeuds et de la quantité d'OCPU affectée à chaque pool de noeuds pour le cluster OKE dans les deux régions. Un cluster OKE peut avoir plusieurs pools de noeuds. Par conséquent, le nombre total d'OCPU pour chaque région est la somme des résultats de tous les pools de noeuds de cette région.

La taille du pool de noeuds sur le cluster OKE principal (nps) est multipliée par le nombre d'OCPU affectées à ce pool de noeuds (npo). Effectuez ce calcul pour chaque pool de noeuds (pnsn+*pnon+) dans la région principale et additionnez les résultats de chacun pour atteindre un nombre total d'OCPU pour la région principale (poc).

La taille du pool de noeuds sur le cluster OKE de secours (sns) est multipliée par le nombre d'OCPU affectées à ce pool de noeuds (sno). Effectuez ce calcul pour chaque pool de noeuds (snsn+*snon+) dans la région principale et additionnez les résultats de chacun.

Ajoutez le nombre total d'OCPU à partir de la région principale et le nombre total d'OCPU à partir de la région de secours afin d'obtenir le nombre total d'OCPU pour OKE (vers).

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

Exemple :

  1. Calculer le nombre total d'OCPU dans la région principale
    • nps1 = La taille du pool de noeuds 1 est : 10
    • npo1 = Nombre d'OCPU du pool de noeuds 1 par noeud : 2
    • nps2 = La taille du pool de noeuds 2 est : 5
    • npo2 = Nombre d'OCPU du pool de noeuds 2 par noeud : 2
    • poc = nombre total d'OCPU pour la région principale : 30
  2. Calculer le nombre total d'OCPU dans la région de secours
    • nps1 = La taille du pool de noeuds 1 est : 10
    • npo1 = Nombre d'OCPU du pool de noeuds 1 par noeud : 2
    • nps2 = La taille du pool de noeuds 2 est : 5
    • npo2 = Nombre d'OCPU du pool de noeuds 2 par noeud : 2
    • soc = nombre total d'OCPU pour la région de secours : 30
  3. Calculer le nombre total d'OCPU dans les deux régions
    • poc = 30
    • soc = 30
    • to = Nombre total d'OCPU pour OKE : 60

Estimateur de coût

Oracle fournit un outil d'estimation des coûts facile à utiliser sur la page de produit Full Stack DR.

La récupération après sinistre Full Stack n'installe, ne configure ni ne déploie les ressources OCI telles que le calcul, le stockage, le réseau, les bases de données ou les applications. Vous êtes responsable de la conception de la stratégie de récupération après sinistre que Full Stack Disaster Recovery doit orchestrer. Vous êtes également responsable de la création, de la configuration et du déploiement de toutes les ressources OCI IaaS et PaaS en dehors du workflow de Full Stack Disaster Recovery. Par conséquent, vous devez déjà avoir une idée des ressources qui seront déployées dans les deux régions avant de commencer à travailler avec Full Stack Disaster Recovery. Cela signifie que l'estimateur de coût peut être utilisé avant que vous ayez déployé des ressources OCI dans l'une ou l'autre des régions OCI.

Remarques :

  • Il n'est pas nécessaire de calculer où les ressources existeront après une opération de récupération après sinistre. Il suffit de considérer les ressources là où elles existent dans l'état actuel, normal des opérations.
  • Pour la région principale, ajoutez les totaux d'OCPU et d'ECPU consommés par les ressources membres ou membres du groupe de protection de récupération après sinistre principal.
  • Pour la région de secours, ajoutez les totaux d'OCPU et d'ECPU consommés par les ressources membres ou membres du groupe de protection de récupération après sinistre de secours. Vous pouvez ou non disposer de ressources imputables en tant que membres du groupe de protection de secours. Par exemple, il est tout à fait possible qu'aucune ressource membre ne consomme d'UC dans le groupe de protection de secours si vous orchestrez uniquement la récupération pour déplacer le calcul.
Exemple 1 : pile d'applications avec uniquement le déplacement du calcul

L'exemple ci-dessous illustre un système métier fictif déployé dans deux régions OCI. Chaque client aura quelque chose de différent en fonction des services IaaS et PaaS qui font partie de la pile d'applications. Cet exemple montre comment estimer le coût de déplacement de calcul uniquement et d'aucune base de données. Dans ce scénario, les ressources OCI n'existent que dans une seule région à tout moment. Cette approche est similaire à celle utilisée par d'autres fournisseurs de services cloud pour la reprise après sinistre. Cette stratégie repose sur la réplication du stockage d'initialisation et de blocs de chaque machine virtuelle vers la région de secours. Par conséquent, vous n'ajouterez le nombre d'OCPU que pour la région dans laquelle les machines virtuelles sont en cours d'exécution.

L'évaluateur de coûts inclut six champs permettant de rattacher le nombre total d'OCPU et d'ECPU pour les ressources IaaS et PaaS dans chaque région. Le tableau suivant représente les six champs que vous devez renseigner dans l'estimateur de coût. Les valeurs des champs sont basées sur les détails affichés sous le tableau représentant une pile d'applications fictive déployée pour la récupération après sinistre dans deux régions OCI.

Tableau A-12 Région OCI principale/Groupe de protection

Nombre total d'OCPU de membre de calcul Nombre total d'OCPU de membre de base de données Nombre total d'ECP de membre de base de données Nombre total de packs de messages OIC
12 0 0 0

Tableau A-13 Groupe de protection/région OCI de secours

Nombre total d'OCPU de membre de calcul Nombre total d'OCPU de membre de base de données Nombre total d'ECP de membre de base de données Nombre total de packs de messages OIC
0 0 0 0

Tableau A-14 Totaux des métriques

Récupération après sinistre sur pile complète OCI (OCPU) Récupération après sinistre sur pile complète OCI (ECPU) Nombre total de packs de messages OIC
12 0 0

UC dans le groupe principal de protection de récupération après sinistre

Totalisez l'ensemble de l'UC consommée par les instances de calcul ou les bases de données membres du groupe de protection de récupération après sinistre dans la région principale (région 1).

Le tableau suivant présente un exemple des ressources IaaS et PaaS qui existent ou existeront dans la région principale. Les totaux de CPU dans la dernière ligne du tableau ci-dessous sont les chiffres présentés dans l'exemple d'estimateur de coût ci-dessus.

UC dans le groupe principal de protection de récupération après sinistre

Tableau A-15 CPU dans le groupe de protection de récupération après sinistre principal

Groupe de protection de récupération après sinistre Ressource membre Description Nombre d'OCPU de calcul Nombre d'OCPU de base de données Nombre d'ECPU de base de données Nombre de packs de messages OIC
Principal Instance de calcul (mobile)
  • Application non Oracle installée et gérée par le client
  • Serveur Web Apache pour le portail client
  • Application en cours d'exécution
 MyApp01Server01 4      
Principal Instance de calcul (mobile)
  • Application non Oracle installée et gérée par le client
  • Serveur Web Apache pour le portail client
  • Application en cours d'exécution
 MyApp01Server02 8      
Principal Equilibreur de charge
  • Ensemble de back-ends 1 actif
  • Ensemble de back-ends 2 actif
 MyLoadBalancerRegion1 Aucun frais Aucun frais Aucun frais  
Principal Groupe de volumes de blocs
  • Actif
  • Répliqué vers la région 2
  • Contient le volume d'initialisation pour MyApp01Server01
  • Contient le volume d'initialisation pour MyApp01Server02
 MyVG00 Aucun frais Aucun frais Aucun frais  
Principal Système de fichiers
  • Actif
  • Répliqué vers la région 2
  • Contient le système de fichiers pour les /myscripts montés sur MyApp01Server01 et MyApp01Server02
 mystiques Aucun frais Aucun frais Aucun frais  
Principal Total de toutes les OCPU et ECPU des ressources membres dans la région principale   12 0 0 0

CPU dans le groupe de protection de récupération après sinistre de secours

Totalisez l'ensemble de l'UC consommée par les instances de calcul ou les bases de données membres du groupe de protection de récupération après sinistre dans la région de secours (région 2).

Cet exemple inclut uniquement le calcul mobile qui n'existe que dans une seule région à un moment donné. Par conséquent, il n'existe aucune ressource membre facturable dans le groupe de protection de secours, ce qui signifie qu'aucun frais n'est engagé pour Full Stack Disaster Recovery dans la région de secours.

CPU dans le groupe de protection de récupération après sinistre de secours

Tableau A-16 UC du groupe de protection de récupération après sinistre de secours

Groupe de protection de récupération après sinistre Ressource membre Description Nombre d'OCPU de calcul Nombre d'OCPU de base de données Nombre d'ECPU de base de données Nombre de packs de messages OIC
De secours Equilibreur de charge
  • Ensemble de back-ends 1 non actif, non renseigné
  • Ensemble de back-ends 2not actif, non renseigné
 MyLoadBalancerRegion2 Aucun frais Aucun frais Aucun frais Aucun frais
De secours Total de toutes les OCPU et ECPU des ressources membres dans la région de secours   0 0 0 0

Exemple 2 : pile d'applications avec déplacement du calcul et des bases de données

L'exemple ci-dessous illustre un système métier fictif déployé dans deux régions OCI. Chaque client aura quelque chose de différent en fonction des services IaaS et PaaS qui font partie de la pile d'applications. Cet exemple montre comment estimer le coût de déplacement du calcul et de deux bases de données Oracle. Dans ce scénario, les ressources OCI de calcul existent uniquement dans une seule région alors que Data Guard est activé pour les deux bases de données, ce qui signifie qu'il existe des ressources OCI dans les deux régions. Cette approche est similaire à l'approche pilote légère utilisée par d'autres fournisseurs de services cloud pour la récupération après sinistre, à ceci près que vous pouvez inclure la base de données dans le cadre de la même récupération sans transférer de tâches à différentes équipes. Cette stratégie repose sur la réplication du stockage d'initialisation et de blocs de chaque machine virtuelle vers la région de secours. Par conséquent, vous n'ajouterez le nombre d'OCPU que pour la région dans laquelle les machines virtuelles sont en cours d'exécution. Pour les bases de données, vous allez ajouter des nombres d'OCPU et d'ECPU aux deux régions car des ressources sont en cours d'exécution dans les deux régions.

L'estimateur de coût inclut six champs permettant de connecter le nombre total d'OCPU et d'ECPU pour les ressources IaaS et PaaS dans chaque région. Le tableau suivant représente les six champs que vous devez renseigner dans l'estimateur de coût. Les valeurs des champs sont basées sur les détails indiqués dans le tableau suivant représentant une pile d'applications fictives déployée pour la récupération après sinistre dans deux régions OCI.

Région OCI/Groupe de protection principal

Tableau A-17 Région OCI principale/Groupe de protection

Nombre total d'OCPU de membre de calcul Nombre total d'OCPU de membre de base de données Nombre total d'ECP de membre de base de données Nombre total de packs de messages OIC
12 16 16 0
Région OCI de secours/groupe de protection

Tableau A-18 Groupe de protection/région OCI de secours

Nombre total d'OCPU de membre de calcul Nombre total d'OCPU de membre de base de données Nombre total d'ECP de membre de base de données Nombre total de packs de messages OIC
0 16 16 0
Totaux de mesure

Tableau A-19 Totaux des métriques

Récupération après sinistre sur pile complète OCI (OCPU) Récupération après sinistre sur pile complète OCI (ECPU) Nombre total de packs de messages OIC
44 32 0

UC dans le groupe principal de protection de récupération après sinistre

Totalisez l'ensemble de l'UC consommée par les instances de calcul ou les bases de données membres du groupe de protection de récupération après sinistre dans la région principale (région 1).

Le tableau suivant présente un exemple des ressources IaaS et PaaS qui existent ou existeront dans la région principale. Les totaux de CPU dans la dernière ligne du tableau ci-dessous sont les chiffres présentés dans l'exemple d'estimateur de coût ci-dessus.

UC dans le groupe principal de protection de récupération après sinistre

Tableau A-20 CPU dans le groupe de protection de récupération après sinistre principal

Groupe de protection de récupération après sinistre Ressource membre Description Nombre d'OCPU de calcul Nombre d'OCPU de base de données Nombre d'ECPU de base de données Nombre de packs de messages OIC
Principal Instance de calcul (mobile)
  • Application non Oracle installée et gérée par le client
  • Serveur Web Apache pour le portail client
  • Application en cours d'exécution
 MyApp01Server01 4      
Principal Instance de calcul (mobile)
  • Application non Oracle installée et gérée par le client
  • Serveur Web Apache pour le portail client
  • Application en cours d'exécution
 MyApp01Server02 8      
Principal Oracle Database
  • Cluster de machines virtuelles Exadata
  • Data Guard dans le rôle principal
  • 64 OCPU au total allouées au cluster de machines virtuelles
  • 4 bases de données provisionnées dans le cluster de machines virtuelles
  • 16 OCPU par base de données : (64/4 = 16 OCPU par base de données)
 MyExaDatabase03   16    
Principal Autonomous Database
  • Infrastructure dédiée
  • Autonomous Data Guard dans le rôle principal
 MyADB01     16  
Principal Equilibreur de charge
  • Ensemble de back-ends 1 actif
  • Ensemble de back-ends 2 actif
 MyLoadBalancerRegion1 Aucun frais Aucun frais Aucun frais  
Principal Groupe de volumes de blocs
  • Actif
  • Répliqué vers la région 2
  • Contient le volume d'initialisation pour MyApp01Server01
  • Contient le volume d'initialisation pour MyApp01Server02
 MyVG00 Aucun frais Aucun frais Aucun frais  
Principal Système de fichiers
  • Actif
  • Répliqué vers la région 2
  • Contient le système de fichiers pour les /myscripts montés sur MyApp01Server01 et MyApp01Server02
 mystiques Aucun frais Aucun frais Aucun frais  
Principal Total de toutes les OCPU et ECPU des ressources membres dans la région principale   12 16 16 0

UC dans le groupe de protection de récupération après sinistre de secours

Totalisez l'ensemble de l'UC consommée par les instances de calcul ou les bases de données membres du groupe de protection de récupération après sinistre dans la région de secours (région 2).

Cet exemple inclut uniquement le calcul mobile qui n'existe que dans une seule région à un moment donné. Par conséquent, il n'existe aucune ressource membre facturable dans le groupe de protection de secours, ce qui signifie qu'aucun frais n'est engagé pour Full Stack Disaster Recovery dans la région de secours.

CPU dans le groupe de protection de récupération après sinistre de secours

Tableau A-21 CPU dans le groupe de protection de récupération après sinistre de de secours

Groupe de protection de récupération après sinistre Ressource membre Description Nombre d'OCPU de calcul Nombre d'OCPU de base de données Nombre d'ECPU de base de données Nombre de packs de messages OIC
De secours Oracle Database
  • Cluster de machines virtuelles Exadata avec 64 OCPU au total
  • Data Guard dans le rôle principal
  • 64 OCPU au total allouées au cluster de machines virtuelles
  • 4 bases de données provisionnées dans le cluster de machines virtuelles
  • 16 OCPU par base de données : (64/4 = 16 OCPU par base de données)
 MyExaDatabase03   16    
De secours Autonomous Database
  • Infrastructure dédiée
  • Data Guard dans le rôle de secours
 MyADB01     16  
De secours Equilibreur de charge
  • Ensemble de back-ends 1 non actif, non renseigné
  • Ensemble de back-ends 2 non actif, non renseigné
 MyLoadBalancerRegion2 Aucun frais Aucun frais Aucun frais  
De secours Total de toutes les OCPU et ECPU des ressources membres dans la région de secours   0 16 16 0

Exemple 3 : pile d'applications avec calcul mobile et non mobile

L'exemple ci-dessous illustre un système métier fictif déployé dans deux régions OCI. Chaque client dispose de quelque chose de différent en fonction des services IaaS et PaaS qui font partie de la pile d'applications.

Cet exemple montre comment tarifer Full Stack DR lorsque des bases de données compatibles avec Data Guard sont membres de groupes de protection de récupération après sinistre dans les deux régions. Voici un exemple simple de la raison et de la façon dont vous pouvez utiliser le calcul mobile pour des applications non Oracle et Oracle telles qu'E-Business Suite, PeopleSoft, JD Edwards EnterpriseOne et d'autres qui n'ont pas leurs propres fonctionnalités de récupération après sinistre inhérentes intégrées à leurs produits. Ces produits nécessitent généralement que l'application soit installée sur des machines virtuelles qui existent et s'exécutent simultanément dans les deux régions. L'application est installée dans les deux régions mais n'est pas en cours d'exécution dans la région de secours.

A des fins d'illustration, cet exemple utilise un total de quatre instances de calcul :

  • Deux instances de calcul standard agissent comme des serveurs de "déplacement" pour une application qui tolère le déplacement entre les régions.
    • Des exemples d'applications qui peuvent être installées sur ces serveurs sont celles qui ne conservent pas de valeurs codées en dur avec conservation de statut, spécifiques à une région, dans des fichiers binaires ou des fichiers de configuration et peuvent facilement tolérer d'être démarrées dans une autre région avec une adresse IP différente et mineure, ou aucune modification des fichiers de configuration au démarrage.
    • Ces instances de calcul seront membres du groupe de protection de récupération après sinistre principal uniquement.
  • Une instance de calcul standard fait office de serveur d'applications actif "non mobile".
    • Cette instance de calcul existe uniquement dans la région 1 et n'existera jamais dans la région 2.
    • L'application est installée et en cours d'exécution dans la région 1.
    • Cette instance de calcul sera membre du groupe de protection de récupération après sinistre principal uniquement.
  • Une instance de calcul standard fait office de serveur d'applications non actif "non mobile".
    • Cette instance de calcul existe uniquement dans la région 2 et n'existera jamais dans la région 1.
    • L'application est installée, mais n'est pas en cours d'exécution dans la région 2.
    • Cette instance de calcul sera membre du groupe de protection de récupération après sinistre de secours uniquement.
  • Une base de données Oracle avec Data Guard déjà activé à l'aide de la console OCI.
    • La base de données principale est membre du groupe de protection de récupération après sinistre principal uniquement.
    • La base de données de secours est membre du groupe de protection de récupération après sinistre de secours uniquement.

L'estimateur de coût inclut six champs permettant de connecter le nombre total d'OCPU et d'ECPU pour les ressources IaaS et PaaS dans chaque région. Le tableau suivant représente les six champs que vous devez renseigner dans l'estimateur de coût. Les valeurs des champs sont basées sur les détails indiqués dans le tableau suivant représentant une pile d'applications fictives déployée pour la récupération après sinistre dans deux régions OCI. Aucun coût n'est associé aux bases de données gérées et installées par l'utilisateur. Le coût est plutôt pris en compte par l'OPCU utilisée par les machines virtuelles hébergeant la base de données et Data Guard.

Région OCI/Groupe de protection principal

Tableau A-22 Région OCI principale/Groupe de protection

Nombre total d'OCPU de membre de calcul Nombre total d'OCPU de membre de base de données Nombre total d'ECP de membre de base de données
14 16 0
Région OCI de secours/groupe de protection

Tableau A-23 Groupe de protection/région OCI de secours

Nombre total d'OCPU de membre de calcul Nombre total d'OCPU de membre de base de données Nombre total d'ECP de membre de base de données
2 16 0
Totaux de mesure

Tableau A-24 Totaux des métriques

Récupération après sinistre sur pile complète OCI (OCPU) Récupération après sinistre sur pile complète OCI (ECPU)
48 0

UC dans le groupe principal de protection de récupération après sinistre

Totalisez l'ensemble de l'UC consommée par les instances de calcul ou les bases de données membres du groupe de protection de récupération après sinistre dans la région principale (région 1).

Le tableau suivant présente un exemple des ressources IaaS et PaaS qui existent ou existeront dans la région principale. Les totaux de CPU dans la dernière ligne du tableau ci-dessous sont les chiffres présentés dans l'exemple d'estimateur de coût ci-dessus.

UC dans le groupe principal de protection de récupération après sinistre

Tableau A-25 CPU du groupe de protection de récupération après sinistre principal

Groupe de protection de récupération après sinistre Ressource membre Description Nombre d'OCPU de calcul Nombre d'OCPU de base de données Nombre d'ECPU de base de données Nombre de packs de messages OIC
Principal Instance de calcul (mobile)
  • Application non Oracle installée et gérée par le client
  • Serveur Web Apache pour le portail client
  • Application en cours d'exécution
 MyApp01Server01 4      
Principal Instance de calcul (mobile)
  • Application non Oracle installée et gérée par le client
  • Serveur Web Apache pour le portail client
  • Application en cours d'exécution
 MyApp01Server02 8      
Principal Instance de calcul (non mobile)
  • Application Oracle installée et gérée par le client, telle qu'Oracle Siebel CRM, PeopleSoft, JD Edwards EnterpriseOne, Oracle E-business Suite, etc.
  • Application en cours d'exécution
 MyApp02Server01 2      
Principal Oracle Database
  • Base de données principale de l'application Oracle exécutée sur MyApp02Server01
  • Cluster de machines virtuelles Exadata
  • Data Guard dans le rôle principal
  • 64 OCPU au total allouées au cluster de machines virtuelles
  • 4 bases de données provisionnées dans le cluster de machines virtuelles
  • 16 OCPU par base de données : (64/4 = 16 OCPU par base de données)
 MyExaDatabase03   16    
Principal Equilibreur de charge
  • Ensemble de back-ends 1 actif
  • Ensemble de back-ends 2 actif
 MyLoadBalancerRegion1 Aucun frais Aucun frais Aucun frais  
Principal Groupe de volumes de blocs
  • Actif
  • Répliqué vers la région 2
  • Contient le volume d'initialisation pour MyApp01Server01
  • Contient le volume d'initialisation pour MyApp01Server02
 MyVG00 Aucun frais Aucun frais Aucun frais  
Principal Système de fichiers
  • Actif
  • Répliqué vers la région 2
  • Contient le système de fichiers pour les /myscripts montés sur MyApp01Server01 et MyApp01Server02
 mystiques Aucun frais Aucun frais Aucun frais  
Principal Total de toutes les OCPU et ECPU des ressources membres dans la région principale   14 16 0 0
UC dans le groupe de protection de récupération après sinistre de secours

Totalisez l'ensemble de l'UC consommée par les instances de calcul ou les bases de données membres du groupe de protection de récupération après sinistre dans la région de secours (région 2).

Cet exemple inclut uniquement le calcul mobile qui n'existe que dans une seule région à un moment donné. Par conséquent, il n'existe aucune ressource membre facturable dans le groupe de protection de secours, ce qui signifie qu'aucun frais n'est engagé pour Full Stack Disaster Recovery dans la région de secours.

CPU dans le groupe de protection de récupération après sinistre de secours

Tableau A-26 CPU du groupe de protection de récupération après sinistre de secours

Groupe de protection de récupération après sinistre Ressource membre Description Nombre d'OCPU de calcul Nombre d'OCPU de base de données Nombre d'ECPU de base de données Nombre de packs de messages OIC
De secours Instance de calcul (non mobile).
  • Application Oracle installée et gérée par le client, telle qu'Oracle Siebel CRM, PeopleSoft, JD Edwards EnterpriseOne, Oracle E-business Suite, etc.
  • Application installée, mais pas en cours d'exécution
 MyApp02Server02 2 0 0  
De secours Oracle Database
  • Base de données de secours pour l'application Oracle exécutée sur MyApp02Server02
  • Cluster de machines virtuelles Exadata
  • Data Guard dans le rôle de secours
  • 64 OCPU au total allouées au cluster de machines virtuelles
  • 4 bases de données provisionnées dans le cluster de machines virtuelles
  • 16 OCPU par base de données : (64/4 = 16 OCPU par base de données)
 MyExaDatabase03   16    
De secours Equilibreur de charge
  • Ensemble de back-ends 1 non actif, non renseigné
  • Ensemble de back-ends 2not actif, non renseigné
 MyLoadBalancerRegion2 Aucun frais Aucun frais Aucun frais  
De secours Total de toutes les OCPU et ECPU des ressources membres dans la région de secours   2 16 0 0

Exemple 4 : pile d'applications avec OKE, base de données, Oracle Integration, déplacement de calcul et calcul non mobile

L'exemple ci-dessous illustre un système métier fictif déployé dans deux régions OCI. Chaque client dispose de quelque chose de différent en fonction des services IaaS et PaaS qui font partie de la pile d'applications.

Cet exemple illustre la tarification de Full Stack DR pour un système métier qui inclut des noeuds de processus actif hébergés sur un cluster Oracle Kubernetes Engine (OKE), ainsi que le déplacement et la non-déplacement du calcul en tant que membres des groupes de protection de récupération après sinistre dans les deux régions. Il s'agit d'un exemple à petite échelle d'architecture de déploiement plus typique pour un système métier qui peut héberger une pile d'applications pour toute application non Oracle ou Oracle pour la planification des ressources, la finance, la gestion des entrepôts, la gestion de la chaîne d'approvisionnement, la gestion de la relation client, le portail de vente, etc. Le calcul mobile peut être utilisé pour héberger des applications Oracle ou non Oracle qui peuvent fonctionner avec un minimum de modifications lorsqu'elles sont affichées dans une autre région. Le calcul non mobile est normalement utilisé pour héberger des applications Oracle ou non Oracle qui ne peuvent pas fonctionner ou qui peuvent être facilement modifiées pour fonctionner lorsqu'elles sont affichées dans une autre région. Les applications Oracle telles que PeopleSoft, JD Edwards EnterpriseOne, Oracle Siebel CRM, Oracle E-Business Suite, Oracle WebLogic Server, etc. peuvent être installées sur des instances de calcul non mobiles. Ces applications doivent être installées et exécutées activement sur des machines virtuelles dans la région principale, et installées, mais pas actives sur des machines virtuelles exécutées dans la région de secours.

A des fins d'illustration, cet exemple utilise un total de quatre instances de calcul standard, quatre noeuds de processus actif OKE, ainsi que plusieurs bases de données Oracle différentes, y compris Autonomous Database, Base Database et Exadata, qui sont toutes récupérées dans une seule exécution de plan de récupération après sinistre :

  • Deux instances de calcul standard agissent comme des serveurs de "déplacement" pour une application qui tolère le déplacement entre les régions.
    • Des exemples d'applications qui peuvent être installées sur ces serveurs sont celles qui ne conservent pas de valeurs codées en dur avec conservation de statut, spécifiques à une région, dans des fichiers binaires ou des fichiers de configuration et peuvent facilement tolérer d'être démarrées dans une autre région avec une adresse IP différente et mineure, ou aucune modification des fichiers de configuration au démarrage.
    • Ces instances de calcul seront membres du groupe de protection de récupération après sinistre principal uniquement.
  • Une instance de calcul standard fait office de serveur d'applications actif "non mobile".
    • Cette instance de calcul existe uniquement dans la région 1 et n'existera jamais dans la région 2.
    • L'application est installée et en cours d'exécution dans la région 1.
    • Cette instance de calcul sera membre du groupe de protection de récupération après sinistre principal uniquement.
  • Une instance de calcul standard fait office de serveur d'applications non actif "non mobile".
    • Cette instance de calcul existe uniquement dans la région 2 et n'existera jamais dans la région 1.
    • L'application est installée, mais n'est pas en cours d'exécution dans la région 2.
    • Cette instance de calcul sera membre du groupe de protection de récupération après sinistre de secours uniquement.
  • Quatre noeuds de processus actif dans le cluster OKE qui hébergent les charges globales d'application à récupérer.
    • Quatre noeuds de processus actif dans le cluster OKE de la région principale, qui reste toujours membre du groupe de protection de récupération après sinistre principal uniquement.
    • Quatre noeuds de processus actif dans le cluster OKE de la région de secours, qui reste toujours membre du groupe de protection de récupération après sinistre de secours uniquement.
  • Quatre bases de données OCI Oracle avec Data Guard déjà activées à l'aide de la console OCI qui prend en charge les différentes applications.
    • Les quatre bases de données principales seront membres du groupe de protection de récupération après sinistre principal uniquement.
    • Les quatre bases de données de secours seront membres du groupe de protection de récupération après sinistre de secours uniquement.
  • Une instance Oracle Integration déjà créée et déployée pour la récupération après sinistre à l'aide du commutateur Activer la récupération après sinistre sous Options avancées lors de la création d'une instance Oracle Integration.
    • Une instance dotée du rôle de récupération après sinistre principal sera membre du groupe de protection de récupération après sinistre principal uniquement.
    • Une instance ayant le rôle de récupération après sinistre secondaire sera membre du groupe de protection de récupération après sinistre de secours uniquement.

L'estimateur de coût inclut six champs permettant de connecter le nombre total d'OCPU et d'ECPU pour les ressources IaaS et PaaS dans chaque région. Le tableau suivant représente les six champs que vous devez renseigner dans l'estimateur de coût. Les valeurs des champs sont basées sur les détails indiqués dans le tableau suivant représentant une pile d'applications fictives déployée pour la récupération après sinistre dans deux régions OCI.

Région OCI/Groupe de protection principal

Tableau A-27 Région OCI principale/Groupe de protection

Nombre total d'OCPU de membre de calcul Nombre total d'OCPU de membre de base de données Nombre total d'ECP de membre de base de données Nombre total de packs de messages OIC
22 24 20 2
Région OCI de secours/groupe de protection

Tableau A-28 Groupe de protection/région OCI de secours

Nombre total d'OCPU de membre de calcul Nombre total d'OCPU de membre de base de données Nombre total d'ECP de membre de base de données Nombre total de packs de messages OIC
10 24 20 2

Totaux de mesure

Tableau A-29 Totaux de mesure

Récupération après sinistre sur pile complète OCI (OCPU) Nombre total d'OCPU de membre de base de données Nombre total de packs de messages OIC
80 40 4

UC dans le groupe principal de protection de récupération après sinistre

Totalisez l'ensemble de l'UC consommée par les instances de calcul ou les bases de données membres du groupe de protection de récupération après sinistre dans la région principale (région 1).

Le tableau suivant présente un exemple des ressources IaaS et PaaS qui existent ou existeront dans la région principale. Les totaux de CPU dans la dernière ligne du tableau ci-dessous sont les chiffres présentés dans l'exemple d'estimateur de coût ci-dessus.

Tableau A-30 CPU dans le groupe de protection de récupération après sinistre principal

Groupe de protection de récupération après sinistre Ressource membre Description Nombre d'OCPU de calcul Nombre d'OCPU de base de données Nombre d'ECPU de base de données Nombre de packs de messages OIC
Principal Instance de calcul (mobile)
  • Application non Oracle installée et gérée par le client
  • Serveur Web Apache pour le portail client
  • Application en cours d'exécution
 MyApp01Server01 4      
Principal Instance de calcul (mobile)
  • Application non Oracle installée et gérée par le client
  • Serveur Web Apache pour le portail client
  • Application en cours d'exécution
 MyApp01Server02 8      
Principal Instance de calcul (non mobile)
  • Application Oracle installée et gérée par le client, telle qu'Oracle Siebel CRM, PeopleSoft, JD Edwards EnterpriseOne, Oracle E-business Suite, etc.
  • Application en cours d'exécution
 MyApp02Server01 2      
Principal Cluster OKE : 4 noeuds de processus actif avec 2 OCPU chacun MyOKECluster01 8      
Principal Oracle Database :
  • Base de données Base
  • Data Guard dans le rôle principal
 MyEEDatabase01   8    
Principal Oracle Database :
  • Base de données principale de l'application Oracle exécutée sur MyApp02Server01
  • Cluster de machines virtuelles Exadata
  • Data Guard dans le rôle principal
  • 64 OCPU au total allouées au cluster de machines virtuelles
  • 4 bases de données provisionnées dans le cluster de machines virtuelles
  • 16 OCPU par base de données : (64/4 = 16 OCPU par base de données)
 MyExaDatabase03   16    
Principal Autonomous Database
  • Infrastructure dédiée
  • Autonomous Data Guard dans le rôle principal
 MyADB01     16  
Principal Autonomous Database
  • Infrastructure sans serveur
  • Autonomous Data Guard dans le rôle principal
 MyADW01     4  
Principal Récupération après sinistre en un clic OIC (récupération après sinistre gérée par Oracle) MyOIC01       2
Principal Equilibreur de charge
  • Ensemble de back-ends 1 actif
  • Ensemble de back-ends 2 actif
 MyLoadBalancerRegion1 Aucun frais Aucun frais Aucun frais  
Principal Groupe de volumes de blocs
  • Actif
  • Répliqué vers la région 2
  • Contient le volume d'initialisation pour MyApp01Server01
  • Contient le volume d'initialisation pour MyApp01Server02
 MyVG00 Aucun frais Aucun frais Aucun frais  
Principal Groupe de volumes de blocs :
  • Actif
  • Répliqué vers la région 2
  • Contient un volume de blocs pour /u02 onMyApp02Server01
  • Remonté vers /u02 sur MyApp02Server02 dans region2 lors de la récupération
 MyVG01 Aucun frais Aucun frais Aucun frais  
Principal Système de fichiers:
  • Actif
  • Répliqué vers la région 2
  • Contient le système de fichiers pour les /myscripts montés sur MyApp01Server01 et MyApp01Server02
 mystiques Aucun frais Aucun frais Aucun frais  
Principal Total de toutes les OCPU et ECPU des ressources membres dans la région principale   22 24 20 2

UC dans le groupe de protection de récupération après sinistre de secours

Totalisez l'ensemble de l'UC consommée par les instances de calcul ou les bases de données membres du groupe de protection de récupération après sinistre dans la région de secours (région 2).

Incluez uniquement les ressources membres qui existent actuellement dans la région de secours. Vous n'avez pas besoin de calculer où les ressources existeront après une opération de récupération après sinistre. Ajoutez simplement les ressources là où elles existent dans l'état normal actuel des opérations. Le calcul mobile dans la région principale n'est pas inclus en tant que membres du groupe de protection de récupération après sinistre de secours. Par conséquent, aucun frais d'OCPU n'est facturé pour le déplacement du calcul dans la région de secours.

Tableau A-31 UC du groupe de protection de récupération après sinistre de secours

Groupe de protection de récupération après sinistre Ressource membre Description Nombre d'OCPU de calcul Nombre d'OCPU de base de données Nombre d'ECPU de base de données Nombre de packs de messages OIC
De secours Instance de calcul (non mobile)
  • Application Oracle installée et gérée par le client, telle qu'Oracle Siebel CRM, PeopleSoft, JD Edwards EnterpriseOne, Oracle E-business Suite, etc.
  • Application installée, mais pas en cours d'exécution
 MyApp02Server02 2      
De secours Cluster OKE : 4 noeuds de processus actif avec 2 OCPU chacun MyOKECluster01 8      
De secours Oracle Database :
  • Base de données Base
  • Data Guard dans le rôle de secours
, 		MyEEDatabase01   8    
De secours Oracle Database :
  • Base de données de secours pour l'application Oracle exécutée sur MyApp02Server02
  • Cluster de machines virtuelles Exadata
  • Data Guard dans le rôle de secours
  • 64 OCPU au total allouées au cluster de machines virtuelles
  • 4 bases de données provisionnées dans le cluster de machines virtuelles
  • 16 OCPU par base de données : (64/4 = 16 OCPU par base de données)
 MyExaDatabase03   16    
De secours Autonomous Database :
  • Infrastructure dédiée
  • Data Guard dans le rôle de secours
 MyADB01     16  
De secours Récupération après sinistre en un clic OIC (récupération après sinistre gérée par Oracle) MyOIC01_Recovery       2
De secours Autonomous Database :
  • Infrastructure sans serveur
  • Data Guard dans le rôle de secours
 MyADW01     4  
De secours Equilibreur de charge:
  • Ensemble de back-ends 1 non actif, non renseigné
  • Ensemble de back-ends 2not actif, non renseigné
 MyLoadBalancerRegion2 Aucun frais   Aucun frais  
De secours Total de toutes les OCPU et ECPU des ressources membres dans la région de secours   10 24 20 2

Rubrique parent : Référence