Este artigo descreve as práticas recomendadas para criar máquinas virtuais spot do Azure. Ele inclui um cenário de exemplo implantável. Máquinas virtuais spot (VMs spot) fornecem acesso à capacidade de computação a preços mais baixos do que as VMs normais. Esse desconto os torna uma boa opção para organizações que desejam otimizar os custos. Mas as economias vêm com uma troca. As VMs spot podem ser removidas a qualquer momento, o que significa que elas perdem o acesso aos recursos de computação. As cargas de trabalho executadas em VMs 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. As recomendações a seguir descrevem como criar VMs spot.
Entender as VMs spot
Em um nível técnico, as VMs spot são iguais às VMs normais. Eles usam as mesmas imagens, hardware e discos que se traduzem no mesmo desempenho. A principal diferença entre VMs spot e VMs regulares é sua prioridade e disponibilidade. As VMs spot não têm prioridade para acessar a capacidade de computação e não têm garantias de disponibilidade depois de acessarem essa capacidade de computação.
Sem acesso de prioridade. VMs regulares têm acesso prioritário à capacidade de computação. Eles acessam a capacidade de computação quando a solicitam. No entanto, as VMs spot só são implantadas quando há capacidade de computação sobressalente. E eles só continuam a ser executados quando uma VM regular não precisa do hardware subjacente.
Nenhuma garantia de disponibilidade. As VMs spot não têm garantias de disponibilidade ou SLAs (contratos de nível de serviço). As VMs spot podem perder o acesso à capacidade de computação imediatamente ou a qualquer momento após a implantação ou remoção. As VMs spot são mais baratas porque podem ser removidas. Quando o Azure precisa da capacidade de computação de volta, um aviso de remoção é enviado e remove a VM spot. O Azure fornece um aviso prévio mínimo de 30 segundos antes da remoção real. Para obter mais informações, consulte Monitorar continuamente ode remoção.
Entender os preços de VM spot
As VMs spot podem ser até 90% mais baratas do que as VMs pagas conforme o uso regular. O desconto varia de acordo com a demanda, o tamanho da VM, a região de implantação e o sistema operacional. Para obter uma estimativa de economia de custos, consulte ferramenta de preço de Máquinas Virtuais Spot do Azure e visão geral de preços de Máquinas Virtuais Spot. Você também pode consultar a API de preços de varejo do Azure para obter programaticamente o preço spot de qualquer SKU.
Entender cargas de trabalho interrompíveis
As VMs spot são ideais para cargas de trabalho interruptíveis, que compartilham várias características comuns. Cargas de trabalho interruptíveis têm restrições mínimas ou sem tempo, baixa prioridade organizacional e tempos curtos de processamento. Eles executam processos que podem parar repentinamente e retomar posteriormente sem prejudicar processos organizacionais essenciais. Exemplos de cargas de trabalho interruptíveis são aplicativos de processamento em lote, análise de dados e cargas de trabalho que criam uma integração contínua e um agente de implantação contínua para um ambiente de não produção. Esses recursos se comparam a cargas de trabalho regulares ou críticas que têm SLAs, sessões autoadesivas e dados com estado.
Você pode usar VMs spot em cargas de trabalho não interrompíveis, mas elas não devem ser a única fonte de capacidade de computação. Use quantas VMs normais precisar para atender aos seus requisitos de tempo de atividade.
Entender a remoção
As VMs spot não têm SLAs após a criação e podem perder o acesso à computação a qualquer momento. Chamamos essa perda de computação de de remoção. Despejos de unidade de demanda e oferta de computação. Quando a demanda por um tamanho de VM específico excede um nível específico, o Azure remove VMs spot para disponibilizar computação para VMs regulares. A demanda é específica do local. Por exemplo, um aumento na demanda na região A não afeta VMs spot na região B.
As VMs 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 de política de remoção da VM spot. Defina essas configurações ao criar a VM spot. O tipo de remoção define as condições de um despejo. A política de remoção determina o que a remoção faz com sua VM spot.
Tipo de remoção
Alterações de capacidade ou alterações de preço causam remoções. A maneira como as alterações de capacidade e preço afetam as VMs spot depende do tipo de remoção escolhido quando a VM é criada. O tipo de remoção define as condições de um despejo. Os tipos de remoção são de remoção somente capacidade e de remoção de preço ou capacidade.
remoção somente capacidade: Esse tipo de remoção dispara uma remoção quando a capacidade de computação em excesso não está mais disponível. Por padrão, o preço é limitado à taxa paga conforme o uso. Use esse tipo de remoção quando você não quiser pagar mais do que o preço da VM paga 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 o excesso de capacidade de computação não está mais disponível 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 muito abaixo do preço pago 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. A orquestração é o processo de tratamento de uma remoção e é discutida posteriormente neste artigo. As políticas de remoção são a política Parar/Desalocar e a política de exclusão de .
política Parar/Desalocar: a política Parar/Desalocar é ideal quando a carga de trabalho pode aguardar a capacidade de lançamento 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. A VM perde capacidade de computação e endereços IP não estáticos com a política Parar/Desalocar. No entanto, os discos de dados da VM permanecem e continuam a incorrer 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 são paradas ou desalocadas. Para obter mais informações, consulte estados do Power ede cobrança.
Política de exclusão: usar a política Excluir se a carga de trabalho puder alterar o local ou o tamanho da VM. Alterar o local ou o tamanho da VM permite que a VM reimplante mais rapidamente. A política Excluir exclui a VM e qualquer disco de dados. A VM não ocupa núcleos em assinaturas. Para obter mais informações, consulte política de remoção.
Design para orquestração flexível
Orquestração é o processo de substituição de uma VM spot após uma remoção. É a base para a criação de uma carga de trabalho confiável e interruptível. Um bom sistema de orquestração tem flexibilidade interna. Flexibilidade significa projetar sua orquestração para ter opções, usar vários tamanhos de VM, implantar em regiões diferentes, ter reconhecimento de remoção e considerar diferentes cenários de remoção para melhorar a confiabilidade e a velocidade da carga de trabalho.
Design para velocidade
Para uma carga de trabalho executada em VMs spot, a capacidade de computação é crucial. Devido ao potencial de remoção, certifique-se de entender o tempo de computação alocado para que você possa tomar decisões de design informadas que priorizem a velocidade da carga de trabalho. Em geral, você deve otimizar o tempo de computação que você tem. Crie uma imagem de VM que tenha todo o software necessário pré-instalado. O software pré-instalado ajuda a minimizar o tempo entre a remoção e um aplicativo totalmente operacional. Evite usar o tempo de computação em processos que não contribuam para a finalidade da carga de trabalho. Por exemplo, uma carga de trabalho para análise de dados deve concentrar a maior parte do tempo de computação no processamento de dados e o menor tempo possível na coleta de metadados de remoção. Elimine processos não essenciais do seu aplicativo.
Usar vários tamanhos e locais de VM
Para aumentar a flexibilidade, crie uma orquestração para usar vários tipos e tamanhos de VMs. O objetivo é dar opções de orquestração para substituir uma VM removida. O Azure tem diferentes tipos e tamanhos de VMs que fornecem funcionalidades semelhantes pelo mesmo preço. Filtre para os núcleos ou vCPUs mínimos, a RAM mínima para VMs e o preço máximo. Esse processo ajuda você a encontrar várias VMs que se encaixam em seu orçamento e têm energia suficiente para executar sua carga de trabalho.
Cada tipo de VM tem uma taxa de remoção expressa como um intervalo percentual, como 0%-5%, 5%-10%, 10%-15%, 15%-20%ou mais 20%. As taxas de remoção podem variar entre 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 no portal na guia Noções Básicas do. Ao lado de Tamanho, selecione Exibir histórico de preços ou Ver todos os tamanhos. Você também pode obter dados de VM spot programaticamente usando o Azure Resource Graph.
Em seu sistema de orquestração, considere usar o recurso de pontuação de posicionamento spot para avaliar a probabilidade de sucesso para implantações pontuais individuais.
Para obter mais informações, consulte os seguintes recursos:
- taxas de remoção
- do Resource Graph
- pontuação de posicionamento spot
Usar a política de remoção mais flexível
A política de remoção da VM local removida afeta o processo de substituição. Por exemplo, uma política Delete é mais flexível do que uma política Stop/Deallocate.
considere a política De exclusão primeiro: usar uma política De exclusão se a carga de trabalho puder lidar com ela. A exclusão permite que a orquestração implante VMs de ponto de substituição em novas zonas e regiões. Essa flexibilidade de implantação pode ajudar sua carga de trabalho a encontrar a capacidade de computação sobressalente mais rapidamente do que uma VM parada ou desalocada. As VMs paradas ou desalocadas precisam aguardar a capacidade de computação sobressalente na mesma zona em que foram criadas. Para a política Excluir, você precisa de um processo externo para monitorar remoções e orquestrar implantações em várias regiões, usar SKUs de VM diferentes ou ambas.
Entenda a política Parar/Desalocar: a política Parar/Desalocar tem menos flexibilidade do que a política De exclusão. As VMs spot devem permanecer na mesma região e zona. Você não pode mover uma VM parada ou desalocada para outro local. Como as VMs têm um local fixo, você precisa de algo em vigor para realocar a VM quando a capacidade de computação estiver disponível. Não há como prever a disponibilidade da capacidade de computação. Portanto, você deve usar 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 fique disponível.
| Política | Quando usar a política |
|---|---|
| Excluir política | - Computação e dados efêmeros - Não quero pagar por discos de dados - Orçamento mínimo |
| Política de parada/desalocação | - Precisa de um tamanho de VM específico - Não é possível alterar o local – Processo de instalação de aplicativo longo - Tempo de espera indefinido - Não impulsionado apenas pela economia de custos |
Monitorar continuamente a remoção
O monitoramento é a chave para a confiabilidade da carga de trabalho em VMs spot. As VMs 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. Se você tiver essas informações, poderá tentar um desligamento normal da carga de trabalho e disparar a automação para orquestrar a substituição.
usar eventos agendados: usar o serviço eventos agendados para cada VM. O Azure envia sinais para VMs quando a manutenção da infraestrutura os afetará. As remoções se qualificam como manutenção de infraestrutura. O Azure envia o sinal de
Preemptpara todas as VMs no mínimo 30 segundos antes de serem removidas. O serviço Eventos Agendados permite que você capture esse sinalPreemptconsultando um ponto de extremidade no endereço IP estático e não existente169.254.169.254.Usar consultas frequentes: 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 até cada segundo, mas uma frequência de um segundo pode não ser necessária para todos os casos de uso. Essas consultas devem vir de um aplicativo que é executado na VM local. A consulta não pode vir de uma fonte externa. Como resultado, as consultas consomem a capacidade de computação da VM e roubam o poder de processamento da carga de trabalho principal. Você precisa equilibrar essas prioridades concorrentes para atender à sua situação específica.
Automatizar a orquestração: Depois de coletar o sinal de
Preempt, sua orquestração deve agir nesse sinal. Dadas as restrições de tempo, o sinal dePreemptdeve tentar um desligamento normal da carga de trabalho e iniciar um processo automatizado que substitua a VM spot. Para obter mais informações, consulte os seguintes recursos:
Criar um sistema de implantação
Sua orquestração precisa de um pipeline automatizado para implantar novas VMs spot após a remoção. O pipeline deve ser executado fora da carga de trabalho interruptível para ajudar a garantir a permanência. O pipeline de implantação deve funcionar de acordo com a política de remoção escolhida para suas VMs spot.
Para uma política De exclusão, recomendamos que você crie um pipeline que use diferentes tamanhos de VM e implante em regiões diferentes. Para uma política Stop/Deallocate, o pipeline de implantação precisa de duas ações distintas. Para a criação inicial de uma VM, o pipeline precisa implantar as VMs de 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 funções do Azure é uma maneira de automatizar um sistema de implantação. O pipeline pode usar modelos de bicep. Eles são declarativos e idempotentes e representam uma prática recomendada para implantação de infraestrutura.
Preparar-se para remoção imediata
É possível que o Azure remova uma VM spot assim que você a criar e antes que sua carga de trabalho seja executada. Em alguns casos, pode haver capacidade suficiente para criar uma VM spot, mas ela não durará. As VMs spot não têm garantias de disponibilidade ou SLAs após a criação. Sua orquestração precisa considerar remoções imediatas. O sinal de Preempt fornece um aviso prévio mínimo de 30 segundos do despejo.
Incorpore 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 de Preempt eventos agendados. Somente a própria VM pode consultar o sinal de Preempt e não há tempo suficiente para iniciar um aplicativo, consultar o ponto de extremidade eventos agendados e desligar normalmente. Portanto, a verificação de integridade precisa residir fora do ambiente de carga de trabalho. As verificações de integridade precisam monitorar o status da VM spot e iniciar o pipeline de implantação para substituir a VM spot quando o status for alterado para desalocar ou parar.
Planejar várias remoções simultâneas
Se você executar um cluster de VMs spot, arquitete a carga de trabalho para suportar vários despejos simultâneos. 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, o pipeline de implantação deve ser capaz de coletar sinais de várias VMs e implantar várias VMs de substituição simultaneamente.
Design para um desligamento normal
O processo de desligamento da VM deve ser inferior a 30 segundos e permitir que sua VM seja desligada antes de uma remoção. O tempo que o desligamento deve levar depende da frequência com que sua carga de trabalho consulta o ponto de extremidade eventos agendados. Quanto mais frequentemente você consulta o ponto de extremidade, mais tempo o processo de desligamento pode levar. O processo de desligamento deve liberar recursos, esvaziar conexões e liberar logs de eventos. Você deve criar e salvar pontos de verificação regularmente para manter o contexto e criar uma estratégia de recuperação mais eficiente. O ponto de verificação é apenas informações sobre quais processos ou transações a próxima VM precisa iniciar. Eles devem indicar se a VM deve retomar onde a VM anterior parou ou se a nova VM deve reverter as alterações e iniciar todo o processo novamente. Armazene os pontos de verificação fora do ambiente de VM local, como em uma conta de armazenamento.
Testar a orquestração
Simule eventos de remoção para testar a orquestração em ambientes de desenvolvimento/teste. Para obter mais informações, consulte Simularde remoção.
Projetar uma carga de trabalho idempotente
Recomendamos que você projete uma carga de trabalho idempotente. O resultado do processamento de um evento mais de uma vez deve ser o mesmo que processá-lo uma vez. Despejos podem resultar em desligamentos forçados, apesar dos esforços para garantir desligamentos normais. Desligamentos forçados podem encerrar processos antes da conclusão. Cargas de trabalho Idempotentes podem receber a mesma mensagem mais de uma vez sem alterar o resultado. Para obter mais informações, consulte Idempotency.
Usar um período de aquecimento do aplicativo
A maioria das cargas de trabalho interruptíveis executa aplicativos. Os aplicativos precisam de tempo para instalar e iniciar. Eles também precisam de tempo para se conectar ao armazenamento externo e coletar informações de pontos de verificação. Tenha um período de aquecimento do aplicativo antes de permitir que ele inicie o processamento. Durante o período de aquecimento, o aplicativo deve iniciar, estabelecer conexões e se preparar para contribuir. Só permita que um aplicativo inicie o processamento de dados depois de validar a integridade do aplicativo.
Configurar identidades gerenciadas atribuídas pelo usuário
Atribua 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 permitem evitar a colocação de credenciais no 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 da ID do Microsoft Entra que podem ser reutilizados e atribuídos para detectar VMs durante a orquestração. A consistência de token em VMs spot ajuda a simplificar a orquestração e simplifica o acesso aos recursos de carga de trabalho que as VMs spot têm.
Se você usar identidades gerenciadas atribuídas pelo sistema, uma nova VM spot poderá obter um token de acesso diferente da ID do Microsoft Entra. Se você precisar usar identidades gerenciadas atribuídas pelo sistema, torne as cargas de trabalho resilientes a respostas 403 Forbidden Error. Sua orquestração precisa obter tokens da ID do Microsoft Entra com as permissões certas. Para obter mais informações, consulte Identidades gerenciadas.
Cenário de exemplo
O cenário de exemplo implanta um aplicativo de processamento de fila que se qualifica como uma carga de trabalho interruptível. Os scripts no cenário servem como exemplos. O cenário orienta você por um push manual único para implantar recursos. Essa implementação não tem um pipeline de implantação. No entanto, um pipeline de implantação é essencial para automatizar o processo de orquestração. O diagrama a seguir mostra a arquitetura do cenário de exemplo.
Baixe um arquivo do Visio dessa arquitetura.
O fluxo de trabalho a seguir corresponde ao diagrama anterior:
definição de aplicativo de VM: a definição do aplicativo de VM é criada na galeria de computação do Azure. Ele define o nome do aplicativo, o local, o sistema operacional e os metadados. A versão do aplicativo é uma versão numerada da definição do aplicativo de VM. A versão do aplicativo representa o aplicativo de VM. Ele precisa estar na mesma região que a VM spot. A versão do aplicativo é vinculada ao pacote de aplicativo de origem na conta de armazenamento.
Conta de armazenamento: a conta de armazenamento armazena o pacote de aplicativo de origem. Nesta arquitetura, é um arquivo tar compactado chamado
worker-0.1.0.tar.gz. Ele contém dois arquivos. Um arquivo é o script bashorchestrate.shque instala o aplicativo de trabalho do .NET.VM spot: a VM spot é implantada. Ele deve estar na mesma região que a versão do aplicativo. Ele 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 de família padrão. 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 executado no trabalho do .NET contém a lógica da fila de mensagens. A ID do Microsoft Entra concede acesso à VM spot à fila de armazenamento no Armazenamento de Filas do Azure com uma identidade atribuída pelo usuário usando o controle de acesso baseado em função.
aplicativo de trabalho do .NET: O script
orchestrate.shinstala 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 dePreempte 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 a desligar.ponto de extremidade eventos agendados de consulta: uma solicitação de API é enviada para um endereço IP nãooutável estático
169.254.169.254. A solicitação de API consulta o ponto de extremidade eventos agendados para sinais de manutenção de infraestrutura.Application Insights: A arquitetura usa o Application Insights apenas para fins de aprendizagem. Não é um componente essencial da orquestração de carga de trabalho interruptível, mas permite validar a telemetria do aplicativo de trabalho do .NET. O aplicativo de trabalho do .NET envia telemetria para o Application Insights. Para obter mais informações, consulte Habilitar métricas dinâmicas do aplicativo .NET.
Implantar esse cenário
Há um repositório GitHub chamado carga de trabalho interruptível no local que tem modelos, scripts e instruções passo a passo para implantar essa arquitetura.