PRIMECLUSTER Global Disk Services 説明書 4.2 (Linux版）

A.2.26 シャドウボリューム

■ノードの再起動

シャドウボリュームの構成情報は占有スライスに保存されず、メモリ上で管理されます。このため、シャドウボリュームが定義されているノードが再起動されると、シャドウボリュームの構成定義は消滅します。ただし、シャドウボリュームのデバイス特殊ファイルは残ることがあります。デバイス特殊ファイルを残したままにしておくと、後述の問題が発生する恐れがあります。

計画的なシャットダウンを行う場合、事前にシャドウボリュームを削除することを推奨します。sdxshadowvolume -Rコマンドを使用してシャドウボリュームを削除すれば、デバイス特殊ファイルも削除されます。sdxshadowvolume -Rコマンドの詳細については、「sdxshadowvolume － シャドウボリュームの操作」を参照してください。

シャドウボリュームを削除せずにノードをシャットダウンした場合や、シャドウボリュームが定義されているノードがパニックや電源切断などによって突然再起動された場合は、下記の手順でシャドウボリュームのデバイス特殊ファイルを削除してください。

[手順]

1. システムに存在するクラスを確認します。

   以下の例では、RootClass, Class1, Class2 が存在します。

   # sdxinfo -C
   OBJ    NAME      TYPE     SCOPE        SPARE
   ------ --------- -------- ------------ -----
   class  RootClass root     (local)          0
   class  Class1    local    node1            0
   class  Class2    shared   node1:node2      0

   
   

2. クラスのデバイス特殊ファイルのディレクトリを確認します。

   以下の例では、RootClass, Class1, Class2 は存在するクラスのデバイス特殊ファイルのディレクトリであり、_adm, _diag はGDSが使用する特殊ファイルです。残りの Class3 が、消滅したシャドウクラスのデバイス特殊ファイルのディレクトリです。

   # cd /dev/sfdsk
   # ls -F
   Class1/      Class2/      Class3/      RootClass/   _adm@        _diag@

   
   

3. 消滅したシャドウクラスのデバイス特殊ファイルのディレクトリを削除します。
   

   # rm -r Class3

消滅したシャドウボリュームのデバイス特殊ファイルが残っていても、消滅前と同じ構成、同じクラス名、同じボリューム名のシャドウボリュームを作成する場合は問題ありません。

それ以外の場合は、次のような問題があります。消滅したシャドウボリュームのデバイス特殊ファイル/dev/sfdsk/シャドウクラス名/[r]dsk/シャドウボリューム名 が残っている状態で、論理ボリュームやシャドウボリュームを作成すると、作成されたボリュームのマイナ番号が、/dev/sfdsk/シャドウクラス名/[r]dsk/シャドウボリューム名 のマイナ番号と同じになる場合があります。この場合、シャドウボリュームが消滅したことに気付かずに/dev/sfdsk/シャドウクラス名/[r]dsk/シャドウボリューム名 にアクセスすると、新たに作成されたボリュームにアクセスしてしまうため、アプリケーションが誤動作したり、新たに作成されたボリュームのデータが破壊されたりする恐れがあります。

 

■シャドウボリュームへのアクセス

シャドウボリュームの管理と、対応する論理ボリュームの管理は、独立しています。たとえば、一方のボリュームにおいてスライスの状態が変更されても、他方のボリュームのスライス状態は反映されません。このため、シャドウボリュームを使用する場合、以下に述べる運用上の注意事項があります。

◆シャドウボリュームの等価性

あるドメイン（ドメインα）でミラーボリュームとして管理されているディスク領域に対して、別のドメイン(ドメインβ)でシャドウボリュームを作成した場合、ドメインαにおけるミラーボリュームへのアクセスと、ドメインβにおけるシャドウボリュームへのアクセスを同時に行わないでください。同時にアクセスを行った場合、次のような問題があります。

• ドメインαのミラーボリュームを構成するスライスでI/Oエラーが発生した場合、そのスライスはINVALID状態になり、ミラーボリュームから切り離されます。しかし、ドメインβのGDSはこのI/Oエラーを検知しないため、シャドウスライスは、INVALID状態にはならず、シャドウボリュームから切り離されません。このとき、シャドウボリュームの等価性は保証されません。

• 同様に、ドメインβにおいてシャドウスライスでI/Oエラーが発生した場合、ドメインαに対応するミラーボリュームのスライスはINVALID状態にはならず、ミラーボリュームから切り離されません。この場合、ミラーボリュームの等価性は保証されません。なお、シャドウスライスでI/Oエラーが発生した場合、ドメインαでディスクの交換、ミラーボリュームの等価性回復などの対処を実施する必要があります。
  

本注意事項は、ミラーボリュームとシャドウボリュームのディスク領域が一致する場合を対象とします。ミラーボリュームへのアクセスとミラーボリュームの複製（一時切離しスライス、プロキシボリューム、またはディスク装置のコピー機能のコピー先のディスク領域）に対応するシャドウボリュームへのアクセスは、同時に行っても問題ありません。

◆ボリューム用の高速等価性回復機構(JRM)

あるドメイン(ドメインα)でミラーボリュームとして管理されているディスク領域に対して、別のドメイン(ドメインβ)でシャドウボリュームを作成してアクセスする場合、ドメインαのミラーボリュームに対して以下の設定を行ってください。

• シャドウボリュームに対応するミラーボリュームへのアクセスを防止するため、ミラーボリュームを停止する。

• シャドウボリュームに対応するミラーボリュームのボリューム用のJRMを有効(on)にする。

この設定が必要な理由は、以下のとおりです。

ドメインβにおいてシャドウボリュームにアクセスしているときに、ドメインαのノードがパニックし、ドメインαにおいてミラーボリュームの等価性回復処理が行われると、シャドウボリュームおよびミラーボリュームの等価性が保証できなくなります。上記の設定を行うことにより、ドメインαのノードがパニックしても、ドメインαでミラーボリュームの等価性回復処理が実行されることはなくなります。

なお、上記の設定が必要なのは、シャドウボリュームと同じディスク領域に作成されているミラーボリュームです。ミラーボリュームの複製(一時切離しスライス、プロキシボリューム、またはディスク装置のコピー機能のコピー先のディスク領域)に対応してシャドウボリュームを作成した場合、複製元のミラーボリュームに対してこれらの設定を行う必要はありません。

パニック後の等価性回復処理

ボリューム用のJRMが有効(on)で、かつ、そのボリュームへの書込みを行っていない場合、パニック後の等価性回復処理は実行されません。ボリューム用のJRMが無効(off)で、かつ、そのボリュームが起動されている場合、パニック後にはボリューム全体の等価性回復処理が実行されます。

◆スライス用の高速等価性回復機構(JRM)

あるドメイン(ドメインα)においてミラーボリュームからスライスを一時的に切離し、他のドメイン(ドメインβ)のシャドウボリュームからこのボリュームまたはスライスの領域への書込みを行った場合、スライスの再組込みを行う前に、スライス用のJRMを無効(off)に設定しておく必要があります。

スライス用のJRMを有効(on)に設定した場合、以下の問題があります。

スライス用のJRMが有効(on)な場合、スライスの再組込み時には、ボリュームとスライスの差分だけがコピーされます。ボリュームとスライスの差分情報は、ドメインαにおいて、スライス用のJRMによって管理されています。しかし、ドメインαにおけるスライス用のJRMはドメインβからの書込みを認識しないため、ドメインβからの書込みによって生じた差分は、差分情報に反映されません。したがって、ドメインαにおいて、スライス用のJRMを有効(on)にして再組込みを行うと、ドメインβからの書込みによって生じた差分がコピーされず、ボリュームの等価性が保証できなくなります。

◆プロキシ用の高速等価性回復機構(JRM)

あるドメイン(ドメインα)においてマスタボリュームからプロキシボリュームを分離し、他のドメイン(ドメインβ)のシャドウボリュームからこのマスタまたはプロキシの領域への書込みを行った場合、プロキシを再結合する前に、プロキシ用のJRMを無効(off)に設定しておく必要があります。また、プロキシを使用してマスタを復元する前にも、プロキシ用のJRMを無効(off)に設定するようにしてください。

プロキシ用のJRMを有効(on)に設定した場合、以下の問題があります。

プロキシ用のJRMが有効(on)な場合、再結合および復元の際には、マスタとプロキシの差分だけがコピーされます。マスタとプロキシの差分情報は、ドメインαにおいて、プロキシ用のJRMによって管理されています。しかし、ドメインαにおけるプロキシ用のJRMはドメインβからの書込みを認識しないため、ドメインβからの書込みによって生じた差分は、差分情報に反映されません。したがって、ドメインαにおいて、プロキシ用のJRMを有効(on)にして再結合または復元を行うと、ドメインβからの書込みによって生じた差分がコピーされず、マスタとプロキシの等価性が保証できなくなります。

ただし、マスタからプロキシへのコピー処理において、差分コピーによる再同期機能を備えたディスク装置のコピー機能(EC、REC、TimeFinder、SRDF)を使用している場合は、ドメインβからの書込みもこれらのディスク装置のコピー機能が管理している差分情報に反映されます。この場合、再結合の際にプロキシ用のJRMを無効(off)に設定する必要はありません。しかしこの場合でも、復元の際にはプロキシ用のJRMが管理している差分情報をもとに等価性コピーの必要性が判断されるため、復元の際はプロキシ用のJRMを無効(off)に設定する必要があります。安全のため、再結合時にディスク装置のコピー機能を使用する場合でも、再結合の前にプロキシ用のJRMを無効(off)に設定することを推奨します。

差分コピーによる再同期機能を備えたディスク装置のコピー機能

プロキシを再結合する際、差分コピーによる再同期機能を備えたディスク装置のコピー機能(EC、REC、TimeFinder、SRDF)を使用してマスタからプロキシへの等価性回復コピーを行う場合、プロキシ用のJRMが有効(on)か無効(off)かに関わらず、差分コピーによる再同期機能が使用されます。

◆シャドウボリュームへの書込み

シャドウボリュームへの書込みを目的とした操作を行わなくても、書込みが行われる場合があります。たとえば、mount(8) (-o roオプション指定時は除く), fsck(8), mkfs(8)の各コマンドを実行すると、書込みが行われます。

シャドウボリュームを作成した場合、プロキシの再結合、マスタの復元、スライスの再組込みを行う際には、安全のため、シャドウボリュームへの書込みを行ったかどうかに関係なく、高速等価性回復モード(JRM)を無効(off)に設定することを推奨します。