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) aplicativos locais que usam bancos de dados Oracle de maneira eficiente para Google Cloud. Este documento também inclui orientações para ajudar você a criar uma topologia do Oracle Database em 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 do Oracle. O documento pressupõe 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 localmente, é possível migrar seus aplicativos de forma eficiente para Google Cloud e executar seus bancos de dados no Oracle Database@Google Cloud. Para mais informações, consulte Aplicativo empresarial em VMs do Compute Engine com o Oracle Exadata no Google Cloud.
Arquitetura
O diagrama a seguir mostra a infraestrutura de um aplicativo empresarial de vários níveis que usa o Oracle Database. As instâncias do banco de dados Oracle, do nível da Web e do nível do aplicativo são hospedadas em VMs do Compute Engine. O nível da Web e o nível do aplicativo são executados no modo ativo-ativo em VMs distribuídas em duas zonas de uma Google Cloud região. As instâncias do banco de dados principal e de 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 Google Cloud seja robusta contra interrupções de zona única1.
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 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 sites (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 no nível da Web para as VMs no 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. |
Instâncias do Oracle Database implantadas em VMs do Compute Engine | O aplicativo nesta arquitetura usa um par primário-reserva 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 do banco de dados. |
Pools de armazenamento de hiperdisco | As VMs em cada zona (em todas as camadas da pilha do aplicativo) usam volumes do Hyperdisk equilibrado 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 de armazenamento e o desempenho 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 de espera do Oracle Database quando a instância principal está indisponível. O observador é executado em uma VM do Compute Engine em uma zona diferente das zonas em que as instâncias do banco de dados principal e de espera são implantadas. |
Bucket do Cloud Storage | Para armazenar backups das instâncias do Oracle Database, essa arquitetura usa um bucket do Cloud Storage. Para facilitar a recuperação do banco de dados durante uma falha de região, 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 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 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 e Cloud Logging | O Cloud Monitoring ajuda a observar o comportamento, a integridade e o desempenho do aplicativo e dos recursos 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 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.
- Google Cloud Hyperdisk: um serviço de armazenamento de rede que pode ser usado para provisionar e dimensionar 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 de fora do Google Cloude são replicados entre locais para redundância.
- 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 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 amplia 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 comprar licenças dos produtos da Oracle que você implanta no Google Cloude por obedecer aos termos e condições das licenças da Oracle.
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.
- 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 todos os níveis 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 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 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 Opções de hospedagem de aplicativos.
Opções de armazenamento
A arquitetura mostrada neste documento usa um pool de armazenamento do Hyperdisk em cada zona, com volumes do Hyperdisk Balanced para as VMs em todos os níveis. Os volumes do hiperdisco oferecem melhor desempenho, flexibilidade e eficiência do que o Persistent Disk. Para informações sobre os tipos e recursos do Hyperdisk, consulte Sobre o Hyperdisk.
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ão. Essa replicação garante alta disponibilidade e robustez contra interrupções dos serviços da zona. É possível armazenar arquivos de configuração compartilhados, ferramentas e utilitários comuns e registros centralizados na instância do Filestore e ativá-la 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 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 e sub-rede. Dependendo dos seus requisitos, é possível usar várias redes VPC ou sub-redes. Para mais informações, consulte a seguinte documentação:
- Como decidir se você precisa criar várias redes VPC
- Decidir o design da rede para sua Google Cloud zona de destino
segurança, privacidade e conformidade
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 ajudar a 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 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 que hospedam o nível da Web, o nível do aplicativo e as instâncias do Oracle Database não precisam de acesso de entrada direto da Internet. Não atribua endereços IP externo a essas VMs. Google Cloud Os recursos que têm apenas endereços IP internos 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 Secure Web Proxy ou o Cloud NAT.
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 suas VMs 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 criadas usando a CLI do Google Cloud ou o console do Google Cloud. O papel 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.
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, é possível 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.
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 falhar em qualquer um dos níveis, o aplicativo poderá continuar processando as solicitações.
- Se uma VM 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 no momento.
- Se a VM que hospeda a instância principal do Oracle Database falhar, o observador do FSFO do Oracle Data Guard vai iniciar um failover automático para a instância do Oracle Database em espera.
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 de zona
Se ocorrer uma falha temporária na zona, o aplicativo vai continuar disponível.
- O nível da Web e o nível do aplicativo estão disponíveis (e responsivos) 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 falha afetar a zona que tem a instância principal do Oracle Database, o observador do FSFO do Oracle Data Guard inicia um failover automático para a instância de espera do Oracle Database. O observador FSFO é executado em uma VM em uma zona diferente das que têm as instâncias de banco de dados principal e de espera.
- Para garantir a alta disponibilidade de dados em volumes do Hyperdisk durante uma interrupção de uma zona, use o Hyperdisk Balanced High Availability. Quando os dados são gravados em um volume, eles são replicados de forma síncrona entre duas zonas na mesma região.
Robustez contra interrupções da região
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:
- Mantenha uma réplica passiva (failover) da pilha de infraestrutura em outra Google Cloud região.
Use um bucket birregional ou multirregional do Cloud Storage para armazenar os backups do banco de dados Oracle. Os backups são replicados de forma assíncrona em pelo menos dois locais geográficos. Com backups de banco de dados replicados, sua arquitetura é mapeada para o nível Prata da arquitetura de disponibilidade máxima (MAA) da Oracle.
Para conseguir uma replicação mais rápida de backups armazenados em buckets birregionais, use a replicação turbo. Para mais informações, consulte Disponibilidade e durabilidade dos dados.
Se ocorrer uma falha temporária na região principal, use o backup do banco de dados para restaurar o banco de dados e ativar o aplicativo na região de failover. Use políticas de roteamento de DNS para rotear o tráfego para o balanceador de carga 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. Para o nível do banco de dados, use o FSFO do Oracle Active Data Guard para failover automático para uma instância de banco de dados Oracle de espera na região de failover. Essa abordagem é mapeada para o nível Gold do MAA da Oracle.
Escalonamento automático de MIG
Quando você executa o aplicativo em VMs de um MIG regional, ele permanece disponível durante interrupções em zonas isoladas. A capacidade de escalonamento automático de MIGs sem estado permite manter a disponibilidade e o desempenho do aplicativo em níveis previsíveis. 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 garante que o aplicativo seja robusto contra interrupções de zona única. 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 de propagação, quando o MIG cria VMs, ele as coloca em cada zona em diferentes servidores físicos (chamados de hosts), de modo que as 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.
Disponibilidade do armazenamento em blocos
A arquitetura neste documento usa um pool de armazenamento de hiperdisco em cada zona para fornecer armazenamento em bloco 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 volumes à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 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.
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 bi 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, você pode 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 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 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:
- Google Cloud Guia de confiabilidade da infraestrutura
- Padrões para apps escalonáveis e resilientes
- Como projetar sistemas resilientes
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 dos recursos 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á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, opções e desempenho de máquina que as VMs regulares. No entanto, quando a capacidade de recursos em uma zona é limitada, os MIGs com VMs spot podem não conseguir fazer escalonar horizontalmente (ou seja, criar VMs) automaticamente para alcançar o tamanho de destino especificado até que a capacidade necessária fique disponível novamente. Não use VMs spot para as VMs que hospedam as instâncias do Oracle Database.
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.
Licenciamento do Oracle Database
Você é responsável por comprar as licenças dos produtos da Oracle que implantar no Compute Engine e por obedecer aos termos e condições das licenças da Oracle. Ao calcular o custo de licenciamento do Oracle Database, considere o número de licenças do Oracle Processor que são necessárias com base no tipo de máquina escolhido para as VMs do Compute Engine que hospedam as instâncias do Oracle Database. Para mais informações, consulte Como licenciar o software Oracle no ambiente de computação em nuvem.
Utilizar recursos de armazenamento em blocos
A arquitetura neste documento usa um pool de armazenamento de hiperdisco em cada zona para fornecer armazenamento em bloco para as VMs do Compute Engine. É possível melhorar a utilização geral da capacidade de armazenamento em blocos e reduzir custos usando pools de armazenamento de capacidade avançada, que usam provisionamento thin 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 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 as atualizações de segurança e os 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.
Gerenciamento de armazenamento em blocos
A arquitetura neste documento usa um pool de armazenamento de hiperdisco em cada zona para fornecer armazenamento em bloco para as VMs do Compute Engine. Os pools de armazenamento do Hyperdisk ajudam a simplificar o gerenciamento de armazenamento. Em vez de alocar e gerenciar a capacidade individualmente para vários discos, você define 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 volumes à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 do aplicativo ao banco de dados
Para conexões do seu aplicativo com o Oracle Database, recomendamos usar o nome DNS interno zonal da VM do banco de dados em vez do endereço IP. 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 do banco de dados.
Suporte e administração do Oracle Database
Quando você executa uma instância autogerenciada do Oracle Database em uma VM do Compute Engine, há problemas operacionais semelhantes aos que ocorrem quando você executa o Oracle Database localmente. No entanto, com uma VM do Compute Engine, você não precisa mais gerenciar a infraestrutura de computação, rede e armazenamento subjacente.
- Para receber orientações sobre como operar e gerenciar suas instâncias do Oracle Database, consulte a documentação fornecida pela Oracle para a versão relevante.
- Para informações sobre a política de suporte do Oracle para instâncias do Oracle Database implantadas em Google Cloud, consulte Suporte do Oracle Database para ambientes de nuvem pública que não são do Oracle (ID do documento 2688277.1).
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 apropriado com base nos requisitos de desempenho para esses níveis. Para conferir uma lista dos tipos de máquina disponíveis que oferecem suporte a volumes do Hyperdisk e que atendem ao seu desempenho e outros requisitos, 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 na série de máquinas C4 da família de máquinas de uso geral. Os tipos de máquina C4 oferecem alto desempenho consistente para cargas de trabalho de banco de dados.
Desempenho da rede
Para cargas de trabalho que precisam de baixa latência de rede entre VMs, crie uma política de posicionamento compacta e aplique-a ao modelo MIG usado para o nível do aplicativo. Quando o MIG cria VMs, ele as coloca em servidores físicos próximos uns dos outros. Enquanto uma política de posicionamento compacta ajuda a melhorar o desempenho da rede entre VMs, uma política de posicionamento distribuída pode ajudar a melhorar a disponibilidade da VM, conforme descrito anteriormente. Para alcançar o equilíbrio ideal entre a performance 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 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.
Desempenho do armazenamento do hiperdisco
A arquitetura descrita neste documento usa volumes do 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 de processamento 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 conectados. Para mais informações sobre os limites e o ajuste de desempenho do Hyperdisk, consulte a seguinte documentação:
- Tipos de máquina compatíveis com o Hyperdisk
- Limites de desempenho de hiperdisco
- Otimizar o desempenho do hiperdisco
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
- Acelerar a transformação em nuvem com Google Cloud e a Oracle
- Arquiteturas de referência do Oracle MAA
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.
Colaboradores
Autor: Kumar Dhanagopal | Desenvolvedor de soluções de vários produtos
Outros colaboradores:
- Andy Colvin | Database Black Belt Engineer (Oracle on Google Cloud)
- Jeff Welsch | Diretor, gerenciamento de produtos
- Lee Gates | Gerente de produtos do grupo
- Marc Fielding | Arquiteto de infraestrutura de dados
- Mark Schlagenhauf | Redator técnico, Rede
- Michelle Burtoft | Gerente de produtos sênior
- Rajesh Kasanagottu | Gerente de engenharia
- Sekou Page | Gerente de produtos de prospecção ativa
- Souji Madhurapantula | Gerente de produtos do grupo
- Victor Moreno | Gerente de produtos, Cloud Networking
- Yeonsoo Kim | Gerente de produtos
-
Para mais informações sobre considerações específicas de cada região, consulte Geografia e regiões. ↩