cloudera manager4.0とnamenode-haセミナー資料

CDHはなぜエンタープライズに適しているのか

嶋内翔

カスタマーオペレーションズエンジニア

アジェンダ

•  エンタープライズにおけるソフトウェアの要件 •  HDFS HA •  Cloudera Manager

エンタープライズにおけるソフトウェアの要件

CDH4 + Cloudera Enterprise 4.0: エンタープライズの要件とは…

スケーラビリティと拡張性

高可用性他のITとの統合

セキュリティ

設定と構築の単純化

グローバルサポートとサービス

他のITとの統合

セキュリティ

設定と構築の単純化

グローバルサポートとサービス

高可用性 4

セキュリティ

6 グローバルサポートとサービス

設定と構築の単純化 5

高可用性 4

セキュリティ

6 グローバルサポートとサービス

HDFS HIGH AVAILABILITY 高可用性HDFS

信頼性、保守性、可用性

•  reliability 信頼性 = MTBF/(1 + MTBF) •  MTBF: 平均故障間隔 •  1ヶ月に1回壊れるより1年に1回の方が信頼性が高

い •  maintainability 保守性 = 1 / (1 + MTTR)

•  MTTR: 平均復旧時間 •  素早く復旧する方が保守性が高い

•  availability 可用性 = MTTF / MTBF •  MTTF: 平均故障時間 •  MTBF = MTTF + MTTR •  信頼性と保守性が高いと可用性も高い

信頼性

•  データの信頼性 •  10クラスタ、20,000ノード上の3.29億ブロックのう

ち19ブロックがロスト(2009年) •  ※同一ファイルのブロックが全てロストする確率はほ

ぼ0 •  1700万ブロック中1ブロック(約4PB) •  原因となったバグは既に修正済み

データの信頼性は十分高い

信頼性(続き)

•  18ヶ月で、25クラスタの間で22回の障害 •  1クラスタあたり年間0.58回の障害

•  HAが役に立っただろうと考えられるのはうち8回の障害(0.23回分)

•  現在はもっと信頼性が上がっている

保守性

•  NN起動時間: 通常1-2分、大きなクラスタだと15分 •  計画停止するたびにこれだけの時間停止する→MTTR増える(保守性下がる)

•  日本で主流のHeartbeat + DRBD も、計画停止によるダウンタイムは回避できない

•  DNの保守性 •  大クラスタ: 1日1DNに障害発生、ディスクはもっ

と高頻度 •  3ヶ月に1回の割合で一斉に補修・入れ替え

可用性

•  HAがなくても障害停止における可用性は十分高い

年間稼働率(%)

HAなし 99.993

HAあり(予測) 99.996

注1 HAなしでの1回の平均ダウンタイムを60分として計算

注2 2009-‐2010年頃のデータを元にしているので、現在はもっと稼働率が高い

可用性

•  計画停止 •  設定変更のたびに再起動 •  アップデート時も当然再起動

ダウンタイムなく計画停止するための仕組みが必要

HDFS HA のデザイン概要 •  アクティブとホットスタンバイ間で状態を共有

•  ファイルシステムの状態 •  ブロックの位置

•  自動フェイルオーバ •  アクティブなNNの監視と障害時のフェイルオーバの実施

•  起動時にアクティブなNNを選出 •  必ず1個のアクティブしか起動しないことを保証

•  スプリットブレイン時のデータ破壊を防ぐ •  共有リソースのフェンシング

•  DN、及び共有ストレージ上のNNのメタデータ •  NNのフェンシング

•  共有リソースをフェンスできなかった場合 •  クライアントフェイルオーバ

•  クライアントはフェイルオーバ後に新しいNNにアクセスできる

NN外からのフェイルオーバ操作

•  一般的なHA製品と同じような設計 •  NN外にHAデーモンが存在する

•  開発が簡単 •  NN障害に影響を受けない

•  デーモンはリソースを管理する •  リソース: OS、ハードウェア、ネットワーク •  NNはただのリソースの一つ

•  実際の動作 •  アクティブNNは起動時に選ばれる •  自動フェイルオーバ •  フェンシング

•  共有リソース •  NN

アーキテクチャ

Daemon Daemon データノード

ネームノード (アクティブ)

ネームノード (スタンバイ)

