Implementação de zona única no Compute Engine

Last reviewed 2025-08-12 UTC

Este documento fornece uma arquitetura de referência para uma aplicação de vários níveis que é executada em VMs do Compute Engine numa única zona no Google Cloud. Pode usar esta arquitetura de referência para realoja (lift and shift) aplicações no local na nuvem de forma eficiente com alterações mínimas às aplicações. O documento também descreve os fatores de design que deve considerar quando criar uma arquitetura zonal para as suas aplicações na nuvem. O público-alvo deste documento são arquitetos da nuvem.

Arquitetura

O diagrama seguinte mostra uma arquitetura para uma aplicação que é executada numa única Google Cloud zona. Esta arquitetura está alinhada com o Google Cloud arquétipo de implementação zonal.

Arquitetura de zona única com o Compute Engine.

A arquitetura baseia-se no modelo de nuvem de infraestrutura como serviço (IaaS). Aprovisiona os recursos de infraestrutura necessários (computação, redes e armazenamento) em Google Cloud. Mantém o controlo total sobre a infraestrutura e a responsabilidade pelo sistema operativo, middleware e camadas superiores da pilha de aplicações. Para saber mais sobre a IaaS e outros modelos na nuvem, consulte o artigo PaaS vs. IaaS vs. SaaS vs. CaaS: How are they different?

O diagrama anterior inclui os seguintes componentes:

Componente Finalidade
Balanceador de carga externo regional

O balanceador de carga externo regional recebe e distribui pedidos de utilizadores para as VMs da camada Web.

Grupo de instâncias geridas (GIG) zonal para a camada Web A camada Web da aplicação é implementada em VMs do Compute Engine que fazem parte de um GIG zonal. O MIG é o back-end do balanceador de carga externo regional. Cada VM no MIG aloja uma instância independente da camada Web da aplicação.
Balanceador de carga interno regional

O balanceador de carga interno regional distribui o tráfego das VMs da camada Web para as VMs da camada de aplicação.

MIG zonal para o nível da aplicação A camada de aplicação é implementada em VMs do Compute Engine que fazem parte de um GIG zonal, que é o back-end do balanceador de carga interno. Cada VM no MIG aloja uma instância independente da camada de aplicação.
Base de dados de terceiros implementada numa VM do Compute Engine

A arquitetura neste documento mostra uma base de dados de terceiros (como o PostgreSQL) implementada numa VM do Compute Engine. Pode implementar uma base de dados em espera noutra zona. As capacidades de replicação e comutação por falha da base de dados dependem da base de dados que usa.

A instalação e a gestão de uma base de dados de terceiros envolvem esforço adicional e custo operacional para aplicar atualizações, monitorizar e garantir a disponibilidade. Pode evitar a sobrecarga de instalar e gerir uma base de dados de terceiros e tirar partido das funcionalidades de alta disponibilidade (HA) incorporadas através de um serviço de base de dados totalmente gerido, como o Cloud SQL ou o AlloyDB para PostgreSQL. Para mais informações sobre as opções de base de dados geridas, consulte o artigo Serviços de base de dados.

Rede de nuvem privada virtual 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

Contentor regional do Cloud Storage

As cópias de segurança de aplicações e bases de dados são armazenadas num contentor do Cloud Storage regional. Se ocorrer uma interrupção de zona, a sua aplicação e dados não são perdidos.

Em alternativa, pode usar o serviço de cópia de segurança e recuperação de desastres para criar, armazenar e gerir as cópias de segurança da base de dados.

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

Exemplos de utilização

Esta secção descreve exemplos de utilização para os quais uma implementação de zona única no Compute Engine é uma escolha adequada.

  • Desenvolvimento e testes na nuvem: pode usar uma arquitetura de implementação de zona única para criar um ambiente de nuvem de baixo custo para desenvolvimento e testes.
  • Aplicações que não precisam de HA: uma arquitetura de zona única pode ser suficiente para aplicações que podem tolerar o tempo de inatividade devido a falhas de infraestrutura.
  • Rede de baixa latência e baixo custo entre componentes da aplicação: uma arquitetura de zona única pode ser adequada para aplicações como a computação em lote que precisam de ligações de rede de baixa latência e elevada largura de banda entre os nós de computação. Com uma implementação de zona única, não existe tráfego de rede entre zonas e não incorre em custos com o tráfego dentro da zona.
  • Migração de cargas de trabalho de commodities: a arquitetura de implementação zonal oferece um caminho de migração para a nuvem para aplicações de commodities nas instalações sobre as quais não tem controlo do código ou que não podem suportar arquiteturas além de uma topologia ativa-passiva básica.
  • Executar software com restrições de licença: uma arquitetura de zona única pode ser adequada para sistemas com restrições de licença em que a execução de mais do que uma instância de cada vez é demasiado cara ou não é permitida.

Considerações de design

Esta secção fornece orientações para ajudar a usar esta arquitetura de referência para desenvolver uma arquitetura que cumpra os seus requisitos específicos de design do sistema, segurança, fiabilidade, eficiência operacional, custo e desempenho.

Quando cria a arquitetura para a sua carga de trabalho, considere as práticas recomendadas e as recomendações na Google Cloud framework Well-Architected.

Design do sistema

Esta secção fornece orientações para ajudar a escolher Google Cloud regiões e zonas para a sua implementação zonal, bem como para 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.

Serviços de armazenamento

A arquitetura apresentada neste documento usa volumes de discos persistentes zonais para todos os níveis. Para um armazenamento persistente mais duradouro, pode usar volumes de discos persistentes regionais, que oferecem replicação síncrona de dados em duas zonas numa região.

O Hyperdisk do Google Cloud oferece melhor desempenho, flexibilidade e eficiência do que o disco persistente. Com o Hyperdisk Balanced, pode aprovisionar IOPS e débito separadamente e de forma dinâmica, o que lhe permite ajustar o volume a uma grande variedade de cargas de trabalho.

Para armazenamento de baixo custo replicado em várias localizações, pode usar contentores regionais, de duas regiões ou multirregionais do Cloud Storage.

  • Os dados em contentores regionais são replicados de forma síncrona nas zonas da região.
  • Os dados em contentores de duas regiões ou multirregiões são armazenados de forma redundante em, pelo menos, duas localizações geográficas separadas. Os metadados são escritos de forma síncrona em todas as regiões, e os dados são replicados de forma assíncrona. Para contentores de dupla região, pode usar a replicação turbo, que garante que os objetos são replicados em pares de regiões, com um objetivo de ponto de recuperação (RPO) de 15 minutos. Para mais informações, consulte o artigo Disponibilidade e durabilidade dos dados.

Para armazenar dados partilhados por várias VMs numa região, como todas as VMs na camada Web ou na camada de aplicação, pode usar uma instância regional do Filestore. Os dados que armazena numa instância regional do Filestore são replicados de forma síncrona em três zonas na região. Esta replicação garante a alta disponibilidade e a robustez contra falhas de zonas. Pode armazenar ficheiros de configuração partilhados, ferramentas e utilitários comuns, e registos centralizados na instância do Filestore e montar a instância em várias VMs. Para garantir a robustez contra interrupções regionais, pode replicar uma instância do Filestore para uma região diferente. Para mais informações, consulte o artigo Replicação de instâncias.

Se a sua base de dados for o Microsoft SQL Server, recomendamos que use o Cloud SQL para SQL Server. Em cenários em que o Cloud SQL não suporta os seus requisitos de configuração ou se precisar de acesso ao sistema operativo, pode implementar uma instância de cluster de failover (FCI) do Microsoft SQL Server. Neste cenário, pode usar os volumes do Google Cloud NetApp totalmente geridos para fornecer armazenamento SMB de disponibilidade contínua (CA) para a base de dados.

Quando cria armazenamento para as suas cargas de trabalho, tenha em conta as características funcionais, 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.

Serviços de bases de dados

A arquitetura de referência neste documento usa uma base de dados de terceiros implementada em VMs do Compute Engine. A instalação e a gestão de uma base de dados de terceiros implicam esforço e custos para operações como a aplicação de atualizações, a monitorização e a garantia da disponibilidade, a realização de cópias de segurança e a recuperação de falhas.

