Перенос информационной базы 1С с одного сервера на другой — это стандартная процедура, однако она часто сопровождается проблемами в работе веб-сервисов. Ситуация осложняется, когда веб-сервер (IIS или Apache) остается на старом месте, а сервер приложений 1С переезжает на «соседнюю» машину. В этом случае возникает распределенная архитектура, требующая тонкой настройки взаимодействия между узлами. Рассмотрим подробно, как диагностировать и устранить наиболее частую проблему — «Ошибку 500» (Internal Server Error), и что необходимо проверить в первую очередь.
Первым делом проанализируем сетевое взаимодействие между сервером, на котором развернут IIS, и новым сервером приложений 1С. Поскольку теперь это разные физические или виртуальные машины, между ними должен быть открыт ряд специфических портов. По умолчанию кластер 1С:Предприятия использует следующие порты, которые должны быть разрешены в брандмауэре (Firewall) на стороне нового сервера базы данных:
Выясним причину недоступности, выполнив команду telnet с сервера IIS на новый сервер 1С по указанным портам. Если соединение не устанавливается, необходимо добавить соответствующие правила в настройки безопасности Windows или сетевого экрана организации.
Разберем структуру файла default.vrd, который является ключевым звеном в публикации веб-сервиса. Этот файл находится в каталоге, который был указан при публикации базы (обычно в подпапках C:\inetpub\wwwroot\). При переносе базы на другой сервер строка соединения внутри этого файла автоматически не обновляется, если вы не выполнили перепубликацию через конфигуратор.
Откроем файл любым текстовым редактором и найдем атрибут ib. Рассмотрим пример правильного заполнения для серверного варианта:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/BaseName"
ib="Srvr="NewServer1C";Ref="TradeBase";">
<ws>
<point name="ExchangeData" alias="exchange.1cws"/>
</ws>
</point>
Убедимся, что в параметре Srvr указано имя именно нового сервера, а в параметре Ref — точное имя базы в кластере. Обратите внимание на использование экранированных кавычек ". Ошибка в одной букве в этом файле гарантированно приведет к ошибке 500, так как IIS не сможет перенаправить запрос к информационной базе.
Посмотрим на проблему с точки зрения безопасности Windows. Когда веб-сервис принимает запрос, он запускает процесс 1С от имени пользователя, назначенного пулу приложений в IIS. Чаще всего это встроенная учетная запись ApplicationPoolIdentity или IUSR.
Проанализируем ситуацию: на новом сервере 1С этот пользователь может быть неизвестен, или у него может не быть прав на запуск сеанса. Проверим следующие моменты:
wsisapi.dll).IUSR.C:\Windows\Temp, так как компоненты 1С активно используют её для работы временных файлов расширения веб-сервиса.Выясним, соответствует ли разрядность установленной платформы настройкам веб-сервера. Если на сервере с IIS установлена 64-битная платформа 1С, то и пул приложений должен работать в 64-битном режиме. Если же используется 32-битная платформа, необходимо зайти в «Дополнительные параметры» пула приложений в консоли IIS и установить значение True для параметра Разрешить 32-разрядные приложения.
Также проверим «Сопоставления обработчиков» (Handler Mappings). Путь к библиотеке wsisapi.dll должен быть актуальным. Если при переносе базы вы также обновили версию платформы 1С, старый путь в настройках обработчика IIS будет указывать на несуществующую папку старой версии. Рекомендуется выполнить повторную публикацию через «Администрирование» — «Публикация на веб-сервере», чтобы система сама обновила пути в реестре и конфигурационных файлах IIS.
Если вышеперечисленные шаги не помогли, нам нужно получить более детальное описание ошибки, чем стандартная «Internal Server Error». Проделаем следующие действия:
Во-первых, в разделе «Страницы ошибок» (Error Pages) для вашего сайта в IIS выберите действие «Изменить параметры групповой ошибки» и установите переключатель в положение Detailed errors (Подробные сообщения об ошибках). Теперь при обращении через браузер вы увидите конкретный модуль или код ошибки, который вызывает сбой.
Во-вторых, обратимся к «Просмотру событий» Windows (Event Viewer). В разделе «Журналы Windows» — «Приложение» (Application) ищите ошибки от источника 1C:Enterprise или IIS-W3SVC-WP. Там часто фиксируются критические отказы, например, Ошибка загрузки компоненты wsisapi или сообщения о нехватке клиентских лицензий.
Помните, что веб-сервису 1С для работы необходима клиентская лицензия. Если база переехала, убедитесь, что на новом сервере или на сервере с веб-сервисом доступен программный или аппаратный ключ защиты, способный выдать лицензию на сеанс веб-сервиса.
Таким образом, последовательно проверяя сетевые доступы, корректность конфигурационного файла default.vrd, права пользователя пула приложений и соответствие версий wsisapi.dll, мы сможем успешно восстановить работу системы в новой инфраструктуре.