ניהול מחזור חיים של אובייקטים

הגדרת ניהול מחזור חיים של אובייקטים דוגמאות להגדרות

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

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

מבוא

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

  • שדרוג לאחור של סוג האחסון (storage class) של אובייקטים מלפני יותר מ-365 ימים ל-Coldline Storage.
  • מחיקת אובייקטים שנוצרו לפני ה-1 בינואר 2019.
  • שמירה של רק 3 הגרסאות האחרונות של כל אובייקט בקטגוריה שבה מופעל ניהול גרסאות.

הגדרה של מחזור החיים

כל הגדרה של ניהול מחזור חיים מכילה רשימת כללים. כל כלל מכיל פעולה אחת ותנאי אחד או יותר.

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

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

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

    לדוגמה, אם יש כלל אחד שמשנה את המחלקה של האובייקט ל-Nearline Storage, וכלל אחר שמשנה את המחלקה של האובייקט ל-Coldline Storage, אבל שני הכללים משתמשים באותו התנאי, המחלקה של האובייקט תמיד משתנה ל-Coldline Storage כשמתקיים התנאי.

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

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

    לדוגמה, אם משנים תנאי של age מ-10 ימים ל-20 יום, אובייקט בן 11 יום עלול להימחק על ידי 'ניהול מחזור חיים של אובייקטים' עד 24 שעות מאוחר יותר, בגלל הקריטריונים של ההגדרה הישנה.

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

פעולות במחזור החיים

כלל מחזור חיים מציין בדיוק אחת מהפעולות הבאות:

Delete

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

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

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

SetStorageClass

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

‫SetStorageClass תומך במעברים הבאים בין סוגי אחסון (storage class):

סוג האחסון (storage class) המקורי סוג האחסון (storage class) החדש
אחסון עמיד בזמינות מופחתת (DRA) Nearline storage
Coldline storage
Archive storage
Multi-Regional storage/Regional storage1
Standard storage,‏ Multi-Regional storage או Regional storage Nearline storage
Coldline storage
Archive storage
Nearline Storage Coldline storage
Archive storage
Coldline Storage Archive Storage

1 לקטגוריות באזור, סוג האחסון (storage class) החדש לא יכול להיות Multi-Regional Storage. לקטגוריות במספר אזורים או בשני אזורים, סוג האחסון (storage class) החדש לא יכול להיות Regional Storage.

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

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

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

אפשר להשתמש רק בתנאים הבאים של מחזור החיים יחד עם הפעולה הזו:

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

תנאים של מחזור החיים

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

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

age

התנאי age מתקיים כשהמשאב מגיע לגיל שצוין (בימים). הגיל נמדד לפי זמן היצירה של המשאב.

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

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

  • בהעלאות מרובות חלקים, זמן היצירה הוא הזמן שבו מתחילה ההעלאה.

  • אם התנאי age מוגדר לערך 0, התנאי מתקיים בחצות (שעון UTC) אחרי שהאובייקט נוצר.

לדוגמה, אם משאב נוצר ב-10.1.2022 בשעה 10:00 (שעון UTC) והתנאי age הוא 10 ימים, התנאי מתקיים בשביל המשאב בתאריך 20.1.2022 מ-10:00 (שעון UTC) ואילך.

createdBefore

התנאי createdBefore מתקיים כשאובייקט נוצר לפני חצות בתאריך שצוין ב-UTC.

customTimeBefore

התנאי customTimeBefore מתקיים כשהתאריך במטא-נתונים של Custom-Time של אובייקט מוקדם יותר מהתאריך שצוין בתנאי הזה. התנאי הזה מוגדר באמצעות פורמט התאריך YYYY-MM-DD. ‫customTimeBefore אף פעם לא מתקיים לאובייקט שלא הוגדרו לו מטא-נתונים של Custom-Time.

daysSinceCustomTime

התנאי daysSinceCustomTime מתקיים כשחלפו מספר הימים שצוינו מאז התאריך והשעה שצוינו בשדה המטא-נתונים Custom-Time של האובייקט. לדוגמה, אם Custom-Time של אובייקט הוא 2020-05-16T10:00:00Z והתנאי daysSinceCustomTime הוא 10 ימים, אז התנאי מתקיים בשביל האובייקט בתאריך 26.5.2020 ב-10:00 (שעון UTC)

‫daysSinceCustomTime אף פעם לא מתקיים לאובייקט שלא הוגדרו לו מטא-נתונים של Custom-Time.

daysSinceNoncurrentTime

