העברת קטגוריות

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

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

לפני שמעבירים דליים, צריך לבצע את השלבים הבאים:

1. הגדרת Storage Intelligence

2. הפעלת מחיקה עם יכולת שחזור.

3. בודקים את המכסות והמגבלות כדי לוודא שבמיקום החדש יש מספיק מכסות להכיל את הנתונים של הדלי.

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

5. מעיינים במגבלות על העברת דליים.

6. מסירים את כל התגים הקיימים של הקטגוריה.

7. אם אתם משתמשים בדוחות מלאי, שמרו את ההגדרות.

8. מקבלים את התפקידים הנדרשים, שמתוארים בקטע הבא.

קבלת התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות להעברת קטגוריות, צריך לבקש מהאדמין להקצות לכם את תפקיד ה-IAM אדמין לניהול אחסון (roles/storage.admin) בפרויקט. להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

ההרשאות הנדרשות

כדי להעביר דליים, צריך את ההרשאות הבאות:

• כדי להעביר מאגר: storage.buckets.relocate
• כדי לראות את הסטטוס של פעולת העברה של קטגוריה: storage.bucketOperations.get
• כדי לראות את רשימת פעולות ההעברה של קטגוריות לפרויקט: storage.bucketOperations.list
• כדי לבטל פעולה של העברת קטגוריה: storage.bucketOperations.cancel
• כדי לראות את המטא-נתונים של קטגוריה במהלך השלבים של הרצת ניסיון והעברת קטגוריה: storage.buckets.get
• כדי לקבל אובייקט בקטגוריה שרוצים להעביר: storage.objects.get
• כדי להציג את רשימת האובייקטים בקטגוריה שרוצים להעביר: storage.objects.list

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

העברת קטגוריות

בקטע הזה מתואר תהליך ההעברה של קטגוריות של Cloud Storage ממיקום אחד למיקום אחר.

כדי להעביר קטגוריה, מבצעים את השלבים הבאים:

1. בדיקת העברת הדלי באמצעות הרצת בדיקה (אופציונלי)

2. איך מתחילים את תהליך ההעברה של הקטגוריה

3. מתחילים את שלב הסנכרון הסופי

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

בדיקת ההעברה של הקטגוריה באמצעות הרצת בדיקה (אופציונלי)

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

• מפתחות הצפנה בניהול הלקוח (CMEK) או מפתחות הצפנה באספקת הלקוח (CSEK)
• מדיניות שמירת נתונים נעולה
• אובייקטים עם החזקות זמניות
• העלאות מרובות חלקים

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

המסוף

1. במסוף Google Cloud , נכנסים לדף Buckets של Cloud Storage.
   

   כניסה לדף Buckets

2. ברשימת הקטגוריות, לוחצים על שם הקטגוריה שרוצים להעביר.
3. בדף Bucket details, לוחצים על הכרטיסייה Configuration.
4. בקטע סקירה כללית, לוחצים על עריכה לצד השדה מיקום.
5. בדף Relocate bucket (העברת קטגוריה), מזינים את המיקום החדש של הקטגוריה. אחרי כל אחד מהשלבים הבאים, לוחצים על המשך כדי לעבור לשלב הבא:
   1. בקטע Confirm the bucket you plan to relocate (אישור הדלי שרוצים להעביר), בודקים את הדלי והמיקום שלו.
   2. בקטע לפני שממשיכים, בודקים את ההגדרות שחוסמות את ההעברה. אם חלה הגבלה על הקטגוריה, אפשר להשתמש בStorage Transfer Service כפתרון חלופי.

   3. בקטע Choose where to relocate your bucket, מבצעים את הפעולות הבאות:

      1. בוחרים סוג מיקום.

      2. בוחרים מיקום שבו יישמרו נתוני האובייקטים בקטגוריה.

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

   4. בקטע Choose how you'd like to proceed (בחירת אופן ההמשך), לוחצים על Start with a dry run (recommended) (התחלה עם הרצה יבשה (מומלץ)). הרצה יבשה מדמה את ההעברה כדי לזהות בעיות פוטנציאליות בלי להעביר נתונים.
   5. לוחצים על Continue.
