אחסון: על דחיסה, Dedup וטריקים שיווקיים

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

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

אתאר סיטואציה: חברה רוצה לרכוש פתרון אחסון אחר ממה שיש לה כיום. בדרך כלל אנשי המכירות של חברות/מפיצים שונים ישאלו כמה נטו אחסון אתה מחפש, האם אתה מחפש All Flash או שילוב של דיסקים מכניים ודיסקים SSD שישמשו כ-Cache ועוד מספר שאלות. עד פה הכל טוב ויפה.

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

נושא ה-Dedup הוא נושא מורכב. ברמת המאקרו, Dedup זו פונקציה בסטורג' שסורקת את הבלוקים באחסון, מוצאת אלו בלוקים נמצאים יותר מפעם אחת, ומשנה את הרישום כך שאם יש לנו 10 בלוקים זהים, בלוק אחד ישאר באחסון ו-9 אחרים יקבלו הפניה (reference) לאותו בלוק, ובכך מקבלים במקרה הזה Dedup ביחס של 10:1. מכיוון שסטורג' מכיל תכנים רבים ושונים, יחס ה-Dedup משתנה בהתאם לתוכן ובד"כ יופיע יחס dedup משוקלל. תהליך ה-dedup בדרך כלל רץ מחוץ לשעות העבודה, בחלק מהפתרונות הוא "יחנוק" את משאבי העיבוד ובחלק מהפתרונות התהליך יתפוס רק כמות קטנה של זכרון ועיבוד (כמו ב-vSAN – שם התהליך תופס עד 5% ממשאבי העיבוד). אחד הדברים הראשונים שצריך לדעת כבעל הסטורג', הוא שאתה לא יכול לקבוע את יחס ה-Dedup. זה נקבע בהתאם למה שמאוחסן בסטורג' – ברמת בלוק, ווליום וכו'. (שוב, זהו תאור ברמת מאקרו).

לדוגמא: נניח ויש מערכת של VMWare ואנחנו יוצרים 3 templates של מערכות הפעלה שונות: Windows 10, Windows Server 2016, Centos 7.7. אחרי שיש לנו את ה-Templates אנחנו מקימים 10 מכונות VM מכל מערכת הפעלה, כלומר יש לנו עכשיו 30 מכונות VM – ונעצור. אם נריץ Dedup עכשיו, עוד לפני שניכנס לכל VM ונתקין אפליקציות שונות, נריץ תהליך Dedup ונקבל מספר משוקלל ל-Dedup של 10:1 ואם כל תהליך ה-Dedup ירוץ בשלמותו, אנחנו נחסוך מקום רב, אולם ברגע שנתקין אפליקציות שונות על כל VM עם הגדרות ותהליכים שונים, יחס ה-Dedup (לכשנריץ את התהליך שוב) ירד מכיוון שה-DATA שונה בין VM אחד לשני, גם כשמדובר באותן מערכות הפעלה. בגלל זה, Dedup זה דבר מעולה כשמקימים פתרון VDI – לא צריך פתרון אחסון מפלצתי.

דחיסה (Compression) לעומת זאת היא תהליך שמבוצע בצורה שונה בכל מיני פתרונות אחסון. בחלקם זה נעשה ברמת Block ובחלקם ברמת קבצים. שוב, ברמת המאקרו – המערכת לוקחת בלוק ומנסה לדחוס אותו דחיסת Lossless (כלומר שאין איבוד נתונים). אם המערכת מצליחה לבצע יחס דחיסה טוב (אם נניח גודל הבלוק הוא 128 קילובייט והיא מצליחה לדחוס אותו ל-40K) הוא ישמר כך ויפרס מחדש בכל פעם שנקרא נתונים ממנו. אם לעומת זאת, יחס הדחיסה נמוך, המערכת תעדיף כדי להשאיר ביצועים גבוהים – לא לדחוס את אותו בלוק.

אם יש לכם חצי שעה פנויה, דני הרניק ממרכז המחקר ב-IBM חיפה נתן הרצאה בנושא, ואני ממליץ לראות אותה:

כשזה מגיע לפתרון HCI כמו vSAN – הדברים שונים. כשמפעילים דחיסה ו-Dedup ב-vSAN, המערכת תבצע זאת בזמן שהיא מעבירה נתונים מהדיסק Cache לדיסקים המסומנים כ-Capacity ואפשר לקרוא על כך כאן. על מנת לחשב נכונה כמה דיסקים תצטרכו, אתם יכולים להשתמש במחשבון הזה (הוא מצריך רישום באתר VMWare). חשוב לקחת בחשבון דברים כמו Slack Space (זהו שטח האחסון שאינו מיועד לשמירת מכונות VM אלא ל-Snapshots ודברים אחרים ש-vSAN צריך – בדרך כלל מומלץ בערך על 25% מהשטח ברוטו). יש את המחשבון הזה שהוא הרבה יותר פשוט ומתאים יותר כדי לחשב אחסון בלבד (אל תתייחסו למחיר, הוא מיועד למי שרוצה לרכוש את ה-Appliance).

