RHEL HAアドオンについてのFAQ

Red Hatでソリューションアーキテクトをしている小島です。

本記事は赤帽エンジニアAdvent Calendar 2018の13日目です。

みなさんはアプリケーションを冗長化する場合、どのようなシステム構成を考えますか?最近だと、KubernetesやOpenShiftなどによるコンテナ環境を利用した冗長構成を考える人も多いかもしれません。しかし、冗長化対象のアプリケーションのサポート条件やライセンスがコンテナ環境に対応していないなど、様々な事情でコンテナ環境を利用できないケースもあると思います。そのような場合には、RHELのHAアドオンというアドオン製品を利用することができます。その際に、よく聞かれる質問をFAQ形式でまとめましたので参考にしてください。

Q. HAアドオンって何ですか?

A. RHEL上で動作するアプリケーションを対象としたフェイルオーバークラスタを構築するためのアドオン製品です。対象のアプリケーションまたはアプリケーションを実行しているサーバに何らかの障害が発生した場合、別の正常系のサーバ上でアプリケーションを再起動してサービスの提供を継続するということを自動的にやってくれます。アプリケーションのActive/Standbyクラスタ*1を組むための製品とも言えます。

Q. HAアドオンの購入単位は?

A. クラスタに参加するRHELサーバに対応するサブスクリプション本数と同じだけ「High Availability」サブスクリプションを購入してください。また、RHEL for Virtual DatacenterにPhysical or Virtualむけの「High Availability」サブスクリプションを2ゲスト分として購入することもできます。その他の要素はカウントしません。

Q. HAアドオンには具体的にどのようなソフトウェアが含まれますか?

A. RHEL7, RHEL8(2018年12月時点ではPublic Beta版)には、主にpacemaker, resource agent, pcs, corosync, fence agentが含まれます。これらは大まかには以下の役割を持ちます。

pacemaker: クラスタの管理者が定義したリソース(IPアドレス/データベース/アプリケーションなど)の起動・停止と状態監視を行います。後述するフェンス処理も担当します。
resource agent: pacemakerがリソースを管理するために利用するエージェントです。管理対象のリソースに対応した様々なエージェントが用意されています。
pcs: pacemakerクラスタの設定ツールです。CLI/Web UIがあります。
corosync: クラスタ基盤の構築や、クラスタのサーバ間通信によるサーバの死活監視を行います。
fence agent: リソースまたはサーバの障害を検知した場合、クラスタから異常サーバを切り離す(これをフェンスまたはSTONITHと呼びます)処理を実行するためのエージェントです。フェンスを行うデバイス毎に異なったエージェントが利用されます。

これらのソフトウェアは、Red Hat製品であるOpenStackのコントローラノード冗長化にも活用されています。ちなみに、RHELのHAアドオンはコミュニティ版にある機能を全て実装しているわけではありません。例えば、設定ツールはpcs(コマンドラインUI)とpcsd(Web UI)に限定されますし、フェンスなどの排他制御の仕組みについてはSFEXなどの機能は利用できないようになっています。

Q. RHEL6のrgmanagerについて、RHEL7ではどうなりましたか?

A. RHEL7からはrgmanagerが排除され、リソース管理やフェンス処理に前述のPacemakerを利用するようになりました。また、RHEL6.5+でもPacemakerを利用できるようになっています。rgmanagerとPacemakerの違いについては、下記も参照してください。

付録A クラスター作成 - Red Hat Enterprise Linux リリース 6.5 および Red Hat Enterprise Linux リリース 6.6 - Red Hat Customer Portal

What are the feature differences between rgmanager and pacemaker in a Red Hat Enterprise Linux 6 High Availability cluster? - Red Hat Customer Portal

Q. HAアドオンの利用には、RHELサーバ以外に何が必要ですか?

A. Red Hatのサポートを受けたい場合は、最低限フェンスデバイスが必要になります。フェンスデバイスを設定していないクラスタ構成はサポート対象外です。フェンスにはいくつか種類があり、電源制御ベースのフェンス(サーバ再起動/電源オフによる障害サーバの排除)、ストレージベースのフェンス(障害サーバからの共有ストレージへのI/O遮断)といったものがあります。電源制御ベース/ストレージベースのフェンスはいずれもサポートされますが、日本での導入実績が最も多いのはIPMIによる電源制御ベースのフェンスです。なお、共有ストレージはクラスタの種類によっては必要になりますが、必須ではありません。

Q. フェンスにはどのデバイスが利用できますか?

A. 2018年12月現在、利用できるデバイスリストは公開していません。RHEL6の時に公開していたデバイスのリストや、RHEL7, RHEL8のfence-agents-xxx.rpmパッケージの名前を見て、どのようなフェンスエージェントが利用できるか判断してください。

Q. リソースエージェントにはどのようなものが用意されていますか?

A. 2018年12月時点での、RHEL7.6で用意されているリソースエージェントの種類の一覧は下記になります。resource-agents-xxx.rpmをインストール/展開して、/usr/lib/ocf/resource.d/以下のディレクトリにあるファイル名を見ることで確認できます。

$ ls /usr/lib/ocf/resource.d/heartbeat/ ; ls /usr/lib/ocf/resource.d/openstack/
CTDB        LVM              VirtualDomain       azure-lb    exportfs          mysql      oracle            rsyncd
Delay       LVM-activate     Xinetd              clvm        galera            nagios     oralsnr           slapd
Dummy       MailTo           aliyun-vpc-move-ip  conntrackd  garbd             named      pgsql             sybaseASE
Filesystem  NodeUtilization  apache              db2         iSCSILogicalUnit  nfsnotify  portblock         symlink
IPaddr      Route            aws-vpc-move-ip     dhcpd       iSCSITarget       nfsserver  postfix           tomcat
IPaddr2     SendArp          awseip              docker      iface-vlan        nginx      rabbitmq-cluster  vdo-vol
IPsrcaddr   Squid            awsvip              ethmonitor  lvmlockd          oraasm     redis
NovaEvacuate  nova-compute-wait

他にも、Google Cloud PlatformやAlibaba Cloud上でHAアドオンを動作させるためのリソースエージェントresource-agents-{gcp,aliyun}-xxx.rpmも提供しています。これらの中に目当てのリソースエージェントがない場合、次の仕様のいずれかに準拠したカスタムエージェントを作成する必要があります。

  • Linux Standard Base (LSB)
  • Open Cluster Framework (OCF)
  • systemd
  • Upstart
  • STONITH
  • Nagios

High Availability Add-On の概要 - Red Hat Customer Portal

Q. ネットワーク系統はどういったものを用意すればいいですか?

A. 最低3系統用意してください。サービス提供用、クラスタのサーバ間通信用、クラスタ管理用、の3つです。電源制御ベースのフェンスに利用するネットワークはクラスタ管理用ネットワークと兼用するか、別途用意しても良いでしょう。それぞれのネットワークは、チーミングやボンディングなどで冗長化することを推奨します。これらのネットワーク系統を利用した、3台構成のクラスタイメージは下図のようになります。Virtual IPのみをリソースとして管理するだけの、最低限のクラスタ構成になります。

f:id:h-kojima:20181211135549p:plain
3台構成のクラスタイメージ (もりわか (id:mrwk) さん作成)

Q. HAアドオンはどのアーキテクチャに対応していますか?

A. 2018年12月時点では、下記のアーキテクチャに対応しています。いずれもRHEL7.6+の利用が前提です。

Q. HAアドオンは仮想化環境やパブリッククラウドに対応していますか?

A. 2018年12月時点では、下記の環境に対応しています。いずれもRHEL7.6+の利用が前提です。

  • RHEL KVM
  • Red Hat Virtualization
  • VMware
  • Microsoft Azure
  • Amazon Web Services EC2
  • Google Cloud Platform
  • Alibaba Cloud

なお、これらの環境にクラスタを作成する場合、下記の利用が不可となりますので注意してください。

  • ライブマイグレーション
  • 仮想マシンがActiveな時のハイパーバイザプラットフォームのアップグレード
  • 異種ハイパーバイザ間のクラスタ構成

HAアドオンが対応しているアーキテクチャやクラウド環境のリストは、下記も参照してください。

Support Policies for RHEL High Availability Clusters - Red Hat Customer Portal

Q. HAアドオンを利用して2台構成のクラスタを組みたいです。

A. 2台構成のクラスタは推奨していません。基本的には3台構成のクラスタを作ってください。これはスプリットブレイン対策によるものです。ネットワーク障害によりクラスタのサーバ間通信が切れた場合、お互いにフェンスし合わないようにQuorum(過半数)のルールでどちらの島が生き残るかを決定します。この時、偶数台、特に2台構成だとどちらがフェンスされるべきかを決定できず、フェンスの撃ち合いが発生する可能性があるからです。

Q. RHEL6の時は共有ストレージを利用して、2台+1 の構成で奇数台構成を作れましたよね?RHEL7ではそのような仕組みはないのですか?

A. RHEL6までは、Quorum Disk(qdisk)というQuorum専用の領域を共有ストレージ上に作成することで擬似的な奇数台構成を作成し、どちらのサーバが生き残るべきかを決定していました。RHEL7からはqdiskが排除され、Quorum Device(qdevice)というQuorum専用のサーバを立てるように変更されました。このqdeviceを動作するサーバ1つにつき、1つのHAアドオンを購入する必要があります。なお、1つのクラスタにつきqdeviceは1つしか利用できませんが、1つのqdeviceを複数のクラスタで共有することはできます。

Q. 2台構成クラスタの場合、qdeviceを利用しないとサポートしませんか?

A. いいえ。qdeviceなしの構成でもサポートします。この時は、片方のサーバへのフェンス処理を数秒間遅延させるといった設定でフェンスの撃ち合いを防ぐ確率を上げれます。ただし、ネットワークやフェンスデバイスの状況によっては、この遅延処理がうまく働かずにフェンスの撃ち合いが発生するケースが報告されていますので、事前検証が必須です。

Q. HAアドオンでは、何台構成のクラスタまでサポートされますか?

A. 通常は2台〜16台構成までのクラスタをサポートします。17台以上のクラスタ構成を作りたい場合、pacemaker-remoteというソフトウェアを使います。これにより、corosyncを実行していないサーバをクラスタに統合し、それらのサーバ上のリソースを実際のクラスタと同様に管理できるようになります。

Q. HAアドオンを試してみたいです。

A. 気軽に触ってみたい場合は、Red Hat Developer Programを利用してください。個人が開発用途でRHELを1つ利用できるようになります。RHELのインストールイメージにはHAアドオンのソフトウェアが含まれていますので、ローカルマシンにRHEL/KVMの仮想化環境を作って、仮想マシン上でHAアドオンを触ってみることができます。複数台で本格的に評価してみたい場合は、評価版サブスクリプションの発行をRed Hatの営業にお願いしてください。

Q. HAアドオンでクラスタを作るのに不安があります。

A. Red Hatのコンサルタントによる、オンサイト作業込みの設計・構築支援サービス(別途有償)があります。RHEL6までのHAアドオンのナレッジがある場合、sosreportなどを上げてクラスタ構成が適切であるかの判断を、Red Hatのサポートチームにお願いすることもできます。いずれの場合も、サポート期限が有効なHAアドオンのサブスクリプションを持っている必要があります。

Q. HAアドオンに関する製品トレーニングはありますか?

A. RH436という名前のオンライントレーニングを提供しています。オンサイトでのトレーニングを希望される場合、Red Hatの営業までお問い合わせください。

www.redhat.com

Q. HAアドオンに関する製品ドキュメントの一覧を教えて下さい。

A. RHEL7の製品ドキュメントの、HAアドオンの概要・管理・リファレンスを参照してください。Active/StandbyのHTTPサーバのクラスタや、NFSサーバのクラスタの設定例もこれらの中で記載しています。日本語版のドキュメントがいずれも用意されていますが、最新の情報となる英語版も合わせて参照してください。また、HAアドオンのサポートポリシーを記載したKBの一覧もありますので、合わせて参照してください。

*1:5台とか7台とかの規模のクラスタで、冗長化対象となるアプリケーションを分散して動作させるActive/Activeな構成を作ることもできます。例えばアプリケーション1をサーバAで、アプリケーション2をサーバCで動作させておき、サーバAに障害が発生した場合、サーバEでアプリケーション1を自動的に再起動させるといった仕組みを作れます。

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません