Slurm estratégias dinâmicas de alocação de nós na versão 3.8.0

PDFRSS

A partir da ParallelCluster versão 3.8.0, ParallelCluster usa o currículo no nível do trabalho ou o escalonamento no nível do trabalho como a estratégia padrão de alocação dinâmica de nós para ParallelCluster escalar o cluster: expande o cluster com base nos requisitos de cada trabalho, no número de nós alocados para o trabalho e nos nós que precisam ser retomados. ParallelCluster obtém essas informações da variável de ambiente SLURM_RESUME_FILE.

A escalabilidade para nós dinâmicos é um processo de duas etapas, que envolve o lançamento das EC2 instâncias e a atribuição das EC2 instâncias da Amazon lançadas ao Slurm nós. Cada uma dessas duas etapas pode ser executada usando uma lógica all-or-nothingde melhor esforço.

Para o lançamento das EC2 instâncias da Amazon:

• all-or-nothingchama a EC2 API de lançamento da Amazon com uma meta mínima igual à capacidade alvo total

• best effort chama o lançamento da EC2 API da Amazon com a meta mínima igual a 1 e a capacidade alvo total igual à capacidade solicitada

Para atribuição das EC2 instâncias da Amazon a Slurm nós:

• all-or-nothingatribui EC2 instâncias da Amazon a Slurm nós somente se for possível atribuir uma EC2 instância da Amazon a cada nó solicitado

• best effort atribui instâncias da Amazon EC2 a Slurm nós, mesmo que todos os nós solicitados não estejam cobertos pela capacidade da EC2 instância da Amazon

  As combinações possíveis das estratégias acima se traduzem nas estratégias de ParallelCluster lançamento.

The available ParallelCluster estratégias de lançamento that can be set into the ScalingStrategy cluster configuration to be used with escalabilidade em nível de trabalho are:

all-or-nothingdimensionamento:

Essa estratégia envolve AWS ParallelCluster iniciar uma chamada de API de instância de EC2 lançamento da Amazon para cada trabalho, que exige que todas as instâncias necessárias para que os nós de computação solicitados sejam executados com sucesso. Isso garante que o cluster seja escalado somente quando a capacidade necessária por trabalho estiver disponível, evitando instâncias ociosas deixadas no final do processo de escalabilidade.

A estratégia usa uma all-or-nothinglógica para o lançamento das EC2 instâncias da Amazon para cada trabalho e uma all-or-nothinglógica para a atribuição das EC2 instâncias da Amazon a Slurm nós.

Os grupos de estratégias iniciam solicitações em lotes, uma para cada recurso computacional solicitado e até 500 nós cada. Para solicitações que abrangem vários recursos computacionais ou excedem 500 nós, processa ParallelCluster sequencialmente vários lotes.

A falha do lote de um único recurso resulta no encerramento de toda a capacidade não utilizada associada, garantindo que nenhuma instância ociosa seja deixada no final do processo de escalabilidade.

Limitações

• O tempo necessário para escalar é diretamente proporcional ao número de trabalhos enviados por execução do Slurm programa de currículo.

• A operação de escalabilidade é limitada pelo limite da conta de RunInstances recursos, definido em 1.000 instâncias por padrão. Essa limitação está de acordo com as políticas AWS de limitação de EC2 API da Amazon. Para obter mais detalhes, consulte a documentação de limitação de EC2 API da Amazon

• Quando você envia um trabalho em um recurso computacional com um único tipo de instância, em uma fila que abrange várias zonas de disponibilidade, a chamada da API de all-or-nothing EC2lançamento só é bem-sucedida se toda a capacidade puder ser fornecida em uma única zona de disponibilidade.

• Quando você envia um trabalho em um recurso computacional com vários tipos de instância, em uma fila com uma única zona de disponibilidade, a chamada da API de EC2 lançamento da all-or-nothingAmazon só é bem-sucedida se toda a capacidade puder ser fornecida por um único tipo de instância.

• Quando você envia um trabalho em um recurso computacional com vários tipos de instância, em uma fila que abrange várias zonas de disponibilidade, a chamada da API de EC2 lançamento da all-or-nothingAmazon não é suportada e, em vez disso, ParallelCluster executa a escalabilidade de melhor esforço.

greedy-all-or-nothingdimensionamento:

Essa variante da all-or-nothing estratégia ainda garante que o cluster seja escalado somente quando a capacidade necessária por trabalho estiver disponível, evitando instâncias ociosas no final do processo de escalabilidade, mas envolve ParallelCluster iniciar uma chamada de API de instância de EC2 lançamento da Amazon que visa uma capacidade mínima alvo de 1, tentando maximizar o número de nós lançados até a capacidade solicitada. A estratégia usa uma lógica de melhor esforço para o lançamento das EC2 instâncias para todos os trabalhos, além da all-or-nothinglógica para a atribuição das instâncias da Amazon EC2 a Slurm nós para cada trabalho.

