נקודות למחשבה בעת בניית פתרון חומרה ללקוחות

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

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

להלן הנקודות:

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

מטריקות זה דבר מאוד חשוב
יש POC? מעולה, אבל לפני שרצים לחפש חומרה תואמת, ODM וכו', כדאי למדוד ביצועים ולהכין כלי Benchmark כלשהו שימדוד ביצועים, ואת הכלי, יחד עם קוד ה-POC – נריץ על פתרונות חומרה שונים בדרך – כדי לראות אם מקבלים את הביצועים שרוצים. ראיתי לצערי לא מעט כאלו שהזדרזו לרכוש לוחות עם מעבדי ARM שונים ולאחר שהקוד עבר קימפול והרצה – הביצועים הגיעו ל-10-20% ממה שהמערכת במקור נותנת על PC.

חשוב לעבוד עם יצרן חומרה
אם האיש או החברה החליטו ללכת על פתרון משובץ עם מעבדים מסויימים ושרותי ODM לתכנון לוח וכו' – חשוב לקחת את המלצות יצרן המעבד או הלוח ואם אפשר – את ה-SDK של יצרן החומרה. אחת הטעויות הנפוצות ביותר לאלו שמתחילים בעולם המערכות המשובצות – היא המחשבה שעולם הלינוקס במערכות משובצות הוא כמו עולם הלינוקס בדסקטופ. הוא בשום פנים ואופן לא ובמקרים רבים החלטה כמו "נלך על Yocto", "נלך על Open Embedded" וכו' מבלי שהיצרן אכן ממליץ ותומך באותה הפצת לינוקס – תיגמר בכי רע, הואיל ויש המון חלקים בעולם הלינוקס המשובץ שניתנים כקוד סגור, או קוד שנמצא Out of tree בהשוואה לגירסאות לינוקס שונות (ואם אין איש לינוקס שמבין בפיתוח דרייברים/קרנל – תהיה בעיה בלשלב את הקוד), או שפשוט לא ניתן יהיה להפעיל חלקים שונים בחומרה כי פשוט אין דרייברים זמינים באופן חופשי לציבור, ולכן – גם אם אתם בונים פתרון משובץ שימכר בכמה עשרות דולרים לצרכן ולכן כל סנט שנחסך הוא חשוב – צרו קשר עם יצרן הלוח או יצרן המעבד וסכמו על תמיכה וקבלת SDK.

נקודות לגבי AI, וידאו ומדיה
כדאי לשים לב כי בתחומים שונים כמו הסקה ב-AI (כלומר Inference), קידוד/פריסת וידאו/אודיו וטיפול בתכני מדיה שונים – יש מרחק רב ממה שהחומר השיווקי מציין לבין מה שמקבלים "ביד" בפועל. בתחום ההסקה לדוגמא, ישנם כמה יצרנים המציינים כי יש ברשותם שבבים ל-"AI" עם ביצועים מרשימים לביצוע הסקה, אבל בפועל (ואני בכוונה לא רוצה להזכיר שמות) התמיכה במודלים ובמטריצות – אינה מספקת או איטית. בתחום הוידאו – יש לא מעט כאלו שתומכים ב-H.264/H.265 – חלקם בפריסה בלבד וחלקם בפריסה וקידוד, אולם כמות וסוג הפרופילים שהם תומכים – היא קטנה מאוד, וברוב המקרים גם אין תמיכה ל-DRM שלקוחות רבים בתחום המדיה (כבלים, STB, וכו') דורשים, ולכן עוד לפני שמתחייבים לרכישות גדולות, כדאי לרכוש/לקבל Sample של לוחות שונים ולנסות אותם. נכון, יש צורך בהשקעה כדי לבצע Porting אבל בדרך כלל ההשקעה אינה גדולה ודי קל להמיר/לקמפל קוד למערכת ARM או X86 אחרת.

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

חשוב לבנות את ה"מסביב"
יש לא מעט חברות שיצרן מוצרים מעניינים לשוק ובמחירים זולים מאוד, אבל כשזה מגיע לאבטחה ועדכונים – תשכחו מזה (נסו לדוגמא לחפש עדכונים למוצרי TP-LINK או DLINK שנמכרים בארץ, אולי תמצאו עדכון אחד או 2 במשך כל חיי המדף של המוצר). כיום, כל מוצר שיוצא לשוק ונמכר במחיר זול – נפרץ די מהר, והדרך מהפריצה ועד לבעיות אבטחה שכל מיני פורצים מנצלים את המוצר כדי "לגייס" את המכשיר על מנת לתקוף מטרות שהפורצים בוחרים ב-DDoS – קצרה, ולכן חשוב עוד לפני שהמוצר בכלל יוצא – לוודא שה-Image כולל תשתית מאובטחת לקבלת עדכונים, לחתום כל עדכון, לא לאפשר לכל דכפין לנצל פלטפורמה כמו U-Boot להתקנת Images עצמאיים של הפורצים.

חושבים להשתמש בפתרון עם אנדרואיד?
אם אתם בונים פתרון המבוסס על אנדרואיד, חשוב יהיה לבנות מחדש את האנדרואיד שיתקבל מיצרן החומרה, להוסיף את התוכנות שלכם (ללא שימוש ב-root! או sudo וכו'), להכין IMAGE, ולתת את ה-Image שבניתם ליצרן החומרה. אם אתם צריכים הגנה על תכני מדיה (DRM), בקשו מהיצרן תמיכה ב-Widevine כולל הטמעת מפתחות בזמן יצור המכשיר. והקפידו על שחרור גרסאות עדכון אחת לזמן מה.

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

בהצלחה.

הדברים החשובים בהטמעת פתרון קוד פתוח בארגון

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

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

להלן מספר נקודות:

  • תכיפות שינויי קוד: חברות כמו רד-האט מפתחות את מוצריהן בצורה פתוחה וזמינה לכולם ב-github, ומכיוון שהפיתוח נעשה בצורה פתוחה וציבורית, מבוצעים שינויי קוד רבים, במקרים רבים – שינויים יומיים, וברוב המקרים, גם אם מוכרזת גירסה של הפתרון/ספריה/פלטפורמה – הגירסה אינה כוללת עדכוני אבטחה, בדיקות יציבות ותיקונים אחרים שקיימים בגרסאות המסחריות. מעבר לכך – אם המוצר קורס או גיליתם באגים – תהיה לכם בעיה לקבל סיוע, והכל יהיה תלוי בליבם הטוב של מתנדבים או עובדים (וגם על זה לא מומלץ לבנות, הואיל וחברות כמו סוזה, רד-האט, קנוניקל ואחרים – מקבלים הוראה לתעדף תיקוני באגים לאלו שרכשו גרסאות מסחריות או לאלו שמשלמים על חוזי שרות ליצרן התוכנה).
  • גרסאות תכופות – פתרונות כמו OpenStack, Kubernetes, Ceph, Gluster ופתרונות רבים אחרים משוחררים בתדירות די תכופה ע"י הקבוצות המפתחות אותם עבור יצרניות הפצת לינוקס. הן לוקחות את הקוד, מבצעות שינויים ותיקונים, מוסיפות עדכוני אבטחה (שיחזרו לקוד ה-Upstream יותר מאוחר), כותבות תיעוד ספציפי ועוד ועוד – ואז משחררות אותו במסגרת Life Cycle רשמי עם תמיכה רשמית ועוד, ומוציאות זאת כמוצר מסחרי, ובמילים אחרות – אותם מוצרים שיוצאים כגרסאות תכופות אינם מיועדים לפרודקשן.
  • האם יש לך צוות לינוקס בחברה? אם יש לך צוות In House שמבין היטב בלינוקס ויכול "לשחות" בתוך קוד של אחרים במקרה של תקלה במוצר/ספריה/פלטפורמה – במקרים כאלו קל יותר להטמיע פתרונות בקוד פתוח שעדיין לא יציבים כפרודקשן, ולכן כדאי להסתכל על הנקודה הבאה…
  • אבטחה – פתרונות קוד פתוח שלא מגיעים מיצרן כלשהו, בחלק גדול מהמקרים לא כוללים עדכוני אבטחה, ולכן אם החלטתם בכל זאת להטמיע את הפתרון בחברה, מומלץ כי אחת לחודש הצוות הפנימי בארגון יבדוק את הפתרון המותקן מול הפתרון שנמצא ב-github לדוגמא, ובמיוחד יבדוק אם ישנם תיקוני/עדכוני אבטחה שפורסמו בנפרד (כ-PR או במקומות אחרים) או גרסאות minor בהשוואה למה שמותקן פנימית – ויבצע עדכון ידני. ארגונים שאין ברשותם אנשי לינוקס, מומלץ מאוד יהיה לעבוד עם הגירסה המסחרית ולקבל את העדכונים מהיצרן.

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

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

כל מי שמסתכל על חברות טכנולוגיות שונות, יכול לראות לא מעט מקרים שחברות שונות "מפספסות את הרכבת" עם הפתרונות והמוצרים שהם מוכרים, תוך התעלמות מהשינויים בשוק. קחו לדוגמא את Qualcomm – לאחרונה התבשרנו שהחברה "נעקפה" מבחינת אחוזים בשוק על ידי המתחרה MediaTek, חברה שקטנה בהרבה מ-Qualcomm (ותחמנית לא קטנה). מבחינת ביצועים, אפל מצליחים להוכיח שוב ושוב בכל גירסת מעבדים שהחברה מוציאה – שהיא עוקפת בקלילות את המעבדים בקצה העליון ש-Qualcomm מוכרת, ובמבחנים שונים שנערכו לאחרונה, מעבד ה-M1 של אפל עוקף בקלילות את ה-Snapdragon 888 5G של Qualcomm. זה מזיז ל-Qualcomm? עד כה, לא ממש. אם קוואלקום לא רוצה להפיק לקחים, הם עלולים למצוא את עצמם מפסידים עוד ועוד אחוזים מהשוק וצניחה בהכנסות ורווחים. אגב, ל-AMD ולמיקרוסופט (כל חברה בנפרד) יש תוכניות במגירה למעבדי ARM חזקים – ולא רק לשרתים.

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

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

מילא העניין של CentOS, הבעיה היותר גדולה היא החברות שרד-האט רכשה ולא עשתה כמעט מאומה עם המוצר או שהרגה את המוצר/פלטפורמה. ניקח 2 דוגמאות:

  • תוכנת oVirt לוירטואליזציה – אנחנו ב-2020 והמוצר הנ"ל של רד-האט עדיין מפגר בצורה משמעותית בהשוואה למתחרים. גרוע מכך: בשעה שכל יצרני פתרונות הוירטואליזציה עוברים ל-Hyperconverge, פתרון ה-oVirt "מעניש" אותך כשאתה משתמש בדיסקים מקומיים ומבטל לך פונקציות קריטיות! בנוסף, רד-האט עדיין לא הצליחו להוציא גירסה שהיא ידידותית למשתמש ושתגרום ללקוחות פוטנציאליים לחשוב על מעבר אליה. הדוגמא הכי פשוטה: מעוניין לדעת מה התכונות החדשות שקיימות בגירסה המסחרית (RHV)? קח, תתחיל להציץ ב-Bugzilla, אולי תבין משהו, כי ברד-האט מתקמצנים לקחת צוות מקצועי שיכתוב את הדברים בצורה קלה לאלו שאין להם מערכת RHV קיימת..
  • פלטפורמת Cloudforms – הנה פלטפורמה שיכולה לסייע המון לכל ארגון שמשתמש בוירטואליזציה ב-On Prem מצד אחד, ובעננים ציבוריים מצד שני. הפלטפורמה עצמה היא ניטרלית לחלוטין והיא יכולה לתת למנהלי המערכת לבצע פעולות שונות בתשתית המקומית ובענן, להרים מערכת אישורים על מנת להוסיף/לבטל תשתית וירטואלית ועוד ועוד. רד-האט רכשה את יצרנית התוכנה (ManageIQ) עוד ב-2012. אתם מכירים איזה ארגון שהקים את הפלטפורמה בתשתית הפנימית? סביר להניח שלא. זה בסדר, רד-האט הרגה את המוצר רשמית לפני שבועיים. מדוע? כי המוצר נהיה סלט שלם, הוא סבל משינויים רבים (כולל החלפת שפה) וחוסר כיוון כללי.

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

ה"קטילה" של CentOS היתה צעד נכון מבחינה עסקית (אם כי רד-האט עשתה זאת בצורה ממש גרועה. החברה היתה צריכה להודות ש-CentOS הורג הכנסות ולא להציע את גירסת ה-Stream, לא כולם מטומטמים!), אבל רד-האט צריכה במהירות לתת פתרון חלופי שאינו עולה 350$! רד-האט צריכה לדוגמא להציע משהו הרבה יותר זול עם תמיכה מאוד מוגבלת, מחיר זול לגירסת VM, מחיר זול לשימוש אישי (או בחינם תמורת רישום ב-RHN) ועוד, ומה שהכי חשוב – להפסיק לעשות את החיים קלים למתחרים! דוגמא פשוטה: רשיון כמו ה-GPL (לא חשוב איזו גירסה) מחייב אותי לדוגמא לשחרר שינויי קוד (לא ממש. הוא מחייב אותי למסור אותם למי שדורש, ואני יכול לדרוש על כך כסף, אגב, הכל מצוין ברשיון) – אבל השינויים לא חייבים להיות משוחררים כטלאים ידידותיים. אם לקחתי לדוגמא קובץ של 10000 שורות ושיניתי 4 שורות, אני יכול לשחרר/למסור את ה-4 שורות ששונו/התווספו, אך בפורמט שאינו מציין מאיזה מקום בקובץ הן שונו, ואלו שורות מחקתי/החלפתי. כך מקשים על מתחרים.

לסיכום: ברד-האט צריכים להחליט מה הם רוצים לעשות מבחינה עסקית. Openshift הוא אחלה פתרון עסקי, אבל צריך לדאוג לפתרון גמיש (מבחינת מחיר) לגבי ה-OS, וצריך להחליט מה עושים עם שאר המוצרים שיש לרד-האט (כמו .. לדאוג סוף סוף לא להבריח לקוחות מ-Gluster עם החלטות מטומטמות כמו לנטוש NFS Scale Out?) ואולי אפילו לפרסם מפת דרכים פר מוצר. אנשים תמיד יתלוננו על כך שלוקחים להם משהו חינמי (אם כי אותם אנשים צודקים לגבי ההחלטה המוזרה וחפוזה ללא פתרון חלופי, ו-CentOS Stream זה הדבר האחרון שהייתי ממליץ אי פעם לארגון להתקין ב-VM או בשרת!), אבל אנשים מעריכים שקיפות והגינות. אם החברה תתעלם, היא עלולה למצוא את עצמה בגורל כמו של חברת דיגיטל, אם מישהו זוכר..

להתראות CentOS – התגובות והתשובות

אתמול פרסמתי את המאמר הזה לגבי ההחלטה של רד-האט להפסיק עם CentOS 8 ובמקומו לקדם את CentOS Stream. באתר CentOS יש FAQ של שאלות ותשובות בנושא, ואני ממליץ לקרוא אותו.

בחור בשם תומר בריסקר, עובד של רד-האט, פרסם פוסט בקבוצת ה-Linux IL בפייסבוק. אני בהחלט ממליץ לקרוא את הפוסט של תומר (הוא פתוח לציבור) ואני מודה לתומר שהסביר את הדברים. הוא גם הוסיף פרטים שלא פרסמתי בפוסט הקודם שלי. בקיצור – קפצו לקרוא.

העניין הוא שתומר מתייחס לנקודות מסויימות ועבדכם הנאמן מתייחס למשהו שונה לחלוטין. אין לי ספק ש-CentOS Stream במהלך הזמן ישתפר (בפעם האחרונה שניסיתי אותו לפני מספר חודשים, ה-Installer שלו (Anaconda) קרס לי לגמרי עוד לפני התחלת ההתקנה, ולא חשוב כמה ניסיתי לעקוף את התקלה) ואף יהיה תואם ל-CentOS 8/RHEL 8 ופידבקים של קהילת משתמשי CentOS Stream ילקחו בחשבון ע"י רד האט להכנסה לגירסת ה-RHEL.

אבל זה לא העניין שבגינו אנשים רבים מאוד עצבניים על רד-האט.

כל משתמש לינוקס, בין אם מישהו שהתחיל להכיר לינוקס רק לאחרונה או מכיר ומשתמש בלינוקס כבר יותר מ-20 שנה מכיר את הדבר הבא: בניגוד למערכות יוניקס, ישנן מאות הפצות לינוקס שמציעות דברים שונים ויש כמובן את ההפצות הפופולריות שרובם משתמשים בהן. כשרוצים לבחור הפצת לינוקס, צריך לבחור הפצה, וההפצות השונות מתחלקות בין הפצות יציבות אך ללא "המילה האחרונה" מבחינת אפליקציות ופלטפורמות (לדוגמא: CentOS, Debian Stable, RHEL, SLE, Ubuntu LTS), לבין הפצות שאינן כל כך יציבות – אך כוללות כמעט כל גירסה חדשה של אפליקציות ופלטפורמות פופולריות (Fedora, Ubuntu, Debian Testing, Open SuSE).

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

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

"CentOS Stream isn’t a replacement for CentOS Linux; rather, it’s a natural, inevitable next step intended to fulfill the project’s goal of furthering enterprise Linux innovation. Stream shortens the feedback loop between developers on all sides of the RHEL landscape, making it easier for all voices, be they large partners or individual contributors, to be heard as we craft future versions of RHEL."

אין לי בעיה עם CentOS Stream, ואני מקווה שבעתיד הרחוק זה יהיה פרויקט מוצלח, אבל אם יש משהו שאני מתעב – זה שמנסים "למרוח" אותי (לא, לא תומר, אלא חברת רד-האט העולמית). עזבו אותי מ-CentOS Stream, אני רוצה לדעת מ-רד-האט עצמה מדוע הם הורגים את CentOS 8. אין תקציב? זה פוגע בהכנסות החברה? חלק מה-SIG פוטר? זכותה המלאה של רד-האט "להרוג" את CentOS 8, אבל מגיע לקהילת המשתמשים לדעת מדוע התקבלה החלטה זו. אחרי הכל, הובטח שיהיו עדכונים ל-CentOS 8 עד 2029. על שום מה הקיצוץ ל-2021?

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

אגב, הפצה מתחרה ל-CentOS בקוד פתוח תקום כבר בזמן הקרוב ויש לה כבר שם: Rocky Linux.

להתראות CentOS??

בימים האחרונים יצאה הודעה כי CentOS 8 תעבור שינויים משמעותיים ובכללם – ההפצה תחדל מלקבל עדכונים בסוף שנת 2021, ולא תהיה הפצת CentOS המקבילה ל-RHEL מבחינת גירסא וקוד. הדבר היחיד שישאר הוא CentOS Stream שזו גירסת CentOS טיפה יותר "מתקדמת" מ-RHEL (אבל מבחינת עדכוני אבטחה – ה-Stream יקבל את העדכונים רק לאחר ש-RHEL יקבל).

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

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

ראשית, אני יכול להבטיח שאין ל-IBM יד ורגל בנושא ובהחלטה. רד-האט היא עדיין חברה עצמאית שמחליטה לעצמה החלטות, כולל את ההחלטה הזו.

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

שלישית – ולעניין זה לא תקבלו שום אישור מגורם רשמי: התקדמות טכנולוגית שגורמת להפסד פיננסי לרד-האט. בעבר, אם הייתי צריך להרים תשתית לינוקס גדולה לפיתוח, פרודקשן, עם backend ועוד דברים רבים – הייתי צריך בארגון גדול, לרכוש מספר לא קטן של רשיונות RHEL לכל שרת פרודקשן, בין מדובר בשרת פיזי או וירטואלי. כיום, לעומת זאת, המעבר לקונטיינרים חוסך לי בצורה משמעותית את כמות רשיונות ה-RHEL שאני צריך לרכוש לפרודקשן. אם פעם, לשם הדוגמא, הייתי צריך לרכוש 20 רשיונות, היום 4 רשיונות ל-Worker Nodes יספיקו, ופה מדובר רק בדוגמא אחת. רבים כיום יעדיפו הפצת לינוקס חינמית ברוב המקומות למעט היכן שחייבים בגלל ההנהלה להשתמש בהפצות RHEL מסחריות.

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

כל איש לינוקס ותיק ירגיש בוודאי תחושת דה-ז'ה וו בנושא. כבר היינו בעבר בסרט הזה. כשחברת רד-האט החליטה להוציא רק גרסאות לינוקס מסחריות בתשלום (מה שהיה RHEL, RHES), נוצרו מספר פרויקטים שלקחו את קוד המקור של RHEL וביצעו Fork לגירסה עם שם אחר אך עם תאימות מלאה (בעקרון, לא מדובר בתהליך של קימפול הכל מחדש באופן אוטומטי. יש לא מעט כלים לפתח, יש לא מעט סקריפטים לכתוב, להסיר קבצי לוגו וסימנים מסחריים של רד-האט וכו') כשה"זוכים" בפופולריות בסופו של דבר היו CentOS, Scientific Linux וכמובן Oracle שהחליטה פשוט לבנות את הכל בעצמה ולגנוב לקוחות מ-רד-האט.

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

לפיכך, להלן המלצותיי (לפי התיעוד הרשמי):

  • אם אתם משתמשים בגירסה כלשהי של CentOS 6 – שדרגו בדחיפות. ה-EOL שלה חל בחודש שעבר.
  • אם אתם משתמשים בגירסה כלשהי של CentOS 7 – אתם בטוחים, ואתם תמשיכו לקבל עדכונים לגירסה עד תאריך 30/6/2024. אם אינכם חייבים לעבור לגירסה 8, פשוט אל תעברו, במיוחד אם המכונות הן וירטואליות.
  • אם אתם משתמשים בגירסה כלשהיא של CentOS 8 – אתם תקבלו עדכונים עד סוף שנה הבאה (31/12/2021)
  • עכשיו, כל מה שנותר לעשות, זה להמתין ולראות מי "יקפוץ". האם רד-האט תחזור בה? (קהילות הלינוקס הן לא קהילות מנומסות, בלשון המעטה!) ואם לא, מי החברות שיכריזו על Fork ל-RHEL? (אמזון? מיקרוסופט? גוגל?) במשך השנה הקרובה אנחנו נראה את ההתפתחויות ואני מאמין שכבר בחודשים הקרובים נראה חדשות בנושא עם מפות דרכים והמלצות לאן להגר.

ולבינתיים, אני ממליץ לא לקחת המלצות פזיזות, אם אפשר.

"הר" פתרונות האבטחה שאינו רלוונטי כל כך

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

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

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

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

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

  • להיפטר מסיסמאות: סיסמאות היו ויהיו – מקור לאחד מכאבי הראש הגדולים, כולל כל ה-Policies ליצור אותם, החלפתם וכו'. גם במיקרוסופט ובחברות תוכנה אחרות הבינו זאת מזמן והם מציעים פתרונות שונים המבוססים על טביעת אצבע, Windows Hello, מפתחות כמו Yubikey של Yubico (או Tian של גוגל, ויש גם מפתחות המבוססים בכלל על קוד פתוח כמו Solokeys). בנוסף, שימוש במפתחות מאפשר להשתמש בהצפנות שונות (נתמכות בעיקר ב-Yubikey) ויחסית די קל להטמיע את הפתרונות בכל מערכות ההפעלה.
  • הצפנת תכנים: הסיוט הכי גדול לחברות מבחינת אבטחת מידע, הוא גניבה ו/או הצפנה באמצעות כופרה של המידע, וארגונים גדולים מאוד (חברות כמו קאנון, אוניברסיטאות, בתי חולים ועוד) חוו את הסיוט ונזק משמעותי נגרם לאותם ארגונים. אחד הפתרונות שניתן לבצע הוא הצפנה של רוב התכנים החשובים, וביצוע Decryption דרך Gateway שאליו מחוברים מספר מצומצם של משתמשים. ניתן לדוגמא לבצע זאת בעזרת הקמת LUN שיחובר למערכת לינוקס וירטואלית. מערכת הלינוקס תבצע encryption/decryption עם כלי כמו LUKS-2 או בכלים אחרים, ושיתוף (לאחר decryption) עם SAMBA. אפשר להתגונן נגד כופרה תוך שימוש ב-snapshots (במכונת הלינוקס בשימוש LVM).
  • ביצוע Snapshots – באופן עקרוני, Snapshots ברמת File systems לא אמורים לצרוך כמות משאבים גדולה ליצירה ולכן מומלץ ליצור Snapshots בפתרון האחסון ל-File systems בצורה תכופה מאוד (כל שעה לדוגמא, ובמקרים חשובים כמו הנח"ש – כל מחצית שעה). כך, אם ישנה התקפת כופרה, ניתן לשחזר מה-Snapshot במהירות במקום לשחזר מקלטות.
  • Pen testing הוא פתרון חלקי שלדעתי אינו מספק: לצערי לא מעט ארגונים וחברות שוכרים מישהו מחברה שיבצע בדיקות (Penetration testing), ורובם גם משתמשים באותם כלים וב-Kali Linux (מתי אנשים יבינו ששימוש ב-Kali Linux הוא "אות קין" שלמשתמש אין הבנה רצינית בלינוקס? כל הפצת לינוקס כוללת את כל הכלים הדרושים!) כדי לבצע את הבדיקות, ובמתודה זו הבדיקות והסריקות פשוט אינן מספקות את התשובה המלאה.
    בדיקות הקשחה וחדירה זה לא רק שימוש בכלים כמו nmap, nessus ו-1001 כלים נוספים, אלא לימוד כל המערכת ועבודה בצוות כדי לחשוב על נסיונות חדירה מכל מערכת שרצה בארגון, חולשות שקיימות לכל שרת, לכל Appliance ולכל ציוד (במיוחד ציוד ישן שאין לו עדכונים כבר מספר שנים – ציוד כזה מומלץ להחליף כמה שיותר מוקדם), מי הם האנשים בחברה שפעולות Phishing עליהם יכולות לגרום נזק מהותי, היכן ניתן לעצור או להאט דליפת מידע אם גורם כלשהו הצליח לפרוץ, האם יש עצירה אוטומטית של תעבורת Upload ל-IP שאינו white listed לאחר כמה מאות מגהבייט לדוגמא (כשהפורץ מנסה לגנוב כמה שיותר קבצים), ובקיצור – הכלים הם רק חלק קטן מהעבודה, ודרוש צוות רציני כדי לנסות לפרוץ (מבלי להגביל את הצוות, אבל עם הנחיה לגבות את הכל ולרשום כל גילוי ושינוי) ולא מישהו שהקים Kali Linux על מכונה וירטואלית ומכיר כמה כלים.
  • "קמצנות כרונית" של הרשאות: תופעה שקיימת בכל ארגון – עודף הרשאות שניתנו למשתמשים שונים, הרשאות שנפתחו "זמנית" ונשארו פתוחות או הרשאות שנפתחו ברמת worldwide (בלינוקס/יוניקס זה מוכר כ-777) בגלל שמישהו התעצל לחפש בגוגל ולקרוא איך מגדירים הרשאות בלינוקס. מאוד מומלץ לבצע אחת לחודש או לתקופה לעבור על כל ההרשאות (גם הרשאות מקומיות!) ולצמצם את ההרשאות. אם רוצים להשתמש לדוגמא ב-passwordless ssh, יש להגביל את החיבוריות להרצת פקודות מסויימות, כניסה מכתובות IP מסויימות, ועוד.
  • עדכוני תוכנה ללא תאריכון: אחת הבעיות שכתבתי לגביה שוב ושוב בבלוג זה – מנמ"ר מחליט שעדכונים יהיו אחת ל-X חודשים ותו לא. לך תסביר לאותו מנמ"ר שחולשות אבטחה מתגלות כל הזמן ויש לא מעט מקרים שיש צורך דחוף בהתקנת עדכונים, אחרת התשתית חשופה. דוגמא פשוטה: אם אתם משתמשים ב-vSphere, האם עדכנתם את הטלאי הדחוף הזה?

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

השינוי המהותי ש-VMware מתכננת לבצע

כנס VMWorld נערך באופן וירטואלי השנה ב-29-30/9 וכלל מגוון הרצאות, שרובם נעו על מוצרים ונושאים שב-VMWare כבר דיברו עליהם בעבר. אחד הנושאים שעבר "הכרזה מחדש" (3 פעמים! פעם אחת בשנה שעברה, פעם שניה בכנס VMworld ופעם שלישית רק לפני יומיים בכנס GTC) הוא נושא ה"DPU" (כלומר Data Processor Unit) של חברת מלאנוקס, עם מעבדי ה-Bluefield-2. חשבתי לכתוב פוסט על ה-DPU, אך מכיוון שיש עוד מספר שחקנים שהולכים להיכנס בדיוק לתחום זה עם שמות משלהם, החלטתי לכתוב פוסט יותר כללי בנושא.

תכירו – פרויקט Monterey

לפני שניכנס לפרטי הפרויקט, נסתכל על המצב הנוכחי, עוד ברמת ה-Hypervisor, ה-ESXi. כיום, ה-ESXi בעצם מריץ את כל השרותים כ-Hypervisor על מעבדי ה-X86 (ה-Xeon או EPYC) – בין אם מדובר בשרותי רשת, שרותי אחסון, אבטחה, Host Management ועוד. כל זה טוב ויפה, אך זה גוזל לא מעט משאבים מהשרת, וזה גם לא נותן מענה מלא לצרכים של הלקוחות כיום, שרוצים מהירות תקשורת יותר גבוהה, שימוש בכרטיסי FPGA וכרטיסים אחרים, חלוקה יותר טובה של נתיבי PCIe (העבודה שרוב יצרני השרתים, למעט חברת Supermicro ו-TYAN עושים בשרתים שלהם בכל הקשור ל-IOMMU, שלא לדבר על SR-IOV ומיפוי הנתיבים – היא פשוט בושה!), ועוד.

ישנה קטגוריה שלמה של כרטיסים חכמים שיכולים לבצע את כל התהליכים הללו, ובצורה הרבה יותר מאובטחת, יותר מהירה ויותר אמינה. הקטגוריה הזו נקראת SmartNIC. בדרך כלל מדובר בכרטיס רשת שכולל בתוכו מעבד ARM, אחסון Flash קטן, זכרון, ויכולות רציניות לטפל בתעבורה במהירות של 100-200 ג'יגהביט, כולל אבטחה בכל רמות התקשורת, הצפנה, שרותי אחסון NVME "על סיב" ועוד. ב-VMware עסקו בשנתיים האחרונות במיגרציה של קוד ה-ESXi ל-ARM על מנת לאפשר ל-ESXi בעצם לרוץ מהכרטיס ואותו מעבד ARM יתן את כל השרותים שה-ESXi כיום נותן – רק מבלי להשתמש במעבדי ה-X86 בשרת. מעבדי ה-X86 הנ"ל יוכלו להריץ מכונות וירטואליות, קונטיינרים, ומעתה – גם Bare Metal. תוכלו להריץ בעצם כל מערכת הפעלה על "הברזל", כאשר ה-OS יקבל את שרותי התקשורת, אחסון, ניהול וכו'  דרך ה-SmartNIC באופן שקוף. בנוסף, בעזרת ה-SmartNIC ופרויקט אחר (פרויקט Bitfusion) – נוכל גם לקבל שרותים מציוד שאינו נמצא על השרת עצמו, כמו שרותי GPU, שרותי אחסון NVME Over Fiber ועוד.

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

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

פרויקט Monterey נמצא כרגע במצב Preview, אך מי שחושב כבר לקפוץ ולהתחיל להשתמש בפירות של הפרויקט, כדאי שיעצור לרגע. כרטיסי ה-SmartNIC מתחברים בחיבור של 100-200 ג'יגהביט ומעלה, כך שסביר להניח שתצטרכו מתגים אחרים יותר מהירים ויותר יקרים. מבחינת סוגי כרטיסי SmartNIC, אין כרגע הרבה הצעות (יש את Bluefield-2 של חברת מלאנוקס, אינטל, ברודקום ועוד מספר חברות יצאו עם כרטיסים כאלו בשנה הבאה) וסביר להניח שתצטרכו גם בדרך להחליף שרתים, הואיל ויש צורך בשינויים על לוח האם, כולל שינויים מהותיים לקוד ה-UEFI שבשרתים.

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

הוירוס, עבודה מרחוק – והלאפטופ

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

מהרגע שעניין הוירוס קיבל דחיפות יותר ויותר גדולה בארץ, חברות עטו על יבואני מחשבים לרכוש לאפטופים לעובדים, בין אם מדובר ברכישה קטנה של בודדים או מאות. כל לאפטופ קיבל טיפול פירמוט והתקנת Image עם כל האפליקציות של החברה, חיבור VPN, חיבור לשיחות וידאו ועוד מספר דברים – וכך כיום רוב החברות עובדות: מרחוק, עם VPN, עם Zoom/teams/WebEx/Skype לצורך פגישות ושיחות וכו'.

וכאן גם מתחילה הבעיה הגדולה, בכל מה שקשור לאבטחת מידע: ככל שיש יותר לאפטופים מבוססי Windows/Mac שמתחברים לרשת הארגונית דרך ה-VPN, הסיכוי לפריצה – גדול עד גדול מאוד. אף קבוצה שפורצת לא מחפשת לפרוץ ישירות את התשתית הארגונית בכך שינסו לתקוף את ה-Firewall/IPS/IDS, הכל עושים "מסביב", דרך קבלני משנה, דרך לאפטופים של עובדים שלא מבינים כלום באבטחת מידע. כל מה שצריך בסופו של יום זה פשוט לפרוץ ללאפטופ שנמצא בבית במגוון שיטות, וברגע שאותו לאפטופ יהיה מחובר דרך ה-VPN, הפורץ יוכל להריץ ברקע מגוון סקריפטים כדי לסרוק/לגנוב מידע ועוד. לא מאמינים? תכירו את חברת Visser, קבלן משנה של NASA, SpaceX, Tesla ועוד מספר חברות – דרכה פרצו לאותן חברות וגנבו מידע ומאוחר יותר פרסמו אותו.

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

האם ניתן לעשות משהו בנידון? כן.

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

  1. ממבוזר – למרוכז. אחד הדברים הראשונים שצריך לעשות, הוא, מה לעשות, לעבור לפתרון VDI. עם תשתית VDI (ואני מדבר על תשתית VDI שרצה על מכונות VM, פחות על פתרונות של VDI לאפליקציות ספציפיות) אפשר להנות ממספר יתרונות:
    1. אין צורך בדרייברים שמגיעים מיצרני לאפטופים ומחשבים. בפתרון VDI מבוסס VMware לדוגמא, יש צורך בהתקנה של ה-VMware Tools וזה כבר יתקין את הדרייברים הנחוצים ותו לא. כך נחסוך בעיות של חורי אבטחה בדרייברים.
    2. הרבה יותר קל לנהל צי של מכונות וירטואליות מבחינת הקמה/כיבוי/הגדרות וכל ה-Life Cycle בהשווה לטיפול במכונה פיזית.
    3. אין צורך להתקין ערימת אפליקציות על Image. יש כלים כמו ThinApp או Enigma Virtual Box (לא להתבלבל בין זה לבין וירטואליזציית VirtualBox – אלו 2 דברים שונים) שנותנים אפשרות להריץ אפליקציות שהמשתמש צריך ללא צורך בהתקנה מראש, כך שהמשתמש יכול לקבל Image עם המינימום שבמינימום ולינקים לדברים נוספים בהתאם להרשאות ולצורך. כך אפשר להוריד את וקטור התקיפה – אין צורך בקורא PDF ישן או אפליקציות אחרות שהמשתמש לא צריך אותם.
  2. מעבר לשימוש ב-Thin Client. כן, כל לאפטופ יכול להתחבר ל-VPN בקלות, אבל אותו לאפטופ הוא מטרה מעולה וקלה מאוד לפריצה. לעומת זאת, מכשירי Thin Client טובים (Dell, HPE, Lenovo – כולם מוכרים כאלו) הם קשים יותר לפריצה הואיל והמערכת הפעלה הלינוקסאית שבתוכם מגיעה מראש כ-Read Only, וקשה יותר לפרוץ אליה מאשר ללאפטופ או לדסקטופ. אפשר לקחת את זה צעד קדימה ופשוט להשתמש במערכות כמו Stratodesk עם דיסק און קי שנחסום אותו לכתיבה – שממנו נבצע Boot, את זה הרבה יותר קשה לפרוץ.
  3. מניעת שימוש במשאבי אחסון מקומיים. מניעת אפשרות גישה לכונן C בלאפטופ המקומי יכולה לעזור בכך שגם לפורץ לא תהיה אפשרות העלאת סקריפטים וקבצים אחרים למכונת VM שהמשתמש יתחבר אליה. אפשר תמיד להקים File Server בתשתית המקומית ולמפות לכל משתמש כמה עשרות ג'יגהבייט כדיסק רשת לאחסון דברים.

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

  • אין צורך ברכישת אחסון סופר-יקר AFA עבור VDI. אפשר להשתמש עם דיסקים מקומיים ו-vSAN. הכי חשוב שהדיסק SSD המשמש לצרכי Caching יהיה SSD טוב, כמו Optane, הואיל ורוב העבודה של VDI עולה מה-Cache וכמעט שלא מהדיסקים האחרים.
  • אין צורך לרכוש כרטיסי GPU יקרים כולל מנוי חודשי ל-nVidia, כל עוד המשתמשים מבצעים עבודות בסיסיות ולא עבודות וידאו/תלת-מימד או עבודות הכרחיות.
  • מומלץ לרכוש מעבדים עם Cache גדול (מכיוון שהמעבד, בהיעדר GPU, מרנדר את התצוגה, ה-L3 Cache שלו חשוב, כמה שיותר גדול, יותר טוב). כיום מעבדי AMD EPYC כמו 7F72, 7F52, 7F32 הם מעבדים מעולים לכך (שימו לב, אלו מעבדים שהוכרזו רק שלשום, נכון לכתיבת שורות אלו, והם יוצעו למכירה ללקוחות בתחילת החודש הקרוב).
  • מומלץ לשנות/לשדרג/להחליף לרשיון "כרוך" (Bundle) ולא לרכוש עצמאית תוספת רשיון. דברו עם נציג שיווק פתרון הוירוטואליזציה שלכם.
  • אין צורך לרכוש במאות דולרים Thin Client. אפשר את הפתרון של Stratodesk (לינק למעלה) יחד עם Raspberry Pi 3/4 ובכך לחסוך יותר מ-50% מהמחיר פר חתיכה.

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

על דיסקים ואחסון

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

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

אבל מה קורה אם יש צורך להזמין כמות גדולה של דיסקים? (ב"גדולה" אני מדבר על כמויות של 30 ומעלה – בתור התחלה). ניקח את זה יותר לכיוון המציאות: אתם רוצים להקים תשתית וירטואליזציה Scale Out עם vSAN או Nutanix. אתם לא רוצים עדיין לרוץ לכיוון All Flash ולכן אתם רוצים לשלב דיסקים מכניים גדולים יחד עם SSD שישמשו כ-Cache. ב-2 הפתרונות המתחרים, כמות ה"ברוטו" מבחינת הדיסקים שתכניסו – רחוקה מאוד מכמות ה"נטו" שתקבלו בפועל לשימוש, ולכן אם נרצה כמות תלת ספרתית של אחסון נטו פנוי, נצטרך לרכוש לא מעט דיסקים עבור מינימום 3 שרתים. נניח לשם הפוסט – שנצטרך 21 דיסקים מכניים ו-3 SSD (כלומר 7 מכניים ו-1 SSD פר שרת).

לפני שנעבור לחישובים שונים, בוא נשנה לרגע נושא ונדבר על שרידות: כיום בשוק, אצל רוב מוחלט של החברות, מצב השרידות שקיים הוא מצב שהמערכת יכולה להמשיך לעבוד, כל עוד דיסק אחד הוא תקול. במקרה והתקלקל דיסק, מפעילים את ה-SLA ותוך 4 שעות יגיע טכנאי ויתן לכם דיסק חלופי, תחליפו את הדיסק בשרת/מערך אחסון, הפעילו תהליך Rebuild. מה יקרה אם יתקלקל עוד דיסק עוד לפני שהקודם הוחלף ובוצע Rebuild? תקוו שהגדרתם דיסק אחד כ-Hot Spare – אחרת אתם בצרות.

נחזור לחישובים: כיום, בין אם מדובר בישראל או כמעט בכל מקום אחר בעולם, רכישת דיסק קשיח, בין אם מדובר ב-SSD או מדובר בדיסק מכני, תעלה אצל יצרן שרתים פי 2-3 בהשוואה לרכישה מיבואן רשמי בארץ. תרגום: אם דיסק כלשהו עולה $100 אצל יבואן רשמי, אצל יצרן שרתים, אותו דיסק יעלה 300-$200. את ההבדל הזה די קל לבלוע כשמדובר על רכישה של שרת אחד עם 4-5 דיסקים. ראש שקט, רכישה חד פעמית, תשלום חד פעמי, לא עושים מזה סיפור.

אבל אם נסתכל על הדוגמא לעיל עם ה-Scale Out בשביל ה-Nutanix/vSAN (או GlusterFS, או Ceph), אנחנו מדברים על 21 דיסקים, ואנחנו נשלם בפועל מחיר של 50-60 דיסקים. אתם לא צריכים להאמין לי, אתם יכולים ליצור קשר ישירות עם היבואנים בארץ:

  • דיסקים של חברת טושיבה – חברת CRG
  • דיסקים של חברות Seagate, Western Digital – חברת ח.י.

(שימו לב – חברות אלו בד"כ לא ימכרו ללקוחות קצה או כמות קטנה של דיסקים בודדים, אבל אתם יכולים לשאול אותם לגבי מחירים, כדי שיהיה לכם מושג.)

אז במקרים שהרעיון של תשלום סכום כה מטורף קצת מפריע לכם – אפשר לחשוב על שרידות ברמה אחרת: במקום לרכוש 21 דיסקים מיצרן השרתים, אפשר לרכוש נניח 25 דיסקים מהיבואן (כל עוד לא מדובר עבור שרתי HPE – הם לא מקבלים דיסקים שאינם בעלי קושחה של HPE), ולאחסן 4 דיסקים בארון. במקרה והתקלקל דיסק, מוציאים אחד מהארון ובמקביל יוצרים קשר עם היבואן כדי לתאם שליחות/קבלה של דיסק חלופי אחר. במקרים כאלו, גם אם עוד דיסק ילך במהלך ה-Rebuild, יהיו לכם מספיק דיסקים חלופיים ועל הדרך תחסכו לא מעט כספים.

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

על אחסון, וירטואליזציה, ובעיות ביצועים

כמעט כל ארגון שמריץ פתרון וירטואליזציה (vSphere, Hyper-V, Xen, ואחרים) בדרך כלל משתמש בפתרון אחסון משותף לשרתים, בין אם מדובר בפתרון "הרכבה עצמית" (FreeNAS), פתרון קופסתי זול (Synology, Asustor, QNAP וכו') ובין אם מדובר במשהו קצת יותר גדול מצד חברות כמו HPE, IBM, Lenovo, Dell, NetApp, EMC וכו'. יש פתרון לכל תקציב.

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

אפשר לקטלג את סוגי התקלות ל-2 סוגים עיקריים. לסוג הראשון אני קורא "תקלות אבסולוטיות" ולסוג השני – "תקלות מעורפלות".

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

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

אני רוצה לתת דוגמא מה-LAB שלי. לפניכם צילום מסך מתוך מכונת VM ב-vSphere 6.7 שמריצה Windows 10 עם Crystal Diskmark 7. השרתים מחוברים לשרת ZFS עם 8 דיסקים מכניים ואין בו שום SSD, בחיבור 10 ג'יגהביט +SFP. על הנייר, כל מי שמבין באחסון, יאמר שהמספרים מעולים – 1.2 ג'יגהבייט קריאה/כתיבה על חיבור של 10 ג'יגהביט – זה המקסימום שאפשר לקבל.

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

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

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

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

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

  • הדבר הראשון שאני ממליץ, זה להשתמש בכלי בשם FIO. את הקוד של הכלי הזה אני ממליץ לקמפל באופן סטטי (בשימוש הפרמטר build-static– ), לפתוח תיקיה ב-Datastore כלשהו ולהעלות את הקובץ FIO הבינארי שקומפל לשם, ולוודא שיש לו הרשאות Executable. את הקובץ נריץ דרך SSH.
    הכלי (FIO) נותן לנו למדוד את מהירות הקריאה והכתיבה שיש לנו עם מדדים ופרמטרים שונים ובכך נוכל לדעת מהי מהירות הקריאה והכתיבה בין האחסון לשרת עצמו ישירות. כך נוכל לדעת אם הבעיה קשורה בתקשורת בין האחסון לשרת ולא בין האחסון למכונת VM כלשהי. חשוב: לבצע את הבדיקה עם כמה שפחות מכונות VM רצות על אותו שרת.
  • אנחנו יכולים להשתמש באותו כלי (ולחובבי Windows – יש את IOMeter שמבוסס על הקוד של FIO. את הכלי הזה, אגב, אפשר להריץ ישירות על Windows Server פיזי אם מדובר במכונה שנותנת שרותים דרך Hyper-V) כדי למדוד את אותם דברים שמדדנו קודם – אך הפעם אנחנו נמדוד בין מכונת ה-VM לאחסון, תוך שימוש ב-Datastore ובדיסק הקשיח הוירטואלי של אותו VM. שימו לב: התוצאות יכולות להיות שונות מהתוצאות שנקבל כתוצאה מבדיקה דרך הסעיף הקודם, הואיל והתרגום לדיסק הוירטואלי גובה מספר אחוזים בביצועים.
  • אם אתם מאלו שאוהבים כמה שיותר DATA כדי לאסוף כמה שיותר תובנות, בנו לעצמכם סקריפט שמשתמש ב-FIO כדי לבצע דגימות שונות ולאסוף את הנתונים לקובץ מסוים כדי לנתח אחר כך ולבדוק דגרגציה של פתרון האחסון ועוד.
  • אם הבעיה קיימת רק עם מכונות VM מסויימות, אז הבעיה אינה ממש קשורה לתקלות באחסון אלא יותר בכח של פתרון האחסון. הגיע הזמן להחליף למשהו יותר לכיוון ה-All Flash או לפחות עם פתרון Flash לכתיבה ו-Caching.
  • זה ישמע טריוואלי – אבל תפרידו תקשורת ברמה של פורטים ואם אפשר גם ברמה של סוויצ' – בין התקשורת מהאחסון לשרתים, לבין כל שאר הדברים. אני משער שחלק מהקוראים יאמרו "מה הבעיה עם VLAN?", אין בעיה – רק שבמקרים רבים אותם אלו שמגדירים נוטים לחתוך פינות ולפעמים ההגדרות לא יהיו נכונות ולא יסייעו. מצד שני – סוויצ' 10 ג'יגה כיום הוא דבר די זול.
  • דבר אחרון – כלים רגילים שמודדים ביצועים של דיסקים מכניים או SSD לא רלוונטיים במקרים של התקלות המדוברות בפוסט זה. זה נחמד להציג תמונות (או כדי למכור ללקוחות מצגת על פתרון) אבל התוצאות לא יהיו באמת נכונות (אתם באמת חושבים שמכונת ה-ZFS  הנ"ל בפועל יכולה לכתוב 1.2 ג'יגה בשניה בשעה שאין שום SSD? לא ממש, אבל ZFS יכול "לעבוד" על VMWare ובכך אפשר להציג את התוצאות הנ"ל, אם יש מספיק RAM בשרת, ובמקרה הזה – יש, 256 ג'יגה).

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