第6章 Red Hat High Availability クラスターのアクティブ/パッシブな NFS サーバーの設定

以下の手順では、共有ストレージを使用して、2 ノードの Red Hat Enterprise Linux High Availability Add-On クラスターで、高可用性アクティブ/パッシブ NFS サーバーを設定します。この手順では、pcs を使用して Pacemaker クラスターリソースを設定します。このユースケースでは、クライアントが、フローティング IP アドレスから NFS ファイルシステムにアクセスします。NFS サービスは、クラスターにある 2 つのノードのいずれかで実行します。NFS サーバーが実行しているノードが正常に動作しなくなると、NFS サーバーはクラスターの 2 番目のノードで再起動し、サービスの中断が最小限に抑えられます。

6.1. 前提条件

このユースケースでは、システムに以下のコンポーネントが必要です。

  • 各ノードに電源フェンスが設定されている 2 ノードの Red Hat High Availability クラスター。プライベートネットワークが推奨されますが、必須ではありません。この手順では、「Pacemaker を使用した Red Hat High Availability クラスターの作成」で説明されているサンプルのクラスターを使用します。
  • NFS サーバーに必要なパブリック仮想 IP アドレス。
  • iSCSI、ファイバーチャネル、またはその他の共有ネットワークデバイスを使用する、クラスター内のノードに対する共有ストレージ。

6.2. 手順の概要

既存の 2 ノードの Red Hat Enterprise Linux High Availability クラスターで高可用性アクティブ/パッシブ NFS サーバーを設定するには、以下の手順を実行する必要があります。

  1. クラスターのノードの共有ストレージの LVM 論理ボリューム my_lv に、ext4 ファイルシステムを設定する。
  2. 共有ストレージの LVM 論理ボリュームで NFS 共有を設定する。
  3. クラスターリソースを作成する。
  4. 設定した NFS サーバーをテストする。

6.3. Pacemaker クラスターで ext4 ファイルシステムを持つ LVM ボリュームの設定

このユースケースでは、クラスターのノード間で共有されるストレージに、LVM 論理ボリュームを作成する必要があります。

注記

LVM ボリュームと、クラスターノードで使用するパーティションおよびデバイスは、クラスターノード以外には接続しないでください。

以下の手順では、LVM 論理ボリュームを作成して Pacemaker クラスターで使用できるように、ボリュームに ext4 ファイルシステムを作成します。この例では、LVM 論理ボリュームを作成する LVM 物理ボリュームを保管するのに、共有パーティション /dev/sdb1 が使用されます。

  1. クラスターの両ノードで以下の手順を実行し、LVM システム ID の値を、システムの uname 識別子の値に設定します。LVM システム ID を使用すると、クラスターのみがボリュームグループをアクティブにできるようになります。

    1. /etc/lvm/lvm.conf 設定ファイルの system_id_source 設定オプションを uname に設定します。

      # Configuration option global/system_id_source.
      system_id_source = "uname"
    2. ノードの LVM システム ID が、ノードの uname に一致することを確認します。

      # lvm systemid
        system ID: z1.example.com
      # uname -n
        z1.example.com
  2. LVM ボリュームを作成し、そのボリュームに ext4 ファイルシステムを作成します。/dev/sdb1 パーティションは共有されるストレージであるため、この手順のこの部分は、1 つのノードでのみ実行してください。

    1. パーティション /dev/sdb1 に LVM 物理ボリュームを作成します。

      # pvcreate /dev/sdb1
        Physical volume "/dev/sdb1" successfully created
    2. 物理ボリューム /dev/sdb1 で構成されるボリュームグループ my_vg を作成します。

      # vgcreate my_vg /dev/sdb1
        Volume group "my_vg" successfully created
    3. 新規ボリュームグループには、実行中のノードで、かつボリュームグループの作成元であるノードのシステム ID があることを確認します。

      # vgs -o+systemid
        VG    #PV #LV #SN Attr   VSize  VFree  System ID
        my_vg   1   0   0 wz--n- <1.82t <1.82t z1.example.com
    4. ボリュームグループ my_vg を使用して、論理ボリュームを作成します。

      # lvcreate -L450 -n my_lv my_vg
        Rounding up size to full physical extent 452.00 MiB
        Logical volume "my_lv" created

      lvs コマンドを実行すると、論理ボリュームを表示できます。

      # lvs
        LV      VG      Attr      LSize   Pool Origin Data%  Move Log Copy%  Convert
        my_lv   my_vg   -wi-a---- 452.00m
        ...
    5. 論理ボリューム my_lv に、ext4 ファイルシステムを作成します。

      # mkfs.ext4 /dev/my_vg/my_lv
      mke2fs 1.44.3 (10-July-2018)
      Creating filesystem with 462848 1k blocks and 115824 inodes
      ...

6.4. 複数のクラスターノードでボリュームグループがアクティブにならないようにする

この手順では、クラスターで Pacemaker が管理するボリュームグループが起動時に自動的にアクティブにならないようにします。Pacemaker ではなく、システムの起動時にボリュームグループが自動的にアクティブになる場合は、ボリュームグループが同時に複数のノードでアクティブになるリスクがあります。これにより、ボリュームグループのメタデータが破損する可能性があります。

この手順では、/etc/lvm/lvm.conf 設定ファイルの auto_activation_volume_list エントリーを変更します。auto_activation_volume_list エントリーは、自動アクティブ化を特定の論理ボリュームに制限するために使用されます。auto_activation_volume_list を空のリストに設定すると、自動アクティベーションは完全に無効になります。

共有されず、Pacemaker によって管理されていないローカルボリュームは、ノードのローカルのルートおよびホームディレクトリーに関連する ボリュームグループを含む auto_activation_volume_list エントリーに含める必要があります。クラスターマネージャーが管理するすべてのボリュームグループは、auto_activation_volume_list エントリーから除外する必要があります。

手順

クラスター内の各ノードで以下の手順を実行します。

  1. 以下のコマンドを使用して、ローカルストレージに現在設定されているボリュームグループを確認します。これにより、現在設定されているボリュームグループの一覧が出力されます。root と、このノードのホームディレクトリー用に、別のボリュームグループに領域を割り当てると、この例のように、それらのボリュームが出力に表示されます。

    # vgs --noheadings -o vg_name
      my_vg
      rhel_home
      rhel_root
  2. /etc/lvm/lvm.conf 設定ファイルの auto _activation_volume_list へのエントリーとして、my_vg 以外のボリューム グループ(クラスターに定義したボリュームグループ)を追加します。

    たとえば、root とホームディレクトリー用の個別のボリュームグループに領域が割り当てられている場合は、以下のように lvm.conf ファイルの auto_activation_volume_list 行のコメントを解除し、これらのボリュームグループを auto_activation_volume_list に追加します。クラスターに対してだけ定義したボリュームグループ(この例ではmy_vg )は、この一覧にない点に注意してください。

    auto_activation_volume_list = [ "rhel_root", "rhel_home" ]
    注記

    クラスターマネージャーの外部でアクティベートするノードにローカルボリュームグループが存在しない場合は、auto_activation_volume _list = [] として auto_activation_volume_ list エントリーを初期化する必要があります。

  3. initramfs ブートイメージを再構築して、ブートイメージがクラスターによって制御されているボリュームグループのアクティベートを試行しないようにします。以下のコマンドを使用して、initramfs デバイスを更新します。このコマンドが完了するまで最大 1 分かかる場合があります。

    # dracut -H -f /boot/initramfs-$(uname -r).img $(uname -r)
  4. ノードを再起動します。

    注記

    ブートイメージで作成したノードをブートしてから、新しい Linux カーネルをインストールした場合は、ノードの再起動時に実行している新しいカーネル用に、新しい initrd イメージを指定します。リブート前後に uname -r コマンドを実行して、実行中のカーネルリリースを判断することで、正しい initrd デバイスが使用されていることを確認できます。リリースが同じでない場合、新規カーネルで再起動した後に initrd ファイルを更新して、ノードをリブートします。

  5. ノードがリブートしたら、ノードで pcs cluster status コマンドを実行して、そのノードでクラスターサービスを再度起動しているかどうかを確認します。これにより、Error: cluster is not running on this node というメッセージが 表示される場合は、以下のコマンドを入力します。

    # pcs cluster start

    または、クラスターの各ノードを再起動して、クラスターの全ノードでクラスターサービスを開始するまで待機するには、次のコマンドを使用します。

    # pcs cluster start --all

6.5. NFS 共有の設定

次の手順では、NFS サービスのフェールオーバーに、NFS 共有を設定します。

  1. クラスターの両方のノードに、/nfsshare ディレクトリーを作成します。

    # mkdir /nfsshare
  2. クラスター内の 1 ノードで、以下の手順を行います。

    1. 「LVM ボリュームと ext4 ファイルシステムの設定」で作成した ext4 ファイルシステムを、/nfsshare ディレクトリーにマウントします。

      [root@z1 ~]# mount /dev/my_vg/my_lv /nfsshare
    2. /nfsshare ディレクトリーに、exports ディレクトリーツリーを作成します。

      [root@z1 ~]# mkdir -p /nfsshare/exports
      [root@z1 ~]# mkdir -p /nfsshare/exports/export1
      [root@z1 ~]# mkdir -p /nfsshare/exports/export2
    3. NFS クライアントがアクセスするファイルを、exports ディレクトリーに置きます。この例では、テストファイル clientdatafile1 および clientdatafile2 を作成します。

      [root@z1 ~]# touch /nfsshare/exports/export1/clientdatafile1
      [root@z1 ~]# touch /nfsshare/exports/export2/clientdatafile2
    4. ext4 ファイルシステムをアンマウントし、LVM ボリュームグループを非アクティブにします。

      [root@z1 ~]# umount /dev/my_vg/my_lv
      [root@z1 ~]# vgchange -an my_vg

6.6. クラスターの NFS サーバーへリソースおよびリソースグループを設定

このセクションでは、このユースケースで、クラスターリソースを設定する手順を説明します。

注記

クラスターにフェンスデバイスを設定していないと、リソースはデフォルトでは起動しないことに注意してください。

設定したリソースが実行していない場合は、pcs resource debug-start resource コマンドを実行して、リソースの設定をテストします。このコマンドは、クラスターの制御や認識の範囲外でサービスを起動します。設定したリソースが再稼働したら、pcs resource cleanup resource を実行して、クラスターが更新を認識するようにします。

