ストレージ ポリシーを構成する

このドキュメントでは、Google Distributed Cloud クラスタの VM ストレージ ポリシーを構成する方法について説明します。

概要

vSphere では、ストレージ ポリシー ベースの管理（SPBM）を使用して、ストレージを仮想マシンのアプリケーションの要求に合わせて調整できます。これは、幅広いデータサービスとストレージ ソリューションにわたって単一の統合コントロール パネルとして機能するストレージ ポリシー フレームワークを提供します。

Google Distributed Cloud では、データストアを指定する代わりに、ストレージ ポリシーを指定できます。アプリケーションの要件に基づいてストレージ ポリシーを定義すると、vSphere が自動的にデータストアを選択して管理します。これにより、ストレージに関連するオーバーヘッドとメンテナンスが削減されます。

継承

ユーザー クラスタ、ユーザー クラスタ内のノードプール、またはユーザー クラスタ内のコントロール プレーン ノードのセットに対してストレージ ポリシーを指定できます。管理クラスタに高可用性コントロール プレーンがあり、Windows ノードプールがない場合は、管理クラスタのストレージ ポリシーを指定することもできます。

ユーザー クラスタにストレージ ポリシーを指定すると、そのポリシーはユーザー クラスタ内のノードプールによって継承されます。個々のノードプールにストレージ ポリシーを指定すると、そのポリシーがクラスタレベルのストレージ ポリシーの代わりに使用されます。同様に、個々のノードプールにデータストアを指定すると、そのデータストアがクラスタレベルのストレージ ポリシーの代わりに使用されます。

Controlplane V2 が有効になっているユーザー クラスタでは、クラスタレベルのストレージ ポリシーがコントロール プレーン ノードに継承されます。コントロール プレーン ノードにストレージ ポリシーまたはデータストアを指定すると、そのストレージ ポリシーまたはデータストアが、クラスタレベルのストレージ ポリシーの代わりに使用されます。

データストアへのストレージ ポリシーの適用

ストレージ ポリシーは、1 つのデータストアまたは複数のデータストアに適用できます。 ストレージ ポリシーを複数のデータストアに適用すると、管理クラスタ、ユーザー クラスタ、またはノードプールのストレージ リソースをデータストア間で分散できます。

例: ストレージ ポリシーとユーザー クラスタを作成する

このセクションでは、ストレージ ポリシーとユーザー クラスタの作成例を示します。この例は、ストレージ ポリシーを 2 つのデータストアに適用できることを示しています。

データストアにタグを適用する

この例の手順を行うには、vSphere 環境に 2 つ以上のデータストアが必要です。

ユーザー クラスタのノードをホストする vSphere クラスタには、この演習で使用するデータストアへのアクセス権が必要です。これを検証するプリフライト チェックがあります。

タグの適用に使用する vCenter アカウントには、ルート vCenter Server に対する次の vSphere のタグ付け権限が必要です。

  • vSphere Tagging.Create vSphere タグ
  • vSphere Tagging.Create vSphere タグカテゴリ
  • vSphere Tagging.Assign または vSphere タグ付け解除

vSphere Client で、この演習に使用するデータストアのそれぞれに同じタグを割り当てます。手順については、データストアへのタグの割り当てをご覧ください。

詳細については、vSphere のタグおよび属性をご覧ください。

ストレージ ポリシーを作成する

vSphere Client で、タグベースの配置用の VM ストレージ ポリシーを作成します。 ストレージ ポリシーで、選択したデータストアに適用したタグを指定します。手順については、タグベースの配置用に仮想マシン ストレージ ポリシーを作成をご覧ください。

詳細については、仮想マシン ストレージ ポリシーの作成と管理をご覧ください。

vSAN データストアを使用している場合は、vSAN のポリシーをご覧ください。

ユーザー クラスタを作成する

この演習では、高可用性コントロール プレーンを持つユーザー クラスタを作成するため、3 つのコントロール プレーン ノードがあります。コントロール プレーン ノードに加えて、6 つのワーカーノード（3 つは 1 つのノードプールに、3 つは 2 番目のノードプールに）があります。すべてのノードが静的 IP アドレスを使用します。

まず、ユーザー クラスタを作成するの手順を実行します。

