Oracle E-Business Suite com o Oracle Database no Compute Engine

Last reviewed 2025-08-13 UTC

Este documento fornece arquiteturas de referência para ajudar você a criar a infraestrutura para executar aplicativos do Oracle E-Business Suite com o Oracle Database em VMs do Compute Engine em Google Cloud. O Oracle E-Business Suite é um pacote de aplicativos corporativos para funções de negócios, como finanças, recursos humanos, cadeia de suprimentos e relacionamento com o cliente.

O público-alvo deste documento são arquitetos e administradores de nuvem de bancos de dados Oracle e aplicativos do Oracle E‑Business Suite. O documento pressupõe que sua equipe esteja familiarizada com o Oracle Database e a arquitetura e o conjunto de tecnologias do Oracle E-Business Suite.

Se você precisar usar o Oracle Exadata ou o Oracle Real Application Clusters (Oracle RAC), migre seus aplicativos para Google Cloud e execute seus bancos de dados no Oracle Database@Google Cloud. Para mais informações, consulte Oracle E-Business Suite no Compute Engine com o Oracle Exadata.

Arquitetura

Dependendo do seu caso de uso e dos requisitos de disponibilidade e recuperação de desastres (DR), escolha um dos seguintes Google Cloud arquétipos de implantação para executar aplicativos do Oracle E‑Business Suite no Google Cloud:

  • Zonal: seus aplicativos são executados em uma única zona do Google Cloud. Esse arquétipo de implantação é adequado para ambientes de desenvolvimento e teste e para aplicativos não críticos que não precisam de alta disponibilidade.
  • Regional: seus aplicativos são executados de maneira independente em duas ou mais zonas em uma única Google Cloud região. Recomendamos esse arquétipo de implantação para aplicativos que não são essenciais, mas precisam de robustez contra interrupções de zona.
  • Multirregional: seus aplicativos são executados de maneira independente em várias zonas em duas ou mais Google Cloud regiões, no modo ativo-ativo ou ativo-passivo. Esse arquétipo de implantação é ideal para oferecer suporte a cenários de DR. Recomendamos esse arquétipo para aplicativos essenciais que precisam de resiliência a interrupções e desastres regionais.

A escolha de um arquétipo de implantação ajuda a simplificar as decisões subsequentes sobre os produtos e recursos do Google Cloud que você precisa para sua arquitetura.

As seções a seguir apresentam quatro opções de arquitetura. Cada opção é baseada em um dos arquétipos de implantação:

Arquitetura zonal

O diagrama a seguir mostra uma arquitetura para aplicativos do Oracle E‑Business Suite com o Oracle Database em execução em uma única zona em uma regiãoGoogle Cloud . Essa arquitetura está alinhada com o arquétipo de implantação zonal.

Uma arquitetura para aplicativos do Oracle E-Business Suite é executada em uma única zona em uma região Google Cloud .

A arquitetura no diagrama anterior inclui os seguintes componentes:

Componente Descrição
Balanceador de carga de aplicativo externo regional O balanceador de carga recebe e distribui solicitações de usuários para os aplicativos do Oracle E‑Business Suite.
Política de segurança do Google Cloud Armor A política de segurança do Cloud Armor ajuda a proteger seus aplicativos contra ameaças como ataques DDoS e XSS.
Oracle E‑Business Suite (BYOL)

Os componentes da camada de aplicativo do Oracle E-Business Suite (Oracle HTTP Server, Oracle WebLogic Server e um servidor de processamento simultâneo) são executados em VMs do Compute Engine. Cada VM hospeda uma instância independente da camada de aplicativo. O disco de inicialização de cada VM é um volume do Google Cloud Hyperdisk.

Você traz suas próprias licenças (BYOL) para o Oracle E-Business Suite e gerencia as VMs e os aplicativos.
Binários e dados de aplicativos Uma instância zonal do Filestore contém os binários e dados do aplicativo. A instância do Filestore é montada nas VMs do Compute Engine que hospedam os componentes da camada de aplicativo.
Oracle Database (BYOL)

Os aplicativos do Oracle E-Business Suite usam uma instância do Oracle Database implantada em uma VM do Compute Engine. Os discos de inicialização e de dados da VM são volumes do Hyperdisk.

Você traz sua própria licença (BYOL) para a instância do Oracle Database e gerencia a VM e o banco de dados.
Backups de aplicativos e bancos de dados Os backups dos dados do aplicativo e do banco de dados são criados, armazenados e gerenciados usando o Serviço de backup e DR.
Rede de nuvem privada virtual (VPC) e sub-redes

