Aplicação empresarial com a base de dados Oracle no Compute Engine

Last reviewed 2025-08-13 UTC

Este documento fornece uma arquitetura de referência para ajudar a criar a infraestrutura para alojar uma aplicação empresarial de elevada disponibilidade que usa uma base de dados Oracle, com a pilha completa implementada em VMs do Compute Engine. Pode usar esta arquitetura de referência para realoçar (migrar) de forma eficiente as aplicações no local que usam bases de dados Oracle para Google Cloud. Este documento também inclui orientações para ajudar a criar uma topologia de base de dados Oracle no Google Cloud que cumpra os requisitos da arquitetura de disponibilidade máxima (MAA) da Oracle.Google Cloud O público-alvo deste documento são arquitetos da nuvem e administradores da base de dados Oracle. Este documento pressupõe que está familiarizado com o Compute Engine e a base de dados Oracle.

Se usar o Oracle Exadata ou o Oracle Real Application Clusters (Oracle RAC) para executar bases de dados Oracle no local, pode migrar as suas aplicações de forma eficiente para Google Cloud e executar as suas bases de dados no Oracle Database@Google Cloud. Para mais informações, consulte o artigo Aplicação empresarial no Compute Engine com o Oracle Exadata.

Arquitetura

O diagrama seguinte mostra a infraestrutura de uma aplicação empresarial de vários níveis que usa a base de dados Oracle. O nível Web, o nível da aplicação e as instâncias da base de dados Oracle estão alojados em VMs do Compute Engine. A camada Web e a camada de aplicação são executadas no modo ativo-ativo em VMs distribuídas por duas zonas numa Google Cloud região. As instâncias de base de dados principal e de reserva são implementadas em zonas separadas. Esta arquitetura está alinhada com o arquétipo de implementação regional, que ajuda a garantir que a sua Google Cloud topologia é robusta contra interrupções de zona única1.

Uma aplicação empresarial de vários níveis usa o Oracle Database em VMs do Compute Engine.

A arquitetura apresentada no diagrama anterior inclui os seguintes componentes:

Componente Finalidade
Balanceador de carga de aplicações externo regional O Application Load Balancer externo regional recebe e distribui pedidos de utilizadores para as VMs da camada Web.
Política de segurança do Google Cloud Armor A política de segurança do Cloud Armor ajuda a proteger a sua pilha de aplicações contra ameaças como ataques de negação de serviço distribuída (DDoS) e scripting entre sites (XSS).
Grupo de instâncias geridas (GIG) regional para a camada Web A camada Web da aplicação é implementada em VMs do Compute Engine que fazem parte de um GIG regional. Este MIG é o back-end do Application Load Balancer externo. O MIG contém VMs do Compute Engine em duas zonas. Cada uma destas VMs aloja uma instância independente da camada Web da aplicação.
Balanceador de carga de aplicações interno regional O balanceador de carga de aplicações interno regional distribui o tráfego das VMs da camada Web para as VMs da camada de aplicações.
MIG regional para o nível da aplicação A camada de aplicação, como um cluster do Oracle WebLogic Server, é implementada em VMs do Compute Engine que fazem parte de um GIG regional. Este MIG é o back-end do balanceador de carga da aplicação interno. O MIG contém VMs do Compute Engine em duas zonas. Cada MV aloja uma instância independente do servidor de aplicações.
Instâncias da base de dados Oracle implementadas em VMs do Compute Engine A aplicação nesta arquitetura usa um par principal/em espera de instâncias da base de dados Oracle implementadas em VMs do Compute Engine em zonas separadas. Traz as suas próprias licenças (BYOL) para estas instâncias da base de dados Oracle e gere as VMs e as instâncias da base de dados.
Pools de armazenamento do Google Cloud Hyperdisk As VMs em cada zona (em todos os níveis na pilha de aplicações) usam volumes Hyperdisk Balanced de um conjunto de armazenamento Hyperdisk. A criação e a gestão de todos os discos num único conjunto de armazenamento permitem melhorar a utilização da capacidade e reduzir a complexidade operacional, ao mesmo tempo que mantém a capacidade de armazenamento e o desempenho de que as VMs precisam.
Oracle Data Guard FSFO observer O observador de comutação por falha de início rápido (FSFO) do Oracle Data Guard é um programa simples que inicia a comutação por falha automática para a instância da base de dados Oracle em espera quando a instância principal está indisponível. O observador é executado numa VM do Compute Engine numa zona diferente das zonas onde as instâncias da base de dados principal e de reserva estão implementadas.
Contentor do Cloud Storage Para armazenar cópias de segurança das instâncias da base de dados do Oracle, esta arquitetura usa um contentor do Cloud Storage. Para facilitar a recuperação da base de dados durante uma indisponibilidade da região, pode armazenar as cópias de segurança de forma georredundante num contentor de duas regiões ou de várias regiões.
Rede de nuvem virtual privada (VPC) e sub-rede Todos os Google Cloud recursos na arquitetura usam uma única rede VPC e sub-rede. Consoante os seus requisitos, pode optar por criar uma arquitetura que use várias redes VPC ou várias sub-redes. Para mais informações, consulte o artigo Decidir se deve criar várias redes VPC.
Gateway do Cloud NAT público A arquitetura inclui um gateway Cloud NAT público para ativar ligações de saída seguras a partir das VMs do Compute Engine que têm apenas endereços IP internos.
Cloud Interconnect e Cloud VPN Para ligar a sua rede no local à rede VPC em Google Cloud, pode usar o Cloud Interconnect ou o Cloud VPN. Para informações sobre as vantagens relativas de cada abordagem, consulte o artigo Escolher um produto de conetividade de rede.
Cloud Monitoring e Cloud Logging O Cloud Monitoring ajuda a observar o comportamento, o estado e o desempenho da sua aplicação e Google Cloud recursos. O agente Ops recolhe métricas e registos das VMs do Compute Engine, incluindo as VMs que alojam as instâncias da base de dados Oracle. O agente envia registos para o Cloud Logging e envia métricas para o Cloud Monitoring.

