Conference PaperPDF Available

分散オブジェクトストレージ Ceph のための Spark ストレージコネクタの設計

Authors:

Abstract

高いスケーラビリティを特徴とする分散オブジェクトストレージ Ceph は,大規模データを蓄積 ・分析に利用するデータレイクとしての活用が広まっている.大規模化するデータを効率的に処理するためには,大容量ストレージとデータ処理アプリケーションとの高速なデータ転送を実現することが重要である.本研究では,スケーラブルな分散オブジェクトストレージ Ceph に蓄積されたデータを効率的に利用することを目的として,リアルタイムの大規模データ処理基盤として広く使用されている Apache Spark や Apache Hadoop からデータの利用を可能にするストレージコネクタを設計 ・実装した.
情報処理学会研究報告
IPSJ SIG Technical Report
分散オブジェクトストレージ Ceph のための
Spark ストレージコネクタの設計
高橋 宗史1,a) 建部修見2
概要:高いスケーラビリティを特徴とする分散オブジェクトストレージ Ceph は,大規模データを蓄積・
分析に利用するデータレイクとしての活用が広まっている.大規模化するデータを効率的に処理するため
には,大容量ストレージとデータ処理アプリケーションとの高速なデータ転送を実現することが重要であ
る.本研究では,スケーラブルな分散オブジェクトストレージ Ceph に蓄積されたデータを効率的に利用
することを目的として,リアルタイムの大規模データ処理基盤として広く使用されている Apache Spark
Apache Hadoop からデータの利用を可能にするストレージコネクタを設計・実装した.
キーワード:分散オブジェクトストレージ,CephApache SparkApache Hadoopストレージコネクタ
1. はじめに
1.1 オブジェクトストレージ
科学と産業の様々な分野において,大規模なデータを蓄
積して,大規模なデータ処理を行うことによって,価値の
あるデータを発見しようとするこ込みが盛んに行わてい
る.科学計算の大規模化・産業でのデータ収集の拡大によ
り,データ処理のために蓄積されるデータの容量は増加の
一途をたどっており,スケーラビリティが高く,大容量の
データをより少ないコストで長期間保管することができる
オブジェクトストレージの重要性は高まっている.
オブジェクトストレージには,パブリッククラウドプロ
バイダが提供する Amazon S3 [1] Google Cloud Stor-
age [2] などのサービスが存在する.パブリッククラウ
のストレージのネットワーク性能は改善が続けられてお
[3],コストや要求性能が満たされる場合には選択肢と
して有力である。しかし,特に,インタラクティブなデー
タ解析を高速に行ったり,セキュリティ上の制限,遠隔地
とのデータ転送に伴うレイテンシやバンド幅の制限などの
理由により,オンサイトでオブジェクトストレージシステ
ムを保有する要求も大きい.
1筑波大学 大学院 システム情報工学研究科
コンピュータサイエンス専攻
Department of Computer Science, Graduate School of Systems
and Information Engineering, University of Tsukuba
2筑波大学 計算科学研究センター
Center for Computational Sciences, University of Tsukuba
a) shuuji3@hpcs.cs.tsukuba.ac.jp
スーパーコンピューティングの分野では,エクサスケー
ル・コンピューティングへ向けて,ストレージを含む各コ
ンポーネントが発展を続けている.計算ノードの性能向
上やスケーラビリティの向上に伴い,しかし,コンピュー
ティングとストレージの性能差は広がり続けており,スト
レージシステムに対しては,多数の計算ノードからのアク
セス要求に応えられる高い性能が求められている.POSIX
互換ファイルシステムでは,メタデータへのアクセスが性
能のボトルネックになることが多い.この問題を解消する
ために,POSIX の制限を緩和した,スケーラビリティの高
いオブジェクトストレージも補完的に活用されている.
1.2 分散オブジェクトストレージ Ceph
Ceph [4] は,エクサスケールレベルの優れたスケー
ビリティを持つ,ソフトウェア定義型の分散オブジェクト
ストレージであるCeph のストレージクラスタは,コモ
ディティなハードウェアを用いて構築することができ,メ
タデータサーバーが存在せず,クラスタを構成するコン
ポーネントに単一障害点がなく,可用性が高いことが特徴
である.クラスタのダウンタイムなしでのキャパシティの
拡張,ストレージシステムのローリングアップデートなど
が可能となっている2006 年に基本設計が発表されて
来, フリーソフトウェアとして継続的に開発が進められて
おり,現在でも活発に改良が続けられている.
Ceph には,RADOS Block Device (RBD)CephFSRA-
DOS Gateway (RGW), などのさまざまなイン
ターフェイスがある.
1
2019 Information Processing Society of Japan
Vol.2019-HPC-171 No.1
2019/9/20
情報処理学会研究報告
IPSJ SIG Technical Report
RBD は,RADOS オブジェクトストアをブロックデバイ
スとして抽象化するインターフェイスである.用途として
は,OpenStack CloudStack などを用いて構築されたプ
ライベートクラウドにおいて,仮想ディスクイメージの格
納先や,オンデマンドの仮想ブロックデバイスを提供する
ストレージ基盤として利用されている [5]
CephFS は,RADOS オブジェクトストアを POSIX 準拠
のファイルシステムとして抽象化するインターフェイスで
ある.しかし,他のインターフェイスと異なり,ファイル
の情報を管理すためのメタデータサーバーを必要として
いる.
RGW は,RADOS オブジェクトストアを REST API
よって利用する,S3 互換のオブジェクトとして抽象化す
るインターフェイスである.パブリッククラウドの S3
換のオブジェクトストレージサービスのバックエンド [6]
OpenStack などのプライベートクラウドのストレージ
基盤としても広く活用されている [5], [7].また,オーバー
ヘッドは大きくなるものの,プライベートクラウドのファ
イルストレージとしてNFS 経由で利用することも可能で
ある [7], [8], [9]
は,RADOS オブジェクトストアに直接アク
セスすることが可能なライブラリであり,RBD RGW
は, を基盤として構築されている.
その他にも,15 万台もの大規模な仮想マシン群のバック
エンドとしての利用や,10 GiB/s 規模の大規模な科学実
験データを保存するためのストレージのバックエンドとし
ての利用も検討されているなど,高いパフォーマンスやス
ケーラビリティが求められる環境で実用されている [10]
特に,大規模なデータを格納するような場合に,HDFS
に存在するストレージクラスタ管理の煩雑さの問題,ス
ケーラビリティの制限,MapReduce のみではなく,多様
なデータ処理技術が活用されるようになってきたことによ
り,HDFS から Ceph への移行が進んでいる [11], [12]
さらに,ストレージを高効率に利用できるようにするた
めに,HDFSCeph ともに Erasure Coding が実装され
おり,実用化されている [13], [14]
1.3 Apache Spark
Apache Spark [15], [16], [17] は,大規模分散処理が可能
なデータ処理基盤ソフトウェアである.
ワークロードによっては現在でも Apache Hadoop
用だが,特に,特定のデータに対して反復的な処理が必要
なインタラクティブなデータ解析や機械学習などイテレー
ション処理が重要なワークロードには Apache Spark が適
しており,こうしたデータ処理では広く普及している.
Apache Spark では,標準でさまざまなライブラリが提
供されており,大規模ストレージに格納されたデータに対
して,MLlib による機械学習,Spark Streaming によるス
トリーム処理,GraphX によるグラフ処理などを行うシス
テムを構築することができる.
また Apache Spark ック 上の
タ処理基盤としても採用が広がっており,Google Cloud
Platform Dataproc [18] や,Amazon Web Service
Amazon EMR [19] などは,Apache Spark をマネージド
サービスとして提供している.こうしたサービスでは,各
クラウドが提供するオブジェクトストレージと Apache
Spark との間でオブジェクトデータの I/O を行うためのコ
ネクタが提供されており,広く活用されている.
1.4 既存の手法の問題点と提案手法の利点
現在,Apache Spark から Ceph に格納されたデータを
利用する場合には,もっぱら,AWS S3 オブジェクトス
トレージ用に開発された S3A コネクタが利用されている.
S3A コネクタは,Hadoop FileSystem API の実装の一つ
であり,Spark S3 のオブジェクトデータを読み書き
することを可能にする.Ceph のインターフェイスの 1
である RADOS Gateway を利用することで,S3 オブジェ
クト互換の形式でデータを Ceph のストレージクラスタに
格納することができるため,Ceph Spark のデータスト
アとして利用することができるようになる.
しかしながら,RADOS Gateway をこのように用いる場
合, から取得しCeph ネイティブRADOS
オブジェクトを,一度 S3 オブジェクトの形式に変換し
上で,さらに S3A からデータを読み書きする必要があり,
データ形式の変換が 2重に行われることになる.また,以
前より,RADOS Gateway 自体が Ceph I/O 性能のボ
トルネックの原因となることが知られてきた.
1に,既存の S3A コネクタと本研究で実装した Ceph
コネクタにおける,オブジェクトの変換の違いを示す.
そこで,本研究では,Spark から直接 RADOS オブジェ
クトを読み書きを行うことができCeph コネクタの設計・
実装を試みた.ボトルネックの原因となっていた Rados
Gateway をバイパスすることで,オーバーヘッドが削減さ
れ,I/O の性能の向上が期待される.
2. 関連研究
2.1 GCS コネクタ / S3 コネクタ (S3A)
Google Cloud Storage (GCS) コネクタ [20], [21] は,GCS
のための実装である.
S3A コネクタは,Hadoop コミュニティによって提供さ
れている Hadoop FileSystem API の実装であり,AWS S3
オブジェクトストレージとデータの読み書きをするための
コネクタである [22], [23]
いずれも Hadoop FileSystem API を実装しているため,
オブ レー デー Apache
Spark Apache Hadoop から透過的に利用することがで
2
2019 Information Processing Society of Japan
Vol.2019-HPC-171 No.1
2019/9/20
情報処理学会研究報告
IPSJ SIG Technical Report
Hadoop FileSystem API
librados
Ceph
Adapter
S3A
Adapter
S3
Object
RADOS Gateway
(S3 Interface)
RADOS
Object
1既存の S3A コネクタと Ceph コネクタにおけるオブジェクト
の変換の違い
きる.これらのコネクタは,パブリッククラウドのサービ
スを利用することを前提としており,プライベートクラウ
ドや,自身で管理されている高性能なストレージクラスタ
で利用するためには,パブリッククラウドの仕様に合わせ
た実装を開発する必要がある.
2.2 CephFS-Hadoop プラグイン
Ceph の ス ト レ ー ジ ク ラ ス タ の デ ー タ に Spark
Hadoop からアクセスする手段としては,Ceph 公式の
cephfs-hadoop プラグインが提供されている [24].これ
は,CephFS インターフェイスを用いて,データを Hadoop
FileSystem API を経由で利用することを可能にするもの
であり,HDFS を置換することを目的として開発された
ラグインである.
しかし,1.2 節で言及したように,CephFS Ceph を基
盤として POSIX 拠のファイルシステムを構築すること
目的として開発されているインターフェイスである.Ceph
のインターフェイスの中では比較的性能が低く,また,完
全な POSIX 準拠を必要としない Hadoop FileSystem API
から利用するためには不要なインターフェイスが多く実装
されているため,さまざざまなオーバーヘッドが存在する.
2.3 分散ファイルシステム向けプラグイン
分 散 フ ァ イ ル シ ス テ ム か ら デ ー タ 処 理 基 盤 へ 接 続
す る た め の 同 様 の プ ラ グ イ ン と し て ,GlusterFS
ため [25]GPFS GPFS-
hadoop [26]Gfarm ?のための Hadoop-Gfarm [27] が開
発されているが,これらはどれも特定の分散ファイルシス
テムに特化したものとなっており,オブジェクトストレー
ジのデータ特性に合わせたオブジェクトデータへの直接ア
クセスを提供するものとはなっていない.
2.4 その他
Ceph に格納されたデータに Apache Hadoop からアク
セスすることを目的に開発されていたプラグインとして
は,RGW に対してロードバランシングを行う RGWFS
RGW-Proxy [28] がある.しかし,これらはオーバーヘッ
ドの存在する RGW に対してさらに追加のレイヤーを加え
るプラグインであり,また,Apache Spark などのデータ
処理基盤からのアクセスには S3A の方がより性能が高い
ため,RADOS オブジェクトへの高性能なアクセスを提供
するという本研究の目的には適さない.
3. 設計と実装
3.1 Spark のストレージインターフェイス
Spark のストレージインターフェイスは Hadoop のス
トレージインターフェイスと完全な互換性を持っており,
Hadoop FileSystem API を実装したすべてのストレージ
コネクタはSpark からも透過的に利用することがで
る.したがって,Ceph のオブジェクトにアクセスするこ
とが可能な Hadoop FileSystem API の実装を行うことに
より,Ceph のデータを Spark Hadoop から直接利用す
ることが可能になる.
3.2 を用いた RADOS オブジェクトへの直接
アクセス
本研究では,Ceph RADOS オブジェクトに直接アク
セスして利用することができる ライブラリを使
用して Ceph コネクタを実装する. 体は C++
で書かれているが,JavaPythonGoHaskellRust
RubyNode.jsPHPDなど,多数の言語用のバインディ
ングが存在するため,さまざまなプログラムから利用する
ことができる.
また,コネクタを実装するプログラミング言語としては,
Scala を選択した.Scala は,Java ライブラリの大部分
をそのまま利用することができ,コンパイル時に Java
バイトコードレベルで互換性があるプログラムを生成する
ことができる.そのため, Java バインディン
グである [29] を利用することで,Scala から
Ceph クラスタ内の RADOS オブジェクトへアクセスする
3
2019 Information Processing Society of Japan
Vol.2019-HPC-171 No.1
2019/9/20
情報処理学会研究報告
IPSJ SIG Technical Report
ことができるようになる. バインディングは,
JNA (Java Native Access) [30] を用いて実装されており,
のネイティブコードが実行されるため,JVM
実行することによるオーバーヘッドはほぼ存在しない.さ
らに,Scala を利用したことで,Java に比べてリーダビリ
ティの高い簡潔なコードで記述することが可能となった.
3.3 コネクタの構成
2に,実装した Ceph コネクタの構成の概略を示す.
本研究ではHadoop FileSystem API の抽象クラスで
ある を継承した新たなクラスと
して, を実装した.このク
ラスが Spark などのデータ処理基盤の I/O 理のエン
リーポイントとなり,データI/O を行う責務を担うこと
になる.
の実際の I/O 理を行うのは,それぞ
れ クラスと
クラスである.
この中で,Java New I/O ライブラリにより提供
され I/O (
)を活用することで,Ceph クラスタ
RADOS オブジェクトのデータとの I/O 理を高速
する工夫を行った.
3.4 オブジェクトストレージにおける仮想的なディレクト
リの表現
オブジェクトストレージでは,POSIX 準拠ファイルシス
テムの制限を緩和するために,フラットな名前空間が採用
されており,バケット内のすべてのオブジェクトはバケッ
トルート直下に配置されている.POSIX 準拠ファイルシス
テムでは の文字がディレクトリ階層を表現するのに使わ
れるが,オブジェクトストレージでは,名前に の文字を
含めたとしても,単なるファイル名の文字の 1つとして扱
われるようになっている.
Hadoop FileSystem API POSIX に完全に準拠してい
るわけではないが,POSIX ファイルシステムがベースと
なっており,ディレクトリ階層の存在を前提として設計
されている.そのため,オブジェクストレージであっ
ても,ファイルとディレクトリとを区別して処理を行う
必要がある.ディレクトリ階層の存在を前提としている
Hadoop FileSystem API のメソッドとしては,カレント
ディレクトリの 1階層のみのファイル情報の一覧を取得す
る ,複数のディレクトリ階層を作成す
,ファイルやディレクトリの再帰的な削除や
動を行う必要がある や が存在する.
本研究で実装した Ceph ネクタでは,こうした API
対して適切に処理を行うために,ファイル名の末尾が で
あるサイズ 0のオブジェクトを作成するという方法を採用
1Ceph クラスタの実験ノードの環境
コンポーネント 説明
CPU Intel Xeon CPU E5-2630 v4 @ 2.20GHz x2
メモリ DDR2 FB-DIMM 667 MHz 4GB x8 (32GB)
ネットワーク 10 GbaseT/Full
ストレージ RevoDrive3 X2 SSD 240GB (60GB x4) x1
OS CentOS Linux release 7.5.1804 (Core)
Linux 3.10.0-957.21.3.el7.x86 64
Ceph v14.2.2 nautilus (stable)
した.これにより,その場所に仮想的なディレクトリが存
在すると見做し,データ処理基盤に対してディレクトリ階
層が存在しているものとして振る舞うことができるように
した.
4. 実験と手法
4.1 実験環境
実験では,合計 6ノードを使用して Ceph ストレージク
ラスタを構成した.表 1に,クラスタを構成する各ノー
ドの情報を示す.6ノードのうち,1ノードは管理用のマ
スターノード,5ノードはオブジェクトをストアするスト
レージノードの役割を担う.
マスターノードには,Ceph クラスタの管理用のデーモ
ン および をセットアップした.スト
レージノードには,ストレージデーモンの を
RevoDrive3 X2 4つのモジュール 1にごとに 1プロセ
ス,すなわち,1ノードごとに 4プロセスをセットアッ
した.RevoDrive3 X2 には 4つの SSD モジュールが搭載
されており,各モジュールごとに独立した I/O が可能であ
り,モジュールごとにデーモンを割り当てることで高速な
並列 I/O 処理が可能となるためである.
Ceph のレプリケーションファクターは,デフォルトの
3に設定した.また,Ceph v12 (Luminous) 以降のデフォ
ルトの設定では,RADOS オブジェクトストアに格納する
ことができるオブジェクトのサイズが 128 MiB までに制
限されている.これは,サイズが大きすぎるオブジェクト
が多数存在すると,クラスタ構成の変化によるオブジェク
トの再配置や,障害回復時にパフォーマンスの低下を招く
場合があるためである.実験では,より大きなサイズのオ
ブジェクトを格納した場合の性能を確かめるために,オ
ブジェクトサイズの上限を 1024 MiB まで増やして実験を
行った.
4.2 Ceph コネクタの性能評価
Ceph クラスタと Apache Spark との間の,オブジェ
トの Read Write それぞれに対して,性能評価を行った.
Read については1248163264128256512
1024 MiB のサイズのランダムなテキストデータ1 GiB
分生成し,これらを RADOS オブジェクトとして Ceph
4
2019 Information Processing Society of Japan
Vol.2019-HPC-171 No.1
2019/9/20
情報処理学会研究報告
IPSJ SIG Technical Report
spark-ceph-connector
CephFileSystem
+ open(): CephFSInputStream
+ create(): CephFSOutputStream
+ listStatus(): Array[FileStatus]
hadoop.fs.FSInputStream
+ read(buf)
org.apache.hadoop.fs.FileSystem
CephFSInputStream
+ read(buf)
hadoop.fs.FSDataOutputStream
+ write(buf)
CephReadChannel
+ read(buf)
CephWriteChannel
+ write(buf)
java.nio.channels.
SeekableByteChannel
+ read(buf)
+ write(buf)
librados
+ open(): FSInputStream
+ create(): FSOutputStream
CephFSDataOutputStream
- channel:
 CephWriteChannel
