Установка и базовая настройка SharePoint Server 2013 SP1 на Windows Server 2012 R2 (в топологии Two-tier farm). Часть 1 - Подготовка отдельного кластерного экземпляра SQL Server 2012 SP1 для баз данных SharePoint Server

Начинаем цикл заметок описывающих процесс установки и базовой настройки SharePoint Server 2013 на Windows Server 2012 R2 в топологии Two-tier farm. Этот цикл не рассчитан на какой-то “дип-драйв” в технологии SharePoint и не может претендовать на какую-то полноту и исключительность, и уж тем более не способен заменить собой официальную документацию по продукту. Его можно позиционировать скорее как упрощённый визуализированный набор инструкций и тезисов по основным этапам установки часто-используемых компонент SharePoint.

Поддержка Windows Server 2012 R2 была анонсирована с выходом Service Pack 1 для SharePoint 2013. Информацию об этом можно найти в заметках SharePoint Server 2013 Service Pack 1 now available и Office Updates - Announcing availability of slipstreamed Office 2013 and SharePoint Server 2013 with SP1

Примеры вариантов топологии SharePoint 2013 можно найти например в постере Traditional Topologies for SharePoint 2013 по ссылке Technical diagrams for SharePoint 2013. Мы рассмотрим установку SharePoint Server 2013 SP1 Standard в топологии Two-tier farm (single-server farm), то есть когда все веб-службы и приложения SharePoint расположены на одном сервере, а базы данных на втором. В таком варианте топологии в перспективе мы можем расширить ферму SharePoint дополнительными Web Front-End (WFE) серверами в случае возникновения такой необходимости.

В качестве сервера БД в нашем случае будет использоваться двух-узловой кластер с SQL Server 2012 Standard, на котором в процессе нашего описания будет создан отдельный экземпляр SQL Server специально под нужды SharePoint Server. Для задач сервера веб-приложений SharePoint развёрнута отдельная виртуальная машина на базе Windows Server 2012 R2 Standard.

В этой заметке будет рассмотрен процесс подготовки отдельного высоко-доступного экземпляра SQL Server для последующего развертывания в него баз данных SharePoint Server 2013. В нашем примере кластер SQL Server фактически уже функционирует, поэтому мы пропустим шаги предварительной настройки узлов кластера Failover Cluster и рассмотрим лишь последовательность действий по добавлению нового экземпляра SQL Server в действующий кластер в следующем порядке:

1. Подготовка инфраструктуры для создания нового высоко-доступного экземпляра SQL Server
2. Создание нового кластера SQL Server на первом узле (KOM-AD01-SQL01)
3. Добавление в кластер SQL Server второго узла (KOM-AD01-SQL02)
4. Обновление узлов кластера SQL Server до последнего Cumulative Update
5. Настройка для экземпляра SQL Server статического порта TCP

 

1. Подготавливаем инфраструктуру для создания нового высоко-доступного экземпляра SQL Server

В отдельном OU в домене создадим учетную запись компьютера с именем, которое мы планируем использовать в дальнейшем для создания кластерного ресурса SQL Server. Эта учетная запись будет использоваться в качестве Cluster Name Object (CNO). После создания учетной записи нам необходимо будет её выключить, чтобы служба кластеризации смогла использовать этот объект при его первоначальной настройке. В нашем случае для экземпляра кластера Failover Cluster уже используется учетная запись KOM-AD01-SQLFC, и мы создадим и отключим учетную запись KOM-AD01-SQLCL1 – для будущей кластеризованной службы SQL Server, которая будет работать на базе этого кластера.

В свойствах безопасности учетной записи KOM-AD01-SQLCL1 добавляем полные разрешения для учетной записи KOM-AD01-SQLFC, чтобы служба кластера могла беспрепятственно сконфигурировать CNO службы SQL Server. Доступ предоставим как на сам объект, так и на его дочерние объекты.

 

Далее создадим в домене служебную учетную запись пользователя (s-KOM-AD01-SQLSP-Svc), от имени которой будут запускаться службы SQL Server на узлах кластера SQL Server. Для этой учетной записи в домене добавим разрешение чтения/записи собственного атрибута servicePrincipalName для возможности динамической регистрации SPN (Service Principal Name) службой SQL Server.

 

2. Создаем новый кластер SQL Server на первом узле (KOM-AD01-SQL01)

Аппаратные и программные требования для развертывания SharePoint 2013 можно найти в документе Hardware and software requirements for SharePoint 2013. Сервера кластера SQL Server в нашем примере работают на базе Windows Server 2012, и поэтому согласно списку требований нам необходимо проверить наличие на этих серверах установленного .NET Framework 4.5 и обновления KB2765317. Однако я не стал устанавливать данное обновление на сервера БД, так как оно по сути касается работы IIS, который к работе SQL Server в контексте нашей задачи отношения не имеет.

Запускаем на первом (активном) узле кластера программу установки SQL Server Installation Center и выбираем пункт создания нового кластера New SQL Server failover cluster installation

Запустится мастер установки который сначала проверит наличие минимальных требований перед началом установки

Затем будет выполнен ряд проверок на наличие возможности создания нового высоко-доступного экземпляра SQL Server 

Далее вводим ключ продукта, принимаем лицензионное соглашение и переходим к экрану выбора устанавливаемых компонент SQL Server. Отмечаем Database Engine Services. Включенные в его состав под-компоненты в случае установки кластерной конфигурации отключить нельзя.

Также убедимся в том, что отмечены компоненты Management Tools – Basic. В нашем случае они недоступны для редактирования, так как уже были установлены ранее при развертывании другого экземпляра SQL Server

Далее будет выполнена очередная проверка…

 

На следующем шаге Instance Configuration задаем сетевое имя кластерного объекта в Windows Failover Cluster, которое будет использоваться для идентификации кластерной роли -  KOM-AD01-SQLCL1. Здесь же определяем имя для экземпляра (instance) SQL Server, в нашем случае это будет SHAREPOINT. Корневой каталог установки оставляем по-умолчанию (этот каталог должен быть одинаковым на обоих узлах кластера, и не должен размещаться на общем кластерном диске)

Будет выполнена проверка наличия свободного места на указанном диске…

 

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

 

На шаге Cluster Disk Selection выбираем общий кластерный диск, который не используется другими кластерными ролями. Именно этот кластерный диск будет использоваться как общее кластерное хранилище для размещения файлов БД SQL Server. В нижней информационной таблице мы увидим информацию об общих кластерных дисках уже используемых в других кластерных группах.

 

На шаге Cluster Network Configuration вводим статический IP адрес, который будет использоваться для нового высоко-доступного экземпляра SQL Server.

 

На шаге Server Configuration на закладке Service Accounts определяем то, что службы экземпляра SQL Server будут выполняться от имени ранее созданной доменной учётной записи s-KOM-AD01-SQLSP-Svc (которую мы предварительно включили на серверах-узлах кластера SQL Server в группу локальных администраторов). Тип запуска служб оставляем Manual, так как управлять запуском служб SQL Server фактически будет служба кластера.

 

Переключаемся на закладку Collation. Явных рекомендаций по выбору Collation для БД SharePoint 2013 я не нашёл, и поэтому будем руководствоваться доступной на данный момент рекомендацией применительно прошлых версий SharePoint KB2008668 - Supportability regarding SQL collation for SharePoint Databases and TempDB, косвенно подтверждённой в документе TechNet Library - Add a database server to an existing farm in SharePoint 2013, на основании чего выберем Collation  - Latin1_General_CI_AS_KS_WS.

 

На шаге Database Engine Configuration на закладке Server Configuration выбираем тип аутентификации Windows authentication mode и включаем в список администраторов создаваемого экземпляра SQL Server встроенную группу локальных администраторов BUILTIN\Administrators 

Переключаемся на закладку Data Directories и убеждаемся в том, что в качестве каталогов для хранения БД SQL Server указаны каталоги, которые будут созданы на выбранном ранее общем кластерном диске.

Далее мастер установки выполнит ещё несколько проверок…

И затем на экране Ready to Install ещё раз проверяем всю введённую информацию и нажимаем Install

Дожидаемся успешного окончания процесса установки.

 

Если на этапе конфигурирования никаких ошибок не было, то новый высоко-доступный экземпляр SQL Server будет успешно создан. Открываем оснастку Failover Cluster Manager и проверяем состояние кластера. Как видим, новая кластерная роль (кластерная группа ресурсов) создана и все её компоненты находятся в состоянии Online 

Проверяем с помощью ping KOM-AD01-SQLCL1.holding.com доступность кластерного имени заодно убедившись в том, что имя успешно динамически зарегистрировано в службе DNS.

Следующим шагом будет добавление второго узла в только что созданный кластер SQL Server.

 

3. Добавляем в кластер SQL Server второй узел (KOM-AD01-SQL02)

На втором узле кластера, в нашем случае это сервер с именем KOM-AD01-SQL02, запускаем программу установки SQL Server Installation Center и выбираем пункт добавления узла в кластер – Add node to a SQL Server failover cluster

Проходим шаги проверки зависимостей, ввода ключа продукта, принятия лицензионного соглашения и на шаге Cluster Node Configuration выбираем имя экземпляра SQL Server который был создан нами на предыдущем этапе, в нашем случае это именованный экземпляр SHAREPOINT 

На шаге Cluster Network Configuration подтверждаем использование IP адреса заданного на этапе создания кластера

На шаге Service Account вводим пароль учетной записи для запуска служб SQL Server, которая была выбрана ранее на этапе создания кластера (s-KOM-AD01-SQLSP-Svc).

Далее будет выполнена проверка на возможность присоединения узла к кластеру SQL Server

На шаге Ready to Add Node ещё раз проверяем всю заданную информацию и нажимаем Install

В процессе установки на добавляемый узел кластера будут установлен тот же набор компонент SQL Server, что был установлен ранее на первый узел кластера. Дожидаемся успешного завершения добавления узла в кластер…

После этого можно считать что наш двух-узловой кластер с высоко-доступным экземпляром SQL Server создан. Так как мы выполняли установку SQL Server 2012 Standard с дистрибутива с интегрированным Service Pack 1, то получили на обоих узлах кластера уровень обновления (patch level) соответствующий версии 11.1.3000. Хотя в документации по развёртыванию SharePoint 2013 нет жёстких требований относительно конкретного уровня обновлений до определённого Cumulative Update (CU), далее мы всё же рассмотрим кратко процесс установки CU для SQL Server на на узлах кластера.

 

4. Обновляем узлы кластера SQL Server до последнего Cumulative Update

Как я уже отметил, чётких требований к поддерживаемым билдам SQL Server 2012 для SharePoint 2013 мне найти не удалось и поэтому будем руководствоваться рекомендациями более широкого спектра. Например из документа TechNet Library - Overview of SQL Server in a SharePoint environment (SharePoint 2013) можно понять, что версии SQL Server 2012 SP1 достаточно для работы компонент SharePoint 2013, поэтому мы вполне можем остановимся на этом уровне обновления для SQL Server. Однако если разворачиваемый экземпляр SQL Server помимо БД SharePoint планируется использовать ещё под какие-то сопутствующие SharePoint вещи, как например Workflow Manager, то возможно имеет смысл поднять уровень обновления  SQL Server до последнего CU. Получить информацию о текущем уровне CU для разных версий SQL Server можно например по ссылке Microsoft SQL Server 2014 - 7.0 Builds. На данный момент к загрузке доступно обновление KB2931078 - Cumulative update package 9 for SQL Server 2012 Service Pack 1.

При установке обновлений Service Pack/Cumulative Update/Hotfix на узлы кластера SQL Server желательно придерживаться определённой последовательности действий. Например, если в нашем двух-узловом кластере на момент обновления владельцем кластерных ресурсов SQL Server (активным узлом) является узел KOM-AD01-SQL01, а узел KOM-AD01-SQL02 является пассивным узлом кластера, то последовательность установки обновления будет следующей:

1. Устанавливаем обновление на пассивный узел кластера (KOM-AD01-SQL02) и перезагружаем его
2. Переключаем ресурсы кластера на обновлённый узел (KOM-AD01-SQL02).
3. Устанавливаем обновление на второй узел кластера (KOM-AD01-SQL01) который в данный момент является пассивным узлом и перезагружаем его.
4. При необходимости возвращаем ресурсы на другой узел кластера (KOM-AD01-SQL01)

Итак, определяемся с тем, какой узел кластера в данный момент является активным (OwnerNode) для кластерной группы нашего вновь созданного кластера SQL Server, например выполнив на любом из узлов кластера PowerShell команду:

Get-ClusterGroup *SHAREPOINT* | Format-List

Как видим, владельцем кластерной группы SQL Server (SHAREPOINT) является узел KOM-AD01-SQL01, поэтому установку обновления мы начнём с пассивного узла, то есть с сервера KOM-AD01-SQL02.

На пассивном узле кластера (KOM-AD01-SQL02) распаковываем полученный файл обновления, в нашем примере это SQLServer2012-KB2931078-x64.exe либо любым архиватором, либо командой:

SQLServer2012-KB2931078-x64.exe /extract:"C:\DISTRIBUTIVES\SQLServer2012_SP1_CU9"

В распакованном каталоге запускаем файл setup.exe и дожидаемся когда мастер установки выполнит проверку на возможность выполнения установки обновления…

