הטעות הגדולה של רד-האט

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

השינוי עצמו, אגב, אינו חל על גירסת ה-Upstream (מה שיהיה בעצם גירסת ה-RHEL החדשה בעתד), אך זה כמובן לא מסייע למי שיש מערכות RHEL או מבוססות חיקויי/fork של RHEL.

על מנת להבין מדוע השינוי הוא כה קריטי, צריך לזכור משהו אחד חשוב: רד-האט נחשבת הפצה יציבה ואיכותית, והיא משמשת אצל ארגונים רבים כ-Gold Standard (הרבה יותר מאשר כל הפצה אחרת, כולל אובונטו או סוזה). מכיוון ש-רד-האט שחררו את הקוד והשינויים המתמשכים לציבור, קמו להן מספר קהילות שהוציאו הפצות "תואמות RHEL" כמו Rocky Linux, AlmaLinux וכמובן – Oracle Linux שעמדו בתנאים של רד-האט (אפשר להשתמש בקוד, כל עוד השם Red Hat או לוגו או כל סימן רשום של רד-האט אינו נכלל) והן בנו את ההפצה מחדש, כאשר ישנה 100% תאימות בינארית ל-RHEL.

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

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

מה שאי אפשר להבין, מדוע הצעד ננקט בצורה כזו הזויה?

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

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

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

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

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

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

שימוש ב-Wireguard כפתרון VPN מלא

יש לא מעט מקרים בהם VPN הוא דבר חיוני ונדרש, בין אם בחיבור בין 2 אתרים (Site to site), בין אם חיבור חיצוני לתשתית בענן ציבורי, בין אם חיבור מהבית לתשתית בעבודה וכמובן – כשרוצים להתחבר לתשתית בבית כדי לבדוק דברים או כדי להשתמש בשרותים שונים שרצים בבית – מבחוץ.

עד כה הפתרונות המוכרים ורצים במקומות שונים, היו פתרונות כמו IPsec, או OpenVPN או פתרונות קנייניים של יצרנים שונים (גם יצרני נתבים ביתיים כמו ASUS הוציאו פתרונות VPN כמו Instant Guard … שלא נתמך ב-Windows , Mac או לינוקס אלא רק למובייל) שעובדים בצורה מעולה. הבעיה בדרך כלל כשמדובר על גוף עם תקציב קטן (או ברצון לא להוציא כסף) – הפתרונות הנ"ל לא היו יכולים לבוא בחשבון, ומה שכן בא בחשבון סבל ממגבלות של רישוי (OpenVPN – מקסימום 2 משתמשים), ניצול גרוע של רוחב פס (במיוחד כשמתחברים לתשתית ביתית או upload בכמות מגהביט מזערית) והבעיה הגדולה מכולן – חוסר עדכונים לפתרונות הללו. בנוסף, פתרונות רבים מבוססי נתבים ביתיים מקבלים כמות קטנה מאוד של עדכוני תוכנה, כך שפתרון VPN מבוסס נתבים כאלו יכול להיות פתרון די מסוכן.

הפתרון שמקבל תאוצה בשנים האחרונות מגיע מכיוון אחר, מעולם הלינוקס, והוא פתרון ה-Wireguard. למי שלא מכיר, Wireguard מממש פתרון VPN, אולם הוא עושה זאת תוך שימוש בצופנים מודרניים שאינם "חונקי מעבד" ולא מצריכים פתרונות חומרה במעבדים. כך לדוגמא, Wireguard שרץ על Raspberry Pi 4 ויכול לתת תעבורה מוצפנת במהירות של 400 מגהביט, מספר הרבה יותר גבוה מ-OpenVPN (שנותן רבע או שליש מזה) ובחלק מהמקרים הוא עוקף פתרונות IPSec שונים מבחינת ביצועים ורוחב פס.

ל-Wireguard יש מספר יתרונות גדולים:

  1. ההגדרות עצמן די קלות, ולמי שמסתבך, יש כלי שנקרא PiVPN (שגם רץ על דביאן ואובונטו על מכונות X86-64) שעוזר להגדיר את ה"שרת" ואת ה-Clients בקלות.
  2. אין צורך בהגדרות משתמשים וסיסמאות. שרת ה-VPN צריך בסך הכל את המפתח הציבורי של ה-Client וה-Client צריך את המפתח הציבורי של השרת. השאר – הם הגדרות כתובת IP, DNS ומספר דברים נוספים לא ממש מורכבים.
  3. מבחינת שינויים בנתב – השינוי היחיד שצריך לבצע הוא הגדרת Port forward ב-UDP אל המכונה שמריצה את ה-Wireguard כשרת. אפילו הנתבים של בזק יכולים לתת זאת בלי בעיה. (הערה: בימים האחרונים פרסמתי כי יש לי בעיה בנתבים מסויימים עם הגדרות ל-Wireguard, מסתבר כי זו היתה בעיית הגדרה של firewalld במכונה)
  4. אתה יכול לנצל את מלוא רוחב הפס Upload שיש לך להנאתך. במקרים של חיבורים כמו DSL או כבלים, רוחב ה-Upload הוא מספר נמוך מאוד של Megabits (בד"כ עד 5) ופתרונות VPN מתחרים יוציאו מתוך זה אולי 1-2 מגהביט. עם Wireguard לפי נסיון שערכתי – מתוך 4 מגהביט Upload, קיבלתי רוחב פס של כ-3.5 מגהביט מוצפן החוצה (Upload).
  5. מבחינת Clients – כל מערכת הפעלה תומכת ב-Wireguard – כל הפצות הלינוקס, אנדרואיד, iOS, מק, Windows, כולל Tizen (אם יש לך את ה-SDK ואתה רשום כמפתח..).
  6. הגדרות Client די קלות במובייל – צור Tunnel, צלם תמונה (עקוב אחר ההוראות של PiVPN), שמור. נגמר. ההגדרות גם קלות ב-Windows ומק – העבר קובץ conf שיצרת עבור ה-client למערכת ההפעלה הנבחרת, הפעל Wireguard client, בצע יבוא (Import tunnel) והפעל.
  7. הקץ להעברת כל התעבורה דרך VPN – הגדרת AllowedIPs תאפשר להגדיל ניתוב VPN רק לתשתית מסויימת (Split DNS), וכל השאר יעבור בצורה רגילה דרך האינטרנט. הקץ לגלישה שעושה "טיול" בחו"ל – לאתרים מקומיים.
  8. כשמדברים על מערכות עם עדכוני אבטחה, כל הפצת לינוקס שתתקין (למעט Fedora) תגיע עם הבטחת עדכונים ל-5 שנים לפחות (גרסאות כמו Rocky/Alma/Oracle לינוקס – ל-10 שנים)

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

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

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

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

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

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

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

מיקרוסופט SQL ללינוקס – ההמשך

לפני כשנה כתבתי את הפוסט הזה לגבי Microsoft SQL 2017 גירסת לינוקס שמיקרוסופט הוציאה. מיקרוסופט הסבה את המוצר ללינוקס מכמה סיבות:

  • לכבוש נתח שוק מאורקל
  • לנסות לחדור לכל מיני שווקים שמשתמשים רק בלינוקס

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

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

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

בגירסה החדשה ללינוקס, מיקרוסופט הוסיפה חלקים שלא היו קיימים ב-SQL 2017 ולראשונה יש תמיכה לא רק להרצה בתוך Docker אלא בתוך Kubernetes (אפשר לראות מה חדש כאן) וסוף סוף יש גם רפליקציה טבעית, תמיכה ל-PV/PVC (כלומר Persistent Volumes). הדוגמאות שמיקרוסופט נותנת בתיעוד קשורות אמנם ל-Azure אבל אני מאמין שזה ירוץ גם על Kubernetes מקומי ובשרותים של ספקי ענן ציבוריים מתחרים.

הבעיה היחידה שאני רואה קשורה יותר לתמחור. SQL בסביבה רגילה במצב שרידותי עובד ב-2 שרתים, הן Active/Passive או Active/Active וזה עובד יפה, אך ב-Kubernetes הדברים שונים לחלוטין, אין Active/Passive ודברים כאלו, יש רפליקציות של Pods וקונטיינרים לפי הגדרות שמחליטים, לדוגמא: אם משאבי זכרון/מעבד מגיעים ל-90% – תרים Pod נוסף עם הקונטיינרים הרלוונטיים, בצע Load Balance (תלוי בשכבת הרשת שהוגדרה ל-Kubernetes) בין ה-Pods שמריצים את ה-SQL. מה המחיר שמיקרוסופט תגבה על כל SQL כזה? אי אפשר לגבות מחיר בשיטה הישנה של Cluster.

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

כמה מילים על WSL 2

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

מיקרוסופט בשנים האחרונות ביצעה כמה שינויים על מנת לכלול תאימות למערכות אחרות. כך לדוגמא ה-command prompt הישן קיבל מתיחת פנים הן ב-Power Shell ומאוחר יותר גם בתאימות להצגת טרמינלים מרחוק (בחיבור SSH או Telnet). זה לא היה מושלם – אבל זה היה צעד חשוב, במיוחד כשמיקרוסופט החלו לשלב גם SSH Client בתוך Windows 10 לגרסאותיו השונות.

בכנס Build האחרון מיקרוסופט הציגה את ה-Windows Terminal שלה – שיפור משמעותי לעומת ה-CMD הישן והקונסולה של PowerShell. הפעם יש טאבים, תמיכה ב-Emoji, קאסטומיזציה ועוד ועוד. בקצרה זה נראה כך:

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

מכאן נעבור לנושא הפוסט: WSL 2.

למי שאינו מכיר, WSL (ראשי תיבות Windows Subsystem for Linux) זו מערכת שמיקרוסופט פיתחה שמשתלבת עם ה-NT Kernel (כן, Windows 10 מבוסס על NT, כמו רוב גרסאות ה-Windows בשנות ה-2000). המערכת הזו משמשת כ"מתרגם" מה-API של ה-Linux Kernel (גירסה 4.4 של ה-Linux Kernel) ל-NT API. בנוסף, המערכת גם דאגה להרשאות מיוחדות של קבצים ותיקיות כך שלא היה צורך ליצור Partition של לינוקס מצד אחד, ומצד שני קבצים בינאריים של לינוקס לא יכלו לרוץ על Windows שלא מותקנת בה WSL. כל הקונסטרוקציה הזו נועדה לתת מספר דברים:

  • לאפשר לבנות הפצות לינוקס ידועות שירוצו ישירות עם ה-WSL ללא צורך במערכת לינוקס ב-VM
  • לאפשר להריץ אפליקציות לינוקס בהתאם להעדפות שלכם.
  • אין צורך בלשלב קוד GPL כמו ה-Kernel לתוך המערכת.

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

מיקרוסופט היו בהחלט מודעים לעניין, והם הבינו שהטריקים של המרה ל-NT-API לא ממש יעזרו. דרוש פתרון אחר ועדיף פתרון "טבעי".

התוצאה: WSL 2.

השינוי המהותי עם WSL 2 שהפעם יש מעין "מיני VM" קטן שעושה Boot ומטעין גירסה מאוד מקוצרת של ה-Kernel, אך ללא ה-1001 דרייברים שמגיעים עם ה-Linux Kernel וכל הדרייברים הנחוצים שלינוקס צריך – הוא מקבל אותם דרך דרייברים Paravirtualized (קצת מזכיר את ה-VMWare Tools שמתקינים). כך, מצד אחד ה-Kernel רץ בצורה מבודדת כ-VM קטנטן, ומצד שני מיקרוסופט לא צריכה להסתבך עם ה-GPL: הם ישחררו את שינויי הקוד שהם צריכים לשחרר ואין נגיעה ישירה לקוד של Windows.

בשיטה הזו, ה-WSL 2 מקבל מספר דברים:

  • אפשרות להשתמש בגירסת Kernel מודרנית (אני מאמין שמיקרוסופט תוציא מסמך איך לקמפל קרנלים משלך לשימוש ב-WSL 2)
  • אפשר להשתמש בדברים כמו cgroups, להריץ קונטיינרים (docker, cri-o וכו')
  • כל גישת ה-File/Directory תעבור דרך דרייבר שמיקרוסופט תשחרר ש"ידבר" עם NTFS, ומיקרוסופט טוענים כי בדיקות שלהם מראות כי הביצועים משתפרים פי 20 בהשוואה ל-WSL 1.
  • יותר אפליקציות יוכלו לרוץ.

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

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

עדכון מערכות לינוקס ו-Windows ממקום אחד

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

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

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

האם יש פתרון טוב לכך?

כן, ל-SuSE יש פתרון: SuSE Manager

תוכנת SuSE Manager מאפשרת מספר דברים:

  • לעדכן הפצות לינוקס חופשיות (CentOS, Scientific Linux, OpenSuSE, Fedora, Ubuntu)
  • לעדכן הפצות לינוקס מסחריות (Red Hat, Oracle Linux, SuSE SLE)
  • להתממשק ל-SCOM כך שניתן יהיה לעדכן את הפצות הלינוקס ישירות דרך ה-SCOM
  • לנטר את כל המערכות המבוססות לינוקס.
  • לבצע Provision ולהתקין לינוקס על מכונות פיזיות ווירטואליות (בשימוש AutoYast/Kickstart)
  • ועוד

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

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

ומה עם אלו שמעוניינים במשהו חופשי?

SuSE Manager ו-Red Hat Satellite מבוססות על תוכנה בשם Spacewalk, כאשר SuSE ו-רד-האט מוסיפים הרחבות משלהם, כך ש-Spacewalk לדוגמא לא מתממשק ל-SCOM ולא יאפשר עדכון מרוכז של מכונות לינוקס ו-Windows כך שניתן לעדכן רק מכונות לינוקס.

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

על בנייה ואבטחת מערכות משובצות

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

עם כניסת ה-Raspberry Pi ושלל החיקויים שלו, יותר ויותר אנשים החלו לגלות את עולם ה-SBC (כלומר Single Board Computer – לוח אחד שעליו נמצא הכל, כולל מעבד, זכרון, אחסון ושלל חיבורים לעולם החיצון) ושוק המערכות המשובצות החל לקבל "ניעור" רציני. חברות המייצרות פתרונות הכוללות מערכות משובצות ראו שניתן לרכוש בכמה עשרות דולרים מערכות SBC ל-Embedded, מה שגרם למתחרים הותיקים להוריד מחירים. למי שאינו מכיר – הכרטיסון בתמונה הוא מחשב Raspberry Pi Zero שכולל כל מה שצריך (למעט חיבור רשת קווית שאפשר להוסיף במספר דרכים). העלות? 5 דולר, וזו סתם דוגמא ל-SBC זול שיכול לבצע פרויקטים שונים.

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

  • עצמאית או C/S? אחד הדברים הראשונים החשובים הוא להחליט איך המערכת תרוץ בעצם. האם מדובר במערכת עצמאית שאין לה תקשורת לשום שרת (עצמאית) או C/S (כלומר Client Server)? אם מדובר במערכת עצמאית, אז נצטרך להתקין עליה את כל האפליקציות (תיכף ארחיב על כך), ולדאוג לכך שהיא תפעל כמעט בכל מצב אפשרי, כולל מצב חרום שבו היא יכולה להציג למפעיל אם יש תקלה, מה התקלה ומה קוד התקלה כדי שיצרן הפתרון יוכל לטפל בכך.
    אם מדובר ב-C/S לעומת זאת, אז יהיה כדאי לבנות מערכת כמה שיותר רזה (לא להתקין הפצת לינוקס על המערכת אלא להשתמש ב-Yocto לדוגמא) וכל אפליקציה נחוצה תרוץ על השרת וביניהם התקשורת תעבור ב-TCP/IP, שימוש ב-Web Sockets וכו'.
    אם מדובר במערכת שיש לה תקשורת לשרת אך התקשורת אינה קבועה (אחת לשעה, אחת ליום וכו') אז כדאי יהיה לבנות אותה למצב אחסון זמני כך שברגע שהתקשורת מבוצעת, כל הנתונים מועברים לשרת, מתבצעת בדיקה שהנתונים נשמרו על השרת באופן תקני (אפשר להשתמש במגוון שיטות checksum) ולאחר מכן הנתונים ימחקו מהמערכת המשובצת. מבחינת אפליקציות להתקנה, נצטרך למצוא מה ניתן עדיין להריץ על השרת הרחוק ומה צריך לרוץ מקומית.
  • לא לדסקטופ: יש לא מעט מפתחי מערכות משובצות, שברגע שהם מקבלים מערכת משובצת עם 4 ליבות, 1-4 ג'יגהבייט זכרון ו-64 ג'יגה אחסון eMMC – בונים מערכת כאילו זה לינוקס דסקטופ. זה לא רעיון טוב הואיל וכל מעבד PC פשוט עוקף בסיבוב כל מעבד של מערכת משובצת. בנוסף, מערכות משובצות בקושי מקבלות עדכונים אם בכלל כך שיש סיכוי לא קטן שמערכת כזו בסופו של דבר תיפרץ ומכיוון שמערכות כאלו לא מעודכנות כמעט, הפורץ יכול להיכנס ולהשתמש ברשת הפנימית ובמערכת המשובצת כפי שירצה.
  • דיאטה: מערכת צריכה להיות כמה שיותר קטנה על מנת להקטין את וקטור התקיפה ולאפשר תחזוקה (אם צריך) קלה, ולכן לא מומלץ להתקין עליה מערכות אפליקציות שרת רגילות. צריכים לדוגמא SQL? תכירו את SQLite. צריכים שרת HTTP? יש מספר אפשרויות שמתאימות למערכות משובצות או httpd שמגיע כחלק מ-BusyBox או שימוש בשרת Web מובנה שקיים בפייתון/GO.
  • שפות כתיבת קוד: אם הפתרון הולך לרוץ כ-C/S, אז אתם יכולים לכתוב באיזו שפה שבא לכם ולהריץ את הקוד על השרת. אם זו מערכת עצמאית, אז אני ממליץ לכתוב בפייתון, Go או PERL (לוותיקים שביניכם) וסקריפטים ניתן ב-Bash או Python. יהיו כמובן חברות שירצו לכתוב קוד ב-JAVA או DOT NET (אפשר להריץ Dot Net Core על לינוקס), אבל חשוב לזכור שאם המערכת מבוססת על ARM ותרוץ עצמאית, אפליקציות כמו Wildfly או runtime של Dot Net Core לוקחות לא מעט משאבים ובלא מעט מקרים גורמות למערכת להגיב בצורה איטית.
    חשוב: לא לכתוב קוד אסמבלר יעודי למעבד. נכון, קוד אסמבלר זה נחמד ונותן מהירות (היום זה פחות רלוונטי, GCC מוציא קוד אסמבלי מעולה!) אבל פעם הבאה שהחברה תחליט להחליף מעבד, מישהו יצטרך לשכתב המון קוד אסמבלר מחדש ולכן אני ממליץ לא להיכנס לביצה הזו.
  • רדו מ-Windows: אתם בוודאי נתקלתם בזה בעבר – כספומטים שמגיבים באיטיות, מערכות מידע שלא מגיבות או שפשוט תקועות, קופות רושמות שנתקעות באמצע העברת מוצרים אצל הקופאית ועוד ועוד. מדוע ישנם הרבה פתרונות מבוססי Windows? כי מיקרוסופט מספרת כמה ה-Windows (כולל גירסת ה-Embedded) "יציבה", חברות גדולות עד לפני מס' שנים כתבו קוד שרץ רק על Windows, בנו "פתרון" שמורכב על PC פשוט והרי לכם מערכת שגם עם מיטב המומחים עדיין מצליחה להיות בלתי יציבה ואיטית פתאום.
    כיום ניתן לבנות מערכת משובצת מבוססת לינוקס שלא תתפוס יותר מ-80 מגהבייט אחסון (בערך) ותרוץ יפה על 1 ג'יגהבייט זכרון והמערכת תכלול דפדפן ותמיכה במסך מגע וכל המערכת תעלה מרגע החיבור לחשמל תוך 8-12 שניות עם הצגת לוגו לקוח בשניה הראשונה ולאחר 10-12 שניות הלקוח האנושי יכול להשתמש במערכת בתוך דפדפן סגור (כך שניתן להציג גרפיקה, OpenGL, אנימציה וכו' וגם לחבר את המערכת לציודים אחרים אם צריך).
    מדוע לא עוברים למערכת כזו? בחלק מהמקרים יהיה צורך לכתוב קוד חדש (במקרים כמו קופות), בחלק מהמקרים מדובר בחששות לא מבוססים, ובחלק מהמקרים עקב אי ידיעה או אי הכרת הדברים. אני מקווה בקרוב לקבל כמה מערכות משובצות, לבנות כמה מערכות דמה ולהוציא קליפים להדגמה ביוטיוב..
  • אבטחת מידע: זוכרים שאמרתי שלא כדאי להתקין הפצת לינוקס על מערכת משובצת? זה אחד הדברים הראשונים שפורץ ינסה להשתמש לטובתו, ולכן מומלץ לעבוד עם Busy Box סופר מצומצם במכונה שיכלול אך ורק פקודות הכרחיות, לצמצם הרשאות, לא להריץ הכל כ-root, ואם אפשר – לעבוד עם מפתחות והצפנה, בשביל זה כמעט כל מערכת משובצת מכילה רכיב TPM (לחובבי Raspberry Pi – יש חלק שניתן לרכוש, להרכיב ולהשתמש מבלי להלחים חוטים). אם המכשיר הולך להיבנות בסין, קחו בחשבון שינסו לגנוב לכם את הקוד ולכן הצפנה היא מאוד חשובה.
  • פשוט זה חכםתכירו את אחד החתולים הביתיים שלי – זהו נימי. מדוע אני מציג אותו? כי רמת המשכל של נימי שווה בערך לרמת המשכל של חלק מהאנשים בסין שיבנו ויקימו את המערכת ללקוח ובחלק מהמקרים – זו גם תהיה רמת המשכל של אלו שישתמשו במערכת (כבר ראיתי מישהו שמנסה להכניס בכח את כרטיס האשראי שלו לחור ממנו יוצאת הפתקית בכספומט!).
    לכן – אם המערכת שלכם כוללת אחסון (eMMC, SSD, לא מומלץ דיסק קשיח מכני, SSD הרבה יותר אמין) ואתם צריכים להקים Installer שירוץ על PC ויתקין את המערכת שלכם על הלוח SBC, תשתמשו בכמה שיותר אוטומציה ותנסו לצפות ולפתור כל תקלה אפשרית. אם המערכת נמסרה וישנה תקלה במערכת, תעלו אותה מחדש אוטומטית כך שברגע שהמשתמש יכנס דרך הדפדפן, התקלה תוצג והלקוח יוכל לשלוח לכם צילום מסך שלה.
    חשוב לנסות (אם התקציב מאפשר) לבנות מערכת Dual Boot (מערכת u-boot תומכת בכך) כך שניתן יהיה לשדרג מרחוק את המערכת עם Image תקין, ואפשר להשתמש בגירסת SystemD האחרונה כדי לעלות למערכת חרום אם המערכת הנוכחית לא עולה (אפשר לקרוא על כך כאן).
  • דלת אחורית/כניסה מרחוק: לא תמיד אתם יודעים היכן המערכת תרוץ ואתם לא יודעים מתי ומאיפה תקבלו בקשת תמיכה, ולכן חשוב לבנות זאת כחלק מהמערכת. אל תצפו ממשתמש קצה להקיש פקודות או שתקבלו בלא מעט מקרים – תוצאות מביכות.

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

מערכות משובצות ומצבי "קיוסק"

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

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

  • עדכוני אבטחה – קשה להתקין עדכוני אבטחה ל-Windows כשאין לך תקשורת חיצונית, ומה לעשות ש-Windows דורש המון עדכוני אבטחה.
  • מחיר רשיון – 150-200$ לרשיון Windows Pro (מחיר שונה ל-Windows Embedded אבל כיום המוצר מאבד פופולריות במהירות לטובת פתרונות מבוססי Linux).
  • קבלת Latency נמוך – לא חשוב כמה תכוונן את Windows, תמיד יהיו "קפיצות" שישבשו את ה-Latency.

לכן הרוב עוברים למערכות מבוססות ARM.

לוחות מבוססי מעבדי ARM כדוגמת I.MX6/7/8 ומעבדים אחרים קיימים בשוק זמן רב ובשנים האחרונות המחירים צונחים (בעיקר עקב פופולריות של Raspberry Pi). מחשב קטן שרק לפני כמה שנים היה עולה מאות דולרים, צנח למחירים שכיום נמדדים בעשרות דולרים (כולל אחסון קבוע כמו eMMC). פאנלים ללוחות כאלו קל לחבר (דרך LVDS לדוגמא) והתוספת ל-Touch היא דולרים בודדים, ולכן יש רצון מצד חברות שונות לבנות פתרונות שאותם הם משלבים במוצריהם – הכוללים מעבדי ARM, עם צג מגע וחוויית משתמש טובה. יש אפילו חברה מסויימת שמייצרת Appliance בגודל 1U .. .עם מסך מגע נשלף. לאן הגענו….

לקוח כזה בסופו של דבר צריך לבנות Image שיוכנס ב-eMMC של הלוח. ה-Image אמור לכלול את כל חלקי התוכנה ויש מספר אפשרויות:

  • לינוקס "רגיל" – אפשרות אחת היא לקחת הפצת לינוקס רגילה (Debian, CentOS וכו') עם Kernel שמגיע מיצרן (או שהאינטגרטור מקמפל תוך שימוש ב-BSP, Cross compiler וכו') ופשוט מקימים לינוקס עם התקנת התוכנות הנדרשות (בשימוש yum/apt) וההגדרות הכרוכות בכך, ולבסוף מכינים Image. יש כלים כמו kickstart (ל-CentOS) או Preseed (ל-Debian) כדי להכין Image כזה.
    הבעיה בשיטה זו היא שיש צורך בידע רציני להגדיר את הסביבה הגרפית (Xorg, Wayland, שימוש ב-OpenGL וכו') מכיוון שאין אוטומציה שניתן להשאיל מ-X86 ויש צורך להשקיע מאמצים מרובים להגדיר את הכל.
    חסרון נוסף: אבטחה. במקרים רבים החבילות המגיעות עם תלויות שאין בהן צורך עבור אותה מערכת משובצת ולכן יש לקמפל את החבילות מחדש ללא אותן תלויות או במקרה היותר קשה – לבטל/להחליף תלויות באחרות. חבילות מיותרות ופונקציונאליות שאינה דרושה, גם אם אינן מופעלות יכולות פוטנציאלית לגרום לחורי אבטחה במערכת.
  • Yocto – אחד הכלים הכי פופולריים. עם Yocto אפשר ליצור Image מצומצם לדברים שאנו צריכים בלבד. מערכת Yocto בונה לנו את כל המערכת ולבסוף מכינה Image שניתן "לזרוק" על כרטיס מיקרו SD או על eMMC. המערכת מספיק חכמה בשביל לא לקמפל חבילות שכבר קומפלו ולא היה בהן שינויים, וכל יצרן לוחות ARM תומך בה.
    החסרון עם Yocto: בלא מעט מקרים תצטרך לדעת איך לבנות Recipe כדי להוסיף את החבילה שאתה רוצה ועם אלו ספריות ו-Compile Flags לעיתים. בנוסף – תצטרך להוסיף את ההגדרות לכל חבילה שתרצה בתוך ה-Yocto. בכל הקשור לגרפיקה – גם כאן, תצטרך לשבור את הראש איך להגדיר את הדברים.
  • Boot2QT – זהו מוצר של חברת TrollTech שמשתמש ב-Yocto כדי לבנות מערכת גרפית מוכנה. לא תצטרך לשבור את הראש על Touch, על הגדרות Frame Buffer או Xorg ופרמטרים אחרים. מוצר הדגל של החברה (QT Creator) נותן לך לכתוב אפליקציות גרפיות ולנסות אותן על מחשבך או ישירות על המערכת המשובצת (מבלי להכין כל פעם Image מחדש כדי לנסות את הקוד שכתבת). המערכת קטנה ועולה תוך שניות ספורות. היא גם הופכת את החיים להרבה יותר קלים מבחינת שימוש ב-Yocto והיא מסתירה לא מעט חלקים מורכבים ומטפלת בקומפילציה.
    החסרון: זו מערכת מסחרית. ישנה גירסה חופשית אך אם תשתמש בה, תצטרך לשחרר את כל הקוד שכתבת באפליקציה הגרפית.
  • Android – עוד פתרון שחברת "אגד" לדוגמא – שמחה לאמץ אותו לנהגים כמערכת קופה/כרטוס. כל יצרן מערכת ARM בדרך כלל משחרר גירסת אנדרואיד ולחברה שרוצה להשתמש בכך, ניתן לקחת את גירסת האנדרואיד ולהוריד חלקים שאין צורך בהם, ואם צריך לכתוב אפליקציות יעודיות, לא חסרים מפתחי אנדרואיד (וכן, יש גם מצב קיוסק באנדרואיד) כך שניתן לכתוב את האפליקציה ולשלב אותה ב-Android הפנימי שיווצר ל-Image שירוץ על המערכת. אם צריכים חבילות לינוקס, אפשר להרים מערכת כמו Linux Deploy שתרוץ ברקע, להקים הפצת לינוקס מינימלית שצריכים עם החבילות הדרושות ואז מהאפליקציה שלכם לתקשר דרך Socket או דרך TCP אל האפליקציה (אישית עשיתי זאת פעמיים וזה הציל פעם אחת פרויקט מביטול מאחר והאפשרויות האחרונות לא אפשרו התקנת חבילות מסויימות).
    החסרון: אם מחפשים Boot של 3-5 שניות – תשכחו מזה. בנוסף, קימפול קרנל למערכת אנדרואיד אינו עניין פשוט הואיל ויש לא מעט חלקים שאנדרואיד כן צריך והפצות לינוקס רגילות לא צריכות.

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

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

כמה מילים על מעבדי Power

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

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

קצת היסטוריה: אפל, IBM ומוטורולה החליטו אי שם בשנות ה-90 להתחרות באינטל ולהוציא מעבדים משל עצמם תחת השם PowerPC. מוטורולה הוציאה את המעבדים, אפל השתמשה בהם בשמחה ו-IBM גם השתמשו בהם בחלק מהשרתים והיה אפילו מחשב ThinkPad יחיד שיצא עם מעבד PowerPC שהריץ OS/2 (וזמן קצת לאחר מכן שיווקו הופסק כי לא היתה לו דרישה).

עם הזמן אפל נטשה את ה-PowerPC, ומוטורולה המשיכו ליצור למשך זמן מה מעבדים כאלו לשווקים נישתיים כמו Embedded. ב-IBM הבינו שאם הם רוצים להתחרות באינטל, הם צריכים לעבוד ולפתח את המעבדים בעצמם וכך IBM שחררה במשך השנים מספר מעבדי Power שונים. בהתחלה המעבדים הללו היו עמוסים בתקנים קנייניים שלא תמכו טוב בסטנדרטים כמו זכרון ECC רגיל, אך החל מ-2015 ב-IBM הבינו שכדאי לרדת מהעניין ולהשתמש בחומרה סטנדרטית, וכך מעבדי ה-Power8 ו-Power9 החלו לתמוך בזכרון רגיל לשרתים, תקן PCIe לכרטיסים (ב-Power9 התקן הוא PCIe 4.0 שכרגע לא נמצא באף שרת מבוסס מעבדי אינטל, זה רק יחל להופיע בשנה שנתיים הבאות, אם כי רוב הסיכויים שהחברות יקפצו ישר ל-PCIe 5.0) ועוד.

מבחינת ארכיטקטורת מעבד, הארכיטקטורה של Power9 היא מורכבת ולא אכנס לפרטי פרטים בפוסט זה (למעוניינים, דף ה-WIKI הזה מסביר יותר), אך נאמר כך: במעבדים כמו EPYC או Xeon, אנחנו רגילים למצוא Cores ו-Threads, כאשר הכלל הקבוע הוא שכל 2 Threads תופסים בעצם ליבה אחת. ב-Power9 זה שונה: ה-Threads נקראים Slices ועל כל Core ניתן לפנות ל-שמונה Slices. ישנם 2 סוגי מעבדי Power9, ה-SMT4 ו-SMT8 כאשר SMT4 מכיל 12 slices ו-SMT8 מכיל 24 slices. מבחינת ליבות, המעבד קיים במספר גרסאות, החל מ-4 ליבות ועד 22 ליבות.

המעבדים הללו יכולים להיות ב-2 תצורות: אחת בשיטה הידועה והפופולרית של Scale Up (נקראת: SU) והשניה היא Scale OUT (נקראת: SO). מערכות שמשתמשות ב-Power9 SU לדוגמא הינן מערכות עם 4 מעבדים ואילו מערכות SO הינן מערכות עם 2 מעבדים. מערכות SU כוללות תמיכה בזכרון ישיר למעבד (Directly Attached) מסוג DDR4 ואילו מערכות SO משתמשות בזכרון כזכרון חוצץ. מהירות הגישה לזכרון ב-SO היא עד 120 ג'יגהבייט לשניה ואילו ב-SU היא 230 ג'יגהבייט לשניה (הרבה יותר מכל מעבד מבוסס X86-64).

אחד היתרונות הגדולים של מעבדי Power9 היא קישוריות מאוד גבוהה לציודים הסובבים למעבד. במידה ומשתמשים ב-GPU של nVidia או ציודים אחרים, ב-IBM משתמשים בדבר שנקרא Bluelink ובעברית פשוטה: כל התקשורת בתוך המכונה עצמה היא הרבה יותר מהירה מהמעבדים המתחרים.

IBM משווקים מספר מכונות, כאשר חלק מהמכונות מגיעות עם מערכת קניינית של IBM ומתוכה בעזרת תוכנת PowerVM אפשר לבנות מכונות VM שמריצות לינוקס ויש ל-IBM גם מכונות שמריצות ישר לינוקס עוד מה-Boot (כמו L922, S914,AC922 ועוד). למעוניינים (יש כאלו?) אפשר להריץ על המערכות הללו גם .. AIX. מבחינת מערכות לינוקס הקיימות ל-Power9, המבחר הוא: SLE של SuSE ו-RHEL של רד-האט. ניתן להריץ גם גירסת Debian על Power9 אבל רק מה"עץ" של ה-Unstable עם מינימום Kernel 4.15 ומעלה.
אה, ואי אפשר להקים מכונות VM עם Windows על מכונות כאלו. אין תאימות ל-X86-64..

אז למי מיועדות המערכות הללו?

הקהל הראשון שירצה לשמוע על המערכות הללו הן חברות שמעוניינות לפתח AI או Deep Learning. בכל מכונה כזו ניתן להכניס 4-6 כרטיסי GPU מסוג Tesla של nVidia, ואם נבדוק את הביצועים של GPU כזה על מערכות Xeon בהשוואה למערכות Power9, נקבל שהביצועים של Power9 מבחינת קישוריות הם פי 7-10 יותר גבוהים. אם נתרגם זאת לתוכנות המקובלות, אז TensorFlow רץ פי 2.3 יותר מהר, Caffe פי 3.7 יותר מהר, ו-Chainer פי 3.8 יותר מהר על מערכות Power9 בהשוואה למעבדי Xeon החדשים ביותר.

הקהל האחר שגם יעניין אותו המכונות הללו הם חברות שרוצות להריץ קונטיינרים והרבה. כאשר כל מעבד תומך בעד 2 טרהבייט זכרון ויש לך 96 Threads/Slices, אתה יכול להריץ המון קונטיינרים, גדולים כקטנים – על מכונה אחת (ואין שום בעיה לעבוד עם מס' מכונות). IBM מציעים את תוכנת ה-Cloud Private שמיועדת לניהול קונטיינרים והיא רצה על בסיס שכולם מכירים – Kubernetes. אם כבר מדברים על קונטיינרים – כלים ומתודות של CI/CD עובדים יפה מאוד על מערכות Power9.

קהל נוסף שדווקא כן מכיר את ה-Power9 הם אלו שרוצים להקים HPC גדול. ל-IBM כבר יש פרויקטים של HPC שרצים כבר עם Scale גדול כמו Summit, Sierra, MareNostrum 4.

כמו תמיד, יהיו מי שירצו לדעת מי משתמש במערכות כאלו – הרבה מאוד חברות בחו"ל, וחברה שאולי שמעתם עליה.. Google.

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

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

פוסט עדכני על קורסים בחברות

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

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

טכנית, אין לי שום בעיה להעביר קורס על לינוקס, על כלים שמשתמשים במתודות Devops (כמו GIT, Jenkins, קונטיינרים, וירטואליזציה, SDS ועוד), אבל להעביר קורס במשך יום יומיים לדוגמא על הכרת לינוקס (ויש לא מעט סוגי קורסים כאלו) – אני יכול להבטיח לכם שההשקעה (שהיא לא ממש קטנה במחיר) תרד לטמיון. מדוע? מכמה סיבות:

  • קורסים מסויימים מלמדים על כמה הפצות לינוקס במהלך הקורס. זו, לעניות דעתי, טעות. לי, אישית, כשאני לומד עדכון של הפצה שאני כבר מכיר, לוקח לי כמה שעות במשך כמה ימים ואילו הפצה חדשה לוקח לי יותר זמן ללמוד (מה לעשות, צריך גם להתפרנס, לא? 🙂 ). לעומת זאת, מישהו שהוא חדש בתחום  הלינוקס, יקח לו הרבה יותר זמן ללמוד, ולימוד הפצות שונות באמצע די מבטיח בלבול רציני. כבר ראיתי מישהו שדי חדש בלינוקס מתעקש במשך שעה לנסות להתקין חבילות תוכנה עם פקודת zypper (שקיימת להפצת SuSE) בשעה שהוא היה צריך להשתמש בפקודת yum (שקיימת בהפצות Red Hat ו-CentOS) ולכן קורס טוב לדעתי צריך להתמקד בהפצה עיקרית אחת.
  • שיטת לימוד של "נזמין את המדריך ליומיים שלוש" להדרכה, היא שיטה די בטוחה שהכסף שיושקע ילך לטמיון. לינוקס זה לא לימוד MCITP ורוב מוחלט של החומר הנלמד הם פקודות טקסטואליות שצריך לשנן, ולנסות. קורס יומיים? תהיה בטוח ש-90% מהחומר ישכח ע"י רוב התלמידים, ועל כך יכול להעיד המייל אצלי. יש צורך לפרוס את זה ליום או יומיים בשבוע לשעות ספורות.
  • רלוונטיות: מכיוון שהשוק פתוח וכל אחד יכול להציע קורסים כאוות נפשו, מגיעים אליי כל מיני שאלות אם אני יכול להעביר קורס על טכנולוגיה זו או אחרת. טכנית, אין לי בעיה להעביר, אבל התועלת לחברה חשובה לי לא פחות מכך וצריך לבדוק (כן, תחת NDA) היכן זה משתלב. כך לדוגמא פנו אליי בעבר להעביר קורס מעמיק ב-Docker. זה, לדוגמא, קורס שהתוכן שרלוונטי הוא אולי 10% כי בסופו של יום אם מתחילים לבנות בחברה קונטיינרים, משתמשים במערכת ניהול והרצת קונטיינרים כמו OpenShift או Kubernetes – כך שללמד איך לבנות קונטיינרים – כן, איך להריץ ואת החלקים הפנימיים ב-Docker – לא ממש, תשאירו את זה להדרכות על כלי הניהול.

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

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