11.10. ホストの置き換え

ホストを置き換える前に、新規ピアが置き換えるものと正確なディスク容量を持つようにします。たとえば、クラスターのピアに 100 GB ドライブが 2 つある場合、新しいピアには同じディスク容量とドライブ数が必要です。また、本セクションで説明する手順は、他のボリューム種別でも実行できます。また、ボリュームで置換およびリセット操作を実行する場合は、「ボリュームの移行」 を参照してください。

11.10.1. ホストマシンを別のホスト名に置き換える

失敗したホストマシンを、別のホスト名を持つ別のホストに置き換えることができます。次の例では、回復不能な障害が発生した元のマシンをserver0.example.com、代替のマシンをserver5.example.comとしています。復旧不可能な障害のあるブリックは server0.example.com:/rhgs/brick1 で、置き換えるブリックは server5.example.com:/rhgs/brick1 です。
  1. 以下のコマンドを実行してジオレプリケーションセッションを停止します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL stop force
  2. 既存のピアの 1 つから新規ピアをプローブし、これをクラスターで使用できるようにします。
    # gluster peer probe server5.example.com
  3. 古いブリック(server5.example.com:/rhgs/brick1)を置き換える新しいブリック(server0.example.com:/rhgs/brick1)が空であることを確認します。
  4. geo レプリケーションセッションが設定されている場合は、以下の手順を実行します。
    1. ssh キーを生成して、geo レプリケーションセッションを設定します。
      # gluster system:: execute gsec_create 
    2. force オプションを指定して、ジオレプリケーションセッションを再度作成して、新しいノードから Slave ノードにキーを配布します。
      # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL create push-pem force
    3. 共有ストレージボリュームの設定に成功すると、新しいノードがクラスターに置き換えられると、共有ストレージはこのノードに自動的にマウントされません。このノードの共有ストレージ用に /etc/fstab エントリーは追加されません。このノードで共有ストレージを使用するには、以下のコマンドを実行します。
      # mount -t glusterfs local node's ip:gluster_shared_storage
      /var/run/gluster/shared_storage
      # cp /etc/fstab /var/run/gluster/fstab.tmp
      # echo  local node's ip:/gluster_shared_storage
      /var/run/gluster/shared_storage/ glusterfs defaults 0 0" >> /etc/fstab
      注記
      3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。
      共有ストレージボリュームの設定についての詳細は、「共有ストレージボリュームの設定」 を参照してください。
    4. geo レプリケーションのメタボリュームを設定します。
      # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL config use_meta_volume true
      meta-volume の設定に関する詳細は、「メタボリュームの設定」 を参照してください。
  5. 以下のコマンドを使用して、server0.example.com のブリックパスを取得します。
    # gluster volume info <VOLNAME>
    Volume Name: vol
    Type: Replicate
    Volume ID: 0xde822e25ebd049ea83bfaa3c4be2b440
    Status: Started
    Snap Volume: no
    Number of Bricks: 1 x 2 = 2
    Transport-type: tcp
    Bricks:
    Brick1: server0.example.com:/rhgs/brick1
    Brick2: server1.example.com:/rhgs/brick1
    Options Reconfigured:
    cluster.granular-entry-heal: on
    performance.readdir-ahead: on
    snap-max-hard-limit: 256
    snap-max-soft-limit: 90
    auto-delete: disable
    
    server0.example.com のブリックパスは /rhgs/brick1 です。これは、新たに追加したホストのブリック (server5.example.com) に置き換える必要があります。
  6. たとえば、/rhs/brick が server5.example.com の XFS マウントポイントである場合は、server5.example.com に必須のブリックパスを作成します。
    # mkdir /rhgs/brick1
  7. replace-brick コマンドを force オプションを指定して実行します。
    # gluster volume replace-brick vol server0.example.com:/rhgs/brick1 server5.example.com:/rhgs/brick1 commit force
    volume replace-brick: success: replace-brick commit successful
  8. 新しいブリックがオンラインであることを確認します。
    # gluster volume status
    Status of volume: vol
    Gluster process                                  Port    Online Pid
    Brick server5.example.com:/rhgs/brick1           49156    Y    5731
    Brick server1.example.com:/rhgs/brick1            49153    Y    5354
  9. ボリュームで自己修復を開始します。修復プロセスのステータスは、以下のコマンドを実行すると確認できます。
    # gluster volume heal VOLNAME
  10. 修復プロセスのステータスは、以下のコマンドを実行すると確認できます。
    # gluster volume heal VOLNAME info
  11. 元のマシンを信頼できるプールから切断します。
    # gluster peer detach (server)
    All clients mounted through the peer which is getting detached need to be remounted, using one of the other active peers in the trusted storage pool, this ensures that the client gets notification on any changes done on the gluster configuration and if the same has been done do you want to proceed? (y/n) y
    peer detach: success
  12. 自己修復が完了したら、拡張属性がレプリカの他のブリックでゼロに設定されていることを確認します。
    # getfattr -d -m. -e hex /rhgs/brick1
    getfattr: Removing leading '/' from absolute path names
    #file: rhgs/brick1
    security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a66696c655f743a733000
    trusted.afr.vol-client-0=0x000000000000000000000000
    trusted.afr.vol-client-1=0x000000000000000000000000
    trusted.gfid=0x00000000000000000000000000000001
    trusted.glusterfs.dht=0x0000000100000000000000007ffffffe
    trusted.glusterfs.volume-id=0xde822e25ebd049ea83bfaa3c4be2b440
    この例では、trusted.afr.vol-client-0 および trusted.afr.vol-client-1 の拡張属性の値がゼロになります。つまり、2 つのブリックのデータは同一であることを意味します。自己修復の完了後にこれらの属性がゼロにならないと、データが正しく同期されません。
  13. force オプションを使用してジオレプリケーションセッションを起動します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL start force