이제 VMware용 Anthos 클러스터는 VMware용 Google Distributed Cloud(소프트웨어 전용)입니다. 자세한 내용은 제품 개요를 참조하세요.

스토리지 정책 구성

이 문서에서는 Google Distributed Cloud 클러스터에 대한 VM 스토리지 정책을 구성하는 방법을 보여줍니다.

개요

vSphere에서 스토리지 정책 기반 관리(SPBM)는 가상 머신의 애플리케이션 요구에 맞게 스토리지를 조정하는 데 도움이 됩니다. 다양한 데이터 서비스와 스토리지 솔루션에서 단일 통합 제어판 역할을 하는 스토리지 정책 프레임워크를 제공합니다.

Google Distributed Cloud에서 datastores를 지정하는 대신 스토리지 정책을 지정할 수 있습니다. 애플리케이션 요구사항을 기반으로 스토리지 정책을 정의하면 vSphere가 데이터 스토어를 자동으로 선택하고 관리합니다. 이를 통해 스토리지와 관련된 오버헤드와 유지보수가 줄어들 수 있습니다.

상속

사용자 클러스터, 사용자 클러스터의 노드 풀 또는 사용자 클러스터의 제어 영역 노드 집합에 스토리지 정책을 지정할 수 있습니다. 또한 관리자 클러스터에 고가용성 제어 영역이 있고 Windows 노드 풀이 없는 경우 관리자 클러스터에 스토리지 정책을 지정할 수 있습니다.

사용자 클러스터에 스토리지 정책을 지정하면 해당 정책은 사용자 클러스터의 노드 풀에 상속됩니다. 개별 노드 풀에 스토리지 정책을 지정하면 클러스터 수준 스토리지 정책 대신 해당 정책이 사용됩니다. 마찬가지로 개별 노드 풀에 데이터 스토어를 지정하면 클러스터 수준 스토리지 정책 대신 해당 데이터 스토어가 사용됩니다.

Controlplane V2가 사용 설정된 사용자 클러스터에서 클러스터 수준 스토리지 정책은 제어 영역 노드에 상속됩니다. 제어 영역 노드에 스토리지 정책 또는 데이터 스토어를 지정하면 클러스터 수준 스토리지 정책 대신 해당 스토리지 정책 또는 데이터 스토어가 사용됩니다.

데이터 스토어에 스토리지 정책 적용

스토리지 정책을 단일 데이터 스토어 또는 여러 데이터 스토어에 적용할 수 있습니다. 스토리지 정책을 여러 데이터 스토어에 적용하면 관리자 클러스터, 사용자 클러스터 또는 노드 풀의 스토리지 리소스를 데이터 스토어 간에 분산할 수 있습니다.

예: 스토리지 정책 및 사용자 클러스터 만들기

이 섹션에서는 스토리지 정책과 사용자 클러스터를 만드는 예시를 제공합니다. 이 예시에서는 스토리지 정책을 2개의 데이터 스토어에 적용할 수 있다는 것을 보여줍니다.

Datastore에 태그 적용

이 예시의 단계를 수행하려면 vSphere 환경에 datastores가 두 개 이상 있어야 합니다.

사용자 클러스터의 노드를 호스팅하는 vSphere 클러스터는 이 연습에 사용할 데이터 스토어에 액세스할 수 있어야 합니다. 이를 확인하기 위한 실행 전 검사가 있습니다.

태그 적용을 위해 사용하는 vCenter 계정에는 루트 vCenter Server에 대해 다음과 같은 vSphere 태그 지정 권한이 있어야 합니다.

vSphere 태그 지정.vSphere 태그 만들기
vSphere 태그 지정.vSphere 태그 카테고리 만들기
vSphere 태그 지정.vSphere 태그 할당 또는 할당 해제

vSphere 클라이언트에서 이 연습에 사용하려고 선택한 각 데이터 스토어에 동일한 태그를 할당합니다. 자세한 내용은 데이터 스토어에 태그 할당을 참조하세요.

자세한 내용은 vSphere 태그 및 속성을 참조하세요.

스토리지 정책 만들기

