האצת ביצועי הקריאה של עומסי עבודה עם שמירת מצב באמצעות GKE Data Cache

במדריך הזה נסביר איך לשפר את הביצועים של אפליקציות עם מצב (stateful) שמתבססות על קריאה, באמצעות GKE Data Cache באשכולות Google Kubernetes Engine ‏(GKE). GKE Data Cache הוא פתרון מנוהל לאחסון בלוקים שמאיץ את פעולות הקריאה של אפליקציות עם שמירת מצב, כמו מסדי נתונים, שפועלות ב-GKE.

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

מידע על GKE Data Cache

באמצעות GKE Data Cache, אתם יכולים להשתמש בכונני SSD מקומיים בצמתי GKE כשכבת מטמון לאחסון מתמיד, כמו Persistent Disks או Hyperdisks. השימוש בכונני SSD מקומיים מפחית את זמן האחזור של קריאת הדיסק ומגדיל את מספר השאילתות לשנייה (QPS) עבור עומסי העבודה עם שמירת מצב, תוך מזעור דרישות הזיכרון. ‫GKE Data Cache תומך בכל הסוגים של Persistent Disk או Hyperdisk כדיסקים לגיבוי.

כדי להשתמש ב-GKE Data Cache באפליקציה, צריך להגדיר את מאגר הצמתים ב-GKE עם כונני SSD מקומיים מצורפים. אתם יכולים להגדיר את GKE Data Cache כך שישתמש בכל או בחלק מה-SSD המקומי המצורף. כונני SSD מקומיים שמשמשים את פתרון GKE Data Cache מוצפנים במצב מנוחה באמצעות הצפנה Google Cloud סטנדרטית.

יתרונות

היתרונות של GKE Data Cache:

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

ארכיטקטורת פריסה

בתרשים הבא מוצגת דוגמה להגדרה של GKE Data Cache עם שני פודים, שכל אחד מהם מריץ אפליקציה. הפודים רצים באותו צומת GKE. כל Pod משתמש ב-SSD מקומי נפרד ובדיסק קבוע שמשמש כגיבוי.

ארכיטקטורת פריסה של GKE Data Cache
איור 1. ארכיטקטורת פריסה של GKE Data Cache.

מצבי פריסה

אפשר להגדיר את GKE Data Cache באחד משני מצבים:

  • Writethrough (מומלץ): כשהאפליקציה כותבת נתונים, הנתונים נכתבים באופן סינכרוני גם למטמון וגם לדיסק הבסיסי הקבוע. המצב writethrough מונע אובדן נתונים ומתאים לרוב עומסי העבודה של הייצור.
  • כתיבה חוזרת: כשהאפליקציה כותבת נתונים, הנתונים נכתבים רק במטמון. לאחר מכן, הנתונים נכתבים בדיסק המתמיד באופן אסינכרוני (ברקע). מצב writeback משפר את ביצועי הכתיבה ומתאים לעומסי עבודה שמסתמכים על מהירות. עם זאת, המצב הזה משפיע על האמינות. אם הצומת נסגר באופן לא צפוי, נתוני מטמון שלא נמחקו יאבדו.

מטרות

במדריך הזה תלמדו איך:

דרישות ותכנון

כדי להשתמש ב-GKE Data Cache, צריך לוודא שאתם עומדים בדרישות הבאות:

  • באשכול GKE צריכה לפעול גרסה 1.32.3-gke.1440000 ומעלה.
  • מאגרי הצמתים צריכים להשתמש בסוגי מכונות שתומכים ב-SSD מקומי. מידע נוסף זמין במאמר בנושא תמיכה בסדרת מכונות.

תכנון

כשמתכננים את קיבולת האחסון של GKE Data Cache, כדאי לקחת בחשבון את ההיבטים הבאים:

  • מספר ה-Pods המקסימלי לכל צומת שישתמש במטמון הנתונים של GKE בו-זמנית.
  • דרישות הגודל הצפויות של המטמון של ה-Pods שישתמשו ב-GKE Data Cache.
  • הקיבולת הכוללת של כונני SSD מקומיים שזמינים בצמתי GKE. למידע על סוגי המכונות שמצורפים אליהם כברירת מחדל התקני SSD מקומיים, ועל סוגי המכונות שבהם צריך לצרף התקני SSD מקומיים, אפשר לקרוא את המאמר בחירת מספר תקין של דיסקים מסוג SSD מקומי.
  • בסוגי מכונות מהדור השלישי ואילך (שמצורף אליהם מספר ברירת מחדל של כונני SSD מקומיים), כדאי לשים לב שכונני ה-SSD המקומיים של מטמון הנתונים שמורים מתוך המספר הכולל של כונני ה-SSD המקומיים שזמינים במכונה.
  • התקורה של מערכת הקבצים, שיכולה להקטין את השטח שניתן לשימוש בכונני SSD מקומיים. לדוגמה, גם אם יש לכם צומת עם שני כונני SSD מקומיים עם קיבולת כוללת של 750 GiB, יכול להיות שהשטח הפנוי לכל נפחי מטמון הנתונים יהיה קטן יותר בגלל תקורה של מערכת הקבצים. חלק מהקיבולת של ה-SSD המקומי שמור לשימוש המערכת.

מגבלות

אי-תאימות לגיבוי ל-GKE

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

תמחור

אתם מחויבים על סך הקיבולת שהוקצתה לדיסקים מסוג Local SSD ולדיסקים הקשיחים המצורפים. החיוב הוא לפי GiB לחודש.

מידע נוסף מופיע במאמר בנושא תמחור של דיסקים במסמכי התיעוד של Compute Engine.

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

  • מפעילים את ממשק Google Kubernetes Engine API.
    • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

הגדרת צמתים של GKE לשימוש במטמון נתונים

כדי להתחיל להשתמש ב-GKE Data Cache לאחסון מהיר יותר, בצמתים שלכם צריכים להיות משאבי Local SSD נדרשים. בקטע הזה מוצגות פקודות להקצאת SSD מקומי ולהפעלת GKE Data Cache כשיוצרים אשכול GKE חדש או כשמוסיפים מאגר צמתים חדש לאשכול קיים. אי אפשר לעדכן מאגר צמתים קיים כדי להשתמש במטמון נתונים. אם רוצים להשתמש במטמון נתונים באשכול קיים, צריך להוסיף מאגר צמתים חדש לאשכול.

באשכול חדש

כדי ליצור אשכול GKE עם הגדרות של Data Cache, משתמשים בפקודה הבאה:

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --machine-type=MACHINE_TYPE \
    --data-cache-count=DATA_CACHE_COUNT \
    # Optionally specify additional Local SSDs, or skip this flag
    --ephemeral-storage-local-ssd count=LOCAL_SSD_COUNT

