יש לכם שרתים/סטורג' של HPE עם SAS SSD? מומלץ לקרוא

חברת HPE הוציאו לאחרונה עדכון דחוף לקושחות עבור מספר דיסקים SSD בחיבור SAS שנמצאים על מגוון הציוד ש-HPE מוכרת: שרתים (Proliant, Apollo), ועבור פתרוות אחסון: (JBOD D3xxx, D6xxx, D8xxx, MSA, StoreVirtual 4335,StoreVirtual 3200). דגמי הדיסקים וכל ההערות ולינקים לאפליקציות תיקון מופיעים במסמך ש-HPE פרסמה.

אני אפרסם בפוסט זה שתי גרסאות הסבר לגבי הבעיה, גירסה ראשונה היא פשוטה ומיועדת יותר להנהלה, הגירסה השניה מיועדת יותר לאנשים שמתחזקים ESXI ושרתי לינוקס (לא מכונות VM).

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

עקב באג בקושחת הבקר על דיסק ה-SSD, לאחר 32,768 שעות (כלומר 3 שנים, 270 יום, ו-8 שעות) כל הנתונים על דיסק ה-SSD יעלמו. זה לא "אם", לא "אולי", זה ודאי. מישהו כתב קוד די דבילי וזו התוצאה. התיקון עצמו משכתב קושחה חדשה לכונן ה-SSD ועל מנת שהקוד יפעל, יש צורך ב-Reboot למערכת (HPE כותבים שאין צורך לעשות Reboot, מהיכרות קודמת עם בקרי ה-Smart של HPE, אני ממליץ דווקא כן לעשות Reboot). התיקון הזה ימנע את ה-Time Bomb לכונני ה-SSD הנ"ל.

עכשיו הגירסה היותר "גיקית" לאנשים שצריכים לטפל בדברים. הדברים שאני כותב רלוונטיים למערכות VMWare ESXi ולהפצות לינוקס השונות (כרגע, רשמית, בלינוקס ההפצות הנתמכות הן RedHat, CentOS, SuSE, אם אתם עם אובונטו או דביאן, תצטרכו קצת להכיר את rpm2cpio).

מבחינה טכנית, לאחר הזמן הנ"ל (3 שנים, 270 יום, 8 שעות), מה שיקרה הוא שהמפות שהבקר משתמש בהם כדי לדעת היכן כל דבר מאוחסן, אלו תאים (Cells) דפוקים, אופטימיזציה וכו' – ימחקו. ה-DATA עדיין נשאר על שבבי ה-Flash, אבל בלי המפות אי אפשר לעשות כלום, אין כאן לצערי תהליך Rebuild שאפשר לעשות (טכנית, זה אפשרי, אם מלחימים JTAG ל-SSD ו"מדברים" ישירות עם הבקר SSD, אבל אז צריך להכיר את הבקר, פקודות, אסמבלר של ARM וכו' – והידע הזה לא קיים ציבורית).

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

  • בלינוקס קיים זמן רב שרות מובנה של עדכון קושחה מבלי שתצטרך לבדוק/לנחש איזה חומרה יש לך בתוך השרת. כל מה שצריך זה להתקין את חבילת fwupd מהפצת הלינוקס שלך, להריץ (כ-root) פקודה fwupdmgr get-updates ואת הפקודה fwupdmgr update והמערכת תוריד אוטומטית את הקושחות הרלוונטיות לשרת/מחשב שלך. כשתבצע Reboot הוא יפעיל אפליקציה דרך ה-UEFI שמעדכנת את הקושחות שצריך, וכשזה מסתיים, המערכת תבצע אוטומטית reboot ובכך העניין טופל. הבעיה? ב-HPE בקושי שולחים עדכוני קושחה לשרות הזה.
  • HPE מוציאים שני עדכונים שונים שמיועדים ל-SSD שונים. HPE כבר הוציאו אפליקציה בלינוקס מאוד ותיקה שיכולה לתשאל את בקר ה-SMART (היא נקראת: hpacucli) אלו דיסקים יש ובכך להשוות דגמים ולהתקין את הקושחה, אבל לא, הצורה שהם כתבו את סקריפט העדכונים תגרום לאנשי לינוקס ותיקים לרענן את קטלוג הקללות שלהם.

כך שקודם כל יש צורך לדעת אם יש לך דיסקים SSD שנכללים בעדכון קושחה הזו, ולכך יש 3 שיטות כדי לגלות זאת:

  • הראשונה – לתשאל את הבקר, וזה במקרה אם אתה מריץ לינוקס פיזית על השרת, פקודה כמו hpacucli ctrl slot=0 pd all show תציג לך את הדיסקים, דגם, מספר סידורי וכו', כאן grep ו-awk יכולים לעזור לך לעשות סדר ולמצוא את הנתונים.
  • השניה – לבצע reboot לשרת ולהיכנס לתפריט ה-SMART. שם מופיעים לך דגמי הדיסקים.
  • השלישית, קצת פחות מומלצת – ללכת לשרת, להוציא דיסק SSD החוצה ולהשוות את הדגם.

