העברה בין קטגוריות של Cloud Storage

אפשר להשתמש ב-Storage Transfer Service כדי להעביר כמויות גדולות של נתונים בין קטגוריות של Cloud Storage, באותו פרויקט בענן של Google או בין פרויקטים שונים.

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

מתי כדאי להשתמש ב-Storage Transfer Service

ב-Google Cloud יש כמה אפשרויות להעברת נתונים בין קטגוריות של Cloud Storage. מומלץ לפעול לפי ההנחיות הבאות:

  • העברה של פחות מ-1TB: משתמשים ב-gcloud. הוראות מפורטות מופיעות במאמר העברה ושינוי שם של קטגוריות.

  • העברת נתונים בנפח של יותר מ-1TB: צריך להשתמש ב-Storage Transfer Service. ‫Storage Transfer Service הוא אפשרות העברה מנוהלת שמספקת אבטחה, אמינות וביצועים מוכנים לשימוש. היא מייתרת את הצורך לבצע אופטימיזציה של סקריפטים ולתחזק אותם, וגם את הצורך לטפל בניסיונות חוזרים.

במדריך הזה מוסברות שיטות מומלצות להעברת נתונים בין קטגוריות של Cloud Storage באמצעות Storage Transfer Service.

הגדרת אסטרטגיית העברה

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

בחירת שם ל-bucket

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

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

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

שם חדש של קטגוריה

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

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

  1. העתקת הנתונים שלכם לקטגוריית אחסון חדשה.
  2. השעות השקטות מתחילות.
  3. עדכון האפליקציות כך שיצביעו על הקטגוריה החדשה.
  4. מוודאים שהכול פועל כצפוי, ושכל המערכות והחשבונות הרלוונטיים מקבלים גישה למאגר.
  5. מחיקת קטגוריית המקור.
  6. סיום השעות השקטות.

שמירת שם הקטגוריה

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

  1. העתקת הנתונים לקטגוריית אחסון זמנית.
  2. השעות השקטות מתחילות.
  3. מחיקת קטגוריית המקור.
  4. יצירת קטגוריה חדשה עם אותו שם כמו הקטגוריה המקורית.
  5. העתקת הנתונים לקטגוריה החדשה מהקטגוריה הזמנית.
  6. מחיקת הקטגוריה הזמנית.
  7. מוודאים שהכול פועל כצפוי, ושכל המערכות והחשבונות הרלוונטיים מקבלים גישה למאגר.
  8. סיום השעות השקטות.

צמצום זמן ההשבתה

‫Storage Transfer Service לא נועל קריאות או כתיבות בקטגוריות המקור או היעד במהלך ההעברה.

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

  1. העברת נתונים ראשונית: ביצוע העברה בכמות גדולה בלי לנעול את הגישה לקריאה ולכתיבה במקור.

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

אופטימיזציה של מהירות ההעברה

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

מגבלות רוחב הפס מוגדרות ברמת האזור ומחולקות באופן שווה בין כל הפרויקטים. אם יש מספיק רוחב פס, Storage Transfer Service יכול להשלים כ-1,000 משימות בשנייה לכל עבודת העברה. במקרה כזה, אפשר להאיץ העברה על ידי פיצול העבודה לכמה עבודות העברה קטנות. למשל, אפשר להשתמש בקידומות include ו-exclude כדי להעביר קבצים מסוימים.

במקרים שבהם המיקום, סוג האחסון ומפתח ההצפנה זהים, Storage Transfer Service לא יוצר עותק חדש של הבייטים, אלא יוצר רשומה חדשה של מטא-נתונים שמפנה ל-Blob המקור. כתוצאה מכך, העתקים של קורפוס גדול באותו מיקום ובאותה רמה מושלמים במהירות רבה, והם מוגבלים רק על ידי QPS.

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

שמירה של מטא-נתונים

המטא-נתונים הבאים של אובייקטים נשמרים כשמעבירים נתונים בין קטגוריות של Cloud Storage באמצעות Storage Transfer Service:

  • מטא-נתונים מותאמים אישית שנוצרו על ידי המשתמש.
  • שדות מטא-נתונים עם מפתח קבוע ב-Cloud Storage, כמו Cache-Control,‏ Content-Disposition,‏ Content-Type ו-Custom-Time.
  • גודל האובייקט.
  • מספר דור נשמר כשדה מטא-נתונים בהתאמה אישית עם המפתח x-goog-reserved-source-generation, שאפשר לערוך או להסיר אותו בהמשך.

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

  • רשימות של בקרת גישה (ACL) (acl)
  • סוג אחסון (storageClass)
  • CMEK (kmsKey)
  • החזקה זמנית לצורך משפטי (temporaryHold)
  • זמן יצירת האובייקט (customTime)

לפרטים נוספים, אפשר לעיין במאמרי העזרה של TransferSpec API.

שדות המטא-נתונים הבאים לא נשמרים:

  • שעת העדכון האחרון (updated)
  • etag
  • componentCount

אם הוא נשמר, זמן יצירת האובייקט מאוחסן כשדה מותאם אישית, customTime. הזמן של האובייקט updated מתאפס בהעברה, ולכן גם הזמן שחלף מאז שהאובייקט הועבר לסוג האחסון שלו מתאפס. המשמעות היא שאובייקט ב-Coldline Storage, אחרי ההעברה, צריך להתקיים שוב במשך 90 ימים ביעד כדי להימנע מחיובים על מחיקה מוקדמת.

אפשר להחיל את מדיניות מחזור החיים שמבוססת על createTime באמצעות customTime. הערכים הקיימים של customTime מוחלפים.

לפרטים נוספים על מה שנשמר ומה שלא, אפשר לעיין במאמר בנושא שמירת מטא-נתונים.

טיפול באובייקטים עם גרסאות

אם רוצים להעביר את כל הגרסאות של אובייקטים באחסון ולא רק את הגרסה האחרונה, צריך להשתמש ב-gcloudCLI או ב-API בארכיטקטורת REST כדי להעביר את הנתונים, בשילוב עם תכונת המניפסט של Storage Transfer Service.

כדי להעביר את כל הגרסאות של האובייקט:

  1. מציגים את רשימת האובייקטים בקטגוריה ומעתיקים אותם לקובץ JSON:

    gcloud storage ls --all-versions --recursive --json [SOURCE_BUCKET] > object-listing.json
    

    בדרך כלל הפקודה הזו מציגה כ-1,000 אובייקטים בשנייה.

  2. פיצול קובץ ה-JSON לשני קובצי CSV, קובץ אחד עם גרסאות לא עדכניות וקובץ אחר עם הגרסאות הפעילות:

    jq -r '.[] | select( .type=="cloud_object" and (.metadata | has("timeDeleted") | not)) | [.metadata.name, .metadata.generation] | @csv' object-listing.json > live-object-manifest.csv
    jq -r '.[] | select( .type=="cloud_object" and (.metadata | has("timeDeleted"))) | [.metadata.name, .metadata.generation] | @csv' object-listing.json > non-current-object-manifest.csv
    
  3. הפעלת ניהול גרסאות של אובייקטים בקטגוריית היעד.

  4. מעבירים קודם את הגרסאות שלא עדכניות על ידי העברת קובץ המניפסט non-current-object-manifest.csv בתור הערך של השדה transferManifest.

  5. לאחר מכן, מעבירים את הגרסאות הפעילות באותה דרך, ומציינים את הקובץ live-object-manifest.csv כמניפסט.

הגדרת אפשרויות ההעברה

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

  • רישום ביומן: Cloud Logging מספק יומנים מפורטים של אובייקטים ספציפיים, שמאפשרים לכם לאמת את סטטוס ההעברה ולבצע בדיקות נוספות של תקינות הנתונים.

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

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

העברת הנתונים

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

יצירת קטגוריה חדשה

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

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

העתקת אובייקטים לקטגוריה החדשה

אפשר להעתיק אובייקטים מקטגוריית המקור לקטגוריה חדשה באמצעותGoogle Cloud המסוף, gcloud ה-CLI, ה-API בארכיטקטורת REST או ספריות הלקוח. הגישה שתבחרו תלויה באסטרטגיית ההעברה שלכם.

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

אל תכללו בשם של עבודת ההעברה מידע רגיש כמו פרטים אישיים מזהים (PII) או נתוני אבטחה. יכול להיות ששמות המשאבים יועברו לשמות של משאבים אחרים ב-Google Cloud, ויוצגו למערכות פנימיות של Google מחוץ לפרויקט שלכם.

מסוף Google Cloud

שימוש ב-Cloud Storage Transfer Service מתוך מסוףGoogle Cloud :

  1. פותחים את הדף 'העברה' במסוף Google Cloud .

    פותחים את הדף Transfer

  2. לוחצים על Transfer.
  3. פועלים לפי ההוראות המפורטות בלחיצה על Next Step בכל שלב:

    • תחילת העבודה: משתמשים ב-Google Cloud Storage גם כסוג המקור וגם כסוג היעד.

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

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

    • בחירת הגדרות: בוחרים באפשרות Delete files from source after they're transferred.

    • אפשרויות תזמון: אפשר להתעלם מהסעיף הזה.

  4. אחרי שמסיימים את ההדרכה המפורטת לוחצים על Create.

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

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

    פותחים את הדף 'העברה' במסוף Google Cloud .

    פותחים את הדף Transfer

    במאמר פתרון בעיות מוסבר איך מקבלים מידע מפורט על שגיאות בנושא פעולות ב-Storage Transfer Service שנכשלו במסוף Google Cloud .

  5. אם סימנתם את תיבת הסימון Delete source objects after the transfer completes במהלך ההגדרה, בסיום ההעברה לא תצטרכו לעשות שום דבר כדי למחוק את האובייקטים מהקטגוריה הישנה. עם זאת, אפשר גם לבצע מחיקה של הקטגוריה הישנה, בנפרד.

‫CLI של gcloud

התקנת ה-CLI של gcloud

אם עוד לא עשיתם זאת, מתקינים את כלי שורת הפקודה של Google Cloud.

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

gcloud init

הוספת חשבון השירות לתיקיית היעד

לפני שיוצרים העברה, צריך להוסיף את חשבון השירות של Storage Transfer Service לדלי היעד. כדי לעשות זאת, משתמשים בפקודה gcloud storage buckets add-iam-policy-binding:

gcloud storage buckets add-iam-policy-binding gs://bucket_name \
--member=serviceAccount:project-12345678@storage-transfer-service.iam.gserviceaccount.com \
--role=roles/storage.admin

הוראות לשימוש במסוף או ב-API מופיעות במאמר שימוש בהרשאות IAM במסמכי Cloud Storage. Google Cloud

יצירת עבודת ההעברה

כדי ליצור משימת העברה חדשה, משתמשים בפקודה gcloud transfer jobs create. יצירת משימה חדשה מתחילה את ההעברה שצוינה, אלא אם צוין לוח זמנים או --do-not-run.

gcloud transfer jobs create SOURCE DESTINATION

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

  • SOURCE הוא מקור הנתונים להעברה הזו, בפורמט gs://BUCKET_NAME.

  • DESTINATION היא הקטגוריה החדשה שלכם, בתבנית gs://BUCKET_NAME.

אפשרויות נוספות:

  • פרטי המשימה: אפשר לציין --name ו--description.

  • לוח זמנים: מציינים --schedule-starts,‏ --schedule-repeats-every ו---schedule-repeats-until, או --do-not-run.

  • תנאים לאובייקטים: משתמשים בתנאים כדי לקבוע אילו אובייקטים יועברו. הם כוללים את --include-prefixes ואת --exclude-prefixes, ואת התנאים מבוססי-הזמן ב---include-modified-[before | after]-[absolute | relative].

  • אפשרויות העברה: מציינים אם להחליף קבצים ביעד (--overwrite-when=different או always) ואם למחוק קבצים מסוימים במהלך ההעברה או אחריה (--delete-from=destination-if-unique או source-after-transfer). מציינים אילו ערכי מטא-נתונים לשמור (--preserve-metadata), ואפשר גם להגדיר מחלקת אחסון לאובייקטים שהועברו (--custom-storage-class).

  • התראות: הגדרה של התראות Pub/Sub להעברות באמצעות --notification-pubsub-topic,‏ --notification-event-types ו---notification-payload-format.

כדי לראות את כל האפשרויות, מריצים את הפקודה gcloud transfer jobs create --help.

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

gcloud transfer jobs create gs://old-bucket gs://new-bucket \
  --include-prefixes="folder1/"

REST

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

בקשה באמצעות transferJobs create:

POST https://storagetransfer.googleapis.com/v1/transferJobs
{
  "description": "YOUR DESCRIPTION",
  "status": "ENABLED",
  "projectId": "PROJECT_ID",
  "schedule": {
      "scheduleStartDate": {
          "day": 1,
          "month": 1,
          "year": 2025
      },
      "startTimeOfDay": {
          "hours": 1,
          "minutes": 1
      },
      "scheduleEndDate": {
          "day": 1,
          "month": 1,
          "year": 2025
      }
  },
  "transferSpec": {
      "gcsDataSource": {
          "bucketName": "GCS_SOURCE_NAME"
      },
      "gcsDataSink": {
          "bucketName": "GCS_SINK_NAME"
      },
      "transferOptions": {
          "deleteObjectsFromSourceAfterTransfer": true
      }
  }
}

תשובה:

200 OK
{
  "transferJob": [
      {
          "creationTime": "2015-01-01T01:01:00.000000000Z",
          "description": "YOUR DESCRIPTION",
          "name": "transferJobs/JOB_ID",
          "status": "ENABLED",
          "lastModificationTime": "2015-01-01T01:01:00.000000000Z",
          "projectId": "PROJECT_ID",
          "schedule": {
              "scheduleStartDate": {
                  "day": 1,
                  "month": 1,
                  "year": 2015
              },
              "startTimeOfDay": {
                  "hours": 1,
                  "minutes": 1
              }
          },
          "transferSpec": {
              "gcsDataSource": {
                  "bucketName": "GCS_SOURCE_NAME",
              },
              "gcsDataSink": {
                  "bucketName": "GCS_NEARLINE_SINK_NAME"
              },
              "objectConditions": {
                  "minTimeElapsedSinceLastModification": "2592000.000s"
              },
              "transferOptions": {
                  "deleteObjectsFromSourceAfterTransfer": true
              }
          }
      }
  ]
}

ספריות לקוח

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

מידע נוסף על ספריות הלקוח של Storage Transfer Service זמין במאמר תחילת העבודה עם ספריות הלקוח של Storage Transfer Service.

Java

מחפשים דוגמאות ישנות יותר? מדריך להעברת נתונים באמצעות Storage Transfer Service

import com.google.protobuf.Duration;
import com.google.storagetransfer.v1.proto.StorageTransferServiceClient;
import com.google.storagetransfer.v1.proto.TransferProto.CreateTransferJobRequest;
import com.google.storagetransfer.v1.proto.TransferTypes.GcsData;
import com.google.storagetransfer.v1.proto.TransferTypes.ObjectConditions;
import com.google.storagetransfer.v1.proto.TransferTypes.Schedule;
import com.google.storagetransfer.v1.proto.TransferTypes.TransferJob;
import com.google.storagetransfer.v1.proto.TransferTypes.TransferJob.Status;
import com.google.storagetransfer.v1.proto.TransferTypes.TransferOptions;
import com.google.storagetransfer.v1.proto.TransferTypes.TransferSpec;
import com.google.type.Date;
import com.google.type.TimeOfDay;
import java.io.IOException;
import java.util.Calendar;

public class TransferToNearline {
  /**
   * Creates a one-off transfer job that transfers objects in a standard GCS bucket that are more
   * than 30 days old to a Nearline GCS bucket.
   */
  public static void transferToNearline(
      String projectId,
      String jobDescription,
      String gcsSourceBucket,
      String gcsNearlineSinkBucket,
      long startDateTime)
      throws IOException {

    // Your Google Cloud Project ID
    // String projectId = "your-project-id";

    // A short description of this job
    // String jobDescription = "Sample transfer job of old objects to a Nearline GCS bucket.";

    // The name of the source GCS bucket to transfer data from
    // String gcsSourceBucket = "your-gcs-source-bucket";

    // The name of the Nearline GCS bucket to transfer old objects to
    // String gcsSinkBucket = "your-nearline-gcs-bucket";

    // What day and time in UTC to start the transfer, expressed as an epoch date timestamp.
    // If this is in the past relative to when the job is created, it will run the next day.
    // long startDateTime =
    //     new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").parse("2000-01-01 00:00:00").getTime();

    // Parse epoch timestamp into the model classes
    Calendar startCalendar = Calendar.getInstance();
    startCalendar.setTimeInMillis(startDateTime);
    // Note that this is a Date from the model class package, not a java.util.Date
    Date date =
        Date.newBuilder()
            .setYear(startCalendar.get(Calendar.YEAR))
            .setMonth(startCalendar.get(Calendar.MONTH) + 1)
            .setDay(startCalendar.get(Calendar.DAY_OF_MONTH))
            .build();
    TimeOfDay time =
        TimeOfDay.newBuilder()
            .setHours(startCalendar.get(Calendar.HOUR_OF_DAY))
            .setMinutes(startCalendar.get(Calendar.MINUTE))
            .setSeconds(startCalendar.get(Calendar.SECOND))
            .build();

    TransferJob transferJob =
        TransferJob.newBuilder()
            .setDescription(jobDescription)
            .setProjectId(projectId)
            .setTransferSpec(
                TransferSpec.newBuilder()
                    .setGcsDataSource(GcsData.newBuilder().setBucketName(gcsSourceBucket))
                    .setGcsDataSink(GcsData.newBuilder().setBucketName(gcsNearlineSinkBucket))
                    .setObjectConditions(
                        ObjectConditions.newBuilder()
                            .setMinTimeElapsedSinceLastModification(
                                Duration.newBuilder().setSeconds(2592000 /* 30 days */)))
                    .setTransferOptions(
                        TransferOptions.newBuilder().setDeleteObjectsFromSourceAfterTransfer(true)))
            .setSchedule(Schedule.newBuilder().setScheduleStartDate(date).setStartTimeOfDay(time))
            .setStatus(Status.ENABLED)
            .build();

    // Create a Transfer Service client
    StorageTransferServiceClient storageTransfer = StorageTransferServiceClient.create();

    // Create the transfer job
    TransferJob response =
        storageTransfer.createTransferJob(
            CreateTransferJobRequest.newBuilder().setTransferJob(transferJob).build());

    System.out.println("Created transfer job from standard bucket to Nearline bucket:");
    System.out.println(response.toString());
  }
}

