Высокий уровень доступности (кэширование в AppFabric 1.1)

  • Статья

Если высокий уровень доступности включен, копия каждого кэшированного объекта или области хранится на отдельном узле кэша. Кластер кэша управляет хранением этих копий и предоставляет их приложению, если основные копии недоступны. Чтобы обеспечить высокую доступность приложений с поддержкой кэша изменять код не требуется. На следующем рисунке иллюстрируется хранение копий объектов и областей на отдельных узлах при включении высокого уровня доступности.

Обзор высокого уровня доступности Velocity

Настройка высокого уровня доступности

Высокий уровень доступности настраивается на уровне кэша в параметрах конфигурации кластера. Его можно включить в качестве свойства кэша при его создании с помощью команды New-Cache с параметром Secondaries равным 1. Таким образом командлетам Windows PowerShell администрирования кэша указывается необходимость создания одной копии каждого объекта или области. Если параметр Secondaries установить равным 0, высокий уровень доступности будет отключен. По умолчанию при создании кэша высокий уровень доступности отключен. Дополнительные сведения об изменении параметров конфигурации кэша см. в разделе Изменение параметров конфигурации кэша с помощью Windows PowerShell.

Для работы функции высокого уровня доступности, входящей в функции Кэш Microsoft AppFabric 1.1 для Windows Server, все узлы кластера кэша должны работать под управлением выпуска Enterprise Edition (или более высокого уровня) операционной системы Windows Server 2008 или Windows Server 2008 R2. Убедитесь, что все узлы кэша с высоким уровнем доступности работают под управлением поддерживаемой операционной системы. Дополнительные сведения о поддерживаемых операционных системах см. в разделе «Требования к программному обеспечению» руководства по установке AppFabric (https://go.microsoft.com/fwlink/?LinkId=169172).

Хранение дополнительных копий

Кластер кэша выбирает место для хранения дополнительных копий объектов и областей. AppFabric распределяет дополнительные копии между всеми узлами кэша в кластере так же, как и кэшированные объекты.

Обеспечение согласованности

Вне зависимости от того, включен ли высокий уровень доступности, приложения с поддержкой кэша работают так, как будто существует только основная копия кэшированного объекта. Все вызовы методов Add, Put и Remove сперва инициируются для основного объекта вне зависимости от того, на каком узле кэша он хранится. После инициации вызова в узел кэша, который обслуживает основной объект или область, итоговое действие отличается в зависимости от того, включен ли высокий уровень доступности.

Если высокий уровень доступности включен, то производится дополнительное действие, заключающееся в уведомлении узла, на котором хранится дополнительная копия, в том, что будет произведено изменение. Далее узел кэша с основной копией объекта ожидает подтверждения от другого узла, после чего посылает подтверждение клиенту о том, что операция завершена.

Например, рассмотрим узлы A и B на следующей схеме. Как только узел кэша A получает запрос, он начинает его обработку и уведомляет узел размещения кэша B об изменении. Затем узел кэша B отправляет подтверждение узлу кэша A. Получив подтверждение, узел кэша A завершает изменение и отправляет подтверждение приложению с поддержкой кэша. Этот процесс гарантирует, что дополнительная и основная копии объекта или области будут иметь одинаковые состояния. Подобная схема называется строгой согласованностью.

Согласованность высокого уровня доступности Velocity

Вопросы производительности

Так как узел кэша, на котором хранится дополнительная копия объекта или области, должен подтверждать все изменения, производимые с основной копией, время ожидания при запросах на запись со стороны приложения с поддержкой кэша немного увеличивается. Обратите внимание, что это не сказывается на производительности при чтении объектов, уже помещенных в кэш. Также следует принять во внимание время, которое необходимо для повторной загрузки объектов в кэш, если узел кэша, на котором хранятся основные копии этих объектов, будет отключен.

Последствия отказа узла кэша

Отказ узла кэша никак не сказывается на работе приложения с поддержкой кэша (при условии наличия достаточного числа узлов кэша для поддержания работоспособности кластера). Кластер кэша перенаправляет запросы объекта узлу кэша, на котором хранится дополнительная копия объекта. В пределах кластера дополнительные копии всех основных объектов становятся основными. Затем дополнительные копии этих новых основных объектов распределяются между другими узлами кэша в кластере. Дополнительные объекты, которые хранились на отказавшем узле кэша, заменяются новыми дополнительными объектами, которые распределяются в пределах кластера. То же самое происходит и с областями.

Чтобы функция высокого уровня доступности могла обеспечить работоспособность приложения в случае отказа узла кэша, кластер кэша должен включать по крайней мере три узла кэша. Это связано с требованием строгой согласованности, в соответствии с которым в кэше с высоким уровнем доступности всегда должны быть две копии кэшированного объекта или области. Для поддержания двух копий объекта или области, кэш с высоким уровнем доступности должен включать по крайней мере два узла кэша.

Например, был создан кэш с высоким уровнем доступности HACache в кластере кэша, включающем три сервера, как показано в следующей таблице. Предположим, что SQL Server был настроен на выполнение роли управления кластером (таким образом, нет необходимости учитывать возможное отключение ведущих узлов).

Время Узел кэша 1 Узел кэша 2 Узел кэша 3 HACache (именованный кэш с высоким уровнем доступности)

T1

работает

работает

работает

доступен

T2

работает

работает

остановлен

доступен

T3

работает

остановлен

остановлен

недоступен

На момент T1, когда доступны три узла кэша, две копии кэшированных объектов или областей могут храниться на одном из трех доступных серверов. На момент T2, при отказе одного из серверов кэша, кэш HACache по-прежнему будет доступен, так как все еще доступны два узла кэша, на которых могут храниться две копии кэшированных объектов или областей. На момент T3, при отказе второго узла кэша, кэш HACache становится недоступен. Это связано с отсутствием узла кэша для хранения второй копии кэшированных объектов или областей.

Дополнительные рекомендации по использованию высокого уровня доступности

Чтобы повысить доступность кэша, воспользуйтесь следующими рекомендациями.

  • Используйте большое число узлов кэша.

  • Развертывайте распределенную систему кэша в пределах зоны, защищенной брандмауэром, на серверах, входящих в один домен, включая клиенты кэша, узлы кэша, основной сервер источника данных и сервер, на котором хранятся данные конфигурации кластера.

  • Используйте SQL Server или поставщик данных для хранения параметров конфигурации кластера кэша.

  • Минимизируйте изменения конфигурации, требующие остановки кластера и связанные, таким образом, с высокими затратами. Для изменения конфигурации кэша в параметрах конфигурации кластера по возможности повторно создавайте именованные кэши вместо остановки всего кластера кэша.

  • Перед перезагрузкой сервера всегда используйте команду Stop-CacheHost для остановки службы кэша. Когда роль управления кластера выполняется ведущими узлами, командлет Stop-CacheHost не будет выполнен успешно, если остановка службы кэша приведет к завершению работы всего кластера кэша (вследствие остановки большинства ведущих узлов).

См. также

Основные понятия

Схема физической архитектуры кэширования AppFabric (кэширование в AppFabric 1.1)
Схема логической архитектуры кэширования AppFabric (кэширование в AppFabric 1.1)

  2012-03-05