.

Развертывание на месте

Для начала хочу напомнить, что если ваши базы данных достаточно важны, чтобы оправдать избыточность, не стоит рисковать, размещая службы отказоустойчивой кластеризации Windows Server (WSFC) под производственными серверами SQL Server. Так вы лишите себя возможности воспользоваться новыми аппаратными средствами, с помощью которых можно безопасно настроить любые параметры, устранить неполадки перед активным применением, а затем использовать новую среду в качестве песочницы для безопасного тестирования отработки отказов, сбоев, программных обновлений и т.д.

Лицензирование

Два основных «правила» лицензирования гласят: «ВСЕ активные рабочие нагрузки должны быть лицензированы» и «каждая версия поставляется с бесплатной лицензией, при этом слово «бесплатная» означает: используется только для целей пассивной отработки отказов». Правила верны. Но это лицензирование, поэтому имейте в виду, что здесь обязательно есть тонкости и дополнительные детали.

Кворум

Один из лучших обзоров важных особенностей — статья Брента Озара о группах доступности AlwaysOn и практических уроках их использования (http://www.brentozar.com/archive/2013/07/alwayson-availability-groups-real-life-lessons-learned-video/). Прочитать ее очень полезно, если вам не хватает знаний о механизме кворума и рекомендуемых методах работы.

Группа серверов или группа доступности

Это слишком сложная тема, чтобы попытаться охватить ее в одной небольшой статье. Если вы хотите узнать, что означают эти термины, рекомендую обратить внимание на документацию по компоненту Backup Preferences мастера установки (http://msdn.microsoft.com/query/dev10.query?appId=Dev10IDEF1&l=EN-US&k=k(SQL11.SWB.AVAILABILITYGROUPPROPERTIES.BACKUPPREFERENCES.F1)&rd=true). Заметьте, в документации говорится, что эти предпочтения не применяются принудительно.

Для их применения необходимо использовать sys.fn_hadr_backup_is_preferred_replica и избрать подход, описанный в документации для резервного копирования вторичных реплик.

Также здесь приводятся сведения об управлении процедурами регистрации и заданиями (technet.microsoft.com/en-us/library/hh270282.aspx).

Масштабирование

Есть некоторые проблемы, относящиеся к группам доступности, Active Secondaries и масштабированию. В частности, почему их намного труднее реализовать (особенно в существующих приложениях), нежели говорить о них. Чтобы избежать проблем, рекомендую использовать iDB компании ScaleArc (www.scalearc.com/), превосходное решение, отлично дополняющее группы доступности AlwaysOn.

Дополнительные вопросы

Есть еще две темы, которые мне хотелось рассмотреть, но не хватало времени.

Отработка отказа не происходит мгновенно. Отработка отказа WSFC обычно совершается не более чем за 2-3 секунды или быстрее (при «чистых» отказах). Тем не менее, когда экземпляр SQL Server запускается и получает контроль над ресурсами базы данных, ему необходимо пройти через процесс восстановления. Благодаря репликам группы доступности время восстановления обычно невелико (если речь идет о синхронных репликах) и может составлять примерно 20-40 секунд. Но при использовании экземпляров отказоустойчивого кластера новый активный узел, в сущности, запускается с нуля. Обычно ему требуется меньше минуты, чтобы начать полноценно обслуживать все базы данных. Дополнительные сведения приведены в моей статье «Косвенные контрольные точки в SQL Server 2012» (опубликованной в этом же номере журнала).

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

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

Предположим, у нас имеется интенсивно используемый сервер, обрабатывающий большие объемы данных. При этом с накопителей регулярно считывается немногим менее 300 Мбайт/с.

В качестве вторичного устанавливается другой, менее мощный сервер. Он не так хорош в качестве резервного сервера, но его предполагается использовать время от времени, при плановых исправлениях и обновлениях, в часы с малой рабочей нагрузкой или в случае временного отказа основного сервера, когда требуется переместить операции на вторичный компьютер. Предположим, что максимальная пропускная способность дисков резервного сервера — 200 Мбайт/с.

В такой ситуации, если объединить эти два сервера как реплики, пропускная способность основного сервера будет ограничена 200 Мбайт/с, просто потому, что каждая операция или транзакция, выполняемая на основном сервере, должна зеркально отражаться (в реальном времени) на медленном вторичном сервере.

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

Проблема обычно возникает, когда группы доступности развертываются при отсутствии понимания текущей рабочей нагрузки и/или при наличии узких мест, появляющихся в результате «объединения» нескольких узлов.

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

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

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

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF