Вопрос о том, нужно ли разносить сервер приложений «1С:Предприятие» и сервер систем управления базами данных (СУБД, таких как MS SQL Server или PostgreSQL) на разные физические машины, остается одним из самых обсуждаемых в среде системных администраторов и разработчиков. С одной стороны, разделение серверов пропагандируется как стандарт масштабируемости. С другой стороны, совмещенная схема обладает уникальными технологическими преимуществами, которые теряются при переносе служб на разные хосты. В этой статье мы подробно разберем, в каких случаях разделение действительно необходимо, когда оно способно навредить производительности и как правильно настроить систему в обоих сценариях.
Прежде чем приступать к масштабным реформам ИТ-инфраструктуры, проанализируем текущие показатели нагрузки нашей информационной системы. Практический опыт эксплуатации систем на платформе 1С позволяет выделить четкие ориентиры:
Самым сильным аргументом против разделения серверов (при условии, что серверное оборудование справляется с нагрузкой) является возможность использования локального протокола обмена данными — Shared Memory (общая память).
Выясним причину высокой скорости работы этого протокола. Когда сервер приложений 1С и СУБД (например, MS SQL Server) работают в рамках одной операционной системы Windows, они могут обмениваться пакетами данных напрямую через оперативную память, минуя сетевые протоколы, разбор заголовков пакетов и стек TCP/IP. Это самый быстрый способ межпроцессного взаимодействия (IPC) из всех существующих.
Рассмотрим подробнее, как включить и гарантировать работу этого механизма. По умолчанию СУБД использует автоопределение. Однако, чтобы принудительно заставить платформу 1С общаться с MS SQL Server по протоколу Shared Memory, при создании и настройке информационной базы в поле имени сервера баз данных необходимо использовать префикс lpc: (например, lpc:ИмяВашегоSQLСервера).
Посмотрим на пример программного создания подключения к такой базе:
// Пример строки соединения для принудительного использования протокола Shared Memory
СтрокаСоединения = "Srvr=""lpc:MyServer1C"";Ref=""Accounting_Base"";";
Подключение = Новый COMОбъект("V81.Application");
Попытка
ОткрытаБаза = Подключение.Connect(СтрокаСоединения);
Сообщить("Успешно подключено через Shared Memory!");
Исключение
Сообщить("Ошибка подключения: " + ОписаниеОшибки());
КонецПопытки;
Использование Shared Memory способно дать чистый прирост производительности СУБД в тестах (например, тесте Гилева) на 10–15% по сравнению с передачей тех же объемов данных по сети.
Когда мы разносим сервер 1С и СУБД на разные физические компьютеры, единственным способом связи между ними становится сеть TCP/IP. Здесь в силу вступает архитектурная особенность платформы 1С:Предприятие, которую специалисты называют «болтливостью» (chattering) запросов.
Суть проблемы заключается в том, что для выполнения даже одной простой бизнес-операции (например, проведения реализации товаров) сервер приложений 1С может совершать сотни и тысячи последовательных мелких запросов к базе данных. С каждым запросом СУБД возвращает небольшие порции данных.
При разделенной схеме работы пропускная способность сети (даже если у вас проложен 10-гигабитный кабель) уходит на второй план. Решающее значение приобретает латентность сети (задержка пакета, ping). Проанализируем ситуацию: если задержка сети на один запрос составляет всего 1 миллисекунду, то при совершении 5000 последовательных запросов в рамках одной транзакции пользователь получит чистую задержку в 5 секунд только на ожидание прохождения сигнала по сетевому кабелю!
Поэтому, если вы приняли решение разнести серверы, обязательно соблюдайте жесткие требования к сетевой инфраструктуре:
Разберем по шагам популярную, но крайне опасную ошибку системных администраторов. Часто в целях «наведения порядка» сервер приложений 1С и сервер СУБД размещают в разных виртуальных машинах (ВМ), но запускают их на одном физическом сервере (гипервизоре).
Почему это решение является наихудшим с точки зрения производительности?
Shared Memory, так как операционные системы у виртуальных машин изолированы.Если ваши серверы виртуализированы и запущены на одном физическом железе, держите сервер 1С и СУБД внутри одной виртуальной машины. Это позволит использовать локальный протокол общей памяти и избавит процессор от холостой работы по эмуляции виртуальной сети.
Если вы решили оставить обе роли на одном мощном многопроцессорном физическом сервере, вам необходимо учитывать архитектуру распределения памяти NUMA (Non-Uniform Memory Access).
Современные серверы имеют два или более физических процессора (сокета). У каждого процессора есть «своя» выделенная область оперативной памяти, подключенная напрямую к его контроллеру памяти. Если процессу, выполняющемуся на процессоре №1, требуется обратиться к данным, лежащим в оперативной памяти процессора №2, происходит медленный межпроцессорный запрос, сильно снижающий общую скорость системы.
Когда сервер 1С и СУБД работают на одной машине, они начинают хаотично использовать общую память на разных NUMA-узлах. Чтобы этого избежать, настроим жесткую привязку (affinity) процессов:
Такая изоляция исключит перекрестные обращения к памяти и обеспечит стабильно высокую производительность обеих систем.
При совместной работе серверов жесткие диски испытывают двойную нагрузку. В старых конфигурациях часто использовались массивы SAS RAID 10. Помните: использование массивов уровня RAID 0 категорически недопустимо из-за полного отсутствия отказоустойчивости (выход из строя любого диска уничтожит всю базу данных без возможности восстановления).
Сегодня стандартом производительности для баз данных стали твердотельные накопители корпоративного класса NVMe SSD. Они обеспечивают сотни тысяч операций ввода-вывода в секунду (IOPS) и практически нивелируют дисковые задержки. Если вы используете быстрые накопители NVMe, дисковая подсистема перестает быть узким местом, что позволяет дольше сохранять совмещенную схему работы без необходимости физического разделения серверов.
Подводя итог, сформулируем алгоритм действий для системного администратора по выбору архитектуры сервера 1С:
Shared Memory.