アプリケーションの適合性の分析

データサービスを作成するための最初の手順では、ターゲットアプリケーションが高可用性またはスケーラビリティを備えるための要件を満たしているかどうかを判定します。すべての要件を満たしていない場合は、要件を満たすようにアプリケーションのソースコードを変更します。

次に、アプリケーションが高可用性またはスケーラビリティを備えるための要件を要約します。要件に関する詳細情報を確認したい場合や、アプリケーションのソースコードを変更する必要がある場合は、付録 B 「データサービスのコード例」を参照してください。

スケーラブルサービスを実現するためには、次に示す高可用性の要件をすべて満たした上で、いくつかの追加要件も満たしている必要があります。

• Sun Cluster 環境では、ネットワーク対応 (クライアントサーバーモデル) とネットワーク非対応 (クライアントレス) のアプリケーションはどちらも、高可用性またはスケーラビリティを備えることが可能です。ただし、タイムシェアリング環境では、アプリケーションは サーバー上で動作し、telnet または rlogin 経由でアクセスされるため、Sun Cluster の可用性を強化することはできません。

• アプリケーションはクラッシュに対する耐障害性 (クラッシュトレラント) を備えていなければなりません。つまり、ノードが予期せぬ停止状態になった後、アプリケーションは再起動時に必要なディスクデータを復元できなければなりません。さらに、クラッシュ後の復元時間にも制限が課せられます。ディスクを復元し、アプリケーションを再起動できる能力は、データの整合性に関わる問題であるため、クラッシュトレラントであることは、アプリケーションが高可用性を備えるための前提条件となります。データサービスは接続を復元できる必要はありません。

• アプリケーションは、自身が動作するノードの物理的なホスト名に依存してはなりません。詳細については、ホスト名を参照してください。

• アプリケーションは、複数の IP アドレスが構成されている環境で正しく動作する必要があります。たとえば、ノードが複数のパブリックネットワーク上に存在する多重ホームホスト環境や、単一のハードウェアインタフェース上に複数の論理インタフェースが構成されているノードが存在する環境で正しく動作しなければなりません。

• 高可用性を備えるには、アプリケーションデータはクラスタファイルシステム内に格納されている必要があります。多重ホストデータを参照してください。

  アプリケーションがデータの格納先を示すのに固定されたパス名を使用している場合、アプリケーションのソースコードを変更しなくても、そのパスをクラスタファイルシステム内の場所を指すシンボリックリンクに変更できる場合があります。詳細については、多重ホストデータを配置するためのシンボリックリンクの使用を参照してください。

• アプリケーションのバイナリとライブラリは、ローカルの各ノードまたはクラスタファイルシステムのどちらにも格納できます。クラスタファイルシステム上に格納する利点は、1 箇所にインストールするだけで済む点です。欠点としては、アプリケーションが RGM の制御下で動作している間はバイナリファイルが使用中になるので、ローリングアップグレードの問題が生じることが挙げられます。

• 初回の照会がタイムアウトした場合、クライアントは自動的に照会を再試行できる必要があります。アプリケーションとプロトコルがすでに単一サーバーのクラッシュと再起動に対応できている場合、関連するリソースグループのフェイルオーバーまたはスイッチオーバーにも対応できる必要があります。詳細については、クライアントの再試行を参照してください。

• アプリケーションは、クラスタファイルシステム内で UNIX ドメインソケットまたは名前付きパイプを使用してはなりません。

さらに、スケーラブルサービスは、次の要件も満たしている必要があります。

• アプリケーションは、複数のインスタンスを実行でき、すべてのインスタンスがクラスタファイルシステム内の同じアプリケーションデータを処理できる必要があります。

• アプリケーションは、複数のノードからの同時アクセスに対してデータの整合性を保証する必要があります。

• アプリケーションは、クラスタファイルシステムのように、広域的に使用可能な機構を備えたロック機能を実装している必要があります。

スケーラブルサービスの場合、アプリケーションの特性により負荷均衡ポリシーが決定されます。たとえば、負荷均衡ポリシー LB_WEIGHTED は、任意のインスタンスがクライアントの要求に応答できるポリシーですが、クライアント接続にサーバー上のメモリー内キャッシュを使用するアプリケーションには適用されません。この場合、特定のクライアントのトラフィックをアプリケーションの 1 つのインスタンスに制限する負荷均衡ポリシーを指定する必要があります。負荷均衡ポリシー LB_STICKY と LB_STICKY_WILD は、クライアントからのすべての要求を同じアプリケーションインスタンスに繰り返して送信します。この場合、アプリケーションはメモリー内キャッシュを使用できます。異なるクライアントから複数の要求が送信された場合、RGM はサービスの複数のインスタンスに要求を分配します。スケーラブルデータサービスに対応した負荷均衡ポリシーを設定する方法については、スケーラブルリソースの実装を参照してください。