As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Estratégias de alocação dinâmica de nós do Slurm na versão 3.8.0
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 escala para nós dinâmicos é um processo de duas etapas, que envolve o lançamento das instâncias do EC2 e a atribuição das instâncias do Amazon EC2 lançadas aos nós do Slurm. Cada uma dessas duas etapas pode ser executada usando uma lógica all-or-nothingde melhor esforço.
Para o lançamento das instâncias do Amazon EC2:
-
all-or-nothingchama a API de lançamento do Amazon EC2 com meta mínima igual à capacidade alvo total
-
melhor esforço chama a API Amazon EC2 de lançamento com meta mínima igual a 1 e a capacidade total da meta igual à capacidade solicitada
Para atribuição de instâncias do Amazon EC2 aos nós Slurm:
-
all-or-nothingatribui instâncias do Amazon EC2 Slurm aos nós somente se for possível atribuir uma instância do Amazon EC2 a cada nó solicitado
-
melhor esforço atribui instâncias do Amazon EC2 aos nós do Slurm, mesmo que todos os nós solicitados não sejam cobertos pela capacidade da instância do Amazon EC2
As combinações possíveis das estratégias acima se traduzem nas estratégias de ParallelCluster lançamento.
exemplo
all-or-nothingdimensionamento:
Essa estratégia envolve AWS ParallelCluster iniciar uma chamada de API de instância de lançamento do Amazon EC2 para cada trabalho, o 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 instâncias do Amazon EC2 para cada job plus e uma all-or-nothinglógica para a atribuição das instâncias do Amazon EC2 aos nós. Slurm
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 programa de currículo do Slurm.
-
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 de limitação de API AWS do EC2. Para obter mais detalhes, consulte a documentação de limitação de API do Amazon EC2
-
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 inicialização do all-or-nothingEC2 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 all-or-nothingchamada da API de lançamento do Amazon EC2 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 lançamento do all-or-nothingAmazon EC2 não é suportada e ParallelCluster , em vez disso, executa o melhor esforço de escalabilidade.
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 lançamento do Amazon EC2 que visa uma capacidade mínima de destino 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 instâncias do EC2 para todos os trabalhos, além da all-or-nothinglógica para a atribuição das instâncias do Amazon EC2 aos Slurm nós de 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 ParellelCluster 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 chamada de API de instância de lançamento do Amazon EC2 visando uma capacidade mínima de 1 e buscando 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 instâncias do Amazon EC2 para todos os trabalhos, além da lógica de melhor esforço para a atribuição das instâncias do Amazon EC2 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, para um total de 40 nós do mesmo tipo, mas há apenas 30 instâncias do Amazon EC2 disponíveis para cobrir a capacidade solicitada no EC2.
all-or-nothingdimensionamento:
-
Para o primeiro trabalho, uma API de instância de lançamento do all-or-nothingAmazon EC2 é chamada, solicitando 20 instâncias. Uma chamada bem-sucedida resulta no lançamento de 20 instâncias
-
all-or-nothing a atribuição das 20 instâncias lançadas aos Slurm nós para o primeiro trabalho foi bem-sucedida
-
Outra API de instância de lançamento do all-or-nothingAmazon EC2 é 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:
-
Uma API de instância de execução de melhor esforço do Amazon EC2 é 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 aos Slurm nós para o primeiro trabalho foi bem-sucedida.
-
Outra all-or-nothingatribuição das instâncias lançadas restantes aos Slurm nós do segundo trabalho foi tentada, 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:
-
Uma API de instância de execução de melhor esforço do Amazon EC2 é 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 melhor esforço de 20 das instâncias lançadas aos nós do Slurm para o primeiro trabalho é bem-sucedida.
-
Outra atribuição de melhor esforço das 10 instâncias lançadas restantes aos nós do Slurm para o segundo trabalho é bem-sucedida, mesmo que a capacidade total solicitada seja 20. Mas como o trabalho estava solicitando os 20 nós e só era possível atribuir instâncias do Amazon EC2 a 10 deles, o trabalho não pode ser iniciado e as instâncias ficam ociosas até que capacidade suficiente seja encontrada para iniciar as outras 10 instâncias em uma chamada posterior do processo de escalabilidade ou até o agendador programar o trabalho em outros nós de computação já em execução.
