Поделиться через


Указания по обновлению путем частичной замены без простоев в SharePoint Server 2016

 

**Применимо к:**SharePoint Server 2016

**Последнее изменение раздела:**2016-10-21

Обновление путем частичной замены без простоя (ZDP) доступно в SharePoint Server 2016. Пользователи смогут работать с документами, а также сохранять и искать их во время обновления фермы SharePoint Server 2016.

Обновление путем частичной замены без простоя — это метод исправления и обновления, предусмотренный в SharePoint Online. Он позволяет администраторам обновлять службу путем частичной замены, пока пользователи работают со своими подписками. Другими словами, этот проверенный способ позволяет выполнять обновление путем частичной замены, в то время как пользователи активно работают со своими файлами, а система поиска выполняет обход и отображает результаты в ферме SharePoint Server. Именно это мы подразумеваем, когда говорим "без простоя".

Рассматривая ZDP, следует упомянуть несколько факторов (мы подробнее рассмотрим их далее в этой статье).

  • Эффективность ZDP можно повысить с помощью функции MinRole в SharePoint Server 2016, но использовать MinRole не обязательно.

    Как может помочь MinRole?

  • Для использования преимуществ ZDP ферме необходим высокий уровень доступности. Фермы SharePoint Server 2016 с высоким уровнем доступности необходимы для ZDP.

    Почему необходим высокий уровень доступности?

Важно помнить, что цель ZDP — устранение простоев в работе пользователей, поэтому в этой статье все решения, связанные с обновлением путем частичной замены и перезагрузкой фермы, принимаются с учетом этой цели.

Важно!

Даже если на всех серверах в вашей ферме SharePoint Server 2016 используется настраиваемая роль, вы можете вручную настроить высокодоступную ферму. На сайте TechNet есть документы, которые помогут вам создавать высокодоступные фермы, а принципы обеспечения отказоустойчивости (избыточное оборудование) и высокого уровня доступности (системы и программное обеспечение для отработки отказа и продления времени работы) остаются прежними. Обратите внимание, что в более сложных высокодоступных или настраиваемых фермах следует соблюдать особую осторожность при обновлении поисковых серверов, чтобы обеспечить поддержку высокого уровня доступности. Например, вы можете исправлять реплики индекса по одной и никогда не обновлять разные реплики индекса из одного раздела одновременно.

Процесс ZDP

В этом примере ZDP применяется к ферме SharePoint Server 2016, настроенной с использованием MinRole. Образец среды выглядит следующим образом:

В данной статье описана среда, включающая 8 серверов: 4 обязательных роли сервера, указанных в столбце 1 (SPWeb01, SPApp01, SPDch01, SPSrch01), а также 4 избыточных роли сервера, указанных в столбце 2 (SPWeb02, SPApp02, SPDch02, SPSrch02).

В этой структуре интерфейсные веб-серверы (WFE) SPWeb01 и SPWeb02 подключены к подсистеме балансировки нагрузки, и в данный момент оба сервера содержат запросы. У нас есть два сервера приложений (SPApp01 и SPApp02), два сервера распределенного кэша (SPDCH01 и SPDCH02) и два поисковых сервера (SPSRCH01 и SPSRCH02). С этой структурой связан (но не включен непосредственно в процесс ZDP) кластер SQL Server (например, SQL Server Always-On).

На этой схеме можно провести условную линию сверху вниз по центру фермы. С одной ее стороны находятся все серверы с номером 01 (столбец 1), а с другой — избыточные серверы с номером 02 (столбец 2). Мы будем использовать эту двойную конструкцию, чтобы поддерживать работу фермы во время обновления путем частичной замены.

Большинство действий, выполняемых по одну сторону линии (на серверах 01), необходимо в точности повторить на серверах 02. Из всех действий, составляющих относительно простой, двухэтапный процесс ZDP, самыми сложными являются действия с интерфейсными веб-серверами (SPWeb01 и SPWeb02). С них и начнем.

Примечание

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

Убедитесь, что интерфейсные веб-серверы перезагружены и протестированы, прежде чем отключать их от подсистемы балансировки нагрузки, чтобы избежать ситуаций, когда обновляемый интерфейсный веб-сервер исключается из оборота, а остальные серверы не выдерживают образующейся нагрузки. Перед обновлением все серверы фермы должны быть перезагружены и работоспособны. Кроме того, во время обновления или частичной замены рекомендуется остановить обход контента при поиске и импорт профилей.

Важно!

Перед обновлением следует разрешить параллельное копирование файлов. Это гарантирует, что все интерфейсные веб-серверы в ферме обрабатывают одно и то же статическое содержимое во время обновления, даже при обновлении или замене статических файлов на том или ином интерфейсном веб-сервере. Параллельное копирование встроено в PSCONFIG, но его необходимо включить. Эта функция обеспечивает согласованный пользовательский интерфейс сайтов при просмотре SharePoint и работе с файлами даже во время изменения и обновления содержимого файловой системы.
Чтобы разрешить параллельное обновление, необходимо открыть Командная консоль SharePoint 2016 и выполнить следующие команды на всех серверах SharePoint:
$webapp = Get-SPWebApplication <webappURL>
$webapp.WebService.EnableSideBySide = $true
$webapp.WebService.update()
Обратите внимание, что администраторы могут отказаться от параллельного обновления, задав для параметра enableSideBySide значение $false. Учтите, что это может повлиять на пользовательский интерфейс сайтов. Обновленный пользовательский интерфейс может отображаться не всегда. Кроме того, могут возникать такие проблемы, как изменение или обновление файлов JavaScript во время их просмотра.

Этап 1. Установка исправлений

На первом этапе мы скопируем двоичные файлы исправлений на серверы и установим их там.

  1. Шаг 1 исправления при нулевом времени простоя

    Отключите первый интерфейсный веб-сервер (SPWeb01) от подсистемы балансировки нагрузки и установите на нем пакеты STS и WSS. Когда исправление будет завершено, перезагрузите сервер. Снова подключите сервер к подсистеме балансировки нагрузки.

  2. Шаг 2 исправления при нулевом времени простоя

    Отключите второй интерфейсный веб-сервер (SPWeb02) от подсистемы балансировки нагрузки и установите на нем пакеты STS и WSS. Когда исправление будет завершено, перезагрузите сервер. Оставьте сервер отключенными от подсистемы балансировки нагрузки, пока обновление не будет полностью завершено.

    Примечание

    Если обновление не выполняется во время технического обслуживания, а на ферму приходится большая нагрузка, вы можете вернуть этот интерфейсный веб-сервер в подсистему балансировки нагрузки, пока не будете готовы к запуску PSCONFIG.

  3. Шаг 3 исправления при нулевом времени простоя

    Установите пакеты STS и WSS на серверах SPApp, SPDCH и SPSRCH в столбце 1. После установки перезагрузите серверы (нагрузка, поступающая с сервера SPWeb01, перейдет на серверы в столбце 2).

  4. Шаг 4 исправления при нулевом времени простоя

    Теперь повторите исправление и перезагрузку для серверов в столбце 2. Установите пакеты STS и WSS на серверах SPApp02, SPDCH02 и SPSRCH02 в столбце 2. После установки перезагрузите серверы (как видите, нагрузка, поступающая с сервера SPWeb01, перейдет на серверы в столбце 1).

Этап 2. Обновление с помощью PSCONFIG

На каждом узле фермы SharePoint Server 2016 установлены исправления, а все серверы перезагружены. Пришло время обновить сборки.

Примечание

В ходе процесса ZDP вы можете использовать командлет Upgrade-SPContentdatabase, чтобы сократить общее время работы PSCONFIG. Это рекомендуется делать при наличии большого количества баз данных или выборе больших баз данных.

  1. Шаг 5 исправления при нулевом времени простоя

    Вернитесь к интерфейсному веб-серверу, отключенному от подсистемы балансировки нагрузки (SPWeb02), откройте Командная консоль SharePoint 2016 и выполните следующую команду PSCONFIG:

    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secrureresources -cmd services -install
    

    После выполнения команды верните этот интерфейсный веб-сервер (SPWeb02) в подсистему балансировки нагрузки. Теперь этот сервер полностью исправлен и обновлен.

    Совет

    На последнем этапе процесса PSCONFIG мы гарантируем, что обновления пользовательского интерфейса копируются из папки /layouts в папку, относящуюся к определенной версии. Эта составляющая параллельного обновления пользовательского интерфейса гарантирует, что пользователям фермы будет доступен один и тот же пользовательский интерфейс до завершения обновления, когда вы будете готовы переключиться на новый пользовательский интерфейс.
    Чтобы убедиться, что параллельное копирование выполнено успешно, проверьте соответствующий файл журнала. По умолчанию он находится в папке C:\program files\common files\Microsoft shared\web server extensions\16\logs (у вас может быть другая буква корневого диска).
    Если по какой-либо причине PSCONFIG не удалось скопировать файлы пользовательского интерфейса, выполните команду Copy-SidebySideFiles, чтобы скопировать их вручную.

  2. Шаг 6 исправления при нулевом времени простоя

    Отключите сервер SPWeb01 от подсистемы балансировки нагрузки. Откройте Командная консоль SharePoint 2016 и выполните ту же команду PSCONFIG:

    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
    

    Верните этот интерфейсный веб-сервер (SPWeb01) в подсистему балансировки нагрузки. Теперь он тоже полностью исправлен и обновлен.

    Оба интерфейсных веб-сервера исправлены и обновлены. Теперь можно переходить к остальным компонентам фермы. Однако убедитесь, что необходимые команды Microsoft PowerShell выполняются на серверах по очереди, а не параллельно. Это означает, что команды выполняются на серверах в столбце 1 по одному. Затем вы по очереди выполните эти команды для серверов в столбце 2. Конечная цель — обеспечение непрерывной работы. Серийное выполнение команд PSCONFIG — самый надежный и предсказуемый способ завершения процесса ZDP, так что им мы и воспользуемся.

  3. Шаг 7 исправления при нулевом времени простоя

    Выполните ту же команду PSCONFIG в Командная консоль SharePoint 2016 для всех остальных серверов в столбце 1 (SPApp01, SPDCH01, SPSRCH01). Последовательно повторяйте эти действия на каждом сервере, пока не будут обновлены все серверы в столбце 1.

    Важно!

    Не забудьте корректно удалить распределенный кэш, прежде чем запускать PSCONFIG, а по завершении снова добавьте распределенный кэш на сервер.

    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
    
  4. Шаг 8 исправления при нулевом времени простоя

    Выполните ту же команду PSCONFIG в Командная консоль SharePoint 2016 для всех остальных серверов в столбце 2 (SPApp02, SPDCH02, SPSRCH02). Сделайте это на каждом сервере по очереди, пока не будут обновлены все серверы в столбце 2.

    Важно!

    Не забудьте корректно удалить распределенный кэш, прежде чем запускать PSCONFIG, а по завершении снова добавьте распределенный кэш на сервер.

    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install
    

    Важно!

    После успешного запуска PSCONFIG для всех серверов не забудьте выполнить представленную ниже команду Командная консоль SharePoint 2016, чтобы переключиться на новые файлы пользовательского интерфейса и завершить параллельный процесс.
    $webapp.WebService.SideBySideToken = <current build number in quotes, ex: "16.0.4338.1000">
    $webapp.WebService.update()

