New web farm update mechanism

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.