Produtos usados

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

  • 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.
  • Cloud Load Balancing: um portefólio de balanceadores de carga globais, escaláveis e de elevado desempenho, bem como balanceadores de carga regionais.
  • Cloud Storage: um serviço de armazenamento de objetos de baixo custo e sem limite para diversos tipos de dados. Os dados podem ser acedidos a partir do interior e do exterior Google Cloud, e são replicados em várias localizações para redundância.
  • 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.
  • 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.
  • Cloud NAT: um serviço que oferece tradução de endereços de rede de alto desempenho gerida pela Google Cloud.
  • Cloud Monitoring: um serviço que oferece visibilidade do desempenho, da disponibilidade e do estado das suas aplicações e infraestrutura.
  • Cloud Logging: um sistema de gestão de registos em tempo real com armazenamento, pesquisa, análise e alertas.
  • 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.

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

  • 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 esta arquitetura de referência para desenvolver uma topologia que cumpra os seus requisitos específicos de segurança, fiabilidade, eficiência operacional, custo e desempenho.

As orientações nesta secção não são exaustivas. Consoante os requisitos específicos da sua aplicação e os produtos e funcionalidades de terceiros que usa, podem existir fatores de design e compromissos adicionais que deve considerar. 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.

Infraestrutura de computação

A arquitetura de referência neste documento usa VMs do Compute Engine para determinados níveis da aplicação. Consoante os requisitos da sua aplicação, pode escolher entre outros Google Cloud serviços de computação:

  • Contentores: pode executar aplicações em contentores em clusters do Google Kubernetes Engine (GKE). O GKE é um motor de orquestração de contentores que automatiza a implementação, o dimensionamento e a gestão de aplicações contentorizadas.
  • Sem servidor: se preferir concentrar os seus esforços de TI nos dados e nas aplicações em vez de configurar e operar recursos de infraestrutura, pode usar serviços sem servidor, como o Cloud Run.

A decisão de usar VMs, contentores ou serviços sem servidor envolve uma troca entre a flexibilidade da configuração e o esforço de gestão. As VMs e os contentores oferecem mais flexibilidade de configuração, mas é responsável pela gestão dos recursos. Numa arquitetura sem servidor, implementa cargas de trabalho numa plataforma pré-configurada que requer um esforço de gestão mínimo. Para mais informações sobre a escolha de serviços de computação adequados para as suas cargas de trabalho no Google Cloud, consulte Alojamento de aplicações no Google Cloud.

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:

Segurança, privacidade e conformidade

