Implantação de zona única no Compute Engine

Last reviewed 2024-02-08 UTC

Neste documento, apresentamos uma arquitetura de referência para um aplicativo de várias níveis executado em VMs do Compute Engine em uma única zona no Google Cloud. É possível usar essa arquitetura de referência para re-hospedar (migração lift-and-shift) de aplicativos locais para a nuvem de maneira eficiente com alterações mínimas nos aplicativos. O documento também descreve os fatores de design que você precisa considerar ao criar uma arquitetura zonal para seus aplicativos na nuvem. Os arquitetos de nuvem são o público-alvo deste documento.

Arquitetura

O diagrama a seguir mostra uma arquitetura para um aplicativo executado em uma única zona do Google Cloud. Essa arquitetura está alinhada com o arquétipo de implantação zonal do Google Cloud.

Arquitetura de zona única usando o Compute Engine.

A arquitetura é baseada no modelo de nuvem infraestrutura como serviço (IaaS). Você provisiona os recursos de infraestrutura necessários (computação, rede e armazenamento) no Google Cloud. Você mantém controle total sobre a infraestrutura e é responsável pelo sistema operacional, middleware e camadas superiores da pilha de aplicativos. Para saber mais sobre IaaS e outros modelos de nuvem, consulte PaaS x IaaS x SaaS x CaaS: qual é a diferença entre eles?

O diagrama anterior inclui os seguintes componentes:

Componente Finalidade
Balanceador de carga externo regional

O balanceador de carga externo regional recebe e distribui as solicitações de usuários para as VMs no nível da Web.

Use um tipo de balanceador de carga apropriado, dependendo do tipo de tráfego e de outros requisitos. Por exemplo, se o back-end consistir em servidores da Web (como mostrado na arquitetura anterior), use um balanceador de carga de aplicativo para encaminhar o tráfego HTTP(S). Use um balanceador de carga de rede para balancear a carga do tráfego TCP. Para mais informações, consulte Escolher um balanceador de carga.

Grupo gerenciado de instâncias (MIG) zonal 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 zonal. O MIG é o back-end do balanceador de carga externo regional. Cada VM no MIG hospeda uma instância independente do nível da Web do aplicativo.
Balanceador de carga interno regional

O balanceador de carga interno regional distribui o tráfego das VMs no nível da Web para as VMs no nível do aplicativo.

Dependendo dos seus requisitos, é possível usar um balanceador de carga de aplicativo interno regional ou um balanceador de carga de rede. Para mais informações, consulte Escolher um balanceador de carga.

MIG zonal para o nível do aplicativo O nível do aplicativo é implantado nas VMs do Compute Engine que fazem parte de um MIG zonal, que é o back-end do balanceador de carga interno. Cada VM no MIG hospeda uma instância independente do nível do aplicativo.
Banco de dados de terceiros implantado em uma VM do Compute Engine

A arquitetura neste documento mostra um banco de dados de terceiros (como o PostgreSQL) implantado em uma VM do Compute Engine. É possível implantar um banco de dados em espera em outra zona. Os recursos de replicação e failover dependem do banco de dados que você usa.

A instalação e o gerenciamento de um banco de dados de terceiros envolve mais esforço e custos operacionais para aplicar atualizações, monitorar e garantir a disponibilidade. É possível evitar o overhead de instalar e gerenciar um banco de dados de terceiros e aproveitar os recursos integrados de alta disponibilidade (HA) usando um serviço de banco de dados totalmente gerenciado, como o Cloud SQL ou o AlloyDB para PostgreSQL. Para mais informações sobre opções de bancos de dados gerenciados, consulte Serviços de banco de dados.

Rede de nuvem privada virtual e sub-rede

Todos os recursos do Google Cloud na arquitetura usam uma única rede VPC e sub-rede.

Dependendo dos seus requisitos, é possível criar uma arquitetura que use várias redes VPC ou várias sub-redes. Para mais informações, consulte Como decidir quando criar várias redes VPC em "Práticas recomendadas e arquiteturas de referência para desenvolver a VPC".

Bucket regional do Cloud Storage

