Oracle E-Business Suite com a base de dados Oracle no Compute Engine

Last reviewed 2025-08-13 UTC

Este documento fornece arquiteturas de referência para ajudar a criar a infraestrutura para executar aplicações do Oracle E‑Business Suite com a base de dados Oracle em VMs do Compute Engine no Google Cloud. O Oracle E-Business Suite é um conjunto de aplicações empresariais para funções empresariais, como finanças, recursos humanos, cadeia de fornecimento e relação com o cliente.

O público-alvo deste documento são os arquitetos e os administradores da nuvem de bases de dados Oracle e aplicações Oracle E‑Business Suite. O documento pressupõe que a sua equipa está familiarizada com a base de dados Oracle e a arquitetura e a pilha de tecnologia do Oracle E‑Business Suite.

Se precisar de usar o Oracle Exadata ou o Oracle Real Application Clusters (Oracle RAC), pode migrar as suas aplicações para o Google Cloud e executar as suas bases de dados no Oracle Database@Google Cloud. Para mais informações, consulte o artigo Oracle E-Business Suite no Compute Engine com o Oracle Exadata.

Arquitetura

Consoante o seu exemplo de utilização e requisitos de disponibilidade e recuperação de desastres (RD), pode escolher um dos seguintes Google Cloud arquétipos de implementação para executar aplicações do Oracle E‑Business Suite no Google Cloud:

  • Zonal: as suas aplicações são executadas numa única zona. Google CloudEste arquétipo de implementação é adequado para ambientes de desenvolvimento e teste, bem como para aplicações não críticas que não precisam de alta disponibilidade.
  • Regional: as suas aplicações são executadas de forma independente em duas ou mais zonas numa única Google Cloud região. Recomendamos este arquétipo de implementação para aplicações que não sejam essenciais, mas que precisem de robustez contra falhas de zonas.
  • Multirregional: as suas aplicações são executadas de forma independente em várias zonas em duas ou mais Google Cloud regiões, no modo ativo-ativo ou ativo-passivo. Este arquétipo de implementação é ideal para suportar cenários de recuperação de desastres. Recomendamos este arquétipo para aplicações de missão crítica que precisam de resiliência a interrupções e desastres na região.

A escolha de um arquétipo de implementação ajuda a simplificar as decisões subsequentes relativas aos Google Cloud produtos e funcionalidades de que precisa para a sua arquitetura.

As secções seguintes apresentam quatro opções de arquitetura. Cada opção baseia-se num dos arquétipos de implementação:

Arquitetura zonal

O diagrama seguinte mostra uma arquitetura para aplicações do Oracle E-Business Suite com a base de dados Oracle a ser executada numa única zona numaGoogle Cloud região. Esta arquitetura está alinhada com o arquétipo de implementação zonal.

Uma arquitetura para aplicações do Oracle E-Business Suite é executada numa única zona numa região Google Cloud .

A arquitetura no diagrama anterior inclui os seguintes componentes:

Componente Descrição
Balanceador de carga de aplicações externo regional O balanceador de carga recebe e distribui pedidos de utilizadores para as aplicações 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 as suas aplicações contra ameaças como ataques DDoS e XSS.
Oracle E‑Business Suite (BYOL)

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

Traz as suas próprias licenças (BYOL) para o Oracle E-Business Suite e gere as VMs e as aplicações.
Binários e dados da aplicação Uma instância zonal do Filestore contém os binários e os dados da aplicação. A instância do Filestore está montada nas VMs do Compute Engine que alojam os componentes da camada de aplicação.
Oracle Database (BYOL)

As aplicações do Oracle E-Business Suite usam uma instância da base de dados Oracle implementada numa VM do Compute Engine. Os discos de arranque e de dados da VM são volumes Hyperdisk.

Traz a sua própria licença (BYOL) para a instância da base de dados do Oracle e gere a VM e a base de dados.
Cópias de segurança de aplicações e bases de dados As cópias de segurança dos dados da aplicação e da base de dados são criadas, armazenadas e geridas através do serviço de cópia de segurança e recuperação de desastres.
Rede de nuvem virtual privada (VPC) e sub-redes

Todos os Google Cloud recursos na arquitetura usam uma única rede VPC. As VMs que alojam a camada de aplicação e a base de dados usam sub-redes separadas.

