Некоторые особенности развёртывания Office SharePoint Server 2007 в NLB, под Windows Server 2008, с HTTPS-доступом

  • Article

Здесь мне хотелось бы рассказать об особенностях развертывания SharePoint под Windows Server 2008 И/ИЛИ в NLB-конфигурации И/ИЛИ с HTTPS-доступом.

Я не буду в подробностях рассказывать о развертывании SharePoint в этих условиях. Расскажу лишь о некоторых нюансах, которые мало упоминаются в блогах и статьях на TechNet.

Но несколько общих истин все же повторю:

  • Обращайтесь к ферме по адресу NLB-кластера, а не по адресам отдельных нод!
  • Веб-приложение Central Administration – исключение из предыдущего правила! Не выставляйте в Default-овую зону Alternate Access Mapping-а DNS-имя NLB-клстера. Это может нарушить функционирование веб-приложения.
  • При работе с WLBS (софтовый load balancer от Microsoft) не используйте Unicast-mode.

В дальнейшем повествовании будем иметь ввиду конфигурацию, описанную в статье про Kerberos. В ней, как мы помним, два WFE и один индекс-сервер.

Несколько правил, касающихся сервисов SharePoint (Central Administration -> Operation -> Services on Server),которые облегчать жизнь:

  • На index-сервере должен быть запущен ТОЛЬКО сервис «Office SharePoint Server Search» и, возможно, Document Conversion Load Balancer. Это конечно не mandatory-правило, то скорее «правило хорошего тона».
  • На WFE-серверах должны быть запущены одни и те же сервисы, за исключением «Document Conversion Load Balancer» (про него отдельно ниже)
  • На Query-серверах (в нашей конфигурации их роль выполняют WFE) конечно также следует запустить «Office SharePoint Server Search».

Теперь о «Document Conversion Load Balancer».

Его особенность в том, что в сервисы, которые выполняют собственно запуск преобразования документов (Document Conversion Launcher), обычно запущены на всех (WFE) серверах фермы, а Load Balancer – только на одном (иногда на WFE, иногда на index-сервере).

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

Наши действия по шагам. Сначала нужно добиться, чтобы сервисы запустились на правильном IP-адресе (мы же помним о NLB!). Для этого необходимо сконфигурировать так называемый IP exclusion:

  • На каждом компьютере фермы открываем файл %PROGRAMFILES%\Microsoft Office Server\12.0\Bin\Microsoft.Office.Server.Conversions.Launcher.exe.config и раскомментируем там узел типа "add" в секции LauncherSettings с ключом key="keyIPExclude" .

  • Выставляем значение value в этом ключе в регулярное выражение, покрывающее IP-адреса по следующим условиям:

    • IP-адрес NLB-кластера
    • ::1 IP-адрес (в Windows Server 2008)
    • другие IP-адреса, полученные от сетевых соединений, которые не обеспечивают взаимодействие серверов фермы между собой

    Фактически не исключенным должен остаться один адрес. Например, в нашей конфигурации, если адрес NLB-кластера равен 10.1.33.120, то ключ будет выглядеть так: <add key="keyIPExclude" value="(10\.1\.33\.120)|(\:\:1)" />

  • Копируем этот ключ в Буфер обмена J

  • Сохраняем файл

  • Открываем файл %PROGRAMFILES%\Microsoft Office Server\12.0\Bin\Microsoft.Office.Server.Conversions.LoadBalancer.exe.config

  • Вставляем в конец секции LoadBalancerSettings из буфера обмена ключ add c keyIPExclude ( <add key="keyIPExclude" value="(10\.1\.33\.120)|(\:\:1)" )

  • Сохраняем файл. Теперь сервисы будут запускаться на правильных IP-адресах.

  • Затем на всех серверах фермы, кроме того, на котором планируем запустить «Document Conversion Load Balancer», делаем следующее:

    • открываем в regedit ключ [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\LauncherSettings]
    • выставляем значение LoadBalancerUrl в https://portal-index:8093/HTMLTrLoadBalancer, где portal-index – сервер на котором мы запустим «Document Conversion Load Balancer»
    • выставляем значение Port в 8082 ( десятичное! )

Все готово для запуска сервисов. Запускаем сначала через Services on Server сервис «Document Conversion Load Balancer» на том сервере, который мы для него отвели (portal-index).

Затем через stsadm запускаем на серверах, объединенных в NLB, сервис «Document Conversion Launcher». Для этого выполняем команды:

  • stsadm -o provisionservice -action stop -servicetype Microsoft.Office.Server.Conversions.LauncherService -servicename dclauncher
  • stsadm -o provisionservice -action start -servicetype Microsoft.Office.Server.Conversions.LauncherService -servicename dclauncher

И под конец несколько действий, специфичных для Windows Server 2008. Они описаны также в статье «Развертывание простой фермы в операционной системе Windows Server 2008 (Office SharePoint Server)».

Конфигурирование Trace Log-а.

В большинстве конфигураций есть действия, выполняющиеся раз в неделю. Например, полный обход User Profiles. По этим и другим причинам целесообразно иметь trace log-и минимум за неделю. Также будем считать целесообразным иметь на каждые 30 минут отдельный файл.

Для этого необходимо выполнить следующие настройки:

  • В Central Administration на вкладке Operation в секции Logging and Reporting открываем Diagnostic Logging
  • В секции Trace Log устанавливаем значение Number of log files в 366 (чтобы хватило на все неделю, по 30 минут каждый)
  • Значение Number of minutes to use a log file выставляем в 30.
  • Убеждаемся в том, что хранилище, на которое указывает значение Path, позволит хранить достаточный для log-ов объем данных.
  • Жмем ОК
    J

Конфигурирование Windows Server Backup.

Запускаем regedit и открываем ключ [HKEY _LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion]. Если подключ WindowsServerBackup существует, то переходим в него. Если нет – создаем.

Затем, Application Support существует, то переходим в него. Если нет – создаем. Затем по шагам:

  • Создаем ключ {c2f52614-5e53-4858-a589-38eeb25c6184}

    (Это GUID WSS Writer-а).

  • В этом новом ключе создаем новое строковое значение с именем Application Identifier и значением Windows SharePoint Services.

  • Создаем новое числовое (DWORD (32-bit) ) значение с именем UseSameVssContext и значением 1.

Далее небольшой trick, описание которого я пока нигде не видел.

В том же regedit-е нужно делегировать "Full Control"-permission на ключ "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Diag" аккаунтам, под которыми запускаются оба Search-сервиса: «Office SharePoint Server Search» и «Windows SharePoint Services Search». В нашем случае это аккаунты svc_sp_serversearch и неописанный svc_sp_wss_search.

Перезагружаем серверы J Кстати, делать это лучше по очереди, начиная с index-сервера, и затем WFE, заканчивая тем, который конфигурировался первым. Вроде бы это неважно, но Event Log-и выглядят лучше. Мелочь, а админам приятно.

Кто хочет узнать больше, может почитать эти статьи:

HTTPS

И немного слов о HTTPS, навеянных комментарием Ильи Шилова. Речь пойдет о ситуации, когда хочется иметь несколько HTTPS-сайтов на 443-ем порту.

Если вспомнить те же действия для других портов, то такое конфигурирование выполняется через host header-ы. Вроде и здесь все то-же самое. Да, но есть пара отличий.

  • Отличие первое: IIS умеет выставлять на одном HTTPS-порту только один SSL-сертификат вне завсимости от количества веб-сайтов, опубликованных на этом порту.
  • Отличие второе: сконфигурировать host header для таких конфигураций правильно можно только через командную строку, а точнее через новую в IIS7 замечательную тулу AppCmd.

Чтобы учесть первое отличие, необходимо получить так называемый Wildcard-сертификат или Subject Alternative Name-сертификат. Первый позволяет идентифицировать все сервера домена по маске (*.company.com), второй позволяет просто идентифицировать несколько серверов (сертификат включает их список).

Командная же строка для создания SSL Host Header-а (или еще говорят "Secure Binding") выглядит так: %SystemRoot%\System32\inetsrv\appcmd
set
site
/site.name:SiteName
/+bindings.[protocol='https',bindingInformation='*:443:HostHeader'] , где SiteName - имя сайта (узнаем в консоли IIS; например Personal Sites), а HostHeader - собственно желаемый host header (например my.company.com).

Хороший пост на эту тему: https://blog.mike-obrien.net/PermaLink,guid,12d9628c-a350-4f7b-a573-9d05429b54e8.aspx

Еще один, учитывающий IIS версии 6 (и работу через adsutil.vbs): https://blogs.technet.com/blairb/archive/2008/01/11/how-to-use-ssl-certificates-with-multiple-subject-alternative-names-in-moss.aspx