このドキュメントでは、WebLogic Serverインスタンス・ポッドのリブネスおよびレディネス・プローブをカスタマイズする方法について説明します。
ノード・マネージャ・プロセスを問合せして、サーバーが稼働していることを確認するようにリブネス・プローブが構成されています。 デフォルトでは、リブネス・プローブは45秒ごとに、5秒後にタイムアウトし、30秒後に最初のチェックを実行するように構成されています。 成功および失敗のデフォルトのしきい値は1です。 ポッドがリブネス・プローブに失敗すると、Kubernetesはそのコンテナを再起動します。
リブネス・プローブの初期遅延、間隔、タイムアウトおよび失敗しきい値は、ドメインまたはクラスタ・リソースのserverPod要素の下にあるlivenessProbe属性を使用してカスタマイズできます。
次に、リブネス・プローブの間隔、タイムアウト、および失敗のしきい値を変更する構成の例を示します。
serverPod:
livenessProbe:
periodSeconds: 30
timeoutSeconds: 10
failureThreshold: 3
ノート: リブネス・プローブの成功しきい値は、常に1である必要があります。 詳細は、Kubernetesドキュメントの「プローブの構成」に関する項を参照してください。
リブネス・プローブ・スクリプト(livenessProbe.sh)が通常のチェックを実行したあと、livenessProbe.shによって呼び出されるカスタム・スクリプトを指定することによって、リブネス・プローブをカスタマイズできます。 カスタム・スクリプトを指定するには、ドメイン・リソースのlivenessProbeCustomScript属性を使用するか、serverPod要素の下にあるenv属性を使用してLIVENESS_PROBE_CUSTOM_SCRIPT環境変数を設定します(次の構成例を参照)。 カスタム・スクリプト・ゼロ以外の終了ステータスで失敗した場合、リブネス・プローブは失敗し、Kubernetesはコンテナを再起動します。
spec.livenessProbeCustomScriptドメイン・リソース属性は、ドメイン内のすべてのWebLogic Serverインスタンス・ポッドに影響します。LIVENESS_PROBE_CUSTOM_SCRIPT環境変数は、spec.livenessProbeCustomScriptドメイン・リソース属性よりも優先され、すべてのドメイン・リソース環境変数と同様に、ドメインごと、クラスタごと、またはサーバーごとにカスタマイズできます。ノート: リブネス・プローブのカスタム・スクリプト・オプションは、詳細使用のみを目的としており、その値はデフォルトで設定されていません。 指定したスクリプトが見つからない場合、カスタム・スクリプトは無視され、既存のlivenessスクリプトは標準チェックを実行します。
ノート: Oracleでは、リブネス・プローブ・カスタム・スクリプトで長時間実行コール(ネットワーク・コールやwlst.shの実行など)を使用しないことをお薦めします。
次の構成を使用して、livenessProbeCustomScriptドメイン・リソース・フィールドを使用してリブネス・プローブ・カスタム・スクリプトを指定します。
spec:
livenessProbeCustomScript: /u01/customLivenessProbe.sh
次の構成を使用して、LIVENESS_PROBE_CUSTOM_SCRIPT環境変数を使用してリブネス・プローブのカスタム・スクリプトを指定します。
serverPod:
env:
- name: LIVENESS_PROBE_CUSTOM_SCRIPT
value: /u01/customLivenessProbe.sh
livenessProbe.shによって呼び出されるリブネス・プローブ・カスタム・スクリプトでは、次のオペレータによって移入された環境変数を使用できます。
ORACLE_HOMEまたはMW_HOME: コンテナ内のファイル・システム・パスとしてのOracle Fusion Middlewareソフトウェアのロケーション。
WL_HOME: コンテナ内のファイル・システム・パスとしてのWeblogic Serverのインストール・ロケーション。
DOMAIN_HOME: コンテナ内のファイル・システム・パスとしてのドメイン・ホームのロケーション。
JAVA_HOME: コンテナ内のファイル・システム・パスとしてのJavaソフトウェアのインストール・ロケーション。
DOMAIN_NAME: WebLogic Serverドメイン名。
DOMAIN_UID: ドメインの一意の識別子。
SERVER_NAME: WebLogic Serverインスタンス名。
LOG_HOME: コンテナ内のファイル・システム・パスとしてのWebLogicログのロケーション。 この変数は、その値が構成で設定されている場合にのみ使用できます。
NOTES:
一覧表示されていない追加のオペレータ入力環境変数は、リブネス・プローブのカスタム・スクリプトでの使用はサポートされていません。
カスタム・リブネス・プローブ・スクリプトは、そのドメイン内のWebLogicユーティリティにアクセスするためにPATHまたはCLASSPATHを設定する必要がある場合は、source $DOMAIN_HOME/bin/setDomainEnv.shをコールできます。
WebLogic Serverインスタンス自体が使用できないときは、カスタム・リブネス・プローブが失敗(ゼロ以外を終了)しないでください。 これは、WebLogic Serverインスタンスが起動しているとき、またはの場合があります。
WebLogic Serverは、ドメイン内のサーバー・インスタンスの信頼性および可用性を向上させる自己ヘルス・モニタリング機能を提供します。 個々のサブシステムが一貫して確実に動作できなくなると判断した場合、そのヘルス状態はホスト・サーバーにFAILEDとして登録されます。 また、各WebLogic Serverインスタンスは登録されているサブシステムの状態をチェックして、全体的な有効性を判断します。 1つ以上のクリティカル・サブシステムがFAILED状態に達した場合、サーバー・インスタンスは、アプリケーションを確実にホストできないことを示すために、そのヘルス状態をFAILEDとしてマークします。
ノード・マネージャを使用すると、サーバー自己ヘルス・モニタリングによって、失敗が発生したサーバー・インスタンスの自動再起動が可能になります。 オペレータは、失敗が発生したサーバーを1時間間隔で最大2回再起動するようにノード・マネージャを構成します。 これを行うには、RestartMaxプロパティの値(「サーバー起動プロパティ」ファイル内)を2に、RestartIntervalプロパティの値を3600に設定します。 serverPod要素の下にあるenv属性を使用して、ドメイン・リソースにRESTART_MAXおよびRESTART_INTERVAL環境変数を設定することで、ノード・マネージャが特定の間隔でサーバーの再起動を試行する回数を変更できます。
次の構成を使用して、RESTART_MAXおよびRESTART_INTERVAL環境変数を使用して、指定の間隔でノード・マネージャがサーバーの再起動を試行できる回数を指定します。
serverPod:
env:
- name: RESTART_MAX
value: "4"
- name: RESTART_INTERVAL
value: "3600"
ノード・マネージャが失敗の発生したサーバーを再起動できず、サーバーの状態をFAILED_NOT_RESTARTABLEとマークした場合、リブネス・プローブは失敗し、WebLogic Serverコンテナが再起動されます。 RESTART_MAX環境変数値を0に設定すると、ノード・マネージャで失敗が発生したサーバーを再起動できなくなり、リブネス・プローブが即時に失敗することを許可できます。
詳細は、「サーバー起動プロパティ」を参照してください。
レディネス・プローブとそのチューニングをカスタマイズするためのオプションを次に示します:
デフォルトでは、レディネス・プローブはWebLogic Server ReadyAppフレームワークを使用するように構成されます。 ReadyAppフレームワークを使用すると、アプリケーションのフレームワークへの参加によってレディネス・プローブを細かくカスタマイズできます。 詳細は、「ReadyAppフレームワークの使用」を参照してください。 レディネス・プローブは、サーバーがユーザー・リクエストを受け入れる準備ができているかどうかを判断するために使用されます。 レディネスは、サーバーがロード・バランサのエンドポイントに含まれるタイミング、ローリング再起動の場合、再起動されたサーバーが完全に起動された場合、および他の様々な目的で決定するために使用されます。
デフォルトでは、レディネス・プローブは5秒ごとにレディネスをチェックし、5秒後にタイムアウトし、30秒後に最初のチェックを実行するように構成されます。 成功および失敗のデフォルトのしきい値は1です。 ドメイン・リソースのserverPod要素の下のreadinessProbe属性を使用して、レディネス・プローブの初期遅延、間隔、タイムアウト、成功および失敗のしきい値をカスタマイズできます。
次に、レディネス・プローブの間隔、タイムアウト、および失敗のしきい値を変更する構成の例を示します。
serverPod:
readinessProbe:
periodSeconds: 10
timeoutSeconds: 10
failureThreshold: 3
ドメイン・リソース構成を使用すると、オペレータがWebLogic Serverポッドの準備が完了するまで待ってから、ポッドが強制的に再起動されるまでの時間をカスタマイズできます。 デフォルトは30分です。 domain.spec.serverPod (ドメイン内のすべてのポッドに適用される)のmaxReadyWaitTimeSeconds属性、domain.spec.adminServer.serverPod、domain.spec.managedServers[*].serverPodまたはcluster.spec.serverPodを参照してください。