Mereplikasi volume secara asinkron

Halaman ini menunjukkan cara menyiapkan dan melakukan replikasi asinkron volume block storage yang terisolasi dari internet Google Distributed Cloud (GDC).

Replikasi asinkron digunakan untuk mereplikasi data dari satu zona GDC ke zona lainnya. Data yang direplikasi ini dapat digunakan dalam skenario failover jika data di zona sumber tidak tersedia. Perhatikan bahwa setelah failover dibuat, volume asli tidak dapat disiapkan untuk mereplikasi ke volume tujuan yang sama. Sebagai gantinya, hubungan replikasi baru harus dibuat.

Untuk Operator Aplikasi yang lebih memilih menggunakan CLI gdcloud, lihat Mereplikasi volume secara asinkron.

Sebelum memulai

Untuk menggunakan replikasi blok asinkron, Operator Infrastruktur (IO) Anda harus menyiapkan dua zona untuk replikasi asinkron terlebih dahulu.

Selanjutnya, pastikan Anda memiliki peran volume-replication-admin-global untuk mengelola resource VolumeReplicationRelationship. Jika API global tidak tersedia, peran app-volume-replication-admin dapat digunakan untuk mengubah resource VolumeReplicationRelationshipReplica zonal secara langsung.

Menyiapkan replikasi

VolumeReplicationRelationship Custom Resource (CR) melayani API replikasi blok asinkron. CR ini ada di API pengelolaan global. Untuk mengaktifkan replikasi bagi perangkat blok tertentu, CR VolumeReplicationRelationship harus dibuat di API pengelolaan global:

PVC API

Binding Project wajib diisi. Pastikan Anda telah melampirkan project ke setiap resource Cluster di setiap zona yang berpartisipasi.

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

Ganti kode berikut:

  • MANAGEMENT_API_SERVER: jalur kubeconfig server API zona.
  • VRR_NAME: nama resource VolumeReplicationRelationship.
  • PROJECT: namespace resource Project.
  • SOURCE_USER_CLUSTER_NAME: nama resource Cluster pengguna sumber yang akan dihubungkan.
  • PVC_NAME: nama Resource PersistentVolumeClaim.
  • SOURCE_ZONE_NAME: nama Resource Zona sumber.
  • DESTINATION_USER_CLUSTER_NAME: nama resource Cluster pengguna tujuan yang akan dihubungkan.
  • DESTINATION_ZONE_NAME: nama Resource Zona tujuan.

Contoh ini mengasumsikan bahwa project bernama PROJECT dibuat di org bernama my-org dan PVC bernama PVC_NAME telah disediakan. SOURCE_USER_CLUSTER_NAME adalah nama cluster sumber tempat PVC berada dan DESTINATION_USER_CLUSTER_NAME adalah nama cluster tujuan tempat PVC baru akan berada.

Kolom source dan destination spesifikasi menunjukkan tempat data direplikasi dari dan ke. Dalam contoh ini, data direplikasi dari SOURCE_ZONE_NAME ke DESTINATION_ZONE_NAME.

VM Disk API

Mereplikasi disk virtual machine

VolumeReplicationRelationship juga melayani API replikasi disk virtual machine (disk VM) asinkron. Disk sumber yang direplikasi disebut disk utama. Disk tujuan yang direplikasi disebut disk sekunder. Memulai replikasi asinkron pada disk utama akan otomatis membuat disk sekunder.

Meminta izin dan akses

Untuk mereplikasi disk VM, Anda harus memiliki peran Project VirtualMachine Admin. Ikuti langkah-langkah untuk memverifikasi bahwa Anda memiliki peran Project VirtualMachine Admin (project-vm-admin) di namespace project tempat disk VM berada.

Untuk operasi VM menggunakan gdcloud CLI, minta Admin IAM Project Anda untuk memberi Anda peran Project VirtualMachine Admin dan peran Project Viewer (project-viewer).

Mulai replikasi asinkron

Mulai replikasi asinkron pada disk VM menggunakan 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

Ganti kode berikut:

  • MANAGEMENT_API_SERVER: jalur kubeconfig server API zona.
  • VRR_NAME: nama resource VolumeReplicationRelationship.
  • PROJECT: namespace resource Project.
  • SOURCE_ZONE_NAME: nama Resource Zona sumber.
  • DESTINATION_ZONE_NAME: nama Resource Zona tujuan.
  • VIRTUAL_MACHINE_SOURCE_DISK_NAME: nama resource VirtualMachineDisk di sumber.
  • VIRTUAL_MACHINE_DESTINATION_DISK_NAME: nama resource VirtualMachineDisk di tujuan.

Contoh ini mengasumsikan bahwa project bernama PROJECT dibuat di org bernama my-org dan VirtualMachineDisk bernama VIRTUAL_MACHINE_SOURCE_DISK_NAME telah disediakan untuk resource VirtualMachine.

Kolom source dan destination spesifikasi menunjukkan tempat data direplikasi dari dan ke. Dalam contoh ini, data direplikasi dari SOURCE_ZONE_NAME ke DESTINATION_ZONE_NAME.

Verifikasi

Periksa status hubungan replikasi dengan mengambil CR VolumeReplicationRelationship dari API global. Lihat contoh berikut. Perhatikan bahwa output telah dipotong untuk menyederhanakan:

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

Outputnya mirip dengan hal berikut ini:

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

Buat failover

Jika zona sumber tidak tersedia karena alasan apa pun, CR VolumeFailover dapat dibuat di bidang pengelolaan zona tujuan organisasi. Untuk organisasi v2, ini akan menjadi server API pengelolaan. Untuk organisasi v1, cluster ini adalah cluster admin organisasi. Misalnya, jika VolumeReplicationRelationship dibuat yang menentukan zone2 sebagai zona tujuan dan PVC atau VirtualMachineDisk ada di organisasi my-org, maka CR VolumeFailover akan dibuat di bidang pengelolaan my-org di zone2. Hal ini akan menghentikan hubungan replikasi antara kedua zona, dan memungkinkan PVC atau VirtualMachineDisk di zona tujuan dipasang oleh workload:

  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

Ganti kode berikut:

  • FAILOVER_NAME: nama resource VolumeFailover.
  • MANAGEMENT_API_SERVER: jalur kubeconfig server API zona.
  • VRR_NAME: nama resource VolumeReplicationRelationship.
  • PROJECT: namespace resource Project.

  • Setelah itu, failover yang berhasil akan tercermin dalam status CR:

    kubectl --kubeconfig MANAGEMENT_API_SERVER get volumefailover FAILOVER_NAME \
            -n PROJECT -o yaml
    
  • Outputnya mirip dengan hal berikut ini:

    apiVersion: storage.gdc.goog/v1
    kind: VolumeFailover
    metadata:
      name: my-failover
      namespace: my-project
    spec:
      volumeReplicationRelationshipRef: my-vrr-repl
    status:
        state: Completed
    
  • Setelah failover dibuat, my-vrr-repl VolumeReplicationRelationship akan bertransisi ke status Broken Off. PVC atau VirtualMachineDisk di zone2 kini dapat di-mount.

  • Pada tahap ini, VolumeReplicationRelationship akan terlihat mirip dengan contoh berikut. Sekali lagi, output ini telah dipotong agar lebih sederhana:

    kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationship VRR_NAME \
            -n PROJECT -o yaml
    
  • Outputnya mirip dengan hal berikut ini:

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
  • Sekarang, VolumeReplicationRelationship dapat dihapus dengan aman karena merupakan satu-satunya tindakan yang tersisa yang dapat dilakukan pada CR ini.

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

Mengubah ukuran volume

Jika volume sumber diubah ukurannya kapan saja, volume yang sesuai di zona tujuan, yang dibuat atas nama pengguna saat VolumeReplicationRelationship dibuat, juga harus diubah ukurannya agar cocok.

Lihat dokumentasi Memperluas disk VM atau Memperluas kapasitas volume untuk mengubah ukuran penyimpanan di zona sumber dan tujuan.