Share via

Настройка SQL 2012 AlwaysOn Availability Groups для Project Server 2013

Пока мы ждем нового релиза SP1, расскажу о своем опыте настройки новой возможности SQL 2012, имя которой AlwaysOn Availability Groups. Процедура с небольшими различиями схожа для SharePoint 2013 и ферм с установленным поверх Project Server 2013. Об этих различиях я расскажу позже.

Исходная инфраструктура: 2 х SQL 2012 (экземпляры Server1\AlwaysOn1 и Server2\AlwaysOn2), 2 х SharePoint & Project Server 2013. Цель простая и часто встречающаяся в требованиях: получить ферму, обеспечив высокую доступность данных.

Общий план действий:

  1. Объединить серверы SQL в WSFC кластер, как того требуют условия https://msdn.microsoft.com/en-us/library/ff878487.aspx#PrerequisitesForAGs
  2. Создать ферму из 1-го сервера на одной из реплик SQL
  3. Создать группу доступности и добавить в нее базы данных
  4. Добавить listener для группы доступности и настроить автоматическую отказоустойчивость
  5. Указать listener в качестве сервера баз данных на серверах фермы, добавить серверы в ферму

В ходе настройки я использовал следующие учетные записи:

  • domain\sqladmin - УЗ служб SQL. Эту УЗ я также использовал для создания WSFC кластера
  • domain\farmadmin - УЗ установки и настройки SharePoint/Project Server
  • domain\farmsvc - УЗ запуска службы таймеров SharePoint
  • domain\svcpool - УЗ приложений-служб SharePoint
  • domain\webpool - УЗ WEB приложений

Подробнее реализация описана ниже.

Создание WSFC кластера

Основные вехи данного этапа:

  1. Установка возможности "Failover Clustering" на серверы SQL
  2. Создание в контейнере объекта типа "Компьютер" и назначение IP адреса будущему кластеру

В целом задача не сложная и подробно описана здесь: https://technet.microsoft.com/en-us/library/dn505754.aspx.

Помните, что при создании кластера учетной записи (в моем случае domain\sqladmin) потребуются права "Create computer objects" на контейнер, а также "Read all properties" (данное разрешение есть по умолчанию у любого пользователя домена, если не настроено иное). Если учетной записи не могут быть предоставлены такие разрешения, то попросите администратора создать объект в контейнере вручную, затем отключить его ("Disable Account") и предоставить вашей учетной записи полные права на этот конкретный объект (https://technet.microsoft.com/en-us/library/dn466519.aspx). После данных манипуляций вы сможете успешно создать WSFC кластер с помощью мастера.

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

Создание фермы на одной из реплик SQL

Основные вехи данного этапа:

  1. Создать псевдоним сервера SQL с помощью cliconfg на одном из серверов фермы
  2. Создать ферму, добавить необходимые приложения-службы, создать WEB приложения и коллекцию PWA

С процессом создания фермы с помощью PSConfig или мастера конфигурации продуктов SharePoint, думаю, знаком каждый, поэтому детально данный этап описывать не буду. Уточню только шаг с созданием псевдонима: на данном шаге еще не настроен функционал AlwaysOn и нет listener-а, поэтому в псевдониме указывается один из экземпляров SQL (в моем случае я указал Server1\AlwaysOn1). Позже этот псевдоним будет отредактирован.

Создание группы доступности и добавление в нее баз данных

Основные вехи данного этапа:

  1. Перенести базы на вторую реплику SQL
  2. Создать группу доступности
  3. Добавить базы в группу доступности

Прежде чем приступить к созданию группы доступности, необходимо на серверах SQL включить возможность "AlwaysOn High Availability". Это можно сделать разными способами. Например, с помощью консоли "SQL Server Configuration Manager":

Имя WSFC кластера подставится автоматически. Если он не создан, включение данной возможности будет не доступно.

Вторым важным шагом подготовки является остановка взаимодействия фермы с сервером SQL. Для этого необходимо остановить IIS и службу таймеров SharePoint.

И, наконец, третье условие успешного создания группы и синхронизации баз между репликами - открытие порта TCP 5022 на серверах SQL. Данный порт используется репликами для синхронизации и взаимодействия в рамках групп доступности.

Перенос баз на вторую реплику SQL

Основные вехи данного этапа:

  1. Создать полные резервные копии баз данных
  2. Перенести копии на вторую реплику и восстановить с параметром "NORECOVERY"

Если используется "Full" модель восстановления баз, а также одинаковые пути расположения файлов (по умолчанию C:\Program Files\Microsoft SQL Server\MSSQL11.InstanceName\MSSQL\DATA), то мастер создания группы доступности автоматически перенесет базы с одной реплики на другую. Однако условия могут быть разные, да и в общем не помешает освоить "ручной" способ синхронизации. Для переноса баз необходимо создать их полную резервную копию на основной реплике, затем перенести bak файлы на вторую реплику и восстановить с настройками по умолчанию, кроме одной - состояние должно быть "Restore with norecovery":

Иначе синхронизация баз будет не возможна: https://technet.microsoft.com/en-us/library/ff878349.aspx. После переноса баз данных в зависимости от их количества вы получите вот такую картину:

Создание группы доступности и добавление в нее баз для последующей синхронизации

Наиболее простой способ - использовать мастер "New Availability Group Wizard…”. После указания имени группы будет предложено выбрать базы, которые необходимо добавить в группу:

На следующем шаге необходимо добавить вторую реплику и указать тип синхронизации. В случае с Project Server 2013 "Synchronous Commit" является обязательным требованием (https://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

  • Last updated on