ユーザー クラスタの構成ファイルに次のように入力します。

  • vCenter.storagePolicyName の値を既存のストレージ ポリシーの名前に設定します。vCenter.datastore の値は設定しないでください。

  • 2 つのノードプールを指定します。最初のノードプールでは、データストアとストレージ ポリシーを指定しないでください。2 番目のノードプールでは、vsphere.datastore の値を既存のデータストアの名前に設定します。

クラスタ構成ファイルの例

次に、IP ブロック ファイルとユーザー クラスタ構成ファイルの一部の例を示します。

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
    - ip: 172.16.21.3
    - ip: 172.16.21.4
    - ip: 172.16.21.5
    - ip: 172.16.21.6
    - ip: 172.16.21.7
    - ip: 172.16.21.8

user-cluster-yaml

apiVersion: v1
kind: UserCluster
...
vCenter:
  storagePolicyName: "my-storage-policy"
network:
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.9"
      hostname: "cp-vm-1"
    - ip: "172.16.21.10"
      hostname: "cp-vm-2"
    - ip: "172.16.21.11"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
    - "172.16.21.30-172.16.21.39"
...
enableControlplaneV2: true
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-pool-1"
  enableLoadBalancer: true
- name: "worker-pool-2"
  vSphere:
    datastore: "my-np2-datastore"
...

上記の例で理解しておくべき重要なポイントは、次のとおりです。

  • ワーカーノードの静的 IP アドレスは、IP ブロック ファイルに指定されています。IP ブロック ファイルには、ワーカーノードが 6 つしかなくてもアドレスが 7 つあります。その追加の IP アドレスは、クラスタのアップグレード、更新、自動修復に必要なものです。

  • コントロール プレーン ノード 3 つの静的 IP アドレスは、ユーザー クラスタ構成ファイルの network.controlPlaneIPBlock セクションで指定されます。このブロックでは、追加の IP アドレスは必要ありません。

  • masterNode.replicas フィールドが 3 に設定されているため、コントロール プレーン ノードは 3 つになります。masterNode で、vsphere.datastore または vsphere.storagePolicyName に何も指定されていません。そのため、コントロール プレーン ノードは vCenter.storagePolicyName で指定されたストレージ ポリシーを使用します。

  • ユーザー クラスタ構成ファイルには vCenter.storagePolicy の値は含まれていますが、vCenter.datastore の値は含まれていません。指定されたストレージ ポリシーは、独自のストレージ ポリシーまたは独自のデータストアを指定していないプール内のノードで使用されます。

  • node-pool-1 で、vsphere.datastore または vsphere.storagePolicyName に何も指定されていません。そのため、node-pool-1 内のノードは vCenter.storagePolicyName で指定されたストレージ ポリシーを使用します。

  • node-pool-2 では vsphere.datastore の値は my-np2-datastore であるため、node-pool-2 のノードはそのデータストアを使用し、ストレージ ポリシーを使用しません。

ユーザー クラスタを作成するの説明に沿って、ユーザー クラスタの作成を継続します。

管理クラスタとは別のデータセンターにユーザー クラスタを作成する

ユーザー クラスタは、管理クラスタとは別のデータセンターに配置できます。2 つのデータセンターは、vCenter Server の同じインスタンスまたは異なるインスタンスを使用できます。

このセクションでは、管理クラスタとは別の vCenter Server インスタンスを使用するユーザー クラスタを作成する方法の例を示します。ユーザー クラスタと管理クラスタは vCenter Server の別々のインスタンスを使用するため、別々のデータセンターに配置されます。

まず、ユーザー クラスタを作成するの手順を実行します。

ユーザー クラスタの構成ファイルに次のように入力します。

  • vCenter.storagePolicyName の値を既存のストレージ ポリシーの名前に設定します。vCenter.datastore の値は設定しないでください。

  • vCenter で、address、datacenter、cluster、resourcePool の値を指定します。

  • network.vCenter.networkName の値を指定します。

  • 2 つのノードプールを指定します。最初のノードプールでは、データストアとストレージ ポリシーを指定しないでください。2 番目のノードプールでは、vsphere.datastore の値を既存のデータストアの名前に設定します。

クラスタ構成ファイルの例

