Escolher uma estratégia de implantação do Compute Engine para sua carga de trabalho
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Como arquiteto de nuvem ou administrador de TI, quando você planeja executar um aplicativo no
Compute Engine, precisa projetar uma topologia de VM que possa ser provisionada e
executada com eficiência.
O Compute Engine oferece várias opções de implantação: por exemplo, é possível
implantar um grupo de VMs gerenciadas como uma única entidade ou provisionar
e gerenciar as VMs como recursos individuais. Cada abordagem tem méritos e limitações
distintos. Como escolher a melhor estratégia de implantação?
Comece avaliando os principais requisitos da sua inscrição.
Analise as opções de implantação disponíveis e os benefícios relativos.
Selecione uma estratégia que atenda aos seus requisitos e que faça uso ideal dos
recursos do Compute Engine.
Avaliar a carga de trabalho
Use as perguntas a seguir para analisar os principais requisitos da
carga de trabalho que você quer implantar. Suas respostas ajudarão a mapear os
recursos de cada opção de implantação (listada na próxima seção) para os
requisitos da carga de trabalho.
Estado do aplicativo
O aplicativo é com estado?
Um aplicativo com estado armazena determinados dados, como o ID do cliente ou
da sessão, até que esses dados não sejam mais necessários. Por exemplo, em
um app de compras on-line, o serviço de carrinho de compras pode armazenar
detalhes de itens adicionados ou removidos à medida que o usuário continua
a fazer compras, e mantém o estado final do carrinho quando o usuário inicia
o processo de finalização da compra.
Um aplicativo sem estado não precisa armazenar
dados de cliente, transação ou sessão. Por exemplo, um servidor da Web
pode fechar uma sessão após exibir o conteúdo solicitado pelo
cliente.
Os metadados específicos da instância precisam ser preservados quando as VMs são reinicializadas
ou quando o Compute Engine recria (automática) as VMs?
Aprovisionamento
As VMs precisam usar uma combinação de tipos de máquina ou imagens? Por exemplo,
algumas VMs precisam de tipos de máquina com otimização de memória, enquanto outras usam
tipos de máquina de uso geral?
A infraestrutura deve ser escalonada automaticamente em sintonia com as alterações na
carga para manter o equilíbrio ideal entre custo e tempo
de resposta?
Todas as VMs podem ser executadas em uma única zona, rede VPC e sub-rede?
O aplicativo precisa ser executado na mesma zona que alguns outros recursos?
Por exemplo, o aplicativo requer uma conexão de baixa latência com
um banco de dados?
Operações
Você quer gerenciar as VMs como um único grupo? Por exemplo, você
quer automatizar o lançamento das atualizações do aplicativo em todas as VMs?
Você precisa usar uma ferramenta personalizada ou de terceiros para gerenciar as VMs?
Você precisa de controle sobre o tratamento de VMs com falha? Por exemplo, se uma VM
falhar, você quer que ela permaneça interrompida enquanto determina a causa
raiz da falha?
Você precisa de controle sobre a sequência iniciar-interromper-suspender-retomar ou
a programação das VMs? Por exemplo, para economizar custos, você planeja parar as
VMs durante os fins de semana ou em determinadas horas do dia?
Resiliência
O aplicativo precisa de proteção contra falhas nas zonas? Em outras
palavras, se uma zona estiver inativa, você gostaria que o aplicativo continuasse
atendendo solicitações de VMs em outras zonas da região?
Se uma VM for interrompida ou falhar por algum motivo ou se o aplicativo não
responder às solicitações, o Compute Engine deverá recriar a VM
automaticamente?
O aplicativo precisa de endereços IP internos ou externos fixos para
as VMs do host?
Agora que você avaliou seus requisitos, saiba mais sobre as opções
de implantação que o Compute Engine oferece.
Analisar as opções de implantação disponíveis
Analise e entenda os recursos e as vantagens relativas das
opções a serem consideradas para implantar cargas de trabalho no
Compute Engine.
VMs independentes
Com essa opção, você escolhe o tipo de máquina, a imagem, os discos e outros
atributos individualmente para cada VM provisionada. E você gerencia as VMs
como recursos separados.
Grupo de instâncias não gerenciadas
É possível provisionar VMs independentes e adicioná-las a um grupo de instâncias. Depois,
use o grupo de instâncias não gerenciadas como back-end para um balanceador de carga.
Grupo gerenciado de instâncias (MIG)
Um grupo gerenciado de instâncias (MIG, na sigla em inglês) é um grupo de instâncias idênticas ou configuradas de maneira semelhante
provisionado a partir de um modelo de instância.
É possível tornar um MIG com estado para que discos ou metadados específicos sejam
preservados.
Para um MIG sem estado, é possível ativar o escalonamento automático e configurar uma política de
escalonamento.
Ao criar um MIG, é possível optar por implantar as VMs em uma única zona
ou distribuí-las em mais de uma zona em uma região para alta
disponibilidade.
A tabela a seguir resume os principais recursos de cada opção de implantação.
Os diagramas a seguir mostram implantações de amostra lado a lado para ajudar a
entender as principais diferenças.
VMs independentes
MIG com estado
MIG sem estado
Este exemplo mostra três VMs criadas individualmente.
Este exemplo mostra um MIG que contém três VMs configuradas de forma semelhante,
provisionadas usando um modelo de instância.
Neste exemplo, mostramos um MIG que contém três VMs idênticas, provisionadas
usando um modelo de instância.
Cada VM neste exemplo usa um tipo de máquina, imagem, discos
e outros atributos distintos.
As VMs foram adicionadas individualmente a um grupo de instâncias não gerenciadas.
As VMs neste exemplo usam um tipo de máquina e uma imagem definidos em um
modelo de instância.
Uma política com estado garante que os discos de inicialização anexados a todas as
VMs tenham estado.
As configurações por instância adicionam os discos de dados com estado necessários.
Neste exemplo, as VMs herdam o tipo de máquina e a imagem
de um modelo de instância.
Os discos são recriados quando a VM é atualizada ou recriada.
O MIG cria e exclui VMs automaticamente com base em uma
configuração de escalonamento automático.
Você avaliou sua carga de trabalho, analisou as opções de implantação que o
Compute Engine oferece e está pronto para escolher uma abordagem de implantação.
Selecionar uma estratégia de implantação
As recomendações discutidas aqui são baseadas em um mapeamento de características de carga de trabalho específicas
para os recursos de cada opção de implantação do
Compute Engine.
Use o fluxo de tomada de decisão a seguir. Se preferir um guia visual, consulte a
árvore de decisão mais adiante neste documento.
Escolha entre VMs independentes e grupos de instâncias.
Requisitos
Estratégia de implantação recomendada
Pelo menos um dos seguintes requisitos é essencial para sua
carga de trabalho.
O aplicativo precisa ser executado em VMs que usam uma combinação de tipos de máquina ou
imagens.
O aplicativo precisa de endereços IP internos ou externos fixos para
as VMs do host.
É necessário tratar as VMs com falha.
É necessário ter controle sobre as operações de iniciar-interromper ou suspender-retomar
as VMs.
É necessário usar um script personalizado ou uma ferramenta de terceiros para provisionar
e remover VMs.
Escolha VMs independentes.
Se todas as VMs independentes puderem ser executadas em uma única zona, rede VPC e
sub-rede, adicione as VMs a um grupo de instâncias não gerenciadas. Em seguida,
use o grupo de instâncias não gerenciadas como back-end para um balanceador de
carga.
Pule o restante deste fluxo de tomada de decisão.
Nenhum dos requisitos acima é essencial para seu caso de uso.
Use um MIG para configurar uma topologia do Compute Engine fácil de
gerenciar, altamente disponível e escalonável.
Prossiga para a próxima etapa.
Escolha entre um MIG com estado e sem estado.
Requisitos
Tipo de MIG recomendado
O aplicativo requer preservação de disco e metadados, ou seja, o
aplicativo tem estado.
Escolha um MIG com estado e configure os discos que o
Compute Engine precisa preservar durante eventos de interrupção, como recriação,
recuperação automática e atualizações de VM.
Prossiga para a próxima etapa.
O aplicativo não tem estado.
Escolha um MIG sem estado e aproveite o recurso de
escalonamento automático. Durante as operações de interrupção, o Compute Engine
recria os discos de acordo com o modelo de instância.
Prossiga para a próxima etapa.
Escolha entre um MIG zonal ou regional.
Requisitos
Tipo de MIG recomendado
O aplicativo precisa ser executado em uma única zona, ou a proteção contra
falhas zonais não é essencial.
Escolha um MIG zonal.
O aplicativo precisa continuar em execução mesmo quando ocorrer uma falha na zona.
Escolha um MIG regional.
Árvore de decisão
O diagrama a seguir guiará você pelos fatores a serem considerados ao decidir
sua estratégia de implantação do Compute Engine:
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-19 UTC."],[[["\u003cp\u003eCompute Engine offers various VM deployment options, including standalone VMs, unmanaged instance groups, and managed instance groups (MIGs), each with unique advantages and limitations.\u003c/p\u003e\n"],["\u003cp\u003eChoosing the optimal deployment strategy involves assessing your application's key requirements, such as whether it is stateful or stateless, needs specific provisioning, requires certain operations control, and has resilience needs.\u003c/p\u003e\n"],["\u003cp\u003eStandalone VMs are recommended if your application requires a mix of machine types or images, fixed IP addresses, or custom VM management, while MIGs are preferable for easier management, high availability, and scalability.\u003c/p\u003e\n"],["\u003cp\u003eStateful MIGs should be chosen for applications that need disk and metadata preservation, whereas stateless MIGs are suitable for applications where disks can be recreated during disruptive operations.\u003c/p\u003e\n"],["\u003cp\u003eSelecting between a zonal and regional MIG depends on whether the application can run in a single zone or if it needs protection against zonal failures by distributing VMs across multiple zones in a region.\u003c/p\u003e\n"]]],[],null,["# Choose a Compute Engine deployment strategy for your workload\n\n*** ** * ** ***\n\nAs a cloud architect or IT administrator, when you plan to run an application in\nCompute Engine, you need to design a VM topology that you can provision and\noperate efficiently.\n\nCompute Engine offers a range of deployment options: for example, you could\ndeploy a group of VMs that you manage as a single entity, or you could provision\nand manage the VMs as individual resources. Each approach has distinct merits\nand limitations. How do you choose an optimal deployment strategy?\n\n1. Start by assessing the key requirements of your application.\n2. Review the available deployment options and their relative merits.\n3. Select a strategy that meets your requirements and makes optimal use of the capabilities of Compute Engine.\n\n| **Note:** Compute Engine provides robust and flexible cloud infrastructure for hosting commercial off-the-shelf applications and for migrating workloads from your on-premises data centers. To learn about the hosting options in Google Cloud for other use cases, such as deploying serverless functions and running containerized applications in a Kubernetes cluster, see [App Hosting on Google Cloud](https://cloud.google.com/blog/topics/developers-practitioners/where-should-i-run-my-stuff-choosing-google-cloud-compute-option).\n\nAssess your workload\n--------------------\n\nUse the following questions to analyze the key requirements of the\nworkload that you want to deploy. Your answers will help you map the\ncapabilities of each deployment option (listed in the next section) to the\nrequirements of your workload.\n| **Important**: When migrating an on-premises workload to the cloud, consider any special requirements for the cloud version of the application. For example, the on-premises deployment might run in a single data center, whereas you might need the cloud topology to span more than one Google Cloud zone for higher availability.\n\n- **Application state**\n\n - Is the application stateful?\n\n - A *stateful* application stores certain data, such as the client or session ID, until that data is no longer necessary. For example, in an online shopping app, the shopping cart service might store details of items that are added or removed as the user continues shopping, and persist the final cart state when the user starts the check-out process.\n - A *stateless* application does not need to store any client, transaction, or session data. For example, a web server might close a session after serving the content that the client requested.\n\n To learn more about stateful and stateless applications, see\n [How stateful workloads are different from stateless workloads](/compute/docs/instance-groups/stateful-migs#how_stateful_workloads_are_different_from_stateless_workloads).\n - Should any instance-specific metadata be preserved when your VMs reboot\n or when Compute Engine recreates (autoheals) the VMs?\n\n- **Provisioning**\n\n - Should the VMs use a mix of machine types or images? For example, do some VMs need memory-optimized machine types while the others use general-purpose machine types?\n - Should the infrastructure scale automatically in tune with changes in load, so that you maintain an optimal balance between cost and response time?\n - Can all the VMs run within a single zone, VPC network, and subnet?\n - Should the application run in the same zone as certain other resources? For example, does the application require a low-latency connection with a database?\n- **Operations**\n\n - Do you want to manage the VMs as a single group? For example, would you like to automate rolling out application updates across all the VMs?\n - Do you need to use a custom or third-party tool to manage the VMs?\n - Do you need control over handling failed VMs? For example, if a VM fails, would you like it to remain stopped while you determine the root cause for the failure?\n - Do you need control over the start-stop-suspend-resume sequence or schedule of your VMs? For example, to save cost, do you plan to stop the VMs during weekends or for certain hours of the day?\n- **Resilience**\n\n - Does the application need protection against zonal failures? In other words, if a zone is down, would you like the application to continue serving requests from VMs in other zones in the region?\n - If a VM stops or crashes for any reason, or if the application doesn't respond to requests, should Compute Engine recreate the VM automatically?\n - Does the application need fixed internal or external IP addresses for the host VMs?\n\nNow that you've assessed your requirements, learn about the deployment options\nthat Compute Engine offers.\n\nReview the available deployment options\n---------------------------------------\n\nReview and understand the features and relative advantages of the\noptions that you can consider for deploying your workloads to\nCompute Engine.\n\n**Standalone VMs**\n: With this option, you choose the machine type, image, disks, and other\n attributes individually for each VM that you provision. And you manage the VMs\n as separate resources.\n\n**Unmanaged instance group**\n: You can provision standalone VMs and add them to an instance group. You can\n then use the unmanaged instance group as a backend to a load balancer.\n\n**Managed instance group (MIG)**\n\n: A MIG is a group of identical or similarly configured instances that you\n provision by using an [instance template](/compute/docs/instance-templates).\n\n - You can make a MIG *stateful*, so that specific disks or metadata are\n preserved.\n\n - For a *stateless* MIG, you can enable autoscaling and configure a scaling\n policy.\n\n - While creating a MIG, you can choose to deploy the VMs within a single zone,\n or distribute them across more than one zone in a region for high\n availability.\n\nThe following table summarizes the key features of each deployment option.\n\nThe following diagrams show sample deployments side-by-side to help you\nunderstand the key differences.\n\nYou've now assessed your workload, reviewed the deployment options that\nCompute Engine offers, and are ready to choose a deployment approach.\n\nSelect a deployment strategy\n----------------------------\n\nThe recommendations discussed here are based on a mapping of specific workload\ncharacteristics to the capabilities of each Compute Engine deployment\noption.\n\nUse the following decision-making flow. If you prefer a visual guide, see the\n[decision tree](#decision_tree) later in this document.\n\n1. Choose between standalone VMs and instance groups.\n\n2. Choose between a stateful and stateless MIG.\n\n3. Choose between a zonal and regional MIG.\n\n| **Important** : Do review and consider the [limitations](/compute/docs/instance-groups/creating-groups-of-managed-instances#limitations) of each MIG type.\n\n### Decision tree\n\nThe following diagram guides you through the factors to consider when deciding\nyour Compute Engine deployment strategy:\n\nWhat's next\n-----------\n\n- Learn more about [instance templates](/compute/docs/instance-templates).\n- Learn [how stateful MIGs work](/compute/docs/instance-groups/how-stateful-migs-work).\n- Learn more about [regional MIGs](/compute/docs/instance-groups/regional-migs).\n- [Create a MIG](/compute/docs/instance-groups/creating-groups-of-managed-instances).\n- [Autoscale groups of instances](/compute/docs/autoscaler).\n- [Migrate an existing workload to a stateful MIG](/compute/docs/tutorials/migrate-workload-to-stateful-mig)."]]
