Utilização de VMs spot em Azure CycleCloud

O Azure CycleCloud suporta a implementação de VMs spot em nodearrays para reduzir consideravelmente o custo operacional dos clusters.

Atenção

Os VM spot não são adequados para todas as cargas de trabalho e tipos de cluster. Não oferecem SLA para disponibilidade ou capacidade. São casos "preempíveis" ou "de baixa prioridade" e podem ser despejados pelo tecido Azure para gerir a capacidade e à medida que o preço à vista muda.

Configurar um Nodearray para Spot

Para ativar o Spot para um nódarray, basta definir Interruptible para ser verdadeiro na [[nodearray]] secção.

O CycleCloud permite que os clusters especifiquem um MaxPrice para instâncias spot. Uma vez que o preço spot pode ajustar-se periodicamente e pode variar significativamente entre Regiões e SKUs, permite MaxPrice que os utilizadores controlem o preço máximo (em $/hora) que estão dispostos a pagar por um VM. Por predefinição, o CycleCloud define MaxPrice=-1 quando não especificado de outra forma, o que significa "não despejar com base no preço spot". Com este cenário, os casos só serão despejados devido a alterações nas exigências de capacidade ou outras decisões a nível da plataforma.

Consulte o Preço à Vista para obter detalhes sobre preços variáveis para instâncias spot.

Para a maioria das aplicações HPC, MaxPrice=-1 é uma boa escolha padrão. No entanto, se um nodearray suporta autoscaling multi-selecionados através de uma gama de SKUs VM, então MaxPrice também pode ser personalizado para criar uma preferência por SKUs a preços mais baixos na lista multi-selecionada.

[cluster demo]

  [[nodearray execute]]
  Interruptible = true
  MaxPrice = 0.2

Para mais detalhes, consulte spot Máquinas Virtuais no guia do modelo de cluster.

Despejo de Spot VM

CycleCloud monitoriza para despejos pontuais através da funcionalidade Eventos Agendados . Quando um evento de preempção de ponto é detetado, o CycleCloud é notificado pelo VM e a instância é movida para um estado de "espera de despejo".

Perguntas Mais Frequentes

A utilização do Spot com CycleCloud tem algumas considerações específicas para as cargas de trabalho do HPC e para o auto-dimensionamento do CycleCloud.

Quando devo considerar usar o Spot?

• Os seus trabalhos individuais são relativamente curtos?
  • Uma boa regra é que os empregos que funcionam em menos de uma hora podem ser um bom ajuste para os casos spot, porque relativamente pouco progresso para a frente se o caso for despejado.
• O seu programador recandidou automaticamente/recandidou automaticamente os trabalhos em anfitriões que falham?
• Os seus trabalhos são seguros para se recandidatar se o hospedeiro for despejado durante a execução?
  • Em geral, as instâncias à vista são melhores para cargas de trabalho apátridas.
• Minimizar o custo da execução é mais importante do que o tempo de conclusão?
  • O spot é muitas vezes perfeito para cargas de trabalho que podem ser agendadas em filas de baixa prioridade ou de reenchimento no local.
  • Este é um dos casos em que o Spot pode ser apropriado mesmo para trabalhos de MPI curtos.

Quando devo evitar a utilização do Spot?

• Se os seus empregos são muito acoplidos a empregos de HPC (por exemplo, empregos de MPI) então eles provavelmente não são bons candidatos para spot.
• Se o seu Trabalho for crítico e/ou tiver um prazo para a conclusão, então as instâncias prioritárias regulares podem ser mais adequadas, uma vez que os despejos e as retrações podem estender o tempo até à conclusão.
  • No entanto, esta pode ser uma excelente oportunidade para configurar o seu cluster para usar uma mistura de instâncias de prioridade regular e spot para garantir que o prazo é cumprido enquanto tenta reduzir o tempo de execução e o custo adicionando instâncias spot.
• Se os seus trabalhos não forem seguros para se recandidatar, então o Spot deve ser evitado.
  • Por exemplo, se o seu trabalho modificar uma base de dados durante a execução, então a recorrida automaticamente do trabalho pode causar erros ou resultados inválidos.
• Se os seus trabalhos são muito longos, então o Spot pode não ser um bom encaixe.
  • Para processos longos, tanto a possibilidade de despejo à vista como o dólar e os custos de tempo das retrógios aumentam.
  • No entanto, este é um caso que pode exigir uma medição caso a caso.

Despejo / Preempção

Consulte a Política de Despejo de Spot para obter detalhes sobre o despejo do Spot em Azure.

P. Pode cycleCloud rastrear despejos/preempções de instância do CycleCloud?

A. Sim. Um evento de despejo spot gerará uma notificação de Registo de Eventos na página de UI dos Clusters.

P. Como é que os utilizadores são notificados do despejo?

A. Depois de um nó CycleCloud ser despejado, os utilizadores verão uma mensagem de registo no registo de eventos do CycleCloud UI para o cluster. Os utilizadores também podem registar-se para receber um Evento do CycleCloud via Azure EventGrid depois de uma instância spot ser despejada.

• Os utilizadores podem verificar se há uma notificação de despejo na máquina 30 segundos antes do despejo. Consulte Eventos Agendados para saber como se registar para o evento.
• Em geral, o despejo deve ser considerado semelhante ao desligar uma máquina no local, e deve ser tratado da mesma forma.
• IMPORTANTE Os manipuladores de eventos não devem reconhecer o Evento de Despejo de Spot, uma vez que o manipulador de eventos Cyclecloud pode não receber o evento se for reconhecido.

P. Com que frequência ocorre o despejo?

A. A taxa de despejo é altamente variável e em grande parte dependente das alterações da procura em toda a região.

P. Por que os casos são despejados?

A. Os VM spot não garantem disponibilidade e podem ser despejados a qualquer momento. Consulte a documentação spot VM para mais detalhes. Se um nódearray tiver definido um MaxPrice , então os casos serão despejados se o preço do Spot subir acima do MaxPrice. Isto tende a ser raro , uma vez que o preço spot move-se muito lentamente. Eis alguns cenários que podem desencadear um despejo:

1. A redução da capacidade spot à medida que a procura de VMs prioritários regulares aumenta.
2. Eventos ao nível da plataforma, como manutenção planeada de hardware.

Como é que o meu fluxo de trabalho é afetado pelo despejo?

P. O que acontece com os meus trabalhos quando um caso spot é despejado?

A. A menos que os trabalhos sejam codificados para lidar com a notificação de despejo de 30 segundos e manuseá-la adequadamente, o nó é simplesmente encerrado e o trabalho é falhado (e espero que re-tentado).

P. Os nós são apagados do aglomerado?

A. Sim, os nós serão limpos no CycleCloud UI. Nos agendamentos apoiados, os nós também serão limpos no agendamento.

P. Os empregos têm de ser recandisso?

A. Em geral, compete ao programador re-tentar/re-executar os postos de trabalho que são despejados. No entanto, muitas classes de trabalho não são tolerantes a re-tentativas (por exemplo, se escreverem dados parciais para armazenamento persistente à medida que funcionam). Estes trabalhos podem não ser bons candidatos à execução em instâncias spot.

P. Posso usar uma mistura de Spot and On-Demand/Regular-Priority VMs?

A. Sim. Pode utilizar nodearrays separados spot (Interruptible) e non-Spot para criar uma mistura de Spot e Regular-Priority. A utilização de uma mistura de tipos de instância geralmente requer algumas decisões de configuração dependendo dos requisitos e do programador que o utilizador escolheu. Aqui estão algumas configurações comuns:

• Separados Spot e Regular-Priority VMs em filas separadas no agendador.
  • Esta configuração permite ao apresentador direcionar facilmente os trabalhos para o tipo VM apropriado
• Crie um único conjunto de recursos grandes com instâncias spot e Regular-Priority.
  • Esta configuração pode ser útil para cargas de trabalho altamente escaláveis que usam uma pequena percentagem de instâncias prioritárias regulares para garantir o progresso avançado e uma grande percentagem de Spot para reduzir custos e tempo de execução.

P. Posso alterar a política de despejo de pontos para os nodearrays do CycleCloud?

A. Sim. Pode definir o EvictionPolicy atributo diretamente no nó para alterar a política para um Delete ou Deallocate (predefinição: Delete). No entanto, atualmente, isto só é útil para autoescaladores personalizados que lidam com as transações adequadamente. Os atuais autoesscalers do Azure CycleCloud esperam que as instâncias spot sejam eliminadas após o despejo.

Suporte de programador para despejo de spot no CycleCloud

Consulte o guia específico do programador para obter informações detalhadas sobre a implementação do CycleCloud para o seu programador.

P. Como é que o autoscaler para o meu Scheduler lida com o despejo do Spot?

A. Todos os autoescaladores para os programadores incorporados/suportados (HTCondor, GridEngine, PBS Professional, Slurm, LSF) tentam lidar graciosamente com os despejos do Spot. Em geral, a instância despejada será removida do Programador e se a procura de capacidade for superior à nova capacidade disponível após o despejo, então o autoescalador substituirá a instância.

Os autoescaladores personalizados devem ser construídos para esperar despejos spot ou falhas gerais da máquina e manuseá-los graciosamente.

P. O que devo esperar que aconteça aos empregos que estavam a decorrer no caso dos despejos?

A. Isto cabe, em grande parte, ao utilizador configurar ao submeter o trabalho. Alguns programadores, como o GridEngine, permitem que a ação predefinida também seja configurada por fila. Por padrão, todas as implementações de programadores de CycleCloud incorporados, com exceção do HTCondor, são configuradas para marcar os trabalhos como falhados quando o nó em que estão a funcionar é despejado ou encerrado inesperadamente. Este comportamento é por design, uma vez que apenas o utilizador pode saber se os seus trabalhos podem ser novamente experimentados com segurança.