יש לכם שרתים/סטורג’ של HPE עם SAS SSD? מומלץ לקרוא

חברת HPE הוציאו לאחרונה עדכון דחוף לקושחות עבור מספר דיסקים SSD בחיבור SAS שנמצאים על מגוון הציוד ש-HPE מוכרת: שרתים (Proliant, Apollo), ועבור פתרוות אחסון: (JBOD D3xxx, D6xxx, D8xxx, MSA, StoreVirtual 4335,StoreVirtual 3200). דגמי הדיסקים וכל ההערות ולינקים לאפליקציות תיקון מופיעים במסמך ש-HPE פרסמה.

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

להלן הגירסה הראשונה: בכל דיסק SSD יש מעין “מחשב” שכולל בקר, זכרון, אחסון Flash (בנפרד משבבי ה-NAND Flash ברוב הדיסקים SSD היקרים). הבקר עצמו די משוכלל והוא זה שקובע לאן כל ביט ירשם – באיזה תא, באיזה בלוק, באיזה שבב, ובקר זה גם אחראי על פעולות אחרות לתחזוקה אוטומטית של דיסק ה-SSD והוא יודע לפתור (שוב, בדיסקים היקרים – כמו בדיסקים הנ”ל) את רוב הבעיות הקשורות לתא דפוק, הזזת נתונים ועוד.

עקב באג בקושחת הבקר על דיסק ה-SSD, לאחר 32,768 שעות (כלומר 3 שנים, 270 יום, ו-8 שעות) כל הנתונים על דיסק ה-SSD יעלמו. זה לא “אם”, לא “אולי”, זה ודאי. מישהו כתב קוד די דבילי וזו התוצאה. התיקון עצמו משכתב קושחה חדשה לכונן ה-SSD ועל מנת שהקוד יפעל, יש צורך ב-Reboot למערכת (HPE כותבים שאין צורך לעשות Reboot, מהיכרות קודמת עם בקרי ה-Smart של HPE, אני ממליץ דווקא כן לעשות Reboot). התיקון הזה ימנע את ה-Time Bomb לכונני ה-SSD הנ”ל.

עכשיו הגירסה היותר “גיקית” לאנשים שצריכים לטפל בדברים. הדברים שאני כותב רלוונטיים למערכות VMWare ESXi ולהפצות לינוקס השונות (כרגע, רשמית, בלינוקס ההפצות הנתמכות הן RedHat, CentOS, SuSE, אם אתם עם אובונטו או דביאן, תצטרכו קצת להכיר את rpm2cpio).

מבחינה טכנית, לאחר הזמן הנ”ל (3 שנים, 270 יום, 8 שעות), מה שיקרה הוא שהמפות שהבקר משתמש בהם כדי לדעת היכן כל דבר מאוחסן, אלו תאים (Cells) דפוקים, אופטימיזציה וכו’ – ימחקו. ה-DATA עדיין נשאר על שבבי ה-Flash, אבל בלי המפות אי אפשר לעשות כלום, אין כאן לצערי תהליך Rebuild שאפשר לעשות (טכנית, זה אפשרי, אם מלחימים JTAG ל-SSD ו”מדברים” ישירות עם הבקר SSD, אבל אז צריך להכיר את הבקר, פקודות, אסמבלר של ARM וכו’ – והידע הזה לא קיים ציבורית).

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

  • בלינוקס קיים זמן רב שרות מובנה של עדכון קושחה מבלי שתצטרך לבדוק/לנחש איזה חומרה יש לך בתוך השרת. כל מה שצריך זה להתקין את חבילת fwupd מהפצת הלינוקס שלך, להריץ (כ-root) פקודה fwupdmgr get-updates ואת הפקודה fwupdmgr update והמערכת תוריד אוטומטית את הקושחות הרלוונטיות לשרת/מחשב שלך. כשתבצע Reboot הוא יפעיל אפליקציה דרך ה-UEFI שמעדכנת את הקושחות שצריך, וכשזה מסתיים, המערכת תבצע אוטומטית reboot ובכך העניין טופל. הבעיה? ב-HPE בקושי שולחים עדכוני קושחה לשרות הזה.
  • HPE מוציאים שני עדכונים שונים שמיועדים ל-SSD שונים. HPE כבר הוציאו אפליקציה בלינוקס מאוד ותיקה שיכולה לתשאל את בקר ה-SMART (היא נקראת: hpacucli) אלו דיסקים יש ובכך להשוות דגמים ולהתקין את הקושחה, אבל לא, הצורה שהם כתבו את סקריפט העדכונים תגרום לאנשי לינוקס ותיקים לרענן את קטלוג הקללות שלהם.

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

  • הראשונה – לתשאל את הבקר, וזה במקרה אם אתה מריץ לינוקס פיזית על השרת, פקודה כמו hpacucli ctrl slot=0 pd all show תציג לך את הדיסקים, דגם, מספר סידורי וכו’, כאן grep ו-awk יכולים לעזור לך לעשות סדר ולמצוא את הנתונים.
  • השניה – לבצע reboot לשרת ולהיכנס לתפריט ה-SMART. שם מופיעים לך דגמי הדיסקים.
  • השלישית, קצת פחות מומלצת – ללכת לשרת, להוציא דיסק SSD החוצה ולהשוות את הדגם.

אם יש לך דיסקים שנכללים בעדכון, תצטרך לבחור להוריד את הסקריפט הרלוונטי, לעקוב אחרי ההוראות ולשלוח את העדכונים שיעברו דרך ה-SMART ישירות לבקר ה-SSD ויעדכנו אותו. האפשרות האחרת שיש זה להוריד SPP, להוריד את החבילות, לשים באיזו מכונת Windows או לזרוק הכל לדיסק און קי (לשים את החבילות תחת תיקיית packages/ ) ולהשתמש ב-SUM. זה כמובן אומר שתצטרך להשבית את המכונה עד שתעדכן את הקושחות באותם דיסקים.

חשוב לזכור: תהליך עדכון קושחת בקר SSD מבצע Reboot לאותו דיסק SSD (לא לשרת), ולכן יכולים “לקפוץ” לכם התראות על בעייתיות באותו דיסק SSD, עד שהמערכת “מבינה” שהדיסק תקין, קחו זאת בחשבון לפני שאתם נזעקים ממערכת ההתראות שלכם, ובגלל זה אני ממליץ במקרים שמדובר בשרת שמריץ ESXi לעשות את העדכונים לאחר שהעפתם ממנו (עם live migrate) את כל מכונות ה-VM ולאחר ה-Reboot לתת ל-DRS להזיז מכונות VM לשרת המעודכן (אם אין DRS, תזיזו ידנית).

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

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

על פריצת ה-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 [“ערפול קוד”], במיוחד כשיש לכם מערכות חשופות לאינטרנט).

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

Exit mobile version