Todos os recursos Google Cloud na arquitetura usam uma única rede VPC. As VMs que hospedam a camada de aplicativo e o banco de dados usam sub-redes separadas.

Dependendo dos seus requisitos, é possível criar uma arquitetura que use várias redes VPC. Para mais informações, consulte Como decidir se você quer criar várias redes VPC.
Gateway NAT público A arquitetura inclui um gateway público do Cloud NAT para conexões de saída seguras das VMs do Compute Engine, que têm apenas endereços IP internos. Por exemplo, as VMs podem acessar o servidor Oracle Linux Yum para fazer o download de pacotes do SO.
Cloud Interconnect e Cloud VPN Para conectar sua rede local à rede VPC em Google Cloud, use o Cloud Interconnect ou o Cloud VPN. Para informações sobre as vantagens relativas de cada abordagem, consulte Como escolher um produto de conectividade de rede.

Arquitetura por zona com uma DMZ

O diagrama a seguir mostra uma arquitetura com duas camadas de aplicativos independentes do Oracle E‑Business Suite em execução em VMs do Compute Engine. Uma das camadas de aplicativo é uma zona desmilitarizada (DMZ), que atende usuários externos dos aplicativos do Oracle E-Business Suite. A outra camada atende usuários internos. As duas camadas de aplicativo são executadas em uma única zona em uma região do Google Cloud e usam uma única instância do Oracle Database. Assim como a arquitetura na seção anterior, essa arquitetura está alinhada com o arquétipo de implantação zonal.

Uma arquitetura para aplicativos do Oracle E-Business Suite é executada em uma única zona com uma DMZ em uma região Google Cloud .

A arquitetura no diagrama anterior inclui os seguintes componentes:

Componente Descrição
Balanceador de carga de aplicativo externo regional O balanceador de carga externo recebe e distribui solicitações de usuários externos para a camada de aplicativo voltada para o externo.
Balanceador de carga de aplicativo interno regional O balanceador de carga interno recebe e distribui solicitações de usuários internos para uma camada de aplicativo interna.
Política de segurança do Cloud Armor A política de segurança do Cloud Armor ajuda a proteger seus aplicativos contra ameaças externas, como ataques DDoS e XSS.
Oracle E‑Business Suite (BYOL)

Os componentes da camada de aplicativo do Oracle E-Business Suite (Oracle HTTP Server, Oracle WebLogic Server e um servidor de processamento simultâneo) são executados em VMs do Compute Engine. Cada VM hospeda uma instância independente da camada de aplicativo. Os aplicativos internos e externos são veiculados de conjuntos distintos de VMs. O disco de inicialização de cada VM é um volume do Hyperdisk.

Você traz suas próprias licenças (BYOL) para o Oracle E-Business Suite e gerencia as VMs e os aplicativos.
Binários e dados de aplicativos Uma instância zonal do Filestore contém os binários e dados do aplicativo. A instância do Filestore é ativada nas VMs do Compute Engine que hospedam os componentes da camada de aplicativo.
Oracle Database (BYOL)

Os aplicativos do Oracle E-Business Suite usam uma instância do Oracle Database implantada em uma VM do Compute Engine. Os discos de inicialização e de dados da VM são volumes do Hyperdisk.

Você traz sua própria licença (BYOL) para a instância do Oracle Database e gerencia a VM e o banco de dados.
Backups de aplicativos e bancos de dados Os backups dos dados do aplicativo e do banco de dados são criados, armazenados e gerenciados usando o Backup e DR.
Rede de nuvem privada virtual (VPC) e sub-redes

Todos os recursos Google Cloud na arquitetura usam uma única rede VPC. As VMs que hospedam a camada de aplicativo e o banco de dados usam sub-redes separadas.

Dependendo dos seus requisitos, é possível criar uma arquitetura que use várias redes VPC. Para mais informações, consulte Como decidir se você quer criar várias redes VPC.
Gateway NAT público A arquitetura inclui um gateway público do Cloud NAT para conexões de saída seguras das VMs do Compute Engine, que têm apenas endereços IP internos. Por exemplo, as VMs podem acessar o servidor Oracle Linux Yum para fazer o download de pacotes do SO.
Cloud Interconnect e Cloud VPN Para conectar sua rede local à rede VPC em Google Cloud, use o Cloud Interconnect ou o Cloud VPN. Os administradores e usuários internos de aplicativos usam essas conexões para acessar os recursos e aplicativos, respectivamente. Para informações sobre as vantagens relativas de cada abordagem, consulte Como escolher um produto de conectividade de rede.

Arquitetura regional

