Ozone OM服务的HA配置搭建

前言

---

在上文中，笔者阐述了Ozone OM服务HA的内部机理，但是没有介绍其是如何配置使用的。本文笔者结合自己在测试环境中的HA搭建过程，来补充介绍下这块的实际配置过程以及中间可能存在的坑。想了解OM HA背后更多的原理方面的内容，可阅读笔者的上一篇文章Ozone OM服务HA原理分析。

OM HA的配置初始化

---

与HDFS NameNode的Active/Standby服务角色分类不同，OM HA采用的是基于Raft协议方式来实现服务状态的一致性控制。基于此协议的实现下，OM服务被分为1个Leader，多Follower的模式，一般我们会设定2N+1个服务。2N+1的设定能保证在领导投票选举过程中能够出现半数以上的投票结果，避免出现同票数的情况。

因此在笔者的测试环境下，笔者设定了3个OM服务，此3个服务将分布部署在以下机器中：

• lyq-m1-xx.xx.xx.xx
• lyq-m2-xx.xx.xx.xx
• lyq-m3-xx.xx.xx.xx

因为要使用Raft协议的HA实现方式，需要开启om ratis(raits为Raft的Java实现库)选项，再配置好om metastore db的位置信息：

  <property>
    <name>ozone.om.db.dirs</name>
    <value>/home/hdfs/data/meta</value>
  </property>

  <property>
    <name>ozone.om.ratis.enable</name>
    <value>true</value>
  </property>

在OM HA模式下，同样也有service的定义，这里笔者的配置service id如下所示：=

  <property>
    <name>ozone.om.service.ids</name>
    <value>om-service-test</value>
  </property>

然后是对应此om service下的om node id,用以区别不同的OM service，

  <property>
    <name>ozone.om.nodes.om-service-test</name>
    <value>omNode-1,omNode-2,omNode-3</value>
  </property>

目前Ozone OM暂不支持OM federation的方式，因此ozone.om.internal.service.id并不需要配置。不过如果OM在未来支持多nameservice的情况，还是需要额外配置internal service id来指定启动哪个nameservice下的OM服务。

定义好上述OM HA的基本配置后，后面就是具体om id下的RPC/Http地址的配置了，每个om节点3个配置项，3个om就是9个配置项，配置结果如下：

  <property>
    <name>ozone.om.address.om-service-test.omNode-1</name>
    <value>lyq-m1-xx.xx.xx.xx:9862</value>
  </property>

  <property>
    <name>ozone.om.http-address.om-service-test.omNode-1</name>