אחסון – הבלוג של חץ ביז

רעיון קטנטן ליצרני פתרונות אחסון

במדינתנו הנחמדה, לא חסרות חברות המפתחות פתרונות אחסון כמעט לכל דבר – מגיבוי ועד Cloud Native, עם תמיכה בכל הפרוטוקולים הידועים, ועם ביצועים מאוד מרשימים. אם אינכם מכירים את שמות החברות, הנה מדגם קטן: Lightbits, Kaminario, Infinidat ויש עוד כמה וכמה, רובן חברות ישראליות או חברות בינלאומיות עם מו"פ בארץ.

אחד הדברים היותר מעניינים שיצא לי לראות בשנים האחרונות – זה המרחק הענק בין מה שחברות אלו מייצרות ומה שמוצריהם נותנים מבחינת שרידות, מהירות העברת נתונים וכו' – לבין מה שחברות רבות בארץ רוכשות לעצמן כשהן מחפשות סטורג'. כיום, ב-2022, יש עדיין לא מעט חברות שרוכשות אחסון המבוסס על דיסקים מכניים עם SSD שמשמש כ-Cache, ואלו היותר מתקדמים – רוכשים דיסקים SSD שמהירות הכתיבה שלהם איטית (Read Intensive) ועם עוד SSD או 2 הכוללים Flash מסוג SLC או MLC לצורך כתיבה מהירה. את אותם פתרונות אחסון מחברים לשרתים המריצים vSphere עם חיבורים של 10 ג'יגהביט חיבור נחושת או +SFP (עם DAC או סיב), או שעדיין משתמשים בחיבורים הישנים בסיבים במהירות עד 16 ג'יגהביט.

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

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

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

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

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

כשאני מדבר על "ברזל זמני", אני חושב שכל יצרן אחסון יכול בעצם לבנות שרת 2U פשוט, עם מעבד EPYC (בשביל כל ה-PCIe Lanes ל-SSD ולציוד הנוסף) וכמות קטנה יחסית של אחסון נטו (נאמר: 4 טרהבייט) עם הציוד המינימלי שצריך כדי לתת ביצועים די טובים (לא צריך להשקיע יותר מדי כמו הוספה של סוויצ', אפשר להשתמש בחיבורי JBOF חיצוניים לדוגמא). שרת כזה ניתן להשאלה לארגון מתעניין ל-30 יום כדי שיחברו ו"ישחקו" איתו – יאחסנו נתונים, יבדקו ביצועים, ויראו איך פתרון כזה יכול להשתלב בחברה.

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

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

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

מוגש כחומר למחשבה.

קצת פרטים לגבי DCPMM של אינטל

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

בשנים האחרונות אינטל הוציאה את מקלות ה-DCPMM (ר"ת DC Persistent Memory Module). אלו מקלות אחסון שאינם משתמשים ב-NAND כמו אחסון SSD אחר, אלא 3D Xpoint, שיטה חדשה שמאפשרת כתיבה וקריאה במהירות מאוד גבוהה ושרידות (מבחינת DWPD לדוגמא) גבוהה בהרבה, בהשוואה לפתרונות Flash אחרים שקיימים בשוק. אינטל הוציאה גם פתרונות אחסון קונבנציונאליים מבוססי 3D Xpoint (תחת השם Optane, למרות שתחת השם הזה הם הכניסו עוד סוגים שונים של אחסון, למה לא לבלבל את הלקוח הפוטנציאלי!) אך ה-DCPMM היה שונה בכך שהוא הרבה יותר מהיר והוא משובץ בתושבות הזכרון בשרת, וכתוצאה מכך, שימוש ב-DCPMM יחד עם זכרון RDIMM יכול לתת פתרון די טוב לזכרון בכמות גבוהה, במחיר יותר נמוך בהשוואה לכמות זהה של זכרון אם כולו היה מבוסס DRAM RDIMM.

בוידאו הבא אסביר קצת לגבי דברים כמו:

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

להלן הקליפ.

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

כאן יש מסמך חשוב מאוד מחברת לנובו המשווה את ביצועי המערכת אם משתמשים רק בזכרון, או שילוב של יותר זכרון ומעט DCPMM, וההיפך, וכמו כן הוא נותן דוגמאות לגבי יחסים RDIMM עם DCPMM מצוותים. מומלץ לקרוא.
הפתרון אינו קיים למערכות שאינן מבוססות אינטל (כמו AMD) הואיל ומדובר בפתרון סגור וקנייני של אינטל.
לא מומלץ להשתמש במצבי אחסון Block Storage כשמשתפים מקלות DCPMM משני מעבדים שונים (או יותר, במקרה ומשתמשים במעבדי ה-Cooper Lake) אלא אם יש לכם מעבדים מסידרה L או מעבדי GOLD, אחרת נוצר צוואר בקבוק שקשה לשחרר.
ולחבריי הגיקים שצופים בערוץ היוטיוב של ServeTheHome – אכן ראיתי את הקליפ של פטריק אתמול, וזה הזכיר לי שעל הנושא לא הוצאתי כמעט כלום, אז בגלל זה החלטתי לבצע "השלמות" 🙂

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אחסון רגיל מול vSAN, Nutanix ופקטורים אחרים

לפני כמה ימים יצא לי לשוחח עם מישהו שפנה אליי מהבלוג לגבי פרויקט שהם מתכננים. מטבע הדברים אינני יכול לפרט, אבל משהו אחד שאני כן יכול לאמר (באישור שלו) – זה שהם מתכננים רשת ממש "אכזרית". כמה "אכזרית"? יש לא מעט ארגונים (בנק הפועלים לדוגמא, לפי פרסום שלהם) שמשתמשים ב-100 ג'יגהביט רשת ל-Backend, פה מדובר על 100 ג'יגהביט פר שרת. מכיוון שלא סגרנו חוזה ודיברנו על כרטיסים, הזכרתי בשיחה כרטיס מסוג CONNECTX-5 EN ADAP שיכול לעמוד יפה במשימה, אך המלצתי לו שבשביל השרידות, הוא יצטרך 2 כרטיסים כאלו וכאן הכל קשור ל-Fear Factor.

מה הכוונה? אם הלקוח רוצה לרכוש את הכרטיס הנ"ל ישירות מהיצרן, אז הוא ישלם 795$. לעומת זאת, אם הוא ירכוש זאת דרך יצרן השרתים שהוא משתמש (HPE) – הוא ישלם על אותו כרטיס בדיוק – 1600-2100$, וכאן בעצם נכנס ה-Fear Factor: ככל שחברה יותר גדולה, מפעילים יותר "ראש קטן" וקונים מיצרן השרתים בגלל Fear Factor וחשש שמא, אולי, יצרן השרתים לא יתן תמיכה, גם אם המחיר הוא פי 2-3. ככל שהחברה לעומת זאת יותר קטנה או שיש בה ראש צוות IT/מנמ"ר שמפעיל ראש יותר "גדול" – הוא ירכוש במחיר היותר נמוך, כל עוד הוא מקבל מסמך אחריות ותמיכה מיצרן הציוד.

מכאן נעבור לאחסון ונראה כיצד ה-Fear Factor יכול להשפיע.

"על הנייר" מבחינה טכנית נטו – אחסון בשיטת Scale out היה אמור לכבוש נתחים גדולים בשוק ולפגוע במכירות אחסון Scale Up מסיבות ידועות: אפשר להגדיל את כמות האחסון ללא השקעה כה מאסיבית מבחינה פיננסית, אפשר להגיע לכמות IOPS רצינית מאוד בכך שמשדכים עוד ועוד שרתים, והשרידות של פתרונות Scale Out מעולה. מבחינת שוק אחסון Scale Out, החלוקה די פשוטה: Nutanix בקצה הנמוך, vSAN בקצה הנמוך עד בינוני, Ceph בקצה הגבוה (כשאני מדבר על קצה גבוה – אני מדבר על החל מ-1-2 פטה ומעלה ועד כמות דו ספרתית של פטהבייטים).

אני רוצה לתת דוגמא של יעוץ שעבדכם הנאמן נותן כשזה מגיע לאחסון Scale Out שמגיע לפטהבייטים – אל תרכוש דיסקים מיצרן השרתים ותכניס לשרתים (למעט 2 דיסקים SSD בתצורת M.2 לאחסון מערכת הפעלה). רכוש שרתים בתצורת 1U, ו- JBOD גדול (12-24 דיסקים), ואז לחבר את ה-JBOD לשרתים ולסגור עיסקה עם מפיץ/יבואן של דיסקים כולל SLA. במקרים של הטמעות כאלו, מדובר על מאות או אלפי דיסקים, ושיטה כמו שאני מציע תחסוך משמעותית במחיר הפרויקט.

את הדבר הזה לדוגמא, קשה "למכור" לארגונים בינוניים עד גדולים בגלל ה-Fear Factor שהזכרתי לעיל, שאולי, חס ושלום, יצרן השרתים לא ירצה לתת תמיכה (או במקרה של HPE, זה יעבוד אבל לא יתן חיווי טוב לגבי הדיסקים אם מכניסים דיסקים צד ג'), ולכן הם יעדיפו לשלם פי 2-3 פר דיסק, גם אם תראה להם שהם משלמים הרבה יותר מדי. זו בדיוק אחת הסיבות שחברות רבות העדיפו לרכוש אחסון Scale Up.

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

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

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

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

אחסון: Scale Up מול Scale out (מאמר עדכון)

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

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

נתחיל בפתרון הפופולרי שיותר ויותר רוצים: פתרון Scale Out ובמקרה של VMWare מדובר כמובן ב-vSAN (עם Nutanix, Simplivity, Hyperflex הדברים מעט שונים). הדבר הראשון שצריך לקחת בחשבון זה עלות שדרוג רשיון ל-vSAN. בכל שרת שיש בו שני מעבדים, צריך לשלם כמדומני $5000 וזה רק על הרשיון, כלומר אם יש נניח 10 שרתים, אנחנו מדברים על $50K לפני שבכלל דיברנו על חומרה. אחרי שדיברנו על רשיונות, נדבר על דיסקים וסוג האחסון: Hybrid או All Flash, רובם כשהם מקבלים הצעות ל-All Flash ב-vSAN נרתעים מהמחיר אז נעבור ל-Hybrid. הדיסקים מקובצים כ-Disk Group. מבחינה טכנית, כל Disk Group יכול להכיל עד 7 דיסקים מכניים ודיסק SSD, המכניים הם ה-Capacity וה-SSD נקרא Cache. חישוב הדיסקים צריך להיות לפי רמת ה-RAID שאתם בוחרים, לפי כמות ה-Fault Domains, ה-Erasure Coding ועוד. לא מומלץ לנסות לחשב לפי Dedup מכיוון שיחס ה-Dedup הוא משתנה נעלם שמשתנה בהתאם לתוכן המאוחסן, כמות פעמים שאותם בלוקים מאוחסנים ועוד, למעוניינים – ניתן לקרוא יותר פרטים על כך כאן וכאן. נקודה חשובה לציון: VMWare גם נוטים להמליץ על דברים שייקרו את המערכת, כמו בקר RAID לכל קבוצת דיסקים (כי זה עוזר ב-Rebuild), תלוי במצב הקונפיגורציה שלכם, לא חייבים להקשיב ולרכוש. מה שכן, ותלוי בתקציב, מומלץ לרכוש SSD Mixed Intense ל-Cache (היחס קריאה כתיבה לדיסקים SSD שהם Read Intense הוא 80/20 או 75/25, ו-VMWare מבקשת 70/30 – לשיקולכם).

מכאן נעזוב את פתרונות ה-HCI ונעבור לאחסון כללי.

אין שום בעיה לאחסן 2-3 פטהבייט באחסון Scale Up. הנה לדוגמא JBOD של Western Digital שיכול לקבל עד 102 דיסקים מכניים של 12 טרהבייט ולתת כמות אחסון ברוטו של 1.2 פטהבייט. אפשר לשרשר קופסא כזו לעוד שלושה קופסאות נוספות כך שתיאורתית ניתן לאחסן ברוטו 3.6 פטהבייט. את הקופסאות האלו ניתן לחבר לשרת שמריץ את תוכנת האחסון (למען האמת, ניתן לחבר את זה כמעט לכל סטורג' חדש כיום, רק שיצרן הסטורג' לא יתמוך בכך מבחינת תמיכה ואחריות, אם כי יכול להיות שגם הוא מוכר משהו דומה) ואם רוצים – אפשר לחבר שתי קופסאות סטורג' ("ראשים") בתצורת High Availability ולקבל פתרון אחסון מעולה…

.. עד שמגיעים לבעיה המרכזית באחסוני Scale Up כאלו: אם בקר ה-SAS באחת מקופסאות ה-JBOD יתקלקל, פתרון האחסון יושבת (וכמובן השרתים המקושרים לו) ואנחנו מדברים על השבתה של מינימום 4 שעות במקרה הטוב, יום עסקים במקרה הפחות טוב, וכמה ימים במקרה הרע (מה לעשות, לא לכל יבואן יש כמה כאלו שהוא שומר בסטוק למקרה חרום, וכבר ראיתי מקרה כזה).

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

ב-Scale Out לעומת זאת, אפשר לשלב מספר קופסאות כמו הנ"ל בכך שנצוות קופסא מול שרת, מינימום שלושה שרתים (הכמות עולה במספר אי זוגי – 3,5,7 וכו' וכו') ואז גם אם יתקלקל JBOD, יתקלקל שרת אחסון Scale Out או שניהם ביחד – המערכת תמשיך לתת שרות. החסרון כמובן קשור לעלויות – צריך יותר שרתים יעודיים, צריך Backbone של 40 ג'יגהביט לפחות, סביר להניח שנצטרך שרת עם דיסקים SSD לצרכי Cache וכו', ולכן פתרונות כאלו מתאימים לפרויקטים גדולים כמו HPC, או Big Data ועוד, וכאן שימוש בפתרונות Scale Up לא יתן פתרון אחסון מהיר ויעיל. אותו דבר לגבי כמות אחסון – אם כל מה שאתה צריך לאחסן זה כמה עשרות או מאות בודדים (100-200) של טרהבייט, לך על Scale Up.

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

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

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

בעבר, פתרונות אחסון של חברות כמו NetApp ו-EMC כללו בתוכן מספר שכבות:

שכבה מאוד מהירה – שהיתה מורכבת ממקלות זכרון בלתי נדיף (NVRAM)
בחלק קטן מהמקרים, שכבה מהירה נוספת – RAM מגובה סוללה
שכבת דיסקים SSD ("שכבה חמה")
שכבת דיסקים מכניים (SAS או SATA) ("שכבה קרה"

עם התפתחויות הטכנולוגיות השונות, כמעט כל היצרנים ירדו משימוש ב-NVRAM (זה יקר מאוד ליצרן הפתרון אחסון, מה שכמובן מייקר את הפתרון ללקוח הסופי ומה שמקשה בתחרות מול יצרנים אחרים), וכיום בד"כ פתרונות אחסון משולבים (דיסקים מכניים ו-SSD) כוללים שכבה חמה קטנה שמורכבת מדיסקים SSD ושאר הדיסקים הם מכניים (כיום רוב היצרנים פשוט מכניסים דיסקים SATA, חלקם עדיין מוכר דיסקים SAS), כך שבסופו של דבר, כלקוח, כל היצרנים יציעו בפניך שתי אפשרויות (עם כל מיני תוספים כמובן): מערכת אחסון "היברידית" (מכנית, SSD) או AFA (כלומר All Flash Array) שמורכבת מדיסקים SSD. משהו חדש שנכנס לשוק (ולא ראיתי עדיין אותו בארץ) הוא "היבריד SSD" (שם שאני נותן עבור פוסט זה) כאשר רוב הדיסקים הם SSD Read Intence ומספר קטן של SSD הוא NVME Mixed Intense. לחברת לנובו יש מערכת שה-SSD Mixed Intense מוחלף בדיסקים Optane של אינטל, כדי לקבל מהירויות כתיבה גבוהות (אבל אותו סטורג' ספציפי יקר מאוד – הוא מתחיל ב-7 ספרות בדולרים).

כעת נתמקד במה שנקרא בחלק מהמקרים "שכבת ה-Cache". בעבר (ועדיין בחלק מהמקרים כיום) פתרון האחסון היה כולל מספר מצומצם של דיסקים SSD די קטנים (200-400 ג'יגהבייט), מטרתם היתה אחת: לקבל את כל המידע שאמור להיכתב לתוך פתרון האחסון, לאשר ל-client שהמידע נכתב (מה שנקרא sync) וברקע להעביר את המידע לדיסקים המכניים שמטבע הדברים הם איטיים בהרבה מאותם SSD. ה-SSD שהיו אז היו דיסקים קטנים ויקרים להחריד, הואיל ותאי ה-Flash שלהם הכילו מקסימום מספר אחד בכל תא (מה שנקרא Single Level Cell, או SLC), כיום רוב מוחלט של הדיסקים מכיל Flash עם תאים שיכולים להכיל שני מספרים בכל תא (MLC) או שלושה מספרים בכל תא (TLC). הכלל הפשוט הוא שככל שמאחסנים יותר מספרים בתא, הכתיבה את התא (ובעצם אל שבבי ה-Flash ב-SSD) יותר איטיים, ולכן – כאשר חושבים לרכוש פתרון אחסון ומקבלים מפרט, חשוב מאוד לשאול מה סוג התאים ב-SSD: האם הם MLC (ונגזרותיו, בכולן מופיעות האותיות MLC) או TLC או QLC (שזה הכי איטי ולמעט ארכיבאות אני לא ממליץ אותו לשום פתרון אחסון). לא תמיד אפשר לדעת זאת הואיל וכל יצרן פתרון אחסון נותן שמות אחרים ל-SSD מהשמות שהיצרן SSD נותן למוצריו, ולכן צריך "לדוג" קצת. אפשרות אחרת לדעת – היא לבדוק האם ה-SSD הוא Read Intense או Mixed Intense (ה-Mixed Intense מתאים לעבודות שכמות הקריאה והכתיבה די שווה, ולכן הוא אידיאלי לשמש כ-Cache בפתרון אחסון). הטובים ביותר הם MLC או Mixed Intense.

זוכרים את הדיסקים הקטנים מהפיסקה הקודמת? איתם קשה לבנות Cache אלא אם רוצים לשרוף כספים כאילו אין מחר. כיום לעומת זאת, דיסקים שהם Mixed Intense שהם מעולים לצרכי Cache – יכולים לתת ביצועים מעולים לא רק בכתיבת ה-DATA מבחוץ אל תוך פתרון האחסון, אלא גם לשמש כ-"שכבה חמה". חישבו על כך: 4 דיסקים SSD בתצורת Mixed Intense בגודל 4 טרהבייט פר דיסק יתנו לנו 16 טרהבייט נטו של "שכבה חמה" (הדיסקים הללו מוגדרים בחיבור כ-RAID-0 הואיל וכל הנתונים שנמצאים שם – זמניים, ה-DATA כולו מאוחסן בשאר הדיסקים שאינם מוגדרים כ-Cache), ועם כמות כזו של Cache (שבעצם משמש כ"שכבה חמה") רוב הקריאות נתונים לדוגמא יקראו מאותם רביעיית SSD, ומכיוון שאלו דיסקים בחיבור NVME, אנחנו יכולים לקבל מהירות קריאה של 12-14 ג'יגהבייט לשניה (תיאורתית, צוואר הבקבוק שלכם במקרים כאלו יהיו הסיבים או כל סוג חיבור אחר, לא הדיסקים).

לכן, כיום, אם מישהו רוצה לפתרון האחסון שלו "שכבה חמה", והוא רוכש אחסון היברידי (מכניים ו-SSD), הוא צריך לוודא כי ישנם מספר SSD שהם Mixed Intense ואם אפשר – בחיבור NVME. אל תרכשו דיסקים SSD גדולים לצרכים כאלו (8-10 טרהבייט ומעלה) מכיוון שהם מאוד יקרים. עדיף לרכוש 4 של 4 מאשר 2 של 8 טרהבייט ושכל אותם SSD בפתרון ההיברדי מוגדרים כ-Cache (זה מה שיוגדר כברירת מחדל במערכת פתרון האחסון). במערכות AFA אין צורך בכך הואיל וגם SSD בחיבור SATA יתן מהירויות קריאה מהירות מאוד ובכך פתרון זה מייתר את הצורך ב"שכבה חמה". אגב, AFA שכולו מלא ב-SSD עם NVME יהיה תמיד "חנוק" מבחינת רוחב פס החוצה אלא אם יש Backbone של 100 ג'יגהביט ומעלה.

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

אחסון: על דחיסה, Dedup וטריקים שיווקיים

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

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

אתאר סיטואציה: חברה רוצה לרכוש פתרון אחסון אחר ממה שיש לה כיום. בדרך כלל אנשי המכירות של חברות/מפיצים שונים ישאלו כמה נטו אחסון אתה מחפש, האם אתה מחפש All Flash או שילוב של דיסקים מכניים ודיסקים SSD שישמשו כ-Cache ועוד מספר שאלות. עד פה הכל טוב ויפה.

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

נושא ה-Dedup הוא נושא מורכב. ברמת המאקרו, Dedup זו פונקציה בסטורג' שסורקת את הבלוקים באחסון, מוצאת אלו בלוקים נמצאים יותר מפעם אחת, ומשנה את הרישום כך שאם יש לנו 10 בלוקים זהים, בלוק אחד ישאר באחסון ו-9 אחרים יקבלו הפניה (reference) לאותו בלוק, ובכך מקבלים במקרה הזה Dedup ביחס של 10:1. מכיוון שסטורג' מכיל תכנים רבים ושונים, יחס ה-Dedup משתנה בהתאם לתוכן ובד"כ יופיע יחס dedup משוקלל. תהליך ה-dedup בדרך כלל רץ מחוץ לשעות העבודה, בחלק מהפתרונות הוא "יחנוק" את משאבי העיבוד ובחלק מהפתרונות התהליך יתפוס רק כמות קטנה של זכרון ועיבוד (כמו ב-vSAN – שם התהליך תופס עד 5% ממשאבי העיבוד). אחד הדברים הראשונים שצריך לדעת כבעל הסטורג', הוא שאתה לא יכול לקבוע את יחס ה-Dedup. זה נקבע בהתאם למה שמאוחסן בסטורג' – ברמת בלוק, ווליום וכו'. (שוב, זהו תאור ברמת מאקרו).

לדוגמא: נניח ויש מערכת של VMWare ואנחנו יוצרים 3 templates של מערכות הפעלה שונות: Windows 10, Windows Server 2016, Centos 7.7. אחרי שיש לנו את ה-Templates אנחנו מקימים 10 מכונות VM מכל מערכת הפעלה, כלומר יש לנו עכשיו 30 מכונות VM – ונעצור. אם נריץ Dedup עכשיו, עוד לפני שניכנס לכל VM ונתקין אפליקציות שונות, נריץ תהליך Dedup ונקבל מספר משוקלל ל-Dedup של 10:1 ואם כל תהליך ה-Dedup ירוץ בשלמותו, אנחנו נחסוך מקום רב, אולם ברגע שנתקין אפליקציות שונות על כל VM עם הגדרות ותהליכים שונים, יחס ה-Dedup (לכשנריץ את התהליך שוב) ירד מכיוון שה-DATA שונה בין VM אחד לשני, גם כשמדובר באותן מערכות הפעלה. בגלל זה, Dedup זה דבר מעולה כשמקימים פתרון VDI – לא צריך פתרון אחסון מפלצתי.

דחיסה (Compression) לעומת זאת היא תהליך שמבוצע בצורה שונה בכל מיני פתרונות אחסון. בחלקם זה נעשה ברמת Block ובחלקם ברמת קבצים. שוב, ברמת המאקרו – המערכת לוקחת בלוק ומנסה לדחוס אותו דחיסת Lossless (כלומר שאין איבוד נתונים). אם המערכת מצליחה לבצע יחס דחיסה טוב (אם נניח גודל הבלוק הוא 128 קילובייט והיא מצליחה לדחוס אותו ל-40K) הוא ישמר כך ויפרס מחדש בכל פעם שנקרא נתונים ממנו. אם לעומת זאת, יחס הדחיסה נמוך, המערכת תעדיף כדי להשאיר ביצועים גבוהים – לא לדחוס את אותו בלוק.

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

כשזה מגיע לפתרון HCI כמו vSAN – הדברים שונים. כשמפעילים דחיסה ו-Dedup ב-vSAN, המערכת תבצע זאת בזמן שהיא מעבירה נתונים מהדיסק Cache לדיסקים המסומנים כ-Capacity ואפשר לקרוא על כך כאן. על מנת לחשב נכונה כמה דיסקים תצטרכו, אתם יכולים להשתמש במחשבון הזה (הוא מצריך רישום באתר VMWare). חשוב לקחת בחשבון דברים כמו Slack Space (זהו שטח האחסון שאינו מיועד לשמירת מכונות VM אלא ל-Snapshots ודברים אחרים ש-vSAN צריך – בדרך כלל מומלץ בערך על 25% מהשטח ברוטו). יש את המחשבון הזה שהוא הרבה יותר פשוט ומתאים יותר כדי לחשב אחסון בלבד (אל תתייחסו למחיר, הוא מיועד למי שרוצה לרכוש את ה-Appliance).

אחד הדברים החשובים כשזה מגיע לרכישה – זה שאתה מקבל את הדיסקים במחיר מופחת כחלק מחבילת האחסון שאתה רוכש. כלומר אם נניח דיסק SSD עולה $1000, סביר להניח שאיש המכירות יוריד את המחיר ל-900 או 800 דולר. לעומת זאת, אם תחזור לאותו נציג יצרן ותבקש לרכוש ממנו נניח עוד דיסקים, אתה תשלם פר דיסק יותר. נניח 1200-1400$, ולכן ההמלצה שלי היא לרכוש את כמות הדיסקים שאתה צריך כדי להגיע לכמות האחסון נטו מבלי להתייחס ל-Dedup Ratio ולדחיסה. אותו Dedup ו-Compression יעזרו לך בדחיית הרכישת דיסקים הבאה (כפי שציינתי – אני מאמין שהם יעלו לך יותר). אם תלך הפוך ותכניס מראש יחס Dedup בחישוב כמות הדיסקים שאתה מזמין ושבמציאות אולי לא תגיע אליה, תקבל בעצם כמות מופחתת של אחסון.

לסיכום: רכישת אחסון קופסא, או שדרוג ל-vSAN או Nutanix או כל פתרון HCI מסחרי הוא עסק יקר, ברוב המקרים זה יעלה כמה מאות אלפי דולרים. אל תאמינו להבטחות של אנשי מכירות, אל תתביישו לשאול שאלות, והכי חשוב: אל תיפלו להבטחות שווא (ראיתי כבר חברת השקעות שנפלה ברכישה בדיוק על הדברים הללו!). מדובר בטכנולוגיה, לא בקסמים ולכן עדיף להתייעץ לפני שמחליטים מה לרכוש.

בהצלחה.

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

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