异步复制卷

本页面介绍了如何设置和执行 Google Distributed Cloud (GDC) 气隙式块存储卷的异步复制。

异步复制用于将数据从一个 GDC 可用区复制到另一个可用区。如果源可用区数据变得不可用,则复制的数据可用于故障切换。请注意,创建故障切换后,无法将原始卷复制到同一目标卷。而是必须创建新的复制关系。

准备工作

如需使用异步块复制,您的基础架构运维者 (IO) 必须先在需要复制的两个可用区之间设置存储基础架构。具体而言,他们首先需要对每个可用区的相关存储集群进行对等互连。接下来,他们需要对与预配块存储的组织相关联的存储虚拟机进行对等互连。

然后,确保您拥有 app-volume-replication-admin-global 角色来管理 VolumeReplicationRelationship 资源。如果全局 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 资源的命名空间。
  • SOURCE_USER_CLUSTER_NAME:要连接的源用户集群资源的名称。
  • PVC_NAME:PersistentVolumeClaim 资源的名称。
  • SOURCE_ZONE_NAME:源可用区资源的名称。
  • DESTINATION_USER_CLUSTER_NAME:要连接的目标用户集群资源的名称。
  • DESTINATION_ZONE_NAME:目标 Zone 资源的名称。

此示例假定在名为 my-org 的组织中创建了一个名为 PROJECT 的项目,并且已预配了一个名为 PVC_NAME 的 PVC。SOURCE_USER_CLUSTER_NAME 是 PVC 所在的源集群的名称,DESTINATION_USER_CLUSTER_NAME 是将存在新 PVC 的目标集群的名称。

规范的 sourcedestination 字段分别指示数据复制的来源目标。在此示例中,数据从 SOURCE_ZONE_NAME 复制到 DESTINATION_ZONE_NAME

复制虚拟机磁盘

VolumeReplicationRelationship 还可为异步虚拟机磁盘 (VM 磁盘) 复制 API 提供服务。被复制的源磁盘称为主磁盘。要复制到的目标磁盘称为辅助磁盘。在主磁盘上开始异步复制会自动创建辅助磁盘。

请求权限和访问权限

如需复制虚拟机磁盘,您必须拥有项目虚拟机管理员角色。按照相关步骤验证您是否在虚拟机磁盘所在项目的命名空间中拥有 Project VirtualMachine Admin 角色 (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 辅助磁盘必须所在的可用区。

虚拟机磁盘 API

开始异步复制

使用 kubectl 在虚拟机磁盘上启动异步复制。

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 资源的命名空间。
  • VIRTUAL_MACHINE_DESTINATION_DISK_NAME:目标位置的 VirtualMachineDisk 资源的名称。
  • DESTINATION_ZONE_NAME:目标 Zone 资源的名称。
  • VIRTUAL_MACHINE_SOURCE_DISK_NAME:源上的 VirtualMachineDisk 资源的名称。
  • SOURCE_ZONE_NAME:源可用区资源的名称。

此示例假设在名为 my-org 的组织中创建了一个名为 PROJECT 的项目,并且已为 VirtualMachine 资源预配了名为 VIRTUAL_MACHINE_SOURCE_DISK_NAMEVirtualMachineDisk

规范的 sourcedestination 字段分别表示数据复制的目标。在此示例中,数据从 SOURCE_ZONE_NAME 复制到 DESTINATION_ZONE_NAME

验证

通过从全局 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

虚拟机磁盘 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 组织,这将是组织管理员集群。例如,如果创建了一个 VolumeReplicationRelationship,其中指定 zone2 为目标可用区,并且 my-org 组织中存在 PVC 或 VirtualMachineDisk,则 VolumeFailover CR 会在 my-org 管理平面中的 zone2 中创建。这会中断两个可用区之间的复制关系,并允许工作负载在目标可用区中挂载 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 资源的命名空间。

之后,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

虚拟机磁盘 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
  • 您现在可以安全地删除 VolumeReplicationRelationship,因为这是可对此 CR 执行的唯一剩余操作。

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

调整卷大小

如果源卷在任何时候调整了大小,您还必须调整目标可用区中的相应卷,使其大小与源卷保持一致。创建 VolumeReplicationRelationship 时,系统会创建目标地区卷。

如需了解如何调整源可用区和目标可用区中的存储空间大小,请参阅扩展虚拟机磁盘文档或扩展卷容量

列出异步复制关系

使用 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 停止主虚拟机磁盘上的异步复制。

gdcloud

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

替换以下内容:

变量定义
PRIMARY_DISK_NAME 正在复制的源磁盘的名称。
PROJECT 主磁盘的 GDC 项目。
PRIMARY_ZONE 主磁盘所在的地区。

API

  1. 查找与主虚拟机磁盘对应的卷复制关系。

    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 主磁盘所在的地区。

如果源可用区因任何原因而不可用,请创建卷故障切换以停止复制。

将复制的磁盘挂接到虚拟机

启用复制后,辅助磁盘无法挂接到虚拟机。停止复制后,您可以将辅助磁盘挂接到新创建的虚拟机现有虚拟机