ההבדלים בין מעבדי אינטל שונים עבור שרתים (וידאו קליפ)

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

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

פרילאנסרים, מצלמה ושיחות וידאו

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

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

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

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

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

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

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

  1. הורידו והתקינו את אפליקציית OBS Studio מהקישור הבא (שימו לב: גירסת לינוקס אינה תומכת במצלמה הוירטואלית, נכון לגירסה 26.1, כך שזה יעבוד רק על Windows או מק).
  2. הפעילו את התוכנה והתרכזו בצד שמאל, בקוביה שכתוב עליה Sources
  3. לחצו על מקש ה- + בחרו Video Capture Device, תנו לזה שם, לחצו OK, ובחרו את המצלמה שלכם (חשוב שהיא לא תהיה בשימוש באפליקציות שיחות אחרות באותו זמן)
  4. באותו חלון של בחירה, יהיו אופציות שונות להגדרת המצלמה. אם אתם לא מבינים בתחום או לא מכירים – אל תשנו. לחצו OK
  5. אם הבחירה שלכם עבדה, אתם תראו את עצמכם בתוך חלון מוקף במסגרת אדומה. המסגרת מציינת אובייקט אקטיבי ב-OBS.
  6. אם אנחנו רוצים להוסיף לוגו, נלחץ שוב על ה- + ונבחר Image. חשוב: ה-Image אמור להיות בפורמט PNG אם רוצים רקע שקוף ללוגו (כמו אצלי בתמונה לעיל). תנו שם, לחצו על Browse ובחרו את הקובץ PNG עם הלוגו. לחצו OK לאישור. שוב אנחנו נראה ריבוע אדום מסביב לתמונה – השתמשו בריבועונים הקטנים מסביב לריבוע האדום הגדול כדי להקטין את התמונה ולמקם אותה היכן שתרצו.
  7. אם נרצה להוסיף טקסט (כמו שם, לדוגמא), נלך שוב לקוביית ה-Sources, נלחץ על + ונבחר Text +GDI – שוב, תנו לזה שם ולחצו OK. כעת יפתח חלון ובתוכו תהיה קוביה שחורה עם הכיתוב משמאל "Text" – הכניסו כאן את הפרטים שאתם רוצים (אפשר במספר שורות). שימו לב שהחלון שנפתח – נגלל, ויש אופציות שניתן לשחק איתן כמו פונט, צבע, ישור לימין, שמאל וכו'. הכניסו את הטקסט שאתם רוצים (אם אתם רוצים להכניס טקסט במספר גדלים, תצטרכו ליצור מספר אובייקטים של טקסט). אחרי שלחצתם OK, שנו את גודל ומיקום הטקסט על החלון.
  8. אפשר להוסיף אלפי דוגמאות נוספות וליצור דברים מדהימים (למי שלא ממש מרוצה מהאפקטים הוירטואליים של זום, ב-OBS יש תמיכה מלאה ב-Chroma Key, להלן קישור להוראות).

מרוצים ממה שאתם רואים? מעולה.

מצד ימין יש מספר כפתורים מוארכים (כמו Start Streaming וכו'). לחצו על הכפתור שנקרא "Start Virtual Camera")

זהו, אתם יכולים לבצע מינימליזציה של חלון ה-OBS (ב-Windows אפשר ללחוץ על אייקון ב-OBS בשורת האייקונים מימין/שמאל).

פתחו את אפליקציית הזום או סקייפ, לחצו על גלגל השיניים מצד ימין למעלה, לחצו על Video, ובחרו OBS Virtual Camera. אתם אמורים לראות מה שרואים ב-OBS. תוכלו לבחור אופציות אחרות כמו Mirror, תאורה וכו'.

ברכותיי, התצוגה המשופרת של עצמכם פעילה, תהנו מהחשיפה 🙂

מספר נקודות טכניות:

  • משתמשי מק – לא בטוח שהמצלמה הוירטואלית תעבוד (במיוחד עם Big Sur). כפי הנראה שתצטרכו להעיף חתימות, כפי שמוסבר כאן.
  • למי שרוצה – אפשר לבצע Up scaling של הוידאו. המצלמה הוירטואלית תשדר לפי הרזולוציה שמוגדרת ב-OBS. לשינוי – יש ללחוץ על Settings, על Video ולהגדר את ה-Output לרזולוציה שרוצים. שימו לב – סביר להניח שזה יאמץ את המחשב שלך במעט.

הקמת HPC – מקומית או בענן? נקודות למחשבה

חדש! אין לכם כח לקרוא? אתם יכולים ללחוץ על הקישור כאן או להסתכל בסוף הפוסט על וידאו קצרצר המסכם את הפוסט.

עולם ה-HPC הוא עולם שמתקדם בקצב איטי. עד לפני שנים מעטות, השינויים המהותיים היו יותר קשורים ל-Job management פופולרי (slurm ש"כבש" פופולריות במקום ה-Sun Grid Engine לדוגמא, שהפך לאחר מכן ל-Son of Grid Engine) וברוב המקרים כשהיה מדובר על מערכות גדולות (עשרות, מאות שרתים ומעלה) חברות כמו Dell ו-HPE החליפו שרתים של Sun (לאלו שהיתה להם מערכת HPC ישנה יותר).

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

  • מבחינת מערכת File system מרכזית – ל-Lustre עדיין יש מקום ורלוונטיות (גירסה חדשה שוחררה רק בחודש שעבר), אך במקביל, מערכות כמו Gluster ו-CEPH תפסו מקום נכבד כ-Scale Out Storage
  • יותר ויותר חברות עוברות לשימוש מאסיבי יותר בכרטיסי GPU יעודיים (V100, A100 של NVIDIA, וכרטיסים אחרים לעיבוד AI/ML/DL מחברות כמו AMD ואיננטל יכנסו בקרוב לשוק בצורה יותר רצינית).
  • חיבוריות/רשת תקשורת פנימית עוברת שדרוג רציני. במקרים רבים, חברות היו משתמשות בחיבור סיב במהירות של 10 ג'יגהביט, כיום בד"כ ההמלצה היא 50 ג'יגהביט ומעלה.

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

כיום חברות כמו NVidia מציעות שרתי DGX במחיר שווה: במחיר של 200-220K אתה מקבל שרת עם 2 טרהבייט זכרון, 8 מודולי GPU מסוג A100 (עם 80 ג'יגהבייט זכרון פר מודול), אחסון מקומי בגודל 36 טרהבייט, 128 ליבות (2 מעבדי AMD EPYC עם 64 ליבות), קישוריות רציפה בין מודולי ה-GPU (זה ה-NVSwitch) ומספר חיבורים במהירות 200 ג'יגהביט. עם קופסאות כאלו, בדרך כלל תצטרך לרכוש מתג (או מתגים, תלוי בקופסא) ותצטרך לדאוג לפתרון אחסון Scale Out (אם מדובר ברכישה של 10+ שרתים) וגם פתרון אחסון יותר איטי – והרי לך פתרון HPC בסיסי ברמה העקרונית (כמובן שברזלים זה נחמד, אבל יש המון עבודה להתקין דברים, להגדיר, אוטומציה, Job Management ועוד ועוד)

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

לרכוש ולבנות "משלנו" או ללכת עם פתרון ענן של ParallelCluster של AWS (או פתרון של Azure או GCP)?

על מנת לענות על שאלה זו, נצטרך בשלב הראשון לחלק בעצם את פתרון ה-HPC ל-2 חלקים:

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

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

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

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

  • זמינות לעבודה מיידית: בין אם אתה צריך 1000 או 10000 ליבות, בין אם אתה צריך 2 או 300 כרטיסי GPU החדשים ביותר – הם זמינים עבורך תוך דקות ספורות. אין צורך להמתין שהמערכת תתפנה, או להבין שאין ב-HPC המקומי את הציוד שאתם כלקוח צריכים.
  • התשלום הוא רק עבור שימוש: הפעלתם דרישה של 1000 ליבות לעבודה שלקחה שעתיים ו-14 דקות? על כך בדיוק תשלמו (פלוס האחסון, תעבורת אינטרנט וכו'). בסיום ה-JOB בדרך כלל (בהתאם להגדרות) המערכת "תהרוג" את כל ה-Nodes המשתתפים בעבודה (לאחר שהחומר הרלוונטי הועבר לאחסון), מה שמאפשר ביצוע עבודות רבות עם תקציב קטן יחסית, גם לסטארט-אפים.
  • מבחר ענק של ציוד: צריכים מכונות חזקות מאוד? חלשות (עם תשלום נמוך)? עם 2 כרטיסי GPU? ללא כרטיסי GPU? עם מהירות תקשורת של מאות ג'יגהביט? עם אחסון במהירות 7 ספרות IOPS? ברוב פתרונות ה-HPC, האפשרויות מצומצמות מאוד, ובענן – כל מה שצריך זה לבחור ולשנות שורה אחת בקובץ קונפיגורציה.
  • תאימות: רגילים לעבוד עם SGE, עם Slurm, עם Torque? רוב הסיכויים שפתרון ה-HPC בענן כבר תומך ב-Job Management שאתם רגילים אליו, ולכן מעבר לשימוש HPC בענן יהא יחסית קל.

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

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

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

ישנן סיטואציות בהן ההחלטה היא יותר קלה לכאן או לכאן:

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

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

למעוניינים – גירסת וידאו קצרה המסכמת את הפוסט:

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

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

הפריצה הגדולה למשרדי ממשלה בחו"ל

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

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

התשובה היתה: פלטפורמת Orion של Solarwinds לניטור המערכות של הארגון.

אחרי שהם הבינו זאת, ב-APT29 פשוט פרצו אל Solarwinds ולקחו שליטה על שרת העדכונים, ומדי פעם הם החליפו את קבצי העדכונים בקבצים שהם Weaponized (כלומר – קבצים הכוללים כלי שליטה ושלל כלים אחרים עבור הפורצים). מערכת ה-ORION היתה מקבלת שדרוג מהשרת הפרוץ, השדרוג היה מותקן אוטומטית בארגון (שום מערכת IPS/IDS לא קופצת על עדכונים כאלו, כי אין להן שום דרך לדעת על העדכון), ולאחר מכן הקבוצה יכלה "לדבר" עם שרת הניטור דרך C&C, לשלוח פקודות, לקבל פלט, לקבל קבצים ומידע וכו'. הכניסה הזו הוותה בעצם "שער אחורי" שממנו הקבוצה חקרה את התשתית הפנימית של הארגון והחלה "לעבוד".

מדוע אני חושב ששיטה זו "גאונית"? הסיבה לכך פשוטה: לא חשוב כמה הארגון הגדיר את התקשורת ואת חוקי ה-Firewall או ה-IPS/IDS בארגון. בדרך כלל נותנים גישה לתוכנת הניטור לכל שרתי הפרודקשן. אינני מדבר על גישת username/password אלא גישה ספציפית לנטר את השרת, הן מבחינת משאבים (דיסק, רשת, CPU וכו') והן מבחינת שרותים שרצים על השרתים. במילים אחרות, גם בלי Agent בכל שרת, במערכת הניטור יש מספיק ידע כדי לדעת מה השרתים שיש, כמה, ומה רץ עליהם, ובחלק מהמקרים מוגדרים שם משתמש וסיסמא כדי להיכנס לשרות. במקרים שיש Agent מותקן, אז כל מה שצריך הוא להכניס Agent "נגוע" לשרת הניטור שיפיץ את ה-Agent לכל השרתים המנוטרים ומשם אפשר להיכנס ולשאוב את המידע מבלי "להקפיץ" מערכות אבטחה. זיכרו: התקשורת בדרך כלל בין שרת הניטור לשרתים האחרים ברוב הארגונים אינה מנוטרת מבחינת אבטחה/רוחב פס, DLP וכו'.

אבל כאן זה לא נגמר.

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

אז מה ניתן לעשות?

אם אתם משתמשים ב-Orion, כדאי בדחיפות לבדוק איזו גירסה יש לכם ולעקוב אחר ההוראות של Solarwinds. במקביל, אני ממליץ לעבור על קבצי LOG לבדוק התנהגות חשודה (לא שתגלו הרבה אם זה APT29, הם עושים את כל המאמצים לא להתגלות ולא להקפיץ מערכות). בנוסף, יכול להיות שהגיע הזמן לרכוש ביטוח סייבר ולמצוא חברה רצינית (לא אדם יחיד) לבצע בדיקות Penetration Testing לארגון.

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

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

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