Как устроить клиент-серверную 1С без лишних узлов

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

Из каких слоёв состоит клиент-серверная 1С

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

Три слоя — не обязательно три корпуса и даже не обязательно три виртуальные машины. В небольшой установке сервер приложений и СУБД могут работать на одном компьютере; логически они всё равно остаются разными компонентами. Разнос по отдельным машинам помогает управлять ресурсами и отказами, но добавляет сетевые зависимости, обслуживание и стоимость. Я сначала выясняю, какая операция тормозит и где упирается система: процессор, память, дисковый ввод-вывод, сеть или сама конфигурация. Потом решаю, стоит ли делить роли. Купить три виртуальные машины «на всякий случай» — тоже архитектура, только без ответа на вопрос, какую проблему она решает.

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

Я не называю клиент-серверную схему автоматически более быстрой. Она даёт серверную обработку и инструменты масштабирования, но плохой диск или тяжёлый отчёт никуда не исчезают. Бывает, что один длинный запрос держит пользователей дольше, чем весь обмен между слоями. Поэтому сначала фиксирую исходные симптомы и измерения, а потом сравниваю результат после изменения. Иначе получается любимый вид диагностики: стало медленно — купили сервер — стало медленно, но дороже.

• Клиент — интерфейс и действия пользователя.
• Кластер — серверная логика и соединения.
• СУБД — хранение информационной базы.

Что делает кластер и когда добавлять узлы

Кластер 1С — программная часть между клиентами и СУБД. В базовой конфигурации рабочий сервер кластера может находиться на одном компьютере; документация описывает и масштабирование такого узла, и добавление одного или нескольких рабочих серверов. Это не обещание, что любой кластер из одной машины потянет любое число сотрудников. Производительность зависит от платформы, конфигурации, активных сеансов, фоновых заданий, объёма данных и одновременно выполняемых операций. Число «18 рабочих мест» из нашего условного кейса само по себе не отвечает на вопрос о мощности. Одни сотрудники проводят документы весь день, другие запускают тяжёлые отчёты в один час — нагрузка разная.

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

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

У кластера есть сетевые параметры, и здесь уже уместна точная цифра. В типовой конфигурации менеджер кластера использует TCP-порт 1541; агент сервера по умолчанию использует 1540, а рабочие процессы — диапазон портов, который зависит от настройки. Значения можно менять. Поэтому совет «откройте 1541 и всё заработает» неполон: нужно сверить конфигурацию конкретной установки, адреса узлов и фактические соединения. Не открывайте диапазон на всю сеть автоматически. Разрешайте нужный трафик между нужными системами, затем проверяйте соединение на клиентах и серверах. Порт — не диагноз, а одна проверяемая часть маршрута.

• Сначала измерьте нагрузку рабочего сервера.
• Добавляйте узел только под выявленную задачу.
• Проверьте сетевые порты по настройкам конкретного кластера.

Как выбрать размещение СУБД и данных

В клиент-серверной базе данные хранит СУБД: например, PostgreSQL или Microsoft SQL Server, если конкретные версии и редакции поддерживаются вашей платформой 1С и выбранной операционной системой. Кластер приложений обращается к СУБД, а клиент — к кластеру. Это разделяет роли и даёт администратору отдельные средства управления базой, но не означает, что данные можно копировать как обычный файл во время работы. Для перемещения, резервирования и восстановления применяют штатные механизмы конкретной СУБД и платформы; способ выбирают с учётом целостности и требуемого времени восстановления. Перед изменением схемы хранения я обязательно фиксирую, где лежат данные, журналы, резервные копии и кто имеет доступ к ним.

Физически сервер приложений и сервер базы могут находиться на одной машине либо на разных. Документация 1С прямо допускает оба варианта. Разнос оправдан, когда ресурсы конфликтуют, нужен независимый рост компонентов, отдельное обслуживание или другая граница отказа. Но две виртуальные машины на одном физическом хосте всё ещё зависят от этого хоста и его дисковой подсистемы. Они разделяют настройки и могут помочь с распределением ресурсов, но не превращают один компьютер в отказоустойчивый центр обработки данных. Для «Пятого фасада» я бы сначала собрал показатели нагрузки и проверил хранение базы, а затем сравнил размещение на одном хосте с раздельным вариантом. Назначать конфигурацию по числу рабочих мест — гадание с красивой схемой.

Особое внимание — дискам, но правило «разделить тома — значит устранить конкуренцию за I/O» неверно. Два логических раздела на одном физическом накопителе не становятся независимыми устройствами. Если данные базы и журнал транзакций СУБД активно читаются одновременно, отдельные физические устройства могут снизить конкуренцию, однако результат зависит от контроллера, массива, типа накопителей, кэша и нагрузки. Разнос файлов также усложняет резервное копирование: согласованные копии должны включать все нужные компоненты в один момент времени. В документации PostgreSQL отдельно оговорено, что снимки файловых систем для данных и WAL на разных дисках должны быть согласованными; копировать каталог работающей базы обычным перетаскиванием нельзя.

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

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

Когда в схеме нужен веб-сервер

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

Слова «веб-сервер», «веб-клиент» и «веб-сервис» обозначают разные вещи. Веб-клиент открывает интерфейс 1С в браузере; для него информационную базу публикуют через поддерживаемый веб-сервер. Тонкий клиент тоже может работать через такую публикацию. Веб-сервис — опубликованный интерфейс для обмена данными; его наличие не делает работу в браузере обязательной и не означает, что каждому пользователю нужен внешний доступ. В проекте я прошу описать конкретную операцию: кто подключается, откуда, каким клиентом и к какому интерфейсу. Потом настраиваю только необходимый маршрут и ограничиваю доступ согласно правилам компании.

Для удалённой работы важно не перепутать публикацию с безопасностью. Сам факт, что база открывается по HTTP(S), не решает вопросы аутентификации, прав, сертификата, обновлений веб-сервера и ограничения входящего трафика. Сначала определяют, нужен ли доступ извне вообще; затем выбирают допустимый канал по политике организации, настраивают шифрование и проверяют права пользователей. Не выставляйте административные интерфейсы и служебные порты кластера в интернет. Это не «удобство», а лишняя поверхность атаки. Кластер и СУБД должны быть доступны только тем узлам, которым они реально нужны.

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

• Веб-клиент требует публикации через веб-сервер.
• Тонкий клиент может подключаться напрямую или через веб-сервер.
• Веб-сервис — отдельный сценарий интеграции.

Схема для 18 рабочих мест: сначала замеры

Условная инженерная сметная группа «Пятый фасад» — 18 рабочих мест. Это вводные, а не результат нагрузочного теста. Я бы начал с трёх вопросов: какой режим 1С используется сейчас, в какие часы и на каких операциях появляются задержки, сколько времени допустимо потерять при аварии. Затем проверил бы конфигурацию платформы, поддерживаемую СУБД, серверные лицензии, диски, сеть, резервные копии и порядок обновления. Только после этого выбрал бы размещение. Возможно, роли останутся на одном физическом сервере; возможно, СУБД потребуется вынести. Третью ВМ под веб-сервер создают только при наличии веб-сценария. Универсального рецепта «18 мест — три ВМ» у 1С нет.

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

План внедрения я строю вокруг измерений и восстановления. Сначала делаю инвентаризацию и фиксирую исходные показатели. Затем согласую целевую схему и окно работ, готовлю тестовое восстановление либо отдельный стенд, переношу базу предусмотренным способом, проверяю типовые операции и подключение пользователей. После запуска сравниваю показатели с исходными и оставляю инструкции для администрирования. Резервная копия должна находиться отдельно от рабочей базы и проходить проверку восстановления. «Задание завершилось без ошибки» — ещё не доказательство, что данные удастся вернуть. Для 1С полезна и отдельная инструкция о переносе базы DT, но формат резервирования выбирают под тип базы и механизм СУБД.

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

• Зафиксировать нагрузку и симптомы.
• Проверить лицензии, накопители и сеть.
• Сравнить размещение по измерениям.
• Проверить восстановление до запуска.

Точки отказа, резервные копии и сеть

Один сервер — одна очевидная точка отказа, даже если на нём крутятся виртуальные машины с разными ролями. Резервирование отдельных компонентов может снизить вероятность некоторых отказов, но не заменяет резервную копию и не устраняет общие точки отказа. Я раскладываю риски по компонентам и спрашиваю, какой простой допустим: час, рабочий день или больше. Ответ определяет, нужна ли запасная площадка, какие копии хранить отдельно и сколько ресурсов вкладывать в автоматизацию восстановления. Нельзя обещать непрерывную работу, просто перечислив оборудование в смете.

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

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

Границы ответственности фиксируют до аварии. Один человек может сопровождать всё, но он должен знать, кто выдаёт доступы, кто контролирует копии, кто обновляет сервер и кто подтверждает тест восстановления. В журналах полезны единые дата и время, чтобы связать событие на клиенте, веб-сервере, кластере и СУБД. После изменений проверяют не только запуск службы, но и вход пользователя, открытие базы, запись, фоновые задания и резервное копирование. Если менялась сеть — проверяют разрешённые соединения; если менялась СУБД — восстановление. Я предпочитаю короткий список проверок длинному документу, который никто не открывает.

• Оцените последствия отказа хоста.
• Храните копии отдельно от рабочей системы.
• Периодически проверяйте восстановление.
• Сверяйте фактические порты и маршруты.

Частые вопросы