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 ずつ処理します。ウェイトの変更は、clresource(1cl) コマンドインタフェースか Sun Cluster 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、InfiniBand、または Scalable Coherent Interface (SCI, IEEE 1596-1992) の使用を通して、高性能のクラスタ内通信がサポートされます。
クラスタ環境のノード間通信には、高速、低遅延のインターコネクトとプロトコルが欠かせません。Sun Cluster システムの SCI インターコネクトは、一般的なネットワークインタフェースカード (NIC) よりも高い性能を発揮します。
RSM Reliable Datagram Transport (RSMRDT) ドライバは、RSM API 上に構築されるドライバと、RSMRDT-API インタフェースをエクスポートするライブラリから構成されます。このドライバは、Oracle Real Application Clusters の性能を向上させます。このドライバはまた、負荷均衡機能と高可用性 (HA) 機能をドライバ内部で直接提供することにより、両機能を強化すると共に、クライアントからの透過な利用を可能にしています。
クラスタインターコネクトは、以下のハードウェアコンポーネントで構成されます。
アダプタ – 個々のクラスタノードに存在するネットワークインタフェースカード。複数のインタフェースを持つネットワークアダプタは、アダプタ全体に障害が生じると、単一地点による障害の原因となる可能性があります。
スイッチ – スイッチはジャンクションとも呼ばれ、クラスタノードの外部にあります。スイッチは、パススルーおよび切り換え機能を実行して、3 つ以上のノードに接続できるようにします。2 ノードクラスタでは、アダプタハードウェアでスイッチが必要な場合を除き、冗長な物理ケーブルによってノードを相互に直接接続できるため、スイッチは必要ありません。これらの冗長なケーブルは、各ノードの冗長化されたアダプタに接続されます。3 ノード以上の構成では、スイッチが必要です。
ケーブル – 2 つのネットワークアダプタまたはアダプタとスイッチの間をつなぐ物理接続。
図 3–4に、3 つのコンポーネントがどのように接続されているかを示します。
パブリックネットワークアダプタは、IPMP グループ (マルチパスグループ) として編成されます。各マルチパスグループには、1 つまたは複数のパブリックネットワークアダプタがあります。マルチパスグループの各アダプタはアクティブにすることができます。あるいは、スタンバイインタフェースを構成し、フェイルオーバーが起こるまでそれらを非アクティブにしておくことができます。
マルチパスグループは、論理ホスト名と共有アドレスリソースの基盤です。つまり、ノード上の同じマルチパスグループは、任意の数の論理ホスト名または共有アドレスリソースをホストできます。マルチパスを作成すれば、クラスタノードのパブリックネットワーク接続を監視できます。
論理ホスト名や共有アドレスリソースについては、『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』を参照してください。
クライアントは、パブリックネットワークインタフェースを介してクラスタに接続します。各ネットワークアダプタカードは、カードに複数のハードウェアインタフェースがあるかどうかによって、1 つまたは複数のパブリックネットワークに接続できます。複数のパブリックネットワークインタフェースカードをもつノードを設定することによって、複数のカードをアクティブにし、それぞれを相互のフェイルオーバーバックアップとすることができます。アダプタの 1 つに障害が発生すると、Sun Cluster の Solaris IPMP ソフトウェアが呼び出され、障害のあるインタフェースが同じグループの別のアダプタにフェイルオーバーされます。