ברודקום רכשה את 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 גם מציעים)

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

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

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

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

פוסט תגובה ל-"לא להינעל" (המאמר של ליאור קיסוס)

קראתי את מאמרו של ידידי היקר ליאור קיסוס באתר PC, וחשבתי להגיב לגבי הדברים.

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

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

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

את הריצה המטורפת לשימוש ב-SAAS אני רואה מכל עבר, ואני חוזר ומציין תחת כל עץ רענן כי ברוב מוחלט של המקרים, שרותי ה-SAAS הם מיותרים לחלוטין אם לא מדובר בפרודקשן שחייב להיות זמין 24/7. אדרבא, ככל שמשתמשים בכמה שיותר שרותי SAAS, האפשרות למעבר לספק ענן מתחרה הופך להיות יותר ויותר קשה, במיוחד כשרוב מוחלט של ספקי הענן הציבורי כיום כלל לא מציעים שום Migration Path נורמלי מענן אחד לשני, ואף אחד כמובן לא מוכן לממן את השינויים בסקריפטים ובמקומות אחרים שצריכים לשנות כדי לעבור ענן.

יש נקודה מסויימת שאינני מסכים עם ליאור, והיא קשורה למחיר: מחירי הענן לא עולים ועולים, ואני אומר זאת באחריות: אני משתמש בשרותי ענן של אמזון כבר 6 שנים לצרכיי האישיים, וכיועץ אני מתעדכן תדיר במחירים של הספקים השונים מבחינת מחירי תשתיות ושרותים. כמעט בכל מצב, תמיד אפשר למצוא דרכים לחסוך כספים בענן, אם מוכנים קצת, טיפה, להתאמץ: במקום להשתמש ב-RDS, תפסיקו להתעצל ותקימו בעצמכם תשתית SQL (לדוגמא). במקום להשתמש ב-CDN הסופר יקר של ספק הענן, תשתמש ב-CDN של מתחרים שאינם נופלים בביצועים ובאיכות ממה שספק הענן שלכם מציע, יש "שכבות" שונות לאחסון Object Storage כמעט אצל כל ספק ענן וניתן בעזרת סקריפט פשוט להעביר קבצים (אם לא רוצים לשלם על Tiering חכם), וזה – על קצה המזלג, כך שבעזרת תכנון נכון וניטור מתמשך, לא צריך להגיע למצב של "שריפת" תקציבים אצל ספק הענן הציבורי.

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

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

קצת פרטים לגבי 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 – אכן ראיתי את הקליפ של פטריק אתמול, וזה הזכיר לי שעל הנושא לא הוצאתי כמעט כלום, אז בגלל זה החלטתי לבצע "השלמות" 🙂

להתראות CentOS??

בימים האחרונים יצאה הודעה כי CentOS 8 תעבור שינויים משמעותיים ובכללם – ההפצה תחדל מלקבל עדכונים בסוף שנת 2021, ולא תהיה הפצת CentOS המקבילה ל-RHEL מבחינת גירסא וקוד. הדבר היחיד שישאר הוא CentOS Stream שזו גירסת CentOS טיפה יותר "מתקדמת" מ-RHEL (אבל מבחינת עדכוני אבטחה – ה-Stream יקבל את העדכונים רק לאחר ש-RHEL יקבל).

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

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

ראשית, אני יכול להבטיח שאין ל-IBM יד ורגל בנושא ובהחלטה. רד-האט היא עדיין חברה עצמאית שמחליטה לעצמה החלטות, כולל את ההחלטה הזו.

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

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

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

כל איש לינוקס ותיק ירגיש בוודאי תחושת דה-ז'ה וו בנושא. כבר היינו בעבר בסרט הזה. כשחברת רד-האט החליטה להוציא רק גרסאות לינוקס מסחריות בתשלום (מה שהיה RHEL, RHES), נוצרו מספר פרויקטים שלקחו את קוד המקור של RHEL וביצעו Fork לגירסה עם שם אחר אך עם תאימות מלאה (בעקרון, לא מדובר בתהליך של קימפול הכל מחדש באופן אוטומטי. יש לא מעט כלים לפתח, יש לא מעט סקריפטים לכתוב, להסיר קבצי לוגו וסימנים מסחריים של רד-האט וכו') כשה"זוכים" בפופולריות בסופו של דבר היו CentOS, Scientific Linux וכמובן Oracle שהחליטה פשוט לבנות את הכל בעצמה ולגנוב לקוחות מ-רד-האט.

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

לפיכך, להלן המלצותיי (לפי התיעוד הרשמי):

  • אם אתם משתמשים בגירסה כלשהי של CentOS 6 – שדרגו בדחיפות. ה-EOL שלה חל בחודש שעבר.
  • אם אתם משתמשים בגירסה כלשהי של CentOS 7 – אתם בטוחים, ואתם תמשיכו לקבל עדכונים לגירסה עד תאריך 30/6/2024. אם אינכם חייבים לעבור לגירסה 8, פשוט אל תעברו, במיוחד אם המכונות הן וירטואליות.
  • אם אתם משתמשים בגירסה כלשהיא של CentOS 8 – אתם תקבלו עדכונים עד סוף שנה הבאה (31/12/2021)
  • עכשיו, כל מה שנותר לעשות, זה להמתין ולראות מי "יקפוץ". האם רד-האט תחזור בה? (קהילות הלינוקס הן לא קהילות מנומסות, בלשון המעטה!) ואם לא, מי החברות שיכריזו על Fork ל-RHEL? (אמזון? מיקרוסופט? גוגל?) במשך השנה הקרובה אנחנו נראה את ההתפתחויות ואני מאמין שכבר בחודשים הקרובים נראה חדשות בנושא עם מפות דרכים והמלצות לאן להגר.

ולבינתיים, אני ממליץ לא לקחת המלצות פזיזות, אם אפשר.

השינוי המהותי ש-VMware מתכננת לבצע

כנס VMWorld נערך באופן וירטואלי השנה ב-29-30/9 וכלל מגוון הרצאות, שרובם נעו על מוצרים ונושאים שב-VMWare כבר דיברו עליהם בעבר. אחד הנושאים שעבר "הכרזה מחדש" (3 פעמים! פעם אחת בשנה שעברה, פעם שניה בכנס VMworld ופעם שלישית רק לפני יומיים בכנס GTC) הוא נושא ה"DPU" (כלומר Data Processor Unit) של חברת מלאנוקס, עם מעבדי ה-Bluefield-2. חשבתי לכתוב פוסט על ה-DPU, אך מכיוון שיש עוד מספר שחקנים שהולכים להיכנס בדיוק לתחום זה עם שמות משלהם, החלטתי לכתוב פוסט יותר כללי בנושא.

תכירו – פרויקט Monterey

לפני שניכנס לפרטי הפרויקט, נסתכל על המצב הנוכחי, עוד ברמת ה-Hypervisor, ה-ESXi. כיום, ה-ESXi בעצם מריץ את כל השרותים כ-Hypervisor על מעבדי ה-X86 (ה-Xeon או EPYC) – בין אם מדובר בשרותי רשת, שרותי אחסון, אבטחה, Host Management ועוד. כל זה טוב ויפה, אך זה גוזל לא מעט משאבים מהשרת, וזה גם לא נותן מענה מלא לצרכים של הלקוחות כיום, שרוצים מהירות תקשורת יותר גבוהה, שימוש בכרטיסי FPGA וכרטיסים אחרים, חלוקה יותר טובה של נתיבי PCIe (העבודה שרוב יצרני השרתים, למעט חברת Supermicro ו-TYAN עושים בשרתים שלהם בכל הקשור ל-IOMMU, שלא לדבר על SR-IOV ומיפוי הנתיבים – היא פשוט בושה!), ועוד.

ישנה קטגוריה שלמה של כרטיסים חכמים שיכולים לבצע את כל התהליכים הללו, ובצורה הרבה יותר מאובטחת, יותר מהירה ויותר אמינה. הקטגוריה הזו נקראת SmartNIC. בדרך כלל מדובר בכרטיס רשת שכולל בתוכו מעבד ARM, אחסון Flash קטן, זכרון, ויכולות רציניות לטפל בתעבורה במהירות של 100-200 ג'יגהביט, כולל אבטחה בכל רמות התקשורת, הצפנה, שרותי אחסון NVME "על סיב" ועוד. ב-VMware עסקו בשנתיים האחרונות במיגרציה של קוד ה-ESXi ל-ARM על מנת לאפשר ל-ESXi בעצם לרוץ מהכרטיס ואותו מעבד ARM יתן את כל השרותים שה-ESXi כיום נותן – רק מבלי להשתמש במעבדי ה-X86 בשרת. מעבדי ה-X86 הנ"ל יוכלו להריץ מכונות וירטואליות, קונטיינרים, ומעתה – גם Bare Metal. תוכלו להריץ בעצם כל מערכת הפעלה על "הברזל", כאשר ה-OS יקבל את שרותי התקשורת, אחסון, ניהול וכו'  דרך ה-SmartNIC באופן שקוף. בנוסף, בעזרת ה-SmartNIC ופרויקט אחר (פרויקט Bitfusion) – נוכל גם לקבל שרותים מציוד שאינו נמצא על השרת עצמו, כמו שרותי GPU, שרותי אחסון NVME Over Fiber ועוד.

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

אם העניין הזה נשמע לכם מוכר ולא מעולם VMware – אתם לא טועים. כך בדיוק עובדת אמזון עם כרטיס ה-Nitro שלהם ומאפשרת ללקוחות לשכור מיידית שרתים פיזיים, מבלי שהשרתים יעברו תהליך Provision כלשהו. הכל רץ מכרטיס עם מעבד ARM ומערכת לינוקס שרצה על הכרטיס ומבצעת את כל הפעולות, ונותנת את כל השרותים הנחוצים בצורה שקופה לשרת. גם ספקי ענן ציבורי אחרים עובדים בשיטות דומות.

פרויקט Monterey נמצא כרגע במצב Preview, אך מי שחושב כבר לקפוץ ולהתחיל להשתמש בפירות של הפרויקט, כדאי שיעצור לרגע. כרטיסי ה-SmartNIC מתחברים בחיבור של 100-200 ג'יגהביט ומעלה, כך שסביר להניח שתצטרכו מתגים אחרים יותר מהירים ויותר יקרים. מבחינת סוגי כרטיסי SmartNIC, אין כרגע הרבה הצעות (יש את Bluefield-2 של חברת מלאנוקס, אינטל, ברודקום ועוד מספר חברות יצאו עם כרטיסים כאלו בשנה הבאה) וסביר להניח שתצטרכו גם בדרך להחליף שרתים, הואיל ויש צורך בשינויים על לוח האם, כולל שינויים מהותיים לקוד ה-UEFI שבשרתים.

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

עריכת תכני מולטימדיה – תחנות עבודה מול עבודה מרחוק

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

