Red5 load balance

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Red5 load balance

swengineeruser
I am looking for options for Red5 clustering. Need to have at least two red5 servers setup with a load balance. I am considering HAProxy. I read it supports rtmp but I do not know if it supports rtmps. Has anyone used HAProxy for load balance of Red5 servers? What other options are there available? Thanks in advance for any opinion or information you can provide.

--

---
You received this message because you are subscribed to the Google Groups "red5" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Red5 load balance

Walter Tak
Your app has to be aware of the cluster. Your clients have to be aware. If a server goes down, everyone has to move to the new server, right? 

If you're using an off-the-shelf app, then you're limited to building a transparent fail-over system, on the server-side (e.g. with an edge-server/router that accepts the connections and then distributes it to servers behind it).

If you are actually building the app (website/html/mobile/standalone) yourself then I'd suggest to develop a 'small independent nodes'-system which means you run Red5 on many smaller 'cheaper' servers, each independent of each other. Build a small single web+database-server that will keep track of users, connections, servers and "rooms".

Let that small database act as a watchdog and let it check on the (Red5) instances and as soon as the watchdog learns that node/server X is down, tag is as down and do not let new users connect to X anymore. The users (their app/client) that are now connected to that bad node should be notified that they should all move to new server Y. Your watchdog should tell to which server they should move.

Next the clients should disconnect from the faulty server X and they all reconnect again to server Y. 

Note that this scenario is highly scalable and makes use of all hardware ; you only need a little extra capacity in case a server goes down. Imagine you run 5 servers , and each runs at a maximum load of 80% ; thus you have 400% capacity in use. That means if 1 server goes down (for a while) you still have 4 x 100% = 400% capacity available which is exactly what you need. Of course I'd recommend to have a little more reserve capacity but you get the idea. The more servers you add (e.g. grow to 10 servers, each running at 90% = 900% capacity) means that you are using your resources more efficient.

Calculate capacity needed upon real world tests ; nobody can predict how much data your streams are going to use because that is highly depending on the environment ; webcams ? screencasts ? what are your settings / resolution / compression / FPS ? Each connection is a stream and if your stream uses 500 KBit or 2 MBit then multiply this and add say 20-30% transport overhead to be 'sure'. Then test this on the servers you are going to buy/rent. Most hosting companies advertise with 100 Mbit or 1 Gbit or 10 Gbit but very few are actually able to saturate those links to YOUR clients. Because your clients are maybe half a world away from the server so their bandwidth to the server is maybe hardly 50 Kbit (!). This is essentially true for EVERY customer outside the US if the server itself is inside the US. 

The more spread out your customers are the more difficult server placement becomes. Go for that cheap location in central US but have bad connections to 50% of your users? Go for a server closer to the majority of your users in Europe, but at the same time make the server impossible to reach from anyone in Asia? Hard questions with difficult answers.

However, if you build a "many-small-nodes"-system you could spread those smaller servers across the globe. Clients connect to your portal, in the portal you look up their country (geo-ip lookup) and then you direct the publisher of the stream (the initiator of the room) to a node/server close to him. If he is from India, setup a server in India, or Singapore or Hong Kong. If he is from Miami let him connect to your server in New York. If he is from Russia use a server in West-Europe. If most of the viewers are also in that area then the traffic is almost 'local' or at least regional ; packets don't have to fly across the whole globe to reach servers and thus your chances are less that packet-loss cripples the connection.

Cheers,
Walter





On Wed, Feb 14, 2018 at 6:22 AM, <[hidden email]> wrote:
I am looking for options for Red5 clustering. Need to have at least two red5 servers setup with a load balance. I am considering HAProxy. I read it supports rtmp but I do not know if it supports rtmps. Has anyone used HAProxy for load balance of Red5 servers? What other options are there available? Thanks in advance for any opinion or information you can provide.

--

---
You received this message because you are subscribed to the Google Groups "red5" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "red5" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Red5 load balance

swengineeruser
Thanks very much Walter for all the information and advice.


On Wednesday, February 14, 2018 at 12:13:20 AM UTC-5, Walter wrote:
Your app has to be aware of the cluster. Your clients have to be aware. If a server goes down, everyone has to move to the new server, right? 

If you're using an off-the-shelf app, then you're limited to building a transparent fail-over system, on the server-side (e.g. with an edge-server/router that accepts the connections and then distributes it to servers behind it).

If you are actually building the app (website/html/mobile/standalone) yourself then I'd suggest to develop a 'small independent nodes'-system which means you run Red5 on many smaller 'cheaper' servers, each independent of each other. Build a small single web+database-server that will keep track of users, connections, servers and "rooms".

Let that small database act as a watchdog and let it check on the (Red5) instances and as soon as the watchdog learns that node/server X is down, tag is as down and do not let new users connect to X anymore. The users (their app/client) that are now connected to that bad node should be notified that they should all move to new server Y. Your watchdog should tell to which server they should move.

Next the clients should disconnect from the faulty server X and they all reconnect again to server Y. 

Note that this scenario is highly scalable and makes use of all hardware ; you only need a little extra capacity in case a server goes down. Imagine you run 5 servers , and each runs at a maximum load of 80% ; thus you have 400% capacity in use. That means if 1 server goes down (for a while) you still have 4 x 100% = 400% capacity available which is exactly what you need. Of course I'd recommend to have a little more reserve capacity but you get the idea. The more servers you add (e.g. grow to 10 servers, each running at 90% = 900% capacity) means that you are using your resources more efficient.

Calculate capacity needed upon real world tests ; nobody can predict how much data your streams are going to use because that is highly depending on the environment ; webcams ? screencasts ? what are your settings / resolution / compression / FPS ? Each connection is a stream and if your stream uses 500 KBit or 2 MBit then multiply this and add say 20-30% transport overhead to be 'sure'. Then test this on the servers you are going to buy/rent. Most hosting companies advertise with 100 Mbit or 1 Gbit or 10 Gbit but very few are actually able to saturate those links to YOUR clients. Because your clients are maybe half a world away from the server so their bandwidth to the server is maybe hardly 50 Kbit (!). This is essentially true for EVERY customer outside the US if the server itself is inside the US. 

The more spread out your customers are the more difficult server placement becomes. Go for that cheap location in central US but have bad connections to 50% of your users? Go for a server closer to the majority of your users in Europe, but at the same time make the server impossible to reach from anyone in Asia? Hard questions with difficult answers.

However, if you build a "many-small-nodes"-system you could spread those smaller servers across the globe. Clients connect to your portal, in the portal you look up their country (geo-ip lookup) and then you direct the publisher of the stream (the initiator of the room) to a node/server close to him. If he is from India, setup a server in India, or Singapore or Hong Kong. If he is from Miami let him connect to your server in New York. If he is from Russia use a server in West-Europe. If most of the viewers are also in that area then the traffic is almost 'local' or at least regional ; packets don't have to fly across the whole globe to reach servers and thus your chances are less that packet-loss cripples the connection.

Cheers,
Walter





On Wed, Feb 14, 2018 at 6:22 AM, <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="Mm17uv77AwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">swengin...@...> wrote:
I am looking for options for Red5 clustering. Need to have at least two red5 servers setup with a load balance. I am considering HAProxy. I read it supports rtmp but I do not know if it supports rtmps. Has anyone used HAProxy for load balance of Red5 servers? What other options are there available? Thanks in advance for any opinion or information you can provide.

--

---
You received this message because you are subscribed to the Google Groups "red5" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="Mm17uv77AwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">red5interest...@googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "red5" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.