We are looking into using Wowza in 2 use cases, and wonder how we can handle the scaling challenge in each of them.
In this deployment we have a lot of video files stored in S3 and would like to deploy a cluster of Wowza servers that will allow playing them.
We configure Wowza to read the video files directly from S3 as described in the Wowza documentation.
The clients are RTMP/T/S clients.
In this use case, we expect many unique clients accessing the video files, when each video file is played a few times only (hence no CDN functionality required).
The question is how to build the Wowza cluster? A simple load balancer will handle RTMP well since it is a single connection, but for RTMPT/S we need stickiness which is not necessarily supported by the client.
In this scenario we have many video sources (publishers) streaming live video into the Wowza cluster in RTMP, and many clients consuming those videos using RTMP/T/S, where each client consumes a different video stream. The Wowza cluster should scale for both the video publishers AND the video clients.
In addition, in this scenario video streams are created and destroyed by the publishers very frequently, and it would be impossible to manually update the Wowza configuration for each such event. The solution needs to be dynamic.
Looks like one option we can try is a repeater-edge configuration, with multiple origin servers and multiple edge servers. The questions that arise are:
- How to dynamically configure the edge servers such that they know the origin streams? Perhaps we con control this using the Wowza APIs, but how can this be done on the entire cluster of edge servers? Is there any cluster configuration management?
- Just like in the VOD case, how do we support load balancing for the edge instances? For the origin instances it seems like a regular load balancer will do the work because there is no RTMPT/S there.