"global distcloud file system"...

株式会社インテック/大阪大学中川郁夫

March, 2015

March, 2015 © Dripcast Project, Distcloud Project, Osaka University, Intec, Inc. and Ikuo Nakagawa 0


Data ??

クラウド業界ではマルチクラウド/インタークラウドの動きが活発化 ⇒ クラウドの使い分け ?? でも、実はデータ共有が大きな課題

クラウド間でのデータ共有は難しい！！


cloud-2

cloud-4

cloud-1

インタークラウドでのデータ共有の仕組み複数のクラウドサービスの上位に仮想的なストレージ空間を構築！

cloud-3

cloud-5 データは複数拠点に地理分散冗長で保存

DR/BCP への応用も！

どこからアクセスしても共通共有のストレージ空間

にアクセス可能

複数・独立な事業者の既存サービス上に

仮想データ空間を構築

どこからでも、標準の POSIXファイルシステム

として透過的にアクセス可

インタークラウド型透過的ファイルシステムの特徴

※ 国内最大3,000Km, 日米間10,000Km以上の長距離をライブマイグレーションで飛ばせるか !?

March, 2015 4 © Dripcast Project, Distcloud Project, Osaka University, Intec, Inc. and Ikuo Nakagawa

仮想OSの超長距離ライブマイグレーション

日本米国

POSIX is Powerful !! 〜って、もしかして.... 仮想OSを動かして、超長距離で、ライブマイグレーションなんてできるのでは?

本日のメイントピック

Japan Advanced Institute of

Science and Technology Kyoto Univ.


プロジェクト名称: Distcloud Project (代表: 大阪大学教授下條真司)

National Institute of Informatics

Kanazawa Univ.

Hiroshima Univ.

Kochi University of Technology

Kyushu Univ.

National Institute of Information and

Communication Technology

Nara Institute of Science and Technology

Osaka Univ.

Intec, Inc.

Kyushu Institute of Technology

UC San Diego

Object storage

Site-A Site-B Site-Z

サイト間は超高速ネットワーク (JGN-X と SINET4 の両方を活用) を用いてインタークラウド環境を構築 (サイト間遅延は RTT=20~45ms 程度)

NFS GW JGN-X+SINET4 UCSD



parallel & distributed processing

object storage

NFS

POSIX GW on Java tomcat で動作

GW = Relay

外部サイトとのGW http+tomcat で動作

Engine

内部データ処理部 tomcat で動作

Store

データ永続化

S3 / thrift / POSIX

processing engine

多数設置可 VIP for mount point

stateless & DNS round-robin

DHT クラスタ上での Java engine

分散KVSによる scale-out store

外部接続

May, 2014 © Intec, Inc. and Ikuo Nakagawa 9

“POSIX = Native file system” 標準ファイルシステム (via NFS)でランダムアクセスも可能

分散ファイルシステムとしての特徴

“Full Distributed” RDBナシ、SPOFナシ、メタデータまで完全分散のアーキテクチャ

“Global Distribution” マルチサイト (N > 2) かつ All Active、データ配置・移動に特徴

広域分散対応の特徴

“Cluster storage” スケールアウト、冗長構成、フェールオーバ & 自動復旧


スループットを向上させる技術

遅延を吸収する技術

グローバル環境に適した整合性モデル

仮想OSの長距離ライブマイグレーション

広域分散環境における “TCPスループット問題” 対策 ⇒ 多数の並列セッションでスループットを劇的に向上 RTT=300ms の環境でも

常時 1Gbps を達成

“/”

~ikuo/work

~ikuo/tmp /home

~ikuo/bin

遅延を考慮して、動的にメタデータの配置を変更

更新・参照時のメタデータアクセスを

最小化

日米間では 10,000Km 以上 (RTT ~ 150ms) の環境下で仮想OSのライブマイグレーションに成功

POSIXでは “Consistency” は必須！ Distcloud では独自の整合性モデルを採用

“C + (A + P) / 2”

⇒ Region 内 = CA, Region 間 = CP

グローバル広域分散 (地球規模での分散, RTT=300ms) を実現するため実は、いろいろやってます...


Distcloud File System 上でのデータの保存、読み出しは性能に大きく影響 ⇒ データ配置は重要な問題！

データ配置・移動の仕組みが鍵

data

delay? consistency ? performance ?

N = 3 or N > 3 ?


Metadata User data

For Directory entries i-node, attributes, etc.

file (a set of blocks)

Data Small,

w/ concurrent update Large,

write once, read many

Impl. Distributed KVS Blob / Object Storage

Issue latency,

for many small data throughput,

restricted by ACK wait

Restriction Strict Consistency Parallelization

ユーザデータとメタデータで配置アルゴリズムは別々！


