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

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

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

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

הפתרון מספק כמה רכיבים פונקציונליים מרכזיים לניהול מסד נתונים:

  • זמינות גבוהה אוטומטית: אפשר להשתמש ב-Patroni וב-etcd כדי לספק בחירה אוטומטית של שרת ראשי ויתירות כשל, וכך לוודא שמסד הנתונים ממשיך לפעול ללא התערבות ידנית.
  • עמידות במספר אזורים: פיזור של צמתי מסד הנתונים על פני שלושה אזורי זמינות שונים כדי להגן מפני הפסקות חשמל מקומיות או הפסקות בתשתית.
  • אוטומציה סטנדרטית: הקצאת כל הערימה באמצעות מחברות הפעלה מבוססות Ansible עם Autobase כדי להבטיח פריסות עקביות שניתנות לשחזור.
  • איגום חיבורים: שירות PgBouncer משולב לניהול מספרים גבוהים של חיבורים ולייצוב צריכת המשאבים בצמתי מסד הנתונים.
  • איזון עומסים גלובלי: אפשר להשתמש במאזן עומסים גלובלי ברמה L4 שמנוהל על ידי הפלטפורמה כדי לספק כתובת IP וירטואלית (VIP) יציבה וייחודית שאפשר לגשת אליה בכל האזורים.
  • מוכנות לשימוש בסביבה מבודדת: תהליכי עבודה מיוחדים לאריזת כל יחסי התלות וקבצי ההפעלה הנדרשים של מערכת ההפעלה לצורך פריסה בסביבות מנותקות.
  • הגנה על נתונים: כדאי להשתמש בכלים סטנדרטיים כמו pg_dump ו-pg_basebackup לצד תמונות מצב של אחסון ב-GDC כדי לשמור על אסטרטגיית גיבוי ושחזור חזקה.

ארכיטקטורה

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

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

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

  • קונצנזוס מבוסס-רוב: נעשה שימוש במודל מבוסס-קבוצות, שבו רוב הצמתים (2 מתוך 3) צריכים להסכים על מצב האשכול, כדי למנוע תרחישי 'פיצול מוח' ולהבטיח את תקינות הנתונים.
  • הפרדה בין תחומים: כל מכונה וירטואלית מריצה מחסנית שירותים (מסד נתונים, מנהל זמינות גבוהה, קונצנזוס ומאגר) שנמצאת באותו מיקום אבל נפרדת, כדי לספק צומת עצמאי ועמיד.
  • יתירות כשל עם מודעות למסד הנתונים: מתן עדיפות למדדי תקינות של מסד הנתונים באמצעות Patroni's API בארכיטקטורת REST כדי לתאם את ההפניה מחדש של תעבורת נתונים דרך מאזן העומסים (LB) של הפלטפורמה.
  • תשתית כקוד: מסתמכת על ספרי הפעלה אוטומטיים לכל משימות ההגדרה, וכך מצמצמת את הסיכון לטעויות אנוש במהלך הפריסה וההתאמה.

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

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

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

  • מכונות וירטואליות (VM): מכונות מחשוב ייעודיות שמפוזרות בין אזורים שונים כדי לארח את מחסנית מסד הנתונים.
  • מאזן עומסים גלובלי בשכבה 4: שירות שמנוהל על ידי הפלטפורמה ומספק כתובת IP וירטואלית (VIP) יציבה שמנתבת את תעבורת הנתונים לראש האשכול הנוכחי.
  • אחסון מתמיד: נדרש אחסון SSD עם ביצועים גבוהים כדי לעמוד בדרישות המחמירות של זמן האחזור עבור יומני הכתיבה מראש של שכבת הקונצנזוס.

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

  • ‫PostgreSQL 17: המנוע של מסד הנתונים הרלציוני המרכזי שאחראי על שמירת הנתונים ועל ביצוע השאילתות.
  • ‫Patroni: מנהל הזמינות הגבוהה שמנטר את תהליך PostgreSQL המקומי ומתאם את בחירת הלידים באמצעות etcd.
  • ‫etcd: מאגר ההגדרות המבוזר שמספק את שכבת הקונצנזוס ומכיל את המצב הסמכותי של האשכול.
  • ‫PgBouncer: כלי קל משקל לניהול מאגר חיבורים שנמצא לפני PostgreSQL כדי לטפל ביעילות בחיבורים נכנסים של אפליקציות.

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

  • ‫PgBouncer (יציאה 6432): נקודת הכניסה הראשית לתנועת נתונים של מסד נתונים של אפליקציה.
  • ‫Patroni API (יציאה 8008): ממשק REST של HTTPS שמאזן העומסים משתמש בו כדי לבצע בדיקות תקינות ולזהות את השרת הראשי הנוכחי באמצעות נקודת הקצה /primary.
  • ‫etcd (יציאה 2379): ערוץ התקשורת של אשכול הקונצנזוס לשמירה על מצב ולביצוע בחירות.

לתשומת ליבכם

  • מדרגיות וביצועים:
    • צריך לקבוע את הגודל של צמתי מסד הנתונים על סמך עומס העבודה, עם מינימום של 2 מעבדים וירטואליים ו-8GB של זיכרון RAM. עומסי עבודה של ייצור מתחילים בדרך כלל ב-8 vCPU וב-32‎ GiB.
    • הביצועים תלויים באחסון עם זמן אחזור נמוך. נדרשים כונני SSD כדי להבטיח ש-etcd יוכל לעבד סנכרונים של נתונים בפחות מ-10 אלפיות השנייה.
    • שכפול סינכרוני: התקורה של שכפול סינכרוני תלויה ישירות בחביון של הרשת בין אזורים. כדי להבטיח ביצועים אופטימליים של תצורות ללא אובדן נתונים, נדרש זמן אחזור נמוך בין האזורים.
  • ניהול משאבים ורישוי:
    • הפתרון הזה מסתמך על רכיבי מסד נתונים חינמיים בקוד פתוח.
    • ‫Autobase משמש ככלי אוטומציה להפניה כדי לייעל את ההתקנה וההגדרה של חבילת HA. עם זאת, הארכיטקטורה לא קשורה באופן בלעדי ל-Autobase, וניתן לנהל את רכיבי הקוד הפתוח הבסיסיים באמצעות צינורות (pipelines) בהתאמה אישית.
    • ארגונים שזקוקים לתמיכה רשמית בחבילת האוטומציה יכולים לרכוש תמיכה בתשלום מצד שלישי.
    • שימוש במאגר חיבורים עם PgBouncer חיוני כדי למנוע ניצול יתר של CPU וזיכרון שנגרם ממספר גבוה של חיבורי משתמשים.
  • זמינות ומהימנות:
    • זמינות גבוהה מושגת באמצעות קוורום של 3 צמתים. השירות לא יופרע אם צומת או אזור יכשלו.
    • יציבות האשכול: כדי לשמור על קוורום אמין, צריך זמן אחזור נמוך ברשת בין הצמתים. זמני הלוך ושוב (RTT) ממוצעים צריכים להיות מתחת ל-10 אלפיות השנייה כדי למנוע פסק זמן לבחירה וחוסר יציבות של האשכול.
  • ניהול תפעולי:
    • משימות שגרתיות כמו תיקון גרסאות משניות ושדרוגים גדולים נשארות באחריות צוות התפעול של הלקוח.
    • הפלט של מכונות ה-VM ב-stdout מוזן אוטומטית לפלטפורמת המעקב של GDC עם air gap. בעתיד נפרסם מדריך שיסביר איך לשלב מעקב מפורט יותר של הרכיבים השונים.
    • צריך להטמיע אסטרטגיית גיבוי חזקה באמצעות כלים מקוריים של מסד הנתונים ותמונות מצב של הפלטפורמה. מדריכים מפורטים לביצוע הפעולות האלה יפורסמו בנפרד.

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

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

מכונות וירטואליות ב-Kubernetes

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

איזון עומסים גלובלי שמקורו בפלטפורמה

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

  • כיסוי גלובלי: מספק כתובת IP וירטואלית יציבה שאפשר לגשת אליה בכל האזורים.
  • בניהול של הפלטפורמה: כתובת ה-VIP מנוהלת באופן עצמאי על ידי מישור הבקרה של הפלטפורמה.
  • מעבר גיבוי אוטומטי פשוט יותר: מעבר הגיבוי האוטומטי מנוהל באמצעות בדיקות תקינות רגילות במקום הגדרות תוכנה מקומיות מורכבות.
  • זמינות גבוהה: הסרת ההסתמכות על שרתי proxy מקומיים מבטיחה שנקודת הכניסה לתנועת הנתונים של מסד הנתונים תישאר עמידה.

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

הנחות

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

מגבלות

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

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