Python

מחפשים דוגמאות ישנות יותר? מדריך להעברת נתונים באמצעות Storage Transfer Service

from datetime import datetime

from google.cloud import storage_transfer
from google.protobuf.duration_pb2 import Duration


def create_daily_nearline_30_day_migration(
    project_id: str,
    description: str,
    source_bucket: str,
    sink_bucket: str,
    start_date: datetime,
):
    """Create a daily migration from a GCS bucket to a Nearline GCS bucket
    for objects untouched for 30 days."""

    client = storage_transfer.StorageTransferServiceClient()

    # The ID of the Google Cloud Platform Project that owns the job
    # project_id = 'my-project-id'

    # A useful description for your transfer job
    # description = 'My transfer job'

    # Google Cloud Storage source bucket name
    # source_bucket = 'my-gcs-source-bucket'

    # Google Cloud Storage destination bucket name
    # sink_bucket = 'my-gcs-destination-bucket'

    transfer_job_request = storage_transfer.CreateTransferJobRequest(
        {
            "transfer_job": {
                "project_id": project_id,
                "description": description,
                "status": storage_transfer.TransferJob.Status.ENABLED,
                "schedule": {
                    "schedule_start_date": {
                        "day": start_date.day,
                        "month": start_date.month,
                        "year": start_date.year,
                    }
                },
                "transfer_spec": {
                    "gcs_data_source": {
                        "bucket_name": source_bucket,
                    },
                    "gcs_data_sink": {
                        "bucket_name": sink_bucket,
                    },
                    "object_conditions": {
                        "min_time_elapsed_since_last_modification": Duration(
                            seconds=2592000  # 30 days
                        )
                    },
                    "transfer_options": {
                        "delete_objects_from_source_after_transfer": True
                    },
                },
            }
        }
    )

    result = client.create_transfer_job(transfer_job_request)
    print(f"Created transferJob: {result.name}")

אימות של אובייקטים שהועתקו

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

  • מוודאים שהאובייקטים הועתקו בצורה נכונה על ידי אימות המטא-נתונים של האובייקטים, כמו סכומי ביקורת וגודל.

  • מוודאים שהעתקתם את הגרסה הנכונה של האובייקטים. ‫Storage Transfer Service מציע אפשרות מוכנה מראש לאימות של העתקת אובייקטים. אם הפעלתם רישום ביומן, תוכלו לצפות ביומנים כדי לוודא שכל האובייקטים הועתקו בהצלחה, כולל שדות המטא-נתונים התואמים שלהם.

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

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

מחיקת הקטגוריה המקורית

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

ב-Storage Transfer Service יש אפשרות למחוק אובייקטים אחרי שהם הועברו. כדי לעשות את זה, צריך לציין deleteObjectsFromSourceAfterTransfer: true בהגדרות העבודה או לבחור באפשרות במסוף Google Cloud .

תזמון מחיקה של אובייקט

כדי לתזמן את המחיקה של האובייקטים לתאריך מאוחר יותר, משתמשים בשילוב של משימת העברה מתוזמנת והאפשרות deleteObjectsUniqueInSink = true.

צריך להגדיר את העברת הנתונים כך שהיא תעביר קטגוריה ריקה לקטגוריה שמכילה את האובייקטים. כתוצאה מכך, Storage Transfer Service יציג את רשימת האובייקטים ויתחיל למחוק אותם. מכיוון שמחיקות הן פעולות של מטא-נתונים בלבד, עבודת ההעברה מוגבלת רק על ידי QPS. כדי לזרז את התהליך, כדאי לפצל את ההעברה לכמה משימות, כשכל אחת מהן פועלת על קבוצה נפרדת של קידומות.

לחלופין, Google Cloud מציעה מתזמן משימות cron מנוהל. מידע נוסף זמין במאמר תזמון של משימת העברה של Google Cloud STS באמצעות Cloud Scheduler.