לפני העברת מאגר, כדאי לבדוק את השימוש במאגר ולתכנן מראש את זמן ההשבתה האפשרי. תכנון ההעברה גם עוזר לשמור על תאימות הנתונים ולשלוט בעלויות האחסון.
בקטעים הבאים מתוארים שלבי התכנון.
קביעת סוג ההעברה של הקטגוריה
כשמעבירים את הדלי, חשוב להבין שייתכן שיהיה זמן השבתה לכתיבה במהלך שלב הסנכרון הסופי, שבמהלכו לא תוכלו לעדכן או להעלות אובייקטים חדשים. בנוסף, לא תוכלו לשנות את ההגדרות של הדלי במהלך תהליך ההעברה. כדי לדעת אם המעבר שלכם כולל השבתה, אפשר לעיין במאמר בנושא סוגי מעברים.
בודקים אילו תכונות לא נתמכות ואת דרישות התאימות
מזהים הגדרות בקטגוריית המקור שלא תומכות בהעברה של קטגוריות, והגדרות שנדרשת פעולה כדי לתמוך בהעברה של קטגוריות. אם הקטגוריה שלכם משתמשת בהגדרות לא נתמכות שאי אפשר לשנות, או אם המקור או היעד הם מיקום לא נתמך, אתם צריכים להעתיק ידנית את האובייקטים לקטגוריה אחרת במיקום היעד, במקום להעביר את הקטגוריה עם האובייקטים שלה. פרטים נוספים זמינים במאמר בנושא העברת נתונים בין קטגוריות.
בקטעים הבאים מפורטות התכונות שלא נתמכות ודרישות התאימות.
תכונות שלא נתמכות
בטבלה הבאה מתוארות התכונות שלא תואמות להעברה של מאגרי מידע. במקרים מסוימים, אפשר להגדיר מחדש תכונה כדי לתמוך בהעברה של מאגרי מידע:
| תכונה | סטטוס התאימות | פעולה נדרשת לפני התחלת ההעברה של ה-bucket |
|---|---|---|
| מרחב שמות היררכי | אין תמיכה בהעברת דליים עם זמן השבתה לכתיבה. | אם בקטגוריה מופעל מרחב שמות היררכי, אפשר להעביר אותה רק אם התהליך לא כולל השבתה של פעולות כתיבה |
| Appspot buckets | לא נתמך. | אי אפשר להעביר מיקומי אחסון מסוג Appspot. כפתרון עקיף לדלי ברירת המחדל שנוצר על ידי App Engine, כדאי להעביר את Container Registry אל Artifact Registry. |
| מאגרי מידע ב-Firebase | לא נתמך. | אי אפשר להעביר את דלי ה-Firebase. |
| החזקות אובייקטים | לא נתמך. אי אפשר להעביר קטגוריות שמכילות אובייקטים עם הקפאות. |
כדי להשתמש בהעברה של קטגוריות, צריך להסיר את ההשהיות של האובייקטים. |
| תיקיות מנוהלות | לא נתמך. אי אפשר להעביר מיקומי אחסון שמכילים תיקיות מנוהלות. |
כדי להשתמש בהעברת קטגוריות למיקום גיאוגרפי אחר, צריך למחוק את התיקיות המנוהלות. |
| מפתחות הצפנה בניהול הלקוח (CMEK) או מפתחות הצפנה באספקת הלקוח (CSEK) | לא אפשרי במעברים עם זמן השבתה לכתיבה. | כדי להשתמש בהעברת קטגוריות למיקום גיאוגרפי אחר, צריך להסיר את מפתחות ההצפנה בניהול הלקוח (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.
שיפור הביצועים: כדי לשפר את מהירות הגישה לנתונים ואת הביצועים של האפליקציה, אפשר להעביר את הדלי למיקום קרוב יותר למשתמשים או לאפליקציות. כדי לעשות זאת, צריך לזהות את האזורים הגיאוגרפיים שבהם הביצועים הם קריטיים, ואז להעביר את הקטגוריות.
שיפור המהימנות: שיפור העמידות של הנתונים והיכולות של תוכנית התאוששות מאסון (DR) באמצעות שימוש בהגדרות של שני אזורים או של כמה אזורים.
החלטה לגבי מיקום הדלי
על סמך הניתוח והיעדים שלכם, בוחרים את מיקום האחסון המתאים ביותר לדלי שממנו מעבירים את הנתונים מבין האפשרויות הבאות:
אזור יחיד: אחסון נתונים באזור יחיד שחוסך עלויות לאפליקציות עם משתמשים שמרוכזים באזור גיאוגרפי אחד.
שני אזורים: שמירה של שני עותקים של הנתונים בשני אזורים באותה יבשת, כדי לספק זמינות גבוהה יותר ויכולות תוכנית התאוששות מאסון (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
הפעלת מחיקה זמנית להעברות עם זמן השבתה לכתיבה
אם העברת קטגוריות למיקום גיאוגרפי אחר של ה-bucket כוללת זמן השבתה של פעולות כתיבה, צריך להפעיל מחיקה זמנית ב-bucket ולהגדיר את משך השמירה ל-7 ימים לפחות. משך השמירה הוא פרק הזמן שבו מחיקה רכה שומרת אובייקטים שנמחקו לפני שהם נמחקים לצמיתות. מידע על הגדרת משך השמירה של מחיקה רכה מופיע במאמר שימוש במחיקה רכה. כדי לדעת אם המעבר שלכם כולל השבתה, אפשר לעיין בסוגי המעברים.
בדיקת מכסות ומגבלות
הערכות של מכסות וקיבולת בענן קשורות לאזורים או לאזורי זמינות ספציפיים. לכן, כשמעבירים מאגר (bucket) למיקום חדש, צריך לוודא שיש במיקום החדש מכסות מספיקות כדי להכיל את הנתונים של המאגר. מידע נוסף על מכסות ומגבלות זמין במאמר מכסות ומגבלות.