Este artigo descreve as práticas recomendadas para criar em Máquinas Virtuais do Azure Spot. Ele inclui um cenário de exemplo implantável. As máquinas virtuais spot (VMs spot) fornecem acesso à capacidade de computação a preços mais baixos do que as VMs comuns. Este desconto torna-os uma boa opção para organizações que querem otimizar custos. Mas a economia vem com uma compensação. 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 locais 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 em VMs locais.
Compreender as VMs spot
Em um nível técnico, as VMs spot são as mesmas que as VMs comuns. 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 prioritário. As 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 normal não precisa do hardware subjacente.
Sem garantia de disponibilidade. As VMs spot não têm garantias de disponibilidade ou contratos de nível de serviço (SLAs). As VMs spot podem perder o acesso à capacidade de computação imediatamente ou a qualquer momento após a implantação ou a remoção. As VMs spot são mais baratas porque podem ser despejadas. Quando o Azure precisa da capacidade de computação de volta, um aviso de remoção é enviado e remove a VM local. O Azure fornece um aviso prévio mínimo de 30 segundos antes que o despejo real ocorra. Para obter mais informações, consulte Monitorar continuamente ade despejo .
Compreender os preços de VM spot
As VMs spot podem ser até 90% mais baratas do que as VMs pré-pagas. 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 de preços da ferramenta de preços 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 para qualquer SKU.
Compreender cargas de trabalho interruptíveis
As VMs spot são ideais para cargas de trabalho interruptíveis, que compartilham várias características comuns. As cargas de trabalho interruptíveis têm restrições de tempo mínimas ou nulas, baixa prioridade organizacional e tempos de processamento curtos. Eles executam processos que podem parar de repente e retomar mais tarde 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 um agente de integração contínua e implantação contínua para um ambiente que não seja de produção. Esses recursos se comparam a cargas de trabalho regulares ou de missão crítica que têm SLAs, sessões rígidas e dados com monitoração de estado.
Você pode usar VMs spot em cargas de trabalho ininterruptas, mas elas não devem ser a única fonte de capacidade de computação. Use quantas VMs regulares precisar para atender aos seus requisitos de tempo de atividade.
Entenda o despejo
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 computacional de despejo . Calcule a oferta e a demanda impulsionam despejos. 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 procura é específica da localização. Por exemplo, um aumento na demanda na região A não afeta as 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 despejo e de política de remoção da VM local. Você define essas configurações ao criar a VM spot. O tipo de despejo define as condições de um despejo. A política de despejo determina o que o despejo faz com sua VM local.
Tipo de despejo
Mudanças de capacidade ou de preço causam despejos. 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 despejo define as condições de um despejo. Os tipos de despejo são de despejo apenas de capacidade e preço ou capacidade de despejo.
Despejo apenas de capacidade: Esse tipo de despejo aciona uma remoção quando o excesso de capacidade de computação não está mais disponível. Por padrão, o preço é limitado à taxa de pré-pagamento. Use esse tipo de remoção quando não quiser pagar mais do que o preço da VM pré-paga.
Preço ou capacidade de despejo: Este tipo de despejo 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 que você definiu. Este tipo de despejo permite-lhe definir um preço máximo muito abaixo do preço pré-pago. Use este tipo de despejo para definir seu próprio limite de preço.
Política de despejo
A política de remoção escolhida para uma VM local afeta sua orquestração. A orquestração é o processo de lidar com um despejo e é discutida mais adiante neste artigo. As políticas de remoção são a política Stop/Deallocate e a política Delete.
política Parar/Desalocar: A política Parar/Desalocar é ideal quando a carga de trabalho pode aguardar a capacidade de liberação 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 deslocalizar uma VM spot é o mesmo que parar e deslocalizar uma VM normal. 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 interrompidas ou deslocalizadas. Para obter mais informações, consulte Estados de energia ede faturamento .
Política de exclusão: Use 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 seja reimplantada 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 despejo.
Design para orquestração flexível
Orquestração é o processo de substituição de uma VM local após uma remoção. É a base para a criação de uma carga de trabalho interruptível de forma confiável. Um bom sistema de orquestração tem flexibilidade incorporada. Flexibilidade significa projetar sua orquestração para ter opções, usar vários tamanhos de VM, implantar em regiões diferentes, ter consciência de remoção e levar em conta 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 locais, a capacidade de computação é crucial. Devido ao potencial de remoção, certifique-se de entender o tempo de computação alocado para que possa tomar decisões de projeto informadas que priorizem a velocidade da carga de trabalho. Geralmente, 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 contribuem para a finalidade da carga de trabalho. Por exemplo, uma carga de trabalho para análise de dados deve concentrar a maior parte de seu 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 recursos semelhantes por aproximadamente o mesmo preço. Filtre o mínimo de vCPUs ou núcleos, a RAM mínima para VMs e o preço máximo. Esse processo ajuda você a encontrar várias VMs que cabem no seu orçamento e têm poder 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 20+%. As taxas de despejo 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 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 programaticamente dados de VM spot usando o Azure Resource Graph.
Em seu sistema de orquestração, considere o uso do recurso de pontuação de posicionamento pontual para avaliar a probabilidade de sucesso de implantações pontuais individuais.
Para obter mais informações, consulte os seguintes recursos:
Use a política de despejo mais flexível
A política de despejo da VM local despejada afeta o processo de substituição. Por exemplo, uma política Excluir é mais flexível do que uma política Parar/Desalocar.
Considere a política Excluir primeiro: Use uma política de Exclusão se sua carga de trabalho puder lidar com ela. A exclusão permite que a orquestração implante VMs 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 ociosa mais rápido do que uma VM parada ou desalocada. As VMs interrompidas 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 ambos.
Compreender a política Parar/Desalocar: A política Parar/Desalocar tem menos flexibilidade do que a política Excluir. As VMs spot devem permanecer na mesma região e zona. Não é possível mover uma VM interrompida ou desalocada para outro local. Como as VMs têm um local fixo, você precisa de algo no local 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 acionar 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 parar/desalocar | - Precisa de um tamanho de VM específico - Não é possível alterar a localização - Longo processo de instalação de aplicações - Tempo de espera indefinido - Não impulsionado apenas pela redução de custos |
Monitore continuamente o despejo
O monitoramento é a chave para a confiabilidade da carga de trabalho em VMs locais. 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 locais é antecipar quando elas serão removidas. Se você tiver essas informações, poderá tentar um desligamento normal da carga de trabalho e acionar a automação para orquestrar a substituição.
Usar eventos agendados: Use o serviço Eventos agendados para cada VM. O Azure envia sinais para VMs quando a manutenção da infraestrutura vai afetá-las. Os despejos qualificam-se como manutenção de infraestruturas. 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 capturar esse sinal dePreemptconsultando um ponto de extremidade no endereço IP estático e não roteável169.254.169.254.Use consultas frequentes: Consultar o ponto de extremidade de Eventos Agendados com frequência suficiente para orquestrar um desligamento normal. Você pode consultar o ponto de extremidade de 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 executado na VM local. A consulta não pode vir de uma fonte externa. Como resultado, as consultas consomem capacidade de computação da VM e roubam poder de processamento da carga de trabalho principal. Você precisa equilibrar essas prioridades concorrentes para atender à sua situação específica.
Automatize a orquestração: Depois de coletar o sinal
Preempt, sua orquestração deve agir sobre esse sinal. Dadas as restrições de tempo, o sinal dePreemptdeve tentar um desligamento normal da sua carga de trabalho e iniciar um processo automatizado que substitua a VM local. Para obter mais informações, consulte os seguintes recursos:- Eventos agendados
- Tipos de eventos agendados
- de frequência de consulta de pontos finais
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 tamanhos de VM diferentes e implante em regiões diferentes. Para uma política de Parar/Desalocar, 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 poderia usar modelos de bíceps. Eles são declarativos e idempotentes e representam uma prática recomendada para a implantação de infraestrutura.
Prepare-se para o despejo imediato
É possível que o Azure remova uma VM local assim que você criá-la 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 dar conta de despejos imediatos. O sinal de Preempt fornece um aviso mínimo de 30 segundos de antecedência do despejo.
Incorpore verificações de integridade de VM em sua orquestração para se preparar para despejos imediatos. A orquestração para despejos imediatos não pode depender do sinal de Preempt de 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 de 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 de deslocalização ou interrupção.
Planeje vários despejos simultâneos
Se você executar um cluster de VMs spot, arquitete 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.
Design para um desligamento gracioso
O processo de desligamento da VM deve ter menos de 30 segundos e permitir que a VM seja desligada antes de uma remoção. A quantidade de tempo que o desligamento deve levar depende da frequência com que sua carga de trabalho consulta o ponto de extremidade de Eventos Agendados. Quanto mais vezes você consultar o ponto de extremidade, mais tempo o processo de desligamento pode levar. 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 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.
Teste a orquestração
Simule eventos de remoção para testar a orquestração em ambientes de desenvolvimento/teste. Para obter mais informações, consulte Simular despejo.
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. Os despejos podem resultar em desligamentos forçados, apesar dos esforços para garantir desligamentos graciosos. 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 Idempotência.
Use 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 comece a ser processado. Durante o período de aquecimento, o aplicativo deve iniciar, estabelecer conexões e se preparar para contribuir. Só permita que um aplicativo comece a processar 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 colocar 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 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 agilizar a orquestração e simplifica o acesso aos recursos de carga de trabalho que as VMs spot possuem.
Se você usar identidades gerenciadas atribuídas ao sistema, uma nova VM spot poderá obter um token de acesso diferente do ID do Microsoft Entra. Se você precisar usar identidades gerenciadas atribuídas ao sistema, torne as cargas de trabalho resilientes a 403 Forbidden Error respostas. Sua orquestração precisa obter tokens do Microsoft Entra ID 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 interinterrupta. 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 VM: A definição de aplicativo 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 VM. A versão do aplicativo representa o aplicativo VM. Ele precisa estar na mesma região que a VM local. A versão do aplicativo vincula-se ao pacote do aplicativo de origem na conta de armazenamento.
Conta de armazenamento: A conta de armazenamento armazena o pacote do aplicativo de origem. Nessa 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 .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 deste aplicativo e não são recomendações gerais para seus aplicativos.fila de armazenamento: O outro serviço executado no trabalhador .NET contém lógica de fila de mensagens. O Microsoft Entra ID concede à VM local acesso à 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 .NET: O script
orchestrate.shinstala um aplicativo de trabalho .NET que executa dois serviços em segundo plano. O primeiro serviço consulta o ponto de extremidade de 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 sinal dePreemptdo primeiro serviço. Quando o segundo serviço recebe o sinal, ele interrompe o processamento da fila de armazenamento e começa a ser desligado.ponto de extremidade de Eventos Agendados de Consulta: Uma solicitação de API é enviada para um endereço IP estático não roteável
169.254.169.254. A solicitação de API consulta o ponto de extremidade de Eventos Agendados em busca de 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 .NET. O aplicativo de trabalho .NET envia telemetria para o Application Insights. Para obter mais informações, consulte Habilitar métricas em tempo real do aplicativo .NET.
Implantar este 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.