אחד הדברים החשובים כשזה מגיע לרכישה – זה שאתה מקבל את הדיסקים במחיר מופחת כחלק מחבילת האחסון שאתה רוכש. כלומר אם נניח דיסק SSD עולה $1000, סביר להניח שאיש המכירות יוריד את המחיר ל-900 או 800 דולר. לעומת זאת, אם תחזור לאותו נציג יצרן ותבקש לרכוש ממנו נניח עוד דיסקים, אתה תשלם פר דיסק יותר. נניח 1200-1400$, ולכן ההמלצה שלי היא לרכוש את כמות הדיסקים שאתה צריך כדי להגיע לכמות האחסון נטו מבלי להתייחס ל-Dedup Ratio ולדחיסה. אותו Dedup ו-Compression יעזרו לך בדחיית הרכישת דיסקים הבאה (כפי שציינתי – אני מאמין שהם יעלו לך יותר). אם תלך הפוך ותכניס מראש יחס Dedup בחישוב כמות הדיסקים שאתה מזמין ושבמציאות אולי לא תגיע אליה, תקבל בעצם כמות מופחתת של אחסון.

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

בהצלחה.

עננים ציבוריים מקומיים מול עננים ציבוריים אמיתיים

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

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

נדמיין עתה מצב תיאורתי שבו החלטתי להתחרות בכולם. אני משיג VC נחמדים ומשכנע אותם להשקיע בעסק שלי סכום נחמד של 8 ספרות (בדולרים). אני רוכש כמה עשרות ארונות, מפזר אותם בין ספקי האינטרנט השונים בארץ, "מפוצץ" את כולם בשרתים חדשים ואני מקים בדרך SDN ו-Software defined storage מפלצתי. על כל התשתית הזו אני מקים מערכת שתתן ללקוחות דרך ממשק WEB ודרך API את השרותים הבאים:

וירטואליזציה, קונטיינרים (עצמאית, ללא צורך בהקמת מכונות וירטואליות), Serverless, הקמת "ברזלים" יעודיים ללקוח, שרותי Object Storage ו-Block Storage, שרותי NFS/CIFS יעודיים לרשת שלך בלבד, שרות רשת פרטית משלך (כמו VPC), שרותי Load Balancer, שרותי DNS, שרותי identity, שרותי Imaging למכונות VM שלך, שרותי אורקסטרציה, שרותי Messaging, שרותי התראות, שמירת משאבים וחלוקתם על ידי הלקוח, אורקסטרציית קונטיינרים, ביג דאטה, שירותי גיבוי, שחזור ו-DR, תאימות ל-EC2 (כפרוקסי), מטריקות, ניטור מלא של הכל, שרותי Event (כמו Cloud trail), שרותי Governance ושרות יחודי של Benchmarks, וכמובן – שרותי Billing ו-Chargeback – וכל זה זמין ביום הראשון. תירשם, תכניס פרטי כרטיס אשראי וצא לדרך.

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

ספקי ענן מקומיים, בניגוד לספקי ענן ציבוריים גדולים – יכולים להציע כמות מוגבלת מאוד של שרותים, ובנוסף – לא יהיה לכם מושג מה תקבלו מבחינת ביצועים (לא מאמינים? קחו את החוזה מול הספק שלכם, חפשו את המילים CPU Pinning או התחייבות לגבי ביצועי Compute, סטורג' וכו'. אני מאמין שלא תמצאו את זה מוזכר במסמכים). טכנית, אם ניקח לדוגמא שרת עם 16 ליבות, אין שום מגבלה שיכולה למנוע הרצה של מכונה וירטואלית עם 32 ליבות. אתה כלקוח יכול לבדוק אם זה מה שאתה מקבל אם תריץ אפליקציית Benchmark כלשהי שוב ושוב במשך כמה ימים ותוציא את הפלט לקובץ ואז תוכל להשוות .. ולהתעצבן.

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

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

לסיכום, אני ממליץ לחשוב על 2 דברים חשובים:

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

כמה מילים על חברות תוכנה ומשחקים באש

כל מי שמכיר כיום את שוק התוכנה בארץ, יודע שיש המון חברות תוכנה שונות בגדלים שונים שמוכרות את המוצר שלהן או כמוצר מדף, כ-Appliance, כ-שרות SAAS ועוד. בלא מעט מקרים השיטה המקובלת ל-Delivery של תוכנה – היא Image להרצה על פתרון וירטואליזציה או כ-Image שנמכר בכל מיני "שווקים" של ספקי ענן ציבורי, וכמובן יש את אלו שמוכרים "ברזל" כשהכל מוכן, רק צריך לחבר, להגדיר IP, שם משתמש ולהתחיל לעבוד עם הפתרון.

