4    アプリケーション移行の一般的な問題

この章では,すべてのアプリケーションのタイプにあてはまる移行の問題を採り上げます。表 4-1 に,移行上の問題点,それが発生するアプリケーション,および詳細情報のある節を示します。

表 4-1:  アプリケーション移行での検討項目

検討項目 影響を受けるアプリケーション・タイプ 参照する節
クラスタ単位のファイルとメンバ固有のファイル シングル・インスタンス マルチ・インスタンス 分散型 4.1 節
デバイスの命名規則 シングル・インスタンス マルチ・インスタンス 分散型 4.2 節
プロセス間通信 マルチ・インスタンス 分散型 4.3 節
共用データへの同期アクセス マルチ・インスタンス 分散型 4.4 節
メンバ固有のリソース シングル・インスタンス 4.5 節
拡張プロセス ID (PID) マルチ・インスタンス分散型 4.6 節
削除された分散ロック・マネージャ (DLM) パラメータ マルチ・インスタンス 分散型 4.7 節
ライセンス シングル・インスタンス マルチ・インスタンス 分散型 4.8 節
ブロッキング・レイヤード・プロダクト シングル・インスタンス マルチ・インスタンス 分散型 4.9 節

4.1    クラスタ単位のファイルとメンバ固有のファイル

クラスタには,次の 2 つの構成データのセットがあります。

クラスタ・ファイル・システム (CFS) では,すべてのファイルがすべてのクラスタ・メンバから見えてアクセスできるため,クラスタ単位の構成データが必要なアプリケーションでは,簡単に構成ファイルに書き込むことができ,すべてのメンバでその内容を見ることができます。しかし,メンバ固有の構成情報を使用し保守しなければならないアプリケーションでは,ファイルへの上書きを防ぐために何らかの対処をする必要があります。

ファイルへの上書きを防ぐためには,次の方式の 1 つを採用することを検討してください。

方式 利点 欠点
単一ファイル 管理しやすい。 アプリケーション側で,単一ファイル上のメンバ固有データにどのようにアクセスするかを意識する必要がある。
複数ファイル 構成情報をクラスタ単位のファイルのセットに保持する。 ファイルの複数のコピーを保守する必要がある。アプリケーション側で,メンバ固有のファイルにどのようにアクセスするかを意識する必要がある。
コンテキスト依存シンボリック・リンク (CDSL) 構成情報をメンバ固有の領域に保持する。CDSL は,アプリケーションでは意識する必要がなく,シンボリック・リンクのように見える。 ファイルを移動したり名前を変更するとシンボリック・リンクが壊れる。アプリケーションでは,どのように CDSL を扱うか意識する必要がある。CDSL を使用すると,アプリケーションでは,そのクラスタ内の別のインスタンスについての情報を見つけ出すのが難しくなる。

アプリケーションの要件に最もよく合う方法を決定する必要があります。以降の各項では,それぞれの選択肢について詳しく説明していきます。

4.1.1    単一ファイル方式の使用

一意の名前のファイルを 1 つ使い,アプリケーションの構成情報を 1 つのクラスタ単位のファイルに保持します。このファイルには,個々のノードのデータが独立したレコードの形で保存されています。アプリケーションでは,このファイル内の正しいレコードを読み書きします。単一ファイルの管理は,すべてのデータが中央に置かれるため簡単です。

たとえば,クラスタ内の /etc/printcap ファイルに,個々のプリンタのエントリを置きます。次のパラメータを指定して,クラスタのどのノードがそのプリンタ・キューのスプーラを実行できるかを示します。

        :on=nodename1,nodename2,nodename3,...:
 

最初のノードが動作している場合は,そのノードがスプーラを実行します。そのノードが停止すると,次のノードが動作していれば,そのノードがスプーラを実行します。

4.1.2    複数ファイル方式の使用

一意な名前のクラスタ単位のファイルのセットによって,構成情報を保持する方法です。たとえば,各クラスタ・メンバは,それぞれのメンバ固有の gated 構成ファイルを /etc に保持します。それぞれのメンバ固有の一意のファイル名は,そのメンバ ID を利用した命名規則によって作成します。メンバ固有のファイルを,コンテキスト依存シンボリック・リンク (CDSL) を使用することにより共通の名前によって参照する方法とは異なります。たとえば,次のようなファイル名になります。

# ls -l /etc/gated.conf.member*
-rw-r--r--   1 root   system    466 Jun 21 17:37 /etc/gated.conf.member1
-rw-r--r--   1 root   system    466 Jun 21 17:37 /etc/gated.conf.member2
-rw-r--r--   1 root   system    466 Jun 21 13:28 /etc/gated.conf.member3
 

この方式では,ファイルの複数のコピーを保守しなければならないため管理に手間がかかります。たとえば,あるクラスタ・メンバのメンバ ID に変更があった場合,そのメンバにかかわるすべてのメンバ固有のファイルを探し出して,名前を変更する必要があります。また,アプリケーションがメンバ固有のファイルのアクセス方法を意識していない場合は,意識するように構成する必要があります。

4.1.3    CDSL の使用

Tru64 UNIX バージョン 5.0 では,コンテキスト依存シンボリック・リンク (CDSL) と呼ぶ,特殊な形式のシンボリック・リンクを採用していました。TruCluster Server では,これを使用して,各メンバの適切なファイルを指し示します。CDSL は,複数のアプリケーション・インスタンスが,複数のクラスタ・メンバ上で,異なるデータのセットに対して動作している場合に便利です。

CDSL を使用する場合,構成情報はメンバ固有の領域に保存されますが,データは,CDSL を通して参照することができます。各メンバは,共通のファイル名のファイルを読みますが,それは透過的に構成ファイルのメンバ固有のコピーにリンクされています。CDSL は,複数ファイル方式を使用するようにアプリケーションを簡単に変更できない場合に,メンバ固有のファイルを保持するために使う選択肢です。

次の例は,/etc/rc.config ファイルの CDSL 構造です。

/etc/rc.config -> ../cluster/members/{memb}/etc/rc.config
 

たとえば,クラスタ・メンバのメンバ ID が 3 の場合,パス名 /cluster/members/{memb}/etc/rc.config は,/cluster/members/member3/etc/rc.config になります。

Tru64 UNIX では mkcdsl コマンドを提供しており,システム管理者はこれを使って,CDSL を作成し,CDSL インベントリ・ファイルを更新することができます。 このコマンドについての詳細は,TruCluster Server の『クラスタ管理ガイド』および mkcdsl(8) を参照してください。CDSL の詳しい作成方法については,Tru64 UNIX の 『システム管理ガイド 』, hier(5)ln(1),および symlink(2) を参照してください。

4.2    デバイスの命名規則

Tru64 UNIX バージョン 5.0 では,新しいデバイス命名規則を採用していました。この命令規則は,デバイスの意味の分かる名前とインスタンス番号からなります。この 2 つの要素が,デバイスのベースネームとなります。この例を,次の表に示します。

/dev の下の場所 デバイス名 インスタンス番号 ベースネーム
./disk dsk 0 dsk0
./disk cdrom 1 cdrom1
./tape tape 0 tape0

ディスクの物理的な接続位置を移動しても,そのディスクのデバイス名は変わりません。したがってシステム管理者は,システム上にデバイスを柔軟に構成できます。詳細は,Tru64 UNIX の『システム管理ガイド』 を参照してください。このデバイス命名規則のモデルの説明があります。

Tru64 UNIX では,古いスタイル (rz) のデバイスと新しいスタイル (dsk) のデバイスの両方のデバイス名を認識しますが,TruCluster Server では,新しいスタイルのデバイス名しか認識しません。古いスタイルのデバイス名に依存するアプリケーションや /dev ディレクトリ構造は,新しい命名規則を使用するように変更する必要があります。

ハードウェア管理用の汎用ユーティリティ hwmgr を使うと,Tru64 UNIX バージョン 5.1B のインストール後に,デバイス名をそれぞれのバス,ターゲット,および LUN 位置にマップすることができます。たとえば,次のようにこのコマンドを実行してデバイスを表示します。

# hwmgr -view devices
 
  HWID: Device Name         Mfg	   Model            Location
  --------------------------------------------------------------------
    45: /dev/disk/floppy0c         3.5in floppy     fdi0-unit-0
    54: /dev/disk/cdrom0c   DEC    RRD47   (C) DEC  bus-0-targ-5-lun-0
    55: /dev/disk/dsk0c     COMPAQ BB00911CA0       bus-1-targ-0-lun-0
    56: /dev/disk/dsk1c     COMPAQ BB00911CA0       bus-1-targ-1-lun-0
    57: /dev/disk/dsk2c     DEC    HSG80            IDENTIFIER=7
    .
    .
    .
 

クラスタ単位のデバイスを参照するには,次のコマンドを使用します。

# hwmgr -view devices -cluster
 
