וירטואליזציה כקוד פתוח – כפתרון טוב

לפני כשבועיים פרסמתי את הפוסט הזה שמדבר על פתרונות אלטרנטיביים ל-vSphere של VMWare. הפעם אני רוצה לדבר על פתרונות קוד פתוח כפתרונות טובים לוירטואליזציה ומדוע RHV/oVirt הוא פתרון שעולה על רוב פתרונות הקוד הפתוח.

פתרונות וירטואליזציה בקוד פתוח מתחלקים בעצם ל-2: אלו שמעוניינים לנהל מספר קטן של שרתים פיזיים וצרכי הוירטואליזציה שלהם בסיסיים, ואלו שמעוניינים בפתרון וירטואליזציה מלא כולל הדברים המתקדמים, משהו כתחליף ל-Hyper-V (עם הניהול המרכזי) או תחליף ל-ESXI+vCenter.

כשמדובר בצרכים בסיסיים לוירטואליזציה ומדובר בכמות קטנה של שרתים (נניח 2-5), ומדובר, לשם השוואה, בדברים ש-ESXi עצמאי (ללא vCenter) יכול לתת – אז הפתרונות שהצעתי בפוסט הקודם יכולים לתת זאת ללא בעיה. יותר מכך, כל הפתרונות (למעט שימוש ב-KVM וב-libvirt עם סקריפטים) שהצעתי גם יכולים לתת לכם ניהול מרוכז של השרתים שלכם בממשק Web.

לעומת זאת, כשאנחנו מעוניינים בדברים יותר מתקדמים כמו:

  • שימוש ב-vSwitch (בגירסת הקוד הפתוח – Open vSwitch) כ-SDN
  • הקמה אוטומטית של מכונות VM
  • שימוש ב-Grafana לתצוגת מצבי מכונות, דיסקים, מעבדים וכו'
  • High Availability מלא
  • אופטימיזציה לשימוש ב-NVME SSD תוך הגדלת I/O Threads
  • תמיכה מובנית ב-DR
  • יצוא/יבוא OVA/OVF
  • תמיכה במעבדי Power של IBM
  • תמיכה בכל פרוטוקולי הסטורג' (NFS, iSCSI, Fiber) + דיסקים מקומיים ו-GlusterFS
  • תמיכה במעבדים חדשים (EPYC, Xeon SP – ברוב הפתרונות המוצעים זה לא יעבוד טוב, במיוחד כשמדובר ב-HA).
  • ניהול מרוכז של כמות שרתים גדולה (עד 400 מכונות פיזיות)
  • פרופילים (סוגי מכונות, גדלים ועוד) כולל High Performance VMs.
  • תמיכה מורחבת ל-Over Commit
  • יבוא/יצוא של Images מ-OpenStack Glance (לא חייבים OpenStack מותקן בחברה).
  • פורטל למשתמשים (לאלו שצריכים לגשת למספר מכונות VM, ולנהל את אותן מכונות VM)
  • תמיכה במספר סוגי LDAP (כולל AD)
  • התממשקות ל-vCenter ויבוא מכונות VM
  • אפשרות לעבוד במצב הרגיל או במצב HCI.
  • תמיכה מלאה ב-GPU וב-VDI.
  • ועוד הרבה פונקציות אחרות.

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

האם פתרון כמו RHV/oVirt יכול להיות תחליף מלא ל-vSphere? התשובה היא: עדיין לא. העניין קשור יותר ל-Kernel ולדברים מתקדמים אחרים שלא קיימים ב-RHEL-7/CentOS-7 (שעליהם oVirt/RHV רץ):

  • Fault Tolerance עדיין לא זמין בגירסה הנוכחית (4.2)
  • VAAI/VVol – יש תמיכה ב-Kernel 4.X כך שנצטרך להמתין ל-RHEL-8/CentOS-8.
  • תוספים כמו vRealize ואחרים (שהם בתשלום) – יש להם חלופות. חלקם בחינם, חלקם בתשלום.

בכל הקשור לפתרונות וירטואליזציה, הגענו לזמנים טובים, למען האמת. רק לפני 3 שנים אם חברה גדולה היתה שואלת אותי לגבי פתרונות אחרים ל-VMWare או Hyper-V, הייתי ממליץ להם לנהל מו"מ בינם לבין מיקרוסופט ו-VMWare כי הפתרונות לא היו מספיק לדעתי טובים לשום Enterprise. פתרונות כמו Proxmox או פתרונות מבוססי Xen היו קיימים, אך לדעתי הם אינם נותנים מענה מספק ל-Enterprise (אם כי הם היו בהחלט יכולים לתת מענה לעסקים קטנים). בשנים האחרונות, החברה שהשקיעה הכי הרבה בפיתוח פתרון וירטואליזציה טוב היתה דווקא רד-האט. המצב בשוק פשוט התהפך: מיקרוסופט ו-VMWare היו עסוקים בפתרונות וירטואליזציה ואילו רד-האט היו עסוקים בפיתוח פתרונות מבוססי קונטיינרים (OpenShift) וב-3 השנים האחרונות רד-האט משקיעה הרבה יותר בפיתוח פתרון וירטואליזציה וגם בשיפור OpenShift, בשעה שמיקרוסופט ו-VMWare בשנתיים האחרונות יותר מתעסקים בפתרונות קונטיינרים.

לסיכום: שום פתרון (פתוח או סגור) אינו Drop In Replacement. לכל פתרון יש יתרונות וחסרונות וכדאי לשקול את הדברים. בכל מקרה תהיה תקופת מעבר ויהיה צורך לפתור לא מעט בעיות. פתרונות בקוד פתוח לא מחייבים תשלום Up front (למעט במוצר מסחרי כמו RHV, אם כי יש Trial חינמי), אבל כן מחייבים יעוץ, אינטגרציה והדרכה – שזה כן עולה כסף.

תובנות על OpenShift בחברות גדולות

