על OpenShfit, הטמעה וציפיות בחברות

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

חלק לא קטן מהטענות ששמעתי הגיעו מצד גופים שחשבו ש-OpenShift זה כלי עם GUI מרשים ל-Kubernetes. הנחה זו היא די מוטעית. אם מחפשים GUI וכלי ניהול בשביל Kubernetes, אפשר להסתכל על מוצר בקוד פתוח שלא עולה כלום כמו Rancher. לעומת זאת, Openshift זה כלי שבא לתת לך הכל ללא צורך בהזדקקות לשרותים חיצוניים מהאינטרנט כמו Containers Registry וכו'.

על מנת להבין יותר את התפיסה של OpenShift, נדמיין סיטואציה אחרת לחלוטין: יש לנו 10 מפתחי JAVA ויש לנו שרת לינוקס גדול ורציני. למפתחים יש משתמש משלהם (נניח דרך אוטנתיקציית AD) על שרת הלינוקס ועל השרת מותקן באופן מרכזי ה-JDK וכלים אחרים שהמפתחים משתמשים, וכל מפתח יכול לבצע login ולבצע checkout מה-GIT המרכזי ולהריץ את האפליקציות JAVA שלו. אין צורך שיהיה לו ידע בניהול מערכת לינוקס, אבל מומלץ שיהיה לו ידע ממש בסיסי ב-BASH, ודברים פשוטים אחרים שאפשר ללמוד בשעה שעתיים – בשביל להריץ את מה שהוא כתב. מי שינהל את שרת הלינוקס מבחינת הגדרות, עדכונים וכו' – תהיה מחלקת ה-IT בחברה. לחובבי Windows אפשר לדמיין את הסיטואציה כשרת Windows שנותן שרותי RDP וכל משתמש נכנס עם המשתמש המאושר שלו והוא עושה מה שהוא צריך לעשות. הידע שהוא צריך – הוא שימוש בסיסי ב-Windows, לא יותר מזה.

השוני הכי גדול בין Kubernetes ל-OpenShift מבחינת כל מה שקשור לקונטיינרים – היא הגישה. ב-Kubernetes אם אני רוצה לבצע Deploy, לבצע Scale, רפליקציה, כתיבת שרותים ודברים רבים אחרים – אני צריך לכתוב קבצי YAML (או JSON) שאותם אני צריך להזין ל-Kubernetes ואני צריך גם לבדוק לוגים כדי לראות שכל רץ תקין, ולכן בחברות שמשתמשות ב-Kubernetes רוב העבודה הזו נופלת על איש ה-Devops. לעומת זאת, עם OpenShfit, הדברים בנויים יותר בכיוון שרת הלינוקס וה-JAVA. עם OpenShift אני מגדיר משתמשים (ומחבר את OpenShift ל-AD על מנת לשמור על סינכרון שם משתמש/סיסמא/הרשאות) ואותו מפתח יכול להריץ דברים ישירות דרך ה-CLI או ה-GUI ויש לו כלים מוכנים כדי שהוא לא יצטרך לשכתב קבצי YAML כדי לבנות קונטיינרים עם הקוד שלו בתוך ה-OpenShift. אם הוא רוצה לבצע לדוגמא Scale או Deploy, הוא פשוט יכול ללחוץ כמה קליקים ולהשתמש ב-Template מוכן, לתת שורת כתובת של ה-GIT שלו, ותוך דקות ספורות ה-POD עם הקונטייר/ים שלו ירוצו, הוא יכול לראות מתוך ה-GUI את הלוגים ואף לקבל גישת טרמינל מוגבלת לתוך הקונטיינר כדי לבדוק אם הכל תקין וכו' וכו' ואם הוא רוצה לשמר את מה שהוא עשה בתור קובץ YAML/JSON, המערכת תשמח ליצור עבורו את הקובץ הנ"ל.

לכן, מבחינת חברה, OpenShift עושה את החיים יותר קלים מבחינת הטמעה ושימוש בקונטיינרים, ניהול תשתית המכונות המריצות את OpenShift ואת הקונטיינרים עצמם, כלומר הצורך במישהו יעודי רק כדי להריץ דברים בקונטיינרים פוחת ואפשר להוציא זאת לשרות חיצוני או ללמד את צוות היוניקס/לינוקס את הדברים הדרושים, ובנוסף קל לראות אם ישנן בעיות בתשתית ה-OpenShift (מערכת Heapster נותנת גרפים עשירים פר Node, פר POD וכו' וכו', וגם ניתן לחבר את OpenShift ל-ELK, גרפאנה ושאר החברים). בנוסף, מכיוון ש-OpenShift מבוססת על Kubernetes, ניתן ליישם את מה שרץ על OpenShift על מערכת Kubernetes במקרים לדוגמא בהם הוחלט ש-OpenShift ירוץ בפיתוח ו-Kubernetes או פתרון תואם רץ בפרודקשן (אם כי זה קצת יותר מורכב).

ונקודה אחרונה לגבי מחיר: אני מכיר כמה מנהלי IT ששמעו את המחירים של רד-האט ולסתותיהם נשמטו. נכון, מחירים פר Node אינם בדיוק זולים, אולם המחיר יורד לחמישית אם מריצים את ה-Node כמכונת VM ומעוניינים להריץ את הגירסה המסחרית. חוץ מזה שאישית – אני ממש לא ממליץ להריץ את OpenShift על "הברזל" אלא אם יש שם למחלקת ה-IT ידע ממש עמוק ורציני בלינוקס, אחרת אפשר להפיל Node (ולא חשוב אם זה Node לעבודה או Master) די בקלות. בכל זאת, לא מדובר על הפעלת Cluster קונבנציונאלי עם HeartBeat, PaceMaker וכו'.

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

נקודות חשובות בשדרוג ל-CentOS 7.4

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

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

כמו תמיד, בגרסאות עדכון Minor ישנם שינויים רבים בהפצה, אך שינויים אלו עדיין שומרים על תאימות בינארית, תאימות קבצי הגדרות וכו'. יחד עם זאת, בחלק מהמקרים מעדיפים ברד-האט (ונגזר מזה גם ב-CentOS) לשדרג חבילות מסויימות לגרסאות Major מתקדמות יותר ובלבד שתשאר התאימות. הסיבה לכך היא שהפצת לינוקס (בניגוד לגירסת Windows) כוללת אלפי חבילות (וזאת לפני הפעלת מאגר תוכנות מומלץ כמו EPEL) ואין לרד-האט את המשאבים לעקוב אחרי כל החבילות וליישם Backporting של עדכוני אבטחה. ברד-האט בודקים אם ישנן פריצות ידועות ואם הפריצות נחסמו בגירסה יציבה מתקדמת יותר, גירסת העדכון הבאה תכלול את הגירסה המתקדמת יותר (מה שנקרא בשפה המקצועית "Rebase").

