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

Red Hat Gluster Storage ボリュームは、ブリックの論理コレクションです。各ブリックは、信頼できるストレージプール内のサーバーのエクスポートディレクトリーです。Red Hat Gluster Storage Server の管理操作のほとんどは、ボリュームに対して実行されます。パフォーマンスを向上させるために Red Hat Gluster Storage を設定する方法は、19章パフォーマンスチューニング を参照してください。
警告
Red Hat は、ブリックへのデータを直接書き込みすることをサポートしていません。ネイティブクライアントまたは NFS または SMB マウントを介してのみデータの読み取りおよび書き込みを行います。
注記
Red Hat Gluster Storage は IP over Infiniband (IPoIB) をサポートします。この機能をサポートするために、すべての Red Hat Gluster Storage サーバーおよびクライアントに Infiniband パッケージをインストールします。yum groupinstall "Infiniband Support" を実行して Infiniband パッケージをインストールします。

ボリュームタイプ

Distributed (分散)
ファイルをボリューム内のブリックに分散します。
スケーリングと冗長性の要件が重要ではないか、他のハードウェアやソフトウェア層により提供されるこのボリュームタイプを使用します。
このボリュームタイプの補足情報は、「分散ボリュームの作成」 を参照してください。
Replicated (レプリケート)
ボリューム内のブリック間でファイルを複製します。
高い可用性と信頼性が重要である環境では、このボリュームタイプを使用します。
このボリュームタイプの補足情報は、「複製ボリュームの作成」 を参照してください。
Distributed Replicated
ファイルをボリューム内の複製されたブリックに分散します。
高い信頼性と柔軟性が重要である環境では、このボリュームタイプを使用します。このボリュームタイプは、多くの環境で読み取りパフォーマンスが向上します。
このボリュームタイプの補足情報は、「分散複製ボリュームの作成」 を参照してください。
Arbitrated Replicated
レプリカセットの 2 つのブリックでファイルを複製し、メタデータのみを 3 番目のブリックに複製します。
一貫性が重要な環境でこのボリュームタイプを使用しますが、ベースとなるストレージ領域は非常に貴重です。
このボリュームタイプの補足情報は、「Arbitrated Replicated ボリュームの作成」 を参照してください。
Dispersed
ボリュームのブリック全体でファイルのデータを分散します。
無駄にする領域を最小元に抑える、信頼性の設定可能なレベルが必要なこのボリュームタイプを使用します。
このボリュームタイプの補足情報は、「分散ボリュームの作成」 を参照してください。
Distributed Dispersed
分散するサブボリューム全体でファイルのデータを分散します。
無駄にする領域を最小元に抑える、信頼性の設定可能なレベルが必要なこのボリュームタイプを使用します。
このボリュームタイプの補足情報は、「Distributed Dispersed ボリュームの作成」 を参照してください。

5.1. gdeploy を使用した Gluster Storage ボリュームの設定

gdeploy ツールは、ブリックの作成、フォーマット、マウントのプロセスを自動化します。gdeploy では、『Section 5.4 Formatting and Mounting Bricks』 と 『Section 5.10 Creating Distributed Dispersed Volumes』 にリストされている手動の手順が自動化されています。
新しい信頼できるストレージプールを設定する場合は、複数のコマンドを手動で実行するとエラーになる可能性があるため、gdeploy が信頼されるストレージプールセットを使用することが推奨されます。
gdeploy を使用してブリックの作成を自動化する利点は次のとおりです。
  • 複数のマシンへのバックエンドの設定は、ラップトップ/デスクトップから実行できます。これにより、信頼されているストレージプール内のノード数が増えると、時間が短縮され、スケールアップできるようになります。
  • 設定するドライブを選択する柔軟性 (sd、vd、...)
  • 論理ボリューム (LV) およびボリュームグループ (VG) の命名に柔軟性がある。

5.1.1. 使い始める

前提条件

  1. 以下のコマンドを実行して、信頼できるストレージプールの一部であるノードのパスフレーズなしの SSH 鍵を生成します。
    # ssh-keygen -t rsa -N ''
  2. 以下のコマンドを実行して、gdeploy コントローラーとサーバー間のキーベースの SSH 認証アクセスを設定します。
    # ssh-copy-id -i root@server
    注記
    Red Hat Gluster Storage ノードを外部ノードではなくデプロイメントノードとして使用する場合は、インストールが実行される Red Hat Gluster Storage ノードにキーベースの SSH 認証を設定する必要があります。
  3. 以下のコマンドを実行して、Ansible のインストールに必要なリポジトリーを有効にします。
    Red Hat Enterprise Linux 8 の場合
    # subscription-manager repos --enable=ansible-2-for-rhel-8-x86_64-rpms
    Red Hat Enterprise Linux 7 の場合
    # subscription-manager repos --enable=rhel-7-server-ansible-2-rpms
  4. 以下のコマンドを実行して、ansible をインストールします。
    # yum install ansible
  5. 以下のことを確認する必要があります。
    • デバイスは raw で未使用である必要があります
    • デフォルトのシステムロケールは en_US に設定する必要があります
      システムロケールの詳細は、『Red Hat Enterprise Linux 7 システム管理者のガイド』の『システムロケールの設定』を参照してください。
    • 複数のデバイスの場合は、gdeploy 設定ファイルで複数のボリュームグループ、シンプール、および thinvol を使用します。
gdeploy を使用して Red Hat Gluster Storage をデプロイする方法は 2 つあります。
  • 信頼できるストレージプールでのノードの使用
  • 信頼できるストレージプールの外部にあるマシンの使用

クラスターでのノードの使用

gdeploy パッケージは、Red Hat Gluster Storage の初回インストールの一部としてバンドルされています。

信頼できるストレージプールの外部にあるマシンの使用

Red Hat Gluster Storage が必要なチャンネルにサブスクライブされていることを確認する必要があります。詳細は、『Red Hat Gluster Storage 3.5 Installation Guide』の『Subscribing to the Red Hat Gluster Storage Server Channels』を参照してください。

以下のコマンドを実行して gdeploy をインストールします。
# yum install gdeploy
gdeploy のインストールに関する詳細は、『Red Hat Gluster Storage 3.5 Installation Guide』の『Installing Ansible to Support Gdeploy』セクションを参照してください。

5.1.2. 信頼できるストレージプールの設定

信頼できるストレージプールの作成は不適切なタスクで、信頼できるストレージプールのノードほど複雑になります。gdeploy では、信頼できるストレージプールの設定には、設定ファイルのみを使用できます。gdeploy をインストールすると、設定ファイルのサンプルが以下に作成されます。
/usr/share/doc/gdeploy/examples/gluster.conf.sample
注記
信頼できるストレージプールは、バックエンドのセットアップ、ボリュームの作成、または 1 つの設定として合計するなど、各タスクを実行することによって作成できます。
たとえば、3 x 3 で複製されたボリュームの基本的な信頼できるストレージプールの場合、設定ファイルの設定詳細は以下のようになります。
3x3-volume-create.conf:
#
# Usage:
#       gdeploy -c 3x3-volume-create.conf
#
# This does backend setup first and then create the volume using the
# setup bricks.
#
#

[hosts]
10.70.46.13
10.70.46.17
10.70.46.21


# Common backend setup for 2 of the hosts.
[backend-setup]
devices=sdb,sdc,sdd
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

# If backend-setup is different for each host
# [backend-setup:10.70.46.13]
# devices=sdb
# brick_dirs=/rhgs/brick1
#
# [backend-setup:10.70.46.17]
# devices=sda,sdb,sdc
# 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
この設定では、ボリューム名を sample_volname とし、指定の IP アドレスとバックエンドデバイスを、/dev/sdb/dev/sdc/dev/sdd として、持つ 3 x 3 レプリカの信頼ストレージプールが作成されます。
可能な値については、「設定ファイル」 を参照してください。
設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf
注記
/usr/share/doc/gdeploy/examples/gluster.conf.sample で利用可能なテンプレートファイルを参照して、新しい設定ファイルを作成することができます。新規設定ファイルを呼び出すには、gdeploy -c /path_to_file/config.txt コマンドを実行します。
バックエンド だけ を設定する場合は、「バックエンドの設定 」 を参照してください。
ボリューム のみ を作成するには、「ボリュームの作成」 を参照してください。
クライアント のみ をマウントする場合は、「クライアントのマウント」 を参照してください。

