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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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