רפליקציה אסינכרונית מספקת יעד נמוך להתאוששות מאסון (RPO) ויעד נמוך למשך ההתאוששות (RTO) של רפליקציית אחסון בלוקים להתאוששות מאסון (DR) פעילה-פסיבית בין אזורים.
רפליקציה אסינכרונית היא אפשרות אחסון שמספקת רפליקציה אסינכרונית של נתונים בין שני אזורים. במקרה הלא סביר של הפסקה זמנית בשירות אזורית, שכפול אסינכרוני מאפשר לבצע יתירות כשל של הנתונים לאזור משני ולהפעיל מחדש את עומס העבודה באזור הזה.
אתם יכולים להשתמש בשכפול אסינכרוני כדי לנהל שכפול של עומסי עבודה ב-Compute Engine ברמת התשתית, במקום ברמת עומס העבודה.
סקירה כללית
רפליקציה אסינכרונית משכפלת נתונים מדיסק שמצורף לעומס עבודה פעיל, הדיסק הראשי, לדיסק נפרד שנמצא באזור אחר. הדיסק שמקבל את הנתונים המשוכפלים נקרא הדיסק המשני.
האזור שבו נמצא הדיסק הראשי נקרא האזור הראשי, והאזור שבו נמצא הדיסק המשני נקרא האזור המשני. האזור הראשי והאזור המשני נקראים זוג אזורים.
כל דיסק שעומד בדרישות לדיסק יכול לשמש כדיסק ראשי. אחרי שיש לכם דיסק ראשי, אתם יכולים ליצור דיסק משני שמפנה לדיסק הראשי ולהתחיל שכפול מהדיסק הראשי לדיסק המשני.
אם מפסיקים את השכפול מהדיסק הראשי בשלב כלשהו ורוצים להפעיל אותו מחדש בשלב מאוחר יותר, צריך ליצור דיסק משני חדש כדי להפעיל מחדש את השכפול.
קבוצות עקביות
קבוצות עקביות מאפשרות לכם לבצע DR ובדיקות DR בכמה דיסקים. קבוצת אפליקציות עקביות היא מדיניות משאבים שמבצעת את הפעולות הבאות:
- התאמה של השכפול בין הדיסקים הראשיים, כדי לוודא שכל הדיסקים מכילים נתוני שכפול מנקודת זמן משותפת, שמשמשים להתאוששות מאסון.
- התאמה של שיבוטים של דיסקים מדיסקים משניים, ולוודא שכל השיבוטים של הדיסקים מכילים נתונים מנקודת זמן משותפת, שמשמשת לתרגול של DR.
אם רוצים ליישר את תקופת השכפול בכמה דיסקים, צריך להוסיף דיסקים ראשיים לקבוצת אפליקציות עקביות. אם רוצים לשכפל כמה דיסקים ולוודא שהשיבוטים האלה מכילים נתונים מנקודת זמן משותפת, מוסיפים דיסקים משניים לקבוצת אפליקציות עקביות. אפשר להשתמש בקבוצת אפליקציות עקביות לשכפול או ליצירת עותק, אבל לא לשניהם בו-זמנית.
אם רוצים להוסיף דיסקים ראשיים לקבוצת אפליקציות עקביות, צריך להוסיף דיסקים לקבוצת אפליקציות עקביות לפני שמתחילים את השכפול. אפשר להוסיף דיסקים משניים לקבוצת אפליקציות עקביות בכל שלב.
מעבר לגיבוי כשל ומעבר חזרה לגיבוי הכשל
במקרה של הפסקה זמנית בשירות באזור הראשי, באחריותכם לזהות את הפסקה זמנית בשירות ולהפעיל מחדש את עומס העבודה באמצעות הדיסקים המשניים באזור המשני. Asynchronous Replication לא מציע ניטור של הפסקות חשמל. כדי לזהות הפסקת שירות, אפשר להשתמש במדדי RPO, בבדיקות תקינות ובמדדים ספציפיים לאפליקציה, או לפנות ל-Cloud Customer Care.
תהליך המעבר לגיבוי כולל את המשימות הבאות:
- מפסיקים את השכפול.
- מצרפים את הדיסקים המשניים למכונות וירטואליות באזור המשני.
אחרי מעבר לגיבוי בעקבות כשל בדיסקים, באחריותכם לאמת ולהפעיל מחדש את עומס העבודה של האפליקציה באזור המשני, ולהגדיר מחדש את כתובות הרשת שמשמשות לגישה לאפליקציה כך שיצביעו על האזור המשני.
אחרי מעבר לגיבוי חם מהאזור הראשי לאזור המשני, האזור המשני הופך לאזור הראשי הפעיל. אחרי שההפסקה הזמנית בשירות או האסון מסתיימים, אפשר להפעיל גיבוי חזרה כדי להתחיל רפליקציה מהאזור המשני המקורי (האזור הראשי הפעיל) לאזור הראשי המקורי. אם רוצים, אפשר לחזור על התהליך כדי להעביר את עומס העבודה בחזרה לאזור הראשי המקורי.
תהליך החזרה לגיבוי כולל את המשימות הבאות:
מגדירים רפליקציה בין האזור הראשי החדש לבין האזור הראשי המקורי.
- הדיסק המשני המקורי הוא עכשיו הדיסק הראשי החדש, ואתם מגדירים אותו לשכפול לדיסק משני חדש באזור הראשי המקורי.
- אתם יכולים ליצור מדיניות חדשה של משאבי קבוצת אפליקציות עקביות באזור הראשי החדש, כדי שהדיסקים הראשיים החדשים (הדיסקים המשניים המקוריים) יוכלו לשכפל באופן עקבי לסט חדש של דיסקים משניים באזור הראשי המקורי.
(אופציונלי) אחרי שהרפליקציה הראשונית מתבצעת, אפשר לחזור על תהליך היתירות כשל כדי להחזיר את עומס העבודה לאזור הראשי המקורי.
הצפנת דיסק
דיסקים ראשיים ומשניים לא תומכים במפתחות הצפנה באספקת הלקוח (CSEK). במקום זאת, צריך להשתמש בGoogle-owned and Google-managed encryption keys או במפתחות הצפנה בניהול הלקוח (CMEK). אם משתמשים ב-CMEK בדיסק הראשי, צריך להשתמש ב-CMEK גם בדיסק המשני. אפשר להשתמש במפתחות CMEK שונים בשני הדיסקים.
התאמה אישית של דיסק משני
כשיוצרים דיסק משני, מערכת Compute Engine מעתיקה באופן אוטומטי את המאפיינים של הדיסק הראשי לדיסק המשני. אתם יכולים לשנות מאפיינים מסוימים של הדיסק המשני כך שהם יהיו שונים מהדיסק הראשי. לדוגמה, הדיסק הראשי והדיסק המשני צריכים להיות באותו גודל ולהשתמש באותו מפתח הצפנה, אבל אפשר להקצות תוויות נוספות לדיסק המשני.
אם הדיסק הראשי הוא דיסק אתחול, הדיסק המשני נוצר עם הגדרות האתחול של הדיסק הראשי. הגדרת האתחול כוללת מידע על ארכיטקטורת מערכת ההפעלה, רישיונות מערכת ההפעלה והתכונות של מערכת ההפעלה האורחת.
בדיסקים לאתחול, אפשר להפעיל אפשרויות אבטחה או רשת נוספות בדיסק המשני על ידי ציון תכונות נוספות של מערכת ההפעלה של האורח. עם זאת, אי אפשר להסיר תכונות של מערכת ההפעלה לאורחים בדיסק הראשי. Compute Engine ממזג את התכונות החדשות שציינתם עם התכונות הקיימות של מערכת ההפעלה האורחת בדיסק הראשי.
מידע נוסף על התאמה אישית של דיסק משני זמין במאמר יצירת דיסק משני בהתאמה אישית.
דוגמה
נניח שיש לכם דיסק אתחול בשם disk-1, עם התכונות הבאות של מערכת ההפעלה האורחת: [GVNIC, UEFI_COMPATIBLE].
אם יוצרים דיסק משני מ-disk-1, אפשר לציין רק תכונות נוספות. אי אפשר להסיר את התכונות UEFI_COMPATIBLE וGVNIC.
לכן, אם מציינים MULTI_IP_SUBNET כשיוצרים את הדיסק המשני, התכונה החדשה משולבת עם התכונות של הדיסק הראשי, כך שהתכונות של מערכת ההפעלה האורחת שמתקבלות עבור הדיסק המשני הן [GVNIC,UEFI_COMPATIBLE, and
MULTI_IP_SUBNET].
שינוי דיסק ראשי
אחרי שיוצרים את הדיסק המשני, יכול להיות שתרצו לשנות את המאפיינים של הדיסק הראשי. בנכסים מסוימים, אם מבצעים שינוי בדיסק הראשי, Compute Engine מעדכן אוטומטית את הנכס בדיסק המשני.
מערכת Compute Engine עוקבת אחרי המאפיינים הבאים ומעדכנת אותם באופן אוטומטי:
- מצב גישה (Hyperdisk בלבד)
- גודל כונן
- הקצאת משאבים לפי IOPS ותפוקה (Hyperdisk בלבד)
- סטטוס השכפול
אם משנים מאפיינים אחרים של הדיסק הראשי, צריך לעדכן את הדיסק המשני באופן ידני.
- מידע על שינוי המאפיינים של נפח Hyperdisk מופיע במאמר שינוי Hyperdisk.
- מידע נוסף על שינוי המאפיינים של Persistent Disk מופיע במאמר שינוי של Persistent Disk.
רפליקציה אסינכרונית ודיסקים אזוריים
אפשר להשתמש בשכפול אסינכרוני עם דיסקים אזוריים כדי להשיג זמינות גבוהה (HA) ושחזור מאסון (DR).
אפשר להשתמש בדיסקים לאחסון מתמיד אזורי ככונן הראשי או המשני בצמד דיסקים של שכפול אסינכרוני. צמד דיסקים הוא דיסק ראשי שמשוכפל לדיסק משני.
כשמשתמשים בדיסק אזורי כשהוא הדיסק הראשי, השכפול נמשך ללא הפרעה גם אם באחד מהאזורים שלו מתרחשת הפסקת חשמל. הדיסק הראשי האזורי ממשיך לשכפל נתונים מהאזור התקין לדיסק המשני. באופן דומה, כשדיסק אזורי משמש כדיסק משני, הרפליקציה נמשכת למרות הפסקה זמנית באחד מהאזורים שלו. שימוש בדיסק אזורי כדיסק משני מכין את עומס העבודה לזמינות גבוהה באזורים שונים במקרה של יתירות כשל, שבו הדיסק המשני הופך לדיסק הראשי החדש.
מגבלות
- Asynchronous Replication נתמך רק בסוגי הדיסקים הבאים:
- דיסק אחסון מתמיד מאוזן
- דיסק אחסון מתמיד (persistent disk) לביצועים (SSD)
- Hyperdisk Balanced
- Hyperdisk Balanced High Availability
- Hyperdisk Extreme
- אין תמיכה בדיסקים לקריאה בלבד.
- דיסקים עם גישת קריאה וכתיבה מרובה נתמכים רק ב-Hyperdisk Balanced וב-Hyperdisk Balanced High Availability.
- לא כל השינויים במאפייני Hyperdisk מוחלים באופן אוטומטי על הדיסק המשני. מידע נוסף על המאפיינים שמוחלים באופן אוטומטי על הדיסק המשני זמין במאמר בנושא התאמה אישית של דיסק משני.
- הגודל המקסימלי של כל דיסק הוא 64 TiB.
- כדי למחוק דיסק ראשי או משני, צריך קודם להפסיק את השכפול.
- אם מתבצעת שכפול של דיסק האתחול של מכונה וירטואלית, אי אפשר למחוק את המכונה הווירטואלית עד שמפסיקים את השכפול.
- אם דיסק ראשי מצורף למכונה וירטואלית כדיסק שאינו דיסק אתחול, והדיסק מוגדר למחיקה עם המכונה הווירטואלית, לא ניתן למחוק את המכונה הווירטואלית או את הדיסק עד שמפסיקים את השכפול או מנתקים את הדיסק הראשי מהמכונה הווירטואלית. הניסיונות למחוק את ה-VM ייכשלו עד שתפסיקו את השכפול.
בכל פרויקט יכולות להיות לכל היותר 1,000 זוגות של דיסקים בכל זוג אזורים.
לדוגמה, בפרויקט מסוים,
project-1, יכולות להיות עד 1,000 זוגות של דיסקים באזור איווה-אורגון.project-1יכול להכיל גם עד 1,000 זוגות של דיסקים באזור בלגיה-פרנקפורט.
אזורים נתמכים
שכפול אסינכרוני זמין בכל האזורים ביבשות הבאות:
- אסיה, למעט אינדונזיה
- אירופה
- צפון אמריקה
- אוקיאניה
- דרום אמריקה
אפשר לשכפל דיסק ראשי באזור מסוים לדיסק משני בכל אזור זמין באותה יבשת. המשמעות היא שאפשר ליצור צמד אזורים מכל שני אזורים באותה יבשת.
לדוגמה, נניח שיש לכם דיסק ראשי בפרנקפורט (europe-west3).
אתם יכולים לשכפל את הדיסק הזה לדיסק משני בכל מקום באירופה,
אבל אתם לא יכולים לשכפל אותו לאזור בצפון אמריקה.
רשימה מלאה של כל האזורים ב-Compute Engine זמינה במאמר אזורים ותחומים זמינים.
ביצועים
יעד נקודת ההתאוששות (RPO), או משך הזמן שחלף עד שהנתונים זמינים באתר המשני, תלויים בשיעורי השינוי בדיסק. בדרך כלל, שכפול אסינכרוני משכפל נתונים עם יעד RPO של דקה אחת, עד 12.5 GB של בלוקים דחוסים שהשתנו לדקה, עם בלוקים בדיסק שמשוכפלים עם גרנולריות של 4 KB לבלוק. אם בלוק מסוים משתנה כמה פעמים בין אירועי שכפול, רק השינוי האחרון משוכפל לדיסק המשני. בשיעורי שינוי גבוהים יותר בדיסק, ה-RPO עשוי להיות גדול מדקה אחת, ובדרך כלל הוא גדל ככל ששיעורי השינוי בדיסק גדלים. לא ניתן להגדיר את RPO.
במקרים הבאים, יכול להיות ש-RPO יעלה על דקה אחת:
- מתי מתחיל השכפול של הדיסק. במהלך השכפול הראשוני, שכפול אסינכרוני משכפל את כל הבלוקים שבשימוש בדיסק הראשי לדיסק המשני. השכפול הראשוני מסתיים כשהמדד
disk/async_replication/time_since_last_replicationזמין ב-Cloud Monitoring. - אם קצב השינוי בדיסק גדול מ-12.5 GB של בלוקים דחוסים שהשתנו לדקה. אחרי עלייה חדה בשינויים בדיסק, ה-RPO למחזורי שכפול מאוחרים יותר עשוי להיות יותר מדקה אחת בזמן שהשכפול מתעדכן.
- אם מנתקים דיסק ממכונה וירטואלית או מפעילים מחדש מכונה וירטואלית בזמן שהדיסק משוכפל. בדיסקים שעוברים שכפול ומופרדים ממכונה וירטואלית, יכול להיות שערך ה-RPO יעלה למשך תקופה קצרה של עד חמש דקות.
כדי ללמוד איך לראות את ה-RPO של הדיסקים, אפשר לעיין במאמר בנושא מדדי ביצועים של שכפול אסינכרוני.
יעד זמן ההתאוששות (RTO) במהלך מעבר לגיבוי (failover) תלוי בזמן שנדרש להשלמת המשימות השונות שקשורות למעבר לגיבוי של עומס העבודה לאזור חדש. משימות כמו עצירת הרפליקציה וצירוף דיסקים למכונות וירטואליות באזור המשני אמורות להימשך רק כמה דקות. כדי לזרז את ה-RTO, צריך לוודא שיש מכונות וירטואליות שפועלות באזור המשני, כך שאם מתרחשת יתירות כשל, לא צריך לחכות עד שהמכונות הווירטואליות יופעלו.
המאמרים הבאים
- איך מגדירים שכפול
- איך מנהלים שכפול
- איך מנהלים קבוצות עקביות
- איך מבצעים מעבר לגיבוי כשל ומעבר חזרה מגיבוי כשל
- איך מנהלים דיסקים שמשתמשים בשכפול אסינכרוני
- איך עוקבים אחרי הביצועים של Asynchronous Replication