EMR的实例需要重启维护,所以我们也需要重启Master节点,为了让该Master节点能漂移到其他的实例上,而不改变Master的基本配置
1、同步fairscheduler文件
2、同步标签配置文件
3、修改znode的储存空间
4、配置job-flow-state.txt的移动脚本
5、修改元数据连接串
二、操作 观察主机进程先登录到需要重启的节点
- Zookeeper
查看当前zk状态
cd /usr/lib/zookeeper/bin/ ./zkServer.sh status
使用脚本查看zk状态
这种为leader
./zkServer.sh status ZooKeeper JMX enabled by default Using config: /usr/lib/zookeeper/bin/../conf/zoo.cfg Mode: leader
这种为follower
./zkServer.sh status ZooKeeper JMX enabled by default Using config: /usr/lib/zookeeper/bin/../conf/zoo.cfg Mode: follower
使用脚本停止zk服务,让其他节点的zk变成leader
./zkServer.sh stop
- ResourceManger
使用指令
yarn rmadmin -getAllServiceState
查看当前所有的 ResourceManger 的状态,若当前的IP是 standby 状态的就不需要额外处理
如果是 active状态,则使用以下指令切换主备
注意:会导致Yarn服务暂时不可用
status hadoop-yarn-resourcemanager stop hadoop-yarn-resourcemanager status hadoop-yarn-resourcemanager 或 systemctl status hadoop-yarn-resourcemanager.service systemctl stop hadoop-yarn-resourcemanager.service systemctl status hadoop-yarn-resourcemanager.service
- MetaStore
观察一下hive-site.xml文件中的对应参数,
javax.jdo.option.ConnectionURL ***** ***** javax.jdo.option.ConnectionDriverName ****** ****** javax.jdo.option.ConnectionUserName ***** ***** javax.jdo.option.ConnectionPassword ******* *****
!!!重要!!!
如果这里的metastore是无法连接的旧地址,会触发AWS侧的bug,导致重启后节点无法正常拉起,解决方法查看【三、异常状况】
关闭节点通过EMR集群控制台跳转到EC2实例控制台,在EC2控制台中下线该节点。EMR集群中若有节点下线,就会自动拉起新的节点
※正常情况,从拉起到运行正常情况需要15分钟
重新配置当成功拉起后,需要重新配置一下各项指标
- hdfs-site.xml
如果集群有访问其他hdfs,则需要配置对应的namespace解析,或者使用其他节点中已经配置过的hdfs-site.xml下
登录正常启动中的master节点
cd /etc/hadoop/conf python2 -m SimpleHTTPServer 9999
在重启中的节点中先备份该文件,再下载对应文件
cd /etc/hadoop/conf mv hdfs-site.xml hdfs-site.xml_bak wget http://启动中的master节点IP:9999/hdfs-site.xml
- 调度规则
Yarn集群有公平调度和容量调度,根据公司常用的调度规则进行配置。
当然这部分配置应该是在集群启动项中已经添加过的。
cd /etc/hadoop/conf vi yarn-site.xml
查看调度规则是否有配置
yarn.resourcemanager.scheduler.class
注意查看当前路径下是否有对应的调度文件,如果没有,则需要上传或者从其他master节点拿,指令与上面hdfs-site.xml的一样
再重启hadoop-yarn-resourcemanager服务
systemctl stop hadoop-yarn-resourcemanager systemctl start hadoop-yarn-resourcemanager
- 添加CORE节点标签
AWS EMR集群设置为CORE节点只运行appMaster
注意:这个配置只会影响现在active的节点,而stand by状态的节点并不会记录该配置,如果发生主备切换,会读取当前节点的文件,若之前该节点没有配置过,则会丢失标签配置
到该机器上执行以下指令
yarn rmadmin -removeFromClusterNodeLabels "CORE" yarn cluster --list-node-labels yarn rmadmin -addToClusterNodeLabels "CORE(exclusive=true)" yarn cluster --list-node-labels
去除上述设置:
yarn rmadmin -removeFromClusterNodeLabels "CORE" yarn cluster --list-node-labels yarn rmadmin -addToClusterNodeLabels "CORE(exclusive=false)" yarn cluster --list-node-labels
若是在stand by状态的节点中使用指令,则会出现以下报错并自动Failing over to 下一个RM
yarn cluster --list-node-labels 22/06/15 07:53:23 INFO client.ConfiguredRMFailoverProxyProvider: Failing over to rm2 Node Labels:
所以需要对该文件进行备份
先去active节点的对应路径
cd /var/lib/hadoop-yarn/nodelabels/ ll total 4 -rw-r--r-- 1 yarn yarn 0 Jun 12 10:10 nodelabel.editlog -rw-r--r-- 1 yarn yarn 18 Jun 12 10:10 nodelabel.mirror
使用以下指令开启内网文件传输接口
python2 -m SimpleHTTPServer 9999 Serving HTTP on 0.0.0.0 port 9999 ...
登录另外2台stand by 节点,执行下面的指令
重点:使用yarn用户,保证文件的用户和组是yarn
su - yarn cd /var/lib/hadoop-yarn/nodelabels/ mkdir bak mv nodelabel* bak ll wget http://active节点的机器IP:9999/nodelabel.editlog wget http://active节点的机器IP:9999/nodelabel.mirror ll
官方建议将该配置文件上传至S3桶,并修改yarn-site.xml的node-labels参数路径为S3
yarn-site.xml:yarn.node-labels.fs-store.root-dir S3中放置标签文件的路径
如果要统一使用该路径的话,则建议直接在实例组启动配置中设置好。
而且如果使用这种方法,后面删除标签配置的指令可能无法生效,因为S3桶文件不能进行编辑。因此不建议使用该方法,因为风险不可控。
- 增加 Znode 的储存空间
如果集群运行时间过长,而且扩缩容频繁的话,需要调整Znode 的储存空间。
当发生 ResourceManager (RM)重启的情况时, ResourceManager 将 Decommissioned Nodes,Lost Nodes 等信息更新时间刷新为最新时间,然后 instance Controller (IC)服务将这些节点信息刷新到 IC 的Zookeeper Node(Znode)上,但是默认 Znode 的储存空间为1M,如果这些信息大于1M就无法写入Znode,再导致 IC 判断集群出现异常而触发保护机制,即EMR集群将24小时内无法扩缩容。
因此,对于长时间运行且扩缩容频繁的集群来说,需要调整EMR集群的 IC 的 Znode 和 instance Controller 的 maxbuff,是因为 Znode 节点默认存储大小为 1M, ic 将 rm 的节点信息写入到 Znode 中存在可能大于1M的情况。而且 IC 写入到 Znode 的过程中,会将数据放到自己的buffer,所以 IC 本身的maxbuff也需要调整。
1: 将下面的参数(单位 字节)
JVMFLAGS="-Djute.maxbuffer=3145728"
添加下面的文件内
vi /usr/share/aws/emr/instance-controller/zookeeper/conf/zookeeper-env.sh
2:将 instance controller 使用到的 zookeeper 进行重启
systemctl stop ic-zookeeper-quorum systemctl start ic-zookeeper-quorum
3,备份文件后,使用如下命令替换 instance controller 中的最大缓存
cp /usr/bin/instance-controller /usr/bin/instance-controller_bak sudo sed -i 's/-Xmx1024m/-Xmx1024m -Djute.maxbuffer=3145728/' /usr/bin/instance-controller
4,将 instance-controller 进程重启
systemctl stop instance-controller systemctl start instance-controller
※注意修改2个服务重启的顺序不能颠倒,因为 instance controller 需要依赖 ic-zookeeper
- 配置自动群里log的指令
/emr 磁盘被AWS侧程序生成的日志文件写满,所以目前我们这边进行的下面操作仅为缓解问题而没有解决根因,根因需要AWS侧给出修复补丁解决不停生成的job-flow-state.txt文件才行
目前通过手动配置脚本自动备份log文件到S3桶里
crontab -e 30 15 * * * find /emr/instance-controller/lib/info/ -mtime +1 -name "*job-flow-state.txt.2*" -exec aws s3 mv {} s3:///log/ / ; > /dev/null
此命令的用途是于每天UTC+0 15:30(中国时间 23:30) 将 /emr/instance-controller/lib/info/ 下超过一天的 job-flow-state.txt 移动到 s3 桶里
请记得替换上列命令
- 拉起的节点长时间处于【正在引导】
当节点超过15分钟还处于【正在引导】,需要开case咨询AWS
AWS侧发现的报错是因为hive metastore配置的RDS instance已经被删除,所以在节点启动时出现“HiveMetaException: Failed to get schema version”以及“Could not connect to address”报错,从而节点启动失败。
原因:
在关闭节点后,AWS侧自动拉起新的节点,但是由于新节点中的HiveMetaStore服务连接是不可用的,所以每次拉起时,Metastore服务都会启动失败而导致整个节点启动失败。
解决方法:
先将两台还启动中的机器metastore连接改成可用的,并重启服务
再将不停重启的机器的metastore链接修改成可用的,并重启服务
登录不停重启的机器后立刻修改以下路径文件
vi /etc/hive/conf/hive-site.xml
根据【MetaStore】修改
javax.jdo.option.ConnectionURL *****
修改完后,观察服务运行状态
相关指令参考这个:
重启 Amazon EMR 中的服务
查看服务状态,如果显示running则说明没问题
systemctl status hive-hcatalog-server ● hive-hcatalog-server.service - HCatalog server Active: active (running)
再去EMR服务中查看该节点是否正常运行中
点击刷新按钮后,显示正在运行则说明没有问题
如果出现下面信息,则说明服务启动失败,需要手动重启
systemctl status hive-hcatalog-server [root@ip-10-1-56-222 conf]# systemctl status hive-hcatalog-server ● hive-hcatalog-server.service - HCatalog server Active: failed (Result: exit-code) Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
手动启动服务后再查看服务状态
systemctl start hive-hcatalog-server
登录其他机器链接该节点的hive服务,检查服务是否正常开启
hive --hiveconf hive.metastore.uris=thrift://重启的IP:9083
正常登录hive后,查看是否能正常查询,有结果出来则说明没问题
show databases;