Sun Cluster アーキテクチャーでは、一連のシステムが単一の大規模システムとして配備され、管理され、認識されます。
この章の内容は次のとおりです。
クラスタは、次のハードウェアコンポーネントから構成されます。
ローカルディスク (非共有) を備えたクラスタノード。クラスタの主要なコンピューティングプラットフォームです。
マルチホストストレージ。ノード間で共有されるディスクです。
テープや CD-ROM などのリムーバブルメディア。グローバルデバイスとして構成されます。
クラスタインターコネクト。ノード間の通信チャネルとして使用されます。
パブリックネットワークインタフェース。クライアントシステムによって使用されるネットワークインタフェースは、このインタフェースを通してクラスタのデータサービスにアクセスします。
図 3–1 は、個々のハードウェアコンポーネント間の関係を示しています。
ノードがクラスタメンバーとして動作するためには、ノードに次のソフトウェアがインストールされていなければなりません。
Solaris ソフトウェア
Sun Cluster ソフトウェア
データサービスアプリケーション
ボリューム管理 (SolarisTM Volume Manager または VERITAS Volume Manager)
ただし、そのボックス自体のボリューム管理を使用する構成は例外です。 この構成では、ソフトウェアボリュームマネージャが必要ない場合があります。
図 3–2 は、Sun Cluster ソフトウェア環境を構成するソフトウェアコンポーネントの概要を示します。
データが破壊から保護されるように保証するには、すべてのノードが、クラスタメンバーシップに対して一定の同意に達していなければなりません。 必要であれば、CMM は、障害に応じてクラスタサービスのクラスタ再構成を調整します。
CMM は、クラスタのトランスポート層から、他のノードへの接続性に関する情報を受け取ります。 CMM は、クラスタインターコネクトを使用して、再構成中に状態情報を交換します。
CMM は、クラスタメンバーシップの変更を検出すると、それに合わせてクラスタを構成します。 この構成処理では、クラスタリソースが、クラスタの新しいメンバーシップに基づいて再配布されることがあります。
CMM は完全にカーネル内で動作します。
CCR は、CMM に依存して、定足数 (quorum) が確立された場合にのみクラスタが実行されるように保証します。 CCR は、クラスタ全体のデータの一貫性を確認し、必要に応じて復旧を実行して、データへの更新を容易にします。
クラスタファイルシステムは、次のコンポーネント間のプロクシです。
あるノード上のカーネルとそのノードが使用しているファイルシステム
そのディスク (1 つまたは複数) と物理的に接続されているノード上のボリュームマネージャ
クラスタファイルシステムでは、グローバルデバイス (ディスク、テープ、CD-ROM) が使用されます。 グローバルデバイスには、クラスタのどのノードからでも同じファイル名 (たとえば、/dev/global/) を使ってアクセスできます。 そのノードは、アクセスするストレージデバイスに物理的に接続されている必要はありません。 ユーザーは、グローバルデバイスを通常のデバイスと同じように使用できます。つまり、newfs や mkfs を使ってグローバルデバイスにファイルシステムを作成することができます。
クラスタファイルシステムには、次の機能があります。
ファイルのアクセス場所が透過的になります。 システムのどこにあるファイルでも、プロセスから開くことができます。 さらに、すべてのノードのプロセスから同じパス名を使ってファイルにアクセスできます。
クラスタファイルシステムは、ファイルを読み取る際に、ファイル上のアクセス時刻を更新しません。
一貫したプロトコルを使用して、ファイルが複数のノードから同時にアクセスされている場合でも、UNIX ファイルアクセス方式を維持します。
拡張キャッシュ機能とゼロコピーバルク入出力移動機能により、ファイルデータを効率的に移動することができます。
クラスタファイルシステムには、fcntl(2) インタフェースに基づく、高度な可用性を備えたアドバイザリファイルロッキング機能があります。 クラスタファイルシステムのファイルに対してアドバイザリファイルロッキング機能を使えば、複数のクラスタノードで動作するアプリケーションの間で、データのアクセスを同期化できます。 ファイルロックを所有するノードがクラスタから切り離されたり、ファイルロックを所有するアプリケーションに障害が発生すると、それらのロックはただちに解放されます。
障害が発生した場合でも、データへの連続したアクセスが可能です。 アプリケーションは、ディスクへのパスが有効であれば、障害による影響を受けません。 この保証は、raw ディスクアクセスとすべてのファイルシステム操作で維持されます。
クラスタファイルシステムは、使用しているボリューム管理ソフトウェアから独立しています。 クラスタファイルシステムでは、サポートされるすべてのオンディスクファイルシステムが広域になります。
クラスタネットワーキングの主な目的は、データサービスにスケーラビリティを提 供することにあります。 スケーラビリティとは、サービスに提供される負荷が増えたときに、新しいノードがクラスタに追加されて新しいサーバーインスタンスが実行されるために、データサービスがこの増加した負荷に対して一定の応答時間を維持できるということを示します。 スケーラブルデータサービスの例としては、Web サービスがあります。 通常、スケーラブルデータサービスはいくつかのインスタンスからなり、それぞれがクラスタの異なるノードで実行されます。 これらのインスタンスは、遠隔クライアントに対して単一のサービスとして動作し、そのサービスの機能を提供します。 別々のノードで動作するいくつかの httpd デーモンからなるスケーラブル Web サービスでは、任意のデーモンでクラスタ要求を処理できます。 要求に対応するデーモンは、ロードバランシングポリシーによって決められます。 クライアントへの応答は、その要求にサービスを提供する特定のデーモンからではなく、サービスからのもののようにみえるため、単一サービスの外観が維持されます。
次の図は、スケーラブルサービスの構造を示したものです。
グローバルインタフェースのホストではないノード (プロキシノード) には、そのループバックインタフェースでホストされる共有アドレスがあります。 グローバルインタフェースに入ってくるパケットは、構成可能なロードバランシングポリシーに基づいてほかのクラスタノードに分配されます。 次に、構成できるロードバランシングポリシーについて説明します。
ロードバランシングは、スケーラブルサービスのパフォーマンスを応答時間とスループットの両方の点で向上させます。
スケーラブルデータサービスには、 pure と sticky の 2 つのクラスがあります。 pure サービスとは、どのインスタンスでもクライアント要求に応答できるサービスをいいます。 sticky サービスでは、ノードへの要求の負荷をクラスタが均衡させます。 これらの要求は、別のインスタンスには変更されません。
pure サービスは、ウェイト設定した (weighted) ロードバランシングポリシーを使用します。 このロードバランシングポリシーのもとでは、クライアント要求は、デフォルトで、クラスタ内のサーバーインスタンスに一律に分配されます。 たとえば、各ノードのウェイトが 1 であるような 3 ノードクラスタでは、各ノードが、任意のクライアントからの要求をそのサービスのために 3 分の 1 ずつ処理します。 ウェイトの変更は、scrgadm(1M) コマンドインタフェースか SunPlex Manager GUI を使っていつでもできます。
sticky サービスには、 ordinary sticky と wildcard sticky があります。 sticky サービスを使用すると、状態間メモリー (アプリケーションセッション状態) を共有でき、複数の TCP 接続でアプリケーションレベルの同時セッションが可能です。
ordinary sticky サービスを使用すると、クライアントは、複数の同時 TCP 接続で状態を共有できます。 このクライアントを、単一ポートで待機するサーバーインスタンスに対して 「sticky」であるといいます。 クライアントは、インスタンスが起動していてアクセス可能であり、ロードバランシングポリシーがサービスのオンライン時に変更されていなければ、すべての要求が同じサーバーのインスタンスに送られることを保証されます。
wildcard sticky サービスは、動的に割り当てられたポート番号を使用しますが、クライアント要求がやはり同じノードに送られるものと想定します。 クライアントは、同じ IP アドレスに対して、複数のポート間で sticky wildcard であるといいます。
Sun Cluster ソフトウェアは、複数のノードに同時に接続できるマルチホストディスクストレージを使用することによって、ディスクの高い可用性を実現します。 これらのディスクは、ボリューム管理ソフトウェアの使用を通して、クラスタノードからマスターされる共有ストレージに編成されます。 そして、障害が発生したときに別のノードに移動されるように構成されます。 Sun Cluster システムでマルチホストディスクを使用することには、さまざまな利点があります。たとえば、次はその例です。
ファイルシステムへのグローバルアクセス
ファイルシステムやデータへの複数のアクセスパス
単一ノード障害に耐えられる
少なくとも2 つの冗長な物理的に独立したネットワーク、またはパスを使用して、すべてのノードをクラスタインターコネクトによって接続し、単一障害を回避する必要があります。 冗長性を保つためには 2 つのインターコネクトが必要ですが、ボトルネックを解消したり、冗長性や拡張性を強化するために、最大 6 つのインターコネクトを使ってトラフィックを分散させることができます。 Sun Cluster インターコネクトでは、Fast Ethernet や Gigabit-Ethernet、Sun Fire Link、Scalable Coherent Interface (SCI, IEEE 1596-1992) の使用を通して、高性能のクラスタ内通信がサポートされます。
クラスタ環境のノード間通信には、高速、低遅延のインターコネクトとプロトコルが欠かせません。 Sun Cluster システムの SCI インターコネクトは、一般的なネットワークインタフェースカード (NIC) よりも高い性能を発揮します。 Sun Cluster では、Sun Fire Link ネットワークにおけるノード間通信に Remote Shared Memory ( RSMTM) インタフェースを使用します。 RSM は、非常に効率的な遠隔メモリ操作を行う Sun メッセージングインタフェースです。
クラスタインターコネクトは、以下のハードウェアコンポーネントで構成されます。
アダプタ – 個々のクラスタノードに存在するネットワークインタフェースカード。 1 つのネットワークアダプタに複数のインターフェイスを持たせると、アダプタ全体に障害が生じると、単一障害の原因となる可能性があります。
ジャンクション – クラスタノードの外部に常駐するスイッチ。 ジャンクションは、パススルーおよび切り換え機能を実行して、3 つ以上のノードに接続できるようにします。 2 ノードクラスタでは、冗長な物理ケーブルによってノードが相互に直接接続されるため、ジャンクションは必要ありません。 これらの冗長化なケーブルは、各ノードの冗長化されたアダプタに接続されます。 3 ノード以上の構成では、ジャンクションが必要です。
ケーブル – 2 つのネットワークアダプタまたはアダプタとジャンクションの間をつなぐ物理接続。
図 3–4 は、3 つのコンポーネントがどのうように接続されるかを示しています。
パブリックネットワークアダプタは、IPMP グループ (マルチパスグループ) として編成されます。 各マルチパスグループには、1 つまたは複数のパブリックネットワークアダプタがあります。 マルチパスグループの各アダプタはアクティブにすることができます。あるいは、スタンバイインタフェースを構成し、フェイルオーバーが起こるまでそれらを非アクティブにしておくことができます。
マルチパスグループは、論理ホスト名と共有アドレスリソースの基盤です。 ノード上の同じマルチパスグループが、任意の数の論理ホスト名、または共有アドレスリソースのホストとなることができます。 マルチパスを作成すれば、クラスタノードのパブリックネットワーク接続を監視できます。
論理ホスト名や共有アドレスリソースについては、『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』を参照してください。
クライアントは、パブリックネットワークインタフェースを介してクラスタに接続します。 各ネットワークアダプタカードは、カードに複数のハードウェアインタフェースがあるかどうかによって、1 つまたは複数のパブリックネットワークに接続できます。 複数のパブリックネットワークインタフェースカードをもつノードを設定することによって、複数のカードをアクティブにし、それぞれを相互のフェイルオーバーバックアップとすることができます。 アダプタの 1 つに障害が発生すると、Sun Cluster の Solaris IPMP ソフトウェアが呼び出され、障害のあるインタフェースが同じグループの別のアダプタにフェイルオーバーされます。