はじめに
これまでの本連載では、LifeKeeperの機能を使用した各種アプリケーションやストレージの冗長化の手法を紹介してきた。今回はハードウェアそのものの冗長化というテーマで、LifeKeeperと親和性の高いハードウェア冗長化の手法について紹介する。
ここで一度、システム構成全体におけるLifeKeeperの守備範囲を確認しておきたい。
図1：APサーバとDBサーバによる冗長化構成のイメージ図
図1は比較的一般的な、AP（アプリケーション）サーバとDB（データベース）サーバによる冗長化構成のイメージ図である。なおネットワーク機器については詳細を省かせていただいた。
図1の緑色の枠でくくられた部分については、ファイアウォールやロードバランサといったネットワーク機器で冗長性が確保されており、APサーバへの 負荷分散が行われている。この場合、外部からのアクセスを受け付けるグローバルアドレスはファイアウォールに割り振られている。
LifeKeeperが保護対象とするのは、下部にある黄色の枠内となる。具体的にはAPサーバからのアクセスを受け付ける仮想IP／データベース ／共有ストレージが保護される。またデータベース以外のアプリケーションもLifeKeeperのリソースとして登録することで保護対象となるが、今回の 趣旨とは異なるため割愛させていただく。
本連載では、図1の黄色の枠内にある1〜3の要素について紹介する。これらの要素の概要は表1の通りである。
- サービスLANの冗長化
- 共有ストレージに対するFC経路のマルチパス構成
- コミュニケーションパス（ハートビート）の冗長化
表1にはLifeKeeper固有の機能ではないものが含まれているが、これらをLifeKeeperと共に利用することで単体サーバとしての可用 性を高めることができる。また単体サーバの可用性を高めることのメリットとして、障害が発生した際に予備のリソースに切り替えることで、他のノードへフェ イルオーバーを行うよりも迅速なサービスの復旧ができる点があげられる。
ネットワークの冗長化
ネットワークの冗長化に関しては、以下の2点が考えられる。
- パブリックネットワーク（サービスLAN）の冗長化（図1の1）
- LifeKeeperが内部的な通信で使用するコミュニケーションパスの冗長化（図1の3）
この項では、「パブリックネットワークの冗長化」について紹介する。
なお、インストール編でも触れている通り、LifeKeeperのコミュニケーションパスは複数定義することが基本的な要件となる。そのためコミュ ニケーションパスの冗長化については、ユーザ側で検討する必要はない。コミュニケーションパスとして定義された経路に障害が発生した場合は、優先順位に 従って順次他のコミュニケーションパスを使用して通信を継続する。これはLifeKeeperの基本機能として、冗長化がはかられているのと同等といえる からである。
予備のコミュニケーションパスとして、Bondingなどで冗長化されたネットワークデバイスを指定することに問題はないが、余計な問題の発生を回 避する意味合いでも、プライマリのコミュニケーションパスは冗長化されていない単体のネットワークデバイスの使用を強く推奨する。
バックナンバー
この記事の筆者
筆者の人気記事
Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。
