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

‫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 או