אפשר להשתמש ב-Storage Transfer Service כדי להעביר כמויות גדולות של נתונים בין קטגוריות של Cloud Storage, באותו פרויקט בענן ב-Google Cloud או בין פרויקטים שונים.
העברות של קטגוריות שימושיות במספר תרחישים. אפשר להשתמש בהן כדי לאחד נתונים מפרויקטים נפרדים, להעביר נתונים למיקום גיבוי או לשנות את המיקום של הנתונים.
מתי כדאי להשתמש ב-Storage Transfer Service
Google Cloud מציע כמה אפשרויות להעברת נתונים בין קטגוריות של Cloud Storage. מומלץ לפעול לפי ההנחיות הבאות:
העברה של פחות מ-1TB: משתמשים ב-
gcloud. הוראות מפורטות מופיעות במאמר העברה ושינוי שם של קטגוריות.העברת נתונים בנפח של יותר מ-1TB: צריך להשתמש ב-Storage Transfer Service. Storage Transfer Service הוא אפשרות העברה מנוהלת שמספקת אבטחה, אמינות וביצועים מוכנים לשימוש. היא מייתרת את הצורך לבצע אופטימיזציה של סקריפטים ולתחזק אותם, וגם את הצורך לטפל בניסיונות חוזרים.
במדריך הזה מוסברות שיטות מומלצות להעברת נתונים בין קטגוריות של Cloud Storage באמצעות Storage Transfer Service.
הגדרת אסטרטגיית העברה
האסטרטגיה להעברה תלויה במורכבות של המצב. חשוב לכלול בתוכנית את השיקולים הבאים.
בחירת שם ל-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)
לפרטים נוספים, אפשר לעיין בהפניית API של TransferSpec.
שדות המטא-נתונים הבאים לא נשמרים:
- שעת העדכון האחרון (
updated) etagcomponentCount
אם שומרים את זמן היצירה של האובייקט, הוא מאוחסן כשדה מותאם אישית, customTime. הזמן updated של האובייקט מאופס בהעברה, ולכן גם הזמן שהאובייקט נמצא בסוג האחסון שלו מאופס. המשמעות היא שאובייקט ב-Coldline Storage, אחרי ההעברה, צריך להיות קיים שוב במשך 90 ימים ביעד כדי להימנע מחיובים על מחיקה מוקדמת.
אפשר להחיל את מדיניות מחזור החיים שמבוססת על createTime באמצעות customTime. ערכים קיימים של customTime מוחלפים.
לפרטים נוספים על מה נשמר ומה לא, אפשר לעיין במאמר בנושא שמירת מטא-נתונים.
טיפול באובייקטים עם גרסאות
אם רוצים להעביר את כל הגרסאות של אובייקטים באחסון ולא רק את הגרסה האחרונה, אפשר להשתמש בתכונת המניפסט של Storage Transfer Service.
כדי להעביר את כל גרסאות האובייקט:
מציגים את רשימת האובייקטים בקטגוריה ומעתיקים אותם לקובץ JSON:
gcloud storage ls --all-versions --recursive --json [SOURCE_BUCKET] > object-listing.jsonבדרך כלל הפקודה הזו מציגה כ-1,000 אובייקטים בשנייה.
מעתיקים את האובייקטים שלא עדכניים לקובץ CSV:
jq -r '.[] | select( .type=="cloud_object" and (.metadata | has("timeDeleted"))) | [.metadata.name, .metadata.generation] | @csv' object-listing.json > non-current-object-manifest.csvמפעילים ניהול גרסאות של אובייקטים בקטגוריית היעד.
העברה של גרסאות לא עדכניות באמצעות אפשרויות ההעברה הבאות:
- מציינים את קובץ המניפסט.
- בוחרים באפשרות להחליף תמיד אובייקטים ב-sink (
OVERWRITE_WHEN=always). שימו לב שבמקרים נדירים, הפעולה הזו עלולה ליצור גרסאות כפולות של קובץ. - שמירה של המטא-נתונים של
timeCreated(MetdataOptions.timeCreated=TIME_CREATED_PRESERVE_AS_CUSTOM_TIME).
מעבירים את הגרסאות הפעילות באמצעות עבודת העברה רגילה.
הגדרת אפשרויות ההעברה
אלה חלק מהאפשרויות שזמינות לכם כשאתם מגדירים את ההעברה:
רישום ביומן: Cloud Logging מספק יומנים מפורטים של אובייקטים ספציפיים, שמאפשרים לכם לאמת את סטטוס ההעברה ולבצע בדיקות נוספות של תקינות הנתונים.
סינון: אתם יכולים להשתמש בקידומות של הכללה והחרגה כדי להגביל את האובייקטים ש-Storage Transfer Service פועל עליהם. אפשר להשתמש באפשרות הזו כדי לפצל העברה לכמה משימות העברה, כך שהן יוכלו לפעול במקביל. מידע נוסף זמין במאמר בנושא אופטימיזציה של מהירות ההעברה.
אפשרויות העברה: אתם יכולים להגדיר את ההעברה כך שתחליף פריטים קיימים בקטגוריית היעד, שתמחק אובייקטים ביעד שלא קיימים בקבוצת ההעברה או שתמחק אובייקטים שהועברו מהמקור.
העברת הנתונים
אחרי שמגדירים את אסטרטגיית ההעברה, אפשר לבצע את ההעברה עצמה.
יצירת קטגוריה חדשה
לפני שמתחילים בהעברה, יוצרים קטגוריית אחסון. במאמר location_considerations מוסבר איך לבחור מיקום מתאים לקטגוריה.
יכול להיות שתרצו להעתיק חלק ממטא-הנתונים של הקטגוריה כשתיצרו את הקטגוריה החדשה. במאמר אחזור מטא-נתונים של קטגוריה מוסבר איך להציג את המטא-נתונים של קטגוריית המקור, כדי שתוכלו להחיל את אותן ההגדרות על הקטגוריה החדשה.
העתקת אובייקטים לקטגוריה החדשה
אפשר להעתיק אובייקטים מקטגוריית המקור לקטגוריה חדשה באמצעותGoogle Cloud המסוף, gcloudCLI, 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 כדי לאתחל את הכלי ולציין את מזהה הפרויקט ואת חשבון המשתמש. פרטים נוספים מופיעים במאמר בנושא אתחול ה-CLI של gcloud.
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.