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

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

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

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

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

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

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

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

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

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

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

באשכולות Autopilot, אתם לא מחויבים על שמירת מקום למשאבים, אלא רק על בקשות למשאבים.

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

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

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

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

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

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