|
||
This chapter describes how Kentico CMS works within the Windows Azure environment, which features of the service are utilized and how the application stores and manages its data in the cloud environment.
The following diagram illustrates the relations between the individual elements that together form Kentico CMS in the cloud environment. The different components depicted in the diagram are described in the text that follows.
If you choose to install Kentico CMS to Windows Azure, all files will be grouped into a solution based on Visual Studio's Windows Azure template. The solution contains several projects. One of them is a web application, which encompasses almost all the functions of Kentico CMS and is designed to run as a Windows Azure ASP.NET Web role. The Smart search worker, is separated from the web application in another project because it cannot run together with the application as the Web role. In order to index content of websites correctly and effectively, the Smart search worker runs as a Windows Azure Worker role.
Because the application is divided into these two entities (called services in the Azure terminology), you will also need to configure them separately. More information on how to configure the application can be found in Application structure and configuration.
Kentico CMS on Windows Azure uses the SQL Azure relational database. This database engine is almost identical to the standard SQL Server engine, with only a few limitations. These limitations are taken into account in Kentico CMS, hence no additional configuration or customization is required. If you're interested in which SQL Server features are not available in SQL Azure, refer to the following MSDN article.
Windows Azure doesn't offer a persistent file system similar to the file systems in Windows that you're used to. Data stored within Azure can't be hierarchically organized into folders. However, Kentico CMS provides an abstract layer called CMS.IO, which enables the system to operate on different types of file storages.
The CMS.IO namespace acts as an intermediary between the Kentico CMS business layer and various file storages, including Azure's blob storage. On a standard non-Azure installation, CMS.IO only overrides the System.IO namespace. On Windows Azure, the namespace uses a provider which works with the blob storage, creating an imitation of the regular Windows file system.
The CMS.IO namespace can be extended to support any other type of storage, e.g. the Amazon cloud drive.
Additionally, you can make use of the Azure storage provider and store files in the cloud even if you're running a non-Azure installation. You can find more information about this approach in the Hybrid storage scenarios topic.
The file storage is shared across multiple instances, therefore no file synchronization is needed.
|
Important!
Contrary to Windows file systems, the blob storage is case-sensitive. As a result, names of all files processed by Kentico CMS are converted to lower case before saving.This won't normally affect functioning of the system, although there are a few scenarios when you will have to take additional actions to prevent unexpected behavior.
|
The fact that Kentico CMS can run in multiple instances on Windows Azure creates the need for synchronization of data between the instances. The CMS handles this by considering each instance a web farm server. Unlike the traditional web farm comprising multiple physical servers, you don't have to configure the web farm servers manually in the multiple-instance Azure environment. The only configuration that needs to be done is setting the number of instances in the service configuration file. Data is synchronized via web farm tasks, which are created and executed automatically.
Every complex web application needs to store information about its state, especially user session data. Since the Azure environment is dynamic and the application doesn't reside constantly in one place, its state has to be stored separately.
Kentico CMS is pre-configured for using the Windows Azure AppFabric caching service to take care of session information. This way, all instances of the application have access to their data, which keeps them synchronized.
|
Please note
Using the AppFabric cache is recommended, however, you can choose any other means of storing session state information.
|