Esta secção descreve os fatores a ter em conta quando usa esta arquitetura de referência para criar 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 são encriptados com Google-owned and Google-managed encryption keys. Como camada de proteção adicional, pode optar por encriptar as chaves de encriptação de dados pertencentes à Google através de chaves que lhe pertencem e que gere no Cloud Key Management Service (Cloud KMS). Para mais informações, consulte Acerca da encriptação de disco.

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 ter em conta quando usa esta arquitetura de referência para criar e operar uma infraestrutura fiável para a sua implementação noGoogle CloudGoogle Cloud.

Robustez contra falhas de VMs

Na arquitetura apresentada neste documento, se uma VM do Compute Engine em qualquer um dos níveis falhar, a aplicação pode continuar a processar pedidos.

  • Se uma VM na camada Web ou na camada de aplicação falhar, o MIG recria automaticamente a VM relevante. Os balanceadores de carga encaminham os pedidos apenas para as instâncias de servidor Web e de servidor de aplicações disponíveis.
  • Se a VM que aloja a instância principal da base de dados Oracle falhar, o observador FSFO do Oracle Data Guard inicia uma comutação por falha automática para a instância da base de dados Oracle em espera.

Autorreparação de VMs

Por vezes, as VMs que alojam a sua aplicação podem estar em execução e disponíveis, mas podem existir problemas com a própria aplicação. A aplicação pode ficar bloqueada, falhar ou não ter memória suficiente. Para verificar se uma aplicação está a responder conforme esperado, pode configurar verificações de funcionamento baseadas em aplicações como parte da política de autocorreção dos seus MIGs. Se a aplicação numa determinada VM não estiver a responder, o GIG faz a autorrecuperação (repara) da VM. Para mais informações sobre a configuração da autocorreção, consulte Acerca da reparação de VMs para alta disponibilidade.

Robustez contra falhas de zonas

Se ocorrer uma indisponibilidade de zona, a aplicação permanece disponível.

  • A camada Web e a camada de aplicação estão disponíveis (e são responsivas) porque as VMs estão em GIGs regionais. Os MIGs regionais garantem que as novas VMs são criadas automaticamente na outra zona para manter o número mínimo de VMs configurado. Os balanceadores de carga encaminham pedidos para as VMs do servidor Web e as VMs do servidor de aplicações disponíveis.
  • Se uma indisponibilidade afetar a zona que tem a instância principal da base de dados Oracle, o observador do FSFO do Oracle Data Guard inicia uma comutação por falha automática para a instância da base de dados Oracle em espera. O observador FSFO é executado numa VM numa zona diferente das zonas que têm as instâncias da base de dados principal e em espera.
  • 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 escritos num volume, são replicados de forma síncrona entre duas zonas na mesma região.

Robustez contra interrupções de regiões

Se ambas as zonas na arquitetura tiverem uma indisponibilidade ou ocorrer uma indisponibilidade na região, a aplicação fica indisponível. Para reduzir o tempo de inatividade causado por falhas de energia em várias zonas ou regiões, pode implementar a seguinte abordagem:

  • Manter uma réplica passiva (com comutação por falha) da pilha de infraestrutura noutra Google Cloud região.

  • Use um contentor do Cloud Storage de duas regiões ou multirregional para armazenar as cópias de segurança da base de dados Oracle. As cópias de segurança são replicadas de forma assíncrona em, pelo menos, duas localizações geográficas. Com as cópias de segurança da base de dados replicadas, a sua arquitetura é mapeada para o nível Silver da arquitetura de disponibilidade máxima (MAA) da Oracle.

    Para conseguir uma replicação mais rápida das cópias de segurança armazenadas em contentores de dupla região, pode usar a replicação turbo. Para mais informações, consulte o artigo Disponibilidade e durabilidade dos dados.

  • Se ocorrer uma indisponibilidade na região principal, use a cópia de segurança da base de dados para restaurar a base de dados e ativar a aplicação na região de alternativa. Use as políticas de encaminhamento de DNS para encaminhar o tráfego para o balanceador de carga na região de alternativa.

Para aplicações essenciais para o negócio que têm de continuar a estar disponíveis mesmo quando ocorre uma interrupção regional, considere usar o arquétipo de implementação multirregional. Para o nível da base de dados, pode usar o Oracle Active Data Guard FSFO para fazer automaticamente o failover para uma instância da base de dados Oracle em espera na região de failover. Esta abordagem é mapeada para o nível Ouro do MAA da Oracle.

Escala automática do MIG

