バックエンドの設定

# brick_dirs=/rhgs/brick{1,2,3}

#

[volume]

action=create

volname=sample_volname replica=yes

replica_count=3 force=yes

[clients]

action=mount

volname=sample_volname hosts=10.70.46.15

fstype=glusterfs

client_mount_points=/mnt/gluster

この設定では、指定の IP アドレスとバックエンドデバイスを持つ 3 x 3 のレプリカ信頼済みストレージ プールが /dev/sdb /dev/sdc、/dev/sdd ボリューム名で作成 sample_volname されます。

可能な値の詳細は、を参照してください。「設定ファイル」

設定ファイルを変更したら、コマンドを使用して設定を呼び出します。

# gdeploy -c txt.conf

注記 注記

にあるテンプレートファイルを参照して、新しい設定ファイルを作成でき

/usr/share/doc/gdeploy/examples/gluster.conf.sampleます。新しい設定ファイルを起 動するには、gdeploy -c /path_to_file/config.txt コマンドを実行します。

バックエンドを only 設定する方法は、を参照してください。「バックエンドの設定」 ボリュームを only 作成するには、を参照してください。「ボリュームの作成」

クライアントを only マウントする場合は、を参照してください。「クライアントのマウント」

物理ボリューム(PV)、ボリュームグループ(VG)、および論理ボリューム(LV)を個別に作成

注記 注記

Red Hat Enterprise Linux 6 の場合は、gdeploy を使用してバックエンドのブリックを設 定する前に、xfsprogs パッケージをインストールする必要があります。

5.1.3.1. [backend-setup] モジュールの使用モジュールの使用

バックエンドの設定は、特定のマシンまたはすべてのマシンで実行できます。backend-setup モジュー ルは、PV、VG、および LV を内部に作成し、デバイスをマウントします。thin-p 論理ボリュームは、

Red Hat のパフォーマンスの推奨事項に従って作成されます。

バックエンドは、以下のような要件に基づいて設定できます。

generic 特定の generic

ディスク名がマシン全体で統一されている場合は、バックエンドの設定は以下のように記述できます。

バックエンドは、'hosts' セクションのすべてのホストに対して設定されます。

可能な値の詳細は、を参照してください。「設定ファイル」

設定ファイルの例： Backend-setup-generic.conf

#

# Usage:

# gdeploy -c backend-setup-generic.conf

#

# This configuration creates backend for GlusterFS clusters

# [hosts]

10.70.46.130 10.70.46.32 10.70.46.110 10.70.46.77

# Backend setup for all the nodes in the `hosts' section. This will create

# PV, VG, and LV with gdeploy generated names.

[backend-setup]

devices=vdb 特定の

特定の

クラスター内のマシン間でディスク名が異なる場合、バックエンドの設定は特定のディスク名を持つ特 定のマシン用に記述できます。gdeploy は、1 つの設定ファイルで特定の設定をホストするのが非常に 柔軟です。

可能な値の詳細は、を参照してください。「設定ファイル」

設定ファイルの例： backend-setup-hostwise.conf

#

# Usage:

# gdeploy -c backend-setup-hostwise.conf

#

# This configuration creates backend for GlusterFS clusters

# [hosts]

10.70.46.130 10.70.46.32 10.70.46.110 10.70.46.77

# Backend setup for 10.70.46.77 with default gdeploy generated names for

# Volume Groups and Logical Volumes. Volume names will be GLUSTER_vg1,

# GLUSTER_vg2...

[backend-setup:10.70.46.77]

devices=vda,vdb

# Backend setup for remaining 3 hosts in the `hosts' section with custom names

# for Volumes Groups and Logical Volumes.

[backend-setup:10.70.46.{130,32,110}]

devices=vdb,vdc,vdd vgs=vg1,vg2,vg3

pools=pool1,pool2,pool3 lvs=lv1,lv2,lv3

mountpoints=/rhgs/brick1,/rhgs/brick2,/rhgs/brick3 brick_dirs=/rhgs/brick1/b1,/rhgs/brick2/b2,/rhgs/brick3/b3

5.1.3.2. PV、、VG、および、および LV の設定によるバックエンドの作成の設定によるバックエンドの作成

バックエンドの設定に対する制御がさらに必要な場合は、pv、vg、および lv を個別に作成できます。

LV モジュールは、VPC に複数の LV を作成する柔軟性を提供します。たとえば、「backend-setup」 モジュールはデフォルトで thin-pool を設定し、デフォルトのパフォーマンス推奨事項を適用します。

ただし、ユーザーが複数の LV を要求するユースケースが異なり、シンプールとシックプールの組み合 わせにより「backend-setup」はヘルプにはなりません。ユーザーは、PV、VG、および LV モジュール を使用してこれを実行できます。

可能な値の詳細は、を参照してください。「設定ファイル」

以下の例は、1 つのボリュームグループに 4 つの論理ボリュームを作成する方法を示しています。この 例では、thinpool と shipool LV の作成を混在しています。

[hosts]

10.70.46.130 10.70.46.32 [pv]

action=create devices=vdb [vg1]

action=create vgname=RHS_vg1 pvname=vdb

[lv1]

action=create vgname=RHS_vg1 lvname=engine_lv lvtype=thick size=10GB

mount=/rhgs/brick1 [lv2]

action=create vgname=RHS_vg1 poolname=lvthinpool lvtype=thinpool

poolmetadatasize=200MB chunksize=1024k

size=30GB [lv3]

action=create

lvname=lv_vmaddldisks poolname=lvthinpool vgname=RHS_vg1 lvtype=thinlv mount=/rhgs/brick2 virtualsize=9GB [lv4]

action=create

lvname=lv_vmrootdisks poolname=lvthinpool vgname=RHS_vg1 size=19GB

lvtype=thinlv mount=/rhgs/brick3 virtualsize=19GB 既存の VG を拡張する例：

#

# Extends a given given VG. pvname and vgname is mandatory, in this example the

# vg `RHS_vg1' is extended by adding pv, vdd. If the pv is not alreay present, it

# is created by gdeploy.

# [hosts]

10.70.46.130 10.70.46.32 [vg2]

action=extend vgname=RHS_vg1 pvname=vdd