ボリュームを非同期で複製する

このページでは、Google Distributed Cloud（GDC）のエアギャップ ブロック ストレージ ボリュームの非同期レプリケーションを設定して実行する方法について説明します。

非同期レプリケーションは、ある GDC ゾーンから別の GDC ゾーンにデータを複製するために使用されます。複製されたデータは、ソースゾーンのデータが使用できなくなった場合にフェイルオーバーに使用できます。フェイルオーバーを作成すると、元のボリュームを同じ宛先ボリュームに複製できなくなります。代わりに、新しいレプリケーション関係を作成する必要があります。

始める前に

非同期ブロック レプリケーションを使用するには、まずインフラストラクチャ オペレーター（IO）が、レプリケーションが必要な 2 つのゾーン間のストレージ インフラストラクチャを設定する必要があります。具体的には、まず各ゾーンから関連するストレージ クラスタをピアリングする必要があります。次に、ブロック ストレージがプロビジョニングされている組織に関連付けられたストレージ仮想マシンをピアリングする必要があります。

次に、VolumeReplicationRelationship リソースを管理する app-volume-replication-admin-global ロールがあることを確認します。グローバル API を使用できない場合は、volume-replication-admin ロールを使用して、ゾーン VolumeReplicationRelationshipReplica リソースを直接変更できます。

レプリケーションを設定する

VolumeReplicationRelationship カスタム リソース（CR）は、非同期ブロック レプリケーション API を提供します。この CR はグローバル管理 API に存在します。特定のブロック デバイスのレプリケーションを有効にするには、グローバル管理 API で VolumeReplicationRelationship CR を作成する必要があります。

PVC API の複製

注: プロジェクトのバインディングが必要です。参加する各ゾーンの各クラスタ リソースにプロジェクトが関連付けられていることを確認します。

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: VRR_NAME
  namespace: PROJECT
spec:
  source:
    pvc:
      clusterRef: SOURCE_USER_CLUSTER_NAME
      pvcRef: PVC_NAME
    zoneRef: SOURCE_ZONE_NAME
destination:
    pvc:
      clusterRef: DESTINATION_USER_CLUSTER_NAME
    zoneRef: DESTINATION_ZONE_NAME
EOF

次のように置き換えます。

• MANAGEMENT_API_SERVER: ゾーン API サーバーの kubeconfig パス。
• VRR_NAME: VolumeReplicationRelationship リソースの名前。
• PROJECT: Project リソースの Namespace。
• SOURCE_USER_CLUSTER_NAME: 接続するソース ユーザー クラスタ リソースの名前。
• PVC_NAME: PersistentVolumeClaim リソースの名前。
• SOURCE_ZONE_NAME: ソース Zone リソースの名前。
• DESTINATION_USER_CLUSTER_NAME: 接続する移行先のユーザー クラスタ リソースの名前。
• DESTINATION_ZONE_NAME: 宛先ゾーン リソースの名前。

この例では、my-org という名前の組織に PROJECT という名前のプロジェクトが作成され、PVC_NAME という名前の PVC がすでにプロビジョニングされていることを前提としています。SOURCE_USER_CLUSTER_NAME は PVC が存在する移行元クラスタの名前で、DESTINATION_USER_CLUSTER_NAME は新しい PVC が存在する移行先クラスタの名前です。

仕様の source フィールドと destination フィールドは、データがレプリケートされる元と先をそれぞれ示します。この例では、データは SOURCE_ZONE_NAME から DESTINATION_ZONE_NAME に複製されます。

注: 非同期ブロック レプリケーション サービスは、レプリケートされたデータを書き込むために、宛先ゾーンに PVC を自動的に作成します。デフォルトでは、この PVC の名前はソース PVC と同じですが、volumeOverrideName フィールドを使用して、作成された PVC の名前を指定できます。ただし、VolumeReplicationFailover が作成されるまで、移行先 PVC は読み取り専用のままで、どのワークロードにもマウントできません。

仮想マシンディスクを複製する

VolumeReplicationRelationship は、非同期仮想マシン ディスク（VM ディスク）レプリケーション API も処理します。複製されるソースディスクをプライマリ ディスクと呼びます。複製先のディスクをセカンダリ ディスクと呼びます。プライマリ ディスクで非同期レプリケーションを開始すると、セカンダリ ディスクが自動的に作成されます。

権限とアクセス権をリクエストする

仮想マシン ディスクを複製するには、プロジェクトの VirtualMachine 管理者のロールが必要です。VM ディスクが存在するプロジェクトの Namespace でプロジェクト VirtualMachine 管理者ロール（project-vm-admin）が付与されていることを確認する手順に沿って操作します。

gdcloud CLI を使用した仮想マシン オペレーションの場合は、プロジェクト IAM 管理者に、プロジェクト仮想マシン管理者ロールとプロジェクト閲覧者（project-viewer）ロールの両方を割り当てるよう依頼してください。

gdcloud

gdcloud compute disks start-async-replication PRIMARY_DISK_NAME \
  --project PROJECT --zone PRIMARY_ZONE \
  --secondary-disk SECONDARY_DISK_NAME --secondary-zone SECONDARY_ZONE

次のように置き換えます。

変数	定義
PRIMARY_DISK_NAME	複製されるソースディスクの名前。
PROJECT	プライマリ ディスクの GDC プロジェクト。
PRIMARY_ZONE	プライマリ ディスクが存在するゾーン。
SECONDARY_DISK_NAME	レプリケート先の宛先ディスクの名前。
SECONDARY_ZONE	セカンダリ ディスクが存在する必要があるゾーン。

VM Disk API

非同期レプリケーションを開始する

kubectl を使用して、VM ディスクで非同期レプリケーションを開始します。

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: VRR_NAME
  namespace: PROJECT
spec:
  destination:
    volumeOverrideName: VIRTUAL_MACHINE_DESTINATION_DISK_NAME
    zoneRef: DESTINATION_ZONE_NAME
  source:
    virtualMachineDisk:
      virtualMachineDiskRef: VIRTUAL_MACHINE_SOURCE_DISK_NAME
    zoneRef: SOURCE_ZONE_NAME
EOF

次のように置き換えます。

• MANAGEMENT_API_SERVER: ゾーン API サーバーの kubeconfig パス。
• VRR_NAME: VolumeReplicationRelationship リソースの名前。
• PROJECT: Project リソースの Namespace。
• VIRTUAL_MACHINE_DESTINATION_DISK_NAME: 宛先の VirtualMachineDisk リソースの名前。
• DESTINATION_ZONE_NAME: 宛先ゾーン リソースの名前。
• VIRTUAL_MACHINE_SOURCE_DISK_NAME: ソース上の VirtualMachineDisk リソースの名前。
• SOURCE_ZONE_NAME: ソース Zone リソースの名前。

この例では、my-org という名前の組織に PROJECT という名前のプロジェクトが作成され、VIRTUAL_MACHINE_SOURCE_DISK_NAME という名前の VirtualMachineDisk が VirtualMachine リソースにすでにプロビジョニングされていることを前提としています。

仕様の source フィールドと destination フィールドは、データがレプリケートされる元と先をそれぞれ示します。この例では、データは SOURCE_ZONE_NAME から DESTINATION_ZONE_NAME に複製されます。

注: 非同期ブロック レプリケーション サービスは、レプリケートされたデータを書き込むために、宛先ゾーンに VirtualMachineDisk を自動的に作成します。デフォルトでは、この VirtualMachineDisk の名前はソース VirtualMachineDisk と同じですが、volumeOverrideName フィールドを使用して、作成された VirtualMachineDisk の名前を指定できます。ただし、VolumeReplicationFailover が作成されるまで、移行先の VirtualMachineDisk は読み取り専用のままであり、どのワークロードでもマウントできません。

検証

グローバル API から VolumeReplicationRelationship CR を取得して、レプリケーション関係のステータスを確認します。次の例を参照してください。出力を簡略化するために切り捨てています。

kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationship VRR_NAME \
        -n PROJECT -o yaml

