Советы по кластеризации серверов SQL Server

Written on . Posted in MS SQL Server

ОГЛАВЛЕНИЕ

Кластер серверов позволяет соединить несколько физических серверов (узлов), которые служат друг для друга партнерами в процедуре перехода на резервный ресурс. Избыточность, предоставляемая кластером, обеспечивает существенно более высокую продолжительность бесперебойной работы, необходимую для критических операций. За 13 лет работы с SQL Server™ я внедрил множество кластеров, и в каждом случае были свои особенности. Этот опыт позволил мне сформулировать ряд советов и рекомендаций, которые помогут сделать работу с кластерами проще и успешнее.

Кластеры серверов позволяют выгодно применить встроенные возможности кластеризации программных продуктов семейства Windows Server® (выпуски Enterprise Edition). Нужно отметить, что операционная система Windows Server 2003 больше подходит для целей кластеризации, чем операционная система Windows 2000 Advanced Server. Чтобы воспользоваться всеми преимуществами кластеризации, необходимо соответствующее оборудование, и это требует определенных затрат. Недостаточно просто «слепить» пару серверов и общий диск; нельзя также полагаться на тот факт, что отдельные компоненты оборудования входят в Каталог Windows® (в прошлом – список совместимого оборудования HCL). В Каталоге Windows должна присутствовать вся система. Однако это не повод для разочарования: существуют одобренные экономичные решения для кластеризации. На рис. 1 показана типичная конфигурация кластера.


Figure 1 A typical cluster

Разумеется, перечень вещей, которые нужно учитывать при кластеризации, не ограничивается оборудованием; необходимо также выбрать правильный выпуск сервера SQL Server 2005. Выпуск Enterprise Edition предоставляет возможности кластеризации, а также другие полезные возможности, такие как использование большего количества процессоров, распределенные и обновляемые секционированные представления, встроенная доставка журналов, автоматическое использование индексированных представлений. В случае наличия лицензии для выпуска Enterprise Edition следует подумать о кластеризации независимо от того, есть ли в организации от двух до восьми серверов, необходимых для формирования традиционного кластера (о кластерах с одним узлом речь пойдет чуть позже). Если используется выпуск SQL Server 2005 Standard Edition, можно установить кластер из двух узлов.

Операционная система Windows Server 2003 выпусков Enterprise Edition и Enterprise Datacenter Edition поставляется со встроенной кластеризацией. Достаточно просто запустить Администратор кластера и настроить кластер. Узлы можно добавлять по одному или все сразу. Аналогичным образом при установке сервера SQL Server можно выбрать установку на отдельный некластеризованный сервер или установку виртуального экземпляра на кластер. При выборе установки виртуального экземпляра можно выполнить установку на все узлы кластера, на избранные узлы или даже на один узел кластера.

Наконец, чтобы достичь истинной цели кластеризации – высокого уровня доступности,– необходимы квалифицированные специалисты и отрепетированные процедуры на случай возникновения неполадок. Хотя кластеризация является хорошей страховкой против сбоев оборудования, она не предотвращает ошибок пользователей, таких, например, как сброс важной таблицы невыспавшимся администратором базы данных посреди ночи.


 

Кластеры с одним узлом

Даже если в данный момент необходим только один сервер, все равно имеет смысл подумать о создании кластера с одним узлом. Это даст возможность впоследствии усовершенствовать конфигурацию до кластера без необходимости переделывать систему. Нужно только удостовериться, что выбранное оборудование присутствует в разделе кластеров Каталога Windows.

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



Добавление узлов

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

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

Разумеется, это заставило меня задуматься еще. Ведь можно создать сценарии, которые бы вызывали программу CLUSTER.EXE для добавления узла в сервер кластеров Microsoft® (MSCS). Все, что нужно сделать, – это передать сценарию имя узла, а остальное он сделает сам. В экстренной ситуации автоматизация – настоящий друг.



Кластеры «N+1»

Иногда узел добавляется в кластер не для замены другого узла. Возможно, в кластер требуется добавить дополнительные экземпляры сервера SQL Server, и каждому экземпляру требуются отдельные дисковые ресурсы. Хотя на одном узле может быть запущено несколько экземпляров сервера, в такой ситуации им приходится делить между собой процессор и ОЗУ, что приводит к снижению производительности. В идеальной ситуации на одном узле должен быть запущен только один экземпляр. Как гарантировать это при переходе на резервный ресурс? Очень просто! На одном из узлов не должно выполняться ни одной службы, а на каждом из остальных узлов должно быть запущено по одному экземпляру сервера SQL Server. Это и есть определение кластера «N+1»: N экземпляров, запущенных на N+1 узлах. Лишний узел является запасным.



Обновление сервера SQL Server

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

Какие имеются варианты? Сначала рассмотрим самое дорогостоящее решение: создание совершенно нового кластера, которое потребует новых серверов и, возможно, новой сети области хранения данных (SAN). Вероятно, удастся сохранить существующие сетевые коммутаторы, но этим исчерпываются возможности использования старого оборудования. Очевидно, это недешевый подход, но у него есть преимущества. Новое оборудование, как правило, работает намного лучше старого; скорость и емкость дисков непрерывно увеличиваются. Следовательно, производительность увеличится уже благодаря обновлению оборудования. Чтобы всегда иметь современное оборудование, возможно даже имеет смысл брать его в аренду.

Когда оборудование установлено, можно создать новый виртуальный сервер SQL Server и скопировать на него производственные базы данных, а затем подвергнуть новую систему всестороннему испытанию, чтобы устранить возможные неполадки до наступления срока переброски сервера. При этом следует обязательно создать сценарии для переноса учетных записей пользователей с существующего сервера на новый. (См. статью support.microsoft.com/kb/246133 (на английском языке). Также имеет смысл обновить сценарий построения учетных записей на случай внезапного полного отказа.)

Для сведения к минимуму времени простоя скорее всего потребуется использовать доставку журналов, за исключением случаев, когда базы данных очень маленькие и есть период времени, когда ни один пользователь не подключен. Доставку журналов можно выполнить непосредственно перед переброской. Затем следует отсоединить пользователей, вырезать и доставить окончательный журнал и указать приложению на новый экземпляр. (Ниже, в разделе о зеркальном отражении баз данных, рассказывается об интересной альтернативе доставке журналов.) Если используются DNS-псевдонимы, то, скорее всего, даже не придется указывать приложениям на новый экземпляр. Вместо этого нужно будет просто обновить DNS-псевдоним. Такой подход имеет следующее преимущество: в случае необходимости остановки процесса миграции на полпути и возвращения в исходное состояние это исходное состояние, по крайней мере, будет в наличии.

Можно выбрать менее дорогостоящий вариант, но он потребует более сложного предварительного планирования. Кластер может поддерживать более одного экземпляра сервера SQL Server, но каждый экземпляр должен иметь собственные дисковые ресурсы. Поэтому при организации сети области хранения данных (SAN) следует зарезервировать один номер логического устройства (LUN) для будущих обновлений. Чтобы выполнить обновление, следует установить двоичные файлы сервера SQL Server на этом дисковом ресурсе. Далее следует провести испытания системы и, когда все будет готово, завершить работу текущего сервера SQL Server, переместить дисковые ресурсы из старой группы SQL Server, обновить зависимости и перевести новый экземпляр сервера SQL Server в оперативный режим. Далее нужно присоединить базы данных из старого экземпляра, и можно считать операцию выполненной. (Вы же создали резервные копии заранее, не так ли?)

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

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



Балансировка нагрузки

Для начала опровергнем одно распространенное заблуждение. Кластеризация MSCS используется для повышения уровня доступности, а не для балансировки нагрузки. Кроме того, сервер SQL Server не имеет встроенной возможности автоматической балансировки нагрузки. Балансировать нагрузку необходимо посредством физического проектирования приложения. Что это значит?

С ростом размеров таблицы следует ожидать ухудшения быстродействия, в частности, при сканировании таблицы. Когда количество строк достигает миллионов и миллиардов, обычным решением до сих пор являлось использование секционированных представлений. Эти секционированные представления состоят из таблиц с одинаковыми схемами, объединенных с помощью инструкций UNION ALL. Кроме того, для различения таблиц-компонентов устанавливаются проверочные ограничения (инструкция CHECK), что предотвращает дупликацию данных в секционированном представлении. Если столбец, используемый в проверочном ограничении, является частью первичного ключа, то представление является обновляемым.

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

Но допустим, что уже испробованы все возможности секционирования таблиц или создания (локальных) секционированных представлений, а быстродействие все равно не на высоте. Если вы пользуетесь сервером SQL Server 2000 или SQL Server 2005, можно воспользоваться распределенными секционированными представлениями. Основное их отличие заключается в том, что таблицы-компоненты могут располагаться на разных экземплярах сервера SQL Server, и эти экземпляры могут быть установлены на кластере с конфигурацией «N+1». В чем же смысл такого решения? Если таблица-компонент в секционированном представлении становится недоступной, недоступным становится и всё представление. Если же сделать эти таблицы-компоненты частью кластера, это предоставит стабильность, необходимую для обеспечения быстродействия и балансировки нагрузки.



А так ли нужен кластер?

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

Заманчивой альтернативой кластеризации является зеркальное отражение баз данных. Для зеркального отражения необходимо три компонента: экземпляр, в котором размещена отражаемая база данных (основной сервер), резервный (зеркальный) сервер и, если требуется автоматический переход на резервный ресурс, третий (следящий) сервер. В двух словах, при зеркальном отражении базы данных происходит следующее: транзакция в базе данных на основном сервере запускается также и на зеркале. Если на основном сервере происходит сбой, возможен переход базы данных на резервный ресурс – зеркальный сервер. При наличии следящего сервера это произойдет автоматически. Зеркальное отражение необходимо настраивать для каждой базы данных вашего приложения; для системных баз данных зеркальное отражение недоступно.

В отличие от кластера, зеркальный сервер – это отдельный экземпляр SQL Server; он может быть расположен на расстоянии тысяч километров от основного сервера. Его кэши наполняются посредством действий по обновлению, которые происходят в результате транзакций, дуплицируемых с основного сервера. Разумеется, предполагается, что на зеркальном сервере не происходит никаких действий кроме получения зеркально отраженных транзакций с основного сервера. Переход на резервный ресурс в этом случае, как правило, происходит быстрее, чем в кластере, так как на зеркальном сервере SQL Server уже запущен. Поскольку кэши уже заполнены (по крайней мере, частично), начальное быстродействие не такое низкое, как в сценарии с кластером. Также следует иметь в виду, что когда на отраженной базе данных происходит переход на резервный ресурс, основной и зеркальный серверы меняются ролями.

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



Комбинированный подход

Так как зеркальный сервер может быть расположен на большом расстоянии от основного, зеркальное отражение имеет смысл использовать в планах аварийного восстановления (DR – Disaster Recovery). Кластер может служить первой линией обороны, но что случится, если применить одновременно и кластеризацию, и зеркальное отражение? Когда происходит переход на резервный ресурс в кластере, то при наличии в конфигурации зеркального отражения следящего сервера последний становится основным на то время, пока кластеризованный сервер SQL Server возвращается в оперативный режим. Однако следует иметь в виду, что переход на резервный ресурс с нового основного сервера обратно на (кластеризованный) новый зеркальный сервер не происходит автоматически. Следовательно, лучше не включать автоматический переход на резервный ресурс для зеркально отражаемых баз данных при использовании совместно с кластером.

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



Повышение гибкости с помощью виртуального сервера

Виртуализация позволяет одновременно запускать одну или более операционных систем на одном физическом сервере. Программное обеспечение виртуализации вносит в концепцию кластеризации дополнительный уровень возможностей, позволяя кластеризовать программы. Если происходит сбой на сервере, на котором запущена ведущая операционная система, этот сервер вместе с гостевыми операционными системами переходит на резервный узел. Таким способом можно легко мигрировать гостевой сервер. Кроме того, гостевая операционная система может не поддерживать кластеризацию. Следовательно, можно запустить сервер SQL Server выпуска Workgroup Edition на гостевой операционной системе Windows Server 2003, запущенной на сервере Microsoft Virtual Server 2005 в кластере. Таким образом, фактически происходит опосредованная кластеризация сервера SQL Server выпуска Workgroup Edition (см. рис. 2).

 

Figure 2 Using a virtual server



Владение ситуацией

 

Администратору, отвечающему за внедрение сервера SQL Server, нужно быть уверенным в непрерывной доступности сервера. Достичь этой цели помогает применение кластеризации сервера. В этой статье предложены проверенные опытом рекомендации, помогающие начать работу. Дополнительные полезные сведения можно найти на врезке «Ресурсы по кластеризации».

Ресурсы по кластеризации

Подробнее об описанных здесь методах и различных продуктах, необходимых для настройки кластера серверов SQL Server, см. статьи по следующим ссылкам:


Автор: Том Моро (Tom Moreau)
Иcточник: TechNet Magazine
Опубликована - 14.03.2007
форум sql server