Серверная инфраструктура 1С: как спроектировать и развернуть рабочую схему

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

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

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

Из чего состоит серверная инфраструктура 1С

В клиент-серверном варианте 1С обычно участвуют три основных уровня:

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

В простой схеме все может быть размещено на одном сервере: и сервер 1С, и СУБД — например, SQL Server или PostgreSQL. Такой вариант подходит для небольших баз и ограниченной нагрузки. Но по мере роста пользователей и объема данных роли часто разделяют: сервер 1С размещают отдельно, сервер СУБД — отдельно. Это упрощает масштабирование и диагностику.

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

Основные процессы кластера 1С

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

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

Один сервер или разделение ролей

Один из первых вопросов при проектировании — размещать ли все компоненты на одной машине или сразу разделять роли. Универсального ответа нет. Все зависит от нагрузки, бюджета, требований к доступности и планов роста.

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

Разделение ролей стоит рассмотреть, если база активно растет, пользователей становится больше, появляются тяжелые отчеты, обмены с сайтом или CRM, регламентные задания мешают дневной работе, а простои уже критичны для бизнеса. В этом случае сервер 1С и СУБД лучше размещать отдельно.

Как оценивать ресурсы для сервера 1С

Главная ошибка при подборе сервера — считать только количество пользователей. В реальности два проекта с одинаковым числом пользователей могут создавать совершенно разную нагрузку. Одна компания в основном вводит документы и печатает счета, другая формирует тяжелые отчеты, обменивается с сайтом, использует CRM-интеграции и запускает сложные регламентные задания.

При оценке ресурсов нужно учитывать:

• количество одновременно работающих пользователей;
• размер информационной базы и скорость ее роста;
• тип конфигурации: Бухгалтерия, Управление торговлей, ERP, ЗУП, отраслевые решения;
• наличие обменов с сайтом, CRM, маркетплейсами, банками и внешними сервисами;
• количество и тяжесть регламентных заданий;
• требования к резервному копированию и допустимому простою;
• планируемый рост пользователей и данных.

Поэтому таблицы вида «до 50 пользователей — столько-то ядер и столько-то памяти» можно использовать только как грубую отправную точку. Окончательный подбор ресурсов лучше делать по фактической нагрузке или хотя бы по описанию бизнес-процессов.

Процессор, память и диски: что важнее

Для 1С важен баланс ресурсов. Нельзя сказать, что производительность зависит только от процессора или только от дисков. Узким местом может стать любой компонент.

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

Оперативная память нужна и серверу 1С, и СУБД, и операционной системе. Если сервер 1С и база данных находятся на одной машине, память нужно распределять особенно аккуратно. SQL Server или PostgreSQL могут активно использовать RAM для кэша, а рабочие процессы 1С — для пользовательских сеансов и фоновых операций.

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

Если сервер проектируется на VPS или VDS, важно смотреть не только на количество vCPU и объем RAM, но и на тип дисков, гарантированность ресурсов, политику резервного копирования и возможность быстро увеличить конфигурацию при росте нагрузки.

Операционная система и СУБД

Сервер 1С может работать как на Windows Server, так и на Linux-дистрибутивах, поддерживаемых используемой версией платформы 1С. Выбор зависит от опыта администратора, используемой СУБД, требований компании и существующей инфраструктуры.

Windows Server или Linux

Windows Server часто выбирают там, где уже используется Microsoft-инфраструктура: Active Directory, RDS, привычные инструменты администрирования, SQL Server. Такой вариант проще для команд, которые много лет работают с Windows-серверами.

Linux часто рассматривают для инфраструктур с PostgreSQL, когда важно снизить стоимость лицензий ОС и получить гибкую серверную среду. Но этот вариант требует опыта администрирования Linux: systemd, права, журналы, обновления, сетевые настройки, безопасность.

Не стоит выбирать ОС только по принципу «дешевле» или «привычнее». Лучше учитывать, кто будет обслуживать сервер, какие специалисты есть в команде, какая СУБД используется и насколько быстро можно будет диагностировать проблему в рабочей эксплуатации.

SQL Server или PostgreSQL

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

На практике для 1С чаще всего рассматривают Microsoft SQL Server и PostgreSQL. У каждого варианта есть свои особенности.

Выбирать СУБД только по стоимости неправильно. Бесплатная лицензия PostgreSQL не отменяет требования к администрированию. SQL Server, в свою очередь, может быть привычнее для Windows-команд, но требует учета лицензий и правильной настройки. В обоих случаях база 1С нуждается в регулярном обслуживании.

Если компания уже использует SQL Server, умеет его администрировать и имеет лицензии, логично рассматривать SQL Server. Если инфраструктура строится на Linux, есть компетенции по PostgreSQL и важно снизить лицензионные расходы, можно рассматривать PostgreSQL. Главное — не выбирать СУБД «по совету из интернета» без учета своей эксплуатации.

Сеть и порты сервера 1С

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

В типовой клиент-серверной схеме 1С используются следующие порты:

Открывать эти порты «наружу» в интернет не нужно. Они должны быть доступны только внутри доверенной сети: между клиентами, сервером 1С, СУБД и административными узлами. Для внешнего доступа лучше использовать VPN, терминальный сервер, веб-клиент или другие контролируемые схемы.

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

Лицензирование, резервное копирование и мониторинг

Лицензирование 1С

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

Главное правило — не оставлять лицензирование «на последний шаг». Бывает, что сервер уже установлен, база перенесена, пользователи готовы работать, но вход невозможен из-за ошибки получения лицензии. В результате технически готовая инфраструктура простаивает.

При планировании нужно проверить:

• какие лицензии уже есть у компании;
• достаточно ли клиентских лицензий для одновременных пользователей;
• нужна ли серверная лицензия 1С;
• где будут размещены программные лицензии или аппаратные ключи;
• как лицензии будут восстанавливаться при переносе сервера или сбое;
• кто отвечает за хранение регистрационных данных и PIN-кодов.

Если используются программные лицензии, особенно важно учитывать привязку к параметрам среды. При переносе виртуальной машины, изменении оборудования или восстановлении из резервной копии может потребоваться повторная активация. Поэтому перед миграцией нужно заранее подготовить регистрационные данные и проверить доступность резервных PIN-кодов.

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

Резервное копирование

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

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

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

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

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

Мониторинг и обслуживание

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

Минимально стоит контролировать:

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

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

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

Безопасность серверной 1С

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

Базовые меры безопасности:

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

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

Типичные ошибки при развертывании серверной 1С

Практический чек-лист перед запуском

Перед вводом серверной 1С в эксплуатацию стоит пройтись по короткому чек-листу.

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

Этот чек-лист не заменяет проектирование, но помогает не пропустить базовые вещи. В небольших проектах именно такие «мелочи» чаще всего становятся причиной простоев.

Заключение

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

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

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

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

Кратко

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