クラスタシステムに関する異常について、以下に該当する場合は、それぞれに記載されている対処を行ってください。
(1) "ERROR: class: cannot operate in cluster environment, ..." というエラーメッセージが出力され、クラス class が操作できない。
説明
クラスタ制御が起動していないときに作成されたローカルクラスを、そのままクラスタシステムで使用することはできません。クラスタ制御が起動されると、以下のエラーメッセージがシステムログおよび GDS デーモンのログファイルに出力され、そのローカルクラスは操作できなくなります。
ERROR: class: cannot operate in cluster environment, created when cluster control facility not ready
このエラーメッセージが出力されるのは、以下のいずれかの場合です。
クラスタ初期構成設定が完了していないノードで、ローカルクラス class を作成した後に、クラスタ初期構成設定を実行した。
シングルユーザモードでローカルクラス class を作成した。
ローカルクラス class が作成されているシングルノードをクラスタシステムに移行した。
対処
以下の方法 a) または方法 b) のいずれかの方法で、ローカルクラスをクラスタシステムで使用できるようにしてください。通常は方法 a) で行いますが、ボリュームデータのバックアップ/リストアを避けたい場合には、方法 b) で行ってください。
方法 a) ローカルクラスをクラスタシステムで再作成する方法:
1) ノードをシングルユーザモードで起動します。
2) 必要に応じて、ボリュームのデータをバックアップします。
3) クラスを削除します。
4) ノードをマルチユーザモードに移行して、クラスタ制御を再起動します。
5) 手順 3) で削除したクラスやボリュームを再作成します。
6) 必要に応じて、手順 2) でバックアップしたボリュームのデータをリストアします。
方法 b) ローカルクラスをクラスタシステム用に変換する方法:
以下の手順で、ローカルクラスをクラスタシステム用に変換してください。以下では、クラス名が Class1 である場合の例を示します。
注意
クラスタ制御が起動しているときに作成されたクラスは、一度、削除して再作成する必要があります。
1) 各ノードで変換するクラスと再作成するクラスを確認します。
# sdxinfo -C
OBJ NAME TYPE SCOPE SPARE
------ ------- -------- ----------- -----
class Class1 local (local) 0
class Class2 local Node1 0
class Class3 shared Node1:Node2 0 |
変換が必要なクラス
TYPE フィールドに local、かつ、SCOPE フィールドに (local) と表示されているクラス。
上記の例では、Class1 が該当します。
再作成が必要なクラス
SCOPE フィールドにクラススコープ (ノード識別名) が正しく表示されているクラス。
上記の例では、Class2、Class3 が該当します。
2) 必要に応じて、再作成するクラスのボリュームのデータをバックアップします。
3) 再作成するクラスを削除します。
4) 変換するローカルクラス Class1 が存在するノードを、シングルユーザモードで起動します。
ok boot -s |
5) ローカルクラス Class1 が存在するノードで、GDS の管理デーモン sdxservd を停止します。
# /etc/opt/FJSVsdx/bin/sdx_stop -S |
以下の方法で、sdxservd デーモンが停止したこと (sdxservd デーモンのプロセスに関する情報が表示されないこと) を確認します。
# ps -e | grep sdxservd
# |
6) ローカルクラス Class1 が存在するノードで、Class1 の構成データベースを退避します。
# rm -rf /var/opt/FJSVsdx/backup/DB/Class1 # /etc/opt/FJSVsdx/bin/sdxcltrandb -B -c Class1 # cd /var/opt/FJSVsdx/backup/DB/Class1 # ls -l |
注意
/var/opt/FJSVsdx/backup/DB 配下に 150[MB] 以上の空き領域があるか確認し、不足している場合は拡張してください。
エラーが発生した場合、以降の手順に進まずに、以下を実施してください。
方法 a) に従って、ローカルクラス Class1 を再作成した後、手順 3) で削除したクラスを再作成し、データをリストアしてください。
7) ローカルクラス Class1 が存在するノードで、Class1 の構成データベースをクラスタシステム用に変換します。
# /etc/opt/FJSVsdx/bin/sdxcltrandb -C -c Class1 |
注意
エラーが発生した場合、10-3) 以降の手順を実施して構成データベースを復元した後、方法 a) に従って、ローカルクラス Class1 を再作成してください。その後、手順 3) で削除したクラスを再作成し、データをリストアしてください。
8) ローカルクラス Class1 が存在するノードをマルチユーザモードにすることにより、クラスタ制御を再起動します。
# init 0 |
注意
シャットダウン中に以下のメッセージが表示されますが、問題はありません。
SDX:sdxshutdown: INFO: waiting for a response from sdxservd daemon... SDX:sdxshutdown: ERROR: connection timeout |
9) ローカルクラス Class1 が存在するノードで、Class1 の構成データベースが正しく変換できたことを確認します。
# sdxinfo -C -c Class1 |
SCOPE フィールドにノード識別名が正しく表示されることを確認します。正しく表示されていれば、変換完了です。
注意
SCOPE フィールドの表示が正しくない場合、Class1 の構成データベースは正しく変換できていません。その場合は、10-1) 以降の手順を実施して構成データベースを復元した後、方法 a) に従ってローカルクラス Class1 を再作成してください。その後、手順 3) で削除したクラスを再作成し、データをリストアしてください。
10) 手順 7) または手順 9) でエラーが発生した場合、手順 6) で退避した構成データベースを復元します。
以下の手順を、ローカルクラス Class1 が存在するノードで実行します。
10-1) ノードをシングルユーザモードで起動します。
ok boot -s |
10-2) GDS の管理デーモン sdxservd を停止します。
# /etc/opt/FJSVsdx/bin/sdx_stop -S |
以下の方法で、sdxservd デーモンが停止したこと (sdxservd デーモンのプロセスに関する情報が表示されないこと) を確認します。
# ps -e | grep sdxservd
# |
10-3) ローカルクラス Class1 の構成データベースを復元します。
# /etc/opt/FJSVsdx/bin/sdxcltrandb -R -c Class1 |
10-4) ノードをシングルユーザモードで再起動します。
# init 0 |
注意
シャットダウン中に以下のメッセージが表示されますが、問題はありません。
SDX:sdxshutdown: INFO: waiting for a response from sdxservd daemon... SDX:sdxshutdown: ERROR: connection timeout |
10-5) ローカルクラス Class1 の構成データベースが正しく復元できたことを確認します。
# sdxinfo -C -c Class1 |
SCOPE フィールドにノード識別名が正しく表示されることを確認します。正しく表示されていれば、復元は完了です。
11) ローカルクラスの変換が完了した後、手順 3) で削除したクラスを再作成します。
その後、必要に応じて、手順 2) でバックアップしたボリュームのデータをリストアします。
(2) PRIMECLUSTER CF の clinitreset(1M) コマンドが 6675 番のエラーメッセージを出力して異常終了する。
説明
クラスタシステムにおいてクラスが存在する場合、PRIMECLUSTER CF の clinitreset コマンドを実行して PRIMECLUSTER のリソースデータベースを初期化しようとすると、clinitreset コマンドは以下のエラーメッセージを出力して異常終了します。
FJSVcluster: エラー： clinitreset: 6675: Cannot run thie command because Global Disk Services has already been set up.
シャドウクラスが存在するノードが、シャットダウンやパニックなどによって再起動されると、シャドウクラスは削除されますが、/dev/sfdsk/クラス名 ディレクトリは削除されません。この状態で clinitreset コマンドを実行した場合にも、clinitreset コマンドは上記のエラーメッセージを出力して異常終了します。
対処
クラスタシステムのすべてのノードにおいて、オブジェクトの構成を確認し、クラスが存在する場合は削除します。クラスを削除すると、ボリュームのデータは失われます。必要に応じて、あらかじめボリュームのデータをバックアップしてください。
参照
GDS 運用管理ビューを使用する場合、「5.5 削除」を参照してください。
コマンドを使用する場合、「付録D コマンドリファレンス」を参照してください。
クラスタシステムのすべてのノードにおいて、/dev/sfdsk ディレクトリにクラスのディレクトリが存在するかどうか確認し、存在する場合は削除します。以下に、クラス Class1 のディレクトリが存在する場合の例を示します。
_adm と _diag は、GDS が使用する特殊ファイルなので、削除しないでください。
# cd /dev/sfdsk # rm -rf Class1 |
(3) クラスタアプリケーションが Inconsistent 状態になる。
説明
共用クラスが RMS リソースとして使用しない設定になっている場合、そのクラスに含まれるボリュームは、ノード起動時に起動されます。そのため、そのボリュームを使用するクラスタアプリケーションを起動すると、すでにボリュームが起動された状態であるため、クラスタアプリケーションは Inconsistent 状態になります。デフォルトでは、クラスは RMS リソースとして使用しない設定になっており、以下のいずれかの操作を行うことで、RMS リソースとして使用する設定にすることができます。
Web-Based Admin View の userApplication Configuration Wizard で、クラスをクラスタアプリケーションで使用するリソースに登録
クラスを指定して hvgdsetup -a コマンドを実行
対処
以下のいずれかの方法で、共用クラスを RMS リソースとして使用する設定に変更してください。その後、クラスタアプリケーションを再起動してください。
クラスがクラスタアプリケーションで使用するリソースに登録されていない場合は、userApplication Configuration Wizard で登録してください。
クラスがクラスタアプリケーションで使用するリソースに登録されている場合は、以下のコマンドを実行してください。
# /opt/SMAW/SMAWRrms/bin/hvgdsetup -a クラス名 ～ |
(4) GFS 共用ファイルシステムが、ノード起動時にマウントされない。
説明
共用クラスが RMS リソースとして使用する設定になっている場合、そのクラスに属しているボリュームは、ノード起動時に起動されません。そのため、そのボリューム上の共用ファイルシステムは、ノード起動時にマウントされません。デフォルトでは、クラスは RMS リソースとして使用しない設定になっていますが、以下のいずれかの操作を行うと、RMS リソースとして使用する設定になります。
Web-Based Admin View の userApplication Configuration Wizard で、クラスをクラスタアプリケーションで使用するリソースに登録
クラスを指定して hvgdsetup -a コマンドを実行
対処
以下のいずれかの対処を行ってください。
a) 共用クラスを RMS リソースとして使用する場合は、そのクラスのボリュームに共用ファイルシステムを作成することはできません。別のクラスのボリュームに共用ファイルシステムを作成してください。
b) 共用クラスを RMS リソースとして使用しない場合は、以下のいずれかの方法で、クラスを RMS リソースとして使用しない設定に戻してください。その後、システムを再起動してください。
クラスがクラスタアプリケーションで使用するリソースに登録されている場合は、userApplication Configuration Wizard で削除してください。
クラスがクラスタアプリケーションで使用するリソースに登録されていない場合は、以下のコマンドを実行してください。
# /opt/SMAW/SMAWRrms/bin/hvgdsetup -d クラス名 ～ |
(5) 共用ディスク上のファイルシステムの使用率が 100% である。
説明
共用クラスのボリュームに作成された切替ファイルシステムの使用率が 100% になることがあります。
対処
復旧手順を以下に示します。
1.ボリュームの状態確認
復旧作業をしないノードで、復旧対象のファイルシステムが存在するボリュームが停止していることを確認します。
復旧作業をしないノードで、以下のコマンドを実行します。
# sdxinfo -V -c class |
例) クラス名「c0」、ボリューム名「v0」の場合
# sdxinfo -V -c c0
OBJ NAME CLASS GROUP SKIP JRM 1STBLK LASTBLK BLOCKS STATUS
------ ------- ------- ------- ---- --- -------- -------- -------- --------
...
volume v0 c0 g0 off on 131072 163839 32768 STOP
... |
NAME が「v0」である行の STATUS がSTOPであることを確認します。
2.ボリュームの起動
復旧作業をするノードで、以下のコマンドを実行します。
# sdxvolume -N -c class -v volume |
例) クラス名「c0」、ボリューム名「v0」の場合
# sdxvolume -N -c c0 -v v0 |
3. ファイルシステムのマウント
復旧作業をするノードで、復旧対象のファイルシステムをマウントします。
例）クラス名「c0」、ボリューム名「v0」、ファイルシステムタイプ「ufs」、マウントポイント「/mnt」の場合
# mount -F ufs /dev/sfdsk/c0/dsk/v0 /mnt |
4. 不要ファイルの削除
復旧作業をするノードで、手順3.のマウントポイント配下の不要なファイルを削除します。
5. ファイルシステムのアンマウント
復旧作業をするノードで、復旧対象のファイルシステムをアンマウントします。
例) マウントポイント「/mnt」の場合
# umount /mnt |
6.ボリュームの停止
復旧作業をするノードで、以下のコマンドを実行します。
# sdxvolume -F -c class -v volume |
例）クラス名「c0」、ボリューム名「v0」の場合
# sdxvolume -F -c c0 -v v0 |
7. クラスタアプリケーションの Faulted 状態のクリア
クラスタを構成する全ノードで、以下のコマンドを実行します。
# hvutil -c userApplication_name |
例）クラスタアプリケーション名「app1」の場合
# hvutil -c app1 |
8. クラスタアプリケーションの起動
運用系ノードで、以下のコマンドを実行します。
# hvswitch userApplication_name SysNode |
例）node1 のクラスタアプリケーション「app1」を起動する場合
# hvswitch app1 node1RMS |
参照
hvutil コマンドおよび hvswitch コマンドについては、「PRIMECLUSTER 活用ガイド ＜コマンドリファレンス編＞」を参照してください。
