Share via

Некоторые особенности развёртывания 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

Comments

  • Anonymous
    January 01, 2003
    Илья, почитайте документ "Deploy in a simple server farm (Office SharePoint Server)": http://technet.microsoft.com/en-us/library/cc262243.aspx Очень много ответов сразу уйдет. По первому вопросу: цитата из этого документа "You must start the Windows SharePoint Services Search service on every computer that you want to search over Help content". По второму вопросу. Если вы выбираете установку "Внешний веб-сервер", значит вы вообще не хотите на этом сервере хостить иных приложений, кроме Web-сайтов. То есть остальные службы должны запускаться на других серверах. Самое простое: выбирайте везде Full, а потом запускайте те службы, которые нужны.  

  • Anonymous
    January 01, 2003
    Замечательный обзор. Нужно только еще упомянуть что сбор NLB в мультикасте не самое тривиальное занятие. А на некоторых серверах еще и превращающеся в умопомрочительный квест - найди правильную комбинацию слабодокументированых ключей в реестре =(

  • Anonymous
    January 01, 2003
    По службе "Поиск Office SharePoint Server" все правильно. А служба "Поиск в Windows SharePoint Services" - это служба поиска, доставшаяся MOSS-у от базовой платформы WSS. В случае с MOSS она выполняет только две простые роли:

  • индексирования Help-а WSS
  • обслуживание запросов поиска ТОЛЬКО по Help-у WSS
  • Anonymous
    October 27, 2008
    Сразу хотелось бы у Вас выяснить некоторые моменты по службам MOSS, потому что из понимания этого вопроса можно полновесно вникнуть в описанную Вами тему. В ферме серверов MOSS присутствуют две службы отвечающие за поиск (так как использую локализованную версию MOSS - возможно некоторое расхождение в названиях):
  • Поиск Office SharePoint Server
  • Поиск в Windows SharePoint Services Теперь подробнее - поправьте меня если что не так: Поиск Office SharePoint Server - выполняет две роли: индексирование; обслуживание запросов поиска. Соответственно две роли можно разнести по нескольким серверам - один индексирует, другой на основе этого индекса отображает конечному пользователю результат. В Вашей, Владимир, среде роль индексирования вынесена на отдельный сервер (Index - PORTAL-INDEX ), а роль обслуживания запросов на внешние веб-серверы (WFE - PORTAL-WFE1, PORTAL-WFE2). Поиск в Windows SharePoint Services - выполняет непосредственно обход содержимого. В Вашей среде я так понимаю эта служба запущена на сервере который выполняет роль индексирования (PORTAL-INDEX)? Это так? И как быть с приведенными Вами правилами - это вписывается в них (На index-сервере должен быть запущен ТОЛЬКО сервис «Office SharePoint Server Search»)? Буду признателен за пояснения?
  • Anonymous
    October 27, 2008
    Соответственно в расчет службу "Поиск в Windows SharePoint Services" при планировании фермы можно не брать и смело ставить вместе с ролью индексирования "Поиск Office SharePoint Server"? Исходя из Ваших правил получается что роль обслуживания запросов поиска лучше размещать на WFE-серверах и это будет являться правилом хорошего тона? Поясню почему столько вопросов: у меня как у человека занимающегося проектированием ферм MOSS на данный момент вопросов больше чем ответов. И небольшое замечание по Document Conversion Launcher: данную службу возможно будет запустить на WFE-серверах только если была выполнена полная установка Microsoft Office SharePoint Server 2007. Если была выполнена установка как "Внешний веб-сервер" то запуск службы "Служба запуска для преобразования документов" будет не возможна - хотя в "Центр администрирования" данная возможность будет отображена.