 |
||||||||||||
|
||||||||||||
| 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| はじめに | ||||||||||||
|
これまでの本連載では、LifeKeeperの機能を使用した各種アプリケーションやストレージの冗長化の手法を紹介してきた。今回はハードウェアそのものの冗長化というテーマで、LifeKeeperと親和性の高いハードウェア冗長化の手法について紹介する。 ここで一度、システム構成全体におけるLifeKeeperの守備範囲を確認しておきたい。  図1：APサーバとDBサーバによる冗長化構成のイメージ図 図1は比較的一般的な、AP（アプリケーション）サーバとDB（データベース）サーバによる冗長化構成のイメージ図である。なおネットワーク機器については詳細を省かせていただいた。 図1の緑色の枠でくくられた部分については、ファイアウォールやロードバランサといったネットワーク機器で冗長性が確保されており、APサーバへの負荷分散が行われている。この場合、外部からのアクセスを受け付けるグローバルアドレスはファイアウォールに割り振られている。 LifeKeeperが保護対象とするのは、下部にある黄色の枠内となる。具体的にはAPサーバからのアクセスを受け付ける仮想IP／データベース／共有ストレージが保護される。またデータベース以外のアプリケーションもLifeKeeperのリソースとして登録することで保護対象となるが、今回の趣旨とは異なるため割愛させていただく。 本連載では、図1の黄色の枠内にある1〜3の要素について紹介する。これらの要素の概要は表1の通りである。
表1：図1の要素の概要 表1にはLifeKeeper固有の機能ではないものが含まれているが、これらをLifeKeeperと共に利用することで単体サーバとしての可用性を高めることができる。また単体サーバの可用性を高めることのメリットとして、障害が発生した際に予備のリソースに切り替えることで、他のノードへフェイルオーバーを行うよりも迅速なサービスの復旧ができる点があげられる。 |
||||||||||||
| ネットワークの冗長化 | ||||||||||||
|
ネットワークの冗長化に関しては、以下の2点が考えられる。
表2：ネットワークの冗長化 この項では、「パブリックネットワークの冗長化」について紹介する。 なお、インストール編でも触れている通り、LifeKeeperのコミュニケーションパスは複数定義することが基本的な要件となる。そのためコミュニケーションパスの冗長化については、ユーザ側で検討する必要はない。コミュニケーションパスとして定義された経路に障害が発生した場合は、優先順位に従って順次他のコミュニケーションパスを使用して通信を継続する。これはLifeKeeperの基本機能として、冗長化がはかられているのと同等といえるからである。 予備のコミュニケーションパスとして、Bondingなどで冗長化されたネットワークデバイスを指定することに問題はないが、余計な問題の発生を回避する意味合いでも、プライマリのコミュニケーションパスは冗長化されていない単体のネットワークデバイスの使用を強く推奨する。 |
||||||||||||
|
1 2 3 4 次のページ |
||||||||||||
|
リファレンスサイトの紹介 本連載のリファレンスとなるWebサイトです。本連載に対するご意見、ご要望などもお寄せください。 ■LifeKeeper製品詳細情報 http://www.10art-ni.co.jp/product/lifekeeper/ ■SteelEye Technology Inc.（開発元） http://www.steeleye.com ■LifeKeeperに関するお問合せ https://www.10art-ni.co.jp/contact/form-lifekeeper_ssl.html |
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
