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

Як розробник, а не DBA, я намагаюся зрозуміти, коли використовувати сценарій для моєї відмови / високої доступності:

• Два (або більше) серверів кластера Windows Failover, SQL Server як кластерний екземпляр
• Два (або більше) екземплярів SQL Server, які оновлюються транзакційною реплікацією
• Два (або більше) SQL-серверів у групі доступності SQL Server, налаштованих у режимі синхронної фіксації

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

Мені завжди подобається візуалізувати рішення з високою доступністю:

Екземпляр кластерного відключення SQL Server (FCI)

Що є високодоступним? Весь екземпляр. Це включає всі серверні об’єкти (входи, завдання агента SQL Server тощо). Сюди також входять бази даних та їх сукупності. Це чудове рішення для високодоступних екземплярів SQL Server, оскільки це буде рівнем стримування цього рішення.

А як щодо звітування? Ні, NULL, не існує. Екземпляр кластерного відключення має активний вузол, який доставляє групу кластерів, що містить екземпляр, VNN тощо.

Що відбувається, коли відбувається аварійний перехід? Час простою для FCI визначається кількістю часу, яке потрібно пасивному вузлу, щоб захопити ресурс кластера та привести екземпляр SQL Server у робочий стан. Зазвичай це мінімально за часом.

Будь-яка клієнтська абстракція? Так, це буде внутрішньо вбудовано з назвою віртуальної мережі для екземпляра кластерного відключення. Це завжди вказуватиме на активний вузол, який наразі доставляє ресурс кластера SQL Server.

Завжди про групи доступності