ה"משחק באש" שאני מדבר עליו, אם מסתכלים על הפתרונות המוצעים כ-Image או כברזל, היא לאו דווקא התוכנה שאותה חברה כתבה, אלא הפלטפורמה או הספריות שהתוכנה משתמשת (ושאותם החברה לא כתבה). מה תעשה אותה חברת יצרנית התוכנה אם מתגלה באג קריטי בפלטפורמה או באחת מהספריות ואין עדיין תיקון לאותו באג? אפשר לפנות לאתר המארח את ה-REPO של אותה תוכנה/פלטפורמה (נניח Github) ולפתוח issue, וכאן נמצאת הבעיה הכי גדולה: אין אפשרות לדעת אם יתייחסו, אם יתקנו ומתי מישהו יתקן את הבאג. יכול להיות שבאג מאוד קריטי יתוקן במהירה, אבל באגים אחרים – יקח זמן עד שיתקנו זאת, והלקוחות של המוצר הסופי לא ממש אוהבים זאת.

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

בדרך כלל ההסכם שלי מול חברות כאלו הוא פשוט:

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

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

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

הבעיות של היום ומחר – עם פתרונות של אתמול ושלשום

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

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

לאחר קריאת החוברת או ההמלצות – אני מחזיר תשובה לפונה, בדרך כלל התשובה תהיה אחת משלושת האופציות הבאות:

  • ההמלצות טובות ונכונות (אם יהיו לי הערות או נקודות מסויימות – אציין אותן)
  • הרעיון העקרוני בהמלצות נכון, אבל מומלץ לשלב פלטפורמות X,Y וטכנולוגיות A,B.
  • אתם שילמתם על היעוץ הזה? ברצינות? אתם נמצאים בשנות ה-90 או ה-2000 או מה?

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

להלן שתי דוגמאות, מהחודשים האחרונים:

  • חברה מסויימת רצתה להריץ פלטפורמה מסויימת על לינוקס מספר רב של פעמים. המערכת אמורה להיות פתוחה לרשת וההפניות יועברו דרך Load Balancer (אני לא יכול לפרט עקב הסכמי סודיות). היעוץ שהם קיבלו: לרכוש 18 שרתים עם מפרט די "כבד", רכישה של Load Balancer חומרתי, סטורג' מפלצתי, לכל הברזלים רשיון VMWare Enterprise.
    ההצעה שלי (שהתקבלה): במקום 18 שרתים עם מפרט כבד, 2 שרתים עם מפרט נמוך, 4 שרתים עם מפרט כבד (יחסית, הרבה זכרון), מערכת OpenShift, ושרת נוסף קטן שיריץ ESXI כדי להריץ 2 מכונות VM שמריצות Windows. סטורג' – או בניה או לרכוש משהו קטן מכיוון שאין צורך ב-IOPS רציני או כמות אחסון גדולה. הפלטפורמה תרוץ כולה על קונטיינרים, ובהתבסס על הסטטיסטיקה שנמסרה לי, אני מתקשה להאמין שתהיה צריכת משאבים של יותר מ-40% בכל השרתים.
  • חברת מדיה מסויימת רצתה לאחסן תכנים רבים ולהערכתם הם יגדלו בכל שנה בסביבות ה-100-150 טרהבייט. הדרישה – אפשרות גדילה ללא SPOF (כלומר: Single Point of Failure) ומבלי לרדת בכמות רוחב הפס הפנימי, אדרבא – אם אפשר שתהיה גדולה יותר ויותר – הם ישמחו. כאן לא היתה חברה מסויימת שנתנה יעוץ, אלא החברה ביקשה מכל מפיצי הסטורג'ים הגדולים והמוכרים בארץ, ואני התבקשתי להמליץ על אחת מההצעות.
    הבעיה: אף הצעה לא כללה פתרון אחסון Scale Out. כל ההצעות היו פחות או יותר "תוסיף מדף" ובקשר לשרידות – קנה שתי ראשים. לפיכך המלצתי הפשוטה (שהתקבלה) היתה: זרקו את ההצעות ובקשו או פתרון Scale Out או לבנות פתרון Scale Out מבוסס קוד פתוח או תוכנה סגורה שמציעות יצרני שרתים וחברות אחרות, ורשת עם Backbone של 40 ג'יגהביט שיגדלו בהמשך לכיוון ה-100 ג'יגהביט.

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

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

שנת 2019 במעבדים – זו לא השנה של אינטל

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