Consoante os seus requisitos, pode optar por criar uma arquitetura que use várias redes VPC. Para mais informações, consulte Decidir se deve criar várias redes VPC.
Gateway de NAT pública A arquitetura inclui um gateway Cloud NAT para ligações de saída seguras das VMs do Compute Engine, que têm apenas endereços IP internos. Por exemplo, as VMs podem aceder ao servidor Oracle Linux Yum para transferir pacotes do SO.
Cloud Interconnect e Cloud VPN Para ligar a sua rede no local à rede VPC em Google Cloud, pode usar o Cloud Interconnect ou a Cloud VPN. Para informações sobre as vantagens relativas de cada abordagem, consulte o artigo Escolher um produto de conetividade de rede.

Arquitetura zonal com uma DMZ

O diagrama seguinte mostra uma arquitetura com duas camadas de aplicação do Oracle E-Business Suite independentes em execução em VMs do Compute Engine. Uma das camadas de aplicação é uma zona desmilitarizada (DMZ), que serve utilizadores externos das aplicações Oracle E-Business Suite. A outra camada serve utilizadores internos. Ambas as camadas de aplicação são executadas numa única zona numa região e usam uma única instância da base de dados Oracle. Google Cloud Tal como a arquitetura na secção anterior, esta arquitetura está alinhada com o arquétipo de implementação zonal.

Uma arquitetura para aplicações do Oracle E-Business Suite é executada numa única zona com uma DMZ numa região Google Cloud .

A arquitetura no diagrama anterior inclui os seguintes componentes:

Componente Descrição
Balanceador de carga de aplicações externo regional O balanceador de carga externo recebe e distribui pedidos de utilizadores externos para a camada de aplicação virada para o exterior.
Balanceador de carga de aplicações interno regional O balanceador de carga interno recebe e distribui pedidos de utilizadores internos para uma camada de aplicação interna.
Política de segurança do Cloud Armor A política de segurança do Cloud Armor ajuda a proteger as suas aplicações contra ameaças externas, como ataques DDoS e XSS.
Oracle E‑Business Suite (BYOL)

Os componentes da camada de aplicação do Oracle E-Business Suite (servidor HTTP da Oracle, servidor WebLogic da Oracle e um servidor de processamento concorrente) são executados em VMs do Compute Engine. Cada VM aloja uma instância independente da camada de aplicação. As aplicações internas e externas são disponibilizadas a partir de conjuntos distintos de VMs. O disco de arranque de cada VM é um volume do Hyperdisk.

Traz as suas próprias licenças (BYOL) para o Oracle E-Business Suite e gere as VMs e as aplicações.
Binários e dados da aplicação Uma instância zonal do Filestore contém os binários e os dados da aplicação. A instância do Filestore está montada nas VMs do Compute Engine que alojam os componentes da camada de aplicação.
Oracle Database (BYOL)

As aplicações do Oracle E-Business Suite usam uma instância da base de dados Oracle implementada numa VM do Compute Engine. Os discos de arranque e de dados da VM são volumes Hyperdisk.

Traz a sua própria licença (BYOL) para a instância da base de dados do Oracle e gere a VM e a base de dados.
Cópias de segurança de aplicações e bases de dados As cópias de segurança dos dados da aplicação e da base de dados são criadas, armazenadas e geridas através da solução Backup and DR.
Rede de nuvem virtual privada (VPC) e sub-redes

Todos os Google Cloud recursos na arquitetura usam uma única rede VPC. As VMs que alojam a camada de aplicação e a base de dados usam sub-redes separadas.

Consoante os seus requisitos, pode optar por criar uma arquitetura que use várias redes VPC. Para mais informações, consulte Decidir se deve criar várias redes VPC.
Gateway de NAT pública A arquitetura inclui um gateway Cloud NAT público para ligações de saída seguras das VMs do Compute Engine, que têm apenas endereços IP internos. Por exemplo, as VMs podem aceder ao servidor Oracle Linux Yum para transferir pacotes do SO.
Cloud Interconnect e Cloud VPN Para ligar a sua rede no local à rede VPC em Google Cloud, pode usar o Cloud Interconnect ou a Cloud VPN. Os administradores e os utilizadores internos da aplicação usam estas ligações para aceder aos recursos e às aplicações, respetivamente. Para informações sobre as vantagens relativas de cada abordagem, consulte o artigo Escolher um produto de conetividade de rede.

Arquitetura regional