O diagrama a seguir mostra uma arquitetura em que os aplicativos do Oracle E‑Business Suite são executados no modo ativo-ativo em VMs do Compute Engine distribuídas em duas zonas em uma região Google Cloud . As duas implantações de aplicativos usam uma instância principal do Oracle Database executada em uma VM em uma das zonas. O Oracle Data Guard gerencia a replicação e o failover do banco de dados para uma instância em espera do Oracle Database na segunda zona. Essa arquitetura é baseada no arquétipo de implantação regional.

Uma arquitetura para aplicativos do Oracle E-Business Suite é executada em duas zonas dentro de uma região Google Cloud .

A arquitetura no diagrama anterior inclui os seguintes componentes:

Componente Descrição
Balanceador de carga de aplicativo externo regional O balanceador de carga recebe e distribui solicitações de usuários para os aplicativos do Oracle E‑Business Suite.
Política de segurança do Cloud Armor A política de segurança do Cloud Armor ajuda a proteger seus aplicativos contra ameaças como ataques DDoS distribuídos e XSS.
Oracle E‑Business Suite (BYOL)

Os componentes da camada de aplicativo do Oracle E-Business Suite (Oracle HTTP Server, Oracle WebLogic Server e um servidor de processamento simultâneo) são executados em VMs do Compute Engine distribuídas em duas zonas. Cada VM hospeda uma instância independente da camada de aplicativo. O disco de inicialização de cada VM é um volume do Hyperdisk.

Você traz suas próprias licenças (BYOL) para o Oracle E-Business Suite e gerencia as VMs e os aplicativos.
Binários e dados de aplicativos Uma instância regional do Filestore contém os binários e dados do aplicativo. A instância do Filestore é ativada em todas as VMs do Compute Engine que hospedam os componentes da camada de aplicativo nas duas zonas.
Oracle Database (BYOL)

Os aplicativos do Oracle E-Business Suite usam um par principal-em espera de instâncias do Oracle Database implantadas em VMs do Compute Engine em zonas separadas. Os discos de inicialização e de dados da VM são volumes do Hyperdisk.

O Oracle Data Guard gerencia a replicação e o failover do banco de dados da instância principal para a instância de espera.

Você traz suas próprias licenças (BYOL) para as instâncias do Oracle Database e gerencia as VMs e os bancos de dados.
Backups de aplicativos e bancos de dados Os backups dos dados do aplicativo e do banco de dados são criados, armazenados e gerenciados usando o Backup e DR.
Rede de nuvem privada virtual (VPC) e sub-redes

Todos os recursos Google Cloud na arquitetura usam uma única rede VPC. As VMs que hospedam a camada de aplicativo e o banco de dados usam sub-redes separadas.

Dependendo dos seus requisitos, é possível criar uma arquitetura que use várias redes VPC. Para mais informações, consulte Como decidir se você quer criar várias redes VPC.
Gateway NAT público A arquitetura inclui um gateway público do Cloud NAT para conexões de saída seguras das VMs do Compute Engine, que têm apenas endereços IP internos. Por exemplo, as VMs podem acessar o servidor Oracle Linux Yum para fazer o download de pacotes do SO.
Cloud Interconnect e Cloud VPN Para conectar sua rede local à rede VPC em Google Cloud, use o Cloud Interconnect ou o Cloud VPN. Para informações sobre as vantagens relativas de cada abordagem, consulte Como escolher um produto de conectividade de rede.

Arquitetura multirregional ativa-passiva (DR)

O diagrama a seguir mostra uma arquitetura em que os aplicativos do Oracle E‑Business Suite são executados no modo ativo-ativo em VMs do Compute Engine distribuídas em duas zonas em uma região Google Cloud . As duas implantações de aplicativos usam uma instância principal do Oracle Database executada em uma VM em uma das zonas. O Oracle Data Guard gerencia a replicação e o failover do banco de dados para uma instância em espera do Oracle Database na segunda zona. A arquitetura inclui uma réplica em menor escala da pilha de aplicativos em uma região remota (de failover) para DR. Assim como a arquitetura na seção anterior, ela se baseia no arquétipo de implantação regional.

Uma arquitetura para aplicativos do Oracle E-Business Suite é executada em duas zonas em uma região Google Cloud , com uma réplica em uma região remota para DR.

A arquitetura no diagrama anterior inclui os seguintes componentes:

Componente Descrição
Política de roteamento de failover de DNS Uma zona pública do Cloud DNS configurada com uma política de roteamento de failover encaminha as solicitações do usuário para o balanceador de carga na região que está atendendo às solicitações.
Balanceador de carga de aplicativo externo regional O balanceador de carga recebe e distribui solicitações de usuários para os aplicativos do Oracle E‑Business Suite.
Política de segurança do Cloud Armor A política de segurança do Cloud Armor ajuda a proteger seus aplicativos contra ameaças como ataques DDoS distribuídos e XSS.
Oracle E‑Business Suite (BYOL)