יוצא לי בלא מעט מקרים לתת יעוץ לחברות גדולות לגבי עניין המעבר ל-Devops, שימוש בקונטיינרים, Docker, שימוש ב-Jenkins ושאר כלים. כמובן, כמו תמיד, בחברות גדולות, אף אחד אינו רץ להטמיע טכנולוגיה זו או אחרת רק בגלל שחץ בן חמו (או נציגי Presale של רד-האט, אין לי קשר אליהם) המליץ עליה. יחד עם זאת, בדרך כלל ההמלצה שלי לפני שמרימים אפילו PoC של OpenShift – אני מבקש מהחברה שתתן לי להיות "הטיפש" – להיות עם צוות שינסה את הדברים החדשים ובעצם ללמוד את התהליכים שהצוות משתמש בהם – החל מכתיבת קוד, שימוש ב-SCM, קומפילציה, טסטים, תהליכים נוספים עד לתוצר הסופי (קבצים בינאריים, Artifacts וכו').

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

  1. ניהול קוד (Source Code Management – SCM)
    ברוב המקרים שישבתי לפגישת היכרות ושיחה על המערכות הקיימות, בד"כ מערכת ניהול הקוד היתה TFS של מיקרוסופט או בחלק מהמקרים SVN. מקומות בודדים הכניסו איזו "תת מערכת" של GIT (בשימוש של Gitlab או BitBucket).
    הבעיה: שום מערכת קונטיינרים המבוססת על Kubernetes לא תומכת באופן רשמי לא ב-TFS ולא ב-SVN. כולן תומכות באופן טבעי ב-GIT.
    הפתרונות שיש הם מאוד עקיפים:
    עם TFS יש פתרון די עקיף לבעיה כפי שמוסבר כאן.
    עם SVN הפתרון הוא למשוך את הקוד למכונה מקומית שמחוברת לשרת GIT, ולאחר מכן לבצע Commit, Push לשרת ה-GIT המקומי. זה פתרון די "מכוער" ובעייתי מכיוון שאם מישהו שכח להוריד ולהעלות קוד ל-GIT, ה-Build יהיה בעייתי. אגב, שרת SVN הוא יחסית קל מאוד להמרה ל-GIT, במידה והחברה מעוניינת לעבור ל-GIT.
  2. מכונות Windows ולינוקס ביחד.

    לא מעט חברות גדולות כותבות קוד ל-Windows וסקריפטים ל-Windows (ראיתי גם מקרים של Build ל-JAR/WAR שכתובים ב-Batch file), וכאן ישנה בעיה מהותית – Kuberenetes בעצמו לא רץ בצורה טובה על Windows והפתרון שיגיע בשנה הבאה יאפשר גם ל-Kubernetes וגם ל-OpenShift להשתמש ב-Nodes שהם גם Windows וגם לינוקס (אם כי שרתי ה-Master וה-Infra יצטרכו להיות מבוססי לינוקס).
    עד אז תהיה בעיה לקמפל קוד בצורה יציבה של דברים כמו DOT Net (כדאי לעבור ל-Dot Net Core שנתמך ורץ על לינוקס), ויהיה צורך להמיר קבצי batch ל-shell כדי לקמפל את הדברים על Windows.

  3. בחירת אסטרטגיה ב-OpenShift
    באופן עקרוני, שימוש ב-OpenShift מחייב בחירת אסטרטגיה, ו-OpenShift תומך ב-4 אסטרטגיות פופולריות: Docker, Source to image (S2I), Jenkins Pipeline ו-Custom (שהוא מאוד מתקדם וברוב המקרים לא יהיה בו שימוש אלא במקרים מיוחדים ששאר האסטרטגיות אינן עונות על כך)

    1. אסטרטגיית Docker מאפשרת שימוש ב-Images קיימים מבחוץ (ממקומות כמו Docker Hub לדוגמא) ושניבנו פנימית כחלק מהרמת אפליקציות. יש עם האסטרטגיה הזו 3 בעיות:
      1. רוב ה-Images שתמצאו בחוץ לא יפעלו עם OpenShift כי הם רצים כ-root ו-OpenShift בנוי בראש ובראשונה לאבטחה הדוקה ולכן הוא חוסם מיידית הרצה של Images כאלו (אפשר לבטל זאת אבל אז מישהו יחטוף על כך ממחלקת אבטחת מידע)
      2. בלא מעט מקרים שוחררו Images שמריצים מספר אפליקציות במקביל בתוך אותו Image וזה הורס כל דבר שקשור לגדילה רוחבית (Scaling) ולכן לא מומלץ להשתמש ב-Image כזה.
      3. טכנית, מבחינת אבטחה בקונטיינרים, דברים צריכים לרוץ רק ב-Foreground ולא ב-background ולכן קונטיינרים שיריצו דברים ב-background (שרותים כמו nginx, apache, postfix ועוד ועוד) – הקונטיינר "ימות" לאחר זמן קצר והמערכת תנסה להקים אותו שוב ושוב, מה שיצור loop (במיוחד אם מופעל Replication Controller – RC).
    2. אסטרטגיית Source to image (כלומר S2I): עם אסטרטגיה זו מערכת OpenShift מושכת ImageStream (כלומר Image "שלד"), יוצרת Image חדש שאליו היא "שופכת" את הקוד מ-GIT, מבצעת שינויים שצריך (הרשאות, התקנת קבצים נוספים כמו דרך PHAR ב-PHP או NPM עבור Javascript ועוד ועוד), ולבסוף בונה Image סופי שאותו המערכת מריצה ומקימה POD עם קונטיינר המכיל את ה-Image. באסטרטגיה זו ניתן "לקשור" (דרך Webhook) בין REPO של GIT לבין אפליקצייה ב-OpenShift וברגע שיש שינוי ב-GIT, המערכת תבנה אוטומטית Image חדש וכשתסיים היא תוריד את ה-POD הקיים ותפעיל מיידית את ה-POD עם הקונטיינר החדש (ניתן כמובן לבצע Blue/Green Deployment – פרטים כאן וזה קיים לא רק ברמת אפליקציות אלא גם ברמת מכונות)
    3. אסטרטגיית Jenkins: עם אסטרטגיה זו אנחנו מגדירים הכל מראש: מאיפה הקוד ימשך, מה ה-pipelines וכו' וכו' ו-OpenShift יקים בכל פעם קונטיינר Jenkins, יקמפל, יריץ את ה-pipelines, יפזר מה שצריך לפזר, יבנה Image חדש ויריץ POD עם קונטיינר המבוסס על ה-Image החדש. הדרך הזו יכולה להתאים לאלו שכבר משתמשים ב-Jenkins על לינוקס.

ישנם עוד חלקים הקשורים להקמת מערכת שיש צורך לערב הן את מחלקת אבטחת מידע והן את צוות ה-Storage. בגופים פיננסיים ובטחוניים יהיה צורך לשים דגש על שרתי Registry מקומיים (לחשיפה מופחתת לאינטרנט, אבל עדיין יש צורך לשאוב קבצי Image, בלי זה אי אפשר להקים שום דבר, ואין זה משנה אם מדובר ב-OpenShift או בכל מערכת אחרת מבוססת Kubernetes), שילוב עם Active Directory, הרשאות וכו' (מובנה ב-OpenShift, לא קיים ב-Kubernetes) ועוד דברים רבים.

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

חושבים לעבור לפתרון וירטואליזציה אחר?

עדכון על Hyper-V מופיע לקראת סוף המאמר.

אנחנו נמצאים ב-2018 וחברות רבות עוברות לענן ומתחילות לקצץ בתקציב רשיונות הוירטואליזציה שלהן, מנויי תמיכה וכו'.

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

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

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

  • לקוח רוצה להריץ מס' חד ספרתי של מכונות וירטואליות, אבל מצד שני הוא רוצה HA (כלומר High Availability) כך שאם נפל שרת אחד – השרת השני עושה pick up והמכונות ממשיכות לעבוד
  • לקוח אחר רוצה לתת שרותי Hosting ללקוחות שלו, יש לו אלפי מכונות וירטואליות אבל אין לו תקציב לרכוש מ-VMWare (אגב, רק לידיעה: VMWare דורשת 50$ פר מכונה וירטואלית מחברות Hosting, גם אם מריצים רק את ESXi החופשי).
  • לקוח אחר מעוניין בפתרון קוד פתוח ולא משהו קנייני להריץ כמה עשרות מכונות וירטואליות עבור העסק שלו.
  • לקוח אחר רוצה את הכל: תתחיל ב-FT, תכלול DR, תכלול HA, סוויצ'ים וירטואליים מורכבים, תמיכה ב-RDMA, NFS, iSCSI, templates ועוד ערימת דברים – אבל לא מוכן לשלם את המחיר ש-VMWare רוצים פר שרת פיזי.
  • לקוח אחר "להוט" מאוד על HCI – הוא רוצה המלצה אם ללכת על vSAN, Nutanix, Simplivity (אחד מהם).
  • ולקוח אחר מעוניין פה ועכשיו בהצעה על OpenStack כפתרון וירטואליזציה חלופי/משלים למה שיש לו כיום.

הבה נכיר את הפתרונות:

VMware
ה"מלכה" הבלתי מעורערת לפתרונות וירטואליזציה. בין אם יש לך בתשתית שרת אחד או 5000 שרתים פיזיים –  המערכת תומכת בצורה מעולה. יש אלפי פונקציות ואפשרויות להתרחב לכל דבר הקשור לוירטואליזציה.
הבעיה העיקרית: המחיר. גירסת ה-ESXi שמותקנת על השרת קיימת כגירסה חינמית, אך כמות הפונקציונאליות מוגבלת ולשם ההרחבה יש לרכוש את vCenter שקיימת במספר גרסאות, ואם יש לך עד 3 שרתים – תוכל לרכוש את רשיון ה-Essentials של vCenter ולנהל במרוכז את השרתים במחיר של 500$, אבל גם אז הפונקציונאליות די מוגבלת. רוצה יותר? תתחיל לשלם פר מעבד אלפי דולרים וגם לרשיון היותר מתקדם של vCenter תצטרך לשלשל עוד כמה אלפי דולרים, ועוד לא דיברנו על תמיכה שנתית – שגם היא עולה כמה אלפי דולרים. בקיצור – הסיבה שרבים מחפשים אלטרנטיבות היא לאו דווקא בגלל מגבלות טכניות, אלא בגלל מגבלות תקציביות.

OpenStack
דמיינו לכם את הדבר הבא: אתם נכנסים לסופרמרקט הקרוב ורוכשים לכם 3-4 קרטונים של חלב, אתם משלמים ויוצאים. מה יש לכם בשקית? 3-4 קרטונים של חלב וזהו. עם OpenStack, אתם מקבלים לא רק את הקרטונים של החלב, אלא גם את המחלבה, הרפת והפרות!

טכנית, OpenStack עושה המון דברים (תסתכלו כאן כדי לראות כמה פרויקטים יש בתוך OpenStack), וירטואליזציה זה רק אחד מהדברים, ואם אתה רוצה אחסון – אז יש לך 3 חלקים (Object, File, Block כל אחד מהם שונה). נכון, אפשר להתקין רק חלקים מסויימים (או להתקין הכל ולהשאיר לכל מה שצריכים ברירות מחדל), אך עקומת הלימוד בהשוואה לשימוש ב-Hyper-V או VMWare – מאוד גבוהה. יהיו כמובן חברות שיש להם את הצוותים שיכולים להתעסק בכך (ויש במה להתעסק, כיום OpenStack מורכב מיותר מ-1800 חבילות!), אבל אז מגיעות 2 נקודות שכדאי לתת עליהן את הדעת:

  1. גירסת OpenStack משתחררת כל חצי שנה עד שנה בערך. מכיוון שבחברות נהוג לעדכן כל 3 שנים, השדרוג לגירסה האחרונה יהיה קשה עד בלתי אפשרי כי בדרך כבר עברו כמה גרסאות (ואף אחד לא מבטיח תאימות).
  2. חברות מסחריות ירצו את ה-OpenStack המסחרי שהגירסה שמשוחררת ונתמכת ל-5 שנים, יצטרכו להתכונן למחיר ממש לא זול. גירסת רד-האט לדוגמא עולה כ-10,000$ לשרת עם 2 מעבדים (הממ, פתאום המחיר של VMWare לא נראה כזה יקר). חברות כמו SuSE וקנוניקל מוכרות במחירים יותר זולים, ואכן – אם חברה מחליטה ללכת לרכוש OpenStack אני ממליץ לה לרכוש זאת מ-SuSE (התמיכה של קנוניקל לא משהו, בלשון המעטה). במילים אחרות – אם אתה מחפש OpenStack שיחזיק כמה שנים טובות ובחינם – לא ממש תמצא זאת. זה לא CentOS.

Xen
טכנית, Xen הוא פתרון וירטואליזציה טוב כשמדובר על כמות שרתים פיזית קטנה. הוא נותן ביצועים טובים, יש ממשק Windows (למעוניינים, אפשר לעשות כמובן הכל בלינוקס ישירות). הבעיה המרכזית עם Xen הוא שהפרויקט עצמו בקושי "חי". Xen יוצא בגרסאות יותר חדשות (4.10.1 זו הגירסה האחרונה), אבל כשזה מגיע לחברות, הן רוצות תמיכה. Citrix מוכרת את Xen ונותנת שרות, אבל זול – הוא לא (3,000 דולר פר מכונה עם 2 מעבדים). הסיבה שאני לא ממליץ על Xen של Citrix היא שהחברה פיטרה מחצית מהעובדים שעבדו על Xen ונתנו לו שרות ולא נראה ש-Citrix תמשיך לקדם ולפתח את מוצר ה-Xen שלה. חברה אחרת שמוכרת את Xen תחת שם אחר היא חברת Oracle (היא לא מזכירה את השם "Xen" בשום מקום בתיעוד השיווקי) והמוצר נקרא Oracle VM Server.

Proxmox
תוכנת Proxmox היא אחת מהוותיקות בשוק שהלכה וגדלה עם השנים, הוסיפה תמיכה למכונות וירטואליות (מבוססות KVM, כמו רוב הפתרונות מבוססי קוד פתוח שמוזכרים כאן), תמיכה לקונטיינרים (לא Docker אלא LXC), תמיכה ל-ZFS, NFS, iSCSI, GlusterFS ועוד. זו תוכנה שמומלצת לאלו שרוצים לנטוש את Xen, לעסקים קטנים שיש להם שרות מאינטגרטור בארץ (השרות המקורי ניתן רק ב-tickets ואין אפשרות SLA, רק NBD מיצרנית התוכנה עצמה). התוכנה גם יכולה להתאים לעסקים קטנים והקהל שהכי "אוהב" את התוכנה אלו חברות ה-Hosting ששם דברים כמו Live Migration, HA וכו' אינם כה חשובים.

KVM/Libvirt/אוטומציה
פתרון שיכול להתאים לחברות שיש בהם מפתחי לינוקס (והמון זמן פנוי) הוא שימוש ב-KVM שמגיע עם כל הפצת לינוקס ושימוש בספריית Libvirt לבנות מערכת וירטואליזציה. הספריה מאפשרת את כל הדברים הבסיסיים ואת כל השאר ניתן לבצע עם אוטומציה בכלים כמו Ansible/Puppet/Chef וכו'. היתרון הגדול בשיטה זו הוא שהכל נמצא בתוך החברה ואם יש תקלה, היא מטופלת פנימית.

oVirt
תוכנת oVirt שנכתבת ע"י רד-האט היא אחת התוכנות שמכוונת ישירות להתחרות ב-vSphere. (שימו לב: גירסת הקוד החופשי נקראת oVirt, הגירסה המסחרית [שמבוססת על אותו קוד] נקראת RHV). ב-oVirt יש בעצם כמעט את כל מה שאתם מקבלים ב-ESXi עם vCenter, היא יכולה לעבוד גם בתצורות של מאות ואלפי שרתים פיזיים מצד אחד, אבל היא גם יודעת להתרחב לאזורים "קרובים" לוירטואליזציה (כמו הרצת Images מ-OpenStack ובגירסה הקרובה כנראה תהיה גם תמיכה לקונטיינרים). היא יודעת להתממשק לפרטוקולי הסטורג' הידועים (NFS, iSCSI וגם GlusterFS ו-Ceph [דרך Cinder]) וגם להתחבר ישירות אל שרתי ה-ESXi או אל ה-vCenter שלכם כדי להמיר מכונות ל-oVirt/RHV. בנוסף, oVirt/RHV היא התוכנה היחידה מתוכנות הקוד הפתוח שיכולה לעבוד גם במצב קלאסי (התקנה של התוכנה במכונה אחת, בשאר מתקינים גירסת Node) או במצב Hyper Converge. בנוסף, זו התוכנה היחידה שיש לה גם Client לאנדרואיד כדי לבדוק מה קורה ולטפל בתקלה מרחוק ללא צורך במחשב.

לחברות המעוניינות ב-RHV (כלומר בגירסה המסחרית), המחיר די זול (יחסית): 1000$ לשנה למכונה עם 2 מעבדים ותמיכה בשעות העסקים או 1500$ לתמיכה של רד-האט 24/7.

פתרונות HCI
מוצרים כמו Nutanix/Simplivity/VSAN/RHV מציעים בעצם שרתים עצמאיים שלא זקוקים ל-Storage חיצוני והם נותנים הכל בפתרון אחד. אלו יכולים להיות פתרונות מעולים, אולם חשוב לזכור שבמרבית המקרים תצטרכו להחליף שרתים (אם יש לכם שרתים ישנים) ובמקרה של vSAN אם תרצו תוצאות ממש גבוהות, תצטרכו דיסקים SSD NVME מסוג Mixed Intense (מה שאומר שתצטרכו לרכוש Backplane נוסף לשרת ל-4 כוננים, שרתים נמכרו בשנים האחרונות ללא Backplane ל-NVME וזה "אקסטרה") כחלק מכל קבוצת דיסקים. בפתרון של VMWare ניתן לעבוד "גם וגם" כך ששרתים ישנים שעובדים מול סטורג' יוכלו להמשיך לעבוד כרגיל. החסרון העיקרי של VMware vSAN הוא המחיר: תוספת של 5000$ פר שרת עם 2 מעבדים – וזה לפני המחיר של הציודים ובנוסף למחירי הרשיון האחרים ש-VMWare מבקשת.

פתרונות ל-VDI
גם מיקרוסופט, גם VMWare, גם Citrix וגם חברות אחרות מציעות פתרון VDI. את הפתרונות הללו אני מגדיר כלא יותר מ"בסדר". אלו פתרונות טובים לעובדי משרד, שמריצים דפדפן, אופיס, ואולי עוד כמה אפליקציות משרדיות, אבל כשזה מגיע לוידאו ותלת מימד – הפתרונות האלו כיום אינם משהו לרוץ לספר לחבר'ה. הסיבה לכך שמי שקובע את הדברים הם יצרניות ה-GPU והפתרונות שהם מציעים מתאימים לדברים שתיארתי לעיל ותו לא. מי שלדוגמא ישתמש ב-RemoteFX יגלה שמבחינת תמיכת OpenGL התמיכה היא חלקית ועל עריכת וידאו או דברים כאלו כבדים – תשכחו מזה. לאמזון יש פתרון שהוא יותר מתקדם ממה שהחברות שציינתי נותנות אבל גם הפתרון שלהם הוא לא בדיוק העלית שבעלית.

מבחינת קוד פתוח, ישנם כמה פרויקטים שמפותחים (והם ישולבו בעתיד במוצרים כמו ProxMox, oVirt ואולי Xen). אחד מהם לדוגמא הוא פרויקט VirGL שמרנדר על GPU בשרת ומעביר דרך הרשת את הפלט למסך. כרגע הוא תומך רק בלינוקס אולם מישהו אחר כרגע עובד על תמיכת Windows. עוד פרויקט (דווקא מחברת אינטל) הוא פרויקט GVT שמשתמש ב-GPU של המכונה כדי לרנדר עבור מכונות וירטואליות. בפרויקט עדיין חסר פלט רינדור לתצוגה רחוקה אבל אני מאמין שאינטל שומרת את החלק הזה ל-GPU שהם עובדים עליו כרגע.

מה עם Hyper-V?
מבחינה טכנית, Hyper-V נותן פתרון טוב לוירטואליזציה ששווה פחות או יותר לפתרון של VMWare (יש פונקציות שיש בפתרון אחד שאין בשני וההיפך). גם מיקרוסופט מציעה גירסה "חינמית" שמגיעה עם גירסת Windows Server (כ-Role) והפתרון הזה יכול להתאים למי שרוצה פונקציות ניהול (די מוגבלות) פר שרת, כך שכל שרת מנוהל בנפרד. ברגע שרוצים לנהל את הכל בצורה מסודרת, יש צורך ב-System Center ויש גם תשלום עבור Operating System Environment (או OSE) ורשיון ה-Windows Server צריך להיות רשיון Data Center. בגירסת Windows Server 2016 מיקרוסופט די החמירה את דרישות הרשיון ואם במקרה של VMWare למערכת לא ממש משנה כמה ליבות יש לך במעבד, במיקרוסופט רוצים תשלום פר ליבה ולא פר מעבד. חברת TAG Provision כתבה פוסט המשווה את המחירים בין המתחרים העיקריים וניתן לראות כל הנתונים כאן וכפי שניתן לראות, עם המחירים הללו, אין שום סיבה לעבור ל-Hyper-V, אלא אם מחפשים את הפתרון המינימלי ה"חינמי" ללא ניהול מרוכז. בנוסף, אם אתה מחפש פתרון HCI, ה-Hyper-V אינו מתאים לכך.

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

כשצריכים סטורג' סופר מהיר (חלק שני)

בפוסט הקודם הסברתי מעט מהו סטורג' סופר מהיר. למעוניינים בגירסה המקוצרת: סטורג' כזה עובד כ-NVMEoF (כלומר NVME over Fiber אם כי הוא כמובן יכול לעבוד גם על Ethernet בלי שום בעיה, אבל תצטרכו תקשורת במהירות של 40/50/100 ג'יגה – תלוי בכמויות שרתים, חיבוריות וכו') והוא בעצם נותן לנו ביצועים של דיסקים SSD NVME מקומיים עם Latency מאוד נמוך (בסביבות ה-20 מיקרו-שניות). מערכי AFA רגילים יכולים תיאורתית לתת NVMEoF אך ה-Latency יהיה בערך פי 10-20 יותר גבוה. בדרך כלל, רוב החברות שרוצות לרכוש AFA לא ממש יצטרכו NVMEoF למעט אותן חברות שמחפשות את ביצועי הדיסקים הכי גבוהים שניתן לקבל, חברות כמו High Frequency Trading, Fast Analysis, מערכי VDI ענקיים (מעל 5000 עם ביצועים מאוד גבוהים), AI/ML כשהביצועים המבוקשים חייבים לכלול Latency סופר נמוך כדי להתמודד עם כמות עצומה של DATA ל-Training, מערכות BIG DATA ענקיות, וכמובן – אלו שרוצים את ה-Top שב-Top (לא תמיד בגלל סיבות טכניות.. יש לא מעט חברות שרכשו פתרון שהוא פי 10 גדול מהצרכים שלהם מהסיבה הפשוטה … שיש תקציב).

על מנת לקבל את אותם ביצועים סופר מהירים, ברוב המקרים ישתמשו ב-XPoint של אינטל או Z-NAND של סמסונג. במקרים אחרים (כמו עם מערכות של E8) יהיה NAND אך ישולב בו Cache אימתני ועוד כמה דברים על מנת לתת את אותו Latency.

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

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

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

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

לכן, כדי לקבל את המספרים הטובים, אנחנו צריכים גוף שהוא מוכר עולמית, יש לו גישה לכל הציודים והוא עורך בדיקות עם הציודים ומפרסם מספרים ללא כל מיני "טובות" והשפעות. יש גוף כזה שנקרא STAC Research שחברים בו יותר מ-300 חברות והוא מפרסם Benchmarks על ציודים שונים בכל התחומים ומי שאינו מכיר את הגוף, מוזמן לקרוא את המאמר הזה באתר The Register. כך לדוגמא נראה גרף טיפוסי בדו"ח:

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

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

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

לסיכום: עם כניסת ה-NVMEoF לשוק ועם חדירת הנושא לתודעה של מנמר"ים/CTO, יהיו המון הצעות בשוק. חלקן הצעות שפשוט לא שוות (הייתי מציין שם של מערכת מסויימת אבל אני מעדיף שלא. בואו נאמר שדיסקים SSD ב-1000 שקל נתנו ביצועים יותר טובים…). בפרויקט כזה כדאי לקחת את הזמן ולא לסמוך על מילה של מאן דהוא שהמערכת "מצויינת" אלא לבדוק דרך גורמים בלתי תלויים ולא להאמין כל כך לחומרי השיווק (תסתכלו בכוכביות ובטקסט הקטן למטה). חשוב להוסיף את כל מחיר שדרוג התשתית והעברת התכנים וחשוב גם לקחת בחשבון לוח זמנים ריאלי כדי להטמיע את המערכת.

רכישת/מכירת שרתים יד שניה, פוסט המשך

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

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

מס' אנשים תלו (ותולים) תקוות שחברות אחרות ירכשו את השרתים שלהם, אך האמת הדי פשוטה היא שרוב החברות בארץ פשוט לא רוכשות שרתים יד שניה (למעט כמובן חברות סוחרים כמו All Trade ואחרים) מהסיבה הפשוטה: חידוש אחריות ל-3 שנים הכוללת הגעת טכנאי בזמן SLA  של 4 שעות – יהיה יקר בהרבה ממחיר רכישת השרת. כך לדוגמא, אם רכשתם שרת יד שניה ב-1500 שקל, עלות השרות שציינתי לעיל תעלה בסביבות 6000-10000 שקל, בשעה שרכישת שרת חדש עם הוספה של תמיכת SLA ל-4 שעות תעלה הרבה פחות בהשוואה לרכישת השרות לשרת יד שניה, כך שכל חברה שאפילו תחשוב על רכישת יד שניה ותרצה SLA כזה, תרד מרכישת שרת יד שניה.

מה לגבי ציודים שבשרתים? אז כך:

  • מקלות זכרון בגודל 1,2,4 ג'יגהבייט – אין להם בד"כ דרישה בשוק, כך שמי שרוצה למכור זכרונות ECC יכול לנסות את מזלו אולי ב-eBay. הדרישה בשוק בד"כ היא למקלות זכרון בגודל 8 ג'יגה ומעלה עם תיוג PC3 10300 או PC3 12800. גם עם מקלות אלו אין הרבה "בשר" מבחינת כסף להרוויח הואיל ורוב המוכרים (שוב, למעט חברות שזה מה שהן מציעות) פשוט לא נותנים שום אחריות לזכרונות, ולכן לדוגמא מקלות זכרון של 8 ג'יגה שווים בערך 20-40 שקל פר חתיכה (בסביבות ה-50-60 לזכרון PC3 10300 בהנחה שמדובר ב-DDR3 ECC).
  • דיסקים קשיחים – לא מומלץ לשום חברה שמעוניינת למכור את הציוד, למכור או לתת את הדיסקים הקשיחים עקב עניינים של אבטחת מידע. השרת מבחינתכם "מת"? העבירו את הדיסקים לגריטה. דיסקים SSD – לא מומלץ לרכוש יד שניה מכיוון שכמות הכתיבה עליהם מוגבלת ודיסקים SSD יד שניה בד"כ אינם כוללים בקרים מורכבים כך שסביר להניח שה-SSD ימות עוד לפני שתימלא לו שנה לאחר רכישה מיד שניה.
  • מעבדים – מאוד תלוי בדגם השרת. שרתים כמו Gen9 של HP (או R730 של Dell או M5 של לנובו) יכולים לקבל מעבדי Xeon E5 v4 כשדרוג במקום E5 v3 (כל מה שצריך זה לשדרג BIOS לגירסה האחרונה לפני החלפת מעבדים), ולכן גם כאן, מי שרוצה לרכוש שרת יד שניה, עדיף שירכוש את המעבד הכי "נמוך" שאפשר וישדרג ברכישת מעבדים ב-eBay. למוכרים – זו עיסקת חבילה ובקטע הזה לא תקבלו הרבה גם על הדגמים עם הכי הרבה ליבות.

מה לגבי מחירים? הפופולריים ביותר אלו הם שרתי 1U ו-2U מה-5 שנים האחרונות (אלו שלפני כן נמכרים במחירים של 3 ספרות). כך לדוגמא שרת Gen8 של HP עם 192 ג'יגהבייט זכרון ועם מעבדים בעלי 8 או 10 ליבות נמכרים במחירים של 1000-1500 שקל (ה-1500 זה אם יש דיסקים חדשים). Gen7 של HP נמכרים בסביבות ה-600-900 שקל עם 208 ג'יגהבייט זכרון לדוגמא, כך שכמו שאתם רואים – הרבה כסף אי אפשר לעשות מזה.

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

סוויצ'ים, UPS – גם כאן, המחירים נעים סביב ה-3 ספרות. UPS לדוגמא לא שווה הרבה אחרי 6-9 שנים של שימוש מכיוון שיש צורך להחליף סוללות פנימיות (והן יקרות!). סוויצ'ים לעומת זאת, חברות רבות נפטרות מהמתגים במהירות 1 ג'יגהביט לטובת מתגים במהירות 10 ג'יגה ומטה, כך שגם כאן המוכר לא יעשה מזה הרבה כסף והרוכשים הפרטיים יכולים אולי למצוא הזדמנויות טובות לשדרג LAB או להוסיף מתג לדברים/פרוייקטים צדדיים.

אז מדוע חברות כמו All Trade מוכרת במחירים כאלו גבוהים שרתים יד שניה? הסיבה פשוטה: הם חייבים להחזיק מלאי והם מוכרים שרות, כך שאם לדוגמא הם רכשו מלאי של 10 שרתי Gen8, הם יוכלו למכור רק 5-7 כאלו כי הם חייבים להחזיק שרתים אחרים כמלאי להחלפה בעת תקלות חרום כחלק מהשרות שהם מוכרים.

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

החל ה"מרדף" אחר החלפת הדיסקים קשיחים שלכם

כמעט בכל חברה גדולה בארץ יש שרתים ואם נסתכל בשרתים – ברוב המקרים נמצא דיסקים קשיחים מכניים. הם לא מהירים כמו דיסקים SSD, אבל הם "סוסי עבודה" שעושים עבודה טובה. אני די בטוח שהיו למנמר"ים או אנשי IT הצעות להחליף את הדיסקים האלו ב-SSD ובוודאי בחלק מהמקרים הדיסקים המכניים הוחלפו ב-SSD, אבל בד"כ חברות לא ממהרות להחליף – בגלל המחיר. אחרי הכל, מחיר ממוצע של SSD ל-Enterprise עולה הרבה יותר מאשר דיסק מכני SAS או NL-SAS ל-Enterprise.

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

הם מיועדים להתחרות בדיסקים הקשיחים שיש לכם בשרתים.

הבה נודה על האמת: דיסקים מכניים בגודל 2.5" לא התקדמו כמעט בשנים האחרונות. ברוב המקרים הדיסק הכי גדול ל-2.5" ל-Enterprise הוא בגודל 2 טרהבייט (יש כמובן גם 5 טרהבייט אם כי הם אינם מיועדים ל-Enterprise ובכל מקרה לא בטוח הם יוכלו להיכנס לשרת שלכם אם השרת הוא של HP לדוגמא – המערכת פשוט תקפיץ הודעה שזה לא נתמך והיא לא תציג התראות מדיסק כזה). המהירות שלהם אינה גבוהה (בין 200-270 מגהבייט ב-Sequencial Read).

חברת Micron, בשיתוף פעולה עם אינטל, הציגו אתמול את ה-SSD מבוסס QLC הראשון שלהם. עדיין אין הרבה פרטים ציבוריים עליו ובאתר Toms Hardware כתבו כמה מילים לגביו.

טכנית, הדיסקים הללו, כפי שציינתי לעיל, מיועדים להיות "באמצע" – בין כוננים מכניים ל-SSD שכולם מכירים ל-Enterprise. הכתיבה שלו לא מהירה בהשוואה לשום SSD שקיים בשוק (כן, גם בהשוואה ל-SSD שעולה 1000 שקל בחנות מחשבים), אולם מהירות הקריאה שלו היא כמו מהירות קריאה של SSD ל-Enterprise, כלומר אתם תקבלו מהירות של 550 מגהבייט לשניה (שוב, ב-Sequencial Read, ב-Random התוצאה תהיה מעט שונה ואם משתמשים ב-Queue Depth התוצאות יהיו לא רעות .. הייתי מרחיב אבל יש אמברגו עד לסתיו הקרוב).

הגדלים של הדיסקים הללו יהיו שונים מגדלים של דיסקים מכניים. ה-5210 ION יהיה זמין בגדלים החל מ-2 טרהבייט ועד 8 טרהבייט (אני מעגל את המספרים), כך שתיאורתית דיסקים כאלו יכולים להחליף גם דיסקים מכניים בגודל 3.5" (ניתן לאכסן תיאורתית בשרת בגודל 1U עם 10 כניסות דיסקים – כמעט 80 טרהבייט של DATA).

והשאלה הכי חשובה לפני שחושבים לרכוש דבר כזה בעתיד: לאיזה עומסי עבודה זה מתאים? ובכן, התשובה היא במובהק לעבודות Read Intensive. זה לא מיועד לאכסן שרת SQL או נתונים של שרת SQL, זה לא מיועד לשמש כדיסקים לוקאליים עבור הרצת מכונות VM. זה מיועד יותר לאחסן תוכן סטטי, כך שאם אתם מריצים פורטל ארגוני גדול בחברה לדוגמא, דיסק כזה יכול לאחסן את התכנים עבור הפורטל (בנוסף לדיסק רגיל שיאחסן את השרת ה-Web ו/או ה-Application Server). חשוב לזכור: כמות הכתיבה/מחיקה על כל תא היא מוגבלת (בסביבות ה-1000 פעם, אבל בד"כ בקר ה-SSD עושה עבודה חכמה שלא תגיעו לזה)

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

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

כמה מילים על ZFS (לשנת 2018)

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

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

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

להלן צילום מסך מ-vSphere client בגירסה 5.5, כאשר מגדירים LUN חדש ובוחרים את ה-Block Size (לחצו להגדלה):

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

במקרה לעיל, לא חשוב איזה Storage יש לך, מהרגע שהגדרת iSCSI LUN בסטורג', לסטורג' אין מושג ירוק מה אתה הולך לעשות איתו. מבחינתו זה Block ולך תשבור את הראש מה לעשות ואיך להגדיר ואיך לעשות אופטימיזציה לו ב-Initiator שלך.

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

אבל מה קורה אם אנחנו רוצים לבנות פתרון סטורג' משלנו ואנחנו מעוניינים לעשות לו אופטימיזציה ולא להיות "שבויים" באיזה פתרון שלא מאפשר לנו להגדיר דברים לעומק? אם אנחנו בונים עם לינוקס מערכת כזו עם File System כמו XFS או EXT4, מאותו הרגע שחילקנו את הדיסק עם או בלי LVM, ואנחנו מפרמטים את כל מערך ה-RAID בזמן ההתקנה, אז כבר אי אפשר לשנות את גודל הבלוקים. ב-XFS לדוגמא, ברירת המחדל היא להגדיר בלוקים בגודל 4K כל בלוק, אבל אם אנחנו הולכים לאחסן רק קבצים שרובם בגודל מס' ג'יגהבייטים, אנחנו נפסיד מהירות.

לעומת זאת ב-ZFS, גם אחרי ששייכנו את כל הדיסקים ל-Pool מסויים, אנחנו תמיד יכולים להגדיר את גודל הבלוקים (ב-ZFS זה נקרא record size) גם אחרי יצירת ה-Pool ויצירת Dataset (חשוב כמובן לשים לב שאם יצרנו Dataset ואנחנו מגדירים לו record size חדש, רק הקבצים החדשים יקבלו את גודל ה-record size החדש, לא הקבצים הישנים) כפי שניתן לראות לדוגמא כאן. (אגב, זה דבר שמאוד עוזר עם MySQL לדוגמא, אתם מוזמנים להציץ כאן)

נקודה נוספת וחשובה היא כמובן הדיסקים. ישנם עדיין מקרים רבים שיש שרתים פיזיים שמריצים אפליקציות מסויימות על דיסקים מקומיים עם כרטיס RAID הכולל זכרון Cache וסוללה, אך עם הדיסקים החדשים שיש כיום שמחירם יורד כל הזמן, יהיו לא מעט חברות שישמחו לקנות דיסקים בגודל 6,8,10,12 או אפילו 14 טרה בייט ויחברו אותם לבקר ה-RAID וכך הם יקבלו כמות אחסון מכובדת, אך יש בעיה מרכזית אחת: כל דיסק מעל גודל 4 או 6 טרהבייט שנדפק ומוחלף, יאיט אוטומטית את הביצועים של כל מערך הדיסקים לזמן רב (זה יכול לקחת ימים או במקרים של דיסקים גדולים כמו 10,12,14 טרהבייט – אפילו שבועות!) מהסיבה הפשוטה שבקר דיסקים הוא דבר די טיפש, הוא יודע לקרוא בלוקים, אבל הוא לא יודע מה יש בבלוקים, כך שבקר ה-RAID מבצע rebuild, הוא יעתיק את כל הבלוקים, גם אם 60% מהדיסק הוא בכלל ריק! לעומת זאת ב-ZFS אם נדפק דיסק והחלפנו אותו, מערכת ה-ZFS תשחזר (מה שנקרא: resilver) רק את הקטעים שלא קיימים בדיסק החדש, כך שה-rebuild יהיה הרבה יותר קצר והמערכת תשוב לאיתנה במהירות הרבה יותר גבוהה מאשר בתהליך rebuild של כרטיס RAID.

חסרונות נוסף שקיימים ל-XFS ול-EXT4 הם לדוגמא:

  • אין בדיקת קבצים מתמשכת. ב-ZFS לכל קובץ יש checksum כך ש-ZFS יודע בדיוק אם מה שהוא קרא תקין או לא ואם לא הוא יטפל בבעיה אוטומטית בכך שהוא יעביר את הנתונים למקום אחר (בערך כמו שבקר SSD טוב עושה) ול-ZFS ישנו גם תהליך scrubbing שעובר אחת לכמה ימים על כל הקבצים בדיסקים לבדוק זאת ולטפל בתקלות באופן אוטומטי. ב-XFS וב-EXT4 יש לך Journal שיכול לעזור בקריסת המכונה, אך זהו פתרון שאינו מספק על מנת לשמור על הנתונים.
  • ב-EXT4 וב-XFS אין מנגנונים לניצול משאבי המכונה מבחינת זכרון. כן, ללינוקס יש שימוש מתוחכם בזכרון החופשי לשם Cache מסוגים שונים, אבל ב-ZFS יש את ARC שלוקח כברירת מחדל מחצית מהזכרון של המערכת להאצת ביצועי דיסק בכך שהוא משתמש באותו זכרון שהוא "גזר" בהתחלה, וכידוע – זכרון RAM הוא הדבר הכי מהיר שיש, יותר מכל SSD שקיים בשוק.
  • שימוש מושכל ב-SSD וב-NVME: עם מערכת כמו bcache או fastcache (לאלו שאוהבים לחיות על הקצה) יכול להיות פתרון די טוב על מנת להאיץ ביצועים של דיסקים מכניים, אך ב-ZFS יש לך 3 מנגנונים שמטפלים בכך:
    • מנגנון ה-ARC (שמשתמש כברירת במחצית הזכרון של המכונה לשם CACHE מהיר)
    • מנגנון ה-ZIL (להאצת ביצועים וטרנזאקציות של קבצים קטנים ורישומי הפניות להיכן קבצים נכתבים, אפשר לקרוא על כך כאן)
    • מנגנון ה-L2ARC – כאן בד"כ יהיה SSD מהיר ששומר עותקים של קבצים שניגשים אליהם בתכיפות גבוהה.
  • מערכת ZDB – לכל File system יש כלים משלו (tune2fs ל-EXT3/EXT4 לדוגמא או ערימת הכלים הזו ל-XFS), אבל ZDB לוקח את זה כמה צעדים קדימה – לבדיקה האם יש Cache אופטימלי, לבדיקה של ביצועים פר דיסק, בדיקות והגדרות ל-B-TREE (כן, ZFS שומר את הקבצים ב-B-Tree) ועוד המון דברים. ZDB הוא ה"אולר השוויצרי" ל-ZFS ועבודה איתו יכולה לתת ביצועים שעוקפים מרחוק כל File System לינוקסי.

יחד עם זאת ל-ZFS יש עדיין חסרונות (שיטופלו בשנה הקרובה):

  • הוספת דיסקים: לא, אתה לא יכול להוסיף עוד דיסק אחד אלא 2 ומעלה. גם החלפת דיסקים קיימים בדיסקים יותר גדולים היא לא בדיוק פיקניק כרגע (אבל זה אפשרי). במהלך 2019 יתווסף קוד להוספה דיסקים – אפילו דיסק בודד כמעט מבלי שנצטרך להתמודד עם איטיות של פריסת DATA מחדש (יועתקו מספר בלוקים בודדים וזהו).
  • עבודה עם SSD – אחד החלקים היותר נחמדים ב-SSD זו פקודת trimfs שאומרת ל-SSD לבצע פקודת TRIM ב-SSD. ב-ZFS יש תמיכה ל-Trim אך היא אינה אוטומטית בגירסת ZFS ללינוקס. יש Pull request שיכול לעבוד ברוב המקרים בגירסה הנוכחית היציבה של ZFS ללינוקס, ובגירסת ה-Master זה עובד בצורה טובה. אני מאמין שבחודשים הקרובים זה יוכנס פנימה.

לסיכום: אפשר להקים שרת ZFS תוך דקות ספורות על מכונה חדשה. יוצרים pool עם תצורת RAIDZ רצויה, מחלקים דיסק SSD ל-2 פרטישנים (אחד log ואחד cache, ככלל עדיף 2 SSD שיעבדו כ-Mirror), מצמידים אותם ל-pool ויאללה – יש מערכת ZFS עובדת. העניין הוא שאם אתה רוצה ביצועים מעולים, תצטרך להשקיע זמן בהגדרות דברים לפי מה שרוצים להריץ ומה ה-ZFS צריך לשרת (ואני ממליץ את הספר הזה ל-ZFS על לינוקס, או את הספרון הזה). האם ZFS הוא פתרון חלופי לסטורג' סגור – במקרים מסויימים כן ובמקרים מסויימים לא (תלוי בדרישות ובצרכים), אבל הוא מאוד מתאים אם חברה מחליטה להקים סטורג' קטן והיא מוכנה להשקיע את שעות העבודה כדי לבצע אופטימיזציה וזה לוקח זמן (לפי הידע של מי שמבצע זאת), זה לא משהו שנעשה בחצי יום, וצריך לעיתים להקים מערכת שלמה כדי להגדיר לבדוק את הביצועים.

תכירו את Redfish

אני רוצה להכיר לכם את Redfish. בעקרון, Redfish זה API סטנדרטי לנהל כמעט כל דבר בתחום ה-IT, החל מ-SDDC (כלומר Software Defined Data Center) וכלה בשרתים, שרותים, מתגים ובקיצור כמעט כל דבר שניתן להתחבר אליו. Redfish משתמש בסטנדרטים קיימים (REST API, web services ופלט כ-JSON) על מנת לעשות את החיים הרבה יותר קלים למחלקת ה-IT בחברה.

אחד הדברים שצריך לדעת על Redfish שזה משהו ענק שמשתתפים בו כל המי ומי בתחומי הברזלים לדוגמא. לפוסט הזה, אני מעוניין להתרכז בתחום ה-OOB (שזה אומר כל ה-iDRAC/IMM/ILO/IMC למיניהם).

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

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

כשמדובר על כמות של 1-3 שרתים, זה לא כזה ביג דיל, אבל אם מדובר על פרויקט חדש והגיעו 20 שרתים.. אתם יכולים לדמיין את הכאב ראש.

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

איך? עם ה-API של Redfish. כאן לדוגמא תוכלו למצוא עבור שרתי Dell סקריפטים הן ב-Python או ב-PowerShell על מנת להשתמש עם ה-Redfish בחיבור ל-iDRAC לעשות כמעט הכל, החל מהגדרת UEFI/BIOS, שדרוגי קושחה, הגדרות iDRAC, הגדרות RAID ושלל ירקות נוספים.

הכל טוב, רק שיש בעיה אחת קטנה: יש לי 20 שרתים להקים, להתחיל לשנות כל פעם סקריפטים? לכתוב סקריפט wrapper שמריץ את הסקריפטים שניתנים באותו אתר? זה חתיכת כאב ראש.

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

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

לסיכום: Redfish נותן סוף סוף דרך "לדבר" בצורה מאובטחת עם הציודים שלכם דרך סקריפטים שונים שניתנים לשימוש באוטומציה. אפשר גם להגדיר כך הגדרות שונות וגם לקרוא לדוגמא מה-OOB את התקלות האחרונות מה-Log. אם נחכים להשתמש גם ב-PXE (אני דווקא ממליץ על IPXE במקום PXE, הוא הרבה יותר מהיר כי הוא עובד ב-HTTP ולא TFTP כך שניתן לעבוד מהר ובמקביל) נוכל גם להתקין בצורה אוטומטית תוך שימוש בכלים כמו kickstart או preseed להתקין מערכות הפעלה שונות בתצורה מינימלית ואת השאר לעשות עם Ansible (כן, כולל Windows, אסביר בפוסט הבא) ובכך לחתוך את הזמן להקמת השרתים בעשרות אחוזים וגם התחזוקה תהיה הרבה יותר מהירה ואוטומטית.

להלן וידאו הדגמה של Dell מכנס Red Hat Summit האחרון שנערך לפני ימים ספורים:

על Ceph ועל HCI – סיבוב בדיקה נוסף

כתבתי כאן בעבר על סוגי סטורג' מבוסס קוד פתוח וניסיתי לענות על השאלה האם הם מתאימים לפתרונות HCI (כלומר Hyper Converege Infrastructure). התשובה שלי לגבי Ceph היתה בפשטות: לא.

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

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

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

והדברים שתצטרכו:

  • כוננים קשיחים מכניים? החוצה.
  • מעבדים – כרטיסי ה-XPoint של אינטל לא יעבדו (לא Boot ולא נעליים, הכרטיסים מצריכים UEFI 2.3.1 מהשנה וחצי האחרונות) על מעבדי E5 מדור 4 ומטה, תצטרכו שרתים חדשים מבוססי Xeon SP כך שגם את השרתים תצטרכו להחליף.
  • כונני SSD 3D של אינטל – זולים, הם לא. המחיר בשוק הוא בערך 3,500$ פר דיסק (וכן, הם צריכים PCIe 3.1, כך שגם שם אתם צריכים להתקין אותם בשרת חדש), כלומר ההדגמה של אינטל עולה רק מבחינת דיסקים 14,000$. (הדגם שהוצג בתצוגה הוא דגם ישן, כיום מוכרים את ה-P4600).
  • ליבות והרבה – המעבד שאינטל הדגימו (ושייכו אליו הרבה ליבות עם CPU Affinity) הוא Xeon SP Platifum 8176 עם 28 ליבות. מחירו בשוק (מעבד בלבד): 8500$.
  • זכרון – כן, ה-384 ג'יגה אמנם אינו מינימלי אבל הוא די באמצע, כך שלרדת מהכמות הזו תפגע בביצועים.
  • כרטיסי רשת במהירות 25 ג'יגה – כמובן שתצטרכו סוויצ' תואם, אתם יכולים לנחש את המחיר.

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

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

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

הסברים על SSD למשתמשים ביתיים ובחברות

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

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

הבעיה מגיעה לכך שכמעוניינים לקנות כונן SSD, ההיצע בשוק ענק, הטקסט השיווקי מטעה בלא מעט מקרים, ואפשר להוסיף על כך כל מיני הצהרות של אנשים טכניים שהיו נכונים לפני 6-9 שנים אך לחלוטין לא נכונים כיום (כן, קרה לי כבר פעם שמישהו מאוד בכיר טען בישיבה כי כונני ה-SSD לא יחזיקו מעמד 5 שנים. יש לי 4 כונני SSD בשרת ZFS שמחזיקים כבר 6 שנים של SanDisk בלי שגיאה אחת והם דווקא מהסוג הכי פשוט שיש!).

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

ניקח כונן SSD, ונפתח אותו. כך הוא נראה בצידו העליון:

כך נראה הכונן. בחלקו השמאלי יושבים מספר שבבי NAND שעליהם יאוחסן המידע. השבב עם ה-M (של חברת Marvell) הוא בעצם ה"מוח" של כונן ה-SSD. הוא הבקר שמצד אחד "מדבר" עם המחשב (החיבורים מימין) ומצד שני הוא האחראי לפריסת הנתונים על שבבי ה-NAND, תחזוקת הנתונים, טיפול בשגיאות, קריאה, כתיבה וכו'. במקרים רבים יש עוד שבב או יותר שמשמשים כזכרון חוצץ (Buffer) אשר מקבלים את הנתונים מבחוץ (אם לדוגמא אנחנו מעתיקים קובץ מבחוץ אל תוך ה-SSD) והבקר כבר דואג לקבל את הנתונים מהזכרון החוצץ ולפרוס אותם אל שבבי ה-NAND. יש עוד פעולות כמו Garbage Collection ו-TRIM שלא ניכנס אליהם אבל הם דברים מאוד חשובים לאורך חיי ה-SSD.

נעבור מכאן לשבבי ה-NAND. אלו השבבים שבהם מאוחסנים הנתונים שלנו. בתוך כל שבב כזה נמצאים מיליוני תאים שמאחסנים את הנתונים והגישה אליהם נעשית דרך הפינים מתחת לשבב. ישנם מספר סוגי תאים (SLC, MLC, TLC, QLC) פרי פיתוח של השנים האחרונות וההבדל ביניהם הוא בעצם כמות הנתונים שאפשר לאכסן פר תא. SLC לדוגמא זה Single Level Cell, כלומר בכל תא אפשר לאחסן נתון אחד וה-SSD הראשונים היו בנויים מ-SLC, כך שהם היו מהירים מצד אחד, אך כמות המידע שהיה אפשר לאחסן – היתה קטנה. MLC הגיע לאחר מכן ולמרות ש-M זה Multi, כמות הנתונים שהיה אפשרי לאחסן היתה בעצם 2 נתונים בתא. (מדוע לא קראו לזה פשוט DLC ש-D הוא Dual, אין לי מושג ירוק). אחרי MLC הגיע TLC (שנמצא ברוב כונני ה-SSD בשוק היום לסקטורים שאינם שרתים) ששם אפשר לאחסן 3 תאים והאחרון (QLC) יכול לאחסן כמות נכבדה של 4 נתונים בתא אחד.

אחת הבעיות הכי מאתגרות בתחום ה-SSD ו-NAND היתה בעצם האפשרות לאחסן כמות גדולה (אני מדבר על תקופת ה-SLC ו-MLC). יש גבול לגודל שבב שאפשר לייצר (ככל שהשבב יותר גדול, הסיכוי לתקלות בו יותר גבוה, בגלל זה מעבדים ו-GPU הם יקרים), ולכן סמסונג (ולאחר מכן חברות אחרות) החלו לעבוד על טכנולוגיה חדשה – במקום ליצור תאים יותר ויותר קטנים על מנת להכניס נתונים רבים – לבנות לגובה, וזה מה שנקרא 3D. בהתחלה סמסונג יצאה עם שבב שיש בו בעצם 32 "שכבות" ולאחר מכן 64 שכבות וכרגע הם מתחילים לייצר 96 שכבות ועובדים על 128 שכבות, כאשר בין כל השכבות יש מעין "מוטות" ותקשורת בין השכבות והבקר כמובן יכול לגשת לכל השבבים ולכל השכבות.

עכשיו שיש כמות רצינית של תאים פר שבב, ניתן לעשות מאות ג'יגהבייט וטרהבייטים, אבל ישנה בעיה אחרת: זוכרים את ה-SLC/MLC/TLC/QLC? הזמן שלוקח לכתוב לאותם תאים הוא יותר ארוך ככל שמתקדמים מ-SLC ל-MLC, מ-MLC ל-TLC, ומ-TLC ל-QLC (כאשר QLC יהיה די איטי אך יותר מהיר מכונן מכני), ולכן ה-Buffer יכול לסייע ובעצם "להחביא" את האיטיות כאשר הכתיבה בפועל תיעשה בתוך ה-SSD ברקע (בעקרון, כונן SSD הוא הרבה יותר חכם מאשר כונן דיסקים מכני. כונן SSD הוא מחשב שלם בפני עצמו הכולל מעבד, זכרון וכו').

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

נתחיל ב"קופסא" – אלו בד"כ כונני ה-SSD שאנחנו מכירים ללאפטופים ושיכולים כמובן להיות מחוברים לתחנות עבודה, דסקטופים וכו'. כל כונני ה-SSD הם בגודל אחיד של 2.5" (יש גם 3.5" אך הם מיועדים לסקטור השרתים והם עולים עשרות אלפי דולרים) והחיבור שלהם הוא חיבור SATA רגיל בדיוק כמו חיבור דיסק קשיח מכני (לאלו שיש להם מחשב ישן דסקטופ, ניתן לרכוש כמובן בזול מתאם בין 3.5" ל-2.5" ב-eBay ובאתרים אחרים, ובחלק מהמוצרים היצרן מוסיף מתכת להתאמה, כמו חברת Kingston). אין צורך בדרייברים על מנת לקבל פעילות של כונן ה-SSD (אך יכול להיות שתצטרכו תוכנה מסויימת, עליה אדבר בהמשך). דיסק SSD כזה הוא דבר מעולה לאלו שיש להם מחשבים ניידים עם דיסקים מכניים והם מעוניינים להשביח את המחשב הנייד שלהם. ישנן מספר תוכנות חינמיות שיכולות להעביר את הנתונים מהדיסק המכני לדיסק SSD (לשם כך תצטרכו לרכוש מתאם USB ל-SATA על מנת לחבר את כונן ה-SSD בחוץ ולהשתמש בתוכנה להעביר את הנתונים ורק לאחר מכן להעביר את ה-SSD לתוך המחשב הנייד).

חוץ מגירסת ה"קופסא" יש לנו את גירסת ה"מקל" – אלו בעצם כונני SSD בתצורה שמתברגת על לוח האם של המחשב (ושל מחשבים ניידים חדשים, בחלק מהמקרים). מדובר ב"מקל" ברוחב 22 מ"מ ובאורך 80 מ"מ (יש גם גירסה של 110 מ"מ) שאותו אנחנו מחברים לחיבור מיוחד ומבריגים. החיבור נראה כך:

כפי שאתם יכולים לראות: ישנם "חורים" היכן שנמצאים הפינים של ה"מקל" והם מאוד חשובים. בכרטיסים עם 2 חורים, ה"מקל" הוא בעצם SSD בחיבור SATA, כלומר המהירות שלו תהיה בדיוק כמו קופסת SSD בחיבור SATA והיתרון היחיד שלו הוא בעצם שהוא לא תופס מקום פיזי במחשב מקדימה. לעומת זאת, אם יש חור אחד, אז מדובר במקל NVME SSD שהוא מהיר פי 4-6 מכונן SSD SATA (ולפיכך הוא גם עולה יותר).

עוד סוג חיבור שיש הוא חיבור ה-U.2, הוא מופיע בריבוע הכחול בתמונה:

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

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

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

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

  • סמסונג – המלכה בשוק. דגמים של ה-960 וה-970, ה-PRO או EVO (ה-PRO יותר מהיר)
  • אינטל – ה-900P או ה-905P בסידרת ה-Optane. שימו לב שהם יקרים מאוד אך ה-905P הוא ה-SSD הכי מהיר שיש כיום בשוק נכון לשעת כתיבת שורות אלו. שימו לב – הפתרונות של אינטל יעבדו רק אם יש לכם מעבדי AMD Ryzen או i7/i5/i3 מהדור השביעי (Kaby Lake) או דור שמיני (Coffee Lake).
  • Western Digital – סידרת ה-Blue או Black בגירסת M.2 NVME.

אלו שלא מומלצים – אני בד"כ לא פוסל SSD כי כמעט תמיד יש סקטורים שזה יכול להתאים להם גם אם הם לא מהירים כל כך, אך במקרה של אינטל, סידרת ה-Optane Memory Series – בגדלים 16,32,64 ג'יגהבייט אני ממליץ לא לרכוש. הם מבחינה טכנית פשוט זבל וכל דיסק SSD מכל יצרן יתן ביצועים הרבה יותר גבוהים עם הפרשי מחירים זעומים.

אז בחרנו SSD ואנחנו מכניסים אותו למחשב. לפרמט ולהשתמש? כמעט. כלל חשוב הוא לא לפרמט את הדיסק לניצול 100% ממנו אלא רק 90%. הסיבה לכך פשוטה: במסגרת התהליכים שבקר ה-SSD מבצע, הוא בודק תאים לבדוק שהנתונים תקינים וכשהוא נתקל בנתונים שיש סיכוי שתהיה בעיה איתם בקריאה/כתיבה, הוא מעבר אוטומטית את הנתונים לחלק שלא פירמטנו והוא מסמן את המקום שממנו הוא העתיק כמקום לא שמיש, כך שאנחנו אולי מפסידים חלק מהמקום בדיסק, אך מצד שני אנחנו מאריכים את אורך חיי הדיסק, וזה שווה את המחיר.

האם כדאי לוותר על הדיסק המכני? התשובה שלי: לא. דיסק מכני הוא מצד אחד זול ומצד שני יכול להכיל הרבה יותר מידע מאשר SSD (סתם לידיעה, סמסונג 850 EVO בגודל 4 טרהבייט יעלה לכם בחו"ל 1500-1700 דולר). בד"כ יצרן ה-SSD יציע תוכנה יחד עם ה-SSD שתעביר את ה-Windows ל-SSD וידע לנטר את הדיסקים כך שנתונים שהקריאה שלהם שכיחה יועברו ל-SSD והנתונים שבקושי קוראים אותם ישארו בדיסק המכני. לאינטל יש תוכנה כמו RST שעושה זאת ול-AMD יש הסכם עם חברת Enmotus למכור תוכנה ב-20$ שנקראת FuzeDrive (היא אמנם מצריכה התקנה של Windows על ה-SSD מחדש, אבל היא עושה עבודה הרבה יותר רצינית מה-RST של אינטל), ויש כמובן תוכנות צד ג' בשוק ל-Windows (חלקן חינמיות). למשתמשי Linux – אם אתם משתמשים ב-LVM במחשב שלכם, אז ה-LVM יכול לקבל כונן או ווליום או Partition כ-Cache ואפשר כמובן להשתמש בדברים כמו bcache כדי לקבל את אותה תוצאה.

דברים נוספים שכדאי לדעת:

  • מעתיקים קבצים של כמה ג'יגהבייט כל אחד? אל תצפו לכתיבה מהירה לאורך כל ההעתקה ברוב כונני ה-SSD (למעט ה-900P/905P וה-970 PRO). הסיבה? הזכרון החוצץ (Buffer) מתמלא ומתחיל לכתוב את הנתונים לשבבי ה-NAND וברגע שאין זכרון פנוי, הכתיבה נהיית איטית.
  • עובדים בפוטושופ ופתחתם קובץ עם מאות שכבות? אם זה לא SSD מהמהירים – יכול להיות שזה יהיה איטי במעט. זיכרו: דיסקים SSD זולים הם טובים בהעברת נתונים רציפה כאשר מדובר בהעברת קובץ גדול, אולם כשיש לו עוד 200 קבצים נוספים, הוא יהיה איטי.
  • מחירים: מחירי ה-SSD יורדים אבל לאט. אם מחירי הדגמים שציינתי לעיל יקרים, אתם מוזמנים להתסכל דור אחד אחורה או לקרוא כל מיני אתרים שמציינים מיקומים שונים לכונני SSD ומחירים.
  • אחריות – כיום כמעט כל יצרני ה-SSD נותנים מינימום 3 שנות אחריות, אינטל וסמסונג בד"כ נותנים 5 שנות אחריות ולדגמים מסויימים אפילו 10 שנות אחריות. חשוב לכל ה-Corporate.
  • משתמשי לינוקס ובחירת File System – אין ממש הבדל. כיום גם XFS, EXT4, BTRFS תומכים בפרמטר mount או עם פקודת fstrim. מערכת ZFS לעומת זאת תתמוך בגירסה 0.8 בפונקציונאליות הזו (אם כי קיימים טלאים שאפשר להשתמש בהם).
  • קונים גירסה M.2 והולכים לגרום למחשב "להזיע"? חפשו ברשת קירור טרמי ל-M.2. אחד החסרונות של M.2 (בחלק מהמקרים) הוא כשה"מקל" חם מאוד – הביצועים יורדים על מנת לשמור עליו. הפתרון הזה לדוגמא, הוא פתרון טוב.

ומה העתיד? אינטל דוחפת חזק את פתרון ה-XPoint שלה שהוא כרגע המהיר ביותר בשוק (אבל גם היקר ביותר – ה-905P שלהם בגירסת ה-600 ג'יגהבייט עולה 1220$ והוא יותר מהיר מגירסת ה-Enterprise שלהם!) אבל סמסונג לא נמצאת מרחוק עם ה-Z-SSD שלהם שמציע ביצועי קריאה יותר מהירים מכל דבר אחר בשוק (ביצועי כתיבה, לא משהו בדור הנוכחי).
סביר להניח שבשנה הבאה נראה SSD מבוסס QLC (שזה 4 נתונים נכתבים/נקראים בכל תא). החסרון הענק שלו הוא מהירות הכתיבה שתהיה די "זוחלת" (בהשוואה ל-SSD אחרים), אבל מצד שני נוכל לרכוש SSD כאלו בגדלים של 4 ו-8 טרהבייט במחיר שלא מגיע לאלפי דולרים ובכך נוכל להחליף כוננים מכניים ב-SSD.

לסיכום: כונני SSD נותנים ביצועים הרבה יותר מהירים מכונני דיסקים מכניים, אבל הם גם "חיות" שונות וכדאי לשים לב להבדלים. השוק מוצף ב-SSD שונים ולכן כדאי לבצע מחקר קטן לפני ששולפים את כרטיסי האשראי. כדאי לשים לב להוראות יצרן לדברים כמו לא לפרמט SSD ל-100% ואם מדובר ב"מקל" M.2 לגבי עניין החום.