O diagrama seguinte mostra uma arquitetura em que as aplicações do Oracle E-Business Suite são executadas no modo ativo-ativo em VMs do Compute Engine distribuídas por duas zonas numa Google Cloud região. Ambas as implementações de aplicações usam uma instância principal da base de dados Oracle que é executada numa VM numa das zonas. O Oracle Data Guard gere a replicação e a comutação por falha da base de dados para uma instância do Oracle Database em espera na segunda zona. Esta arquitetura baseia-se no arquétipo de implementação regional.

Uma arquitetura para aplicações do Oracle E-Business Suite é executada em duas zonas numa região Google Cloud .

A arquitetura no diagrama anterior inclui os seguintes componentes:

Componente Descrição
Balanceador de carga de aplicações externo regional O balanceador de carga recebe e distribui pedidos de utilizadores para as aplicações 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 as suas aplicações contra ameaças como ataques DDoS distribuídos e XSS.
Oracle E‑Business Suite (BYOL)

Os componentes da camada de aplicação do Oracle E-Business Suite (servidor HTTP da Oracle, servidor WebLogic da Oracle e um servidor de processamento concorrente) são executados em VMs do Compute Engine que são distribuídas por duas zonas. Cada MV aloja uma instância independente da camada de aplicação. O disco de arranque de cada VM é um volume do Hyperdisk.

Traz as suas próprias licenças (BYOL) para o Oracle E-Business Suite e gere as VMs e as aplicações.
Binários e dados da aplicação Uma instância regional do Filestore contém os binários e os dados da aplicação. A instância do Filestore está montada em todas as VMs do Compute Engine que alojam os componentes da camada de aplicação em ambas as zonas.
Oracle Database (BYOL)

As aplicações do Oracle E-Business Suite usam um par principal/em espera de instâncias da base de dados Oracle implementadas em VMs do Compute Engine em zonas separadas. Os discos de arranque e de dados da VM são volumes Hyperdisk.

O Oracle Data Guard gere a replicação e a comutação por falha da base de dados da instância principal para a instância de reserva.

Traz as suas próprias licenças (BYOL) para as instâncias da base de dados do Oracle e gere as VMs e as bases de dados.
Cópias de segurança de aplicações e bases de dados As cópias de segurança dos dados da aplicação e da base de dados são criadas, armazenadas e geridas através da solução Backup and DR.
Rede de nuvem virtual privada (VPC) e sub-redes

Todos os Google Cloud recursos na arquitetura usam uma única rede VPC. As VMs que alojam a camada de aplicação e a base de dados usam sub-redes separadas.

Consoante os seus requisitos, pode optar por criar uma arquitetura que use várias redes VPC. Para mais informações, consulte Decidir se deve criar várias redes VPC.
Gateway de NAT pública A arquitetura inclui um gateway Cloud NAT público para ligações de saída seguras das VMs do Compute Engine, que têm apenas endereços IP internos. Por exemplo, as VMs podem aceder ao servidor Oracle Linux Yum para transferir pacotes do SO.
Cloud Interconnect e Cloud VPN Para ligar a sua rede no local à rede VPC em Google Cloud, pode usar o Cloud Interconnect ou a Cloud VPN. Para informações sobre as vantagens relativas de cada abordagem, consulte o artigo Escolher um produto de conetividade de rede.

Arquitetura ativa-passiva multirregional (DR)

O diagrama seguinte mostra uma arquitetura em que as aplicações do Oracle E-Business Suite são executadas no modo ativo-ativo em VMs do Compute Engine distribuídas por duas zonas numa Google Cloud região. Ambas as implementações de aplicações usam uma instância principal da base de dados Oracle que é executada numa VM numa das zonas. O Oracle Data Guard gere a replicação e a comutação por falha da base de dados para uma instância do Oracle Database em espera na segunda zona. A arquitetura inclui uma réplica à escala mais pequena da pilha de aplicações numa região remota (de alternativa) para a recuperação de desastres. Tal como a arquitetura na secção anterior, esta arquitetura baseia-se no arquétipo de implementação regional.

Uma arquitetura para aplicações do Oracle E‑Business Suite é executada em duas zonas numa região Google Cloud , com uma réplica numa região remota para recuperação de desastres.

A arquitetura no diagrama anterior inclui os seguintes componentes:

Componente Descrição
Política de encaminhamento de comutação por falha de DNS Uma zona pública do Cloud DNS configurada com uma política de encaminhamento de comutação por falha encaminha os pedidos dos utilizadores para o balanceador de carga na região que está a publicar pedidos.
Balanceador de carga de aplicações externo regional O balanceador de carga recebe e distribui pedidos de utilizadores para as aplicações 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 as suas aplicações contra ameaças como ataques DDoS distribuídos e XSS.
Oracle E‑Business Suite (BYOL)

