Rolling application update in Wildfly -for 100% availability during deployment

[Amit Pareek]

Dear All ,

Hope you all are doing good .

I have a requirement where we want zero downtime for any new version upgrade of application = 100% availability.

Some of the points

1) Environment

1) Standalone

2)  Domain controller cluster

For few customer we run application on standalone environment and for few customer in cluster mode.

2) Approach we are thinking

a) Standalone - 100% availability architecture  minus user session

   1) Creating 2 Standalone server .

   2) At a time running only 1 server.

   3) Deploy Version1 of application on server 1 and server 2.

   4) Loadbalance pointing to server 1.

    5) User hitting Load balancer url and request will be forwarded to server 1.

   6) Now time to upgrade application .

   7) Application upgrade happen in server 2 .

    8) Load balancer will be pointed to server 2.

    9) In the mean time server 1 will be upgraded .

  

Challenge with this approach , how user session , j2ee jaas principal will be manged ?

Can someone give suggestion here ?

b) Domain cluster -

      1) Create server group 1 with 3 nodes .

       2) Create Rollout plan with rolling-to-servers=true .

deploy ProdApp.war --name=ProdApp.war --runtime-name=ProdApp.war --server-groups=ha-server-group --headers={rollout ha-server-group(rolling-to-servers=true)}

 3) In this approach how Load balancer will know that deployment is happening in node 2 of the cluster and it should not forward the request to  this node. ?

Im new to the Wildfly need suggestion with your experiences ?

Thanks.

[Paul Ferraro]

On Tuesday, November 22, 2022 at 9:02:34 AM UTC-5 amit...@gmail.com wrote:

Dear All ,

Hope you all are doing good .

I have a requirement where we want zero downtime for any new version upgrade of application = 100% availability.

Some of the points

1) Environment

1) Standalone

2)  Domain controller cluster

Just to clarify, standalone vs domain has nothing to do with clustering, but rather to do with how WildFly is managed.

You can have a cluster of standalone servers, just as you can have a domain managing a group of non-clustered servers.

 

For few customer we run application on standalone environment and for few customer in cluster mode.

2) Approach we are thinking

a) Standalone - 100% availability architecture  minus user session

   1) Creating 2 Standalone server .

   2) At a time running only 1 server.

   3) Deploy Version1 of application on server 1 and server 2.

   4) Loadbalance pointing to server 1.

    5) User hitting Load balancer url and request will be forwarded to server 1.

   6) Now time to upgrade application .

   7) Application upgrade happen in server 2 .

    8) Load balancer will be pointed to server 2.

    9) In the mean time server 1 will be upgraded .

  

Challenge with this approach , how user session , j2ee jaas principal will be manged ?

Can someone give suggestion here ?

Generally, you will launch new server instances containing the new version of your deployment and rely on the session draining feature of your load balancer.

For a deployment using non-HA sessions, you would simply launch a new instance of WildFly, and initiate session draining on the old WF instance.

This directs requests for existing session to the old instance, and requests for new sessions to the new instance - and sticky sessions ensures that requests don't bounce between them.

For a deployment with HA sessions, the method of upgrade will depend on the compatibility of your session state between deployment versions.

If your new deployment makes not changes to, or only makes forward/backward compatible changes to session state, then you can use upgrade method above.

If your new deployment makes forward/backward *incompatible* changes to session state, then you will need to configure your new server instances to use an isolated cluster so that this new cluster only contains sessions created by the new deployment version.  You can then start these new server instances, and begin session draining of your old server instances.

Ideally, your load balancer should support logical grouping of backend servers.  e.g. mod_jk calls these "domains", whereas mod_cluster calls these "load-balancing-groups".

This ensures that the load balancer does not inadvertently failover requests from and old server to a new server (or visa versa) during the session draining process.

[Everly, David W]

I think one must also plan for wildfly version upgrades, which sometimes are incompatible with each other regardings cluster/session management.

https://groups.google.com/g/wildfly/c/ENMiy1EnI3M/m/59tD94JHDQAJ

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/a8f337ec-e33e-45c0-8fa0-fd464e1e1547n%40googlegroups.com.