תגית: אחסון

אחסון Scale Out בקוד פתוח – פוסט עדכון

כתבתי בעבר לגבי Ceph ולגבי GlusterFS. בפוסט זה אנסה לענות לשאלה שחוזרת מדי פעם אצלי באימייל: במי מהם לבחור אם הולכים על Scale Out Storage?

בשביל לענות, נתחיל מההתחלה הפשוטה: רוב הארגונים רוכשים לעצמם סטורג' קנייני כלשהו שעובד בשיטת ה-Scale Up: רוצה יותר אחסון? תוסיף מדפי דיסקים, SSD, Cache וכו' וכו'. ברוב הארגונים לעומת זאת, כשחושבים לדוגמא על Cluster Storage במובן של 2-3 מכונות סטורג' נפרדות שמסונכרנות ביניהם – המחיר של הפתרון הקנייני מרתיע ואז מתחילים להישלח אימיילים ולחייג ליועצים שונים.

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

כיום, אני שמח לציין, שום ארגון רציני (כולל משרדי ממשלה, משרד הבטחון וכו') לא פוסל מלשמוע הצעות על SDS (כלומר Software Defined Storage) מבוסס קוד פתוח, במיוחד שיש לזה "אבא" בארץ כמו Red Hat או SuSE. בכל הארגונים שציינתי יש פתרונות של יצרני הפצות הלינוקס הנ"ל.

מבחינת תחרות, יש 2 פתרונות, וכל אחד מהם מיועד לשוק ולצרכים מסויימים. אף אחד מהם לא הולך "לסגור את הבאסטה" בקרוב. 2 הפתרונות הם Ceph מול GlusterFS. את Ceph אפשר לרכוש מ-Red Hat ו-SuSE, ואת Gluster מ-Red Hat (את שתיהם כמובן אפשר להוריד בחינם, אבל אני לא ממליץ במערכות פרודקשן קריטיות להריץ את הגרסאות קוד פתוח).

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

  • משרד האוצר פונה אליי בבקשה להקים SDS בגודל 4 פטהבייט שיאכסן ארכיב של מידע ישן: הודעות לעיתונות, גיבויים, מסמכי הצעות שונות ותוכן נוסף שכולו מורכב מקבצי אופיס ופורמטים אחרים. הגישה אל האחסון למשתמשים תהיה דרך SMB/CIFS בלבד עם הרשאות AD. אין גישת Web או שום דבר אחר. אחסון קבצים קלאסי.
    ההצעה שלי אליהם: GlusterFS.
    מדוע? GlusterFS מיועד לתת גישה לקבצים בלבד, בין אם דרך NFS או SMB/CIFS. קל להרחיב אותו (מוסיפים עוד ברזלים עם דיסקים, מחברים לסוויצ', מתקינים מערכת הפעלה, מריצים כמה סקריטפים ותוך שעות ספורות יש עוד כמה מאות טרהבייט זמינים) והרבה יותר קל לנהל אותו בהשוואה ל-Ceph.
  • ערוץ "כאן" פונה בבקשה להקים SDS בגודל 20 פטהבייט. בסטורג' הזה יאוחסן כל הסרטים, הסדרות, החדשות וכל מה שצולם עוד מימי הערוץ הראשון והטלויזיה החינוכית – והכל יהיה זמין דרך פורטל VOD לגולשים בארץ דרך נגן HTML5 יעודי והוידאו יוגש בזרימה או להורדה לתצוגה ב-Offline.
    ההצעה שלי אליהם: Ceph.
    מדוע? במערכת Ceph כל דבר שמאוחסן – מאוחסן כאובייקטים שבתוכם יאוחסנו הנתונים בפורמט שאנחנו רוצים. במקרה של "כאן" לדוגמא – כל קבצי הוידאו יאוחסנו כ-Object Storage וכל קליפ מקבל זיהוי יעודי משלו, מה שעוזר מאוד בגישה מהירה לקליפ ולהתחלת השידור שלו. כך, אגב, רוב חברות המדיה מאחסנות באמזון את קבצי הוידאו שלהם (ב-S3 ולא תחת File system עם איזה סטורג' כלשהו). ל-Ceph יש יתרון של Seek מהיר מאוד, והעברת מידע מהירה.
  • משרד הבטחון מקים מרכז מיחשוב חדש לאחד מהחילות. במרכז יהיו 200 שרתים פיזיים שיריצו וירטואליזציה כלשהי (נניח OpenStack או VMware) ומערכת Kubernetes או OpenShift. במשרד מעוניינים ב-SDS בגודל 30 פטהבייט עם אופציה לגדילה מהירה.
    ההצעה שלי אליהם: Ceph
    מדוע? כי Ceph יכול לאפשר ליצור Block Devices וירטואליים וגישת קבצים קלאסית (File System – CephFS) עם שרידות גבוהה. אם לדוגמא הם ישתמשו ב-OpenStack, הם יכולים ליצור דרך Ceph דבר שנקרא RBD (כלומר Raw Block Devices) ואם הם משתמשים ב-VMware – הם יכולים לקבל iSCSI כמו שהם רגילים אליו, ואם הם מעוניינים ב-NFS – אפשר ליצור ולייצא את זה מ-Ceph דרך ה-CephFS ואפשרי לתת להם גם שרותי PV ל-Kubernetes לדוגמא.
  • חברת "שופרסל" מעוניינת ב-SDS  בגודל 5 פטהבייט שיאכסן גיבויים, קבצים וכו'. הם מעוניינים שבחוות שרתים אחרת ישב SDS זהה עם סינכרון מתמשך בין ה-2.
    ההצעה שלי: GlusterFS
    מדוע? מכיוון שגם כאן מדובר בקבצים בלבד בשיטה המסורתית ו-GlusterFS כולל  בתוכו פונקציות לסינכרון מתמשך בתנאי תקשורת שונים מבלי להעמיס על התקשורת או להאיט את שרותי ה-File Server.

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

נסכם את היתרונות והחסרונות של כל מערכת SDS:

  • ל-Ceph יש יתרון גדול בכך שזו מערכת רצינית לתת לך כל סוג של פורמט נתונים שאתה רוצה, בין אם מדובר ב-File Server קלאסי, Block Device, Object Storage ועוד. למערכת יש שרידות מצוינת (כך שאם נופל שרת Ceph – המערכת ממשיכה לעבוד כרגיל). ב-Ceph יש תמיכה ל-tiering, דחיסה, Dedup וכל הדברים שמוצאים ב-Scale Up.
  • ל-GlusterFS יש יתרון בכך שהיא מיועדת בדיוק לדברים הקלאסים של File Server (דרך CIFS/NFS) ותו לא. אפשר להקים אותה על ברזלים ישנים, היא תומכת גם ב-RAID חומרה או RAID תוכנה, היא לא דורשת המון משאבים (מבחינת CPU/זכרון) וממש לא אכפת לה מה ה-File System מתחתיה. ל-GlusterFS יש Load Balancing מובנה, כך שאם יש צורך ב-File Server שישרת מאות משתמשים ובגדלים של עשרות או מאות טרהבייט ומעלה – GlusterFS היא בחירה טובה ויחסית קלה יותר ללימוד בהשוואה ל-Ceph.

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

בואו נדבר קצת על IOPS

IOPS, או Input Output operations Per Second – הוא אחד המושגים הכי ערמומיים שנכנסו לשוק הדיסקים והסטורג'. אם אינני טועה, מי שהתחיל עם העניין היתה חברת Sun עם ה-ZFS ששולב ב-Solaris 10. באותו זמן, החלו לצאת ה-SSD הראשונים (קטנים מבחינת כמות אחסון, ויקרים רצח).

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

לשם כתיבת פוסט זה השתמשתי ב-SSD בתצורת M.2 NVME מסוג Samsung 960 EVO בגודל חצי טרהבייט על מנת לבדוק את הדברים בטרם אני כותב את הפוסט הזה ועל מנת להיות בטוח. הכלים שהשתמשתי במהלך הבדיקות לשם כתיבת פוסט זה: FIO ו-IOMeter.

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

על הנייר, ה-SSD הזה אמור לתת ביצועים מעולים! 330,000 IOPS בכתיבה בבלוגים של 4K כשיש 4 עבודות במקביל! נשמע פנטסטי, לא?

אז זהו. שלא. בעזרת שימוש בכלים כמו אלו שציינתי לעיל – אפשר להגיע למספר שציינתי לעיל (למען האמת, קצת יותר – 349,400 לפי הניסוי שלי). העניין הוא, שברגע שכשמייצרים Partition עם גודלי בלוקים שונים (ולא חשוב מה גודל הבלוקים, גם אם אתה מגדיר נכונה את הבלוקים ביחס לקבצים שאתה הולך לאחסן) ומפרמט ל-File system כלשהו ותנסה למדוד עם פרמטר direct=1 עם FIO לדוגמא, תגלה שמספר ה-IOPS צלל בערך במחצית! כלומר אם ננסה לגשת ישירות ולמדוד עם direct על ה-file system שב-SSD – המספרים יהיו הרבה יותר נמוכים. כמובן שאם נשתמש ב-SSD דרך מערכת ההפעלה ללא גישת Direct, המהירות תהיה גבוהה יותר, וזאת מכיוון שמערכת ההפעלה משתמשת בכל מיני דברים כמו Cache, Scheduling וכו' כדי להציג מהירות גבוהה (במיוחד שדברים נעשים ברקע ולא ישירות).

ה-IOPS עצמו נמדד בקטגוריות שונות כמו קריאה אקראית (Random Read), כתיבה אקראית (Random Write), קריאה טורית/רציפה (Sequential Read), כתיבה טורית/רציפה (Sequential Write). את מספר ה-IOPS מכפילים בגודל הנתונים שעוברים פר שניה והתוצאה היא כמה Bytes לשניה מקבלים (את זה נהוג בתוך כלל לחלק למגהבייט לשניה).

נחזור לטבלה של סמסונג המוצגת למעלה. אחד הנתונים שמופיעים שוב ושוב בסוגריים הוא QD, כלומר Queue Depth. בעקרון מדובר בעצם על מנגנון של "תורים", כאשר בכל תור נכנסים משימות לביצוע. ככל שיש יותר תורים לדיסק, כך ניתן לעשות יותר פעולות. בדיסק SSD בחיבור SATA למשל, ישנם 31 תורים. ב-SSD NVME לעומת זאת, עניין התורים הורחב משמעותית ושם יש 65,000 תורים ובכל תור יכולים להיכנס 65,000 עבודות! המספר הזה הוא כמובן רק תיאורתי, ולא מומלץ לנסות להגדיר את ה-Queue Depth מעבר ל-128 (אלא אם אתם ממש עשירים ואתם רוצים לרכוש SSD כמו Samsung 983 ZET, עניין של 2000$ לחצי טרה, ולמעט מקרים מיוחדים, הוא לא יתאים לרוב השימושים. כרטיס זה יודע לתת ביצועים טובים יותר ב-QD של 128 ומעלה).

עוד נקודה שמופיעה בטבלה היא Thread – ו-Thread בעצם מדבר על כמות עבודות במקביל לאותו SSD ולפי הטבלה של סמסונג, המספרים המוצגים הם כשרצים 4 עבודות, וזו אחת הנקודות שכדאי להתמקד עליה: SSD NVME – בין אם ביתי/מקצועי או ל-Enterprise יתן עבודה יותר מהירה כשיש מספר עבודות במקביל. יחד עם זאת, תריצו 100 עבודות כתיבה על הדיסק במקביל ותקבלו SSD זוחל, לא חשוב איזה דגם או מאיזה יצרן.

עוד נקודה שאמנם לא מופיעה בטבלה אך היא חשובה מאוד לביצועים – היא המתזמן במערכת ההפעלה (ה-Scheduler) לאותו ציוד. בלינוקס יש מספק Schedulers וכיום הפצת לינוקס עדכנית מזהה את הדיסק (מכני או SSD, חיבור SATA או NVME) ומתאימה אוטומטית את ה-Scheduler המתאים לדיסק (אפשר כמובן לשנות אם רוצים). ה-Scheduler חשוב מאוד ובחירה שגויה תפגע גם בביצועי ה-IOPS. חשוב לזכור: גם לבקר הדיסקים, ל-HBA וכו' יש הגדרות Queue Depth ואם אתם משתמשים ב-VMWare אתם יכולים לקרוא על כך בהרחבה כאן.

עניין ה-Block Size הוא גם דבר שיכול להשפיע על ה-IOPS, אבל בעקיפין. אם לדוגמא הגדרתי Dataset ב-ZFS בגודל 128 קילובייט ואני כותב קבצים בגודל 2-4 קילובייט, אז לא רק שאני מבזבז מקום, גם הביצועים ירדו. מצד שני, בחלק מהסטורג'ים זה לא כל כך ישפיע בגלל ה-Cache שיש בסטורג' עצמו, כך שזה נושא נתון לויכוח ובכל מקרה מומלץ לחשוב היטב לאיזה גודל בלוקים להגדיר את ה-Volume/Partition/Dataset ובמקרה של ZFS תמיד ניתן לשנות מבלי להרוס דברים.

מכאן נעבור לסטורג', החלק שרבים מתעניינים בו 🙂

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

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

  • הגדרות לא נכונות של מערכת ההפעלה ב-VM עם כמות זכרון מופחתת, מה שיכריח את ה-OS להשתמש ב-Swap. ה-Swap יושב ב.. סטורג'.
  • הגדרות Scheduling ב-VM עצמו.
  • העתקה/מיגרציה של קבצים רבים מסטורג' אחר
  • רפליקציות LIVE מתמשכות
  • פעילות שנעשית דרך VAAI (ה-VAAI או VVOL אינם הוקוס פוקוס, להזכירכם).
  • גיבויים (כן, גם ל-CBT יש מחיר, תלוי כמה מכונות VM מגבים)
  • הגדרות בלוקים לא נכונות ב-Volume/Partition.
  • כתיבות של טרהבייטים
  • ועוד ועוד..

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

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

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

קצת על אחסון נתונים ונקודות חשובות לפני החלטה

[stextbox id='info' mode='css' direction='rtl' shadow="false"]הערה: בפוסט זה אני רוצה להתייחס לנקודות שלדעתי חשובות לפני שמחליטים לקנות או לבנות סטורג'. פוסט זה אינו בא להמליץ על יצרן מסוים, דיסקים מסויימים וכו'. הפוסט נכתב כחומר למחשבה בלבד.[/stextbox]

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

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

לפני שאמשיך – הערה קטנה: תודות לחברות שונות (CRG, ווסטרן-דיגיטל, סופר-מיקרו ואחרות) השאלתי ציוד כדי להעביד אותו בפרך (Stress Testing) למשך חודש או חודשיים, 24/7 עם תעבורה רציפה מקסימלית (תקשורת/דיסקים, מעבדים, מאווררים, תלוי בטסטים המתבקשים) בהתאם לסטנדרטים של IEEE וארגונים אחרים על מנת לבדוק לחברות וארגונים שונים אם המפרט שהם מבקשים יכול לעמוד בעומסים שונים. כך שהדברים שיכתבו כאן – נוסו.

(בתמונה למעלה: לקוח שרצה לבדוק LACP של 12 פורטים עם תעבורת נתונים של 16 פטהבייט. המבחן עלה לו יותר מסוויצ' 10 ג'יגהביט Low End, אבל – הלקוח דורש ומשלם, אני לא אומר "לא".)

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

הבה נתחיל.

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

  • כמה אחסון נטו אתם צריכים? עזבו חישובים של RAID כזה או אחר, דחיסה, dedup ושאר ירקות. 2 האחרונים הם נחמדים, אך לא תמיד יתנו לכם את מה שאתם מבקשים (זה תלוי בתכנים).
  • כמה לקוחות (clients) הולכים להשתמש בזה? יש הבדל ענק בין אחסון שמשמש לכמה עשרות/מאות מכונות וירטואליות, כמה אלפי משתמשים פיזיים שמשתמשים באחסון כ-File Server או עשרות/מאות אלפי משתמשים דרך האינטרנט.
  • האם החיבור בין האחסון למכונות אחרות ישתמש בתקשורת מהירה? (FC במהירות 8/16 ג'יגהביט, תקשורת 10 ג'יגהביט קואקסיאלית, TwinAX, סיב, Infiniband וכו') והאם אתה צריך ציוד חדש לחבר את הכל ביחד (גם בצד של השרתים, גם מתגים, חיבור לסטורג' עצמו וכו')
  • אחריות, SLA ושאר נושאים פרוצדורליים.
  • והכי חשוב – יחס הקריאה/כתיבה וסוג התוכן.
  • דיסקים SSD שישמשו כ-Cache, שימוש ב-Cache כ-Tiering וכו'.
  • פתרונות של Synology או QNAP.
  • הרחבת אחסון, זכרון.

להלן הנקודות בפירוט:

  • אחסון נטו: נניח ואתה צריך 40 טרהבייט אחסון נטו. אם נשתמש במחשבון הזה תוכלו לראות ש-5 דיסקים של 10 טרהבייט יתנו לנו 40 טרהבייט אחסון נטו עם שרידות של דיסק אחד (כלומר RAID-5). מצד אחד זה יכול "לסגור פינות" שיש לנו כמות אחסון מספקת, וגם שרידות. הבעיה המרכזית: מהירות כתיבת נתונים ושליפתם. אין לנו שום האצה בכתיבת הנתונים, יש לנו האצה בקריאת הנתונים (שזה אידיאלי אולי לארכיבאות לדוגמא). בשביל לקבל האצה פי 4 בכתיבה ופי 8 (בהשוואה לקריאה/כתיבה מדיסק בודד) נצטרך 8 דיסקים של 10 טרהבייט ב-RAID-10. אם אנחנו רוצים מהירות קריאה/כתיבה יותר גבוהה בהרבה (X10 בכתיבה, X20 בקריאה) נצטרך לעבור מדיסקים של 10 טרה לדיסקים של 4 טרה בייט ולרכוש 20 כאלו (תגידו "היי" למארזי 4U). ככל שנבחר דיסקים יותר גדולים, כמות ההאצה שהמערכת תתן – היא יותר קטנה (לדוגמא: 10 דיסקים של 8 טרהבייט יתנו X5 בכתיבה, X10 בקריאה – הדוגמאות הם ב-RAID-10). טעות נפוצה, אגב, היא שימוש ב-RAID-5: הגדרות RAID-5 נותנת אפס האצה בכתיבה לאחסון.
  • לקוחות שהולכים להשתמש בסטורג'. אם מדובר על שרת קבצים לדוגמא, עניין המהירות הוא יחסית די שולי כי כולם משתמשים בתקשורת 1 ג'יגהביט שברוב הזמן מנוצלת חלקית, ואם מישהו יחכה עוד חצי שניה לשמירת קובץ האקסל שלו, השמיים לא יפלו.
    לעומת זאת – מכונות וירטואליות זה סיפור אחר לגמרי. פרוטקול כמו iSCSI הוא פרוטוקול "מפונק" ומערכת כמו VMWare לדוגמא דורשת אישור מהסטורג' על כל קבוצת נתונים שנרשמת, כך שאם אין איזה מנגנון ש"יאמר" ל-VMWare "קיבלתי, מאשר" בכל פעם ובאופן מהיר – המכונות הוירטואליות פשוט יזחלו בכל כתיבה. כיום ברוב פתרונות הסטורג' (סגורים ופתוחים) יש מנגנון שמטפל בכך, אבל אם תרימו מכונת לינוקס עם MDADM ל-RAID, זה לא יתן פתרון (אפשר לעקוף זאת על ידי ביטול ה-sync ב-ZFS לדוגמא, אבל זה מסוכן, במיוחד אם אין UPS למכונה).
    לכן, כשמדובר בסטורג' שיטפל בכל הקשור לאחסון מכונות וירטואליות, חשוב לבדוק שהסטורג' תומך ב-Sync On write, reclaim space, תמיכה ב-VAAI, VVOL ואחרים.
  • חיבור בין הסטורג' למכונות אחרת. הנה נקודה שרבים יתווכחו עליה מתוך איזה נסיון שיש להם, מתוך אמונות, מתוך שמועות, אך כמו שכתבתי למעלה – הנקודות נוסו על ידי הח"מ בתנאי Extreme.
    חיבורי ה-FC היו מעולים לזמנים שהתקשורת נחושת היתה במהירות 1 ג'יגהביט וחיבורי 10 ג'יגהביט היו יקרים מאוד. כיום, לעומת זאת, ישנם 5 אפשרויות פופולריות:

    • CAT6/CAT-6E – חיבורי נחושת של 10 ג'יגהביט, עובדים מעולה ואם רוצים, אפשר לעבוד עם LACP (או Bridge) בצוותים של 2 חיבורים לדוגמא לקבל מהירות יותר גבוהה. היתרון: עלות זולה יותר של כבלים וסוויצ'ים.
    • +SFP עם TwinAx (נקרא גם DAC) – עובד מעולה למרחקים קצרים (עד 5 מטר). חשוב לשים לב שהחיבורים יהיו מאותו מותג של הסוויצ' (בסוויצ'ים 10 ג'יגהביט בקצה הנמוך זה לא רלוונטי, הם מתעלמים מה-Branding Tag).
    • +SFP עם סיבים אופטיים – את זה כולם ימליצו. לא חוכמה 🙂
    • +QSFP – כמו ה-+SFP רק למהירות 40 ג'יגהביט. מדובר בחיבור פיזי גדול יותר כך שהוא אינו תואם אחורה. קיים גם כגירסת DAC/TwinAX וגם כחיבור עצמאי שאליו מחברים סיב אופטי.
  • אחריות, SLA וכו' – כל יצרניות השרתים מוכרות כיום פתרונות סטורג' (ברזלים יעודיים או תוכנה לשימוש בשרתים עצמם) משלהם, אך יחד עם זאת הן גם "מכשירות" (Certified) תוכנות אחרות, ובדרך כלל ביקור באתר יצרן תוכנת הסטורג' יראה את הלוגואים של היצרנים שנתנו "הכשרה" לתוכנת הסטורג', כלומר אם תפנו לתמיכת יצרן השרתים, אף אחד לא יעקם את האף מדוע אתם משתמשים בתוכנת סטורג' X. בחלק מהמקרים (תלוי בחוזה התמיכה) אולי יסייעו לכם עם תוכנת הסטורג' צד ג' או יפנו את בקשת התמיכה ליצרן התוכנה (במקרים בהם יצרן השרתים [כמו HPE] מכר לכם חוזה תמיכה על כל הציוד והתוכנות שברשותכם).
  • SSD, Caching: בכל סטורג' המשלב דיסקים מכניים ודיסקים SSD – המערכת תורכב מ"שכבות" (או במושג המקצועי: Tiering), כאשר השכבה המהירה מורכבת מהדיסקים SSD והשכבה האיטית יותר מדיסקים מכניים (SAS או SATA). ישנם כמובן סוגי סטורג' שונים שבהם יש עוד שכבות כמו מדף זכרון מגובה סוללות, NVRAM, או שכבות של דיסקים מכניים מהירים ובשכבה מתחת דיסקים SATA במהירות 7200 RPM.
    בכל המקרים הללו, ה-SSD נועד "להחביא" את הדברים הקשורים לכתיבה. הוא מקבל את ה-DATA ולאחר מכן ה-DATA מופץ לשכבות היותר איטיות, והוא גם מאחסן נתונים שנקראים תדיר (נניח יש לך 10 מכונות לינוקס, כולן רפליקציות מלאות או משורשרות – רוב הסיכויים שה-DATA יקרא מה-SSD). ה-DATA עצמו לא נכתב ישר אל הדיסקים המכניים, אבל הסטורג' מציג את הדברים כאלו שהנתונים כן נכתבו למכניים, והסטורג' ברקע עושה זאת.
    במערכות יקרות יותר (מילת קסם: AFA או All Flash Array) ישנם גם שכבות אם כי טיפה שונות: רוב הדיסקים הם Read Intense וחלק קטן מהם Write Intense או Mixed Intense ולפעמים יש שימוש ב-NVRAM או בזכרון מגובה סוללה (נדיר). במערכות הסופר-סופר-יקרות, מכניסים גם Optane, גם כרטיסי FPGA ודברים נוספים כדי להאיץ את הכל (ועוברים בדרך לפרוטוקול ה-RDMA הוותיק) – כמו במערכות NVMEoF לדוגמא.
  • פתרונות של Synology או QNAP: אלו פתרונות שאני יכול להמליץ עליהם בלב שלם כפתרונות לשמירה/קריאה של מידע, פחות למכונות וירטואליות (אם כי ל-LAB קטן הם בהחלט יכולים להספיק). כיום בכל QNAP או Synology ניתן להוסיף דיסק SSD לקבלת Cache בסיסי, אבל אל תנסו להכניס לשם SSD מסוג Optane  לדוגמא (כמו שינוי QD) – בשביל זה יש צורך לשנות כמה וכמה דברים בלינוקס ואין במכשירים הללו לא את הספריות ולא את האפשרויות לשנות פרמטרים.
  • הרחבת אחסון, זכרון: בכל מה שקשור לזכרון, רוב הסטורג'ים שמבוססים לינוקס/BSD/סולאריס ו/או ZFS ישתמשו בזכרון כ"מאיץ ראשי" לקבלת הנתונים ולשחרר את צוואר הבקבוק, כך שאם אתם יכולים להשקיע ברכישת RAM – מה טוב.
    לגבי הרחבת האחסון עצמו: בסטורג' סגור הפתרון תמיד יגיע עם "מדפים" לאחסון הדיסקים. בסטורג' פתוח לעומת זאת, חשוב לבדוק שיש חיבור מאחורה המאפשר לחבר JBOD אחד או יותר על מנת להוסיף קופסת JBOD או יותר עם דיסקים ומומלץ לבדוק שהחיבור הוא SAS-3 (נקרא גם HD MINI-SAS או בשמו המקצועי: SFF-8644). לפני שנתיים שוחרר סטנדרט שנקרא SAS-24G אך אני לא ממליץ לרכוש אותו הואיל ודיסקים קשיחים עתידיים (כמו אלו עם 2 מנועים שאמורים לצאת בשנה הקרובה/שנה הבאה) עוברים להשתמש בחיבור NVME. ה-24G פיספס את הרכבת.

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

כשצריכים סטורג' לעסק קטן

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

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

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

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

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

הבעיה המרכזית לפחות ממה שאני רואה – שיש לא מעט כאלו שרוצים משהו שניתן להרחיב, שניתן להכניס 8-12 דיסקים (דיסקים מכניים הם יחסית זולים כיום, גם בגודל 8 טרהבייט), יש כאלו שרוצים חיבור כפול של 10 ג'יגהביט לשרידות, והרוב המוחלט שיודע שיש שרתים שנמכרים כיד שניה במחירים של 1000-3000 שקל – רוצים פתרון יותר זול ממה שהשניים מציעים. אחרי הכל, פתרון כמו Synology DiskStation DS3617xs מתחיל במחיר של $3000 עם 0 דיסקים.

האם יש איזה פתרון שעונה על הדברים הבאים?

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

יש.

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

היתרון הגדול של XPEnology הוא שאין צורך לרכוש חומרה מיוחדת. גם מעבד i7 ישן עם 8-16 ג'יגה זכרון יעשו את העבודה, ואת החומרה הזו תמיד ניתן לשדרג (אם כי החלפה של לוח אם ומעבד יצריכו, סביר להניח – התקנה חדשה. ה-XPENology מבוסס אמנם על לינוקס, אולם הוא רחוק שנות אמור מכל הפצת לינוקס שלא משנה מה החומרה שתזרוק לה – תכיר את הכל אוטומטית ב-Boot הבא), ולכן את ההתקנה הראשונית צריך לעשות מישהו שמכיר טוב את XPEnology, או שלא תצליחו אפילו לעשות Boot לקובץ ה-ISO הקטנטן. מנסיון. זה, אגב, גם החסרון שלה – הקושי בהתקנה עצמה.

אחרי ההתקנה וההפעלה – החיים (יחסית) דבש – יש לך ממשק גרפי מאוד עשיר (מהדפדפן) – בדיוק כמו כל מכשיר Synology או QNAP, וניתן להגדיר בקלות משתמשים, חיבור AD, שיתוף NFS, iSCSI, SMB (כולל Multipath). להתקין אפליקציות רבות (הרבה יותר ממה שמכשיר טיפוסי שנמכר – מכיוון שרוב המכשירים שנמכרים יכולים להכיל כמות קטנה של זכרון), מכונות וירטואליות, קונטיינרים ועוד.

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

על דיסקים מכניים גדולים ו-RAID

מי שעוקב אחרי חדשות טכנולוגיות יכול למצוא אחת לכמה חודשים הכרזות של יצרני דיסקים שונים על דיסקים חדשים, לפעמים על שיטת קריאה/כתיבה חדשה. כך לדוגמא, חברת Showa Denko K. K. הכריזה כי היא סיימה לפתח ראש MAMR חדש לדיסקים קשיחים עבור חברת טושיבה, וטושיבה תוציא דיסקים קשיחים בגודל 18 טרה המבוססים על טכנולוגיה זו במשך השנה. צפו להכרזות דומות מצד שאר היצרנים.

כיום, בין אם יש לך שרת שאתה מכניס בו דיסקים קשיחים ומחבר אותו לבקר RAID כלשהו, ובין אם יש לך סטורג' קנייני – כל היצרנים ישמחו למכור לך דיסקים קשיחים גדולים – בין אם ישירות מיבואן יצרן הדיסקים ובין אם דרך החברה שרכשת ממנה את השרת או הסטורג'. רוצה מדף עם 12 דיסקים של 10 טרהבייט? בשמחה! תחתום פה ופה, תעביר כרטיס אשראי או תשלח צ'ק וטכנאי בדרך אליך להתקין את המדף לסטורג' ולהגדיר אותו. אין צורך לדאוג, גם הדיסקים הגדולים שנמכרים כיום נמכרים עם SAS Dual Port לחבר ל-2 כרטיסי RAID (אם אתה רוצה להכניס את זה לשרת, בסטורג' זה אוטומטי).

אבל האם זה שווה לרכוש את הדיסקים הללו? בכל זאת, אם קנינו מדף של 12 דיסקים בגודל 10 טרה, אנחנו נקבל ברוטו 120 טרהבייט, זה שקט להרבה זמן מבחינת אחסון פנוי!

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

לשם פוסט זה, נניח ויש לנו את ה-12 דיסקים של 10 טרה, והם מורכבים בסטורג' או בשרת עצמאי עם 2 בקרי RAID (או אחד, זה לא ממש משנה מבחינת מהירות קבלת נתונים, ה-Dual Port ב-SAS הוא יותר לשרידות, אם כי במצב שהולך לך בקר, אני הייתי ממליץ לך להשבית את השרת עד שיגיע טכנאי עם חלק חלופי. אתה לא רוצה לסכן את ה-DATA שלך!). נניח שהגדרנו RAID, נניח 5 או 6 (במצב של 1 זה הרבה יותר מסוכן) או כל "RAID" בסטורג'.

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

וכאן… מתחילות הבעיות והסיכונים צצים…

  • אם הדיסקים נמצאים בשרת והם מחוברים לבקר RAID (וזה לא חשוב איזה RAID הגדרתם, למעט כמובן 0 שאז הלך ה-DATA) – השחזור לא רק שיהיה איטי ויקח מספר ימים, אלא שאתם תסבלו מביצועים נמוכים מאוד באותם ימים הואיל וכל מערך ה-RAID צריך לעבוד בעצם כפול: גם לשרת את הצרכים שלכם, וגם לקרוא מהחלקים השונים של הדיסקים על מנת לכתוב את ה-DATA מחדש על הדיסק החלופי.
  • מכיוון שאתם מאמצים את המערכת – יש סיכוי שדיסק נוסף יפסיק לעבוד, הואיל והמערכת עובדת נון סטופ.
  • במקרים של שרת ו-RAID מבוסס בקר חומרה, הכתיבה היא "הכל" – גם אם היה לכם ב-RAID חומר בגודל 10 ג'יגהבייט, הוא יבצע Rebuild של 10 טרהבייט, מכיוון שבקר RAID הוא דבר די טיפש.
  • במקרים של סטורג' (או Software defined Storage) – שיטת ה-Rebuild תהיה שונה, וכמות ה-DATA שתיכתב על הדיסק תהיה כמו שאר הדיסקים באותו "RAID", כך אם יש חומר של 10 ג'יגה, יכתב 10 ג'יגה. ההבדל הגדול בין סטורג' לבין שרת עם בקר RAID חומרה – זה שהסטורג' יודע "להסתיר" את האיטיות עם דיסקים SSD, עם Flash Cache וטריקים אחרים, אבל עדיין – תורגש איטיות.

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

  • חברו את הדיסקים ל-HBA ולא לבקר RAID (אפשר לרכוש בקרי LSI עם IT MODE או להחליף להם קושחה).
  • השתמשו בתוכנה כדי לבצע RAID. יש הרבה פתרונות – החל מ-FreeNAS, ZFS, XPEnology, או Storage Spaces של מיקרוסופט. הכל תלוי בהעדפה שלכם.
  • השתמשו ב-SSD שהוא Mixed Intensed או SSD שמתאים ל-Enterprise אם המהירות חשובה לכם. ההמלצה שלי היא ללכת על Optane 900P או DC P4800X (אם יש לכם את התקציב) של אינטל על מנת לקבל Latency מאוד נמוך וביצועים גבוהים מאוד (שימו לב – אם השרת אינו חדש, אז ה-Optane לא יוכל לבצע Boot ואם בשרת אין תושבות PCIe 3.0 – אז הוא לא יעבוד).
  • אם אתם משתמשים ב-ZFS, אל תשכחו להגדיר תהליך "קרצוף" (scrub) של הדיסקים לפחות אחת לשבוע (התהליך עובר על כל ה-DATA והיכן שהוא מוצע בעיות, הוא משכתב את ה-DATA למקום פנוי אחר, כך שהעבודה תהיה חלקה).
  • גיבויים, גיבויים, גיבויים – תוכנות גיבוי זה טוב, אבל snapshots ברמת האחסון הם יותר טובים והשחזור הרבה יותר מהיר. דאגו שתהיה מכונה אחרת עם מקום פנוי לקבל את ה-Snapshots.

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

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

הסברים והבהרות לגבי Scale Out בתחום אחסון

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

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

אך מהו בעצם פתרון Scale Out?

חברות אחסון רבות לקחו את המושג "Scale Out" לכיוון שהם רוצים. יש חברות שמייצרות HCI (כלומר Hyper Converged) שלקחו את המושג Scale Out לכיוון הוספת שרתים שיתנו לך יותר משאבי מחשוב/רשת/אחסון. חברות אחרות לוקחות את זה לכיוון שאם אתה מרים ערימת שרתים, אתה מתקין VM בכל אחד מהם שמחובר לדיסקים המקומיים בכל שרת וישנה תוכנה שמתחברת לכולם ובכך נוצר Storage (אין Networking גודל בכל מכונה והמכונה לאו דווקא מריצה מכונות VM אחרות) ויש כמובן את ה-Scale Out שעליו דיברתי בפוסט הקודם – ערימת שרתים מלאים דיסקים שלא מריצים מכונות VM או Payload משלך אלא תוכנה יעודית של יצרן הפתרון בלבד.

לעומת פתרון Scale Out – יש פתרון ותיק שנקרא Scale Up, שבו יש פתרון שמורכב ממערכת אחת (או 2 לשרידות) ודרך הגדלת האחסון היא הוספת דיסקים מכניים (או SSD אם רוצים יותר IOPS), אך כמות הברזלים נשארת זהה.

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

לא כל פתרון Scale Out מתאים לכל הסיטואציות. בתחום HCI לדוגמא, אתה יכול להוסיף עוד כמה טרהבייט בחישוב הכולל בכך שתוסיף עוד כמה דיסקים (מכניים/SSD) פר מכונה ובכך תקבל יותר אחסון ויותר IOPS, אבל פתרון כזה אינו מתאים אם לדוגמא אתה צריך מאות טרהבייטים עד פטהבייטים (ומעלה) של אחסון ואין לך צורך בהרבה מקום נוסף למכונות VM. בסיטואציה כזו אתה חייב פתרון אחסון Scale Out שידע לעמוד בשרידות של שרת אחד או 2 שנופלים ולא פתרון Scale Up (למרות שרוב פתרונות ה-Scale Up מתהדרים בכך שהם יכולים לגדול לפטהבייטים).

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

  • אם מדובר במערכת HCI שתהווה אלטרנטיבה ל-VSAN/Simplivity/Nutanix – אז יש את GlusterFS והוא מגיע יחד עם RHV.
  • אם מדובר במערכת Scale Out שלא הולכת לגדול מעבר למספר קטן של שרתים (כמה עשרות) – ניתן לרכוש את GlusterFS בנפרד.
  • אם צריכים מערכת אחסון שתורכב מעשרות שרתים ואחסון בגדלים של מאות טרהבייט ומעלה, או שתריץ מערכת ענן פרטי כמו OpenStack בחברה – מערכת SES של SuSE או Red Hat Ceph Storage יתנו לכם מערכת מבוססת CEPH שבנויה לדברים הללו (הפתרון של SuSE בארץ זול משמעותית בהשוואה למחיר שרד-האט מבקשים, ויש את אותה פונקציונאליות בשתיהן).
  • גם Ceph וגם GlusterFS מתאימות אם אתם הולכים להריץ קונטיינרים/Kubernetes/OpenShift על הברזלים.

לסיכום: פתרון Scale Out טוב (שאינו מבוסס HCI) הוא פתרון שנותן:

  • להגדיל את כמות האחסון למימדים גדולים (מאות טרהבייט ומעלה)
  • שרידות הרבה יותר גבוהה מפתרון Scale Up (מערכת ששורדת גם כששרת אחד או יותר המאחסנים את הפתרון נופלים)
  • תמיכה בסטנדרטים אחרונים (Object Storage, Persistent Volume, ,Cinder וכו')

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

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

כל מי שעובד ב-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.

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

תכירו: Red Hat Storage One

חברת Red Hat הכריזה אתמול על פתרון חדש לסטורג' לחברות שנקרא Red Hat Storage One. הפתרון עצמו הוא די פשוט: אתה קובע פרמטרים מסויימים, אנחנו אומרים לך איזו מערכת יכולה לתת לך את מה שאתה רוצה ומוכרים לך אותה אין צורך ברכישת רשיונות נוספים. אתה רוכש בעצם מחברת Red Hat – ברזל מוכן. הקץ להתקנות ו-1001 קונפיגורציות וכך זה נראה (לחצו להגדלה):

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

אז רד-האט מוציאים את Red Hat Storage One כפתרון סטורג'. זהו הפתרון הראשון ובהמשך יהיו פתרונות נוספים שלא מבוססים על GlusterFS אלא גם על Ceph, וכאן בד"כ נמצאת הבעיה בד"כ – לדעת את ההבדלים בין GlusterFS ל-Ceph ומה מתאים למה (ולא, הם לא מתאימים לכל הצרכים).

בוא נסתכל לשם הדוגמא בכל סטורג' קנייני בינוני. סביר להניח שאותו פתרון סטורג' יתן לך את כל מה שתרצה. רוצה להקים LUN ל-iSCSI? אהלן. שיתוף קבצים? שלם רשיון ויש לך CIFS. רוצה NFS? שוב, רשיון – ויש לך את זה. רוצה snapshots? אולי clones? זה בפנים. רוצה לגבות את הסטורג'? תצטרך תוכנה יעודית – אבל זה אפשרי. רוצה Cluster לסטורג'? זה אפשרי, תכין צ'ק שמן :).

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

  • גישת קבצים – CIFS או NFS – מערכת GlusterFS בנויה כולה על גישת קבצים ואת זה היא יודעת לעשות בצורה מהירה (במיוחד אם הכנסת כרטיס PCIe ל-Nodes עם 3DXpoint של אינטל). צריך Cluster של CIFS או NFS שגם יכול לגדול? GlusterFS הוא הפתרון. אם תנסו את Ceph ל-CIFS או NFS, תקבל בערך 50% פחות בביצועים מהסיבה הפשוטה ש-Ceph עובד מבפנים על Object Store וכך הוא מאחסן הכל, כך שכל גישה לקובץ מצריכה מהמערכת "להרכיב" את הקובץ מאובייקטים ולהגיש אותו, ולפני כן על ה-Client לברר דרך אחד משרתי ה-MDS איפה בכלל הקובץ נמצא, איזה Node זמין וכו', כך שאם אנחנו צריכים להעתיק 1000 קבצים – עשו את זה לקראת היציאה מהעבודה באותו יום, זה יקח זמן.
  • Block Storage. בסטורג' קנייני עניין ה-iSCSI ו-LUN מבוצע בד"כ ברמת חומרה + שימוש ב-NVRAM, כך שהביצועים מאוד גבוהים. ב-GlusterFS זה אפשרי, אבל הביצועים לא יהיו גבוהים כי המערכת לא מכוונת לעשות את זה (אבל למי שמתעקש – זה אפשרי אך עדיין תצטרך באמצע מכונה "מתווכת"). ב-Ceph לעומת זאת גישת Block Storage היא אפשרית בהחלט וזה עובד מעולה, במיוחד אם משתמשים במערכת OpenStack למכונות וירטואליות וקונטיינרים (או Swift). מצד שני יש תמיכה ב-iSCSI אבל שוב, יש צורך ש-2 מכונות (בשביל HA) שיבצעו המרה מ-Raw Block Device ל-iSCSI החוצה.
  • סטורג' לקונטיינרים או Object Store – כאן Ceph מנצח מבלי להתאמץ אפילו. הבסיס העיקרי של Ceph לכל הקבצים הם אחסון אובייקטים, כך שאם החברה רוצה להקים אחסון מדמה S3 כחלק מפתרון ל-OpenStack – אז Ceph נותן פתרון מעולה. גם כאן ל-GlusterFS יש פתרון אבל אם רוצים משהו גדול או ענק לאחסן מיליוני אובייקטים – Ceph עדיף.
  • פתרון Hyper Converge המשלב את הסטורג' יחד עם מכונות וירטואליות. כאן התשובה פשוטה: GlusterFS. מערכות Ceph צריכות להיות מוקמות על שרתים פיזיים נפרדים (שזה מה שהם יעשו בלבד) ו-Ceph אינו פתרון Hyper Converge (וכן, בדקתי, זה הזכיר לי את מהירות טעינות משחקים מקלטות בקומודור 64…).

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

כמה מילים על פתרון סטורג' (קוד פתוח) משולב

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

הבעיה בד"כ היא במחשבה או בתכנון מעבר. אם לדוגמא יש לכם פתרון וירטואליזציה של VMWare ותרצו ליישם את VSAN, ההשקעה תהיה גבוהה. על כל שרת ממוצע תצטרכו לשלם 5000$ וזה עוד לפני הדיסקים והתצורה היחודית שיש צורך ב-VSAN (על כל 2 דיסקים מכניים או SSD בינוניים, דיסק SSD מהיר או Mixed Intense או ביחד). במקרים אחרים יש פתרונות HyperConverged כמו Nutanix, Simplivity וכו' שבסופו של דבר מחייבות אותך לרכוש כמעט הכל מחדש (אם כי כמובן אפשר במקרים מסויימים להשמיש שרתים שונים, תלוי מה ה"גיל" שלהם).

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

גם במקרים של פתרון קוד סגור או קוד פתוח, נצטרך דבר ראשון להעיף מבט על השרתים שיש לנו. רוב השרתים שמריצים פתרון וירטואליזציה כלשהי, אנחנו נראה שרוב התושבות בשרתים – פנויים (וכמובן שיצרני השרתים מנצלים זאת על מנת לתת פתרון Backplane חלקי, כך שגם אם תרצה למלא 24 דיסקים 2.5" בשרת, לא תוכל אלא אם תרכוש עוד 2 backplanes עם החיבורים. בד"כ ה-backplane שאתה מקבל בשרת יכול לחבר מקסימום 8 דיסקים), כלומר שמבחינת השקעה בברזלים אם נרצה פתרון סטורג' מבוזר, נצטרך לרכוש פתרונות backplane לשרתים, וכמובן דיסקים מכניים, SSD (מסוגים שונים – read intense או mixed Intese – תלוי בתקציב ובמה שאתם רוצים לעשות). נקודה נוספת שנצטרך לקחת בחשבון זו הרחבת זכרון. אין צורך "להשתולל", בד"כ לפתרון SDS נצטרך 16 או 32 ג'יגהבייט זכרון. הנקודה האחרונה שיכולה להיות קצת יקרה היא רשת – אנחנו נצטרך בכל מכונה חיבור של 10 ג'יגהביט לתקשורת פנימית בין ה-VM שמריצים את פתרון ה-SDS.

את פתרון ה-SDS נריץ כ-VM בתוך כל מכונה, אולם אנחנו צריכים קודם כל להחליט איפה בעצם לאכסן את הנתונים, באלו דיסקים. דיסקים בגודל 2.5" לדוגמא יהיו קצת בעייתיים כי כמות ה-DATA שאפשר לאכסן בהם היא לא גדולה אך המחיר הוא די גבוה. אם לדוגמא נדמיין שאנחנו מכניסים 20 דיסקים של 1 טרה בגודל 2.5", ועוד 2 דיסקים SSD שישמשו כ-Cache, אז נקבל "ברוטו" 20 ג'יגהבייט. אולם אם נחליף את הפאנל הקדמי (כולל הלוח המוצמד) לגירסת LFF (כלומר Large Form Factor), אז נוכל להכניס 12 דיסקים של 4 טרהבייט, אז נקבל "ברוטו" 48 טרהבייט ומחירי הדיסקים הללו יהיו יותר זולים מ-20 דיסקים של 2.5" (בד"כ נוכל להכניס 2 דיסקים SSD ל-Cache מאחורי השרת). מבחינת הוירטואליזיציה, אין לנו צורך להתקין אותה (בגירסת vSphere) על הדיסקים המקומיים, 2 כרטיסוני מיקרו SD יוכלו לעשות את העבודה. (בין כה כמות הכתיבה אליהן מאוד קטנה ואם כרטיס נופל, כרטיס שני "לוקח פיקוד") כך שאנחנו יכולים בסופו של דבר להצמיד את כרטיס ה-RAID ל-VM עצמו ולקבל מקסימום ביצועים.

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

כעת, כל מה שנותן לעשות זה לחבר את הדברים. בכל מכונה נקים VM עם הפצת לינוקס כלשהי (GlusterFS קיים לכל הפצת לינוקס שתרצו), להגדיר אם אנחנו מעוניינים בשכפול והפצת קבצים (אפשר לראות את האפשרויות כאן, פוסט מורחב על הנושא יהיה בקרוב) ומאותו פתרון SDS נוכל להגדיר שיתופים איך שנרצה: CIFS, NFS, iSCSI ועוד. כך נוכל להנות גם מפתרון SDS יציב, שיכול לעמוד במצב ששרת או 2 נופלים (תלוי איך הוגדר GlusterFS, בד"כ הגדרות ברירת מחדל יתנו HA כך שאם מכונה נופלת, השניה לוקחת פיקוד), גם נוכל להרחיב את הפתרון בהמשך (הוספת דיסקים, JBOD, מכונות נוספות) והכי חשוב – נוכל להנות מפתרון שנותן גם ביצועים מהירים וגם התחזוקה עצמה תהיה די מינימלית.

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

נקודות למחשבה בעת קניית סטורג' – חלק שני

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

בעסק קטן עם נניח 1-2 שרתים ועוד כמה Share ל-Windows, המחשבות וההתלבטויות לגבי קניית פתרון אחסון הם אינן גדולות. קונים NAS טוב, דיסקים, מגדירים את הכל ומתחילים לעבוד. בד"כ הפרמטרים הכי חשובים שם זה מהירות מספקת לצרכי עבודה ומחיר טוב. בד"כ פתרון NAS טוב נותן את הדברים שהעסק שצריך החל מ-CIFS, iSCSI, שרידות מינימלית וזהו.

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

נתחיל ברמה הכללית בכמה נקודות (ותודה לעומר שציין מס' נקודות בפייסבוק):

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

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

  • DeDuplication (או DeDup בקיצור): כשאנחנו משתמשים בוירטואליזציה, אנחנו מקימים מכונות VM רבים שיש בהם את אותה מערכת הפעלה ואותם קבצים. פונקציונאליות ה-DeDup מזהה חלקים זהים והיא "רושמת לעצמה" היכן נמצאים החלקים הזהים (ברמת Block או קבצים) אך היא שומרת עותק יחיד (במקרים מסויימים 2 עותקים) של אותם אזורים זהים, ובכך המערכת חוסכת מקום בסטורג'. ככל שיש יותר חלקים זהים, המערכת חוסכת יותר מקום.
  • Compression (דחיסה): פונקציואנליות נוספת "שכנה" של DeDup היא הדחיסה. יצרניות סטורג' שונות מאפשרות להקים Policy (שוב, ברמת בלוק או קבצים) המאפשרת דחיסה של נתונים שונים ופריסתם ברגע שצריך את הנתונים (הדחיסה והפריסה הם "שקופים").
  • Thin Provisioning: כשיש צורך בהקמת LUN (או משאב אחר הקשור בהקצאת שטח אחסון לטובת פרוייקט כלשהו) יש באפשרותנו להקצות חלק משטח האחסון ב-2 שיטות עיקריות: Thick Provisioning ו-Thin Provisioning. ב-Thick כל השטח המתבקש מוקצה מיידית לטובת אותו LUN לדוגמא ואילו ב-Thin יש רק "הכרזה" במערכת כי LUN X יקבל כך וכך שטח אך במציאות הוא מקבל מעט מקום ובכל פעם שיש צורך בעוד מקום, אותו LUN יקבל את מבוקשו עד גובה ההכרזה הראשונית. היתרון ב-Thin Provisioning הוא שאין צורך מיד "לכסח" חלק גדול ממקום האחסון אך החסרון הוא שכל בקשה לוקחת מעט יותר זמן (דבר שיכול להיות קריטי למערכות כבדות כמו שרת SQL וכו'). היתרון ב-Thick הוא בכך שיש את השטח לאפליקציה זמין כל הזמן והגישה היא יותר מהירה.
  • Snapshots: כל חברה נורמלית דואגת לגיבוי יומי של כל הנתונים בשרתים ובסטורג', אך הבעיה עם גיבוי ושחזור – זה ששחזור לוקח זמן. לעומת זאת, Snapshot מייצר "צילום" עכשוי של אחסון ספציפי (LUN או משאבים אחרים לדוגמא) וכך אם לדוגמא אנחנו משדרגים מערכת שמשתמשת ישירות בסטורג' ואיננו מרוצים מהתוצאה, אנחנו יכולים "לקפוץ אחורה" אל ה-Snapshot במקום לשחזר מהגיבוי, ופעולת החזרה אל ה-Snapshot היא מאוד מהירה.
  • Disaster Recovery: נשרף הראש, קרתה תקלה באחד הבקרים – מהי הדרך לשחזר, האם קיימת כזו, מה הזמן שלוקח לשחזר?
  • Tiering – עם Tiering פתרון האחסון עובד ב"שכבות" והוא מעביר קבצים לפי השימוש שלהם, כלומר אם יש לנו קבצים שיש בהם צורך מדי יום, הוא יאחסן אותם בדיסקים הכי מהירים שיש במערכת ואילו קובץ שקוראים אותו אולי פעם בכמה חודשים – עובר להישמר באחסון הכי איטי שיש (דיסקים SATA), ובכך המערכת מגיבה הרבה יותר מהר כי הקבצים שיש בהם צורך תכוף נמצאים בדיסקים הכי מהירים שיש.
  • IOPS – המושג שמשתמשים בו הכי הרבה בתחום הזה. כמה IOPS הסטורג' נותן בכתיבה ובקריאה? אל תתפתו להאמין לנתוני שיווק! דרשו מסמך התחייבות לכמה IOPS הפתרון נותן ומתי.

נקודות חשובות נוספות שכדאי לבדוק:

  • כמות תושבות PCIe: לפעמים יש צורך להכניס עוד כרטיסים לסטורג', כמו להוסיף כרטיסי תקשורת וכו'. כמה מקומות יש, אם בכלל?
  • כמות דיסקים וסוג: כל סטורג' יכול להכיל כמות מסויימת של דיסקים ולא מעבר לכך, ולכן חשוב לדעת מהי המגבלה, וכמו כן אלו דיסקים מתקבלים: SAS, NL-SAS, NVME, FC, SATA…
  • מעבדים מסייעים: בכל סטורג' היום נמצא מעבד Xeon כלשהו, והשאלה החשובה היא האם קיימים מעבדים מסייעים לעבודות שונות, כמו Block Storage Processor שלוקח עליו את העבודה בכל הקשור ל-Block Storage. קיומם של מעבדים כאלו במערכת מסייע מאוד בעבודה מהירה.
  • עדכונים ועדכוני אבטחה: בכל סטורג' חדש תקבלו עדכונים בשנתיים שלוש הראשונות כולל עדכוני אבטחה. השאלה החשובה היא מה קורה לאחר התקופה הזו. האם היצרן מתחייב לפרסם עדכוני אבטחה גם לאחר שלוש שנים? אם כן, לכמה זמן?
  • המשכיות: קניתם פתרון סטורג' מהיצרן ולאחר 3-4 שנים החלטתם לשדרג לדגם אחר – האם אפשר להשתמש בציודים הקיימים (מדפים ודיסקים) בציוד העתידי או שצריך הכל מחדש?
  • הדרכה/שרות/SLA: האם יש הדרכה רשמית שמדריך מגיע לחברה ומלמד את צוות ה-IT או שזורקים עליכם כמה קבצי PDF ותסתדרו? וכשזה מגיע לשרות – מה ה-SLA? זיכרו: במקרים רבים, כש-SLA לא מצוין, מדובר על יום העסקים הבא (NBD), וזה קורה במיוחד כשמוכרים לעסקים קטנים, קחו את זה בחשבון.

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