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.7.x
<a name="scheduler-dynamic-node-allocation-v3-3.7.x"></a>

ParallelCluster usa dois tipos de estratégias dinâmicas de alocação de nós para escalar o cluster:
+ 

**Alocação com base nas informações disponíveis do nó solicitado:**
  + **Retomada de todos os nós** ou escalabilidade da **lista de nós**:

    ParallelCluster aumenta o cluster com base somente nos nomes Slurm da lista de nós solicitada quando Slurm ele é `ResumeProgram` executado. Ele aloca recursos computacionais aos nós somente pelo nome do nó. A lista de nomes de nós pode se estender por vários trabalhos.
  + **Continuação em nível de trabalho** ou escalonamento **em nível de trabalho**:

    ParallelCluster aumenta o cluster com base nos requisitos de cada trabalho, no número atual 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 `SLURM_RESUME_FILE` ambiente.
+ 

**Alocação com uma estratégia de execução do Amazon EC2:**
  + Escalabilidade com o **melhor esforço**:

    ParallelCluster expande o cluster usando uma chamada de API de instância de execução do Amazon EC2 com a capacidade mínima de destino igual a 1, para iniciar algumas, mas não necessariamente todas, as instâncias necessárias para suportar os nós solicitados.
  + **Uma ll-or-nothing** escala:

    ParallelCluster aumenta a escala do cluster usando uma chamada de API de instância de execução do Amazon EC2 que só é bem-sucedida se todas as instâncias necessárias para suportar os nós solicitados forem iniciadas. Nesse caso, ele chama a API de instância de execução do Amazon EC2 com a capacidade mínima de destino igual à capacidade total solicitada.

Por padrão, ParallelCluster usa escalabilidade de **lista** de nós com a melhor estratégia de lançamento do **Amazon** EC2 para lançar algumas, mas não necessariamente todas, as instâncias necessárias para dar suporte aos nós solicitados. Ele tenta provisionar o máximo de capacidade possível para atender ao workload enviado.

**A partir da ParallelCluster versão 3.7.0, ParallelCluster usa escalabilidade em **nível de trabalho** com uma estratégia de lançamento do **all-or-nothing**EC2 para trabalhos enviados no modo exclusivo.** Quando você envia um trabalho em modo exclusivo, o trabalho tem acesso exclusivo aos nós alocados. Para obter mais informações, consulte [EXCLUSIVE](https://slurm.schedmd.com/slurm.conf.html#OPT_EXCLUSIVE) na documentação do Slurm.

Para enviar um trabalho no modo exclusivo:
+ Transmita o sinalizador exclusivo ao enviar um trabalho do Slurm para o cluster. Por exemplo, .`sbatch ... --exclusive`

  OU
+ Envie um trabalho para uma fila de cluster que tenha sido configurada com [`JobExclusiveAllocation`](Scheduling-v3.md#yaml-Scheduling-SlurmQueues-JobExclusiveAllocation) definido como `true`.

Ao enviar um trabalho no modo exclusivo:
+ ParallelCluster atualmente agrupa solicitações de lançamento em lotes para incluir até 500 nós. Se um trabalho solicitar mais de 500 nós, ParallelCluster faz uma solicitação de **all-or-nothing**inicialização para cada conjunto de 500 nós e uma solicitação de inicialização adicional para o restante dos nós.
+ Se a alocação de nós estiver em um único recurso computacional, ParallelCluster fará uma solicitação de **all-or-nothing**inicialização para cada conjunto de 500 nós e uma solicitação de inicialização adicional para o restante dos nós. Se uma solicitação de execução falhar, ParallelCluster encerrará a capacidade não utilizada que foi criada por todas as solicitações de execução.
+ Se a alocação de nós abranger vários recursos computacionais, será ParallelCluster necessário fazer uma solicitação de **all-or-nothing**lançamento para cada recurso computacional. Essas solicitações também são agrupadas. Se uma solicitação de inicialização falhar para um dos recursos computacionais, ParallelCluster a capacidade não utilizada criada por todas as solicitações de inicialização do recurso computacional será encerrada.

escalabilidade **em nível de trabalho** com limitações conhecidas da estratégia de **all-or-nothing**lançamento:
+ 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-nothing**EC2 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-nothing**chamada 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-nothing**Amazon EC2 não é suportada e ParallelCluster, em vez disso, executa o melhor esforço de escalabilidade.**