VMWare על AWS – האם שווה להשכיר?

(אני רוצה להתחיל בהערה קטנה. אחרי שכתבתי את הפוסט על PKS קיבלתי מאנשים הערות שאני "אנטי VMware". אני לא. למען האמת, אני בשלבים של מעבר כל המכונות שלי ל-vSphere 6.7 ואני חושב שפתרון הוירטואליזציה של VMWare הוא מהטובים בשוק. יחד עם זאת, יש לי השגות לגבי חלק ממוצרי החברה ואת אותן השגות אני משתף, לא יותר מזה). נקודה נוספת: בעבר כתבתי על VMWare on AWS אבל הכל היה מבוסס על שמועות. הפעם ביקשתי מחבר שבעבודתו משתמשים במוצר להקדיש לי שעתיים ולהראות לי את התכונות ובדקתי גם את ההדגמות והקליפים הרשמיים טרם כתיבת פוסט זה.

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

לתוך הנישה הזו VMWare מוציאה "מוצר חדש" שנקרא VMWare on AWS ופתרון זה יוצר מעין "המשכיות בענן", אתה יכול להשתמש ב-SDDC Manager לנהל את הפתרון של VMware בענן יחד עם הפתרון שרץ אצלך מקומית (On Prem). אתה לא צריך לשנות מכונות וירטואליות לעבר הפתרון שלהם שרץ בענן של ה-סע"צ שבחרת, אתה פשוט מבצע Migrate של אותן מכונות וירטואליות לאותו DC מרוחק, ל-Cluster המרוחק ול-Datastore המרוחק, בוחר את הסוויצ', מאשר, וזהו – המכונות הוירטואליות בדרך לענן הציבורי. נשמע קל ופשוט, בלי הרבה כאבי ראש.. לא?

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

  • הפתרון VMWare on AWS הוא בעצם פתרון vSAN המוכר. אתם לא משלמים פר VM, אתם משלמים פר שרת פיזי ויש צורך במינימום 3 שרתים.
  • התמחור יכול להיות דינמי (פר שעה) או פר שנה או פר 3 שנים והמחיר עצמו טיפ טיפה גבוה .. אם לדוגמא אתם רוצים להקים זאת בארה"ב, בוירג'יניה, שם המחיר יהיה הכי "זול". כמה? ובכן, על 3 מכונות בסיס (נקראת i3) תשלמו 155,961 דולר לשנה. רוצים להריץ את זה בפרנקפורט, גרמניה? המחיר מטפס ל-185,952 דולר לשנה. המחיר כולל את הרשיונות ל-vSphere ו-vSAN אך אינו כולל VMWare Site recovery, ובשביל לכלול זאת יש לשלם $22,600 פלוס 347$ פר VM.
  • ישנן שתי סוגי מכונות: i3 metal, r5 metal. ה-i3 כוללת דיסקים NVME מקומיים (אחסון כולל Cache בסביבות ה-16 טרה), ואילו מכונת ה-i5 משתמשת באחסון של AWS (ה-EBS) כ-"דיסקים מקומיים", אחסון EBS אינו נכלל בסכומים שציינתי לעיל והתשלום הוא חודשי. פונקציה נוספת – Elastic vSAN (מאפשר להשתמש באחסון שבשרת גם אם אותו שרת הוא במצב תחזוקה) עולה $2.28 לשעה פר מכונה. אלו מחירים ל-3 שרתים בשרת ה"נמוך" (18 ליבות, i3-metal). אם אתם רוצים להשתמש באחסון של אמזון (EBS) ולקחת שרתים יותר רציניים (r5 metal, עם 48 ליבות) אז בוירג'יניה תצטרכו לשלם 174,411 דולר לשנה, ובפרנקפורט המחיר מטפס ל-210,396 דולר לשנה.
  • רוצים הנחות על המחיר? בשמחה, רק אם אתם משלמים מראש. אם אתם שוכרים את הברזלים ל-3 שנים מראש, יש לכם 50% הנחה. אם לשנה – 30% הנחה (לפי המסמך הזה).

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

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

אם נרכוש שלושה שרתים, בכל אחד מהם מעבד אחד AMD EPYC עם 32 ליבות (כך נחסוך במחצית את העלויות של vSphere ו-vSAN וכל מוצר אחר שמחושב Per Socket), עם חצי טרהבייט זכרון, עם 6 דיסקים NVME SSD ו-2 דיסקים NVME SSD Mixed Intense, עם כרטיס רשת של 10 ג'יגהביט, כל הרשיונות (ל-3 שנים) שצריך ולקינוח גם סוויצ' נחמד. צריכים את המערכת בגרמניה, או ארה"ב או אפילו מחוץ למשרדכם פה בארץ? חפשו ספק שמוכר שרותי COLO (כלומר Co Location) לאחסן 4U או 7U (שזה 3 שרתים, תלוי בגודלם הפיזי – פלוס סוויצ') עם רוחב פס נאה, ואתם תשלמו לו בערך 2000-4000$ לחודש.

ניקח את כל הערימה הזו ונחשב אותה – ותראו שלא תגיעו ל-$160,000 שתצטרכו לשלם בממוצע לשנה על VMWare on AWS, ובנוסף – הציוד והרשיונות הם שלכם, וזה כולל SLA לברזלים ולציוד עצמו.

אחד הדברים שחשוב להבין לגבי VMWare on AWS היא למרות שהשיווק יזכיר בכל שניה וחצי את המילה "ענן" – חוץ מהעובדה שזה יושב ב-DC של ספק ענן ציבורי, אין לפתרון הנ"ל כמעט כלום עם מה ש-סע"צ בעצם מייצג. (ה"כמעט" קשור למכונה r5 metal שמשתמשת באחסון של ספק הענן אבל זה בעצם לא ממש משנה כלום. EBS מאפשר גדילה דינמית, אבל vSAN לא יודע "לאכול" דיסק "פיזי" שגודלו השתנה). כל השירותי ענן שתשתמש בהם מתוך ה-VMware on AWS יהיו בדיוק כמו שתיקח את השרותים מבחוץ או ממכונות וירטואליות שה-סע"צ משכיר מהשרותים שלו.

