CEPH – הבלוג של חץ ביז

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

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