Solstice HA の hareg(1M) のマニュアルページには、明示的な再構成シーケンスが定義されていました。たとえば、stop メソッドが呼び出されるのは start メソッドが呼び出される前であり、stop メソッドが呼び出されるときは start メソッドも最終的に呼び出されるなどです。
しかし、Sun Cluster 2.x の実装は Solstice HA モデルから変更されています。Sun Cluster 2.x の場合は特に、全体的な再構成シーケンスに過度に依存してはなりません。次のようなことが発生する可能性があります。
論理ホストを物理ホストから移動するときは、stop_net メソッドと stop メソッドが呼び出されます。しかし、start メソッドと start_net メソッドは必ずしも呼び出されません。これは、hareg(1M) のマニュアルページの記述とは異なります。
論理ホストを物理ホストに移動するときは、start メソッドと start_net メソッドが呼び出されます。しかし、stop_net メソッドと stop メソッドは必ずしも呼び出されません。これも、hareg(1M) のマニュアルページの記述とは異なります。
Solstice HA 1.3 では、再構成時、移動するすべての論理ホストの各メソッドが 1 回だけ呼び出されるように実装されています。たとえば、物理ホストが 2 つの論理ホストをマスターしていて、その物理ホストに障害が発生したと仮定します。2 つの論理ホストは正常に動作している物理ホストに移動しなければなりません (ここでは、ノードクラスタが 2 つだけと仮定します)。Solstice HA 1.3 では、登録されている各データサービスのメソッドが 1 回だけ呼び出され、当該物理ホストが現在管理しているすべての論理ホストのリストが、メソッド呼び出しの引数として渡されます。Sun Cluster 2.x では、再構成時、論理ホストは 1 度に 1 つずつ移動するように実装されています。したがって、各データサービスのメソッドは複数回 (つまり、移動する論理ホストごとに 1 回) 呼び出されます。
この節では、API の違いに対処できるようにアプリケーションを調整する方法について説明します。
API 定義 (および、その実装の両方) は、最終的にメソッドのコールバックの機能が「呼び出された回数に依存しない」ことが必要です。つまり、何回も呼び出すことができ、さらに、その影響は 1 回呼び出したときと同じです。実際には、コールバックされるメソッドは、何回か前のメソッドの呼び出しですでに実際の作業が行われているときは、何もしないように設計されていなければなりません。具体的には、移動する論理ホストに作業を行うかどうかを判断するロジックがメソッドに必要です。このようなロジックがない場合、メソッドは戻るだけにすべきです。この例については、第 2 章「データサービスの例」 で説明します。
データサービスのコールバックの機能を呼び出し回数に依存させないことで、これらの API の実装の違いを最小限にすることができます。