זמינות ועמידות נתונים

בדף הזה מוסברים המושגים "זמינות" ו"עמידות" ב-Cloud Storage:

• זמינות: היכולת לגשת לנתונים מיד כשמבקשים.

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

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

מושגים מרכזיים

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

• ‫Cloud Storage מתוכנן לספק עמידות שנתית של לפחות 99.999999999% (11 ספרות 9), בלי קשר לסוג האחסון ולסוג המיקום.

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

  • פעולות כתיבה ב-Cloud Storage מאושרות כפעולות שהצליחו רק אחרי שהנתונים נשמרים באופן יתיר.

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

איך סוג המיקום של הקטגוריה משפיע על הזמינות והעמידות

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

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

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

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

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

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

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

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

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

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

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

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

יתירות בין אזורים

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

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

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

ברירת המחדל של רפליקציה ב-Cloud Storage מתוכננת לספק יתירות בין אזורים של 99.9% בשביל אובייקטים חדשים שנכתבו בטווח של שעה אחת, ו-100% בשביל אובייקטים חדשים שנכתבו בטווח של 12 שעות. אובייקטים חדשים שנכתבו כוללים העלאות, כתיבה מחדש, עותקים והרכבות.

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

רפליקציה בקצב טורבו

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

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

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

מידע נוסף מופיע במאמר המדריך המפורט לתכנון תוכנית התאוששות מאסון (DR) של אפליקציות ב- Google Cloud.

מגבלות

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

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

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

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

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

רפליקציה בין קטגוריות

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

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

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

כדי לשכפל בין קטגוריות, משתמשים ב-Storage Transfer Service לשכפול אובייקטים וב-Pub/Sub לקבלת התראות על שינויים בקטגוריות המקור והיעד. אפשר להפעיל רפליקציה בין קטגוריות בקטגוריות חדשות שיוצרים ובקטגוריות קיימות.

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

במאמר שימוש ברפליקציה בין קטגוריות מוסבר איך להשתמש ברפליקציה בין קטגוריות.

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

מגבלות

• אי אפשר להשתמש בשמות בהתאמה אישית למשימות של שכפול בין קטגוריות. בקשות ליצירה שמכילות ערך בשדה name מחזירות שגיאה.

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

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

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

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

• אפשר להשתמש ברפליקציה בין קטגוריות כדי לשכפל נתונים בין קטגוריות שנמצאות בכל מיקום ב- Google Cloud , ולכן הביצועים של הרפליקציה בין קטגוריות משתנים בהתאם למיקומים שנבחרו. לכן, ברפליקציה בין קטגוריות אין יעד להתאוששות מאסון (RPO).

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

מעקב ביצועים

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

לדוגמה, אם אובייקט אחד הניב 20 דקות חריגה בין 9:00 ל-9:20, ואובייקט אחר הניב 10 דקות חריגה בין 9:15 ל-9:25, אז יש שני אובייקטים בחודש שחרגו מה-RPO. מספר הדקות הכולל של זמן ההשבתה באותו חודש הוא 25 דקות, כי בין השעות 9:00 ל-9:25 היה לפחות אובייקט אחד שלא עמד ביעד ה-RPO.

• בקטגוריות שמופעלת בהן רפליקציה בקצב טורבו, ה-RPO של האובייקטים הוא 15 דקות.

• בקטגוריות שמשתמשות ברפליקציית ברירת מחדל, ה-RPO של האובייקטים הוא 12 שעות.

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

• רפליקציה בין קטגוריות לא מספקת RPO.

במסוף Google Cloud , התרשים Percent of minutes out of RPO מאפשר לעקוב אחרי אחוז הדקות הלא תקינות במהלך 30 הימים האחרונים בקטגוריה, כשמשתמשים ברפליקציה שמוגדרת כברירת מחדל או ברפליקציה בקצב טורבו בקטגוריות בשני אזורים או במספר אזורים. אפשר להשתמש במדד רמת שירות (SLI) כדי לעקוב אחר תאימות זמן הרפליקציה החודשית בקטגוריה. באופן דומה, המדד Percent of objects out of target עוקב אחרי רפליקציות של אובייקטים שלא התרחשו במסגרת ה-RPO. אפשר להשתמש במדד רמת שירות (SLI) כדי לעקוב אחר תאימות נפח האחסון החודשית של הרפליקציה בקטגוריה. מידע נוסף זמין במאמרים מעקב אחרי Cloud Storage והסכם רמת השירות של Cloud Storage.

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

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