Updating Cache Servers

A Microsoft AppFabric 1.1 for Windows Server cache cluster consists of one or more servers that work together to provide a unified in-memory cache. There are times when you must update one or more of the servers in a cache cluster, and these updates can require a reboot. This section provides cache cluster guidance for this patching scenario.

Scheduled Maintenance

The easiest solution to this problem is to schedule a maintenance window to perform updates on all cache servers. In this scenario, you stop the cache cluster with the Stop-CacheCluster command, update the computers, and then start the cache cluster with the Start-CacheCluster command. This works best for caches that have time-periods of lower demand. If the client applications have a steady demand for the cache cluster, then you can consider other options where the cache cluster stays up during the upgrades.

Sequential Cache Server Updates

It is possible to update individual cache servers while the cache cluster remains running. This requires that the cache cluster contain a minimum of two cache hosts. The basic process consists of the following steps:

1. Stop one of the servers in the cluster with the Stop-CacheHost command. If possible, use the Graceful switch to move the cached data off of that cache host before it stops.

2. Update and reboot that server.

3. Start the server by using the Start-CacheHost command.

4. Repeat the steps on each cache server sequentially.

Although these steps are straightforward, there are several considerations covered in the following sections.

Updating Lead Hosts

The cluster management role exists to successfully manage the cache hosts in a cache cluster. If you use the XML provider for storing the cache cluster configuration settings, then this role is performed by designating some of the cache hosts as lead hosts. In order for the cache cluster to stay operational, a majority of lead hosts must be running. This affects sequentially updating cache servers. Consider the following two server cache cluster.

In this example, CacheServer1 is the lead host in this two-node cache cluster. Because a majority of lead hosts must stay running, you cannot stop CacheServer1 without stopping the cache cluster. In this example, it does not help to make both servers lead hosts, because bringing down one of the servers would not leave a majority of lead hosts running. To solve this problem, you can add another cache host server and make all servers lead hosts with the Export-CacheClusterConfig and Import-CacheClusterConfig commands. For more information about how to change the designated lead hosts, see Set the Cluster Management Role and Lead Host Designations. Consider the cache cluster following these changes.

In this new configuration, all three servers are lead hosts. It is now possible to bring one cache server down at a time to perform updates.

Note that the System.Data.SqlClient provider does not experience this issue, because SQL Server performs the cluster management role instead of lead hosts. For more information about lead hosts, see Lead Hosts and Cluster Management.

Updating Cache Hosts with Caches that use High Availability

High availability creates secondary copies of cached items on another cache host. If the primary cache host becomes unavailable, the cached item is provided from the secondary cache host. Therefore, the cached data is not lost. For more information about this feature, see High Availability. By definition, high availability requires at least three servers to exist in the cache cluster. The cached item can exist on one server, have a secondary copy on another server, and rely on the third server to fulfill the high availability requirements if either the primary or secondary servers go down. If you only have two cache hosts running, then you will be unable to stop either of them individually, because the third server is not present to maintain high availability.

You can use a Windows PowerShell script to determine whether one or more of your caches use the high availability feature. The following PowerShell script provides an example that cycles through each cache and checks the Secondaries property.

Import-Module DistributedCacheAdministration

Use-CacheCluster

$Caches = Get-Cache -MaxRegions 0
$HighAvailability = $false

foreach ($Cache in $Caches)
{
   $CacheConfig = Get-CacheConfig $Cache.CacheName
   if ($CacheConfig.Secondaries -eq 1)
   {
      Write-Host $CacheConfig.CacheName
      $HighAvailability = $true
   }
}

if ($HighAvailability -eq $true)
{
   Write-Host "One or more caches use high availability (Secondaries = 1)"
}
else
{
   Write-Host "No caches use high availability (Secondaries = 1)"
}

Even if you have more than two servers in your cache cluster, you should check their running status with Get-CacheHost before you begin updating them sequentially.

Client Application Considerations

When sequentially updating the cache hosts without stopping the cache cluster, there are several important considerations for the client applications that access use the cache cluster.

1. Applications reference one or more cache hosts by name in order to initially connect to the cache cluster. This is accomplished either in the application configuration file or programmatically. If the client application only points to one cache host, then it will be unable to make new connections to the cache cluster as long as that host is down. Client applications should reference more than one cache host when it is possible. Note that client applications do not have to reference all of the cache hosts. The referenced cache hosts act as a gateway to the whole cluster.

2. When a cache host is stopped, applications may not find items that were previously located on the stopped cache host. The application is responsible for repopulating those items.

3. When a cache host is stopped, applications may temporarily receive various DataCacheException exceptions. These should resolve automatically as the cache cluster adapts to the loss of a cache host. Applications should be designed to expect common exceptions. Clients can either decide to implement retry logic or they can use source data until the exceptions resolve. For more information, see Handling Errors.

4. When a cache host is stopped, applications might not be able to temporarily write to a cache that uses high availability. After the cache host stops, new copies of cached items (secondaries) are created on another cache host.

See Also

Concepts

Common Cache Cluster Management Tasks (Windows Server AppFabric Caching)

  2012-10-26