אם יש לך דיסקים שנכללים בעדכון, תצטרך לבחור להוריד את הסקריפט הרלוונטי, לעקוב אחרי ההוראות ולשלוח את העדכונים שיעברו דרך ה-SMART ישירות לבקר ה-SSD ויעדכנו אותו. האפשרות האחרת שיש זה להוריד SPP, להוריד את החבילות, לשים באיזו מכונת Windows או לזרוק הכל לדיסק און קי (לשים את החבילות תחת תיקיית packages/ ) ולהשתמש ב-SUM. זה כמובן אומר שתצטרך להשבית את המכונה עד שתעדכן את הקושחות באותם דיסקים.

חשוב לזכור: תהליך עדכון קושחת בקר SSD מבצע Reboot לאותו דיסק SSD (לא לשרת), ולכן יכולים "לקפוץ" לכם התראות על בעייתיות באותו דיסק SSD, עד שהמערכת "מבינה" שהדיסק תקין, קחו זאת בחשבון לפני שאתם נזעקים ממערכת ההתראות שלכם, ובגלל זה אני ממליץ במקרים שמדובר בשרת שמריץ ESXi לעשות את העדכונים לאחר שהעפתם ממנו (עם live migrate) את כל מכונות ה-VM ולאחר ה-Reboot לתת ל-DRS להזיז מכונות VM לשרת המעודכן (אם אין DRS, תזיזו ידנית).

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

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

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

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

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

סקירה: מיקרו שרת של HPE דור 10

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

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

נתחיל במפרט הטכני:

  • מעבדים – AMD Opteron (קיימים 3 דגמים: X3216, X3418, X3421). הדגם שמיובא לארץ הוא הדגם הנמוך עם מעבד X3216 עם 2 ליבות, 1 מגה זכרון מטמון, APU מובנה, ומבחינת כח – הוא הכי נמוך עם הספק של 12-15 וואט). שאר הדגמים הם עם 4 ליבות, 2 מגה זכרון מטמון, כח גרפי מעט יותר חזק, והספק של 12-35 וואט.
  • זכרון – עד 32 ג'יגהבייט (ECC).
  • אחסון: 4 דיסקים קשיחים בגודל 3.5 אינטש ללא תמיכה להחלפה חמה, ואפשרות להוסיף דיסק 2.5 אינטש בחיבור SATA (לצרכים של Boot או Cache עם SSD).
  • חיבור PCIe: ישנם 2 תושבות, הראשונה היא PCIe X8 והשניה היא PCIe X1 בחיבור של PCIe X4.
  • חיבורי רשת – 2 חיבורים של 1 ג'יגה עם LOM
  • חיבורי תצוגה – 2 חיבורי Display Port כולל תמיכה ברזולוציית 4K.
  • חיבורי USB – כ-2 חיבורי USB 2.0 ו-2 חיבורי USB 3.0.

נתחיל בקהל היעד: קהל היעד למכונה זו (בשימוש כ-NAS) הם אלו שמעוניינים ליצור לעצמם גיבויים – הן מבחינת תכנים שקיימים להם, גיבוי מכונות Windows או לינוקס. HPE רשמית ממליצה על מערכת הפעלה ClearOS שמתאימה ל-SMB/SOHO אבל כמובן כל מערכת הפעלה מודרנית תרוץ ללא בעיות על מכונה כזו. (שימו לב: המערכות שנמכרות בארץ עם X3216 יהיו איטיות בהרבה מ-2 האופציות האחרות ש-HPE מוכרת ולכן לא כדאי "להשתולל" עם התקנת שרותים רבים על המכונה).

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

מבחינת המעבד עצמו, HPE ו-AMD עשו בסופו של דבר עיסקה לא רעה בכלל: ל-AMD יש מלאי רציני של מעבדי Opteron ישנים שהם רוצים להיפטר מהם (לטובת ה-Ryzen V1000 ו-EPYC Embedded), ו-HP חיפשו מעבדים לשרתים בקצה הנמוך מאוד ובמחיר זול מאוד. AMD, לפי השמועות, מוכרים את המעבדים בכחמישית מהמחיר שאינטל מבקשת על אותו מפרט וה-Opteron (לפחות ה-X3421) נותן פייט די רציני למעבדי ה-Atom C3000 של אינטל. התוצאה: הלקוח מקבל מכונה עם ביצועים די מכובדים כ-NAS (שוב, לא הגירסה שנמכרת בארץ) במחיר מאוד נמוך של כמה מאות דולרים. אגב, אחד השימושים הכי מעניינים שיצא לי לשמוע עליו בשימוש מכונות כאלו, אגב, הם מקומות עם תקציב די קטן שמריצים קונטיינרים. לפחות מ-2 מקומות (בחו"ל) שמעתי שהם מרוצים מהתוצאות.

מבחינתי, הבעיה המרכזית במכונות הללו היא התכנון שלהם. ב-HPE יכלו לדוגמא לוותר על יציאת Display Port אחת ולהחליף את חיבורי הרשת הקבועים בחיבור של מודול, כך שהלקוח היה יכול להחליף בין 2 חיבורי 1 ג'יגה ל-2 חיבורי 10 ג'יגה, ובנוסף הם יכלו להוסיף ללוח האם כניסת M.2 PCIe X4. הוספת 2 הדברים הללו היו יכולים לשדרג מכונה כזו לביצועי NAS מכובדים מאוד, לשמש כ-Storage למספר קטן של מכונות פיזיות המריצות וירטואליזציה ועוד, אבל כנראה ש-HPE מעדיפים שאם אתה רוצה משהו עם ביצועים קצת יותר גבוהים – תכיר את המכונות שלנו שמבוססות Xeon SP או AMD EPYC – שהן כמובן הרבה הרבה יותר יקרות.

לסיכום: האם הייתי ממליץ לאחרים לרכוש את המכונה הזו? כן, אם הצרכים שלהם הם מה שציינתי לעיל. אם הם צריכים משהו יותר חזק, אז עדיף שיחפשו את הגירסה עם מעבד X3421 או שיחפש פתרון NAS אחר או שיבנה לעצמו NAS. אישית, אני מקווה בזמן הקרוב לבחון לוח אם חדש (שעדיין לא יצא – מחברת ASRock Rack) המבוסס על מעבד EPYC Embedded ושתומך בהרבה יותר דיסקים קשיחים, יש בו כניסת M.2, תושבת PCIe X16 ו-2 כניסות 10 ג'יגהביט מובנות – ואת זה להכניס למארז 2U.

ההבדל בין קוד פתוח למוצר מסחרי מבוסס קוד פתוח

לפני מספר חודשים פרסמתי בכמה מקומות סקירה מקוצרת על פרויקט של Red Hat שנקרא oVirt. הפרויקט הזה הוא בעצם ה"תשובה" של Red Hat לכל אלו שמחפשים מוצר וירטואליזציה כ-Hyper Converge. המערכת כוללת בפנים פתרון סטורג', רשת וכמובן Compute ויש בה עוד חלקים שלמוצרים מתחרים יש תשובות חלקיות.

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

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

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

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

הנקודה השניה החשובה היא כמאמר הפתגם "יותר משהעגל רוצה לינוק, הפרה רוצה להניק". כל יצרני השרתים מוכרים את המוצרים המסחריים מבוססי הקוד הפתוח כולל תמיכה מלאה 24/7, כלומר אם מחר תרצה לרכוש שרתים מ-HPE או DELL או LENOVO ותרצה לרכוש פתרון אחסון SDS, פתרון קונטיינרים כמו OpenShift המסחרי, פתרון סטורג' Scale Out כמו Ceph או Gluster או מוצר ענק כמו SAP HANA – הם ימכרו ויתמכו בך כולל SLA מלא ואז אינך תלוי באם חץ בן חמו זמין או אם יש מישהו אחר שיתן לך תמיכה. אתה מקבל תמיכה מלאה בדיוק כמו שאתה מקבל תמיכה לברזלים שלך. ליצרן יש תמיכת "גב אל גב" עם יצרן התוכנה. דוגמא פשוטה לחובבי מיקרוסופט ו-Azure – אם יש לך הפצת לינוקס מותקנת על VM ב-Azure ויש לך בעיה, אתה פונה לתמיכת Azure והם מנסים לפתור. לא מצליחים? יש להם קו ישיר ליצרן ההפצה שיעזור להם ולך לפתור את הבעיה.

לסיכום: כמו שאתה קונה מתגי תקשורת של Cisco, כמו שאתה קונה מערכת מורכבת כמו JIRA, כך גם עם מוצרים מסחריים מבוססי קוד פתוח. החברה שמוכרת לך את זה, בין אם יצרן התוכנה או יצרן הברזלים – אתה מקבל שרות מלא הכולל התקנה, הטמעה, תמיכה וכו' לפי SLA שנקבע בין הצדדים. זה ש-HP מעדיפים למכור סטורג' 3PAR שלהם או DELL מוכרים סטורג' כמו UNITY, לא אומר שזה הדבר היחיד שהם מוכרים. יש להם עוד מוצרים, אתה פשוט צריך לבקש את זה במסגרת ההזמנה ואין שום הבדל בתמיכה/התקנה/הטמעה בין אם קנית לדוגמא סטורג' קנייני או פתרון סטורג' SDS, בין אם קנית פתרון מבוסס קוד פתוח או פתרון סגור לחלוטין. יש כמובן את הפרויקטים בקוד פתוח שהם אינם מוצר מסחרי ואתה חוסך את הקניה איתם, אבל שם המסלול הוא שונה והוא יותר קשור בחברות ועצמאים פה בארץ שיכולים לתת לך שרות על כך, ולכן כדאי להבדיל בין הדברים.

Exit mobile version