Aplicativo empresarial com o Oracle Database no Compute Engine

Last reviewed 2025-08-13 UTC

Este documento fornece uma arquitetura de referência para ajudar você a criar a infraestrutura para hospedar um aplicativo empresarial altamente disponível que usa um banco de dados Oracle, com toda a pilha implantada em VMs do Compute Engine. É possível usar essa arquitetura de referência para re-hospedar (migração lift-and-shift) de maneira eficiente aplicativos locais que usam bancos de dados Oracle para Google Cloud. Este documento também inclui orientações para ajudar você a criar uma topologia do Oracle Database no Google Cloud que atenda aos requisitos da arquitetura de disponibilidade máxima (MAA) da Oracle. O público-alvo deste documento são arquitetos de nuvem e administradores de banco de dados Oracle. Neste documento, presumimos que você esteja familiarizado com o Compute Engine e o Oracle Database.

Se você usa o Oracle Exadata ou o Oracle Real Application Clusters (Oracle RAC) para executar bancos de dados Oracle no local, é possível migrar seus aplicativos com eficiência para Google Cloud e executar os bancos de dados no Oracle Database@Google Cloud. Para mais informações, consulte Aplicativo empresarial no Compute Engine com o Oracle Exadata.

Arquitetura

O diagrama a seguir mostra a infraestrutura de um aplicativo empresarial de várias camadas que usa o Oracle Database. Os níveis da Web e do aplicativo e as instâncias do Oracle Database são hospedados em VMs do Compute Engine. O nível da Web e o nível de aplicativo são executados no modo ativo-ativo em VMs distribuídas em duas zonas em uma Google Cloud região. As instâncias de banco de dados principal e em espera são implantadas em zonas separadas. Essa arquitetura está alinhada com o arquétipo de implantação regional, o que ajuda a garantir que sua topologia do Google Cloud seja robusta contra interrupções de zona única1.

Um aplicativo empresarial de várias camadas usa o Oracle Database em VMs do Compute Engine.

A arquitetura mostrada no diagrama anterior inclui os seguintes componentes:

Componente Finalidade
Balanceador de carga de aplicativo externo regional O balanceador de carga de aplicativo externo regional recebe e distribui solicitações de usuários para as VMs no nível da Web.
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).
Grupo gerenciado de instâncias (MIG) regional para o nível da Web O nível da Web do aplicativo é implantado nas VMs do Compute Engine que fazem parte de um MIG regional. Esse MIG é o back-end do balanceador de carga de aplicativo externo. O MIG contém VMs do Compute Engine em duas zonas. Cada uma dessas VMs hospeda uma instância independente do nível da Web do aplicativo.
Balanceador de carga de aplicativo interno regional O balanceador de carga de aplicativo interno regional distribui o tráfego das VMs de nível da Web para as VMs de nível de aplicativo.
MIG regional para o nível do aplicativo O nível do aplicativo, como um cluster do Oracle WebLogic Server, é implantado em VMs do Compute Engine que fazem parte de um MIG regional. Esse MIG é o back-end do balanceador de carga de aplicativo interno. O MIG contém VMs do Compute Engine em duas zonas. Cada VM hospeda uma instância independente do servidor de aplicativos.
Instâncias do Oracle Database implantadas em VMs do Compute Engine O aplicativo nesta arquitetura usa um par principal-em espera de instâncias do Oracle Database implantadas em VMs do Compute Engine em zonas separadas. Você traz suas próprias licenças (BYOL) para essas instâncias do Oracle Database e gerencia as VMs e as instâncias de banco de dados.
Pools de armazenamento do Google Cloud Hyperdisk As VMs em cada zona (em todas as camadas na pilha de aplicativos) usam volumes do Hyperdisk Balanced de um pool de armazenamento do Hyperdisk. Ao criar e gerenciar todos os discos em um único pool de armazenamento, você melhora a utilização da capacidade e reduz a complexidade operacional, mantendo a capacidade e o desempenho de armazenamento necessários para as VMs.
Observador do Oracle Data Guard FSFO O observador de failover de início rápido (FSFO, na sigla em inglês) do Oracle Data Guard é um programa leve que inicia o failover automático para a instância do banco de dados Oracle em espera quando a instância principal está indisponível. O observador é executado em uma VM do Compute Engine em uma zona diferente daquelas em que as instâncias de banco de dados primário e em espera são implantadas.
Bucket do Cloud Storage Para armazenar backups das instâncias do Oracle Database, esta arquitetura usa um bucket do Cloud Storage. Para facilitar a recuperação do banco de dados durante uma interrupção regional, armazene os backups com redundância geográfica em um bucket birregional ou multirregional.
Rede de nuvem privada virtual (VPC) e sub-rede Todos os recursos do Google Cloud na arquitetura usam uma única rede VPC e sub-rede. Dependendo dos seus requisitos, é possível criar uma arquitetura que use várias redes VPC ou várias sub-redes. Para mais informações, consulte Como decidir se você quer criar várias redes VPC.
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 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.
Cloud Monitoring e Cloud Logging O Cloud Monitoring ajuda você a observar o comportamento, a integridade e o desempenho do seu aplicativo e dos recursos do Google Cloud . O Agente de operações coleta métricas e registros das VMs do Compute Engine, incluindo as que hospedam as instâncias do Oracle Database. O agente envia registros para o Cloud Logging e métricas para o Cloud Monitoring.

Produtos usados

Esta arquitetura de referência usa 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.
  • Cloud Load Balancing: um portfólio de balanceadores de carga globais, regionais, escalonáveis, globais e de alto desempenho.
  • Cloud Storage: um armazenamento de objetos de baixo custo e sem limite para diversos tipos de dados. Os dados podem ser acessados de dentro e fora Google Cloude são replicados entre locais para redundância.
  • 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.
  • 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.
  • 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 Logging: um sistema de gerenciamento de registros em tempo real com armazenamento, pesquisa, análise e alertas.
  • 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.

Esta arquitetura de referência usa os seguintes produtos da Oracle:

  • 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

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.

As orientações desta seção não são completas. Dependendo dos requisitos específicos do seu aplicativo e dos produtos e recursos do Google Cloud e de terceiros que você usa, pode haver outros fatores de design e compensações que você precisa considerar.

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.

Infraestrutura de computação

A arquitetura de referência neste documento usa VMs do Compute Engine para determinados níveis do aplicativo. Dependendo dos requisitos do aplicativo, é possível escolher outros serviços de computação do Google Cloud :

  • Contêineres: é possível executar aplicativos conteinerizados nos clusters do Google Kubernetes Engine (GKE). O GKE é um mecanismo de orquestração de contêineres que automatiza a implantação, o escalonamento e o gerenciamento de aplicativos em contêineres.
  • Sem servidor: se você preferir concentrar as iniciativas de TI nos dados e aplicativos em vez de configurar e operar recursos de infraestrutura, use serviços sem servidor, como o Cloud Run.

A decisão de usar VMs, contêineres ou serviços sem servidor envolve uma troca entre flexibilidade de configuração e esforço de gerenciamento. As VMs e os contêineres oferecem mais flexibilidade de configuração, mas você é responsável por gerenciar os recursos. Em uma arquitetura sem servidor, as cargas de trabalho são implantadas em uma plataforma pré-configurada que requer esforço mínimo de gerenciamento. Para mais informações sobre como escolher serviços de computação adequados para suas cargas de trabalho no Google Cloud, consulte Hospedagem de aplicativos no Google Cloud.

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:

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 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 são criptografados usando Google-owned and Google-managed encryption keys. Como uma camada extra de proteção, você pode criptografar as chaves de criptografia de dados do Google usando chaves que você tem e gerencia no Cloud Key Management Service (Cloud KMS). Para mais informações, consulte Sobre a criptografia de disco.

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 essa arquitetura de referência para criar e operar uma infraestrutura confiável para sua implantação noGoogle Cloud.

