CDH HDFS HA 支持¶
https://blueprints.launchpad.net/sahara/+spec/cdh-ha-support
此蓝图旨在为 Cloudra 插件实现 HDFS 高可用性 (HA)。
问题描述¶
目前 Cloudera 插件不支持服务的 HA。我们计划将 HDFS HA 作为第一步实现。Yarn 和其他服务的 HA 将在后续步骤中实现。
提议的变更¶
HDFS HA 的实现将通过 CM API enable_nn_ha() 来完成。此 API 将通过提供一些信息增强来帮助我们启用 HDFS HA。
CDH 5 仅支持基于 Quorum 的存储作为唯一的 HA 实现，因此我们只会实现此方案。为此，我们需要添加一个备用 NameNode 和若干个 JournalNode。JournalNode 的数量应该是奇数，并且至少为 3。当 HDFS HA 启用时，SecondaryNameNode 将不再使用。因此，我们可以将用于 SecondaryNameNode 的节点重用于备用 NameNode。
HDFS HA 有一些硬件约束（请参阅参考链接）。但是，由于 Openstack 中的所有资源都是虚拟的，我们只需要确保 NameNode 和备用 NameNode 位于不同的物理主机上即可。
总而言之，我们将按以下方式实现 HDFS
添加一个角色 JournalNode。
如果用户（集群管理员）选择了 JournalNode，则将启用 HA。
如果启用了 HA，我们将验证 JournalNode 的数量是否满足要求。
JournalNode 角色在集群创建期间不会真正创建。实际上，它们将用作 CM API enable_nn_ha() 的参数。
如果启用了 HA，我们将使用 SecondaryNameNode 作为备用 NameNode。
如果启用了 HA，我们将设置反亲和性，以确保 NameNode 和 SecondaryNameNode 不位于同一物理主机上。
如果启用了 HA，则集群中需要 Zookeeper 服务。
集群启动后，我们将调用 enable_nn_ha 来启用 HDFS HA。
如果启用了 HA，在 Oozie workflow xml 文件中，我们将提供 nameservice 名称而不是 NameNode 名称，在 get_name_node_uri 方法中。以便集群可以自行确定哪个 NameNode 是活动的。
替代方案¶
无。
数据模型影响¶
无。
REST API 影响¶
无。
其他最终用户影响¶
无。
部署者影响¶
无。
开发者影响¶
无。
Sahara-image-elements impact¶
无。
Sahara-dashboard / Horizon 影响¶
无。
实现¶
负责人¶
- 主要负责人
Ken Chen
工作项¶
更改将仅在 sahara/plugins/cdh 目录中进行。目前，我们将仅基于 CDH 5.4.0 进行此操作。CDH 5.0.0 和 CDH 5.3.0 插件将不受支持。更改在“Proposed change”部分中描述。
依赖项¶
无。
测试¶
我们将仅进行基本检查：创建一个具有 HDFS HA 的 Cloudera 集群，并查看它是否处于活动状态。
文档影响¶
需要更新文档，其中包含有关启用 CDH HDFS HA 的信息。
参考资料¶
NameNode HA with QJM <http://www.edureka.co/blog/namenode-high-availability-with-quorum-journal-manager-qjm/>
Introduction to HDFS HA <http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/cdh_hag_hdfs_ha_intro.html>
Enable HDFS HA Using Cloudera Manager <http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/cdh_hag_hdfs_ha_enabling.html#cmug_topic_5_12_unique_1>
Configuring Hardware for HDFS HA <http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/cdh_hag_hdfs_ha_hardware_config.html>
