← На главную

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

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

Почему тестирование платформы 1С является критически важным?

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

1. Минимизация рисков: Обновление платформы всегда несет потенциальные риски нарушения стабильности работы. Тестирование позволяет выявить и устранить проблемы до того, как они затронут продуктивную среду.
2. Проверка критического функционала: Убедимся, что обмены данными, выгрузки, интеграции с другими системами и специфические доработки конфигурации работают корректно на новой платформе.
3. Выявление неописанных ошибок: Как показывает опыт, не все проблемы, возникающие при переходе на новые версии платформы, всегда своевременно документируются фирмой "1С". Собственное тестирование становится единственным надежным способом обнаружения таких "сюрпризов".

Общие подходы к организации тестового контура 1С

Для эффективного тестирования нам потребуется специально выделенная среда – тестовый контур. Рассмотрим несколько рекомендуемых подходов к его организации:

1. Отдельный тестовый сервер 1С:

   Идеальным решением является выделение отдельного физического или виртуального сервера для разработки и тестирования. Этот подход гарантирует полную изоляцию от продуктивной среды и позволяет проводить любые эксперименты без риска повлиять на текущую работу пользователей. Такой сервер должен быть максимально приближен к продуктивному по своим характеристикам и составу ПО.

   Нам может потребоваться дополнительная лицензия на сервер 1С для такого тестового контура. Если бюджет ограничен, можно рассмотреть вариант приобретения мини-сервера на 5 подключений, что существенно дешевле полнофункционального, но вполне достаточно для большинства задач тестирования.

2. Использование виртуализации:

   Виртуальные машины (VM) стали стандартным и предпочтительным способом организации тестовых серверов 1С. Они предоставляют огромные преимущества:

   • Легкое клонирование: Можно быстро создавать копии продуктивных баз для тестирования.
   • Снимки состояния (snapshots): Перед каждым тестом можно сделать снимок системы, а в случае неудачи – мгновенно откатиться к исходному состоянию.
   • Изоляция: Каждая тестовая среда полностью изолирована от других, что исключает взаимное влияние.
   • Быстрое развертывание и удаление: Тестовые среды можно быстро разворачивать для конкретных задач и удалять по их завершении.

   Если в продуктивной среде 1С работает на виртуальных машинах, то логично и тестирование проводить в аналогичных виртуальных средах. Это обеспечит максимальное соответствие тестового контура продуктивному.

3. Контейнеризация (Docker/Kubernetes):

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

Решение проблемы с запуском нескольких консолей управления серверами 1С разных версий

Автор изначально столкнулся с проблемой запуска двух консолей управления серверами 1С разных версий на одной машине. Эта проблема часто возникает из-за конфликтов DLL-библиотек (например, comcntr.dll), которые регистрируются в системе и используются консолями. Рассмотрим несколько подходов к решению этой задачи:

1. Установка консолей на разных машинах:

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

2. Ручная перерегистрация DLL-библиотек:

   Для запуска консолей разных версий на одной машине, нам может потребоваться ручная регистрация или отмена регистрации нужных версий DLL-библиотек. Основной библиотекой, вызывающей конфликты, является comcntr.dll. Мы можем использовать утилиту regsvr32 для этого.

   Важный момент: Этот метод требует осторожности и понимания того, как работает регистрация COM-объектов в Windows. Неправильные действия могут нарушить работу других приложений.

   Мы можем создать пакетные файлы (батники), которые будут:

   1. Отменять регистрацию текущей версии comcntr.dll.
   2. Регистрировать нужную версию comcntr.dll из папки с требуемой версией платформы.
   3. Запускать консоль управления.
   4. (Опционально) Возвращать регистрацию предыдущей версии или отменять текущую после завершения работы.

   Пример (концептуальный) батника для запуска консоли определенной версии:

   Скопировать код

   
   :: Отменяем регистрацию текущей версии (путь может отличаться)
   "%systemroot%\system32\regsvr32.exe" /u "C:\Program Files\1cv8\current_version\bin\comcntr.dll"
   
   :: Регистрируем нужную версию для запуска (например, 8.3.18.1289)
   "%systemroot%\system32\regsvr32.exe" "C:\Program Files\1cv8\8.3.18.1289\bin\comcntr.dll"
   
   :: Запускаем консоль управления нужной версии
   start "C:\Program Files\1cv8\8.3.18.1289\bin\1cv8.exe" /c "ENTERPRISE" /S server_name /N user /P password
   
   :: После использования, можно отменить регистрацию или вернуть предыдущую
   :: "%systemroot%\system32\regsvr32.exe" /u "C:\Program Files\1cv8\8.3.18.1289\bin\comcntr.dll"
   :: "%systemroot%\system32\regsvr32.exe" "C:\Program Files\1cv8\current_version\bin\comcntr.dll"
   

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

3. Использование переменных окружения или реестра:

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

Запуск нескольких экземпляров сервера 1С на одном физическом или виртуальном хосте

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

Техническая реализация

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

1. Установить разные версии платформы 1С:Предприятия в отдельные каталоги (например, C:\Program Files\1cv8\8.3.18.1289 и C:\Program Files\1cv8\8.3.20.1711).
2. Настроить каждый экземпляр сервера 1С на работу на разных портах (например, стандартный 1541 для продуктивного, и 1542, 1543 и т.д. для тестовых). Это можно сделать при установке или позже, через конфигурационный файл или средства администрирования.
3. Использовать подсистему "Инструменты разработчика" -> "Управление службами серверов 1С": Этот инструмент, входящий в состав платформы, предназначен для управления отдельными службами агентов сервера 1С:Предприятия. Он может быть полезен при настройке нескольких рабочих серверов в рамках одного кластера или при запуске тестовых служб на отдельном порту.
4. Разделять публикации баз на разные веб-приложения: Если мы публикуем базы на веб-сервере (Apache или IIS), для каждого экземпляра сервера и каждой версии платформы следует настроить отдельные веб-приложения, чтобы избежать конфликтов.
5. Запускать разные версии платформы под разными пользователями: Это может помочь в изоляции процессов и их настроек, хотя и не всегда является строго необходимым.

Аспекты лицензирования 1С

Вопрос о лицензировании нескольких экземпляров сервера 1С на одной лицензии вызывает много споров. Однако, согласно официальной информации и практике, запуск нескольких экземпляров сервера 1С (разных или одинаковых версий) на одном физическом или виртуальном сервере на одной лицензии является законным и не противоречит условиям использования. Это подтверждается как опытом многих специалистов, так и наличием описаний подобных сценариев в официальной документации 1С (например, на ИТС).

Разберем ключевые моменты:

1. Одна лицензия – один сервер (физический/виртуальный): Лицензия на сервер 1С:Предприятия (ПРОФ или КОРП) дает право на запуск одного экземпляра сервера 1С на одной машине (физической или виртуальной). Однако, она не ограничивает количество экземпляров агента сервера 1С, которые могут быть запущены на этом одном сервере.
2. Лицензия ПРОФ и ограничение на 12 ядер:

   Лицензия 1С:Предприятие 8 ПРОФ на сервер ограничивает использование одним экземпляром сервера 1С не более 12 ядер процессора. Важно понимать, что запуск нескольких экземпляров сервера 1С (например, двух) на одной ПРОФ-лицензии на одном физическом сервере, даже если каждый из них использует до 12 ядер, не считается обходом ограничения ПРОФ и не дает функционала КОРП. Каждый запущенный экземпляр сервера 1С будет привязан к одной лицензии и будет работать в рамках ее ограничений (например, не более 12 ядер для ПРОФ).

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

3. Привязка программных лицензий:

   Программные лицензии 1С привязываются к ключевым параметрам оборудования (MAC-адрес, CPU ID, жесткий диск и т.д.) либо физического сервера, либо виртуальной машины, на которой они активированы. Если параметры двух виртуальных машин идентичны (например, при клонировании без изменения ID), это может привести к проблемам с лицензированием и деактивации лицензий. Для тестовых целей, когда мы используем одну и ту же физическую или виртуальную машину для разных экземпляров сервера, программная лицензия обычно активируется один раз для этой машины и "видна" всеми запущенными на ней экземплярами.

4. Аппаратные USB-ключи (HASP):

   Аппаратные USB-ключи обычно проще в использовании для нескольких экземпляров сервера на одном физическом хосте, так как ключ может быть "увиден" всеми экземплярами сервера или проброшен в виртуальные машины. Многие подтверждают, что с аппаратным ключом эта схема отлично работает и не вызывает проблем с лицензированием.

Практические советы и "хитрости" при тестировании

Помимо основных подходов, существуют практические советы, которые сделают процесс тестирования более эффективным:

1. Стабильная работа нескольких платформ 1С:

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

   • Изоляция процессов: Запускайте разные версии платформы под разными пользователями операционной системы (если это возможно и удобно).
   • Разделение публикаций баз: Если вы публикуете информационные базы для веб-доступа, убедитесь, что каждая база (или группа баз под определенной версией платформы) публикуется в отдельное веб-приложение на веб-сервере (IIS, Apache, Nginx).
   • Аккуратность с DLL: Как мы уже обсуждали, будьте внимательны с системными библиотеками.
2. Использование символических ссылок для быстрого развертывания:

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

   В этом случае, установка новой платформы и ее "встраивание" в тестовый контур занимает время на скачивание и саму установку платформы, плюс буквально 1-2 минуты на изменение ссылки и перезапуск службы. Это создает готовое к работе окружение с минимальными затратами времени.

3. Пошаговый процесс тестирования и обновления (пример):

   Давайте рассмотрим типичный порядок действий при тестировании и обновлении:

   1. Устанавливаем новую версию платформы на наш тестовый сервер (физический или виртуальный). Если у нас несколько экземпляров на одном хосте, то устанавливаем в отдельный каталог на свободный порт.
   2. Разворачиваем копию продуктивной базы данных на тестовом сервере, подключаем ее к новому экземпляру сервера 1С.
   3. Проводим тщательное тестирование всех критически важных функций: обмены, выгрузки, отчеты, специфические доработки, производительность.
   4. Если тестирование успешно:
      • На рабочем (продуктивном) сервере гасим службу старого сервера 1С.
      • Устанавливаем новую платформу (если еще не установлено) на продуктивный сервер в соответствующий каталог, указываем новый порт, если необходимо (хотя обычно на продуктивном сервере достаточно обновить текущий экземпляр).
      • Запускаем новую службу сервера 1С и проверяем, что все взлетело и функционирует корректно.

   Общая мысль: В продуктивную среду должно идти только то, что было всесторонне протестировано в тестовом контуре.

Таким образом, для эффективного тестирования серверной платформы 1С мы рекомендуем:

• Всегда использовать отдельный тестовый контур, предпочтительно на виртуальных машинах.
• Для решения проблем с консолями управления рассмотреть их установку на разных машинах или использовать ручную перерегистрацию DLL.
• Не бояться запускать несколько экземпляров сервера 1С на одном хосте для тестовых целей, понимая особенности лицензирования ПРОФ/КОРП и используя разные порты.
• Применять практические "хитрости", такие как символические ссылки и "Инструменты разработчика", для оптимизации процесса.

Такой комплексный подход позволит нам обеспечить стабильность и надежность работы вашей системы 1С после обновлений.