Руководство по архитектуре AlwaysOn. Построение
advertisement
Руководство по архитектуре AlwaysOn. Построение решения высокого уровня доступности и аварийного восстановления с помощью групп доступности AlwaysOn Техническая статья по SQL Server Авторы: Джозеф Сэк (SQLskills.com), Санджай Мишра (Майкрософт) Технические рецензенты: Линдсей Аллен (MS), Юрген Томас (MS), Майк Вайнер (MS), Прем Мехра (MS), Йохирито Тада (MS), Курт Мэттьюс (MS), Амитаб Тамхейн (MS), Адития Самант (MS), Даниэль Джаник (MS), Джимми Мей (MS), Дэвид П Смит (ServiceU), Ричард Веймайр (SolidQ), Брент Озар (Brent Ozar PLF), Вольфган Кучера (bwin.party), Поль С. Рэндал (SQLskills.com), Джанлука Хоц (SolidQ), Айад Шаммут (Caregroup) Руководитель программы содержимого: Гленн Минч (Майкрософт) Опубликовано: июнь 2012 г. Область применения: SQL Server 2012 Сводка. Группы доступности AlwaysOn SQL Server 2012 предоставляют стандартизированное решение высокого уровня доступности и аварийного восстановления (HADR), которое улучшает функциональность, в прошлом распределенную по различным компонентам. До выпуска SQL Server 2012 многие клиенты использовали зеркальное отображение базы данных для достижения высокого уровня локальной доступности в центре обработки данных и доставку журналов для аварийного восстановления в удаленном центре обработки данных. В SQL Server 2012 эту распространенную схему можно заменить архитектурой, использующей группы доступности для обеспечения как высокого уровня доступности, так и аварийного восстановления. В документе приводится описание основных требований к топологии этой схемы, включая рекомендации по настройке кворума, шаги, необходимые для построения рабочей среды, а также рабочий процесс, который показывает, как обрабатывать событие аварийного восстановления в новой топологии. Авторские права Данный документ предоставляется согласно принципу «как есть». Сведения и мнения, содержащиеся в этом документе, включая URL-адреса, а также ссылки на другие веб-сайты, могут изменяться без предварительного уведомления. Вы принимаете на себя риск, связанный с использованием этого документа. Некоторые примеры, описанные в настоящем документе, являются вымышленными и приведены исключительно в демонстрационных целях. Примеры не рассчитаны на применение в реальных условиях, поэтому их не следует рассматривать как относящиеся к реальным ситуациям. Настоящий документ не предоставляет пользователям прав на интеллектуальную собственность Майкрософт. Разрешается копирование и использование документа только для внутреннего использования с целью предоставления справочных сведений. © Корпорация Майкрософт (Microsoft Corporation), 2012. Все права защищены. 2 Содержание Введение ...................................................................................................................................................... 4 Устаревшая архитектура. Зеркальное отображение базы данных для обеспечения высокого уровня доступности и доставка журналов для аварийного восстановления ....................... 5 Группы доступности AlwaysOn для обеспечения высокого уровня доступности и аварийного восстановления ........................................................................................................................................... 6 Рекомендации по планированию и развертыванию ............................................................................... 7 Необходимые компоненты топологии ................................................................................................. 8 Единица отработки отказа...................................................................................................................... 8 Рекомендации по замене доставки журналов ..................................................................................... 8 Модель кворума и голоса узлов ............................................................................................................ 8 Средства для просмотра или изменения модели кворума и голосов узлов ............................... 12 Настройка модели кворума WSFC ................................................................................................... 12 Использование динамических административных представлений и панели мониторинга AlwaysOn для просмотра сведений о кворуме ....................................................... 13 Настройка голосов узлов .................................................................................................................. 15 Возможность подключения клиентов ................................................................................................. 15 Строки подключения к зеркальным отображениям устаревших баз данных ............................. 15 Прослушиватель группы доступности ............................................................................................. 15 Поддержка соединения с несколькими подсетями ...................................................................... 16 Построение решения на основе групп доступности .............................................................................. 16 Рекомендации по мониторингу ............................................................................................................... 27 Восстановление по журналу после сбоя ................................................................................................. 27 Возврат к использованию основного центра обработки данных ......................................................... 33 Заключение ................................................................................................................................................ 37 Ссылки ........................................................................................................................................................ 37 Приложение А. Пример групп доступности на основе высокой доступности и аварийного восстановления с использованием трех центров обработки данных.................................................. 38 3 Введение Microsoft SQL Server 2012 AlwaysOn обеспечивает гибкость при проектировании, позволяя выбрать подходящее для вашего приложения решение по высокому уровню доступности и аварийному восстановлению. Существует несколько схем для построения решений высокой доступности и аварийного восстановления с помощью SQL Server 2012 AlwaysOn. В техническом документе приводится описание решения, использующего группы доступности AlwaysOn для обеспечения высокой доступности и аварийного восстановления. Это решение, которое основывается исключительно на закрытом хранилище, поскольку каждый экземпляр SQL Server в топологии имеет собственную копию данных, при этом нет необходимости открывать хранилище для общего доступа. Дополнительные сведения о других вариантах схемы см. в разделе Схемы разработки высокого уровня доступности и аварийного восстановления с помощью SQL Server 2012 AlwaysOn. До выпуска SQL Server 2012 распространенная архитектура развертывания высокой доступности и аварийного восстановления предполагала использование зеркального отображения базы данных для обеспечения высокого уровня локальной доступности и доставки журналов для удаленного аварийного восстановления. В SQL Server 2012 решение на основе групп доступности с несколькими серверами-получателями может заменить устаревшее решение, использующее зеркальное отображение базы данных и доставку журналов. В документе рассматриваются рекомендации по планированию и инструкции, необходимые для построения групп доступности с целью обеспечить высокий уровень доступности и аварийное восстановление. В документе также перечислены шаги, необходимые для восстановления после сбоя, и рассматривается процесс возврата к основному центру обработки данных после его восстановления. Предполагается, что читатель обладает базовыми наборами знаний о группах доступности AlwaysOn, концепциях высокого уровня доступности и аварийного восстановления. Дополнительные сведения о полном наборе возможностей решения AlwaysOn см. в техническом документе Руководство по решениям высокого уровня доступности и аварийного восстановления Microsoft SQL Server AlwaysOn. Целевая аудитория этого технического документа — администраторы баз данных, эксплуатирующие SQL Server, а также архитекторы технологий. Документ также будет интересен системным администраторам, которые работают вместе с администраторами баз данных и занимаются управлением Windows Server, служб Active Directory Domain Services (AD DS), отказоустойчивых кластеров Windows Server и сетей. 4 Устаревшая архитектура. Зеркальное отображение базы данных для обеспечения высокого уровня доступности и доставка журналов для аварийного восстановления До выпуска SQL Server 2012 одна из популярных клиентских архитектур развертывания SQL Server предполагала использование зеркального отображения базы данных для обеспечения высокого уровня доступности в основном центре обработки данных и доставку журналов для аварийного восстановления независимо от центра обработки данных. Для этого решения зеркальное отображение базы данных настраивается в основном центре обработки данных. Для реализации автоматической отработки отказа необходимо настроить синхронное зеркальное отображение базы данных со следящим сервером (дополнительный экземпляр SQL Server). Если необходимо исключить потерю данных, включается режим (синхронный) высокой безопасности зеркального отображения базы данных с целью обеспечения нулевой потери данных между двумя серверами, расположенными в первичном центре обработки данных. Для повышения доступности базы данных в основном центре обработки данных необходимо настроить в качестве следящего сервера третий экземпляр SQL Server с целью обеспечения автоматической отработки отказа между участниками зеркального отображения. Если в результате сбоя основного центра обработки данных оба экземпляра, участвующие в зеркальном отображении базы данных, становятся недоступными, то для аварийного восстановления используется доставка журналов. Доставка журналов задействует текущие резервные копии журналов транзакций основной базы данных. Такие резервные копии журналов транзакций копируются в экземпляр SQL Server в центре обработки данных аварийного восстановления. Входящие резервные копии журналов транзакций восстанавливаются по порядку один за другим. Можно также настроить доставку журналов для рабочей нагрузки только для чтения. Недостаток такого подхода заключается в том, что соединения в режиме только для чтения должны быть сброшены перед применением резервных копий журналов входящих транзакций. Рис. 1 демонстрирует архитектуру решения. 5 Рис. 1. Зеркальное отображение базы данных для обеспечения высокого уровня доступности и доставка журналов для аварийного восстановления Дополнительные сведения об этом решении, включая пример практического использования, см. в технической публикации Высокий уровень доступности и аварийное восстановление для уровня данных SAP Microsoft. Технический пример практического использования SQL Server 2008. Группы доступности AlwaysOn для обеспечения высокого уровня доступности и аварийного восстановления Группы доступности AlwaysOn можно использовать для замены вышеуказанного решения зеркального отображения базы данных и доставки журналов. Использование групп доступности для высокой доступности и аварийного восстановления предоставляет следующие преимущества. 6 Можно сгруппировать несколько пользовательских баз данных в одну единицу отработки отказа. Напротив, зеркальное отображение базы данных поддерживает только одну пользовательскую базу данных как единицу отработки отказа. Несколько серверов-получателей групп доступности позволяют пользователю объединить решение высокой доступности и аварийного восстановления в одну технологию, что заменяет собой использование нескольких технологий, используемых в предыдущем решении. Вторичные реплики также можно настроить так, чтобы рабочие нагрузки только для чтения получали практически актуальные данные. В отличие от доставки журналов, не нужно отключать текущие соединения только для чтения с вторичными репликами, чтобы просмотреть текущие изменения данных для первичной реплики. Вторичные реплики также можно использовать, чтобы освободить все операции баз данных и резервной копии журнала транзакций. Группы доступности и связанный прослушиватель групп доступности поддерживают автоматическое перенаправление клиента либо на первичную реплику, либо к доступным вторичным репликам. Прослушиватели групп доступности снимают необходимость назначать партнера по обеспечению отработки отказа в клиентской строке подключения. Рис. 2 демонстрирует решение высокой доступности и аварийного восстановления с помощью групп доступности. Аварийное восстановление Центр обработки данных Основной центр обработки данных Отказоустойчивый кластер Windows Server (один WSFC, действующий в двух центрах обработки данных) SQL Server SQL Server Вторичный SQL Server Основной Вторичный Синхронная Асинхронная Группа доступности Рис. 2. Использование групп доступности для обеспечения высокого уровня доступности и аварийного восстановления Как указано на рис. 2, три узла, каждый из которых работает под управлением экземпляра SQL Server, участвуют в одном отказоустойчивом кластере Windows Server (WSFC), который работает для двух центров обработки данных. Также важно отметить, что это закрытое решение, поэтому узлы не имеют общего хранилища с другими узлами. Каждый узел работает под управлением экземпляра SQL Server и имеет собственную копию данных. Примечание. На рис. 2 показан простой сценарий с двумя центрами обработки данных. В основном центре обработки данных размещены две реплики, а в центре обработки данных для аварийного восстановления — одна. Архитектура допускает разные варианты топологии с использованием нескольких центров данных, а также нескольких реплик (не более пяти). Обсуждение в этом техническом документе сосредоточено на топологии, показанной на рис. 2, в то же время общие концепции применимы и к другим ее вариантам. Один такой вариант, в котором задействуется три ЦОД, рассматривается в приложении A. Рекомендации по планированию и развертыванию В следующих нескольких разделах приводятся рекомендации по планированию, требования и необходимые условия, которые следует учитывать при планировании развертывания групп доступности для обеспечения высокого уровня доступности и аварийного восстановления. 7 Необходимые компоненты топологии Важно понимать предварительные условия и ограничения до начала разработки решения высокой доступности и аварийного восстановления с помощью групп доступности. Дополнительные сведения о предварительных условиях и ограничениях для групп доступности AlwaysOn см. в разделе Предварительные требования, ограничения и рекомендации для групп доступности AlwaysOn (SQL Server). Единица отработки отказа В этом решении высокой доступности и аварийного восстановления за единицу отработки отказа принимается группа доступности (группа пользовательских баз данных). Задания агента SQL Server, имена входа, связанные серверы и другие объекты, сохраненные вне баз данных доступности, не участвуют в отработке отказа с группой доступности. Воспользуйтесь автономными базами данных для имен входа, которые участвуют в отработке отказа для нескольких реплик доступности. Для других объектов вне пользовательской базы данных, таких как задания агента SQL Server, связанные серверы и пакеты служб SQL Server Integration Services, необходимо выполнить дополнительные шаги синхронизации между экземплярами SQL Server. Рекомендации по замене доставки журналов При замене прежнего решения на основе доставки журналов решением на основе групп доступности следует учитывать следующие вопросы. Удаление доставки журналов означает, что в отношении вторичных реплик не будет применяться «отложенное действие». Записи журнала реплики групп доступности применяются сразу, и соответствующее отложенное действие, которое обеспечивалось доставкой журналов, недоступно для групп доступности. Если эта функция была обязательной частью прежнего решения, необходимо разработать альтернативное решение или использовать доставку журналов совместно с решением на основе групп доступности. Удаление доставки журналов также означает, что задание обычного резервного копирования журналов будет удалено. Группы доступности не заменяют стратегию резервного копирования и восстановления. Необходимо проводить периодическое резервное копирование журналов как отдельный процесс для групп доступности в целях сохранения контроля над журналом транзакций для всех баз данных доступности в группе доступности. Модель кворума и голоса узлов Примечание. Кворум и соответствующие вопросы в этом техническом документе применимы к решениям в операционных системах Windows Server 2008 и Windows Server 2008 R2 с соответствующими обновлениями программного обеспечения. 8 Поскольку базовой инфраструктурой группы доступности служит кластер WSFC, важно рассмотреть соответствующую модель кворума для WSFC. Управление конфигурацией кворума происходит на уровне WSFC вне зависимости от количества реплик и групп доступности, размещенных в WSFC. Кластер WSFC поддерживает 4 модели кворума. Однако не все модели кворума подходят для решения на основе закрытого хранилища, которое рассматривается в этом техническом документе. В этом смысле модели кворума на основе общего диска (большинство узлов и дисков, в меньшинстве — только диск) неприменимы. Таким образом, остаются две модели кворума, совместимые с выбранной архитектурой решения: большинство узлов с общим доступом к файлам или большинство узлов без доступа. Дополнительные сведения о четырех моделях кворума см. в разделе Пошаговое руководство по отказоустойчивым кластерам. Настройка кворума в отказоустойчивом кластере. Прежде чем выбирать модель кворума, важно учитывать число голосующих узлов. Назначение голосов соответствующим узлам играет важную роль в схеме HA+DR. По умолчанию у каждого узла в отказоустойчивом кластере имеется один голос, но этот вариант может быть неподходящим для отдельных решений HA+DR в зависимости от распределения узлов между основным центром обработки данных и центром обработки данных аварийного восстановления. Доступен пакет исправления для Windows Server (http://support.microsoft.com/kb/2494036), позволяющий присваивать в кластере WSFC каким-то узлам один голос, а каким-то нуль голосов. Свойство NodeWeight узла WSFC представляет количество голосов для данного узла. Значение «0» указывает, что у узла нет голоса. Значение «1» означает, что у узла есть голос в кворуме. Это исправление необходимо установить на все узлы в топологии. Общие рекомендации голосования кворума для решения HA+DR на основе групп доступности AlwaysOn приведены в статье Рекомендуемые настройки для голосования с кворумом в разделе Режимы кворума и конфигурация голосования WSFC электронной документации по SQL Server. Их следует рассматривать как рекомендации при выборе схемы голосования в решении AlwaysOn. Если следовать этим рекомендациям для решения на основе групп доступности HA+DR, представленного на рис. 2, схема голосования будет следующей: Один голос для каждого из узлов в основном центре обработки данных. Нуль голосов для узла в центре обработки данных аварийного восстановления. Такое распределение голосов позволяет кворуму голосов в основном центре данных работать вне зависимости от сбоев в центре обработки данных аварийного восстановления или потери возможности подключения между двумя центрами обработки данных. 9 При нечетном числе узлов с правом голоса лучше всего использовать модель кворума на основе большинства узлов. Поскольку топология, рассматриваемая в этом техническом документе, имеет четное число узлов с правом голоса (2 узла в основном центре обработки данных), то есть возможность выбрать один из следующих вариантов. Добавить дополнительный узел с правом голоса в кластер WSFC в основном центре обработки данных и затем использовать модель кворума на основе большинства узлов. На этом дополнительном узле нет необходимости устанавливать экземпляр SQL Server, и ему не обязательно быть репликой группы доступности. Такая конфигурация с голосами соответствующего узла приведена на рис. 3 (распределение голосов узлов будет рассмотрено в последующих разделах в этом техническом документе). Аварийное восстановление Центр обработки данных Основной центр обработки данных Отказоустойчивый кластер Windows Server (один WSFC, действующий в двух центрах обработки данных) SQL Server SQL Server ГОЛОСУЕТ ГОЛОСУЕТ Основной НЕ ГОЛОСУЕТ Вторичный SQL Server Вторичный Синхронная Асинхронная Группа доступности ГОЛОСУЕТ Дополнительный сервер для модели кворума по большинству узлов Рис. 3. Распределение голосов узлов для развертывания групп доступности с использованием HA+DR и модели кворума на основе большинства узлов 10 Использовать модель кворума на основе большинства узлов c открытым доступом к файлам вместе со следящим сервером с защищенным доступом к файлам. Общий доступ к файлам предоставляет дополнительный голос для кворума и не содержит каких-либо данных SQL Server. Эта конфигурация с голосами соответствующего узла показана на рис. 4. Аварийное восстановление Центр обработки данных Основной центр обработки данных Отказоустойчивый кластер Windows Server (один WSFC, действующий в двух центрах обработки данных) SQL Server SQL Server ГОЛОСУЕТ ГОЛОСУЕТ НЕ ГОЛОСУЕТ Вторичный Основной SQL Server Вторичный Синхронная Асинхронная Группа доступности ГОЛОСУЕТ Общая папка Рис. 4. Распределение голосов узлов для развертывания групп доступности с использованием HA+DR и модель кворума на основе большинства узлов с открытым доступом к файлам Обратите внимание, что следящий сервер с общим доступом к файлам находится за пределами кластера WSFC, в котором размещается группа доступности. Общая папка может объединять один или несколько кластеров WSFC. Следящий сервер с общей папкой, если он используется, всегда имеет голос. Нельзя присвоить 0 голосов следящему серверу с общим доступом к файлам. Для модели кворума и распределения голосов, представленных на рис. 3 и 4, предполагается наличие трех реплик (одна основная и две дополнительные) группы доступности (две реплики в основном центре обработки данных и одна — в центре обработки данных аварийного восстановления). При наличии другого числа узлов и реплик распределение голосов может немного отличаться, однако основные принципы по-прежнему будут применимы. Например, если имеется дополнительная реплика в основном центре обработки данных (чтобы высвободить рабочую нагрузку только для чтения или рабочую нагрузку резервного копирования), в основном центре обработки данных будет всего три узла. Таким образом, можно будет использовать модель кворума на основе большинства узлов и не использовать дополнительный узел (как показано на рис. 3) или следящий сервер с общим доступом к файлам (как показано на рис. 4). В этом случае можно присвоить один голос каждому узлу в основном центре обработки данных и нуль голосов узлу в центре обработки данных аварийного восстановления. Для модели кворума и распределения голосов, представленных на рис. 3 и 4, также предполагается, что решение работает с двумя центрами данных. В случае если центров обработки данных больше и часть решения планируется разместить в третьем центре обработки данных, решения по модели кворума и назначениям голосов могут изменяться. 11 Средства для просмотра или изменения модели кворума и голосов узлов Существует несколько способов просмотра и изменения как кластерной модели, так и голосов кворума. В следующих таблицах приведены различные средства для выполнения этих задач. Просмотр модели кворума Диспетчер отказоустойчивого кластера Windows PowerShell Cluster.exe Динамические административные представления SQL Server (DMV) Панель мониторинга AlwaysOn в SQL Server Management Studio Просмотр голосов узлов Windows PowerShell Cluster.exe Динамические административные представления SQL Server (DMV) Панель мониторинга AlwaysOn Изменение модели кворума Диспетчер отказоустойчивого кластера Windows PowerShell Cluster.exe Изменение голосов узлов Windows PowerShell Cluster.exe Настройка модели кворума WSFC Ниже приведены примеры использования Windows PowerShell с помощью командной строки для просмотра текущей модели кворума и ее изменения. Просмотр текущей модели кворума Get-ClusterQuorum Настройка модели кворума на основе большинства узлов Set-ClusterQuorum -NodeMajority Изменение модели кворума на «Большинство узлов и общих папок» Set-ClusterQuorum -NodeAndFileShareMajority \\EMU-DC\Witness Выбираемая общая папка следящего сервера не должна располагаться на узле, уже участвующем в конфигурации AlwaysOn кластера WSFC. Однако ее можно разместить в виде общей папки в другой конфигурации кластера WSFC. Она должна располагаться в том же домене Active Directory, что и кластер WSFC. Кроме того, учетной записи службы кластера WSFC требуется разрешение как на чтение, так и на запись в общую папку следящего сервера. Диспетчер отказоустойчивого кластера содержит встроенную логику, добавляющую эти разрешения в общую папку следящего сервера, если учетная запись администратора, через которую изменяется модель кворума, имеет в этой папке соответствующие разрешения. 12 Использование динамических административных представлений и панели мониторинга AlwaysOn для просмотра сведений о кворуме Задать или изменить модель кворума и количество голосов узла с помощью средств SQL Server невозможно, однако можно использовать запросы Transact-SQL к динамическим административным представлениям и панель мониторинга AlwaysOn в среде SQL Server Management Studio для просмотра голосов узлов и модели кворума в кластере Windows, в котором размещается группа доступности. Чтобы просмотреть модель кворума кластера Windows, на котором размещается группа доступности, выполните запрос к динамическому административному представлению sys.dm_hadr_cluster. SELECT FROM cluster_name, quorum_type_desc, quorum_state_desc sys.dm_hadr_cluster; Если запрос выполняется в среде, рассмотренной в техническом документе, он возвращает следующее. cluster_name -----------EMU-AGClstr quorum_type_desc ---------------NODE_AND_FILE_SHARE_MAJORITY quorum_state_desc ----------------NORMAL_QUORUM Для просмотра голосов узлов выполните запрос к динамическому административному представлению sys.dm_hadr_cluster_members. SELECT FROM member_name, number_of_quorum_votes sys.dm_hadr_cluster_members; Если запрос выполняется в среде, рассмотренной в техническом документе, он возвращает следующее. (Распределение голосов рассматривается в следующем разделе.) Member_name number_of_quorum_votes ----------- ---------------------EMU-SQL1 1 EMU-SQL2 1 EMU-SQL3 0 FSWitness 1 Панель мониторинга AlwaysOn в SQL Server Management Studio также можно использовать для отображения голосов кворума и состояния кластера. На рис. 5 показаны эти сведения для кластера Windows с моделью кворума «Большинство узлов» (состояние кластера и голоса кворума выделены). 13 Рис. 5. Отображение голосов кворума и состояния кластера на панели мониторинга AlwaysOn для модели кворума на основе большинства голосов По умолчанию столбец Голоса кворума не отображается, но его можно добавить на панель мониторинга, щелкнув правой кнопкой мыши заголовок столбца таблицы Реплика доступности и выбрав столбец для отображения. Для модели кворума «Большинство узлов и общих папок» это представление панели мониторинга AlwaysOn отображает только узлы, но не общий файловый ресурс. Чтобы просмотреть полные сведения о кворуме, щелкните в правой части окна Просмотр сведений о кворуме кластера. Откроется всплывающее окно, подобное рис. 6. Рис. 6. Сведения о кворуме кластера для модели «Большинство узлов и общих папок» 14 Настройка голосов узлов Свойство NodeWeight узла WSFC представляет количество голосов для данного узла. В следующем примере показана настройка свойства NodeWeight узла из узла в кластере WSFC с помощью Windows PowerShell. Чтобы запустить Windows PowerShell на узле сервера, нажмите Пуск, выберите Средства администрирования, затем выберите Модули Windows PowerShell. В этом примере EMU-SQL3 представляет узел WSFC, расположенный в дополнительном центре обработки данных. Просмотр текущих настроек голосов для всех узлов Get-ClusterNode | fl NodeName, NodeWeight Установка голоса узла в «0» (Get-ClusterNode "EMU-SQL3").NodeWeight=0 Примечание. Значение «0» указывает, что у узла нет голоса. Значение «1» означает, что у узла есть голос в кворуме. Возможность подключения клиентов В этом разделе приводится краткое описание возможности подключения клиента при перемещении к решению группы доступности. Дополнительные сведения о возможности подключения клиентов и деталях отработки отказа в приложениях см. в разделе Возможность подключения клиентов и отработка отказа приложений (группы доступности AlwaysOn). Строки подключения к зеркальным отображениям устаревших баз данных В случае переноса соединений приложений с прежнего решения зеркального отображения базы данных, указывающего на атрибут партнера по обеспечению отработки отказа, можно продолжить использовать строку подключения зеркального отображения, если группа доступности настроена с помощью одной вторичной реплики. Вторичная реплика не может работать в режиме «только для чтения». Можно (но необязательно) указать исходное имя сервера-участника и имя партнера по обеспечению отработки отказа. Имейте в виду, что такое решение не рекомендуется как долгосрочное и неприменимо к развертыванию, рассматриваемому в этом техническом документе, поскольку для него требуются по крайней мере три реплики (одна первичная реплика доступности и две вторичные реплики). Прослушиватель группы доступности Для групп доступности можно задать имя прослушивателя группы доступности (атрибут на стороне сервера). Прослушиватель группы доступности — виртуальное сетевое имя (VNN), которое создается для использования с определенной группой доступности. Это имя связано с одним или несколькими TCP/IP-адресами и портами прослушивателя и используется для автоматического подключения к первичной реплике, где бы она ни находилась в этот момент. Виртуальное сетевое имя устраняет необходимость указывать атрибут партнера по обеспечению отработки отказа и допускает масштабированную топологию, где общее число расположений реплик доступности не превышает пяти. Например, если группа доступности выполняет отработку отказа на Узел1 с Узла2, то новые подключения к прослушивателю группы доступности автоматически подключаются к реплике, на которой в данный момент размещена первичная реплика. 15 Кроме того, прослушиватель группы доступности можно также использовать для автоматической маршрутизации действий «только для чтения» на вторичные реплики «только для чтения». Дополнительные сведения об этих функциях см. в разделе Настройка маршрутизации только для чтения для группы доступности (SQL Server). Поддержка соединения с несколькими подсетями Что касается других атрибутов соединения, связанных с группами доступности, то рекомендуется указывать в строках соединения для групп доступности атрибут MultiSubnetFailover как для односетевой, так и для многосетевой топологии, если они используют имя прослушивателя группы доступности. Если атрибут строки подключения включен, параметр соединения MultiSubnetFailover разрешает поддержку для соединений с несколькими подсетями и параллельно открывает TCP-сокеты для IP-адресов прослушивателя группы доступности. При использовании устаревших клиентских библиотек, которые не поддерживают атрибут MultiSubnetFailover, следует увеличить время ожидания входа клиента в строке подключения приложения, чтобы учитывать возможную задержку соединения с несколькими подсетями. Время ожидания должно быть больше среднего времени отработки отказа группы доступности на одну рабочую среду. Дополнительные сведения о поддержке клиентов см. в разделе Поддержка SQL Server Native Client для обеспечения высокого уровня доступности и аварийного восстановления. Построение решения на основе групп доступности В этом разделе рассматриваются шаги и рабочий процесс, выполняемые при создании группы доступности для решения высокого уровня локальной доступности и удаленного аварийного восстановления. В этом документе рассматриваются вопросы создания новой среды, сравнимой с топологией, показанной на рис. 4 ранее. Помните, что для этой конкретной схемы предполагается использование закрытого хранилища для каждого экземпляра SQL Server. Минимальные требования для SQL Server 2012 в Windows Server 2008 R2 с пакетом обновления 1 (SP1) или Windows Server 2008 с пакетом обновления 2 (SP2). Для следующих инструкций предполагается, что операционной системой узла сервера является Windows Server 2008 R2 с пакетом обновления 1 (SP1). В таблице 1 показаны шаги, необходимые для построения решения на основе групп доступности с целью обеспечения высокого уровня локальной доступности и удаленного аварийного восстановления. Несмотря на то что в этом разделе не рассматривается каждый шаг, цель раздела заключается в том, чтобы уточнить последовательность рабочего процесса для разных реализаций и участвующих ролей. При необходимости приводятся ссылки на техническую документацию. Шаги разбиты по ролям заданий, так как в большинстве крупных корпоративных сред определено разделение обязанностей между ролями администраторов сети, базы данных и Windows Server (или кластера). Важно правильно взаимодействовать и координировать действия ролей. 16 Шаг Администратор базы данных Администратор Windows Server \ кластера 1. Начните процесс с добавления функции отказоустойчивой кластеризации на два заново настроенных узла, расположенные в основном центре обработки данных, и на третий заново настроенный узел, расположенный во вторичном центре обработки данных. Дополнительные сведения об этом процессе см. в разделах Установка функции отказоустойчивой кластеризации и Основные сведения о требованиях для отказоустойчивых кластеров. Да — для координации действий по ролям Да 17 Администратор сети Шаг 2. Убедитесь, что учетная запись, которая будет использоваться для установки и настройки WSFC, является учетной записью домена. Эта учетная запись также должна иметь разрешение администратора на каждом из узлов кластера, а также разрешения Создание объектов компьютера и Чтение всех свойств свойства для контейнера, используемого для учетных записей компьютера домена. Другой способ — настроить учетные записи объекта Active Directory заблаговременно или использовать для установки учетную запись администратора домена. Дополнительные сведения о необходимых разрешениях и параметрах провизионирования, включая подробные инструкции, см. в статье Пошаговое руководство по отказоустойчивым кластерам. Настройка учетных записей в Active Directory. 18 Администратор базы данных Администратор Windows Server \ кластера Да Администратор сети Шаг 3. Выполните проверку кластера трех узлов сервера с помощью диспетчера отказоустойчивого кластера для обоих центров данных, которые будут добавлены в кластер WSFC. Поскольку рассматриваемая схема не разрешает использовать общее хранилище, тесты общего хранилища во время проверки не выполняются. После завершения проверки кластера, прежде чем создавать кластер WSFC, убедитесь, что отсутствуют какие-либо критические препятствия, выявленные ранее. Даже если, несмотря на предупреждение, разрешение на переход к следующему шагу все же получено, для обеспечения стабильной конфигурации важно узнать причину возникновения предупреждения. Дополнительные сведения, включая инструкции по выполнению проверочного теста, см. в разделе Проверка конфигурации отказоустойчивого кластера. 19 Администратор базы данных Администратор Windows Server \ кластера Администратор сети Да Да — для всех проблем, которые могут возникать в связи с обменом данными между узлами по сети Шаг 4. После завершения проверки для создания кластера WSFC из трех узлов используйте диспетчер отказоустойчивого кластера. Дополнительные сведения об этом процессе см. в разделе Создание нового отказоустойчивого кластера. Если предположить, что в кластере WSFC существует три узла, конфигурация режима кворума по умолчанию на этом этапе будет Большинство узлов. При необходимости позже можно изменить модель кворума на «Большинство узлов и общих папок» или добавить другой узел в качестве узла для голосования без установки SQL Server. 20 Администратор базы данных Администратор Windows Server \ кластера Администратор сети Да Да — для всех проблем, которые могут возникать в связи с обменом данными между узлами по сети Шаг 5. Чтобы узел центра обработки данных аварийного восстановления не смог повлиять на доступность узлов основного центра обработки данных, установите исправление KB 2494036 из раздела Доступно исправление, позволяющее настраивать узел кластера, не имеющего кворума голосов, в Windows Server 2008 и Windows Server 2008 R2. После установки исправления на каждом узле кластера WSFC следуйте инструкциям из раздела «Настройка голосов узлов» в этом документе и задайте параметру NodeWeight узла центра обработки данных аварийного восстановления в кластере WSFC значение «0» (нуль). Это означает, что голоса будут иметь только два узла в основном центре обработки данных и следящий сервер с общим доступом к файлам, который будет настроен при следующем шаге. Для этого рабочего процесса предполагается, что вместо дополнительного сервера для большинства узлов был выбран следящий сервер с общим доступом к файлам. Если вместо этого был выбран дополнительный сервер для обеспечения голоса, то к голосам кворума применимы прежние рекомендации. 21 Администратор базы данных Администратор Windows Server \ кластера Да Администратор сети Шаг 6. Поскольку третий узел располагается в отдельном центре обработки данных и больше не имеет голоса, следует изменить эту модель кворума на «Большинство узлов и общих папок». Создайте общую папку в основном центре обработки данных на узле сервера, который не будет участвовать в WSFC. Эта общая папка будет функционировать как общая папка следящего сервера. После создания общей папки следуйте инструкциям, приведенным ранее, и измените конфигурацию кворума на «Большинство узлов и общих папок». Прежде чем изменить конфигурацию, следует предоставить разрешения чтения и записи на общую папку следящего сервера учетной записи кластера WSFC. 22 Администратор базы данных Администратор Windows Server \ кластера Да Администратор сети Шаг Администратор базы данных 7. Установите автономный экземпляр SQL Server 2012 Enterprise на каждый из трех узлов WSFC. Каждый узел должен иметь доступ к своему локальному закрытому хранилищу для использования SQL Server. Да Для каждого узла в кластере WSFC установите ядро СУБД SQL Server 2012 Enterprise (вместе с другими дополнительными функциями рабочей среды), следуя тем же шагам, которые выполняются для установки автономного экземпляра SQL Server. Несмотря на то что это будет обычный автономный процесс, следует убедиться, что все устанавливаемые экземпляры SQL Server используют одну соответствующую данной службе сортировку, чтобы размещать реплики группы доступности (более того, все экземпляры должны иметь сортировку существующего зеркального отображения базы данных и среды доставки журналов). Также рекомендуется использовать одинаковые пути к файлам на каждом узле. 8. Включите функции групп доступности AlwaysOn для каждой службы SQL Server. Дополнительные сведения, включая подробные шаги по использованию диспетчера конфигурации SQL Server или Windows PowerShell, см. в разделе Включение и отключение групп доступности AlwaysOn. 23 Да Администратор Windows Server \ кластера Администратор сети Шаг Администратор базы данных 9. После того как все три экземпляра SQL Server настроены на поддержку групп доступности AlwaysOn, а базы данных, которые будут относиться к группе доступности, настроены на модель полного восстановления FULL, создайте резервные копии рабочих пользовательских баз данных из прежней топологии и восстановите их на узле основного центра обработки данных в кластере WSFC. Да Предполагается, что будет выполняться перенос одной или нескольких пользовательских баз данных на один экземпляр SQL Server в основном центре обработки данных. Второй узел в основном центре обработки данных будет использоваться как вторичная реплика синхронного режима. Также необходимо создать скрипт для других объектов SQL Server из прежней топологии, которые не содержатся в восстанавливаемых пользовательских базах данных, но от которых эти базы (например, имена входа SQL Server, связанные разрешения на уровне сервера и задания агента SQL Server) будут зависеть. Это сравнимо с процессом, выполняемым при выгрузке в скрипт зависимых объектов, находящихся вне зеркалируемой базы данных, для участия в партнерстве зеркальных отображений баз данных. Существует несколько методов передачи объектов базы данных между экземплярами SQL Server. Задача по переносу объектов SQL Server с помощью служб Integration Services — один из таких методов. 24 Администратор Windows Server \ кластера Администратор сети Шаг Администратор базы данных 10. Создайте группу доступности с помощью мастера SQL Server Management Studio (Использование нового мастера создания групп доступности), Transact-SQL или окна PowerShell. Да Дополнительные сведения о том, как использовать инструкции языка Transact-SQL или SQL Server PowerShell, см. в разделе Создание группы доступности (Transact-SQL) или Создание группы доступности (SQL Server PowerShell). 11. Создайте прослушивателя Да группы доступности (если он еще не был создан на предыдущем шаге). Прослушиватель группы доступности можно создать с помощью мастера SQL Server Management Studio, Transact-SQL или SQL Server PowerShell. Дополнительные сведения об использовании различных методов см. в разделе Создание или настройка прослушивателя группы доступности (SQL Server). Администратор Windows Server \ кластера Администратор сети Да — чтобы убедиться в том, что порт прослушивателя, назначенный для конечной точки группы доступности, открыт каждому экземпляруучастнику SQL Server Да — обеспечить соответствие параметров брандмауэра для выбранных IP-адресов Да — для координирования соображений по IP-адресам и портам Таблица 1. Построение решения на основе групп доступности с учетом роли задания Во время установки группы доступности см. описание конфигураций реплики в таблице 2 (конфигурации применимы к специфической схеме решения, которое рассматривается в этом документе). Имейте в виду, что в качестве реплик, доступных для чтения, можно также выбрать вторичные реплики. Это целесообразно, поскольку не оказывает влияния на общее решение на основе высокой доступности и аварийного восстановления. Вариант не был включен в таблицу. 25 Центр обработки данных Реплика Роль Режим доступности Режим отработки отказа Основной центр обработки данных Основной центр обработки данных Центр обработки данных аварийного восстановления Узел 1 Первичная Синхронная фиксация Авто Узел 2 Вторичная Синхронная фиксация Авто Узел 3 Вторичная Асинхронная фиксация (допускается только вторичная синхронная реплика, следует учитывать задержку в сети между двумя центрами обработки данных и ее влияние на производительность приложения) Вручную Таблица 2. Параметры реплики После выполнения шагов, описанных в таблице 1, в диспетчере отказоустойчивого кластера появится новая группа ресурсов для группы доступности. В этой группе ресурсов можно также найти ресурс прослушивателя группы доступности, связанные IP-адреса прослушивателя и ресурс группы доступности. Рис. 7 демонстрирует, как это может выглядеть в диспетчере отказоустойчивого кластера. Рис. 7. Диспетчер отказоустойчивого кластера Windows Server. Группа доступности для решения на основе высокой доступности и аварийного восстановления 26 Рекомендации по мониторингу При переходе с зеркального отображения базы данных и топологии путем доставки журналов на топологию решения на основе групп доступности потребуется изменить подход к слежению за топологией. Среди доступных методов и средств, используемых для слежения за инфраструктурой группы доступности, можно выделить следующие: — панель мониторинга групп доступности AlwaysOn в среде SQL Server Management Studio; сведения о состоянии обозревателя объектов; новые счетчики производительности на основе групп доступности; представления каталогов; динамические административные представления (DMV); сеанс расширенных событий, который отслеживает недавние исполнения инструкций на основе DDL-интерфейса AlwaysOn, проблемы возможности подключения кластера WSFC, события отработки отказа, изменения состояния и повторные события при блокировке. Панель мониторинга групп AlwaysOn — эффективный способ быстро оценить работоспособность определенной группы доступности. На панели мониторинга можно определить расположение первичного экземпляра, режим отработки отказа реплик, состояние синхронизации реплик и готовность разных реплик выполнить отработку отказа (то есть риск потери данных для определенной реплики). Можно также открыть данные сеанса расширенных событий работоспособности AlwaysOn непосредственно на панели мониторинга, чтобы узнать о последних действиях в группе доступности, изменениях состояния и событиях. Также можно создать предупреждения агента SQL Server и ответы заданий, основанные на пороговых значениях счетчиков производительности и изменениях состояния группы доступности. Дополнительные сведения о мониторинге среды групп доступности см. в разделе Мониторинг групп доступности. Восстановление по журналу после сбоя В этом разделе приводится подробное описание рабочего процесса, который необходимо выполнить в случае сбоя узлов в кластере WSFC в центре обработки данных. Для этого сценария предполагается, что узлы в центре обработки данных недоступны. Для этого сценария также предполагается, что единственный доступный узел WSFC находится во вторичном центре обработки данных аварийного восстановления. Обратите внимание, что в случае реального происшествия могут иметь место несколько видов сбоев. В этом примере в результате сбоя становятся недоступными узлы центра обработки данных. Как упоминалось ранее, в этом примере также предполагается, что оставшиеся узлы не имеют кворума голосов и что узлы с правом голоса располагались в основном центре обработки данных (см. рис. 4). 27 Чтобы восстановить группу доступности в случае сбоя центра обработки данных, выполните следующие шаги. 1. Диспетчер отказоустойчивого кластера, запущенный в узле аварийного восстановления, вряд ли сможет сразу представить полезные сведения о состоянии WSFC, так как кластер в кворуме отсутствует. Кроме того, на панели мониторинга группы AlwaysOn для узла аварийного восстановления, вероятнее всего, будет указано, что режим отработки отказа «неизвестен», а реплики доступности находятся в «состоянии разрешения» (вероятнее всего, во время сбоя будет отображаться только состояние локальной реплики). Базы данных доступности могут быть невидимыми в представлении в виде дерева обозревателя объектов SQL Server Management Studio для узла аварийного восстановления (примерное представление см. на рис. 8). Рис. 8. Второй центр обработки данных во время сбоя в основном центре обработки данных 2. В случае если состояние центра обработки данных неизвестно, а службу необходимо восстановить из вторичного центра обработки данных аварийного восстановления, единственная возможность уложиться в заданное время восстановления — это запустить кластер Windows после принудительного создания кворума для узла центра обработки данных аварийного восстановления. Принудительный кворум следует использовать только как последнюю возможность, когда ожидается, что центр обработки данных может оставаться недоступным длительное время. После принудительного создания кворума убедитесь, что узлы в центре обработки данных не формируют собственный кворум. В следующем примере Windows PowerShell создает принудительный кворум для узла в центре обработки данных аварийного восстановления. Сначала убедитесь, что служба кластеров уже не запущена на узле аварийного восстановления. Stop-ClusterNode –Name "EMU-SQL3" 28 Затем запустите службу кластеров путем принудительного создания кворума. Start-ClusterNode –Name "EMU-SQL3" –FixQuorum Дополнительные сведения о принудительном кворуме см. в разделе Принудительный запуск кластера WSFC без кворума 3. В это время модель кворума кластера по-прежнему представляет собой большинство узлов и общих папок. Get-ClusterQuorum Cluster ------EMU-AGClstr QuorumResource -------------File Share Witness QuorumType ---------NodeAndFileShareMajority Так как кластер выполняется на узле аварийного восстановления в состоянии принудительного кворума, следует настроить модель кворума и голосования узлов соответствующим образом. Поскольку только один узел находится в центре обработки данных аварийного восстановления (для этого примера топологии), измените модель кворума на «Большинство узлов» (в данном случае это будет большинство одного узла) и задайте один голос узлу аварийного восстановления и нуль голосов узлам основного центра обработки данных. Чтобы задать модель кворума на основе большинства узлов, введите следующую команду. Set-ClusterQuorum -NodeMajority При изменении модели кворума голосование узлов изменится на состояние по умолчанию (по одному голосу на каждый узел). Теперь измените голосование узлов. (Get-ClusterNode "EMU-SQL3").NodeWeight=1 (Get-ClusterNode "EMU-SQL1").NodeWeight=0 (Get-ClusterNode "EMU-SQL2").NodeWeight=0 В этот момент в среде имеется один узел и один голос и, следовательно, только одна точка ошибки. Прежде чем продолжить, убедитесь, что голосование узлов было изменено надлежащим образом с помощью следующей команды Windows PowerShell. Get-ClusterNode | fl NodeName, NodeWeight При смене владельцев группы кластеров WSFC так, чтобы они относились только к основному центру обработки данных, следует также сменить владельцев группы кластеров WSFC и включить узел аварийного восстановления. 29 4. Активируйте группу доступности в сети на экземпляре SQL Server узла аварийного восстановления. Внимание! Если реплика настроена в асинхронном режиме, восстановление службы может привести к потере данных для всех записей неотправленного журнала. Перед восстановлением службы следует оценить последствия этого действия. Дополнительные сведения о рисках, связанных с восстановлением службы в состояние реплики, настроенной в асинхронном режиме, см. в разделе Выполнение принудительной отработки отказа для группы доступности. Если риск потери данных не так важен по сравнению с необходимостью уложиться в заданное время восстановления и восстановить службы в центре обработки данных, выполните следующую инструкцию Transact-SQL в экземпляре SQL Server аварийного восстановления, чтобы принудительно отработать отказ (в данном примере EMU-AG1 — имя группы доступности). ALTER AVAILABILITY GROUP [EMU-AG1] FORCE_FAILOVER_ALLOW_DATA_LOSS; В этот момент базы данных в группе доступности станут доступны. Необходимо также убедиться, что все входящие соединения приложения отключены от прежней первичной реплики или полностью отключены. Новые соединения с прослушивателем группы доступности (который должен снова работать) должны автоматически перенаправляться на экземпляр аварийного восстановления. Кроме того, чтобы избежать ситуации «дробления ресурсов», необходимо также убедиться, что приложения больше не пытаются установить соединение с центром обработки данных. Также обратите внимание, что даже после повторной установки кворума в центре данных аварийного восстановления по-прежнему будут появляться разные предупреждения о недоступности узлов центра обработки данных в среде SQL Server Management Studio. На рис. 9 показано, как это может выглядеть, включая представление обозревателя объектов и панель мониторинга группы AlwaysOn. 30 Рис. 9. SQL Server Management Studio после принудительной отработки отказа Как упоминалось ранее, в больших корпоративных средах, как правило, предусмотрено разделение обязанностей между ролями администраторов сети, баз данных, Windows Server (или кластера). На таблица 3 показана общая картина рабочего процесса аварийного восстановления, описанного ранее, с указанием того, какие области относятся к определенным корпоративным ролям с точки зрения планирования. 31 Шаг Администратор базы данных Проверка текущего состояние основного центра обработки данных и остальных узлов WSFC аварийного восстановления с координацией усилия. Принудительное обслуживание кворума на узле аварийного восстановления. Удалите голоса с основных узлов и задайте голос узлу аварийного восстановления. Выполните принудительную отработку отказа группы доступности на экземпляр аварийного восстановления SQL Server. Да Администратор Windows Server \ кластера Да Да Да Да Таблица 3. Аварийное восстановление по журналу по ролям заданий 32 Администратор сети Да Возврат к использованию основного центра обработки данных Для этого сценария предполагается, что восстановленная служба на сайте аварийного восстановления нужна только для запуска рабочей нагрузки во время сбоя. Рекомендуется переместить рабочую нагрузку обратно на основной сайт, как только он вновь сможет обслуживать рабочую нагрузку. Ситуация отказа может иметь несколько разновидностей и соответственно вариантов восстановления. В описанном здесь сценарии предполагается аварийная ситуация, когда серверы основного центра обработки данных недоступны в течение длительного периода времени. После устранения проблем в основном центре обработки данных все узлы в основном центре данных снова включаются и пытаются подключиться к WSFC. После восстановления соединения с кластером WSFC, на котором запущены службы кластеров, в силу вступают веса узлов, назначенные на узле аварийного восстановления. В этом сценарии также предполагается, что первоначальные установки SQL Server и связанные базы данных остаются неизменными. На этом этапе необходимо решить, следует сохранить данные (то есть изменения данных, которые были сделаны в исходной первичной реплике, но не были отправлены в реплику аварийного восстановления непосредственно перед сбоем) или же продолжить полное восстановление всех сеансов реплик. Реплики на узлах, давших сбой, будут находиться в состоянии «синхронизация отсутствует» после принудительной отработки отказа, а реплика аварийного восстановления — в состоянии «синхронизация», как показано на рис. 10. 33 Рис. 10. Состояние баз данных в репликах перед возвратом системы в основной центр обработки данных Один из методов восстановления данных из исходной первичной реплики — создать моментальный снимок базы данных в приостановленной базе данных-получателе (то есть в исходном первичном ресурсе) с целью извлечения соответствующих данных, необходимых для повторной синхронизации с версией реплики аварийного восстановления баз данных доступности. В следующем примере показано, как создать моментальный снимок базы данных в базе данных доступности с состоянием «не синхронизируется». -- Создание моментального снимка базы данных CREATE DATABASE AppDB_A1 ON (NAME = AppDB, FILENAME = 'S:\Data\AppDB_A1.ss' ) AS SNAPSHOT OF AppDB; GO Поскольку в изначальном сценарии использовался асинхронный режим аварийного восстановления баз данных, предполагается, что процесс восстановления может сопровождаться потерей некоторых данных. Для следующего набора шагов предполагается, что служба будет восстановлена с использованием существующих первичных реплик центров обработки данных. 1. Запустите управляемую миграцию обратно в центр обработки данных, изменив модель кворума соответствующим образом (в данном случае необходимо переключиться на «Большинство узлов и общих папок»), и после этого измените распределение голосов. 2. Убедитесь, что экземпляры основного центра обработки данных SQL Server запущены, после чего на каждом экземпляре SQL Server в основном центре обработки данных выполните следующую инструкцию Transact-SQL из контекста базы данных master, чтобы возобновить работу каждой базы данных, участвующей в группе доступности. USE [master] GO ALTER DATABASE AppDB SET HADR RESUME; GO ALTER DATABASE ConfigDB SET HADR RESUME; GO ALTER DATABASE SecurityDB SET HADR RESUME; GO 34 3. Для синхронизации до отработки отказа измените группу доступности для аварийного восстановления, временно переключив ее на режим доступности с синхронной фиксацией. Команда Transact-SQL выглядит следующим образом (при выполнении на текущей первичной реплике в центре обработки данных аварийного восстановления, если EMU-AG1 — группа доступности и EMU-SQL3 — реплика ЦОД аварийного восстановления из примера). В идеальном случае параметр синхронной фиксации следует устанавливать во время низкой нагрузки от приложений, чтобы уменьшить влияние задержки транзакций на пользователей. USE [master] GO ALTER AVAILABILITY GROUP [EMU-AG1] MODIFY REPLICA ON N'EMU-SQL3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT); GO 4. Проверьте состояние синхронизации между двумя местоположениями (до перехода к следующему шагу все реплики должны быть в состоянии «исправно», это значит, что обе реплики с синхронной фиксацией синхронизированы). SELECT role_desc, synchronization_health_desc FROM sys.dm_hadr_availability_replica_states; 5. Выполните отработку отказа групп доступности с узла центра обработки данных аварийного восстановления на узел основного центра обработки данных (то есть подключитесь и выполните следующий скрипт на узле основного центра обработки данных, который станет новой первичной репликой). ALTER AVAILABILITY GROUP [EMU-AG1] FAILOVER; 6. Чтобы соответствовать изначальному развертыванию, измените узел реплики аварийного восстановления обратно на асинхронную фиксацию. Выполните следующую инструкцию Transact-SQL в новой первичной реплике, в которой EMU-SQL3 — имя реплики аварийного восстановления, а EMU-AG1 — имя группы доступности. USE [master] GO ALTER AVAILABILITY GROUP [EMU-AG1] MODIFY REPLICA ON N'EMU-SQL3' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT); GO 7. Удалите голос кворума из узла WSFC в центре обработки данных аварийного восстановления. 35 В следующей таблице повторно приведен описанный выше рабочий процесс аварийного восстановления и указывается, какие из его областей обычно относятся к различным корпоративным ролям с точки зрения планирования. Шаг 1. После восстановления службы центра обработки данных измените модель кворума соответствующим образом. Затем задайте обратно голоса кворума узлам основного центра обработки данных. 2. Возобновление сеансов доступности баз данных на каждой из вторичных реплик. 3. Изменение реплики аварийного восстановления на синхронную фиксацию. 4. Проверка состояния синхронизации между двумя расположениями (до перехода к следующему шагу все реплики должны находиться в состоянии «исправно»). 5. Отработка отказа на реплику в центре обработки данных. 6. Возврат реплики аварийного восстановления к асинхронной фиксации (в соответствии с исходной конфигурацией). 7. Удаление голосов кворума с узла в центре обработки данных аварийного восстановления. Администратор Администратор базы данных Windows Server \ кластера Да Да Да Да Да Да Да Таблица 4. Возврат к использованию основного центра обработки данных 36 Администратор сети Заключение SQL Server 2012 AlwaysOn предоставляет несколько вариантов построения решения на основе высокого уровня доступности и аварийного восстановления решения для приложений. В техническом документе приводится описание решения, использующего группы доступности для обеспечения высокой доступности и аварийного восстановления. Это решение основывается исключительно на закрытом хранилище, поскольку каждый экземпляр SQL Server в топологии имеет собственную копию данных, при этом нет необходимости открывать хранилище для общего доступа. Это решение может заменить прежние топологии, которые используют зеркальное отображение базы данных и доставку журналов. Успешное развертывание такого решения на основе высокой доступности и аварийного восстановления требует не только участия команды администраторов баз данных, но и тесного сотрудничества между командой администраторов баз данных, командой администраторов Windows Server и командой специалистов по сетям в ИТ-организации. Навыки, которыми обладают смежные дисциплины, будут крайне полезны при развертывании решения высокой доступности или аварийного восстановления. Ссылки 37 Шаблоны разработки высокого уровня доступности и аварийного восстановления SQL Server 2012 AlwaysOn (http://go.microsoft.com/fwlink/?LinkId=255048) Руководство по решениям высокой доступности и аварийного восстановления Microsoft SQL Server AlwaysOn (http://msdn.microsoft.com/library/hh781257.aspx) Обзор групп доступности AlwaysOn (http://technet.microsoft.com/library/ff877884(v=SQL.110).aspx) Предварительные требования, ограничения и рекомендации для групп доступности AlwaysOn (http://technet.microsoft.com/library/ff878487(v=sql.110).aspx) Пошаговое руководство по отказоустойчивым кластерам. Настройка кворума в отказоустойчивом кластере (http://technet.microsoft.com/library/cc770620(v=WS.10).aspx) Исправление Windows Server для голосов кворума (http://support.microsoft.com/kb/2494036) Windows PowerShell (http://technet.microsoft.com/library/bb978526) Сопоставление команд Cluster.exe с командлетами Windows PowerShell для отказоустойчивых кластеров (http://technet.microsoft.com/library/ee619744(v=WS.10).aspx) Руководство по выявлению проблем Windows PowerShell (http://social.technet.microsoft.com/wiki/contents/articles/183.windows-powershell-survivalguide-en-us.aspx) Командлеты отказоустойчивого кластера в Windows PowerShell (http://technet.microsoft.com/library/ee461009.aspx) SQL Server PowerShell (http://msdn.microsoft.com/ru-ru/library/hh245198.aspx) Приложение А. Пример групп доступности на основе высокой доступности и аварийного восстановления с использованием трех центров обработки данных Архитектура, рассмотренная в этом техническом документе, основывается на двух центрах обработки данных, что является распространенной топологией развертывания. Однако иногда некоторые клиенты используют третий центр обработки данных для развертывания. В большинстве случаев основным мотивом для такого решения является потребность обеспечить автоматическую отработку отказа группы доступности для основного ЦОД и ЦОД аварийного восстановления. Один из способов реализации такого подхода — развернуть две реплики в двух центрах обработки данных, а следящий сервер с общим доступом к файлам — в третьем центре обработки данных, как показано на рис. 11. Третий центр обработки данных ГОЛОСУЕТ Основной центр обработки данных SQL Server Общая папка Отказоустойчивый кластер Windows Server Аварийное восстановление Центр обработки данных ГОЛОСУЕТ ГОЛОСУЕТ Основной SQL Server Вторичный Синхронная Группа доступности Рис. 11. Решение групп доступности на основе HA/DR с использованием трех центров обработки данных Дополнительные сведения см. на следующих страницах: http://www.microsoft.com/sqlserver/. Веб-сайт SQL Server http://technet.microsoft.com/en-us/sqlserver/. Технический центр SQL Server http://msdn.microsoft.com/en-us/sqlserver/. SQL Server DevCenter 38 Помогла ли вам эта статья? Пожалуйста, оставьте свой отзыв. Оцените материал по шкале от 1 (плохо) до 5 (отлично) и укажите причины выставления своей оценки. Например: Вы высоко оценили этот документ из-за наличия подходящих примеров, четких снимков экрана, ясного изложения или по какой-либо другой причине? Вы низко оценили степень полезности этого документа из-за плохих примеров, нечетких снимков экрана и путаного изложения? Ваш отзыв поможет нам повысить качество выпускаемых нами технических документов. Отправить отзыв 39