5.1.3. バックエンドの設定

Gluster Storage ボリュームを設定するには、LVM thin-p をストレージディスクに設定する必要があります。信頼できるストレージプール内のマシン数が大きい場合、関連するコマンド数が大きい場合、注意してもエラーが発生するため、これらのタスクには時間がかかります。gdeploy では、バックエンドの設定には設定ファイルのみを使用できます。バックエンドは、新たに信頼されているストレージプールを設定する際に設定されます。これには、ボリュームを作成する前にブリックを設定する必要があります。gdeploy をインストールすると、設定ファイルのサンプルが以下に作成されます。
/usr/share/doc/gdeploy/examples/gluster.conf.sample
バックエンドを設定する方法は 2 つあります。
  • [backend-setup] モジュールの使用
  • 物理ボリューム (PV)、ボリュームグループ (VG)、および論理ボリューム (LV) の個別作成
注記
Red Hat Enterprise Linux 6 の場合は、gdeploy を使用してバックエンドブリックを設定する前に xfsprogs パッケージをインストールする必要があります。
重要
Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。インストールガイドの『バージョンの詳細』表および『Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 を参照してください。

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

バックエンドの設定は、特定のマシンまたはすべてのマシンで実行できます。backend-setup モジュールは内部的に PV、VG、および LV を作成し、デバイスをマウントします。thin-p 論理ボリュームは、Red Hat によるパフォーマンス推奨事項に従って作成されます。
バックエンドは、以下のような要件に基づいて設定することができます。
  • 汎用
  • 特定

汎用

ディスク名がマシン全体で統一されている場合は、以下のようにバックエンドの設定を作成することができます。'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 モジュールは、VG 上に複数の LV を作成する柔軟性を提供します。たとえば、`backend-setup’モジュールは、デフォルトでシンプールをセットアップし、デフォルトのパフォーマンス推奨事項を適用します。ただし、複数の LV、シンプールとシックプールの組み合わせを必要とするような異なるユースケースがある場合は、`backend-setup’ は役に立ちません。これは、PV、VG、および LV モジュールを使用して実行できます。
可能な値については、「設定ファイル」 を参照してください。
以下の例は、1 つのボリュームグループに論理ボリュームを 4 つ作成する方法を示しています。この例では、シンとシックプール 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

5.1.4. ボリュームの作成

ボリュームのセットアップには、ホスト名/IP とブリックの順序を慎重に選択し、エラーが送出される可能性があります。gdeploy は、このタスクを簡素化するのに役立ちます。gdeploy をインストールすると、設定ファイルのサンプルが以下に作成されます。
/usr/share/doc/gdeploy/examples/gluster.conf.sample
たとえば、4 x 3 で複製されたボリュームの基本的な信頼できるストレージプールの場合、設定ファイルの設定詳細は以下のようになります。
[hosts]
10.0.0.1
10.0.0.2
10.0.0.3
10.0.0.4

[volume]
action=create
volname=glustervol
transport=tcp,rdma
replica=yes
replica_count=3
brick_dirs=/glus/brick1/b1,/glus/brick1/b1,/glus/brick1/b1
force=yes
可能な値については、「設定ファイル」 を参照してください。
設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf

複数のボリュームの作成

注記
gdeploy 2.0 から複数ボリュームを作成することしかサポートされません。この設定を試みる前に、gdeploy バージョンを確認してください。
1 つの設定で複数のボリュームを作成する場合は、[volume] モジュールに番号を指定する必要があります。たとえば、ボリュームが 2 つある場合、[volume1]、[volume2] の番号が付けられます。
vol-create.conf
[hosts]
10.70.46.130
10.70.46.32
10.70.46.16

[backend-setup]
devices=vdb,vdc,vdd,vde
mountpoints=/mnt/data{1-6}
brick_dirs=/mnt/data1/1,/mnt/data2/2,/mnt/data3/3,/mnt/data4/4,/mnt/data5/5,/mnt/data6/6

[volume1]
action=create
volname=vol-one
transport=tcp
replica=yes
replica_count=3
brick_dirs=/mnt/data1/1,/mnt/data2/2,/mnt/data5/5

[volume2]
action=create
volname=vol-two
transport=tcp
replica=yes
replica_count=3
brick_dirs=/mnt/data3/3,/mnt/data4/4,/mnt/data6/6
gdeploy 2.0 を使用すると、複数のボリュームオプションを設定してボリュームを作成できます。値と一致するキーの数。
[hosts]
10.70.46.130
10.70.46.32
10.70.46.16

[backend-setup]
devices=vdb,vdc
mountpoints=/mnt/data{1-6}

[volume1]
action=create
volname=vol-one
transport=tcp
replica=yes
replica_count=3
key=group,storage.owner-uid,storage.owner-gid,features.shard,features.shard-block-size,performance.low-prio-threads,cluster.data-self-heal-algorithm
value=virt,36,36,on,512MB,32,full
brick_dirs=/mnt/data1/1,/mnt/data3/3,/mnt/data5/5

[volume2]
action=create
volname=vol-two
transport=tcp
replica=yes
key=group,storage.owner-uid,storage.owner-gid,features.shard,features.shard-block-size,performance.low-prio-threads,cluster.data-self-heal-algorithm
value=virt,36,36,on,512MB,32,full
replica_count=3
brick_dirs=/mnt/data2/2,/mnt/data4/4,/mnt/data6/6
上記の設定では、複数のボリュームオプションを設定した 2 つのボリュームが作成されます。

5.1.5. クライアントのマウント

クライアントをマウントする場合は、マウントする必要のあるすべてのクライアントにログインする代わりに、gdeploy を使用してクライアントをリモートでマウントできます。gdeploy をインストールすると、設定ファイルのサンプルが以下に作成されます。
/usr/share/doc/gdeploy/examples/gluster.conf.sample
以下は、クライアントをマウントするための設定ファイルに対する変更例です。
[clients]
action=mount
hosts=10.70.46.159
fstype=glusterfs
client_mount_points=/mnt/gluster
volname=10.0.0.1:glustervol
注記
ファイルシステムタイプ (fstype) が NFS の場合は、nfs-version と記載します。デフォルトのバージョンは 3 です。
可能な値については、「設定ファイル」 を参照してください。
設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf

5.1.6. ボリュームの設定

ボリュームは設定ファイルを使用して設定できます。ボリュームは、信頼できるストレージプールにログインせずに設定ファイルを使用してリモートで設定できます。設定ファイルのセクションおよびオプションの詳細は、「設定ファイル」 を参照してください。

5.1.6.1. ブログの追加および削除

設定ファイルを変更して、ブリックを追加または削除できます。

ブログの追加

設定ファイルの [volume] セクションを変更して、ブリックを追加します。以下に例を示します。

[volume]
action=add-brick
volname=10.0.0.1:glustervol
bricks=10.0.0.1:/rhgs/new_brick
設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf

ブリックの削除

設定ファイルの [volume] セクションを変更して、ブリックを削除します。以下に例を示します。

[volume]
action=remove-brick
volname=10.0.0.1:glustervol
bricks=10.0.0.2:/rhgs/brick
state=commit
state についての他のオプションは stop、start、および force です。
設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf
可能な値については、「設定ファイル」 を参照してください。

5.1.6.2. ボリュームのリバランス

設定ファイルの [volume] セクションを変更して、ボリュームをリバランスします。以下に例を示します。
[volume]
action=rebalance
volname=10.70.46.13:glustervol
state=start
state 用の他のオプションは stop および fix-layout です。
設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf
可能な値については、「設定ファイル」 を参照してください。

5.1.6.3. ボリュームの起動、停止、または削除

設定ファイルは、ボリュームの起動、停止、または削除が可能です。

ボリュームの起動

設定ファイルの [volume] セクションを変更してボリュームを起動します。以下に例を示します。

[volume]
action=start
volname=10.0.0.1:glustervol
設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf

ボリュームの停止

設定ファイルの [volume] セクションを変更してボリュームを起動します。以下に例を示します。

[volume]
action=stop
volname=10.0.0.1:glustervol
設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf

ボリュームの削除

設定ファイルの [volume] セクションを変更してボリュームを起動します。以下に例を示します。

[volume]
action=delete
volname=10.70.46.13:glustervol
設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf
可能な値については、「設定ファイル」 を参照してください。

