עדכון מערכות לינוקס ו-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 – לא ממש, תשאירו את זה להדרכות על כלי הניהול.

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

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

הפצה מול הפצה: רד האט מול SuSE

בעולם ה-Enterprise יש כיום 2 הפצות לינוקס מרכזיות שנותנות פתרונות מלאים לשוק זה והן RHEL של חברת Red Hat ו-SLE של חברת SuSE. הפעם ננסה לבחון מי מהן טובה יותר בכל מיני קטגוריות, לא כולן טכניות.

נתחיל מבחינה טכנית של הטמעה ושימוש: לשתי ההפצות יש התקנה מסודרת שיודעת לתמוך במגוון ציודים שיש בשרת, בין אם הן רצות "על הברזל" או על מכונה וירטואלית או כ-Image בסיס לקונטיינר. ב-99% מהמקרים לא תצטרך לחפש דרייברים נוספים (למעט כרטיסים של nVidia, אם כי SuSE מציעה פתרון שאינו מצריך חיפוש והורדה של דרייברים). אם כל מה שאתם עושים בלינוקס נמצא בתוך החבילות של ההפצה, אין שום בעיה לעבוד עם כל אחת מההפצות, והשינויים בין הפצה אחת לשניה אינם כה מהותיים. פה yum ושם zypper.

למרות זאת, עם כל האהבה שלי ל-CentOS/RHEL, ל-SuSE יש מספר יתרונות על רד-האט שחשוב לדעת עליהם, לדוגמא:

  • הפצת SLE מתקדמת יותר מההפצת לינוקס של רד-האט. יש שם Kernel חדש יותר, והכלים עצמם יותר מעודכנים ויותר מודרניים, כך שאם לדוגמא מתקינים Kubernetes, אז לא צריך לחפש אותם במאגר צד ג' כלשהו, מה שמגיע עם ההפצה זו הגירסה האחרונה היציבה, וכנ"ל שאר כלים נוספים כולל קומפיילרים וסביבות פיתוח יותר עדכניות.
  • הפצת SLE קלה יותר להגדרת דברים. ב-SLE יש כלים כמו yast2 שמאפשרים להגדיר הרבה דברים במערכת, החל מ-NFS, iSCSI, רשת ועוד ועוד מבלי לדעת איזה פרמטרים להכניס בקבצי ההגדרה.
  • ויש עוד דברים…

נמשיך מכאן להפצות עבור שימוש בכלים או פלטפורמות יחודיות להפצה. לדוגמא OpenShift במקרה של Red Hat, או SES במקרה של SuSE או OpenStack במקרה של שתי ההפצות: הגרסאות שההפצות מוציאות רצות אך ורק על הפצות הלינוקס מתוצרתיהן, כך שלדוגמא OpenShift לא ירוץ על SLE וגירסת ה-SES או OpenStack של SuSE לא ירוצו על מערכת של Red Hat (ניתן כמובן לעשות טריקים שכן ירוצו אך לא תקבלו לכך תמיכה רשמית). לכל אחת מההפצות יש שינויים ותוספים יחודיים לה (לדוגמא מערכת OpenAttic שנמצאת ב-SES), כך שבמקרים כאלו אם ארגון מסויים מעוניין במערכת של אחד היצרנים והפצת הלינוקס אינה ההפצה הרגילה של שאר מערכותיו, הוא יכול להתקין את את ההפצה והפלטפורמה כמעין "Appliance". הן מערכות RHEL והן מערכות SLE ניתנות להגדרה בקלות לניטור ולביצוע פעולות אחרות והן אינן מערכות סגורות.

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

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

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

כמה מילים על Microsoft SQL 2017 ללינוקס

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

אתחיל במידע כללי: מדוע מיקרוסופט בעצם שחררה את שרת ה-SQL שלה ללינוקס? התשובה די פשוטה: להתחרות מול אורקל ולהציע לחברות שמריצות לינוקס בפרודקשן בגלל היציבות – את שרת ה-SQL שלהם. בדרך להציע זאת ללקוחות, מיקרוסופט פתחה לעצמה פתח להציע דברים אחרים ללקוחות עם Linux עם פרויקט Draw bridge וזאת מבלי לשנות שום קבצים באפליקציה שלהם ומבלי לשבור תאימות, כך שהכלים של SQL ב-Windows יוכלו להתחבר לשרת לינוקס ולעשות את אותה עבודה. כלל, מבחינה טכנית, כשאתם מורידים SQL Server של מיקרוסופט ללינוקס, אתם מקבלים את האפליקציה + ספריות וגם קבצים בינאריים של .. Windows 8 (אפשר לקרוא על כך ולשחק עם זה, למעוניינים. פרטים כאן).

