Neste artigo, descrevemos as práticas recomendadas para criar em VMs (máquinas virtuais) de spot do Azure e incluímos um cenário de exemplo implantável. As VMs de spot fornecem acesso à capacidade de computação com descontos significativos para VMs regulares. Esse desconto as tornam uma solução atraente para organizações que buscam otimizar custos, mas a economia vem com uma condição. As VMs de spot podem perder o acesso à computação a qualquer momento. Chamamos esse processo de remoção. As cargas de trabalho em execução em VMs de spot devem ser capazes de lidar com essas interrupções na computação. A carga de trabalho certa e um mecanismo de orquestração flexível são as chaves para o sucesso. Veja a seguir as nossas recomendações para criar em VMs de spot.
Compreender as máquinas virtuais de spot
Em um nível técnico, as VMs de spot são as iguais às VMs regulares. Elas usam os mesmos discos, imagens e hardware que se convertem no mesmo desempenho. A diferença entre VMs de spot e regulares se resume à prioridade e à disponibilidade. As VMs de spot não têm prioridade para acessar a capacidade de computação e não têm garantias de disponibilidade depois de acessar essa capacidade de computação. Vamos discutir a prioridade e a disponibilidade em mais detalhes.
Sem acesso prioritário. As VMs regulares têm acesso prioritário à capacidade de computação. Elas acessam a capacidade de computação sempre que solicitam. As VMs de spot, por outro lado, só são implantadas quando há capacidade de computação sobressalente e só permanecem em execução quando uma VM regular não precisa do hardware subjacente.
Sem garantia de disponibilidade. As VMs de spot não têm garantias de disponibilidade. Elas não têm SLAs (contratos de nível de serviço). As VMs de spot podem perder o acesso à capacidade de computação imediatamente ou a qualquer momento após a implantação (remoção). As VMs de spot são mais baratas devido à possibilidade de remoção. Sempre que o Azure precisar da capacidade de computação de volta, um aviso de remoção será enviado e removerá a VM spot. O Azure fornece um aviso prévio mínimo de 30 segundos antes da remoção de fato. Para obter mais informações, confira a seção Monitorar continuamente a remoção, mais adiante neste artigo.
Compreender os preços das máquinas virtuais de spot
As VMs de spot podem ser até 90% mais baratas do que as VMs regulares (pagas conforme o uso). O desconto varia de acordo com a demanda, o tamanho da VM, a região de implantação e o sistema operacional. É recomendável usar a ferramenta de preços de VM spot do Azure para obter uma estimativa das economias de custo. Para saber mais, veja:
Você também pode consultar a API de preços de varejo do Azure para obter de maneira programática o preço de spot para qualquer SKU de interesse.
Compreender cargas de trabalho interruptíveis
As cargas de trabalho interruptíveis são o melhor caso de uso para VMs de spot. As cargas de trabalho interruptíveis têm algumas características comuns. Elas têm restrições de tempo mínimo a nenhum tempo, baixa prioridade organizacional e tempos curtos de processamento. Elas executam processos que podem parar repentinamente e retomar mais tarde sem prejudicar os processos essenciais da organização. Exemplos de cargas de trabalho interruptíveis são aplicativos de processamento em lote, análise de dados e cargas de trabalho que criam um agente de implantação contínua/integração contínua para um ambiente que não seja de produção. Esses recursos contrastam com cargas de trabalho regulares ou de missão crítica que têm SLAs (contratos de nível de serviço), sessões temporárias e dados com estado. A tabela fornece exemplos para ambos os tipos de carga de trabalho.
| Recursos de carga de trabalho interruptível | Recursos de carga de trabalho regular | |
|---|---|---|
| Recursos | Restrições de tempo mínimo a nenhum Baixa prioridade organizacional Tempos curtos de processamento |
SLAs (contratos de nível de serviço) Requisitos de sessões temporárias Cargas de trabalho com estado |
Você pode usar VM spot em cargas de trabalho não interruptíveis, mas elas não devem ser a única fonte de capacidade de computação. Use quantas VMs regulares você precisar para atender aos seus requisitos de tempo de atividade.
Compreender a remoção
As VMs de spot não têm SLAs (contratos de nível de serviço) depois de criadas e podem perder o acesso à computação a qualquer momento. Chamamos essa perda computacional de remoção. A oferta e a demanda de computação impulsionam a remoção. Quando a demanda por um tamanho de VM específico excede um determinado nível, o Azure remove VMs de spot para disponibilizar computação para VMs regulares. A demanda é específica do local. Um aumento na demanda na região A não afetará as VMs de spot na região B.
As VMs de spot têm duas opções de configuração que afetam a remoção. Essas configurações são o "tipo de remoção" e a "política de remoção" da VM spot. Você define essas configurações ao criar a VM spot. O "tipo de remoção" define as condições de uma remoção. A "política de remoção" determina o que a remoção faz com sua VM spot. Vamos abordar ambas as opções de configuração.
Tipo de remoção
A remoção é causada por mudanças de capacidade ou alterações no preço. A maneira como elas afetam as VMs de spot depende do tipo de remoção escolhido quando a VM foi criada. O tipo de remoção define as condições de uma remoção. Os tipos de remoção são "remoção apenas da capacidade" e "remoção de preço ou capacidade".
Remoção apenas da capacidade: esse tipo de remoção dispara uma remoção quando o a capacidade de computação em excesso desaparece. Por padrão, o preço é limitado à taxa de pagamento conforme o uso. Use esse tipo de remoção quando estiver disposto a pagar o preço da VM de pagamento conforme o uso.
Remoção de preço ou capacidade: esse tipo de remoção tem dois gatilhos. O Azure remove uma VM spot quando a capacidade de computação em excesso desaparece ou o custo da VM excede o preço máximo definido. Esse tipo de remoção permite que você defina um preço máximo bem abaixo do preço de pagamento conforme o uso. Use esse tipo de remoção para definir seu próprio limite de preço.
Política de remoção
A política de remoção escolhida para uma VM spot afeta sua orquestração. Por orquestração, entendemos o processo de lidar com uma remoção. Abordaremos a orquestração em detalhes posteriormente. As políticas de remoção são a "política Parar/Desalocar" e a "política Excluir".
Política Parar/Desalocar: a política de remoção Parar/Desalocar é melhor quando a carga de trabalho pode aguardar a liberação da capacidade no mesmo local e tipo de VM A política Parar/Desalocar interrompe a VM e encerra sua concessão com o hardware subjacente. Parar e desalocar uma VM spot é o mesmo que parar e desalocar uma VM regular. A VM permanece acessível no Azure e você pode reiniciar a mesma VM mais tarde. Com a política Parar/Desalocar, a VM perde capacidade de computação e endereços IP não estáticos. No entanto, os discos de dados da VM permanecem e ainda incorrem em encargos. A VM também ocupa núcleos na assinatura. As VMs não podem ser movidas de sua região ou zona, mesmo quando paradas/desalocadas. Para obter mais informações, confira Estados de energia e cobrança da VM.
Política Excluir: use a "política Excluir" se a carga de trabalho puder alterar o local ou o tamanho da VM. Alterar o local e/ou o tamanho da VM permite que a VM seja reimplantada mais rapidamente. A política Excluir exclui a VM e qualquer disco de dados. A VM não ocupa núcleos nas assinaturas. Para saber mais sobre políticas de remoção , confira política de remoção.
Design para orquestração flexível
A orquestração é o processo de substituição de uma VM spot após uma remoção. É a base da criação de uma carga de trabalho confiavelmente interruptível. Um bom sistema de orquestração tem flexibilidade interna. Por flexibilidade, queremos dizer projetar sua orquestração para ter opções, usar vários tamanhos de VM, implantar em diferentes regiões, ter reconhecimento de remoção e levar em conta diferentes cenários de remoção para melhorar a confiabilidade e a velocidade da carga de trabalho.
Abaixo, descrevemos recomendações que ajudam a projetar uma orquestração flexível para sua carga de trabalho interruptível.
Design para velocidade
Para uma carga de trabalho executada em VMs de spot, a capacidade de computação é essencial. O potencial iminente de remoção deve elevar sua apreciação pelo tempo de computação alocado e deve se traduzir em decisões de design significativas que priorizem a velocidade da carga de trabalho. Em geral, é recomendável otimizar o tempo de computação que você tem. Você deve criar uma imagem de VM com todo o software necessário pré-instalado. O software pré-instalado ajudará a minimizar o tempo entre a remoção e um aplicativo totalmente em execução. Você deseja evitar o uso do tempo de computação em processos que não contribuem para a finalidade da carga de trabalho. Uma carga de trabalho para análise de dados, por exemplo, deve concentrar a maior parte do tempo de computação no processamento de dados e o mínimo possível na coleta de metadados de remoção. Elimine processos secundários do seu aplicativo.
Usar vários tamanhos e locais de VM
É recomendável criar uma orquestração para usar vários tipos e tamanhos de VM a fim de aumentar a flexibilidade. O objetivo é dar opções de orquestração para substituir uma VM removida. O Azure tem diferentes tipos e tamanhos de VM que fornecem recursos semelhantes por aproximadamente o mesmo preço. Você deve filtrar VMs por mínimo de vCPUs/núcleos e/ou mínimo de RAM, bem como por preço máximo, a fim de encontrar várias VMs que tenham o poder de executar sua carga de trabalho e caber dentro do seu orçamento. Cada tipo de VM tem uma taxa de remoção expressa como um intervalo percentual (0-5%, 5-10%, 10-15%, 15-20%, +20%). As taxas de remoção podem variar entre as regiões. Você pode encontrar uma taxa de remoção melhor para o mesmo tipo de VM em uma região diferente. Você pode encontrar as taxas de remoção para cada tipo de VM na guia "Noções básicas" do portal. Selecione os links "Tamanho" ("Ver histórico de preços" ou "Ver todos os tamanhos"). Você também pode obter dados de VM spot de maneira programática usando o Azure Resource Graph. Para saber mais, veja:
Usar a política de remoção mais flexível
A política de remoção da VM spot removida afeta o processo de substituição. Uma política de remoção de exclusão é mais flexível do que uma política de remoção de parada/desalocação.
Considere a política de exclusão primeiro: é recomendável usar uma política de remoção de exclusão se sua carga de trabalho puder lidar com ela. A exclusão permite que a orquestração implante VMs de spot de substituição em novas zonas e regiões. Essa flexibilidade de implantação pode ajudar sua carga de trabalho a encontrar capacidade de computação sobressalente mais rapidamente do que uma VM parada/desalocada. As VMs paradas/desalocadas precisam aguardar a capacidade de computação sobressalente na mesma zona em que foram criadas. Para a política de exclusão, você precisará de um processo para monitorar remoções externas ao aplicativo e orquestrar implantações em regiões diferentes e/ou com SKUs de VM diferentes.
Compreenda a política de parada/desalocação: a política de parada/desalocação tem menos flexibilidade do que a política de exclusão. As VMs de spot devem permanecer na mesma região e zona. Não é possível mover uma VM parada/desalocada para outro local. Como as VMs têm um local fixo, você precisará de algo estabelecido para realocar a VM quando a capacidade de computação estiver disponível. Não há como prever quando a capacidade de computação estará disponível. Portanto, é recomendável o uso de um pipeline de agendamento automatizado para tentar uma reimplantação após uma remoção. Uma remoção deve disparar o pipeline de agendamento, e as tentativas de reimplantação devem verificar continuamente a capacidade de computação até que ela se torne disponível.
| Policy | Quando | |
|---|---|---|
| Excluir | Computação e dados efêmeros Não deseja pagar por discos de dados Orçamento mínimo |
|
| Parada/desalocação | Precisa de um tamanho de VM específico Impossibilidade de alterar o local Processo longo de instalação de aplicativos |
Tempo de espera indefinido Sem impulsão apenas pela redução de custos |
Monitorar continuamente a remoção
O monitoramento é a chave para a confiabilidade da carga de trabalho em VMs de spot. As VMs de spot não têm SLA após a criação e podem ser removidas a qualquer momento. A melhor maneira de melhorar a confiabilidade da carga de trabalho em VMs spot é prever quando elas serão removidas. Com essas informações, você pode tentar um desligamento normal da carga de trabalho e disparar a automação que orquestra a substituição.
Usar Eventos Agendados: é recomendável usar o serviço Eventos Agendados para cada VM. O Azure envia sinais para VMs de quando elas serão afetadas pela manutenção da infraestrutura. As remoções são qualificadas como manutenção da infraestrutura. O Azure envia o sinal Preempt para todas as VMs pelo menos 30 segundos antes da remoção. Um serviço chamado Eventos Agendados permite capturar esse sinal Preempt consultando um ponto de extremidade em um endereço IP 169.254.169.254 estático e não roteável.
Use consultas frequentes: é recomendável consultar o ponto de extremidade Eventos Agendados com frequência suficiente para orquestrar um desligamento normal. Você pode consultar o ponto de extremidade Eventos Agendados a cada segundo, mas a frequência de um segundo talvez não seja necessária para todos os casos de uso. Essas consultas devem ser originadas em um aplicativo executado na VM spot. A consulta não pode ter origem em uma fonte externa. Consequentemente, as consultas consumirão a capacidade de computação da VM e roubarão a capacidade de processamento da carga de trabalho principal. Você precisará equilibrar essas prioridades concorrentes para atender a essa situação específica.
Automatize a orquestração: depois de coletar o sinal Preempt, sua orquestração deve agir com base nele. Dadas as restrições de tempo, o sinal Preempt deve tentar um desligamento normal da carga de trabalho e iniciar um processo automatizado de substituição da VM spot. Para saber mais, veja:
Criar um sistema de implantação
Sua orquestração precisa de um pipeline automatizado para implantar novas VMs spot quando removidas. O pipeline deve ser executado fora da própria carga de trabalho interruptível para garantir a permanência. A maneira como o pipeline de implantação deve funcionar depende da política de remoção selecionada para suas VMs spot.
Para uma política de exclusão, é recomendável a criação de um pipeline que use tamanhos de VM diferentes e implante em regiões diferentes. Para uma política de parada/desalocação, o pipeline de implantação precisará de duas ações distintas. Para a criação inicial de uma VM, o pipeline precisa implantar as VMs do tamanho certo no local certo. Para uma VM removida, o pipeline precisa tentar reiniciar a VM até que ela funcione. Uma combinação de alertas do Azure Monitor e do Azure Functions é uma das várias maneiras de automatizar um sistema de implantação. O pipeline pode usar modelos bicep. Eles são declarativos e idempotentes, além de representarem uma prática recomendada para a implantação de infraestrutura.
Preparar-se para a remoção imediata
É possível que sua VM spot seja designada para remoção assim que for criada e antes mesmo que sua carga de trabalho seja executada. Não é porque houve a capacidade de se criar uma VM spot, que ela persistirá. As VMs spot não têm garantias de disponibilidade (SLAs) após a criação. Sua orquestração precisa levar em conta as remoções imediatas. O sinal Preempt ainda fornecerá um aviso no mínimo 30 segundos antes da remoção.
É recomendável incorporar verificações de integridade da VM em sua orquestração para se preparar para remoções imediatas. A orquestração para remoções imediatas não pode depender do sinal Preempt de Eventos Agendados. Somente a própria VM pode consultar o sinal Preempt, e não há tempo suficiente para iniciar um aplicativo, consultar o ponto de extremidade Eventos Agendados e fazer um desligamento normal. Portanto, a verificação de integridade precisa residir fora do ambiente de carga de trabalho. As verificações de integridade precisam observar o status da VM spot e iniciar o pipeline de implantação para substituir a VM spot quando o status for alterado para desalocação ou parada.
Planejar várias remoções simultâneas
Se estiver executando um cluster de VMs spot, você deverá arquitetar a carga de trabalho para suportar várias remoções simultâneas. Várias VMs spot na carga de trabalho podem ser removidas ao mesmo tempo. Uma remoção simultânea de várias VMs pode afetar a taxa de transferência do aplicativo. Para evitar essa situação, seu pipeline de implantação deve ser capaz de coletar sinais de várias VMs e implantar várias VMs de substituição simultaneamente.
Projetar para um desligamento normal
Os processos de desligamento da VM devem ter menos de 30 segundos e permitir que a VM seja encerrada antes de uma remoção. O tempo de um desligamento dependerá da frequência com que sua carga de trabalho consulta o ponto de extremidade Eventos Agendados. Quanto mais frequentes forem as consultas ao ponto de extremidade, mais longo poderá ser o processo de desligamento. O processo de desligamento deve liberar recursos, drenar conexões e liberar logs de eventos. Você deve criar e salvar pontos de verificação regularmente para salvar o contexto e criar uma estratégia de recuperação mais eficiente. O ponto de verificação são apenas informações sobre quais processos ou transações a próxima VM precisa iniciar. Elas devem indicar se a VM deve continuar de onde a VM anterior parou ou se a nova VM deve reverter as alterações e iniciar todo o processo novamente. Você deve armazenar os pontos de verificação fora do ambiente da VM spot. Uma conta de armazenamento funcionaria.
Testar a orquestração
É recomendável simular eventos de remoção para testar a orquestração em ambientes de desenvolvimento/teste. Para saber mais, confira simular remoção.
Projetar uma carga de trabalho idempotente
É recomendável projetar uma carga de trabalho idempotente. O resultado do processamento de um evento mais de uma vez deve ser o mesmo que ao processá-lo uma vez. As remoções podem levar a desligamentos forçados, apesar dos esforços para garantir desligamentos normais. Os desligamentos forçados podem encerrar processos antes da conclusão. As cargas de trabalho idempotentes podem receber a mesma mensagem mais de uma vez e o resultado permanece o mesmo. Para obter mais informações, confira idempotência.
Usar um período de aquecimento do aplicativo
A maioria das cargas de trabalho interruptíveis executa aplicativos. Os aplicativos precisam de tempo para instalação e tempo para inicialização. Eles precisam de tempo para conexão com o armazenamento externo e para a coleta de informações dos pontos de verificação. É recomendável ter um período de aquecimento do aplicativo antes de permitir que ele inicie o processamento. Durante o período de aquecimento, o aplicativo deve estar inicializando, conectando e se preparando para contribuir. Você deve permitir que um aplicativo inicie o processamento de dados somente depois de validar a integridade do aplicativo.
Configurar identidades gerenciadas atribuída pelo usuário
É recomendável usar identidades gerenciadas atribuídas pelo usuário para simplificar o processo de autenticação e autorização. As identidades gerenciadas atribuídas pelo usuário evitam a colocação de credenciais em código e não estão vinculadas a um único recurso, como identidades gerenciadas atribuídas pelo sistema. As identidades gerenciadas atribuídas pelo usuário contêm permissões e tokens de acesso do Microsoft Entra ID que podem ser reutilizados e atribuídos a VMs spot durante a orquestração. A consistência de token entre VMs spot ajuda a simplificar a orquestração e o acesso aos recursos de carga de trabalho que as VMs spot possuem.
Com identidades gerenciadas atribuídas pelo sistema, uma nova VM spot pode obter um token de acesso diferente do Microsoft Entra ID. Se você precisar usar identidades gerenciadas atribuídas pelo sistema, é recomendável tornar as cargas de trabalho resilientes às respostas 403 Forbidden Error. Sua orquestração precisará obter tokens do Microsoft Entra ID com as permissões certas. Para obter mais informações, confira identidades gerenciadas.
Cenário de exemplo
O cenário de exemplo implanta um aplicativo de processamento de fila que é qualificado como uma carga de trabalho interruptível. Os scripts no cenário são ilustrativos. O cenário detalha um envio manual único para implantação de recursos. Não fornecemos um pipeline de implantação com essa implementação. Mas um pipeline de implantação é essencial para automatizar o processo de orquestração. O diagrama ilustra a arquitetura do cenário de exemplo.
As notas a seguir explicam os principais aspectos da arquitetura:
- Definição de aplicativo da VM: a definição de aplicativo da VM é criada na Galeria de Computação do Azure. Ela define o nome, o local, o sistema operacional e os metadados do aplicativo. A versão do aplicativo é uma versão numerada da definição do aplicativo da VM. A versão do aplicativo é uma instanciação do aplicativo da VM. Ela precisa estar na mesma região que a VM spot. A versão do aplicativo vincula-se ao pacote de aplicativos de origem na conta de armazenamento.
- Conta de armazenamento: a conta de armazenamento armazena o pacote de aplicativos de origem. Nessa arquitetura, é um arquivo tar compactado chamado
worker-0.1.0.tar.gz. Ele contém dois arquivos. Um arquivo é o script de buscaorchestrate.shque instala o aplicativo de trabalho do .NET. - VM spot: a VM spot é implantada. Ela deve estar na mesma região que a versão do aplicativo. Ela baixa
worker-0.1.0.tar.gzpara a VM após a implantação. O modelo bicep implanta uma imagem do Ubuntu em uma VM da família Standard. Essas configurações atendem às necessidades desse aplicativo e não são recomendações gerais para seus aplicativos. - Fila de Armazenamento: o outro serviço em execução no trabalho do .NET contém lógica de fila de mensagens. O Microsoft Entra ID concede à VM spot acesso à fila de armazenamento com uma identidade atribuída pelo usuário usando RBAC.
- Aplicativo de trabalho do .Net: o script orchestrate.sh instala um aplicativo de trabalho do .NET que executa dois serviços em segundo plano. O primeiro serviço consulta o ponto de extremidade Eventos Agendados, procura o sinal
Preempte envia esse sinal para o segundo serviço. O segundo serviço processa mensagens da fila de armazenamento e escuta o sinalPreemptdo primeiro serviço. Quando o segundo serviço recebe o sinal, ele interrompe o processamento da fila de armazenamento e começa o desligamento. - Consulta ao ponto de extremidade Eventos Agendados: uma solicitação de API é enviada para um endereço IP 169.254.169.254 estático e não roteável. A solicitação de API consulta o ponto de extremidade Evento Agendado para obter sinais de manutenção de infraestrutura.
- Application Insights: a arquitetura usa o Application Insights apenas para fins de aprendizado. Não é um componente essencial da orquestração de carga de trabalho interruptível. Nós o incluímos como uma maneira de validar a telemetria do aplicativo de trabalho do .NET. Configuramos o aplicativo de trabalho do .NET para enviar telemetria ao Application Insights. Para obter mais informações, confira habilitar métricas em tempo real no aplicativo .NET.
Implantar este cenário
Criamos um repositório do GitHub chamado carga de trabalho interruptível no spot com modelos, scripts e instruções passo a passo para implantação dessa arquitetura. Você encontrará mais detalhes técnicos sobre os artefatos de arquitetura e engenharia nesse repositório.
Próxima etapa
Para obter mais informações sobre Máquinas Virtuais Spot, confira Máquinas Virtuais de Spot do Azure.