Иногда одной установкой сервера 1С на компьютере обойтись неудобно. Например, нужно разделить рабочую и тестовую среду, поднять отдельный контур для обновления, проверить новую версию платформы, изолировать базы разных подразделений или временно перенести часть нагрузки на тот же физический сервер. В таких случаях администратор задается вопросом: можно ли установить два сервера 1С на один компьютер и как сделать это так, чтобы службы, порты и кластеры не конфликтовали друг с другом.
Короткий ответ: да, несколько серверных экземпляров 1С можно разместить на одной машине, но только при аккуратном разделении параметров. У каждого экземпляра должны быть свои порты, свой каталог служебных данных, отдельная служба или отдельный системный unit, понятное имя, свой диапазон портов рабочих процессов и продуманная схема администрирования. Если просто запустить второй сервер «как первый», он попытается занять те же порты и тот же каталог, что приведет к ошибкам запуска или нестабильной работе.
Ниже разберем практический подход: что подготовить до установки, какие параметры развести, как выглядит схема на Windows и Linux, какие проверки выполнить после запуска и в каких случаях лучше не ставить два сервера 1С на один компьютер, а выбрать виртуализацию или отдельный сервер.
Когда нужны два сервера 1С на одном компьютере
Чаще всего такую схему используют не для постоянной промышленной эксплуатации, а для аккуратного разделения задач. Например, на одном физическом сервере уже работает основной кластер 1С, а рядом нужно поднять тестовый контур для обновления конфигурации. Или компания хочет проверить новую версию платформы, не затрагивая рабочие базы. Еще один вариант — временный переходный период, когда старый и новый серверы должны работать параллельно до завершения миграции.
Также два экземпляра могут потребоваться для разных правил обслуживания. Один кластер обслуживает рабочие базы и перезапускается строго по регламенту, второй используется для разработки, тестирования отчетов, обменов или интеграций. При этом администратор может отдельно управлять службами, логами, каталогами кластера и портами подключения.
Но важно понимать ограничение: два сервера 1С на одном компьютере все равно делят общие ресурсы — процессор, оперативную память, диск, сеть и иногда один сервер СУБД. Если рабочие базы уже сильно нагружают машину, добавление второго кластера может ухудшить производительность. Поэтому перед установкой нужно оценить нагрузку, объем памяти, скорость диска, резервное копирование и требования пользователей.
Что обязательно разделить
Главная техническая идея проста: каждый серверный экземпляр 1С должен быть самостоятельным. Он не должен использовать те же порты, тот же каталог служебных данных и то же имя службы, что первый. Если эти параметры пересекаются, второй сервер либо не запустится, либо будет мешать первому.
| Параметр | Зачем разделять | Пример подхода |
|---|---|---|
| Порт агента сервера | По нему клиенты и администраторы обращаются к серверному агенту. | Первый экземпляр использует стандартный порт, второй получает другой свободный порт. |
| Порт менеджера кластера | Нужен для регистрации и взаимодействия внутри кластера. | Для второго кластера задается отдельный порт регистрации. |
| Диапазон рабочих процессов | Рабочие процессы 1С используют порты из выделенного диапазона. | Диапазоны первого и второго сервера не должны пересекаться. |
| Каталог служебных данных | В нем хранятся данные кластера, настройки и служебная информация. | Для второго экземпляра создают отдельный каталог, например отдельный srvinfo. |
| Имя службы | Операционная система должна различать два серверных процесса. | Службам дают понятные разные имена: рабочий контур, тестовый контур, старая версия, новая версия. |
Для типового сервера 1С часто встречается стандартная схема портов: агент сервера на одном порту, менеджер кластера на соседнем, рабочие процессы в выделенном диапазоне, а сервер администрирования использует свой порт. Для второго экземпляра обычно выбирают другой набор, например с тем же шагом, но на свободных значениях. Конкретные номера нужно проверять по установленной версии платформы, настройкам организации, правилам безопасности и занятости портов на сервере.
Подготовка перед установкой
Перед любыми изменениями сделайте резервную копию информационных баз, служебных каталогов и настроек. Если сервер рабочий, заранее согласуйте окно обслуживания: установка платформы, перезапуск служб, изменение firewall и проверка подключения могут повлиять на пользователей. Также стоит зафиксировать текущую схему: какая версия платформы установлена, где находится каталог кластера, какие порты заняты, какие базы подключены, какие службы работают и от какой учетной записи они запускаются.
Далее проверьте свободные порты. На сервере могут уже работать СУБД, веб-сервер, агенты мониторинга, резервное копирование, терминальные службы и другие сервисы. Выбранные порты для второго экземпляра 1С не должны пересекаться ни с первым сервером 1С, ни с другими приложениями. После выбора портов их нужно открыть в брандмауэре, если к серверу будут подключаться клиенты или администраторы с других компьютеров.
Отдельно проверьте учетную запись службы. В небольших тестовых контурах иногда используют локальную системную учетную запись, но для промышленной среды лучше продумать права более аккуратно. Учетная запись должна иметь доступ к каталогу служебных данных, журналам, временным каталогам и сетевым ресурсам, если они используются. При этом не стоит давать ей лишние административные права без необходимости.
Схема установки на Windows
На Windows сервер 1С обычно работает как служба. Если на компьютере уже есть один серверный экземпляр, для второго нужно установить или зарегистрировать отдельную службу с другим набором параметров. Важно не перезаписать существующую службу и не указать тот же каталог служебных данных. Если устанавливаются разные версии платформы, дополнительно проверяют путь к нужному исполняемому файлу конкретной версии.
Общая логика выглядит так:
Команда регистрации службы зависит от версии платформы и принятого способа установки. В документации и на практике используются параметры агента сервера, порта, порта регистрации, диапазона рабочих процессов и каталога служебных данных. Пример логики: для первого экземпляра оставляют стандартные параметры, а для второго задают другой порт агента, другой порт регистрации, другой диапазон рабочих процессов и отдельный каталог. Перед копированием команд обязательно проверьте синтаксис для вашей версии 1С:Предприятия и выполните тест на непроизводственном сервере.
После регистрации службы проверьте ее свойства в оснастке служб Windows: имя, путь к исполняемому файлу, параметры, учетную запись запуска, тип запуска и состояние. Если служба сразу останавливается, чаще всего причина в занятых портах, недоступном каталоге служебных данных, ошибке в параметрах запуска или недостаточных правах учетной записи.
Схема установки на Linux
На Linux задача решается похожим образом, но вместо служб Windows обычно используются отдельные systemd units. Для второго экземпляра создают отдельный unit-файл, задают свой каталог служебных данных, свои порты и свою учетную запись или группу прав. Если используются разные версии платформы, unit должен ссылаться на правильный путь к исполняемому файлу нужной версии.
При настройке на Linux важно проверить права на каталоги, владельца файлов, SELinux или AppArmor при их использовании, правила firewall и журнал systemd. Если служба не стартует, диагностика обычно начинается с просмотра статуса unit, системного журнала и логов 1С. Как и на Windows, чаще всего проблемы связаны с портами, правами на каталог или ошибками в параметрах запуска.
Если второй сервер 1С нужен для тестирования обновлений, полезно сразу разделить не только служебные каталоги, но и каталоги логов, временные файлы, резервные копии и правила мониторинга. Тогда администратор сможет быстро понять, где возникла ошибка: в рабочем контуре или в тестовом.
Как подключаться к двум серверам
После запуска второго экземпляра нужно проверить подключение. В консоли администрирования сервера 1С или в инструментах администрирования указывают адрес сервера и порт нужного экземпляра. Если используется сервер администрирования, для него также должен быть выбран отдельный порт. Важно, чтобы администраторы и разработчики не путали рабочий и тестовый контуры, поэтому лучше заранее договориться о понятных именах, описаниях и правилах подключения.
Клиентские подключения к информационным базам также должны указывать правильный сервер. Если две базы называются похоже, а серверы находятся на одном компьютере, риск ошибки возрастает. В списке информационных баз стоит использовать понятные названия: рабочая база, тестовая база, база обновления, архивная база. Для пользователей лучше не показывать лишние тестовые базы, чтобы случайно не начать работу не в том контуре.
Если используются лицензии 1С:Предприятие 8, нужно также проверить лицензионную схему. Размещение двух серверов на одном компьютере не отменяет требований к лицензиям, серверным компонентам, клиентским подключениям и правам использования программного продукта. На этапе планирования лучше сразу уточнить, какие лицензии есть у организации и хватает ли их для выбранной архитектуры.
Типовые ошибки
Первая ошибка — одинаковые порты. Второй сервер не может занять порт, который уже слушает первый сервер 1С или другой сервис. В результате служба не запускается, клиенты не подключаются или администрирование работает нестабильно. Перед установкой нужно проверять занятые порты и фиксировать выбранные значения в документации.
Вторая ошибка — общий каталог служебных данных. Два серверных экземпляра не должны одновременно использовать один и тот же каталог кластера. Это может привести к повреждению служебной информации, конфликтам настроек и сложной диагностике. Для каждого экземпляра нужен свой каталог, понятное имя и отдельные права доступа.
Третья ошибка — смешивание версий без плана. Если на одном компьютере запускаются разные версии платформы 1С, нужно понимать совместимость информационных баз, расширений, внешних компонент, тонкого клиента, веб-сервера и фоновых заданий. Тестовый сервер для обновления должен быть отделен от рабочего не только портами, но и регламентом: кто имеет доступ, какие базы можно обновлять, как возвращаться назад при ошибке.
Четвертая ошибка — отсутствие мониторинга. Администратор может успешно запустить две службы, но не настроить наблюдение за памятью, процессором, диском, журналами регистрации и количеством рабочих процессов. В результате тестовый контур неожиданно забирает ресурсы у рабочего. Если два сервера 1С работают на одной машине, мониторинг становится особенно важным.
Когда лучше выбрать другой вариант
Два сервера 1С на одном компьютере удобны для тестов, временной миграции и небольших контуров, но не всегда подходят для постоянной эксплуатации. Если обе среды критичны для бизнеса, лучше рассмотреть отдельные виртуальные машины или отдельные физические серверы. Это упростит резервное копирование, обновления, безопасность, мониторинг и распределение ресурсов.
Если цель — проверить обновление конфигурации, часто достаточно тестовой базы на отдельном серверном экземпляре или виртуальной машине. Если цель — разделить пользователей разных подразделений, возможно, правильнее настроить отдельные кластеры, роли, публикации или серверы приложений. Если задача связана с высокой нагрузкой, то установка второго сервера на ту же машину не решит проблему производительности, а может усилить ее.
Хороший критерий простой: если отказ одного компьютера остановит оба критичных контура, это риск. Для тестовой среды такой риск допустим, для рабочей и резервной одновременно — обычно нет. Поэтому архитектуру нужно выбирать не только по принципу «получится ли установить», но и по требованиям бизнеса к надежности.
Разные версии платформы на одной машине
Отдельный сценарий — когда на одном компьютере нужно держать две разные версии платформы 1С. Например, рабочий контур еще остается на проверенной версии, а тестовый уже используется для обновления конфигурации и проверки совместимости. В такой ситуации важно не только развести порты, но и четко понимать, какой экземпляр запускается из какого каталога платформы. Иначе можно случайно подключить тестовую базу к старому серверу или рабочую базу к новой версии без подготовленного плана обновления.
Перед запуском разных версий стоит проверить совместимость конфигурации, расширений, внешних компонент, обработок, фоновых заданий, обменов, веб-публикаций и клиентских приложений. Если пользователи подключаются тонким клиентом, нужно понимать, какая версия клиента будет использоваться. Если есть COM-соединения, внешние сервисы или интеграции с сайтом, складом, CRM, телефонией или обменами с контрагентами, их тоже нужно включить в тестирование.
Для обновлений удобно использовать правило: рабочий контур не трогаем, пока тестовый не прошел проверку. На втором сервере поднимается копия базы, выполняется обновление платформы и конфигурации, проверяются ключевые документы, регламентные задания, отчеты, обмены и права пользователей. Только после этого составляется план перехода рабочей базы. Такой подход особенно полезен, если у компании есть доработанная конфигурация или критичные обмены.
Резервное копирование и журналы
Когда на одном компьютере работают два сервера 1С, резервное копирование нужно проверить особенно внимательно. Недостаточно сохранять только информационные базы в СУБД. Нужно понимать, где находятся служебные каталоги каждого экземпляра, какие журналы регистрации ведутся, где лежат технологические журналы, какие настройки кластера нужно восстановить при аварии и как быстро можно поднять контур после сбоя.
Для рабочего сервера резервное копирование обычно должно выполняться по строгому расписанию с контролем успешности. Для тестового контура требования могут быть мягче, но если в нем выполняются важные проверки обновлений или разработка, его тоже нельзя полностью игнорировать. В идеале администратор должен иметь документ: какие каталоги относятся к первому серверу, какие ко второму, какие базы подключены, как остановить службы перед обслуживанием и как восстановить каждый контур отдельно.
Журналы также лучше разделять. Если все события смешаны, диагностика становится сложнее: непонятно, какой сервер создал ошибку, где завис рабочий процесс и какой кластер потребляет память. Раздельные технологические журналы, понятные имена служб и отдельные каталоги помогают быстрее находить причину проблем.
Регламент эксплуатации
После установки двух серверов 1С важно не оставить схему «в голове у администратора». Нужен короткий регламент: какие порты используются, где находятся каталоги, кто имеет доступ к рабочему и тестовому контуру, когда можно перезапускать службы, кто отвечает за обновления, где смотреть логи и как действовать при аварии. Такой документ особенно полезен, если в компании несколько администраторов или обслуживание передается подрядчику.
В регламенте стоит отдельно указать, какие действия запрещены. Например, нельзя обновлять рабочую базу на тестовом сервере без копии, нельзя менять порты без уведомления пользователей, нельзя удалять служебный каталог непонятного назначения, нельзя давать пользователям доступ к тестовым базам с похожими названиями без пояснения. Эти простые правила защищают от ошибок, которые обычно возникают не из-за сложности платформы, а из-за спешки.
Также полезно настроить мониторинг: состояние служб, занятость портов, доступность кластера, свободное место на диске, потребление памяти, ошибки в журналах, длительные сеансы и фоновые задания. Если тестовый сервер начинает активно потреблять ресурсы, администратор увидит это до того, как пользователи рабочего контура начнут жаловаться на медленную работу.
Проверочный список после установки
- Обе службы или оба systemd units запускаются и не конфликтуют по портам.
- У каждого экземпляра свой каталог служебных данных и свои права доступа.
- Консоль администрирования подключается к нужному кластеру по правильному порту.
- Тестовая информационная база создается и запускается без ошибок.
- Клиенты подключаются к нужному серверу, а пользователи видят только свои базы.
- Firewall разрешает необходимые подключения и не открывает лишние порты наружу.
- Настроены журналы, резервное копирование, мониторинг ресурсов и регламент перезапуска.
- Администраторы понимают, какой контур рабочий, какой тестовый и какие действия в каждом разрешены.
Чем поможет ТехКон
ТехКон помогает компаниям проектировать, устанавливать и сопровождать серверную инфраструктуру 1С. Мы можем оценить, можно ли безопасно разместить два сервера 1С на одном компьютере, подобрать порты и каталоги, зарегистрировать отдельные службы, настроить firewall, проверить подключение клиентов, настроить резервное копирование, мониторинг и регламент обслуживания. Если задача связана с обновлением платформы или конфигурации, специалисты ТехКон помогут подготовить тестовый контур и снизить риск для рабочей базы.
Мы продаем, внедряем, сопровождаем и дорабатываем программы 1С, а также оказываем бухгалтерский аутсорсинг. Поэтому смотрим на сервер 1С не только как на техническую службу, но и как на основу работы бухгалтерии, торговли, склада, производства и управленческого учета. Ошибка в установке сервера может остановить пользователей, обмены, регламентные задания и отчетность, поэтому такие изменения лучше выполнять по плану и с резервными копиями.
Если у вас уже есть один сервер 1С и нужно поднять второй контур на той же машине, ТехКон поможет выбрать безопасную схему: отдельный серверный экземпляр, тестовая база, виртуальная машина, перенос на другой сервер или полноценная модернизация инфраструктуры. Такой подход позволяет решить задачу без лишних простоев и без случайных конфликтов портов, служб и кластеров.
Получить подробную БЕСПЛАТНУЮ КОНСУЛЬТАЦИЮ по программам 1С и другим вопросам для вашего бизнеса Вы можете по телефону +7 (4712) 220-720 или +7 (919) 213-71-11.
Возможно Вы искали: как установить два сервера 1С на один компьютер, два сервера 1С на одном ПК, несколько кластеров 1С на одном сервере, порты сервера 1С, второй сервер 1С Windows, второй сервер 1С Linux