以下の手順では、システムリソースを設定します。これらのリソースがすべて同じノードで実行するように、これらのリソースはリソースグループ nfsgroup に含まれます。リソースは、グループに追加された順序で起動し、その逆の順序で停止します。この手順は、クラスター内のいずれかのノードで実行してください。

  1. LVM が有効なリソース my_lvm を作成します。リソースグループ my_lvm は存在しないため、このコマンドによりリソースグループが作成されます。

    警告

    データ破損のリスクとなるため、アクティブ/パッシブの HA 設定で、同じ LVM ボリュームグループを使用する LVM が有効 なリソースを複数設定しないでください。また、LVM が有効 なリソースは、アクティブ/パッシブの HA 設定のクローンリソースとして設定しないでください。

    [root@z1 ~]# pcs resource create my_lvm ocf:heartbeat:LVM-activate vgname=my_vg vg_access_mode=system_id --group nfsgroup
  2. クラスターのステータスを確認し、リソースが実行していることを確認します。

    root@z1 ~]#  pcs status
    Cluster name: my_cluster
    Last updated: Thu Jan  8 11:13:17 2015
    Last change: Thu Jan  8 11:13:08 2015
    Stack: corosync
    Current DC: z2.example.com (2) - partition with quorum
    Version: 1.1.12-a14efad
    2 Nodes configured
    3 Resources configured
    
    Online: [ z1.example.com z2.example.com ]
    
    Full list of resources:
     myapc  (stonith:fence_apc_snmp):       Started z1.example.com
     Resource Group: nfsgroup
         my_lvm     (ocf::heartbeat:LVM):   Started z1.example.com
    
    PCSD Status:
      z1.example.com: Online
      z2.example.com: Online
    
    Daemon Status:
      corosync: active/enabled
      pacemaker: active/enabled
      pcsd: active/enabled
  3. クラスターに Filesystem リソースを設定します。

    以下のコマンドは、ext4 の Filesystem リソース nfsshare を、nfsgroup リソースグループに追加します。このファイルシステムは、「ext4 ファイルシステムを持つ LVM ボリュームの設定」で作成した、LVM ボリュームグループおよび ext4 ファイルシステムを使用します。このファイルシステムは、「NFS 共有の設定」で作成した /nfsshare ディレクトリーにマウントされます。

    [root@z1 ~]# pcs resource create nfsshare Filesystem \
    device=/dev/my_vg/my_lv directory=/nfsshare \
    fstype=ext4 --group nfsgroup

    options=options パラメーターを使用すると、Filesystem リソースのリソース設定にマウントオプションを指定できます。すべての設定オプションを確認する場合は、pcs resource describe Filesystem コマンドを実行します。

  4. my_lvm リソースおよび nfsshare リソースが実行していることを確認します。

    [root@z1 ~]# pcs status
    ...
    Full list of resources:
     myapc  (stonith:fence_apc_snmp):       Started z1.example.com
     Resource Group: nfsgroup
         my_lvm     (ocf::heartbeat:LVM):   Started z1.example.com
         nfsshare   (ocf::heartbeat:Filesystem):    Started z1.example.com
    ...
  5. nfsgroup リソースグループに、nfs-daemon という名前の nfsserver リソースを作成します。

    注記

    nfsserver リソースを使用して、nfs_shared_infodir パラメーターを指定できます。これは、NFS サーバーが、NFS 関連のステートフル情報を保管するのに使用するディレクトリーです。

    この属性は、このエクスポートのコレクションで作成した Filesystem リソースのいずれかのサブディレクトリーに設定することが推奨されます。これにより、NFS サーバーは、このリソースグループを再配置する必要がある場合に別のノードで使用できるデバイスに、ステートフル情報を保存します。この例では、以下のように設定されています。

    • /nfsshare は、Filesystem リソースにより管理される shared-storage ディレクトリーです。
    • /nfsshare/exports/export1 および /nfsshare/exports/export2 は、エクスポートディレクトリーです。
    • /nfsshare/nfsinfo は、nfsserver リソースの共有情報ディレクトリーです。
    [root@z1 ~]# pcs resource create nfs-daemon nfsserver \
    nfs_shared_infodir=/nfsshare/nfsinfo nfs_no_notify=true \
    --group nfsgroup
    
    [root@z1 ~]# pcs status
    ...
  6. exportfs リソースを追加して、/nfsshare/exports ディレクトリーをエクスポートします。このリソースは、nfsgroup リソースグループに含まれます。これにより、NFSv4 クライアントの仮想ディレクトリーが構築されます。このエクスポートには、NFSv3 クライアントもアクセスできます。

    注記

    fsid=0 オプションは、NFSv4 クライアントに仮想ディレクトリーを作成する場合にのみ必要です。詳細は、「NFS サーバーで /etc/exports ファイルの fsid オプションを設定する方法」を参照してください。

    [root@z1 ~]# pcs resource create nfs-root exportfs \
    clientspec=192.168.122.0/255.255.255.0 \
    options=rw,sync,no_root_squash \
    directory=/nfsshare/exports \
    fsid=0 --group nfsgroup
    
    [root@z1 ~]# # pcs resource create nfs-export1 exportfs \
    clientspec=192.168.122.0/255.255.255.0 \
    options=rw,sync,no_root_squash directory=/nfsshare/exports/export1 \
    fsid=1 --group nfsgroup
    
    [root@z1 ~]# # pcs resource create nfs-export2 exportfs \
    clientspec=192.168.122.0/255.255.255.0 \
    options=rw,sync,no_root_squash directory=/nfsshare/exports/export2 \
    fsid=2 --group nfsgroup
  7. NFS 共有にアクセスするために、NFS クライアントが使用するフローティング IP アドレスリソースを追加します。このリソースは、リソースグループ nfsgroup に含まれます。このデプロイメント例では、192.168.122.200 をフローティング IP アドレスとして使用します。

    [root@z1 ~]# pcs resource create nfs_ip IPaddr2 \
    ip=192.168.122.200 cidr_netmask=24 --group nfsgroup
  8. NFS デプロイメント全体が初期化されたら、NFSv3 の再起動通知を送信する nfsnotify リソースを追加します。このリソースは、リソースグループ nfsgroup に含まれます。

    注記

    NFS の通知が適切に処理されるようにするには、フローティング IP アドレスにホスト名が関連付けられており、それが NFS サーバーと NFS クライアントで同じである必要があります。

    [root@z1 ~]# pcs resource create nfs-notify nfsnotify \
    source_host=192.168.122.200 --group nfsgroup
  9. リソースとリソースの制約を作成したら、クラスターのステータスを確認できます。すべてのリソースが同じノードで実行していることに注意してください。

    [root@z1 ~]# pcs status
    ...
    Full list of resources:
     myapc  (stonith:fence_apc_snmp):       Started z1.example.com
     Resource Group: nfsgroup
         my_lvm     (ocf::heartbeat:LVM):   Started z1.example.com
         nfsshare   (ocf::heartbeat:Filesystem):    Started z1.example.com
         nfs-daemon (ocf::heartbeat:nfsserver):     Started z1.example.com
         nfs-root   (ocf::heartbeat:exportfs):      Started z1.example.com
         nfs-export1        (ocf::heartbeat:exportfs):      Started z1.example.com
         nfs-export2        (ocf::heartbeat:exportfs):      Started z1.example.com
         nfs_ip     (ocf::heartbeat:IPaddr2):       Started  z1.example.com
         nfs-notify (ocf::heartbeat:nfsnotify):     Started z1.example.com
    ...