Теперь все готово, и ферма была полностью обновлена во время ее использования без простоев.

Как может помочь MinRole?

Рассматривая ZDP, также стоит упомянуть о понятии MinRole. MinRole — это параметр установки SharePoint Server 2016. Он разбивает конфигурацию фермы на роли, такие как интерфейсные веб-серверы (WFE), серверы приложений (App), серверы распределенного кэша (DCache), поисковые или настраиваемые серверы (для пользовательского кода или продуктов от сторонних разработчиков). Такая конфигурация в среднем включает четыре сервера — два интерфейсных веб-сервера, два сервера приложений, два сервера распределенного кэша и два поисковых сервера.

По умолчанию интерфейсные веб-серверы оптимизированы для минимальной задержки, а серверы приложений — для высокой пропускной способности. Аналогичным образом, если объединить компоненты поиска так, чтобы вызовы не покидали исходный блок, поисковые серверы будут работать эффективнее. Одно из важнейших преимуществ MinRole — встроенная отказоустойчивость.

Почему необходим высокий уровень доступности?

Высокий уровень доступности в SharePoint — это обширная тема. В Интернете ей посвящают целые документы и статьи, такие как эта документация на сайте TechNet. Чтобы быстрее разобраться (хотя бы в информации этой статьи), вспомните, что функция ZDP и MinRole впервые появились в SharePoint Online (SPO). В SPO виртуализированные серверы содержат встроенные избыточные компоненты, чтобы два сервера с одинаковыми ролями в одной ферме SharePoint не располагались в одном узле или на одной стойке. Это повышает отказоустойчивость SPO. Вы можете смоделировать аналогичную ситуацию, разместив по два сервера с каждой ролью SharePoint Server в разных узлах или на разных стойках в своем центре обработки данных и соединив стойки общим маршрутизатором или кабелями для быстрой связи. Вы также можете настроить по два физических сервера для каждой роли SharePoint Server в тестовой среде (выбрав отдельные стойки питания для каждой половины фермы и убедившись, что маршрутизация между серверами выполняется быстро и, если это возможно, в обход трафика общей сети для сокращения задержки).

Здесь следует стремиться к высокому уровню доступности и отказоустойчивости. Это означает, что нашим главным приоритетом будут разделение ролей между стойками или серверами, подготовка двух серверов для каждой роли, обеспечение высокой скорости сетевого трафика между этими двумя уровнями, а также настройка двух систем для отслеживания и автоматической отработки отказа на серверах баз данных. Для установки служб в SharePoint вручную (например, при выборе настраиваемой роли) важна избыточность служб в ферме. Допустим, сервер распределенного кэша является кластерным, в ферме есть несколько интерфейсных веб-серверов, а серверы приложений и поисковые серверы настраиваются парами. Таким образом, при возникновении серьезной проблемы на одном сервере второй сервер может обрабатывать пользовательскую нагрузку.

В приведенных выше примерах мы использовали физические серверы, чтобы нагляднее продемонстрировать основные понятия. Когда придет время планировать ZDP, вам следует запланировать собственную среду, где бы она ни находилась (с названиями и номерами стоек, а также номерами серверов, на которых можно найти каждую из ролей SharePoint Server). Это один из самых быстрых способов изолировать любые нарушения требований к избыточности ролей и отказоустойчивости, которые могли быть допущены в вашей среде, независимо от ее размера.

Смежные темы

Видеоролик с демонстрацией работы функции применения исправлений без простоев в SharePoint Server 2016