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

כשצריכים אחסון מהיר (SSD) מקומית

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

להלן 2 תחומים שונים לחלוטין שמצריכים גישה מקומית מהירה לנתונים ופתרון של אחסון רשת (NAS/SAN) בין במהירות 1 ג'יגהביט או 10 ג'יגהביט – לא ממש תספק.

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

אבל בואו ניקח עורך וידאו מקצועי, אחד כזה שצריך לערוך ערימות של קליפים מכמה מצלמות שצולמו במקביל/בזמנים שונים – בפרויקט, להשתמש בפרמייר ואפטר ואולי בעוד כמה תוכנות. במקרה של תחנות עבודה יש כאלו שיקנו מארז 1U עם 4 דיסקים וחיבור SFF-8088, יתקינו כרטיס RAID במחשב ויעבדו. אחרים ירכשו לעצמם NAS קטן של Synology או QNAP עם 4 דיסקים, יתחברו בחיבור של 1 ג'יגהביט דרך סוויצ' קטן וכך הם יעבדו.

נעבור מכאן לדוגמא שניה: מישהו שעובד על Deep Learning. יש לו אלפי תמונות או תכנים שונים שהוא צריך להריץ אותם כ-Training עם האלגוריתמים שהוא כותב/משתמש. כאן הפתרונות הידועים יהיו בערך כמו של העורך וידאו או במקרה של עבודה בחברה – יהיה חיבור רשת ל-NAS/SAN בחברה ושהחומר יאוחסן שם.

ב-2 המקרים, הפתרונות הללו פשוט איטיים. חיבור של 1 ג'יגהביט יתן מהירות של 100-110 מגהבייט לשניה וחיבור של 10 ג'יגהביט יתן חיבור של 1 ג'יגהבייט לשניה. יש כמובן את כל הקופסאות החיצוניות האלו שניתן להכניס בהם 2/4/8 דיסקים וניתן יהיה לחשוב שתקבלו מהירות יותר גבוהה מקומית, אבל בד"כ עיון במפרטים של הציודים האלו מראה שהיצרן נותן חיבור של USB 3.0 (שם מקבלים מקסימום 600 מגהבייט לשניה) או חיבור eSATA (שכבר מת מהעולם) ששם מקבלים מהירות של .. 500 מגהבייט לשניה בערך.

בדרך כלל הפתרון שאני מציע, הוא להשתמש בפתרון "כלובים" (Cage) – פתרון כזה נכנס לתושבת 5.25" במכונת דסקטופ (איפה שהיה פעם CDROM/DVD-ROM).

ניקח לדוגמא את הפתרון (הישן יותר) של חברת Icy Dock. קופסא כזו יכולה להכיל 8 דיסקים SSD (כשכל SSD יכול להכיל עד 2 טרהבייט). את הקופסא הזו אנחנו מכניסים היכן שהיה ה-CD-ROM או במקום בגודל זהה פנוי במחשב, ובצד האחורי אנחנו מחברים 2 חיבורי כח של SATA ואת כל חיבורי ה-SATA אנחנו מחברים אל לוח האם או אל כרטיס RAID זול ופשוט (כמו זה שעולה 103 שקל ומשלוח חינם מחו"ל. אפילו לא תצטרכו לשלם מיסים/מע"מ על זה). כשמפעילים את המחשב יופיעו מספר שורות לפני עליית מערכת ההפעלה ללחוץ מקש מסוים (אם רוצים) וכשלוחצים מופיעה אפליקציה קטנה ופשוטה להגדיר RAID מהדיסקים שהכנסנו. לאחר שנשמור את ההגדרות והמחשב יופעל מחדש, במערכת ההפעלה שלנו נוכל להגדיר "כונן" חדש שיורכב מהדיסקים שהגדרנו וכל מה שנותר לנו לעשות זה פשוט להעתיק את התכנים לתוך אותו "כונן" חדש, ולאחר שסיימנו עם הפרויקט – להעביר אותו לאחסון האיטי. תיאורתית מארז כזה יכול להכיל עד 16 טרהבייט של מקום.

והמהירות? מבחינת קריאה – תקבלו מהירות של 4 ג'יגהבייט לשניה (לא ג'יגהביט), ומבחינת כתיבה – זה תלוי ב-SSD שתכניסו ותלוי כמה תשקיעו ב-SSD טוב. בכל מקרה המהירות כתיבה תהיה יותר גבוהה מאשר כתיבה לדיסק מכני.

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

