Cluster Configuration Storage Options (Velocity)

[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]

Microsoft project code named "Velocity" allows the option of storing your cache cluster configuration settings in a shared folder or in a SQL Server database. This topic describes considerations for choosing either option.

When you select the shared folder-based cluster configuration storage option, 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.

Note

The cluster configuration storage location should not be located on any of the cache servers. It should be on a computer in the same domain as the cache servers, primary data source server, and cache clients—all within the perimeter of the corporate firewall.

Editing Configuration Settings

Choices for editing the cluster configuration settings are not determined by how you store the configuration settings. In each case, whether SQL Server or shared folder, you can edit configuration settings with PowerShell or by using the PowerShell Export-CacheClusterConfig and Import-CacheClusterConfig commands to edit configuration settings directly with XML. For more information, see Configuring the Cache Cluster (Velocity).

Selecting Configuration Storage Options

When you decide which storage option to use for cluster configuration settings, there are four primary factors involved in the decision:

  • Cluster management options: Do you want SQL Server or lead hosts to perform the cluster management role?

  • High-availability resources: What highly available resources do you have at your disposal? For example, does your organization already have a "clustered" SQL Server resource available for your distributed cache system to use?

  • Cluster size: Do you want a large cluster? Large clusters may have contention issues when using shared network folders to host the configuration settings. Some operating only systems support a limited number of concurrent connections.

Cluster Management Options

There are two options for how the cluster management role is performed, depending on how you deploy your distributed cache system. For more information, see Lead Hosts and Cluster Management (Velocity).

If you store your cluster configuration settings in a SQL Server database, that SQL Server instance can also be used to perform the cluster management role. If you choose to store your cluster configuration settings in a shared folder, the cluster management role is always performed by special cache hosts, referred to as lead hosts. This is illustrated in the following table:

cluster configuration storage type cluster configuration storage location cluster management

SQL Server Compact data file

shared network folder

lead hosts

SQL Server database

SQL Server

SQL Server (default) or lead hosts

Your High-Availability Resources

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 which "clustered" resources are available to your application (in your ecosystem) and balance that with the degree of availability required for your distributed cache system in order to decide which storage option is best for you.

For example, your infrastructure may already have a "clustered" SQL Server database available to store your configuration settings. Alternatively, there may be a "clustered" folder available for you to deploy a shared folder-based cluster configuration.

Cluster Size

When using a shared folder to store your 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. With SQL Server, there are not the same limits on concurrent connections as there are for shared folders. Instead, a maximum number of concurrent connections to the instance of SQL Server can be imposed by the database administrator. 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, or the database administrator may 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 instance of SQL Server can accommodate additional connections before you add cache hosts to the cache cluster.

Storage Option Details

For more details about each of these options, see the topics listed in the following table.

Topic Description

Shared Folder-Based Cluster Configuration (Velocity)

Describes what is involved when specifying a shared folder-based cluster configuration location.

SQL Server-Based Cluster Configuration (Velocity)

Describes what is involved when specifying a SQL Server-based cluster configuration location.

See Also

Concepts

Cluster Configuration Settings (Velocity)
Lead Hosts and Cluster Management (Velocity)
Cluster Configuration Settings (Velocity)

Other Resources

Configuring the Cache Cluster (Velocity)
Installation and Deployment (Velocity)