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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מגבלת זמן החיים של העברה

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

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

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

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

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

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

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

הגדרת Storage Intelligence

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

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

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

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

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

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

• איך מעבירים קטגוריות