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

Last reviewed 2025-08-18 UTC

Este documento fornece uma arquitetura de referência para ajudar você a criar a infraestrutura para executar aplicativos do Oracle E-Business Suite com conectividade de baixa latência aos bancos de dados Exadata do Oracle Cloud Infrastructure (OCI) que são executados emGoogle Cloud. O Oracle E-Business Suite é um pacote de aplicativos empresariais 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 a arquitetura e a pilha de tecnologia do Oracle E-Business Suite e com o Oracle Exadata Database Service.

Se você usa o Oracle Exadata ou o Oracle Real Application Clusters (Oracle RAC) para executar bancos de dados Oracle no local, pode migrar seus aplicativos com eficiência para Google Cloud e executar os bancos de dados no Oracle Database@Google Cloud. O Oracle Database@Google Cloud é uma oferta do Google Cloud Marketplace que permite executar o Oracle Exadata Database Service e o Oracle Autonomous Database diretamente no Google Cloud.

Arquitetura

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 do Google Cloud. O aplicativo usa bancos de dados Oracle Exadata na mesma região Google Cloud.

Todos os componentes da arquitetura estão em uma única região Google Cloud. Essa arquitetura está alinhada com o arquétipo de implantação regional. É possível adaptar essa arquitetura para criar uma topologia robusta contra interrupções regionais usando o arquétipo de implantação multirregional. Para mais informações, consulte Implantação multirregional no Compute Engine e as orientações na seção Confiabilidade mais adiante neste documento.

Os aplicativos do Oracle E-Business Suite são executados no modo ativo-ativo em VMs do Compute Engine.

A arquitetura no diagrama anterior inclui os seguintes componentes:

