しすなま！ 第31回「今アツい、分散ストレージを語ろう」

本日のパネリスト

織 学（Manabu Ori)Linux/OSS Cloud サポートセンター

2

石川 公基ＩＳＥ．仮想インフラ・ソリューション

早川 哲郎（Tetsuro Hayakawa）

System xエバンジェリスト

半田 達郎System x事業部．テクニカル・セールス

New

New

New

今日のお題

今アツい、分散ストレージを語ろう

3

なぜ分散ストレージなのか？

4

近のサーバーは大量ストレージが搭載可能になっている

3.5型 SSD/HDD x 14本HDD 4TB x 14 = 56TBSSD 800GB x 14 = 11.2TB

2.5型 SSD/HDD x 26本HDD 1.2TB x 26 = 31.2TBSSD 1.6TB x 26 = 41.6TB

これらのサーバーの用途は何なのか？

2.5型 SSD/HDD x 32本HDD 1.2TB x 32 = 38.4TBSSD 1.6TB x 26 = 51.2TB

5

内蔵ストレージが多く必要なシステムで使われる

IAサーバーに大量のストレージが搭載できる背景には、IAサーバーがストレージシステムとして使用し始められている

ディスクI/O負荷を分散

サーバー負荷を分散

いままではここの部分は専用ストレージ（アプライアンス）で構成されることが多かった。

しかし、サーバー性能の向上とソフトウェア技術の進展により、安価なIAサーバーで構成することができるようになってきた

要は分散ストレージをIAサーバー上で使うことが

増えてきたということになる

要は分散ストレージをIAサーバー上で使うことが

増えてきたということになる6

OSSによる分散ストレージ

7

NoSQLコミュニティ

8

NoSQLコミュニティ

9

分散ストレージとは

ディスクI/O負荷を分散

サーバー負荷を分散NFSサーバが

ボトルネックに

ディスクI/Oも

集中する

10

構成要素

• x86サーバー

• ストレージ

– サーバーの内蔵ディスクを使用

– SAN, iSCSI等で接続する外部ストレージは使われない

– RAIDを構成せず、JBODで使う場合も多い

– SSD, PCIe型NAND Flashを使う場合もあるが、多くの場合は容量単価重視でSATA HDD

• ネットワーク

– 1GbE, 10GbE, InfiniBand

• ソフトウェア (ミドルウェア)

– 死活監視、データの複製、障害時の自動修正等は全てこの層で自動で行われる

11

ソフトウェアの動き(1)

ひとつデータは複数ノードに多重に配置–ノードに障害が発生してもデータロストしない

ノード障害の場合は、自動的に縮退

ノードを追加した場合、自動的に容量増大–データ再配置/リバランシングも(半)自動

ブロック分散型

ファイル分散型

1ファイルへのアクセス速度重視

全体での合計速度重視

12

ソフトウェアの動き(2)

データ位置の取得方式の違い

–カタログ型•誰かが位置を管理

•SPOFやボトルネックになりやすい

•整合性は保持しやすい

–P2P型

•計算により一意に定まる何がしかの仕組みを利用

•速度やスケーラビリティの面で有利

•ノードの動的追加・削除には弱い場合もある

Hash!

here

here

Where?

here

here

13

運用イメージ

「壊れたら 直さず 取り替える」

–データは必ず複製がどこかに保持されているので運用を単純化して膨大な数のサーバやHDDの管理コストを下げる

•例) 壊れてもバックアップから戻したりしない

障害発生のHWを切離して、まっさらな新規HWを追加する

壊れてもすぐ取り替えない

内蔵 HDD 12本のうち、半分が壊れるまで放置

壊れたらサーバごと切り離す

壊れたら壊れっぱなし

ラック内の稼働率を見てラック単位でリプレース

データは同じところに再複製する or 別のところに再配置する

14

RAIDとホットスワップ

• RAIDが必要かどうかは、使うソフトウェアによる

– RAIDを構成した方がいい場合

•トランザクションのスループットとして、HDD 1個分以上のスループットを出したいとき

•例： GlusterFS

– JBODでも大丈夫な場合

•HDD 1個分程度のスループットでいいとき

•複数HDDに並列アクセスするようなワークロードのミドルウェア

•例： HDFS, Swift

• ホットスワップが必要かどうか

– HDD交換時はノード停止が伴う ⇔ ノード停止のインパクトがどの程度か？

–基本的に、どのソフトウェアを使っても「全同期やり直し」が発生

– RAIDを構成する場合はホットスワップの方がよさそう

– JBODの場合はお客様要件による

15

分散ストレージソフトウェアの種類

種別POSIX互換性

メタデータ管理 分散単位 開発元 API

GlusterFS ファイルシステムあり(不完全)

メタデータ管理ノードなし ファイル Red Hat POSIX, REST, HDFS, Swift

Ceph ファイルシステム あり メタデータ管理ノードあり ブロック Inktank Native, POSIX, REST, Swift

(GPFS) ファイルシステム あり メタデータ管理ノードなし ブロック IBM POSIX, HDFS (GPFS FPO)

HDFS ファイルシステム なし メタデータ管理ノードあり ブロック Apache Native

(Google File System) ファイルシステム なし メタデータ管理ノードあり ブロック Google Native

Swift オブジェクトストレージ - メタデータ管理ノードあり ファイルOpenStack Foundation

REST

(Amazon S3) オブジェクトストレージ - P2P型？ ？ Amazon Web Services REST

Cassandra NoSQL - P2P型 - Apache Native, REST

HBase NoSQL - P2P型 - Apache Native

MongoDB NoSQL - P2P型 - 10gen Native, REST, HDFS

Redis NoSQL - P2P型 - Pivotal Native, REST

Riak NoSQL - P2P型 - Basho Native, REST(Riak CS)

(Google BigTable) NoSQL - 集中管理型？ - Google Native

(Amazon DynamoDB)

NoSQL - P2P型？ - Amazon REST

16

商用製品による分散ストレージ〜 ファイルシステム 〜

17

GPFS (General Parallel File System)

約20年の実績のある並列ファイルシステム

– データはストライプ分散が基本

– ディスクはRAID構成・共有が基本

高い可用性

– Active-Active構成の分散コンポーネントにより構成

– HAクラスタソフト不要で可用性を保持

•GPFS 自身のコンポーネントは冗長化機能を提供

•NFSクライアントに対してはClustered NFS 機能を提供

– 対ディスク障害を想定する場合は、GPFSレベルでレプリカの作成が可能

スナップショット機能の活用

– ファイルシステム状態の版管理

App. App. App. App.

App. App. App. App.

対ディスク装置障害用にブロックレプリカ作成も可能

クライアントはGPFSNative プロトコルかNFSプロトコルでアクセス

フェイルオーバーが十全に行えるようなサーバのペアリングや設定は必要です

GPFS

GPFSor

NFS

GPFS snapshot

3月31日時点 4月1日時点

全コンポーネントがHA構成

個別のクラスタソフトは不要

シングルイメージ

18

GPFS-FPO (File Placement Optimizer)

GPFSシングルイメージ

GPFSの拡張版

– シェアードナッシング構成

•データ保護はレプリカが基本

従来のGPFSの特長はそのまま

– Active-Active構成の分散コンポーネントにより構成

– HAクラスタソフト不要で可用性を保持

– スナップショット機能の活用

シェアードナッシング構成向けの拡張

– レプリカ作成数の上限拡大 (2 -> 3)

– レプリカ配置アルゴリズムの拡張

– パイプライン・レプリケーション

– データローカリティ対応用の拡張

App. App.App. App. App.

19

OSSによる分散ストレージ〜 ファイルシステム 〜

20

Lustre

HPCで事例の多いファイルシステム

非対称型分散構成

– メタデータとデータを分離

– データノードのスケールアウトが容易

