生产EMR集群高可用升级

为什么升级

随着业务的发展，单master节点的集群存在越来越高的高可用风险，具体如下：

1、master节点一旦宕机，则整个EMR集群将进入不可用状态。

2、master节点上有HMS，一旦HMS服务故障，整个hive的读写都将会受到影响。

3、由于核心节点只有3个，EMR集群将hdfs的block副本数设置为1，也就意味着hdfs的block没有任何副本，一旦某个核心节点上的hdfs datanode宕机，则此节点上的所有block块都将丢失造成数据丢失。并且如果丢失的块超过了hdfs的限制，则hdfs将会进入到安全模式，不能对外提供写服务，这也意味这hdfs服务基本不可用。

4、master节点上有hdfs namenode，且namenode没有高可用机制，一旦namenode故障整个hdfs都将不可用，并且会影响整个集群的任务提交运行，此时整个集群也基本不可用。

5、master节点有运行hue，我们会使用hue做查询分析，一旦master节点出现故障，则hue服务将不可用，不能正常进行查询分析。

6、整个集群提供的资源不足，yarn队列经常处于满负荷的状态，任务出现排队等待、超时、获取不到资源被kill等情况。

一旦master节点出现故障宕机，那么整个EMR集群都将不可用。必须要对EMR集群进行高可用技术方案升级。

升级方案

针对EMR集群的升级只有一个核心思想，那就是消除当前集群中存在的所有单点风险，包括但不限于hdfs namenode的高可用，hms的高可用，hdfs的block多副本等等。

经过调研，我们决定采用如下的集群部署架构。

master节点部署多个组成实例组做HA，采用外部MySQL主备数据库作为hive，hue等组件的元数据外部持久化存储。

升级步骤

步骤

升级过程中只有一个核心指导方针，那就是不对原有集群造成任何影响，不对用户造成任何影响，对用户完全无感知。

所以我们采用新建集群，然后进行滚动迁移的方案进行操作。由于数据目前均存储在S3，所以不涉及数据的迁移，更多是元数据和自建服务相关的迁移。

具体步骤如下：

1、创建新的高可用架构的EMR集群。

2、集群环境初始化，包括但不限于git、python、Mongo、paimon、flink等等。

3、采用平台共用的MySQL主备数据库作为EMR集群相关组件的元数据持久化存储介质。提前创建相关database。

4、元数据迁移，采用MySQL dump的方式导出相关元数据，然后在新集群进行重放恢复。

• hive元数据迁移，主要包含hive库、表、列、分区等信息。

• hue元数据迁移，主要包含hue用户、权限等信息。

• sheepdog元数据迁移，主要包含flink session、flink job等信息。

• azkaban元数据迁移，主要包含project、flow、调度等信息。

5、自建服务迁移

• sheepdog服务迁移

• azkaban调度服务迁移

• grafana服务迁移，域名解析

6、任务迁移

• 离线调度任务迁移

• 实时Flink任务迁移。通过savepoint方式停止，在新集群从savepoint中恢复。

7、核对确认

• 数据核对

• 任务核对

• 相关服务健康检查

  
  

风险点及回滚方案