アプリケーションがスケーラブルサービスになれるかどうかを判断するには、いくつかの基準があります。アプリケーションがスケーラブルサービスになれるかどうかを判断する方法については、『Sun Cluster データサービス開発ガイド (Solaris OS 版)』の「アプリケーションの適合性の分析」を参照してください。
次に、これらの基準の要約を示します。
第 1 に、このようなサービスは 1 つまたは複数のサーバーインスタンスから構成されます。各インスタンスは、異なるノードで実行されます。同じサービスの複数のインスタンスを、同じノードで実行することはできません。
第 2 に、このサービスが外部の論理データストアを提供する場合は、十分に注意する必要があります。このストアに複数のサーバーインスタンスから並行にアクセスする場合、このような並行アクセスの同期をとることによって、更新を失ったり、変更中のデータを読み取ったりすることを避ける必要があります。「外部」という用語は、このストアとメモリー内の状態を区別するために使用しています。「論理」という用語は、ストア自体複製されている場合でも、単一の実体として見えることを表します。さらに、このデータストアでは、サーバーインスタンスがデータストアを更新すると、その更新がすぐにほかのインスタンスで「認識」されます。
Sun Cluster ソフトウェアは、このような外部記憶領域をそのクラスタファイルシステムと広域 raw パーティションを介して提供します。例として、サービスが外部ログファイルに新しいデータを書き込む場合や既存のデータを修正する場合を想定してください。このサービスのインスタンスが複数実行されている場合、各インスタンスはこの外部ログへのアクセスを持ち、このログに同時にアクセスできます。各インスタンスは、このログに対するアクセスの同期をとる必要があります。そうしないと、インスタンスは相互に妨害しあうことになります。このサービスは、fcntl と lockf による通常の Solaris ファイルロック機能を使用して、必要な同期をとることができます。
この種類のデータストアのもう一つの例はバックエンドデータベースで、たとえば、Oracle や SPARC ベースのクラスタ用の高可用性 Oracle Real Application Clusters Guard などがあります。この種類のバックエンドデータベースサーバーには、データベース照会または更新トランザクションによる同期が組み込まれています。したがって、複数のサーバーインスタンスが独自の同期を実装する必要はありません。
スケーラブルサービスではないサービスの例としては、Sun の IMAP サーバーがあります。このサービスは記憶領域を更新しますが、その記憶領域はプライベートであり、複数の IMAP インスタンスがこの記憶領域に書き込むと、更新の同期がとられないために相互に上書きし合うことになります。IMAP サーバーは、同時アクセスの同期をとるよう書き直す必要があります。
最後に、インスタンスは、ほかのインスタンスのデータから切り離されたプライベートデータを持つ場合があることに注意してください。このような場合、データはプライベートであり、そのインスタンスだけがデータを処理するため、サービスは並行アクセスの同期をとる必要はありません。この場合、個人的なデータをクラスタファイルシステムに保存すると、これらのデータが広域にアクセス可能になる可能性があるため、十分に注意する必要があります。