Пока мы ждем нового релиза SP1, расскажу о своем опыте настройки новой возможности SQL 2012, имя которой AlwaysOn Availability Groups. Процедура с небольшими различиями схожа для SharePoint 2013 и ферм с установленным поверх Project Server 2013. Об этих различиях я расскажу позже.
Исходная инфраструктура: 2 х SQL 2012 (экземпляры Server1\AlwaysOn1 и Server2\AlwaysOn2), 2 х SharePoint & Project Server 2013. Цель простая и часто встречающаяся в требованиях: получить ферму, обеспечив высокую доступность данных.
Общий план действий:
- Объединить серверы SQL в WSFC кластер, как того требуют условия http://msdn.microsoft.com/en-us/library/ff878487.aspx#PrerequisitesForAGs
- Создать ферму из 1-го сервера на одной из реплик SQL
- Создать группу доступности и добавить в нее базы данных
- Добавить listener для группы доступности и настроить автоматическую отказоустойчивость
- Указать listener в качестве сервера баз данных на серверах фермы, добавить серверы в ферму
В ходе настройки я использовал следующие учетные записи:
- domain\sqladmin - УЗ служб SQL. Эту УЗ я также использовал для создания WSFC кластера
- domain\farmadmin - УЗ установки и настройки SharePoint/Project Server
- domain\farmsvc - УЗ запуска службы таймеров SharePoint
- domain\svcpool - УЗ приложений-служб SharePoint
- domain\webpool - УЗ WEB приложений
Подробнее реализация описана ниже.
Создание WSFC кластера
Основные вехи данного этапа:
- Установка возможности "Failover Clustering" на серверы SQL
- Создание в контейнере объекта типа "Компьютер" и назначение IP адреса будущему кластеру
В целом задача не сложная и подробно описана здесь: http://technet.microsoft.com/en-us/library/dn505754.aspx.
Помните, что при создании кластера учетной записи (в моем случае domain\sqladmin) потребуются права "Create computer objects" на контейнер, а также "Read all properties" (данное разрешение есть по умолчанию у любого пользователя домена, если не настроено иное). Если учетной записи не могут быть предоставлены такие разрешения, то попросите администратора создать объект в контейнере вручную, затем отключить его ("Disable Account") и предоставить вашей учетной записи полные права на этот конкретный объект (http://technet.microsoft.com/en-us/library/dn466519.aspx). После данных манипуляций вы сможете успешно создать WSFC кластер с помощью мастера.
Помимо этого, чтобы в будущем не испытывать трудностей с сетевым взаимодействием SQL серверов, для именованных экземпляров SQL лучше назначить статический порт и его добавить в исключения на всех серверах SQL.
Создание фермы на одной из реплик SQL
Основные вехи данного этапа:
- Создать псевдоним сервера SQL с помощью cliconfg на одном из серверов фермы
- Создать ферму, добавить необходимые приложения-службы, создать WEB приложения и коллекцию PWA
С процессом создания фермы с помощью PSConfig или мастера конфигурации продуктов SharePoint, думаю, знаком каждый, поэтому детально данный этап описывать не буду. Уточню только шаг с созданием псевдонима: на данном шаге еще не настроен функционал AlwaysOn и нет listener-а, поэтому в псевдониме указывается один из экземпляров SQL (в моем случае я указал Server1\AlwaysOn1). Позже этот псевдоним будет отредактирован.
Создание группы доступности и добавление в нее баз данных
Основные вехи данного этапа:
- Перенести базы на вторую реплику SQL
- Создать группу доступности
- Добавить базы в группу доступности
Прежде чем приступить к созданию группы доступности, необходимо на серверах SQL включить возможность "AlwaysOn High Availability". Это можно сделать разными способами. Например, с помощью консоли "SQL Server Configuration Manager":
Имя WSFC кластера подставится автоматически. Если он не создан, включение данной возможности будет не доступно.
Вторым важным шагом подготовки является остановка взаимодействия фермы с сервером SQL. Для этого необходимо остановить IIS и службу таймеров SharePoint.
И, наконец, третье условие успешного создания группы и синхронизации баз между репликами - открытие порта TCP 5022 на серверах SQL. Данный порт используется репликами для синхронизации и взаимодействия в рамках групп доступности.
Перенос баз на вторую реплику SQL
Основные вехи данного этапа:
- Создать полные резервные копии баз данных
- Перенести копии на вторую реплику и восстановить с параметром "NORECOVERY"
Если используется "Full" модель восстановления баз, а также одинаковые пути расположения файлов (по умолчанию C:\Program Files\Microsoft SQL Server\MSSQL11.InstanceName\MSSQL\DATA), то мастер создания группы доступности автоматически перенесет базы с одной реплики на другую. Однако условия могут быть разные, да и в общем не помешает освоить "ручной" способ синхронизации. Для переноса баз необходимо создать их полную резервную копию на основной реплике, затем перенести bak файлы на вторую реплику и восстановить с настройками по умолчанию, кроме одной - состояние должно быть "Restore with norecovery":
Иначе синхронизация баз будет не возможна: http://technet.microsoft.com/en-us/library/ff878349.aspx. После переноса баз данных в зависимости от их количества вы получите вот такую картину:
Создание группы доступности и добавление в нее баз для последующей синхронизации
Наиболее простой способ - использовать мастер "New Availability Group Wizard…”. После указания имени группы будет предложено выбрать базы, которые необходимо добавить в группу:
На следующем шаге необходимо добавить вторую реплику и указать тип синхронизации. В случае с Project Server 2013 "Synchronous Commit" является обязательным требованием (http://technet.microsoft.com/en-us/library/jj841106.aspx#SAppDbsSPS). Но в общем случае для разных компонентов SharePoint настройка данного параметра может отличаться. Дополнительно имеет смысл включить "Automatic Failover", чтобы при отключение одной из реплик переключение на вторую происходило автоматически:
Так как базы были перенесены вручную, на следующем шаге необходимо выбрать опцию "Join only":
На этапе проверки выбранной конфигурации могут появиться предупреждения, например, о том, что нет listener-а. Это нормальное поведение, можно продолжать создание группы. Если все настроено верно, то в конце можно увидеть вот такую картину:
Группа создана, базы добавлены в группу и успешно синхронизированы между репликами:
В дальнейшем добавлять базы в группу можно с помощью мастера "Add database...".
Важно: помните, что синхронизация баз не означает синхронизацию логинов. А значит после переноса баз и создания группы доступности на второй реплике SQL необходимо создать все логины, которые выполняют те или иные функции в ферме SharePoint/Project Server 2013, и назначить им соответствующие роли (в моем случае это domain\farmadmin, domain\farmsvc, domain\svcpool, domain\webpool). Сопоставление логинов с базами переносится вместе с самими базами.
Добавление listener-а и настройка псевдонимов
Основной этап настройки AlwaysOn Availability Groups завершен. Осталось создать listener и указать его в псевдониме SQL для серверов фермы. Аналогично добавлению баз в группу создается listener с помощью мастера "Add listener...". При создании необходимо указать имя, порт и IP адрес (данный IP адрес отличен от IP адреса WSFC кластера и должен быть согласован с администраторами, чтобы в будущем не возникало конфликтов адресов):
После создания можно проверить отклик listener-а с помощью ping-а.
На завершающем этапе необходимо добавить listener в псевдонимы сервера фермы, настроенного ранее, а также сервера, еще не добавленного в ферму:
Теперь осталось запустить IIS и службу таймера SharePoint. Готово!
Ну а как добавить еще один сервер в ферму вы разберетесь сами! :)
Если появятся вопросы - буду рад помочь!
Артём Хлобыстин - Premier Field Engineer II, EMEA Technical Lead
