HDFS问题总结

问题一：Namenode主从切换注意：NameNode is safe mode。

注意：这是因为集群处于安全模式下,安全模式下禁止对文件的任何操作，包括写和删除等操作。在做主从切换的时候需要保证standby节点为Safemode is off，否则会造成集群无法执行写操作。

操作：

• 退出安全模式的命令: ${HADOOP_HOME}/bin/hdfs dfsadmin –safemode leave。
• 查看集群的状态信息:  ${HADOOP_HOME}/bin/hdfs dfsadmin -report。

原因：集群刚启动DN会向NN汇报一些信息处于安全模式，如果集群启动后还是不退出就出现异常了。需要手动退出安全模式。可以查看日志信息或重启集群。

问题二：start-dfs.sh报NameNode is not formatted。

注意：在启动namenode和datanode之前需要提前格式化HDFS，格式化后会有如下文件${HADOOP_DATA_DIR}/current/VERSION

操作：${HADOOP_HOME}/bin/hdfsnamenode –format

HA模式的namenode启动方式：

首先启动journalnode，因为namenode在-format的工程中会连接journalnode

然后使用${HADOOP_HOME}/bin/hdfs zkfc –formatZK        ${HADOOP_HOME}/bin/hdfs namenode -format

问题三：访问namenode的50070端口异常： (namenode 50070端口异常代表namenode服务没有正常运行，即服务启动失败，失败的原因有很多，其中包括问题二提到的namenode没有format成功，/Data目录权限问题，数据盘挂载问题等，其实问题三可以总结为namenode未正常启动的可能原因总结)

操作步骤：

• 在服务器的终端命令行使用jps查看相关进程
• 观察节点是否存活
• 如果已经知道了启动失败的服务进程，进入到相关进程的日志目录下，查看日志，分析异常的原因
  1. 配置文件出错，saxparser  exception； ——找到错误提示中所指出的配置文件检查修改即可
  2. unknown host——主机名不认识，配置/etc/hosts文件或者DNS服务器即可，或者是配置文件中所用主机名跟实际不一致
  3. directory 访问异常—— 检查namenode的工作目录，看权限是否正常

注意点：

在${HADOOP_HOME}/etc/hadoop/hdfs-site.xml文件中dfs.ha.namenodes.ns1配置的时候尽量不要写localhost:50070，否则50070只能本机访问导致外部用户无法访问，因为呢？我们在使用netstat –ntlp命令查看的时候会发现50070绑定端口是127.0.0.1只能通过本地回环IP访问。

问题四：Namenode无法主从切换

原因：centos7.2 HA切换需要依赖fuser命令，而此需要预安装：yum install psmisc –y（安装fuser的原因，以及fuser是如何工作使namenode进行主备切换的，参考以下我之前整理的部分。） （下文配置文件优化还会详细介绍）

Case 1 ：SRE团队进行抗脆弱测试关机一台namenode，namenode因无法完成主备切换导致服务异常。

dfs.ha.fencing.methods 配置有sshfence和 shell 两种方法：sshfence：防止namenode发生脑裂，即 出现两个 master 同时对外提供服务,导致系统处于不一致状态,可能导致数据丢失等潜在问题。在 HDFS HA 中,JournalNode 只允许一个 NameNode 写数据,不会出现两个 active NameNode 的问题, 但是,当主备切换时,之前的 active NameNode 可能仍在处理客户端的 RPC 请求,为此, 需要增加隔离机制(fencing)将之前的 active NameNode 杀死。HDFS 允许用户配置多个隔离机制,当发生主备切换时,将顺次执行这些隔离机制,直 到一个返回成功。Hadoop 2.0及以上版本内部封装了两种类型的隔离机制,分别是 shell 和 sshfence。

• Sshfence

sshfence 通过 ssh 登录到前一个 active NameNode 并将其杀死。为了让该机 制成功执行,需配置免密码 ssh 登陆,这可通过参数 dfs.ha.fencing.ssh.private-key-files 设置一个私钥文件。且namenode必须安装psmisc(fuser)模块实现sshfence功能。

2 ） shell(/bin/true)

如果出现故障并且fencing方法返回false，则会继续执行shell(true)，从而active/standby自动切换。fencing方法返回true，则不会执行shell。

