ZFSが長年染み付いているので、対比表を作ってみました。
1年以上前にも導入を検討しましたが、いろいろあって見送りました。
最近システム構成を考える中で意外と行けるかもと思い直すようになりました。
ZFSよりもメモリへの要求が少ないのが、特にいいですね。
■確認したバージョン
GlusterFS 3.2.5（CentOS5.7）
ZFS v28（FreeBSD9.0）
まずは概念図から。
GlusterFSのマニュアルはZFSと同じだけど意味の違う用語が入り乱れているので、読んでて混乱します。
頭に叩き込んでおきましょう。
次にファイルシステムを作成する段取りについて。
| ZFSでの操作 | GlusterFSでの操作 |
サーバにデバイス（ディスク）を設置する | サーバを信任する（例：2台） ブリック（ディレクトリ）を作成する |
デバイスからストレージプールを作成する ストレージプールからファイルシステムを作成する | ブリックからボリュームを作成する ボリュームを利用開始する |
マウントポイントを設定する（マウント自体は全自動） | マウントする |
最後に、もうちょっと細かい操作コマンドの違いについて。
オプションは一切省いているので、説明書を必ず熟読してください。
GlusterFSは設定ファイルを直接いじれば、リネームとかも可能なんだと思いますけれども、覚えるのが面倒なのでコマンドラインツールで操作できる内容に絞りました。
| ZFSの操作 | ZFSでのコマンド | GlusterFSでのコマンド | GlusterFSの操作 |
| ZFSにはGlusterFSの"信頼されたストレージプール"に相当する概念はない。 サーバ構成は自分自身の1台のみで完結なので関係ない。 | gluster peer probe | サーバを信任する（"信頼されたストレージプール"に追加する） | |
| gluster peer detach | サーバを信任解除する（"信頼されたストレージプール"から取り除く） | ||
| ファイルシステムのマウント許可（デフォルト） | zfs set canmount=on | gluster volume start | ボリューム利用開始 |
| ファイルシステムのマウント禁止 | zfs set canmount=off | gluster volume stop | ボリューム利用停止（デフォルト） |
| デバイスからストレージプールを作成する | zpool create | gluster volume create | ディレクトリからボリュームを作成する |
| ストレージプールからファイルシステムを作成する | zfs create | ||
| ストレージプールを破棄する | zpool destroy | gluster volume delete | ボリュームを破棄する |
| ファイルシステムを破棄する | zfs destroy | ||
| ストレージプールにデバイスを追加する（容量拡大、ホットスペア、ZIL、L2ARC） | zpool add | gluster volume add-brick | ボリュームにブリックを追加する（容量拡大のみ） |
| ZFSでは容量は縮小できない（通常デバイスは取り外せない） | gluster volume remove-brick | ボリュームからブリックを取り外す（そのブリックに記録されているデータはボリュームから消失する）(*1) | |
| ストレージプールからデバイスを取り外す（ホットスペア、ZIL、L2ARC） | zpool remove | GlusterFSにはそうした特殊デバイスは存在しない。 | |
| デバイスを入れ替える | zpool replace | gluster volume replace-brick | ブリックを入れ替える |
| ZFSでは記録済みデータはリバランスできない | gluster volume rebalance | ブリック間で記録済みデータをリバランスする | |
| ストレージプールにミラーデバイスを追加する | zpool attach | GlusterFSではミラー数は途中変更できない。 | |
| ストレージプールのミラーデバイスを削除する | zpool detach | ||
| ストレージプールの一覧を表示する | zpool list | gluster volume info all | ボリュームの構成情報を表示する。ただし容量は表示されない。(*2) |
| ストレージプールの状態を表示する | zpool status | ||
| ファイルシステムの一覧を表示する | zfs list | ||
| デバイスの使用を停止する | zpool offline | GlusterFSではブリックは個別停止できない。(*3)(*5) | |
| デバイスの使用を再開する | zpool online | ||
| エラーチェック＆修復 | zpool scrub | レプリケーションはファイルにアクセスする度に自動修復される。(*4) | |
| ファイルシステムをリネームする | zfs rename | GlusterFSではボリューム名は途中変更できない。 | |
(*1)ファイル消失について
ボリュームの構成情報のみが削除され、データは残る。
各ブリックはただのディレクトリなので、ストライピングしていなければ直接救出可能。
ストライピングしている場合はファイルの一部分がsparseで欠損しているので非常に大変だと思うが、不可能ではないだろうとは思う。
まぁディスクなりブリックなりを一度追加したら簡単には外せないというのはZFSもGlusterFSも似たような状況ということで。
(*2)容量の確認方法
容量はマウント先でdf -kコマンド等で確認すればよい。
ただしGlusterFSのボリュームは普通のディレクトリの寄せ集めのため、ディレクトリ毎に空き容量がバラバラなので、df的には空いててもバランシングの状況次第では容量フルでエラっちゃう可能性がある気がする。
容量オーバーを防止するなら構成ディレクトリをそれぞれ個別に監視しないといけませんね。
(*3)ブリックは個別停止できない件について
ミラーされていて、かつNative Clientでマウントしていれば自動でフェイルオーバーされるので、停止させずに抜いちゃっても問題ないはず・・・（と思うけど確かめたわけではない）(*5)
(*4)レプリケーションの修復について
インデックスのみで良ければ find <gluster-mount> -print0 | xargs --null stat >/dev/null
ファイル内容まで完全に find <gluster-mount> -type f -exec dd if='{}' of=/dev/null bs=1M; > /dev/null 2>&1
チェックサム情報は（多分）持っていないので静的なデータ破壊までは点検できない（と思うけど確かめたわけではない）
以下20120124追記
(*5)試してみた
稼働中に、brickに使ってるディスクをマウントしてあるディレクトリをumountしてみました。
umountされてもGlusterFSは何事も無かったかのように稼働し続けました。素晴らしい。ではなくて、大変な事態に陥りました。
マウントポイントはマウント解除されることによって単なる空ディレクトリに変わりますが、GlusterFSはその空ディレクトリを使って勝手にレプリカの復元を始めてしまいます。おそらくファイルシステムの異変は感知せずレプリカの片割れが欠落したとだけ認識してしまうんでしょう。USB起動だったので起動ディスクが一瞬で埋まってしまいました・・・orz
では単にumountするだけではなくマウントポイントのディレクトリを削除するとどうなるかというと、復元動作は一応停止しますが、レプリケーションの片割れが読み書きできないことでクライアントにinput/output errorが返ってしまい、稼働継続できませんでした。レプリケーションの片割れは正常であるにも関わらずです。
シンプル設計との観点でいえば妥当な動作ではあろうと思いますが、運用中にマウントが外れることは、異常/正常を問わず有り得ると思うんですよね。これじゃ単発ディスクがSPOFになっちゃう。その対策としてディスクとファイルシステムで2重に冗長化するのはコスト高でしょう。やっぱりbrickは明示的に個別に一時停止できたほうが、いいんじゃないかなぁ。
これがネットワーク切断やサーバダウンによる片割れ停止だったら異常検知されて稼働し続けられるのかなぁと想像しますが、どうなんでしょう。後日、試してみたいと思います。
0 件のコメント:
コメントを投稿