Componente Finalidade
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 sua pilha de aplicativos contra ameaças como ataques distribuídos de negação de serviço (DDoS) e scripting em vários locais (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 Hyperdisk Balanced.

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.
Backups de aplicativos Os backups do aplicativo são criados, armazenados e gerenciados usando o Serviço de backup e DR.
Rede de nuvem privada virtual (VPC) Todos os recursos Google Cloud na arquitetura usam uma única rede VPC. Dependendo dos seus requisitos, é possível criar uma arquitetura que use várias redes. Para mais informações, consulte Como decidir se você quer criar várias redes VPC.
Oracle Database@Google Cloud

Os aplicativos leem e gravam dados em bancos de dados Oracle no Oracle Exadata Database Service. Você provisiona o Oracle Exadata Database Service usando o Oracle Database@Google Cloud, uma oferta do Cloud Marketplace que permite executar bancos de dados Oracle em hardware gerenciado pela Oracle em um data center Google Cloud .

Você usa interfaces Google Cloud como o console Google Cloud , a Google Cloud CLI e APIs para criar instâncias de infraestrutura do Exadata. A Oracle configura e gerencia a infraestrutura necessária de computação, armazenamento e rede em um data center em uma região Google Cloud em hardware dedicado ao seu projeto.
Instâncias da infraestrutura do Exadata Cada instância da infraestrutura do Exadata contém dois ou mais servidores de banco de dados físicos e três ou mais servidores de armazenamento. Esses servidores, que não aparecem no diagrama, são interconectados usando uma estrutura de rede de baixa latência. Ao criar uma instância da infraestrutura do Exadata, você especifica o número de servidores de banco de dados e de armazenamento que precisam ser provisionados.
Clusters de VM do Exadata

Em uma instância de infraestrutura do Exadata, crie um ou mais clusters de VM do Exadata. Por exemplo, você pode criar e usar um cluster de VM do Exadata separado para hospedar os bancos de dados necessários para cada uma das suas unidades de negócios. Cada cluster de VM do Exadata contém uma ou mais VMs do Oracle Linux que hospedam instâncias do Oracle Database.

Ao criar um cluster de VM do Exadata, você especifica o seguinte:

  • O número de servidores de banco de dados.
  • A capacidade de computação, memória e armazenamento a ser alocada para cada VM no cluster.
  • A rede VPC a que o cluster precisa se conectar.
  • Intervalos de endereços IP das sub-redes de backup e do cliente para o cluster.

As VMs nos clusters de VM do Exadata não são VMs do Compute Engine.
Instâncias do Oracle Database Você cria e gerencia bancos de dados Oracle no console do OCI e em outras interfaces do OCI. O software do Oracle Database é executado nas VMs no cluster de VM do Exadata. Ao criar o cluster de VM do Exadata, você especifica a versão da infraestrutura de grade do Oracle. Você também pode escolher o tipo de licença: trazer suas próprias licenças (BYOL) ou optar pelo modelo com licença incluída.
VCN da OCI e sub-redes Quando você cria um cluster de VM do Exadata, uma rede virtual em nuvem (VCN) da OCI é criada automaticamente. A VCN tem uma sub-rede de cliente e uma sub-rede de backup com intervalos de endereços IP especificados. A sub-rede do cliente é usada para conectividade da sua rede VPC com os bancos de dados Oracle. A sub-rede de backup é usada para enviar backups de banco de dados para o Object Storage da OCI.
Cloud Router, Interconexão por parceiro e DRG da OCI O tráfego entre a rede VPC e a VCN é roteado por um Cloud Router conectado à VPC e por um gateway de roteamento dinâmico (DRG) conectado à VCN. O tráfego flui por uma conexão de baixa latência que o Google configura usando a Interconexão por parceiro.
Zona particular do Cloud DNS Quando você cria um cluster de VM do Exadata, uma zona privada do Cloud DNS é criada automaticamente. Quando seus aplicativos enviam solicitações de leitura e gravação para os bancos de dados Oracle, o Cloud DNS resolve os nomes de host do banco de dados para os endereços IP correspondentes.
OCI Object Storage e OCI Service Gateway Por padrão, os backups dos bancos de dados do Oracle Exadata são armazenados no Object Storage da OCI. Os backups de banco de dados são encaminhados para o Object Storage da OCI por um gateway de serviço.
Gateway Cloud NAT público A arquitetura inclui um gateway público do Cloud NAT para ativar conexões de saída seguras das VMs do Compute Engine, que têm apenas endereços IP internos.
Cloud Interconnect ou 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.
Cloud Monitoring É possível usar o Cloud Monitoring para observar o comportamento, a integridade e o desempenho do aplicativo e dos recursos do Google Cloud , incluindo os recursos do Oracle Exadata. Também é possível monitorar os recursos do Oracle Exadata usando o serviço OCI Monitoring.

Produtos usados

Esta arquitetura de referência usa os seguintes produtos do Google Cloud :

  • 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 Monitoring: um serviço que fornece visibilidade do desempenho, da disponibilidade e da integridade dos aplicativos e da infraestrutura.
  • 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.
  • Interconexão por parceiro: um serviço que fornece conectividade entre sua rede local e as redes de nuvem privada virtual e outras redes por meio de um provedor de serviços compatível.
  • 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.
  • 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 DNS resiliente e de baixa latência na rede mundial do Google.

Esta arquitetura de referência usa 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.
  • Exadata Database Service na infraestrutura dedicada: um serviço que permite executar instâncias do Oracle Database em hardware Exadata dedicado a você.
  • Armazenamento de objetos: um serviço para armazenar grandes quantidades de dados estruturados e não estruturados como objetos.
  • VCNs e sub-redes: uma VCN é uma rede virtual e privada para recursos em uma região da OCI. Uma sub-rede é um intervalo contíguo de endereços IP com uma VCN.
  • Gateway de roteamento dinâmico: um roteador virtual para tráfego entre uma VCN e redes externas.
  • Gateway de serviço: um gateway que permite que os recursos em uma VCN acessem serviços específicos da Oracle de forma privada.

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

Nesta seção, descrevemos fatores de design, práticas recomendadas e recomendações de design que você precisa considerar ao usar essa arquitetura de referência para desenvolver uma topologia que atenda aos seus requisitos específicos de segurança, confiabilidade, eficiência operacional, custo e desempenho. Ao criar a arquitetura para sua carga de trabalho, considere as práticas recomendadas e recomendações do Google Cloud Well-Architected Framework.

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 bancos de dados locais para o Oracle Database@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 informações sobre o procedimento e as ferramentas que podem ser usadas para migrar bancos de dados Oracle para o Google Cloud, consulte o Oracle Migration Methods Advisor.

Antes de usar os bancos de dados migrados em um ambiente de produção, verifique a conectividade dos seus aplicativos com os bancos de dados.

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 Persistent Disk. 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 em 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 do Oracle Database@Google Cloud

Escolha um design de rede que atenda aos seus requisitos comerciais e técnicos. Por exemplo, é possível usar uma única rede VPC ou várias redes VPC. Para mais informações, consulte Saiba como selecionar topologias de rede para o Oracle Database@Google Cloud.

Ao atribuir intervalos de endereços IP para as sub-redes de cliente e de backup a serem usadas nos clusters de VM do Exadata, considere os requisitos mínimos de tamanho da sub-rede. Para mais informações, consulte Planejar o espaço de endereços IP no Oracle Database@Google Cloud.

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 essa arquitetura 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 privado 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.

Para as sub-redes usadas pelas VMs do Exadata, a Oracle recomenda que você atribua intervalos de endereços IP particulares.

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 dados

Por padrão, os dados armazenados no Hyperdisk, Persistent Disk e no Filestore são criptografados usando oGoogle-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 de Hyperdisk e Persistent Disk e Criptografar dados com chaves de criptografia gerenciadas pelo cliente para o Filestore.

Por padrão, os bancos de dados do Exadata usam a criptografia transparente de dados (TDE), que permite criptografar dados sensíveis armazenados em tabelas e tablespaces.

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.

Segurança e compliance do Oracle Exadata

O Oracle Exadata Database Service inclui o Oracle Data Safe, que ajuda você a gerenciar os requisitos de segurança e conformidade dos bancos de dados Oracle. Você pode usar o Oracle Data Safe para avaliar controles de segurança, monitorar a atividade do usuário e mascarar dados sensíveis. Para mais informações, consulte Gerenciar a segurança do banco de dados com o Oracle Data Safe.

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 Framework doGoogle Cloud Well-Architected: segurança, privacidade e conformidade.

Confiabilidade

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

Robustez da camada de aplicativo contra falhas de VM

Se algumas (mas não todas) das VMs que hospedam os aplicativos do Oracle E-Business Suite falharem, os aplicativos vão continuar disponíveis porque o balanceador de carga encaminha solicitações para outras VMs de aplicativos.

À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 contra interrupções de zona

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 de zona única, 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 ficarão indisponíveis. Para reduzir o tempo de inatividade causado por falhas de região, implemente a seguinte abordagem:

  • Mantenha uma réplica passiva (failover) da camada de aplicativo em outra região Google Cloud .
  • Crie uma instância de infraestrutura do Exadata em espera com os clusters de VM do Exadata necessários na mesma região que tem a réplica passiva da pilha de aplicativos. Use o Oracle Data Guard para replicação de dados e failover automático para os bancos de dados Exadata em espera. Se o aplicativo precisar de um objetivo de ponto de recuperação (RPO) menor, faça backup e recupere os bancos de dados usando o Oracle Autonomous Recovery Service.
  • Se ocorrer uma interrupção na região principal, use a réplica ou o backup do banco de dados para restaurar o banco de dados para produção e ativar o aplicativo na região de failover.
  • Use políticas de roteamento de DNS para rotear o tráfego para um balanceador de carga externo na região de failover.

Para aplicativos essenciais para os negócios que precisam continuar disponíveis mesmo quando ocorre uma interrupção de região, considere usar o arquétipo de implantação multirregional. É possível usar o Oracle Active Data Guard para fornecer um banco de dados em espera somente leitura na região de failover.

A Oracle gerencia a infraestrutura no Oracle Database@Google Cloud. Para informações sobre os objetivos de nível de serviço (SLOs) do Oracle Exadata Database Service na infraestrutura dedicada, consulte Objetivos de nível de serviço para serviços de nuvem pública de PaaS e IaaS da Oracle.

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 específico 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.

Capacidade do Oracle Exadata

É possível escalonar a infraestrutura do Exadata adicionando servidores de banco de dados e de armazenamento conforme necessário. Depois de adicionar os servidores de banco de dados ou de armazenamento necessários à infraestrutura do Exadata, para usar os recursos extras de CPU ou armazenamento, adicione a capacidade ao cluster de VM do Exadata associado. Para mais informações, consulte Como escalonar o armazenamento e a computação do Exadata.

Durabilidade dos dados

É possível usar o serviço de Backup e DR para criar, armazenar e gerenciar backups de VMs do Compute Engine. O Backup e DR armazena 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 os dados do armazenamento de backup de longo prazo sem atividades demoradas de movimentação ou preparação de dados. Para mais informações, consulte Backup e DR para backups de instâncias do Compute Engine.

Para garantir a durabilidade dos dados nas instâncias do Filestore, crie backups e snapshots da instância ou use o Backup e DR para Filestore e sistemas de arquivos.

Por padrão, os backups de bancos de dados no Oracle Exadata Database Service on Dedicated Infrastructure são armazenados no OCI Object Storage. Para reduzir o RPO, faça backup e recuperação dos bancos de dados usando o Oracle Autonomous Recovery Service.

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 essa arquitetura 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.

Licenças do banco de dados Oracle Exadata

Ao criar um cluster de VM do Exadata, você pode trazer sua própria licença (BYOL) ou usar uma licença comprada como parte do seu pedido do Google Cloud Marketplace para o Oracle Database@Google Cloud.

As cobranças de rede para transferência de dados entre seus aplicativos e bancos de dados Oracle Exadata na mesma região estão incluídas no preço da oferta do Oracle Database@Google Cloud.

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 essa arquitetura de referência para projetar uma topologia de 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.

Administração do banco de dados Oracle Exadata

A Oracle gerencia os servidores de banco de dados físicos, os servidores de armazenamento e o hardware de rede no Oracle Exadata Database Service na infraestrutura dedicada. É possível gerenciar as instâncias da infraestrutura do Exadata e os clusters de VM do Exadata pelas interfaces do OCI ou do Google Cloud . Você cria e gerencia bancos de dados pelas interfaces da OCI. As páginas do console Google Cloud para o Oracle Database@Google Cloud incluem links que podem ser usados para acessar diretamente as páginas relevantes no console da OCI. Para evitar a necessidade de fazer login novamente no OCI, configure a federação de identidade entre o OCI e o Google Cloud.

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.

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. Para orientações sobre como operar e gerenciar produtos da Oracle, consulte a documentação relevante da Oracle.

Para informações sobre a política de suporte da Oracle para instâncias do Oracle Database implantadas em Google Cloud, consulte Suporte do Oracle Database para ambientes de nuvem pública que não são da Oracle (ID do documento 2688277.1).

Para um resumo das políticas de suporte da Oracle para o Oracle E-Business Suite, consulte Certificações do EBS.

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 essa arquitetura 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 para as cargas de trabalho executadas em VMs. Escolha um tipo de máquina adequado com base nos seus requisitos de desempenho. Para mais informações, consulte o Guia de comparação e recursos para famílias de máquinas.

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 ter uma largura de banda de saída máxima maior ativando a rede Tier_1. Para mais informações, consulte Configurar o desempenho de rede Tier_1 por VM.

O tráfego de rede entre as VMs do aplicativo e a rede do Oracle Exadata é encaminhado por uma conexão de baixa latência da Interconexão por parceiro configurada pelo Google.

A infraestrutura do Exadata usa RDMA sobre Ethernet convergente (RoCE) para rede de alta largura de banda e baixa latência entre os servidores de banco de dados e de armazenamento. Os servidores trocam dados diretamente na memória principal sem envolver o processador, o cache ou o sistema operacional.

Desempenho de armazenamento do hiperdisco

A arquitetura descrita neste documento usa volumes do hiperdisco para todos os discos de inicialização das VMs que hospedam os aplicativos do Oracle E-Business Suite. O Hyperdisk permite escalonar o desempenho e a capacidade dinamicamente. É 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 sua 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 os limites de desempenho e o ajuste 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: