שרת קבצים ווידאו: כך חוסכים I/O יקר מפז בעשר דקות עבודה

6 בנובמבר 2012

תגיות: , ,
2 תגובות

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

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

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

נשארנו עם בעיית חומרה: מערך הדיסקים או ה-Storage פשוט לא מהיר מספיק.

המשותף לכל המקרים היה, קבצי וידאו/התמונות סופקו למערכת משרת קבצים או NAS. במקרה של אלו מבוססי לינוקס, השלב הבא היה להפעיל שם את פרוטוקול SMB2 על ידי התקנה של Samba בגרסה מעודכנת ושינוי קבצי ההגדרות בהתאם – זה הועיל, אבל לא פתר את הבעיה.

אני לא התייאשתי, ונזכרתי של-IIS יש אפשרות ותיקה בשם Kernel Cache, כלומר שמירת קבצים סטטיים בזיכרון.
החלטתי ללכת על פתרון  Reverse Proxy ולנצל את האפשרות הזו.
האמור כאן מכוון כלפי IIS, אבל יעבוד על כל שרת Proxy תומך אחר, כולל Apache, Squid, Nginx ואחרים.

השלב הראשון היה התקנת שרת HTTP כלשהו בשרת הקבצים.

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

אם מדובר בוידאו, כדאי להפעיל ולהגדיר נכון את BitRate Throttling, כדי לחסוך בתעבורה ו-I/O יקרים.

כעת נעבור למסך Output Caching, גם כן ב-IIS.
תחת האפשרות Edit Feature Settings, נסמן את Enable cache, Enable kernel cache, ונשנה את המספרים שבברירת המחדל, לכמה שיותר – בהתאם להגיון וכמות הזיכרון שיש לנו.

בשלב הבא צריך להתקין את IIS Application Request Routing. לאחר שיותקן ניגש לאייקון Application Request Routing, ונפעיל משם את הפרוקסי (תחת האפשרות Server Proxy Settings).
בהתאם לכמות הזיכרון, נשנה את זמן השהיה בזיכרון (Memory cache duration) למשהו יותר סביר מדקה, ובהתאם לתשתית – לאפשר Disk cache.
חשוב מאוד לאפשר Request Consolidation – חוסך עוד קצת I/O.
Apply.

עכשיו נשאר רק להגדיר Rewrite Rule שישתמש בפרוקסי. לא ארחיב על זה כאן אבל יש מדריכים מתאימים בשפע.

השלב הבא יהיה לבדוק ש-Kernel Cache עובד.
נפעיל שורת פקודה, ונכתוב שם:

C:\Users\Administrator>netsh http show cachestate | more

Snapshot of HTTP response cache:
--------------------------------

URL: http://internallink/filename2
Status code: 200 HTTP verb: GET Cache policy type: Time to live Cache entry Time to Live (secs): 31536000 Creation time: 2012.10.31:13.55.52:0 Request queue name: DefaultAppPool Content type: video/x-ms-wmv Content encoding: (null) Headers length: 346 Content length: 690299 Hit count: 310 Force disconnect after serving: FALSE URL: http://internallink/filename Status code: 200 HTTP verb: GET Cache policy type: Time to live Cache entry Time to Live (secs): 31536000 Creation time: 2012.9.3:6.47.21:0 Request queue name: DefaultAppPool Content type: video/x-ms-wmv Content encoding: (null) Headers length: 347 Content length: 1473071 Hit count: 209 Force disconnect after serving: FALSE ...

אם הכל הוגדר כהלכה, נראה פה קבצים במלוא אורכם, המסופקים מתוך הזיכרון של השרת מספר הפעמים שב-Hit count.

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

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

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

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

2 תגובות

  1. אבי קינן8 בנובמבר 2012 ב 21:47

    משה תוכל לפרט על גודל הקבצים, אורך הקבצים הממוצע וכמות הבקשות בשעות העומס?

    אני עובד עם nginx עם כמה שרתי וידאו, לקבצי flv/mp4, עם כונני SAS ובקר RAID (עם CACHE מופעל) ועד כה ללא בעיות.

    אבי

    הגב
  2. משה9 בנובמבר 2012 ב 10:41

    גודל הקבצים – 1-100MB – וידאו
    פרט שלא צוין בפוסט – מדובר במכונה וירטואלית שיושבת על מערך אחסון שעליו יושבים עוד 20 שרתים, כולל בסיסי נתונים עמוסים – כך שה-I/O שלה הוא יקר.

    שעות העומס זה אומר שמצפים ממנה לספק כ-200-250Mbps, שוב – כאמור – כאשר ה-I/O אינו רק שלה.
    הדרישה לעבור למכונה פיסית או לשדרג את מערך האחסון הייתה כרוכה בתקציב לא קטן בכלל.

    יתרה מזאת – במקרה של קבצים משיתופים (למשל כשמשתמשים ב-NAS), אין בכלל שימוש ב-OS Cache, מה שמחמיר את העומס על ה-I/O היקר מפז.

    אני משער שאתה משתמש בשרת פיזי כשהקבצים נמצאים עליו, ועוד כונני SAS יקרים, אם ככה – סיכוי סביר ש-OS Cache יעשה את העבודה מצויין כל עוד יש מספיק זיכרון.
    כשרוצים לעבוד עם SATA בגלל נפחם העדיף ומחירם הזול, זה כבר מורכב יותר, ואז פיתרונות כאלה מועילים.

    הגב