高可用性クラスタへの応用
前回までで、非同期/同期でのストリーミング・レプリケーションの設定、状態確認の方法、フェイルオーバーのしかたを見てきました。最終回となる今回では、その応用として、プライマリデータベースが障害で停止する事態になっても、自動的にフェイルオーバーを行うことでデータベースサービスを継続して行えるような、冗長性を持った簡易的な高可用性クラスタの構築をしていきます。
Keepalived と VRRP
今回用いる Keepalived は、本来は LVS (Linux Vertual Server) の可用性 (Availability) を向上させるためのアプリケーションなのですが、その高可用性 (High-Availability: HA) 確保のために実装されている Virtual Router Redundancy Protocol (VRRP) プロトコルの機能を利用することで、任意のサービスの HA 化に応用することができます (参考: 「Virtual Router Redundancy Protocol - Wikipedia」)。
その役割を簡単に見てみます。ルータやロードバランサ、リバースプロキシのような、それぞれが同じ構成を持つホストをたくさん並べておいて、それぞれに Keepalived をインストールします。Keepalived をインストールしたホストどうしはお互いに通信しあい、1 つ（以上）の稼動系ノードを「マスター」として稼働状態にし、それ以外の待機系ホストを「バックアップ」として休止状態に置きます。そして、実サービスを行うマスターホストが障害を起こし、マスターからの「稼働中」を示すマルチキャストパケットが届かなくなったら、バックアップホストがマスターに昇格して、新たなマスターとしてサービスを続行する、という処理の流れになります。
このように Keepalived は、本来はルータやロードバランサなどを前提としものであるため、稼働するサービスを管理する機能が貧弱です。そのため、データベースのように複雑で、データの同期やストレージとの相互依存するリソースを持つケースでは弊社の LifeKeeper や OSS 実装の Pacemaker 等の本格的な HA ソフトウェアを使うべきなのですが、それらを使って説明をすると、HA ソフトウェアの設定の方に紙幅を使ってしまい、ストリーミング・レプリケーションのために行う処理が埋もれてしまいがちです。そのため今回は、機能としては「マスター化」と「バックアップ化」程度しか持たない Keepalived を用いることで、HA 構成を採る際にストリーミング・レプリケーションで気をつけるべき点を明確にして行きたいと思います。
なおこれ以降、用語として、Keepalived の稼働系/待機系の役割を「マスター」/「バックアップ」、PostgreSQL のレプリケーションのデータ発信元/受信先を「プライマリ」/「スタンバイ」と呼称しますので、混同しないように気をつけてください。
|
|
| 図1：Keepalived + ストリーミング・レプリケーション概要図 |
今回の構成の初期状態では、クライアントは図にあるように、Keepalived によってマスターホストに振られた仮想 IP アドレス (Virtual IP アドレス、VIP アドレス) に対してアクセスをしてデータベースに接続します。この時、マスターとバックアップの Keepalived どうしは VRRP プロトコルで通信しあっており、お互いにプライマリサーバが (正確には Keepalived のマスターが) 正常に動いていることを確認しています。
マスターサーバに障害 (突然の電源断など) が発生すると、マスターサーバからの VRRP パケットがバックアップに届かなくなるので、残った Keepalived のバックアップホストは、マスターホストに昇格をすると同時に、設定した手順どおりに、バックアップホスト上で動いていた PostgreSQL のスタンバイノードをプライマリノードに昇格させます。その際、新しいマスターノードは仮想 IP アドレスを引き継ぎますので、クライアントは引き続き、同一の IP アドレスを用いて新しいマスターホスト上のプライマリサーバに接続し、サービスを受け続けることができます。ただし、残念ながらコネクションは引き継げませんので、クライアントは再接続をする必要があります。
追加パッケージのインストール
それではさっそく構築に入ろうと思います。これ以降、"node1", "node2", "spare" という 3 台のホストが登場します。この内、"node1" と "node2" は同期/非同期構成ともに使用しますが、"spare" は、同期レプリケーション構成でのみ必要となります。また、仮想 IP アドレス "192.18.12.23" は、名前 "vip" で引けるように設定されているものとします。インストールするパッケージは、いずれのホストでも同じ構成となります。
第1回で PostgreSQL をインストールしましたが、それに加えて、ここで Keepalived をインストールします。ここで用いるレポジトリ EPEL (Extra Packages for Enterprise Linux) は、Fedora を元にして RHEL が作られる際に取り込まれなかったパッケージ群を、RHEL やその互換ディストリビューションのために有志が提供してくださっているプロジェクトです。
[root@node1 ~]# rpm -Uvh http://download.fedora.redhat.com/pub/epel/6/x86_64/epel-release-6-5.noarch.rpm (中略) [root@node1 ~]# yum install -y keepalived (中略) Installing : keepalived-1.2.2-2.el6.x86_64 1/1 Installed: keepalived.x86_64 0:1.2.2-2.el6 Complete! [root@node1 ~]# rpm -e epel-release [root@node1 ~]#
加えて、前回ご紹介した recovery_target_timeline = 'latest' の設定をする際に、今回は rcp コマンドで *.history ファイルをネットワーク経由で別のホストからコピーする必要があるため、RSH 関連のクライアントとサーバをインストールし、サービスを起動しておきます。
[root@node1 ~]# yum install -y rsh rsh-server (中略) [root@node1 ~]# chkconfig xinetd on [root@node1 ~]# service xinetd start xinetd を起動中: [ OK ] [root@node1 ~]# chkconfig rsh on [root@node1 ~]#
なおここで、よりセキュアな SCP ではなく RCP を使っている理由は、認証やホスト識別キーなどの設定を割愛するためです。これは、データベースを設置するネットワークが、比較的セキュリティの問題やパケットの覗き見の脅威にさらされていないことを前提としています。SCP を用いるのであれば、複数の別ホストに振り直される仮想 IP アドレスに対して同じキーで接続をする必要があるため、各ホストのホストキーを合わせる等の設定を適切におこなってください。