HWID: Device Name        Mfg   Model            Hostname    Location
-----------------------------------------------------------------------
  45: /dev/disk/floppy0c         3.5in floppy    swiss    fdi0-unit-0
  54: /dev/disk/cdrom0c  DEC     RRD47   (C) DEC swiss    bus-0-targ-5-lun-0
  55: /dev/disk/dsk0c    COMPAQ  BB00911CA0      swiss    bus-1-targ-0-lun-0
  56: /dev/disk/dsk1c    COMPAQ  BB00911CA0      swiss    bus-1-targ-1-lun-0
  57: /dev/disk/dsk2c    DEC     HSG80           swiss    IDENTIFIER=7
  .
  .
  .
 

このコマンドの使用方法についての詳細は, hwmgr(8) および 『クラスタ管理ガイド』 を参照してください。

新しいスタイルのデバイス命名規則を使用するようにアプリケーションを変更する際には,次の項目を探してください。

注意

ASE で,SCSI バスの番号をふり直していた場合は,TruCluster Server にアップグレードする際に,物理デバイスとバス番号の対応を注意深く調査する必要があります。詳細は,『クラスタ・インストレーション・ガイド』を参照してください。

4.3    プロセス間通信

クラスタ単位でサポートされているプロセス間通信 (IPC) メカニズムは,次のとおりです。

クラスタ単位でサポートされていない IPC メカニズムは,次のとおりです。

アプリケーションがこれらの IPC 方式のいずれかを使う場合は,シングル・インスタンス・アプリケーションとしての動作に制限されます。

4.4    共用データへの同期アクセス

クラスタ内で実行されている複数のアプリケーション・インスタンスは,お互いに同期をとらなければなりません。これは,マルチプロセス,マルチスレッドのアプリケーションがスタンドアロンのシステム上で同期をとる必要があるのと同じ理由です。しかし,メモリ・ベースの同期メカニズム (クリティカル・セクション,相互排他,単純なロック,および複雑なロックなど) は,ローカル・システムでのみ機能し,クラスタ単位では機能しません。共用ファイルのデータでは,同期アクセスができなければなりません。これができない場合,クラスタ全体でインスタンスの実行の同期をとるために,ファイルを使用しなければなりません。

クラスタ・ファイル・システム (CFS) は完全に POSIX に準拠しているため,アプリケーションは flock() システム・コールを使ってインスタンス間で共用するファイルの同期をとることができます。また,分散ロック・マネージャ (DLM) API ライブラリを使うことで,より高性能なロック機能 (追加のロック・モード,ロック変換,デッドロック検出など) を利用することもできます。DLM API ライブラリは TruCluster Server 製品のみで提供されているため,その関数を使用するコードのうち,非クラスタ・システムでも実行する予定のあるコードは,clu_is_member() への呼び出しを行うすべての DLM 関数の前に置くようにしてください。clu_is_member() 関数は,システムが実際にクラスタ・システムであるかどうかを検証します。このコマンドについての詳細は, clu_is_member(3) を参照してください。DLM API についての詳細は,第 9 章を参照してください。

4.5    メンバ固有のリソース

複数のアプリケーション・インスタンスを複数のクラスタ・メンバで同時に起動した場合,アプリケーションのインスタンスが正しく動作しないことがあります。これは,大規模な CPU 処理能力や大容量物理メモリなど,特定のメンバだけが利用できるリソースに依存する場合があるためです。これによって,アプリケーションはクラスタ内でシングル・インスタンスとしてしか動作できなくなる場合があります。アプリケーションのこのような特性を変更するだけで,クラスタ内でマルチ・インスタンスとして実行できる場合があます。すなわち,複数のメンバにリソースが存在する場合は,これらのメンバ上でアプリケーションを実行するだけです。

4.6    拡張 PID

TruCluster Server では,プロセス識別子 (PID) が完全な 32 ビット値に拡張されました。データ・タイプ PID_MAX は,2147483647 (0x7fffffff) に拡大されました。このため,PID <= PID_MAX という条件判定をしているアプリケーションは,再コンパイルする必要があります。

PID はクラスタ全体で一意の番号です。各クラスタ・メンバの PID は,メンバ ID をベースとしており,そのメンバにとって一意で一定範囲の番号が割り当てられます。クラスタ内で利用できる PID は次の式に従います。

PID = (memberid * (2**19)) + 2
 

