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

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

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

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

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

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

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

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

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

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

אחד מול השני: Ceph מול GlusterFS

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

2 הפתרונות שבגינן יש בלבול רב הם GlusterFS מול Ceph. למרות ש-2 הפתרונות הם פתרונות Scale Up, יש שוני גדול ביניהם שכדאי להכיר לפני שחושבים לאמץ פתרון זה או אחר.

נתחיל ב-Ceph. מערכת Ceph היא מערכת "חייתית" שהמטרה שלה אחת היא: לתת ביצועים מקסימליים לחברות שמוכנות להשקיע בתשתית. באופן עקרוני, מערכת Ceph שולטת במכונות האחסון בדברים מ-א' ועד ת' – הן שולטות על הדיסקים, המערכת שולטת לאן כל דבר יכתב ואיך יכתב ומהיכן צריך לשחזר ואיך לשחזר במקרה שקם צורך להתקין מכונה אחרת במקום אחת שהלכה, ובגלל זה חישוב האחסון הוא מעט שונה: על כל ג'יגהבייט שתרצה לאחסן, תצטרך בדיסקים מקום של 3 ג'יגהבייט לערך (יותר בכיוון 2.4) ומכונה אחת אינה מספיקה, יש צורך ב-3 מכונות (כאשר כל מכונה היא בעצם שרת 2 או 3U מלאה בדיסקים מכניים וחלק SSD) עם הרבה זכרון, רוחב פס של 40 ג'יגהביט (המינימום הוא 10 ג'יגהביט) ועם מעבדים חזקים, כך שכל דרישה להגדיל כמות אחסון או מענה מבחינת מהירות ורשת ללקוחות – מצריך הוספה של מכונות (במדריך ההטמעה של SuSE לדוגמא יש "רשימת קניות" מה הדרישות חומרה פר Node).

מי שיציץ בלינק יחשוב בוודאי שזה נשמע מוגזם מבחינת דרישות חומרה, וכאן בדיוק העניין: זהו פתרון שאינו מתאים לחברות קטנות ובינוניות. זה פתרון שיכול להתאים לבנקים, קופות חולים, חברות ביטוח, חברות פיננסיות גדולות שיש להן המון DATA ואותם נתונים אמורים להיות זמינים בכל דקה, 24/7/365 ועם Latency מאוד נמוך. האם הן כבר אצות רצות להטמיע? התשובה היא "עדיין לא". מנמר"ים, מנהלי IT ו-CTO רבים צריכים בשביל זה "להחליף דיסקט", וכשאני שומע מהם שהם מחפשים פתרון שיהיה Active/Active או Active/Passive אז אני מבין שהם עדיין לא ממש "נכנסו לראש" של Scale Out.

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

עם GlusterFS המצב שונה לחלוטין. נתחיל בכך שאם ב-Ceph כל השרת 2U/3U מיועד לשימוש הסטורג', ב-GlusterFS המצב הפוך. אם לדוגמא אתם מריצים vSphere/ESXi, אז אתם בוודאי מכירים את העניין שאפשר לעשות boot ל-ESXi מ-Disk on key או PXE ואין צורך בדיסק קשיח מקומי להתקנת ה-OS, אז אפשר על אותה מכונה להקים ESXI, להקים VM עם נניח 16 ג'יגהבייט זכרון, ולמפות אל ה-VM את כרטיס ה-RAID עם הדיסקים. ונצטרך להגדיר גם 2 חיבורי רשת פיזיים (האחד לקבל שרותים מה-Gluster והשני לחבר את כל המכונות שישתתפו ב-GlusterFS). לא צריך שרת חדש נוצץ מהניילונים, גם שרת R610/R710 דור 11 של DELL, שרתי HP G7, שרתי X3550/3650 M2 של לנובו/IBM יתאימו למטה (כל עוד הבקר תומך ב-SATA במהירות 6 ג'יגהביט), אפשר למלא דיסקים פשוטים (WD RED PRO ואחרים שנותנים מהירות 7200 RPM) ואולי 1-2 דיסקים SSD בחיבור SATA. שאר משאבי המערכת ישומשו טובת הרצת אפליקציות אחרות, מכונות וירטואליות, קונטיינרים (בפוסט קרוב אדגים איך Gluster FS יכול לעזור ל-Kubernetes בכך שתצטרך מעתה לבקש רק Volume Claim מבלי ליצור Volume, המערכת תיצור אוטומטית וניתן לגשת לאותו Volume ממספר קונטיינרים במקביל) וכו'.

גם כאן, כמות המכונות המשתתפות ביצירת Volume יכולה להיות מינימום 2 אך עדיף ברוב המקרים להתחיל עם 3, רק שכאן אם אתם רוצים להישאר עם 3 ולהוסיף דיסקים לדוגמא, חברו JBOD עם הדיסקים, צרו מהדיסקים דבר שנקרא Brick, והוסיפו אותו ל-Volume קיים. זה יספיק. מבחינת File system, ל-Gluster FS זה כלל לא משנה. תקים ZFS על הדיסקים ועל זה תריץ GlusterFS? אין בעיה. תרצה לפרמט עם בקר ה-RAID שלך את כל הדיסקים לאיזה RAID מסוים ועל זה להריץ GlusteFS? אין שום בעיה. גם כמות הדיסקים אינה ממש משנה, ואפשר אפילו להתחיל בדיסק יחיד (לא כל כך מומלץ אלא אם זה דיסק וירטואלי).

עכשיו החלק היותר מעניין: החלק הכי קריטי בבחירת מערכת זה החלק של השרותים. איזה שרותים אפשר לקבל עם הפתרון? גם עם Ceph וגם עם Gluster FS, אתה יכול לקבל את אותם פתרונות. רוצה iSCSI MP? יש. NFS כולל גירסה 4.1 או PNFS? יש. רוצה Object Store? יש. שרידות במקרה ששרת פיזי נופל? יש. מחפש Deduplication? ב-Gluster FS ניתן לקבל זאת כשמפרמטים את הדיסקים עם מערכת ZFS ובדרך גם ניתן לקבל דחיסה. (ב-Ceph כרגע אין את זה). מה עם Caching ו-Erasure Coding? יש ב-Ceph ויש גם ב-Gluster FS, וכן, לשתיהם יש גם ממשק WEB.

מה עם שרות ותמיכה? לגבי Ceph – גם SuSE ישראל וגם רד-האט ישראל (דרך הנציגים שלהם בארץ) מוכרים חבילה מסחרית ותמיכה מסביב לשעון של Ceph (ב-Suse זה נקרא SuSE enterprise storage 5, ב-רד-האט זה נקרא Red Hat Ceph Storage) עם תמיכה מסביב לשעון. כשזה מגיע ל-Gluster, רד-האט מוכרת את Red Hat Gluster Storage. אני ממליץ לשים לב לנקודה עקרונית: לא מומלץ להתקין את התוכנות אם אתם לא קונים ואין לכם מישהו שיתמוך לכם בתוכנה. נכון, Gluster FS לוקח חצי שעה להקים, אבל כשהתקלות מתחילות, אם אין ידע, זה כאב ראש (במיוחד ב-Ceph).

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

על אחסון ווידאו בחברות מדיה

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

בעולם ה-Corporate, סטורג' הינו חלק קריטי מהתשתית. מכונות VM מאוחסנות על סטורג' ולא על דיסקים מקומיים, אפליקציות כמו SQL/Oracle DB דורשות סטורג' (במיוחד אם מריצים כתצורת אשכול [cluster]), כל קבצי העבודה של העובדים (מסמכים, קוד וכו') מאוחסנים בסטורג', גיבויים זמניים מאוחסנים בסטורג' ובקיצור – הסטורג' "נוגע" כמעט בכל תחום. אחרי הכל, כולם מכירים: כשסטורג' נופל – ההיסטריה בשיאה.

בשנים האחרונות, עם חדירת העננים הציבוריים ל-Corporate – השימוש ב-Storage פוחת במעט (ככל שמעבירים VM ושרותים לענן), אך עדיין לסטורג' יש מקום מאוד שוב. יחד עם זאת, כמות השדרוגים או רכישות סטורג' חדש – מתמעטת. אחרי הכל, אם "העפתי" 50 VM ל-AWS לדוגמא, והם יעבדו ב-AWS באופן קבוע, אני אשמור מקומית גיבוי, אבל אני לא אצטרך להשאיר אותם ב-Datastore היקר המקומי, אני אמחק אותם ואז יתפנה לי מקום בסטורג', מה שאומר שרכישת עוד מדף סטורג' תיהפך למיותרת. בנוסף, בעולם ה-Corporate הגדילה היא איטית. לא כל יום מרימים עוד 100 VM (וגם אם מרימים, משתמשים ב-Template כך שרק השינויים נשמרים ולא כל VM שוקל 10 ג'יגה ומעלה).

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

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

מדוע? כי חברות הוידאו דורשות צילום איכותי וגבוה. פעם היו מסתפקים ברזולוציית SD ולאחר מכן העולם קפץ ל-HD ול-Full HD וכיום הרוב מצולם ב-4K או 5K ו-6K וחלק (שמשתמשים ב-RED לדוגמא) מצולם בכלל ב-8K. בניגוד לצילום באייפון (או גוגל פיקסל) – מצלמות מקצועיות מצלמות ב-Bitrate החל מ-20 מגהביט ועד 80-130 מגהביט (ומעלה במקרה של RED אם לא משתמשים ב-REDCODE) ועוד לא דיברנו על ביטים פר ערוץ צבע (8,10,12 וכו') ועוד. במקרים רבים מצלמים ב-2 מצלמות (או יותר), נוסיף אודיו שמוקלט בנפרד, צילומי סטילס (בחלק מהמקרים). את כל הערימה הזו צריך להעלות לאיזה סטורג' כלשהו ובחלק מהמקרים צריך גם לתרגם (Transcode) ל-Codec אחר (מה שנקרא Mezzanine Codec) בכדי לאפשר עבודה רציפה על התכנים בהתאם לתוכנת העריכה המועדפת על החברה. אחרי זה יש צורך בעריכה של הקובץ, הוספת תכנים שונים (אפקטים, תלת מימד, אנימציות, אודיו וכו'), ולבסוף יש צורך שוב בהמרה של התכנים לפורמטים שונים (הוצאה לאולפנים שונים בהתאם לדרישות שלהם, יוטיוב, סטרימינג וכו').

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

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

הבה נאמר שלחברה יש סטורג' כיום זמין שאליו מתחברים עורכי הוידאו ומשתמשים בתכנים. אחרי שהתוכן עבר עריכה והמרה – יש צורך לאחסן את התכנים על מנת שיהיו זמינים מיידית. כאן פתרון Scale Up פתוח (כמו ZFS) יכול להוות פתרון מעולה תוך שימוש בשרת יחיד שאליו משורשרים מספר JBOD ובתוך אותה מערכת יש מספר קטן של דיסקים SSD מהירים והשאר – דיסקים SATA פשוטים (או SAS או NL-SAS, בהתאם לתקציב) וגדולים מאוד (8,10,12 טרהבייט) עם תצורת RAIDZ שמאפשרת מצב שגם אם 2 דיסקים קשיחים נדפקים, התוכן נשאר תקין בצורה זמינה. זיכרו – סטורג' זה משמש רק לאחסון ולא לעבודה ישירות, כך שעורך שצריך תוכן כלשהו, רואה את הקבצים כ-Read Only ללא אפשרות שינוי. נגמר המקום? מוסיפים JBOD גדול עם 36 דיסקים (לדוגמא) וכל דיסק הוא בגודל 10 טרהבייט, ב-RAIDZ2, הרי שנטו נקבל תוספת של 309 טרהבייט, ואם חברה רוצה ממש אחסון של 1 פטהבייט, אז 4 JBOD כאלו מלאים יתנו 1.2 פטהבייט עם שרידות טובה.

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

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