נובמבר 2018 – חברת AMD מכריזה על מעבדי ROME, הדור השני של מעבדי EPYC לשרתים. החברה כינסה את הכתבים והבלוגרים הטכניים ליום עיון טכני, ובסופו של דבר לאחר שהדברים החלו להתפרסם, התברר משהו פשוט אחד: ב-AMD הפיקו מהר מאוד לקחים מהדור הראשון (Naples) והם שינו את הארכיטקטורה (מ-NUMA ל-UMA). החברה עברה בהצלחה מ-14 ננומטר ל-7 ננומטר, והחברה ממשיכה לעבוד בשיטת ה-Chiplets במקום שבב ענק אחד – השיטה שאינטל עובדת (יעברו עוד כמה חודשים עד שאינטל תכריז כי בשבבים עתידיים שלה בעוד שנתיים, גם הם יעברו כ-Chiplets). חברת AMD החליטה לשנות בדרך גם מספר דברים פנימיים מבחינת עיבוד נתונים וגם להגדיר את ה-Cache לגדלים בומבסטיים. בסופו של דבר, כשיצאו המעבדים לשוק ותוצאות המבחנים הראו מעבר לכל ספק שמעבדי EPYC דור שני עוקפים כמעט בכל מבחן את המעבדים של אינטל, כל ספקי הענן הציבורי מיהרו לרכוש וכל יצרני השרתים החלו לקחת את AMD ברצינות והחלו להוציא הן דגמים מעודכנים עם מעבדי EPYC החדשים והן להכריז על משפחות שרתים חדשים שישתמשו במעבדים הללו. מכיוון ששדרוג שרתים נעשה באיטיות ולוקח לשינוי להתרחש במשך שנים בתחום ה-Enterprise, אף אחד לא ציפה ש-AMD תחטוף לאינטל פלח שוק גדול, וגם AMD עצמה הכריזו שהשאיפה שלהם היא להגיע עד 2020 ל-10%, ולפי דיווחים שונים, הם בהחלט בדרך לכך.

האירוניה הגדולה הקשורה לאינטל ולשוק זה – לאינטל יש מענה ל-ROME, והוא נקרא Xeon Platinum 9200, רק שיש מספר בעיות עם המענה הנ"ל:

  • אינטל בראש ובראשונה יעדה אותו אך ורק לשוק ה-HPC. ב-AMD מצהירים בפשטות שמי שרוצה ביצועים גבוהים וכמות ליבות גדולה, ישנם מספר דגמים עם 64 ליבות לרכישה.
  • מערכות השרתים שמריצות את ה-Xeon Platinum 9200 שונות לחלוטין ממערכות שרתים רגילות, הן בחשמל, הן במעבדים והן בתושבת (אין תושבת, המעבדים מולחמים ישירות על הלוח) – מה שלא מאפשר לשום יצרן שרתים לבנות ולמכור מכונות כאלו, זולת יצרנים שמייצרים לוחות אם Custom כמו Supermicro וכו'.
  • התמחור: במחיר של שרת עם מעבד יחיד, תוכל לרכוש שרת עם 2 מעבדי EPYC כשלכל אחד מהם 64 ליבות. עם הפרש מחירים כה גבוה, קשה מאוד לשכנע חברות לרכוש שרתים ועוד ישירות מאינטל (לאינטל אין נסיון רב במכירות שרתים ללקוח הסופי).

משוק השרתים נעבור לשוק ה-HEDT (כלומר: High End Desktop)

תחום ה-HEDT נוצר כתוצאה של תחרות בין אינטל ל-AMD. במקור, אינטל הוציאה סידרת מעבדים חדשה תחת משפחת Skylake, אלו מעבדים שיועדו לכל התחומים, מדסקטופ ועד שרתים. לדסקטופ אינטל הוציאה מספר מעבדים כאשר מקסימום הליבות פר מעבד הוא 4. AMD באותו זמן החלה להוציא פרטים על מעבדים חדשים, משהו שהחברה לא תכננה מראש והם תוצר פנימי של קבוצת מהנדסים שתכננו, הציגו להנהלה, בהנהלה אהבו את זה והחלו לייצר אותם. מהרגע שאינטל שמעה על זה, אינטל נכנסה לפאניקה והחלה לדרוש מיצרני לוחות האם לשנות את הלוחות שאמורים לצאת לשוק כדי לתמוך בכמויות יותר גדולה של PCIe, ולהוסיף תמיכה לסידרת מעבדים חדשה, ה-Skylake X, והכל כמובן היה תחת לחץ אטומי של אינטל לשנות הכל תוך .. 3 חודשים, והתוצאות גם ניכרו בהמשך כאשר לוחות שהחלו לצאת לשוק לא יכלו לתמוך מבחינת VRM וחום במעבדים החדשים. אז בזמן שאינטל הציגה רשימת מעבדים חדשה כשבראשה עומד ה-7980XE, חברת AMD הוציאו את ה-Threadripper עד 16 ליבות במחיר נמוך משמעותי מהמחירים שאינטל ביקשו. מאז החברות הוציאו דור שני למעבדי HEDT, ו-AMD הוציאה גם מעבדי Threadripper עם 32 ליבות.

