tutorial dispositivos cluster hadoop configuration hdfs

cluster - dispositivos hadoop



Hadoop:... replicarse en 0 nodos en lugar de minReplication(= 1). Hay 1 códigos de datos en ejecución y no se excluye ningún nodo en esta operación (8)

Compruebe si el comando jps en las computadoras que ejecutan los datanodes muestra que los datanodes se están ejecutando. Si se están ejecutando, significa que no pudieron conectarse con el namenode y, por lo tanto, el namenode piensa que no hay datanodes en el sistema hadoop.

En tal caso, después de ejecutar start-dfs.sh , ejecute netstat -ntlp en el nodo maestro. 9000 es el número de puerto que la mayoría de los tutoriales le indican que especifique en core-site.xml . Así que si ves una línea como esta en la salida de netstat

tcp 0 0 120.0.1.1:9000 0.0.0.0:* LISTEN 4209/java

entonces tienes un problema con el alias de host. Tuve el mismo problema, así que diré cómo se resolvió.

Este es el contenido de mi core-site.xml

<configuration> <property> <name>fs.default.name</name> <value>hdfs://vm-sm:9000</value> </property> </configuration>

Por lo tanto, el alias vm-sm en la computadora maestra se asigna al 127.0.1.1. Esto se debe a la configuración de mi /etc/hosts .

127.0.0.1 localhost 127.0.1.1 vm-sm 192.168.1.1 vm-sm 192.168.1.2 vm-sw1 192.168.1.3 vm-sw2

Parece que el core-site.xml del sistema maestro parecía haberse mapeado en el 120.0.1.1:9000 mientras que el de los nodos de trabajo están intentando conectarse a través de 192.168.1.1:9000 .

Así que tuve que cambiar el alias del nodo maestro para el sistema hadoop (solo eliminé el guión) en el /etc/hosts

127.0.0.1 localhost 127.0.1.1 vm-sm 192.168.1.1 vmsm 192.168.1.2 vm-sw1 192.168.1.3 vm-sw2

y reflejó el cambio en los archivos core-site.xml , mapred-site.xml y slave (donde ocurriera el antiguo alias del maestro).

Después de eliminar los archivos hdfs antiguos de la ubicación hadoop, así como la carpeta tmp y reiniciar todos los nodos, se solucionó el problema.

Ahora, netstat -ntlp después de iniciar devoluciones DFS

tcp 0 0 192.168.1.1:9000 0.0.0.0:* LISTEN ... ...

Recibo el siguiente error al intentar escribir en HDFS como parte de mi aplicación de subprocesos múltiples

could only be replicated to 0 nodes instead of minReplication (=1). There are 1 datanode(s) running and no node(s) are excluded in this operation.

He intentado la respuesta mejor calificada aquí con respecto al reformateo, pero esto no me funciona: error de HDFS: solo se pudo replicar en 0 nodos, en lugar de 1

Lo que está pasando es esto:

  1. Mi aplicación consta de 2 subprocesos, cada uno configurado con su propia Spring Data PartitionTextFileWriter
  2. El subproceso 1 es el primero en procesar datos y puede escribir correctamente en HDFS
  3. Sin embargo, una vez que Thread 2 comienza a procesar los datos, aparece este error cuando intenta descargarse a un archivo.

Los subprocesos 1 y 2 no se escribirán en el mismo archivo, aunque sí comparten un directorio principal en la raíz de mi árbol de directorios.

No hay problemas con el espacio en disco en mi servidor.

También veo esto en mis registros de nombre-nodo, pero no estoy seguro de lo que significa:

2016-03-15 11:23:12,149 WARN org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy: Failed to place enough replicas, still in need of 1 to reach 1 (unavailableStorages=[], storagePolicy=BlockStoragePolicy{HOT:7, storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]}, newBlock=true) For more information, please enable DEBUG log level on org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy 2016-03-15 11:23:12,150 WARN org.apache.hadoop.hdfs.protocol.BlockStoragePolicy: Failed to place enough replicas: expected size is 1 but only 0 storage types can be selected (replication=1, selected=[], unavailable=[DISK], removed=[DISK], policy=BlockStoragePolicy{HOT:7, storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]}) 2016-03-15 11:23:12,150 WARN org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy: Failed to place enough replicas, still in need of 1 to reach 1 (unavailableStorages=[DISK], storagePolicy=BlockStoragePolicy{HOT:7, storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]}, newBlock=true) All required storage types are unavailable: unavailableStorages=[DISK], storagePolicy=BlockStoragePolicy{HOT:7, storageTypes=[DISK], creationFallbacks=[], replicationFallbacks=[ARCHIVE]} 2016-03-15 11:23:12,151 INFO org.apache.hadoop.ipc.Server: IPC Server handler 8 on 9000, call org.apache.hadoop.hdfs.protocol.ClientProtocol.addBlock from 10.104.247.78:52004 Call#61 Retry#0 java.io.IOException: File /metrics/abc/myfile could only be replicated to 0 nodes instead of [2016-03-15 13:34:16,663] INFO [Group Metadata Manager on Broker 0]: Removed 0 expired offsets in 1 milliseconds. (kafka.coordinator.GroupMetadataManager)

