קצת על מעבדי ה-Ryzen 4000G וחישוב מחירי מחשבים

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

סגמנט גדול הוא שוק ה-OEM במקומות גיאוגרפיים גדולים, בהם כל סנט שאפשר לחתוך – נחתך. מדובר במקומות כמו הודו, חלק מ-סין, אפריקה, דרום אמריקה וכו'. במקומות אלו, יצרני המחשב המקומיים קובעים עבור יצרני הלוחות איזה פורטים ישארו או יעופו, ובמקרים רבים מדובר בהחלטות של סנטים בודדים, לדוגמא: להשאיר HDMI, להעיף DVI – זה חוסך 3 סנט בעלות הלוח (להעיף HDMI יחסוך עוד יותר אולם רוב המסכים הזולים כיום יוצאים עם כניסות DP ו-HDMI או VGA במקום DP) ומכיוון שיצרני מחשב אלו רוכשים עשרות אלפי לוחות אם מיצרני הלוחות, אף אחד לא מתווכח.

בדיוק באותם שווקים זולים ובסגמנטים הקשורים למחשבים אישיים היתה לאינטל עד לאחרונה עדיפות מוחצת. מדוע? חוץ מהסיבה הברורה של MDF שבהחלט מתקבל בברכה ע"י מחלקות שיווק שונות של יצרני מחשבים, הסיבה השניה היתה שאינטל כורכת מעבד גרפי בתוך ה-CPU מה שחוסך הרבה כספים מבחינת רכישת חלקי מחשב עבור יצרני המחשבים. נכון, זה לא ממש יתן ביצועים גבוהים למשחקים, אבל בשווקים הללו התחרות היא To the Bottom: אם אני יכול להוריד את המחיר שלי ב-10$ בהשוואה למתחרה שלי ובכך לזכות בחוזה מכירות כמות גדולה של מחשבים לארגון גדול, לרשת מחשבים וכו' – אז למה לא?

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

ואז לפני קצת יותר משנתיים החלו בעיות היצור של אינטל ובמעבר מ-14 ננומטרים וכתוצאה מכך קיבולת היצור של אינטל ירדה בצורה משמעותית ואינטל קיבלה החלטה שמעבדים ייוצרו לפי סולם רווח, כלומר מעבדי Xeon יקבלו עדיפות גבוהה יותר ומעבדי דסקטופ (i7, i5, i3 ומטה) יקבלו עדיפות הרבה יותר נמוכה. כך נוצר מצב שיצרניות גדולות כמו HP, Dell, Lenovo ואחרים מצאו את עצמם בסיטואציות מוזרות: לקוחות רוצים לקנות מהם מחשבי דסקטופ, אבל אותן יצרניות לא יכולות למכור כי אינטל לא יכלה לייצר כמות מספקת של מעבדים. בחברת HP נשלחו הודעות בהולות למנהלי המכירות באזורים גיאוגרפיים שונים – להתחיל "להמליץ בחום" על פתרונות של החברה עם מעבדי AMD (הן לדסקטופ והן לשרתים), וחברות כמו לנובו ואפילו Dell החלו "לגשש" אצל היצרן הטקסני (AMD) לגבי מרכולתו ולגבי פתרונות עתידיים.

התשובה של AMD לסיטואציה תוצג בקרוב לציבור הרחב תחת השם: 4XXXG. החברה תציג 12 מעבדי APU חדשים שמבוססים על ארכיטקטורת הדור הנוכחי (Zen 2) אשר יכללו יחידה גרפית מובנית במעבד ואשר תהיה מהירה בצורה משמעותית בהשוואה למה שאינטל מציעים במעבדיהם. מעבדים אלו יוצעו עם כמות ליבות משתנה (בין 4 ל-8) ועם מעטפת צריכת חשמל (TDP) של 64 וואט ו-35 וואט (שיתחרו בדגמי T של אינטל).

היתרון במעבדים אלו, כמו במעבדים למחשבים ניידים – כרוך במחיר ובמה אפשר לקבל תמורת מחיר נמוך: לראשונה, צרכנים יוכלו לקבל עד 8 ליבות עם GPU מכובד (זה לא מתחרה בשום מצב בכרטיסי ה-GPU של AMD או nvidia) או כפי שאמר הסלוגן של אטארי ז"ל: Power without the price. המחירים של AMD עדיין לא פורסמו (כל הנתונים יפורסמו בקרוב) אבל רק לשם השוואה: אינטל מבקשת על מעבד עם 8 ליבות בין 340-400 דולר (המחירים שמפורסמים באתרים שונים הם מחירי K, כלומר מחירים של 1000 חתיכות).

