Aplicativo empresarial em VMs do Compute Engine com o Oracle Exadata em Google Cloud

Last reviewed 2024-09-30 UTC

Este documento apresenta uma arquitetura de referência para um aplicativo empresarial altamente disponível hospedado em máquinas virtuais (VMs) do Compute Engine com conectividade de baixa latência aos bancos de dados Exadata da Oracle Cloud Infrastructure (OCI) executados em Google Cloud. O público-alvo deste documento são arquitetos de nuvem e administradores de banco de dados do Oracle. O documento pressupõe que você já conhece o Compute Engine e o serviço de banco de dados Oracle Exadata.

Se você usa o Oracle Exadata ou o Oracle Real Application Clusters (Oracle RAC) para executar bancos de dados Oracle localmente, é possível migrar seus aplicativos de forma eficiente para Google Cloud e executar seus 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.

Se você não precisar do recurso Oracle RAC ou precisar de uma versão do Oracle Database diferente do 19c e do 23ai, será possível executar bancos de dados autogerenciados do Oracle em VMs do Compute Engine. Para mais informações, consulte Aplicativo empresarial com o Oracle Database no Compute Engine.

Arquitetura

O diagrama a seguir mostra uma visão geral da arquitetura:

Visão geral de alto nível de uma arquitetura que usa o Oracle Database@Google Cloud.

No diagrama anterior, um balanceador de carga externo recebe solicitações de usuários de um aplicativo voltado ao público e as distribui para servidores da Web do front-end. Os servidores da Web encaminham as solicitações do usuário por um balanceador de carga interno para os servidores de aplicativos. Os servidores de aplicativos leem e gravam dados em bancos de dados no Oracle Database@Google Cloud. Os administradores e os serviços do OCI podem se conectar e interagir com os bancos de dados Oracle.

O diagrama a seguir mostra uma visão detalhada da arquitetura:

Uma visão detalhada de uma arquitetura que usa o Oracle Database@Google Cloud.

Nesta arquitetura, o nível da Web e do aplicativo são executados no modo ativo-ativo em VMs do Compute Engine distribuídas por duas zonas em uma Google Cloud região. O aplicativo usa bancos de dados Oracle Exadata na mesma Google Cloud região.

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 também as orientações na seção Confiabilidade mais adiante neste documento.

A arquitetura mostrada no diagrama anterior inclui os seguintes componentes:

Componente Purpose
Balanceador de carga de aplicativo externo regional O balanceador de carga de aplicativo externo regional recebe solicitações de usuários e as distribui para as VMs no nível da Web.
Política de segurança do Google Cloud Armor A política de segurança do Google Cloud Armor ajuda a proteger o conjunto 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 do 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 interno do aplicativo. O MIG contém VMs do Compute Engine em duas zonas. Cada VM hospeda uma instância independente do servidor de aplicativos.
Rede de nuvem privada virtual (VPC) e sub-rede 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 no Google Cloud

Os servidores de aplicativos leem e gravam dados nos bancos de dados Oracle no serviço de banco de dados Oracle Exadata. Você provisiona o Oracle Exadata Database Service usando o Oracle Database@Google Cloud, uma oferta do Cloud Marketplace que permite executar bancos de dados do Oracle em hardware gerenciado pelo Oracle em um centro de dados Google Cloud .

Use Google Cloud interfaces como o console do Google Cloud, a Google Cloud CLI e APIs para criar instâncias da Exadata Infrastructure. O Oracle configura e gerencia a infraestrutura de computação, armazenamento e rede necessária em um data center em uma Google Cloud região em hardware dedicado ao seu projeto.

