סקירה מקדימה: מעבד AMD EPYC ROME

בשבוע שעבר אינטל החלה לחשוף מספר נתונים על מעבדי על Cascade Lake AP שלהם. כשאני מדבר על "מספר נתונים", אני מדבר על פירורים ורמזים – הרבה מאוד מידע חסר. אינטל חשפה את המידע יום אחד לפני ש-AMD חשפו את מעבדי ה-EPYC החדשים תחת הקוד "ROME" (רומא, כל הקודים של מעבדי EPYC קשורים למקומות/ערים באיטליה).

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

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

ב-2017, אחרי שההנהלה הוחלפה וד"ר ליסה סו נכנסה לתפקיד המנכ"לית, הציגה AMD את ארכיקטורת ZEN, ואת מעבדי ה-EPYC, ו-AMD הציגו את המעבד הראשון בעולם עם 32 ליבות, 64 נימים ותמיכה של עד 2 טרהבייט זכרון פר מעבד. מבחינת ביצועים, אם נשווה את ה-EPYC למעבדי ה-Xeon SP, מעבדי ה-EPYC של AMD מובילים ב-2 קטגוריות עיקריות:

  • וירטואליזציה, כולל VDI
  • קונטיינרים

ב-2 המקרים, מעבדי ה-EPYC נותנים יתרונות ברורים על פני מעבדי Xeon SP, הן במצב וירטואליזציה "קלאסי" (סטורג' חיצוני, מכונות VM רצות על ברזלים) והן בפתרונות Hyper Converged (סטורג', רשת, Compute – הכל רץ על הברזלים המקומיים). ב-VDI היתרון של EPYC הוא שניתן להכניס הרבה יותר סשנים/מכונות וירטואליות פר ברזל מבלי לשלם את המחירים הגבוהים של מעבדי Xeon SP. כשזה מגיע לעומת זאת לאפליקציות ופלטפורמות שרצים על הברזל כמו Deep Learning, AI, רינדור תלת מימד ועוד מספר דברים (או מכונת VM שמשתמשת ברוב הליבות) – היתרון למעבדי Xeon SP ברור (אם כי רק בדגמים של Gold ו-Titanium). הביצועים היו יותר נמוכים עקב הארכיקטורה של המעבד שנתנה ביצועי Latency יותר גבוהים, תלוי על איזה ליבות או פיסת סיליקון נופלים, דבר שלא משנה ממש בוירטואליזציה/קונטיינרים וניתן להגדרה בקלות עם CPU Affinity.

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

