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

‫Hyperdisk Balanced High Availability היא אפשרות אחסון שמאפשרת להטמיע שירותים עם זמינות גבוהה (HA) ב-Compute Engine. ב-Hyperdisk Balanced High Availability, הנתונים משוכפלים באופן סינכרוני בין שני אזורים באותו מחוז, כדי להבטיח זמינות גבוהה של נתוני הדיסק במקרה של כשל אחד באזור.

יצירת שירותים עם זמינות גבוהה באמצעות דיסקים אזוריים

בקטע הזה מוסבר איך ליצור שירותים עם זמינות גבוהה באמצעות דיסקים מסוגHyperdisk Balanced High Availability.

שיקולים שקשורים לעיצוב

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

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

כשמתכננים להשגת זמינות גבוהה, כדאי לקחת בחשבון את הדברים הבאים:

  • ההשפעה על האפליקציה של שימוש ב- Persistent Disk אזורי או בפתרונות אחרים.
  • ביצועי הכתיבה בדיסק.
  • יעד זמן ההתאוששות של השירות – כמה מהר השירות צריך להתאושש מהפסקה זמנית של השירות באזור, ודרישות ה-SLA.
  • העלות של בניית ארכיטקטורת שירותים גמישה ואמינה.
  • למידע נוסף על שיקולים ספציפיים לאזורים, קראו את המאמר מיקום גיאוגרפי ואזורים.

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

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

    • עלויות של מכונות וירטואליות
    • עלויות שלHyperdisk
    • עלויות התחזוקה של שכפול האפליקציה

  • שימוש במכונה וירטואלית אחת עם דיסקים שמשוכפלים באופן סינכרוני. כדי להשיג זמינות גבוהה עם דיסק Persistent Disk דיסק Hyperdisk Balanced High Availability, משתמשים באותם רכיבים של מכונה וירטואלית ודיסק כמו באפשרות הקודמת, אבל כוללים גם דיסק שמשוכפל באופן סינכרוני. Hyperdisk Balanced High Availability היא כפולה בהשוואה לדיסקים של תחום מוגדר, כי הם משוכפלים בשני אזורים.

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

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

השוואה בין עלות, ביצועים ועמידות

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

ארכיטקטורת שירות
בזמינות גבוהה
תמונות מצב של דיסק אחסון מקומי
סינכרוני
ברמת האפליקציה
אסינכרוני ברמת האפליקציה		 דיסקים אזוריים
הגנה מפני כשלים באפליקציה, במכונה הווירטואלית ובאזור*
הפחתת הסיכון לפגיעה באפליקציה (לדוגמה: חוסר סבילות לקריסת אפליקציה) * *
עלות $ $$

  • Two instances of the database or VM running, application replication setup and maintenance, cross zone networking.
 $$

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

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

  • ללא אפקטים

  • השפעה על ביצועי האפליקציה בגלל רפליקציה סינכרונית

  • ללא אפקטים

  • אין השפעה על רוב האפליקציות
מתאים לאפליקציות עם דרישות RPO נמוכות (סבילות נמוכה מאוד לאובדן נתונים)

  • אובדן נתונים, בהתאם למועד שבו נוצר קובץ ה-snapshot

  • אין אובדן נתונים‡

  • אובדן נתונים כי הרפליקציה היא אסינכרונית

  • אין אובדן נתונים
זמן ההתאוששות של האחסון מאסון#
  • O(minutes)
  • O(seconds)
  • O(seconds)
  • ‫O (שניות) – כדי לאלץ את חיבור הדיסק למכונה וירטואלית במצב המתנה

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

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

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

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

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

בקטע הזה נסביר באופן כללי איך ליצור פתרונות לזמינות גבוהה בשירותים של מסדי נתונים עם שמירת מצב (MySQL,‏ Postgres וכו') באמצעות Compute Engine עםHyperdisk Balanced High Availability.

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

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

  • מכונה וירטואלית ראשית באזור הראשי
  • מכונה וירטואלית במצב המתנה באזור משני

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

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

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

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

בטבלה הבאה מפורטים כמה אתגרים נפוצים בהגדרה ובניהול של רפליקציה סינכרונית או חצי-סינכרונית של אפליקציות (כמו MySQL), בהשוואה לרפליקציה סינכרונית של דיסקים באמצעותHyperdisk Balanced High Availability.

אתגרים רפליקציה סינכרונית
או חצי סינכרונית של אפליקציות		 שכפול דיסק סינכרוני
שמירה על רפליקציה יציבה בין הרפליקה הראשית לבין הרפליקה של יתירות הכשל. יש כמה דברים שיכולים להשתבש ולגרום למכונה וירטואלית לצאת ממצב HA:
  1. הגדרות שגויות של פרמטרים של רפליקציה, כמו אי-התאמה של אישור SSL או ACL חסר בצד הראשי.
  2. עומס גבוה על המכונה הווירטואלית הראשית, שגורם לכך שהרפליקה ליתירות כשל לא מצליחה לעמוד בקצב.
  3. באגים שגורמים לבעיות ברפליקציה, כמו בעיות באפליקציה, הגדרה שגויה של מערכת ההפעלה או כשל ב-Docker.
  4. כשלים בתשתית, כמו תחרות על משאבי מעבד (CPU), מכונה וירטואלית שקפאה או הפרעה זמנית ברשת.

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

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

Hyperdisk Balanced High Availability מספקים רפליקציה סינכרונית, כך שזמן המעבר למצב של יתירות כשל מוגבל לסכום של זמני האחזור הבאים:

  1. יצירת מכונה וירטואלית משנית, אלא אם כבר יש מכונה וירטואלית זמינה במצב המתנה.
  2. צירוף מאולץ של דיסק אזורי.
  3. אתחול האפליקציה.
פיצול מוח (Split-brain) כדי למנוע מצב של split-brain, בשתי הגישות צריך להבטיח שיש רק מאסטר אחד בכל פעם.

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

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

כברירת מחדל, מכונה וירטואלית של Compute Engine עםHyperdisk Balanced High Availability פועלת במצב שכפול מלא, שבו בקשות לקריאה או לכתיבה מהדיסק נשלחות לשתי הרפליקות.

במצב שכפול מלא, קורים הדברים הבאים:

  • כשכותבים, בקשת הכתיבה מנסה לכתוב לשתי הרפליקות ומאשרת כששתי הכתיבות מצליחות.
  • בזמן הקריאה, ה-VM שולחת בקשת קריאה לשתי הרפליקות ומחזירה את התוצאות מהרפליקה שהצליחה. אם פג הזמן הקצוב לבקשת הקריאה, נשלחת בקשת קריאה נוספת.

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

בדיקות תקינות

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

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

סוכן בדיקת התקינות עצמו חייב להיות עמיד בפני תקלות. לדוגמה, שימו לב שבתמונה הבאה מישור הבקרה מופרד מהמכונה הווירטואלית הראשית, שנמצאת באזור us-central1-a, בעוד שהמכונה הווירטואלית במצב המתנה נמצאת באזור us-central1-f.

תפקיד הסוכן של בדיקת התקינות ב-VM.

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

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