פרילאנס: חשיבות הלבוש בראיונות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

קצת על אחסון נתונים ונקודות חשובות לפני החלטה

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

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

אחד הדברים המעניינים שניתן לראות קשור לגודל החברה המעוניינת בפתרון: ככל שהחברה יותר גדולה והיא יותר "Enterprise" – היא יותר ויותר "נצמדת לפרוטוקול" – הם ירצו פתרון של יצרן ברזלים מסוים ופחות יסכימו לפתרון SDS (כלומר Software Defined Stroage) עצמאי – אלא אם יצרן הברזלים ימליץ על הפתרון. הם יעדיפו תמיכה במקום אחד (שרתים, סטורג'), מקסימום 2 (שרתים של יצרן אחד, סטורג' של יצרן מאוד ידוע) אבל לא מעבר לכך. ככל שהעסק יותר קטן – הדברים יהיו הפוכים (בכל זאת, צריך לחסוך). החריגה מהכללים אצל החברות הגדולות, אגב, מגיעה כשצריך אחסון של מעל 1 פטהבייט – פתאום הח"מ מקבל טלפונים בדיוק מאותם אנשים שהתנגדו לתוכן שכתבתי על סטורג' בבלוג זה.

לפני שאמשיך – הערה קטנה: תודות לחברות שונות (CRG, ווסטרן-דיגיטל, סופר-מיקרו ואחרות) השאלתי ציוד כדי להעביד אותו בפרך (Stress Testing) למשך חודש או חודשיים, 24/7 עם תעבורה רציפה מקסימלית (תקשורת/דיסקים, מעבדים, מאווררים, תלוי בטסטים המתבקשים) בהתאם לסטנדרטים של IEEE וארגונים אחרים על מנת לבדוק לחברות וארגונים שונים אם המפרט שהם מבקשים יכול לעמוד בעומסים שונים. כך שהדברים שיכתבו כאן – נוסו.

(בתמונה למעלה: לקוח שרצה לבדוק LACP של 12 פורטים עם תעבורת נתונים של 16 פטהבייט. המבחן עלה לו יותר מסוויצ' 10 ג'יגהביט Low End, אבל – הלקוח דורש ומשלם, אני לא אומר "לא".)

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