问题五：host配置文件中取消127.0.0.1 配置，否则会出现：Configuration has multiple addresses that match local node’s address. Please configure the system with dfs.nameservice.id and dfs.ha.namenode.id报错 （host问题参考以下）

注意： /etc/hosts 第一行不能用 127.0.0.1 HOSTNAME localhost.localdomain localhost ，会造成 namenode 启动失败（失败原因可以去复现一下，但 100% 会失败，这块可以写详细一些），需用 127.0.0.1 localhost.localdomain localhost 。原因为会与（ REAL_IP HOSTNAME ）冲突。

问题六：配置文件优化

优化项一：修改hdfs-site.xml文件中dfs.ha.fencing.methods的配置，增加shell(/bin/true)方法或仅仅配置这个方法，可以使得网卡中断后（死机）切换成功进行。

原因：杀死原来ACTIVE namenode上的NameNode进程，会成功自动切换，这主要是与fencing方法的设置有关。Hadoop提供的两种fencing方法是sshfence和shell，其中sshfence要求ssh登录到目标结点杀死NameNode进程，因此当仅仅配置fencing方法是sshfence之后，当原active namenode的网卡down掉之后，原standby namenode的zkfc实际上已经不能ssh到原active namenode上杀死NameNode进程，因此该fencing不能成功执行，因此无法继续切换自己的状态成active，只能不断尝试。sshfence失败导致不能切换之后，如果这时候恢复网卡连通性（ifup ），那么切换过程又可以继续进行下去，仍然完成将原来active/standby结点状态对调的切换。

优化项二：修改hdfs-site.xml文件中dfs.ha.fencing.ssh.private-key-files指定namenode之前免密私钥，因为在主从切换的时候如上所诉，需要两台namenode免密，所以这个文件需要指定正确路径。

操作步骤：

ssh-keygen –t rsa –P “” # 生成密钥对

ssh-copy-id –i /home/${USER}/.ssh/id_rsa.pub ${IP} # 将公钥拷贝到${IP}

优化项三：修改hdfs-site.xml文件中dfs.ha.automatic-failover.enabled=true用于主从切换。

优化项四：修改hdfs-site.xml文件

hdfs-site.xml中增加配置：

dfs.qjournal.start-segment.timeout.ms=90000

dfs.qjournal.select-input-streams.timeout.ms = 90000

dfs.qjournal.write-txns.timeout.ms = 90000

core-site.xml中增加配置：

ipc.client.connect.timeout = 90000

原因：这是一个连锁反应，namenode开启新日志段时，需要大多数journalnode写成功并响应，由于规定时间内只得到一个jn响应，active namenode认为异常然后自动退出服务;zkfailover捕捉到namenode异常，但zk同步日志耗时太长，session超时，进而导致zkfailover服务关闭，没有引发热切，之前的standby namenode依旧是standby,从而整个hadoop不可用。

优化项五：修改core-site.xml文件fs.hdfs.impl.disable.cache=false，增加HDFS缓存机制，从源码来看复用FileSystem对象，比如spark要去连namenode找那些文件，比如查一个表的时候，如果这个表有10个文件，不关闭缓存，它会去连10次namenode所以将该功能关闭。如果打开了缓存的话，就会直接从静态缓存对象中返回已经创建的实例。而缓存默认是打开的。缓存的方式就是常见的懒加载模式（存在就返回，不存在就创建并放在 cache 中）。 （可以参考我之前整理的，再完善一下）

case 2 ：SRE团队进行抗脆弱测试时发现，当一台namenode服务器断电后，新建测试大屏不显示数据或数据更新延迟较大。

排查原因为大屏服务通过spark sql从HDFS中取数据，上图两个参数如果设置成true会使所有FileSystem.get方法都重新去连namenode，而不复用连接，即缓存机制。如果主namenode（即配置文件靠前的namenode）宕机的话，每一次的FileSystem.get方法都会试图先尝试连接主namenode，导致超时。在spark sql中，表中文件数量越多，则调用FileSystem.get方法的次数越多，因此上图两个配置项如果设置为true，则会大幅度增加连接时长，最终导致大量spark sql堆积，大屏无法显示数据。