Documentação do Oracle Cloud Infrastructure

Detalhes de Faturamento do Full Stack DR

Saiba como o serviço Full Stack DR calcula o faturamento de cada tipo de membro adicionado a um grupo de proteção de DR, incluindo alguns cálculos de amostra.

Como o Faturamento é Calculado para uma Configuração de DR (para um par de grupos de proteção de DR associados)

  1. O Full Stack DR usa apenas CPU alocada (OCPU ou ECPU) como base para calcular cobranças. Armazenamento, rede e outros usos de recursos não são cobrados pelo Full Stack DR.
  2. O valor total faturado é a soma do custo de faturamento baseado em CPU para todos os membros individuais adicionados a ambos os grupos de proteção de DR em um par associado.
  3. O uso da CPU para membros relevantes de um grupo de proteção de DR é calculado usando os métodos descritos na tabela abaixo.
  4. Depois de analisar os detalhes abaixo e o cálculo de amostra fornecido, consulte este site para carregar a calculadora de estimativa de custo. Use isso para estimar os encargos da sua configuração de DR.

Recursos membros que incorrem em cobranças

O Full Stack DR usa apenas CPU alocada (OCPU ou ECPU) como base para calcular cobranças. As cobranças do Full Stack DR incorrem em qualquer membro de computação ou banco de dados 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, no entanto, está sempre em um estado interrompido até que uma operação de DR ainda acumule cobranças por hora para o Full Stack DR, mesmo que ele não esteja em execução.

Recursos do OCI que incorrem em cobranças

Os encargos do Full Stack DR são incorridos para os seguintes tipos de recursos IaaS e PaaS do OCI:
  • do Autonomous Database
    • Oracle Autonomous Database Serverless (Data Warehousing)
    • Oracle Autonomous Database Serverless (Processamento de Transações)
  • Autonomous Container Database
    • Autonomous Database no Exadata Infrastructure Dedicado
  • Database
    • Base Database
    • Banco de Dados Exadata em Infraestrutura Dedicada
    • Exadata Database on Cloud@Customer
    • Exadata Database na Infraestrutura do Exascale
  • Instância de Computação (movimentação)
  • Instância de Computação (sem movimentação)
  • Mecanismo Kubernetes (OKE) da Oracle
Não há cobranças do Full Stack DR para os seguintes tipos de recursos IaaS e PaaS do OCI:
  • Armazenamento em blocos (incluindo volumes de inicialização)
  • Armazenamento de arquivos
  • Armazenamento de objetos
  • Balanceadores de carga
  • Balanceadores de carga da rede
Não há cobranças do Full Stack DR para o seguinte:
  • Aplicativos Oracle
  • Aplicativos não Oracle

Determinando o consumo do processador

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

Tabela A-9 Determinando o consumo do processador

Tipo de membro Tipo de CPU Base para cálculo
Instância de Computação (Movimentação) OCPU A Contagem de OCPUs alocada para a instância de computação. Consulte a seção Configuração da Forma na página Documentação do OCI para a instância de computação.
Instância de Computação (Sem Movimentação) OCPU A Contagem de OCPUs alocada para a instância de computação. Consulte a seção Configuração da Forma na página Documentação do OCI da instância de computação.
Banco de Dados: Oracle Base Database OCPU A Contagem de Núcleos de CPU alocada para o Sistema de Banco de Dados (Sistema de BD) associado ao Banco de Dados Base. Consulte a seção Informações Gerais na página Documentação do OCI do Base Database.
Banco de Dados:
  • Oracle Exadata Database on Dedicated Infrastructure
  • Oracle Exadata Database on Cloud@Customer
  • Oracle Exadata Database on Exascale Infrastructure
 ECPU ou OCPU (Legado)

A contagem total de ECPUs ou OCPUs para o cluster de VMs (tc) que hospeda este banco de dados, dividida pelo número total de bancos de dados provisionados nesse cluster de VMs (ti) é igual à CPU por instância de banco de dados (to). Essa contagem média de CPUs derivada é uma aproximação.

Fórmula: (tc/ti) =to

Por exemplo:
  • tc = Total de ECPU ou OCPU designada ao cluster de VMs do Exadata: 64
  • ti = Número total de instâncias de banco de dados no cluster: 4
  • to = ECPU ou OCPU por instância de banco de dados: 16
do Autonomous Database:
  • Data Warehouse sem Servidor
  • Processamento de Transações sem Servidor
ECPU ou OCPU (Legado) O número total de ECPU/OCPU alocadas para uma instância é mostrado como Contagem de ECPU/OCPU na seção Alocação de Recursos na página de detalhes do recurso para cada instância do Autonomous Serverless Database na console do OCI.
Autonomous Container Database:
  • Autonomous Database no Exadata Infrastructure Dedicado
  • Autonomous Database no Exadata Cloud@Customer
 ECPU ou OCPU (Legado)

O número total de ECPU/OCPU alocadas para uma instância é mostrado como Contagem de ECPU/OCPU na seção Alocação de Recursos na página de detalhes do recurso para cada instância do Autonomous Container Database na console do OCI.

Cluster do Oracle Kubernetes (OKE) OCPU

O cálculo depende do tamanho do pool de nós e da quantidade de OCPUs designadas a cada pool de nós para o cluster do OKE em ambas as regiões. Um cluster do OKE pode ter vários Pools de Nós. Portanto, o total de OCPUs para cada região é uma soma dos resultados de todos os Pools de Nós dessa região.

O tamanho do Pool de Nós no cluster principal do OKE (nps) é multiplicado pelo número de OCPUs designadas a esse Pool de Nós (npo). Execute esse cálculo para cada pool de nós (pnsn+*pnon+) na região principal e some os resultados de cada um para atingir uma contagem total de OCPUs para a região principal (poc).

O tamanho do Pool de Nós no cluster do OKE stand-by (sns) é multiplicado pelo número de OCPUs designadas a esse Pool de Nós (sno). Execute esse cálculo para cada pool de nós (snsn+*snon+) na região principal e some os resultados de cada um.

Adicione a contagem total de OCPUs da região principal (poc) e a contagem total de OCPUs da região stand-by (soc) para chegar a uma contagem total de OCPUs do OKE (até)

Fórmula: ∑(pnsn+*pnon+) + ∑(snsn+*snon+) = to

Por exemplo:

  1. Calcular o total de OCPUs na região principal
    • nps1 = O tamanho do Pool de Nós 1 é: 10
    • npo1 = A contagem de OCPUs do Pool de Nós 1 por nó é: 2
    • nps2 = O tamanho do Pool de Nós 2 é: 5
    • npo2 = A contagem de OCPUs do Pool de Nós 2 por nó é: 2
    • poc = A contagem total de OCPUs para a região principal é: 30
  2. Calcular o total de OCPUs na região stand-by
    • nps1 = O tamanho do Pool de Nós 1 é: 10
    • npo1 = A contagem de OCPUs do Pool de Nós 1 por nó é: 2
    • nps2 = O tamanho do Pool de Nós 2 é: 5
    • npo2 = A contagem de OCPUs do Pool de Nós 2 por nó é: 2
    • soc = A contagem total de OCPUs para a região stand-by é: 30
  3. Calcular a contagem total de OCPUs em ambas as regiões
    • poc = 30
    • soc = 30
    • to = A contagem total de OCPUs do OKE é: 60

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:

  • Não há necessidade de calcular onde os recursos existirão após uma operação de DR. Basta considerar os recursos onde eles existem no estado normal atual das operações.
  • Para a região principal, adicione os totais de OCPU e ECPU consumidos por recursos que são membros ou serão membros do grupo de proteção de DR principal.
  • Para a região stand-by, adicione os totais de OCPU e ECPU consumidos por recursos que são membros ou serão membros do grupo de proteção de DR stand-by. Você pode ou não ter recursos cobráveis como membros do grupo de proteção stand-by. Por exemplo, é totalmente possível que você não tenha recursos membros que consumam CPU no grupo de proteção stand-by se estiver apenas orquestrando a recuperação para mover a computação.
Exemplo 1: Pilha de aplicativos com apenas computação em movimento

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 para mover apenas computação e nenhum banco de dados.

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.

Tabela A-10 Região Principal do OCI/Grupo de Proteção

Total de OCPUs do Membro de Computação Total de OCPUs de Membros do Banco de Dados Total de ECPUs do Membro do Banco de Dados
12 0 0

Tabela A-11 Região/Grupo de Proteção do OCI Stand-by

Total de OCPUs do Membro de Computação Total de OCPUs de Membros do Banco de Dados Total de ECPUs do Membro do Banco de Dados
0 0 0

Tabela A-12 Totais de Métricas

OCI Full stack DR (OCPU) ECPU (Complete stack DR) do OCI
12 0

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 Principal

Tabela A-13 CPU no Grupo de Proteção de DR Principal

Grupo de Proteção de DR Recurso do Membro Descrição Contagem de OCPUs de Computação Contagem de OCPUs do Banco de Dados Contagem de ECPUs do Banco de Dados
Primária Instância de Computação (Movimentação)
  • Aplicativo não Oracle instalado e gerenciado pelo cliente
  • Servidor Web Apache para portal do cliente
  • Aplicativo em execução ativamente
 MyApp01Server01 4    
Primária Instância de Computação (Movimentação)
  • Aplicativo não Oracle instalado e gerenciado pelo cliente
  • Servidor Web Apache para portal do cliente
  • Aplicativo em execução ativamente
 MyApp01Server02 8    
Primária Balanceador de carga
  • Conjunto de backend 1 ativo
  • Conjunto de backend 2 ativo
 MyLoadBalancerRegion1 Sem cobrança Sem cobrança Sem cobrança
Primária Grupo de volumes em blocos
  • Ativo
  • Replicado à região 2
  • Contém volume de inicialização para MyApp01Server01
  • Contém volume de inicialização para MyApp01Server02
 MyVG00 Sem cobrança Sem cobrança Sem cobrança
Primária Sistema de arquivos
  • Ativo
  • Replicado à região 2
  • Contém o sistema de arquivos para /myscripts montados em MyApp01Server01 e MyApp01Server02
 myscripts Sem cobrança Sem cobrança Sem cobrança
Primária Total de todos os recursos de OCPU e ECPU de membros na região principal   12 0 0

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.

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

CPU da Tabela A-14 no Grupo de Proteção de DR Stand-by

Grupo de Proteção de DR Recurso do Membro Descrição Contagem de OCPUs de Computação Contagem de OCPUs do Banco de Dados Contagem de ECPUs do Banco de Dados
Stand-by Balanceador de carga
  • Conjunto de backend 1 não ativo, não preenchido
  • Conjunto de backend 2not ativo, não preenchido
 MyLoadBalancerRegion2 Sem cobrança Sem cobrança Sem cobrança
Stand-by Total de todos os recursos de OCPU e ECPU de membros na região stand-by   0 0 0

Exemplo 2: Pilha de aplicativos com a movimentação de computação e bancos de dados

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 para mover computação e dois Bancos de Dados Oracle.

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.

Região/Grupo de Proteção do OCI Principal

Tabela A-15 Região Principal do OCI/Grupo de Proteção

Total de OCPUs do Membro de Computação Total de OCPUs de Membros do Banco de Dados Total de ECPUs do Membro do Banco de Dados
12 16 16
Região/Grupo de Proteção do OCI Stand-by

Tabela A-16 Região/Grupo de Proteção do OCI Stand-by

Total de OCPUs do Membro de Computação Total de OCPUs de Membros do Banco de Dados Total de ECPUs do Membro do Banco de Dados
0 16 16
Totais de Métricas

Tabela A-17 Totais de Métricas

OCI Full stack DR (OCPU) ECPU (Complete stack DR) do OCI
44 32

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 Principal

Tabela A-18 CPU no Grupo de Proteção de DR Principal

Grupo de Proteção de DR Recurso do Membro Descrição Contagem de OCPUs de Computação Contagem de OCPUs do Banco de Dados Contagem de ECPUs do Banco de Dados
Primária Instância de Computação (Movimentação)
  • Aplicativo não Oracle instalado e gerenciado pelo cliente
  • Servidor Web Apache para portal do cliente
  • Aplicativo em execução ativamente
 MyApp01Server01 4    
Primária Instância de Computação (Movimentação)
  • Aplicativo não Oracle instalado e gerenciado pelo cliente
  • Servidor Web Apache para portal do cliente
  • Aplicativo em execução ativamente
 MyApp01Server02 8    
Primária Oracle Database
  • Cluster de VMs do Exadata
  • Data Guard na atribuição principal
  • Total de 64 OCPUs alocadas para o Cluster de VMs
  • 4 bancos de dados provisionados no Cluster de VMs
  • 16 OCPUs por banco de dados: (64/4 = 16 OCPUs por banco de dados)
 MyExaDatabase03   16  
Primária do Autonomous Database
  • Infraestrutura Dedicada
  • Autonomous Data Guard na atribuição principal
 MyADB01     16
Primária Balanceador de carga
  • Conjunto de backend 1 ativo
  • Conjunto de backend 2 ativo
 MyLoadBalancerRegion1 Sem cobrança Sem cobrança Sem cobrança
Primária Grupo de volumes em blocos
  • Ativo
  • Replicado à região 2
  • Contém volume de inicialização para MyApp01Server01
  • Contém volume de inicialização para MyApp01Server02
 MyVG00 Sem cobrança Sem cobrança Sem cobrança
Primária Sistema de arquivos
  • Ativo
  • Replicado à região 2
  • Contém o sistema de arquivos para /myscripts montados em MyApp01Server01 e MyApp01Server02
 myscripts Sem cobrança Sem cobrança Sem cobrança
Primária Total de todos os recursos de OCPU e ECPU de membros na região principal   12 16 16

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.

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

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

Grupo de Proteção de DR Recurso do Membro Descrição Contagem de OCPUs de Computação Contagem de OCPUs do Banco de Dados Contagem de ECPUs do Banco de Dados
Stand-by Oracle Database
  • Cluster de VMs do Exadata com total de 64 OCPUs
  • Data Guard na atribuição principal
  • Total de 64 OCPUs alocadas para o Cluster de VMs
  • 4 bancos de dados provisionados no Cluster de VMs
  • 16 OCPUs por banco de dados: (64/4 = 16 OCPUs por banco de dados)
 MyExaDatabase03   16  
Stand-by do Autonomous Database
  • Infraestrutura Dedicada
  • Data Guard na atribuição stand-by
 MyADB01     16
Stand-by Balanceador de carga
  • Conjunto de backend 1 não ativo, não preenchido
  • Conjunto de backend 2 não ativo, não preenchido
 MyLoadBalancerRegion2 Sem cobrança Sem cobrança Sem cobrança
Stand-by Total de todos os recursos de OCPU e ECPU de membros na região stand-by   0 16 16

Exemplo 3: Pilha de aplicativos com computação móvel e 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 quando computação móvel e não móvel são membros de grupos de proteção de DR em ambas as regiões. Isso também ilustra um caso de uso em que alguém optou por instalar manualmente um Oracle Database e o Data Guard em uma instância de computação, em vez de usar o serviço Oracle Database na console do OCI. Este é um exemplo simples de por que e como você pode usar computação estática, no entanto, ele não está aproveitando o suporte integrado para bancos de dados Oracle no Full Stack Disaster Recovery.

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

  • Duas instâncias de computação padrão atuarão como servidores "em movimento" para um aplicativo que tolera ser movido entre regiões.
    • Exemplos de aplicativos que podem ser instalados nesses servidores são aqueles que não mantêm valores com monitoramento de estado, específicos da região, com código fixo em binários ou arquivos de configuração e podem tolerar facilmente que sejam iniciados em outra região com outro endereço IP e menor, ou nenhuma alteração nos arquivos de configuração na inicialização.
    • Essas instâncias de computação só serão membros do Grupo de Proteção de DR principal.
  • Uma instância de computação padrão atuará como um servidor de aplicativos ativo "não móvel".
    • Essa instância de computação só existe na região 1 e nunca existirá na região 2.
    • O aplicativo está instalado e em execução na região 1.
    • Esta instância de computação só será membro do Grupo de Proteção de DR principal.
  • Uma instância de computação padrão atuará como um servidor de aplicativos "não móvel" e não ativo.
    • Essa instância de computação só existe na região 2 e nunca existirá na região 1.
    • O aplicativo está instalado, mas não está em execução na região 2.
    • Esta instância de computação só será membro do Grupo de Proteção de DR stand-by.

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.

Região/Grupo de Proteção do OCI Principal

Tabela A-20 Região Principal do OCI/Grupo de Proteção

Total de OCPUs do Membro de Computação Total de OCPUs de Membros do Banco de Dados Total de ECPUs do Membro do Banco de Dados
14 16 0
Região/Grupo de Proteção do OCI Stand-by

Tabela A-21 Região/Grupo de Proteção do OCI Stand-by

Total de OCPUs do Membro de Computação Total de OCPUs de Membros do Banco de Dados Total de ECPUs do Membro do Banco de Dados
2 16 0
Totais de Métricas

Tabela A-22 Totais de Métricas

OCI Full stack DR (OCPU) ECPU (Complete stack DR) do OCI
48 0

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 Principal

Tabela A-23 CPU no Grupo de Proteção de DR Principal

Grupo de Proteção de DR Recurso do Membro Descrição Contagem de OCPUs de Computação Contagem de OCPUs do Banco de Dados Contagem de ECPUs do Banco de Dados
Primária Instância de Computação (Movimentação)
  • Aplicativo não Oracle instalado e gerenciado pelo cliente
  • Servidor Web Apache para portal do cliente
  • Aplicativo em execução ativamente
 MyApp01Server01 4    
Primária Instância de Computação (Movimentação)
  • Aplicativo não Oracle instalado e gerenciado pelo cliente
  • Servidor Web Apache para portal do cliente
  • Aplicativo em execução ativamente
 MyApp01Server02 8    
Primária Instância de Computação (Sem Movimentação)
  • Aplicativo Oracle instalado e gerenciado pelo cliente, como Oracle Siebel CRM, PeopleSoft, JD Edwards EnterpriseOne, Oracle E-business Suite e assim por diante.
  • Aplicativo em execução ativamente
 MyApp02Server01 2    
Primária Oracle Database
  • Banco de dados principal para o aplicativo Oracle em execução em MyApp02Server01
  • Cluster de VMs do Exadata
  • Data Guard na atribuição principal
  • Total de 64 OCPUs alocadas para o Cluster de VMs
  • 4 bancos de dados provisionados no Cluster de VMs
  • 16 OCPUs por banco de dados: (64/4 = 16 OCPUs por banco de dados)
 MyExaDatabase03   16  
Primária Balanceador de carga
  • Conjunto de backend 1 ativo
  • Conjunto de backend 2 ativo
 MyLoadBalancerRegion1 Sem cobrança Sem cobrança Sem cobrança
Primária Grupo de volumes em blocos
  • Ativo
  • Replicado à região 2
  • Contém volume de inicialização para MyApp01Server01
  • Contém volume de inicialização para MyApp01Server02
 MyVG00 Sem cobrança Sem cobrança Sem cobrança
Primária Sistema de arquivos
  • Ativo
  • Replicado à região 2
  • Contém o sistema de arquivos para /myscripts montados em MyApp01Server01 e MyApp01Server02
 myscripts Sem cobrança Sem cobrança Sem cobrança
Primária Total de todos os recursos de OCPU e ECPU de membros na região principal   14 16 0
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.

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

CPU da Tabela A-24 no Grupo de Proteção de DR Stand-by

Grupo de Proteção de DR Recurso do Membro Descrição Contagem de OCPUs de Computação Contagem de OCPUs do Banco de Dados Contagem de ECPUs do Banco de Dados
Stand-by Instância de Computação (Não móvel).
  • Aplicativo Oracle instalado e gerenciado pelo cliente, como Oracle Siebel CRM, PeopleSoft, JD Edwards EnterpriseOne, Oracle E-business Suite e assim por diante.
  • Aplicativo instalado, mas não em execução
 MyApp02Server02 2 0 0
Stand-by Oracle Database
  • Banco de dados stand-by para o aplicativo Oracle em execução em MyApp02Server02
  • Cluster de VMs do Exadata
  • Data Guard na atribuição stand-by
  • Total de 64 OCPUs alocadas para o Cluster de VMs
  • 4 bancos de dados provisionados no Cluster de VMs
  • 16 OCPUs por banco de dados: (64/4 = 16 OCPUs por banco de dados)
 MyExaDatabase03   16  
Stand-by Balanceador de carga
  • Conjunto de backend 1 não ativo, não preenchido
  • Conjunto de backend 2not ativo, não preenchido
 MyLoadBalancerRegion2 Sem cobrança Sem cobrança Sem cobrança
Stand-by Total de todos os recursos de OCPU e ECPU de membros na região stand-by   2 16 0

Exemplo 4: Pilha de aplicativos com OKE, banco de dados, computação móvel 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:

  • Duas instâncias de computação padrão atuarão como servidores "em movimento" para um aplicativo que tolera ser movido entre regiões.
    • Exemplos de aplicativos que podem ser instalados nesses servidores são aqueles que não mantêm valores com monitoramento de estado, específicos da região, com código fixo em binários ou arquivos de configuração e podem tolerar facilmente que sejam iniciados em outra região com outro endereço IP e menor, ou nenhuma alteração nos arquivos de configuração na inicialização.
    • Essas instâncias de computação só serão membros do Grupo de Proteção de DR principal.
  • Uma instância de computação padrão atuará como um servidor de aplicativos ativo "não móvel".
    • Essa instância de computação só existe na região 1 e nunca existirá na região 2.
    • O aplicativo está instalado e em execução na região 1.
    • Esta instância de computação só será membro do Grupo de Proteção de DR principal.
  • Uma instância de computação padrão atuará como um servidor de aplicativos "não móvel" e não ativo.
    • Essa instância de computação só existe na região 2 e nunca existirá na região 1.
    • O aplicativo está instalado, mas não está em execução na região 2.
    • Esta instância de computação só será membro do Grupo de Proteção de DR stand-by.
  • Quatro nós de trabalho no cluster do OKE que hospedam cargas de trabalho do aplicativo que precisam ser recuperadas.
    • Quatro nós de trabalho no cluster do OKE da região principal que sempre permanece como membro apenas do Grupo de Proteção de DR principal.
    • Quatro nós de trabalho no cluster do OKE da região stand-by que sempre permanece como membro apenas do Grupo de Proteção de DR stand-by.
  • Quatro bancos de dados Oracle da OCI com o Data Guard já estão ativados usando a console da OCI que suporta as várias aplicações.
    • Os quatro bancos de dados principais serão membros apenas do Grupo de Proteção de DR principal.
    • Os quatro bancos de dados stand-by serão membros apenas do Grupo de Proteção de DR stand-by.

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.

Região/Grupo de Proteção do OCI Principal

Tabela A-25 Região Principal do OCI/Grupo de Proteção

Total de OCPUs do Membro de Computação Total de OCPUs de Membros do Banco de Dados Total de ECPUs do Membro do Banco de Dados
22 24 20
Região/Grupo de Proteção do OCI Stand-by

Tabela A-26 Região/Grupo de Proteção do OCI Stand-by

Total de OCPUs do Membro de Computação Total de OCPUs de Membros do Banco de Dados Total de ECPUs do Membro do Banco de Dados
10 24 20

Totais de Métricas

Tabela A-27 Totais de Métricas

OCI Full stack DR (OCPU) Total de OCPUs de Membros do Banco de Dados
80 40

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.

Tabela A-28 CPU no Grupo de Proteção de DR Principal

Grupo de Proteção de DR Recurso do membro Descrição Contagem de OCPUs de Computação Contagem de OCPUs do banco de dados Contagem de ECPUs do banco de dados
Primária Instância de Computação (Movimentação)
  • Aplicativo não Oracle instalado e gerenciado pelo cliente
  • Servidor Web Apache para portal do cliente
  • Aplicativo em execução ativamente
 MyApp01Server01 4    
Primária Instância de Computação (Movimentação)
  • Aplicativo não Oracle instalado e gerenciado pelo cliente
  • Servidor Web Apache para portal do cliente
  • Aplicativo em execução ativamente
 MyApp01Server02 8    
Primária Instância de Computação (Sem Movimentação)
  • Aplicativo Oracle instalado e gerenciado pelo cliente, como Oracle Siebel CRM, PeopleSoft, JD Edwards EnterpriseOne, Oracle E-business Suite e assim por diante.
  • Aplicativo em execução ativamente
 MyApp02Server01 2    