6. לוחצים על התחלה.
7. בתיבת הדו-שיח לאישור Start with a dry run, בודקים את ההודעה שמופיעה ולוחצים על Start dry run.

אחרי שמתחילים הרצה יבשה, מתחילה פעולה ממושכת. אפשר לעקוב אחר ההתקדמות בכרטיסייה Operations בדף bucket details.

שורת הפקודה

כדי להתחיל הרצה יבשה, מריצים את הפקודה gcloud storage buckets relocate עם הדגל --dry-run:

gcloud storage buckets relocate gs://BUCKET_NAME --location=LOCATION --dry-run

כאשר:

• ‫BUCKET_NAME הוא שם הקטגוריה שרוצים להעביר.

• ‫LOCATION הוא מיקום היעד של הקטגוריה.

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

אם במהלך ההרצה היבשה מתגלות בעיות, צריך לטפל בהן לפני שממשיכים לשלב ההעברה.

API ל-JSON

1. התקנה והפעלה של ה-CLI של gcloud, שמאפשרות ליצור אסימון גישה לכותרת Authorization.

2. יוצרים קובץ JSON עם ההגדרות של הקטגוריה, שחייבות לכלול את הפרמטרים destinationLocation ו-validateOnly. רשימה מלאה של ההגדרות מופיעה במאמרי העזרה של Buckets: relocate. ההגדרות הנפוצות שצריך לכלול בקובץ:

   {
     "destinationLocation": "DESTINATION_LOCATION",
     "destinationCustomPlacementConfig": {
       "dataLocations": [
         LOCATIONS,
           ...
           ]
       },
     "validateOnly": "true"
     }

   כאשר:

   • ‫DESTINATION_LOCATION הוא מיקום היעד של הקטגוריה.
   • ‫LOCATIONS היא רשימה של קודי מיקום שישמשו לשני אזורים שניתנים להגדרה.
   • הערך של validateOnly מוגדר ל-true כדי להריץ בדיקה.

3. כדי להפעיל את API ל-JSON משתמשים בפקודת cURL:

   curl -X POST --data-binary @JSON_FILE_NAME \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json" \
     "https://storage.googleapis.com/storage/v1/b/BUCKET_NAME/relocate"

   כאשר:

   • ‫JSON_FILE_NAME הוא השם של קובץ ה-JSON שיצרתם.
   • ‫BUCKET_NAME הוא שם הקטגוריה שרוצים להעביר.

   אחרי שמתחילים הרצה יבשה, מתחילה פעולה ממושכת. ההרצה היבשה תצליח אם התנאים הבאים יתקיימו:

   • בדוח של ההרצה היבשה לא מופיעות שגיאות.

   • הערך של השדה done שמוחזר במשאב operations הוא true.

     {
     "kind": "storage#operation",
     "name": "projects/_/buckets/bucket/operations/operation_id",
     "metadata": {
       "@type": OperationMetadataType*,
       metadata OperationMetadata*
     },
     "done": "true",
     "response": {
           "@type": ResponseResourceType*,
           response ResponseResource*
         }
       }

     אם במהלך ההרצה היבשה מתגלות בעיות, צריך לטפל בהן לפני שממשיכים לשלב הפעלת ההעברה.

התחלת ההעברה של קטגוריית המוצרים

המסוף

1. במסוף Google Cloud , נכנסים לדף Buckets של Cloud Storage.
   

   כניסה לדף Buckets

