手順

1. inventory ファイルの作成

   以下の例を使用して、/etc/ansible/roles/gluster.infra/playbooks ディレクトリーに新しい inventory ファイルを作成します。

   このファイルは、新しいブリックを作成するホストを一覧表示します。

   inventory ファイルの例

   [hosts]
   server4.example.com
   server5.example.com
   server6.example.com

2. bricks.yml 変数ファイルを作成します。

   次の例を使用して、/etc/ansible/roles/gluster.infra/playbooks ディレクトリーに新しい bricks.yml ファイルを作成します。

   このファイルは、各ホストで作成または使用される基礎となるストレージインフラストラクチャーおよび設定を定義します。

   bricks.yml 変数ファイルの例

   # gluster_infra_disktype
   # Set a disk type. Options: JBOD, RAID6, RAID10 - Default: JBOD
   gluster_infra_disktype: RAID10
   
   # gluster_infra_dalign
   # Dataalignment, for JBOD default is 256K if not provided.
   # For RAID{6,10} dataalignment is computed by multiplying
   # gluster_infra_diskcount and gluster_infra_stripe_unit_size.
   gluster_infra_dalign: 256K
   
   # gluster_infra_diskcount
   # Required only for RAID6 and RAID10.
   gluster_infra_diskcount: 10
   
   # gluster_infra_stripe_unit_size
   # Required only in case of RAID6 and RAID10. Stripe unit size always in KiB, do
   # not provide the trailing `K' in the value.
   gluster_infra_stripe_unit_size: 128
   
   # gluster_infra_volume_groups
   # Variables for creating volume group
   gluster_infra_volume_groups:
      - { vgname: 'vg_vdb', pvname: '/dev/vdb' }
      - { vgname: 'vg_vdc', pvname: '/dev/vdc' }
   
   # gluster_infra_thick_lvs
   # Variable for thick lv creation
   gluster_infra_thick_lvs:
     - { vgname: 'vg_vdb', lvname: 'vg_vdb_thicklv1', size: '10G' }
   
   # gluster_infra_thinpools
   # thinpoolname is optional, if not provided `vgname' followed by _thinpool is
   # used for name. poolmetadatasize is optional, default 16G is used
   gluster_infra_thinpools:
     - {vgname: 'vg_vdb', thinpoolname: 'foo_thinpool', thinpoolsize: '10G', poolmetadatasize: '1G' }
     - {vgname: 'vg_vdc', thinpoolname: 'bar_thinpool', thinpoolsize: '20G', poolmetadatasize: '1G' }
   
   # gluster_infra_lv_logicalvols
   # Thinvolumes for the brick. `thinpoolname' is optional, if omitted `vgname'
   # followed by _thinpool is used
   gluster_infra_lv_logicalvols:
      - { vgname: 'vg_vdb', thinpool: 'foo_thinpool', lvname: 'vg_vdb_thinlv', lvsize: '500G' }
      - { vgname: 'vg_vdc', thinpool: 'bar_thinpool', lvname: 'vg_vdc_thinlv', lvsize: '500G' }
   
   # Setting up cache using SSD disks
   gluster_infra_cache_vars:
      - { vgname: 'vg_vdb', cachedisk: '/dev/vdd',
          cachethinpoolname: 'foo_thinpool', cachelvname: 'cachelv',
          cachelvsize: '20G', cachemetalvname: 'cachemeta',
          cachemetalvsize: '100M', cachemode: 'writethrough' }
   
   # gluster_infra_mount_devices
   gluster_infra_mount_devices:
      - { path: '/rhgs/thicklv', vgname: 'vg_vdb', lvname: 'vg_vdb_thicklv1' }
      - { path: '/rhgs/thinlv1', vgname: 'vg_vdb', lvname: 'vg_vdb_thinlv' }
      - { path: '/rhgs/thinlv2', vgname: 'vg_vdc', lvname: 'vg_vdc_thinlv' }

   重要

   path: 定義が /rhgs で開始しない場合、ブリックは管理ポータルによって自動的に検出されません。create_brick.yml Playbook を実行した後にホストストレージを同期し、新しいブリックを管理ポータルに追加します。

