Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

High Availability Add-On の管理

Red Hat Enterprise Linux 7

High Availability Add-On の設定と管理

Logo

Steven Levine

Red Hat Customer Content Services

概要

High Availability Add-On の管理』 は、Red Hat Enterprise Linux 7 向けの High Availability Add-On の設定と管理について説明しています。

第1章 Pacemaker を使用した Red Hat High Availability クラスターの作成

本章では、pcs コマンドを使用して 2 ノードの Red Hat High Availability クラスターを作成する手順を説明します。クラスターの作成後、必要なリソースやリソースグループを設定できます。
本章で説明しているクラスターを設定する場合には次のコンポーネントが必要になります。
  • 2 ノード、クラスターを構成させるノードです。ここでは z1.example.comz2.example.com という名前にしています。
  • プライベートネットワーク用のネットワークスイッチ、クラスター同士の通信およびネットワーク電源スイッチやファイバーチャンネルスイッチなどのクラスターハードウェアとの通信に必要になります。
  • 各ノード用の電源フェンスデバイス、ここでは APC 電源スイッチの 2 ポートを使用しています。ホスト名は zapc.example.com にしています。
本章は 3 つの項に分かれています。

1.1. クラスターソフトウェアのインストール

クラスターのインストールおよび設定手順を以下に示します。
  1. クラスターの各ノードに、Red Hat High Availability Add-On ソフトウェアパッケージと使用可能なすべてのフェンスエージェントを High Availability チャンネルからインストールします。
    # yum install pcs pacemaker fence-agents-all
  2. firewalld デーモンを実行している場合は、以下のコマンドを実行して Red Hat High Availability Add-On が必要とするポートを有効にします。

    注記

    firewalld デーモンがシステムにインストールされているかどうかを確認するには、rpm -q firewalld コマンドを実行します。firewalld デーモンがインストールされている場合は、firewall-cmd --state コマンドを使用して実行されているかどうかを確認できます。
    # firewall-cmd --permanent --add-service=high-availability
    # firewall-cmd --add-service=high-availability
  3. pcs を使ってクラスターの設定やノード間の通信を行うため、pcs の管理アカウントとなるユーザー ID hacluster のパスワードを各ノードに設定しなければなりません。ユーザー hacluster のパスワードは各ノードで同じパスワードにすることを推奨しています。
    # passwd hacluster
    Changing password for user hacluster.
    New password:
    Retype new password:
    passwd: all authentication tokens updated successfully.
  4. クラスターを設定する前に、各ノードで起動時にブートするよう pcsd デーモンが起動および有効化されている必要があります。このデーモンは pcs コマンドで動作し、クラスターのノード全体で設定を管理します。
    クラスターの各ノードで次のコマンドを実行し pcsd サービスを起動、またシステムの起動時に pcsd が有効になるよう設定します。
    # systemctl start pcsd.service
    # systemctl enable pcsd.service
  5. pcs を実行するノードでクラスター内の各ノードの pcs ユーザー hacluster を認証します。
    次のコマンドでは、z1.example.comz2.example.com の 2 ノードで構成されるクラスターの両ノードに対してユーザー hacluster の認証を z1.example.com 上で行っています。
    [root@z1 ~]# pcs cluster auth z1.example.com z2.example.com
    Username: hacluster
    Password:
    z1.example.com: Authorized
    z2.example.com: Authorized

1.2. クラスターの作成

この手順では、z1.example.com および z2.example.com ノードで構成される Red Hat High Availability Add-On を作成します。
  1. 次のコマンドを z1.example.com で実行し ノード z1.example.com とノード z2.example.com で構成される 2 ノードクラスターの my_cluster を作成します。これによりクラスター設定ファイルがクラスター内の全ノードに伝搬されます。このコマンドには --start オプションが含まれます。このオプションを使用すると、クラスター内の全ノードでクラスターサービスが起動されます。
    [root@z1 ~]# pcs cluster setup --start --name my_cluster \
    z1.example.com z2.example.com
    z1.example.com: Succeeded
    z1.example.com: Starting Cluster...
    z2.example.com: Succeeded
    z2.example.com: Starting Cluster...
  2. クラスターサービスを有効にし、ノードがブートしたときにクラスターの各ノードでクラスターサービスが実行されるようにします。

    注記

    使用環境によってクラスターサービスを無効にしておきたい場合などはこの手順を省いて構いません。この手順を行うことで、ノードがダウンした場合にクラスターやリソース関連の問題をすべて解決してからそのノードをクラスターに戻すことができます。クラスターサービスを無効にしている場合には、ノードを再起動する時に pcs cluster start コマンドを使って手作業でサービスを起動しなければならないので注意してください。
    [root@z1 ~]# pcs cluster enable --all
pcs cluster status コマンドを使用するとクラスターの現在の状態を表示できます。pcs cluster setup コマンドの --start オプションを使用してクラスターサービスを起動した場合は、クラスターが稼働する前に若干の遅延が発生することがあるため、クラスターに対する後続アクションと設定を行う前にクラスターが稼働していることを確認する必要があります。
[root@z1 ~]# pcs cluster status
Cluster Status:
 Last updated: Thu Jul 25 13:01:26 2013
 Last change: Thu Jul 25 13:04:45 2013 via crmd on z2.example.com
 Stack: corosync
 Current DC: z2.example.com (2) - partition with quorum
 Version: 1.1.10-5.el7-9abe687
 2 Nodes configured
 0 Resources configured

1.3. 排他処理の設定

クラスターの各ノードにフェンスデバイスを設定する必要があります。フェンス設定コマンドの説明やオプションは、『Red Hat Enterprise Linux 7 High Availability Add-On リファレンス』 を参照してください。排他処理 (フェンシング) やその重要性は、Fencing in a Red Hat High Availability Cluster を参照してください。

注記

フェンスデバイスの設定をする際、そのフェンスデバイスで管理を行うノードと電源が共有されていないことを必ず確認してください。
ここでは zapc.example.com というホスト名の APC 電源スイッチを使ってノードの排他処理を行います。このスイッチは fence_apc_snmp フェンスエージェントを使用します。ノードはすべて同じフェンスエージェントで排他処理されるため、pcmk_host_mappcmk_host_list のオプションを使ってすべてのフェンスデバイスを一つのリソースとして設定できます。
pcs stonith create コマンドを使って stonith リソースとしてデバイスを設定し、フェンスデバイスを作成します。次のコマンドは、z1.example.com および z2.example.com ノードの fence_apc_snmp フェンスエージェントを使用する myapc という名前の stonith リソースを設定します。pcmk_host_map オプションは z1.example.com をポート 1 にマップし、z2.example.com をポート 2 にマップします。APC デバイスのログイン値とパスワードはいずれも apc です。デフォルトでは、このデバイスは各ノードに対して 60 秒間隔で監視を行います。
ノードのホスト名を指定する場合、IP アドレスを使用することができます。
[root@z1 ~]# pcs stonith create myapc fence_apc_snmp \
ipaddr="zapc.example.com" pcmk_host_map="z1.example.com:1;z2.example.com:2" \
pcmk_host_check="static-list" pcmk_host_list="z1.example.com,z2.example.com" \
login="apc" passwd="apc"

注記

fence_apc_snmp stonith デバイスを作成するときに次のような警告メッセージが表示されることがありますがこのメッセージは無視して構いません。
Warning: missing required option(s): 'port, action' for resource type: stonith:fence_apc_snmp
次のコマンドを使うと既存の STONITH デバイスのパラメーターが表示されます。
[root@rh7-1 ~]# pcs stonith show myapc
 Resource: myapc (class=stonith type=fence_apc_snmp)
  Attributes: ipaddr=zapc.example.com pcmk_host_map=z1.example.com:1;z2.example.com:2 pcmk_host_check=static-list pcmk_host_list=z1.example.com,z2.example.com login=apc passwd=apc
  Operations: monitor interval=60s (myapc-monitor-interval-60s)
フェンスデバイスの設定が終了したら、デバイスのテストを行ってください。フェンスデバイスのテストの説明は、『High Availability Add-On リファレンス』 の フェンス機能: STONITH の設定

注記

ネットワークインターフェースを無効にしてフェンスデバイスのテストを実行しないでください。フェンシングが適切にテストされなくなるためです。

注記

フェンシングが設定され、クラスターが起動されると、ネットワークの再起動により、タイムアウトを超えない場合でもネットワークを再起動するノードのフェンシングがトリガーされます。このため、クラスターサービスの実行中にネットワークサービスを再起動しないでください。ノード上の意図しないフェンシングがトリガーされてしまうためです。

第2章 Red Hat High Availability クラスターのアクティブ/パッシブ Apache HTTP サーバー

本章では、pcs コマンドを使用してクラスターリソースを設定し、2 ノードの Red Hat Enterprise Linux High Availability Add-On クラスターでアクティブ/パッシブな Apache HTTP サーバーを設定する方法を説明します。このユースケースでは、クライアントはフローティング IP アドレスを用いて Apache HTTP サーバーにアクセスします。Web サーバーは 2 つのノードの 1 つで実行されます。Web サーバーが稼働しているノードが正常に動作しなくなった場合、Web サーバーは 2 つ目のノードで再起動され、サービスの中断は最小限になります。
図2.1「2 ノード Red Hat High Availability クラスターの Apache」 はクラスターのハイレベルの概要を示しています。クラスターはネットワーク電源スイッチおよび共有ストレージで設定される 2 ノードの Red Hat High Availability クラスターです。クライアントは仮想 IP を用いて Apache HTTP サーバーへアクセスするため、クラスターノードはパブリックネットワークに接続されます。Apache サーバーはノード 1 またはノード 2 のいずれかで実行されます。いずれのノードも Apache のデータが保持されるストレージへアクセスできます。
2 ノード Red Hat High Availability クラスターの Apache

図2.1 2 ノード Red Hat High Availability クラスターの Apache

このユースケースでは、システムに以下のコンポーネントが必要になります。
  • 各ノードに電源フェンスが設定されている 2 ノードの Red Hat High Availability クラスター。この手順では 1章Pacemaker を使用した Red Hat High Availability クラスターの作成 に記載されているクラスターの例を使用します。
  • Apache に必要なパブリック仮想 IP アドレス。
  • iSCSI またはファイバーチャネルを使用する、クラスターのノードに対する共有ストレージ。
web サーバーで必要とされる LVM リソース、ファイルシステムリソース、IP アドレスリソース、web サーバーリソースなどのクラスターコンポーネントを含ませた Apache リソースグループでクラスターが設定されます。このリソースグループはクラスター内の一つのノードから別のノードへのフェールオーバーが可能なため、いずれのノードでも web サーバーを稼働することができます。クラスターにリソースグループを作成する前に次の手順を行います。
  1. 「LVM ボリュームを ext4 ファイルシステムで設定」 の説明に従い my_lv 論理ボリュームに ext4 ファイルシステムを設定します。
  2. 「Web サーバーの設定」 の説明に従い web サーバーを設定します。
  3. 「ボリュームグループのアクティブ化をクラスター内に限定」 の説明に従い、my_lv を含むボリュームグループの作動はクラスターでしか行えないよう限定し、またボリュームグループが起動時にクラスター以外の場所で作動しないようにします。
上記の手順をすべて完了したら、「pcs コマンドを使用したリソースおよびリソースグループの作成」 の説明に従いリソースグループおよびそのグループに含ませるリソースを作成します。

2.1. LVM ボリュームを ext4 ファイルシステムで設定

このユースケースでは、クラスターのノード間で共有されるストレージに LVM 論理ボリュームを作成する必要があります。
次の手順に従い LVM 論理ボリュームを作成しその論理ボリューム上に ext4 ファイルシステムを作成します。ここでは /dev/sdb1 共有パーティションを使って LVM 論理ボリュームの作成元となる LVM 物理ボリュームを格納します。

注記

LVM ボリューム、該当パーティション、クラスターノードで使用するデバイスなどはクラスターノード以外には接続しないでください。
/dev/sdb1 パーティションは共有させるストレージとなるため、この手順は一つのノードでのみ行います。
  1. LVM 物理ボリュームを /dev/sdb1 パーティション上に作成します。
    # 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. 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
      ...
  4. ext4 ファイルシステムを my_lv 論理ボリューム上に作成します。
    # mkfs.ext4 /dev/my_vg/my_lv
    mke2fs 1.42.7 (21-Jan-2013)
    Filesystem label=
    OS type: Linux
    ...

2.2. Web サーバーの設定

次の手順に従って Apache HTTP サーバーを設定します。
  1. Apache HTTP サーバーがクラスターの各ノードにインストールされているようにしてください。また、Apache HTTP サーバーの状態を確認するには、wget ツールをクラスターにインストールする必要があります。
    各ノードで次のコマンドを実行します。
    # yum install -y httpd wget
  2. Apache リソースエージェントが Apache HTTP サーバーの状態を取得できるようにするため、クラスターの各ノードの /etc/httpd/conf/httpd.conf ファイルに以下のテキストが含まれ、コメントアウトされていないことを確認してください。このテキストが含まれていない場合は、このファイルの最後に追加します。
    <Location /server-status>
        SetHandler server-status
        Require local
    </Location> 
    
  3. apache リソースエージェントを使用して Apache を管理する場合、systemd は使用されません。そのため、Apache のリロードに systemctl が使用されないようにするため、Apache によって提供される logrotate スクリプトを編集する必要があります。
    クラスター内の各ノード上で、/etc/logrotate.d/httpd ファイルから以下の行を削除します。
    /bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true
    削除した行を以下の行に置き換えます。
    /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf -c "PidFile /var/run/httpd.pid" -k graceful > /dev/null 2>/dev/null || true
  4. Apache で提供する web ページを作成します。クラスター内のいずれかのノードに 「LVM ボリュームを ext4 ファイルシステムで設定」 で作成したファイルシステムをマウントし、そのファイルシステム上で index.html ファイルを作成したら再びファイルシステムをアンマウントします。
    # mount /dev/my_vg/my_lv /var/www/
    # mkdir /var/www/html
    # mkdir /var/www/cgi-bin
    # mkdir /var/www/error
    # restorecon -R /var/www
    # cat <<-END >/var/www/html/index.html
    <html>
    <body>Hello</body>
    </html>
    END
    # umount /var/www

2.3. ボリュームグループのアクティブ化をクラスター内に限定