vSphere 클라이언트에서 태그 기반 배치를 위한 VM 스토리지 정책을 만듭니다. 스토리지 정책에서 선택한 데이터 스토어에 적용한 태그를 지정합니다. 자세한 내용은 태그 기반 배치를 위한 VM 스토리지 정책 만들기를 참조하세요.

자세한 내용은 VM 스토리지 정책을 참조하세요.

vSAN 데이터 스토어를 사용하는 경우 vSAN 스토리지 정책을 참조하세요.

사용자 클러스터 만들기

이 연습에서는 고가용성 제어 영역이 있는 사용자 클러스터를 만들므로 제어 영역 노드가 3개 있습니다. 제어 영역 노드 외에도 하나의 노드 풀과 두 번째 노드 풀에 각각 3개씩 6개의 워커 노드가 있습니다. 모든 노드에는 고정 IP 주소가 사용됩니다.

먼저 사용자 클러스터 만들기의 안내를 따르세요.

사용자 클러스터 구성 파일을 입력할 때 다음을 수행합니다.

vCenter.storagePolicyName의 값을 기존 스토리지 정책의 이름으로 설정합니다. vCenter.datastore에 대한 값을 설정하지 않습니다.
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 블록 파일에 지정됩니다. 워커 노드가 6개뿐인데도 IP 블록 파일은 주소가 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의 노드에 이 하나의 데이터 스토어가 사용되고 스토리지 정책은 사용되지 않습니다.

사용자 클러스터 만들기에 설명된 대로 사용자 클러스터 만들기를 계속합니다.

관리자 클러스터와 별도의 데이터 센터에 사용자 클러스터 만들기

사용자 클러스터가 관리자 클러스터와 별도의 데이터 센터에 있을 수 있습니다. 두 데이터 센터에서 동일한 vCenter Server 인스턴스를 사용하거나 다른 vCenter Server 인스턴스를 사용할 수 있습니다.

이 섹션에서는 관리자 클러스터와 별도로 vCenter Server 인스턴스를 사용하는 사용자 클러스터를 만드는 방법의 예시를 제공합니다. 사용자 클러스터와 관리자 클러스터는 별도의 vCenter Server 인스턴스를 사용하므로 별도의 데이터 센터에 있습니다.

먼저 사용자 클러스터 만들기의 안내를 따르세요.

사용자 클러스터 구성 파일을 입력할 때 다음을 수행합니다.

vCenter.storagePolicyName의 값을 기존 스토리지 정책의 이름으로 설정합니다. vCenter.datastore에 대한 값을 설정하지 않습니다.
vCenter에서 address, datacenter, cluster, resourcePool에 대한 값을 지정합니다.
network.vCenter.networkName에 대한 값을 지정합니다.
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의 노드에 이 하나의 데이터 스토어가 사용되고 스토리지 정책은 사용되지 않습니다.

사용자 클러스터 만들기에 설명된 대로 사용자 클러스터 만들기를 계속합니다.

스토리지 vMotion 사용

이 섹션에서는 SPBM을 사용하는 클러스터에서 스토리지 vMotion을 사용하는 방법을 보여줍니다. SPBM을 사용하지 않는 클러스터에서 스토리지 vMotion을 사용하려면 데이터 스토어 마이그레이션 도구 사용을 참조하세요.

다음 단계를 따르세요.

모든 클러스터 VM을 대상 데이터 스토어로 마이그레이션합니다. 자세한 내용은 가상 머신을 새로운 컴퓨팅 리소스 및 스토리지로 마이그레이션을 참조하세요.

VM이 새 데이터 스토어로 성공적으로 마이그레이션되었는지 확인합니다.

클러스터의 머신 객체를 가져옵니다.

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

클러스터에 있는 모든 머신의 모든 디스크가 대상 데이터 스토어로 마이그레이션되었는지 확인합니다.

gkectl diagnose를 실행하여 클러스터가 정상인지 확인합니다.
이전 데이터 스토어를 제외하도록 스토리지 정책을 업데이트합니다. 그렇지 않으면 새 볼륨과 다시 생성된 VM이 이전 데이터 스토어에 할당될 수 있습니다.