Hadoop -ResourceManager HAの仕組み-

Hadoop研修 –ResourceManager HAの仕組み-
2018/06 Ver.1.0
JBSテクノロジー株式会社権田祐樹

自己紹介
■所属/氏名
- JBSテクノロジー株式会社
- 権田祐樹 (Yuki Gonda)
■略歴 ※2018/06現在
- Linux歴 9年 (運用保守3年、構築6年)
- 某通信会社のサーバ構築自動化など
- Hadoop歴 4カ月
- Hadoopの構築/運用/保守(150台規模)
- HDPのバージョンアップに向け準備中！
■趣味
- 写真 (Canon EOS 7D所有)
- 映画 (昔は年間100本くらい…)
- 読書 (月1冊程度)

会社紹介
名称
所在地
設立
社員数
事業拠点
JBSテクノロジー株式会社
虎ノ門ヒルズ森タワー16F
2004年6月1日
958名（2018年6月現在）
北海道事業所
中部事業所
西日本事業所
九州事業所
データの山からビジネスの種の
掘り起こしをお手伝い！
Hadoopには、2013年から
取り組んでいます。
有資格者を含めて10名以上
のHadoopエンジニアが
所属しています。
Cloudera on Azure
サービスも提供中

はじめに
本資料は、社内で実施したHadoopエンジニア育成研修の中で取り組んだ課
題のアウトプット資料です。
Hadoop (主に ResourceManager、NodeManager) についての基礎知
識があり、ResourceManager HA について詳しく知りたい人向けの内容となっ
ております。
見ていただいた方にとって、少しでもお役に立てれば幸いです。

課題とスケジュール
研修
ステップ
1か月目 2か月目 3か月目
Linux研修
基本的なOSインストールから
Hadoopに必要な設定や
ログの追い方を習得
ステップ1
Hadoop研修（基礎/応用）
Hadoopの概要理解から手動構
築、管理ツールを利用した構
築、マスターコンポーネント
の高可用性設定を習得
ステップ2
Hadoop研修（エコシステム）
HiveやImpala、Rangerなどのエ
コシステムの理解と実装、運用の
際の考慮点等を習得
ステップ3
ステップ1 ステップ2 ステップ3
ResourceManager
HA
※今回はここ
Linux研修 Hadoop研修
（基礎 / 応用）
Hadoop研修
（エコシステム）
ステップ
完了

Agenda
ResourceManager HA 化の必要性
ResourceManager HA に関する設定項目
ResourceManager HA全体構成図
ResourceManager HA構成の動き
Hadoopクラスタ全体構成図
ResourceManager HA 化前後の比較
ResourceManager HA 化前提条件
ResourceManager HA 化手順

研修で構築したHadoopクラスタ全体構成図
Active NN Active RM
JobHistoryServer
Master
・DataNode
・NodeManager
・Repository Server
・NTP Server
Slave
Ambari
Server
MySQL
管理系
Standby NN
Standby RM

ResourceManager HA 化の必要性
1
0
ResourceManager
NodeManagerの死活監視、及びクラスタ全体のリソースを一元管理し、
ジョブ実行する際のリソースの割り当て等を行うため、ダウンするとジョブが実行できない
⇒ ResourceManagerのHA化が必要
ResourceManager を HA 構成にすることで、F/O を自動的に実施する
Active-Standby の構成となる。

ResourceManager HA 化前提条件
今回は、以下を前提条件として ResourceManager HA化を実施
- HDPバージョン：2.4.2
- Ambariバージョン：2.5.2
- Ambariにて、以下の構成でHadoopクラスタ構築済み
(NameNode HA化済み)
Active NN ResourceManager
JobHistoryServer
Master
・DataNode
・NodeManager
Slave
Ambari
Server
MySQL
管理系
Standby NN

ResourceManager HA化
RM HA化開始
ホスト選択
デプロイ前確認
コンポーネント構築
HA設定完了
参考手順：
ResourceManager High Availability

RM HA化開始
「YARN」＞「Service Actions」＞「Enable ResourceManager HA」を選択

RM HA化開始
「Next」をクリック

追加ResourceManagerを実行させるホストを選択
ホスト選択

デプロイ前確認

コンポーネント構築

HDFSサービスの再起動が必要なので再起動実施
HA設定完了

RM HA化前後のサービス配置比較
①NameNode
②ZooKeeper
③JournalNode
④ZKFailOverController
①ResourceManager
②HistoryServer
③ZooKeeper
④JournalNode
⑤ZKFailOverController
①NameNode
②ZooKeepr
③JournalNode
⑤ResourceManager
①NameNode
②ZooKeeper
③JournalNode
①ResourceManager
②HistoryServer
③ZooKeeper
④JournalNode
⑤ZKFailOverController
①NameNode
②ZooKeepr
③JournalNode
HA化
Master#1
Master#2
Master#3
Master#1
Master#2
Master#3
※NN HA化後に RM HAを実施している為、JournalNode、ZKFC が既に配置されている状態となっています

ResourceManager HAに関する設定項目
yarn-site.xml に HA に関するプロパティが追加されている
<name>yarn.resourcemanager.ha.automatic-failover.zk-base-path</name>
<value>/yarn-leader-election</value>
⇒ ZKでリーダー選挙をする際に、リーダー情報を格納するために使用する基本zノードパス
<name>yarn.resourcemanager.ha.enabled</name>
<value>true</value>
⇒ RMのHA有効
<name>yarn.resourcemanager.ha.rm-ids</name>
<value>rm1,rm2</value>
⇒ 個々のResourceManager ID

ResourceManager HA全体構成図
ZK1 ZK2 ZK3
ResourceManager
(Active)
ActiveStandbyElector
NodeManager群
HeatbeatHeatbeat
ResourceManager#1 ResourceManager#2
セッション管理
Active選出
ジョブ情報読込
ジョブ情報保存
/rmstore/ZKRMStateRoot
/yarn-leader-election
一時znode
永続znode
ZKRMStateStore
ResourceManager
(Standby)
ZKRMStateStoreセッション管理
Active選出
F/O時ジョブ情報読込

ZK1 ZK2 ZK3
ResourceManager
(Active)
NodeManager群
Heatbeat③Heatbeat
①Active選出
②ジョブ情報読込
ジョブ情報保存 /rmstore/ZKRMStateRoot
一時znode
永続znode
ZKRMStateStore
ResourceManager
(Standby)
ZKRMStateStore①Active選出
①RMは起動の際、ZKの/yarn-leader-election配下にLockファイル(znode)が作成される
⇒ 書き込みに成功した方が Active となる
②Active RMは起動後、ZKよりRMStoreをロード
③Active RMは、NodeManagerからのハートビートを受信しクラスタリソース情報を作成

