第 3 章 データサービスの要件

通常、クラスタを認識しないアプリケーションの高可用性 (HA) を実現するには、この章で説明する要件に適合する必要があります。

データサービスの高可用性を実現するには、そのリソースをリソースグループで構成します。データサービスのデータは、高可用性の広域ファイルシステムに格納されます。したがって、1 つのサーバーが異常終了しても、正常に動作しているサーバーがデータにアクセスできます。『Sun Cluster 3.0 の概念』のクラスタファイルシステムに関する情報も参照してください。

ネットワーク上のクライアントがネットワークにアクセスする場合、論理ネットワーク IP アドレスは、データサービスリソースと同じリソースグループにある論理ホスト名リソースで構成されます。データサービスリソースとネットワークアドレスリソースは共にフェイルオーバーします。この場合、データサービスのネットワーククライアントは新しいホスト上のデータサービスリソースにアクセスします。

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

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

障害の耐性

データサービスは障害に対する耐性を持たなければなりません。つまり、クラスタ再構成、scha_control ギブオーバー、または scswitch スイッチオーバーの後で再起動されたとき、データサービスは (必要であれば) ディスクデータをクラッシュから回復する必要があります。クラッシュからの回復 (つまり、ディスクをクラッシュから回復し、データサービスを再起動すること) はデータの完全性の問題であるため、クラッシュの耐性はデータサービスの高可用性を実現するための前提条件となります。

データサービスは接続を回復できなくてもかまいません。

多重ホストデータ

高可用性の広域ファイルシステムのディスクセットは多重ホスト化されているため、ある物理ホストがクラッシュしても、正常に動作している物理ホストの 1 つがディスクにアクセスできます。データサービスの高可用性を実現するには、そのデータが高可用性であること、つまり、そのデータが広域 HA ファイルシステムに格納されていることが必要です。

広域ファイルシステムは、独立したものであるように作成されたディスクグループにマウントされます。ユーザーは、あるディスクグループをマウントされた広域ファイルシステムとして使用し、別のディスクグループをデータサービス (HA Oracle など) で使用する raw デバイスとして使用することもできます。

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

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

Sun Cluster は、ボリューム管理ソフトウェアに構成されている UNIX UFS ファイルシステムと HA の raw デバイスの使用をサポートします。Sun Cluster をインストールおよび構成するとき、システム管理者はどのディスクリソースを UFS ファイルシステムまたは raw デバイス用に使用するかを指定する必要があります。通常、raw デバイスを使用するのは、データベースサーバーとマルチメディアサーバーだけです。

ホスト名

データサービス開発者は、データサービスが動作しているサーバーのホスト名を、データサービスが知る必要があるかどうかを判断する必要があります。知る必要があると判断した場合は、物理ホストではなく、論理ホストのホスト名 (つまり、アプリケーションリソースと同じリソースグループ内にある論理ホスト名リソース内に構成されているホスト名) を使用するようにデータサービスを変更する必要があります。

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

多重ホームホスト

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

リソースグループに対するホスト名/IP アドレスのペアは、リソースグループに含まれる論理ホスト名リソースとして構成されます。このようなネットワークアドレスリソースは、システム管理者がリソースグループを作成および構成するときに指定します。Sun Cluster データサービス API は、このようなホスト名/IP アドレスのペアを照会する機能を持っています。

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

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

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

データサービスの中には、INADDR_ANY にバインドしていると、Sun Cluster 環境で適切に動作しないもあります。このようなデータサービスは、リソースグループのマスターになるとき、またマスターをやめるときに、バインドしている IP アドレスのセットを動的に変更する必要があります。このようなデータサービスが再バインドする方法の 1 つが、起動メソッドと停止メソッドを使用し、データサービスのデーモンを強制終了および再起動するという方法です。

Network_resources_used リソースプロパティを使用すると、エンドユーザーは、アプリケーションリソースをバインドすべきネットワークアドレスリソースを構成できます。この機能が必要なリソースタイプの場合、そのリソースタイプの RTR ファイルで Network_resources_used プロパティを宣言する必要があります。

リソースグループをオンラインまたはオフラインにするとき、RGM は、データサービスリソースメソッドを呼び出す順番に従って、ネットワークアドレスを取り付けて (plumb) 取り外し (unplumb)、「起動」または「停止」に構成します。詳細は、「START と STOP メソッドを使用するかどうかの決定」 を参照してください。

データサービスは、STOP メソッドが戻るまでに、リソースグループのネットワークアドレスの使用を終了している必要があります。同様に、データサービスは、START メソッドが戻るまでに、リソースグループのネットワークアドレスの使用を開始している必要があります。

データサービスが、個々の IP アドレスではなく、INADDR_ANY にバインドする場合、データサービスリソースメソッドが呼び出される順番とネットワークアドレスメソッドが呼び出される順番には重要な関係があります。

データサービスの停止メソッドと起動メソッドでデータサービスのデーモンを終了および再起動する場合、データサービスは適切な時間にネットワークアドレスの使用を停止および開始します。

クライアントの再試行

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

多重ホストデータを配置するためのシンボリックリンクの使用

この節では、データサービスのコードを変更しないようにするために、シンボリックリンクを使用する方法について説明します。既存のデータサービスの中には、そのデータファイルへのパス名が固定されており、しかも、固定されたパス名を変更する機構がないものもあります。データサービスのコードを変更せずに、シンボリックリンクを使用できる場合もあります。

たとえば、データサービスがそのデータファイルに固定されたパス名 /etc/mydatafile を指定すると仮定します。このパスは、論理ホストのファイルシステムの 1 つにあるファイルを示す値を持つシンボリックリンクに変更できます。たとえば、/global/phys-schost-2/mydatafile へのシンボリックリンクに変更できます。

シンボリックリンクの使用には、潜在的な問題があります。つまり、データファイルの名前を内容とともに変更するデータサービス (または、その管理手順) もあります。たとえば、データサービスが更新を実行するとき、まず、新しい一時ファイル /etc/mydatafile.new を作成すると仮定します。次に、このデータベースは rename(2) システムコール (または mv(1) プログラム) を使用し、この一時ファイルの名前を実際のファイルの名前に変更します。一時ファイルを作成し、その名前を実際のファイルの名前に変更することにより、データサービスは、そのデータファイルの内容が常に適切であるようにします。

rename("/etc/mydatafile.new", "/etc/mydatafile");

rename(2) の操作はシンボリックリンクを破壊します。このため、/etc/mydatafile という名前は通常ファイルとなり、クラスタの広域ファイルシステムの中ではなく、/etc ディレクトリと同じファイルシステムの中に存在することになります。/etc ファイルシステムは各ホスト専用であるため、テイクオーバーまたはスイッチオーバー後はデータが利用できなくなります。

このような状況の根本的な問題は、既存のデータサービスがシンボリックリンクに気付かない、つまり、シンボリックリンクを考慮するように作成されていないことです。シンボリックリンクを使用し、データアクセスを論理ホストのファイルシステムにリダイレクトするには、データサービス実装がシンボリックリンクを消去しないように動作する必要があります。したがって、シンボリックリンクは、論理ホストのファイルシステムへのデータの配置に関する問題をすべて解決できるわけではありません。