מחבר: דורין זביוס

פריצת ה-Spectre – תיקוני סיליקון

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

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

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

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

מה שאינטל כן יכולה להוציא זה את מעבדי ה-Xeon SP החדשים עם תיקונים (שאגב, לפני התיקון תצטרכו לשדרג את ה-BIOS/UEFI אחרת המכונה לא תצליח אפילו לבצע Boot), רק שכאן הבעיה היא שאף חברה לא "זרקה" את כל השרתים שלה והחליפה אותם לשרתים עם מעבדי Xeon-SP, כל חברה נורמלית בד"כ כשהיא מחליטה לשדרג, השדרוג מחליף רק חלק מהשרתים. אין שום סיבה לזרוק מכונות עם מעבדי Xeon V4 לדוגמא.

אם כבר מדברים על Xeon V4, אינטל כנראה תצטרך להוציא את התכנון של ה-Xeon V4 ולבצע גם שם תיקונים ולייצר את המעבדים הללו מחדש עם התיקונים. הנחות על מעבדי Xeon SP לא יספקו לשום חברה כתירוץ לרכוש שרתים "במקום" ולהשקיע אלפי דולרים פר שרת (וגם לא ניתן להכניס מעבדי Xeon SP לתושבות Xeon V4). "למזלה" של אינטל – שרתים בעלי Xeon V3 יכולים לקבל מעבדי Xeon V4 כך שאם אינטל תוציא מעבד Xeon V4, היא תוכל "לכסות" שרתים עם Xeon V3. כאן מתעוררת בעיה לוגיסטית: בניגוד למעבדי דסקטופ, לקוחות לא יכולים לבוא, לפרק את המעבדים מהשרתים, לנסוע למקום כלשהו, לקבל מעבדים חלופיים בהחלפת המקוריים, לנסוע בחזרה לחברה, להחליף ושזה יעבוד (בכל מקרה זה לא יעבוד, צריך קודם לשדרג BIOS/UEFI ורק אז להחליף מעבד פיזית). אינטל תצטרך כנראה לדאוג שיצרני השרתים יסעו ללקוחות ויבצעו תהליך החלפה (אם זה אפשרי בכלל. מה עושים לקוחות שיש להם TYAN, סופרמיקרו או שרתים "לבנים" אחרים?), אבל .. מי בדיוק ישלם על זה? טכנאי, נסיעות, שעות עבודה – זה לא בחינם ואינטל תצטרך לשבור את הראש על כך, ועוד לא דיברנו על תהליך ולדיציה – איך בדיוק אינטל תדע כמה מעבדים יש לחברה? להציג חשבוניות – אף חברה לא תסכים לכך (מה גם שזה מאוחסן אי שם…) – בקיצור לאינטל יש הרבה על מה לחשוב.

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

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

על Spectre/Meltdown ועל יצרניות סטורג'

הערה: הפוסט הבא נכתב כטור דעה אישית בלבד ואינו בא "לתקוף מתחרים"

כולנו שמענו על הצרות עם Meltdown ו-Spectre. בחברות מסויימות מיהרו להטמיע עדכוני BIOS/UEFI רק כדי לראות מערכות שבאופן רנדומלי מבצעות Cold Reboot ללא השארת עקבות והצהרות מצד היצרנים לא להתקין את העדכונים האחרונים ואם הם הותקנו – יש לבצע Rollback.

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

תסלחו לי, אבל מדובר לדעתי האישית בחתיכת בולש*ט!

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

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

כיום, מה שבד"כ רואים בפריצות למערכות, זה שמנסים לפרוץ אל השרתים ומכיוון שלשרתים אין גישה לכל מה שנמצא על ה-Storage, אפשר לגשת דרך השרת רק לחלק מהמידע. עכשיו תנסו לחשוב על פורצים מתוחכמים וממומנים. תחשבו על חברות מתחרות שיש ברשותן מאות מילונים/מיליארדי דולרים, תחשבו על מדינות כמו סין ורוסיה שמחזיקות צבא של פורצים ושהן מעוניינות במידע שלך. גם באותם גופים קוראים חדשות והם קוראים שיצרניות ה-Storage מתחמקות והן לא הולכות לבצע עדכוני Meltdown/Spectre. עכשיו אותם פורצים פשוט צריכים לשנות אסטרטגיה: עכשיו הם צריכים בעצם לפרוץ לתחנת עבודה שמריצה Windows או מק או לינוקס ומשם לפרוץ לממשק ווב או לקונסולה (CLI) של ה-Storage, להעלות משהו כמו busybox ואז להשתמש ב-חורים Spectre/Meltdown כדי לקבל מידע סודי/פנימי/חסוי. (הנה משהו שאולי יכול לעזור לכם: בדקו אם יש לכם ACL שנותן גישה לממשק רק למכונות מסויימות בחברה).

מדוע החברות Storage עושות זאת? אני יכול רק לנחש: אם הם יתקינו את הטלאים נגד Spectre/Meltdown – תהיה ללקוחות הנחתה רצינית מאוד בביצועים. כמה? אני יכול להמר בסביבות ה-5-40% תלוי כמובן כמה ה-Storage חדש או ישן. את הלקוחות לא יעניין שהחור קשור למעבדים של אינטל, הם יפנו אצבע מאשימה ליצרני ה-Storage ויצרניות ה-Storage יצטרכו להחליף לוח עם כמעט כל החומרה (למעט כרטיסים וספקי כח..) והמחיר לדבר כזה הוא אסטרונומי מבחינתם.

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

מה ההבדל האמיתי בין SSD רגיל ל-SSD ל-Enterprise?

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

הרשו לי להציג לכם את ה"יורש" של הסמסונג 850 PRO  שיצא שלשום – אחד מכונני ה-SSD שהצליח במשך 3 שנים להתעלות מעל רוב כונני ה-SSD הביתיים מבחינת ביצועים. זהו הסמסונג 860 PRO. מבחינת ביצועים הן מבדיקות והן "על הנייר" – זו חיה: 560 מגהבייט לשניה בקריאה ו-530 מגהבייט לשניה בכתיבה (זהו כונן בחיבור SATA). מבחינת IOPS יש לו בהחלט מה להתגאות: 100000 בקריאה, 90000 בכתיבה, ואורך החיים שלו – אתם יכולים לכתוב עליו ולמחוק – עד 4800 טרהבייט בכל משך ימי חייו. שום דיסק מכני לא נותן דבר כזה כמובן. מחיר: $238 לחצי טרהבייט.

והנה ה"אח הבכור" – ה-960 PRO בגירסת M.2 NVME. הביצועים? 3.5 ג'יגהבייט קריאה, 1.9 ג'יגהבייט כתיבה. IOPS? טוב ששאלתם: 440000 בקריאה, 360,000 בכתיבה. המחיר: $300 לחצי טרהבייט. אפשר לכתוב עליו באורך חייו כ-400 טרהבייט. (כן, ה-860 מחזיק הרבה יותר).

תכירו את ה-SSD החדש ביותר של אינטל (כתבתי עליו בעבר) – ה-900P. הוא יקר יותר ($628 לגירסה של 480 ג'יגהבייט), הוא יותר איטי בגישה לנתונים (2.5 ג'יגה בקריאה, 2 ג'יגה בכתיבה) אבל כשזה מגיע ל-IOPS, הוא בועט בכולם: 550,000 בקריאה, 500,000 בכתיבה.

אז מי מהם מתאים לחברות ומי לא מתאים לבית? ומדוע ההבדלים?

נתחיל ב-900P (הוא "האח הקטן" של ה-DC P4800X). נניח שאתה רוצה SSD מהיר לבית, אתה עורך וידאו נניח או מוכן לשפוך סכומים רציניים על המחשב למשחקים שלך. הכסף לא ממש משנה לך. האם כדאי לקנות אותו? התשובה היא לא. אם נעמיד את ה-900P במבחן מול ה-960 PRO או ה-860 PRO, שתיהם ינצחו אותו בקלות, כלומר אתה יכול לחסוך 300 דולר ולקבל SSD שיתאים לך לבית.

עכשיו נלך לחברה. נניח שאנחנו מקימים Storage משלנו, נניח שאנחנו מקימים שרת SQL כלשהו (לא חשוב אם זה מיקרוסופט, אורקל או PostgreSQL או MySQL) או שרת אפליקציה שאמור לתת שרות למחשבים רבים או משתמשים רבים. כאן דווקא ה-900P יתן ביצועים הרבה יותר גבוהים בהשוואה ל-2 ה-SSD של סמסונג, הם "יחנקו" מהר מאוד.

ה-SSD ל-Enterprise בעקרון בנוי לתת שרות לכמה שיותר משתמשים/מחשבים/תחנות, כמה שיותר Clients, בשעה שה-2 השניים בנויים לתת שרותים לכמה שפחות, כלומר למחשב אחד, לכמה אפליקציות שרצות במקביל במחשב הביתי/תחנת עבודה. במילים אחרות – אם לא מעמיסים על דיסק SSD ל-Enterprise אתם תקבלו ביצועים רחוקים מאוד ממה שמוצהר ע"י היצרן.

פרסמתי כאן בתחילת השנה פוסט על SSD ל-Enterprise והוא רלוונטי בדיוק לפוסט זה. בפוסט הקודם הזכרתי את ה-QD (ה-Queue Depth) שצריך אותו כדי לתת שרותים לכמה שיותר Clients וזה בדיוק מה ש-SSD ל-Enterprise מצטיין בו ו-SSD לבית גרוע בו. ניקח לדוגמא את ה-960 PRO, אם תסתכלו בסקירה זו תיראו שברגע שמתחילים להעמיס עליו, הביצועים צונחים דרמטית.

עכשיו נשארנו עם בעיה אחת: נניח ואנחנו רוצים ביצועים מאוד גבוהים לשרתים עם דיסקים מקומיים (כן, לאלו שמריצים vSphere עם דיסקים מקומיים לדוגמא) אבל המחיר מפחיד. ה-DC P4800X לדוגמא בגירסה צנועה של 375 ג'יגהבייט עולה $1700 (המחיר קצת יקר באמזון, המחיר הרשמי הוא $1520) וגירסת ה-750 ג'יגהבייט עולה מחיר "צנוע" של $3,653. במחיר כזה, גם חברות גדולות מתחילות לחשוב פעמיים אם לקנות במחיר כזה.

מה ניתן לעשות? ישנן מס' אפשרויות:

  • לקנות כמה קטנים. אפשר לדוגמא לרכוש 2 כרטיסי 900P (אגב, אם השרתים שלכם חדשים, אז ניתן לקנות את ה-900P בגירסת U.2 שנכנסת מקדימה) ולחבר אותם ב-RAID-0 ולהגדיר אותם כ-Cache. זה מתאים למצבים שאנחנו רוצים להריץ את השרת כשרת קבצים או כשרת NFS/SAMBA ואליו נחבר לדוגמא שרתי vSphere.
  • אם אנחנו רוצים להריץ שרת SQL או שרת אפליקציה כבד, נוסיף דיסק SSD כלשהו למערכת, עליו נתקין את מערכת ההפעלה והאפליקציות אך ה-DATA ישב ב-RAID-0 (מתוך הנחה שיש לכם גיבוי יומי!) כ"כונן" נפרד.
  • נבחר כונני Enterprise יותר זולים. לאינטל יש את ה-750 שישן קצת (מ-2015) אבל נותן ביצועים יותר טובים, יש את ה-P4600 ו-4700, שהם מעולים. חברות גדולות, כמובן, לא קונות כוננים ישירות מאינטל או סמסונג, ולכן מומלץ לחברות אלו לבדוק מיצרן השרת שלהם אלו דיסקים ניתן לקנות (לא מומלץ לקנות עם חיבור SAS, לכולן יש פאנל קדמי לחיבור דיסקים SSD בחיבור U.2 או SATA).

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

על פריצת ה-Spectre V2

בפעם הקודמת כתבתי כאן על הפריצות Meltdown ו-Spectre, על תיקונים ועל ביצועים. הפעם אני מעוניין להתעכב על Spectre גירסה 2 (V2), ומה קורה עם זה.. למעוניינים: פריצת Meltdown כבר תוקנה, ה-Spectre V1 גם (פחות או יותר) אבל Spectre V2 מתגלה כבעיה עקשנית..

והאצבעות מופנות הפעם ל… אינטל. (היתה בעיה עם מעבדי AMD, היא כבר טופלה [כולל במעדי Epyc ו-Threadripper]).

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

את הפירצה בגירסה 2 של Spectre אפשר לסכם בפשטות כך: מריצים VM בוירטואליזציה כלשהי? (באמת שלא חשוב מה פתרון הוירטואליזציה, כולם משתמשים ב-VT-X, VT-D במעבדי אינטל) אז מאותו VM ניתן להגיע למכונות VM אחרות ול-HOST עצמו. מריצים קונטיינרים? אז מהקונטיינר ניתן להגיע אל ה-HOST עצמו וב-2 המקרים מספיק קוד זדוני די קטן כדי להשתמש בפירצה. מספיק חמור?

בניגוד למקרים אחרים, בכדי לטפל ב-Spectre V2 צריך עדכון מיקרוקוד ישירות למעבד וכאן הדברים מתחילים להיות טיפה יותר מורכבים: כשזה מגיע ללינוקס ול-VMWare (נו טוב, VMWare בחלקן מכיל תואמות ברמת ה-Host ללינוקס ברמה של ABI) – אז עדכון המיקרוקוד מגיע מיצרן הפצת הלינוקס או מ-VMWare, כך שלא צריך לפנות ליצרן החומרה כדי לקבל את העדכונים. בעקרון, לינוקס קורא אמנם את הגדרות ה-UEFI/BIOS אבל לא מתייחס לכל ההגדרות ברצינות (מפתחי Kernel ותיקים בלינוקס די מזלזלים במימושי ה-UEFI/BIOS, בהצדקה מסויימת).

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

אינטל שחררה עדכוני מיקרוקוד ויצרניות הפצת הלינוקס הכניסו אותו לעדכוני הפצת לינוקס, וגם VMWare הכניסה את העדכון (דרך ה-VUM), אלא שאז התגלתה הפדיחה של אינטל. כנראה שאינטל לא ביצעה מספיק ניסויים ובדיקות על מעבדי E5/E7 V3, V4 וחלק מהחברות שעדכנו את המיקרוקוד קיבלו "הפתעה" לא נעימה – אתה מפעיל את המכונה, מתחיל לבצע עבודות ולפתע – המחשב מבצע לעצמו Reset. אין לוגים, אין כלום. נסו לדמיין את זה על שרת שמריץ ESXI או איזה שרת DB כבד שפתאום מנתקים לו את החשמל.

כתוצאה מכך, VMWare, RedHat ואחרים החליטו לבצע Rollback וכנ"ל גם יצרני שרתים ששחררו עדכוני מיקרוקוד דרך מערכות העדכונים שלהם ל-Windows. במכונות לינוקס כשבודקים את עניין המיקרוקוד לאחר עדכונים מיום שלישי, זה נראה כך (ב-CentOS 7 וב-RHEL 7) כשבודקים את ה-Changelog. אני מאמין ששאר הפצות הלינוקס גם חזרו אחורה.

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

שימו לב: ההבדל העיקרי בין עדכונים מיצרן השרת לבין עדכוני לינוקס/VMWare בכל הקשור למיקרוקוד, הוא שבמערכות לינוקס/VMWare, עדכוני המיקרוקוד חלים על המערכת זמנית, אחר ה-Boot ואילו עדכוני המיקרוקוד של יצרן השרתים שנמצאים בחבילת ה-BIOS/UEFI הם קבועים. זה לא כל כך משנה בלינוקס וב-VMware אולם בהחלט משנים ברמה של מערכות מבוססות Windows.

אז מה עושים כרגע? לא ניתן לעשות יותר מדי דברים עד שיצא עדכון חדש. בשלב זה אם תיפנו ל-Red Hat (ואתם לא לקוח גדול כמו בנק או חברת Fortune 500) אז תופנו בנימוס ליצרן השרת שיטפל בכם (ויצרן השרת יפנה בנימוס ל-Red Hat כי עם כל הכבוד, תמיכת הלינוקס של יצרני השרתים היא לא בדיוק רמה גבוהה..) ואם תפנו בנימוס לאינטל, היא תפנה אותך ליצרן מערכת ההפעלה שלך ואם מערכת ההפעלה שלך היא Windows אתה תופנה בנימוס ל.. יצרן המכונה שלך. כיף!!

מבחינת לינוקס, אם אתם מריצים RHEL או CentOS (מגירסה 5 ומעלה) ואתם רוצים לבדוק אם לאחר העדכונים אתם חסינים, אתם מוזמנים להריץ על המכונות שלכם את הסקריפט בלינק כאן (לחצו על Diganose והורידו את הסקריפט שמופיע שם).

לסיכום: כרגע, לא ניתן לעשות הרבה זולת המתנה לאינטל שישחררו עדכון מיקרוקוד יותר יציב שנבדק על מעבדים ישנים יותר. אם יש לכם מערכות סריקה (IPS ושאר קיצורי שמות) – אני מאמין שהם הוציאו עדכוני חתימות לגלות אם מישהו מנסה להזריק לכם קוד שמשתמש ב-Spectre (אבל אני לא בטוח כמה זה יתפוס, אפשר להשתמש בפירצה הזו גם עם קוד JS פשוט ובמקרים רבים ניתן פשוט לבצע code obfuscation ["ערפול קוד"], במיוחד כשיש לכם מערכות חשופות לאינטרנט).

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

אחסון אובייקטים (Object storage) ו-Ceph

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

באופן עקרוני, בניגוד ל-GlusterFS ו-ZFS, ה-Ceph היא מערכת מבוססים אחסון קבצים (Object Storage). היתרון במערכת כזו היא שהיא "מפשיטה" את כל המורכבות של File System רגיל (כמו XFS, EXT4 וכו') ל"קוביות" קטנות אחידות בגודל 64 קילובייט ואת אותן "קוביות" (שהם בעצם Objects) המערכת משכפלת לשרתים אחרים על מנת ליצור שרידות גבוהה מצד אחד, והם נגישים ל-Clients השונים מכל שכפול, כך קורה מצב שאם לדוגמא מספר מכונות דורשות את אותו קובץ, הוא נקרא משרתים שונים. בנוסף, מאותו Object Storage המערכת בונה גם שרותים אחרים שהיא מציעה, בין אם מדובר באחסון דומה ל-S3, אחסון File System, או NFS (ש"רוכב" על ה-File System") או אחסון "בלוקים" עבור iSCSI.

עם Ceph ניתן לאחסן מיליוני קבצים (ומעלה) עם גישה מאוד מהירה כאשר מגדירים את האחסון וקריאה כמו שקוראים לקבצים ב-S3. היכן זה יכול לעזור לדוגמא? כאשר רוצים לשדר וידאו. בדרך כלל לא מומלץ לחבר שרתי שידור (כמו WOWZA) לאחסון כמו Ceph, אלא מחברים זאת למערכת CDN טובה שהיא מפיצה את התוכן לנקודות EDGE/POP במקומות שונים בארץ/בעולם ומאותן נקודות השידור עצמו מתבצע. באותה שיטה (רק ללא צורך ב-CDN ברוב המקרים) ניתן לדוגמא להקים ארכיב ענק של קבצי מסמכים (גם בגודל של פטהבייטים רבים) ולאפשר גישה מאובטחת למסמכים דרך REST API שניגש ל-RADOS ב-Ceph שמחבר את אותן "קוביות" לאובייקטים ומשם האפליקציה יכולה לקרוא את המסמך ולהנגיש אותו עבור הלקוח. יתרון נוסף הוא באבטחה: אם מישהו מחר גונב שרת ומצפה למצוא את הקבצים שהוא מעניין בהם, הוא יתאכזב לראות שאין ממש קבצי DOC/PDF, יש "קוביות" וצריך את כל המערכת בכדי לקבל את הקבצים הרצויים.

טכנולוגיה חדשה שנכנסת לשוק בשנים האחרונות הם אמצעי אחסון מוכוונים KV (כלומר Key Value) והם מיועדים בראש ובראשונה לאחסן אובייקטים. חברת Seagate לדוגמא הדגימה דיסקים מסוג SMR (שהם דיסקים המיועדים לארכיב – Shingled Magnetic Recorder) בצירוב SSD מאיץ מסוג Nytro נותן ביצועים גבוהים פי 11 בהשוואה לדיסקים מכניים רגילים עם Ceph (ניתן לקרוא על כך ולראות וידאו בנושא כאן).

במסגרת תערוכת CES האחרונה, סמסונג הציגה SSD בפורמט חדש (NGSFF) לשרתים, זהו ה-PM983 וניתן לרכוש אותו בגודל של 8 טרהבייט ובמחצית השניה של השנה, הדגם הזה ימכר בגודל מדהים של 16 טרהבייט למקל. חברת Supermicro הכריזה על שרת פיצה (דגם:SSG-1029P-NMR36L – שם ממש קליט…) בגודל 1U שיכול לאחסן 36 מקלות כאלו, כך שניתן לאחסן 288 טרהבייט על שרת כזה. זה נראה כך:

Supermicro_SSG_1029P_NMR36L

היתרון בשרת כזו הוא שהוא בנוי כולו לאחסון של Ceph. מקלות זכרון האחסון של סמסונג מובנים מראש לאחסון KV וסמסונג מדגימה זאת בתמונה הבאה:

Samsung_KV_Stack_diagram

כפי שאתם יכולים לראות, מצד שמאל זה המצב הרגיל שקיים כיום כשמקימים אחסון מבוסס Ceph: מכניסים דיסקים רגילים או SSD, יוצרים פרטישנים, File System ואז משם מקימים את ה-KV Store שעליו מאוחסנים האובייקטים. מצד ימין רואים פתרון של סמסונג שכל מה שצריך הוא דרייבר והשאר נעשה בצורה טבעית על קושחת ה-SSD, אין צורך בשכבת "המרה" בחזרה ל-File System. במילים אחרות: אם תרכשו לקראת הרבעון השלישי את המכונה הזו ומקלות של 16 טרהבייט, תוכלו לקבל עם 10 מכונות כאלו 5 פטהבייט לאחסון אובייקטים. פעם זה היה לוקח ארון שלם..

לסיכום: כשצריכים לאחסן המון קבצים (כשמדובר במיליונים ומעלה) אחסון מבוסס Object Storage הוא הפתרון, ואמזון הדגימה זאת לעולם במסגרת שרותי ה-S3 שלה, ו-Ceph נותן בדיוק את אותו פתרון, ועתה גם חברות חומרה נכנסות ומציעות אחסון בצורה טבעית שמורידה את כל שלב התרגום מ-Object ל-File system ובחזרה. זהו אינו פתרון זול (ובוודאי לא פתרון להחליף File Server רגיל) – אך פתרונות כאלו מציעים שרידות וביצועים למי שצריך זאת ומוכן לשלם על כך. למעוניינים בפתרונות Ceph בארץ אני ממליץ לפנות ל-SuSE ישראל.

אתם באמת צריכים איש Devops? (חלק שני)

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

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

אתן דוגמא: כפרילאנסר, אין לי שום בעיה להרים Software Defined Storage, או קונטיינרים או לבנות מערכות לינוקס גדולות לבצע תפקודים מסויימים, או מערכות וירטואליזציה סגורות או בקוד פתוח, אבל כשזה מגיע למערכות כאלו, יודעים כמה חברות גדולות יכנסו לדף ה"אודות" כדי להזמין אותי, לשפוך כמה מאות אלפי דולרים ולשלם לי כמה עשרות אלפי שקלים בפגישה הראשונה? אפס. אף אחד לא מוכן להקים מחר בבוקר מערכת כזו. כל מי שיפנה – אז הוא יצור קשר להתעניינות, אולי להיפגש ואם זה ישמע לו, הוא ירצה בתור התחלה PoC (כלומר Proof Of Concept) ורק אם ה-PoC מראה תוצאות טובות – אז החברה תיקח זמן לחשוב, אולי תסתכל על הצעות אחרות ואם הם ירצו – הם יפנו מחדש כדי להקים מערכת כזו. כל פרילאנסר שעובד עם גופים גדולים יכול לספר לכם על כך. באופן עקרוני – ככל שהגוף/חברה יותר גדולה, דברים נעשים יותר לאט. מה שאנשים מקצועניים עושים בסטארט-אפ מהבוקר שהם מתחילים לעבוד ועל הפסקת הצהרים – יתורגם לשבועות ואף לחודשים – בחברות גדולות.

בסטארטאפ, הדברים הם פשוטים: כולם עובדים יחד. יש כמובן צוותים, ובתוך כל צוות פיתוח – כל אחד כותב חלק מסוים של הקוד, וסביר להניח שהוא יכתוב את קוד ה-Units testing, את ה-UAT או את ה-User Stories (לפי ה-Agile Development) לאותו קוד שהוא כתב. בקיצור – יש הרמוניה, וכשיש דינמיקה, דברים זזים מהר, ותמיד יהיה מישהו שיהיה אחראי על אוטומציה, תשתית ושאר ירקות שקשורים ל-Devops.

בחברות גדולות לעומת זאת, דברים זזים לאט ולפעמים "נתקעים". אז אתה רוצה לעבוד במתודולוגיית Agile? כאילו ה-Devops הזה ששומעים עליו? אוקיי, נתחיל עם PoC. הגיוני, לא? רק שאז צצה לה ה"פוליטיקה" של הארגון. ההוא שם טיפוס מבודד שלא מוכן לעבוד עם אף אחד (ומה לעשות, הדבר הראשון ב-Devops זה עבודה ביחד) ההוא לא רוצה לעבוד עם ההיא וכו', אנשים לא רוצים עבודות נוספות כמו כתיבת טסטים, Stories וכו', יש חוסר רצון בולט בלעבור לכלים יותר מודרניים (גם אם אתה מציע כלים שישמרו על תאימות לדברים הקלאסיים) ובכלל – בארגונים רבים מנסים (וחברות גולגלות/כ"א די מסייעות לכך מבלי לשים לב) "לכמת" את זה למישהו מסוים, אולי 2-3 לצוות – בדיוק כמו שיש צוות לסטורג', לנטוורק, לוירטואליזציה – אז עכשיו יהיה "צוות Devops".

כאן, בשביל ה-PoC מישהו חיצוני (פרילאנסר) יכול להוות פתרון. החלק הראשון הוא ההסברה לגבי מה זה לכל הרוחות Devops, מה זה מתולודוגיית Agile software development, מה נדרש בעצם מהמפתחים, איך זה הולך להיות וכו', כלומר הרבה לפני שבכלל מרימים אפילו VM או קונטיינר אחד – יש ישיבות על גבי ישיבות, הסברה עם מצגות, צריכים הסכמות לגבי הדברים, אישורים עקרוניים מצד מנהלי צוותים שונים, חישוב ואישור תקציב – וכל זה לפני שאתה נוגע במקלדת בשביל לבנות משהו. האמינו לי, בחברה מסויימת אני אמור להקים קונטיינר יחיד ב-Docker. כמה זה מסובך? זה לא, אבל אנחנו כבר 6 חודשים בישיבות. בגלל זה, פרילאנסר מתאים לחלק של ה-PoC. הסכימה החברה לשנות את כל העבודה שלה ועבודת הצוותים? שם כבר יכול להיכנס שכיר (ולשכירים שנכנסים לגופים גדולים ההמלצה שלי: הצטיידו בטונות של סבלנות).

במהלך היום (אני קצת חולה עדיין) עברתי המון על קליפים ביוטיוב שיכולים להסביר בצורה עניינית ולא בצורה של בלה-בלה-בלה מה זה Devops ולבסוף מצאתי אחד שמסביר בצורה טובה (לדעתי) את הדברים. הוא לא נכנס לפרטים של איזה בדיוק כלי לבחור ולשם מה, אבל הוא מסביר את זה בקטגוריות. הוא גם מתייחס לדברים בחברות גדולות. אורכו של הקליפ הוא שעה וחצי, אבל יש חלקים שונים שאפשר לדלג מעליהם (השתמשו במקשים L ו-J [ללא shift] כדי לקפוץ 10 שניות כל פעם) ולדעתי הקליפ די עוזר לתפוס מה זה Devops.

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

אתם באמת צריכים איש Devops?

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

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

אני אקח ברשותכם את הדברים טיפה קדימה. אני יותר ממשיל "איש Devops" (המרכאות בכוונה) למשהו מהדת הנוצרית: לאוונגליסט. הוא האדם ש"מצעיד" את החברה ממצב עבודה "קלאסי" (כתיבת קוד, קימפול, הכנסה ל-source repository, הוצאת Build, העברה ל-QA, תיקונים, קימפול, הוצאת Beta, תיקוני באגים, עוד Beta, עוד תיקונים ושחרור גירסה – כל זה ב"מבט על" וקפיצה על כל מיני שלבים בדרך) למצב עבודה שונה וזריז בהרבה.

המצב הזה נקרא CI/CD, במצב הזה דוחפים את הקוד ל-GIT, ישנה מערכת כמו Jenkins ואחרות שבודקות את ה-GIT וברגע שיש תיוג – היא מושכת ומקמפלת. את ה-QA מחליפים ב-Unit Testing – שזהו קוד מצטבר שכותבים בחברה לבחון את הקוד הנכנס האם הוא עומד בבדיקות שונות שהמפתחים כותבים. הנה לדוגמא וידאו קליפ על Unit Testing:

בתוך Jenkins (וכלים אחרים שנותנים פחות או יותר אותו דבר) יש לנו גם "צינורות" שבהם אנחנו מתכננים את כל התהליך מרגע שהמערכת מושכת קוד מה-GIT, מקמפלת ועושה שורה של דברים (חלקם מותנים, כך שיש מעין "תתי צינורות")  עד לחלק האחרון שאנחנו רוצים שהמערכת תעשה וניתן יהיה לשלב זאת בפרודקשן או לבצע מהלכים כלשהם (בדיקה ידנית, Selenium ואחרים).

בקיצור – לא רק הכלים שונים, השיטה שונה.

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

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

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

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

הבאג הקריטי במעבדי אינטל – עדכונים

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

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

בפעם שעברה דיברתי על הנחתה בביצועים בין 5 ל-30%, וכאן יש לעדכן: זה תלוי במעבדים בשרתים. מעבדים עד 5 שנים אחורה. מעבדים כמו Xeon E3/E5/E7 V3 ומעלה יש בתוכם פונקציונאליות שעוזרת למגר את הנחתת הביצועים כך שלא תהיה הנחתה משמעותית בביצועים, אולי אחוזים בודדים.

במעבדים היותר ישנים (שרתים כמו DELL דור 11 ומטה, HPE דור 7 ומטה, לנובו/IBM דור M3 ומטה) עדיין יורגשו הנחתות בביצועים במקרים מסויימים. המקרה הכי נפוץ שמצאתי הוא שכשמריצים שרתים כאלו כ-Hypervisor (כמו Hyper-V או ESXi) ומריצים את המכונות דרך Datastore שעובד על דיסקים מקומיים. מכיוון שלשרתים אלו אין אפשרות להיות משודרגים למעבדים מדור 3 ו-4 (טוב, למעט SuperMicro ששם אתה יכול להחליף לוח אם, בנוסף למעבדים, ובנוסף גם זכרון..) – האפשרויות שישנם הינן:

  • להקים מכונת VM שמחוברת לבקר דיסקים ולהריץ עליה מערכת שרות קבצים NFS/iSCSI.
  • להקים פתרון כמו שתיארתי לעיל אבל בתצורה פיזית.
  • לקנות פתרון סטורג' כלשהו.

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

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

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

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

לסיכום: מכיוון שרוב החברות הגדולות כבר לא מחזיקות בשרתים ישנים – אז הבעיה אינה כל כך חמורה בכל הקשור ל-Meltdown. בנוגע ל-Spectre בגירסה הראשונה, העדכון לא מוריד ביצועים (והתיקונים לגירסה השניה יעשו הן ע"י יצרניות מערכות הפעלה והן ע"י יצרניות אפליקציות). עדיין נשארו בעיות בכל הקשור ל-Spectre על טלפונים מבוססי אנדרואיד ועדכונים יצאו ע"י יצרני הטלפונים (ואם יש לכם מכשירים ישנים, אולי כדאי להחליף להם ROM למשהו כמו LineageOS). מבחינת ספקי ענן – כולם משתמשים בציוד די חדיש וכולם מעדכנים את כל השרתים שלהם, יכול להיות שתקבלו הודעה מנומסת מהן לעשות Reboot ל-Instances שלכם. מבחינת מחשבי Desktop, לאפטופים – ההנחתה בביצועים כמעט ולא קיימת. מה שהכי חשוב – יש לעדכן את כל השרתים ולבצע לאחר מכן Reboot לאותם שרתים.

הבאג הקריטי במעבדי אינטל

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

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

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

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

הבאג עצמו – הוא באג חומרה, כלומר תיקון דרך מיקרו-קוד לא אפשרי במקרים כאלו והוא משפיע על מעבדים לשרתים, דסקטופ, מחשבים ניידים וגם Appliances. בקיצור – כל מה שיש בו מעבד אינטל מהעשור האחרון בערך, חשוף – ובתרגום לאנשי IT: גשו לחווה שלכם, תסתכלו על השרתים שלכם, 90% מהם – חשופים.

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

איזה מחיר? בביצועים. תלוי מה האפליקציות שאתם מריצים ולאיזה ציוד הם ניגשים – הביצועים ירדו בין 3 ל-30 אחוז אחרי התקנת הטלאי (הטלאי יהיה חובה בכל מערכות ההפעלה). במילים אחרות – אם אתם לדוגמא מריצים מערכת מורכבת נניח על 10 מכונות VM, אחרי התקנת הטלאי ועל מנת לקבל את אותם ביצועים – תצטרכו בין VM ל-3 VM נוספים. ישנם דברים שאינם מושפעים והם יותר קשורים למכונות דסקטופ או מחשבים ניידים כמו משחקים, קידוד וידאו ועוד מספר דברים. הפרטים יתבהרו יותר בשבוע הבא, אבל הנה דוגמאת גרף של מעבד דסקטופ חדש (משפחת CofeeLake, מעבד i7 8700K) בהשוואה למעבד i7 מלפני 2 דורות: ה-i7 6800K (תודה לאתר phoronix.com על הגרפים)

הפס הסגול מציין מצב לפני הטמעת טלאי במערכות Linux והפס הירוק – אחרי. הבדיקה היא גישת יצירה/כתיבה/קריאה ל-4000 קבצים שנמצאים במכונה, בתוך 32 תיקיות, כל קובץ בגודל 1 מגהבייט. כפי שאתם יכולים לראות – לאחר ההטמעה כמו שניתן לראות במעבד החדש – המהירות צונחת חזק מטה. אגב, הגרף נוצר עם בדיקות על Linux אולם גם אם תשנו מערכת הפעלה, התמונה תהיה פחות או יותר אותו דבר.

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

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

כמה מילים על SSD ל-Enterprise

כתבתי בעבר מספר פוסטים על SSD בהשוואה לדיסק מכני ועל סוגי SSD. הפעם נתמקד יותר במה כדאי לחברות לרכוש (במידה והחברה לא רכשה שרתים שעושים קצת צרות עם דיסקים שאינם מאותו יצרן שרתים – היי HPE!)

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

התשובה לכך פשוטה וקשורה ל… תור, ספציפית לדבר שנקרא QD (כלומר: Queue Depth). המושג QD אומר בעצם כמה פעולות הבקר והדיסק יכולים להתמודד מבחינת תור. נסו לדמיין את עצמכם בסופרמרקט, זה עתה סיימתם להכניס מוצרים לעגלה ואתם עוברים לקופות. בד"כ אתם לא תגיעו ישר לקופאית, אלא תמתינו בתור כמו כל אחד אחר (טוב, תמיד יש תחמנים אבל זה משהו אחר) עד שיגיע תורכם להעלות את המוצרים מהעגלה למסוע, לתת לקופאית להעביר את המוצרים בסורק ולבסוף לשלם על המוצרים. ככל שיש יותר קופות פתוחות, התורים מתקצרים, וזה ההבדל הגדול בין דיסק SAS ל-SATA: בדיסק SATA יש 32 ערוצי תורים, ב-SAS יש 254 תורים, כך ש-SAS תמיד ישרת את הפניות יותר מהר.

עכשיו נשנה את הסיטואציה: אין קופאיות, העגלה בעצמה סורקת את המוצרים שלך ואז אתה מעביר את כרטיס האשראי בעמדות תשלום. האם התור יתקצר? בוודאי, תוך 2-3 דקות תוכל לסיים את הקניה, להעביר לשקיות ולצאת (טוב נו, בתיאוריה) – וזה מה שקורה עם SATA SSD: בגלל שה-SSD מאד מהיר והוא יודע בדיוק כל קובץ היכן הוא נמצא ואין צורך בראשים שיגיעו ויתחילו לקרוא את הנתונים ממקומות שונים, אז כתיבת/קריאת הנתונים תהיה מאוד זריזה, בוודאי כשנשווה זאת מול דיסק SAS מכני ולא חשוב מה תהיה מהירות ה-RPM שלו. בנוסף, דיסק SSD SATA טוב מגיע למהירות קריאה/כתיבה לפחות כפולה מכל דיסק SAS מכני והוא מריץ את ה-QD המוגבל שלו הרבה יותר יעיל ומהר מדיסק SAS מכני.

עוד סוג דיסקים שקיים הוא SAS SSD. טכנית, הדיסק נותן מהירות כפולה מדיסק SATA SSD, אך אם תבדקו אצל יצרנים שונים, תראו שהם פשוט כבר כמעט לא מייצרים כאלו מהסיבה הפשוטה: אם אתה רוצה משהו יותר מהיר מ-SATA, עבור ל-NVME. סמסונג, לדוגמא, מייצרת רק דיסק SSD אחד בחיבור SAS, והוא ה-PM1633a שמיוצר בגודל מרשים של 15.3 טרהבייט. המחיר? 4500$ לחתיכה. משום מה אני בספק אם יהיו רבים בארץ שיקנו אותו.

דיסקים NVME לא מתחברים לשום בקר RAID אלא מתחברים דרך חיבור U.2 (שהוא בעצם PCIe X4) ישירות ללוח ולמעבד (אם כי בחלק מהמקרים הוא עובר דרך צ'יפ "Switch" שנקרא PLX כי בלוח אין הרבה יציאות PCIe בלוחות מבוססי אינטל, ב-AMD Epyc התמונה אחרת לגמרי).

דיסקים SSD NVME בנוים בתצורה כזו של שרידות מאוד גבוהה, כך שאפשר לעבוד עליהם כיחידים או שניתן לקבוע זוג (דרך ה-BIOS/UEFI) כ-RAID-1 בשביל שרידות טובה או RAID-0 בשביל איחוד מקום (הדיסקים האלו הרבה יותר אמינים מכל דיסק SAS והם יודעים בעצמם לתקן שגיאות, בגלל זה יש להם גם אחריות של 5 שנים), אבל לפני שרצים חשוב לשים לב לא לקנות את הכי יקרים מהסיבה הפשוטה: אם אתם מייעדים את הדיסקים לשימוש אותו שרת מקומי בלבד או אם אתם מכניסים את זה לשרת קבצים שישרת 2-4 שרתים, אז הדיסקים המאוד יקרים לא יתנו לכם את הביצועים שאתם צריכים, בשביל שיתנו ביצועים גבוהים, צריכים כמה שיותר שרתים ושרותים שיכתבו ויקראו לדיסק, כלומר צריך למלא את ה-QD והרבה – בד"כ QD של 128 ידע לנצל את הדיסק הזה ואגב, אם SAS יכול לתת 254 תורים, דיסק NVME יכול לתת.. 50,000 תורים וכמה שתמלא את התור הזה הביצועים יהיו יותר גבוהים, לכן מומלצים דיסקים NVME מהסוג כמו של סמסונג כמו ה-PM863a  שמכיל 1 טרהבייט ועולה (בחו"ל) 480$. חשוב גם להכניס למחיר פאנל קדמי שיודע לתמוך ב-NVME (זה מגיע רק בתוספת תשלום ובחלק מהדגמים רק לחלק מהפאנל).

נקודה חשובה נוספת בשיקול היא דיסקים SSD עם או בלי סופר-קבלים (Supercapacitors). ישנם דיסקים רבים ל-Enterprise שמכילים זאת ובכך הם שומרים נתונים שעדיין לא נכתבו בעת הפסקת חשמל. זהו דבר חשוב אם אתם קונים דיסקים NVME, אולם אם הדיסקים הם SATA SSD, בד"כ הסוללה על הבקר תשמור את הנתונים עד לחזרת החשמל. כדאי לקחת זאת בחשבון.

לסיכום: מעבר ל-SSD זה דבר שיכול רק להועיל. לא חייבים לשרוף את התקציב השנתי על דיסקים ולא תמיד חייבים דיסקים Enterprise במקרים של SSD, אבל אם גם הולכים על דיסקים Enterprise, אין תמיד הצדקה לרכוש את היקרים ביותר – מכיוון שהם לא יתנו את הביצועים אם הדברים שאנחנו הולכים לבצע לא "קורעים" את ה-QD. לא מומלץ לנסות להקים RAID-5/RAID-6 על דיסקים NVME (ולמען האמת גם לא על SATA SSD) כי זה יקצר את חייהם משמעותית ולכן עדיף לרכוש דיסקים מעט יותר גדולים ולחבר אותם (דרך ה-BIOS/UEFI או תוכנת Storage) כ-RAID-1/RAID-10.