בשבוע שעבר היתה לסוקרים ולבלוגרים הטכניים שמקבלים מעבדים לסקירה – "הפתעה" לא נעימה: אינטל החליטה להרים את ה-NDA כ-6 שעות לפני שהסוקרים יכלו להציג את מעבדי ה-Threadripper החדשים. ערוצי יוטיוב רציניים כמו Jaytwocents ו-Linus Tech tips די קטלו את אינטל על המהלך הנבזי הנ"ל (אינטל עם המהלך הזה רצתה להשיג סקירות שלא משוות את המעבדים החדשים ובמיוחד את ה-10980XE מול מעבדי ה-Threadripper) ובסופו של דבר רוב הסקירות שיצאו לשוק – די קטלו את המעבד החדש.

המעבד החדש, למרות שהוא מהיר בכ-400 מגהרץ בהשוואה לדור קודם (9980XE) קיבל חלק מתיקוני האבטחה, מה שגורם להאטת ביצועים מול ה-9980XE, כלומר מהירות השעון היא אכן יותר גבוהה, אך הביצועים יותר נמוכים. אינטל גם החליטה לחתוך במחצית את מחיר המעבד בהשוואה ל-9980XE כך שכולם ראו את התאוותנות של אינטל, ואז הגיעה ההשוואה מול מעבדי Threadripper החדשים של AMD (ה-3960X ו-3970X), וכאן – הפתעה: לא רק שה-Threadripper החדשים בועטים ב-10980XE כמעט בכל מבחן, ה-3950X, המעבד שמיועד בכלל לדסקטופ ויש לו "רק" 16 ליבות – גם הוא עוקף במבחנים רבים את ה-10980XE. בקיצור – אינטל נשארו עם עוגה על הפרצוף וההמלצה ברוב הסקירות היא שאם אין לך מערכת קודמת מבוססת X299, עדיף לבחור מהפתרונות של AMD.

שוק תחנות העבודה: הנה שוק שאינטל שולטת בו לחלוטין, והדבר היחיד החדש שהיה בו זה אינטל הוציאה לשוק זה את ה-Xeon W-3275. מעבד עם 28 ליבות במחיר של 4500$. רק לשם השוואה, ה-Threadripper 3970X עולה $2000 והוא "חוגג בסיבובים" ברוב מוחלט של המבחנים סביב המעבד הנ"ל של אינטל.

הגענו לשוק הדסקטופ, וכאן לאינטל השנה לא היה כמעט כלום מה לחדש. הם הוציאו מעבדים עם 8 ליבות שיכולים להגיע למהירות 5 ג'יגהרץ (כל הליבות), והם הוציאו גם כמה מעבדים ללא יחידת עיבוד גרפי פנימי (המבחנים הראו שחבל לרכוש אותם, לא מקבלים ביצועים יותר גבוהים). ב-AMD לעומת זאת "כיסו" עם שורת מעבדים את כל מה שאינטל מציעים, החל ממעבדים 2 ליבות ועד 16 ליבות – שרצים על לוחות אם חדשים וישנים (כל מה שצריך זה לעדכן BIOS) עם מחירים מאוד תחרותיים מול אינטל. המסקנה של רוב הסוקרים היתה פשוטה: אם אתה מחפש לרכוש/לבנות מערכת גיימינג שתתן לך את כל הפריימים עד האחרון שבהם, קח מעבד של אינטל ועדיף את ה-9900KS. אם יש לך צרכים מעורבים (כולל עריכת וידאו, אפקטים וכו'), תסתכל על ההצעות של AMD.

לסיכום: ל-AMD אין משאבים כמו שיש לאינטל, והשמועות על פלטפורמת Zen-2 (שכל המעבדים החדשים מתבססים עליה) החלו עוד באפריל 2018 ואני בטוח שאינטל ידעה הרבה יותר מהציבור, ובכל זאת, במהלך שנה וחצי, אינטל לא הוציאו שום מעבד תחרותי. אני פשוט המום מכך שחברה בשווי שוק של 254 מיליארד דולר לא מצליחה להוציא מעבדים תחרותיים בשעה שהמתחרה הקטנה שלה מצליחה לפתח ארכיקטורות חדשות (ה-Zen-3 שיצא בשנה הבאה היא הארכיטקטורה השלישית -AMD תוציא והיא מכוונת לנקודות החזקות של אינטל: Floating Point ו-IPC, ועוד כמה דברים). אני מאמין שאינטל תתעשת ותוציא ארכיטקטורות ומעבדים חדשים ויותר חזקים, אבל איך זה קורה ששנה וחצי אין שום התפתחות אצלם?

ה"פקקים" בדרך לביצוע פרויקטים

כפרילאנסר, אחד הדברים שאתה צריך מהר מאוד ללמוד וליישם אצל כל לקוח חדש שאתה מגיע אליו – הוא "למדוד תקשורת". כשאני מדבר על מדידת תקשורת, אינני מדבר על תקשורת TCP/IP או תקשורת DATA כלשהי, אלא כמה זמן לוקח לתהליכים להתרחש, מה או מי מעכב את התהליכים מלהתרחש.

