技術情報

技術情報

Ceph/RADOS の OpenStack 利用
第1回 OpenStack 環境向けストレージ構成の性能比較例

2015年4月13日
技術本部 クラウド基盤エキスパート 佐藤友昭

技術文書トップへ

Ceph/RADOS を OpenStack のストレージインフラとして利用する場合の構成例と性能比較例を解説します。

本稿は、@IT外部リンク で連載している『Ceph/RADOS 入門』 の内容を踏まえた解説となります。@IT での連載記事は、以下を参照ください。

なお、@IT 連載記事および本稿執筆時の Ceph のバージョンは Emperor です。Ceph/RADOS のファイルシステムインターフェース (CephFS) については Emperor バージョンではバグ修正等が続いており、プロダクション環境には推奨しない旨が Ceph Documentation に記載されていました。

2015年4月にリリースされた最新バージョン Hammer での CephFS の利用については、プロダクション環境での使用は可能なものの、'fsck' チェックと修復機能が十分ではなく、ディザスタリカバリツールも開発中であることから、重要なデータを保存する際には注意する旨が記載外部リンクされています。

ページトップ

Shared storage-based live migration 用途のストレージ構成の比較

Nova の共有ストレージ方式に関する比較です。

shared storage-based のライブマイグレーションを行う前提で、/var/lib/nova/instances ディレクトリの構成方法として次のパターンを比較します。

なお、本稿は同じ条件下での NFSv4 とその他の方式の比較を目的としているので、測定環境のサーバやネットワークに関するスペックを記載していません。

【ディレクトリの構成パターン】

ページトップ

OpenStack におけるライブマイグレーションの整理

まず、OpenStack におけるライブマイグレーションについて整理します。ライブマイグレーションには、以下の 3 つがあります。

1. Shared storage-based live migration
対象 イメージから起動したインスタンス
CLI nova live-migration <インスタンス> <ホスト>
共有要件 各ホストは /var/lib/nova/instances を共有して「いる」必要がある。
2. Block live migration
対象 イメージから起動したインスタンス
CLI --block-migrate オプションを指定する他は 1. と同じ
共有要件 各ホストは /var/lib/nova/instances を共有して「いない」必要がある。
3. Volume-backed live migration
対象 ボリュームから起動したインスタンス
CLI 1. と同じ
共有要件 各ホストは /var/lib/nova/instances を共有して「いる」「いない」どちらでもよい。
ただし例外はある。NFS や Gluster (FUSE) を Cinder に使用する場合には共有して「いる」必要がある。

1. と 2. はイメージから起動したインスタンスが対象で、3. はボリュームから起動したインスタンスが対象です。
1. と 2. の違いは、各ホストが /var/lib/nova/instance ディレクトリを共有しているかどうかです。共有している場合 1. が、共有していない場合 2. がそれぞれ可能です。

上記のうち今回比較を行うのは 1. の、各ホストが /var/lib/nova/instances ディレクトリを共有している状況でのイメージから起動したインスタンスのライブマイグレーションが可能な各構成です。

ページトップ

比較の目的

比較を行う目的は、まず、

  • 1. iSCSI ボリュームによる /var/lib/nova/instances ディレクトリ共有の現実性を見極める。
そして、現実的でない場合やスケーラビリティが NFS に劣る場合
  • 2. NFS による /var/lib/nova/instances ディレクトリ共有よりもスケーラビリティに優れた共有方法を検討する。
OpenStack ホストの Linuxカーネル変更が必要な方法は不可とします。

1. CLVM を前提とするファイルシステムとしてGFS2 を使用する方式
・ GFS2 は共有クライアント数の上限が低い (Red Hat のサポート範囲は 16 台)
・ スケーラビリティ性能を NFS 方式と比較
2. CLVM を直接使用する方式
・ OpenStack の用途において CLVM を直接使用することが現実的か?
・ GFS2 を省略することでスケーラビリティ性能がどの程度改善されるか?
3. その他の方式
・ 上記 2 方式の検証結果がいずれもあまり芳しくない場合
・ 現実的な (OpenStack 側 Linuxカーネル変更を伴わない) 代替案を検討

iSCSIボリュームによる /var/lib/nova/instances ディレクトリの共有方法としては、SAN ファイルシステムを用いる方法があります。SANファイルシステムとしては GFS2 や OCFS2 があります。OCFS2 は linux カーネルの変更が必要なので、ここでは GFS2 を使用します。

GFS2 は CLVM を前提とします。GFS2 のスケーラビリティが NFS に劣る場合、CLVM を OpenStack から直接使用することを検討します。CLVM を直接使用してもスケーラビリティが NFS に劣る場合は Linux カーネルの変更が不要な方法として、 Gluster と Ceph を検討します。

