Як досягти високого рівня доступності сервера SQL Server, Інші СУБД, Бази даних, статті

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


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


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



Визначення високого рівня доступності


При плануванні роботи додатки з високим рівнем доступності перш за все необхідно визначитися, що під цим розуміється в даній конкретній середовищі. Для деяких організацій високий рівень доступності означає наявність надлишкового обладнання, аналогічного робітникові, причому як дані, так і обладнання повинні бути в працездатному стані і доступні протягом не менше 99,995 відсотків часу. Іншим організаціям може вимагатися лише високий рівень доступності самих даних, а можливості перемикання на інший ресурс при збої приділяється менше уваги. Щоб вибрати правильне рішення в конкретній ситуації, дуже важливо визначитися, що саме мається на увазі під високим рівнем доступності.


Необхідно також зрозуміти, які типи простоїв можуть виникати, і проаналізувати, як вони можуть позначитися на угодах про умови обслуговування (SLA). Простої, які можуть вплинути на рівень доступності, поділяються на планові, позапланові і періоди зниженою продуктивності.


Зазвичай плановий простій – це час, відведений для запланованого обслуговування, про який користувачі систем попереджаються заздалегідь. Позаплановий простий частіше за все є результатом відмови обладнання або збою програмного забезпечення, через який дані стають недоступними. Період зниженою продуктивності теж може служити причиною простоїв і часто визначається за часом відгуку для кінцевих користувачів, яке зазвичай заздалегідь узгоджується підприємством і ІТ-організацією і включається в угоду про умови обслуговування того чи іншого виду.


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


Дзеркальне відображення баз даних


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


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


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


Роль показує, служить конкретний сервер основним або дзеркальним.


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


Партнер – основної або дзеркальний сервер.


У звичайному середовищі на основному сервері виконується резервна копія бази даних основного сервера, яка потім відновлюється на дзеркальному сервері (див. рис. 2). Після цього на основному сервері необхідно налаштувати дзеркальне відображення: або у вікні властивостей бази даних основного сервера в середовищі SQL Server Management Studio (SMSS), або за допомогою сценаріїв мови T-SQL.

Figure 5 Log shipping setup wizard

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


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


Завдяки своїй простоті доставка журналів добре працює в багатьох випадках. Ця технологія є вдалим варіантом для підвищення рівня доступності, оскільки вона недорога і може працювати в системі з високою інтенсивністю транзакцій. База даних-одержувач, яка використовується при доставці журналів, може бути доступна тільки для читання, і тоді її зручно застосовувати для складання звітів. Доставка журналів вимагає мінімальних витрат, але в разі її використання необхідно створити політику попереджень для обробки збоїв.


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


Кластеризація серверів SQL Server


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


Тема кластеризації є досить складною, тому в даній статті буде розглядатися не докладно, а лише у вигляді короткого огляду. Для створення кластера потрібні два або більше серверів, на кожному з яких повинна бути встановлена ​​одна і та ж версія операційної системи Windows Server ® 2000 випусків Advanced чи Datacenter або системи Windows Server ® 2003 випусків Enterprise або Datacenter. Крім того, буде потрібно установка служб MSCS (Microsoft ® Cluster Services – служби кластерів корпорації Майкрософт), які розподіляють права володіння загальними ресурсами між серверами і керують IP-адресами, загальними дисками і мережевими іменами. Ще для створення кластера необхідний загальний дисковий ресурс. Зазвичай цю роль виконує мережу SAN (Storage Area Network – мережа областей зберігання) або підключений запам’ятовуючий пристрій SCSI.


Примірник сервера SQL Server також вважається ресурсом. У конфігурації кластера можна встановити як випуск Standard, так і Enterprise продукту SQL Server 2005. Список можливостей, які підтримуються кожним з випусків програми SQL Server 2005, можна знайти в документі “Feature Comparison Chart for SQL Server 2005” (Порівняльна таблиця характеристик випусків програми SQL Server 2005), розташованому за адресою microsoft.com / sql / prodinfo / features / compare-features.mspx (англійською мовою).


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


У разі виходу з ладу основного вузла ресурси переміщуються на додатковий вузол, причому стан логічного сервера не змінюється. Клієнти можуть продовжувати працювати з сервером після невеликої паузи. Весь процес переходу на інший ресурс при збої може зайняти від приблизно 5 секунд і менше до 30 секунд і більше (у деяких випадках), що залежить від устаткування, програмного забезпечення і мережі кластера.


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


Реплікація


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


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


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


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


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


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


На відміну від дзеркального відображення баз даних, при реплікації як вихідна, так і кінцева бази даних повністю доступні для клієнтських додатків. Реплікація моментальних знімків забезпечує ті ж можливості, що і доставка журналів.


Потрібно враховувати, що реплікація – це перевірена і добре документована технологія. Використання реплікації як рішення для підвищення рівня доступності може мати деякі недоліки і приводити до зниження продуктивності, втім, не в більшій мірі, ніж при застосуванні дзеркального відображення. Найімовірніше, будь-яке рішення для підвищення рівня доступності, побудоване на основі реплікації, матиме складнішу для управління архітектуру: не обов’язково вдосконалену, але точно більше складну. Крім того, одна з найбільш значних труднощів, яку потрібно враховувати, полягає в наступному: якщо змінюється структура таблиць бази даних або необхідно налаштувати реплікацію ще однієї таблиці, доведеться видалити і заново визначити публікацію, щоб внести зміни в обидві бази даних.


Висновок


З наведеного матеріалу зрозуміло, що до створення рішення для підвищення рівня доступності в наявній середовищі треба підходити творчо. Кожна надається додатком SQL Server 2005 технологія для підвищення рівня доступності має свої сильні і слабкі сторони, і в різних ситуаціях потрібно застосовувати різні рішення.


Доставка журналів, реплікація моментальних знімків і навіть дзеркальне відображення баз даних в режимі високої продуктивності можуть стати хорошим вибором в тому випадку, якщо веб-база даних-джерело географічно відокремлена від бази даних-одержувача (особливо, якщо не потрібно, щоб допоміжні дані були доступні в режимі реального часу).


З іншого боку, якщо база даних-одержувач повинна бути доступна в режимі реального часу, транзакційна реплікація або дзеркальне відображення можуть допомогти в розподілі навантаження, якщо інтенсивність транзакцій на сервері-джерелі не дуже велика, а з’єднання між двома вузлами середовища є швидким і не перевантажено.


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


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


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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*