התקלה של Crowdstrike ומשהו שהכנתי

כמו שכבר כולם יודעים, עדכון של Falcon Sensor מבית Crowdstrike הצליח לגרום למכונות Windows שקיבלו את העדכון – לקרוס לחלוטין (BSOD). התיקון שהחברה מציעה – הוא למחוק איזה קובץ ולבצע Reboot

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

ממש "כיף"

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

  1. יש להוריד את קובץ ה-ISO מכאן (זה הגוגל דרייב שלי, אם גוגל מחליט לחסום עקב פופולריות יתר, צרו איתי קשר ואני אארח את הקובץ במקום אחר)
  2. מכיוון שמדובר בקובץ ISO, אפשר להתקין אותו על דיסק און קי (עם RUFUS לדוגמא ב-Windows או Media Writer בלינוקס), או להוסיף אותו לדיסק Ventoy
  3. ה-ISO תומך גם BIOS וגם UEFI, וניסיתי לתמוך גם ב-Secure Boot ולבדוק זאת, אך אין לי אפשרות לבדוק זאת על כל חומרה וכל פיפס של אבטחת Boot, כך שאם המערכת מתחילה לדבר על Secure Boot – תבטלו זמנית את ה-Secure Boot.
  4. ברוב המחשבים אין אפשרות להפעיל דיסק און קי מ-USB מיידית, ולכן יש להיכנס ל-BIOS/UEFI ולבחור את ה-USB כ-Boot Device ראשי
  5. אין תמיכה ב-Bit Locker. במכונות כאלו תצטרכו לעשות את הניקוי ידנית
  6. המערכת בנויה לסביבות וירטואליות ופיזיות שכוללות דיסק יחיד.

לאחר ששיניתם ב-BIOS וביצעתם BOOT – תקבלו מסך גרפי של DEBIAN. כל מה שצריך לעשות – זה ללחוץ Enter. מערכת הלינוקס תתחיל לעלות ובסיום אתם תהיו בתוך הלינוקס ללא הקשת שם משתמש וסיסמא

על מנת להפעיל את הניקוי, יש להריץ את הפקודה sudo cs-fix.sh

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

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

כמה הערות:

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

תהנו 🙂

מעבדי דור 13 ו-14 (סידרת K) של אינטל – והתקלות

לפני מס' חודשים שחררתי קליפ לגבי הבעיות שיש עם מעבדי אינטל דור 13 ו-14, ספציפית בדגמים ה-Unlocked (דגמים K, KS, KF) ובעיות החומרה שיש איתם (אתם כמובן מוזמנים לעשות Subscribe לערוץ 🙂 ).

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

הפתרון המוצע היה פשוט: עדכנו את ה-BIOS של המערכת שלכם, ודאו שאינכם משתוללים עם Overclocking ושאתם רצים בהגדרות קרובות לברירת המחדל של ה-BIOS (כן, אתם תפסידו מהירות) – והכל יהיה בסדר…

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

למי שאינו יודע, חברות Hosting רבות משתמשות במעבדים אלו (שמיועדים במקור ל-Desktop ולתחנות עבודה בקצה התחתון) כמוצר להשכרה עבור חברות שמעוניינות להריץ שרתי משחקים, מכונות להשכרה אישית (לדוגמא: תחנות פיזיות לשימושים כמו עריכת וידאו והרצת ישומים אחרים ללא שימוש בוירטואליזציה). חברות אלו אינן משתמשות בלוחות אם רגילים אלא לוחות אם שמיועדות בראש ובראשונה לתחנות עבודה, והן כוללות Chipset מסוג W680 שנבנים בראש ובראשונה עבור מערכות יציבות שירוצו 24X7. אותן חברות Hosting רוכשות את הלוחות הללו מיצרנים כמו ASRock Rack, SuperMicro ו-ASUS. כל היצרנים הללו כוללים חלקים למערכת יציבה המאפשרת גם שליטה מרחוק.

בחודשים האחרונים, גם  החברות הללו החלו למצוא כי ישנן בעיות עם המעבדים הנ"ל, והן מצאו את עצמן מחליפות מעבדים ללקוחות על ימין ועל שמאל, עד שזה הגיע למצב שאם לקוח מעוניין לשכור שרת לתקופה והשרת כולל מעבדים מסידרת K/KS/KF מדור 13 או 14 – הן היו מוסיפות כ-1000 דולר (בערך) תוספת למחיר עבור כל המאמץ העתידי והבעיות שהן תצטרכנה להתמודד בעתיד. אותם 1000 דולר תוספת במחיר – לא מופיעה בהצעות עם מעבדים מהמתחרים של AMD – ה-Ryzen 7XXX. לקוחות שתהו מה ניתן לעשות בכדי לא לשלם ולא להיגרר לבעיות יציבות – קיבלו המלצה מהחברות לבחור מערכות מבוססות Ryzen.

אינטל הודיעה בעבר כי היא מכבדת את האחריות על המעבדים ולקוחות שחווים בעיות, יוכלו להחליף את המעבדים בתהליך RMA. הבעיה: לאחרונה צצות בעיות באותן מערכות (עם המעבדים הנ"ל) בהן המערכות לא מוכנות לעבוד עם SSD במצב PCIe Gen 5 והלקוח יאלץ לעבור ל-PCIe Gen 4 (גם אם ה-SSD הוא דור 5), ולקוחות שדיווחו על כך לאינטל וביקשו להחליף את המעבד בתהליך RMA – קיבלו הודעה מאינטל שבמקרים אלו ה-RMA יסורב.

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

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

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

אם אתם חושבים לרכוש מערכת חדשה, לא מומלץ לרכוש את אחד מהמעבדים הנ"ל ובהתאם להעדפותיכם, תוכלו לרכוש עתה לוחות מבוססות Ryzen או להמתין לסוף השנה למעבדי אינטל החדשים (סידרת Arrow Lake S).

על גניבת הרשאות ואותנטיקציות של מיקרוסופט

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

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

גופים רבים עדיין משתמשים בשיטות כמו 2FA שאמנם ימנעו (בחלק מהמקרים) את  העברת פרטי האותנטיקציה של שם משתמש/סיסמא, אולם הדבר אינו יעזור כשיש לגנב את ה-Session Cookies, כנ"ל במקרים משתמשים ב-Microsoft Authenticator בשיטת ה-Passworldless (שימו לב – Passworldless ו-Passkeys הם דברים שונים לחלוטין) שבהם הגנב עדיין מקבל, שוב, את ה-Session Cookies ויכול להתחזות בהצלחה למשתמש הלגיטימי ולגנוב או לגרום נזקים.

בן, מערוץ Syn/Ack Time הכין קליפ קצר (7 וחצי דקות) שמדגים בעזרת כלי כמו Evilginx על מנת להתחזות לאתר מיקרוסופט והוא מדגים שימוש בשיטות אותנטיקציה שונות, וכיצד הוא מצליח לקבל את פרטי כניסת המשתמש ואת ה-Session Cookies. להלן הקליפ:

אם צפיתם בקליפ, אתם יכולים להבין את הדברים הבאים:

  • שימוש ב-Yubikey (או פתרון חומרתי אחר שתומך ב-FIOD2) עדיין נותן את הפתרון הכי חזק, תוך תמיכה בכל פלטפורמה (Windows, Mac, Linux) ובכל דפדפן, ואם בארגון מחליטים להשתמש ב-Microsoft Authenticator – זהו הפתרון היחיד שהוא מספיק חזק ויכול לתמוך בכל המשתמשים, כולל אלו שאין ברשותם מכשירי טלפון חכמים.
  • תמיכה ב-Passkeys של מיקרוסופט היא בעייתית לארגונים גדולים, הואיל והיא דורשת את גירסת האנדרואיד האחרונה או גירסת IOS האחרונה (גירסה 17, נכון לרגעים אלו), דבר שלא קיים בטלפונים רבים ישנים יותר. Google passkey שבנוי לתוך הדפדפן והטלפונים, דורש אנדרואיד גירסה 9 או IOS גירסה 16, דבר שקיים בד"כ ברוב הטלפונים כיום.

אסכם את הדברים כך: הגיע הזמן להיפתר מ-2FA ולעבור לשימוש ב-passkey (או לפחות במפתחות חומרה כמו Yubikey). בשיטות אלו, טריקים של SMS ו"חטיפת" מכשיר הסלולר לאישור אותנטיקציה לא יעזרו (יש צורך בקירבה פיזית למחשב, passkey משתמש ב-Bluetooth ו-Yubikey מצריך חיבור USB), וגם אם הקורבן הכניס את שם המשתמש והסיסמא שלו, הפורץ לא יוכל "לדוג" אותם, ובמקרים של שימוש ב-passkey, יהיה אפשר לוותר על תוכנת Authenticator (הגירסה של גוגל מסתמכת אותנטיקציה לכניסה לטלפון ואינה מצריכה אותנטיקציה מחודשת על מנת ליצור מספרים חדשים, בניגוד לגירסה של Yubikey לדוגמא).

לקצר דרכים – ולסבול מאוחר יותר

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

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

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

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

אחד הנזקים, לדוגמא, קשור לשדרוג. אם מישהו הקים מערכת Kubernetes והוא ינסה לשדרג אותה – סביר להניח שהוא יתקל במספר שגיאות, שאם הוא לא מבין בתחזוקה והקמת הפלטפורמה, יכולים פשוט להשבית לו את המערכת, וכנ"ל לגבי הרצה של כל מיני קונטיינרים חיצוניים תוך שימוש בקבצי YAML שאיש מהחברה לא עבר עליהם: צריך לזכור שקוברנטיס לא שואל יותר מדי שאלות לפני הטמעה של קבצים כאלו (kubectl apply -f something.yaml).

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

חג שמח.

המעבר ל-DPU

(הערת Off topic: פוסט זה ופוסטים בעתיד יכתבו בלשון נקבה. מדוע? הפרטים נמצאים כאן)

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

  • סיבוב ראשון – פתרונות כמו ESX/ESXI ופתרונות וירטואליזציה של מתחרים התמקדו בכך שישנם חלקים פיזיים שונים שמרכיבים את פתרון הוירטואליזציה: יש פתרון אחסון יעודי, יש מתגים ונתבים, יש חומת אש יעודית ועוד מספר "ברזלים" שנותנים שרותים משלימים – ויש את כל שרותי ה-Compute שמתקבלים מהשרתים. כל דבר – בנפרד.
  • סיבוב שני – קונסולידציה – פתרונות כמו vSAN של VMware ופתרונות מתחרים – מעבירים את השרותים המשלימים ל-Compute – אל תוך ה-Nodes עצמם. אחסון? הכנס דיסקים ונקים. רשת? יש NSX ופתרונות אחרים שייתרו פתרונות "ברזלים" יעודיים לטובת פתרון וירטואלי, כך שבסופו של יום, מערכת כזו תהיה בנויה משרתים עם דיסקים, כרטיסי רשת ומספר מתגים פשוטים ותו לא. הכל מוקם, מוגדר ומתוחזק בתוך פתרון הוירטואליזציה.

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

להלן תרשים שיפשט את הדברים:

(קרדיט: The Next Platform)

כפי שאנו רואים, ה-DPU (מצד שמאל למטה בתרשים לעיל) הוא זה שיריץ את שרותי ה-ESXI וכל שרותי ה-Management (לשם כך ה-DPU מכיל מעבד ARM עם מספר ליבות וזכרון) והשרת עצמו יריץ מערכת מינימלית שמכילה Hypervisor או כל מערכת הפעלה יעודית "על הברזל" – והמערכת תתממשק  אל ה-DPU, כך שה-DPU בעצם ינהל את השרת והשרותים.

מדוע בעצם עושים זאת? הסיבה לכך די פשוטה: אין זה משנה איזה מעבד X86-64 קיים לך בשרת, בין אם מדובר ב-Xeon של אינטל או ב-EPYC של AMD, המעבדים הללו טובים בדברים מסויימים כמו Compute, אך פחות טובים בכל מה שקשור לתקשורת, הצפנות, תעבורת רשת גבוהה, אחסון ברמה ובביצועים של SAN וכו', ודברים אלו יכולים להתבצע ביעילות עם שבבים יעודיים (ASIC או FPGA, תלוי ביצרן, בפתרון וכו') ולשם גם VMWare וגם היצרניות האחרות (חוץ מ-AMD, אינטל ו-NVIDIA, גם חברות אחרות מתכוונות להציע DPU משלהן, כמו Marvell, ברודקום וכו') רוצות להיכנס, ובמילים אחרות – מה שהיה פרויקט Project Monterey בעבר, עכשיו זה חלק אינטגרלי מ-vSphere 8 שיוצא.

מאיפה בעצם הגיע הרעיון לכך? התשובה די פשוטה: ספקי ענן ציבורי, ובמיוחד AWS. רוב השרתים ב-AWS (הסתכלו לדוגמא על AWS Nitro) כוללים בעצם מערכת שמכילה KVM לינוקסי מינימלי שמריץ רק מכונות וירטואליות, וכל שאר השרותים מתקבלים דרך כרטיסי PCIe Express בעלי שבבים יעודיים (דוגמת Pensando של AMD) שנותנים שרותים יעודיים כמו אחסון, תקשורת, הצפנה ושרותים נוספים לפי הצורך, כך שבעצם המעבדים בשרת לא מריצים כמעט מאומה – זולת ה-Compute של הלקוחות וה-Hypervisor המינימלי. בשיטה זו רמת האבטחה היא הרבה יותר גבוהה, וגם אם מאן דהוא יצליח לפרוץ לשרת, אין שרות אחסון שרץ מקומית בשרת שניתן להתחבר אליו ולגנוב ממנו מידע (כל התחברות בין VM לאחסון  דרך הכרטיס היעודי מבוססת הצפנה עם מפתח יעודי פר VM ויש עוד מספר אלמנטים לאבטחה).

יש גם נקודת לינוקס בכל העניין: מכיוון ש-DPU מכיל במקרים רבים מעבדי ARM עם אחסון וזכרון עצמאיים נפרדים מהשרת, אפשר לתכנת אותם, ו-Linux Foundation, יחד עם יצרני חומרה נוספים הקימו פרויקט שנקרא Open Programmable Infrastracture Project (ובקיצור – OPI) כדי לעודד חברות תוכנה לכתוב אפליקציות ודברים נוספים עבור אותם DPU.

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

… שלא מתאים לכולם.

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

אני חושבת שיש צורך לספר משהו אחד פשוט לגבי אותם IPU/DPU שהולכים להיות מוצעים: כל הפתרונות הללו נבנו בראש ובראשונה עבור ספקי ענן ציבורי (אז'ור, AWS, GCP, אני בספק אם אורקל משתמשת בכך), ואותן יצרניות החלו להוסיף ולשנות את הפתרונות כך שיוכלו לעבוד עם Project Monterey, כך שבסופו של יום – מדובר על פתרון שהוא מאוד חדש, ואינני בטוחה אם אפשר לקרוא לו "יציב", ובכל מקרה – מחירי כרטיסים כאלו – גבוהים מאוד, ויש צורך גם במתגים עם תמיכה במהירויות גבוהות (25 או 50 ג'יגהביט כמינימום!) – כך שגם אלו שרוצים פתרונות DPU כאלו, לא בטוח שזה יתאים להם.

לסיכום: DPU הוא פתרון מעולה, כאשר יש לארגון עשרות רבות, מאות או אלפי שרתי ESXi. לשאר הארגונים, מעבדי X86-64 כמו Xeon או EPYC – יתנו עבודה כלל לא רעה, ובמיוחד במעבדים העתידיים של שתי החברות ששואפות להכניס רכיבי האצה שונים לתוך מעבדיהן – ואת התוצאות לכך נוכל לראות בחודשים הקרובים.

רעיון קטנטן ליצרני פתרונות אחסון

במדינתנו הנחמדה, לא חסרות חברות המפתחות פתרונות אחסון כמעט לכל דבר – מגיבוי ועד Cloud Native, עם תמיכה בכל הפרוטוקולים הידועים, ועם ביצועים מאוד מרשימים. אם אינכם מכירים את שמות החברות, הנה מדגם קטן: Lightbits, Kaminario, Infinidat ויש עוד כמה וכמה, רובן חברות ישראליות או חברות בינלאומיות עם מו"פ בארץ.

אחד הדברים היותר מעניינים שיצא לי לראות בשנים האחרונות – זה המרחק הענק בין מה שחברות אלו מייצרות ומה שמוצריהם נותנים מבחינת שרידות, מהירות העברת נתונים וכו' – לבין מה שחברות רבות בארץ רוכשות לעצמן כשהן מחפשות סטורג'. כיום, ב-2022, יש עדיין לא מעט חברות שרוכשות אחסון המבוסס על דיסקים מכניים עם SSD שמשמש כ-Cache, ואלו היותר מתקדמים – רוכשים דיסקים SSD שמהירות הכתיבה שלהם איטית (Read Intensive) ועם עוד SSD או 2 הכוללים Flash מסוג SLC או MLC לצורך כתיבה מהירה. את אותם פתרונות אחסון מחברים לשרתים המריצים vSphere עם חיבורים של 10 ג'יגהביט חיבור נחושת או +SFP (עם DAC או סיב), או שעדיין משתמשים בחיבורים הישנים בסיבים במהירות עד 16 ג'יגהביט.

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

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

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

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

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

כשאני מדבר על "ברזל זמני", אני חושב שכל יצרן אחסון יכול בעצם לבנות שרת 2U פשוט, עם מעבד EPYC (בשביל כל ה-PCIe Lanes ל-SSD ולציוד הנוסף) וכמות קטנה יחסית של אחסון נטו (נאמר: 4 טרהבייט) עם הציוד המינימלי שצריך כדי לתת ביצועים די טובים (לא צריך להשקיע יותר מדי כמו הוספה של סוויצ', אפשר להשתמש בחיבורי JBOF חיצוניים לדוגמא). שרת כזה ניתן להשאלה לארגון מתעניין ל-30 יום כדי שיחברו ו"ישחקו" איתו – יאחסנו נתונים, יבדקו ביצועים, ויראו איך פתרון כזה יכול להשתלב בחברה.

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

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

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

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

השוואת Proxmox למתחרים

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

קצת מידע על Proxmox – מדובר מערכת ותיקה שהחלה את חייה עוד לפני שלמעבדי X86 היו יכולות וירטואליות בחומרה כמו שיש להם כיום, ולפיכך המערכת תמכה בפתרון וירטואליזציה כמו OpenVZ – הרצת מערכת לינוקס (ומערכות אחרות, אך לא Windows) בקונטיינר (אם כי פורמט הקונטיינר שונה מפורמט כמו של Docker וכו'). מאוחר יותר, כש-KVM בלינוקס צבר עם QEMU פופולריות, הוא הוטמע בפתרונות רבים (כל ספקי הענן הציבורי משתמשים ב-KVM הלינוקסי, מיקרוסופט ב-Azure משתמשת ב-KVM ב-Instances המאפשרים Nested Virtualization) וגם ב-Proxmox וכיום כשמקימים מכונה וירטואלית ב-Proxmox, היא תרוץ עם KVM.

כשזה מגיע לוירטואליזציה, Proxmox עומד בכבוד מול המתחרים ויש לו כמעט את כל מה שיש בפתרונות Hypervisor מתחרים. אין בעיה להצמיד ב-VM חומרה מסוגים וחיבורים שונים, המערכת תקבל בשמחה כל דיסק עם כל File system כ-Storage, כולל ext3, ext4,btrfs, zfs,ceph, glusterfs, והמערכת גם כוללת תמיכה שיתופית באחסון: יש לך דיסקים במכונה אחת אך לא במכונה אחרת? אין בעיה! בהגדרת ה-Storage, בחר ב-All Nodes (ראו תמונה לעיל, לחצו להגדלה) והמערכת תייצר עבורך NBD מבלי שתצטרך להרים NFS או CIFS עם כל ההגדרות. גם כשזה מגיע לשרידות, יש ל-Proxmox מה להציע (כל עוד יש לך 3 מכונות פיזיות) – הגדר את המכונות הוירטואליות שאתה מעוניין שישרדו, והמערכת תבצע להן מיגרציית Live אם אחד השרתים יורד בצורה מסודרת, או שהיא תריץ את ה-VM מחדש במכונה אחרת (כל עוד האחסון מבוסס על NFS או CIFS. קצת בעייתי לבצע שרידות שכל הדיסקים יושבים על שרת אחד שבדיוק מכבים אותו)…

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

מה קורה אם ניקח את Proxmox ונשווה אותו לפתרונות יותר גדולים כמו oVirt/RHV או vSphere של VMware? התשובה פשוטה: אין ל-Proxmox סיכוי להתחרות, הואיל ו-Proxmox לא כולל חלקים רבים. קחו לדוגמא עניין כמו איזון עומסים של מכונות VM בשרתים (ב-VMWare זה נקרא DRS, ב-oVirt/RHV זה נקרא Scheduling Policies) – זה לא קיים ב-Proxmox. עוד דוגמא קשורה לניצול כל הדיסקים הקיימים בשרתים ליצירת מערך אחסון גדול ושורד. נכון, יש GlusterFS שנתמך ב-Proxmox, אולם ל-Proxmox אין מושג ירוק מה קורה עם ה-GlusteFS – אתה יכול לבצע Mount וזהו. ב-VMware לעומת זאת, פתרון vSAN ליצירת אחסון מדיסקים – נלקח הרבה יותר ברצינות (ב-oVirt/RHV היה פתרון Hyperconverged מבוסס GlusterFS אולם הוא היה פתרון חצי אפוי והוחלט בשקט לבעוט אותו החוצה). אם נבחן לדוגמא את עניין הרשתות ושימוש ברשתות וירטואליות, הממשק ב-Proxmox מאוד אנמי (אין לך אפשר להגדיר דברים כמו VLAN, Slaves ודברים רבים דרך הממשק, אין לך אפילו אפשרות לראות אם החיבור נפל או לא, ואם אתה מתעקש להגדיר, אתה צריך לעבוד בדרכים הישנות, כמו לפני ש-NetworkManager או Netplan היו קיימים) ואילו ב-vSphere או RHV הדברים נלקחים בצורה הרבה יותר רצינית (הנה דוגמא ב-oVirt), ועוד לא דיברנו על ההתעקשות של מפתחי Proxmox לא לשלב את libvirt – ה-API הגדול והמשמעותי ביותר לכל ענייני וירטואליזציה בלינוקס ובמערכות הפעלה אחרות.

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

קצת פרטים לגבי DCPMM של אינטל

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

בשנים האחרונות אינטל הוציאה את מקלות ה-DCPMM (ר"ת DC Persistent Memory Module). אלו מקלות אחסון שאינם משתמשים ב-NAND כמו אחסון SSD אחר, אלא 3D Xpoint, שיטה חדשה שמאפשרת כתיבה וקריאה במהירות מאוד גבוהה ושרידות (מבחינת DWPD לדוגמא) גבוהה בהרבה, בהשוואה לפתרונות Flash אחרים שקיימים בשוק. אינטל הוציאה גם פתרונות אחסון קונבנציונאליים מבוססי 3D Xpoint (תחת השם Optane, למרות שתחת השם הזה הם הכניסו עוד סוגים שונים של אחסון, למה לא לבלבל את הלקוח הפוטנציאלי!) אך ה-DCPMM היה שונה בכך שהוא הרבה יותר מהיר והוא משובץ בתושבות הזכרון בשרת, וכתוצאה מכך, שימוש ב-DCPMM יחד עם זכרון RDIMM יכול לתת פתרון די טוב לזכרון בכמות גבוהה, במחיר יותר נמוך בהשוואה לכמות זהה של זכרון אם כולו היה מבוסס DRAM RDIMM.

בוידאו הבא אסביר קצת לגבי דברים כמו:

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

להלן הקליפ.

נקודות חשובות נוספות לגבי הנושא:

  • כאן יש מסמך חשוב מאוד מחברת לנובו המשווה את ביצועי המערכת אם משתמשים רק בזכרון, או שילוב של יותר זכרון ומעט DCPMM, וההיפך, וכמו כן הוא נותן דוגמאות לגבי יחסים RDIMM עם DCPMM מצוותים. מומלץ לקרוא.
  • הפתרון אינו קיים למערכות שאינן מבוססות אינטל (כמו AMD) הואיל ומדובר בפתרון סגור וקנייני של אינטל.
  • לא מומלץ להשתמש במצבי אחסון Block Storage כשמשתפים מקלות DCPMM משני מעבדים שונים (או יותר, במקרה ומשתמשים במעבדי ה-Cooper Lake) אלא אם יש לכם מעבדים מסידרה L או מעבדי GOLD, אחרת נוצר צוואר בקבוק שקשה לשחרר.
  • ולחבריי הגיקים שצופים בערוץ היוטיוב של ServeTheHome – אכן ראיתי את הקליפ של פטריק אתמול, וזה הזכיר לי שעל הנושא לא הוצאתי כמעט כלום, אז בגלל זה החלטתי לבצע "השלמות" 🙂

ההבדלים בין מעבדי אינטל שונים עבור שרתים (וידאו קליפ)

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

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

פרילאנסרים, מצלמה ושיחות וידאו

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

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

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

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

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

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

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

  1. הורידו והתקינו את אפליקציית OBS Studio מהקישור הבא (שימו לב: גירסת לינוקס אינה תומכת במצלמה הוירטואלית, נכון לגירסה 26.1, כך שזה יעבוד רק על Windows או מק).
  2. הפעילו את התוכנה והתרכזו בצד שמאל, בקוביה שכתוב עליה Sources
  3. לחצו על מקש ה- + בחרו Video Capture Device, תנו לזה שם, לחצו OK, ובחרו את המצלמה שלכם (חשוב שהיא לא תהיה בשימוש באפליקציות שיחות אחרות באותו זמן)
  4. באותו חלון של בחירה, יהיו אופציות שונות להגדרת המצלמה. אם אתם לא מבינים בתחום או לא מכירים – אל תשנו. לחצו OK
  5. אם הבחירה שלכם עבדה, אתם תראו את עצמכם בתוך חלון מוקף במסגרת אדומה. המסגרת מציינת אובייקט אקטיבי ב-OBS.
  6. אם אנחנו רוצים להוסיף לוגו, נלחץ שוב על ה- + ונבחר Image. חשוב: ה-Image אמור להיות בפורמט PNG אם רוצים רקע שקוף ללוגו (כמו אצלי בתמונה לעיל). תנו שם, לחצו על Browse ובחרו את הקובץ PNG עם הלוגו. לחצו OK לאישור. שוב אנחנו נראה ריבוע אדום מסביב לתמונה – השתמשו בריבועונים הקטנים מסביב לריבוע האדום הגדול כדי להקטין את התמונה ולמקם אותה היכן שתרצו.
  7. אם נרצה להוסיף טקסט (כמו שם, לדוגמא), נלך שוב לקוביית ה-Sources, נלחץ על + ונבחר Text +GDI – שוב, תנו לזה שם ולחצו OK. כעת יפתח חלון ובתוכו תהיה קוביה שחורה עם הכיתוב משמאל "Text" – הכניסו כאן את הפרטים שאתם רוצים (אפשר במספר שורות). שימו לב שהחלון שנפתח – נגלל, ויש אופציות שניתן לשחק איתן כמו פונט, צבע, ישור לימין, שמאל וכו'. הכניסו את הטקסט שאתם רוצים (אם אתם רוצים להכניס טקסט במספר גדלים, תצטרכו ליצור מספר אובייקטים של טקסט). אחרי שלחצתם OK, שנו את גודל ומיקום הטקסט על החלון.
  8. אפשר להוסיף אלפי דוגמאות נוספות וליצור דברים מדהימים (למי שלא ממש מרוצה מהאפקטים הוירטואליים של זום, ב-OBS יש תמיכה מלאה ב-Chroma Key, להלן קישור להוראות).

מרוצים ממה שאתם רואים? מעולה.

מצד ימין יש מספר כפתורים מוארכים (כמו Start Streaming וכו'). לחצו על הכפתור שנקרא "Start Virtual Camera")

זהו, אתם יכולים לבצע מינימליזציה של חלון ה-OBS (ב-Windows אפשר ללחוץ על אייקון ב-OBS בשורת האייקונים מימין/שמאל).

פתחו את אפליקציית הזום או סקייפ, לחצו על גלגל השיניים מצד ימין למעלה, לחצו על Video, ובחרו OBS Virtual Camera. אתם אמורים לראות מה שרואים ב-OBS. תוכלו לבחור אופציות אחרות כמו Mirror, תאורה וכו'.

ברכותיי, התצוגה המשופרת של עצמכם פעילה, תהנו מהחשיפה 🙂

מספר נקודות טכניות:

  • משתמשי מק – לא בטוח שהמצלמה הוירטואלית תעבוד (במיוחד עם Big Sur). כפי הנראה שתצטרכו להעיף חתימות, כפי שמוסבר כאן.
  • למי שרוצה – אפשר לבצע Up scaling של הוידאו. המצלמה הוירטואלית תשדר לפי הרזולוציה שמוגדרת ב-OBS. לשינוי – יש ללחוץ על Settings, על Video ולהגדר את ה-Output לרזולוציה שרוצים. שימו לב – סביר להניח שזה יאמץ את המחשב שלך במעט.
Exit mobile version