Daemon Daemon ZooKeeper

フェイルオーバコントローラ

editlog

ブロックレポート

編集ログ (フェンシング)

コマンドコマンド

リーダー選択リーダー選択

状態監視状態監視

共有ストレージ(NFS)

ホットスタンバイ

Daemon Daemon データノード

editlog

編集ログ (フェンシング)

マニュアルフェイルオーバ

クライアントフェイルオーバの設計

•  スマートクライアント(クライアントサイドフェイルオーバ) •  ユーザは論理URIを使い、クライアントは正しいNNに

接続しにいく •  クライアントはどの操作が冪等か知っているので、

フェイルオーバをリトライしても問題ない •  クライアントはカスタム可能なフェイルオーバ/リトライ

ストラテジーを持つ •  現在の実装

•  クライアントは全NNのホスト名を設定する必要がある

自動フェイルオーバの設計

•  Zookeeperを使う •  手動フェイルオーバでは不要 •  ZKを使うと…

•  アクティブNNの障害検知が簡単になる •  アクティブNNの選定が簡単になる

•  両方のNNで　ZKFailoverController (ZKFC)というデーモンを動かす必要がある

•  ZKFCは以下のことを行う •  対象NNの状態監視 •  ZKセッション管理 •  ZKベースのアクティブNN選定

マスタサーバB マスタサーバA

自動フェイルオーバ

Daemon Daemon ZooKeeper

ZKFC ZKFC

アクティブ/スタンバイ切り替え

リーダー選択 ZKセッション管理

状態監視状態監視

リーダー選択 ZKセッション管理

アクティブ/スタンバイ切り替え

フェンシング

HAの運用:共有ストレージ

•  NNの状態を共有するために共有ストレージが必要 •  SPOF回避のため共有ストレージ自身もHA化す

る必要あり •  多くのHAソリューションにはIPフェンシング機能がある

•  推奨マウントオプション •  tcp,soft, intr, timeo=60, retrans=10

•  将来的にはNFSでなくBookKeeperベースになる予定(HDFS-3077)

HAの運用: NNフェンシング

•  NNは絶対に一つだけしかアクティブになってはいけない •  NNのメタデータは死守

•  サーバ外から以下の処理を行う •  RPCでアクティブNNをスタンバイにする(グレースフルフェイル

オーバ) •  SSHでアクティブNNに kill -9 を叩く

•  プラガブルオプション •  多くのNFSソリューションがIPベースのフェンシング機能を持つ •  多くのPDUがIPベースのSTONITHが可能

•  確実にフェンスする唯一の方法 •  「リモートから電源を引っこ抜く」ことに相当 •  OSがダウンした場合などに使う

HAの運用: 自動フェイルオーバ

•  ZKクラスタは奇数台で構築すること •  ZKは軽いので1つをNNに、1つをYARN　RM に共存

させてもいい •  ただしZK専用のディスクを作ることを推奨

•  あるいは既存クラスタを使ってもいい •  HBaseのZKクラスタを流用してもいい

•  フェンシングを設定すること •  アクティブNNに選ばれたNNのZKFCはフェンシング

を実行しなければならない •  手動フェイルオーバは可能だがZKFCを操作し

た方がいい

HAの運用: 監視

•  新しいNNメトリクス •  ペンディングされているDNのメッセージキューのサイ

ズ •  スタンバイNNが後に共有editsから読み込んでか

ら何秒経過したか •  DNのブロックレポートのタイムラグ •  スタンバイNNのタイムラグを測る指標

•  共有ストレージの監視ソリューション •  ディスク容量、ディスクの状態など

•  ファイル・テーブルアクセスベースの監視は効果的(ストール対策)

HAの運用: ハードウェア

•  アクティブ/スタンバイNNは別のラックに設置 •  共有ストレージも別のラックに設置 •  アクティブ/スタンバイNNは同一HW構成 •  あとはNNの推奨構成と同じ

•  ECCメモリ48GB •  複数の異なるディスクにメタデータを書く •  RAID5かミラーリング •  冗長電源

CLOUDERA MANAGER 4 ビッグデータ時代の運用管理ソフトウェア

Cloudera Manager(以下CM) とは？

•  CDHを1つのシステムとして扱い、あらゆる構築・運用のシナリオを統一されたインタフェースから行うための運用管理ツール

