אופטימיזציה ידנית של מנהל התקן ה-CSI של Cloud Storage FUSE לשיפור הביצועים

במדריך הזה נסביר איך לשפר את הביצועים של מנהל ההתקן ה-CSI של Cloud Storage FUSE ב-Google Kubernetes Engine ‏ (GKE). כדי לקבל מידע על דרך פשוטה ואוטומטית לאופטימיזציה של הביצועים של Cloud Storage FUSE לעומסי עבודה של AI/ML, ראו אופטימיזציה אוטומטית של הביצועים באמצעות פרופילים של Cloud Storage FUSE. השלבים הידניים במאמר הזה מיועדים למשתמשים מתקדמים, או כדי לתת מענה לצרכים מותאמים אישית שלא נכללים בפרופילים.

‫Cloud Storage FUSE מציע גמישות ומדרגיות, אבל כדי להשיג ביצועים אופטימליים חשוב לבצע הגדרה וכוונון מדויקים. הביצועים של Cloud Storage FUSE יכולים להיות שונים ממערכת קבצים של POSIX מבחינת זמן האחזור, התפוקה והעקביות. המטרה של כוונון היא לצמצם את התקורה של פעולות מטא-נתונים ולמקסם את היעילות של גישה לנתונים. אם אתם מריצים אפליקציות AI/ML שצורכות נתונים בקטגוריות של Cloud Storage, כוונון של מנהל ההתקן CSI יכול להוביל לזמני אימון והסקה מהירים יותר של אפליקציות ה-AI/ML.

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

לפני שקוראים את הדף הזה, חשוב לוודא שמכירים את העקרונות הבסיסיים של Cloud Storage,‏ Kubernetes ומנהל התקן ה-CSI של Cloud Storage FUSE. חשוב גם לבדוק את דרישות הגרסה של GKE לתכונות ספציפיות שרוצים להשתמש בהן.

הגדרת אפשרויות ההרכבה

מנהל התקן ה-CSI של Cloud Storage FUSE תומך באפשרויות טעינה כדי להגדיר איך קטגוריות של Cloud Storage נטענות במערכת הקבצים המקומית.

אפשר לציין אפשרויות הרכבה בדרכים הבאות, בהתאם לסוג הנפח שבו אתם משתמשים:

נפח אחסון זמני של CSI

אם אתם משתמשים בכרכים זמניים של CSI, אתם צריכים לציין את אפשרויות ההרכבה בשדה spec.volumes[n].csi.volumeAttributes.mountOptions של מניפסט ה-Pod.

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

  mountOptions: "implicit-dirs,file-cache:enable-parallel-downloads:true,file-cache:download-chunk-size-mb:3"

נפח אחסון מתמיד

אם אתם משתמשים בנפחי אחסון מתמידים, צריך לציין את אפשרויות ההרכבה בשדה spec.mountOptions במניפסט PersistentVolume.

צריך לציין את אפשרויות ההרכבה כרשימה. לדוגמה:

  mountOptions:
    - implicit-dirs
    - file-cache:enable-parallel-downloads:true
    - file-cache:download-chunk-size-mb:3

שיקולים לגבי טעינה

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

שיקולים כלליים

  • הדגלים הבאים אסורים: app-name,‏ temp-dir,‏ foreground,‏ log-file,‏ log-format,‏ key-file,‏ token-url ו-reuse-token-from-url.
  • כברירת מחדל, Cloud Storage FUSE לא מציג ספריות מרומזות.
  • אם רוצים לטעון רק ספרייה בקטגוריה ולא את כל הקטגוריה, צריך להעביר את הנתיב היחסי של הספרייה באמצעות הדגל only-dir=relative/path/to/the/bucket/root.

אבטחה והרשאות

  • אם אתם משתמשים בהקשר אבטחה עבור ה-Pod או הקונטיינר, או אם קובץ האימג' של הקונטיינר משתמש בקבוצה או במשתמש שאינם root, אתם צריכים להגדיר את דגלי הטעינה uid ו-gid. צריך גם להשתמש בדגלי הטעינה file-mode ו-dir-mode כדי להגדיר את ההרשאות של מערכת הקבצים. שימו לב שאי אפשר להריץ פקודות chmod, chown או chgrp במערכת קבצים של Cloud Storage FUSE, לכן צריך להשתמש בדגלי ההרכבה uid, gid, file-mode ו-dir-mode כדי לקבל גישה למשתמש או לקבוצה שהם לא משתמש או קבוצה עם הרשאות root.

