Apache Hadoopの新機能Ozoneの現状

© 2017 NTT DATA Corporation
Apache Hadoopの新機能Ozoneの現状
2017/11/29
株式会社NTTデータ OSSプロフェッショナルサービス
鯵坂明
Hadoopソースコードリーディング第24回

© 2017 NTT DATA Corporation 2
 鯵坂明 (Akira Ajisaka, @ajis_ka)
 NTTデータ OSSプロフェッショナルサービス
 Apache Hadoopと関わり続けて6年が経過
 Hadoopの新機能や、関連するミドルウェアの検証
 プロジェクトへの技術支援
 サポートサービス
 Apache Hadoop committer, PMC member
 HadoopのJava 9対応を実施中
自己紹介

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

 https://cwiki.apache.org/confluence/display/HADOOP/R
oadmap
今後のRoadmap

 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

本スライドは、feature branchで開発中の機能
を紹介するものです
設定方法、コマンドなど全てにおいて、今後変更
される可能性が大いにあります
Ozoneについて詳しく紹介する前に... 注意事項

ボリューム、バケット、オブジェクト
Ozone
ACLACL ACL
ボリューム
バケットを複数持つ。
管理者アカウントが設定されている。
一定の容量が割り当てられている。
バケット
オブジェクトを複数持つ。
ACL を設定することができる。
名前空間はバケットで独立。
オブジェクト
キーと値の組。
キーはバケット内でユニーク。
･･･
･･･
･･･

各コンポーネント間の関係
Key Space Manager (KSM) Storage Container Manager (SCM)
Ozone Client
Containers
Ozone Handler
DataNode
Containers
Ozone Handler
DataNode
･･･

 Container
 DataNode上に保持
 Ozoneにおけるレプリケーションの単位
Ozoneを構成するコンポーネント

 Ozone Handler
 クライアントに対してOzoneのREST APIを提供
 各DataNode上で動作
 Key Space Manager (KSM)
 名前空間に関するクエリを処理
 オブジェクトのキーやバケット名からcontainerを解決
 Storage Container Manager (SCM)
 DataNodeとheartbeat通信し、各containerがどの
DataNode上に存在するかをトラッキングする
 障害時にcontainerのレプリケーションを実施
Ozoneを構成するコンポーネント

Volume作成におけるリクエストの流れ
Ozone Client
Containers
Ozone Handler
DataNode
Containers
Ozone Handler
DataNode
･･･
① create volume
② create volume
 Volume, Bucketに関するリクエストは同じ流れ

オブジェクト挿入におけるリクエストの流れ
Ozone Client
Containers
Ozone Handler
DataNode
Containers
Ozone Handler
DataNode
･･･
① put object
② allocate containers
③ container names
⑥ put data
④ get container locations
⑤ container locations (pipeline)

 DataNode -> ObjectStoreHandler ->
DistributedStorageHandler という順番で追うことで、Ozone
Handlerの全貌が掴める
 DistributedStorageHandler がクライアントからのリクエスト
を受け付ける
 Volumeの作成 -> #createVolume
 オブジェクトの挿入 -> #newKeyWriter
 ...
 デモ
ソースコードリーディング

1. SCMがcontainerを3つ選択
2. クライアントはcontainer Aに書き込む
3. container Aはcontainer Bに対して書き込む
(ここで書き込みが正常に完了したとみなす)
4. container Bはcontainer Cに対して書き込む
container replicationの流れ
Copysets
RAFT
コンテナ B
クライアント
書き込み完了
コンテナ A コンテナ C

 ランダムレプリケーションだと、データロストの確率が増える
 5000ノードのクラスタで1%のサーバが同時に故障した場合、
ほぼ確実にデータロスト
 レプリケーションをするノードの組み合わせが増えすぎること
が問題
 ノードの組み合わせ: 5000C3 = 約208億通り
 データロストする組み合わせ: 50C3 = 19600通り
 あるblockが故障する確率: 208億/19600 = 約100万分の1
 block数は億オーダー -> データロスト
 ノードの組み合わせを減らすしかない
Copysets: Reducing the Frequency of Data Loss in Cloud Storage

 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を小さくすると組み合わせが減り、データロスト発生確率は
下がるが、小さくしすぎてもよくない
 故障時の再レプリケーションが遅くなる

 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
)

5000台のうち50台故障時のデータロスト発生確率

Copysetsによって書き込み先が決まる流れ
Permutation Phase
Copyset と呼ばれるノードのまとまりを
ランダムに生成した順列に基づいて決定
Replication Phase
ランダムにひとつのノードを選択し、
copysets に従ってレプリケーションを実施
⇒ Ozone は Copysets のアルゴリズムに基づいて書き込み先のコンテナを3つ決定

 分散合意のプロトコル
 詳しくはこちら: http://thesecretlivesofdata.com/raft/
 Ozoneの開発メンバが中心となって、RAFTのJava実装
Apache Ratis (Incubator)を開発
 https://github.com/apache/incubator-ratis
 OzoneではレプリケーションにRatisを利用
RAFT

 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>

 SCM
 KSM
Ozoneの起動
$ hdfs --daemon start scm
$ hdfs --daemon start ksm

 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
困ったときは...

KSM Web UI (port 9874)

SCM Web UI (port 9876)

DataNode Web UI (port 9864)

config確認が便利になった

 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

 DNにおける ozone.container.metadata.dirs 配下の構成
 datanode.id: DNのユニークIDを格納
 ratis/: RAFTのログを格納
 repository/: containerの実データを格納
 実際にデータを置いてみたところ、2個のノードにしかレプリ
ケーションされていなかった... (11/22時点)
 DNログを読む限り、Ratisでのログ共有に失敗している
 今後の修正に期待 (最新版だと動くかも)
 ちなみに2017/9時点ではRatisが入っていなかった
 状況が刻一刻と変わるので、長い目で見守るのが良さそう
データの配置状況

 10人規模でのonline meetingが何度か実施されている
 議事録は JIRA に記載されている
 trunkにマージすべきか延長すべきかで、まだ結論が出ていない
 Ozoneの取り組みがHDFSのスケーラビリティを解消している
ことについては同意
 NameNodeとOzoneを統合した状態でマージするのが理想だ
が、NameNodeにおいて密結合している FSNameSystem
と BlockManager のロックを分離する必要があって hard
work
 このタイミングでマージするのが落としどころでは
3.1.0でのマージに向けた議論

 NameNodeにおけるFSNameSystemとBlockManagerの密結合は、
HDFS append APIを実装した2010年にもたらされた
 当時は、RAFTのようなメンバの追加/削除が可能な分散合意プロトコルが
一般的ではなかったため、中央集権的に実装された
 Ozoneのマージを機に、7年続いた密結合が取り崩されることに期待が膨ら
む
 私も開発に参加して、取り組みを加速させたい
最後に

https://issues.apache.org/jira/secure/attachment/12895963/HDFS%20Scalability%20and%20Ozone.pdf

 Copysets: Reducing the Frequency of Data Loss in
Cloud Storage
 https://www.usenix.org/node/174509
References

Apache Hadoopの新機能Ozoneの現状

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Apache Hadoopの新機能Ozoneの現状

Similar to Apache Hadoopの新機能Ozoneの現状 (20)

More from NTT DATA OSS Professional Services

More from NTT DATA OSS Professional Services (20)

Recently uploaded

Recently uploaded (11)

Apache Hadoopの新機能Ozoneの現状