Os componentes da camada de aplicação do Oracle E-Business Suite (servidor HTTP da Oracle, servidor WebLogic da Oracle e um servidor de processamento concorrente) são executados em VMs do Compute Engine que são distribuídas por duas zonas na região principal. Cada MV aloja uma instância independente da camada de aplicação. O disco de arranque de cada VM é um volume do Hyperdisk.

Traz as suas próprias licenças (BYOL) para o Oracle E-Business Suite e gere as VMs e as aplicações.
Binários e dados da aplicação

Uma instância regional do Filestore na região principal contém os binários da aplicação e os dados. A instância do Filestore está montada em todas as VMs do Compute Engine que alojam os componentes da camada de aplicação em ambas as zonas na região principal. A instância do Filestore é replicada para a região de comutação por falha.
Oracle Database (BYOL)

As aplicações do Oracle E-Business Suite usam um par principal/em espera de instâncias da base de dados do Oracle que são implementadas em VMs do Compute Engine em zonas separadas na região principal. Os discos de arranque e de dados da VM são volumes Hyperdisk.

O Oracle Data Guard gere a replicação e a comutação por falha da base de dados da instância principal para a instância de reserva.

Traz as suas próprias licenças (BYOL) para as instâncias da base de dados do Oracle e gere as VMs e as bases de dados.
Cópias de segurança de aplicações e bases de dados As cópias de segurança dos dados da aplicação e da base de dados são criadas, armazenadas e geridas através da solução Backup and DR.
Rede de nuvem virtual privada (VPC) e sub-redes

Todos os Google Cloud recursos na arquitetura usam uma única rede VPC. As VMs que alojam a camada de aplicação e a base de dados usam sub-redes regionais separadas.

Consoante os seus requisitos, pode optar por criar uma arquitetura que use várias redes VPC. Para mais informações, consulte Decidir se deve criar várias redes VPC.
Gateway de NAT pública A arquitetura inclui um gateway Cloud NAT público em cada região para ligações de saída seguras a partir das VMs do Compute Engine, que têm apenas endereços IP internos. Por exemplo, as VMs podem aceder ao servidor Oracle Linux Yum para transferir pacotes do SO.
Cloud Interconnect e Cloud VPN Para ligar a sua rede no local à rede VPC em Google Cloud, pode usar o Cloud Interconnect ou a Cloud VPN. Para informações sobre as vantagens relativas de cada abordagem, consulte o artigo Escolher um produto de conetividade de rede.

Produtos usados

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

  • Compute Engine: um serviço de computação seguro e personalizável que lhe permite criar e executar VMs na infraestrutura da Google.
  • Google Cloud Hyperdisk: um serviço de armazenamento na rede que pode usar para aprovisionar e dimensionar dinamicamente volumes de armazenamento em bloco com um desempenho configurável e previsível.
  • Filestore: um serviço que oferece armazenamento de ficheiros de elevado desempenho e totalmente gerido no qual pode estabelecer ligação a vários tipos de clientes. Google Cloud
  • Serviço de cópia de segurança e recuperação de desastres: um serviço de cópia de segurança e recuperação seguro e gerido centralmente para Google Cloud cargas de trabalho que ajuda a proteger os dados de cópia de segurança contra eliminação maliciosa ou acidental.
  • Cloud DNS: um serviço que fornece um serviço de DNS resiliente e de baixa latência a partir da rede mundial da Google.
  • Cloud Load Balancing: um portefólio de balanceadores de carga globais, escaláveis e de elevado desempenho, bem como balanceadores de carga regionais.
  • Google Cloud Armor: um serviço de segurança de rede que oferece regras de firewall de aplicação Web (WAF) e ajuda a proteger contra ataques DDoS e de aplicações.
  • Nuvem virtual privada (VPC): um sistema virtual que oferece funcionalidade de rede global e escalável para as suas Google Cloud cargas de trabalho. A VPC inclui o intercâmbio da rede da VPC, o Private Service Connect, o acesso a serviços privados e a VPC partilhada.
  • Cloud NAT: um serviço que oferece tradução de endereços de rede de alto desempenho gerida pela Google Cloud.
  • Cloud Interconnect: um serviço que expande a sua rede externa para a rede Google através de uma ligação de alta disponibilidade e baixa latência.
  • VPN na nuvem: um serviço que estende de forma segura a sua rede ponto a ponto à rede da Google através de um canal VPN IPsec.

