התקלה של 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 לדוגמא).

האם לחזור ממחשוב ענן לתשתיות מקומיות?

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

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

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

מבחינה טכנית, ישנה כמובן אפשרות "אמצע" – להפעיל איש FINOPS כדי לראות היכן ניתן לחסוך, ובמקרים רבים ניתן לחסוך בצורה משמעותית כאשר מסתכלים על דברים שלא שמו לב אליהם. חברות וארגונים רבים בודקים היטב, לדוגמא, אלו סוגי Instnace הם שוכרים, ואלו הנחות ניתן לקבל (בין אם מדובר ב-SPOT או Reserved Instance כדוגמאות), אך קשה למצוא מישהו שממש עורך חשבון כשבוחרים אחסון לאותו Instance. אך ה"בזבוזים" הכי גדולים מתרחשים ברקע, כשלא מבצעים חישוב רציני לפני שבוחרים שרותי SAAS שונים שמציע הספק. להלן מספר דוגמאות:

  • בשביל מה להרים DB ולתחזק אותו אם הספק מציע שרותי DB מנוהלים מסוגים שונים?
  • שומרים מידע בתעריף הכי גבוה של אחסון אובייקטים (S3) מבלי להזיז את הקבצים הישנים יותר לשכבות יותר נמוכות ויותר זולות
  • בוחרים פתרונות אבטחה שהשתמשו בהן "בבית" (בתשתית המקומית) במקום לבדוק פתרונות אבטחה אחרים זולים ואולי טובים יותר (לאו דווקא מטעם ספקי הענן).
  • משתמשים בפתרון ה-CDN של ספק הענן במקום פתרונות CDN צד ג'
  • משתמשים בשרותי ה-K8S של ספק הענן גם כשלא מדובר בצרכי פרודקשן, וכך במקרים רבים יוצרים עוד ועוד Nodes שאמנם לא מבצעים הרבה עבודה, אך בהחלט משפיעים על החשבונית החודשית
  • ואפשר לתת עוד ועוד דוגמאות….

בקיצור – ההתמכרות לשרותי SAAS היא אחד החלקים שמכבידים מאוד בחשבון.

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

  • יותר ויותר יצרני שרתים, אחסון וכו' לתשתית המקומית "הבינו את הפואנטה" ועתה אותם יצרנים "דוחפים" את הלקוחות לכיוון השכרת ציוד (אתם משלמים על הברזל, הברזל מכיל יותר ממה שרכשתם והיתרה ביניהם "נעולה" עד שתחליט לקחת גם את השאר) וניהול חיצוני ע"י היצרן – חברות כמו HPE מציעות את GreenLake, חברת Dell מציעה את APEX, ולנובו מציעים את Truscale (אני בטוחה שיש עוד הצעות). אם יש משהו אחד שאני בהחלט יכולה לאמר באופן גורף – זה שאני לא ממליצה לאף גוף, קטן כגדול, לשכור שרותים אלו. אתם ממש לא רוצים את שרותי הניהול הללו (ראיתי פעם מבחן שניתן לתומכים אצל אחת היצרניות שמציעות שרותי ניהול. לא אציין שמות, אך בהחלט אומר כי צריך להתאמץ להיכשל במבחן כזה), ועדיף לרכוש ציוד באופן סופי מאשר השכרה עם כל מיני עלויות שיצוצו פה ושם. אתם כבר מכירים את זה מספקי הענן…
  • בענן או בתשתית מקומית, קחו/תשכרו אנשים מקצועיים. יצא לי בלא מעט מקרים להדגים לארגונים כי במחיר העלות השנתית שהם שילמו לדוגמא על DB מנוהל, היה ניתן לשכור אנשי מקצוע מהשורה הראשונה כדי להקים DB באותה תשתית, כולל ביצוע אופטימיזציות, וללקוח היה נשאר לא מעט עודף.
  • המנעו מהצעות "היברידיות" של ספקי הענן: רוב ספקי ענן ישמח לשלוח אליכם מספר "ברזלים", אולם במקרים רבים עדיף להשמיש ברזלים קיימים (ואולי לשדרג?) או לרכוש חדשים ולבצע חיבור לענן הציבורי שמארח את התשתיות שלכם.
  • שימוש ב-Multi Cloud: הנה מונח שרבים משתמשים בו לפני חתימת הסכם עם ספק ענן ציבורי, אך הרוב המוחלט לא משתמש בו לאחר מכן (אלא במקרים בודדים מסוימים). אני תמיד ממליצה שתשתית הפרודקשן תהיה לפחות בחלקה מתארחת אצל ספק ענן ציבורי אחר, עם מערכת Fail Over למקרה ויש תקלות אצל ספק הענן העיקרי שלכם.

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

  • פיתוח וטסטים – עדיין בתשתיות מקומיות.
  • פרודקשן בלבד – בענן, עדיף Multi Cloud
  • כמה שיותר להימנע מ"השכרות" שרותי SAAS בתשתיות מקומיות, ואם חושבים לשכור שרותים מסויימים, מומלץ להסתכל גם על הצעות שאינן מטעם ספקי הענן (דוגמאות: CDN – Cloudflare, גיבויים – Backblaze).
  • אימוץ פתרונות מבוססי קוד פתוח
  • המנעו מאימוץ פתרונות שמייצרים Vendor Lock כתוצאה מהעברת חלקים רבים בתשתית לספק פתרון מסוים.

ברודקום רכשה את VMWare – מה ניתן לעשות?

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

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

אני רוצה להצהיר מראש: פוסט זה אינו "אנטי VMware". אני חושבת שפתרון הוירטואליזציה עצמו (ESXI + vCenter) הוא פתרון מעולה שהרוויח את מקומו הדומיננטי בשוק הוירטואליזציה ביושר! במקרה זה הבעיה היא ה"הורים" – המשקיעים וברודקום שגרמו למצב הנוכחי (בעת כתיבת שורות אלו אני מוצאת כי גם DELL ניתקה את קשרי השת"פ עם VMware/ברודקום).

נעבור להצעות. אתחיל בהצעה שכרוכה בעלויות חד פעמיות: שדרוג חומרה.

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

  • "הפרשה" של שרתים ישנים (כן, אותם שרתי מבוססי מעבדי Xeon מסידרת E5-XXXX)  לטובת שדרוג לשרת אחד או 2 עם מעבדי AMD EPYC או Intel Xeon (במקרה שחושבים לרכוש שרת מבוסס AMD EPYC דור שלישי או רביעי: אפשר לרכוש שרת מבוסס מעבד אחד. כיום עם מעבדים אלו, אפשר לרכוש מעבדים עם כמות ליבות גדולה, כך שאין צורך ממשי בשרת עם 2 מעבדים). לאחר הרכישה והוספת המערכות ל-vCenter, ניתן לבצע מיגרציה של המכונות הוירטואליות מהשרתים הישנים ובסיום ניתן להעביר את הרשיון משרת ישן לשרת חדש. כך ניתן בקלות לקבל חסכון בעשרות אחוזים – בהתאם לתשתיות שיש בארגון.
  • שדרוג מכונות קיימות: יש לכם שרתים עם 8 ליבות? החליפו את המעבדים (בהתאם למה שניתן) למעבדים עם 16 ליבות (בשרתים עם 2 תושבות מעבדים) ואם השרת כבר מכיל 32 ליבות סה"כ, עיינו באתר של אינטל או יצרן השרת, ובידקו אם ישנן גרסאות מעבדים מאותה משפחה עם מהירות שעון גבוהה יותר (במקרים רבים המשווקים מוכרים מעבדים עם מהירות שעון נמוכה בכדי להוזיל את עלויות השרת). כנ"ל לגבי זכרונות: אפשר לשדרג למהירות זכרון (MT, MegaTransfer) יותר גבוהה אם מכניסים רק מקל זכרון יחיד פר ערוץ זכרון (עיינו בחוברת או PDF של השרת), ואם ננצל את מחירי הזכרון שירדו (במיוחד ECC DDR4), אפשר לרכוש DIMM עם כמות זכרון גבוהה ובכך גם להגדיל את כמות הזכרון, וגם לקבל מהירות יותר גבוהה.

אפשרות נוספת ושונה לחלוטין (שתצריך מחשבה ותכנון) ממה שהצעתי לעיל, היא ביצוע קונטיינריזציה של המערכות בארגון. כיום, ברוב המקרים, אפשר להריץ אפליקציות שרתים שונות בקונטיינרים, ורוב יצרני שרתי אפליקציות מאפשרים להתקין את תוצרתם ישירות כקונטיינר, תוך קבלת חסכון משמעותי במשאבי התשתית בהשוואה למצב הנוכחי, והכנה לעתיד למעבר לענן (אם חושבים על כך בהמשך). מעבר לכך, מהרגע שמגיעים למצב שרוב האפליקציות שרתים שנריץ, רצים על קונטיינרים בתוך כל מערכת המבוססת Kubernetes (לדוגמא: OpenShift, Rancher ואחרים) – יהיה אפשר להריץ מכונות וירטואליות מלאות (שלא ניתן להמירן לקונטיירים) כקונטיינרים בתוך המערכות שציינתי לעיל (כאן יש הסברים איך לעשות זאת עם Rancher וכאן יש הסברים איך לעשות זאת עם OpenShift), כך שניתן "לכסות" את הרוב המוחלט של הסיטואציות עם פתרונות מבוססי K8S, ולהשאיר דברים שאי אפשר "להזיז" (פתרונות VDI לדוגמא) על vSphere.

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

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

ברודקום רכשה את VMWare – ההמשך

בתחילת השנה פרסמתי פוסט על כך שחברת Broadcom רכשה את חברת VMWare בסכום של 69 מיליארד דולר, ובאותו פוסט/קליפ חיוותי את דעתי, וחשבתי שסיימתי עם הנושא… עד שקיבלתי טלפון מחברה מנמ"ר שביקש ממני לבדוק יותר לעומק ולחוות דעה יותר מפורטת. החלטתי שאם אני בין כה עושה זאת, אני גם אפרסם זאת כאן.

להלן תקציר:

למי שלא מכיר את חברת ברודקום, החברה רוכשת חברות שונות, ולאחר הרכישה היא מוכרת חלקים שונים של החברה הנרכשת, מקצצת בהשקעות בצורה משמעותית בחברה הנרכשת, כך שבמקרים רבים, החברה הנרכשת אינה יותר מ"שלד" ממה שהיתה בעבר חברה גדולה. דוגמאות לא חסר: CA, symantec ויש עוד כמה. גם רכישת VMWare אינה הרכישה האחרונה, החברה רכשה מאז את ConnectAll.

בחודשים האחרונים התקיימו מספר ישיבות עם הנהלת ברודקום, VMware, שותפים ואחרים, בהם התגלו הדברים הבאים:

  • החברה מחסלת את תוכנית השותפים המקורית של VMware וברדקום מעתה היא המחליטה מי יהיו השותפים והתנאים החדשים.
  • החברה משנה לחלוטין את פורטפוליו המוצרים של VMWare ומעתה יהיו שני מוצרי "אב", ורוב המוצרים האחרים של החברה לא יהיו זמינים יותר לרכישה עצמאית, אלא כ"תוספים" לאותם "מוצרי אב" – ארחיב בנושא בהמשך הפוסט
  • ברודקום החליטה ש-VMWare תצא מכל מה שקשור לוירטואליזציית קצה (VDI), ניהול מערכות קצה, וכל מה שקשור ל-End User Computing והיא מציעה את החטיבה למכירה עד סוף השנה הקלנדרית הנוכחית בסכום של 5 מיליארד דולר.

עתה נתרכז בעניין אותם "מוצרי אב": החברה תציע בעצם שני משפחות חדשות, הראשונה תיקרא VCF (ר"ת VMware Cloud Foundation) וחבילה זו תציע את כל מה שיש ל-VMWare להציע בתחום וירטואליזציה מנוהלת, מקומית או בענן (או בצורה משולבת) , כולל חלקים רבים שהוצעו כפתרנות נפרדים ומעתה יוצעו כ-Add-ons (תוסף) למי שרוכש את VCF. להלן תרשים דוגמא למה יוצע לרוכשים (לחצו להגדלה)

קרדיט: William Lam

מוצר האב השני הוא VVF (ר"צ VMware vSphere Foundation) – שזו כמובן חבילת ה-vSphere שמיועדת לקצה הגבוה וללקוחות הגדולים. כמו ב-VCF, גם כאן, מוצרים שהיו בעבר עצמאיים וניתנים לרכישה נפרדת, ימכרו מעתה רק כ-Addons. להלן תרשים החבילה (לחצו להגדלה):

קרדיט: William Lam

כפי שניתן לראות מהתרשימים, ישנם מספר חבילות מוצרים שהחברה כורכת, בין אם הלקוח רוצה או לא. כך לדוגמא, מעתה חבילת ARIA כלולה ב-VVF. יש לך מערכת אחרת לניתוח קבצי LOG  לדוגמא? או שתיפטר מהמערכת או שתשלם עבור חלק שלא תשתמש. מצד שני, ישנם חלקים שמעתה זמינים רק אם רוכשים את VCF – כמו VMWare firewall או ATP.

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

החבילה הקטנה הנוספת היא חבילת VMware vSphere Standard (VVS) – להלן התרשים (לחצו להגדלה):

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

ההצעה האחרונה שיש לברודקום/VMWare להציע נקראת VMware vSphere Essentials Plus Kit (VVEP) והיא די זהה ל-VVS. להלן התרשים (ההגבלה ל-3 שרתים היא במקור – לחצו להגדלה):

אלו הם ההצעות הזמינות ללקוחות, כאשר מעתה הכל זמין כמנוי (Subscription) בלבד. לאלו המעוניינים במידע לגבי ה-Validated solution על VCF, אפשר לראות פרטים כאן.

בקליפ שפרסמתי בפוסט הקודם, ציינתי כי חברות גדולות לא יתרגשו מעליית המחיר הצפויה (והיא בהחלט צפויה – מפוסטים שונים ברשת רואים עליה שנעה בין 100 ל-300 אחוז, אבל תמיד כדאי לשאול את הנציגות שמולה אתם עובדים), אך הבעיה המהותית קשורה לעיקר: שום חברה לא מוכנה "לבלוע" עליית מחיר כה גבוהה כשמדובר בדיוק באותו מוצר שהיה זמין במחיר נמוך משמעותית בעבר (כבר ציינתי כי רוב מוצרי VMWare הפסיקו להיות זמינים לרכישה עצמאית ו/או רשיון Perpetual? הנה פוסט של VMware עצמה על כך לגבי רשיונות, כל המוצרים ושרותי SAAS) ולכן רבים מתחילים להתעניין בפתרונות מתחרים (ספקי הענן כבר מציעים הצעות מפתות, Nutanix גם מציעים)

מה ניתן לעשות? על מה מומלץ להסתכל ולבחון? על כך – בפוסט הבא שיפורסם בסופ"ש זה.

חברת Broadcom רכשה את VMWare – מה המשמעות?

חברת ברודקום רכשה לאחרונה את חברת VMWare.

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

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

הטעות הגדולה של רד-האט

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

השינוי עצמו, אגב, אינו חל על גירסת ה-Upstream (מה שיהיה בעצם גירסת ה-RHEL החדשה בעתד), אך זה כמובן לא מסייע למי שיש מערכות RHEL או מבוססות חיקויי/fork של RHEL.

על מנת להבין מדוע השינוי הוא כה קריטי, צריך לזכור משהו אחד חשוב: רד-האט נחשבת הפצה יציבה ואיכותית, והיא משמשת אצל ארגונים רבים כ-Gold Standard (הרבה יותר מאשר כל הפצה אחרת, כולל אובונטו או סוזה). מכיוון ש-רד-האט שחררו את הקוד והשינויים המתמשכים לציבור, קמו להן מספר קהילות שהוציאו הפצות "תואמות RHEL" כמו Rocky Linux, AlmaLinux וכמובן – Oracle Linux שעמדו בתנאים של רד-האט (אפשר להשתמש בקוד, כל עוד השם Red Hat או לוגו או כל סימן רשום של רד-האט אינו נכלל) והן בנו את ההפצה מחדש, כאשר ישנה 100% תאימות בינארית ל-RHEL.

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

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

מה שאי אפשר להבין, מדוע הצעד ננקט בצורה כזו הזויה?

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

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

כיום, רד-האט לא נוקטת אף אחד מהצעדים. החברה אמנם מציעה (ללא קשר להודעה) עד 16 רשיונות בחינם, אולם יש תנאי לכך: הרשיונות הם עבור מפתחים/פיתוח בלבד.

אז מה ניתן לעשות?

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

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

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

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

חג שמח.