Understanding Campaign Listener Clustering and Listener Failover - Part 2

Clustered Listener Environments

With the introduction of Clustered listener setups in Campaign, you have to think of them as a setup with multiple independently operating listener nodes that are being directed requests from a centralized entity. Each listener process behaves as it would in a single listener environment (See Part 1 of this Blog for more information), independently starting up and shutting down unica_acsvr processes local to its machine and maintaining its own unica_aclsnr.udb file. Each listener node does NOT share information. They act like individual, independent SINGLE listener nodes even though a “master listener” is managing them. The following shows a depiction of what a Clustered Campaign Listener setup would look like.

Think of a master listener process as a load balancer. When a request comes down from the Campaign J2EE Web application server to login to Campaign or to view/edit/run a flowchart, instead of the Campaign web application talking to a specific listener to do that, it passes those requests over to the master listener in a clustered setup.

The master listener then reviews its configuration settings to know which child listener node should take on this task. Once the Master listener determines which child listener node should receive the request, the request is passed along to that child listener node.

At that point, the child listener node on that specific machine processes the request as if it was a single listener node running in a non-clustered setup. It spawns applicable unica_acsvr processes, and those unica_acsvr processes perform the requested action. The listener node then updates its local copy of unica_aclsnr.udb to understand the unica_acsvr’s it’s managing.

No other child listener in the cluster has any idea about what other child listeners are working on. All activity is localized to a single child listener node. The child listener nodes never communicate or share their relative local unica_acsvr information from their unica_aclsnr.udb files they are managing. You could have some user requests going to one child listener node and other user requests going to another child listener node, all being distributed to them by the master listener to manage/balance the workload based on configuration setups of the environment.

So how does this all work when a listener becomes unavailable, and failover needs to happen? When you have a master listener managing two or more child listener nodes, requests coming in from the business users via the UI are being load-balanced across those child listener nodes. If one of those listener nodes should go down due to manual intervention or some other event, new requests that funnel in are transferred by the master listener to the remaining child nodes in the system that works. Those operate on separate machines but still have access to the same system table database information and file server contents (in a shared directory). To the frontend business users, business goes on as normal, and no downtime is suffered because you still have at least one working listener node available to receive requests even though the other listener node is down. Behind the scenes, the IT team can look into the down child listener node without any disruption to the frontend business users. The master listener flips the switch to always point to the remaining working listener nodes when it comes to redirecting requests from the Campaign J2EE web application server. When the down listener node is brought back up, the master listener will start sending requests to that node (and the others) as before.

Now say you have one of your listener’s come down while there is already flowchart and login session unica_acsvr’s running on that listener. What happens then? If one of the child listener nodes goes out, the master listener will transfer any NEW requests to other child listener nodes, but any previously existing unica_acsvr’s running on the machine where the listener node went down will act just like a single listener setup. They may continue to run any flowchart logic to a point, but the updates to the UI or any further UI clicks may not get through because the listener on that machine is gone. There is no transference of unica_acsvr processes from one listener node to another when a listener goes down. In other words, if the listener on node A goes down, any managed unica_acsvr processes that existed at the time it went down cannot be started on some other listener node. They instead must be restarted manually on those other listener nodes through new UI requests to access the flowchart.

If the machine where the Master Listener node exists should become unavailable, Campaign will automatically switch to using one of the remaining child listener nodes as a new Master Listener node to avoid any disruption.

The bottom line is, in a clustered listener setup, failover means simply when a listener node goes down or is down, and a NEW request comes into startup a unica_acsvr process, it will always direct to a running child listener node. Any unica_acsvr processes that were running on the listener node that goes down cannot be recovered. Users must log out of the UI (which is now frozen potentially) to establish a new Campaign login session on one of the operational child listener nodes.

You can read the first part of the blog here- Understanding Campaign Listener Clustering and Listener Failover – Part 1

To learn more about the configuration properties for cluster listener setups, subscribe to Unica Blog, and Stay Updated.