![]() ![]() ![]() ![]() |
サーバー・テンプレート: 構成: 移行
クラスタ・サーバーで障害が発生したときに、WebLogic Serverによってサーバーとそのサービスを自動的に別のマシンで再起動(別のマシンに移行)できます。または、このサーバーのJMS関連サービス(JMSサーバー、SAFエージェント、パス・サービス、カスタム永続ストアなど)とJTAトランザクション・リカバリ・サービスを手動で別のサーバーに移行できるように、これらのサービスのオプションを構成できます。また、JTAトランザクション回復サービスが自動的に別のサーバーに移行されるように指定することもできます。
このページでは、サーバーの移行の有効化、またはサービスのみの移行の構成を行います。
構成オプション
名前 説明 サーバーの自動移行を有効化 サーバーで障害が発生した場合に、ノード・マネージャが自動的に別マシンでこのサーバーおよびサービスを再起動できるかどうかを指定します。
MBean属性:
ServerMBean.AutoMigrationEnabled
構成オプション
名前 説明 JTA移行ポリシー この移行可能なターゲットでホストされるサービスに対して使用する移行ポリシーのタイプを定義します。有効なオプションは次のとおりです。
サービスの手動での移行のみ
この移行可能なターゲットでホストされるサービスの自動移行は行われないことを示します。
Auto-Migrate Exactly-Once Services
候補サーバーのリストにある管理ターゲット・サーバーが1つ以上動作しているかどうかを示します。この移行可能ターゲットでホストされるサービスは、サーバーが失敗するか管理者によって(正常または強制的に)シャットダウンされた場合に、クラスタ内のいずれかの場所でアクティブ化されます。たとえば、推奨のベストプラクティスは、移行可能ターゲットにパス・サービスがホストされている場合にこのポリシーを使用することです。そのようにすると、対応する優先サーバーが失敗したりシャットダウンされたりした場合に、パス・サービスが自動的に別の候補サーバーに移行し、クラスタ内で常にアクティブな状態となります。
ノート:
この値を指定すると、ターゲットが1つのサーバー・メンバーにグループ化される場合があります。たとえば、必ず1回の指定された移行可能ターゲットが5つあり、クラスタ内で管理ターゲット・サーバーが1つのみ起動されている場合、5つのターゲットすべてがそのサーバー上でアクティブ化されます。
このポリシーはJTAサービスの移行には適用されません。Auto-Migrate Failure-Recovery Services
この移行可能ターゲットのユーザー優先サーバー(User Preferred Server: UPS)が起動している場合にのみ、移行可能ターゲットでホストされているサービスが起動することを示します。管理者が手動でUPSを正常または強制的にシャットダウンした場合、障害回復サービスは移行しません。ただし、内部エラーによってUPSが失敗した場合、サービスは別の候補サーバーに移行されます。そのような候補サーバーが(手動シャットダウンまたは内部障害のために)使用できない状態の場合、移行フレームワークではまずサービスをそのUPSサーバー上で再アクティブ化しようとします。その時点でUPSサーバーが利用できない場合、そのサービスは別の候補サーバーに移行されます。
Auto-Migrate Shutdown-Recovery Services
サーバーが管理上(正常にまたは強制的に)停止された場合に、この移行可能ターゲットでホストされているサービスが候補サーバーのいずれかに移行されることを示します。リカバリが実行されると、サービスは障害が発生したサーバーに戻されます。
厳密な所有権チェックを有効化 フェイルバックを行うTRSの現在のオーナーが見つからない場合、起動を続行するかどうか。この属性はクラスタ内のサーバーにとってのみ意味があります。
trueの場合、この状況においてサーバーの起動は失敗します。
falseの場合、サーバーはフェイルバックを試行しないで、起動を続行します。
![]() |