このドキュメントでは、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インスタンスのポッド生成に影響するドメインの次のいずれかのフィールドが変更されると、オペレータはサーバーを再起動します:
auxiliaryImages
auxiliaryImageVolumes
containerSecurityContext
domainHome
domainHomeSourceType
env
image
imagePullPolicy
imagePullSecrets
includeServerOutInPodLog
logHomeEnabled
logHome
livenessProbe
nodeSelector
podSecurityContext
readinessProbe
resources
restartVersion
startupProbe
volumes
volumeMounts
Model 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
...
ドメインのライフサイクル操作の開始に役立つスクリプトについては、「ライフサイクルのサンプル・スクリプト」を参照してください。