5.1.7. 設定ファイル

設定ファイルには、gdeploy の設定変更に使用できるさまざまなオプションが含まれます。現在、以下のオプションがサポートされています。
  • [hosts]
  • [devices]
  • [disktype]
  • [diskcount]
  • [stripesize]
  • [vgs]
  • [pools]
  • [lvs]
  • [mountpoints]
  • [peer]
  • [clients]
  • [volume]
  • [backend-setup]
  • [pv]
  • [vg]
  • [lv]
  • [RH-subscription]
  • [yum]
  • [shell]
  • [update-file]
  • [service]
  • [script]
  • [firewalld]
  • [geo-replication]
オプションは、以下のリストで簡単に説明されています。
  • hosts

    これは、信頼できるストレージプール内のマシンの IP アドレスまたはホスト名が含まれる必須のセクションです。ホスト名または IP アドレスは別々の行に記載する必要があります。

    以下に例を示します。
    [hosts]
    10.0.0.1
    10.0.0.2
  • devices

    これは汎用セクションであり、[hosts] セクションに一覧表示されている全ホストに適用できます。ただし、[hostname] や [IP-address] などのホストのセクションが存在する場合は、[devices] などの一般的なセクションのデータは無視されます。ホスト固有のデータが優先されます。これは任意のセクションです。

    以下に例を示します。
    [devices]
    /dev/sda
    /dev/sdb
    注記
    バックエンドの設定時に、デバイスをこのセクションに一覧表示するか、ホスト固有のセクションに記載する必要があります。
  • disktype

    本セクションでは、バックエンドの設定中に使用されるディスク設定を指定します。gdeploy は、RAID 10、RAID 6、RAID 5、および JBOD 設定をサポートします。これは任意のセクションであり、このフィールドが空のままであれば、JBOD がデフォルト設定として取得されます。このフィールドに有効な値は、raid10raid6raid5jbod です。

    以下に例を示します。
    [disktype]
    raid6
  • diskcount

    本セクションでは、セットアップ内のデータディスクの数を指定します。RAID ディスクタイプが [disktype] の下に指定される場合、これは必須フィールドです。[disktype] が JBOD の場合、[diskcount] の値は無視されます。このパラメーターはホスト固有のものです。

    以下に例を示します。
    [diskcount]
    10
  • stripesize

    本セクションでは、stripe_unit サイズを KB 単位で指定します。

    ケース 1: [disktype] が JBOD で、指定の値は無視されます。
    ケース 2: [disktype] が RAID 5 または RAID 6 として指定されている場合、これは必須フィールドです。
    [disktype] RAID 10 の場合、デフォルト値は 256KB になります。Red Hat では、この値を変更することは推奨していません。その他の値を指定すると、以下の警告が表示されます。
    "Warning: We recommend a stripe unit size of 256KB for RAID 10"
    注記
    K、KB、M などのサフィックスを追加しないでください。このパラメーターはホストごとに固有で、hosts セクションに追加できます。
    以下に例を示します。
    [stripesize]
    128
  • vgs

    このセクションは、gdeploy 2.0 で非推奨となりました。gdeploy 2.0 の詳細は [backend-setup] を参照してください。本セクションでは、[devices] に一覧表示されているデバイスのボリュームグループ名を指定します。[vgs] セクションのボリュームグループ数は、[devices] 内のボリュームグループの数に一致する必要があります。ボリュームグループ名がない場合には、ボリュームグループはデフォルトで GLUSTER_vg{1, 2, 3, ...} という名前になります。

    以下に例を示します。
    [vgs]
    CUSTOM_vg1
    CUSTOM_vg2
  • プール

    このセクションは、gdeploy 2.0 で非推奨となりました。gdeploy 2.0 の詳細は [backend-setup] を参照してください。本セクションでは、[vgs] セクションに指定したボリュームグループのプール名を指定します。[pools] セクションに一覧表示されるプールの数は、[vgs] セクションのボリュームグループの数と一致する必要があります。プール名がない場合、プールの名前は GLUSTER_pool{1, 2, 3, ...} になります。

    以下に例を示します。
    [pools]
    CUSTOM_pool1
    CUSTOM_pool2
  • lvs

    このセクションは、gdeploy 2.0 で非推奨となりました。gdeploy 2.0 の詳細は [backend-setup] を参照してください。本セクションでは、[vgs] で指定したボリュームグループの論理ボリューム名を説明します。[lvs] セクションに一覧表示される論理ボリュームの数は、[vgs] に記載されているボリュームグループの数と一致する必要があります。論理ボリューム名が見つからない場合は、GLUSTER_lv{1, 2, 3, ...} という名前になります。

    以下に例を示します。
    [lvs]
    CUSTOM_lv1
    CUSTOM_lv2
  • mountpoints

    このセクションは、gdeploy 2.0 で非推奨となりました。gdeploy 2.0 の詳細は [backend-setup] を参照してください。本セクションでは、論理ボリュームのブリックマウントポイントを指定します。マウントポイントの数は、[lvs] で指定した論理ボリュームの数と一致している必要があります。マウントポイントを指定しないと、マウントポイントは /gluster/brick{1, 2, 3…} と名前になります。

    以下に例を示します。
    [mountpoints]
    /rhgs/brick1
    /rhgs/brick2
  • peer

    本セクションでは、Trusted Storage Pool Management (TSP) の設定を指定します。本セクションは、[hosts] セクションで指定されているすべてのホストをプローブして相互にプローブして、信頼できるストレージプールの作成、または信頼済みストレージプールからすべてのホストの割り当てを解除するのに役立ちます。本セクションの唯一のオプションは 'action' です。それらの値はプローブまたはデタッチのいずれかになります。

    以下に例を示します。
    [peer]
    action=probe
  • clients

    本セクションでは、作成した gluster ストレージボリュームをマウントするためにクライアントホストと client_mount_points を指定します。'action' オプションは、フレームワークに対して指定して、実行すべきアクションを決定します。オプションは 'mount' と 'unmount' です。Client hosts フィールドは必須です。マウントポイントを指定しないと、すべてのホストに対して /mnt/gluster としてデフォルトが使用されます。

    fstype オプションは、gluster ボリュームのマウント方法を指定します。デフォルトは glusterfs (FUSE mount) です。ボリュームは NFS としてマウントすることもできます。各クライアントには、異なるタイプのボリュームマウントを設定できます。これはコンマ区切りで指定する必要があります。以下のフィールドが含まれます。
    * action
    * hosts
    * fstype
    * client_mount_points
    以下に例を示します。
    [clients]
    action=mount
    hosts=10.0.0.10
    fstype=nfs
    options=vers=3
    client_mount_points=/mnt/rhs
  • ボリューム

    本セクションでは、ボリュームの設定オプションを指定します。このセクションでは、以下のフィールドが含まれます。

    * action
    * volname
    * transport
    * replica
    * replica_count
    * disperse
    * disperse_count
    * redundancy_count
    * force
    • 動作

      このオプションは、ボリューム内で実行する必要のあるアクションを指定します。選択肢は、[create, delete, add-brick, remove-brick] のようになります。

      create: これはボリュームを作成する場合に使用します。
      delete: delete オプションを使用すると、'volname' 以外のオプションはすべて無視されます。
      add-brick または remove-brick: add-brick または remove-brick が選択された場合は、ブリック名のコンマ区切りリスト (形式: <hostname>:<brick path>) で、追加のオプションブリックを指定します。remove-brick の場合は、state オプションも、ブックの削除後にボリュームの状態を指定する必要もあります。
    • volname

      このオプションは、ボリューム名を指定します。デフォルト名は glustervol です。

      注記
      • ボリュームの操作時、'hosts' セクションは省略できます。ただし、volname は <hostname>:<volname>⁠ の形式になります。hostname はクラスター内のノードのいずれかのホスト名 / IP です。
      • ボリュームの作成/使用/設定のみがサポートされます。
    • transport

      このオプションはトランスポートタイプを指定します。デフォルトは tcp です。オプションは、tcp または rdma (非推奨) または tcp,rdma です。

    • replica

      このオプションは、ボリュームのタイプが replica であるべきかどうかを指定します。オプションは yes と no で、デフォルトは no です。'replica' が yes の場合は、'replica_count' が提供されます。

    • disperse

      このオプションは、ボリュームのタイプが分散すべきかどうかを指定します。オプションは yes と no です。デフォルトは no です。

    • disperse_count

      このフィールドは、’disperse' が yes の場合でも任意です。指定しないと、コマンドラインで指定されたブリックの数は disperse_count の値として取得されます。

    • redundancy_count

      この値が指定されておらず、'disperse' が yes の場合、デフォルト値は計算され、最適な設定が生成されます。

    • force

      これはオプションのフィールドであり、ボリュームの作成時にボリューム作成を強制するために使用することができます。

    以下に例を示します。
    [volname]
    action=create
    volname=glustervol
    transport=tcp,rdma
    replica=yes
    replica_count=3
    force=yes
  • backend-setup

    gdeploy 2.0 で利用できます。本セクションでは、GlusterFS ボリュームで使用するバックエンドを設定します。複数の backend-setup を実行するには、[backend-setup1], [backend-setup2], ... のようにセクションに番号を付けることで、これらを行うことができます。

    backend-setup セクションは、以下の変数をサポートします。
    • devices: これは gdeploy 1.x の [pvs] セクションを置き換えます。devices 変数は、バックエンドの設定に使用する raw ディスクを一覧表示します。以下に例を示します。
      [backend-setup]
      devices=sda,sdb,sdc
      これは必須フィールドです。
    • dalign:
      Logical Volume Manager は、物理ボリュームの一部を使用してメタデータを格納できます。残りは、データ部分として使用されます。物理ボリュームの作成時に、dalign オプションを使用して、Logical Volume Manager (LVM) 層で I/O を調整します。以下に例を示します。
      [backend-setup]
      devices=sdb,sdc,sdd,sde
      dalign=256k
      JBOD の場合は、256K の調整の値を使用します。ハードウェア RAID の場合は、RAID ストライプユニットのサイズをデータディスクの数で乗算して、調整値を取得する必要があります。RAID 6 設定で 12 個のディスクを使用すると、データディスクの数は 10 になります。その一方で、RAID 10 設定に 12 個ディスクを使用する場合は、データディスクの数は 6 になります。
      以下の例は、ストライプユニットサイズが 128 KiB の RAID 6 設定の 12 個のディスクに適しています。
      [backend-setup]
      devices=sdb,sdc,sdd,sde
      dalign=1280k
      以下の例は、ストライプユニットサイズが 256 KiB の RAID 10 設定の 12 個のディスクに適しています。
      [backend-setup]
      devices=sdb,sdc,sdd,sde
      dalign=1536k
      dalign オプションに以前に設定した物理ボリューム設定を表示するには、pvs -o +pe_start device コマンドを実行します。以下に例を示します。
      # pvs -o +pe_start /dev/sdb
      PV         VG   Fmt  Attr PSize PFree 1st PE
      /dev/sdb        lvm2 a--  9.09t 9.09t   1.25m
      PV セクションに dalign オプションを設定することもできます。
    • vgs: これは任意の変数です。この変数は、gdeploy 1.x の [vgs] セクションを置き換えます。vgs 変数には、ボリュームグループの作成時に使用される名前の一覧が表示されます。VG 名の数は、デバイス数と一致するか、空欄にする必要があります。gdeploy は、ボリュームグループの名前を生成します。以下に例を示します。
      [backend-setup]
      devices=sda,sdb,sdc
      vgs=custom_vg1,custom_vg2,custom_vg3
      custom_vg{1..3} などの vg には、パターンを 3 つ作成できます。
      [backend-setup]
      devices=sda,sdb,sdc
      vgs=custom_vg{1..3}
    • pool: これは任意の変数です。変数は、gdeploy 1.x の [pools] セクションに代わるものです。プールは、ボリュームのシンプール名を一覧表示します。
      [backend-setup]
      devices=sda,sdb,sdc
      vgs=custom_vg1,custom_vg2,custom_vg3
      pools=custom_pool1,custom_pool2,custom_pool3
      vg と同様に、シンプール名用にパターンを指定できます。例: custom_pool{1..3}
    • lvs: これは任意の変数です。この変数は、gdeploy 1.x の [lvs] セクションに代わるものです。lvs は、ボリュームの論理ボリューム名を一覧表示します。
      [backend-setup]
      devices=sda,sdb,sdc
      vgs=custom_vg1,custom_vg2,custom_vg3
      pools=custom_pool1,custom_pool2,custom_pool3
      lvs=custom_lv1,custom_lv2,custom_lv3
      LV のパターンは、vg と同様に利用できます。例: custom_lv{1..3}
    • mountpoints: この変数は、gdeploy 1.x の [mountpoints] セクションを非推奨にします。マウントポイントは、論理ボリュームをマウントする必要のあるマウントポイントを一覧表示します。マウントポイントの数は、論理ボリュームの数と同じでなければなりません。以下に例を示します。
      [backend-setup]
      devices=sda,sdb,sdc
      vgs=custom_vg1,custom_vg2,custom_vg3
      pools=custom_pool1,custom_pool2,custom_pool3
      lvs=custom_lv1,custom_lv2,custom_lv3
      mountpoints=/gluster/data1,/gluster/data2,/gluster/data3
    • SSD: キャッシュを追加する必要がある場合には、この変数が設定されます。たとえば、キャッシュ用に ssd を使用したバックアップ設定は以下のようになります。
      [backend-setup]
      ssd=sdc
      vgs=RHS_vg1
      datalv=lv_data
      cachedatalv=lv_cachedata:1G
      cachemetalv=lv_cachemeta:230G
      注記
      SSD の追加中にデータ LV の名前を指定する必要があります。datalv がすでに作成されていることを確認します。それ以外の場合は、以前の `backend-setup’ セクションのいずれかにこれを作成するようにしてください。
  • PV

    gdeploy 2.0 で利用できます。ユーザーがバックエンドのセットアップに対する制御を強化し、backend-setup セクションを使用しない場合は、pv、vg、および lv モジュールが使用されます。pv モジュールは、以下の変数をサポートします。

    • action: 必須'create' と 'resize' の 2 つの値をサポートします。
      例: 物理ボリュームの作成
      [pv]
      action=create
      devices=vdb,vdc,vdd
      例: 特定のホストでの物理ボリュームの作成
      [pv:10.0.5.2]
      action=create
      devices=vdb,vdc,vdd
    • devices: 必須pv の作成に使用するデバイスの一覧。
    • expand: action=resize の場合に使用します。
      例: すでに作成した pv の拡張
      [pv]
      action=resize
      devices=vdb
      expand=yes
    • shrink: action=resize の場合に使用します。
      例: すでに作成された pv の縮小
      [pv]
      action=resize
      devices=vdb
      shrink=100G
    • dalign:
      Logical Volume Manager は、物理ボリュームの一部を使用してメタデータを格納できます。残りは、データ部分として使用されます。物理ボリュームの作成時に、dalign オプションを使用して、Logical Volume Manager (LVM) 層で I/O を調整します。以下に例を示します。
      [pv]
      action=create
      devices=sdb,sdc,sdd,sde
      dalign=256k
      JBOD の場合は、256K の調整の値を使用します。ハードウェア RAID の場合は、RAID ストライプユニットのサイズをデータディスクの数で乗算して、調整値を取得する必要があります。RAID 6 設定で 12 個のディスクを使用すると、データディスクの数は 10 になります。その一方で、RAID 10 設定に 12 個ディスクを使用する場合は、データディスクの数は 6 になります。
      以下の例は、ストライプユニットサイズが 128 KiB の RAID 6 設定の 12 個のディスクに適しています。
      [pv]
      action=create
      devices=sdb,sdc,sdd,sde
      dalign=1280k
      以下の例は、ストライプユニットサイズが 256 KiB の RAID 10 設定の 12 個のディスクに適しています。
      [pv]
      action=create
      devices=sdb,sdc,sdd,sde
      dalign=1536k
      dalign オプションに以前に設定した物理ボリューム設定を表示するには、pvs -o +pe_start device コマンドを実行します。以下に例を示します。
      # pvs -o +pe_start /dev/sdb
      PV         VG   Fmt  Attr PSize PFree 1st PE
      /dev/sdb        lvm2 a--  9.09t 9.09t   1.25m
      backend-setup セクションで dalign オプションを設定することもできます。
  • VG

    gdeploy 2.0 で利用できます。このモジュールは、ボリュームグループの作成および拡張に使用されます。vg モジュールは、以下の変数に対応します。

    • action - 作成または拡張のいずれかになります。
    • pvname - ボリュームの作成に使用する PV。複数の PV にはコンマ区切りの値を使用します。
    • vgname - vg の名前。名前が指定されない場合は、GLUSTER_vg がデフォルト名として使用されます。
    • 1 対 1 - yes に設定すると、pv と vg の間で 1 対 1 のマッピングが行われます。
    action を extend に設定すると、vg は指定した pv を組み込むように拡張されます。
    例 1: 2 つの PV を持つ images_vg という名前の vg を作成します。
    [vg]
    action=create
    vgname=images_vg
    pvname=sdb,sdc
    例 2: 2 つの PV を持つ rhgs_vg1 および rhgs_vg2 という名前の 2 つの vgs を作成します。
    [vg]
    action=create
    vgname=rhgs_vg
    pvname=sdb,sdc
    one-to-one=yes
    例 3: 指定したディスクを持つ既存の vg を拡張します。
    [vg]
    action=extend
    vgname=rhgs_images
    pvname=sdc
  • LV

    gdeploy 2.0 で利用できます。このモジュールは、論理ボリュームの作成、セットアップキャッシュ、変換に使用されます。lv モジュールは、以下の変数に対応します。

    action: アクション変数では、'create'、'setup-cache'、'convert'、および 'change' の 3 つの値を使用できます。アクションが ’create’ の場合は、以下のオプションがサポートされます。
    • lvname: 論理ボリュームの名前。これは任意のフィールドです。デフォルトは GLUSTER_lv です。
    • POOLNAME: thinpool ボリューム名。これは任意のフィールドです。デフォルトは GLUSTER_pool です。
    • lvtype: 作成する論理ボリュームのタイプ。許可される値は ’thin’ および ’thick’ です。これはオプションのフィールドで、デフォルトはシックです。
    • サイズ: 論理ボリュームのサイズデフォルトでは、vg で利用可能な領域をすべて取ります。
    • extent: エクステントサイズ、デフォルトは 100%FREE
    • force: lv create を強制し、質問は行いません。使用できる値は ’yes’、'no' です。これは任意のフィールドで、デフォルトは yes です。
    • vgname: 使用するボリュームグループの名前。
    • pvname: 使用する物理ボリュームの名前。
    • chunksize: スナップショット、キャッシュプール、およびシンプールに使用されるチャンクユニットのサイズ。デフォルトでは、これはキロバイト単位で指定されます。RAID 5 および 6 ボリュームの場合は、gdeploy は、ストライプサイズとディスク数を掛けてデフォルトのチャンクサイズを計算します。RAID 10 の場合、デフォルトのチャンクサイズは 256 KB です。詳細は、「ブリック設定」 を参照してください。
      警告
      Red Hat では、少なくともデフォルトのチャンクサイズを使用することを推奨しています。チャンクサイズが小さすぎて、ボリュームのメタデータの容量が不足すると、ボリュームはデータを作成できません。これには、メタデータプールのサイズを増やすか、メタデータ領域が不足しているボリュームからデータを移行するために必要なデータが含まれます。Red Hat は、論理ボリュームをモニタリングして、メタデータボリュームが完全に満杯になる前に、拡張またはストレージが作成されるようにすることを推奨します。
    • poolmetadatasize: プールのメタデータ論理ボリュームのサイズを設定します。可能な場合は、最大チャンクサイズ (16 GiB) を割り当てます。最大数未満に割り当てる場合は、プールサイズの 0.5% を割り当て、メタデータ領域が不足しないようにします。
      警告
      メタデータプールの容量が不足すると、データを作成できません。これには、メタデータプールのサイズを増やすか、メタデータ領域が不足しているボリュームからデータを移行するために必要なデータが含まれます。lvs -o+metadata_percent コマンドを使用してメタデータプールを監視し、領域が不足しないようにします。
    • Virtualsize: シンプロビジョニングされたデバイスまたは指定のサイズでスパースデバイスを作成します。
    • mkfs: 指定のタイプのファイルシステムを作成します。デフォルトは xfs を使用します。
    • mkfs-opts: mkfs のオプション。
    • mount: 論理ボリュームをマウントします。
    アクションが setup-cache の場合、以下のオプションがサポートされます。
    • SSD: ssd デバイスの名前。たとえば、キャッシュを設定する sda/vda/…。
    • vgname: ボリュームグループの名前。
    • pookname: プールの名前。
    • cache_meta_lv: dm-cache (カーネルドライバー) からの要件により、LVM はさらにキャッシュプール LV を 2 つのデバイス (キャッシュデータ LV およびキャッシュメタデータ LV) に分割します。ここで cache_meta_lv 名を指定します。
    • cache_meta_lvsize: キャッシュメタ LV のサイズ
    • cache_lv: キャッシュデータ lv の名前。
    • cache_lvsize: キャッシュデータのサイズ
    • force: 強制
    action が convert の場合は、以下のオプションがサポートされます。
    • lvtype: lv タイプ。使用できるオプションは thin および sibling です。
    • force: lvconvert を強制。デフォルトは yes です。
    • vgname: ボリュームグループの名前。
    • poolmetadata: キャッシュまたはシンプールメタデータ論理ボリュームを指定します。
    • cachemode: 許可される値 writeback、writethrough。デフォルトは writethrough です。
    • cachepool: 論理ボリュームをキャッシュ LV に変換する際に、この引数が必要です。cachepool の名前。
    • lvname: 論理ボリュームの名前。
    • chunksize: スナップショット、キャッシュプール、およびシンプールに使用されるチャンクユニットのサイズ。デフォルトでは、これはキロバイト単位で指定されます。RAID 5 および 6 ボリュームの場合は、gdeploy は、ストライプサイズとディスク数を掛けてデフォルトのチャンクサイズを計算します。RAID 10 の場合、デフォルトのチャンクサイズは 256 KB です。詳細は、「ブリック設定」 を参照してください。
      警告
      Red Hat では、少なくともデフォルトのチャンクサイズを使用することを推奨しています。チャンクサイズが小さすぎて、ボリュームのメタデータの容量が不足すると、ボリュームはデータを作成できません。Red Hat は、論理ボリュームをモニタリングして、メタデータボリュームが完全に満杯になる前に、拡張またはストレージが作成されるようにすることを推奨します。
    • poolmetadataspare: プールメタデータの予備の論理ボリュームの作成および保守をコントロールします。この論理ボリュームは、自動プール復旧に使用されます。
    • thinpool: 論理ボリュームをシンプールのデータボリュームに指定または変換します。ボリュームの名前またはパスを指定する必要があります。
    アクションが変更されると、以下のオプションがサポートされます。
    • lvname: 論理ボリュームの名前。
    • vgname: ボリュームグループの名前。
    • zero: シンプールにゼロ化モードを設定します。
    例 1: シン LV の作成
    [lv]
    action=create
    vgname=RHGS_vg1
    poolname=lvthinpool
    lvtype=thinpool
    poolmetadatasize=200MB
    chunksize=1024k
    size=30GB
    例 2: シック LV の作成
    [lv]
    action=create
    vgname=RHGS_vg1
    lvname=engine_lv
    lvtype=thick
    size=10GB
    mount=/rhgs/brick1
    複数の論理ボリュームがある場合は、[lv1], [lv2] … など、LV セクションに番号を付けることで LV を作成できます
  • RH-subscription

    gdeploy 2.0 で利用できます。このモジュールは、リポジトリーのサブスクライブ、サブスクライブ解除、添付、有効化などに使用されます。RH-subscription モジュールでは、以下の変数が許可されます。

    このモジュールは、リポジトリーのサブスクライブ、サブスクライブ解除、添付、有効化などに使用されます。RH-subscription モジュールでは、以下の変数が許可されます。
    アクションが register の場合は、以下のオプションがサポートされます。
    • Username/activationkey: ユーザー名または activationkey。
    • Password/activationkey: パスワードまたはアクティベーションキー
    • auto-attach: true/false
    • pool: プールの名前。
    • repos: サブスクライブします。
    • disable-repos: 無効にする名前を指定します。このオプションを空白のままにすると、すべてのリポジトリーが無効になります。
    • ignore_register_errors: no に設定すると、システム登録に失敗すると gdeploy が終了します。
    • アクションが attach-pool の場合、以下のオプションがサポートされます。
      pool: 割り当てるプール名
      ignore_attach_pool_errors: no に設定すると、attach-pool の失敗時に gdeploy に失敗します。
    • アクションが enable-repos の場合は、以下のオプションがサポートされます。
      repos: サブスクライブするコンマ区切りのリポジトリーの一覧。
      ignore_enable_errors: no に設定すると、enable-repos の失敗時に gdeploy に失敗します。
    • アクションが disable-repos の場合、以下のオプションがサポートされます。
      repos: サブスクライブするコンマ区切りのリポジトリーの一覧。
      ignore_disable_errors: no に設定すると、disable-repos が失敗すると gdeploy に失敗します。
    • action が unregister の場合は、システムの登録が解除されます。
      ignore_unregister_errors: no に設定すると、登録解除に失敗したときに gdeploy に失敗します。
    例 1: Red Hat サブスクリプションネットワークにサブスクライブします。
    [RH-subscription1]
    action=register
    username=qa@redhat.com
    password=<passwd>
    pool=<pool>
    ignore_register_errors=no
    例 2: すべてのリポジトリーを無効にします。
    [RH-subscription2]
    action=disable-repos
    repos=*
    例 3: 一部のリポジトリーの有効化
    [RH-subscription3]
    action=enable-repos
    repos=rhel-7-server-rpms,rh-gluster-3-for-rhel-7-server-rpms,rhel-7-server-rhev-mgmt-agent-rpms
    ignore_enable_errors=no
  • yum

    gdeploy 2.0 で利用できます。このモジュールは、yum モジュールで rpm パッケージのインストールまたは削除に使用され、インストール時にリポジトリーを追加することもできます。

    アクション変数では、'install' と 'remove' の 2 つの値が許可されます。
    アクションをインストールする場合、以下のオプションがサポートされます。
    • packages: インストールするパッケージのコンマ区切りリスト。
    • repos: 追加するリポジトリー。
    • gpgcheck: yes/no の値を指定する必要があります。
    • update: yum 更新を開始する必要があるかどうか。
    action が remove の場合は、1 つのオプションのみを指定する必要があります。
    • remove: 削除するパッケージのコンマ区切りリスト
    たとえば、以下のようになります。
    [yum1]
    action=install
    gpgcheck=no
    # Repos should be an url; eg: http://repo-pointing-glusterfs-builds
    repos=<glusterfs.repo>,<vdsm.repo>
    packages=vdsm,vdsm-gluster,ovirt-hosted-engine-setup,screen,xauth
    update=yes
    特定のホストにパッケージをインストールします。
    [yum2:host1]
    action=install
    gpgcheck=no
    packages=rhevm-appliance
  • シェル

    gdeploy 2.0 で利用できます。このモジュールにより、ユーザーはリモートノードでシェルコマンドを実行できます。

    現在シェルでは、値 execution を持つアクション変数を 1 つ提供します。有効なシェルコマンドを値として持つコマンド変数。
    以下のコマンドは、すべてのノードで vdsm-tool を実行します。
    [shell]
    action=execute
    command=vdsm-tool configure --force
  • update-file

    gdeploy 2.0 で利用可能。update-file モジュールでは、ユーザーはファイルのコピー、ファイルの行の編集、または新しい行をファイルに追加できます。action 変数はコピー、編集、または追加のいずれかになります。

    action 変数が copy に設定されている場合は、以下の変数がサポートされます。
    • src: コピー元のファイルのソースパス。
    • dest: ファイルのコピー先に対するリモートマシンの宛先パス。
    action 変数が edit に設定されている場合は、以下の変数がサポートされます。
    • dest: 編集する必要がある宛先ファイル名
    • replace: 置き換える行に一致する正規表現。
    • line: 置き換える必要があるテキスト。
    アクション変数を追加すると、以下の変数がサポートされます。
    • dest: 行を追加するリモートマシンのファイル。
    • line: ファイルに追加する必要があります。行はファイルの末尾に追加されます。
    例 1: ファイルをリモートマシンにコピーします。
    [update-file]
    action=copy
    src=/tmp/foo.cfg
    例 2: リモートマシンの行を編集します。以下の例では、allowed_hosts の行が allowed_hosts=host.redhat.com に置き換えられます。
    [update-file]
    action=edit
    replace=allowed_hosts
    line=allowed_hosts=host.redhat.com
    例 3: ファイルの末尾に行を追加する
    Red Hat Enterprise Linux 7 の場合
    [update-file]
    action=add
    dest=/etc/ntp.conf
    line=server clock.redhat.com iburst
    Red Hat Enterprise Linux 8 の場合:
    [update-file]
    action=add
    dest=/etc/chrony.conf
    line=server 0.rhel.pool.ntp.org iburst
  • サービス

    gdeploy 2.0 で利用できます。サービスモジュールを使用すると、ユーザーはサービスの起動、停止、再起動、リロード、有効化、または無効化を行うことができます。action 変数は、これらの値を指定します。

    action 変数が start、stop、restart、reload、enable のいずれかに設定されていると、変数 servicename は、開始および停止するサービスなどを指定します。
    • service: 起動するサービスの名前、停止など。
    Red Hat Enterprise Linux 7 の場合
    例: ntp デーモンを有効にして起動します。
    [service1]
    action=enable
    service=ntpd
    [service2]
    action=restart
    service=ntpd
    Red Hat Enterprise Linux 8 の場合:
    例: chrony デーモンを有効にして起動します。
    [service1]
    action=enable
    service=chrony
    [service2]
    action=restart
    service=chrony
  • script

    gdeploy 2.0 で利用可能。script モジュールでは、ユーザーはリモートマシンでスクリプト/バイナリーを実行できます。action 変数は execute に設定されます。ユーザーは、2 つの変数ファイルと引数を指定できます。

    • file: ローカルマシンで実行ファイル。
    • args: 上記のプログラムへの引数。
    例: ’hosts’ セクションに記載されているすべてのリモートノードで disable-multipath.sh を実行します。
    [script]
    action=execute
    file=/usr/share/ansible/gdeploy/scripts/disable-multipath.sh
  • firewalld

    gdeploy 2.0 で利用可能。firewalld モジュールでは、ユーザーはファイアウォールルールを操作することができます。action 変数は 'add' と 'delete' の 2 つの値をサポートします。追加および削除は、以下の変数もサポートします。

    • port/services: ファイアウォールに追加するポートまたはサービス。
    • permanent: エントリーを永続化するかどうか。使用できる値は true/false です。
    • zone: デフォルトゾーンは public です
    以下に例を示します。
    [firewalld]
    action=add
    ports=111/tcp,2049/tcp,54321/tcp,5900/tcp,5900-6923/tcp,5666/tcp,16514/tcp
    services=glusterfs
  • geo-replication

    gdeploy 2.0.2 で利用可能。geo-replication モジュールにより、ユーザーは geo レプリケーションセッション、制御の設定および geo レプリケーションセッションの検証を行うことができます。サポートされる変数を以下に示します。

    • action: ジオレプリケーションセッションに対して実行されるアクション。
      • create: geo レプリケーションセッションを作成します。
      • start: 作成した geo レプリケーションセッションを開始します。
      • stop: 開始した geo レプリケーションセッションを停止します。
      • pause: geo レプリケーションセッションを一時停止するには、次のコマンドを実行します。
      • resume: 一時停止した geo レプリケーションセッションを再開します。
      • delete: geo レプリケーションセッションを削除するには、次のコマンドを実行します。
    • georepuser: 実行されるアクションに使用するユーザー名
      重要
      georepuser 変数を省略すると、ユーザーは root ユーザーであることが想定されます。
    • mastervol: プライマリーボリュームの詳細の形式は以下のとおりです。
      Master_HostName:Master_VolName
    • slavevol: セカンダリーボリュームの詳細の形式は以下のとおりです。
      Slave_HostName:Slave_VolName
    • slavenodes: セカンダリーノードの IP アドレスの形式は以下のとおりです。
      Slave1_IPAddress,Slave2_IPAddress
      重要
      セカンダリー IP アドレスはコンマ (,) で区切る必要があります。
    • force: システムが強制的にアクションを実行するようにします。使用できる値は yes または no です。
    • start: 設定ファイルで指定されたアクションを開始します。使用できる値は yes または no です。デフォルト値は yes です。
    以下に例を示します。
    [geo-replication]
    action=create
    georepuser=testgeorep
    mastervol=10.1.1.29:mastervolume
    slavevol=10.1.1.25:slavevolume
    slavenodes=10.1.1.28,10.1.1.86
    force=yes
    start=yes

5.1.8. gdeploy を使用した NFS Ganesha のデプロイ

gdeploy は、gdeploy バージョン 2.0.2-35 からの Red Hat Gluster Storage 3.5 での NFS Ganesha のデプロイメントおよび設定をサポートしています。
NFS-Ganesha は、NFS プロトコルのユーザー空間ファイルサーバーです。NFS-Ganesha の詳細は、https://access.redhat.com/documentation/ja-jp/red_hat_gluster_storage/3.5/html-single/administration_guide/#nfs_ganeshaを参照してください。

5.1.8.1. 前提条件

以下の前提条件を満たしていることを確認します。

Subscription Manager のサブスクライブ

続行する前に、サブスクリプションマネージャーにサブスクライブして、NFS Ganesha パッケージを取得する必要があります。

以下の詳細を設定ファイルに追加して、サブスクリプションマネージャーにサブスクライブします。
[RH-subscription1]
action=register
username=<user>@redhat.com
password=<password>
pool=<pool-id>
以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

レポジトリーの有効化

必要なリポジトリーを有効にするには、設定ファイルに以下の情報を追加します。

[RH-subscription2]
action=enable-repos
repos=rhel-7-server-rpms,rh-gluster-3-for-rhel-7-server-rpms,rh-gluster-3-nfs-for-rhel-7-server-rpms,rhel-ha-for-rhel-7-server-rpms,rhel-7-server-ansible-2-rpms
以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

ファイアウォールポートの有効化

ファイアウォールポートを有効にするには、設定ファイルに以下の情報を追加します。

[firewalld]
action=add
ports=111/tcp,2049/tcp,54321/tcp,5900/tcp,5900-6923/tcp,5666/tcp,16514/tcp
services=glusterfs,nlm,nfs,rpc-bind,high-availability,mountd,rquota
注記
NFS クライアントの UDP マウントが失敗しないようにするには、gdeploy の [firewalld] セクションにポート 2049/udp を追加します。
以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

必要なパッケージをインストールします。

必要なパッケージをインストールするには、設定ファイルに以下の情報を追加します。

[yum]
action=install
repolist=
gpgcheck=no
update=no
packages=glusterfs-ganesha
以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

5.1.8.2. サポートされるアクション

gdeploy の NFS Ganesha モジュールにより、ユーザーは以下の操作を実行できます。
  • クラスターの作成
  • クラスターの破棄
  • ノードの追加
  • ノードの削除
  • ボリュームのエクスポート
  • ボリュームのエクスポート解除
  • NFS Ganesha 設定の更新

クラスターの作成

このアクションにより、指定のボリューム上に最新の NFS-Ganesha の設定が作成されます。このアクションでは、設定ファイルの nfs-ganesha が以下の変数に対応します。

  • ha-name: これは任意の変数です。デフォルトでは ganesha-ha-360 です。
  • cluster-nodes: これは必須の引数です。この変数は、クラスターを構成するために使用されるクラスターノード名のコンマ区切り値を想定します。
  • vip: これは必須引数です。この変数は、IP アドレスのコンマ区切りリストが必要です。これらは仮想 IP アドレスになります。
  • volname: これは、設定で [volume] セクションが含まれている場合に任意の変数です。
たとえば、NFS-Ganesha クラスターを作成するには、設定ファイルに以下の情報を追加します。
[hosts]
host-1.example.com
host-2.example.com
host-3.example.com
host-4.example.com

[backend-setup]
devices=/dev/vdb
vgs=vg1
pools=pool1
lvs=lv1
mountpoints=/mnt/brick

[firewalld]
action=add
ports=111/tcp,2049/tcp,54321/tcp,5900/tcp,5900-6923/tcp,5666/tcp,16514/tcp,662/tcp,662/udp
services=glusterfs,nlm,nfs,rpc-bind,high-availability,mountd,rquota

[volume]
action=create
volname=ganesha
transport=tcp
replica_count=3
force=yes

#Creating a high availability cluster and exporting the volume
[nfs-ganesha]
action=create-cluster
ha-name=ganesha-ha-360
cluster-nodes=host-1.example.com,host-2.example.com,host-3.example.com,host-4   .example.com
vip=10.70.44.121,10.70.44.122
volname=ganesha
ignore_ganesha_errors=no
上記の例では、必要なパッケージがインストールされ、ボリュームが作成され、NFS-Ganesha が有効化されていることを前提とします。
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf

クラスターの破棄

このアクションの destroy-cluster クラスターは、NFS Ganesha を無効にします。これにより、1 つの変数 cluster-nodes が許可されます。

たとえば、NFS-Ganesha クラスターを破棄するには、設定ファイルに以下の情報を追加します。
[hosts]
host-1.example.com
host-2.example.com

# To destroy the high availability cluster

[nfs-ganesha]
action=destroy-cluster
cluster-nodes=host-1.example.com,host-2.example.com
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf

ノードの追加

add-node アクションでは、3 つの変数が許可されます。

  • nodes: クラスターに追加する必要のあるコンマ区切りのホスト名の一覧を受け入れます。
  • vip: コンマ区切りの IP アドレスの一覧を受け入れます。
  • cluster_nodes: NFS Ganesha クラスターのコンマ区切りノードの一覧を受け入れます。
たとえば、ノードを追加するには、設定ファイルに以下の情報を追加します。
[hosts]
host-1.example.com
host-2.example.com
host-3.example.com

[peer]
action=probe

[clients]
action=mount
volname=host-3.example.com:gluster_shared_storage
hosts=host-3.example.com
fstype=glusterfs
client_mount_points=/var/run/gluster/shared_storage/


[nfs-ganesha]
action=add-node
nodes=host-3.example.com
cluster_nodes=host-1.example.com,host-2.example.com
vip=10.0.0.33
注記
3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf

ノードの削除

delete-node アクションは nodes という変数を 1 つ取ります。これは、NFS Ganesha クラスターから削除するノードまたはノードをコンマ区切りのリストで指定します。

以下に例を示します。
[hosts]
host-1.example.com
host-2.example.com
host-3.example.com
host-4.example.com

[nfs-ganesha]
action=delete-node
nodes=host-2.example.com

ボリュームのエクスポート

この操作により、ボリュームをエクスポートします。export-volume アクションは 1 つの変数 volname をサポートします。

たとえば、ボリュームをエクスポートするには、設定ファイルに以下の情報を追加します。
[hosts]
host-1.example.com
host-2.example.com

[nfs-ganesha]
action=export-volume
volname=ganesha
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf

ボリュームのエクスポート解除:

この操作により、ボリュームを unexport します。export-volume アクションは 1 つの変数 volname をサポートします。

たとえば、ボリュームのエクスポートを解除するには、設定ファイルに以下の情報を追加します。
[hosts]
host-1.example.com
host-2.example.com

[nfs-ganesha]
action=unexport-volume
volname=ganesha
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf

NFS Ganesha 設定の更新

このアクションにより、config ブロックが設定ファイルに追加/削除され、クラスターで refresh-config を実行します。

アクション refresh-config は以下の変数をサポートします。
  • del-config-lines
  • block-name
  • volname
  • ha-conf-dir
  • update_config_lines
例 1: クライアントブロックを追加して refresh-config を実行するには、設定ファイルに以下の詳細を追加します。
注記
refresh-config クライアントブロックにはいくつかの制限があります。
  • 1 つのクライアントでのみ動作します。
  • ユーザーは設定ブロックから行を削除できません
[hosts]
host1-example.com
host2-example.com

[nfs-ganesha]
action=refresh-config
# Default block name is `client'
block-name=client
config-block=clients = 10.0.0.1;|allow_root_access = true;|access_type = "RO";|Protocols = "2", "3";|anonymous_uid = 1440;|anonymous_gid = 72;
volname=ganesha
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf
例 2: 行を削除し、refresh-config を実行するには、設定ファイルに以下の詳細を追加します。
[hosts]
host1-example.com
host2-example.com


