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

Ceph/RADOS を OpenStack のストレージインフラとして利用する場合の構成例と性能比較例を解説します。
本稿は、@ITで連載している『Ceph/RADOS 入門』 の内容を踏まえた解説となります。@IT での連載記事は、以下を参照ください。

• 第1回 分散ストレージ Ceph/RADOS とは？
• 第2回 Ceph/RADOSの実装から動作の仕組みを理解する
• 第3回 Ceph/RADOSのインストール、環境構築と接続テストまで
• 第4回 Cephがスケールできる理由、単一障害点を排除する仕組み、負荷を減らす実装

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

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

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

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

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

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

• 1. NFSv4
• 2. GFS2
• 3. CLVM + NFSv4
• 4-1. Gluster (NFSv3)
• 4-2. Gluster (FUSE)
• 5. Ceph (FUSE)

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

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カーネル変更が必要な方法は不可とします。

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 によるオブジェクトレベルでの冗長化は行っていません。

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

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