האם לך כצרכן יהיה כדאי לרכוש אחד מהמעבדים הללו? אם אתה מסתכל רק על ההצעות של AMD – זה תלוי. אם 1000-2000 שקל בשביל GPU טוב זו תוספת שאין באפשרותך לשלם עליה, אז כן, לך על ה-4XXXG עם כמות הליבות שתרצה. לעומת זאת, אם אתה חושב לבנות מחשב עם GPU יעודי ועם עוד כרטיסים נוספים במחשב בהמשך – לך על מעבדי ה-Ryzen הרגילים. אם לעומת זאת, מהירות הליבות פר ליבה היא הדבר הכי חשוב לך (או שאתה מריץ פוטושופ רוב הזמן) – לך על המעבדים של אינטל בסידרה 10 החדשה (פרטים על ביצועי המעבדים של אינטל בסידרה החדשה יפורסמו עד יום ה' או ו' השבוע).

השוק משתנה: מעבדי ה-Ryzen Mobile, המחיר והתחרות

אינטל שולטת בשוק המחשבים הניידים שנים רבות. עד לפני בערך כ-3 שנים, אפשרויות הבחירה שלך נעו בין מחשב זול עם 2 ליבות (או 4 ליבות במהירות נמוכה) או 4 ליבות במהירות רצינית ובמחיר שמתחיל ב-1200$ ומעלה. היית יכול למצוא מחשבים ניידים עם שש ליבות – אבל המחירים של אותם מחשבים ניידים התחיל בערך ב-2000$ ומעלה לתצורות הבסיסיות, ובקיצור – אם רצית מחשב עם כח עיבוד רציני, היית צריך לשלם כמה אלפי דולרים. לכל השאר – אינטל יצרה מעבדים שננעלו במהירויות נמוכות יותר, מה שכמובן לא הצריך מצד היצרן פתרון קירור רציני.

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

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

וכאן נכנסה לשוק AMD בשנתיים האחרונות.

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

https://pcinfo.co.il/wp-content/uploads/2020/03/AMD-Ryzen-4000-Renoir-Specs-1.jpg

הדברים החלו להשתנות כש-AMD הוציאו את משפחת המעבדים הניידים (שם קוד: רנואר). בדיקות ביצועים מאתרים ומגזינים מקצועיים שונים הראו כי המעבדים החדשים מתחרים בצורה חזקה מאוד ומביסים ברוב המקרים הן את המעבדים הניידים מדור 9 ומדור 10 של אינטל (חלק מהמבחנים עדיין לא פורסמו והם יפורסמו במהלך חודש יוני – בכל הקשור למעבדים עם צריכת מעטפת של 45 וואט) והמחירים ליצרנים – זולים בצורה מאוד משמעותית בהשוואה למה שאינטל מבקשת כיום. AMD גם הוציאה סידרת מעבדי Ryzen Mobile Pro הכוללים ניהול מרוכז עבור ארגונים הדורשים זאת (משהו זהה ל-vPro של אינטל) ולקינוח – AMD יכריזו בחודש הבא על מעבדי APU (מעבדים הכוללים יחידת GPU קטנה) שתתחרה במעבדים זולים של אינטל – עד 8 ליבות (עדיין לא ניתן להרבות בפרטים, הם יפורסמו רשמית כבר בקרוב).

התוצאה? בחודשים האחרונים צרכנים מגלים כי גם במחשבים ניידים זולים (600-800$) הם יכולים למצוא דגמים עם 6 או 8 ליבות ועם ביצועים חזקים, דבר שלא נשמע כמוהו בעבר, והמכירות – בהתאם. חברת Lenovo לדוגמא יצאה עם ה-IdeaPad סדרות 3 ו-5 עם מספר דגמים, חלק מהם עם מעבדי Ryzen החדשים של AMD וחלק מהם עם מעבדים דור 10 למחשבים ניידים של אינטל. כשמחפשים לרכוש את הדגמים עם מעבדי AMD, מוצאים כמעט בכל מקום כי המלאי אזל, ומה שזמין לרכישה – הם הדגמים עם מעבדי אינטל. גם חברת ASUS וגם חברת Acer דיווחה על כך. החברות שמו בהחלט לב לכך ו-Lenovo לדוגמא כבר מוציאה החודש מחשבים ניידים מסידרת Legion עם מעבדי Ryzen החדשים כאשר רק בחודש ינואר אפילו לא היתה תוכנית לתכנן מחשב נייד כזה.