6.7. NFS リソース設定のテスト

以下の手順を使用すると、システムの設定を検証できます。NFSv3 または NFSv4 のいずれかで、エクスポートされたファイルシステムをマウントできるはずです。

6.7.1. NFS エクスポートのテスト

  1. デプロイメントと同じネットワークにあるクラスター外部のノードで NFS 共有をマウントして、NFS 共有が表示されることを確認します。この例では、192.168.122.0/24 ネットワークを使用します。

    # showmount -e 192.168.122.200
    Export list for 192.168.122.200:
    /nfsshare/exports/export1 192.168.122.0/255.255.255.0
    /nfsshare/exports         192.168.122.0/255.255.255.0
    /nfsshare/exports/export2 192.168.122.0/255.255.255.0
  2. NFSv4 で NFS 共有をマウントできることを確認する場合は、クライアントノードのディレクトリーに NFS 共有をマウントします。マウントしたら、エクスポートディレクトリーの内容が表示されることを確認します。テスト後に共有をアンマウントします。

    # mkdir nfsshare
    # mount -o "vers=4" 192.168.122.200:export1 nfsshare
    # ls nfsshare
    clientdatafile1
    # umount nfsshare
  3. NFSv3 で NFS 共有をマウントできることを確認します。マウントしたら、テストファイル clientdatafile1 が表示されていることを確認します。NFSv4 とは異なり、NFSv3 は仮想ファイルシステムを使用しないため、特定のエクスポートをマウントする必要があります。テスト後に共有をアンマウントします。

    # mkdir nfsshare
    # mount -o "vers=3" 192.168.122.200:/nfsshare/exports/export2 nfsshare
    # ls nfsshare
    clientdatafile2
    # umount nfsshare