אתן דוגמא (בלי שמות): לפני שנתיים בערך, הוזמנתי ע"י חברת סטארט-אפ שעסקה בתחום טרנדי מסוים – לבוא ולתת שרותי אינטגרציה ב-OS. הסטארט אפ היה מאוד ידוע, הושקעו בו מאות מיליוני דולרים, כך שעבודה איתם יכלה להניב עבודות נוספות מבחינה פוטנציאלית בתחומים שאני יכול לסייע. מה רע? הוזמנתי לראיון הראשוני. מהטלפון עד זימון הראיון עברו בערך חודשיים. נו, אולי האנשים סופר עסוקים, לך תדע. הגעתי לראיון, היתה כימיה טובה, וכבר למחרת נמסר לי כי התקבלתי. מעולה, רק שמאז עברה חצי שנה עד שסוף סוף קיבלתי את ה-NDA והחוזה לחתימה (חתיכת חוזה, אם אני זוכר נכון, בסביבות 120 עמודים!) וכשסוף סוף הוזמנתי להתחיל לעבוד (עניין של עוד חודשיים וחצי) – חשכו עיניי. המוצר היה אמור לצאת בעוד חצי שנה, ורק 30% מהמוצר מוכן! הסטטוה הזה הפליא אותי הואיל ואני מכיר חלק מצוות הפיתוח והוא ממש לא איטי – כשהייתי צריך מהם דברים מסוימים, זה בוצע תוך דקות ספורות, אבל כל שאר החלקים בפרויקט – זוחלים בקצב צב.

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

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

האידיליה הזו במקרים רבים נשברת על ידי צוותי הנהלה. לי כמובן אין שום דבר נגד צוותי ניהול, אך הבעיה המהותית שמתרחשת זה שדברים שמצריכים החלטה עוברים לדרג ניהולי, וחלק מאותם מנהלים מוסיף לעצמו עוד ועוד דברים וכתוצאה מכך – החלטות מתקבלות לאט (ידידנו האמריקאיים מומחים בכך, תאמינו לי. הם אלו שהמציאו את ה-Project Manager, Product Manager, Director ושלל תארים נוספים) וכך מתרחשים לדוגמא השהיות: נניח ואני צריך עוד שלוש שרתים כדי לבצע עבודה. שום איש IT לא יכול לאשר רכישות כאלו, אז זה צריך לטפס למנמ"ר, ל-CTO, ל-CFO ולמנכ"ל. מכיוון שלכל אחד מהם יש "בצלחת" דברים רבים שהוא צריך לעקוב/להחליט לגביהם, הזמן שיקח עד שיגיעו שרתים – נמדד בחודשים, ועד אז אותו חלק שאני צריך לבצע – מוקפא, מה שאומר שאותו פרויקט יתארך ויהיה צורך לשלם יותר לעובדים החיצוניים.

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

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

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

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

קצת על Scale Out עם פלטפורמות יעודיות

בשנים האחרונות אנחנו עדים ליותר ויותר פלטפורמות שעובדות בשיטות של Scale Out. הפלטפורמה הכי ידועה לדברים כאלו היא כמובן Kubernetes, אך כמובן שישנן פלטפורמות אחרות שקשורות יותר לעיבוד נתונים – Kafka או Cassandra לדוגמא, כל אחת מהן פלטפורמה לצרכים שונים, אבל מבחינת צרכי חומרה, הצרכים הם פחות או יותר זהים: מעבדים בינוניים (לא צריך כמות מפוצצת של ליבות, יספיקו 8-16), ולא צריך דיסקים (קשיחים או SSD) יקרים.

כלומר – אם אתה צריך להריץ פלטפורמה שעובדת ב-Scale Out מקומית בתשתית שלך, אל תנסה לחפש את היוקרתי עם כל מילות הבאז האחרונות, אלא ההיפך – מי הספק שיכול לתת לך את ההצעה הכי זולה שתעמוד במפרט שנקבע מראש, SLA שאתה צריך וכו'. ב-Scale Out אין את מושגי השרידות מעולם ה-Scale Up. אין Heart beat, אין Active/Passive, Active/Active וכו'. עם Scale Out בדרך כלל הפלטפורמה תהיה בנויה כך שאם שרת למטה/אינו זמין/אינו פעיל, המערכת תאזן את עצמה אוטומטית (למי שמשתמש ב-Kubernetes ורוצה לראות זאת – תורידו Node ותראו איך זה עובד).

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

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

אחת השגיאות שאפשר לראות בפורומים שונים, זה שאנשים שעובדים עם פתרונות Scale Out מחפשים איך לאחסן את כמות הנתונים שהולכת וגודלת והם עדיין לא מכירים/מבינים את עניין ההוספה המתמדת של ברזלים ודיסקים מקומיים – והם תמיד יקבלו את הצעות הפתרונות שמתאימים ל-Scale Up: לתכנן את הגדילה למשך שנה וכו' וכו' ואז לבחור סטורג'. זו טעות, כי בעולם המדידות/דגימות ושימוש בפלטפורמות Scale Out אתה מחפש לקבל כמה שיותר מידע, לא כמה שפחות, ויכול להיות שהחודש הקרוב אתה תוסיף עוד 4 טרה מידע לחודש אבל בעוד 3 חודשים זה יקפוץ ל-15 טרה לחודש. בגדלים כאלו, שום פתרון סטורג' קנייני אינו מתאים, אלא אם רוצים "לשרוף" את תקציב החברה, ולכן יש צורך ללכת לפי הפתרון של הפלטפורמה, לא לפי שם/דגם של סטורג'.