App. App. App. App.

App. App. App. App.

クライアントはNative プロトコルアクセス

フェイルオーバーが十全に行えるようなサーバのペアリングや設定は必要です

LustreProtocol

LustreFSシングルイメージ

メタデータサーバ(MDS)

データ格納サーバ(OSS)

21

GlusterFS

複数ノードのファイルシステムをまとめて仮想的な大きいファイルシステムとして提供

ファイル単位で分散配置

ファイルの配置は、専用ハッシュ関数を通してパス名から算出

– クライアント側の演算のみで判明

レプリカ数、ストライプ数は設定で変更可能

OpenStackとの連携

– Cinder driver

– Swift API

Red Hat社がRed Hat Storageとして商

用サポート

ノード1 ノード2 ノード3

ブリック ブリック ブリック

ボリューム

クライアント

ファイルA

ファイルA

ファイルA

レプリケーションボリュームレプリケーションボリューム

ノード1 ノード2 ノード3

ブリック ブリック ブリック

ボリューム

クライアント

ストライプボリュームストライプボリューム

22

Ceph

独自のオブジェクトストレージRADOSに対して

様々なアクセス方法を提供– POSIX API (MDS)

•クライアントコードはLinuxカーネルに統合ずみ

– 専用ネイティブAPI (librados)

– S3互換API (RADOS Gateway)

– ブロックデバイス (RBD)

– OpenStack Swift API

ファイルシステムのメタデータは専用のメタデータサーバで管理

– サブディレクトリごとにメタデータサーバをわけて負荷分散することが可能

スナップショット

レプリケーション

ストライプ

http://ceph.comより引用23

HDFS

普通の階層型ファイルシステム

フォールトトレラント– ハードウエアは信頼できないのでソフトウエ

ア設計でカバー

データスループット志向– レイテンシーはちょっと犠牲– POSIX互換も気にしない

巨大で大量なデータを扱う– 1000万ファイル以上

– GigabyteからTerabyte単位のファイル

Write once, NO Change．

– データ整合性の課題を回避– Appendはサポートしたい意向

“Moving Computation is Cheaper than Moving Data”

– データのあるところにアプリケーションを貼り付けることを容易にするためのAPIを提供する

まずは量次に複雑性安全 後

（でもちょっとほしい）

24

Google File System (GFS)

x86サーバで構築した分散ファイルシステム

「x86サーバは壊れる」という前提で設計

– 壊れてもデータが失われない、自動的に復旧できる、ことを主眼に開発

ファイルは64MBのチャンクに分割されて、3台の異なるノードに保存

基本的に追記および読み出しを中心に想定

1台+αのマスターノード、複数のチャンクサーバ

25

26

OSSによる分散ストレージ〜 オブジェクトストレージ 〜

Swift

オブジェクト・ストレージのサービス (Amazon S3相当)

HTTP (REST API) でアクセスするファイルサーバー

Glanceと連携して、仮想マシンのイメージ置き場としても使用可能

構成要素

– ストレージノード

•オブジェクトを保持する

– プロキシーノード

•ストレージノードに振り分ける

•プロキシーノードへの振り分けはDNSラウンドロビンやロードバランサーを使用

高い可用性、自己修復機能

– RAID不要

– デフォルトで３つの複製を作成し、異なるストレージノードに配置

– データ破損や消失を自動的に検知して修復

– 内部ではrsyncを使っている

容易にスケールアウト、容量増加が可能

ClientHTTP HTTP

Swift

StorageNode

StorageNode

StorageNode

StorageNodeProxy

NodeProxyNode

ProxyNode

27

Amazon S3

AWS主力サービスのひとつ

2006年より利用開始

“Webスケール”なコンピューティングを

想定した特徴–高いスケーラビリティ

–高い信頼性・堅牢性

–セキュア

–高速

–低価格

シンプルなAPI– PUT/GET/DELETE/LIST

28

OSSによる分散ストレージ〜 KVS 〜