出力は次のようになります。

PVC API

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-pvc-repl
  namespace: my-project
spec:
  destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: zone2
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: zone1
status:
  zones:
  - name: zone1
    replicaStatus:
      message: SnapMirror relationship has been established. Please check the destination
        zone for relationship state
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Established
  - name: zone2
    replicaStatus:
      exportedSnapshotName: snapmirror.c34f8845-e8c0-11ef-ad24-00a0b89f23fb_2150007868.2025-02-21_150000
      message: SnapMirror relationship has been successfully established
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Idle

VM Disk API

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-vmdisk-vrr
  namespace: my-project
spec:
  destination:
    zoneRef: zone2
  source:
    virtualMachineDisk:
      virtualMachineDiskRef: my-vmdisk
    zoneRef: zone1
status:
  zones:
  - name: zone1
    replicaStatus:
      message: SnapMirror relationship has been established. Please check the destination
        zone for relationship state
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Established
  - name: zone2
    replicaStatus:
      exportedSnapshotName: snapmirror.c34f8845-e8c0-11ef-ad24-00a0b89f23fb_2150007868.2025-02-21_150000
      message: SnapMirror relationship has been successfully established
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Idle

フェイルオーバーの作成

ソースゾーンが何らかの理由で使用できない場合は、宛先ゾーンの組織の管理プレーンに VolumeFailover CR を作成できます。v2 組織の場合、これは管理 API サーバーになります。v1 組織の場合、これは組織の管理クラスタになります。たとえば、宛先ゾーンとして zone2 を指定する VolumeReplicationRelationship が作成され、my-org 組織に PVC または VirtualMachineDisk が存在する場合、VolumeFailover CR は zone2 の my-org 管理プレーンに作成されます。これにより、2 つのゾーン間のレプリケーション関係が解除され、ワークロードが宛先ゾーンの PVC または VirtualMachineDisk をマウントできるようになります。

  kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
  apiVersion: storage.gdc.goog/v1
  kind: VolumeFailover
  metadata:
    name: FAILOVER_NAME
    namespace: PROJECT
  spec:
    volumeReplicationRelationshipRef: VRR_NAME
  EOF

次のように置き換えます。

• FAILOVER_NAME: VolumeFailover リソースの名前。
• MANAGEMENT_API_SERVER: ゾーン API サーバーの kubeconfig パス。
• VRR_NAME: VolumeReplicationRelationship リソースの名前。
• PROJECT: Project リソースの Namespace。

フェイルオーバーが成功すると、CR のステータスに反映されます。

  kubectl --kubeconfig MANAGEMENT_API_SERVER get volumefailover FAILOVER_NAME \
          -n PROJECT -o yaml

• 出力は次のようになります。

  apiVersion: storage.gdc.goog/v1
  kind: VolumeFailover
  metadata:
    name: my-failover
    namespace: my-project
  spec:
    volumeReplicationRelationshipRef: my-vrr-repl
  status:
      state: Completed
  

• フェイルオーバーが作成されると、my-vrr-repl VolumeReplicationRelationship は Broken Off 状態に移行します。zone2 の PVC または VirtualMachineDisk をマウントできるようになりました。

• この時点で、VolumeReplicationRelationship は次の例のようになります。この出力も、簡略化のために切り捨てられています。

  kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationship VRR_NAME \
          -n PROJECT -o yaml
  

• 出力は次のようになります。

PVC API

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-vrr-repl
  namespace: my-project
spec:
  destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: zone2
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: zone1
status:
  zones:
  - name: zone1
    replicaStatus:
      message: SnapMirror relationship has been broken off
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Broken Off
  - name: zone2
    replicaStatus:
      exportedSnapshotName: snapmirror.c34f8845-e8c0-11ef-ad24-00a0b89f23fb_2150007868.2025-02-21_150000
      message: SnapMirror relationship has been broken off
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Broken Off

VM Disk API

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-vmdisk-vrr
  namespace: my-project
spec:
  destination:
    zoneRef: zone2
  source:
    virtualMachineDisk:
      virtualMachineDiskRef: my-vmdisk
    zoneRef: zone1
