Capacity Planning Considerations for Windows Azure Caching
The required capacity of a Windows Azure Caching cache is determined by several factors, including the amount of data to be placed in the cache, the frequency and amount of reads and writes to the cache, and what options, such as high availability, are specified for the cache. Once the cache requirements are determined, the cache topology can be configured. The topology ofthe provisioned cache cluster depends on several factors, including the size of the virtual machine, the number of deployed instances, and whether the role is a shared role or dedicated for caching. This topic shows how to use the Capacity Planning Guide spreadsheet to determine the required capacity of the cache, and the settings to configure to provision a cache cluster to meet the requirements.
|This topic provides guidance on how to use the Capacity Planning Guide spreadsheet to determine the capacity and the settings to provision a cache of the desired size. For additional guidance on determining what size may be appropriate for your application, see the Capacity Planning Methodology section of the Capacity Planning for Caching in Windows Azure whitepaper. Although the Capacity Planning for Caching in Windows Azure whitepaper contains guidance that is specific to Windows Azure Shared Caching, the guidance in the Capacity Planning Methodology section is applicable for Windows Azure Caching and may help you determine the size of cache that meets your application's requirements. Note that this guidance is a starting point to get a sense of the capacity required based on caching requirements, and that testing is required before going into production, even for configurations recommended by this guide.|
Using the Capacity Planning Guide Spreadsheet
The Capacity Planning Guide spreadsheet is a spreadsheet that can be downloaded from the Microsoft Download Center, and includes two worksheets that can be used to assist with capacity planning: Dedicated Role – Planner and Co-Located Role - Planner. Dedicated Role – Planner provides guidance on creating a Dedicated Role cache cluster, and Co-Located Role - Planner provides guidance on creating a Co-Located Role cache cluster.
|Cache Cluster Deployment Topology||Description|
Dedicated Role caching
Worker role instances are used exclusively for caching.
Co-located Role caching
The cache shares the VM resources (bandwidth, CPU, and memory) with the primary application hosted by the role.
If your application has unutilized memory in its existing roles, then you can configure a co-located role cache cluster on those roles, and utilize that extra memory for caching. If there is not sufficient extra memory in the roles to support a cache cluster, you can scale the roles out, or you can add a cache worker role and configure a dedicated role cache cluster. This guide helps you determine the settings to use for the deployment topology that meets the caching needs of your application.
The following sections describe how to use the two worksheets for capacity planning for Dedicated Role and Co-located Role caching.
Dedicated Role - Planner
The Dedicated Role – Planner worksheet is the first worksheet in the Capacity Planning Guide spreadsheet and it is used to help determine the settings for a Dedicated Role cache cluster. A dedicated role cache cluster is one in which the worker role instances are used exclusively for caching.
The Dedicated Role – Planner worksheet takes several types of input. The first section, Input: Data Requirements, is used to calculate the maximum size of data for the cache. For up to ten data types, you can enter the Average Object Size (Post-Serialization), Maximum Number of Objects, and High Availability Enabled. In the previous example, there is one data type modeled. The average size is 2,560 bytes, with 100,000 as the maximum number of objects in the cache. High availability is not enabled.
The second section, Input: Throughput Requirements, is used to calculate the bandwidth requirements for the cache, and has as inputs the Number of Reads/sec and Number of Writes/sec at peak load. In this example the peak load for Data Type 1 is 10,000 reads per second and 500 writes per second.
The third section, Input: Advanced Options, provides several additional input settings. Cushion for peak load - data and Cushion for peak load - Throughput provide a buffer for surges in application load. These settings provide a convenient way to increase or decrease the desired buffer for the amount and throughput of data in the cache.
Preserve Data across Azure Updates indicates whether the capacity planner spreadsheet should include extra capacity for rolling upgrade scenarios when the roles in an upgrade domain go down due to an update. When Windows Azure shuts down the roles in an upgrade domain due to an update, Caching attempts to move the data to the other nodes in the cluster before the node goes offline. If there is insufficient capacity in the other nodes to take up the extra load, then all of the cached items from the role may not be transferred to other nodes. Preserve Data across Azure Updates is set to Yes by default in the capacity planner spreadsheet. If it is set to No, then the capacity requirements for the role are decreased. When Preserve Data Across Azure Updates is set to Yes, the guide reserves extra capacity equivalent to one upgrade domain worth of capacity. For more information about upgrade domains, see Overview of Updating a Windows Azure Service.
|If a node goes down due to a failure, or due to the number of role instances being reduced due a configuration change, then cache data is not moved to other nodes. Windows Azure Caching only moves data to other nodes when the shutdown is planned. High Availability can be enabled to provide backup copies of cache data in the event of a node failure. For more information, see High Availability (Windows Azure Caching).|
Upgrade Domain Count refers to the number of upgrade domains for the role that hosts the cache cluster. You can either let the capacity planner spreadsheet recommend an upgrade domain count for your cache cluster, or you can specify it yourself. The default setting is Set by planner. When Set by planner is selected, the capacity planning spreadsheet provides a recommendation in the Upgrade Domains column of the Output: Possible Configurations section. When an upgrade domain count is manually specified in Upgrade Domain Count, then the specified count is displayed in the Output section. For more information about upgrade domains, see Overview of Updating a Windows Azure Service.
Once the inputs are configured, the tool provides proposals in the Output: Possible Configurations section. In this example the recommended configuration is a Medium VM size with 3 role instances and an upgrade domain count of 3. In addition to the recommended configuration, the Output: Possible Configurations section shows the required settings if one of the other VM sizes is chosen.
If the average size of objects in the cache is less than 2k, then the capacity planner guide displays a CacheDataSize (MB)* column and a note under the Output section.
|The link displayed under the Output section links to the Capacity Planning Considerations topic you are currently reading.|
If this message is displayed, then create an XML file in your role project named CacheSettings.xml and add a
dataCache section that includes the CacheDataSize (MB) setting from the Output section by performing the following steps.
Right-click the role project that hosts the cache cluster in Solution Explorer and choose Add, New Item. Select XML File from the Templates pane, type CacheSettings.xml into the Name box and click Add.
Copy the XML snippet below and paste it into the CacheSettings.xml file.
<?xml version="1.0" encoding="utf-8" ?> <configuration> <configSections> <section name="dataCache" type="Microsoft.ApplicationServer.Caching.DataCacheSection, Microsoft.ApplicationServer.Caching.Core" allowLocation="true" allowDefinition="Everywhere" /> </configSections> <dataCache size="Small"> <advancedProperties> <memoryPressureMonitor cacheUserDataSizePerNode="[CacheDataSize (MB) Setting]" /> </advancedProperties> </dataCache> </configuration>
[CacheDataSize (MB) Setting]with the setting from the CacheDataSize (MB) column that corresponds to your VM Size. In the following example,
<?xml version="1.0" encoding="utf-8" ?> <configuration> <configSections> <section name="dataCache" type="Microsoft.ApplicationServer.Caching.DataCacheSection, Microsoft.ApplicationServer.Caching.Core" allowLocation="true" allowDefinition="Everywhere" /> </configSections> <dataCache size="Small"> <advancedProperties> <memoryPressureMonitor cacheUserDataSizePerNode="2088" /> </advancedProperties> </dataCache> </configuration>This CacheCluster.xml file will be deployed along with your application and contains the required configuration.
Important Do not modify any other settings in this snippet, such as the
sizeattribute does not specify the size of the VM Role that you are using for the cache cluster and must be set to
To use the Dedicated Role – Planner worksheet, enter values into the Input sections that match your caching requirements. Use the recommended proposals as a starting point for configuring your cache cluster. To configure a dedicated role cache, add a Cache Worker Role to the project and configure the cache cluster properties. For an example of configuring a dedicated role cache cluster, see How to: Configure a Cache Cluster on Windows Azure Caching.
Co-located Role - Planner
The Co-located Role – Planner worksheet is the second worksheet in the Capacity Planning Guide spreadsheet and it is used to help determine the settings for a Co-located Role cache cluster. A co-located role cache cluster is one in which the resources of the role instances (memory, CPU, and bandwidth) are shared between caching and the application.
To use the Co-Located Role – Planner worksheet, enter your role's configuration in the Input: Cluster Configuration section. In VM Size, enter the VM size that hosts your role, and enter the number of role instances into Number of VM Instances. Enter the desired cache size into User Data to be stored in Cache, and specify the desired setting for High Availability Enabled. Enter Yes if you want to enable high availability, or No if not. In this example, The VM size is medium with 3 role instances, and a desired cache size of 1,500 MB, with no high availability.
Once the inputs are configured, the tool provides a recommendation on the feasibility of hosting the desired cache cluster on the existing role instances, and the setting to use for the Cache Size slider on the Caching tab of the role properties. These are located in the Output: Feasibility & Settings section. In this example, the Cache Size (%) setting would be set to 30%, with the remainder used by the OS and other processing. If the desired cache size is not feasible for the current role configuration, you can model other configurations by changing the VM size, role instance count, and cache size, until you find a configuration that meets your application needs.
To use the Co-located Role – Planner worksheet, enter values into the Input: Cluster Configuration section that match your caching requirements. Use the recommendations in the output section as a starting point for determining your cache cluster configuration.
|The load that a co-located cache can bear is a function of how much bandwidth/cpu is available for caching, once the bandwidth and cpu consumption of the primary application are taken into account. Testing should verify performance for both the cache and the primary application.|
Once the cache cluster configuration is determined, the cache cluster can be configured in the property pages for the role. For an example of configuring a co-located role cache cluster, see How to: Configure a Cache Cluster on Windows Azure Caching.