כמה מילים על מעבדי Power

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

אבל יש עוד אופציה שחלק קטן מהאנשים מכירים – אלו מעבדי ה-Power של IBM, ספציפית מעבדי Power8 ו-Power9.

קצת היסטוריה: אפל, IBM ומוטורולה החליטו אי שם בשנות ה-90 להתחרות באינטל ולהוציא מעבדים משל עצמם תחת השם PowerPC. מוטורולה הוציאה את המעבדים, אפל השתמשה בהם בשמחה ו-IBM גם השתמשו בהם בחלק מהשרתים והיה אפילו מחשב ThinkPad יחיד שיצא עם מעבד PowerPC שהריץ OS/2 (וזמן קצת לאחר מכן שיווקו הופסק כי לא היתה לו דרישה).

עם הזמן אפל נטשה את ה-PowerPC, ומוטורולה המשיכו ליצור למשך זמן מה מעבדים כאלו לשווקים נישתיים כמו Embedded. ב-IBM הבינו שאם הם רוצים להתחרות באינטל, הם צריכים לעבוד ולפתח את המעבדים בעצמם וכך IBM שחררה במשך השנים מספר מעבדי Power שונים. בהתחלה המעבדים הללו היו עמוסים בתקנים קנייניים שלא תמכו טוב בסטנדרטים כמו זכרון ECC רגיל, אך החל מ-2015 ב-IBM הבינו שכדאי לרדת מהעניין ולהשתמש בחומרה סטנדרטית, וכך מעבדי ה-Power8 ו-Power9 החלו לתמוך בזכרון רגיל לשרתים, תקן PCIe לכרטיסים (ב-Power9 התקן הוא PCIe 4.0 שכרגע לא נמצא באף שרת מבוסס מעבדי אינטל, זה רק יחל להופיע בשנה שנתיים הבאות, אם כי רוב הסיכויים שהחברות יקפצו ישר ל-PCIe 5.0) ועוד.

מבחינת ארכיטקטורת מעבד, הארכיטקטורה של Power9 היא מורכבת ולא אכנס לפרטי פרטים בפוסט זה (למעוניינים, דף ה-WIKI הזה מסביר יותר), אך נאמר כך: במעבדים כמו EPYC או Xeon, אנחנו רגילים למצוא Cores ו-Threads, כאשר הכלל הקבוע הוא שכל 2 Threads תופסים בעצם ליבה אחת. ב-Power9 זה שונה: ה-Threads נקראים Slices ועל כל Core ניתן לפנות ל-שמונה Slices. ישנם 2 סוגי מעבדי Power9, ה-SMT4 ו-SMT8 כאשר SMT4 מכיל 12 slices ו-SMT8 מכיל 24 slices. מבחינת ליבות, המעבד קיים במספר גרסאות, החל מ-4 ליבות ועד 22 ליבות.

המעבדים הללו יכולים להיות ב-2 תצורות: אחת בשיטה הידועה והפופולרית של Scale Up (נקראת: SU) והשניה היא Scale OUT (נקראת: SO). מערכות שמשתמשות ב-Power9 SU לדוגמא הינן מערכות עם 4 מעבדים ואילו מערכות SO הינן מערכות עם 2 מעבדים. מערכות SU כוללות תמיכה בזכרון ישיר למעבד (Directly Attached) מסוג DDR4 ואילו מערכות SO משתמשות בזכרון כזכרון חוצץ. מהירות הגישה לזכרון ב-SO היא עד 120 ג'יגהבייט לשניה ואילו ב-SU היא 230 ג'יגהבייט לשניה (הרבה יותר מכל מעבד מבוסס X86-64).

אחד היתרונות הגדולים של מעבדי Power9 היא קישוריות מאוד גבוהה לציודים הסובבים למעבד. במידה ומשתמשים ב-GPU של nVidia או ציודים אחרים, ב-IBM משתמשים בדבר שנקרא Bluelink ובעברית פשוטה: כל התקשורת בתוך המכונה עצמה היא הרבה יותר מהירה מהמעבדים המתחרים.

IBM משווקים מספר מכונות, כאשר חלק מהמכונות מגיעות עם מערכת קניינית של IBM ומתוכה בעזרת תוכנת PowerVM אפשר לבנות מכונות VM שמריצות לינוקס ויש ל-IBM גם מכונות שמריצות ישר לינוקס עוד מה-Boot (כמו L922, S914,AC922 ועוד). למעוניינים (יש כאלו?) אפשר להריץ על המערכות הללו גם .. AIX. מבחינת מערכות לינוקס הקיימות ל-Power9, המבחר הוא: SLE של SuSE ו-RHEL של רד-האט. ניתן להריץ גם גירסת Debian על Power9 אבל רק מה"עץ" של ה-Unstable עם מינימום Kernel 4.15 ומעלה.
אה, ואי אפשר להקים מכונות VM עם Windows על מכונות כאלו. אין תאימות ל-X86-64..

אז למי מיועדות המערכות הללו?

הקהל הראשון שירצה לשמוע על המערכות הללו הן חברות שמעוניינות לפתח AI או Deep Learning. בכל מכונה כזו ניתן להכניס 4-6 כרטיסי GPU מסוג Tesla של nVidia, ואם נבדוק את הביצועים של GPU כזה על מערכות Xeon בהשוואה למערכות Power9, נקבל שהביצועים של Power9 מבחינת קישוריות הם פי 7-10 יותר גבוהים. אם נתרגם זאת לתוכנות המקובלות, אז TensorFlow רץ פי 2.3 יותר מהר, Caffe פי 3.7 יותר מהר, ו-Chainer פי 3.8 יותר מהר על מערכות Power9 בהשוואה למעבדי Xeon החדשים ביותר.