Gluster は NFSv3 または FUSE で /var/lib/nova/instances ディレクトリにマウント可能です。
Ceph は FUSE で /var/lib/nova/instances ディレクトリにマウント可能です。ceph.ko でマウントする方法は Linux カーネルの変更が必要なので除外します。

ページトップ

比較の方法

比較する値には、3台の Nova compute ノード上で動作する最大 9 個のインスタンス (VM) から bonnie++ による I/O 負荷を掛けたときの、bonnie++ 終了までの所要時間を用います。

各インスタンス上での所要時間にバラつきがなく、より短時間に全て終了することとが期待する結果です。

【ディレクトリの構成パターン】

1. NFSv4

これは比較の基準となる、NFSv4 での測定環境です。

各 Nova ホストが NFSv4 でマウントする /var/lib/nova/instances ディレクトリは 1 台の サーバがサービスしています。
NFS ボリュームはブロックレベルで冗長化されています。データ冗長度は 3 です。

【ディレクトリの構成パターン】一覧に戻る

2. GFS2

これは GFS2 での測定環境です。

各 Nova ホストが GFS2 でマウントする /var/lib/nova/instances ディレクトリは 1 個の CLVM ボリューム上に構築されています。
CLVM ボリュームは 1 個の iSCSI ボリュームで構成されています。iSCSI ボリュームは 1 台のサーバがサービスしています。

iSCSI ボリュームもブロックレベルで冗長化されています。データ冗長度は 3 です。

【ディレクトリの構成パターン】一覧に戻る

3. CLVM+NFSv4

これは CLVM での測定環境です。

各 Nova ホストが接続する CLVM ボリュームグループは 1 個の iSCSI ボリュームで構成されています。iSCSI ボリュームは 1 台のサーバがサービスしています。
CLVMボリュームグループに VM イメージを配置します。VM イメージ以外は NFSv4 に配置します。各 Nova ホストが NFSv4 でマウントする /var/lib/nova/instances ディレクトリは iSCSI ボリュームと同じサーバがサービスしています (図中では別のサーバとなっています)。

NFS ボリューム、iSCSI ボリュームいずれもブロックレベルで冗長化されています。データ冗長度は 3 です。

【ディレクトリの構成パターン】一覧に戻る

4-1. Gluster (NFSv3)

これは Gluster (NFSv3) での測定環境です。

各 Nova ホストが NFSv3 でマウントする /var/lib/nova/instances ディレクトリは 4 台の Gluster サーバがサービスしています。

Gluster ボリュームは 4 台の Gluster サーバ上の全 12 個のボリュームで構成されています。各 Gluster サーバ上のボリュームはブロックレベルで冗長化されています。データ冗長度は 2 です。ブロックレベルでのデータ冗長化を行っているので Gluster によるファイルレベルでの冗長化は行っていません。

【ディレクトリの構成パターン】一覧に戻る

4-2. Gluster (FUSE)

これは Gluster (FUSE) での測定環境です。4-1. Gluster (NFSv3) と同じ環境で /var/lib/nova/instances ディレクトリのマウント方法のみが異なります。

各 Nova ホストが FUSE でマウントする /var/lib/nova/instances ディレクトリは 4 台の Gluster サーバがサービスしています。

Gluster ボリュームは 4 台の Gluster サーバ上の全 12 個のボリュームで構成されています。各 Gluster サーバ上のボリュームはブロックレベルで冗長化されています。データ冗長度は 2 です。ブロックレベルでのデータ冗長化を行っているので Gluster によるファイルレベルでの冗長化は行っていません。

【ディレクトリの構成パターン】一覧に戻る

5. Ceph (FUSE)

これは Ceph (FUSE) での測定環境です。

各 Nova ホストが FUSE でマウントする /var/lib/nova/instances ディレクトリは 4 台の Ceph OSD サーバがサービスしています。

Ceph Storage Cluster は 4 台の OSD サーバにより全 8 個のボリューム (OSD) で構成されています。各ボリューム (OSD) はブロックレベルで冗長化されています。データ冗長度は 3 です。ブロックレベルでのデータ冗長化を行っているので Ceph によるオブジェクトレベルでの冗長化は行っていません。

【ディレクトリの構成パターン】一覧に戻る

次回は、これまで開設した構成での測定結果を紹介します。

関連記事

クラウド
2012年7月31日
OpenStack: 分散オブジェクトストレージ Swift
ストレージ
2015年4月13日
Ceph/RADOS の OpenStack 利用
ネットワーク
2014年10月7日
OpenFlow の概要
お気軽にお問い合わせください

VA Linuxでは、様々なOSSにおける「コンサルティングサービス」をご提供しております。
サービスに関する詳細は、「コンサルティングサービス」の説明ページをご覧ください。

お問い合わせフォームはこちら
ページトップ