Estas arquiteturas de referência usam os seguintes produtos Oracle:

  • Oracle E-Business Suite: um conjunto de aplicações para operações empresariais, como finanças, recursos humanos e cadeia de abastecimento.
  • Oracle Database: um sistema de gestão de base de dados relacional (RDBMS) que estende o modelo relacional a um modelo relacional de objetos.
  • Oracle Data Guard: um conjunto de serviços para criar, manter, gerir e monitorizar uma ou mais bases de dados em espera.

É responsável pela obtenção de licenças para os produtos Oracle que implementar no Google Cloude pela conformidade com os termos de utilização das licenças Oracle.

Considerações de design

Esta secção descreve os fatores de design, as práticas recomendadas e as recomendações de design que deve considerar quando usa estas arquiteturas de referência para desenvolver uma topologia que cumpra os seus requisitos específicos de segurança, fiabilidade, eficiência operacional, custo e desempenho.

Google Cloud

Design do sistema

Esta secção fornece orientações para ajudar a escolher as Google Cloud regiões para a sua implementação e a selecionar os Google Cloud serviços adequados.

Seleção de região

Quando escolher as Google Cloud regiões onde as suas aplicações têm de ser implementadas, considere os seguintes fatores e requisitos:

  • Disponibilidade de Google Cloud serviços em cada região. Para mais informações, consulte Produtos disponíveis por localização.
  • Disponibilidade dos tipos de máquinas do Compute Engine em cada região. Para mais informações, consulte o artigo Regiões e zonas.
  • Requisitos de latência do utilizador final.
  • Custo dos Google Cloud recursos.
  • Custos de transferência de dados entre regiões.
  • Requisitos regulamentares.

Alguns destes fatores e requisitos podem envolver compromissos. Por exemplo, a região mais rentável pode não ter a menor pegada de carbono. Para mais informações, consulte o artigo Práticas recomendadas para a seleção de regiões do Compute Engine.

Migração de base de dados

Quando planeia migrar implementações da base de dados Oracle no local para o Google Cloud, avalie o seu ambiente de base de dados atual e receba recomendações de configuração e dimensionamento através da ferramenta Database Migration Assessment (DMA).

Para migrar dados no local para implementações da base de dados Oracle no Google Cloud, pode usar ferramentas Oracle padrão, como o Oracle GoldenGate.

Opções de armazenamento

Para as VMs do Compute Engine na arquitetura, pode usar volumes de arranque do Hyperdisk ou do Persistent Disk. Os volumes Hyperdisk oferecem melhor desempenho, flexibilidade e eficiência do que o disco persistente. Com o Hyperdisk Balanced, pode aprovisionar IOPS e débito de forma separada e dinâmica, o que lhe permite ajustar o volume a uma grande variedade de cargas de trabalho.

Para armazenar binários de aplicações, use o Filestore. Os ficheiros que armazena numa instância do Filestore regional são replicados de forma síncrona em três zonas na região. Esta replicação ajuda a garantir a alta disponibilidade e a robustez contra falhas de zonas. Para garantir a robustez contra interrupções de regiões, pode replicar uma instância do Filestore para uma região diferente. Para mais informações, consulte o artigo Replicação de instâncias.

Quando cria armazenamento para as suas cargas de trabalho, considere as características funcionais das cargas de trabalho, os requisitos de resiliência, as expetativas de desempenho e os objetivos de custo. Para mais informações, consulte o artigo Crie uma estratégia de armazenamento ideal para a sua carga de trabalho na nuvem.

Design de rede

Escolha um design de rede que cumpra os seus requisitos empresariais e técnicos. Pode usar uma única rede VPC ou várias redes VPC. Para mais informações, consulte a seguinte documentação:

Análise de dados

Para análises avançadas, pode usar o Google Cloud Cortex Framework para carregar dados das suas aplicações Oracle E-Business Suite para o BigQuery. Para mais informações, consulte o artigo Cortex Framework: integração com o Oracle E‑Business Suite.

Segurança, privacidade e conformidade

Esta secção descreve os fatores a ter em conta quando usa estas arquiteturas de referência para conceber uma topologia que cumpra os requisitos de segurança e conformidade das suas cargas de trabalho. Google Cloud

Proteção contra ameaças externas