אפשרויות טעינה של ליבת Linux

  • אם אתם צריכים להגדיר את אפשרויות הטעינה של ליבת Linux, אתם יכולים להעביר את האפשרויות באמצעות הדגל o. לדוגמה, אם אתם לא רוצים לאפשר הפעלה ישירה של קבצים בינאריים במערכת הקבצים המצורפת, צריך להגדיר את הדגל o=noexec. לכל אפשרות צריך להשתמש בדגל נפרד, לדוגמה, o=noexec,o=noatime. מותר להשתמש רק באפשרויות הבאות: exec,‏ noexec,‏ atime,‏ noatime,‏ sync,‏ async ו-dirsync.

הגדרת שמירה במטמון

בקטע הזה מוסבר על אפשרויות השמירה במטמון שזמינות עם מנהל ההתקן Cloud Storage FUSE CSI כדי לשפר את הביצועים.

שמירת קבצים במטמון

אפשר להשתמש במנהל התקן ה-CSI של Cloud Storage FUSE עם שמירת קבצים במטמון כדי לשפר את ביצועי הקריאה של אפליקציות שמטפלות בקבצים קטנים מקטגוריות של Cloud Storage. תכונת מטמון הקבצים של Cloud Storage FUSE היא מטמון קריאה מבוסס-לקוח, שמאפשר לשרת קריאות חוזרות של קבצים מהר יותר מאחסון המטמון שתבחרו.

אתם יכולים לבחור מתוך מגוון אפשרויות אחסון למטמון הקריאה, כולל Local SSD, אחסון בלוקים עמיד כמו Google Cloud Hyperdisk או Persistent Disk, ודיסק RAM (זיכרון), בהתאם לצרכים שלכם מבחינת מחיר וביצועים.

הפעלה של שמירת קבצים במטמון ושימוש בה

כברירת מחדל, תכונת שמירת הקבצים במטמון מושבתת ב-GKE. כדי להפעיל שמירה במטמון של קבצים באמצעות מנהל התקן ה-CSI של Cloud Storage FUSE, צריך להביע הסכמה.

כדי להפעיל את שמירת הקבצים במטמון ולשלוט בה, מגדירים את מאפיין עוצמת הקול fileCacheCapacity או משתמשים באפשרות ההרכבה file-cache:max-size-mb.

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

אתם יכולים להגדיר נפח מטמון קריאה מותאם אישית עבור קונטיינר ה-sidecar כדי להחליף את נפח ברירת המחדל emptyDir של מטמון הקבצים בפעולות קריאה.

מידע נוסף על שיטות מומלצות לשמירת קבצים במטמון זמין במאמר בנושא הביצועים של Cloud Storage FUSE.

