מעבר לענן – תכנונים, עדיפויות ומציאות

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

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

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

ניקח לדוגמא תשתית פשוטה: יש לנו 2 מכונות, אחת מריצה MySQL והשניה מריצה שרת Web NGINX ושרת שלישי שמריץ אפליקציות על Tomcat. התשתית הזו נגישה החוצה לציבור שמבצע אותנטיקציה עם שם משתמש/סיסמא והתשתית יושבת מאחורי Firewall (ואולי מערכות הגנה נוספות).

אם נסתכל על התשתית הזו בתצורה המקומית, סביר להניח שהמכונה שמריצה את ה-NGINX תהיה חשופה (מבחינת כתובת IP) לאינטרנט עם פורט 80 או 443 פתוח החוצה ב-Firewall עם כתובת IP אמיתית או שתהיה כתובת חיצונית ב-Firewall שתמופה אל כתובת IP פנימית. יהיו כאלו שיטמיעו את מכונת ה-NGINX ב-DMZ עם 2 רגליים – אחת ב-DMZ ואחת ב-LAN, כך שה-NGINX יוכל לדבר עם ה-Tomcat ברשת הפנימית (מכונת ה-Tomcat ומכונת ה-MySQL לא יהיו זמינות מבחוץ כלל).

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

  • אנחנו נצטרך להקים VPC שיכלול:
    • חלוקה ל-Subnets ששם ישבו מכונות בהתאם לקטגוריות שאנחנו בונים: Prod, testing, stage, devel וכו'. רובם לא יקבלו כלל כתובות IP אמיתיות.
    • Internet Gateway שיתן ל-Subnet שנבחר גישת אינטרנט החוצה
    • Elastic IP – שיהיה מחובר ספציפית למכונת ה-NGINX
    • NAT Gateway – שיאפשר למכונות הפנימיות לגשת לאינטרנט מבפנים החוצה (אך לא ההיפך)
    • Network ACL – שישמש כ-Stateless Firewall על מנת להחליט מי יכול לצאת ודרך איזה פורטים
    • Security Groups (שהולכים עם Network ACL) – שם נגדיר ספציפית מאלו כתובות ואלו פורטים יוכלו להיכנס לשרת(ים).
    • ויש עוד כמה צעדים, וחברות רבות גם יוסיפו כאן אולי Appliance Firewall מסחרי בנוסף למה שאמזון נותנת ועוד ועוד…

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

לאחר מכן אנחנו נקים מכונות ב-EC2. נצטרך לבחור Template של מכונה מהקטלוג, בחירת ה-VPC, וכמובן – גודל Storage מקומי למכונה. כאן הדברים שונים מהסטורג' שנמצא אצל חברות – ב-AWS תוכל לבחור בין General Purpose SSD לבין Provisioned IOPS SSD שהוא הרבה יותר מהיר והאפשרות השלישית היא דיסקים מגנטיים (מבלי אפשרות לבחור IOPS). ההבדל (חוץ מביצועים) בין ה-General ל-Provisioned מתבטא לא רק בביצועים אלא גם במחיר (ב-Provisioned הוא הרבה יותר גבוה) וראיתי מספר מקרים שבחרו ב-Provisioned והתפלאו מדוע המחיר טס בכמה מאות דולרים פר מכונה. לאחר הגדרות הסטורג' נצטרך לבחור תגים (Tags) אם נרצה, את ה-Security Groups (אם לא הגדרנו קודם), מפתח PEM להתחברות ולבסוף נאשר את הכל ו-AWS יקים לנו את המכונה. לאחר מספר דקות נוכל להתחבר אליה אם הגדרנו שהיא תקבל כתובת IP אמיתית דינמית או ללא כתובת IP דינמית דרך מכונת Bastian או דרך חיבור Direct שיש לנו אל ה-VPC. משם נגדיר פנימית את המכונה, נקים עוד כמה מכונות וכו' וכו'.

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

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

כפי שציינתי לעיל, יש פתרון כמו VMWare on AWS שמאפשר לך "להרחיב" את המערכת המקומית שלכם לענן אך ממשיך להשתמש במושגים ובטכנולוגיות של VMWare. אם ניקח לדוגמא את 3 המכונות מהדוגמא הקודמת, נוכל בקלות לבצע עבורם Migrate לתשתית ה-VMWare on AWS בענן וכל מה שנצטרך לשנות לפני המעבר זה החיבור ל-vSwitch/DVSwitch, לבחור לאן לאחסן את המכונות ועוד מספר פרמטרים – והמערכת תבצע את השאר בצורה עצמאית.

חברות רבות לעומת זאת מחפשות משהו יותר "מעונן" – הן מחפשות דברים כמו שרצים בענן, אך שירוצו מקומית עם אפשרות שימוש ב-Hybrid להעברת עומסים, מבלי להיות תלוים בפתרון של VMware (או שהם כלל לא משתמשים ב-VMware). מיקרוסופט לדוגמא מציעה את Azure Stack – מדובר בערימה של שרתים שמריצים תוכנות, סקריפטים ודברים נוספים על המכונות הללו והתשתית הזו יושבת ב-DC המקומי של הלקוח והוא מקבל גירסה מזערית של Azure מקומית עם אפשרות להתרחב ל-Azure הגלובאלי ובכך לעבוד או מקומית בלבד תוך שימוש בכלים הרגילים על Azure (מתאים לגופים בטחוניים לדוגמא) או שימוש כ-Hybrid כמקומי והעברה פנימה והחוצה לענן הציבורי. גם אמזון הכריזה על פתרון דומה שנקרא AWS Outposts וגוגל גם בונים פתרון כזה (אם כי עדיין לא ראיתי שום הכרזה קונקרטית על משהו מצד גוגל).

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

אלו שרוצים משהו פחות מחייב ויותר מדבר על פתרון Hybrid שמתייחס לקונטיינרים ומכונות VM יכול להשתמש כמובן ב-Open Stack והוידאו הבא מסביר בהרחבה איך ניתן לחבר OpenStack מקומי לעננים הציבוריים השונים.

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

על בנייה ואבטחת מערכות משובצות

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