Para proteger a sua aplicação contra ameaças como ataques de negação de serviço distribuída (DDoS) e scripting entre sites (XSS), pode usar as políticas de segurança do Google Cloud Armor. Cada política é um conjunto de regras que especifica determinadas condições que devem ser avaliadas e ações a tomar quando as condições são cumpridas. 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 específico ou a um intervalo CIDR, o tráfego tem de ser recusado. Também pode aplicar regras de firewall de app Web (WAF) pré-configuradas. Para mais informações, consulte a Vista 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 a partir da Internet. Não atribua endereços IP externos às VMs. Google Cloud Os recursos que têm apenas um endereço IP interno e privado podem continuar a aceder a determinadas APIs e serviços Google através do Private Service Connect ou do acesso privado à Google. Para mais informações, consulte Opções de acesso privado para serviços.

Para ativar ligações de saída seguras a partir de Google Cloud recursos que têm apenas endereços IP privados, como as VMs do Compute Engine nesta arquitetura de referência, pode usar o proxy Web seguro 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 predefinidas, recomendamos que crie contas de serviço dedicadas e especifique os recursos aos quais a conta de serviço pode aceder. A conta de serviço predefinida tem uma vasta gama de autorizações, incluindo algumas que podem não ser necessárias. Pode personalizar contas de serviço dedicadas para terem apenas as autorizações essenciais. Para mais informações, consulte o artigo Limite os privilégios da conta de serviço.

Segurança SSH

Para melhorar a segurança das ligações SSH às VMs do Compute Engine na sua arquitetura, implemente o Identity-Aware Proxy (IAP) e a API Cloud OS Login. O IAP permite-lhe controlar o acesso à rede com base na identidade do utilizador e nas políticas de gestão de identidade e de acesso (IAM). A API Cloud OS Login permite-lhe controlar o acesso SSH do Linux com base na identidade do utilizador e nas políticas de IAM. Para mais informações sobre a gestão do acesso à rede, consulte as Práticas recomendadas para controlar o acesso ao início de sessão SSH.

Encriptação de disco

Por predefinição, os dados armazenados em volumes do Hyperdisk e no Filestore são encriptados através da encriptação AES-256.Google-owned and Google-managed encryption keysComo camada adicional de proteção, pode optar por encriptar os dados de conversão usando chaves que detém e gere no Cloud Key Management Service (Cloud KMS). Google-owned and managed key Para mais informações, consulte Acerca da encriptação de disco para volumes do Hyperdisk e Encriptar dados com chaves de encriptação geridas pelo cliente para o Filestore.

Segurança de redes

Para controlar o tráfego de rede entre os recursos na arquitetura, tem de configurar as políticas da firewall de nova geração (NGFW) do Google Cloud adequadas.

Mais considerações de segurança

Quando criar a arquitetura para a sua carga de trabalho, considere as práticas recomendadas e as recomendações de segurança ao nível da plataforma fornecidas no projeto de base empresarial e na Google Cloud estrutura bem arquitetada: segurança, privacidade e conformidade.

Fiabilidade

Esta secção descreve os fatores de design a considerar quando usa estas arquiteturas de referência para criar e operar uma infraestrutura fiável para a sua implementação no Google Cloud.

Robustez da camada de aplicação contra falhas de VMs

Com todas as opções de arquitetura neste documento, se algumas (mas não todas) das VMs de aplicações falharem, as aplicações continuam a estar disponíveis porque o equilibrador de carga encaminha os pedidos para outras VMs de aplicações.

Por vezes, uma VM de aplicação pode estar em execução e disponível, mas podem existir problemas com a própria aplicação. A aplicação pode bloquear, falhar ou não ter memória suficiente. Neste cenário, a VM não responde às verificações de estado do balanceador de carga e o balanceador de carga não encaminha o tráfego para a VM que não responde.

Robustez da base de dados contra falhas de VMs

Numa arquitetura zonal, se a VM da base de dados falhar, pode restaurar a base de dados para produção numa nova VM através das cópias de segurança armazenadas no Backup and DR. Depois de restaurar a base de dados, tem de associar as aplicações à nova instância da base de dados.

Se a consistência dos dados for uma prioridade, configure uma instância de base de dados principal e uma de reserva, de preferência em VMs que estejam em zonas diferentes, conforme mostrado na arquitetura regional. Para a replicação e a comutação por falha para a instância da base de dados em espera, use o Data Guard. O Data Guard ajuda a garantir a consistência replicando as transações para a instância de espera antes de as confirmar na instância principal. A arquitetura de base de dados principal-suplente envolve custos adicionais de infraestrutura e licenciamento.

