Ця документація переміщена в архів і не підтримується.
Кластер кеша Windows Server AppFabric - це динамічна група серверів, які працюють разом як єдиний логічний кеш для даних додатків. Для управління операціями кластера між вузлами кеша потрібні певні додаткові витрати. Роль управління кластером відповідає за управління вузлами кеша і самим кластером кеша.
Залежно від способу розгортання системи розподіленого кешу у ролі управління кластером є два варіанти дій. Якщо параметри конфігурації кластера зберігаються в базі даних SQL Server, то даний екземпляр SQL Server також може використовуватися для виконання ролі управління кластером.
Якщо для зберігання параметрів конфігурації кластера обрана загальна мережева папка, то роль управління кластером завжди виконується спеціальними вузлами кешу, званими провідними вузлами. Провідні вузли виконують такі ж завдання, що і інші вузли кешу, що не призначені провідними, проте вони додатково відповідають за виконання ролі управління кластером спільно з з іншими провідними вузлами.
У наступній таблиці показано, як вибір під час установки пов'язаний з варіантами управління кластером. Додаткові відомості про вибір відповідних параметрів конфігурації див. Розділ Способи зберігання конфігурації кластера (кешування в Windows Server AppFabric).
Тип сховища конфігурації кластера
Розташування сховища конфігурації кластера
Завдання ролі управління кластером
Є два основних параметри конфігурації, які визначають порядок функціонування кластера щодо управління кластером.
- leadHostManagement. цей параметр рівня кластера визначає, де буде виконуватися роль управління кластером. Якщо параметр має значення «true», роль управління кластером виконують провідні вузли. Якщо для зберігання параметрів конфігурації кластера обрана загальна мережева папка, то значення true »є єдиним допустимим значенням для цього параметра. Значення «false» означає, що роль управління кластером буде виконувати SQL Server або настроюється постачальник. При використанні SQL Server або настроюваного постачальника для зберігання параметрів конфігурації кластера можна встановити значення цього параметра рівним «true» і дозволити провідним вузлам виконувати роль управління кластером.
Наявність цих двох властивостей дозволяє використовувати чотири можливих варіанти визначення поведінки вузла кеша. Ці варіанти описані в наступній таблиці.
Параметр рівня кластера leadHostManagement
Параметр вузла кеша leadHost
Опис комбінації параметрів
Результуюча сфера відповідальності вузла кеша
SQL Server або настроюється постачальник виконує роль управління кластером. Це не провідний вузол.
Тільки звичайні операції вузла кеша.
SQL Server виконує роль управління кластером. Це провідний вузол, якщо значення параметра leadHostManagement задано рівним «true».
Тільки звичайні операції вузла кеша.
Коли провідні вузли виконують роль управління кластером
Коли параметри leadHostManagement і leadHost мають значення true. вузла кеша переходить на рівень підвищеної відповідальності в кластері і призначається ведучим вузлом. На додаток до звичайних операцій вузла кеша, пов'язаними з кешуванням даних, провідний вузол також працює з іншими провідними вузлами, здійснюючи управління операціями кластера.
При збої ведучого вузла
Для підтримки доступності кластера кеша більшість провідних вузлів повинно залишатися доступним. Кластери невеликого розміру схильні до найбільшого ризику, так як для мимовільного завершення роботи кластера потрібна менша кількість збоїв серверів.
Якщо провідні вузли виконують роль управління кластером, то в ситуації збою більшості провідних вузлів весь кластер кеша завершує роботу.
Наприклад, розглянемо кластер кеша, що складається з шести серверів і зображений на наступною схемою. У цьому прикладі провідні вузли виконують роль управління кластером, при цьому два вузла кеша призначені провідними.
У разі збою одного зі звичайних вузлів кеша в кластері кластер зможе продовжувати роботу. Дані на вузлах, які не є провідними, будуть втрачені (за умови, що не включений високий рівень доступності), однак інші кластери продовжать видачу і зберігання даних. На ділі кластер може продовжувати працювати навіть в разі втрати всіх чотирьох вузлів кешу, непризначених провідними.
Однак в разі збою всього лише одного з провідних вузлів кластер кеша завершить роботу, так як більшість провідних вузлів не буде знаходитися в робочому стані. Для усунення цієї проблеми можна призначити додаткові провідні вузли.
Команда Stop-CacheHost не зупинить службу вузла кеша Windows, якщо вона виконує роль управління кластером. Зупинка викликає завершення роботи всього кластера.
Призначення додаткових провідних вузлів
У майстра настройки AppFabric для визначення потрібної кількості провідних вузлів кластера використовується список, що розкривається Cluster Size. Також можна призначити додаткові провідні вузли після установки. Однак важливо врахувати, що вибір занадто великої кількості провідних вузлів може викликати проблеми:
- Для підтримки працездатності кластера кеша завжди має бути доступна більшість провідних вузлів. Чим більше вузлів визначено в якості ведучих, тим менше відмов серверів зможе витримати кластер без порушення роботи.
Коли SQL Server виконує роль управління кластером
Якщо параметр кластера leadHostManagement має значення false. то незалежно від параметра leadHost кожен вузол кеша виконує тільки свої звичайні (не належать до провідних вузлів) обов'язки, пов'язані з кешуванням даних. У цьому сценарії екземпляр SQL Server, який використовується для зберігання параметрів конфігурації кластера, також використовується для виконання ролі управління кластером.
У разі відмови сервера
Для підтримки доступності кластера в разі, якщо роль управління кластером виконує SQL Server, щонайменше один вузол кеша повинен мати доступ до бази даних SQL Server.
Наприклад, розглянемо кластер кеша, що складається з шести серверів і зображений на наступною схемою.
У цьому прикладі роль управління кластером виконує SQL Server; всі шість вузлів кешу можуть надавати свої ресурси клієнтам кеша для доступу до даних.
Якщо хоча б один з вузлів кеша в кластері відмовляє, дані на таких серверах губляться (передбачається, що не включений високий рівень доступності), однак кластер продовжує працювати. Дані на інших вузлах кеша залишаються доступними для клієнтів кеша. У такому сценарії кластер зможе продовжувати функціонувати навіть у разі втрати п'яти вузлів кеша з шести.