• 検索結果がありません。

使用不可能な Brick のクリーニング

ドキュメント内 管理ガイド (ページ 76-79)

第 5 章 ストレージボリュームの設定

5.1. GDEPLOY を使用した GLUSTER ストレージボリュームの設定

5.3.4. 使用不可能な Brick のクリーニング

2. サブディレクトリーをブリックとして使用し、Red Hat Gluster Storage ボリュームを作成しま す。

# gluster volume create distdata01 ad-rhs-srv1:/rhgs/brick1 ad-rhs-srv2:/rhgs/brick2

3. Red Hat Gluster Storage ボリュームを起動します。

# gluster volume start distdata01 4. ボリュームのステータスを確認します。

# gluster volume status distdata01

注記 注記

同じサーバーから複数のブリックを使用する場合は、ブリックが以下の形式でマウント されていることを確認します。例:

# df -h

/dev/rhs_vg/rhs_lv1 16G 1.2G 15G 7% /rhgs1 /dev/rhs_vg/rhs_lv2 16G 1.2G 15G 7% /rhgs2

各サーバーから 2 つのブリックを持つ分散ボリュームを作成します。例:

# gluster volume create test-volume server1:/rhgs1/brick1 server2:/rhgs1/brick1 server1:/rhgs2/brick2 server2:/rhgs2/brick2

5.3.3. 削除されたボリュームからの Brick の再利用

ブリックは削除したボリュームから再利用できますが、ブリックを再利用できるようにするにはいくつ かの手順が必要になります。

再フォーマットのためのファイルシステム対応ブリック

再フォーマットのためのファイルシステム対応ブリック(Optimal Method)

を実行 # mkfs.xfs -f -i size=512 device して、サポートされている要件に合わせてブリックを再フォー マットし、新規ボリュームですぐに再利用できるようにします。

注記 注記

ブリックを再フォーマットすると、すべてのデータが消去されます。

Brick ディレクトリーの親上のファイルシステムディレクトリーの親上のファイルシステム

ファイルシステムを再フォーマットできない場合は、ブリックディレクトリー全体を削除し、再度作成 します。

ブリックに関連付けられたファイルシステムを再フォーマットできず、ブリックディレクトリーを削除 できない場合は、以下の手順を実行します。

1. .glusterfs サブディレクトリーを含む、ブリック内の既存のデータをすべて削除します。

2. を実行 # setfattr -x trusted.glusterfs.volume-id brick # setfattr -x trusted.gfid brick して、

ブリックのルートから属性を削除します。

3. # getfattr -d -m . brick を実行して、ボリュームに設定された属性を確認します。属性を書き留 めます。

4. # setfattr -x attribute brick を実行して、glusterFS ファイルシステムに関連する属性を削除し ます。

分散ボリュームの trusted.glusterfs.dht 属性は、削除する必要がある属性の例の 1 つです。

5.4. 分散ボリュームの作成

このタイプのボリュームは、ボリュームのブリック全体にファイルを分散します。

図5.1 分散ボリュームの図分散ボリュームの図

警告 警告

ディレクトリーの内容はボリューム内のブリックにランダムに分散されるため、分 散ボリュームでは、ディスクやサーバーの障害時にデータ損失が大幅に発生し、実 稼働環境での使用前にアーキテクチャーの確認が必要になるためです。

分散ボリュームのみを使用する場合は、Red Hat アカウントチームに連絡してアー キテクチャーの確認を依頼してください。

冗長性が重要ではない場合や、他のハードウェアまたはソフトウェア層で提供され る場合にのみ、分散ボリュームを使用します。他の場合には、分散複製ボリューム などの冗長性を提供するボリューム種別の 1 つを使用します。

分散ボリュームのみの制限は次のとおりです。

1. サービスのアップグレードなし:アップグレード時にボリュームのみをオ フラインにする必要があります。

2. 最終的なノードに障害が発生している間、ディレクトリーエントリーと

inode の一時的な不整合。

3. I/O 操作は、ノードの利用不可や最終的なノードの障害によりブロックま

たは失敗します。

4. データの永続的な損失。

分散ボリュームの作成 分散ボリュームの作成

gluster volume create コマンドを使用して、異なるタイプのボリュームを作成し、ボリュームの作成

が正常に行われたことを確認する gluster volume info コマンドを実行します。

前提条件 前提条件

で説明されているように、信頼済みストレージプールが作成されました「信頼済みストレージ プールへのサーバーの追加」。

の説明に従って、ボリュームを起動および停止する方法を理解し「ボリュームの起動」ます。

1. gluster volume create コマンドを実行して、分散ボリュームを作成します。

構文はです。 gluster volume create NEW-VOLNAME [transport tcp | rdma (Deprecated) | tcp,rdma] NEW-BRICK...

transport のデフォルト値はです tcp。auth.allow またはなどの他のオプションを指定でき

auth.rejectます。パラメーターの全リストは、を参照「ボリュームオプションの設定」してく

ださい。

この performance.client-io-threads オプションは、パフォーマンスが低下する傾向があるた め、分散ボリュームでオプションを無効にすることを推奨します。以下のコマンドを実行して 無効にし performance.client-io-threadsます。

# gluster volume set VOLNAME performance.client-io-threads off

例5.1 2 つのストレージサーバーを備えた分散ボリュームつのストレージサーバーを備えた分散ボリューム

例5.2 4 台のサーバーを使用した台のサーバーを使用した InfiniBand を介した分散ボリュームを介した分散ボリューム

2. 以下のコマンド # gluster volume start VOLNAME を実行してボリュームを起動します。

3. gluster volume info コマンドを実行して、オプションでボリューム情報を表示します。

以下の出力はの結果になり例5.1「2 つのストレージサーバーを備えた分散ボリューム」ます。

ドキュメント内 管理ガイド (ページ 76-79)