Os componentes da camada de aplicativo do Oracle E-Business Suite (Oracle HTTP Server, Oracle WebLogic Server e um servidor de processamento simultâneo) são executados em VMs do Compute Engine distribuídas em duas zonas na região principal. Cada VM hospeda uma instância independente da camada de aplicativo. O disco de inicialização de cada VM é um volume do Hyperdisk.

Você traz suas próprias licenças (BYOL) para o Oracle E-Business Suite e gerencia as VMs e os aplicativos.
Binários e dados de aplicativos

Uma instância regional do Filestore na região principal contém os binários e os dados do aplicativo. A instância do Filestore é montada em todas as VMs do Compute Engine que hospedam os componentes da camada de aplicativo nas duas zonas da região principal. A instância do Filestore é replicada para a região de failover.
Oracle Database (BYOL)

Os aplicativos do Oracle E-Business Suite usam um par principal-standby de instâncias do Oracle Database implantadas em VMs do Compute Engine em zonas separadas na região principal. Os discos de inicialização e de dados da VM são volumes do Hyperdisk.

O Oracle Data Guard gerencia a replicação e o failover do banco de dados da instância principal para a instância de espera.

Você traz suas próprias licenças (BYOL) para as instâncias do Oracle Database e gerencia as VMs e os bancos de dados.
Backups de aplicativos e bancos de dados Os backups dos dados do aplicativo e do banco de dados são criados, armazenados e gerenciados usando o Backup e DR.
Rede de nuvem privada virtual (VPC) e sub-redes

Todos os recursos Google Cloud na arquitetura usam uma única rede VPC. As VMs que hospedam a camada de aplicativo e o banco de dados usam sub-redes regionais separadas.

Dependendo dos seus requisitos, é possível criar uma arquitetura que use várias redes VPC. Para mais informações, consulte Como decidir se você quer criar várias redes VPC.
Gateway NAT público A arquitetura inclui um gateway público do Cloud NAT em cada região para conexões de saída seguras das VMs do Compute Engine, que têm apenas endereços IP internos. Por exemplo, as VMs podem acessar o servidor Oracle Linux Yum para fazer o download de pacotes do SO.
Cloud Interconnect e Cloud VPN Para conectar sua rede local à rede VPC em Google Cloud, use o Cloud Interconnect ou o Cloud VPN. Para informações sobre as vantagens relativas de cada abordagem, consulte Como escolher um produto de conectividade de rede.

Produtos usados

Essas arquiteturas de referência usam os seguintes produtos do Google Cloud :

  • Compute Engine: um serviço de computação seguro e personalizável que permite criar e executar VMs na infraestrutura do Google.
  • Google Cloud Hyperdisk: um serviço de armazenamento em rede que pode ser usado para provisionar e escalonar dinamicamente volumes de armazenamento em blocos com desempenho configurável e previsível.
  • Filestore: um serviço que oferece armazenamento de arquivos de alto desempenho e totalmente gerenciado no Google Cloud , que pode ser conectado a vários tipos de clientes.
  • Serviço de backup e DR: um serviço seguro e gerenciado centralmente de backup e recuperação para cargas de trabalho do Google Cloud que ajuda a proteger os dados de backup contra exclusão acidental ou maliciosa.
  • Cloud DNS: um serviço que oferece exibição de DNS resiliente e de baixa latência na rede mundial do Google.
  • Cloud Load Balancing: um portfólio de balanceadores de carga globais, regionais, escalonáveis, globais e de alto desempenho.
  • Google Cloud Armor: um serviço de segurança de rede que oferece regras de firewall de aplicativos da Web (WAF) e ajuda a proteger contra ataques DDoS e de aplicativos.
  • Nuvem privada virtual: um sistema virtual que oferece funcionalidade de rede global e escalonável para suas cargas de trabalho do Google Cloud . A VPC inclui o peering de rede VPC, o Private Service Connect, o acesso a serviços particulares e a VPC compartilhada.
  • Cloud NAT: um serviço que oferece conversão de endereços de rede de alta performance gerenciada pelo Google Cloud.
  • Cloud Interconnect: um serviço que estende sua rede externa para a rede do Google por meio de uma conexão de alta disponibilidade e baixa latência.
  • Cloud VPN: um serviço que estende com segurança sua rede de peering para a rede do Google por um túnel de VPN IPsec.