בדרך כלל משתמשים בתנאי daysSinceNoncurrentTime רק בשילוב עם ניהול גרסאות של אובייקטים. התנאי מתקיים כשחלפו מספר הימים שצוינו מאז שהאובייקט הפך ללא עדכני, כי הגרסה הפעילה נמחקה או הוחלפה. לדוגמה, אם אובייקט הוא לא עדכני ב-8.7.2020 בשעה 15:00 (שעון UTC) והתנאי daysSinceNoncurrentTime הוא 10 ימים, התנאי מתקיים בשביל האובייקט בתאריך 18.7.2020 בשעה 15:00 (שעון UTC) ואילך.

isLive

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

matchesPrefix וגם matchesSuffix

התנאים matchesPrefix ו-matchesSuffix מתקיימים כשההתחלה או הסוף של שם האובייקט מהווים התאמה מדויקת באותיות רישיות (case-sensitive) לקידומת או לסיומת שצוינו. אפשר לציין מספר מחרוזות כרשימה (לדוגמה, "matchesSuffix": [".jpg", ".png"]).

כשמשתמשים ב-matchesPrefix, לא כוללים את שם הקטגוריה או את ה-/ שקודם לשמות האובייקטים ברוב נתיבי הבקשות. לדוגמה, ב-Google Cloud CLI, הפורמט של הנתיב לאובייקט בקטגוריה בשם my_bucket דומה ל-gs://my_bucket/pictures/paris_2022.jpg. כדי לבצע התאמה לאובייקט, צריך להשתמש בתנאי כמו "matchesPrefix":["pictures/paris_"].

אפשר לציין עד 1,000 קידומות וסיומות בסך הכול בכל הכללים יחד. במסוף Google Cloud , אפשר להעתיק ולהדביק עד 1,000 קידומות או סיומות בסך הכול. אי אפשר להשתמש בקידומת או בסיומת פעמיים בתנאי יחיד.

matchesStorageClass

התנאי matchesStorageClass מתקיים כשאובייקט בקטגוריה מאוחסן כסוג האחסון (storage class) שצוין. אפשר להשתמש בערכים הבאים בשביל matchesStorageClass: STANDARD, NEARLINE, COLDLINE, ARCHIVE, MULTI_REGIONAL, REGIONAL ו-DURABLE_REDUCED_AVAILABILITY.

באופן כללי, אם מתכוונים להשתמש בתנאי matchesStorageClass באובייקטים של Standard Storage, צריך לכלול גם את הפרטים הבאים:

  • אם הקטגוריה נמצאת באזור, צריך לכלול את REGIONAL ואת DURABLE_REDUCED_AVAILABILITY בתנאי.

  • אם הקטגוריה נמצאת במספר אזורים או בשני אזורים, צריך לכלול את MULTI_REGIONAL ואת DURABLE_REDUCED_AVAILABILITY בתנאי.

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

noncurrentTimeBefore

בדרך כלל משתמשים בתנאי noncurrentTimeBefore רק בשילוב עם ניהול גרסאות של אובייקטים. התנאי מתקיים בשביל אובייקטים שהפסיקו להיות פעילים בתאריך שקודם לזה שצוין בתנאי הזה. התנאי מוגדר באמצעות פורמט התאריך YYYY-MM-DD. ‎noncurrentTimeBefore אף פעם לא תואם לאובייקט פעיל.

numNewerVersions

בדרך כלל משתמשים בתנאי numNewerVersions רק בשילוב עם ניהול גרסאות של אובייקטים. אם הערך של התנאי הזה הוא N, גרסת אובייקט עומדת בתנאי כאשר יש לפחות N גרסאות (כולל הגרסה הפעילה) חדשות יותר. בשביל גרסה פעילה של אובייקט, מספר הגרסאות החדשות יותר נחשב ל-0. בשביל הגרסה האחרונה שאינה עדכנית, מספר הגרסאות החדשות יותר הוא 1 (או 0 אם אין גרסה פעילה של האובייקט), וכן הלאה.

התנהגות מחזור החיים של אובייקט

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

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

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

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

  • האובייקט כפוף לכלל עם פעולת Delete.

  • התנאי היחיד לכלל הוא תנאי age או שילוב של התנאים age ו-matchesStorageClass.

  • התנאי age מתקיים בשביל האובייקט בכללים שכוללים רק תנאי גיל. אם כלל המחיקה כולל את שני התנאים age ו-matchesStorageClass, האובייקט צריך לעמוד בשני התנאים.

  • לאובייקט אין השהיות אובייקטים.

התנהגות מחזור החיים של אובייקט בגרסאות של אובייקטים

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

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

שיקולי עלות SetStorageClass

בדומה לשינוי ידני של סוג האחסון (storage class) של אובייקט, השימוש ב-SetStorageClass נחשב כפעולה Class A ומחויב לפי התעריף של סוג האחסון (storage class) של היעד.

בניגוד לשינוי ידני של סוג האחסון (storage class) של אובייקט, השימוש ב-SetStorageClass לא משכתב אובייקט. כך יש יתרון תמחור מסוים לניהול מחזור חיים של אובייקטים:

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

  • הזמן המוגדר לאובייקט בסוג האחסון (storage class) המקורי נחשב כחלק ממשך האחסון המינימלי שחל על סוג האחסון (storage class) החדש.

לדוגמה, נניח שמעלים אובייקט בתור Nearline Storage, ו-20 ימים לאחר מכן ההגדרה של מחזור החיים משנה את סוג האחסון (storage class) של האובייקט ל-Coldline Storage. שינוי זה לא כרוך בעמלות אחזור או בעמלות מחיקה מוקדמת. אם מוחקים את האובייקט 60 ימים אחרי השינוי של סוג האחסון (storage class), יחול רק חיוב על מחיקה מוקדמת של 10 ימים, כי ל-Coldline Storage יש משך אחסון מינימלי של 90 ימים, והאובייקט היה קיים רק במשך 80 ימים.

לשם השוואה, נניח שמעלים אובייקט כ-Nearline Storage, ו-20 ימים לאחר מכן משנים את סוג האחסון (storage class) באמצעות שכתוב (שוב ל-Coldline Storage). בעקבות השינוי הזה יהיו גם עמלת אחזור וגם חיוב על מחיקה מוקדמת של 10 ימים. אם מוחקים את האובייקט 60 ימים אחרי השכתוב, יחול חיוב על מחיקה מוקדמת של 30 ימים.

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

זמן יצירת האובייקט

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

  • אובייקט לא כפוף לכללי מחזור החיים עד לסיום ההעלאה שלו.
  • זמן היצירה של אובייקט מבוסס על מועד הסיום של ההעלאה. זה משפיע על התנאים age ו-createdBefore של מחזור החיים.
  • כשמגדירים Custom-Time לאובייקט, צריך לעשות זאת בתחילת ההעלאה. אם מגדירים Custom-Time לפי מועד הבקשה, ייתכן שה-Custom-Time יהיה מוקדם בהרבה מזמן היצירה של האובייקט. זה משפיע על התנאים customTimeBefore ו-daysSinceCustomTime של מחזור החיים.

מטא-נתונים של מועד התפוגה

אם צוינה פעולת Delete בקטגוריה עם התנאי age (בלי תנאים אחרים חוץ מ-matchesStorageClass), יכול להיות שחלק מהאובייקטים יתויגו עם זמן תפוגה במטא-נתונים. זמן התפוגה של האובייקט מציין את הזמן שבו האובייקט הופך (או הפך) לכשיר למחיקה על ידי ניהול מחזור החיים של האובייקט. זמן התפוגה עשוי להשתנות בהתאם לשינויים בהגדרה של מחזור החיים או במדיניות שמירת הנתונים של הקטגוריה.

שימו לב שאם חסרים מטא-נתונים לגבי זמן התפוגה, זה לא בהכרח אומר שהאובייקט לא יימחק, אלא שאין מספיק מידע זמין כדי לקבוע מתי או אם הוא יימחק. לדוגמה, אם זמן היצירה של האובייקט הוא 10.1.2020 בשעה 10:00 (שעון UTC) והתנאי age מוגדר ל-10 ימים, אז זמן התפוגה של האובייקט הוא 20.1.2020 בשעה 10:00 (שעון UTC). אבל, זמן התפוגה לא זמין לאובייקט אם:

  • ישנם תנאים אחרים המוגדרים בכלל Delete, למעט matchesStorageClass.

  • משתמשים בתנאי matchesStorageClass שלא כולל את סוג האחסון (storage class) של האובייקט.

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

  • האפשרות 'מחיקה עם יכולת שחזור' מופעלת בקטגוריה שלכם.

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

כשקובעים זמני תפוגה, חשוב לזכור:

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

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

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

כדי לעקוב אחרי פעולות ניהול מחזור החיים של Cloud Storage, אפשר להשתמש באחת מהאפשרויות הבאות:

  • שימוש ביומני השימוש של Cloud Storage. תכונה זו מתעדת גם את הפעולה וגם את האדם שביצע אותה. הערך GCS Lifecycle Management בשדה cs_user_agent של הרשומה ביומן מציין שהפעולה בוצעה על ידי Cloud Storage בהתאם להגדרה של מחזור החיים.
  • הפעלה של התראות Pub/Sub ל-Cloud Storage בקטגוריה. כשהפעולות האלו מתבצעות, תכונה זו שולחת התראות לנושא Pub/Sub לפי בחירתכם. שימו לב שהתכונה הזו לא מתעדת מי ביצע את הפעולות.

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