データサービスの要件

この後の節では、データサービスが Sun Cluster のデータサービス API に適合するために準拠しなければならない要件について説明します。

クライアントサーバー環境

Sun Cluster は、クライアントサーバーネットワーク環境用に設計されています。telnet または rlogin 経由でアクセスされるサーバー上でアプリケーションが動作するタイムシェアリング環境では動作できません。このような環境では、通常、サーバーに障害が発生しても回復できません。

障害の耐性

データサービスは障害に対する耐性を持たなければなりません。つまり、データサービスのデーモンプロセスは相対的な状態を持たないように (つまり、すべての更新を同期的にディスクに書き込むこと) しなければなりません。

論理ホストを管理する物理ホストに障害が発生し、新しい物理ホストが管理を引き継いだとき、Sun Cluster は各データサービスの start メソッドを呼び出します。start メソッドが呼び出されると、ディスク上のデータの障害からの回復が始まります。たとえば、データサービスがロギング技術を使用している場合、start メソッドが呼び出されると、データサービスはログを使用して障害からの回復を行います。

多重ホストデータ

ある物理ホストに障害が発生したときに、正常に動作しているホストの 1 つがディスクにアクセスできるように、論理ホストのディスクセットは多重ホスト化されます。データサービスの高可用性を実現するには、そのデータの可用性が高いこと、つまり、そのデータが論理ホストのディスクセットに格納されていることが必要です。

データサービスは、データファイルの位置を指すコマンド行スイッチまたは構成ファイルを持っていることもあります。データサービスが固定されたパス名を使用する場合は、データサービスのコードを変更せずに、このパス名を論理ホストのディスクセットにあるファイルを指すシンボリックリンクに変更できます。シンボリックリンクを使用する方法についての詳細は、付録 A 「多重ホストデータを配置するためのシンボリックリンクの使用」 を参照してください。

最悪の場合は、実際のデータの位置を指すような何らかの機構を使用し、データサービスのコードを変更しなければなりません。この作業は、コマンド行スイッチを追加することにより行うことができます。

Sun Cluster は、論理ホストのディスクセット上における UFS、VxFS、および raw パーティションをサポートしています。Sun Cluster をインストールおよび構成するとき、システム管理者は、どのディスクリソースを UFS または VxFS のファイルシステム、あるいは raw パーティション用に使用するのかを指定しなければなりません。通常、raw パーティションはデータベースサーバーとマルチメディアサーバー用だけに使用します。

ホスト名

データサービスが動作しているサーバーのホスト名を、データサービスが知る必要があるかどうかを判断しなければなりません。知る必要があると判断した場合は、物理ホストではなく、論理ホストのホスト名を使用するようにデータサービスを変更する必要があります。ここで、Sun Cluster の「論理ホスト」の概念を思い出してください。物理ホストに論理ホストのホスト名と IP アドレスを「まねさせる」ことを意味します。

あるデータサービスのクライアントサーバープロトコルでは、サーバーが自分のホスト名をクライアントへのメッセージの一部としてクライアントに戻すことがあります。このようなプロトコルでは、クライアントは戻されたホスト名をサーバーに接続するときのホスト名として使用できます。戻されたホスト名をテイクオーバーやスイッチオーバーが発生した後にも使用できるようにするには、物理ホストではなく、論理ホストのホスト名を使用しなければなりません。物理ホストのホスト名を使用している場合は、論理ホスト名をクライアントに戻すようにデータサービスのコードを変更しなければなりません。

多重ホームホスト

多重ホームホストとは、複数のパブリックネットワーク上にあるホストのことです。このようなホストは複数 (つまり、ネットワークごとに 1 つ) のホスト名/IP アドレスのペアを持ちます。Sun Cluster は、1 つのホストが複数のネットワーク上に存在できるように設計されています。1 つのホストが単一のネットワーク上に存在することも可能ですが、このような場合は「多重ホームホスト」とは呼びません。物理ホスト名が複数のホスト名/IP アドレスのペアを持つように、各論理ホストも複数 (つまり、パブリックネットワークごとに 1 つ) のホスト名/IP アドレスのペアを持ちます。慣習上、ペアのセットのホスト名 1 つには、論理ホストと同じホスト名を持つペアが存在します。Sun Cluster が論理ホストをある物理ホストから別の物理ホストに移動するとき、その論理ホストに対するホスト名/IP アドレスのペアもすべて移動します。