3. create_brick.yml Playbook ファイルを作成します。

   以下の例を使用して、/etc/ansible/roles/gluster.infra/playbooks ディレクトリーに新しい create_brick.yml ファイルを作成します。

   このファイルは、gluster.infra ロールと、上記で作成した変数ファイルを使用してブリックを作成する作業を定義します。

   Playbook ファイル create_brick.yml の例

   ---
   - name: Create a GlusterFS brick on the servers
     remote_user: root
     hosts: all
     gather_facts: false
     vars_files:
       - bricks.yml
   
     roles:
       - gluster.infra

4. Playbook を実行します

   /etc/ansible/roles/gluster.infra/playbooks ディレクトリーから以下のコマンドを実行し、inventory と上で定義した変数ファイルを使用して作成した Playbook を実行します。

   # ansible-playbook -i inventory create_brick.yml

5. ブリックが使用可能であることを確認します。

   1. Compute → Hosts をクリックし、ホストを選択します。

   2. Storage Devices をクリックし、新しいブリックのストレージデバイスの一覧を確認します。

      新しいブリックが表示されない場合は、Sync をクリックし、ストレージデバイスの一覧に表示されるまで待機します。

手順

1. inventory ファイルの作成

   以下の例を使用して、/etc/ansible/roles/gluster.infra/playbooks ディレクトリーに新しい inventory ファイルを作成します。

   このファイルは、新しいブリックを作成するホストを一覧表示します。

   inventory ファイルの例

   [hosts]
   server4.example.com
   server5.example.com
   server6.example.com

2. bricks.yml 変数ファイルを作成します。

   次の例を使用して、/etc/ansible/roles/gluster.infra/playbooks ディレクトリーに新しい bricks.yml ファイルを作成します。

   このファイルは、各ホストで作成または使用される基礎となるストレージインフラストラクチャーおよび設定を定義します。

   vdo_bricks.yml 変数ファイルの例

   # gluster_infra_disktype
   # Set a disk type. Options: JBOD, RAID6, RAID10 - Default: JBOD
   gluster_infra_disktype: RAID10
   
   # gluster_infra_dalign
   # Dataalignment, for JBOD default is 256K if not provided.
   # For RAID{6,10} dataalignment is computed by multiplying
   # gluster_infra_diskcount and gluster_infra_stripe_unit_size.
   gluster_infra_dalign: 256K
   
   # gluster_infra_diskcount
   # Required only for RAID6 and RAID10.
   gluster_infra_diskcount: 10
   
   # gluster_infra_stripe_unit_size
   # Required only in case of RAID6 and RAID10. Stripe unit size always in KiB, do
   # not provide the trailing `K' in the value.
   gluster_infra_stripe_unit_size: 128
   
   # VDO creation
   gluster_infra_vdo:
      - { name: 'hc_vdo_1', device: '/dev/vdb' }
      - { name: 'hc_vdo_2', device: '/dev/vdc' }
   
   # gluster_infra_volume_groups
   # Variables for creating volume group
   gluster_infra_volume_groups:
      - { vgname: 'vg_vdb', pvname: '/dev/mapper/hc_vdo_1' }
      - { vgname: 'vg_vdc', pvname: '/dev/mapper/hc_vdo_2' }
   
   # gluster_infra_thick_lvs
   # Variable for thick lv creation
   gluster_infra_thick_lvs:
     - { vgname: 'vg_vdb', lvname: 'vg_vdb_thicklv1', size: '10G' }
   
   # gluster_infra_thinpools
   # thinpoolname is optional, if not provided `vgname' followed by _thinpool is
   # used for name. poolmetadatasize is optional, default 16G is used
   gluster_infra_thinpools:
     - {vgname: 'vg_vdb', thinpoolname: 'foo_thinpool', thinpoolsize: '10G', poolmetadatasize: '1G' }
     - {vgname: 'vg_vdc', thinpoolname: 'bar_thinpool', thinpoolsize: '20G', poolmetadatasize: '1G' }
   
   # gluster_infra_lv_logicalvols
   # Thinvolumes for the brick. `thinpoolname' is optional, if omitted `vgname'
   # followed by _thinpool is used
   gluster_infra_lv_logicalvols:
      - { vgname: 'vg_vdb', thinpool: 'foo_thinpool', lvname: 'vg_vdb_thinlv', lvsize: '500G' }
      - { vgname: 'vg_vdc', thinpool: 'bar_thinpool', lvname: 'vg_vdc_thinlv', lvsize: '500G' }
   
   # gluster_infra_mount_devices
   gluster_infra_mount_devices:
      - { path: '/rhgs/thicklv', vgname: 'vg_vdb', lvname: 'vg_vdb_thicklv1' }
      - { path: '/rhgs/thinlv1', vgname: 'vg_vdb', lvname: 'vg_vdb_thinlv' }
      - { path: '/rhgs/thinlv2', vgname: 'vg_vdc', lvname: 'vg_vdc_thinlv' }

   重要

   path: 定義が /rhgs で開始しない場合、ブリックは管理ポータルによって自動的に検出されません。create_brick.yml Playbook を実行した後にホストストレージを同期し、新しいブリックを管理ポータルに追加します。

