שיקולי ביצועים

בדף הזה מפורטות הנחיות להגדרת סביבת Google Cloud Managed Lustre כדי להשיג את הביצועים הכי טובים.

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

ביצועים אחרי הגדלת הקיבולת

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

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

ניצול גבוה של הקיבולת

אם השימוש בנפח האחסון של מופע מסוים מגיע ל-90%, יכול להיות שהביצועים של המופע ירדו. מומלץ להגדיל את הקיבולת של מכונת Managed Lustre. יכול להיות שתצטרכו לבקש מכסה נוספת לפני ההרחבה.

אם מוצגות שגיאות No space left on device אבל במופע שלכם מוצג נפח אחסון פנוי, כדאי לעיין במאמר בנושא שגיאות No space left on device.

יחידת השידור המקסימלית (MTU) של רשת VPC

כשיוצרים רשת VPC, הגדרת הערך של mtu (יחידת שידור מקסימלית, או הגודל של מנת ה-IP הגדולה ביותר שאפשר לשדר ברשת הזו) לערך המקסימלי המותר של 8896 משפרת את הביצועים בעד 10% בהשוואה לערך ברירת המחדל של 1460 בייט.

אפשר לראות את ערך ה-MTU הנוכחי של הרשת באמצעות הפקודה הבאה:

gcloud compute networks describe NETWORK_NAME --format="value(mtu)"

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

סוגי מכונות ב-Compute Engine

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

  • להגדיל את מספר המעבדים הווירטואליים. רוחב הפס המקסימלי של התעבורה היוצאת לכל מכונה הוא בדרך כלל 2Gbps לכל vCPU, עד למקסימום של סוג המכונה.
  • בוחרים סדרת מכונות שתומכת במגבלות גבוהות יותר של תעבורת נכנסת ויוצאת. לדוגמה, מכונות C2 עם תמיכה ברשת Tier_1 יכולות להגיע לרוחב פס של עד 100Gbps ליציאה. מכונות C3 עם תמיכה ברשת Tier_1 יכולות להגיע למהירות של עד 200‎ Gbps.
  • הפעלה של ביצועי רשת ברמה 1 לכל מכונה וירטואלית עם סוגי מכונות גדולים יותר.
  • משתמשים ב-Google Virtual NIC‏ (gVNIC).‏ gVNIC היא האפשרות היחידה לסוגי מכונות מדור 3 ומעלה. השימוש ב-gVNIC נדרש כשמשתמשים ברשת Tier_1.

מידע מפורט זמין במאמר בנושא רוחב פס ברשת.

הגדרה של כמה מתאמי NIC

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

כדי להגדיר כמה כרטיסי רשת, צריך:

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

אימות איזון התנועה

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

Compute Engine

כדי לוודא שהנתונים מאוזנים, אפשר לעקוב אחרי ממשקי הרשת שהוגדרו (לדוגמה, eth0 ו-eth1) באמצעות nload בזמן יצירת תנועה בעורף המערכת של Managed Lustre:

nload -m eth0 eth1

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