29

NoSQLに至る背景 – 原点はmemcached

データ層のスケーラビリティ確保に課題

– 大規模なWeb系システムにおいて徐々に問題として顕在化

解決策のひとつとしてMySQLのレプリ (+ memcached)

– マスタ + マルチスレーブで負荷分散というアイディアが広まる

解決が困難だった点

– 極端にライトに負荷がかかる場合

•マスタへのライトがボトルネックになる

– マルチマスタにする場合

•データ同期の問題

– シャーディングする場合

•アプリケーションのメンテナンス・コスト増大や可用性

•フレームワークでクッションする場合はフレームワークのメンテナンスが課題になる

– リード負荷分散でデータ整合性の制御が困難

•MySQLのレプリ任せ + 負荷分散装置のロジックに依存

•データの扱いについては 終的にアプリケーションでの判別ロジックに負荷

LoadBalancer

Sharding by App

RDBMSほど高機能でなくてもいいので 初から速度やスケーラビリティを重視して

アプリ側の負担を軽くする分散型データ・ミドルウェアを新規開発する、という風潮が生まれる

Master

30

NoSQL

NoSQL = Not only SQL– SQL = RDBMS

ファイルシステムとRDBMSの中間的存在– ファイルシステムより機能豊富

•(NoSQLは)後からデータを取り出す”キー”を決めて使う （データベースっぽい点）

•一部だけデータを取出したり更新したり加工したりするのが〔ファイルより）速くて便利

– RDBMSほど高機能でない・信頼性はない•NoSQLは（フル・スペックの）SQLが使えない

SQLっぽい方式でデータの出し入れが可能なことはある

•NoSQLはお金の出し入れなど重要なトランザクション処理を間違えない…とは限らない間違わせないようにするにはアプリケーションで工夫が必要

– RDBMSより（だいたい）動作速度が高速•もしくは速度以外の点で RDBMS を凌駕する性質を持つ

利用例– Webサイトの裏側でよく読まれる情報（キャッシュ）

•小さい画像、ユーザの属性情報

