Détails de facturation RS de pile complète

Calcul de la facturation pour une configuration RS

Ressources de membre qui entraînent des frais

La récupération après sinistre de pile complète utilise uniquement les ensembles de messages OCPU, ECPU ou OIC affectés comme base de calcul des frais. Les frais pour la récupération après sinistre de pile complète sont comptabilisés pour tous les membres de calcul, de base de données ou d'Oracle Integration d'un groupe de protection RS, 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 qui entraînent des frais

Détermination de la consommation des ressources

Le tableau suivant montre comment la consommation des ressources est déterminée pour divers types de ressource de membre OCI qui entraînent des frais horaires pour la récupération après sinistre de pile complète. La détermination de l'ensemble de messages OIC et de la consommation du processeur pour la plupart des types de ressource OCI est simple et basée sur ce qui est affiché dans la page de détails pour chaque ressource individuelle de la console OCI. Toutefois, certaines ressources, comme certaines bases de données Oracle, qui n'affichent pas la consommation du processeur pour des bases de données individuelles, sont dérivées du total agrégé d'UC consommé par la grappe de machines virtuelles.

Évaluateur de coût

Oracle fournit un outil d'estimation des coûts facile à utiliser sur la page de produit de récupération après sinistre de pile complète.

La récupération après sinistre de pile complète 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 vous voulez orchestrer la récupération après sinistre de pile complète. 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 flux de travail pour la récupération après sinistre de pile complète. 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 à utiliser la récupération après sinistre de pile complète. Cela signifie que l'estimateur de coûts peut être utilisé avant que vous ayez réellement déployé des ressources OCI dans l'une ou l'autre des régions OCI.

Points à considérer :

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

L'évaluateur de coût inclut six champs pour brancher 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 remplir dans l'évaluateur 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 fictives déployée pour la récupération après sinistre dans deux régions OCI.

Totaliser l'ensemble de l'UC consommée par les instances de calcul ou les bases de données qui sont membres du groupe de protection RS de 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 CPU de la dernière ligne du tableau ci-dessous sont les chiffres indiqués dans l'exemple de l'estimateur de coûts ci-dessus.

UC dans le groupe de protection RS de secours

Totaliser l'ensemble de l'UC consommée par les instances de calcul ou les bases de données qui sont membres du groupe de protection RS de la région de secours (région 2).

Cet exemple n'inclut que le déplacement du calcul qui n'existe que dans une seule région à un moment donné. Par conséquent, il n'y a pas de ressources membres facturables dans le groupe de protection de secours, ce qui signifie qu'aucun frais n'est engagé pour la récupération après sinistre de pile complète dans la région de secours.

L'exemple ci-dessous montre un système d'affaires fictif déployé dans deux régions OCI. Chaque client aura quelque chose de différent selon les services IaaS et PaaS qui font partie de la pile d'applications. Cet exemple montre comment estimer le coût du déplacement du calcul et de deux bases de données Oracle. Dans ce scénario, les ressources OCI de calcul n'existent que 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. Ceci est similaire à l'approche pilote légère utilisée par d'autres fournisseurs de services cloud pour la reprise après sinistre, sauf que vous pouvez inclure la base de données dans le cadre de la même récupération sans transférer les tâches à différentes équipes. Cette stratégie repose sur la réplication du stockage de démarrage et du stockage par blocs pour chaque machine virtuelle dans la région de secours, de sorte que vous n'ajoutez que le nombre d'OCPU pour la région où 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 s'exécutent dans les deux régions.

L'estimateur de coûts comprend six champs pour 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 remplir dans l'estimateur de coûts. Les valeurs des champs sont basées sur les détails présentés dans le tableau suivant représentant une pile d'applications fictive déployée pour la récupération après sinistre dans deux régions OCI.

Totaliser l'ensemble de l'UC consommée par les instances de calcul ou les bases de données qui sont membres du groupe de protection RS de 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 CPU de la dernière ligne du tableau ci-dessous sont les chiffres indiqués dans l'exemple de l'estimateur de coûts ci-dessus.

Totaliser l'ensemble de l'UC consommée par les instances de calcul ou les bases de données qui sont membres du groupe de protection RS de la région de secours (région 2).

Cet exemple n'inclut que le déplacement du calcul qui n'existe que dans une seule région à un moment donné. Par conséquent, il n'y a pas de ressources membres facturables dans le groupe de protection de secours, ce qui signifie qu'aucun frais n'est engagé pour la récupération après sinistre de pile complète dans la région de secours.

L'exemple ci-dessous présente un système d'affaires fictif déployé sur deux régions OCI. Chaque client aura quelque chose de différent selon les services IaaS et PaaS qui font partie de la pile d'applications.

