CVM 2.2.1 に関して、次の使用上の問題点が判明しています。
ディスクグループがディスクにアクセスできなくなったことにより、CVM がそのディスクグループをデポートした場合、そのディスク (クラスタ内のノードに依然として接続されている) を再びアクセスできるようにする唯一の方法は、そのディスクグループを強制的にインポートすることです。しかし、この状況で強制インポートを実行すると、ミラーの同期が失われ、どのミラーに正しいデータがあるかを判定できなくなる可能性があります。
物理的に共有されているディスク上に、個人用 (非共有) のディスクグループを配置することは可能です。ただし、これらのディスクが障害防止用に指定された (たとえば、Sun Cluster によって予約された) コントローラ上に存在する場合、個人用ディスクグループの所有者は、そのコントローラがクラスタに結合されていない場合はディスクグループにアクセスできません。
CVM は現在 RAID5 ボリュームをサポートしていません。
共有ディスクグループでは gen ボリュームタイプだけがサポートされています。fsgen ボリュームを使用するとシステムデッドロックの原因となる可能性があります。
クリーンシャットダウンまたは異常終了が原因で一方のノードがクラスタを切り離した場合、残ったノードはクラスタの再構成を実行します。この再構成が完了しないうちに、切り離したノードがクラスタに再び結合しようとした場合、その結果は切り離したノードがスレーブまたはマスターのどちらであるかによって異なります。
切り離したノードがスレーブの場合は、再結合は失敗し、次のいずれかのエラーメッセージが表示されます。
Resource temporarily unavailable [vxclust] return from cluster_establish is configuration daemon error -1 Resource temporarily unavailable master has disconnected |
後で再試行すれば、正常に結合できます。
切り離したノードがマスターの場合は、両方のノードでディスク関連のエラーメッセージが表示され、もう一方のノードが異常終了します。結合中のノードは最終的にクラスタに結合し、マスターになります。
マスターおよびスレーブノードの両方で vxconfigd が停止し、先にスレーブで再起動した場合、vxconfigd がマスターで起動されスレーブが再接続するまで (約 30 秒かかる場合がある)、vxconfigd が表示する情報は正しくありません。特に、共有ディスクグループは「disabled」と表示され、それらに関する情報はまったく提供されません。したがって、先にマスターで vxconfigd を起動する必要があります。
クラスタからノードが異常終了した場合、I/O がアクティブでない共有ディスクグループ上のオープン状態のボリュームデバイスは、それらのボリュームが閉じられるまで除去されません。これらのボリュームが引き続きオープンのとき、このノードがマスターとしてクラスタに結合する場合、これらのボリュームの存在によって特に問題になることはありません。ただし、ノードがスレーブとしてクラスタに再結合しようとすると失敗し、次のエラーメッセージが表示されます。
cannot assign minor # |
同時に、次のコンソールメッセージも表示されます。
WARNING:minor number ### disk group group in use |
現在のディスクのホットスペア機構は、ディスクの「部分的な」故障時にはうまく動作しません。この機能は、ディスクは部分的ではなく全体的に故障し、部分的なエラーは障害が発生したセクターを書き直すことによって修正できるという前提に基づいて作成されているからです。通常はこの前提で問題ありませんが、いくつかのセクターだけで障害が発生しホットスペアが作用しなかった事例が報告されています。
vxconfigd が停止し再起動されたとき、それによって大きなディスクグループ (たとえば数百のボリュームを含むディスクグループ) が使用不可になる場合があります。
回避策: vxconfigd を cleartempdir オプション付きで再起動します。必要ならディスクグループをデポートし、再度インポートしてからすべてのボリュームを起動してください。
ある種の状況では、ノードの異常終了が障害を引き起こす可能性があります。このような状況はほとんど発生しませんが、入出力を適切なときに停止できず、データの整合性を保証するためノードを停止させる必要がある場合に、発生する可能性があります。