Robustez contra falhas de VM

Na arquitetura mostrada neste documento, se uma VM do Compute Engine em qualquer um dos níveis falhar, o aplicativo poderá continuar processando solicitações.

  • Se uma VM no nível da Web ou de aplicativo falhar, o MIG relevante vai recriar a VM automaticamente. Os balanceadores de carga encaminham solicitações apenas para as instâncias de servidor da Web e de servidor de aplicativos disponíveis.
  • Se a VM que hospeda a instância principal do Oracle Database falhar, o observador do Oracle Data Guard FSFO vai iniciar um failover automático para a instância em espera do Oracle Database.

Recuperação automática de VM

Às vezes, as VMs que hospedam o aplicativo podem estar em execução e disponíveis, mas pode haver problemas com o próprio aplicativo. O aplicativo pode congelar, falhar ou não ter memória suficiente. Para verificar se um aplicativo está respondendo conforme o esperado, configure verificações de integridade baseadas em aplicativo como parte da política de recuperação automática dos seus MIGs. Se o aplicativo em uma VM específica não estiver respondendo, o MIG vai recuperar (reparar) automaticamente a VM. Para mais informações sobre como configurar a recuperação automática, consulte Como reparar VMs para alta disponibilidade.

Robustez contra interrupções de zona

Se ocorrer uma interrupção na zona, o aplicativo vai continuar disponível.

  • As camadas da Web e de aplicativos estão disponíveis (e responsivas) porque as VMs estão em MIGs regionais. Os MIGs regionais garantem que novas VMs sejam criadas automaticamente na outra zona para manter o número mínimo configurado de VMs. Os balanceadores de carga encaminham solicitações para as VMs de servidor da Web e de servidor de aplicativos disponíveis.
  • Se uma interrupção afetar a zona que tem a instância principal do Oracle Database, o observador de FSFO do Oracle Data Guard vai iniciar um failover automático para a instância em espera do Oracle Database. O observador de FSFO é executado em uma VM em uma zona diferente das zonas que têm as instâncias de banco de dados primário e de espera.
  • 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, eles são replicados de maneira síncrona entre duas zonas na mesma região.

Robustez contra interrupções regionais

Se as duas zonas na arquitetura tiverem uma interrupção ou se ocorrer uma interrupção da região, o aplicativo ficará indisponível. Para reduzir o tempo de inatividade causado por interrupções em várias zonas ou regiões, implemente a seguinte abordagem:

Para aplicativos essenciais para os negócios que precisam continuar disponíveis mesmo quando ocorre uma interrupção em uma região, considere usar o arquétipo de implantação multirregional. Para a camada de banco de dados, use o Oracle Active Data Guard FSFO para fazer failover automático para uma instância de espera do Oracle Database na região de failover. Essa abordagem é mapeada para o nível Gold do MAA da Oracle.

Escalonamento automático de MIG

Para controlar o comportamento de escalonamento automático de seus MIGs sem estado, é possível especificar métricas de utilização de destino, como a utilização média da CPU. Também é possível configurar o escalonamento automático baseado em programação para MIGs sem estado. MIGs com estado não podem ser escalonados automaticamente. Para mais informações, consulte Escalonamento automático de grupos de instâncias.

Limite de tamanho do MIG

Ao decidir o tamanho dos MIGs, considere os limites padrão e máximo do número de VMs que podem ser criadas em um MIG. Para mais informações, consulte Adicionar e remover VMs de um MIG.

Posicionamento da VM

Para melhorar a robustez da arquitetura, crie uma política de posicionamento distribuído e aplique-a ao modelo do MIG. Quando o MIG cria VMs, ele as coloca dentro de cada zona em diferentes servidores físicos (chamados de hosts), de modo que suas VMs sejam resistentes contra falhas de hosts individuais. Para mais informações, consulte Criar e aplicar políticas de posicionamento distribuído às VMs.

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.

Disponibilidade do armazenamento em blocos

A arquitetura neste documento usa um pool de armazenamento de hiperdisco em cada zona para fornecer armazenamento em blocos para as VMs do Compute Engine. Você cria um pool de capacidade de armazenamento em blocos para uma zona. Em seguida, crie volumes do Hyperdisk no pool de armazenamento e anexe-os às VMs na zona. O pool de armazenamento tenta adicionar capacidade automaticamente para garantir que a taxa de utilização não exceda 80% da capacidade provisionada do pool. Essa abordagem garante que o espaço de armazenamento em blocos esteja disponível quando necessário. Para mais informações, consulte Como funcionam os pools de armazenamento do Hyperdisk.

Armazenamento com estado

Uma prática recomendada ao projetar aplicativos é evitar a necessidade de discos locais com estado. No entanto, se o requisito existir, é possível configurar os discos permanentes com estado para garantir que os dados sejam preservados quando as VMs forem reparadas ou recriadas. No entanto, recomendamos que você mantenha os discos de inicialização sem estado para atualizá-los para as imagens mais recentes com novas versões e patches de segurança. Para mais informações, consulte Como configurar discos permanentes com estado em MIGs.

Backup e recuperação

A arquitetura neste documento usa o Cloud Storage para armazenar backups de banco de dados. Se você escolher o tipo de local birregional ou multirregional para o bucket do Cloud Storage, os backups serão replicados de forma assíncrona em pelo menos dois locais geográficos. Se ocorrer uma falha temporária na região, use os backups para restaurar o banco de dados em outra região. Com um bucket birregional, é possível conseguir uma replicação mais rápida ativando a opção de replicação turbo. Para mais informações, consulte Disponibilidade e 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 serviço de 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 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 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.

Modelo de provisionamento de VM

Se o aplicativo for tolerante a falhas, as VMs spot podem ajudar a reduzir os custos do Compute Engine para as VMs nos níveis do aplicativo e da Web. O custo das VMs spot é significativamente menor do que as VMs regulares. No entanto, o Compute Engine pode interromper ou excluir antecipadamente as VMs spot para recuperar a capacidade.

As VMs spot são adequadas para jobs em lote que toleram preempção e não têm requisitos de alta disponibilidade. As VMs spot oferecem os mesmos tipos de máquina, opções e desempenho que as VMs regulares. No entanto, quando a capacidade de recursos em uma zona é limitada, os MIGs podem não conseguir fazer o escalonamento horizontal (ou seja, criar VMs) automaticamente para o tamanho de destino especificado até que a capacidade necessária fique disponível novamente.

Utilização de recursos da VM

O recurso de escalonamento automático dos MIGs sem estado permite que seu aplicativo processe aumentos no tráfego de maneira eficiente, além de ajudar a reduzir o custo quando a necessidade de recursos for baixa. MIGs com estado não podem ser escalonados automaticamente.

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.

Utilização de recursos de armazenamento em blocos

A arquitetura neste documento usa um pool de armazenamento de hiperdisco em cada zona para fornecer armazenamento em blocos para as VMs do Compute Engine. Você pode melhorar a utilização geral da capacidade de armazenamento em blocos e reduzir o custo usando pools de armazenamento de capacidade avançada, que usam provisionamento superficial e tecnologias de redução de dados para melhorar a eficiência do armazenamento.

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.

Atualizações de configuração da VM

Para atualizar a configuração das VMs em um MIG (como o tipo de máquina ou a imagem do disco de inicialização), crie um novo modelo de instância com a configuração necessária e, em seguida, aplique o novo modelo ao MIG. O MIG atualiza as VMs usando o método de atualização que você escolher: automático ou seletivo. Escolha um método apropriado com base nos seus requisitos de disponibilidade e eficiência operacional. Para mais informações sobre esses métodos de atualização de MIG, consulte Aplicar novas configurações de VM em um MIG.

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.

