קטגוריה: וירטואליזציה

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

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

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

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

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

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

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

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

תכירו: משפחת ה-Ryzen 5000

חברת AMD הכריזה לפני כשבועיים על מעבדי ה-Ryzen דור רביעי לדסקטופ (מבחינת מספרי הדגמים, הם החליטו לקפוץ מ-3000 ל-5000 לאחר שהם הצליחו ליצור סלט שלם בדגמי ה-4000). בפוסט זה אתייחס הן לדגמי הדסקטופ והן למעבדי ה-EPYC לשרתים שיצאו כבר בקרוב.

מעבדי Desktop לשרתים

מבחינת מעבדי הדסקטופ, ב-AMD ממשיכים להוציא את אותם מספרי דגמים שהוציאו בגירסה הקודמת, בקצה הגבוה נמצא 5950X עם 16 ליבות, 5900X עם 12 ליבות, 5800X עם 8 ליבות ו-5600X עם 6 ליבות, בדיוק כמו שהיה עם ה-3950X, 3900X, 3800X, 3600X, רק שהפעם אין בשלב זה דגמים ללא X כמו שהיו בדגמי ה-3000 (אלו יצאו בשנה הבאה). המחירים – עלו במעט, בממוצע כ-50$ בהשוואה למעבדים מסידרה 3000.

מבחינת ביצועים (שזה כמובן הדבר הכי חשוב למשתמשים) – AMD הציגה עליה משמעותית בביצועים של עד 19% – במיוחד בעבודות Single Threaded, ולראשונה במבחנים סינטתיים – AMD עוקפת את כל המעבדים שאינטל מוכרת בגיזרת הדסקטופ (שוב, בעבודות Single Threaded, ב-Multi Threaded המעבדים של AMD עוקפים ממזמן את המעבדים של אינטל). במבחן כמו Cinebench, מעבד כמו ה-5950X מגיע ל-640 ב-Single Threaded ומעבד 5900X מציג באותו מבחן את המספר 631. לשם השוואה, מעבד ה-10900K מגיע ל-539 באותו מבחן ומעבד כמו ה-Tiger Lake החדש לדסקטופ (דגם: Core i7-1185G7) מגיע ל-598 (אך זהו אינו מעבד לדסקטופ, זהו מעבד למחשב נייד).

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

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

  • אם יש לכם לוח אם מבוסס Chipset כמו X570 או B550 – תוכלו כבר בחודש הבא לרכוש את המעבד, לשדרג את ה-BIOS, להחליף את המעבד ולהמשיך לעבוד כרגיל.
  • אם יש לכם לוח אם מבוסס Chipset כמו X470 או B450 – לרוב הדגמים יצא שדרוג BIOS במהלך חודש ינואר אשר יוסיף תאימות למעבדים החדשים (אך יסיר תאימות ממעבדים ישנים כמו Ryzen מסידרה 1000 ו-2000, פשוט אין מקום בשבב הפלאש לכל העדכונים).
  • רשמית – המעבדים יצאו לשוק ב-5/11. הסיכוי שלכם לרכוש ולקבל מעבד כזה בארץ בתאריך הנ"ל – די טוב (נודע לי לאחרונה כי כבר יש מלאי בארץ, אך המכירה אסורה עד ה-5/11).
  • לאלו שאין ברשותם מעבד Ryzen וחושבים לרכוש (במסגרת בניה עצמית של מחשב) לוח אם ואז את המעבד, אני ממליץ להמתין: בהשקה הרשמית יכריזו יצרני לוח האם על לוחות אם חדשים עם תכנונים משופרים.

חשוב לזכור: כמו שזה נראה כרגע, כנראה שסידרת ה-Ryzen מסידרה 5000 הם "תחנה אחרונה", וכשיצאו מעבדי ה-Ryzen 6000 יהיה צורך בלוח אם חדש וכנראה זכרונות חדשים (DDR5), ולכן אם חושבים להשקיע סכום מהותי ברכישת לוח אם חדש ובמעבד, כדאי לקחת בחשבון שכנראה לא ניתן יהיה לשדרג את המערכת למעבדי Ryzen עתידיים.

מעבדי EPYC לשרתים

באופן רשמי, ב-AMD עדיין לא מדברים/מספרים על מעבדי ה-EPYC מסידרה 7003 (שם קוד: Milan), והדברים יפורסמו באופן רשמי במהלך השבועות הקרובים (אני מאמין שבמהלך נובמבר), אבל עד אז – הנה כמה נקודות מעניינות:

  • שיפור ביצועים משמעותי בהשוואה ל-EPYC דור קודם (7002): כמו ב-Ryzen, גם כאן יש תכנון חדש לזכרון המטמון ברמות 1 ו-2, כך שבפועל ה-Latency נחתך בצורה משמעותית, מה שמתורגם לביצועים גבוהים, כאשר ברוב המקרים מדובר על שיפור דו ספרתי.
  • מבחינת וירטואליזציה – מעבד EPYC דור 7002 (הדור הנוכחי) נתנו מספר יתרונות מבחינת אבטחת וירטואליזציה בהשוואה למה שאינטל נותנים (אינטל תתן פתרון מועתק במשפחת מעבדי ה-Xeon הבאים בשנה הבאה, ע.ע. TME) ולאחרונה התבשרנו כי vSpehre 7 עדכון 1 יתן תמיכה בפונקציות החדשות להצפנת מכונות וירטואליות, דבר שיתקבל בהחלט בברכה במקומות שאבטחה היא במקום הראשון. במעבדי EPYC דור 7003 אנחנו צפויים לקבל עוד מספר שיפורים חדשים באבטחת וירטואליזציה (אם כי מבחינת תמיכה, זה אולי יהיה ב-vSphere 7U2 או בגירסה 8, אך אם משתמשים בוירטואליזציה מבוססת KVM – התמיכה תגיע בחודשים הקרובים)
  • אחת הנקודות שעולות שוב ושוב בפורומים שונים של משתמשי EPYC היא תאימות לאפליקציות שאינטל מבצעת בהם אופטימיזציה, כמו הוספת תמיכה ב-AVX 512. ובכן, בדגמי ה-EPYC החדשים יש תמיכה ל-AVX 512 ולעוד מספר טכנולוגיות ידועות.
  • תאימות לאחור – גם הפעם, יהיה אפשר להשתמש במעבד EPYC מסידרה 7003 על שרתים ישנים יותר (3 דורות אחורה). חשוב לציין כי את התמיכה לכך יש צורך לקבל מיצרן השרתים (בד"כ זה יהיה במסגרת KIT הכולל מעבד חדש או במסגרת עדכונים שהיצרן מוציא לשרתים). כל היצרנים יתמכו בשדרוג ממעבדי EPYC דור 7002 לדור 7003, אולם רק חלק מהם יתנו תמיכה לשדרוג מ-EPYC דור 7001.
  • שיפור ביצועים משמעותי בכל הקשור ללינוקס: ב-AMD הוסיפו פקודות חדשות, והוסיפו שיפורים למהדר כמו GCC (זה נקרא Znver3), כך שאם רוצים שיפורים מעבר לשיפורים שמקבלים כברירת מחדל, אפשר לקמפל עם הפרמטרים החדשים ולקבל ביצועים עוד יותר גבוהים

חשוב לציין: גם כאן, כמו עם מעבדי Ryzen, המעבדים שיצאו יהיו כנראה בחזקת "תחנה אחרונה". ב-AMD עובדים במרץ על EPYC דור 7004 (שם קוד: Genoa) שיתן תמיכה ב-PCIe 5, זכרון DDR5, תמיכה ב-CXL, וטכנולוגיות רבות אחרות, כולל שינוי כל ה"שיחה" בין ה-CPU לכרטיסי GPU (בהצלחה ל-NVIDIA עם NVLINK), ומעבדים אלו לא יהיו תואמים אחורה.

לסיכום: AMD פתחה את הרבעון האחרון של 2020 בהכרזה על מעבדי Ryzen, בהמשך החודש על כרטיסי ה-GPU לדסקטופ, ולאחר מכן יגיעו ההכרזות על מעבדי EPYC לשרתים, כרטיסי GPU לצרכי ML/DL. התחרות בתחומי ה-GPU – בשיאה (NVIDIA כבר הכריזה על הכרטיסים שלה, AMD יכריזו בחודש הקרוב, ואינטל במחצית הראשונה של השנה הבאה) והתחרות בתחום המעבדים תתחיל החודש הבא ואילו אינטל תתן מענה הן בתחילת שנה הבאה (ICE Lake, מעבדים שאני לא ממליץ לרכוש, הואיל ואלו מעבדים שיהיו רלוונטיים אולי במשך חצי שנה) והן במחצית השניה של 2021 שבה היא תציג את מעבדי ה-Sapphire Rapids שיהיו מבוססים ארכיטקטורה חדשה (ביי ביי, Skylake), ויהיו שונים מהותית ממה שאינטל מוכרת כיום, ועם שיפורים מדהימים ורעיונות.. יצירתיים.

תכירו: ESXi למעבדי ARM

בכל מה שקשור לוירטואליזציה, עד היום שלטו ללא עוררין מעבדי ה-X86 ובסקטור ה-Enterprise שולטת ללא עוררין חברת VMware, עם פלטפורמת ה-vSphere. אינטל ו-AMD משקיעות מאמצים רבים בפיתוח ושיפור התמיכה בוירטואליזציה במעבדים (ה-"שוס" האחרון: הצפנת מכונות וירטואליות, דבר שקיים זמן רב במעבדי EPYC ויהיה זמין במעבדים בדור הבא בשנה הבאה במעבדים של אינטל).

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

בעולם השרתים ב-On Prem, כפי שציינתי, מעבדי X86 שולטים, ובשוליים אפשר למצוא גם מעבדי Power של IBM (שתומכים בוירטואליזציה הרבה לפני שאינטל בכלל חשבו על VT-X לדוגמא) ולאחרונה יש יותר ויותר התעניינות גם במעבדי ARM מבחינת הרצת מכונות וירטואליות, קונטיינרים וכו', והפעם מדובר לא רק בגלל המחיר – מספר מעבדים מבוססי ARM לשרתים שיצאו בשנה הבאה הבאה ידעו לתת פייט רציני מבחינת ביצועים גם מול מעבדי Xeon המובילים של אינטל.

ב-VMware היו מודעים לנושא ובשנים האחרונות ישנו צוות שכל מטרתו היה לגייר את קוד ה-ESXi וכל השכבות והחלקים של הפלטפורמה – למעבדי ARM השונים הפופולריים בשוק, וכעת סוף סוף החברה חושפת את המוצר לציבור ומאפשרת הורדה למספר מערכות עם מעבדי ARM שונים:

  • מערכת Raspberry Pi 4 (תצטרכו 8 ג'יגה זכרון, על גירסת ה-4 ג'יגהבייט בקושי תצליח להריץ משהו ותשכחו מ-Raspberry Pi 3 וגרסאות קודמות)
  • מספר מערכות הכוללות מעבדים Ampere eMAG (אין קשר ל-NVidia)
  • Solidrun Honeycomb LX2
  • לוחות המבוססים על LS1046A של NXP (מי שחושב לרכוש ולא מכיר את הלוחות האלו – מומלץ לפני כן לפנות ליבואן של NXP, המערכות שלהם די מורכבות ולא מומלץ לרכוש ישירות מהאתר)

לאלו שכבר רוצים להוריד את ה-ISO – הוא זמין להורדה כאן, רק לפני שרצים להוריד ולהשתמש, אתם מוזמנים לקרוא את ההערות הבאות:

  • הגירסה שזמינה היא נסיונית ומוגבלת בזמן. הגירסה תפעל ל-180 יום ולאחר מכן תצטרכו להקים אותה מחדש.
  • יש קובץ ISO להורדה, אבל בניגוד לגירסת ה-X86, ההתקנה עצמה יותר מורכבת ומי שלא מכיר לינוקס יצטרך להיאזר בסבלנות ולעקוב אחר ההוראות (המעולות) שהם סיפקו. ככלל, ידע בלינוקס מאוד יעזור עם הגירסה הזו (אגב, בגירסה הזו VMWare עושים "אחורה פנה" וחוזרים להיות מבוססי לינוקס)
  • מכיוון שיש עשרות (אם לא מאות) לוחות/SBC מבוססי ARM, רבים יתהו האם ESXi גירסת ARM תרוץ על לוחות אלו. התשובה לכך קשורה בתשובה לגבי הלוח/SBC אם הוא תואם SystemReady SR ופלטפורמת ה-ARM היא V8 ומעלה. אם כן, יש סיכוי שה-ESXi ירוץ. מעבדי ALTRA או Jetson של NVIDIA – לא נתמכים כרגע.
  • מבחינת מערכות הפעלה שניתן להריץ כ-Guest: כרגע אפשר להריץ אובונטו 20, פדורה ועוד כמה הפצות לינוקס. כרגע גרסאות Windows ל-ARM אינן נתמכות.
  • מבחינת Storage – אפשר להשתמש ב-SSD מקומי או לחבר iSCSI. אין תמיכה כרגע ב-NFS.
  • אם אתם מתקינים הפצה בלתי נתמכת וצריך לבחור מהו כרטיס הרשת, זה vmnic128 (לקח לי קצת זמן למצוא את זה)
  • אפשר לנהל את ה-ESXi מ-vCenter כמו כל שרת רגיל – כל עוד אתם משתמשים ב-VCSA 7.0D ומעלה.
  • אם אתם רוצים להריץ כמה וכמה קונטיינרים ומכונות VM – אני ממליץ לרכוש לוח אם או תחנה מבוססת eMAG של Ampere + מעבד, זכרונות וכרטיס רשת שמופיע בתיעוד (לא מלאנוקס וכו')
  • אל תנסו להתקין VMWare Tools דרך ה-vSphere. השתמשו ב-Open VM Tools (קיים לכל ההפצות)
  • יש יכולות של Live Migration, רק שכדאי לשים לב לפני כן להגדרות כרטיס רשת וכו', אחרת אתם עלולים לתקוע את המחשב.
  • אל תחברו ותנתקו ציוד USB מהמחשב, זה יכול לגרום לקריסה.
  • אם אתם רוצים להקים Cluster של ESXi מבוסס Raspberry Pi, אז מומלץ להשתמש ב-HAT ו-PoE במקום ערימת ספקי כח. במסמך של VMWare ל-Pi יש המלצות ספציפיות.
  • אל תנסו להקים VDI על זה 🙂

לסיכום: ESXi על מעבדי ARM יכול להיות פתרון מעולה אם רוצים לנסות מכונות VM שלא מצריכות כח מחשוב מאסיבי, וזה יכול להיות גם פתרון מעולה להרצת קונטיינרים לטסטים/Dev וכו', רק חשוב לזכור שזוהי גירסה ציבורית ראשונה ונסיונית, וחשוב לעקוב אחר ההוראות הניתנות בתיעוד ה-PDF ש-VMware פרסמו.

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

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

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

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

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

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

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

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

אז מה ניתן לעשות? לשכנע את הלקוח לנסות משהו אחר. אחת ההצעות: מכונה שתהיה זמינה Online.

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

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

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

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

האם מומלץ להעביר מערכת שלמה לענן מ-On Prem?

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

למי שלא מכיר, אחד המושגים הכי שגורים בפני כל מי שמתעסק בתחום עננים ציבורים הוא המושג "Lift & Shift", כלומר המושג מתאר מצב בו הלקוח מעביר את כל או רוב התשתית שלו מה-DC שלו אל ספק הענן בתצורה כמה שיותר זהה. לדוגמא: אם יש ללקוח 100 מכונות וירטואליות שמריצות את כל האפליקציות, הפלטפורמות ושאר דברים ב-On Prem, ב-Lift&shift מעבירים הכל "כמו שזה" (או כמעט) אל ספק הענן הציבורי שהחברה חתמה מולה, כך שבסופה של ההעברה, יש 100 (או קצת פחות) מכונות וירטואליות רצות בענן.

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

להלן הסיבה מדוע אני לא ממליץ על המהלך:

ללקוח יש 100 מכונות וירטואליות והוא מעביר אותם בתהליך lift & shift. הלקוח בעצם ישלם את מחיר המקסימום לספק הענן מבחינת ההמרה. הועברו 100 מכונות, כאשר רוב המכונות כלל אינן מנצלות את המשאבים ב-VM. מה הרווח של הלקוח ממעבר כזה? מבחינת ביצועים, אינני בטוח שפתאום יהיו ביצועים גבוהים יותר (אלא אם מעבירים מכונות VM משרתים בני יותר מ-7 שנים). מה שכן, התשלום לספק הענן יהיה הרבה יותר מסיבי: אם הגדרת 100 ג'יגהבייט דיסק וירטואלי מבוסס SSD, אתה תשלם על 100 ג'יגהבייט (במיוחד אם הגדרת את ה-Block Storage מ-SSD מהיר), גם אם השתמשת ב-10 ג'יגהבייט. בענן אין "Thin Provisioning", וכנ"ל לגבי זכרון וכח עיבוד, וכל זה עוד לפני שינויים ואופטימיזציות שהלקוח רוצה לעשות כדי לעבוד בענן..

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

  • שימוש בשרותים מנוהלים במקום מכונות VM שאתה מקים/מריץ. יצא לי לבחון לא מעט שרותים של ספקי ענן שונים ואני חייב לציין שבמרבית המקרים, השרותים של ספקי הענן נתנו ביצועים טובים. בלא מעט מקרים, אצל לקוחות שונים מריצים מכונות VM שמריצים אפליקציות שונות – אין הגדרות ואופטימיזציה טובה. דוגמא פשוטה: אצל ספקי ענן שונים אפשר לאחסן את ה-DB המנוהל באחסון זול ומכני או SSD או ב-SSD מסוג מהיר, כאשר ה-OS יושב על אחסון מסוג אחר. (בסביבות On prem, רוב מכונות ה-VM גם רצות וגם מאחסנות את ה-DB על אותו סטורג)'. נכון, זה עולה יותר, אך הביצועים גם גבוהים בצורה משמעותית, שלא לדבר על כך שכשזה מגיע להגדרות של אפליקציות שונות (שרתי Web, שרתי SQL ועוד) – אצל רבים אין ממש אופטימיזציה – שכן קיימת בשרותים המנוהלים אצל ספקי הענן.
    לכן, לפני שחושבים להעביר את אותו שרת SQL (לדוגמא) – כדאי לחשב מה העלויות של שרות זהה מנוהל עם Instance דרוש ואחסון, וזאת בהשוואה ל-VM שאתם תקימו. כדאי לקחת בחשבון גם תחזוקה והשבתה שתתרחש במקרה של VM שלכם.
  • אפליקציות עצמאיות: שרותים כמו Beanstalk, או App Service של אז'ור, או App Engine של גוגל – ושלל פתרונות זהים אחרים – שרותים אלו נותנים לך בעצם להריץ את הקוד שלך בשפה שאתה כותב – על תשתיות ספק הענן, כאשר אינך צריך להקים תשתית של VM, תשתית Load Balancing ועוד. אתה כותב קוד ומאחסן אותו בשרות כלשהו, מצמיד Webhook לשרות הנ"ל בענן, והשרות כבר ירים ויריץ את כל מה שצריך מבחינת pipelines, הוא יקמפל ויארוז מה שצריך, ויכין Instances חדשים שבחרת את גודלם. אתה לא צריך לדאוג לגבי עומסים, המערכת תדע לבצע אוטומטית Scale Out לאפליקציה שלך ותוסיף/תוריד Instances כנדרש, ותצמיד אותם ברקע לשרות Load Balancing כך שלא תפסיד בקשות מדפדפנים או ממכשירים שונים (בהתאם לאפליקציה). כאן בדיוק נמצא עקב האכילס אצל חברות רבות שמריצות אפליקציות בתשתית On-Prem (או תשתית Hosting) שמשרתות גולשים וה-Scaling שלהם הוא ידני. עם שרותים כנ"ל, אפשר להגדיר Instances קטנים ולשלם מחיר זול רק על מה שהיה בשימוש, הקץ לניחושים והערכות לגבי הקמה של יותר מדי או פחות מדי משאבים.
  • קונטיינרים: זו ה-טכנולוגיה של השנים האחרונות שחברות רבות כבר עברו להשתמש בה (ומי שלא – הסעיף לעיל רלוונטי לגביו) וכאן ספקי ענן שונים מציעים שרותי קונטיינריזציה שונים, בין אם מדובר על שרותי קונטיינר מנוהלים שאתה מחליט כמה Instances להקים/להוסיף/להוריד, ובין אם מדובר בשרותים שאתה כלל לא דואג לתשתית ובמקום זאת אתה פשוט משלם על שימוש בזכרון ובמשאבי עיבוד. השילוב של קונטיינריזציה ושימוש בתשתית של ספקי ענן ציבוריים יכול לתת פתרון עם ביצועים מעולים ולאו דווקא מאוד יקרים.

מעבר לענן ציבורי יכול לחסוך כסף, כל עוד מוכנים "לשנות את הדיסקט" בראש ולוותר על חלק משיטות העבודה מה-20+ שנה האחרונות. שיטות כמו Lift & Shift לא יעזרו הרבה ללקוח אבל הם בהחלט יעזרו לשורה התחתונה מבחינת כספים לספק הענן הציבורי שבו הלקוח משתמש. אם רוצים לעבור לענן ציבורי, אני ממליץ לחשוב על המעבר כעל פתיחת דף חדש, תוך אימוץ טכנולוגיות מודרניות ונטישה הדרגתית של טכנולוגיות Legacy.

עריכת תכני מולטימדיה – תחנות עבודה מול עבודה מרחוק

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

לשיטה כזו יש כמובן יתרונות כמו "שקט" ללקוח הרוכש, אולם יש לה גם בעיות:

  • חוק מרפי אומר שאם ידפק הדיסק הקשיח של תחנת העבודה, שחזור דרך ה-Image לעולם לא יספיק ותמיד יאבדו קבצים חשובים ספציפית לאותו עורך או קבצים חשובים אחרים שנשמרו בתחנה אך מעולם לא גובו בגיבוי המרכזי.
  • Overpowered או Underpowered – בלא מעט מקרים שיצא לי לראות, הלקוח רכש מכונה שהיא או חזקה מדי לאותו סוג עבודות, או שהיא חלשה מדי. מה לעשות, לא כולם לוקחים בחשבון חישובי Single threaded Performance לתוכנות "סוררות" כמו פוטושופ, אפטר אפקט ועוד.
  • למכונה אין גיבוי בפתרון הגיבוי המרכזי, כך שאם מישהו החליט שעכשיו זה רעיון טוב לשדרג לדוגמא את פרמייר ופתאום פרמייר כלל לא מוכן לעבוד, גם לאחד הסרת הגירסה החדשה – יהיה לנו עובד ותחנה מושבתים, וכמה שעות של עבודה כדי להחזיר את התחנה לעבודה רגילה. כנ"ל גם במקרים שיש תקלות פתאומיות (כי מישהו לחץ על OK להתקין עדכוני Windows ש..אופס, דפקו את התחנה)

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

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

  • התאמה מדויקת של מכונה וירטואלית לאותו עובד. בתחנות עבודה יש צורך לקבוע מראש כמות ליבות/זכרון/סוג GPU. במכונה וירטואלית אפשר לעומת זאת "לחתוך" כמות מדוייקת ובכך למנוע בזבוז משאבים. מעבד עם 20 ליבות לדוגמא, הוא דבר מיותר לחלוטין לפוטושופ או לאפטר אפקט.
  • אפשרות שדרוג מיידית כשצריך יותר משאבים: רבים אולי לא מודעים לכך, אבל כשעורכים סרט/וידאו, עריכה "רגילה" (חיתוך, Transitions, דברים די בסיסיים) אינה מצריכה כמו זכרון VRAM גדולה. לעומת זאת, קולוריסטים שמשתמשים ב-דה-וינצ'י ויוצרי אפקטים (באותה תוכנה) יצטרכו כמות VRAM הרבה יותר גדולה, ואת זה אפשר לקבוע פר VM.
  • מכונות ה-VM הנ"ל יגובו כל יום במסגרת גיבוי מרכזי באולפן וכך, גם במקרה של תקלת "הצילו" יהיה אפשר לחזור יום אחורה בלי בעיה תוך דקות ספורות.
  • התכנים ישבו בתוך פתרון אחסון (אין צורך במשהו סופר יקר) שגם הוא יגובה, כך שגם כאן – שום תוכן לא הולך לאיבוד ולא מסתמכים יותר על פתרונות NAS שעולים 800 שקל ב-IVORY.
  • אפשר לעבוד מכל מקום – מהלאפטופ, בגינה בחוץ, אפשר להדגים בחדרי ישיבות את העבודה ועוד ועוד.
  • קל להוסיף משאבים לשרתים: GPU? זכרונות? מעבירים את מכונות ה-VM למכונה אחרת, מוסיפים, מפעילים, יוצאים ממצב Maintenance, ואפשר לפזר את המשאבים החדשים למי שצריך.

הפתרון שאני מדבר עליו קשור ל-VMware (למען האמת, גם פתרונות מתחרים כמו Nutanix, Xen יתנו את אותו פתרון) ללא שימוש ב-VDI. החיבור עצמו יכול להתבצע דרך RDP שקיים בתוך ה-VM או דרך פתרון צד ג' כמו Parsec או Teradici. מבחינת Latency, מנסיונות שביצעתי לאחרונה, הוא נמוך מאוד.

מה לגבי עבודה מרחוק, מהבית? ובכן, בישראל, לצערי ספקי אינטרנט אוהבים "לשחק" עם רוחבי הפס (הן מצד החוות שרתים והן מצד ה-DSL/כבלים). פרמייר/דה-וינצ'י/AVID ותוכנות אחרות בעבודה מרחוק דורשים רוחבי פס די משמעותיים (20-50 מגהביט), במיוחד עם פתרונות תקשורת כמו Teradici אם מעוניינים לקבל צבעים מדוייקים לקולוריסטים – ולפחות ממה שידוע לי, לפעמים אפשר לקבל תקשורת מהירה כזו ולפעמים .. לא (מהצד של ה-DSL). את זה בכל מקרה אני חושב לבדוק בקרוב.

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

מעבדי Cooper Lake של אינטל (Xeon SP דור 3)

אינטל הציגה לאחרונה את מעבדי ה-Xeon SP דור 3. סביר להניח שאם אתם לא ממש בודקים חדשות לגבי מעבדים, לא ממש שמעתם הרבה דברים על כך, והסיבה לכך היא שהפעם אינטל החליטה לחלק את ההכרזה ל-2: מעבדים לשרתים בעלי 4 ו-8 מעבדים (שם קוד: Cooper Lake) עכשיו, ומעבדים לשרתים 1-2 מעבדים – שנה הבאה כנראה (שם קוד: Ice Lake). זו, אגב, הסיבה שרוב הגולשים כאן לא ממש שמעו מנציגי שיווק של יצרני השרתים, מכיוון שהיצרנים כמעט ולא הוציאו שרתים חדשים עם המעבדים החדשים, דגש על כמעט – כל היצרנים הגדולים הוציאו 1-2 דגמים עם תמיכה ברוב המקרים ל-4 מעבדים ותו לא (שרתים כאלו עם 8 מעבדים – הם מאוד פופולריים בסין, לא בשאר העולם).

מבחינת שינויים ושיפורים במעבדים החדשים – אין הרבה, ומה שיש, די מאכזב:

  • "פי 2 ביצועים" – כן, כשמשווים את המעבדים החדשים למעבדים מלפני 5 שנים, וגם אז – רק ב-workloads מסוימים בלבד.
  • bfloat, VNNI – אינטל מנסה שוב ושוב להיכנס לתום ה-Machine/Deep Learning/AI ומכניסה תמיכה במתודות נוספות לתמיכה בתחומים הנ"ל. הבעיה המרכזית: לקוחות רצו/רוצים/ירצו לעשות זאת דרך ה-GPU כי זה זמין (לא צריך לרכוש שרת שלם, אפשר פשוט לרכוש כרטיס), קל לשדרג (שוב, אפשר להחליף כרטיס, לא צריך להחליף שרת שלם) ויותר זול.
  • תמיכה בזכרון – אינטל סוף סוף החליטו להעלות את מהירות הזכרון הנתמך ל-3200 מגהרץ, שנה אחרי ש-AMD עשו זאת. מצד שני, כל מעבד תומך מקסימום 256 ג'יגהבייט זכרון, או איך אומרים בקומדיה "היהודים באים" – "איזה עולב".
  • תמיכה ב-Optane Persistent Memory 200. עוד משהו שלא ממש הולך איתו חזק לאינטל, אבל היי, סיבוב שלישי, אולי יצליח הפעם?

חלק מההכרזה יועד ל-SSD החדשים של אינטל, ה-D7-P5500, P5600. אלו באמת דיסקים SSD מעולים, עם בעיה קטנטנה שלא קשורה טכנית ל-SSD עצמו: בשביל לקבל ביצועים טובים, תצטרך שרתים עם … מעבדי EPYC של AMD, מכיוון שאינטל עדיין לא שחררה שום chipset שתומך ב-PCIe דור רביעי, ואותם SSD דווקא צריכים זאת כדי לתת את הביצועים המיטביים.

אחת ההפתעות לעיתונאים ולאלו שצפו בהכרזה (וקיבלו מידע מוקדם) – היתה שאינטל לא הכריזה על מעבדים חדשים עם 56 ליבות (אלו בעצם מארזים שמודבקים בהם 2 מעבדים עם 28 ליבות. מה שאינטל גיכחה על AMD – בסוף הם בעצמם עשו). ההערכה היא שאינטל בכל זאת תכריז על כך בשנה הבאה, כשהיא תכריז על Xeon SP דור 3-חלק-ב' (שם קוד: Ice Lake).

לסיכום: אני לא ממש מצליח להבין את אינטל. עם כל המשאבים שיש לחברה, עם כל מאגר המוחות העצום שעובד בחברה – זה הדור השלישי של Xeon SP שהחברה מצליחה להוציא? זה הכל? אם מעבדי ה-Ice Lake יהיו ללא תכונות חדשות, יותר ממה שאינטל מציעים ב-Cooper Lake, אני אתקשה להבין מדוע חברות ירצו לרכוש שרתים עם מעבדים כאלו, ובמקרה כזה עדיף יהיה כבר לרכוש את השרתים עם המעבדים הנוכחיים – Xeon SP דור שני או מעבדי AMD EPYC.

גישות SaaS/PaaS והגישה ההיברידית

כמעט בכל חברה יתקיים מצב בו החברה תחפש תוכנה שתבצע שרות X או שתתן שרותי פלטפורמה Y במקום "להמציא את הגלגל" מחדש בכל פעם. אם לדוגמא העסק מעוניין לשלוח איחולי חג שמח לכל הלקוחות, ניתן יכול לשכור שרותי Saas של חברה כמו Mailchimp לדוגמא ובתמורה תקבלו ממשק קל לשימוש וסיכוי מאוד גדול שכל לקוחות העסק יקבלו את המייל. מצד שני אפשר בעזרת מעט סקריפטולוגיה ושימוש באמזון SES לבצע את אותו דבר אך במחיר זול בהרבה (יכול לחסוך לא מעט אם לחברה יש מאות אלפי או מיליוני לקוחות לדוגמא). אפשר כמובן לקחת גם את האופציה החינמית ולהקים שרת מייל או להשתמש בשרת מייל מקומי כדי לשלוח את הררי האימיילים, אבל במקרים כאלו הסיכוי שהמייל יתקבל אצל כל הלקוחות הוא די קלוש – אם לא משקיעים בכל עניין של Whitelist, RBL, דבר שלוקח לא מעט זמן ומשאבים.

יותר ויותר חברות תוכנה מקצצות בהשקעה של כתיבת תוכנות והפצת כ-Stand alone המיועדות לרוץ על שרתים בתשתית מקומית של הלקוח, וזאת ממספר סיבות, הנה 2 העיקריות:

  1. עלויות תמיכה – ככל שתוכנה נמכרת כ-Stand Alone, עלות התמיכה ליצרן התוכנה תהיה גבוהה, מכיוון שיש לא מעט סיכוי שהתוכנה לא תעבוד בסביבות או מכונות שונות, הרשאות שגויות, חוסר ידע טכני של הלקוח ועוד. ככל שהתומכים הטכניים יהיו עסוקים יותר ויותר שעות בפתרון בעיות של לקוח ספציפי זה או אחר, הרווח של יצרן התוכנה ירד. אחרי הכל, אף אחד לא משלם ליצרן התוכנה אם מחלקת התמיכה השקיעה 10 שעות בפתרון בעיה אצל לקוח יחיד לדוגמא.
  2. פיראטיות – בהרבה מאוד חברות הצוות מוריד אפליקציה או פלטפורמות מסויימות למטרת Trial ומיד לאחר מכן הם מחפשים כל מיני כלים ודרכים כדי לפרוץ את ה-Trial. הרווח של יצרן התוכנה ממקרים כאלו – אפס.

מהרגע שיצרן התוכנה מציע את מוצריו כ-PaaS או SaaS, הדברים נהיים יותר קלים עבורו:

  1. אין פיראטיות
  2. עלויות התמיכה מצטמצמות משמעותית הואיל והכל רץ בתשתית וירטואלית של יצרן התוכנה בעננים שונים ומקרי התמיכה נהיים יותר ויותר פשוטים כי ניתן לשחזר את התקלות במחלקת התמיכה של יצרן התוכנה.
  3. תזרים הכנסות חודשי/שנתי רציף מהלקוחות.
  4. קצב הפיתוח מואץ יותר, באגים ופונקציונאליות חדשה נכנסת ל-Life Cycle של השרות במהירות גבוהה יותר ובכך דרישות לדברים חדשים שלקוחות מבקשים – נענים במהירות גבוהה יותר.
  5. אין צורך בתמיכת Legacy הואיל וכולם עובדים על גירסה אחת או שתי גרסאות.

אך יש גם חסרונות:

  1. עלויות תשתית הרבה יותר גבוהות בענן ציבורי. בניגוד למכירת תוכנת Stand Alone שלא מתחברת החוצה, כאן פתרון ה-Saas/PaaS יצטרך חיבור קבוע למשאבים שונים של יצרן התוכנה.
  2. אבטחת המידע צריכה להיות הרבה יותר רצינית בהשוואה למקרים של תשתית סגורה החוצה. מהרגע שמתגלה אצל יצרן כזה דליפת מידע, יש סיכוי לא רע שחלק מהלקוחות יעדיפו לנטוש ולחפש פתרון מתחרה.

אלו, פחות או יותר הסיבות שבגללן חברות תוכנה יעדיפו להציע שרותי PaaS/SaaS.

אחת הנקודות שבמקרים רבים אינני רואה התייחסות מצד אותן חברות – היא למקרים שהלקוח אינו מוכן "לעבור All In", כלומר הלקוח לא מוכן שכל ה-DATA שלו ישב בתשתית של יצרנית תוכנה ולו (ללקוח) לא תהיה שליטה על הנתונים מבחינת אבטחת מידע או בכלל מהבחינה העקרונית שזה ישב בתשתית של חברה אחרת שאין לו מושג ירוק לגביה. זו לדוגמא אחת הסיבות שחברות יעדיפו לוותר על פתרון SaaS/PaaS שמוצע רק על ענן ובמקומו הם יעדיפו פתרון שרץ מההתחלה ועד הסוף על תשתית מקומית (On Prem).

מה שלעניות דעתי אותן יצרניות תוכנה PaaS/SaaS צריכות להציע – הן את האפשרויות הבאות (אחת או יותר), משהו שהוא יותר מעין "Hybrid":

  1. ה-DATA של הלקוח יכול להיות מאוחסן On Prem עם Agent שמתחבר לענן. לשרות תהיה גישה עם הרשאות מאוד מוגבלות
  2. אם ללקוח יש חשבון בענן ציבורי כלשהו, הלקוח יוכל להגדיר אחסון אובייקטים כלשהו (S3 לדוגמא) עם הרשאות מוגבלות שינתנו בעת הפעלה ראשונית של שרות ה-SaaS/PaaS והרשאות אלו יהיו תחומים למשאבים מסויימים בלבד (נניח Bucket כלשהו)
  3. הלקוח יצטרך לבחור כבר בהתחלת שימוש ה-PaaS/SaaS את ה-Passphrase שלו (ובלבד שיהיה מורכב) ועם אותו Passphrase (ואולי יחד עם עוד מספר נתונים) יוצפן ה-DATA של הלקוח כך שגם ליצרן התוכנה לא תהיה גישה לנתונים. (אפשר כמובן במקום Passphrase יהיה אפשר להשתמש במפתחות פרטי/ציבורי יחד עם Passphrase)

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