על לאפטופים וטריקים מכוערים

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

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

אני משער שקהל גדול של משתמשי מק יאמר ש"לי יש אחריות עם Apple Care, אפל מתקנים לי ללא תשלום". אז תרשו לי להציג משהו.

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

רוצים לראות דוגמא? הסתכלו בקליפ הבא:

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

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

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

  • בארץ אצל יבואני מחשבים (או חברות שנותנות שרותי טכנאות עבורן אותן יבואניות) – בקושי משתמשים במלחם. בדרך כלל מחליפים את החלק כולו, ולכן הדבר הראשון שכדאי לבדוק לפני קניית דגם ספציפי של מחשב – זה לחפש צילום לוח אם שלו ולראות שה-SSD הוא שליף (בין בגירסת מקלון או בגירסת דיסק 2.5 אינטש). בלי זה – כל תקלה תבטיח שהמידע שיש לכם במחשב הנייד – אבד.
  • ודאו שניתן להרחיב זכרון במחשב. הזכרון במחשבים ניידים אינו ECC ויכולים לקרות בו תקלות, ושוב – אם הזכרון מולחם ולא ניתן לשלוף את ה-SSD – המידע שלכם יעלם.
  • אם אתם קונים כמות גדולה של מחשבים ניידים עבור משתמשים שונים בחברה, תנסו לקחת אחד מהם ולהריץ עליו עבודות ש"חונקות" את ה-CPU ובסיום העבודה תבדקו בעזרת מכשיר מודד חום את הטמפרטורות בצד הקדמי (היכן שהמקלדת). אם הטמפרטורה מגיעה ל-50+ מעלות, חפשו דגם אחר – ההגנות הטרמיות במחשבים ניידים מסויימים אינן אחידות ויכול להיות שרכיבים מסויימים ישרפו לאחר עבודה מאומצת כל פעם לאחר מספר חודשים.
  • תבדקו סקירות עצמאיות של המחשבים הניידים שאתם רוצים לרכוש, לא רק את ניירות השיווק של היבואן.

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

על ליבות, נימים, אינטל, 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 הקיימים בשוק).

דעה: כמה מילים על פרשת הריגול ו-Super Micro

עדכון בסוף הפוסט

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

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

כשאני מסתכל על עולם השרתים, אני מחלק אותם ל-2. רוב השרתים שנרכשים בישראל ובחברות Enterprise אמריקאיות רוכשים שרתים, הם רוכשים אותם מחברות כמו Dell, HPE, Cisco, Lenovo, Fujitsu ואצל האירופאים יש גם את Siemens, Huawai ועוד כמה. את כל אלו אני מכניס תחת קטגוריית "פתרון שרתים רגיל".

לעומת זאת, אצל חברות מחשוב ענן (גוגל, פייסבוק, אפל, אמזון, מיקרוסופט, אקמאי ועוד כמה) הכל שונה. בחברות רגילות ירכשו שרת בגודל 1U ובחברות ענן לא יהיה דבר כזה – יהיו לפחות 4 שרתים במארז 1U. אין ספק כח (או זוג ספקים) בכל שרת – הם פשוט יזרימו את המתח שצריך ישירות, פתרונות האוורור/קירור שונים, אין מתגים/סוויצ'ים של ג'וניפר, פורטיגייט, סיסקו ואחרים – אלא מתגים "תוצרת בית" מבוססי לינוקס שמשתמשים במעבד כמו של Avago בסוויצ' לעשות את העבודה + מעבד אינטל מהקצה הנמוך ללינוקס. אין סטורג' כמו NetApp או EMC ואין אחסון מקומי (למעט במכונות מסויימים ללקוח – אחסון שנמחק מיידית ברגע שהלקוח מסיים את העבודה עם המכונה) בשרתים. לא משתמשים בדיסקים ל-Enterprise בשום מצב (כי זה סתם מייקר את העלויות) ומה שהכי חשוב – בדרך כלל אצל ספק הענן מתכננים את כל הלוחות והדברים מוצאים החוצה לייצור (בכמויות של מינימום כמה אלפים, אחרת אין עיסקה). בד"כ מי שמייצר את הדברים הללו הם חברות כמו Super Micro, Compal, WyWinn ועוד מספר חברות סיניות או שהייצור שלהם בסין. רוב הטכנולוגיות והתוכניות ללוחות אם מופיעות תחת רשיון בקוד פתוח בפרויקט OCP שמשותף לכל ספק הענן. כמעט כל הטכנולוגיות הללו לא מופיעים אצל יצרני פתרונות שרתים רגילים מכל מיני סיבות (במיוחד רווח של היצרנים).

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

כפי שתיארתי לעיל, כמעט כל אותן חברות ענן מתכננות In House את הלוחות לשרתים ולשאר הציודים. הם מעבירים את התוכנית ליצרן, היצרן מעביר את הייצור לסין (כי בארה"ב ובשאר מקומות בעולם או שאין תשתית או שזה יקר מדי והלקוחות לא ממש רוצים לשלם פרמייה יקרה רק שזה ייוצר בארה"ב). בהתחלה מעבירים תוכנית לאב טיפוס (תהליך סופר יקר!) – חוזרים מס' לוחות בודדים עם הרכיבים ואותם לוחות עוברים בדיקות. במידה ויש בעיות, ייצרו שוב אב-טיפוס נוסף (וכמה אנשים יחטפו על הראש), הלוח המיוצר חוזר ללקוח, עובר בדיקות, ואם יש אישור QC מלא, מוציאים אישור הזמנה לכמה אלפי עותקים. כאן יכולה להיות בעיה שאף אחד מצד הלקוח לא בדק מה הרכיבים שיש והאם יש כל מיני דברים שנוספו (ואני בטוח שכבר 3 שנים החברות הללו הפיקו את הלקחים והם בודקים עם מיקרוסקופ).

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

האם חברת Super Micro ידעה לגבי העניין? אני מוכן להמר שלא, ואני מאמין שגופים כמו ה-CIA ואחרים שמשתמשים בענן המאובטח של אמזון, ה-GOV Cloud) שמקבלים דיווח על נסיון חדירה כזה והיו מוצאים שהנהלת Super Micro (שהיא חברה אמריקאית) – ההנהלה היתה ממזמן מבלה כבר בכלא, כך שסביר להניח שגופי הבטחון האמריקאיים חקרו ומצאו שלהנהלה האמריקאית לא היה מושג ירוק לגבי העניין.

עכשיו לגבי ה-So called "פריצה".

מכיוון שאף אחד לא פירסם איך אותו מיקרו שבב חובר ללוח האם ולאיזה שבב או רכיבים – קשה לדעת מה בדיוק תפקיד השבב, אבל אם יש משהו אחד (במיוחד ב-GOV Cloud ובעננים כמו באמזון) שאין בשרתים – זה גישה חופשית לאינטרנט. כל מי שהקים אי פעם VPC (חוץ מברירת המחדל) באמזון יודע שברירת מחדל – אין לך גישה לאינטרנט, וכך גם בשרתים עצמם – אין גישה לאינטרנט. כשאתה מקים Instance ואתה מריץ אפילו פקודת ping 8.8.8.8, אותו ping עובר דרך כמה שרתים וכמה ניתובים עד שהוא יוצא החוצה, ולשרת שמריץ את אותו VM אין מושג ירוק מהיכן זה יוצא – הוא מעביר את הבקשה ל-hop הבא ומשם זה ממשיך ובחזרה.

נמשיך: אותו מיקרו שבב לא יכל לעשות הרבה מהסיבה הפשוטה שכל ספק מריץ מערכת אחרת, מודולים שונים, ה-TCP/IP לפעמים מבוצע בשרת ולפעמים מבוצע בכלל כ-Offload על שבב יעודי בכרטיס הרשת. בנוסף, כשמדובר בלינוקס או VMWare, המודולים חתומים כך שכל נסיון שינוי שלהם יגרום להם פשוט לא לעלות. נוסיף על כך שבמכונות האלו אין UEFI שדרכו ניתן להיכנס (יש Core Boot, כל הספקים מספיק חכמים לזרוק את ה-UEFI המעפן לפח!) וגם המודולים של Core Boot חתומים, שינית? אין Boot לשרת.

בקיצור, בניגוד למצב של הרבה חברות שכמעט לכל מכונה יש גישה דרך סוויצ' ב-Firewall החוצה, אצל ספקי ענן אין את הדברים הללו, כך שעם כל הכבוד לנסיון הסיני, אני מאמין שהטריק הנבזי הזה נכשל (במיוחד בענן GOV Cloud ששם אין אינטרנט בשום מצב). מי שאכל אותה מזה היתה חברת Super Micro שהפסידה חוזים ולקוחות, ואישית, כאחד שמדי פעם משוחח עם החברה – זו אחת החברות שהכי כיף לעבוד איתם ולמצוא אצלם פתרונות שאין אצל אף אחד אחר בשוק החופשי (ואפשר להתכתב באנגלית מבלי לקבל תשובות באנגלית ברמה של כיתה ה').

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

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

על 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, כמות השינויים שיצטרכו כדי לעבור למערכת החדשה היא מאוד מינימלית.

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

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

לחברת אינטל יש בעיה שקיימת החל מסביבות יוני-יולי – כושר היצור של המעבדים הנוכחיים נפגע, ומדובר לא רק במעבדים לדסקטופ, אלא גם במעבדי 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, וכך אוכל להנות מ-יותר ליבות פר מעבד וכל זאת מבלי להפריש עוד כספים לחברת החשמל. אני חושב שהגיון כזה יכול לפעול גם אצל חברות.

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