Шаги по исправлению нулевого простоя SharePoint Server

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ:no-img-132013 yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint в Microsoft 365

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

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

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

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

Важно!

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

Процесс ZDP

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

The environment for this article has 8 servers: 4 required server roles in column 1 (SPWeb01, SPApp01, SPDch01, SPSrch01) and 4 redundant server roles in column 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 можно найти здесь. Обратите внимание, что в этой статье приведены ссылки на документацию по параметрам разрешений для SharePoint Server. Просматривайте эти статьи по мере необходимости и помните, что обновление путем частичной замены включает обновление баз данных. Например, если вы изменили разрешения SQL Server для учетных записей SharePoint после установки, вам потребуется ознакомиться с этими статьями.

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

Важно!

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

Чтобы включить параллельные функции, выполните один раз следующий сценарий PowerShell, используя URL-адрес для одного из веб-приложений содержимого:

$webapp = Get-SPWebApplication <webappURL>
$webapp.WebService.EnableSideBySide = $true
$webapp.WebService.update()

С версии KB3178672 (обновление за март 2017 г.) для SharePoint Server 2016 и более поздних версий PSCONFIG автоматически копирует в папку все файлы .js, CSS и .htm в 16-HIVE\TEMPLATE\LAYOUTS папку16-HIVE\TEMPLATE\LAYOUTS\<NEW BUILD NUMBER>, необходимую для переключения на новые файлы пользовательского интерфейса и выполнения параллельного процесса, как описано далее в этом разделе в разделе Этап 2 — обновление PSCONFIG (4).

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

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

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

    Выведите первый WFE (SPWeb01) из подсистемы балансировки нагрузки и исправите его пакетами STS и WSS.
    Перезагрузите сервер после установки исправлений.
    Верните сервер для смены в подсистеме балансировки нагрузки.

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

    Извлеките второй WFE (SPWeb02) из подсистемы балансировки нагрузки и исправите его пакетами STS и WSS.
    Перезагрузите сервер после установки исправлений.
    Оставьте этот сервер вне подсистемы балансировки нагрузки до завершения всего обновления.

    Примечание.

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

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

    Для каждого из SPApp, SPDCH и SPSRCH в столбце 1 установите исправления с пакетами STS и WSS.
    Перезагрузите их по завершении. (Работа, отправленная SPWeb01, будет выполняться на серверах в столбце 2.

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

    Теперь вы повторите "исправление и перезагрузка" для столбца 2. Для каждого из SPApp02, SPDCH02 и SPSRCH02 в столбце 2 установите исправления с пакетами STS и WSS.
    Перезагрузите их по завершении. (Как видите, работа, отправленная SPWeb01, теперь будет приходится на серверы в столбце 1.)

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

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

Примечание.

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

  1. Шаг 5 в процессе ZDP показан на рисунке.

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

    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -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 и выполните ту же команду PSCONFIG:

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

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

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

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

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

    Важно!

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

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

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

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

    Важно!

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

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

    Важно!

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

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

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

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

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

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

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

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

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

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