Numa arquitetura regional ou multirregional, se a VM que aloja a base de dados principal falhar, o Oracle Data Guard inicia uma comutação por falha para a instância da base de dados Oracle em espera. Durante o processo de comutação por falha, as aplicações não podem aceder à base de dados.

Robustez contra falhas de zonas

Numa arquitetura zonal, se a zona que aloja a sua implementação tiver uma indisponibilidade, as aplicações e a base de dados ficam inativas. Pode restaurar as aplicações e a base de dados para produção numa zona ou região diferente através das cópias de segurança armazenadas no Backup and DR.

Numa arquitetura regional, se uma das zonas tiver uma indisponibilidade, o balanceador de carga encaminha os pedidos para instâncias das aplicações que são executadas 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 Hyperdisk durante uma interrupção de uma única zona, pode usar o Hyperdisk Balanced de alta disponibilidade. Quando os dados são gravados num volume Hyperdisk Balanced de alta disponibilidade, os dados são replicados de forma síncrona entre duas zonas na mesma região.

Robustez contra interrupções de regiões

Se ocorrer uma interrupção ao nível de uma região, as aplicações e a base de dados ficam indisponíveis. Pode restaurar as aplicações e a base de dados para produção numa região diferente através das cópias de segurança armazenadas no serviço de cópia de segurança e recuperação de desastres. Para reduzir o tempo de inatividade, use a arquitetura ativa-passiva (DR) multirregional. Depois de apresentar as aplicações e a base de dados, tem de atualizar a política de encaminhamento de DNS para encaminhar o tráfego para o equilibrador de carga na região de alternativa.

Para aplicações essenciais para o negócio que não podem tolerar inatividade, mesmo quando ocorre uma interrupção na região, use o arquétipo de implementação ativo-ativo multirregional.

Planeamento de capacidade de VMs

Para garantir que a capacidade das VMs do Compute Engine está disponível quando as VMs precisam de ser aprovisionadas, pode criar reservas. Uma reserva oferece capacidade garantida numa zona específica para um número especificado de VMs de um tipo de máquina à sua escolha. Uma reserva pode ser específica de um projeto ou partilhada em vários projetos. Para mais informações sobre reservas, consulte o artigo Escolha um tipo de reserva.

Durabilidade dos dados

As arquiteturas neste documento usam o Backup and DR para criar, armazenar e gerir cópias de segurança de VMs do Compute Engine. A cópia de segurança e a recuperação de desastres armazenam os dados de cópia de segurança no formato original legível pela aplicação. Quando necessário, pode restaurar cargas de trabalho para produção usando diretamente dados do armazenamento de cópias de segurança a longo prazo e evitar a necessidade de preparar ou mover dados.

A cópia de segurança e a RD suportam dois métodos para criar cópias de segurança:

  • Armazenamento do cofre de cópias de segurança: os dados de cópia de segurança são armazenados na mesma região que os dados de origem e não podem ser alterados nem eliminados.
  • Armazenamento autogerido: os utilizadores autorizados podem modificar ou eliminar os dados de cópia de segurança, e pode armazenar dados em várias regiões.

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

Mais considerações de fiabilidade

Quando criar a arquitetura de nuvem para a sua carga de trabalho, reveja as práticas recomendadas e as recomendações relacionadas com a fiabilidade que são fornecidas na seguinte documentação:

Otimização de custos

Esta secção fornece orientações para otimizar o custo de configuração e funcionamento de uma topologia criada com estas arquiteturas de referência. Google Cloud

Tipos de máquinas de VMs

Para ajudar a otimizar a utilização de recursos das suas instâncias de VM, o Compute Engine oferece recomendações de tipo de máquina. Use as recomendações para escolher tipos de máquinas que correspondam aos requisitos de computação da sua carga de trabalho. Para cargas de trabalho com requisitos de recursos previsíveis, pode personalizar o tipo de máquina de acordo com as suas necessidades e poupar dinheiro usando tipos de máquinas personalizados.

Licenças de produtos Oracle

É responsável pela obtenção de licenças para os produtos Oracle que implementa no Compute Engine, e é responsável por agir em conformidade com os termos de utilização das licenças Oracle. Para mais informações, consulte o artigo Licenciamento de software Oracle no ambiente de computação em nuvem.

Mais considerações sobre o custo

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

Eficiência operacional