בתמונה משמאל נוכל לראות את המעבד בגירסה הראשונה: 4 מעבדים שמכילים את כל מה שצריך (I/O, PCIe, ניהול זכרון וכו') בתוך כל אחד מהם. בתמונה למעלה נוכל לראות תצורה שונה לחלוטין: כל מלבן קטנטן שרואים בתמונה (AMD קוראים להם Chiplets) הם פיסות סיליקון שמכילות כל אחת מהן 8 ליבות (וסך הכל 64 ליבות במעבד בקצה הגבוה) אך ללא הדברים האחרים כמו ניהול זכרון, I/O, PCIe ועוד. מי שדואג לכל הדברים הוא המלבן האמצעי הגדול – זהו ה-I/O מודול שכולל את כל מה שצריך בשרת, הוא מנהל את הזכרון מה-Chiplets ואליהם, תעבורה, חיבור למעבדים וציוד אחר ועוד. בשיטה הזו, מהירויות תעבורת הנתונים וה-Latency הם צפויים וקבועים. כך בעצם AMD מסירה מה-Chiplets כל דבר שאינו קשור ישירות לליבות והביצועים יותר גבוהים בהשוואה למעבדי EPYC מדור קודם: פי 2 בהשוואה לדור קודם בעבודות רגילות, ופי 4 כשמדובר על Floating Point. ב-AMD החליטו גם להיות הראשונים (במעבדי X86-64) לצאת עם מעבדים עם תמיכת PCIe 4.0 כך שרוחב הפס לכל כרטיס PCIe הוא כפול ושבב ה-I/O יוכל לתקשר איתם במהירות כפולה בהשוואה לכל מעבד של אינטל.

מבחינת תאימות, AMD מאוד אוהבת סולידיות (כמו הלקוחות שלהם) ולכן מעבדי ה-EPYC החדשים יכולים להיות מוכנסים לשרתים הנוכחיים, לעדכן BIOS/UEFI ולקבל גם את הביצועים הגבוהים וגם כמות ליבות גבוהה (עד 64 ליבות פר מעבד) באותו שרת, ו-AMD מבטיחים שגם משפחת ה-EPYC הבאה (שם קוד: "Milan" שתצא ב-2020) תהיה תואמת לאותה תושבת, כך שניתן יהיה לשדרג כל שרת קדימה.

בזמן הצגת המעבד, ב-AMD החליטו קצת להתעמר באינטל עם הדגמת C-RAY, זו תוכנה לחישובי תלת מימד שמשתמשת רק במעבד (לא ב-GPU), והם השוו מכונה עם 2 מעבדי Xeon SP 8180M (זה המעבד הכי גבוה שיש לאינטל להציע ללקוחות, עם 28 ליבות פר מעבד) מול מכונה עם מעבד יחיד של EPYC החדש, וזה נראה כך:

ה-Sales Pitch של AMD לחברות שמריצות פתרונות וירטואליזציה הוא כזה: מחירי המעבדים שלנו זולים ב-60% מהמעבדים של אינטל בקצה הגבוה. אתה יכול לחסוך חשמל, ניהול מכונות וחסכון ברשיונות וירטואליזציה (הם מדברים על VMWare, לא על הפתרונות של מיקרוסופט) בכך שתעבור לכמות קטנה של שרתים מבוססי EPYC החדשים. הוידאו כולו המציג את המעבדים החדשים, את 2 כרטיסי ה-GPU החדשים ל-Data Center, עננים וחסכון ב-Datacenter אפשר לראות בוידאו הבא (הקישור לוידאו מתחיל בחלק של החסכון, תרגישו חופשי לרוץ קדימה ואחורה בוידאו):

לסיכום: AMD הציגה פרטים על מעבדי ה-EPYC החדשים ו-AMD מראה שאין לה כל כוונה לרדת מה"מלחמה" מול אינטל בכל הנוגע לתחרות של מעבדים לשרתים (על מעבדים לדסקטופ – AMD תציג פרטים במהלך ינואר). ב-AMD הפיקו לקחים רבים מה-EPYC הראשון ושינו דברים רבים, אך יחד עם זאת חשוב להם לשמור על תאימות כך שלקוחות לא יצטרכו לזרוק שרתים רק בגלל שהחברה החליטה להחליף תושבת למעבד (דבר שאינטל משנה תדיר, מה שמקשה על שדרוג שרתים מבלי להחליף שרת). ישנם שינויים רבים ש-AMD ביצעה ל-I/O Chip שלהם שלא כתבתי עליהם ושיופיעו בפוסט עתידי.

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

יש חברות שכבר הספיקו לתכנן את תקציב ה-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 כתבתי כאן וכאן.

על ליבות, נימים, אינטל, AMD

בשבוע האחרון נשאלתי ע"י מס' אנשים לגבי ליבות, נימים לאחר שפירסמתי לינק (שאפרסם אותו שוב בהמשך פוסט זה) מבחינת ביצועים. למען פוסט זה, אבהיר שכשאני מדבר על "נימים", אני מדבר על Threads, אינטל קוראת לזה HT (או Hyper Threading) ו-AMD קוראת לזה SMT (או Simultaneous multithreading).

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

מדוע אינטל מציעה את אותם HT מזה שנים רבות? התשובה לכך פשוטה: מחיר. במשך שנים רבות אינטל היתה די בודדה בצמרת (אם נשכח לרגע את Sun, אבל המכירות של Sun לשעבר היו קטנות לעומת המכירות של אינטל, לפחות ב-15 השנים האחרונות) ואינטל גבתה מחירים גבוהים מאוד על מעבדים שהיו בסופו של דבר קצת יותר משופרים ממעבדי הדסקטופ שלה (כשאני מדבר על "קצת יותר משופרים" אני מדבר על כך שיש יותר זכרון מטמון ועוד מס' דברים שאינטל לא רצתה שיהיו במעבדי הדסקטופ, כמו תמיכת זכרון ECC, או RAS וכו'). אינטל תמיד ציינה שיצור מעבדים מעל 4 ליבות הוא תהליך יקר עם תפוקה יותר נמוכה, ובכך הם צודקים, אז אינטל ניסתה בעצם "להיפגש באמצע" עם לקוחות, בכך שהם הציעו את ה-HT. אינטל נקטה עוד כמה צעדים שיווקיים כמו "עידוד" היצרנים לייצר לוחות אם בעלי תושבת מעבד כפולה גם אם הלקוח רוצה מעבד יחיד ואין לו כוונה להוסיף מעבד (כיום זה מעט פחות רלוונטי מכיוון שיצרני השרתים מייצרים גם דגמים עם תושבת אחת).

אינטל, בשונה מ-AMD, מייצרת את המעבדים שלה כך שכל הליבות יושבות על פיסת סיליקון בודדת (במעבדי Xeon ישנים בעלי 3 ספרות, היו 2 פיסות סיליקון). ב-AMD לעומת זאת, הלכו על שיטה שונה לגמרי: בכל פיסת סיליקון ישנם 8 ליבות (בגרסאות מעבדים עם פחות מ-8 ליבות הם מבטלים ליבות עם מיקרוקוד), ובמעבדים כמו Threadripper ו-EPYC הם פשוט שמים עד 4 פיסות סיליקון (שנקראים CCX) ומשתמשים בטכנולוגיה שנקראת Infinity Fabric כדי לקשר בין הליבות במהירות של 100 ג'יגהביט לשניה. כך AMD יכולה למכור ברבע עד חצי מחיר מעבדים עם אותה כמות ליבות כמו אינטל.

כפי שציינתי לעיל, ברוב המקרים ל-HT אין יתרון. היכן בעצם יש יתרון (חלקי)? כשאנחנו מעוניינים "לנעוץ" מכונת VM לליבה לוגית (מה שנקרא CPU Affinity) או כשאנחנו מעוניינים להצמיד Process מסוים לליבה לוגית (בתוך ה-OS) כדי לקבל את כל אותם משאבי הליבה הלוגית. שם – יש יתרון ויש יותר גמישות כי יש לך "יותר ליבות".

עוד מקום שיש לו יתרון קטן ל-HT/SMT הוא דווקא בתחום ה-VDI. אם ניקח לדוגמא מערכת Windows ונפעיל אותה על VM, הליבה תהיה עמוסה (יחסית) בזמן ש-Windows עושה Boot, מעלה דרייברים, שרותים, ואפליקציות שונות, אולם מהרגע שהמשתמש ביצע Login והפעיל את האפליקציות שלו, הליבות די "משתחררות" והעומס יורד. מדוע ציינתי "יתרון קטן"? כי אם נרים פתרון VDI של מאות מכונות וירטואליות, שרתים עם כמות ליבות קטנה (פחות מ-16 ליבות פיזיות בכל השרת) ו-HT יתנו ביצועים נמוכים יותר בעת הפעלת מכונות ה-Windows הוירטואליות, וצריכת החשמל תהיה יותר גבוהה.

באתר Phoronix ישנו מאמר שמראה מה קורה אם אנחנו רוצים להריץ אפליקציות Multi Threaded על כמות ליבות שונה, החל מ-2 ליבות (ללא HT) ועד 64 ליבות פיזיות – והשוואה של התוצאות כשמפעילים HT/SMT. המבחנים בוצעו על שרת R7425 של DELL עם 2 מעבדי EPYC  של AMD והפצת לינוקס, אך התוצאות יהיו פחות או יותר זהות על מערכת עם מעבדי אינטל.

לסיכום: האם כדאי לכבות את ה-HT? כן, אם יש לכם מכונות VM עם ליבות מרובות או שאתם מריצים דברים "על הברזל" ואותן אפליקציות הן Multi Threaded. אם לעומת זאת, מכונות VM לא ממש מנצלות את הליבות עד תום או שהאפליקציות הן Single Threaded, אז HT לא ממש יפריע. בתחום ה-VDI לעומת זאת, כדאי לשקול לבטל את ה-HT – אחרי בדיקות ביצועים (יש הבדלים שונים בין פתרונות VDI הקיימים בשוק).

על 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, אין מנוס מאשר לחתום מול ספק ענן ציבורי.

עדכון בקשר לרכישת שרתים חדשים

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

לחברת אינטל יש בעיה שקיימת החל מסביבות יוני-יולי – כושר היצור של המעבדים הנוכחיים נפגע, ומדובר לא רק במעבדים לדסקטופ, אלא גם במעבדי Xeon SP לשרתים. כרגע כשבודקים מחירים של מעבדי דסקטופ באתרים השונים עם התוסף keepa, ניתן לראות כי ישנה עליה במחירים של בין 10-20%, תלוי במעבד. בתחום השרתים בחנויות כמו אמזון, המחיר ירד מעט ועל מיד ל-$460 לחתיכה.

התמונה שונה החל מחודש יולי אצל חברות שצריכות מעבדים לשרתים למכירת כמויות רציניות, והן נתקלות בבעיה שהן פשוט מתקשות להשיג מעבדי Xeon SP מכל הסוגים, החל מהברונזה ועד הפלטיניום. HPE הוציאה בחודש אוגוסט הודעה למשווקים שלה על כך. ההודעה, איך לאמר בעדינות – טיפה אופטימית מדי. הם מדברים על כך שתוך חודש חודשיים המצב ישתפר. הוא לא. הסיבה לכך פשוטה: אינטל מנסה על אותם פסי יצור ליצור את משפחת המעבדים החדשים לשרתים Cascade Lake SP (עם ליטוגרפיה של 14 ננומטר) והוצאתו ברבעון האחרון של השנה, Cooper Lake SP ברבעון האחרון של 2019 ו-ICE Lake SP ברבעון האחרון של 2020. את ה-Cascade Lake SP (למעט Cascade Lake AP שרוב החברות בארץ לא יצטרכו אותו בין כה, אלא אם הן צריכות פונקציונאליות FPGA במעבד) אי אפשר להכניס לשרתי HPE דור 10, התושבת אמנם תואמת אך הלוח וה-UEFI אם צריכם שינויים רציניים.

לכן, HPE מודיעה חגיגית למשווקים ללקוחות שרוצים להזמין עכשיו מעבדים, להציג את דגמי ה-DL325 ו-DL385. אלו הם השרתים עם מעבדי .. EPYC של AMD. מבחינת ביצועים, כל עוד אתם מריצים וירטואליזציה על הברזלים או קונטיינרים "על הברזל", הביצועים מעולים. אם אתם קונים למטרת HPC אז ה-EPYC יהיה טיפה יותר איטי בהשוואה למעבדי Xeon SP.

אני מאמין שהודעות פנימיות כאלו יוצאות גם אצל DELL ושאר יצרני השרתים, מכיוון שהבעיה לא יחודית ל-HP.

לכן ההמלצות שלי הן:

  • אם אתם צריכים את השרתים "עכשיו" (כלומר בחודשיים שלושה הקרובים) ואתם צריכים זאת למטרת הרצת מכונות וירטואליות או קונטיינרים – תסתכלו על ההצעות שמבוססות על EPYC. תוכלו לחסוך לא מעט כספים מבלי לאבד ביצועים. שימו לב – אם אתם משתמשים בוירטואליזציה המסחרית של Xen (של Citrix או Oracle) – ודאו כי אתם משתמשים בגירסה האחרונה.
  • אם אתם מתעקשים על מעבדי Xeon SP – תבקשו הצעת מחיר עדכנית, סביר להניח שהמחיר עלה, ולכן כדאי לשקול מה לקנות עם המחיר החדש.
  • אם אתם חושבים להמתין עד שנה הבאה, אל תזרקו את המפרט. דור 11 שיצא ברבעון האחרון אינו שונה כה מהותית מדור 10, והתוספות החדשות של Cascade Lake SP הן נחמדות (כמו NV-DIMM כ"סטורג'" שיושב היכן שנמצאות תושבות הזכרון) אבל רובן כרגע נתמכות רק על לינוקס וגם לא על הגרסאות הנוכחיות של ההפצות (RHEL 8, SLE 16).

לסיכום: יש חוסר במעבדים של אינטל ואף אחד לא יודע מתי זה יסתיים. אינטל מצידה רוצה "לדחוף" את המעבדים החדשים לדסקטופ ולשרתים בעוד מס' חודשים כך שלא הכי דחוף לה ליצור מעבדים מהסדרות הקיימות. זו הזדמנות לבחון אלטרנטיבות ולתעדף מה צריך לקנות כבר בקרוב ומה אפשר לדחות לשנה הבאה. בניגוד למחשבי דסקטופ שכאן בארץ יש מלאי מעבדים, בשרתים כל ההזמנות מנותבות לחו"ל (בשיטה של Tier 2 [נניח] מזמין מ-Tier 1 שמזמין מהיבואן, ששולח את ההזמנה לחו"ל, וההיפך כשהשרת מגיע ארצה).

על vSphere ועל החלפת שרתים

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

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

חברות רבות בארץ משתמשות בפלטפורמת vSphere כמענה ראשי לצרכי וירטואליזציה, ויש גם לא מעט כאלו שלאחר שמיקרוסופט הטיסה את מחירי רשיונות ה-Windows Server 2016 לשמיים – שמתעניינים לעבור לפלטפורמה זו. מבחינה טכנית, הפתרון של vSphere הוא פתרון מעולה, יש להם גם תמיכה מעולה, הם מוכרים שורה של מוצרים שמשתלבים יפה עם הפלטפורמה. מבחינת אבטחה ועדכוני אבטחה – ל-VMware יש רקורד די מרשים מבחינת מהירות שחרור עדכונים כך שהמלצה על פלטפורמת vSphere היא המלצה קלה שרוב חבריי היועצים ימליצו המלצה זהה.

אבל אחד הדברים שעדיין מתרחשים בארץ זה חוסר עדכון גרסאות. לא מעט מהחברות עדיין משתמשות בגירסאות 5.5 (הן מבחינת ESXI והן מבחינת vCenter) למרות שנשארו שבועיים בלבד לחיי התוכנה. ב-19 לחודש זה, המוצר "ימות" רשמית ולא יצאו לו כל עדכונים, גם לא עדכוני אבטחה קלים או קריטיים, ולכן חשוב לשדרג גירסה כמה שיותר מהר.

כאן מתקיים איזה משהו מוזר: חברות רבות שכן משתמשות בגירסה 6, אינן משדרגות לגירסה האחרונה (6.7) למרות שאין עלות נוספת מבחינת רשיון (אם כי יש צורך לשנות מספר סידורי – המספר הסריאלי שונה בין 6, 6.5 ו-6.7 ומספר של 6.0 לדוגמא לא יאפשר הפעלה של Schedule DRS על גירסה 6.5 ומעלה). כיום גירסה 6.7 היא גירסה בהחלט יציבה עם פונקציות רבות ותמיכה מתקדמת בדברים כמו NVME 1.3 (המאפשרת לקבל הרבה יותר מידע והתראות על SSD NVME) ודברים רבים נוספים.

וכאן מגיע עניין שדרוג שרתים.

בגירסה 6.7 של ESXI החליטו ב-VMWare להתחיל לנופף את גרזן התאימות אחורה. יש לך שרתים של HP מדור 6 לדוגמא או שרתים אחרים עם Xeon 55XX, Xeon 56xx, ויש עוד רשימה ארוכה של מעבדים שבהם גירסה 6.7 לא תעבוד. מדוע? אין לי גישה לקוד או ל-VMware עצמם, אך אני יכול לנחש שבשביל לתמוך בפונקציונאליות של ה-VT, כתבו ב-VMware הרבה קוד "בעייתי" שהם מתים להעיף, גם במחיר הסרת תאימות למעבדים מסויימים.

מטבע הדברים, מי שקורא את הרשימה ויש לו מעבדים ישנים המוזכרים ברשימה, יעדיף להתקין גירסה יותר ישנה של ESXi כמו 6.0 או 6.5. שם עדיין כמובן נשמרת התאימות.

אך זו, לעניות דעתי, החלטה אינה טובה, מכיוון שגירסה 6.0 נתמכת רק עוד שנה וחצי, ויש עוד נושא אחד חשוב…

PPW – או Performance Per Watt.

בעקרון, מעבדי Xeon נחלקים לדגמים מסויימים בכל גירסה: גירסת L הינה גירסה שצורכת הרבה פחות חשמל (אבל יש לה ביצועים נמוכים), ויש את גירסה E והיא הכי פופולרית (זה מה שבד"כ יצרן השרתים ימכור לך). למעבדים הישנים היתה גם גירסת X ששם מהירות המעבד היתה גבוהה, אבל צריכת החשמל היתה גבוהה בהתאם, פר מעבד.

אם נשווה מעבד Xeon ישן מסידרה 55XX (בלי ה-V) או 56XX בדגמים L או E, למעבדי Xeon E5 V4 לדוגמא (או למשפחה החדשה של ברונזה, כסף, זהב, פלטינום במעבדי Xeon-SP) נראה שצריכת החשמל היא כמעט אותה צריכה, רק שרמת הביצועים שונה לחלוטין. מעבד V4 או SP יתן ביצועים שנעים בין פי 3 ל-פי 10 (תלוי בפלטפורמה, תוכנה וכו') בהשוואה למעבדים הישנים. פלטפורמות כמו vSphere גם יודעות לנצל את הפונקציונאליות החדשה במעבדים כדי לתת HA יותר טוב ודברים נוספים (PCI Pass-through משופר, תמיכה יותר טובה ב-SR-IOV ועוד).

יוצא מכך, שאם תשקיעו חד פעמית בהחלפת השרתים, תוכלו לקבל הרבה יותר (יותר מכונות VM פר ברזל, תמיכה של יותר זכרון, תמיכה בציודים מודרניים ועוד) , וצריכת החשמל שלכם תישאר פחות או יותר אותו דבר (סביר להניח שזה יהיה פחות, המעבדים כיום יותר חכמים ומתחשבים יותר בצריכת חשמל, במיוחד מעבדי EPYC של AMD בוירטואליזציה). נכון, תצטרכו להקים Clusters חדשים (אחרת אין HA), אבל זהו דבר שקל לעשות והעברת מכונות VM בין השרתים הישנים לחדשים מצריכה בסך הכל חיבור ל-Datastore השונים, כיבוי המכונה הוירטואלית והפעלתה מחדש ב-Cluster החדש (יכול להיות שתצטרכו לשנות אולי גם את ה-Network אם חיברתם ל-VLAN אחר).

אישית אני יכול לאמר שאני מפעיל LAB ואני זה שמשלם את החשמל על ה-LAB ומצאתי שהחזקת שרתים ישנים והרצת מכונות VM עליהם פשוט אינה כדאית, במיוחד אם אני משווה את הביצועים וצריכת החשמל למעבדים מודרניים. בשבילי עדיף לי לקנות 2 מכונות עם מעבדי EPYC במקום הפעלה של 4 שרתים ישנים עם מעבדי Xeon 56XX. כך אוכל גם להשתמש ב-NVME, גם אוכל להכניס כרטיסי PCIe 3.0, וכך אוכל להנות מ-יותר ליבות פר מעבד וכל זאת מבלי להפריש עוד כספים לחברת החשמל. אני חושב שהגיון כזה יכול לפעול גם אצל חברות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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