שיטות מומלצות לתכנון פריסות של מסדי נתונים ב-GKE

בדף הזה מוסברות שיטות מומלצות להפעלת מסדי נתונים במאגרי תמונות (containers) ב-GKE. אתם יכולים להשתמש בפריסה כדי ליצור קבוצה של מופעי מסד נתונים בקונטיינרים שמנוהלים על ידי Kubernetes. לאחר מכן יוצרים שירות כדי לספק גישה למסד הנתונים באופן עצמאי מכל Pod מסוים. השירות לא משתנה גם אם ה-Pod מועבר לצומת אחר.

כדי לגשת לנתונים במופע של מסד הנתונים, יוצרים משאב PersistentVolumeClaim (PVC) ומקצים אותו לעומס העבודה.

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

אם אתם בונים או פורסים אפליקציה עם מצב שפועלת ב-GKE, כדאי להשתמש באחת מאפשרויות הפריסה הבאות עבור מופעי מסד נתונים:

  • מסדי נתונים מנוהלים: מסד נתונים מנוהל, כמו Cloud SQL או Spanner, מספק הפחתה בתקורה התפעולית ומותאם לתשתית Cloud de Confiance by S3NS . מסדי נתונים מנוהלים דורשים פחות מאמץ לתחזוקה ולהפעלה מאשר מסד נתונים שאתם פורסים ישירות ב-Kubernetes.
  • אפליקציית Kubernetes: אתם יכולים לפרוס ולהריץ מופע של מסד נתונים (כמו MySQL או PostgreSQL) באשכול GKE.
לסקירה מרוכזת של כל השיטות המומלצות ל-GKE, אפשר לעיין במאמר שיטות מומלצות ל-GKE.

שיקולים לגבי פריסות של מסדי נתונים ב-GKE

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

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

שינוי גודל אנכי: אתם יכולים להגדיר את בקשות ה-Pods שלכם כך שיתבצע שינוי גודל אוטומטי. עם זאת, אתם צריכים לוודא שאפליקציית מסד הנתונים שלכם יכולה לעמוד בשיבושים כשמתבצעת הגדלה של ה-Pods באמצעות התאמה אנכית של קבוצות Pod לעומס.

הרחבה אופקית: יכול להיות שתוכלו להרחיב את מסד הנתונים שלכם אופקית כדי להוסיף רפליקות לקריאה או לכתיבה. התמיכה בהרחבה אופקית במסד הנתונים תלויה בארכיטקטורה שלו – אם יש לו כותב יחיד או כמה כותבים. כדי להשתמש בהרחבה אופקית, יכול להיות שתצטרכו לעדכן את הגדרות מסד הנתונים, בנוסף להגדלת מספר העותקים.
תקורה ב-GKE

ב-Autopilot clusters, אתם לא מחויבים על הזמנות של משאבים, אלא רק על בקשות למשאבים.

באשכולות Standard, ‏ GKE שומר משאבים לפעולות שלו. מסדי נתונים באשכולות Standard לא עוברים התאמה אוטומטית של העומס, ולכן יכול להיות שהתקורה תהיה גבוהה עבור יחידות Pod קטנות.
מספר המופעים של מסד הנתונים בהקשר של Kubernetes, כל מופע של מסד נתונים פועל ב-Pod משלו ויש לו PersistentVolumeClaim משלו. אם יש לכם מספר גדול של מקרים, אתם צריכים להפעיל ולנהל קבוצה גדולה של Pod, צמתים ו-volume claims. אולי כדאי להשתמש במסד נתונים מנוהל במקום זאת.
גיבוי מסד נתונים ב-GKE

היקף ההרשאה של PersistentVolumeClaim הוא אשכול GKE. ההיקף הזה אומר שכשאשכול GKE נמחק, התביעה על נפח האחסון נמחקת. גם קבצים של מסדי נתונים באשכול נמחקים. כדי למנוע אובדן מקרי של קובצי מסד הנתונים, מומלץ לבצע שכפול או גיבוי תכוף.

אתם יכולים להשתמש ב- Backup for GKE כדי ליצור תמונות מצב של נתוני ההגדרות והנפח של האפליקציה במרווחי זמן קבועים. הגיבוי ל-GKE מטפל בתזמון של גיבויים של נפחים, בניהול מחזור החיים של הגיבויים ובשחזור של גיבויים לאשכול.

אופן השחזור הספציפי ל-Kubernetes כש-Pod נכשל ב-Kubernetes, הוא נוצר מחדש. מנקודת המבט של מופע מסד נתונים, המשמעות היא שכאשר יוצרים מחדש Pod, כל הגדרה שלא נשמרת במסד נתונים או באחסון יציב מחוץ ל-Pods, נוצרת מחדש גם כן.
ארכיטקטורת מסד נתונים אם מסד הנתונים שלכם מוגדר לשימוש בארכיטקטורה פעילה-סבילה, אתם צריכים לוודא שרק עותק אחד מוגדר כעותק ראשי. במקרים רבים במסדי נתונים רלציוניים יש אפשרות ליתירות כשל פעיל-סביל, שבה ניתן להעלות משני לראשי במקרה של כשל ראשי.
העברה של מסדי נתונים אם אתם מתכננים להעביר את מערכת מסד הנתונים הקיימת שלכם ל-GKE, מומלץ לעיין במאמרים העברת מסד נתונים: מושגים ועקרונות (חלק 1) ו העברת מסד נתונים: מושגים ועקרונות (חלק 2).
הדרכה מחדש של משתמשים אם עוברים מפריסה בניהול עצמי או בניהול ספק לפריסת מסד נתונים של Kubernetes, צריך להכשיר מחדש את האדמינים של מסד הנתונים כדי שיוכלו לפעול בסביבה החדשה באותה רמת מהימנות שבה הם פועלים בסביבה הנוכחית. מפתחי אפליקציות צריכים גם ללמוד על ההבדלים, אבל במידה פחותה.

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

המאמרים הבאים