[nfs-ganesha]
action=refresh-config
del-config-lines=client
volname=ganesha
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf
例 3: ボリュームで refresh-config を実行するには、設定ファイルに以下の情報を追加します。
[hosts]
host1-example.com
host2-example.com


[nfs-ganesha]
action=refresh-config
volname=ganesha
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf
例 4: 行を変更し、refresh-config を実行するには、設定ファイルに以下の詳細を追加します。
[hosts]
host1-example.com
host2-example.com


[nfs-ganesha]
action=refresh-config
update_config_lines=Access_type = "RO";
#update_config_lines=Protocols = "4";
#update_config_lines=clients = 10.0.0.1;
volname=ganesha
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf

5.1.9. gdeploy を使用した Samba / CTDB のデプロイ

サーバーメッセージブロック (SMB) プロトコルを使用して、サーバー上の SMB 共有として GlusterFS ボリュームにディレクトリーをエクスポートすることで、Red Hat Gluster Storage ボリュームにアクセスできます。Red Hat Gluster Storage では、Samba は SMB プロトコルを使用してボリュームを共有するために使用されます。

5.1.9.1. 前提条件

以下の前提条件を満たしていることを確認します。

Subscription Manager のサブスクライブ

サブスクリプションマネージャーにサブスクライブし、Samba パッケージを取得してから詳細に進む必要があります。

