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

בדף הזה מוסבר על המושגים 'זמינות' ו'עמידות' ב-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) של אפליקציות ב- Cloud de Confiance by S3NS.

מגבלות

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

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

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

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

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

שכפול בין דליים

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

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

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

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

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

הוראות לשימוש בשכפול בין קטגוריות זמינות במאמר שימוש בשכפול בין קטגוריות.

מגבלות

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

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

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

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

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

• אפשר להשתמש בשכפול בין מאגרי מידע כדי לשכפל נתונים בין מאגרי מידע שנמצאים בכל מיקום Cloud de Confiance by S3NS , ולכן הביצועים של שכפול בין מאגרי מידע משתנים בהתאם למיקומים שנבחרו. לכן, שכפול בין מאגרי מידע לא מציע יעד להתאוששות מאסון (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.

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

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

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