View a markdown version of this page

Noções básicas da estratégia e dos cenários de alocação de nós do Amazon EMR - Amazon EMR
Estratégia de alocação de nósConsiderações sobre alocação de nósCenários de alocação de nós

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á.

Noções básicas da estratégia e dos cenários de alocação de nós do Amazon EMR

Esta seção fornece uma visão geral da estratégia de alocação de nós e dos cenários comuns de ajuste de escala que você pode usar com o Ajuste de Escala Gerenciado do Amazon EMR.

Estratégia de alocação de nós

O Ajuste de Escala Gerenciado do Amazon EMR aloca nós centrais e de tarefa com base nas seguintes estratégias de aumento e redução da escala verticalmente:

Scale-up estratégia

  • Para as versões 7.2 e superiores do Amazon EMR, o ajuste de escala gerenciado primeiro adiciona nós com base nos rótulos dos nós e na propriedade do YARN de restrição do processo de aplicação.

  • Para as versões 7.2 e superiores do Amazon EMR, caso tenha habilitado rótulos de nós e restringido processos de aplicações a nós CORE, o Ajuste de Escala Gerenciado do Amazon EMR aumenta a escala verticalmente de nós centrais e os nós de tarefas se a demanda do processo da aplicação e a demanda do executor aumentarem. Da mesma forma, caso tenha habilitado os rótulos de nós e restringido os processos da aplicação aos nós ON_DEMAND, o ajuste de escala gerenciado ampliará verticalmente os nós sob demanda se a demanda do processo da aplicação aumentar e escalará os nós spot se a demanda do executor crescer.

  • Se os rótulos de nós não estiverem habilitados, o posicionamento do processo da aplicação não estará restrito a nenhum nó ou tipo de mercado.

  • Ao usar rótulos de nós, o ajuste de escala gerenciado pode aumentar e reduzir a escala verticalmente de diferentes grupos de instâncias e frotas de instâncias na mesma operação de redimensionamento. Por exemplo, em um cenário em que instance_group1 tem um nó ON_DEMAND e instance_group2 tem um nó SPOT, os rótulos dos nós estão habilitados e os processos da aplicação são restritos aos nós com o rótulo ON_DEMAND. O ajuste de escala gerenciado reduzirá a escala verticalmente de instance_group1 e aumentará a escala verticalmente de instance_group2 se a demanda do processo da aplicação diminuir e a demanda do executor aumentar.

  • Quando o Amazon EMR sofre um atraso ao aumentar a escala verticalmente com o grupo de instâncias atual, os clusters que usam o ajuste de escala gerenciado alternam automaticamente para outro grupo de instâncias de tarefa.

  • Se o parâmetro MaximumCoreCapacityUnits estiver definido, o Amazon EMR escalará os nós centrais até que as unidades centrais atinjam o limite máximo permitido. Toda a capacidade restante é adicionada aos nós de tarefa.

  • Se o MaximumOnDemandCapacityUnits parâmetro for definido, o Amazon EMR escalará o cluster usando as On-Demand Instâncias até que as On-Demand unidades atinjam o limite máximo permitido. Toda a capacidade restante é adicionada usando instâncias spot.

  • Se os parâmetros MaximumCoreCapacityUnits e MaximumOnDemandCapacityUnits estiverem definidos, o Amazon EMR considerará os dois limites durante o ajuste de escala.

    Por exemplo, se MaximumCoreCapacityUnits for menor que MaximumOnDemandCapacityUnits, o Amazon EMR primeiro escala os nós centrais até atingir o limite de capacidade do núcleo. Para a capacidade restante, o Amazon EMR primeiro usa On-Demand Instâncias para escalar nós de tarefas até que o On-Demand limite seja atingido e, em seguida, usa Instâncias Spot para nós de tarefas.

