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

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

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

始める前に

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

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

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

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

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-pvc-repl
  namespace: my-project
spec:
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: xx-xxxx-zone1
 destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: xx-xxxx-zone2

この例では、my-org という名前の組織に my-project という名前のプロジェクトが作成され、my-block-pvc という名前の PVC がすでにプロビジョニングされていることを前提としています。clusterRef は、PVC が存在するクラスタの名前です。

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

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

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

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-pvc-repl
  namespace: my-project
spec:
  destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: xx-xxxx-zone2
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: xx-xxxx-zone1
status:
  zones:
  - name: xx-xxxx-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: xx-xxxx-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 組織の場合、これは組織の管理クラスタになります。たとえば、宛先ゾーンとして xx-xxxx-zone2 を指定する VolumeReplicationRelationship が作成され、PVC が my-org 組織に存在する場合、VolumeFailover CR は xx-xxxx-zone2 の my-org 管理プレーンに作成されます。これにより、2 つのゾーン間のレプリケーション関係が解除され、宛先ゾーンの PVC をワークロードでマウントできるようになります。

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

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

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

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

この時点で、VolumeReplicationRelationship は次の例のようになります。この出力では、わかりやすくするために一部の値を省略しています。

apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: my-pvc-repl
  namespace: my-project
spec:
  destination:
    pvc:
      clusterRef: my-pvc-cluster
    zoneRef: xx-xxxx-zone2
  source:
    pvc:
      clusterRef: my-pvc-cluster
      pvcRef: my-block-pvc
    zoneRef: xx-xxxx-zone1
status:
  zones:
  - name: xx-xxxx-zone1
    replicaStatus:
      message: SnapMirror relationship has been broken off
      replicationID: a096621e-f062-11ef-ad24-00a0b89f23fb
      state: Broken Off
  - name: xx-xxxx-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 を安全に削除できます。

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

ソース ボリュームのサイズが変更された場合は、VolumeReplicatioRelationship の作成時にユーザーに代わって作成された宛先ゾーン内の対応するボリュームのサイズも、一致するように変更する必要があります。

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

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

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

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

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

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

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

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	セカンダリ ディスクが存在する必要があるゾーン。

API

kubectl --kubeconfig GLOBAL_MANAGEMENT_API \
  apply -f - <<EOF
apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: VRR_NAME
  namespace: PROJECT
spec:
  source:
    virtualMachineDisk:
      virtualMachineDiskRef: PRIMARY_DISK_NAME
    zoneRef: PRIMARY_ZONE
  destination:
    volumeOverrideName: SECONDARY_DISK_NAME
    zoneRef: SECONDARY_ZONE
EOF

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

変数	定義
GLOBAL_MANAGEMENT_API	グローバル管理 API サーバーの kubeconfig ファイル。
VRR_NAME	ボリューム レプリケーション関係の名前。 非同期レプリケーションを停止するときは、同じ名前を使用する必要があります。
PROJECT	プライマリ ディスクの GDC プロジェクト。
PRIMARY_DISK_NAME	複製されるソースディスクの名前。
PRIMARY_ZONE	プライマリ ディスクが存在するゾーン。
SECONDARY_DISK_NAME	レプリケート先の宛先ディスクの名前。
SECONDARY_ZONE	セカンダリ ディスクが存在する必要があるゾーン。

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

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

kubectl --kubeconfig GLOBAL_MANAGEMENT_API get volumereplicationrelationships -n my-project

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

• PROJECT: プライマリ ディスクの GDC プロジェクト。
• GLOBAL_MANAGEMENT_API: グローバル管理 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 GLOBAL_MANAGEMENT_API 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 GLOBAL_MANAGEMENT_API delete volumereplicationrelationships \
     -n PROJECT VRR_NAMES
   

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

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

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

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

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