2. ברשימת הקטגוריות, לוחצים על שם הקטגוריה שרוצים להעביר.
3. בדף Bucket details, לוחצים על הכרטיסייה Configuration.
4. בקטע סקירה כללית, לוחצים על עריכה לצד השדה מיקום.
5. בדף Relocate bucket (העברת קטגוריה), מזינים את המיקום החדש של הקטגוריה. אחרי כל אחד מהשלבים הבאים, לוחצים על המשך כדי לעבור לשלב הבא:
   1. בקטע Confirm the bucket you plan to relocate (אישור הדלי שרוצים להעביר), בודקים את הדלי והמיקום שלו.
   2. בקטע לפני שממשיכים, בודקים את ההגדרות שחוסמות את ההעברה. אם חלה הגבלה על הקטגוריה, אפשר להשתמש בStorage Transfer Service כפתרון חלופי.

   3. בקטע Choose where to relocate your bucket, מבצעים את הפעולות הבאות:

      1. בוחרים סוג מיקום.

      2. בוחרים מיקום שבו יישמרו נתוני האובייקטים בקטגוריה.

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

   4. בקטע בוחרים איך להמשיך, לוחצים על העברה עכשיו.
   5. לוחצים על Continue.
6. כדי להתחיל בתהליך ההעברה, לוחצים על התחלה.
7. בתיבת הדו-שיח לאישור העברה מיידית, בודקים את ההודעה שמופיעה ולוחצים על התחלת ההעברה.

אחרי שמתחילים את תהליך ההעברה, מתחילה פעולה ממושכת. אפשר לעקוב אחר ההתקדמות בכרטיסייה Operations בדף bucket details.

שורת הפקודה

כדי להתחיל את ההעברה של הקטגוריה, מריצים את הפקודה gcloud storage buckets relocate:

gcloud storage buckets relocate gs://BUCKET_NAME --location=LOCATION

כאשר:

• ‫BUCKET_NAME הוא שם הקטגוריה שרוצים להעביר.

• ‫LOCATION הוא מיקום היעד של הקטגוריה.

  הערה: כשיוצרים שני אזורים שאפשר להגדיר, צריך להגדיר את הדגל --location כקוד המיקום שמשויך לאזורים שצוינו, ולהשתמש בדגל --placement עם צמד אזורים תקין. לדוגמה, --location=US --placement=US-CENTRAL1,US-EAST1

API ל-JSON

1. התקנה והפעלה של ה-CLI של gcloud, שמאפשרות ליצור אסימון גישה לכותרת Authorization.

2. יוצרים קובץ JSON עם ההגדרות של הקטגוריה. רשימה מלאה של ההגדרות מופיעה במאמרי העזרה של Buckets: relocate. ההגדרות הנפוצות שצריך לכלול בקובץ:

   {
     "destinationLocation": "DESTINATION_LOCATION",
     "destinationCustomPlacementConfig": {
     "dataLocations": [
       LOCATIONS,
       ...
       ]
       },
     "validateOnly": "false"
     }

   כאשר:

   • ‫DESTINATION_LOCATION הוא מיקום היעד של הקטגוריה.
   • ‫LOCATIONS היא רשימה של קודי מיקום שישמשו לשני אזורים שניתנים להגדרה.
   • הערך של validateOnly מוגדר ל-false כדי להתחיל את ההעברה של הקטגוריה.

3. כדי להפעיל את API ל-JSON משתמשים בפקודת cURL:

   curl -X POST --data-binary @JSON_FILE_NAME \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json" \
     "https://storage.googleapis.com/storage/v1/b/BUCKET_NAME/relocate"

   כאשר:

   • ‫JSON_FILE_NAME הוא השם של קובץ ה-JSON שיצרתם.
   • ‫BUCKET_NAME הוא שם הקטגוריה שרוצים להעביר.

מעקב אחרי תהליך ההעברה

המסוף

כדי לעקוב אחרי ההתקדמות של ההרצה היבשה או של תהליך ההעברה, מבצעים את השלבים הבאים:

1. במסוף Google Cloud , נכנסים לדף Buckets של Cloud Storage.
   

   כניסה לדף Buckets

2. ברשימת הקטגוריות, לוחצים על שם הקטגוריה שרוצים להעביר.

3. בדף Bucket details, לוחצים על הכרטיסייה Operations.

4. ברשימת פעולות הקטגוריה שמופיעה, לוחצים על ההרצה היבשה או על פעולת ההעברה כדי לראות את הפרטים שלה.

בדף פרטי הפעולה מוצגים סיכום ההעברה, מדדים מרכזיים וסיכום שגיאות.

שורת הפקודה

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

API ל-JSON

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

בדוגמה הבאה מוצג הפלט שנוצר על ידי פעולת העברה:

  done: false
  kind: storage#operation
  metadata:
  '@type': type.googleapis.com/google.storage.control.v2.RelocateBucketMetadata
  commonMetadata:
    createTime: '2024-10-21T04:26:59.666Z
    endTime: '2024-12-29T23:39:53.340Z'
    progressPercent: 99
    requestedCancellation: false
    type: relocate-bucket
    updateTime: '2024-10-21T04:27:03.2892'
  destinationLocation: US-CENTRAL1
  finalizationState: 'READY'
  progress:
    byteProgressPercent: 100
    discoveredBytes: 200
    remainingBytes: 0
    discoveredObjectCount: 10
    remainingObjectCount: 8
    objectProgressPercent: 100
    discoveredSyncCount: 8
    remainingSyncCount: 0
    syncProgressPercent: 100
  relocationState: SYNCING
  sourceLocation: US
  validateOnly: false
  estimatedWriteDowntimeDuration: '7200s'
  writeDowntimeExpireTime: '2024-12-30T10:34:01.786Z'
  name: projects//buckets/my-bucket1/operations/Bar7-1b0khdew@nhenUQRTF_R-Kk4dQ5V1f8fzezkFcPh3XMvlTqJ6xhnqJ1h_QXFIeAirrEqkjgu4zPKSRD6WSSG5UGXil6w
  response:
    '@type': type.googleapis.com/google.storage.control.v2.RelocateBucketResponse
      selfLink: https://storage.googleusercontent.com/storage/v1_ds/b/my-bucket1/operations/Bar7-1b0khdew@nhenUQRTF_R-Kk4dQ5V1f8fzezkFcPh3XMvlTqJ6xhnqJ1h_QXFIeAirrEqkjgu4zPKSRD6WSSG5UGXil6w

בטבלה הבאה מפורטים השדות העיקריים בפלט שנוצר על ידי פעולת ההעברה:

