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

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

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

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

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

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

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

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

  • לשם כך, 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 לשנייה והאובייקטים קטנים מ-‎1GiB, שכפול בין קטגוריות נמשך בדרך כלל בין דקות ספורות לעשרות דקות, אבל אין תמיכה בגבול עליון ספציפי. בנוסף, בקטגוריות שבהן שיעורי השינויים גבוהים יותר או שיש בהן אובייקטים גדולים יותר, צפויים עיכובים ארוכים יותר ברפליקציה.

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

הערה: כשמשתמשים ברפליקציה בין קטגוריות, יכול להיות שתחויבו על העברת נתונים, אחסון נתונים, עיבוד נתונים, אחזור נתונים ופעולות מ-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.

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

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