Load balancing multiple servers

Can you guys provide documentation for load balancing multiple servers for a single site? What are the requirements for the load balancer? What are the JR config settings we need to be aware of so that users will access same data on both servers? Is it as simple as making sure the configuration is exactly the same on both servers and they both point to the same DB?


updated by @dannya: 06/16/17 09:28:36PM

Yes - for now.

Note that Jamroom Cloud 2.0 is in active development right now and is getting fairly close to it's first release. We've been doing A LOT of work to make running a JR cloud much, much easier by simplifying many aspects of the system. JRC 2.0 will also run much better when distributed across multiple front ends.

Upgrading from JRC 1 will be pretty straightforward and will mainly involve turning off some of the modules that are no longer used.

More details will be coming in the next few weeks.

Thanks!


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

Ok. I'll wait until then. Although we have a lot of custom modules that use the queue to process on other servers. Hopefully it won't affect that.

Also, it may be too late, but to re-iterate some feedback I provided a while back. In the medium term, I am really interested in being able to break out modules as microservices that can be scaled independently. Right now we have a few modules that run on conversions servers and the log server is also separate. The next thing i want to be able to break out are the (custom) reporting and analytics modules and some other cpu intensive functions.

The cloud modules allow this to an extent. The problem is having to deploy a full instance of JR to run a service is really resource intensive. It would be great if the architecture made it easire to call out external services without requireing a full JR install.
updated by @dannya: 03/11/17 10:04:48AM

You're not going to see JR move in the micro services direction - in my opinion microservices just add more overhead, complexity and creates a slower more error prone system (since now your flow overwhelmingly requires network, which is the most prone to problems).

I believe microservices make sense when you have different teams running different parts of infrastructure and you want to "black box" as much stuff as possible, but it makes very little sense for most sites to even move in that direction. I've read a lot on microservices and found this blog post to be one I agree with:

http://basho.com/posts/technical/microservices-please-dont/

The direction we are moving with JRC 2.0 is to make even a large JR cluster easy to admin and run even for a solo site owner. This means less cloud modules and more "it just works". This means running a lot of things as "services" internally, but the site owner just does not need to care. Our goal is that when you feel you need more CPU power you just spin up a new app server, add it to your cluster, and you're done.


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net
updated by @brian: 03/11/17 10:15:18AM

I don't disagree with the points made in the blog post. And I agree your solution will provide benefits over the current implementation. But I'll also argue, as mentioned in the blog, that if you really understand your workflows and bottlenecks, having microservices can help.

Encoding is the best example. You can optimize a server for encoding much better to process media files; especially if you don't have all the overhead of the monolith. Even today, our conversion servers conversion server has very few modules active. But having to provide enough resources, maintain, and monitor a full jamroom install and another db just to run FFMPEG and SOX is pretty silly. And it still requires the same connection/IO resource of a microservice.

I realize that aside from the Jamroom network, 98% of JR users aren't scaling a single site enough to require that. The JR network also runs multiple sites, not a single large site; so it's needs are different and I'm sure it's driving much of the cloud module's new capabilities.

Happy to try the new release. Every improvement helps. Just wanted to throw my hat in the ring
updated by @dannya: 03/11/17 11:11:08AM

Just to add - you'll still be able to run as many different encoding servers as you want - I'm not changing much in regards to how the conversions work, so that should be no problem.


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

Ya. The conversion servers were just an example because the are especially resource intensive. But the example is ideal because if you have one service (module?) that requires a disproportionate amount of a resource, it's nice to be able to scale it separately. You can do it today but just enabling the modules you need; it's just that you have to deploy a full node to handle one service and that carries an administrative and resource overhead. It's not wrong, just not optimal for certain functions.

You're always going to have to run a Jamroom install on some of the cluster servers:

- App Servers (front end servers)
- Conversion workers
- Cluster Master (which runs the Queue server and conversion master)

the MySQL database and Redis cache servers do not need a JR install.


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

What's the redis cache? I found a link to details in jamroom site search but its broken

Actually getting page not found on documentation link for many modules.. The ones i found so far:
https://www.jamroom.net/the-jamroom-network/networkmarket/64/playlist-ads
https://www.jamroom.net/the-jamroom-network/networkmarket/113/daily-limits
https://www.jamroom.net/the-jamroom-network/networkmarket/155/media-limits

It's not released yet, but will be coming with JR Cloud 2.0 - it's a new caching/sessions module that uses Redis:

https://redis.io/


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net