第7章 高可用性機能の構成

目次

この章では、複数ノードにわたり実行されているサービスへの継続的なアクセスを提供するHAクラスタを作成するためにPacemakerおよびCorosyncテクノロジを構成する方法について説明します。

7.1 Oracle Linux高可用性サービスについて

Oracle Linux高可用性サービスは、CorosyncやPacemakerなどのいくつかのオープンソース・パッケージで構成されており、Oracle Linux上で実行されるアプリケーションおよびサービスの高可用性を実現するためのツールを提供します。Corosync、Pacemakerおよび機能サブパッケージは、https://linux.oracle.comでUnbreakable Linux Networkから、またはhttps://yum.oracle.comでOracle Linux yumサーバーからダウンロードできます。

Corosyncはオープン・ソースのクラスタ・エンジンであり、これには、プロセスを障害発生時に再起動できる可用性マネージャ、構成および統計データベース、およびクォーラムが達成されたか失われた場合にアプリケーションに通知できるクォーラム・システムなど、多数の高可用性機能を実装するためのAPIが含まれています。

Corosyncは、クラスタ上にデプロイされたソフトウェアのライフサイクルの管理、および高可用性サービスの提供を担当するオープン・ソースの高可用性クラスタ・リソース・マネージャであるPacemakerとともにインストールします。高可用性サービスは、このクラスタ・エンジンによって提供されるAPIを介して、ノードおよびリソース・レベルの障害を検出およびリカバリすることで実現されます。

また、Pacemakerには、クラスタとそのリソースへのアクセスおよび構成に使用できるPacemakerコマンド・シェル(pcs)も付属しています。pcsデーモンは、クラスタ内の各ノードでサービスとして実行されます。これにより、クラスタ内のすべてのノードにわたり構成変更を同期できます。

オラクル社は、Oracle Linux 7.3以上でのアクティブ/パッシブの2ノード(1:1)のクラスタ構成に使用するCorosyncおよびPacemakerのサポートを提供しています。クラスタリング・サービスのサポートは、これらのサービスを使用してクラスタ化されたOracle製品のサポートを意味するわけではありません。

オラクル社は、Oracle Databaseを使用した高可用性クラスタリングのためにOracle Clusterwareも提供しています。詳細は、https://www.oracle.com/database/technologies/rac/clusterware.htmlを参照してください。

7.2 PacemakerおよびCorosyncのインストール

クラスタ内の各ノードで、pcsおよびpacemakerソフトウェア・パッケージを、Oracle Linux yumサーバーまたはUnbreakable Linux Networkから入手可能なすべてのリソースおよびフェンス・エージェントとともにインストールします。 

# yum install pcs pacemaker resource-agents fence-agents-all

firewalldを実行している場合は、サービス・コンポーネントがネットワーク間で通信できるように、各ノードにhigh-availabilityサービスを追加する必要があります。通常、この手順では、TCPポート2224 (pcsデーモンで使用)、3121 (Pacemaker Remoteノード用)および21064 (DLMリソース用)、ならびにUDPポート5405 (Corosyncクラスタリング用)および5404 (Corosyncマルチキャスト用、これが構成されている場合)を有効にします。 

# firewall-cmd --permanent --add-service=high-availability
# firewall-cmd --add-service=high-availability

pcsコマンドを使用してクラスタを構成および管理するには、haclusterユーザー用に各ノードでパスワードを設定する必要があります。このユーザーに設定するパスワードを各ノードで同じにしておくと便利です。各ノードでpasswdコマンドを使用して、パスワードを設定します。 

# passwd hacluster

pcsコマンドを使用するには、クラスタ内の各ノードでpcsdサービスが実行されている必要があります。次のコマンドを使用して、このサービスが実行されるように設定することや、ブート時に開始されるように設定することができます。 

# systemctl start pcsd.service
# systemctl enable pcsd.service

7.3 初期クラスタとサービスの構成

次の例では、node1およびnode2という解決可能なホスト名でシステムでホストされている2つのノードにわたる、1つのクラスタを構成します。各システムは、第7.2項「PacemakerおよびCorosyncのインストール」で示した手順でインストールされ構成されています。

このクラスタは、pacemakerパッケージとともにインストールする必要があるresource-agentsパッケージに含まれている、サービスDummyを実行するように構成されています。このツールでは、それが動作しているかどうかの追跡のみを実行します。ここでは、Pacemakerを、Dummyプロセスが失敗したかどうかを判断するためのチェック間の待機時間を決める間隔パラメータを指定して構成します。

