ארכיטקטורת עזר של מסד נתונים של MySQL ב-GDC עם air gap

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

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

תכונות ויכולות

  • עמידות בכמה אזורים: הגדרה עמידה במיוחד של 3 צמתים שנפרסת על פני שלושה אזורי זמינות נפרדים כדי להגן מפני כשלים באזור תשתית יחיד.
  • זמינות גבוהה וקונצנזוס אוטומטיים: נעשה שימוש בשכפול קבוצתי עבור אשכולות קונצנזוס מבוססי Paxos, שמספקים זיהוי אוטומטי של כשלים, הסכמה בין צמתים וסנכרון נתונים גלובלי ללא תרחישי פיצול מוח.
  • ניתוב חכם של תעבורת נתונים: מופעים של MySQL Router שמוצבים באותו מיקום מנהלים את ניתוב החיבורים. הנתב מפנה פעולות כתיבה (לדוגמה, יציאה 6446) רק לצומת ראשי פעיל, ומבצע איזון עומסים של פעולות קריאה (לדוגמה, יציאה 6447) בין העותקים המשוכפלים המסונכרנים.
  • איזון עומסים גלובלי: משולב עם מאזן העומסים הגלובלי ברמה 4 של GDC כדי לספק כתובת IP וירטואלית (VIP) יציבה אחת לאפליקציות לקוח, וכך להסתיר את טופולוגיית הצמתים הבסיסית.

עקרונות אדריכליים

  • הסכמה שמבוססת על קוורום: נותנת עדיפות לעקביות נתונים מחמירה. השכפול הקבוצתי מבוסס על מודל Paxos שדורש הסכמה של רוב חברי הקבוצה, ולכן מבטל את הסיכון לאובדן נתונים או לפיצול המוח במהלך חלוקת הרשת.
  • הפרדה בין תחומים: מפרידים בין מנוע מסד הנתונים ושכבת הקונצנזוס (Group Replication) לבין שכבת ניתוב תעבורת הלקוחות (MySQL Router), תוך פישוט הניהול של מחזור החיים של האשכול באמצעות MySQL Shell.
  • אופטימיזציה של התשתית: פתרון שתוכנן במיוחד לסביבות מבודדות, שמשתמש במכונות וירטואליות חזקות כדי לעקוף את המגבלות הנוכחיות של רשתות Kubernetes.

ארכיטקטורה

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

מושגים וטכנולוגיות

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

תשתית ופלטפורמה

  • מכונות וירטואליות (VM): שלושה מופעי Compute ייעודיים, שכל אחד מהם נפרס באזור זמינות נפרד כדי ליצור את הגבולות של תחום הכשל.
  • מאזן עומסים גלובלי ברמה 4 של GDC: מבנה רשת שמנוהל על ידי הפלטפורמה, שחושף כתובת IP וירטואלית פנימית יציבה, ומעריך באופן אוטומטי את בדיקות התקינות של MySQL Router כדי להפנות מחדש תנועה נכנסת.

שירותים ולוגיקה

  • ‫MySQL 8.4: המנוע של מסד הנתונים הרלציוני.
  • ‫Group Replication / InnoDB Cluster: מסגרת האשכולות המובנית שאחראית על שכפול מרובה ראשי ועל אימות של קוורום הצמתים באמצעות Paxos.
  • ‫MySQL Shell: ממשק שורת הפקודה המאוחד שמשמש במיוחד להגדרה, להקצאה ולניהול של מכונות באשכול InnoDB.
  • ‫MySQL Router: פועל כנתב תנועה בכל מכונת VM. מוגדר באופן דינמי להאזנה למטא-נתונים של האשכול ולהעברת תנועה: פעיל/גיבוי לכתיבה ושיטת רובין עגול לקריאה.

זרימת נתונים וממשקים

  1. האפליקציות שולחות בקשות למסד הנתונים אל כתובת ה-VIP של מאזן העומסים הגלובלי GDC L4.
  2. מאזן העומסים מעביר את החיבור באמצעות פרוקסי למופע תקין של MySQL Router באחת מהמכונות הווירטואליות.
  3. בהתאם ליציאה המבוקשת, MySQL Router מעביר את התנועה באופן דינמי: יציאה 6446 מכוונת באופן בלעדי לצומת הפעיל לצורך כתיבה, ואילו יציאה 6447 מעבירה קריאות באופן מחזורי בין הצמתים באשכול.

לתשומת ליבכם

  • הפשרה בין ביצועים לעקביות: מכיוון ש-Group Replication אוכף קונצנזוס, טרנזקציות דורשות אישור מעמיתים באשכול. הביצועים קשורים ישירות לזמן האחזור ברשת בין האזורים בסביבת GDC.
  • ניהול משאבים: פריסה של MySQL Router ישירות במכונות הווירטואליות של מסד הנתונים מייעלת את השימוש בחומרה, אבל דורשת כוונון מדויק של המשאבים כדי למנוע מצב שבו התקורה של איגום החיבורים גורמת לתהליכי הליבה של MySQL לא לקבל מספיק משאבים.

החלטה בנוגע לעיצוב

  • מכונות וירטואליות ב-Kubernetes: GDC עם בידוד פיזי לא תומך באשכולות Kubernetes שמשתרעים על פני כמה אזורים פיזיים. הגישה שמבוססת על מכונות וירטואליות נבחרה באופן בלעדי כי פריסת מכונות וירטואליות ייעודיות באזורים נפרדים היא השיטה היחידה שמאפשרת להשיג זמינות גבוהה אמיתית בכמה אזורים, ולשרוד כשל מוחלט באזור.
  • אשכול InnoDB לעומת Orchestrator ו-ProxySQL: נבדקה ארכיטקטורה מסורתית של primary/secondary בשילוב עם ProxySQL ו-Orchestrator כחלופה אפשרית. עם זאת, נבחרה האפשרות המובנית InnoDB Cluster (שילוב של Group Replication‏, MySQL Router ו-MySQL Shell), כי היא מבטלת את ההסתמכות על שכבות-על של ניתוב מצד שלישי ומפשטת באופן משמעותי את המורכבות התפעולית של מעבר לגיבוי בשעת כשל, על ידי שמירה על ההסכמה ישירות ב-MySQL.
  • איזון עומסים גלובלי שמוטמע בפלטפורמה: שימוש במאזן העומסים הגלובלי L4 של GDC מבטיח שכתובת ה-VIP נשלטת על ידי מישור הבקרה של GDC, כך שנקודת הכניסה עמידה ומסירת התעבורה בין האזורים פשוטה יותר.

הנחות ומגבלות

הנחות

  • זמינות של תשתית: ללקוחות יש מכסות פרויקט מספיקות להקצאת מכונות וירטואליות ייעודיות בגודל המתאים ומאזני עומסים גלובליים שמפוזרים באופן שווה על פני שלושה אזורי זמינות.
  • אבטחת הרשת: גישה שמבוססת על מפתח ומדיניות נכונה של ProjectNetworkPolicies ‏(PNPs) מוגדרות כדי לאפשר סנכרון של שכפול קבוצתי בתוך האשכול ותעבורת נתונים של MySQL Router.

מגבלות

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

חומרים נוספים