Automation of Rolling Upgrade of Hadoop Cluster without Data Lost and Job Failures - Hadoop Source Code Reading #22 #hadoopreading

Automation of Rolling Upgrade of Hadoop
Cluster without Data Lost and Job Failures
Hadoopソースコードリーディング第22回
ヤフー株式会社
安達寛之、山口寛
2017年3月3日

自己紹介
2Copyright (C) 2017 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
• 安達寛之
• 新卒１年目
• 半年ほど前からHadoopの運用、
自動化を担当
• 趣味：エレクトーン

自己紹介
• 山口寛
• 2012年入社
• 〜 2015/10 広告レポートシステム
• 2015/10 〜 Hadoop運用
• 運用ツール作成
• 運用作業の自動化
• 趣味：ビール

Hadoopのマイナーアップグレードを
無停止＆自動化して実施しました
Copyright (C) 2017 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 4

アジェンダ
• なぜ無停止&自動化
• 実現したいこと
• どのようにアップグレードしたか
• 自動化苦労話
• まとめ

なぜ無停止にするのか？
なぜ自動化するのか？

Yahoo! JAPANのHadoopクラスタ
• HDP 2.3.x + Ambari 2.2
• Master Node
• NN, RM, JN, JHS, ATS
• HiveServer2, Oozie, HttpFS
• Slave Node
• 800 DataNodes/NodeManagers

Yahoo! JAPANのHadoopクラスタ
• ジョブ実行
• 2〜3万 job / day
• ストレージ利用
• 50〜60TB / day
• Total 37PB
写真: アフロ

クラスタ停止の影響
• ビジネス影響大
• 数万のジョブが止まる
• データにもアクセスできない
• 運用コストもかかる
• 大量のジョブリカバリのための
調整が必要
写真: アフロ

ユーザジョブへの影響を最小限に

なぜ無停止にするのか？
なぜ自動化するのか？

面倒でも自動化できることは自動化する
by Cay Horstmann

同じ作業や時間がかかる作業が多い
• HA構成されたコンポーネント
• 各コンポーネントで同じ作業を実施が必要
• 大量のSlaveNode
• 同一作業は機械的に実施
写真: アフロ

実現したい２つのこと

1. ユーザ影響を出さない
2. 運用コストの削減

1. ユーザ影響を出さない
• ジョブ実行、HDFSの読み書きに影響を出さない
• 提供コンポーネントの動作を保証する
※ ただしHA構成でないものを除く