Scale-down estratégia

  • Semelhante à estratégia de aumento vertical da escala, o Amazon EMR remove nós com base nos rótulos dos nós. Para obter mais informações sobre os rótulos de nós, consulte Understand node types: primary, core, and task nodes.

  • Se você não habilitou os rótulos de nós, o ajuste de escala gerenciado remove os nós de tarefa e depois os nós centrais até alcançar a capacidade desejada de redução da escala verticalmente. O ajuste de escala gerenciado nunca reduz verticalmente a escala do cluster abaixo das restrições mínimas especificadas na política de ajuste de escala gerenciado.

  • O Amazon EMR 5.34.0 e versões posteriores e o Amazon EMR 6.4.0 e versões posteriores oferecem suporte ao reconhecimento de dados de shuffle do Spark, o que impede que a escala vertical de uma instância seja reduzida enquanto o ajuste de escala gerenciado reconhece dados de shuffle existentes. Para obter mais informações sobre operações de shuffle, consulte o Guia de programação do Spark. O Ajuste de escala gerenciado se esforça ao máximo para evitar reduzir a escala verticalmente de nós com dados de shuffle do estágio atual e anterior de qualquer aplicação Spark ativa por até um máximo de 30 minutos. Isso ajuda a minimizar a perda acidental de dados de shuffle, evitando a necessidade de repetir trabalhos e recalcular dados intermediários. No entanto, a prevenção da perda de dados de shuffle não é garantida. Para melhorar a proteção do Spark shuffle, recomendamos o reconhecimento aleatório em clusters com a etiqueta de versão 7.4 ou superior. Adicione os seguintes sinalizadores à configuração do cluster para ativar a proteção aprimorada do Spark shuffle.

    • Se o yarn.nodemanager.shuffledata-monitor.interval-ms sinalizador (padrão 30000 ms) ou o spark.dynamicAllocation.executorIdleTimeout (padrão 60 segundos) tiver sido alterado dos valores padrão, certifique-se de que a condição spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms permaneça true atualizando o sinalizador necessário.

      [
	{
		"Classification": "yarn-site",
		"Properties": { 
		"yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true"
		}
	},
	{
		"Classification": "spark-defaults",
		"Properties": {
		"spark.dynamicAllocation.enabled": "true",
		"spark.shuffle.service.removeShuffle": "true"
		}
	}
]

  • O ajuste de escala gerenciado primeiro remove os nós de tarefa e depois os nós centrais até alcançar a capacidade desejada de redução da escala verticalmente. O cluster jamais escala abaixo das restrições mínimas especificadas na política de ajuste de escala gerenciado.

  • Para clusters que são lançados com o Amazon EMR 5.x versões 5.34.0 e superiores e 6.x versões 6.4.0 e superiores, o Amazon EMR Managed Scaling não reduz a escala dos nós que existem ApplicationMaster para o Apache Spark, se houver estágios ativos nos aplicativos em execução neles. Isso minimiza falhas e novas tentativas de trabalho, o que ajuda a melhorar a performance do trabalho e reduzir custos. Para confirmar quais nós do cluster estão executando ApplicationMaster, acesse o Spark History Server e filtre o driver na guia Executores do ID da aplicação Spark.

  • Embora o ajuste de escala inteligente com o Ajuste de escala gerenciado do EMR minimize a perda de dados de shuffle para o Spark, pode haver casos em que dados de shuffle transitórios podem não ser protegidos durante tal redução. Para fornecer maior resiliência dos dados de shuffle durante a redução da escala vertical, recomendamos habilitar a opção de Desativação gradual para dados de shuffle no YARN. Quando a opção Desativação gradual para dados de shuffle estiver habilitada no YARN, os nós selecionados para redução de escala vertical que tenham dados de shuffle entrarão no estado de desativação e continuarão a fornecer arquivos de shuffle. O YARN ResourceManager espera até que os nós relatem a presença de arquivos aleatórios antes de remover os nós do cluster.

    • A versão 6.11.0 e superior do Amazon EMR oferece suporte ao Yarn-based descomissionamento normal dos dados do Hive shuffle para os manipuladores Tez e Shuffle. MapReduce

      • Habilite a Desativação gradual para dados de shuffle definindo yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data como true.

    • A versão 7.4.0 e superior do Amazon EMR oferecem suporte ao Yarn-based descomissionamento normal dos dados do Spark shuffle quando o serviço externo de reprodução aleatória está ativado (ativado por padrão no EMR no EC2).

      • O comportamento padrão do serviço de reprodução aleatória externa do Spark, ao executar o Spark no Yarn, é que o Yarn remova os arquivos aleatórios do aplicativo no NodeManager momento do encerramento do aplicativo. Isso pode ter um impacto na velocidade de descomissionamento dos nós e na utilização da computação. Para aplicações de longa execução, considere configurar spark.shuffle.service.removeShuffle como true para remover arquivos de shuffle que não estão mais em uso para permitir a desativação mais rápida de nós sem dados de shuffle ativos.

    • Para minimizar a perda de dados do Spark shuffle no Amazon EMR versão 7.4.0 e superior, considere definir as seguintes sinalizações.

      • Se o yarn.nodemanager.shuffledata-monitor.interval-ms sinalizador (padrão 30000 ms) ou o spark.dynamicAllocation.executorIdleTimeout (padrão 60 segundos) tiver sido alterado dos valores padrão, certifique-se de que a condição spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms permaneça true atualizando o sinalizador necessário.

        [
	{
		"Classification": "yarn-site",
		"Properties": { 
		"yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true"
		}
	},
	{
		"Classification": "spark-defaults",
		"Properties": {
		"spark.dynamicAllocation.enabled": "true",
		"spark.shuffle.service.removeShuffle": "true"
		}
	}
]

Se o cluster não tiver nenhuma carga, o Amazon EMR cancelará a adição de novas instâncias de uma avaliação anterior e executará operações de redução da escala verticalmente. Se o cluster tiver uma carga pesada, o Amazon EMR cancelará a remoção de instâncias e executará operações de aumento da escala verticalmente.

Considerações sobre alocação de nós

Recomendamos que você use a opção de On-Demand compra dos nós principais para evitar a perda de dados do HDFS em caso de recuperação do Spot. Você pode usar a opção de compra spot para nós de tarefa para reduzir custos e obter uma execução mais rápida do trabalho quando mais instâncias spot são adicionadas aos nós de tarefa.

Cenários de alocação de nós

Você pode criar vários cenários de escalabilidade com base em suas necessidades configurando os parâmetros Máximo, Mínimo, On-Demand Limite e Máximo do nó principal em combinações diferentes.

Cenário 1: escalar somente os nós centrais

Para escalar somente os nós centrais, os parâmetros do ajuste de escala gerenciado devem atender aos seguintes requisitos:

  • O On-Demand limite é igual ao limite máximo.

  • O nó central máximo é igual ao limite máximo.

Quando o On-Demand limite e os parâmetros máximos do nó central não são especificados, ambos os parâmetros usam como padrão o limite máximo.

Esse cenário não é aplicável se você usa ajuste de escala gerenciado com rótulos de nós e restringe os processos da aplicação para serem executados somente em nós CORE, porque o ajuste de escala gerenciado dimensiona os nós de tarefas para acomodar a demanda do executor.

Os exemplos a seguir demonstram o cenário de ajuste de escala somente para os nós centrais.

Estado inicial do cluster Parâmetros de escalabilidade Comportamento do ajuste de escala

Grupos de instâncias

Núcleo: 1 On-Demand

Tarefa: 1 On-Demand e 1 ponto

UnitType: instâncias

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 20

Escale entre 1 a 20 instâncias ou unidades da frota de instâncias nos nós principais usando o On-Demand tipo. Sem ajuste de escala nos nós de tarefa.

Ao usar o ajuste de escala gerenciado com rótulos de nós e restringir os processos da aplicação ao nós ON_DEMAND, o cluster escalará de 1 a 20 instâncias ou unidades da frota de instâncias em nós CORE usando o tipo On-Demand ou Spot, dependendo do tipo de demanda.

Frotas de instâncias

Núcleo: 1 On-Demand

Tarefa: 1 On-Demand e 1 ponto

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 20

Cenário 2: escalar somente nós de tarefa

Para escalar somente os nós de tarefa, os parâmetros do ajuste de escala gerenciado devem atender ao seguinte requisito:

  • O nó central máximo deve ser igual ao limite mínimo.

Os exemplos a seguir demonstram o cenário de ajuste de escala somente para os nós de tarefa.

Estado inicial do cluster Parâmetros de escalabilidade Comportamento do ajuste de escala

Grupos de instâncias

Núcleo: 2 On-Demand

De tarefa: uma spot

UnitType: instâncias

MinimumCapacityUnits: 2

MaximumCapacityUnits: 20

MaximumCoreCapacityUnits: 2

Mantenha os nós centrais estáveis em 2 e escale somente os nós de tarefa de 0 a 18 instâncias ou unidades da frota de instâncias. A capacidade entre os limites mínimo e máximo é adicionada somente aos nós de tarefa.

Ao usar o ajuste de escala gerenciado com rótulos de nós e restringir os processos da aplicação aos nós ON_DEMAND, o cluster mantém os nós centrais estáveis em 2 e só escala os nós de tarefa entre 0 a 18 instâncias ou unidades da frota de instâncias que usam o tipo On-demand ou Spot, dependendo do tipo de demanda.

Frotas de instâncias

Núcleo: 2 On-Demand

De tarefa: uma spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 2

MaximumCapacityUnits: 20

MaximumCoreCapacityUnits: 2

Cenário 3: Somente On-Demand instâncias no cluster

Para ter somente On-Demand instâncias, seu cluster e os parâmetros de escalabilidade gerenciados devem atender aos seguintes requisitos:

  • O On-Demand limite é igual ao limite máximo.

    Quando o On-Demand limite não é especificado, o valor do parâmetro assume como padrão o limite máximo. O valor padrão indica que o Amazon EMR escala somente On-Demand instâncias.

Se o nó central máximo for menor que o limite máximo, o parâmetro do nó central máximo poderá ser usado para dividir a alocação de capacidade entre os nós centrais e os nós de tarefa.

Para habilitar esse cenário em um cluster composto por grupos de instâncias, todos os grupos de nós no cluster devem usar o tipo de On-Demand mercado durante a configuração inicial.

Esse cenário não é aplicável se você usa o ajuste de escala gerenciado com rótulos de nós e restringe os processos da aplicação para serem executados somente em nós ON_DEMAND, porque o ajuste de escala gerenciado dimensiona os nós Spot para acomodar a demanda do executor.

Os exemplos a seguir demonstram o cenário de ter On-Demand instâncias em todo o cluster.

Estado inicial do cluster Parâmetros de escalabilidade Comportamento do ajuste de escala

Grupos de instâncias

Núcleo: 1 On-Demand

Tarefa: 1 On-Demand

UnitType: instâncias

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 12

Escale entre 1 a 12 instâncias ou unidades da frota de instâncias nos nós principais usando o On-Demand tipo. Dimensione a capacidade restante usando On-Demand nós de tarefas. Sem ajuste de escala usando instâncias spot.

Ao usar o ajuste de escala gerenciado com rótulos de nós e restringir os processos da aplicação aos nós CORE, o cluster escala entre 1 a 20 instâncias ou unidades da frota de instâncias em nós CORE ou task usando o tipo ON_DEMAND, dependendo do tipo de demanda. O ajuste de escala nos nós centrais não excederá 12 instâncias ou unidades da frota de instâncias.

Frotas de instâncias

Núcleo: 1 On-Demand

Tarefa: 1 On-Demand

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 12

Cenário 4: somente instâncias spot no cluster

Para ter somente instâncias spot, os parâmetros de ajuste de escala gerenciado devem atender aos seguintes requisitos:

  • On-Demand o limite é definido como 0.

Se o nó central máximo for menor que o limite máximo, o parâmetro do nó central máximo poderá ser usado para dividir a alocação de capacidade entre os nós centrais e os nós de tarefa.

