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