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

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

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

מפעילים של אפליקציות שמעדיפים להשתמש ב-CLI של gdcloud יכולים לעיין במאמר בנושא שכפול נפחים באופן אסינכרוני.

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

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

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

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

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

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 של היעד נשאר במצב קריאה בלבד ולא ניתן להרכבה על ידי עומסי עבודה כלשהם.

VM Disk API

שכפול של דיסקים של מכונות וירטואליות

בנוסף, VolumeReplicationRelationship מספק שירותים ל-API של שכפול אסינכרוני של דיסקים של מכונות וירטואליות (VM). דיסק המקור שמשוכפל נקרא הדיסק הראשי. דיסק היעד שמשוכפל אליו נקרא הדיסק המשני. התחלת שכפול אסינכרוני בדיסק ראשי תיצור באופן אוטומטי את הדיסק המשני.

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

כדי לשכפל דיסקים של מכונות וירטואליות, צריך להיות לכם תפקיד אדמין של מכונות וירטואליות בפרויקט. פועלים לפי השלבים לאימות שיש לכם את התפקיד Project VirtualMachine Admin ‏ (project-vm-admin) במרחב השמות של הפרויקט שבו נמצא דיסק ה-VM.

כדי לבצע פעולות במכונות וירטואליות באמצעות gdcloud CLI, צריך לבקש מהאדמין של IAM בפרויקט להקצות לכם את התפקיד 'אדמין מכונות וירטואליות בפרויקט' ואת התפקיד 'צפייה בפרויקט' (project-viewer).

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

מפעילים שכפול אסינכרוני בדיסק של מכונה וירטואלית באמצעות 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: מרחב השמות של משאב הפרויקט.
• ‫SOURCE_ZONE_NAME: השם של משאב האזור של המקור.
• ‫DESTINATION_ZONE_NAME: השם של משאב היעד של האזור.
• ‫VIRTUAL_MACHINE_SOURCE_DISK_NAME: השם של משאב VirtualMachineDisk במקור.
• ‫VIRTUAL_MACHINE_DESTINATION_DISK_NAME: השם של משאב VirtualMachineDisk ביעד.

בדוגמה הזו אנחנו מניחים שפרויקט בשם 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 כי זו הפעולה היחידה שנותרה שאפשר לבצע ב-CR הזה.

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

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

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

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