3. create_brick.yml Playbook ファイルを作成します。

   以下の例を使用して、/etc/ansible/roles/gluster.infra/playbooks ディレクトリーに新しい create_brick.yml ファイルを作成します。

   このファイルは、gluster.infra ロールと、上記で作成した変数ファイルを使用してブリックを作成する作業を定義します。

   Playbook ファイル create_brick.yml の例

   ---
   - name: Create a GlusterFS brick on the servers
     remote_user: root
     hosts: all
     gather_facts: false
     vars_files:
       - vdo_bricks.yml
   
     roles:
       - gluster.infra

4. Playbook を実行します

   /etc/ansible/roles/gluster.infra/playbooks ディレクトリーから以下のコマンドを実行し、inventory と上で定義した変数ファイルを使用して作成した Playbook を実行します。

   # ansible-playbook -i inventory create_brick.yml

5. ブリックが使用可能であることを確認します。

   1. Compute → Hosts をクリックし、ホストを選択します。

   2. Storage Devices をクリックし、新しいブリックのストレージデバイスの一覧を確認します。

      新しいブリックが表示されない場合は、Sync をクリックし、ストレージデバイスの一覧に表示されるまで待機します。

手順

1. 新規ブリックの作成

   要件に応じて、ansible を使用してブリックを作成する または ansible を使用した VDO レイヤー上のブリックの作成 の手順に従って、ボリュームを拡張するサーバー上にブリックを作成します。

   重要

   定義した path: が /rhgs で始まらない場合、ブリックは管理ポータルによって自動的に検出されません。create_brick.yml Playbook を実行してからホストストレージを同期し、新しいブリックを管理ポータルに同期します。

   1. Compute → Hosts をクリックし、ホストを選択します。
   2. Storage Devices をクリックします。
   3. Sync をクリックします。

   新しいブリックを持つホストごとに繰り返します。

2. ボリュームに新しいブリックを追加する

   1. RHV 管理コンソールにログインします。
   2. Storage → Volumes をクリックし、展開するボリュームを選択します。
   3. Bricks タブをクリックします。
   4. Add をクリックします。Add Bricks ウィンドウが開きます。

   5. 新しいブリックを追加します。

      1. Host ドロップダウンメニューからブリックホストを選択します。
      2. Brick Directory ドロップダウンメニューから追加するブリックを選択し、Add をクリックします。
   6. すべてのブリックがリストされたら、OK をクリックしてボリュームにブリックを追加します。

