שכפול נפחי אחסון באופן אסינכרוני

בדף הזה מוסבר איך להגדיר ולבצע שכפול אסינכרוני של נפחי אחסון בלוקים ב-Google Distributed Cloud ‏ (GDC) עם בידוד פיזי.

שכפול אסינכרוני משמש לשכפול נתונים מאזור GDC אחד לאזור GDC אחר. אפשר להשתמש בנתונים המשוכפלים ליתירות כשל אם הנתונים באזור המקור לא זמינים. חשוב לזכור שאחרי שיוצרים מעבר לגיבוי, אי אפשר לשכפל את אמצעי האחסון המקורי לאותו אמצעי אחסון יעד. במקום זאת, צריך ליצור קשר שכפול חדש.

אדמינים של פלטפורמות שמנהלים PVC באמצעות KRM API יכולים לעיין במאמר שכפול נפחים באופן אסינכרוני.

לפני שמתחילים

כדי להשתמש בשכפול בלוקים אסינכרוני, מפעיל התשתית (IO) צריך קודם להגדיר שני אזורים לשכפול אסינכרוני.

לאחר מכן, מוודאים שיש לכם את התפקיד app-volume-replication-admin-global לניהול המשאב VolumeReplicationRelationship. במקרים שבהם ה-API הגלובלי לא זמין, אפשר להשתמש בתפקיד volume-replication-admin כדי לשנות ישירות את משאב VolumeReplicationRelationshipReplica האזורי.

הגדרת רפליקציה

המשאב המותאם אישית (CR) VolumeReplicationRelationship משרת את ה-API של שכפול בלוקים אסינכרוני. התגובה המוכנה מראש הזו קיימת ב-API לניהול גלובלי. כדי להפעיל שכפול של מכשיר בלוק מסוים, צריך ליצור CR של VolumeReplicationRelationship ב-API לניהול גלובלי:

Replicate PVC API

הערה: נדרש קישור לפרויקט. צריך לוודא שצירפתם את הפרויקט לכל משאב Cluster בכל אזור משתתף.

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: הנתיב של kubeconfig של שרת ה-API האזורי.
• ‫VRR_NAME: השם של משאב VolumeReplicationRelationship.
• ‫PROJECT: מרחב השמות של משאב הפרויקט.
• ‫SOURCE_USER_CLUSTER_NAME: השם של משאב האשכול של משתמש המקור שרוצים להתחבר אליו.
• ‫PVC_NAME: השם של משאב PersistentVolumeClaim.
• ‫SOURCE_ZONE_NAME: השם של משאב האזור של המקור.
• ‫DESTINATION_USER_CLUSTER_NAME: השם של משאב היעד של אשכול המשתמשים שאליו רוצים להתחבר.
• ‫DESTINATION_ZONE_NAME: השם של משאב היעד של האזור.

בדוגמה הזו מניחים שפרויקט בשם PROJECT נוצר בארגון בשם my-org, וש-PVC בשם PVC_NAME כבר הוקצה. ‫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 מספק שירותים ל-API של שכפול אסינכרוני של דיסקים של מכונות וירטואליות (VM). דיסק המקור שמשוכפל נקרא הדיסק הראשי. דיסק היעד שאליו מתבצעת השכפול נקרא הדיסק המשני. התחלת שכפול אסינכרוני בדיסק ראשי יוצרת אוטומטית את הדיסק המשני.

שליחת בקשה להרשאות ולגישה

כדי לשכפל דיסקים של מכונות וירטואליות, צריך להיות לכם התפקיד Project VirtualMachine Admin. פועלים לפי השלבים כדי לוודא שיש לכם את התפקיד 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	האזור שבו הדיסק המשני צריך להיות.

VM Disk 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: הנתיב של kubeconfig של שרת ה-API האזורי.
• ‫VRR_NAME: השם של משאב VolumeReplicationRelationship.
• ‫PROJECT: מרחב השמות של משאב הפרויקט.
• ‫VIRTUAL_MACHINE_DESTINATION_DISK_NAME: השם של משאב VirtualMachineDisk ביעד.
• ‫DESTINATION_ZONE_NAME: השם של משאב היעד של האזור.
• ‫VIRTUAL_MACHINE_SOURCE_DISK_NAME: השם של משאב VirtualMachineDisk במקור.
• ‫SOURCE_ZONE_NAME: השם של משאב האזור של המקור.

