クラスタ化されたサーバー・プール内の複数のOracle VM Serverが同時にオフラインになっている場合、そのうち1つのサーバーがサーバー・プールから削除されると、他のオフライン・サーバーがオンラインに戻っても、クラスタは障害が発生した状態のままになります。 これは、クラスタのメンバー間でクラスタ構成が同期しなくなるためです。

サーバーがクラスタに追加されたり、クラスタから削除されるたびに、Oracle VM Managerはクラスタ内の各Oracle VM Server上で、クラスタ構成情報を更新するための操作をトリガーします。 ただし、いずれかのサーバーがこの時点でオフラインになっていると、そのサーバーは更新された構成を受信できないため、サーバー上のクラスタ構成とクラスタの残りの実際の構成との間に構成の不一致が生じます。 その結果、サーバーはクラスタに参加できなくなります。

x86プラットフォームでは、この状況はOracle VM Manager内で発生するのみで、Oracle VM Manager内から簡単に解決できます。 SPARCプラットフォームでは、サーバーがオンラインに戻ったときにクラスタ・パニックが原因でサーバーが何度も再起動されることがあります。

回避策(SPARC): SPARCサーバーが継続的に再起動されている場合、クラスタのメンバーでなくなったサーバーがクラスタに再参加しようとすることで問題が発生します。 その結果、サーバーでは、次のようなメッセージとともに繰り返しパニックが発生することがあります。

panic[cpu5]/thread=2a102a13c60: 
 **** dlm FENCING this system by PANICing

この問題が発生し、サーバーのパニックが繰り返し発生する場合、ovs-agentサービスを停止して、クラスタの構成を解除することにより、サーバーのパニックの再発生を回避できます。 これを行うためには、ルートとしてサーバーに接続し、次のコマンドを実行します。

# svcadm disable -s ovs-agent
# dlmcconf -S

サーバーのパニックがすぐに発生するためにこれらのコマンドを実行できない場合は、シングル・ユーザー・モードでサーバーを起動します。

ok boot -s

ovs-agentサービスを無効にします。

# svcadm disable ovs-agent

サーバーを再起動します。 ovs-agentサービスが無効になっている間は、サーバーのパニックは停止します。 ovs-agentサービスを再有効化する場合は、まずクラスタ構成問題を解決する必要があります。

クラスタ構成問題を解決した後は、Oracle VM Manager内のサーバー・クラスタ障害イベントを確認して、通常の操作を再開できます。

回避策(x86): 環境を通常の操作にリストアするために、まず、Oracle VM Manager内のサーバー・クラスタ障害イベントを確認する必要があります。 構成変更を行ったときにオフラインになっていたサーバーをサーバー・プールから削除した後、そのサーバーのクラスタ構成情報が適切にリフレッシュされるように、そのサーバーをサーバー・プールに戻します。

Oracle Bug#22304185、Oracle Bug#18776654