手順

1. Web コンソールにログインします。
2. Virtualization → Hosted Engine をクリックしてから Manage Gluster をクリックします。

3. Expand Cluster をクリックします。Gluster Deployment ウィンドウが開きます。

   1. Hosts タブで、新しいハイパーコンバージドノードの FQDN または IP アドレスを入力し、Next をクリックします。

      

   2. Volumes タブで、作成するボリュームの詳細を指定します。

      

   3. Bricks タブで、Gluster ボリュームの作成に使用するディスクの詳細を指定します。

      

   4. Review タブで、生成されたファイルで問題の有無を確認します。問題がなければ、Deploy をクリックします。

      

      デプロイメントが完了するまでに時間がかかります。クラスターが正常に拡張されると、次の画面が表示されます。

      

1. 管理ポータルで、Compute → Clusters をクリックします。
2. クラスターを選択し、Edit をクリックします。Edit Cluster ウィンドウが開きます。
3. Fencing policy タブをクリックします。
4. Enable fencing チェックボックスをオンにします。

5. 少なくとも次のフェンシングポリシーのチェックボックスをオンにします。

   • Skip fencing if gluster bricks are up
   • Skip fencing if gluster quorum not met

   これらのポリシーの影響の詳細については、付録B Red Hat Gluster Storage のフェンシングポリシー を参照してください。

6. OK をクリックして設定を保存します。

1. 管理ポータルで Compute → Hosts をクリックします。
2. 設定するホストを選択し、Edit をクリックして Edit Host ウィンドウを開きます。

3. Power Management タブをクリックします。

   図2.1 電源管理の設定

   
4. Enable Power Management チェックボックスをオンにします。これにより、タブの他のフィールドが有効になります。

5. Kdump integration チェックボックスを選択すると、カーネルクラッシュダンプの実行中にホストがフェンシングするのを防ぐことができます。

   重要

   既存のホストで Kdump 統合を有効にする場合、kdump を設定するにはホストを再インストールする必要があります。ホストの再インストール手順については、11章ハイパーコンバージドホストの再インストール を参照してください。

1. プラス (+) ボタンをクリックして、新しい電源管理デバイスを追加します。Edit fence agent ウィンドウが開きます。

   図2.2 フェンスエージェントの編集

   
   1. 電源管理デバイスの Address、User Name、Password を入力します。
   2. ドロップダウンリストから電源管理デバイスの Type を選択します。

1. 電源管理デバイスがホストとの通信に使用する SSH Port の番号を入力します。
2. 電源管理デバイスのブレードを識別するための Slot 番号を入力します。
3. 電源管理デバイスの オプション を入力します。key=value エントリーのコンマ区切りリストを使用します。
4. 電源管理デバイスがホストに安全に接続できるようにするには、Secure チェックボックスを選択します。

5. Test ボタンをクリックして、設定が正しいことを確認します。Test Succeeded、Host Status is: on 検証が成功すると表示されます。

   警告

   電源管理パラメーター (ユーザー ID、パスワード、オプションなど) は、セットアップ時と Red Hat Virtualization Manager でパラメーター値が手動で変更されたときの 2 つの状況で、Red Hat Virtualization Manager によってテストされます。不正なパラメーターに関する警告を無視したり、Red Hat Virtualization Manager で対応する変更を行わずに電源管理ハードウェアでパラメーターを変更したりするとフェンシングが失敗する可能性があります。

6. OK をクリックして、フェンスエージェントの追加を完了します。

1. OK をクリックして、ホスト設定を保存します。

1. すべての 前提条件 が満たされていることを確認してください。
2. geo レプリケーションターゲットとして使用する適切なボリュームを作成します。
3. ソースボリュームとターゲットボリューム間の geo レプリケーションセッションを設定 します。
4. geo レプリケーションプロセスを スケジュール します。

