4.3. ストレージストラテジーの設定

本セクションでは、CodeReady Workspaces ワークスペースのストレージストラテジーを設定する方法を説明します。

4.3.1. codeready-workspaces ワークスペースのストレージストラテジー

ワークスペース Pod は、ReadWriteOnce アクセスモードで物理的な永続ボリューム (PV) にバインドされる Persistent Volume Claim(永続ボリューム要求、PVC)を使用します。CodeReady Workspaces サーバーがワークスペースに PVC を使用する方法を設定できます。この設定の個別の方法は PVC ストラテジーと呼ばれます。

ストラテジー詳細利点不利な点

unique

ワークスペースボリュームまたはユーザー定義 PVC ごとに 1 つの PVC

ストレージの分離

定義されない数の PV が必要です

per-workspace (デフォルト)

1 つのワークスペースに 1 つの PVC

一意のストラテジーと比較すると、ストレージの管理と制御が容易になります。

PV 数は不明で、ワークスペース数により異なります。

common

1 つの OpenShift namespace のすべてのワークスペースに 1 つの PVC

ストレージの管理と制御が容易になります。

PV が ReadWriteMany (RWX) アクセスモードをサポートしない場合、ワークスペースは別の OpenShift namespace になければなりません。

または、1 つの namespace で 2 つ以上のワークスペースを同時に実行することはできません。

Red Hat CodeReady Workspaces は、すべての CodeReady Workspaces ワークスペースがユーザーのプロジェクトで動作し、1 つの PVC を共有する場合に、common PVC ストラテジーを「ユーザーごとに 1 プロジェクト」のプロジェクトストラテジーと共に使用します。

4.3.1.1. common PVC ストラテジー

OpenShift プロジェクト内のすべてのワークスペースは、宣言されたボリュームに以下のようなデータを保存する際に、デフォルトのデータストレージと同じ Persistent Volume Claim(永続ボリューム要求、PVC)を使用します。

  • プロジェクト
  • ワークスペースログ
  • 使用に基づいて定義される追加のボリューム

common PVC ストラテジーが使用されている場合、ユーザー定義 PVC は無視され、これらのユーザー定義 PVC を参照するボリュームは共通 PVC を参照するボリュームに置き換えられます。このストラテジーでは、すべての CodeReady Workspaces ワークスペースが同じ PVC を使用します。ユーザーが 1 つのワークスペースを実行すると、一度にクラスター内の 1 つのノードにのみバインドします。

対応するコンテナーボリュームのマウントは共通ボリュームにリンクされ、サブパスには <workspace-ID> または <original-PVC-name> のプレフィックスが付けられます。詳細は、「サブパスが PVC で使用される方法」を参照してください。

CodeReady Workspaces ボリューム名は、ユーザー定義 PVC の名前と同じです。つまり、マシンがユーザー定義の PVC と同じ名前を持つ CodeReady Workspaces ボリュームを使用するように設定されている場合、それらは共通 PVC で同じ共有フォルダーを使用します。

ワークスペースが削除されると、対応するサブディレクトリー (${ws-id}) が PV ディレクトリーで削除されます。

注記

common PVC は、ユーザーのワークスペースがすべて削除された時点で削除されます。PVC は、一時ワークスペース以外のワークスペースの開始時に再作成されます。

common PVC ストラテジーの使用に関する制限

common ストラテジーが使用され、ワークスペース PVC アクセスモードが ReadWriteOnce (RWO) の場合、1 つのノードのみが PVC を同時に使用できます。

ノードが複数ある場合には、common ストラテジーを使用できますが、以下の点を注意してください。

  • ワークスペース PVC アクセスモードを ReadWriteMany (RWM)に再設定し、複数のノードがこの PVC を同時に使用できるようにする必要があります。
  • 同じプロジェクトの 1 つのワークスペースのみを実行できます。「ユーザーが実行できるワークスペース数の設定」を参照してください。

common PVC ストラテジーは、大規模なマルチノードクラスターには適していません。そのため、単一ノードクラスターで使用することが最も適しています。ただし、per-workspace プロジェクトストラテジーと組み合わせにより、common PVC ストラテジーは 75 ノードを超えるクラスターで使用できます。このストラテジーで使用する PVC は、1 つのプロジェクトが他のプロジェクトのリソースを使い切る状況を防ぐために、すべてのプロジェクトに対応するのに十分な大きさである必要があります。

4.3.1.2. per-workspace PVC ストラテジー

per-workspace ストラテジーは、common PVC ストラテジーに似ています。すべてのワークスペースではなく、すべてのワークスペースのボリュームが以下についてデフォルトのデータストレージと同じ PVC を使用する点が唯一の違いになります。

  • プロジェクト
  • ワークスペースログ
  • ユーザーが定義する追加のボリューム

このストラテジーでは、CodeReady Workspaces は単一の PVC によって割り当てられる割り当てられた PV にワークスペースのデータを保持します。

per-workspace PVC ストラテジーは、利用可能な PVC ストラテジーの中でも最も汎用的なストラテジーであり、ユーザーの量が多い大規模なマルチノードクラスターの適切なオプションとして機能します。per-workspace PVC ストラテジーを使用すると、ユーザーは複数のワークスペースを同時に実行できます。これにより、PVC がさらに作成されます。

4.3.1.3. unique PVC ストラテジー

'unique 'PVC ストラテジーを使用する場合、ワークスペースのすべての CodeReady Workspaces ボリュームには独自の PVC があります。その場合、ワークスペース PVC は以下のようになります。

  • ワークスペースの初回起動時に作成されます。
  • 対応するワークスペースが削除されると削除されます。

ユーザー定義の PVC は以下の詳細で作成されます。

  • これらは、プロジェクトの他の PVC との名前の競合を防ぐために、生成される名前でプロビジョニングされます。
  • ユーザー定義の PVC を参照するマウントされた物理的な永続ボリュームのサブパスには、<workspace-ID> または <PVC-name> のプレフィックスが付けられます。これにより、同じ PV データ構造が異なる PVC ストラテジーで設定されます。詳細は、「サブパスが PVC で使用される方法」を参照してください。

unique PVC ストラテジーは、ユーザーの量が少ない大規模なマルチノードクラスターに適しています。このストラテジーはワークスペースの各ボリュームについて別個の PVC で動作するため、さらに多くの PVC が作成されます。

4.3.1.4. サブパスが PVC で使用される方法

サブパスは、永続ボリューム (PV) のフォルダー階層を示しています。

/pv0001
  /workspaceID1
  /workspaceID2
  /workspaceIDn
    /che-logs
    /projects
    /<volume1>
    /<volume2>
    /<User-defined PVC name 1 | volume 3>
    ...

ユーザーが devfile でコンポーネントのボリュームを定義すると、同じ名前のボリュームを定義するすべてのコンポーネントは、PV 内の <PV-name>, <workspace-ID> または `<original-PVC-name> と同じディレクトリーでサポートされます。各コンポーネントでは、コンテナー内の異なるパスにこの場所をマウントすることができます。

common PVC ストラテジーを使用すると、ユーザー定義の PVC は共通 PVC のサブパスに置き換えられます。ユーザーがボリュームを my-volume として参照すると、これは /workspace-id/my-volume サブパスで common-pvc にマウントされます。