לשיטה כזו יש כמובן יתרונות כמו "שקט" ללקוח הרוכש, אולם יש לה גם בעיות:

  • חוק מרפי אומר שאם ידפק הדיסק הקשיח של תחנת העבודה, שחזור דרך ה-Image לעולם לא יספיק ותמיד יאבדו קבצים חשובים ספציפית לאותו עורך או קבצים חשובים אחרים שנשמרו בתחנה אך מעולם לא גובו בגיבוי המרכזי.
  • Overpowered או Underpowered – בלא מעט מקרים שיצא לי לראות, הלקוח רכש מכונה שהיא או חזקה מדי לאותו סוג עבודות, או שהיא חלשה מדי. מה לעשות, לא כולם לוקחים בחשבון חישובי Single threaded Performance לתוכנות "סוררות" כמו פוטושופ, אפטר אפקט ועוד.
  • למכונה אין גיבוי בפתרון הגיבוי המרכזי, כך שאם מישהו החליט שעכשיו זה רעיון טוב לשדרג לדוגמא את פרמייר ופתאום פרמייר כלל לא מוכן לעבוד, גם לאחד הסרת הגירסה החדשה – יהיה לנו עובד ותחנה מושבתים, וכמה שעות של עבודה כדי להחזיר את התחנה לעבודה רגילה. כנ"ל גם במקרים שיש תקלות פתאומיות (כי מישהו לחץ על OK להתקין עדכוני Windows ש..אופס, דפקו את התחנה)

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

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

  • התאמה מדויקת של מכונה וירטואלית לאותו עובד. בתחנות עבודה יש צורך לקבוע מראש כמות ליבות/זכרון/סוג GPU. במכונה וירטואלית אפשר לעומת זאת "לחתוך" כמות מדוייקת ובכך למנוע בזבוז משאבים. מעבד עם 20 ליבות לדוגמא, הוא דבר מיותר לחלוטין לפוטושופ או לאפטר אפקט.
  • אפשרות שדרוג מיידית כשצריך יותר משאבים: רבים אולי לא מודעים לכך, אבל כשעורכים סרט/וידאו, עריכה "רגילה" (חיתוך, Transitions, דברים די בסיסיים) אינה מצריכה כמו זכרון VRAM גדולה. לעומת זאת, קולוריסטים שמשתמשים ב-דה-וינצ'י ויוצרי אפקטים (באותה תוכנה) יצטרכו כמות VRAM הרבה יותר גדולה, ואת זה אפשר לקבוע פר VM.
  • מכונות ה-VM הנ"ל יגובו כל יום במסגרת גיבוי מרכזי באולפן וכך, גם במקרה של תקלת "הצילו" יהיה אפשר לחזור יום אחורה בלי בעיה תוך דקות ספורות.
  • התכנים ישבו בתוך פתרון אחסון (אין צורך במשהו סופר יקר) שגם הוא יגובה, כך שגם כאן – שום תוכן לא הולך לאיבוד ולא מסתמכים יותר על פתרונות NAS שעולים 800 שקל ב-IVORY.
  • אפשר לעבוד מכל מקום – מהלאפטופ, בגינה בחוץ, אפשר להדגים בחדרי ישיבות את העבודה ועוד ועוד.
  • קל להוסיף משאבים לשרתים: GPU? זכרונות? מעבירים את מכונות ה-VM למכונה אחרת, מוסיפים, מפעילים, יוצאים ממצב Maintenance, ואפשר לפזר את המשאבים החדשים למי שצריך.

הפתרון שאני מדבר עליו קשור ל-VMware (למען האמת, גם פתרונות מתחרים כמו Nutanix, Xen יתנו את אותו פתרון) ללא שימוש ב-VDI. החיבור עצמו יכול להתבצע דרך RDP שקיים בתוך ה-VM או דרך פתרון צד ג' כמו Parsec או Teradici. מבחינת Latency, מנסיונות שביצעתי לאחרונה, הוא נמוך מאוד.

מה לגבי עבודה מרחוק, מהבית? ובכן, בישראל, לצערי ספקי אינטרנט אוהבים "לשחק" עם רוחבי הפס (הן מצד החוות שרתים והן מצד ה-DSL/כבלים). פרמייר/דה-וינצ'י/AVID ותוכנות אחרות בעבודה מרחוק דורשים רוחבי פס די משמעותיים (20-50 מגהביט), במיוחד עם פתרונות תקשורת כמו Teradici אם מעוניינים לקבל צבעים מדוייקים לקולוריסטים – ולפחות ממה שידוע לי, לפעמים אפשר לקבל תקשורת מהירה כזו ולפעמים .. לא (מהצד של ה-DSL). את זה בכל מקרה אני חושב לבדוק בקרוב.

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

בעקבות אירועי אבטחה וקורונה: כדאי VDI?

אם מחר יצא לי לפגוש חבר שהולך להתחיל את צעדיו בעולם הפרילאנס, בתחומים כמו יעוץ, אינטגרציית פתרונות וכו' – הייתי שמח לתת לו 3 טיפים חשובים בתור התחלה:

  1. לא חשוב מה הפתרון – חברות רוצות לראות שאחרים (לפחות בגודל של אותו לקוח, עדיף יותר גדול) משתמשים בפתרון
  2. שהפתרון לא יהיה Bleeding Edge
  3. הלקוח ירצה לנהל את הפתרון In House עם כמה שפחות תלות מבחוץ.

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

וזו היתה טעות רצינית. לעניות דעתי.

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

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

בעולם ה-VDI הדברים שונים. לחלוטין.

הרעיון המרכזי ב-VDI הוא שאתה יכול להתחבר אל הדסקטופ הוירטואלי עם כל סוג של ציוד, כל עוד אותו ציוד מכיל אפליקציה שיודעת "לדבר" בשפת התקשורת להתחברות ל-VDI (הדוגמא הכי נפוצה: RDP), כלומר אותו ציוד שתתחבר איתו, יכול להיות בעל מערכת הפעלה אחרת (לינוקס לדוגמא), מעבד שאינו X86 (כמו ARM), או Form Factor שאינו כולל מסך נייח (סמארטפון, טאבלט). פתרון החיבור מעביר בסופו של דבר כברירת מחדל את הקשות המקלדת, תנועות עכבר ותצוגה – דרך תקשורת מוצפנת. בברירת המחדל, אין גישה לשום ציוד מקומי כמו מדפסת, דיסקים קשיחים, חיבורי USB (שאינם מקלדת ועכבר) וכו' ובדרך כלל תהיה גם הפרדה ברמת הרשת בין גישת ה-RDP לבין התקשורת שהדסקטופ הוירטואלי עצמו משתמש – לצורך גלישה באינטרנט/אינטרה-נט לדוגמא, כך שגם אם מחשב פרוץ מתחבר, אין לו גישה ישירה אל הקבצים והתיקיות בדיסק הקשיח הוירטואלי או דרך להריץ סקריטפים מהמחשב הנייד הנגוע למכונת הדסקטופ הוירטואלית. שכבה נוספת של הגנה שקיימת בפתרונות כמו Horizon של VMware היא שימוש חד פעמי בדסקטופ וירטואלי, כך שאם המשתמש התנתק/ביצע Log out – אותו VM פשוט ימחק ויבנה מחדש, כך שגם אם מישהו הצליח לפרוץ, אותו VM "יחיה" רק בזמן סשן החיבור של המשתמש, ולאחריו – (לפי ה-Policy שנקבע) המכונה תימחק.

כל מה שתיארתי הוא די בסיסי מבחינת אבטחת מידע. אפשר מכאן והלאה לקחת את זה לרמות יותר גבוהות הכוללות בדיקת Integrity של הציוד שיתחבר (לדוגמא באנדרואיד יש SafetyNet, ב-iOS יש מספר דרכים לבדוק אם המכשיר עבור Jailbreak, וב-Windows מיקרוסופט עובדת על פתרון "שרשרת" שעובר מה-BIOS והלאה כדי לבדוק שדברים לא שונו. בלינוקס יש מספר דרכים, כאשר הדרך הפופולרית ביותר היא לחתום עם TPM על ה-Image, לבצע mount כ-read only ועוד מספר דברים על מנת למנוע tampering ב-thin client) – ובכך למנוע כמה שיותר נסיונות פריצה לרשת הפנימית של הארגון.