ולכן:

  • אם הולכים להשתמש בפלטפורמה שהיא בראש ובראשונה Scale Out לצרכי עיבוד נתונים/קליטת נתונים – נצטרך דיסקים ושרת מהקצה הנמוך-בינוני, מבלי להשקיע יותר מדי כספים פר ברזל (קחו דיסקים בסיסיים, בפוסט קרוב אסביר לגבי הגדרות אחסון מקומי למערכות כמו Kafka ו-Cassandra), (אגב, אם אתם רוצים להריץ Kafka בענן, אמזון לדוגמא שמחה להציע לכם את MSK).
  • אם אנחנו רוצים לשמור כמות גדולה מאוד של מידע לאחר עיבוד או ארכיבאי כשהכמות גודלת כל הזמן, או שאנחנו צריכים Object Storage – פתרון אחסון Scale Out (כמו Gluster) יתאים יותר לשימושים הללו מכיוון שעלות הגדילה היא זולה, והביצועים גודלים ככל שמוסיפים ברזלים לאותו אחסון.

לסיכום: בעולם ה-Enterprise, הסטורג' הקנייני היה ה-דבר הכי חשוב וקריטי. אין סטורג', שום דבר לא פועל. מאז הגיעו ספקי הענן הציבורי הגדולים שהכריזו שאצלם אין ולא יהיה שום סטורג' מרכזי, ובמקביל התפתחו יותר ויותר פלטפורמות שמחזירות את השימוש בדיסקים מקומיים ומאפשרות לבנות אחסון מדיסקים זולים וממשאבים צנועים, וזהו בדיוק החלק שבמחלקות ה-IT או ה-CIO/CTO צריכים להבין: אל תנסו לכפות פתרון Scale Up על פתרון Scale Out.

המעבר ל-10 ג'יגהביט למעבדה קטנה

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

כפרילאנסר, אחת הסברות שאני שומע שוב ושוב בעולם ה-Enterprise מכל מיני מנמר"ים/CTO/CIO – זו התרשמות, שלא לאמר התפעלות – משרתים חדשים שמיוצרים על ידי המובילים: לנובו, Dell, Cisco, HPE, ואחרים. תראה להם מכונה עם 4 מעבדים – והם פותחים עיניים (טוב, עד שהם רואים את תגית המחיר). אותו דבר קורה כשמדברים על ציוד תקשורת – רוב החברות בארץ משתמשות עדיין בתקשורת 1 ג'יגהביט, 10 ג'יגהביט, 25 ג'יגהביט, Infiniband (במקרים מסויימים) במהירות 56 ג'יגהביט היא השיא. 100 ג'יגה ומעלה? נדיר למצוא, גם במקומות שהתקציב מאפשר ועל 400 ג'יגהביט – לא שמעתי שום מקום שמשתמש בזה.