Instâncias da infraestrutura do Exadata Cada instância da Exadata Infrastructure 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 um tecido 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 da Exadata Infrastructure, você cria um ou mais clusters de VM do Exadata. Por exemplo, é possível criar e usar um cluster de VM do Exadata separado para hospedar os bancos de dados necessários para cada uma das 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, especifique 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 à qual o cluster precisa se conectar.
  • Intervalos de endereços IP das sub-redes de backup e cliente do 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 pelo console do OCI e outras interfaces do OCI. O software Oracle Database é executado nas VMs no cluster de VMs do Exadata. Ao criar o cluster de VM do Exadata, você especifica a versão da infraestrutura de grade do Oracle. Você também escolhe o tipo de licença: traga sua própria licença (BYOL) ou escolha o modelo de licença incluída.
VCN da OCI e sub-redes Quando você cria um cluster de VM do Exadata, uma rede de nuvem virtual (VCN, na sigla em inglês) do 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 aos bancos de dados Oracle. A sub-rede de backup é usada para enviar backups de banco de dados ao OCI Object Storage.
Cloud Router, Interconexão por parceiro e DRG OCI O tráfego entre a rede VPC e a VCN é roteado por um Cloud Router anexado à VPC e por um gateway de roteamento dinâmico (DRG) anexado à 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 os servidores de aplicativos enviam solicitações de leitura e gravação para os bancos de dados do 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 Oracle Exadata são armazenados no OCI Object Storage. Os backups do banco de dados são roteados para o OCI Object Storage por um gateway de serviço.
Gateway público do NAT do Cloud 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 a 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 Google Cloud , incluindo os recursos do Oracle Exadata. Também é possível monitorar os recursos no Oracle Exadata usando o serviço de monitoramento do OCI.

Produtos usados

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

  • Compute Engine: um serviço de computação seguro e personalizável que permite criar e executar VMs na infraestrutura do Google.
  • Cloud Load Balancing: um portfólio de balanceadores de carga globais, regionais, escalonáveis, globais e de alto desempenho.
  • Nuvem privada virtual (VPC): um sistema virtual que oferece funcionalidade de rede global e escalonável para suas cargas de trabalho Google Cloud . A VPC inclui peering de rede VPC, Private Service Connect, acesso a serviços particulares e VPC compartilhada.
  • Google Cloud Armor: um serviço de segurança de rede que oferece regras de firewall de aplicativos da Web (WAF, na sigla em inglês) 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 alto desempenho gerenciada por 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 a rede local e as redes de nuvem privada virtual e outras redes por 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.

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

  • Exadata Database Service em 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.
  • VCN e sub-redes: uma VCN é uma rede virtual e privada para recursos em uma região do OCI. Uma sub-rede é um intervalo contínuo 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 para permitir que os recursos em uma VCN acessem serviços específicos do Oracle de forma particular.

Considerações sobre o design

Esta seção descreve os fatores de design, as práticas recomendadas e as 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 aplicativo e dos produtos e recursos do Google Cloud e de terceiros que você usa, pode haver outros fatores de design e vantagens que você precisa considerar.

design do sistema

Esta seção fornece orientações para ajudar você a escolher regiões Google Cloud para sua implantação e selecionar os serviços Google Cloud apropriados.

Seleção da região

Ao escolher a região Google Cloud para a implantação, considere os seguintes fatores e requisitos:

  • Disponibilidade dos Google Cloud serviços 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.
  • Disponibilidade do Oracle Database@Google Cloud em cada região. Para mais informações, consulte Configurações disponíveis.
  • Requisitos de latência do usuário final.
  • Custo dos recursos Google Cloud .
  • 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. Saiba mais em 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 hospedar o nível da Web e do aplicativo. Dependendo dos requisitos do aplicativo, é possível escolher os seguintes serviços de computação 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ê prefere concentrar os esforços de TI nos dados e aplicativos em vez de configurar e operar recursos de infraestrutura, use os serviços sem servidor, como o Cloud Run e as funções do 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 e controle 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. As orientações de design para esses serviços estão fora do escopo deste documento. Para mais informações sobre as opções de serviço, consulte Hospedagem de aplicativos no Google Cloud.

