第5章 ストレージボリュームの設定
ボリュームタイプ
- Distributed (分散)
- ファイルをボリューム内のブリックに分散します。スケーリングと冗長性の要件が重要ではないか、他のハードウェアやソフトウェア層により提供されるこのボリュームタイプを使用します。このボリュームタイプの補足情報は、「分散ボリュームの作成」 を参照してください。
- Replicated (レプリケート)
- ボリューム内のブリック間でファイルを複製します。高い可用性と信頼性が重要である環境では、このボリュームタイプを使用します。このボリュームタイプの補足情報は、「複製ボリュームの作成」 を参照してください。
- Distributed Replicated
- ファイルをボリューム内の複製されたブリックに分散します。高い信頼性と柔軟性が重要である環境では、このボリュームタイプを使用します。このボリュームタイプは、多くの環境で読み取りパフォーマンスが向上します。このボリュームタイプの補足情報は、「分散複製ボリュームの作成」 を参照してください。
- Arbitrated Replicated
- レプリカセットの 2 つのブリックでファイルを複製し、メタデータのみを 3 番目のブリックに複製します。一貫性が重要な環境でこのボリュームタイプを使用しますが、ベースとなるストレージ領域は非常に貴重です。このボリュームタイプの補足情報は、「Arbitrated Replicated ボリュームの作成」 を参照してください。
- Dispersed
- ボリュームのブリック全体でファイルのデータを分散します。無駄にする領域を最小元に抑える、信頼性の設定可能なレベルが必要なこのボリュームタイプを使用します。このボリュームタイプの補足情報は、「分散ボリュームの作成」 を参照してください。
- Distributed Dispersed
- 分散するサブボリューム全体でファイルのデータを分散します。無駄にする領域を最小元に抑える、信頼性の設定可能なレベルが必要なこのボリュームタイプを使用します。このボリュームタイプの補足情報は、「Distributed Dispersed ボリュームの作成」 を参照してください。
5.1. gdeploy を使用した Gluster Storage ボリュームの設定
- 複数のマシンへのバックエンドの設定は、ラップトップ/デスクトップから実行できます。これにより、信頼されているストレージプール内のノード数が増えると、時間が短縮され、スケールアップできるようになります。
- 設定するドライブを選択する柔軟性 (sd、vd、...)
- 論理ボリューム (LV) およびボリュームグループ (VG) の命名に柔軟性がある。
5.1.1. 使い始める
前提条件
- 以下のコマンドを実行して、信頼できるストレージプールの一部であるノードのパスフレーズなしの SSH 鍵を生成します。
# ssh-keygen -t rsa -N ''
- 以下のコマンドを実行して、gdeploy コントローラーとサーバー間のキーベースの SSH 認証アクセスを設定します。
# ssh-copy-id -i root@server
注記Red Hat Gluster Storage ノードを外部ノードではなくデプロイメントノードとして使用する場合は、インストールが実行される Red Hat Gluster Storage ノードにキーベースの SSH 認証を設定する必要があります。 - 以下のコマンドを実行して、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
- 以下のコマンドを実行して、
ansible
をインストールします。# yum install ansible
- 以下のことを確認する必要があります。
- デバイスは raw で未使用である必要があります
- デフォルトのシステムロケールは
en_US
に設定する必要がありますシステムロケールの詳細は、『Red Hat Enterprise Linux 7 システム管理者のガイド』の『システムロケールの設定』を参照してください。 - 複数のデバイスの場合は、
gdeploy
設定ファイルで複数のボリュームグループ、シンプール、および thinvol を使用します。
- 信頼できるストレージプールでのノードの使用
- 信頼できるストレージプールの外部にあるマシンの使用
クラスターでのノードの使用
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』を参照してください。
# yum install gdeploy
gdeploy
のインストールに関する詳細は、『Red Hat Gluster Storage 3.5 Installation Guide』の『Installing Ansible to Support Gdeploy』セクションを参照してください。
5.1.2. 信頼できるストレージプールの設定
/usr/share/doc/gdeploy/examples/gluster.conf.sample
# # 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. バックエンドの設定
/usr/share/doc/gdeploy/examples/gluster.conf.sample
- [backend-setup] モジュールの使用
- 物理ボリューム (PV)、ボリュームグループ (VG)、および論理ボリューム (LV) の個別作成
xfsprogs
パッケージをインストールする必要があります。
5.1.3.1. [backend-setup] モジュールの使用
- 汎用
- 特定
汎用
ディスク名がマシン全体で統一されている場合は、以下のようにバックエンドの設定を作成することができます。'hosts' セクション内のすべてのホストに対して、バックエンドが設定されます。
# # 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 つの設定ファイルでホスト固有の設定を非常に柔軟に実行することができます。
# # 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 のセットアップによるバックエンドの作成
[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
# # 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. ボリュームの作成
/usr/share/doc/gdeploy/examples/gluster.conf.sample
[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
複数のボリュームの作成
[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
[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
5.1.5. クライアントのマウント
/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] 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. 設定ファイル
- [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 がデフォルト設定として取得されます。このフィールドに有効な値は、
raid10
、raid6
、raid5
、jbod
です。以下に例を示します。[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 のデプロイ
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
# gdeploy -c txt.conf
必要なパッケージをインストールします。
必要なパッケージをインストールするには、設定ファイルに以下の情報を追加します。
[yum] action=install repolist= gpgcheck=no update=no packages=glusterfs-ganesha
# gdeploy -c txt.conf
5.1.8.2. サポートされるアクション
- クラスターの作成
- クラスターの破棄
- ノードの追加
- ノードの削除
- ボリュームのエクスポート
- ボリュームのエクスポート解除
- NFS Ganesha 設定の更新
クラスターの作成
このアクションにより、指定のボリューム上に最新の NFS-Ganesha の設定が作成されます。このアクションでは、設定ファイルの nfs-ganesha が以下の変数に対応します。
- ha-name: これは任意の変数です。デフォルトでは ganesha-ha-360 です。
- cluster-nodes: これは必須の引数です。この変数は、クラスターを構成するために使用されるクラスターノード名のコンマ区切り値を想定します。
- vip: これは必須引数です。この変数は、IP アドレスのコンマ区切りリストが必要です。これらは仮想 IP アドレスになります。
- volname: これは、設定で [volume] セクションが含まれている場合に任意の変数です。
[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
# gdeploy -c txt.conf
クラスターの破棄
このアクションの destroy-cluster クラスターは、NFS Ganesha を無効にします。これにより、1 つの変数 cluster-nodes
が許可されます。
[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
# 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
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
[hosts] host1-example.com host2-example.com [nfs-ganesha] action=refresh-config del-config-lines=client volname=ganesha
# gdeploy -c txt.conf
[hosts] host1-example.com host2-example.com [nfs-ganesha] action=refresh-config volname=ganesha
# gdeploy -c txt.conf
[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 のデプロイ
5.1.9.1. 前提条件
Subscription Manager のサブスクライブ
サブスクリプションマネージャーにサブスクライブし、Samba パッケージを取得してから詳細に進む必要があります。
[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-samba-for-rhel-7-server-rpms,rhel-7-server-ansible-2-rpms
[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 の有効化
- ボリューム作成時の Samba の有効化
既存のボリュームでの Samba の有効化
Red Hat Gluster Storage ボリュームがすでに存在する場合は、ユーザーはそのアクションを volume セクションで smb-setup
として指定する必要があります。gdeploy は各ホストの glusterd 設定ファイルを更新するため、クラスター内のすべてのホストについて言及する必要があります。
[hosts] 10.70.37.192 10.70.37.88 [volume] action=smb-setup volname=samba1 force=yes smb_username=smbuser smb_mountpoint=/mnt/smb
# gdeploy -c txt.conf
ボリューム作成時の Samba の有効化
ボリュームの作成時に Samba を設定している場合は、設定ファイルで smb
変数を yes に設定する必要があります。
[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
smb_username
と smb_mountpoint
が必要です。
5.1.9.3. 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 の有効化
5.1.10.1. ボリュームの作成および 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
# gdeploy -c txt.conf
5.1.10.2. 既存のボリュームで 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 ログファイル
/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
ファイルの別の行と同じコマンドを追加します。