次に、IP ブロック ファイルとユーザー クラスタ構成ファイルの一部の例を示します。

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
    - ip: 172.16.21.3
    - ip: 172.16.21.4
    - ip: 172.16.21.5
    - ip: 172.16.21.6
    - ip: 172.16.21.7
    - ip: 172.16.21.8

user-cluster-yaml

apiVersion: v1
kind: UserCluster
...
vCenter:
  address: "my-vcenter-server-2.my-domain.example"
  datacenter: "my-uc-data-center"
  cluster: "my-uc-vsphere-cluster"
  resourcePool: "my-uc-resource-pool"
  storagePolicyName: "my-storage-policy"
network:
  vCenter:
    networkName: "my-uc-network"
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.9"
      hostname: "cp-vm-1"
    - ip: "172.16.21.10"
      hostname: "cp-vm-2"
    - ip: "172.16.21.11"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
    - "172.16.21.30-172.16.21.39"
...
enableControlplaneV2: true
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-pool-1"
  enableLoadBalancer: true
- name: "worker-pool-2"
  vSphere:
    datastore: "my-np2-datastore"
...

上記の例で理解しておくべき重要なポイントは、次のとおりです。

  • ユーザー クラスタ構成ファイルには vCenter.storagePolicy の値は含まれていますが、vCenter.datastore の値は含まれていません。指定されたストレージ ポリシーは、独自のストレージ ポリシーまたは独自のデータストアを指定していないノードプール内のノードで使用されます。

  • vCenter では、address、datacenter、cluster、resourcePool に指定された値があります。そのため、ユーザー クラスタは、管理クラスタとは異なる vCenter Server、データセンター、vSphere クラスタ、リソースプールを使用します。

  • network.vCenter.networkName に指定された値があります。

  • masterNode.replicas フィールドが 3 に設定されているため、コントロール プレーン ノードは 3 つになります。masterNode で、vsphere.datastore または vsphere.storagePolicyName に何も指定されていません。そのため、コントロール プレーン ノードは vCenter.storagePolicyName で指定されたストレージ ポリシーを使用します。

  • node-pool-1 で、vsphere.datastore または vsphere.storagePolicyName に何も指定されていません。そのため、node-pool-1 内のノードは vCenter.storagePolicyName で指定されたストレージ ポリシーを使用します。

  • node-pool-2 では vsphere.datastore の値は my-np2-datastore であるため、node-pool-2 のノードはそのデータストアを使用し、ストレージ ポリシーを使用しません。

ユーザー クラスタを作成するの説明に沿って、ユーザー クラスタの作成を継続します。

Storage vMotion の使用

このセクションでは、SPBM を使用するクラスタでストレージ vMotion を使用する方法について説明します。SPBM を使用しないクラスタでストレージ vMotion を使用する場合は、データストア移行ツールを使用するをご覧ください。

手順は次のとおりです。

  1. すべてのクラスタ VM をターゲット データストアに移行します。手順については、仮想マシンを新しい Compute リソースとストレージに移行するをご覧ください。

  2. VM が新しいデータストアに正常に移行されたことを確認します。

    クラスタ内の Machine オブジェクトを取得します。

    kubectl --kubeconfig CLUSTER_KUBECONFIG get machines --output yaml

    出力の status.disks で、VM にアタッチされているディスクを確認できます。例:

    status:
addresses:
– address: 172.16.20.2
  type: ExternalIP
disks:
– bootdisk: true
  datastore: pf-ds06
  filepath: ci-bluecwang-head-xvz2ccv28bf9wdbx-2/ci-bluecwang-head-xvz2ccv28bf9wdbx-2.vmdk
  uuid: 6000C29d-8edb-e742-babc-9c124013ba54
– datastore: pf-ds06
  filepath: anthos/gke-admin-nc4rk/ci-bluecwang-head/ci-bluecwang-head-2-data.vmdk
  uuid: 6000C29e-cb12-8ffd-1aed-27f0438bb9d9

    クラスタ内のすべてのマシンのすべてのディスクがターゲット データストアに移行されていることを確認します。

  3. gkectl diagnose を実行して、クラスタが正常であることを確認します。

  4. 古いデータストアを除外するようにストレージ ポリシーを更新します。そうしないと、新しいボリュームと再作成された VM が古いデータストアに割り当てられる可能性があります。