次の手順でボリュームグループを設定すると、クラスターでしかボリュームグループを作動することができなくなり、またボリュームグループは起動時にクラスター以外の場所では作動しなくなります。クラスター以外のシステムでボリュームグループが作動されるとボリュームグループのメタデータが破損する恐れがあります。
この手順では /etc/lvm/lvm.conf 設定ファイル内の volume_list のエントリーを編集します。volume_list のエントリーに記載されているボリュームグループはクラスターマネージャーの管轄外となるローカルノードでの自動作動が許可されます。ノードのローカルな root ディレクトリやホームディレクトリに関連するボリュームグループはこのリストに含ませてください。クラスターマネージャーで管理するボリュームグループは volume_list のエントリーには入れないでください。ここでの手順に clvmd を使用する必要はありません。
クラスター内の各ノードで以下の手順を行います。
  1. 次のコマンドを実行して、/etc/lvm/lvm.conf ファイルで locking_type が 1 に設定されていることと use_lvmetad が 0 に設定されていることを確認します。また、このコマンドを実行すると、すべての lvmetad プロセスがすぐに無効になり、停止します。
    # lvmconf --enable-halvm --services --startstopservices
  2. 次のコマンドでローカルストレージに現在設定されているボリュームグループを確認します。現在設定されているボリュームグループ一覧が出力されます。このノード上に root ディレクトリ用のボリュームグループとホームディレクトリ用のボリュームグループを別々に用意している場合は各ボリュームが以下のように出力されます。
    # vgs --noheadings -o vg_name
      my_vg        
      rhel_home
      rhel_root
  3. my_vg 以外のボリュームグループ (クラスターに定義したボリュームグループ) をエントリとして/etc/lvm/lvm.conf という設定ファイルの volume_list に追加します。
    例えば、root ディレクトリ用のボリュームグループ、ホームディレクトリ用のボリュームグループを別々に用意している場合は、lvm.conf ファイルの volume_list の行のコメントを外して以下のように root ディレクトリ用、ホームディレクトリ用の各ボリュームグループを volume_list のエントリーとして追加します。クラスターに定義したボリュームグループ (この例では my_vg) は、このリストにないことに注意してください。
    volume_list = [ "rhel_root", "rhel_home" ]

    注記

    クラスターマネージャーの管轄外で作動させるローカルボリュームグループがノードにない場合でも volume_list のエントリーは volume_list = [] と指定して初期化する必要があります。
  4. 起動イメージがクラスターで制御しているボリュームグループを作動させないよう initramfs 起動イメージを再構築します。次のコマンドで initramfs デバイスを更新します。このコマンドは完了に 1 分ほどかかる場合があります。
    # dracut -H -f /boot/initramfs-$(uname -r).img $(uname -r)
  5. ノードを再起動します。

    注記

    起動イメージを作成したノードに新しい Linux カーネルをインストールした場合、initrd イメージはそれを作成したときに実行していたカーネル用であってノードを再起動したら実行される新しいカーネル用ではありません。再起動の前後で uname -r コマンドを使って実行しているカーネルリリースを確認し必ず正しい initrd デバイスを使用するよう注意してください。リリースが異なる場合は新しいカーネルで再起動した後、initrd ファイルを更新しノードをもう一度再起動します。
  6. ノードが再起動したら pcs cluster status コマンドを実行し、クラスターサービスがそのノードで再度開始されたかどうかを確認します。Error: cluster is not currently running on this node というメッセージが出力される場合は次のコマンドを実行します。
    # pcs cluster start
    または、クラスター内の各ノードの再起動が完了するのを待ってから次のコマンドで各ノードでのクラスターサービスの起動を行います。
    # pcs cluster start --all

2.4. pcs コマンドを使用したリソースおよびリソースグループの作成

この事例の場合、クラスターリソースを 4 つ作成する必要があります。すべてのリソースが必ず同じノードで実行されるよう apachegroup というリソースグループの一部として構成させます。作成するリソースを起動する順序で以下に示します。
  1. 「LVM ボリュームを ext4 ファイルシステムで設定」 の手順で作成した LVM ボリュームグループを使用する、my_lvm という名前の LVM リソース。
  2. 「LVM ボリュームを ext4 ファイルシステムで設定」 の手順で作成したファイルシステムデバイス /dev/my_vg/my_lv を使用する、my_fs という名前の Filesystem リソース。
  3. apachegroup リソースグループのフローティング IP アドレスである IPaddr2 リソース。すでに物理ノードに関連付けされた IP アドレスは使用できません。IPaddr2 リソースの NIC デバイスが指定されていない場合、クラスターノードによって使用される静的に割り当てられた IP アドレスと同じネットワーク上にフローティング IP が存在しないと、フローティング IP アドレスを割り当てる NIC デバイスが適切に検出されません。
  4. Website と言う名前の apache リソース、「Web サーバーの設定」 の手順で定義した index.html ファイルと Apache 設定を使用します。
次の手順で apachegroup リソースグループとこのグループに含ませるリソースを作成します。リソースはグループに追加した順序で起動し、またその逆順で停止します。次の手順はクラスター内いずれか一つのノードだけで行います。
  1. 次のコマンドでは my_lvm LVM リソースを作成しています。LVM 論理ボリュームの作動がクラスター以外では行えないよう exclusive=true パラメーターを指定しています。この時点で apachegroup リソースグループはまだ存在していないため、このコマンドにより作成されることになります。
    [root@z1 ~]# pcs resource create my_lvm LVM volgrpname=my_vg \
    exclusive=true --group apachegroup
    リソースを作成するとそのリソースは自動的に起動されます。次のコマンドを使ってリソースが確かに作成、起動されたことを確認します。
    # pcs resource show
     Resource Group: apachegroup
         my_lvm	(ocf::heartbeat:LVM):	Started
    pcs resource disablepcs resource enable のコマンドを使用すると手作業によるリソースの停止と起動をリソースごと個別に行うことができます。
  2. 次のコマンドでは構成に必要な残りのリソースを作成し、apachegroup リソースグループに追加しています。
    [root@z1 ~]# pcs resource create my_fs Filesystem \
    device="/dev/my_vg/my_lv" directory="/var/www" fstype="ext4" --group \
    apachegroup
    
    [root@z1 ~]# pcs resource create VirtualIP IPaddr2 ip=198.51.100.3 \
    cidr_netmask=24 --group apachegroup
    
    [root@z1 ~]# pcs resource create Website apache \
    configfile="/etc/httpd/conf/httpd.conf" \
    statusurl="http://127.0.0.1/server-status" --group apachegroup
  3. リソースおよびそのリソースを含ませるリソースグループの作成が完了したらクラスターの状態を確認します。4 つのリソースすべてが同じノードで実行していることを確認してください。
    [root@z1 ~]# pcs status
    Cluster name: my_cluster
    Last updated: Wed Jul 31 16:38:51 2013
    Last change: Wed Jul 31 16:42:14 2013 via crm_attribute on z1.example.com
    Stack: corosync
    Current DC: z2.example.com (2) - partition with quorum
    Version: 1.1.10-5.el7-9abe687
    2 Nodes configured
    6 Resources configured
    
    
    Online: [ z1.example.com z2.example.com ]
    
    Full list of resources:
     myapc	(stonith:fence_apc_snmp):	Started z1.example.com 
     Resource Group: apachegroup
         my_lvm	(ocf::heartbeat:LVM):	Started z1.example.com 
         my_fs	(ocf::heartbeat:Filesystem):	Started z1.example.com 
         VirtualIP	(ocf::heartbeat:IPaddr2):	Started z1.example.com 
         Website	(ocf::heartbeat:apache):	Started z1.example.com
    「排他処理の設定」 の手順でクラスターにフェンスデバイスを設定していないとリソースはデフォルトでは起動しないので注意してください。
  4. クラスターが起動し稼働し始めたら、 ブラウザで IPaddr2 リソースとして定義した IP アドレスをポイントし "Hello" のテキストで構成されるサンプル表示が正しく表示されるか確認します。
    Hello
    設定したリソースが実行していない場合には pcs resource debug-start resource コマンドを実行してリソースの設定をテストしてみます。pcs resource debug-start コマンドの詳細については 『High Availability Add-On Reference (High Availability Add-On リファレンス)』 のガイドを参照してください。

2.5. リソース設定のテスト

「pcs コマンドを使用したリソースおよびリソースグループの作成」 で示すようにクラスターの状態表示では全リソースが z1.example.com ノードで実行しています。次の手順に従い 1 番目のノードを standby モードにしてリソースグループが z2.example.com ノードにフェールオーバーするかどうかテストします。1 番目のノードをスタンバイモードにするとこのノードではリソースをホストできなくなります。
  1. 次のコマンドでは z1.example.comstandby モードにしています。
    root@z1 ~]# pcs cluster standby z1.example.com
  2. z1 をスタンバイモードにしたらクラスターの状態を確認します。リソースがすべて z2 で実行しているはずです。
    [root@z1 ~]# pcs status
    Cluster name: my_cluster
    Last updated: Wed Jul 31 17:16:17 2013
    Last change: Wed Jul 31 17:18:34 2013 via crm_attribute on z1.example.com
    Stack: corosync
    Current DC: z2.example.com (2) - partition with quorum
    Version: 1.1.10-5.el7-9abe687
    2 Nodes configured
    6 Resources configured
    
    
    Node z1.example.com (1): standby
    Online: [ z2.example.com ]
    
    Full list of resources:
    
     myapc	(stonith:fence_apc_snmp):	Started z1.example.com 
     Resource Group: apachegroup
         my_lvm	(ocf::heartbeat:LVM):	Started z2.example.com 
         my_fs	(ocf::heartbeat:Filesystem):	Started z2.example.com 
         VirtualIP	(ocf::heartbeat:IPaddr2):	Started z2.example.com 
         Website	(ocf::heartbeat:apache):	Started z2.example.com
    定義している IP アドレスの web サイトは中断されることなく表示されているはずです。
  3. standby モードから z1 を削除するには、以下のコマンドを実行します。
    root@z1 ~]# pcs cluster unstandby z1.example.com

    注記

    ノードを standby モードから削除しても、リソースがそのノードにフェイルバックされることはありません。実行できるノードリソースの制御に関する詳細は、『Red Hat High Availability Add-On Reference リファレンス』 のクラスターリソースの設定に関する章を参照してください。

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

本章では、共有ストレージを使用して 2 ノードの Red Hat Enterprise Linux High Availability Add-On クラスターで高可用性アクティブ/パッシブ NFS サーバーを設定する方法について説明します。手順では pcs コマンドを使用して Pacemaker クラスターリソースを設定します。このユースケースでは、クライアントはフローティング IP アドレスより NFS ファイルシステムにアクセスします。NFS サービスは、クラスターの 2 つのノードの 1 つで実行されます。NFS サーバーが稼働しているノードが正常に動作しなくなった場合、NFS サーバーはクラスターの 2 つ目のノードで再起動され、サービスの中断は最小限になります。
このユースケースでは、システムに以下のコンポーネントが必要になります。
  • Apache HTTP サーバーを実行するクラスターを作成するために使用される 2 つのノード。この例では、z1.example.comz2.example.com の 2 つのノードが使用されます。
  • 各ノード用の電源フェンスデバイス、ここでは APC 電源スイッチの 2 ポートを使用しています。ホスト名は zapc.example.com にしています。
  • NFS サーバーに必要なパブリック仮想 IP アドレス。
  • iSCSI またはファイバーチャネルを使用する、クラスターのノードに対する共有ストレージ。
2 ノード Red Hat Enterprise Linux で高可用性アクティブ/パッシブ NFS サーバーを設定するには、以下の手順を実行する必要があります。
  1. 「NFS クラスターの作成」 の説明に従って、NFS サーバーを実行するクラスターを作成し、クラスターの各ノードにフェンシングを設定します。
  2. 「LVM ボリュームを ext4 ファイルシステムで設定」 の説明に従って、クラスターのノードに対する共有ストレージの LVM 論理ボリューム my_lv にマウントされた ext4 ファイルシステムを設定します。
  3. 「NFS 共有の設定」 の説明に従って、LVM 論理ボリュームの共有ストレージで NFS 共有を設定します。
  4. 「ボリュームグループのアクティブ化をクラスター内に限定」 の説明に従って、論理ボリューム my_lv が含まれる LVM ボリュームグループをクラスターのみがアクティブ化できるようにし、ボリュームグループが起動時にクラスターの外部でアクティブ化されないようにします。
  5. 「クラスターリソースの設定」 の説明に従って、クラスターリソースを作成します。
  6. 「リソース設定のテスト」 に従って、設定した NFS サーバーをテストします。

3.1. NFS クラスターの作成

以下の手順に従って、NFS クラスターをインストールおよび作成します。
  1. 「クラスターソフトウェアのインストール」 の手順に従って、z1.example.com および z2.example.com ノードにクラスターソフトウェアをインストールします。
  2. 「クラスターの作成」 の手順に従って、z1.example.comz2.example.com で構成される 2 ノードクラスターを作成します。この手順の例と同様に、クラスターには my_cluster という名前が付けられます。
  3. 「排他処理の設定」 の説明に従って、クラスターの各ノードにフェンスデバイスを設定します。この例では、ホスト名が zapc.example.com という APC 電源スイッチの 2 つのポートを使用してフェンシングが設定されます。

3.2. LVM ボリュームを ext4 ファイルシステムで設定

このユースケースでは、クラスターのノード間で共有されるストレージに LVM 論理ボリュームを作成する必要があります。
次の手順に従い LVM 論理ボリュームを作成しその論理ボリューム上に ext4 ファイルシステムを作成します。ここでは /dev/sdb1 共有パーティションを使って LVM 論理ボリュームの作成元となる LVM 物理ボリュームを格納します。

注記

LVM ボリューム、該当パーティション、クラスターノードで使用するデバイスなどはクラスターノード以外には接続しないでください。
/dev/sdb1 パーティションは共有させるストレージとなるため、この手順は一つのノードでのみ行います。
  1. LVM 物理ボリュームを /dev/sdb1 パーティション上に作成します。
    [root@z1 ~]# pvcreate /dev/sdb1
      Physical volume "/dev/sdb1" successfully created
  2. /dev/sdb1 物理ボリュームで構成される my_vg ボリュームグループを作成します。
    [root@z1 ~]# vgcreate my_vg /dev/sdb1
      Volume group "my_vg" successfully created
  3. my_vg ボリュームグループを使用する論理ボリュームを作成します。
    [root@z1 ~]# lvcreate -L450 -n my_lv my_vg
      Rounding up size to full physical extent 452.00 MiB
      Logical volume "my_lv" created
    lvs コマンドを使って論理ボリュームを表示してみます。
    [root@z1 ~]# lvs
      LV      VG      Attr      LSize   Pool Origin Data%  Move Log Copy%  Convert
      my_lv   my_vg   -wi-a---- 452.00m
      ...
  4. ext4 ファイルシステムを my_lv 論理ボリューム上に作成します。
    [root@z1 ~]# mkfs.ext4 /dev/my_vg/my_lv
    mke2fs 1.42.7 (21-Jan-2013)
    Filesystem label=
    OS type: Linux
    ...

3.3. NFS 共有の設定

以下の手順では、NFS デーモンフェールオーバーに対して NFS 共有を設定します。この手順は、クラスターの 1 つのノードのみで行う必要があります。
  1. /nfsshare ディレクトリーを作成します。
    [root@z1 ~]# mkdir /nfsshare
  2. 「LVM ボリュームを ext4 ファイルシステムで設定」 で作成した ext4 ファイルシステムを /nfsshare ディレクトリーにマウントします。
    [root@z1 ~]# mount /dev/my_vg/my_lv /nfsshare
  3. /nfsshare ディレクトリー内に exports ディレクトリーツリーを作成します。
    [root@z1 ~]# mkdir -p /nfsshare/exports
    [root@z1 ~]# mkdir -p /nfsshare/exports/export1
    [root@z1 ~]# mkdir -p /nfsshare/exports/export2
  4. NFS クライアントがアクセスするファイルを exports ディレクトリーに置きます。この例では、clientdatafile1 および clientdatafile2 という名前のテストファイルを作成します。
    [root@z1 ~]# touch /nfsshare/exports/export1/clientdatafile1
    [root@z1 ~]# touch /nfsshare/exports/export2/clientdatafile2
  5. ext4 ファイルをアンマウントし、LVM ボリュームグループを非アクティブ化します。
    [root@z1 ~]# umount /dev/my_vg/my_lv
    [root@z1 ~]# vgchange -an my_vg

3.4. ボリュームグループのアクティブ化をクラスター内に限定

次の手順では、LVM ボリュームグループを設定して、クラスターのみがボリュームグループをアクティブ化でき、ボリュームグループが起動時にクラスターの外部でアクティブ化されないようにします。ボリュームグループがクラスター外部のシステムによってアクティブ化されると、ボリュームグループのメタデータが破損することがあります。
この手順では /etc/lvm/lvm.conf 設定ファイル内の volume_list のエントリーを編集します。volume_list のエントリーに記載されているボリュームグループはクラスターマネージャーの管轄外となるローカルノードでの自動作動が許可されます。ノードのローカルな root ディレクトリやホームディレクトリに関連するボリュームグループはこのリストに含ませてください。クラスターマネージャーで管理するボリュームグループは volume_list のエントリーには入れないでください。ここでの手順に clvmd を使用する必要はありません。
クラスター内の各ノードで以下の手順を行います。
  1. 次のコマンドを実行して、/etc/lvm/lvm.conf ファイルで locking_type が 1 に設定されていることと use_lvmetad が 0 に設定されていることを確認します。また、このコマンドを実行すると、すべての lvmetad プロセスがすぐに無効になり、停止します。
    # lvmconf --enable-halvm --services --startstopservices
  2. 次のコマンドでローカルストレージに現在設定されているボリュームグループを確認します。現在設定されているボリュームグループ一覧が出力されます。このノード上に root ディレクトリ用のボリュームグループとホームディレクトリ用のボリュームグループを別々に用意している場合は各ボリュームが以下のように出力されます。
    # vgs --noheadings -o vg_name
      my_vg        
      rhel_home
      rhel_root
  3. /etc/lvm/lvm.conf 設定ファイルの volume_list のエントリーとして my_vg (クラスター用として定義したボリュームグループ) 以外のボリュームグループを追加します。例えば、root ディレクトリ用のボリュームグループ、ホームディレクトリ用のボリュームグループを別々に用意している場合は、lvm.conf ファイルの volume_list の行のコメントを外して以下のように root ディレクトリ用、ホームディレクトリ用の各ボリュームグループを volume_list のエントリーとして追加します。
    volume_list = [ "rhel_root", "rhel_home" ]

    注記

    クラスターマネージャーの管轄外で作動させるローカルボリュームグループがノードにない場合でも volume_list のエントリーは volume_list = [] と指定して初期化する必要があります。
  4. 起動イメージがクラスターで制御しているボリュームグループを作動させないよう initramfs 起動イメージを再構築します。次のコマンドで initramfs デバイスを更新します。このコマンドは完了に 1 分ほどかかる場合があります。
    # dracut -H -f /boot/initramfs-$(uname -r).img $(uname -r)
  5. ノードを再起動します。

    注記

    起動イメージを作成したノードに新しい Linux カーネルをインストールした場合、initrd イメージはそれを作成したときに実行していたカーネル用であってノードを再起動したら実行される新しいカーネル用ではありません。再起動の前後で uname -r コマンドを使って実行しているカーネルリリースを確認し必ず正しい initrd デバイスを使用するよう注意してください。リリースが異なる場合は新しいカーネルで再起動した後、initrd ファイルを更新しノードをもう一度再起動します。
  6. ノードが再起動したら pcs cluster status コマンドを実行し、クラスターサービスがそのノードで再度開始されたかどうかを確認します。Error: cluster is not currently running on this node というメッセージが出力される場合は次のコマンドを実行します。
    # pcs cluster start
    この代わりに、クラスターの各ノードを再起動し、再起動が完了してから次のコマンドを実行してクラスターのすべてのノードでクラスターサービスを開始することもできます。
    # pcs cluster start --all

3.5. クラスターリソースの設定

このユースケースでクラスターリソースを設定する手順について説明します。

注記

