AWS EMR集群的Master节点重启流程

一、背景

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文件中的对应参数，

<property>
    <name>javax.jdo.option.ConnectionURL</name>
   <value>*****</value>
   <description>*****</description>
  </property>


  <property>
    <name>javax.jdo.option.ConnectionDriverName</name>
    <value>******</value>
    <description>******</description>
  </property>


  <property>
    <name>javax.jdo.option.ConnectionUserName</name>
    <value>*****</value>
    <description>*****</description>
  </property>


  <property>
    <name>javax.jdo.option.ConnectionPassword</name>
    <value>*******</value>
    <description>*****</description>
  </property>

！！！重要！！！

如果这里的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

查看调度规则是否有配置

<property><name>yarn.resourcemanager.scheduler.class</name>

注意查看当前路径下是否有对应的调度文件，如果没有，则需要上传或者从其他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: <CORE:exclusivity=true>

所以需要对该文件进行备份

先去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:  <property><name>yarn.node-labels.fs-store.root-dir</name><value>S3中放置标签文件的路径</value></property>

如果要统一使用该路径的话，则建议直接在实例组启动配置中设置好。

而且如果使用这种方法，后面删除标签配置的指令可能无法生效，因为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://<S3 bucket>/log/<ec2-id>/ \; > /dev/null

此命令的用途是于每天UTC+0 15:30（中国时间 23:30）将 /emr/instance-controller/lib/info/ 下超过一天的 job-flow-state.txt 移动到 s3 桶里

请记得替换上列命令<S3 bucket>为对应区域的桶名，<ec2-id> 为对应实例的ec2 id

三、异常情况

拉起的节点长时间处于【正在引导】

当节点超过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】修改

<property>
   <name>javax.jdo.option.ConnectionURL</name>
   <value>*****</value>

修改完后，观察服务运行状态