הבה נסתכל על ההצעות של ה-סע"צ. רבים נוטים להתעצל ולבחור נניח מהעשיריה הראשונה של ההצעות ל-VM כדי לא להסתבך, אבל המציאות היא שכל סע"צ מציע מספר "דורות" של מכונות וירטואליות, חלק לא קטן מההצעות די זולות ויכולות להתאים למשימות שונות (הנה לדוגמא ההצעות של AWS. מיקרוסופט, לפחות ממה שבדקתי, לא מציעה טבלה כזו אז חברת Nakivo מציעה טבלה כזו עם הסברים, ובגוגל יש דף פשוט שמסביר את הסוגים. אז אם לדוגמא אתם צריכים להריץ אפליקציה שדורשת המון זכרון אך כמעט ולא עושה כלום עם המעבד, אתם יכולים לשכור Instance מדור ישן יותר ובכך לחסוך. צריכים מכונות VM שאליהן מחוברים דיסקים SSD פיזיים לוקאלית? יש. ב-VMWare on AWS אין חיה כזו – יש סוג אחד של מעבד (ישן, מלפני שלוש דורות – Xeon V4) ואין לך אפשרות לחבר SSD פיזי לוקאלית ל-VM (על VMware on AWS – כי זה מנוהל על ידי VMware).

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

קונטיינרים ו-Windows – מאמר עדכון (2020)

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

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

וזה חתיכת כאב ראש..

באותו זמן מיקרוסופט החלה להציע דרכים להכין ולהריץ קונטיינרים, אבל רק ב-Windows Server 2019 (ובגרסאות Windows 10 היותר מתקדמות) הם הציעו באופן רשמי דרכים להריץ קונטיינרים ל-Windows (הכוונה שהקונטיינר מכיל IMAGE עם קבצים בינאריים ל-Windows). בהתחלה עם Hyper-V בצורה מבודדת (דרך מצויינת לבזבז זכרון) ואחר כך כ-Process מבודד.

העניין הוא שחברות רוצות לא רק קונטיינרים, אלא את כל ה"מסביב", אורקסטרציה, תמיכת Plugins שונים, HA ועוד ועוד – כל מה ש-Kuberentes נותן. את זה לא היה באותו זמן, ו-K8S החל להיתמך באופן רשמי ויחסית יציב – בגירסה 1.14 (אם כי יש תיקוני באגים בכל הקשור לתמיכת Windows ולכן כדאי להסתכל על גירסה 1.17 האחרונה).

בחודשים האחרונים החלו יצרני "הפצות" K8S כמו PKS של VMWare להציע גירסת בטא לתמיכת Windows Containers וגירסת Openshift הבאה תציע זאת גם. אם אתם מתכוננים להיפגש עם נציג של VMWare לגבי PKS, הוא בוודאי יציג לכם מצגת עם שקופית שמזכירה לכם ש-Windows 2008/2008R2 מסיים לקבל תמיכה רשמית השנה ולכן כדאי לנצל את העניין לעבור לקונטיינרים (אכן התמיכה מסתיימת אבל יש שמירה לאחור די רצינית בכל הקשור לתאימות בינארית, כך שאפשר להריץ את אותן אפליקציות ב-Windows 2012/2016/2019, המקסימום – תצטרכו לקמפל מול ספריות סטנדרטיות, כך שהטענה שגירסת OS הסתיימה ולכן עכשיו עכשיו חשוב לעבור לקונטיינרים – לא ממש "מחזיקה מים").

אז מה המצב כיום?

טכנית, אין בעיה להריץ K8S תחת Windows, אך כרגע Windows נתמך כ-Workers Node באופן רשמי ולכן עדיין תצטרכו מכונת לינוקס שתשמש כ-Master. אם אתם רוצים להריץ K8S מהקוד הקיים הפתוח, אתם צריכים לעבור תהליך התקנה די ארוך ומורכב שאפשר לקרוא עליו כאן (יש עוד 2 חלקים בצד שמאל, אל תדלגו עליהם). אם אתם חושבים להשתמש ב-Rancher, גירסה 2.3 תומכת ב-Windows Containers, לגבי השאר – ציינתי לעיל.

אם אתם מתכננים לממש ולהריץ קונטיינרים ל-WIndows בעננים ציבוריים, אז כל הספקים המספקים שרות הרצת קונטיינרים מנוהל כבר תומכים בכך.

הדברים החשובים לזכור ולבדוק (אם אתם מריצים K8S ב-On prem):

  • לא לשדרג את ה-Windows אוטומטית. אם מיקרוסופט מוציאה מחר Service Pack או עדכון שמעלה את גירסת ה-Windows (דוגמא: 1709 ל-1903) יכול לשבור דברים בקלות, ויכול להיות מצב שלא תוכלו להריץ קונטיינרים.
  • תמיכת Plugins – ל-K8S יש מאות Plugins שונים בתחומים שונים. ב-Windows רק חלק קטן נתמך ורץ (הם מופיעים בקישור שנתתי בפיסקת תהליך ההתקנה לעיל). כך לדוגמא, חלק מיצרני הסטורג'ים שחררו Plugins ל-K8S בכל הקשור ל-Volumes, צרו איתם קשר לראות אם הם שחררו את ה-Plugins שלהם ל-Windows. כמו כן, תמיכת CSI (כלומר: Containers Storage Interface) היא עדיין ברמת אלפא/בטא.
  • יכול להיות שה-IPS/IDS שלכם לא יאהבו את K8S ל-Windows, הואיל ובחלק מהמקרים נעשים שינויים לפאקטות. כמו כן התמיכה ב-NAT היא קצת בעייתית (תסתכלו בחלק של ה-Networking באותו קישור) – קחו את זה בחשבון לטיפול.
  • קונטיינרים ברמת privileged (אלו בדרך כלל קונטיינרים שמשפיעים על כל ה-K8S) לא יכולים כרגע לרוץ תחת Windows.
  • ניהול זכרון: בלינוקס יש תהליך (שנוא אבל הכרחי) שנקרא OOMKiller שהורג תהליכים בעת מצבים שמסתיים הזכרון. ב-Windows זה אחרת, וברגע שמסתיים הזכרון, המערכת משתמשת ב-pagefile כך שאין משהו שיהרוג תהליכים אם הזכרון מסתיים ולכן יכול להיות מצב שה-Node "יזחל" רק בגלל שאין זכרון. התיעוד מציע מספר אפשרויות, אבל כדאי לעקוב היטב במערכת הניטור לגבי זכרון במכונות Windows המריצות PKS.
  • אם אתם משתמשים ב-Flannel פלאגין לרשת K8S, כדאי לזכור שאין אפשרות לתקשורת בין Node ל-POD.
  • אבטחה – בכל מה שקשור ל-Secrets – דברים נכתבים כ-clear text ב-Node Volume. יש שתי המלצות בתיעוד – או ACL או Bitlocker, שתי פתרונות שלדעתי די עקומים אבל זה מה שיש. בנוסף – האבטחה ל-POD שהפצות K8S שונות מאפשרות תחת לינוקס (SELinux, AppArmor וכו') – לא נתמכות ב-Windows בכלל ויכול להיות שבעתיד יפותח משהו.

כל הנקודות לעיל נלקחו מהמסמך בקישור לעיל והם רלוונטיים לגירסה האחרונה (שברוב המקרים לא כלולה בהפצות K8S השונות), ולכן אני עדיין טוען: התמיכה ב-Windows היא עדיין Work In progress, זה יכול להספיק להריץ דברים פנימית שאינם פתוחים/חשופים לאינטרנט, בסביבות Testing, Staging ואפילו PROD מצומצם, אבל מומלץ לעבור עם מחלקת אבטחת מידע על כל המגבלות במסמך המקורי ולהחליט אלו קונטיינרים ל-Windows להקים ולהריץ ב-K8S, מה ממירים להרצה על לינוקס (כדאי לזכור: בתוך POD אי אפשר להריץ קונטיינרים גם מ-Windows וגם מלינוקס), ועל מה כרגע מדלגים.

לסיכום: K8S ל-Windows, למרות יצרני הפצות K8S שונות, הוא עדיין Work In Progress. יש את כל החלקים הבסיסיים, אבל חסרים לא מעט דברים חיצוניים ויש לא מעט אורות אדומים בכל מה שקשור לאבטחת מידע, ניהול זכרון, Plugins וכו' וכו'. אין שום בעיה ואפילו מומלץ – להקים מערכת K8S ולצוות אליה מכונות Windows לשרת Linux שישמש כ-Master ולהתחיל תהליכי המרה, טסטים והרצות שונות, אבל כשזה מגיע לפרודקשן, ממליץ "לעשות חושבים", גם אם מדובר בהרצת קונטיינרים לפרודקשן במערכות קונטיינרים מנוהלות ע"י ספקי ענן ציבורי.

השוואה: PKS מול OpenShift

יצא לי לשוחח עם לא מעט חברות שרוצות להשתמש בקונטיינרים. רבים כבר התחילו ממזמן להשתמש ב-Docker (הערה: לא הגיע הזמן להכיר ולהשתמש ב-cri-o?) והם החלו להשתמש ב-Docker-compose להרמת מספר קונטיינרים במכה אחת. חלקם מתחילים להשתמש בשרותים המנוהלים לקונטיינרים בעננים הציבוריים וחלקם רוצים פתרון On Prem ומטבע הדברים הם מתחילים לקרוא על Kubernetes וכשהם מתחילים להבין כמה הוא מורכב לתפעול (ומגירסה לגירסה זה נהיה יותר ויותר מורכב) – הם מבקשים המלצות על פתרון קל יותר להקים ולנהל אשכול Kubernetes (ובקיצור בשמו החביב: K8S).

רוב מוחלט של החברות הבינוניות והגדולות משתמשות ב-VMWare (מי שמשתמש ב-Hyper-V וירצה פתרון קל להתקנה וניהול ל-K8S – בהצלחה עם זה) ומטבע הדברים הם מעדיפים משהו מחברה גדולה וידועה כמו VMWare, ששמחה מאוד למכור להם את PKS. המוצר עצמו נמכר בשתי תמחורים שונים – פר POD (כאשר POD הוא מעין "קבוצה" כאשר כל POD מכיל קונטיינר אחד או יותר, ברוב המקרים יריצו קונטיינר עם אפליקציה ועוד קונטיינרים שמכילים אפליקציות נסמכות תחת POD אחד ואז יש גם תקשורת בין הקונטיינרים בקבוצה) או פר ליבות. זה מתחיל ב-50 PODS או ליבות. (המלצה: לא לרכוש פר POD. בכל ליבה אפשר להריץ עשרות PODs).

המתחרה העיקרי והיותר גדול ומיועד ל-Enterprise להרצת Kubernetes היא מערכת Openshift. גם היא תומכת באופן טבעי ומלא ב-VMWare (כן, כולל תמיכה ב-NSX-T), רק שבניגוד ל-PKS, היא לא מיועדת רק להקמה וניהול של Kubernetes במובן הסיסטמטי, אלא היא יותר מיועד לכל השרשרת – מרמת ההנהלה, אנשי אבטחת מידע, ומפתחים. ב-PKS אם אני רוצה להקים אפליקציה, אני צריך להשתמש ב-Cloud Foundry (או דרך ה-cli ב-kubectl), צריך במקרים רבים לכתוב קבצי YAML (ימח שמו וזכרו עם כל הקטע של רווחים!) שמצריכים ידע מספק ב-K8S. עם Openshift – יש לך Template (שתמיד אפשר לכתוב נוספים) והמתכנת עושה הכל דרך ה-Web UI. יש קטלוג מובנה שמאפשר להתחבר לאינטרנט ולהוריד אוטומטית templates נוספים והקמה של אפליקציות נוספות בכמה קליקים, יש אבטחת מידע הרבה יותר רצינית מ-PKS (בגלל זה רוב הקונטיינרים הזמינים לציבור לא ירוצו על Openshift אלא אם משנים הגדרת אבטחה שבחברה עלולים לפטר אותך אם תשנה אותה), יש גרפים וניטור מובנה, קל מאוד לשייך בין אפליקציה לשרות (נניח אפליקציית JAVA לקונטיינר אחר שמריץ MySQL – משתמשים ב-BIND בתפריט ותוך שניות ספורות המערכת תבנה את הכל) ויש עוד תוספות רבות שכלל לא קיימות ב-PKS. בקיצור, מי שיקים מערכת Openshift (קראו בהמשך על כך למי שמעוניין להתנסות אישית במחיר יקר של 0 שקלים) ויקים מערכת PKS, יראה את ההבדלים מהר מאוד. אגב, אחת האפשרויות שכיום אין ב-PKS ומאוד חשובה כשרוצים להוסיף ולהוריד מכונות וירטואליות המריצות קונטיינרים – כלל לא קיימת ב-PKS, אך קיימת בגירסת Openshift האחרונה.

וכאן אני מגיע להמלצה לא פופולרית שאני ממליץ: אל תרכשו PKS.

לא, זה לא קשור למחיר. מי שישווה בין Openshift ל-PKS יראה כי המחיר של Openshift ל-On Premise יותר יקר מ-PKS (בחלק מהמקרים, תלוי בחישובי ליבות, כמויות וכו')

הבעיה קשורה יותר ל-VMWare ולזמן הנוכחי. VMWare מציעה את PKS (גרסאות Essential, Enterprise) אבל אותה חברה גם מציעה את Tanzu Kubernetes Grid. היא מדברת על ניהול אשכולות של Kubernetes עם Tanzu Mission Control – אל תחפשו לרכוש או להוריד, זה מוצר של חברת Heptio (ש-VMWare רכשה) שעושים בו שינויים והוא כרגע בבטא ללקוחות VMware ולא זמין להורדה. יש גם את עניין ה-Health אשכול ה-K8S שלך והחלק הזה ממוצר וקוד מחברות ש-VMWare רכשה: Wavefront ו-CloudHealth.

בקיצור, VMWare מכינה איזה משהו גדול שמשולב מקוד ממקורות שונים שאמור לתת לך מענה מבחינת הקמת וניהול אשכולות K8S שונים הן מקומית והן בענן, אבל עד שזה יהיה מוכן ויציב – יקח זמן. כ-Enterprise, היציבות מאוד חשובה והדבר האחרון שאתם רוצים לעשות זה לעבור למשהו אחר השנה או שנה הבאה ולך תדע כמה זה תואם אחורה והאם המיגרציה תעבוד חלק…

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

לאלו שכן רוצים לנסות את Openshift על הדסקטופ שלהם (לא על ESXI או פתרון וירטואליזציה מרכזי, כל עוד יש לך 32 ג'יגהבייט זכרון, הגירסה המצומצמת שניתנת להורדה תופסת 16 ג'יגהבייט זכרון, לגמרי), מוזמנים לגלוש לקישור הבא. תצטרכו להירשם ל-רד-האט כדי להוריד "קוד סודי" ולהדביק אותו בזמן ההתקנה. האפליקציה נקראת Code Ready Containers והיא יכולה לרוץ על לינוקס, מק ו-Windows. המערכת משתמשת בוירטואליזציה במחשב המקומי כך שב-Windows היא תפעיל את אופציית Hyper-V. טיפ קטן: אם אתם מחוברים ל-Active Directory, תתחברו למכונה שלכם עם שם משתמש מקומי. באג ידוע.

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

אחסון: Scale Up מול Scale out (מאמר עדכון)

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

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

נתחיל בפתרון הפופולרי שיותר ויותר רוצים: פתרון Scale Out ובמקרה של VMWare מדובר כמובן ב-vSAN (עם Nutanix, Simplivity, Hyperflex הדברים מעט שונים). הדבר הראשון שצריך לקחת בחשבון זה עלות שדרוג רשיון ל-vSAN. בכל שרת שיש בו שני מעבדים, צריך לשלם כמדומני $5000 וזה רק על הרשיון, כלומר אם יש נניח 10 שרתים, אנחנו מדברים על $50K לפני שבכלל דיברנו על חומרה. אחרי שדיברנו על רשיונות, נדבר על דיסקים וסוג האחסון: Hybrid או All Flash, רובם כשהם מקבלים הצעות ל-All Flash ב-vSAN נרתעים מהמחיר אז נעבור ל-Hybrid. הדיסקים מקובצים כ-Disk Group. מבחינה טכנית, כל Disk Group יכול להכיל עד 7 דיסקים מכניים ודיסק SSD, המכניים הם ה-Capacity וה-SSD נקרא Cache. חישוב הדיסקים צריך להיות לפי רמת ה-RAID שאתם בוחרים, לפי כמות ה-Fault Domains, ה-Erasure Coding ועוד. לא מומלץ לנסות לחשב לפי Dedup מכיוון שיחס ה-Dedup הוא משתנה נעלם שמשתנה בהתאם לתוכן המאוחסן, כמות פעמים שאותם בלוקים מאוחסנים ועוד, למעוניינים – ניתן לקרוא יותר פרטים על כך כאן וכאן. נקודה חשובה לציון: VMWare גם נוטים להמליץ על דברים שייקרו את המערכת, כמו בקר RAID לכל קבוצת דיסקים (כי זה עוזר ב-Rebuild), תלוי במצב הקונפיגורציה שלכם, לא חייבים להקשיב ולרכוש. מה שכן, ותלוי בתקציב, מומלץ לרכוש SSD Mixed Intense ל-Cache (היחס קריאה כתיבה לדיסקים SSD שהם Read Intense הוא 80/20 או 75/25, ו-VMWare מבקשת 70/30 – לשיקולכם).

מכאן נעזוב את פתרונות ה-HCI ונעבור לאחסון כללי.

אין שום בעיה לאחסן 2-3 פטהבייט באחסון Scale Up. הנה לדוגמא JBOD של Western Digital שיכול לקבל עד 102 דיסקים מכניים של 12 טרהבייט ולתת כמות אחסון ברוטו של 1.2 פטהבייט. אפשר לשרשר קופסא כזו לעוד שלושה קופסאות נוספות כך שתיאורתית ניתן לאחסן ברוטו 3.6 פטהבייט. את הקופסאות האלו ניתן לחבר לשרת שמריץ את תוכנת האחסון (למען האמת, ניתן לחבר את זה כמעט לכל סטורג' חדש כיום, רק שיצרן הסטורג' לא יתמוך בכך מבחינת תמיכה ואחריות, אם כי יכול להיות שגם הוא מוכר משהו דומה) ואם רוצים – אפשר לחבר שתי קופסאות סטורג' ("ראשים") בתצורת High Availability ולקבל פתרון אחסון מעולה…

.. עד שמגיעים לבעיה המרכזית באחסוני Scale Up כאלו: אם בקר ה-SAS באחת מקופסאות ה-JBOD יתקלקל, פתרון האחסון יושבת (וכמובן השרתים המקושרים לו) ואנחנו מדברים על השבתה של מינימום 4 שעות במקרה הטוב, יום עסקים במקרה הפחות טוב, וכמה ימים במקרה הרע (מה לעשות, לא לכל יבואן יש כמה כאלו שהוא שומר בסטוק למקרה חרום, וכבר ראיתי מקרה כזה).

לכן חשוב להבין, מבחינת Scale Up, תיאורתית אפשר לאחסן בו המון, אך ככל שמכניסים יותר ויותר חלקים לפתרון (עוד בקרי RAID, עוד קופסאות JBOD וכו') הסיכוי להשבתה הוא יותר גדול, הזמן לבצע Rebuild לדיסק עם מספר דו ספרתי של טרהבייט – גודל בצורה משמעותית, ולכן מעשית – זה לא מומלץ

ב-Scale Out לעומת זאת, אפשר לשלב מספר קופסאות כמו הנ"ל בכך שנצוות קופסא מול שרת, מינימום שלושה שרתים (הכמות עולה במספר אי זוגי – 3,5,7 וכו' וכו') ואז גם אם יתקלקל JBOD, יתקלקל שרת אחסון Scale Out או שניהם ביחד – המערכת תמשיך לתת שרות. החסרון כמובן קשור לעלויות – צריך יותר שרתים יעודיים, צריך Backbone של 40 ג'יגהביט לפחות, סביר להניח שנצטרך שרת עם דיסקים SSD לצרכי Cache וכו', ולכן פתרונות כאלו מתאימים לפרויקטים גדולים כמו HPC, או Big Data ועוד, וכאן שימוש בפתרונות Scale Up לא יתן פתרון אחסון מהיר ויעיל. אותו דבר לגבי כמות אחסון – אם כל מה שאתה צריך לאחסן זה כמה עשרות או מאות בודדים (100-200) של טרהבייט, לך על Scale Up.

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

אבטחת מידע: קצת על Cloud Hopper

בעשור האחרון בעולם חל גידול מאסיבי בשימוש בעננים. יש כמובן את שלושת האמיגוס (אמזון,גוגל,מיקרוסופט) אבל ישנן חברות רבות, כולל יצרני שרתים, ספקי Hosting שונים ברחבי העולם שהציעו שרותים שונים, החל מ-Hybrid Cloud, תשתית "רק בענן" או שימוש בשרותים שונים כ-SAAS. האמת היא שברוב החברות בארץ ובעולם, יש לפחות שימוש בשרות SAAS אחד או יותר (זוכרים שפעם שרת המייל היה יושב בארגון, לדוגמא?)

הוול-סטריט ג'ורנל פירסם לאחרונה מאמר גדול וארוך על "פרויקט" בשם Cloud Hopper ומנויי WSJ יכולים לקרוא אותו כאן. מכיוון שרוב הגולשים כאן אינם מנויים על WSJ, הנה לינק למאמר סיכום של Fox Business על הנושא, ואני רוצה להרחיב בנידון בפוסט זה..

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

אחד הדברים המייחדים את הסינים בכל הקשור לריגול, גניבות, פריצות וכו' – זה הסדר שהם עובדים. אין "קפריזות". יש צוותים (שמוזכרים בקצרה בפוסט של Fox Business) וכל צוות אחראי על משהו אחר: צוות שאחראי על בדיקת הפריצות, על שמות משתמשים וסיסמאות שלא שונו, צוות שאחראי על מיפוי חוזר ונשנה של תשתיות החברות הנפרצות, צוות (גדול) שאחראי על התמודדויות מול אנטי-וירוסים, IPS/IDS, צוות שאחראי על כתיבת סקריפטים וכלים שונים כמו C&C, צוות שבודק פריצות חדשות שלא ידועות ציבורית, צוות שאחראי על קבלת Payload, רישומי דומיינים – ויש בוודאי עוד כמה צוותים.

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

פרויקט Cloud Hopper הוא פרויקט של הפורצים שמימן המשרד לבטחון הפנים הסיני. הקבוצה העיקרית שהיתה אחראית על הפרויקט נקראת APT10 וזו קבוצה סופר מתוחכמת שלא רק מכירה למי הם פורצים, הם בדרך כלל מכירים גם את רמת הידע של חברות שמנסות להגן על הלקוחות נגד פריצות וה-APT10 לא ממש ביישנים: הם יודעים מי מנסה "לצוד" אותם והם משאירים strings בכלים המותקנים על המכונות הפרוצות עם כל מיני הקנטות, כולל רמזים ללמוד איך עובד אנטי וירוס והמעקפים בכך שהם הפנו את ה-C&C לדומיין: gostudyantivirus.com ועוד (הטריק הזה אקסלוסיבי לא רק לסינים כמובן, גם החבר'ה ב-8200 ואחרים משתמשים בו)

קבוצת APT10 במסגרת Cloud Hopper החליטה למצוא לה אי שם ב-2014 מטרה חדשה: ספקי Cloud (או CSP כפי שזה מוכר יותר בשוק), לחדור אל תשתיות ה-CSP, להשיג הרשאות לתשתיות הוירטואליות של הלקוחות ופשוט להיכנס, לגנוב מידע, ולקפוץ (Hopping) מלקוח ללקוח באותה תשתית, כאשר לא מדובר בגניבה חד פעמית אלא מתמשכת.

ומי היו ה-CSP? אולי שמעתם את השמות, הכי מפורסמים הם HPE ו-IBM והיו עוד כמה עשרות CSP יותר קטנים. מי הלקוחות שנפרצו? גם כאן, אולי שמעתם עליהם: חברת Ericsson (כן, חברת התקשורת), פיליפס, חברת TATA ההודית, פוג'יטסו, ועוד רבים אחרים. המצב ב-HPE היה כל כך גרוע, שהפורצים פשוט "דרסו" כל נסיון חסימה מצד מנהלי אבטחת המידע של HPE והם נכנסו שוב ושוב לתשתית. אגב, ללקוחות ה-CSP לא הודיעו מאומה מחשש לתביעות (ואולי מחשש שהלקוח ינסה תוך שעות ספורות לעבור מיידית לספק אחר).

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

על ה-Cloud Hopper תוכלו לקרוא באתרים שונים, אבל אם יש משהו אחד שלא תמצאו שם – זה פריצה לשלושת האמיגוס. אין ספק שתוכלו למצוא מאמרים על פריצות לכל מיני מאגרים שהיו שמורים בתוך S3 Buckets שטיפשים לא הגדירו להם אבטחה מספקת, לתשתיות וירטואליות של לקוחות שהגדרות האבטחה בהן היו בדיחה – אבל לא תמצאו מאמרים על פריצות לתשתיות הפיזיות של AWS, GCP או Azure או לחלקים המאפשרים כניסה לתשתיות וירטואליות של לקוחות, מכיוון שאותה שלישיה בונה את הדברים בצורה שונה לחלוטין, משקיעה הרבה יותר מכל CSP שהחליט שזה אחלה רעיון לקרוא לעצמו "ענן", כולל השקעה בצוותים שאשכרה מנסים לפרוץ בכל דרך מבחוץ פנימה נון סטופ ומיישמים מיידית את הלקחים, במקום לסמוך על כל מיני חומות אש, IPS/IDS ו-MFA (להלן החדשות: רוב שיטות ה-MFA כבר נפרצו עוד לפני שנתיים!).

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

  • Firewall, IPS/IDS, Antivirus, Malware protection, עדכוני אבטחה – כל הדברים הללו נחמדים, אבל פורצים מקצועיים יודעים לעקוף את אותם כלים. אף אחד לא ינסה להיכנס ל-Firewall שלך ולשנות פורטים כי אין צורך בכך, וכל כלי שפורצים כותבים עובר בדיקה מול כל אנטיוירוס מסחרי אם הכלי מתגלה או לא (ואם כן אז משנים את הקוד), ולגבי IPS/IDS – ארמוז בעדינות שיש מספר דרכים לנצל חולשות שלו בתוך ה-LAN, ומדובר על רוב המוצרים המסחריים המצויים בשוק. לא קשה כל כך לזייף ב-Stream פיסות Headers.
  • כמו שמחליפים גירסת לינוקס או Windows, כדאי אחת לתקופה להחליף חלקים גדולים ממערך האבטחה – כלים, מתודות וכו'. תתחילו בשני דברים פשוטים: Zero Trust (זה מה שהשלישיה משתמשים), ו-U2F.
  • אתם מרימים תשתית וירטואלית בענן מקומי? (גם אם זה DR) – אל תתנו לאף אחד גישה ועדיף שזה יהיה על ברזלים ותשתית נפרדת שלכם, ואם צריך קו יעודי לכך שלא מחובר לתשתית של הספק בתוך ה-DC. לחשוב ש-VLAN מגן על משהו – זו בדיחה במקרה הטוב, לא מסובך לפורץ מקצועי להיכנס למתג. רק קחו בחשבון שספקים מקומיים ינתקו לכם את התקשורת אם אתם מותקפים ב-DDoS.
  • אם אתם מקימים תשתית וירטואלית אצל אחד משלישיית האמיגוס, תשתמשו בכלי אבטחה שלהם ולא בכלים צד ג'. הכלים של אותם ספקי ענן ציבורי הרבה יותר רציניים, מעודכנים תדיר (לא רק כשמגלים חור אבטחה וסוגרים אותו כמה ימים אחרי זה כמו אצל רוב הכלים המסחריים!), יכולים לבצע Scaling רציני ומנוסים שוב ושוב על ידי מאות אלפי לקוחות. להגדיר Security Groups ולחשוב שאתם מאובטחים – אתם ממש לא.
  • "התקמצנות" במפתחות פרטים/ציבוריים. רוצים לבצע Passwordless SSH? תשאירו את זה בצורה סופר מצומצמת לצרכי אוטומציה. בשאר המקרים – תקנו Yubikey ותשתמשו בו או מפתח Titan מ-גוגל. אפשר גם 2FA אבל תיזהרו לא ליפול לטריקים כאלו. זיכרו: העצלנות היא הגורם מספר אחד לפריצות קלות.
  • בעננים ציבוריים במיוחד – אף ספק ענן ציבורי לא נותן לך אבטחה כברירת מחדל ולכן תצטרך להשתמש בשרותים שלהם לצרכים אלו, ב-AWS יש רשימה שלמה, תעברו עליה, תבחרו ותגדירו את מה שאתם צריכים (הנה גם ל-Azure, אל תאכלו לי את הראש)
  • אני ממליץ לחשוב מחדש (לכיוון ויתור) על שירותי ניהול מרוחקים. אתם יכולים להגן על התשתית שלכם כמה שתרצו אבל אם עובד משרותי הניהול הוא סופר אהבל ופורצים למחשב הנייד/נייח שלו – ההגנות שלכם לא שוות כלום ומכיוון שיש לו הרשאות admin ברוב המקרים (כי הם מנהלים את התשתית) – יהיו לפורץ את אותן ההרשאות.
  • בדיקות Pen testing זה נחמד, אבל זה עובד מול שורת פריצות ופרמטרים ידועים מראש בתוך הכלי. רוצים להיות יותר בטוחים שאתם מוגנים? תשכרו מישהו שאשכרה ינסה לפרוץ בצורות קצת יותר .. מקוריות.

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

תשתית מקומית וענן: חסכון – צו השעה

כמעט בכל חברה מגיע מצב שאחת הסיטואציות הבאות מתרחשות:

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

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

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

אז איך בעצם ניתן לחסוך?

בכל הקשור לתשתית מקומית, ההמלצה שלי במקרים רבים היא לפני שאצים רצים לרכוש שרתים חדשים לדוגמא, לשדרג את הקיימים. תחליפו מעבדים לכאלו עם יותר ליבות, תוסיפו זכרון, אם אתם עובדים עם דיסקים מקומיים – תחליפו אותם ל-SSD טובים וכו'. אם לדוגמא רכשתם (בחוכמה) שרתים כמו של חברת SuperMicro, אז אתם בכלל יכולים לעבור קדימה דור של מעבדים (לדוגמא: V3 ל-V4 או Xeon SP דור ראשון לדור שני) – כלומר בלא מעט מקרים ניתן לשדרג תשתית קיימת של שרתים ולהרוויח ביצועים יותר גבוהים, וזאת במחיר קטן בהרבה מרכישת שרת חדש (מה גם שהשדרוג נתמך לחלוטין על ידי היצרן והמפיץ)

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

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

  • להפסיק לחשוב על הענן הציבורי כ-DC פרטי שלנו. ב-VMware, כשמקימים מכונה מקומית וכשאתה מגדיר VM עם 16 ליבות או חצי טרה אחסון (ב-Thin Provisioning) – אז המערכת תהיה מספיק חכמה לתת לך משאבים, אבל לא לחסום את המשאבים הללו משימוש מכונות VM אחרות. בענן ציבורי – אתה משלם על כך, גם אם השתמש באחסון ב-2% ובמעבד ב-4%, אתה תשלם כאילו ניצלת את הכל, אז במקרים כאלו, כדאי לשנות Instance או לבנות אותה מחדש עם משאבים יותר מצומצמים.
  • לנטר ולצמצם – כלים כמו Terraform יודעים היטב לתמוך בכל ספקי הענן הציבורי. נכון, זה לא בדיוק "קליק קליק קליק" אבל בהחלט שווה להשקיע וללמוד ואז להתחיל להריץ את זה על החשבון שלכם ולמצוא מה המשאבים שאינם מנוצלים, דברים שהוגדרו בפראות אבל לא ממש משומשים וכו' – ומשם להחליט מה לעשות עם זה. החסכון בשיטה הזו – גדול מאוד.
  • להפסיק להתעצל! אתה צריך SQL שכל מה שמתחבר אליו זה client ורבע? תקים קונטיינר או Instance כזה בעצמך במקום להשתמש בשרות מנוהל. זה יותר זול. נכון, צריך להשקיע קצת יותר בהקמה והגדרה, אבל זה חוסך בטווח הארוך.
  • לעבור לקונטיינרים במקום מכונות וירטואליות – קונטיינר תופס פחות משאבים, ניתן לרפלק, ויש לו Scaling מעולה. אה, ובחישוב סופי, זה יוצא יותר זול.
  • לבחור תוכנות אחרות שהן יותר "Native" לענן – תוכנות שיודעות לאחסן ב-Object Storage לדוגמא, שהוא הרבה יותר זול מאחסון שמחובר ל-Instance, וזו רק דוגמא אחת.
  • לכבות מכונות – מכונה כבויה עולה הרבה פחות ממכונה פעילה (אתה עדיין צריך לשלם על האחסון שהיא תופסת), אז אולי הגיע הזמן לאיזה סקריפט קטן שרץ על כל המכונות ומכבה כאלו שלא עושות כלום, ואגב, עדיף להגדיר עם Terraform שמכונות מסויימות יכובו אוטומטית (או ימחקו) לאחר זמן מה, כמו מכונות טסטים שהוקמו זמנית ושכחו מהן.

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

אחסון: שכבה חמה, שכבה קרה, דברים שחשוב לדעת

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

בעבר, פתרונות אחסון של חברות כמו NetApp ו-EMC כללו בתוכן מספר שכבות:

  • שכבה מאוד מהירה – שהיתה מורכבת ממקלות זכרון בלתי נדיף (NVRAM)
  • בחלק קטן מהמקרים, שכבה מהירה נוספת – RAM מגובה סוללה
  • שכבת דיסקים SSD ("שכבה חמה")
  • שכבת דיסקים מכניים (SAS או SATA) ("שכבה קרה"

עם התפתחויות הטכנולוגיות השונות, כמעט כל היצרנים ירדו משימוש ב-NVRAM (זה יקר מאוד ליצרן הפתרון אחסון, מה שכמובן מייקר את הפתרון ללקוח הסופי ומה שמקשה בתחרות מול יצרנים אחרים), וכיום בד"כ פתרונות אחסון משולבים (דיסקים מכניים ו-SSD) כוללים שכבה חמה קטנה שמורכבת מדיסקים SSD ושאר הדיסקים הם מכניים (כיום רוב היצרנים פשוט מכניסים דיסקים SATA, חלקם עדיין מוכר דיסקים SAS), כך שבסופו של דבר, כלקוח, כל היצרנים יציעו בפניך שתי אפשרויות (עם כל מיני תוספים כמובן): מערכת אחסון "היברידית" (מכנית, SSD) או AFA (כלומר All Flash Array) שמורכבת מדיסקים SSD. משהו חדש שנכנס לשוק (ולא ראיתי עדיין אותו בארץ) הוא "היבריד SSD" (שם שאני נותן עבור פוסט זה) כאשר רוב הדיסקים הם SSD Read Intence ומספר קטן של SSD הוא NVME Mixed Intense. לחברת לנובו יש מערכת שה-SSD Mixed Intense מוחלף בדיסקים Optane של אינטל, כדי לקבל מהירויות כתיבה גבוהות (אבל אותו סטורג' ספציפי יקר מאוד – הוא מתחיל ב-7 ספרות בדולרים).

כעת נתמקד במה שנקרא בחלק מהמקרים "שכבת ה-Cache". בעבר (ועדיין בחלק מהמקרים כיום) פתרון האחסון היה כולל מספר מצומצם של דיסקים SSD די קטנים (200-400 ג'יגהבייט), מטרתם היתה אחת: לקבל את כל המידע שאמור להיכתב לתוך פתרון האחסון, לאשר ל-client שהמידע נכתב (מה שנקרא sync) וברקע להעביר את המידע לדיסקים המכניים שמטבע הדברים הם איטיים בהרבה מאותם SSD. ה-SSD שהיו אז היו דיסקים קטנים ויקרים להחריד, הואיל ותאי ה-Flash שלהם הכילו מקסימום מספר אחד בכל תא (מה שנקרא Single Level Cell, או SLC), כיום רוב מוחלט של הדיסקים מכיל Flash עם תאים שיכולים להכיל שני מספרים בכל תא (MLC) או שלושה מספרים בכל תא (TLC). הכלל הפשוט הוא שככל שמאחסנים יותר מספרים בתא, הכתיבה את התא (ובעצם אל שבבי ה-Flash ב-SSD) יותר איטיים, ולכן – כאשר חושבים לרכוש פתרון אחסון ומקבלים מפרט, חשוב מאוד לשאול מה סוג התאים ב-SSD: האם הם MLC (ונגזרותיו, בכולן מופיעות האותיות MLC) או TLC או QLC (שזה הכי איטי ולמעט ארכיבאות אני לא ממליץ אותו לשום פתרון אחסון). לא תמיד אפשר לדעת זאת הואיל וכל יצרן פתרון אחסון נותן שמות אחרים ל-SSD מהשמות שהיצרן SSD נותן למוצריו, ולכן צריך "לדוג" קצת. אפשרות אחרת לדעת – היא לבדוק האם ה-SSD הוא Read Intense או Mixed Intense (ה-Mixed Intense מתאים לעבודות שכמות הקריאה והכתיבה די שווה, ולכן הוא אידיאלי לשמש כ-Cache בפתרון אחסון). הטובים ביותר הם MLC או Mixed Intense.

זוכרים את הדיסקים הקטנים מהפיסקה הקודמת? איתם קשה לבנות Cache אלא אם רוצים לשרוף כספים כאילו אין מחר. כיום לעומת זאת, דיסקים שהם Mixed Intense שהם מעולים לצרכי Cache – יכולים לתת ביצועים מעולים לא רק בכתיבת ה-DATA מבחוץ אל תוך פתרון האחסון, אלא גם לשמש כ-"שכבה חמה". חישבו על כך: 4 דיסקים SSD בתצורת Mixed Intense בגודל 4 טרהבייט פר דיסק יתנו לנו 16 טרהבייט נטו של "שכבה חמה" (הדיסקים הללו מוגדרים בחיבור כ-RAID-0 הואיל וכל הנתונים שנמצאים שם – זמניים, ה-DATA כולו מאוחסן בשאר הדיסקים שאינם מוגדרים כ-Cache), ועם כמות כזו של Cache (שבעצם משמש כ"שכבה חמה") רוב הקריאות נתונים לדוגמא יקראו מאותם רביעיית SSD, ומכיוון שאלו דיסקים בחיבור NVME, אנחנו יכולים לקבל מהירות קריאה של 12-14 ג'יגהבייט לשניה (תיאורתית, צוואר הבקבוק שלכם במקרים כאלו יהיו הסיבים או כל סוג חיבור אחר, לא הדיסקים).

לכן, כיום, אם מישהו רוצה לפתרון האחסון שלו "שכבה חמה", והוא רוכש אחסון היברידי (מכניים ו-SSD), הוא צריך לוודא כי ישנם מספר SSD שהם Mixed Intense ואם אפשר – בחיבור NVME. אל תרכשו דיסקים SSD גדולים לצרכים כאלו (8-10 טרהבייט ומעלה) מכיוון שהם מאוד יקרים. עדיף לרכוש 4 של 4 מאשר 2 של 8 טרהבייט ושכל אותם SSD בפתרון ההיברדי מוגדרים כ-Cache (זה מה שיוגדר כברירת מחדל במערכת פתרון האחסון). במערכות AFA אין צורך בכך הואיל וגם SSD בחיבור SATA יתן מהירויות קריאה מהירות מאוד ובכך פתרון זה מייתר את הצורך ב"שכבה חמה". אגב, AFA שכולו מלא ב-SSD עם NVME יהיה תמיד "חנוק" מבחינת רוחב פס החוצה אלא אם יש Backbone של 100 ג'יגהביט ומעלה.

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

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

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

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

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

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