 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| ハードウェア | ||||||||||||
|
Cluster Managerが必要とするハードウェアは、2〜16台のノード用のサーバと、ノードが共有するストレージ、データの完全性を保証するためのフェンスデバイスです。フェンスデバイスはノードの死活確認を行って共有ストレージの排他処理（フェンシング）を確実にし、データの破壊や不整合を防止するためのもので、ネットワーク対応の無停電電源装置やサーバに搭載されるリモート管理用のカードなどが代表的です。 利用できるデバイスのリストがRed Hat Cluster Suite Configuring and Managing a Cluster（http://www.redhat.com/docs/manuals/csgfs/）に掲載されています。 |
||||||||||||
| フェイルオーバーの仕組み | ||||||||||||
|
Cluster Managerを技術的に見ると（図3）、フェイルオーバー時にアクティブになったノードでは、まず共有ストレージをロックし、サービスを起動後にサービスに使用するIPアドレス（浮動IPアドレス＝VIP）をNIC（Network Interface Card）に割り振ります。この一連の動作によりVIP（図3の10.0.0.1）が維持され続けます。  図3：フェイルオーバーの仕組み サービスの種類にもよりますが、Cluster Managerがフェイルオーバーするのに必要な時間は最短で数秒です。 |
||||||||||||
| アクティブ/アクティブ型クラスタ | ||||||||||||
|
Cluster Managerではアクティブ／スタンバイ型のクラスタだけではなく、アクティブ／アクティブ型のクラスタを構築することも可能です。 例えば2ノードクラスタにおいて、ノード1でサービスA、ノード2でサービスBとサービスCを提供しているとします。ノード1でサービスAが停止した場合にはノード2がサービスAを継続します。またノード2でサービスBとサービスCのいずれかあるいは両方が停止した場合、ノード1が停止したサービスを継続することが可能です。 この構成ではスタンバイノードも何らかのサービスを提供することになり、クラスタでよくいわれる「スタンバイ機の無駄」を避け、TCOを抑えることにも寄与します。 |
||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
