Detalhes de Faturamento do Full Stack DR

Como o Faturamento é Calculado para uma Configuração de DR

Recursos membros que incorrem em cobranças

O Full Stack DR só usa pacotes de mensagens de OCPU, ECPU ou OIC alocados como base para calcular cobranças. As cobranças do Full Stack DR são acumuladas para qualquer membro de computação, banco de dados ou Oracle Integration de um Grupo de Proteção de DR, independentemente de o recurso estar em execução ou interrompido. Por exemplo, uma instância de computação não móvel que existe na região stand-by, mas está sempre em um estado interrompido até que uma operação de DR seja executada, ainda acumulará cobranças por hora, mesmo que ela não esteja em execução.

Recursos do OCI que incorrem em cobranças

Determinação do consumo de recursos

A tabela a seguir mostra como o consumo de recursos é determinado para vários tipos de recursos de membros do OCI que incorrem em cobranças por hora para o Full Stack DR. A determinação do consumo de pacotes de mensagens e processadores do OIC para a maioria dos tipos de recursos do OCI é direta e baseada no que é visto na página de detalhes de cada recurso individual na console do OCI. No entanto, alguns recursos, como alguns bancos de dados Oracle que não mostram o consumo do processador para bancos de dados individuais, são derivados do total agregado de CPU consumida pelo cluster de VMs.

Estimador de custos

A Oracle fornece uma ferramenta de estimativa de custos fácil de usar na página do produto Full Stack DR.

A recuperação completa de desastres de pilha não instala, configura ou implanta recursos da OCI, como computação, armazenamento, rede, bancos de dados ou aplicativos. Você é responsável por projetar a estratégia de recuperação de desastres que deseja que o Full Stack Disaster Recovery orquestre e também é responsável por criar, configurar e implantar todos os recursos OCI IaaS e PaaS fora do workflow do Full Stack Disaster Recovery. Portanto, você já deve ter alguma ideia dos recursos que serão implantados em ambas as regiões antes de começar a trabalhar com o Full Stack Disaster Recovery. Isso significa que o estimador de custos pode ser usado antes de você realmente implantar qualquer recurso do OCI em qualquer uma das regiões do OCI.

Considerações:

O exemplo abaixo mostra um sistema de negócios fictício implantado em duas regiões da OCI. Cada cliente terá algo diferente, dependendo dos serviços IaaS e PaaS que fazem parte da pilha de aplicativos. Este exemplo mostra como estimar o custo de mover somente computação e nenhum banco de dados. Nesse cenário, os recursos do OCI só existem em uma única região a qualquer momento. Isso é semelhante à abordagem que outros provedores de serviços de nuvem empregam para recuperação de desastres. Essa estratégia depende da replicação do armazenamento em blocos e de inicialização para cada máquina virtual na região stand-by; portanto, você só adicionará a contagem de OCPUs para a região em que as máquinas virtuais estão em execução no momento.

O estimador de custos inclui seis campos para conectar o total de contagens de OCPU e ECPU para recursos IaaS e PaaS em cada região. A tabela a seguir representa os seis campos que você preencheria no estimador de custos. Os valores nos campos se baseiam nos detalhes mostrados abaixo da tabela que representa uma pilha de aplicativos fictícios implantada para recuperação de desastres em duas regiões da OCI.

Totalizar toda a CPU consumida por instâncias de computação ou bancos de dados que são membros do grupo de proteção de DR na região principal (região 1).

A tabela a seguir mostra um exemplo dos recursos IaaS e PaaS que existem ou existirão na região principal. Os totais de CPU na última linha da tabela abaixo são os números mostrados no exemplo de estimador de custos acima.

CPU no Grupo de Proteção de DR Stand-by

Totalizar toda a CPU consumida por instâncias de computação ou bancos de dados que são membros do grupo de proteção de DR na região stand-by (região 2).

Este exemplo inclui apenas a movimentação de computação que existe apenas em uma única região a qualquer momento. Portanto, não há recursos de membro cobráveis no grupo de proteção stand-by, o que significa que não há cobranças incorridas para o Full Stack Disaster Recovery na região stand-by.