הקהל האחר שגם יעניין אותו המכונות הללו הם חברות שרוצות להריץ קונטיינרים והרבה. כאשר כל מעבד תומך בעד 2 טרהבייט זכרון ויש לך 96 Threads/Slices, אתה יכול להריץ המון קונטיינרים, גדולים כקטנים – על מכונה אחת (ואין שום בעיה לעבוד עם מס' מכונות). IBM מציעים את תוכנת ה-Cloud Private שמיועדת לניהול קונטיינרים והיא רצה על בסיס שכולם מכירים – Kubernetes. אם כבר מדברים על קונטיינרים – כלים ומתודות של CI/CD עובדים יפה מאוד על מערכות Power9.

קהל נוסף שדווקא כן מכיר את ה-Power9 הם אלו שרוצים להקים HPC גדול. ל-IBM כבר יש פרויקטים של HPC שרצים כבר עם Scale גדול כמו Summit, Sierra, MareNostrum 4.

כמו תמיד, יהיו מי שירצו לדעת מי משתמש במערכות כאלו – הרבה מאוד חברות בחו"ל, וחברה שאולי שמעתם עליה.. Google.

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

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

על VDI ועל GPU בשרתים

כשאנחנו מקימים פתרון וירטואליזציה, ברוב המקרים אנחנו מקימים מערכות VM עם מערכת הפעלה לשרתים, כמו הפצות לינוקס למיניהן, גרסאות Windows Server, אולי FreeBSD וגם Appliances וירטואליים למיניהן. המכנה המשותף לכל אלו – אנחנו לא צריכים כרטיס גרפי יעודי בשרת בשביל להשתמש באותן מכונות וירטואליות.

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

לכן, כשאנחנו רוצים להקים מערכת VDI רצינית ל-50+ מכונות וירטואליות, אנחנו נצטרך כרטיסים גרפיים בשרת.

אז נתחיל במשהו פשוט: מה בעצם תפקיד ה-GPU בסביבה הוירטואלית?

התפקיד המרכזי של GPU בפתרון וירטואליזציה (וזה לא משנה איזו וירטואליזציה) הוא בעצם לקחת את כל העניין של "ציור" המסך הוירטואלי ולהזרים אותו אל ה-Client שרץ על המכונה הקטנה שנמצאת אצל המשתמש הסופי. לשם כך, כשאנחנו מתקינים GPU המיועד לשרתים, אנחנו מתקינים על כל VM תוספת שנקרא vGPU או Virtual GPU. במערכת זה יופיע כמעין "כרטיס" נוסף ב-Device Manager ואנחנו נצטרך Client יעודי (למעט במקרים של מיקרוסופט ששם RDP עדכני נותן את הפתרון עם תמיכה ל-RemoteFX. שימו לב ש-RemoteFX עובד טוב עם תוכנות תלת מימד רק ב-Windows Server 2016 ומעלה) להתחבר אליו ומשם נקבל את ההאצה.

מהי בעצם אותה האצה? ה-GPU בשרת הוירטואליזציה יוצר בעצם מסך (כמו המסך שמולכם) כרגע ועליו הוא "מצייר" את החלונות, הגרפיקה ואלמנטים ויזואליים נוספים. ברגע שהוא מסיים ליצור Frame של המסך, הוא משדר זאת בזרימת (Stream) וידאו אל ה-Client, כאשר ה-Client יכול להיות PC פשוט, מק, מכונת לינוקס מקומית, iPAD, iPhone או טלפון/טאבלט עם אנדרואיד. לא חשוב מה היכולות הגרפיות של מכשיר הקצה.

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

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

וכאן מגיעים כרטיסי GPU שונים.

בניגוד לפתרונות וירטואליזציה ששם אפשר "לדחוף" כמה שיותר מכונות וירטואליות, כל עוד יש מספיק משאבי זכרון ומעבד פנויים, ב-GPU הדברים מוגבלים. כמה מוגבלים? בד"כ GPU לשרתים יכול לשרת מקסימום בין 16 ל-32 משתמשים על אותו GPU. לכל מכונה וירטואלית אנחנו מגדירים כמות זכרון מה-GPU (בין חצי ג'יגה לדסקטופ בסיסי ועד 4 או 8 ג'יגה לדסקטופ וירטואלי שמריץ מערכות גרפיקה כבדות) ואין אפשרות ל-Over Provision, כלומר אם נרצה להרים 60 מכונות וירטואליות כ-VDI למשתמשי קצה, נצטרך בעצם 2 כרטיסי GPU יקרים שאת הזכרון שלהם בין המכונות הוירטואליות.

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

אז מה יש לשוק להציע מבחינת GPU?

אם נסתכל בפתרונות של nVidia המוצעים לשוק, יש את כרטיסי ה-GRID K1 ו-K2. אלו כרטיסים שיכולים להעביר סשנים של דסקטופ בסיסי (שוב – אופיס, דפדפן) בצורה לא רעה, אך אלו כרטיסים ישנים. כיום ל-nVidia יש כרטיסי TESLA, כאשר סידרה M מתאימה לדסקטופ בסיסי וסידרה P יותר מתאימה למשתמשים כבדים ואילו סידרה V מתאימה למשתמשים ממש כבדים (עריכת וידאו, פוטושופ בצורה מסחרית וכו').

מהצד של AMD יש את משפחת ה-Radeon Pro ודגמי S7150 (שמתאים עד ל-16 משתמשים) ו-S7150 X2 שמתאים עד ל-32 משתמשים כולל עבודות תלת מימד. כרטיס נוסף ש-AMD מוציאה בקרוב הוא ה-Radeon Pro V340 שמתאים למשתמשים כבדים (עד 32 משתמשים). היתרון של AMD מול nVidia הם מחירים נמוכים (לעיתים חצי מהמחיר ש-nVidia מבקשת) בלי להתפשר על ביצועים.

מי ממערכות הוירטואליזציה הקיימות צריך GPU למכונות VM דסקטופ? התשובה פשוטה: כולם.

ומה בדבר הכנסת כרטיסים "ביתיים" פשוטים לשרת כמו Geforce GTX 1080TI או VEGA 56/64 כפתרון זול? את זה לא תוכלו לעשות מכיוון שהדרייברים מזהים את הכרטיסים ומסרבים לעבוד איתם. פתרון של כרטיסים ביתיים בוירטואליזציה מתאים רק כשממפים (PCI Passthrough) את הכרטיס למכונת VM יחידה (רק מי בדיוק ירצה לעבוד מול שרת רועש?). פתרון של כרטיס ביתי יכול להתאים אם מריצים פתרון וירטואליזציה מקומי כמו KVM על לינוקס בתחנת עבודה כאשר מכונת VM של Windows משתמשת ב-KVM עם מיפוי לכרטיס ה-GPU. העניין קצת מורכב (ולא קיים בפתרונות כמו VMWare workstation, VirtualBox).

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

בפוסט הבא נדבר על השורה התחתונה, הכסף.

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

כמה מילים על לימוד-מכונה ועל GPU ועננים

עדכונים לפוסט – בסופו.

בשנים האחרונות, תחום ה"לימוד מכונה"/"לימוד עמוק"/"AI" ושלל שמות נוספים (ותוסיפו לכך טונות של Hype) קיבלו תאוצה מאוד חזקה. כיום התחום "חם" מאוד ואלו שמכירים את התחום נחטפים, וחברות כמו אמזון וגוגל מציעות משכורות מאוד מפתות (כמה מפתות? 50K ומעלה לחודש, בשקלים כמובן, ויש גם מענק חתימת-חוזה, תלוי כמה אתה מכיר, וכמה אתה מנוסה). סטארט אפים לנושאים אלו צצים כמו פטריות לאחר הגשם וכמובן שחברות הענן הציבורי הזדרזו להוציא שרותים שמציעים תחומים אלו בקלות מופלאה – תכניס את ה-DATA, הנה API קל לשימוש ובהצלחה.

אבל האם לחברות ולסטארטאפים שווה לרוץ לענן ולהשתמש בשרותי ה-SAAS הללו? כמו תמיד, אין כאן תשובה של "כן" או "לא". יש חלקים שבהחלט שווה להשתמש בענן הציבורי ובחלק מהמקרים – עדיף מכונות מקומיות.

מכיוון שהתחומים הללו מכסים תחומים כמו אודיו, וידאו, צ'אט בוטים ודברים רבים נוספים, לא ניכנס לדברים במובנים הטכניים לעומק אלא נדבר על הדברים בכלליות. באופן עקרוני, לא חשוב איזה AI או Deep Learning או Machine Learning מדובר, הכללים די ידועים:

  • אתה בונה את התוכנה (או משתמש בשילוב של Tensorflow, Caffe2 ושאר ספריות) ו"מסביר" לתוכנה מה אתה בעצם רוצה לעשות.
  • אתה מכניס את הנתונים שאתה רוצה לעבד.
  • אתה מכוון שוב ושוב ושוב ו"מאמן" את האלגוריתמים שהתוכנה תכיר את הנתונים ותתן תוצאות שאתה רוצה שתתן – עד לתוצאות שאתה רוצה.

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

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

זה – במבט על מגבוה בערך מה שקורה.

הבעיה מתחילה כשמקימים את החלק הראשון בענן. כיום, ברוב המקרים מומלץ לעשות את הדברים על GPU הואיל והוא מכיל אמנם "ליבות טיפשות" שמסוגלות לעשות רק דברים פשוטים, אבל יש אלפי ליבות פר GPU ולכן העיבוד יהיה הרבה יותר זריז מאשר לבצע אותו על CPU. הבעיה מתחילה בכך שאינך מקבל מקבל GPU יעודי עבור המכונה/מכונות שלך אלא רק חלק ממנו. כמה? אף ספק לא אומר, אבל אני יכול להמר על 1/8 או יותר נמוך (1/16, תלוי כמה GPU יש במכונה, תלוי כמה VM רצים עליה ושאר פרמטרים).

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

חברות גדולות שעוסקות בתחומים הללו כבר למדו שבכל מה שקשור לאימון, עדיף לעשות זאת In house ולא לסמוך על עננים, ומכיוון שהן חברות גדולות, הן יכולות להרשות לעצמן לרכוש מכונה כמו ה-DGX-1 של nVidia. כמה עולה המכונה הזו? 130,000 דולר, סכום שאין להרבה סטראטאפים או חברות קטנות או בינוניות. בשרת זה ישנם 8 כרטיסי Tesla מבוססי Volta (הארכיטקטורה החדשה של nVidia) שכוללים ליבות יעודיות ל-Tensor והרבה ליבות שמיועדות ל-CUDA. בנוסף, הכרטיסים מחוברים ביניהם עם NVLink שנותן מהירות מדהימה של 200 ג'יגהבייט לשניה פר כרטיס. בקיצור – מפלצת יעודית ל-AI/DL/ML. (אפשר ללחוץ על התמונה על מנת לקבל את הפרטים).

לאחרונה חברת nVidia הבינה שאותם חברות קטנות ובינוניות מעוניינות גם בפתרון. הם לא מחפשים לקנות DGX-1 והם מעדיפות פתרון יותר זול אך חזק. כרטיסים גרפיים כמו GTX 1080TI או אפילו Titan Xp הם טובים, אך המהירות עדיין אינה מספיקה.

לכן nVidia הוציאה בימים האחרונים את הכרטיס מימין. תכירו – זה ה-Titan V, ה"אח הקטן" של Tesla V100. מדובר על כרטיס עם אותו GPU כמו אחיו הגדול, אך יש לו 12 ג'יגהבייט זכרון (ב-Tesla יש 16), אין אפשרות לשרשר אותו עם Titan V אחרים (ואין SLI) ויש עוד מס' הבדלים – טבלת השוואה ניתן לראות כאן. אגב, אם אתם רוכשים כרטיס כזה, שדרגו ל-CUDA 9.1 שידע לתמוך בכל הפונקציות של הכרטיס.

מחיר הכרטיס (לא כולל מסים ומכס) – 3000$. יקר בהרבה מכל כרטיס אחר שמיועד ללקוחות פרטיים, אבל עדיין זול בהרבה בהשוואה ל-Tesla V100 (שאותו בין כה לא תוכלו להכניס לרוב השרתים). עם כרטיס כזה, אני יכול להבטיח לכם שהביצועים שלו יהיו גבוהים בהרבה מכל Instance עם GPU שתרימו בענן. (ניתן כמובן להרים מס' מכונות VM בשרתים מקומיים ולכל מכונה להצמיד GPU כזה בשיטת GPU Passthrough, כדאי לשאול את יצרן השרת לגבי התמיכה ב-Passthrough ולגבי IOMMU).

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

השלב השני לעומת זאת, עדיף לבצע אותו בענן, מכיוון שהתהליך ה-Evaluation של המידע שנכנס מהלקוח הוא הרבה יותר קצר ולכן גם חלק מ-GPU יכול להספיק לכך, מה עוד שבענן הרבה יותר קל לעשות Scale Out ולשרת בכך יותר ויותר לקוחות.

לסיכום: חברות הענן הציבורי יעשו הכל כדי שתשתמשו בשרותיהן ולשם כך הם עושים מאמצי שיווק אדירים. אישית, אינני חסיד של שרותי SAAS בנושאים שהועלו בפוסט זה ואני יותר מאמין בשיטות היותר קלאסיות של שרתים (לא ראיתי עדיין אף ענן ציבורי שמציע קונטיינרים עם GPU רציני. ניתן לעשות זאת מקומית אך זה עדיין לא דבר יציב) שמתווספים ל-Scale Out כדי לעמוד בעומס פניות מלקוחות ולכן השלב השני הרבה יותר מתאים לענן ואילו השלב הראשון – מתאים יותר להרצה מקומית.

עדכון 17/12/17: קיבלתי פניה לגבי מידע שגוי שאני מפרסם בפוסט זה ולכן אני רואה צורך להבהיר: אינני אומר ששום ענן ציבורי לא נותן תשתית מואצת GPU (במקרה של אמזון ומיקרוסופט – Tesla ובמקרה של גוגל – TPU). כולם נותנים שרות SAAS כזה או אחר ל-ML/DL מואצים, אבל זהו שרות SAAS. למי שמחפש פתרון VM או קונטיינרים נטו שבהם הוא יכול להשתמש בפשטות ב-tensorflow-gpu עם PIP ועם הקוד שלו – זה כרגע למיטב ידיעתי והבנתי – לא קיים.

כמה עדכונים על וירטואליזציות שונות

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

העדכון הראשון נוגע ל-vSphere גירסה 6 שאמורה לצאת בשנה הבאה. ישנם לא מעט חידושים (כל אחד יכול להצטרף לבטא) ואחד מהחידושים שכבר נכנס בגירסה 5.5 הוא NDDK חדש (ר"ת של Native Driver Development Kit). מי שמעוניין לקרוא קצת יותר מה שכתבו על כך, אפשר לקרוא כאן. אני אתייחס לאספקט טיפה שונה.

טכנית, עד גירסה 5.5 חברת VMWare די "תפסה טרמפ" על הדרייברים שיש ללינוקס. לא, ESXI אינו בנוי עם קרנל של לינוקס, אך ישנה מעין "שכבה" (vmkernel) שמתרגמת בין לקרנל הקנייני של ESXI לדרייברים שכתובים עבור לינוקס. היתרון: כבר ביום הראשון, היה אפשר להתקין את ESXI על כל דבר, כל עוד שזה היה מעבד X86 עם 64 סיביות ותמיכת VT. החסרון: שכבת ה"תרגום" הורידה חלק מהביצועים.

ב-6.0 שיגיע, החגיגה נגמרת. למען האמת, ב-5.5 כל הדרייברים שמגיעים עם ה-ISO הם Native אבל יש עדיין אפשרות להכניס דרייברים ישנים אם קימפלת ויצרת ISO חדש, אך לא תוכל לבצע את הטריק הזה ב-6.0 ולכן "קופסאות לבנות" (PC גנרי) לא יוכל להריץ גירסה 6.0, וכבר ב-5.5 קמו צעקות ש-VMWare העיפה דרייברים לכרטיסי רשת ביתיים.

ה-NDDK הוא קוד סגור ו-VMWare בשלב זה לא מתכננת לשחרר אותו לציבור, כך שיהיה מעניין לראות איך קהילת המשתמשים הביתיים תתגבר על הבעיה (מה עוד שב-6.0 תצטרך להתרגל להשתמש ב-VCSA במקום ה-vCenter שהיה רץ על Windows).

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

אחת הבעיות הגדולות בגרפיקה עם וירטואליזציה – היא המהירות של הגרפיקה. היא פשוט א-י-ט-י-ת. אינטל הוציאה את תמיכת ה-VT-D שמאפשרת לך (תאורתית) למפות כרטיס PCi-E (כמו כרטיס מסך) למערכת הפעלה אורחת. לצערי, התמיכה של אינטל בתוספת הזו היא כמו הליכה בשדה מוקשים: יכול להיות שהמעבד החדש שלך תומך בכך, אבל אתה צריך לבדוק שגם ה-Chipset בלוח האם שלך תומך ושגם ה-UEFI/BIOS בלוח האם שלך תומך, אחרת לא תוכל להשתמש ב-VT-D.

אז נניח שעברת את החלק הזה בשלום והחלטת שאתה רוצה להשתמש בפונקציה הזו. אם תחליט להשתמש ב-VMWare Workstation האחרון לדוגמא (גירסה 11), תמצא שאין פונקציונאליות כזו. את זה VMWare מאפשרת רק ב-ESXI. אז תתקין ESXI על המחשב שלך ותעבוד מ-VM, לא משהו מסובך, נכון?

אז זהו, שגם אם תעשה את השמיניות באוויר הללו, אתה תמצא שאתה לא יכול למפות כרטיס GTX מבוסס nVidia אלא רק כרטיסי Quadro יוקרתיים (יש אפשרות "להמיר" כרטיסים ישנים יותר שיהיו Quadro אבל זה לא לבעלי לב חלש, בחלק מהמקרים תצטרך להלחים..). עם כרטיסי Radeon יהיה לך יותר מזל אבל גם לכך תצטרך לשחק עם כל מיני הגדרות (כמו למפות את הזכרון שהמכונה תיקח כזכרון שלא ניתן למיפוי ל-VM אחר, אחרת הכל יתקע, מנסיון…), אבל תוכל לעשות משהו, שכמובן לא נתמך ע"י אף אחד.

ל-nVidia יש פתרונות – שתקנה כרטיס יקר או שתקנה פתרון יותר יקר, כמו כרטיסי ה-GRID שלהם (כולה כמה אלפי דולרים..). יש גם פתרונות "באמצע" כמו Horizon של VMWare, אך עדיין – כל הפתרונות הנ"ל יקרים ולא תמיד מתאימים.

לתוך הבעיה הזו אינטל נכנסה לאחרונה, עם גישה מאוד מעניינת: עד היום, הפתרונות שיש נתנו לך להריץ רק מכונה וירטואלית אחת עם האצה גרפית אמיתית (במקרה של Hyper-V אפשר מספר מכונות עם RemoteFX אך התמיכה הזו מאוד מוגבלת ולא כוללת דברים כמו OpenGL כך ששום אפליקציה רצינית לא תרוץ בצורה מואצת). מדוע שלא נבנה מחדש את כל רעיון ה-vGPU כך שכל מכונה וירטואלית תוכל לגשת למעבד הגרפי (של אינטל, לא מעבדים גרפיים אחרים) ותקבל ביצועים מעולים? אז 3 מהנדסים באינטל עובדים על כך והפרויקט נקרא KVMGT. תוכלו לראות מצגת (PDF) על כך כאן.

העבודה עדיין בעיצומה אולם לפני ימים ספורים אינטל שחררה מעין "אב טיפוס" (מצריך קימפול) שיכול לרוץ על וירטואליזציית KVM. הביצועים – מאוד מרשימים:

graph

אינטל כמובן לוקחת את הצד הניטרלי והשינויים יכנסו גם ל-QEMU, גם ל-XEN וגם ל-KVM. זה עדיין כמובן לא אומר שתוכל לרנדר פוטשופ עם כמה מאות שכבות בשניות, וכמובן זה לא ממש יתאים להריץ את המשחקים האחרונים שחונקים את המעבד הגרפי עד שהוא מתחנן לטישו, אבל זהו צעד ענק שאין ספק שיאומץ על ידי פתרונות וירטואליזציה אחרים כמו VirtualBox ואולי גם ע"י VMWare ומיקרוסופט (מי יודע..). בשלב זה המתחרים (AMD ו-nVidia) לא מציגים פתרונות מתחרים, אולם אני מאמין שלחץ מהמשתמשים יגרום להם לחשוב מחדש לגבי פיתוח פתרונות שיאומצו ע"י יצרני פתרונות הוירטואליזציה השונים.

אגב, למי שמחפש לדעת מה קורה עם VMWare בכל הקשור להאצה, אז אפשר לקבל רמז מגירסת VMWare Workstation 11., בגירסה זו התווספה האפשרות להגדיל את הזכרון הגרפי עד 2 ג'יגה (ע"ח ה-RAM שלך, לא על חשבון ה-RAM בכרטיס הגרפי שלך). מנסיון פשוט שביצעתי, זה משפר בטיפה, לא הרבה.

עוד עדכונים – בקרוב.