התנסיתי בעבר עם מספר מוצרים של החברה לגבי כונני SSD ולהלן 3 מוצרים שאני יכול להמליץ עליהם:

  • דגם MB998SK-B – בדגם זה משתמשים בכבל SFF-8087 שמתפצל ל-4 חיבורי SATA (כך שצריך 2 כבלים כאלו ל-8 דיסקים) ויש צורך בכרטיס RAID כזה לדוגמא.
  • דגם MB608SP-B – כמו הדגם הקודם אבל ל-6 דיסקים, יש צורך באותם כבלים ובקר RAID.
  • דגם MB998IP-B – כמו הדגם הראשון אבל עם חיבור יותר מודרני של SFF-8643. כאן יש צורך בכרטיס RAID כמו זה. דגם זה, אגב, אמור להגיע ארצה במהלך השבועות הקרובים.

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

שימו לב: ישנם ב-eBay ו-Ali Express פתרונות שנראים זהים, אך עם מאוורר יחיד. עם SSD יש צורך בקירור טוב עם 2 מאווררים (ואם רוצים שקט כמעט מוחלט, אגב, אפשר להחליף עם המאווררים של Noctua) – ואני לא ממליץ עליהם הואיל והם אינם מוציאים חום בצורה טובה, מה שיגרום לדיסקים SSD להאט את מהירותם על מנת שלא לשרוף את הלוח SSD.

למעוניינים לרכוש את הקופסאות פה בארץ, ניתן לפנות לחברת דיגיטל מאסטר טכנולוגיות – היבואנית של IcyDock בארץ. למי שמחפש דיסקים SSD טובים ולא סופר-יקרים, אני יכול להמליץ על Crucial שניתן לרכוש מחברת CRG. (הערה: הפוסט או ההפניה אינם מקנים לי אחוזים במכירות כלשהן).

לסיכום: הכל מתחיל ונגמר ב-Work Flow שלך. אם תרצה להשקיע ולרכוש פתרון כזה ולעבוד איתו, תוכל להאיץ את העבודה שלך. כיום ישנם SSD שקיימים בשוק הביתי/סמי-מקצועי שכבר אינם כה יקרים, ופתרון כמו שהצעתי יכול גם לסבול (תלוי בהגדרות RAID) דיסק או 2 תקולים ועדיין להמשיך לעבוד.

על בעיה X ופתרון Y

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

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

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

  • מה הפונקציונאליות שהוא מחפש
  • מה הפונקציונאליות שמאוד חשובה לו, ומה הפונקציונאליות שבשבילו זה יהיה "נחמד" אם קיים אך אותה פונקציונאליות אינה קריטית.
  • האם הוא מחפש פתרון Scale Up או Scale Out
  • האם הוא מחפש פתרון שישולב כ-Hyper Converge או שהוא מחפש פתרון של ברזלים נפרדים
  • ויש עוד לא מעט שאלות…

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

  • אינטגריטי – אם מישהו יבוא אליי ויבקש לדוגמא פתרון סטורג' Scale Out והדבר הכי חשוב לו זה iSCSI לדוגמא, אז אני אומר לו בפשטות שכרגע אין פתרון Scale Out בקוד פתוח (גם כמוצר מסחרי) שיש לו פתרון iSCSI ל-Scale Out בצורה טובה והוא יצטרך פתרון קנייני.
  • על מה הפתרון אמור לענות? לקוח רוצה X על מנת לפתור את בעיית Y. נעזוב לרגע את X, ונשמע מהלקוח מהו אותו Y. אין ספק, דרישותיו של הלקוח הן חשובות, אולם ברגע שמספרים לי מהו אותו Y, אז ניתן להעלות מספר פתרונות שיכולים לענות על Y וגם להתחשב בצרכי הלקוח.
    לדוגמא: ללקוח יש 20 מכונות VM שמשמשות לפיתוח והלקוח רוצה פתרון סטורג' עבורם Scale Up. במקרה כזה אני יכול להציע לדוגמא פתרונות מבוססים ZFS, בין אם כקוד פתוח נטו או מוצרים מסחריים ובהצעה שאגיש לו יוסבר מדוע הפתרון הזה טוב ויוצעו ללקוח מספר פתרונות מבוססים ZFS, כך שבסופו של דבר ה-Y הם אותם 20 מכונות VM וה-X יהיה פתרון מבוסס ZFS.

וכאן בעצם מגיעה השאלה המרכזית שלי…

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

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

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

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

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

כשצריכים לבחור Storage לסטודיו

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

אותה חברה החליטה לעבור ל-NAS אחר ובאותה הזדמנות לעבור לחיבור 10 ג'יגהביט לכל מכונות הדסקטופ.

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

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

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

הדבר הראשון שצריך לקחת בחשבון הוא בעצם את החומר שאנחנו הולכים לערוך וליתר דיוק – בכמה מגהביט מוקלט הוידאו. יש הבדל עצום בין וידאו שמוקלט ממכשיר טלפון סיני, מאייפון או גלקסי – לבין מצלמות DSLR מקצועיות, מצלמות וידאו מקצועיות (כמו Sony) ומצלמות RED בדחיסה נמוכה. המצלמות הפשוטות בטלפון מקליטות ב-10-20 מגהביט ואילו RED יכולות להגיע בערך ל-300 מגהבייט לשניה ואני מאמין שיש מצלמות שמקליטות במגהביט יותר גבוה.

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

כלל האצבע הוא: ככל שהמגהביט בהקלטה יותר גבוה, ויש יותר אנשים שצריכים לעבוד במקביל על הפרויקטים – הציוד ל-NAS יהיה יותר יקר (כמה יותר יקר? כל דיסק NVME SSD לעומסים כאלו עולה בין 1000-1500$) ולכן יש צורך לבדוק פר מקרה מה החומרים, לאן גודלים, כמה עורכים יש, האם יש עבודה במקביל ועוד ועוד. קניה של NAS ספציפי רק כי יש כזה לשכן ממול – לעניות דעתי, אינה החלטה חכמה.

ובנוגע לרשת שהחבר'ה ב-FStoppers הקימו, לו היו החברים קוראים את הסטנדרט בגירסה הקצרה, הם היו מוצאים שהכבלים שהם רכשו, ולא חשוב מאיזה פירמה – לא יתנו תמיד 10 ג'יגהביט הואיל ו-CAT7 מספק 10 ג'יגהביט עד אורך 100 מטר, לא 200. בשביל 200 מטר יש צורך להשקיע בכבלים CAT 7A או ברכישת כבלים מוקשחים (כאלו שמכניסים בקירות).

שידור וידאו: על קידוד וצרות של רוחב פס ומחיר (חלק 2)

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

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

  • חברת HOT: הערוצים המתורגמים משודרים דרך מערכת הכבלים עם מערכת DOCSIS כאשר ישנו מרכז בקרה שמשדר את הדברים המוקלטים/מתורגמים מהמרכז דרך המערכות החוצה לגולשים. מערכת ה-DOCSIS היא מערכת מעולה לדברים האלו והחיבור הקואקסיאלי של הכבלים מאפשר שידורים ו-DATA ברוחבי פס פנומנליים. עם DOCSIS 4 לדוגמא, אפשר להגיע למהירות חיבור אינטרנט (ושידור) של 1 ג'יגהביט פר בית! (במאמר מוסגר אציין כי יש לי השגות לגבי ההגדרות שמגדירים בארץ. צפיתם פעם בכבלים ופתאום התמונה קפאה או שראיתם קוביות? על זה אני מדבר). לעומת זאת הערוצים המוזרמים ישירות מחו"ל (CNN, ערוצי ספורט זרים, ערוצי סדרות בשפות זרות וכו') נקלטים בצלחות לווין גדולות בעמק האלה ומועברים דרך כבלי תקשורת למרכז בראש העין ומשם לצופים.
  • חברת Yes: בחברת Yes הדברים מעט שונים. לכל לקוח יש צלחת לווין והלקוח קולט דרכה את כל השידורים שהחברה מנגישה ללקוחותיה. שידורים מתורגמים מועלים דרך צלחת לווין שלהם והשידור נקלט על ידי צלחות הלווין של הלקוחות.
  • עידן/עידן+ – עד לפני מס' חודשים, השידורים בעידן היו שידורים אנלוגיים באיכות SD. החל מחודש מרץ 2017 בעידן עברו סוף סוף לשידור/קליטה עם DVB-T2 שמאפשר קליטת שידורים עד Full-HD אולם למעט ערוץ 1 (שמשדר ב-HD, לא Full HD) השאר עדיין משדרים ב-SD וכפי הנראה בקרוב יעברו לשדר ב-HD או Full HD. עוד פרטים תוכלו לקרוא באתר המצוין GoDigital.

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

כשזה מגיע ל-SD, HD ו-Full HD, אפשר לאמר פחות או יותר שהתעשיה בישראל הסתדרה, אבל אז מגיעה לה בעיית ה-4K (לא נדבר על כאן על 8K שחברה כמו NHK משדרת ביפן ועוד בשידור חי!) והבעיה היא רוחב פס. ל-HOT אין ממש בעיה כי הכל נחשב כ"תשתית פנימית", אולם ל-Yes ועידן יש ויש בעיה: שידור 4K עם אודיו 5.1 דורש רוחב פס של פי כמה וכמה בהשוואה להיום, שלא לדבר על כך ש-VOD דרך האינטרנט הוא בעייתי בישראל הואיל וחיבור האינטרנט הוא א-סינכרוני כך שכל העלאה של תכנים ע"י אחד מתושבי הבית או שימוש נרחב של תושבי הבית באינטרנט (צפיה ביוטיוב, משחקים אונליין וכו') די מהר "חונקת" את חוויית הצפיה ב-4K (אתם מוזמנים לנסות זאת בחבילת ה-4K של נטפליקס), ומה קורה עם עידן/עידן+? לא יכולים עם DVB-T2 לתמוך ב-4K בכלל, עד שיצא DVB-T3 עוד שנה וחצי כמדומני.

גם בארצות אחרות כמו ארה"ב הבעיה לא פחות חמורה מאצלנו. שם כבר משדרים רוב הזמן HD (ובחלק מהמקרים FULL HD) אולם כשזה מגיע ל-4K, מאפשרים זאת דרך האינטרנט בלבד באתרים יעודיים של הרשתות או רשתות VOD מבוססות אינטרנט כמו Netflix, CBS Access או Amazon וידאו וכו'.

הבעיה המרכזית של כולם זה שהם רוצים לשדר 4K אך עם רוחב פס של SD. הם מוכנים לעשות החלפה של כל הציוד (כולל הממירים בבית, תחום שהיה להם קרב לא קטן עם ה-FCC בשנה שעברה) אבל הם לא רוצים בעיות של רוחב פס בין אם בשידור לוויני או שידור תכנים דרך האינטרנט בחיבור DSL או אחר, ולכן רובם לא עברו ל-4K ורק חלק קטן משדר ב-Full HD.