מחליפים את מה שכתוב בשדות הבאים:

  • ‫CLUSTER_NAME: שם האשכול. מזינים שם ייחודי לאשכול GKE שיוצרים.
  • ‫LOCATION: Google Cloud האזור או התחום של האשכול החדש.
  • ‫MACHINE_TYPE: סוג המכונה לשימוש מסדרת מכונות מהדור השני, השלישי או דורות מאוחרים יותר עבור האשכול, כמו n2-standard-2 או c3-standard-4-lssd. זהו שדה חובה כי אי אפשר להשתמש ב-SSD מקומי עם סוג ברירת המחדל e2-medium. מידע נוסף מופיע במאמר בנושא סדרות מכונות.
  • ‫DATA_CACHE_COUNT: מספר הכרכים של SSD מקומי שיוקדשו באופן בלעדי למטמון נתונים בכל צומת במאגר הצמתים שמוגדר כברירת מחדל. לכל אחד מה-SSD המקומיים האלה יש קיבולת של 375 GiB. המספר המקסימלי של אמצעי אחסון משתנה בהתאם לסוג המכונה ולאזור. שימו לב שחלק מהקיבולת של ה-SSD המקומי שמור לשימוש המערכת.

  • ‫(Optional) LOCAL_SSD_COUNT: מספר נפחי ה-Local SSD שצריך להקצות לצרכים אחרים של אחסון זמני. משתמשים בדגל --ephemeral-storage-local-ssd count אם רוצים להקצות עוד כונני SSD מקומיים שלא משמשים למטמון נתונים.

    הערות לגבי סוגי מכונות מהדור השלישי ואילך:

    • לסוגי מכונות מהדור השלישי ואילך יש מספר מסוים של כונני SSD מקומיים שמצורפים כברירת מחדל. מספר כונני ה-SSD המקומיים שמצורפים לכל צומת תלוי בסוג המכונה שאתם מציינים.
    • אם אתם מתכננים להשתמש בדגל --ephemeral-storage-local-ssd count לאחסון זמני נוסף, הקפידו להגדיר את הערך של DATA_CACHE_COUNT למספר שהוא קטן ממספר דיסקי ה-SSD המקומיים הזמינים הכוללים במכונה. המספר הכולל של כונני SSD מקומיים שזמינים כולל את הדיסקים המצורפים כברירת מחדל ואת כל הדיסקים החדשים שמוסיפים באמצעות הדגל --ephemeral-storage-local-ssd count.

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

ההגדרות האלה חלות רק על מאגר הצמתים שמוגדר כברירת מחדל.

באשכול קיים

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

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

gcloud container node-pool create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --machine-type=MACHINE_TYPE \
    --data-cache-count=DATA_CACHE_COUNT \
    # Optionally specify additional Local SSDs, or skip this flag
    --ephemeral-storage-local-ssd count=LOCAL_SSD_COUNT

מחליפים את מה שכתוב בשדות הבאים:

  • ‫NODE_POOL_NAME: השם של מאגר הצמתים. צריך לציין שם ייחודי למאגר הצמתים שיוצרים.
  • ‫CLUSTER_NAME: השם של אשכול GKE קיים שבו רוצים ליצור את מאגר הצמתים.
  • ‫LOCATION: אותו Google Cloud אזור או תחום כמו האשכול.
  • ‫MACHINE_TYPE: סוג המכונה לשימוש מסדרת מכונות מהדור השני, השלישי או דורות מאוחרים יותר עבור האשכול, כמו n2-standard-2 או c3-standard-4-lssd. השדה הזה הוא חובה, כי אי אפשר להשתמש ב-SSD מקומי עם סוג ברירת המחדל e2-medium. מידע נוסף מופיע במאמר בנושא סדרות מכונות.
  • ‫DATA_CACHE_COUNT: מספר נפחי ה-SSD המקומי שיוקדשו באופן בלעדי למטמון נתונים בכל צומת במאגר הצמתים. לכל אחד מה-SSD המקומיים האלה יש קיבולת של 375 GiB. המספר המקסימלי של אמצעי אחסון משתנה בהתאם לסוג המכונה ולאזור. שימו לב שחלק מהקיבולת של ה-SSD המקומי שמור לשימוש המערכת.

  • ‫(Optional) LOCAL_SSD_COUNT: מספר נפחי ה-Local SSD שצריך להקצות לצרכים אחרים של אחסון זמני. משתמשים בדגל --ephemeral-storage-local-ssd count אם רוצים להקצות עוד כונני SSD מקומיים שלא משמשים למטמון נתונים.

    הערות לגבי סוגי מכונות מהדור השלישי ואילך:

    • לסוגי מכונות מהדור השלישי ואילך יש מספר מסוים של כונני SSD מקומיים שמצורפים כברירת מחדל. מספר כונני ה-SSD המקומיים שמצורפים לכל צומת תלוי בסוג המכונה שאתם מציינים.
    • אם אתם מתכננים להשתמש בדגל --ephemeral-storage-local-ssd count לאחסון זמני נוסף, הקפידו להגדיר את DATA_CACHE_COUNT לערך נמוך מהערך הכולל הזמין של דיסקי ה-SSD המקומיים במכונה. המספר הכולל של כונני SSD מקומיים שזמינים כולל את הדיסקים המצורפים כברירת מחדל ואת כל הדיסקים החדשים שמוסיפים באמצעות הדגל --ephemeral-storage-local-ssd count.

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

הקצאת Data Cache לאחסון מתמיד ב-GKE

בקטע הזה מופיעה דוגמה להפעלה של היתרונות של GKE Data Cache בביצועים של אפליקציות עם שמירת מצב.

יצירת מאגר צמתים עם כונני SSD מקומיים למטמון נתונים

כדי להתחיל, יוצרים מאגר צמתים חדש עם כונני SSD מקומיים שמצורפים לאשכול GKE. ‫GKE Data Cache משתמש ב-SSD מקומי כדי לשפר את הביצועים של דיסקים מתמידים שמצורפים.

הפקודה הבאה יוצרת מאגר צמתים שמשתמש במכונה מהדור השני, n2-standard-2:

gcloud container node-pools create datacache-node-pool \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --num-nodes=2 \
    --data-cache-count=1 \
    --machine-type=n2-standard-2

מחליפים את מה שכתוב בשדות הבאים:

  • ‫CLUSTER_NAME: שם האשכול. מציינים את אשכול GKE שבו יוצרים את מאגר הצמתים החדש.
  • ‫LOCATION: אותו Google Cloud אזור או אזור משנה כמו האשכול שלכם.

הפקודה הזו יוצרת מאגר צמתים עם המפרט הבא:

  • ‫--num-nodes=2: מגדיר את המספר הראשוני של הצמתים במאגר הזה לשניים.
  • ‫--data-cache-count=1: מציין SSD מקומי אחד לכל צומת שמוקדש ל-GKE Data Cache.

המספר הכולל של כונני SSD מקומיים שהוקצו למאגר הצמתים הזה הוא שניים, כי לכל צומת הוקצה כונן SSD מקומי אחד.

יצירת Data Cache StorageClass

יוצרים StorageClass Kubernetes שמגדיר ל-GKE איך להקצות באופן דינמי נפח אחסון קבוע שמשתמש במטמון נתונים.

משתמשים במניפסט הבא כדי ליצור ולהחיל StorageClass בשם pd-balanced-data-cache-sc:

kubectl apply -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-balanced-data-cache-sc
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-balanced
  data-cache-mode: writethrough
  data-cache-size: "100Gi"
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
EOF

StorageClass הפרמטרים של מטמון הנתונים כוללים את הפרטים הבאים:

  • ‫type: מציין את סוג הדיסק הבסיסי של נפח האחסון המתמיד. אפשרויות נוספות זמינות במאמרים בנושא סוגי Persistent Disk נתמכים או סוגי Hyperdisk.
  • ‫data-cache-mode: משתמש במצב writethrough המומלץ. מידע נוסף זמין במאמר בנושא מצבי פריסה.
  • ‫data-cache-size: מגדיר את הקיבולת של ה-SSD המקומי ל-100 GiB, שמשמש כמטמון לקריאה לכל PVC.

בקשה לנפח אחסון באמצעות PersistentVolumeClaim ‏ (PVC)

יוצרים PVC שמפנה אל pd-balanced-data-cache-sc StorageClass שיצרתם. ה-PVC מבקש נפח אחסון מתמיד עם הפעלת Data Cache.

משתמשים במניפסט הבא כדי ליצור PVC בשם pvc-data-cache שמבקש נפח אחסון קבוע של לפחות 300 GiB עם גישת ReadWriteOnce.

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-data-cache
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 300Gi
  storageClassName: pd-balanced-data-cache-sc
EOF

יצירת פריסה שמשתמשת ב-PVC

יוצרים פריסה בשם postgres-data-cache שמפעילה Pod שמשתמש ב-PVC‏ pvc-data-cache שיצרתם קודם. הכלי cloud.google.com/gke-data-cache-countnode selector מוודא שה-Pod מתוזמן לצומת שיש בו את משאבי ה-SSD המקומי שנדרשים לשימוש ב-GKE Data Cache.

יוצרים את המניפסט הבא ומחילים אותו כדי להגדיר Pod שמבצע פריסה של שרת אינטרנט של Postgres באמצעות ה-PVC:

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
 name: postgres-data-cache
 labels:
   name: database
   app: data-cache
spec:
 replicas: 1
 selector:
   matchLabels:
     service: postgres
     app: data-cache
 template:
   metadata:
     labels:
       service: postgres
       app: data-cache
   spec:
     nodeSelector:
       cloud.google.com/gke-data-cache-disk: "1"
     containers:
     - name: postgres
       image: postgres:14-alpine
       volumeMounts:
       - name: pvc-data-cache-vol
         mountPath: /var/lib/postgresql/data2
         subPath: postgres
       env:
       - name: POSTGRES_USER
         value: admin
       - name: POSTGRES_PASSWORD
         value: password
     restartPolicy: Always
     volumes:
     - name: pvc-data-cache-vol
       persistentVolumeClaim:
         claimName: pvc-data-cache
EOF

מוודאים שהפריסה נוצרה בהצלחה:

kubectl get deployment

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

אימות הקצאת המקום במטמון הנתונים

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

  1. כדי לוודא ש-pvc-data-cache קשור בהצלחה לנפח אחסון מתמשך, מריצים את הפקודה הבאה:

    kubectl get pvc pvc-data-cache

    הפלט אמור להיראות כך:

    NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                VOLUMEATTRIBUTESCLASS   AGE
pvc-data-cache   Bound    pvc-e9238a16-437e-45d7-ad41-410c400ae018   300Gi      RWO            pd-balanced-data-cache-sc   <unset>                 10m

  2. כדי לוודא שקבוצת Logical Volume Manager ‏ (LVM) של מטמון הנתונים נוצרה בצומת, פועלים לפי השלבים הבאים:

    1. מאחזרים את שם ה-Pod של מנהל ההתקן PDCSI בצומת:

      NODE_NAME=$(kubectl get pod --output json |  jq '.items[0].spec.nodeName' | sed 's/\"//g')
kubectl get po -n kube-system -o wide | grep ^pdcsi-node | grep $NODE_NAME

      מעתיקים את השם של pdcsi-node Pod מהפלט.

    2. צפייה ביומני מנהלי התקנים של PDCSI ליצירת קבוצת LVM:

      PDCSI_POD_NAME="PDCSI-NODE_POD_NAME"
kubectl logs -n kube-system $PDCSI_POD_NAME gce-pd-driver | grep "Volume group creation"

      מחליפים את PDCSI-NODE_POD_NAME בשם ה-Pod בפועל שהעתקתם בשלב הקודם.

      הפלט אמור להיראות כך:

      Volume group creation succeeded for LVM_GROUP_NAME

ההודעה הזו מאשרת שהגדרת ה-LVM של מטמון הנתונים מוגדרת בצורה נכונה בצומת.

הסרת המשאבים

כדי להימנע מחיובים בחשבון Google Cloud , מוחקים את משאבי האחסון שיצרתם במדריך הזה.

  1. מוחקים את הפריסה.

    kubectl delete deployment postgres-data-cache

  2. מוחקים את PersistentVolumeClaim.

    kubectl delete pvc pvc-data-cache

  3. מוחקים את מאגר הצמתים.

    gcloud container node-pools delete datacache-node-pool \
    --cluster CLUSTER_NAME

    מחליפים את CLUSTER_NAME בשם האשכול שבו יצרתם את מאגר הצמתים שמשתמש במטמון נתונים.

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