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

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

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

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

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

עקרונות ארכיטקטוניים

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

ארכיטקטורה

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

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

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

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

  • מכונות וירטואליות (VM): שלוש מכונות ייעודיות של Compute, שכל אחת מהן פרוסה באזור זמינות נפרד כדי ליצור את גבולות דומיין הכשל.
  • ‫GDC Global L4 Load Balancer: מבנה רשת שמנוהל על ידי הפלטפורמה וחושף כתובת VIP פנימית יציבה, שמעריך באופן אוטומטי את בדיקות התקינות של נתב MySQL כדי להפנות מחדש את התנועה הנכנסת.

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

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

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

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

לתשומת ליבכם

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

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

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

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

הנחות

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

מגבלות

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

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