通常,最初の 2 つの値は kernel idle プロセスと /sbin/init 用に予約されています。たとえば,PID 524,288 と 524,289 は memberid が 1 のクラスタ・メンバ上にある kernel idle プロセスと init にそれぞれ割り当てられます。

ログ・ファイルと一時ファイルを一意に識別するのにも PID を使います。アプリケーションでファイルに PID を保存する場合は,そのファイルをメンバ固有のファイルとする必要があります。

4.7    削除された DLM パラメータ

分散ロック・マネージャ (DLM) の不変リソース,リソース・グループ,およびトランザクション ID は,TruCluster Available Server,TruCluster Production Server Version 1.6,および TruCluster Server バージョン 5.0 以降では,省略時の設定により有効にされるため,dlm_disable_rd および dlm_disable_grptx 属性は必要でなく,DLM カーネル・サブシステムから削除されました。

4.8    ライセンス

この節では,ライセンスの制約と問題点について説明します。

4.8.1    TruCluster Server のクラスタ単位でのライセンスはサポートされない

TruCluster Server バージョン 5.1B は,クラスタ単位のライセンスをサポートしていません。クラスタにメンバを追加するたびに,そのメンバ上で実行するアプリケーションのすべての必要なライセンスをそのメンバに登録する必要があります。

4.8.2    レイヤード・プロダクトのライセンスとネットワーク・アダプタのフェイルオーバ

NetRAIN (Redundant Array of Independent Network Adapter) および NIFF (Network Interface Failure Finder) は,ネットワーク・フェイルオーバを容易に行うためのメカニズムを提供し,TruCluster Available Server および Production Server 製品で採用されていたネットワーク・インタフェース監視機能はこれに置き換わります。

NetRAIN では,複数アダプタ構成での透過的なネットワーク・アダプタ・フェイルオーバを提供します。NetRAIN は,自身のネットワーク・インタフェースの状態を NIFF を使って監視します。NIFF は,ネットワークの障害を検出して報告します。NIFF を使うことにより,複合 NetRAIN デバイスなどのネットワーク・デバイスに障害が起こったときにイベントを生成することができます。そうしたイベントを監視すれば,障害が起こったときに適切な処置をとることができます。NetRAIN と NIFF についての詳細は,Tru64 UNIX の『ネットワーク管理ガイド:接続編』を参照してください。

クラスタ内では,アプリケーションはフェイルオーバ機構によって他のメンバで再起動することができます。再起動する際にアプリケーションがライセンス・チェックを行う場合,特定のメンバの IP アドレス,またはアダプタのメディア・アクセス制御 (MAC) アドレスをチェックするため,チェックに失敗することがあります。

ネットワーク・アダプタの MAC アドレスを使って,マシンを一意に識別するライセンス機構では,NetRAIN がどのように MAC アドレスを変換するかに左右されます。すべてのネットワーク・ドライバは,MAC アドレスをインタフェースから取り出す SIOCRPHYSADDR ioctl をサポートしています。この ioctl は,次の 2 つのアドレスを配列内に返します。

MAC アドレスに基づくライセンス機構では,SIOCRPHYSADDR ioctl で返される省略時のハードウェア・アドレスを使う必要があります。現在の物理アドレスは,NetRAIN がそのときに応じて変更しているので使用してはなりません。SIOCRPHYSADDR ioctl のサンプル・プログラムが,使用しているネットワーク・アダプタのリファレンス・ページ (たとえば, tu(7)) にあるので参照してください。

4.9    ブロッキング・レイヤード・プロダクト

移行したいアプリケーションがブロッキング・レイヤード・プロダクトかどうか確認してください。ブロッキング・レイヤード・プロダクトは,コマンド installupdate を実行して,TruCluster Server バージョン 5.1B のアップデート・インストレーションを行う際に弊害となる製品です。コマンド installupdate を使用してローリング・アップグレードを開始する前に,ブロッキング・レイヤード・プロダクトをクラスタから削除する必要があります。

レイヤード・プロダクトのドキュメントで,最初にローリングするメンバ上にプロダクトの新バージョンをインストールできること,および複数のバージョンが混在するクラスタ内でレイヤード・プロダクトが動作できることが特記されていない場合は,新しいレイヤード・プロダクトまたは現在インストール済みのレイヤード・プロダクトの新バージョンのどちらもローリング・アップグレード中にインストールしないでください。

TruCluster Server バージョン 5.1B でアップデート・インストレーションを中断することが分かっているレイヤード・プロダクトは,TruCluster Server 『クラスタ・インストレーション・ガイド』 にリストされています。