ハードウェア冗長化

はじめに

   これまでの本連載では、LifeKeeperの機能を使用した各種アプリケーションやストレージの冗長化の手法を紹介してきた。今回はハードウェアそのものの冗長化というテーマで、LifeKeeperと親和性の高いハードウェア冗長化の手法について紹介する。

   ここで一度、システム構成全体におけるLifeKeeperの守備範囲を確認しておきたい。

図1：APサーバとDBサーバによる冗長化構成のイメージ図

   図1は比較的一般的な、AP（アプリケーション）サーバとDB（データベース）サーバによる冗長化構成のイメージ図である。なおネットワーク機器については詳細を省かせていただいた。

   図1の緑色の枠でくくられた部分については、ファイアウォールやロードバランサといったネットワーク機器で冗長性が確保されており、APサーバへの 負荷分散が行われている。この場合、外部からのアクセスを受け付けるグローバルアドレスはファイアウォールに割り振られている。

   LifeKeeperが保護対象とするのは、下部にある黄色の枠内となる。具体的にはAPサーバからのアクセスを受け付ける仮想IP／データベース ／共有ストレージが保護される。またデータベース以外のアプリケーションもLifeKeeperのリソースとして登録することで保護対象となるが、今回の 趣旨とは異なるため割愛させていただく。

   本連載では、図1の黄色の枠内にある1〜3の要素について紹介する。これらの要素の概要は表1の通りである。

1. サービスLANの冗長化
2. 共有ストレージに対するFC経路のマルチパス構成
3. コミュニケーションパス（ハートビート）の冗長化

   表1にはLifeKeeper固有の機能ではないものが含まれているが、これらをLifeKeeperと共に利用することで単体サーバとしての可用 性を高めることができる。また単体サーバの可用性を高めることのメリットとして、障害が発生した際に予備のリソースに切り替えることで、他のノードへフェ イルオーバーを行うよりも迅速なサービスの復旧ができる点があげられる。

ネットワークの冗長化

   ネットワークの冗長化に関しては、以下の2点が考えられる。

• パブリックネットワーク（サービスLAN）の冗長化（図1の1）

• LifeKeeperが内部的な通信で使用するコミュニケーションパスの冗長化（図1の3）

   この項では、「パブリックネットワークの冗長化」について紹介する。

   なお、インストール編でも触れている通り、LifeKeeperのコミュニケーションパスは複数定義することが基本的な要件となる。そのためコミュ ニケーションパスの冗長化については、ユーザ側で検討する必要はない。コミュニケーションパスとして定義された経路に障害が発生した場合は、優先順位に 従って順次他のコミュニケーションパスを使用して通信を継続する。これはLifeKeeperの基本機能として、冗長化がはかられているのと同等といえる からである。

   予備のコミュニケーションパスとして、Bondingなどで冗長化されたネットワークデバイスを指定することに問題はないが、余計な問題の発生を回 避する意味合いでも、プライマリのコミュニケーションパスは冗長化されていない単体のネットワークデバイスの使用を強く推奨する。