על בחירת מחשב תעשייתי/מוקשח

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

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

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

ברכבים לדוגמא, כשהחלק יושב בסביבת המנוע, פתרון קירור רציני הוא חובה. קחו לדוגמא את הלוח של nVidia Drive PX2. רואים את 4 המעבדים? תנסו להפעיל את המערכת ללא איוורור ותראו את המערכת נכבית תוך שניות ספורות. במקרה של הלוח הזה, הפתרון קירור יחד עם הלוח נראה כך (התמונה עם לוח מהגירסה הקודמת):

  • סוג מעבד: במקרים של מחשבים תעשייתיים, את סוג המעבד יש לקבוע בהתאם לעבודה שאותו מחשב אמור לבצע. אין שום סיבה לרכוש i7 אם המחשב מבצע עבודה שמעבד עם ביצועים נמוכים יותר יוכל לעשות מבלי לפגוע בביצועים. בניגוד לדסקטופ, כאן בהחלט מומלץ גם לשקול מעבדים מבוססי ARM, מעבדי ATOM של אינטל, או EPYC Embedded של AMD.
  • חיבור ציוד עם USB: חיבור ציודים עם USB הוא בעייתי. בניגוד לחיבורים כמו VGA או DVI או Display Port שכוללים ברגים או מנגנון לנעילת החיבור, USB הוא לא החיבור הכי יציב, ולכן אם חייבים לחבר ציוד בעזרת USB, יש צורך לדאוג לפתרון בולם זעזועים מחוץ למחשב. ללא פתרון לזעזועים, המערכת תדווח בזמן עבודה על חיבור/ניתוק ציודים באופן תכוף.
  • אמצעי אחסון: לא מומלץ להשתמש בדיסקים מכניים. הדיסקים המכניים כוללים בתוכם בולם זעזועים, אבל אם הפתרון מצריך נסיעות בדרכים או עמידה בתנאים קיצוניים הכוללים תנועה, פתרון הבולם זעזועים הפנימי לא תמיד יפעל טוב (הבולם זעזועים מתאים למקרים של נפילה פיזית פתאומית אחת לזמן רב, לא כל מספר דקות). בעבר ההמלצה היתה להשתמש ב-SATADOM (שהוא בעצם Flash Disk שנכנס ישירות לתוך חיבור SATA ומצריך חיבור חשמל על לוח האם), אולם כיום מומלץ להשתמש ב-SSD בחיבור M.2 הכולל 2 ברגים לחיזוק החיבור. M.2 הרבה יותר אמין ועומד בכבוד גם בזעזועים על טרקטורים.
  • שימוש בכרטיסי PCIe: אין בעיה להכניס כרטיסי PCIe (יש מעט דגמים של מחשבים תעשייתיים המאפשרים הכנסת כרטיסי PCIe) בפתרונות הללו, אולם מומלץ אם אפשר – לחפש כרטיסי Mini PCIe עם אותה פונקציונאליות. כמו ב-M.2, הפתרון מוברג ומוחזק בצורה יותר טובה.
  • שימוש במאווררים: רוב המחשבים התעשייתיים הם מחשבים שקטים, ודרישת השקט מגיעה במקרים רבים מהלקוחות וכך יצרני אותם מחשבים עושים הכל על מנת שהמחשב יהיה שקט. יחד עם זאת, יש לעיתים צורך (בהתאם לתצורה) להחליף את המאווררים הכלולים במאווררים אחרים. הדבר האחרון שמומלץ הוא להשתמש במאווררים רגילים שעולים 30 שקל. יש צורך לבדוק את כמות ה-RPM וה-CFM ואז לרכוש את המאווררים המתאימים או לבקש מהיצרן מאווררים אחרים או המלצות על מאווררים אחרים. מאווררים שאינם תואמים עלולים לגרום לנזק למחשב.

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

התקציב השנתי ורכישת ציוד

יש חברות שכבר הספיקו לתכנן את תקציב ה-IT לשנה הקרובה, יש כאלו שעדיין יושבים על המספרים. כמובן שאצל כל חברה הדברים שונים, יהיו כאלו שירצו בשנה הקרובה להחליף שרתים, להחליף סטורג', אולי לרכוש PC חדשים, לשדרג ל-SSD, לעבור לתקשורת פנימית יותר מהירה (10/40/50/100 ג'יגהביט), וכמובן שיש את כל עניין הפלטפורמות: לעבור לקונטיינרים, הטמעת CI/CD, להתחיל לעבוד בתצורת AGILE, לשכור אנשים/חברות ללמד את העובדים טכנולוגיות חדשות וכו'.

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

נתחיל בסטורג' SDS.

את עולם הסטורג' לקצה התחתון עד הבינוני ניתן לחלק ל-2: סטורג' קנייני (כזה שמגיע עם "ראש", מדפים), וסטורג' מבוסס תוכנה (SDS – כלומר Software Defined Storage). אם תשאלו את אנשי השיווק של הסטורג' הקנייני, תקבלו הילולים מכאן עד הודעה חדשה כמה הוא יציב, וכמה "לא כדאי" לרכוש SDS. המצב במציאות – די הפוך. בואו נאמר שאתם הולכים להוציא $50,000 על פתרון סטורג' ואתם מבקשים מכל העולם והחתול שלו הצעות מחיר לסטורג'. רוב ההצעות שתקבלו – הם SDS, גם אם הם לא יקראו כך בכותרת.

באופן עקרוני, סטורג' SDS מבוסס בעצם על חלקים COTS (כלומר Common Off The Shelf), כלומר שרת SDS אינו שונה מהותית מכל שרת שיש לכם בחדר/חוות שרתים שלכם. יש בו זכרון, מעבדים, בקר דיסקים, דיסקים קשיחים, וכרטיסי רשת. 2 הדברים ששונים בין סטורג' SDS לשרת רגיל הם בקר דיסקים (בחלק מהמקרים יש SAS Expander ו/או בקר RAID יותר יוקרתי הכולל תמיכה ל-SSD Caching) וכרטיסי רשת לחיבור מהיר (10/40/50 ג'יגה). הדבר העיקרי שהופך את השרת ל-סטורג', זו בעצם התוכנה שרצה עליו.

אחת השאלות הראשונות שאני נשאל לגבי פתרונות כאלו זה "האם יש תמיכה מהיצרן שרתים"? והתשובה בדרך כלל היא "כן", כלומר אם תבקשו מ-HP או DELL או LENOVO פתרון תוכנה של סטורג', הם ישמחו למכור לכם את התוכנה, עם או בלי שרת שלהם. היתרון הגדול בשיטה זו הוא שאם ציוד כלשהו בשרת נדפק, אתה נמצא תחת אחריות מלאה וטכנאי יגיע אליך תוך 4 שעות או ביום העסקים הבא (בהתאם לחוזה שרות שחתמת), ואם יש לך שאלות או תקלות עם תוכנת הסטורג', תוכל לקבל תמיכה מהיצרן שרתים או מיצרן התוכנה, כך שאתה מכוסה מכל צד. אפשר להשוות זאת לרכישת ברזלים + רשיונות של vSphere – אני לא מכיר מקרים שלקוח נשאר ללא מענה לתקלות אם הוא תחת אחריות של יצרן השרת והתוכנה.

מבחינת ביצועים – אחת השאלות שאני תמיד מקבל מצד כל מיני חברות שמתעניינות בסטורג' זה משהו בסגנון "אני צריך פתרון סטורג' עם X טרהבייט ועם כמות Y של IOPS רציפים". עם SDS אין בכלל את העניין הזה. רוצה X טרהבייט? תכניס כך וכך דיסקים ואם נגמר המקום, חבר JBOD בחיבור SAS-HD2. רוצה IOPS? תגדיל כמות זכרון ותוודא שיש לך SSD מהירים כמו P4800X או 905P של אינטל או Z-SSD של סמסונג (זה במקרה הקיצוני שצריכים IOPS גבוה בכל מחיר) או כל SSD שהוא Mixed והוא נמכר לך ע"י יצרן השרתים שלך. סמסונג, אינטל, מיקרון, טושיבה – כולם מייצרים כאלו.

שרידות – אחת הבעיות הקשורות במחיר – היא שרידות High Availability בסטורג' קנייני, כלומר כשצריכים "2 ראשים" לקבל שרידות. המחיר של ראש שני – יקר מאוד! לעומת זאת, בסטורג' SDS, מדובר בעצם על עוד שרת, רכישת JBOD לדיסקים וחיבור ה-JBOD ל-2 השרתים והפעלת פונקציית HA בתוכנת הסטורג'.

מה עם ביצועי רשת ב-SDS? שרת חזק יחיד עם כרטיסי רשת במהירות גבוהה, יתן ביצועים גבוהים ומענה לחיבור כל התשתית שצריך. מנסיון אישי על שרתים שהקמתי, הגעתי ל-250 ג'יגהביט תוך חיבור 150 שרתים, חלקם ב-NFS, חלקם ב-iSCSI וחלקם ב-CIFS (הייתי יכול להגיע ליותר אם היתה לי מכונה יותר חזקה ויותר כרטיסי רשת), כך שפתרון SDS יכול לעמוד בעומסים בלי שום בעיה.

מחירים ו"חופש": כשרוכשים סטורג' קנייני, אתה בעצם רוכש ברזל עם כמות X של דיסקים וכמות Y של פונקציונאליות. רוצה עוד פונקציונאליות? תשלם. רוצה להכניס דיסקים אחרים? ברוב המקרים יאמרו לך ש"אי אפשר". ב-SDS לעומת זאת, אתה יכול להתחיל היום עם דיסקים של 4 טרהבייט (נניח) ולעבור מחר ל-10 טרהבייט, ובד"כ הרשיון של התוכנה כולל את כל האפשרויות במחיר, רק שהמחיר משתנה לפי כמות האחסון בפתרון (אם כי יש תוכנות שכמות האחסון לא משנה את מחיר הרשיון), כך שעם SDS יש לך יותר חופש להחליט איך להשתדרג ומה לשדרג – אתה מזמין מיצרן השרתים את החומרה שאתה צריך, מרכיבים את החומרה, מפעילים את המכונה וממשיכים לעבוד.

לסיכום: פתרון סטורג' SDS נותן לך הרבה יותר ואתה עדיין מקבל תמיכה מיצרן החומרה שאתה רוכש ממנו את הברזלים – אם זו נקודה קריטית עבורך. אפשר כמובן להקים מערכות כמו FreeNAS או ZFS על לינוקס (או על אחת מגרסאות הקוד פתוח של Solaris) אם אתה לא מעוניין לשלם על התוכנה ואתה מעדיף לסגור עם אינטגרטור חיצוני שיעשה את העבודה ויתן לך את התמיכה הרצויה. סטורג' קנייני בדרך כלל יעלה לך הרבה יותר בהשוואה לרכישת שרת כלשהו שיארח את פתרון האחסון ואתה תמיד יכול לגדול עם פתרון הסטורג' בהתאם לצרכים שלך מבלי לשלם סכומי עתק על כל שדרוג בהשוואה לסטורג' קנייני.

עוד על SDS כתבתי כאן וכאן.

אחסון נתונים – לאן אנחנו מתקדמים?

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

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

נפתח בכותרת ראשית: מלחמה. יצרני פתרונות SSD כמו אינטל, טושיבה, סמסונג, מיקרון ואחרים מתחילים להוציא דיסקים SSD מבוססי QLC NAND Flash (כלומר בכל תא ניתן יהיה לאחסן 4 בייטים של מידע) בכדי להתחרות ביצרני הדיסקים הקשיחים המכניים. היתרונות של SSD QLC על פני דיסקים מכניים:

  • ניתן יהיה לרכוש SSD בגדלים של עד 32 טרהבייט (פר דיסק) – בהשוואה לעד 14 טרהבייט דיסק מכני.
  • מהירות הכתיבה תהיה יותר מהירה ממהירות הכתיבה לדיסק מכני, אם כי לא בהבדל כה משמעותי כמו SSD MLC – זה יהיה בסביבות ה-800-1000 מגהבייט לשניה. מהירות הקריאה לעומת זאת תהיה בערך כמו SSD MLC – בערך 2 ג'יגהבייט לשניה.
  • טיפול בשגיאות יהיה הרבה יותר חכם בהשוואה לדיסקים קשיחים מכניים – והטיפול יהיה פנימי (עם Garbage Collection ו-TRIM).
  • הקץ לחיבורי SATA ו-SAS2/SAS3 – כל החברות מעוניינות להעיף זאת (אוקיי, חוץ מטושיבה) לטובת NVME.

הדיסקים הללו יצאו במהלך השנה הקרובה. שימו לב: במקרים מסויימים, גם אם יש לכם תמיכת NVME בשרת, לא בטוח שדיסקים כאלו יהיה ניתן להכניס אותם הואיל והעובי שלהם הוא 15 מ"מ (בניגוד לרוב הדיסקים SSD שהם בין 5 ל-7 מ"מ).

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

מ-QLC נעבור לטכנולוגיה שאינטל כה גאה בה – ה-3D Xpoint. טכנולוגיה זו, למי שאינו מכיר – היא טכנולוגיית אכסון על שבבים, אך לא מדובר ב-NAND Flash אלא על פתרון קנייני של אינטל ומיקרון. SSD בטכנולוגיות כאלו יחזיק הרבה יותר זמן, מהירות הכתיבה והקריאה שלו שווה פחות או יותר למתחרים, אולם הטכנולוגיה "עוקפת" את המתחרים בכל מה שקשור ל-Latency או בשימוש בחלק מה-SSD כ-SWAP והוא מאוד מתאים לדברים כמו SQL אם אנחנו מעוניינים להצמיד SSD כזה למכונת VM (או להריץ על "הברזל").

למרות שאינטל מהללת את הטכנולוגיה – ברוב המקרים אצל רוב החברות, לא יהיה לה ממש שימוש, הואיל ושימוש ב-SSD כזה על פתרון וירטואליזציה כמו vSphere לא יתן יתרון גדול על מתחרים אחרים כמו סמסונג, מיקרון ואחרים (ב-SSD ל-Enterprise). בנוסף, אינטל מייצרת אותם בגודל די קטן: 280, 375, ו-750 ג'יגהבייט (שוב, בגרסאות Enterprise) במחיר הרבה יותר גבוה מהמתחרים, כך שאם רוצים להשתמש ב-SSD כאלו – מומלץ לחשוב ולקחת יעוץ. מצד שני, אם אתם בונים פתרון NAS, דגם 905P לדוגמא יכול לתת פתרון Cache הרבה יותר טוב מאחרים (שימו לב, שבשביל להשתמש ב-SSD כזה, צריך מכונה די חדשה, מהשנתיים האחרונות).

טכנולוגיה נוספת שתעניין חברות שמשתמשות ב-SQL ושצריכים ביצועי Read רצחניים, היא טכנולוגיית ה-Z-SSD של סמסונג. ה-Z-SSD עוקף בביצועים את ה-3D Xpoint של אינטל, אבל הוא הרבה יותר איטי בכתיבה.

מכאן נעבור לפתרונות אחסון קנייניים. ברוב המקרים בקצה הנמוך עד בינוני (תקציב של 5-6 ספרות בדולרים) הטכנולוגיות הם פחות או יותר אותן טכנולוגיות, רק שכל חברה נותנת שמות אחרים (די מזכיר מה שקורה בתחום השרתים) ואחת השגיאות שרבים נופלים אליה – היא המושג "AFA" (או All Flash Array). אפשר להשוות את זה למושג שיגיע מאיש שיווק של רכבים – "מכונית מפוארת". זה שפתרון Storage הוא All Flash יכול להטעות, בגלל שכל SSD יש לו מגבלות – בכמות כתיבה רנדומלית או Sequencial, חלקם הוא Mixed Intense אבל ברוב המקרים בהצעה הראשונה שתקבל ה-SSD הוא Read Intense, מה שיאיט את הביצועים בצורה ניכרת בעבודות דיסק כבדות.

בשנה הקרובה יהיו יותר ויותר הצעות AFA שמבוססים על דיסקים SSD TLC (ולא MLC שהוא הרבה יותר מהיר. ה-TLC יושב "באמצע" בין ה-MLC ל-QLC) ושיהיו Read Intense. בהצעות היותר גבוהות, סביר להניח שנראה לקראת סוף שנה הבאה פתרונות Storage גדולים יותר מבוססי SSD QLC – כאשר חלק מה-SSD יהיו TLC כדי "להחביא" ביצועי כתיבה איטיים. אלו שרוצים להקים פתרונות VDI גדולים – פתרונות Storage כאלו יאיטו ביצועים במקרים מסויימים (במיוחד אם מרימים כל דסקטופ כ-VM ולא כ-Session RDP לדוגמא).

עוד תחום שיקבל תאוצה בשנה הקרובה הוא ה-NVMEoF שעליו כתבתי בעבר. הפתרונות הללו יקרים (7 ספרות בדולרים) והם הרבה יותר מורכבים מפתרונות Storage קודמים. תחום נוסף שיקבל דחיפה ויכול לעניין את אלו שמחפשים פתרון Storage עם Scale Out – הם פתרונות קנייניים של Scale Out מ-EMC, NetApp, ואחרים אך לעניות דעתי אין להם הצדקת רכישה – יש מספר פתרונות Scale Out Storage שיכולים לרוץ על ה-Nodes עצמם מבלי לרכוש עוד Storage.

עוד פתרונות מעניינים שיגיעו לשוק (אבל אני מאמין שלא יכנסו לשוק הישראלי האולטרא-שמרן) הם פתרונות JBOF – מכונות שמזכירות JBOD אך עם SSD במקום דיסקים מכניים, שמחברים כל מכונה למספר שרתים עם כרטיס HBA וב-JBOF מגדירים כמות דיסקים שיוקצו פר שרת. יש גם פתרונות של מכונות שיכולות לקבל 45-60 דיסקים מכניים בגודל 3.5 אינטש וכוללות מעבד, זכרון וכו' ויכולות לשמש כפתרון Storage (אולם יש צורך בשדרוג תשתית הרשת ל-40-50 ג'יגהביט).

מצד הדיסקים המכניים אנחנו נראה בשנה הבאה דיסקים שעובדים עם מנועים כפולים (ומהירות גישה כפולה – בסביבות ה-450 מגהבייט לשניה) בחיבורי NVME והיצרניות כבר יציעו דיסקים שמגיעים לגדלים של עד 20 טרהבייט. יהיה מעניין לראות את התחרות מבחינת מחירים – בהשוואה ל-SSD QLC.

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

על PLX, שרתים מיוחדים ומחשבים תעשייתיים

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

כיום יש בחלק קטן מהמקרים דרישות לשרתים שונים. אחד הפופולריים לדוגמא הוא שרת שיכול לקבל כמה שיותר GPU לצרכי Deep Learning או AI. ברוב השרתים מהיצרנים הידועים ניתן להכניס בין 1 ל-4 כרטיסי GPU. מדוע זה נעצר ב-4 GPU? הרי תמיד אפשר לבנות שרת בגודל 3U ולדחוף בו עד 8 GPU בקלות (ואם מתאמצים – ויש כמה דגמים כאלו בשוק – גם 10 GPU). הסיבה לכך (לדעתי) היא המחשבה של רוב היצרנים שאם אתה רוצה לדחוף 8 כרטיסי GPU – עדיף שתקנה 2 שרתים שבכל אחד מהם יהיה 4 כרטיסי GPU. השיטה הזו עובדת מעולה על רוב החברות, אבל ממש לא עובדת על חברות ענן.

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

תכירו את השרת הבא: 3U8G-C612 מחברת Asrock Rack (לחצו להגדלה):

כפי שאתם יכולים לראות, השרת נראה מעט .. מוזר. לא רואים את ספקי הכח (הם נמצאים מתחת ללוח האם, יש 4 ספקי כח אימתניים), והמאווררים נמצאים באמצע, לא בחלק השמאלי כמו רוב השרתים. כמו שאנחנו רואים, יש לנו 8 כרטיסי GPU.

מי שיציץ במפרט הכללי של מעבדי Xeon SP, יגלה שיש לנו בכל מעבד עד 48 נתיבי PCIe, כלומר יש לנו סה"כ (ברוטו) 96 נתיבים. לעומת זאת יש לנו 8 כרטיסי GPU שכל אחד מהם משתמש ב-16 נתיבי PCIe. חישוב פשוט של 8 כפול 16 שווה 128, אבל אין לנו 128 נתיבים, שלא לדבר על כך שכל פיפס דורש מס' נתיבי PCIe: ה-Chipset דורש 4, כרטיס רשת 10 ג'יגה דורש בממוצע 8, בקר ה-RAID דורש גם 8, ויש עוד כמה ציודים שגם הם דורשים מס' נתיבי PCIe.

אז איך ניתן לכולם וגם נספק 128 נתיבי PCIe לכל הכרטיסים?

לשם כך ישנה טכנולוגיה שנקראת PCIe Switching או כפי שהיא יותר מוכרת בתעשיה: PLX.

מה שה-PLX עושה בעצם, הוא יוצר מעין "מתג" בין מספר תושבות PCIe, ובכל פעם הוא מעביר למערכת מידע מכרטיס אחר. כך לדוגמא ישנם דגמים שיודעים לעשות סימולציה של 2 או 4 תושבות PCIe X16 ואותו PLX ממתג בין ארבעתם ומעביר את כל הנתונים הלוך וחזור בין המעבד לכרטיסים, כל זאת בשעה שהמערכת עצמה מודעת לכך שיש 4 כרטיסים (נניח) אבל המעבד מקבל כל פעם נתונים מכרטיס אחד. לשיטה הזו יש יתרון עצום בכך שאפשר להכניס הרבה יותר ציוד במחשב, אם כי המחיר שלה היא איבד מועט של מהירות (בסביבות ה-50-80 ננושניות).

שיטת ה-PCI Switching גם עובדת חיצונית. נניח ויש לנו מערכת vSphere עם מספר שרתים ואנחנו צריכים לתת למספר מכונות VM כרטיס GPU יעודי. אם נתקין GPU בשרת פיזי שמריץ vSphere לא תהיה לנו אפשרות לעשות Migration של המכונה לשרת אחר או Fault Tolerance. עם PLX לעומת זאת, אנחנו יכולים להקים מכונה כמו בתמונה לעיל, ולמפות בעזרת ציוד PCI Switching (שיושב "באמצע" בין השרת לשרתי ה-vSphere – כולל כבלים כמו SAS HD בין הציודים לשרתים) כרטיס ספציפי ל-VM ואנחנו יכולים להעביר ב-Live את הציוד בין מכונות ה-VM. (אגב, לאלו שחושבים לאמץ את הטכנולוגיה – היא יקרה, מאוד!)

כך, בקרוב, השרתים החדשים מבית DELL, Cisco ו-HPE יאפשרו ללקוחות להכניס בכל תושבות הדיסקים – SSD NVME. כל NVME דורש 4 נתיבי PCIe כך שאם אנחנו יכולים להכניס 24 דיסקים SSD NVME, נצטרך 96 נתיבים שאותם ב"טבעי" אין לנו ולכן ב-Backplane של השרת יהיו 2 שבבי PLX שישתמשו ב-32 נתיבי PCIe ואת זה אין שום בעיה ל-PCIe לתת. אגב, אינטל מאפשרת עד 96 נתיבי PCIe ו-AMD נותנת .. 128 נתיבים. יום אחד אולי אצליח להבין מדוע אינטל כה "חוסכת" נתיבי PCIe… אגב: שרתים מבית SuperMicro, Tyan, ASRock Rack כוללים כבר פתרון כזה מזה שנתיים וחצי…