Para habilitar esse cenário em um cluster composto por grupos de instâncias, o grupo de instâncias central deve usar a opção de compra spot durante a configuração inicial. Se não houver nenhuma instância spot no grupo de instâncias de tarefa, o Ajuste de Escala Gerenciado do Amazon EMR criará um grupo de tarefas usando instâncias spot quando necessário.

Esse cenário não é aplicável se você usa o ajuste de escala gerenciado com rótulos de nós e restringe os processos da aplicação para serem executados somente em nós ON_DEMAND, porque o ajuste de escala gerenciado dimensiona os nós ON_DEMAND para acomodar a demanda do processo da aplicação.

Os exemplos a seguir demonstram o cenário de ter instâncias spot em todo o cluster.

Estado inicial do cluster Parâmetros de escalabilidade Comportamento do ajuste de escala

Grupos de instâncias

Central: uma spot

De tarefa: uma spot

UnitType: instâncias

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 0

Escale de 1 a 20 instâncias ou unidades da frota de instâncias nos nós centrais usando spot. Sem escalonamento usando o On-Demand tipo.

Ao usar o ajuste de escala gerenciado com rótulos de nós e restringir os processos da aplicação aos nós CORE, o cluster escala entre 1 a 20 instâncias ou unidades da frota de instâncias em nós CORE ou TASK usando o spot, dependendo do tipo de demanda. O Amazon EMR não escala usando o tipo ON_DEMAND.

Frotas de instâncias

Central: uma spot

De tarefa: uma spot

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 0

Cenário 5: escalar On-Demand instâncias nos nós principais e instâncias spot nos nós de tarefas

Para escalar On-Demand instâncias em nós principais e instâncias spot em nós de tarefas, os parâmetros de escalabilidade gerenciada devem atender aos seguintes requisitos:

  • O On-Demand limite deve ser igual ao nó central máximo.

  • Tanto o On-Demand limite quanto o nó central máximo devem ser menores que o limite máximo.

Para habilitar esse cenário em um cluster composto por grupos de instâncias, o grupo de nós principais deve usar a opção On-Demand de compra.

Esse cenário não é aplicável se você usa o ajuste de escala gerenciado com rótulos de nós e restringe os processos da aplicação para serem executados somente em nós ON_DEMAND ou CORE.

Os exemplos a seguir demonstram o cenário de escalabilidade de On-Demand instâncias nos nós principais e instâncias spot nos nós de tarefas.

Estado inicial do cluster Parâmetros de escalabilidade Comportamento do ajuste de escala

Grupos de instâncias

Núcleo: 1 On-Demand

Tarefa: 1 On-Demand e 1 ponto

UnitType: instâncias

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 7

MaximumCoreCapacityUnits: 7

Expanda até 6 On-Demand unidades no nó principal, pois já existe 1 On-Demand unidade no nó da tarefa e o limite máximo On-Demand é 7. Depois escale até 13 unidades spot nos nós de tarefa.

Frotas de instâncias

Núcleo: 1 On-Demand

Tarefa: 1 On-Demand e 1 ponto

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 7

MaximumCoreCapacityUnits: 7

Cenário 6: escale as instâncias CORE para a demanda do processo da aplicação e as instâncias TASK para a demanda do executor.

Esse cenário só é aplicável se você usa o ajuste de escala gerenciado com rótulos de nós e restringe os processos da aplicação para serem executados somente em nós CORE.

Para escalar os nós CORE com base na demanda do processo da aplicação e os nós TASK com base na demanda do executor, você deve definir as seguintes configurações na inicialização do cluster:

  • yarn.node-labels.enabled:true

  • yarn.node-labels.am.default-node-label-expression: 'CORE'

Se você não especificar o limite de ON_DEMAND e os parâmetros máximos do nó CORE, ambos os parâmetros serão padronizados para o limite máximo.

