מידע על שכפול מופעים

‫Filestore כולל עכשיו שכפול אסינכרוני של המכונות.

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

כדי לבחור לקוחות, Filestore מציע תמיכה בשכפול מופעים עבור מופעים שנוצרו ברמות השירות הבאות:

  • אזורי
  • אזורי
  • Enterprise

השוואה בין שכפול מופעים לבין אפשרויות אחרות לשחזור נתונים

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

Snapshots

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

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

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

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

גיבויים

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

שכפול מכונה

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

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

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

תפקידים של זוגות מופעים

כשמשכפלים מכונה, לכל מכונה בצמד מוקצה תפקיד:

  • ACTIVE

    מופע המקור.

  • STANDBY

    מופע הרפליקה.

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

השהיה והמשך של השכפול

כשהשכפול מושהה, סטטוס המופע של העותק משתנה מ-STANDBY ל-ACTIVE על סמך נקודת הנתונים האחרונה שהשכפול שלה הצליח.

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

מידע נוסף מופיע במאמרים השהיית הרפליקציה והמשכת הרפליקציה.

קידום רפליקה

אי אפשר להפעיל את מופע ההעתק או לכתוב בו ישירות, אבל במקרה של הפסקת שירות, ההעתק יכול לבצע פעולת promote-replica. אפשר לבצע את אותה פעולה דרך מסוף Google Cloud .

הפעולה הזו יוזמת את הפעולות הבאות:

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

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

מידע נוסף מופיע במאמר הפסקת הרפליקציה והעלאת העותק.

קידום רפליקה מושהית

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

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

חזרה למצב הקודם (Failback)

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

מגבלות

ההגבלות הבאות חלות:

  • שכפול מופעים לא זמין ברמות השירות הבאות:

    • HDD בסיסי
    • SSD בסיסי

  • המפרטים הבאים חייבים להיות זהים בכל מופע בצמד:

בקטעים הבאים מפורטות מגבלות אחרות שקשורות ל-RPO, לפעולות, לתנועת רשת, לביצועים ולזמינות:

RPO

  • הזמנים שצוינו של RPO הם משוערים ולא נתמכים במסגרת הסכם רמת השירות (SLA) של Filestore.

  • יעד ה-RPO של 30 דקות חל על מקרים עם קצב שינוי של 100 MB לשנייה וקצב IOPS של 300 לשנייה, כאשר IOPS מוגדר ככל פעולה של create,‏ edit או delete שמוחלת על קובץ או על ספרייה כלשהם.

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

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

תפעול

  • הפעולות הבאות מושבתות במופע ACTIVE:

    • מחיקת מכונה
    • חזרה לתמונת מצב

  • המגבלות הבאות חלות על מופע STANDBY:

    • לא תומך בגישת NFS
    • הגיבויים מושבתים
    • התמונות המהירות מושבתות

תנועה ברשת

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

ביצועים

  • שכפול רציף של נתונים בין הצמד משפיע על ביצועי ה-IOPS במופע המקור.

זמינות

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

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

המלצות

כדי לקבל פתרון אמין לתוכנית התאוששות מאסון (DR), מומלץ מאוד למשתמשים לבחור אזור נפרד ולא תחום (zone) נפרד עבור מופע הרפליקה.

מעקב

המדד time_since_last_replication מייצג את חותמת הזמן של העותק המלא האחרון של המופע הפעיל.

מידע נוסף זמין במקורות המידע הבאים:

תמחור

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

למידע נוסף, אפשר לפנות לנציג Filestore.

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