קצת על Scale Out עם פלטפורמות יעודיות

בשנים האחרונות אנחנו עדים ליותר ויותר פלטפורמות שעובדות בשיטות של Scale Out. הפלטפורמה הכי ידועה לדברים כאלו היא כמובן Kubernetes, אך כמובן שישנן פלטפורמות אחרות שקשורות יותר לעיבוד נתונים – Kafka או Cassandra לדוגמא, כל אחת מהן פלטפורמה לצרכים שונים, אבל מבחינת צרכי חומרה, הצרכים הם פחות או יותר זהים: מעבדים בינוניים (לא צריך כמות מפוצצת של ליבות, יספיקו 8-16), ולא צריך דיסקים (קשיחים או SSD) יקרים.

כלומר – אם אתה צריך להריץ פלטפורמה שעובדת ב-Scale Out מקומית בתשתית שלך, אל תנסה לחפש את היוקרתי עם כל מילות הבאז האחרונות, אלא ההיפך – מי הספק שיכול לתת לך את ההצעה הכי זולה שתעמוד במפרט שנקבע מראש, SLA שאתה צריך וכו'. ב-Scale Out אין את מושגי השרידות מעולם ה-Scale Up. אין Heart beat, אין Active/Passive, Active/Active וכו'. עם Scale Out בדרך כלל הפלטפורמה תהיה בנויה כך שאם שרת למטה/אינו זמין/אינו פעיל, המערכת תאזן את עצמה אוטומטית (למי שמשתמש ב-Kubernetes ורוצה לראות זאת – תורידו Node ותראו איך זה עובד).

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

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

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

ולכן:

  • אם הולכים להשתמש בפלטפורמה שהיא בראש ובראשונה Scale Out לצרכי עיבוד נתונים/קליטת נתונים – נצטרך דיסקים ושרת מהקצה הנמוך-בינוני, מבלי להשקיע יותר מדי כספים פר ברזל (קחו דיסקים בסיסיים, בפוסט קרוב אסביר לגבי הגדרות אחסון מקומי למערכות כמו Kafka ו-Cassandra), (אגב, אם אתם רוצים להריץ Kafka בענן, אמזון לדוגמא שמחה להציע לכם את MSK).
  • אם אנחנו רוצים לשמור כמות גדולה מאוד של מידע לאחר עיבוד או ארכיבאי כשהכמות גודלת כל הזמן, או שאנחנו צריכים Object Storage – פתרון אחסון Scale Out (כמו Gluster) יתאים יותר לשימושים הללו מכיוון שעלות הגדילה היא זולה, והביצועים גודלים ככל שמוסיפים ברזלים לאותו אחסון.

לסיכום: בעולם ה-Enterprise, הסטורג' הקנייני היה ה-דבר הכי חשוב וקריטי. אין סטורג', שום דבר לא פועל. מאז הגיעו ספקי הענן הציבורי הגדולים שהכריזו שאצלם אין ולא יהיה שום סטורג' מרכזי, ובמקביל התפתחו יותר ויותר פלטפורמות שמחזירות את השימוש בדיסקים מקומיים ומאפשרות לבנות אחסון מדיסקים זולים וממשאבים צנועים, וזהו בדיוק החלק שבמחלקות ה-IT או ה-CIO/CTO צריכים להבין: אל תנסו לכפות פתרון Scale Up על פתרון Scale Out.

אחסון: כמה שווה השקט שלכם?

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

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

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

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

  • 2-3 שיחות טלפון לשאול שאלות תמיכה
  • 1-2 דיסקים תקולים להחליף.

וזהו.. (כל הדברים הם כמובן בממוצע).

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