O exemplo abaixo mostra um sistema de negócios fictício implantado em duas regiões da OCI. Cada cliente terá algo diferente, dependendo dos serviços IaaS e PaaS que fazem parte da pilha de aplicativos. Este exemplo mostra como estimar o custo de movimentação de computação e dois Bancos de Dados Oracle. Nesse cenário, os recursos do OCI de computação só existem em uma única região enquanto os bancos de dados têm o Data Guard ativado, o que significa que há recursos do OCI em ambas as regiões. Isso é semelhante à abordagem de luz piloto que outros provedores de serviços de nuvem empregam para recuperação de desastres, exceto que você pode incluir o banco de dados como parte da mesma recuperação sem entregar tarefas a diferentes equipes. Essa estratégia depende da replicação do armazenamento em blocos e de inicialização para cada máquina virtual na região stand-by; portanto, você só adicionará a contagem de OCPUs para a região em que as máquinas virtuais estão em execução no momento. Para os bancos de dados, você adicionará contagens de OCPU e ECPU às duas regiões, pois você tem recursos em execução nas duas regiões.

O estimador de custos inclui seis campos para conectar o total de contagens de OCPUs e ECPUs para recursos IaaS e PaaS em cada região. A tabela a seguir representa os seis campos que você preencheria no estimador de custos. Os valores nos campos são baseados nos detalhes mostrados na tabela a seguir representando uma pilha de aplicativos fictícios implantada para recuperação de desastres em duas regiões do OCI.

Totalizar toda a CPU consumida por instâncias de computação ou bancos de dados que são membros do grupo de proteção de DR na região principal (região 1).

A tabela a seguir mostra um exemplo dos recursos IaaS e PaaS que existem ou existirão na região principal. Os totais de CPU na última linha da tabela abaixo são os números mostrados no exemplo de estimador de custos acima.

Totalizar toda a CPU consumida por instâncias de computação ou bancos de dados que são membros do grupo de proteção de DR na região stand-by (região 2).

Este exemplo inclui apenas a movimentação de computação que existe apenas em uma única região a qualquer momento. Portanto, não há recursos de membro cobráveis no grupo de proteção stand-by, o que significa que não há cobranças incorridas para o Full Stack Disaster Recovery na região stand-by.

O exemplo abaixo mostra um sistema de negócios fictício implantado em duas regiões da OCI. Cada cliente terá algo diferente, dependendo dos serviços IaaS e PaaS que fazem parte da pilha de aplicativos.

Este exemplo ilustra como precificar o Full Stack DR quando os bancos de dados móveis, estáticos e ativados para o Data Guard são membros de grupos de proteção de DR em ambas as regiões. Este é um exemplo simples de por que e como você pode usar computação imóvel para aplicativos não Oracle e Oracle, como E-Business Suite, PeopleSoft, JD Edwards EnterpriseOne e outros que não têm seus próprios recursos de DR inerentes incorporados em seus produtos. Esses produtos geralmente exigem que o aplicativo seja instalado em máquinas virtuais que existem e são executadas simultaneamente em ambas as regiões; o aplicativo é instalado em ambas as regiões, mas não está em execução na região stand-by.

Para fins de ilustração, este exemplo usa um total de quatro instâncias de computação:

O estimador de custos inclui seis campos para conectar o total de contagens de OCPUs e ECPUs para recursos IaaS e PaaS em cada região. A tabela a seguir representa os seis campos que você preencheria no estimador de custos. Os valores nos campos são baseados nos detalhes mostrados na tabela a seguir representando uma pilha de aplicativos fictícios implantada para recuperação de desastres em duas regiões do OCI. Observe que não há custos associados aos bancos de dados instalados e gerenciados pelo usuário - em vez disso, o custo é contabilizado pela OPCU que está sendo consumida pelas máquinas virtuais que hospedam o banco de dados e o Data Guard.

Totalizar toda a CPU consumida por instâncias de computação ou bancos de dados que são membros do grupo de proteção de DR na região principal (região 1).

A tabela a seguir mostra um exemplo dos recursos IaaS e PaaS que existem ou existirão na região principal. Os totais de CPU na última linha da tabela abaixo são os números mostrados no exemplo de estimador de custos acima.

Totalizar toda a CPU consumida por instâncias de computação ou bancos de dados que são membros do grupo de proteção de DR na região stand-by (região 2).

Este exemplo inclui apenas a movimentação de computação que existe apenas em uma única região a qualquer momento. Portanto, não há recursos de membro cobráveis no grupo de proteção stand-by, o que significa que não há cobranças incorridas para o Full Stack Disaster Recovery na região stand-by.

Exemplo 4: Pilha de aplicativos com OKE, banco de dados, Oracle Integration, movimentação de computação e computação não móvel

O exemplo abaixo mostra um sistema de negócios fictício implantado em duas regiões da OCI. Cada cliente terá algo diferente, dependendo dos serviços IaaS e PaaS que fazem parte da pilha de aplicativos.

Este exemplo ilustra como precificar o Full Stack DR para um sistema de negócios que inclui nós de trabalho hospedados em um cluster do Oracle Kubernetes Engine (OKE) e também computação móvel e não móvel como membros de grupos de proteção de DR em ambas as regiões. Este é um exemplo em pequena escala de uma arquitetura de implantação mais típica para um sistema de negócios que pode hospedar uma pilha de aplicativos para qualquer aplicativo não Oracle ou Oracle para planejamento de recursos, finanças, gerenciamento de warehouse, gerenciamento da cadeia de suprimentos, gerenciamento de relacionamento com o cliente, portal de vendas etc. A computação em movimento pode ser usada para hospedar aplicativos Oracle ou não Oracle que podem funcionar com modificações mínimas quando criados em outra região. A computação estática normalmente é usada para hospedar aplicativos Oracle ou não Oracle que não podem funcionar ou podem ser facilmente modificados para funcionar quando criados em outra região. Exemplos de aplicativos que podem ser instalados em computação não móvel são aplicativos Oracle, como PeopleSoft, JD Edwards EnterpriseOne, Oracle Siebel CRM, Oracle E-Business Suite, Oracle WebLogic Server etc. Esses aplicativos exigem que sejam instalados e executados ativamente em máquinas virtuais na região principal e instalados, mas não ativos em máquinas virtuais em execução na região stand-by.

Para fins de ilustração, este exemplo usa um total de quatro instâncias de computação padrão, quatro nós de trabalho do OKE, além de vários bancos de dados Oracle diferentes, incluindo Autonomous Database, Base Database e Exadata, que são todos recuperados em uma única execução do Plano de DR:

O estimador de custos inclui seis campos para conectar o total de contagens de OCPUs e ECPUs para recursos IaaS e PaaS em cada região. A tabela a seguir representa os seis campos que você preencheria no estimador de custos. Os valores nos campos são baseados nos detalhes mostrados na tabela a seguir representando uma pilha de aplicativos fictícios implantada para recuperação de desastres em duas regiões do OCI.

Totais de Métricas

CPU no Grupo de Proteção de DR Principal

Totalizar toda a CPU consumida por instâncias de computação ou bancos de dados que são membros do grupo de proteção de DR na região principal (região 1).

A tabela a seguir mostra um exemplo dos recursos IaaS e PaaS que existem ou existirão na região principal. Os totais de CPU na última linha da tabela abaixo são os números mostrados no exemplo de estimador de custos acima.

CPU no Grupo de Proteção de DR Stand-by

Totalizar toda a CPU consumida por instâncias de computação ou bancos de dados que são membros do grupo de proteção de DR na região stand-by (região 2).

Inclua apenas recursos membros que existem atualmente na região stand-by. Não é necessário calcular onde os recursos existirão após uma operação de DR; basta adicionar os recursos onde eles existem no estado normal atual das operações. A computação em movimento na região principal não está incluída como membros do grupo de proteção de DR stand-by; portanto, não há cobranças de OCPU para mover a computação na região stand-by.