Конфигуратор сервера 1С: какие данные подготовить заранее

Даже одинаковые 50 пользователей могут создавать совершенно разную нагрузку на 1С: в одной компании они оформляют несколько документов в час, в другой одновременно запускают тяжелые отчеты, обмены и фоновые задания. Поэтому ввод в конфигуратор только числа сотрудников часто приводит либо к нехватке ресурсов, либо к дорогому запасу, который останется невостребованным. Разберем, какие показатели собрать по информационным базам, рабочим сценариям, СУБД и планам роста, чтобы расчет сервера 1С опирался на реальную нагрузку.

Какие данные нужно подготовить заранее

Формулировки вроде «в компании работают 80 человек» или «нужен сервер для 1С:ERP» недостаточно для точного расчета. Важнее понять, сколько пользователей действительно работают одновременно, какие операции они выполняют и в какие часы нагрузка достигает максимума. Например, проведение документов и закрытие месяца предъявляют к системе совсем разные требования, хотя число сотрудников не меняется.

Чтобы конфигуратор сервера для 1С не строил расчет на предположениях, исходные данные лучше собрать по пяти группам:

1. Указать общее число пользователей и отдельно количество одновременных активных сеансов в обычные часы и пиковые периоды.

2. Зафиксировать конфигурацию и версию платформы 1С, число информационных баз, используемую СУБД, текущий объем каждой базы и темпы ее роста.

3. Описать рабочие сценарии: проведение документов, формирование тяжёлых отчётов, регламентные задания, обмены между базами, веб-сервисы и внешние интеграции.

4. Снять показатели действующей системы в часы пик: загрузку процессоров, потребление оперативной памяти, задержку дисковой подсистемы и длину очереди запросов к хранилищу.

5. Обозначить инфраструктурные ограничения: физический сервер или виртуальная среда, совместное либо раздельное размещение кластера 1С и СУБД, требования к резервированию и горизонт планируемого роста.

Даже приблизительные замеры за несколько рабочих дней полезнее абстрактного запаса «на будущее». Они показывают не только масштаб системы, но и характер нагрузки, от которого зависит соотношение частоты процессора, числа ядер, объема RAM и производительности накопителей.

Критерии технического решения

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

На практике техническое решение удобно проверять по трём группам критериев:

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

2. Оперативная память рассчитывается суммарно для кластера 1С, СУБД, операционной системы и кеша, причем под нагрузкой система не должна переходить к активному использованию файла подкачки.

3. Дисковая подсистема оценивается не только по объему и скорости последовательного чтения, но и по задержке, IOPS и устойчивости при одновременном чтении и записи.

Для практической сверки рассчитанных параметров с доступными серверными платформами можно использовать конфигуратор сервера для 1С от компании Dorfa, сравнивая варианты по процессору, числу каналов памяти, накопителям и возможностям расширения.

Архитектура также влияет на итоговый расчет. При совместном размещении кластера 1С и СУБД их потребности в CPU, RAM и дисковых ресурсах складываются. Разнесение ролей упрощает масштабирование и изоляцию нагрузки, но повышает требования к сети. Запас лучше выражать конкретно: например, ростом числа активных сеансов на 20% и объема базы на 30% в течение двух лет, а не формулировкой «на перспективу».

Компромиссы по производительности, риску и стоимости

Самая мощная конфигурация не всегда оказывается самой рациональной. Избыточные ресурсы увеличивают бюджет, но не гарантируют ускорения 1С: причиной медленной работы могут быть неоптимальные запросы, блокировки, фоновые задания или неправильные настройки СУБД.

Чтобы не переплачивать за характеристики, которые не решают реальную задачу, при подборе стоит оценить три ключевых компромисса:

1. Частота процессора или количество ядер. Для плохо распараллеливаемых операций важна производительность одного ядра, тогда как большое число ядер требуется при высокой параллельной нагрузке. Дополнительные процессоры также могут увеличить стоимость лицензирования СУБД, если оно зависит от вычислительных ресурсов.

2. Объем памяти или скорость накопителей. RAM позволяет удерживать рабочие данные в кеше и сокращает обращения к дискам, но после размещения активного набора данных эффект от дальнейшего увеличения памяти снижается. NVMe уменьшает задержки, однако не компенсирует ошибки в запросах и обслуживании базы.

3. Экономия или отказоустойчивость. RAID 10, резервные блоки питания, hot spare и запасные компоненты повышают стоимость сервера, зато уменьшают вероятность длительного простоя при одиночном отказе.

Выбор зависит от роли системы. Для некритичной базы может быть достаточно одного сервера и регулярно проверяемых резервных копий. Если остановка 1С блокирует бухгалтерию, склад, продажи или производство, расходы нужно сравнивать уже со стоимостью часа простоя. В этом случае резервирование и заданные показатели RPO и RTO важнее дополнительного процессора, который большую часть времени останется незагруженным.

Практическая схема выбора

Подбор сервера для 1С лучше вести не от каталога оборудования, а от последовательных технических решений. Тогда на каждом этапе понятно, почему выбран конкретный процессор, объем памяти или тип накопителей и какие данные еще требуется уточнить.

Практический алгоритм можно выстроить из пяти шагов:

1. Определить источник данных. Если 1С уже работает, собрать метрики в обычные дни и во время пиков. Для нового внедрения нагрузку моделируют по числу одновременных пользователей, конфигурации, типовым операциям и фоновым заданиям.

2. Выбрать архитектуру. При умеренной нагрузке кластер 1С и СУБД можно разместить на одном сервере. При росте базы, высокой параллельности или жёстких требованиях к доступности роли лучше рассчитывать раздельно.

3. Найти доминирующую нагрузку. Медленное проведение документов указывает на необходимость проверить процессор и блокировки, тяжелые отчеты — CPU и RAM, а задержки при массовой записи — дисковую подсистему.

4. Задать измеримый запас. В расчет включают прогноз роста числа активных сеансов, объёма базы и интенсивности обменов на два-три года, а не условное удвоение всех ресурсов.

5. Проверить конфигурацию. До закупки желательно воспроизвести пиковый сценарий на тестовой базе и сравнить время ключевых операций с согласованными требованиями.

Результатом такого расчета становится не просто спецификация сервера, а зафиксированная логика выбора: текущая нагрузка, допустимые пределы, резерв и точки будущего расширения. Если показатели меняются, конфигурацию можно пересчитать без полного повторения проекта.

Подведем итог

Точный расчет сервера 1С начинается не с выбора процессора, а со сбора данных о параллельной нагрузке, рабочих сценариях, размере баз и требованиях к доступности. Замеры действующей системы и прогноз роста позволяют связать каждый компонент с конкретной задачей и отказаться от неопределённого запаса «на будущее».

Конфигуратор помогает сравнить варианты, но окончательное решение нужно проверять по времени ключевых операций, устойчивости в часы пик и возможности дальнейшего расширения. Такой расчёт снижает риск как нехватки ресурсов, так и неоправданной переплаты.