1. リモートボリュームへのバックアップを設定 します。
2. フェイルオーバーターゲットとして使用する適切なクラスターを作成します。
3. ソースクラスターとターゲットクラスターの マッピングファイルを準備します。
4. フェイルオーバー Playbook を準備します。
5. プライマリークラスターの クリーンアップ Playbook を準備します。
6. フェイルバック Playbook を準備します。

1. インベントリーファイルの作成

   以下の例に基づいて、cache_inventory.yml という名前のインベントリーファイルを作成します。

   <host1>、<host2>、および <host3> を、キャッシュを設定するホストの FQDN に置き換えます。

   ファイル全体で次の値を置き換えます。

   <slow_device>,<fast_device>

   キャッシュを接続するデバイスを指定し、次にキャッシュデバイスをコンマ区切りのリストとして指定します (例 : cachedisk: '/dev/sdb,/dev/sde')。

   <fast_device_name>

   作成するキャッシュ論理ボリュームの名前を指定します (例: cachelv_thinpool_gluster_vg_sde)。

   <fast_device_thinpool>

   作成するキャッシュシンプールの名前を指定します (例: gluster_thinpool_gluster_vg_sde)。

   cache_inventory.yml ファイルの例

   hc_nodes:
     hosts:
       # Host1
       <host1>:
         gluster_infra_cache_vars:
           - vgname: gluster_vg_sdb
             cachedisk: '<slow_device>,<fast_device>'
             cachelvname: <fast_device_name>
             cachethinpoolname: <fast_device_thinpool>
             cachelvsize: '10G'
             cachemode: writethrough
   
       #Host2
       <host2>:
         gluster_infra_cache_vars:
           - vgname: gluster_vg_sdb
             cachedisk: '<slow_device>,<fast_device>'
             cachelvname: <fast_device_name>
             cachethinpoolname: <fast_device_thinpool>
             cachelvsize: '10G'
             cachemode: writethrough
   
       #Host3
       <host3>:
         gluster_infra_cache_vars:
           - vgname: gluster_vg_sdb
             cachedisk: '<slow_device>,<fast_device>'
             cachelvname: <fast_device_name>
             cachethinpoolname: <fast_device_thinpool>
             cachelvsize: '10G'
             cachemode: writethrough

2. Playbook ファイルの作成

   lvm_cache.yml という名前の ansible Playbook ファイルを作成します。

   lvm_cache.yml ファイルの例

   ---
   # Create LVM Cache
   - name: Setup LVM Cache
     hosts: hc_nodes
     remote_user: root
     gather_facts: no
     any_errors_fatal: true
   
     roles:
        - gluster.infra

3. cachesetup タグを使用して Playbook を実行します

   次のコマンドを実行して、lvm_cache.yml で指定された設定を cache_inventory.yml で指定されたホストとデバイスに適用します。

   ansible-playbook -i cache_inventory.yml lvm_cache.yml --tags=cachesetup

手順

1. ホストエンジンの仮想マシンにログインします。

2. 環境のシャットダウン Playbook を作成します。

   次のテンプレートを使用して、Playbook ファイルを作成します。

   • ovirt-engine.example.com を Hosted Engine 仮想マシンの FQDN に置き換えます。
   • 123456 を admin@internal アカウントのパスワードに置き換えます。

   Playbook ファイルの例: shutdown_rhhi-v.yml

   ---
   - name: oVirt shutdown environment
     hosts: localhost
     connection: local
     gather_facts: false
   
     vars:
       engine_url: https://ovirt-engine.example.com/ovirt-engine/api
       engine_user: admin@internal
       engine_password: 123456
       engine_cafile: /etc/pki/ovirt-engine/ca.pem
   
     roles:
       - ovirt.ovirt.shutdown_env

手順

1. Hosted Engine 仮想マシンに対してシャットダウン Playbook を実行します。

   # ansible-playbook -i localhost <shutdown_rhhi-v.yml>

