New web farm update mechanism

A part of the current hotfix package (6.0.21) is the brand new mechanism for synchronizing web farm servers. This mechanism does not use URL notifications so it eases web farm configuration. Also, it will continue to work when any of your web farm servers change its internal IP address (for example, when you make a VIP swap on Windows Azure).
One of the main motivations for building this feature was to solve an issue with the VIP swap on Windows Azure. During the swap, your Windows Azure staging instances become production instances and they change IP addresses. Unfortunately, this event cannot be recognized by the instance itself. Since our standard web farm update mechanism used an instance internal IP address for sending synchronization notifications, you had to modify the URL of the given web farm server with the new address (after the swap). Also, you had to generate a new license for the new internal IP address. We heard from you that this causes you some troubles. That’s why we decided to build a new synchronization mechanism which solves these problems. We added it to the latest hotfix package.

Currently, the default web farm update mechanism remains the same, the one which uses URLs and internal servers’ IPs for sending notifications. If you want to use the new one, you need to apply the latest hotfix and then configure an application settings key in your web.config file (optionally in a service configuration file if you are using Windows Azure):

<add key="CMSWebFarmUseDBUpdater" value="true" />

Please keep in mind one important thing, this mechanism must be “started” by request on every server. Each server in the web farm should be hit sooner or later by a site visitor but I strongly recommend you to make sure that all your servers process at least one request right after the start.

New Web farm mechanism under the hood

Reading this section is not required in order to use this new mechanism, it is only informational. Please note that for full understanding of the lines below, an advanced knowledge of the Kentico CMS web farm module is needed.

As the name of the setting key suggests, the synchronization is done through a database. There is a new column in the CMS_WebFarmServer table, which contains a timestamp with information about the last server update. Every time any server creates a new web farm synchronization task, this column is updated for all other servers. There are also a few lines of code running in its own thread which periodically polls a database to find out if a timestamp changed. When the column contains a newer timestamp, the task processing is executed. The polling interval is set to 1 second. The separate thread with the polling code is started when the given server receives the first request. That’s why every server should be hit at least once after the start. We cannot start the thread with an Application start since whole Kentico CMS is initialized within the first request.   

Do you like this feature? Is it sufficient for your scenario? Please let me know through comments.
Share this article on   LinkedIn

Dominik Pinter

I'm a fan of cloud computing (primarily Windows Azure) and I really like to dig into web application security. My blog is focused on everything related to Kentico, .NET Framework, Cloud platforms and web application security.


kentico_dominikp commented on

Hi Rick,
It depends on concrete situation and your web farm configuration.

In case of this mechanism, each node will run separate thread and also each node will query your database once per second. On the other hand, standard mechanism just sends one HTTP request when needed. So, from this point of view, standard mechanism seems better. But, if one node processes 20 requests per second and each request changes something in the cache then node will send 20*5 (nodes) HTTP requests per second which consumes more resources on all nodes.

We tried to build this mechanism as effective as possible. I would say that this mechanism is not worse from performance point of view than old one in typical real world scenarios.

Rick Seinfeld commented on

I am curious about performance? Is it better or worse for example for 5 nodes in a farm?