Modelos deterministas de instância

Se os modelos de instância que você usa para seus MIGs incluírem scripts de inicialização para instalar software de terceiros, verifique se os scripts especificam explicitamente os parâmetros de instalação de software, como a versão do software. Caso contrário, quando o MIG criar as VMs, o software instalado nelas poderá não ser consistente. Por exemplo, se o modelo de instância incluir um script de inicialização para instalar o Servidor HTTP Apache 2.0 (o pacote apache2), verifique se o script especifica a versão exata do apache2 que precisa ser instalada como a versão 2.4.53. Para mais informações, consulte Modelos deterministas de instâncias.

Gerenciamento de armazenamento em blocos

A arquitetura neste documento usa um pool de armazenamento de hiperdisco em cada zona para fornecer armazenamento em blocos para as VMs do Compute Engine. Os pools de armazenamento de hiperdisco ajudam a simplificar o gerenciamento do armazenamento. Em vez de alocar e gerenciar a capacidade individualmente para vários discos, defina um pool de capacidade que pode ser compartilhado entre várias cargas de trabalho em uma zona. Em seguida, crie volumes do Hyperdisk no pool de armazenamento e anexe-os às VMs na zona. O pool de armazenamento tenta adicionar capacidade automaticamente para garantir que a taxa de utilização não exceda 80% da capacidade provisionada do pool.

Conectividade do servidor de aplicativos com o banco de dados

Para conexões do seu aplicativo 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.

Administração e suporte do Oracle Database

Ao executar uma instância autogerenciada do Oracle Database em uma VM do Compute Engine, há preocupações operacionais semelhantes às de quando você executa o Oracle Database no local. No entanto, com uma VM do Compute Engine, não é mais 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 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 que podem ser escolhidos de acordo com os requisitos de desempenho das suas cargas de trabalho.

  • Para as VMs que hospedam as camadas da Web e de aplicativo, escolha um tipo de máquina adequado com base nos requisitos de desempenho dessas camadas. 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 as VMs que hospedam 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.

Várias linhas de execução de VM

Cada CPU virtual (vCPU) alocada para uma VM do Compute Engine é implementada como um multithread de hardware único. Por padrão, duas vCPUs compartilham um núcleo físico da CPU. Para aplicativos que envolvem operações altamente paralelas ou que realizam cálculos de ponto flutuante, como análise de sequência genética e modelagem de risco financeiro, é possível melhorar o desempenho reduzindo o número de linhas de execução executadas em cada núcleo de CPU física. Para ver mais informações, consulte Definir número de linhas de execução por núcleo.

O multithreading de VMs pode ter implicações de licenciamento para alguns softwares de terceiros, como bancos de dados. Para saber mais, leia a documentação de licenciamento do software de terceiros.

Desempenho da rede

Para cargas de trabalho que precisam de baixa latência de rede entre VMs nas camadas de aplicativo e da Web, crie uma política de posicionamento compacto e aplique-a ao modelo do MIG usado para essas camadas. Quando o MIG cria VMs, ele as coloca em servidores físicos próximos uns dos outros. Embora uma política de posicionamento compacto ajude a melhorar o desempenho da rede entre VMs, uma política de posicionamento distribuído pode ajudar a melhorar a disponibilidade da VM, conforme descrito anteriormente. Para alcançar um equilíbrio ideal entre o desempenho e a disponibilidade da rede, ao criar uma política de posicionamento compacto, é possível especificar a distância entre as VMs. Para mais informações, consulte Visão geral das políticas de posicionamento.

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.

Desempenho de armazenamento do hiperdisco

A arquitetura descrita neste documento usa volumes de Hyperdisk para as VMs em todos os níveis. O Hyperdisk permite escalonar o desempenho e a capacidade dinamicamente. É possível ajustar as IOPS provisionadas, a capacidade 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 de desempenho e 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:

  1. Para mais informações sobre considerações específicas de cada região, consulte Geografia e regiões.  ↩