Primária Cluster do OKE: 4 nós de trabalho com 2 OCPUs cada MyOKECluster01 8    
Primária Oracle Database:
  • Banco de dados Base
  • Data Guard na atribuição principal
 MyEEDatabase01   8  
Primária Oracle Database:
  • Banco de dados principal para o aplicativo Oracle em execução em MyApp02Server01
  • Cluster de VMs do Exadata
  • Data Guard na atribuição principal
  • Total de 64 OCPUs alocadas para o Cluster de VMs
  • 4 bancos de dados provisionados no Cluster de VMs
  • 16 OCPUs por banco de dados: (64/4 = 16 OCPUs por banco de dados)
 MyExaDatabase03   16  
Primária do Autonomous Database
  • Infraestrutura Dedicada
  • Autonomous Data Guard na atribuição principal
 MyADB01     16
Primária do Autonomous Database
  • Infraestrutura sem servidor
  • Autonomous Data Guard na atribuição principal
 MyADW01     4
Primária Balanceador de carga
  • Conjunto de backend 1 ativo
  • Conjunto de backend 2 ativo
 MyLoadBalancerRegion1 Sem cobrança Sem cobrança Sem cobrança
Primária Grupo de volumes em blocos
  • Ativo
  • Replicado à região 2
  • Contém volume de inicialização para MyApp01Server01
  • Contém volume de inicialização para MyApp01Server02
 MyVG00 Sem cobrança Sem cobrança Sem cobrança
Primária Grupo de volumes em blocos:
  • Ativo
  • Replicado à região 2
  • Contém volume em blocos para /u02 onMyApp02Server01
  • É remontado para /u02 em MyApp02Server02 em region2 durante a recuperação
 MyVG01 Sem cobrança Sem cobrança Sem cobrança
Primária Sistema de arquivos:
  • Ativo
  • Replicado à região 2
  • Contém o sistema de arquivos para /myscripts montados em MyApp01Server01 e MyApp01Server02
 myscripts Sem cobrança Sem cobrança Sem cobrança
Primária Total de todos os recursos de OCPU e ECPU de membros na região principal   22 24 20

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.

CPU da Tabela A-29 no Grupo de Proteção de DR Stand-by

Grupo de Proteção de DR Recurso do membro Descrição Contagem de OCPUs de Computação Contagem de OCPUs do banco de dados Contagem de ECPUs do banco de dados
Stand-by Instância de Computação (Sem Movimentação)
  • Aplicativo Oracle instalado e gerenciado pelo cliente, como Oracle Siebel CRM, PeopleSoft, JD Edwards EnterpriseOne, Oracle E-business Suite e assim por diante.
  • Aplicativo instalado, mas não em execução
 MyApp02Server02 2    
Stand-by Cluster do OKE: 4 nós de trabalho com 2 OCPUs cada MyOKECluster01 8    
Stand-by Oracle Database:
  • Banco de dados Base
  • Data Guard na atribuição stand-by
, 		MyEEDatabase01   8  
Stand-by Oracle Database:
  • Banco de dados stand-by para o aplicativo Oracle em execução em MyApp02Server02
  • Cluster de VMs do Exadata
  • Data Guard na atribuição stand-by
  • Total de 64 OCPUs alocadas para o Cluster de VMs
  • 4 bancos de dados provisionados no Cluster de VMs
  • 16 OCPUs por banco de dados: (64/4 = 16 OCPUs por banco de dados)
 MyExaDatabase03   16  
Stand-by do Autonomous Database:
  • Infraestrutura Dedicada
  • Data Guard na atribuição stand-by
 MyADB01     16
Stand-by do Autonomous Database:
  • Infraestrutura sem servidor
  • Data Guard na atribuição stand-by
 MyADW01     4
Stand-by Balanceador de carga:
  • Conjunto de backend 1 não ativo, não preenchido
  • Conjunto de backend 2not ativo, não preenchido
 MyLoadBalancerRegion2 Sem cobrança   Sem cobrança
Stand-by Total de todos os recursos de OCPU e ECPU de membros na região stand-by   10 24 20

Tópico principal: Referência