فرآیند سنجش و انتخاب سخت‌افزار مناسب برای سرور Streaming Media، فرآیند پیچیده‌ای است. پاسخهای متفاوتی برای "چه توانی برای Server خود مد نظر دارید؟" وجود دارد که معمولا پاسخ افراد به آن "حداقل مقدار ممکن یا مقداری که برای انجام کار کافی باشد" است. اگر در انتخاب خود تردید دارید، طبیعی و قابل درک است. از طرفی نمی‌خواهید زیاد هزینه کنید، اما نمی‌خواهید در زمانی کوتاه هم نیاز مجدد به خرید پیدا کنید. چنین پاسخهایی، جای انعطاف و تغییر را باقی می‌گذارد که با ذات منبع محور و غیرقابل پیش‌بینی ارائه سرویس Video Streaming، قابل ترکیب است. اگر از Streaming Engineهای پیشرو در بازار استفاده می‌کنید، محدودیتی در تعداد Stream‌هایی که می‌توانید Transcode یا تبدیل کد کنید، وجود ندارد اما با محدودیت در سخت‌افزار Server و پهنای باندی که Data Center یا تامین کننده Hosting ارائه می‌دهند، مواجه می‌شوید. Transcode به فرآیندی گفته می‌شود که Media و Videoها از فرمتی به فرمتی دیگر تبدیل می‌شوند: مانند Beta به VHS و VHS به QuickTime و QuickTime به MPEG.

خوب، شما هنگام انتخاب Media Server، چگونه میزان توانی که لازم دارید را تعیین می‌کنید؟ در این مورد، عوامل مختلفی نقش دارند که مهمترین آن، ایجاد توازن در دو محدودیت است: پهنای باند شبکه و ظرفیت پردازش.

برخی مواقع، تعداد منابع و در نتیجه Stream‌های شما زیاد است که خود، عاملی برای ایجاد گلوگاه در ارائه Video Streaming است. محدودیت پهنای باند و پر شدن ظرفیت حافظه، باعث می‌شود سرور برای Streaming از حداکثر ظرفیتش استفاده کند. خوشبختانه برای اجتناب از Overload شدن Server، راهکارهایی وجود دارد که در ادامه به صورت چهار نکته بیان می‌شود. این چهار نکته به شما کمک می‌کند سخت‌افزار Media Serverتان را طوری انتخاب کنید که نیازهای Streaming را برآورده کند.

نکته اول: تعیین تعداد Streamingهای ورودی و چگونگی بسته‌بندی آنها

تعداد Streamingهای ورودی خود را تعیین کنید و بدانید که چگونه بسته‌بندی می‌شوند. پردازنده و حافظه، ظرفیت پردازشی سرور را تحت تاثیر قرار می‌دهند، برای جلوگیری از ایجاد Overloadای که به دلیل محدودیت در ظرفیت پردازشی به وجود می‌آید، باید تعداد Streamهایی که سرورتان باید به صورت همزمان پردازش کند را بدانید و بدانید چه میزان RAM لازم است.

میزان Stream برای Transcode 

همه پردازشها به توان پردازشی مشابهی نیاز ندارند. بعد از فهمیدن تعداد Streamهای ورودی که سرورتان باید کنترل کند، باید برنامه Package کردن Streamها برای ارائه را بدانید.

