7    プログラミングの検討項目

この章では,アプリケーションをクラスタ内で実行できるようにするために行う,アプリケーションのソース・コードへの変更について説明します。実際に変更を行うには,アプリケーションのソース・ファイルにアクセスできなければなりません。

この章では,次の項目について説明します。

7.1    RPC プログラムに必要な変更

既存の,カプセル化されていないリモート・プロシージャ・コール (RPC) プログラムを次のように変更して,クラスタ環境で実行できるようにします。

7.2    移植性のあるアプリケーション: スタンドアロンとクラスタ

Tru64 UNIX バージョン 5.0 以降では,クラスタ・システムとスタンドアロン・システムのどちらでも実行できるアプリケーションを簡単に開発できる,次のような組み込み機能が提供されています。

詳細は, 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_nmconvCD_GETNMCONV 成功 成功
cd_nmconvCD_SETNMCONV 成功 成功
cd_getdevmap マップなし サポートされていない
cd_setdevmap サポートされていない サポートされていない
cd_idmapCD_GETUMAPCD_GETGMAP 成功 サポートされていない
cd_idmapCD_SETUMAP CD_SETGMAP 成功 成功
cd_defsCD_GETDEFS 成功 成功
cd_defsCD_SETDEFS 成功 成功

クラスタの CDFS ファイル・システムを管理する方法についての詳細は,TruCluster Server の『クラスタ管理ガイド』 を参照してください。

7.6    /cluster/admin/run ディレクトリから呼び出されるスクリプト

クラスタが作成されるとき,メンバが追加されるとき,また削除されるときに,特定の処理を行う必要があるアプリケーションでは,/cluster/admin/run ディレクトリにスクリプトを置くことができます。このスクリプトは,初期クラスタ・メンバの最初のブート時に clu_create の実行に続いて呼び出されます。clu_add_member に続いては,クラスタの各メンバ (最も新しいものも含めて) について呼び出され,clu_delete_member に続いては,残りのすべてのクラスタ・メンバについて呼び出されます。

/cluster/admin/run 内のスクリプトには,次のエントリ・ポイントを記述する必要があります。

root が実行できるファイルやファイルへのシンボリック・リンクだけを,/cluster/admin/run ディレクトリに置きます。できるだけ,次のファイル命名規則に従うようにしてください。

この命名規則を使用したファイル名の例を次に示します。

/cluster/admin/run/C40sendmail
 

clu_createclu_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");
}
 

7.8    クラスタにおけるファイル・アクセスの障害許容度

クラスタのアプリケーションがファイルを転送している最中にそのアプリケーションを実行しているメンバがシャットダウンされるか障害が発生すると,そのファイルの読み取り/書き込み操作は失敗します。そのような場合,アプリケーションのクライアントにはサーバとの間の接続が切れたように見えるのが普通です。アプリケーションが消失した接続をどのように処理するかに注意してください。アプリケーションが消失した接続を処理する方法には次のようなものがあります。

サーバ・アプリケーションとの間の接続が消失した場合に (それがシングル・システムまたはクラスタのどちらで動作しているかに関係なく) クライアントのアプリケーションが異常終了するようであれば,次に示す方法を検討してください。