Esta secção descreve os fatores a ter em conta quando usa estas arquiteturas de referência para criar uma Google Cloud topologia que pode operar de forma eficiente.

Imagens do Oracle Linux

Para as suas VMs, pode usar imagens do Oracle Linux disponíveis no Compute Engine ou pode importar imagens do Oracle Linux que cria e mantém. Também pode criar e usar imagens de SO personalizadas que incluem as configurações e o software de que as suas aplicações precisam. Pode agrupar as suas imagens personalizadas numa família de imagens personalizadas. Uma família de imagens aponta sempre para a imagem mais recente nessa família, pelo que os seus modelos de instâncias e scripts podem usar essa imagem sem ter de atualizar referências a uma versão de imagem específica. Tem de atualizar regularmente as suas imagens personalizadas para incluir as atualizações e os patches de segurança fornecidos pelo fornecedor do SO.

Conetividade do servidor de aplicações à base de dados

Para ligações das suas aplicações à base de dados Oracle, recomendamos que use o nome DNS interno zonal da VM da base de dados, em vez do respetivo endereço IP.O Google Cloud resolve automaticamente o nome DNS para o endereço IP interno principal da VM. Uma vantagem adicional desta abordagem é que não precisa de reservar e atribuir endereços IP internos estáticos às VMs da base de dados.

Documentação e apoio técnico da Oracle

Os produtos Oracle executados em VMs do Compute Engine têm preocupações operacionais semelhantes às dos produtos Oracle executados no local. No entanto, não tem de gerir a infraestrutura subjacente de computação, rede e armazenamento.

Observabilidade para aplicações Oracle

Para implementar a observabilidade para cargas de trabalho Oracle implementadas no Google Cloud, pode usar os serviços de observabilidade do Google Cloud ou o Oracle Enterprise Manager. Escolha uma estratégia de monitorização adequada consoante os seus requisitos e restrições. Por exemplo, se executar outras cargas de trabalho, Google Cloud além das cargas de trabalho Oracle, pode usar os serviços de observabilidade do Google Cloud para criar um painel de controlo de operações unificado para todas as cargas de trabalho.

Mais considerações operacionais

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

Otimização do desempenho

Esta secção descreve os fatores a ter em conta quando usa estas arquiteturas de referência para criar uma topologia que cumpra os requisitos de desempenho das suas cargas de trabalho. Google Cloud

Desempenho de computação

O Compute Engine oferece uma vasta gama de tipos de máquinas predefinidos e personalizáveis que pode escolher consoante os requisitos de desempenho das suas cargas de trabalho.

  • Para as VMs que alojam as aplicações e a base de dados, escolha um tipo de máquina adequado com base nos seus requisitos de desempenho. Para obter uma lista dos tipos de máquinas disponíveis que suportam volumes do Hyperdisk e que cumprem os seus requisitos de desempenho e outros requisitos, use a tabela Comparação de séries de máquinas.
  • Para a VM que aloja as instâncias da base de dados Oracle, recomendamos que use um tipo de máquina na série de máquinas C4 da família de máquinas de uso geral. Os tipos de máquinas C4 oferecem um desempenho consistentemente elevado para cargas de trabalho de bases de dados.

Desempenho da rede

O Compute Engine tem um limite por VM para a largura de banda da rede de saída. Este limite depende do tipo de máquina da VM e se o tráfego é encaminhado através da mesma rede VPC que a VM de origem. Para VMs com determinados tipos de máquinas, para melhorar o desempenho da rede, pode obter uma largura de banda de saída máxima mais elevada ativando a rede de nível 1. Para mais informações, consulte o artigo Configure o desempenho da rede de nível 1 por VM.

Desempenho do armazenamento do Hyperdisk

As arquiteturas descritas neste documento usam volumes do Hyperdisk para todos os discos de arranque das VMs e para os discos de dados da VM da base de dados. O Hyperdisk permite-lhe dimensionar o desempenho e a capacidade de forma dinâmica. Pode ajustar os IOPS aprovisionados, a taxa de transferência e o tamanho de cada volume para corresponderem ao desempenho de armazenamento e às necessidades de capacidade da sua carga de trabalho. O desempenho dos volumes do Hyperdisk depende do tipo de Hyperdisk e do tipo de máquina das VMs às quais os volumes estão anexados. Para mais informações acerca dos limites de desempenho e da otimização do Hyperdisk, consulte a seguinte documentação:

Mais considerações sobre o desempenho

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

O que se segue?

Colaboradores

Autores:

Outros colaboradores: