Кластеры SQL Server

Шесть шагов к созданию отказоустойчивой системы

Немного найдется вещей, которые беспокоят администраторов баз данных больше, чем кластеры 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 может видеть только те диски, которые расположены в общей с ним группе. В настройке по умолчанию после установки кластера каждый диск принадлежит своей группе.

Экран 1. Стандартный интерфейс Cluster Administrator

Логическая организация групп важна потому, что переключаются не индивидуальные ресурсы, а именно группы. Существует отличный способ протестировать аварийное переключение или просто выполнить плановое обслуживание на другом узле — это ручное переключение. Для ручного переключения группы, содержащей 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 на каждом из остальных узлов кластера.

Экран 2. Присваивание имени виртуальному SQL Server

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

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

Экран 3. Назначение адреса VIP для SQL Server

Следующая часть процесса установки позволяет указать, как расположены файлы данных и какие узлы являются возможными владельцами экземпляра 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. С ним можно связаться по адресу: bknight@swynk.com

Устранение проблем при неудачной установке

Ликвидировать неполадки в кластеризованном 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, то нарушаются все коммуникации с кластером. Эта одиночная точка сбоя — неприемлемый риск для большинства организаций.

Рисунок A. Минимально поддерживаемая сетевая инфраструктура

Во втором варианте сетевой конфигурации, изображенном на рис. B, уязвимость сети с одиночной точкой сбоя устранена посредством замены одной сетевой карты NIC2 (см. рис. A) двумя. Как показано на рисунке, NIC2 обеспечивает частные коммуникации сети через один порт, а другой порт карты NIC1 предназначен для общедоступных коммуникаций. В этой конфигурации уязвимой одиночной точкой сбоя является только концентратор.

Рисунок B. Сетевая конфигурация с пониженной зависимостью от одиночной точки сбоя

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

Рисунок C. Сетевая конфигурация без одиночной точки сбоя