Para controlar o comportamento de escalamento automático dos MIGs sem estado, pode especificar métricas de utilização alvo, como a utilização média da CPU. Também pode configurar o ajuste de escala automático baseado em programação para MIGs sem estado. Não é possível ajustar automaticamente a escala dos MIGs com estado. Para mais informações, consulte o artigo Grupos de escalamento automático de instâncias.

Limite de tamanho do MIG

Quando decidir o tamanho dos seus MIGs, considere os limites predefinidos e máximos no número de VMs que podem ser criadas num MIG. Para mais informações, consulte o artigo Adicione e remova VMs de um MIG.

Posicionamento de VMs

Para melhorar a robustez da arquitetura, pode criar uma política de posicionamento disperso e aplicá-la ao modelo MIG. Quando o MIG cria VMs, coloca-as em diferentes servidores físicos (denominados anfitriões) em cada zona, para que as VMs sejam robustas contra falhas de anfitriões individuais. Para mais informações, consulte o artigo Crie e aplique políticas de posicionamento disperso a VMs.

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.

Disponibilidade do armazenamento em bloco

A arquitetura neste documento usa um conjunto de armazenamento Hyperdisk em cada zona para fornecer armazenamento de blocos para as VMs do Compute Engine. Cria um conjunto de capacidade de armazenamento em bloco para uma zona. Em seguida, crie volumes do Hyperdisk no conjunto de armazenamento e anexe os volumes às VMs na zona. O conjunto de armazenamento tenta adicionar capacidade automaticamente para garantir que a taxa de utilização não excede 80% da capacidade aprovisionada do conjunto. Esta abordagem garante que o espaço de armazenamento de blocos está disponível quando necessário. Para mais informações, consulte o artigo Como funcionam os conjuntos de armazenamento do Hyperdisk.

Armazenamento com estado

Uma prática recomendada no design de aplicações é evitar a necessidade de discos locais com estado. No entanto, se o requisito existir, pode configurar os discos persistentes para serem com estado, de modo a garantir que os dados são preservados quando as VMs são reparadas ou recriadas. No entanto, recomendamos que mantenha os discos de arranque sem estado para que os possa atualizar para as imagens mais recentes com novas versões e patches de segurança. Para mais informações, consulte o artigo Configurar discos persistentes com estado em MIGs.

Cópia de segurança e recuperação

A arquitetura neste documento usa o Cloud Storage para armazenar cópias de segurança da base de dados. Se escolher o tipo de localização de região dupla ou multirregião para o contentor do Cloud Storage, as cópias de segurança são replicadas de forma assíncrona em, pelo menos, duas localizações geográficas. Se ocorrer uma indisponibilidade regional, pode usar as cópias de segurança para restaurar a base de dados noutra região. Com um contentor de duas regiões, pode alcançar uma replicação mais rápida ativando a opção de replicação turbo. Para mais informações, consulte o artigo Disponibilidade e durabilidade dos dados.

Pode usar o serviço de cópia de segurança e recuperação de desastres para criar, armazenar e gerir cópias de segurança de VMs do Compute Engine. O serviço de cópia de segurança e RD armazena dados de cópia de segurança no seu 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 sem atividades de preparação ou movimentação de dados demoradas. 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 que cria através desta arquitetura 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.

Modelo de aprovisionamento de VMs

Se a sua aplicação for tolerante a falhas, as VMs do Spot podem ajudar a reduzir os custos do Compute Engine para as VMs nas camadas de aplicação e Web. O custo das VMs do Spot é significativamente inferior ao das VMs normais. No entanto, o Compute Engine pode parar ou eliminar preventivamente VMs do Spot para reaver capacidade.

As VMs do Spot são adequadas para tarefas de lotes que podem tolerar a preempção e não têm requisitos de alta disponibilidade. As VMs do Spot oferecem os mesmos tipos de máquinas, opções e desempenho que as VMs normais. No entanto, quando a capacidade de recursos numa zona é limitada, os GIGs podem não conseguir ser expandidos (ou seja, criar VMs) automaticamente para o tamanho alvo especificado até que a capacidade necessária fique novamente disponível.

Utilização de recursos da VM

A capacidade de escala automática dos GIGs sem estado permite que a sua aplicação lide facilmente com aumentos no tráfego e ajuda a reduzir os custos quando a necessidade de recursos é baixa. Não é possível ajustar automaticamente a escala dos MIGs com estado.

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.