فعالیتهای Encoding و Transcoding (رمزگذاری و تبدیل کد)، ذاتاً پردازشهایی مبتنی بر پردازنده هستند. برای مثال، اجراء بعضی چیز‌ها مثل (Flash Media Live Encoder) FMLE، در محیط Desktop، حتی تا 80% از پردازنده استفاده می‌کند. به هر حال، مقدار پردازنده لازم برای انجام فعالیتهای سنتی تبدیل کد، متفاوت است. تبدیل کد، یا به تغییر Codecها (مثلا تبدیل VP8 بهH.264 ) یا به Transrating Stream برای دسترسی به Adaptive Bitrate (ABR) اشاره دارد (برای مثال، تبدیل Single Bitrate Stream به چهار نسخه). هر دوی اینها از پردازنده استفاده می‌کنند اما تغییر  Bitrate Stream برای ارائه  ABR، پردازنده بیشتری استفاده می‌کند. گاهی اوقات هم ممکن است Stream فقط  (Transmuxe (Transcode-Multiplexin)شود (مثلا تبدیل RTMP به HLS). این فرآیند را Pass-Through Processing  می‌نامند: یعنی کاری که پردازنده بسیار کمتری برای Packaging لازم دارد. اگر لازم است که چندین Stream را برای ارائه ABR تبدیل کد کنید به سروری با ظرفیت پردازشی بیشتر نیاز دارید. تعداد Streamهایی که Server می‌تواند تبدیل Code کند، بسیار متفاوت است. با این حال ما در اینجا سرور‌ها و حجمهای کاری رایج را بررسی می‌کنیم تا کاربران را در شناخت آنچه نیاز دارند، کمک کنیم. در شکل زیر، پیکربندی ساده‌ای برای Broadcast OTT ارائه شده است.

Broadcast OTT:

Processor: Single Quad Core 4GHZ i7 6700K

RAM: 16GB

OS: Windows 10 (64-bit)

With this configuration, our testing indicates you cloud:

1- Accept seven inbound 1080p stream at 9.7 MB/PS

2- Transcode four renditions for each incoming stream at 160p, 240p, 360p and 720p

 چقدر RAM لازم دارید؟

حافظه مصرفی در فرآیند‌های دریافت و بسته‌بندی، معمولا با کل تعداد اتصالات Stream ورودی، که به صورت فرآیندهای Java، قابل مشاهده هستند، ارتباط دارد: هرچه Streamها و منابع ورودی بیشتر باشد، سرور شما به ظرفیت پردازشی بیشتری نیاز دارد. مثلا در نصب Wowza Streaming Engine ، نسخه سروری لازم برای (Java Runtime Environment (JRE، به صورت خودکار، نصب می‌شود. بعضی از گزارشهای کاربران سخت‌افزارهای سنتی، حاکی از آن است که JRE، استفاده از RAM را تا ۸ گیگابایت محدود می‌کند، هرچند نصب سخت‌افزار مدرن می‌تواند تا ۱۶ گیگابایت را فراهم کند.

تنظیمات پیش‌فرض در Wowza Streaming Engine برابر با ۱۰ گیگابایت است، اما این مقدار را می‌توانید در XML به حداکثر ۱۶ گیگابایت به ازاء هر سخت‌افزار، ویرایش کنید. معمولا رساندن پیکربندی رم به ۳۲ گیگابایت، برای هماهنگ کردن تعداد زیادی از منابع ورودی، مناسب است.

نکته دوم: تخمین حداکثر همزمانی Streamها در سرور شما

ارتباط بین Stream Bitrate و پهنای باند، بسیار شبیه به ارتباط ورودی و خروجی است که البته در سمت خروجی، چالش بیشتری وجود دارد. چرا؟ همیشه هم حدس زدن تعداد بینندگانی که دارید و یا نسخه‌هایی که آن بینندگان نیاز دارند، راحت نیست. برای اجتناب ازOverload‌های مرتبط با پهنای باند، حداکثر پهنای باند خروجی که در سرور باید کنترل شود را تخمین بزنید. مثال ساده‌ای برای روشنتر شدن مطلب ارائه می‌دهیم.

فرض کنید از Datacenter استفاده می‌کنید که حداکثر ظرفیت توان عملیاتی2 GB/s  را فراهم می‌کند. اگر بخواهید بر اساس قانون 80% بالا عمل کنید، باید برای داشتن حداکثر پهنای باندی با سرعت 1.6 GB/s، برنامه‌ریزی کنید. برای اینکه بدانید چه تعداد Stream را می‌توانید با سرعت 1.6 GB/s تنظیم کنید، باید ابتدا میانگین اندازه Stream که به مخاطبان ارائه خواهد شد را مشخص کنید. یادتان باشد، متوسط رزولوشن Stream مخاطبان شما، می‌تواند با رزولوشن Stream اصلی شما متفاوت باشد. اگر Stream اصلی را به نسخه‌های کوچکتر، تبدیل کد کنید. ممکن است مخاطبان، Stream را 40% کوچکتر از Stream اصلی مشاهده کنند (در مورد Streamهای خروجی، به اندازه Stream که متوسط مخاطبان می‌بینند، توجه می‌کنیم). سه فریم در ثانیه را در نظر بگیرید. برای اندازه Stream به جدول زیر توجه کنید:

Streaming Bitrate	Stream Resolution
21-50Mbps	8k
13-34Mbps	4k
3-6Mbps	1080P
1.5-4Mbps	720P
0.5-2Mbps	420P
0.4-1Mbps	360P

با استفاده از اندازه Stream متوسط مخاطبان، با قاطعیت می‌توانید پهنای باند مورد نیاز خود را تعیین کنید. برای این کار Stream Bitrate را در حداکثر تعداد Streamها ضرب کنید که حاصل باید از 80% کل پهنای باند در دسترس کمتر باشد:

Stream Bitrate * Number of Peak Concurrent Streams < 80% of Total Available Bandwidth

در ادامه با مثالی همراه باشید: در اینجا چند سناریو‌ برای حداکثر ارتباطات وجود دارد که اندازه Stream متوسط مخاطبان، مقادیر متفاوتی دارند.

Total Pipe	Useable Bandwidth	Outbound Bandwidth	Total Viewers	Average Viewer Stream Size
2Gbps	1.6Gbps	1.55Gbps	258	1080P@6Mbps
2Gbps	1.6Gbps	1.55Gbps	775	720P@2Mbps
2Gbps	1.6Gbps	1.55Gbps	3.100	این آدرس ایمیل توسط spambots حفاظت می شود. برای دیدن شما نیاز به جاوا اسکریپت دارید

به خاطر داشته باشید که باید پهنای باند Stream ورودی خود را حساب کنید. این مقدار، معمولا درصد کوچکی از تمام Streamهای همزمان شما خواهد بود. در سناریو‌هایی با تعداد زیادی Broadcastهای یک به یک یا یک به چند، پهنای باند Streamهای ورودی می‌تواند اضافه شوند. در نهایت، اگر این محاسبات نشان دهد که پهنای باند سرور شما کافی نیست، می‌توانید از CDN استفاده کنید تا Streamهایی را برای هر تعداد مخاطب فراهم کنید. مثالی از Content Delivery Network یا شبکه ارائه محتوا، Wowza CDN است. قابلیتهای Stream Targets این امکان را می‌دهد تا یک Stream یا گروهی از نسخه‌های Stream تبدیل کد شده را از Wowza Streaming Engine گرفته تا Wowza CDN، برای هر تعداد از مخاطبان ارسال کنید.

نکته سوم: انتخاب مدل درست پیاده‌سازی

نکته‌ای دیگر که باید به آن توجه شود این است که، چه در زیرساخت ابری نصب و راه‌اندازی شود و چه به صورت On-Premise، از فضای سخت‌افزاری Server استفاده می‌شود. راه‌اندازی Cloud مزایایی مانند استفاده از منابع کارآمد و صرفه‌جویی در مخارج کلی دارد. با این وجود، زیر‌ساخت ابری از مجازی سازی و مدیریت منظم انبوهی از منابع  که به شکل سنتی به منابع فیزیکی مانند CPU، Network و RAM اضافه می‌شوند، استفاده می‌کنند و وقتی با فعالیتهای رایج ذخیره سازی ترکیب می‌شود، حجم سرویس‌دهی در ماشین مجازی را کاهش می‌دهد. از طرفی دیگر، پیکربندی Bare-Metal، ظرفیتهای پردازشی بزرگتری را فراهم می‌کند. در سرور Bare Metal، شما می‌‎توانید انتظار استفاده از حداکثر 80% از کل پهنای باند شبکه و حتی درصد بالاتری از پردازنده را داشته باشید. این مورد، قابل مقایسه است با راه‌اندازی مجازی و ابری که قابلیت استفاده از پردازنده تا 65% و شبکه در دسترس نیز حدود 50% افزایش می‌یابد. در حالیکه مزیت پیکربندی Bare-Metal، دسترسی به منابع بزرگتر است. محیطهای ابری و مجازی، منعطف و کاربرپسند است و قابلیتهای Self-Service ارائه می‌دهد. برای بسیاری از مردم، این مزایا به معایب آن می‌ارزد.

نکته چهارم: استفاده از GPU Offload و CDN

برای اینکه از حداکثر ظرفیت پردازشی سرور خود استفاده کنید، قابلیتهای زیرساختی وجود دارد که شما می‌توانید از آنها استفاده کنید: GPU Offload و CDNها.

ارتباط  GPU Offload و شتاب‌دهی

Wowza Streaming Engine، استفاده از GPU offload در تبدیل‌کننده های کد (Transcoder) را پشتیبانی می‌کند بنابراین می‌توانید توان پردازشی خود را به حداکثر برسانید. با استفاده از GPU Scaling، کاربران هر دو پیکربندی Cloud و Bare-Metal، می‌توانند تا 75% از پردازنده را در تبدیل کد حجمهای کاری Offload کنند. (یعنی پردازش را از دوش CPU برداشته و بر روی GPU قرار دهند)

در لیست بالا که با عنوان پیکربندی ساده‌ای برای Broadcast OTT می‌بینید، با فعال کردن GPU scaling، استفاده از CPU را از 68% به 43% کاهش می‌دهد. با پیشرفتهایی که در GPUهای Wowza Streaming Engine ارائه شده، استفاده کمتر از CPU-Workload فراهم شده است: در بعضی موارد، بیش از 90% کاهش در CPU-Workload، امکانپذیر است.

Content Delivery Network یا CDNها

بکارگیری Streamها در CDN یکی از رایجترین راهها برای حذف گلوگاه (Bottleneck) در سرور است. با استفاده از CDN، برای هر نسخه، Stream خروجی را به یک تک Stream، کاهش می‌دهد.

همانگونه که اشاره شد، می‌توان از قابلیتهای Stream Targets در Wowza Streaming Engine استفاده کرد تا Single Stream و یا Stream چند بیت ریتی را در Wowza CDN قرار داد تا به دست عموم مخاطبان برسد. این کار حجم کار را از سرور شما برمی‌دارد تا Stream برای تعداد بیشتری از مخاطبان به طور همزمان، قابل نمایش باشد و در عین حال دیگر نگرانی از بابت پهنای باند نخواهید داشت.

نکته مهم، پیکربندی CDN است که باعث افزایش چشمگیری در تعداد درخواستها از سرور Wowza Streaming Engine می‌شود این پیکربندیها شامل Cache Miss Ratio و (Time-To-Live) TTL برای محتوای کش شده است.

کلام آخر:

هر چند که ممکن است این نکات، قطعی و کامل نباشد اما امیدواریم کمک کند تا گزینه‌های پیش رو و منابع سرورتان را به طور مناسب انتخاب کنید. توصیه ما به شما این است که حتی پس از سنجش معیارهای انتخاب، کارائی را تحت Loud، تست کنید و یا از مجازی سازی استفاده کنید که امکان هماهنگی و افزودن منابع را به شما می‌دهد.