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

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

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

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

החל ה"מרדף" אחר החלפת הדיסקים קשיחים שלכם

כמעט בכל חברה גדולה בארץ יש שרתים ואם נסתכל בשרתים – ברוב המקרים נמצא דיסקים קשיחים מכניים. הם לא מהירים כמו דיסקים SSD, אבל הם "סוסי עבודה" שעושים עבודה טובה. אני די בטוח שהיו למנמר"ים או אנשי IT הצעות להחליף את הדיסקים האלו ב-SSD ובוודאי בחלק מהמקרים הדיסקים המכניים הוחלפו ב-SSD, אבל בד"כ חברות לא ממהרות להחליף – בגלל המחיר. אחרי הכל, מחיר ממוצע של SSD ל-Enterprise עולה הרבה יותר מאשר דיסק מכני SAS או NL-SAS ל-Enterprise.

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

הם מיועדים להתחרות בדיסקים הקשיחים שיש לכם בשרתים.

הבה נודה על האמת: דיסקים מכניים בגודל 2.5" לא התקדמו כמעט בשנים האחרונות. ברוב המקרים הדיסק הכי גדול ל-2.5" ל-Enterprise הוא בגודל 2 טרהבייט (יש כמובן גם 5 טרהבייט אם כי הם אינם מיועדים ל-Enterprise ובכל מקרה לא בטוח הם יוכלו להיכנס לשרת שלכם אם השרת הוא של HP לדוגמא – המערכת פשוט תקפיץ הודעה שזה לא נתמך והיא לא תציג התראות מדיסק כזה). המהירות שלהם אינה גבוהה (בין 200-270 מגהבייט ב-Sequencial Read).

חברת Micron, בשיתוף פעולה עם אינטל, הציגו אתמול את ה-SSD מבוסס QLC הראשון שלהם. עדיין אין הרבה פרטים ציבוריים עליו ובאתר Toms Hardware כתבו כמה מילים לגביו.

טכנית, הדיסקים הללו, כפי שציינתי לעיל, מיועדים להיות "באמצע" – בין כוננים מכניים ל-SSD שכולם מכירים ל-Enterprise. הכתיבה שלו לא מהירה בהשוואה לשום SSD שקיים בשוק (כן, גם בהשוואה ל-SSD שעולה 1000 שקל בחנות מחשבים), אולם מהירות הקריאה שלו היא כמו מהירות קריאה של SSD ל-Enterprise, כלומר אתם תקבלו מהירות של 550 מגהבייט לשניה (שוב, ב-Sequencial Read, ב-Random התוצאה תהיה מעט שונה ואם משתמשים ב-Queue Depth התוצאות יהיו לא רעות .. הייתי מרחיב אבל יש אמברגו עד לסתיו הקרוב).

הגדלים של הדיסקים הללו יהיו שונים מגדלים של דיסקים מכניים. ה-5210 ION יהיה זמין בגדלים החל מ-2 טרהבייט ועד 8 טרהבייט (אני מעגל את המספרים), כך שתיאורתית דיסקים כאלו יכולים להחליף גם דיסקים מכניים בגודל 3.5" (ניתן לאכסן תיאורתית בשרת בגודל 1U עם 10 כניסות דיסקים – כמעט 80 טרהבייט של DATA).