ב-רד-האט שחררו מסמך ארוך לגבי השינויים ברד-האט 7.4 (וכמובן כל הדברים נמצאים ב-CentOS 7.4) שנמצא כאן ומאוד מומלץ לקריאה לפני שדרוג שרתים. ישנם שינויים כמעט בכל תחום, Kernel עם עדכוני מודולים, תמיכה בדרייברים חדשים, חבילות בגירסאות חדשות (ה-Rebase שהזכרתי לעיל). בלינק לעיל תוכלו למצוא את ה-General Updates שמדבר בכלליות על השינויים ומתחתיו פירוט לגבי השינויים.

ברוב המקרים, הרצת yum update תשדרג מערכת מכל גירסה קודמת (7.0, 7.1 וכו') לגירסה האחרונה בלי הרבה בעיות, אולם ישנם מקרים בהם השדרוג יכשל או יותר חמור – המכונה/VM לא תצליח לעשות Boot או לא תצליח להפעיל תקשורת דרך כניסות התקשורת הרגילות/וירטואליות.

להלן כמה נקודות חשובות שכדאי לשים אליהן לב לפני שמשדרגים לגירסה 7.4:

  • אם אתם משתמשים ב-iptables וב-ip6tables (הראשון מיועד ל-IPV4 והשני ל-IPV6, הן מותקנות כברירת מחדל בהתקנה רגילה). אם אתם מפעילים את שתיהם, יכולות להיווצר בעיות של תקשורת. הבאג מתוקן ב-CentOS 7.4 בחבילה iptables-1.4.21-18.0.1.el7 אך הוא עדיין לא מתוקן ברד-האט 7.4. הפתרון המומלץ כרגע – להפעיל רק אחד מהם ולבטל את השני (בעזרת פקודת systemctl disable).
  • אם אתם משתמשים ב-Xen, מכונת VM של CentOS 7.4 עם דרייברים Paravirtualized – ה-VM לא יצליח לבצע BOOT וכרגע הפתרון הוא HVM (או PV-on-HVM). תיקון לכך יצא בקרוב.
  • במקרים מסויימים הרצת yum update תתקין חבילות i686 ולא X86-64. הבעיה מתרחשת עקב התקנת RDMA. אם אתם משתמשים ב-RDMA, מומלץ להריץ yum install rdma-core && yum update. אם אתם עדיין רואים בעיה, מומלץ להריץ yum install rdma-core ibacm. 
  • אם אתם רוצים להתקין VirtualBox על תחנת עבודה שתריץ כ-host את CentOS 7.4, תצטרכו להתקין את גירסת VirtualBox 5.1.28 מהאתר. גירסה 5.1.26 לא תעבוד.
  • משתמשים ב-VMware ורוצים להקים VM מבוסס CentOS 7.4? עקב שינויים שרד-האט ביצעו בקרנל, התקשורת הוירטואלית לא תעבוד. יש צורך בהתקנת Patch ל-VMware tools. לפרטים – כנסו ובצעו את ההוראות בקישור הזה.
  • חבילת ה-initramFS הרבה יותר גדולה מבעבר, ולכן אם מחיצת ה-boot/ שלכם קטנה מ-1 ג'יגהבייט, תצטרכו להרחיב אותה לפני השדרוג ל-7.4 לפחות לגודל 1 ג'יגהבייט (אני ממליץ להרחיב לגודל 5 ג'יגהבייט אם הנכם מתקינים מספר גרסאות קרנל).
  • יכול להיות ששרות SAMBA יפול עם השגיאה symbol krb5_get_init_creds_opt_set_pac_request, not defined. במקרים כאלו יש להתקין את חבילת  krb5-libs-1.15.1-8.el7 ולהפעיל את שרות SAMBA מחדש.
  • ועוד בעניין SAMBA – אם אתם עובדים עם אותנטיקציית SSSD ומאפשרים SHARE, זה לא יעבוד. כרגע האפשרות היחידה היא לשנמך לגירסה שקיימת בסנטוס 7.3. כרגע רד-האט עובדים על הבאג הזה.
  • נדיר, אבל ראיתי מקרים שזה קורה: אתם מפעילים את ה-CentOS ואין תקשורת עד שאתם מבצעים Login או שהתקשורת לא מופעלת בזמן Boot. במקרים כאלו, עקבו אחר ההוראות כאן.
  • החל מגירסה 7.4, מינימום זכרון שנדרש עבור המערכת הוא 1 ג'יגהבייט. במקרים שאתם רוצים להריץ את ה-ISO כ-LIVE, יש צורך בלפחות 1.5 ג'יגהבייט זכרון.
  • עוד בענייני VMWare: אם אתם מגדירים ידנית VM לשימוש עם CentOS 7.4, אל תנסו לבחור דרייברים SCSI אלא אך ורק את ה-Paravirtualized. דרייברים ל-SCSI ש-VMWare השתמשו כבר לא קיימים בקרנל הזה.
  • אוהבים את פקודת ifconfig ו-netstat? תתכוננו לשכוח מהם. הם מסומנים כ-Deprecated והם אינם מותקנים כברירת מחדל עם CentOS 7.4, ולכן אם הרשת שלך לא עלתה, השתמשו בפקודת nmcli כדי להפעיל את כרטיס הרשת ואז תוכלו להתקין את החבילה (ותתכוננו לשנות סקריפטים שמשתמשים בפקודות הנ"ל).
  • בסנטוס 7.4 מותקנת גירסה חדשה של sudo שמשתמשת ב-var/db/sudo/lectured/ ולפיכך ההתראה הראשונה שמשתמשים ב-sudo (עם האזהרות וכו') תופיע מחדש לכל המשתמשים ב-sudo לאחר שדרוג לסנטוס 7.4.
  • אם אתם משתמשים ב-CentOS 7.4 עם GNOME, יכול להיות שמנהל הקבצים (Nautilus) יראה את האייקונים מאוד גדולים. הפתרון הוא להריץ את הפקודה: gsettings set org.gnome.nautilus.icon-view default-zoom-level 'small' ולבצע lougout ולאחר מכן login.
  • אם אתם משתמשים ב-CentOS 7.3 (או גרסאות 7 קודמות) ואתם מריצים על זה OpenLDAP ואתם מתכוונים לשדרג, יש לבצע את ההוראות בלינקים כאן וכאן או שתהיה לכם בעיה רצינית עם ה-OpenLDAP. בכל מקרה אם מדובר ב-VM, בצעו snapshot לפני כן.

בכל מקרה, תמיד מומלץ להסתכל בדף ה-Errata של רד-האט ולוודא שאין עדכונים שלא התקנתם או שלא שמתם לב אליהם.

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

הפריצה ב-Equifax והבעיות ב-Enterprise

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

מקור הפריצה גם ידוע: בחברה השתמשו בפלטפורמת פיתוח Apache Struts המאפשרת פיתוח אפליקציות WEB ב-JAVA בקלות. חור האבטחה התגלה וטלאי תיקון שוחרר במרץ, אבל ב-Equifax לא ממש טרחו להטמיע את הטלאי, מה שנוצל בחודש מאי כדי לפרוץ ולגנוב את הררי המידע.

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

וכאן בדיוק מתחילה הבעיה..

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

אבל ישנם 2 בעיות בסיסיות ששום טכנולוגיה כמו FW/IPS/WAF וכו' לא ממש יכולות לפתור.

נתחיל בבעיה היותר קלה לפתרון שרובם כלל לא מיישמים. אני קורא לה "סימוכין עיוור" – שורת שרתי אפליקציה פנימיים מתחברים ל-SQL כלשהו ושולפים מידע. בד"כ אתר מבוסס Web או אפליקצייה וובית או אפליקציית מובייל – יעבירו בקשות מהאפליקציה או מהשרתי Front End לשרתי Back End, שרתי ה-Back End יתשאלו את ה-SQL, יבצעו סינון/סידור פלט ויעבירו את הנתונים בחזרה לשרתי Front End או אפליקציה. עד פה הכל טוב ויפה, וכאן יש לנו "סימוכין עיוור" – מכיוון שכל השרתי Back End ושרת ה-SQL נמצאים בכתובות פנימיות, אין שום מגבלה לכמות השאילתות (ובמקרים מסויימים גם אין סינון שאילתות) ששרתי ה-Back End יכולים לשלוח אל ה-SQL ולהעביר הלאה את המידע. שאילתה אחת או מיליון – זה אותו דבר. ה-IPS או ה-WAF יכולים להגן נגד שאילתות רחבות (ה-*), וכך בדיוק נגנב המידע מ-Equifax (מבלי להיכנס לכל הפרטים הטכניים של הפריצה).

הבה נדגים זאת: חברת תקשורת סלולרית מפעילה מוקד שרות לקוחות. מחשבי פקידי השרות לקוחות מריצים אפליקציות ווביות שמתשאלים ה-SQL נון סטופ לגבי פרטים על הלקוחות והפקידים גם מבצעים שינויים בפרטים (שינוי חבילה, חסימת מספר, שינוי פרטי לקוח ועוד ועוד). האם יש איזו מגבלה של כמות שאילתות פר PC? סביר מאוד להניח שלא וסביר להניח שגם לא נמצא מגבלה כזו גם באפליקציה הסלולרית או באתר החברה, וכך יוצא מצב שאם מאן דהוא פורץ ואני מוצא פריצה בספריה שהחברה משתמשת כדי לבנות את האפליקציית Web – אני יכול להקים מספר מכונות VM אצל ספקי ענן שונים (או יותר גרוע – כמה עשרות קונטיינרים פר VM) – הפורץ יכול לתשאל דרך החור שהוא מוצא את ה-SQL שאלות ובעזרת סקריפט שהוא יכול לבנות – הוא יכול לשאוב את המידע מה-SQL, ועד שהחברה תעלה על כך – הפורץ כבר יעלם לו (אחרי הכל, כשפתוחים חשבון אצל ספקי ענן, ספק הענן אינו מחטט בציציות הלקוח – כל עוד יש ללקוח כרטיס אשראי כלשהו [גם אם מדובר בכרטיס חד פעמי או אפילו קרדיט שהתקבל מביקור בכנס]), אף אחד לא יעצור את אותו פורץ לעשות כרצונו, ואם הוא רוצה – הוא יכול לעשות את הכל דרך VPN או הקמת VPN על ספק הוסטינג נידח כלשהו. בהצלחה במציאת הפורץ.

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

כיום רוב העולם כבר למד לעבוד עם תוכנות/ספריות/פלטפורמות חיצוניות שמדיניות עדכוני האבטחה שלהם לא תמיד ברורה והם אינם כלולים באיזה Repository של הפצת לינוקס. יש כיום את Github שבמקרים רבים יכול להציל מפתחים ואנשי IT עם פרויקטים שאנשים כתבו והעלו ורבים משתמשים בכך כדי לפתור בעיות וכדי לממש דברים שונים, אולם כלי ה-IPS לדוגמא לא ממש מגלים חורי אבטחה וכלי סריקה לא ימצאו את החורים כי לפעמים אין CVE לחור אבטחה לכלי שמישהו פיתח, העלה ל-github ושכח בכלל מהפרויקט לאחר זמן מה. יותר מכך – במקרים רבים ההטמעה עצמה מוטמעת עם הרשאות שגויות (ברמת Administrator או root), עם הרשאות קבצים שגויות, או שפתחו יוזר ב-SQL ברמת "הכל כלול" (רוצים דוגמא? לכו תבדקו בחברה אלו הרשאות ה-Jenkins מותקן ורץ. הוא לא אמור לרוץ כ-root).

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

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

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

החלוקה

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

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

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

התשובה: אני מעריך בין 1 ל-2. להלן הסיבות מדוע המספר נמוך:

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

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

  • "לא בטוח שרלוונטי" – במקרים אלו הסיכויים לקבלת שכרך ובזמן אינם כה גבוהים. דוגמאות:
    • אתה מבקש מחיר של 200 ש"ח + מע"מ לשעה, הם מוכנים לשלם לך .. 50 ש"ח לשעה או שהם מוכנים לשלם לך באחוזים וירטואליים תמורת "שותפות", ושאר ירקות.
    • הצעות מפוקפקות – הם מוכנים לשלם לך פחות או יותר את מה שאתה מבקש אבל הכסף לך יגיע לחשבונך מחו"ל וינכו משכרך כמה עשרות דולרים על כך, או שתנאי התשלום אינם ברורים.
    • תשלום שכר בסימן שאלה – הסטארט-אפ ישמח לשלם לך… ברגע שימצאו משקיע/אנג'ל. עד אז תקבל חלק קטן מהשכר שביקשת.

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

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

אז מה ניתן לעשות בנידון? איך ניתן להשיג עוד עבודות? להלן מספר נקודות חשובות:

  • פרסם עבודות שאינן מתאימות לך. אתה מומחה בפייתון ומישהו מחפש מתכנת ++C? קח את פרטיו ופרסם את פרטי ההצעה (אתה יכול לפרסם כאן וכאן).
  • עדיין לא הומצאה מכונה לקריאת מחשבות ואיש אינו יודע אם אתה במצב של 0 עבודות או שאתה מחפש עבודות, מחפש עבודה קבועה לחצי משרה, מחפש משרה מלאה לטווח ארוך וכו'. אל תתבייש, תפרסם זאת! (הח"מ מחפש לחצי משרה 🙂 ), זו הדרך הכי מהירה שחברים ישתפו זאת וסיכוייך לקבל משרה כך אינם נמוכים.
  • פרסם תכנים משלך על התחומים שאתה נותן בהם שרות(ים) ומדי פעם תבצע קצת SEO כך שגוגל יעלה את דירוג הבלוג/אתר שלך.. להלן דוגמא על קונטיינרים:

  • הדגם את יכולותיך. קל לדבר ולכתוב על דברים אבל אם יש משהו שמושך אנשים להתעניין בשרותיך – הם הדגמות של הדברים. התקנה של דברים מאפס, הגדרות שונות, הסברים איך מפעילים דברים וכו'. כל מה שאתה צריך זה חשבון בגוגל, מיקרופון ותוסף Nimbus לכרום (ניתן להתקנה מכאן). להלן דוגמא:
  • כרטיסי ביקור – נפגשת עם מישהו? אתה ב-Meetup ומשוחח עם אנשים? חלק כרטיסים, אולי יחזרו אליך. אל תשאיר אנשים עם תהיה "הבחור שפגשתי רציני, חבל שאין לי את הפרטים שלו".
  • הסעיף הבא נתון למחלוקת ביני לבין חבריי אך אני עדיין עומד על שלי: אם אתה טוב בתחומך, שקף זאת במחיר שאתה גובה. הנה כמה דוגמאות למחירים שמהם לא כדאי לרדת (תחום סיסטם/Devops/אינטגרציה/יעוץ). תזכרו שכעצמאים המדינה עושקת אותנו בכל מצב:
    • עבודה חד פעמית חרום לתיקון תקלה (מעכשיו לעכשיו) – לא פחות מ-300 שקל
    • חצי משרה קבועה – לא פחות מ-150 שקל
    • משרה מלאה קבועה (תשלום כנגד חשבונית, לא תלוש משכורת) – לא פחות מ-120 לשעה
    • יעוץ מומחה – פר שעות (בד"כ לוקחים מינימום שעה או שעתיים) – לא פחות מ-200 לשעה
  • "לחפור" קצת. הגעת ללקוח שרוצה ממך עבודה X. בדוק אם יש עוד דברים שאתה יכול לעשות עבורו ובכך להרחיב את העבודה או כמות שעות העבודה.
  • חשוב: דרוש מקדמה כאשר מדובר בעבודה גדולה. שיטות תשלום של ש+60 או ש+30 הן נחמדות אבל אם אין לך כרגע עבודות שאתה עושה בנוסף, אתה יכול להיתקע למצוקת מזומנים. אין כללים לסכום אולם אני לדוגמא נוהג לבקש בין שליש למחצית הסכום כמקדמה (בהתאם לכמות השעות או מחיר הפרויקט) וחשוב לוודא שהמקדמה תשולם לפני שאתה מתחיל לעבוד.

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

התהליך המומלץ בעת ביצוע פרויקט ע"י יועץ

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

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

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

לעניות דעתי, דברים צריכים להתבצע בדיוק ההיפך.

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

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

משם עוברים לשאר החלקים – אחסון (Storage), רשת (Network) ומחשוב (Compute). היכן מומלץ לחשוב על פתרון NFS והיכן מומלץ על פתרון בלוק כמו iSCSI? האם ללקוח יש תשתית תקשורת מתקדמת (10/25/50 ג'יגהביט) או שצריך לעבוד ב-Teaming? האם חיבור הסטורג' "יחנק" עקב עבודה מאומצת של הפתרון שהלקוח רוצה שירימו לו? האם הלקוח צריך לעבוד ב-HA או DR או שאם נופל הפתרון ויש השבתה זמנית זה לא יהיה קריטי בשבילו? ועוד לא דיברנו על שילוב אוטומציה, Workflow ועוד דברים אחרים.

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

Solaris / SPARC – הסוף

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

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

בהתחלה זה עבד לא רע. בכל זאת, ל-Sun היו שרתים כלל לא רעים, פתרונות סטורג' מבוססי ZFS, פתרונות משולבים כמו Exadata ועוד מוצרים שחברות גדולות רכשו, אך הבעיה הגדולה ביותר היתה – סטגנציה. מערכת ההפעלה Solaris לא קיבלה עדכונים רציניים, מערכת ה-ZFS גם לא קיבלה תכונות חדשות ורציניות מאז סולאריס 10, וגם מעבדי ה-SPARC החדשים לא ממש היוו איום רציני לאינטל (שבסופו של דבר כבשה את שוק השרתים בכל מובן). אינטל פתחה מרכזי לינוקס בתוך החוברה ובסבלנות ועבודה עם יצרני הפצות לינוקס כמו רד-האט ו-SuSE כדי לשפר עוד ועוד את ליבת הלינוקס (ואת המעבדים עצמם) על מנת לתת תוצאות לא-פחות-טובות מהשילוב של סולאריס ו-SPARC וכיום מבחינה טכנית, אין שום הצדקה טכנולוגית להטמיע Solaris. אם אתה מחפש פתרון מבוסס יוניקס, פשוט תתקין לינוקס ותגמור עם זה, שלא לדבר על כך שדברים שנכנסו חזק לטרנד כמו Machine Learning או IOT – אתה צריך לינוקס וסולאריס לא יתן לך פתרון (בהצלחה להפעיל כרטיסי Tesla עם סולאריס. מנסיון – זה לא כיף, גם כשיש דרייברים של nVidia).

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

אורקל מנסה גם ללכת בשיטת ה-Me too. פתרון הוירטואליזציה שלהם? העתק של Xen. פתרון הלינוקס שלהם? העתקה ישירה מ-RHEL (של רד-האט) ואפילו הכלים המיוחדים שאורקל העבירו מסולאריס – כיום ב-2017 יש להם חלופות שהן בקוד פתוח לגמרי וכמובן רצות על כל הפצת לינוקס. גם בתחום הענן אורקל התעוררה מאוחר מדי ואם תסתכלו מבחינת דוחות Market Share, תוכלו לראות שאורקל נמצאת בד"כ בגרפים בתוך קטגוריית ה-Others. איך אורקל ישיגו לקוחות לענן שלהם? בכך שהם יעשו כל מאמץ לדחוף את הלקוחות שלהם שמשתמשים ב-Middleware וב-DB של אורקל – לענן תוך מתן הנחות (אני מנחש: זמניות) ולמי שמתעקש לעבוד On Premise – חכו לחשבוניות החידוש רשיון.

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

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

מוגש כחומר למחשבה.

משפחת ה-Xeon W החדשה של אינטל. שווה לרכוש?

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

בשבוע שעבר אינטל הכריזה על משפחת מעבדים חדשה, ה-Xeon W שמיועדת (כפי שהאות W רומזת) לתחנות עבודה. מבחינת דירוג, מעבדים אלו לתחנות עבודה יושבים באמצע, כאשר ברמה הראשונית יש את ה-Xeon E3 (כלומר תקבל משהו שהוא טיפ טיפה יותר מ-i7 לדסקטופ, אבל עם מגבלות של 32 ג'יגהבייט זכרון), לאחר מכן מגיעים דגמי Xeon W ואם אתה צריך יותר מכך, אתה מוזמן לעבוד למשפחת ה-Xeon החדשים תחת שם הקוד Purley. אם נשווה זאת לדגמים קודמים, הרמה ההתחלתית היתה גם אז Xeon E3, אם אתה צריך יותר אז היית רוכש Xeon E5 V4 מסידרה 16XX ואם אתה צריך מערכת עם זוג מעבדים, היית רוכש מערכת עם מעבד (או 2 מעבדים) מסידרה 26XX. בתכל'ס – אף אחד מיצרני תחנות המותג לא היה מוכר מערכות עם 16XX אלא מערכות עם מעבדים 26XX כאשר היית יכול לרכוש מעבד יחיד ולהרחיב יותר מאוחר ל-2 מעבדים מאותה משפחה. אם לעומת זאת היית בונה מערכת, היית יכול לקנות לוח אם לתחנת עבודה ולהרכיב בו מעבד Xeon E5 V4 16XX ואם היית רוצה ביצועים נוספים, היית יכול להחליף אותו למעבד E5 26XX. טריק נוסף נחמד שהיה הוא האפשרות להחליף מעבד Xeon E5 דור 3 (כלומר V3) לדור 4 מבלי להחליף חומרה נוספת, רק עם עדכון BIOS והחלפת מעבד+קירור.

מאז שאינטל הוציאה את דור 4 ואת מעבדי ה-Kaby Lake לדסקטופ, חלו כמה שינויים גדולים בתחומי המעבדים. AMD יצאה עם משפחת ה-Ryzen והראתה שאפשר למכור לציבור מעבדים מכובדים עם יותר ליבות בפחות מהמחיר שאינטל מבקשת על Kaby Lake ולשם שינוי – גם לתת ביצועים מכובדים. בחודש שעבר AMD גם שחררה את משפחת ה-Threadripper שלה שנותנת ללקוחות ה-Prosumer מעבדים עם עד 16 ליבות ו-32 נימים, עם תמיכה של עד 1 טרהבייט זכרון ECC, עם 64 נתיבי PCIE ובלי שום נעילת מעבדים (מבחינת Overclocking) במחירים נמוכים בהרבה ממה שאינטל מציעה.

אינטל בתגובה הוציאה את מעבדי ה-Skylake-X עם Chipset חדש (ה-X299 – כך שאתה חייב להחליף לוח אם) ובמשפחת מעבדי ה-Skylake-X ישנם מעבדים שבקצה הנמוך הם עם 4 ליבות (ללא תצוגה ושמיד מבטלים לך חצי מפונקציונאליות לוח האם) ועם מעבדים די ראויים בסידרת ה-78XX כאשר בקצה העליון יש מעבד כמו 7890XE עם 18 ליבות, 36 נימים, 44 נתיבי PCI ואפילו RAID לדיסקים מבוססי NVME! כמובן שאינטל גובה על המחיר למעבדים אלו מחיר מפולפל. על ה-7890XE היא גובה 2000$ (זה כמובן לא כולל לוח אם די יקר). הפתרון המתחרה של AMD עולה 1000$ (עם פחות 2 ליבות אבל עם יותר פונקציונאליות) – אבל אינטל לא ממש מתעניינת בתחרות ואלו המחירים.

וכרגיל, כשזה מגיע לאינטל, עצם העובדה שהיא מוכנה למכור מעבדים עם יותר ליבות במחיר יותר גבוה – לא אומר שהיא תפתח פונקציונאליות שהיא מייעדת ל-Enterprise – למשתמשי ה-Prosumer! חס ושלום! רוצה זכרון? יופי, נגביל אותך ל-128 ג'יגהבייט. זכרון ECC? לא ולא! אז מה אם אתה תשלם מחיר יקר בהשוואה לפתרונות של AMD?

מה שמביא אותנו למעבדי ה-Xeon W החדשים. המעבדים האלו .. הם בעצם ה-Skylake-X רק שאינטל הפעילה כמה ביטים בתוך המעבד והגבילה את התאימות שלהם. זה שקנית לוח אם עם X299 Chipset לא אומר שתוכל לרכוש Xeon W ולהכניס אותם (למרות שהם בדיוק עם אותם כמות פינים – 2066). בשביל זה אינטל הוציאה Chipset חדש, ה-C422 וכמובן אותו Chipset מקבל רק Xeon W ואתה לא יכול לתחמן בהכנסת מעבד Skylake-X. גם מחירי ה-Xeon W קיבלו "שדרוג" ואתה תשלם בין 400-1000$ יותר על אפס תוספת בביצועים, אבל תוכל להכניס זכרון ECC (בלבד!) עד 512 ג'יגהבייט, ותקבל את שאר הבבל"ט של ה-RAS ושאר ירקות שאינטל דוחפת ללקוחות Enterprise.

עד לשנה האחרונה, לחברות שרצו תחנות עבודה או ביצועים של תחנות עבודה, לא היו הרבה ברירות. או Xeon עם המחירים הגבוהים או מעבדים כמו 6950X שהיה יותר מיועד ל-Enthusiasts עם תג מחיר מאוד גבוה. כיום לעומת זאת – המצב שונה לחלוטין. תחנות קצה רגילות (דסקטופ) לחברות – אפשר לרכוש עבורן Ryzen Pro (שכולל את הפונקציות ל-Enterprise) או Ryzen רגיל ולתחנות דסקטופ רגילות עבור הפקידות ניתן לרכוש מעבדים כמו Ryzen 3 (מגיע עם 4 ליבות ויותר זול מ-i3 שמגיע רק עם 2). לקצה הגבוה של תחנות עבודה אפשר לרכוש תחנות עם Skylake-X או AMD Threadripper (בהתחלת השנה כל יצרני המותג יאפשרו רכישה כזו), ואם מתעקשים על פונקציונאליות של Enterprise אז ניתן לרכוש את ה-Xeon W או לחלופין תחנה עם מעבד כמו EPYC 7401P שעולה $1050 אבל מגיע עם 24 ליבות, 48 נימים, 124 נתיבי PCIE ותמיכת זכרון ECC עד 2 טרהבייט ובעודף שנשאר במקום רכישת Xeon W אפשר לרכוש מספר SSD או כרטיס/ים GPU טוב/ים.

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

אינטל מציגה – הדור השמיני .. בערך

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

אינטל הציגה לפני כשנה (ב-20 לאוגוסט 2016) את משפחת ה-Kaby Lake, מעבדים חדשים לדסקטופ ולמובייל, הדור השביעי החדש. כשמנפים את כל הילולי היח"צ, מבינים אנשי מקצוע רבים שקניה של המעבדים הללו לא תועיל בהרבה. כן, יש שיפור של 10-15% (וגם זה רק במקרים מאוד מסויימים), אבל שינויים ושיפורים משמעותיים – אין ממש כאן. בהמשך הדרך אינטל הציגה את ה-Kaby Lake-X, משפחת מעבדים שצריכה לוח אם חדש עם צ'יפ X299, רק שעד היום רבים וטובים לא הצליחו להבין מה עבר בראש להנהלת אינטל בחיפה. קניה ושימוש במעבד כזה מבטיחה לך מיידית שהלוח אם היקר שקנית – מחצית ממנו מיד תהיה מושבתת ברגע שתכניס מעבד Kaby Lake-X לתושבת, ושלא לדבר על כך שאין אפילו את היחידה הגרפית במעבד. בקיצור – אתה משלם יותר ממחיר מעבד Kaby Lake (ואם תכלול את מחיר הלוח אז המחיר יוצא הרבה יותר), ואתה מקבל .. פחות. מה בדיוק הטעם לרכוש מעבד כזה ממשפחה כזו? אין לי ולאחרים מושג ירוק.

אז שלשום אינטל ניסתה את מזלה בפעם השלישית בהצגת .. Kaby Lake Refresh כלומר "דור שלישי" ל-Kaby Lake (ובקיצור KLR), וגם הפעם אינטל הבטיחה ניסים ונפלאות, רק שהם יותר התרכזו בתוכן וידאו ברזולוציית 4K (ואם מי שקורא את הוידאו חושב שמעבד כזה ללא כרטיס גרפי חיצוני יתן פתרון טוב לעריכה – הוא טועה טעות מרה), וכרגיל גם הפעם אינטל הצהירה שהמעבדים החדשים יהיו מהירים ב-10-15% בהשוואה ל-Kaby Lake (על Kaby Lake-X אף אחד לא דיבר במהלך החשיפה).

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

להלן התשובה של אינטל (לחצו להגדלה):

עד היום בסידרת המעבדים U של אינטל בגירסת ה-15 וואט, היו 2 ליבות ו-4 נימים. אינטל סוף סוף בדגמים i7-8650U, i7-8550U, i5-8350U, i5-8250U מוסיפה 2 ליבות ומאיצה את מהירות השעון כשהמעבד נמצא במצב Turbo (אם כי מהירות הבסיס יותר נמוכה, לא באשמת אינטל, יש גבול למה שאפשר להוסיף במגבלת מעטפת של 15 וואט). בנוסף, אינטל הכפילה את זכרון המטמון בדגמי i7 ל-8 מגהבייט ובדגמי i5 ל-6 מגהבייט. אם נתרגם את זה לביצועים אז אם האפליקציה שאתה מריצה אינה מתפרסת על נימים וליבות נוספים, תקבל עוד 5-15% בביצועים אולם באפליקציות שיודעות לנצל כמות ליבות ונימים, תקבל ביצועים יותר גבוהים עד 40-50%. בכל הקשור לכמות זכרון במחשב, היצרנים יוכלו להציע עד כמות זכרון של 32 ג'יגהבייט (בניגוד למגבלת ה-16 ג'יגהבייט בעבר). שימו לב: המעבדים האלו לא יופיעו בכל המחשבים הניידים אלא יותר במחשבים בסקטור ה-Ultra Book במחירים שמתחילים ב-1000$ ומעלה (מחיר המעבד בלבד הוא בסביבות ה-410$!!)

אינטל בחודשים הקרובים תציג את שאר המעבדים שמיועדים לדסקטופ או למחשבים ניידים כתחנות עבודה (Mobile Workstation – סידרת ה-35 וואט) תחת השם Coffee Lake ובשנה הבאה היא תציג עוד מעבדים באותו דור (אם כי ביצור של 10 ננומטר) תחת שם הקוד Ice Lake. על מעבדי ה-Coffee Lake אפרסם פוסט בקרוב אבל ממה שכבר ידוע, אינטל החליטה להוסיף לכל המעבדים עוד 2 ליבות ולהרחיב את הזכרון מטמון בחלק מהמקרים.

כפי שציינתי לעיל, עניין הליבות הוא מאוד חשוב ואני שמח שאינטל החלה לזוז בעניין. אחד הצעדים המבורכים שאינטל עשתה היא להוציא את סידרת ה-Sky Lake X שסוף סוף מאפשרת לצרכנים לרכוש מעבדים ופתרונות עם 8 עד 18 ליבות מבלי למכור כליה או למשכן את הבית בקניית מעבדי Xeon (הסידרה הזו לא מחליפה את Kaby Lake אלא רק מוסיפה דגמים לשוק היותר מקצועי). אפשר לראות זאת גם בסידרת מעבדי ה-Atom C3000 החדשה שמיועדת לשרתים קטנים (דגש על "קטנים", זה מובנה בתוך לוח אם Mini ITX) ששם אינטל סוף סוף מציעה מעבדים עם 16 ליבות ו-16 מגהבייט זכרון מטמון במחיר זול (יחסית!) של 449$ (הלוח עם המעבד עולה בערך $1000).

מה שעכשיו אינטל צריכה לעשות, זה להפסיק עם ההתנהגות של "בשביל מה לך?". אינטל מדור לדור של מעבדים ו-Chipset מקצצת בכמות ניתובי ה-PCIe. מילא היה מדובר בחסכון מחיר לצרכן אך כפי ש-AMD מוכיחה עם מעבד ה-Threadripper 1900X שלה (ששם AMD מציעים 8 ליבות ו-16 נימים עם 60 ניתובי PCIe זמינים למשתמש! במחיר של 549$ למעבד) – אין כאן שום חסכון. גרוע מכך – בלוחות עם ה-X299 Chipset, כל מקל M.2 SSD עובר דרך ה-Chipset ואם יש לך 2 מקלות או יותר, אתה תקבל ביצועים שמוגבלים ע"י ה-Chipset. ב-AMD אין שום מגבלה כזו במעבדי ה-Threadripper, ואין שום בעיה להכניס אפילו 4 כרטיסים גרפיים ולקבל PCIe X16 על כל כרטיס, דבר שהוא בלתי אפשרי בלוחות המבוססים על X299 וחבל.

עוד נקודה שאינטל צריכה להבין – היא עניין המחירים. כש-AMD יצאו עם מעבדי ה-Ryzen, אינטל חתכה במכה אחת את המעבד עם הכי הרבה ליבות שהיה לה לדסקטופ (ה-6950X) מ-1700$ למחיר של 628$ (כיום באמזון ניתן להשיג אותו במחיר מצחיק של $359!). כיום בסידרת מעבדי ה-Sky Lake-X, מחיר מעבד של 16 ליבות ו-32 נימים שיצא בקרוב יעלה לא פחות מ-1700$ (בשעה שמעבד Threadripper עם 16 ליבות ו-32 נימים עולה $1000). כפי שתיארתי לעיל, גם מעבד כזה יסבול מהגבלות בגלל ה-X299 Chipset אולם עד כה אינטל לא חשבה להוריד מחירים.

לסיכום: לעניות דעתי, אינטל צריכה הרבה יותר להקשיב לצרכנים שהם הלקוחות שלה. מבחינת מכירות, אינטל מוכרת הרבה יותר ללקוחות הדסקטופ והמחשבים הניידים מאשר לשרתים או לסקטורים אחרים. לקוחות רוצים יותר ואם לקוחות מעוניינים, אז כדאי לספק להם את מה שהם רוצים במחיר הוגן. אם לקוח רוצה שהמחשב שלו ירוץ בצורה מעולה ללא תקלות ורוצה להשתמש בזכרון מסוג ECC – אינטל צריכה לאפשר לו במקום לחסום את זה ברמת ה-Chipset. אם לקוח רוצה להכניס 4 מקלות M.2 ולקבל מהירות מקסימלית ב-RAID-5 ולא להיות מוגבל על ידי Chipset – אפשרו לו ותחסכו את הפדיחות ש-AMD מציעה כל מה שלא הצעתם ובמחיר יותר זול.

עדכונים לגבי ESXI

זמן רב לא כתבתי על VMWare ESXI והגיע הזמן אולי לפרסם כמה דברים שחלק מהקוראים יודעים וחלק לא וגם לתת לכם זמן לחשוב לגבי גירסה עתידית של ESXI והאם כדאי יהיה לעבור אליה.

נתחיל בהווה: אם יש לכם גרסאות 4, 5, 5.1, 5.5 אז אולי הגיע הזמן יהיה לחשוב על שדרוג. לפי המסמך הזה של VMWare, גרסאות 4, 5.0, 5.1 כבר סיימו את חייהם מבחינת תמיכה ואם אתם מריצים גירסה 5.5 – היא תסיים את חייה ב-19/9/2018 כך שכדאי בתכנון התקציבי להכניס הוצאת שדרוג.

אם אתם משתמשים בגירסה 6.0 של ESXI אז מאוד מומלץ לשדרג לגירסה 6.5U1. השינויים בין 6.0 ל-6.5 הם רבים וכוללים שינויים ועדכונים ל-vSAN, עדכוני דרייברים רבים, מעבר ל-VSCA (ב-VMware ממש רוצים שתעבור ל-VCSA והם נותנים "הטבות" ב-VCSA כמו כלי מיגרציה, High Availability "טבעי", וגיבוי ושחזור "טבעיים" (של ה-Appliance, לגיבוי מכונות VM תמשיכו להשתמש ב-Veeam). ההתקנה של VCSA הרבה יותר קלה ואתם יכולים לקרוא על מגוון התכונות החדשות במסמך הארוך והרשמי כאן או בגירסה המקוצרת כאן. השדרוג מ-6.0 ל-6.5U1 עולה לכם … 0 שקלים מבחינת רישוי.

אם יש לכם גירסה 6.5, מאוד מומלץ לשדרג ל-6.5U1 בגלל כמה סיבות, להלן חלק מהן:

  • גירסת VSAN שודרגה ל-6.6 (והיא מצריכה ESXI 6.5 כולל VCSA 6.5 או אם אתם עדיין בגירסת Windows – אז vCenter Server 6.5 – מומלץ בחום לעבור ל-VCSA, הוא יעביר לכם את הנתונים אוטומטית) ואם אתם עובדים All Flash תקבלו הפתעה נחמדה – שיפור של 50% בביצועים. בנוסף תכנון גדילה עובר עתה תהליך Pre-check כך שהדברים יהיו יותר בטוחים ולא יפלו עקב חישוב שגוי מצד מנהל המערכת. בנוסף מקבלים את vRealize Operation Management, תהליך ה-Deploy יותר קל, תהליך בדיקת התקינות שופר מאוד, אין יותר צורך ב-Multicast (אני יכול לדמיין אנחת רווחה מאנשי התקשורת), שיפורים ב-Cross Site Protection (לאלו שמשתמשים בזה, לא מכיר כאלו) ועוד. אפשר לקרוא מה חדש כאן.
  • אם אתם חושבים לרכוש ברזלים חדשים כמו שרתים מבוססי מעבדי EPYC (שאפו!) או שרתים מבוססי דור 5 של Xeon – תצטרכו את ה-Update 1 של גירסה 6.5, אחרת תקבלו מסך סגול והמון עצבים. לאלו שרוצים להריץ בביתם כ-LAB את גירסה 6.5 על מעבדי Ryzen או Threadripper או Skylake-X – גם אתם תצטרכו את גירסת 6.5U1. (לא מומלץ לנסות על Kabylake-X – ניסיתי, זה נופל לאחר זמן מה מבחינת ביצועים ו-VMware אפילו לא מוכנים להתייחס לכך).
  • עדכוני דרייברים – ישנם עדכונים לכל כרטיסי הרשתות, החל מכרטיסים בסיסיים כמו כרטיסים מבוססי אינטל של 1 ג'יגהביט ועד לכרטיסים של 40/50 ג'יגהביט (למיטב ידיעתי כרטיסים של 100 ג'יגה תצטרכו דרייבר יצרן עדיין).
  • ה-vCenter יכול להיות ב-High Availability באופן טבעי ללא צורך בקפיצת ראש לבריכה בעומק חצי מטר. מגדירים Active, Passive ו-Witness ויאללה – יש HA. פונקציה זו אינה קיימת בגירסת Windows. כמו שאמרתי – VMWare מאוד רוצים שתעופו מגירסת ה-Windows לטובת גירסת ה-Appliance.
  • שדרוג מכונות ESXI הרבה יותר קל וברוב המקרים אוטומטי לגירסה אחרונה עם VCSA. שימו לב: קודם משדרגים Appliance ורק אז את ה-Hosts.
  • גם VUM עבר שדרוגים בכל הקשור לעדכונים ומעתה הוא יכול גם לשדרג אוטומטית (אם תרצו) מכונות VM לגירסה אחרונה (או גירסה שתקבעו) של תאימות VM.
  • בכל הקשור ל-Auto Deploy, מי שמנהל את ה-vSphere בחברה אולי ישמח לדעת שהוא פחות יצטרך להשתמש ב-PowerCLI ועכשיו יש ניהול גרפי מלא של הדברים וגם בניית Image חדש של ESXI Boot תוך כדי הוספה והעפה של דרייברים.
  • ויש עוד ערימות של תכונות חדשות…

אחד הדברים החשובים לגבי תשתית vSphere מהגירסאות הקיימות לגירסה 7 העתידית – זה שגירסה 7 העתידית תהיה שונה מאוד ממה שהיה עד כה. זה לא סוד ש-VMWare עובדים לאט (רק בגירסה 6.5 הם התחילו לתמוך ב-VMWare tools חתומים והתקנה של מערכות הפעלה עם Secure Boot), אבל בגירסה 7 הם רוצים לסגור פערים. העולם עובר לקונטיינרים וכרגע ל-VMware אין תשובה ב-vSphere באופן רשמי, כנ"ל לגבי פתרון תחרותי ל-OpenStack או Azure Stack של מיקרוסופט (אם כי יש להם כלי להקים OpenStack בתוך vSphere – ראו למטה), כך שגירסה 7 תהיה שונה לחלוטין מכל הגרסאות הקודמות. אי אפשר למסור עליה פרטים (אין לי הסכם NDA עם VMware אבל מצד שני אין לי חשק מחר לקום בבוקר ולקבל טלפון וצעקות מאנשים שם) אך מה שכן אפשר לאמר – שהיא בהחלט תקל על חברות גדולות שרוצות לעבור להשתמש בקונטיינרים (ויש לה כבר פרויקטים בקוד פתוח בנושא, אפשר לראות אותם כאן – ויש המון). משהו אחד שאני יכול להמר (אין לי בסיס משמועות לכך) זה ש-VMWare גם תבצע אינטגרציה של VMWare Integrated Openstack לתוך vSphere בעזרת מוצרים משלימים שיש כבר ל-VMware ובעזרת חלקים בקוד פתוח (שהיא תשחרר שינויים תחת אותם רשיונות). אגב, למי שלא מכיר את התוכנה – מוזמן לעקוב אחר המצגת הנחמדה כאן.

לסיכום: ישנם לא מעט חברות גדולות שרוצות להישאר רק על VM, לא ענן מבוסס OpenStack, לא קונטיינרים (אולי בעתיד) וחברות רבות הן גם מאוד שמרניות, לכן אני חושב שנראה כאן מעין "קו" וירטואלי בין מוצרים והטמעות שחברות יבחרו. עד גירסה 6.5U1 ה-vSphere סובב כולו סביב VM והתשתיות לספק את הדרישות ל-VM (רשתות, סטורג' וכו'). מגירסה 7 המוצר יהיה הרבה יותר גדול ומורכב בהרבה מהיום ולא בטוח שחברות ירצו לקפוץ אליו  ויש מצב שיותר ויותר חברות יחליטו להישאר עם 6.5U1 ואת השאר להעביר לעננים ציבוריים במקום לשדרג לגירסה 7 (ודרך אגב, אני מאמין שגירסה מוקדמת שלה אנו נראה ב-VMWorld שתתרחש עוד 18 יום ולאחר מכן ב-VMWare Europe. אגב, בכנס הזה נראה את התשובה של VMWare לאינטגרציה עם עננים ציבוריים, לא רק של אמזון).

הולך להיות מעניין…

קצת על רד-האט, BTRFS, פוליטיקה ומוכנות ל-Enterprise

אם נסתכל כיום על תשתיות של כל Enterprise או כל חברה גדולה, נראה שכיום רוב מכונות הלינוקס וה-Windows רצות כרגע על VM, בין אם זה רץ על ESXI, על Hyper-V, על OpenStack או בעננים ציבוריים או פרטיים. גם לינוקס וגם Windows רצים בלי בעיה כ-VM ולכל מערכת הפעלה יש תמיכה טובה בקישוריות בין ה-VM ל-Hypervisor שמריץ אותו.

הבעיות מתחילות כשצריכים להריץ הפצות לינוקס כמו רד-האט או סנטוס על "ברזל" פיזי או Appliance פיזי. אין שום בעיה להתקין לינוקס וברוב המקרים גם לא נצטרך דרייברים, וה-File system יעבוד כמו שצריך, אולם יש דברים בלינוקס שהם אינם קלים או מובנים למשתמשים רבים שאינם אנשי לינוקס ותיקים. יצירת RAID מבוסס תוכנה (Software RAID או Fake RAID) הם לא בדיוק דבר הכי קליל, במיוחד אם רוצים לשלב Volume Management בתוך אותו RAID תוכנה (אם כי כמובן יש אתרים שמסבירים כיצד לעשות זאת). את המשוכה הזו ניתן לדלג עליה די בקלות אולם אם אנחנו רוצים לבצע Snapshots או להוסיף SSD כ-Cache לאותו RAID, זה כבר נהיה יותר מורכב. רוצה גם לבצע Compression ו-DeDup בזמן אמת? כאן כבר תצטרך איש לינוקס טוב וזה לא תמיד אפשרי, תלוי במה קיים ובאפשרות לשנות דברים.

האם ניתן לעשות את הדברים בלינוקס? התשובה היא שבהחלט כן. אני כותב את הפוסט הזה בביתי ואחד משרתי ה-NAS שלי עושה בדיוק את הדברים הללו: ה-RAID הוא תוכנה, המערכת מייצאת iSCSI, CIFS, NFS החוצה למערכות אחרות (כל עריכת הוידאו שלי שאתם רואים בערוץ הוידאו של העסק מבוצעת על CIFS/SAMBA, לא על דיסק מקומי), יש DeDuplication  ויש דחיסה והכל רץ על "מפלצת" עם … מעבד i5 ועם 16 ג'יגהבייט זכרון, 5 דיסקים מכניים ו-2 דיסקים SSD ישנים שישבו אצלי במגירות. המערכת עצמה רצה על ZFS עם הפצת CentOS 7 ועם כל העומס שאני זורק עליה (ויש עומס) – היא עושה את עבודתה יציב כבר 4 שנים בלי תקלה אחת הקשורה ל-ZFS.

אז אם יש את זה, מדוע אינך רואה בהפצת לינוקס מבוססת רד-האט או סוזה אפשרות להקים מכונה עם ZFS? הרי ל-ZFS יש כבר ותק של בערך 12 שנה ב-Sun עם סולאריס (המערכת פותחה שם במשך 5 שנים לפני שהיא שולבה בסולאריס).

הסיבה הרשמית היא "בעיה ברשיון", הסיבה המציאותית יותר היא … פוליטית.

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

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

ב-2008 החלה לקום מערכת ניהול קבצים ודיסקים חדשה בשם BTRFS. בעקרון, BTRFS אמור להיות התשובה ל-ZFS רק בקוד GPL והוא משולב בתוך הליבת לינוקס. אנחנו ב-2017 וכיום כל הפצת לינוקס תומכת ב-BTRFS אולם הבעיה הגדולה ביותר של BTRFS היא ביציבות. ה-BTRFS יציב מבחינת file-system אך יש לא מעט בעיות במימוש ה-RAID שלו ובחלקים אחרים. בזמנו הקוד נבנה תחת קורת הגג של אורקל, אולם מאז שאורקל החליטה לברוח מקוד פתוח כאילו מדובר במחלה מדבקת – התפזרו המפתחים לכל עבר ואין עבודה יציבה על BTRFS, מה שגרם לרד-האט להודיע שהיא "יורדת" מ-BTRFS בגירסאות הבאות של הפצת הלינוקס שלה (בינתיים שאר ההפצות ממשיכות לתמוך ב-BTRFS, וזו מערכת עיקרית בהפצות כמו SuSE).

נשמע כמו צעד די דרסטי – לא? אכן, רק שבימים האחרונים הסתבר מדוע רד-האט עשתה זאת. רד-האט רכשה חברה קטנה בשם Permabit ש.. מציעה בדיוק את השרותים שה-Enterprise צריך: דחיסה, Dedupe, thin provisioning וכו'. האם רד-האט תציע זאת בחינם לקהל הרחב? כן, אבל יקח זמן. במילים אחרות, במקום לחכות ש-BTRFS יבשיל, רד-האט העדיפה לקנות חברה וטכנולוגיה. במקביל הודיעה רד-האט שהם החלו פרויקט חדש שנקרא Stratis שיאפשר לבצע חלק מהדברים בצורה קלה ופשוטה. אל תחזיקו את נשימתכם, לפרויקט יקח כמה שנים עד שיהיו פירות וניתן יהיה להשתמש בו בצורה בטוחה.

לסיכום: כיום ב-8 מתוך 10 מקרים, כשמקימים מכונת לינוקס, מקימים אותה כ-VM. לא צריך RAID ב-VM (אבל כן צריך LVM אם תרצו להגדיל דיסק או להוסיף דיסק ל-VM) ו-snapshots ניתן לעשות ברמת VM – ועדיין, עקב כל מיני החלטות שאני קורא להן "פוליטיות" הפצות רשמיות עדיין לא כוללות (גם בגרסאות המסחריות) דברים ש-Enterprise צריכים כשמקימים מערכת עם דיסקים מקומיים. הרכישה ש-רד האט ביצעה מסייעת במשהו, אבל אם רד-האט היתה עושה צעדים לפני מס' שנים כדי לסגור עיסקה עם אורקל, אז היינו כיום עם מערכת כמו ZFS שנותנת את הדברים שאותם לקוחות חשובים צריכים, במיוחד במקומות שמעוניינים להרים Software defined storage בשיטה של Scale Up.