以下の詳細を設定ファイルに追加して、サブスクリプションマネージャーにサブスクライブします。
[RH-subscription1]
action=register
username=<user>@redhat.com
password=<password>
pool=<pool-id>
以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

レポジトリーの有効化

必要なリポジトリーを有効にするには、設定ファイルに以下の情報を追加します。

Red Hat Enterprise Linux 7
[RH-subscription2]
action=enable-repos
repos=rhel-7-server-rpms,rh-gluster-3-for-rhel-7-server-rpms,rh-gluster-3-samba-for-rhel-7-server-rpms,rhel-7-server-ansible-2-rpms
Red Hat Enterprise Linux 8
[RH-subscription2]
action=enable-repos
rh-gluster-3-for-rhel-8-x86_64-rpms,ansible-2-for-rhel-8-x86_64-rpms,rhel-8-for-x86_64-baseos-rpms,rhel-8-for-x86_64-appstream-rpms,rhel-8-for-x86_64-highavailability-rpms,rh-gluster-3-samba-for-rhel-8-x86_64-rpms
以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

ファイアウォールポートの有効化

ファイアウォールポートを有効にするには、設定ファイルに以下の情報を追加します。

[firewalld]
action=add
ports=54321/tcp,5900/tcp,5900-6923/tcp,5666/tcp,4379/tcp
services=glusterfs,samba,high-availability
以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

