Neste artigo, descrevemos as práticas recomendadas para criar máquinas virtuais (VMs) spot do Azure e incluímos um cenário de exemplo implantável. As VMs spot fornecem acesso à capacidade de computação com descontos significativos para VMs regulares. Este desconto torna-os uma solução atrativa para organizações que procuram otimizar custos, mas a poupança vem acompanhada de uma condição. As VMs spot podem perder o acesso à computação a qualquer momento. Chamamos a este processo um despejo. 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. Aqui estão nossas recomendações para criar VMs no local.
Compreender as máquinas virtuais spot
Em um nível técnico, as VMs spot são as mesmas que as VMs regulares. Eles usam as mesmas imagens, hardware e discos que se traduzem no mesmo desempenho. A diferença entre VMs spot e regulares se resume à 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 acessar essa capacidade de computação. Vamos discutir a prioridade e a disponibilidade com mais detalhes.
Sem acesso prioritário. As VMs regulares têm acesso prioritário à capacidade de computação. Eles acessam a capacidade de computação sempre que a solicitam. As VMs spot, por outro lado, só são implantadas quando há capacidade de computação sobressalente e só permanecem em execução quando uma VM normal não precisa do hardware subjacente.
Sem garantia de disponibilidade. As VMs spot não têm garantias de disponibilidade. Eles não têm 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 (remoção). As VMs spot são mais baratas devido à possibilidade de despejo. Sempre que o Azure precisar 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 a remoção neste artigo.
Compreender os preços das máquinas virtuais spot
As VMs spot podem ser até 90% mais baratas do que as VMs normais (pré-pagas). O desconto varia de acordo com a demanda, o tamanho da VM, a região de implantação e o sistema operacional. Recomendamos que você use a ferramenta de preços de VM spot do Azure para obter uma estimativa da economia de custos. Para obter mais informações, consulte:
Você também pode consultar a API de preços de varejo do Azure para obter programaticamente o preço 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 spot. As cargas de trabalho interruptíveis têm algumas características comuns. Eles têm restrições de tempo mínimas ou nenhumas, 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 implantação contínua de 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 (Service Level Agreements, contratos de nível de serviço), sessões rígidas e dados com monitoração de estado. A tabela fornece exemplos para ambos os tipos de carga de trabalho.
| Recursos de carga de trabalho interruptível | Recursos regulares de carga de trabalho | |
|---|---|---|
| Funcionalidades | Restrições de tempo mínimas ou nulas Baixa prioridade organizacional Tempos de processamento curtos |
Contratos de nível de serviço (SLAs) Requisitos de sessões adesivas Cargas de trabalho com monitoração de estado |
Você pode usar VM 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 contratos de nível de serviço (SLAs) depois de serem criadas e podem perder o acesso à computação a qualquer momento. Chamamos isso de perda computacional de despejo. A computação de oferta e demanda impulsiona a remoção. Quando a demanda por um tamanho de VM específico excede um determinado nível, o Azure remove VMs spot para disponibilizar computação para VMs regulares. A procura é específica da localização. Um aumento na demanda na região A não afetará 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 a "política de despejo" 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 a sua VM local. Vamos abordar ambas as opções de configuração.
Tipo de despejo
O despejo é causado por mudanças de capacidade ou de preços. A maneira como elas afetam as VMs spot depende do tipo de remoção escolhido quando a VM foi criada. O tipo de despejo define as condições de um despejo. Os tipos de despejo são "despejo apenas de capacidade" e "despejo de preço ou capacidade".
Despejo apenas com capacidade: este tipo de despejo desencadeia um despejo quando o excesso de capacidade de computação desaparece. Por padrão, o preço é limitado à taxa de pré-pagamento. Use esse tipo de remoção quando estiver disposto a pagar até o preço da VM pré-pago.
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 desaparece ou o custo da VM excede o preço máximo definido. 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 despejo escolhida para uma VM spot afeta sua orquestração. Por orquestração, entende-se o processo de tratamento de um despejo. Abordaremos a orquestração em detalhes mais tarde. As políticas de despejo são a "Política de parada/desalocar" e "Política de exclusão".
Política de parar/desalocar: a política de parar/desalocar remoção é melhor 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. 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/deslocalizadas. Para obter mais informações, consulte Estados de energia e faturamento da VM.
Excluir política: use a opção "Excluir política" 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 em assinaturas. Para obter mais informações sobre políticas de despejo, 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 da construção de uma carga de trabalho interruptível de forma confiável. Um bom sistema de orquestração tem flexibilidade incorporada. Por flexibilidade, queremos dizer projetar sua orquestração para ter opções, usar vários tamanhos de VM, implantar em diferentes regiões, estar ciente da 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 para ajudá-lo 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 locais, a capacidade de computação é um tesouro. O potencial iminente de despejo deve elevar seu apreço pelo tempo de computação alocado e deve se traduzir em decisões de projeto significativas que priorizam a velocidade da carga de trabalho. Em geral, recomendamos 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 não essenciais do seu aplicativo.
Usar vários tamanhos e locais de VM
Recomendamos criar uma orquestração para usar vários tipos e tamanhos de VM para 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 pelo mesmo preço. Você deve filtrar VMs min vCPUs/Cores e/ou min RAM e preço máximo para encontrar várias VMs que têm o poder de executar sua carga de trabalho e caber dentro do seu orçamento. Cada tipo de VM tem uma taxa de despejo expressa como um intervalo percentual (0-5%, 5-10%, 10-15%, 15-20%, 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 "Básicos". Selecione os links "Tamanho" ("Ver 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. Para obter mais informações, consulte:
Use a política de despejo mais flexível
A política de despejo da VM local despejada afeta o processo de substituição. Uma política de despejo de exclusão é mais flexível do que uma política de despejo interrompido/desalocado.
Considere a política de exclusão primeiro: recomendamos usar uma política de remoção de exclusão se sua carga de trabalho puder lidar com isso. 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/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 diferentes regiões e/ou com diferentes SKUs de VM.
Compreender a política de parada/desalocada: a política de parada/desalocação tem menos flexibilidade do que a política de exclusão. As VMs 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 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, recomendamos o uso de 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 | |
|---|---|---|
| Eliminar | Computação e dados efêmeros Não quer pagar por discos de dados Orçamento mínimo |
|
| Parado/Desalocado | Precisa de um tamanho de VM específico Não é possível alterar a localização Longo processo de instalação de aplicativos |
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. Com essas informações, você pode tentar um desligamento normal da carga de trabalho e acionar a automação que orquestra a substituição.
Usar eventos agendados: recomendamos usar o serviço de eventos agendados para cada VM. O Azure envia sinais para VMs quando elas serão afetadas pela manutenção da infraestrutura. Os despejos qualificam-se como manutenção de infraestruturas. O Azure envia o Preempt sinal para todas as VMs no mínimo 30 segundos antes de serem removidas. Um serviço chamado Schedule Events permite capturar esse Preempt sinal consultando um ponto de extremidade em um endereço 169.254.169.254IP estático e não roteável.
Use consultas frequentes: recomendamos consultar o ponto de extremidade Agendar eventos com frequência suficiente para orquestrar um desligamento normal. Você pode consultar o ponto de extremidade de Eventos Agendados até cada segundo, mas a frequência de um segundo pode não ser necessária para todos os casos de uso. Essas consultas devem vir de um aplicativo em execução na VM local. A consulta não pode vir de uma fonte externa. Como resultado, as consultas consumirão a capacidade de computação da VM e roubarão o poder de processamento da carga de trabalho principal. Você precisará equilibrar essas prioridades concorrentes para atender à sua situação específica.
Automatize a orquestração: Depois de coletar o Preempt sinal, sua orquestração deve agir sobre esse sinal. Dadas as restrições de tempo, o sinal deve tentar um desligamento Preempt normal da sua carga de trabalho e iniciar um processo automatizado que substitua a VM local. Para obter mais informações, consulte:
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, recomendamos 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 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 do Azure Functions é uma das várias maneiras 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 sua VM local seja designada para remoção assim que for criada e antes mesmo de sua carga de trabalho ser executada. Só porque houve capacidade para criar uma VM spot, não significa que ela persistirá. As VMs spot não têm garantias de disponibilidade (SLAs) após a criação. Sua orquestração precisa dar conta de despejos imediatos. O Preempt sinal ainda fornecerá um aviso mínimo de 30 segundos de antecedência do despejo.
Recomendamos incorporar 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 Schedule Events Preempt . Somente a própria VM pode consultar o sinal, e não há tempo suficiente para iniciar um aplicativo, consultar o Preempt ponto de extremidade Schedule Events e desligar normalmente. 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 mudar para deslocalização ou parada.
Planeje vários despejos simultâneos
Se você estiver executando um cluster de VMs spot, 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.
Design para um desligamento gracioso
Os processos de desligamento da VM devem 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 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 é 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. Você deve armazenar os pontos de verificação fora do ambiente de VM local. Uma conta de armazenamento funcionaria.
Teste a orquestração
Recomendamos simular 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 projetar 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 levar a 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 e o resultado permanece o mesmo. 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 tempo para inicializar. Eles precisam de tempo para se conectar ao armazenamento externo e coletar informações de pontos de verificação. Recomendamos ter 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 estar inicializando, conectando-se e preparando-se para contribuir. Você só deve permitir que um aplicativo comece a processar dados depois de validar a integridade do aplicativo.
Configurar identidades gerenciadas atribuídas pelo usuário
Recomendamos o uso de 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 simplificar a orquestração e o acesso aos recursos de carga de trabalho que as VMs spot têm.
Com identidades gerenciadas atribuídas pelo sistema, uma nova VM spot pode obter um token de acesso diferente do ID do Microsoft Entra. Se você precisar usar identidades gerenciadas atribuídas ao sistema, recomendamos tornar as cargas de trabalho resilientes às 403 Forbidden Error respostas. Sua orquestração precisará 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 são ilustrativos. O cenário orienta você por um push manual único para implantar 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 aspetos da arquitetura:
- 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 é uma instanciação do 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 bash que instala oorchestrate.shaplicativo de trabalho .NET. - VM spot: a VM spot é implantada. Ele deve estar na mesma região que a versão do aplicativo. Ele é baixado
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 deste aplicativo e não são recomendações gerais para seus aplicativos. - Fila de armazenamento: O outro serviço em execução no trabalhador .NET contém lógica de fila de mensagens. O Microsoft Entra ID concede à VM local acesso à fila de armazenamento com uma identidade atribuída ao usuário usando RBAC.
- Aplicativo de trabalho .Net: O script orchestrate.sh instala um aplicativo de trabalho .NET que executa dois serviços em segundo plano. O primeiro serviço consulta o ponto de extremidade Schedule Events e procura o sinal e envia esse sinal para o
Preemptsegundo serviço. O segundo serviço processa mensagens da fila de armazenamento e escuta oPreemptsinal do 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 evento agendado 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. Nós o incluímos como uma maneira de validar a telemetria do aplicativo de trabalho .NET. Configuramos o aplicativo de trabalho .NET para enviar telemetria para o Application Insights. Para obter mais informações, consulte habilitar métricas em tempo real do aplicativo .NET.
Implementar este cenário
Criamos um repositório GitHub chamado carga de trabalho interruptível no local com modelos, scripts e instruções passo a passo para implantar essa arquitetura. Você encontrará mais detalhes técnicos sobre os artefatos de arquitetura e engenharia neste repositório.
Próximo passo
Para obter mais informações sobre Máquinas Virtuais Spot, consulte Máquinas Virtuais Spot do Azure.