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
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.