必要なパッケージをインストールします。

必要なパッケージをインストールするには、設定ファイルに以下の情報を追加します。

[yum]
action=install
repolist=
gpgcheck=no
update=no
packages=samba,samba-client,glusterfs-server,ctdb
以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

5.1.9.2. Samba の設定

Samba は、以下の 2 つの方法で有効にできます。
  • 既存のボリュームでの Samba の有効化
  • ボリューム作成時の Samba の有効化

既存のボリュームでの Samba の有効化

Red Hat Gluster Storage ボリュームがすでに存在する場合は、ユーザーはそのアクションを volume セクションで smb-setup として指定する必要があります。gdeploy は各ホストの glusterd 設定ファイルを更新するため、クラスター内のすべてのホストについて言及する必要があります。

たとえば、既存のボリュームで Samba を有効にするには、設定ファイルに以下の情報を追加します。
[hosts]
10.70.37.192
10.70.37.88

[volume]
action=smb-setup
volname=samba1
force=yes
smb_username=smbuser
smb_mountpoint=/mnt/smb
注記
ホストが CTDB クラスターに含まれていないことを確認します。
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf

ボリューム作成時の Samba の有効化

ボリュームの作成時に Samba を設定している場合は、設定ファイルで smb 変数を yes に設定する必要があります。

