רפליקציה אסינכרונית מספקת רפליקציה של אחסון בלוקים עם יעד נמוך להתאוששות מאסון (RPO) ויעד נמוך לזמן התאוששות (RTO), לצורך התאוששות מאסון (DR) פעילה-סבילה באזורים שונים.
רפליקציה אסינכרונית היא אפשרות אחסון שמספקת רפליקציה אסינכרונית של נתונים בין שני אזורים. במקרה הלא סביר של הפסקה זמנית בשירות באזור מסוים, רפליקציה אסינכרונית מאפשרת לכם לבצע יתירות כשל של הנתונים לאזור משני ולהפעיל מחדש את עומס העבודה באותו אזור.
אתם יכולים להשתמש ברפליקציה אסינכרונית כדי לנהל את הרפליקציה של עומסי העבודה ב-Compute Engine ברמת התשתית, במקום ברמת עומס העבודה.
סקירה כללית
ב-Asynchronous Replication, הנתונים משוכפלים מדיסק שמחובר לעומס עבודה פעיל, הדיסק הראשי, לדיסק נפרד שנמצא באזור אחר. הדיסק שמקבל את הנתונים המשוכפלים נקרא הדיסק המשני.
האזור שבו נמצא הדיסק הראשי נקרא האזור הראשי, והאזור שבו נמצא הדיסק המשני נקרא האזור המשני. האזור הראשי והאזור המשני נקראים צמד אזורים.
כל דיסק שעומד בדרישות הדיסק יכול לשמש כדיסק ראשי. אחרי שיש לכם דיסק ראשי, אתם יכולים ליצור דיסק משני שמפנה לדיסק הראשי ולהתחיל את הרפליקציה מהדיסק הראשי לדיסק המשני.
אם מפסיקים את השכפול מהדיסק הראשי בשלב כלשהו ורוצים להפעיל מחדש את השכפול בשלב מאוחר יותר, צריך ליצור דיסק משני חדש כדי להפעיל מחדש את השכפול.
קבוצות אפליקציות עקביות
קבוצות אפליקציות עקביות מאפשרות לבצע 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 בלבד)
- סטטוס הרפליקציה
אם משנים מאפיינים אחרים של הדיסק הראשי, צריך לעדכן ידנית את הדיסק המשני.
- במאמרים שינוי הגודל של Persistent Disk ושינוי הגודל והביצועים שהוקצו של נפח Hyperdisk מוסבר איך משנים את הגודל של נפח Persistent Disk או Hyperdisk.
- במאמר שינויים במצב הגישה מוסבר איך משנים את מצב הגישה של Hyperdisk.
רפליקציה אסינכרונית ודיסקים אזוריים
אתם יכולים להשתמש ברפליקציה אסינכרונית עם דיסקים אזוריים כדי להשיג זמינות גבוהה (HA) והתאוששות מאסון (DR).
אפשר להשתמש בדיסקים אזוריים לאחסון מתמיד כדיסק ראשי או משני בזוג דיסקים של רפליקציה אסינכרונית. צמד דיסקים הוא דיסק ראשי שמשוכפל לדיסק משני.
כשמשתמשים בדיסק אזורי כדיסק הראשי, הרפליקציה נמשכת גם אם יש הפסקה באחד מהאזורים שלו. הדיסק הראשי האזורי ממשיך לשכפל נתונים מהאזור התקין לדיסק המשני. באופן דומה, כשדיסק אזורי משמש כדיסק משני, הרפליקציה נמשכת למרות הפסקה זמנית בשירות באחד מהאזורים שלו. שימוש בדיסק אזורי כדיסק משני מכין את עומס העבודה לזמינות גבוהה באזורים, במקרה של יתירות כשל שבו הדיסק המשני הופך לדיסק הראשי החדש.
מגבלות
- אפשר להשתמש ב-Asynchronous Replication רק בסוגי הדיסקים הבאים:
- דיסק אחסון מתמיד מאוזן
- דיסק מתמיד שמבוסס על ביצועים (SSD)
- Hyperdisk Balanced
- Hyperdisk Balanced High Availability
- Hyperdisk Extreme
- אין תמיכה בדיסקים לקריאה בלבד.
- אפשר להשתמש בדיסקים עם כמה כותבים רק ב-Hyperdisk Balanced וב-Hyperdisk Balanced High Availability.
- לא כל השינויים במאפייני Hyperdisk חלים באופן אוטומטי על הדיסק המשני. למידע נוסף על המאפיינים שחלים באופן אוטומטי על הדיסק המשני, ראו התאמה אישית של דיסק משני.
- הגודל המקסימלי של כל דיסק הוא 64 TiB.
- כדי למחוק דיסק ראשי או משני, צריך קודם להפסיק את הרפליקציה.
- אם מתבצעת רפליקציה של דיסק האתחול של ה-VM, אי אפשר למחוק את ה-VM עד שמפסיקים את הרפליקציה.
- אם דיסק ראשי מחובר למכונה וירטואלית כדיסק שלא משמש לאתחול, והדיסק מוגדר כך שיימחק יחד עם המכונה הווירטואלית, אי אפשר למחוק את המכונה הווירטואלית או את הדיסק עד שמפסיקים את הרפליקציה או מנתקים את הדיסק הראשי מהמכונה הווירטואלית. ניסיונות למחוק את ה-VM ייכשלו עד שתפסיקו את הרפליקציה.
בכל פרויקט יכולים להיות עד 1,000 זוגות של דיסקים בכל זוג של אזורים.
לדוגמה, בפרויקט
project-1יכולים להיות עד 1,000 זוגות דיסקים באזור Iowa-Oregon. ב-project-1יכולים להיות גם עד 1,000 זוגות דיסקים בצמד האזורים בלגיה-פרנקפורט.
אזורים נתמכים
רפליקציה אסינכרונית זמינה בכל האזורים ביבשות הבאות:
- אסיה, חוץ מאינדונזיה
- אירופה
- צפון אמריקה
- אוקיאניה
- דרום אמריקה
אתם יכולים לשכפל דיסק ראשי באזור מסוים לדיסק משני בכל אזור זמין באותה יבשת. כלומר, אפשר ליצור צמד אזורים מכל שני אזורים באותה יבשת.
לדוגמה, נניח שיש לכם דיסק ראשי בפרנקפורט (europe-west3). אתם יכולים לשכפל את הדיסק הזה לדיסק משני בכל מקום באירופה, אבל לא לאזור בצפון אמריקה.
רשימה מלאה של כל האזורים ב-Compute Engine
ביצועים
יעד נקודת השחזור (RPO), או משך הזמן עד שהנתונים זמינים באתר המשני, תלוי בקצב השינויים בדיסק. בדרך כלל, ברפליקציה אסינכרונית הנתונים משוכפלים עם יעד RPO של דקה אחת, עד 12.5GB של בלוקים דחוסים שהשתנו לדקה, ובלוקים של דיסק משוכפלים עם רמת פירוט של בלוקים בגודל 4KB. אם בלוק מסוים משתנה כמה פעמים בין אירועי רפליקציה, רק השינוי האחרון משוכפל לדיסק המשני. בשיעורי שינוי גבוהים יותר בדיסק, ה-RPO עשוי להיות גדול מדקה אחת, ובדרך כלל הוא גדל ככל ששיעורי השינוי בדיסק גדלים. אי אפשר להגדיר את ה-RPO.
יכול להיות שה-RPO יהיה ארוך מדקה בתרחישים הבאים:
- כשהשכפול של הדיסק מתחיל. במהלך הרפליקציה הראשונית, הרפליקציה האסינכרונית משכפלת את כל הבלוקים שבשימוש בדיסק הראשי לדיסק המשני. הרפליקציה הראשונית מסתיימת כשהמדד
disk/async_replication/time_since_last_replicationזמין ב-Cloud Monitoring. - אם קצב השינוי בדיסק גדול מ-12.5GB של בלוקים דחוסים שהשתנו לדקה. אחרי עלייה חדה בשינויים בדיסק, יכול להיות שזמן ה-RPO של מחזורי הרפליקציה הבאים יהיה ארוך מדקה עד שהרפליקציה תתעדכן.
- אם מנתקים דיסק ממכונה וירטואלית או מפעילים מחדש מכונה וירטואלית בזמן שהדיסק משוכפל. אם מנתקים מה-VM דיסקים שעוברים רפליקציה, יכול להיות שזמן ה-RPO יגדל עד חמש דקות לפרק זמן קצר.
במאמר מדדי ביצועים של רפליקציה אסינכרונית מוסבר איך בודקים את ה-RPO של הדיסקים.
יעד זמן ההתאוששות (RTO) במהלך יתירות כשל תלוי בזמן שנדרש כדי להשלים את המשימות השונות שקשורות למעבר של עומס העבודה לאזור חדש. משימות כמו הפסקת הרפליקציה וחיבור הדיסקים למכונות הווירטואליות באזור המשני אמורות להימשך רק כמה דקות. כדי לקצר את ה-RTO, אתם יכולים לוודא שהמכונות הווירטואליות פועלות באזור המשני, כך שאם תהיה יתירות כשל, לא תצטרכו לחכות שהמכונות הווירטואליות יופעלו.