משרתים נעבור למחשבים תעשיתיים. אלו מחשבים שאמורים לעמוד בתנאים קיצוניים של רעידות, חום קיצוני (עד 60 מעלות בזמן עבודה). בחלק מהמקרים המחשב, כשפותחים אותו, נראה כמו PC רגיל, ובחלק מהמקרים המחשב מורכב מלוח אם שהוא כמעט ריק ויש בו תושבת אחת ארוכה ועוד תושבות PCIe X16 ו-PCIe X8. המחשב עצמו יושב ב-90 מעלות אנכית בתושבת הארוכה (שמזכירה תושבת Riser בשרתים) והציודים מתחברים לאותו לוח אם. אחת הטעויות הנפוצות שיבואנים לא מודעים (וחלק מחברות האינטגרציה לא מודעות) היא שפתרון שאינו כולל PLX הוא מוגבל. ברוב המקרים במחשבים תעשייתיים יש מעבד i5 או i7 או Xeon E3 מכילים כמות קטנה של נתיבי PCIe! כך לדוגמא אם מכניסים GPU אז הוא משתמש ב-16 נתיבים ומעבד כמו Xeon E3-1585 v5 מגיע עם .. 16 נתיבים בלבד. אם לא מכניסים GPU, אז אנחנו יכולים להכניס 2 כרטיסים שמשתמשים כל אחד מהם ב-8 נתיבים או כרטיס של 8 נתיבים וכרטיס של 4 נתיבי PCIe, כך שאם בונים מחשב תעשייתי עם ציוד רב שצריך להתחבר אליו (GPU, בקרים – לא ב-RS232, חיבורי USB, חיבורים קנייניים וכו') אז חובה לחפש פתרון שכולל PCIe Switching.

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

קונטיינרים – הפתרונות שקיימים ומה כדאי לבדוק

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

(הערה: מכיוון שמערכות כמו OpenShift, IBM Private Cloud, CAAS, Rancher ועוד מבוססים על Kubernetes ועל זה הם הוסיפו דברים אחרים, אתייחס בפוסט זה ל-Kubernetes או בשמו המקוצר הידוע – K8S).

אחד הדברים הראשונים שמנמר"ים ואנשי IT רבים עדיין לא מבינים, זה את הבסיס, שקונטיינרים אינם מכונות וירטואליות. קונטיינר שקם משתמש ב-Images והוא לא מיועד לאחסן נתונים באופן פרמננטי כמו במכונה וירטואלית, לשם אחסון נתונים יש Volumes שעליהם אתייחס בפוסט זה בהמשך. בקונטיינר אין מערכת הפעלה מלאה, אלא מה שהותקן בעת הקמת ה-Image וברוב מוחלט של המקרים מדובר במשהו מזערי שאמור לספק את דרישות האפליקציה שתרוץ בקונטיינר. בנוסף, קונטיינר מאובטח לא אמור להריץ שרותים כמשתמש root אלא כמשתמש רגיל (ללא הרשאות root/sudo) ולבסוף – קונטיינרים לא אמורים להריץ מספר אפליקציות, אלא אפליקציה אחת בכל קונטיינר/POD ו"לדבר" עם POD/קונטיינרים נוספים שמריצים אפליקציות אחרות, בשביל זה יש לנו TCP/IP ובשביל זה יש שרות DNS פנימי שרץ על K8S שיודע לתקשר בין החלקים והשרותים השונים.

הדבר השני שחשוב להבין בקונטיינרים, זה שזו מערכת מאוד דינמית. לא מומלץ לנסות לקבוע למערכת על איזה שרת לרוץ, מערכת K8S יודעת לבד באיזה שרת להקים את הקונטיינרים, היא יודעת למדוד עומסים וכשצריך – היא תקים את הקונטיינר בשרת אחר אם השרת שכרגע הקונטיינר רץ – עמוס או תקול. אין Live Migration של קונטיינרים, יש להרוג את הקונטיינר ולהריץ אותו מחדש במקום אחר, ובגלל זה כל מידע שצריך להישמר – צריך להיות מאוחסן ב-Volume, אחרת המידע ימחק.

הרעיון של Volume הוא שונה מכל מה שאנחנו מכירים וקשור לאחסון. במערכות וירטואליזציה לדוגמא, אנחנו מגדירים "אחסון" (כמו Datastore ב-VMWare) שיש לו Backing שיכול להיות iSCSI, NFS ובמקרה של Hyper-V זה יכול להיות CIFS. בפתרון הסטורג' שלנו אנחנו מקימים LUN או מחיצה כלשהו שייוצאו כ-NFS/CIFS לפתרון הוירטואליזציה (לא ניכנס עכשיו לכל עניין שרידות, Multipath ושאר ירקות) ועל המקום הזה פתרון הוירטואליזציה שלנו יוצר/משתמש בדיסקים וירטואליים כדי להריץ את מערכת ההפעלה ולאחסן את המידע שלנו.

ב-Volumes לעומת זאת, הדברים שונים לחלוטין. אנחנו עדיין צריכים את ה-Backing (רק שיש הרבה יותר אופציות מאשר iSCSI, NFS – יש 26 אופציות, ו-OpenShift מוסיף עוד כמה) מהסטורג' כדי לאחסן את ה-Volumes, אבל כשאנחנו באים ליצור/להשתמש ב-Volume, אנחנו צריכים קודם כל להגדיר Persistence Volume, להגדיר מה הגודל של אותו Persistence Volume, מה יקרה ל-DATA באותו Volume אחרי שהקונטיינר מת, ומה ההרשאות שיהיה לאותו Persistence Volume מבחינת קריאה/כתיבה. בהגדרות הקונטיינר עצמו אנחנו נשתמש ב-Persistence Volume Claim (או PVC בקיצור) כדי להתחבר לאותו Persistence Volume (או PV בקיצור) ולהגדיר גם Path להיכן להתחבר. ה-PV בדרך כלל מוגדר ברמה של מגהבייט או ג'יגהבייט.

דבר חשוב נוסף קשור לעננים ציבוריים, ואת הטעות הזו אני רואה במיוחד אצל לקוחות שלאחרונה התחילו להשתמש בעננים ציבוריים. מה הטעות? לנסות לבנות מערכות לקונטיינרים כאילו מדובר בתשתית מקומית. זו טעות. K8S נותן מספיק אפשרויות להשתמש בשרותי סטורג' ותקשורת שאותו ענן ציבורי נותן. דיברתי מקודם על Volumes, אז יש Volumes "טבעיים" לכל ספק ענן, לא צריך להקים שרת שיתן שרותי iSCSI או NFS בשביל Volumes ואפשר להשתמש בשאר שרותי הענן לצרכים שונים כדי להריץ K8S.

לכן, אם אנחנו רוצים להקים פלטפורמת K8S, אנחנו קודם כל צריכים להחליט, האם אנחנו מקימים את זה "על הברזל" או על מכונות וירטואליות? אם על מכונות וירטואליות והפתרון מבוסס vSphere, אז אנחנו יכולים להסתכל על VMware Kubernetes Engine™ VKE לדוגמא (ואפשר במקביל להציץ גם ב-PKS של VMWare/Pivotal). חובבי מיקרוסופט? בחודש הבא יוצא Windows Server 2019 שכולל את Kubernetes בתוכו. אם לעומת זאת אנחנו מעדיפים פתרונות כמו OpenShift, CAAS ואחרים, נצטרך להקים מכונות לינוקס ועליהן להריץ את אותם פתרונות. לא אכנס כאן ליתרונות וחסרונות של פתרונות "טבעיים" מול הקמת פתרונות על מכונות וירטואליות – אבל אחת הנקודות שחשוב לזכור, זה שפתרונות שמקימים על מכונות וירטואליות – זה שקל להזיז את הפתרון לעננים או למקומות אחרים במקום להיות "נעול" על פתרון שיצרני ה-OS ווירטואליזציה מציעים. חוץ מזה קיים גם עניין המחיר.

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

  • תקשורת 10 ג'יגהביט. שוב, אין בקונטיינרים Live Migration שמשתנה בו כמה קבצי קונפיגורציה וה-VM "קופץ" למכונה אחרת, יש הקמה מחדש של קונטיינרים ולמרות שה-Image נמצא בסטורג', בחלק מהמקרים הוא מועתק לדיסקים מקומיים ולכן פתרון תקשורת 1 ג'יגה יאיט הכל.
  • סטורג' עם שרידות – יש לא מעט חברות שבטוחות שזה שהדיסקים מחוברים בבקר RAID כפול יש אחלה שרידות. לדעתי – עדיף שרידות שאם "ראש" נופל, "ראש" אחר לוקח מיידית פיקוד, אבל שוב – הכל תלוי בתקציב וכמה הפלפורמה תהיה פרודקשן.
  • דיסקים מקומיים – מאוד חשוב. ה-Images ימצאו בדרך כלל ב-Container Registry, אבל הם יועתקו לדיסקים מקומיים ברוב המקרים ועם הדיסקים מקומיים איטיים, זמן הקמת הקונטיינר יתארך (ותהיו בטוחים שיהיו ערימות קונטיינרים, חוץ מהקונטיינרים שלכם, תלוי בפלטפורמה). דיסקים מכניים זה פתרון לא רע אבל אם רוצים ביצועים – תחשבו על SSD Mixed Intense.
  • אם המערכת הולכת להיות חשופה החוצה לאינטרנט (הכוונה השרותים כמו WEB חשופים לאינטרנט) – אז אבטחה רצינית היא חשובה: לא להקים Images כ-root, תקשורת ו-Namespace מופרדים ועוד דברים חשובים שמצריכים הכרה עמוקה עם פלטפורמת הקונטיינרים. תזכרו: קונטיינר שרץ כ-root וחשוף לרשת – יכול לתת לפורץ הרבה יותר ממה שאתם חושבים.

לסיכום: שוב ושוב אזכיר – קונטיינרים אינם VM והם מצריכים ידע שונה ותכנון שונה לגמרי מאשר פלטפורמות וירטואליזציה. חשוב לבדוק את האפשרויות מבחינת פלטפורמת קונטיינרים ובלא מעט מקרים להשקיע יותר כסף מאשר סתם להתקין K8S חופשי (האבטחה הפנימית של Kubernetes אינה מתחרה בפתרון כמו OpenShift). אם צריך, קחו קורס עבור המפתחים והעובדים על הפתרון שאתם הולכים להכניס וקחו יעוץ לפני שאתם מחליטים איזה פתרון קונטיינרים להטמיע.

הבעיות של SSD NVME בשרתים

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

לפני מס' שבועות קיבלתי פניה מחברה מאוד גדולה (קיבלתי אישור לפרסם את העניין פה בפוסט) עם בעיה די מעניינת: הם רכשו שרת של HP עבור פרויקט מסויים שמצריך תעבורת נתונים במהירות מקסימלית תוך שימוש מאוד כבד במעבדים עם האפליקציה שלהם. הם רכשו דיסקים SSD NVME של אינטל מ-HP ו"על הנייר" הדיסקים והמערכת אמורים לתת את התוצאות שהם רוצים. לא חסר זכרון (יש 2 טרה), הדיסקים מחוברים ישירות דרך ה-PCI מה-Backplane עם הציוד ש-HP מכרו להם (אין בקר RAID כך שמדובר ב-RAID תוכנה ולא RAID-5) ובפועל המהירות מגיעה אולי ל-50% ואם מתחילים לשחק עם ה-Queue Depth אז המהירות יורדת ל-30%.

ב-HP האשימו את כל העולם ואחותו, כולל כמובן את הלינוקס שרץ על הברזל. באותה חברה החליטו לנסות Windows 2016 לראות אם הלינוקס אשם אבל גם שם התוצאות חזרו, ואז הם הגיעו אליי (היי, אני אשמח אם הם יהיו לקוחות קבועים שלי 🙂 ).

אז האם הבעיה קשורה למערכת ההפעלה? לא. גם לינוקס וגם Windows יכולים להתמודד עם NVME בלי שום בעיה. האם משהו דפוק בדיסקים או ב-Backplane המיוחד? גם לא. ה-Backplane עצמו אינו שונה מהותית מה-Backplane שקיים ב-DELL לדוגמא (כמובן שהלוח מעוצב מעט שונה) ובמקרה של לנובו עם שרתים כמו SR650 הפתרון שלהם נקרא Any Drive והוא לא מצריך Back Plane מיוחד – תדחוף SATA, SAS, SAS2, NVME – הכל עובד (לנובו ו-SuperMicro הם היחידים שהיו נבונים מספיק להכניס מתגי PLX ל-Back Plane מבלי שהלקוח יצטרך לרכוש תוספות).

בכדי להסביר את הבעיה, נסתכל בשרת DL320 דור 10 של HP מלמעלה:

מתחת למלבן האדום נמצאים הדיסקים. המלבן הצהוב מציין את המאווררים ששואבים אוויר דרך החורים ב-Caddy והחיצים הכחולים מציינים את כיוון האוויר (משמאל לימין). התכנון עצמו זהה גם בשרתי 2U של HP וגם אצל יצרנים אחרים. האויר חייב להגיע דרך חורי האיוורור שנמצאים ב-Caddy (בתמונה משמאל). לא רואים שיש הרבה חורים לאיוורור, אבל אם נכפיל כמות הכוננים ובעוד כמה חורים שיש – זה מספיק כדי שיכנס מספיק אויר.

וכאן בדיוק העניין: הדיסקים נמצאים לפני המאווררים, ואותם מאווררים מסתובבים במהירות די גבוהה (תלוי אם מדובר בשרת 1U או 2U או 3U – לכל אחד יש גודל מאווררים שונה – 5,10,12 או 14 ס"מ), ומכיוון שהאוויר נכנס דרך החורים בלחץ רציני, הוא קודם כל מקרר את הדיסקים בכוננים עקב ה"יניקה" של המאווררים, שזה מעולה לדיסקים מכניים ולשמירת החום הנמוך בשרת – 18-27 מעלות (השרת טכנית יכול לעבוד גם ב-40 מעלות אבל אז מאווררים יתחילו להישרף בתכיפות גבוהה).

בדיסקים SSD NVME לעומת זאת, הדברים הפוכים. SSD NVME צריך חום כדי לפעול, טמפרטורות כמו 25-40 מעלות למצב Idle וטמפרטורות כמו 40-65 מעלות במצב כתיבה וקריאה רציפים. רכיבי ה-Flash חייבים להיות חמים כדי לכתוב ולקרוא ביעילות. קר מדי? הכתיבה והקריאה יהיו איטיים. חם מדי (מעל 70 מעלות)? ה-SSD NVME יבצע Throttle כדי לשמור על עצמו. שימו לב – הדבר נכון רק כשמהעבדים מתאמצים וחום השרת עולה. במידה והשימוש במעבדים נע בין 10 ל-35% בערך, תקבלו עדיין ביצועי NVME די טובים (הטמפרטורה של ה-NVME עצמם לא משפיעים כמעט על החום בשרת עצמו, והם ניתנים למדידה עצמאית).

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

כדי לראות את הבעיה בצורה אחרת, הבה נסתכל על SSD NVME ל-Enterprise מבית אינטל. בתמונה מימין (כל יצרני השרתים מוכרים אותו) – תכירו: DC P4800X. זהו SSD די "חייתי", אם כי כמות האחסון שלו לא גדולה (עד 750 ג'יגהבייט) והוא מגיע ממשפחת ה-Optane שאינה NAND Flash רגיל.

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

אז אם נניח אנחנו רוצים להכניס עד 4 SSD NVME ולקבל ביצועים גבוהים, מה ניתן לעשות?

תכירו את את ה-Z Turbo Drive Quad Pro של HP. הכרטיס הזה משתמש בטריק שנקרא pci bifurcation, ובו המערכת "מפצלת"  PCIe X16 ל-4 "מסלולי" PCIe X4 ובכך מאפשרת ל-4 כרטיסי SSD M.2 NVME לעבוד ביחד. ישנו מאוורר בכרטיס המופעל ע"י בקר עצמאי כדי לשמור על החום כדי שיהיה ברמה המקובלת ל-SSD NVME. קונים כרטיס כזה, ומכניסים בתוכו עד 4 כרטיסי M.2 NVME (שקונים מיצרן השרתים), משנים הגדרה ב-BIOS/UEFI ומתחילים לעבוד. (הערה, הכרטיס הזה הוא עבור תחנות עבודה של HP, יכול להיות שיש לזה שם/דגם שונה לשרתים אבל פנימית הכל זהה). לכל היצרנים יש פתרון זהה.

הבעיה שתיארתי לעיל היא לא בעיה סודית, כל היצרנים (כולל יצרני SSD כמו סמסונג ואינטל) מכירים אותה והפתרונות יגיעו בשרתים חדשים, רק שכרגע יש מריבה בין אינטל לסמסונג לגבי סטנדרטים חדשים ל-SSD – סמסונג מציעה את NF1 שנכנס מקדימה עם מעטפת מתכת מיוחדת לשמירה על החום ולאינטל יש את פורמט ה"סרגל" שנקרא EDSFF (עכשיו יצרנים צריכים לבחור איזה מהפתרונות למכור, כי אין תאימות בין EDSFF ל-NF1).

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

לסיכום: אם אתם רוכשים מיצרן השרתים שלכם SSD NVME ואתם לא חייבים את הביצועי מעבדים ו-NVME הכי גבוהים, אפשר להכניס אותם מקדימה. לעומת זאת, אם ביצועים מאוד גבוהים תוך צריכת CPU גבוהה הם Must עבורכם, קחו כרטיס מיצרן השרתים המאפשר הכנסה של 4 כרטיסי M.2 NVME ותקבלו את הביצועים שביקשתם.

חישובים על מעברים לעננים ציבוריים מול ענן פנימי

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

בחברות רבות בארץ נערכים מדי פעם חישובים האם לעבור לענן או לא והשאלה הכי חשובה שנשאלת היא: האם זה יוצא יותר זול מאשר לרכוש תשתית כאן בארץ (או היכן שהחברה נמצאת, ארצות שונות וכו').

אם נתייחס למצב בישראל, אז הדבר הכי אירוני שקורה פה בארץ, הוא עניין מחירי שרתי המותג (HP, Dell, Lenovo, Cisco, Fujitsu): המחירים כאן די "דוחפים" את הלקוחות לעבור לשרותי ענן עקב מחירם היקר (מאוד).

הבה נסתכל מהצד השני, אצל ספקי ענן, ולא חשוב אם מדובר בספק קטן יחסית (Linode, Digital Ocean) או על הגדולים (אמזון, גוגל, מיקרוסופט): אצל כל אותם ספקים יש התחמקות רצינית מכל ציוד מותג. אצל הגדולים לא תמצאו שום ציוד מותג של שרתים, לא תמצאו חומרה של Enterprise ממותג (למעט מעבדים), לא תמצאו מתגים של מותגים, אין שום NetApp או EMC שמשמש כ-Storage ל-VM, ועוד. אצל היותר קטנים יכול להיות שתמצאו שרתי מותג – אך הם נרכשים בתצורה הכי בסיסית וכל הציוד הפנימי הוא צד ג' – ללא גרסאות Enterprise. הגדולים בונים לעצמם את הכל ושרתים מיוחדים נרכשים משמות שאף אחד לא מכיר כמו Wywinn הסינית שמייצרת את הדגמים לפי שרטוטי לוחות שספקי הענן מעבירים). בקיצור: המטרה של כל אותם ספקי ענן היא להוציא כמה שפחות כספים על הציוד, ובגלל זה פרויקטים כמו OCP מאוד פופולריים אצל ספקי הענן וכולם משתתפים ותורמים שרטוטים, תכנונים וכו'.

במילים אחרות: כשחברה עוברת לענן, המכונות הוירטואליות לדוגמא שהם יקימו – יוקמו על ציודים שספק אם בחברות ירצו לרכוש אותם מקומית. זה שאתם עוברים לענן לא אומר שלא יהיו לכם מכונות VM תקועות ושאר תקלות. אתם פשוט תצטרכו לבצע Restart והתשתית ענן תקים את ה-VM במכונה אחרת, ומכיוון שתשתית ה-Storage שם שונה לחלוטין מכל NetApp או EMC שאתם מכירים, לא יהיה צורך בביצוע Migrate (ואגב, הדיסקים באותו פתרון Storage – המכניים הם SATA "ביתי" וה-SSD ברובם גם "ביתיים" למעט חלק קטן עבור Write Cache שהם OEM מיצרנים ידועים כמו Samsung).

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

אז איך אפשר לקבל מחיר נמוך, יחד עם עמידה בכל מה ש-Enterprise דורש?

התשובה פשוטה אך לא קלה לעיכול לאנשי מנמ"ר: להחליף את הדיסקט.

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

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

  • וירטואליזציה – 2 הדברים החשובים כשמקימים ענן פרטי זה יציבות ומחיר נמוך (כשאני מדבר על מחיר נמוך, אני מדבר על מחיר תלת ספרתי בדולרים פר ברזל בגירסה המסחרית, או גירסת קוד פתוח עם חוזה תמיכה מבחוץ). מי שמעוניין ב-OpenStack, כדאי שיצור קשר עם SuSE ישראל (המחיר זול בעשרות אחוזים מהמחיר של Red Hat). מי שמעוניין בפתרון שהוא וירטואליזציה נטו, כדאי שיסתכל על RHV של Red Hat.
  • שרתים – אתם יכולים להשתמש בשרתים קיימים או לרכוש שרתים מתור קודם (ברוב המקרים, ההבדל בביצועים בין הדור הקודם לנוכחי לא כזה גדול). אני ממליץ גם להסתכל על השרתים של SuperMicro ושל חברת Tyan. ספציפית ל-SuperMicro יש מבחר הרבה יותר גדול של שרתים לצרכים שונים ופתרונות חדשניים שעדיין לא קיימים אצל HP או DELL לדוגמא, ובמחיר שהוא זול בהרבה בהשוואה לחמשת היצרנים שציינתי לעיל. אגב, הנה משהו מעניין שכתבה חברת Barrons על Supermicro. שרתים שאני לא ממליץ – הם דווקא של HP ובסעיף הבא אסביר מדוע.
  • דיסקים – עולם הדיסקים משתנה כל הזמן. דיסק SATA טיפוסי שבעבר היה נותן מהירות קריאה של 110-150 מגהבייט לשניה נותן כיום 250 מגהבייט לשניה ובקרוב יצאו דיסקים מכניים שנותנים מהירות שמגיעה ל-420 מגהבייט בשניה ובחיבור NVME (כן, SAS/SAS-HD מגיע לסוף דרכו). המבחר די גדול וכפי שהוכיחה חברת BackBlaze בדו"ח אחרי דו"ח (הם מנפיקים דו"ח פר רבעון והם קונים אלפי דיסקים) – דיסקים ל-Enterprise לא נותנים מאומה הן מבחינת ביצועים והן מבחינת שרידות. גם מבחינת מחיר, בממוצע אתה יכול לרכוש 3 דיסקים במחיר שקונים לדוגמא דיסק קשיח מ-HP, כך שאתה יכול להגדיר 2 דיסקים ב-RAID-1 ועוד דיסק כ-Hot Spare, ואתה מסודר לתקופה ארוכה – פר שרת. אני לא ממליץ על שרתי HP מבחינת דיסקים מכיוון ש-HP נועלים אותך על דיסקים שלהם בלבד (שעולים פי 3 בלי הצדקה, במיוחד כשרוכשים פתרון כולל SLA ואז עניין כל החלפת הדיסקים הוא על מי שנותן לכם שרות).
  • דיסקים SSD – עולם ה-SSD מתעדכן כמעט כל חצי שנה במהירות ויש המון יצרנים וסוגי SSD שונים. המצב מול SSD ל-Enterprise הגיע למצב כזה מגוחך כשראיתי אצל לקוח דיסק SSD שעלה המון והביצועים שאותו SSD נותן הם פחות ממחצית מדיסק SSD שיושב לי פה במחשב הדסקטופ שלי, ואני שילמתי רבע מחיר ממה שהוא שילם. לכן, חשוב לבחור יצרן שרתים שמאפשר הכנסה של כל דיסק צד ג' ובכך להנות מהתחרות בשוק.
  • מעבדים – המלצתי בעבר על EPYC ואני עדיין ממשיך להמליץ על מעבדים אלו מהסיבה הפשוטה שמקבלים יותר ביצועים וליבות ומשלמים פחות. החשבון פשוט.
  • תקשורת – זמן רב שהמחירים לא זזו בצורה רצינית בתחום התקשורת אולם כיום יש ירידה במחירים ולכן מומלץ לצייד כל מכונה בכרטיס עם זוג כניסות בחיבור +SFP כתקשורת עיקרית ומתגים עם חיבורים של 10 ג'יגה ו-Up/DownLink של 40 או 50 ג'יגה. אגב, יש בהחלט גם מתגים שתומכים ב-RJ45 וחיבור 10 ג'יגה על CAT6 (למרחקים קצרים) או DAC (גם למרחקים קצרים) או סיבים אופטיים (למרחקים יותר ארוכים).
  • סטורג' – אף אחד מספקי העננים, גדולים כקטנים, לא משתמש בסטורג'. כיום הבון טון הוא שימוש בדיסקים מקומיים עם פתרון Scale Out לסטורג' בין כל המכונות הפיזיות. הפתרונות הפופולריים כיום הם CEPH ו-GlusterFS.

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

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

לסיכום: אפשר להקים תשתית שיכולה בחישוב ROI/TCO להיות יותר נמוכה ממחירים של ענן ציבורי – אם "משתחררים" מהראש של ציוד Enterprise ממותג מהיצרנים שציינתי בתחילת הפוסט. הציוד שתיארתי יכול לעמוד בדרישות פרודקשן חמורות והוא כבר עומד – אצל ספקי עננים קטנים לדוגמא (אגב, כשאני מדבר על "קטנים" אני מדבר על ספק עם מינימום 5 DC ואלפי שרתים פיזיים). כל עוד הדרישות שלכם מסתכמות במכונות וירטואליות וקונטיינרים – זה עובד. יש כמובן דברים שעננים מקומיים לא כל כך נותנים כמו כל עניין ה-Serverless או API ענק כמו של אמזון ל-1001 שרותים שונים, ואם רוצים להשתמש באותם API, אין מנוס מאשר לחתום מול ספק ענן ציבורי.

על מערכות משובצות ועל המעבד המתחרה החדש מ-AMD

בואו נדבר מעט על מערכות חומרה משובצות (Embedded). מה הן בעצם? אלו בעצם מערכות שמיועדות ללקוחות קצה ואמורות להיות סגורות ולהחזיק זמן רב. הנה מספר דוגמאות כלליות: תחשבו על המכשיר שיש לנהגי אוטובוסים לקרוא ולעדכן כרטיסי רב קו, תחשבו על נתבים, תחשבו על פתרונות Firewall, על פתרונות CDN כקופסאות שמיועדים לשבת ב"קצה" (Edge), תחשבו על פתרונות סטורג' קנייניים, על כספומטים, על שלטי חוצות דיגיטליים ועוד המון דברים.

לכל הדברים שהזכרתי יש מס' דברים משותפים:

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

בעולם הקופסאות המשובצות, יש חשיבות גדולה לאיזו חומרה מכניסים, החל ברמת לוח אם, וכלה בשבבים, יציאות, קירור וכו'. במקרים מסויימים יצרנים פשוט ירכשו לוחות אם Mini ITX ומטה (Nano-ITX, Pico-ITX,Mini-STX) עם מעבדים מולחמים ללוח האם והיצרן יוסיף ללוח זכרון, SATA DOM בשביל התוכנה וידאג לפתרון קירור/איוורור מספק + ספק כח קטן מובנה. במקרים אחרים היצרן יעצב לוח אם עם השבבים שהוא בוחר, כניסות/יציאות, פתרון אחסון, קירור, ספק כח וכו' ויצור קשר עם יצרן לוח מטיוואן (Compal, Quanta, Pegasus, FoxConn ועוד) שיקבל את כל השבבים והחלקים, ידפיס לוח אם, ירכיב את החלקים, יבדוק וימשיך בשרשרת האופציות (הרכבה בקופסאות, בדיקות QA/QC וכו'). השיטה הזו לדוגמא מתאימה ליצרנים שצריכים כמות גדולה מאוד של אותו פתרון Embedded (מינימום הזמנה: 10,000 חתיכות). הדברים מעט שונים אצל ספקי ענן ציבורי – הם מתכננים לוח אם, שולחים לייצור ומקבלים את הלוחות בחזרה, ההרכבה וכו' נעשית מקומית אצל ספק הענן.

מבחינת ה"שחקנים" בשוק המעבדים לציוד משובץ, ברוב המקרים אם צריכים מערכת קטנה שאין לה צורך עיבוד רציני, אז סוגרים עיסקה עם יצרן מעבד ARM כלשהו. אם צריך משהו שמצריך עיבוד תקשורת רציני, יסגרו עיסקה על מעבדים כאלו עם חברות כמו Broadcom ואחרים, ואם צריך מעבדים X86-64 – הולכים כמובן לאינטל. לאינטל יש את סידרת Xeon-D וסידרת ATOM CXXX לצרכים הללו.

כל הסידור הזה ידוע לכל יצרן מערכות משובצות. הבעיות מתחילות כשמתגלות תקלות הקשורות למעבד.

בתחילת 2017 התגלה באג קריטי במשפחת מעבדי Atom C2000 למערכות משובצות. מי שרוצה לקרוא על הבאג יכול לקרוא כאן אולם אם נקצר את הדברים, אז יוצא כך: המערכת תעבוד יפה במשך שנה וחצי אבל יום אחד היא יכולה ליפול ולא לקום עקב באג רציני במעבד. מכיוון שאלו מערכות משובצות, בהן אין תושבת המאפשרת החלפת מעבד (המעבד מולחם בשיטה שנקראת BGA – Ball Grid Array), הפתרון הוא להחליף את כל לוח האם. אבל מה קורה אם היצרן החליט להכניס שבבי SSD/Flash על לוח האם? כאן זה נהיה יותר מורכב. תכפילו את המורכבות הזו באלפי מערכות שנמצאות מסביב לעולם – ותקבלו היסטריה רבתי! היצרן צריך לייצר מחדש לוחות אם עם מעבד מתוקן, עם כל השבבים הנוספים (יצרני השבבים הנוספים בהחלט נהנים מהרכישה הכפולה), לשלוח טכנאים על חשבון היצרן, להעביר איכשהו את הגדרות הלקוח, וכמובן לסבול מכל לקוח צעקות על השבתה ארוכה ואולי גם תביעות בדרך מאותם לקוחות. בקיצור – היסטריה רבתי.

בקיצור, לאחר הבעיה המהותית הזו, יצרני קופסאות גדולים החלו לחפש פתרונות אלטרנטיביים שיתנו תאימות X86-64 והעיקר שיהיו עם כמה שפחות באגים כאלו. אחד מיצרני הקופסאות ביקש יצור של לוח אם מיוחד עם מעבד Desktop מסוג Ryzen של AMD ושיהיה עם תושבת – לקופסאות שלו. אב הטיפוס של הלוח נראה כך (המאוורר משמאל מסתיר GPU זמני שיוחלף במעבד ARM של ASPEED לשם שליטה מרחוק):

השאלה שעתה כמעט כל יצרן שואל – יש אלטרנטיבה למעבדי CXXX ו-Xeon-D שיתנו תואמות מלאה?

כן

ב-AMD לאחרונה החליטו להוציא סידרה חדשה של מעבדי EPYC: סידרה 3000 המיועדת כולה למערכות משובצות. היתרונות של המעבדים החדשים קשורים לתאימות מלאה, חסכון בחשמל וביצועים שווים או יותר מהמעבדים המתחרים של אינטל. בנוסף ניתן לחסוך ב-BOM כי אין צורך ב-Chipset.

להלן רשימת המעבדים במשפחת ה-EPYC (לחצו להגדלה):

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

כמובן ששום יצרן לא יקח מעבד חדש בלי מערכת לבדיקות. לשם כך ל-AMD יש לוחות אם הכוללים מעבדי EPYC Embedded תחת השם AMD Wallaby. הלוח שונה מעט בין דגמי המעבדים השונים, כך הוא נראה עם מעבד 8 ליבות ו-16 נימים (לחצו להגדלה):

אז איך המעבדי EPYC 3000 בהשוואה לתחרות מבית אינטל? הם צורכים מעט יותר חשמל (דגם 3251 שמופיע בסקירה כאן לדוגמא) מכיל 8 ליבות אך מכיל גם 16 נימים. המעבד הכי קרוב (דגם C3758 מאינטל) מכיל רק 8 ליבות. ה-C3758 יכול להגיע למהירות שעון מקסימלית של 2.20 ג'יגהרץ ואילו ה-3251 מגיע עד 3.10 ג'יגהרץ.

ומה עם אלו שמחפשים פתרון יותר קטן הכולל חיבורים למסך/ים חיצוני/ים, שצורך פחות חשמל עם פחות ליבות? ל-AMD יש פתרון גם לזה, והוא ה-Ryzen Embedded 1XXX המכיל עד 4 כניסות Display Port, עם 2-4 ליבות, ועם 4 עד 8 נימים. חברת Sapphire מייצרת מספר לוחות כאלו וניתן לקרוא עליהם כאן. העלות של הפתרון המוכן (ללא קופסא, זכרון ואמצעי אחסון) נע בין 325-450 דולר. יש ל-Sapphire עוד מספר פתרונות והם כמובן גם ODM ומייצרים לוחות ללקוחות שרוצים לוח לפתרונות רפואיים, קופות רושמות, קיוסקים, ציוד תקשורת, שילוט חוצות ועוד. אפשר לראות עוד פרטים בוידאו הבא:

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

השורה התחתונה בעניין הטמעת VDI

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

השלב הראשון, עוד לפני שבכלל חושבים על תקציב וטכנולוגיה, היא עניין הכדאיות ואצל רבים אחרים זה לשכנע שלא מדובר באיזה "טרנד" חולף (זוכרים את טרנד ה-Diskless עם PXE בעבר הרחוק? כן, זה היה טרנד שנדחף ע"י Sun וכיום יש בו שימוש פה ושם. אישית אני משתמש בו ב-LAB בשרתי ESXi כשאני לא מעוניין להכניס דיסקים או דיסק-און-קי כדי לבצע Boot מהם).

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

החסרון: המחיר. צריך Storage יותר מהיר ממה שיש אצל רוב החברות (בעברית פשוטה: בלי דיסקים מכניים, עם SSD שהוא Mixed Intense) כי כשיום העבודה מתחיל והעובד יושב ליד המחשב אחרי שהכין לעצמו שתיה והוא מפעיל את ההתחברות ל-VM שלו, הוא רוצה זמן תגובה מהיר, ול-Windows יש Profile וזה צריך לעלות, מה שיוצר עומס עצום על ה-Storage (או מה שנקרא "סופה"/Storm) ועל השרתים שמריצים את מכונות ה-VM. בנוסף יש צורך במספר כרטיסי GPU כשעולים כל אחד כמה אלפי דולרים ושרתים מודרניים מהשנתיים שלוש האחרונים בשביל להריץ את כל העסק. בקיצור: ההוצאה הראשונית היא הוצאה גדולה (ועוד לא דיברנו על רשיונות תוכנה, להיכן לגבות, אם לרכוש Thin Clients או להשתמש ב-PC הקיימים עם לינוקס וכו').

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

אז אחרי שנחתום NDA (לא לספר לאף אחד שאתם רוצים לעבור ל-VDI, לא לספר על התשתית שלכם וכו'), אצטרך לדעת מה יש מבחינת תשתית. או שתספרו או שנעשה "טיול" לחווה. הבה נתחיל בציודים:

סטורג'

לא חשוב איזה סטורג' יש לכם, כל עוד יש בו דיסקים מכניים עם 2-4 SSD לצרכי Cache – הוא לא יספק בשביל להריץ מערכת VDI רצינית. מערכות Windows לדסקטופ "טוחנות" דיסקים עם הפרופילים, ודיסקים מכניים פשוט איטיים לזה וה-Cache קטן מדי. יכול להיות שתצטרכו או להוסיף מדף של SSD Mixed או סטורג' שהוא נטו SSD Mixed. אני מדגיש את Mixed כי Windows דסקטופ אוהב "להשתולל" עם הקריאה וכתיבה. זה לא Windows Server.

פתרונות וירטואליזציה מבוססי HCI

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

שרתים

כאן העניין די פשוט: תצטרכו שרתים מדור קודם או דור נוכחי, בהתאם לדגמים המועדפים עליכם. אפשר שרתים של 1U אבל עדיף 2U שאפשר לדחוף לתוכם יותר מ-GPU יחיד.

חיבור לסטורג'

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

סוויצ'ים

כאן ברוב המקרים נצטרך לשדרג: 10 ג'יגה כפול 2 פר שרת, ו-40 ג'יגה בין הסוויצ'ים (ומעלה אם מדובר באלפי מכונות VM ל-VDI). חיבור 4 כבלים של 1 ג'יגה ב-Bond זה ממש לא פתרון להטמעה גדולה.

רשיונות לוירטואליזציה

מיקרוסופט: כדאי לדלג. עוד ילמדו יום אחד בבתי הספר לעסקים על השגיאה הגדולה שמיקרוסופט עשתה בכך שתמחרה את מחירי ה-Windows Server 2016 מחוץ לשוק (ב-VMWare מודים למיקרוסופט, תוצאות הרבעון האחרון והקודמים מראים על הגירה מהפתרון של מיקרוסופט ל-VMware). אתם תצטרכו לשלם פר ליבה ומכיוון שפתרון VDI מצריך מכונות מרובות ליבות (יותר מ-4 פר מעבד), המחיר שתשלמו יהיה גבוה בהרבה מכל פתרון אחר, אלא אם יש לכם הסדר מיוחד עם מיקרוסופט. חושבים להשתמש ב-Windows Server 2012R2? תצטרכו רשיון Data Center וגם אז התמיכה ב-VDI (למעט RDS) היא די חלקית, השיפורים הרציניים קיימים רק ב-Windows Server 2016.

VMWare: לא זול. תצטרכו את Enterprise Plus ואת Horizon 7.

Citrix: רוצים פורטל מסודר? נתחיל ב-3000$ על Xen Server (רשיון Enterprise ל-2 מעבדים פר שרת) ועל כך נוסיף את Xen App ואת Net Scaler (כתשלום נוסף כמובן). לא בטוח שהפתרון הזה זול ממש בהשוואה ל-VMWare.

Oracle VM Server: כבר עדיף ללכת על הפתרון של Citrix.

RHV של רד-האט: 900$ פר שרת (לתמיכה בשעות עסקיות+ או 1500$ לתמיכה 24/7). לפתרון של רד-האט יש חסרון כלשהו בכך שה-GUI אינו הכי "משופשף", כך שזה יותר מתאים לצוות הוירטואליזציה לנהל בשיתוף צוות לינוקס.

"תצורת ערימה"

יש כאלו שלא ירצו פתרון VDI עם פורטל אלא סתם פשוט "ערימה" של מכונות VM לדסקטופ. כאן גם פתרונות HCI יכולים להתאים (vSAN, Nutanix, Simplivity) אבל חשוב לזכור שכל פתרון HCI יחייב רכישת עוד שרתים בהטמעה גדולה על מנת לקבל תצורת IOPS מאסיבית. אפשר כמובן גם להרים זאת בתצורה הזו (ללא פורטל) בכל פתרון וירטואליזציה רגיל עם דיסקים מקומיים (לא HCI), אבל תצטרכו SSD Mixed וכרטיסי GPU לשרתים.

רשיונות Windows

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

חסכון

בדרך כלל כשמדובר בפתרון למאות או אלפי מכונות Windows בתצורת VDI וכשרואים הצעת מחיר, כולם מרימים גבות, והשאלות מתחילות לצוץ – איך ניתן לחסוך במחיר. עם או בלי פורטל.

אם הולכים ב"תצורת ערימה" ורוצים להשתמש בדיסקים מקומיים, ההצעה הראשונה שלי היא להשתמש במה שנקרא JBOF (כמו JBOD, רק Flash). כרגע היצרן היחידי שמציע זאת זו חברת SuperMicro, והפתרון הוא בעצם קופסא שאליה מכניסים את ה-SSD ומאחורה יש לה יציאות PCIe מיוחדות. מחברים את היציאות האלו (אחת פר שרת) לכרטיס HBA עם כבל יעודי ומנהלים את הדיסקים מה"שרת" של SuperMicro. כך אתם מקבלים ביצועי SSD גבוהים מאוד ומבלי המגבלה של רכישת דיסקים ספציפיים של יצרן השרתים שלכם. בכל קופסא כזו אפשר להכניס כמות "צנועה" של עד 1 פטהבייט של אחסון. ההצעה הזו יכולה לחסוך המון הואיל ואינכם תלויים בדיסקים שיצרן השרתים מוכר (בעשרות אחוזים מעל מחיר השוק, גם אם מדובר באותו דגם אחד לאחד שהיצרן שרתים מוכר. אף אחד מיצרני השרתים לא מייצר דיסקים).

אפשרות נוספת היא לבדוק פתרון מבוסס קוד פתוח (כמו oVirt) עם חוזה שרות לפי SLA שתקבעו.

ישנן עוד אפשרויות שעבדכם הנאמן שוקד על נסיון איתן אך הן עדיין לא בשלות ל-Enterprise.

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

על 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 יצרנים וצריך יעוץ כדי לבדוק איזה כרטיסים מתאימים ולאלו עומסים.