בחירת האחסון לגיבוי של מטמון הקבצים

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

  • למשפחות של מכונות וירטואליות עם GPU ומעבד שתומכות ב-Local SSD (לדוגמה, מכונות וירטואליות מסוג A3), מומלץ להשתמש ב-Local SSD.

    • במכונות וירטואליות מסוג A3+, ‏ GKE מגדיר באופן אוטומטי SSD מקומי לשימוש ב-Pods.
    • אם משפחת המכונות הווירטואליות לא תומכת ב-SSD מקומי, ‏ GKE משתמש בדיסק האתחול לצורך שמירת נתונים במטמון. סוג הכונן שמוגדר כברירת מחדל לכונן האתחול ב-GKE הוא pd-balanced.

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

      כדי לבדוק אם ב-Local SSD מופעל אחסון זמני בצומת, מריצים את הפקודה הבאה:

      kubectl describe node <code><var>NODE_NAME</var></code> | grep "cloud.google.com/gke-ephemeral-storage-local-ssd"

  • במשפחות של מכונות וירטואליות של TPU, במיוחד v6 ומעלה, מומלץ להשתמש ב-RAM כמטמון קבצים כדי להשיג את הביצועים הטובים ביותר, כי למופעים של המכונות הווירטואליות האלה יש RAM גדול יותר.

    • כשמשתמשים ב-RAM, חשוב לשים לב לשגיאות של חוסר זיכרון (OOM), כי הן גורמות לשיבושים ב-Pod. ‫Cloud Storage FUSE צורך זיכרון, ולכן הגדרת מטמון קבצים לצריכת קונטיינר ה-sidecar עלולה לגרום לשגיאות OOM. כדי למנוע תרחישים כאלה, צריך לשנות את הערך בשדה file-cache:max-size-mb של הגדרת מטמון הקבצים לערך קטן יותר.
    • למשפחות אחרות של TPU, מומלץ להשתמש ב-pd-balanced או ב-pd-ssd. סוג הדיסק שמוגדר כברירת מחדל לדיסק האתחול ב-GKE הוא pd-balanced.

  • לא מומלץ להשתמש בדיסק האתחול לאחסון במטמון, כי זה עלול להוביל לירידה בביצועים ולסיום לא צפוי של הפעולה. במקום זאת, כדאי להשתמש ב-PersistentVolume שמגובה על ידי אחסון בלוקים עמיד.

שימוש במטמון קבצים שמבוסס על דיסק RAM

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

כדי להשתמש בדיסק RAM עם מנהל התקן ה-CSI של Cloud Storage FUSE, מוסיפים את הקוד הבא למניפסט:

volumes:
  - name: gke-gcsfuse-cache
    emptyDir:
      medium: Memory

מטמון נתונים סטטיסטיים

מנהל התקן ה-CSI של Cloud Storage FUSE משפר את הביצועים באמצעות שמירת מטא-נתונים של קבצים במטמון, כמו גודל ושעת שינוי. דרייבר ה-CSI מפעיל את מטמון הסטטוס הזה כברירת מחדל, ומקטין את זמן האחזור על ידי אחסון מידע באופן מקומי במקום לבקש אותו שוב ושוב מ-Cloud Storage. אתם יכולים להגדיר את הגודל המקסימלי שלו (ברירת המחדל היא 32 MB) ואת משך הזמן שהנתונים יישארו במטמון (ברירת המחדל היא 60 שניות). אפשר לצמצם את מספר הקריאות ל-API של Cloud Storage באמצעות כוונון עדין של מטמון המטא-נתונים, וכך לשפר את הביצועים והיעילות של האפליקציה על ידי צמצום תעבורת הרשת והחביון.

מידע נוסף על שיטות מומלצות לשמירה במטמון של נתוני stat זמין במאמר סקירה כללית על שמירה במטמון ב-Cloud Storage FUSE.

שימוש באחזור מראש של מטא-נתונים כדי לאכלס מראש את מטמון המטא-נתונים

התכונה 'טעינה מראש של מטא-נתונים' מאפשרת ל-Cloud Storage FUSE CSI driver לטעון באופן יזום מטא-נתונים רלוונטיים לגבי האובייקטים בקטגוריה של Cloud Storage במטמון של Cloud Storage FUSE. הגישה הזו מצמצמת את הקריאות ל-Cloud Storage, והיא מועילה במיוחד לאפליקציות שמשתמשות במערכי נתונים גדולים עם הרבה קבצים, כמו עומסי עבודה (workloads) של אימון AI/ML.

כדי להשתמש בתכונה הזו, צריך GKE מגרסה 1.32.1-gke.1357001 ואילך. התכונה הזו לא נתמכת בחיבור דינמי, שבו מציינים קו תחתון (‎_) כדי לחבר את כל הקטגוריות שלחשבון שירות Kubernetes יש גישה אליהן. אם משתמשים בהרכבה דינמית, לא מתבצעת אחזור מראש של מטא נתונים.

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

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

  • מגדירים את מאפיין עוצמת הקול gcsfuseMetadataPrefetchOnMount: true.
  • מעדכנים את אפשרויות ההרכבה הבאות:
  • כדי למנוע שיבושים בעומס העבודה, מומלץ להגדיל את מגבלת הזיכרון של gke-gcsfuse-metadata-prefetch sidecar.
    • כדי להגדיל את המגבלות, צריך להגדיר את הערך של הערת ה-Pod‏ gke-gcsfuse/metadata-prefetch-memory-limit ל-"512Mi" או לערך גבוה יותר. מידע נוסף זמין במאמר הגדרת משאבים של קונטיינר sidecar.
    • אפשרות אחרת היא לבטל את הגדרת מגבלת הזיכרון על ידי הגדרת הערת ה-Pod‏ gke-gcsfuse/metadata-prefetch-memory-limit ל-"0" (האפשרות הזו נתמכת רק באשכולות רגילים).

לדוגמה, אפשר לעיין בדוגמת הקוד במאמר שיפור הביצועים של קריאת קבצים גדולים באמצעות הורדה מקבילה.

מטמון רשימות

כדי לזרז את הרישום של אפליקציות בספרייה, אפשר להפעיל שמירת רשימות במטמון. התכונה הזו מאחסנת את רשימות הספרייה בזיכרון, כדי שאפשר יהיה לטפל בבקשות חוזרות מהר יותר. מטמון הרשימה מושבת כברירת מחדל. כדי להפעיל אותו, צריך להגדיר את הפרמטר kernel-list-cache-ttl-secs באפשרויות ההרכבה. ההגדרה הזו קובעת את משך הזמן שבו כרטיסי המוצר נשמרים במטמון.

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

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

לפני שמפעילים קריאות עם מאגר זמני, כדאי לשים לב לנקודות הבאות:

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

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

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

מומלץ להשתמש באפשרויות ההרכבה: read-global-max-blocks כדי לציין את המספר המקסימלי של בלוקים שזמינים לקריאות עם מאגר זמני בכל ידיות הקבצים.

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

אתם יכולים להשתמש בהורדה מקבילה של Cloud Storage FUSE כדי להאיץ את הקריאה של קבצים גדולים מ-Cloud Storage להורדות מרובות-שרשורים. הורדה מקבילה של Cloud Storage FUSE יכולה להיות שימושית במיוחד בתרחישים של מודלים שמשרתים בקשות עם קריאות בגודל של יותר מ-1GB.

כדי להשתמש בהורדות מקבילות, צריך להפעיל את מטמון הקבצים. החל מגרסה GKE 1.32.0-gke.1795000, ‏ Cloud Storage FUSE אוכף את הדרישה הזו באופן מחמיר ומציג את השגיאה הבאה אם מנסים להשתמש בהורדות מקבילות ללא מטמון הקבצים, מה שמונע את הפעלת ה-Pod: MountVolume.SetUp failed for volume "gcs-fuse-csi-pv" : rpc error: code = Internal desc = gcsfuse failed with error: Error: error while parsing config: error parsing parallel download config: file cache should be enabled for parallel download support.

דוגמאות נפוצות:

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

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

כדי להשתמש בהורדה מקבילה עם מנהל התקן ה-CSI של Cloud Storage FUSE, פועלים לפי השלבים הבאים:

  1. יוצרים אשכול עם הפעלת שמירת קבצים במטמון, כמו שמתואר במאמר הפעלה של שמירת קבצים במטמון ושימוש בה.

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

    1. מגדירים את file-cache:enable-parallel-downloads:true.
    2. משנים את file-cache:parallel-downloads-per-file,‏ file-cache:parallel-downloads-per-file,‏ file-cache:max-parallel-downloads ו-file-cache:download-chunk-size-mb לפי הצורך.

  3. (אופציונלי) אם צריך, אפשר לשנות את מאפייני עוצמת הקול הבאים:

צמצום צריכת המכסה מבדיקות בקרת גישה

כברירת מחדל, מנהל ההתקן של CSI מבצע בדיקות של בקרת גישה כדי לוודא שלחשבון השירות של ה-Pod יש גישה לקטגוריות של Cloud Storage. התוצאה היא תקורה נוספת בצורה של קריאות ל-Kubernetes Service API, ל-Security Token Service ול-IAM. החל מגרסה GKE 1.29.9-gke.1251000, אפשר להשתמש במאפיין volume skipCSIBucketAccessCheck כדי לדלג על בדיקות מיותרות כאלה ולצמצם את ניצול המכסה.