•  分散システムの熟知やコンポーネントの相互依存性などのCDHの運用・構築に必須の知識を必要としない

アーキテクチャ

•  集約型管理サーバ •  全デーモンとサービスの設定情報を管理 •  サービスと設定の作成・管理をするためのWeb

UI を提供

アーキテクチャ(続き)

•  エージェントは全てのノードで稼働 •  エージェントはHadoopの起動・停止に責任を持

つ •  設定はサーバから送信される •  デーモンが確実に稼働するようにし、もし起動に失敗

した場合はエラーを報告する •  サーバから指示されたコマンドを実行する •  デーモンのログへのアクセス手段を提供する •  必要なディレクトリが適切なパーミッションで存在

していることを確実にする

CM なしの CDH

DN/RS/NM

HMaster

管理者

CDH クラスタ

CM 導入後

DN/RS/NM

管理者

HMaster

Cloudera Manager

CMエージェント

Cloudera Manager 構成図

DN/RS/NM

管理PC

スイッチ

管理者はwebブラウザで CMにアクセス

設定情報やログ等は DBに保存

CM管理画面(サービス管理画面)

CM管理画面(設定管理画面)

CM 用語集

•  Service Types (サービスタイプ) •  サービスの種類を表す。例: HDFS, MapReduce, HBase

•  Service Instances (サービスインスタンス) •  サービス一単位を表す。例: hdfs1, mapred1

•  Role Types (ロールタイプ) •  サービスを構成するコンポーネントの種類を表す。例:

DATANODES, JOBTRACKER •  Role Instances (ロールインスタンス)

•  サービスを構成するコンポーネントの一単位を表す。例: datanode1

•  Commands (コマンド) •  サービスに対して実行する処理などを表す。例: Restart

CM4.0 の新機能

•  ホスト監視 •  複数クラスタ管理 •  API •  ローカルリポジトリからのインストール •  Ubuntu/Debian サポート •  PostgreSQL/Oracle サポート •  クライアントの設定管理 •  Cloudera のサポートとの連携機能強化

CM4.0 の新機能(続き)

•  ログローテート設定 •  国際化対応(日本語化!) •  Gatewayロールの追加(クライアント専用ロー

ル) •  CM管理者ユーザアカウントのLDAP連携 •  「アクティビティ」タブからジョブをkillできるよう

になった(MRとStreamingのみ) •  「レポート」タブからHDFS上のファイルの閲

覧と検索ができるようになった

CM Free Edition

•  ウェブサイトから自由にダウンロード可能 •  監視、アラート、イベント、ログ検索、

