機械翻訳について

起動と停止

このドキュメントでは、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
    ...

クラスタの停止

クラスタを停止するには(たとえば、サービスを停止するには)、クラスタをドメインに追加し、そのserverStartPolicyNeverに設定します。

  kind: Cluster
  metadata:
    name: domain1-cluster1
  spec:
    clusterName: "cluster1"
    serverStartPolicy: Never
    ...

クラスタ・リソースは、domain.spec.clustersから参照される必要があり、ドメインのWebLogic構成の対応するクラスタと一致する.spec.clusterNameが必要です。

特定のスタンドアロン・サーバーの停止

特定のスタンドアロン・サーバーを停止するには、そのサーバーをドメインに追加し、そのserverStartPolicyNeverに設定します。

  kind: Domain
  metadata:
    name: domain1
  spec:
    managedServers:
    - serverName: "server1"
      serverStartPolicy: Never
    ...

管理サーバーを停止するには、adminServerserverStartPolicyNeverに設定します。 管理サーバーを停止するときは注意が必要です。 起動時に管理対象サーバーに接続できない場合は、管理対象サーバー独立(MSI)モード」で起動を試みますが、管理対象サーバーのポッドからアクセスできない認証プロバイダなどの理由で失敗する可能性があります。

特定のクラスタ化された管理対象サーバーの強制的な起動

通常、クラスタ内のすべての管理対象サーバー・メンバーは同一であり、オペレータがクラスタのreplicas数を取得するために十分な数のメンバーを起動しているかぎり、どの管理対象サーバー・メンバーが実行されているかは問題になりません。 ただし、一部の管理対象サーバーは異なる場合があり(たとえば、クラスタ内の他のサーバーが使用する一部の追加サービスをサポートしている場合)、常に起動する必要があります。

これを行うには、サーバーをドメインに追加し、そのserverStartPolicyAlwaysに設定します。

  kind: Domain
  metadata:
    name: domain1
  spec:
    managedServers:
    - serverName: "cluster1_server1"
      serverStartPolicy: Always
    ...

サーバーはクラスタのreplicasカウントにカウントされます。 また、Alwaysに対してreplicasサーバー数を超える数を構成すると、replicas数を超えてもすべてのサーバーが起動されます。

停止オプション

ドメインおよびクラスタのYAMLファイルには、domain.specdomain.adminServerdomain.spec.managedServersの各エントリおよびcluster.specで使用可能なフィールドserverPodが含まれます。 serverPodフィールドは、WebLogic Serverインスタンスに対してポッドが生成される方法の多くの詳細を制御します。

serverPodshutdownフィールドは、管理対象サーバーの停止方法を制御し、次の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プロパティが考慮されます。 waitForAllSessionstrueの場合、正常な停止プロセスは、すべてのHTTPセッションが完了するか無効になるまで待機してから続行します。 waitForAllSessionsfalseの場合、正常な停止プロセスは、続行する前に、非永続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」サーバー・インスタンスはセッションを無視しないため、タイムアウトが長くなります。

サーバーの再起動

ポッド生成に影響するドメインのフィールド(imagevolumesenvなど)が変更されると、オペレータは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インスタンス上に予備のレプリカを作成します。 1maxUnavailableプロパティ値を指定すると、ローリング再起動プロセス中にプライマリ・サーバーとセカンダリ・サーバーの両方が同時に停止した場合に発生する可能性のある不注意のセッション状態損失から保護されます。

実行中のModel in Imageドメインの更新済モデルまたはシークレットを指定し、ローリング再起動を使用して構成の更新を有効にする場合は、このドキュメントを参照する前に、「WebLogic構成の変更」および「ランタイムの更新」を参照してください。

ノードおよびPodDisruptionBudgetの排出

Kubernetesクラスタ管理者は、Kubernetesクラスタを修復、アップグレードまたはスケール・ダウンするために「ノードのドレイン」を実行できます。

オペレータは、バージョン3.2以降、ノード・ドレイン操作中の高可用性のためにKubernetesによって提供されるPodDisruptionBudget機能を利用します。 オペレータは、ドメイン・ネームスペースの各WebLogicクラスタに対してPodDisruptionBudget (PDB)を作成し、ノードの排出時に同時に削除されるWebLogic Serverポッドの数を制限します。 同時に削除されるWebLogicクラスタのサーバー・ポッドの最大数は、クラスタ・リソースのmaxUnavailableフィールドによって決まります。 クラスタのPDBの.spec.minAvailableフィールドは、クラスタ用に構成された現在のreplicas数とmaxUnavailable値の差から計算されます。 たとえば、3つのレプリカおよびmaxUnavailable1のWebLogicクラスタがある場合、PDBの.spec.minAvailable2に設定されます。 この場合、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が必要です。

管理サーバーの再起動

restartVersionadminServerレベルで新しい値に設定します。

  kind: Domain
  metadata:
    name: domain1
  spec:
    adminServer:
      restartVersion: "5"
    ...

スタンドアロンまたはクラスタ化された管理対象サーバーの再起動

restartVersionmanagedServerレベルで新しい値に設定します。

  kind: Domain
  metadata:
    name: domain1
  spec:
    managedServers:
    - serverName: "standalone_server1"
      restartVersion: "1"
    - serverName: "cluster1_server1"
      restartVersion: "2"
    ...

ドメイン全体の再起動

ドメインを完全に再起動するには、まずすべてのサーバー(管理サーバーおよび管理対象サーバー)を停止し、ドメインをサービスから削除してから再起動します。 ローリング再起動とは異なり、オペレータは完全なドメイン再起動を検出して開始できません。常に手動で開始する必要があります。

ドメインの完全再起動を手動で開始するには:

  1. ドメインのドメイン・レベルのserverStartPolicyNeverに変更します。
  kind: Domain
  metadata:
    name: domain1
  spec:
    serverStartPolicy: Never
    ...
  1. オペレータがそのドメインのすべてのサーバーを停止するまで待ちます。

  2. ドメインを再起動するには、ドメイン・レベルのserverStartPolicyIfNeededに戻します。 または、serverStartPolicyをデフォルト値のIfNeededとして指定する必要はありません。

  kind: Domain
  metadata:
    name: domain1
  spec:
    serverStartPolicy: IfNeeded
    ...
  1. オペレータは、ドメイン内のすべてのサーバーを再起動します。

ドメイン・ライフサイクルのサンプル・スクリプト

ドメインのライフサイクル操作の開始に役立つスクリプトについては、「ライフサイクルのサンプル・スクリプト」を参照してください。