The obvious problem is that the stream chunk names don’t match. This prevents load balancing, as the HTTP chunk names between servers don’t/won’t ever match up. Is there a way to control this?
Obviously, restarting the Wowza instances is also problematic with scheduled streaming, as the VOD files restart at the beginning, along with the chunk names as well (they restart at chunk_1.ts for HLS,…).
With time stamp based chunks, this could be “solved”, as long as the servers times are kept in sync.
Also seeking into the scheduled VOD file seems to be possible with Wowza itself (start/offset), so I’m not exactly sure why Wowza doesn’t play this stream honoring the time passed since the scheduled parameter defined in the playlist.
Are you sourcing so many streams in HTTP origin mode that you would need to load balance? CDN distribution usually obviates load balancing. In any case, the CDN would have to negotiate the load balancing, and it would probably be best to do that per stream, i.e. all chunks for a stream from one server or the other.
We want to have the functionality to loadbalance the edge servers which are taking care of the chunking for HLS and HDS for both VOD and Live. However we need to find a system where we can sync the chunk names.
Our setup is as follows:
x2 Origin Wowzas where clients will be pushing a livestream to
x3 Edge Wowzas which will be pulling from Origin Wowzas and creating HLS and HDS chunks
Loadbalancer in front of the edges and clients pull direct from the loadbalancer.
The action point here is that we need to be able to pull a chunk with a specific name from edge1 or edge3 or edge2 and it has to be that same chunk all throughout.
Are you sourcing so many streams in HTTP origin mode that you would need to load balance? CDN distribution usually obviates load balancing. In any case, the CDN would have to negotiate the load balancing, and it would probably be best to do that per stream, i.e. all chunks for a stream from one server or the other.
Richard
We are sourcing a significant number of streams. Load itself not so important, we would be fine with round-robin or even GeoDNS/Route53 latency routing - and sticky sessions, as you suggested yourself.
The main “catch” for us is to eliminate a SPOF in this case and provide a transparent fallback location for any failed requests, if they should occur (they have in the past).
This is where the root of the problem is very much visible:
“chunk_234.ts” will not have the same name on the other server(s) - interrupting playback for clients in an outage until they request playlist/chunklist data and continue on.
Scheduled streams will absolutely not match up, causing the clients to skip or replay a significant part of the VOD.
This property will enable the chunk ID numbering based on incoming stream packet time. If all your 3 edge server will connect to the same stream, the chunk names on those 3 edge server should be the same at one particular point in time.