Kerberosサポートはありません •  50ホストまで管理可能 •  ライセンスキーでアップグレード可能(要再起

Free Edition と Enterprise Edition の違い

Free Edi-on Enterprise Edi-on サービス管理 ◯ ◯

設定管理 ◯ ◎(バージョン管理可能)

CDH一括インストール ◯ ◯

API ◯ ◯

管理ノード数制限 50ノードまで無制限

監視機能 -‐-‐ ◯

セキュリティ機能 -‐-‐ ◯

イベント機能 -‐-‐ ◯

入手方法無償でDL可 Cloudera Enterprise サブスクリプションがあれば誰で

も利用可

CMサーバインストール方法

•  ウィザードによるインストール •  自己解凍形式のインストーラ •  UIベースのウィザード •  高速かつシンプルなインストールが可能

•  マニュアルインストール •  ユーザが手動でインストールする •  柔軟性の高いインストールをしたいならこちら

CM4.0でのインストーラ

•  インストール時のカスタムリポジトリのサポート •  LAN内でインターネット接続ができなくても利用可能に

•  DB関連機能の強化 •  組み込みPostgreSQLのサポート

•  手動でのDBセットアップが必須でなくなった •  ウィザードでDBの自動設定が可能に

•  専用のDB設定インタフェースの追加 •  設定の誤りチェック

•  自動DBスキーマインストール・アップグレード •  CDHバージョンの選択が可能になった •  Debian/Ubuntu のサポート

SERVICE AND CONFIGURATION MANAGER クラスタの管理を簡単にする

•  Service and Configuration Manager (サービス・設定マネージャ)

•  プロセスの起動・停止、すなわちシステムのブートストラップを行う

•  設計思想 •  install everything, everywhere •  設定の集中管理

•  Free Edition ではほぼ全機能が使用可能 •  設定のバージョン管理機能のみEnterprise専用(後

サービス管理画面

コマンドメニュー

•  再起動なども簡単 •  HBase の graceful stop なども自動で行う

•  クラスタ単位の再起動が可能 •  停止順序などもきちんと考慮

設定管理画面

•  設定に問題がある場合は警告する •  下の図では2箇所に警告が出ている

•  NNと2NNのヒープサイズが異なる •  NNのヒープサイズが1GBを下回っている

設定はバージョン管理できる Enterprise Only

設定変更後は再起動を促す

マルチクラスタサポート

•  サービスはクラスタとしてグループ化される •  サービス設定と監視はクラスタ別に可能 •  複数の HDFS/MapReduce を管理できる。

ただし1クラスタに1サービスのみ

マルチクラスタサポート(続き)

•  クラスタ単位の起動/停止/再起動 •  依存関係もきちんと考慮

•  クラスタ単位でCDHバージョンを指定可能 •  1つのクラスタにおける全てのサービスは同一

バージョンで稼働 •  異なるクラスタであれば異なるバージョンで稼働

可能

2クラスタ管理時

クライアント設定管理

•  クライアント = サービスを利用するためにアクセスするノード

•  alternatives を使った全サーバの /etc 管理 •  手動でのzipダウンロードは不要になった

•  全てのサービスはクライアント設定を /etc にデプロイ可能 •  そのサービスを稼働させている全ホストはクライアン

ト設定のターゲットとして指定可能 •  サービスと無関係なホストも Gateway ロールを割り

当てられれば指定可能 •  クラスタ単位のデプロイをサポート

クライアント設定管理(続き)

•  クライアント専用の設定値はUI内でグループ化されている

•  zip形式での手動ダウンロードは引き続き有効 •  wget/curl などでDL可能

•  注意点 •  クライアント設定は必ず自動で再デプロイされるわけ

ではない •  ユーザは自分で行う必要がある

•  手動でファイル編集すると、再デプロイ時にその設定は失われる

•  必要ならコピーをとってから編集すること

クライアント設定の配布とダウンロード

HDFS HA

•  新しく作成されたHDFSインスタンスは ‘basic’ モードになっている。HA 無効、フェデレーション無効

•  UI ウィザードにより簡単に HA, 自動フェイルオーバ、フェデレーションを有効にできる •  もし手動で構築すると16ステップ必要。すごく大

変 •  CM用のカスタムフェイルオーバフェンシング

ルール

3ステップ HA(ステップ1)

1. スタンバイNNを選ぶ

3ステップ HA(ステップ2) 2. 共有editsディレクトリを指定する 3ステップ目で設定が始まるので注意

サービス管理画面から見たHA

NNの片方がダウンして、アクティブのみで動いていることがわかる

CDH3からCDH4へのアップグレード

•  重要: CMはCDHパッケージ自体のアップグレードはしません

•  パッケージがアップデートされたら、サービスごとのアップグレードウィザードがある •  例: HDFS メタデータアップグレード

•  古い設定プロパティは新しいプロパティに自動置換してくれる

CDH3からCDH4へのアップグレード(続き)

•  アップグレードはクラスタ単位で行われる •  アップグレードのロールバックは非常に難し

い •  CMのDBのバックアップと設定のエクスポートを

推奨 •  CDHのロールバックサポートはまちまち

•  HDFS: サポート •  HBase, Oozie: 未サポート

新しいDBのサポート

•  PostgreSQLとOracle •  全てのCMコンポーネント用にこれらのDBをサ

ポート •  CM3.7: Oracle は未サポート、PostgreSQLはSCM

データベースのみサポート •  ただし推奨DBは引き続きMySQL

•  組み込み PostgreSQL は全てのコンポーネントにおいて自動で設定を行う •  小さいデモクラスタにとっては完璧

CM使用時の設定ファイルの管理方法

•  サーバの設定ファイルは /etc の下ではない •  クライアントの設定ファイルは /etc の下 •  XMLファイルで設定管理しない

•  全ての設定はCMサーバのDBに保存され、CMのUIから管理する

CLOUDERA MANAGER API 既存管理システムとの連携

RESTful な CM API

•  REST API とは? •  関数 = URL と HTTPメソッド(GET, POST, etc) •  引数 = クエリパラメータと POST/PUT データ

•  CM API •  HTTP ベーシック認証 •  JSON を使用

•  Free Edition では全機能が使用可能

組み込みの API ドキュメント

例:クラスタのリスト $ curl -u "admin:admin" http://$CM/api/v1/clusters {

"items" : [ {

"name" : "Cluster 1 - CDH4",

"version" : "CDH4"

"name" : "Cluster 2 - CDH3",

"version" : "CDH3"

例:コマンドの実行 $ curl -X POST -u admin:admin 'http://$CM/api/v1/clusters/Cluster%201%20-

%20CDH4/services/my_hbase/commands/hbaseCreateRoot' { "id" : 142, "name" : "CreateRootDir", "startTime" : "2012-05-06T20:56:57.918Z", "active" : true, "serviceRef" : { "serviceName" : "my_hbase", "clusterName" : "Cluster 1 - CDH4" } }

Python API クライアントライブラリ

•  github で公開中 (Apache License) •  http://cloudera.github.com/cm_api/

CM API まとめ

•  Web UI で使える機能はほぼ全てAPI経由でも使用可能

•  インストールの完全自動化も可能 •  サードパーティ製の監視ツールなどとも連携

可能 •  iPhone アプリも作れます！

CLOUDRA MANAGER ENTERPRISE EDITION

Enterprise Editionとは？

•  CM Free Edition に、監視やログ検索、Kerberos認証などエンタープライズ領域において必須の機能を追加したもの

•  サブスクリプションをご購入いただいたお客様なら自由に利用できます

Cloudera Manager Free Edi-on Cloudera Manager Ent. Edi-on

自動構築 Yes Yes

API Yes Yes

サービス及び設定管理

HDFS, MapReduce, MR2, HBase, Hue, Oozie, Zookeeper の管理 Yes Yes

高可用性と名前空間管理のサポート Yes Yes

設定の自動化 Yes Yes

クライアント設定管理 Yes Yes

監査と追跡 Yes Yes

追加/再起動/デコミッションロールインスタンス Yes Yes

設定のバージョン管理 Yes

サービス監視

プロアクティブ・ヘルスチェック Yes

ステータスサマリー Yes

ヒートマップと性能監視 Yes

ホスト監視 Yes

セキュリティ

LDAP 認証 Yes

Kerberos 設定 Yes

マルチクラスタ管理 Yes

インテリジェント・ログ管理 Yes

イベントマネジメントとアラート Yes

アクティビティ監視 Yes

運用レポート Yes

ファイルブラウザとクォータ管理 Yes

グローバルタイムコントロール Yes

サポート統合 Yes

Enterprise

サービスモニタ

•  サービスの状態をグラフィカルに監視する機能

•  表示できる情報はサービスによって異なる •  HDFS: IO, 壊れたレプリカ数, etc •  MapReduce: Map数, Reduce数

•  アラートなどもリンクつきでモニタに表示 •  クリックすると詳細ページに飛ぶ

サービスモニタ(トップ画面) 画面はSCMと変わらない

サービスモニタ(HDFS)

サービスモニタ(HDFS詳細)

サービスモニタ(HDFSチャート)

サービスモニタ(MapReduceチャート)

ホストモニタ

•  ホストに関する情報を管理・監視できる •  IPアドレス、ホスト名、ラックID •  CPUコア数、メモリ量などのハードウェア情報 •  ロードアベレージ

•  ホストインスペクタにより、ホストレベルでのヘルスチェックが可能 •  障害の原因として頻出のホスト名設定ミスなど

ホストモニタ(ホスト全体画面)

ホストモニタ(ホスト画面)

ホストモニタ(ホスト画面詳細)

ホストモニタ(ホスト画面チャート)

ホストモニタ(ホスト監視設定)

ホストインスペクタ

ホストのヘルスチェックを能動的に行うことも可能

インストールされているパッケージのバージョンチェックなども行う

アクティビティモニタ

•  実行した(している)ジョブを監視可能 •  MapReduce, Hive, Pig, Oozie など全て

•  map数/reduce数、mapの入出力バイト数など、MapReduceジョブに関するあらゆるデータをグラフィカルに表示可能

•  現在MR1のみ対応

アクティビティモニタ

アクティビティモニタ(ジョブ詳細画面)

アクティビティモニタ(ジョブ比較)

•  類似ジョブの比較が可能 •  徐々に性能劣化していく、特定の日のジョブだけ遅い、

などが検出可能

アクティビティモニタ(jobのkill)

ジョブの強制終了が可能(MRとStreamingのみ)

アクティビティモニタ(タスクの分散)

•  異なる2つの評価軸による、タスクの分散を調べるヒートマップを作成可能

•  クリックするとそのタスクを実行したタスクトラッカーの一覧が表示される

•  遅いタスクがどのノードで実行されていたか、容易に特定が可能

アクティビティモニタ(タスクの分散)

ログ検索

•  クラスタ全体のログを高速に検索可能 •  以下のようなクエリで検索できる

•  「7月6日 20:00から21:00の間に」 •  「ホストa,b,c,dにおいて」 •  「サービスmapreduce1で発生した」 •  「WARN以上のログ」

•  結果をグラフィカルに表示するため、特定のホストのログが極端に多いなども一目で識別可能

ログ検索

ヘルスチェック

•  サービスの状態を細かくチェック •  問題がある場合アラートを上げる

ヒートマップ

•  多数のノードの状態をグラフィカルに表現

•  ヘルスチェックの項目の多くはヒートマップで表現可能

ヒートマップ(HDFS)

ヒートマップ(HBase)

イベント

•  ヘルスチェックにおいて、イベントのしきい値を柔軟に設定可能 •  重要、致命的の2段階

•  CDH標準のログには出力されない情報をイベントとしてログ化 •  ログと同様検索が可能

イベント設定(HDFS)

イベント検索

レポート機能 •  クラスタのディスク使用率についてのレポートを作成することがで

きる •  データサイズ別 •  ユーザ別 •  ディレクトリ別 •  etc.

•  ファイルを検索したり、クォータを設定したりすることも可能 •  ユーザ別のMapReduceアクティビティも閲覧することができる •  CSVやExcel形式でのダウンロードも可能

レポート機能

•  トップ画面

レポート機能(ユーザ別ディスク使用量)

レポート機能(ユーザ別ディスク使用履歴)

サポート連携: Cluster Stats •  ユーザはボタン一つでクラスタの情報をzip形式に圧縮できる •  クラスタ情報の一例

•  ログ •  設定 •  メトリクス •  イベント •  ホスト情報

•  自動アップロード、自動定期アップロードが可能 •  自動送信はデフォルトで無効 •  ユーザはzipファイルをダウンロード可能

Cluster Stats

Cluster Stats 結果画面

まとめ

HDFS HA

•  HDFSの弱点と言われていたNNのSPOFを解決し、高可用性を実現

•  Cloudera Manager を使えば3ステップで設定可能

•  エンタープライズHadoopにおける必須機能

Cloudera Manager

•  構築・運用が大変なHadoop の管理を楽にする

•  数100ノードのクラスタを数分で構築可能 •  Enterprise Edition ならログ検索、アラート機

能なども搭載 •  管理に時間をとられたくない人はまず試して

みましょう

デモビデオ(CDHのインストール)

•  http://www.youtube.com/watch?v=CobVqNMiqww

•  CDHを並列にインストールしているのがわかる

cloudera.co.jp 03(6228)7930 twiSer.com/

ClouderaJP

facebook.com/ cloudera

Thank You!

ご質問はこちら: info-jp@cloudera.com

cloudera manager4.0とnamenode-haセミナー資料

Technology

cloudera installation & configuration

datamanagementpart1vt2018 -...

cogito + cloudera

managing high availability - cloudera · 2020-05-09 ·...

building the enterprise data lake with cloudera & cisco ·...

datanode communicate with namenode

cloudera data management · importantnotice...

centerity service pack for cloudera€¦ · oozie [roles...

cloudera developer training

apache hadoop yarn, namenode ha, hdfs federation

cloudera impala

deploying cloudera cdh (cloudera distribution including...

cloudera impala internals

cloudera search

namenode high...

cloudera大阪セミナー 20130219

cloudera case study

cloudera manager intro

cloudera desktop

cloudera godatafest deploying cloudera in the cloud