דוגמה להצגת מסקנות

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

  1. יוצרים מניפסט של PersistentVolume ו-PersistentVolumeClaim עם המפרט הבא:

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: serving-bucket-pv
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 64Gi
  persistentVolumeReclaimPolicy: Retain
  storageClassName: example-storage-class
  claimRef:
    namespace: NAMESPACE
    name: serving-bucket-pvc
  mountOptions:
    - implicit-dirs #avoid if list cache enabled and doing metadata prefetch
    - metadata-cache:ttl-secs:-1
    - metadata-cache:stat-cache-max-size-mb:-1
    - metadata-cache:type-cache-max-size-mb:-1
    - file-cache:max-size-mb:-1
    - file-cache:cache-file-for-range-read:true
    - file-system:kernel-list-cache-ttl-secs:-1
    - file-cache:enable-parallel-downloads:true
    - read_ahead_kb=1024
  csi:
    driver: gcsfuse.csi.storage.gke.io
    volumeHandle: BUCKET_NAME
    volumeAttributes:
      skipCSIBucketAccessCheck: "true"
      gcsfuseMetadataPrefetchOnMount: "true"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: serving-bucket-pvc
  namespace: NAMESPACE
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 64Gi
  volumeName: serving-bucket-pv
  storageClassName: example-storage-class

    מחליפים את הערכים הבאים:

    • ‫NAMESPACE: מרחב השמות של Kubernetes שבו רוצים לפרוס את ה-Pod.
    • ‫BUCKET_NAME: שם הקטגוריה ב-Cloud Storage שציינתם כשקבעתם את הגישה לקטגוריות ב-Cloud Storage. אפשר לציין קו תחתון (_) כדי לטעון את כל הקטגוריות שחשבון השירות של Kubernetes יכול לגשת אליהן. מידע נוסף זמין במאמר Dynamic mounting במאמרי העזרה של Cloud Storage FUSE.

  2. מחילים את המניפסט על האשכול:

    kubectl apply -f PV_FILE_PATH

    מחליפים את PV_FILE_PATH בנתיב לקובץ ה-YAML.

  3. יוצרים מניפסט של Pod עם המפרט הבא כדי להשתמש ב-PersistentVolumeClaim, בהתאם לסוג מטמון הקבצים שבו אתם משתמשים: מטמון קבצים שמגובה על ידי SSD מקומי או מטמון קבצים שמגובה על ידי דיסק RAM:

    אחסון SSD מקומי

    apiVersion: v1
kind: Pod
metadata:
  name: gcs-fuse-csi-example-pod
  namespace: NAMESPACE
  annotations:
    gke-gcsfuse/volumes: "true"
    gke-gcsfuse/cpu-limit: "0"
    gke-gcsfuse/memory-limit: "0"
    gke-gcsfuse/ephemeral-storage-limit: "0"
spec:
  containers:
    # Your workload container spec
    ...
    volumeMounts:
    - name: serving-bucket-vol
      mountPath: /serving-data
      readOnly: true
  serviceAccountName: KSA_NAME
  volumes:
  - name: serving-bucket-vol
    persistentVolumeClaim:
      claimName: serving-bucket-pvc

    דיסק RAM

    apiVersion: v1
kind: Pod
metadata:
  name: gcs-fuse-csi-example-pod
  namespace: NAMESPACE
  annotations:
    gke-gcsfuse/volumes: "true"
    gke-gcsfuse/cpu-limit: "0"
    gke-gcsfuse/memory-limit: "0"
    gke-gcsfuse/ephemeral-storage-limit: "0"
spec:
  containers:
    # Your workload container spec
    ...
    volumeMounts:
    - name: serving-bucket-vol
      mountPath: /serving-data
      readOnly: true
  serviceAccountName: KSA_NAME 
  volumes:
    - name: gke-gcsfuse-cache # gcsfuse file cache backed by RAM Disk
      emptyDir:
        medium: Memory 
  - name: serving-bucket-vol
    persistentVolumeClaim:
      claimName: serving-bucket-pvc

  4. מחילים את המניפסט על האשכול:

    kubectl apply -f POD_FILE_PATH

    מחליפים את POD_FILE_PATH בנתיב לקובץ ה-YAML.

