Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]
Selecting the configuration storage options that are right for your application and cache cluster may depend on several factors when you are using Microsoft project code named "Velocity." Your choice may be matter of technical requirements for your application or may depend on the resources available in your infrastructure. Or, your choice may be a personal preference.
This topic describes some of the implications you may want to consider when you choose among options for specifying the client and cluster configuration settings.
Client Options
Specifying cache client configuration settings programmatically may be the best choice if configuration options will change while the application is running. For example, you may want to enable local cache for some parts of your application but not use it in others. Also, you may not want to add an application configuration file to your application if there would otherwise be no need for one.
Using an application configuration file to specify cache client configuration options may be the best choice if some parameters may change after the application is compiled. For example, if the name of some of your cache hosts changes, you only have to update and resave the client configuration file. If you specify those settings programmatically, you must recompile your application.
Because programmatic configuration of the cache client overrides the XML settings, you may also want to take a hybrid approach. Settings in the application configuration file could be treated as your application's default and you could override those settings with programmatic configuration. Whether you set them programmatically depends on whether or not you provide configuration parameters to the constructor of the CacheFactory class.
Cluster Options
When you select the XML or SQL Server Compact-based cluster configuration storage options, you must provide a shared network folder in which to store the configuration data. When you select the SQL Server-based option, you must provide a SQL Server database
When you decide which storage option to use for cluster configuration settings, consider how you would prefer to change the cluster configuration and what degree of availability you want. The size of your cache cluster may also determine which option that you choose. Unlike the cache client configuration settings, you can only use one storage option for the cluster configuration.
The storage format you choose for the cluster configuration remains for the life of the cluster. But because of the PowerShell-based administration tool, cache configuration can be scripted. This makes migrations to another configuration storage format quick and efficient. For more information about the cache configuration commands available to the PowerShell administration tool, see Cache Administration with PowerShell (Velocity).
Cluster Configuration Changes
When considering making cluster configuration changes, the question to ask is: do you want the option to use XML to change settings or not? By selecting the XML-based configuration storage option, you can change the configuration by using an XML file that is named the ClusterConfig.xml. You can still use PowerShell to make configuration changes but that does not need to be the exclusive means of configuration changes.
Note
You can change cluster configuration settings (XML attributes) in the ClusterConfig.xml file, but adding or removing named caches and cache hosts by inserting or removing XML elements is not supported. To add or remove named caches or cache hosts, use the PowerShell cache administration tool and the "Velocity" installer.
With the XML storage format, all configuration options are visible in a single file. You still must use the PowerShell administration tool to stop and start the cache cluster for changes to take effect, but it is not the only way to make configuration changes.
The PowerShell cache administration tool is the best answer for most configuration tasks. If you are only going to use PowerShell for these changes, all cluster configuration storage options are equally weighted. For more information about the available PowerShell commands, see Cache Administration with PowerShell (Velocity).
Cluster Configuration Availability
The cluster configuration storage location can be a single point of failure for your distributed cache system. For this reason, we recommend that you use Windows Server 2008 Failover Clustering, when you can, to optimize the availability of your cluster's configuration data. Consider whether Failover Clustering resources are available to your application (in your ecosystem) and balance that with the degree of availability required for your distributed cache system to decide which storage option to choose.
For example, your infrastructure may already have a clustered SQL Server database available for your cache-enabled application to use. Alternatively, there may not be a database available for your application to use, but there might be a "failover clustered" folder available from another Failover Clustering resource.
Cluster Size
When using the XML or SQL Server Compact data file storage formats for cluster configuration settings, the operating system that is used for the cache configuration storage location may limit the number of concurrent connections to the shared folder. In such cases, it is not supported to have the number of cache hosts in the cluster exceed that limit.
Note
Microsoft Windows XP, Microsoft Windows Server 2003, and the 32-bit version of Microsoft Windows Vista do not allow more than 10 concurrent connections to a shared network folder. We do not recommend that you use these operating systems to store the cache configuration settings for large clusters.
When you use a SQL Server database to store cluster configuration settings, a shared network folder is not required. But the same guidance per the maximum number of concurrent connections still applies. In SQL Server, the maximum number of concurrent connections is configured at the server level. The server may be configured not to have any limits on concurrent connections, but the database administrator may also configure that setting very low for administrative or other reasons.
When using a SQL Server database to store cluster configuration data, make sure that the SQL Server can support additional connections before you add cache hosts to the cache cluster.
See Also
Concepts
XML-Based Client Configuration (Velocity)
Programmatic Client Configuration (Velocity)
XML-Based Cluster Configuration (Velocity)
SQL Server Compact-Based Cluster Configuration (Velocity)
SQL Server-Based Cluster Configuration (Velocity)
Other Resources
Configuration Settings (Velocity)
Configuring the Cache Client with XML (Velocity)
Administration Guide (Velocity)
Programming Guide (Velocity)