pcs resource create コマンドを使用してクラスターリソースを作成する場合、作成直後に pcs status コマンドを実行してリソースが稼働していることを検証することが推奨されます。「排他処理の設定」 の説明に従ってクラスターのフェンスデバイスを設定していない場合、デフォルトではリソースが起動しません。
設定したリソースが実行されていない場合は、pcs resource debug-start resource コマンドを実行してリソースの設定をテストできます。このコマンドは、クラスターの制御や認識の範囲外でサービスを起動します。設定したリソースが再度実行されたら、pcs resource cleanup resource コマンドを実行してクラスターが更新を認識するようにします。pcs resource debug-start コマンドの詳細は 『High Availability Add-On リファレンス』 を参照してください。
以下の手順では、システムリソースを設定します。これらのリソースがすべて同じノードで実行されるようにするため、これらのリソースはリソースグループ nfsgroup の一部として設定されます。リソースは、グループに追加された順序で起動し、その逆の順序で停止します。この手順は、クラスターの 1 つのノードのみで実行してください。
  1. 以下のコマンドは my_lvm という名前の LVM リソースを作成します。このコマンドは、exclusive=true パラメーターを指定し、クラスターのみが LVM 論理ボリュームをアクティブ化できるようにします。この時点ではリソースグループ nfsgroup は存在しないため、このコマンドによって作成されます。
    [root@z1 ~]# pcs resource create my_lvm LVM volgrpname=my_vg \
    exclusive=true --group nfsgroup
    クラスターの状態を確認し、リソースが実行されていることを確認します。
    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
  2. クラスターの Filesystem リソースを設定します。

    注記

    options=options パラメーターを使用すると、Filesystem リソースのリソース設定の一部としてマウントオプションを指定できます。完全な設定オプションを表示するには、pcs resource describe Filesystem コマンドを実行します。
    以下のコマンドは、nfsshare という名前の ext4 Filesystem リソースを nfsgroup リソースグループの一部として設定します。このファイルシステムは、「LVM ボリュームを ext4 ファイルシステムで設定」 で作成された LVM ボリュームグループと ext4 ファイルシステムを使用します。このファイルシステムは 「NFS 共有の設定」 で作成された /nfsshare ディレクトリーにマウントされます。
    [root@z1 ~]# pcs resource create nfsshare Filesystem \
    device=/dev/my_vg/my_lv directory=/nfsshare \
    fstype=ext4 --group nfsgroup
    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
    ...
  3. nfsgroup リソースグループの一部である nfs-daemon という名前の nfsserver リソースを作成します。

    注記

    nfsserver リソースを使用して、nfs_shared_infodir パラメーターを指定できます。これは、NFS デーモンが、NFS 関連のステートフル情報を保管するのに使用するディレクトリーです。この属性は、このエクスポートのコレクションで作成した Filesystem リソースのいずれかのサブディレクトリーに設定することが推奨されます。これにより、NFS デーモンは、このリソースグループを再度移動する必要が生じた場合に、別のノードで利用可能になるステートフル情報をデバイスに保存します。この例では、/nfsshareFilesystem リソースで管理される共有ストレージディレクトリーで、/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
    ...
  4. exportfs リソースを追加して /nfsshare/exports ディレクトリーをエクスポートします。これらのリソースは nfsgroup リソースグループの一部です。これにより、NFSv4 クライアントの仮想ディレクトリーが構築されます。NFSv3 クライアントもこれらのエクスポートにアクセスできます。
    [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
  5. NFS 共有にアクセスするために NFS クライアントが使用するフローティング IP アドレスリソースを追加します。指定するフローティング IP アドレスには DNS リバースルックアップが必要になりますが、クラスターのすべてのノードで /etc/hosts にフローティング 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
  6. NFS デプロイメント全体が初期化されたら、NFSv3 の再起動通知を送信するため nfsnotify リソースを追加します。このリソースは、リソースグループ nfsgroup の一部です。

    注記

    NFS の通知が適切に処理されるようにするには、フローティング IP アドレスとホスト名が関連付けられ、NFS サーバーと NFS クライアントの両方で一貫性を保つ必要があります。
    [root@z1 ~]# pcs resource create nfs-notify nfsnotify \
    source_host=192.168.122.200 --group nfsgroup
リソースとリソースの制約を作成したら、クラスターの状態をチェックできます。すべてのリソースは同じノードで実行されていることに注意してください。
[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.6. リソース設定のテスト

以下の手順を使用するとシステムの設定を検証できます。NFSv3 または NFSv4 のいずれかでエクスポートされたファイルシステムをマウントできるはずです。
  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
  4. フェイルオーバーをテストするには、以下の手順を実行します。
    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 cluster 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 を実行していたノードをスタンバイノードから削除します。これだけでは、クラスターリソースはこのノードに戻されません。
      [root@z1 ~]# pcs cluster unstandby z1.example.com

第4章 Red Hat High Availability クラスター (Red Hat Enterprise Linux 7.4 以降) のアクティブ/アクティブ Samba サーバー

Red Hat Enterprise Linux 7.4 リリースでは、Red Hat の High Availability Add-On は、Pacemaker を使用して、アクティブ/アクティブクラスタ構成での Samba の実行に対応しています。本章では、共有ストレージを使用した 2 ノードの Red Hat Enterprise Linux High Availability Add-On クラスターでアクティブ/アクティブ Samba サーバーを構成する方法を説明します。この手順では、Pacemaker クラスターリソースの構成に pcs を使用します。
このユースケースでは、システムに以下のコンポーネントが必要になります。
  • Clustered Samba を実行しているクラスターの作成に使用する 2 つのノード。この例で使用するノードは  z1.example.comz2.example.com で、それぞれの IP アドレスは 192.168.1.151192.168.1.152 です。
  • 各ノード用の電源フェンスデバイス、ここでは APC 電源スイッチの 2 ポートを使用しています。ホスト名は zapc.example.com にしています。
  • iSCSI またはファイバーチャネルを使用する、クラスターのノードに対する共有ストレージ。
2 ノード Red Hat Enterprise Linux High Availability Add-On クラスターで高可用性アクティブ/アクティブ NFS サーバーを設定するには、以下のステップを実行する必要があります。
  1. 「NFS クラスターの作成」 の説明に従い、Samba 共有をエクスポートして、クラスターの各ノードに対するフェンシングを構成します。
  2. 「LVM ボリュームを ext4 ファイルシステムで設定」 の説明に従い、クラスターのノードに対する共有ストレージ上のクラスター化された LVM 論理ボリューム my_clv にマウントした gfs2 ファイルシステムを設定します。
  3. 「Samba の設定」 を参照してクラスターの各ノードで Samba を設定します。
  4. 「Samba クラスターリソースの設定」 の説明に従って、Samba クラスターリソースを作成します。
  5. 「リソース設定のテスト」 に従って、設定した Samba 共有をテストします。

4.1. クラスターの作成

次の手順に従って、Samba サービスに使用するクラスターのインストールと作成を行います。
  1. 「クラスターソフトウェアのインストール」 の手順に従って、z1.example.com および z2.example.com ノードにクラスターソフトウェアをインストールします。
  2. 「クラスターの作成」 の手順に従って、z1.example.comz2.example.com で構成される 2 ノードクラスターを作成します。この手順の例と同様に、クラスターには my_cluster という名前が付けられます。
  3. 「排他処理の設定」 の説明に従って、クラスターの各ノードにフェンスデバイスを設定します。この例では、ホスト名が zapc.example.com という APC 電源スイッチの 2 つのポートを使用してフェンシングが設定されます。

4.2. GFS2 ファイルシステムでのクラスター化 LVM ボリュームの構成

このユースケースでは、クラスターのノード間で共有しているストレージにクラスター化 LVM 論理ボリュームを作成する必要があります。
本項では、クラスター化 LVM 論理ボリュームを GFS2 ファイルシステムでそのボリューム上に作成します。この例では /dev/vdb 共有パーティションを使って LVM 論理ボリュームの作成元となる LVM 物理ボリュームを格納します。

注記

LVM ボリューム、該当パーティション、クラスターノードで使用するデバイスなどはクラスターノード以外には接続しないでください。
この手順を始める前に、Resilient Storage チャンネルの lvm2-clustergfs2-utils パッケージをクラスターの両方のノードにインストールします。
# yum install lvm2-cluster gfs2-utils
/dev/vdb パーティションは共有させるストレージとなるため、この手順は 1 つのノードでのみ行います。
  1. グローバル Pacemaker パラメーターを no_quorum_policy から freeze に設定します。この設定により、クォーラムが失われるたびにクラスター全体にフェンシングが発生しなくなります。このポリシーの設定についての詳細は、『Global File System 2』 を参照してください。
    [root@z1 ~]# pcs property set no-quorum-policy=freeze
  2. dlm リソースを設定します。これは、clvmd サービスと GFS2 ファイルシステムに必要な依存関係です。
    [root@z1 ~]# pcs resource create dlm ocf:pacemaker:controld op monitor interval=30s on-fail=fence clone interleave=true ordered=true
  3. clvmd をクラスターリソースとしてセットアップします。
    [root@z1 ~]# pcs resource create clvmd ocf:heartbeat:clvm op monitor interval=30s on-fail=fence clone interleave=true ordered=true
    この開始手順の一環として、ocf:heartbeat:clvm リソースエージェントにより、/etc/lvm/lvm.conf ファイルの locking_type パラメーターが 3 に変更され、lvmetad デーモンが無効化されることに注意してください。
  4. clvmd および dlm の依存関係をセットアップし、順番に起動します。clvmd リソースは dlm の後に起動し、dlm と同じノードで実行する必要があります。
    [root@z1 ~]# pcs constraint order start dlm-clone then clvmd-clone
    Adding dlm-clone clvmd-clone (kind: Mandatory) (Options: first-action=start then-action=start)
    [root@z1 ~]# pcs constraint colocation add clvmd-clone with dlm-clone
  5. dlm および clvmd リソースが全てのノードで実行されていることを確認します。
    [root@z1 ~]# pcs status
    ...
    Full list of resources:
    ...
     Clone Set: dlm-clone [dlm]
         Started: [ z1 z2 ]
     Clone Set: clvmd-clone [clvmd]
         Started: [ z1 z2 ]
  6. クラスター化論理ボリュームの作成
    [root@z1 ~]# pvcreate /dev/vdb
    [root@z1 ~]# vgcreate -Ay -cy cluster_vg /dev/vdb
    [root@z1 ~]# lvcreate -L4G -n cluster_lv cluster_vg
  7. ボリュームが正しく作成されているかどうかを確認するには、論理ボリュームを表示する lvs コマンドを使用します。
    [root@z1 ~]# lvs
      LV         VG         Attr       LSize ...
      cluster_lv cluster_vg -wi-ao---- 4.00g
      ...
  8. GFS2 でボリュームをフォーマットします。この例では、my_cluster がクラスター名です。また、2 つのジャーナルを示すために -j 2 を指定しています。これは、ジャーナルの数が、クラスターのノードの数に一致する必要があるためです。
    [root@z1 ~]# mkfs.gfs2 -p lock_dlm -j 2 -t my_cluster:samba /dev/cluster_vg/cluster_lv
  9. ファイルシステムのマウントと管理を行うように Pacemaker を設定するための Filesystem リソースを作成します。この例では、fs という Filesystem リソースを作成し、両方のクラスターで /mnt/gfs2share を作成します。
    [root@z1 ~]# pcs resource create fs ocf:heartbeat:Filesystem device="/dev/cluster_vg/cluster_lv" directory="/mnt/gfs2share" fstype="gfs2" --clone
  10. GFS2 ファイルシステムと clvmd のサービスとの依存関係を構成し、順番に起動します。GFS2 は clvmd の後に起動し、clvmd と同じノードで実行する必要があります。
    [root@z1 ~]# pcs constraint order start clvmd-clone then fs-clone
    Adding clvmd-clone fs-clone (kind: Mandatory) (Options: first-action=start then-action=start)
    [root@z1 ~]# pcs constraint colocation add fs-clone with clvmd-clone
  11. 想定通りに GFS2 ファイルがマウントされていることを確認します。
    [root@z1 ~]# mount |grep /mnt/gfs2share
    /dev/mapper/cluster_vg-cluster_lv on /mnt/gfs2share type gfs2 (rw,noatime,seclabel)

4.3. Samba の設定

以下の手順では、Samba 環境を初期化し、クラスターノードで Samba を設定します。
  1. クラスターの両方のノードで、以下の手順を実行します。
    1. sambactdbcifs-utils をインストールします。
      # yum install samba ctdb cifs-utils
    2. firewalld デーモンを実行している場合は、以下のコマンドを実行して、 ctdbsamba サービスに必要なポートを有効にします。
      # firewall-cmd --add-service=ctdb --permanent
      # firewall-cmd --add-service=samba --permanent
      # firewall-cmd --reload
    3. 以下のコマンドを実行して、ctdb や samba サービスが動作しておらず、ブート時に起動しないようにします。これら 2 つのサービスがお使いのシステムに存在して動作しているわけではないことに注意してください。
      # systemctl disable ctdb
      # systemctl disable smb
      # systemctl disable nmb
      # systemctl disable winbind
      # systemctl stop ctdb
      # systemctl stop smb
      # systemctl stop nmb
      # systemctl stop winbind
    4. /etc/samba/smb.conf ファイルでは、Samba サーバーを設定して [public] 共有定義を設定します。例:
      # cat << END > /etc/samba/smb.conf
      [global]
      netbios name = linuxserver
      workgroup = WORKGROUP
      server string = Public File Server
      security = user
      map to guest = bad user
      guest account = smbguest
      clustering = yes
      ctdbd socket = /tmp/ctdb.socket
      [public]
      path = /mnt/gfs2share/public
      guest ok = yes
      read only = no
      END
      この例で見られるように Samba をスタンドアローンサーバーとして設定する方法や、testparm ユーティリティで smb.conf ファイルを検証する方法は、『システム管理者のガイド』の ファイルとプリントサーバーを参照してください。
    5. クラスターノードの IP アドレスを /etc/ctdb/nodes ファイルに追加します。
      # cat << END > /etc/ctdb/nodes
      192.168.1.151
      192.168.1.152
      END
    6. クラスターのノード間における負荷分散は、このクラスターによってエクスポートされた Samba 共有へのアクセスに使用できる 2 つ以上の IP アドレスを /etc/ctdb/public_addresses ファイルに追加できます。この IP は、Samba サーバーの名前の DNS で設定する必要があるアドレスで、SMB クライアントが接続するアドレスです。複数の IP アドレスで 1 つのタイプ A の DNS レコードとして Samba サーバーの名前を設定し、ラウンドロビンがクラスターのノードにわたりクライアントを分散できるようにします。
      この例では、DNS エントリ linuxserver.example.com が、/etc/ctdb/public_addresses ファイル下にリストされている両方のアドレスで定義されています。これにより、DNS によって、ラウンドロビン方式でクラスターノードにわたり Samba クライアントが分散されます。この操作を行う際、DNS エントリがニーズに一致する必要があります。
      このクラスターによってエクスポートされた Samba 共有へのアクセスに使用できる IP アドレスを /etc/ctdb/public_addresses ファイルに追加します。
      # cat << END > /etc/ctdb/public_addresses
      192.168.1.201/24 eth0
      192.168.1.202/24 eth0
      END
    7. Samba グループを作成し、パブリックテスト共有ディレクトリのローカルユーザーを追加して、以前に作成したグループをプライマリグループとして設定します。
      # groupadd smbguest
      # adduser smbguest -g smbguest
    8. CTDB 関連のディレクトリで SELinux コンテキストが 正しいことを確認してください。
      # mkdir /var/ctdb/
      # chcon -Rv -u system_u -r object_r -t ctdbd_var_lib_t /var/ctdb/
      changing security context of ‘/var/ctdb/’
      # chcon -Rv -u system_u -r object_r -t ctdbd_var_lib_t /var/lib/ctdb/
      changing security context of ‘/var/lib/ctdb/’
  2. クラスターの 1 つのノードで、以下の手順に従います。
    1. CTDB ロックファイルとパブリック共有のディレクトリを設定します。
      [root@z1 ~]# mkdir -p /mnt/gfs2share/ctdb/
      [root@z1 ~]# mkdir -p /mnt/gfs2share/public/
    2. GFS2 共有上の SELinux コンテキストを更新します。
      [root@z1 ~]# chown smbguest:smbguest /mnt/gfs2share/public/
      [root@z1 ~]# chmod 755 /mnt/gfs2share/public/
      [root@z1 ~]# chcon -Rv -t ctdbd_var_run_t /mnt/gfs2share/ctdb/
      changing security context of ‘/mnt/gfs2share/ctdb/’
      [root@z1 ~]# chcon -Rv -u system_u -r object_r -t samba_share_t /mnt/gfs2share/public/
      changing security context of ‘/mnt/gfs2share/public’

4.4. Samba クラスターリソースの設定

本項では、このユースケースで Samba クラスターリソースを設定する手順について説明します。
次の手順では、samba.cib というクラスターの cib のスナップショットを作成し、実行しているクラスターで直接リソースを設定するのではなく、リソースをテストファイルに追加します。リソースと制約を設定すると、この手順により、実行しているクラスター設定に samba.cib がプッシュされます。
クラスターの 1 ノードで、以下の手順を行います。
  1. クラスター設定ファイルの cib ファイルのスナップショットを作成します。
    [root@z1 ~]# pcs cluster cib samba.cib
  2. Samba が使用する CTDB リソースを作成します。このリソースは、両方のクラスタノードで実行できるようにクローンリソースとして作成してください。
    [root@z1 ~]# pcs -f samba.cib resource create ctdb ocf:heartbeat:CTDB \
    ctdb_recovery_lock="/mnt/gfs2share/ctdb/ctdb.lock" \
    ctdb_dbdir=/var/ctdb ctdb_socket=/tmp/ctdb.socket \
    ctdb_logfile=/var/log/ctdb.log \
    op monitor interval=10 timeout=30 op start timeout=90 \
    op stop timeout=100 --clone
  3. クローン Samba サーバーを作成します。
    [root@z1 ~]# pcs -f samba.cib resource create samba systemd:smb --clone
  4. クラスターリソースのコロケーションと順序の制約を作成します。起動順序は、Filesystem リソース、CTDB リソース、Samba リソースです。
    [root@z1 ~]# pcs -f samba.cib constraint order fs-clone then ctdb-clone
    Adding fs-clone ctdb-clone (kind: Mandatory) (Options: first-action=start then-action=start)
    [root@z1 ~]# pcs -f samba.cib constraint order ctdb-clone then samba-clone
    Adding ctdb-clone samba-clone (kind: Mandatory) (Options: first-action=start then-action=start)
    [root@z1 ~]# pcs -f samba.cib constraint colocation add ctdb-clone with fs-clone
    [root@z1 ~]# pcs -f samba.cib constraint colocation add samba-clone with ctdb-clone
  5. cib スナップショットのコンテンツをクラスターにプッシュします。
    [root@z1 ~]# pcs cluster cib-push samba.cib
    CIB updated
  6. クラスターの状態を確認し、リソースが実行されていることを確認します。
    Red Hat Enterprise Linux 7.4 では、CTDB による Samba の起動、共有のエクスポート、安定化にしばらく時間がかかることがあります。このプロセスの前にクラスターステータスを確認すると、CTDB ステータスの呼び出しが失敗したというメッセージが表示されることがあります。このプロセスが完了すれば、pcs resource cleanup ctdb-clone コマンドを使用して表示されたメッセージを消去できます。
    [root@z1 ~]# pcs status
    Cluster name: my_cluster
    Stack: corosync
    Current DC: z1.example.com (version 1.1.16-12.el7_4.2-94ff4df) - partition with quorum
    Last updated: Thu Oct 19 18:17:07 2017
    Last change: Thu Oct 19 18:16:50 2017 by hacluster via crmd on z1.example.com
    
    2 nodes configured
    11 resources configured
    
    Online: [ z1.example.com z2.example.com ]
    
    Full list of resources:
    
     myapc  (stonith:fence_apc_snmp):       Started z1.example.com
     Clone Set: dlm-clone [dlm]
         Started: [ z1.example.com z2.example.com ]
     Clone Set: clvmd-clone [clvmd]
         Started: [ z1.example.com z2.example.com ]
     Clone Set: fs-clone [fs]
         Started: [ z1.example.com z2.example.com ]
     Clone Set: ctdb-clone [ctdb]
         Started: [ z1.example.com z2.example.com ]
     Clone Set: samba-clone [samba]
         Started: [ z1.example.com z2.example.com ]

    注記

    設定したリソースが実行されていない場合は、pcs resource debug-start resource コマンドを実行してリソースの設定をテストできます。このコマンドは、クラスターの制御や認識の範囲外でサービスを起動します。設定したリソースが再度実行された場合は、pcs resource cleanup resource コマンドを実行してクラスターが更新を認識するようにします。pcs resource debug-start コマンドの詳細は、 『High Availability Add-On リファレンス』 の クラスターリソースの有効化、無効化、および禁止 の項を参照してください。

4.5. リソース設定のテスト

Samba の構成に成功した場合は、クラスターのノードで Samba 共有をマウントできます。以下の例の手順では、Samba 共有をマウントしています。
  1. クラスターノードの既存のユーザーを smbpasswd ファイルに追加してパスワードを割り当てます。以下の例では、既存のユーザー smbuser を追加しています。
    [root@z1 ~]# smbpasswd -a smbuser
    New SMB password:
    Retype new SMB password:
    Added user smbuser
  2. Samba 共有をマウントします。
    [root@z1 ~]# mkdir /mnt/sambashare
    [root@z1 ~]# mount -t cifs -o user=smbuser //198.162.1.151/public /mnt/sambashare
    Password for smbuser@//198.162.1.151/public:  ********
  3. ファイルシステムがマウントされているかどうかを確認します。
    [root@z1 ~]# mount | grep /mnt/sambashare
    //198.162.1.151/public on /mnt/sambashare type cifs (rw,relatime,vers=1.0,cache=strict,username=smbuser,domain=LINUXSERVER,uid=0,noforceuid,gid=0,noforcegid,addr=10.37.167.205,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=65536,echo_interval=60,actimeo=1)
Samba の復元を確認するには、以下の手順を行います。
  1. 以下のコマンドを使用して CTDB リソースを手動で停止します。
    [root@z1 ~]# pcs resource debug-stop ctdb
  2. このリソースを停止すると、システムによってサービスが復元されます。pcs status コマンドを使用してクラスターのステータスを確認します。ctdb-clone リソースが開始したことがわかりますが、ctdb_monitor がエラーしたこともわかります。
    [root@z1 ~]# pcs status
    ...
    Clone Set: ctdb-clone [ctdb]
         Started: [ z1.example.com z2.example.com ]
    ...
    Failed Actions:
    * ctdb_monitor_10000 on z1.example.com 'unknown error' (1): call=126, status=complete, exitreason='CTDB status call failed: connect() failed, errno=111',
        last-rc-change='Thu Oct 19 18:39:51 2017', queued=0ms, exec=0ms
    ...
    このステータスのエラーを消去するには、クラスターノードの 1 つで以下のコマンドを実行します。
    [root@z1 ~]# pcs resource cleanup ctdb-clone

付録A 改訂履歴

改訂履歴
改訂 5-2Thu Oct 4 2018Steven Levine
7.6 GA 公開用ドキュメントの準備
改訂 4-2Wed Mar 14 2018Steven Levine
7.5 GA 公開用ドキュメントの準備
改訂 4-1Thu Dec 14 2017Steven Levine
7.5 ベータ版公開用ドキュメントの準備
改訂 3-4Wed Aug 16 2017Steven Levine
7.4 のバージョンを更新
改訂 3-3Wed Jul 19 2017Steven Levine
7.4 GA 公開用ドキュメントバージョン
改訂 3-1Wed May 10 2017Steven Levine
7.4 ベータ公開用ドキュメントの準備
改訂 2-6Mon Apr 17 2017Steven Levine
7.3 の更新
改訂 2-4Mon Oct 17 2016Steven Levine
7.3 GA 公開用バージョン
改訂 2-3Fri Aug 12 2016Steven Levine
7.3 ベータ公開用ドキュメントの準備
改訂 1.2-3Mon Nov 9 2015Steven Levine
7.2 GA 公開用ドキュメントの準備。
改訂 1.2-2Tue Aug 18 2015Steven Levine
7.2 ベータ公開用ドキュメントの準備 。
改訂 1.1-19Mon Feb 16 2015Steven Levine
7.1 GA リリース向けのバージョン
改訂 1.1-10Thu Dec 11 2014Steven Levine
7.1 ベータリリース向けバージョン
改訂 0.1-33Mon Jun 2 2014Steven Levine
7.0 GA リリース向けバージョン

法律上の通知

Copyright © 2018 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.