Os backups de aplicativos e bancos de dados são armazenados em um bucket regional do Cloud Storage. Se ocorrer uma interrupção do serviço zonal, seu aplicativo e os dados não serão perdidos.

Como alternativa, é possível usar o Serviço de backup e DR para criar, armazenar e gerenciar os backups do banco de dados.

Produtos usados

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

  • Compute Engine: um serviço de computação seguro e personalizável que permite criar e executar VMs na infraestrutura do Google.
  • Cloud Load Balancing: um portfólio de balanceadores de carga globais, regionais, escalonáveis, globais e de alto desempenho.
  • Cloud Storage: um armazenamento de objetos de baixo custo e sem limite para diversos tipos de dados. Os dados podem ser acessados de dentro e fora do Google Cloud e são replicados entre locais para redundância.
  • Nuvem privada virtual: um sistema virtual que oferece funcionalidade de rede global e escalonável para suas cargas de trabalho do Google Cloud.

Casos de uso

Nesta seção, descrevemos casos de uso em que uma implantação de zona única no Compute Engine é uma escolha apropriada.

  • Desenvolvimento e teste de nuvem: use uma arquitetura de implantação de zona única para criar um ambiente de nuvem de baixo custo para desenvolvimento e teste.
  • Aplicativos que não precisam de alta disponibilidade: uma arquitetura de zona única pode ser suficiente para aplicativos que conseguem tolerar a inatividade devido a interrupções do serviço da infraestrutura.
  • Rede de baixa latência e baixo custo entre componentes de aplicativo: uma arquitetura de zona única pode ser adequada para aplicativos como computação em lote que precisam de conexões de rede de baixa latência e alta largura de banda entre os nós de computação. Com uma implantação de zona única, não há tráfego de rede entre zonas e não há custos para o tráfego intrazona.
  • Migração de cargas de trabalho comuns: a arquitetura de implantação zonal fornece um caminho simples de migração na nuvem para aplicativos locais comuns para os quais você não tem controle sobre o código ou que não oferecem suporte a arquiteturas além de uma topologia ativa-passiva básica.
  • Executar software com restrição de licença: uma arquitetura de zona única pode ser adequada para sistemas com restrição de licença em que a execução de mais de uma instância por vez é muito cara ou não é permitida.

Considerações sobre o design

Nesta seção, você encontra orientações sobre como usar essa arquitetura de referência para desenvolver uma arquitetura que atenda aos requisitos específicos de projeto, segurança e conformidade, confiabilidade, eficiência operacional, custo e desempenho do sistema.

.

Design do sistema

Nesta seção, fornecemos orientações para ajudar você a escolher regiões e zonas do Google Cloud para sua implantação zonal e selecionar os serviços apropriados do Google Cloud.

Seleção da região

Ao escolher uma região e uma zona do Google Cloud para seus aplicativos, considere os seguintes fatores e requisitos:

  • Disponibilidade dos serviços do Google Cloud. Para mais informações, consulte Produtos disponíveis por local.
  • Disponibilidade de tipos de máquina do Compute Engine. Para mais informações, consulte Regiões e zonas.
  • Requisitos de latência do usuário final.
  • Custo dos recursos do 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. Para mais informações, consulte Selecionar zonas e regiões geográficas no Framework de arquitetura do Google Cloud.

Serviços do Compute

A arquitetura de referência neste documento usa VMs do Compute Engine para todos os níveis do aplicativo. As orientações de design neste documento são específicas do Compute Engine, salvo indicação em contrário.

Dependendo dos requisitos do aplicativo, é possível escolher um dos outros serviços de computação do Google Cloud a seguir. As orientações de design para esses serviços estão fora do escopo deste documento.

  • É 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.
  • Se você preferir concentrar as iniciativas de TI nos dados e aplicativos em vez de configurar e operar recursos de infraestrutura, use serviços sem servidor, como o Cloud Run e o Cloud Functions.

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

Serviços de armazenamento

A arquitetura mostrada neste documento usa volumes zonais do Persistent Disk para todos os níveis. Para um armazenamento permanente mais durável, use volumes regionais do Persistent Disk, que oferecem replicação síncrona de dados em duas zonas de uma região.

