test

Sun Cluster 2.2 API 開発ガイド

第 1 章 データサービス API

この章では、Sun Cluster のデータサービス API とデータサービスアプリケーションの高可用性を実現するための概念を紹介します。Solstice HA 1.3 と Sun Cluster 2.x 間の API 実装の違いについても説明します。

概要

Sun Cluster のデータサービス API は、コマンド行ユーティリティと C 言語呼び出し可能ライブラリを使用します。すべての C 言語呼び出し可能ライブラリはコマンド行ユーティリティプログラムを使用しても利用できます。したがって、Bourne シェル (sh(1)) などのスクリプト言語のコードでも使用できます。

次に、API が定義されているマニュアルページを示します。

コマンド行ユーティリティと C 言語呼び出し可能ライブラリについては、マニュアルページを参照してください。

データサービスと Sun Cluster ソフトウェア間の対話

データサービスを初めて Sun Cluster に登録するとき、データサービスはコールバックプログラムのセット (つまり、メソッド) を登録します。重要なイベントがクラスタ内で発生すると、Sun Cluster はデータサービスのメソッドに対してコールバックを行います。この節では、任意のデータサービスを Sun Cluster 環境で実行するために必要な 3 つの基本的なメソッド、start、stop、abort について説明します。

あるホストで障害が発生すると、Sun Cluster は論理ホスト (ディスクセットと論理ネットワーク IP アドレスの両方) を正常に動作しているホストに移動します。この時点で、データサービスのソフトウェアをその正常に動作しているホスト上で再起動しなければなりません。Sun Cluster 自身はデータサービスを再起動できません。その代わりに、データサービスに自分自身を再起動するように伝える呼び出しを行います。つまり、データサービスの start メソッドまたは start_net メソッドに対して呼び出しを行います。

Sun Cluster の haswitch(1M) コマンドは、ある物理サーバー上の論理ホストを正常に停止し、別の物理サーバーに論理ホストを移動する準備を行います。Sun Cluster がこの停止作業を階層化データサービスで行うために、各データサービスは stop メソッドも登録します。scadmin switch または haswitch(1M) の操作中、および scadmin stopnode で Sun Cluster を停止したとき、Sun Cluster はデータサービスの stop メソッドを呼び出します。この stop メソッドはデータサービスを正常かつ安全に停止します。時間がかかる可能性があるため、stop メソッドはネットワーク上のクライアントが各自作業を完了するのを待たずにデータベースを停止します。

Sun Cluster はクラスタ内の物理サーバーの動作状況を継続的に監視します。物理サーバーが異常終了したとき、Sun Cluster は、サーバーを停止および再起動する前に、最終手段としてのクリーンアップコードを実行できるかどうかを決定します。実行できると決定した場合、Sun Cluster は、サーバーを停止する前に、最終手段としてのクリーンアップコードを実行するための機会を各データサービスに与えます。最終手段としてのクリーンアップを行う機会が必要ないデータサービスは abort メソッドを登録しなくてもかまいません。

論理ホストの構成についての問題

Sun Cluster の論理ホストという概念を利用すると、データサービスの高可用性を実現できます。データサービスのデータは論理ホストのディスクセットに格納されます。ディスクセットはデュアルポート形式であり、あるサーバーが異常終了したときには、動作中のサーバーからデータをアクセスできます。ネットワーク上のクライアントがネットワークにアクセスするために、データサービスは、クライアントが使用すべきサーバー名として論理ホスト名を通知します。論理ネットワーク IP アドレスがフェイルオーバーすると、データサービスのネットワーククライアントは論理ホストとともに移動します。

単一または複数の論理ホストを使用するデータサービス

Sun Cluster では、論理ホストの数は任意です。したがって、データサービスの実装は量に依存してはなりません。データサービスのデータを単一の論理ホストに保存するか、複数の論理ホストに保存するかを決定する必要があります。

一般的に、単一の論理ホストにデータサービスのデータを保存するように設計および実装する方が簡単です。この場合、データサービスのすべてのデータは単一の論理ホストのディスクセットに格納されます。データサービスには 1 セットのデーモンだけが必要です。物理ホストがこのデータサービス用のデーモンを実行するのは、その物理ホストが物理ホストのマスターになっている場合だけです。物理ホストが論理ホストのマスターをテイクオーバーするときは、データサービスの start メソッドでデーモンを起動します。物理ホストが論理ホストのマスターを放棄するときは、データサービスの stop メソッドでデーモンを停止します。場合によっては、強制終了シグナルを送信してデーモンを強制終了するだけでもかまいません。

複数の論理ホストを使用する場合は、データサービスのデータを異なるセットに分割しなければなりません。データを分割するときは、データサービスが実行する 1 つの操作に必要なデータが、複数のセットに分かれないように分割しなければなりません。

Sun の HA-NFS 製品を考えた場合、複数のファイルシステムが存在し、各ファイルシステムに異なるデータが格納されています。HA-NFS の場合、各論理ホストは独自の NFSTM ファイルシステムセットを持ちます。各物理ホストは、マスターしている論理ホストに属するファイルシステムを NFS により共有します。2 つの論理ホストに属する NFS ファイルシステムセットは分割されます。

複数の論理ホストを使用すると、ある程度の基本負荷均衡を実現できます。つまり、両方の物理ホストが起動しているとき、各物理ホストは論理ホストの 1 つをマスターし、その論理ホストに対するデータサービスのトラフィックを処理できます。したがって、両方の物理ホストはお互いにスタンバイ状態になることができるため、効率よく作業できます。

いくつかのデータサービスでは、データを分割するとき、データサービスの操作に必要なデータが複数のセットに分かれないようにすることが不可能なものもあります。第 2 章「データサービスの例」で説明する in.named の例がこのようなデータサービスです。相互依存するデータファイルは 1 セットだけであるため、異なるセットに分割することは困難です。

注 -

簡単にデータを分割できない場合や、複数の論理ホストを使用しても基本負荷均衡があまり期待できない場合は、単一の論理ホストを使用するようにデータサービスを構成してください。

各論理ホストの必須ファイルシステム

Sun Cluster では、各論理ホストに (1 つまたは複数のファイルシステムまたは raw パーティションを持つ) ディスクセットが少なくとも 1 つ必要です。また、各論理ホストに特別なファイルシステムが 1 つ必要です。特別なファイルシステムとは、必ず存在し、特定の名前を持つ (つまり、名前空間階層中の特定のディレクトリ名にマウントされている) ファイルシステムのことです。Sun Cluster を初めてインストールして構成するとき、管理者は scconf(1M) プログラムを使用し、必要なファイルシステムを作成し、必須規約に準拠させます。Sun Cluster では、このような必須ファイルシステムのことを「管理ファイルシステム」と呼びます。

必須管理ファイルシステムの規約

データサービスが管理ファイルシステムを使用する場合は、この項で説明する規約に準拠しなければなりません。

データサービスごとのサブディレクトリ

各データサービスの管理データは、管理ファイルシステムの下にある各データサービス独自のサブディレクトリに格納しなければなりません。たとえば、データサービスが Solaris パッケージを使用する場合、サブディレクトリ名は /administrative_file_system/PkgName という形式でなければなりません (PkgName はデータサービスパッケージの名前)。

データサービスがパッケージ機構を使用しない場合、サブディレクトリ名は、hareg(1M) で Sun Cluster に登録したときにデータサービス名として使用した名前と同じでなければなりません。hareg(1M) ユーティリティは、名前に関する衝突を検出および禁止します。たとえば、論理ホスト「hahost1」を使用する実装において、「hainnamed」という名前を hareg(1M) で登録した場合は、 /hahost1/hainnamed という名前の管理サブディレクトリを作成します。

少量のデータ

管理ファイルシステムは比較的小さなファイルシステムです。各データサービスは管理ファイルシステムに保存する管理データの量を数 K バイトに制限しなければなりません。大きな管理データが必要な場合は、管理ファイルシステムを (論理ホストのファイルシステムにある別のディレクトリを指す) 使用します。ほとんどのデータサービスにおいてデータは大きくなるため、データサービスのユーザーデータは管理ファイルシステムに格納してはなりません。

データサービスの要件

この後の節では、データサービスが 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 メソッドでデータサービスのデーモンを強制終了および再起動する場合、データサービスは適切な時間にネットワークアドレスの使用を停止および開始します。

クライアントの再試行

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

データサービスの登録

データサービスを Sun Cluster に登録するには、hareg(1M) プログラムを使用します。一度登録すると、テイクオーバー、スイッチオーバー、再起動などが発生しても、登録は無効になりません。Sun Cluster への登録は、通常、データサービスのインストールおよび構成の最後の手順で行います。登録は 1 度だけの操作です。データサービスを Sun Cluster から登録解除するにも、hareg(1M) を使用します。詳細は、hareg(1M) のマニュアルページを参照してください。

登録と登録解除の概念に加えて、Sun Cluster にはデータサービスの「オン」と「オフ」の概念もあります。この「オン」と「オフ」の状態の目的は、データサービスの登録を解除するのではなく、データサービスを一時的に停止する機構をシステム管理者に提供することです。たとえば、システム管理者はデータサービスを「オフ」にしてから、スタンドアロンのバックアップを取ることができます。データサービスが「オフ」の間、クライアントにはサービスは提供されません。データサービスが「オフ」のとき、Sun Cluster がデータサービスのメソッドに渡すパラメータは、データサービスがどの論理ホストからもデータをサービスしてはならないことを示します。

初めて Sun Cluster に登録するとき、データサービスの初期状態は「オフ」です。データサービスの状態を「オフ」から「オン」に切り替えるには、hareg(1M) プログラムを使用します。データサービスの状態の変更を完了するには、再構成する必要があります。詳細は、hareg(1M) のマニュアルページを参照してください。

データサービスの登録を解除する前に、システム管理者はまず hareg(1M) を呼び出し、データサービスを「オフ」の状態にしなければなりません。

Solstice HA 1.3 と Sun Cluster 2.x API の違い

Solstice HA の hareg(1M) のマニュアルページには、明示的な再構成シーケンスが定義されていました。たとえば、stop メソッドが呼び出されるのは start メソッドが呼び出される前であり、stop メソッドが呼び出されるときは start メソッドも最終的に呼び出されるなどです。

しかし、Sun Cluster 2.x の実装は Solstice HA モデルから変更されています。Sun Cluster 2.x の場合は特に、全体的な再構成シーケンスに過度に依存してはなりません。次のようなことが発生する可能性があります。

Solstice HA 1.3 と Sun Cluster 2.x 間の違いへの対処

この節では、API の違いに対処できるようにアプリケーションを調整する方法について説明します。

API 定義 (および、その実装の両方) は、最終的にメソッドのコールバックの機能が「呼び出された回数に依存しない」ことが必要です。つまり、何回も呼び出すことができ、さらに、その影響は 1 回呼び出したときと同じです。実際には、コールバックされるメソッドは、何回か前のメソッドの呼び出しですでに実際の作業が行われているときは、何もしないように設計されていなければなりません。具体的には、移動する論理ホストに作業を行うかどうかを判断するロジックがメソッドに必要です。このようなロジックがない場合、メソッドは戻るだけにすべきです。この例については、第 2 章「データサービスの例」 で説明します。

データサービスのコールバックの機能を呼び出し回数に依存させないことで、これらの API の実装の違いを最小限にすることができます。