NVIDIA GPU Operator: היכן הולכת לאיבוד הקצאת המאיצים
צביר עם מאיצים לעתים רחוקות שוהה במצב סרק בגלל מחסור בחומרה — לעתים קרובות יותר הזמן שבו המאיצים בטלים נגרם מכך שהקצאת ה-GPU בצביר אינה תואמת את המצב בפועל של הצמתים.
צומת מסומן ככזה שמכיל כרטיס, אך הדרייבר לא עלה לאחר עדכון הקרנל, ה-device plugin לא רשם את המשאב, והמתזמן כבר אינו רואה כרטיסים פנויים. המשימות ממתינות בתור, בעוד המאיצים עומדים ללא עומס.
השורש בדרך כלל בהתקנה ידנית של דרייברים על הצמתים. בחלק מהמכונות יש סט ספריות שונה מזה שבאימג'; מישהו הפעיל מחדש את השרת ולא החזיר את התצורה; בצומת אחד גרסת הדרייבר חדשה, ובאחר — מפגרת בכמה מהדורות.
ככל שיש יותר צמתים, כך מהר יותר מצטברת הסטייה, ותדירות רבה יותר המהנדס, במקום לעבוד עם המודל, מגלה מדוע צומת מסוים הפסיק להעמיד לרשות כרטיס.
צוואר הבקבוק השני בתזמון משימות — מהימנות המשאבים. המתזמן מחלק רק את מה שמוצהר על ידי הצומת, ולכן ללא רישום נכון של הכרטיסים העומס או שאינו עולה כלל, או שכמה תהליכים חולקים כרטיס אחד וקורסים בגלל זיכרון. חלק מהמשימות עוברות לצמתים ללא מאיץ ומסתיימות ב-timeout כבר לאחר שהושקע זמן התור.
NVIDIA GPU Operator מעביר את הדרייברים, רישום הכרטיסים וסימון הצמתים למצב דקלרטיבי של הצביר: הצומת עצמו מדווח במה הוא מצויד, והסטייה בין הגרסאות מטופלת בעדכון רגיל, ולא בכניסות ידניות למכונה.
להלן נבחן כיצד זה בנוי והיכן נותרות המלכודות — מהתאמת הדרייבר לקרנל ועד לגישה משותפת של כמה משימות לכרטיס אחד.
מה משתנה בצביר לאחר אוטומציה של המאיצים
לאחר ש-NVIDIA GPU Operator נוטל על עצמו את מחזור החיים של המאיצים, הקצאתם מפסיקה להיות אוסף של צעדים ידניים. הדרייבר, הספריות ורכיבי התזמון מותקנים על הצומת באופן עקבי, הצביר רואה את המאיץ כמשאב רגיל ומחלק אותו בין המשימות. הכנת צומת חדש נכנסת לחלון זמן צפוי, במקום לרצף שכל מהנדס ביצע מהזיכרון שלו.
הפעולות הידניות פוחתות באופן ניכר: עדכון הדרייבר והענקת גישה להתקן מתוארים באופן דקלרטיבי ומיושמים באופן זהה בכל הצמתים. זה מסיר סוג תקלות נפרד — סטייה בין גרסאות הדרייבר והספריות בין המכונות, שבגללה המשימה או שלא עלתה, או איבדה גישה למאיץ כבר במהלך העבודה.
יכולת התצפית של המאיצים מפסיקה להיות סיפור נפרד. עומס, שגיאות וסימני התחממות יתר נאספים באותו מעגל שבו נאספים המדדים של שאר הצביר, ולכן ההידרדרות נראית לפני שהמשימות נופלות, ולא אחרי. את התשובה לשאלה «איזה צומת מתנהג באופן לא אופייני» נותן גרף, ולא יומני האירועים של מכונה מסוימת.
גם העדכונים ניתנים לניהול: ענף חדש של הדרייבר מתגלגל על הצמתים בגלים, השאר ממשיכים לשרת את העומס, והחזרה לגרסה הקודמת אינה דורשת בנייה מחדש של הצביר. סך הכול חמישה שינויים מדידים — הקצאה אחידה של המאיצים, זמן צפוי להכנת הצומת, פחות פעולות ידניות, הסרת סוג תקלות ובעדכונים מבוקרים.
אפשרויות פריסה: תצורה ידנית או שכבה מנוהלת
הבחירה בין התקנה ידנית לשכבה מנוהלת נקבעת לא לפי גודל הצביר, אלא לפי תדירות החלפת הדרייברים וכמה מאיצים שונים פועלים באותו Pool. NVIDIA GPU Operator מאגד דרייבר, device plugin, טלמטריה ותוויות צמתים לאובייקט דקלרטיבי אחד, אך מוסיף מחזור חיים משלו, שגם אותו יש לתחזק.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| הרכבה ידנית על הצמתים | צומת אחד-שניים, עדכונים נדירים, שילוב קבוע של דרייבר וספריות | עדכון רק באמצעות יצירה מחדש של הצומת, הגרסאות נבדלות בין המכונות, שחזור לאחר תקלה — ידני |
| שכבה מנוהלת של האופרטור | הצביר גדל, מאיצים מדורות שונים, נדרשים עדכונים ללא השבתה | דורשת תוויות ו-tolerations על הצמתים, סדר עדכון משל עצמה, מתנגשת עם דרייבר שכבר מותקן |
| Pool צמתים ייעודי | ערבוב של אימון והסקה, פרופיל שונה של צריכת משאבים | נדרשים taint-ים וכללי תזמון, חלק מהמלאי בטל בין משימות |
| מצב היברידי | חלק מהמלאי מועבר לשכבה המנוהלת, חלק נשאר בתצורה ידנית | סט כפול של הוראות לצוות, סטיית גרסאות בין המקטעים |
בפועל הבחירה נבדקת בשאלה אחת: כמה פעולות ידניות ייוותרו בעת החלפת גרסת הדרייבר בכל המלאי. אם התשובה היא «ליצור מחדש את הצמתים» — ניקח את השכבה המנוהלת, ואם «לא לשנות דבר» — ההרכבה הידנית פשוטה יותר לתחזוקה.
המצב ההיברידי מוצדק בתקופת המיגרציה: הוא מאפשר להעביר לניהול Pool אחד, בלי לגעת בשאר, ולחזור אחורה בכל שלב.
שלבי ההטמעה: מביקורת הצביר ועד מסירה לכם
סדר העבודה בנוי כך שכל שינוי יהא בר-בדיקה, ומצב הצביר — בר-החזרה. אנחנו מתחילים במיפוי מלאי, ומסיימים במסירת תצורות ומדדים לצוות שלכם.
- ביקורת הצביר. אוספים את הרכב הצמתים עם המאיצים, את הסימון, את הדרייברים המותקנים ואת אופן חלוקת ההתקנים על ידי המתזמן. כאן גם מזהים התנגשויות: דרייברים ישנים, תצורות ידניות, מגבלות שנשכחו.
- תרשים מיקום המאיצים. מסכמים אילו משימות מקבלות התקנים וכמה, כיצד מחלקים את הצמתים בין הצוותים, ואילו תוויות ומגבלות מונעות מפודים זרים לתפוס מאיץ.
- הגדרת האופרטור. מתקינים דרייברים, גישה להתקנים וטלמטריה באופן דקלרטיבי — הפרמטרים מתוארים במאגר. שיתוף של מאיץ אחד בין משימות מפעילים רק במקום שבו פרופיל העומס מצדיק זאת.
- בדיקה על עומס אמיתי. מריצים לא סינתטיקה אלא מודל או שירות בעבודה: זמן העלייה לכשירות, ניצולת, התנהגות בעת פינוי פודים ובכמה צמתים בו-זמנית.
- תוכנית חזרה אחורה. קובעים את סדר החזרה למצב הקודם: הוצאת צמתים מה-Pool, הסרת השינויים, נקודות שחזור. את החזרה אחורה בודקים על מתקן ניסוי, ולא מתארים במילים.
- מסירה לתפעול. מוסרים תצורות, תרשים מיקום, מדדים והתראות, הוראות לפעולות שגרתיות ולעדכון דרייברים.
כל שלב מסתיים בארטיפקט בר-בדיקה: תרשים, תצורה, דוח על הרצת עומס. לכן התוצאה אינה תלויה במי שנשאר בצוות לאחר המסירה.
תצורות, תרשימים ותקנות שנשארים אצלכם
החבילה נמסרת לא כ«תיקייה עם קבצים», אלא כמערכת עובדת: תצורות במערכת בקרת גרסאות עם תיאור הסטיות מערכי הבסיס, תרשימים שלפיהם מהנדס חדש מבין תוך שעה כיצד תנועה ומשימות מגיעות למאיצים, ותקנות שלפיהן העדכון מתבצע בלי לעצור שירותים. להלן — מה בדיוק נשאר אצלכם לאחר המסירה.
- תצורות של צמתים עם מאיצים — מניפסטים של תוויות ובחירת צמתים, פרופילים של שיתוף מאיץ, פרמטרים של דרייבר ושל device plugin. בנפרד מתעדים אילו ערכים שונו במכוון ומדוע, כדי שבעדכון הבא הם לא יימחקו על ידי הגדרות ברירת המחדל.
- תרשימים של אינטראקציה בין רכיבים — מתזמון המשימה ועד להקצאת ההתקן: אילו שירותים משתתפים, באיזה סדר עולים, היכן נקודת הכשל. התרשים מקושר לשמות האובייקטים בצביר, ולא לבלוקים מופשטים.
- מדיניות גישה והפרדת הרשאות — תפקידים לתפעול, פיתוח ותצפית; מי יכול לשנות פרמטרים של מאיצים, ומי רק קורא מדדים. ההרשאות לשינוי דרייברים הוצאו מחשבונות היישום.
- תקנון עדכון — סדר הפעולות בעת יציאת ענף חדש: הכנת צמתים, ניקוז, בדיקת משימות ביקורת, קריטריונים לחזרה אחורה. החזרה אחורה מתוארת בנפרד ונבדקה על מתקן ניסוי לפני המסירה.
- תיעוד תפעולי — תקלות אופייניות (המשימה אינה רואה את המאיץ, הצומת מסומן כלא-כשיר, המדדים אינם מתיישבים), פקודות אבחון ומה לבדוק קודם כול.
- תרשים ניטור והתראות — אילו מדדים נאספים, אילו ספים נחשבים לחירום, למי וכיצד מגיעה התראה.
- צ'ק-ליסט לקבלה ולמסירת משמרת — רשימה קצרה של בדיקות לאחר כל עבודה בצביר, כדי ששינויים לא יישארו בלתי מורגשים.
כל זה נשמר לצד קוד התשתית, ולא בהתכתבות, — ולכן עדכון האופרטור ועדכון הדרייברים מפסיקים להיות אירוע עם תוצאה לא ידועה.
ניתוח פרויקט: הצביר הפסיק לשהות במצב סרק
אלינו הגיע צביר לאימון מודלים ולעיבוד נתונים באצווה: עשרות משימות בתור, צמתים הטרוגניים עם מאיצים מדורות שונים, ותחושה מתמשכת בצוות שחצי מההרצות נופלות «לא בגלל הקוד».
צוואר הבקבוק התברר לא במתזמן, אלא בשכבה שבין החומרה לצביר. הדרייברים, הספריות וה-device plugin הותקנו על כל צומת ידנית, הגרסאות בין המכונות נבדלו, ולאחר הפעלה מחדש הצומת חזר לפעולה בלי מאיצים נראים לעין — המשימה נפלה כבר בהתחלה, ואכלה את התור ואת זמן המהנדסים.
העברנו את הכנת הצמתים ל-NVIDIA GPU Operator. האופרטור פורש בעצמו את הדרייברים, מערך הספריות, ה-device plugin ואיסוף מדדים דרך DaemonSet, מסמן את המכונות לפי הימצאות המאיץ בפועל, ומביא צומת חדש למצב עבודה בלי צעדים ידניים. בנוסף הגדרנו בדיקות כשירות: הצומת נכנס ללוח הזמנים רק כאשר המאיץ נראה לעין וכבר נבדק.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| שיעור ההרצות המוצלחות של משימות | 71% | 98% |
| הכנת צומת חדש | 45–60 דקות ידנית | 5–7 דקות אוטומטית |
| שחזור לאחר תקלת צומת | 2–3 שעות | 10–15 דקות |
| פניות לתמיכה בנושא מאיצים | כמה בשבוע | בודדות ברבעון |
בנפרד הסרנו עומס מהמשמרת התורנית: תקלות אופייניות מטופלות כעת ביצירה מחדש של הצומת, ולא בבדיקה של מכונה מסוימת. מקרה כזה אינו עוסק בהחלפת ציוד, אלא בשכבה מנוהלת מעליו.
מה לעשות אם ה-GPU כבר פרוס אך המשימות נופלות
המשימות נופלות בדרך כלל לא בגלל האופרטור, אלא בגלל סטייה בין שתי סכמות. בצמתים שהוגדרו ידנית, הדרייבר הותקן כחבילות, והתוויות שם הוצבו ביד. היכן שפועל NVIDIA GPU Operator, אותו דבר מגיע בקונטיינרים, והתוויות מנוהלות על ידי האופרטור.
כל עוד שתי הסכמות מתקיימות זו לצד זו, פודים מגיעים לצומת שאינו מקבל אותם: משאב ה-GPU אינו מפורסם, גרסת הדרייבר אינה תואמת, התוויות אינן עונות לסלקטור.
האבחון מתחיל במצב הצמתים ובאירועים: נראה אילו צמתים מעמידים את המשאב לרשות ואילו לא, היכן הקונטיינר עם הדרייבר מופעל מחדש ומוביל את הצומת לאי-כשירות. לאחר מכן משווים בין הצמתים שלושה דברים — תוויות, tolerations וגרסת דרייבר; הסטיות דווקא כאן גורמות לכמעט כל הנפילות בעת ההרצה.
מעבירים צומת-צומת, בלי לעצור את העבודה: הצומת נסגר לפודים חדשים, העומס שלו עובר לאחרים, לאחר מכן מוסרים ממנו התוויות הידניות והוא מתחבר לסכמה הכללית. לאחר המעבר, פרסום המשאב נבדק על ידי פוד ניסיון, ורק אז הצומת חוזר לפעולה. הקיבולת אינה נפגעת — מהעבודה הוצא צומת אחד, ולא כל ה-Pool.
איחוד הסכמות לאחת — זהו מקור אמת יחיד: גרסאות דרייבר, תוויות, tolerations ומדיניות מגיעים ממקום אחד, ואין מבצעים בהם עריכות ידניות. צמתים שהוגדרו חלקית אינם מיושרים ידנית אל האחרים, אלא מובאים לאותה צורה כמו המנוהלים, — כך נעלם סוג תקלות שבו המשימה נופלת בגלל צומת «לא נכון». את התוויות וה-tolerations המקוריים שומרים: החזרה אחורה — פעולה אחת, וחלון המעבר נמדד בדקות.
ספקות טכניים: תאימות, עדכונים, חזרה אחורה
פריסת האופרטור נוגעת בצמתים משותפים של הצביר, ולכן ספקות לגבי תאימות וחזרה לסכמה הקודמת הן טבעיות. להלן — תשובות למה שנבדק לרוב לפני ההתחלה: עם מה מתחבר הצביר הנוכחי, באיזה סדר מתבצעים העדכונים וכיצד נראית החזרה אחורה.
האם האופרטור תואם לצביר שלנו?
משווים את גרסת הצביר, סביבת ההרצה של הקונטיינרים ואת אופן התקנת הדרייברים על הצמתים. האופרטור מוגדר רק על צמתים עם מאיצים לפי תוויות ואינו מתערב בשאר — צביר מעורב ממשיך לעבוד כבעבר. אם הסביבה שונה מהטיפוסית, מריצים תחילה קבוצת צמתים לניסיון.
באיזה סדר מתבצעים העדכונים והאם אפשר לעבוד בזמן הזה?
העדכון מתבצע בגלים: תחילה צומת אחד, עליו בודקים את העומס, ולאחר מכן השאר. משימות מהצומת המתעדכן עוברות לפנויים, ולכן התורים והשירותים נשארים זמינים, והשבתה אינה מתוכננת. גרסת הדרייבר נקבעת בצביר, ולא נערכת ידנית בכל צומת — סטיות בין הצמתים אינן נוצרות.
מה עם תוכנית החזרה אחורה?
הסכמה הקודמת של התקנת הדרייברים נשמרת עד סוף העבודה, ותצורת האופרטור נשמרת כריליס נפרד עם היסטוריה — החזרה למצב הקודם אורכת צעד אחד. הסרת התוויות מחזירה את הצמתים למצב ההתחלתי. את תוכנית החזרה אחורה מתעדים בכתב לפני תחילת ההגדרה.
כיצד מופרדות ההרשאות של הצוותים?
ניהול האופרטור נשאר בידי צוות התשתית: עדכונים, תוויות צמתים, מדיניות. צוותי המוצר עובדים רק במרחבי השמות שלהם ומבקשים מאיצים דרך בקשה או מכסה. אין להם הרשאות ישירות לדרייברים ולרכיבי המערכת.
נדון במשימה: נחזור עם הערכה ותוכנית עבודה
ההערכה של הטמעת NVIDIA GPU Operator נשענת על שלושה דברים: אילו צמתים מיועדים למאיצים, כיצד בנוי הצביר כעת ומה בדיוק יחושב על המאיצים הללו. תארו את המשימה בצורה חופשית — זה יספיק כדי לחזור עם תוכנית, ולא עם שאלות הבהרה.
- תרשים הצביר: כמה צמתים ו-Pools, היכן ממוקמים המאיצים וכמה מהם בכל אחד
- כיצד הצביר מנוהל ומה מגביל אותו: מעגל סגור ללא רשת חיצונית, רישום אימג'ים פרטי, מדיניות גישה משל עצמו
- אילו עומסים יתפסו את המאיצים והאם יש צורך לחלק אותם בין הצוותים
- מה כבר נעשה: האם הדרייבר פרוס ידנית, אילו ניסיונות היו והיכן נעצרו
- דרישות לבידוד ולסדרי עדיפויות: מי יכול לתפוס מאיץ ומה חשוב יותר בעת מחסור
- חלון העבודה: מתי מותר להפעיל מחדש צמתים וכמה רגיש זמן ההשבתה
בתגובה תקבלו מסמך עבודה שלפיו ניתן להתחיל בעבודות:
- תרשים פריסה עם חלוקת הצמתים ל-Pools והתפקיד של כל אחד
- הרכב העבודות לפי שלבים: הכנת צמתים, פריסת האופרטור, בדיקת תזמון משימות, איסוף מדדים
- סדר הפריסה עם נקודות בקרה ותוכנית חזרה אחורה למצב הנוכחי
- לוחות זמנים להטמעה וצ'ק-ליסט קבלה: אילו בדיקות מאשרות שהעומס אכן עבר למאיצים
- מה יישאר לצוות שלכם: תצורות, תיאור מדיניות, הוראות לתחזוקה
תארו את המשימה — נחזור עם הערכה ותוכנית עבודה לצביר שלכם.