У цій статті ми розглянемо покрокову установку і настройку груп доступності Always On в SQL Server в Windows Server 2019, розглянемо сценарії відпрацювання відмов і ряд інших суміжних питань.
"Always On Availability Groups"Або"Групи доступності Always On"Це технологія для забезпечення високої доступності в SQL Server. Always On з'явилися в релізі Microsoft SQL Server 2012.
зміст:
- Особливості груп доступності Always On в SQL Server
- Налаштування Windows Server Failover Cluster для Always On
- Налаштування Always On в MS SQL Server
- Always On: перевірка роботи, автоматична відпрацювання відмови
Особливості груп доступності Always On в SQL Server
Для чого можуть використовуватися групи доступності SQL Server?
- Висока доступність MS SQL і автоматична відпрацювання відмови;
- Балансування навантаження select запитів між вузлами (вторинні репліки можуть бути доступні для читання);
- Створення резервних копій з вторинних реплік;
- Надмірність даних. Кожна репліка зберігає копії баз даних групи доступності.
Always On працює на платформі Windows Server Failover Cluster (WSFC). WSFC забезпечує моніторинг вузлів беруть участь в групі доступності і може здійснювати автоматичний відробіток відмови за допомогою голосування між вузлами. Починаючи з MS SQL Server 2017 з'явилася можливість використовувати Always On без WSFC, в тому числі на Linux системах. При побудові кластера на Linux можна використовувати Pacemaker як альтернативу WSFC.
Always On доступний в Standard редакції, але з деякими обмеженнями:
- Ліміт на 2 репліки (основну і вторинну);
- Вторинна репліка не може бути використана для read доступу;
- Вторинна репліка не може бути використана для резервного копіювання MS SQL;
- Підтримка тільки 1 бази даних на групу доступності.
У редакції Enterprise обмежень немає.
Особливості ліцензування MS SQL Server.Розберемося в термінології:
- Групу доступності Always ON - це набір реплік і баз даних;
- репліка - це екземпляр SQL Server знаходиться в групі доступності. Репліка може бути основна (primary) І вторинна (secondary). Кожна репліка може містити одну або більше баз даних.
В основі Always On лежить WSFC. Кожен вузол групи доступності повинен бути членом відмов кластеру Windows. Кожен екземпляр SQL Server може мати кілька груп доступності. У кожній групі доступності може бути до 8 вторинних реплік.
При відмові основою репліки, кластер проголосує за нову основну репліку і Always On переведе одну з вторинних реплік в статус основної. Так як при роботі з Always On користувачі з'єднуються з Прослуховувач кластера (або Listener, тобто спеціальний IP адрес кластера і відповідне йому DNS ім'я), то можливість виконувати write запити повністю відновиться. Прослуховувач також відповідає за балансування select запитів між вторинними репліками.
Налаштування Windows Server Failover Cluster для Always On
Перш за все нам потрібно налаштувати відмовостійкий кластер на всіх вузлах, які братимуть участь в Always On.
Моя конфігурація:
- 2 віртуальних машини на Hyper-V з Windows Server 2019;
- 2 примірника SQL Server 2019 редакції Enterprise;
- Hostname вузлів - testnode1 і testnode2. Ім'я примірників node1 і node2.
У Server Manager додаємо роль Failover Clustering, або встановіть компонент за допомогою PowerShell:
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
Установка автоматична, нічого налаштовувати поки не потрібно. Після закінчення установки запустіть оснащення Failover Cluster Manager (FailoverClusters.SnapInHelper.msc).
Створюємо новий кластер.
Додаємо імена серверів, які будуть брати участь в кластері.
Далі майстер пропонує пройти тести. Чи не відмовляємося, вибираємо перший пункт.
Вказуємо ім'я кластера, вибираємо мережу і IP адрес кластера. Ім'я кластера автоматично з'явиться в DNS, прописувати його спеціально не потрібно. У моєму випадку ім'я кластера - ClusterAG.
Прибираємо чебокс "Add all eligible storage to the cluster", Так як диски ми зможемо додати пізніше.
Вузлів в кластері всього 2, тому необхідно налаштувати Cluster Quorum. Кворум кластера - це "вирішальний голос". Наприклад, якщо один з вузлів кластера стає недоступний, кластеру необхідно визначити які вузли насправді доступні і можуть бачити один одного. Кворум потрібен для узгодженості кластера (Cluster -> More Actions -> Configure Cluster Quorum Settings).
Виберіть тип кворуму зі свідком (quorum witness).
Потім вибираємо тип свідка - мережева папка (file share witness).
Вкажіть UNC шлях до мережевої папці. Цю директорію потрібно створити самостійно, і вона обов'язково повинна бути на сервері, який не бере участі в кластері.
Під час налаштування кластера ви можете отримати помилку:
There was an error configuring the file share witness. Unable to save property changes for File Share Witness. The system can not find the file specified.
Швидше за все це означає, що у користувача з-під якого працює кластер немає прав на цю мережеву папку. За замовчуванням кластер працює з-під локального користувача. Ви можете дати права на цю папку всім комп'ютерам кластера, або змінити обліковий запис для служби кластера і роздати права йому.
На цьому базова конфігурація кластера закінчена. Переконаємося, що DNS кластера прописаний і віддає правильний IP
Налаштування Always On в MS SQL Server
Після стандартної установки примірника SQL Server ви можете включити і налаштувати групи доступності Always On. Їх потрібно включити в SQL Server Configuration Manager у властивостях примірника. Як видно на скріншоті, SQL Server вже визначив, що він є учасником кластера WSFC. Поставте чекбокс "Enable Always On Availability Groups"І перезавантажте службу примірника MSSQL. Виконайте ті ж дії на другому екземплярі.
У SQL Server Management Studio клацніть по вузлу "Always On High Availability"І запустіть майстер настройки групи доступності (New Availability Group Wizard).
Вкажіть ім'я групи доступності Always On і виберіть опцію "Database Level Health Detection". З цією опцією Always On зможе визначати, коли база даних знаходиться в нездоровому стані.
Виберіть бази даних SQL Server, які братимуть участь в групі доступності Always On.
Натисніть "Add Replica ..." і встановіть з'єднання з другого сервера SQL. Таким чином можна додати до 8 серверів.
- Initial Role - роль репліки на момент створення групи. Може бути Primary і Secondary;
- Automatic Failover - якщо база даних стане недоступна, Always On переведе primary роль на іншу репліку. Відзначаємо чекбокс;
- Availability Mode - можливо вибрати Synchronous Commit або Asynchronous Commit. При виборі синхронного режиму, транзакції, що надходять на primary репліку, будуть відправлені на всі інші вторинні репліки з синхронним режимом. Primary репліка завершить транзакцію тільки після того, як репліки запишуть транзакцію на диск. Таким чином виключається можливість втрати даних при збої primary репліки. При асинхронному режимі основна репліка відразу записує зміни, не чекаючи відповіді від вторинних реплік;
- Readable Secondary - параметр задає можливість робити select запити до вторинних реплік. При значенні yes, клієнти навіть при з'єднанні без ApplicationIntent = readonly зможуть отримати readonly доступ;
- Required synchronized secondaries to commit - число синхронізованих вторинних реплік для завершення транзакції. Потрібно виставляти в залежності від кількості реплік, я поставлю 1. Майте на увазі, що, якщо вторинних синхронізованих реплік стане менше зазначеного числа (наприклад, при аварії), бази даних групи доступності стануть недоступні навіть для читання.
Вкладку Endpoints не чіпаємо.
на вкладці Backup Preferences можна вибрати звідки будуть робитися бекапи. Ми залишаємо все за замовчуванням - Prefer Secondary.
Вказуємо ім'я слухача групи доступності (availability group listener), порт і IP адреса.
вкладку Read-Only Routing залишаємо без змін.
Вибираємо яким чином будуть синхронізуватися репліки. Я залишаю перший пункт - автоматичну синхронізацію (Automatic seeding).
Після цього ваші настройки повинні пройти валідацію. Якщо помилок немає, натисніть Finish для застосування змін.
У моєму випадку все тести пройшли успішно, але після установки на кроці Results, майстер повідомив про помилку при створенні слухача групи доступності. В логах кластера була така помилка:
Cluster network name resource failed to create its associated computer object in domain.
Це означає, що у кластера недостатньо прав для створення слухача. У документації написано, що достатньо дати дозвіл на створення об'єктів типу "комп'ютер" об'єкту вашого кластера. Найпростіше це зробити через делегування повноважень в AD (або, швидкий але поганий варіант - тимчасово додати об'єкт CLUSTERAG $ в групу Domain Admins).
При діагностиці проблем з Always ON і низькою продуктивністю SQL в групі доступності, крім стандартних засобів діагностики SQL Server, потрібно уважно дивитися логи кластера Windows.Так як група доступності у мене створилася, а слухач немає, я додав його вручну. Викликаємо контекстне меню на групі доступності і тиснемо Add Listener...
Вкажіть IP адреса, порт і DNS ім'я слухача.
Перевірте, що Listener з'явився у розділі доступних слухачів групи Always On.
На цьому базова настройка групи доступності Always On закінчена.
Always On: перевірка роботи, автоматична відпрацювання відмови
Подивимося на панель моніторингу груп доступності (Show Dashboard).
Всі OK, група доступності створена і працює.
Спробуємо перевести основну роль на екземпляр node2 в ручному режимі. Клацніть ПКМ по групі доступності та виберіть Failover.
Варто звернути увагу на пункт Failover Readiness. значення No data loss значить, що втрата даних при переході виключена.
Єднаймося з node2.
тиснемо Finish.
Перевіряємо, що node2 став основною реплікою в групі доступності (Primary Instance).
Переконаємося, що слухач працює як треба. У SSMS вкажіть DNS ім'я слухачі і порт через кому: ag1-listener-1,1445
Зробимо прості insert, select і update запити в нашу базу SQL Server.
Тепер перевіримо автоматичний відробіток відмови основної репліки. Просто завершіть процес sqlservr.exe на TESTNODE2.
Перевіряємо стан групи доступності на останньому вузлі - TESTNODE1 \ NODE1.
Кластер автоматично перевів статус репліки testnode1 \ node1 в primary, так як testnode2 \ node2 став недоступний.
Перевіримо стан слухача, тому що з'єднання клієнтів будуть надходити саме на нього.
У моєму випадку я успішно з'єднався зі слухачем, але при доступі до бази даних з'явилася помилка
Unable to access database 'TestDatabase' because it lacks a quorum of nodes for high availability. Try the operation again later.
Ця помилка виникла через параметра "Required synchronized secondaries to commit". Так як під час налаштування ми виставляли це значення в 1, Always On не дає підключитися до бази даних, тому що у нас залишилася всього одна primary репліка.
Встановимо це значення в 0 і спробуємо знову.
Включаємо testnode2 і перевіряємо статус групи.
Статус Primary репліки залишився у testnode1, а testnode2 став вторинної реплікою. Дані, які ми міняли на testnode1 при вимкненому testnode2 успішно синхронізувалися після включення машини.
На цьому тестування закінчено. Ми переконалися все працює коректно і при критичному збої дані залишаться доступні для read / write доступу.
Крім Always On в SQL Server є ще кілька технологій забезпечення високої доступності.Групи доступності Always On досить прості в налаштуванні. Якщо перед вами стоїть завдання побудувати поломок рішення на базі SQL Server, то групи доступності відмінно впораються з цим завданням.
З випуском SQL Server 2017 і SQL Server 2019 SQL Server Management Studio 18.x з'явилися настройки Always On, які раніше були доступні тільки через T-SQL, тому рекомендується користуватися останньою версією SSMS.