– Webサイトの裏側で頻繁に更新される細かいデータ•細かい行動履歴(足あと）

– RDBMSに挿す前のトランザクション・データ•ショッピングカートの中身

31

Logical Ring

Topology

token

token

token

token

token

token

token

token

Apache Cassandra

読込みも得意（高速）だが書込みがもっと得意（高速）なNoSQLデータを広く分散させるように使いやすい

– ひとつひとつのレコードに素早くアクセスすることに特化

– 連続したデータを集めて、集計する用途には向いていない

稼動継続性が高い– 常にデータが読める・書けるが、 新

データとは限らない

著名な利用事例– Facebook– ebay

メモリ内データ

Cassandra Server

先行書込みログ 永続化ファイル

Hash!

here

here

32

Apache HBase

ユーザからは表のように扱えるNoSQLの一種Hadoopと組合せると超巨大なExcelワークシートとして使える

– 集計関数などは、Hadoopのほかの仕組みでプログラミングする

– Hadoop HDFS の上で稼動する

半ばインメモリデータベースのようにして使っている例も多い

著名な利用例– Twitter– Facebook– LINE

– IBM Smart(er) Cloud Provisioning

User Application

HTable

HDFS

HMaster

HSlaves(HRegionServers)

33

10gen MongoDB

NoSQLの中では比較的汎用性が高いデータの表現形式がJSON

– 操作体系的には、JavaScriptアプリケーション(AJAXやサーバーサイドJS)との相性がよいので、Web企業に受けがよい

•JS以外の言語からでも当然使える

RDBMSから転換しやすい– パっと見RDBMSっぽくないものの

RDBMSのノウハウや概念も通用する部分があるのでスキル移行しやすい

•テーブルやレコードに近似する概念あり•検索を高速化するためのインデックス•インデックスのメリ/デメのトレードオフ

地理情報演算用の関数組込みなど時流にそった機能拡張もある

•ある地点から周囲 X kmの範囲のオブジェクト（店とか）を抽出する、など

著名な利用例– CyberAgent Ameba– 楽天– …etc.

db.unicorns.find({gender: 'f', $or: [{loves: 'apple'},{loves: 'orange'},{weight: {$lt: 500}}]})

db.unicorns.insert({name: 'Horny', dob: new Date(1992,2,13,7,47),loves: ['carrot','papaya'], weight: 600,gender: 'm', vampires: 63});

db.unicorns.update({name: 'Roooooodles'}, {weight: 590})

{name: 'Horny', dob: new Date(1992,2,13,7,47),loves: ['carrot','papaya'], weight: 600,gender: 'm', vampires: 63}

JSON形式でのデータ表現例

RDBっぽいクエリ(SELECT/INSERT/UPDATE相当の例)

34

Redis

分散オンメモリ型のデータ構造ストア

– プログラマがよく使うデータ構造と定番操作をそのまま機能としてサポートしている

•ハッシュ、リスト、セットなど

•自分でファイルに書いて管理するよりレプリケーションしてくれたり、サポートされているデータ構造の要素操作のATOMICITYを保証してくれたりするので便

利

– オンメモリ型なので高速

•書込みはバックグラウンドでディスクに書出しされて永続化される

著名な採用事例– Github

– LINE (Hbase移行前)

– Ameba (ランキング)

– ニコニコ動画

35

Basho Riak

Cassandraとほぼ同じような特徴

– どちらもAmazon Dynamo Inspiredだから

後発ゆえ下記のような工夫（もしくはマイルドな要素）が付加– REST API (HTTPによる操作)でのCRUD操作に対応しているので 近のクライアント(JS

の動くブラウザやスマホ)アプリから操作しやすい

– Map/Reduce演算によるアドホックな集計処理の実行に対応

– セカンダリ・インデックス（プライマリ以外の索引）が持てる•二次索引対応のためGoogle Level DB ライブラリをバックエンドで利用

– 全文検索ベースのクエリが打てる

Riac CS (Riak の追加ソフトウェア) を使うとオブジェクトストレージとして利用可能

著名な利用例– Wikia

– Yahoo!

36

(参考) Amazon Dynamo DB

Cassandra, Bashoの元ネタ

2007年に論文公開– Amazon.comが自社のショッピングカートに利用

–理論を論文として公開（ソフトウェアは非公開）

– CassandraやBashoなどのOSSが登場

2012年からAWSでサービス開始

–自社構築をやめるユーザも出てくる可能性あり

37

(参考) Google BigTable

CassandraやHBaseの元ネタ– 2006年に論文発表

•Googleが自社の様々サービスのデータ格納庫として利用

– HbaseなどのOSSが登場

– 2008年にGoogle App Engine のデータ層として

利用可能に

38

Windows / VMwareの分散ストレージ

39

Windows ／ VMwareの 近のストレージ機能拡張

Windows Server 2012 / 2012 R2–ファイルサーバー、ストレージ関連で大幅な機能拡張

vSphere 5.5–SSD活用とストレージ仮想化機能の強化

•Virtual SAN：分散共有型データストア

•Flash Read Cache：SSDを活用したディスクアクセス高速化

iSCSI NFSSMB3.0

CIFS

New!

スケールアウトファイルサーバー New!

NTFS ReFS重複除去

New! New!

記憶域プール•階層化ストレージ•Write Back Cache

New!

SSD HDD HDD

ディスク管理

•記憶域プール：物理ディスクのプール化

•(R2~)階層化ストレージ、SSD Write Back Cache

ストレージサービス

•SMB3.0：マルチチャンネル、透過的フェイルオーバー、暗号化、帯域制御…

•スケールアウトファイルサーバー（SOFS）

ファイルシステム

•NTFS重複排除：オンラインVHDX対応（VDIのみ）

•ReFS：耐久性・拡張性に優れた新ファイルシステム

40

スケールアウト・ファイルサーバー（SOFS）

Microsoft Windows Server 2012より追加されたファイルサーバーのクラスタリング方式

Windows の共有フォルダを複数のファイルサーバーホストで分散して提供する

フェイルオーバー発生時も（ほぼ）停止なし

ファイルサーバーのアクティブ-アクティブクラスター

特徴

• ファイルサーバーのアクティブ-アクティブクラスター（WSFCを使用）

• 大8ノードまで構成可能

• SMBの透過的フェイルオーバーをサポート

• Hyper-V、SQL Serverなどのアプリケーション・

ワークロードに 適化

• 共有ディスク領域にCSVを使用

• 負荷の自動リバランスなども可能(R2から)Cluster Shared Volume

File Serverアクティブ

File Serverアクティブ

Hyper-V

VM VM

Hyper-V

VM VM

SOFS（¥¥SOFS¥share）

41

Hyper-V over SMB with SOFS

SOFSの使用例：Hyper-V基盤の共有ストレージ– Hyper-V仮想マシンファイルをSOFS共有フォルダ上に配置する– ファイル共有プロトコル SMB3.0で構成すればSANのスキル不要– 規模に応じてHyper-Vホスト、ファイルサーバーを個別にスケールアウト

Hyper-V ホスト• WSFCクラスターを構成

ファイルサーバー（冗長構成）• SOFSでHyper-Vのワークロードを負荷分散

• 共有ストレージ上にCSVを配置

WSFC（Hyper-Vクラスター）

WSFC（SOFS）

ファイル共有プロトコル（SMB3.0）

ネットワーク構成• 10Gb EthernetまたはInfinibandを推奨• SMB DirectやSMBマルチチャンネル

を活用

ゲストOS ゲストOS

Hyper-V

ゲストOS ゲストOS

Hyper-V

ゲストOS ゲストOS

Hyper-V

42

Virtual SAN（VSAN）

VMware ESXiのローカルディスクを共有ストレージとして使用

VMware ESXi

VMware ESXi

VMware ESXi

VSAN (分散共有ストレージ)

vSphere 5.5で追加された共有ストレージ構成。現在パブリックベータとしてVMware社より提供されている

サーバーハードウェア内蔵のSSDとHDDを利用して共有ストレージを構成する

ポリシーベースでのデータ管理を行う（次ページ）

特徴

• 使用可能な実用量はHDD領域の合計容量

• SSDはキャッシュ領域として使用される

• ホスト間はVSAN専用のネットワーク構成が必

要10Gbネットワークでの構成を推奨

• 3ノード～8ノードの構成をサポート

• オブジェクトに対するポリシー設定により、データのレプリカ数・ストライプ数を柔軟に設定できる

vSphereクラスター

vSAN Datastore

43

VSAN Data Store

VSANでのストレージポリシーの適用

VMware ESXiVMware ESXi VMware ESXi

VM

•仮想マシンの作成

VMware ESXi

データ

データ

•データ書込が発生

•ポリシーに応じたデータ処理※実際の処理はデータのオーナーとなるESXiホストが実行

データ データ

レプリカ

1 2 1 2 ストライプ

1 2 1 21 12 2

•SSDに書込処理を実行•SSDから適宜HDDにデステージ

許容障害台数（レプリカ数）=1ストライプ数=2

•VMDKファイルに定義済のポリシーを設定

44

まとめ

内蔵ストレージを活用するための多くのソリューションがはやって（はやり始めて）いる

近はサーバーに内蔵できるストレージの本数、容量ともに増えてきている

新しい流れをうまく活用し、ビジネスイシューの解決に役立てることができる

45

次回 しすなま!第32回のご案内

【日時】

–2013年12月19日(木) 18:00-19:30 (約90分)

【テーマ】

–クリスマス特集

–年末恒例 ネットワークの 新動向

【出演】

–パネラー：今年もサンタクロース登場か？

46

乞うご期待

ご清聴ありがとうございました