עם כניסת ה-Raspberry Pi ושלל החיקויים שלו, יותר ויותר אנשים החלו לגלות את עולם ה-SBC (כלומר Single Board Computer – לוח אחד שעליו נמצא הכל, כולל מעבד, זכרון, אחסון ושלל חיבורים לעולם החיצון) ושוק המערכות המשובצות החל לקבל "ניעור" רציני. חברות המייצרות פתרונות הכוללות מערכות משובצות ראו שניתן לרכוש בכמה עשרות דולרים מערכות SBC ל-Embedded, מה שגרם למתחרים הותיקים להוריד מחירים. למי שאינו מכיר – הכרטיסון בתמונה הוא מחשב Raspberry Pi Zero שכולל כל מה שצריך (למעט חיבור רשת קווית שאפשר להוסיף במספר דרכים). העלות? 5 דולר, וזו סתם דוגמא ל-SBC זול שיכול לבצע פרויקטים שונים.

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

  • עצמאית או C/S? אחד הדברים הראשונים החשובים הוא להחליט איך המערכת תרוץ בעצם. האם מדובר במערכת עצמאית שאין לה תקשורת לשום שרת (עצמאית) או C/S (כלומר Client Server)? אם מדובר במערכת עצמאית, אז נצטרך להתקין עליה את כל האפליקציות (תיכף ארחיב על כך), ולדאוג לכך שהיא תפעל כמעט בכל מצב אפשרי, כולל מצב חרום שבו היא יכולה להציג למפעיל אם יש תקלה, מה התקלה ומה קוד התקלה כדי שיצרן הפתרון יוכל לטפל בכך.
    אם מדובר ב-C/S לעומת זאת, אז יהיה כדאי לבנות מערכת כמה שיותר רזה (לא להתקין הפצת לינוקס על המערכת אלא להשתמש ב-Yocto לדוגמא) וכל אפליקציה נחוצה תרוץ על השרת וביניהם התקשורת תעבור ב-TCP/IP, שימוש ב-Web Sockets וכו'.
    אם מדובר במערכת שיש לה תקשורת לשרת אך התקשורת אינה קבועה (אחת לשעה, אחת ליום וכו') אז כדאי יהיה לבנות אותה למצב אחסון זמני כך שברגע שהתקשורת מבוצעת, כל הנתונים מועברים לשרת, מתבצעת בדיקה שהנתונים נשמרו על השרת באופן תקני (אפשר להשתמש במגוון שיטות checksum) ולאחר מכן הנתונים ימחקו מהמערכת המשובצת. מבחינת אפליקציות להתקנה, נצטרך למצוא מה ניתן עדיין להריץ על השרת הרחוק ומה צריך לרוץ מקומית.
  • לא לדסקטופ: יש לא מעט מפתחי מערכות משובצות, שברגע שהם מקבלים מערכת משובצת עם 4 ליבות, 1-4 ג'יגהבייט זכרון ו-64 ג'יגה אחסון eMMC – בונים מערכת כאילו זה לינוקס דסקטופ. זה לא רעיון טוב הואיל וכל מעבד PC פשוט עוקף בסיבוב כל מעבד של מערכת משובצת. בנוסף, מערכות משובצות בקושי מקבלות עדכונים אם בכלל כך שיש סיכוי לא קטן שמערכת כזו בסופו של דבר תיפרץ ומכיוון שמערכות כאלו לא מעודכנות כמעט, הפורץ יכול להיכנס ולהשתמש ברשת הפנימית ובמערכת המשובצת כפי שירצה.
  • דיאטה: מערכת צריכה להיות כמה שיותר קטנה על מנת להקטין את וקטור התקיפה ולאפשר תחזוקה (אם צריך) קלה, ולכן לא מומלץ להתקין עליה מערכות אפליקציות שרת רגילות. צריכים לדוגמא SQL? תכירו את SQLite. צריכים שרת HTTP? יש מספר אפשרויות שמתאימות למערכות משובצות או httpd שמגיע כחלק מ-BusyBox או שימוש בשרת Web מובנה שקיים בפייתון/GO.
  • שפות כתיבת קוד: אם הפתרון הולך לרוץ כ-C/S, אז אתם יכולים לכתוב באיזו שפה שבא לכם ולהריץ את הקוד על השרת. אם זו מערכת עצמאית, אז אני ממליץ לכתוב בפייתון, Go או PERL (לוותיקים שביניכם) וסקריפטים ניתן ב-Bash או Python. יהיו כמובן חברות שירצו לכתוב קוד ב-JAVA או DOT NET (אפשר להריץ Dot Net Core על לינוקס), אבל חשוב לזכור שאם המערכת מבוססת על ARM ותרוץ עצמאית, אפליקציות כמו Wildfly או runtime של Dot Net Core לוקחות לא מעט משאבים ובלא מעט מקרים גורמות למערכת להגיב בצורה איטית.
    חשוב: לא לכתוב קוד אסמבלר יעודי למעבד. נכון, קוד אסמבלר זה נחמד ונותן מהירות (היום זה פחות רלוונטי, GCC מוציא קוד אסמבלי מעולה!) אבל פעם הבאה שהחברה תחליט להחליף מעבד, מישהו יצטרך לשכתב המון קוד אסמבלר מחדש ולכן אני ממליץ לא להיכנס לביצה הזו.
  • רדו מ-Windows: אתם בוודאי נתקלתם בזה בעבר – כספומטים שמגיבים באיטיות, מערכות מידע שלא מגיבות או שפשוט תקועות, קופות רושמות שנתקעות באמצע העברת מוצרים אצל הקופאית ועוד ועוד. מדוע ישנם הרבה פתרונות מבוססי Windows? כי מיקרוסופט מספרת כמה ה-Windows (כולל גירסת ה-Embedded) "יציבה", חברות גדולות עד לפני מס' שנים כתבו קוד שרץ רק על Windows, בנו "פתרון" שמורכב על PC פשוט והרי לכם מערכת שגם עם מיטב המומחים עדיין מצליחה להיות בלתי יציבה ואיטית פתאום.
    כיום ניתן לבנות מערכת משובצת מבוססת לינוקס שלא תתפוס יותר מ-80 מגהבייט אחסון (בערך) ותרוץ יפה על 1 ג'יגהבייט זכרון והמערכת תכלול דפדפן ותמיכה במסך מגע וכל המערכת תעלה מרגע החיבור לחשמל תוך 8-12 שניות עם הצגת לוגו לקוח בשניה הראשונה ולאחר 10-12 שניות הלקוח האנושי יכול להשתמש במערכת בתוך דפדפן סגור (כך שניתן להציג גרפיקה, OpenGL, אנימציה וכו' וגם לחבר את המערכת לציודים אחרים אם צריך).
    מדוע לא עוברים למערכת כזו? בחלק מהמקרים יהיה צורך לכתוב קוד חדש (במקרים כמו קופות), בחלק מהמקרים מדובר בחששות לא מבוססים, ובחלק מהמקרים עקב אי ידיעה או אי הכרת הדברים. אני מקווה בקרוב לקבל כמה מערכות משובצות, לבנות כמה מערכות דמה ולהוציא קליפים להדגמה ביוטיוב..
  • אבטחת מידע: זוכרים שאמרתי שלא כדאי להתקין הפצת לינוקס על מערכת משובצת? זה אחד הדברים הראשונים שפורץ ינסה להשתמש לטובתו, ולכן מומלץ לעבוד עם Busy Box סופר מצומצם במכונה שיכלול אך ורק פקודות הכרחיות, לצמצם הרשאות, לא להריץ הכל כ-root, ואם אפשר – לעבוד עם מפתחות והצפנה, בשביל זה כמעט כל מערכת משובצת מכילה רכיב TPM (לחובבי Raspberry Pi – יש חלק שניתן לרכוש, להרכיב ולהשתמש מבלי להלחים חוטים). אם המכשיר הולך להיבנות בסין, קחו בחשבון שינסו לגנוב לכם את הקוד ולכן הצפנה היא מאוד חשובה.
  • פשוט זה חכםתכירו את אחד החתולים הביתיים שלי – זהו נימי. מדוע אני מציג אותו? כי רמת המשכל של נימי שווה בערך לרמת המשכל של חלק מהאנשים בסין שיבנו ויקימו את המערכת ללקוח ובחלק מהמקרים – זו גם תהיה רמת המשכל של אלו שישתמשו במערכת (כבר ראיתי מישהו שמנסה להכניס בכח את כרטיס האשראי שלו לחור ממנו יוצאת הפתקית בכספומט!).
    לכן – אם המערכת שלכם כוללת אחסון (eMMC, SSD, לא מומלץ דיסק קשיח מכני, SSD הרבה יותר אמין) ואתם צריכים להקים Installer שירוץ על PC ויתקין את המערכת שלכם על הלוח SBC, תשתמשו בכמה שיותר אוטומציה ותנסו לצפות ולפתור כל תקלה אפשרית. אם המערכת נמסרה וישנה תקלה במערכת, תעלו אותה מחדש אוטומטית כך שברגע שהמשתמש יכנס דרך הדפדפן, התקלה תוצג והלקוח יוכל לשלוח לכם צילום מסך שלה.
    חשוב לנסות (אם התקציב מאפשר) לבנות מערכת Dual Boot (מערכת u-boot תומכת בכך) כך שניתן יהיה לשדרג מרחוק את המערכת עם Image תקין, ואפשר להשתמש בגירסת SystemD האחרונה כדי לעלות למערכת חרום אם המערכת הנוכחית לא עולה (אפשר לקרוא על כך כאן).
  • דלת אחורית/כניסה מרחוק: לא תמיד אתם יודעים היכן המערכת תרוץ ואתם לא יודעים מתי ומאיפה תקבלו בקשת תמיכה, ולכן חשוב לבנות זאת כחלק מהמערכת. אל תצפו ממשתמש קצה להקיש פקודות או שתקבלו בלא מעט מקרים – תוצאות מביכות.

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

