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

• [backend-setup] モジュールの使用
• 物理ボリューム (PV)、ボリュームグループ (VG)、および論理ボリューム (LV) の個別作成

• [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

• /rhgs ファイルシステムが利用できないと、システム内で利用可能な /rhgs/brick1 ディレクトリーがなくなりました。したがって、別の場所に書き込むことでデータ損失は発生しません。
• これには、ネスト化に追加のファイルシステムは必要ありません。

• 複数の Arbitrated Replicated ボリュームをチェーンします。これは、別のボリュームのデータブリックと同じノードの 1 つのボリュームに対して arbiter ブリックを配置して行います。チェーンは、メタデータのファイルサイズ (32 - 128 KiB から) に近くなる場合に書き込み負荷に便利です。これにより、1 つのディスクを経由するすべてのメタデータ I/O が回避されます。
  判別分散複製ボリュームでは、arbiter ブックを、別のレプリカサブボリュームのデータブリックと同じノードに配置することもできます。これらは同じデータを共有しないためです。
• 1 つの専用ノードで、複数のボリュームから arbiter ブリックを配置します。専用の arbiter ノードは、大きなファイルを使用した書き込みの高ワークロードおよび読み取りの高ワークロードに適しています。

• 専用の判別ノードの場合は、arbiter ブリックに JBOD を、データブリックには RAID6 を使用します。
• チェーンの arbiter ボリュームの場合は、データおよび判別ブリックの両方に同じ RAID6 ドライブを使用します。

• コマンドラインを使用した、システムの Red Hat Subscription Management への登録およびサブスクライブ
• Web Interface を使用した、システムの Red Hat Subscription Management への登録およびサブスクライブ

• 「ボリュームの手動マウント」
• 「ボリュームの自動マウント」
• 「Native Client を使用したサブディレクトリーの手動マウント」

• nfs.acl ON を設定するには、以下のコマンドを実行します。

  # gluster volume set VOLNAME nfs.acl on

• nfs.acl OFF を設定するには、以下のコマンドを実行します。

  # gluster volume set VOLNAME nfs.acl off

• 「Gluster NFS 用の CTDB の設定 (非推奨) 」
  • 「前提条件」
  • 「Gluster NFS のポートおよびファイアウォール情報」
  • 「Red Hat Gluster Storage サーバーでの CTDB の設定」
• 「Gluster NFS を使用した Red Hat Gluster Storage ボリュームのマウント (非推奨)」
  • 「Gluster NFS を使用したボリュームの手動マウント (非推奨)」
  • 「Gluster NFS を使用したボリュームの自動マウント (非推奨)」
  • 「NFS を使用したサブディレクトリーの自動マウント (非推奨)」
  • 「Gluster NFS を使用したマウントしたボリュームのテスト (非推奨)」
• 「Gluster NFS のトラブルシューティング (非推奨)」

• 「NFS-Ganesha のサポートされる機能」
• 「NFS Ganesha の設定」
  • 「NFS-Ganesha のポートおよびファイアウォール情報」
  • 「NFS-Ganesha を実行するための前提条件」
  • 「クラスターサービスの設定」
  • 「ganesha-ha.conf ファイルの作成」
  • 「Gluster CLI を使用した NFS-Ganesha の設定」
  • 「NFS-Ganesha を使用したボリュームのエクスポートとエクスポート解除」
  • 「NFS-Ganesha ステータスの確認」
• 「NFS-Ganesha エクスポートへのアクセス」
  • 「NFSv3 モードでのエクスポートのマウント」
  • 「NFSv4 モードでのエクスポートのマウント」
  • 「dbus での NFS サーバーのクライアントの検索」
  • 「 dbus を使用して NFS サーバーから認可されたクライアントリストおよびその他の情報の検索」
• 「NFS-Ganesha HA 設定の変更」
  • 「ノードのクラスターへの追加」
  • 「クラスター内のノードの削除」
  • 「クラスター内のノードの置き換え」
• 「デフォルトのエクスポート設定の変更」
  • 「特定クライアントのパーミッションの提供」
  • 「NFSv4 ACL の有効化および無効化 」
  • 「NFSv4 マウントに疑似パスを提供」
  • 「サブディレクトリーのエクスポート」
  • 「サブディレクトリーのエクスポート」
• 「Kerberized NFS-Ganesha の設定」
  • 「NFS-Ganesha サーバーの設定」
  • 「NFS クライアントの設定」
• 「NFS-Ganesha サービスがダウンタイム」
  • 「フェイルオーバー時間の変更」
• 「NFS Ganesha のトラブルシューティング」

• Samba は、Red Hat Gluster Storage で SMB プロトコルのサポートと相互運用性を維持するために必要です。また、SMB を使用して複製したボリュームを共有する場合は、CTDB が必要です。SMB サポートの正しいチャンネルへのサブスクライブ情報は、『Red Hat Gluster Storage 3.5 Installation Guide』 の Subscribing to the Red Hat Gluster Storage server channels を参照してください。
• ランタイムおよび永続モードのアクティブなゾーンで Samba ファイアウォールサービスを有効にします。以下のコマンドは、Red Hat Enterprise Linux 7 をベースとするシステムを対象にしています。
  アクティブゾーンの一覧を取得するには、以下のコマンドを実行します。

  # firewall-cmd --get-active-zones

  アクティブなゾーンでファイアウォールサービスを許可するには、次のコマンドを実行します。

  # firewall-cmd --zone=zone_name --add-service=samba
  # firewall-cmd --zone=zone_name --add-service=samba  --permanent

前提条件

• 古いバージョンの CTDB (バージョン <= ctdb1.x) がすでにある場合は、以下のコマンドを実行して CTDB を削除します。

  # yum remove ctdb

  古いバージョンを削除したら、最新の CTDB のインストールに進みます。
  注記

  最新の CTDB パッケージを取得するには、システムが samba チャンネルにサブスクライブしていることを確認してください。
• 以下のコマンドを実行して、Samba サーバーとして使用されるすべてのノードに CTDB をインストールします。

  # yum install ctdb

• Samba の CTDB ベースの高可用性環境では、ロックはフェイルオーバー時に移行されません。
• ランタイムおよび永続モードのアクティブなゾーンで CTDB ファイアウォールサービスを有効にします。以下のコマンドは、Red Hat Enterprise Linux 7 をベースとするシステムを対象にしています。
  アクティブゾーンの一覧を取得するには、以下のコマンドを実行します。

  # firewall-cmd --get-active-zones

  アクティブゾーンにポートを追加するには、次のコマンドを実行します。

  # firewall-cmd --zone=zone_name --add-port=4379/tcp
  # firewall-cmd --zone=zone_name --add-port=4379/tcp  --permanent

ベストプラクティス

• CTDB には、Gluster 内部ネットワークとは異なるブロードキャストドメインが必要です。Samba でエクスポートされた Gluster ボリュームにアクセスするために Windows クライアントが使用するネットワークは、内部の Gluster ネットワークとは異なります。これを実行できないと、ノード間に CTDB のフェイルオーバーがある場合や、Windows のファイル共有にアクセスするパフォーマンスが低下した場合に多すぎる可能性があります。
  たとえば、CTDB がネットワーク 192.168.10.X で実行されている誤った設定例を以下に示します。

  Status of volume: ctdb
  Gluster process                             TCP Port  RDMA Port  Online  Pid
  Brick node1:/rhgs/ctdb/b1                   49157     0          Y       30439
  Brick node2:/rhgs/ctdb/b1                   49157     0          Y       3827
  Brick node3:/rhgs/ctdb/b1                   49157     0          Y       89421
  Self-heal Daemon on localhost                N/A      N/A        Y       183026
  Self-heal Daemon on sesdel0207               N/A      N/A        Y       44245
  Self-heal Daemon on segotl4158               N/A      N/A        Y       110627
  
  cat ctdb_listnodes
  
  192.168.10.1
  192.168.10.2
  
  cat ctdb_ip
  Public IPs on node 0
  192.168.10.3 0
  

  注記

  ホスト名 node1、node2、および node3 は、ブリックを設定し、同じネットワーク 192.168.10.X の IP を解決するために使用されます。Windows クライアントは内部 Gluster ネットワークを使用してファイル共有にアクセスしているため、これは当てはまらないはずです。
• また、CTDB ネットワークと Gluster 内部ネットワークは、別の物理インターフェースで実行する必要があります。Red Hat では、パフォーマンスを向上させるために 10GbE インターフェースを推奨します。
• Gluster ネットワークおよび CTDB ネットワークに同じネットワーク帯域幅を使用することが推奨されます。異なるネットワーク速度を使用すると、パフォーマンスのボトルネックが生じる可能性があります。内部ネットワークと外部ネットワークの両方で同じネットワークトラフィックが予想されます。

• メタデータキャッシングを有効にして、Red Hat Gluster Storage ボリュームの SMB アクセスのパフォーマンスを改善します。
• ディレクトリーリスティングのパフォーマンスの強化
• ファイル/ディレクトリー作成パフォーマンスの強化