この章では,アプリケーションをクラスタ内で実行できるようにするために行う,アプリケーションのソース・コードへの変更について説明します。実際に変更を行うには,アプリケーションのソース・ファイルにアクセスできなければなりません。
この章では,次の項目について説明します。
リモート・プロシージャ・コール (RPC) プログラムに必要な変更 (7.1 節)
移植性のあるアプリケーション -- クラスタ・システムやスタンドアロン・システムで動作するアプリケーションの開発 (7.2 節)
CLSM (Cluster Logical Storage Manager) のサポート (7.3 節)
診断ユーティリティのサポート (7.4 節)
CDFS (Compact Disc-Read Only Memory File System) ファイル・システムの制約 (7.5 節)
/cluster/admin/run
ディレクトリから呼ばれるスクリプト (7.6 節)
ローリング・アップグレード中のクラスタ・メンバの状態(7.7 節)
クラスタにおけるファイル・アクセスの回復力 (7.8 節)
既存の,カプセル化されていないリモート・プロシージャ・コール (RPC) プログラムを次のように変更して,クラスタ環境で実行できるようにします。
クラスタ環境で実行されているときに,bind
() への呼び出しから
clusvc_getcommport
() または
clusvc_getresvcommport
() への呼び出しに切り替えられるように,コードに条件判定を組み込みます。これらの関数は,RPC アプリケーションを複数のクラスタ・メンバ上で実行し,クラスタ別名を使ってこれにアクセスできるようにしたい場合にだけ使用します。これらの関数では,RPC
アプリケーションのそれぞれのインスタンスが同じ共用ポートを使用することが保証され,また,ポート・マッパにそのアプリケーションがマルチ・インスタンスの別名アプリケーションであることが伝えられます。詳細は,
clusvc_getcommport
(3)clusvc_getresvcommport
(3)
svc_register
() を呼び出さないサービスは,clua_registerservice
()
を呼び出して,到着したクラスタ別名接続要求を,そのサービスが受け取れるようにしなければなりません。詳細は,
clua_registerservice
(3)clusvc_getcommport
() と
clusvc_getresvcommport
() は,自動的に
clua_registerservice
() を呼び出します)。
7.2 移植性のあるアプリケーション: スタンドアロンとクラスタ
Tru64 UNIX バージョン 5.0 以降では,クラスタ・システムとスタンドアロン・システムのどちらでも実行できるアプリケーションを簡単に開発できる,次のような組み込み機能が提供されています。
Tru64 UNIX バージョン 5.0 以降のスタブ・ライブラリによって,TruCluster Server で提供される
libclu.so
API ライブラリの関数を呼び出すアプリケーションを作成することができます。
libc
で用意されている
clu_is_member
() 関数は,ローカル・システムがクラスタ・メンバかどうかを判断します。この関数は,ローカル・システムがクラスタ・メンバの場合は TRUE を返し,クラスタ・メンバでない場合は FALSE を返します。
libc
で用意されている
clu_is_ready
() 関数も,ローカル・システムがクラスタ・メンバとして構成されているかどうか (つまり,TruCluster Server Software がインストールされ,システムがクラスタ対応のカーネルを実行しているかどうか) を判断します。この関数は,ローカル・システムがクラスタ内で動作している場合は TRUE を返し,動作していない場合は FALSE を返します。clu_is_ready
() 関数は,接続マネージャがクラスタ・メンバシップを確立する前に,ブート・パスで実行されるコードの中で一番有用な関数です。
clu_info
() 関数と
clu_get_info
() コマンドは,構成に関する情報,またはそのシステムがクラスタ内で構成されていないことを示す値を返します。
詳細は,
clu_info
(3)clu_is_member
(3)clu_get_info
(8)7.3 CLSM のサポート
CLSM (Cluster Logical Storage Manager) は,2 つの異なるノード間でミラーリングされているボリュームに対する,通常の入出力のインターロックをサポートしていません。CLSM では,異なるノードから同じボリュームを同時にオープンするアプリケーションは,同じブロックに同時に書き込まないようにするための必要なロックをすでに行なっていると仮定しています。つまり,クラスタ対応のアプリケーションの統制がとれていなくて,CLSM ミラー・ボリューム上の同じブロックに対して異なるノードから書き込みが行われた場合には,データの整合性が失われます。
OPS (Oracle Parallel Server) では,このような事態にはなりません。OPS が分散ロック・マネージャ (DLM) を使って,このような状況を回避しているからです。クラスタ・ファイル・システム (CFS) の場合も,このような事態にはなりません。ファイル・システムは一度に 1 つのノードしかマウントできないからです。
CLSM は,ミラー・ボリュームへの定常状態の入出力では,異なるノード間のインターロックを行いませんが,ミラーの回復とプレックスの組み込み用には,ノード間のインターロック機能を用意しています。
7.4 診断ユーティリティのサポート
アプリケーションやサブシステムの診断ユーティリティがすでにある場合または作成する場合,TruCluster Server の
clu_check_config
コマンドは,その診断ユーティリティを呼び出して実行するとともに,ログ・ファイルを保持することができます。
クラスタ環境に診断ユーティリティを追加する方法と,clu_check_config
コマンドでそれを呼び出す方法については,
clu_check_config
(8)7.5 CDFS ファイル・システムの制約
TruCluster Server 環境では,CDFS (Compact Disc-Read Only Memory File System) ファイル・システムをクラスタ内で管理する際に制約があります。クラスタ・システムとスタンドアロン・システムで,異なる動きをするコマンドやライブラリ関数があります。
表 7-1
に,CDFS ライブラリ関数と TruCluster Server 環境での予想される動作を示します。
表 7-1: CDFS ライブラリ関数
ライブラリ関数 | サーバでの予想される結果 | クライアントでの予想される結果 |
cd_drec |
成功 | サポートされていない |
cd_ptrec |
成功 | サポートされていない |
cd_pvd |
成功 | サポートされていない |
cd_suf |
成功 | サポートされていない |
cd_type |
成功 | サポートされていない |
cd_xar |
成功 | サポートされていない |
cd_nmconv CD_GETNMCONV |
成功 | 成功 |
cd_nmconv CD_SETNMCONV |
成功 | 成功 |
cd_getdevmap |
マップなし | サポートされていない |
cd_setdevmap |
サポートされていない | サポートされていない |
cd_idmap CD_GETUMAP CD_GETGMAP |
成功 | サポートされていない |
cd_idmap CD_SETUMAP
CD_SETGMAP |
成功 | 成功 |
cd_defs CD_GETDEFS |
成功 | 成功 |
cd_defs CD_SETDEFS |
成功 | 成功 |
クラスタの CDFS ファイル・システムを管理する方法についての詳細は,TruCluster Server の『クラスタ管理ガイド』 を参照してください。
7.6 /cluster/admin/run ディレクトリから呼び出されるスクリプト
クラスタが作成されるとき,メンバが追加されるとき,また削除されるときに,特定の処理を行う必要があるアプリケーションでは,/cluster/admin/run
ディレクトリにスクリプトを置くことができます。このスクリプトは,初期クラスタ・メンバの最初のブート時に
clu_create
の実行に続いて呼び出されます。clu_add_member
に続いては,クラスタの各メンバ (最も新しいものも含めて) について呼び出され,clu_delete_member
に続いては,残りのすべてのクラスタ・メンバについて呼び出されます。
/cluster/admin/run
内のスクリプトには,次のエントリ・ポイントを記述する必要があります。
-c
clu_create
の実行時にとるべき処理
-a
clu_add_member
の実行時にとるべき処理
-d memberid
clu_delete_member
の実行時にとるべき処理
root
が実行できるファイルやファイルへのシンボリック・リンクだけを,/cluster/admin/run
ディレクトリに置きます。できるだけ,次のファイル命名規則に従うようにしてください。
実行可能ファイルは,大文字
C
で始める。
次の 2 つの文字は
/sbin/rc3.d
内で使われる順番を示す続き番号にする。番号が小さいスクリプトから先に実行される。これらのスクリプトはシングル・ユーザ・モードで実行されるため,すべてのデーモンおよびサービスは利用できない。
残りの文字は,スクリプトに対応する名前にする。
この命名規則を使用したファイル名の例を次に示します。
/cluster/admin/run/C40sendmail
clu_create
,clu_add_member
,および
clu_delete_member
コマンドでは,必要な
it
(8)7.7 ローリング・アップグレード中のクラスタ・メンバの状態のテスト
次のプログラム例に,クラスタがローリング・アップグレード中であるかどうかと,クラスタ・メンバがローリングされたかどうかを調べる方法の例を示します。
#include <stdio.h> #include <sys/clu.h> /* compile with -lclu */ #define DEBUG 1 main() { struct clu_gen_info *clu_gen_ptr = NULL; char cmd[256]; if (clu_is_member()) { if (clu_get_info(&clu_gen_ptr) == 0) { if(system("/usr/sbin/clu_upgrade -q status") == 0) { sprintf(cmd, "/usr/sbin/clu_upgrade -q check roll %d", clu_gen_ptr->my_memberid); if (system(cmd) == 0) { if (DEBUG) printf("member has rolled\n"); } else if (DEBUG) printf("member has not rolled\n"); } else if (DEBUG) printf("no rolling upgrade in progress\n"); } else if (DEBUG) printf("nonzero return from clu_get_info(\n"); } else if (DEBUG) printf("not a member of a cluster\n"); }
クラスタのアプリケーションがファイルを転送している最中にそのアプリケーションを実行しているメンバがシャットダウンされるか障害が発生すると,そのファイルの読み取り/書き込み操作は失敗します。そのような場合,アプリケーションのクライアントにはサーバとの間の接続が切れたように見えるのが普通です。アプリケーションが消失した接続をどのように処理するかに注意してください。アプリケーションが消失した接続を処理する方法には次のようなものがあります。
クライアントのアプリケーションが単に異常終了する (たとえば,エラーをログに出力して,アプリケーションが終了する)。
クライアントのアプリケーションはコネクションの問題を知ると自動的に読み取り/書き込み操作を再試行する。
クライアントのアプリケーションはコネクションの問題を知ると,ウィンドウにそのことを表示して,操作を中止するか,再試行するか,またはキャンセルするかの決定をユーザに任せる。
サーバ・アプリケーションとの間の接続が消失した場合に (それがシングル・システムまたはクラスタのどちらで動作しているかに関係なく) クライアントのアプリケーションが異常終了するようであれば,次に示す方法を検討してください。
ファイルを更新するとき,最初にそのアップデートを新しい一時ファイルに書く。書き込みが成功したら,一時ファイルの内容を元のファイルに上書きする。書き込みが失敗しても,元のファイルはそのまま残るので,一時ファイルを消して再び処理を開始するだけでよい。
ファイルを読み取る場合は,アプリケーションが読み取り操作のエラーを処理してそのエラーから復帰できるようになっていることを確認する (たとえば,操作の再試行)。