כשצריכים שרת קטן

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

כל יצרני השרתים מייצרים סוגים מסויימים של שרתים שנמכרים בכמויות גדולות, ואלו שרתי ה-1U וה-2U ה"רגילים": מעבד יחיד או זוג של Xeon, זכרון, דיסקים וכו'. מחירי השרתים הללו (חדשים) בדרך כלל מתחילים בסביבות ה-3000$ לתצורה מינימלית.

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

חברת DELL הוציאה לאחרונה בדיוק שרת כזה. תכירו – זהו שרת R340.

השרת הזה הוא שרת 1U אך הוא שרת שהוא קטן פיזית, כך שהוא יכול להיכנס בקלות בארון עם עומק של 80 ס"מ. השרת עצמו בנוי עם לוח אם ש"הושאל" מתחנת עבודה: אין לו תושבת LGA-3647 אלא תושבת של מעבדי דסקטופ (LGA-1151). המעבדים שנתמכים בשרת כזה הם מעבדים כמו ה-Intel® Pentium G5500 ועד מעבדי Intel® Xeon® E-2126G – עד 6 ליבות ו-12 נימים. מבחינת זכרון – אפשר להכניס עד 64 ג'יגהבייט זכרון (בהמשך יצא עדכון שיאפשר להכניס מקלות DIMM של 32 ג'יגהבייט זכרון וכך ניתן יהיה להרחיב את המכונה לזכרון של 128 ג'יגהבייט). מבחינת אכסון ניתן להכניס או 4 דיסקים 3.5" או 8 דיסקים 2.5". השרת כולל ניהול (iDRAC), ניתן להחליף את חיבורי הרשת (יש 2) מ-1 ג'יגהביט ל-10 ג'יגהביט, ויש גם תמיכה לכרטיסי מיקרו SD וגם למקלוני אחסון M.2.

בקיצור – שרת סולידי בקצה התחתון.

נו, אז מה המחיר של מכונה כזו? ובכן, מכונה כזו עם מעבד Xeon E-2124 עם 4 ליבות, 8 ג'יגהבייט זכרון ודיסק 1 טרהבייט יעלו לך (בארה"ב) כ-1569$. אני מאמין שבארץ המחיר יהיה שונה ויותר גבוה, אבל אני לא מאמין שזה יגיע לכפול מכך. למי שרוצה לחסוך עוד במחיר, יש גם את דגם R240 עם אותה קונפיגורציה ב-1319$ (שוב, מחירי ארה"ב Online), אך הוא אינו מתאים לאלו שרוצים להתחיל עם מעבד שאינו Xeon.

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

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

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

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

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

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

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

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

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

מעבדים: כולם מכירים את המעבדים של אינטל (i3,i5,i7) אך לאינטל יש גם תתי דגמים למעבדים השונים. הדגמים שציינתי, אם יש להם בסוף U לדוגמא, כמות הליבות היא כמחצית ממעבד ללא האות U, והם נמצאים במחשבים היותר קטנים (מה שנקרא SFF) אך הם אינם יותר זולים (תתפלאו, במקרים רבים הם יותר יקרים מהמעבדים ללא האות U). בל נשכח שמחירי המעבדים במחצית השנה האחרונה עלו בממוצע בכ-20%.

נקודה חשובה לציין: במחשבי ה-SFF המעבדים יעבדו בערך במחצית המהירות של מעבדים רגילים הואיל והקירור במקרים רבים הוא פאסיבי או עם מאוורר קטן (החלפה של המאוורר לא תעזור הואיל וזה קשור למעבד, לא לקירור)
אפשרות שתמיד קיימת לכם – היא לבחון את מעבדי AMD. בדרך כלל המחיר שלהם נמוך בכ-400-600 שקל מהמעבד המקביל של אינטל מבלי לספוג הנחתת ביצועים רצינית (הבדלי הביצועים נעים בכ-5-9% לטובת אינטל) כך שניתן לקבל הנחה רצינית פר מכונה. בנוסף, מקבלים גם ניהול מרחוק שבנוי בתוך המעבד לטובת התמיכה הטכנית הפנימית בחברה (כמו ה-vPro של אינטל).

