目次 - 昨今のストレージにある背景 - ストレージのデザインと要件定義 - Ceph Storageの特徴

1. 昨今のストレージ選定のポイントと
Ceph Storageの特徴
レッドハット株式会社 ソリューションアーキテクト
宇都宮 卓也
2018-08-08

2. 目次
● 昨今のストレージにある背景
● ストレージのデザインと要件定義
● Ceph Storageの特徴
2

3. 昨今のストレージにある背景

4. ストレージは全てのワークロードに関するもの
&
あらゆる形、サイズでデータは生まれる
4

5. Data Explosion
Source: IDC Executive Summary, 2015
医療システム
エンターテインメント
クラウド、Web、モバイル、ソー
シャルメディア
Big Data
非構造化データを生み出す代表的なシステム
IoT, M2M
* 20,000 エクサバイト
= 20,000,000 ペタバイト
= 20,000,000,000 テラバイト5

6. エスカレートするストレージへのニーズ
● Massive scalability
● Easy to expand
● Elasticity
● No more guessing
about future.
あたかも無限にある
ような容量
オンデマンドな拡張 Pay-As-You-Go
● API driven
● On demand rapid
provisioning and
operations.
● Speed and agility
● Unified Management
● Effective Monitoring
and Metering.
● Deeper Integration.
セルフサービス
● Robust User
Interface
● Simplified API
● Multi-tenancy
6

7. SDSが必要とされる背景
● 爆発的に生成される非構造化データ
○ 仮想インスタンス、テキスト、画像 /音声/動画、ログ、センサデータ、 etc…
● 予測できないデータの増減
○ 一日に数百GB〜数TBの単位でどんどん増加するサービス
○ 一方でほとんど増えないサービスも
→ 5年後の容量増加を見越して、最初に大きくストレージ調達するのはハイリスク
○ 容量不足、性能不足
○ 過剰投資
スモールスタート
- 初期投資を最小限に
- クイックスタート
- サービスをやめる時の衝撃を低減
容易で高い拡張性
- 想定外のデータ増加に簡単に対応
- サービス無停止
- 同じ方法で都度拡張可能
SDS
7

8. (参考) 国内のSDS市場
8
インフラ全体の平均支出の縮小 (-2.8%) に対し、
SDS(+28.2%), Hyperconverged(+20.6%)
の高い成長率

9. ストレージのデザインと要件定義

10. ストレージの設計
TARGET
STORAGE
ARCHITECTURE
データ保護の方式?
障害時のリスク管理?
必要な容量 ? ストレージのアクセス方式?
ワークロードのI/Oプロ
ファイル ?
Scale-Out型ストレージが
必要 ?
10

11. ストレージの設計
TARGET
STORAGE
ARCHITECTURE
データ保護の方式?
- データ冗長化
障害時のリスク管理?
- 現行I/Oへの影響度合い
- リカバリの時間
必要な容量 ?
- 最終的にどれだけ必要か
ストレージのアクセス方式?
- Block / File (NAS) / Object
- 利用するシステム、アプリに依存
ワークロードのI/Oプロ
ファイル ?
- random / sequential
- IOPS / Throughput
Scale-Out型ストレージが
必要 ?
- 将来的なリソース計画
11

12. ワークロードを把握する
容量
スループット
IOPS
I/Oパターン
I/Oサイズ
I/O
レイテンシ
アクセス
プロトコル
Read/Write比
12

13. その他の要素
BCP
災害対策
バックアップ /
レプリケーション
コスト
コモディティHW
管理インター
フェース
モニタリング
ハイパーコンバージド
運用性 先進的な機能
シンプロビジョニング
重複排除 / 圧縮
STORAGE
13

14. ストレージ要件の定義
● システムの移行、更改の場合
○ 既存システムのストレージ利用状況をベースに予測できる
● 新規システムの場合
○ 稼働する仮想マシンやアプリが既知ならば、アプリの要件からある程度は予測できる
○ 未知ならば、予測は難しい
■ どんなワークロードが乗っても対応できるよう想定するには、ハイスペックなストレー
ジが必要。高コスト。
■ IaaSなどではSLAで条件を提示することが一般的
→ いずれにせよ、
● システムの利用状況を想定し、できるだけシュアな要件の姿を形作る
● 本番想定のPoCを実施し、実践的な要件を隅々まで調査する
ことが、失敗しないために必要
14

15. 要件を定義しにくい時代のストレージ
● 予測できないワークロードを迎え撃つストレージに必要なこと
スモールスタート
- 小さな初期投資
- クイックスタート
最適解 = SDS
15
容易な追加拡張
- サービス無停止
- 同じ手順で何度でも追加可能
高いスケーラビリティ
- ほぼ無限に思われる容量拡張
- ボトルネックになりやすいCPU, メモリ,
NW等のリソースも拡張

16. Ceph Storageの特徴

17. Cephの概要
● オープンソースのユニファイドストレージ
○ Block, File, Objectの全てで利用可能
● Scale-Out型の分散アーキテクチャ
○ 1,000+ノードのスケーラビリティ
○ 無停止&最小限の負荷で行うノード追加
● OpenStackとの統合に極めて優れる
○ 単独でCinder, Glance, Nova, Keystone, Swift,
Manilaのストレージとして稼働可能
● 最適なデータの分散配置を自動で実現
○ RADOSオブジェクトストア
○ CRUSHアルゴリズム
CEPH BLOCK DEVICE
(RBD)
CEPH OBJECT
GATEWAY (RGW)
OPENSTACK
Keystone API Swift API
Cinder
API
Glance API
Nova
API
Hypervisor
CEPH CLUSTER
Manila API
CEPHFS
17

18. OpenStackで使われるストレージ
IaaS+
IaaS
TELEMETRY ORCHESTRATION
CEILOMETER SAHARA HEAT
DATA
PROCESSING
COMPUTE
NOVA
NETWORKING
NEUTRON IRONICCINDER GLANCE SWIFT
STORAGE
BLOCK IMAGE OBJECT
BARE-METAL
PROVISIONING
HORIZON TRIPLEO
DASHBOARD
SHARED SERVICES
IDENTITY
KEYSTONE
DIRECTOR
DEPLOYMENT
and
MANAGEMENT
MANILA
SHARED
FILESYSTEM
主に、Nova, Cinder, Glance, Swift, Manila...etc.
18

19. SCALE ENCRYPTION RE-BALANCING SNAPSHOTS REPLICATION CRUSH
RED HAT
SUPPORT
ONLINE
UPGRADES
STORAGE
CONSOLE
Ceph FS - 53%
Ceph RBD - 65%
CONTAINERIZED
CEPH
HYPER
CONVERGENCE
Red Hat Ceph Storageの特徴と機能
19

20. OpenStack環境で標準的に利用されるCeph
* April 2017 OpenStack User Survey : https://www.openstack.org/assets/survey/April2017SurveyReport.pdf
Which OpenStack block storage (Cinder) drivers are in use? Which OpenStack Shared File Systems (Manila) driver(s) are you using ?
20

21. node2node1 node3 node4 node5 node6node3node1
Cephのデータ冗長性の担保
data
node2
datadata data
Replication
- データを複製して冗長化
- 容量効率は低いがI/O性能とリカバリの早さはECより優
れる。一般的によく利用される標準のタイプ
- RBDではこのタイプのみサポート
data
A
Erasure Coding (EC)
- データを分割し計算によってパリティを作成する、
RAID5, 6に似た仕組みで冗長化
- I/O性能とリカバリはReplicationに劣るが容量効率は高
い。厳しい性能要件のない大容量用途向け
- RGWでのみサポート、RBDでは未サポート
B C X Y
coded codeddata data data
D
data
21

22. (参考)2つのタイプの比較
Replication
*Nは多重度(レプリカの数 )
Erasure Coding
*K, Mはそれぞれ data chunk, coded chunkの数
サポートされる構成 ● SSD : N >= 2
● HDD : N >= 3
*https://access.redhat.com/articles/1548993
● K+M : 8+3, 8+4, 4+2
● (K+M+1)台以上のOSDノード
● RGW利用のみ
*https://access.redhat.com/articles/1548993
耐障害性
(データロスしない OSD障害の限界 )
(N-1)個まで M個まで
容量効率
(物理容量に対する実効容量の割合 )
1 / N
- 例: 3x replicationの場合は1/3
K / (K+M)
- 例: 4+2構成の場合は4/(4+2)=2/3
I/Oパフォーマンス *
OSD障害時のリカバリー *
主な利用用途 デフォルトのPoolタイプで、一般的にどのような用途にも適
する
性能より容量を重視するオブジェクトストレージに適する
速 遅
速 遅
* 一般的な傾向としての比較であり、実際の速度は環境に依存する
低 高
22

23. Ceph OSD Ceph OSD Ceph OSD
OS OS journal OS OS journal OS OS journal
osd osd osd osd osd osd osd osd osd osd osd osd osd osd osd
: 480GB SSD
: 1.92TB SSD
Replicationの多重度の選択
3x Replication 2x Replication
実効容量 物理容量の 1/3
上図の構成であれば 1.92TB x 5本 x 3ノード x 1/3 = 9.6TB
物理容量の 1/2
上図の構成であれば 1.92TB x 5本 x 3ノード x 1/2 = 14.4TB
データロスしないOSD
同時障害の限界
2ドライブ
RAID6と同レベル
1ドライブ
RAID5と同レベル
I/Oパフォーマンス Readはどちらも同じ。Writeは2x Replicationが優れる。
(Cephのwriteは完全同期書き込みで、3xでは3ドライブに対して同期が必要だが、2xでは2ドライブで済むため)
しかし、高Write負荷環境でない限り体感できる程の差異は出ないと思われる
備考 容量効率は良くないが、ドライブ障害時のデータロスのリスクが低い 容量効率は良いが、1ドライブ障害時にリカバリ完了までにもう1ドライ
ブ障害が起きるとデータロスとなり、リスクが高い
23

24. (参考)ドライブ障害時のリカバリ動作
● Cephは従来型ストレージ装置が持つスペアドライブの概念がない
● ドライブ故障等でOSDのDownを検知すると、そのOSDが持っていたデータを他の OSDに分散してリ
カバリーする
● 複数のドライブで並列してリカバリー処理を行うため、従来型ストレージの 1本のスペアドライブでの
みリカバリーする方法よりも早くリカバリーが終わる
● ノード全体がDownした場合は、そのノードの全 OSDがDownしたとみなされ、同様にリカバリーが行
われる
node3node1 node2
osd.0
osd.1
osd.2
osd.3
osd.4
osd.5
osd.6
osd.7
osd.8
1 1
2
2
2
3
3
4
4
5
5
56 6
7 7
node4
osd.9
osd.10
osd.11
1
3
4
6
7
node3node1 node2
osd.0
osd.1
osd.2
osd.3
osd.4
osd.5
osd.6
osd.7
osd.8
1 1
2
2
2
3
3
4
4
5
5
56 6
7 7
node4
osd.9
osd.10
osd.11
1
3
4
6
7
X : データ
(例) 4 OSD ノードの Ceph クラスタ、3x replication 構成
8
8
8
8
8
osd.0
Down
8DOWN 8
1 5
node 1のosd.0がDownした場合、osd.1が持っていたデータは他の OSDから並列して再
作成(コピー)され、冗長性が保たれるようにリカバリーされる
24

25. Thank you