המעבר ל-DPU

Print Friendly, PDF & Email

(הערת Off topic: פוסט זה ופוסטים בעתיד יכתבו בלשון נקבה. מדוע? הפרטים נמצאים כאן)

עולם הוירטואליזציה קיים כבר יותר מ-20 שנה, והפתרונות עברו מספר "סבבים" של שינויים מהותיים בפתרונות, להלן פירוט (ברשותכם, אינני מתכוונת להיכנס לפרטים של רמת Hypervisor וכו' שגם הם השתנו, אך הדבר אינו רלוונטי לפוסט זה):

  • סיבוב ראשון – פתרונות כמו ESX/ESXI ופתרונות וירטואליזציה של מתחרים התמקדו בכך שישנם חלקים פיזיים שונים שמרכיבים את פתרון הוירטואליזציה: יש פתרון אחסון יעודי, יש מתגים ונתבים, יש חומת אש יעודית ועוד מספר "ברזלים" שנותנים שרותים משלימים – ויש את כל שרותי ה-Compute שמתקבלים מהשרתים. כל דבר – בנפרד.
  • סיבוב שני – קונסולידציה – פתרונות כמו vSAN של VMware ופתרונות מתחרים – מעבירים את השרותים המשלימים ל-Compute – אל תוך ה-Nodes עצמם. אחסון? הכנס דיסקים ונקים. רשת? יש NSX ופתרונות אחרים שייתרו פתרונות "ברזלים" יעודיים לטובת פתרון וירטואלי, כך שבסופו של יום, מערכת כזו תהיה בנויה משרתים עם דיסקים, כרטיסי רשת ומספר מתגים פשוטים ותו לא. הכל מוקם, מוגדר ומתוחזק בתוך פתרון הוירטואליזציה.

הסיבוב הנוסף הוא בעצם "חצי סיבוב". השינוי העיקרי הפעם הוא שאנחנו מוציאים החוצה מעבודת המעבד כל מה שקשור לאבטחה, תעבורת רשת, אחסון, הצפנה וכו' – ואנחנו מעבירים את הכל לדבר שנקרא SmartNIC (או כפי ש-NVIDIA ו-AMD ואחרים רוצים שתקראו לזה: DPU. אינטל רוצים שתקראו לזה: IPU).

להלן תרשים שיפשט את הדברים:

(קרדיט: The Next Platform)

כפי שאנו רואים, ה-DPU (מצד שמאל למטה בתרשים לעיל) הוא זה שיריץ את שרותי ה-ESXI וכל שרותי ה-Management (לשם כך ה-DPU מכיל מעבד ARM עם מספר ליבות וזכרון) והשרת עצמו יריץ מערכת מינימלית שמכילה Hypervisor או כל מערכת הפעלה יעודית "על הברזל" – והמערכת תתממשק  אל ה-DPU, כך שה-DPU בעצם ינהל את השרת והשרותים.

מדוע בעצם עושים זאת? הסיבה לכך די פשוטה: אין זה משנה איזה מעבד X86-64 קיים לך בשרת, בין אם מדובר ב-Xeon של אינטל או ב-EPYC של AMD, המעבדים הללו טובים בדברים מסויימים כמו Compute, אך פחות טובים בכל מה שקשור לתקשורת, הצפנות, תעבורת רשת גבוהה, אחסון ברמה ובביצועים של SAN וכו', ודברים אלו יכולים להתבצע ביעילות עם שבבים יעודיים (ASIC או FPGA, תלוי ביצרן, בפתרון וכו') ולשם גם VMWare וגם היצרניות האחרות (חוץ מ-AMD, אינטל ו-NVIDIA, גם חברות אחרות מתכוונות להציע DPU משלהן, כמו Marvell, ברודקום וכו') רוצות להיכנס, ובמילים אחרות – מה שהיה פרויקט Project Monterey בעבר, עכשיו זה חלק אינטגרלי מ-vSphere 8 שיוצא.

מאיפה בעצם הגיע הרעיון לכך? התשובה די פשוטה: ספקי ענן ציבורי, ובמיוחד AWS. רוב השרתים ב-AWS (הסתכלו לדוגמא על AWS Nitro) כוללים בעצם מערכת שמכילה KVM לינוקסי מינימלי שמריץ רק מכונות וירטואליות, וכל שאר השרותים מתקבלים דרך כרטיסי PCIe Express בעלי שבבים יעודיים (דוגמת Pensando של AMD) שנותנים שרותים יעודיים כמו אחסון, תקשורת, הצפנה ושרותים נוספים לפי הצורך, כך שבעצם המעבדים בשרת לא מריצים כמעט מאומה – זולת ה-Compute של הלקוחות וה-Hypervisor המינימלי. בשיטה זו רמת האבטחה היא הרבה יותר גבוהה, וגם אם מאן דהוא יצליח לפרוץ לשרת, אין שרות אחסון שרץ מקומית בשרת שניתן להתחבר אליו ולגנוב ממנו מידע (כל התחברות בין VM לאחסון  דרך הכרטיס היעודי מבוססת הצפנה עם מפתח יעודי פר VM ויש עוד מספר אלמנטים לאבטחה).

יש גם נקודת לינוקס בכל העניין: מכיוון ש-DPU מכיל במקרים רבים מעבדי ARM עם אחסון וזכרון עצמאיים נפרדים מהשרת, אפשר לתכנת אותם, ו-Linux Foundation, יחד עם יצרני חומרה נוספים הקימו פרויקט שנקרא Open Programmable Infrastracture Project (ובקיצור – OPI) כדי לעודד חברות תוכנה לכתוב אפליקציות ודברים נוספים עבור אותם DPU.

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

… שלא מתאים לכולם.

למען האמת – אפילו לא לרוב אלו שיש להם מספר קטן עד בינוני של שרתי ESXI.

אני חושבת שיש צורך לספר משהו אחד פשוט לגבי אותם IPU/DPU שהולכים להיות מוצעים: כל הפתרונות הללו נבנו בראש ובראשונה עבור ספקי ענן ציבורי (אז'ור, AWS, GCP, אני בספק אם אורקל משתמשת בכך), ואותן יצרניות החלו להוסיף ולשנות את הפתרונות כך שיוכלו לעבוד עם Project Monterey, כך שבסופו של יום – מדובר על פתרון שהוא מאוד חדש, ואינני בטוחה אם אפשר לקרוא לו "יציב", ובכל מקרה – מחירי כרטיסים כאלו – גבוהים מאוד, ויש צורך גם במתגים עם תמיכה במהירויות גבוהות (25 או 50 ג'יגהביט כמינימום!) – כך שגם אלו שרוצים פתרונות DPU כאלו, לא בטוח שזה יתאים להם.

לסיכום: DPU הוא פתרון מעולה, כאשר יש לארגון עשרות רבות, מאות או אלפי שרתי ESXi. לשאר הארגונים, מעבדי X86-64 כמו Xeon או EPYC – יתנו עבודה כלל לא רעה, ובמיוחד במעבדים העתידיים של שתי החברות ששואפות להכניס רכיבי האצה שונים לתוך מעבדיהן – ואת התוצאות לכך נוכל לראות בחודשים הקרובים.

תגובה אחת בנושא “המעבר ל-DPU”

  1. סיכום יפה של הטכנולוגיה.
    רק דבר אחד… היתרון שבעבודה עם כרטיסי רשת רשת כאלה, שגם תומכים ב rdma, כזאת הוא שהיא מאפשרת גישה לnvme מרוחק, ללא שימוש במעבד של השרת המרוחק. הועיל והגדלת נפח הstorage ב san server גורמת למעבד בצד האיחסון להיות צוואר בקבוק. למעשה המערכת בצד השרת ממפה ישירות את זיכרון ה nvme לזכרון כרטיס הרשת וזה מאפשר גישה מרוחקת לnvme ללא שימוש במעבד בצד האיחסון. Scale out solution
    ראי, למשל הפתרון של אקסלרו שנקנו לאחרונה על ידי nvidia
    https://www.excelero.com/what-is-nvmesh/

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

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