הבה נתחיל.

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

  • כמה אחסון נטו אתם צריכים? עזבו חישובים של RAID כזה או אחר, דחיסה, dedup ושאר ירקות. 2 האחרונים הם נחמדים, אך לא תמיד יתנו לכם את מה שאתם מבקשים (זה תלוי בתכנים).
  • כמה לקוחות (clients) הולכים להשתמש בזה? יש הבדל ענק בין אחסון שמשמש לכמה עשרות/מאות מכונות וירטואליות, כמה אלפי משתמשים פיזיים שמשתמשים באחסון כ-File Server או עשרות/מאות אלפי משתמשים דרך האינטרנט.
  • האם החיבור בין האחסון למכונות אחרות ישתמש בתקשורת מהירה? (FC במהירות 8/16 ג'יגהביט, תקשורת 10 ג'יגהביט קואקסיאלית, TwinAX, סיב, Infiniband וכו') והאם אתה צריך ציוד חדש לחבר את הכל ביחד (גם בצד של השרתים, גם מתגים, חיבור לסטורג' עצמו וכו')
  • אחריות, SLA ושאר נושאים פרוצדורליים.
  • והכי חשוב – יחס הקריאה/כתיבה וסוג התוכן.
  • דיסקים SSD שישמשו כ-Cache, שימוש ב-Cache כ-Tiering וכו'.
  • פתרונות של Synology או QNAP.
  • הרחבת אחסון, זכרון.

להלן הנקודות בפירוט:

  • אחסון נטו: נניח ואתה צריך 40 טרהבייט אחסון נטו. אם נשתמש במחשבון הזה תוכלו לראות ש-5 דיסקים של 10 טרהבייט יתנו לנו 40 טרהבייט אחסון נטו עם שרידות של דיסק אחד (כלומר RAID-5). מצד אחד זה יכול "לסגור פינות" שיש לנו כמות אחסון מספקת, וגם שרידות. הבעיה המרכזית: מהירות כתיבת נתונים ושליפתם. אין לנו שום האצה בכתיבת הנתונים, יש לנו האצה בקריאת הנתונים (שזה אידיאלי אולי לארכיבאות לדוגמא). בשביל לקבל האצה פי 4 בכתיבה ופי 8 (בהשוואה לקריאה/כתיבה מדיסק בודד) נצטרך 8 דיסקים של 10 טרהבייט ב-RAID-10. אם אנחנו רוצים מהירות קריאה/כתיבה יותר גבוהה בהרבה (X10 בכתיבה, X20 בקריאה) נצטרך לעבור מדיסקים של 10 טרה לדיסקים של 4 טרה בייט ולרכוש 20 כאלו (תגידו "היי" למארזי 4U). ככל שנבחר דיסקים יותר גדולים, כמות ההאצה שהמערכת תתן – היא יותר קטנה (לדוגמא: 10 דיסקים של 8 טרהבייט יתנו X5 בכתיבה, X10 בקריאה – הדוגמאות הם ב-RAID-10). טעות נפוצה, אגב, היא שימוש ב-RAID-5: הגדרות RAID-5 נותנת אפס האצה בכתיבה לאחסון.
  • לקוחות שהולכים להשתמש בסטורג'. אם מדובר על שרת קבצים לדוגמא, עניין המהירות הוא יחסית די שולי כי כולם משתמשים בתקשורת 1 ג'יגהביט שברוב הזמן מנוצלת חלקית, ואם מישהו יחכה עוד חצי שניה לשמירת קובץ האקסל שלו, השמיים לא יפלו.
    לעומת זאת – מכונות וירטואליות זה סיפור אחר לגמרי. פרוטקול כמו iSCSI הוא פרוטוקול "מפונק" ומערכת כמו VMWare לדוגמא דורשת אישור מהסטורג' על כל קבוצת נתונים שנרשמת, כך שאם אין איזה מנגנון ש"יאמר" ל-VMWare "קיבלתי, מאשר" בכל פעם ובאופן מהיר – המכונות הוירטואליות פשוט יזחלו בכל כתיבה. כיום ברוב פתרונות הסטורג' (סגורים ופתוחים) יש מנגנון שמטפל בכך, אבל אם תרימו מכונת לינוקס עם MDADM ל-RAID, זה לא יתן פתרון (אפשר לעקוף זאת על ידי ביטול ה-sync ב-ZFS לדוגמא, אבל זה מסוכן, במיוחד אם אין UPS למכונה).
    לכן, כשמדובר בסטורג' שיטפל בכל הקשור לאחסון מכונות וירטואליות, חשוב לבדוק שהסטורג' תומך ב-Sync On write, reclaim space, תמיכה ב-VAAI, VVOL ואחרים.
  • חיבור בין הסטורג' למכונות אחרת. הנה נקודה שרבים יתווכחו עליה מתוך איזה נסיון שיש להם, מתוך אמונות, מתוך שמועות, אך כמו שכתבתי למעלה – הנקודות נוסו על ידי הח"מ בתנאי Extreme.
    חיבורי ה-FC היו מעולים לזמנים שהתקשורת נחושת היתה במהירות 1 ג'יגהביט וחיבורי 10 ג'יגהביט היו יקרים מאוד. כיום, לעומת זאת, ישנם 5 אפשרויות פופולריות:

    • CAT6/CAT-6E – חיבורי נחושת של 10 ג'יגהביט, עובדים מעולה ואם רוצים, אפשר לעבוד עם LACP (או Bridge) בצוותים של 2 חיבורים לדוגמא לקבל מהירות יותר גבוהה. היתרון: עלות זולה יותר של כבלים וסוויצ'ים.
    • +SFP עם TwinAx (נקרא גם DAC) – עובד מעולה למרחקים קצרים (עד 5 מטר). חשוב לשים לב שהחיבורים יהיו מאותו מותג של הסוויצ' (בסוויצ'ים 10 ג'יגהביט בקצה הנמוך זה לא רלוונטי, הם מתעלמים מה-Branding Tag).
    • +SFP עם סיבים אופטיים – את זה כולם ימליצו. לא חוכמה 🙂
    • +QSFP – כמו ה-+SFP רק למהירות 40 ג'יגהביט. מדובר בחיבור פיזי גדול יותר כך שהוא אינו תואם אחורה. קיים גם כגירסת DAC/TwinAX וגם כחיבור עצמאי שאליו מחברים סיב אופטי.
  • אחריות, SLA וכו' – כל יצרניות השרתים מוכרות כיום פתרונות סטורג' (ברזלים יעודיים או תוכנה לשימוש בשרתים עצמם) משלהם, אך יחד עם זאת הן גם "מכשירות" (Certified) תוכנות אחרות, ובדרך כלל ביקור באתר יצרן תוכנת הסטורג' יראה את הלוגואים של היצרנים שנתנו "הכשרה" לתוכנת הסטורג', כלומר אם תפנו לתמיכת יצרן השרתים, אף אחד לא יעקם את האף מדוע אתם משתמשים בתוכנת סטורג' X. בחלק מהמקרים (תלוי בחוזה התמיכה) אולי יסייעו לכם עם תוכנת הסטורג' צד ג' או יפנו את בקשת התמיכה ליצרן התוכנה (במקרים בהם יצרן השרתים [כמו HPE] מכר לכם חוזה תמיכה על כל הציוד והתוכנות שברשותכם).
  • SSD, Caching: בכל סטורג' המשלב דיסקים מכניים ודיסקים SSD – המערכת תורכב מ"שכבות" (או במושג המקצועי: Tiering), כאשר השכבה המהירה מורכבת מהדיסקים SSD והשכבה האיטית יותר מדיסקים מכניים (SAS או SATA). ישנם כמובן סוגי סטורג' שונים שבהם יש עוד שכבות כמו מדף זכרון מגובה סוללות, NVRAM, או שכבות של דיסקים מכניים מהירים ובשכבה מתחת דיסקים SATA במהירות 7200 RPM.
    בכל המקרים הללו, ה-SSD נועד "להחביא" את הדברים הקשורים לכתיבה. הוא מקבל את ה-DATA ולאחר מכן ה-DATA מופץ לשכבות היותר איטיות, והוא גם מאחסן נתונים שנקראים תדיר (נניח יש לך 10 מכונות לינוקס, כולן רפליקציות מלאות או משורשרות – רוב הסיכויים שה-DATA יקרא מה-SSD). ה-DATA עצמו לא נכתב ישר אל הדיסקים המכניים, אבל הסטורג' מציג את הדברים כאלו שהנתונים כן נכתבו למכניים, והסטורג' ברקע עושה זאת.
    במערכות יקרות יותר (מילת קסם: AFA או All Flash Array) ישנם גם שכבות אם כי טיפה שונות: רוב הדיסקים הם Read Intense וחלק קטן מהם Write Intense או Mixed Intense ולפעמים יש שימוש ב-NVRAM או בזכרון מגובה סוללה (נדיר). במערכות הסופר-סופר-יקרות, מכניסים גם Optane, גם כרטיסי FPGA ודברים נוספים כדי להאיץ את הכל (ועוברים בדרך לפרוטוקול ה-RDMA הוותיק) – כמו במערכות NVMEoF לדוגמא.
  • פתרונות של Synology או QNAP: אלו פתרונות שאני יכול להמליץ עליהם בלב שלם כפתרונות לשמירה/קריאה של מידע, פחות למכונות וירטואליות (אם כי ל-LAB קטן הם בהחלט יכולים להספיק). כיום בכל QNAP או Synology ניתן להוסיף דיסק SSD לקבלת Cache בסיסי, אבל אל תנסו להכניס לשם SSD מסוג Optane  לדוגמא (כמו שינוי QD) – בשביל זה יש צורך לשנות כמה וכמה דברים בלינוקס ואין במכשירים הללו לא את הספריות ולא את האפשרויות לשנות פרמטרים.
  • הרחבת אחסון, זכרון: בכל מה שקשור לזכרון, רוב הסטורג'ים שמבוססים לינוקס/BSD/סולאריס ו/או ZFS ישתמשו בזכרון כ"מאיץ ראשי" לקבלת הנתונים ולשחרר את צוואר הבקבוק, כך שאם אתם יכולים להשקיע ברכישת RAM – מה טוב.
    לגבי הרחבת האחסון עצמו: בסטורג' סגור הפתרון תמיד יגיע עם "מדפים" לאחסון הדיסקים. בסטורג' פתוח לעומת זאת, חשוב לבדוק שיש חיבור מאחורה המאפשר לחבר JBOD אחד או יותר על מנת להוסיף קופסת JBOD או יותר עם דיסקים ומומלץ לבדוק שהחיבור הוא SAS-3 (נקרא גם HD MINI-SAS או בשמו המקצועי: SFF-8644). לפני שנתיים שוחרר סטנדרט שנקרא SAS-24G אך אני לא ממליץ לרכוש אותו הואיל ודיסקים קשיחים עתידיים (כמו אלו עם 2 מנועים שאמורים לצאת בשנה הקרובה/שנה הבאה) עוברים להשתמש בחיבור NVME. ה-24G פיספס את הרכבת.

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

ההכרזה של אינטל על חומרה חדשה

אינטל לאחרונה הכריזה על שורת מוצרים חדשים – משפחת מעבדי ה-Xeon Cascade Lake שמהווים שדרוג למשפחה הנוכחית, Xeon Scalable. אלו שרוכשים שרתים מ-Dell יוכלו להתחיל לרכוש את הדור הבא של השרתים (סידרת ה-R650,750 וכו') בשבועיים הקרובים (לפחות בחו"ל). חברת HPE עוד לא הכריזה על תאריך השקה וגם לא לנובו. בסיסקו הולכים להוציא את המשפחה החדשה בערך בעוד חודש וחצי. בהשוואה למעבדים הנוכחיים, המעבדים החדשים יהיו קצת יותר מהירים אך באותו מחיר כמו הקיימים, וניתן יהיה (לאחר עדכון BIOS) להחליף את המעבדים הנוכחיים במעבדים החדשים. פוסט יותר מפורט על המעבדים החדשים (כולל רשימת המעבדים) – יופיע פה בבלוג בקרוב.

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

נתחיל בדיסק ה-SSD החדש של אינטל, ה-DC D4800X (תבדילו בינו ל-P4800X). ה-D בשם המוצר מסמן Dual Port. זהו SSD בחיבור NVME כפול. בשביל מה צריך כפול? כדי לקבל שרידות כמובן!…

אממה .. מישהו שכח או התעלם מכלל פשוט שקיים בכל PC, החל מלאפטופ ועד שרת עצבני עם 8 מעבדים: כשיש לך תקלה בחיבור PCIe, המערכת פשוט תקפא או תקרוס. לגמרי. נסיון לבצע כיבוי/הפעלה מחדש לא יצליח לעבור את ה-POST. (בעקרון, כשמפעילים את המכונה, לאחר שהמעבד הופעל וה-BIOS נכנס לשליטה, הוא מריץ את המיקרוקוד שבתוכו, הוא מתחיל לאפס את תושבות וציודי ה-PCIe. כשהוא לא מצליח – תופיע שגיאה שלא תאפשר המשך הפעלת המכנה). במילים אחרות – זה ציוד מעולה .. אם יש לכם Mainframe של IBM, שם אפשר להחליף כמעט את כל הציוד שהמכונה פעילה (וניתן להפעיל/לכבות תושבות PCIe בזמן ריצה) – אבל לא כל כך רלוונטי בשרתים.

מכאן – נעבור ל-Optane DC.

למי שלא מכיר – Optane DC זו גירסת SSD שאינה מתחברת לתושבת PCIe אלא יושבת בתוך תושבות הזכרון של השרת. בתמונה משמאל תוכלו לראות אותם כ"מקלות זכרון" (עם המדבקות, כלומר 3 מקלות Optane DC ו-3 מקלות זכרון DDR4 ECC). כל מקל Optane DC מגיע ב-3 גדלים – 128, 256 או 512 ג'יגהבייט אחסון! (המחירים, אגב, לאלו שרוצים לדעת – ואלו לא מחירים סופיים: 893, 2461 דולר וה-512 ג'יגהבייט עדיין לא יצא). אלו אינם מקלות זכרון, כך שאם יש לך מול מעבד כ-256 ג'יגה זכרון והכנסת מקל Optane DC של 256 ג'יגהבייט, לא יהיה לך זכרון של כחצי טרה, אלא 256 ג'יגה זכרון ו-256 ג'יגה של אחסון מהיר.

בכנס Ignite האחרון, מיקרוסופט הדגימה איך ה-Optane DC עוזר בסביבת HCI שמורכבת מ-Hyper-V, Storage spaces direct וכו'. להלן הוידאו:

שימו לב למשהו אחד חשוב שקצת פחות מודגש בוידאו: כל ה-Optane DC שבשרתים בהדגמה משומש ל-Cache בלבד ולא כ-Storage! במילים אחרות, גם אם תכניס טרהבייט של Optane DC בשרת, עדיין תצטרך Storage כלשהו, ולכן השימוש של Optane DC יותר מתאים כ-Cache ל-DB או למכונות וירטואליות. ניתן לראות את הדגש הזה גם במסמך הזה שהוציאה VMWare שמתייחסת ל-Optane DC ולגירסה עתידית של vSphere.

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

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

אחד המוצרים הנוספים שאינטל הכריזה עליו הוא Intel SSD D5-P4326 – כונן SSD בתצורת "סרגל" (שמו הטכני של הסטנדרט: EDSFF E1.L – שם שממש מתגלגל בפה). כל סרגל SSD כזה יכיל בדור הנוכחי עד 15.32 טרהבייט אחסון… רק לפני שמתלהבים, האחסון מורכב מ-QLC NAND, הווה אומר שבתא NAND אפשר לאחסן 4 ביטים, מה שמאפשר לאחסן יותר מידע פר תא, אך מצד שני, מהירות הכתיבה – איטית מאוד בהשוואה לכונני SSD מדור נוכחי מבוססי TLC (כלומר 3 ביטים בתא). אינטל ושותפיה ימכרו שרת 1U שבו יהיה ניתן להכניס 32 סרגלים כאלו ליצור אחסון עד כמעט חצי פטהבייט שמיועד יותר לאחסון מידע לקריאה, ובמילים אחרות – לא מאחסנים על זה מכונות וירטואליות, קונטיינרים ושאר דברים שמצריכים קריאה/כתיבה מהירה יותר ממה שאותם סרגלי SSD יכולים להציע.

הבעיה המרכזית במוצר היא התחרות שלו מול דיסקים קשיחים מכניים. נכון, SSD נותן מהירות קריאה הרבה יותר גבוהה מכל דיסק מכני, אבל דיסק מכני כמו Seagate Baracuda בגודל 14 טרהבייט ל-Enterprise עולה בסביבות ה-550$ ואילו סרגל של 15.3 טרהבייט של אינטל עולה פי 8. את עניין הבדלי הקריאה/כתיבה ניתן תמיד לפתור בעזרת מספר דיסקים SSD שישמשו ל-Cache כך שהפתרון של אינטל עדיין אינו שווה לדעתי מבחינה כלכלית.

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

על דיסקים מכניים גדולים ו-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 והוא עדיין בפיתוח.