SQL Server-Based Cluster Configuration (Velocity)

  • Article

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

By selecting the SQL Server-based cluster configuration storage option in Microsoft project code named "Velocity," the cluster can use a SQL Server database to track the cluster configuration information. This database is automatically prepared during installation for managing the cluster configuration. "Velocity" then uses this database as the primary point of reference for defining the cache cluster, cache hosts, and named caches. All cache servers in the cluster must be able to access the cluster configuration database.

For more information about preparing a SQL Server database for the cluster configuration storage location, see How to: Prepare a SQL Server Database for Cluster Configuration Settings (Velocity).

Before installing "Velocity" on the first cache server, you must create a database that you can provide to the installation program to use for installing the necessary database tables. All cache servers in the cluster must be able to access the cluster configuration database.

Note

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 Microsoft Windows Server 2008 Failover Clustering to host a "clustered" database resource for the cache cluster configuration storage location. Doing this optimizes the availability of your cluster's configuration data.

Permissions

All of the cache hosts must have logon permissions to the database server that hosts the cluster configuration database. The cluster configuration database must also have its security settings configured so that each cache server has a SQL Server login, db_datareader, db_datawriter , and EXECUTE permissions to the database.

Note

The installation program will attempt to configure these permissions automatically. Note that the security identity of the person performing the installation must have db_owner permissions to the SQL Server database, and a SQL Server login to the instance of SQL Server.

To simplify long term administration of the cluster configuration database, we do not recommend running the "Velocity" service under the credentials of a domain user account. By using the default installation settings, you can use the domain computer accounts of the cache servers instead and avoid password maintenance.

If you create a Windows security group to manage access to the cache configuration database, you need only set up SQL Server logon and database permissions once. For example, you could set up a Windows security group named ClusterACacheServers to indicate the cache servers that have permission to become part of cache cluster ClusterA.

After you create the ClusterACacheServers security group, grant the domain computer accounts of the applicable cache servers membership to this group (for example, domain\computername$). Then grant the ClusterACacheServers security group a SQL Server login, db_datawriter, db_datareader , and EXECUTE permissions to the database. Once you set this up, every time that you add a server to the cache cluster, you need only add the domain computer account of the new server to the security group.

Database Structure

When you install "Velocity" for the first time with the SQL Server-based configuration option, the installation program creates many tables in the database that you specified. There are also some stored procedures added for internal operations of the cluster.

Note

The data in the cluster configuration database is not meant to be edited manually. To help ensure continuous operation of the cluster, only the cache hosts themselves and the installation program should write to the database.

Database Security

Use of passwords in connection strings presents a security risk and should be avoided whenever possible. Connections strings are stored in clear text in the cache host configuration file on each cache server, in DistributedCache.exe.config. To minimize such risks, use integrated security to make a trusted connection with SQL Server. By using this approach, you do not have to store a password in the connection string. In the absence of integrated security, a clear-text password will be needed in the connection string. The best way to help secure your connection string is as follows, in increasing order of risk:

  1. Use integrated security.

  2. Secure connection strings with passwords and minimize passing around connection strings.

  3. Minimize lifetimes and touch points for all connection strings.

Database Connections

When you use a SQL Server 2005 or later database to store cluster configuration settings, make sure that the server is configured to allow enough concurrent connections to accommodate all cache hosts in the cluster. It is not supported for the number of cache hosts in the cluster to exceed the amount of available concurrent connections.

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. In such cases, make sure that the server can support additional connections before you add cache hosts to the cache cluster.

See Also

Concepts

Shared Folder-Based Cluster Configuration (Velocity)
Cluster Configuration Settings (Velocity)
Client Configuration Options (Velocity)

Other Resources

Configuring the Cache Cluster (Velocity)
Administration Guide (Velocity)
Programming Guide (Velocity)