2. 運用コストの削減（過去の実績）
バージョンアップ作業実績
(※ Meta情報更新を含むメジャーアップデート）
• 12時間 * 10人で実施
• 何時間も人が張り付き、同じ作業を繰り返していた
• メンテ中ユーザの利用不可
• 事前に日程調整必須（調整だけでも数週間）
• 事後にはジョブの実行順整理も必須

どのようにアップグレードしたか

無停止アップグレード
処理ストレージ
Map
Reduce
Hive Spark … Replica
Check
missing
AmbariのCustom Serviceを利用スクリプトでコントロール
Ansibleで自動化

課題：Ambariのアップグレードでは不十分
• Express Upgradeはクラスタが停止してしまう
• 当然Jobが失敗するので不可
• Rolling Upgradeでも問題がある
• HiveServer2に適用しているロードバランサを
コントロールできないため影響あり
• DataNodeリスタートを細かくコントロールができない

対応：Ambariのオペレーションを拡張
• 安全なリスタートや環境に合わせた機能を追加
• Ambari Custom Serviceとして実装
• 詳細は後ほど
• Ambari CLI*を実装
• 正常性確認の強化
• データを意識した細かいコントロール
*Ambari, NN, RM等のAPIをラップした独自ツール

Map
Reduce
Check
missing
Ansibleで自動化

Ansible
• 構成管理ツールの一種
• 全体のアップグレードフローをコントロール
• Chefと比較して
• 学習コストが低い
• エージェントレス
• 順序制御がやりやすそう

Ansibleによるアップグレード概要図
Ansible
Ambari CLI
クラスタ管理
各コンポーネントの構成管理
アップグレード順序の制御
写真: アフロ

アップグレードフロー
Preparing Registering Installing Upgrading Finalize
c.f. https://docs.hortonworks.com/HDPDocuments/Ambari-2.1.1.0/bk_upgrading_Ambari/content/_manual_minor_upgrade.html
メタデータの
バックアップなど
新バージョンの
レポジトリの登録
全ホストに
新バージョンを
インストール
サービス停止
各ホストの
バージョンを更新
サービス再開
ファイナライズ
新バージョン
として稼働
Ansible Ambari AnsibleAmbari 手動

アップグレードフロー詳細
マスター系
• ZooKeeper
• NN, JN, JHS, ATS, RM
アプリケー
ション系
• HttpFS, Oozie
• HiveMeta, HiveServer2
スレーブ系
• DataNode
• NodeManager
クライ
アント系
• MapReduce2, Spark, YARN, HDFS, Oozie, Tez,
Hive, ZooKeeper, HCat, Pig
3時間
4時間
7.5時間
0.5時間
並列実行

Map
Reduce
Check
missing
Ansibleで自動化

Ambari Custom Service
• その名の通り、独自にカスタマイズしたサービスを
Ambariに追加することができる
• 運用コマンド等を追加
• NameNode F/O
• ロードバランサ In/Out

Ambari Custom Service
• サービス構成xmlとPythonスクリプトを配置し、
Ambariにサービスとして追加するだけで、
既存のものと同様にUIやAPIからオペレーション可
• サーバにログインしてコマンドを打つ必要がなく、
オペミスも防げる

Ambari CLI
• 運用のために独自に作成したスクリプト
• Ambari, NameNode, ResourceManagerなどの
APIをラップし、より安全なオペレーションを提供

例: HiveServer2の安全なリスタート
• 各コンポーンネントごとに安全に外す手順を確立
• 実行中のジョブに影響を与えない
写真: アフロ
Load balancer
HiveServer2
Client
Wait for jobs to be finished
Established connection
Job submit

Map
Reduce
Check
missing
Ansibleで自動化

DataNodeの安全なリスタート
• データ配置を考慮し横一列でリスタート
• MissingBlockなどが解消されるのを待つ
MissingBlocks: 0
UnderReplicatedBlocks: 0
CorruptBlocks: 0
写真: アフロ

各コンポーネントのテストジョブを作成
• HDFS, MapReduce
Hive, Hive on Tez, Pig, Spark
HttpFS, Oozie
• バージョンアップ中に常時実行するようにし、
ジョブに影響が出ていないことを確認

アップグレードの結果

ほぼ無停止
コンポーネント無停止バージョンアップ成否備考
HDFS ○
HttpFS ○
MapReduce ○
Hive ○
Pig ○
Spark △
Hive Merastoreとの接続が切れ、
一部のジョブが失敗
HiveServer2 △
mapreduce.tar.gzが置き替わり、
checksum不一致で一部のジョブが失敗
Oozie △ HA構成ではないので数分間停止

半自動化
• 大規模環境で発生した問題と対応
• NN Health Check失敗によるFailover失敗
• NNリスタート時にメモリ不足で立ち上がらない
• メモリを解放しきる前に立ち上げようとして失敗
• DNリスタート失敗
• stop/startの間にpidファイルが消えていなかったため

自動化苦労話

Pre/Post Action
• AmbariのAction(Start, Stop, Restart, etc.)に
Pre-StartやPost-Startが定義できなかった
• プラグインで組み込めるようになっていると嬉しい
• ambari-server/src/.../hooks/before-START
をうまく使えばできる？

動作確認
• システムテストや受け入れテストになるのでツライ
• アップグレード作業の検証に時間がかかる
• テストクラスタで数十分
• Stagingクラスタだと5時間程度

まとめ

君はアップグレード自動化が得意な
フレンズなんだね！
写真: アフロ

Automation of Rolling Upgrade of Hadoop Cluster without Data Lost and Job Failures - Hadoop Source Code Reading #22 #hadoopreading

More Related Content

What's hot (20)

Similar to Automation of Rolling Upgrade of Hadoop Cluster without Data Lost and Job Failures - Hadoop Source Code Reading #22 #hadoopreading (20)

More from Yahoo!デベロッパーネットワーク (20)

Automation of Rolling Upgrade of Hadoop Cluster without Data Lost and Job Failures - Hadoop Source Code Reading #22 #hadoopreading