1. Шість кроків до створення відмовостійкої системи Небагато знайдеться речей, які турбують адміністраторів...
2. Поетапна настройка кластера
3. 1. Налаштовуємо загальне сховище і мережі
4. 2. Створюємо кластер
5. 3. Налаштування кластера
6. 4. Встановлюємо SQL Server на кластері
7. 5. Налаштовуємо диски кластера
8. 6. Встановлюємо пакети виправлень
9. Усунення проблем при невдалій установці
10. Параметри настройки мережі

Шість кроків до створення відмовостійкої системи

Небагато знайдеться речей, які турбують адміністраторів баз даних більше, ніж кластери SQL Server, почасти тому, що кластеризація в SQL Server 7.0 і раніших версіях була досить складною. У SQL Server 2000 процес кластеризації вже значно спрощений. Описувані в цій статті шість кроків утворюють базовий набір дій для настройки кластера на SQL Server 2000.

Кластеризація з аварійним перемиканням - це найефективніший спосіб досягти високої відмовостійкості в середовищі SQL Server. Для кластеризації будь-яких серверів Windows використовується служба Microsoft Cluster, що зв'язує воєдино кілька серверів. У функцію служби Cluster входить перезапуск на вторинному сервері драйверів, SQL Server і відповідних служб, якщо на якомусь важливому компоненті обладнання або в службі SQL Server відбувається збій. Перемикання виконується автоматично і зазвичай займає від 30 до 60 секунд. В інших рішеннях, які забезпечують високу відмовостійкість SQL Server, таких як переміщення журналів і реплікація, хтось повинен вручну змінювати ролі на вторинному сервері, якщо аварія трапляється на головному. Незважаючи на те що переміщення журналів може виявитися ефективним рішенням з додатковими можливостями, його підтримка здійснюється вручну і настройка переміщення журналів може викликати труднощі.

Перш ніж створити кластер, потрібно зрозуміти, що кластеризація в Windows використовується тільки для цілей високою відмовостійкості. Вона не підвищує продуктивності SQL Server, оскільки в кожен момент часу працює тільки один сервер - пов'язані сервери не обробляють запити разом. Щоб отримати загальне уявлення про те, як кластеризація вписується в високу відмовостійкість SQL Server в цілому, рекомендується прочитати статтю Майкла Хотек «Методи досягнення високої відмовостійкості» ( http://www.osp.ru/ win2000 / sql / 312_4.htm ).

Базова архітектура кластерів

На малюнку спрощено зображена архітектура кластера, в якій два сервера Windows, звані вузлами, використовують загальний дисковий масив або мережеве сховище (SAN). Можна налаштувати мінімум два вузла і максимум вісім вузлів, в залежності від того, які використовуються версії SQL Server і Windows. Наприклад, кластер з 32-розрядної версії SQL Server може мати до чотирьох вузлів. Деякі кластерні архітектури можуть підтримувати два активних вузла, однак архітектура, зображена на малюнку, містить тільки один активний вузол; інший вузол, пасивний, - це сервер, що знаходиться в режимі очікування. Кожні кілька секунд служба SQL Server виконує простий запит до SQL Server, перевіряючи, чи доступний пасивний сервер. Клієнтські програми, такі як Enterprise Manager або додатки власної розробки, підключаються до SQL Server по віртуальному імені або IP-адресою (VIP-адреса), а не через реальні ім'я сервера і IP-адреса. Коли відбувається збій з подальшим перемиканням на інший вузол, володіння VIP-адресою переходить до раніше пасивного сервера, тому міняти рядок підключення для роботи програми не потрібно.

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

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

Поетапна настройка кластера

Для того щоб створити кластерізованний середу SQL Server 2000, спочатку потрібно об'єднати два або більше серверів Windows Server 2003, Windows 2000 або Windows NT. Потім можна встановлювати SQL Server 2000 на кластері. У наведеному нижче прикладі показано, як налаштувати двовузлового кластер на Windows 2000 Enterprise Edition, хоча Windows 2003 Datacenter Server підтримує до чотирьох вузлів, а Windows 2003 дозволяє збільшити число використовуваних вузлів до восьми.

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

• налаштувати загальне сховище і мережі для використання в кластері;
• створити кластер;
• налаштувати кластер;
• встановити на кластері SQL Server;
• налаштувати дисків кластера;
• встановити необхідні пакети оновлень Windows і SQL Server.

У проміжках слід перевіряти журнал подій Windows на випадок виникнення помилок. Серйозні помилки, поява яких можливо, - це порушення процедури спільного доступу. Після того як буде встановлено кластер, потрібно перевірити: системний журнал Windows і журнал додатків Windows; журнал настройки SQL Server - sqlstpn.log, де n в імені файлу позначає порядковий номер спроби настройки; журнал кластера SQL Server - sqlclstr.log. Цих двох журналів SQL Server не існує до першої спроби встановити SQL Server. Об'єднана інформація з цих журналів показує, що відбувається в кластері, і чи немає яких-небудь проблем. Можна також ввести в командному рядку SET CLUSTERLOG і побачити розташування журналів кластера. Слід обов'язково виправляти всі помилки, перш ніж переходити до наступного кроку, інакше успішна установка може зірватися. Отже, перейдемо до поетапної налаштування двовузлового кластера для SQL Server.

1. Налаштовуємо загальне сховище і мережі

Налаштування дисків для кластерних серверів - так, щоб Windows розпізнавала сховище обміну такими даними, - зазвичай самий виснажливий етап створення кластеру, оскільки цей процес вимагає принаймні трьох перезавантажень. Для пристрою спільного доступу можна використовувати або сховище SAN, або диск SCSI. Зазвичай я вибираю SAN, оскільки це дозволяє об'єднувати дисковий простір багатьох серверів і без праці додавати диски. Після того як почнеться процес кластеризації, збільшити ємність існуючих дисків не вдасться, тому в процесі настройки слід переконатися, що кожен диск, призначений для кластера, має достатню кількість вільного простору. Незважаючи на те що можна буде додавати диски пізніше, додати простір до існуючих дискам складно, так як кластеризація динамічних дисків не підтримує (тип налаштування дисків, який зазвичай допускає збільшення ємності). Ємність існуючого диска збільшується за допомогою утиліти Diskpart, що входить в комплект Windows 2000 Resource Kit і вбудованої в Windows 2003. Проте не всі виробники устаткування підтримують утиліту Diskpart, тому створення необхідного дискового простору в процесі настройки краще додавання простору пізніше.

Під час налаштування дисків на першому сервері (або вузлі) в кластері (який я назвав SQL2KNODE1) другий сервер (SQL2KNODE2) повинен залишатися вимкненим. Для настройки дисків на першому вузлі потрібно натиснути правою кнопкою на My Computer, вибрати Manage, відкрити оснастку Computer Management консолі Microsoft Management Console (MMC) і відкрити інструмент Disk Management, який використовується для управління дисками і розбиття дисків.

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

Після завершення форматування і створення міток для дисків SQL2KNODE1 слід вимкнути SQL2KNODE1 і включити SQL2KNODE2. Повернувшись до інструменту Disk Management оснащення Computer Management, ви побачите, що всі імена, призначені мережевих дисків, - неправильні, а імена томів - правильні. Потрібно скористатися іменами томів для з'ясування відповідної букви мережевого диска і перепризначити букви мережевих дисків так, щоб вони збігалися з буквами на SQL2KNODE1. На цьому настройка дисків для обох серверів закінчується.

Є кілька можливостей перейти в налаштування мережі кластера від конфігурації з одиночної точкою збою до конфігурації, що забезпечує повне резервування. Вивчити ці можливості допоможе врізка «Параметри настройки мережі». Для даної статті я вибрав перший варіант, описуваний в урізанні: використання двох мережевих карт - для простоти; але така конфігурація дійсно обходить одиночну точку збою комунікацій. Після того як бажаний варіант настройки обраний, слід привласнити кожному мережевому з'єднанню ім'я відповідно до його призначення. Наприклад, своє внутрішнє з'єднання я назвав LAN_PRIVATE, а відкрите з'єднання - LAN_PUBLIC. Тепер, коли диски спільного доступу і мережі налаштовані, все готово для створення кластера.

2. Створюємо кластер

Перед тим як встановлювати службу Cluster на перший сервер, потрібно отримати кілька IP-адрес. Знадобиться по одному IP-адресою для кожного NIC-порту на кожному сервері, один для VIP-адреси Windows і по одному для кожного екземпляра SQL Server, які планується встановити.

Необхідно відкрити Control Panel і вибрати Add / Remove Programs, Windows Components, Cluster service для запуску майстра Cluster service Configuration Wizard. Перевіряючи службу Cluster, можна помітити, що загальні компоненти Internet Information Services (IIS) встановлюються автоматично при установці служби Cluster. Ці компоненти IIS необхідні для правильної установки і комунікацій служби Cluster. На першому екрані майстра потрібно підтвердити, що все обладнання, на якому працює Windows, внесено до списку Hardware Compatibility List (HCL). Якщо проблем з обладнанням немає, слід вибрати I Understand і клацнути Next. Якщо який-небудь компонент не входить в HCL, створювана середовище може виявитися нестабільною. У наступному вікні майстра потрібно вибрати First Node in the Cluster і клацнути Next.

Потім майстер запитує, як слід назвати кластер Windows. Виберіть ім'я, що містить не більше 15 символів, використовуючи яке легко нумерувати кластери: наприклад, SANCLUSTER01 після додавання кластерів може перетворитися в SANCLUSTER02 і SANCLUSTER03. Після цього потрібно ввести ім'я користувача, пароль і ім'я домену облікового запису, від імені якої запускається служба Cluster. Обліковий запис повинен належати групі Administrators і мати пароль з необмеженим терміном дії.

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

У кількох наступних екранах майстра налаштовуються мережеві з'єднання кластера. Потрібно вибрати ім'я мережі і вказати, для чого слід використовувати мережу (для внутрішніх комунікацій, зовнішніх комунікацій або для обох типів комунікацій). На першому екрані цього ряду потрібно відповісти на питання, яку мережу слід використовувати для приватного з'єднання. Слід вибрати варіант Internal Cluster Communication Only. Для загальнодоступного мережевого з'єднання або з'єднань потрібно вибрати варіант All Communications. На наступному екрані необхідно відповісти, яка мережа має пріоритет для приватних комунікацій. В останньому вікні потрібно визначити, який IP-адреса буде використовувати кластер для клієнтського доступу.

Після того як буде задана конфігурація мережевих комунікацій, служба Cluster завершить процедуру настройки. Тепер можна завантажити сервер SQL2KNODE2 і запустити майстер Cluster service Configuration Wizard знову на другому вузлі. На цей раз слід вибрати настройку Second or Next Node in the Cluster і ввести ім'я кластера, до якого належить приєднати даний вузол. Далі потрібно ввести ім'я облікового запису та пароль для підключення до кластеру нового вузла. У наступному вікні майстер пропонує підтвердити пароль. Після цього служба Cluster об'єднує SQL2KNODE2 з кластером.

3. Налаштування кластера

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

Для настройки кластера слід розкрити Cluster Administrator в групі програм Administrative Tools панелі управління. Cluster Administrator попросить ввести ім'я кластера, до якого слід підключитися. Якщо потрібно підключитися до кластеру на сервері, на якому виконувалася реєстрація, потрібно ввести (.) І клацнути OK. Розкривши секцію Groups панелі Cluster Administrator (див. Екран 1), ви побачите, що за замовчуванням служба Cluster створює кластерну групу для кожного диска в кластері. Кластерна група - це набір дисків і служб, таких як SQL Server, які можуть бути незалежні або пов'язані один з одним. У кластерізованний середовищі SQL Server може бачити тільки ті диски, які розташовані в загальній з ним групі. У налаштуванні за замовчуванням після установки кластера кожен диск належить своїй групі.

Логічна організація груп важлива тому, що перемикаються не індивідуальні ресурси, а саме групи. Існує відмінний спосіб протестувати аварійне перемикання або просто виконати планове обслуговування на іншому вузлі - це ручне перемикання. Для ручного перемикання групи, що містить SQL Server, слід натиснути правою кнопкою миші на групі в секції Groups і вибрати з контекстного меню Move Group. Можна буде побачити, як ресурси групи переводяться з робочого режиму в неробочий, а потім знову в робочий режим на новому вузлі. Стовпець Owner в правій панелі вікна Cluster Administrator показує, який вузол зараз володіє даними груповим ресурсом. У кожної групи є свій кращий власник.

Оскільки залежності між ресурсами можна встановити тільки для ресурсів однієї і тієї ж групи, потрібно консолідувати кластерні групи по вузлу. Для того щоб консолідувати групи, я зазвичай створюю нову групу і даю їй ту ж назву, яке має сервер кращого власника цієї групи. Наприклад, після завершення налаштування кластера SQL Server буде використовувати диски M, N, O і P, як показано в табл. 1. Тому я міг би консолідувати ці диски в кластерну групу під назвою SQL2KNODE1. Щоб створити нову групу, потрібно натиснути правою кнопкою миші на папці Groups і вибрати New, Group. Далі слід привласнити групі ім'я і вказати, які вузли можуть бути власниками групи. Якщо слід перемістити диск O в кращу групу, потрібно клацнути диск правою кнопкою, вибрати Change Group, а потім вибрати ім'я групи, в яку необхідно перемістити диск O. Cluster Administrator попросить підтвердити вибір, після чого ресурс переміститься в нову групу. Ті ж дії доведеться повторити для інших вузлів кластера.

Іноді під час налаштування кластера система видає повідомлення про помилку: The cluster node is not the owner of the group. Ця помилка з'являється внаслідок того, що ресурси не можуть вільно переміщатися між власниками. Наприклад, якщо SQL2KNODE2 володіє ресурсом Disk P і слід перемістити Disk P в групу, якою володіє SQL2KNODE1, можна отримати повідомлення про помилку. Для усунення проблеми потрібно просто перемкнути ресурсну групу, як описано вище, потім спробувати змінити власника знову. Після того як всі необхідні зміни, що стосуються груп, виконані, можна видалити імена груп, які цього дня руїна, вибираючи групу і натискаючи клавішу Delete.

Після установки Cluster Services можна помітити, що обидва вузла бачать даний диск в Windows Explorer, але тільки вузол, що володіє диском, може відкривати і використовувати його. Якщо спробувати отримати доступ до диска через який не володіє диском вузол, побачити ім'я томи не вдасться - буде показана тільки буква диска. А при спробі відкрити диск система видасть повідомлення про помилку Drive is Not Accessible. Завершивши налаштування кластера, переходимо до установки SQL Server.

4. Встановлюємо SQL Server на кластері

Після того як всі кластерні ресурси переміщені в їх нові кластерні групи, все готово до установки SQL Server на кластері. Однак перед інсталяцією потрібно запустити утиліту командного рядка comclust.exe на первинному вузлі. Цей інструмент додає ресурс Microsoft Distributed Transaction Coordinator (MS DTC) в групу Cluster Group, щоб всі вузли могли мати розподілений доступ до цього ресурсу. Потім слід запустити comclust.exe на кожному з інших вузлів кластера.

Тепер можна встановлюваті SQL Server на кластері. Процедура установки SQL Server на кластері аналогічна установці SQL Server на локальному диску. На екрані 2 показано перше вікно, яке ми бачимо в процесі установки. Коли віртуального сервера призначається ім'я, SQL Server автоматично визначає, що робиться спроба інсталювати екземпляр на кластері, і вибирає потрібну настройку (Virtual Server) за замовчуванням. Необхідно ввести унікальне ім'я віртуального сервера, при цьому я знову-таки вважаю за краще дотримуватися простої моделі створення імен, які легко впорядкувати по зростанню (VSQL01), - і клацнути Next. Потім відбудеться пауза, під час якої відбувається реєстрація і перевірка імен в DNS.

Далі SQL Server пропонує призначити VIP-адресу, відповідний імені віртуального SQL Server, і вказати мережу, яку буде використовувати SQL Server, як показано на екрані 3. Необхідно ввести VIP-адресу та ім'я мережі і клацнути Add.

Наступна частина процесу установки дозволяє вказати, як розташовані файли даних і які вузли є можливими власниками примірника SQL Server. У вікні, де вказується шлях до файлів даних і двійковим файлів, потрібно підтвердити шлях до даних ще раз. Я помічав, що іноді, навіть якщо я вказав, що хочу мати дані, наприклад, на диску P, в остаточному вікні підтвердження з'являвся інший диск. Двійкові файли програм SQL Server будуть встановлені на локальні сервери через будь-які вузли, які були обрані раніше в якості можливих власників примірника. Файли даних будуть розміщуватися на кластерному диску загального доступу.

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

Цей процес може зайняти 10 хвилин, протягом яких на екрані буде тільки одне повідомлення: Setup is performing required operations on cluster nodes. This may take a few minutes ( «Програма установки виконує необхідні операції з вузлами кластера. Це може зайняти кілька хвилин»). Нарешті, служба SQL Server і підтримують служби запускаються, і установка завершена. Як і при звичайній установці SQL Server, можливо, буде потрібно перезавантажити обидва вузла в залежності від того, чи використовується модернізований Microsoft Data Access Components (MDAC) і мав процес установки ексклюзивний доступ до деяких файлів.

