|
||||||||||||||||||||||||
| 前のページ 1 2 3 4 | ||||||||||||||||||||||||
| RHCSによるThree Tiered LVS | ||||||||||||||||||||||||
|
ここまで説明したIPロードバランサとフェイルオーバークラスタを組み合わせることで、図4のようなThree Tiered LVSを構築することが可能です。インターネット側から見るとIPアドレスが1つだけ存在するように見えますが、実際にはそのIPアドレスは2台のLVSにより維持されます。 ![]() 図4:Three tiered LVS また、Server Poolに置かれた実サーバからはバックエンドにあるデータベースのIPアドレスも1つのみ存在するように見えますが、こちらもCluster Managerによって構成された2台以上のノードによって維持されています。 |
||||||||||||||||||||||||
| 冗長ハードウェア構成 | ||||||||||||||||||||||||
|
こういった可用性を重視するシステムにおいては、個別のハードウェア構成に関しても十分な考慮が必要になります。
表1:可用性を重視するハードウェアの構成に必要なこと
これらの項目のうち、ハードディスクのRAID化はOSによるソフトウェアRAIDが可能ですし、ボンディングの機能もRed Hat Enterprise Linuxに同梱されるbondingドライバによって提供されます。 |
||||||||||||||||||||||||
| 実装が大きく変更されたCluster Manager | ||||||||||||||||||||||||
|
1つ前のバージョンであるRHCS3と比較すると、RHCS4ではCluster Managerの実装が大きく変更されています。構成する際に注意が必要な点を簡単にご紹介します。 |
||||||||||||||||||||||||
| Quorumパーティションの有無 | ||||||||||||||||||||||||
|
RHCS3を含む一般的なクラスタソフトでは、各ノードの状態は共有ストレージ上のQuorumパーティションに保持されます。しかし先ほども説明したように、RHCS4ではフェンスデバイスを用いてノードの状態を把握するため、Quorumパーティションが必要ありません。 |
||||||||||||||||||||||||
| カーネルモジュール | ||||||||||||||||||||||||
|
ロックの管理を行うDLM(Distributed Lock Manager)にはdlm-kernelパッケージ、クラスタ全体の管理を行うcmanにはcman-kernelパッケージが必要です。これらのパッケージはカーネルのバージョンに依存しますので、新しいカーネルを追加インストールする際には注意が必要です。 |
||||||||||||||||||||||||
| 設定ファイルの同期 | ||||||||||||||||||||||||
|
RHCS3ではクラスタの設定ファイルを修正する度に、ftpやscpなどで設定ファイルをもう一方のノードにコピーする必要がありました。それに対して、RHCS4ではccsdによって自動的に設定が同期されます。 また設定ファイルの世代管理も可能になっており、もし設定変更後にサービスに不具合が発生したとしても、1つ前のバージョンの設定ファイルを適用し直すことが可能です。 |
||||||||||||||||||||||||
| 最後に | ||||||||||||||||||||||||
|
RHCSに関して寄せられるご質問のうち、構築費用について最も多く問い合わせを寄せられるので、以下に構成例を提示して、締めさせていただきます。なお、価格は2005年11月現在のものとなりますので、最新の価格については是非問い合わせください。
表2:IPロードバランサ構成例 |
||||||||||||||||||||||||
表3:Cluster Managerによる2ノード構成例 |
||||||||||||||||||||||||
|
前のページ 1 2 3 4 |
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||


