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

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

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

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

שיקולים בתכנון

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

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

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

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

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

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

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

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

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

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

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

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

ארכיטקטורה של שירות HA	תמונות מצב של דיסקים אזוריים	ברמת האפליקציה סנכרוני	ברמת האפליקציה אסינכרוני	דיסקים אזוריים
הגנה מפני כשל באפליקציה, במכונה וירטואלית או באזור^*
הפחתת הסיכון לפגיעה באפליקציה (דוגמה: אפליקציה שלא יכולה לקרוס)		^†	^†
עלות	$	$$ Two instances of the database or VM running, application replication setup and maintenance, cross zone networking.	$$ שני מופעים של מסד הנתונים או של המכונה הווירטואלית פועלים, הגדרה ותחזוקה של שכפול האפליקציה, רשתות חוצות אזורים.	$1.5x - $$ העלויות זהות לעלויות של שכפול אפליקציות אם משתמשים במכונה וירטואלית פעילה במצב המתנה. כדי להשיג עלות נמוכה יותר, אפשר להתחיל הרצה של מכונה וירטואלית לגיבוי לפי דרישה במהלך יתירות כשל. אין חיוב על רשתות חוצות אזורים בין עותקים של דיסקים.
ביצועי האפליקציה	ללא אפקטים	הפשרה בנוגע לביצועי האפליקציה עם שכפול סינכרוני	ללא אפקטים	אין השפעה על רוב האפליקציות
מתאים לאפליקציות עם דרישה נמוכה של RPO (סבילות נמוכה מאוד לאובדן נתונים)	אובדן נתונים בהתאם למועד שבו צולם צילום המסך	לא יתרחש אובדן נתונים^‡	אובדן נתונים בגלל שכפול אסינכרוני	לא יאבדו נתונים
זמן השחזור של האחסון מאסון^#	‫O(minutes)	O(seconds)	O(seconds)	‫O(seconds)—to force attach the disk to a standby VM instance

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אתגרים	שכפול סינכרוני של האפליקציה או שכפול חצי סינכרוני	שכפול דיסקים סינכרוני
שמירה על רפליקציה יציבה בין רפליקה ראשית לרפליקת יתירות כשל.	יש כמה דברים שיכולים להשתבש ולגרום למופע של מכונה וירטואלית לצאת ממצב זמינות גבוהה: הגדרה שגויה של פרמטרים של שכפול, כמו אי התאמה של אישור SSL או ACL חסר בצד הראשי. עומס גבוה על מופע ה-VM הראשי שגורם לכך שרפליקת הגיבוי למעבר חלקה לא מצליחה לעמוד בקצב. באגים שגורמים לבעיות בשכפול, כמו בעיות באפליקציה, הגדרה שגויה של מערכת ההפעלה או כשל ב-Docker. תקלות בתשתית כמו תחרות על משאבי CPU, מכונה וירטואלית קפואה או הפרעה זמנית ברשת.	תקלות באחסון מטופלות על ידי ודיסקים של Hyperdisk Balanced High Availability. הפעולה הזו מתבצעת באופן שקוף לאפליקציה, למעט תנודות אפשריות בביצועים של הדיסק. צריכות להיות בדיקות תקינות שהוגדרו על ידי המשתמש כדי לחשוף בעיות באפליקציה או במכונה וירטואלית ולהפעיל מעבר לגיבוי בעת כשל.
זמן המעבר לגיבוי (failover) מקצה לקצה ארוך מהצפוי.	אין גבול עליון לזמן שלוקח לבצע את פעולת המעבר לגיבוי. ההמתנה להפעלה מחדש של כל הטרנזקציות (שלב 2 למעלה) עשויה להימשך זמן רב, בהתאם לסכימה ולעומס על מסד הנתונים.	‫Hyperdisk Balanced High Availability מספקים שכפול סינכרוני, כך שזמן המעבר לגיבוי מוגבל לסכום של זמני האחזור הבאים: יצירה של מכונה וירטואלית משנית, אלא אם כבר יש מכונה וירטואלית במצב המתנה. כפיית צירוף של דיסק אזורי. אתחול האפליקציה.
פיצול מוח	כדי להימנע מפיצול מוח, בשתי הגישות צריך להקפיד שיהיה רק שרת ראשי אחד בכל פעם.

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

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

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

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

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

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

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

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

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

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

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

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

• איך יוצרים ומנהלים דיסקים אזוריים.
• איך מגדירים מופע של אשכול מעבר לגיבוי בענן של SQL Server לדיסקים במצב מרובה כתיבה
• כך מפתחים אפליקציות אינטרנט עמידות שניתנות להרחבה ב- Google Cloud.
• מומלץ לעיין במדריך להכנת תוכנית התאוששות מאסון.