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

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

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

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

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

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

מכאן נעבור לצד הטכני: האם מערכות סטורג' בקוד פתוח יכולות להוות תחרות מול סטורג' קנייני מבחינה טכנולוגית? התשובה: כן. האם הן יכולות לתת את 3 השרותים העיקריים שחברות מחפשות (CIFS/SMB, NFS, iSCSI)? בחלק המקרים. האם הן יכולות לגדול (Scale Out)? גם – בחלק מהמקרים. על מנת לפשט דברים, יצרתי טבלה פשוטה עם 3 המתמודדים הידועים בקוד פתוח, מה הם מסוגלים לתת ומה לא.

סוג מערכת NFS iSCSI CIFS/SMB Scale Out Scale Up
ZFS 2 1 3
GlusterFS 4
Ceph

1 תמיכת iSCSI ב-ZFS על לינוקס עבור VMWare כולל תמיכת VAAI מחייבת Kernel 4.4 ומעלה.
2 תמיכת NFS ב-ZFS על לינוקס תלויה בגירסת הפצת הלינוקס
3 ניתן לעבוד עם ZFS בלינוקס כ-Cluster בשימוש כלים כמו Sanoid או PaceMaker.
4 למרות שניתן לעבוד עם GlusterFS ב-2 שרתים – הדבר אינו מומלץ מעבר לרמת POC.

אלו המערכות העיקריות. לכל מערכת יש מספר גרסאות מסחריות (למעט GlusterFS). מערכת כמו ZFS ניתן לרכוש מערכת עם "ברזלים" ישירות מ-Oracle או ניתן להתקין FreeNAS, או להקים על שרת לינוקס עם הפצת Debian לדוגמא. תוכנת Ceph ניתנת לרכישה מ-רד-האט או מ-SuSE.

כשזה מגיע לתמיכה/תחזוקה – הדברים שונים בהתאם לגודל העסק/חברה:

  • לעסק קטן שמחפש סטורג' ואולי סטורג' עם שרת ב-Standby (כלומר Active/Passive – כ-Scale Up) הייתי ממליץ לבחור פתרון מבוסס ZFS. אם הלקוח מחפש פתרון Scale Out של כמה טרהבייט, אז אמליץ על GlusterFS וחוזה תמיכה עם אינטגרטור.
  • לעסקים בינוניים וגדולים, אם העסק מחפש פתרון מבוסס קוד פתוח ב-Scale Up, הייתי ממליץ על ZFS ופתרון Scale Out מבוסס Gluster. אם החברה מחפשת פתרון Scale Out בגדלים של Petabyte, אני ממליץ על Ceph. במקרים של GlusterFS ו-Ceph אני ממליץ לחברה לרכוש את התוכנה מהיצרן כולל תמיכה, כך שהאינטגרטור יתן תמיכה ואם יש עדיין בעיה – ניתן לפנות ליצרן התוכנה כך שבכל מקרה החברה מכוסה מבחינת תקלות תוכנה.
  • לחברות גדולות המחפשות פתרון סטורג' גדול מבחינת כמות DATA (שוב, פטהבייטים ומעלה) – אני ממליץ על ישיבה ויעוץ לגבי הפתרון מכיוון שבכל מקרה הפתרון הוא יקר ויש צורך לשמוע את 2 הצדדים (פתרון קנייני ופתרון מבוסס קוד פתוח).

בכל אחד מהסוגי לקוחות, הפתרונות המוצעים כוללים פתרון שרידות כך שלמעט תקלות חומרה או הפסקת חשמל, המערכת אמורה לשרוד נפילה אם יש תקלת תוכנה בסטורג' עצמו. אגב, בהזדמנות זו אני רוצה להדגיש: כאשר אתם קונים פתרון סטורג' שהוא Scale Up מ-NetApp או Dell/EMC, פתרון השרידות שלו הוא חלקי: זה שיש בקר RAID כפול, 2 מעבדים – תקלות כמו בעיית זכרון (ECC יכול לתקן תקלות עד גבול מסויים), או בעיה בלוח האם ב"ראש" – הסטורג' יפול, וכדאי לקחת זאת בחשבון כשרוכשים פתרון.

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

על Spectre/Meltdown ועל יצרניות סטורג'

הערה: הפוסט הבא נכתב כטור דעה אישית בלבד ואינו בא "לתקוף מתחרים"

כולנו שמענו על הצרות עם Meltdown ו-Spectre. בחברות מסויימות מיהרו להטמיע עדכוני BIOS/UEFI רק כדי לראות מערכות שבאופן רנדומלי מבצעות Cold Reboot ללא השארת עקבות והצהרות מצד היצרנים לא להתקין את העדכונים האחרונים ואם הם הותקנו – יש לבצע Rollback.

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

תסלחו לי, אבל מדובר לדעתי האישית בחתיכת בולש*ט!

אני רוצה להפנות את תשומת לבכם למכשיר שאולי אתם מחזיקים כרגע ביד, או שנמצא על שולחנכם או בכיסכם: הסמארטפון שלכם. לא חשוב אם יש לכם אייפון או מכשיר מבוסס אנדרואיד של יצרן גדול וידוע. המכשיר שלכם יודע לבצע Boot והרצת דברים חתומים ומאושרים בלבד. במכשירי אנדרואיד של יצרנים כמו סמסונג, גוגל, LG, מוטורולה לדוגמא, אם תרצה לפרוץ את המכשיר ולשים לו ROM אחר, לא תוכל לעשות זאת אלא רק אם תבצע unlock למכשיר וברגע שתבצע – כל הנתונים האישיים שלך ימחקו מהמכשיר כולל שירים ווידאו שרכשת. באייפון אין בכלל אפשרות כזו. במידה ותנסה להתקין באנדרואיד תוכנה חיצונית שהורדת כקובץ APK, המכשיר לא יתן לך לעשות זאת אלא אם תלך להגדרות ותאפשר לו התקנה ממקורות חיצוניים (ואז תקבל חלונית אזהרה). באייפון זה יותר הדוק בכך שאינך יכול להתקין תוכנות חיצוניות שלא מהחנות ותצטרך לבצע jailbreak ולהתקין מס' תוכנות נוספות כדי לפרוץ את המכשיר. אך כמו שכולנו יודעים, גם לאנדרואיד וגם לאייפון היו (ויש) נוזקות, פריצות ועוד דברים אחרים, לא חשוב כמה המכשיר סגור, עדיין ניתן לפרוץ אותו כולל במערכות הפעלה החדשות וגם לאחר עדכונים, תמיד מישהו ימצא דרך לפרוץ.

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

כיום, מה שבד"כ רואים בפריצות למערכות, זה שמנסים לפרוץ אל השרתים ומכיוון שלשרתים אין גישה לכל מה שנמצא על ה-Storage, אפשר לגשת דרך השרת רק לחלק מהמידע. עכשיו תנסו לחשוב על פורצים מתוחכמים וממומנים. תחשבו על חברות מתחרות שיש ברשותן מאות מילונים/מיליארדי דולרים, תחשבו על מדינות כמו סין ורוסיה שמחזיקות צבא של פורצים ושהן מעוניינות במידע שלך. גם באותם גופים קוראים חדשות והם קוראים שיצרניות ה-Storage מתחמקות והן לא הולכות לבצע עדכוני Meltdown/Spectre. עכשיו אותם פורצים פשוט צריכים לשנות אסטרטגיה: עכשיו הם צריכים בעצם לפרוץ לתחנת עבודה שמריצה Windows או מק או לינוקס ומשם לפרוץ לממשק ווב או לקונסולה (CLI) של ה-Storage, להעלות משהו כמו busybox ואז להשתמש ב-חורים Spectre/Meltdown כדי לקבל מידע סודי/פנימי/חסוי. (הנה משהו שאולי יכול לעזור לכם: בדקו אם יש לכם ACL שנותן גישה לממשק רק למכונות מסויימות בחברה).

מדוע החברות Storage עושות זאת? אני יכול רק לנחש: אם הם יתקינו את הטלאים נגד Spectre/Meltdown – תהיה ללקוחות הנחתה רצינית מאוד בביצועים. כמה? אני יכול להמר בסביבות ה-5-40% תלוי כמובן כמה ה-Storage חדש או ישן. את הלקוחות לא יעניין שהחור קשור למעבדים של אינטל, הם יפנו אצבע מאשימה ליצרני ה-Storage ויצרניות ה-Storage יצטרכו להחליף לוח עם כמעט כל החומרה (למעט כרטיסים וספקי כח..) והמחיר לדבר כזה הוא אסטרונומי מבחינתם.

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

אחסון אובייקטים (Object storage) ו-Ceph

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

באופן עקרוני, בניגוד ל-GlusterFS ו-ZFS, ה-Ceph היא מערכת מבוססים אחסון קבצים (Object Storage). היתרון במערכת כזו היא שהיא "מפשיטה" את כל המורכבות של File System רגיל (כמו XFS, EXT4 וכו') ל"קוביות" קטנות אחידות בגודל 64 קילובייט ואת אותן "קוביות" (שהם בעצם Objects) המערכת משכפלת לשרתים אחרים על מנת ליצור שרידות גבוהה מצד אחד, והם נגישים ל-Clients השונים מכל שכפול, כך קורה מצב שאם לדוגמא מספר מכונות דורשות את אותו קובץ, הוא נקרא משרתים שונים. בנוסף, מאותו Object Storage המערכת בונה גם שרותים אחרים שהיא מציעה, בין אם מדובר באחסון דומה ל-S3, אחסון File System, או NFS (ש"רוכב" על ה-File System") או אחסון "בלוקים" עבור iSCSI.

עם Ceph ניתן לאחסן מיליוני קבצים (ומעלה) עם גישה מאוד מהירה כאשר מגדירים את האחסון וקריאה כמו שקוראים לקבצים ב-S3. היכן זה יכול לעזור לדוגמא? כאשר רוצים לשדר וידאו. בדרך כלל לא מומלץ לחבר שרתי שידור (כמו WOWZA) לאחסון כמו Ceph, אלא מחברים זאת למערכת CDN טובה שהיא מפיצה את התוכן לנקודות EDGE/POP במקומות שונים בארץ/בעולם ומאותן נקודות השידור עצמו מתבצע. באותה שיטה (רק ללא צורך ב-CDN ברוב המקרים) ניתן לדוגמא להקים ארכיב ענק של קבצי מסמכים (גם בגודל של פטהבייטים רבים) ולאפשר גישה מאובטחת למסמכים דרך REST API שניגש ל-RADOS ב-Ceph שמחבר את אותן "קוביות" לאובייקטים ומשם האפליקציה יכולה לקרוא את המסמך ולהנגיש אותו עבור הלקוח. יתרון נוסף הוא באבטחה: אם מישהו מחר גונב שרת ומצפה למצוא את הקבצים שהוא מעניין בהם, הוא יתאכזב לראות שאין ממש קבצי DOC/PDF, יש "קוביות" וצריך את כל המערכת בכדי לקבל את הקבצים הרצויים.

טכנולוגיה חדשה שנכנסת לשוק בשנים האחרונות הם אמצעי אחסון מוכוונים KV (כלומר Key Value) והם מיועדים בראש ובראשונה לאחסן אובייקטים. חברת Seagate לדוגמא הדגימה דיסקים מסוג SMR (שהם דיסקים המיועדים לארכיב – Shingled Magnetic Recorder) בצירוב SSD מאיץ מסוג Nytro נותן ביצועים גבוהים פי 11 בהשוואה לדיסקים מכניים רגילים עם Ceph (ניתן לקרוא על כך ולראות וידאו בנושא כאן).

במסגרת תערוכת CES האחרונה, סמסונג הציגה SSD בפורמט חדש (NGSFF) לשרתים, זהו ה-PM983 וניתן לרכוש אותו בגודל של 8 טרהבייט ובמחצית השניה של השנה, הדגם הזה ימכר בגודל מדהים של 16 טרהבייט למקל. חברת Supermicro הכריזה על שרת פיצה (דגם:SSG-1029P-NMR36L – שם ממש קליט…) בגודל 1U שיכול לאחסן 36 מקלות כאלו, כך שניתן לאחסן 288 טרהבייט על שרת כזה. זה נראה כך:

Supermicro_SSG_1029P_NMR36L

היתרון בשרת כזו הוא שהוא בנוי כולו לאחסון של Ceph. מקלות זכרון האחסון של סמסונג מובנים מראש לאחסון KV וסמסונג מדגימה זאת בתמונה הבאה:

Samsung_KV_Stack_diagram

כפי שאתם יכולים לראות, מצד שמאל זה המצב הרגיל שקיים כיום כשמקימים אחסון מבוסס Ceph: מכניסים דיסקים רגילים או SSD, יוצרים פרטישנים, File System ואז משם מקימים את ה-KV Store שעליו מאוחסנים האובייקטים. מצד ימין רואים פתרון של סמסונג שכל מה שצריך הוא דרייבר והשאר נעשה בצורה טבעית על קושחת ה-SSD, אין צורך בשכבת "המרה" בחזרה ל-File System. במילים אחרות: אם תרכשו לקראת הרבעון השלישי את המכונה הזו ומקלות של 16 טרהבייט, תוכלו לקבל עם 10 מכונות כאלו 5 פטהבייט לאחסון אובייקטים. פעם זה היה לוקח ארון שלם..

לסיכום: כשצריכים לאחסן המון קבצים (כשמדובר במיליונים ומעלה) אחסון מבוסס Object Storage הוא הפתרון, ואמזון הדגימה זאת לעולם במסגרת שרותי ה-S3 שלה, ו-Ceph נותן בדיוק את אותו פתרון, ועתה גם חברות חומרה נכנסות ומציעות אחסון בצורה טבעית שמורידה את כל שלב התרגום מ-Object ל-File system ובחזרה. זהו אינו פתרון זול (ובוודאי לא פתרון להחליף File Server רגיל) – אך פתרונות כאלו מציעים שרידות וביצועים למי שצריך זאת ומוכן לשלם על כך. למעוניינים בפתרונות Ceph בארץ אני ממליץ לפנות ל-SuSE ישראל.

נקודות שיצרני Storage לא רוצים שתדעו

כפרילאנסר שמוכר שרות הטמעה/התקנה של SDS (כלומר Software Defined Storage) אני משתדל בדרך כלל להיות מעודכן גם ב"רכילות" של מה קורה אצל אלו שמוכרים פתרונות כ"קופסאות סגורות", מה-NetApp ו-Dell/EMC ועד ליצרני פתרונות AFA (כלומר All Flash Array) למיניהם. תמיד נחמד לדעת על כל מיני פתרונות שיצרני ה-AFA מכניסים או הולכים להכניס בשעה שהגדולים .. המהנדסים שלהם מדברים על פתרונות כאלו בארוחת צהרים, ההנהלה לא הכניסה את זה ל-Road Map עדיין.

כשזה מגיע ל-SDS, החיים קלים ופשוטים: הלקוח רוכש שרת, עם כל הציוד הנדרש, דיסקים וכו', הוא נניח שוכר את שרותיי, אני מציע לו מספר פתרונות, בין בקוד פתוח או סגור (כולם מבוססי לינוקס למעט Windows – ב-Windows יש לו כיום את Storage Spaces [שהוא אגב, אינטרגלי ב-Windows Server 2016] והוא ממש לא צריך אותי לשם כך), הלקוח בוחר, מרימים גירסה, אני מגדיר את כל מה שהלקוח מבקש, מריצים סידרת טסטים ואם הוא מרוצה – מכניסים לפרודקשן. במקרה ויש לו בעיות עם המערכת הוא פונה אליי ואני מטפל בבעיה אם מדובר בתוכנה או מבקש ממנו לפנות למי שהוא קנה ממנו את הברזל כדי להחליף דיסק/זכרון/לוח/כרטיס-רשת וכו'. פשוט וקל.

אבל כשזה מגיע לסטורג' סגור, אני ממליץ לעבוד בשיטה שאני קורא לה "הבן של מי אתה?"

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

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

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

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

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

  • אם אתם חושבים לרכוש סטורג' – ראשית מומלץ לבדוק לגבי המוצר שאתם רוצים לרכוש – האם הוא מוצר שיוצר בעבר ע"י חברה אחרת שנרכשה ע"י אותה חברה גדולה שאתה רוצה לרכוש ממנה. אם כן – עדיף לחפש מוצר אחר.
  • אם כבר רכשתם מוצר מחברה קטנה שנרכשה ע"י החברה הגדולה, תפנו זמן לצוות הטכני ותתנו להם הוראה להתחיל להתעמק ב"בפנוכו" של הסטורג', לא ברמת GUI אלא ברמת CLI. לא צריך לנסות דברים שיזיקו, אבל כדאי שיכירו את הפקודות, קבצי הקונפיגורציה ומי עושה מה.
    • עוד משהו שאתם יכולים לעשות – זה להיעזר בחברים ולרכוש בנק שעות תמיכה מאינטגרטור שמכיר את הסטורג' הזה. אישית אינני נותן שרותים לסטורג' סגורים, אבל מהיכרות עם חברים שנתנו תמיכה לכל מיני חברות ועסקים שיש להם סטורג'ים כאלו – ההשקעה בבנק שעות כזה הצילה חברות לא פעם ולא פעמיים בהשוואה ל"טקס מעבר-בגהינום" של התמיכה בחברה הגדולה. קנו לכם כמה עשרות שעות שיהיה לכם שקט במקרה של תקלות (יהיה לכם עדיין את היתרון שבמקרה ויש תקלת חומרה – החברה הגדולה תשלח נציג שיבוא ויחליף את הציוד התקול).
  • העולם עובר ל-Software Defined Everything, מסטורג' לרשת ודברים נוספים, ולכן מומלץ לשקול בחיוב לקחת פתרון Software Defined Storage. אל תאמינו לי, תשאלו את VMWare, Microsoft, Red Hat, Amazon וחברות מפורסמות אחרות. עם SDS אין לך שום "מסע גהינום" של תמיכה, יועץ/אינטגרטור נותן לך תמיכה ואם אינך מרוצה אפשר להחליף אותו ביועץ/אינטגרטור או חברה שנותנת את אותם שרותים ואם יש תקלת חומרה – החברה שמכרה לך את הברזל תחליף לך את הציוד, כך שזמן ההשבתה מתקצר משמעותית, יש למי לפנות וניתן לקבל בזמן קצר פתרונות.

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

על אחסון וגדילה

כשמדברים על אחסון (כ-Storage), רובנו נתייחס למכונה הגדולה שנמצאת בחברה, ה-Storage הזה שברוב מוחלט של המקרים הוא קופסא של יצרן כלשהו. זה יכול להיות של NetApp, של EMC, של IBM, של HP ושלל חברות גדולות וקטנות, כל חברה בד"כ תקנה לפני הצרכים או לפי ההמלצות, ואצל רובן תהיה "קופסא" אחת כזו שאליה משורשרים "מגשים" של דיסקים. זה יכול להיות דיסקים מכניים מבוססי SAS, דיסקים שהם SSD, דיסקים שהם NL-SAS או אפילו במקרים מסויימים – SATA.

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

מה קורה כשכמות המקום הפנוי היא קטנה? בד"כ מוסיפים עוד "מגש" (במקרים מסויימים זה נקרא גם JBOD) והדיסקים שיהיו בפנים יכולים להיות מסוגים שונים, בהתאם לתקציב ולביצועים שמעוניינים לקבל. הגישה הזו נקראת Scale Up.

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

בנוסף – ישנם 2 בעיות רציניות:

הבעיה הראשונה נקראת SPOF (או Single Point Of Failure): הגדרות שגויות, מעבד שמתקלגל, זכרון שנדפק, בקר שהפסיק לעבוד בצורה תקינה – והפתרון אחסון שלך יתן ביצועים גרועים או שבמקרה הגרוע – יפסיק לעבוד. נכון, יש SLA שסביר להניח שרכשתם ובו טכנאי של החברה המייצרת/יבואן הפתרון יתחבר אליכם מרחוק או יגיע אליכם תוך זמן קצר, אך עדיין, גם אם הוא יתקן את התקלה, תצטרך ברוב המקרים להפעיל את כל המכונות הוירטואליות מחדש, לוודא שכל השרותים למעלה, לוודא שהגדרות שביצעו אנשי ה-IT באמת נשמרו ולא צריכים להגדיר מחדש כדי ששרותים יעלו ובקיצור – כמעט שום תקלה שקשורה לתיקון האחסון אינה מסתיימת בדקות ספורות אלא יותר בשעות.

אם תשאל את יבואן האחסון לפתרון, הוא ישמח להציע לך פתרון של "אשכול" (Cluster): בפתרון כזה אתם רוכשים עוד פתרון אחסון זהה (אם כי אפשר בחלק מהמקרים להסתפק בדיסקים יותר איטיים ו-SSD שישמש כמטמון, תלוי ביצרן, תלוי בדגם) ואז מבחינה תיאורתית אם האחסון הראשי נופל – האחסון השני נכנס לפעולה (מה שנקרא Active/Passive Cluster) ואפשר "לטפל" לדגמים יותר גבוהים שמאפשרים לך בעצם לפצל את העומס בערך למחצית, כאשר 2 האחסונים עובדים ביחד וכל ביט שנכתב – נכתב ב-2 האחסונים. פתרון זה נקרא Active/Active Cluster ובמקרה כזה אם אחד האחסונים נופל, השני ימשיך לעבוד כרגיל וברגע שהאחסון התקול יטופל ויעלה, יהיה סינכרון בין האחסונים. הבעיה הכי גדולה בפתרון כזה – הוא המחיר, והוא מאוד גבוה.

הבעיה השניה שהיא יותר מהותית באותם אחסונים כמו NetApp ואחרים – היא "קניינות" של הפתרון, כלומר שהכל סגור מבחינת ה"ברזל", הדיסקים והמערכות שעובדות בתוכו. אם מחר יפנה אליך לדוגמא יבואן דיסקים ויציע לך מבצע-משוגע של דיסקים מבוססי SAS גדולים במחיר של 3 ותקבל 4 (לדוגמא) – לא תוכל להכניס את הדיסקים הללו לאחסונים הנ"ל. ישנו קוד מיוחד שבודק את הדיסק שהכנסת ל"מגש" וברגע שהוא מוצא שהדיסק אינו מאותו יצרן/סוג מסויים שיצרן האחסון עובד איתו – המערכת פשוט לא תהיה מוכנה להכניס את הדיסקים החדשים שקנית לשימוש. אתה גם לא יכול להכניס JBOD שאינם של אותו יצרן אחסון לשימוש עם פתרון האחסון. בקיצור – הכל צריך לעבור דרך השיווק של יצרן פתרון האחסון שיש לך, והוא כמובן נוקב במחירים הרבה יותר גבוהים ממה שאתה יכול לקנות בשוק החופשי. (אם כי אסייג שבחלק מהפתרון לקצה היותר נמוך, במיוחד פתרונות NAS – אין בעיה להכניס דיסק של כל יצרן, אבל הבעיות של פתרונות כאלו הם עדיין ה-Scaling).

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

מ-Scale Up נעבור למושג שמוכר יותר בתחום ה-High Performance Computing ותחום הענן – זהו תחום ה-Scale Out בפתרונות אחסון.

סביר להניח שלקוראי פוסט זה יש חשבון אחד או יותר אצל אחד מספקי פתרון ענן כלשהו, בין אם זה אמזון , או Google Compute Platform או Azure של מיקרוסופט – ונגזרותיהם: לאמזון יש את S3, לגוגל יש את ה-Google Drive, למיקרוסופט יש את OneDrive ויש גם פתרונות אחרים כמו DropBox ואחרים.

המכנה המשותף לכל אותם פתרונות אחסון קבצים בענן – זה מערכות האחסון שלהם. אף אחד מספקי הענן לא משתמש ב-NetApp או EMC והם לא משתמשים בדיסקים SAS במהירות 15K RPM כדי לאחסן את הקבצים שאתה מעלה (אינני מדבר על אחסון של מכונות וירטואליות או EBS – לזה נגיע בהמשך). במה הם משתמשים? בדיסקים הכי פשוטים שיש (כן, גם דיסקים איטיים). מהי מערכת האחסון שלהם? לכל אחד מספקי הענן יש פתרון In House משלו שהמתכנתים שלו כתבו או השתמשו בפתרון קוד פתוח אחר (אף אחד מהספקים לא מפרט) וברוב המקרים זה רץ על לינוקס. הם כמובן משתמשים בדיסקים של SSD כחלק מהפתרון, ואת השרידות הם מבצעים בכך שהם כותבים את אותו הקובץ למספר מקומות אחרים באותו Data Center. מכיוון שמדובר בפתרון שמכיל מאות אלפי (ויותר) דיסקים קשיחים – הפתרון מבחינה טכנית אצלהם שונה לחלוטין ממה שיש ב-Corporate. אין RAID ברמה כלשהי, ואין מעבדים קניינים מיוחדים בתוך שרתי האחסון (שאליו מחוברים כמות רצינית של JBOD). כך מצד אחד הם חוסכים בהשקעה ומצד שני הם יכולים לתת רמת שרידות מעולה. אחרי הכל, במחיר של דיסק אחד ל-Enterprise אפשר לקנות 3 דיסקים הרבה יותר גדולים מבוססי SATA פשוטים.

כשזה מגיע לאחסון מכונות וירטואליות או אחסון שיותר מוכר כ-Raw Storage – לדוגמא EBS, PD, Drives – בהתאם לספק ענן, גם כאן ספקי הענן לא "רצים" לקנות את פתרונות ה-Enterprise והם מעדיפים פתרונות SSD שהם זולים, גם אם חיי המוצר יהיו קצרים, והספקים משתמשים בכל טריק אפשרי כדי לתת למכונות שלך בענן ביצועים גבוהים (יחסית), אבל שוב -אין שימוש בפתרונות אחסון קנייניים מבחוץ כמו של EMC ואחרים. זה פשוט לא שווה להם פיננסית, במיוחד בתחרות האכזרית כיום שכל ספק חותך בעשרות אחוזים את המחיר והשאר "נגררים" אחריו בחיתוכי מחיר לאחר מספר ימים.

הפתרונות שתיארתי מבחינת ספקי הענן – הם נכללים בקטגוריות ה-Scale Out, כלומר הפתרונות לא מבוססים על שרת אחסון יחיד ואולי עוד Mirror, אלא הם מתחילים ב-3 שרתים ומעלה כאשר העומס מחולק בין השרתים. במקרה של ספקי הענן מדובר כמובן בהרבה יותר מ-3, ומכיוון שהכל נכתב בכמה וכמה עותקים, גם אם יפלו שרתים שמחזיקים מאות דיסקים, אתה לא תרגיש בכלום, כי אתה תקבל את השרות משרתי אחסון שכנים שיושבים באותו Data Center.

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

בפוסט הבא אתאר כיצד פתרון Scale Out יכול להתאים ל-Enterprise/Corporate, מהם ה"מועמדים", יתרונות וחסרונות ובמיוחד – על Ceph.