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人で実施

• 何時間も人が張り付き、同じ作業を繰り返していた

• メンテ中ユーザの利用不可

• 事前に日程調整必須（調整だけでも数週間）

• 事後にはジョブの実行順整理も必須

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



無停止アップグレード

処理ストレージ

MapReduce

Hive Spark … ReplicaCheck

missing

AmbariのCustom Serviceを利用スクリプトでコントロール

Ansibleで自動化

課題：Ambariのアップグレードでは不十分


• Express Upgradeはクラスタが停止してしまう

• 当然Jobが失敗するので不可

• Rolling Upgradeでも問題がある

• HiveServer2に適用しているロードバランサを

コントロールできないため影響あり

• DataNodeリスタートを細かくコントロールができない

対応：Ambariのオペレーションを拡張


• 安全なリスタートや環境に合わせた機能を追加

• Ambari Custom Serviceとして実装

• 詳細は後ほど

• Ambari CLI*を実装

• 正常性確認の強化

• データを意識した細かいコントロール

*Ambari, NN, RM等のAPIをラップした独自ツール




MapReduce


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時間

並列実行




MapReduce


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 connectionJob submit




MapReduce


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時間程度

まとめ



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

写真: アフロ

Technology

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