קטגוריה: אחסון / Storage

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

על VDI: מה הפתרון שיכול להתאים?

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

מבחינת מתחרים, יש כמה ש"תפורים" ל-VDI (בצורה מלאה):

  • מיקרוסופט RDS
  • חבילת המוצרים של Citrix
  • VMWare Horizon
  • RHV/oVirt * (כמעט מלאה)

יהיו כמובן אלו שיציצו ברשימה הקטנה ויטענו שחסרים המון פתרונות אחרים, החל מ-Hyper-V ובוודאי יש עוד כמה. התשובה לכך היא שכשאני מדבר על "צורה מלאה" הכוונה מוצר שכבר יש בו פורטל עבור משתמש הקצה להריץ אפליקציות או להיכנס לתוך VM דסקטופי ולהתחיל לעבוד. על oVirt/RHV שמתי כוכבית כי לפתרון חסר מספר "תפירות" בשביל לתת פתרון מלא. כמו כן לא ציינתי מוצרים לדסקטופ כמו VirtualBox, VMWare workstation, Fusion, KVM מכיוון שאלו פתרונות שרצים על דסקטופ, לא על שרתים.

מבחינה טכנית, אין פתרון אחד שיכול להתאים לכולם, וברשותכם אדגים על משרד עו"ד קטן, 10 מחשבים (כולל פקידות ועו"ד). אם מחר משרד כזה היה פונה אליי ומבקש יעוץ לגבי VDI, השאלה הראשונה שהייתי שואל אותו היא פשוטה: מה יותר חשוב לך? מחיר נמוך או שרידות גבוהה? אם מדובר בלקוח ש-2 שרתים, NAS וסוויטצ' ורשיון Essentials של VMWare יקר לו, אז השרידות יורדת מהפרק ובמקרים כאלו שרת ESXI חופשי עם דיסקים מקומיים (נניח RAID-1 ועוד RAID-1 לצרכי גיבוי) יכול להיות פתרון VDI בשבילו (זיכרו, אין לו כסף מעבר לברזל יחיד), כאשר כל המכונות המקומיות עוברות P2V ולאחר העבודה כל העובדים מתחברים ב-RDP. מחיר הרשיונות? אפס (ה-Windows עובר מכונה, לא נשאר מקומית) ויכול להיות שהדבר היחיד שיצטרך לשלם (מעבר לעבודה ולברזל) הוא על תוכנת גיבוי. נכון, בפתרון כזה אין שום פורטל, אבל מצד שני הלקוח לא מוכן להוציא כסף. פתרון Xen או Hyper-V יכולים גם להתאים אך ברוב המקרים פתרון של ESXI יהיה הכי מהיר להקמה (ברוב המקרים אפשר להוריד את ה-ISO מהיצרן שרת, להירשם ל-VMWare לקבל מפתח חינמי ולהתחיל בעבודה).

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

