作者:李佩京
时间:2019-01-25
问题一: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查看相关进程;
- 观察节点是否存活;
- 如果已经知道了启动失败的服务进程,进入到相关进程的日志目录下,查看日志,分析异常的原因
- 配置文件出错,saxparser exception; ——找到错误提示中所指出的配置文件检查修改即可
- unknown host——主机名不认识,配置/etc/hosts文件或者DNS服务器即可,或者是配置文件中所用主机名跟实际不一致
- 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 KaTeX parse error: Expected 'EOF', got '#' at position 6: {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堆积,大屏无法显示数据。