Utilização de recursos de armazenamento em bloco

A arquitetura neste documento usa um conjunto de armazenamento Hyperdisk em cada zona para fornecer armazenamento de blocos para as VMs do Compute Engine. Pode melhorar a utilização geral da capacidade de armazenamento de blocos e reduzir os custos através dos pools de armazenamento de capacidade avançada, que usam o aprovisionamento reduzido e as tecnologias de redução de dados para melhorar a eficiência do armazenamento.

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 esta arquitetura de referência para criar uma Google Cloud topologia que pode operar de forma eficiente.

Atualizações da configuração de VMs

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

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.

Modelos de instância determinísticos

Se os modelos de instância que usa para os seus MIGs incluírem scripts de arranque para instalar software de terceiros, certifique-se de que os scripts especificam explicitamente parâmetros de instalação de software, como a versão do software. Caso contrário, quando o MIG cria as VMs, o software instalado nas VMs pode não ser consistente. Por exemplo, se o modelo de instância incluir um script de arranque para instalar o Apache HTTP Server 2.0 (o pacote apache2), certifique-se de que o script especifica a versão exata do apache2 que deve ser instalada, como a versão 2.4.53. Para mais informações, consulte o artigo Modelos de instâncias determinísticos.

Gestão de armazenamento em bloco

A arquitetura neste documento usa um conjunto de armazenamento Hyperdisk em cada zona para fornecer armazenamento de blocos para as VMs do Compute Engine. Os conjuntos de armazenamento Hyperdisk ajudam a simplificar a gestão do armazenamento. Em vez de atribuir e gerir a capacidade individualmente para vários discos, define um conjunto de capacidade que pode ser partilhado por várias cargas de trabalho numa zona. Em seguida, cria volumes do Hyperdisk no conjunto de armazenamento e anexa os volumes às VMs na zona. O conjunto de armazenamento tenta adicionar capacidade automaticamente para garantir que a taxa de utilização não excede 80% da capacidade aprovisionada do conjunto.

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

Para ligações da sua aplicação à 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.

Administração e apoio técnico da base de dados Oracle

Quando executa uma instância da base de dados Oracle autogerida numa VM do Compute Engine, existem preocupações operacionais semelhantes às que existem quando executa a base de dados Oracle no local. No entanto, com uma VM do Compute Engine, já 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 esta arquitetura de referência para criar uma topologia no Google Cloud que cumpre os requisitos de desempenho das suas cargas de trabalho.

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 a camada Web e a camada de aplicação, escolha um tipo de máquina adequado com base nos seus requisitos de desempenho para essas camadas. 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 de comparação de séries de máquinas.
  • Para as VMs que alojam 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.

Vários threads da VM

Cada CPU virtual (vCPU) que atribui a uma VM do Compute Engine é implementada como um único multithread de hardware. Por predefinição, duas vCPUs partilham um núcleo da CPU físico. Para aplicações que envolvem operações altamente paralelas ou que realizam cálculos de vírgula flutuante (como a análise de sequências genéticas e a modelagem de risco financeiro), pode melhorar o desempenho reduzindo o número de threads que são executados em cada núcleo da CPU física. Para mais informações, consulte o artigo Defina o número de threads por núcleo.

A multithreading de VMs pode ter implicações de licenciamento para algum software de terceiros, como bases de dados. Para mais informações, 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 da aplicação e Web, pode criar uma política de posicionamento compacta e aplicá-la ao modelo de MIG usado para essas camadas. Quando o MIG cria VMs, coloca-as em servidores físicos próximos uns dos outros. Embora uma política de posicionamento compacta ajude a melhorar o desempenho da rede entre VMs, uma política de posicionamento dispersa pode ajudar a melhorar a disponibilidade das VMs, conforme descrito anteriormente. Para alcançar um equilíbrio ideal entre o desempenho da rede e a disponibilidade, quando cria uma política de posicionamento compacta, pode especificar a distância entre as VMs. Para mais informações, consulte a vista geral das políticas de posicionamento.

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.

Desempenho do armazenamento do Hyperdisk

A arquitetura descrita neste documento usa volumes do Hyperdisk para as VMs em todos os níveis. O Hyperdisk permite-lhe dimensionar o desempenho e a capacidade dinamicamente. Pode ajustar os IOPS provisionados, 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 sobre os limites de desempenho e a 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:

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