בשביל זה צריך מקודד טוב. האם יש? כן, הוא נקרא H.265 (או HEVC) אך הוא סובל ממספר בעיות:

  • הוא עדיין לא מאפשר שידור 4K ברוחב פס של SD עם אודיו 5.1. הוא צורך פחות רוחב פס מ-H.264, אבל בשבילם (במיוחד בארה"ב) זה לא מספיק.
  • הבעיה הכי גדולה: כסף, או ליתר דיוק – תמלוגים והגוף האחראי על התמלוגים (MPEG-LA) דורש סכומים שלדעת כל הגופים שרוצים להשתמש (ומשתמשים) ב-Codec – הסכומים מאוד גבוהים.

מי שכן עשה משהו בנידון היו חברות הצפיה בוידאו ברשת כמו Netflix ואמזון, שאימצו מקודד חדש שמגיע מגוגל בשם VP9. המקודד נמצא בשימוש כשמורידים תכנים לטלפון/טאבלט ולאט לאט הם מכניסים אותו לשימוש בצפיה ישירה. יש עוד "לקוח" שמשתמש בצורה כבדה מאוד ב-VP9 יחד עם מקודד האודיו Opus. אולי שמעתם עליהם – יוטיוב. ברוב המקרים זה הפורמט שיוטיוב מגישים לגולשים למעט במקרים של דפדפן אקספלורר, ודפדפן ספארי (שתומך עד H.264). יותר מכך, בהשוואה שנערכה בין H.265 ל-VP9 מול H.264, הצליחו 2 המקודדים לתת ב-Bitrate יותר נמוך תוצאות יותר טובות מאשר ב-Bit Rate גבוה של H.264.

גם VP9 וגם Opus נכנסים תחת פורמט הקונטיינר WebM, והפורמט נתמך בדיוק באותם מקומות כמו שיוטיוב נתמך, כך שאם חושבים להקים תשתית כזו, רוב המשתמשים יוכלו לקבל וידאו ואודיו / אודיו בלבד – ברוב המכשירים כאשר ניתן להוסיף FallBack ל-H.264 (או AAC או MP3 במקרים של אודיו בלבד).

ישנו עוד מקודד אחד שכל החברות הידועות (גוגל, מיקרוסופט, מוזילה, נטפליקס, אמזון, אדובי, הולו וכמובן חברות חומרה כמו AMD, ARM, nVidia, סיסקו, ברודקום ואינטל) עובדים יחד תחת עמותת המלכ"ר Alliance for Open Media. שם המקודד: AV1. המטרה? ליצור משהו יותר טוב בהרבה מ-H.265 ללא צורך בתשלום על תמלוגים. פשוט תטמיע ותשתמש.

אבל זה לא נעצר כאן: מקודד AV1 כבר כיום (מי שרוצה לנסות את המקודד, אהלן וסהלן, נדרש ידע בלינוקס וידע עמוק בשימוש במקודדים) מוביל על HEVC והתוצאה שחברות השידור המסורתיות רוצות לראות – 50% מרוחב הפס של H.265, כלומר רבע מ-H.264 – ואז האימוץ יחל. כבר כיום טלפונים כמו גלקסי S8 ו- +S8 תומכים ב-AV1 (לא בברירת מחדל) ומכשירים סלולריים רבים יתמכו בו, חברות השידור באינטרנט כבר עושות ניסויים על AV1 וישחררו תמיכה בו ברגע שהוא יצא, דפדפנים כמו כרום, פיירפוקס ו-Edge יתמכו בו וכל מי שלא יתמוך בו יעמוד בפני אפשרות של שימוש ב-AV1 איכותי ללא תשלום תמלוגים לשידור, או תשלום מחירים גבוהים ל-MPEG-LA עם H.265. אתם יכולים לנחש את ההמשך.

אז האם כדאי לעבור ל-VP9/Opus? זה תלוי.

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

לעומת זאת, חברות שידור אינטרנט שלהם אין ציוד בחוץ בכל מיני מרכזים וממירים ללקוחות – יכולים להמיר קבצים ל-VP9, כפי שציינתי לעיל – הצצה ביוטיוב עם דפדפן כרום/פיירפוקס/Edge תראה לך מה זו איכות של VP9 – ובכך להנות בחסכון ברוחב פס (כשמקודדים ב-Bit Rate יותר נמוך אך עדיין שומר על איכות כמו H.264) ובגודל הקבצים אם אתם מאפשרים הורדת הקבצים ללקוחות (אפשר להשתמש ב-DRM כמו של Widevine כדי להגן על התוכן).

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

 

שידור וידאו: על קידוד וצרות של רוחב פס ומחיר (חלק 1)

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

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

בעבר אתרי אינטרנט רבים העבירו שידור וידאו או קליפים בקידוד WMV של מיקרוסופט או VC, או VCM בחלק הקטן מהמקרים, אולם כיום כולם (למעט אתרים שלא עודכנו שנים ועדיין חושבים שהעולם הוא עדיין ברובו משתמש במיקרוסופט) עברו לשדר בקידוד של MPEG-4 עם פרופיל Base או Main והאודיו מגיע או כ-AAC או כ-MP3. היתרונות של מקודדים (Codecs) אלו הוא בכך שכל מערכת הפעלה, טלפונים סלולריים וטאבלטים – תומכים בכך וכל מי שמשדר מעוניין להגיע לכמה שיותר קהל מבלי שהגולשים יצטרכו להתקין אפליקציות/תוספים מיוחדים, מה שגורם במקרים רבים לתקלות ולאנשים שאין להם תמיכה והם נוטשים וממשיכים הלאה.

אז כיצד בעצם אפשר לדחוס יותר משתמשים על אותו רוחב פס?

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

אבל יש פתרון אחר, שכולו קוד פתוח ונתמך בפלטפורמות כמו Wowza ואחרים (כן, גם במערכות בלוגים כמו WordPress) שנקרא Opus שמגיע מ-קרן Xiph ומהנדסים רבים בעולם עובדים בהתנדבות בזמנם הפנוי על פיתוחו. גירסה 1.2 (ו-1.2.1) שוחררה לא מזמן. אתם יכולים להיכנס לדף הזה, לגלול לאמצע ולבחור בקידוד וב-Bit Rate. אני ממליץ לבחור שם Opus 1.2 עם 32 קילוביט לשניה ולנגן ותתרשמו בעצמכם מהאיכות.

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

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

אז מה עושים? לשמחתנו ב-HTML5 יש אפשרות לקבוע Fallback כך שאם הציוד של הלקוח אינו תומך ב-Opus, הוא יועבר לגירסה ב-MP3 או AAC.

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

מה רע? 🙂

בפוסט הבא נדבר על ה"חבר" של Opus – קידוד וידאו VP9.

Exit mobile version