Essas arquiteturas de referência usam os seguintes produtos da Oracle:

  • Oracle E-Business Suite: um pacote de aplicativos para operações comerciais, como finanças, recursos humanos e cadeia de suprimentos.
  • Oracle Database: um sistema de gerenciamento de banco de dados relacional (RDBMS) que estende o modelo relacional para um modelo relacional de objetos.
  • Oracle Data Guard: um conjunto de serviços para criar, manter, gerenciar e monitorar um ou mais bancos de dados de espera.

Você é responsável por adquirir licenças para os produtos da Oracle que implanta no Google Cloude por obedecer aos termos e condições das licenças da Oracle.

Considerações sobre o design

Esta seção descreve fatores de design, práticas recomendadas e recomendações de design que você precisa considerar ao usar essas arquiteturas de referência para desenvolver uma topologia que atenda aos seus requisitos específicos de segurança, confiabilidade, eficiência operacional, custo e desempenho.

design do sistema

Nesta seção, fornecemos orientações para ajudar você a escolher Google Cloud regiões para sua implantação e selecionar os Google Cloud serviços adequados.

Seleção da região

Ao escolher as Google Cloud regiões em que seus aplicativos precisam ser implantados, considere os seguintes fatores e requisitos:

  • Disponibilidade dos serviços do Google Cloud em cada região. Para mais informações, consulte Produtos disponíveis por local.
  • Disponibilidade de tipos de máquina do Compute Engine em cada região. Para mais informações, consulte Regiões e zonas.
  • Requisitos de latência do usuário final.
  • Custo dos recursos Google Cloud .
  • Custos da transferência de dados entre regiões.
  • Requisitos regulatórios.

Alguns desses fatores e requisitos podem envolver compensações. Por exemplo, a região mais econômica pode não ter a menor pegada de carbono. Para mais informações, consulte Práticas recomendadas para a seleção de regiões do Compute Engine.

Migração de bancos de dados

Ao planejar a migração de implantações locais do Oracle Database para o Google Cloud, avalie seu ambiente de banco de dados atual e receba recomendações de configuração e dimensionamento usando a ferramenta Database Migration Assessment (DMA).

Para migrar dados locais para implantações de banco de dados Oracle em Google Cloud, use ferramentas padrão do Oracle, como o Oracle GoldenGate.

Opções de armazenamento

Para as VMs do Compute Engine na arquitetura, é possível usar volumes de inicialização do Hyperdisk ou do disco permanente. Os volumes do Hyperdisk oferecem melhor desempenho, flexibilidade e eficiência do que o disco permanente. Com o Hyperdisk equilibrado, é possível provisionar IOPS e capacidade de processamento de maneira separada e dinâmica, o que permite ajustar o volume a uma grande variedade de cargas de trabalho.

Para armazenar binários de aplicativos, use o Filestore. Os arquivos armazenados em uma instância do Filestore Regional são replicados de maneira síncrona em três zonas na região. Essa replicação ajuda a garantir alta disponibilidade e robustez contra interrupções dos serviços da zona. Para ter robustez contra interrupções regionais, é possível replicar uma instância do Filestore para outra região. Para mais informações, consulte Replicação de instâncias.

Ao projetar o armazenamento para suas cargas de trabalho, considere as características funcionais, os requisitos de resiliência, as expectativas de desempenho e as metas de custo. Para mais informações, consulte Criar uma estratégia de armazenamento ideal para sua carga de trabalho na nuvem.

Design de rede

Escolha um design de rede que atenda aos seus requisitos comerciais e técnicos. É possível usar uma ou várias redes VPC. Para mais informações, consulte a seguinte documentação:

Análise de dados

Para análises avançadas, use o Google Cloud Cortex Framework para ingerir dados dos aplicativos do Oracle E-Business Suite no BigQuery. Para mais informações, consulte Cortex Framework: integração com o Oracle E‑Business Suite.

segurança, privacidade e conformidade

Nesta seção, descrevemos os fatores que você precisa considerar ao usar essas arquiteturas de referência para projetar uma topologia no Google Cloud que atenda aos requisitos de segurança e conformidade das suas cargas de trabalho.

Proteção contra ameaças externas

Para proteger o aplicativo contra ameaças como ataques distribuídos de negação de serviço (DDoS) e scripting em vários locais (XSS), use as políticas de segurança do Google Cloud Armor. Cada política é um conjunto de regras que especifica determinadas condições que precisam ser avaliadas e ações a serem tomadas quando as condições são atendidas. Por exemplo, uma regra pode especificar que, se o endereço IP de origem do tráfego de entrada corresponder a um endereço IP ou intervalo CIDR específico, o tráfego precisará ser negado. Também é possível aplicar regras pré-configuradas de firewall de aplicativos da Web (WAF). Para mais informações, consulte Visão geral da política de segurança.