אופטימיזציה של חיפושי DNS באמצעות NodeLocal DNSCache ב-GKE

בגרסאות GKE מוקדמות יותר מ-1.34.1-gke.3899000, אם משתמשים ב-Cloud Storage FUSE עם פרוטוקול HTTP/1.1, יצירה תכופה של חיבורים חדשים עלולה להוביל לנפח גדול של חיפושי DNS. התנהגות כזו עלולה להשפיע על הביצועים, במיוחד בסביבות GKE.

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

  • Standard Pods: פריסת NodeLocal DNSCache מייעלת באופן אוטומטי את חיפושי ה-DNS עבור רוב ה-Pods הרגילים באשכול.

  • ‫Host network Pods: כדי להשתמש ב-NodeLocal DNSCache, צריך לבצע שינוי נוסף בהגדרה של Pods שמשתמשים בהגדרה hostNetwork: true. צריך לבטל את ברירת המחדל של dnsPolicy במפרט של ה-pod ולהגדיר את הערך ClusterFirstWithHostNet.

בדרך כלל אין צורך במטמון DNS נפרד בתרחישים הבאים, כי המערכת מטפלת במטמון באופן פנימי:

  • מכונות וירטואליות ב-Compute Engine: ליבת מערכת ההפעלה של המכונה הווירטואלית בדרך כלל שומרת במטמון את בדיקות ה-DNS בצורה יעילה, ולכן אין צורך בשכבת מטמון נוספת.

  • ‫GKE 1.34.1-gke.3899000 ואילך: בגרסאות האלה של Cloud Storage FUSE יש מטמון DNS מובנה, שפותר את הבעיה של חיפושים בתדירות גבוהה באופן פנימי.

הגדרת מאפייני עוצמת הקול

מאפייני נפח מאפשרים להגדיר התנהגות ספציפית של מנהל התקן ה-CSI של Cloud Storage FUSE.

מנהל התקן ה-CSI של Cloud Storage FUSE לא מאפשר לציין ישירות את קובץ ההגדרות של Cloud Storage FUSE. אפשר להגדיר חלק מהשדות בקובץ ההגדרות באמצעות מאפייני הנפח של Cloud Storage FUSE CSI. הדרייבר של CSI מטפל בתרגום של ערכי המאפיין volume לשדות בקובץ ההגדרות.

רשימה מלאה של מאפייני עוצמת הקול הנתמכים זמינה בחומר העזר בנושא מאפייני עוצמת הקול.

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

  • בשדה spec.csi.volumeAttributes במניפסט של PersistentVolume, אם אתם משתמשים בנפחי אחסון מתמיד.
  • בשדה spec.volumes[n].csi.volumeAttributes, אם משתמשים בכרכים זמניים של CSI.

בקובץ המניפסט, אפשר לציין את מאפייני עוצמת הקול כצמדי מפתח/ערך. לדוגמה:

volumeAttributes:
  mountOptions: "implicit-dirs"
  fileCacheCapacity: "-1"
  gcsfuseLoggingSeverity: warning

מדדים של Cloud Storage FUSE

מדדי Cloud Storage FUSE הבאים זמינים עכשיו דרך GKE Monitoring API. פרטים על מדדים של Cloud Storage FUSE, כמו תוויות, סוג ויחידה, מופיעים במאמר מדדי מערכת של GKE. המדדים האלה זמינים לכל Pod שמשתמש ב-Cloud Storage FUSE, ואפשר להשתמש במדדים כדי להגדיר תובנות לכל נפח ולא לכל קטגוריה.

המדדים מופעלים כברירת מחדל החל מגרסה 1.33.0-gke.2248000 של GKE ואילך. כדי להשבית אותן, מגדירים את מאפיין עוצמת הקול disableMetrics לערך true.

מדדים של מערכת קבצים

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

  • gcsfusecsi/fs_ops_count
  • gcsfusecsi/fs_ops_error_count
  • gcsfusecsi/fs_ops_latency

