Every business website should be running a high-availability configuration, ensuring it’s always available and responsive to traffic. In order to facilitate this environment, Kentico has built in synchronization for web farms. This features keeps all servers updated as content / information changes within the sites. With the advent of Windows Azure and other cloud platforms, this functionality has been modified and expanding to handle the multiple deployment scenarios and dynamic architecture. This blog details how some of those changes work and tips on how your site should be configured.
How Content is Synced
Here’s a Play-By-Play to help further explain the process.
(Content update example)
- Editor logs into site in a web farm
- Behind the scenes, the user is placed on one of the servers in the web farm
- Editor updates some editable text
- The data is updated in the database
- The server the change was made on updates it’s memory with the new data
- A task is logged in the database for the content update
- The system processes the task
- The system tells each server to refresh the data from the database (excluding the server that logged the change)
- The content change is then synced to all servers
Here’s a handy chart of the process. (to impress your friends!)
Web Farm Synchronization
The “Original” way
Prior to Windows Azure, Kentico handled web farm support by way of some custom web.config settings and the manual registration of web servers within the CMS Site Manager. Each web server in the farm was given a unique name, along with an internal IP. When a change is made on one server, the system logs the event in the database, denoting which server the change was made on. When the next request comes into the site, the base system then looks at any un-synced changes, then processes them on all the registered servers that aren't the “original” one.
Web Farm Server Registration
<add key="CMSWebFarmServerName" value="<servername>"/>
In addition, Kentico has a pre-configured Scheduled Tasks to manually set the synchronization interval. This can run as often as 1 second to ensure the content is synchronized when appropriate for the site.
Kentico details this process in the Developer’s Guide here
The “Just Sync It all the time” way
With the emergence of Windows Azure and other cloud platforms, the days of “manually” registered servers was not efficient, as the cloud service provider may change these settings at any time. Kentico introduced the “auto-register” feature which detects any new servers that are started. As these servers created/started from the cloud provider, Kentico extracts the internal IP and server name (set by the cloud provider) and registers them automatically. Subsequently, any “deleted” servers are auto-removed from the configuration, as well. The following key enables the system to causes the auto-registration.
<add key="CMSWebFarmGenerateServers" value="true"/>
Windows Azure projects already have this enabled by default so the key is unnecessary.
With this change Kentico also introduced the CMSWebFarmUseDBUpdater web.config key. This key changes the behavior of Kentico and how it checks for outstanding synchronization tasks. Changes are still logged with the “original” server. The application, however, will check every second for these changes and then process them on the “other” servers.
<add key="CMSWebFarmUseDBUpdater" value="true" />
If using the CMSWebFarmUseDBUpdater key, you will want to DISABLE the “Synchronize Web Farm“ Scheduled Task. Having both enabled causes conflicts in the processing of the changes.
Rolling your own solution
As with nearly every aspect of the system, the web farm synchronization process is completely configurable and scriptable via the API. By use of a custom WebFarmTaskLoader you can process changes on dynamic schedules or conditions, based on your project needs.
You can find out tons of info on the Web Farm API in the Developer’s guide here
Which one to use?
Synching web farms, like any other feature, is going to be a little different for each project. The “auto-register” functionality is available in both scenarios to minimize administration. If you need to have more granular control over your web farm server names, you will want to register them manually. You can, however, leverage the CMSWebFarmUseDBUpdater functionality in all projects, so that is a good solution if you require up to the minute synchronization.
There are times when the “every second” frequency is too demanding on the site and not appropriate. Often in high-traffic sites this can cause more harm than good and increase the workload on the servers and database. In these systems, you probably still want to rely on the “original” method of using the Scheduled Task to synchronize changes. You may need to try each configuration to see which on allows your site to perform the best but still sync your changes adequately.
If you have some complex processing conditions or just like a challenge, you may want to into leveraging the API for your site. With this method you’ll have full control over the entire process of registering servers, logging tasks, and processing them on you web farm servers.
Wrapping It All Up
Understanding what’s happening behind the scenes of the synchronization process is very important when configuring your load balanced site. Your use of caching, frequency of updates, and deployment scenario will determine which method is best for keeping your content synced across all servers. As with most things, there are several ways to accomplish functionality and you will want to test each to determine which one suits your project best.
Have more questions or a complex scenario you want to know about? Join us for Kentico- Ask The Experts #3
on 6/25/2013 and ask your question in real-time! Hope to see you there!