Opções de armazenamento

Para fornecer armazenamento permanente para as VMs do Compute Engine no nível da Web e do aplicativo, escolha um tipo de Persistent Disk ou Google Cloud Hyperdisk apropriado com base nos requisitos de capacidade, escalonamento, disponibilidade e desempenho do aplicativo. Para mais informações, consulte Opções de armazenamento.

Se você precisar de armazenamento de baixo custo redundante nas zonas de uma região, use os buckets regionais do Cloud Storage.

Para armazenar dados compartilhados entre várias VMs em uma região, como arquivos de configuração de todas as VMs no nível da Web, use uma instância regional do Filestore. Os dados armazenados em uma instância regional do Filestore são replicados de maneira síncrona em três zonas na região1. Essa replicação ajuda a garantir alta disponibilidade e robustez contra interrupções de zona dos dados armazenados no Filestore. É possível armazenar arquivos de configuração compartilhados, ferramentas e utilitários comuns e registros centralizados na instância do Filestore e montar a instância em várias VMs.

Ao projetar o armazenamento para suas cargas de trabalho, considere as características funcionais das cargas de trabalho, requisitos de resiliência, expectativas de desempenho e 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

Ao criar a infraestrutura para uma pilha de aplicativos de vários níveis, você precisa escolher um design de rede que atenda aos seus requisitos técnicos e comerciais. A arquitetura mostrada neste documento usa uma topologia de rede simples com uma única rede VPC. Dependendo dos seus requisitos, é possível usar várias redes. Para mais informações, consulte a seguinte documentação:

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 de sub-rede. Para mais informações, consulte Planejar o espaço de endereços IP no Oracle Database@Google Cloud.

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 migrar dados locais para implantações de banco de dados Oracle em Google Cloud, use ferramentas padrão do Oracle, como o Oracle GoldenGate.

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.

Segurança

Esta seção descreve os fatores a serem considerados 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 seu aplicativo contra ameaças externas, como ataques DDoS e XSS, defina as políticas de segurança do Google Cloud Armor adequadas com base nos seus requisitos. Cada política é um conjunto de regras que especifica as condições a serem avaliadas e as ações a serem tomadas quando as condições forem 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 WAF pré-configuradas. 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 que hospedam o nível da Web e do aplicativo não precisam de acesso de entrada direto da Internet. Não atribua endereços IP externo a essas VMs. Google Cloud Os recursos com apenas endereços IP internos e particulares 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 Google Cloud recursos que têm apenas endereços IP privados, como as VMs do Compute Engine nesta arquitetura de referência, use o Cloud NAT conforme mostrado no diagrama de arquitetura anterior ou use o Secure Web Proxy.

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

Segurança de imagens de VM

Imagens aprovadas são imagens com software que atende à sua política ou aos requisitos de segurança. Para garantir que as VMs no nível da Web e do aplicativo usem apenas imagens aprovadas, defina uma política da organização que restrinja o uso de imagens em projetos de imagens públicas específicos. Para mais informações, consulte Como configurar políticas de imagem confiáveis.

Privilégios da conta de serviço

Nos projetos do Google Cloud em que a API Compute Engine está ativada, uma conta de serviço padrão é criada automaticamente. Para Google Cloud organizações criadas antes de 3 de maio de 2024, essa conta de serviço padrão recebe o papel de Editor do IAM (roles/editor), a menos que esse comportamento esteja desativado.

Por padrão, a conta de serviço padrão é anexada a todas as VMs do Compute Engine criadas usando a CLI gcloud ou o console do Google Cloud. O papel de editor inclui uma ampla variedade de permissões. Portanto, anexar a conta de serviço padrão às VMs cria um risco de segurança. Para evitar esse risco, é possível criar e usar contas de serviço dedicadas para cada nível da pilha de aplicativos. Para especificar os recursos que a conta de serviço pode acessar, use políticas detalhadas. Para mais informações, consulte Limitar os privilégios da conta de serviço.