Sun Cluster の各論理ホストにおいて、ホスト名/IP アドレスのペアのセットは Sun Cluster 構成データの一部であり、Sun Cluster を初めてインストールおよび構成するときに管理者により指定されます。Sun Cluster のデータサービス API には、ペアのセットを照会する機能があります。hads(3HA) と haget(1M) のマニュアルページにある names_on_subnets フィールドを参照してください。

ほとんどの市販のデータサービスデーモンは Solaris 用に書かれており、多重ホームホストを適切に処理できます。ネットワーク通信を行うとき、多くのデータサービスは Solaris のワイルドカードアドレス INADDR_ANY にバインドします。すると、INADDR_ANY は、すべてのネットワークインタフェースのすべての IP アドレスを自動的に処理します。INADDR_ANY は、現在マシンに構成されているすべての IP アドレスに効率的にバインドします。一般的に、INADDR_ANY を使用するデータサービスデーモンを変更しなくても、Sun Cluster の論理ホストの IP アドレスを処理できます。

INADDR_ANY へのバインドと特定の IP アドレスへのバインド

Sun Cluster の論理ホストの概念では、多重ホーム化されていない環境でも、マシンは複数の IP アドレスを持つことができます。つまり、独自の物理ホストの IP アドレスを 1 つだけ持ち、さらに、現在マスターしている論理ホストごとに 1 つの IP アドレスを持ちます。マシンが論理ホストのマスターになるとき、そのマシンは動的に追加の IP アドレスを獲得します。論理ホストのマスターを終了するとき、マシンは動的に IP アドレスを放棄します。

データサービスの中には、INADDR_ANY を使用するだけでは適切に動作しないものもあります。このようなデータサービスは、論理ホストのマスターになる時、またマスターをやめる時に、バインドする IP アドレスのセットを動的に変更しなければなりません。start メソッドまたは stop メソッドを呼び出すと、Sun Cluster は論理ホストが出現または消滅したことをデータサービスに知らせます。このようなデータサービスが再バインドする方法の 1 つが、stop メソッドと start メソッドを使用し、データサービスのデーモンを強制終了および再起動するという方法です。

クラスタの再構成時、データサービスのメソッドが呼び出される順番と、論理ホストのネットワークアドレスが Sun Cluster により構成される時間との間には関係があります。この関係についての詳細は、hareg(1M) のマニュアルページを参照してください。

データサービスは、stop メソッドが戻ってくるまでに、論理ホストの IP アドレスの使用を終了していなければなりません。同様に、データサービスは、start_net メソッドが戻ってくるまでに、論理ホストの IP アドレスの使用を開始していなければなりません。データサービスが、個々の IP アドレスにバインドするのではなく、INADDR_ANY を使用する場合は問題ありません。データサービスの stop メソッドと start メソッドでデータサービスのデーモンを強制終了および再起動する場合、データサービスは適切な時間にネットワークアドレスの使用を停止および開始します。

クライアントの再試行

ネットワーククライアントから見ると、テイクオーバーやスイッチオーバーは、論理ホストに障害が発生し、高速再起動しているように見えます。したがって、クライアントアプリケーションとクライアントサーバープロトコルは、このような場合に何回か再試行するように構成されていることが理想的です。すでに、単一サーバーの障害と高速再起動を処理するように構成されているアプリケーションとプロトコルは、上記のような場合も、論理ホストのテイクオーバーやスイッチオーバーとして処理してしまいます。無限に再試行するようなアプリケーションもあります。また、何回も再試行していることをユーザーに通知し、さらに継続するかどうかをユーザーにたずねるような、より洗練されたアプリケーションもあります。