[Джерело] Висока доступність у SQL Server (1) ---- огляд високої доступності

Починаючи з SQL Server 2005, Microsoft впровадила різноманітні технології високої доступності для зменшення простоїв і підвищення захисту бізнес-даних, а з безперервним випуском SQL Server 2008, SQL Server 2008 R2 та SQL Server 2012 у SQL Server існує багато технологій високої доступності, які відповідають різним сценаріям.

    Перш ніж почати цю статтю, я коротко опишу те, що визначає, яку технологію з високою доступністю варто використовувати.

    Багатьом компаніям потрібно, щоб усі або частина їхніх даних були максимально доступними, наприклад, сайти онлайн-покупок, онлайн-бази даних товарів мають бути онлайн 24/7, інакше в умовах висококонкурентного ринку простій означає втрату клієнтів і доходів. Наприклад, у кол-центрі, який покладається на SQL Server, якщо база даних виходить з ладу, усі абоненти можуть лише сидіти і відповідати клієнту «Вибачте, системна помилка», що також є неприйнятним.

    Звісно, в ідеальному світі всі критично важливі дані завжди будуть онлайн, але в реальному світі існують різні причини недоступності бази даних, оскільки неможливо передбачити час і форму катастрофи, необхідно заздалегідь вживати заходів для запобігання різним надзвичайним ситуаціям, тому SQL Server надає різноманітні технології високої доступності, ці технології переважно включають: кластеризацію, реплікацію, дзеркалювання, доставку журналів, групи доступності AlwaysOn та інші, такі як резервне копування та відновлення файлових груп, Одноекземплярні високодоступні технології, такі як онлайн-індекси відновлення. Використання технологій високої доступності полягає не в тому, щоб обрати знайому технологію для прямого застосування, а для всебічного розгляду бізнесу та технологій. Тому що не існує єдиної технології, яка могла б виконувати всі функції. Як впроваджувати ці технології відповідно до конкретного бізнесу та бюджету — це так звана стратегія високої доступності.

При розробці стратегії високої доступності слід спочатку врахувати такі фактори:

• RTO (Objective Recovery Time Objective) — тобто об'єктивний час відновлення означає, скільки дозволеного простою, зазвичай виражається кількома 9-ми, наприклад, 99,999% доступності означає не більше 5 хвилин простою на рік, 99,99% — не більше 52,5 хвилин простою на рік, а 99,9% — не більше 8,75 годин простою на рік. Варто зазначити, що метод розрахунку RTO враховує, чи система працює 24*365, чи лише з 6 ранку до 9 вечора тощо. Також потрібно звертати увагу, чи вважається період обслуговування простоєм, і легше досягти більшої доступності, якщо під час цього періоду дозволено обслуговування та патчі бази даних.
• RPO (Ціль точки відновлення) – також відомий як ціль точки відновлення, означає, скільки дозволеної втрати даних. Зазвичай, якщо зробити якісне резервне копіювання, можна легко досягти нульових втрат даних. Але коли трапляється катастрофа, залежно від ступеня пошкодження бази даних, час, необхідний для відновлення даних із резервної копії, призведе до недоступності бази даних, що вплине на впровадження RTO. Раннім і більш відомим прикладом є банківська система в Європі та США, яка розглядає лише RPO, у системі є лише повні резервні копії та журнали, повні резервні копії кожні 3 місяці, журнали кожні 15 хвилин, коли трапляється катастрофа, лише повні резервні копії та журнали можуть відновити дані, тож хоча втрати даних немає, але через те, що відновлення даних займало два повних дні, банківська система була недоступна протягом 2 днів, тому велика кількість клієнтів була втрачена. Іншим протилежним прикладом є вітчизняний онлайн-відеосайт, який використовує SQL Server як реляційну базу даних бекенду, фронтенд — No-SQL і регулярно імпортує дані No-SQL у реляційну базу даних як резервну копію.
  

    Бюджет – RTO та RPO разом відомі як SLA (Service Level Agreements), і при розробці стратегії високої доступності потрібно вимірювати, наскільки добре ви відповідаєте SLA залежно від вашого бізнесу, залежно від вашого бюджету, а також оцінювати вартість різних SLA у разі невдачі. Загалом, досягти високих SLA з обмеженим бюджетом складно, і навіть якщо високі SLA досягаються через складні архітектури, складні архітектури також означають високі експлуатаційні та технічні витрати, тому необхідно обирати правильну технологію в межах бюджету для відповідності SLA.

Отже, загалом загальну основу для високої доступності можна визначити кількома питаннями для прийняття порядку:

• Який період простою акціонери готові прийняти?
• Який простій є прийнятним для менеджерів?
• Який бюджет передбачено для ситуації з високою доступністю?
• Яка втрата за годину через простої?
  

• Холодне резервне копіювання: Резервний сервер налаштований на прийом даних основного сервера, а у разі відмови — вручну відновлювати дані до первинної бази даних або переналаштовувати рядок підключення чи дозволи програми для запуску резервної бази даних онлайн.
• Тепле резервне копіювання: Основні дані сервера постійно передають журнали на резервний сервер (з нерегулярними інтервалами це може бути 15 хвилин, 30 хвилин, 1 хвилина тощо), таким чином основний сервер до резервного сервера зазвичай оновлюється асинхронно, тому дані основного та резервного сервера не можуть бути гарантовані. Крім того, ця схема зазвичай не реалізує автоматичний моніторинг несправностей і переключення на відмови.
• Гаряче резервне копіювання: Дані основного сервера автоматично синхронізуються на резервному сервері, і в більшості випадків включено автоматичний моніторинг несправностей і резервне переключення, а також гарантована узгодженість даних основного сервера та резервного сервера.
  

    Від холодних до теплих резервних копій — вартість стрімко зростає.

    Функції високої доступності, які підтримується SQL Server, тісно пов'язані з версією, а Enterprise версія підтримує всі функції високої доступності, зокрема:

• Резервний кластер
• Зображення бази даних l
• l Передача транзакційного журналу
• Знімки бази даних I
• Оновлення з високою доступністю
• I Гаряче завантаження пам'яті
• l Онлайн-операції індексування
• l Часткова онлайн база даних (відновлюються лише група головних файлів або група головних файлів та додаткові файли NDF)
  

    Для конкретних версій з високою доступністю дивіться:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxВарто зазначити, що безкоштовна версія Express може слугувати сервером свідків для дзеркалювання бази даних, що дозволяє економити кошти.

Резервний кластер

    Резервні кластери забезпечують підтримку високої доступності для всього екземпляра SQL Server, що означає, що екземпляр SQL Server на вузлі кластера переходить з ладу на інші вузли кластера через апаратні помилки, помилки операційної системи тощо. Висока доступність досягається завдяки тому, що кілька серверів (вузлів) ділять один або кілька дисків, а кластери резервування з'являються в мережі так само, як і один комп'ютер, але з високими характеристиками доступності. Важливо зазначити, що оскільки резервні кластери базуються на спільних дисках, існує одна точка відмови диска, тому додаткові захисти, такі як реплікація SAN, потрібно розгортати на рівні диска. Найпоширенішим кластером резервування є двовузловий кластер з резервуванням, включно з головним і підлеглим.

Передача транзакційного журналу

    Доставка транзакційного журналу забезпечує захист високої доступності на рівні бази даних. Логування використовується для підтримки однієї або кількох резервних баз даних (які називаються «вторинними базами даних») відповідної виробничої бази даних (яка називається «первинною базою даних»). Перед тим, як відбутися аварійне переключення, вторинна база даних має бути повністю оновлена шляхом ручного застосування всіх невідновлених резервних копій журналів. Доставка журналів має гнучкість для підтримки кількох резервних баз даних. Якщо потрібно кілька альтернативних баз даних, доставка журналів може використовуватися окремо або як доповнення до дзеркалювання бази даних. Коли ці рішення використовуються разом, основна база даних поточної конфігурації дзеркалювання баз даних також є основною базою даних поточної конфігурації доставки журналів.

    Доставка транзакційного журналу може використовуватися для холодних і теплих резервних копій.

Дзеркалювання бази даних

    Дзеркалювання баз даних фактично є програмним рішенням, яке також забезпечує захист на рівні бази даних, забезпечуючи майже миттєве перемикання з резерву для покращення доступності бази даних. Дзеркало бази даних може використовуватися для підтримки єдиної резервної бази даних (або «дзеркальної бази даних») для відповідної виробничої бази даних (яка називається «головною базою даних»).
Оскільки дзеркальна база даних завжди перебуває у стані відновлення, але база даних не відновлена, до дзеркальної бази даних неможливо отримати прямий доступ. Однак для завантаження лише для читання, таких як звіти, можна використовувати дзеркальну базу даних опосередковано, створивши знімок дзеркальної бази даних. Знімки бази даних надають клієнтам доступ лише для читання до даних у базі даних під час створення знімка. Кожна конфігурація дзеркалювання баз даних включає «головний сервер», який містить головну базу даних, а також дзеркальний сервер, що містить дзеркальну базу даних. Сервер дзеркал постійно оновлює дзеркальну базу даних основною базою даних.
    Дзеркалювання бази даних працює синхронно в режимі високої безпеки або асинхронно в режимі високої продуктивності. У високопродуктивному режимі транзакції не потрібно чекати, поки дзеркальний сервер запише журнали на диск перед їх поданням, що максимізує продуктивність. У режимі високої безпеки фіксовані транзакції здійснюються обома партнерами, але час затримки транзакції подовжується. Найпростіша конфігурація дзеркалювання бази даних включає лише головний сервер і дзеркальний сервер. У такій конфігурації, якщо головний сервер втрачається, дзеркальний сервер може використовуватися як резервний, але це може спричинити втрату даних. Режим високої безпеки підтримує налаштування в режимі очікування, режим високої безпеки з автоматичним резервуванням. Ця конфігурація передбачає сторонній сервер, який називається «сервером свідка», що дозволяє використовувати дзеркальний сервер як сервер гарячого резервного копіювання. Резервний перехід від первинної бази даних до дзеркальної зазвичай займає кілька секунд.

    Дзеркалювання бази даних може використовуватися як для теплих, так і для гарячих резервних копій.

копіювати

    Реплікація — це не строго функція, розроблена для високої доступності, але її можна застосовувати до високої доступності. Реплікація забезпечує захист на об'єктному рівні бази даних. Реплікація використовує модель публікації-підписки, коли дані публікуються основним сервером, відомим як видавець, одному або кільком вторинному абоненту. Реплікація забезпечує доступність у реальному часі та масштабованість між цими серверами. Він підтримує фільтрацію для надання підмножини даних абонентам, а також оновлення розділів. Абонент онлайн і доступний для звітування або інших функцій без відновлення запитів. SQL Server пропонує чотири типи реплікації: реплікація за снапшотом, транзакційна реплікація, однорангова реплікація та реплікація злиття.

AlwaysOnГрупа зручності

    AlwaysOn Availability Groups — це нова функція, введена в SQL Server 2012. Також передбачено захист на рівні бази даних. Це також розширює обмеження, що дзеркалювання бази даних може бути лише 1:1, так що одна первинна репліка може відповідати до 4 вторинних реплік (у SQL Server 2014 це обмеження розширено до 8), з яких 2 вторинні репліки можна синхронізувати як гарячі резервні копії та первинні репліки в реальному часі, а дві інші асинхронні вторинні репліки можуть використовуватися як теплі резервні копії. Крім того, вторинні репліки можуть бути налаштовані як лише для читання і використовуються для виконання навантаження резервних копій.

    Через це дзеркалювання бази даних позначено як «застаріле» в SQL Server 2012.

    Після розуміння базових понять високої доступності та технологій високої доступності, які пропонує SQL Server, давайте розглянемо розробку стратегії високої доступності. Планування стратегії високої доступності можна поділити на чотири етапи:

Вимоги до збору

    Першим кроком у виборі стратегії високої доступності є збір бізнес-вимог для створення SLA. RTO та RPO є найважливішими частинами, і на цій основі встановлюють реалістичні очікування щодо вимог до доступності та формують реалістичну стратегію високої доступності на основі цих очікувань.

Межі оцінки

    Обмеження оцінки обмежуються не лише обмеженнями різних високодоступних технологій у SQL Server, а й тими, що не є технічними. Якщо у вас бюджет лише в десятки тисяч юанів, але ви хочете створити рішення з високою доступністю на основі дата-центрів поза сайтом і реплікації SAN, це безперечно марна мрія. Ще одним нетехнічним обмеженням є рівень оперативного персоналу, і часто складні архітектури означають більше кваліфікованих операційних працівників. Інші нетехнічні обмеження включають наявність дискового простору в дата-центрі, питання, чи можуть живлення та кондиціонування повітря задовольнити потреби, а також час, необхідний для реалізації стратегії доступності.

    Технічні обмеження включають різні функції та обмеження високої доступності, функції, які підтримуються різними версіями SQL Server, кількість процесорів і розмір пам'яті. Настійно рекомендується спочатку звертатися до обмежень різних версій і функцій SQL Server на сайті Microsoft MSDN перед впровадженням політики високої доступності.

Вибрана технологія

    Після збору вимог і оцінки обмежень наступним кроком є вибір технологій або комбінації технологій, описаних раніше в цій статті, для відповідності вимогам SLA. Якщо обрана технологія не відповідає вимогам SLA, легко повідомити, які обмеження не відповідають SLA, що дозволяє запитувати відсутні ресурси або компрометувати SLA.

Тестуйте, перевіряйте та документуйте

    Політики високої доступності мають бути ретельно протестовані та підтверджені з самого початку, щоб гарантувати, що поточні політики доступності відповідають SLA. Однак, коли запускається стратегія високої доступності, необхідно регулярно тестувати та перевіряти її, щоб переконатися, що чинна політика може відповідати SLA, незважаючи на зростання даних, зміни в бізнесі чи вимогах. Водночас конфігурація рішення доступності, метод резервування та план відновлення після катастрофи мають бути задокументовані одночасно, щоб їх можна було простежити у разі збою або майбутньої коригування стратегії високої доступності.

У цій статті пояснюються основні поняття високої доступності, концепція SLA, різні типи функцій високої доступності, які підтримується SQL Server, а також кроки, необхідні для розробки стратегії високої доступності. Варто зазначити, що хоча ця стаття йдеться лише про високу доступність на рівні бази даних, висока доступність стосується не лише DBA, а й включає співпрацю різних ролей, таких як персонал з експлуатації та обслуговування систем, адміністратори мереж, розробники та менеджери для кращого виконання SLA.