נעבור לאספקט הטכני: שרת SQL של מיקרוסופט ללינוקס נראה בדיוק כמו כל אפליקציה אחרת ללינוקס. כשרוצים להתקין לדוגמא על שרת CentOS או RHEL או SLE של SuSE – מורידים קובץ אחד של REPO ומשתמשים ב-YUM להתקין (או zypper במקרה של SuSE) (לצערי מיקרוסופט לא כל כך עקבו אחרי תקן ה-LSB ללינוקס והקבצים ימצאו ב-var/opt/mssql/ בשעה שהסטנדרט מדבר על opt/). הנה וידאו על התקנה של SQL על CentOS 7 כולל שימוש בכלי חדש של מיקרוסופט לעבוד עם ה-SQL (אפשר לעבוד כמובן גם עם הכלים הרגילים):

וכאן יש וידאו כיצד לבצע Auto Tune עם SQL על לינוקס:

כלומר מבחינת עבודה עם SQL Server של מיקרוסופט, אתם יכולים לעבוד עליו בדיוק כאילו התקנתם אותו על שרת Windows. הרשיון הוא אותו רשיון ואין צורך בתשלום נוסף ולאנשי ה-DBA אין שינוי כלשהו שצריך לבצע. לעומת זאת, לאנשים שאוהבים לעבוד ב-CLI, מיקרוסופט מספקת את mssql-cli שמאפשר עבודה ב-cli (כפי שמודגם בוידאו הראשון) ויש גם את פקודת sqlcli שמאפשרת לגבות DB, לשחזר וכו' וכו'. מנסיוני, ה-sqlcli עובד יפה (רק חבל שמיקרוסופט לא הטמיעו שיטה להכנסת סיסמאות מוצפנות דרך ה-cli).

אחד העניינים שכמובן חברות גדולות יתעניינו בו, הוא עניין האשכולות (Clusters). מה עושים כשרוצים להריץ SQL Server כ-Cluster בתשתית? התשובה במקרה הזה די פשוטה: משתמשים בכלי לינוקס כמו CoroSync ו-PaceMaker כדי לבצע זאת (הוראות נמצאות כאן).

אבל אחד היתרונות הגדולים של SQL Server של מיקרוסופט בלינוקס – זה שאפשר להריץ אותו כקונטיינר, ואז כל עניין ה-Cluster מתייתר. כל מה שצריך לעשות זה להריץ את גירסת הקונטיינר של SQL Server של מיקרוסופט תחת Kubernetes או OpenShift ואז תקבלו לא רק ביצועים גבוהים, אלא שרידות הרבה יותר גבוהה ממה שהייתם משיגים מכל פתרון Cluster קלאסי (לינוקס או Windows), החל מרמה פשוטה של הרצת SQL ב-Pod שכשהוא נופל אוטומטית Pod אחר קם ואז ניתן לעבוד שוב, וכלה בפתרון של הרצת 3 PODs כשבכל אחד מהם רץ SQL Server וכאשר אחד מהם נופל, מתקיים תהליך "בחירות" אוטומטי והזוכה נהיה ה-Primary. אפשר לראות הדגמה של כך בלינק הזה.

לסיכום: SQL Server של מיקרוסופט מאפשר לכם לעבור מ-Windows ללינוקס מבלי להיתקל ביותר מדי בעיות ומבלי לשלם על רשיון SQL נוסף. תגבו את כל ה-DB בגירסת SQL ל-Windows, תקימו SQL Server ללינוקס, תשחזרו נתונים על הלינוקס ותתחילו לעבוד (וכן, אפשר לחבר את המכונה ל-AD). אתם יכולים גם להשתמש בכלי אוטומציה שקיימים ללינוקס ולבצע פעולות רבות על ה-SQL ללינוקס בדיוק כמו לכל שרת לינוקס אחר. אין Kernel Modules (מיקרוסופט העיפה את כל ה-syscalls של Windows) כך ששום דבר לא אמור להפריע למערכת לעבוד בצורה נורמלית, יש את כל התמיכה ב-SystemD וכן .. זה רץ גם על אובונטו 🙂

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

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

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

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

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

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

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

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

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

כמה מילים על ZFS (לשנת 2018)

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

כיום, אם חברה מסויימת רוצה לרכוש לעצמה סטורג' כפתרון קצה – היא בהחלט יכולה וישנם פתרונות טובים בשוק שיתנו לכם קופסא עם דיסקים, חיבורי רשת מאחורה, מערכת Appliance שרצה בתוך הקופסא עם ממשק WEB ו-CLI ועם פונקציונאליות בהתאם למחיר ולרשיון שרכשתם. פעם היו EMC, NetApp הכי פופולריים, היום יש מגוון שלם של מוצרים מוכנים – רק להרכיב, להגדיר מספר דברים מצומצם וקדימה – אפשר לעבוד עם הפתרון, ואלו פתרונות שיכולים להתאים לרוב החברות והעסקים.

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

להלן צילום מסך מ-vSphere client בגירסה 5.5, כאשר מגדירים LUN חדש ובוחרים את ה-Block Size (לחצו להגדלה):

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

במקרה לעיל, לא חשוב איזה Storage יש לך, מהרגע שהגדרת iSCSI LUN בסטורג', לסטורג' אין מושג ירוק מה אתה הולך לעשות איתו. מבחינתו זה Block ולך תשבור את הראש מה לעשות ואיך להגדיר ואיך לעשות אופטימיזציה לו ב-Initiator שלך.

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

אבל מה קורה אם אנחנו רוצים לבנות פתרון סטורג' משלנו ואנחנו מעוניינים לעשות לו אופטימיזציה ולא להיות "שבויים" באיזה פתרון שלא מאפשר לנו להגדיר דברים לעומק? אם אנחנו בונים עם לינוקס מערכת כזו עם File System כמו XFS או EXT4, מאותו הרגע שחילקנו את הדיסק עם או בלי LVM, ואנחנו מפרמטים את כל מערך ה-RAID בזמן ההתקנה, אז כבר אי אפשר לשנות את גודל הבלוקים. ב-XFS לדוגמא, ברירת המחדל היא להגדיר בלוקים בגודל 4K כל בלוק, אבל אם אנחנו הולכים לאחסן רק קבצים שרובם בגודל מס' ג'יגהבייטים, אנחנו נפסיד מהירות.

לעומת זאת ב-ZFS, גם אחרי ששייכנו את כל הדיסקים ל-Pool מסויים, אנחנו תמיד יכולים להגדיר את גודל הבלוקים (ב-ZFS זה נקרא record size) גם אחרי יצירת ה-Pool ויצירת Dataset (חשוב כמובן לשים לב שאם יצרנו Dataset ואנחנו מגדירים לו record size חדש, רק הקבצים החדשים יקבלו את גודל ה-record size החדש, לא הקבצים הישנים) כפי שניתן לראות לדוגמא כאן. (אגב, זה דבר שמאוד עוזר עם MySQL לדוגמא, אתם מוזמנים להציץ כאן)

נקודה נוספת וחשובה היא כמובן הדיסקים. ישנם עדיין מקרים רבים שיש שרתים פיזיים שמריצים אפליקציות מסויימות על דיסקים מקומיים עם כרטיס RAID הכולל זכרון Cache וסוללה, אך עם הדיסקים החדשים שיש כיום שמחירם יורד כל הזמן, יהיו לא מעט חברות שישמחו לקנות דיסקים בגודל 6,8,10,12 או אפילו 14 טרה בייט ויחברו אותם לבקר ה-RAID וכך הם יקבלו כמות אחסון מכובדת, אך יש בעיה מרכזית אחת: כל דיסק מעל גודל 4 או 6 טרהבייט שנדפק ומוחלף, יאיט אוטומטית את הביצועים של כל מערך הדיסקים לזמן רב (זה יכול לקחת ימים או במקרים של דיסקים גדולים כמו 10,12,14 טרהבייט – אפילו שבועות!) מהסיבה הפשוטה שבקר דיסקים הוא דבר די טיפש, הוא יודע לקרוא בלוקים, אבל הוא לא יודע מה יש בבלוקים, כך שבקר ה-RAID מבצע rebuild, הוא יעתיק את כל הבלוקים, גם אם 60% מהדיסק הוא בכלל ריק! לעומת זאת ב-ZFS אם נדפק דיסק והחלפנו אותו, מערכת ה-ZFS תשחזר (מה שנקרא: resilver) רק את הקטעים שלא קיימים בדיסק החדש, כך שה-rebuild יהיה הרבה יותר קצר והמערכת תשוב לאיתנה במהירות הרבה יותר גבוהה מאשר בתהליך rebuild של כרטיס RAID.

חסרונות נוסף שקיימים ל-XFS ול-EXT4 הם לדוגמא:

  • אין בדיקת קבצים מתמשכת. ב-ZFS לכל קובץ יש checksum כך ש-ZFS יודע בדיוק אם מה שהוא קרא תקין או לא ואם לא הוא יטפל בבעיה אוטומטית בכך שהוא יעביר את הנתונים למקום אחר (בערך כמו שבקר SSD טוב עושה) ול-ZFS ישנו גם תהליך scrubbing שעובר אחת לכמה ימים על כל הקבצים בדיסקים לבדוק זאת ולטפל בתקלות באופן אוטומטי. ב-XFS וב-EXT4 יש לך Journal שיכול לעזור בקריסת המכונה, אך זהו פתרון שאינו מספק על מנת לשמור על הנתונים.
  • ב-EXT4 וב-XFS אין מנגנונים לניצול משאבי המכונה מבחינת זכרון. כן, ללינוקס יש שימוש מתוחכם בזכרון החופשי לשם Cache מסוגים שונים, אבל ב-ZFS יש את ARC שלוקח כברירת מחדל מחצית מהזכרון של המערכת להאצת ביצועי דיסק בכך שהוא משתמש באותו זכרון שהוא "גזר" בהתחלה, וכידוע – זכרון RAM הוא הדבר הכי מהיר שיש, יותר מכל SSD שקיים בשוק.
  • שימוש מושכל ב-SSD וב-NVME: עם מערכת כמו bcache או fastcache (לאלו שאוהבים לחיות על הקצה) יכול להיות פתרון די טוב על מנת להאיץ ביצועים של דיסקים מכניים, אך ב-ZFS יש לך 3 מנגנונים שמטפלים בכך:
    • מנגנון ה-ARC (שמשתמש כברירת במחצית הזכרון של המכונה לשם CACHE מהיר)
    • מנגנון ה-ZIL (להאצת ביצועים וטרנזאקציות של קבצים קטנים ורישומי הפניות להיכן קבצים נכתבים, אפשר לקרוא על כך כאן)
    • מנגנון ה-L2ARC – כאן בד"כ יהיה SSD מהיר ששומר עותקים של קבצים שניגשים אליהם בתכיפות גבוהה.
  • מערכת ZDB – לכל File system יש כלים משלו (tune2fs ל-EXT3/EXT4 לדוגמא או ערימת הכלים הזו ל-XFS), אבל ZDB לוקח את זה כמה צעדים קדימה – לבדיקה האם יש Cache אופטימלי, לבדיקה של ביצועים פר דיסק, בדיקות והגדרות ל-B-TREE (כן, ZFS שומר את הקבצים ב-B-Tree) ועוד המון דברים. ZDB הוא ה"אולר השוויצרי" ל-ZFS ועבודה איתו יכולה לתת ביצועים שעוקפים מרחוק כל File System לינוקסי.

יחד עם זאת ל-ZFS יש עדיין חסרונות (שיטופלו בשנה הקרובה):

  • הוספת דיסקים: לא, אתה לא יכול להוסיף עוד דיסק אחד אלא 2 ומעלה. גם החלפת דיסקים קיימים בדיסקים יותר גדולים היא לא בדיוק פיקניק כרגע (אבל זה אפשרי). במהלך 2019 יתווסף קוד להוספה דיסקים – אפילו דיסק בודד כמעט מבלי שנצטרך להתמודד עם איטיות של פריסת DATA מחדש (יועתקו מספר בלוקים בודדים וזהו).
  • עבודה עם SSD – אחד החלקים היותר נחמדים ב-SSD זו פקודת trimfs שאומרת ל-SSD לבצע פקודת TRIM ב-SSD. ב-ZFS יש תמיכה ל-Trim אך היא אינה אוטומטית בגירסת ZFS ללינוקס. יש Pull request שיכול לעבוד ברוב המקרים בגירסה הנוכחית היציבה של ZFS ללינוקס, ובגירסת ה-Master זה עובד בצורה טובה. אני מאמין שבחודשים הקרובים זה יוכנס פנימה.

לסיכום: אפשר להקים שרת ZFS תוך דקות ספורות על מכונה חדשה. יוצרים pool עם תצורת RAIDZ רצויה, מחלקים דיסק SSD ל-2 פרטישנים (אחד log ואחד cache, ככלל עדיף 2 SSD שיעבדו כ-Mirror), מצמידים אותם ל-pool ויאללה – יש מערכת ZFS עובדת. העניין הוא שאם אתה רוצה ביצועים מעולים, תצטרך להשקיע זמן בהגדרות דברים לפי מה שרוצים להריץ ומה ה-ZFS צריך לשרת (ואני ממליץ את הספר הזה ל-ZFS על לינוקס, או את הספרון הזה). האם ZFS הוא פתרון חלופי לסטורג' סגור – במקרים מסויימים כן ובמקרים מסויימים לא (תלוי בדרישות ובצרכים), אבל הוא מאוד מתאים אם חברה מחליטה להקים סטורג' קטן והיא מוכנה להשקיע את שעות העבודה כדי לבצע אופטימיזציה וזה לוקח זמן (לפי הידע של מי שמבצע זאת), זה לא משהו שנעשה בחצי יום, וצריך לעיתים להקים מערכת שלמה כדי להגדיר לבדוק את הביצועים.

על לינוקס, VMWare וטעות הקשורה לחיישנים

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

עד לגירסה 5 (גם 5.5) ב-VMware השתמשו בד"כ בדרייברים מבוססי לינוקס כדי להפעיל ציודים, בין אם מדובר בציוד זול או בבקרים יקרים מאוד. בגירסה 6 החליטו ב-VMWare לעבור לדרייברים שהם כותבים (או שהיצרן כותב) עם שינויים מהותיים בקוד כך שלא כל כך קל לקחת דרייבר של לינוקס ולזרוק אותו לגירסה 6 (ולפי השמועות, זה הולך להשתנות שוב בגירסה 7, אבל בינתיים אלו רק שמועות).

אם יש לכם שרתים שמריצים VMWare, אחד הדברים החשובים שתרצו לדעת הוא מה מצב החיישנים במערכת. מה הטמפרטורה של המעבד, דיסקים, ספק כח, חום פנימי בשרת, מצב תקלות זכרון ודברים כאלו ואכן, עד גירסה 6 של vCenter קיבלתם את המידע כולו בתצורת עץ. המידע הזה חשוב (וגם ניתן לקריאה על ידי תוכנת הניטור שלכם דרך SNMP). עד גירסה 6 ה-vCenter עשה משהו פשוט מאוד: הוא פנה לכל שרת ESXi שרשום ב-vCenter וקרא ממנו את הערכים. איך ESXi קורא את הערכים? בעזרת חבילה שכלולה בכל הפצת לינוקס שנקראת lm-sesors והיא קיימת בכל התקנה של שרת ESXi. החבילה הזו מעודכנת כל הזמן וכל עוד הקרנל בלינוקס מעודכן, תוכל לקרוא את כל החיישנים במערכת, וזה רץ על כל מערכת, בין אם מדובר במחשב נייד, בדסקטופ, תחנת עבודה או שרת מפלצתי.

בגירסה 6.5 ל-VMware "קפץ הפיוז" והם החליטו שה-vCenter (בין בגירסת Windows או VCSA) לא יקרא יותר את החיישנים מה-ESXi (שכבר יש לו את הנתונים שמתעדכנים כל 90 שניות), אלא יפנה אל ה-IPMI. למי שלא מכיר – בכל לוח אם של שרת יש רכיבים שנותנים ניהול מרחוק, אתם אולי מכירים את זה בשמות כמו ILO, IMM, iDRAC – וכולם בעצם מממשים פחות או יותר את סטנדרט IPMI לשליטה מרחוק על המכונה. הבעיה, כמו תמיד, שיש לא מעט מקרים שהמימושים הם לא ממש משהו או שהיצרן החליט להתעלם מחלק מסטנדרט ה-IPMI. אחרי הכל, למשתמש יש גישת CLI או גישת Web לניהול מרחוק, אז אפשר להחביא את המימוש העקום מתחת לשטיח.

וזה משהו שב-VMWare לא ממש התעמקו כנראה. מבחינתם, החל מגירסה 6.5, יש שרות שנקרא wbem ויש API לפונקציה שנקראת HostConfigManager.healthStatusSystem והיצרן צריך לכלול (או לשחרר) VIB שכולל את הגישה לניהול מרחוק של השרת, כך שבתאוריה המנהל יצטרך רק להכניס פרטי התחברות ל-IMM/IDRAC/ILO והמערכת תתחיל לקרוא את החיישנים ישירות מהניהול הרחוק.

במציאות .. זה לא ממש עובד. כך לדוגמא אחד השרתים שלי (גם אחרי התקנת ה-VIB) מראה תצוגה של החיישנים בכל שרת (לחצו להגדלה):

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

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

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