זכרון: בעקרון המינימום המומלץ כיום הוא 8 ג'יגהבייט לפקידות, ו-16 ג'יגהבייט לשאר (למפתחים מומלץ 32 ג'יגהבייט). מהירות הזכרון המינימלית המומלצת היא 2666 מגהרץ וחשוב מאוד: הזכרון אמור להגיע בזוגות, כלומר אם אנחנו מזמינים מכונה עם 8 ג'יגהבייט של זכרון, שזה יגיע ב-2 מקלות של 4 ולא במקל אחד של 8 ג'יגהבייט, אחרת סתם מפסידים ביצועים.

דיסק קשיח: ברוב המקרים מומלץ לקחת SSD, הואיל ודיסק קשיח זול פחות אמין מ-SSD מהדור הנוכחי. המינימום המומלץ: 250 ג'יגהבייט אבל עדיף לשקול את גרסאות ה-500 ג'יגהבייט, בהתאם למחיר שיתנו לכם.

כרטיסים גרפיים ומסכים: ברוב המקרים המחשבים שתרכשו כבר כוללים פתרון גרפי או במעבד או ככרטיס במחשב. אם אלו מחשבים חדשים ואתם הולכים לרכוש איתם מסכים, ריכשו מסכים עם חיבור Display Port שהוא חיבור הרבה יותר אמין מ-VGA או DVI וכל המסכים כיום תומכים בו. ככלל, מחירי המסכים ירדו (גם בארץ) וניתן להשיג גם מסכים שהם יותר מ-20 אינטש במחיר זול מאוד ולכן מומלץ לחשוב על הוצאת רכישת מסכים במכרז נפרד.

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

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

לסיכום: חשוב לשים לב מה אתם רוצים לרכוש לפני שאתם מוציאים מכרז. אפשר ורצוי להפריד סוגי מחשבים אם אתם צריכים מחשבים ל-2 מחלקות שונות כאשר כל אחת צריכה מפרט שונה, ולא מומלץ ללכת על ה-Low Bottom, במיוחד שמחשבים אלו אמורים לשרת את המשתמשים במשך 4+ שנים. אם יש לכם שאלות, אפשר ליצור קשר.

מערכות משובצות ומצבי "קיוסק"

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

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

  • עדכוני אבטחה – קשה להתקין עדכוני אבטחה ל-Windows כשאין לך תקשורת חיצונית, ומה לעשות ש-Windows דורש המון עדכוני אבטחה.
  • מחיר רשיון – 150-200$ לרשיון Windows Pro (מחיר שונה ל-Windows Embedded אבל כיום המוצר מאבד פופולריות במהירות לטובת פתרונות מבוססי Linux).
  • קבלת Latency נמוך – לא חשוב כמה תכוונן את Windows, תמיד יהיו "קפיצות" שישבשו את ה-Latency.

לכן הרוב עוברים למערכות מבוססות ARM.

לוחות מבוססי מעבדי ARM כדוגמת I.MX6/7/8 ומעבדים אחרים קיימים בשוק זמן רב ובשנים האחרונות המחירים צונחים (בעיקר עקב פופולריות של Raspberry Pi). מחשב קטן שרק לפני כמה שנים היה עולה מאות דולרים, צנח למחירים שכיום נמדדים בעשרות דולרים (כולל אחסון קבוע כמו eMMC). פאנלים ללוחות כאלו קל לחבר (דרך LVDS לדוגמא) והתוספת ל-Touch היא דולרים בודדים, ולכן יש רצון מצד חברות שונות לבנות פתרונות שאותם הם משלבים במוצריהם – הכוללים מעבדי ARM, עם צג מגע וחוויית משתמש טובה. יש אפילו חברה מסויימת שמייצרת Appliance בגודל 1U .. .עם מסך מגע נשלף. לאן הגענו….

לקוח כזה בסופו של דבר צריך לבנות Image שיוכנס ב-eMMC של הלוח. ה-Image אמור לכלול את כל חלקי התוכנה ויש מספר אפשרויות:

  • לינוקס "רגיל" – אפשרות אחת היא לקחת הפצת לינוקס רגילה (Debian, CentOS וכו') עם Kernel שמגיע מיצרן (או שהאינטגרטור מקמפל תוך שימוש ב-BSP, Cross compiler וכו') ופשוט מקימים לינוקס עם התקנת התוכנות הנדרשות (בשימוש yum/apt) וההגדרות הכרוכות בכך, ולבסוף מכינים Image. יש כלים כמו kickstart (ל-CentOS) או Preseed (ל-Debian) כדי להכין Image כזה.
    הבעיה בשיטה זו היא שיש צורך בידע רציני להגדיר את הסביבה הגרפית (Xorg, Wayland, שימוש ב-OpenGL וכו') מכיוון שאין אוטומציה שניתן להשאיל מ-X86 ויש צורך להשקיע מאמצים מרובים להגדיר את הכל.
    חסרון נוסף: אבטחה. במקרים רבים החבילות המגיעות עם תלויות שאין בהן צורך עבור אותה מערכת משובצת ולכן יש לקמפל את החבילות מחדש ללא אותן תלויות או במקרה היותר קשה – לבטל/להחליף תלויות באחרות. חבילות מיותרות ופונקציונאליות שאינה דרושה, גם אם אינן מופעלות יכולות פוטנציאלית לגרום לחורי אבטחה במערכת.
  • Yocto – אחד הכלים הכי פופולריים. עם Yocto אפשר ליצור Image מצומצם לדברים שאנו צריכים בלבד. מערכת Yocto בונה לנו את כל המערכת ולבסוף מכינה Image שניתן "לזרוק" על כרטיס מיקרו SD או על eMMC. המערכת מספיק חכמה בשביל לא לקמפל חבילות שכבר קומפלו ולא היה בהן שינויים, וכל יצרן לוחות ARM תומך בה.
    החסרון עם Yocto: בלא מעט מקרים תצטרך לדעת איך לבנות Recipe כדי להוסיף את החבילה שאתה רוצה ועם אלו ספריות ו-Compile Flags לעיתים. בנוסף – תצטרך להוסיף את ההגדרות לכל חבילה שתרצה בתוך ה-Yocto. בכל הקשור לגרפיקה – גם כאן, תצטרך לשבור את הראש איך להגדיר את הדברים.
  • Boot2QT – זהו מוצר של חברת TrollTech שמשתמש ב-Yocto כדי לבנות מערכת גרפית מוכנה. לא תצטרך לשבור את הראש על Touch, על הגדרות Frame Buffer או Xorg ופרמטרים אחרים. מוצר הדגל של החברה (QT Creator) נותן לך לכתוב אפליקציות גרפיות ולנסות אותן על מחשבך או ישירות על המערכת המשובצת (מבלי להכין כל פעם Image מחדש כדי לנסות את הקוד שכתבת). המערכת קטנה ועולה תוך שניות ספורות. היא גם הופכת את החיים להרבה יותר קלים מבחינת שימוש ב-Yocto והיא מסתירה לא מעט חלקים מורכבים ומטפלת בקומפילציה.
    החסרון: זו מערכת מסחרית. ישנה גירסה חופשית אך אם תשתמש בה, תצטרך לשחרר את כל הקוד שכתבת באפליקציה הגרפית.
  • Android – עוד פתרון שחברת "אגד" לדוגמא – שמחה לאמץ אותו לנהגים כמערכת קופה/כרטוס. כל יצרן מערכת ARM בדרך כלל משחרר גירסת אנדרואיד ולחברה שרוצה להשתמש בכך, ניתן לקחת את גירסת האנדרואיד ולהוריד חלקים שאין צורך בהם, ואם צריך לכתוב אפליקציות יעודיות, לא חסרים מפתחי אנדרואיד (וכן, יש גם מצב קיוסק באנדרואיד) כך שניתן לכתוב את האפליקציה ולשלב אותה ב-Android הפנימי שיווצר ל-Image שירוץ על המערכת. אם צריכים חבילות לינוקס, אפשר להרים מערכת כמו Linux Deploy שתרוץ ברקע, להקים הפצת לינוקס מינימלית שצריכים עם החבילות הדרושות ואז מהאפליקציה שלכם לתקשר דרך Socket או דרך TCP אל האפליקציה (אישית עשיתי זאת פעמיים וזה הציל פעם אחת פרויקט מביטול מאחר והאפשרויות האחרונות לא אפשרו התקנת חבילות מסויימות).
    החסרון: אם מחפשים Boot של 3-5 שניות – תשכחו מזה. בנוסף, קימפול קרנל למערכת אנדרואיד אינו עניין פשוט הואיל ויש לא מעט חלקים שאנדרואיד כן צריך והפצות לינוקס רגילות לא צריכות.

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

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

סקירה מקדימה: מעבד AMD EPYC ROME

בשבוע שעבר אינטל החלה לחשוף מספר נתונים על מעבדי על Cascade Lake AP שלהם. כשאני מדבר על "מספר נתונים", אני מדבר על פירורים ורמזים – הרבה מאוד מידע חסר. אינטל חשפה את המידע יום אחד לפני ש-AMD חשפו את מעבדי ה-EPYC החדשים תחת הקוד "ROME" (רומא, כל הקודים של מעבדי EPYC קשורים למקומות/ערים באיטליה).

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

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

ב-2017, אחרי שההנהלה הוחלפה וד"ר ליסה סו נכנסה לתפקיד המנכ"לית, הציגה AMD את ארכיקטורת ZEN, ואת מעבדי ה-EPYC, ו-AMD הציגו את המעבד הראשון בעולם עם 32 ליבות, 64 נימים ותמיכה של עד 2 טרהבייט זכרון פר מעבד. מבחינת ביצועים, אם נשווה את ה-EPYC למעבדי ה-Xeon SP, מעבדי ה-EPYC של AMD מובילים ב-2 קטגוריות עיקריות:

  • וירטואליזציה, כולל VDI
  • קונטיינרים

ב-2 המקרים, מעבדי ה-EPYC נותנים יתרונות ברורים על פני מעבדי Xeon SP, הן במצב וירטואליזציה "קלאסי" (סטורג' חיצוני, מכונות VM רצות על ברזלים) והן בפתרונות Hyper Converged (סטורג', רשת, Compute – הכל רץ על הברזלים המקומיים). ב-VDI היתרון של EPYC הוא שניתן להכניס הרבה יותר סשנים/מכונות וירטואליות פר ברזל מבלי לשלם את המחירים הגבוהים של מעבדי Xeon SP. כשזה מגיע לעומת זאת לאפליקציות ופלטפורמות שרצים על הברזל כמו Deep Learning, AI, רינדור תלת מימד ועוד מספר דברים (או מכונת VM שמשתמשת ברוב הליבות) – היתרון למעבדי Xeon SP ברור (אם כי רק בדגמים של Gold ו-Titanium). הביצועים היו יותר נמוכים עקב הארכיקטורה של המעבד שנתנה ביצועי Latency יותר גבוהים, תלוי על איזה ליבות או פיסת סיליקון נופלים, דבר שלא משנה ממש בוירטואליזציה/קונטיינרים וניתן להגדרה בקלות עם CPU Affinity.

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

בתמונה משמאל נוכל לראות את המעבד בגירסה הראשונה: 4 מעבדים שמכילים את כל מה שצריך (I/O, PCIe, ניהול זכרון וכו') בתוך כל אחד מהם. בתמונה למעלה נוכל לראות תצורה שונה לחלוטין: כל מלבן קטנטן שרואים בתמונה (AMD קוראים להם Chiplets) הם פיסות סיליקון שמכילות כל אחת מהן 8 ליבות (וסך הכל 64 ליבות במעבד בקצה הגבוה) אך ללא הדברים האחרים כמו ניהול זכרון, I/O, PCIe ועוד. מי שדואג לכל הדברים הוא המלבן האמצעי הגדול – זהו ה-I/O מודול שכולל את כל מה שצריך בשרת, הוא מנהל את הזכרון מה-Chiplets ואליהם, תעבורה, חיבור למעבדים וציוד אחר ועוד. בשיטה הזו, מהירויות תעבורת הנתונים וה-Latency הם צפויים וקבועים. כך בעצם AMD מסירה מה-Chiplets כל דבר שאינו קשור ישירות לליבות והביצועים יותר גבוהים בהשוואה למעבדי EPYC מדור קודם: פי 2 בהשוואה לדור קודם בעבודות רגילות, ופי 4 כשמדובר על Floating Point. ב-AMD החליטו גם להיות הראשונים (במעבדי X86-64) לצאת עם מעבדים עם תמיכת PCIe 4.0 כך שרוחב הפס לכל כרטיס PCIe הוא כפול ושבב ה-I/O יוכל לתקשר איתם במהירות כפולה בהשוואה לכל מעבד של אינטל.

מבחינת תאימות, AMD מאוד אוהבת סולידיות (כמו הלקוחות שלהם) ולכן מעבדי ה-EPYC החדשים יכולים להיות מוכנסים לשרתים הנוכחיים, לעדכן BIOS/UEFI ולקבל גם את הביצועים הגבוהים וגם כמות ליבות גבוהה (עד 64 ליבות פר מעבד) באותו שרת, ו-AMD מבטיחים שגם משפחת ה-EPYC הבאה (שם קוד: "Milan" שתצא ב-2020) תהיה תואמת לאותה תושבת, כך שניתן יהיה לשדרג כל שרת קדימה.

בזמן הצגת המעבד, ב-AMD החליטו קצת להתעמר באינטל עם הדגמת C-RAY, זו תוכנה לחישובי תלת מימד שמשתמשת רק במעבד (לא ב-GPU), והם השוו מכונה עם 2 מעבדי Xeon SP 8180M (זה המעבד הכי גבוה שיש לאינטל להציע ללקוחות, עם 28 ליבות פר מעבד) מול מכונה עם מעבד יחיד של EPYC החדש, וזה נראה כך:

ה-Sales Pitch של AMD לחברות שמריצות פתרונות וירטואליזציה הוא כזה: מחירי המעבדים שלנו זולים ב-60% מהמעבדים של אינטל בקצה הגבוה. אתה יכול לחסוך חשמל, ניהול מכונות וחסכון ברשיונות וירטואליזציה (הם מדברים על VMWare, לא על הפתרונות של מיקרוסופט) בכך שתעבור לכמות קטנה של שרתים מבוססי EPYC החדשים. הוידאו כולו המציג את המעבדים החדשים, את 2 כרטיסי ה-GPU החדשים ל-Data Center, עננים וחסכון ב-Datacenter אפשר לראות בוידאו הבא (הקישור לוידאו מתחיל בחלק של החסכון, תרגישו חופשי לרוץ קדימה ואחורה בוידאו):

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

על בחירת מחשב תעשייתי/מוקשח

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

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

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

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

  • סוג מעבד: במקרים של מחשבים תעשייתיים, את סוג המעבד יש לקבוע בהתאם לעבודה שאותו מחשב אמור לבצע. אין שום סיבה לרכוש i7 אם המחשב מבצע עבודה שמעבד עם ביצועים נמוכים יותר יוכל לעשות מבלי לפגוע בביצועים. בניגוד לדסקטופ, כאן בהחלט מומלץ גם לשקול מעבדים מבוססי ARM, מעבדי ATOM של אינטל, או EPYC Embedded של AMD.
  • חיבור ציוד עם USB: חיבור ציודים עם USB הוא בעייתי. בניגוד לחיבורים כמו VGA או DVI או Display Port שכוללים ברגים או מנגנון לנעילת החיבור, USB הוא לא החיבור הכי יציב, ולכן אם חייבים לחבר ציוד בעזרת USB, יש צורך לדאוג לפתרון בולם זעזועים מחוץ למחשב. ללא פתרון לזעזועים, המערכת תדווח בזמן עבודה על חיבור/ניתוק ציודים באופן תכוף.
  • אמצעי אחסון: לא מומלץ להשתמש בדיסקים מכניים. הדיסקים המכניים כוללים בתוכם בולם זעזועים, אבל אם הפתרון מצריך נסיעות בדרכים או עמידה בתנאים קיצוניים הכוללים תנועה, פתרון הבולם זעזועים הפנימי לא תמיד יפעל טוב (הבולם זעזועים מתאים למקרים של נפילה פיזית פתאומית אחת לזמן רב, לא כל מספר דקות). בעבר ההמלצה היתה להשתמש ב-SATADOM (שהוא בעצם Flash Disk שנכנס ישירות לתוך חיבור SATA ומצריך חיבור חשמל על לוח האם), אולם כיום מומלץ להשתמש ב-SSD בחיבור M.2 הכולל 2 ברגים לחיזוק החיבור. M.2 הרבה יותר אמין ועומד בכבוד גם בזעזועים על טרקטורים.
  • שימוש בכרטיסי PCIe: אין בעיה להכניס כרטיסי PCIe (יש מעט דגמים של מחשבים תעשייתיים המאפשרים הכנסת כרטיסי PCIe) בפתרונות הללו, אולם מומלץ אם אפשר – לחפש כרטיסי Mini PCIe עם אותה פונקציונאליות. כמו ב-M.2, הפתרון מוברג ומוחזק בצורה יותר טובה.
  • שימוש במאווררים: רוב המחשבים התעשייתיים הם מחשבים שקטים, ודרישת השקט מגיעה במקרים רבים מהלקוחות וכך יצרני אותם מחשבים עושים הכל על מנת שהמחשב יהיה שקט. יחד עם זאת, יש לעיתים צורך (בהתאם לתצורה) להחליף את המאווררים הכלולים במאווררים אחרים. הדבר האחרון שמומלץ הוא להשתמש במאווררים רגילים שעולים 30 שקל. יש צורך לבדוק את כמות ה-RPM וה-CFM ואז לרכוש את המאווררים המתאימים או לבקש מהיצרן מאווררים אחרים או המלצות על מאווררים אחרים. מאווררים שאינם תואמים עלולים לגרום לנזק למחשב.

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

ה"מפלצות" החדשות של אינטל

אינטל החלה לאחרונה לחשוף יותר ויותר פרטים על המעבדים החדשים מסידרת Cascade Lake לשרתים, אלו מעבדים שישבו תחת המשפחה "Cascade Lake SP" והמשפחה הזו תהיה היורשת של הדגמים מסוג "Skylake SP". בימים האחרונים הציגה אינטל פרטים ראשונים על נגזרת ממשפחת ה-Cascade Lake ואותה נגזרת נקראת Cascade Lake AP.

הסיפור (הלא רשמי) בכל מה שקשור ל-Cascade Lake AP (שמעתה פשוט אקרא לו בפוסט: AP) הוא פשוט: AMD הוציאה את מעבדי ה-EPYC שלהם עם גרסאות עד 32 ליבות. מעבדי ה-EPYC בנויים בעצם ממספר מעבדים שיושבים בחבילה אחת. כך לדוגמא, מעבד עם 32 ליבות מכיל 4 פיסות סיליקון שכל אחת מהן מכילה 8 ליבות.

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

עובדתית, הדברים אינם נכונים, מה גם שמבחינת ביצועים, המעבדים של AMD עוקפים את המעבדי שרתים של אינטל בכל הקשור לוירטואליזציה וקונטיינרים, אבל איך אומרים באנגלית: Water Under the bridge. מה שלא השתנה – זה שאינטל רוצה עכשיו להתחרות במספר ה-Cores מול AMD וכמובן לגרוף מכך רווחים רציניים. לגטימי? בהחלט.

מה שאינטל כן עשו, הם בעצם החליטו לעשות "Me Too" כמו ש-AMD עושים, רק עם שינויים. מעבדי ה-AP יהיו עם עד 48 ליבות. מה שאינטל בעצם עושים, זה לקחת 2 פיסות סיליקון של ה-SP (כלומר Cascade Lake SP) שכל אחד מהם עם 28 ליבות, לבטל לכל אחד מהם 4 ליבות, להכניס אותם לחבילה אחת (עם תושבת שונה ממה שיש כיום, ההערכות בשוק מדברות על LGA 5903), ובכך למכור ללקוח מכונה עם 2 מעבדים שתכיל בעצם 96 ליבות.

איך יבוצע החיבור בין הליבות עצמן ובין הליבות לבין המעבד השני? דרך חיבור שאינטל המציאה ומשתמשת ב-SP, שנקרא UPI. החלק של ה-UPI הוא חלק מאוד חשוב: חיבור לא אופטימלי יתן תקשורת יותר איטית בין הליבות ובין המעבדים, אבל לאינטל יש נסיון. כרגע לא ניתן ממש להרחיב לגבי ה-UPI במעבדי AP הואיל ואינטל לא פרסמה את התצורה שבה היא תפרוס את חיבורי ה-UPI (ופרטים רבים נוספים על הארכיטקטוטרה והמעבדים), וההערכות הן שאינטל תפרסם יותר פרטים בשבוע הבא, בכנס ה-Super Computing 2018.

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

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

אינטל גם הציעה מעבדים שמתאימים לשרתים עם תמיכה ל-4 עד 8 מעבדים (בעבר אלו היו מעבדי Xeon E7, כיום הם אותם מעבדי Xeon SP אם כי מסידרת ה-Gold או Platinum). הבעיה (שבגינה אני לא ממליץ לרכוש שרתים כאלו, ויש להבדיל בין שרת 2U/3U/4U עם 4-8 מעבדים לבין מארז Blade ששם הדברים שונים לחלוטין) המרכזית היא שה-Scaling שתצורות כאלו נותנות אינו נותן ביצועים ששווים את המחיר של שרת כזה. זה לא רק ש-חץ בן חמו לא ממליץ, זו המלצה שניתנת ע"י מאות ואלפי אנשי מקצוע בארץ ובעולם, ובגלל זה הרוב פשוט רוכשים שרתים עם מקסימום 2 מעבדים, ונראה שאינטל הבינו את הפואנטה עם מעבדי ה-AP, שם התצורה המקסימלית תהיה עד 2 מעבדים.

למי מיועדים המעבדים והמערכות הללו? ברוב המקרים, התשובה היא: לספקי העננים הגדולים ובמיוחד לאלו שנותנים שרותים של Deep Learning/AI. לשאר החברות, מחיר של שרת עם 2 מעבדי AP יהיה יותר גבוה מ-2 שרתים עם מעבדי SP בתוכם.

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

התקציב השנתי ורכישת ציוד

יש חברות שכבר הספיקו לתכנן את תקציב ה-IT לשנה הקרובה, יש כאלו שעדיין יושבים על המספרים. כמובן שאצל כל חברה הדברים שונים, יהיו כאלו שירצו בשנה הקרובה להחליף שרתים, להחליף סטורג', אולי לרכוש PC חדשים, לשדרג ל-SSD, לעבור לתקשורת פנימית יותר מהירה (10/40/50/100 ג'יגהביט), וכמובן שיש את כל עניין הפלטפורמות: לעבור לקונטיינרים, הטמעת CI/CD, להתחיל לעבוד בתצורת AGILE, לשכור אנשים/חברות ללמד את העובדים טכנולוגיות חדשות וכו'.

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

נתחיל בסטורג' SDS.

את עולם הסטורג' לקצה התחתון עד הבינוני ניתן לחלק ל-2: סטורג' קנייני (כזה שמגיע עם "ראש", מדפים), וסטורג' מבוסס תוכנה (SDS – כלומר Software Defined Storage). אם תשאלו את אנשי השיווק של הסטורג' הקנייני, תקבלו הילולים מכאן עד הודעה חדשה כמה הוא יציב, וכמה "לא כדאי" לרכוש SDS. המצב במציאות – די הפוך. בואו נאמר שאתם הולכים להוציא $50,000 על פתרון סטורג' ואתם מבקשים מכל העולם והחתול שלו הצעות מחיר לסטורג'. רוב ההצעות שתקבלו – הם SDS, גם אם הם לא יקראו כך בכותרת.

באופן עקרוני, סטורג' SDS מבוסס בעצם על חלקים COTS (כלומר Common Off The Shelf), כלומר שרת SDS אינו שונה מהותית מכל שרת שיש לכם בחדר/חוות שרתים שלכם. יש בו זכרון, מעבדים, בקר דיסקים, דיסקים קשיחים, וכרטיסי רשת. 2 הדברים ששונים בין סטורג' SDS לשרת רגיל הם בקר דיסקים (בחלק מהמקרים יש SAS Expander ו/או בקר RAID יותר יוקרתי הכולל תמיכה ל-SSD Caching) וכרטיסי רשת לחיבור מהיר (10/40/50 ג'יגה). הדבר העיקרי שהופך את השרת ל-סטורג', זו בעצם התוכנה שרצה עליו.

אחת השאלות הראשונות שאני נשאל לגבי פתרונות כאלו זה "האם יש תמיכה מהיצרן שרתים"? והתשובה בדרך כלל היא "כן", כלומר אם תבקשו מ-HP או DELL או LENOVO פתרון תוכנה של סטורג', הם ישמחו למכור לכם את התוכנה, עם או בלי שרת שלהם. היתרון הגדול בשיטה זו הוא שאם ציוד כלשהו בשרת נדפק, אתה נמצא תחת אחריות מלאה וטכנאי יגיע אליך תוך 4 שעות או ביום העסקים הבא (בהתאם לחוזה שרות שחתמת), ואם יש לך שאלות או תקלות עם תוכנת הסטורג', תוכל לקבל תמיכה מהיצרן שרתים או מיצרן התוכנה, כך שאתה מכוסה מכל צד. אפשר להשוות זאת לרכישת ברזלים + רשיונות של vSphere – אני לא מכיר מקרים שלקוח נשאר ללא מענה לתקלות אם הוא תחת אחריות של יצרן השרת והתוכנה.

מבחינת ביצועים – אחת השאלות שאני תמיד מקבל מצד כל מיני חברות שמתעניינות בסטורג' זה משהו בסגנון "אני צריך פתרון סטורג' עם X טרהבייט ועם כמות Y של IOPS רציפים". עם SDS אין בכלל את העניין הזה. רוצה X טרהבייט? תכניס כך וכך דיסקים ואם נגמר המקום, חבר JBOD בחיבור SAS-HD2. רוצה IOPS? תגדיל כמות זכרון ותוודא שיש לך SSD מהירים כמו P4800X או 905P של אינטל או Z-SSD של סמסונג (זה במקרה הקיצוני שצריכים IOPS גבוה בכל מחיר) או כל SSD שהוא Mixed והוא נמכר לך ע"י יצרן השרתים שלך. סמסונג, אינטל, מיקרון, טושיבה – כולם מייצרים כאלו.

שרידות – אחת הבעיות הקשורות במחיר – היא שרידות High Availability בסטורג' קנייני, כלומר כשצריכים "2 ראשים" לקבל שרידות. המחיר של ראש שני – יקר מאוד! לעומת זאת, בסטורג' SDS, מדובר בעצם על עוד שרת, רכישת JBOD לדיסקים וחיבור ה-JBOD ל-2 השרתים והפעלת פונקציית HA בתוכנת הסטורג'.

מה עם ביצועי רשת ב-SDS? שרת חזק יחיד עם כרטיסי רשת במהירות גבוהה, יתן ביצועים גבוהים ומענה לחיבור כל התשתית שצריך. מנסיון אישי על שרתים שהקמתי, הגעתי ל-250 ג'יגהביט תוך חיבור 150 שרתים, חלקם ב-NFS, חלקם ב-iSCSI וחלקם ב-CIFS (הייתי יכול להגיע ליותר אם היתה לי מכונה יותר חזקה ויותר כרטיסי רשת), כך שפתרון SDS יכול לעמוד בעומסים בלי שום בעיה.

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

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

עוד על SDS כתבתי כאן וכאן.

אחסון נתונים – לאן אנחנו מתקדמים?

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

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

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

  • ניתן יהיה לרכוש SSD בגדלים של עד 32 טרהבייט (פר דיסק) – בהשוואה לעד 14 טרהבייט דיסק מכני.
  • מהירות הכתיבה תהיה יותר מהירה ממהירות הכתיבה לדיסק מכני, אם כי לא בהבדל כה משמעותי כמו SSD MLC – זה יהיה בסביבות ה-800-1000 מגהבייט לשניה. מהירות הקריאה לעומת זאת תהיה בערך כמו SSD MLC – בערך 2 ג'יגהבייט לשניה.
  • טיפול בשגיאות יהיה הרבה יותר חכם בהשוואה לדיסקים קשיחים מכניים – והטיפול יהיה פנימי (עם Garbage Collection ו-TRIM).
  • הקץ לחיבורי SATA ו-SAS2/SAS3 – כל החברות מעוניינות להעיף זאת (אוקיי, חוץ מטושיבה) לטובת NVME.

הדיסקים הללו יצאו במהלך השנה הקרובה. שימו לב: במקרים מסויימים, גם אם יש לכם תמיכת NVME בשרת, לא בטוח שדיסקים כאלו יהיה ניתן להכניס אותם הואיל והעובי שלהם הוא 15 מ"מ (בניגוד לרוב הדיסקים SSD שהם בין 5 ל-7 מ"מ).

רוב האנשים שאומר להם את המילים "SSD עם QLC Flash" לא ממש יבינו את ההבדלים בין SSD רגיל ל-SSD QLC ולכן אני מציע להציץ בלינק הבא. כפי שתוכלו להבין מקריאת המאמר שם – אלו דיסקים שלא מיועדים להירכש במקום דיסקים SSD שנמכרים כיום, אלא מיועדים להחליף את רכישת הדיסקים המכניים.

מ-QLC נעבור לטכנולוגיה שאינטל כה גאה בה – ה-3D Xpoint. טכנולוגיה זו, למי שאינו מכיר – היא טכנולוגיית אכסון על שבבים, אך לא מדובר ב-NAND Flash אלא על פתרון קנייני של אינטל ומיקרון. SSD בטכנולוגיות כאלו יחזיק הרבה יותר זמן, מהירות הכתיבה והקריאה שלו שווה פחות או יותר למתחרים, אולם הטכנולוגיה "עוקפת" את המתחרים בכל מה שקשור ל-Latency או בשימוש בחלק מה-SSD כ-SWAP והוא מאוד מתאים לדברים כמו SQL אם אנחנו מעוניינים להצמיד SSD כזה למכונת VM (או להריץ על "הברזל").

למרות שאינטל מהללת את הטכנולוגיה – ברוב המקרים אצל רוב החברות, לא יהיה לה ממש שימוש, הואיל ושימוש ב-SSD כזה על פתרון וירטואליזציה כמו vSphere לא יתן יתרון גדול על מתחרים אחרים כמו סמסונג, מיקרון ואחרים (ב-SSD ל-Enterprise). בנוסף, אינטל מייצרת אותם בגודל די קטן: 280, 375, ו-750 ג'יגהבייט (שוב, בגרסאות Enterprise) במחיר הרבה יותר גבוה מהמתחרים, כך שאם רוצים להשתמש ב-SSD כאלו – מומלץ לחשוב ולקחת יעוץ. מצד שני, אם אתם בונים פתרון NAS, דגם 905P לדוגמא יכול לתת פתרון Cache הרבה יותר טוב מאחרים (שימו לב, שבשביל להשתמש ב-SSD כזה, צריך מכונה די חדשה, מהשנתיים האחרונות).

טכנולוגיה נוספת שתעניין חברות שמשתמשות ב-SQL ושצריכים ביצועי Read רצחניים, היא טכנולוגיית ה-Z-SSD של סמסונג. ה-Z-SSD עוקף בביצועים את ה-3D Xpoint של אינטל, אבל הוא הרבה יותר איטי בכתיבה.

מכאן נעבור לפתרונות אחסון קנייניים. ברוב המקרים בקצה הנמוך עד בינוני (תקציב של 5-6 ספרות בדולרים) הטכנולוגיות הם פחות או יותר אותן טכנולוגיות, רק שכל חברה נותנת שמות אחרים (די מזכיר מה שקורה בתחום השרתים) ואחת השגיאות שרבים נופלים אליה – היא המושג "AFA" (או All Flash Array). אפשר להשוות את זה למושג שיגיע מאיש שיווק של רכבים – "מכונית מפוארת". זה שפתרון Storage הוא All Flash יכול להטעות, בגלל שכל SSD יש לו מגבלות – בכמות כתיבה רנדומלית או Sequencial, חלקם הוא Mixed Intense אבל ברוב המקרים בהצעה הראשונה שתקבל ה-SSD הוא Read Intense, מה שיאיט את הביצועים בצורה ניכרת בעבודות דיסק כבדות.

בשנה הקרובה יהיו יותר ויותר הצעות AFA שמבוססים על דיסקים SSD TLC (ולא MLC שהוא הרבה יותר מהיר. ה-TLC יושב "באמצע" בין ה-MLC ל-QLC) ושיהיו Read Intense. בהצעות היותר גבוהות, סביר להניח שנראה לקראת סוף שנה הבאה פתרונות Storage גדולים יותר מבוססי SSD QLC – כאשר חלק מה-SSD יהיו TLC כדי "להחביא" ביצועי כתיבה איטיים. אלו שרוצים להקים פתרונות VDI גדולים – פתרונות Storage כאלו יאיטו ביצועים במקרים מסויימים (במיוחד אם מרימים כל דסקטופ כ-VM ולא כ-Session RDP לדוגמא).

עוד תחום שיקבל תאוצה בשנה הקרובה הוא ה-NVMEoF שעליו כתבתי בעבר. הפתרונות הללו יקרים (7 ספרות בדולרים) והם הרבה יותר מורכבים מפתרונות Storage קודמים. תחום נוסף שיקבל דחיפה ויכול לעניין את אלו שמחפשים פתרון Storage עם Scale Out – הם פתרונות קנייניים של Scale Out מ-EMC, NetApp, ואחרים אך לעניות דעתי אין להם הצדקת רכישה – יש מספר פתרונות Scale Out Storage שיכולים לרוץ על ה-Nodes עצמם מבלי לרכוש עוד Storage.

עוד פתרונות מעניינים שיגיעו לשוק (אבל אני מאמין שלא יכנסו לשוק הישראלי האולטרא-שמרן) הם פתרונות JBOF – מכונות שמזכירות JBOD אך עם SSD במקום דיסקים מכניים, שמחברים כל מכונה למספר שרתים עם כרטיס HBA וב-JBOF מגדירים כמות דיסקים שיוקצו פר שרת. יש גם פתרונות של מכונות שיכולות לקבל 45-60 דיסקים מכניים בגודל 3.5 אינטש וכוללות מעבד, זכרון וכו' ויכולות לשמש כפתרון Storage (אולם יש צורך בשדרוג תשתית הרשת ל-40-50 ג'יגהביט).

מצד הדיסקים המכניים אנחנו נראה בשנה הבאה דיסקים שעובדים עם מנועים כפולים (ומהירות גישה כפולה – בסביבות ה-450 מגהבייט לשניה) בחיבורי NVME והיצרניות כבר יציעו דיסקים שמגיעים לגדלים של עד 20 טרהבייט. יהיה מעניין לראות את התחרות מבחינת מחירים – בהשוואה ל-SSD QLC.

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

Exit mobile version