Рассмотренный ранее пример скриптового решения для автоматизации периодического полного резервного копирования фермы выполняет свою задачу и применительно к SharePoint Server 2016, и до некоторых пор у нас всё было хорошо. Однако, очередная проверка успешности создания резервных копий показала наличие проблемы, возникающей со службой поиска и приводящей к созданию неполной резервной копии фермы. В этой заметке мы рассмотрим шаги, которые были предприняты для решения этой проблемы.
В лог-файле spbackup.log процесса резервного копирования, который создаёт SharePoint Server 2016 в подкаталоге сохранения резервной копии, была обнаружена проблема взаимодействия с приложением службы поиска Search Service Application:
[FatalError] Object Search Service Application failed in event OnBackup. ... Object Search Service Application failed in event OnPrepareBackup. ... InvalidOperationException: State 'Backup' can't be set due to current application state 'Backup'. ... [FatalError] Backup failed for Object Crawl-0 (C: on KOM-WEB1) failed in event OnBackup. For more information, see the spbackup.log or sprestore.log file located in the backup directory.
Общий смысл проблемы заключался в том, что приложение службы поиска невозможно включить в резервную копию, так как оно уже находится в состоянии создания резервной копии.
При проверке приложения службы поиска на веб-узле SharePoint Central Administration было обнаружено, что статус приложения отображается как Paused for:Backup/Restore
Перезапуск служб SharePoint на уровне ОС, а также полная перезагрузка сервера со службой поиска, на ситуацию никак не повлияли.
Статья "Restore Search service applications in SharePoint Server" навела на мысль о том, что можно попытаться в ручную "толкнуть" службу поиска командлетом Resume-SPEnterpriseSearchServiceApplication. Для этого нам может потребоваться выяснить имя или идентификатор службы поиска
В итоге команда форсированного запуска приложения службы поиска с конкретным Id будет иметь вид:
$ssa = Get-SPEnterpriseSearchServiceApplication -Identity 781c57c2-56e9-4956-b42f-2a4d1df4e754 Resume-SPEnterpriseSearchServiceApplication -Identity $ssa
На форумах можно встретить свидетельства того, что такой вариант в некоторых случаях исправлял ситуацию. Но это был не наш случай, так как попытка выполнения приводила к многочасовому зависанию процесса без понимания дальнейшей перспективы ожидания (особенно учитывая наш небольшой поисковый индекс).
Не помог также несколько иной способ форсированного запуска приложения:
$ssa = Get-SPEnterpriseSearchServiceApplication -Identity 781c57c2-56e9-4956-b42f-2a4d1df4e754 $ssa.ForceResume(0x02)
После очередного "окей гугл" была обнаружена ветка обсуждения Cannot un-pause Search Service Application, где предлагалось проверить состояние локального экземпляра службы поиска командлетом Get-SPEnterpriseSearchServiceInstance:
Get-SPEnterpriseSearchServiceInstance -Local | ft -AutoSize
И в нашем случае оказалось, что статус объекта – Provisioning, хотя при штатной работе экземпляра состояние должно быть Online.
Предложенным в обсуждении методом экземпляр был повторно активирован:
$si = Get-SPServiceInstance -Identity 806d0f09-3000-4f96-a734-fd9481d3b7e0 $si.Provision() $si.Update()
Однако, данный шаг не решил проблему статуса приложения службы поиска, который на веб-узле Central Administration по прежнему находился в состоянии Paused.
Но теперь в event-логе Application появилась ежеминутно фиксирующаяся ошибка с Event ID 6482, которой ранее не наблюдалось.
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (806d0f09-3000-4f96-a734-fd9481d3b7e0). Reason: There is no project Portal_Content mounted under gatherer application b77aa267-ef2d-4e48-a803-25f33bf8b997. Technical Support Details: System.InvalidOperationException: There is no project Portal_Content mounted under gatherer application b77aa267-ef2d-4e48-a803-25f33bf8b997. at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize() at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)
По данной ошибке один гражданин из солнечной Индии любезно рассказал историю про решение подобной проблемы через саппорт MS. Понимая, что вариантов у нас не особо много (и следующим будет уже полная переустановка службы поиска), пробуем:
Get-SPEnterpriseSearchServiceApplication | ft -Property Name,Id $ssa = Get-SPEnterpriseSearchServiceApplication 781c57c2-56e9-4956-b42f-2a4d1df4e754 $ssa.RefreshComponents()
Последняя команда выполнилась быстро и без ошибок.
В результате из event-лога Application пропала вышеописанная ошибка с Event ID 6482, а на веб-узле Central Administration статус приложения наконец-то изменился на Running.
Последующее проверочное резервное копирование фермы прошло штатным образом, без каких либо ошибок и предупреждений в лог-файле spbackup.log.
Ситуация разрешилась, но до первопричины произошедшего докопаться не удалось (или не было сильного желания). Беглый анализ event-логов системы на предмет событий, предшествующих первому неудачному бэкапу никаких аномалий в работе сервера не выявил. Никакие обновления для Windows Server/SharePoint Server накануне также не устанавливались, а лог первой неудачной попытки резервного копирования просто обрывался по середине (как раз на начале обработки службы поиска). В общем в очередной раз с нашим горячо любимым SharePoint Server "что-то пошло не так" и, на первый раз, спишем это на "загадку дыры" 
RSS - Записи
Добавить комментарий