Os grupos de estratégias iniciam solicitações em lotes, uma para cada recurso computacional solicitado e até 500 nós cada. Para solicitações que abrangem vários recursos computacionais ou excedem 500 nós, o Parellelcluster processa sequencialmente vários lotes.

Ele garante que nenhuma instância seja deixada ociosa no final do processo de escalabilidade, maximizando o throughput ao custo da escalabilidade excessiva temporária durante o processo.

Limitações

• A escalabilidade excessiva temporária é possível, gerando custos adicionais para instâncias que fazem a transição para um estado de execução antes da conclusão da escalabilidade.

• O mesmo limite de instância da all-or-nothing estratégia se aplica, sujeito ao limite AWS da conta de RunInstances recursos da.

Escalabilidade de melhor esforço:

Essa estratégia chama a Amazon EC2 Launch Instance API call, visando uma capacidade mínima de 1 e visando atingir a capacidade total solicitada ao custo de deixar instâncias ociosas após a execução do processo de escalabilidade, caso nem toda a capacidade solicitada esteja disponível. A estratégia usa uma lógica de melhor esforço para o lançamento das EC2 instâncias da Amazon para todos os trabalhos, além da lógica de melhor esforço para a atribuição das EC2 instâncias da Amazon aos nós do Slurm para cada trabalho.

Os grupos de estratégias iniciam solicitações em lotes, uma para cada recurso computacional solicitado e até 500 nós cada. Para solicitações que abrangem vários recursos computacionais ou excedem 500 nós, processa ParallelCluster sequencialmente vários lotes.

Essa estratégia permite escalar muito além do limite padrão de 1.000 instâncias em várias execuções de processos de escalabilidade, ao custo de ter instâncias ociosas nos diferentes processos de escalabilidade.

Limitações

• Possíveis instâncias ociosas em execução no final do processo de escalabilidade, caso não seja possível alocar todos os nós solicitados pelos trabalhos.

Veja a seguir um exemplo que mostra como o dimensionamento dos nós dinâmicos se comporta usando as diferentes estratégias de ParallelCluster lançamento. Suponha que você tenha enviado dois trabalhos solicitando 20 nós cada, totalizando 40 nós do mesmo tipo, mas há apenas 30 EC2 instâncias da Amazon disponíveis para cobrir a capacidade solicitada. EC2

all-or-nothingdimensionamento:

• Para o primeiro trabalho, uma API de instância de EC2 lançamento da all-or-nothingAmazon é chamada, solicitando 20 instâncias. Uma chamada bem-sucedida resulta no lançamento de 20 instâncias

• all-or-nothing atribuição das 20 instâncias lançadas para Slurm os nós para o primeiro trabalho são bem-sucedidos

• Outra API de instância de EC2 lançamento da all-or-nothingAmazon é chamada, solicitando 20 instâncias para o segundo trabalho. A chamada não foi bem-sucedida, pois só há capacidade para outras 10 instâncias. Nenhuma instância foi iniciada no momento

greedy-all-or-nothingdimensionamento:

• A API de instância de EC2 lançamento da Amazon de melhor esforço é chamada, solicitando 40 instâncias, que é a capacidade total solicitada por todos os trabalhos. Isso resulta no lançamento de 30 instâncias

• Uma all-or-nothingatribuição de 20 das instâncias lançadas para Slurm os nós para o primeiro trabalho são bem-sucedidos

• Outra all-or-nothingatribuição das instâncias lançadas restantes para Slurm os nós do segundo trabalho foram testados, mas como há apenas 10 instâncias disponíveis do total de 20 solicitadas pelo trabalho, a atribuição não foi bem-sucedida

• As 10 instâncias lançadas não atribuídas são encerradas

Escalabilidade de melhor esforço:

• A API de instância de EC2 lançamento da Amazon de melhor esforço é chamada, solicitando 40 instâncias, que é a capacidade total solicitada por todos os trabalhos. Isso resulta no lançamento de 30 instâncias.

• Uma atribuição de 20 das instâncias lançadas ao melhor esforço possível para Slurm os nós para o primeiro trabalho são bem-sucedidos.

• Outra atribuição de grande esforço das 10 instâncias lançadas restantes para Slurm os nós para o segundo trabalho são bem-sucedidos, mesmo que a capacidade total solicitada tenha sido 20. Mas como o trabalho estava solicitando os 20 nós, e foi possível atribuir EC2 instâncias da Amazon a apenas 10 deles, o trabalho não pode ser iniciado e as instâncias ficam inativas, até que seja encontrada capacidade suficiente para iniciar as 10 instâncias ausentes em uma chamada posterior do processo de escalabilidade, ou o programador agenda o trabalho em outros nós de computação já em execução.