Що є високодоступним? Група доступності буде логічним стримуванням високої доступності тут, тоді як група доступності складається з ряду баз даних та імені віртуальної мережі (слухач, необов'язковий ресурс кластера). Варто зауважити, що серверні об’єкти, такі як входи в систему та завдання SQL Server Agent, не будуть частиною рішення HA, і слід звернути особливу увагу на забезпечення їх належної реалізації з групою доступності. Це не надто обтяжлива вимога, але її потрібно доглядати.

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

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

Будь-яка клієнтська абстракція? Так, ви необов’язково можете налаштувати слухач групи доступності AlwaysOn. Це в основному лише назва віртуальної мережі (може розглядатися через WSFC як ресурс кластера в групі кластерів AG), який вказує на поточну первинну репліку. Це ключова частина переміщення вашої звітної навантаження навколо, а також встановлення списку маршрутів лише для читання на будь-яких серверах, на які ви хочете перенаправляти трафік ReadOnly (це встановлюється через рядок підключення, за допомогою постачальника .NET Framework для SQL Сервер, це буде параметр Намір програми , встановлений на ReadOnly ). Вам також потрібно встановити URL-адресу маршрутизації, доступну лише для читання, для кожної репліки, на яку ви хочете отримати це навантаження звітності, перебуваючи в ролі вторинної реплікації.

Транзакційна реплікація

Що є високодоступним? Це сперечається, але я нічого не кажу . Я не бачу реплікації як рішення високої доступності. Так, зміни даних підштовхуються до передплатників, але ми говоримо на рівні публікацій / статей. Це буде підмножина даних (може включати всі дані, але це не буде примусово виконуватись. Тобто ви створюєте нову таблицю в базі даних видавця, і вона автоматично не буде висунута підписникам). Що стосується HA, це нижня стовбур, і я не згрупуватиму його там із твердим розчином HA.

А як щодо звітування? Прекрасне рішення для звітування про підмножину даних, про це не виникає сумнівів. Якщо у вас є база даних на 1 ТБ, яка є дуже транзакційною, і ви хочете, щоб це навантаження звітності не було в базі даних OLTP, транзакційна реплікація - це чудовий спосіб підштовхувати підмножину даних до абонента (або передплатників) для завантаження звітності. Що станеться, якщо з цього 1 ТБ даних завантаженість вашої звітності становить близько 50 ГБ? Це розумне рішення та відносно налаштоване для задоволення потреб вашого бізнесу.

Підсумок

Що зводиться до цього - це кілька питань, на які потрібно відповісти (частково бізнес):

1. Що має бути високодоступним ?
2. Що диктує SLA для HA / DR?
3. Яка звітність буде мати місце та які затримки прийнятні?
4. Що нам потрібно впоратися з географічно розсіяною НА? (реплікація пам’яті дорога, але обов'язкова з FCI. АГ не вимагають спільного зберігання в окремих автономних екземплярах, і ви можете використовувати свідчення спільного доступу до файлів для кворуму, що потенційно позбавляє від необхідності спільного зберігання)

два (або більше) серверів кластера Windows Failover, SQL Server як кластерний екземпляр

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

2. Мінуси / занепокоєння - Єдиною точкою несправності є ваше сховище та всі його компоненти. Постачальники SAN завжди кажуть "SAN не виходять з ладу", але в мережі зберігання є багато рухомих деталей, і, як я тут веду блоги , вони можуть. Крім того - ви платите за вторинний сервер, який нічого не може зробити, окрім зависання та очікування. Тепер ви можете робити Active / Active / Multi-Node та мати два активні екземпляри, які можуть переходити в інший бік і використовувати другий вузол.

3. Автоматична відмова? "Найбільш" автоматичний. Нікому не потрібно свідка, це кластер. Це робота кластера, щоб зробити його максимально безпроблемним. Тепер із будь-яким із них, коли станеться аварія, ви "відчуєте" це, оскільки SQL повинен запускатися або з'єднання повинні вказувати. Тут, коли це станеться, ви відчуваєте себе, як перезавантаження SQL, БД повертаються та запускають відновлення / тощо.

Якщо у мене клієнт скаже «Я хочу повністю працювати з усіма базами даних, усіма входами тощо» у середовищі підвищеної доступності в моєму локальному центрі обробки даних, оскільки у мене надзвичайно низька толерантність до простоїв, я б вважав, що Failover Cluster Examences (хоча останній варіант, який ви згадуєте, - сильний претендент, за винятком того, що потрібно виконувати деякі управління накладними витратами). Ймовірно, я б зробив локальний FCI та AG-асинхронний вторинний захист від відмови сайту або відмови SAN.

два (або більше) екземплярів SQL Server, які оновлюються транзакційною реплікацією

1. Який вид навантаження? Я, чесно кажучи, не ходив би сюди для багатьох випадків, коли потребує високої доступності чи аварійного відновлення як першого вибору. Напевно не в SQL 2012. Але в основному це добре, якщо вам довелося зайти в центр даних, який був недалеко, ви не могли використовувати АГ (можливо, проблема домену, що заважає вам використовувати кластер Windows, необхідний для АГ), можливо, ви хотіли бути у стандарті SQL Server, який може робити реплікацію, але не АГ, але ви все-таки хотіли мати можливість читати з другої сторони та бути асинхронним.
2. Мінуси / проблеми - це реплікація. Він має накладні витрати, він може вийти з синхронізації, ви можете розвинути проблеми з продуктивністю на стороні джерела тощо.
3. Автоматична відмова - Ні. Ви повинні керувати нею самостійно. Чи через CNAME, які вказують на те чи інше, і ви теоретично можете написати свій власний процес для цього, але не з вікна? Зверніть увагу тут.

два (або більше) сервери SQL в групі доступності SQL Server, налаштовані в режимі синхронної фіксації

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

1. Який вид навантаження? Це чудово, коли у мене є керований набір баз даних, який потрібно підтримувати синхронізувати, а також ресурси та час, щоб переконатися, що завдання, входи в систему, нові бази даних тощо синхронізуються (хоча команда в SQL Skills створила великий додаток до автоматизуйте щось для цього, зробивши його ще сильнішим варіантом). Мені це подобається, коли я хочу зберегти речі повністю відокремленими. Я захищаю від апаратних проблем, проблем з ОС, проблем із встановленням SQL, проблем з латками та проблем SAN / Storage. Я також отримую перевагу від можливості мати середній (Якщо я хочу заплатити за нього ліцензію підприємства) бути активним середнім, з якого я можу читати, робити резервні копії тощо. Плюс у майбутньому я можу додати третю вторинні, які є асинхронними на віддаленому місці та мають відмову / DR.
2. Мінуси / стурбованість Ліцензування, максимальна кількість реплік, витрати на ліцензування, щоб скористатися однією з найбільших переваг (активний вторинний), потребує підприємства, потребує вдвічі більше сховища, ніж кластеризація.
3. Автоматична відмова - так. Це може статися при налаштуванні очевидців, і розробники ваших програм можуть підключитися до слухача замість вузла, так що відмова трапляється там, де слухач вказує, і вам там має бути добре. Так, так, ви можете зробити це тут - і слід - але, звичайно, ви повинні це добре перевірити.

Підсумок

HA та DR різні. І ці технології допомагають забезпечити шматочки будь-якого. Висока доступність означає (для мене), що ви можете швидко відновитись, якщо з однією машиною трапиться щось погане, вам потрібна коротка ціль точки відновлення та мета часу відновлення. Це кластеризація та синхронна АГ.

Відновлення стихійних лих - це "ви можете встати, коли у вас є збій навіть у вашому рішенні HA. Для мене це можуть бути АГ, коли ви переходите до іншого центру обробки даних, дзеркального відображення або навіть реплікації.

Важливо також врахувати те, що спільне .

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

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

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

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