Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Apache Hadoopの新機能Ozoneの現状

1,684 views

Published on

2017年11月29日に開催されたHadoopソースコードリーディング 第24回の講演資料です。

Published in: Technology
  • Be the first to comment

Apache Hadoopの新機能Ozoneの現状

  1. 1. © 2017 NTT DATA Corporation Apache Hadoopの新機能Ozoneの現状 2017/11/29 株式会社NTTデータ OSSプロフェッショナルサービス 鯵坂 明 Hadoopソースコードリーディング 第24回
  2. 2. © 2017 NTT DATA Corporation 2  鯵坂 明 (Akira Ajisaka, @ajis_ka)  NTTデータ OSSプロフェッショナルサービス  Apache Hadoopと関わり続けて6年が経過  Hadoopの新機能や、関連するミドルウェアの検証  プロジェクトへの技術支援  サポートサービス  Apache Hadoop committer, PMC member  HadoopのJava 9対応を実施中 自己紹介
  3. 3. © 2017 NTT DATA Corporation 3 Hadoop 3.0.0のリリースが目前 20142011 20132012 2015 2.2.0 2.3.0 2.4.02.0.0-alpha 2.1.0-beta 0.23.0 0.23.11(final) NameNode Federation, YARN NameNode HA HDFS Snapshots NFSv3 support Windows Heterogeneous storage HDFS in-memory caching HDFS ACLs HDFS Rolling Upgrades Application History Server RM Automatic Failover 2.5.0 2.6.0 YARN Rolling Upgrades Transparent Encryption Archival Storage 2.7.0 Drop JDK6 support Truncate API 2016 branch-0.23 branch-2 trunk Hadoop2 Hadoop3 2017 2.8.0 3.0.0-alpha1 3.0.0-beta1 HDFS caller context S3A improvement Support Azure Data Lake 3.0.0-alpha4 2.9.0 Timeline Service v.2 YARN Web UI v2 Opportunistic Containers YARN Federation HDFS Router-based federation
  4. 4. © 2017 NTT DATA Corporation 4  https://cwiki.apache.org/confluence/display/HADOOP/R oadmap 今後のRoadmap
  5. 5. © 2017 NTT DATA Corporation 5  S3のようなオブジェクトストレージをHadoop上で実現する  多数のオブジェクトを格納したいという、HDFSが苦手とす る領域をカバーする目的で開発されている  HDFS-7240 branchで開発中  開発が始まって2年半  Issue数はErasure Coding (HDFS-7285) のおよそ2倍  Roadmapによると、Hadoop 3.1.0で使える予定  2018 1Qあたり? Ozone: Object Store in Apache Hadoop
  6. 6. © 2017 NTT DATA Corporation 6 本スライドは、feature branchで開発中の機能 を紹介するものです 設定方法、コマンドなど全てにおいて、今後変更 される可能性が大いにあります Ozoneについて詳しく紹介する前に... 注意事項
  7. 7. © 2017 NTT DATA Corporation 7 ボリューム、バケット、オブジェクト Ozone ACLACL ACL ボリューム バケットを複数持つ。 管理者アカウントが設定されている。 一定の容量が割り当てられている。 バケット オブジェクトを複数持つ。 ACL を設定することができる。 名前空間はバケットで独立。 オブジェクト キーと値の組。 キーはバケット内でユニーク。 ・・・ ・・・ ・・・
  8. 8. © 2017 NTT DATA Corporation 8 各コンポーネント間の関係 Key Space Manager (KSM) Storage Container Manager (SCM) Ozone Client Containers Ozone Handler DataNode Containers Ozone Handler DataNode ・・・
  9. 9. © 2017 NTT DATA Corporation 9  Container  DataNode上に保持  Ozoneにおけるレプリケーションの単位 Ozoneを構成するコンポーネント
  10. 10. © 2017 NTT DATA Corporation 10  Ozone Handler  クライアントに対してOzoneのREST APIを提供  各DataNode上で動作  Key Space Manager (KSM)  名前空間に関するクエリを処理  オブジェクトのキーやバケット名からcontainerを解決  Storage Container Manager (SCM)  DataNodeとheartbeat通信し、各containerがどの DataNode上に存在するかをトラッキングする  障害時にcontainerのレプリケーションを実施 Ozoneを構成するコンポーネント
  11. 11. © 2017 NTT DATA Corporation 11 Volume作成におけるリクエストの流れ Key Space Manager (KSM) Storage Container Manager (SCM) Ozone Client Containers Ozone Handler DataNode Containers Ozone Handler DataNode ・・・ ① create volume ② create volume  Volume, Bucketに関するリクエストは同じ流れ
  12. 12. © 2017 NTT DATA Corporation 12 オブジェクト挿入におけるリクエストの流れ Key Space Manager (KSM) Storage Container Manager (SCM) Ozone Client Containers Ozone Handler DataNode Containers Ozone Handler DataNode ・・・ ① put object ② allocate containers ③ container names ⑥ put data ④ get container locations ⑤ container locations (pipeline)
  13. 13. © 2017 NTT DATA Corporation 13  DataNode -> ObjectStoreHandler -> DistributedStorageHandler という順番で追うことで、Ozone Handlerの全貌が掴める  DistributedStorageHandler が クライアントからのリクエスト を受け付ける  Volumeの作成 -> #createVolume  オブジェクトの挿入 -> #newKeyWriter  ...  デモ ソースコードリーディング
  14. 14. © 2017 NTT DATA Corporation 14 1. SCMがcontainerを3つ選択 2. クライアントはcontainer Aに書き込む 3. container Aはcontainer Bに対して書き込む (ここで書き込みが正常に完了したとみなす) 4. container Bはcontainer Cに対して書き込む container replicationの流れ Copysets RAFT コンテナ B クライアント 書き込み完了 コンテナ A コンテナ C
  15. 15. © 2017 NTT DATA Corporation 15  ランダムレプリケーションだと、データロストの確率が増える  5000ノードのクラスタで1%のサーバが同時に故障した場合、 ほぼ確実にデータロスト  レプリケーションをするノードの組み合わせが増えすぎること が問題  ノードの組み合わせ: 5000C3 = 約208億通り  データロストする組み合わせ: 50C3 = 19600通り  あるblockが故障する確率: 208億/19600 = 約100万分の1  block数は億オーダー -> データロスト  ノードの組み合わせを減らすしかない Copysets: Reducing the Frequency of Data Loss in Cloud Storage
  16. 16. © 2017 NTT DATA Corporation 16  Scatter width (以下 S) を定義  あるノードのデータのコピーを持っているノード数がS  9 nodeの場合、{1, 2, 3}, {4, 5, 6}, {7, 8, 9}, {1, 4, 7}, {2, 5, 8}, {3, 6, 9} という組み合わせは S=4 を満 たす  ここで、{1, 2, 3}はあるデータが 1, 2, 3番のノードにそ れぞれレプリケーションされることを示す  1にあるデータは 2, 3, 4, 7の4ノードが持っている (S=4)  Sを小さくすると組み合わせが減り、データロスト発生確率は 下がるが、小さくしすぎてもよくない  故障時の再レプリケーションが遅くなる Copysets: Reducing the Frequency of Data Loss in Cloud Storage
  17. 17. © 2017 NTT DATA Corporation 17  Sをなるべく保ったまま、組み合わせを減らすことが重要  以下はどちらもS=4だが、上のほうがよい  {1, 2, 3}, {4, 5, 6}, {7, 8, 9}, {1, 4, 7}, {2, 5, 8}, {3, 6, 9}  {1, 2, 3}, {2, 3, 4}, {3, 4, 5}, {4, 5, 6}, {5, 6, 7}, {6, 7, 8}, {7, 8, 9}, {8, 9, 1}, {9, 1, 2}, {1, 2, 4}, {1, 3, 4}, {2, 3, 5}, {2, 4, 5}, {3, 4, 6}, {3, 5, 6}, {4, 5, 7}  詳細は省くが、うまく作ると組み合わせ数は O(S) になる  完全ランダムの場合、O(SR-1 ) Copysets: Reducing the Frequency of Data Loss in Cloud Storage
  18. 18. © 2017 NTT DATA Corporation 18 5000台のうち50台故障時のデータロスト発生確率
  19. 19. © 2017 NTT DATA Corporation 19 Copysetsによって書き込み先が決まる流れ Permutation Phase Copyset と呼ばれるノードのまとまりを ランダムに生成した順列に基づいて決定 Replication Phase ランダムにひとつのノードを選択し、 copysets に従ってレプリケーションを実施 ⇒ Ozone は Copysets のアルゴリズムに基づいて書き込み先のコンテナを3つ決定
  20. 20. © 2017 NTT DATA Corporation 20  分散合意のプロトコル  詳しくはこちら: http://thesecretlivesofdata.com/raft/  Ozoneの開発メンバが中心となって、RAFTのJava実装 Apache Ratis (Incubator)を開発  https://github.com/apache/incubator-ratis  OzoneではレプリケーションにRatisを利用 RAFT
  21. 21. © 2017 NTT DATA Corporation 21  trunkではなく、HDFS-7240 branchをビルド  ozone-site.xmlの設定例  Ratisはデフォルト無効 (レプリケーションされない) Ozoneのセットアップ、設定 <configuration> <property name="ozone.enabled" value="true" /> <property name="ozone.container.metadata.dirs" value="containerを格納するディレクトリ" /> <property name="ozone.scm.names" value="SCM のホスト名" /> <property name="ozone.scm.client.address" value="SCM のホスト名"/> <property name="ozone.ksm.address" value="KSM のホスト名" /> <property name="dfs.container.ratis.enabled" value="true" /> </configuration>
  22. 22. © 2017 NTT DATA Corporation 22  SCM  KSM Ozoneの起動 $ hdfs --daemon start scm $ hdfs --daemon start ksm
  23. 23. © 2017 NTT DATA Corporation 23  design docやAPI docがJIRAにあるが、情報が古い  ソースコード付属のマニュアルがおすすめ  https://github.com/apache/hadoop/blob/HDFS- 7240/hadoop-hdfs-project/hadoop- hdfs/src/site/markdown/OzoneGettingStarted.md.v m 困ったときは...
  24. 24. © 2017 NTT DATA Corporation 24 KSM Web UI (port 9874)
  25. 25. © 2017 NTT DATA Corporation 25 SCM Web UI (port 9876)
  26. 26. © 2017 NTT DATA Corporation 26 DataNode Web UI (port 9864)
  27. 27. © 2017 NTT DATA Corporation 27 config確認が便利になった
  28. 28. © 2017 NTT DATA Corporation 28 config確認が便利になった
  29. 29. © 2017 NTT DATA Corporation 29  Volumeの作成  quota設定はここで実施  Bucketの作成  ACLの設定はここで実施  Keyの作成  実データのコピー データを配置してみる $ hdfs oz -createVolume http://localhost:9864/volume ¥ -user centos $ hdfs oz -createBucket http://localhost:9864/volume/bucket $ hdfs oz -putKey http://localhost:9864/volume/bucket/key ¥ -file localkey
  30. 30. © 2017 NTT DATA Corporation 30  DNにおける ozone.container.metadata.dirs 配下の構成  datanode.id: DNのユニークIDを格納  ratis/: RAFTのログを格納  repository/: containerの実データを格納  実際にデータを置いてみたところ、2個のノードにしかレプリ ケーションされていなかった... (11/22時点)  DNログを読む限り、Ratisでのログ共有に失敗している  今後の修正に期待 (最新版だと動くかも)  ちなみに2017/9時点ではRatisが入っていなかった  状況が刻一刻と変わるので、長い目で見守るのが良さそう データの配置状況
  31. 31. © 2017 NTT DATA Corporation 31  10人規模でのonline meetingが何度か実施されている  議事録は JIRA に記載されている  trunkにマージすべきか延長すべきかで、まだ結論が出ていない  Ozoneの取り組みがHDFSのスケーラビリティを解消している ことについては同意  NameNodeとOzoneを統合した状態でマージするのが理想だ が、NameNodeにおいて密結合している FSNameSystem と BlockManager のロックを分離する必要があって hard work  このタイミングでマージするのが落としどころでは 3.1.0でのマージに向けた議論
  32. 32. © 2017 NTT DATA Corporation 32  NameNodeにおけるFSNameSystemとBlockManagerの密結合は、 HDFS append APIを実装した2010年にもたらされた  当時は、RAFTのようなメンバの追加/削除が可能な分散合意プロトコルが 一般的ではなかったため、中央集権的に実装された  Ozoneのマージを機に、7年続いた密結合が取り崩されることに期待が膨ら む  私も開発に参加して、取り組みを加速させたい 最後に
  33. 33. © 2017 NTT DATA Corporation 33 https://issues.apache.org/jira/secure/attachment/12895963/HDFS%20Scalability%20and%20Ozone.pdf
  34. 34. © 2017 NTT DATA Corporation 34  Copysets: Reducing the Frequency of Data Loss in Cloud Storage  https://www.usenix.org/node/174509 References
  35. 35. © 2017 NTT DATA Corporation 本資料中に記載されている会社名、商品名、ロゴは、各社の商標または登録商標です。

×