Cloudera Manager4.0とNameNode-HAセミナー資料
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Cloudera Manager4.0とNameNode-HAセミナー資料

on

  • 5,665 views

2012年7月のセミナーおよび説明会で使用した、CDH4の高可用NameNode(NameNode-HA)とCloudera Manager4.0の資料です。

2012年7月のセミナーおよび説明会で使用した、CDH4の高可用NameNode(NameNode-HA)とCloudera Manager4.0の資料です。

Statistics

Views

Total Views
5,665
Views on SlideShare
4,921
Embed Views
744

Actions

Likes
15
Downloads
103
Comments
0

12 Embeds 744

http://d.hatena.ne.jp 299
http://www.cloudera.co.jp 296
http://www.twylah.com 74
http://garagekidztweetz.hatenablog.com 54
http://us-w1.rockmelt.com 8
http://test100.cloudera.co.jp 3
https://twitter.com 3
http://translate.googleusercontent.com 2
http://webcache.googleusercontent.com 2
http://twitter.com 1
http://tweetedtimes.com 1
http://cloudera2014.tsukinowa.jp 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Cloudera Manager4.0とNameNode-HAセミナー資料 Presentation Transcript

  • 1. CDHはなぜエンタープライズに適しているのか嶋内 翔 カスタマーオペレーションズエンジニア
  • 2. アジェンダ•  エンタープライズにおけるソフトウェアの要件•  HDFS HA•  Cloudera Manager
  • 3. エンタープライズにおける ソフトウェアの要件
  • 4. CDH4 + Cloudera Enterprise 4.0:エンタープライズの要件とは…1 4 他のITとの統合   高可用性    2 セキュリティ   5 設定と構築の単純化  3 6 スケーラビリティと拡張性   グローバルサポートとサービス  
  • 5. CDH4 + Cloudera Enterprise 4.0:エンタープライズの要件とは…1 4 他のITとの統合   高可用性    2 セキュリティ   5 設定と構築の単純化  3 6 スケーラビリティと拡張性   グローバルサポートとサービス  
  • 6. CDH4 + Cloudera Enterprise 4.0:エンタープライズの要件とは…1 4 他のITとの統合   高可用性    2 セキュリティ   5 設定と構築の単純化  3 6 スケーラビリティと拡張性   グローバルサポートとサービス  
  • 7. CDH4 + Cloudera Enterprise 4.0:エンタープライズの要件とは…1 4 他のITとの統合   高可用性    2 セキュリティ   5 設定と構築の単純化  3 6 スケーラビリティと拡張性   グローバルサポートとサービス  
  • 8. 高可用性HDFSHDFS HIGH AVAILABILITY
  • 9. 信頼性、保守性、可用性•  reliability 信頼性 = MTBF/(1 + MTBF) •  MTBF: 平均故障間隔 •  1ヶ月に1回壊れるより1年に1回の方が信頼性が高 い•  maintainability 保守性 = 1 / (1 + MTTR) •  MTTR: 平均復旧時間 •  素早く復旧する方が保守性が高い•  availability 可用性 = MTTF / MTBF •  MTTF: 平均故障時間 •  MTBF = MTTF + MTTR •  信頼性と保守性が高いと可用性も高い
  • 10. 信頼性•  データの信頼性 •  10クラスタ、20,000ノード上の3.29億ブロックのう ち19ブロックがロスト(2009年) •  ※同一ファイルのブロックが全てロストする確率はほ ぼ0 •  1700万ブロック中1ブロック(約4PB) •  原因となったバグは既に修正済み データの信頼性は十分高い  
  • 11. 信頼性(続き)•  18ヶ月で、25クラスタの間で22回の障害 •  1クラスタあたり年間0.58回の障害•  HAが役に立っただろうと考えられるのはうち 8回の障害(0.23回分)•  現在はもっと信頼性が上がっている
  • 12. 保守性•  NN起動時間: 通常1-2分、大きなクラスタだと 15分 •  計画停止するたびにこれだけの時間停止する →MTTR増える(保守性下がる) •  日本で主流のHeartbeat + DRBD も、計画停止 によるダウンタイムは回避できない•  DNの保守性 •  大クラスタ: 1日1DNに障害発生、ディスクはもっ と高頻度 •  3ヶ月に1回の割合で一斉に補修・入れ替え
  • 13. 可用性•  HAがなくても障害停止における可用性は十 分高い 年間稼働率(%)   HAなし   99.993   HAあり(予測)   99.996   注1  HAなしでの1回の平均ダウンタイムを60分として計算   注2  2009-­‐2010年頃のデータを元にしているので、現在はもっと稼働率が高い  
  • 14. 可用性•  計画停止 •  設定変更のたびに再起動 •  アップデート時も当然再起動ダウンタイムなく計画停止するための 仕組みが必要  
  • 15. HDFS HA のデザイン概要•  アクティブとホットスタンバイ間で状態を共有 •  ファイルシステムの状態 •  ブロックの位置•  自動フェイルオーバ •  アクティブなNNの監視と障害時のフェイルオーバの実施•  起動時にアクティブなNNを選出 •  必ず1個のアクティブしか起動しないことを保証•  スプリットブレイン時のデータ破壊を防ぐ •  共有リソースのフェンシング •  DN、及び共有ストレージ上のNNのメタデータ •  NNのフェンシング •  共有リソースをフェンスできなかった場合•  クライアントフェイルオーバ •  クライアントはフェイルオーバ後に新しいNNにアクセスできる
  • 16. NN外からのフェイルオーバ操作•  一般的なHA製品と同じような設計•  NN外にHAデーモンが存在する •  開発が簡単 •  NN障害に影響を受けない•  デーモンはリソースを管理する •  リソース: OS、ハードウェア、ネットワーク •  NNはただのリソースの一つ•  実際の動作 •  アクティブNNは起動時に選ばれる •  自動フェイルオーバ •  フェンシング •  共有リソース •  NN
  • 17. アーキテクチャ Daemon Daemon リーダー選択   ZooKeeper リーダー選択   フェイルオーバ フェイルオーバ コントローラ コントローラ 状態監視   editlog   状態監視  コマンド   編集ログ   コマンド   (フェンシング)   ネームノード ネームノード (アクティブ) (スタンバイ) Daemon Daemon データノード ブロックレポート   ブロックレポート  
  • 18. ホットスタンバイ マニュアルフェイルオーバ   共有ストレージ(NFS)   editlog   編集ログ   (フェンシング)  ネームノード ネームノード (アクティブ) (スタンバイ) Daemon Daemon データノード ブロックレポート   ブロックレポート  
  • 19. クライアントフェイルオーバの設計•  スマートクライアント(クライアントサイドフェイル オーバ) •  ユーザは論理URIを使い、クライアントは正しいNNに 接続しにいく •  クライアントはどの操作が冪等か知っているので、 フェイルオーバをリトライしても問題ない •  クライアントはカスタム可能なフェイルオーバ/リトライ ストラテジーを持つ•  現在の実装 •  クライアントは全NNのホスト名を設定する必要があ る
  • 20. 自動フェイルオーバの設計•  Zookeeperを使う •  手動フェイルオーバでは不要 •  ZKを使うと… •  アクティブNNの障害検知が簡単になる •  アクティブNNの選定が簡単になる•  両方のNNで ZKFailoverController (ZKFC)と いうデーモンを動かす必要がある•  ZKFCは以下のことを行う •  対象NNの状態監視 •  ZKセッション管理 •  ZKベースのアクティブNN選定
  • 21. 自動フェイルオーバ Daemon Daemon リーダー選択   ZooKeeper リーダー選択   ZKセッション管理   ZKセッション管理   ZKFC フェンシング   ZKFC アクティブ/スタンバイ   アクティブ/スタンバイ  状態監視   切り替え   切り替え   状態監視   ネームノード ネームノード (アクティブ) (スタンバイ) マスタサーバA マスタサーバB
  • 22. HAの運用:共有ストレージ•  NNの状態を共有するために共有ストレージ が必要 •  SPOF回避のため共有ストレージ自身もHA化す る必要あり •  多くのHAソリューションにはIPフェンシング機能がある •  推奨マウントオプション •  tcp,soft, intr, timeo=60, retrans=10•  将来的にはNFSでなくBookKeeperベースに なる予定(HDFS-3077)
  • 23. HAの運用: NNフェンシング•  NNは絶対に一つだけしかアクティブになってはいけない •  NNのメタデータは死守•  サーバ外から以下の処理を行う •  RPCでアクティブNNをスタンバイにする(グレースフルフェイル オーバ) •  SSHでアクティブNNに kill -9 を叩く•  プラガブルオプション •  多くのNFSソリューションがIPベースのフェンシング機能を持つ •  多くのPDUがIPベースのSTONITHが可能 •  確実にフェンスする唯一の方法 •  「リモートから電源を引っこ抜く」ことに相当 •  OSがダウンした場合などに使う
  • 24. HAの運用: 自動フェイルオーバ•  ZKクラスタは奇数台で構築すること •  ZKは軽いので1つをNNに、1つをYARN RM に共存 させてもいい •  ただしZK専用のディスクを作ることを推奨 •  あるいは既存クラスタを使ってもいい •  HBaseのZKクラスタを流用してもいい•  フェンシングを設定すること •  アクティブNNに選ばれたNNのZKFCはフェンシング を実行しなければならない•  手動フェイルオーバは可能だがZKFCを操作し た方がいい
  • 25. HAの運用: 監視•  新しいNNメトリクス •  ペンディングされているDNのメッセージキューのサイ ズ •  スタンバイNNが最後に共有editsから読み込んでか ら何秒経過したか •  DNのブロックレポートのタイムラグ •  スタンバイNNのタイムラグを測る指標•  共有ストレージの監視ソリューション •  ディスク容量、ディスクの状態など•  ファイル・テーブルアクセスベースの監視は効果 的(ストール対策)
  • 26. HAの運用: ハードウェア•  アクティブ/スタンバイNNは別のラックに設置•  共有ストレージも別のラックに設置•  アクティブ/スタンバイNNは同一HW構成•  あとはNNの推奨構成と同じ •  ECCメモリ48GB •  複数の異なるディスクにメタデータを書く •  RAID5かミラーリング •  冗長電源
  • 27. ビッグデータ時代の運用管理ソフトウェアCLOUDERA MANAGER 4
  • 28. Cloudera Manager(以下CM) とは?•  CDHを1つのシステムとして扱い、あらゆる構 築・運用のシナリオを統一されたインタフェー スから行うための運用管理ツール•  分散システムの熟知やコンポーネントの相互 依存性などのCDHの運用・構築に必須の知 識を必要としない
  • 29. アーキテクチャ•  集約型管理サーバ •  全デーモンとサービスの設定情報を管理 •  サービスと設定の作成・管理をするためのWeb UI を提供
  • 30. アーキテクチャ(続き)•  エージェントは全てのノードで稼働 •  エージェントはHadoopの起動・停止に責任を持 つ •  設定はサーバから送信される •  デーモンが確実に稼働するようにし、もし起動に失敗 した場合はエラーを報告する •  サーバから指示されたコマンドを実行する •  デーモンのログへのアクセス手段を提供する •  必要なディレクトリが適切なパーミッションで存在 していることを確実にする
  • 31. CM なしの CDH DN/RS/NM   DN/RS/NM   NN   DN/RS/NM   DN/RS/NM   RM   DN/RS/NM   DN/RS/NM  管理者   HMaster   DN/RS/NM   DN/RS/NM   Hue   DN/RS/NM   DN/RS/NM   DN/RS/NM   DN/RS/NM  
  • 32. CM 導入後 CDH  クラスタ   DN/RS/NM   DN/RS/NM   NN   DN/RS/NM   DN/RS/NM   Cloudera     RM   DN/RS/NM   DN/RS/NM   Manager  管理者   HMaster   DN/RS/NM   DN/RS/NM   Hue   DN/RS/NM   DN/RS/NM   DN/RS/NM   DN/RS/NM   CMエージェント  
  • 33. Cloudera Manager 構成図 管理PC   DN/RS/NM   DN/RS/NM   管理者はwebブラウザで   CMにアクセス   スイッチ   DN/RS/NM   DN/RS/NM   DN/RS/NM   DN/RS/NM   CM   DN/RS/NM   DN/RS/NM   スイッチ   DN/RS/NM   DN/RS/NM   設定情報やログ等は   DN/RS/NM   DN/RS/NM   DB   DBに保存  
  • 34. CM管理画面(サービス管理画面)
  • 35. CM管理画面(設定管理画面)
  • 36. CM 用語集•  Service Types (サービスタイプ) •  サービスの種類を表す。例: HDFS, MapReduce, HBase•  Service Instances (サービスインスタンス) •  サービス一単位を表す。例: hdfs1, mapred1•  Role Types (ロールタイプ) •  サービスを構成するコンポーネントの種類を表す。例: DATANODES, JOBTRACKER•  Role Instances (ロールインスタンス) •  サービスを構成するコンポーネントの一単位を表す。例: datanode1•  Commands (コマンド) •  サービスに対して実行する処理などを表す。例: Restart
  • 37. CM4.0 の新機能•  ホスト監視•  複数クラスタ管理•  API•  ローカルリポジトリからのインストール•  Ubuntu/Debian サポート•  PostgreSQL/Oracle サポート•  クライアントの設定管理•  Cloudera のサポートとの連携機能強化
  • 38. CM4.0 の新機能(続き)•  ログローテート設定•  国際化対応(日本語化!)•  Gatewayロールの追加(クライアント専用ロー ル)•  CM管理者ユーザアカウントのLDAP連携•  「アクティビティ」タブからジョブをkillできるよう になった(MRとStreamingのみ)•  「レポート」タブからHDFS上のファイルの閲 覧と検索ができるようになった
  • 39. CM Free Edition•  ウェブサイトから自由にダウンロード可能•  監視、アラート、イベント、ログ検索、 Kerberosサポートはありません•  50ホストまで管理可能•  ライセンスキーでアップグレード可能(要再起 動)
  • 40. Free Edition と Enterprise Edition の違い Free  Edi-on   Enterprise  Edi-on   サービス管理   ◯   ◯   設定管理   ◯   ◎(バージョン管理可能)   CDH一括インストール   ◯   ◯   API   ◯   ◯   管理ノード数制限   50ノードまで   無制限   監視機能   -­‐-­‐   ◯   セキュリティ機能   -­‐-­‐   ◯   イベント機能   -­‐-­‐   ◯   入手方法   無償でDL可   Cloudera  Enterprise  サブス クリプションがあれば誰で も利用可  
  • 41. CMサーバインストール方法•  ウィザードによるインストール •  自己解凍形式のインストーラ •  UIベースのウィザード •  高速かつシンプルなインストールが可能•  マニュアルインストール •  ユーザが手動でインストールする •  柔軟性の高いインストールをしたいならこちら
  • 42. CM4.0でのインストーラ•  インストール時のカスタムリポジトリのサポート •  LAN内でインターネット接続ができなくても利用可能に•  DB関連機能の強化 •  組み込みPostgreSQLのサポート •  手動でのDBセットアップが必須でなくなった •  ウィザードでDBの自動設定が可能に •  専用のDB設定インタフェースの追加 •  設定の誤りチェック •  自動DBスキーマインストール・アップグレード•  CDHバージョンの選択が可能になった•  Debian/Ubuntu のサポート
  • 43. クラスタの管理を簡単にするSERVICE AND CONFIGURATION MANAGER
  • 44. SCM•  Service and Configuration Manager (サービ ス・設定マネージャ)•  プロセスの起動・停止、すなわちシステムのブー トストラップを行う•  設計思想 •  install everything, everywhere •  設定の集中管理•  Free Edition ではほぼ全機能が使用可能 •  設定のバージョン管理機能のみEnterprise専用(後 述)
  • 45. サービス管理画面
  • 46. コマンドメニュー•  再起動なども簡単 •  HBase の graceful stop なども自動で行う•  クラスタ単位の再起動が可能 •  停止順序などもきちんと考慮
  • 47. 設定管理画面•  設定に問題がある場合は警告する•  下の図では2箇所に警告が出ている •  NNと2NNのヒープサイズが異なる •  NNのヒープサイズが1GBを下回っている
  • 48. Enterprise  Only  設定はバージョン管理できる
  • 49. 設定変更後は再起動を促す
  • 50. マルチクラスタサポート•  サービスはクラスタとしてグループ化される•  サービス設定と監視はクラスタ別に可能•  複数の HDFS/MapReduce を管理できる。 ただし1クラスタに1サービスのみ
  • 51. マルチクラスタサポート(続き)•  クラスタ単位の起動/停止/再起動 •  依存関係もきちんと考慮•  クラスタ単位でCDHバージョンを指定可能 •  1つのクラスタにおける全てのサービスは同一 バージョンで稼働 •  異なるクラスタであれば異なるバージョンで稼働 可能
  • 52. 2クラスタ管理時
  • 53. クライアント設定管理•  クライアント = サービスを利用するためにアクセ スするノード•  alternatives を使った全サーバの /etc 管理 •  手動でのzipダウンロードは不要になった•  全てのサービスはクライアント設定を /etc にデ プロイ可能 •  そのサービスを稼働させている全ホストはクライアン ト設定のターゲットとして指定可能 •  サービスと無関係なホストも Gateway ロールを割り 当てられれば指定可能•  クラスタ単位のデプロイをサポート
  • 54. クライアント設定管理(続き)•  クライアント専用の設定値はUI内でグループ化 されている•  zip形式での手動ダウンロードは引き続き有効 •  wget/curl などでDL可能•  注意点 •  クライアント設定は必ず自動で再デプロイされるわけ ではない •  ユーザは自分で行う必要がある •  手動でファイル編集すると、再デプロイ時にその設定 は失われる •  必要ならコピーをとってから編集すること
  • 55. クライアント設定の配布とダウンロード
  • 56. HDFS HA•  新しく作成されたHDFSインスタンスは ‘basic’ モードになっている。HA 無効、フェデレーショ ン無効•  UI ウィザードにより簡単に HA, 自動フェイル オーバ、フェデレーションを有効にできる •  もし手動で構築すると16ステップ必要。すごく大 変•  CM用のカスタムフェイルオーバフェンシング ルール
  • 57. 3ステップ HA(ステップ1)1. スタンバイNNを選ぶ
  • 58. 3ステップ HA(ステップ2)2. 共有editsディレクトリを指定する3ステップ目で設定が始まるので注意
  • 59. サービス管理画面から見たHANNの片方がダウンして、アクティブのみで動いていることがわかる
  • 60. CDH3からCDH4へのアップグレード•  重要: CMはCDHパッケージ自体のアップグ レードはしません•  パッケージがアップデートされたら、サービス ごとのアップグレードウィザードがある •  例: HDFS メタデータアップグレード•  古い設定プロパティは新しいプロパティに自 動置換してくれる
  • 61. CDH3からCDH4へのアップグレード(続き)•  アップグレードはクラスタ単位で行われる•  アップグレードのロールバックは非常に難し い •  CMのDBのバックアップと設定のエクスポートを 推奨 •  CDHのロールバックサポートはまちまち •  HDFS: サポート •  HBase, Oozie: 未サポート
  • 62. 新しいDBのサポート•  PostgreSQLとOracle •  全てのCMコンポーネント用にこれらのDBをサ ポート •  CM3.7: Oracle は未サポート、PostgreSQLはSCM データベースのみサポート •  ただし推奨DBは引き続きMySQL•  組み込み PostgreSQL は全てのコンポーネ ントにおいて自動で設定を行う •  小さいデモクラスタにとっては完璧
  • 63. CM使用時の設定ファイルの管理方法•  サーバの設定ファイルは /etc の下ではない•  クライアントの設定ファイルは /etc の下•  XMLファイルで設定管理しない •  全ての設定はCMサーバのDBに保存され、CM のUIから管理する
  • 64. 既存管理システムとの連携CLOUDERA MANAGER API
  • 65. RESTful な CM API•  REST API とは? •  関数 = URL と HTTPメソッド(GET, POST, etc) •  引数 = クエリパラメータと POST/PUT データ•  CM API •  HTTP ベーシック認証 •  JSON を使用•  Free Edition では全機能が使用可能
  • 66. 組み込みの API ドキュメント
  • 67. 例:クラスタのリスト$ curl -u "admin:admin" http://$CM/api/v1/clusters{ "items" : [ { "name" : "Cluster 1 - CDH4", "version" : "CDH4" }, { "name" : "Cluster 2 - CDH3", "version" : "CDH3" } ]}
  • 68. 例:コマンドの実行$ 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" } }
  • 69. Python API クライアントライブラリ•  github で公開中 (Apache License) •  http://cloudera.github.com/cm_api/
  • 70. CM API まとめ•  Web UI で使える機能はほぼ全てAPI経由で も使用可能•  インストールの完全自動化も可能•  サードパーティ製の監視ツールなどとも連携 可能•  iPhone アプリも作れます!
  • 71. CLOUDRA MANAGER ENTERPRISE EDITION
  • 72. Enterprise Editionとは?•  CM Free Edition に、監視やログ検索、 Kerberos認証などエンタープライズ領域にお いて必須の機能を追加したもの•  サブスクリプションをご購入いただいたお客様 なら自由に利用できます
  • 73. 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   ホスト監視  セキュリティ   Free   Yes   LDAP  認証   Yes   Kerberos  設定   Yes  マルチクラスタ管理   Yes  インテリジェント・ログ管理   Yes  イベントマネジメントとアラート  アクティビティ監視   Enterprise   Yes   Yes  運用レポート   Yes  ファイルブラウザとクォータ管理   Yes  グローバルタイムコントロール   Yes  サポート統合   Yes  
  • 74. サービスモニタ•  サービスの状態をグラフィカルに監視する機 能•  表示できる情報はサービスによって異なる •  HDFS: IO, 壊れたレプリカ数, etc •  MapReduce: Map数, Reduce数•  アラートなどもリンクつきでモニタに表示 •  クリックすると詳細ページに飛ぶ
  • 75. サービスモニタ(トップ画面)画面はSCMと変わらない
  • 76. サービスモニタ(HDFS)
  • 77. サービスモニタ(HDFS詳細)
  • 78. サービスモニタ(HDFSチャート)
  • 79. サービスモニタ(MapReduceチャート)
  • 80. ホストモニタ•  ホストに関する情報を管理・監視できる •  IPアドレス、ホスト名、ラックID •  CPUコア数、メモリ量などのハードウェア情報 •  ロードアベレージ•  ホストインスペクタにより、ホストレベルでのヘル スチェックが可能 •  障害の原因として頻出のホスト名設定ミスなど
  • 81. ホストモニタ(ホスト全体画面)
  • 82. ホストモニタ(ホスト画面)
  • 83. ホストモニタ(ホスト画面詳細)
  • 84. ホストモニタ(ホスト画面チャート)
  • 85. ホストモニタ(ホスト監視設定)
  • 86. ホストインスペクタホストのヘルスチェックを能動的に行うことも可能インストールされているパッケージのバージョンチェックなども行う
  • 87. アクティビティモニタ•  実行した(している)ジョブを監視可能 •  MapReduce, Hive, Pig, Oozie など全て•  map数/reduce数、mapの入出力バイト数な ど、MapReduceジョブに関するあらゆるデー タをグラフィカルに表示可能•  現在MR1のみ対応
  • 88. アクティビティモニタ
  • 89. アクティビティモニタ(ジョブ詳細画面)
  • 90. アクティビティモニタ(ジョブ比較)•  類似ジョブの比較が可能•  徐々に性能劣化していく、特定の日のジョブだけ遅い、 などが検出可能
  • 91. アクティビティモニタ(jobのkill)ジョブの強制終了が可能(MRとStreamingのみ)
  • 92. アクティビティモニタ(タスクの分散)•  異なる2つの評価軸による、タスクの分散を調 べるヒートマップを作成可能•  クリックするとそのタスクを実行したタスクト ラッカーの一覧が表示される•  遅いタスクがどのノードで実行されていたか、 容易に特定が可能
  • 93. アクティビティモニタ(タスクの分散)
  • 94. ログ検索•  クラスタ全体のログを高速に検索可能•  以下のようなクエリで検索できる •  「7月6日 20:00から21:00の間に」 •  「ホストa,b,c,dにおいて」 •  「サービスmapreduce1で発生した」 •  「WARN以上のログ」•  結果をグラフィカルに表示するため、特定のホス トのログが極端に多いなども一目で識別可能
  • 95. ログ検索
  • 96. ヘルスチェック•  サービスの状態を細かくチェック•  問題がある場合アラートを上げる
  • 97. ヒートマップ•  多数のノードの状態を グラフィカルに表現•  ヘルスチェックの項目 の多くはヒートマップで 表現可能
  • 98. ヒートマップ(HDFS)
  • 99. ヒートマップ(HBase)
  • 100. イベント•  ヘルスチェックにおいて、イベントのしきい値 を柔軟に設定可能 •  重要、致命的の2段階•  CDH標準のログには出力されない情報をイ ベントとしてログ化 •  ログと同様検索が可能
  • 101. イベント設定(HDFS)
  • 102. イベント検索
  • 103. レポート機能•  クラスタのディスク使用率についてのレポートを作成することがで きる •  データサイズ別 •  ユーザ別 •  ディレクトリ別 •  etc.•  ファイルを検索したり、クォータを設定したりすることも可能•  ユーザ別のMapReduceアクティビティも閲覧することができる•  CSVやExcel形式でのダウンロードも可能
  • 104. レポート機能•  トップ画面
  • 105. レポート機能(ユーザ別ディスク使用量)
  • 106. レポート機能(ユーザ別ディスク使用履歴)
  • 107. サポート連携: Cluster Stats•  ユーザはボタン一つでクラスタの情報をzip形式に圧縮できる•  クラスタ情報の一例 •  ログ •  設定 •  メトリクス •  イベント •  ホスト情報•  自動アップロード、自動定期アップロードが可能•  自動送信はデフォルトで無効•  ユーザはzipファイルをダウンロード可能
  • 108. Cluster Stats
  • 109. Cluster Stats 結果画面
  • 110. まとめ
  • 111. HDFS HA•  HDFSの弱点と言われていたNNのSPOFを 解決し、高可用性を実現•  Cloudera Manager を使えば3ステップで設 定可能•  エンタープライズHadoopにおける必須機能
  • 112. Cloudera Manager•  構築・運用が大変なHadoop の管理を楽にす る•  数100ノードのクラスタを数分で構築可能•  Enterprise Edition ならログ検索、アラート機 能なども搭載•  管理に時間をとられたくない人はまず試して みましょう
  • 113. DEMO
  • 114. デモビデオ(CDHのインストール)•  http://www.youtube.com/watch? v=CobVqNMiqww•  CDHを並列にインストールしているのがわか る
  • 115. Thank ご質問はこちら: You! info-jp@cloudera.com   03(6228)7930   cloudera.co.jp   twiSer.com/   ClouderaJP facebook.com/   cloudera