Segurança de rede

Para controlar o tráfego de rede entre os recursos do nível da Web e do aplicativo da arquitetura, é necessário configurar as políticas do Cloud Next Generation Firewall (NGFW) adequadas.

Segurança e compliance de bancos de dados

O serviço Exadata Database inclui o Oracle Data Safe, que ajuda a gerenciar requisitos de segurança e conformidade para 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.

Confiabilidade

Esta seção descreve os fatores de design que você precisa considerar ao usar essa arquitetura de referência para criar e operar uma infraestrutura confiável para a implantação em Google Cloud.

Robustez contra falhas de VM

Na arquitetura mostrada neste documento, se uma VM do Compute Engine no nível da Web ou do aplicativo falhar, o MIG relevante recria a VM automaticamente. Os balanceadores de carga encaminham solicitações apenas para as instâncias do servidor da Web e do servidor de aplicativos disponíveis.

Recuperação automática de VM

Às vezes, as VMs que hospedam a camada da Web e do aplicativo podem estar em execução e disponíveis, mas pode haver problemas com o próprio aplicativo. O app pode congelar, falhar ou não ter memória suficiente. Nesse cenário, as VMs não vão responder às verificações de integridade do balanceador de carga, e o balanceador não vai rotear o tráfego para as VMs sem resposta. Para garantir que os aplicativos respondam conforme o esperado, configure verificações de integridade baseadas em aplicativos 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 da região

Se ocorrer uma falha temporária na região, o aplicativo ficará indisponível. Para reduzir o tempo de inatividade causado por falhas na região, implemente a seguinte abordagem:

  • Mantenha uma réplica passiva (failover) do nível da Web e do nível do aplicativo em outra Google Cloud região.
  • Crie uma instância de infraestrutura de Exadata reserva 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 a replicação de dados e o failover automático para os bancos de dados Exadata de reserva. 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 falha temporária 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 uma interrupção de região ocorre, use o arquétipo de implantação multirregional. É possível usar o Oracle Active Data Guard para fornecer um banco de dados de 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 serviço de banco de dados Oracle Exadata em infraestrutura dedicada, consulte Objetivos de nível de serviço para serviços de nuvem pública do Oracle PaaS e IaaS.

Escalonamento automático de MIG

A arquitetura neste documento usa MIGs regionais para o nível da Web e do aplicativo. O recurso de escalonamento automático de MIGs sem estado garante que as VMs do Compute Engine que hospedam o nível da Web e do aplicativo não sejam afetadas por falhas de zona única. MIGs com estado não podem ser escalonados automaticamente.

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 mais informações, consulte Escalonamento automático de grupos de instâncias.

Posicionamento da VM

Na arquitetura descrita neste documento, a camada do aplicativo e da Web são executadas nas VMs do Compute Engine distribuídas por várias zonas. Essa distribuição ajuda a garantir que o nível da Web e o nível do aplicativo sejam robustos contra interrupções de uma zona. Para melhorar ainda mais essa robustez, crie uma política de posicionamento distribuído e aplique-a ao modelo do MIG. Com uma política de posicionamento distribuída, quando o MIG cria VMs, ele as coloca em cada zona em diferentes servidores físicos (chamados de hosts), de modo que suas VMs sejam resistentes contra falhas de hosts individuais. No entanto, uma desvantagem dessa abordagem é que a latência do tráfego de rede entre VMs pode aumentar. Para mais informações, consulte Visão geral das políticas de posicionamento.

Planejamento de capacidade de VM

Para garantir que a capacidade de VMs do Compute Engine esteja disponível quando necessário para o escalonamento automático de MIGs, 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. Você vai receber cobranças por recursos reservados, mesmo que eles não sejam provisionados ou usados. Para mais informações sobre reservas, incluindo considerações sobre faturamento, consulte Reservas de recursos zonais do Compute Engine.

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 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 facilmente 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.

