המודלים הפיננסיים החדשים לשרתים

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

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

אם נלך לפי אחוזים ונבדוק כמה סטארט-אפים שקיבלו מעבדכם הנאמן שרות יעוץ – רכשו ציוד בסוף, נגיע למספר מפתיע: 90% לא רכשו בכלל חומרה (למעט לאפטופים, מתג כלשהו, VPN, תקשורת DATA) ומי שכן רכש, היה סטארט-אפ אחד שפיתח כלי סייבר שהתעקש על ציוד On prem. שימו לב: אני לא מדבר על מצב שלא רכשו דרכי, אלא לא רכשו כלל שרתים, סטורג' וכו'.

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

אם ישנה טעות אחת גדולה שעשו כל יצרני השרתים הפופולריים (Dell/HPE/Cisco/Lenovo) – הטעות תהיה ההתעלמות המוחלטת מהמעבר של לקוחות לשימוש ב-סע"צ. יצרני השרתים לא יכולים למכור שום ציוד לסע"צ כי סע"צ בונה ורוכש חלקים, כך שעלות ה-BOM לשרת אצל סע"צ היא מחצית ומטה ממה שיצרן שרתים מבקש. אז למי אפשר למכור? לעסקים קטנים עד גדולים, אולם אלו עוברים לענן ומקבלים משהו שהם לא מקבלים משום יצרן.

כפי שתיארתי לעיל, כל הסטארט-אפים שקיבלו מימון מ-VC קיבלו קרדיטים לשימוש אצל סע"צ. עם הקרדיטים הללו אותם סטארט-אפים יכולים להקים תשתית וירטואלית והכסף יכול להספיק בניהול נכון למשך 12-18 חודשים מבלי שהסטארט-אפ יצטרך להוציא סנט. לעומת זאת, כשסטארט-אפ צריך לרכוש ברזלים, הוא צריך לשלם Up Front (תשלום אחד או יותר, לא ממש משנה). מהרגע שסטארט-אפ משתמש בקרדיטים ומקים את התשתית ועוברת שנה – הסיכוי שאותו סטארט-אפ יזרוק את כל התשתית הוירטואלית ויעבור לתשתית On prem היא אפסית.

וכך מגיע מצב שחברה כמו Dell ראתה ברבעון האחרון איך המכירות שלה עלו בהשוואה לרבעון הקודם ב-2%, אולם בהשוואה לשנה הקודמת, נרשמה ירידה של 12%. המצב אינו מעודד אצל אף יצרן שרתים. ככל שעסקים וסטארט-אפים עוברים להשתמש בתשתית ובשרותים של סע"צ, הסיכוי שהם ירכשו שרתים/סטורג'/סוויצ'ים וכו' יורד במהירות. המצב ב-Dell אינו יחודי, אותו דבר מתרחש גם ב-HPE (הנה קישור)גם ב-Cisco (קישור) וכן, גם ב-לנובו (קישור). הסיפור חוזר על עצמו באותן חברות: או ירידה במכירות, או שגרף המכירות "שטוח" עם אזהרות מההנהלות השונות שהמצב לא הולך להשתפר כרגע. שימו לב שהמספרים מתייחסים למכירות כוללות – כלומר גם ממכירות ישירות וגם מכירות ממפיצים, תיכף אתייחס לכך.

ואז היצרנים החלו לעשות "חושבים" איך להתחרות ב-סעצ"ים והראשונה שהכריזה על שינוי היתה חברת HPE שהכריזה כי החל מ-2022 כל הברזלים (שרתים, סטורג', רשתות וכו'), תוכנות ושרותים יהיו זמינים כ-Subscription. שלשום הכריזה חברת Dell על משהו דומה שנקרא Dell On Demand. אני מאמין שיצרנים מתחרים יכריזו בקרוב על שרותים מתחרים חופפים. המכנה המשותף לכולם: שרות שמתחרה באמזון ובמיקרוסופט.

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

אפשרויות התשלום שהזכרתי לעיל ישארו, אולם יתווספו אופציות חדשות, כשהמכנה המשותף באופציות החדשות היא שניהול השרת (מבחינת OS, עדכונים, תקלות מתבצע על ידי יצרן השרת מרחוק ולא על ידך) והאופציות החדשות הן:

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

כל יצרן יממש את הדברים האלו בצורה שהוא יחליט אולם לפי מה שידוע לי משיחות עם מהנדסים (כלל חשוב: אם אתה רוצה לדעת דברים אמיתיים על יצרן, דבר עם מהנדס שעובד בחברה, לא עם איש מכירות/הנהלה) – הדברים יבוצעו דרך ה-ILO עם License Manager או בחיבור ישיר מרחוק לשרת (תלוי בתקשורת, כמות שרתים וכו') וב-Dell דרך iDRAC מעודכן. כך, אם אתה מנסה להתחמק מתשלום או שכרטיס האשראי/אמצעי תשלום לא פעיל, החברה יכולה לנתק (תקשורת) את השרת מרחוק, לחסום Boot/UEFI עם סיסמא וכו' וכו'.

האם שיטות מכירה אלו יעבדו? אני לא בטוח מהסיבות הבאות:

  • כשאתה משלם על תשתית וירטואלית ל-סע"צ, התשלום שלך כולל חשמל,  קירור, תחזוקה וכו'. כאן אתה עדיין ממשיך לשלם על חשמל וקירור ועל אנשי סיסטם שכבר עובדים אצלך, כך שלא בטוח שזה שווה.
  • חברות גדולות כבר רגילות לעניין התשלום Up Front. לא בטוח שהם יאהבו את השיטות החדשות.
  • הנהלות רבות יתהו – אם כבר משלמים כל חודש, מדוע לא לקחת שרותים אצל סע"צ? (למעט מקרים שחייבים את התשתית On Prem עקב Latency וכו')

ולבסוף – הנקודה הישראלית: תשאל יבואנים או מפיצים, וכולם כיום יאמרו לך ששרותים אלו לא יהיו זמינים בישראל. זה נכון? בשלב הנוכחי כאן, אבל בעתיד הקרוב לא בגלל סיבה פשוטה: היצרנים רוצים להרוויח מכל סוג מכירה שיש, כך שזה לא יהיה מוגבל לארה"ב (בשום מסמך, לא של HPE ולא של Dell שאני ראיתי – לא נכתב ששרותי ה-Subscription/On Demand לא כתוב, למיטב ידיעתי, שזה יהיה מוגבל לארה"ב). אני מאמין שיצרני השרתים יציגו חוזים חדשים שבהם המפיצים מקבלים עמלה מופחתת אם הלקוח לוקח On Demand, אבל המפיץ ממשיך לקבל כספים שנגבים מהלקוח – באופן שוטף חודשי, כך שיהיה מצב שגם בשביל מפיצים זה יהיה שווה לקדם שרותי Subscription/On Demand. בשלב זה, כפי שציינתי – זה לא זמין בארץ.

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

מעבדי EPYC דור שני – סקירה

אני רוצה לפתוח את הפוסט עם סיפור קצר "מאחורי הקלעים".

תכננתי זמן רב לכתוב את הפוסט הזה ולשחרר אותו היום (לאחר שהסתיים האמברגו אתמול) על המעבדים החדשים של AMD לשרתים, מעבדי EPYC דור שני (סידרה 7002) ולהשוות אותם למעבדים הנוכחיים של אינטל שמגיעים עם עד 56 ליבות במעבד. מהנדסי אינטל עשו עבודה מצויינת והמעבדים עם 40 או 56 ליבות יכולים לתת "פייט" מצוין למעבדי EPYC דור שני של AMD, אבל קרה מה שקורה לפעמים בחברות גדולות – בהנהלה באינטל "נפתח התאבון" והם החליטו שמעבדים בסידרה 92XX יהיו שונים פיזית ממעבדי Xeon Scalable האחרים. אם תיקחו מעבד כזה ותהפכו אותו, לא תמצאו פינים או ריבועי זהב קטנטנים. אתם תמצאו כדורים או מה שנקרא בשפה המקצועית BGA (כלומר Ball Grid Array), ובמילים אחרות – המעבדים הללו חייבים להיות מולחמים ללוח אם. בנוסף, אינטל החליטו שיצרן המעוניין לרכוש מעבדים כאלו ומעוניין לשלב אותם בשרתים – יצטרך גם לרכוש מאינטל עוד כמה שבבים והם מחוייבים להיות מוטמעים בשרתים ומה לעשות – אותם שבבים מתחרים בדיוק במה שהיצרנים מוכרים מבחינת ניהול – iDrac, iLO וכו'.

כך שכיום – גם אם יש לכם כסף, מערכות X86 הכוללים מעבדים עם יותר מ-28 ליבות –  לא תוכלו לרכוש כי אף יצרן לא מוכן לתנאים הללו. באינטל הבינו את השגיאה הפטאלית רק לפני מס' חודשים והיא תתוקן ב-2020 עם המשפחה החדשה Ice Lake AP.

בקיצור – AMD צריכים לשלוח פרחים ואולי עוגה עם שלט גדול של "תודה" לאינטל.

המעבדים החדשים של AMD – סידרה 7002 הם מעבדים שרבים מאוד בתעשיות השונות חיכו להם. מעבדי EPYC דור ראשון (סידרה 7001) היוו כניסה מחדש של AMD לתחום השרתים לאחר ש-AMD שחררה לפני יותר מעשור את מעבדי ה-Opteron שהיו מאכזבים בכל תחום למעט המחיר ואינטל לא היו צריכים להתאמץ יותר מדי בכדי לכבוש 99% מהשוק מאז 2006. ל-AMD לא היו שום פתרונות עם שהם פיתחו את ארכיטקטורת ZEN וגם כש-AMD הוציאו את ה-EPYC דור ראשון, לאותם מעבדים היה יתרון בהרצת מכונות וירטואליות, פתרונות VDI וקונטיינרים, אבל כשזה מגיע להרצת אפליקציות גדולות ופלטפורמות פיתוח על כל המעבדים בשרת (ללא וירטואליזציה) – אינטל ניצחה מבחינת ביצועים כמעט בכל קטגוריה.

בדור שני של ארכיטקטורת ZEN, ה-ZEN-2, הפיקו ב-AMD לקחים רבים ובאותה הזדמנות החליטו לשנות הכל. ה-EPYC סידרה 7002 זו ארכיטקטורה שונה לחלוטין מהדור הראשון, לא רק בתוספות ש-AMD הוסיפו, אלא גם בתכנון עצמו. בדור הראשון של EPYC היו בעצם 4 מעבדים שיצרו תצורת NUMA שהצריכו הגדרות וכיוונונים שונים על מנת לקבל ביצועים טובים וגם אז – היה Latency לא קטן עקב התצורה. בדור השני לעומת זאת, ישנו Chiplet מרכזי גדול (כפי שאתם יכולים לראות בתמונה לעיל) שאחראי לכל ה-I/O וכל שבבי הליבות "מדברים" דרכו בלבד, מה שחוסך בצורה ניכרת את ה-Latency. ככלל, תצורת המעבדים הללו (כמו גם מעבדי ה-Ryzen ש-AMD שחררו ומעבדי ה-Threadripper שישוחררו כנראה בחודש הבא) היא תצורה חדשה ושונה לחלוטין ממה שאינטל מתכננים ומייצרים מעבדים – וזה גם הכיוון שאינטל יעברו אליו במהלך השנה שנתיים הקרובות. חברה קטנה כמו AMD מקדימה את אינטל הענקית. כמה מרענן לראות זאת.

כפי שכתבתי, יצרניות רבות של שרתים, ספקי הענן הציבורי, יצרנים תעשייתיים של ציוד לשרתים וכו' חיכו ל-EPYC החדש מהסיבה הפשוטה שסוף סוף אפשר להתחיל מאפס עם טכנולוגיות יותר מתקדמות ממה שאינטל מציעה. עם 128 נתיבי PCIe אפשר לבנות דברים מדהימים ללא צורך ברכיבי מיתוג סופר-יקרים ליצרן (שמגלגל זאת כמובן ללקוח הסופי), אפשר להשתמש בזכרון יותר מהיר (3200 מגהרץ), אפשר לקבל תקשורת יותר מהירה כי כמעט כל תושבות ה-PCIe הם PCIe 4.0 עם רוחב פס של 16 ג'יגהבייט לשניה (כפול מ-PCIe 3.0), אפשר להכניס הרבה יותר דיסקים SSD NVME (לנובו בהחלט "משתוללים" בקטע הזה עם השרתים מבוססי EPYC שהם מציעים החל משבוע הבא. צפו בוידאו הזה), יש מעבדים עם עד 64 ליבות, יש זכרון מסמון בגודל 256 מגהבייט, ועוד ועוד. מי שרוצה את "רשימת המכולת" מוזמן לעיין בפוסט הארוך ש-STH שחררו כאן.

להלן טבלה שמראה את ההבדלים בין הדור השני של Xeon Scalable מבית אינטל ל-EPYC דור שני מבית AMD:

אחת השאלות שכמובן מיד עולה היא: איך הביצועים? וכאן AMD מפתיעה. ברוב מוחלט של המבחנים מעבדי ה-EPYC פשוט עוקפים את המעבדים בקצה הגבוה (28 ליבות) של אינטל עם 50-90% ביצועים יותר מהירים, גם כשלאינטל יש יתרון כמו AVX512 – מעבדי EPYC עוקפים זאת (ע"י שימוש ברוחב פס כפול לתעבורת פקודות) ובמילים אחרים – לא חשוב מה ה-Work Load שאתה צריך להריץ, אם אתה חושב לרכוש ברזלים חדשים או לקחת Instances אצל ספק ענן ציבורי – כדאי מאוד להסתכל על מכונות המכילות את מעבדי EPYC החדשים. אגב, מיקרוסופט וגוגל הכריזו כי ניתן כבר מהיום לשכור Instances מבוססי EPYC דור שני. באמזון אם הבנתי נכון, זה יוצע בחודש הבא.

ומה בנוגע למחיר?

ובכן, בקצה הגבוה של מעבדי אינטל מהסידרה 9200 (כן, אלו שאי אפשר לרכוש כרגע מהיצרנים הפופולריים) אינטל דורשת לבלב, ריאה או משכנתא קטנה. מעבד בקצה הכי גבוה – Xeon 9282 עם 56 ליבות, מתחיל במחיר של $25000 (המחיר כמובן הוא לא מחיר ללקוח סופי, אלא ליצרן שרתים, אז המספר יעלה). לעומת זאת, המעבד בקצה הכי גבוה של AMD, ה-EPYC 7742 עם 64 ליבות עולה פחות משליש – ב-AMD מסתפקים ב-$6950.

ככלל, המשוואה ש-AMD מציעה היא פשוטה: תחליט כמה ליבות פר מעבד אתה צריך במעבדים של המתחרים. יש לך מספר? יפה. תוסיף בערך 100-150$ ותקבל כמות ליבות כפולה ובאותה הזדמנות יש מצב שלא תצטרך שרת עם 2 מעבדים אם אתה רוכש מעבד מבוסס EPYC דור שני.

יתרון גדול נוסף ללקוח הסופי הוא מבחינת רישוי. AMD מציעה לך מעבדים עם עד 64 ליבות ואם אתה משתמש בוירטואליזציה של VMWare, אז אתה חוסך 50% פר שרת במחיר הרישוי.

מבחינת זמינות שרתים לרכישה, אלו השרתים הזמינים כיום ובקרוב. חשוב לשים לב אלו מעבדים אתם בוחרים, המעבדים החדשים מתחילים במספר 77 ומסתיימים ב-2. לדוגמא: 7742.

  • HPE – מציעים את ה-DL325, DL385 ו-Apollo 35. את השרתים הללו ניתן לרכוש כבר כיום עם מעבדי EPYC דור ראשון או שני (יש תאימות אחורה). HPE הכריזו כי במהלך 2019-2020 הם יוציאו עוד 9 דגמים של שרתים מבוססי EPYC דור שני. השרתים המוצעים כיום הם עם PCIe 3.0 ולא עם PCIe 4.0.
  • DELL מציעים את שרתי R7425, R7415, R6415. את כל השרתים הללו ניתן לרכוש עם מעבדים דור קודם או נוכחי. בחודש ספטמבר DELL יציגו שרתים חדשים ובמהלך השנה הבאה יוצגו עוד 6 שרתים מבוססי EPYC דור שני.
  • LENOVO מציעים את SR635 ו-SR655. לנובו הם היחידים שמציעים החל משבוע הבא שרתים עם לוח אם שתוכנן מאפס למעבדי דור EPYC דור שני. גם לנובו יציעו החל מתחילת הבאה עוד מספר דגמי שרתים מבוססי EPYC דור שני.
  • Supermicro – החברה מציעה כרגע 4 שרתים דור 12 (H12) שניתן לראות כאן (נכון לכתיבת שורות אלו יש להם כמה בעיות באתר) כאשר Supermicro דוחפת יותר לכיוון ה-Twin (כלומר 2 שרתים במארז 2U).
  • Gigabyte – החברה החליטה להוציא לא פחות מ-13 שרתים מבוססי EPYC דור שני (די מדהים, בהתחשב שבדור הקודם של EPYC היו לחברה .. רק 2 שרתים להציע). אתם יכולים לראות את הרשימה כולה כאן.
  • TYAN (יש להם נציג בארץ?) – מציגים 6 שרתים ו-2 לוחות אם (לבנייה ואינטגרציה). הרשימה – כאן.
  • ASUS – בעת כתיבת שורות אלו, החברה הכריזה על שרתים חדשים (E10) ולוחות אם מבוססי EPYC דור שני. האתר עצמו עדיין לא מכיל את רשימת השרתים, סביר להניח שזה יעודכן היום או מחר.

לסיכום: אם אתם הולכים לרכוש שרתים בקרוב, סביר להניח שתיתקלו בשם "EPYC" מכאן ועד הודעה חדשה מצד כל יצרן שרתים. מבחינת ביצועים – מדובר בשיפור מאוד שנותן ביצועים יותר גבוהים בהשוואה למה שאינטל נותנת ומבחינת המחיר, מדובר בהנחה משמעותית מאוד בהשוואה לכל ה-SKU של אינטל. לאינטל יש מענה למעבדים הללו, אבל המענה (Ice Lake לשרתים) יצא רק בשנה הבאה – בערך באותו זמן ש-AMD תוציא את EPYC דור שלישי (Milan).

עכשיו אחרי ש-AMD הוציאו את EPYC, החברה הולכת לשחרר כנראה בחודש הבא את Threadripper דור שלישי שיהיה שונה משמעותית מהדורות הקודמים והוא מיועד לתחנות עבודה ועל כך אכתוב בפוסט אחר.

למעוניינים, להלן כמה קטעי וידאו שיכולים לעניין אתכם מבחינת ביצועים:

הראשון – מבחן ביצועים VMMark של VMWare:

השני – קונטיינרים (מבוססי Docker):

בקשר למחירי שרתים

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

בסופו של דבר מישהו מאותה חברה יצר קשר עם עבדכם הנאמן. אני שאלתי רק שאלה אחת: האם במקרה המעבד הוא Xeon מהסידרה Silver, Gold או Platinum? התשובה היתה חיובית. הסברתי לבחור שלצערי ב-2 הדורות האחרונים של Xeon Scalable באינטל פשוט התעצלו לבנות מנגנון אחיזה (Retension) רציני למעבד והפעם צריך להסתדר עם ברגים בלבד, כאשר אם יש תנועה של אפילו חצי מילימטר – מקבלים את התופעות שהם מקבלים, ובקיצור – צריך לחזור לשולחן התכנונים, לחשוב על מעבד אחר ולשנות עוד כמה דברים.

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

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

נניח לשם הדוגמא שבמקום אותה חברה לעיל, פונה חברת משאיות אמריקאית שמבקשת ממני לבנות מערכת כזו. לאחר שתכננתי ובניתי את ה-POC, הייתי יכול להיכנס לאתר של אחד מיצרניות השרתים, לבצע custom ובסופו של דבר האתר מציג לי מחיר רשמי, גם אם ה-fulfillment יבוצע ע"י חברות אחרות כמו CDW – המחיר שמופיע זה מה שאני צריך רשמית לשלם. אני כמובן מכאן יכול ליצור קשר ולהוריד את המחיר אם מדובר בכמות שרתים, או בגלל דברים אחרים שאני רוצה מאותה חברה ובתנאי שמחיר הברזלים ירד. הדבר החשוב ביותר לי: יש לי מחיר התחלה לשם מו"מ.

בישראל לעומת זאת, ככל שזה מגיע לשרתים, מחשבים אישיים וכו' – אין חיה כזו. שום יבואן רשמי לא מוכן לפרסם את המחיר הרשמי ללקוח הסופי. אני יכול לפנות לדוגמא ל CData, One, CDLog, הראל ואחרים ולקבל עבור אותו מפרט הצעות מחיר שונות (וכמובן בדרך לחכות בין יומיים לחודש וחצי להצעת מחיר!) עם הבדלים של אלפי (או עשרות אלפי – תלוי במפרט) שקלים בין הצעה אחת לאחרת. במילים אחרות: אם לדוגמא שרת DELL עם מפרט משלי עולה בארה"ב 10,000 דולר ובארץ אותו שרת עם אותו מפרט היה עולה 17,000 דולר מחיר רשמי, לא תהיה לי בעיה עם זה (זה לא אני זה שמשלם את המחיר, זה הלקוח), אבל כשאני רואה שתי הצעות מחיר שונות עם הבדל של 6000 שקל לדוגמא, אני פשוט תוהה – על מה ההבדל? על זה שנציג מכירות הוציא כמה אימיילים וישב 5 דקות מול אקסל? (כי למעט המשלוח השרת ללקוח וההתקנה הסופר ראשונית – הכל נעשה ע"י היצרן בכלל).

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

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

על תכנון מפרט שרתים

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

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

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

יש לא מעט אנשים בתחום הגדרות ומכירת שרתים שלא ממש מעודכנים בטכנולוגיות שנמצאים בתוך השרתים. ניקח לדוגמא את תחום הזכרון: השרתים הנמכרים כיום אצל רוב המשווקים – מבוססים על Xeon SP של אינטל או EPYC של AMD. ב-EPYC הדברים מאוד פשוטים: יש לכל מעבד 8 ערוצי זכרון לכל מעבד, ואם אתה רוצה את הביצועים המקסימליים שהמעבד יכול לתת, אתה פשוט קונה זכרון לכל הערוצים. כך לדוגמא אם אתה רוצה 256 ג'יגהבייט לשרת עם מעבד אחד, אתה פשוט קונה 8 מקלות SDRAM ECC מיצרן השרת, כשכל DIMM הוא בגודל 32 ג'יגהבייט.

באינטל המצב שונה. בעבר למעבדי Xeon היו 3 ערוצי זכרון וכל ערוץ זכרון הצריך 3 מקלות DIMM זהים, כך שעל מנת לקבל ניצול מקסימלי של ביצועי מעבד/זכרון, היית צריך להכניס 9 מקלות DIMM. רוצה לדוגמא להכניס 128 ג'יגהבייט זכרון למעבד? שדרג טיפה ל-144 ג'יגה זכרון ורכוש 9 מקלות של 16 ג'יגהבייט זכרון. כיום המצב שונה במעט, ולכל מעבד Xeon SP יש 2 בקרי זכרון, עם 6 ערוצים לכל מעבד. כל ערוץ מחובר ל-2 מקלות DIMM ויש דרכים שונות לקבל Balanced Memory. למי שמעוניין, המסמך הזה מ-LENOVO מסביר את הדברים בהרחבה (וההסבר מתאים לכל שרת מבוסס Xeon SP, לא חשוב מי היצרן).

גם בגיזרת הדיסקים דברים משתנים. לא מעט אנשי IT היו מריצים תוכנות מדידה שונות למשך יום יומיים כדי לקבל מצב ולהחליט אם לרכוש דיסקים SSD שהם Read Intensive או Mixed Intensive. אני חולק על השיטה הזו הואיל והיא לא יכולה לקחת בחשבון צרכים עתידיים, וההפתעה הכי גדולה שאני מבשר לאנשי IT – ההבדלים בין Read ל-Mixed מבחינת מחיר – צנחו. אם לדוגמא תשוו דיסק SSD של מיקרון או אינטל או סמסונג שהוא Read Intensive לדיסק SSD כמו PM883 של סמסונג (שנמכר ע"י כל יצרני השרתים, אגב, עם תמיכה מלאה ו-SLA) הוא 100-120$ כשאנחנו מדברים על גודל דיסק SSD זהה, וחיבור SATA. אז אם לדוגמא אתם רוכשים לשרת 5 דיסקים, האם הפרש של 500-600$ בעלות הכוללת של השרת, זה מה שישבור את הדיל?

תחום נוסף הוא חיבוריות לרשת. לא מעט חברות עוברות ל-10 ג'יגה ובמקרים רבים מתקבלת החלטה לחבר את השרת ב-teaming של זוג בשיטת חיבור Active/Passive, כך שאם חיבור אחד נופל, חיבור שני ימשיך לעבוד. צר לי, זה לא יעבוד אם מחברים את זה לאותו כרטיס או ללוח האם מסיבה פשוטה: בכרטיס או לוח האם יש מעבד אחד ואם יש בו תקלה, אף אחד מהחיבורים לא יעבוד. זה כן יכול לעבוד אם לדוגמא סיב נפגם, אבל על מנת לכסות את מקסימום האפשרויות לתקלות, תצטרכו 2 כרטיסי רשת נפרדים ולחבר אותם ב-Teaming.

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

  • בישראל אין חנות Online לאף יצרן שרתים ואתם גם לא תקבלו את מלוא הקטלוג של חלקי החומרה שהיצרן מייצר/משווק, לכן אני ממליץ להיכנס לחנות Online בחו"ל, ו"לבנות" את השרת שלכם. המחיר כמובן אינו כמו המחיר שתשלמו בישראל, אבל תוכלו לראות בדיוק את האפשרויות שיש לכם במקום לסמוך על איש שיווק שבמקרים רבים לא יודע על מה הוא סח (מבלי לפגוע במישהו).
  • תכננו את הזכרון באופן אופטימלי, אך תשדלו לא לרכוש דברים שלא תוכלו להשתמש בהם מאוחר יותר בעת שדרוג, כמו מקלות זכרון של 4 ג'יגהבייט.
  • אם אתם מתכננים פרויקט שהשרתים יבצעו בו עבודת Scale Out, יהיה עדיף לרכוש מספר מצומצם יותר של שרתים "חזקים" מאשר כמות גדולה יותר של שרתים "חלשים". הסיבה לכך פשוטה: יותר תחזוקה, יותר עלות של חשמל, תופס יותר מקום. אז במקום 20 שרתים חלשים, 10 חזקים יעשו את העבודה ויחסכו את הדברים שציינתי לעיל.
  • מעבדים: כיום המצב הוא שבאותו מחיר שאתם רוכשים מעבד אינטל עם 4 ליבות, אתם יכולים לרכוש EPYC של AMD עם 8 ליבות. לא עדיף לקבל יותר באותו מחיר? (ולא, אל תתנו למסמכי השיווק של אינטל לבלבל אתכם, במקרים רבים הנתונים מעוותים/מוטים).
  • דיסקים: לכו על Mixed ותחסכו לעצמכם הפתעות עתידיות. ההבדל במחיר אינו כה משמעותי.
  • רשת: עדיף 2 כרטיסי רשת מאשר לחבר לאחד עם 2-4 חיבורים לשם שרידות.
  • VDI: למי שלא מודע, nVidia כעת גובה על ה-Grid שלהם תשלום חודשי. הגיע הזמן שתכירו את ה-Fire Pro של AMD שעובד מצוין על VMWare, Citrix, Microsoft – שם לא תשלמו חודשי.

 

טיפ: כשרוצים להוסיף דיסקים SSD מקומיים בשרת

בעולם השרתים, יש סוג מסוים שמיועד לאינטגרטורים ולא ללקוחות קצה. הקטגוריה של השרתים הללו נקראת "שרתי Tier 1".

בניגוד לשרתים רגילים שרוכשים מ-HP/לנובו/DELL ששם אתם מקבלים שרות מהקצה עד הקצה, בשרתי Tier 1 אתה מקבל אפס תמיכה טכנית (הדבר היחיד שכן מוכנים לעשות עבורך הוא להחליף ציוד תקול) והתשובה הקבועה שתקבל מהתמיכה הטכנית היא משהו כמו: זה שרת Tier-1, אין תמיכה טכנית, כך שאם מישהו רוצה לרכוש שרת כזה, עדיף שיכיר היטב איך לזהות חולשות ובעיות תכנוניות של לוח אם, איוורור, נתיבי PCIe מבחינה לוגית (לא רק פיזית) ועוד, אחרת בקלות אפשר לרכוש "פיל לבן". כך לדוגמא השרת בתמונה למעלה היה אמור להירכש על ידי חברה מסויימת בארץ – למטרת הקמת "סטורג'" מאוד מהיר (כל הדיסקים שנכנסים מקדימה הם SSD NVME בלבד). הם פנו לכל מיני אינטגרטורים שנתנו המלצה חיובית לרכישה ואז הם פנו אל עבדכם הנאמן דרך בלוג זה והמלצתי היתה שלא לרכוש מהסיבות הבאות:

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

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

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

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

טכנית, אני ממליץ לרכוש מיצרן השרת דיסקים SSD מבוססי SATA ולא SAS מכיוון ש-SATA Enterprise עבר כברת דרך ארוכה באמינות, ויתרון הערוץ הכפול לא רלוונטי בשרתים מודרניים הואיל ובקר ה-RAID הראשי מוטמע בלוח האם, כך שאם יש תקלה, השרת מושבת בכל מקרה. מבחינת ביצועים – כיום SATA עוקף SAS (ב-SSD).

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

יש לכם כבר 8 ורוצים להוסיף עוד? סביר להניח שתצטרכו בנוסף לדיסקים SSD לרכוש "Extension Kit" לשרת עצמו. אצל חלק מהיצרנים מדובר על מספר כבלים וכרטיס SAS Expander שאותו יש לחבר אל כניסות בקר ה-RAID ומה-SAS Expander לחבר את כל הכבלים אל ה-Backplane. יש מקרים שאתם תצטרכו לעשות זאת ויש מקרים שטכנאי מטעם היצרן יבוא ויעשה זאת (תלוי בחוזה שלכם מול יצרן השרתים). אם מדובר לעומת זאת בשרת ישן (נניח G7/G8 של HPE או R710/R720 של DELL או M2/M3 של IBM) – תהיה לכם בעיה כלשהי, ההסבר לגביה – בהמשך הפוסט.

יהיו מקרים, כמובן, שבחברה מסויימת ירצו להרחיב מעבר ל-16 דיסקים. במקרים כאלו בדרך כלל היצרן ימכור ללקוח כרטיס SAS Expander בערך כמו שיש פה בתמונה משמאל שמאפשר חיבור של 24 דיסקים. מבחינת חיבוריות – אין שום בעיה לחבר את הכל כמו במקרה של הרחבה מ-8 ל-16.

הבעיה – צוואר בקבוק.כמעט כל בקר RAID, בין אם מדובר בכרטיס ובין אם מדובר בשבב שנמצא על לוח האם, תופס 8 נתיבי PCIe (כלומר PCIe X8) ו-PCIe 3.0 X8 (שנמצאים בשרתים מודרניים) יכול להעביר ברוטו עד 8 ג'יגהבייט (קצת פחות בפועל). אם נזכור ש-SSD כשקורא נתונים – מעביר אותם במהירות של 450-550 מגהבייט לשניה, ונכפיל את זה כפול כמות ה-SSD בשרת (אני לא ממליץ על RAID-5 כמו שכתבתי לעיל, אבל מי באמת מקשיב?) – ואנחנו יכולים להגיע למצב שבקר ה-RAID "יחנק" עוד במצב של 16 דיסקים. אם כל הדיסקים (24) מחוברים ל-RAID והמערכת מוגדרת כ-RAID-5 על כל הדיסקים – הביצועים פשוט יצנחו בכל מה שקשור לקריאת נתונים. המצב חמור יותר בשרתים ישנים ששם בקר ה-RAID משתמש ב-PCIe 2.0 X8 שאז יש מחצית מרוחב הפס והבקר "יחנק" מ-8 דיסקים SSD אם המערכת קוראת וכותבת מכל הדיסקים במקביל.

לכן – אם מתעקשים להכניס לדוגמא 24 דיסקים SSD בשרת אחד (או בשרת ישן לעבוד עם יותר מ-8 דיסקים SSD), יש לשקול את האפשרויות הבאות:

  • להוסיף בקר RAID עם 2 כניסות SFF 8087 ולחבר אליו את ה-8 דיסקים SSD (אחרי 16). בשרתים ישנים אפשר לרכוש 2 בקרי RAID עם 2 כניסות SFF 8087 ולחבר אליהם את הדיסקים. החסרון בשיטה זו: אין RAID "המשכי" לכל הדיסקים, אבל גם לכך יש פתרון, המשיכו לקרוא.
  • לעצור ב-16 דיסקים.
  • לרכוש במקום בקר RAID – כרטיסי HBA (או כרטיס RAID במצב IT MODE) ולהקים RAID מבוסס תוכנה (כל מערכת הפעלה מאפשרת זאת, ויש גם תוכנות יעודיות לכך כמו FreeNAS, UnRaid, XPEnology ועוד). שימו לב – החלפת בקרים אינה דבר מומלץ ואינו נתמך רשמית על ידי יצרני השרתים.
  • לפצל לשרתים נפרדים. 2 שרתים עם 8 דיסקים SSD יתנו עבודה יותר מהירה.

לסיכום: זה שיש 24 מקומות לדיסקים SSD בשרת, לא אומר שהשרת באמת בנוי להפעיל 24 דיסקים SSD (ובשרתים ישנים – יותר מ-8 SSD במקביל, גם אם מדובר בבקר עם 4 כניסות SFF-8087), בדיוק כמו שרוב מוחלט של השרתים שנמכרים לחברות לא יכולים להפעיל 24 דיסקים SSD NVME (אל תנסו. תכנון הקירור, גם בדגמים הכי חדשים של DELL/HPE/לנובו לא מתאים לכך). עדיף לחלק את הדיסקים בין 2 מכונות פיזיות, ואם אתם מתעקשים "להפציץ" מכונה אחת בדיסקים SSD – עדיף לייעד אותה לשימוש כ-NAS עם מפרט נמוך ולהריץ את הדברים הדורשים ביצועים בשרת אחר.

תחום ה-VDI וענן – עדכון מצב

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

על מנת להבין את הבעיה, נתחיל בהתחלה הפשוטה: כל ספקי הענן ישמחו לאפשר לך לשכור מכונה (Instance או VM) מבוססת Windows, בין אם מדובר על Windows Server 2012, 2016 או אפילו 2019. אין שום בעיה. רוצה משהו כמו Windows 10 או גירסה מתחת? תשכח מזה. ספקית ענן כמו אמזון שמחה להציע משהו "דומה ל-Windows 10" לדוגמא. מה שתקבל בעצם זה Windows Server 2016 ששינו לו מספר גדול של ערכים ב-Registry, שהותקן עליו Windows Experience וגם מספר אפליקציות בסיסיות. יש גם את חבילת ה"פלוס" שכוללת אופיס, אבל אז אתה משלם תוספת שכוללת תשלום חודשי למיקרוסופט לא רק על ה-OS, אלא גם על ה-Office שמותקן ב-Instance. למכונה כזו אתה יכול להתחבר עם כלים שונים שמתאימים לכל מערכת הפעלה קיימת, כולל סלולרי/טאבלט/כרומבוק וכו'.

אז מדוע אף אחד לא מציע מכונה מבוססת Windows 10? אחרי הכל, שרות שידע להקים מכונה כזו מ-אפס או אפילו לקחת Sysprep שלך ו"להלביש" אותו על ה-OS זה לא משהו כזה מסובך לכתוב…

הבעיה מגיעה מכיוון רדמונד. מיקרוסופט לא רוצה (ולפעמים גם נלחמת באמצעים משפטיים) ששום ספק יציע שרות כזה, ולא חשוב אם מדובר בספק ענן ענק, או בחברת Hosting פצפונת. מבחינת מיקרוסופט, המוצרים היחידים מבחינת OS המוצעים לספקי Hosting וענן כאחד – הם אלו הכלולים תחת רשיון SPLA בהם הספק משלם למיקרוסופט כל חודש על רשיונות ה-Windows Servers (וכלים אחרים) ואת המחיר הוא מגלגל על הלקוח. במסגרת הדברים המוצעים ב-SPLA, אין שום הצעה/שורה למערכת דסקטופ כלשהי, ולא חשוב אם מדובר בגירסת Home או Enterprise.

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

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

וכאן נשאלת השאלה שכולם ירצו לדעת: האם זה שווה פיננסית? ניקח דוגמא: ראובן, CTO של חברה גדולה מעוניין לזרוק/לגרוט את כל ה-800 דסקטופים של החברה. להתקין לכולם Thin Client (ואלו שמחוץ לחברה ישתמשו בתוכנת Client יעודית או בדפדפן) ופשוט לעבוד בענן. אם מחר ראובן היה שוכר את שרותי היעוץ שעבדכם הנאמן מציע – מה הייתי אומר לו?

כל מי שהרים מערכת VDI יודע שיש בעצם 2 אפשרויות, ברמת המאקרו: הראשונה היא "לפרסם" אפליקציות ולהתחבר דרך מערכת מרוכזת אחת ולקבל בעצם (לאחר אותנטיקציה) את תצוגת האפליקציה ללא כל הדסקטופ "מסביב", והאפשרות השניה היא בעצם "Pool" של מכונות וירטואליות הכוללות מערכת הפעלה עם האפליקציות הדרושות, וכשהמשתמש מתחבר, הוא מקבל בעצם VM עם הדסקטופ כשאליו מקושר הפרופיל של המשתמש.

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

בקיצור: אם ספקי הענן יציעו שרות של מכונות וירטואליות עם Windows 10 כ-שרות VDI והם יגבו כמו שהם גובים כיום על Instances, המחיר הכולל פשוט לא יהיה שווה מכיוון שעלויות התקשורת יהיו אסטרונומיות. החברות יצטרכו להציע חבילות Bundle הכוללות מספר טרהבייט תעבורה בחודש עם שרות VDI.

לסיכום: VDI בענן במחשבה ראשונה יכול להישמע רעיון לא רע, אבל כשמתחילים לחשוב על העלויות של Instances ובמיוחד העלויות של תקשורת בין הענן אל המשתמשים בארגון, ואם מוסיפים לכך ענייני רגולציה ובעיות תקשורת עקב כך שהכתובות IP אינן ישראליות – הרעיון כרגע אינו שווה כל כך פיננסית. אם לעומת זאת ספקי הענן יתנו חבילות תקשורת עם מחיר טוב בכל הקשור לתעבורת VDI וניתן יהיה לקשר כתובות IP ישראליות מספק מקומי אל ספק הענן (כמו שרות BYOIP שאמזון מציעים) – יכול להיות שזה יהיה משתלם. האם ניתן יהיה להעביר הכל לענן? לא. כל דבר שמצריך VPN לא ניתן יהיה להעביר (מכיוון שמשתמשים בתקשורת אל ה-VM ש"נופלת" ברגע שיש שכבת VPN, ובמקרים של VPN כמו של סיסקו המערכת פשוט לא נותנת להתחבר) ויש כמובן את המכונות המקומיות שקשורות לכל מיני ציודים שיש בהם צורך מקומית (GPU, תקשורת לסטורג' מקומי וכו').

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

עדכון מערכות לינוקס ו-Windows ממקום אחד

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

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

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

האם יש פתרון טוב לכך?

כן, ל-SuSE יש פתרון: SuSE Manager

תוכנת SuSE Manager מאפשרת מספר דברים:

  • לעדכן הפצות לינוקס חופשיות (CentOS, Scientific Linux, OpenSuSE, Fedora, Ubuntu)
  • לעדכן הפצות לינוקס מסחריות (Red Hat, Oracle Linux, SuSE SLE)
  • להתממשק ל-SCOM כך שניתן יהיה לעדכן את הפצות הלינוקס ישירות דרך ה-SCOM
  • לנטר את כל המערכות המבוססות לינוקס.
  • לבצע Provision ולהתקין לינוקס על מכונות פיזיות ווירטואליות (בשימוש AutoYast/Kickstart)
  • ועוד

כך שבשימוש SuSE Manager, אפשר להתקין עדכונים וחבילות ישירות דרך המערכת למכונת לינוקס אחת, לקבוצה או לכולן.

התוכנה היא תוכנה מסחרית (בתשלום) וניתן לרכוש אותה עם תמיכה בארץ. חשוב לזכור: עדכון הפצות לינוקס מחייב מנוי להפצת לינוקס המסחרית. SuSE Manager לא מאפשר להתחמק מכך.

ומה עם אלו שמעוניינים במשהו חופשי?

SuSE Manager ו-Red Hat Satellite מבוססות על תוכנה בשם Spacewalk, כאשר SuSE ו-רד-האט מוסיפים הרחבות משלהם, כך ש-Spacewalk לדוגמא לא מתממשק ל-SCOM ולא יאפשר עדכון מרוכז של מכונות לינוקס ו-Windows כך שניתן לעדכן רק מכונות לינוקס.

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

סטטוס וירטואליזציה מבוססת קוד פתוח – סוף 2018

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

מי שהולך לכנסים והרצאות של חברות שונות ושל ספקי ענן שונים, שומע בוודאי איך חברה X או חברה Y עברו לענן, הם מרוצים עד השמיים והכל ורוד ומאושר. המציאות, לפחות משיחה עם חברים פרילאנסרים שמבצעים אינטגרציות או מעברים לפלטפורמות שונות – קצת שונה. כן, ישנן חברות שמעבירות חלק מהמכונות VM שלהן לענן, חלקן מעיפות מכונות VM ומשתמשות בשרתי ענן שונים (כ-PaaS), אבל לא יצא לי להכיר שום חברה עם כמה אלפי מכונות VM בארץ שבסופו של דבר השביתה את ה-DC שלה והעבירה הכל מהכל לענן. ככלל, הויכוחים על העלויות השונות בטווח הזמן הקצר והארוך (בתוספת כמה מילות Buzz) גורמים ללא מעט חברות להאט מעבר לענן, לבצע Hybrid מדוד מאוד, והיו כמובן לא מעט מקרים שפשוט "חזרו הביתה" (אם כי זה לא סופי. מי שחושב שאין בתחום ה-IT מקרים שמקבלים החלטה X ואחר כך מבטלים ואחר כך שוב חוזרים – מוזמן להתעורר).

אני מודה שעד לאחרונה כל עניין הוירטואליזציה בקוד פתוח לא ממש תפס אחוז גדול בתחום ההטמעות ב-Enterprise. כמעט כולם הולכים ל-VMware, חברות שכמעט כל התשתית שלהם מבוססת מיקרוסופט משתמשים ב-Hyper-V ואלו שרוצים Hyper Converged הולכים על Nutanix או Simplivity. אחרי הכל – למוצרים האלו יש תמיכה, יש בארץ אינטגרטורים, לא צריך לקנות מחו"ל רשיונות, יצרני החומרה מאשרים שהמוצרים עובדים עם הברזלים. בקיצור, סבבה אגוזים.

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

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

בפוסט זה אציג, כמו בפוסטים קודמים – 3 מערכות (Proxmox, oVirt/RHV, OpenStack) ולמי הם מתאימים ומה השוני שלהם.

נתחיל במערכת שמתאימה יותר לחברה קטנה או ל-LAB מקומי: Proxmox.

תוכנת Proxmox מתאימה ליישומי וירטואליזציה הן על מערכות ישנות (כן, אותו שרת G7 של HP שיושב שם בצד) והן על מערכות חדשות. המערכת עצמה היא יחסית קלה ללימוד, ומי שעבד על ESXi עם vCenter בצורה לא מקצועית (כלומר לא עבר קורסים והכשרות של VMware) יוכל להקים תוך דקות ספורות מכונות וירטואליות על דיסקים מקומיים, לחבר NFS או iSCSI וגם להשתמש ב-HA ולבצע Live Migration (כל עוד יש אחסון משותף, זו לפחות הדרך המומלצת). בקיצור -אם אתם צריכים להקים מערכת וירטואליזציה על מספר קטן של שרתים, ללא הקמה של רשתות וירטואליות מורכבות או דברים הרבה יותר מורכבים (DVSwitch?) – אז Proxmox יכול להתאים למשימה.

המערכת הבאה יותר מתאימה לחברות שמריצות מערכות וירטואליזציה מורכבות עם רשתות וירטואליות שונות (המערכת משתמשת ב-Open Virtual Network ו-Open vSwitch, וכן רשתות SDN), סטורג'ים בפרוטוקולים שונים, חיבור ל-OpenStack, ודברים נוספים. המערכת היא oVirt. טכנית, oVirt נבנתה מגירסה 4 להריץ מערכות גדולות וכשאני מציין גדולות, אני מדבר על אלפי ועשרות אלפי מכונות וירטואליות. בשעה שפתרונות כמו ProxMox מתרכזים ב-Bridge Networking, מערכת oVirt תומכת במספר פתרונות רשתות וירטואליות, והיא בין המערכות היחידות שתומכות גם בפלטפורמות שאינן X86-64 כמו מערכות Power ו-S390 של IBM. מבחינת HA, היא בין המערכות המובילות בדיקות ברמת חומרה (דרך ILO/IMM/IDRAC) מה קורה לברזל והיא יודעת להעביר את ה-VM אם יש תקלה ולטפל בשרתים פיזיים בעייתיים – החל מהקמה של חדשים, שדרוג קיימים ועוד. מערכת oVirt מבוססת על מערכת KVM האחרונה (כן, אותה חברה שמפתחת את oVirt היא אותה חברה שמפתחת את KVM – זו רד-האט) כך שיש תמיכה בציודים וירטואליים חדשים, מערכות UEFI וירטואליות מודרניות ועוד), התממשקות ל-VCenter, המרה יעילה של מכונות וירטואליות ל-oVirt, תמיכה ב-AD/LDAP ועוד שורה ארוכה של פונקציות. בהשוואה ל-Proxmox, מערכת oVirt היא מפלצת ולכן היא פחות מתאימה לרוץ על שרתים עם מכונות וירטואליות שמאוחסנות על דיסקים מקומיים. oVirt, אגב, מגיעה מוכנה לשימוש הן כשרת שיתחבר לסטורג' והן כ-Hyper Converged.

oVirt מתאימה להטמעות גדולות הן כ-PoC והן כפרודקשן כל עוד יש בחברה ידע פנימי (או יועץ חיצוני) שיכול לתת תמיכה. מנהלים שמנוסים עם VMWare או Hyper-V ואינם מנוסים מספיק או בעלי ידע רציני בלינוקס יתקשו בניהול מערכת כזו ללא השקעה בלימוד הדברים, והסיבה לכך פשוטה: oVirt אינה מנסה להיות העתק של VMware והדגש של oVirt הוא יותר על פונקציונאליות מאשר חזותיות (אם כי חל שיפור ניכר בחלק הזה בגירסה 4.2 ובגירסה 4.3 שתצא במהלך 2019). חברות שמעוניינות במוצר ארוז ובתמיכה רשמית עם רשיונות – ניתן לרכוש את מוצר ה-RHV עם תמיכה.

ומכאן – למפלצת הגדולה: OpenStack.

אם oVirt היא מערכת גדולה, OpenStack היא גודזילה לכל דבר ועניין. ההבדל הגדול בין oVirt ל-OpenStack הוא ש-OpenStack מנסה לתת לך הכל מהכל. וירטואליזציה? יש. קונטיינרים? יש את Zun שמאפשר להריץ קונטיינרים כ-שרות. DB כ-שרות? יש. אחסון תואם S3? יש. אחסון Images ודברים אחרים? יש. צריך Load Balancer? תכיר את Octavia, ויש עוד עשרות חלקים. עם oVirt לעומת זאת – המיקוד הוא לכיוון מתן שרותי וירטואליזציה והשרותים מסביב, לא יותר מכך.

המטרה של OpenStack היא לתת לחברה להקים ענן פרטי, רק שבניגוד לדרכים ישנות יותר שבהם היינו מקימים מערכות VM מבוססות לינוקס ריקות ועליהן היינו מקימים כל מיני שרותים – כאן המערכת מוקמת על הברזלים עם השרותים שאתה צריך ואז אפשר להשתמש בשרותים כדי להקים מה שרוצים – מכונות וירטואליות, קונטיינרים, שרותים וכו'. חשוב לזכור: מערכת OpenStack היא מערכת מאוד מורכבת, ומחייבת שיהיה בחברה ידע פנימי רציני בלינוקס, SQL, פייתון, BASH וכו' (בלא מעט מקרים כדי לאבחן תקלה או כדי לטפל בתקלה,  העבודה נעשית מול Shell ולאו דווקא מול ה-GUI) ומאוד מומלץ יועץ חיצוני צמוד ל-OpenStack.

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

ומה העתיד?

פתרונות הוירטואליזציה ממשיכים להתקדם, גם הפתרונות המסחריים הסגורים אך גם הפתרונות מבוססי הקוד הפתוח. ב-VMWare הכריזו בכנס האחרון על ESXI ל-ARM, פלטפורמה שנכנסת יותר ויותר לספקי הענן הציבורי ו"זוחלת" לכיוון ה-Enterprise (תסתכלו על Ampere). פתרון הוירטואליזציה KVM ו-QEMU (שבהם כל מערכת בנייה כמו Yocto משתמשות) יש תמיכה בעשרות מעבדי ARM כבר 6 שנים ומעלה, מערכת OpenStack תומכת ב-ARM, ו-oVirt תתמוך כנראה בגירסה הבאה (אם לא תהיה גירסה כזו, אני כנראה בשנה הבאה ארכוש שרת ARM ואבצע BUILD לכך. מהנדסי רד-האט ישראל – תתכוננו להצקות ממני 🙂 ). עוד ארכיטקטורה שהולכת להיתמך היא מעבדים זולים מבוססי MIPS החדשים.

מבחינת תקשורת – רשתות 100, 200 ו-400 ג'יגה יהפכו לאט לאט לנורמה והמתגים עצמם יהיו מבוססים שבב מרכזי קנייני ושבב ARM שמריץ לינוקס, ומי שינהל את המתג – זו מערכת הוירטואליזציה (דרך הלינוקס שרץ על המתג).

מבחינת אחסון: ישנו תהליך יחסית די חדש שיכנס לאט דרך יצרני ה-SSD והוא "העפה" של מערכת הבקר מה-SSD כך שמערכת הוירטואליזציה תחליט איך לנהל את ה-SSD, איך לבצע Garbage Collection לפי העומסים במכונה, לפי המכונות הוירטואליות שירוצו ועוד. אינטל גם תוציא את ה-Optane DC Persistent Memory – מקלות אחסון שיושבים היכן שמקלות הזכרון יושבים, מכילים הרבה יותר אחסון ממקלות זכרון ECC רגילים ועם ביצועים קרובים לביצועי זכרון. תמיכה לכך ב-OpenStack תהיה קיימת בקרוב (להלן השקפים), רק שמחכים למעבדים ושרתים מבוססי Cannon Lake SP.
עוד תחום אחסון שיקבל Boost רציני בוירטואליזציה הוא NVMEoF שיתן Latency מאוד נמוך.

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

אם יש לכם שאלות לגבי המוצרים, אתם מוזמנים ליצור קשר.

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

הבעיות של 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 ותקבלו את הביצועים שביקשתם.