ארכיטקטורת העזר הזו מספקת מסגרת קונספטואלית לפריסה ולהפעלה של מסדי נתונים של PostgreSQL בניהול הלקוח ב-Google Distributed Cloud (GDC) עם air gap. הפתרון הזה מאפשר לארגונים לתחזק עומסי עבודה קריטיים של מסדי נתונים, באמצעות אשכול עם זמינות גבוהה (HA) בכמה אזורים שפרוס במכונות וירטואליות.
הארכיטקטורה מתמקדת בהגדרה גמישה של 3 צמתים, שמבטיחה את הזמינות של מסד הנתונים גם במקרה של כשל באזור או בתשתית אחת. הוא מכסה את מחזור החיים המלא, החל מהקצאה ורישות אוטומטיים ועד לפעולות ברמת הייצור, כמו זמינות גבוהה, גיבוי, שחזור וניטור.
תכונות ויכולות
הפתרון מספק כמה רכיבים פונקציונליים עיקריים לניהול מסדי נתונים:
- זמינות גבוהה אוטומטית: משתמשים ב-Patroni וב-etcd כדי לספק בחירת מנהיג ויתירות כשל באופן אוטומטי, וכך לוודא שמסד הנתונים ימשיך לפעול בלי התערבות ידנית.
- עמידות בכמה אזורים: פיזור צומתי מסד הנתונים בשלושה אזורי זמינות נפרדים כדי להגן מפני הפסקות מקומיות בחומרה או בתשתית.
- אוטומציה סטנדרטית: הקצאת כל המקבץ באמצעות פלייבוקים שמבוססים על Ansible עם Autobase, כדי להבטיח פריסות עקביות וניתנות לשחזור.
- מאגר חיבורים: שירות PgBouncer משולב לניהול מספרים גבוהים של חיבורים ולייצוב צריכת המשאבים בצומתי מסד הנתונים.
- איזון עומסים גלובלי: משתמשים במאזן עומסים גלובלי ברמת L4 שמנוהל על ידי הפלטפורמה כדי לספק כתובת IP וירטואלית (VIP) יציבה אחת, שאפשר לגשת אליה מכל האזורים.
- מוכנות ל-air gap: תהליכי עבודה מיוחדים לאריזת כל יחסי התלות והקבצים הבינאריים הנדרשים של מערכת ההפעלה לפריסה בסביבות מנותקות.
- הגנה על נתונים: אתם יכולים להשתמש בכלים סטנדרטיים כמו
pg_dumpו-pg_basebackupלצד תמונות מצב של האחסון ב-GDC, כדי לשמור על אסטרטגיית גיבוי ושחזור חזקה.
ארכיטקטורה
הארכיטקטורה מורכבת מסביבה של שלוש מכונות וירטואליות שפרוסות על פני שלושה אזורי זמינות, שמריצים סטאק של שירותים באותו מיקום.
עקרונות ארכיטקטוניים
- קונצנזוס מבוסס-רוב: משתמש במודל מבוסס-קוורום שבו רוב הצמתים (2 מתוך 3) חייבים להסכים על מצב האשכול, כדי למנוע תרחישים של "פיצול מוח" ולהבטיח את תקינות הנתונים.
- הפרדת תחומי האחריות: כל מכונה וירטואלית מריצה סטאק נפרד של שירותים (מסד נתונים, מנהל HA, קונצנזוס ו-pooler) שנמצא באותו מיקום, כדי לספק צומת עצמאי וגמיש.
- יתירות כשל עם מודעות למסד הנתונים: מתעדפת מדדי תקינות של מסד הנתונים באמצעות ה-API בארכיטקטורת REST של Patroni, כדי לתאם את ההפניה מחדש של התנועה דרך מאזן העומסים של הפלטפורמה.
- תשתית כקוד: מסתמכת על פלייבוקים אוטומטיים לכל משימות ההגדרה, וכך מפחיתה את הסיכון לטעויות אנוש במהלך הפריסה וההתאמה לעומס.
מושגים וטכנולוגיות
בקטע הזה מפורטים הרכיבים הפונקציונליים, תחומי האחריות שלהם ואופן התקשורת שלהם בתוך המערכת.
תשתית ופלטפורמה
- מכונות וירטואליות (VM): מכונות ייעודיות שפרוסות באזורים שונים ומארחות את מחסנית מסד הנתונים.
- מאזן עומסים גלובלי בשכבה 4: שירות שמנוהל על ידי הפלטפורמה ומספק כתובת IP וירטואלית (VIP) יציבה, שמנתבת את התנועה ל-leader הנוכחי של האשכול.
- אחסון מתמיד: נדרש אחסון מגובה ב-SSD עם ביצועים גבוהים כדי לעמוד בדרישות המחמירות של זמן האחזור של יומני הכתיבה מראש של שכבת הקונצנזוס.
שירותים ולוגיקה
- PostgreSQL 17: המנוע של מסד הנתונים הרלציוני שאחראי על שמירת הנתונים ועל הרצת השאילתות.
- Patroni: מנהל הזמינות הגבוהה שעוקב אחרי התהליך המקומי של PostgreSQL ומתאם את בחירת המנהיג באמצעות etcd.
- etcd: מאגר ההגדרות המבוזר שמספק את שכבת הקונצנזוס ומכיל את המצב המוסמך של האשכול.
- PgBouncer: מאגר חיבורים קל שיושב לפני PostgreSQL כדי לטפל ביעילות בחיבורים נכנסים של אפליקציות.
זרימת נתונים וממשקים
- PgBouncer (יציאה 6432): נקודת הכניסה הראשית לתנועה במסד הנתונים של האפליקציה.
- Patroni API (יציאה 8008): ממשק HTTPS REST שמשמש את מאזן העומסים כדי לבצע בדיקות תקינות ולזהות את ה-leader הנוכחי באמצעות נקודת הקצה
/primary. - etcd (יציאה 2379): ערוץ התקשורת של אשכול הקונצנזוס לשמירה על המצב ולביצוע בחירות.
לתשומת ליבכם
- מדרגיות וביצועים:
- צריך לקבוע את הגודל של צומתי מסד הנתונים בהתאם לעומס העבודה, עם מינימום של 2 מעבדי vCPU ו-8GiB RAM. עומסי עבודה בסביבת ייצור מתחילים בדרך כלל ב-8 מעבדי vCPU ו-32GiB.
- הביצועים תלויים באחסון עם זמן אחזור קצר. נדרשים כונני SSD כדי להבטיח ש-etcd יוכל לעבד סנכרוני נתונים תוך פחות מ-10 אלפיות השנייה.
- רפליקציה סינכרונית: התקורה של רפליקציה סינכרונית תלויה ישירות בזמן האחזור ברשת בין אזורים. כדי להבטיח ביצועים אופטימליים להגדרות אישיות ללא אובדן נתונים, נדרש זמן אחזור נמוך בין האזורים.
- ניהול משאבים ורישוי:
- הפתרון הזה מסתמך על רכיבי מסד נתונים חינמיים בקוד פתוח.
- Autobase משמש ככלי האוטומציה לדוגמה כדי לייעל את ההתקנה וההגדרה של מחסנית ה-HA. עם זאת, הארכיטקטורה לא קשורה באופן בלעדי ל-Autobase, ואפשר לנהל את רכיבי הקוד הפתוח הבסיסיים באמצעות צינורות עיבוד נתונים בהתאמה אישית.
- אם הארגון שלכם צריך תמיכה רשמית בחבילת האוטומציה, אתם יכולים לקבל תמיכה בתשלום מצד שלישי.
- איגוד חיבורים באמצעות PgBouncer חיוני כדי למנוע ניצול יתר של המעבד (CPU) והזיכרון, שנגרם בגלל מספר גבוה של חיבורי משתמשים.
- זמינות ואמינות:
- זמינות גבוהה מושגת באמצעות קוורום של 3 צמתים. כשל בצומת או באזור מסוים לא קוטע את השירות.
- יציבות האשכול: כדי לשמור על קוורום מהימן, צריך זמן אחזור קצר ברשת בין הצמתים. כדי למנוע זמן קצוב לתפוגה של בחירות וחוסר יציבות באשכול, זמן הלוך ושוב (RTT) הממוצע צריך להיות פחות מ-10 אלפיות השנייה.
- ניהול תפעולי:
- משימות שגרתיות כמו תיקון גרסאות משניות ושדרוגים משמעותיים נשארות באחריות צוות התפעול של הלקוח.
- הפלטים מ-
stdoutשל המכונות הווירטואליות נקלטים באופן אוטומטי בפלטפורמת המעקב של GDC עם air gap. בעתיד נפרסם מדריך שיסביר איך לשלב מעקב מפורט יותר אחרי הרכיבים הבודדים. - כדאי להטמיע אסטרטגיית גיבוי חזקה באמצעות כלים מקוריים של מסד הנתונים ותמונות מצב של הפלטפורמה. מדריכים מפורטים לגבי ההליכים האלה יפורסמו בנפרד.
החלטה לגבי העיצוב
הבחירות האדריכליות של הפתרון הזה מספקות נתיב גמיש לפריסות בכמה אזורים.
מכונות וירטואליות ב-Kubernetes
נבחרה גישה שמבוססת על מכונות וירטואליות כדי לספק זמינות גבוהה בכמה אזורים. ב-GDC אין תמיכה באשכולות Kubernetes שמתפרסים על פני כמה אזורים פיזיים. לכן, כדי ליצור ארכיטקטורה חזקה בין אזורים, צריך לפרוס מכונות וירטואליות ייעודיות באזורים נפרדים. ההגדרה הזו יכולה לשרוד כשל מוחלט של אזור תשתית אחד.
איזון עומסים גלובלי שמותאם לפלטפורמה
הארכיטקטורה משתמשת במאזן העומסים הגלובלי של GDC בשכבה 4, במקום בשרתי proxy מבוססי-תוכנה במכונות הווירטואליות. לגישה הזו יש כמה יתרונות:
- גישה גלובלית: כתובת IP וירטואלית יציבה שאפשר לגשת אליה מכל האזורים.
- בניהול של הפלטפורמה: ה-VIP מנוהל באופן עצמאי על ידי מישור הבקרה של הפלטפורמה.
- מעבר פשוט במקרה של כשל: המעבר במקרה של כשל מנוהל באמצעות בדיקות תקינות סטנדרטיות, ולא באמצעות הגדרות תוכנה מקומיות מורכבות.
- זמינות גבוהה: הסרת ההסתמכות על שרתי proxy מקומיים מבטיחה שנקודת הכניסה לתעבורת הנתונים של מסד הנתונים תישאר עמידה.
הנחות ומגבלות
הנחות
- בסביבה יש רישום מקומי או מנגנון לייבוא של יחסי תלות וקבצים בינאריים של מערכת ההפעלה.
- גישת SSH מבוססת-מפתח זמינה לכל המכונות הווירטואליות המיועדות לאוטומציה מבוססת-Ansible.
- בפרויקט יש מכסה מספיקה להקצאת מכונות וירטואליות ומאזני עומסים בכמה אזורים.
מגבלות
- תחזוקה ידנית: תיקון מערכת ההפעלה ושדרוג הגרסה של PostgreSQL הן משימות ידניות שלא מתבצעות באופן אוטומטי על ידי הפתרון.
- רגישות האחסון: שכבת הקונצנזוס (etcd) רגישה מאוד לזמן האחזור של הדיסק. תחרות גבוהה ומתמשכת על האחסון יכולה להשפיע על היציבות של שכבת הקונצנזוס.
- יציבות הרשת: מנהל הזמינות הגבוהה מסתמך על קישוריות רשת עקבית עם זמן אחזור קצר בין אזורים. עיכובים או תנודות ברשת יכולים להשפיע על התזמון של תיאום האשכולות ועל מעברי התפקידים.
חומרים נוספים
- מאגר המקורות של הקוד לאוטומציה של קובצי עזר: קוד המקור של Autobase ב-GitHub
- הטמעת קובץ עזר של מסד נתונים ב-PostgreSQL