Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Comprendere la strategia e gli scenari di allocazione dei nodi di Amazon EMR
<a name="managed-scaling-allocation-strategy"></a>

In questa sezione viene fornita una panoramica della strategia di allocazione dei nodi e degli scenari di dimensionamento comuni che è possibile utilizzare con il dimensionamento gestito da Amazon EMR. 

## Strategia di assegnazione dei nodi
<a name="node-allocation-strategy"></a>

Il dimensionamento gestito da Amazon EMR assegna nodi core e attività in base alle seguenti strategie di aumento e riduzione: 

**Scale-up strategia**
+ Per le versioni 7.2 e successive di Amazon EMR, la scalabilità gestita aggiunge innanzitutto i nodi in base alle etichette dei nodi e alla proprietà YARN di restrizione del processo applicativo. 
+ Per le release 7.2 e successive di Amazon EMR, se hai abilitato le etichette dei nodi e i processi applicativi limitati ai nodi`CORE`, la scalabilità gestita di Amazon EMR aumenta la scalabilità verso i nodi core e i nodi task se la domanda dei processi applicativi aumenta e la domanda degli esecutori aumenta. Allo stesso modo, se sono state abilitate le etichette dei nodi e i processi applicativi sono limitati ai `ON_DEMAND` nodi, la scalabilità gestita aumenta i nodi su richiesta se la domanda del processo applicativo aumenta e aumenta i nodi spot se aumenta la domanda degli esecutori.
+ Se le etichette dei nodi non sono abilitate, il posizionamento dei processi applicativi non è limitato a nessun tipo di nodo o mercato.
+ Utilizzando le etichette dei nodi, la scalabilità gestita può aumentare e ridimensionare diversi gruppi di istanze e flotte di istanze nella stessa operazione di ridimensionamento. Ad esempio, in uno scenario in cui `instance_group1` ha un `ON_DEMAND` nodo e `instance_group2` ha un `SPOT` nodo e le etichette dei nodi sono abilitate e i processi applicativi sono limitati ai nodi con l'etichetta. `ON_DEMAND` La scalabilità gestita si ridurrà `instance_group1` e aumenterà `instance_group2` se la domanda dei processi applicativi diminuisce e la domanda degli esecutori aumenta. 
+ Quando Amazon EMR subisce un ritardo nel dimensionamento verticale rispetto al gruppo di istanze corrente, i cluster che utilizzano il dimensionamento gestito passano automaticamente a un gruppo di istanze di attività diverso.
+ Se hai impostato il parametro `MaximumCoreCapacityUnits`, Amazon EMR ridimensiona i nodi principali fino a quando le unità principali non raggiungono il limite massimo consentito. La capacità rimanente viene aggiunta ai nodi attività. 
+ Se il `MaximumOnDemandCapacityUnits` parametro è impostato, Amazon EMR ridimensiona il cluster utilizzando le On-Demand istanze fino a quando le On-Demand unità raggiungono il limite massimo consentito. La capacità rimanente viene aggiunta utilizzando istanze Spot. 
+ Se hai impostato entrambi i parametri `MaximumCoreCapacityUnits` e `MaximumOnDemandCapacityUnits`, Amazon EMR considera entrambi i limiti durante il dimensionamento. 

  Ad esempio, se l'opzione `MaximumCoreCapacityUnits` è minore di `MaximumOnDemandCapacityUnits`, Amazon EMR ridimensiona innanzitutto i nodi principali fino al raggiungimento del limite di capacità principale. Per la capacità residua, Amazon EMR utilizza prima On-Demand le istanze per scalare i nodi di attività fino al raggiungimento del On-Demand limite, quindi utilizza le istanze Spot per i nodi di attività. 

**Scale-down strategia**
+ Analogamente alla strategia di scalabilità verticale, Amazon EMR rimuove i nodi in base alle etichette dei nodi. Per ulteriori informazioni sulle etichette dei nodi, consulta [Comprendere i tipi di nodi: nodi primari, principali e](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html) nodi di attività.
+ Se non hai abilitato le etichette dei nodi, la scalabilità gestita rimuove i nodi di attività e quindi rimuove i nodi principali fino a raggiungere la capacità target di scalabilità verso il basso desiderata. La scalabilità gestita non riduce mai il cluster al di sotto dei vincoli minimi specificati nella politica di scalabilità gestita. 
+ Le versioni 5.34.0 e successive di Amazon EMR e le versioni 6.4.0 e successive di Amazon EMR supportano il riconoscimento dei dati shuffle di Spark, che impedisce la scalabilità verso il basso di un'istanza mentre Managed Scaling è a conoscenza dei dati shuffle esistenti. Per ulteriori informazioni sulle operazioni di shuffle, consulta la [Guida di programmazione Spark](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations). Managed Scaling fa del suo meglio per evitare che i nodi vengano ridimensionati in modo casuale, con dati provenienti dalla fase corrente e precedente di qualsiasi applicazione Spark attiva, fino a un massimo di 30 minuti. Questo aiuta a ridurre al minimo la perdita involontaria dei dati provenienti dallo shuffle, evitando la necessità di ripetere i tentativi di lavoro e il ricalcolo dei dati intermedi. Tuttavia, la prevenzione della perdita di dati in modalità shuffle non è garantita. Per una migliore protezione da Spark Shuffle, consigliamo di riconoscere lo shuffle su cluster con etichetta di release 7.4 o superiore. Aggiungi i seguenti flag alla configurazione del cluster per abilitare una migliore protezione Spark shuffle.
  + Se il `yarn.nodemanager.shuffledata-monitor.interval-ms` flag (predefinito 30000 ms) o il `spark.dynamicAllocation.executorIdleTimeout` (predefinito 60 sec) sono stati modificati rispetto ai valori predefiniti, assicurati che la condizione `spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms` rimanga aggiornata `true` aggiornando il flag necessario.

    ```
    [
    	{
    		"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"
    		}
    	}
    ]
    ```
+ La scalabilità gestita rimuove prima i nodi di attività e poi i nodi principali fino a raggiungere la capacità target di scalabilità verso il basso desiderata. Il cluster non scende mai al di sotto dei vincoli minimi specificati nella politica di scalabilità gestita.
+ Per i cluster lanciati con Amazon EMR 5.x release 5.34.0 e successive e 6.x versioni 6.4.0 e successive, Amazon EMR Managed Scaling non ridimensiona i nodi con `ApplicationMaster` Apache Spark, se sono presenti fasi attive nelle applicazioni in esecuzione su di essi. Ciò riduce al minimo gli errori e i nuovi tentativi del processo, il che aiuta a migliorare le prestazioni lavorative e a ridurre i costi. Per confermare su quali nodi del cluster è in esecuzione `ApplicationMaster`, visita Spark History Server e filtra i driver nella scheda **Esecutori** dell'ID applicazione Spark.
+ Sebbene la scalabilità intelligente con EMR Managed Scaling riduca al minimo la perdita di dati shuffle per Spark, in alcuni casi i dati shuffle transitori potrebbero non essere protetti durante uno scale-down. **Per fornire una maggiore resilienza dei dati shuffle durante lo scale-down, consigliamo di abilitare Graceful Decommissioning for Shuffle Data in YARN.** **Quando **Graceful Decommissioning for Shuffle Data è abilitato in YARN, i nodi selezionati per lo scale-down con dati shuffle** entreranno nello stato Decommissioning e continueranno a servire i file shuffle.** YARN attende che i nodi segnalino l'assenza di file ResourceManager shuffle prima di rimuovere i nodi dal cluster.
  + La versione 6.11.0 e successive di Amazon EMR supportano lo smantellamento Yarn-based graduale dei dati **Hive** shuffle per i gestori Tez e Shuffle. MapReduce 
    + Abilita Graceful `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data` Decommissioning `true` for Shuffle Data impostando su.
  + Amazon EMR versione 7.4.0 e successive supportano lo smantellamento Yarn-based graduale dei dati Spark shuffle quando il servizio shuffle esterno è abilitato (abilitato per impostazione predefinita in EMR su EC2).
    + Il comportamento predefinito del servizio shuffle esterno Spark, quando si esegue Spark su Yarn, prevede che Yarn rimuova i file shuffle delle applicazioni al momento della chiusura dell'applicazione. NodeManager Ciò può avere un impatto sulla velocità di disattivazione dei nodi e sull'utilizzo del calcolo. Per le applicazioni con esecuzione prolungata, valuta la possibilità di `spark.shuffle.service.removeShuffle` `true` impostare la rimozione dei file shuffle non più in uso per consentire una più rapida disattivazione dei nodi senza dati shuffle attivi.
  + Per ridurre al minimo la perdita di dati Spark shuffle in Amazon EMR versione 7.4.0 e successive, prendi in considerazione l'impostazione dei seguenti flag.
    + Se il `yarn.nodemanager.shuffledata-monitor.interval-ms` flag (predefinito 30000 ms) o il `spark.dynamicAllocation.executorIdleTimeout` (predefinito 60 sec) è stato modificato rispetto ai valori predefiniti, assicurati che la condizione `spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms` rimanga aggiornata aggiornando il flag necessario. `true`

      ```
      [
      	{
      		"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 il cluster non ha alcun carico, Amazon EMR annulla l'aggiunta di nuove istanze da una valutazione precedente ed esegue operazioni di dimensionamento verso il basso. Se il cluster presenta un carico pesante, Amazon EMR annulla la rimozione delle istanze ed esegue operazioni di aumento.

## Considerazioni sull'assegnazione
<a name="node-allocation-considerations"></a>

Ti consigliamo di utilizzare l'opzione di On-Demand acquisto per i nodi principali per evitare la perdita di dati HDFS in caso di recupero di Spot. È possibile utilizzare l'opzione di acquisto Spot per i nodi attività al fine di ridurre i costi e ottenere un'esecuzione più rapida dei processi quando vengono aggiunte più istanze Spot ai nodi attività.

## Scenari di assegnazione dei nodi
<a name="node-allocation-scenarios"></a>

È possibile creare vari scenari di scalabilità in base alle proprie esigenze impostando i parametri dei nodi principali Massimo, Minimo, On-Demand Limite e Massimo in diverse combinazioni. 

**Scenario 1: Dimensionare i soli nodi principali**

Per ridimensionare solo i nodi principali, i parametri di dimensionamento gestiti devono soddisfare i seguenti requisiti: 
+ Il On-Demand limite è uguale al limite massimo.
+ Il nodo principale massimo è uguale al limite massimo. 

Quando il On-Demand limite e i parametri massimi del nodo principale non sono specificati, entrambi i parametri utilizzano per impostazione predefinita il limite massimo. 

Questo scenario non è applicabile se si utilizza la scalabilità gestita con etichette dei nodi e si limita l'esecuzione dei processi applicativi solo sui `CORE` nodi, poiché la scalabilità gestita ridimensiona i nodi delle attività per soddisfare la domanda degli esecutori.

I seguenti esempi dimostrano lo scenario di dimensionamento dei nodi principali.


<table>
<thead>
  <tr><th>Stato iniziale del cluster</th><th>Parametri di dimensionamento</th><th>Comportamento del dimensionamento</th></tr>
</thead>
<tbody>
  <tr><td>**Gruppi di istanze**<br />Nucleo: 1 On-Demand<br />Compito: 1 On-Demand e 1 Spot</td><td>`UnitType`: Istanze<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20 <br />`MaximumCoreCapacityUnits`: 20</td><td rowspan="2">Scala da 1 a 20 istanze o unità del parco istanze sui nodi principali utilizzando il On-Demand tipo. Nessun dimensionamento sui nodi attività.<br />Quando utilizzi la scalabilità gestita con etichette di nodi e limiti i processi applicativi ai `ON_DEMAND` nodi, il cluster scalerà da 1 a 20 istanze o unità del parco istanze sui `CORE` nodi utilizzando il `Spot` tipo `On-Demand` o, a seconda del tipo di domanda.</td></tr>
  <tr><td>**Parchi istanze**<br />Nucleo: 1 On-Demand<br />Compito: 1 On-Demand e 1 Spot</td><td>UnitType: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20 <br />`MaximumCoreCapacityUnits`: 20</td></tr>
</tbody>
</table>


**Scenario 2: Dimensionamento dei soli nodi attività **

Per ridimensionare solo i nodi attività, i parametri di dimensionamento gestiti devono soddisfare il seguente requisito: 
+ Il nodo principale massimo è uguale al limite minimo.

I seguenti esempi dimostrano lo scenario di dimensionamento dei nodi attività.


<table>
<thead>
  <tr><th>Stato iniziale del cluster</th><th>Parametri di dimensionamento</th><th>Comportamento del dimensionamento</th></tr>
</thead>
<tbody>
  <tr><td>**Gruppi di istanze**<br />Nucleo: 2 On-Demand<br />Attività: 1 Spot</td><td>`UnitType`: Istanze<br />`MinimumCapacityUnits` 2:<br />`MaximumCapacityUnits`: 20<br />`MaximumCoreCapacityUnits` 2:</td><td rowspan="2">Mantenimento dei nodi principali a 2 e dimensionamento dei soli nodi attività da 0 a 18 istanze o unità di parchi istanze. La capacità tra i limiti minimo e massimo viene aggiunta solo ai nodi attività.<br /> Quando si utilizza la scalabilità gestita con etichette dei nodi e si limitano i processi applicativi ai nodi ON\_DEMAND, il cluster mantiene invariati i nodi principali su 2 e ridimensiona i nodi di attività solo tra 0 e 18 istanze o unità del parco istanze che utilizzano il tipo or, a seconda del `On-demand` `Spot` tipo di domanda. </td></tr>
  <tr><td>**Parchi istanze**<br />Nucleo: 2 On-Demand<br />Attività: 1 Spot</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits` 2:<br />`MaximumCapacityUnits`: 20<br />`MaximumCoreCapacityUnits` 2:</td></tr>
</tbody>
</table>


**Scenario 3: solo On-Demand istanze nel cluster**

Per avere solo On-Demand istanze, il cluster e i parametri di scalabilità gestita devono soddisfare i seguenti requisiti: 
+ Il On-Demand limite è uguale al limite massimo. 

  Quando il On-Demand limite non è specificato, il valore predefinito del parametro è il limite massimo. Il valore predefinito indica che Amazon EMR ridimensiona solo le istanze. On-Demand 

Se il nodo principale massimo è inferiore al limite massimo, è possibile utilizzare il parametro nodo principale massimo per dividere l'assegnazione della capacità tra nodi principali e nodi attività. 

Per abilitare questo scenario in un cluster composto da gruppi di istanze, tutti i gruppi di nodi del cluster devono utilizzare il tipo di On-Demand mercato durante la configurazione iniziale. 

Questo scenario non è applicabile se si utilizza la scalabilità gestita con etichette dei nodi e si limita l'esecuzione dei processi applicativi solo sui `ON_DEMAND` nodi, poiché la scalabilità gestita ridimensiona i `Spot` nodi per soddisfare la domanda degli esecutori.

Gli esempi seguenti illustrano lo scenario di presenza di On-Demand istanze nell'intero cluster.


<table>
<thead>
  <tr><th>Stato iniziale del cluster</th><th>Parametri di dimensionamento</th><th>Comportamento del dimensionamento</th></tr>
</thead>
<tbody>
  <tr><td>**Gruppi di istanze**<br />Nucleo: 1 On-Demand<br />Compito: 1 On-Demand </td><td>`UnitType`: Istanze<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20 <br />`MaximumCoreCapacityUnits`: 12</td><td rowspan="2">Scala da 1 a 12 istanze o unità del parco istanze sui nodi principali utilizzando On-Demand type. Scala la capacità residua utilizzando On-Demand i nodi di attività. Nessun dimensionamento utilizzando istanze Spot.<br /> Quando si utilizza la scalabilità gestita con etichette di nodi e si limitano i processi applicativi ai soli `CORE` nodi, il cluster viene scalato da 1 a 20 istanze o unità del parco istanze su `CORE` nodi o `task` nodi che utilizzano il `ON_DEMAND` tipo, a seconda del tipo di domanda. La scalabilità sui nodi principali non supererà le 12 istanze o unità del parco istanze. </td></tr>
  <tr><td>**Parchi istanze**<br />Nucleo: 1 On-Demand<br />Compito: 1 On-Demand</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20 <br />`MaximumCoreCapacityUnits`: 12</td></tr>
</tbody>
</table>


**Scenario 4: Solo istanze Spot nel cluster**

Per avere solo istanze Spot, i parametri di dimensionamento gestito devono soddisfare i requisiti seguenti: 
+ On-Demand il limite è impostato su 0.

Se il nodo principale massimo è inferiore al limite massimo, è possibile utilizzare il parametro nodo principale massimo per dividere l'assegnazione della capacità tra nodi principali e nodi attività.

Per abilitare questo scenario in un cluster composto da gruppi di istanze, il gruppo di istanze principale deve utilizzare l'opzione acquisto Spot durante la configurazione iniziale. Se non è presente alcuna istanza spot nel gruppo di istanze attività, il dimensionamento gestito da Amazon EMR crea un gruppo di attività utilizzando le istanze spot quando necessario. 

Questo scenario non è applicabile se si utilizza la scalabilità gestita con etichette dei nodi e si limita l'esecuzione dei processi applicativi solo sui `ON_DEMAND` nodi, poiché la scalabilità gestita ridimensiona i `ON_DEMAND` nodi per soddisfare la domanda dei processi applicativi.

Negli esempi seguenti viene illustrato lo scenario che presenta istanze Spot nell'intero cluster.


<table>
<thead>
  <tr><th>Stato iniziale del cluster</th><th>Parametri di dimensionamento</th><th>Comportamento del dimensionamento</th></tr>
</thead>
<tbody>
  <tr><td>**Gruppi di istanze**<br />Principale: 1 Spot<br />Attività: 1 Spot</td><td>`UnitType`: Istanze<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 0</td><td rowspan="2">Dimensionamento da 1 a 20 istanze o unità di parchi istanze sui nodi principali utilizzando il tipo Spot. Nessun ridimensionamento utilizzando il tipo. On-Demand<br />Quando si utilizza la scalabilità gestita con etichette di nodi e si limitano i processi applicativi ai soli `CORE` nodi, il cluster viene scalato da 1 a 20 istanze o unità del parco istanze su `CORE` o `TASK` nodi che utilizzano Spot, a seconda del tipo di domanda. Amazon EMR non è scalabile utilizzando questo tipo. `ON_DEMAND`</td></tr>
  <tr><td>**Parchi istanze**<br />Principale: 1 Spot<br />Attività: 1 Spot</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 0</td></tr>
</tbody>
</table>


**Scenario 5: scalabilità On-Demand delle istanze sui nodi principali e istanze Spot sui nodi delle attività**

Per scalare On-Demand le istanze sui nodi principali e le istanze Spot sui nodi delle attività, i parametri di scalabilità gestiti devono soddisfare i seguenti requisiti: 
+ Il On-Demand limite deve essere uguale al numero massimo di nodi principali.
+ Sia il On-Demand limite che il nodo centrale massimo devono essere inferiori al limite massimo.

Per abilitare questo scenario in un cluster composto da gruppi di istanze, il gruppo di nodi principali deve utilizzare l'opzione On-Demand di acquisto.

Questo scenario non è applicabile se si utilizza la scalabilità gestita con etichette di nodi e si limita l'esecuzione dei processi applicativi solo su `ON_DEMAND` nodi o `CORE` nodi. 

Gli esempi seguenti illustrano lo scenario di scalabilità delle On-Demand istanze sui nodi principali e delle istanze Spot sui nodi delle attività.


<table>
<thead>
  <tr><th>Stato iniziale del cluster</th><th>Parametri di dimensionamento</th><th>Comportamento del dimensionamento</th></tr>
</thead>
<tbody>
  <tr><td>**Gruppi di istanze**<br />Nucleo: 1 On-Demand<br />Compito: 1 On-Demand e 1 Spot</td><td>`UnitType`: Istanze<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 7 <br />`MaximumCoreCapacityUnits`: 7</td><td rowspan="2">Scala fino a 6 On-Demand unità sul nodo principale poiché c'è già 1 On-Demand unità nel nodo attività e il limite massimo per On-Demand è 7. In seguito, aumento a 13 unità Spot sui nodi attività.</td></tr>
  <tr><td>**Parchi istanze**<br />Nucleo: 1 On-Demand<br />Compito: 1 On-Demand e 1 Spot</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 7<br />`MaximumCoreCapacityUnits`: 7</td></tr>
</tbody>
</table>


**Scenario 6: scalare `CORE` le istanze per la domanda dei processi applicativi e `TASK` le istanze per la domanda degli esecutori.**

Questo scenario è applicabile solo se si utilizza la scalabilità gestita con etichette dei nodi e si limita l'esecuzione dei processi applicativi solo sui nodi. `CORE`

Per scalare `CORE` i nodi in base alla richiesta del processo applicativo e `TASK` i nodi in base alla domanda degli esecutori, è necessario impostare le seguenti configurazioni all'avvio del cluster:
+  `yarn.node-labels.enabled:true` 
+  `yarn.node-labels.am.default-node-label-expression: 'CORE'` 

Se non si specificano il `ON_DEMAND` limite e i parametri massimi del `CORE` nodo, entrambi i parametri utilizzano per impostazione predefinita il limite massimo.

Se il `ON_DEMAND` nodo massimo è inferiore al limite massimo, la scalabilità gestita utilizza il parametro del `ON_DEMAND` nodo massimo per suddividere l'allocazione della capacità tra i nodi. `ON_DEMAND` `SPOT` Se si imposta il parametro del `CORE` nodo massimo su un valore inferiore o uguale al parametro di capacità minima, `CORE` i nodi rimangono statici alla capacità core massima.

Gli esempi seguenti illustrano lo scenario di scalabilità delle istanze CORE in base alla domanda dei processi applicativi e delle istanze TASK in base alla domanda dell'esecutore.


<table>
<thead>
  <tr><th>Stato iniziale del cluster</th><th>Parametri di dimensionamento</th><th>Comportamento del dimensionamento</th></tr>
</thead>
<tbody>
  <tr><td>**Gruppi di istanze**<br />Nucleo: 1 On-Demand<br />Compito: 1 On-Demand</td><td>`UnitType`: Istanze<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 10<br />`MaximumCoreCapacityUnits`: 20</td><td rowspan="2">Scala i `CORE` nodi tra 1 e 20 nodi in base alla richiesta del processo applicativo del cluster utilizzando il tipo di mercato On-Demand o Spot. Ridimensiona i `TASK` nodi in base alla domanda dell'esecutore e alla capacità disponibile residua dopo l'allocazione dei nodi da parte di Amazon EMR. `CORE`<br />La somma delle richieste `CORE` e dei `TASK` nodi non supererà il valore di 20. `maximumCapacity` La somma dei nodi principali su richiesta e dei nodi di attività su richiesta non supererà il numero `maximumOnDemandCapacity` di 10. I nodi core o task aggiuntivi utilizzano il tipo di mercato Spot. </td></tr>
  <tr><td>**Parchi istanze**<br />Nucleo: 1 On-Demand<br />Compito: 1 On-Demand</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 10<br />`MaximumCoreCapacityUnits`: 20</td></tr>
</tbody>
</table>


**Scenario 7: scalare `ON_DEMAND` le istanze per la domanda dei processi applicativi e `SPOT` le istanze per la domanda degli esecutori.**

Questo scenario è applicabile solo se si utilizza la scalabilità gestita con etichette dei nodi e si limita l'esecuzione dei processi applicativi solo sui nodi. `ON_DEMAND`

Per scalare `ON_DEMAND` i nodi in base alla richiesta del processo applicativo e `SPOT` i nodi in base alla domanda degli esecutori, è necessario impostare le seguenti configurazioni all'avvio del cluster:
+  `yarn.node-labels.enabled:true` 
+  `yarn.node-labels.am.default-node-label-expression: 'ON_DEMAND'` 

Se non si specificano il `ON_DEMAND` limite e i parametri massimi del `CORE` nodo, entrambi i parametri utilizzano per impostazione predefinita il limite massimo.

Se il `CORE` nodo massimo è inferiore al limite massimo, la scalabilità gestita utilizza il parametro del `CORE` nodo massimo per suddividere l'allocazione della capacità tra i nodi. `CORE` `TASK` Se si imposta il parametro del `CORE` nodo massimo su un valore inferiore o uguale al parametro di capacità minima, `CORE` i nodi rimangono statici alla capacità core massima.

Gli esempi seguenti illustrano lo scenario di scalabilità delle On-Demand istanze in base alla domanda del processo applicativo e delle istanze Spot in base alla domanda dell'esecutore.


<table>
<thead>
  <tr><th>Stato iniziale del cluster</th><th>Parametri di dimensionamento</th><th>Comportamento del dimensionamento</th></tr>
</thead>
<tbody>
  <tr><td>**Gruppi di istanze**<br />Nucleo: 1 On-Demand<br />Compito: 1 On-Demand</td><td>`UnitType`: Istanze<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20<br />`MaximumCoreCapacityUnits`: 10</td><td rowspan="2">Ridimensiona i `ON_DEMAND` nodi tra 1 e 20 nodi in base alla richiesta del processo applicativo del cluster utilizzando il tipo di `TASK` nodo `CORE` or. Ridimensiona i `SPOT` nodi in base alla domanda dell'esecutore e alla capacità disponibile residua dopo l'allocazione dei nodi da parte di Amazon EMR. `ON_DEMAND`<br />La somma delle richieste `ON_DEMAND` e dei `SPOT` nodi non supererà il valore di 20. `maximumCapacity` La somma dei nodi core on-demand richiesti e dei nodi core spot non supererà il valore `maximumCoreCapacity` di 10. I nodi on-demand o spot aggiuntivi utilizzano il tipo di `TASK` nodo. </td></tr>
  <tr><td>**Parchi istanze**<br />Nucleo: 1 On-Demand<br />Compito: 1 On-Demand</td><td>`UnitType`: InstanceFleetUnits<br />`MinimumCapacityUnits`: 1<br />`MaximumCapacityUnits`: 20<br />`MaximumOnDemandCapacityUnits`: 20<br />`MaximumCoreCapacityUnits`: 10</td></tr>
</tbody>
</table>