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à. # Errori di risorse durante le operazioni del cluster Amazon EMR I seguenti errori sono comunemente causati da risorse vincolate sul cluster. La guida descrive ogni errore e fornisce assistenza per la risoluzione dei problemi. **Topics** + [Il cluster Amazon EMR termina con NO\$1SLAVE\$1LEFT e i nodi principali FAILED\$1BY\$1MASTER](emr-cluster-NO_SLAVE_LEFT-FAILED_BY_MASTER.md) + [Errore del cluster Amazon EMR: impossibile replicare il blocco, è riuscito a replicare solo su zero nodi.](enough-hdfs-space.md) + [Errore del cluster Amazon EMR: QUOTA EC2 SUPERATA](emr-EC2.md) + [Errore del cluster Amazon EMR: troppi errori di fetch](emr-troubleshoot-error-resource-1.md) + [Errore del cluster Amazon EMR: il file può essere replicato solo su 0 nodi anziché su 1](emr-troubleshoot-error-resource-2.md) + [Errore del cluster Amazon EMR: nodi con elenco negato](emr-troubleshoot-error-resource-3.md) + [Errori di limitazione con un cluster Amazon EMR](emr-throttling-error.md) + [Errore del cluster Amazon EMR: tipo di istanza non supportato](emr-INSTANCE_TYPE_NOT_SUPPORTED-error.md) + [Errore del cluster Amazon EMR: la capacità di EC2 è esaurita](emr-EC2_INSUFFICIENT_CAPACITY-error.md) + [Errore del cluster Amazon EMR: errore del fattore di replica HDFS](emr-hdfs-insufficient-replication.md) + [Errore del cluster Amazon EMR: errore di spazio HDFS insufficiente](emr-hdfs-insufficient-space.md) # Il cluster Amazon EMR termina con NO\$1SLAVE\$1LEFT e i nodi principali FAILED\$1BY\$1MASTER In genere, ciò accade perché la protezione da cessazione è disabilitata e tutti i nodi principali superano la capacità di storage su disco come specificato da una soglia di utilizzo massimo nella classificazione di configurazione `yarn-site`, che corrisponde al file `yarn-site.xml`. Per impostazione predefinita, questo valore è 90%. Quando l'utilizzo del disco per un nodo principale supera la soglia di utilizzo, il servizio sanitario YARN segnala il nodo come. NodeManager `UNHEALTHY` Mentre è in questo stato, Amazon EMR elenca come negato il nodo e non assegna i container YARN a tale nodo. Se il nodo rimane nello stato non integro per 45 minuti, Amazon EMR contrassegna l'istanza Amazon EC2 associata per la terminazione come `FAILED_BY_MASTER`. Quando tutte le istanze Amazon EC2 associate con i nodi principali sono contrassegnate per la terminazione, il cluster viene terminato con lo stato `NO_SLAVE_LEFT` perché non vi sono risorse per l'esecuzione dei processi. Il superamento dell'utilizzo del disco su un nodo principali potrebbe causare una reazione a catena. Se un singolo nodo supera la soglia di utilizzo del disco a causa di HDFS, è probabile che anche altri nodi siano vicini alla soglia. Il primo nodo supera la soglia di utilizzo del disco, quindi Amazon EMR lo elenca come negato. Ciò aumenta il carico di utilizzo del disco per i nodi rimanenti perché questi iniziano a replicare tra loro i dati HDFS che hanno perso sul nodo elencato come negato. Di conseguenza, ogni nodo diventa `UNHEALTHY` nello stesso modo e infine il cluster viene terminato. ## Best practice e raccomandazioni ### Configurazione di hardware cluster con archiviazione adeguata Quando crei un cluster, accertati che vi sia un numero sufficiente di nodi principali e che ogni nodo disponga di volumi adeguati di storage EBS e instance store per HDFS. Per ulteriori informazioni, consulta [Calcolo della capacità HDFS richiesta di un cluster](emr-plan-instances-guidelines.md#emr-plan-instances-hdfs). Puoi inoltre aggiungere istanze principali ai gruppi di istanze esistenti manualmente o utilizzando il dimensionamento automatico. Le nuove istanze hanno la stessa configurazione di storage delle altre istanze nel gruppo di istanze. Per ulteriori informazioni, consulta [Usa la scalabilità dei cluster Amazon EMR per adattarti ai carichi di lavoro in continua evoluzione](emr-scale-on-demand.md). ### Abilitare la protezione da cessazione Abilita la protezione da cessazione. In questo modo, se un nodo principale è elencato come negato, puoi connetterti all'istanza Amazon EC2 associata utilizzando SSH per risolvere i problemi relativi ai dati e recuperare i dati. Se abiliti la protezione da cessazione, ricorda che Amazon EMR non sostituisce l'istanza Amazon EC2 con una nuova istanza. Per ulteriori informazioni, consulta [Utilizzo della protezione dalle terminazioni per proteggere i cluster Amazon EMR da arresti accidentali](UsingEMR_TerminationProtection.md). ### Crea un allarme per la metrica Nodes MRUnhealthy CloudWatch Questo parametro indica il numero di nodi con stato `UNHEALTHY`. È equivalente al parametro YARN `mapred.resourcemanager.NoOfUnhealthyNodes`. Puoi impostare una notifica per questo allarme in modo che ti vengano segnalati i nodi non integri prima che venga raggiunto il timeout di 45 minuti. Per ulteriori informazioni, consulta [Monitoraggio dei parametri di Amazon EMR con CloudWatch](UsingEMR_ViewingMetrics.md). ### Impostazioni Tweak mediante yarn-site Le impostazioni riportate di seguito possono essere regolate in base ai requisiti dell'applicazione. Ad esempio, potresti voler aumentare la soglia di utilizzo del disco in base alla quale un nodo segnala lo stato `UNHEALTHY` aumentando il valore di `yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage`. Puoi impostare questi valori quando crei un cluster utilizzando la classificazione di configurazione `yarn-site`. Per ulteriori informazioni, consulta [Configurazione delle applicazioni](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) nella *Guida ai rilasci di Amazon EMR*. Puoi inoltre connetterti alle istanze Amazon EC2 associate ai nodi principali tramite SSH, quindi aggiungere i valori in `/etc/hadoop/conf.empty/yarn-site.xml` utilizzando un editor di testo. Dopo aver apportato la modifica, è necessario riavviare hadoop-yarn-nodemanager come illustrato di seguito. **Importante** Quando si riavvia il NodeManager servizio, i contenitori YARN attivi vengono eliminati a meno che non `yarn.nodemanager.recovery.enabled` sia impostato l'`true`utilizzo della classificazione di `yarn-site` configurazione al momento della creazione del cluster. Devi inoltre specificare la directory in cui memorizzare lo stato del container utilizzando la proprietà `yarn.nodemanager.recovery.dir`. ``` sudo /sbin/stop hadoop-yarn-nodemanager sudo /sbin/start hadoop-yarn-nodemanager ``` Per ulteriori informazioni sulle proprietà `yarn-site` correnti e i valori predefiniti, consulta la [pagina delle impostazioni predefinite di YARN](http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-common/yarn-default.xml) nella documentazione di Apache Hadoop. | Proprietà | Valore predefinito | Description | | --- | --- | --- | | yarn.nodemanager. disk-health-checker.intervallo-ms | 120000 | La frequenza (in secondi) con cui viene eseguito il controllo dello stato del disco. | | yarn.nodemanager. disk-health-checker. min-healthy-disks | 0.25 | La frazione minima del numero di dischi che devono essere integri per NodeManager poter avviare nuovi contenitori. Ciò corrisponde sia a yarn.nodemanager.local-dirs (per impostazione predefinita `/mnt/yarn` in Amazon EMR) che a yarn.nodemanager.log-dirs (per impostazione predefinita `/var/log/hadoop-yarn/containers`, del quale è eseguito il symlink a `mnt/var/log/hadoop-yarn/containers` in Amazon EMR). | | `yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage` | 90,0 | La percentuale massima di utilizzo dello spazio su disco consentita dopo che un disco viene contrassegnato come difettoso. I valori possono andare da 0,0 a 100,0. Se il valore è maggiore o uguale a 100, NodeManager verifica la presenza di un disco completo. Ciò è valido per `yarn-nodemanager.local-dirs` e `yarn.nodemanager.log-dirs`. | | `yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb` | 0 | Lo spazio minimo che deve essere disponibile su un disco affinché possa essere utilizzato. Ciò è valido per `yarn-nodemanager.local-dirs` e `yarn.nodemanager.log-dirs`. | # Errore del cluster Amazon EMR: impossibile replicare il blocco, è riuscito a replicare solo su zero nodi. Generalmente, l'errore "Cannot replicate block, only managed to replicate to zero nodes (Impossibile replicare il blocco, gestito solo per la replica su zero nodi)." si verifica quando un cluster non dispone di sufficiente spazio di archiviazione HDFS. Questo errore si verifica quando la quantità di dati generata nel cluster è superiore alla capacità di archiviazione di HDFS. Questo errore viene visualizzato solo durante l'esecuzione del cluster in quanto quando termina il processo rilascia lo spazio HDFS che stava utilizzando. La quantità di spazio HDFS disponibile per un cluster dipende dal numero e dal tipo di istanze Amazon EC2 che vengono utilizzate come nodi principali. I nodi di task non vengono utilizzati per lo storage HDFS. L'intero spazio su disco di ciascuna istanza Amazon EC2, inclusi i volumi di archiviazione EBS associati, è disponibile per HDFS. Per ulteriori informazioni sulla quantità di storage locale per ogni tipo di istanza EC2, consulta [Tipi e famiglie di istanze](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) nella *Amazon EC2* User Guide. L'altro fattore che può influenzare la quantità di spazio HDFS disponibile è il fattore di replica, ovvero il numero di copie di ciascun blocco di dati che viene archiviato in HDFS per la ridondanza. Il fattore di replica aumenta con il numero di nodi nel cluster: sono disponibili 3 copie di ogni blocco di dati per un cluster con 10 o più nodi, 2 copie di ogni blocco per un cluster con un numero di nodi da 4 a 9 e 1 copia (nessuna ridondanza) per i cluster con al massimo 3 nodi. Lo spazio HDFS totale disponibile è diviso per il fattore di replica. In alcuni casi, ad esempio incrementando il numero di nodi da 9 a 10, l'aumento del fattore di replica può causare effettivamente la diminuzione della quantità di spazio HDFS disponibile. Ad esempio, per un cluster con 10 nodi principali di tipo m1.xlarge sarebbero disponibili 2833 GB di spazio in HDFS ((10 nodi x 850 GB per nodo)/fattore di replica 3). Se le dimensioni del cluster superano la quantità di spazio disponibile per HDFS, puoi aggiungere altri nodi principali nel cluster o utilizzare la compressione dati per creare più spazio HDFS. Se il cluster può essere interrotto e riavviato, puoi valutare il ricorso ai nodi principali di un tipo di istanza Amazon EC2 più grande. Puoi anche valutare la modifica del fattore di replica. Tiene presente, tuttavia, che la riduzione del fattore di replica riduce la ridondanza dei dati HDFS e la capacità del cluster di recuperare da blocchi HDFS persi o danneggiati. # Errore del cluster Amazon EMR: QUOTA EC2 SUPERATA Se viene visualizzato un messaggio `EC2 QUOTA EXCEEDED`, le cause potrebbero essere diverse. A seconda della differenze di configurazione, potrebbero essere necessari tra i 5 e i 20 minuti affinché i cluster precedenti vengano terminati e le risorse allocate rilasciate. Se visualizzi un errore `EC2 QUOTA EXCEEDED` al tentativo di avvio di un cluster, potrebbe essere dovuto al rilascio non ancora avvenuto delle risorse di un terminato recentemente. Questo messaggio può anche essere causato dal ridimensionamento di un gruppo di istanze o di un parco istanze in una dimensione di destinazione maggiore della quota di istanza corrente per l'account. Questa operazione può essere eseguita manualmente o automaticamente attraverso il dimensionamento automatico. Considera le seguenti opzioni per risolvere il problema: + Segui le istruzioni in [Service Quotas di AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) in *Riferimenti generali di Amazon Web Services* per richiedere un aumento dei limiti del servizio. Per alcuni APIs, l'impostazione di un CloudWatch evento potrebbe essere un'opzione migliore rispetto all'aumento dei limiti. Per ulteriori dettagli, consultare [Quando configurare gli eventi EMR in CloudWatch](emr-service-limits-cloudwatch-events.md). + Se uno o più cluster in esecuzione non hanno capacità, ridimensiona i gruppi di istanze o riduci le capacità di destinazione sui parchi istanze per l'esecuzione di cluster. + Crea i cluster con un numero minore di istanze EC2 o una capacità di destinazione ridotta. # Errore del cluster Amazon EMR: troppi errori di fetch La presenza di messaggi di errore "**Too many fetch-failures (Troppi errori fetch)**" o "**Error reading task output (Errore di lettura output attività)**" nella fase o nei log del tentativo di attività indica che l'attività in esecuzione dipende dall'output di un'altra attività. Ciò si verifica spesso quando un'attività di riduzione viene accodata per l'esecuzione e richiede l'output di una o più attività di mappatura e tale output non è ancora disponibile. L'output potrebbe non essere disponibile per diversi motivi: + L'attività preliminare è ancora in fase di elaborazione. Questa è spesso un'attività di mappatura. + I dati potrebbero non essere disponibili a causa di scarsa connettività di rete se i dati si trovano su un'istanza diversa. + Se si utilizza HDFS per recuperare l'output, potrebbe verificarsi un problema con HDFS. La causa più comune di questo errore è che l'attività precedente è ancora in corso di elaborazione. Ciò è probabile soprattutto se gli errori si verificano durante il primo tentativo di esecuzione delle attività di riduzione. Puoi verificare se questo è il motivo esaminando il log syslog per la fase di cluster che restituisce l'errore. Se il syslog mostra che entrambe le attività di mappatura e riduzione stanno avanzando, significa che la fase di riduzione è iniziata mentre ci sono attività di mappatura non ancora completate. Ti consigliamo di cercare nei log una percentuale di avanzamento della mappatura che raggiunge il 100% e quindi scende nuovamente a un valore più basso. Quando la percentuale di mappatura è pari al 100%, questo non significa che tutte le attività di mappatura sono state completate, ma semplicemente che Hadoop sta eseguendo tutte le attività di mappatura. Se questo valore scende nuovamente sotto il 100%, significa che un'attività di mappatura non è riuscita e, a seconda della configurazione, Hadoop potrebbe tentare di pianificare di nuovo l'attività. Se la percentuale della mappa rimane al 100% nei log, esamina le CloudWatch metriche, in particolare`RunningMapTasks`, per verificare se l'attività della mappa è ancora in fase di elaborazione. Puoi anche trovare queste informazioni utilizzando l'interfaccia Web Hadoop sul nodo master. Se si verifica questo problema, puoi provare a eseguire una serie di operazioni: + Configura la fase di riduzione per aspettare più a lungo prima dell'avvio. A questo scopo, puoi modificare l'impostazione di configurazione Hadoop mapred.reduce.slowstart.completed.maps su un tempo più lungo. Per ulteriori informazioni, consulta [Crea azioni di bootstrap per installare software aggiuntivo con un cluster Amazon EMR](emr-plan-bootstrap.md). + Associa il conteggio del riduttore alla funzionalità del riduttore totale del cluster. A questo scopo, modifica l'impostazione di configurazione Hadoop mapred.reduce.tasks per il processo. + Utilizza un codice classe combiner per ridurre al minimo la quantità di output da recuperare. + Verifica che non ci siano problemi con il servizio Amazon EC2 che influenzano le prestazioni di rete del cluster. A questo scopo, puoi utilizzare il [Service Health Dashboard](https://status.aws.amazon.com/). + Esamina le risorse di CPU e della memoria delle istanze nel cluster per verificare che l'elaborazione dei dati non stia sovraccaricando le risorse dei nodi. Per ulteriori informazioni, consulta [Configurazione dell'hardware e della rete del cluster Amazon EMR](emr-plan-instances.md). + Controlla la versione di Amazon Machine Image (AMI) utilizzata nel cluster Amazon EMR. Se la versione è compresa tra 2.3.0 e 2.4.4, esegui l'aggiornamento a una versione più recente. Le versioni AMI nell'intervallo specificato utilizzano una versione di Jetty che potrebbe non essere in grado di fornire l'output dalla fase di mappatura. L'errore di recupero si verifica quando i riduttori non sono in grado di ottenere l'output dalla fase di mappatura. Jetty è un server HTTP open source utilizzato per le comunicazioni da macchina a macchina all'interno di un cluster Hadoop. # Errore del cluster Amazon EMR: il file può essere replicato solo su 0 nodi anziché su 1 Un file scritto in HDFS viene replicato in più nodi principali. Quando viene visualizzato questo errore, significa che il NameNode demone non dispone di DataNode istanze disponibili su cui scrivere dati in HDFS. In altre parole, la replica dei blocchi non viene eseguita. Questo errore può essere causato da diversi problemi: + Possibile mancanza di spazio libero per il filesystem HDFS. Questa è la causa più probabile. + DataNode le istanze potrebbero non essere disponibili al momento dell'esecuzione del processo. + DataNode le istanze potrebbero essere state bloccate dalla comunicazione con il nodo master. + Istanze non disponibili nel gruppo di istanze principale. + Possibile mancanza di autorizzazioni. Ad esempio, il JobTracker demone potrebbe non disporre delle autorizzazioni necessarie per creare informazioni sul job tracker. + L'impostazione dello spazio riservato per un' DataNode istanza potrebbe essere insufficiente. Controlla se questo è il caso verificando l'impostazione di configurazione dfs.datanode.du.reserved. Per verificare se questo problema è causato dall'esaurimento dello spazio su disco di HDFS, guarda la `HDFSUtilization` metrica in. CloudWatch Se questo valore è troppo elevato, puoi aggiungere altri nodi principali al cluster. Se hai un cluster che pensi possa esaurire lo spazio su disco HDFS, puoi impostare un allarme CloudWatch per avvisarti quando il valore di `HDFSUtilization` supera un certo livello. Per ulteriori informazioni, consultare [Ridimensiona manualmente un cluster Amazon EMR in esecuzione](emr-manage-resize.md) e [Monitoraggio dei parametri di Amazon EMR con CloudWatch](UsingEMR_ViewingMetrics.md). Se l'esaurimento dello spazio su HDFS non era il problema, controllate i log, DataNode i NameNode log e la connettività di rete per verificare la presenza di altri problemi che avrebbero potuto impedire a HDFS di replicare i dati. Per ulteriori informazioni, consulta [Visualizza i file di log di Amazon EMR](emr-manage-view-web-log-files.md). # Errore del cluster Amazon EMR: nodi con elenco negato Il NodeManager daemon è responsabile del lancio e della gestione dei container sui nodi core e task. I contenitori vengono allocati al NodeManager demone dal demone in esecuzione sul nodo ResourceManager master. ResourceManager Monitora il nodo tramite un battito cardiaco. NodeManager Ci sono un paio di situazioni in cui il ResourceManager daemon deny elenca a NodeManager, rimuovendolo dal pool di nodi disponibili per elaborare le attività: + Se non NodeManager ha inviato un heartbeat al ResourceManager demone negli ultimi 10 minuti (600.000 millisecondi). Questo periodo di tempo può essere configurato utilizzando l'impostazione di configurazione `yarn.nm.liveness-monitor.expiry-interval-ms`. Per ulteriori informazioni sulla modifica delle classificazioni di configurazione Yarn, consulta la sezione relativa alla [Configurazione delle applicazioni](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) nella *Guida ai rilasci di Amazon EMR*. + NodeManager controlla lo stato dei dischi determinato da e. `yarn.nodemanager.local-dirs` `yarn.nodemanager.log-dirs` I controlli includono le autorizzazioni e lo spazio libero su disco (< 90%). Se un disco non supera il controllo, NodeManager smette di utilizzare quel particolare disco ma riporta comunque lo stato del nodo come integro. Se più dischi non superano il controllo, il nodo viene segnalato come non integro ResourceManager e i nuovi contenitori non vengono assegnati al nodo. Il master dell'applicazione può anche negare l'elenco di un NodeManager nodo se presenta più di tre attività non riuscite. Puoi modificare questa impostazione su un valore più alto utilizzando il parametro di configurazione `mapreduce.job.maxtaskfailures.per.tracker`. Altre impostazioni di configurazione che è possibile modificare sono il numero di tentativi di esecuzione di una task prima che venga contrassegnata come non riuscita: `mapreduce.map.max.attempts` per task di mappatura e `mapreduce.reduce.maxattempts` per task di riduzione. Per ulteriori informazioni sulla modifica delle classificazioni di configurazione, consulta la sezione relativa alla [Configurazione delle applicazioni](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) nella *Guida ai rilasci di Amazon EMR*. # Errori di limitazione con un cluster Amazon EMR Gli errori «Throttled from *Amazon EC2* while launching cluster» e «Failed to provisioning delle istanze a causa della limitazione da» si verificano *Amazon EC2* quando Amazon EMR non è in grado di completare una richiesta perché un altro servizio ha limitato l'attività. Amazon EC2 è la fonte più comune di errori di limitazione, ma non è l'unica. I [limiti del servizio AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) sono specifici in base alla Regione e servono a migliorare le prestazioni; infatti, un errore di limitazione indica a un utente che ha superato i limiti del servizio per il suo account in una specifica Regione. ## Possibili cause L'origine più comune degli errori di limitazione di Amazon EC2 è il numero elevato di istanze cluster avviate che porta al superamento del limite del servizio per le istanze EC2. Le istanze cluster possono essere avviate per i seguenti motivi: + Vengono creati nuovi cluster. + I cluster vengono ridimensionati manualmente. Per ulteriori informazioni, consulta [Ridimensiona manualmente un cluster Amazon EMR in esecuzione](emr-manage-resize.md). + I gruppi di istanze in un cluster aggiungono istanze (ridimensionamento) come risultato di una regola di ridimensionamento automatico. Per ulteriori informazioni, consulta [Comprensione delle regole di scalabilità automatica](emr-automatic-scaling.md#emr-scaling-rules). + I parchi istanze in un cluster aggiungono le istanze per soddisfare una maggiore capacità di destinazione. Per ulteriori informazioni, consulta [Pianificazione e configurazione di flotte di istanze per il tuo cluster Amazon EMR](emr-instance-fleet.md). È anche possibile che la frequenza o il tipo di richiesta API ad Amazon EC2 causi errori di limitazione. Per ulteriori informazioni su come Amazon EC2 limita le richieste API, consulta [Tasso delle richieste API sulle query](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/query-api-troubleshooting.html#api-request-rate) nella *Guida di riferimento alle API di Amazon EC2*. ## Soluzioni Prendi in considerazione le soluzioni seguenti: + Segui le istruzioni in [Service Quotas di AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) in *Riferimenti generali di Amazon Web Services* per richiedere un aumento dei limiti del servizio. Per alcuni APIs, organizzare un CloudWatch evento potrebbe essere un'opzione migliore rispetto all'aumento dei limiti. Per ulteriori dettagli, consultare [Quando configurare gli eventi EMR in CloudWatch](emr-service-limits-cloudwatch-events.md). + Se disponi di cluster che si avviano con la stessa pianificazione, ad esempio all'inizio di ogni ora, puoi aspettarti tempi di avvio straordinari. + Se disponi di cluster dimensionati per la domanda di picco e hai periodicamente la capacità di istanza, considera la possibilità di specificare il ridimensionamento automatico per aggiungere e rimuovere le istanze on demand. In questo modo, le istanze vengono utilizzate in modo più efficiente e, in base al profilo della domanda, è possibile richiedere un numero inferiore di istanze in un dato momento in un account. Per ulteriori informazioni, consulta [Utilizzo del ridimensionamento automatico con una politica personalizzata, ad esempio gruppi in Amazon EMR](emr-automatic-scaling.md). # Errore del cluster Amazon EMR: tipo di istanza non supportato Se crei un cluster e non riesci a visualizzare il messaggio di errore «Il tipo di istanza richiesto non *InstanceType* è supportato nella zona di disponibilità richiesta», significa che hai creato il cluster e specificato un tipo di istanza per uno o più gruppi di istanze che non è supportato da Amazon EMR nella regione e nella zona di disponibilità in cui è stato creato il cluster. Amazon EMR è in grado di supportare un tipo di istanza in una zona di disponibilità all'interno di una Regione ma non in un'altra. La sottorete selezionata per un cluster determina la zona di disponibilità all'interno della regione. ## Soluzione **Determina i tipi di istanze disponibili in una zona di disponibilità utilizzando il AWS CLI** + Utilizza il comando `ec2 run-instances` con l’opzione `--dry-run`. Nell'esempio seguente, sostituisci *m5.xlarge* con il tipo di istanza che desideri utilizzare, *ami-035be7bafff33b6b6* con l'AMI associato a quel tipo di istanza e *subnet-12ab3c45* con una sottorete nella zona di disponibilità che desideri interrogare. ``` aws ec2 run-instances --instance-type m5.xlarge --dry-run --image-id ami-035be7bafff33b6b6 --subnet-id subnet-12ab3c45 ``` Per istruzioni su come trovare un ID AMI, consulta [Ricerca di un'AMI Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/finding-an-ami.html). Per trovare un ID di sottorete, puoi utilizzare il comando [describe-subnets](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-subnets.html). Per ulteriori informazioni su come scoprire i tipi di istanza disponibili, consulta [Individuazione di un tipo di istanza Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html). Dopo aver determinato i tipi di istanza disponibili, è possibile eseguire una delle operazioni seguenti: + Crea il cluster nella stessa regione e sottorete EC2 e seleziona un tipo di istanza diverso con funzionalità simili a quelle della scelta iniziale. Per una lista di tipi di istanze supportate, consulta [Tipi di istanze supportati con Amazon EMR](emr-supported-instance-types.md). Per confrontare le caratteristiche dei tipi di istanza EC2, consulta la sezione sui [tipi di istanza Amazon EC2](https://aws.amazon.com/ec2/instance-types/). + Scegli una sottorete per il cluster in una zona di disponibilità in cui il tipo di istanza è disponibile e supportato da Amazon EMR. **Riduci gli errori di avvio del cluster della flotta di istanze a causa di tipi di istanze primarie non supportati in Amazon EMR** I nodi primari sono essenziali nei cluster Amazon EMR. L'avvio di un cluster EMR potrebbe non riuscire con un `instance type not supported` errore in cui Amazon EMR tenta di avviare il cluster in una zona di disponibilità se il tipo di istanza principale non è supportato. La selezione avanzata della zona di disponibilità, ad esempio i cluster di flotte in Amazon EMR, filtra automaticamente le istanze AZs non supportate per i tipi di istanze principali specificati nella configurazione del cluster. Ciò significa che Amazon EMR non sceglierà una zona di disponibilità in cui i tipi di istanza primarie configurati non siano supportati, il che impedisce errori di avvio del cluster a causa di tipi di istanze non supportati. Per consentire questo miglioramento, aggiungi l'autorizzazione richiesta al ruolo o alla policy di servizio per il tuo cluster. L'ultima versione di `AmazonEMRServicePolicy_v2` include questa autorizzazione, quindi se si utilizza tale politica, il miglioramento è già disponibile. Se utilizzi un ruolo o un criterio di servizio personalizzato, aggiungi l'autorizzazione all'`ec2:DescribeInstanceTypeOfferings`avvio del cluster. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "ec2:DescribeInstanceTypeOfferings" ], "Effect": "Allow", "Resource": [ "*" ], "Sid": "AllowEC2Describeinstancetypeofferings" } ] } ``` ------ # Errore del cluster Amazon EMR: la capacità di EC2 è esaurita Un *EC2 è fuori capacità perché* si verifica un *InstanceType* errore quando si tenta di creare un cluster o di aggiungere istanze a un cluster in una zona di disponibilità che non ha più il tipo di istanza EC2 specificato. La sottorete selezionata per un cluster determina la zona di disponibilità. Per creare un cluster, effettua una delle operazioni indicate di seguito: + Specifica un diverso tipo di istanza con funzionalità simili + Crea il cluster in una Regione diversa + Seleziona una sottorete in una zona di disponibilità in cui potrebbe essere disponibile il tipo di istanza che desideri. Per aggiungere istanze a un cluster in esecuzione, effettua una delle seguenti operazioni: + Modifica le configurazioni dei gruppi di istanze o le configurazioni dei parchi istanze per aggiungere tipi di istanze disponibili con capacità simili. Per una lista di tipi di istanze supportate, consulta [Tipi di istanze supportati con Amazon EMR](emr-supported-instance-types.md). Per confrontare le caratteristiche dei tipi di istanza EC2, consulta la sezione sui [tipi di istanza Amazon EC2](https://aws.amazon.com/ec2/instance-types/). + Termina il cluster e ricrealo in una Regione e in una zona di disponibilità in cui è disponibile il tipo di istanza. # Errore del cluster Amazon EMR: errore del fattore di replica HDFS Quando rimuovi un nodo principale da un [gruppo di istanze](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-uniform-instance-group.html) principali o da una [flotta di istanze](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-fleet.html), Amazon EMR potrebbe riscontrare un errore di replica HDFS. Questo errore si verifica quando rimuovi i nodi principali e il numero di nodi principali scende al di sotto del [fattore dfs.replication](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html) configurato per l'Hadoop Distributed File System (HDFS). Pertanto, Amazon EMR non è in grado di eseguire l'operazione in sicurezza. Per determinare il valore predefinito della `dfs.replication` configurazione, configurazione [HDFS](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html). ## Possibili cause Di seguito sono riportate le possibili cause dell'errore del fattore di replica HDFS: + Se si [ridimensiona manualmente](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-resize.html) un gruppo di istanze principale o un parco di istanze al di sotto del fattore configurato. `dfs.replication` + Le tue politiche per la [scalabilità gestita o la scalabilità](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) [automatica](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-automatic-scaling.html) potrebbero consentire la scalabilità per ridurre il numero di nodi principali al di sotto della soglia di. `dfs.replication` + Questo errore può verificarsi anche se Amazon EMR tenta di [sostituire](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-node-replacement.html) un nodo centrale non integro quando un cluster ha il numero minimo di nodi core definito da. []() ## Soluzioni e best practice Per le soluzioni e le best practice, consulta quanto segue: + Quando ridimensionate manualmente un cluster Amazon EMR, non ridimensionatelo al di sotto, `dfs.replication` poiché Amazon EMR non può completare il ridimensionamento in modo sicuro. + Quando utilizzi la scalabilità gestita o la scalabilità automatica, assicurati che la capacità minima del cluster non sia inferiore al fattore. `dfs.replication` + Il numero di istanze principali deve essere almeno più uno. `dfs.replication` Ciò garantisce che Amazon EMR possa sostituire con successo un nodo principale non integro se hai abilitato la sostituzione del core non integro. **Importante** Il guasto di un singolo nodo core può portare alla perdita di dati HDFS se impostato su 1. `dfs.replication` Se il tuo cluster dispone di storage HDFS, ti consigliamo di configurare il cluster con almeno quattro nodi principali per i carichi di lavoro di produzione per evitare la perdita di dati e di impostare il `dfs.replication` fattore su almeno 2. # Errore del cluster Amazon EMR: errore di spazio HDFS insufficiente Se si tenta di rimuovere un nodo principale, può verificarsi un errore di spazio insufficiente nell'Hadoop Distributed File System (HDFS), ma Amazon EMR non può completare l'operazione in modo sicuro a causa dello spazio insufficiente rimasto nell'HDFS. Prima che Amazon EMR rimuova un nodo principale, tutti i dati HDFS sul nodo devono essere trasferiti su altri nodi principali per garantire la ridondanza dei dati. Tuttavia, se non c'è abbastanza spazio sugli altri nodi principali per la replica, Amazon EMR non può disattivare il nodo senza problemi. ## Possibili cause Consulta quanto segue per un elenco delle possibili cause dell'errore di spazio insufficiente HDFS: + Se si ridimensiona manualmente un gruppo di istanze principale o un parco di istanze quando non c'è abbastanza spazio HDFS sui nodi rimanenti per la replica dei dati prima del ridimensionamento. + La scalabilità gestita o la scalabilità automatica riducono un gruppo di istanze principale o un parco di istanze quando non c'è abbastanza spazio HDFS per la replica dei dati. + Amazon EMR tenta di sostituire un nodo principale non integro, ma non è in grado di sostituirlo in modo sicuro a causa dello spazio HDFS insufficiente. ## Soluzioni e best practice Per le soluzioni e le best practice, consulta quanto segue: + Aumenta il numero di nodi principali nel tuo cluster Amazon EMR. Se utilizzi la scalabilità gestita o la scalabilità automatica, aumenta la capacità minima dei tuoi nodi principali. + Usa volumi EBS più grandi per i tuoi nodi principali quando crei il tuo cluster EMR. + Elimina i dati HDFS non necessari nel tuo cluster EMR. Ti consigliamo di impostare CloudWatch allarmi per monitorare la `HDFSUtilization` metrica nel cluster per sapere se lo spazio sul cluster EMR è insufficiente.