לסיכום: ארגונים שמריצים מערכות דסקטופ רבות (לפחות אחת פר עובד) – אני ממליץ להן לשקול ברצינות מעבר ל-VDI. כיום דרישות החומרה אינן כה גבוהות (אפשר אפילו לעשות זאת גם ללא רכישת סטורג' All Flash NVME ב-7 ספרות בדולרים) אם משתמשים בשרתים מודרניים, ולגבי מחירי License אפשר תמיד למצוא פתרון עם נציגי המכירות של יצרני פתרונות VDI השונים. אם הנתונים שלכם בחברה חשובים – כדאי לשקול זאת.

גישות SaaS/PaaS והגישה ההיברידית

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

יותר ויותר חברות תוכנה מקצצות בהשקעה של כתיבת תוכנות והפצת כ-Stand alone המיועדות לרוץ על שרתים בתשתית מקומית של הלקוח, וזאת ממספר סיבות, הנה 2 העיקריות:

  1. עלויות תמיכה – ככל שתוכנה נמכרת כ-Stand Alone, עלות התמיכה ליצרן התוכנה תהיה גבוהה, מכיוון שיש לא מעט סיכוי שהתוכנה לא תעבוד בסביבות או מכונות שונות, הרשאות שגויות, חוסר ידע טכני של הלקוח ועוד. ככל שהתומכים הטכניים יהיו עסוקים יותר ויותר שעות בפתרון בעיות של לקוח ספציפי זה או אחר, הרווח של יצרן התוכנה ירד. אחרי הכל, אף אחד לא משלם ליצרן התוכנה אם מחלקת התמיכה השקיעה 10 שעות בפתרון בעיה אצל לקוח יחיד לדוגמא.
  2. פיראטיות – בהרבה מאוד חברות הצוות מוריד אפליקציה או פלטפורמות מסויימות למטרת Trial ומיד לאחר מכן הם מחפשים כל מיני כלים ודרכים כדי לפרוץ את ה-Trial. הרווח של יצרן התוכנה ממקרים כאלו – אפס.

מהרגע שיצרן התוכנה מציע את מוצריו כ-PaaS או SaaS, הדברים נהיים יותר קלים עבורו:

  1. אין פיראטיות
  2. עלויות התמיכה מצטמצמות משמעותית הואיל והכל רץ בתשתית וירטואלית של יצרן התוכנה בעננים שונים ומקרי התמיכה נהיים יותר ויותר פשוטים כי ניתן לשחזר את התקלות במחלקת התמיכה של יצרן התוכנה.
  3. תזרים הכנסות חודשי/שנתי רציף מהלקוחות.
  4. קצב הפיתוח מואץ יותר, באגים ופונקציונאליות חדשה נכנסת ל-Life Cycle של השרות במהירות גבוהה יותר ובכך דרישות לדברים חדשים שלקוחות מבקשים – נענים במהירות גבוהה יותר.
  5. אין צורך בתמיכת Legacy הואיל וכולם עובדים על גירסה אחת או שתי גרסאות.

אך יש גם חסרונות:

  1. עלויות תשתית הרבה יותר גבוהות בענן ציבורי. בניגוד למכירת תוכנת Stand Alone שלא מתחברת החוצה, כאן פתרון ה-Saas/PaaS יצטרך חיבור קבוע למשאבים שונים של יצרן התוכנה.
  2. אבטחת המידע צריכה להיות הרבה יותר רצינית בהשוואה למקרים של תשתית סגורה החוצה. מהרגע שמתגלה אצל יצרן כזה דליפת מידע, יש סיכוי לא רע שחלק מהלקוחות יעדיפו לנטוש ולחפש פתרון מתחרה.

אלו, פחות או יותר הסיבות שבגללן חברות תוכנה יעדיפו להציע שרותי PaaS/SaaS.

אחת הנקודות שבמקרים רבים אינני רואה התייחסות מצד אותן חברות – היא למקרים שהלקוח אינו מוכן "לעבור All In", כלומר הלקוח לא מוכן שכל ה-DATA שלו ישב בתשתית של יצרנית תוכנה ולו (ללקוח) לא תהיה שליטה על הנתונים מבחינת אבטחת מידע או בכלל מהבחינה העקרונית שזה ישב בתשתית של חברה אחרת שאין לו מושג ירוק לגביה. זו לדוגמא אחת הסיבות שחברות יעדיפו לוותר על פתרון SaaS/PaaS שמוצע רק על ענן ובמקומו הם יעדיפו פתרון שרץ מההתחלה ועד הסוף על תשתית מקומית (On Prem).

מה שלעניות דעתי אותן יצרניות תוכנה PaaS/SaaS צריכות להציע – הן את האפשרויות הבאות (אחת או יותר), משהו שהוא יותר מעין "Hybrid":

  1. ה-DATA של הלקוח יכול להיות מאוחסן On Prem עם Agent שמתחבר לענן. לשרות תהיה גישה עם הרשאות מאוד מוגבלות
  2. אם ללקוח יש חשבון בענן ציבורי כלשהו, הלקוח יוכל להגדיר אחסון אובייקטים כלשהו (S3 לדוגמא) עם הרשאות מוגבלות שינתנו בעת הפעלה ראשונית של שרות ה-SaaS/PaaS והרשאות אלו יהיו תחומים למשאבים מסויימים בלבד (נניח Bucket כלשהו)
  3. הלקוח יצטרך לבחור כבר בהתחלת שימוש ה-PaaS/SaaS את ה-Passphrase שלו (ובלבד שיהיה מורכב) ועם אותו Passphrase (ואולי יחד עם עוד מספר נתונים) יוצפן ה-DATA של הלקוח כך שגם ליצרן התוכנה לא תהיה גישה לנתונים. (אפשר כמובן במקום Passphrase יהיה אפשר להשתמש במפתחות פרטי/ציבורי יחד עם Passphrase)

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

הולכים לרכוש דיסקים קשיחים? שימו לב!

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

יצרניות הדיסקים הקשיחים מנסים כל הזמן להגדיל את כמות האחסון פר דיסק ואחת השיטות שכל יצרני הדיסקים הטמיעו נקראת SMR או Shingled Magnetic Recording. בשיטה זו, כשכותבים נתונים על הדיסק ובאותו אזור שבו הדיסק רוצה לכתוב, כבר קיימים נתונים – אז הבקר של הדיסק יורה למערכת לקרוא את הנתונים הקיימים בדיסק, לצרף אותם (בזכרון המכונה) לנתונים שצריכים להיכתב – ולכתוב את הכל מחדש. כל התהליך הזה לא קיים בדיסקים קשיחים רגילים שמשתמשים בשיטת קריאה/כתיבה שנקראת PMR ולפיכך דיסקים קשיחים שעובדים בשיטת SMR מתאימים יותר לצרכי גיבוי ארכיבאי, הווה אומר: אם אתה רוצה לגבות כמות גדולה של מידע בצורה חד פעמית ולהכניס לאחר מכן את הדיסק לארון או כספת או לשלוח את הדיסק Off Site – אז דיסקים כאלו מעולים לכך. בקיצור – אלו דיסקים שמתאימים כ-WORM.

מכאן נעבור לשוק ה-NAS, השוק בו אותן חברות בדרך כלל מוכרות ללקוחות וליצרני קופסאות NAS דיסקים קשיחים בגדלים של 2-8 טרהבייט. חברות כמו Western Digital גם מייצרת 2 משפחות דיסקים ל-NAS, האחת היא סידרת RED והשניה היא סידרת Red Pro, כאשר ה-Red Pro יותר מתאים ל-Enterprise הואיל והדיסקים שם מגיעים בחיבור SAS ולא SATA. יצרנים אחרים גם יעדו דגמים ומשפחות שונים של דיסקים לשוק ה-NAS. אחרי הכל זהו שוק שגודל וסקטור ה-SMB קונה המון ממנו מחברות כמו Synology או QNAP.

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

כפי שציינתי לעיל, דיסק מבוסס SMR מתאים לצרכים של קריאה מרובה אך אינו מתאים לצרכים של כתיבה מרובה (גם לא כתיבה של 50% ומטה!) ולכן אם אתם רוצים לרכוש דיסקים לשרתים שלכם (מצד ג') או דיסקים ל-NAS שלכם, חשוב יהיה לוודא שהדיסקים עובדים בשיטה כמו PMR, CMR או שיטות מתקדמות אחרות (יש שיטות כאלו אולם עדיין לא יצאו לשוק המסחרי דיסקים המבוססים בשיטות החדשות) ולא SMR.

אז יצרני הדיסקים החליטו לעשות משהו פשוט: מכיוון שהם בטוחים ש-NAS זה רק לשוק ה-SOHO/SMB שלא מצריך כתיבה מרובה, אפשר לדחוף להם דיסקים קשיחים שהם SMR מבלי לגלות ללקוח שהדיסקים הם SMR. מדוע? כי לאותם לקוחות יש "פעילות מועטה".

חמור מכך: חברות כמו Western Digital טענה כי רק הדיסקים בגודל 20 טרהבייט שלהם עובד ב-SMR, אבל כפי שתוכלו לראות כאן וכאן, הם לא בדיוק אומרים את האמת – וגרוע מכך, הם מסרבים לענות כששואלים אותם מהי שיטת הקריאה/כתיבה של דגם ספציפי. אם יש לכם דיסקים של WD, אז אם אותם דיסקים מסתיימים ב-EFRX אז אלו דיסקים שעובדים PMR/CMR ואין שום בעיה לעבוד איתם, הם מעולים. אם לעומת זאת הדגם שלהם מסתיים ב- EFAX – אז כדאי להחליף אותם.

מאז שהתפוצצה הפרשה הזו – גם Seagate וגם טושיבה הודו שגם הם משתמשים בטריק הזה. כאן אפשר לראות לגבי הדיסקים של Seagate וכאן אפשר לראות לגבי הדיסקים של טושיבה.

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