וירטואליזציה כקוד פתוח – כפתרון טוב

לפני כשבועיים פרסמתי את הפוסט הזה שמדבר על פתרונות אלטרנטיביים ל-vSphere של VMWare. הפעם אני רוצה לדבר על פתרונות קוד פתוח כפתרונות טובים לוירטואליזציה ומדוע RHV/oVirt הוא פתרון שעולה על רוב פתרונות הקוד הפתוח.

פתרונות וירטואליזציה בקוד פתוח מתחלקים בעצם ל-2: אלו שמעוניינים לנהל מספר קטן של שרתים פיזיים וצרכי הוירטואליזציה שלהם בסיסיים, ואלו שמעוניינים בפתרון וירטואליזציה מלא כולל הדברים המתקדמים, משהו כתחליף ל-Hyper-V (עם הניהול המרכזי) או תחליף ל-ESXI+vCenter.

כשמדובר בצרכים בסיסיים לוירטואליזציה ומדובר בכמות קטנה של שרתים (נניח 2-5), ומדובר, לשם השוואה, בדברים ש-ESXi עצמאי (ללא vCenter) יכול לתת – אז הפתרונות שהצעתי בפוסט הקודם יכולים לתת זאת ללא בעיה. יותר מכך, כל הפתרונות (למעט שימוש ב-KVM וב-libvirt עם סקריפטים) שהצעתי גם יכולים לתת לכם ניהול מרוכז של השרתים שלכם בממשק Web.

לעומת זאת, כשאנחנו מעוניינים בדברים יותר מתקדמים כמו:

  • שימוש ב-vSwitch (בגירסת הקוד הפתוח – Open vSwitch) כ-SDN
  • הקמה אוטומטית של מכונות VM
  • שימוש ב-Grafana לתצוגת מצבי מכונות, דיסקים, מעבדים וכו'
  • High Availability מלא
  • אופטימיזציה לשימוש ב-NVME SSD תוך הגדלת I/O Threads
  • תמיכה מובנית ב-DR
  • יצוא/יבוא OVA/OVF
  • תמיכה במעבדי Power של IBM
  • תמיכה בכל פרוטוקולי הסטורג' (NFS, iSCSI, Fiber) + דיסקים מקומיים ו-GlusterFS
  • תמיכה במעבדים חדשים (EPYC, Xeon SP – ברוב הפתרונות המוצעים זה לא יעבוד טוב, במיוחד כשמדובר ב-HA).
  • ניהול מרוכז של כמות שרתים גדולה (עד 400 מכונות פיזיות)
  • פרופילים (סוגי מכונות, גדלים ועוד) כולל High Performance VMs.
  • תמיכה מורחבת ל-Over Commit
  • יבוא/יצוא של Images מ-OpenStack Glance (לא חייבים OpenStack מותקן בחברה).
  • פורטל למשתמשים (לאלו שצריכים לגשת למספר מכונות VM, ולנהל את אותן מכונות VM)
  • תמיכה במספר סוגי LDAP (כולל AD)
  • התממשקות ל-vCenter ויבוא מכונות VM
  • אפשרות לעבוד במצב הרגיל או במצב HCI.
  • תמיכה מלאה ב-GPU וב-VDI.
  • ועוד הרבה פונקציות אחרות.

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

האם פתרון כמו RHV/oVirt יכול להיות תחליף מלא ל-vSphere? התשובה היא: עדיין לא. העניין קשור יותר ל-Kernel ולדברים מתקדמים אחרים שלא קיימים ב-RHEL-7/CentOS-7 (שעליהם oVirt/RHV רץ):

  • Fault Tolerance עדיין לא זמין בגירסה הנוכחית (4.2)
  • VAAI/VVol – יש תמיכה ב-Kernel 4.X כך שנצטרך להמתין ל-RHEL-8/CentOS-8.
  • תוספים כמו vRealize ואחרים (שהם בתשלום) – יש להם חלופות. חלקם בחינם, חלקם בתשלום.

בכל הקשור לפתרונות וירטואליזציה, הגענו לזמנים טובים, למען האמת. רק לפני 3 שנים אם חברה גדולה היתה שואלת אותי לגבי פתרונות אחרים ל-VMWare או Hyper-V, הייתי ממליץ להם לנהל מו"מ בינם לבין מיקרוסופט ו-VMWare כי הפתרונות לא היו מספיק לדעתי טובים לשום Enterprise. פתרונות כמו Proxmox או פתרונות מבוססי Xen היו קיימים, אך לדעתי הם אינם נותנים מענה מספק ל-Enterprise (אם כי הם היו בהחלט יכולים לתת מענה לעסקים קטנים). בשנים האחרונות, החברה שהשקיעה הכי הרבה בפיתוח פתרון וירטואליזציה טוב היתה דווקא רד-האט. המצב בשוק פשוט התהפך: מיקרוסופט ו-VMWare היו עסוקים בפתרונות וירטואליזציה ואילו רד-האט היו עסוקים בפיתוח פתרונות מבוססי קונטיינרים (OpenShift) וב-3 השנים האחרונות רד-האט משקיעה הרבה יותר בפיתוח פתרון וירטואליזציה וגם בשיפור OpenShift, בשעה שמיקרוסופט ו-VMWare בשנתיים האחרונות יותר מתעסקים בפתרונות קונטיינרים.

לסיכום: שום פתרון (פתוח או סגור) אינו Drop In Replacement. לכל פתרון יש יתרונות וחסרונות וכדאי לשקול את הדברים. בכל מקרה תהיה תקופת מעבר ויהיה צורך לפתור לא מעט בעיות. פתרונות בקוד פתוח לא מחייבים תשלום Up front (למעט במוצר מסחרי כמו RHV, אם כי יש Trial חינמי), אבל כן מחייבים יעוץ, אינטגרציה והדרכה – שזה כן עולה כסף.

תובנות על OpenShift בחברות גדולות

יוצא לי בלא מעט מקרים לתת יעוץ לחברות גדולות לגבי עניין המעבר ל-Devops, שימוש בקונטיינרים, Docker, שימוש ב-Jenkins ושאר כלים. כמובן, כמו תמיד, בחברות גדולות, אף אחד אינו רץ להטמיע טכנולוגיה זו או אחרת רק בגלל שחץ בן חמו (או נציגי Presale של רד-האט, אין לי קשר אליהם) המליץ עליה. יחד עם זאת, בדרך כלל ההמלצה שלי לפני שמרימים אפילו PoC של OpenShift – אני מבקש מהחברה שתתן לי להיות "הטיפש" – להיות עם צוות שינסה את הדברים החדשים ובעצם ללמוד את התהליכים שהצוות משתמש בהם – החל מכתיבת קוד, שימוש ב-SCM, קומפילציה, טסטים, תהליכים נוספים עד לתוצר הסופי (קבצים בינאריים, Artifacts וכו').

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

  1. ניהול קוד (Source Code Management – SCM)
    ברוב המקרים שישבתי לפגישת היכרות ושיחה על המערכות הקיימות, בד"כ מערכת ניהול הקוד היתה TFS של מיקרוסופט או בחלק מהמקרים SVN. מקומות בודדים הכניסו איזו "תת מערכת" של GIT (בשימוש של Gitlab או BitBucket).
    הבעיה: שום מערכת קונטיינרים המבוססת על Kubernetes לא תומכת באופן רשמי לא ב-TFS ולא ב-SVN. כולן תומכות באופן טבעי ב-GIT.
    הפתרונות שיש הם מאוד עקיפים:
    עם TFS יש פתרון די עקיף לבעיה כפי שמוסבר כאן.
    עם SVN הפתרון הוא למשוך את הקוד למכונה מקומית שמחוברת לשרת GIT, ולאחר מכן לבצע Commit, Push לשרת ה-GIT המקומי. זה פתרון די "מכוער" ובעייתי מכיוון שאם מישהו שכח להוריד ולהעלות קוד ל-GIT, ה-Build יהיה בעייתי. אגב, שרת SVN הוא יחסית קל מאוד להמרה ל-GIT, במידה והחברה מעוניינת לעבור ל-GIT.
  2. מכונות Windows ולינוקס ביחד.

    לא מעט חברות גדולות כותבות קוד ל-Windows וסקריפטים ל-Windows (ראיתי גם מקרים של Build ל-JAR/WAR שכתובים ב-Batch file), וכאן ישנה בעיה מהותית – Kuberenetes בעצמו לא רץ בצורה טובה על Windows והפתרון שיגיע בשנה הבאה יאפשר גם ל-Kubernetes וגם ל-OpenShift להשתמש ב-Nodes שהם גם Windows וגם לינוקס (אם כי שרתי ה-Master וה-Infra יצטרכו להיות מבוססי לינוקס).
    עד אז תהיה בעיה לקמפל קוד בצורה יציבה של דברים כמו DOT Net (כדאי לעבור ל-Dot Net Core שנתמך ורץ על לינוקס), ויהיה צורך להמיר קבצי batch ל-shell כדי לקמפל את הדברים על Windows.

  3. בחירת אסטרטגיה ב-OpenShift
    באופן עקרוני, שימוש ב-OpenShift מחייב בחירת אסטרטגיה, ו-OpenShift תומך ב-4 אסטרטגיות פופולריות: Docker, Source to image (S2I), Jenkins Pipeline ו-Custom (שהוא מאוד מתקדם וברוב המקרים לא יהיה בו שימוש אלא במקרים מיוחדים ששאר האסטרטגיות אינן עונות על כך)

    1. אסטרטגיית Docker מאפשרת שימוש ב-Images קיימים מבחוץ (ממקומות כמו Docker Hub לדוגמא) ושניבנו פנימית כחלק מהרמת אפליקציות. יש עם האסטרטגיה הזו 3 בעיות:
      1. רוב ה-Images שתמצאו בחוץ לא יפעלו עם OpenShift כי הם רצים כ-root ו-OpenShift בנוי בראש ובראשונה לאבטחה הדוקה ולכן הוא חוסם מיידית הרצה של Images כאלו (אפשר לבטל זאת אבל אז מישהו יחטוף על כך ממחלקת אבטחת מידע)
      2. בלא מעט מקרים שוחררו Images שמריצים מספר אפליקציות במקביל בתוך אותו Image וזה הורס כל דבר שקשור לגדילה רוחבית (Scaling) ולכן לא מומלץ להשתמש ב-Image כזה.
      3. טכנית, מבחינת אבטחה בקונטיינרים, דברים צריכים לרוץ רק ב-Foreground ולא ב-background ולכן קונטיינרים שיריצו דברים ב-background (שרותים כמו nginx, apache, postfix ועוד ועוד) – הקונטיינר "ימות" לאחר זמן קצר והמערכת תנסה להקים אותו שוב ושוב, מה שיצור loop (במיוחד אם מופעל Replication Controller – RC).
    2. אסטרטגיית Source to image (כלומר S2I): עם אסטרטגיה זו מערכת OpenShift מושכת ImageStream (כלומר Image "שלד"), יוצרת Image חדש שאליו היא "שופכת" את הקוד מ-GIT, מבצעת שינויים שצריך (הרשאות, התקנת קבצים נוספים כמו דרך PHAR ב-PHP או NPM עבור Javascript ועוד ועוד), ולבסוף בונה Image סופי שאותו המערכת מריצה ומקימה POD עם קונטיינר המכיל את ה-Image. באסטרטגיה זו ניתן "לקשור" (דרך Webhook) בין REPO של GIT לבין אפליקצייה ב-OpenShift וברגע שיש שינוי ב-GIT, המערכת תבנה אוטומטית Image חדש וכשתסיים היא תוריד את ה-POD הקיים ותפעיל מיידית את ה-POD עם הקונטיינר החדש (ניתן כמובן לבצע Blue/Green Deployment – פרטים כאן וזה קיים לא רק ברמת אפליקציות אלא גם ברמת מכונות)
    3. אסטרטגיית Jenkins: עם אסטרטגיה זו אנחנו מגדירים הכל מראש: מאיפה הקוד ימשך, מה ה-pipelines וכו' וכו' ו-OpenShift יקים בכל פעם קונטיינר Jenkins, יקמפל, יריץ את ה-pipelines, יפזר מה שצריך לפזר, יבנה Image חדש ויריץ POD עם קונטיינר המבוסס על ה-Image החדש. הדרך הזו יכולה להתאים לאלו שכבר משתמשים ב-Jenkins על לינוקס.

ישנם עוד חלקים הקשורים להקמת מערכת שיש צורך לערב הן את מחלקת אבטחת מידע והן את צוות ה-Storage. בגופים פיננסיים ובטחוניים יהיה צורך לשים דגש על שרתי Registry מקומיים (לחשיפה מופחתת לאינטרנט, אבל עדיין יש צורך לשאוב קבצי Image, בלי זה אי אפשר להקים שום דבר, ואין זה משנה אם מדובר ב-OpenShift או בכל מערכת אחרת מבוססת Kubernetes), שילוב עם Active Directory, הרשאות וכו' (מובנה ב-OpenShift, לא קיים ב-Kubernetes) ועוד דברים רבים.

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

חושבים לעבור לפתרון וירטואליזציה אחר?

עדכון על Hyper-V מופיע לקראת סוף המאמר.

אנחנו נמצאים ב-2018 וחברות רבות עוברות לענן ומתחילות לקצץ בתקציב רשיונות הוירטואליזציה שלהן, מנויי תמיכה וכו'.

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

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

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

  • לקוח רוצה להריץ מס' חד ספרתי של מכונות וירטואליות, אבל מצד שני הוא רוצה HA (כלומר High Availability) כך שאם נפל שרת אחד – השרת השני עושה pick up והמכונות ממשיכות לעבוד
  • לקוח אחר רוצה לתת שרותי Hosting ללקוחות שלו, יש לו אלפי מכונות וירטואליות אבל אין לו תקציב לרכוש מ-VMWare (אגב, רק לידיעה: VMWare דורשת 50$ פר מכונה וירטואלית מחברות Hosting, גם אם מריצים רק את ESXi החופשי).
  • לקוח אחר מעוניין בפתרון קוד פתוח ולא משהו קנייני להריץ כמה עשרות מכונות וירטואליות עבור העסק שלו.
  • לקוח אחר רוצה את הכל: תתחיל ב-FT, תכלול DR, תכלול HA, סוויצ'ים וירטואליים מורכבים, תמיכה ב-RDMA, NFS, iSCSI, templates ועוד ערימת דברים – אבל לא מוכן לשלם את המחיר ש-VMWare רוצים פר שרת פיזי.
  • לקוח אחר "להוט" מאוד על HCI – הוא רוצה המלצה אם ללכת על vSAN, Nutanix, Simplivity (אחד מהם).
  • ולקוח אחר מעוניין פה ועכשיו בהצעה על OpenStack כפתרון וירטואליזציה חלופי/משלים למה שיש לו כיום.

הבה נכיר את הפתרונות:

VMware
ה"מלכה" הבלתי מעורערת לפתרונות וירטואליזציה. בין אם יש לך בתשתית שרת אחד או 5000 שרתים פיזיים –  המערכת תומכת בצורה מעולה. יש אלפי פונקציות ואפשרויות להתרחב לכל דבר הקשור לוירטואליזציה.
הבעיה העיקרית: המחיר. גירסת ה-ESXi שמותקנת על השרת קיימת כגירסה חינמית, אך כמות הפונקציונאליות מוגבלת ולשם ההרחבה יש לרכוש את vCenter שקיימת במספר גרסאות, ואם יש לך עד 3 שרתים – תוכל לרכוש את רשיון ה-Essentials של vCenter ולנהל במרוכז את השרתים במחיר של 500$, אבל גם אז הפונקציונאליות די מוגבלת. רוצה יותר? תתחיל לשלם פר מעבד אלפי דולרים וגם לרשיון היותר מתקדם של vCenter תצטרך לשלשל עוד כמה אלפי דולרים, ועוד לא דיברנו על תמיכה שנתית – שגם היא עולה כמה אלפי דולרים. בקיצור – הסיבה שרבים מחפשים אלטרנטיבות היא לאו דווקא בגלל מגבלות טכניות, אלא בגלל מגבלות תקציביות.

OpenStack
דמיינו לכם את הדבר הבא: אתם נכנסים לסופרמרקט הקרוב ורוכשים לכם 3-4 קרטונים של חלב, אתם משלמים ויוצאים. מה יש לכם בשקית? 3-4 קרטונים של חלב וזהו. עם OpenStack, אתם מקבלים לא רק את הקרטונים של החלב, אלא גם את המחלבה, הרפת והפרות!

טכנית, OpenStack עושה המון דברים (תסתכלו כאן כדי לראות כמה פרויקטים יש בתוך OpenStack), וירטואליזציה זה רק אחד מהדברים, ואם אתה רוצה אחסון – אז יש לך 3 חלקים (Object, File, Block כל אחד מהם שונה). נכון, אפשר להתקין רק חלקים מסויימים (או להתקין הכל ולהשאיר לכל מה שצריכים ברירות מחדל), אך עקומת הלימוד בהשוואה לשימוש ב-Hyper-V או VMWare – מאוד גבוהה. יהיו כמובן חברות שיש להם את הצוותים שיכולים להתעסק בכך (ויש במה להתעסק, כיום OpenStack מורכב מיותר מ-1800 חבילות!), אבל אז מגיעות 2 נקודות שכדאי לתת עליהן את הדעת:

  1. גירסת OpenStack משתחררת כל חצי שנה עד שנה בערך. מכיוון שבחברות נהוג לעדכן כל 3 שנים, השדרוג לגירסה האחרונה יהיה קשה עד בלתי אפשרי כי בדרך כבר עברו כמה גרסאות (ואף אחד לא מבטיח תאימות).
  2. חברות מסחריות ירצו את ה-OpenStack המסחרי שהגירסה שמשוחררת ונתמכת ל-5 שנים, יצטרכו להתכונן למחיר ממש לא זול. גירסת רד-האט לדוגמא עולה כ-10,000$ לשרת עם 2 מעבדים (הממ, פתאום המחיר של VMWare לא נראה כזה יקר). חברות כמו SuSE וקנוניקל מוכרות במחירים יותר זולים, ואכן – אם חברה מחליטה ללכת לרכוש OpenStack אני ממליץ לה לרכוש זאת מ-SuSE (התמיכה של קנוניקל לא משהו, בלשון המעטה). במילים אחרות – אם אתה מחפש OpenStack שיחזיק כמה שנים טובות ובחינם – לא ממש תמצא זאת. זה לא CentOS.

Xen
טכנית, Xen הוא פתרון וירטואליזציה טוב כשמדובר על כמות שרתים פיזית קטנה. הוא נותן ביצועים טובים, יש ממשק Windows (למעוניינים, אפשר לעשות כמובן הכל בלינוקס ישירות). הבעיה המרכזית עם Xen הוא שהפרויקט עצמו בקושי "חי". Xen יוצא בגרסאות יותר חדשות (4.10.1 זו הגירסה האחרונה), אבל כשזה מגיע לחברות, הן רוצות תמיכה. Citrix מוכרת את Xen ונותנת שרות, אבל זול – הוא לא (3,000 דולר פר מכונה עם 2 מעבדים). הסיבה שאני לא ממליץ על Xen של Citrix היא שהחברה פיטרה מחצית מהעובדים שעבדו על Xen ונתנו לו שרות ולא נראה ש-Citrix תמשיך לקדם ולפתח את מוצר ה-Xen שלה. חברה אחרת שמוכרת את Xen תחת שם אחר היא חברת Oracle (היא לא מזכירה את השם "Xen" בשום מקום בתיעוד השיווקי) והמוצר נקרא Oracle VM Server.

Proxmox
תוכנת Proxmox היא אחת מהוותיקות בשוק שהלכה וגדלה עם השנים, הוסיפה תמיכה למכונות וירטואליות (מבוססות KVM, כמו רוב הפתרונות מבוססי קוד פתוח שמוזכרים כאן), תמיכה לקונטיינרים (לא Docker אלא LXC), תמיכה ל-ZFS, NFS, iSCSI, GlusterFS ועוד. זו תוכנה שמומלצת לאלו שרוצים לנטוש את Xen, לעסקים קטנים שיש להם שרות מאינטגרטור בארץ (השרות המקורי ניתן רק ב-tickets ואין אפשרות SLA, רק NBD מיצרנית התוכנה עצמה). התוכנה גם יכולה להתאים לעסקים קטנים והקהל שהכי "אוהב" את התוכנה אלו חברות ה-Hosting ששם דברים כמו Live Migration, HA וכו' אינם כה חשובים.

KVM/Libvirt/אוטומציה
פתרון שיכול להתאים לחברות שיש בהם מפתחי לינוקס (והמון זמן פנוי) הוא שימוש ב-KVM שמגיע עם כל הפצת לינוקס ושימוש בספריית Libvirt לבנות מערכת וירטואליזציה. הספריה מאפשרת את כל הדברים הבסיסיים ואת כל השאר ניתן לבצע עם אוטומציה בכלים כמו Ansible/Puppet/Chef וכו'. היתרון הגדול בשיטה זו הוא שהכל נמצא בתוך החברה ואם יש תקלה, היא מטופלת פנימית.

oVirt
תוכנת oVirt שנכתבת ע"י רד-האט היא אחת התוכנות שמכוונת ישירות להתחרות ב-vSphere. (שימו לב: גירסת הקוד החופשי נקראת oVirt, הגירסה המסחרית [שמבוססת על אותו קוד] נקראת RHV). ב-oVirt יש בעצם כמעט את כל מה שאתם מקבלים ב-ESXi עם vCenter, היא יכולה לעבוד גם בתצורות של מאות ואלפי שרתים פיזיים מצד אחד, אבל היא גם יודעת להתרחב לאזורים "קרובים" לוירטואליזציה (כמו הרצת Images מ-OpenStack ובגירסה הקרובה כנראה תהיה גם תמיכה לקונטיינרים). היא יודעת להתממשק לפרטוקולי הסטורג' הידועים (NFS, iSCSI וגם GlusterFS ו-Ceph [דרך Cinder]) וגם להתחבר ישירות אל שרתי ה-ESXi או אל ה-vCenter שלכם כדי להמיר מכונות ל-oVirt/RHV. בנוסף, oVirt/RHV היא התוכנה היחידה מתוכנות הקוד הפתוח שיכולה לעבוד גם במצב קלאסי (התקנה של התוכנה במכונה אחת, בשאר מתקינים גירסת Node) או במצב Hyper Converge. בנוסף, זו התוכנה היחידה שיש לה גם Client לאנדרואיד כדי לבדוק מה קורה ולטפל בתקלה מרחוק ללא צורך במחשב.

לחברות המעוניינות ב-RHV (כלומר בגירסה המסחרית), המחיר די זול (יחסית): 1000$ לשנה למכונה עם 2 מעבדים ותמיכה בשעות העסקים או 1500$ לתמיכה של רד-האט 24/7.

פתרונות HCI
מוצרים כמו Nutanix/Simplivity/VSAN/RHV מציעים בעצם שרתים עצמאיים שלא זקוקים ל-Storage חיצוני והם נותנים הכל בפתרון אחד. אלו יכולים להיות פתרונות מעולים, אולם חשוב לזכור שבמרבית המקרים תצטרכו להחליף שרתים (אם יש לכם שרתים ישנים) ובמקרה של vSAN אם תרצו תוצאות ממש גבוהות, תצטרכו דיסקים SSD NVME מסוג Mixed Intense (מה שאומר שתצטרכו לרכוש Backplane נוסף לשרת ל-4 כוננים, שרתים נמכרו בשנים האחרונות ללא Backplane ל-NVME וזה "אקסטרה") כחלק מכל קבוצת דיסקים. בפתרון של VMWare ניתן לעבוד "גם וגם" כך ששרתים ישנים שעובדים מול סטורג' יוכלו להמשיך לעבוד כרגיל. החסרון העיקרי של VMware vSAN הוא המחיר: תוספת של 5000$ פר שרת עם 2 מעבדים – וזה לפני המחיר של הציודים ובנוסף למחירי הרשיון האחרים ש-VMWare מבקשת.

פתרונות ל-VDI
גם מיקרוסופט, גם VMWare, גם Citrix וגם חברות אחרות מציעות פתרון VDI. את הפתרונות הללו אני מגדיר כלא יותר מ"בסדר". אלו פתרונות טובים לעובדי משרד, שמריצים דפדפן, אופיס, ואולי עוד כמה אפליקציות משרדיות, אבל כשזה מגיע לוידאו ותלת מימד – הפתרונות האלו כיום אינם משהו לרוץ לספר לחבר'ה. הסיבה לכך שמי שקובע את הדברים הם יצרניות ה-GPU והפתרונות שהם מציעים מתאימים לדברים שתיארתי לעיל ותו לא. מי שלדוגמא ישתמש ב-RemoteFX יגלה שמבחינת תמיכת OpenGL התמיכה היא חלקית ועל עריכת וידאו או דברים כאלו כבדים – תשכחו מזה. לאמזון יש פתרון שהוא יותר מתקדם ממה שהחברות שציינתי נותנות אבל גם הפתרון שלהם הוא לא בדיוק העלית שבעלית.

מבחינת קוד פתוח, ישנם כמה פרויקטים שמפותחים (והם ישולבו בעתיד במוצרים כמו ProxMox, oVirt ואולי Xen). אחד מהם לדוגמא הוא פרויקט VirGL שמרנדר על GPU בשרת ומעביר דרך הרשת את הפלט למסך. כרגע הוא תומך רק בלינוקס אולם מישהו אחר כרגע עובד על תמיכת Windows. עוד פרויקט (דווקא מחברת אינטל) הוא פרויקט GVT שמשתמש ב-GPU של המכונה כדי לרנדר עבור מכונות וירטואליות. בפרויקט עדיין חסר פלט רינדור לתצוגה רחוקה אבל אני מאמין שאינטל שומרת את החלק הזה ל-GPU שהם עובדים עליו כרגע.

מה עם Hyper-V?
מבחינה טכנית, Hyper-V נותן פתרון טוב לוירטואליזציה ששווה פחות או יותר לפתרון של VMWare (יש פונקציות שיש בפתרון אחד שאין בשני וההיפך). גם מיקרוסופט מציעה גירסה "חינמית" שמגיעה עם גירסת Windows Server (כ-Role) והפתרון הזה יכול להתאים למי שרוצה פונקציות ניהול (די מוגבלות) פר שרת, כך שכל שרת מנוהל בנפרד. ברגע שרוצים לנהל את הכל בצורה מסודרת, יש צורך ב-System Center ויש גם תשלום עבור Operating System Environment (או OSE) ורשיון ה-Windows Server צריך להיות רשיון Data Center. בגירסת Windows Server 2016 מיקרוסופט די החמירה את דרישות הרשיון ואם במקרה של VMWare למערכת לא ממש משנה כמה ליבות יש לך במעבד, במיקרוסופט רוצים תשלום פר ליבה ולא פר מעבד. חברת TAG Provision כתבה פוסט המשווה את המחירים בין המתחרים העיקריים וניתן לראות כל הנתונים כאן וכפי שניתן לראות, עם המחירים הללו, אין שום סיבה לעבור ל-Hyper-V, אלא אם מחפשים את הפתרון המינימלי ה"חינמי" ללא ניהול מרוכז. בנוסף, אם אתה מחפש פתרון HCI, ה-Hyper-V אינו מתאים לכך.

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

במקרה חרום

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

נתחיל בעניין ה-DR/DRP. כן, אני מודע לכך שהנושא היה "שוס" ב-3 השנים האחרונות, ערימות של מסמכים נכתבו על הנושא פנימית וחיצונית בחברות שונות בארץ ובעולם וכמובן שחברות רבות רכשו חבילות תוכנה/שרותים ורכשו ציוד שיושב באיזו שהיא חווה (או באחד מהעננים הציבוריים) והמערכת מסתנכרנת תדיר בין ישראל לבין המיקום השני. הפתרון הזה הוא פתרון מעולה כאשר חברה נותנת שרותים לקהל לקוחותיה שנמצאים מחוץ לחברה. במקרים כאלו, התשתית המרוחקת (לאחר שינוי DNS) תתן שרותים וכשהתשתית הישראלית תחזור לפעילות, הנתונים יסתנכרנו ארצה.

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

אין תקשורת. החוצה.

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

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

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

  • שימוש ב-DNS פנימי, 2 שרתי DNS שמסונכרנים ביניהם תדיר עם AD ו-DHCP. (סביר להניח שזה מצב קיים אצל הרוב, אבל יש כאלו שהעבירו את זה לענן. תתפלאו).
  • שרת מייל פנימי – נכון, אין אפשרות לקבל/לשלוח מיילים מחוץ לחברה אך במקרים רבים המיילים/יומנים הם פנימיים ולכן שרת מייל פנימי יוכל לבצע זאת. (מכיוון שאינני מומחה Exchange, כדאי לשאול את מיקרוסופט איך מסנכרנים שרת כזה ל-365 אחרי שהתקשורת חוזרת).
  • שרתים (VM) שעברו לענן – כדאי להקים אותם פנימית בחברה עם DB ו-Snapshot שמתעדכן תדיר, עם כתובות FQDN זהות פנימית לשרתי DNS שציינתי בנקודה הראשונה, כך ששירותים חיוניים יופעלו מהתשתית המקומית בהיעדר תקשורת החוצה.
  • גיבוי – לוודא היטב שיש גיבוי מקומי והוא תקין (כן, מומלץ להריץ Verify על הקלטות). תזכרו – אין תקשורת, אין DR מרוחק.

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

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

אנשי שיווק מול אנשי מקצוע

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

ואז שאלתי: איזה פתרון וירטואליזציה אתם הולכים להריץ? הם נקבו בשם מוצר. תשובתי: זה לא ירוץ.

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

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

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

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

עוד דוגמא: חברה מסויימת פנתה אליי בקשר למוצר שהם משתמשים וכבדרך אגב אותו אדם שפנה אליי סיפר לי שגם להם יש שרתים כמו שרכשתי (X3550 M3 של IBM) והם בדיוק הולכים  לרכוש הרחבת זכרון ל-256 ג'יגהבייט. הסברתי לבחור משהו פשוט: אתה תרחיב זכרון, ותראה נחיתה של 40% בביצועים. הוא לא האמין, הנציג שמוכר לו את הזכרון לא סיפר לו כלום על כך, אז שלחתי לו מסמך של לנובו שמראה שבשרתים עם מעבדים המבוססים על פלטפורמה של Westmere או Sandy Bridge, ברגע שממלאים את הזכרון, מהירות הזכרון יורדת מ-1333 מגהרץ ל-800 מגהרץ. אז יהיה יותר RAM, אבל הגישה תהיה יותר איטית. עדיף להוסיף שרתים – וזה ההבדל בין מישהו מקצועי לאיש שיווק.

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

  1. הפתרון שלהם מתאים אולי לשנת 2000, לא לשנת 2018.
  2. אין שום גדילה אופקית בפתרונות שהציעו
  3. אין שום שרידות רצינית בפתרונות שהציעו
  4. אין שום עדכוני אבטחה בפתרונות שהציעו.
  5. ההשקעה הכספית הראשונית גבוהה.
  6. הפתרון שהצעתי לאותה חברה הוא פתרון מבוסס קונטיינרים בענן. לאותה חברה יש ספק ענן מועדף ובכל הקשור לתמחור – יש לפנות לאיש השיווק של אותו ספק ענן.

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

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

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

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

מעבר ל-CI/CD בחברות גדולות

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

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

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

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

  1. לבחור צוות שיעבור ל-CI/CD מתוך כל הצוותים שיש בחברה. כדאי שבצוות יהיו אנשים עם מוטביציה ועם ראש פתוח. בלי זה – המעבר יכשל, מבטיח לכם.
  2. להעדיף כלים מבוססי קוד פתוח או פתרונות מסחריים מבוססי קוד פתוח. כלים קנייניים הם מקור לצרות בעולם ה-CI/CD שמתפתח בקצב מהיר. לעומת זאת, כלים בקוד פתוח צריכים בד"כ הרצה של פקודת YUM או APT כדי לעדכן.
  3. האם בהזדמנות זו מכניסים פתרון קונטיינרים? (אפשר לבצע CI/CD ללא קונטיינרים) – אם כן, כדאי להחליט אם הולכים על פתרון מסחרי של Kubernetes (כמו CAAS של SuSE) או על OpenShift של רד-האט שהוא גם מבוסס Kubernetes אבל נותן הרבה הרבה יותר יכולות. (ישנם כמובן גם פתרונות אחרים אבל הם לא עונים לצרכים של Enterprise).
  4. פיתוח כ-Multi Platform – חשוב במיוחד לבנקים, חברות ביטוח וחברות פיננסיות. זה נחמד וטוב לפתח ל-Windows אבל אפשר בעזרת עבודה די קצרה לעבור ל-Multi Platform. עובדים ב-JAVA? מצוין, אפשר גם עם לינוקס, צריך בסה"כ לשנות מספר סקריפטים (אם כתבתם) כדי לעבוד בלינוקס. עובדים עם Dot Net? תכירו את Dot Net Core שמאפשר לכם עבודה עם Windows ולינוקס. היתרון של עבודה עם לינוקס הוא שמגוון רחב של כלים יהיה זמין לכם (במיוחד אם אתם עובדים עם קונטיינרים).
  5. טסטים טסטים טסטים … יש עדיין מקומות שמעסיקים אנשי QA. ברוב המקומות לעומת זאת, כבר אין חיה כזו מהסיבה הפשוטה שהיום פשוט כותבים טסטים שרצים במערכת כמו Jenkins המבצעים בדיקות Unit testing ועוד מספר סוגי טסטים על מנת לוודא שמה שמפותח – הוא יציב ועובד.

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

ועוד משהו אחד שרבים לא יאהבו שאני כותב זאת: החיה הזו בשם "איש Devops" זו המצאה שגויה של אנשים שלא מבינים מה זה Devops. הבה נסתכל על משהו פשוט בחברה גדולה: החברה מחליפה תוכנת גיבוי, תוכנת Code Repository, אולי כלי אוטומציה ועוד מספר דברים. האם אותה חברה צריכה פתאום שכיר נוסף? לא, כי צוות ה-IT אמור לדעת לתמוך בכלים. אפשר לקרוא למישהו מבחוץ שילמד ויתרגל את הצוות, אבל הצוות יכול בהחלט להמשיך ולתחזק את אותם כלים. אדרבא, הן אנשי ה-IT והן צוותי הפיתוח צריכים להכיר את הכלים (ברמות מסויימות כמובן, ה-IT ברמה של Sysadmin והשאר ברמה של Usage).

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

כשצריכים סטורג' סופר מהיר (חלק שני)

בפוסט הקודם הסברתי מעט מהו סטורג' סופר מהיר. למעוניינים בגירסה המקוצרת: סטורג' כזה עובד כ-NVMEoF (כלומר NVME over Fiber אם כי הוא כמובן יכול לעבוד גם על Ethernet בלי שום בעיה, אבל תצטרכו תקשורת במהירות של 40/50/100 ג'יגה – תלוי בכמויות שרתים, חיבוריות וכו') והוא בעצם נותן לנו ביצועים של דיסקים SSD NVME מקומיים עם Latency מאוד נמוך (בסביבות ה-20 מיקרו-שניות). מערכי AFA רגילים יכולים תיאורתית לתת NVMEoF אך ה-Latency יהיה בערך פי 10-20 יותר גבוה. בדרך כלל, רוב החברות שרוצות לרכוש AFA לא ממש יצטרכו NVMEoF למעט אותן חברות שמחפשות את ביצועי הדיסקים הכי גבוהים שניתן לקבל, חברות כמו High Frequency Trading, Fast Analysis, מערכי VDI ענקיים (מעל 5000 עם ביצועים מאוד גבוהים), AI/ML כשהביצועים המבוקשים חייבים לכלול Latency סופר נמוך כדי להתמודד עם כמות עצומה של DATA ל-Training, מערכות BIG DATA ענקיות, וכמובן – אלו שרוצים את ה-Top שב-Top (לא תמיד בגלל סיבות טכניות.. יש לא מעט חברות שרכשו פתרון שהוא פי 10 גדול מהצרכים שלהם מהסיבה הפשוטה … שיש תקציב).

על מנת לקבל את אותם ביצועים סופר מהירים, ברוב המקרים ישתמשו ב-XPoint של אינטל או Z-NAND של סמסונג. במקרים אחרים (כמו עם מערכות של E8) יהיה NAND אך ישולב בו Cache אימתני ועוד כמה דברים על מנת לתת את אותו Latency.

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

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

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

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

לכן, כדי לקבל את המספרים הטובים, אנחנו צריכים גוף שהוא מוכר עולמית, יש לו גישה לכל הציודים והוא עורך בדיקות עם הציודים ומפרסם מספרים ללא כל מיני "טובות" והשפעות. יש גוף כזה שנקרא STAC Research שחברים בו יותר מ-300 חברות והוא מפרסם Benchmarks על ציודים שונים בכל התחומים ומי שאינו מכיר את הגוף, מוזמן לקרוא את המאמר הזה באתר The Register. כך לדוגמא נראה גרף טיפוסי בדו"ח:

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

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

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

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

כשצריכים סטורג' סופר-מהיר (חלק ראשון)

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

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

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

עכשיו אסביר.

רוב הסטורג'ים AFA הם פחות או יותר "גלגול" של הסטורג'ים מבוססי דיסקים מכניים. במקרים רבים עם כל היוקרה של AFA, אתם מקבלים SSD בחיבורי SAS/SAS2 או SATA Enterprise (שם נחמד ל-SATA רגיל רק עם "יוקרה"), לאו דווקא דיסקים SSD בחיבור NVME וגם אלו עם חיבור ה-NVME – יתנו בהחלט ביצועים יותר גבוהים מדיסקים מכניים, אבל ה-Latency יהיה עדיין גבוה בהשוואה לדיסקים NVME שיושבים בתוך השרת פיזית. זו לא דעה, זו עובדה – קחו 2 דיסקים NVME והגדירו אותם לדוגמא כ-RAID-0 בשרת, עשו את העבודות שאתם רוצים לבדוק ואחר כך קחו זוג דיסקים SSD NVME במכונה אחרת והגדירו שיתוף כמו iSCSI או CIFS או NFS. לא חשוב איזו רשת יש לכם (10/25/50/100 ג'יגה), Ethernet או Infiniband – הביצועים יהיו גבוהים אבל ה-Latency יהיה גבוה. פתרונות כאלו יכולים להיות מעולים לאלו שרוצים מהירות גבוהה יותר מדיסקים מכניים, אבל הם לא הביצועים הכי גבוהים שניתן להשיג, ומכיוון ש-AFA עולה מאוד יקר, ההמלצה שלי לחברים ולעסקים שמשוחחים איתי – היתה להמתין, לא לרכוש עדיין.

הביצועים הכי גבוהים שמאוד רצויים אצל חברות פיננסיות, AI/ML, HFT ולכל ארגון גודל שמוכן לשלם בתמורה לביצועים מקסימליים – הם ביצועים ששווים לדיסקים SSD NVME (כמו ה-XPoint של אינטל/מיקרון או Z-SSD של סמסונג) שיושבים מקומית בתוך השרתים. זיכרו: דיסק NVME (בקרוב יהיו גם דיסקים מכניים עם NVME, אגב) לא מצריך איזה בקר שיושב באמצע והוא מדבר ישירות ל-CPU ולזכרון המחשב ולכן דיסקים בטכנולוגיות כמו XPoint או Z-SSD מצטיינים ב-Latency נמוך וביצועים שנמוכים אך במעט מזכרון RAM שיושב במחשב. ב-AFA שנמכרים כיום, יש לנו כל מיני פרוטוקולים שמגדילים את ה-Latency, החל מ-iSCSI, המשך ב-NFS וכלה ב-CIFS, כך שהדיסקים יושבים בסטורג' היוקרתי, יש צורך באחד מהפרוטוקולים הנ"ל כדי להעביר DATA דו צדדית בין השרתים לסטורג'.

כאן נכנס לתמונה ה-NVMEoF שכתבתי עליו לפני 3 חודשים, ועם NVMEoF ה-Latency יורד לרמה של דיסקים SSD NVME מקומיים, כך שפעולות התחלת קריאה/כתיבה או כל פעילות אחרת נעשית ב-Latency מאוד נמוך.

איך זה מבוצע? כפי שציינתי באותו פוסט – עם RDMA, כלומר עם אותו פרוטוקול ותיק, ידוע ומאוד אמין ובמקרים רבים זה נעשה על מעבד יעודי שנמצא בכרטיסי הרשת (בגלל זה כרטיסי Mellanox מעולים לארכיטקטורה כזו הן בשרתים והן בסטורג') ואת עניין ה-NVMEoF לא תמצאו ברוב הסטורג'ים AFA. רק בשנה האחרונה חברות ישראליות כמו E8 וכמובן Kaminario (כן, אנחנו "מעצמה" בתחום הסטורג'… טוב, לפחות בפיתוח 🙂 ) וחברות כמו Toshiba, Pure Storage ו-Lenovo (וכמובן הגדולים) מתחילים להציע פתרונות כאלו. אלו שרכשו סטורג' AFA יוכלו (תלוי בחברה) אולי לשדרג ל-NVME-oF אבל גם אז – יהיה צורך להחליף כרטיסים בשרתים וציודים "באמצע" בחלק גדול מהמקרים.

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

רכישת/מכירת שרתים יד שניה, פוסט המשך

לפני כ-3 חודשים פרסמתי את הפוסט הזה לגבי עניין מכירת שרתים ע"י חברות ורכישה של שרתים יד שניה ע"י אינדיבידואלים או חברות. מאז שפרסמתי את הפוסט פנו אליי מס' אנשים שחושבים לרכוש או למכור מכונות וחשבתי שהגיעה העת לפרסם פוסט עדכון כדי להסביר לחברות כמה דברים לגבי מכירת שרתים ואת המציאות…

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

מס' אנשים תלו (ותולים) תקוות שחברות אחרות ירכשו את השרתים שלהם, אך האמת הדי פשוטה היא שרוב החברות בארץ פשוט לא רוכשות שרתים יד שניה (למעט כמובן חברות סוחרים כמו All Trade ואחרים) מהסיבה הפשוטה: חידוש אחריות ל-3 שנים הכוללת הגעת טכנאי בזמן SLA  של 4 שעות – יהיה יקר בהרבה ממחיר רכישת השרת. כך לדוגמא, אם רכשתם שרת יד שניה ב-1500 שקל, עלות השרות שציינתי לעיל תעלה בסביבות 6000-10000 שקל, בשעה שרכישת שרת חדש עם הוספה של תמיכת SLA ל-4 שעות תעלה הרבה פחות בהשוואה לרכישת השרות לשרת יד שניה, כך שכל חברה שאפילו תחשוב על רכישת יד שניה ותרצה SLA כזה, תרד מרכישת שרת יד שניה.

מה לגבי ציודים שבשרתים? אז כך:

  • מקלות זכרון בגודל 1,2,4 ג'יגהבייט – אין להם בד"כ דרישה בשוק, כך שמי שרוצה למכור זכרונות ECC יכול לנסות את מזלו אולי ב-eBay. הדרישה בשוק בד"כ היא למקלות זכרון בגודל 8 ג'יגה ומעלה עם תיוג PC3 10300 או PC3 12800. גם עם מקלות אלו אין הרבה "בשר" מבחינת כסף להרוויח הואיל ורוב המוכרים (שוב, למעט חברות שזה מה שהן מציעות) פשוט לא נותנים שום אחריות לזכרונות, ולכן לדוגמא מקלות זכרון של 8 ג'יגה שווים בערך 20-40 שקל פר חתיכה (בסביבות ה-50-60 לזכרון PC3 10300 בהנחה שמדובר ב-DDR3 ECC).
  • דיסקים קשיחים – לא מומלץ לשום חברה שמעוניינת למכור את הציוד, למכור או לתת את הדיסקים הקשיחים עקב עניינים של אבטחת מידע. השרת מבחינתכם "מת"? העבירו את הדיסקים לגריטה. דיסקים SSD – לא מומלץ לרכוש יד שניה מכיוון שכמות הכתיבה עליהם מוגבלת ודיסקים SSD יד שניה בד"כ אינם כוללים בקרים מורכבים כך שסביר להניח שה-SSD ימות עוד לפני שתימלא לו שנה לאחר רכישה מיד שניה.
  • מעבדים – מאוד תלוי בדגם השרת. שרתים כמו Gen9 של HP (או R730 של Dell או M5 של לנובו) יכולים לקבל מעבדי Xeon E5 v4 כשדרוג במקום E5 v3 (כל מה שצריך זה לשדרג BIOS לגירסה האחרונה לפני החלפת מעבדים), ולכן גם כאן, מי שרוצה לרכוש שרת יד שניה, עדיף שירכוש את המעבד הכי "נמוך" שאפשר וישדרג ברכישת מעבדים ב-eBay. למוכרים – זו עיסקת חבילה ובקטע הזה לא תקבלו הרבה גם על הדגמים עם הכי הרבה ליבות.

מה לגבי מחירים? הפופולריים ביותר אלו הם שרתי 1U ו-2U מה-5 שנים האחרונות (אלו שלפני כן נמכרים במחירים של 3 ספרות). כך לדוגמא שרת Gen8 של HP עם 192 ג'יגהבייט זכרון ועם מעבדים בעלי 8 או 10 ליבות נמכרים במחירים של 1000-1500 שקל (ה-1500 זה אם יש דיסקים חדשים). Gen7 של HP נמכרים בסביבות ה-600-900 שקל עם 208 ג'יגהבייט זכרון לדוגמא, כך שכמו שאתם רואים – הרבה כסף אי אפשר לעשות מזה.

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

סוויצ'ים, UPS – גם כאן, המחירים נעים סביב ה-3 ספרות. UPS לדוגמא לא שווה הרבה אחרי 6-9 שנים של שימוש מכיוון שיש צורך להחליף סוללות פנימיות (והן יקרות!). סוויצ'ים לעומת זאת, חברות רבות נפטרות מהמתגים במהירות 1 ג'יגהביט לטובת מתגים במהירות 10 ג'יגה ומטה, כך שגם כאן המוכר לא יעשה מזה הרבה כסף והרוכשים הפרטיים יכולים אולי למצוא הזדמנויות טובות לשדרג LAB או להוסיף מתג לדברים/פרוייקטים צדדיים.

אז מדוע חברות כמו All Trade מוכרת במחירים כאלו גבוהים שרתים יד שניה? הסיבה פשוטה: הם חייבים להחזיק מלאי והם מוכרים שרות, כך שאם לדוגמא הם רכשו מלאי של 10 שרתי Gen8, הם יוכלו למכור רק 5-7 כאלו כי הם חייבים להחזיק שרתים אחרים כמלאי להחלפה בעת תקלות חרום כחלק מהשרות שהם מוכרים.

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

הפצה מול הפצה: רד האט מול SuSE

בעולם ה-Enterprise יש כיום 2 הפצות לינוקס מרכזיות שנותנות פתרונות מלאים לשוק זה והן RHEL של חברת Red Hat ו-SLE של חברת SuSE. הפעם ננסה לבחון מי מהן טובה יותר בכל מיני קטגוריות, לא כולן טכניות.

נתחיל מבחינה טכנית של הטמעה ושימוש: לשתי ההפצות יש התקנה מסודרת שיודעת לתמוך במגוון ציודים שיש בשרת, בין אם הן רצות "על הברזל" או על מכונה וירטואלית או כ-Image בסיס לקונטיינר. ב-99% מהמקרים לא תצטרך לחפש דרייברים נוספים (למעט כרטיסים של nVidia, אם כי SuSE מציעה פתרון שאינו מצריך חיפוש והורדה של דרייברים). אם כל מה שאתם עושים בלינוקס נמצא בתוך החבילות של ההפצה, אין שום בעיה לעבוד עם כל אחת מההפצות, והשינויים בין הפצה אחת לשניה אינם כה מהותיים. פה yum ושם zypper.

למרות זאת, עם כל האהבה שלי ל-CentOS/RHEL, ל-SuSE יש מספר יתרונות על רד-האט שחשוב לדעת עליהם, לדוגמא:

  • הפצת SLE מתקדמת יותר מההפצת לינוקס של רד-האט. יש שם Kernel חדש יותר, והכלים עצמם יותר מעודכנים ויותר מודרניים, כך שאם לדוגמא מתקינים Kubernetes, אז לא צריך לחפש אותם במאגר צד ג' כלשהו, מה שמגיע עם ההפצה זו הגירסה האחרונה היציבה, וכנ"ל שאר כלים נוספים כולל קומפיילרים וסביבות פיתוח יותר עדכניות.
  • הפצת SLE קלה יותר להגדרת דברים. ב-SLE יש כלים כמו yast2 שמאפשרים להגדיר הרבה דברים במערכת, החל מ-NFS, iSCSI, רשת ועוד ועוד מבלי לדעת איזה פרמטרים להכניס בקבצי ההגדרה.
  • ויש עוד דברים…

נמשיך מכאן להפצות עבור שימוש בכלים או פלטפורמות יחודיות להפצה. לדוגמא OpenShift במקרה של Red Hat, או SES במקרה של SuSE או OpenStack במקרה של שתי ההפצות: הגרסאות שההפצות מוציאות רצות אך ורק על הפצות הלינוקס מתוצרתיהן, כך שלדוגמא OpenShift לא ירוץ על SLE וגירסת ה-SES או OpenStack של SuSE לא ירוצו על מערכת של Red Hat (ניתן כמובן לעשות טריקים שכן ירוצו אך לא תקבלו לכך תמיכה רשמית). לכל אחת מההפצות יש שינויים ותוספים יחודיים לה (לדוגמא מערכת OpenAttic שנמצאת ב-SES), כך שבמקרים כאלו אם ארגון מסויים מעוניין במערכת של אחד היצרנים והפצת הלינוקס אינה ההפצה הרגילה של שאר מערכותיו, הוא יכול להתקין את את ההפצה והפלטפורמה כמעין "Appliance". הן מערכות RHEL והן מערכות SLE ניתנות להגדרה בקלות לניטור ולביצוע פעולות אחרות והן אינן מערכות סגורות.

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

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

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