Capacidade do banco de dados

É possível dimensionar a Exadata Infrastructure 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 à Exadata Infrastructure, adicione a capacidade ao cluster de VM Exadata associado para poder usar os recursos de CPU ou armazenamento adicionais. Para mais informações, consulte Como dimensionar o Exadata Compute e o Exadata Storage.

Backup e recuperação

É 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 as 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 serviço de DR para backups de instâncias do Compute Engine.

Por padrão, os backups de bancos de dados no Oracle Exadata Database Service em infraestrutura dedicada são armazenados no OCI Object Storage. Para alcançar um RPO menor, faça backup e recupere os 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

Esta seção fornece 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 das VMs, o Compute Engine fornece recomendações de tipo de máquina. Use as recomendações para escolher os tipos de máquina que correspondem aos requisitos de computação das VMs do nível da Web e do nível do aplicativo. 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áquina 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 no nível da Web e do aplicativo. O custo das VMs spot é significativamente menor do que as VMs regulares. No entanto, o Compute Engine pode interromper ou excluir preemptivamente 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 alcançar 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. O escalonamento automático também ajuda a reduzir custos quando a necessidade de recursos é baixa. MIGs com estado não podem ser escalonados automaticamente.

Custos do banco de dados

Ao criar um cluster de VM do Exadata, você pode escolher o BYOL ou provisionar bancos de dados do Oracle incluídos na licença.

As cobranças de rede para transferência de dados entre seus aplicativos e bancos de dados do Oracle Exadata que estão 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 em Google Cloud Framework de arquitetura: otimização de custos.

Eficiência operacional

Esta seção descreve os fatores a serem considerados ao usar essa arquitetura de referência para projetar uma topologia 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 um método de atualização especificado por você: 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 de VM

Para seus modelos de instância MIG, em vez de usar imagens públicas fornecidas pelo Google, recomendamos que você crie e use imagens de SO personalizadas que incluam as configurações e o software que seus aplicativos exigem. É possível agrupar suas imagens personalizadas em uma família de imagens personalizadas. Uma família de imagens sempre aponta para 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 atualizações de segurança e patches 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 (por exemplo, para instalar software de terceiros), verifique se os scripts especificam explicitamente os parâmetros de instalação do software, como a versão do software. Caso contrário, quando o MIG criar as VMs, o software instalado nas VMs 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.

Administração de banco de dados

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

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 em Google Cloud Framework de arquitetura: excelência operacional.

Otimização de desempenho

Esta seção descreve os fatores a serem considerados 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 cargas de trabalho. Para as VMs que hospedam o nível da Web e do aplicativo, escolha um tipo de máquina adequado com base nos requisitos de desempenho para esses níveis. Para mais informações, consulte Comparação de séries de máquina.

Desempenho da rede

Para cargas de trabalho que precisam de baixa latência de rede entre VMs nas camadas do aplicativo e da Web, crie uma política de posicionamento compacta e aplique-a ao modelo MIG usado para essas camadas. Quando o MIG cria VMs, ele as coloca em servidores físicos próximos uns dos outros. Enquanto uma política de posicionamento compacto ajuda 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 o equilíbrio ideal entre o desempenho e a disponibilidade da rede, ao criar uma política de posicionamento compacto, você pode 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 saída da rede. 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áquina, é possível ter uma largura de banda de saída máxima maior ativando a rede Tier_1 para melhorar o desempenho da rede. Para mais informações, consulte Configurar o desempenho de rede Tier_1 por VM.

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

A Exadata Infrastructure usa RDMA sobre Ethernet Convergente (RoCE) para redes 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 envolvimento do processador, cache ou sistema operacional.

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 de arquitetura: otimização de desempenho.

A seguir

Colaboradores

Autor: Kumar Dhanagopal | Desenvolvedor de soluções de vários produtos

Outros colaboradores:


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