並列セッションによるトータルスループットの向上 300ms の遅延環境でもローカルと同程度のI/Oを実現

1GB/s 10MB/s x 100


並列セッションによるトータルスループットの向上 300ms の遅延環境でもローカルと同程度のI/Oを実現

-10

10

30

50

70

90

110

130

150

0 20 50 100 200 300

MB/

s

delay

5GB dd read(m3_AS) READ performance

-10

10

30

50

70

90

110

130

150

0 20 50 100 200 300

MB/

s

delay

5GB dd write(m3_AS) WRITE performance


“/”

~ikuo/work

~ikuo/tmp

/home/ikuo

/home

~ikuo/work/text.log

~ikuo/bin

/home/ikuo

~ikuo/work/text.log

/home

“/”

~ikuo/work

~ikuo/tmp

~ikuo/bin

整合性を確保しながらも、メタデータの再配置を実現メタデータのアクセス時間も最適化可能に！

In concurrent and lock-free / non-blocking model !


メタデータへのアクセスは、当該ノードへの通信を意味する ⇒ ノードが存在する Region が遠いと、当然遅延が発生する

attr-1: value-1 attr-2: value-2



next: object-2 next: object-3

node-1/region-1 (Tokyo)

node-2/region-2 (Seattle)

node-3/region-3 (London)

object-1 object-2 object-3

10ms 140-160ms 200-250ms

Osaka

ノード間に大きな遅延がある場合遅延がリスト探索に影響...


next: object-3

node-2/region-2 (Seattle)

object-2


ノード自身の更新情報を持つ “Link-self” の実装 ⇒ 結果的に lock-free, non-blocking の更新処理を可能にした



next: object-2

node-1/region-1 (Tokyo)

node-3/region-3 (London)

object-1 object-3

(1)   duplicate “object-2”��as “object-a”��

in local site (region-a)

(2) update “object-2”��to set “self: object-a”,��

by CAS operation

self: null self: null


next: object-3

node-a/region-a (Osaka)

object-a

self: null

self: object-a


POSIXファイルシステムは「分散 linked-list」の (複雑な) 集合体よく使うディレクトリのメタデータを「手元に」移動させることで、遅延を低減


etc: object-21

node-t/Tokyo

object-89

self: null

root: object-89

usr: object-38

tmp: object-99


bin: object-71

node-n/NYC

object-38

self: null

lib: object-22

src: object-27


ls: object-13

node-p/Paris

object-71

self: null

sh object-55

test: object-2


length

node-o/Osaka

object-55

self: null

table

⇒ ライブマイグレーションの前後でアクセスに locality... 仮想OSのアクセスでは、メタデータの移動は極めて有効！


整合性を確保しながらも、メタデータの再配置を実現メタデータのアクセス時間も最適化可能に！

0

50

100

150

200

250

300

0 20 40 60 80 100 120

"m3/CREATE-GLOBAL-count-50.data" using 1:2"m3/CREATE-LOCAL-count-50.data" using 1:2

"m3/REMOVE-GLOBAL-count-50.data" using 1:2"m3/REMOVE-LOCAL-count-50.data" using 1:2

delay (one way)

Tim

e [s

ec]

データ移動実装後

REMOVE, 旧モデル


Consistency

Availability Partition Tolerance

CAP定理によると... C + A + P = φ

POSIX では Consistency 必須

もちろん「CAP定理」も考える必要が... ⇒ POSIXなので “Consistency” は必須として “A” と “P” は??


整合性モデルにも一工夫 ⇒ C + (A + P) / 2 intra-region inter-region

C+A

C+P


High Speed Network (JGN-X and SINET4)

by JGN-X

金沢大学 SDSC

(San Diego)

奈良先端大

CSx4

CSx8 ASx1

CSx8

ASx1

SC14 では、国内4大学+1研究機関, 米国1大学を接続太平洋横断環境で Distcloud File System を構成

CSx4

CSx4

広島大学

京都大学

学術情報センター CSx4 ASx1 ASx1


※上記は国内3拠点でのライブマイグレーションの様子


大学間インタークラウドプロジェクト (Distcloud) では既存のクラウドサービスを活用しつつ

地球規模のグローバルデータ基盤を実現する技術を研究中

独自の実装による「透過的広域分散ファイルシステム」の技術により、大陸間に巨大な単一 POSIX ファイルシステムを実現、

仮想OSのライブマイグレーションに成功！

実現にあたっては、技術的なチャレンジも多数.... インタークラウド、データ分散モデル (Metadata, Userdata)、

実践的な整合性モデル “C+(A+P)/2” の採用、etc., etc., etc., ...


とうことで....

協力者、参加者を絶賛募集中 !!

Contact to Ikuo Nakagawa


Thank you !!