+ write(buf)
+ listStatus(): Array[FileStatus]
2Ceph コネクタの構成
5
2019 Information Processing Society of Japan
Vol.2019-HPC-171 No.1
2019/9/20
情報処理学会研究報告
IPSJ SIG Technical Report
124.8
523.1
107.1
700.1
# of Prallel
Throughput [MiB/s]
0.0
200.
0
400.
0
600.
0
800.
0
1.0 16.0
Read Write
3の測定結果
ラスタに格納しておき,Apache Spark からの読み込むの
スループットを測定した.
Write ついては,Apache Spark のキャッシュにあらか
じめロードしておいた同様のサイズのオブジェクトデータ
を,それぞれ Ceph クラスタへ書き込むときのスループッ
トを測定した.なお,オブジェクトデータの準備時の Ceph
クラスタへのデータの書き込みには,GNU Parallel [31]
用いて並列化を行うことで,高速にデータを格納する工夫
を行った.
4.3 性能のベースライン
まずCeph ストレージクラスタの性能のベースラ
Ceph
ベンチマクを用いて予 実験を行 た.
これにより,Ceph クラスタに対して,並列アクセスを含
む直接のシーケンシャルアクセスの性能を測定することが
できる.並列アクセス数として 1並列および 16 並列,オ
ブジェクトサイズとして基本となる 4 MiB に対して,シー
ケンシャルの Read / Write 性能を測定した.
の測定結果を図 3に示す.
1並列の Read/Write では,Read 124.8 MiB/sWrite
107.1 MiB/s であった.本稿では,1並列での性能測定
を行ったため,この値が性能の上限となると考えられる.
一方,16 並列の Read/Write では,Read 1並列のと
きの約 4倍の 523.1 MiB/sWrite が約 7700.1 MiB/s
の高い性能を示した.
5. 結果と考察
5.1 Read 性能
オブジェクトサイズを変化させたときの Read の性能を,
4に示す.
オブジェクトサイズが大きくなるにつれて Read 能も
向上し,オブジェクトサイ32 MiB あたりから性能が徐々
に飽和していることが確認できる.
最も大きなオブジェクトサイズ 1024 MiB のとき,Read
性能は最大となり,112.1 MiB/s であった.節 4.3 で測
24.1 24.6 28.9
53.1
79.7
91.4 94.7 100.6
107.6 107.7 112.1
Object Size [MiB]
Throughput [MiB/s]
0.0
25.0
50.0
75.0
100.0
125.0
1 2 4 8 16 32 64 128 256 512 1024
4オブジェクトサイズを変化させたときの Read 性能
0.106 0.141 0.175
0.294
0.475
0.626
0.716
0.781 0.820 0.809
Object Size [MiB]
Throughput [MiB/s]
0.000
0.250
0.500
0.750
1.000
1 2 4 8 16 32 64 128 256 512
5オブジェクトサイズを変化させたときの Write 性能
した Read のベースライン性能と比較すると,オブジェク
トサイズ 1024 MiB 90 % の非常に高い性能が発揮さ
れた.Hadoop HDFS ではデフォルトでブロックサイズ
128 MiB が利用されるがCeph で同じサイズの 128 MiB
のサイズのオブジェクトを Read した場合でも,100.6 MiB
の性能が発揮され,ベースライン性能の約 81 %の高い性
能を発揮することができた.
5.2 Write 性能
オブジェクトサイズを変化させたときWrite の性能を,
5に示す.
オブジェクトサイズが大きくなるにつれて性能が向上し
32 MiB あたりから徐々に性能が飽和する傾向は,Read
場合とよく似ている.
一方,Read 性能がベースライン性能に対して非常に良
い性能を発揮していたのに対して,Write の性能は著しく
低く,Read の約 1/200 1/100 という非常に低い性能を
示している.最も高い 1024 MiB のオブジェクトサイズの
場合であっても,1 MiB/s を下回る結果となっている.
5.2.1 性能劣化の原因
性能劣化の原因として考えられる理由の一つはApache
Spark のデータ保存時のデータの書き込み方法であると考
えられる.Apache Spark でのデータの保存時には,耐障
6
2019 Information Processing Society of Japan
Vol.2019-HPC-171 No.1
2019/9/20
情報処理学会研究報告
IPSJ SIG Technical Report
170
256 256 246 208
85
256
168 197 170
340
426
568
439 511
426
511
480
638
426
Time [s]
Throughput [KiB/s]
0
200
400
600
800
20 40 60 80 100
Write Read
61 MiB のオブジェクト Write 時の Ceph クラスタにおける I/O
の内訳
害性を高めるなどの理由により,次のような 3ステップで
のデータの書き込みが行われる.
( 1 ) ファイルシステムに対して書き込みが成功するかどう
かを確認するために,ジョブが割り当てられたタスク
という prefix のついたファイルに実際
データの書き込みを試みる.
( 2 ) データの書き込みが成功したら,書き込まれたファイ
ルを,当該タスクが生成したデータとしてファイルシ
ステムの別の一時ファイルに する.
( 3 ) すべてのタスクが成功したら,一時ファイルをファイ
ルシステム上の最終的な書き込み場所に移動するため
に,さらに を実行する.
このとき問題となるのは,オブジェクトストレージのフ
ラットな名前空間とデータの実体とを結びつけている関係
である.Ceph では,オブジェクトデータの格納先を決定
するために CRUSH というデータの格納ストレージを決
定的に計算可能なアルゴリズムを使用している.CRUSH
は,オブジェクト名をキーとして,ファイルの格納先を決
定するため,上のような 3ステップの処理の中で
が実行されるたびに,オブジェクト名が変更されるととも
に,Ceph クラスタ上でのオブジェクトの格納先を変更す
ることが必要とされる.そのため,rename が行われるた
びにオブジェクトデータの読み込み・コピー・削除の作業
が必要になる.本稿では,この問題の解決方法について提
示することはできなかったS3 などのオブジェクトスト
レージでも同様の問題が存在することが知られている.
5.2.2 Write 時の I/O の内訳
オブジェクトサイズを変化させたときの Write の性能を
5に,1 MiB のオブジェクト Write 時の Ceph クラスタ
における I/O の内訳を示す.この値は,Ceph クラスタ内
外の I/O の統計情報を取得することを可能にする
モジュールを利用して取得した.
グラフより,オブジェクトデータの Write 処理の間に,
Write の約 1/4 1/3 もの Read 処理が同時に行われて
いることが確認できる.この Read/Write 処理の中には,
単に 1つのオブジェクトデータの Write 処理だけではな
く,前述した 3ステップの rename による同一オブジェク
トの Read / Write が含まれていると考えられる.さらに,
Ceph クラスタ内では,中間ファイルを含むすべてのオブ
ジェクトデータに対して,3OSD にレプリケーショ
ンする Read / Write 処理が自動的に発生するため,同一
のオブジェクトデータに対して,レプリケーションのため
Read 処理と Rename 処理が競合することが性能劣化の
原因となっている可能性がある.データ書き込み時I/O
をより詳細に解析することが求められる.
6. まとめと今後の課題
本研究では,分散オ ジェクトストージ Ceph
納された大規模データを,ビッグデータ処理基盤である
Apache Spark Apache Hadoop から高効率で利用でき
るようにすることを目的として,Hadoop FileSystem API
をもとにした Ceph のストレージコネクタの設計と実装を
行った.これにより,従来から使用されている,オブジェ
クトの冗長な変換が必要なコネクタを介さずに,RADOS
オブジェクトのデータに直接アクセスすることが可能であ
ることを示した.
今後の課題としては,性能劣化の大きかった Write の性
能向上を改善するために,ノードローカルストレージを
活用し,書き込みデータを一時的に保存することにより,
Ceph クラスタとの I/O の通信を最適化することが考えら
れる.
また,図 3示した の測定結果により,
Ceph ストレージは並列アクセスにより高い性能を発揮す
ることが示された,RADOS オブジェクトへのアクセスを
効率化するために,同期アクセスによる 1並列のアクセス
だけではなく, の非同期アクセス API を活用し
たり,高い並列度のアクセスを行えるように改良すること
により,ストレージコネクタを高性能化することが挙げら
れる.
さらに,今回の実験では,シングルノードからの I/O
能のみを測定したが,多数ノードからなる Ceph クラスタ
および Spark クラスタを構成した場合のストレージアクセ
ススケーラビリティを明らかにすることも重要である.
7. 謝辞
本研究の一部は,JSPS 科研費 17H01748国立研究開発
法人新エネルギー・産業技術総合開発機構(NEDOJST
CREST JPMJCR1414 および富士通研究所との共同研究に
よる.
7
2019 Information Processing Society of Japan
Vol.2019-HPC-171 No.1
2019/9/20
情報処理学会研究報告
IPSJ SIG Technical Report
参考文献
[1] Amazon: Amazon S3拡張性と耐久性を兼ね揃えた
ラウドストレージ)| AWS.
[2] Google: Cloud Storage - オンライン データ ストレージ
| Cloud Storage | Google Cloud.
[3] 吉田 浩 , 合田 憲人 , 上田 郁夫 , 原 隆宣 , 小杉 城
治 , 森田英輔 , 中村 光志 :クラウドコールドストレー
ジに対する大規模実験データ格納のケーススタディ,研
究報告ハイパフォーマンスコンピューティング(HPC
Vol. 2018-HPC-165, No. 8, pp. 1 – 10(オンライン)DOI:
http://id.nii.ac.jp/1001/00190561/ (2018).
[4] Weil, S. A., Brandt, S. A., Miller, E. L., Long, D. D. E.
and Maltzahn, C.: Ceph: A Scalable, High-Performance
Distributed File System, Proceedings of the 7th Sympo-
sium on Operating Systems Design and Implementation,
USA, USENIX Association, p. 307–320 (online), DOI:
10.5555/1298455.1298485 (2006).
[5] OpenStack Foundation : OpenStack User Sur-
vey Analytics and Data , (online), available from
https://www.openstack.org/analytics.
[6] DigitalOcean: Storage on Digi-
talOcean , (online), available from
https://github.com/digitalocean/navigators-
guide/blob/master/book/03-backup/ch07-storage-
on-digitalocean.md.
[7] Mascetti, L., Cano, E., Chan, B., Espinal, X., Fiorot, A.,
Labrador, H. G. a. l., Iven, J., Lamanna, M., Presti, G. L.,
Mo ´s cicki, J. et al.: Disk storage at CERN, Journal of
Physics: Conference Series, Vol. 664, No. 4, IOP Publish-
ing, p. 042035 (2015).
[8] 高野了成,谷村勇輔,竹房あつ子,広渕崇宏,田中良夫: 高
性能かつスケールアウト可能HPC クラウド AIST Super
Green Cloud ,研究報告ハイパフォーマンスコンピュー
ティングHPCVol. 2014-HPC-145, No. 4, pp. 1–6(オ
ンライン)入手先 http://id.nii.ac.jp/1001/00102255/
(2014).
[9] 谷村勇輔,浜西貴宏,高野了成,田中良夫: AIST Super
Green Cloud におけるストレージシステムの構築と運用,
研究報告ハイパフォーマンスコンピューティングHPC
Vol. 2015-HPC-148, No. 30, pp. 1–6(オンライン),入手
http://id.nii.ac.jp/1001/00113235/(2015).
[10] Lamanna, M.: Large-scale data services for science:
Present and future challenges, Physics of Particles and
Nuclei Letters, Vol. 13, No. 5, pp. 676–680 (2016).
[11] Hat, R.: Why Spark on Ceph? (Part 1 of 3).
[12] Mrowczynski, P.: Scaling cloud-native Apache Spark
on Kubernetes for workloads in external storages, PhD
Thesis (2018).
[13] James S. Plank : Erasure Codes for Storage Systems: A
Brief Primer | USENIX , pp. 44 – 50 (online), available
from https://www.usenix.org/publications/login/
december-2013-volume-38-number-6/erasure-codes-
storage-systems-brief-primer(2013).
[14] Arafa, Y., Barai, A., Zheng, M. and Badawy, A.-H. A.:
Evaluating the Fault Tolerance Performance of HDFS
and Ceph , Proceedings of the Practice and Experience on
Advanced Research Computing - PEARC ’18, New York,
New York, USA, ACM Press, pp. 1–3 (online), DOI:
10.1145/3219104.3229269 (2018).
[15] Zaharia, M., Chowdhury, M., Franklin, M. J.
and Shenker, S.: Spark: Cluster Computing
with Working Sets , (online), available from
https://www.usenix.org/conference/hotcloud-
10/spark-cluster-computing-working-sets.
[16] Zaharia, M., Chowdhury, M., Das, T., Dave, A.,
Ma, J., McCauly, M., Franklin, M. J., Shenker, S.
and Stoica, I.: Resilient Distributed Datasets:
A Fault-Tolerant Abstraction for In-Memory Clus-
ter Computing , pp. 15–28 (online), available from
https://www.usenix.org/node/162809(2012).
[17] The Apache Software Foundation : Apache SparkTM -
Unified Analytics Engine for Big Data , (online), avail-
able from https://spark.apache.org/.
[18] Google: Cloud Dataproc - クラウド ネイティブな
Apache Hadoop Apache Spark | Cloud Dataproc
| Google Cloud .
[19] Amazon: Amazon EMR での Apache Spark | AWS .
[20] Google: bigdata-interop/gcs at mas-
ter ·GoogleCloudPlatform/bigdata-
interop , (online), available from
https://github.com/GoogleCloudPlatform/bigdata-
interop/tree/master/gcs.
[21] Google: Cloud Storage コネクタ | Cloud Dataproc
キュメン | Google Cloud ンラ ン),入手先
https://cloud.google.com/dataproc/docs/concepts/
connectors/cloud-storage?hl=ja.
[22] The Apache Software Foundation : Apache Hadoop
Amazon Web Services support – Hadoop-AWS module:
Integration with Amazon Web Services.
[23] The Apache Software Foundation :
Hadoop/S3AFileSystem.java at master ·sharvin-
bala/Hadoop.
[24] Ceph : ceph/cephfs-hadoop: cephfs-hadoop, (online),
available from https://github.com/ceph/cephfs-
hadoop.
[25] : gluster/glusterfs-hadoop: GlusterFS plugin for
Hadoop HCFS.
[26] Raghavendra, R., Dewan, P. and Srivatsa, M.: Unify-
ing HDFS and GPFS: Enabling Analytics on Software-
Defined Storage, Proceedings of the 17th Interna-
tional Middleware Conference, Middleware ’16, New
York, NY, USA, ACM, pp. 3:1–3:13 (online), DOI:
10.1145/2988336.2988339 (2016).
[27] 俊輔三上,一樹太田,修見建部:広域分散ファイルシス
テム Gfarm 上での MapReduce を用いた大規模分散デー
タ処理,研究報告ハイパフォーマンスコンピューティン
グ(HPCVol. 2010, No. 4, pp. 1–7(オンライン),入
手先 https://ci.nii.ac.jp/naid/110007995492/(2010).
[28] : Big Data Analytics on Object Storage.
[29] Ceph: ceph/rados-java , (online), available from
https://github.com/ceph/rados-java.
[30] JNA : java-native-access/jna: Java Native Access, (on-
line), available from https://github.com/java-native-
access/jna.
[31] Tange, O. et al.: Gnu parallel-the command-line power
tool, The USENIX Magazine, Vol. 36, No. 1, pp. 42–47
(2011).
8
2019 Information Processing Society of Japan
Vol.2019-HPC-171 No.1
2019/9/20
ResearchGate has not been able to resolve any citations for this publication.
Conference Paper
Full-text available
We have developed Ceph, a distributed file system that provides excellent performance, reliability, and scalability. Ceph maximizes the separation between data and metadata management by replacing allocation tables with a pseudo-random data distribution function (CRUSH) designed for heterogeneous and dynamic clusters of unreliable object storage devices (OSDs). We leverage device intelligence by distributing data replication, failure detection and recovery to semi-autonomous OSDs running a specialized local object file system. A dynamic distributed metadata cluster provides extremely efficient metadata management and seamlessly adapts to a wide range of general purpose and scientific computing file system workloads. Performance measurements under a variety of workloads show that Ceph has excellent I/O performance and scalable metadata management, supporting more than 250,000 metadata operations per second.
Conference Paper
Large-scale distributed systems are a collection of loosely coupled computers interconnected by a communication network. They are now an integral part of everyday life with the development of large web applications, social networks, peer-to-peer systems, wireless sensor networks and many more. Because each disk by itself is prone to failure, one key challenge in designing such systems is their ability to tolerate faults. Hence, fault tolerance mechanisms such as replication are widely used to provide data availability at all times. On the other hand, many systems now are increasingly supporting new mechanism called erasure coding (EC), claiming that using EC provides high reliability at lower storage cost than replication. However, this comes at the cost of performance. Our goal in this paper is to compare the performance and storage requirements of these two data reliability techniques for two open source systems: HDFS and Ceph especially that the Apache Software Foundation had released a new version of Hadoop, Apache Hadoop 3.0.0, which now supports EC. In addition, with the Firefly release (May 2014) Ceph added support for EC as well. We tested replication vs. EC in both systems using several benchmarks shipped with these systems. Results show that there are trade-offs between replication and EC in terms of performance and storage requirements.
Conference Paper
Distributed file systems built for Big Data Analytics and cluster file systems built for traditional applications have very different functionality requirements, resulting in separate storage silos. In enterprises, there is often the need to run analytics on data generated by traditional applications that is stored on cluster file systems. The absence of a single data store that can serve both classes of applications leads to data duplication and hence, increased storage costs, along with the cost of moving data between the two kinds of file systems. It is difficult to unify these two classes of file systems since the classes of applications that use them have very different requirements, in terms of performance, data layout, consistency and fault tolerance. In this paper, we look at the design differences of two file systems, IBM's GPFS [1] and the open source Hadoop's Distributed File System (HDFS) [2] and propose a way to reconcile these design differences. We design and implement a shim layer over GPFS that can be used by analytical applications to efficiently access data stored in GPFS. Through our evaluation, we provide quantitative results that show that our system performs at par with with HDFS, for most Big Data applications while retaining all the guarantees provided by traditional cluster file systems.
Article
I discuss some directions for evolving our data management services in the next years, using the experience in operating heavy-duty data storage services at CERN, notably for the Worldwide LHC Computing Grid (WLCG). These new developments are potentially useful beyond our community, wherever the success of a project depends on large computing resources and requires the active participation of a large and distributed collaborations.
  • L Mascetti
  • E Cano
  • B Chan
  • X Espinal
  • A Fiorot
  • H G Labrador
  • J Iven
  • M Lamanna
  • G L Presti
  • J Mó S Cicki
Mascetti, L., Cano, E., Chan, B., Espinal, X., Fiorot, A., Labrador, H. G. a. l., Iven, J., Lamanna, M., Presti, G. L., Mó s cicki, J. et al.: Disk storage at CERN, Journal of Physics: Conference Series, Vol. 664, No. 4, IOP Publishing, p. 042035 (2015).
Scaling cloud-native Apache Spark on Kubernetes for workloads in external storages
  • P Mrowczynski
Mrowczynski, P.: Scaling cloud-native Apache Spark on Kubernetes for workloads in external storages, PhD Thesis (2018).
  • R Raghavendra
  • P Dewan
  • M Srivatsa
Raghavendra, R., Dewan, P. and Srivatsa, M.: Unifying HDFS and GPFS: Enabling Analytics on SoftwareDefined Storage, Proceedings of the 17th International Middleware Conference, Middleware '16, New York, NY, USA, ACM, pp. 3:1-3:13 (online), DOI: 10.1145/2988336.2988339 (2016).