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á. # Erros de recursos durante as operações de cluster do Amazon EMR Os seguintes erros são geralmente causados pela restrição de recursos no cluster. A orientação descreve cada erro e fornece ajuda na solução de problemas. **Topics** + [O cluster do Amazon EMR é encerrado com NO\$1SLAVE\$1LEFT e nós centrais FAILED\$1BY\$1MASTER](emr-cluster-NO_SLAVE_LEFT-FAILED_BY_MASTER.md) + [Erro de cluster do Amazon EMR: não é possível replicar o bloco, só foi possível replicar para zero nós.](enough-hdfs-space.md) + [Erro de cluster do Amazon EMR: COTA DO EC2 EXCEDIDA](emr-EC2.md) + [Erro de cluster do Amazon EMR: muitas falhas de busca](emr-troubleshoot-error-resource-1.md) + [Erro de cluster do Amazon EMR: o arquivo só pôde ser replicado para 0 nós em vez de 1](emr-troubleshoot-error-resource-2.md) + [Erro de cluster do Amazon EMR: nós listados como negados](emr-troubleshoot-error-resource-3.md) + [Erros de controle de utilização com um cluster do Amazon EMR](emr-throttling-error.md) + [Erro de cluster do Amazon EMR: tipo de instância sem suporte](emr-INSTANCE_TYPE_NOT_SUPPORTED-error.md) + [Erro de cluster do Amazon EMR: o EC2 está sem capacidade](emr-EC2_INSUFFICIENT_CAPACITY-error.md) + [Erro de cluster do Amazon EMR: erro do fator de replicação do HDFS](emr-hdfs-insufficient-replication.md) + [Erro de cluster do Amazon EMR: erro de espaço insuficiente no HDFS](emr-hdfs-insufficient-space.md) # O cluster do Amazon EMR é encerrado com NO\$1SLAVE\$1LEFT e nós centrais FAILED\$1BY\$1MASTER Geralmente, isso acontece porque a proteção contra encerramento está desabilitada, e todos os nós core excedem a capacidade de armazenamento em disco, conforme especificado por um limite de utilização máxima na classificação de configuração `yarn-site`, que corresponde ao arquivo `yarn-site.xml`. Esse valor é 90%, por padrão. Quando a utilização do disco de um nó principal excede o limite de utilização, o serviço de NodeManager integridade do YARN relata o nó como. `UNHEALTHY` Enquanto ele estiver nesse estado, o Amazon EMR coloca o nó na lista de negação e não aloca contêineres YARN a ele. Se o nó permanecer não íntegro por 45 minutos, o Amazon EMR marcará a instância associada do Amazon EC2 para término como `FAILED_BY_MASTER`. Quando todas as instâncias do Amazon EC2 associadas a nós centrais são marcadas para término, o cluster é terminado com o status `NO_SLAVE_LEFT` porque não há recursos para executar trabalhos. Ultrapassar a utilização de disco em um nó core pode causar uma reação em cadeia. Se um único nó exceder o limite de utilização de disco por causa do HDFS, outros nós também poderão estar perto do limite. O primeiro nó excede o limite de utilização de disco, então o Amazon EMR o coloca na lista de negação. Isso aumenta a carga de utilização do disco para os nós restantes, pois eles começam a replicar dados do HDFS entre si que foram perdidos no nó que está na lista de negação. Cada nó subsequentemente entra no status `UNHEALTHY` da mesma maneira, e o cluster por fim é encerrado. ## Práticas recomendadas e orientações ### Configurar o hardware do cluster com armazenamento adequado Ao criar um cluster, certifique-se de que haja nós core suficientes e que cada um tenha um armazenamento de instâncias adequado e volumes de armazenamento do EBS para HDFS. Para obter mais informações, consulte [Calcular a capacidade necessária do HDFS de um cluster](emr-plan-instances-guidelines.md#emr-plan-instances-hdfs). Você também pode adicionar instâncias core aos grupos de instâncias existentes manualmente ou usando a escalabilidade automática. As novas instâncias têm a mesma configuração de armazenamento que outras instâncias no grupo de instâncias. Para obter mais informações, consulte [Use o ajuste de escala de cluster do Amazon EMR para se ajustar às mudanças nas workloads](emr-scale-on-demand.md). ### Habilitar a proteção contra encerramento Habilitar a proteção contra encerramento. Dessa forma, se um nó central estiver na lista de negação, você poderá se conectar à instância associada do Amazon EC2 usando SSH para solucionar problemas e recuperar dados. Se você habilitar a proteção contra término, lembre-se de que o Amazon EMR não substitui a instância do Amazon EC2 por uma nova instância. Para obter mais informações, consulte [Uso da proteção contra encerramento para proteger clusters do Amazon EMR do desligamento acidental](UsingEMR_TerminationProtection.md). ### Crie um alarme para a CloudWatch métrica MRUnhealthy Nodes Essa métrica informa o número de nós com o status `UNHEALTHY`. É equivalente à métrica do YARN `mapred.resourcemanager.NoOfUnhealthyNodes`. Você pode configurar uma notificação desse alarme para avisá-lo de nós não íntegros antes que o limite de 45 minutos seja atingido. Para obter mais informações, consulte [Monitorando métricas do Amazon EMR com CloudWatch](UsingEMR_ViewingMetrics.md). ### Ajustar as configurações com yarn-site As configurações a seguir podem ser ajustadas de acordo com os requisitos do aplicativo. Por exemplo, talvez você queira aumentar o limite de utilização de disco onde um nó informa `UNHEALTHY` ao aumentar o valor de `yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage`. Você pode definir esses valores ao criar um cluster usando a classificação de configuração `yarn-site`. Para obter mais informações, consulte [Configuring applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) no *Guia de lançamento do Amazon EMR*. Você também pode se conectar às instâncias do Amazon EC2 associadas a nós centrais usando SSH e, em seguida, adicionar os valores `/etc/hadoop/conf.empty/yarn-site.xml` usando um editor de texto. Depois de fazer a alteração, você deve reiniciar hadoop-yarn-nodemanager conforme mostrado abaixo. **Importante** Quando você reinicia o NodeManager serviço, os contêineres ativos do YARN são eliminados, a menos que `yarn.nodemanager.recovery.enabled` esteja configurado para `true` usar a classificação de `yarn-site` configuração ao criar o cluster. Você também deve especificar o diretório no qual armazenar um estado de contêiner usando a propriedade `yarn.nodemanager.recovery.dir`. ``` sudo /sbin/stop hadoop-yarn-nodemanager sudo /sbin/start hadoop-yarn-nodemanager ``` Para obter mais informações sobre as propriedades `yarn-site` atuais e valores padrão, consulte [Configurações padrão do YARN](http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-common/yarn-default.xml) na documentação do Apache Hadoop. | Propriedade | Valor padrão | Description | | --- | --- | --- | | yarn.nodemanager. disk-health-checker.intervalo-ms | 120000 | A frequência (em segundos) em que o verificador de integridade do disco é executado. | | yarn.nodemanager. disk-health-checker. min-healthy-disks | 0.25 | A fração mínima do número de discos que devem estar íntegros NodeManager para lançar novos contêineres. Isso corresponde a yarn.nodemanager.local-dirs (por padrão, `/mnt/yarn` no Amazon EMR) e yarn.nodemanager.log-dirs (por padrão `/var/log/hadoop-yarn/containers`, que apresenta um link simbólico para `mnt/var/log/hadoop-yarn/containers` no Amazon EMR). | | `yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage` | 90.0 | A porcentagem máxima de utilização de espaço em disco permitido depois que um disco é marcado como inválido. Os valores variam de 0,0 a 100,0. Se o valor for maior ou igual a 100, NodeManager verificará se há um disco cheio. Isso se aplica a `yarn-nodemanager.local-dirs` e a `yarn.nodemanager.log-dirs`. | | `yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb` | 0 | O espaço mínimo que deve estar disponível em um disco para que ele seja usado. Isso se aplica a `yarn-nodemanager.local-dirs` e a `yarn.nodemanager.log-dirs`. | # Erro de cluster do Amazon EMR: não é possível replicar o bloco, só foi possível replicar para zero nós. O erro: “Não é possível replicar os blocos, só foi possível replicar para zero nós”. normalmente ocorre quando o cluster não tem armazenamento HDFS suficiente. Esse erro ocorre quando você gera no seu cluster uma quantidade de dados maior do que o HDFS pode armazenar. Você verá esse erro somente enquanto o cluster estiver em execução, porque quando o trabalho é terminado, ele libera o espaço que o HDFS estava usando. A quantidade de espaço disponível no HDFS para um cluster depende do número e do tipo de instâncias do Amazon EC2 que são usadas como nós centrais. Nós de tarefa não são usados para armazenamento HDFS. Todo o espaço em disco em cada instância do Amazon EC2, incluindo os volumes de armazenamento do EBS anexados, está disponível para o HDFS. Para obter mais informações sobre a quantidade de armazenamento local para cada tipo de instância do EC2, consulte os [tipos e famílias de instâncias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) no *Guia do usuário do Amazon EC2*. O outro fator que pode afetar a quantidade de espaço disponível no HDFS é o fator de replicação, que é o número de cópias de cada bloco de dados que são armazenadas no HDFS por redundância. O fator de replicação aumenta de acordo com o número de nós no cluster: são 3 cópias de cada bloco de dados para um cluster com 10 ou mais nós, 2 cópias de cada bloco para um cluster com 4 a 9 nós e 1 cópia (sem redundância) para clusters com 3 ou menos nós. O total de espaço disponível no HDFS é dividido pelo fator de replicação. Em alguns casos, como por exemplo, com o aumento do número de nós de 9 para 10, o aumento no fator de replicação pode realmente fazer com que a quantidade de espaço disponível no HDFS diminua. Por exemplo, um cluster com 10 nós core do tipo m1.large teria 2833 GB de espaço disponível para o HDFS ((10 nós X 850 GB por nó)/fator de replicação de 3). Se o seu cluster exceder a quantidade de espaço disponível no HDFS, você pode adicionar mais nós core ao cluster ou usar a compactação de dados para criar mais espaço no HDFS. Se o cluster pode ser interrompido e reiniciado, você pode considerar o uso dos nós centrais de um tipo de instância maior do Amazon EC2. Você também deve considerar um ajuste no fator de replicação. Observe, no entanto, que a redução do fator de replicação diminui a redundância dos dados do HDFS e, consequentemente, a capacidade do seu cluster para recuperar blocos perdidos ou corrompidos do HDFS. # Erro de cluster do Amazon EMR: COTA DO EC2 EXCEDIDA Se uma mensagem `EC2 QUOTA EXCEEDED` for exibida, pode haver várias causas. Dependendo das diferenças na configuração, pode demorar entre 5 a 20 minutos para que clusters anteriores sejam encerrados totalmente e liberem os recursos alocados. Se você está recebendo um erro `EC2 QUOTA EXCEEDED` ao tentar iniciar um cluster, pode ser que os recursos de um cluster recém-encerrado ainda não tenham sido liberados. Essa mensagem também pode ser causada pelo redimensionamento de um grupo ou frota de instâncias para um tamanho de destino maior do que a cota de instâncias atual da conta. Isso pode acontecer manualmente ou automaticamente por meio de escalabilidade automática. Considere as opções a seguir para resolver o problema: + Siga as instruções descritas em [AWS service quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) no *Referência geral da Amazon Web Services* para solicitar um aumento do limite de serviço. Para alguns APIs, organizar um CloudWatch evento pode ser uma opção melhor do que aumentar os limites. Consulte mais detalhes em [Quando configurar eventos do EMR em CloudWatch](emr-service-limits-cloudwatch-events.md). + Se um ou mais clusters em execução não estiverem na capacidade, redimensione os grupos de instâncias ou reduza as capacidades de destino nas frotas de instâncias para os clusters em execução. + Crie clusters com um número menor de instâncias do EC2 ou reduza a capacidade de destino. # Erro de cluster do Amazon EMR: muitas falhas de busca A presença de mensagens de erro "**Too many fetch-failures (Excesso de falhas de busca)**" ou "**Error reading task output (Erro ao ler a saída da tarefa)**" nas etapas ou em logs de tentativas de tarefas indica que a tarefa em execução está dependendo da saída de uma outra tarefa. Isso geralmente ocorre quando uma tarefa é colocada na fila de execução e necessita da saída de uma ou mais tarefas de mapeamento, e essa saída ainda não está disponível. Há vários motivos pelos quais a saída pode não estar disponível: + A tarefa de pré-requisito ainda está em processamento. Essa geralmente é uma tarefa de mapeamento. + Os dados podem estar indisponíveis devido à conectividade de rede ruim, se os dados estiverem localizados em uma instância diferente. + Se o HDFS estiver sendo usado para recuperar a saída, pode haver um problema com o HDFS. A causa mais comum deste erro é que a tarefa anterior ainda está em processamento. Isso é mais provável se os erros estão ocorrendo quando as tarefas de redução estão sendo executadas pela primeira vez. Você pode verificar se é esse o caso examinando o log do syslog para a etapa do cluster que está gerando o erro. Se o syslog mostra que ambas as tarefas de mapeamento e redução estão em andamento, isso indica que a fase de redução foi iniciada e, ao mesmo tempo, há tarefas de mapeamento que ainda não foram concluídas. Um item a ser pesquisado nos logs é a porcentagem de andamento do mapeamento que vai até 100% e, em seguida, cai para um valor mais baixo. Quando a porcentagem está em 100%, isso não significa que todas as tarefas de mapeamento foram concluídas. Isto significa simplesmente que o Hadoop está executando todas as tarefas de mapeamento. Se esse valor voltar a ficar abaixo de 100%, isso significa que uma tarefa de mapeamento falhou e, dependendo da configuração, o Hadoop pode tentar reprogramar a tarefa. Se a porcentagem do mapa permanecer em 100% nos registros, observe as CloudWatch métricas, especificamente`RunningMapTasks`, para verificar se a tarefa do mapa ainda está sendo processada. Você também pode encontrar essas informações usando a interface da web do Hadoop no nó principal. Se você está vendo esse problema, pode tentar várias ações: + Inclua instruções na fase de redução para esperar mais antes de iniciar. Você pode fazer isso alterando a definição da configuração do Hadoop mapred.reduce.slowstart.completed.maps para um tempo maior. Para obter mais informações, consulte [Como criar ações de bootstrap para instalar softwares adicionais com um cluster do Amazon EMR](emr-plan-bootstrap.md). + Iguale a contagem de reducers com a capacidade total de reducers do cluster. Você pode fazer isso ajustando a definição de configuração do Hadoop mapred.reduce.tasks de acordo com o trabalho. + Use um código de classe de combiner para minimizar o número de saídas que precisam ser obtidas. + Verifique se não há problemas com o serviço do Amazon EC2 que estejam afetando a performance de rede do cluster. Você pode fazer isso usando o [Painel de status dos serviços](https://status.aws.amazon.com/). + Analise os recursos de CPU e memória das instâncias no seu cluster para assegurar-se de que o processamento dos dados não está degradando os recursos dos seus nós. Para obter mais informações, consulte [Configuração de hardware e redes do cluster do Amazon EMR](emr-plan-instances.md). + Verifique a versão da Imagem de máquina da Amazon (AMI) usada no cluster do Amazon EMR. Se a versão estiver entre a 2.3.0 e a 2.4.4, ambas incluídas, atualize para uma versão mais recente. As versões da AMI desse intervalo especificado usam uma versão do Jetty que pode falhar ao produzir uma saída da fase de mapeamento. O erro de busca ocorre quando os reducers não conseguem obter uma saída da fase de mapeamento. O Jetty é um servidor de HTTP de código aberto usado para estabelecer a comunicação entre máquinas em um cluster do Hadoop. # Erro de cluster do Amazon EMR: o arquivo só pôde ser replicado para 0 nós em vez de 1 Quando um arquivo é gravado no HDFS, ele é replicado para vários nós core. Quando você vê esse erro, significa que o NameNode daemon não tem nenhuma DataNode instância disponível para gravar dados no HDFS. Em outras palavras, a replicação de blocos não está sendo realizada. Esse erro pode ser causado por vários problemas: + O sistema de arquivos do HDFS pode estar com o espaço esgotado. Esta é a causa mais provável. + DataNode as instâncias podem não estar disponíveis quando o trabalho foi executado. + DataNode as instâncias podem ter sido bloqueadas de se comunicar com o nó principal. + As instâncias no grupo de instâncias core podem não estar disponíveis. + Podem estar faltando permissões. Por exemplo, o JobTracker daemon pode não ter permissões para criar informações do rastreador de tarefas. + A configuração do espaço reservado para uma DataNode instância pode ser insuficiente. Verifique se esse é o caso, examinando a definição da configuração de dfs.datanode.du.reserved. Para verificar se esse problema é causado pela falta de espaço em disco do HDFS, veja a `HDFSUtilization` métrica em CloudWatch. Se o valor for muito alto, você pode adicionar mais nós core ao cluster. Se você tem um cluster que acha que pode ficar sem espaço em disco no HDFS, você pode configurar um alarme CloudWatch para alertá-lo quando o valor de `HDFSUtilization` subir acima de um determinado nível. Para obter mais informações, consulte [Redimensionar manualmente um cluster do Amazon EMR em execução](emr-manage-resize.md) e [Monitorando métricas do Amazon EMR com CloudWatch](UsingEMR_ViewingMetrics.md). Se o HDFS ficar sem espaço não fosse o problema, verifique os registros, os DataNode NameNode registros e a conectividade de rede em busca de outros problemas que poderiam ter impedido o HDFS de replicar dados. Para obter mais informações, consulte [Exibição dos arquivos de log do Amazon EMR](emr-manage-view-web-log-files.md). # Erro de cluster do Amazon EMR: nós listados como negados O NodeManager daemon é responsável por lançar e gerenciar contêineres nos nós principais e de tarefas. Os contêineres são alocados ao NodeManager daemon pelo ResourceManager daemon executado no nó principal. Ele ResourceManager monitora o NodeManager nó por meio de um batimento cardíaco. Há algumas situações em que o ResourceManager daemon deny lista uma NodeManager, removendo-a do pool de nós disponíveis para processar tarefas: + Se o não NodeManager tiver enviado uma pulsação ao ResourceManager daemon nos últimos 10 minutos (600.000 milissegundos). Esse intervalo de tempo pode ser configurado usando a definição da configuração `yarn.nm.liveness-monitor.expiry-interval-ms`. Para obter mais informações sobre a alteração das definições de configuração do Yarn, consulte [Configuring applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) no *Guia de lançamento do Amazon EMR*. + NodeManager verifica a integridade dos discos determinada por `yarn.nodemanager.local-dirs` e. `yarn.nodemanager.log-dirs` As verificações incluem permissões e espaço livre em disco (< 90%). Se um disco falhar na verificação, ele para de NodeManager usar esse disco específico, mas ainda informa o status do nó como íntegro. Se vários discos falharem na verificação, o nó será reportado como não íntegro ResourceManager e os novos contêineres não serão atribuídos ao nó. O mestre do aplicativo também pode negar a lista de um NodeManager nó se ele tiver mais de três tarefas com falha. Você pode aumentar esse valor usando o parâmetro de configuração `mapreduce.job.maxtaskfailures.per.tracker`. Outras definições de configuração que você pode alterar controlam o número de tentativas para uma tarefa antes de marcá-la como falha: `mapreduce.map.max.attempts` para tarefas de mapeamento e `mapreduce.reduce.maxattempts` para tarefas de redução. Para obter mais informações sobre a alteração das definições de configuração, consulte [Configuring applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) no *Guia de lançamento do Amazon EMR*. # Erros de controle de utilização com um cluster do Amazon EMR Os erros “Limitado *Amazon EC2* ao iniciar o cluster” e “Falha ao provisionar instâncias devido à limitação de” *Amazon EC2* ocorrem quando o Amazon EMR não consegue concluir uma solicitação porque outro serviço limitou a atividade. O Amazon EC2 é a origem mais comum de erros de controle de utilização, mas outros serviços podem ocasionar esses erros. Os [limites de serviço da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) se aplicam por região para melhorar a performance, e um erro de controle de utilização indica que você excedeu o limite de serviço da conta naquela região. ## Possíveis causas A origem mais comum de erros de controle de utilização do Amazon EC2 é um grande número de instâncias do cluster sendo iniciadas, de modo que o limite de serviço para instâncias do EC2 é excedido. As instâncias do cluster podem ser executadas pelos seguintes motivos: + Novos clusters são criados. + Os clusters são redimensionados manualmente. Para obter mais informações, consulte [Redimensionar manualmente um cluster do Amazon EMR em execução](emr-manage-resize.md). + Os grupos de instâncias em um cluster adicionam instâncias (expandem) como resultado de uma regra de escalabilidade automática. Para obter mais informações, consulte [Noções básicas sobre as regras de ajuste de escala automático](emr-automatic-scaling.md#emr-scaling-rules). + As frotas de instâncias em um cluster adicionam instâncias para atender a uma maior capacidade de destino. Para obter mais informações, consulte [Planejamento e configuração de frotas de instâncias para o cluster do Amazon EMR](emr-instance-fleet.md). Também é possível que a frequência ou tipo de solicitação de API sendo feita ao Amazon EC2 cause erros de controle de utilização. Para obter mais informações sobre como o Amazon EC2 limita solicitações de API, consulte [Query API request rate](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/query-api-troubleshooting.html#api-request-rate) na *Amazon EC2 API Reference*. ## Soluções Considere as seguintes soluções: + Siga as instruções descritas em [AWS service quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) no *Referência geral da Amazon Web Services* para solicitar um aumento do limite de serviço. Para alguns APIs, organizar um CloudWatch evento pode ser uma opção melhor do que aumentar os limites. Consulte mais detalhes em [Quando configurar eventos do EMR em CloudWatch](emr-service-limits-cloudwatch-events.md). + Se você tiver clusters são executados no mesmo agendamento (por exemplo, no começo da hora) considere intercalar os horários de início. + Se tiver clusters que são dimensionados para picos de demanda, e você periodicamente tiver capacidade de instância, considere especificar a escalabilidade automática para adicionar e remover instâncias sob demanda. Dessa forma, as instâncias serão usadas de forma mais eficiente e, dependendo do perfil de demanda, menos instâncias poderão ser solicitadas em um determinado momento em uma conta. Para obter mais informações, consulte [Uso do ajuste de escala automático com uma política personalizada para grupos de instâncias no Amazon EMR](emr-automatic-scaling.md). # Erro de cluster do Amazon EMR: tipo de instância sem suporte Se você criar um cluster e ele falhar com a mensagem de erro “O tipo de instância solicitado não *InstanceType* é suportado na zona de disponibilidade solicitada”, significa que você criou o cluster e especificou um tipo de instância para um ou mais grupos de instâncias que não é suportado pelo Amazon EMR na região e na zona de disponibilidade em que o cluster foi criado. O Amazon EMR pode oferecer suporte a um tipo de instância em uma zona de disponibilidade de uma região e não em outra. A sub-rede selecionada para um cluster determina a Zona de disponibilidade na região. ## Solução **Determine os tipos de instância disponíveis em uma zona de disponibilidade usando o AWS CLI** + Use o comando `ec2 run-instances` com a opção `--dry-run`. No exemplo abaixo, *m5.xlarge* substitua pelo tipo de instância que você deseja usar, pela AMI *ami-035be7bafff33b6b6* associada a esse tipo de instância e *subnet-12ab3c45* por uma sub-rede na zona de disponibilidade que você deseja consultar. ``` aws ec2 run-instances --instance-type m5.xlarge --dry-run --image-id ami-035be7bafff33b6b6 --subnet-id subnet-12ab3c45 ``` Para obter instruções sobre como encontrar um ID de AMI, consulte [Encontre uma AMI do Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/finding-an-ami.html). Para encontrar um ID de sub-rede, você pode usar o comando [describe-subnets](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-subnets.html). Para saber mais sobre como descobrir tipos de instância disponíveis, consulte [Localizar um tipo de instância do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html). Depois de determinar os tipos de instâncias disponíveis, você pode fazer o seguinte: + Crie o cluster na mesma região e sub-rede do EC2 e selecione um tipo de instância diferente com recursos semelhantes que a escolha inicial. Para obter uma lista dos tipos de instâncias compatíveis, consulte [Tipos de instância compatíveis do Amazon EMR](emr-supported-instance-types.md). Para comparar recursos de tipos de instância do EC2, consulte [Tipos de instância do Amazon EC2](https://aws.amazon.com/ec2/instance-types/). + Selecione uma sub-rede para o cluster em uma zona de disponibilidade onde o tipo de instância esteja disponível e tenha suporte do Amazon EMR. **Mitigue as falhas de lançamento do cluster da frota de instâncias devido a tipos de instância primária sem suporte no Amazon EMR** Os nós primários são essenciais nos clusters do Amazon EMR. A inicialização de um cluster do EMR pode falhar com um erro `instance type not supported` em que o Amazon EMR tenta iniciar o cluster em uma zona de disponibilidade, caso o tipo de instância primária não tenha suporte. A seleção aprimorada da zona de disponibilidade para clusters de frotas de instâncias no Amazon EMR filtra automaticamente os tipos de AZs instâncias primárias que você especificou na configuração do cluster. Isso significa que o Amazon EMR não escolherá uma zona de disponibilidade em que os tipos de instância primária configurados não tenham suporte, o que evita falhas na inicialização do cluster devido a tipos de instância não compatíveis. Para permitir essa melhoria, adicione a permissão necessária ao perfil ou política de serviço do cluster. A versão mais recente do `AmazonEMRServicePolicy_v2` inclui essa permissão, portanto, se você usar essa política, a melhoria já estará disponível. Ao usar um perfil ou política de serviço personalizados, adicione a permissão `ec2:DescribeInstanceTypeOfferings` ao iniciar o cluster. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "ec2:DescribeInstanceTypeOfferings" ], "Effect": "Allow", "Resource": [ "*" ], "Sid": "AllowEC2Describeinstancetypeofferings" } ] } ``` ------ # Erro de cluster do Amazon EMR: o EC2 está sem capacidade Um *EC2 está sem capacidade porque* um *InstanceType* erro ocorre quando você tenta criar um cluster ou adicionar instâncias a um cluster em uma zona de disponibilidade que não tem mais do tipo de instância EC2 especificado. A sub-rede que você selecionou para um cluster determina a zona de disponibilidade. Para criar um cluster, siga um destes procedimentos: + Especificar outro tipo de instância com recursos semelhantes + Criar o cluster em outra região + Selecione uma sub-rede em uma zona de disponibilidade em que o tipo de instância desejado possa estar disponível. Para adicionar instância a um cluster em execução, realize uma destas ações: + Modifique as configurações do grupo de instâncias ou as configurações da frota de instâncias para adicionar os tipos de instância disponíveis com recursos semelhantes. Para obter uma lista dos tipos de instâncias compatíveis, consulte [Tipos de instância compatíveis do Amazon EMR](emr-supported-instance-types.md). Para comparar recursos de tipos de instância do EC2, consulte [Tipos de instância do Amazon EC2](https://aws.amazon.com/ec2/instance-types/). + Termine o cluster e o recrie em uma região e zona de disponibilidade em que o tipo de instância está disponível. # Erro de cluster do Amazon EMR: erro do fator de replicação do HDFS Quando você remove um nó central de um [grupo de instâncias](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-uniform-instance-group.html) centrais ou de uma [frota de instâncias](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-fleet.html), o Amazon EMR pode se deparar com um erro de replicação do HDFS. Esse erro ocorre quando você remove os nós centrais e o número deles fica abaixo do [fator de replicação dfs.replication](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html) configurado para o Sistema de Arquivos Distribuído do Hadoop (HDFS). Dessa forma, o Amazon EMR não pode realizar a operação com segurança. Para determinar o valor padrão da configuração `dfs.replication`, [configuração do HDFS](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html). ## Possíveis causas Confira as possíveis causas do erro do fator de replicação do HDFS: + Se você [redimensionar manualmente](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-resize.html) um grupo de instâncias centrais ou uma frota de instâncias abaixo do fator `dfs.replication` configurado. + Suas políticas de [escalabilidade gerenciada](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) ou [ajuste de escala automático](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-automatic-scaling.html) podem permitir que o ajuste reduza o número de nós centrais abaixo do limite de `dfs.replication`. + Esse erro também pode ocorrer se o Amazon EMR tentar [substituir](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-node-replacement.html) um nó central não íntegro quando um cluster tem o número mínimo de nós centrais definido por [](). ## Soluções e práticas recomendadas Consulte as seguintes informações para obter as soluções e práticas recomendadas: + Ao redimensionar manualmente um cluster do Amazon EMR, não reduza a escala verticalmente abaixo de `dfs.replication`, pois o Amazon EMR não pode concluir o redimensionamento com segurança. + Ao usar o ajuste de escala gerenciado ou automático, certifique-se de que a capacidade mínima do cluster não seja inferior ao fator `dfs.replication`. + O número de instâncias centrais deve ser pelo menos `dfs.replication` mais uma. Isso garante que o Amazon EMR possa substituir com êxito um nó central não íntegro se você habilitou a substituição de núcleo não íntegro. **Importante** A falha de um único nó central pode levar à perda de dados do HDFS se você definir `dfs.replication` como 1. Se o cluster tiver armazenamento HDFS, é recomendável configurá-lo com pelo menos quatro nós centrais para workloads de produção e evitar perda de dados; defina também um fator `dfs.replication` de pelo menos 2. # Erro de cluster do Amazon EMR: erro de espaço insuficiente no HDFS Um erro de espaço insuficiente do Sistema de Arquivos Distribuído do Hadoop (HDFS) pode ocorrer se você tentar remover um nó central, mas o Amazon EMR não pode concluir a operação com segurança devido à falta de espaço no HDFS. Antes que o Amazon EMR remova um nó central, todos os dados do HDFS no nó devem ser transferidos para outros nós centrais para garantir a redundância dos dados. No entanto, se não houver espaço suficiente nos outros nós centrais para replicação, o Amazon EMR não poderá desativar o nó. ## Possíveis causas Confira esta lista das possíveis causas do erro de espaço insuficiente no HDFS: + Se você reduzir manualmente a escala de um grupo de instâncias centrais ou de uma frota de instâncias quando não houver espaço suficiente no HDFS nos nós restantes para replicação de dados antes de reduzir a escala verticalmente. + O ajuste de escala gerenciado ou automático reduzem verticalmente a escala de um grupo de instâncias centrais ou de uma frota de instâncias quando não há espaço suficiente no HDFS para a replicação de dados. + O Amazon EMR tenta substituir um nó central não íntegro, mas não consegue substituí-lo com segurança devido ao espaço insuficiente no HDFS. ## Soluções e práticas recomendadas Consulte as seguintes informações para obter as soluções e práticas recomendadas: + Aumente verticalmente a escala do número de nós centrais no cluster do Amazon EMR. Se você usa ajuste de escala gerenciado ou automático, aumente a capacidade mínima dos nós centrais. + Use volumes maiores do EBS para os nós centrais ao criar o cluster do EMR. + Exclua dados do HDFS desnecessários no cluster do EMR. Recomendamos que você configure CloudWatch alarmes para monitorar a `HDFSUtilization` métrica em seu cluster para saber se seu cluster EMR está com pouco espaço.