Para ter um 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 em todas as VMs no nível da Web ou do aplicativo, use o Filestore. Os dados que você armazena em uma instância do Filestore Enterprise 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.

Se o banco de dados for o Microsoft SQL Server, recomendamos o uso do Cloud SQL para SQL Server. Nos cenários em que o Cloud SQL não for compatível com os requisitos de configuração ou se você precisar de acesso ao sistema operacional, implante uma instância de cluster de failover (FCI, na sigla em inglês). , Nesse cenário, é possível usar o Google Cloud NetApp Volumes para fornecer armazenamento SMB de disponibilidade contínua (CA) para o banco de dados.

Ao projetar o armazenamento para suas cargas de trabalho, considere as características funcionais, os requisitos de resiliência, as expectativas de desempenho e as metas de custo. Para mais informações, consulte Criar uma estratégia de armazenamento ideal para sua carga de trabalho na nuvem.

Serviços de banco de dados

A arquitetura de referência neste documento usa um banco de dados de terceiros, como o PostgreSQL, que é implantado em VMs do Compute Engine. A instalação e o gerenciamento de um banco de dados de terceiros envolve esforço e custo para operações como aplicação de atualizações, monitoramento e garantia de disponibilidade, realização de backups e recuperação de falhas.

Para evitar o esforço e o custo de instalação e gerenciamento de um banco de dados de terceiros, use um serviço de banco de dados totalmente gerenciado, como Cloud SQL, AlloyDB para PostgreSQL, Cloud Bigtable, Spanner ou Firestore. Esses serviços de banco de dados do Google Cloud fornecem contratos de nível de serviço (SLAs) de tempo de atividade e incluem recursos padrão para escalonabilidade e observabilidade. Se as cargas de trabalho exigirem um banco de dados Oracle, use a Solução Bare Metal fornecida pelo Google Cloud. Para uma visão geral dos casos de uso para os quais cada serviço de banco de dados do Google Cloud é adequado, consulte Bancos de dados do Google Cloud.

Segurança e compliance

Nesta seção, descrevemos os fatores que você precisa considerar ao usar essa arquitetura de referência para projetar e criar uma topologia zonal no Google Cloud que atenda aos requisitos de segurança e conformidade das suas cargas de trabalho.

Proteção contra ameaças externas

