 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 | ||||||||||
|
||||||||||
| SGLXの共有ストレージ接続構成とストレージパスのフェールオーバー | ||||||||||
|
SGLXの共有ストレージ接続はホストバスアダプタ、スイッチ、ストレージコントローラ、ストレージパスのすべてを冗長構成にします。 クラスタノードのPCIスロットにホストバスアダプタを2枚接続し、各ホストバスアダプタはそれぞれ冗長構成されたFibre Channelスイッチに接続します。スイッチと共有ストレージ間も冗長パスを持っており、Fibre Channelスイッチの1つに障害が発生しても共有ストレージへのパスは確保されます。さらに共有ストレージに搭載されたコントローラも冗長構成になっており、コントローラに障害が発生した場合でも共有ストレージへのパスを確保するようになっています。 以上のことから、ホストバスアダプタ、スイッチ、共有ストレージコントローラの冗長構成によってノードとストレージ間における単一障害点を排除しています。SGLXでは、冗長構成されたホストバスアダプタのドライバとして、OSに添付されている標準のドライバではなく、HP製のQlogic failoverドライバを使用します。 |
||||||||||
| SGLXで推奨されるネットワーク構成とNICのフェールオーバー | ||||||||||
|
クラスタノードはお互いのノードの生死監視専用のハートビートLANとネットワークサービスが利用するLAN（一般にはサービスLANやユーザLAN、データLANなどと呼びます）を構成します。SGLXにおけるサービスLANのNICはbonding構成を強く推奨します。サービスLANをbonding構成にしないクラスタは可用性が低下するためです。 さらにSGLXではハートビートLANの冗長構成として、サービスLANとハートビートLANを兼用し、ハートビートパケットはハートビート専用LANとサービスLANの2つに流れます。ハートビートLANとサービスLANは別セグメントに構築することが推奨されており、別セグメントのLAN上にハートビートパケットを流すことによって、ハートビートLAN自体の冗長構成を実現します。 これにより、ハートビートLANの１つに障害が発生したとしても、クラスタノード間のハートビートは保たれ、クラスタノードの生死監視は継続します。SGLXではハートビート専用LANに障害が発生しても別セグメントでハートビートLANが生きている限りクラスタは稼動し続けます。ハートビートのパケットをどのネットワークインタフェースで送受信するかは、クラスタ構成ファイルとよばれるテキストファイルに記述します。 SGLXにおけるNICの通信に関するフェールオーバー機能は、Linux上で動作するbondingドライバが担当します。最近のエンタープライズ用途のLinuxディストリビューションの多くはOS標準でbondingドライバを持っています。bondingドライバを持たない比較的古いディストリビューションでは、HP製のbondingドライバをインストールしていましたが、現在はOSが標準で持つbondingドライバを利用してSGLXの冗長LAN構成を組むことが可能となっています。  図2：Serviceguard for LinuxにおけるNICのフェールオーバー （画像をクリックすると別ウィンドウに拡大図を表示します） |
||||||||||
| 次回は | ||||||||||
|
クラスタリングの必要性については省いて、Linuxでのクラスタリングについて説明を進めてきました。今回の説明でも、RHELで行うクラスタがいかに便利かがわかるかと思います。続く次回はクラスタノードについて説明します。 |
||||||||||
|
前のページ 1 2 3 |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