והשאלה הכי חשובה לפני שחושבים לרכוש דבר כזה בעתיד: לאיזה עומסי עבודה זה מתאים? ובכן, התשובה היא במובהק לעבודות Read Intensive. זה לא מיועד לאכסן שרת SQL או נתונים של שרת SQL, זה לא מיועד לשמש כדיסקים לוקאליים עבור הרצת מכונות VM. זה מיועד יותר לאחסן תוכן סטטי, כך שאם אתם מריצים פורטל ארגוני גדול בחברה לדוגמא, דיסק כזה יכול לאחסן את התכנים עבור הפורטל (בנוסף לדיסק רגיל שיאחסן את השרת ה-Web ו/או ה-Application Server). חשוב לזכור: כמות הכתיבה/מחיקה על כל תא היא מוגבלת (בסביבות ה-1000 פעם, אבל בד"כ בקר ה-SSD עושה עבודה חכמה שלא תגיעו לזה)

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

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

הקשחת שרתים במבט יותר עמוק

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

הדבר הראשון שצריך להבין לגבי ההקשחות זה שתלויות חיצוניות לא תמיד עוזרות או לא עוזרות הרבה. ה-Firewall שיש בחברה לדוגמא כמעט ולא רלוונטי לנושא. כן, הוא יכול לזהות שכתובת IP מסויימת מנסה להיכנס, דרך פורט מסוים, אבל ה-Firewall לא יודע ולא יכול לדעת אם הפורץ הצליח להיכנס, ואם הצליח, באיזה קבצים הוא נגע. בלינוקס יש דבר שנקרא access time לדוגמא שיכול לאמר איזה משתמש נגע באיזה קובץ ומתי, אבל אם הפורץ כבר יצא והמשתמש הלגטימי (עם אותו username) נכנס ועבר על הקבצים, אז הרבה פעולות פורנזיות לא יעזרו הרבה לדעת מי נכנס ובמה הוא נגע (מה עוד שבימינו פורצים רציניים משתמשים ב-VPN ושלל טריקים נוספים להחביא את זהותם כך שמאוד קשה לדעת מי בדיוק נכנס). ישנם כלים אחרים שעובדים עם חתימות שונות כדי לזהות כניסות דרך שיטות ידועות וזה עוזר, אבל שוב – לא תמיד זה יעזור ותיכף ארחיב על כך.

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

אחת העבודות היותר מורכבות לפני שמגיעים למימוש CIS Benchmark היא עניין החבילות תוכנה שמותקנות על השרת. התקנת גירסת CentOS 7 לדוגמא בתצורה מינימלית מתקינה בסביבות 300+ חבילות. זה שאני יכול לבטל שרותים זה נחמד, אבל פורץ רציני יכול להפעיל את השרותים מחדש ברגע שהוא נכנס, ולכן העבודה הראשונית היא "כיסוח" של החבילות המותקנות שאין צורך בהן ובמקרים מסויימים קימפול מחדש של חבילות מסויימות ויצירת חבילות חדשות יותר מצומצמות על מנת להקטין כמה שיותר את וקטור התקיפה, ביטול גישת אינטרנט להתקנת חבילות ועוד ועוד. רק לאחר מכן אפשר לעבור לשלב מימוש ה-CIS Benchmark.

עוד נקודה שרבים שוכחים היא פורטים 80 ו/או 443. בד"כ הם פתוחים לעולם, וכאן גם מתרכזת בעיה רצינית: קיימים לא מעט סקריפטים שיתנו מעין shell גם אם ל-user שמריץ את שרת ה-web אין בכלל גישת shell מכיוון שלמודולים שרצים תחת אותו שרת web יש אפשרות לבצע דברים שונים הקשורים ל-shell. דוגמא נפוצה עם PHP היא [email protected] ומשם אפשר לבצע נזקים רבים, ולכן צריך לקחת בחשבון מה רץ בשרת ה-web ומה רץ "מאחורה", והכי חשוב – בדיקת ההזנה של המידע המגיע מהאינטרנט אל שרת האפליקציות לדוגמא (זהו החלק שקשור לצוות הפיתוח או מי שמריץ pen-testing).

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

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

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

סטארטאפים ואבטחת מידע בענן

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

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

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

וכאן בדרך כלל מתחילות הבעיות הקשורות לאבטחת מידע.

לא מעט אנשים שמתחילים סטארטאפים חושבים להם שאם יקימו את התשתית שלהם בענן, ספק הענן יגן עליהם בצורות כלשהן וזו כמובן טעות ענקית. לא חשוב מי ספק הענן, כמות ההגנה המסופקת ללקוח היא ברמה אפסית (אינני מדבר על הגנות בתוספת תשלום כמו נגד DDoS). אתה יכול להפעיל Multi Factor Authentication כדי למנוע כניסת אנשים לא מורשים לחשבון בענן, אבל זה לא אומר כלום לגבי ה-Instances שאתה משתמש. מהרגע שיש לך Instance חי ויש לו כתובת IP ציבורית, עשרות אלפי סקריפטים ינסו לחדור לשרת שלך בכל דרך. כל שרות שתפעיל באותו Instance ושאינו סגור לכתובת הציבורית (כמו שרבים נוטים להשאיר פורטים פתוחים לשרותי SQL/NOSQL, GUI, או SSH עם סיסמא (ללא מפתחות) – הסקריפטים ינסו להיכנס, ואם הם יצליחו, חלקם יעבירו את המידע חזרה מבלי לנגוע במידע בשרת וחלק אחר של סקריפטים פשוט "יגייסו" את המכונה להריץ BOT או תולעים או 1001 דברים מזיקים אחרים ויש כמובן גם סקריפטים שישמחו פשוט למחוק את המכונה.

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

לכן ההמלצה הראשונה שלי לכל סטארט אפ שכולל מס' קטן של מפתחים זה לקחת מישהו חיצוני שיעשה את עבודות הסיסטם ואבטחת מידע ברמה מספקת של הגנה כלשהי על התשתית. הגנה ברמה גבוהה מצריכה הרבה עבודה בכל מיני אספקטים כמו API, שרתי Web שנותנים את השרות, TLS ודברים רבים אחרים וכאן זה תלוי אם איש ה-Devops שלכם יודע לעשות זאת או שילוב של מישהו חיצוני שיעבוד יחד עם איש ה-Devops שלכם.

להלן מספר נקודות בסיסיות שיכולות לסייע לסטארטאפ בתחילת דרכו:

  • אם מדובר במספר עובדים בסטארטאפ אחד שיושבים במשרד כלשהו, דאגו ל-VPN וחברו את ה-VPN כ-Site To Site לחשבון הענן שלכם. מי שרוצה להתחבר מהבית, יתכבד הבחור ויתחבר ל-VPN שלכם ומשם לתשתית.
  • עבודה עם סיסמאות לכניסה לשרתי לינוקס היא no no. השתמשו במפתחות בלבד והחליפו את קבצי ה-PEM שניתנו לכם ע"י שרות הענן שלכם במפתחות שלכם בחלוקה של פרטי/ציבורי (עדיף ליצור עבור כל מפתח מפתח, להכניס את החלק הציבורי לשרת ואת החלק הפרטי למכונה של המפתח כך שאפשר לדעת מי נכנס עם איזה מפתח), כך שמי שצריך להיכנס למכונה יהיה לו את החלק הפרטי של המפתח (החלק הציבורי נמצא בשרת). קבצי ה-PEM למיניהם קל "לדוג" אותם מכל מיני פורומים, אימיילים ושאר מקומות.
  • מקימים DB? ראשית יש להקשיח את ה-DB לפני שמכניסים אליו נתונים. אם זה mysql לדוגמא, יש להריץ קודם כל mysql_secure_install, ואם זה mongoDB יש למחוק משתמש דוגמא,  ובכל המקרים יש לוודא כניסה רק דרך IP מסוים פנימי.
  • משתמשים בשרותים שונים של ספק הענן? ודאו שאתם משתמשים בכתובות IP פנימיות בלבד. זה לא מצליח? יש לכם בעיה עם ה-VPC (במקרה של אמזון), כדאי לבדוק הגדרות.
  • שימוש ב-DB – לפני שכותבים נתונים ל-DB, כדאי "להמליח" דברים כמו סיסמאות ומידע חשוב (להלן לינק לוידאו המסביר איך לעשות זאת ב-MySQL לדוגמא), כך שמי שיצליח לגנוב את ה-DB, לא יוכל לעשות הרבה עם זה. אפשר כמובן לשפר את זה ולהשתמש בכל מיני שרותי Vault לשמור את המפתח להמלחה אך זה כבר עניין אחר.
  • גיבויים ל-S3 או כל מקום ששומר Object Storage – לאחר יצירת הגיבוי, יש להצפין אותו ורק אז להעלות אותו (כמובן שכדאי לוודא שהרשאות ה-S3 שלכם מוגדרות בצמצום).
  • לא לקחת כתובות IP ציבוריות עבור כל Instance (טריק שלצערי ראיתי פעמים רבות שנעשה בחברות שונות). אם אין אפשרות להקים ולהשתמש ב-VPN ויש צורך להתחבר ממקומות שונים עם IP שונה, מומלץ להשתמש בטריק שנקרא Linux Bastion, זו מכונת לינוקס קטנה שבה נשתמש כ"מקפצה" (להלן לינק למאמר שמסביר זאת) ולמכונה זו יש להגדיר Security Groups עם הכתובות שיכנסו אליה (חשוב: לא להוסיף כל פעם כתובות אלא לעדכן ב-SG).
  • תעודות SSL – אם המכונה פונה החוצה ואין לכם עדיין תעודות SSL מסודרות, אפשר להשתמש ב-Let's Encrypt כדי ליצור תעודות SSL תקינות זמניות (שניתנות להארכה בפקודה פשוטה) במקום להשתמש ב-Self Signed Certificates. באותה הזדמנות כדאי לבטל Ciphers ישנים ולאפשר אך ורק ל-TLS מהגירסא האחרונה להיכנס.

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

קצת על Windows ואוטומציה

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

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

  • Chef
  • Puppet
  • Ansible
  • SALT

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

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

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

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

תכירו את Redfish

אני רוצה להכיר לכם את Redfish. בעקרון, Redfish זה API סטנדרטי לנהל כמעט כל דבר בתחום ה-IT, החל מ-SDDC (כלומר Software Defined Data Center) וכלה בשרתים, שרותים, מתגים ובקיצור כמעט כל דבר שניתן להתחבר אליו. Redfish משתמש בסטנדרטים קיימים (REST API, web services ופלט כ-JSON) על מנת לעשות את החיים הרבה יותר קלים למחלקת ה-IT בחברה.

אחד הדברים שצריך לדעת על Redfish שזה משהו ענק שמשתתפים בו כל המי ומי בתחומי הברזלים לדוגמא. לפוסט הזה, אני מעוניין להתרכז בתחום ה-OOB (שזה אומר כל ה-iDRAC/IMM/ILO/IMC למיניהם).

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

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

כשמדובר על כמות של 1-3 שרתים, זה לא כזה ביג דיל, אבל אם מדובר על פרויקט חדש והגיעו 20 שרתים.. אתם יכולים לדמיין את הכאב ראש.

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

איך? עם ה-API של Redfish. כאן לדוגמא תוכלו למצוא עבור שרתי Dell סקריפטים הן ב-Python או ב-PowerShell על מנת להשתמש עם ה-Redfish בחיבור ל-iDRAC לעשות כמעט הכל, החל מהגדרת UEFI/BIOS, שדרוגי קושחה, הגדרות iDRAC, הגדרות RAID ושלל ירקות נוספים.

הכל טוב, רק שיש בעיה אחת קטנה: יש לי 20 שרתים להקים, להתחיל לשנות כל פעם סקריפטים? לכתוב סקריפט wrapper שמריץ את הסקריפטים שניתנים באותו אתר? זה חתיכת כאב ראש.

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

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

לסיכום: Redfish נותן סוף סוף דרך "לדבר" בצורה מאובטחת עם הציודים שלכם דרך סקריפטים שונים שניתנים לשימוש באוטומציה. אפשר גם להגדיר כך הגדרות שונות וגם לקרוא לדוגמא מה-OOB את התקלות האחרונות מה-Log. אם נחכים להשתמש גם ב-PXE (אני דווקא ממליץ על IPXE במקום PXE, הוא הרבה יותר מהיר כי הוא עובד ב-HTTP ולא TFTP כך שניתן לעבוד מהר ובמקביל) נוכל גם להתקין בצורה אוטומטית תוך שימוש בכלים כמו kickstart או preseed להתקין מערכות הפעלה שונות בתצורה מינימלית ואת השאר לעשות עם Ansible (כן, כולל Windows, אסביר בפוסט הבא) ובכך לחתוך את הזמן להקמת השרתים בעשרות אחוזים וגם התחזוקה תהיה הרבה יותר מהירה ואוטומטית.

להלן וידאו הדגמה של Dell מכנס Red Hat Summit האחרון שנערך לפני ימים ספורים: