このドキュメントでは、Kubernetes環境でWebLogic Serverインスタンスを停止、起動、ローリングおよび再起動する方法を説明します。
ドメインとクラスタには、どのサーバーを実行するか、どのサーバーを再起動するか、必要な初期状態を指定するフィールドがあります。 サーバーを起動、停止または再起動するには、ドメインまたはクラスタでこれらのフィールドを変更します(たとえば、kubectlまたはKubernetes REST APIを使用)。 オペレータは変更を検出して適用します。
ドメインおよびクラスタのserverStartPolicyおよびreplicasフィールドは、どのサーバーを実行するかを制御します。この場合、クラスタのreplicasフィールドは、対応するドメイン値にデフォルト設定されます。 オペレータは、これらのフィールドを監視し、対応するWebLogic Serverインスタンス・ポッドを作成または削除します。
WebLogic Server管理コンソールを使用してサーバーを起動または停止しないでください。
serverStartPolicyルールserverStartPolicyプロパティは、domain.specドメイン・レベル、cluster.specクラスタ・レベル、domain.spec.managedServers管理対象サーバー・レベルまたはdomain.spec.adminServer管理サーバー・レベルで指定できます。 各レベルでは、異なる値セットがサポートされます。
serverStartPolicy値| レベル | デフォルト値 | サポートされる値 |
|---|---|---|
| ドメイン | IfNeeded |
IfNeeded, AdminOnly, Never |
| クラスタ | IfNeeded |
IfNeeded, Never |
| サーバー | IfNeeded |
IfNeeded, Always, Never |
| ドメイン | 管理サーバー | 開始 / 停止 |
|---|---|---|
Never |
任意の値 | 停止中 |
AdminOnly, IfNeeded |
Never |
停止中 |
AdminOnly, IfNeeded |
IfNeeded, Always |
起動済 |
| ドメイン | スタンドアロン・サーバー | 開始 / 停止 |
|---|---|---|
AdminOnly, Never |
任意の値 | 停止中 |
IfNeeded |
Never |
停止中 |
IfNeeded |
IfNeeded, Always |
起動済 |
| ドメイン | クラスタ | クラスタ化サーバー | 開始 / 停止 |
|---|---|---|---|
AdminOnly, Never |
任意の値 | 任意の値 | 停止中 |
IfNeeded |
Never |
任意の値 | 停止中 |
IfNeeded |
IfNeeded |
Never |
停止中 |
IfNeeded |
IfNeeded |
Always |
起動済 |
IfNeeded |
IfNeeded |
IfNeeded |
必要に応じて起動し、クラスタのreplicas数を取得 |
Alwaysとして構成されたサーバーは、クラスタのreplicas数にカウントされます。
クラスタのreplicas数より多くのサーバーがAlwaysとして構成されている場合、それらはすべて起動され、replicas数を超えます。
通常、管理サーバー、すべてのスタンドアロン管理対象サーバー、および各クラスタ内の十分な数の管理対象サーバー・メンバーが、そのreplicas数を満たすように起動する必要があります。 この場合、ドメインはserverStartPolicyを指定したり、clustersまたはserversをリストする必要はありませんが、replicasカウントを指定する必要があります。
例えば:
kind: Domain
metadata:
name: domain1
spec:
image: ...
replicas: 3
domain.spec.replicasフィールドは、すべてのクラスタのデフォルトです。 個々のクラスタは、cluster.spec.replicasを使用してレプリカをカスタマイズできます。
ドメインを完全に停止する必要がある場合があります(たとえば、サービスを停止します)。
kind: Domain
metadata:
name: domain1
spec:
serverStartPolicy: Never
...
場合によっては、管理サーバーのみを起動する必要があります。つまり、ドメインを管理できるように、管理対象サーバーのサービスを停止し、管理サーバーは実行したままにしておきます。
kind: Domain
metadata:
name: domain1
spec:
serverStartPolicy: AdminOnly
...
クラスタを停止するには(たとえば、サービスを停止するには)、クラスタをドメインに追加し、そのserverStartPolicyをNeverに設定します。
kind: Cluster
metadata:
name: domain1-cluster1
spec:
clusterName: "cluster1"
serverStartPolicy: Never
...
クラスタ・リソースは、domain.spec.clustersから参照される必要があり、ドメインのWebLogic構成の対応するクラスタと一致する.spec.clusterNameが必要です。
特定のスタンドアロン・サーバーを停止するには、そのサーバーをドメインに追加し、そのserverStartPolicyをNeverに設定します。
kind: Domain
metadata:
name: domain1
spec:
managedServers:
- serverName: "server1"
serverStartPolicy: Never
...
管理サーバーを停止するには、adminServerのserverStartPolicyをNeverに設定します。 管理サーバーを停止するときは注意が必要です。 起動時に管理対象サーバーに接続できない場合は、「管理対象サーバー独立(MSI)モード」で起動を試みますが、管理対象サーバーのポッドからアクセスできない「認証プロバイダ」などの理由で失敗する可能性があります。
通常、クラスタ内のすべての管理対象サーバー・メンバーは同一であり、オペレータがクラスタのreplicas数を取得するために十分な数のメンバーを起動しているかぎり、どの管理対象サーバー・メンバーが実行されているかは問題になりません。 ただし、一部の管理対象サーバーは異なる場合があり(たとえば、クラスタ内の他のサーバーが使用する一部の追加サービスをサポートしている場合)、常に起動する必要があります。
これを行うには、サーバーをドメインに追加し、そのserverStartPolicyをAlwaysに設定します。
kind: Domain
metadata:
name: domain1
spec:
managedServers:
- serverName: "cluster1_server1"
serverStartPolicy: Always
...
サーバーはクラスタのreplicasカウントにカウントされます。 また、Alwaysに対してreplicasサーバー数を超える数を構成すると、replicas数を超えてもすべてのサーバーが起動されます。
ドメインおよびクラスタのYAMLファイルには、domain.spec、domain.adminServer、domain.spec.managedServersの各エントリおよびcluster.specで使用可能なフィールドserverPodが含まれます。 serverPodフィールドは、WebLogic Serverインスタンスに対してポッドが生成される方法の多くの詳細を制御します。
serverPodのshutdownフィールドは、管理対象サーバーの停止方法を制御し、次の4つのプロパティを持ちます: shutdownType, timeoutSeconds, ignoreSessionsおよびwaitForAllSessions。 オペレータのランタイムはこれらのプロパティをモニターしますが、停止オプションを調整するためにのみサーバーポッドを再起動しません。 かわりに、別のプロパティ変更のために作成または再起動されたサーバーポッドは、WebLogic Serverインスタンス・ポッドの作成時に設定された停止オプションを使用して適切なタイミングで停止するように構成されます。
| フィールド | デフォルト値 | サポートされる値 | 説明 |
|---|---|---|---|
shutdownType |
Graceful |
GracefulまたはForced |
オペレータがサーバー・インスタンスを停止する方法を指定します。 |
timeoutSeconds |
30 | 0はタイムアウトを意味しない整数(秒)。 | 正常な停止の場合のみ、処理中の作業を中止してサーバーを停止する前に待機する秒数。 |
ignoreSessions |
false |
trueまたはfalse |
アクティブなセッションを無視するかどうかを示すブール値。停止が正常な場合にのみ適用されます。 |
waitForAllSessions |
false |
trueまたはfalse |
正常な停止の場合のみ、進行中の作業処理中にすべてのHTTPセッションを待機するようにtrueに設定します。falseは、進行中の作業処理中にのみ非永続HTTPセッションを待機するように設定します。 |
ignoreSessionsプロパティがtrueの場合、waitForAllSessionsプロパティは適用されません。 ignoreSessionsプロパティがfalseの場合、WebLogicの正常な停止プロセス中にwaitForAllSessionsプロパティが考慮されます。 waitForAllSessionsがtrueの場合、正常な停止プロセスは、すべてのHTTPセッションが完了するか無効になるまで待機してから続行します。 waitForAllSessionsがfalseの場合、正常な停止プロセスは、続行する前に、非永続HTTPセッションが完了または無効化するまで待機します。
オペレータは、次の環境変数を使用して停止動作を構成します。 かわりに、これらの環境変数を直接構成することもできます。 ユーザーが構成した環境変数が存在する場合、オペレータは停止構成に基づいて環境変数をオーバーライドしません。
| 環境変数 | デフォルト値 | サポートされる値 |
|---|---|---|
SHUTDOWN_TYPE |
Graceful |
GracefulまたはForced |
SHUTDOWN_TIMEOUT |
30 | 整数(秒)。0はタイムアウトがないことを意味 |
SHUTDOWN_IGNORE_SESSIONS |
false |
アクティブ・セッションを無視するかどうかを示すブール値。停止が正常な場合にのみ適用されます |
SHUTDOWN_WAIT_FOR_ALL_SESSIONS |
false |
処理中の作業処理中にすべてのHTTPセッションを待機する場合はtrue、非永続HTTPセッションのみ待機する場合はfalse。停止が正常の場合にのみ適用可能 |
shutdownルールshutdownフィールドを含むserverPodフィールドは、ドメイン、クラスタおよびサーバー・レベルで指定できます。 shutdownがクラスタやそのクラスタの一部であるメンバー・サーバーなどの複数のレベルで指定されている場合、特定のサーバーの停止構成は、関連するすべての値と、最も具体的なスコープのshutdownフィールドの値を持つ各フィールドの組合せになります。
たとえば、次のドメインYAMLおよびクラスタYAMLファイルがあるとします:
kind: Domain
metadata:
name: domain1
spec:
serverPod:
shutdown:
shutdownType: Graceful
timeoutSeconds: 45
clusters:
- name: "domain1-cluster1"
managedServers:
- serverName: "cluster1_server1"
serverPod:
shutdown:
timeoutSeconds: 60
ignoreSessions: false
...
kind: Cluster
metadata:
name: domain1-cluster1
labels:
weblogic.domainUID: sample-domain1
spec:
clusterName: cluster1
replicas: 2
serverPod:
shutdown:
ignoreSessions: true
正常な停止は、ドメイン内のすべてのサーバーで使用されます。これは、これがドメイン・レベルで指定され、どのクラスタ・レベルまたはサーバー・レベルでもオーバーライドされないためです。 「cluster1」クラスタはデフォルトでセッションを無視しますが、「cluster1_server1」サーバー・インスタンスはセッションを無視しないため、タイムアウトが長くなります。
ポッド生成に影響するドメインのフィールド(image、volumes、envなど)が変更されると、オペレータはWebLogic Serverインスタンス・ポッドを自動的に再作成(再起動)します。 ドメインのrestartVersionフィールドでは、オペレータに一連のWebLogic Serverインスタンス・ポッドの再起動を強制できます。
オペレータは、サービスが維持されるように、クラスタ化されたサーバーのローリング再起動を行います。
WebLogic Serverインスタンスのポッド生成に影響するドメインの次のいずれかのフィールドが変更されると、オペレータはサーバーを再起動します:
auxiliaryImagesauxiliaryImageVolumescontainerSecurityContextdomainHomedomainHomeSourceTypeenvimageimagePullPolicyimagePullSecretsincludeServerOutInPodLoglogHomeEnabledlogHomelivenessProbenodeSelectorpodSecurityContextreadinessProberesourcesrestartVersionstartupProbevolumesvolumeMountsModel in Imageでは、introspectVersionフィールドを変更すると、イントロスペクションの結果として変更されたWebLogicドメイン・ホームが生成された場合に、オペレータが新しい「イントロスペクション」を起動するため、サーバーが再起動されます。 変更されたWebLogicドメイン・ホームの生成の原因となるモデルまたは関連リソース(シークレットなど)の変更の詳細は、Model in Image 「ランタイム更新」のドキュメントを参照してください。
検出された唯一の変更が顧客指定のラベルまたは注釈の追加または変更である場合、オペレータはポッドを再起動するのではなく、ポッドに「パッチ」を適用します。 ドメインからラベルまたは注釈を削除すると、再起動もパッチ適用も行われません。 restartVersionを変更することで、再起動でそのようなラベルまたは注釈を強制的に削除できます。
クラスタを再起動する必要があるクラスタ化されたサーバーは徐々に再起動されるため(ローリング再起動など)、クラスタはサービスを停止せず、進行中の作業をクラスタ内の他のサーバーに移行できます。
クラスタのmaxUnavailableフィールドは、ローリング再起動の実行時に一度にサービスの停止が行われるクラスタ・サーバーの数を決定します。 クラスタ・レベルで指定でき、デフォルトは1です(つまり、デフォルトでは、クラスタ化されたサーバーは一度に1つずつ再起動されます)。
インメモリー・セッション・レプリケーションを使用する場合、Oracle WebLogic Serverはプライマリ-セカンダリ・セッション・レプリケーション・モデルを使用して、アプリケーション・セッション状態(HTTPおよびEJBセッション)の高可用性を実現します。 プライマリ・サーバーはクライアントが最初に接続するサーバー上にプライマリ・セッション状態を作成し、クラスタ内の別のWebLogic Serverインスタンス上に予備のレプリカを作成します。 1のmaxUnavailableプロパティ値を指定すると、ローリング再起動プロセス中にプライマリ・サーバーとセカンダリ・サーバーの両方が同時に停止した場合に発生する可能性のある不注意のセッション状態損失から保護されます。
実行中のModel in Imageドメインの更新済モデルまたはシークレットを指定し、ローリング再起動を使用して構成の更新を有効にする場合は、このドキュメントを参照する前に、「WebLogic構成の変更」および「ランタイムの更新」を参照してください。
Kubernetesクラスタ管理者は、Kubernetesクラスタを修復、アップグレードまたはスケール・ダウンするために「ノードのドレイン」を実行できます。
オペレータは、バージョン3.2以降、ノード・ドレイン操作中の高可用性のためにKubernetesによって提供されるPodDisruptionBudget機能を利用します。 オペレータは、ドメイン・ネームスペースの各WebLogicクラスタに対してPodDisruptionBudget (PDB)を作成し、ノードの排出時に同時に削除されるWebLogic Serverポッドの数を制限します。 同時に削除されるWebLogicクラスタのサーバー・ポッドの最大数は、クラスタ・リソースのmaxUnavailableフィールドによって決まります。 クラスタのPDBの.spec.minAvailableフィールドは、クラスタ用に構成された現在のreplicas数とmaxUnavailable値の差から計算されます。 たとえば、3つのレプリカおよびmaxUnavailableが1のWebLogicクラスタがある場合、PDBの.spec.minAvailableは2に設定されます。 この場合、Kubernetesは、WebLogicクラスタの管理対象サーバーの少なくとも2つのポッドをいつでも使用できるようにし、3つのポッドすべての準備が完了したときにのみポッドを削除します。 ノードとPodDisruptionBudgetの概念を安全に排出する方法の詳細は、「ノードを安全にドレイン」およびPodDisruptionBudgetを参照してください。
restartVersionを使用した、オペレータによるサーバーの再起動の強制restartVersionプロパティを使用すると、オペレータに強制的にサーバーを再起動させることができます。
一部のサーバーを再起動するたびに、restartVersionを別の値に設定する必要があります。 特定の値は重要ではないため、ほとんどの顧客は整数値を使用します。
オペレータは、新しい値を検出し、影響を受けるサーバーを再起動します(クラスタ化されたサーバーのローリング再起動など、WebLogic Serverインスタンスのポッド生成に影響する他のフィールドが変更された場合と同じメカニズムを使用します)。
restartVersionプロパティは、ドメイン、クラスタおよびサーバー・レベルで指定できます。 これら3つの値のいずれかが変更されると、サーバーが再起動されます。
restartVersionがドメインから削除されると、サーバーも再起動されます(たとえば、再起動する値を以前に指定した場合は、前回の再起動の完了後にその値を削除します)。
restartVersionをドメイン・レベルで新しい値に設定します。
kind: Domain
metadata:
name: domain1
spec:
restartVersion: "5"
...
クラスタ・レベルでrestartVersionを新しい値に設定します。
kind: Cluster
metadata:
name: domain1-cluster1
spec:
clusterName : "cluster1"
restartVersion: "5"
maxUnavailable: 2
...
クラスタ・リソースは、domain.spec.clustersから参照される必要があり、ドメインのWebLogic構成の対応するクラスタと一致する.spec.clusterNameが必要です。
restartVersionをadminServerレベルで新しい値に設定します。
kind: Domain
metadata:
name: domain1
spec:
adminServer:
restartVersion: "5"
...
restartVersionをmanagedServerレベルで新しい値に設定します。
kind: Domain
metadata:
name: domain1
spec:
managedServers:
- serverName: "standalone_server1"
restartVersion: "1"
- serverName: "cluster1_server1"
restartVersion: "2"
...
ドメインを完全に再起動するには、まずすべてのサーバー(管理サーバーおよび管理対象サーバー)を停止し、ドメインをサービスから削除してから再起動します。 ローリング再起動とは異なり、オペレータは完全なドメイン再起動を検出して開始できません。常に手動で開始する必要があります。
ドメインの完全再起動を手動で開始するには:
serverStartPolicyをNeverに変更します。 kind: Domain
metadata:
name: domain1
spec:
serverStartPolicy: Never
...
オペレータがそのドメインのすべてのサーバーを停止するまで待ちます。
ドメインを再起動するには、ドメイン・レベルのserverStartPolicyをIfNeededに戻します。 または、serverStartPolicyをデフォルト値のIfNeededとして指定する必要はありません。
kind: Domain
metadata:
name: domain1
spec:
serverStartPolicy: IfNeeded
...
ドメインのライフサイクル操作の開始に役立つスクリプトについては、「ライフサイクルのサンプル・スクリプト」を参照してください。