Se o nó ON_DEMAND máximo for menor que o limite máximo, o ajuste de escala gerenciado usará o parâmetro do nó ON_DEMAND máximo para dividir a alocação de capacidade entre os nós ON_DEMAND e SPOT. Se você definir o parâmetro máximo do nó CORE como menor ou igual ao parâmetro de capacidade mínima, os nós CORE permanecerão estáticos na capacidade máxima do núcleo.

Os exemplos a seguir demonstram o cenário de ajuste de escala de instâncias CENTRAIS com base na demanda do processo da aplicação e de instâncias DE TAREFA com base na demanda do executor.

Estado inicial do cluster Parâmetros de escalabilidade Comportamento do ajuste de escala

Grupos de instâncias

Núcleo: 1 On-Demand

Tarefa: 1 On-Demand

UnitType: instâncias

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 10

MaximumCoreCapacityUnits: 20

Dimensiona os CORE nós entre 1 e 20 nós com base na demanda do processo de aplicação do cluster usando o tipo de mercado spot On-Demand ou spot. Escala os nós TASK com base na demanda do executor e na capacidade disponível restante após a alocação dos nós CORE pelo Amazon EMR.

A soma dos nós solicitados CORE e TASK não excederá a maximumCapacity de 20. A soma dos nós centrais sob demanda solicitados e dos nós de tarefas sob demanda não excederá maximumOnDemandCapacity de 10. Os nós centrais ou de tarefas adicionais usam o tipo de mercado spot.

Frotas de instâncias

Núcleo: 1 On-Demand

Tarefa: 1 On-Demand

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 10

MaximumCoreCapacityUnits: 20

Cenário 7: escale as instâncias ON_DEMAND para a demanda do processo da aplicação e as instâncias SPOT para a demanda do executor.

Esse cenário só é aplicável se você usa o ajuste de escala gerenciado com rótulos de nós e restringe os processos da aplicação para serem executados somente em nós ON_DEMAND.

Para escalar os nós ON_DEMAND com base na demanda do processo da aplicação e os nós SPOT com base na demanda do executor, você deve definir as seguintes configurações na inicialização do cluster:

  • yarn.node-labels.enabled:true

  • yarn.node-labels.am.default-node-label-expression: 'ON_DEMAND'

Se você não especificar o limite de ON_DEMAND e os parâmetros máximos do nó CORE, ambos os parâmetros serão padronizados para o limite máximo.

Se o nó CORE máximo for menor que o limite máximo, o ajuste de escala gerenciado usará o parâmetro do nó CORE máximo para dividir a alocação de capacidade entre os nós CORE e TASK. Se você definir o parâmetro máximo do nó CORE como menor ou igual ao parâmetro de capacidade mínima, os nós CORE permanecerão estáticos na capacidade máxima do núcleo.

Os exemplos a seguir demonstram o cenário de escalar On-Demand instâncias com base na demanda do processo de aplicação e instâncias spot com base na demanda do executor.

Estado inicial do cluster Parâmetros de escalabilidade Comportamento do ajuste de escala

Grupos de instâncias

Núcleo: 1 On-Demand

Tarefa: 1 On-Demand

UnitType: instâncias

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 10

Escala os nós ON_DEMAND entre 1 e 20 nós com base na demanda do processo da aplicação do cluster usando o tipo de nó CORE ou TASK. Escala os nós SPOT com base na demanda do executor e na capacidade disponível restante após a alocação dos nós ON_DEMAND pelo Amazon EMR.

A soma dos nós solicitados ON_DEMAND e SPOT não excederá a maximumCapacity de 20. A soma dos nós centrais sob demanda solicitados e dos nós centrais spot não excederá a maximumCoreCapacity de 10. Os nós sob demanda ou spot adicionais usam o tipo de nó TASK.

Frotas de instâncias

Núcleo: 1 On-Demand

Tarefa: 1 On-Demand

UnitType: InstanceFleetUnits

MinimumCapacityUnits: 1

MaximumCapacityUnits: 20

MaximumOnDemandCapacityUnits: 20

MaximumCoreCapacityUnits: 10