מדדים של Cloud Storage

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

  • gcsfusecsi/gcs_download_bytes_count
  • gcsfusecsi/gcs_read_count
  • gcsfusecsi/gcs_read_bytes_count
  • gcsfusecsi/gcs_reader_count
  • gcsfusecsi/gcs_request_count
  • gcsfusecsi/gcs_request_latencies

מדדים של מטמון קבצים

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

  • gcsfusecsi/file_cache_read_bytes_count
  • gcsfusecsi/file_cache_read_latencies
  • gcsfusecsi/file_cache_read_count

הפעלת ברירות המחדל של הביצועים של Cloud Storage FUSE

החל מגרסה 1.33.2-gke.4655000, ‏ GKE מפעיל באופן אוטומטי מספר הגדרות ברירת מחדל של ביצועים ל-Cloud Storage FUSE שפועל בצמתים שמגובים על ידי סוגי מכונות עם ביצועים גבוהים. הגדרות ברירת המחדל האלה של הביצועים לא נתמכות מגרסה 1.34.1-gke.1431000 עד גרסה 1.34.1-gke.3403001 בגלל בעיה ידועה.

במהלך טעינת אמצעי האחסון, מנהל התקן ה-CSI של Cloud Storage FUSE מאחזר את סוג מופע הצומת של היעד ומעביר אותו ל-Cloud Storage FUSE באמצעות אפשרות טעינה חדשה machine-type.

כשמעבירים לו סוג מכונה עם ביצועים גבוהים, Cloud Storage FUSE מגדיר אוטומטית את אפשרויות הטעינה הבאות שמוגדרות כברירת מחדל:

  • metadata-cache:negative-ttl-secs:0
  • metadata-cache:ttl-secs:-1
  • metadata-cache:stat-cache-max-size-mb:1024
  • metadata-cache:type-cache-max-size-mb:128
  • implicit-dirs:true
  • file-system:rename-dir-limit:200000
  • write:global-max-blocks:1600

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

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

mountOptions: "implicit-dirs,disable-autoconfig"

שיטות מומלצות לשיפור הביצועים