Cet exemple montre comment tarifer la reprise après sinistre de pile complète lorsque des bases de données mobiles, non mobiles et activées pour Data Guard multiples sont membres de groupes de protection RS dans les deux régions. Il s'agit d'un exemple simple de pourquoi et de comment utiliser le calcul sans déplacement pour des applications non Oracle et Oracle comme E-Business Suite, PeopleSoft, JD Edwards EnterpriseOne et d'autres qui n'ont pas leurs propres capacités de reprise après sinistre inhérentes intégrées à leurs produits. Ces produits exigent généralement que l'application soit installée sur des machines virtuelles qui existent et qui s'exécutent simultanément dans les deux régions; l'application est installée dans les deux régions, mais ne s'exécute pas dans la région de secours.

Pour l'illustration, cet exemple utilise un total de quatre instances de calcul :

L'estimateur de coûts comprend six champs pour 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 remplir dans l'estimateur de coûts. Les valeurs des champs sont basées sur les détails présentés dans le tableau suivant représentant une pile d'applications fictive déployée pour la récupération après sinistre dans deux régions OCI. Notez qu'aucun coût n'est associé aux bases de données installées et gérées par l'utilisateur. Le coût est plutôt pris en compte par l'OPCU consommée par les machines virtuelles hébergeant la base de données et Data Guard.

Totaliser l'ensemble de l'UC consommée par les instances de calcul ou les bases de données qui sont membres du groupe de protection RS de 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 CPU de la dernière ligne du tableau ci-dessous sont les chiffres indiqués dans l'exemple de l'estimateur de coûts ci-dessus.

Totaliser l'ensemble de l'UC consommée par les instances de calcul ou les bases de données qui sont membres du groupe de protection RS de la région de secours (région 2).

Cet exemple n'inclut que le déplacement du calcul qui n'existe que dans une seule région à un moment donné. Par conséquent, il n'y a pas de ressources membres facturables dans le groupe de protection de secours, ce qui signifie qu'aucun frais n'est engagé pour la récupération après sinistre de pile complète dans la région de secours.

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

L'exemple ci-dessous présente un système d'affaires fictif déployé sur deux régions OCI. Chaque client aura quelque chose de différent selon les services IaaS et PaaS qui font partie de la pile d'applications.

Cet exemple montre comment tarifer la reprise après sinistre de pile complète pour un système d'affaires qui inclut des noeuds de travail hébergés sur une grappe Oracle Kubernetes Engine (OKE), ainsi que le calcul mobile et non mobile en tant que membres de groupes de protection RS dans les deux régions. Il s'agit d'un exemple à petite échelle d'architecture de déploiement plus typique pour un système d'affaires qui peut héberger une pile d'applications pour toute application autre qu'Oracle ou Oracle pour la planification des ressources, les finances, la gestion d'entrepôts, la gestion de la chaîne d'approvisionnement, la gestion des relations avec la clientèle, le portail des ventes, etc. Le calcul en mouvement peut être utilisé pour héberger des applications Oracle ou non Oracle qui peuvent fonctionner avec des modifications minimes lorsqu'elles sont apporté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 présenté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. sont des exemples d'applications qui peuvent être installées sur des instances de calcul non mobiles. Ces applications doivent être installées et s'exécuter activement sur des machines virtuelles dans la région principale, et installées, mais non actives sur des machines virtuelles s'exécutant dans la région de secours.

À des fins d'illustration, cet exemple utilise un total de quatre instances de calcul standard, quatre noeuds de travail OKE, plus plusieurs bases de données Oracle différentes, notamment Autonomous Database, Base de données de base et Exadata, qui sont toutes récupérées dans une seule exécution de plan RS :

L'estimateur de coûts comprend six champs pour 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 remplir dans l'estimateur de coûts. Les valeurs des champs sont basées sur les détails présentés dans le tableau suivant représentant une pile d'applications fictive déployée pour la récupération après sinistre dans deux régions OCI.

Totaux des mesures

UC du groupe de protection RS principal

Totaliser l'ensemble de l'UC consommée par les instances de calcul ou les bases de données qui sont membres du groupe de protection RS de 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 CPU de la dernière ligne du tableau ci-dessous sont les chiffres indiqués dans l'exemple de l'estimateur de coûts ci-dessus.

UC du groupe de protection RS de secours

Totaliser l'ensemble de l'UC consommée par les instances de calcul ou les bases de données qui sont membres du groupe de protection RS de la région de secours (région 2).

N'incluez que 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, il vous suffit d'ajouter les ressources là où elles existent dans l'état courant et normal des opérations. Le calcul en déplacement dans la région principale n'est pas inclus en tant que membres du groupe de protection RS de secours. Par conséquent, il n'y a pas de frais d'OCPU pour le déplacement du calcul dans la région de secours.