Cluster Management and Lead Host Designations
There are two main configuration settings that determine how the cluster functions with respect to cluster management:
leadHostManagement : This cluster-level setting determines what will perform the cluster management role. When true, lead hosts perform the cluster management role. If you have chosen to store your cluster configuration settings in a shared network folder, true is the only valid value for this setting. False indicates that SQL Server will perform the cluster management role. If you have chosen to store your cluster configuration settings in SQL Server, this setting will default to false. When using SQL Server to store cluster configuration settings, you can set this setting to true and let lead hosts perform the cluster management role.
quorumHost : This cache host-level setting determines which cache hosts will be lead hosts when lead hosts perform the cluster management role. Even if SQL Server is going to perform the cluster management role, the installation program designates lead hosts, in case you later change the LeadHostManagement setting.
For more information about changing these settings, see How to: Set the Cluster Management Role and Lead Host Designations (Velocity).
Note
The "quorum" reference is a term that was used in a previous community technology preview (CTP) of "Velocity" to refer to a lead host. The name of this setting may change in the future.
| leadHost-Management cluster-level setting | quorumHost cache host setting | Setting combination description | Effective cache host responsibilities |
| FALSE | FALSE | SQL Server performs the cluster management role. This is not a lead host. | Normal cache host operations only. |
| FALSE | TRUE | SQL Server performs the cluster management role. This is a lead host if you change the leadHostManagement setting to true. | Normal cache host operations only. |
| TRUE | FALSE | Lead hosts perform the cluster management role, but this is not a lead host. | Normal cache host operations only. |
| TRUE | TRUE | Lead hosts perform the cluster management role. This is a lead host. | Normal cache host operations and works with other lead hosts to manage the cluster. |
Cache Notifications (Velocity)
To receive asynchronous cache notifications, add a cache notification callback to your application. When you add the callback, you define the types of cache operations that trigger a cache notification and which method in your application should be called when the specified operations occur. This topic describes the process in detail.
Note
In order to use cache notifications, you will have to enable cache notifications on a named cache with the New-Cache or Set-CacheConfig PowerShell cmdlets from the PowerShell-based cache administration tool. You also need to configure your application to use a routing client.
Triggering Cache Notifications
As shown in the following figure, changes to both regions and cached objects (referred to as items within the cache) can trigger cache notifications.
These cache operations are defined by members of the DataCacheOperation class.
Region Operations
Your application can receive cache notifications when the following cache operations occur on a region.
CreateRegion: When a region is created in the cache.
ClearRegion: When a region is cleared in the cache.
RemoveRegion: When a region is removed from the cache.
Item Operations
Your application may receive cache notifications when the following cache operations occur on a cached object (referred to as an item within the cache).
AddItem: When an item is added to the cache.
ReplaceItem: When an item is replaced in the cache.
RemoveItem: When an item is removed from the cache.
Posted in: C# and .NET| Tags: Velocity CTP CTP 3 Distribute Cache Cache NotificationWhat Happens When a Cache Host Fails
If a cache host fails (assuming there are still a sufficient number of cache hosts available to keep the cluster running) nothing changes for the cache-enabled application. The cache cluster re-routes requests for the object to the cache host that maintained the secondary copy of the object. Within the cluster, the secondary copies of all the primary objects are then elevated to become the new primary objects. Then, secondary copies of those new primary objects are distributed to other cache hosts across the cluster. Secondary objects on the cache host that failed are replaced by new secondary objects and distributed across the cluster. This process also applies to regions.
For the high availability feature to help insulate your application from the failure of a cache host, at least three cache hosts must be members of the cache cluster. This is due to a strong consistency requirement stating that there must always be two copies of a cached object or region in a high availability-enabled cache. In order to maintain two copies of a cache or region, a high availability-enabled cache requires at least two cache hosts to function.
For example, perhaps you have created a high availability-enabled cached named HACache in a three-server cache cluster as shown in the following table. Assume that SQL Server was configured to perform the cluster management role (so that this example does not need to consider the potential loss of lead hosts).
| Time | Cache host 1 | Cache host 2 | Cache host 3 | HACache (high availability-enabled named cache) |
| T1 | running | running | running | available |
| T2 | running | running | stopped | available |
| T3 | running | stopped | stopped | not available |
At T1, when there are three cache hosts available, two copies of cached objects or regions can be stored on one of three available servers. At T2, when one cache server fails, HACache continues to be available because there are still two cache hosts available to store the two copies of cached objects or regions. At T3, when the second cache host fails, HACache becomes unavailable. This is because there is no longer another cache host available to store the second copy of cached objects or regions.
High Availability (Velocity)
The high availability feature in Microsoft project code named "Velocity" supports continuous availability of your cached data by storing copies of that data on separate cache hosts. When you have high availability enabled on a multi-server cluster, your application can still retrieve its cached data if a cache server fails.
Without high availability enabled, "Velocity" can provide some protection for your cached data because objects not stored in regions are distributed across all hosts in the cluster. Due to this distributed nature, the more cache servers there are in the cluster, the less chance there is that a single server failure can affect the data that your application was using. With high availability enabled, server failures pose even less risk to your application.
The high availability feature helps guard against computer and process failures from individual cache hosts while the cluster is running. There may also be scenarios when the entire cluster goes down. For this reason, your application code should be designed so that it can function without the cache, and not require that cached data always be available. Because data in the cache is not persisted in a durable fashion, there is always the possibility that it may become unavailable to your application, even with the high availability feature enabled.
Note
For the high availability feature to help insulate your application from the failure of a cache host, at least three cache hosts must be members of the cache cluster. Due to strong consistency requirements, there must always be two cache hosts in order for a high availability-enabled cache to function. It is also important to consider that the failure of a lead host in a small lead host-managed cluster may force the entire cluster to shut down. For more information, see Lead Hosts and Cluster Management (Velocity).
How High Availability Works
When high availability is enabled, a copy of each cached object or region is maintained on a separate cache host. The cache cluster manages maintenance of these copies and supplies them to your application if the primary copies are not available. No code changes are required to make your cache-enabled applications highly available. The following figure illustrates how copies of objects and regions are stored on separate hosts when the high availability feature is enabled.
High Availability Configuration
High availability is configured at the cache level in the cluster configuration settings. As a property of the cache, you can enable it when you first create the cache using the New-Cache command with the Secondaries parameter equal to 1. This tells the cache administration PowerShell cmdlets that you want one copy of each cached object or region. If you set the Secondaries parameter to 0, you disable the high availability feature. By default, the high availability option is disabled when you create a new cache. For more information about editing cache configuration settings, see How to: Edit Cache Configuration Settings with PowerShell (Velocity).
Secondary Copy Storage
The cache cluster chooses where the secondary copies of objects and regions are stored. Just as "Velocity" distributes cached objects across all cache hosts in the cluster, it also distributes the secondary copies of those objects across all cache hosts in the cluster.
How Consistency is Maintained
Regardless of whether high availability is enabled or not, cache-enabled applications work as if only the primary copy of the cached object exists. All Add, Put, and Remove method calls are first initiated on the primary object on whichever cache host they reside. Only after those calls are initiated to the cache host maintaining the primary object or region is there any difference in what occurs.
If high availability is enabled, there is an added step of notifying the host maintaining the secondary copy that a change is about to occur. Then, the cache host with the primary copy of the object waits for an acknowledgement from the other host before acknowledging back to the client that the operation is complete.
For an example, see cache hosts A and B in the following diagram. As soon as cache host A receives a request, it starts processing the request and notifies cache host B of the change. Then cache host B sends an acknowledgement back to cache host A. When cache host A receives the acknowledgement, it finishes the change and sends an acknowledgement back to the cache-enabled application. This process makes sure that the secondary copy of the object or region is always in the same state as the primary. This process is referred to as strong consistency.
Performance Considerations
Because the cache host maintaining the secondary copy of the object or region must acknowledge all changes that pertain to the primary copy, there is a small performance cost in the response time to the cache-enabled application. Whatever that cost may be, you also want to consider how long it will take to reload the cache with those objects if the cache host that maintains the primary copies of those objects is lost.
Expiration in Velocity, Microsoft’s Distribute Cache
Cached objects do not remain in memory permanently in Microsoft project code named "Velocity." In addition to being explicitly removed from cache by use of the Remove method, cached objects may also expire or be evicted by the cache cluster.
Expiration
Cache expiration allows the cache cluster to automatically remove cached objects from the cache. When using the Put or Add methods, an optional object time-out value can be set for the particular cached object that will determine how many minutes it will reside in cache. If the object time-out value is not provided at the time the object is cached, the values specified in the cluster configuration settings for the named cache are used to determine the lifetime of the object in cache.
When cached objects are locked for the purposes of concurrency, they will not be removed from cache even if they are past their expiration. As soon as they are unlocked, they will be immediately removed from cache if past their expiration.
To prevent instant removal when you unlock expired objects, the Unlock method also supports extending the expiration of the cached object. For more information about the supported concurrency models and methods, see Concurrency Models (Velocity) and Concurrency Methods (Velocity).
Local Cache Invalidation
Once objects are downloaded to local cache, your application continues to use those objects until they are invalidated, regardless of whether those objects are updated by another client on the cache cluster. For this reason, it is best to use local cache for data that changes less frequently. There are two types of invalidation for local cache: timeout-based invalidation and notification-based invalidation.
Timeout-based Invalidation
Once objects are downloaded to local cache, they stay there until they reach the object timeout value specified in the client configuration settings (ttlValue in the app.config file). Once they reach this time-out value, objects are invalidated so that the object can be refreshed from the cache cluster the next time that it is requested.
Note
Your application continues to use objects stored in the local cache until they reach the end of their lifetimes, regardless of whether those objects are updated by another client on the cache cluster. For this reason, it is best to use local cache for data that changes infrequently.
To specify timeout-based cache invalidation for local cache set the sync attribute in the localCache element to TTLBased. For more information about application configuration settings, see Application Configuration Settings (Velocity).
Notification-based Invalidation
If local cache is enabled on a routing client, you may also use cache notifications to automatically invalidate your locally cached objects. By shortening the lifetime of those objects on an "as needed" basis, you can reduce the possibility that your application is using stale data.
When you use cache notifications, your application checks with the cache cluster on a regular interval to see if any new notifications are available. This interval, called the polling interval, is every 300 seconds by default. The polling interval is specified in units of seconds in the application configuration settings. To specify a specific interval, use can use the pollInterval attribute of the clientNotifications element in the application configuration file. You can also specify a specific polling interval programmatically with the DataCacheFactory constructor.
Note
In order for your application to use notifications you will need to enable them on a named cache. Use the notificationsEnabled parameter with the New-Cache or Set-CacheConfig commands. For more information, see Cache Administration with PowerShell (Velocity).
To specify notification-based cache invalidation for local cache set the sync attribute in the localCache element to NotificationsBased. When notification-based invalidation is chosen for local cache, any specified timeout value is ignored. For more information, see How to: Enable Local Cache (XML) (Velocity).
Eviction
In order to maintain the memory capacity available for cache on each cache host, "Velocity" supports least recently used (LRU) eviction. Thresholds, referred to as watermarks, are used to make sure that memory is evenly distributed across all cache hosts in the cluster.
When the memory consumption of the cache host service on a cache server exceeds the low watermark threshold, "Velocity" starts evicting objects that have already expired.
When memory consumption exceeds the high watermark threshold, objects are evicted out of memory, regardless of whether they have expired or not, until memory consumption goes back down to the low watermark. Subsequently cached objects may be rerouted to other hosts in order to maintain an optimal distribution of memory.
Posted in: C# and .NET| Tags: NET Velocity CTP CTP 3 Distribute Cache .NET 4.0 ExpirationOptimistic Concurrency Model in Velocity
To mitigate security risks, all cache clients, cache servers, and the primary data source server should be members of the same corporate domain, and should be deployed within the perimeter of the corporate firewall. It is also highly recommended to secure your application configuration files on the cache clients.
To help your application deal with concurrency issues, "Velocity" supports optimistic and pessimistic concurrency models. For information about the methods available to align to these models, see Concurrency Methods (Velocity).
Optimistic Concurrency Model
In the optimistic concurrency model, updates to cached objects do not take locks. Instead, the cache client first reads the version of the object to be updated and then sends that version information together with the updated object to the cache for an update. The system only updates the object if the version sent matches the current version of the object. Every update to an object changes its version number, which prevents the update from overwriting someone else’s changes.
The example in this topic illustrates how optimistic concurrency maintains data consistency.
Example
In this example, two cache clients (cacheClientA and cacheClientB) on two separate application servers try to update the same cached object, which is named RadioInventory.
Time Zero: Both Clients Retrieve the Same Object
At time zero (T0), both cache clients instantiate a DataCacheItem class to capture the cached object that they intend to update, together with additional information associated with that cached object, such as version and tag information. This is illustrated in the following diagram and code example.
Client types in Velocity: Simple
Routing Client
The routing client offers better performance than the simple client because it contains a routing table that is kept up to date by the lead hosts. The routing table is used to track cached object placement across all cache hosts in the cluster and identifies all cache hosts in the cluster. The routing client uses this table to optimize performance by making requests to the cache host where the object is physically located. For information about how to configure a routing client, see How to: Get Started with a Routing Client (XML) (Velocity) and How to: Get Started with a Routing Client (Code) (Velocity).
Note
In order to use a routing client, the computer that is running the cache-enabled client application must have network connectivity to all cache servers in the cluster.
Simple Client
Whenever possible, the routing client should always be used. Due to networking topologies, there may be cases where client applications can only access some of the cache servers in the cache cluster. In those cases, the simple client can be used to provide distributed cache resources.
To work in scenarios of limited cache server connectivity, the simple client has been designed to only require access to one cache host in the cluster. It has no routing capabilities and does not track where each cached object is stored. Because the simple client has no routing capabilities, requested cached objects often have to traverse additional cache hosts before reaching the simple client. This indirect path makes the simple client less efficient than the routing client.
For more information about how to configure a simple client, see How to: Get Started with a Simple Client (XML) (Velocity) and How to: Get Started with a Simple Client (Code) (Velocity).
Posted in: C# and .NET| Tags: NET Velocity CTP CTP 3 Distribute Cache .NET 4.0 Client Types Routing Client Simple ClientNamed Caches in Velocity
A named cache, also referred to as a cache, is a configurable unit of in-memory storage that all applications use to store data in the distributed cache. You can configure one or more named caches for each of your applications. Each cache can be configured independent of the others, which lets you to optimize the policies of each cache for your application.
As you saw in the previous diagram, each cache spans all cache hosts in the cluster. When "Velocity" is first installed, a cache comes pre-configured with the name "default." If you do not specify a particular cache name when performing cache operations, data is stored in this default cache.
All caches are defined in the cluster configuration. Use the PowerShell cache administration tool to create or reconfigure caches. Some settings can only be configured when you first create the cache. For example, you can only enable the high availability or notifications feature using the New-Cache command. Other settings can be changed later, but may require the entire cache cluster to be restarted. For more information about the PowerShell cmdlets, see Cache Administration with PowerShell (Velocity).
Note
Restarting your cache cluster causes all data to be flushed from all named caches in the cluster.
Posted in: C# and .NET| Tags: NET Velocity CTP CTP 3 Distribute Cache .NET 4.0 Named Caches