6.7.2. フェイルオーバーのテスト

  1. クラスター外のノードで、NFS 共有をマウントし、「NFS 共有の設定」で作成した clientdatafile1 へのアクセスを確認します。

    # mkdir nfsshare
    # mount -o "vers=4" 192.168.122.200:export1 nfsshare
    # ls nfsshare
    clientdatafile1
  2. クラスター内で、nfsgroup を実行しているノードを確認します。この例では、nfsgroupz1.example.com で実行しています。

    [root@z1 ~]# pcs status
    ...
    Full list of resources:
     myapc  (stonith:fence_apc_snmp):       Started z1.example.com
     Resource Group: nfsgroup
         my_lvm     (ocf::heartbeat:LVM):   Started z1.example.com
         nfsshare   (ocf::heartbeat:Filesystem):    Started z1.example.com
         nfs-daemon (ocf::heartbeat:nfsserver):     Started z1.example.com
         nfs-root   (ocf::heartbeat:exportfs):      Started z1.example.com
         nfs-export1        (ocf::heartbeat:exportfs):      Started z1.example.com
         nfs-export2        (ocf::heartbeat:exportfs):      Started z1.example.com
         nfs_ip     (ocf::heartbeat:IPaddr2):       Started  z1.example.com
         nfs-notify (ocf::heartbeat:nfsnotify):     Started z1.example.com
    ...
  3. クラスター内のノードから、nfsgroup を実行しているノードをスタンバイモードにします。

    [root@z1 ~]# pcs node standby z1.example.com
  4. nfsgroup が、別のクラスターノードで正常に起動することを確認します。

    [root@z1 ~]# pcs status
    ...
    Full list of resources:
     Resource Group: nfsgroup
         my_lvm     (ocf::heartbeat:LVM):   Started z2.example.com
         nfsshare   (ocf::heartbeat:Filesystem):    Started z2.example.com
         nfs-daemon (ocf::heartbeat:nfsserver):     Started z2.example.com
         nfs-root   (ocf::heartbeat:exportfs):      Started z2.example.com
         nfs-export1        (ocf::heartbeat:exportfs):      Started z2.example.com
         nfs-export2        (ocf::heartbeat:exportfs):      Started z2.example.com
         nfs_ip     (ocf::heartbeat:IPaddr2):       Started  z2.example.com
         nfs-notify (ocf::heartbeat:nfsnotify):     Started z2.example.com
    ...
  5. NFS 共有をマウントしたクラスターの外部のノードから、この外部ノードが NFS マウント内のテストファイルに引き続きアクセスできることを確認します。

    # ls nfsshare
    clientdatafile1

    フェイルオーバー時に、クライアントに対するサービスが一時的に失われますが、クライアントはユーザーが介入しなくても回復します。デフォルトでは、NFSv4 を使用するクライアントの場合は、マウントの復旧に最大 90 秒かかることがあります。この 90 秒は、システムの起動時にサーバーが監視する NFSv4 ファイルのリースの猶予期間です。NFSv3 クライアントでは、数秒でマウントへのアクセスが回復します。

  6. クラスター内で、最初に nfsgroup を実行していたノードをスタンバイモードから削除します。

    注記

    ノードを スタンバイ モードから削除しても、リソースはそのノードにフェイルオーバーしません。これは、リソースの resource-stickiness 値により異なります。resource-stickiness メタ属性の詳細は、「現在のノードを優先するようにリソースを設定」を参照してください。

    [root@z1 ~]# pcs node unstandby z1.example.com

このページには機械翻訳が使用されている場合があります (詳細はこちら)。