Para proteger o aplicativo contra ameaças como ataques distribuídos de negação de serviço (DDoS) e scripting em vários sites (XSS), use as políticas de segurança do Google Cloud Armor. As políticas de segurança são aplicadas no perímetro, ou seja, antes que o tráfego atinja o nível da Web. Cada política é um conjunto de regras que especifica determinadas condições que precisam ser avaliadas e ações a serem tomadas quando as condições são atendidas. Por exemplo, uma regra pode especificar que, se o endereço IP de origem do tráfego de entrada corresponder a um endereço IP ou intervalo CIDR específico, o tráfego precisará ser negado. Além disso, é possível aplicar regras de firewall de aplicativos da Web (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 do aplicativo, o nível da Web e os bancos de dados não precisam de acesso de entrada da Internet. Não atribua endereços IP externos a essas VMs. Os recursos do Google Cloud que têm apenas um endereço IP interno particular ainda podem acessar determinadas APIs e serviços do Google usando o Private Service Connect ou o Acesso privado do Google. Para mais informações, consulte Opções de acesso privado para serviços.

Para ativar conexões de saída seguras de recursos do Google Cloud que têm apenas endereços IP privados, como as VMs do Compute Engine nesta arquitetura de referência, use o Cloud NAT.

Segurança de imagens de VM

Para garantir que suas VMs usem apenas imagens aprovadas (ou seja, imagens com software que atenda aos requisitos de política ou segurança), 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. A 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 aplicativo. 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 em "Práticas recomendadas para usar contas de serviço".

Segurança de rede

Para controlar o tráfego de rede entre os recursos na arquitetura, é preciso configurar as regras do Cloud de última geração apropriadas. Cada regra de firewall permite controlar o tráfego com base em parâmetros como protocolo, endereço IP e porta. Por exemplo, é possível configurar uma regra de firewall para permitir o tráfego TCP das VMs do servidor da Web para uma porta específica das VMs do banco de dados e bloquear todos os outros tráfegos.

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

Nesta seção, descrevemos os fatores de desenvolvimento que você precisa considerar ao usar essa arquitetura de referência para criar e operar uma infraestrutura confiável para implantações zonais no Google Cloud.

Falhas na infraestrutura

Em uma arquitetura de implantação de zona única, se algum componente da pilha de infraestrutura falhar, o aplicativo poderá processar solicitações se cada nível tiver pelo menos um componente em funcionamento com capacidade adequada. Por exemplo, se uma instância do servidor da Web falhar, o balanceador de carga encaminhará as solicitações do usuário para as outras instâncias disponíveis do servidor. Quando uma VM que hospeda um servidor da Web ou uma instância do servidor de apps falha, o MIG recria a VM automaticamente. Se o banco de dados falhar, você precisará ativar manualmente o segundo banco de dados e atualizar as instâncias do servidor de apps para se conectar ao banco de dados.

Uma interrupção do serviço na zona ou região afeta todas as VMs do Compute Engine em uma implantação de zona única. Uma interrupção do serviço na zona não afeta o balanceador de carga nessa arquitetura porque é um recurso regional. No entanto, o balanceador de carga não pode distribuir o tráfego porque não há back-ends disponíveis. Se ocorrer uma interrupção do serviço na zona ou região, você precisará aguardar o Google resolver essa interrupção e verificar se o aplicativo funciona conforme o esperado.

É possível reduzir a inatividade causada por interrupções do serviço na zona ou região mantendo uma réplica passiva (failover) da pilha de infraestrutura em outra zona ou região do Google Cloud. Se ocorrer uma interrupção do serviço na zona principal, ative a pilha na zona ou região de failover e use políticas de roteamento de DNS para rotear o tráfego ao balanceador de carga na zona ou região de failover.

Para aplicativos que exigem robustez em relação a interrupções do serviço na zona ou região, considere o uso de uma arquitetura regional ou multirregional. Consulte as arquiteturas de referência a seguir:

Escalonamento automático de MIG

O recurso 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.

Limite de tamanho do MIG

Por padrão, um MIG zonal pode ter até 1.000 VMs. É possível aumentar o limite de tamanho de um MIG para 2.000 VMs.

Recuperação automática de VM

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

Posicionamento da VM

Na arquitetura descrita neste documento, os níveis do aplicativo e da Web são executados nas VMs do Compute Engine em uma única zona. Para melhorar a robustez da arquitetura, crie uma política de posicionamento distribuído e aplique-a ao modelo do MIG. Quando o MIG cria VMs, ele as coloca em diferentes servidores físicos (chamados de hosts), de modo que as VMs sejam resistentes contra falhas de hosts individuais. Para mais informações, consulte Aplicar políticas de posicionamento distribuído às VMs.

Planejamento de capacidade de VM

Para garantir que a capacidade de VMs do Compute Engine esteja disponível quando 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ê 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.

Estado do disco permanente

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

Durabilidade dos dados

É possível usar backup e DR para criar, armazenar e gerenciar backups das VMs do Compute Engine. O backup e a DR armazenam 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.

Se você usa um serviço de banco de dados gerenciado, como o Cloud SQL, os backups são feitos automaticamente com base na política de retenção definida. É possível complementar a estratégia de backup com backups lógicos extras para atender aos requisitos regulatórios, de fluxo de trabalho ou de negócios.

Se você usa um banco de dados de terceiros e precisa armazenar backups de banco de dados e registros de transações, é possível usar buckets regionais do Cloud Storage. Os buckets regionais do Cloud Storage fornecem armazenamento de backup de baixo custo que é redundante entre zonas.

O Compute Engine oferece as opções a seguir para ajudar a garantir a durabilidade dos dados armazenados nos volumes do Persistent Disk:

  • É possível usar snapshots para capturar o estado pontual dos volumes do Persistent Disk. Os snapshots são armazenados de maneira redundante em várias regiões, com somas de verificação automáticas para garantir a integridade dos dados. Por padrão, os snapshots são incrementais e usam menos espaço de armazenamento, e você economiza dinheiro. Os snapshots são armazenados em um local do Cloud Storage configurável. Para mais recomendações sobre como usar e gerenciar snapshots, consulte Práticas recomendadas para snapshots de disco do Compute Engine.
  • Os volumes regionais do Persistent Disk permitem executar aplicativos altamente disponíveis que não são afetados por falhas em discos permanentes. Quando você cria um volume regional do Persistent Disk, o Compute Engine mantém uma réplica do disco em uma zona diferente na mesma região. Os dados são replicados de maneira síncrona para os discos nas duas zonas. Se alguma das duas zonas tiver uma interrupção, os dados permanecerão disponíveis.

Disponibilidade do banco de dados

Se você usa um serviço de banco de dados gerenciado como o Cloud SQL na configuração de alta disponibilidade, em caso de falha do banco de dados primário, o Cloud SQL faz o failover automaticamente para o modo de espera de arquivos. Não é preciso alterar o endereço IP do endpoint do banco de dados. Se você usa um banco de dados de terceiros autogerenciado implantado em uma VM do Compute Engine, use um balanceador de carga interno ou outro mecanismo para garantir que o aplicativo possa se conectar a outro banco de dados. o banco de dados primário não estiver disponível.

Para implementar o failover entre zonas para um banco de dados implantado em uma VM do Compute Engine, é necessário ter um mecanismo para identificar falhas do banco de dados principal e um processo para fazer failover no banco de dados em espera. As especificidades do mecanismo de failover dependem do banco de dados que você usa. É possível configurar uma instância do observador para detectar falhas do banco de dados primário e orquestrar o failover. Você precisa configurar as regras de failover corretamente para evitar uma situação de dupla personalidade e evitar o failover desnecessário. Para ver exemplos de arquiteturas que podem ser usadas para implementar o failover para bancos de dados do PostgreSQL, consulte Arquiteturas para alta disponibilidade de clusters do PostgreSQL no Compute Engine.

Mais considerações sobre confiabilidade

Ao criar a arquitetura de nuvem para sua carga de trabalho, analise as práticas recomendadas e as recomendações relacionadas à confiabilidade fornecidas na documentação a seguir:

Otimização de custos

Nesta seção, você encontra orientações para otimizar o custo de configuração e operação de uma topologia zonal do Google Cloud criada usando essa arquitetura de referência.

Tipos de máquina de VM

Para ajudar você a otimizar a utilização de recursos das instâncias de VM, o Compute Engine fornece recomendações de tipo de máquina. Use as recomendações para escolher os tipos de máquina que atendem aos requisitos de computação da carga de trabalho. Para cargas de trabalho com requisitos de recursos previsíveis, é possível personalizar o tipo de máquina de acordo com suas necessidades e economizar dinheiro usando tipos de máquinas personalizados.

Modelo de provisionamento de VM

Se o aplicativo for tolerante a falhas, as VMs spot podem ajudar a reduzir os custos do Compute Engine para as VMs nos níveis do aplicativo e da Web. O custo das VMs spot é significativamente menor do que as VMs regulares. No entanto, o Compute Engine pode interromper ou excluir antecipadamente as VMs spot para recuperar a capacidade. As VMs spot são adequadas para jobs em lote que toleram a preempção e não têm requisitos de alta disponibilidade. As VMs spot oferecem os mesmos tipos de máquina, opções e desempenho que as VMs regulares. No entanto, quando a capacidade de recursos em uma zona é limitada, os MIGs podem não conseguir fazer o escalonamento horizontal (ou seja, criar VMs) automaticamente para o tamanho de destino especificado até que a capacidade necessária fique disponível novamente.

Uso dos recursos

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

Licenciamento de terceiros

Ao migrar cargas de trabalho de terceiros para o Google Cloud, você pode reduzir os custos trazendo suas próprias licenças (BYOL, na sigla em inglês). Por exemplo, para implantar VMs do Microsoft Windows Server, em vez de usar uma imagem Premium que gera mais custos com a licença de terceiros, é possível criar e usar uma imagem personalizada BYOL do Windows. Você paga apenas pela infraestrutura de VM usada no Google Cloud. Essa estratégia ajuda você a manter o valor dos seus investimentos em licenças de terceiros. Se você decidir usar a abordagem BYOL, recomendamos o seguinte:

Se você implantar um banco de dados de terceiros, como o Microsoft SQL Server, em VMs do Compute Engine, considere os custos da licença do software de terceiros. Quando você usa um serviço de banco de dados gerenciado, como o Cloud SQL, os custos da licença de banco de dados são incluídos nas cobranças do serviço.

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 Framework de arquitetura do Google Cloud: otimização de custos.

Eficiência operacional

Nesta seção, descrevemos os fatores que você precisa considerar ao usar essa arquitetura de referência para projetar e criar uma topologia zonal do Google Cloud para operar de maneira eficiente.

Atualizações de configuração da VM

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

Imagens 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 personalizadas que contenham 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 indica a imagem mais recente que ela contém, permitindo que seus modelos e scripts de instâncias usem essa imagem sem precisar atualizar as referências para uma versão específica de imagem.

Modelos deterministas de instância

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

Mais considerações operacionais

Ao criar a arquitetura para a carga de trabalho, considere as práticas recomendadas gerais para eficiência operacional descritas em Framework de arquitetura do Google Cloud: excelência operacional.

Otimização de desempenho

Nesta seção, descrevemos os fatores que você precisa considerar ao usar essa arquitetura de referência para projetar e criar uma topologia zonal no Google Cloud que atenda aos requisitos de desempenho das suas cargas de trabalho.

Posicionamento da VM

Para cargas de trabalho que exigem baixa latência de rede entre VMs, crie uma política de posicionamento compacto e aplique-a ao modelo do MIG. Quando o MIG cria VMs, ele as coloca em servidores físicos próximos uns dos outros. Para mais informações, consulte Reduzir a latência usando políticas de posicionamento compactas.

Tipos de máquina de VM

O Compute Engine oferece uma ampla variedade de tipos de máquinas predefinidos e personalizáveis que podem ser escolhidos de acordo com seus requisitos de custo e desempenho. Os tipos de máquina são agrupados em séries e famílias. A tabela a seguir fornece um resumo das famílias e séries de máquinas recomendadas para diferentes tipos de carga de trabalho:

Requisito Família de máquinas recomendada Exemplo de série de máquinas
Melhor custo-benefício para diversas cargas de trabalho Família de máquinas de uso geral C3, C3D, E2, N2, N2D, Tau T2D, Tau T2A
Maior desempenho por núcleo e otimizado para cargas de trabalho de computação intensiva Família de máquinas com otimização para computação C2, C2D, H3
Proporção alta de memória para vCPU para cargas de trabalho com uso intensivo de memória Família de máquinas com otimização de memória M3, M2, M1
GPUs para cargas de trabalho em paralelo Família de máquinas com otimização de acelerador A2, G2

Para mais informações, consulte o Guia de comparação e recursos para famílias de máquinas.

Várias linhas de execução de VM

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

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

Níveis de serviço de rede

Os Níveis de serviço de rede permitem otimizar o custo de rede e o desempenho das suas cargas de trabalho. É possível escolher o nível Premium ou Standard.

  • O nível Premium usa o backbone global altamente confiável do Google para ajudar você a conseguir latência e perda de pacotes mínimas. O tráfego entra e sai da rede do Google em um ponto de presença (PoP, na sigla em inglês) de borda global próximo do usuário final. Recomendamos o uso do nível Premium como padrão para um desempenho ideal.
  • Com o nível Standard, o tráfego entra e sai da rede do Google em um PoP de borda mais próximo do local do Google Cloud em que sua carga de trabalho é executada. O preço do nível Standard é menor que o do nível Premium. O nível Standard é adequado para tráfego que não é sensível à perda de pacotes e que não tem requisitos de baixa latência.

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

A seguir

Colaboradores

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

Outros colaboradores: