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

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

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

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

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

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

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

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

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

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

• アプリケーションのバイナリとライブラリは、ローカルの各ノードまたはクラスタファイルシステムに格納できます。クラスタファイルシステム上に格納する利点は、1 箇所にインストールするだけで済む点です。 不便な点は、順次アップグレードを使用する場合、アプリケーションが RGM 制御のもとで動作している間はバイナリが使用されることです。

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

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

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

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

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

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

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