לפני העברת מאגר, כדאי לבדוק את השימוש במאגר ולתכנן מראש את זמן ההשבתה האפשרי. תכנון ההעברה גם עוזר לשמור על תאימות הנתונים ולשלוט בעלויות האחסון.
בקטעים הבאים מתוארים שלבי התכנון.
קביעת סוג ההעברה של הקטגוריה
כשמעבירים את הדלי, חשוב להבין שייתכן שיהיה זמן השבתה לכתיבה במהלך שלב הסנכרון הסופי, שבמהלכו לא תוכלו לעדכן או להעלות אובייקטים חדשים. בנוסף, לא תוכלו לשנות את ההגדרות של הדלי במהלך תהליך ההעברה. כדי לדעת אם המעבר שלכם כולל השבתה, אפשר לעיין במאמר בנושא סוגי מעברים.
בדיקת התכונות שלא נתמכות ודרישות התאימות
מזהים הגדרות בקטגוריית המקור שלא תומכות בהעברה של קטגוריות, והגדרות שנדרשת פעולה כדי לתמוך בהעברה של קטגוריות. אם הקטגוריה שלכם משתמשת בהגדרות לא נתמכות שאי אפשר לשנות, או אם המקור או היעד הם מיקום לא נתמך, אתם צריכים להעתיק ידנית את האובייקטים לקטגוריה אחרת במיקום היעד, במקום להעביר את הקטגוריה עם האובייקטים שלה. פרטים נוספים זמינים במאמר העברת נתונים בין קטגוריות.
בקטעים הבאים מפורטות התכונות שלא נתמכות ודרישות התאימות.
תכונות שלא נתמכות
בטבלה הבאה מתוארות התכונות שלא תואמות להעברה של מאגרי מידע. במקרים מסוימים, אפשר להגדיר מחדש תכונה כדי לתמוך בהעברה של מאגרי מידע:
| תכונה | סטטוס התאימות | פעולה נדרשת לפני התחלת ההעברה של ה-bucket |
|---|---|---|
| מרחב שמות היררכי | אין תמיכה בהעברת דליים עם זמן השבתה לכתיבה. | אם בקטגוריה מופעל מרחב שמות היררכי, אפשר להעביר אותה רק אם התהליך לא כולל זמן השבתה של כתיבה |
| Appspot buckets | לא נתמך. | אי אפשר להעביר מיקומי אחסון מסוג Appspot. כפתרון עקיף לדלי ברירת המחדל שנוצר על ידי App Engine, כדאי להעביר את Container Registry אל Artifact Registry. |
| מאגרי מידע ב-Firebase | לא נתמך. | אי אפשר להעביר את דלי הנתונים של Firebase. |
| החזקות אובייקטים | לא נתמך. אי אפשר להעביר קטגוריות שמכילות אובייקטים עם הקפאות. |
כדי להשתמש בהעברה של קטגוריות, צריך להסיר את ההשהיות של האובייקטים. |
| תיקיות מנוהלות | לא נתמך. אי אפשר להעביר מיקומי אחסון שמכילים תיקיות מנוהלות. |
כדי להשתמש בהעברה של קטגוריות, צריך למחוק את התיקיות המנוהלות. |
| מפתחות הצפנה בניהול הלקוח (CMEK) או מפתחות הצפנה באספקת הלקוח (CSEK) | לא נתמך במעברים עם זמן השבתה לכתיבה. | כדי להשתמש בהעברה של דלי, צריך להסיר את מפתחות ההצפנה בניהול הלקוח או את מפתחות ההצפנה באספקת הלקוח. אחרי ההסרה, Cloud Storage מגן על הנתונים שלכם באופן אוטומטי באמצעות ההצפנה הסטנדרטית של Cloud Storage. |
| Rapid Cache | האפשרות הזו לא נתמכת בהעברות של מאגרי מידע ללא השבתה של פעולות כתיבה, ונתמכת באופן חלקי בהעברות של מאגרי מידע עם השבתה של פעולות כתיבה. | כדי להעביר דליים בלי זמן השבתה של כתיבה, צריך להשבית את Rapid Cache לפני שמתחילים בהעברה. אם מעבירים דליים עם זמן השבתה לכתיבה, צריך להשבית את Rapid Cache לפני שלב הסנכרון הסופי. |
| נעילת קטגוריות | האפשרות הזו לא נתמכת בדליים עם מדיניות שימור פעילה. אם מדיניות שמירת הנתונים נעולה (Bucket Lock מופעל), אי אפשר לבטל את המדיניות. לכן, Cloud Storage לא תומך בהעברה של הקטגוריה. | אם מדיניות שמירת הנתונים לא נעולה, צריך להסיר את המדיניות לפני שממשיכים בהעברה. |
| נעילת שימור אובייקטים | לא נתמך. אחרי שמפעילים את נעילת השמירה של אובייקט, אי אפשר להשבית אותה. | אי אפשר להעביר קטגוריות שמופעל בהן נעילת שמירת אובייקטים. |
| תגים | לא נתמך במעברים עם זמן השבתה לכתיבה. |
צריך לנתק תגים שמצורפים ישירות לקטגוריה. אם נעשה שימוש בתגים כלשהם שמנותקים מקטגוריית המקור לצורך בקרת גישה, תצטרכו להשתמש בשיטה חלופית כדי להגדיר את תפקידי ה-IAM לאבטחת הנתונים בקטגוריה. כדי לעשות זאת, מבצעים את השלבים הבאים:
|
| הגדרות של דוחות מלאי | ההגדרות הקיימות של דוח המלאי לא נשמרות במהלך תהליך ההעברה. | לפני שמתחילים את תהליך ההעברה, צריך לשמור באופן ידני את ההגדרות הקיימות של דוחות המלאי, כדי שאפשר יהיה ליצור אותן מחדש אחרי שתהליך ההעברה יסתיים. מידע על ניהול הגדרות של דוחות מלאי זמין במאמר יצירה וניהול של הגדרות של דוחות מלאי. |
תאימות של תכונות במהלך שינוי מיקום הקטגוריות
בטבלה הבאה מוסבר איך יכולות אחרות של Cloud Storage פועלות כשמעבירים מיקום של באקט. ההתנהגות עשויה להשתנות בהתאם למצב ההעברה:
| תכונה | העברה עם זמן השבתה לכתיבה | העברה ללא זמן השבתה לכתיבה |
|---|---|---|
| התנהגות הסיווג האוטומטי | הסיווג האוטומטי מושהה באופן זמני במהלך שלב הסנכרון הסופי. יכול להיות שההשהיה תגרום לעיכוב בהעברת אובייקטים לסוגי אחסון בשימוש נדיר יותר. מידע נוסף זמין במאמר מעברים של אובייקטים בסיווג אוטומטי כשמעבירים קטגוריות. | אין שינוי בהתנהגות של סיווג אוטומטי. |
| טבלאות ב-BigQuery וב-BigLake | לאחר העברה, לא ניתן לגשת לטבלאות חיצוניות של BigLake ולטבלאות של BigQuery באמצעות Apache Iceberg, וצריך ליצור אותן מחדש באופן ידני. אי אפשר לזהות באופן אוטומטי את הטבלאות שמושפעות מהבעיה. | יש תמיכה |
| מגבלת גודל של אובייקט | יש מגבלה של 2TB על גודל האובייקטים. | אין הגבלת גודל. |
| העלאות מרובות חלקים |
התאימות וההתנהגות של העלאות מרובות חלקים תלויות בסטטוס של ההעלאה כשמתחילים להעביר את הדלי:
|
התאימות וההתנהגות של העלאות מרובות חלקים תלויות בסטטוס של ההעלאה כשמתחילים להעביר את הדלי:
|
| העלאות שניתן להמשיך | לא נתמך. כדי למנוע אובדן נתונים, צריך להשלים העלאות שניתן להמשיך שהן בתהליך לפני השלב האחרון של סנכרון בתהליך העברת הקטגוריה. |
יש תמיכה |
| העברה בין פרויקטים | לא נתמך. אי אפשר להעביר דליים בין פרויקטים. |
יש תמיכה |
| עדכוני מטא-נתונים | לא נתמך. אי אפשר לעדכן את המטא-נתונים של קטגוריה במהלך העברה. |
יש תמיכה |
| הגדלה הדרגתית של קצב הבקשות | ההנחיות לגבי הגדלת קצב הבקשות חלות על מאגרי נתונים שהועברו בדיוק כמו על מאגרי נתונים חדשים. | לא רלוונטי. |
ניתוח המאפיינים של הדלי
כדי להעריך את משך הזמן שיידרש להעברת הקטגוריה, צריך לנתח את המאפיינים והשימוש שלה, תוך התחשבות בגורמים הבאים:
בייטים במצב מנוחה: הכמות הכוללת של הנתונים שמאוחסנים בקטגוריה משפיעה על עלויות האחסון ועל זמן ההעברה.
שכפול: שכפול הקטגוריה לאזורים אחרים, באופן סינכרוני או אסינכרוני, משפיע על הזמינות, העמידות והעלות של הנתונים. פרטים נוספים זמינים במאמר זמינות ועמידות של נתונים.
העברת נתונים: כמות הנתונים שמועברת מהקטגוריה במהלך ההעברה משפיעה על חישובי העלות של העברת הנתונים. כדי לחשב את עלויות העברת הנתונים של הקטגוריה, אפשר לעיין במחירון של Cloud Storage.
דפוסי שימוש: הבנת רמות הפעילות בדלי, או כמה הדלי עמוס, באמצעות דפוסי שימוש עוזרת למנוע התנגשויות לא צפויות במהלך ההעברה. כדי להבין את דפוסי השימוש בדלי, אפשר לנתח את היומנים. פרטים נוספים זמינים במאמר בנושא יומני שימוש ויומני אחסון.
פעולות כתיבה של מאגרי מידע: פעולות כתיבה תכופות של מאגרי מידע במהלך תהליך ההעברה מגדילות את העלות ואת משך הזמן. ההתקדמות בהעברה לא לינארית ואי אפשר לחזות אותה. אל תשתמשו במשך הזמן של העברות קטנות כדי להעריך את הזמן שנדרש להעברות גדולות יותר. כדי לעקוב אחרי התדירות שבה נכתבים אובייקטים בקטגוריה, אפשר לעיין במאמר סקירה כללית על מעקב ב-Cloud Storage.
הגדרת יעדי ההעברה
על סמך הניתוח של מאפייני הדלי, מזהים את הסיבות להעברת הדלי. אלה יעדים נפוצים להעברת קטגוריה:
ניהול עלויות: אפשר להפחית את עלויות האחסון על ידי מעבר לאזור עם עלויות נמוכות יותר, או לצמצם את עלויות העברת הנתונים על ידי העברת הנתונים למיקום קרוב יותר למיקום הגישה. תצטרכו לחשב את העלויות של Cloud Storage והעברת נתונים ולהשוות אותן לעלויות פוטנציאליות במיקומים שונים. לפרטים על חישוב העלויות של Cloud Storage, ראו תמחור של Cloud Storage.
שיפור הביצועים: כדי לשפר את מהירות הגישה לנתונים ואת הביצועים של האפליקציה, אפשר להעביר את הדלי למיקום קרוב יותר למשתמשים או לאפליקציות. כדי לעשות זאת, צריך לזהות את האזורים הגיאוגרפיים שבהם הביצועים הם קריטיים, ואז להעביר את הקטגוריות.
שיפור המהימנות: שיפור העמידות של הנתונים והיכולות של התאוששות מאסון באמצעות שימוש בהגדרות של אזור כפול או רב-אזורי.
קובעים את המיקום של הקטגוריה
בהתאם לניתוח ולמטרות שלכם, בוחרים את מיקום האחסון המתאים ביותר לדלי שממנו מעבירים את הנתונים מבין האפשרויות הבאות:
אזור יחיד: אחסון נתונים באזור יחיד שחוסך עלויות לאפליקציות עם משתמשים שמרוכזים באזור גיאוגרפי אחד.
שני אזורים: שמירה של שני עותקים של הנתונים בשני אזורים באותה יבשת, כדי לספק זמינות גבוהה יותר ויכולות שחזור לאחר אסון באזור גיאוגרפי מסוים.
מספר אזורים: הנתונים מפוזרים בכמה אזורים, מה שמספק את הרמה הגבוהה ביותר של זמינות ועמידות.
מידע נוסף על בחירת מיקום זמין במאמר שיקולים לבחירת מיקום.
הסבר על הגורמים שמשפיעים על משך ההעברה
יש כמה גורמים שמשפיעים על זמן ההעברה, והבנתם יכולה לעזור להעריך את הזמן הנדרש. הגורמים האלה מספקים נקודת התחלה שימושית לתכנון ולתזמון של ההעברה, אבל משך ההעברה בפועל עשוי להיות ארוך או קצר יותר מהזמן המשוער. לכן, כשמתכננים את המעבר, כדאי להוסיף זמן להפסקה כדי להתחשב בעיכובים פוטנציאליים. בקטעים הבאים מתוארים הגורמים שמשפיעים על משך הזמן של ההעברה.
מגבלות על שירותי רילוקיישן
בטבלה הבאה מתוארות המגבלות שמשפיעות על זמן ההעברה:
| גורם | ערך | תיאור |
|---|---|---|
| קצב בקשות מקסימלי לכל עבודה | 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) למיקום חדש, צריך לוודא שיש במיקום החדש מכסות מספיקות כדי להכיל את הנתונים של המאגר. מידע נוסף על מכסות ומגבלות זמין במאמר מכסות ומגבלות.