i’ve thinking about this for quite a while. To illustrate the situation i’ve scratched the current deployment strategy on my AWS environment (aws-cuba-vpc-direct-be.png). Basically it’s multiple FE servers behind a load balancer. Each has two connections to the backend servers configured.
What i’m thinking of is if it is possible to make use of horizontal scaling for the backend servers. What i mean by that is that instead of giving the FE servers the direct connections to the BE servers just give them connection to one or two BE load balancers. This seems a little bit more aligned towards what is able with something like AWS elastic container service (ECS).
The problem with this is, that when the ECS cluster should start new BE servers because of load requirements or because an instance is not available anymore - it just can’t easily spin up a new instance. The reason is that the backend servers would have to get to know each other in a
fully meshed network.
My question now is, if there is a way to achieve this. I could imagine that the user sessions could be stored in the DB or in an additional external cache or something. In order to understand it would be interesting to know what exactly do the BE servers share. Can you give a little explanation on this topic?
so i think i totally missed the point. My assumption was that the connectionUrlList attribute is not only for FE servers to communicate to BE servers, but between BE servers as well. After going through the docs once again, it seems that the BE (middleware) servers uses a self discovery mechanisms in order to talk between the different BE server nodes.
So from this point of view i would not need to handle the connection lists between the BE servers - which is very good for my desired scenario.
So then my only question remains if it possible to put a load balancer between FE and BE servers. This would remove the need to manually maintain the connection lists from the FE servers. This would open up the above described possibility to add another BE node if required. Since a self discovery mechanism like implemented in JGroups is a good basis for more than two BE servers, i think i should work, right?
Nevertheless, can you explain a little on how JGroups communicates between nodes and especially as i saw that UDP broadcast is the default in the jgroups.xml if you have any experience and or problem with running this scenario within Docker?
Hi Mario,
You are right, the cuba.connectionUrlList application property is designed primarily for connection of clients to middleware servers. It can be used on the middleware too if a middleware block needs to connect to another middleware block as a client, but this is not a typical use case.
Each CUBA client block contains some kind of embedded load-balancer with sticky-session behavior. The balancer is set up with the cuba.connectionUrlList application property. This is convenient for local deployments where you can easily control your hosts and IP addresses but becomes cumbersome in a distributed cloud deployment. So you can use a regular external load-balancer between clients and middleware and point cuba.connectionUrlList to it. There is one hidden complexity in this scenario: your load-balancer will redirect each call to the different middleware server, so immediately after login the next call will go to a server that might not receive the user session yet because it was created on the first server and the user session replication is asynchronous by default. In order to ensure the new user session exists on all cluster members, you should turn on synchronous replication for login. It can be done for all clients by using the cuba.syncNewUserSessionReplication application property on the middleware (see ServerConfig.getSyncNewUserSessionReplication()), or only for clients of some kind. In the latter case, these clients should pass the cuba.syncNewUserSessionReplication parameters with true value to the LoginService.login() method.
Regarding the cluster communication between middleware blocks, I should note that default JGroups config using UDP-based auto-discovery of cluster members is not suitable for cloud deployments - UDP just won’t work there. TCP-based configuration works well, but it is not convenient in the cloud because you should provide static IP addresses. So you should use one of the discovery protocols listed in the JGroups manual: Chapter 7. List of Protocols
We use S3_PING in one of our projects deployed in Amazon AWS, see the example config file below.
Finally, I would like to note that CUBA mechanisms do not use JGroups directly. Instead, they work with the ClusterManagerAPI bean, which has an implementation based on JGroups. So it is possible to completely replace JGroups with something different in an application project just by overriding the bean.
thank you for the explanation. Regarding the load balancer and the not received user session:
Would it help if the BE load balancer is configured such that it uses sticky sessions for the FE --> BE communication? Then this problem should not occur, right? Or is the synchronous session replication not a big deal?
Thanks for the tip with the AWS S3 ping mechanism. Since VPC doesn’t allow Broadcast at all - this is very handy. What i wounder about is that your settings differ to some degree from the one that is in the detault jgrous.xml file in the project (which i copied over here):
> Would it help if the BE load balancer is configured such that it uses sticky sessions for the FE --> BE communication?
It would help but I don’t know how to configure the load-balancer for sticky sessions while there are no standard HTTP sessions in this communication channel. If you manage to do this - please let us know.
> Or is the synchronous session replication not a big deal?
It’s definitely not a big deal because it is synchronous only for the first request on login.
> your settings differ to some degree from the one that is in the detault jgrous.xml file in the project
Yes, but I believe the differences in recv_buf_size, send_buf_size are not important - these are just default values from some previuos JGroups version.
> Yes, but I believe the differences in recv_buf_size, send_buf_size are not important - these are just default values from some previuos JGroups version.
You mean the values in your example are older? Or the one that comes with CUBA (in my case: 6.1.2). ok, with recv_buf_size changes i can live with, but there are some major ones like “thread_pool.queue_enabled” or the absence of “pbcast.NAKACK2” xml tag.
Yes, this config is probably older (it uses pbcast.NAKACK instead of NAKACK2), but it should work for newer versions too. As I said, I took it from the real application in production. You can play with all these protocols and parameters, but I’m sure default values will be fine for most cases.