1. クラスター内のすべてのホストの電源を入れます。

2. 必要なサービスが利用可能であることを確認します。

   1. すべてのホストで glusterd サービスが正しく開始されたことを確認します。

      # systemctl status glusterd
      ● glusterd.service - GlusterFS, a clustered file-system server
         Loaded: loaded (/usr/lib/systemd/system/glusterd.service; enabled; vendor preset: disabled)
        Drop-In: /etc/systemd/system/glusterd.service.d
                 └─99-cpu.conf
         Active: active (running) since Wed 2018-07-18 11:15:03 IST; 3min 48s ago
         [...]

      glusterd が開始されていない場合は、開始します。

      # systemctl start glusterd

   2. ホストネットワークが使用可能であり、ホストに必要なインターフェイスに IP アドレスが割り当てられていることを確認します。

      # ip addr show

   3. すべてのホストがストレージクラスターの一部であることを確認します (Peer in Cluster (Connected) として表示されます)。

      # gluster peer status
      
      Number of Peers: 2
      
      Hostname: 10.70.37.101
      Uuid: 773f1140-68f7-4861-a996-b1ba97586257
      State: Peer in Cluster (Connected)
      
      Hostname: 10.70.37.102
      Uuid: fc4e7339-9a09-4a44-aa91-64dde2fe8d15
      State: Peer in Cluster (Connected)

   4. すべてのブリックが online として表示されていることを確認します。

      # gluster volume status engine
      Status of volume: engine
      Gluster process                             TCP Port  RDMA Port  Online  Pid
      ------------------------------------------------------------------------------
      Brick 10.70.37.28:/gluster_bricks/engine/en
      gine                                        49153     0          Y       23160
      Brick 10.70.37.29:/gluster_bricks/engine/en
      gine                                        49160     0          Y       12392
      Brick 10.70.37.30:/gluster_bricks/engine/en
      gine                                        49157     0          Y       15200
      Self-heal Daemon on localhost               N/A       N/A        Y       23008
      Self-heal Daemon on 10.70.37.30             N/A       N/A        Y       10905
      Self-heal Daemon on 10.70.37.29             N/A       N/A        Y       13568
      
      Task Status of Volume engine
      ------------------------------------------------------------------------------
      There are no active volume tasks

3. hosted engine 仮想マシンを起動します。

   1. hosted engine ノードにするホストで、次のコマンドを実行します。

      # hosted-engine --vm-start

   2. hosted engine 仮想マシンが正常に起動したことを確認します。

      # hosted-engine --vm-status

4. hosted engine 仮想マシンを Global Maintenance モードから取ります。

   1. 管理ポータルにログインします。
   2. Compute → Hosts をクリックし、hosted engine ノードを選択します。
   3. ⋮ → Disable Global HA Maintenance をクリックします。

5. Web コンソールを使用して他の仮想マシンを起動します。

   1. Compute → Virtualization をクリックします。
   2. 起動する仮想マシンを選択し、Run をクリックします。

1. Red Hat Hyperconverged Infrastructure for Virtualization のデプロイ の指示に従って、代替デプロイメントをインストールして設定します。

1. リモートクラスターへのフェイルオーバーを設定します。
2. ソースクラスターとターゲットクラスターのマッピングファイルが正確であることを確認します。

3. バックアップボリュームで読み取り専用モードを無効にする

   geo レプリケートされたボリュームは、各同期後に読み取り専用に設定され、データが変更されないようにします。ボリュームをストレージドメインとしてインポートするには、Red Hat Virtualization に書き込み権限が必要です。

   次のコマンドを実行して、バックアップボリュームの読み取り専用モードを無効にします。

   # gluster volume set <backup-vol> features.read-only off

   重要

   フェイルオーバー Playbook を実行する前に、プライマリーサイトでリモート同期スケジュールを停止してください。

   プライマリーサイトの Red Hat Virtualization Manager 管理ポータルにアクセスできる場合は、以下の手順を使用して、スケジュールされたリモートデータ同期を削除します。

   1. Red Hat Virtualization Manager Administration Portal → Storage の選択 → Domains を選択し、admin としてログインします。
   2. storage domain configured with remote data sync を選択→ Remote Data Sync Setup タブを選択→ Edit → Recurrence を none として選択します。