Pode evitar o esforço e o custo de instalar e gerir uma base de dados de terceiros usando um serviço de base de dados totalmente gerido como o Cloud SQL, o AlloyDB para PostgreSQL, o Bigtable, o Spanner ou o Firestore. Estes Google Cloud serviços de base de dados oferecem contratos de nível de serviço (SLAs) de tempo de atividade e incluem capacidades predefinidas de escalabilidade e observabilidade.

Se a sua carga de trabalho precisar de uma base de dados Oracle, pode implementar a base de dados numa VM do Compute Engine ou usar o Oracle Database@Google Cloud. Para mais informações, consulte o artigo Cargas de trabalho da Oracle no Google Cloud.

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 que deve considerar quando usa esta arquitetura de referência para conceber e criar uma topologia zonal no Google Cloud que cumpre 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.

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.

Cada regra de firewall permite-lhe controlar o tráfego com base em parâmetros como o protocolo, o endereço IP e a porta. Por exemplo, pode configurar uma regra de firewall para permitir o tráfego TCP das VMs do servidor Web para uma porta específica das VMs da base de dados e bloquear todo o outro tráfego.

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 que deve considerar quando usa esta arquitetura de referência para criar e operar uma infraestrutura fiável para as suas implementações zonais no Google Cloud.

Robustez contra interrupções de infraestruturas

Numa arquitetura de implementação de zona única, se qualquer componente na pilha de infraestrutura falhar, a aplicação pode processar pedidos se cada camada contiver, pelo menos, um componente funcional com capacidade adequada. Por exemplo, se uma instância do servidor Web falhar, o balanceador de carga encaminha os pedidos dos utilizadores para as outras instâncias do servidor Web disponíveis. Se uma VM que aloja uma instância de servidor Web ou de app falhar, o MIG recria automaticamente a VM. Se a base de dados falhar, tem de ativar manualmente a segunda base de dados e atualizar as instâncias do servidor de apps para estabelecer ligação à base de dados.

Uma indisponibilidade de zona ou de região afeta todas as VMs do Compute Engine numa implementação de zona única. Uma indisponibilidade de zona não afeta o balanceador de carga nesta arquitetura porque é um recurso regional. No entanto, o equilibrador de carga não consegue distribuir o tráfego porque não existem back-ends disponíveis. Se ocorrer uma indisponibilidade de uma zona ou de uma região, tem de aguardar que a Google resolva a indisponibilidade e, em seguida, verificar se a aplicação funciona conforme esperado.

Pode reduzir o tempo de inatividade causado por falhas de zonas ou regiões mantendo uma réplica passiva (de alternativa) da pilha de infraestrutura noutraGoogle Cloud zona ou região. Se ocorrer uma indisponibilidade na zona principal, pode ativar a pilha na zona ou região de alternativa e usar uma política de encaminhamento de DNS para encaminhar o tráfego para o equilibrador de carga na zona ou região de alternativa.

Para aplicações que requerem robustez contra interrupções de zonas ou regiões, considere usar uma arquitetura regional ou multirregional. Veja as seguintes arquiteturas de referência:

Escala automática do MIG

A capacidade de escala automática dos GIGs sem estado permite-lhe manter a disponibilidade e o desempenho da aplicação a níveis previsíveis.

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.

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.

Posicionamento de VMs

Na arquitetura descrita neste documento, a camada de aplicação e a camada Web são executadas em VMs do Compute Engine numa única zona.

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.

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.

Durabilidade dos dados

Pode usar o Backup and DR para criar, armazenar e gerir cópias de segurança das VMs do Compute Engine. A cópia de segurança e a RD armazenam dados de cópia de segurança no formato original legível pela aplicação. Quando necessário, pode restaurar as suas cargas de trabalho para produção usando diretamente dados do armazenamento de cópias de segurança a longo prazo e evitar a necessidade de preparar ou mover dados.

O Compute Engine oferece as seguintes opções para ajudar a garantir a durabilidade dos dados armazenados em volumes de discos persistentes:

Disponibilidade da base de dados

Se usar um serviço de base de dados gerido, como o Cloud SQL na configuração de HA, em caso de falha da base de dados principal, o Cloud SQL faz automaticamente o failover para a base de dados em espera. Não tem de alterar o endereço IP do ponto final da base de dados. Se usar uma base de dados de terceiros autogerida implementada numa VM do Compute Engine, tem de usar um equilibrador de carga interno ou outro mecanismo para garantir que a aplicação se pode ligar a outra base de dados se a base de dados principal estiver indisponível.

Para implementar a comutação por falha entre zonas para uma base de dados implementada numa VM do Compute Engine, precisa de um mecanismo para identificar falhas da base de dados principal e um processo para comutar por falha para a base de dados em espera. As especificidades do mecanismo de comutação por falha dependem da base de dados que usa. Pode configurar uma instância de observador para detetar falhas da base de dados principal e orquestrar a comutação por falha. Tem de configurar as regras de alternativa adequadamente para evitar uma situação de cérebro dividido e impedir a alternativa desnecessária. Para ver exemplos de arquiteturas que pode usar para implementar a comutação por falha para bases de dados PostgreSQL, consulte o artigo Arquiteturas para alta disponibilidade de clusters PostgreSQL no Compute Engine.

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 zonal Google Cloud que cria através desta arquitetura de referência.

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.

Licenciamento de terceiros

Quando migra cargas de trabalho de terceiros para o Google Cloud, pode reduzir os custos usando as suas próprias licenças (BYOL). Por exemplo, para implementar VMs com o Microsoft Windows Server, em vez de usar uma imagem premium que incorre em custos adicionais para a licença de terceiros, pode criar e usar uma imagem BYOL do Windows personalizada. Depois, paga apenas pela infraestrutura de VM que usa no Google Cloud. Esta estratégia ajuda a continuar a obter valor dos seus investimentos existentes em licenças de terceiros. Se decidir usar a abordagem BYOL, as seguintes recomendações podem ajudar a reduzir o custo:

  • Aprovisione o número necessário de núcleos da CPU de computação independentemente da memória através de tipos de máquinas personalizados. Ao fazê-lo, limita o custo de licenciamento de terceiros ao número de núcleos do CPU de que precisa.
  • Reduza o número de vCPUs por núcleo de 2 para 1 desativando o multithreading simultâneo (SMT).

Se implementar uma base de dados de terceiros, como o Microsoft SQL Server, em VMs do Compute Engine, tem de considerar os custos de licença do software de terceiros. Quando usa um serviço de base de dados gerido, como o Cloud SQL, os custos da licença da base de dados estão incluídos nos encargos do serviço.

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 que deve considerar quando usa esta arquitetura de referência para conceber e criar uma topologia zonal que possa operar de forma eficiente. Google Cloud

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 de VMs

Para as suas VMs, em vez de usar imagens públicas fornecidas pela Google, recomendamos que crie e use imagens de SO personalizadas que contenham as configurações e o software que as suas aplicações requerem. 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, para que os seus modelos de instâncias e scripts possam usar essa imagem sem ter de atualizar as 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.

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 que deve considerar quando usa esta arquitetura de referência para conceber e criar uma topologia zonal que cumpra os requisitos de desempenho das suas cargas de trabalho.Google Cloud

Desempenho de computação

O Compute Engine oferece uma ampla gama de tipos de máquinas predefinidos e personalizáveis para as cargas de trabalho que executa em VMs. Escolha um tipo de máquina adequado com base nos seus requisitos de desempenho. Para mais informações, consulte o recurso de famílias de máquinas e o guia de comparação.

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.

Níveis de serviço de rede

Os níveis de serviço de rede permitem otimizar o custo e o desempenho da rede das suas cargas de trabalho. Pode escolher o nível Premium ou o nível Standard. O nível Premium fornece tráfego na infraestrutura global da Google para alcançar uma perda de pacotes mínima e uma latência baixa. O nível padrão fornece tráfego através de intercâmbio de tráfego, fornecedores de serviços de Internet (ISP) ou redes de trânsito num ponto de presença (PoP) periférico mais próximo da região onde a sua Google Cloud carga de trabalho é executada. Para otimizar o desempenho, recomendamos que use o nível Premium. Para otimizar os custos, recomendamos que use o nível padrão.

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.

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: