על דיסקים מכניים גדולים ו-RAID

מי שעוקב אחרי חדשות טכנולוגיות יכול למצוא אחת לכמה חודשים הכרזות של יצרני דיסקים שונים על דיסקים חדשים, לפעמים על שיטת קריאה/כתיבה חדשה. כך לדוגמא, חברת Showa Denko K. K. הכריזה כי היא סיימה לפתח ראש MAMR חדש לדיסקים קשיחים עבור חברת טושיבה, וטושיבה תוציא דיסקים קשיחים בגודל 18 טרה המבוססים על טכנולוגיה זו במשך השנה. צפו להכרזות דומות מצד שאר היצרנים.

כיום, בין אם יש לך שרת שאתה מכניס בו דיסקים קשיחים ומחבר אותו לבקר RAID כלשהו, ובין אם יש לך סטורג' קנייני – כל היצרנים ישמחו למכור לך דיסקים קשיחים גדולים – בין אם ישירות מיבואן יצרן הדיסקים ובין אם דרך החברה שרכשת ממנה את השרת או הסטורג'. רוצה מדף עם 12 דיסקים של 10 טרהבייט? בשמחה! תחתום פה ופה, תעביר כרטיס אשראי או תשלח צ'ק וטכנאי בדרך אליך להתקין את המדף לסטורג' ולהגדיר אותו. אין צורך לדאוג, גם הדיסקים הגדולים שנמכרים כיום נמכרים עם SAS Dual Port לחבר ל-2 כרטיסי RAID (אם אתה רוצה להכניס את זה לשרת, בסטורג' זה אוטומטי).

אבל האם זה שווה לרכוש את הדיסקים הללו? בכל זאת, אם קנינו מדף של 12 דיסקים בגודל 10 טרה, אנחנו נקבל ברוטו 120 טרהבייט, זה שקט להרבה זמן מבחינת אחסון פנוי!

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

לשם פוסט זה, נניח ויש לנו את ה-12 דיסקים של 10 טרה, והם מורכבים בסטורג' או בשרת עצמאי עם 2 בקרי RAID (או אחד, זה לא ממש משנה מבחינת מהירות קבלת נתונים, ה-Dual Port ב-SAS הוא יותר לשרידות, אם כי במצב שהולך לך בקר, אני הייתי ממליץ לך להשבית את השרת עד שיגיע טכנאי עם חלק חלופי. אתה לא רוצה לסכן את ה-DATA שלך!). נניח שהגדרנו RAID, נניח 5 או 6 (במצב של 1 זה הרבה יותר מסוכן) או כל "RAID" בסטורג'.

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

וכאן… מתחילות הבעיות והסיכונים צצים…

  • אם הדיסקים נמצאים בשרת והם מחוברים לבקר RAID (וזה לא חשוב איזה RAID הגדרתם, למעט כמובן 0 שאז הלך ה-DATA) – השחזור לא רק שיהיה איטי ויקח מספר ימים, אלא שאתם תסבלו מביצועים נמוכים מאוד באותם ימים הואיל וכל מערך ה-RAID צריך לעבוד בעצם כפול: גם לשרת את הצרכים שלכם, וגם לקרוא מהחלקים השונים של הדיסקים על מנת לכתוב את ה-DATA מחדש על הדיסק החלופי.
  • מכיוון שאתם מאמצים את המערכת – יש סיכוי שדיסק נוסף יפסיק לעבוד, הואיל והמערכת עובדת נון סטופ.
  • במקרים של שרת ו-RAID מבוסס בקר חומרה, הכתיבה היא "הכל" – גם אם היה לכם ב-RAID חומר בגודל 10 ג'יגהבייט, הוא יבצע Rebuild של 10 טרהבייט, מכיוון שבקר RAID הוא דבר די טיפש.
  • במקרים של סטורג' (או Software defined Storage) – שיטת ה-Rebuild תהיה שונה, וכמות ה-DATA שתיכתב על הדיסק תהיה כמו שאר הדיסקים באותו "RAID", כך אם יש חומר של 10 ג'יגה, יכתב 10 ג'יגה. ההבדל הגדול בין סטורג' לבין שרת עם בקר RAID חומרה – זה שהסטורג' יודע "להסתיר" את האיטיות עם דיסקים SSD, עם Flash Cache וטריקים אחרים, אבל עדיין – תורגש איטיות.

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

  • חברו את הדיסקים ל-HBA ולא לבקר RAID (אפשר לרכוש בקרי LSI עם IT MODE או להחליף להם קושחה).
  • השתמשו בתוכנה כדי לבצע RAID. יש הרבה פתרונות – החל מ-FreeNAS, ZFS, XPEnology, או Storage Spaces של מיקרוסופט. הכל תלוי בהעדפה שלכם.
  • השתמשו ב-SSD שהוא Mixed Intensed או SSD שמתאים ל-Enterprise אם המהירות חשובה לכם. ההמלצה שלי היא ללכת על Optane 900P או DC P4800X (אם יש לכם את התקציב) של אינטל על מנת לקבל Latency מאוד נמוך וביצועים גבוהים מאוד (שימו לב – אם השרת אינו חדש, אז ה-Optane לא יוכל לבצע Boot ואם בשרת אין תושבות PCIe 3.0 – אז הוא לא יעבוד).
  • אם אתם משתמשים ב-ZFS, אל תשכחו להגדיר תהליך "קרצוף" (scrub) של הדיסקים לפחות אחת לשבוע (התהליך עובר על כל ה-DATA והיכן שהוא מוצע בעיות, הוא משכתב את ה-DATA למקום פנוי אחר, כך שהעבודה תהיה חלקה).
  • גיבויים, גיבויים, גיבויים – תוכנות גיבוי זה טוב, אבל snapshots ברמת האחסון הם יותר טובים והשחזור הרבה יותר מהיר. דאגו שתהיה מכונה אחרת עם מקום פנוי לקבל את ה-Snapshots.

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

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

עדכון ליבה בשרתי לינוקס – ללא Reboot

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

בלינוקס – ברוב המקרים אינך צריך לעשות Reboot לשרת גם לאחר שביצעת עדכונים. במקרה הכי גרוע אתה פשוט יכול להפעיל מחדש את השרותים שרצים על השרות – לאחר התקנת העדכונים. חברות כמו רד-האט ו-SuSE עושות את הכל כדי לשמור תאימות בינארית של 100% כך שקונפיגורציות ודברים אחרים פשוט אינם משתנים (ב-2 ההפצות, כשמתקינים גירסה חדשה של תוכנה על הגירסה הישנה, המערכת תייצר קבצי rpmsave באותה תיקיה שנשמרות בה ההגדרות של האפליקציה, כך שתוכל לראות מה השתנה).

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

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

לאחר זמן מה יצאה רד-האט עם kpatch וחברת SuSE יצאה עם Live patching. קנוניקל לא נשארה מאחור והם הכריזו על שרות שנקרא livepatch.

כל השרותים לעיל – הם בתשלום בלבד, כלומר העדכונים צריכים לעבור דרך מערכת עדכונים מורשית של ההפצה בלבד. לא מדובר באיזו חבילת RPM או DEB שאפשר להוריד ולהתקין חופשי על כל השרתים בחברה. ב-רד האט יש צורך לעשות זאת דרך שרות Satellite וב-SuSE דרך SuSE Manager. באובונטו נותנים בונוס למשתמשים – מי שנרשם, יכול לעדכן דרך שרות livepatch עד כ-3 מכונות דסקטופ בלבד (לא שרתים, זה כבר בתשלום).

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

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

לסיכום: אם יש לכם שרתי לינוקס בפרודקשן והם שרתים מבוססים על Red Hat או SuSE או אובונטו בתשלום – כדאי להשתמש בשרות ה-Live Patching ותחסכו לעצמכם דאגות על אבטחה וענייני Reboot.

פרילאנסרים: תמצאו את החתול

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

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

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

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

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

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

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

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

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

בהצלחה.

להתקדם בתחום

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

כל השואלים יודעים ורואים במקום עבודתם ושומעים גם מחברים – על השינויים המתרחשים. על שימוש בעננים ציבוריים במסגרת העבודה, על קונטיינרים, על Devops, CI/CD, Kubernetes, ויש גם עשרות תתי נושאים. כל מי שקורא את הפוסט הזה בוודאי שמע על המושגים אבל רבים אינם יודעים בעצם מה ללמוד, מה חשוב ומה לא ובקיצור – איך להיות רלוונטי בעולם ה-IT של היום.

בעבר, החיים היו הרבה יותר פשוטים. אם היית רוצה "להתמקצע" בתחום של מיקרוסופט, אז היית לוקח איזה קורס MCSE (או איך שזה נקרא כיום, סורי, אני לא עוקב אחר שינויי השמות), לומד כלים משלימים של מיקרוסופט כמו SCCM, אקסצ'יינג', אולי PowerShell, ועם זה היית הולך לחפש עבודה. אחרים הלכו לתחומים כמו לינוקס ושלל השרותים שנמצאים בלינוקס, יש כאלו שהיו הולכים ללמוד CCNA בשביל תקשורת מחשבים, ויש כאלו שלמדו קורס כלשהו על סטורג', אחרים למדו VCP בשביל וירטואליזציה. בחברות גדולות היו מחפשים יותר דברים ספציפיים כמו אחד מהנושאים שציינתי לעיל (לדוגמא – איש וירטואליזציה), ובמקומות יותר קטנים היו מצפים שתכיר את כל הנושאים שציינתי על מנת להתקבל למקום העבודה.

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

אז מה אתה יכול לעשות כדי לשפר את סיכוייך למצוא עבודה טובה בעתיד?

יש כמה דברים.

אם אתה רוצה להישאר בתחום ה-IT הקלאסי (לפני כניסת הענן) אז מה שמומלץ לך זה ללמוד את התחומים "השכנים": אתה איש סיסטם מיקרוסופט? תכיר יותר את תחום הסטורג' הרגיל, תכיר יותר נטוורק לעומק (אתה יכול להשתמש בכלי כמו GNS3 לבצע סימולציות), והכי חשוב – להכיר את מערכת ההפעלה ה"מתחרה" לינוקס במובן הטרמינל (לא במובן הגרפי. ברוב המקרים אתה לא תעבוד מול תצוגה גרפית במכונות לינוקס) – מה זה לינוקס, איך הוא בנוי, פקודות לינוקס בסיסיות, כתיבת סקריפטים בסיסיים ב-BASH, הגדרות ציודים שונים, ניתובים, ניהול חבילות תוכנה, ועוד. אם אתה רוצה, יש אתר בשם Linux Academy שמלמד את הדברים (יש מנוי חודשים שעולה 50$ לחודש, שבוע ראשון בחינם). אם אתה יותר טיפוס של ספרים – יש לא מעט ספרים שמלמדים על לינוקס ויש כמובן גם קורסים בבתי הספר המקצועיים השונים שמלמדים לינוקס. לגבי סטורג' ונטוורקינג – אני ממליץ ללמוד לבד.

במקומות גדולים החל לצוץ לו תפקיד חדש לאחרונה (לא באופן רשמי, לפחות ממה שאני יודע) והוא "Cloud Admin" – מה שאתה עושה מקומית, עכשיו בענן, רק שבענן לא יחכה לך איזה סטורג' של Netapp/EMC, אין לך סוויצ'ים, אין לך פיירוול (את זה אפשר להוסיף, כ-Appliance) והכל בעצם נעשה בתוכנה, בין אם דרך ממשק ווב, אבל יותר דרך ממשק CLI וכאן כבר צריך ללמוד איך להגדיר דברים, החל ממכונות VM, נטוורקינג, דיסקים קשיחים וירטואליים ועוד ועוד. בלינק שפירסמתי לעיל יש גם קורסים לכל ספקי הענן הגדולים, כך שאפשר ללמוד שם גם איך להשתמש בענן ואיך לנהל משאבים. העננים הפופולריים ביותר הם של אמזון (AWS) ו-Azure של מיקרוסופט. קצת פחות פופולרי (והרבה יותר טכני) הוא הענן של גוגל, לכן מומלץ ללמוד לפחות את הענן שבו החברה משתמשת ואולי את הענן השני הפופולרי.

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

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

איש ה-Devops טוב צריך לדעת כמה דברים חשובים:

  • הוא צריך להכיר טוב לינוקס, ברמה של כתיבת סקריפטים, הגדרות לינוקס, ניהול חבילות
  • הוא צריך להכיר את עולם הקונטיינרים – החל משימוש ב-Docker כדי לבנות Images, והוא צריך להכיר Kubernetes (או OpenShift או Caas) כדי לבצע אורקסטרציה בין הקונטיינרים השונים שירוצו, שרותים, רשתות, Scaling ועוד.
  • הוא צריך להכיר כלי CI/CD על מנת לאפשר ביצוע Build אוטומטי דרך כלים כמו Jenkins או Teamcity לדוגמא.
  • הוא צריך להכיר כלי ניהול קוד טוב. כל כלי שיודע לעבוד עם GIT זה טוב, בין אם מדובר ב-Bit Bucket או GitLab או כלי אחר, וכדאי להכיר את הדברים לא רק ברמת ממשק הווב אלא גם להכיר את GIT עצמו.
  • "קוד כתשתית" – אחד הדברים ש"רצים חזק" כיום הם כלים שכותבים איתם "קוד" לניהול תשתית כמו הענן הפנימי שלכם בענן הציבורי, כלי כמו Terraform או Ansible או SALT הם כלים מעולים לכך.
  • שפות – BASH מאוד יעזור לכתיבת סקריפטים פשוטים, מומלץ להכיר גם Python.
  • שרותים – כל ספק ענן ציבורי מספק מאות שרותים שונים. תצטרכו עם הכלים הנ"ל להגדיר ולהשתמש בשרותים הנ"ל ואצל כל ספק ענן זה שונה. כן. Not Fun.
  • ניטור באופן שונה – מכיוון שיש הרבה שרותים שספק הענן מציע ולך אין גישה לתשתית השרותים, תצטרך להשתמש בכלים שונים לניטור, סביר להניח דרך כלי הניטור של ספק הענן.

כמו שאתם רואים – ערימה לא קטנה של דברים. אגב, כמעט את כולם ניתן ללמוד ב-Linux Academy בלינק שנתתי לעיל.

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

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

בהצלחה.

על קונטיינרים ו-Windows Server 2019

מיקרוסופט שחררה לפני זמן מה את Windows Server 2019 ואחד החידושים הגדולים שלו קשור לקונטיינרים. בעבר היית יכול להריץ עם Windows Server 2016 קונטיינרים, אולם המשאבים שכל קונטיינר היה תופס היו נכבדים (אין פלא, זה היה בעצם VM "מינימלי"), והיו מספר בעיות תאימות בהשוואה לקונטיינרים ללינוקס. כעת מיקרוסופט מכריזה שקונטיינרים ב-Windows Server 2019 הם הרבה יותר קרובים למה שניתן כיום להריץ על לינוקס, ואכן, כיום קונטיינר אינו VM אלא תהליך (Process) נפרד וכל הקונטיינרים רצים תחת אותו Kernel באותה מכונה.

ב-Windows Server 2019 ניתן להריץ קונטיינרים בדיוק כמו בלינוקס, כשאנחנו מדברים על קונטיינרים בודדים שאנחנו משתמשים ב-Docker, ואם אנחנו מעוניינים להריץ מספר קונטיינרים שמקושרים ביניהם – נשתמש ב-Docker Swarm.

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

אז .. איך Windows Server 2019 עם Kubernetes? התשובה: זה עובד. להכניס לפרודקשן? שלא תעיזו!. מיקרוסופט עדיין עובדים על זה.

ניסיתי בימים האחרונים את Windows Server 2019 עם Kubernetes (גירסה 1.13) והלן הערותיי:

  • תצטרכו לעבוד Multi OS, הווה אומר – ה-Master Node צריך לרוץ על מכונת לינוקס. אם אתם רוצים להשתמש בטריקים כמו HAProxy כדי לחשוף שרות (או NGINX) – תצטרכו גם Node מבוסס לינוקס, בנוסף למכונות Windows שישומשו כ-Nodes כדי להריץ אפליקציות מבוססות Windows.
  • בלינוקס Kubernetes משתמש ב-iptables כדי לנהל את התעבורה הפנימית. ב-Windows זה VFP כך שעדיין יש שימוש ב-Hyper-V. זה לא הולך לרדת.
  • מבחינת משאבים – Windows זה לא לינוקס, וכל קונטיינר מצריך פי 3 משאבים (במינימום!) בהשוואה לקונטיינר שרץ על לינוקס – גם בשביל קונטיינר שיציג Hello World, כך שאם אתם רוצים להריץ הרבה קונטיינרים מבוססי Windows – תצטרכו להקצות לא מעט משאבים לכך מבחינת מחשוב.
  • אין תאימות. בניתם דברים על Windows 10 או על Windows 2016 מבחינת קונטיינרים? תצטרכו לבנות אותם מחדש על Windows Server 2019.
  • וכן .. הכל עדיין דרך CLI (דרך PowerShell).

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

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

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

לסיכום: כן, ניתן להריץ Kubernetes על Windows, אך עדיין תצטרכו לפחות מכונת לינוקס אחת שתהיה ה-Master (ואם זה פרודקשן, זוג מכונות לינוקס שיעבדו כ-HA). מיקרוסופט עדיין עובדת על זה. תהליך ההתקנה עדיין מורכב (אם כי בגירסה האחרונה יותר קל להוסיף מכונות Windows לאשכול Kubernetes, וחשוב לשנות את קובץ ה-YAML לביצוע Deploy כדי שקונטיינר Windows ירוץ על מכונת Windows. ברגע שיש לכם אשכול כזה רץ, אפשר להגדיר את כלי ה-CI/CD שלכם להשתמש גם ב-Nodes מבוססי Windows ואפשר כמובן להשתמש ב-Draft, Helm לעשות את החיים קצת יותר קלים. לחברות שחושבות לעבור ל-OpenShift – בקרוב תצא גירסה שתומכת גם במכונות Windows. כמובן שאפשר לחסוך את כל הכאב ראש – עם תעברו ל-Net Core.

למעוניינים – להלן וידאו הדגמה משבוע שעבר איך Kubernetes רץ על Windows. (הוידאו ארוך: שעה וחצי!)

קונטיינרים ומכונות וירטואליות – השילוב הנחוץ

בפוסט הקודם שכתבתי על קונטיינרים ומכונות VM, דיברתי על עניין אבטחת מידע, וכיצד כלי כמו CRI-O יכול להחליף את Docker ובאותו זמן גם מאפשר לנו להריץ קונטיינרים שאיננו בוטחים בהם (Untrusted) בתוך QEMU – מכונה וירטואלית קטנה שמעלה לינוקס קטן ובתוך אותו VM "מולבש" הקונטיינר שלנו, וכך אנחנו נהנים מ-2 העולמות: לא צריכים לבנות את הקונטיינרים מחדש, ומצד שני האבטחה הרבה יותר רצינית.

הפעם נדבר על דבר הפוך וחדש.

סיפור קטן: לפני מס' חודשים ישבתי בישיבה אצל חברה פיננסית גדולה מאוד שכולם מכירים. מטרת הישיבה – שיחה על מעבר עתידי לתצורת עבודה של Devops, שימוש ב-CI/CD, קונטיינרים, מתודות וכו'. בדרך כלל בישיבה כזו אני מבקש לדעת מה הכלים שהם משתמשים כרגע, כמו שרתי אפליקציות, קומפיילרים, מערכות הפעלה וכלים אחרים, ולפי זה ניתן להעריך בהערכה גסה מה יהיה קל להעביר לקונטיינרים ול-Micro Services. במקרה של אותה חברה, מבלי לפרט דברים, היו כמה דברים שלהעביר אותם לקונטיינרים יהיה סיפור סופר-מורכב, ובחלק מהמקרים כנראה שלא אפשרי מכל מיני סיבות שלא אכנס אליהם כדי לא לחשוף פרטים. אלו הדברים שבדרך כלל אני רושם לעצמי בצד לבדוק מה ניתן לעשות עבור הלקוח.

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

כאן נכנס לתמונה כלי חדש של רד-האט שנקרא Kubevirt.

Kubevirt בעקרון עושה משהו הפוך ממה ש-CRI-O עם Kata containers עושה: עם CRI-O אנחנו מריצים קונטיינרים בתוך VM מינימלי, ואילו Kubevirt מריץ מכונה וירטואלית בתוך POD, וכן, אני מדבר על המכונה הוירטואלית המלאה – עם OS ואפליקציות משלה, שמתורגמת ישירות מ-VMWare או מ-OVA.

במילים אחרות – אנחנו נריץ VM כ-קונטיינר! (וכן, נקבל את האבטחה המלאה של ה-VM).

כך ניתן בעצם עם Kubevirt לקחת את אותן מכונות וירטואליות שלא ניתן להמיר לקונטיינרים ולהריץ אותן ישירות בתוך Kubernetes או OpenShift ובדרך להנות מדברים כמו Scaling ועוד תופינים שמערכת Kubernetes/OpenShift נותנת, מבלי שנהיה תקועים עם דברים שאי אפשר להמיר לקונטיינרים. כך לדוגמא אצל אותה חברה פיננסית גדולה, כל מה שאצטרך בעצם לעשות, זה להמיר את ה-VM (ליתר דיוק את הדיסק) ל-Persistent Volume ובקובץ ה-YAML להשתמש ב-PVC על מנת "לחבר" את ה"דיסק") לאותו VM.

יש גם מגבלות נכון לגירסה הנוכחית כמו:

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

רד-האט, מפתחת Kubevirt, פרסמה לאחרונה פוסט בנושא.

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

למעוניינים, באתר Kubevirt יש מספר דוגמאות איך ניתן להשתמש בכלי הן עם Minikube, הן בתוך Cluster של Kubernetes, הן בתוך AWS, והן בתוך GCP.

לסיכום: Kubevirt נותן סוף סוף את האפשרות לחברות לקחת מכונות וירטואליות ולהעביר אותן לעבוד יחד עם Kubernetes או OpenShift. אינני מדבר על ההעברה של כל תשתית הוירטואליזציה ל-Kubernetes (אני לא מוצא יתרון בהעברת מכונת SAP), אלא לדברים שאנחנו צריכים כחלק מעבודות מתודת Devops, CI/CD וכו'. במקרים שקשה או לא ניתן להעביר מכונות וירטואליות לפורמט קונטיינרים, הרבה יותר קל להעביר מכונה וירטואלית מפורמט VMware לפורמט KVM ולהריץ את אותה מכונה וירטואלית כמו שהיא – כקונטיינר.

הערה: הכלי נמצא במצב Preview והוא עדיין בפיתוח.

 

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

אני רוצה לחזור לימים שמיקרוסופט שחררו את Windows 95. הנה מערכת הפעלה חדשה, טענה מיקרוסופט, שיכולה להריץ ריבוי משימות מבלי שאפליקציה אחת תגרום לקריסת שאר האפליקציות שרצות! כולנו כמובן יודעים את האמת הפשוטה שאפליקציות בהחלט גרמו למערכת ההפעלה לקרוס כמו כלום, אפליקציות "בלעו" זכרון וניהול הזכרון היה די כושל, בוודאי כשמשווים זאת למערכות היותר מתקדמות שמיקרוסופט הוציאו שנים לאחר מכן כמו ה-NT 4.0 וה-2000 וכו'. הסיבה המרכזית לכך היתה כמובן כל הסביבה "מתחת" – DOS, שלא היתה ממש בנויה טוב לדברים כאלו, וה-Protected Mode שאינטל הוסיפה החל במעבדי i386 לא ממש עזר הרבה (אם כי לא באשמת אינטל).

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

מדוע אי נוחות מבחינת אבטחת מידע? כי הקונטיינר הוא לא יותר מאשר Process, שלא-כל-כך קשה "לצאת" ממנו אל ה-Host ומשם לחולל נזקים. רד-האט עם מערכת ה-OpenShift שלה לא מאפשרת (בברירת מחדל) לדוגמא לקונטיינרים לרוץ כ-root או להריץ בתוכה אפליקציות כ-root, וכל המערכת רצה עם SELinux מופעל (כ-Enforcing), כך שאם אתה מבטל SELinux, אין OpenShift. בפתרונות אחרים מבוססים Kubernetes חוסמים תקשורת בין ה-Pods, אבל זה לא תמיד יכול לסייע – במיוחד אם המערכת חשופה החוצה ומריצים מאות pods שמכילים Apache או NGINX לדוגמא.

לשם כך נצטרך קודם להיפטר מ-Docker.

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

במקום Docker, תכירו את CRI-O. (מבטאים "קריאו")

CRI-O זו מערכת חלופית ל-Docker שיודעת לבצע מה ש-Docker מבצע (ולכן היא תואמת ל-Docker), רק שהיא צורכת פחות משאבים, ואחד הדברים המעולים שיש בה הוא שניתן בעצם להגדיר קונטיינרים שאנחנו בוטחים בהם (Trusted) וקונטיינרים שאיננו בוטחים בהם (Untrusted) ולהריץ את 2 הסוגים במקביל, כאשר קונטיינרים שאיננו בוטחים בהם, ירוצו דרך מערכת QEMU כמכונה וירטואלית (sandbox) עם kernel קטן וכל השרותים הנחוצים להרצת קונטיינר. במילים אחרות – בשינוי קובץ YAML נוכל בקלות להקים את הקונטיינרים בצורה מופרדת או בצורה רגילה.

CRI-O מתחבר ל-Kubernetes בצורה חלקה ואינו מצריך הטמעת טלאים, וכמו כן CRI-O משתמש בשיטה של אינטל (שנקראה בעבר Clear Containers וכיום Kata Containers) כדי להריץ קונטיינרים בצורה מבודדת, אך שעדיין מאפשרת להשתלב בתוך אותם Namespaces לדוגמא.

להלן הדגמת וידאו קטנה איך עם CRI-O בשילוב Kubernetes מאפשר להריץ קונטיינרים שאנחנו מגדירים כ-Trusted ואיך משלבים קונטיינרים שאנחנו מגדירים כ-Untrusted ורצים בתוך סשן VM (לחצו מצד ימין למטה על האייקון עם החצים כדי לצפות בכל הטרמינל, הנגן לא יודע לבצע Scale לוורדפרס):

כפי שאנחנו יכולים לראות, השילוב רץ יפה מאוד.

לאלו המעוניינים לנסות את הדברים הללו, חשוב לשים לב לנקודות הבאות:

  • כרגע, לא ניתן להריץ את הדברים בענן ציבורי בתוך Instance רגיל אלא אך ורק בתוך Bare Metal Instances. כמו כן לא ניתן להשתמש ב-CRI-O בתוך שרותים כמו ECS.
  • אם אתם רוצים להריץ זאת בתשתית מקומית שלכם, ואתם מריצים Kubernetes על מכונות VM, יש להגדיר את אותן מכונות VM עם Nested Virtualization על מנת להריץ קונטיינרים Untrusted.
  • אם אתם רוצים לנסות את הדברים על מכונת הדסקטופ שלכם עם Minikube, יש להפעיל את minikube עם ההוראות כאן.
  • אם אתם משתמשים במערכת OpenShift (גירסה 3.11 ומעלה), ניתן להוסיף תמיכת CRI-O בנוסף לתמיכת Docker למערכת. ההוראות – כאן.
  • אם אתם משתמשים ב-CAAS של SuSE, בגירסה 3 ומעלה ניתן לבחור בין Docker ל-CRI-O. עוד פרטים ניתן לקרוא כאן.

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

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

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

על עננים ציבוריים ותקציבים

בשנים האחרונות חברות רבות עברו להשתמש בשרותי ענן ציבוריים, החל בשרותים של מיקרוסופט שהחליפו שרתי Exchange מקומיים (אופיס 365), העברת מכונות VM לענן, שימוש היברידי בתשתית מקומית ובעננים ציבוריים וכלה בשימוש בשרתים כפלטפורמות ושירותים (PAAS/SAAS). גם הבנקים, אחד הסקטורים הכי שמרניים שהשתמש בשרותי ענן יותר לצרכים שיווקיים – קיבל אישור מהרגולטור להשתמש ביותר שרותי ומשאבי ענן ציבורי.

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

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

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

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

נניח ואני חברה בשם X ויש לי חדר שרתים נחמד עם 5 ארונות, ו-100 שרתים פיזיים, תקשורת, סטורג', מיזוג וכו'. השרתים מריצים כ-1500 מכונות VM. נניח ועכשיו יש צורך להוסיף עוד 500 מכונות VM ויש לי משאבים פנויים בשרתים ובסטורג', אז תוספת העלות לחברה תהיה יחסית זניחה (אני לא מדבר כרגע על רשיונות פר OS כמו ב-Windows): עלות החשמל תהיה קצת יותר גבוהה. אם אצטרך לרכוש ברזלים כדי להקים את אותן מכונות VM, אז העלות שלהם תהיה עלות חד פעמית ואני יכול להשתמש בציוד הזה במשך 3-5 שנים בלי בעיה, אך בשורה התחתונה – ההוצאות הכספיות לגבי תוספת אותן מכונות VM הן צפויות.

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

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

  • "לחזור הביתה" – לתשתיות On prem
  • להתחיל לשוחח עם נציגי ענן מתחרה על שרותים זהים כמו שמשתמשים עכשיו אך במחיר יותר נמוך
  • קיצוץ מאסיבי בשימוש שרותי הענן, ואם משתמשים ב-Hybrid (כלומר On Prem ועננים) – לקצץ את השימוש בענן לצרכים הכרחיים בלבד.

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

מי שהסתכל בלינק יכל לראות שישנן תשובות שונות. אני אפרסם כאן את התשובות שלי:

  • בנוגע למעבר ל-On Prem ("חזרה הביתה") – אם מדובר על מכונות VM, אז זה אפשרי כמובן, אם כי סביר להניח שתקבלו אולי ירידה כלשהי בביצועים הואיל וספקי הענן בד"כ משתמשים במעבדים מהדור האחרון או זה שלפניו, בהשוואה ל-2-3 דורות אחורה שחברות משתמשות. בנוסף, תלוי בסיטואציה, יכול להיות שתצטרכו לרכוש ציוד נוסף כדי לארח את המכונות שמוחזרות מהענן.
    לעומת זאת – אם אתם משתמשים בשרותים שספקית הענן מציעה (RDS, S3, ELB ועוד שרותים רבים) – חלק מהם ניתן להקים מקומית בקלות (אם כי לא באותה שרידות – לדוגמא במקרה של S3) וחלקם מצריך משאבים ניכרים בכדי להקים משהו זהה רק ב-Scale קטן בהרבה (כמו Aurora), כך שבכל מקרה מדובר על הקצאת משאבים ניכרים שהולכים וגודלים ככל שהעברתם/הקמתם תשתיות וירטואליות בענן או שאתם משתמשים בשרותים המוצעים ע"י ספק הענן.
  • מעבר לענן מתחרה: "על הנייר" זה נשמע קל – מביאים את נציגי המתחרים, מבקשים מחיר נמוך וקרדיטים ואפשר לסגור חוזה. הבעיה בדרך כלל היא במימוש: אם אתם בנק ואתם משלמים מאות אלפי דולרים ומעלה פר חודש לספק הענן הנוכחי, אז ספק הענן המתחרה יקח על עצמו את כל ההקמה והעברת המכונות והנתונים אליו. אם אתם יותר קטנים – הספק המתחרה ישמח לתת לכם שרותי יעוץ (תרגום: אתם עושים את העבודה השחורה, הספק רק מייעץ תיאורתית ושולח לכם לינקים לתיעוד).
    משהו שחשוב לזכור: אין הבדלים רציניים במחירים בין ספקי הענן. הוא יכול נניח לתת לכם מחיר יותר זול על הקמת VM, אבל הוא יקח יותר על ה"דיסק" הוירטואלי, על רשתות תקשורת וירטואליות או על דברים אחרים, כך שלדעתי הסיבות היחידות לעזוב ספק ענן זה שרות גרוע, בעיות Downtime או שאין שרותים שאתם צריכים.
  • קיצוץ בשימוש שירותי הענן: אני יכול להבין בהחלט את אלו שרוצים את האופציה הזו, אבל חשוב לזכור (וזה רלוונטי אצל רוב ספקי הענן!) – אפשר להוציא לדוגמא 1000$ לחודש על פרויקט שרץ על הענן ואפשר במקרים רבים לעשות את זה אצל אותו ספק ענן ב-500$. הכל תלוי בידע של אותו אדם לגבי השרותים המוצעים על ידי אותו ספק ענן.
    סתם דוגמא מציאותית: התשתית שמציגה את הבלוג הזה (ובלוגים אחרים שלי ועוד כמה אפליקציות וניסויים שאני מריץ) לפני כשנה עלתה בסביבות ה-85$ לחודש. כיום אני משלם בחודש 26$. איך? צריך לדעת לבחור את השרותים, לראות מה השרותים החדשים שמוצעים, היכן ספק הענן הוריד מחירים, איך ניתן לבזר את הדברים, היכן כדאי לשלם מראש על משאבים מסויימים לתקופה ארוכה ולחסוך הרבה כסף, היכן ניתן להשתמש במשאבים זמניים כדי להריץ דברים שלא לוקחים זמן רב וזולים בהרבה ועוד ועוד. יש מספר חברות (כולל הח"מ) שמציעים שרות כזה, כך שלפני שמניפים את הגרזן – כדאי להתייעץ.

לסיכום: בלא מעט חברות שיש להם תשתיות בענן ציבורי מגיעים לפעמים סיטואציות שההנהלה דורשת חיתוך רציני בתקציב התשלומים לספק הענן. לא צריך להיכנס לפאניקה, תמיד אפשר למצוא פתרונות איך לקבל ביצועים נאותים תוך ביצוע שינויים שחוסכים מחיר ללא צורך ירידה לשימוש במשאבים בלתי מספקים (תמיד אזכור את אותו עסק שפנה אליי אחרי שקיבל חשבונית היסטרית על שרת SQL שהריץ באמזון ושבקושי נותן שרותים למישהו, אבל האינטגרטור הקודם החליט שזה רעיון מעולה להגדיר שה-SQL ירוץ על m5.4xlarge [כלומר 16 ליבות, 64 ג'יגהבייט זכרון!]).

תודה למשתתפי פורום Operation Israel על תשובותיהם.

כמה מילים על רד-האט 8 (BETA)

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

גירסת ה-Major האחרונה שרד-האט שחררה (גירסה 7.0) יצאה לשוק ב-9/6/2014 ולאחר מכן רד-האט שחררה עדכונים לגירסה זו וגרסאות קודמות, עדכונים שלא שברו תאימות בינארית כך שדברים לא השתנו, ובעולם האינטרנט – 4 שנים זה נצח.

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

רד-האט 8 עושה קפיצת דרך בכל אספקט אפשרי. גירסת ה-Kernel עוברת מ-3.11 לגירסה 4.18 (אני מנחש שזה יעלה ל-4.19). הקומפיילר משתדרג מספר גירסאות קדימה, ולראשונה ניתן ב-RHEL להוסיף Repositories ולהחליף גירסאות של אותה אפליקציה מבלי לעשות פעמיים פליק פלאק לאחור. לחובבי פייתון – רד-האט נוטשת רשמית את גירסה 2.7 ועולה לגירסה 3.6 (התקנת ברירת המחדל, אגב, אינה כוללת שום גירסת פייתון ב-RHEL-8). תחום התקשורת בין קונטיינרים מקבל שיפור בדמות תמיכת IPVLANS והתווספו כלים נוספים חדשים לבניה וניהול קונטיינרים, ניהול שרתים בצורה מרוכזת עכשיו יותר קליל ומסודר עם Cockpit (אגב, אני לא ממליץ להשתמש בו ככלי ניטור). משתמשים בקבצי Image בענן או מקומית? רד-האט משתמשת בכלי ידוע – Composer לבניית אימג'ים.

רד-האט שינתה כמעט כל פונקציה ושדרגה את כל האפליקציות שקיימות בהפצה. רד-האט 8 היא בעצם Fedora 28 ש-רד-האט לקחו כבסיס ומשם הם החלו לשפר ולייצב את המערכת על מנת לעמוד בכל המבחנים שיצרני תוכנה וחומרה שונים עושים לפני שהם מאשרים את ההפצה כנתמכת וכיציבה.

מכיוון שזו גירסת בטא ראשונה ציבורית, גירסה זו, סביר להניח, לא תעבוד ולא תריץ כמעט אף פלטפורמה אחרת של רד האט, כולל OpenShift, RHV/oVirt, Cloud Formation, Foreman ואחרים. במהלך החודשים החודשים שאר הכלים והפלטפורמות (מחוץ ל-RHEL-8) יתעדכנו ויתמכו בהפצה החדשה בגירסת הבטא. אם אתם רוצים להתקין אותה ולנסות אותה, אל תשכחו להירשם לרד-האט ולבצע Subscription על ההתקנה כדי שתקבלו עדכונים (ויש כבר ערימה).

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

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

ולמעוניינים לשרוף זמן או ללמוד מה השינויים ב-RHEL-8 – להלן קובץ ה-PDF.

Red_Hat_Enterprise_Linux-8-beta-8.0_Beta_release_notes-en-US