status:
  zones:
  - name: zone1
    replicaStatus:
      message: SnapMirror relationship has been broken off
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Broken Off
  - name: zone2
    replicaStatus:
      exportedSnapshotName: snapmirror.c34f8845-e8c0-11ef-ad24-00a0b89f23fb_2150007868.2025-02-21_150000
      message: SnapMirror relationship has been broken off
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Broken Off

• この CR で実行できるアクションは VolumeReplicationRelationship のみになったため、安全に削除できます。

  kubectl --kubeconfig MANAGEMENT_API_SERVER delete volumereplicationrelationship VRR_NAME \
          -n PROJECT
  

ボリュームのサイズを変更する

ソース ボリュームのサイズが変更された場合は、移行先ゾーンの対応するボリュームのサイズも一致するように変更する必要があります。移行先ゾーン ボリュームは、VolumeReplicationRelationship の作成時に作成されます。

移行元ゾーンと移行先ゾーンの両方でストレージのサイズを変更するには、VM ディスクを拡張するドキュメントまたはボリューム容量を拡張するドキュメントをご覧ください。

非同期レプリケーション関係を一覧表示する

kubectl を使用して、プロジェクト内の非同期レプリケーション関係を一覧表示します。

kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationships -n PROJECT

次のように置き換えます。

• PROJECT: プライマリ ディスクの GDC プロジェクト。
• MANAGEMENT_API_SERVER: ゾーン管理 API サーバーの kubeconfig ファイル。

出力は次のようになります。

NAME       AGE     SOURCE ZONE   SOURCE PVC   SOURCE PVC CLUSTER   SOURCE VM DISK      DEST. ZONE   DEST. PVC CLUSTER   DEST. VOLUME OVERRIDE     STATE
my-vrr     3m21s   zone1                                           my-vm-boot-disk     zone2                            my-vm-boot-disk-replica
test-vrr   7s      zone1                                           test-vm-boot-disk   zone2

非同期レプリケーションを停止する

gdcloud または kubectl を使用して、プライマリ VM ディスクの非同期レプリケーションを停止します。

gdcloud

gdcloud compute disks stop-async-replication PRIMARY_DISK_NAME \
  --project PROJECT --zone PRIMARY_ZONE

次のように置き換えます。

変数	定義
PRIMARY_DISK_NAME	複製されるソースディスクの名前。
PROJECT	プライマリ ディスクの GDC プロジェクト。
PRIMARY_ZONE	プライマリ ディスクが存在するゾーン。

API

1. プライマリ VM ディスクに対応するボリューム レプリケーション関係を見つけます。

   kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationships \
     -n PROJECT -o json | \
     jq -r '.items[] | select(.spec.source.virtualMachineDisk.virtualMachineDiskRef == "PRIMARY_DISK_NAME"
     and .spec.source.zoneRef == "PRIMARY_ZONE") | .metadata.name'
   

2. 前の手順でリストしたボリューム レプリケーション関係をそれぞれ削除します。VRR_NAMES は、ボリューム レプリケーション関係の名前に置き換えます。

   kubectl --kubeconfig MANAGEMENT_API_SERVER delete volumereplicationrelationships \
     -n PROJECT VRR_NAMES
   

   次のように置き換えます。

   変数	定義
   MANAGEMENT_API_SERVER	グローバル管理 API サーバーの kubeconfig ファイル。
   PROJECT	プライマリ ディスクの GDC プロジェクト。
   PRIMARY_DISK_NAME	複製されるソースディスクの名前。
   PRIMARY_ZONE	プライマリ ディスクが存在するゾーン。

なんらかの理由でソースゾーンが使用できない場合は、ボリューム フェイルオーバーを作成してレプリケーションを停止します。

レプリケートされたディスクを VM にアタッチする

レプリケーションが有効になっている間は、セカンダリ ディスクを VM にアタッチできません。レプリケーションが停止したら、セカンダリ ディスクを新しく作成した VM または既存の VM にアタッチできます。