← На главную

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

Анализируем исходную проблему: Отключение 11-го пользователя и конфликты HASP-ключей

Наш сценарий включает следующую инфраструктуру:

1. Сервер баз данных на Debian с PostgreSQL, где размещены несколько баз (например, УТ, ЗиК).
2. Сервер терминалов на Windows Server 2012, к которому подключены два HASP-ключа по 5 лицензий каждый. Третий ключ по 5 лицензий "отваливается" и не распознается системой.
3. При подключении 11-го пользователя происходит отключение первого.

Эта проблема с отключением 11-го пользователя при наличии, казалось бы, 10 или даже 15 доступных лицензий, а также с "отваливающимся" третьим ключом, указывает на несколько потенциальных источников конфликтов. Мы выясним, что проблема кроется не столько в PostgreSQL, сколько в особенностях работы HASP-ключей в связке с сервером терминалов Windows и общей архитектурой 1С:Предприятия.

Причины проблем с HASP-ключами на терминальных серверах Windows

Мы рассмотрим несколько факторов, которые часто приводят к некорректной работе HASP-ключей в подобной среде:

1. Ограничения сервера терминалов Windows: Часто Windows Server, особенно при пробросе USB-устройств в виртуальные машины или при использовании встроенных USB-контроллеров, имеет ограничения на количество USB-устройств, которые могут быть корректно распознаны и работать одновременно.
2. Конфликты драйверов: Могут возникать конфликты между драйверами различных USB-устройств или даже между несколькими ключами HASP, особенно если используются разные модели или версии.
3. Программное обеспечение Sentinel HASP License Manager: Некорректная установка, настройка или работа службы Sentinel HASP License Manager (также известной как Sentinel LDK License Manager или Sentinel Protection Server) может приводить к тому, что система не агрегирует лицензии со всех доступных ключей или некорректно их выдает. Если у нас 3 ключа по 5 лицензий, система должна видеть 15 лицензий. Проблема с отключением 11-го пользователя может указывать на то, что доступны только лицензии с двух ключей, либо существуют другие ограничения в пуле лицензий.
4. Проблемы с сетью: В некоторых случаях нестабильность сетевого соединения между клиентами, сервером 1С и сервером лицензий HASP может приводить к потере лицензий.

Для диагностики мы можем проверить корректность работы службы Sentinel LDK License Manager и доступность всех ключей через утилиту Admin Control Center, которая обычно доступна по адресу http://localhost:1947.

Решение 1: Оптимизация архитектуры 1С:Предприятия — Перенос сервера 1С на Linux и централизованное управление лицензиями

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

Рассмотрим преимущества такого переноса:

1. Оптимизация производительности: Мы выясним, что сервер 1С:Предприятие и PostgreSQL значительно лучше работают на Linux в тандеме, поскольку обе системы оптимизированы для этой операционной системы. Это может значительно увеличить скорость работы и обработки данных, что особенно важно для 15 пользователей.
2. Повышенная стабильность: Мы достигаем более высокой стабильности системы в целом за счет разделения ролей сервера 1С и терминального сервера. Сбои на терминальном сервере (например, связанные с драйверами USB или другими клиентскими приложениями) больше не будут влиять на работу сервера 1С и базы данных.
3. Эффективное использование ресурсов: Мы знаем, что Linux потребляет меньше системных ресурсов по сравнению с Windows Server. Это позволяет выделить больше вычислительных ресурсов (процессор, оперативная память) непосредственно для работы 1С:Предприятия и PostgreSQL, что критично для производительности.
4. Гибкость лицензирования: Мы можем использовать программные лицензии 1С:Предприятие, которые более гибки и удобны для привязки к серверу 1С на Linux. Если же мы продолжим использовать HASP-ключи, то организуем централизованный сервер лицензий HASP.

Централизованный сервер лицензий HASP

Для стабильной работы нескольких аппаратных ключей мы настоятельно рекомендуем использовать отдельный сервер лицензий HASP (Sentinel HASP License Manager). Этот сервер может быть установлен на отдельной машине или на одном из существующих серверов (например, на сервере PostgreSQL, если он достаточно производителен, или на специально выделенном для этого сервере). Мы настроим его для централизованного управления всеми ключами. В этом случае клиенты 1С:Предприятие и сервер 1С:Предприятие будут обращаться к этому серверу лицензий по сети, а не напрямую к USB-портам терминального сервера. Это позволит нам:

• Агрегировать лицензии: Система должна будет корректно видеть все 15 лицензий (3 ключа по 5).
• Гибко распределять лицензии: Мы сможем более гибко распределять лицензии между различными серверами 1С и терминальными серверами, независимо от того, к какому физическому USB-порту подключен ключ.
• Устранить конфликты: Мы минимизируем проблемы с пробросом USB-ключей и конфликтами драйверов на терминальном сервере.

Решение 2: Создание второго терминального сервера и распределение нагрузки

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

1. Сервер баз данных Debian на PostgreSQL: Остается в текущей конфигурации с несколькими базами (УТ, ЗиК).
2. Сервер терминалов Ubuntu/Windows для базы УТ: Мы создадим отдельный терминальный сервер (например, на Ubuntu с RDP-сервером или на Windows Server) специально для пользователей, работающих с базой УТ. Этот сервер будет подключаться к центральному серверу 1С и использовать лицензии, выданные централизованным менеджером HASP.
3. Сервер терминалов Win-2012 для базы ЗиК: Наш существующий сервер Win-2012 будет использоваться для подключения к базе ЗиК, также обращаясь к центральному серверу 1С и получая лицензии от централизованного менеджера HASP.

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

Взаимодействие серверов 1С и PostgreSQL

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

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

Таким образом, беспокоиться о том, что PostgreSQL не сможет одновременно обслуживать несколько серверов 1С, не стоит. Главное — обеспечить адекватные ресурсы для PostgreSQL.

Рекомендации по оборудованию для 15 пользователей

Для 15 пользователей, работающих с двумя базами (УТ и ЗиК), даже при наличии VPN-подключений, файловая база не подходит (подтверждено проблемой с VPN и количеством пользователей). Клиент-серверный вариант с PostgreSQL и сервером 1С:Предприятие на отдельном сервере является правильным выбором. Мы рассмотрим, какое оборудование нам понадобится для обеспечения комфортной работы:

1. Процессор: Нам потребуется современный многоядерный процессор. Мы выбираем, например, Intel Xeon E-22xx или аналогичный AMD EPYC/Ryzen Pro с частотой не ниже 3.0 ГГц. Критически важно количество ядер и потоков, так как PostgreSQL и сервер 1С активно используют их для параллельной обработки запросов и сеансов пользователей.
2. Оперативная память (RAM): Мы рекомендуем установить не менее 32 ГБ RAM. PostgreSQL активно кэширует данные в оперативной памяти, а сервер 1С также требует значительного объема RAM для обработки сеансов пользователей и кэширования метаданных. Если базы данных достаточно большие или ожидается рост, мы можем рассмотреть 64 ГБ или более для сервера.
3. Дисковая подсистема: Это один из самых критичных компонентов для производительности 1С и PostgreSQL. Мы обязательно используем быстрые SSD-накопители, предпочтительно NVMe, для максимальной производительности ввода-вывода. Мы рекомендуем использовать RAID 1 или RAID 10 для обеспечения отказоустойчивости и повышения скорости чтения/записи. Для оптимизации производительности, мы можем рассмотреть использование отдельных дисков или разделов для следующих компонентов:
   • Операционная система и системные файлы.
   • Файлы баз данных PostgreSQL (pg_data).
   • Журналы транзакций PostgreSQL (WAL - Write-Ahead Log), которые являются одними из самых интенсивно используемых частей дисковой подсистемы. Их размещение на отдельном, очень быстром диске может значительно улучшить производительность записи.

Грамотное планирование и распределение нагрузки по дисковой подсистеме позволит нам избежать "узких мест" и обеспечить быструю работу системы.

Заключительные рекомендации

В итоге, мы видим, что решение нашей проблемы требует комплексного подхода. Давайте подытожим наши шаги:

1. Переносим сервер 1С:Предприятие на отдельный сервер на базе Linux, оптимально – совместно с PostgreSQL, чтобы воспользоваться преимуществами обеих систем в Linux-среде.
2. Организуем централизованный сервер лицензий HASP (Sentinel HASP License Manager), чтобы агрегировать все лицензии (15 из 3 ключей) и обеспечить стабильную выдачу их серверам 1С и клиентам.
3. Создаем несколько терминальных серверов (RDP) для клиентов 1С, разделяя их по функционалу или базам данных (например, один для УТ, другой для ЗиК), которые будут обращаться к центральному серверу 1С за обработкой данных и к серверу лицензий HASP за лицензиями.
4. Обеспечиваем адекватные аппаратные ресурсы для сервера 1С/PostgreSQL, особенно уделяя внимание скорости дисковой подсистемы и объему оперативной памяти.

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