Pacemakerツールの外部でDummyプロセスを手動で停止して失敗をシミュレーションし、これにより、どのように代替ノードでプロセスが自動的に再起動されるかを示します。

クラスタの作成

  1. 構成内の各ノードでhaclusterユーザーのpcsクラスタ構成ツールを認証します。これを行うには、クラスタに含める予定のノードのいずれかで、次のコマンドを実行します。 

    # pcs cluster auth node1 node2 -u hacluster

    node1およびnode2を、クラスタに含める予定のノードの解決可能ホスト名に置き換えます。ツールにより、haclusterユーザーのパスワードを求めるプロンプトが表示されます。各ノードでPacemakerソフトウェアをインストールして構成したときにこのユーザー用に設定したパスワードを指定する必要があります。

  2. クラスタを作成するには、pcs cluster setupコマンドを使用します。クラスタの名前、およびクラスタ内の各ノードの解決可能ホスト名を指定する必要があります。 

    # pcs cluster setup --name pacemaker1 node1 node2

    pacemaker1をクラスタの適切な名前に置き換えます。node1およびnode2を、クラスタ内のノードの解決可能ホスト名に置き換えます。

  3. すべてのノードでこのクラスタを起動します。これを手動で実行するには、次のようにpcsコマンドを使用します。 

    # pcs cluster start --all

    また、次のようにsystemdからpacemakerおよびcorosyncサービスを起動することでもこれを実行できます。 

    # systemctl start pacemaker.service
# systemctl start corosync.service

    オプションで、次のようにして、これらのサービスをブート時に起動するように有効化できます。それにより、ノードの再起動時に自動的にそれがクラスタに再参加するようになります。 

    # systemctl enable pacemaker.service
# systemctl enable corosync.service

    ユーザーによっては、システム全体の再起動につながるノード障害を、そのノードがクラスタに再参加する前に適切にデバッグできるように、これらのサービスを有効にしないでおく場合があります。

クラスタ・パラメータの設定

  1. フェンシングは、障害が発生したか使用できないノードによってデータが破損しないようにするための高度な機能です。Pacemakerでは、stonith (shoot the other node in the head)という用語を使用してフェンシングのオプションを記述します。この構成は、特定のハードウェアに依存しており、フェンシング・プロセスの深い理解を必要とするため、この例ではフェンシング機能を無効にすることをお薦めします。 

    # pcs property set stonith-enabled=false

    フェンシングは、本番レベルのHAクラスタを設定する上では重要な部分ですが、この例では、単純にするために無効になっています。stonithを利用する場合は、第7.4項「フェンシング構成」で詳細を参照してください。

  2. この例はノード2つのクラスタであるため、クォーラムなしポリシーを無効にできます。クォーラムは、最少でも3つノードがないと意味をなさないためです。クォーラムは、クラスタのステータスに同意したノードが半数を超えている場合にのみ達成されます。この例では、クォーラムを達成できないため、次のように、クォーラムの状態を無視するようクラスタを構成します。 

    # pcs property set no-quorum-policy=ignore

  3. 移行ポリシーを構成します。この例では、障害が1つ発生したらサービスを新しいノードに移動するようにクラスタを構成します。 

    # pcs resource defaults migration-threshold=1
サービスの作成およびフェイルオーバーのテスト

サービスは作成されており、通常は、プロセスの開始および停止を担当するリソース・エージェントを実行するように構成されています。ほとんどのリソース・エージェントは、Linux Standard Base (LSB)の拡張機能として定義されているOCF (Open Cluster Framework)仕様に従って作成されます。resource-agentsパッケージには、よく使用されるプロセスのための便利なリソース・エージェントが多数含まれており、よく使用されるデーモンやサービスがまだ実行中かどうかを追跡する様々なハートビート・エージェントなどがあります。

この例では、Pacemakerをテストするために作成されたDummyリソース・エージェントを使用するサービスを設定します。このエージェントを使用するのは、このエージェントでは、必要な構成が最小限であり、ご使用の環境や、Pacemakerとともに実行するサービスのタイプが想定されていないためです。

  1. サービスをリソースとして追加するには、pcs resource createコマンドを使用します。サービスの名前を指定します。次の例では、このリソースにdummy_serviceという名前を使用します。 

    # pcs resource create dummy_service ocf:pacemaker:Dummy op monitor interval=120s

    Dummyリソース・エージェントを起動するには、表記法(ocf:pacemaker:Dummy)を使用して、それがOCF標準に準拠しており、pacemakerネームスペースで実行され、Dummyスクリプトを使用する必要があることを指定します。Oracle Database用のハートビート監視サービスを構成した場合は、ocf:heartbeat:oracleリソース・エージェントを使用できます。

    このエージェントで監視操作を使用するようにリソースが構成され、サービスの状態をチェックする間隔が設定されています。この例では、フェイルオーバーのデモンストレーション中にサービスが失敗する時間を用意するために、間隔を120に設定します。デフォルトではこれは20秒に設定されますが、サービスのタイプやご使用の環境に応じて変更できます。

  2. サービスを作成するとすぐに、クラスタにより、そのリソース・エージェントの起動コマンドを使用してノード上でリソースの起動が試みられます。pcs statusコマンドを実行すると、次のように、リソースの開始と実行のステータスを確認できます。 

    # pcs status
Cluster name: pacemaker1
Stack: corosync
Current DC: node1 (version 1.1.16-12.el7-94ff4df) - partition with quorum
Last updated: Wed Jan 17 06:35:18 2018
Last change: Wed Jan 17 03:08:00 2018 by root via cibadmin on node1

2 nodes configured
1 resource configured

Online: [ node2 node1 ]

Full list of resources:

 dummy_service   (ocf::pacemaker:Dummy): Started node2

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

  3. サービスを手動で停止したことをクラスタが認識しないように、crm_resourceを使用してサービスを直接強制停止することで、サービスの失敗をシミュレーションします。 

    # crm_resource --resource dummy_service --force-stop

  4. ノードの失敗とFailed Actionsというメッセージが表示されるまで待機できるように、対話型モードでcrm_monを実行します。代替ノードでサービスが再起動されたことがわかります。 

    # crm_mon
Stack: corosync
Current DC: node1 (version 1.1.16-12.el7-94ff4df) - partition with quorum
Last updated: Wed Jan 17 06:41:04 2018
Last change: Wed Jan 17 06:39:02 2018 by root via cibadmin on node1

2 nodes configured
1 resource configured

Online: [ node2 node1 ]

Active resources:

dummy_service    (ocf::pacemaker:Dummy): Started node1

Failed Actions:
* dummy_service_monitor_120000 on node2 'not running' (7): call=16, status=complete, exitreason='none',
    last-rc-change='Wed Jan 17 06:41:02 2018', queued=0ms, exec=0ms

    いつでもCtrl-Cキーの組合せを使用してcrm_monを終了できます。

  5. サービスが実行されているノードの再起動を試みて、ノード障害が発生した場合にフェイルオーバーも発生することを確認できます。corosyncおよびpacemakerサービスをブート時に開始するように有効化していない場合は、再起動したノードで手動でサービスを開始する必要があることがあります。次に例を示します。 

    # pcs cluster start node1

7.4 フェンシング構成

フェンシングまたはstonithは、ノードが応答しなくなったときにデータを保護するために使用します。ノードは応答に失敗した場合でもデータにアクセスしている可能性があります。データが安全であることを確認するために、フェンシングを使用して、元のノードが実際にオフラインになるまで、ライブ・ノードがデータにアクセスできないようにすることができます。これを行うには、ノードを確実にオフラインにできるデバイスを構成する必要があります。この目的のために構成できるフェンシング・エージェントは多数あります。一般に、stonithは、クラスタを保護するためにノードを物理的かつ強制的に再起動またはシャットダウンできる、特定のハードウェアおよびサービス・プロトコルに依存しています。

この項では、例として、入手可能なフェンシング・エージェントのうちのいくつかを使用する様々な構成を示します。なお、これらの例では、ハードウェアについていくらか仮定が採用されており、関連するハードウェアの設定方法、構成方法および使用方法をすでに把握していることが前提となっています。これらの例は基本的なガイダンスを提供するものであり、ここで示す概念の一部を理解するために、上流のドキュメントも参照することをお薦めします。

これらの構成例に進む前に、次のように、クラスタ構成でstonithが有効になっていることを確認する必要があります。 

# pcs property set stonith-enabled=true

stonithを構成した後は、次のコマンドを実行することで、構成が正しく設定されていることを確認できます。 

# pcs stonith show --full
# pcs cluster verify -V

stonith構成のステータスを確認するには、次を実行します。 

# pcs stonith

クラスタのステータスを確認するには、次を実行します。 

# pcs status

IPMI LANフェンシング

Intelligent Platform Management Interface (IPMI)は、ホスト・システムのハードウェアおよびファームウェアの管理機能を提供するサブシステムへのインタフェースであり、システムのオペレーティング・システムにアクセスする必要なく専用のネットワーク経由でシステムの電源再投入を行う機能があります。fence_ipmilanフェンシング・エージェントは、IPMI LAN全体でstonithを実現できるようにクラスタに対して構成できます。

システムでIPMIが構成されている場合は、クラスタ内のいずれかのノードで次のコマンドを実行して、ipmilanフェンシング・エージェントを有効にすることや、両方のノードに対してstonithを構成することができます。 

# pcs stonith create ipmilan_n1_fencing fence_ipmilan pcmk_host_list=node1 delay=5 \
ipaddr=203.0.113.1 login=root passwd=password lanplus=1 op monitor interval=60s
# pcs stonith create ipmilan_n2_fencing fence_ipmilan pcmk_host_list=node2 \
ipaddr=203.0.113.2 login=root passwd=password lanplus=1 op monitor interval=60s

上の例では、node1という名前のホストに、IP 203.0.113.1でIPMI LANインタフェースが構成されています。node2という名前のホストには、IP 203.0.113.2でIPMI LANインタフェースが構成されています。ここでは、両方のシステムでのIPMIログイン用のrootユーザー・パスワードをpasswordと指定しています。各インスタンスで、これらの構成変数を、ご使用の環境に合わせて適切な情報に置き換える必要があります。

delayオプションは1つのノードにのみ設定する必要があることに注意してください。これは、まれにフェンスの競合状態が発生しても、一方のノードのみが強制終了され、もう一方のノードは稼働し続けるようにするために役立ちます。このオプションを設定しないと、両方のノードが、自分を存続している唯一のノードであると認識し、お互いを同時にリセットする可能性があります。

警告

IPMI LANエージェントは、IPMIサブシステムのログイン資格証明をプレーン・テキストで公開します。セキュリティ・ポリシーで、Pacemakerの構成およびツールにアクセスできるユーザーにこれらの資格証明および基礎となる関連サブシステムへのアクセスも許可されるようにする必要があります。

SCSIフェンシング

SCSIフェンシング・エージェントは、ストレージ・レベルのフェンシングを提供するために使用します。これは、SCSI-3 PR (Persistent Reservation)を使用して、ストレージ・リソースが同時に2つのノードによって書き込まれないようにします。watchdogサービスと組み合せて使用すると、ノードが予約なしでSCSIリソースにアクセスしようとしたときに、stonithを介してそのノードを自動的にリセットできます。

このように環境を構成するには、次のように、両方のノードにwatchdogサービスをインストールし、そのサービスを有効にする前に、提供されたfence_scsi_checkスクリプトをwatchdog構成にコピーします。 

# yum install watchdog
# cp /usr/share/cluster/fence_scsi_check /etc/watchdog.d/
# systemctl enable --now watchdog

このフェンシング・エージェントを使用するには、両方のノードで、iscsi-initiator-utilsパッケージで提供されるiscsidサービスも有効にする必要があります。 

# yum install -y iscsi-initiator-utils
# systemctl enable --now iscsid

watchdogサービスとiscsidサービスを使用するように両方のノードを構成した後は、いずれかのクラスタ・ノードでfence_scsiフェンシング・エージェントを構成して、iSCSIターゲットなどの共有ストレージ・デバイスを監視できます。次に例を示します。 

# pcs stonith create scsi_fencing fence_scsi pcmk_host_list="node1 node2" \
 devices="/dev/sdb" meta provides="unfencing"

この例では、node1とnode2はクラスタ内のノードのホスト名であり、/dev/sdbは共有ストレージ・デバイスです。これらの変数を、ご使用の環境に合わせて適切な情報に置き換える必要があります。

SBDフェンシング

Storage Based Death (SBD)は、システム上で動作し、共有ストレージを監視できるデーモンであり、メッセージング・システムを使用してクラスタの状態を追跡できます。SBDは、適切なフェンシング・エージェントによってstonithの実装が必要だと判断された場合に、リセットをトリガーできます。

SBDフェンシングを設定および構成するには、いずれかのノードで次のコマンドを実行してクラスタを停止します。 

# pcs cluster stop --all

各ノードで、次のように、SBDデーモンをインストールして構成します。 

# yum install sbd

/etc/sysconfig/sbdを編集して、共有ストレージ・デバイスを識別するためのSBD_DEVICEパラメータを設定します。たとえば、共有ストレージ・デバイスが/dev/sdcにある場合は、次の行を含むようにファイルを編集します。 

SBD_DEVICE="/dev/sdc"

次のように、systemdでSBDサービスを有効にします。 

# systemctl enable --now sbd

いずれかのノードで、共有ストレージ・デバイスにSBDメッセージング・レイアウトを作成し、そのレイアウトが配置されていることを確認します。たとえば、/dev/sdcにある共有ストレージ・デバイスでメッセージングを設定して検証するには、次のコマンドを実行します。 

# sbd -d /dev/sdc create
# sbd -d /dev/sdc list

最後に、クラスタを起動し、共有ストレージ・デバイス用にfence_sbdフェンシング・エージェントを構成します。たとえば、共有ストレージ・デバイス/dev/sdcを構成するには、いずれかのノードで次のコマンドを実行します。 

# pcs cluster start --all
# pcs stonith create sbd_fencing fence_sbd devices=/dev/sdc

IF-MIBフェンシング

IF-MIBフェンシングは、SNMPを利用して、イーサネット・ネットワーク・スイッチ上のIF-MIBにアクセスし、スイッチ上のポートを停止してホストを効果的にオフラインにします。これにより、ホストは稼働したまま、ネットワークから切断されます。イーサネット接続が終了した後でも、FibreChannel接続やInfiniBand接続が元の状態のままである可能性があることに留意してください。つまり、これらの接続で使用可能になっているデータは、まだ危険にさらされる可能性があります。そのため、これをフォールバック・フェンシング・メカニズムとして構成することをお薦めします。複数のフェンシング・エージェントを一緒に使用してstonithの成功を最大限にする方法の詳細は、フェンシング・レベルの構成を参照してください。

IF-MIBフェンシングを構成するには、少なくともSNMP v2c用にスイッチが構成されており、SNMP SETメッセージが有効になっていることを確認します。たとえば、Oracle Switchで、ILOM CLIを使用して、次を実行できます。 

# set /SP/services/snmp/ sets=enabled
# set /SP/services/snmp/ v2c=enabled

クラスタ内のいずれかのノードで、ご使用の環境内の各ノード用にfence_ifmibフェンシング・エージェントを構成します。次に例を示します。 

# pcs stonith create ifmib_n1_fencing fence_ifmib pcmk_host_list=node1 \
ipaddr=203.0.113.10 community=private port=1 delay=5 op monitor interval=60s
# pcs stonith create ifmib_n2_fencing fence_ifmib pcmk_host_list=node2 \
ipaddr=203.0.113.10 community=private port=2 op monitor interval=60s

上の例では、スイッチSNMP IF-MIBにはIPアドレス203.0.113.10でアクセスできます。ホストnode1は、スイッチのポート1に接続されています。ホストnode2は、スイッチのポート2に接続されています。これらの変数を、ご使用の環境に合わせて適切な情報に置き換える必要があります。

フェンシング・レベルの構成

複数のフェンシング・エージェントを構成してある場合は、様々なフェンシング・レベルを設定できます。フェンシング・レベルにより、フェンシングのための様々な手法に優先順位を付けることができ、デフォルトのフェンシング手法が失敗した場合にフォールバック・オプションを提供する貴重なメカニズムが提供されます。

各フェンシング・レベルは、レベル1から始まる昇順で試行されます。特定のレベル用に構成されたフェンシング・エージェントが失敗した場合は、かわりに次のレベルのフェンシング・エージェントが試行されます。

たとえば、レベル1でIPMI-LANフェンシングを構成し、レベル2のオプションとしてIF-MIBフェンシングにフォールバックさせることができます。IPMI LANフェンシングおよびIF-MIBフェンシングで示した構成例を使用して、いずれかのノードで次のコマンドを実行し、構成済の各エージェントにフェンシング・レベルを設定できます。 

# pcs stonith level add 1 node1 ipmilan_n1_fencing
# pcs stonith level add 1 node2 ipmilan_n2_fencing
# pcs stonith level add 2 node1 ifmib_n1_fencing
# pcs stonith level add 2 node2 ifmib_n2_fencing

7.5 詳細情報

PacemakerおよびCorosyncの詳細とドキュメントは、https://clusterlabs.org/pacemaker/doc/を参照してください。

Copyright © 2020, 2021, Oracle and/or its affiliates. 法律上の注意点