Ведущие узлы и управление кластером (кэширование в Windows Server AppFabric)

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

В зависимости от способа развертывания системы распределенного кэша у роли управления кластером есть два варианта действий. Если параметры конфигурации кластера хранятся в базе данных SQL Server, то данный экземпляр SQL Server также может использоваться для выполнения роли управления кластером.

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

В следующей таблице показано, как выбор во время установки связан с вариантами управления кластером. Дополнительные сведения о выборе подходящих параметров конфигурации см. в разделе Способы хранения конфигурации кластера (кэширование в Windows Server AppFabric).

Задачи роли управления кластером

Есть два основных параметры конфигурации, которые определяют порядок функционирования кластера в отношении управления кластером.

• leadHostManagement: этот параметр уровня кластера определяет, где будет выполняться роль управления кластером. Если параметр имеет значение «true», роль управления кластером выполняют ведущие узлы. Если для хранения параметров конфигурации кластера выбрана общая сетевая папка, то значение true» является единственным допустимым значением для этого параметра. Значение «false» означает, что роль управления кластером будет выполнять SQL Server или настраиваемый поставщик. При использовании SQL Server или настраиваемого поставщика для хранения параметров конфигурации кластера можно установить значение этого параметра равным «true» и позволить ведущим узлам выполнять роль управления кластером.

• leadHost: этот параметр уровня кластера определяет, какие узлы кэша будут являться ведущими узлами при выполнении роли управления кластером. Даже если для выполнения роли управления кластером выбран SQL Server, программа установки назначает ведущие узлы на случай, если позднее будет изменен параметр leadHostManagement.

Дополнительные сведения об изменении этих параметров см. в разделе Назначение роли управления кластером и ведущих узлов (кэширование в Windows Server AppFabric).

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

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

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

При сбое ведущего узла

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

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

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

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

Назначение дополнительных ведущих узлов

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

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

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

• В больших кластерах для устойчивой работы кластера в пределах 50 серверов кэша достаточно от пяти до семи ведущих узлов.

Дополнительные сведения об изменении конфигурации ведущих узлов см. в разделе Назначение роли управления кластером и ведущих узлов (кэширование в Windows Server AppFabric).

Когда SQL Server выполняет роль управления кластером

Если параметр кластера leadHostManagement имеет значение false, то независимо от параметра leadHost каждый узел кэша выполняет только свои обычные (не относящиеся к ведущим узлам) обязанности, связанные с кэшированием данных. В этом сценарии экземпляр SQL Server, используемый для хранения параметров конфигурации кластера, также используется для выполнения роли управления кластером.

В случае отказа сервера

Для поддержания доступности кластера в случае, если роль управления кластером выполняет SQL Server, по меньшей мере один узел кэша должен иметь доступ к базе данных SQL Server.

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

В этом примере роль управления кластером выполняет SQL Server; все шесть узлов кэша могут предоставлять свои ресурсы клиентам кэша для доступа к данным.

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

Сбой SQL Server вызывает завершение работы кластера через несколько минут. Для устранения этой проблемы рекомендуется использовать отказоустойчивый кластер Microsoft Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=130692) для размещения «кластерной» базы данных в качестве расположения хранилища конфигурации кластера кэша и роли управления кластером.

См. также

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

Схема физической архитектуры кэширования Windows Server AppFabric
Схема логической архитектуры кэширования Windows Server AppFabric
Параметры конфигурации кластера (кэширование в Windows Server AppFabric)
Назначение роли управления кластером и ведущих узлов (кэширование в Windows Server AppFabric)

  2011-12-05