GKE

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

  1. מזהים את הצומת שבו מתוזמן עומס העבודה:

    kubectl get pod POD_NAME -o wide

    מחליפים את POD_NAME בשם ה-Pod. בפלט פקודה, רושמים את השם בעמודה NODE.

  2. מפעילים את הכלי לניפוי באגים ברשת בצומת הזה:

    kubectl run multi-nic-debug --rm -i --tty --image=nicolaka/netshoot \
  --overrides='{"spec": {"hostNetwork": true, "nodeSelector": {"kubernetes.io/hostname": "NODE_NAME"}, "tolerations": [{"key": "nvidia.com/gpu", "operator": "Exists", "effect": "NoSchedule"}]}}' \
  -- /bin/bash -c "apk update && apk add nload && nload -m eth0 eth1"

    מחליפים את NODE_NAME בשם הצומת מהשלב הקודם.

  3. בפלט, מנתחים את קצבי העברת הנתונים בעמודה Outgoing (יוצא) עבור eth0 ו-eth1. אם ההגדרה מצליחה, קצבי העברת הנתונים יהיו שווים בערך. הפלט אמור להיראות כך:

    Device eth0 [10.1.0.50] (1/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.63 MBit/s                       Curr: 1.46 GBit/s
Avg: 1.60 MBit/s                        Avg: 1.44 GBit/s
Min: 1.40 MBit/s                        Min: 1.25 GBit/s
Max: 1.64 MBit/s                        Max: 1.47 GBit/s
Ttl: 590.94 GByte                       Ttl: 405.19 GByte

Device eth1 [172.16.15.5] (2/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.64 MBit/s                       Curr: 1.47 GBit/s
Avg: 1.62 MBit/s                        Avg: 1.44 GBit/s
Min: 1.42 MBit/s                        Min: 1.26 GBit/s
Max: 1.66 MBit/s                        Max: 1.47 GBit/s
Ttl: 587.68 GByte                       Ttl: 406.36 GByte

  4. כדי לצאת ממנפה הבאגים, מקישים על Ctrl+C.

פתרון בעיות נפוצות שגורמות לצווארי בקבוק

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

  • מספר לא מספיק של מכונות לקוח: מכונת לקוח אחת מוגבלת על ידי המעבד הווירטואלי (vCPU) שלה ומגבלות העיבוד של רשת עם קישור יחיד. כדי להגיע לניצול מלא של רמות הביצועים הגבוהות, צריך לפזר את העומס. לדוגמה, כדי להגיע לרוחב הפס המקסימלי של מערכת קבצים מנוהלת של Lustre בנפח 100,000MBps, בדרך כלל צריך לפחות 60 מכונות לקוח רגילות (או 12 מכונות לקוח שמגדירות שימוש ברשת ברוחב פס גבוה ברמה 1) שכותבות במקביל. כדי להגיע לגודל המקסימלי של מופע בכל רמת ביצועים, יכול להיות שתצטרכו יותר מ-2,500 מכונות לקוח שמוגדרות לשימוש ברשת ברוחב פס גבוה ברמה 1.

  • MTU לא אופטימלי של ענן וירטואלי פרטי (VPC): כברירת מחדל, רשתות VPC משתמשות ב-MTU של 1460 (מסגרות אתרנט רגילות). כדי להשתמש באחסון עם ביצועים גבוהים כמו Managed Lustre, צריך להגדיר מסגרות ג'מבו עם MTU של 8896. הפעלה עם MTU רגיל של 1460 מחייבת את המעבד לעבד יותר מפי שניים ממספר חבילות הרשת, מה שמוסיף עומס על המעבד ומגביל את רוחב הפס המקסימלי.

  • חסרה הגדרה של רוחב פס ברשת Tier 1: בסוגים רבים של מכונות בעלות ביצועים גבוהים צריך להביע הסכמה מפורשת לשימוש ברוחב פס ברשת Tier 1.

    • ב-Compute Engine ובמאגרי צמתים רגילים של GKE, משתמשים בדגל --network-performance-configs=total-egress-bandwidth-tier=TIER_1 במהלך היצירה. בלי התג הזה, יכול להיות שהמכונה הווירטואלית או הצומת יוגבלו למגבלת יציאה נמוכה יותר שמוגדרת כברירת מחדל.
    • ב-GKE Autopilot, לא מציינים את הדגל הזה באופן ישיר. במקום זאת, בוחרים סדרת מכונות שתומכת ברוחב פס גבוה יותר (כמו c3) באמצעות בוררי צמתים במפרט של ה-Pod.

    מידע נוסף זמין במאמר בנושא סוגי מכונות ב-Compute Engine.

  • שימוש לא מאוזן ב-Object Storage Target ‏ (OST) של Lustre:‏ Managed Lustre מפצל נתוני קבצים בין כמה Object Storage Target ‏ (OST). אם הבדיקה או עומס העבודה כותבים לקובץ יחיד לא מפוספס, או אם משימות של לקוח כותבות דפוסים שמעמיסים יתר על המידה על OST יחיד, ה-OST הזה הופך לצוואר בקבוק בזמן ששאר מערכת הקבצים לא פעילה. כדי למנוע את הבעיה הזו, צריך לוודא שמאזנים את מטען הנתונים של הכתיבה באופן שווה בין כל ה-OST הזמינים (לדוגמה, באמצעות שימוש במצב של קובץ לכל תהליך בבדיקות ביצועים).

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