אפשר להשתמש ב-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 הנוכחי. האופן שבו עושים את זה תלוי באופן שבו האפליקציות בנויות ונפרסות.
במקרים מסוימים, הגישה הזו עשויה להוביל להשבתה קצרה יותר, אבל היא דורשת יותר עבודה כדי להבטיח מעבר חלק. התהליך כולל את השלבים הבאים:
- העתקת הנתונים שלכם לקטגוריית אחסון חדשה.
- השעות השקטות מתחילות.
- עדכון האפליקציות כך שיצביעו על הקטגוריה החדשה.
- מוודאים שהכול פועל כצפוי, ושכל המערכות והחשבונות הרלוונטיים מקבלים גישה למאגר.
- מחיקת קטגוריית המקור.
- סיום השעות השקטות.
שמירת שם הקטגוריה
מומלץ להשתמש בגישה הזו אם אתם לא רוצים לשנות את הקוד כך שיצביע על שם חדש של מאגר. התהליך כולל את השלבים הבאים:
- העתקת הנתונים לקטגוריית אחסון זמנית.
- השעות השקטות מתחילות.
- מחיקת קטגוריית המקור.
- יצירת קטגוריה חדשה עם אותו שם כמו הקטגוריה המקורית.
- העתקת הנתונים לקטגוריה החדשה מהקטגוריה הזמנית.
- מחיקת הקטגוריה הזמנית.
- מוודאים שהכול פועל כצפוי, ושכל המערכות והחשבונות הרלוונטיים מקבלים גישה למאגר.
- סיום השעות השקטות.
צמצום זמן ההשבתה
Storage Transfer Service לא נועל קריאות או כתיבות בקטגוריות המקור או היעד במהלך ההעברה.
אם בוחרים לנעול ידנית את פעולות הקריאה והכתיבה בדלי, אפשר לצמצם את זמן ההשבתה על ידי העברת הנתונים בשני שלבים: אתחול וסנכרון.
העברת נתונים ראשונית: ביצוע העברה בכמות גדולה בלי לנעול את הגישה לקריאה ולכתיבה במקור.
העברת סנכרון: אחרי שההרצה הראשונה מסתיימת, נועלים את הגישה לקריאה ולכתיבה בדלי המקור ומבצעים העברה נוספת. ההעברות של 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) etagcomponentCount
אם הוא נשמר, זמן יצירת האובייקט מאוחסן כשדה מותאם אישית, customTime. הזמן של האובייקט updated מתאפס בהעברה, ולכן גם הזמן שחלף מאז שהאובייקט הועבר לסוג האחסון שלו מתאפס. המשמעות היא שאובייקט ב-Coldline Storage, אחרי ההעברה, צריך להתקיים שוב במשך 90 ימים ביעד כדי להימנע מחיובים על מחיקה מוקדמת.
אפשר להחיל את מדיניות מחזור החיים שמבוססת על createTime באמצעות customTime. הערכים הקיימים של customTime מוחלפים.
לפרטים נוספים על מה שנשמר ומה שלא, אפשר לעיין במאמר בנושא שמירת מטא-נתונים.
טיפול באובייקטים עם גרסאות
אם רוצים להעביר את כל הגרסאות של אובייקטים באחסון ולא רק את הגרסה האחרונה, צריך להשתמש ב-gcloudCLI או ב-API בארכיטקטורת REST כדי להעביר את הנתונים, בשילוב עם תכונת המניפסט של Storage Transfer Service.
כדי להעביר את כל הגרסאות של האובייקט:
מציגים את רשימת האובייקטים בקטגוריה ומעתיקים אותם לקובץ JSON:
gcloud storage ls --all-versions --recursive --json [SOURCE_BUCKET] > object-listing.jsonבדרך כלל הפקודה הזו מציגה כ-1,000 אובייקטים בשנייה.
פיצול קובץ ה-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הפעלת ניהול גרסאות של אובייקטים בקטגוריית היעד.
מעבירים קודם את הגרסאות שלא עדכניות על ידי העברת קובץ המניפסט
non-current-object-manifest.csvבתור הערך של השדהtransferManifest.לאחר מכן, מעבירים את הגרסאות הפעילות באותה דרך, ומציינים את הקובץ
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 :
פותחים את הדף 'העברה' במסוף Google Cloud .
- לוחצים על Transfer.
פועלים לפי ההוראות המפורטות בלחיצה על Next Step בכל שלב:
תחילת העבודה: משתמשים ב-Google Cloud Storage גם כסוג המקור וגם כסוג היעד.
בחירת מקור: מזינים ישירות את השם של הקטגוריה הרצויה או לוחצים על Browse כדי לחפש את הקטגוריה הרצויה ולבחור אותה.
בחירת יעד: מזינים ישירות את השם של הקטגוריה הרצויה או לוחצים על Browse כדי לחפש את הקטגוריה הרצויה ולבחור אותה.
בחירת הגדרות: בוחרים באפשרות Delete files from source after they're transferred.
אפשרויות תזמון: אפשר להתעלם מהסעיף הזה.
אחרי שמסיימים את ההדרכה המפורטת לוחצים על Create.
כך תתחיל העתקת האובייקטים מהקטגוריה הישנה אל הקטגוריה החדשה. התהליך עשוי להימשך לא מעט זמן. אבל אחרי שלוחצים על Create, אפשר לצאת ממסוף Google Cloud .
כדי להציג את התקדמות ההעברה:
פותחים את הדף 'העברה' במסוף Google Cloud .
במאמר פתרון בעיות מוסבר איך מקבלים מידע מפורט על שגיאות בנושא פעולות ב-Storage Transfer Service שנכשלו במסוף Google Cloud .
אם סימנתם את תיבת הסימון 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
Python
מחפשים דוגמאות ישנות יותר? מדריך להעברת נתונים באמצעות Storage Transfer Service
אימות של אובייקטים שהועתקו
אחרי שההעברה מסתיימת, מומלץ לבצע בדיקות נוספות של תקינות הנתונים.
מוודאים שהאובייקטים הועתקו בצורה נכונה על ידי אימות המטא-נתונים של האובייקטים, כמו סכומי ביקורת וגודל.
מוודאים שהעתקתם את הגרסה הנכונה של האובייקטים. 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.