כתוצאה מהסיטואציה החדשה, דברים אחרים מקבלים יותר תשומת לב ברכישה. אתה יכול למצוא מחשב נייד זול עם 6 או 8 ליבות במחיר של 600-800$, אבל לא מומלץ לרכוש את המחשבים הללו רק בגלל המעבדים! כדאי לבדוק את המקלדות, את ה-Track Pad והכי חשוב – איכות מסך ובהירות, ועדיף שיהיה כמה שיותר זכרון, מכיוון שבמחירים אלו, לא ניתן להרחיב את הזכרון במחשבים ניידים אלו.

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

גישות 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 וכאן אפשר לראות לגבי הדיסקים של טושיבה.

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

הוירוס, עבודה מרחוק – והלאפטופ

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

מהרגע שעניין הוירוס קיבל דחיפות יותר ויותר גדולה בארץ, חברות עטו על יבואני מחשבים לרכוש לאפטופים לעובדים, בין אם מדובר ברכישה קטנה של בודדים או מאות. כל לאפטופ קיבל טיפול פירמוט והתקנת Image עם כל האפליקציות של החברה, חיבור VPN, חיבור לשיחות וידאו ועוד מספר דברים – וכך כיום רוב החברות עובדות: מרחוק, עם VPN, עם Zoom/teams/WebEx/Skype לצורך פגישות ושיחות וכו'.

וכאן גם מתחילה הבעיה הגדולה, בכל מה שקשור לאבטחת מידע: ככל שיש יותר לאפטופים מבוססי Windows/Mac שמתחברים לרשת הארגונית דרך ה-VPN, הסיכוי לפריצה – גדול עד גדול מאוד. אף קבוצה שפורצת לא מחפשת לפרוץ ישירות את התשתית הארגונית בכך שינסו לתקוף את ה-Firewall/IPS/IDS, הכל עושים "מסביב", דרך קבלני משנה, דרך לאפטופים של עובדים שלא מבינים כלום באבטחת מידע. כל מה שצריך בסופו של יום זה פשוט לפרוץ ללאפטופ שנמצא בבית במגוון שיטות, וברגע שאותו לאפטופ יהיה מחובר דרך ה-VPN, הפורץ יוכל להריץ ברקע מגוון סקריפטים כדי לסרוק/לגנוב מידע ועוד. לא מאמינים? תכירו את חברת Visser, קבלן משנה של NASA, SpaceX, Tesla ועוד מספר חברות – דרכה פרצו לאותן חברות וגנבו מידע ומאוחר יותר פרסמו אותו.

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

האם ניתן לעשות משהו בנידון? כן.

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

  1. ממבוזר – למרוכז. אחד הדברים הראשונים שצריך לעשות, הוא, מה לעשות, לעבור לפתרון VDI. עם תשתית VDI (ואני מדבר על תשתית VDI שרצה על מכונות VM, פחות על פתרונות של VDI לאפליקציות ספציפיות) אפשר להנות ממספר יתרונות:
    1. אין צורך בדרייברים שמגיעים מיצרני לאפטופים ומחשבים. בפתרון VDI מבוסס VMware לדוגמא, יש צורך בהתקנה של ה-VMware Tools וזה כבר יתקין את הדרייברים הנחוצים ותו לא. כך נחסוך בעיות של חורי אבטחה בדרייברים.
    2. הרבה יותר קל לנהל צי של מכונות וירטואליות מבחינת הקמה/כיבוי/הגדרות וכל ה-Life Cycle בהשווה לטיפול במכונה פיזית.
    3. אין צורך להתקין ערימת אפליקציות על Image. יש כלים כמו ThinApp או Enigma Virtual Box (לא להתבלבל בין זה לבין וירטואליזציית VirtualBox – אלו 2 דברים שונים) שנותנים אפשרות להריץ אפליקציות שהמשתמש צריך ללא צורך בהתקנה מראש, כך שהמשתמש יכול לקבל Image עם המינימום שבמינימום ולינקים לדברים נוספים בהתאם להרשאות ולצורך. כך אפשר להוריד את וקטור התקיפה – אין צורך בקורא PDF ישן או אפליקציות אחרות שהמשתמש לא צריך אותם.
  2. מעבר לשימוש ב-Thin Client. כן, כל לאפטופ יכול להתחבר ל-VPN בקלות, אבל אותו לאפטופ הוא מטרה מעולה וקלה מאוד לפריצה. לעומת זאת, מכשירי Thin Client טובים (Dell, HPE, Lenovo – כולם מוכרים כאלו) הם קשים יותר לפריצה הואיל והמערכת הפעלה הלינוקסאית שבתוכם מגיעה מראש כ-Read Only, וקשה יותר לפרוץ אליה מאשר ללאפטופ או לדסקטופ. אפשר לקחת את זה צעד קדימה ופשוט להשתמש במערכות כמו Stratodesk עם דיסק און קי שנחסום אותו לכתיבה – שממנו נבצע Boot, את זה הרבה יותר קשה לפרוץ.
  3. מניעת שימוש במשאבי אחסון מקומיים. מניעת אפשרות גישה לכונן C בלאפטופ המקומי יכולה לעזור בכך שגם לפורץ לא תהיה אפשרות העלאת סקריפטים וקבצים אחרים למכונת VM שהמשתמש יתחבר אליה. אפשר תמיד להקים File Server בתשתית המקומית ולמפות לכל משתמש כמה עשרות ג'יגהבייט כדיסק רשת לאחסון דברים.

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

  • אין צורך ברכישת אחסון סופר-יקר AFA עבור VDI. אפשר להשתמש עם דיסקים מקומיים ו-vSAN. הכי חשוב שהדיסק SSD המשמש לצרכי Caching יהיה SSD טוב, כמו Optane, הואיל ורוב העבודה של VDI עולה מה-Cache וכמעט שלא מהדיסקים האחרים.
  • אין צורך לרכוש כרטיסי GPU יקרים כולל מנוי חודשי ל-nVidia, כל עוד המשתמשים מבצעים עבודות בסיסיות ולא עבודות וידאו/תלת-מימד או עבודות הכרחיות.
  • מומלץ לרכוש מעבדים עם Cache גדול (מכיוון שהמעבד, בהיעדר GPU, מרנדר את התצוגה, ה-L3 Cache שלו חשוב, כמה שיותר גדול, יותר טוב). כיום מעבדי AMD EPYC כמו 7F72, 7F52, 7F32 הם מעבדים מעולים לכך (שימו לב, אלו מעבדים שהוכרזו רק שלשום, נכון לכתיבת שורות אלו, והם יוצעו למכירה ללקוחות בתחילת החודש הקרוב).
  • מומלץ לשנות/לשדרג/להחליף לרשיון "כרוך" (Bundle) ולא לרכוש עצמאית תוספת רשיון. דברו עם נציג שיווק פתרון הוירוטואליזציה שלכם.
  • אין צורך לרכוש במאות דולרים Thin Client. אפשר את הפתרון של Stratodesk (לינק למעלה) יחד עם Raspberry Pi 3/4 ובכך לחסוך יותר מ-50% מהמחיר פר חתיכה.

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

האם שווה לרכוש VxRail או Nutanix Appliance?

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

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

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

לפני שנוכל לענות על כך, ננסה להסתכל במבט על – על התשתית ב-DC המקומי של החברה. בכל ארגון גדול בדרך כלל תהיה תשתית Life cycle management כלשהי שנועדה בראש ובראשונה להציג לנו את מצב החומרה שיש ב-DC, בין אם מדובר במתגים, אחסון, שרתים, UPS וכו'. יצרניות השרתים לדוגמא כוללות גירסה פשוטה של ניהול השרת וגירסת Enterprise בתוספת תשלום. אותו ניהול יתריע בפנינו אם יש תקלת חומרה, אם יש צורך להחליף חומרה וכו'. בפתרונות אחסון יש משהו קרוב שמתריע שעלינו להחליף דיסק או להתייחס לבעיה אחרת, וכנ"ל במתגים, UPS וכו'. בדרך כלל אנחנו נחבר את כל המערכות הללו למערכת ניטור מרכזית אחת שתוציא לנו התראות לכל הדברים הנדרשים.

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

היתרון השני שעליו מדברים יצרני הקופסאות הוא ניהול הרבה יותר קל של אותן קופסאות. בקופסאות עם VxRail לדוגמא, יש את תוכנת VxRail Manager (הנה הדגמה) שנותנת לך לא רק לחבר שרת חדש ל-Cluster קיים, אלא גם להתקין תוכנות מה-Market, לתחזק את השרתים, לכבות, להדליק וכו'. אבל כפי שציינתי לעיל – חברות מעדיפות לנהל את הדברים במרוכז, כך שאם לחברה יש נניח מערכת iDrac Enterprise, עדיף לחבר את כל קופסאות ה-VxRail ל-iDrac Enterprise ולנהל משם, ולא דרך ה-VxRail Manager, ואותו דבר לגבי קופסאות שמריצות פתרון HCI של Nutanix.

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

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

לעומת זאת, למי לא כדאי לרכוש את הקופסאות הללו:

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

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

הכנות לסיטואציית בידוד

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

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

  • רוחב פס: יש לכם 100 מגה או 1 ג'יגה או יותר – רוחב פס לחיבור לאינטרנט, ועליו אתם מחברים משתמשים דרך VPN. גם אם יש לכם 1 ג'יגה, זה לא אומר שיש לכם 1 ג'יגה נטו ל-VPN, רחוק מכך: כל VPN מממש הצפנה בדרך משלו (עם Ciphers שונים, תלוי במעבד שיש בקופסא או מה שהוגדר ב-Appliance הוירטואלי וכו') כך שעם חיבור 1 ג'יגה לדוגמא, יכול להיות שיש לכם אולי 500-600 מגהביט ברוטו. אם יש לכם כמה עשרות משתמשים שמתחברים לחיבור כזה (ונוסיף לכך את הגלישה באינטרנט שתעבור דרך החיבור הזה) אתם תמצאו את עצמכם מהר מאוד בבעיה של איטיות גלישה/התחברות/גישה לקבצים.
    אפשר לשם הניסוי לחבר מספר משתמשים סימולטנית ל-VPN שיש ברשותכם ולנסות לבצע חישוב מהירות כמה כל משתמש מקבל ולחלק את זה תיאורתית בהמשך, אבל תצטרכו בהמשך לקחת כאופציה את העניין שתצטרכו מהר מאוד לשכור רוחב פס הרבה יותר גדול ולבדוק שהתשתית VPN שלכם יכולה לעמוד בכמות גדולה של חיבורים.
  • ענן ציבורי ו-VPN משני: אפשרות נוספת לגבי חיבורי VPN של המשתמשים, אם הקמתם כבר תשתית בענן ציבורי כלשהו (אני מדבר על השלישיה, לא על "עננים" מקומיים ישראליים) – אפשר להקים VPN בתשתית הוירטואלית, לחבר את אותה תשתית וירטואלית ב-Site to site אל ה-VPN המקומי בארץ בארץ ולאפשר למשתמשים להתחבר דרך הענן אל התשתית המקומית שלכם. אתם תשלמו על התעבורה ועל שרות ה-VPN בענן, אבל אתם תשלמו רק על השימוש, לא תשלום חודשי/שנתי.
  • העברת חלק מהתשתית לענן ציבורי: תלוי בחברה ובתשתית, בחלק מהמקרים ניתן לשכפל מספר מערכות או פשוט להעביר מספר מערכות לתשתיות וירטואליות בענן הציבורי ואותן תשתיות יתנו שרות למשתמשים מבחוץ. חשוב לדאוג לסינכרוניזציה בשני הכיוונים (בין הענן לתשתית On Prem). לעניות דעתי, כדאי לחשוב על כך.
  • בדיקת תשתיות ניטור: במשרד רואים על מסכים גדולים את התקלות, מה רץ, מה לא. בבית – לא רואים כלום, ולכן חשוב לבדוק שאפליקציות הניטור שולחות התראות דרך תשתיות חיצוניות (מייל, SMS, וואצאפ וכו') ושיש מי שיטפל בתקלות (עבודה מהבית במקרים רבים אצל לא מעט אנשים היא סיבה מצויינת "להבריז" לטובת דברים אחרים).
  • צפו לתקלות תקשורת: אם בעתיד יוכרז במדינה "עוצר" (כפי שהוכרז אתמול באיטליה), תקלות תקשורת לא יהיו "אם" אלא "מתי" (פה בישראל, אל תאמינו לשום ספק תקשורת לגבי שרידות, ראינו את זה רק לפני שבועיים כמדומני, בתשתית של בזק/מטרו) ולכן כדאי לתת את הדעת על פעילות המערכת On Prem כשאין תקשורת ומה כדאי להוציא החוצה לענן הציבורי בחשבונכם וב-VPC שלכם שימשיך לעבוד.

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

בהצלחה.

על דיסקים ואחסון

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

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

אבל מה קורה אם יש צורך להזמין כמות גדולה של דיסקים? (ב"גדולה" אני מדבר על כמויות של 30 ומעלה – בתור התחלה). ניקח את זה יותר לכיוון המציאות: אתם רוצים להקים תשתית וירטואליזציה Scale Out עם vSAN או Nutanix. אתם לא רוצים עדיין לרוץ לכיוון All Flash ולכן אתם רוצים לשלב דיסקים מכניים גדולים יחד עם SSD שישמשו כ-Cache. ב-2 הפתרונות המתחרים, כמות ה"ברוטו" מבחינת הדיסקים שתכניסו – רחוקה מאוד מכמות ה"נטו" שתקבלו בפועל לשימוש, ולכן אם נרצה כמות תלת ספרתית של אחסון נטו פנוי, נצטרך לרכוש לא מעט דיסקים עבור מינימום 3 שרתים. נניח לשם הפוסט – שנצטרך 21 דיסקים מכניים ו-3 SSD (כלומר 7 מכניים ו-1 SSD פר שרת).

לפני שנעבור לחישובים שונים, בוא נשנה לרגע נושא ונדבר על שרידות: כיום בשוק, אצל רוב מוחלט של החברות, מצב השרידות שקיים הוא מצב שהמערכת יכולה להמשיך לעבוד, כל עוד דיסק אחד הוא תקול. במקרה והתקלקל דיסק, מפעילים את ה-SLA ותוך 4 שעות יגיע טכנאי ויתן לכם דיסק חלופי, תחליפו את הדיסק בשרת/מערך אחסון, הפעילו תהליך Rebuild. מה יקרה אם יתקלקל עוד דיסק עוד לפני שהקודם הוחלף ובוצע Rebuild? תקוו שהגדרתם דיסק אחד כ-Hot Spare – אחרת אתם בצרות.

נחזור לחישובים: כיום, בין אם מדובר בישראל או כמעט בכל מקום אחר בעולם, רכישת דיסק קשיח, בין אם מדובר ב-SSD או מדובר בדיסק מכני, תעלה אצל יצרן שרתים פי 2-3 בהשוואה לרכישה מיבואן רשמי בארץ. תרגום: אם דיסק כלשהו עולה $100 אצל יבואן רשמי, אצל יצרן שרתים, אותו דיסק יעלה 300-$200. את ההבדל הזה די קל לבלוע כשמדובר על רכישה של שרת אחד עם 4-5 דיסקים. ראש שקט, רכישה חד פעמית, תשלום חד פעמי, לא עושים מזה סיפור.

אבל אם נסתכל על הדוגמא לעיל עם ה-Scale Out בשביל ה-Nutanix/vSAN (או GlusterFS, או Ceph), אנחנו מדברים על 21 דיסקים, ואנחנו נשלם בפועל מחיר של 50-60 דיסקים. אתם לא צריכים להאמין לי, אתם יכולים ליצור קשר ישירות עם היבואנים בארץ:

  • דיסקים של חברת טושיבה – חברת CRG
  • דיסקים של חברות Seagate, Western Digital – חברת ח.י.

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

אז במקרים שהרעיון של תשלום סכום כה מטורף קצת מפריע לכם – אפשר לחשוב על שרידות ברמה אחרת: במקום לרכוש 21 דיסקים מיצרן השרתים, אפשר לרכוש נניח 25 דיסקים מהיבואן (כל עוד לא מדובר עבור שרתי HPE – הם לא מקבלים דיסקים שאינם בעלי קושחה של HPE), ולאחסן 4 דיסקים בארון. במקרה והתקלקל דיסק, מוציאים אחד מהארון ובמקביל יוצרים קשר עם היבואן כדי לתאם שליחות/קבלה של דיסק חלופי אחר. במקרים כאלו, גם אם עוד דיסק ילך במהלך ה-Rebuild, יהיו לכם מספיק דיסקים חלופיים ועל הדרך תחסכו לא מעט כספים.

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

על אחסון, וירטואליזציה, ובעיות ביצועים

כמעט כל ארגון שמריץ פתרון וירטואליזציה (vSphere, Hyper-V, Xen, ואחרים) בדרך כלל משתמש בפתרון אחסון משותף לשרתים, בין אם מדובר בפתרון "הרכבה עצמית" (FreeNAS), פתרון קופסתי זול (Synology, Asustor, QNAP וכו') ובין אם מדובר במשהו קצת יותר גדול מצד חברות כמו HPE, IBM, Lenovo, Dell, NetApp, EMC וכו'. יש פתרון לכל תקציב.

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

אפשר לקטלג את סוגי התקלות ל-2 סוגים עיקריים. לסוג הראשון אני קורא "תקלות אבסולוטיות" ולסוג השני – "תקלות מעורפלות".

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

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

אני רוצה לתת דוגמא מה-LAB שלי. לפניכם צילום מסך מתוך מכונת VM ב-vSphere 6.7 שמריצה Windows 10 עם Crystal Diskmark 7. השרתים מחוברים לשרת ZFS עם 8 דיסקים מכניים ואין בו שום SSD, בחיבור 10 ג'יגהביט +SFP. על הנייר, כל מי שמבין באחסון, יאמר שהמספרים מעולים – 1.2 ג'יגהבייט קריאה/כתיבה על חיבור של 10 ג'יגהביט – זה המקסימום שאפשר לקבל.

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

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

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

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

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

  • הדבר הראשון שאני ממליץ, זה להשתמש בכלי בשם FIO. את הקוד של הכלי הזה אני ממליץ לקמפל באופן סטטי (בשימוש הפרמטר build-static– ), לפתוח תיקיה ב-Datastore כלשהו ולהעלות את הקובץ FIO הבינארי שקומפל לשם, ולוודא שיש לו הרשאות Executable. את הקובץ נריץ דרך SSH.
    הכלי (FIO) נותן לנו למדוד את מהירות הקריאה והכתיבה שיש לנו עם מדדים ופרמטרים שונים ובכך נוכל לדעת מהי מהירות הקריאה והכתיבה בין האחסון לשרת עצמו ישירות. כך נוכל לדעת אם הבעיה קשורה בתקשורת בין האחסון לשרת ולא בין האחסון למכונת VM כלשהי. חשוב: לבצע את הבדיקה עם כמה שפחות מכונות VM רצות על אותו שרת.
  • אנחנו יכולים להשתמש באותו כלי (ולחובבי Windows – יש את IOMeter שמבוסס על הקוד של FIO. את הכלי הזה, אגב, אפשר להריץ ישירות על Windows Server פיזי אם מדובר במכונה שנותנת שרותים דרך Hyper-V) כדי למדוד את אותם דברים שמדדנו קודם – אך הפעם אנחנו נמדוד בין מכונת ה-VM לאחסון, תוך שימוש ב-Datastore ובדיסק הקשיח הוירטואלי של אותו VM. שימו לב: התוצאות יכולות להיות שונות מהתוצאות שנקבל כתוצאה מבדיקה דרך הסעיף הקודם, הואיל והתרגום לדיסק הוירטואלי גובה מספר אחוזים בביצועים.
  • אם אתם מאלו שאוהבים כמה שיותר DATA כדי לאסוף כמה שיותר תובנות, בנו לעצמכם סקריפט שמשתמש ב-FIO כדי לבצע דגימות שונות ולאסוף את הנתונים לקובץ מסוים כדי לנתח אחר כך ולבדוק דגרגציה של פתרון האחסון ועוד.
  • אם הבעיה קיימת רק עם מכונות VM מסויימות, אז הבעיה אינה ממש קשורה לתקלות באחסון אלא יותר בכח של פתרון האחסון. הגיע הזמן להחליף למשהו יותר לכיוון ה-All Flash או לפחות עם פתרון Flash לכתיבה ו-Caching.
  • זה ישמע טריוואלי – אבל תפרידו תקשורת ברמה של פורטים ואם אפשר גם ברמה של סוויצ' – בין התקשורת מהאחסון לשרתים, לבין כל שאר הדברים. אני משער שחלק מהקוראים יאמרו "מה הבעיה עם VLAN?", אין בעיה – רק שבמקרים רבים אותם אלו שמגדירים נוטים לחתוך פינות ולפעמים ההגדרות לא יהיו נכונות ולא יסייעו. מצד שני – סוויצ' 10 ג'יגה כיום הוא דבר די זול.
  • דבר אחרון – כלים רגילים שמודדים ביצועים של דיסקים מכניים או SSD לא רלוונטיים במקרים של התקלות המדוברות בפוסט זה. זה נחמד להציג תמונות (או כדי למכור ללקוחות מצגת על פתרון) אבל התוצאות לא יהיו באמת נכונות (אתם באמת חושבים שמכונת ה-ZFS  הנ"ל בפועל יכולה לכתוב 1.2 ג'יגה בשניה בשעה שאין שום SSD? לא ממש, אבל ZFS יכול "לעבוד" על VMWare ובכך אפשר להציג את התוצאות הנ"ל, אם יש מספיק RAM בשרת, ובמקרה הזה – יש, 256 ג'יגה).

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

הדרך לאימוץ טכנולוגיות חדשות

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

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

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

אז איך בעצם מתקדמים, למה כדאי להקשיב, מה כדאי לעשות או ללמוד?

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

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

  • מה הדרישות מהפתרון שאתם מגדירים כ-Must, זה יכול להיות: כמות אחסון נטו, כמות IOPS שתהיה זמינה גם בעומס, רוחב פס מסוים, תמיכה בציוד מסוים. אני מדבר על רשימה מסודרת של דרישות חובה מאותו פתרון.
  • מה הדרישות ש"טוב שיהיה" – זוכרים את אותו פרויקט שבהנהלה מדברים עליו הרבה זמן אבל אף אחד לא תיקצב אותו עדיין? תכניסו את הדרישות שלו בסעיף הזה (הדבר האחרון שאתם רוצים זה מצב שמישהו בהנהלה יחליט לאשר תקצוב לאותו פרויקט והפתרון החדש שרכשתם כלל לא כולל את אותם משאבים להרצת אותו פרויקט!). נסו לחשוב ולבדוק קדימה היכן ואיך אתם הולכים לגדול במהלך השנה-שנתיים-שלוש הקרובות והכניסו את אותן דרישות (לסעיף ה-Must או לסעיף "טוב שיהיה")
  • תקציב מינימום-מקסימום. את הסעיף הזה אתם כמובן שומרים לעצמכם ולא מפרסמים בשום מקום. את הסעיף הזה אפשר למלא אחר כך, כשיש לכם מספר הצעות מתחרות, אבל בכל מקרה, חשוב לקחת בחשבון דברים כמו כמות רשיונות נכונה – רבים וגדולים נופלים בדיוק על הדבר הזה.
  • האם הפתרון מצריך רכישת ציוד נוסף? במקרים בהם מדובר בפתרון תוכנה, הדרישות הרשמיות המינימליות יהיו בלתי מציאותיות (אהלן, מיקרוסופט) ובפועל הפתרון ירוץ בצורה איטית – תשאלו חברים שמריצים את הפתרון על מה הם מריצים את הפתרון ואיך הביצועים. ראיתי מספיק פרויקטים שנידחו כי הפתרון נרכש אבל בשרתים לא היה מספיק משאבים מבחינת זכרון ו-CPU או משאבי תקשורת. קחו את זה בחשבון.

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

  • עניין ה-"הם רכשו" – בנק מסוים רכש, חברות X,Y,Z הגדולות והידועות קנו את המוצר, ואם הם קנו, אז אתם יכולים להיות רגועים ולהבין מכך שהמוצר הוא מ-ע-ו-ל-ה ובהחלט מתאים לכם.
    • את המידע הזה כדאי להכניס לראש בקטגוריית "נחמד לדעת" אבל לא לתת לזה להשפיע עליכם מסיבה פשוטה: אינכם יודעים מה גודל הפתרון שניקנה, האם הוא נקנה רק כי אותו לקוח קיבל הנחה ענקית, והאם אותו לקוח משתמש בזה רק באחוז קטן מאוד מהתשתית שלו. אתם לא מצפים שבנק מסוים, אם תתקשרו אליו, יתחיל לפרט לכם מה התשתיות שלו, נכון?
    • תשתיות שונות – נציגי השיווק מציינים בגאווה שהמוצר רץ בחברה גדולה X. למעט פתרונות חומרה, קשה מאוד לדעת על איזו חומרה ועל איזה ציוד הפתרון רץ, כך שיכול להיות שאצל אותו לקוח הפתרון יטוס, אולם עקב תקציב מינימלי שיש לכם, הפתרון ירוץ אצלכם בצורה איטית.
  • שאלות ותשובות – חשוב לזכור: נציגי הפתרון רוצים למכור לכם את הפתרון ולכן כל פתרון מתחרה הוא זבל ומי שתומך/ממליץ על המוצר המתחרה – בכלל לא מבין בתחום. לא תשמעו דברים טובים על הפתרונות המתחרים ולשאלות טכניות במקרים רבים תקבלו תשובות סובייקטיביות.
  • נקודה חשובה מאוד: במהלך הישיבה יובטחו לכם דברים שונים (מבחינת ביצועים, עלויות וכו') – שום הבטחה לא שווה אלא אם היא כתובה בלשון ברורה על הנייר וחתומה. ראיתי מספיק מקרים שבו נמכרו ללקוחות פתרונות אחסון עם הבטחה לכמות IOPS מסוימת, ואחרי שנתיים כשלהקוח הפסיק לקבל את אותם IOPS וכשהוא פנה אליי, הסתבר שנציגי המכירות לא ממש טרחו להסביר לו את עניין ה-Wear Leveling.

ככל שתפגשו עם יותר נציגים שמוכרים פתרונות שונים, תקבלו יותר ויותר מידע מוטעה. הנציג הקודם עם המוצר המתחרה הבטיח X מבחינת ביצועים? אפשר לקבל את X במוצר המתחרה – אם תשקיעו עוד 100,000$ בחומרה לדוגמא. בקיצור – תתכוננו להטעיות (עם/בלי כוונה).

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

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

קיבלתם יעוץ ובחרתם פתרון? ברכותיי. עכשיו הגיע השלב להטמיע את הפתרון.

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

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

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

בהצלחה.