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

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

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

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

בודקים את התכונות שלא נתמכות ואת דרישות התאימות

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

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

תכונות שלא נתמכות

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

תכונה סטטוס התאימות פעולה נדרשת לפני התחלת ההעברה של ה-bucket
מרחב שמות היררכי לא ניתן להשתמש באפשרות הזו להעברת דליים עם זמן השבתה לכתיבה. אם בקטגוריה מופעל מרחב שמות היררכי, אפשר להעביר אותה רק אם התהליך לא כולל השבתה של פעולות כתיבה
Appspot buckets לא נתמך. אי אפשר להעביר מיקומי אחסון מסוג Appspot. כפתרון עקיף לדליים שנוצרו כברירת מחדל על ידי App Engine, כדאי לשקול העברה של Container Registry אל Artifact Registry.
מאגרי מידע ב-Firebase לא נתמך. אי אפשר להעביר מאגרי Firebase.
החזקות אובייקטים לא נתמך.
אי אפשר להעביר קטגוריות שמכילות אובייקטים עם הקפאות.		 כדי להשתמש בהעברה של קטגוריות, צריך להסיר את ההשהיות של האובייקטים.
תיקיות מנוהלות לא נתמך.
אי אפשר להעביר מיקומי אחסון שמכילים תיקיות מנוהלות.		 כדי להשתמש בהעברה של קטגוריות, צריך למחוק את התיקיות המנוהלות.
מפתחות הצפנה בניהול הלקוח (CMEK) או מפתחות הצפנה באספקת הלקוח (CSEK) לא נתמך במעברים עם זמן השבתה לכתיבה. כדי להשתמש בהעברה של דלי, צריך להסיר את מפתחות ההצפנה בניהול הלקוח או את מפתחות ההצפנה באספקת הלקוח. אחרי ההסרה, Cloud Storage מגן על הנתונים שלכם באופן אוטומטי באמצעות ההצפנה הסטנדרטית של Cloud Storage.
Anywhere Cache יש תמיכה בהעברת מיקום של קטגוריות ללא השבתה של פעולות כתיבה, ותמיכה חלקית בהעברת מיקום של קטגוריות עם השבתה של פעולות כתיבה. אם מעבירים מאגרי מידע עם זמן השבתה לכתיבה, צריך להשבית את Anywhere Cache לפני שלב הסנכרון הסופי.
נעילת קטגוריה האפשרות הזו לא אפשרית כשכללי מדיניות שמירת הנתונים נעולים. ביטול הנעילה של מדיניות שמירת הנתונים.
תגים לא נתמך במעברים עם זמן השבתה לכתיבה.

צריך לנתק תגים שמצורפים ישירות לקטגוריה.

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

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

תאימות של תכונות במהלך העברה של דלי

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

תכונה העברה עם זמן השבתה לכתיבה העברה ללא זמן השבתה לכתיבה
אופן הפעולה של הסיווג האוטומטי הסיווג האוטומטי מושהה באופן זמני במהלך שלב הסנכרון הסופי. יכול להיות שההשהיה תגרום לעיכוב בהעברת אובייקטים לסוגי אחסון בשימוש נדיר יותר. מידע נוסף זמין במאמר מעברים של אובייקטים בסיווג אוטומטי כשמעבירים קטגוריות. אופן הפעולה של סיווג אוטומטי לא מושפע.
טבלאות ב-BigQuery וב-BigLake לאחר העברה, לא ניתן לגשת לטבלאות חיצוניות של BigLake ולטבלאות BigQuery באמצעות Apache Iceberg, וצריך ליצור אותן מחדש באופן ידני. אי אפשר לזהות באופן אוטומטי את הטבלאות שמושפעות מהבעיה. יש תמיכה.
מגבלת גודל האובייקט יש מגבלה של 2TB על גודל האובייקטים. אין מגבלת גודל.
העלאות מרובות חלקים התאימות וההתנהגות של העלאות מרובות חלקים תלויות בסטטוס של ההעלאה כשמתחילים להעביר את הדלי:
  • העלאות חדשות מרובות חלקים: לא אפשרי.
    התחלת העלאה מרובת חלקים אחרי שההעברה התחילה לא אפשרית, ולכן ההעלאה לא תתחיל. ניסיון ההעלאה של קובץ מרובה חלקים נכשל עם שגיאה FAILED_PRECONDITION.
  • העלאות מרובות חלקים בתהליך: לא נתמכות.
    העלאות מרובות חלקים שנמצאות בתהליך ולא הושלמו לפני שלב הסנכרון הסופי, חוסמות את סיום ההעברה. אחרי שמסיימים או מבטלים את ההעלאה מרובת החלקים שנמצאת בתהליך, אפשר לנסות שוב את שלב הסיום.
  • העלאות מרובות חלקים שהושלמו: נתמך.
    אם העלאה מרובת חלקים מתחילה לפני תחילת ההעברה של הדלי ומסתיימת לפני שלב הסנכרון הסופי, האובייקטים שהועלו מועברים בלי שצריך להעלות אותם מחדש.
 התאימות וההתנהגות של העלאות מרובות חלקים תלויות בסטטוס של ההעלאה כשמתחילים להעביר את הדלי:
  • העלאות חדשות מרובות חלקים: לא אפשרי.
    התחלת העלאה מרובת חלקים אחרי שההעברה התחילה לא אפשרית, ולכן ההעלאה לא תתחיל. ניסיון ההעלאה של קובץ מרובה חלקים נכשל עם שגיאה FAILED_PRECONDITION.
  • העלאות מרובות חלקים בתהליך: לא נתמכות.
    לפני שמתחילים בהעברת הדלי, צריך להשלים או לבטל את כל ההעלאות מרובות החלקים שנמצאות בתהליך.
  • העלאות מרובות חלקים שהושלמו: נתמך.
העלאות שניתן להמשיך לא נתמך.
כדי למנוע אובדן נתונים, צריך להשלים העלאות שניתן להמשיך, לפני השלב האחרון בתהליך של העברת הקטגוריה.		 יש תמיכה.
העברה בין פרויקטים לא נתמך.
אי אפשר להעביר דליים בין פרויקטים.		 יש תמיכה.
עדכוני מטא-נתונים לא נתמך.
אי אפשר לעדכן את המטא-נתונים של קטגוריה במהלך העברה.		 יש תמיכה.
הגדלה הדרגתית של קצב הבקשות ההנחיות לגבי הגדלת קצב הבקשות חלות על מאגרי מידע שהועברו בדיוק כמו על מאגרי מידע חדשים. לא רלוונטי.

ניתוח המאפיינים של הדלי

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

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

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

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

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

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

הגדרת יעדי ההעברה

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

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

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

  • שיפור האמינות: שיפור העמידות של הנתונים ויכולות תוכנית התאוששות מאסון (DR) באמצעות שימוש בהגדרות של שני אזורים או במספר אזורים.

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

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

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

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

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

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

הסבר על הגורמים שמשפיעים על משך ההעברה

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

מגבלות על שירותי רילוקיישן

בטבלה הבאה מפורטות המגבלות שמשפיעות על זמן ההעברה:

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

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

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

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

רוחב פס מקסימלי לכל אובייקט

‫8 MBps זו המהירות המקסימלית שבה אפשר להעביר אובייקט יחיד.

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

מספר ההעברות המקסימלי בו-זמנית לכל פרויקט

‫30 העברות שירות ההעברה של קטגוריות תומך בעד 30 העברות בו-זמניות מאותו מיקום בתוך פרויקט.

מגבלת אורך חיים (TTL) של העברה

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

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

אם תהליך ההעברה חורג ממגבלת ה-TTL של 28 ימים, פעולת ההעברה נכשלת.

פעילות מתמשכת בדלי

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

כללים של מחזור החיים

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

הגדרת Storage Intelligence

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

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

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

בדיקת מכסות ומגבלות

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

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