ב-RDS ובמקרה של Citrix (לא XEN Server) הפתרון בגדול הוא כמעט אותו דבר (למען האמת Citrix בנו את הפתרון עוד ב-Windows NT ומיקרוסופט סיכמו עיסקה עם Citrix להשתמש בבסיס לצרכי RDS אך עם פרוטקולים שונים וכו' וכו'): אתה מרים שרתים (ב-RDS לדוגמא זה Windows 2012/2016 Data Center), מגדיר את הדברים (במקרה של Citrix מתקין עוד כמה תוכנות) ואז כל משתמש מקבל בעצם Session, ה-Session יכול להיות דסקטופ מלא או אפליקציה ספציפית. ב-Citrix יש יתרון שיש לך Portal קל להבנה והוא יכול להכיל גם אפליקציות עצמאיות וגם Session של דסקטופ (קופ"ח מכבי משתמשת בכך לדוגמא, הרופאים שביקרתי אצלם והשתמשו בזה לא ממש מתפעלים).

וכאן גם נעוצה הבעיה המרכזית גם בפתרון של Citrix וגם בפתרון RDS: ניהול משאבי החומרה. ב-VM אני מגדיר כמות ליבות, כמות זכרון, כמות דיסק, חיבור רשת וכו', ואם המשתמש לדוגמא גולש לאיזה אתר והאתר נפרץ ומישהו הזריק לשם Coinhive, אותו משתמש ספציפי יתלונן שה-VM שלו איטי (טוב, הוא לא יאמר "VM" 🙂 ) אבל הדברים לא ישפיעו על מכונות VM אחרון (למעט בנוזקה שיודעת להשתמש ברשת). בפתרונות שאינם מבוססי VM, סביר להניח שגם אחרים יושפעו, כי אין הפרדה מוחלטת של משאבי CPU וכו'. יהיו כמובן אלו שיאמרו שהם משתמשים בסביבה סגורה ללא אינטרנט, ושם יכולים להיות באגים של תוכנות שונות שיש בהן Memory Leak – בהצלחה למצוא זאת. יחד עם זאת, ל-RDS ולפתרון של Citrix יש יתרון נוסף בכך שמבחינת חומרה, אין צורך להשקיע בסטורג' סופר יוקרתי (בניגוד לפתרון VDI מבוסס על מכונות VM).

ומה עם Horizon? ל-Horizon יש יתרון של גם וגם וגם. הוא תומך בפתרונות RDS, הוא תומך באפליקציות כ-Session (מה שנקרא ThinApp) וגם במכונות VM מלאות והכל נגיש למשתמש בפורטל נחמד. החסרון? בניגוד ל-RDS "רגיל" או הפתרון של CItrix שיכולים לרוץ על סטורג' די פשוט (שבנוי מדיסקים מכניים) – פתרון של Horizon עם מאות או אלפי מכונות יצריך סטורג' מבוסס SSD.

מה עם פתרון מבוסס קוד פתוח? עם oVirt יש פורטל (אך לא ניתן להשתמש באפליקציות כ-Session), ואפשר לעבוד איתו כפתרון VDI (הוא גם תומך בכרטיסי Tesla כמאיצים). העבודה עם RHV/oVirt מצריכה הכרת מושגים מעט שונים. RHV הוא הפתרון המסחרי.

ומה עם עננים ציבוריים? כאן כדאי לזכור שאנחנו חיים בישראל, וה-Latency מחו"ל לארץ (למעט אם רכשת חיבור יעודי ב-7500$ ומעלה!) מתחיל ב-100 מילישניות וזה די יגרום למשתמשים סבל, במיוחד כאשר יש משתמשים רבים.

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

חומרה ל-VDI: מציאות מול חומר שיווקי

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

כאן צריך לקחת בחשבון 2 נקודות מאוד חשובות:

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

בואו ניקח דוגמא מתחום הוירטואליזציה: אינטל רוצה לדחוף את משפחת מעבדי ה-Xeon-SP שלה (תחת שם קוד: Purley) ומוציאה דו"ח איך המעבדים שלה מנצחים בנוק-אאוט את המתחרים, מעבדי ה-EPYC של AMD. כך הם מציגים גרף שבו מעבד ה-Xeon 8160 שלהם מהיר ב-37% מהמעבד 7601 EPYC של AMD.

נשמע מרשים, לא? שליש יותר! רק שבאותיות הקטנות רואים את הבדיקה המוטעה: אינטל הקימה 58 מכונות וירטואליות על ה-Xeon 8160 ועל ה-EPYC 7601 הם הקימו .. 42 מכונות וירטואליות. חשוב לזכור: בניגוד למצב שבו יש לנו שרת ללא וירטואליזציה ואנחנו מריצים אפליקציית Multi Threaded – לאפליקציה זמינים כל משאבי השרת, ואילו במכונה וירטואלית, המשאבים הזמינים לאפליקציה הם רק המשאבים שהגדרנו ל-VM. במילים אחרות: מעבד ה-EPYC במדידה ישב עם 16 ליבות פיזיות בלתי משומשות במבחן (מתוך הנחה שהם הגדירו 2 ליבות וירטואליות פר VM כאשר המכונה שהם משתמשים לבחינה מכילה 2 מעבדי EPYC 7601), כך שאם הם היו מקימים עוד מכונות וירטואליות על אותה מכונה, התוצאה היתה מתהפכת!

וכך בעצם מטעים לקוחות.

מכאן נעבור לתחום די פופולרי שמקבל תאוצה בזמן הזה: תחום ה-VDI. יש 3 מתחרים גדולים (VMWare, Microsoft, Xen – ויש עוד מוצר מסחרי שדווקא די מלהיב מחברה אחרת, אני אכתוב עליו פוסט בזמן הקרוב, לאחר קבלת אישור מהיצרן).

בשביל להקים תשתית VDI, אנחנו צריכים להחליט מה תהיה תצורת ה-VM. סביר להניח שנגדיר 2 ליבות, 4-8 ג'יגהבייט זכרון, ו-50-100 ג'יגהבייט דיסק. המכונה עצמה תהיה Linked Clone למכונת Master VM (אני לא מדבר כרגע על הפתרון RDS של מיקרוסופט, אלא מכונות VM).

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

ועל מה ירוצו כל מכונות ה-VM הללו? כמובן, על שרתים פיזיים. כאן בעצם חברות מתחלקות ל-3:

  • יש חברות שיקימו את ה-VDI על שרתים שקיימים בחברה תוך הסבתם לסביבת VDI חדשה.
  • יש חברות שיבחרו לרכוש שרתים חדשים ולהקים זאת כ-Hyper Converged (או HCI)
  • יש חברות שיקנו שרתים חדשים מבוססי מעבדי אינטל, סטורג', סוויצ'ים ויקימו עליה את תשתית ה-VDI.

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

  • שימוש בתשתית קיימת: למעבדי Xeon מהראשונים עד V4 (לא כולל) כמות ה-Cache היא קטנה והביצועים הם לא רעים – אם בונים VDI לכמות משתמשים של עשרות בודדות. צריכים כמה אלפי מכונות VM ל-VDI? המעבדים הללו יהיו חלשים מדי. (כמות Cache רצינית נמצאת במעבדים כמו Xeon E5 v4 2998/2999 אבל אינטל די מתחמנת עם המספרים ומכלילה אותם כ-"Smart Cache" מבלי לפרט רמות L1, L2, L3 – והמעבדים הללו סופר יקרים – 4000$ לחתיכה וזה במחיר של אמזון. בארץ – זה הרבה יותר גבוה).
  • שימוש ב-HCI: על פניו הרעיון הוא טוב, אולם בניגוד ל-VM אחרים, VDI מחייב IOPS גבוה, ובשביל להשיג IOPS גבוה, אתה צריך לרכוש המון (תחשבו במושג של ארונות) שרתים, כך שזה לא ממש משתלם, במיוחד במחירים בארץ שגבוהים מאוד בהשוואה לארה"ב לדוגמא.

שרתים חדשים מבוססי אינטל Xeon SP: המחירים של אינטל גבוהים (במיוחד כאן בארץ, ולא חשוב מי היצרן/ספק), ואם לדוגמא אתה רוכש מכונה עם 2 מעבדים בעלי 8 ליבות (כלומר 16 ליבות במכונה), אתה יכול לרכוש מכונה עם 2 מעבדי EPYC בעלי 16 ליבות באותו מחיר ולקבל בעצם 16 ליבות בחינם. במקרים של מעבדים עם יותר ליבות, המחיר של מכונה עם אותו מפרט אך עם מעבדי EPYC יהיה זול בהרבה וזה מגיע למצב של מעבדי הפלטינום של אינטל ששם אתה יכול לחסוך מינימום 6000$ פר מעבד ולקבל במקום 28 ליבות בקצה הכי גבוה של אינטל – 32 ליבות במערכת מבוססת EPYC.

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

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

התוצאה (המחירים הם של Dell ארה"ב אחרי הנחה של 250$, המחיר בארץ יהיה גבוה בהרבה, לא חשוב איזה יצרן):

  • שרת DELL R7425 עם 2 מעבדי EPYC 7601 (כל מעבד עם 32 ליבות) ו-512 ג'יגהבייט זכרון: מחיר של 24,079 דולר.
  • שרת DELL R740 עם 2 מעבדי Xeon 8180 (כל מעבד מכיל 28 ליבות) ו-512 ג'יגהבייט זכרון: המחיר הוא: 37,834 דולר

במילים אחרות: אתה תשלם 13,755 דולר על פחות ליבות (8 פחות), פחות Cache (באינטל תקבל 38.5 מגה למעבד, ב-AMD תקבל 64 מגה למעבד), פחות ערוצי זכרון ישירים (אינטל: 6, מול AMD: 8) ופחות נתיבי PCIe (אינטל: 48, ואצל AMD: 128), ועוד לא דיברנו על כך שמבחינת Performance Per Dollar ומבחינת Performance Per Watt ההצעה של אינטל לא משתלמת בהשוואה להצעה של AMD.

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

מבחינת תצורת VDI, יש 2 דרכים לממש זאת: בתצורת "מפלצות" ואז כמות השרתים קטנה, או בתצורה של שרתים יותר קטנים. אישית הייתי ממליץ לקחת את שיטת ה"מפלצות" מכיוון שכמות השרתים במחיר הגבוה היא קטנה וניתן לדחוס אליה מאות מכונות VDI (תלוי כמובן בכמות הזכרון). כך לדוגמא: אם יש צורך ב-500 מכונות VM ל-VDI, אפשר בקלות להכניס אותם ל-2 מכונות (או 3 בשביל שרידות והתרחבות עתידית). אגב, אם תלכו לפי המחירים של VMWare ומעבדי EPYC, תשלמו פחות פר מכונה (ב-VMWare אין חשיבות לכמות ליבות פר מעבד, במיקרוסופט בהחלט יש!).

בכל מה שקשור ל-GPU, רבים אצים רצים לרכוש את הכרטיסים של nVIDIA כדי להכניס לפתרונות VDI, אולם כרטיס כמו AMD FirePro S7150 X2 שנותן ביצועים לא פחות מ-Tesla בכל הקשור ל-vGPU רק בפחות ממחצית המחיר. אפשר לרכוש אותו ישירות מיצרן השרתים או מיבואן AMD בארץ.

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

  • האם הפלטפורמה יציבה? בהחלט.
  • האם היצרנים כבר מכרו כאלו פה בארץ לחברות גדולות? בהחלט (בדקתי)
  • האם ציודים קיימים (כרטיסים שונים, דיסקים, GPU וכו') נתמכים? בהחלט.
  • האם בארץ ליצרנים יש שרתים כאלו שאפשר לבדוק במשרדיהם? ל-Dell ו-HPE כן. לנובו – לא. לחברת Cisco יש שרתים עם מעבדי EPYC (שרתי Cisco UCS C4200 ו-Cisco UCS C125 M5 Rack Server Node שניתן להכניס 8 כאלו בשרת 2U) אך לא ידוע לי אם יש להם שרת כזה בארץ לבדיקות/הדגמה. במידה ואתם מעדיפים שרתים מיצרנים אחרים (Asus, ASRock Rack, SuperMicro, TYAN) – לכולם יש משפחות שרתים עם EPYC.
  • האם יש תמיכה במערכות הפעלה? כולן עובדות ללא צורך בטלאים מיוחדים, כולל RHEL, VMware 6.5U3, Windows Server 2012R2/2016, CentOS 7.5.
  • האם מעבדים עתידיים יתאמו לשרתים הנוכחיים? כן. תושבת ה-SP3 של AMD תומכת במעבד הנוכחי ובדור שיצא אחריו לפחות (שיכלול עד 48 ליבות) כך שאם תרצו לשדרג את השרת למעבד עתידי, כל מה שתצטרכו לעשות זה לעדכן BIOS/UEFI ולרכוש את ה-Kit מהיצרן שרתים. AMD בדרך כלל שומרת תאימות ל-5 שנים קדימה מהופעת התושבת לראשונה.

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

נקודות למחשבה כשרוצים לרכוש סטורג' חדש

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

לא מעט חברות בארץ משווקים (או Reseller) של מוצרי סטורג'. חלק מהמוצרים הם סטורג' "אמיתי" וחלק מהמוצרים הם לא יותר מאשר שרת סטנדרטי שהוכנסו לתוכו דיסקים, מערכת הפעלה קניינית הכוללת פתרון סטורג' בתוכנה – והרי לכם סטורג' מבוסס תוכנה. כמעט אף אחד, אגב, לא יאמר לכם שזה SDS (כלומר Software Defined Storage) למרות שרוב הסטורג'ים שמוכרים בקצה התחתון עד בינוני הם SDS לכל דבר ועניין, רק שאתם תשלמו מחיר הרבה יותר גבוה ממחיר שרת רגיל שיש בו דיסקים ואיזו תוכנה. מדוע? וולקאם טו איזראל!

אני רוצה להכיר לכם את Elsa, סטורג' שאני בניתי מחלקים שהשאלתי מ-2 יבואנים יקרים (תרתי משמע). Elsa מזמן כבר "מתה" והציוד הוחזר ליבואנים אולם בעתיד אני מתכוון לבנות את Elsa מחדש. מה יש בשרת Elsa?

  • 22 דיסקים של סמסונג מסוג PM883 בגודל 1 טרהבייט מסוג Mixed Intensive
  • 2 דיסקים של אינטל 900P (לצרכי Cache, ZIL, Logs) בגודל 280 ג'יגהבייט
  • 256 ג'יגהבייט זכרון DDR4 ECC במהירות 2666 מגהרץ
  • מעבד יחיד Xeon V4 עם 4 ליבות
  • מערכת הפעלה: Fedora 28 עם ZFS
  • חיבורי רשת של 25 ג'יגהביט

המערכת הזו עבדה במשך חודשיים תוך כדי שהיא מחוברת ל-15 שרתי ESXi ונתנה הן שרותי iSCSI והן שרותי NFS (נפרדים, ישירות ל-VM). מבחינת IOPS – זה נע בין חצי מיליון ל-מיליון.

מערכת כזו אינה בנויה כפי שניתן לראות ל-Enterprise. אין בה בקרי RAID כפולים והשרידות שלה היא לא משהו (אין שום שרת נוסף זהה לצרכי HA), אבל אני מראה כאן את Elsa כדי ללמוד משהו חשוב, על Tiering שמאוד חשוב בכל סטורג' שקונים.

בעקרון, ה-Tiering הוא בעצם "שכבות" בהם נמצא המידע שלנו. ככל שהמידע נדרש בתכיפות יותר גבוהה, הוא "יושב" ב-Tiering יותר גבוה (כאשר הוא תמיד גם נמצא ב-Tier הכי נמוך – בדיסקים הקשיחים). שכבות ה-Tiering ב-Elsa הם (מהכי מהירים להכי "איטיים", אין ב-Elsa דיסקים מכניים):

  • ה-256 ג'יגהבייט זכרון – זה ה-RAM של המערכת, זה הדבר הכי מהיר שיש
  • 2 הדיסקים 900P של אינטל – יש להם Latency יותר גבוה מ-RAM אבל יותר נמוך מכל דיסק אחר
  • דיסקים SSD

בסטורג' קנייני לעומת זאת (StorWiz של IBM, או VNX של EMC לדוגמא) ה-Tiering מעט שונה:

  • שכבת ה-RAM
  • שכבת NVRAM – זהו זכרון מסוג מיוחד שאינו נמחק ברגע שאין חשמל
  • שכבת ה-SSD
  • שכבת הדיסקים המכניים / SSD שליפים (במדפים)

בשרתי סטורג' שהם SDS אין שכבת NVRAM ובמקרים רבים גם אין בקרי RAID כפולים, כך שה-Tiering הוא כמו זכרון, SSD, ודיסקים. כאן, חשוב לדרוש שיהיו SSD שלא מותקנת עליהם מערכת ההפעלה, ה-Cache אמור לשבת ב-SSD נפרדים ושיהיו Mixed Intensive. ברוב ההצעות מחיר שתקבלו, ה-SSD יהיו Read Intensive ויש הבדל ניכר במחיר.

דבר נוסף שחשוב הוא עניין החיבוריות: כמעט כל מי שמוכר פתרון סטורג', מוכר אותו עם פתרון FC (כלומר Fiber Channel) במהירות 16 ג'יגהביט. זהו פתרון טוב לדיסקים בחיבור SAS ו-SAS2 או SATA למדפים/JBOD או בדיסקים שיושבים בשרת, אבל אם אתם חושבים על NVME – פתרון ה-FC יהווה צוואר בקבוק – חיבור 16 ג'יגהביט מאפשר ברוטו 2 ג'יגהבייט לשניה, ו-NVME מעביר בין 1.5 ל-2.5 ג'יגהבייט לשניה ואני מדבר על דיסק יחיד, ומכיוון שלעולם לא תכניסו SSD NVME יחיד, החיבור יחנק, ולכן אולי כדאי לחשוב על פתרונות Infiniband או Ethernet מהירים במהירות 25 ג'יגהביט ומעלה (ובקשר ל-Latency – ישנם מס' פתרונות עם Latency נמוך, כולל RDMA וחבריו).

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

נקודה נוספת שחשוב לקחת בחשבון היא גיבוי הסטורג' עצמו. כן, יש Veeam שמגבה מכונות וירטואליות (והוא מגבה ל.. סטורג') אך תקלה רצינית בסטורג' (ותקלות תמיד קורות, תשאלו את מרפי) לא תאפשר לכם לא לשחזר מכונות VM או דברים אחרים, ולכן כדאי לגבות את הסטורג' לקלטות גיבוי או למכונת NAS זולה אחרת (במכונות שהן אינן G8/G9/G10 של HPE שהן אינן ביצור/פרודקשן אפשר גם להכניס SATA "ביתיים" גדולים זולים, רק חשוב להוסיף SSD לשם Cache). כאן, אגב, אני רוצה להזהיר בהזדמנות שדיסקים SSD של אינטל ש-HPE משווקת, במקרים רבים הקושחה כזו גרועה, שדיסקים נופלים גם בצוותים!

ודבר אחרון שיכול להיות חשוב: חוץ מ-iSCSI, תחשבו על פרוטוקולים אחרים שאתם צריכים בשרתים שניתן להוציא אותם באופן "טבעי" מהסטורג' ולא להסתמך על שרת VM שיוציא אותם (SMB/CIFS, NFS) מכיוון שסטורג' תמיד יוציא אותם עם ביצועים גבוהים יותר. ואם יש לכם צורך בכך, הכניסו את זה בתנאי הרכישה של הסטורג'.

ומה לגבי כל ההתלהבות לגבי HCI עם vSAN/Nutanix/Simplivity במקום סטורג' יעודי? הם טובים, אבל הבעיה האמיתית שלא תמיד שמים לב אליה היא עניין גדילת כמות הסטורג': במקרים כמו vSAN לדוגמא תצטרכו להוסיף 3 דיסקים (2 מכניים או SSD Read פלוס SSD מהיר) פר שרת שמשתתף ב-HCI, ומהירות IOPS גבוהה מקבלים רק כשכמות השרתים המשתתפים ב-HCI היא גדולה (ארון פלוס). נוסיף לכך שבניגוד לדיסקים ביתיים, דיסקים ל-Enterprise יקרים והמחירים בקושי יורדים (וחברה כמו HPE לוקחת עשרות אחוזים יותר בגלל … מדבקה ושינוי כמה ביטים בקושחה) – זה יכול להוות בעיה בטווח הארוך.

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