עם כניסת ספקי העננים בשנים האחרונות (או בשמם היותר ידוע: Hyperscalers), חל דבר מעניין מאוד: ברוב מוחלט של המקרים (ואני מדבר על מעל 95%) אף ספק כזה לא היה מוכן לרכוש ציוד של Enterprise – בין אם מדובר בשרתים, סוויצ'ים, סטורג', גיבויים וכו'. הסיבות די פשוטות: הסיבה הראשונה קשורה למחיר החסר פרופורציות לחלוטין פר ברזל, והסיבה השניה – הציוד לא יכול לעמוד בדרישות שלהם, וכך בהחלה כל ספק Hyperscaler החל לתכנן ולבנות את הציוד שלו, ואז הגיעו פייסבוק שחוללו מהפכה והחליטו לפתוח את כל המפרטים של הציוד שלהם, כולל סכימות וכו' תחת מטריית ה-OCP (ר"ת Open Compute Project). לקח קצת זמן עד שענן החשדות מצד ספקי Hyperscalers ירד ואז כולם החלו לשתף את המפרטים. התוצאה: מאות חברות חדשות שקמו שהחלו לתכנן ולמכור את הציוד לספקי ה-Hyperscalers במחירים יותר נמוכים ממה שביקשו ספקי ציוד ה-Enterprise בשעה שהציוד נתן הרבה יותר מבחינת ביצועים.

מאז החלו לזלוג לשוק ה-Enterprise חלק קטן מאותו ציוד: למי שמכיר את הקופסאות JBOD 4U – כן, זה התחיל ב-OCP. מתגי תקשורת שבעבר היו מערכות סגורות עד הקצה – כיום יש יותר ויותר מתגים שמשתמשים במעבד רשת של Broadcom ושבב X86 של אינטל שמריץ לינוקס כדי לנהל את הכל ואתה מבצע בעצם את הכל דרך לינוקס עם הפקודות הידועות והמוכרות.

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

כשאני משוחח עם חברים ושואל אותם לגבי ה-LAB שלהם מדוע הם לא עוברים לחיבוריות פנימית של 10 ג'יגהביט, עולות מיד סיבות שלא ממש נכונות כיום. חלקן:

  • מחיר המתג וההמרה ל-10 ג'יגהביט יקר מדי
  • בשביל מה צריך את זה? 1 ג'יגהביט מספיק
  • קשה לחבר מעל 2 מחשבים בלי מתג
  • קשה להגדיר

אז נתחיל מהסיבה הפשוטה ביותר: רוחב פס מוגבל. נניח שיש לכם NAS, לא חשוב איזה NAS. נניח שיש בו 4 דיסקים מכניים (בלי להזכיר שום SSD) ונניח שהם מוגדרים ב-RAID כלשהו (לא חשוב איזה). מהירות ממוצעת לקריאה/כתיבה של דיסק מכני היא נעה בין 100-200 מגהבייט לשניה וזה לדיסק יחיד. נכפיל ב-4 לצרכי קריאה לדוגמא, ואנחנו מקבלים מהירות שנעה בין 400 ל-800 מגהבייט. תזכורת: מהירות 1 ג'יגהביט מתורגמת בערך ל-120 מגהבייט, כלומר דיסק יחיד "חונק" את חיבור ה-1 ג'יגהביט. יבואו אנשים ויאמרו "אפשר לצוות מספר חיבורים", שזה נכון, אז בואו נצוות 4 חיבורים של 1 ג'יגהביט ונקבל מהירות ברוטו תיאורתית של … 480 מגהבייט, כלומר את החיבור המצוות אנחנו "נחנוק" עם תעבורה של בערך 2.5 דיסקים קשיחים מכניים (שוב, לא מזכיר SSD שזורק מיד כל חיבור 1 ג'יגהביט).

נעבור למחיר: האם מתג של 10 ג'יגהביט הוא יקר מדי? אם אתה רוצה לרכוש מתג Enterprise של סיסקו או HPE – כן, זה יעלה לך כמה אלפי דולרים. אם לעומת זאת תרכוש מתג של חברת MicroTik, המחיר יפתיע אותך בהחלט. לי לדוגמא, מתג של 16 פורטים +SFP במהירות 10 ג'יגהביט עלה לי 1500 שקל וזה כולל משלוח ומסים. אם אתה רוצה לעומת זאת לחבר רק 2-3 שרתים ואולי מחשב, אז מתג כמו MikroTik CRS305-1G-4S+in יעלה לך 604 שקלים, כולל משלוח מסים (זה המתג שבתמונה).

מה לגבי כרטיסים לחבר למחשבים ושרתים? פה eBay יכול לעזור לך: כרטיס רשת של Mellanox מסוג ConnectX-3 כמו הכרטיס הזה עולה 142 שקל לכרטיס (שימו לב, רוב ההצעות האחרות מדברות על 150+ שקל לכרטיס, ואם אתם משתמשים ב-ESXi רכשו את ה-Connect-X3 ומעלה, לישנים אין יותר תמיכה ב-VMWare), שזה הרבה פחות מהמחיר של כרטיס רשת טוב לשרת במהירות 1 ג'יגה.

כבלים – נחסוך את הרכישה של סיבים אופטיים. לא צריך אותם יותר (בתור אחד שיש לו 3 חתולים שנהנים מדי פעם לבדוק את השיניים שלהם על כבלים כאלו – הם עמידים בצורה מעולה!), במקום זה נשתמש בכבל DAC TwinAX נחושת וכאן תלוי מה האורך שאתם צריכים. אם המחשבים שלכם יושבים במקום אחד וצמודים, כבל של 1 מטר יספיק, והכבל הכי זול שמצאתי זה מהסוחר הזה ב-eBay במחיר של 26.64 שקל. בניגוד לסיבים, לא צריך ג'יביקים ובכלל, המתגים של MicroTik עובדים עם כל כבל – נחושת או סיב או כל GBIC, אין בדיקה ואין חסימות.

אחרי שקנינו, קיבלנו את הכל וחיברנו, בד"כ ההגדרות עצמן הם פשוטות ויש אולי צורך לשנות את הגדרות ה-Jumbo Frames (שינוי MTU ל-9000) – ואפשר להתחיל לעבוד.

אז אם יש לנו 3 מחשבים, העלות תהיה: 604 שקל למתג, 426 שקל ל-3 כרטיסים, 80 שקל לכבלים. סך הכל: 1110 שקל. פתאום 10 ג'יגהביט זה לא כזה יקר? 🙂

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

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