Кластер серверів дозволяє з'єднати кілька фізичних серверів (вузлів), які служать один для одного партнерами в процедурі переходу на резервний ресурс. Надмірність, що надається кластером, забезпечує більш високу тривалість безперебійної роботи, необхідну для критичних
операцій. За 13 років роботи з SQL Server ™ я впровадив безліч кластерів, і в кожному випадку були свої особливості. Цей досвід дозволив мені сформулювати ряд порад і рекомендацій, які допоможуть зробити роботу з кластерами простіше і успішніше.
Figure 1 A typical cluster
Нарешті, щоб досягти справжньої мети кластеризації - високого рівня доступності, - необхідні кваліфіковані фахівці і відрепетирувані процедури на випадок виникнення неполадок. Хоча кластеризація є хорошою страховкою проти збоїв обладнання, вона не запобігає помилок користувачів, таких, наприклад, як скидання важливою таблиці не виспався адміністратором бази даних посеред ночі.
Кластери з одним вузлом
Навіть якщо в даний момент необхідний тільки один сервер, все одно має сенс подумати про створення кластера з одним вузлом. Це дасть можливість згодом удосконалити конфігурацію до кластера без необхідності переробляти систему. Потрібно тільки упевнитися, що вбрання обладнання присутня в розділі кластерів Каталогу Windows.
Можливість подальшого додавання вузла корисна не тільки заради підвищення рівня доступності. Розглянемо ситуацію, коли в якийсь момент виявляється, що потужність сервера недостатня. Це означає необхідність міграції, тобто витрати часу і сил. При наявності кластера з одним вузлом міграцію можна буде виконати набагато легше і з меншим часом простою. У кластер додається новий вузол; на новий вузол встановлюються виконавчі файли і пакети оновлень сервера SQL Server, а потім за допомогою процедури переходу на резервний ресурс виконується перенесення сервера на новий вузол. Після цього потрібно встановити додаткові виправлення, випущені після пакета оновлень, і, нарешті, виключити старий вузол. Час простою обмежується часом переходу на резервний ресурс і установки оновлень (якщо необхідно).
Зрозуміло, це змусило мене задуматися ще. Адже можна створити сценарії, які б викликали програму CLUSTER.EXE для додавання вузла в сервер кластерів Microsoft® (MSCS). Все, що потрібно зробити, - це передати сценарієм ім'я вузла, а решту він зробить сам. В екстреній ситуації автоматизація - справжній друг.
Іноді вузол додається в кластер не для заміни іншого вузла. Можливо, в кластер потрібно додати додаткові екземпляри сервера SQL Server, і кожного примірника потрібні окремі дискові ресурси. Хоча на одному вузлі може бути запущено декілька примірників сервера, в такій ситуації їм доводиться ділити між собою процесор і ОЗУ, що призводить до зниження продуктивності. В ідеальній ситуації на одному вузлі повинен бути запущений тільки один екземпляр. Як гарантувати це при переході на резервний ресурс? Дуже просто! На одному з вузлів не повинно виконуватися жодної служби, а на кожному з інших вузлів повинно бути запущено по одному примірнику сервера SQL Server. Це і є визначення кластера «N + 1»: N примірників, запущених на N + 1 вузлах. Зайвий вузол є запасним.
Сервер оновлення SQL Server
Які є варіанти? Спочатку розглянемо найдорожче рішення: створення абсолютно нового кластера, яке зажадає нових серверів і, можливо, нової мережі області зберігання даних (SAN). Ймовірно, вдасться зберегти існуючі мережеві комутатори, але цим вичерпуються можливості використання старого обладнання. Очевидно, це недешевий підхід, але у нього є переваги. Нове обладнання, як правило, працює набагато краще старого; швидкість і ємність дисків безперервно збільшуються. Отже, продуктивність збільшиться вже завдяки оновленню обладнання. Щоб завжди мати сучасне обладнання, можливо навіть має сенс брати його в оренду.
Коли обладнання встановлено, можна створити новий віртуальний сервер SQL Server і скопіювати на нього виробничі бази даних, а потім піддати нову систему всебічному випробуванню, щоб усунути можливі неполадки до настання терміну перекидання сервера. При цьому слід обов'язково створити сценарії для перенесення облікових записів користувачів з існуючого сервера на новий. (Див. Статтю support.microsoft.com/kb/246133 (англійською мовою). Також має сенс оновити сценарій побудови облікових записів на випадок раптового повної відмови.)
Для зведення до мінімуму часу простою швидше за все буде потрібно використовувати доставку журналів, за винятком випадків, коли бази даних дуже маленькі і є період часу, коли жоден користувач не підключений. Доставку журналів можна виконати безпосередньо перед перекиданням. Потім слід від'єднати користувачів, вирізати і доставити остаточний журнал і вказати додатком на новий екземпляр. (Нижче, в розділі про дзеркальному відображенні баз даних, розповідається про цікаву альтернативу доставці журналів.) Якщо використовуються DNS-псевдоніми, то, швидше за все, навіть не доведеться вказувати додатків на новий екземпляр. Замість цього потрібно буде просто оновити DNS-псевдонім. Такий підхід має наступне перевагу: в разі необхідності зупинки процесу міграції на півдорозі і повернення в початковий стан це початковий стан, по крайней мере, буде в наявності.
Можна вибрати менш дорогий варіант, але він зажадає більш складного попереднього планування. Кластер може підтримувати більш одного екземпляра сервера SQL Server, але кожен екземпляр повинен мати власні дискові ресурси. Тому при організації мережі області зберігання даних (SAN) слід зарезервувати один номер логічного пристрою (LUN) для майбутніх оновлень. Щоб оновити програмне забезпечення, слід встановити виконавчі файли сервера SQL Server на цьому дисковому ресурсі. Далі слід провести випробування системи і, коли все буде готово, завершити роботу поточного сервера SQL Server, перемістити дискові ресурси зі старої групи SQL Server, оновити залежності і перевести новий екземпляр сервера SQL Server в оперативний режим. Далі потрібно приєднати бази даних зі старого примірника, і можна вважати операцію виконаною. (Ви ж створили резервні копії заздалегідь, чи не так?)
Цей підхід вимагає менших витрат, але і несе з собою частку ризику. Якщо щось піде не так, від'єднати бази даних від нового примірника і повернути їх на колишнє місце буде вже неможливо. У цьому випадку відновлення можливе тільки з резервних копій, а це може привести до тривалого простою.
Як варіант, можна помістити два примірника сервера SQL Server в мережу області зберігання, якщо в ній досить місця. Далі слід відновити виробничі резервні копії (і доставити журнали) на новий екземпляр сервера і продовжити приблизно так само, як описано вище. Однак тепер є шляхи для відступу. Після закінчення міграції можна звільнити ресурси мережі області зберігання від старого примірника. Вартість цього дії буде дорівнює лише ціною нових дисків.
Для початку спростуємо одна поширена помилка. Кластеризація MSCS використовується для підвищення рівня доступності, а не для балансування навантаження. Крім того, сервер SQL Server не має вбудованої можливості автоматичного балансування навантаження. Балансувати навантаження необхідно за допомогою фізичного проектування програми. Що це означає?
Зі збільшенням розмірів таблиці слід очікувати погіршення швидкодії, зокрема, при скануванні таблиці. Коли кількість рядків досягає мільйонів і мільярдів, через просте рішення до сих пір було використання секціонованих уявлень. Ці секціоновані уявлення складаються з таблиць з однаковими схемами, об'єднаних за допомогою інструкцій UNION ALL. Крім того, для розрізнення таблиць-компонентів встановлюються перевірочні обмеження (інструкція CHECK), що запобігає дуплікацію даних в Секціонірованние поданні. Якщо стовпець, який використовується в перевірочному обмеження, є частиною первинного ключа, то уявлення є оновлюваних.
Можливо, у вас є кілька зайвих серверів, але вони відсутні в розділі кластерів Каталогу Windows. Не хотілося б купувати нові сервери тільки для підтримки кластера, коли є вільні сервери.
Привабливою альтернативою кластеризації є дзеркальне відображення баз даних. Для дзеркального відображення необхідно три компонента: екземпляр, в якому розміщена відображена база даних (основний сервер), резервний (дзеркальний) сервер і, якщо потрібно автоматичний перехід на резервний ресурс, третій (стежить) сервер. У двох словах, при дзеркальному відображенні бази даних відбувається наступне: транзакція в базі даних на основному сервері запускається також і на дзеркалі. Якщо на основному сервері відбувається збій, можливий перехід бази даних на резервний ресурс - дзеркальний сервер. При наявності стежить сервера це станеться автоматично. Дзеркальне відображення необхідно налаштовувати для кожної бази даних вашого застосування; для системних баз даних дзеркальне відображення недоступно.
На відміну від кластера, дзеркальний сервер - це окремий екземпляр SQL Server; він може бути розташований на відстані тисяч кілометрів від основного сервера. Його кеші наповнюються за допомогою дій по оновленню, які відбуваються в результаті транзакцій, дупліціруемих з основного сервера. Зрозуміло, передбачається, що на дзеркальному сервері не відбувається ніяких дій крім отримання дзеркально відображених транзакцій з основного сервера. Перехід на резервний ресурс у цьому випадку, як правило, відбувається швидше, ніж в кластері, так як на дзеркальному сервері SQL Server вже запущений. Оскільки кеші вже заповнені (по крайней мере, частково), початкова швидкодію не така низька, як в сценарії з кластером. Також слід мати на увазі, що коли на відбитої базі даних відбувається перехід на резервний ресурс, основний і дзеркальний сервери міняються ролями.
Недоліком дзеркального відображення баз даних є потреба в подвоєною ємності дисків в порівнянні з кластером. Також необхідно більше обчислювальних потужностей, якщо потрібен синхронний режим без втрати даних. Як вже говорилося, висока доступність не буває дешевою.
Так як дзеркальний сервер може бути розташований на великій відстані від основного, дзеркальне відображення має сенс використовувати в планах аварійного відновлення (DR - Disaster Recovery). Кластер може служити першою лінією оборони, але що трапиться, якщо застосувати одночасно і кластеризації, і дзеркальне відображення? Коли відбувається перехід на резервний ресурс у кластері, то при наявності в конфігурації дзеркального відображення стежить сервера останній стає основним на той час, поки кластерізованний сервер SQL Server повертається в оперативний режим. Однак слід мати на увазі, що перехід на резервний ресурс з нового основного сервера назад на (кластерізованний) новий дзеркальний сервер не відбувається автоматично. Отже, краще не включати автоматичний перехід на резервний ресурс для дзеркально відображаються баз даних при використанні спільно з кластером.
Аварійне відновлення - не єдина мета використання дзеркального відображення. Це також корисно в ситуації, коли необхідно застосувати пакет оновлень або виправлення на основному сервері; в таких випадках можна виконати перехід на резервний ресурс на дзеркальний сервер. При застосуванні сервісний пакет або виправлення колишній основний сервер тимчасово переводиться в автономний режим, а завершення транзакції, виконані на новому основному сервері, стають в чергу, чекаючи відправлення назад на новий дзеркальний (колишній основний) сервер. Після закінчення установки пакету оновлень або виправлення відбувається синхронізація, в результаті якої два сервера наводяться в повну відповідність. Тепер можна поміняти основний і дзеркальний сервери ролями. Час простою становить кілька секунд, витрачених на перехід на резервний ресурс і назад. Цей підхід можна також використовувати для міграції сервера SQL Server на інший фізичний сервер. Відмінність тільки в тому, що не потрібно переходити назад.
Підвищення гнучкості за допомогою віртуального сервера
Figure 2 Using a virtual server
Адміністратору, який відповідає за впровадження сервера SQL Server, потрібно бути впевненим в безперервної доступності сервера. Досягти цієї мети допомагає застосування кластеризації сервера. У цій статті запропоновані перевірені досвідом рекомендації, які допомагають почати роботу. Додаткові корисні відомості можна знайти на урізанні «Ресурси по кластеризації».