ZK1 ZK2 ZK3
ResourceManager
(Active)
NodeManager群
Heatbeat③Heatbeat
Active選出
②
ZKRMStateStore
ResourceManager
(Standby)
ZKRMStateStore
Active選出
①RMは起動の際、ZKの/yarn-leader-election配下にLockファイル(znode)が作成される
⇒ 書き込みに成功した方が Active となる
yarn-yarn-resourcemanager-[ResourceManager#1].logより抜粋
INFO ha.ActiveStandbyElector - Writing znode /yarn-leader-election/yarn-cluster/ActiveBreadCrumb
to indicate that the local node is the most recent active...
ZKに接続し確認
ls /yarn-leader-election/yarn-cluster
[ActiveBreadCrumb, ActiveStandbyElectorLock]
※ActiveStandbyElectorLock：一時 znode ※ZKとのセッションが切れると消滅
※ActiveBreadCrumb：永続 znode ※Active RMの情報が記載されている
②Active RMは起動後、ZKよりRMStoreをロード
INFO recovery.ZKRMStateStore - ZKRMStateStore Session connected
INFO recovery.ZKRMStateStore - ZooKeeper sync operation succeeded. path: /rmstore/ZKRMStateRoot

ResourceManager HA構成の動き(F/O時)
ZK1 ZK2 ZK3
ResourceManager
(Active)
NodeManager群
HeatbeatHeatbeat
Active選出
③一時znode
永続znode
ZKRMStateStore
ResourceManager
(Standby)
ZKRMStateStoreActive選出
①ActiveであるResourceManager#1がダウン
②ZKとのセッションが消える
③ResourceManager#1が作成した一時znodeが消滅する
①
②

ZK1 ZK2 ZK3
ResourceManager
(Active)
NodeManager群
HeatbeatHeatbeat
Active選出
③一時znode ④一時znode
⑤永続znode
ZKRMStateStore
ResourceManager
(Standby
⇒ ⑥ Active)
①
②
④StandbyであるResourceManager#2が一時znodeの作成を試みる
⇒ 成功するとActiveの権利を得る
⑤ResourceManager#2は/yarn-leader-election/配下にある永続znodeを書き換える
⑥ResourceManager#2がActiveになる
INFO ha.ActiveStandbyElector - Checking for any old active which needs to be fenced...
INFO ha.ActiveStandbyElector - Old node exists: 0a0c7961726e2d636c75737465721203726d32
INFO ha.ActiveStandbyElector - Writing znode /yarn-leader-election/yarn-cluster/ActiveBreadCrumb
to indicate that the local node is the most recent active...
INFO resourcemanager.ResourceManager - Transitioning to active state

ZK1 ZK2 ZK3
ResourceManager
(Active)
NodeManager群
⑧HeatbeatHeatbeat
Active選出
③一時znode ④一時znode
⑤永続znode
ZKRMStateStore
ResourceManager
(Standby
⇒ ⑥ Active)
⑦F/O時ジョブ情報読込
①
②
⑦ResourceManage#2はZooKeeperよりRMStoreをロード
INFO recovery.ZKRMStateStore - ZKRMStateStore Session connected
INFO recovery.ZKRMStateStore - ZooKeeper sync operation succeeded. path: /rmstore/ZKRMStateRoot
INFO recovery.RMStateStore - Loaded RM state version info 1.2
⑧NMからのハートビートを受信しクラスタリソース情報を作成

参考：ZooKeeper 一時znodeの中身
ZK1 ZK2 ZK3
ResourceManager
(Active)
NodeManager群
⑦Heatbeat③Heatbeat
⑤Active選出
⇒一時znode作成
ZKRMStateStore
ResourceManager
(Standby)
ZKRMStateStoreZKとのセッション断
⑥F/O時ジョブ情報読込
ZooKeeperに接続し確認
# sh /usr/hdp/2.4.2.0-258/zookeeper/bin/zkCli.sh
get /yarn-leader-election/yarn-cluster/ActiveStandbyElectorLock
yarn-clusterrm2 ※現在のActiveノードのID
cZxid = 0x900000033
ctime = Tue Apr 17 11:10:56 JST 2018 ※ctime=znodeが作成された時刻
mZxid = 0x900000033
mtime = Tue Apr 17 11:10:56 JST 2018 ※mtime=znodeが更新された時刻
pZxid = 0x900000033
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x162d15ab230000f
dataLength = 19
numChildren = 0

参考：ZooKeeper 永続znodeの中身
ZK1 ZK2 ZK3
ResourceManager
(Active)
NodeManager群
⑦Heatbeat③Heatbeat
⑤Active選出
⇒一時znode作成
ZKRMStateStore
ResourceManager
(Standby)
ZKRMStateStoreZKとのセッション断
⑥F/O時ジョブ情報読込
ZooKeeperに接続し確認
# sh /usr/hdp/2.4.2.0-258/zookeeper/bin/zkCli.sh
get /yarn-leader-election/yarn-cluster/ActiveBreadCrumb
yarn-clusterrm2 ※現在のActiveノードのID
cZxid = 0x70000002c
ctime = Mon Apr 16 11:50:37 JST 2018 ※ctime=znodeが作成された時刻
mZxid = 0x900000034
mtime = Tue Apr 17 11:10:56 JST 2018 ※mtime=znodeが更新された時刻
pZxid = 0x70000002c
cversion = 0
dataVersion = 4
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 19
numChildren = 0

RMStoreについて
ZK1 ZK2 ZK3
ResourceManager
(Active)
ResourceManager#1
ZKRMStateStore
ResourceManager#2
ResourceManager
(Standby)
ZKRMStateStore
ResourceManagerは処理中に以下の情報をメモリに保持している
- 実行中アプリケーションの状態に関する情報
ResourceManager を F/O するには上記の情報をいずれかの場所に格納しておく必要があり、
格納しておくための Store を RMStore という
これにより、処理中に F/O が発生しても処理が継続される

RMStoreについて
ZKに接続し、RMStoreの中身を確認
ls /rmstore/ZKRMStateRoot/RMAppRoot/
application_1522729518001_0001
application_1522803123236_0001
application_1522803123236_0003
application_1522803123236_0002
application_1522803123236_0005
application_1523854479035_0002
application_1522803123236_0004
application_1522803123236_0006
application_1522724639487_0002
application_1522724639487_0004
：
省略
⇒ アプリケーションIDの名前がついた znode が格納されている

RMStoreについて
ZK1 ZK2 ZK3
ResourceManager
(Active)
ResourceManager#1
ZKRMStateStore
ResourceManager#2
ResourceManager
(Standby)
ZKRMStateStore
Pi計算中にRMStoreを確認みる
$ yarn jar /usr/hdp/current/hadoop-mapreduce-client/hadoop-mapreduce-examples.jar pi 10 100000
：
INFO impl.YarnClientImpl: Submitted application application_1523855487035_0001
⇒ アプリケーションIDが出力されたタイミングで RMStore を確認
ls /rmstore/ZKRMStateRoot/RMAppRoot/
application_1522729518001_0001
application_1522803123236_0001
application_1522803123236_0003
application_1522803123236_0002
application_1522803123236_0005
application_1523854479035_0002
application_1522803123236_0004
application_1522803123236_0006
application_1522724639487_0002
application_1523855487035_0001
：
⇒ アプリケーションを実行した瞬間に znode が作成された
処理中にF/Oした場合、新たに Active になる RM が RMStore の情報をロードする為、
処理が継続できる。

RMStoreについて
ZK1 ZK2 ZK3
ResourceManager
(Active)
ResourceManager#1
ZKRMStateStore
ResourceManager#2
ResourceManager
(Standby)
ZKRMStateStore
Active の RM からしか RMStore へのファイル(znode)作成はできない
- Active RM のみファイル(znode)の作成/削除の権限を有している
- Active RM がファイル(znode)の作成権限を独占することによって暗黙的にフェンシングが成立している
そのため、RMStore にファイル(znode)を作成できる ResourceManager は必ず1つとなり、
NN HA における ZKFC のような仕組みがなくてもスプリットブレインは発生しない
ジョブ情報保存ジョブ情報保存

RMStoreについて
ZK1 ZK2 ZK3
ResourceManager
(Active)
ResourceManager#1
ZKRMStateStore
ResourceManager#2
ResourceManager
(Standby)
ZKRMStateStore
ZooKeeper に接続し、権限を確認
getAcl /rmstore/ZKRMStateRoot
'world,'anyone
: rwa
'digest,‘[ResourceManager#1]:yWb/HqqmNPY1s9sgTgRuQbvwNyo=
: cd
⇒ Active RMである ResourceManager#1 に、作成/削除の権限があることが分かる
パーミッションの説明：
CREATE: 子ノードを作成可能
READ : ノードのデータと子のリストを取得可能
WRITE : ノードのデータを設定可能
DELETE: 子ノードを削除可能
ADMIN : パーミッションを設定可能

お問い合わせ先
何かございましたら、下記よりお問い合わせください。
http://www.jbst.co.jp/contact/

Hadoop -ResourceManager HAの仕組み-

Hadoop -ResourceManager HAの仕組み-

More Related Content

What's hot

Similar to Hadoop -ResourceManager HAの仕組み-

Hadoop -ResourceManager HAの仕組み-