במאמר הזה מתוארות כמה ארכיטקטורות שמספקות זמינות גבוהה (HA) לפריסות של MySQL ב- Cloud de Confiance by S3NS. זמינות גבוהה היא מדד לעמידות המערכת בתגובה לכשל בתשתית הבסיסית. במסמך הזה, המונח 'זמינות גבוהה' מתייחס לזמינות של אשכולות MySQL בתוך אזור יחיד בענן.
המסמך הזה מיועד לאדמינים של מסדי נתונים, למומחי Cloud Architect ולמהנדסי DevOps שרוצים ללמוד איך לשפר את האמינות של שכבת הנתונים ב-MySQL על ידי שיפור זמן הפעולה הכולל של המערכת. המסמך הזה מיועד לכם אם אתם מריצים MySQL ב-Compute Engine. אם אתם משתמשים ב-Cloud SQL ל-MySQL, המאמר הזה לא רלוונטי עבורכם.
במערכת או באפליקציה שנדרש בהן מצב מתמשך כדי לטפל בבקשות או בעסקאות, שכבת שמירת הנתונים צריכה להיות זמינה כדי לטפל בהצלחה בבקשות לשאילתות נתונים או לשינויים בנתונים. אם האפליקציה צריכה לבצע אינטראקציה עם שכבת הנתונים כדי לטפל בבקשות, כל השבתה בשכבת הנתונים מונעת מהאפליקציה לבצע את המשימות הנדרשות.
בהתאם ליעדים למדידת רמת השירות (SLO) של המערכת, יכול להיות שתצטרכו טופולוגיה ארכיטקטונית שתספק רמת זמינות גבוהה יותר. יש יותר מדרך אחת להשיג זמינות גבוהה, אבל באופן כללי, אתם מקצים תשתית מיותרת שאפשר לגשת אליה במהירות מהאפליקציה.
במסמך הזה מפורטים הנושאים הבאים:
- הגדרת מונחים שיעזרו לכם להבין את המושגים שקשורים למסדי נתונים עם זמינות גבוהה.
- עוזרות לכם להבין כמה אפשרויות לטופולוגיות של HA MySQL.
- כדאי לספק מידע לפי ההקשר כדי להבין מה צריך לקחת בחשבון בכל אחת מהאפשרויות.
הסברים על המונחים
יש כמה מונחים ומושגים שהם סטנדרטיים בתעשייה וחשוב להכיר אותם גם למטרות אחרות שלא נכללות במסגרת המסמך הזה.
שכפול. התהליך שבו עסקאות כתיבה (INSERT, UPDATE או DELETE) נרשמות באופן מהימן ביומן, ואז מוחלות באופן סדרתי על כל צמתי מסד הנתונים בטופולוגיה.
שכפול סינכרוני. שיטה לשכפול נתונים שמבטיחה עקביות של נתונים בזמן אמת על ידי כתיבה בו-זמנית למסדי נתונים ראשיים ולמסדי נתונים משוכפלים.
שכפול חצי-סינכרוני. שיטה לשכפול נתונים שמבטיחה מידה מוגבלת של עקביות בנתונים על ידי כתיבה בו-זמנית למסד הנתונים הראשי ולפחות למסד נתונים משוכפל אחד נוסף.
שכפול אסינכרוני. שיטה לשכפול נתונים שמאפשרת השהיה בין העדכונים של המקור והעותק, ונותנת עדיפות לביצועים על פני עקביות מיידית.
צומת המקור. כל פעולות הכתיבה במסד הנתונים צריכות להיות מופנות לצומת מקור. צומת המקור מספק קריאה עם המצב העדכני ביותר של הנתונים שנשמרו.
צומת העתקה. עותק אונליין של צומת מסד הנתונים של המקור. השינויים משוכפלים כמעט באופן סינכרוני לצמתי העתקים מצומת המקור. אפשר לקרוא מצמתי רפליקה, אבל צריך להבין שהנתונים עשויים להתעדכן באיחור קל בגלל פרק הזמן מהחשיפה להמרה.
השהיית שכפול. מדד זמן שמבטא את ההפרש בין המועד שבו העסקה מוחלת על העותק לבין המועד שבו היא מוחלת על צומת המקור.
זמן פעולה תקינה. אחוז הזמן שבו מקור מידע פועל ויכול לספק תשובה לבקשה.
זיהוי כשלים. התהליך של זיהוי כשל בתשתית.
יתירות כשל. התהליך שבו מקדמים את תשתית הגיבוי (במקרה הזה, צומת העותק) כדי שתהפוך לתשתית הראשית (צומת המקור).
יעד משך ההתאוששות (RTO). משך הזמן, בזמן שחלף בפועל, שבו שכבת הנתונים יכולה להיות במצב אופליין עד שתהליך המעבר לגיבוי מסתיים, מנקודת מבט עסקית.
יעד להתאוששות מאסון (RPO). משך הזמן, בזמן שעבר בפועל, שבו מותר לאבד נתונים עד להשלמת תהליך המעבר לגיבוי, מנקודת מבט עסקית.
חלופה. התהליך להחזרת צומת המקור הקודם אחרי מעבר לגיבוי.
תיקון עצמי. היכולת של מערכת לפתור בעיות בלי פעולות חיצוניות של מפעיל אנושי.
חלוקת משאבי רשת למחיצות. מצב שבו שני צמתים בטופולוגיה, למשל צומת המקור וצומת העותק, לא יכולים לתקשר זה עם זה ברשת.
מוח מפוצל. מצב שבו שני צמתים מאמינים בו-זמנית שהם צומת המקור.
קבוצת צמתים. קבוצה של משימות של משאבי מחשוב שמספקות שירות. במסמך הזה, השירות הזה הוא שכבת שימור הנתונים.
צומת עדים או צומת קוורום. משאב נפרד של מחשוב שעוזר לקבוצת צמתים לקבוע מה לעשות כשמתרחש מצב של פיצול מוח.
בחירת מקור או בחירת מנהיג. התהליך שבו קבוצה של צמתים עם מודעות לעמיתים, כולל צמתים של עדים, קובעת איזה צומת צריך להיות צומת המקור.
קבוצת צמתים. קבוצה של משימות של משאבי מחשוב שמספקות שירות. במסמך הזה, השירות הזה הוא שכבת שימור הנתונים.
המתנה פעילה. צומת שמייצג עותק כמעט זהה של צומת מקור אחר, ויכול להפוך לצומת המקור החדש עם זמן השבתה מינימלי.
מתי כדאי לשקול ארכיטקטורה של זמינות גבוהה
ארכיטקטורות HA מספקות הגנה משופרת מפני השבתה של שכבת הנתונים. כדי לבחור את האפשרות המתאימה לתרחיש לדוגמה של העסק שלכם, חשוב להבין מהי הסבילות שלכם להשבתה, ואת היתרונות והחסרונות של הארכיטקטורות השונות.
כדאי להשתמש בטופולוגיה של זמינות גבוהה כשרוצים לספק זמן פעולה משופר של שכבת הנתונים כדי לעמוד בדרישות המהימנות של עומסי העבודה והשירותים. בסביבות שבהן יש סובלנות לזמן השבתה מסוים, טופולוגיה של זמינות גבוהה (HA) מוסיפה עלויות ומורכבות שלא לצורך. לדוגמה, בסביבות פיתוח או בדיקה לא תמיד נדרשת זמינות גבוהה של רמת מסד הנתונים.
הגדרת הדרישות לזמינות גבוהה
העלות היא שיקול חשוב, כי צריך לצפות לעלייה של לפחות פי שניים בעלויות של תשתית המחשוב והאחסון כדי לספק זמינות גבוהה. חשוב להעריך היטב את העלות הזו בהשוואה להשפעה הפיננסית הפוטנציאלית של זמן ההשבתה. כשמעריכים את האפשרויות האפשריות לזמינות גבוהה של MySQL, כדאי לשקול את השאלות הבאות:
- אילו שירותים או לקוחות מסתמכים על רמת הנתונים שלכם?
- מה התקציב התפעולי שלך?
- מה העלות לעסק שלכם במקרה של השבתה בשכבת העמידות של הנתונים?
- כמה אוטומטי התהליך צריך להיות?
- מה רמת הזמינות שאתם רוצים להשיג: 99.5%, 99.9% או 99.99%?
- תוך כמה זמן צריך לבצע מעבר לגיבוי? מהם יעדי הזמן לשחזור (RTO) ויעדי נקודת השחזור (RPO) שלכם?
הגורמים הבאים משפיעים על זמן השחזור, ולכן חשוב לקחת אותם בחשבון כשקובעים את ה-RTO ואת ה-RPO:
- זיהוי ההשבתה
- מוכנות של מכונה וירטואלית (VM) משנית
- סוג השכפול ותדירות הגיבוי
- מעבר לגיבוי במקרה של כשל באחסון
- זמן השחזור של מסד הנתונים
- זמן השחזור של האפליקציה
ארכיטקטורות של HA ב-MySQL
ברמה הבסיסית ביותר, זמינות גבוהה בשכבת הנתונים מורכבת מהרכיבים הבאים:
- מנגנון לזיהוי כשל בצומת המקור.
- תהליך לביצוע מעבר לגיבוי בעת כשל, שבו צומת העותק מקודם להיות צומת מקור.
- תהליך לשינוי ניתוב השאילתות כך שבקשות האפליקציה יגיעו לצומת המקור החדש.
- אפשרות: שיטה לחזרה לטופולוגיה המקורית באמצעות צמתים של מקור ועותק.
במסמך הזה נדון בשלוש ארכיטקטורות של זמינות גבוהה:
בנוסף לכשל בתשתית, כל אחת מהארכיטקטורות האלה יכולה לעזור למזער את זמן ההשבתה במקרה הלא סביר של הפסקת חשמל אזורית. אתם משתמשים בארכיטקטורות האלה עם שינויים במערכת שמות הדומיין (DNS) כדי לספק זמינות גבוהה (HA) במספר אזורים, כדי להגן מפני הפרעות בשירותים אזוריים, אבל במסמך הזה נדון בהפסקות חשמל אזוריות.
זמינות גבוהה עם דיסקים לאחסון מתמיד אזורי
זמינות גבוהה בשכבת הנתונים תמיד מסתמכת על סוג מסוים של שכפול נתונים. השכפול הפשוט ביותר הוא שכפול שלא צריך לנהל.
בעזרת אפשרות האחסון regional Persistent Disk מ-Compute Engine, אתם יכולים להקצות מכשיר לאחסון בלוקים שמספק שכפול נתונים סינכרוני בין שני אזורים באזור. דיסקים לאחסון מתמיד של אזור מספקים אבן בניין חזקה ליישום שירותים של זמינות גבוהה ב-Compute Engine.
התרשים הבא מדגים את הארכיטקטורה של זמינות גבוהה עם דיסקים קשיחים אזוריים.
אם המכונה הווירטואלית של צומת המקור הופכת ללא זמינה בגלל כשל בתשתית או הפסקה זמנית בשירות באזור, אפשר לכפות את צירוף דיסק האחסון המתמיד האזורי למכונה וירטואלית באזור הגיבוי באותו אזור.
כדי לבצע את המשימה הזו, צריך לבצע אחת מהפעולות הבאות:
- מפעילים מכונה וירטואלית נוספת באזור הגיבוי שבו יש גישה לדיסק קשיח אזורי משותף.
- שומרים על מופע VM של המתנה פעילה באזור הגיבוי. מכונה וירטואלית במצב המתנה פעיל היא מכונה וירטואלית שפועלת וזהה למכונה שבה אתם משתמשים. אחרי שמחברים את ה-Persistent Disk האזורי, אפשר להפעיל את המנוע של מסד הנתונים.
אם מזהים במהירות את ההשבתה של שירות הנתונים, פעולת הצירוף הכפוי בדרך כלל מסתיימת תוך פחות מדקה, מה שאומר שאפשר להשיג RTO שנמדד בדקות, עם RPO של אפס.
אם העסק שלכם יכול לסבול את זמן ההשבתה הנוסף שנדרש כדי לזהות הפסקת חשמל ולדווח עליה, וכדי לבצע את המעבר לגיבוי ידנית, אין צורך להפוך את התהליך לאוטומטי.
אם סף הטולרנס שלכם ל-RTO נמוך יותר, אתם יכולים להפוך את תהליך הזיהוי והמעבר האוטומטי לגיבוי לאוטומטי. אם תבצעו אוטומציה של הארכיטקטורה הזו, המערכת תהיה מורכבת יותר כי יש כמה מקרים קיצוניים בתהליך המעבר לגיבוי והחזרה לגיבוי הקודם שצריך לקחת בחשבון. למידע נוסף על הטמעה אוטומטית מלאה של הארכיטקטורה הזו, אפשר לעיין במאמר בנושא הגדרת זמינות גבוהה ב-Cloud SQL.
יתרונות
יש כמה יתרונות להשגת זמינות גבוהה באמצעות דיסקים קשיחים אזוריים, בגלל התכונות הבאות:
הארכיטקטורה הזו מספקת הגנה בו-זמנית מפני כמה מצבי כשל: כשל בתשתית של אזור שרת המקור, ירידה ברמת האחסון בבלוקים באזור יחיד או הפסקת פעילות מלאה באזור.
אין צורך בשכפול של שכבת האפליקציה או מסד הנתונים, כי דיסקים קשיחים אזוריים מספקים שכפול נתונים רציף וסינכרוני ברמת הבלוק, שמנוהל באופן מלא על ידי Cloud de Confiance. דיסק מתמשך אזורי מזהה באופן אוטומטי שגיאות והאטה, מחליף את מצב השכפול ומבצע השלמה של נתונים שמשוכפלים רק לאזור אחד.
אם יש בעיות באחסון באזור ראשי, קריאות של דיסק קשיח אזורי מתבצעות באופן אוטומטי מהאזור המשני. הפעולה הזו עלולה להוביל לעלייה בזמן האחזור של הקריאה, אבל האפליקציה יכולה להמשיך לפעול בלי שתידרש פעולה ידנית.
לתשומת ליבכם
המגבלות של הארכיטקטורה הזו קשורות לאופי האזורי של הטופולוגיה הזו ולחלק מהמגבלות המובנות הבאות של דיסקים קשיחים אזוריים:
- אפשר לצרף את הדיסק לאחסון מתמיד האזורי רק למסד נתונים אחד. גם אם המכונה הווירטואלית של מסד הנתונים במצב המתנה פועלת, אי אפשר להשתמש בה כדי להציג קריאות של מסד הנתונים. עם זאת, עם Hyperdisk Balanced High Availability של Google Cloud במצב multi-writer, כמה מופעים יכולים לקרוא ולכתוב לאותו דיסק. מידע נוסף על Hyperdisk זמין במאמר מידע על Hyperdisk.
- הטכנולוגיה הבסיסית שמאחורי הארכיטקטורה הזו מאפשרת שכפול רק בין אזורים באותו אזור . לכן, יתירות כשל אזורי הוא לא אפשרות כשמשתמשים רק בארכיטקטורה הזו.
- קצב העברת הנתונים (throughput) של כתיבה בדיסקים לאחסון מתמיד אזורי נמוך בחצי בהשוואה לדיסקים לאחסון מתמיד של אזור. חשוב לוודא שמגבלות התפוקה נמצאות בטווח הסבילות הנדרש.
- זמן האחזור של כתיבה בדיסק אזורי לאחסון מתמיד (persistent disk) גבוה מעט מזמן האחזור של כתיבה בדיסק של תחום מוגדר לאחסון מתמיד. מומלץ לבדוק את עומס העבודה כדי לוודא שביצועי הכתיבה עומדים בדרישות שלכם.
- במהלך אירוע כשל והמעבר שנובע ממנו, צריך לכפות על דיסק האחסון המתמיד האזורי להתחבר למכונת ה-VM באזור ההמתנה. הפעולה force-attach בדרך כלל מתבצעת תוך פחות מדקה, ולכן צריך לקחת את הזמן הזה בחשבון כשמעריכים את זמן ההתאוששות (RTO).
- ההערכה של RTO צריכה לכלול את הזמן שנדרש לחיבור הכפוי של דיסק האחסון המתמיד האזורי ולזיהוי של מערכת הקבצים של מכונת ה-VM של הדיסק שמחובר בזמן ההפעלה.
זמינות גבוהה עם המתנה פעילה וצומת עדים
אם רוצים מעבר אוטומטי לגיבוי, נדרשת ארכיטקטורה שונה. אפשרות אחת היא לפרוס קבוצה של לפחות שני צמתי מסד נתונים, להגדיר שכפול אסינכרוני של מסד הנתונים ולהפעיל צמתי עדים כדי להבטיח שאפשר יהיה להגיע לקוורום במהלך בחירה של צומת מקור.
צומת מסד הנתונים של המקור מעבד עסקאות כתיבה ומשרת שאילתות קריאה. תהליך השכפול של מסד הנתונים מעביר שינויים לצומת המשוכפל של הגיבוי הפעיל אונליין.
מכיוון שצומת העד יכול להיות מכונה וירטואלית קטנה, הוא מספק מנגנון בעלות נמוכה כדי לוודא שרוב הקבוצה זמין לבחירת צומת מקור.
צמתי קבוצה מעריכים באופן רציף את הסטטוס של צמתי הקבוצה האחרים. האותות שבודקים את הסטטוס כל כמה שניות נקראים פעימות לב, כי הם משמשים להערכת תקינות הצמתים בקבוצה השנייה. חשוב לבצע הערכה בזמן של תקינות הצומת במסד הנתונים, כי צריך לזהות במהירות צומת לא תקין במסד הנתונים של המקור כדי שאפשר יהיה להתחיל בהעברה אוטומטית של הגיבוי הפעיל.
הקוורום של קבוצת הצמתים נקבע לפי מספר הרכיבים המצביעים שצריכים להיות חלק מחברות פעילה באשכול כדי שהאשכול יתחיל לפעול בצורה תקינה או ימשיך לפעול. כדי שקבוצת צמתים תגיע לקוורום בבחירות של צומת מסד נתונים במקור, רוב הצמתים בקבוצה צריכים להשתתף. כדי למנוע מצב של פיצול מוח, דרישת הרוב מבטיחה שבמקרה של חלוקת הרשת, לא יהיו בו-זמנית שתי קבוצות הצבעה עם מספיק צמתים להצבעה.
רוב בקבוצה מורכב מ-(n+1)/2 צמתים, כאשר n הוא המספר הכולל של הצמתים בקבוצה. לדוגמה, אם יש שלוש צמתים בקבוצה, לפחות שני צמתים צריכים לפעול כדי לבחור צומת מקור. אם יש חמישה צמתים בקבוצה, נדרשים לפחות שלושה צמתים.
גודל הקבוצות הוא מספר אי-זוגי של צמתים, למקרה שיש חלוקה של הרשת שמונעת תקשורת בין קבוצות משנה של קבוצת הצמתים. אם הקבוצה היא זוגית, יש סיכוי גבוה יותר ששתי קבוצות המשנה יוכלו להכיל פחות מהרוב. אם גודל הקבוצה הוא מספר אי-זוגי, סביר יותר שאחת מקבוצות המשנה תהיה ברוב או שאף אחת מהקבוצות לא תהיה ברוב.
בתרשים הבא מוצגת השוואה בין קבוצת צמתים תקינה לבין קבוצת צמתים עם בעיות.
בתרשים מוצגות שתי קבוצות של צמתים – קבוצת צמתים פונקציונלית וקבוצת צמתים עם ביצועים ירודים. בקבוצת הצמתים שפועלת בצורה מלאה ותקינה יש שלושה חברים. במצב הזה, צומתי מסד הנתונים של המקור והרפליקה מספקים את המטרה הצפויה שלהם. הקבוצה הזו של הצמתים צריכה קוורום של שני צמתים.
קבוצת הצמתים עם הביצועים הירודים מציגה את המצב שבו פעימות הלב של צומת המקור לא נשלחות יותר בגלל כשל בתשתית. יכול להיות שהמצב הזה הוא תוצאה של כשל במופע של צומת מסד הנתונים של המקור, או שהצומת של המקור עדיין פועל. לחלופין, יכול להיות שחלוקת הרשת תמנע תקשורת בין צומת המקור לבין הצמתים האחרים בקבוצה.
לא משנה מה הסיבה, התוצאה היא שגם העותק וגם העד קובעים שצומת המקור כבר לא תקין. בשלב הזה, רוב הקבוצה עורכת בחירה של צומת מקור, קובעת שצומת הגיבוי הפעיל צריך להפוך לצומת המקור ומתחילה את המעבר לגיבוי.
התרשים הבא מציג את תהליך העברת הנתונים של העסקה, השכפול והדופק במסד הנתונים בארכיטקטורת צומת העד.
בתרשים הקודם, ארכיטקטורת ה-HA הזו מסתמכת על צומת רפליקה במצב המתנה פעילה כדי להתחיל במהירות לעבד כתיבות של נתוני ייצור במקרה של מעבר לגיבוי. מנגנון המעבר לגיבוי (failover) – למשל, קידום של צומת מקור – מבוצע על ידי צמתי מסד הנתונים בקבוצה.
כדי להטמיע את הארכיטקטורה הזו, כדאי להשתמש בשני הפרויקטים הבאים:
- MySQL Group Replication הוא פלאגין קוד פתוח ל-MySQL שמקל על יצירת טופולוגיות של זמינות גבוהה (HA).
- Galera Cluster ו-Percona XtraDB Cluster הן אפשרויות נוספות של קוד פתוח שיכולות לספק זמינות גבוהה.
יתרונות
לארכיטקטורה של המתנה פעילה יש מעט חלקים נעים, היא פשוטה להטמעה ומספקת כמה יתרונות:
- עם צומת עדים אחד נוסף בעלות נמוכה, מתקבל מעבר גיבוי אוטומטי לחלוטין.
- הארכיטקטורה הזו יכולה לטפל ביעילות בכשלים בתשתית לטווח ארוך ובכשלים זמניים (לדוגמה, בגלל הפעלה מחדש של המערכת).
- זמינות גבוהה במספר אזורים מסופקת עם השהיית שכפול משויכת.
לתשומת ליבכם
המעבר לגיבוי אוטומטי, אבל הפעולות הבאות עדיין נדרשות:
- אתם מנהלים את השכפול בין צומתי המקור וההעתק.
- אתם מנהלים את צמתי העדים.
- צריך לפרוס ולנהל את ניתוב החיבור באמצעות מאזן עומסים.
- בלי לבצע שינויים בלוגיקה של האפליקציה, שהם מעבר להיקף של המסמך הזה, אי אפשר להפנות קריאות לצומת המשוכפל.
HA עם Orchestrator ו-ProxySQL
אם משלבים את רכיבי הקוד הפתוח Orchestrator ו-ProxySQL, מקבלים ארכיטקטורה שיכולה לזהות הפסקות שירות ולבצע מעבר אוטומטי של התנועה ממקור בעייתי לשכפול תקין שקודם לאחרונה.
בנוסף, אפשר להפנות שאילתות בצורה שקופה לצמתים המתאימים לקריאה או לקריאה ולכתיבה, כדי לשפר את הביצועים של שכבת הנתונים במצב יציב.
Orchestrator הוא כלי בקוד פתוח לניהול טופולוגיית שכפול של MySQL ופתרון למעבר לגיבוי (failover). התוכנה מאפשרת לכם לזהות, לשאול ולשנות טופולוגיות מורכבות של שכפול, ומספקת זיהוי אמין של כשלים, שחזור חכם וקידום.
ProxySQL הוא שרת proxy בקוד פתוח, עם ביצועים גבוהים וזמינות גבוהה, שמודע לפרוטוקול של MySQL. היכולת של ProxySQL להתרחב מאפשרת לו לטפל במיליוני חיבורים במאות אלפי שרתים בעורף.
התרשים הבא מציג את הארכיטקטורה המשולבת של Orchestrator ו-ProxySQL.
בארכיטקטורה הזו, כפי שמוצג בתרשים הקודם, תנועה שמוגבלת למסד נתונים מנותבת על ידי מאזן עומסים פנימי למופעים מיותרים של ProxySQL. המכונות האלה מעבירות את התעבורה למכונת מסד נתונים עם יכולת כתיבה או קריאה, על סמך ההגדרה של ProxySQL.
הכלי Orchestrator מספק את השלבים הבאים לזיהוי כשלים ולשחזור:
- הכלי Orchestrator קובע שצומת מסד הנתונים של המקור לא זמין.
- מתבצעת שאילתה בכל הצמתים המשוכפלים כדי לקבל חוות דעת שנייה לגבי הסטטוס של צומת המקור.
- אם הרפליקות מספקות בדיקה עקבית שלפיה המקור לא זמין, יתירות הכשל תופעל.
- כפי שמוגדר בטופולוגיה, הצומת המקודם הופך לצומת המקור החדש במהלך המעבר לגיבוי.
- כשהגיבוי האוטומטי מסתיים, Orchestrator עוזר לוודא שמספר הצמתים החדשים של השכפול מוקצים בהתאם לטופולוגיה.
רפליקציה מתמשכת בין מסד הנתונים של המקור באזור א' לבין העותקים של מסד הנתונים באזורים חלופיים שומרת על העדכניות של העותקים בכל כתיבה שמופנית למקור. הכלי Orchestrator בודק את תקינות מסדי הנתונים של המקור וההעתק על ידי שליחת פעימות לב באופן רציף. מצב האפליקציה של Orchestrator נשמר במסד נתונים נפרד של Cloud SQL. אם נדרשים שינויים בטופולוגיה, Orchestrator יכול גם לשלוח פקודות למסדי הנתונים.
ProxySQL מנתב את התנועה בצורה מתאימה לצמת המקור וההעתק החדשות כשהמעבר לגיבוי מלא הושלם. השירותים ממשיכים לפנות לרמת הנתונים באמצעות כתובת ה-IP של מאזן העומסים. כתובת ה-IP הווירטואלית מועברת בצורה חלקה מצומת המקור הקודם לצומת המקור החדש.
יתרונות
רכיבי הארכיטקטורה והאוטומציה מספקים את היתרונות הבאים:
- התוכנה שמשמשת בארכיטקטורה הזו מספקת תכונות שונות של יכולת צפייה, כולל גרפים של טופולוגיית שכפול ונתוני תנועת שאילתות.
- ProxySQL ו-Orchestrator פועלים יחד כדי לספק קידום אוטומטי של העתקים ומעבר לגיבוי בעת כשל.
- אפשר להגדיר את מדיניות הקידום של העותק באופן מלא. בניגוד להגדרות אחרות של זמינות גבוהה, במקרה של מעבר לגיבוי (failover) אפשר לבחור לקדם צומת שכפול ספציפי למקור.
- אחרי יתירות כשל, מוקצים רפליקות חדשות באופן הצהרתי בהתאם לטופולוגיה.
- ProxySQL מספק יתרון נוסף של איזון עומסים, כי הוא מנתב באופן שקוף בקשות קריאה וכתיבה לצמתים המתאימים של העותק והמקור על סמך המדיניות שהוגדרה.
לתשומת ליבכם
הארכיטקטורה הזו מגדילה את האחריות התפעולית וגורמת לעלויות אירוח נוספות בגלל השיקולים הבאים:
- צריך לפרוס את Orchestrator ואת ProxySQL ולתחזק אותם.
- ל-Orchestrator נדרש מסד נתונים נפרד כדי לשמור את המצב.
- צריך להגדיר את Orchestrator ואת ProxySQL לזמינות גבוהה, ולכן יש מורכבות נוספת בהגדרות ובפריסה.
בנוסף, Orchestrator לא תומך בשכפול ממקורות מרובים, לא תומך בכל סוגי השכפול המקביל ולא ניתן לשלב אותו עם תוכנות לאשכולות כמו Galera או Percona XtraDB. מידע נוסף על המגבלות הנוכחיות זמין בשאלות הנפוצות בנושא Orchestrator.
המאמרים הבאים
- מידע על הגדרת זמינות גבוהה ב-Cloud SQL
- מידע נוסף על אפשרויות זמינות גבוהה באמצעות דיסקים קשיחים אזוריים
- כדאי לעיין במסמכי התיעוד בנושא שכפול קבוצתי של MySQL.
- מידע נוסף על Galera Cluster או על Percona XtraDB Cluster.
- כדאי לעיין במסמכי התיעוד של Orchestrator.
- ProxySQL
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.