• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Hadoop Operations #cwt2013
 

Hadoop Operations #cwt2013

on

  • 1,511 views

#cwt2013 Clouderaの小林 @d1ce_ ...

#cwt2013 Clouderaの小林 @d1ce_ によるHadoop構築・運用のポイントについてのスライドを公開しました。2013年度版ハードウェア選定、HA構成の考え方から、実際にサポートで直面した事例についても紹介しています

Statistics

Views

Total Views
1,511
Views on SlideShare
1,498
Embed Views
13

Actions

Likes
8
Downloads
32
Comments
0

1 Embed 13

https://twitter.com 13

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

    Hadoop Operations #cwt2013 Hadoop Operations #cwt2013 Presentation Transcript

    • Hadoop  Operations  ~∼構築・運⽤用のポイント Cloudera  カスタマーオペレーションズエンジニア ⼩小林林  ⼤大輔  |  @d1ce_̲ 2013年年11⽉月7⽇日 1
    • ⾃自⼰己紹介   ⼩小林林  ⼤大輔 •  カスタマーオペレーションズエンジニア •  主に国内外のテクニカルサポート業務を担当 •  email:  daisuke@cloudera.com   •  twi3er:  d1ce_   •  2
    • Hadoop  オペレーションの⽇日本語訳が発売予定です •  •  •  •  •  •  3 11⽉月下旬発売 通称「パカ」本  (?) Cloudera  の  Eric  Sammer  著 翻訳は安⼼心の⽟玉川⻯竜司さん レビューを⼿手伝ってました ⽇日本語版のみの付録も執筆!
    • 今⽇日お話すること   •  •  Hadoop  クラスタを安定して運⽤用するためのノウハウを 共有します 去年年、嶋内が発表した「Hadoopのシステム設計・運⽤用 のポイント」のアップデート版と考えてください http://www.slideshare.net/Cloudera_̲jp/hadoop-‐‑‒15944692 •  4 HDFS/MapReduce,  HBase  についての基本知識識がある ことが前提です
    • アジェンダ   ハードウェア選定の⽬目安 •  推奨するソフトウェア構成 •  クラスタ運⽤用時の注意点   •  5
    • ハードウェア選定の⽬目安 6
    • ハードウェア選定:スレーブノード   •  コスト対効果の⾼高いコモディティサーバーを使う •  •  コモディティ  =  各部品がどこでも調達可能という意味 低スペックの安いサーバーではない Hadoopクラスタ構成時のハードウェア選定の⽬目安 •  ブログ:  h3p://www.cloudera.co.jp/blog/how-­‐to-­‐select-­‐the-­‐right-­‐hardware-­‐ for-­‐your-­‐new-­‐hadoop-­‐cluster.html   •  ⼀一般的な選定の範囲 •  •  •  •  7 ディスク:1-‐‑‒4TB  の  HDD  を  12-‐‑‒24  台積む  (JBOD) CPU:2-‐‑‒2.5GHz  の  4/6/8コア  CPU  ×  2 RAM:64-‐‑‒512GB   (Impala  を利利⽤用する場合は  128GB  以上を推奨) ネットワーク:10Gbit  (20台以下であれば  1Gbit)
    • ワークロードについて   •  IO  バウンドな処理理 •  •  •  •  •  CPU  バウンドな処理理 •  •  •  •  8 インデクシング グルーピング データのインポートやエクスポート データ移動や転送 クラスタリングや分類 複雑なテキストマイニング ⾃自然⾔言語処理理 特徴抽出
    • ワークロードに応じた選定   •  IO  バウンドな処理理 •  •  •  •  CPU  バウンドな処理理 •  •  •  9 ディスク:2TB-‐‑‒4TB  ×  16-‐‑‒24台 CPU:4コア  ×  2 RAM:48-‐‑‒96GB ディスク:1TB-‐‑‒2TB  ×  4-‐‑‒8台 CPU:6コア  ×  2 RAM:64-‐‑‒512GB
    • ハードウェア選定:マスターノード   ハイエンドのサーバーを使う •  電源⼆二重化、NIC  ボンディング、RAID1 •  ⼀一般的な選定 •  •  •  •  •  10 ディスク:1TB  の  HDD  を  4-‐‑‒6台積む OS  ⽤用(1台)  +  fsimage  ⽤用(2台:RAID1)  +   ZooKeeper  (1台)  +  JournalNode  (1台) CPU:2-‐‑‒2.5GHz  の  4/6/8コア  CPU  ×  2 RAM:64-‐‑‒128GB ネットワーク:10Gbit  (20台以下であれば  1Gbit)
    • 推奨するソフトウェア構成 11
    • ソフトウェア選定     •  CDH4を使う •  •  •  12 (GA  版では)  最新の  CDH4.4(11/7  時点)   ネームノード、ジョブトラッカーが  HA  対応し SPOF  がない HBase、Hive  など周辺エコシステムを含んでいる
    • ソフトウェア選定:HA構成 必ず  HA  構成を組む •  ⾼高可⽤用性ネームノード  (NFS  は不不要) •  •  •  •  アクティブ/スタンバイネームノード JournalNode  (edits  の保存先として)  ×  3 ⾃自動フェイルオーバー⽤用 •  •  •  5⽉月に開催したHDFS  HAセミナーの資料料も参照 •  13 ZooKeeper  ×  3 ZooKeeperFailoverController  (ZKFC)  ×  2 http://www.slideshare.net/Cloudera_̲jp/hdfs-‐‑‒ha
    • 宣伝 •  14 今⽉月末発売のパカ本の 付録にも詳しい仕組みが 載っています
    • ソフトウェア選定:HA構成 •  ⾼高可⽤用性ジョブトラッカー •  •  アクティブ/スタンバイジョブトラッカー ⾃自動フェイルオーバー⽤用 •  •  15 ZooKeeper  ×  3 ZooKeeperFailoverController  (ZKFC)  ×  2
    • クラスタ構成の例例 •  スレーブ •  •  •  マスター •  16 コモディティサーバーを最低  4  ノード -‐‑‒>  ひとつのデータノード障害時にも  3  レプリカが存在 するため、業務継続可能 Hadoop  の性能を活かすには不不⼗十分  (あくまで評価⽤用) ネームノード/ジョブトラッカー  HA  を最⼩小構成で組む と、ハイエンドサーバー  ×  3台
    • クラスタ構成の例例1:マスターノード   ZooKeeper ZooKeeper ZKFC ZKFC アクティブ ネームノード スタンバイ ネームノード ZooKeeper ZKFC スタンバイ ジョブトラッカー JounalNode マスター1 17 ZKFC アクティブ ジョブトラッカー JounalNode JounalNode マスター2 マスター3
    • クラスタ構成の例例2:マスターノード   ZooKeeper ZKFC アクティブ ネームノード ZKFC スタンバイ ジョブトラッカー HMaster JounalNode 18 ZooKeeper ZKFC スタンバイ ネームノード ZKFC ZooKeeper プライマリ HMaster Impala StateStore アクティブ ジョブトラッカー JounalNode JounalNode
    • クラスタ運⽤用時の注意点 19
    • 運⽤用時の注意点:OS編     •  Transparent  Huge  Page •  全ノードで無効にすること •  •  •  •  #  echo  ‘never’  >  sys/kernel/mm/redhat_transparent_hugepage/defrag   RHEL  6.2  and  6.3 CentOS  6.2  and  6.3 SLES  11  SP2 対象  OS  は以下 •  •  •  参考  http://structureddata.org/2012/06/18/linux-‐‑‒6-‐‑‒transparent-‐‑‒ huge-‐‑‒pages-‐‑‒and-‐‑‒hadoop-‐‑‒workloads/ vm.swappiness •  全ノードでデフォルト  60  から  0  に変更更すること •  •  20 #  sysctl  -­‐w  vm.swappiness=0 どちらも、デフォルト設定では致命的なパフォーマンス劣劣化を 招くことが報告されています
    • 運⽤用時の注意点:HDFS編     •  ネームノード •  •  ヒープサイズは、100万ブロックで  1GB  が⽬目安 ブロックサイズは  128MB  を推奨 •  •  •  fsimage  を保存する  dfs.namenode.name.dir  は 複数ドライブを指定し、ミラーリングすること RAID1  も推奨 JournalNode •  •  21 small  files  problem  に注意する dfs.journalnode.edits.dir  をひとつ指定 RAID1  上に構成することを推奨  
    • 運⽤用時の注意点:HDFS編     •  データノード •  •  •  ブロック数はノードあたり最⼤大でも  30  万が⽬目安 ヒープサイズは  1-‐‑‒4GB  間で調整 バランサーによるブロック転送量量の調整 •  •  •  デコミッション/障害時のブロック転送量量の調整   •  •  •  22 dfs.datanode.balance.bandwidthPerSec   下記コマンドで動的に変更更可 $  sudo  -­‐u  hdfs  hdfs  dfsadmin  -­‐setBalancerBandwidth  …   dfs.namenode.replicaKon.work.mulKplier.per.iteraKon   をデフォルトの  2  から変更更する  (最⼤大でも  5)   ネームノードの再起動が必要   あくまでも⼀一時的な変更更とすること  
    • 運⽤用時の注意点:HDFS編     •  Hive  の  HA  対応   1.  2.  3.  •  23 Hive  サービスの停⽌止 metatool  の  実⾏行行   $  hive  -­‐-­‐service  metatool  -­‐listFSRoot   $  hive  -­‐-­‐service  metatool  -­‐updateLocaKon          hdfs://nameservice1  hdfs://oldnamenode.com   Hive  サービスの起動 HA  <-‐‑‒>  non-‐‑‒HA  どちらに移⾏行行しても実施する こと
    • 運⽤用時の注意点:HDFS編     •  実際にあった話1 •  事象   •  24 実ブロックが存在しているにもかかわらず、ネームノードか ら⾒見見えなくなっており、missing  replica  のアラートがあ がった
    • 運⽤用時の注意点:HDFS編     •  実際にあった話1 •  事象   •  •  原因   •  •  •  •  25 実ブロックが存在しているにもかかわらず、ネームノードか ら⾒見見えなくなっており、missing  replica  のアラートがあ がった 実ブロックを格納しているディレクトリが、あるひとつの   DN  の  hdfs-‐‑‒site.xml  から削除されていた     プロパティ:dfs.datanode.data.dir   注意:HDFS  ⾃自⾝身に耐性はあるので致命的ではありません   このようなヒューマンエラーは  Cloudera  Manager  を利利⽤用す ることで回避できます  
    • 運⽤用時の注意点:HDFS編     •  実際にあった話2 •  事象   •  26 スタンバイネームノード側の  ZKFC  が起動しない。アク ティブ側は起動しており、ネームノードも正常動作している。 この状態でアクティブ側に障害が発⽣生すると、フェイルオー バーできずクラスタダウンにつながる
    • 運⽤用時の注意点:HDFS編     •  実際にあった話2 •  事象   •  •  スタンバイネームノード側の  ZKFC  が起動しない。アク ティブ側は起動しており、ネームノードも正常動作している。 この状態でアクティブ側に障害が発⽣生すると、フェイルオー バーできずクラスタダウンにつながる 原因   •  •  ZKFC  <-‐‑‒>  ZK  間の通信に失敗していた ZK  が許容する最⼤大接続数が低すぎたことが原因  (60) •  27 プロパティ:maxClientCnxns  
    • 運⽤用時の注意点:HDFS編     •  実際にあった話2 •  事象   •  •  スタンバイネームノード側の  ZKFC  が起動しない。アク ティブ側は起動しており、ネームノードも正常動作している。 この状態でアクティブ側に障害が発⽣生すると、フェイルオー バーできずクラスタダウンにつながる 原因   •  •  ZKFC  <-‐‑‒>  ZK  間の通信に失敗していた ZK  が許容する最⼤大接続数が低すぎたことが原因  (60) •  •  28 プロパティ:maxClientCnxns   教訓:原因⾃自体は単純でも、思いがけないミス、設定 不不備がクラスタに影響をあたえます!
    • 運⽤用時の注意点:HDFS編     •  ストレージのサイジング •  •  •  •  29 複製数が  3 ジョブの中間データも書き込まれる   -‐‑‒>  ストレージサイズの  25%  で計算 実データに対し、4-‐‑‒5  倍の余裕をもつこと +  OS  等  HDFS  以外の容量量も確保 ストレージ容量量が  1ノードあたり  32TB  の場合 実データとしては  8TB  に相当
    • 運⽤用時の注意点:MapReduce編     •  ジョブトラッカー •  以下の情報のメタデータをヒープ領領域に確保する 1.  2.  30 完了了済みのジョブ 履履歴から参照したジョブ
    • 運⽤用時の注意点:MapReduce編     •  ジョブトラッカー •  以下の情報のメタデータをヒープ領領域に確保する 1.  2.  •  完了了済みのジョブ •  •  •  31 完了了済みのジョブ 履履歴から参照したジョブ デフォルト  100 タスクあたり  5-‐‑‒6KB   -‐‑‒>  10000  万タスクをもつジョブであれば、50MB  前後は消 費する計算 -‐‑‒>  デフォルトのままだと  5GB  に相当 mapred.jobtracker.completeuserjobs.maximum  を  5  に設定する
    • 運⽤用時の注意点:MapReduce編     •  ジョブトラッカー •  以下の情報のメタデータをヒープ領領域に確保する 1.  2.  •  履履歴から参照したジョブ •  •  •  •  32 完了了済みのジョブ 履履歴から参照したジョブ JT  WebUI  からジョブの履履歴を参照するたびに確保 デフォルト  5 30000  万タスクほどのジョブであれば、約  170MB mapred.job.tracker.jobhistory.lru.cache.size  で調整   (デフォルト値が⼩小さいので、あまり気にする必要はない)  
    • 運⽤用時の注意点:MapReduce編     •  ジョブトラッカー  WebUI  は、実際に消費中のヒープは表⽰示しない •  前者は、現在および将来のオブジェクトに利利⽤用可能な現在のメモリの総容量量   •  後者は、仮想マシンが使⽤用できる最⼤大メモリ容量量 http://docs.oracle.com/javase/jp/6/api/java/lang/Runtime.html#totalMemory%28%29 http://docs.oracle.com/javase/jp/6/api/java/lang/Runtime.html#maxMemory%28%29 •  消費中のヒープは  Hadoop  が提供するメトリクスから確認 1.  2.  33 http://<ジョブトラッカーのホスト名>:50030/jmx “java.lang:type=Memory”  -‐‑‒>  "used"  
    • 運⽤用時の注意点:MapReduce編     •  タスクトラッカーとタスクが使⽤用するヒープの⾒見見積もり •  •  適切切に⾒見見積もらなければ、そもそも単純なジョブにも失敗します 総スロット数  =  CPU  コア数  -‐‑‒  稼働しているサービスの数 (Mapのタスク数  mapred.tasktracker.map.tasks.maximum + Reduceタスク数  mapred.tasktracker.reduce.tasks.maximum) ☓ タスクのヒープサイズ(mapred.child.java.optsの-‐‑‒Xmxオプション) TaskTracker  のヒープサイズ 34
    • 運⽤用時の注意点:HBase編     HMaster  のヒープサイズは  2-‐‑‒4GB  で調整 •  問題はリージョンサーバー  (RS) •  •  パフォーマンス劣劣化を招く問題は  3  つ 1.  2.  3.  GC  によるタイムアウト -‐‑‒>  ZK  とのセッションが維持できないと、RS  は⾃自ら停⽌止 OutOfMemoryError -‐‑‒>  ヒープサイズは最⼤大  16GB  を推奨 ホットスポット発⽣生 -‐‑‒>  特定の  RS  に書き込みが集中していないか、ログや   HMaster  の  WebUI  から確認する。スキーマ設計につい ては嶋内の資料料も参考 http://www.slideshare.net/Cloudera_̲jp/hbase-‐‑‒hcj13w 35
    • 運⽤用時の注意点:HBase編     •  ZK  との通信について •  •  (再掲)  RS  は  ZK  との通信が維持できないと⾃自ら停⽌止 最⼤大コネクション数 hbase.zookeeper.property.maxClientCnxns •  •  •  •  ヘルスチェック •  •  36 CDH4  のデフォルト値は  300 CDH3  では  30  だったので設定ミスに注意すること 300  -‐‑‒  1000  の範囲で調整する hbase  hbck  -­‐details  2>&1  |  tee  filename.txt   echo  "scan  '.META.'"  |  hbase  shell  >  META-­‐output.txt  
    • 運⽤用時の注意点:HBase編     •  実際にあった話 •  事象 •  HBase  を利利⽤用するまったく別の  2つの  MR  ジョブが同じよ うに実⾏行行に失敗していた 1.  2.  3.  4.  37 タスクの失敗 TT  がブラックリスト⼊入り ⻑⾧長い実⾏行行時間の末、ジョブが失敗 RS  がダウン
    • 運⽤用時の注意点:HBase編     •  実際にあった話 •  原因  (ジョブA) •  •  •  •  原因  (ジョブB) •  •  •  •  RS  間でネットワーク障害が発⽣生し、ZK  への接続に失敗 その結果、RS  が停⽌止 RS  が停⽌止したことで、MR  のタスクも失敗 教訓 •  38 RS  でスワップが発⽣生し、ZK  への接続に失敗 その結果、RS  が停⽌止 RS  が停⽌止したことで、MR  のタスクも失敗 表⾯面的な事象は同じでも、根本原因はまったく異異なっていた。 さらに、クラスタ全体を監視しなければ特定できない問題 だった
    • まとめ 39
    • まとめ   •  Hadoop  は単なるバッチ処理理⽤用のシステムから、企業のすべての データを格納するハブへと進化中 •  バッチ処理理とインタラクティブな処理理が同居する環境では、ある程 度度のハードウェアスペック、適切切なソフトウェア構成が必須 •  •  40 もちろん、低スペックのマシンでも動作はするが、運⽤用が⼤大変 システムの挙動を理理解して、余裕をもった構成にすることが⼤大事
    • トレーニングと認定資格   •  トレーニング •  •  •  •  •  Hadoop開発者向け      ・  HBase Hadoop管理理者向け      ・  Hadoopエッセンシャル データアナリスト向け データサイエンティスト⼊入⾨門 認定資格 •  •  •  •  Hadoop開発者認定 http://enterprisezine.jp/article/corner/220/ Hadoop管理理者認定 HBaseスペシャリスト認定 Cloudera認定スペシャリスト:データサイエンス http://cloudera.co.jp/university 41
    • Hadoop  オペレーション •  •  •  •  42 運⽤用監視については⽂文句句なしの 内容 今⽇日話した内容はほぼ載ってい ます 各種パラメータの詳細説明はこ れ以上の書籍はありません ⽇日本語版のみの付録  ×  3
    • Cloudera  Impala  の⽇日本語フリーブック •  •  •  オライリーの「インパラ本」、⽇日本語PDF版が無償公開される予定で す! Cloudera  の  John  Russell  著 Hadoop、HBase、Hadoopオペレーション、 プログラミングHiveなどを翻訳された ⽟玉川⻯竜司さんが翻訳! 「これまでClouderaの皆 さんにご尽力いただいた 翻訳レビューへの感謝の 気持ちとして、Cloudera World Tokyo開催のお祝 いに翻訳寄贈します!」 43
    • We  are  Hiring!   •  Clouderaは貴⽅方を求めています!!   •  ソリューションアーキテクト   •  •  カスタマーオペレーションズエンジニア   (サポート)   •  •  •  Hadoopを使ったコンサルティングやモデリング   世界中のお客様のHadoopを守る!   インストラクター   セールス   興味のある⽅方は   info-­‐jp@cloudera.com  にご連絡下さい!   44
    • 45