Weīre currently developing a project thatīs all based in Windows Media streaming. And the truth is, this project seems to be getting quite big.
Most of the content will be streamed live, and we anticipate we could have perhaps 2,000 simultaneous users, streaming at 100 kbps each, which would mean a bandwidth of up to 200 mbps .
So, we could easily go over the 100 mbps limit I current have at the my streaming server.
Iīm a little in doubt of what approaches I could take:
1. Use Round Robin DNS. Wouldnīt my users be rebuffering all the time with that?
2. Add another network card to the current streaming server. I do have plenty of RAM (2 GB) and the CPU Power is good too (Dual Xeon 2.4). My bottleneck is really on the network card. If I put two or three cards, that should increase my bandwidth by 3, right?
3. Add real load balancing, using Alteon hardware.
Which approach do you guys suggest?
Thanks in advance for your help.
Atitude Digital Media
Round Robin will do the job fine, you won't have any rebuffering issues as so long as the stream stays active the DNS will be locally cached.
An extra network card probably isn't a good idea, media streaming is a lot more resource hungry than you might think... Network load balancing on Windows doesn't work that well either - it always seems to be tempted to send all outgoing traffic through one specific NIC (I worked around that one by creating a seperate vLan for each NIC with its own gateway).
█ Dan Kitchen | Technical Director | Razorblue
█ ddi: (+44) (0)1748 900 680 | e: [email protected]
█ UK Intensive Managed Hosting, Clusters and Colocation.
█ HP Servers, Cisco/Juniper Powered BGP Network (AS15692).
I doubt arised, though. Iīve conducted some tests on the two servers I already run. Here is what I did:
1. I set Windows Media Services in each of them.
2. I configured a publishing point on server 2 to stream content thatīs originally on server 1. It ran just fine. Iīm able to access the content normally, using the address from server 2. Good. I simulated 100 simulatenous users. Ran fine.
However, the server 1 doesnīt seem to "give" 1 copy of the content to server 2 and then the server 2 distributes it. Actually, when I check the bandwidth use on both, both of them act as if they had 100 users! And thatīs not correct!
My server 1 actually has a single user (the other server) and the server 2 is the one thatīs actually streaming the content for the final users.
Doing some further reading on Windows Media Services Help, I saw something about Reverse Proxy on Windows Media Services. However, this feature is only available on Windows Server Enterprise and Datacenter editions.
So, to make it simple: what I want to do is take the load from one server and make another server (2) able to pull the content from server 1 and reditribute it. How can I do that?
Actually what you want to do is have two source streams from the encoder go to both servers in parallel. That way you arent taxing one server in favor of the other, and it is a more reliable solution. If the first server fails, the second server will still run.
As far as load balancing, that can be set up in the URL on the web page (flip back and forth between the servers).
Load limiting can be done in the windows media control panel on the servers themselves, limit the number of streams per server so that you dont exceed say 85 mbps.
Would recommend using Windows 2003 for our streaming
Would also recommend using a gigabit nic rather then multiple fastE nics, it is much easier to manage.
The idea of load balacing on the URL is not bad at all! Via ASP programming, I would send the user for server 1 or 2. Since Iīm doing mostly live content, I can monitor the servers at all times. Not as easy as a real balancer, but itīs a nice clue. And itīs free!
But I do have a problem in having the server send two streams, one for each server. Iīm using a proprietary application (MediaSite Live) and it will only allow me to send to one server at a time.
So, I need a way to re-distribute that live content to the second server. My enconding app will not be able to that.