Tips for DBA: выравнивание кластеров NTFS и блоков RAID-массивов

Tips for DBA: Database is in transition?!

select * from sys.dm_exec_requests ORDER BY command

ALTER DATABASE [ХХХ] SET SINGLE_USER WITH ROLLBACK IMMEDIATE

Tips for DBA: Deadlock Event Notifications

Начиная с SQL Server 2005, на службе DBA появилась такая замечательная возможность, как Event Notifications, что в русской версии BOL принято называть уведомлением о событиях. Этот механизм позволяет включить незаметную трассировку системных событий и извлекать информацию о заданных события из очереди для анализа или реакции со стороны администратора. Полный список событий, которые таким образом можно отслеживать, можно найти в статье: События трассировки для использования с уведомлениями о событии

Давайте рассмотрим упрощённый пример организации уведомлений о тупиковой блокировке и сделаем так, чтобы по электронной почте можно было получить письмо с графом блокировок.

Подготовительные действия

Для начала настройте на тестовом сервере Database Mail и убедитесь, что всё работает правильно. С возможными проблемами с почтой поможет статья: Устранение неполадок в работе компонента Database Mail

У меня с настройками возникла только одна проблема, пришлось учесть, что вызов системной хранимой процедуры в следующем ниже примере будет выполняться не в том контексте, в котором я привык работать :) В общем, пришлось на время сделать её доступной всем желающим. Вот один из способов это сделать:

USE MSDB 
Go 
GRANT EXECUTE ON msdb.dbo.sp_send_dbmail TO public
GO

Для того, чтобы задействовать очереди событий для интересующих нас баз данных, нужно включить компонент Service Broker. Как это сделать для базы AdventureWorks показано в следующем сценарии:

USE master
GO
ALTER DATABASE [AdventureWorks] SET ENABLE_BROKER WITH NO_WAIT -- с базой должен работать брокер
SELECT name, is_broker_enabled FROM sys.databases -- проверка, что брокер включён
GO

ALTER DATABASE [AdventureWorks]SET NEW_BROKER WITH ROLLBACK IMMEDIATE
GO 
ALTER DATABASE [AdventureWorks] SET ENABLE_BROKER
GO

Создание очереди, службы, сообщения и маршрута

В качестве места базирования наших очередей и сообщений мы выберем системную базу данных tempdb. Она есть на любом сервере и Service Broker для неё включён по умолчанию. Первым делом мы заготавливаем процедуру, которая будет вызываться при регистрации интересующего нас события:

USE tempdb
GO
CREATE PROCEDURE [p_Notify] 
AS
DECLARE  @subject nvarchar(128), @body nvarchar(MAX) 
DECLARE  @NotificationStore TABLE (message_body varbinary(MAX));
-- извлекаем сообщения из очереди и помещаем их в табличную переменную
RECEIVE	TOP (1) message_body FROM tempdb..DEADLOCK_Queue INTO @NotificationStore
-- собираем тему и содержимое электронного письма
SELECT	TOP (1) @body = CAST(message_body AS nvarchar(MAX)) FROM @NotificationStore        
SELECT	@subject = CAST(CURRENT_TIMESTAMP AS varchar) + ' Случился DEADLOCK'
IF @body IS NOT NULL
EXEC msdb.dbo.sp_send_dbmail	 
	 @profile_name = 'ПОЧТОВЫЙ ПРОФИЛЬ' -- профиль по умолчанию и не скрытый
	,@recipients   = 'АДРЕСАТ@ХОСТ.ru' -- адресат
	,@subject      = @subject
	,@body         = @body
GO
-- создаём очередь
CREATE	 QUEUE DEADLOCK_Queue WITH	 
	 STATUS = ON
	,RETENTION = OFF
	,ACTIVATION (
			PROCEDURE_NAME = tempdb..p_Notify,
			MAX_QUEUE_READERS = 1,
			EXECUTE AS 'dbo' 
		     )
GO
-- создаём службу
CREATE SERVICE DEADLOCK_Notify ON QUEUE DEADLOCK_Queue 
	([http://schemas.microsoft.com/SQL/Notifications/PostEventNotification])
GO
-- определяем локальную маршрутизацию
CREATE ROUTE DEADLOCK_Route WITH SERVICE_NAME = 'DEADLOCK_Notify', ADDRESS = 'LOCAL';
GO
-- создаём уведомление уровня сервера для событий появления графа тупиковой блокировки
CREATE EVENT NOTIFICATION DEADLOCK_Event ON SERVER FOR DEADLOCK_GRAPH 
-- если нужны все виды сообщений о блокировках, используйте TRC_LOCKS
TO SERVICE 'DEADLOCK_Notify', 'current database'
-- проверка
SELECT * FROM sys.server_event_notifications WHERE name = 'DEADLOCK_Event';
SELECT * FROM sys.server_events
GO

После того, как представленный выше сценарий будет успешно применён на тестовом сервере, будет создано всё необходимое для получения почтовых сообщений. В теле письма будет правильный XML, у которого в теге <TextData> лежит стандартный граф взаимоблокировки, который открывается тэгом <deadlock-list>. Если его вырезать и сохранить в файле с расширением xdl, то при открытии такого файла в приложении SQL Server Management Studio, вы увидите привычную схему блокировки, обычно получаемую с помощью SQL Server Profiler.

Удаление созданных для тестовых целей объектов

Удалить следы наших сценариев в базе данных tempdb помогут следующие команды:

-- DROP PROCEDURE p_Notify
-- DROP EVENT NOTIFICATION DEADLOCK_Event ON SERVER 
-- DROP ROUTE DEADLOCK_Route
-- DROP SERVICE DEADLOCK_Notify
-- DROP QUEUE DEADLOCK_Queue
-- ALTER DATABASE [AdventureWorks] SET  DISABLE_BROKER WITH NO_WAIT

Бонус

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

USE tempdb
GO
ALTER PROCEDURE [p_Notify] 
AS
DECLARE  @subject nvarchar(255), @x XML, @body NVARCHAR(MAX), @query NVARCHAR(MAX), @filename nvarchar(30) 
DECLARE  @NotificationStore TABLE (message_body varbinary(MAX));
-- извлекаем сообщения из очереди и помещаем их в табличную переменную
RECEIVE	TOP (1) message_body FROM tempdb..DEADLOCK_Queue INTO @NotificationStore
-- собираем тему и содержимое электронного письма
SELECT	TOP (1) @x = CAST(message_body AS XML) FROM @NotificationStore
SELECT @body = CAST(@x AS nvarchar(MAX))
SELECT @x = @x.query('/EVENT_INSTANCE/TextData/deadlock-list')
SELECT @subject = CONVERT(nvarchar(19), CURRENT_TIMESTAMP, 126) + '_DEADLOCK'
SELECT @filename = REPLACE(@subject,':','')+ '.xdl'
IF @body IS NOT NULL
BEGIN
	SELECT	@query = N'SET NOCOUNT ON SELECT ' + N'''' + REPLACE(CAST(@x AS nvarchar(MAX)),'''','') + N''''
	EXEC	msdb.dbo.sp_send_dbmail	 
	        @profile_name = 'ПОЧТОВЫЙ ПРОФИЛЬ' -- профиль по умолчанию и не скрытый
	       ,@recipients   = 'АДРЕСАТ@ХОСТ.ru' -- адресат
	       ,@subject      = @subject
	       ,@body         = @body
	       ,@query	      = @query
	       ,@execute_query_database      = 'tempdb'
	       ,@query_attachment_filename   = @filename
	       ,@attach_query_result_as_file = 1
	       ,@query_result_header = 0
	       ,@query_result_width = 32767
END
GO

Минимальные требования к размещению файлов пользовательских баз данных

Tips for DBA: Статистика I/O файлов баз данных

USE master
GO
SELECT TOP 10	DB_NAME(saf.dbid)			AS [База данных]
	,	saf.name				AS [Логическое имя]
	,	vfs.BytesRead/1048576			AS [Прочитано (Мб)]
	,	vfs.BytesWritten/1048576		AS [Записано (Мб)]
	,	saf.filename 				AS [Путь к файлу]
FROM		sysaltfiles				AS saf
JOIN	::	fn_virtualfilestats(NULL,NULL)		AS vfs
ON		vfs.dbid = saf.dbid 
AND		vfs.fileid = saf.fileid
AND		saf.dbid NOT IN (1,3,4)
ORDER BY	vfs.BytesRead/1048576 + BytesWritten/1048576 DESC
GO

SELECT   SUBSTRING(saf.physical_name, 1, 1)		AS [Диск]
       , SUM(vfs.num_of_bytes_read/1048576)		AS [Прочитано (Мб)]
       , SUM(vfs.num_of_bytes_written/1048576)		AS [Записано (Мб)]
FROM	 sys.master_files				AS saf
JOIN	 sys.dm_io_virtual_file_stats(NULL,NULL)	AS vfs
ON	 vfs.database_id = saf.database_id 
AND	 vfs.file_id = saf.file_id
AND	 saf.database_id NOT IN (1,3,4)
AND	 saf.type < 2
GROUP BY SUBSTRING(saf.physical_name, 1, 1)
ORDER BY [Диск]
GO

USE master
GO
DECLARE   @dbid int, @dbname sysname, @fileid int
	, @name sysname, @BytesRead int
	, @BytesWritten int, @filename nvarchar(255)
CREATE TABLE ##IOfilestat 
	( [База данных] sysname
	, [№ файла] int
	, [Логическое имя] sysname
	, [Прочитано (Мб)] int
	, [Записано (Мб)] int
	, [Путь к файлу] nvarchar(255)
	)
DECLARE	  filestats CURSOR GLOBAL FAST_FORWARD READ_ONLY FOR
SELECT	  saf.dbid
	, saf.fileid
	, saf.name
	, saf.filename
FROM	  sysaltfiles AS saf
WHERE	  saf.dbid NOT IN (1,3,4)
ORDER BY  saf.name

OPEN GLOBAL filestats
WHILE 1 = 1
BEGIN
	FETCH filestats INTO @dbid, @fileid, @name, @filename
	IF @@fetch_status <> 0 BREAK
	INSERT INTO ##IOfilestat 
		(   [База данных]
		,   [№ файла]
		,   [Логическое имя]
		,   [Прочитано (Мб)]
		,   [Записано (Мб)]
		,   [Путь к файлу] 
		)
	SELECT	DB_NAME(@dbid)
		,  @fileid
		,  @name
		, (SELECT BytesRead/1048576 FROM :: fn_virtualfilestats(@dbid, @fileid))
		, (SELECT BytesWritten/1048576 FROM :: fn_virtualfilestats(@dbid, @fileid))
		,  @filename
END
CLOSE GLOBAL filestats
DEALLOCATE filestats
SELECT [База данных],[№ файла],[Логическое имя],[Прочитано (Мб)],[Записано (Мб)],[Путь к файлу]
FROM ##IOfilestat
ORDER BY [Прочитано (Мб)] + [Записано (Мб)] DESC
DROP TABLE ##IOfilestat
GO

Разработка технической документации. Руководство для технических писателей и локализаторов ПО (+CD)

Как включить SQL Server 2005 в кластер

По материалам статьи Рандай Диесс (Randy Dyess): How to Guide: SQL Server 2005 Clustering

Введение

Этот документ, опубликованный в журнале «SQL Server Magazine», предназначен для технических специалистов, которые хотят разобраться с тем, как работает отказоустойчивый кластер, как SQL Server 2005 работает в кластере, как осуществляется установка и настройка SQL Server 2005 в отказоустойчивом кластере, какая практика считается лучшей для обеспечения работоспособности SQL Server 2005 в кластере.
Давно уже наметился переход от использования SQL Server 2005 для небольших решений к решениям корпоративного масштаба, критичным для бизнеса, а также возросла необходимость обеспечения высокой доступности обслуживаемых СУБД данных. В SQL Server 2005 встроены несколько механизмов, позволяющих обеспечить высокую доступность, но ни одно из стандартных средств и распространённых методов не позволяют обеспечить такой уровень доступности данных, который часто называемый «missioncritical». Это достигается только включением SQL Server 2005 в кластер.

Основы кластеризации SQL Server: Что это такое?

Отказоустойчивые кластеры (Failover clusters) – это решение для операционной системы Windows, которое позволяет администраторам создавать функциональные группы серверов, которые для приложений могут быть видимы, как суррогатные хосты, работающие на одном или более сервере, и в случае отказа этого сервера работа переносится на другой сервер группы, согласованно с прикладным уровнем. Проще говоря, кластеры обеспечивают высокую доступность приложений, работающих на серверах. Эта высокая доступность не гарантирует безостановочность работы, потому что существует некоторое время простоя, вызванное отработкой отказа; кроме того, после отказа не гарантируется тот же самый уровень работоспособности, как в штатном режиме. Включение в кластер гарантирует, что приложения кластера будут им контролироваться, и, в случае разного рода отказов, работоспособность таких приложений будет автоматически восстановлена, а они, вместе со своими ресурсами, будут запущены на другом сервере.

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

Существует несколько типов ресурсов, используемых службой кластера Windows, но наиболее проблематичным из них для администраторов, устанавливающих SQL Server 2005, является группа дисковых ресурсов. Эта группа ресурсов (Рисунок 1) представляет собой один или несколько дисков, которые сгруппированы в один функциональный модуль. Группу дисковых ресурсов рассматривают, как модуль отказа кластера, и наличие такой группы ресурсов необходимо для каждого экземпляра SQL Server 2005, работающего в одном кластере.

Каждая группа ресурсов одновременно может принадлежать только одному узлу кластера, и именно перемещение группы для монопольного использования на другой узел называется отработкой отказа (failover). Когда мы имеем дело с работающим в кластере SQL Server 2005, мы говорим о группе ресурсов, которая представляет собой цельный модуль отказа. Поскольку группа ресурсов определяет модуль отказа, каждый индивидуальный экземпляр SQL Server 2005 должен иметь свою собственную группу ресурсов. Можно использовать и несколько групп ресурсов для одной инсталляции, но в таком случае нужно установить зависимости ресурсов в разных группах, так чтобы все такие группы вели себя как единый модуль отказа.

Связанные с дисковой группой ресурсы образуют зависимости, вовлеченные в отработку отказа в кластере. Такие зависимости включают и сетевые имена, и IP – адреса каждого из ресурсов, и будут отрабатывать отказ вместе с дисковой группой ресурсов.

Примечание: Экземпляры, которые размещают базы данных или файлы баз данных на нескольких дисковых массивах (для балансировки ввода-вывода между несколькими массивам), могут связать эти массивы с помощью зависимостей ресурсов. Зависимости ресурсов позволяют нескольким группам ресурсов выступать как единый модуль отказа, и они переносятся на другой узел вместе.

Примечание: есть специальная группа ресурсов, которая принадлежит всем узлам кластера. Эта специальная группа ресурсов называется Кворум - диском, и содержит базу данных, которая используется кластером в качестве контейнера для имён участвующих в кластере узлов, а так же для информации о состоянии каждого из узлов кластера.

Какие встречаются типы кластеров?

Служба кластера Windows предлагает несколько различных типов и режимов работы кластера: кластер с одним узлом, несколько узлов в кластере, мажоритарная группа узлов (Majority NodeSet) кластера и кластер с географически разнесёнными узлами. Каждый из этих типов кластера имеет своё предназначение, а большинство кластеров, используемых для обеспечения высокой доступности SQL Server 2005, имеют один или несколько узлов, поэтому, этот документ посвящён соответствующим двум типам кластера. Для получения информации о других типах кластера обратитесь к справочной документации по Windows Server 2003.

Кластер одного узла

Кластер из одного узла (Рисунок 2) – это такая кластерная конфигурация, в которой активен только один сервер, а ещё один или несколько серверов "не активны". Неактивный сервер – это такой сервер, на котором нет активных (выполняющихся) приложений, но операционная система запущена. Неактивный сервер "поджидает", когда активный сервер попадёт в такое состояние, которое обычно вызвано выходом оборудования или программного обеспечения из строя, и начинает сам обслуживать приложение, которое в обычных условиях обслуживается активным сервером. В случае обнаружения состояния отказа, неактивный сервер становится активным сервером, и все необходимые приложениям ресурсы передаются для монопольного управления новому активному серверу, в то время как все подключения, которые существовали на старом активном сервере, повторно переустанавливаются с новым активным сервером.

Кластер нескольких узлов

Такой кластер может включать от двух до восьми активных серверов (Рисунок 3), которые работают в одной кластерной группе. Все эти активные серверы обслуживают свои приложения и каждый занят своей работой. Каждый активный сервер может быть настроен хостом приложений для одного или нескольких других активных серверов, в случае их отказа, или каждый активный сервер можно настроить так, чтобы он использовал один активный или неактивный сервер в качестве хоста приложений, если произойдёт отказ (Рисунок 4).

Кластеры из нескольких узлов позволяют администраторам использовать все или только часть ресурсов каждого сервера в группе кластера. Работая с таким кластером нужно быть предельно осторожным, поскольку работа серверов строится так, что сервер может не только быть запасным хостом для другого сервера, но он также должен обслуживать и свои собственные приложения.

Три наиболее значимые проблемы кластеров

При выборе типа кластера для ваших приложений баз данных SQL Server 2005, особое внимание стоит обратить на использование ресурсов каждого отдельного узла кластера. Утилизации ресурсов СУБД нужно уделить особое внимание, а если на сервере несколько кластерных систем, то в случае отказа в модели кластера с несколькими узлами при распределении и использовании ресурсов нужно быть особенно осторожным.

Процессор

Планирование использования процессорных ресурсов - одно из трех основных направлений при создании кластера. Используемая в не кластерных системах практика выбора такой процессорной конфигурации, чтобы процессоры использовались на 60 - 80 процентов все еще приемлема, но эта норма использования теперь должна учитывать и случаи отказа.

Это означает, что если оставить каждому узлу нагрузку процессоров в 60 – 80 процентов, они не смогут обслужить рабочую нагрузку после отработки отказа и перемещения к ним отказавшего экземпляра. Что нужно предпринять? Чтобы правильно оценить величину нагрузки на процессоре после добавление ресурсов с отказавшего узла, нужно обеспечить такой резерв, чтобы суммарная утилизация процессоров вместе с ресурсами отказавшего узла, в самом плохом варианте развития событий, никогда не превышала 80 процентов утилизации процессоров, даже если нормальная утилизация на сервере держится ниже 40 процентов. Это позволит учесть практически все возможные последствия отказов.

Память

В кластере, как и в случае с процессорными ресурсами, для обеспечения его работы в случае отказа очень важно грамотное планирование ресурсов памяти. Администратор должен чётко понимать как память узла будет использоваться приложениями в случае отработки отказа. Интенсивно использующие память прикладные программы, такие как SQL Server 2005, при отказе используют столько памяти, сколько смогут получить, и потому после перемещения отказавший экземпляр SQL Server 2005 будет запущен и начнёт работу с таким количеством памяти, который ему достанется от других экземпляров. Если памяти мало, могут возникнуть проблемы с производительностью приложений.

Примечание: Одним из новшеств SQL Server 2005 является то, что начиная с этой версии появилась возможность использования динамической памяти в кластерной конфигурации.

При настройке SQL Server 2005 в кластере с несколькими узлами, администраторам базы данных советуют установить значение параметра глобальной конфигурации сервера «max server memory» таким, чтобы оставался запас для сервера, который будет запущен на этом узле в случае отказа его оборудования. Также рекомендуется задать значение для «min server memory», чтобы не позволить экземпляру с отказавшего узла захватить всю доступную память и, тем самым, повлиять на производительность уже работающих на узле приложений.

Диски

Часто, при создании кластеров нескольких узлов, администраторы сталкиваются с проблемой недостатка букв алфавита для дисковых устройств. В операционной системе Windows группам ресурсов дают разные имена дисков на разных узлах кластера. Поскольку число групп ресурсов увеличивается вместе с увеличением числа установленных экземпляров SQL Server 2005 или из-за применения дизайна с использованием для базы данных нескольких файловых групп, при увеличения числа узлов в кластере, ограничение в 26 буквенных имен дисков может стать проблемой. Администратор баз данных совместно с системным администратором, который часто устанавливает Windows - кластер до установки туда SQL Server 2005, должны убедиться, что буквенных имен дисков достаточно много, они доступны и размеры этих дисков достаточно велики, чтобы вместить файлы баз данных.

Почему нужен кластер?

Основная цель использования кластера – обеспечение высокой доступности базы данных. Сегодня для приложений всё чаще выдвигаются такие бизнес – требования, чтобы был обеспечен доступ к данным в режиме 24/7, и недоступность базы данных из-за выхода из строя оборудования или из-за необходимости выполнения операций по обслуживанию сервера часто просто недопустима. Использование кластера серверов баз данных может помочь предотвратить недоступность данных из-за выхода из строя сервера, вызванного сбоем в программном обеспечении, необходимостью выполнения операций по обслуживанию сервера или из-за потери сетевого соединения с сервером.

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

Выгоды от кластера - Top 3

Кластер даёт довольно много преимуществ администраторам сервера и баз данных, но главными преимуществами, часто цитируемыми в контексте использования кластера серверов с SQL Server 2005, являются возможность без остановки приложений инсталлировать сервисные пакеты SQL Server 2005 или Windows, а также защита от сбоев операционной системы.

Сервисные пакеты SQL Server 2005

Несмотря на то, что команда разработки и поддержки SQL Server 2005 прилагает максимум усилий к тому, чтобы при установке сервисных пакетов не возникало простоя в работе приложений, все вышедшие на момент написания этой статьи сервисные пакеты к SQL Server 2005 требуют, чтобы администратор баз данных запланировал перезапуск обновляемых служб SQL Server 2005. При использовании кластера администраторы могут установить сервисный пакет практически без простоя приложений, инициируя отказ узла, вследствие которого база данных будет обслуживаться другим узлом, что позволит заняться установкой сервисного пакета на первом узле. В это время база данных будет доступна на втором узле, а экземпляр на первом узле может быть недоступен на время перезагрузок или иных действий.

Сервисные пакеты Windows

Как и при установке сервисных пакетов SQL Server 2005, сервисные пакеты операционной системы Windows становятся причиной простоя приложений, который может возникнуть во время установки и перезагрузки сервера после инсталляции такого пакета. Возможность инициации отказа базы данных, который переместит её ресурсы на другой узел, позволяет избежать простоя в работе с базой данных, пока операционная система Windows будет обслуживаться администратором.

Сбои Windows

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

Как устроен кластер?

Для связи между узлами кластер использует локальную сеть, и по ней же посылаются сигналы «жизни» от сервера к серверу. Такие сигналы нужны для проверки работоспособности узлов и способности их к обслуживанию приложений на уровне операционной системы и на прикладном уровне (SQL Server 2005). На уровне операционной системы этот сигнал служит для постоянного поддержания связи между узлами кластера и проверки правильности их работы.

После установки SQL Server 2005 в кластере, входящий в комплект программного обеспечения кластера Service Control Manager начинает посылать каждые пять секунд сигнал каждому активному экземпляру SQL Server 2005 (Рисунок 5). Этот сигнал, называемый "LooksAlive", практически не требует ресурсов для обработки и не выполняет других действий кроме проверки существования и работоспособности экземпляров SQL Server 2005. В задачу обмена сигналами жизни не входит проверка того, может ли экземпляр исполнять какие – либо более сложные операции. Для определения фактической работоспособности экземпляра SQL Server 2005 и его способности исполнять операции, каждые 60 секунд выполняется более глубокая проверка “IsAlive”, которая включает в себя запрос SELECT @SERVERNAME, и проверку возвращаемого значения. Если ответа нет, проверка IsAlive повторяется еще пять раз, прежде чем кластер попытается запустить ресурс на другом узле.

При отработке состояния отказа, кластер передаёт все необходимые ресурсы в монопольное владение другому экземпляру SQL Server 2005. Каждому экземпляру SQL Server 2005 принадлежит собственный набор дисков, называемый группой ресурсов (resource group), и именно эта группа ресурсов передаётся в монопольное владение другому узлу. После того, как группа ресурсов будет передана, экземпляр SQL Server 2005 инициирует процедуру стартовой регенерации (recovery), после исполнения recovery для системных баз данных, SQL Server 2005 переходит в состояние готовности к работе и обслуживанию запросов пользователей. Служба сервера баз данных должна быть запущена, а это значит, что должна быть доступна и база данных master. После обеспечения доступности базы данных master, служба сервера баз данных начинает запуск и регенерацию пользовательских баз данных.

Клиентские приложения должны будут выполнить повторное подключение, взяв за основу нового подключение конфигурацию приложения. Когда приложение соединяется с экземпляром SQL Server 2005, они используют виртуальный, а не физический IP - адрес. Фактическая принадлежность виртуального IP - адреса управляется кластером, так что приложения никогда не будут знать, на каком узле фактически находится адресуемый экземпляр. Чтобы подключится к службе SQL Server 2005 можно использовать её физический IP - адрес, но если так сделать, к ней невозможно будет подключиться в случае аппаратного отказа, т.е. если узел, являющийся основным для службы SQL Server 2005, откажет по какой – либо причине.

Как установить SQL Server 2005 в кластере

При установке SQL Server 2005 без кластера всё происходит просто и понятно, а установка SQL Server 2005 в кластер добавляет только несколько специфических шагов. Поддержка отказоустойчивого кластера осуществляется в SQL Server 2005 Enterprise Edition (поддержка до 8 узлов кластера), Developer Edition (поддержка до 8 узлов кластера) или Standard Edition (поддержка до 2 узлов кластера), а также необходима поддержка кластеризации операционной системой Windows, это следующие редакции: Windows Server 2003 Enterprise Edition, Windows 2003 Datacenter Edition, Windows 2000 Advanced Server или Windows 2000 Datacenter Edition.

Администратор, устанавливающий SQL Server 2005 в кластер, должен координировать свою работу с администраторами сервера, чтобы задать правильные номера групп ресурсов, имена дисков, размеры дисков и IP - адреса, необходимые для подключения к экземпляру SQL Server 2005. Администратор баз данных должен определиться с набором компонент, которые он должен будет установить, и понять, как эти компоненты поведут себя в кластере.

Установка ядра базы данных

Администраторам баз данных, которые только готовятся приступить к установке SQL Server 2005 в отказоустойчивом кластере, будет приятно узнать, что программа установки SQL Server 2005 умеет определять наличие кластера и автоматически устанавливать экземпляр SQL Server 2005 на обоих узлах кластера и правильно всё для этого настраивать.

При установке кластера с несколькими узлами, необходимо установить активный экземпляр на первый узел, а затем активные экземпляры на других узлах.

Примечание: допускается существование в кластере только одного экземпляра по умолчанию, это означает, что в кластере вы должны устанавливать именованные экземпляры на всех узлах, кроме одного.

Примечание: Пожалуйста, перед установкой экземпляра ядра баз данных SQL Server 2005 в кластер, изучите следующую статью SQL Server 2005 Books Online: «Как создать новый отказоустойчивый кластер SQL Server 2005 (программа установки)».

Установка Analysis Services

Как и с ядром баз данных, мастер установки SQL Server 2005 устанавливает экземпляр Analysis Services на обоих узлах кластера. Пожалуйста, предварительно ознакомьтесь с материалами, опубликованными в статье SQL Server 2005 Books Online: «Как установить службы Analysis Services на отказоустойчивом кластере».

Установка Reporting Services

К сожалению, Reporting Services не поддерживается кластером и его нужно устанавливать как автономный компонент на всех узлах. Reporting Services сможет использовать базы данных кластера, но когда случится отказ узла, к которому подключается служба Reporting Services, экземпляры отказавшего узла не будут автоматически переподключаться. Для восстановления подключения нужно соединяться с новым узлом, используя новый IP - адрес.

Установка SQL Server Integration Services

Чтобы установить SSIS, нужно установить SSIS на всех активных узлах, а затем сделать службу SSIS кластерным ресурсом. Чтобы сделать SSIS кластерным ресурсом, нужно выполнить несколько шагов:

1. Открыть Cluster Administrator.
2. В меню File выбрать пункт New, а затем щелкнуть по Resource
3. На странице New Resource мастера ресурсов (Resource Wizard), введите имя нового ресурса и выберите в качестве типа службы “Generic Service”. Измените группу на группу SQL Server. Нажмите Next.
4. На странице Possible Owners, добавьте или удалите узлы кластера, которые возможно будут владельцами нового ресурса. Нажмите Next.
5. Добавить зависимость можно на странице Dependencies, выбрав из списка Available resources новый ресурс, а затем нажав кнопку Add. В случае отказа, SQL Server 2005 и общий диск, на котором хранятся пакеты SSIS, должны стать доступны до того, как станет активен SSIS. После настройки зависимостей, нажмите кнопку Next.
6. На странице Generic Service Parameters, введите в качестве имени службы MsDtsServer, и нажмите кнопку Next.
7. На странице Registry Replication нажмите Add, чтобы добавить ключ реестра, который идентифицирует файл конфигурации SSIS.
   1. Этот файл должен быть расположен на общем диске, который принадлежит той же группе, что и SSIS, и при отказе будет перенесён на тот же узел, что и SSIS.
   2. В диалоговом окне Registry Key, введите SOFTWARE\Microsoft\MSDTS\ServiceConfigFile. Нажмите OK, а затем нажмите кнопку Finish. Служба SSIS должна добавиться под управление кластера.
9. Найдите файл конфигурации по пути %ProgramFiles%\Microsoft SQL Server 2005\90\DTS\Binn\MsDtsSrvr.ini.xml, и скопируйте его на общий диск.
10. На общем диске создайте новую папку с именем Packages и дайте на неё права List Folders и Write встроенной группе Users.
11. Откройте в текстовом или XML - редакторе файл конфигурации на общем диске и замените значение элемента ServerName на имя виртуального SQL Server 2005, который находится в этой же группе.
12. Замените значение элемента StorePath на полностью-квалифицированный путь к созданной ранее папке Packages на общем диске.
13. Откорректируйте значение ключа системного реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTS\ServiceConfigFile, записав там полностью квалифицированное имя и путь к файлу конфигурации сервиса на общем диске.
14. В приложении Cluster Administrator, выберите службу SSIS, нажмите не ней правую кнопку мыши, и выберите в выпадающем меню пункт Bring Online. Служба SSIS должна стать активной, как и служба кластера.

Установка инструментария и электронной документации

Программа установки SQL Server 2005 не устанавливает компоненты инструментов и документацию по SQL Server 2005 на все узлы кластера. Мастер устанавливает эти компоненты только на том узле, на котором была инициализирована подпрограмма установки. Если инструменты и документация нужны и на других узлах, там их нужно установить вручную после успешного окончания установки SQL Server в кластере.

Установка MSDTC

Microsoft Distributed Transaction Coordinator часто используется SQL Server 2005 для задач поддержки распределенных транзакций. Администраторы баз данных и системные администраторы должны чётко понимать, что MSDTC не будет установлен на кластере без исполнения нескольких дополнительных шагов, которые они должны правильно выполнить. В случае с кластерами серверов Windows 2003, MSDTC может быть установлен на всех серверах кластера. В прежних версиях операционных систем, MSDTC нужно было устанавливать на каждом сервере отдельно. Windows 2003 предоставляет два варианта установки MSDTC: использование для установки MSDTC в кластере программы Cluster Administrator или программы Cluster.exe, с помощью которой тоже можно установить MSDTC в кластере.

Обратите внимание: перед началом установки MSDTC в кластере Windows 2000 или Windows 2003, ознакомьтесь со следующими статьями Microsoft:

• How to configure Microsoft Distributed Transaction Coordinator on a Windows Server 2003 cluster
• How to configure MSDTC in a Windows 2000 cluster environment
• How to Cluster MSDTC
• Как установить координатор распределенных транзакций (Майкрософт)

Хорошая практика

Операционная система Windows Server 2003

• Лучше потратьте больше времени на разработку и планирование кластера, чем на само создание кластера.
• Все аппаратные средства, используемые в кластере, должен входить в лист совместимости (HCL) кластера Windows 2003, причём, в качестве модулей, а не только в качестве самостоятельных частей.
• Каждый узел кластера долж