ואז מגיעה השאלה הקשה: לבלוע את הגלולה ולשלם על הארכת האחריות או להתחיל לחפש סטורג' אחר?

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

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

  • הציוד שמתקלקל בדרך כלל בסטורג' הוא – דיסקים, בין אם מכניים או SSD, ולכן אני ממליץ לרכושחומרה-כמה-שווה-השקט-שלכם מהיצרן (או מחברות צד ג' כמו אולטרייד ואחרים) 2-3 דיסקים מכניים ו-SSD, מה שיש לכם בסטורג' – שישבו בארון. זו התקלה הכי שכיחה בסטורג' ובמקרה וילך לכם דיסק, יקח כמה דקות לטפל בתקלה בלי לשלם לאף אחד.
  • חפשו חברות צד ג' שנותנות שרות לסטורג' שלכם. אני חושב ש-We Ankor מספקת אבל אני לא בטוח לאיזה ציוד היא מספקת שרות ואם היא מספקת שרות כשלציוד תמה האחריות. אתם מוזמנים לשאול בפורומים בפייסבוק, חברים וכו' (לי אין קשר ישיר, אבל אם יש חברות שמוכרות שרותי תחזוקה/תמיכה לציודים כאלו – שלחו לי מייל, בהזדמנות אפרסם או אפנה אליכם אם יתקבלו פניות). מכיוון שאתם לא הולכים להשבית את הסטורג' שלכם מחר בבוקר, דברו עם צד ג' על אחריות לשנה פלוס.
  • תתחילו להוציא "קול קורא"/מכרז לרכישת סטורג' בין החברות השונות. הנה פוסט שכתבתי לפני זמן קצר על נקודות עקרוניות וכמובן אל תשכחו את עניין ה-IOPS.
  • סטורג' מבוסס מוצר קוד פתוח? בניגוד למה שהרבה חושבים, אין שום קשר בין אם החברה משתמשת במוצרי קוד פתוח לבין שימוש בסטורג' מבוסס קוד פתוח (אגב, כשאתם עושים קניות ומשלמים ב-PayPal לדוגמא – רוב התשתית שדרכה עוברים פרטיכם – היא בקוד פתוח). כשאני ממליץ על פתרון כזה, אני ממליץ על פתרון שיש לו "אבא ואמא" מצד החברה המוכרת ונותנת תמיכה כמו SuSE ישראל, כך שיש תמיכה מסביב לשעון אם יש בעיה, בדיוק כמו בסטורג' קנייני. ההבדלים הגדולים: מחיר הרבה יותר זול וחופש לבחור על איזה ציוד זה ירוץ. אני לא אתקין ללקוח לדוגמא מערכת Ceph שמשכתי מ-GitHub (למעט אם זה PoC וגם אז, בדרך כלל אני אתקין גירסת Trial מסחרית). אגב, בקרוב אעלה וידאו הדגמה של המוצר.
  • לא חשוב איזה סטורג' קנייני תרצו לרכוש – אם אתם רוצים IOPS גבוה, שרידות רצינית וכמות אחסון גבוהה (50 טרה ומעלה נטו) – המחיר הולך להיות גבוה, במקרים רבים יותר ממה שאתם חושבים בהתחלה. במקרים שאתם מקבלים הצעות מחיר והם מאוד רחוקים מהתקציב שחשבתם להשקיע – יהיה כדאי לחשוב על "Offload" של הדברים, כך שרק הדברים שחייבים מצב "פרודקשן" ישבו על הסטורג' החדש והשאר ירוץ על הסטורג' הישן או להקים סטורג' מבוסס קוד פתוח כסטורג' משני או שלישוני. כל סטורג' רציני שעולה עשרות אלפי דולרים ניתן להרחבה גם ל-100 טרה ומעלה בלי בעיה.
  • בקשו הצעות מחיר שכוללות 5 שנות אחריות או 7 שנים (כמדומני שכל הגדולים מציעים גם 7 שנים) מראש. כמו שציינתי, רכישת הארכת אחריות בנפרד היא דבר מאוד יקר ואת המחיר הזול אפשר להשיג בעת הרכישה, לא לאחר מכן.

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

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

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

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

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

אחד הדברים המעניינים שניתן לראות קשור לגודל החברה המעוניינת בפתרון: ככל שהחברה יותר גדולה והיא יותר "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…).

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