На шаге Select Features нам будет выведена информация о найденных на текущем сервере экземплярах и компонентах SQL Server. Выбираем для обновления интересующий нас именованный экземпляр SQL Server – SHAREPOINT и сразу видим, что Patch Level соответствует уровню SQL Server 2012 SP1. Здесь же видим, что статус устанавливаемого обновления для выбранного экземпляра на данном сервере – Not installed. Обратите внимание на то, что отмечать для обновления соседствующие экземпляры SQL Server совершенно не обязательно, однако компоненты из группы Shared Features (набор компонент необходимых для всех экземпляров SQL Server) будут обновлены в любом случае.

На шаге Ready to update просматриваем все параметры предстоящего обновления и нажимаем Update

Дожидаемся успешного окончания процесса обновления…

Обновление установлено и теперь можно перезагрузить обновлённый сервер, после чего можно будет приступить к обновлению второго узла кластера.

Перед обновлением второго узла кластера необходимо передать все запущенные на нём кластерные группы на уже обновлённый узел, например с помощью PowerShell:

Get-ClusterGroup | Move-ClusterGroup -Node KOM-AD01-SQL02

 

После этого сервер KOM-AD01-SQL01 фактически станет пассивным узлом кластера и можно приступить к его обновлению. Порядок установки CU на втором узле кластера будет точно такой же, как и на первом.

После успешного завершения установки обновления перезагружаем обновлённый сервер.

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

Get-ClusterGroup | Move-ClusterGroup -Node KOM-AD01-SQL01

Дополнительно проверить уровень обновления кластерного экземпляра SQL Server можно простым SQL-запросом:

SELECT
SERVERPROPERTY('IsClustered') as _1_Means_Clustered ,
SERVERPROPERTY('Edition') as Edition ,
SERVERPROPERTY('ProductVersion') as Version ,
SERVERPROPERTY('ComputerNamePhysicalNetBIOS') as ActiveNode 

В результате его выполнения мы получим информацию о том, что экземпляр SQL Server - кластерный, узнаем его редакцию, номер версии (из которого можно понять уровень CU) а также имя активного узла кластера – держателя ресурсов кластерной группы.

 

5. Настраиваем для экземпляра SQL Server статический порт TCP

В нашем случае TCP порт службы SQL Server по умолчанию (1433) уже используется для другого экземпляра SQL Server в кластере и поэтому нашему экземпляру созданному для SharePoint мы настроим другой статический порт. Выполним эту настройку на активном узле кластера с помощью оснастки SQL Server Configuration Manager. Развернём узел SQL Server Network Configuration выберем настройку протоколов (Protocols) для нашего именованного экземпляра SHAREPOINT и вызовем в меню свойства протокола TCP/IP

Включим прослушиватель статического порта TCP, например 1435 (или другого не занятого в системе порта), на IP адресе созданного кластерного экземпляра SQL Server (в нашем примере это адрес 10.160.0.250), то есть для этого интерфейса переведём значение параметра Enabled в Yes. Очистим значение TCP Dynamic Port, чтобы отключить использование динамически назначаемого порта, а в значении TCP Port впишем номер выбранного нами статического порта (те же настройки укажем в разделе IPAll)

После этого для вступления изменений в силу нужно перезапустить службу SQL Server обслуживающую наш экземпляр SHAREPOINT

На втором узле кластера можно не выполнять эту настройку так как она автоматически будет передана на него в случае перемещения кластерной группы с службой SQL Server на этот узел.

Теперь проверим, что на активном узле кластера создался TCP прослушиватель на указанном нами номере порта…

netstat -na | findstr 1435

… а также поверим, то что после указания статического порта и перезапуска службы в домене для сервисной учетной записи от имени которой у нас работает служба SQL Server успешно зарегистрировался соответствующий SPN:

setspn -L s-KOM-AD01-SQLSP-Svc

 

Как видим TCP прослушиватель работает и теперь всё, что нам остается сделать, это добавить на серверы-узлы кластера SQL Server разрешающее правило в Windows Firewall для возможности удалённого подключения на соответствующий статический TCP порт SQL Server. Сделаем это с помощью PowerShell:

New-NetFirewallRule -DisplayName "SQL Server Service (SHAREPOINT) TCP-In" -Direction "Inbound" -Protocol "TCP" -Action "Allow" -LocalPort "1435"

На этом создание и подготовку экземпляра SQL Server будем считать законченными, а в следующей части рассмотрим процесс установки WFE-сервера SharePoint Server 2013 SP1 на выделенный сервер Windows Server 2012 R2.