שם השדה	תיאור	ערכים אפשריים
done	הודעה על השלמת פעולת ההעברה של הדלי.	true, false
kind	מציין שהמשאב הזה מייצג פעולת אחסון.
metadata	מספק מידע על הפעולה.
metadata.@type	מציין את סוג הפעולה כהעברה של קטגוריה.
metadata.commonMetadata	מטא-נתונים שמשותפים לכל הפעולות.
metadata.commonMetadata.createTime	השעה שבה נוצרה הפעולה הממושכת.
metadata.commonMetadata.endTime	השעה שבה הסתיימה הפעולה הממושכת.
metadata.commonMetadata.progressPercent	התקדמות משוערת של פעולה ארוכת טווח, באחוזים.	בין 0 ל-100%. ערך של -1 מציין שההתקדמות לא ידועה או לא רלוונטית.
metadata.commonMetadata.requestedCancellation	מציין אם המשתמש ביקש לבטל את הפעולה ארוכת הטווח.	true, false
metadata.commonMetadata.type	מציין את הסוג של הפעולה הממושכת.
metadata.commonMetadata.updateTime	המועד שבו הפעולה הממושכת עודכנה לאחרונה.
metadata.destinationLocation	מיקום היעד של קטגוריית הנתונים.
metadata.finalizationState	מציין את המוכנות להפעלת שלב הסנכרון הסופי.	‫READY: מציין שאפשר להתחיל את שלב הסנכרון הסופי. עם זאת, מומלץ להמתין עד שהערך בשדה progressPercent יגיע ל-99. WAITING_ON_SYNC: מציין שאי אפשר להתחיל את שלב הסנכרון הסופי. ‫NOT_REQUIRED: מציין ששלב הסנכרון הסופי לא נחוץ עבור הדלי הזה, ואפשר לדלג עליו. ‫BLOCKED_ON_ERRORS: מציין ששלב הסיום מושהה זמנית בגלל שגיאות. כדי להמשיך לשלב הבא, צריך לפתור את השגיאות. ‫RUNNING: מציין שהשלב האחרון נמצא בתהליך. ‫FINALIZED: מציין ששלב הסיום הושלם בהצלחה.
metadata.progress	פרטי ההתקדמות של פעולת ההעברה.
metadata.progress.byteProgressPercent	התקדמות העתקת הבייטים באחוזים.	בין 0 ל-100%. ערך של -1 מציין שההתקדמות לא ידועה או לא רלוונטית.
metadata.progress.discoveredBytes	מספר הבייטים שנמצאו בדלי המקור.
metadata.progress.discoveredObjectCount	מספר האובייקטים שנמצאו בקטגוריית המקור.
metadata.progress.discoveredSyncCount	מספר עדכוני המטא-נתונים של האובייקטים שנמצאו בקטגוריית המקור.
metadata.progress.objectProgressPercent	התקדמות העתקת האובייקטים באחוזים.	בין 0 ל-100%. ערך של -1 מציין שההתקדמות לא ידועה או לא רלוונטית.
metadata.progress.remainingBytes	מספר הבייטים שנותרו להעתקה מקטגוריית המקור לקטגוריית היעד.
metadata.progress.remainingObjectCount	מספר האובייקטים שנותרו להעתקה מקטגוריית המקור לקטגוריית היעד.
metadata.progress.remainingSyncCount	מספר עדכוני המטא-נתונים של האובייקטים שנותרו לסנכרון.
metadata.progress.syncProgressPercent	התקדמות עדכוני המטא-נתונים של האובייקט שיסונכרנו באחוזים.	בין 0 ל-100%. ערך של -1 מציין שההתקדמות לא ידועה או לא רלוונטית.
metadata.relocationState	המצב הכולל של פעולת ההעברה של ה-bucket.	‫SYNCING: מציין שהשלב של העברת הקטגוריה מעתיק באופן פעיל אובייקטים מקטגוריית המקור לקטגוריית היעד. ‫FINALIZING: מציין שהתחיל השלב האחרון. ‫FAILED: מציין שנתקלה שגיאה בשלב של העברת הדלי והוא לא הושלם בהצלחה. ‫SUCCEEDED: מציין ששלב ההעברה של הקטגוריה הושלם בהצלחה. ‫CANCELLED: מציין ששלב ההעברה של הקטגוריה בוטל.
metadata.sourceLocation	מיקום המקור של הקטגוריה.
metadata.validateOnly	מציין אם הופעל dry run של העברת הדלי.	true, false
metadata.estimatedWriteDowntimeDuration	משך ההשבתה המשוער של פעולות הכתיבה. הערך הזה מאוכלס אחרי ש-finalizationState הופך ל-READY.	הערך המינימלי הוא 7200s.
metadata.writeDowntimeExpireTime	השעה שבה מסתיים זמן ההשבתה של הכתיבה.
name	המזהה הייחודי של פעולת ההעברה הזו. פורמט: projects/_/buckets/bucket-name/operations/operation-id
response	התשובה של הפעולה.
response.@type	סוג התגובה.
selfLink	קישור לפעולה הזו.

הערה: ב-metadata.commonMetadata.progressPercent מוצג מצב ההשלמה הכולל של הפעולה הממושכת. הוא מגיע ל-100% כשכל השלבים מסתיימים. זהו האינדיקטור המהימן היחיד להצלחה מלאה. אינדיקטורים אחרים של התקדמות מציגים את התנועה של בייטים, אובייקטים ומטא-נתונים. יכול להיות שהם יגיעו ל-100% לפני metadata.commonMetadata.progressPercent. אחרי העברת הבייטים, האובייקטים והמטא-נתונים, תהליך ההעברה של הדלי מסתיים בשלבים האחרונים, ואז הערך של metadata.commonMetadata.progressPercent מתעדכן ל-100%.

אם נתקלתם בבעיות באינטראקציה עם תכונות אחרות של Cloud Storage, כדאי לעיין במאמר בנושא מגבלות.

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

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

המסוף

כדי להתחיל את שלב הסנכרון הסופי, מבצעים את השלבים הבאים:

1. במסוף Google Cloud , נכנסים לדף Buckets של Cloud Storage.
   

   כניסה לדף Buckets

2. ברשימת הקטגוריות, לוחצים על שם הקטגוריה שרוצים להעביר.

3. בדף Bucket details, לוחצים על הכרטיסייה Operations.

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

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

6. לוחצים על התחלת הסנכרון הסופי.

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

בדף פרטי הפעולה מוצג סיכום של ההעברה, מדדי מפתח וסיכום של השגיאות.

שורת הפקודה

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

כשהערך של finalizationState הוא READY, מריצים את הפקודה gcloud storage buckets relocate כדי להתחיל את הסנכרון הסופי:

gcloud storage buckets relocate --finalize --operation=projects/_/buckets/BUCKET_NAME/operations/OPERATION_ID

כאשר:

• ‫BUCKET_NAME הוא שם הקטגוריה שרוצים להעביר.
• ‫OPERATION_ID הוא המזהה של הפעולה הממושכת להעברת הקטגוריה, שמוחזר בתגובה של השיטות שמפעילים. לדוגמה, התגובה הבאה מוחזרת מקריאה ל-gcloud storage operations list ומזהה הפעולה הממושכת הוא AbCJYd8jKT1n-Ciw1LCNXIcubwvij_TdqO-ZFjuF2YntK0r74.

 `name: projects/_/buckets/my-bucket/operations/AbCJYd8jKT1n-Ciw1LCNXIcubwvij_TdqO-ZFjuF2YntK0r74` 

מגדירים את הדגל ttl כדי לקבל שליטה טובה יותר בתהליך ההעברה. לדוגמה:

gcloud storage buckets relocate --finalize --ttl TTL_DURATION --operation=projects/_/buckets/BUCKET_NAME/operations/OPERATION_ID

כאשר:

‫TTL_DURATION הוא אורך החיים (TTL) של שלב ההשבתה של הכתיבה במהלך תהליך העברה. הערך הזה מבוטא כמחרוזת, כמו 12h ל-12 שעות. הערך TTL_DURATION קובע את משך הזמן המקסימלי המותר של שלב ההשבתה של הכתיבה. אם זמן ההשבתה של פעולות הכתיבה חורג מהמגבלה הזו, תהליך ההעברה חוזר אוטומטית לשלב של העברת הדלי, ופעולות הכתיבה לדלי מופעלות מחדש. הערך צריך להיות בטווח של 6h (6 שעות) עד 48h (48 שעות). אם לא מציינים ערך, ברירת המחדל היא 12h (12 שעות).

API ל-JSON

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

אם מתחילים את שלב הסנכרון הסופי לפני הזמן, הפקודה מחזירה את הודעת השגיאה The relocate bucket operation isn't ready to advance to finalization running state, אבל תהליך ההעברה נמשך.

מומלץ להמתין עד שהערך של progressPercent יהיה 99 לפני שמתחילים את שלב הסנכרון הסופי.

1. התקנה והפעלה של ה-CLI של gcloud, שמאפשרות ליצור אסימון גישה לכותרת Authorization.

2. יוצרים קובץ JSON עם ההגדרות של העברת הקטגוריה. רשימה מלאה של ההגדרות מופיעה במאמרי העזרה של Buckets: advanceRelocateBucket. ההגדרות הנפוצות שצריך לכלול בקובץ:

   {
   "expireTime": "EXPIRE_TIME",
   "ttl": "TTL_DURATION"
   }

   כאשר:

   • ‫EXPIRE_TIME הוא הזמן שבו פג תוקף ההשבתה של פעולות הכתיבה.
   • ‫TTL_DURATION הוא אורך החיים (TTL) של שלב ההשבתה של הכתיבה במהלך תהליך העברה. הערך הזה מבוטא כמחרוזת, כמו 12h ל-12 שעות. הערך TTL_DURATION קובע את משך הזמן המקסימלי המותר של שלב ההשבתה של הכתיבה. אם זמן ההשבתה של פעולות הכתיבה חורג מהמגבלה הזו, תהליך ההעברה חוזר אוטומטית לשלב של העברת הדלי, ופעולות הכתיבה לדלי מופעלות מחדש. הערך צריך להיות בטווח של 6h (6 שעות) עד 48h (48 שעות). אם לא מציינים ערך, ברירת המחדל היא 12h (12 שעות).