בקטע הזה מפורטות כמה טכניקות מומלצות לשיפור הביצועים ולאופטימיזציה של מנהל התקן CSI של Cloud Storage FUSE.

  • שימוש בקטגוריות עם מרחב שמות היררכי (HNS): מומלץ להשתמש בקטגוריות עם HNS כדי להשיג עלייה משמעותית של פי 8 במספר השאילתות הראשוניות לשנייה (QPS). הבחירה הזו גם מאפשרת לשנות שם של ספריות במהירות ובאופן אטומי, וזהו תנאי חיוני ליצירת נקודות ביקורת יעילות באמצעות Cloud Storage FUSE. קטגוריות עם HNS מאפשרות חוויה טובה יותר שדומה לשימוש בקבצים,כי הן תומכות ב-40,000 בקשות קריאה של אובייקטים ו-8, 000 בקשות כתיבה של אובייקטים בשנייה. זה שיפור משמעותי לעומת 8,000 בקשות קריאה של אובייקטים ו-1,000 בקשות כתיבה של אובייקטים בשנייה שמוצעות בקטגוריות שטוחות.

  • טעינת ספריות ספציפיות כשזה אפשרי: אם עומס העבודה שלכם כולל גישה לספרייה ספציפית בתוך קטגוריה, השתמשו בדגל --only-dir במהלך הטעינה. הגישה הממוקדת הזו מזרזת את הקריאות לרשימה, כי היא מגבילה את היקף הקריאות ל-LookUpInode, שכוללות קריאה ל-list+stat לכל קובץ או ספרייה בנתיב שצוין. אם מצמצמים את הנתיב של נקודת הגישה לספריית המשנה הנדרשת, אפשר לצמצם את מספר הקריאות האלה ולשפר את הביצועים.

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

  • מקסום משאבי ה-sidecar של GKE: Cloud Storage FUSE פועל בתוך קונטיינר sidecar בסביבת GKE. כדי למנוע צווארי בקבוק במשאבים, צריך להסיר את המגבלות על צריכת המעבד והזיכרון של קונטיינר ה-sidecar. כך Cloud Storage FUSE יכול לשנות את ניצול המשאבים שלו בהתאם לדרישות עומס העבודה, ולמנוע הגבלת קצב העברת נתונים (throttling), מה שעוזר להבטיח תפוקה אופטימלית.

  • אכלוס מראש של מטמון המטא-נתונים: מפעילים את האחזור המקדים של המטא-נתונים עבור מנהל התקן ה-CSI. כך מאכלסים ביעילות את המטא נתונים ואת מטמון הרשימות, מצמצמים את הקריאות למטא נתונים ב-Cloud Storage ומאיצים את ההרצה הראשונית. הרבה מסגרות ML מבצעות את הפעולה הזו באופן אוטומטי, אבל חשוב לוודא שהשלב הזה מתבצע בקוד אימון מותאם אישית. מידע נוסף זמין במאמר שימוש באחזור מראש של מטא-נתונים כדי לאכלס מראש את מטמון המטא-נתונים.

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

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

  • אופטימיזציה של נקודות ביקורת: כדי להשתמש בנקודות ביקורת עם Cloud Storage FUSE, מומלץ מאוד להשתמש בקטגוריית HNS. אם משתמשים בקטגוריה שלא מוגדרת בה מערכת HNS, צריך להגדיר את הפרמטר rename-dir-limit לערך גבוה כדי להתאים לשינוי השמות של הספריות שנעשה לעיתים קרובות על ידי מסגרות ML במהלך יצירת נקודות ביקורת. עם זאת, שימו לב ששינוי שמות של ספריות בדליים שאינם HNS עשוי להיות לא אטומי, והוא עשוי להימשך זמן רב יותר.

  • הפעלת שמירת רשימות במטמון: כדי לשפר עוד יותר את הביצועים, מפעילים שמירת רשימות במטמון באמצעות הדגל --kernel-list-cache-ttl-secs. התכונה הזו שומרת במטמון את רשימות הספרייה והקבצים, וכך משפרת את המהירות של פעולות ls. שמירת רשימות במטמון מועילה במיוחד לעומסי עבודה שכוללים רישומים חוזרים של כל הספרייה, כמו בתרחישי אימון של AI/ML. מומלץ להשתמש במטמון של רשימות עם נקודות הרכבה לקריאה בלבד, כדי לשמור על עקביות הנתונים.

  • הגדלת הקריאה מראש של ליבת המערכת: בעומסי עבודה שכוללים בעיקר קריאות רציפות של קבצים גדולים, כמו שירות ושחזור של נקודות ביקורת, הגדלת הגודל של הקריאה מראש יכולה לשפר משמעותית את הביצועים. כדי להגדיל את קריאת הנתונים מראש ב-Cloud Storage FUSE, מציינים את הדגל read_ahead_kb ב-mountOptions ומגדירים אותו ל-1MB (למשל read_ahead_kb=1024). כדי להשתמש בתכונה הזו, צריך GKE גרסה 1.32.2-gke.1297001 ואילך. במאגרי מידע אזוריים, Cloud Storage FUSE מנהל אוטומטית את פרמטר הליבה read_ahead_kb ב-GKE בגרסה 1.35.0-gke.3047001 ואילך. לכן, האפשרות read_ahead_kb לא רלוונטית, והמערכת תתעלם מכל ערך שיוזן בה.

  • הפעלת כתיבה של נתונים בזמן אמת: כתיבה של נתונים בזמן אמת היא נתיב כתיבה חדש שמעלה נתונים ישירות ל-Cloud Storage בזמן שהם נכתבים. הגישה הזו שונה משיטת הכתיבה שמוגדרת כברירת מחדל, שבה כל הכתיבה מועברת באופן זמני לספרייה מקומית ואז מועלית ל-Cloud Storage אחרי פעולה של close או fsync. כתיבה באמצעות סטרימינג מקטינה את זמן האחזור ואת השימוש בנפח האחסון, ולכן היא מועילה במיוחד לכתיבות גדולות ורציפות, כמו נקודות ביקורת. כדי להפעיל כתיבה לסטרימינג, מציינים את התכונה הניסיונית בשורת הפקודה enable-streaming-writes ב-mountOptions.

פתרון בעיות

מידע נוסף על פתרון בעיות זמין במאמרים הבאים:

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