Acesso externo para VMs

Na arquitetura de referência descrita neste documento, as VMs do Compute Engine não precisam de acesso de entrada da Internet. Não atribua endereços IP externos às VMs.Os recursos do Google Cloud que têm apenas um endereço IP interno particular ainda podem acessar determinadas APIs e serviços do Google usando o Private Service Connect ou o Acesso privado do Google. Para mais informações, consulte Opções de acesso privado para serviços.

Para ativar conexões de saída seguras de recursos do Google Cloud que têm apenas endereços IP privados, como as VMs do Compute Engine nessa arquitetura de referência, use o Secure Web Proxy ou o Cloud NAT.

Privilégios da conta de serviço

Para as VMs do Compute Engine na arquitetura, em vez de usar as contas de serviço padrão, recomendamos criar contas de serviço dedicadas e especificar os recursos a que elas podem acessar. A conta de serviço padrão tem uma ampla variedade de permissões, incluindo algumas que podem não ser necessárias. É possível personalizar contas de serviço dedicadas para ter apenas as permissões essenciais. Para mais informações, consulte Limitar os privilégios da conta de serviço.

Segurança SSH

Para aumentar a segurança das conexões SSH com as VMs do Compute Engine na sua arquitetura, implemente o Identity-Aware Proxy (IAP) e a API Cloud OS Login. Com o IAP, é possível controlar o acesso à rede com base na identidade do usuário e nas políticas do Identity and Access Management (IAM). A API Cloud OS Login permite controlar o acesso SSH do Linux com base na identidade do usuário e nas políticas do IAM. Para mais informações sobre como gerenciar o acesso à rede, consulte Práticas recomendadas para controlar o acesso de login SSH.

Criptografia de disco

Por padrão, os dados armazenados em volumes do Hyperdisk e no Filestore são criptografados usando Google-owned and Google-managed encryption keys. Como uma camada extra de proteção, é possível criptografar o Google-owned and managed key usando chaves que você tem e gerencia no Cloud Key Management Service (Cloud KMS). Para mais informações, consulte Sobre a criptografia de disco para volumes do Hyperdisk e Criptografar dados com chaves de criptografia gerenciadas pelo cliente para o Filestore.

Segurança de rede

Para controlar o tráfego de rede entre os recursos na arquitetura, é preciso configurar as políticas do Cloud Next Generation Firewall (NGFW) adequadas.

Mais considerações sobre a segurança

Ao criar a arquitetura para a carga de trabalho, considere as práticas recomendadas de segurança no nível da plataforma e as recomendações fornecidas no Blueprint de bases empresariais e no Google Cloud Framework do Well-Architected: segurança, privacidade e conformidade.

Confiabilidade

Nesta seção, descrevemos os fatores de design que você precisa considerar ao usar essas arquiteturas de referência para criar e operar uma infraestrutura confiável para sua implantação em Google Cloud.

Robustez da camada de aplicativo contra falhas de VM

Com todas as opções de arquitetura neste documento, se algumas (mas não todas) das VMs de aplicativo falharem, os aplicativos vão continuar disponíveis porque o balanceador de carga encaminha solicitações para outras VMs de aplicativo.

Às vezes, uma VM de aplicativo pode estar em execução e disponível, mas pode haver problemas com o próprio aplicativo. O aplicativo pode congelar, falhar ou não ter memória suficiente. Nesse cenário, a VM não responde às verificações de integridade do balanceador de carga, e o balanceador não encaminha o tráfego para a VM que não responde.

Robustez do banco de dados contra falhas de VM

Em uma arquitetura zonal, se a VM do banco de dados falhar, você poderá restaurar o banco de dados para produção em uma nova VM usando os backups armazenados no Backup e DR. Depois de restaurar o banco de dados, conecte os aplicativos à nova instância de banco de dados.

Se a consistência de dados for uma prioridade, configure uma instância de banco de dados primária e uma de espera, de preferência em VMs que estejam em zonas diferentes, conforme mostrado em Arquitetura regional. Para replicação e failover na instância do banco de dados em espera, use o Data Guard. O Data Guard ajuda a garantir a consistência replicando transações para a instância de espera antes de confirmá-las na instância principal. A arquitetura de banco de dados principal-standby envolve custos adicionais de infraestrutura e licenciamento.