3. כדי להפעיל את API ל-JSON משתמשים בפקודת cURL:

   curl -X POST --data-binary @JSON_FILE_NAME \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Content-Type: application/json" \
    "https://storage.googleapis.com/storage/v1/b/bucket/BUCKET_NAME/operations/OPERATION_ID/advanceRelocateBucket"

   כאשר:

   • ‫JSON_FILE_NAME הוא השם של קובץ ה-JSON שיצרתם.
   • ‫BUCKET_NAME הוא שם הקטגוריה שרוצים להעביר.
   • ‫OPERATION_ID הוא המזהה של הפעולה הממושכת שהפעילה את ההעברה של הקטגוריה. כדי לקבל את רשימת המזהים של פעולות ממושכות עבור דלי, אפשר לעיין במאמר בנושא Operations: list.

אחרי שהעברתם קטגוריה בהצלחה, לא תוכלו להעביר את אותה קטגוריה שוב במשך 14 ימים.

בדיקת תהליך ההעברה של הקטגוריה

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

כדי לוודא שתהליך ההעברה הושלם בהצלחה, אפשר להשתמש בשיטות הבאות:

• דגימה של פעולות ממושכות: העברה של קטגוריה היא פעולה ממושכת. אפשר לדגום את הפעולה הממושכת באמצעות operation id כדי לעקוב אחר התקדמות הפעולה ולוודא שהיא הושלמה בהצלחה על ידי אימות הסטטוס success. התהליך כולל שליחת שאילתות לגבי סטטוס הפעולה באופן תקופתי עד שהיא מגיעה למצב סופי. מידע על מעקב אחר פעולות ממושכות מופיע במאמר שימוש בפעולות ממושכות ב-Cloud Storage.

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

  רשומות היומן הבאות יעזרו לכם לקבוע אם ההעברה הצליחה או נכשלה:

  • העברה מוצלחת: Relocate bucket succeeded. All existing objects are now in the new placement configuration.

  • העברה נכשלה: Relocate bucket has failed. Bucket location remains unchanged.

  אפשר גם להגדיר התראות באמצעות התראות Pub/Sub, כדי לקבל הודעה כשהאירוע הספציפי של הצלחה או של כשל מופיע ביומנים. מידע על הגדרת התראות Pub/Sub זמין במאמר הגדרת התראות Pub/Sub ל-Cloud Storage.

השלמת המשימות להעברת דלי הפוסטים

אחרי שמעבירים את הקטגוריה, מבצעים את השלבים הבאים:

1. אופציונלי: משחזרים את אמצעי בקרת הגישה מבוססי התגים בדלי.
2. הגדרות קיימות של דוחות מלאי לא נשמרות במהלך תהליך ההעברה, ותצטרכו ליצור אותן מחדש באופן ידני. מידע על יצירת הגדרות של דוח מלאי זמין במאמר יצירת הגדרות של דוח מלאי.
3. מעדכנים את ההגדרות של התשתית כקוד, כמו Terraform ו-Google Kubernetes Engine configuration connector, כדי לציין את המיקום החדש של הדלי.
4. נקודות קצה אזוריות קשורות למיקומים ספציפיים, ותצטרכו לשנות את קוד האפליקציה כדי לשקף את נקודת הקצה החדשה.

איך לטפל בפעולות העברה של קטגוריות אחסון שנכשלו

לפני שמטפלים בפעולות העברה של דלי שנכשלו, כדאי לשים לב לגורמים הבאים:

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

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

המאמרים הבאים

• מידע על העברת קטגוריות