Якщо інсталяція пройшла невдало, можна загрузнути в тривалому процесі налагодження: не помітивши під час установки повідомлення про помилку, ви будете перевіряти велику кількість журналів, щоб знайти причину негативного результату. Кілька прийомів усунення проблем при установці SQL Server на кластері описано в урізанні «Усунення проблем при невдалій установці».

5. Налаштовуємо диски кластера

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

Щоб налаштувати залежність ресурсу SQL Server від нових дисків, спочатку потрібно перевести ресурс SQL Server в неробочий режим: натиснути правою кнопкою по ресурсу в оснащенні MMC Cluster Administrator і вибрати Take Offline. Ця дія зупиняє службу SQL Server, що викликає простий в роботі додатків, підключених до бази даних. Далі слід натиснути правою кнопкою і вибрати Properties. Щоб побачити поточні залежності, у вікні SQL ресурс Server Properties потрібно перейти на вкладку Dependencies. Потім необхідно натиснути кнопку Modify для додавання нових дисків.

Щоб з'ясувати, які ресурси кластерних дисків доступні примірнику SQL Server, можна скористатися функцією T-SQL fn_servershareddrives (). У запиті

SELECT * FROM :: FN_SERVERSHAREDDRIVES ()

ця функція формує список дисків, до яких SQL Server може отримати доступ в кластері. Це може бути корисним для усунення проблем в тому випадку, якщо не задана залежність.

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

6. Встановлюємо пакети виправлень

Навіть якщо кластер успішно встановлений, робота на цьому ще не закінчується. Завершальний крок у створенні кластера - це установка Windows 2000 Service Pack 4 (SP4) і останнього пакета виправлень SQL Server 2000 - SP3a. Windows 2000 SP4 містить безліч виправлень для кластера і усуває деякі проблеми, які можуть вводити в замішання, такі як загадковий збій, при якому SQL Server втрачає зв'язок з дисками. SQL Server SP3a також містить виправлення, а його установка на кластері порівнянна по простоті з установкою в звичайному середовищі SQL Server.

І останнє зауваження про довгостроковість роботи кластера: якщо SQL Server призначений для робіт з базою даних (т. Е. Не є Web-сервером), встановлювати на сервері антивірусні програми необхідності немає. Антивірусне програмне забезпечення на сервері SQL Server може стати причиною виникнення проблем під час аварійного перемикання. Припустимо, наприклад, що під час аварійного перемикання антивірус «бачить» нові диски на пасивному вузлі і починає сканувати їх. Якщо ці диски містять сотні гігабайтів або терабайтов даних, антивірусне сканування може привести до втрати процесором великої кількості часу з недостатнім виділенням часу на обробку запитів SQL Server, що в свою чергу обернеться зниженням продуктивності на час сканування. Якщо все ж слід запускати антивірусні програми на сервері SQL Server, як це заведено в багатьох корпораціях, ні в якому разі не слід сканувати кворумний диск і кворумние дані, журнал і резервні копії файлів.

У кластеризації немає нічого надприродно складного; це звичайний процес, який можна розбити на елементарні дії. Хоча дана стаття зачіпає основну масу питань, які можуть виникнути під час установки кластера, можливо, буде потрібно невелика практика в розгортанні кластера, перш ніж ви освоїте всі особливості обладнання. На сайті Microsoft TechNet Webcast за адресою http://www.microsoft.com/usa/webcasts/ ondemand /2030.asp представлений процес побудови кластера «0 to Cluster in 60 minutes - Clustering Windows Server 2003 and SQL Server».

Брайан Найт - старший адміністратор баз даних в компанії Alltel, має сертифікат MCSE, веде сайт http://www.swynk.com/friends/knight . З ним можна зв'язатися за адресою: [email protected]

Усунення проблем при невдалій установці

Ліквідувати неполадки в кластерізованний SQL Server буває складно, оскільки, як правило, важко зрозуміти, чому стався збій. При збої система зазвичай видає повідомлення: Setup failed to perform required operations on the cluster nodes. Після того як користувач клацне OK у вікні повідомлення, відбувається скасування установки з видаленням всіх програмних файлів і файлів даних SQL Server на кожному вузлі кластера.

Проблема установки, з якою доводиться стикатися найчастіше, полягає в тому, що в процесі установки виникають труднощі з копіюванням файлів з одного вузла на інший. Коли система видає вказане вище повідомлення про помилку, не варто натискати OK відразу. Спочатку потрібно відкрити Windows Explorer і перевірити, чи всі програмні файли SQL Server успішно скопійовані на другий вузол. Якщо немає, потрібно перевірити мережеві з'єднання кожної мережі на кожному вузлі і переконатися, що настройка File and Printer Sharing for Microsoft Networks включена. Спільний доступ до файлів і принтерів потрібно включити для того, щоб файли можна було пересилати через приватний адміністраторський ресурс admin.

Щоб перевірити, чи працює зв'язок між вузлами, слід відкрити командний рядок Run (Start, Run) і спробувати встановити доступ до ресурсу admin на іншому вузлі. Наприклад, якщо екземпляр SQL Server встановлений на диску C на вузлі SQL2KNODE1 з прикладу головної статті, потрібно спробувати отримати доступ до SQL2KNODE1, набравши SQL2KNODE2C $ в рядку Run на вузлі SQL2KNODE1. Якщо отримати доступ до зазначеного вузла не вдасться, слід з'ясувати, що перешкоджає з'єднанню. Ось кілька можливих причин.

• Налаштування брандмауера занадто суворі і, можливо, вони заважають копіювання даних з одного вузла на інший.
• Служби, що працюють на одному з вузлів, перешкоджають копіюванню файлів. Перед установкою слід зупинити всі служби, в роботі яких немає необхідності. Серед служб, з якими виникали проблеми, я міг би назвати такі служби, як будь-які захисні екрани, SNMP, Tivoli та інші служби моніторингу, а також служби незалежних розробників, наприклад Compaq Insight Manager.
• Були посилені заходи безпеки на одному або обох вузлах. Це означає, наприклад, що була виконана настройка, при якій непідписані сертифікати видаляються. Якщо це так, то потрібно зареєструватися на кожному вузлі з обліковим записом, що використовувалася в кроці 4 основної статті, скопіювати файли з одного вузла на інший і подивитися, чи немає повідомлень про такі факти, як непідписані сертифікати. Якщо подібне спливаюче повідомлення на первинному вузлі є, воно з'явиться і на вторинному. Якщо ніхто інтерактивно не є зареєстрованим користувачем і не може прочитати ці повідомлення, відбудеться затримка установки і її припинення.
• Обліковий запис, з якої виконується копіювання файлів між вузлами, можливо, не має відповідних дозволів для копіювання файлів або доступу до реєстру.

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

Корисна функція T-SQL, якою можна скористатися для налагодження кластерізованного SQL Server, - fn_virtualservernodes (). За допомогою запиту
SELECT * FROM :: FN_VIRTUALSERVERNODES ()
на основі цієї функції можна визначити, які вузли є можливими власниками ресурсу SQL Server. Наприклад, після установки обох кластерів в результатах цього запиту я повинен побачити SQL2KNODE1 і SQL2KNODE2. Після установки за допомогою даного запиту слід переконатися, що екземпляр SQL Server працює, як очікувалося, і що всі можливі вузли можуть бути власниками ресурсу.

Параметри настройки мережі

Налаштовуючи кластерізованний середу для SQL Server, потрібно мати на увазі, що існує кілька варіантів настройки мережі. На рис. A показано, як виглядає мінімальна конфігурація кластера, підтримувана Microsoft. На малюнку видно, що одна мережева карта на кожному сервері зарезервована для приватного межкомпонентное з'єднання. Це приватний зв'язок призначене тільки для роботи кластера - в його функції входить лише перевірка стану кластерних ресурсів. Інша мережева карта зарезервована для загальнодоступних комунікацій, і вона є каналом резервного копіювання кластера. Завжди краще мати приватні комунікації у власній підмережі, оскільки зв'язок в кластерізованний середовищі використовує значну частину смуги пропускання мережі. Приватне з'єднання може бути або перехресним (використовується спеціальний мережевий кабель, безпосередньо з'єднує два сервера), або звичайним мережевим з'єднанням. Основний недолік цієї простої конфігурації полягає в тому, що вона вразлива в плані наявності одиночної точки збою. Наприклад, якщо відбувається відмова NIC2, зображеної на рис. A, то порушуються всі комунікації з кластером. Ця одиночна точка збою - неприйнятний ризик для більшості організацій.

У другому варіанті конфігурації мережі, зображеному на рис. B, вразливість мережі з одиночної точкою збою усунена за допомогою заміни однієї мережевої карти NIC2 (див. Рис. A) двома. Як показано на малюнку, NIC2 забезпечує приватні комунікації мережі через один порт, а інший порт карти NIC1 призначений для загальнодоступних комунікацій. У цій конфігурації вразливою одиночній точкою збою є тільки концентратор.

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