בדוגמה הזו אנחנו מניחים שפרויקט בשם PROJECT נוצר בארגון בשם my-org, וש-VirtualMachineDisk בשם VIRTUAL_MACHINE_SOURCE_DISK_NAME כבר הוקצה למשאב VirtualMachine.

השדות source ו-destination במפרט מציינים את המיקום שממנו מתבצעת השכפול ואליו הוא מתבצע, בהתאמה. בדוגמה הזו, הנתונים משוכפלים מ-SOURCE_ZONE_NAME אל DESTINATION_ZONE_NAME.

הערה: שירות השכפול האסינכרוני של בלוקים יוצר אוטומטית VirtualMachineDisk באזור היעד כדי לכתוב את הנתונים המשוכפלים. כברירת מחדל, ל-VirtualMachineDisk הזה יש את אותו השם כמו ל-VirtualMachineDisk המקור, אבל אפשר להשתמש בשדה volumeOverrideName כדי לציין את השם של ה-VirtualMachineDisk שנוצר. אבל עד שנוצר VolumeReplicationFailover, יעד VirtualMachineDisk נשאר לקריאה בלבד ולא ניתן להרכבה על ידי עומסי עבודה כלשהם.

אימות

כדי לבדוק את הסטטוס של יחסי הרפליקציה, מאחזרים את ה-CR‏ VolumeReplicationRelationship מה-API הגלובלי. אפשר להיעזר בדוגמה הבאה. הערה: הפלט קוצר לצורך פשטות:

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 במישור הניהול של אזור היעד בארגון. בארגון בגרסה 2, זה יהיה שרת ה-API לניהול. בארגון בגרסה 1, זה יהיה אשכול האדמין של הארגון. לדוגמה, אם נוצר VolumeReplicationRelationship שמציין את zone2 כאזור היעד, וקיים PVC או VirtualMachineDisk בארגון my-org, אז נוצר CR של VolumeFailover במישור הניהול של 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: הנתיב של kubeconfig של שרת ה-API האזורי.
• ‫VRR_NAME: השם של משאב VolumeReplicationRelationship.
• ‫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. אפשר עכשיו לטעון את ה-PVC או את VirtualMachineDisk ב-zone2.

• בשלב הזה, אסימון 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

• עכשיו אפשר למחוק את VolumeReplicationRelationship בבטחה, כי זו הפעולה היחידה שנותרה שאפשר לבצע בבקשת השינוי הזו.

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

שינוי הגודל של נפחים

אם משנים את הגודל של עוצמת הקול של המקור, צריך לשנות את הגודל של עוצמת הקול התואמת באזור היעד כך שיהיה זהה. נפח אזור היעד נוצר כשיוצרים את VolumeReplicationRelationship.

אפשר לעיין במסמכי התיעוד בנושא הרחבת דיסקים של מכונות וירטואליות או הרחבת נפח האחסון כדי לשנות את הגודל של האחסון באזורי המקור והיעד.

List asynchronous replication relationships

הצגת רשימה של יחסי שכפול אסינכרוני בפרויקט באמצעות kubectl.

kubectl --kubeconfig MANAGEMENT_API_SERVER get volumereplicationrelationships -n PROJECT

מחליפים את מה שכתוב בשדות הבאים:

• ‫PROJECT: פרויקט GDC של הדיסק הראשי.
• ‫MANAGEMENT_API_SERVER: קובץ ה-kubeconfig של שרת ה-API לניהול אזורי.

הפלט אמור להיראות כך:

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

הפסקת השכפול האסינכרוני

מפסיקים את השכפול האסינכרוני בדיסק של מכונת VM ראשית באמצעות 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	קובץ ה-kubeconfig של שרת ה-API לניהול גלובלי.
   PROJECT	פרויקט GDC של הדיסק הראשי.
   PRIMARY_DISK_NAME	השם של דיסק המקור שמשוכפל.
   PRIMARY_ZONE	האזור שבו נמצא הדיסק הראשי.

אם אזור המקור לא זמין מסיבה כלשהי, צריך ליצור מעבר לגיבוי נפח כדי להפסיק את השכפול.

צירוף הדיסק המשוכפל למכונה וירטואלית

בזמן שהשכפול מופעל, אי אפשר לצרף את הדיסק המשני למכונה וירטואלית. אחרי שההעתקה תופסק, תוכלו לצרף את הדיסק המשני למכונה וירטואלית חדשה או למכונה וירטואלית קיימת.