¿Cuál podría ser la causa de este error?

Gracias

En mi caso el problema fue hadoop archivos temporales.

Los registros mostraban el siguiente error:

2019-02-27 13:52:01,079 INFO org.apache.hadoop.hdfs.server.common.Storage: Lock on /tmp/hadoop-i843484/dfs/data/in_use.lock acquired by nodename 28111@slel00681841a 2019-02-27 13:52:01,087 WARN org.apache.hadoop.hdfs.server.common.Storage: java.io.IOException: Incompatible clusterIDs in /tmp/hadoop-i843484/dfs/data: namenode clusterID = CID-38b0104b-d3d2-4088-9a54-44b71b452006; datanode clusterID = CID-8e121bbb-5a08-4085-9817-b2040cd399e1

Resolví eliminando archivos hadoop tmp

sudo rm -r /tmp/hadoop-*

En mi caso, fue una política de almacenamiento de la ruta de salida establecida en COLD.

Cómo verificar la configuración de su carpeta:

hdfs storagepolicies -getStoragePolicy -path my_path

En mi caso volvió.

The storage policy of my_path BlockStoragePolicy{COLD:2, storageTypes=[ARCHIVE], creationFallbacks=[], replicationFallbacks=[]}

Volcé los datos en otro lugar (al almacenamiento HOT) y el problema desapareció.

Este error es causado por el sistema de replicación de bloques de HDFS, ya que no pudo realizar copias de un bloque específico dentro del archivo enfocado. Razones comunes de eso:

  1. Solo se está ejecutando una instancia de NameNode y no está en modo seguro
  2. No hay instancias de DataNode en funcionamiento, o algunas están muertas. (Consultar los servidores)
  3. Las instancias de Namenode y Datanode se ejecutan, pero no pueden comunicarse entre sí, lo que significa que hay un problema de conectividad entre las instancias de DataNode y NameNode.
  4. Las instancias en ejecución de DataNode no pueden comunicarse con el servidor debido a algunos problemas de red basados ​​en hadoop (consulte los registros que incluyen información del nodo de datos)
  5. No hay espacio en el disco duro especificado en los directorios de datos configurados para las instancias de DataNode o las instancias de DataNode se han quedado sin espacio. (verifique dfs.data.dir // borre los archivos antiguos si los hay)
  6. Los espacios reservados especificados para las instancias de DataNode en dfs.datanode.du.reserved son más que el espacio libre que hace que las instancias de DataNode comprendan que no hay suficiente espacio libre.
  7. No hay suficientes hilos para las instancias de DataNode (verifique los registros de datanode y el valor de dfs.datanode.handler.count)
  8. Asegúrese de que dfs.data.transfer.protection no sea igual a "autenticación" y dfs.encrypt.data.transfer es igual a true.

También por favor:

  • Verifique el estado de los servicios de NameNode y DataNode y verifique los registros relacionados
  • Verifique si core-site.xml tiene el valor correcto de fs.defaultFS y hdfs-site.xml tiene un valor válido.
  • Verifique que hdfs-site.xml tiene dfs.namenode.http-address .. para todas las instancias de NameNode especificadas en el caso de la configuración de PHD HA.
  • Verificar si los permisos en los directorios son correctos.

Ref: https://wiki.apache.org/hadoop/CouldOnlyBeReplicatedTo

Ref: https://support.pivotal.io/hc/en-us/articles/201846688-HDFS-reports-Configured-Capacity-0-0-B-for-datanode

Además, marque: Escribir en HDFS desde Java, obteniendo "solo se podría replicar en 0 nodos en lugar de minReplication"

Puede dejar el modo seguro HDFS:

hdfs dfsadmin -safemode forceExit

Tuve el mismo error, al reiniciar los servicios hdfs se resolvió este problema. es decir, reinició los servicios de NameNode y DataNode.

Tuve un problema similar recientemente. Como mis datanodes (solo) tenían SSD para almacenamiento, puse [SSD]file:///path/to/data/dir para la configuración dfs.datanode.data.dir . Debido a los registros que contienen unavailableStorages=[DISK] , eliminé la etiqueta [SSD] , lo que solucionó el problema.

Aparentemente, Hadoop usa [DISK] como tipo de almacenamiento predeterminado, y no se "repliega" (o más bien ''fallup'') para usar SSD si no hay una ubicación de almacenamiento etiquetada [DISK] disponible. Aunque no pude encontrar ninguna documentación sobre este comportamiento.

Yo también tuve el mismo error, entonces he cambiado el tamaño del bloque. Esto vino a resolver el problema.