Em uma arquitetura regional ou multirregional, se a VM que hospeda o banco de dados primário falhar, o Oracle Data Guard vai iniciar um failover para a instância do Oracle Database em espera. Durante o processo de failover, os aplicativos não podem acessar o banco de dados.

Robustez contra interrupções de zona

Em uma arquitetura zonal, se a zona que hospeda sua implantação tiver uma interrupção, os aplicativos e o banco de dados vão ficar inativos. É possível restaurar os aplicativos e o banco de dados para produção em uma zona ou região diferente usando os backups armazenados no Backup e DR.

Em uma arquitetura regional, se uma das zonas tiver uma interrupção, o balanceador de carga encaminhará as solicitações para instâncias dos aplicativos que são executados na outra zona. O Filestore continua disponível porque a arquitetura usa o nível de serviço regional do Filestore.

Para garantir a alta disponibilidade dos dados em volumes do Hyperdisk durante uma interrupção em uma única zona, use o Hyperdisk Balanced High Availability. Quando os dados são gravados em um volume do Hyperdisk Balanced High Availability, eles são replicados de forma síncrona entre duas zonas na mesma região.

Robustez contra interrupções regionais

Se ocorrer uma interrupção do serviço na região, os aplicativos e o banco de dados ficarão indisponíveis. É possível restaurar os aplicativos e o banco de dados para produção em uma região diferente usando os backups armazenados no Backup e DR. Para reduzir o tempo de inatividade, use a arquitetura multirregional ativa-passiva (DR). Depois de ativar os aplicativos e o banco de dados, atualize a política de roteamento de DNS para encaminhar o tráfego ao balanceador de carga na região de failover.

Para aplicativos essenciais aos negócios que não podem tolerar inatividade, mesmo quando ocorre uma interrupção regional, use o arquétipo de implantação ativa-ativa multirregional.

Planejamento de capacidade de VM

Para garantir que a capacidade de VMs do Compute Engine esteja disponível quando elas precisarem ser provisionadas, crie reservas. Uma reserva oferece capacidade garantida em uma zona específica para um número especificado de VMs de um tipo de máquina escolhido por você. Uma reserva pode ser específica para um projeto ou compartilhada entre vários projetos. Para mais informações sobre reservas, consulte Escolher um tipo de reserva.

Durabilidade dos dados

As arquiteturas neste documento usam o Backup e DR para criar, armazenar e gerenciar backups de VMs do Compute Engine. O backup e a DR armazenam os dados de backup no formato original legível pelo aplicativo. Quando necessário, é possível restaurar cargas de trabalho para produção usando diretamente dados do armazenamento de backup de longo prazo e evitar a necessidade de preparar ou mover dados.

O Backup e DR oferece suporte a dois métodos para criar backups:

  • Armazenamento do backup vault: os dados de backup são armazenados na mesma região dos dados de origem e não podem ser alterados ou excluídos.
  • Armazenamento autogerenciado: os usuários autorizados podem modificar ou excluir os dados de backup, e você pode armazenar dados em várias regiões.

Para mais informações, consulte a seguinte documentação:

Mais considerações sobre confiabilidade

Ao criar a arquitetura de nuvem para sua carga de trabalho, analise as práticas recomendadas e as recomendações relacionadas à confiabilidade fornecidas na documentação a seguir:

Otimização de custos

Nesta seção, você encontra orientações para otimizar o custo de configuração e operação de uma topologia Google Cloud criada usando essas arquiteturas de referência.

Tipos de máquina de VM

Para ajudar você a otimizar a utilização de recursos das instâncias de VM, o Compute Engine fornece recomendações de tipo de máquina. Use as recomendações para escolher os tipos de máquina que atendem aos requisitos de computação da carga de trabalho. Para cargas de trabalho com requisitos de recursos previsíveis, é possível personalizar o tipo de máquina de acordo com suas necessidades e economizar dinheiro usando tipos de máquinas personalizados.

Licenças de produtos da Oracle

Você é responsável por adquirir licenças para os produtos da Oracle que implanta no Compute Engine e por obedecer aos termos e condições das licenças da Oracle. Para mais informações, consulte Licenciamento de software da Oracle no ambiente de computação em nuvem.

Mais considerações sobre custo

Ao criar a arquitetura para a carga de trabalho, considere também as práticas recomendadas gerais e as recomendações fornecidas no Google Cloud Framework Well-Architected: otimização de custos.

Eficiência operacional

Nesta seção, descrevemos os fatores que você precisa considerar ao usar essas arquiteturas de referência para projetar uma topologia Google Cloud que possa ser operada de maneira eficiente.

Imagens do Oracle Linux

Para suas VMs, use imagens do Oracle Linux disponíveis no Compute Engine ou importe imagens do Oracle Linux que você cria e mantém. Também é possível criar e usar imagens do SO personalizadas que incluem as configurações e o software necessários para seus aplicativos. É possível agrupar suas imagens personalizadas em uma família de imagens personalizadas. Uma família de imagens sempre indica a imagem mais recente que ela contém, permitindo que seus modelos e scripts de instâncias usem essa imagem sem precisar atualizar as referências para uma versão específica de imagem. É necessário atualizar regularmente as imagens personalizadas para incluir as atualizações e os patches de segurança fornecidos pelo fornecedor do SO.

Conectividade do servidor de aplicativos com o banco de dados

Para conexões dos seus aplicativos com o Oracle Database, recomendamos que você use o nome DNS interno zonal da VM do banco de dados em vez do endereço IP.O Google Cloud resolve automaticamente o nome DNS para o endereço IP interno principal da VM. Uma vantagem adicional dessa abordagem é que você não precisa reservar e atribuir endereços IP internos estáticos para as VMs de banco de dados.

Documentação e suporte da Oracle

Os produtos da Oracle executados em VMs do Compute Engine têm preocupações operacionais semelhantes aos produtos da Oracle executados no local. No entanto, não é necessário gerenciar a infraestrutura de computação, rede e armazenamento subjacente.

Observabilidade para aplicativos Oracle

Para implementar a capacidade de observação das cargas de trabalho do Oracle implantadas no Google Cloud, use os serviços do Google Cloud Observability ou o Oracle Enterprise Manager. Escolha uma estratégia de monitoramento adequada de acordo com seus requisitos e restrições. Por exemplo, se você executar outras cargas de trabalho no Google Cloud além das cargas de trabalho da Oracle, poderá usar os serviços do Google Cloud Observability para criar um painel de operações unificado para todas as cargas de trabalho.

Mais considerações operacionais

Ao criar a arquitetura para a carga de trabalho, considere as práticas recomendadas gerais e as recomendações para eficiência operacional descritas no Google Cloud Framework Well-Architected: excelência operacional.

Otimização de desempenho

Nesta seção, descrevemos os fatores que você precisa considerar ao usar essas arquiteturas de referência para projetar uma topologia no Google Cloud que atenda aos requisitos de desempenho das suas cargas de trabalho.

Desempenho de computação

O Compute Engine oferece uma ampla variedade de tipos de máquinas predefinidos e personalizáveis que podem ser escolhidos de acordo com os requisitos de desempenho das suas cargas de trabalho.

  • Para as VMs que hospedam os aplicativos e o banco de dados, escolha um tipo de máquina adequado com base nos seus requisitos de desempenho. Para conferir uma lista dos tipos de máquinas disponíveis que oferecem suporte a volumes do Hyperdisk e atendem aos seus requisitos de desempenho e outros, use a tabela Comparação de séries de máquinas.
  • Para a VM que hospeda as instâncias do Oracle Database, recomendamos usar um tipo de máquina da série C4 da família de máquinas de uso geral. Os tipos de máquinas C4 oferecem alto desempenho consistente para cargas de trabalho de banco de dados.

Desempenho da rede

O Compute Engine tem um limite por VM para a largura de banda de rede de saída. Esse limite depende do tipo de máquina da VM e se o tráfego é roteado pela mesma rede VPC da VM de origem. Para VMs com determinados tipos de máquinas, é possível melhorar o desempenho da rede e aumentar a largura de banda máxima de saída ativando a rede Tier_1. Para mais informações, consulte Configurar o desempenho de rede Tier_1 por VM.

Desempenho de armazenamento do hiperdisco

As arquiteturas descritas neste documento usam volumes de hiperdisco para todos os discos de inicialização das VMs e para os discos de dados da VM de banco de dados. O Hyperdisk permite escalonar o desempenho e a capacidade de forma dinâmica. É possível ajustar as IOPS provisionadas, a capacidade de processamento e o tamanho de cada volume para atender às necessidades de desempenho e capacidade de armazenamento da carga de trabalho. O desempenho dos volumes do Hyperdisk depende do tipo de Hyperdisk e do tipo de máquina das VMs a que os volumes estão anexados. Para mais informações sobre limites e ajuste de desempenho do Hyperdisk, consulte a seguinte documentação:

Mais considerações de desempenho

Ao criar a arquitetura para a carga de trabalho, considere as práticas recomendadas gerais e as recomendações fornecidas em Google Cloud Framework Well-Architected: otimização de desempenho.

A seguir

Colaboradores

Autores:

Outros colaboradores: