Обновление серверов кэша
Кластер кэша Microsoft AppFabric 1.1 для Windows Server состоит из одного или нескольких серверов, которые работают совместно и предоставляют единый кэш в памяти. В некоторых ситуациях необходимо обновить один или несколько серверов в кластере кэша, причем такие обновления могут потребовать перезагрузки. В этом разделе приводятся сведения по обновлению кластера кэша.
Запланированное обслуживание
Наиболее легким решением этой проблемы является планирование обслуживания для обновления всех серверов кэша. В этом случае кластер кэша останавливается с помощью команды Stop-CacheCluster
, компьютеры обновляются, а затем кластер запускается снова с помощью команды Start-CacheCluster
. Это оптимально для кэшей, которые в течение определенного времени имеют небольшую нагрузку. Если клиентские приложения регулярно используют кластер кэша, то можно рассмотреть другие методы обновления, при которых кластер кэша не прерывает работу.
Последовательные обновления сервере кэша
Отдельные серверы кэша можно обновлять, не отключая кластер. Для этого кластер должен содержать минимум два узла кэша. Эта процедура выполняется в три этапа:
Остановите один из серверов в кластере с помощью команды
Stop-CacheHost
. Используйте параметрGraceful
, чтобы переместить все данные, кэшированные на останавливаемом узле, перед его остановкой.Обновите и перезапустите этот сервер.
Запустите сервер, используя команду
Start-CacheHost
.Последовательно повторите эти действия на каждом из серверов.
Несмотря на то, что эти действия достаточно просты, необходимо учитывать некоторые особенности, описанные в следующих разделах.
Обновление ведущих узлов
Роль управления кластером позволяет успешно управлять узлами кэша в кластере. При использовании поставщика XML для хранения параметров конфигурации кластера эта роль выполняется путем назначения некоторых узлов кэша в качестве ведущих. Чтобы кластер кэша оставался в рабочем состоянии, необходимо запустить большую часть ведущих узлов. Это влияет на последовательное обновление серверов кэша. Рассмотрим следующий кластер из двух серверов.
Имя узла | Является ведущим узлом? |
---|---|
CacheServer1 |
Да |
CacheServer2 |
Нет |
В этом примере CacheServer1
является ведущим узлом в кластере, состоящим из двух узлов. Так как для сохранения рабочего состояния должна использоваться большая часть ведущих узлов, то остановка CacheServer1
без остановки кластера невозможна. В этом примере назначение обоих узлов ведущими не будет являться выходом из ситуации, так как отключение одного из серверов не приводит к ситуации, в которой работает большинство серверов. Чтобы решить эту проблему, можно добавить другой сервер узла кэша и сделать все серверы ведущими с помощью команд Export-CacheClusterConfig
и Import-CacheClusterConfig
. Дополнительные сведения об изменении указанных ведущих узлов см. в разделе Назначение роли управления кластером и ведущих узлов. Просмотрите кластер после внесения этих изменений.
Имя узла | Является ведущим узлом? |
---|---|
CacheServer1 |
Да |
CacheServer2 |
Да |
CacheServer3 |
Да |
В новой конфигурации все серверы являются ведущими узлами. Теперь один из серверов кэша можно отключить для обновления.
Обратите внимание на то, что поставщик System.Data.SqlClient не вызывает этой ошибки, так как SQL Server выполняет роль управления кластером вместо ведущих узлов. Дополнительные сведения о ведущих узлах см. в разделе Ведущие узлы и управление кластером.
Обновление узлов кэша кэшами с высоким уровнем доступности
Высокий уровень доступности позволяет создать дополнительные копии кэшированных элементов на другом узле. Если основной узел кэша становится недоступным, то кэшированный элемент можно получить со вторичного узла кэша. Таким образом, кэшированные данные не будут утеряны. Дополнительные сведения об этой функции см. в разделе Высокий уровень доступности. Высокий уровень доступности согласно определению требует наличия минимум трех серверов в кластере. Кэшированный элемент может существовать на одном сервере, иметь дополнительную копию на другом сервере и использовать третий сервер для соответствия требованиям высокой доступности, если основной или дополнительный серверы отключатся. При наличии двух узлов кэша их остановка по отдельности будет невозможной, так как высокий уровень доступности не обеспечивается третьим сервером.
Скрипт Windows PowerShell позволяет определить возможность использования высокого уровня доступности в одном или нескольких кэшах. Следующий скрипт PowerShell циклически обрабатывает кэши и проверяет свойство Secondaries
.
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)"
}
Даже при наличии более двух серверов в кластере кэша необходимо проверять их состояние с помощью команды Get-CacheHost
перед запуском последовательного обновления.
Рекомендации для клиентских приложений
При последовательном обновлении узлов кэша без остановки кластера необходимо учитывать некоторые рекомендации для клиентских приложений, использующих кластер.
Приложения ссылаются на один или несколько узлов кэша по имени, чтобы выполнить первое подключение к кластеру. Это выполняется в файле конфигурации приложения или программным образом. Если клиентское приложение указывает только на один узел кэша, то установка новых подключений к кластеру кэша будет невозможно, если этот узел отключен. Клиентские приложения по возможности должны ссылаться на несколько узлов кэша. Обратите внимание на то, что клиентские приложения могут не ссылаться на все узлы кэша. Ссылочный кэш служит шлюзом для всего кластера.
При остановке узла приложения могут не обнаружить элементы, которые ранее были расположены на остановленном узле. Приложение должно выполнять повторное наполнение этих элементов.
Если узел кэша остановлен, то приложения могут получать различные исключения DataCacheException. Они будут устранены автоматически по мере того, как кластер адаптируется к потере узла кэша. Приложения должны обрабатывать стандартные исключения. Клиенты могут реализовать логику повтора или использовать исходные данные до устранения исключений. Дополнительные сведения см. в разделе Обработка ошибок.
При остановке узла кэша в некоторых случаях запись в кэш с высоким уровнем доступности будет невозможна. После остановки узла кэша новые (дополнительные) копии кэшированных элементов будут созданы на другом узле кэша.
См. также
Основные понятия
Часто выполняемые действия по управлению кластером кэша (кэширование Windows Server AppFabric)
2012-03-05