たとえば、ボリュームの作成時に Samba を有効にするには、設定ファイルに以下の情報を追加します。
[hosts]
10.70.37.192
10.70.37.88
10.70.37.65

[backend-setup]
devices=/dev/vdb
vgs=vg1
pools=pool1
lvs=lv1
mountpoints=/mnt/brick

[volume]
action=create
volname=samba1
smb=yes
force=yes
smb_username=smbuser
smb_mountpoint=/mnt/smb
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf
注記
Samba を有効にする場合の両方で、samba に acls を正しく設定する必要がある場合には、smb_usernamesmb_mountpoint が必要です。

5.1.9.3. CTDB の設定

CTDB を使用するには、CTDB ロックファイルを保護するために、別のボリュームを設定する必要があります。Red Hat は、レプリカ数が Samba サーバーとして使用されるサーバー数と同じになる複製ボリュームを推奨しています。
以下の設定ファイルは、Samba サーバーでもある 2 つのホストに CTDB ボリュームを設定します。
[hosts]
10.70.37.192
10.70.37.88
10.70.37.65

[volume]
action=create
volname=ctdb
transport=tcp
replica_count=3
force=yes

[ctdb]
action=setup
public_address=10.70.37.6/24 eth0,10.70.37.8/24 eth0
volname=ctdb
以下の例のように ctdb_nodes パラメーターを使用して、CTDB クラスターを別の IP アドレスを使用するように設定できます。
[hosts]
10.70.37.192
10.70.37.88
10.70.37.65

[volume]
action=create
volname=ctdb
transport=tcp
replica_count=3
force=yes

[ctdb]
action=setup
public_address=10.70.37.6/24 eth0,10.70.37.8/24 eth0
ctdb_nodes=192.168.1.1,192.168.2.5
volname=ctdb
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf

5.1.10. ボリュームでの SSL の有効化

SSL が有効なボリュームを作成するか、gdeploy (v2.0.1) を使用して既存ボリュームで SSL を有効にすることができます。本セクションでは、SSL を有効にするために gdeploy 用に設定ファイルを書き込む方法を説明します。

5.1.10.1. ボリュームの作成および SSL の有効化

ボリュームを作成して SSL を有効にするには、設定ファイルに以下の情報を追加します。
[hosts]
10.70.37.147
10.70.37.47
10.70.37.13

[backend-setup]
devices=/dev/vdb
vgs=vg1
pools=pool1
lvs=lv1
mountpoints=/mnt/brick

[volume]
action=create
volname=vol1
transport=tcp
replica_count=3
force=yes
enable_ssl=yes
ssl_clients=10.70.37.107,10.70.37.173
brick_dirs=/data/1

[clients]
action=mount
hosts=10.70.37.173,10.70.37.107
volname=vol1
fstype=glusterfs
client_mount_points=/mnt/data
上記の例では、vol1 という名前のボリュームが作成され、SSL がこのファイルで有効になっています。gdeploy は自己署名証明書を作成します。
設定ファイルに詳細を追加したら、以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

5.1.10.2. 既存のボリュームで SSL を有効にする場合:

既存のボリュームで SSL を有効にするには、設定ファイルに以下の情報を追加します。
[hosts]
10.70.37.147
10.70.37.47

# It is important for the clients to be unmounted before setting up SSL
[clients1]
action=unmount
hosts=10.70.37.173,10.70.37.107
client_mount_points=/mnt/data

[volume]
action=enable-ssl
volname=vol2
ssl_clients=10.70.37.107,10.70.37.173

[clients2]
action=mount
hosts=10.70.37.173,10.70.37.107
volname=vol2
fstype=glusterfs
client_mount_points=/mnt/data
設定ファイルに詳細を追加したら、以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

5.1.11. Gdeploy ログファイル

gdeploy は通常、権限のないユーザーによって実行されるため、デフォルトでは gdeploy ログファイルは /var/log ディレクトリーではなく /home/username/.gdeploy/logs/gdeploy.log に書き込まれます。
ログの場所を変更するには、GDEPLOY_LOGFILE 環境変数の値として別の場所を設定します。たとえば、このセッションで gdeploy ログの場所を /var/log/gdeploy/gdeploy.log に設定するには、以下のコマンドを実行します。
$ export GDEPLOY_LOGFILE=/var/log/gdeploy/gdeploy.log
これを永続的に設定するには、そのユーザーの /home/username/.bash_profile ファイルの別の行と同じコマンドを追加します。