‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

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

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

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

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

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

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

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: הנתיב של 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.

VM Disk API

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

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

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

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

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

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

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

אימות

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

יצירת יתירות כשל

אם אזור המקור לא זמין מסיבה כלשהי, אפשר ליצור בקשת שינוי (CR) של VolumeFailover במישור הניהול של הארגון באזור היעד. בארגון בגרסה 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.

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

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

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

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

PVC API

VM Disk API

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

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

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

אימות

PVC API

VM Disk API

יצירת יתירות כשל

PVC API

VM Disk API

שינוי הגודל של אמצעי אחסון

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