4. fail_over タグを使用してフェイルオーバー Playbook を実行します。

   # ansible-playbook dr-rhv-failover.yml --tags="fail_over"

1. clean_engine タグを使用してクリーンアップ Playbook を実行して、フェイルバック用にプライマリークラスターを準備します。

   # ansible-playbook dr-cleanup.yml --tags="clean_engine"

2. ソースクラスターとターゲットクラスターのマッピングファイルが正確であることを確認します。

3. fail_back タグを使用してフェイルバック Playbook を実行することにより、フェイルバックを実行します。

   # ansible-playbook dr-cleanup.yml --tags="fail_back"

1. データが現在同期されていないことを確認します

   Manager の右上にある Tasks アイコンをクリックして、Tasks ページを確認します。

   データ同期に関連する継続的なタスクがないことを確認します。

   データ同期タスクが存在する場合は、それらが完了するまで待ちます。

2. geo レプリケーションセッションを停止します

   1. Storage → Volumes をクリックします。
   2. geo レプリケーションを停止するボリュームの名前をクリックします。
   3. Geo-replication サブタブをクリックします。
   4. 停止するセッションを選択し、Stop をクリックします。

1. 任意のソースノードで管理ポータルにログインします。
2. Storage から Domains をクリックします。
3. バックアップするストレージドメインの名前をクリックします。
4. Remote Data Sync Setup サブタブをクリックします。

5. Setup をクリックします。

   Setup Remote Data Synchronization ウィンドウが開きます。

6. Recurrence フィールドで、NONE の繰り返し間隔タイプを選択し、OK をクリックします。

7. (オプション) geo レプリケーションセッションを削除します。

   geo レプリケーションマスターノードから次のコマンドを実行します。

   # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL delete

   このコマンドは、reset-sync-time パラメーターを指定して実行することもできます。このパラメーターと geo レプリケーションセッションの削除の詳細については、Red Hat Gluster Storage 3.5 管理ガイド の Geo レプリケーションセッションの削除 を参照してください。

診断

1. 自己修復状態を確認します。

   次のコマンドを数分間にわたって数回実行します。表示されるエントリーに注意してください。

   # gluster volume heal <volname> info

   毎回同じエントリーが表示される場合は、これらのエントリーに GFID の不一致がある可能性があります。

2. 各ホストの各エントリーの GFID を確認します。

   各ホストで、エントリーごとに次のコマンドを実行します。

   # getfattr -d -m. -ehex <backend_path> -h

   エントリーの <backend_path> は、ブリックパスとエントリーで設定されます。たとえば、engine ボリュームのブリックに /gluster_bricks/engine/engine のパスがあり、修復情報に表示されるエントリーが 58d392a6-e5b1-4aed-9bbc-952210a7137d/ha_agent/hosted-engine.metadata である場合、使用する backend_path は /gluster_bricks/engine/engine/58d392a6-e5b1-4aed-9bbc-952210a7137d/ha_agent/hosted-engine.metadata です。

3. 各ホストからの出力を比較します。

   エントリーの trusted.gfid がすべてのホストで同じでない場合、GFID の不一致があります。

解決方法

1. 最新の変更時刻を持つ GFID を優先して不一致を解決します。

   # gluster volume heal <volume> split-brain latest-mtime <entry>

   以下に例を示します。

   # gluster volume heal engine split-brain latest-mtime /58d392a6-e5b1-4aed-9bbc-952210a7137d/ha_agent/hosted-engine.metadata

2. 手動でボリュームの回復をトリガーします。

   # gluster volume heal <volname>