Вопрос разделения ролей сервера приложений 1С:Предприятие и СУБД (MS SQL Server, PostgreSQL и др.) является одним из самых дискуссионных в среде системных администраторов и архитекторов систем 1С. С одной стороны, разделение кажется логичным шагом для масштабирования, с другой — оно вносит дополнительные задержки в работу системы. В этой статье мы подробно разберем, в каких случаях стоит переходить к многосерверной архитектуре, а когда лучше оставить всё на одной машине.
Рассмотрим механизм взаимодействия сервера 1С и СУБД. Когда они установлены на одном физическом или виртуальном сервере, система может использовать протокол Shared Memory (общая память). Проанализируем ситуацию: в этом режиме данные передаются между процессами rphost и процессом СУБД напрямую через оперативную память, минуя сетевой стек операционной системы. Это обеспечивает максимально возможную скорость обмена данными и минимальные задержки (latency).
Как отмечается в обсуждении, после появления и широкого внедрения этой технологии смысл разделения серверов для малых и средних баз во многом исчез. При переходе на разные серверы система вынуждена использовать протокол TCP/IP. Даже в рамках 10-гигабитной сети накладные расходы на упаковку/распаковку пакетов и время прохождения сигнала по физической среде приводят к падению производительности. По тестам Гилева, это падение в "попугаях" может быть весьма заметным, хотя в реальной работе пользователи могут этого не ощутить при правильной настройке сети.
Выясним причину, по которой разделение всё же может быть полезным. Сервер 1С и СУБД предъявляют диаметрально противоположные требования к аппаратному обеспечению:
Когда обе роли совмещены, возникает проблема Resource Contention (борьба за ресурсы). СУБД по своей природе стремится занять всю доступную память. Если не ограничить аппетиты SQL-сервера жестко в настройках, он может вытеснить процессы rphost в файл подкачки (свопинг), что приведет к катастрофическому замедлению всей системы. Разделение серверов позволяет подобрать идеальную конфигурацию "железа" под каждую роль независимо.
Если мы всё же принимаем решение о разделении, необходимо проанализировать сетевую среду. Для 1С критична не столько пропускная способность (количество мегабит в секунду), сколько время отклика (ping). Разберем по шагам, как минимизировать негативный эффект от разделения:
TCP/IP даже на локальной машине. Для активации Shared Memory при совместном размещении используйте (local) или точку . в качестве имени сервера SQL.Посмотрим на ситуацию с точки зрения долгосрочной эксплуатации. Разделение — это первый и обязательный шаг к созданию кластера 1С. К одной мощной СУБД можно подключить несколько серверов приложений, распределяя нагрузку между ними. Это также повышает безопасность: базу данных можно спрятать в глубокий сегмент сети, закрытый от прямого доступа пользователей и интернета, оставив снаружи только сервер приложений.
С точки зрения обслуживания, раздельные серверы позволяют выполнять регламентные работы (обновление ОС, перезагрузка) независимо друг от друга. Например, вы можете перезагрузить сервер приложений 1С для очистки кеша, не прерывая работу SQL-сервера, на котором могут крутиться другие важные базы или аналитические системы компании.
Рассмотрим пример из практики, упомянутый в обсуждении. Организация использует следующую схему:
Такая схема позволяет гибко управлять ресурсами и версиями платформы, хотя и вносит небольшую просадку в производительности из-за виртуализации сети и протокола TCP/IP. Для проброса ключей защиты в виртуальную среду в таких случаях используются программные решения или USB-over-IP серверы.
Проанализировав все факторы, можно сделать следующие выводы:
Совместное размещение (Single Server):
Shared Memory.Раздельное размещение (Multi-Server):
При выборе всегда стоит опираться на замеры производительности конкретно в вашей инфраструктуре, используя нагрузочное тестирование и тесты Гилева, так как "синтетика" не всегда отражает реальные ощущения пользователей от работы с интерфейсом.