← На главную

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

Понимание основ лицензирования 1С

Прежде чем перейти к обоснованиям, давайте разберем, как работает лицензирование в 1С. Система лицензирования 1С:Предприятия предназначена для контроля количества одновременно работающих пользователей и компонентов. В общем случае, клиентские лицензии (или лицензии на рабочие места) могут быть аппаратными (USB-ключи) или программными. Сервер 1С:Предприятия также требует серверную лицензию.

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

Аппаратные USB-ключи (HASP) — это физические устройства, которые содержат информацию о лицензиях. Они не привязаны к конфигурации компьютера и могут быть легко перемещены между серверами. Для работы с USB-ключами требуется установка драйвера HASP.

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

1. Локальный клиентский ключ: Система сначала ищет аппаратный ключ, воткнутый непосредственно в тот компьютер, откуда запускается клиент (не применимо для веб-клиента).
2. Сетевой клиентский ключ: Затем осуществляется поиск аппаратного ключа, доступного в локальной сети через протокол NetHASP (также не применимо для веб-клиента). Это регулируется файлом nethasp.ini.
3. Локальный клиентский ключ сервера 1С:Предприятия: Если аппаратный ключ не найден, система обращается к серверу 1С. Сервер ищет локальный ключ на компьютере менеджера лицензий, на который назначен сервис сеансовых данных. Для файловых информационных баз на веб-сервере используется локальный ключ самого веб-сервера.
4. Сетевой клиентский ключ сервера 1С:Предприятия: Наконец, сервер 1С ищет аппаратный ключ в сети.

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

Основные аргументы для обоснования невозможности использования программных лицензий

1. Работа в закрытом контуре без доступа к интернету

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

• Государственные учреждения и ведомства.
• Военные организации.
• Крупные финансовые институты и банки.
• Промышленные предприятия с повышенными требованиями к информационной безопасности (например, объекты критической инфраструктуры).

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

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

Аппаратный USB-ключ, будучи полностью автономным устройством, не требует подключения к интернету ни для активации, ни для последующей проверки. Его просто подключают к серверу, и он немедленно обеспечивает работоспособность системы, что идеально соответствует требованиям закрытого контура.

2. Динамическая виртуализация и облачные среды

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

Программные лицензии привязываются к уникальному "отпечатку" аппаратного обеспечения виртуальной машины, который формируется на основе таких параметров, как MAC-адрес сетевой карты, объем оперативной памяти, количество ядер процессора, UUID виртуальной машины и другие. В средах, где параметры виртуальных машин могут меняться динамически, это приводит к следующим проблемам:

1. Частая "слет" лицензий:
   • Миграция виртуальных машин (Live Migration, vMotion): При переносе виртуальной машины между физическими хостами (например, для балансировки нагрузки или обслуживания оборудования) ее аппаратные параметры могут измениться, что приведет к немедленному "слету" программной лицензии.
   • Изменение ресурсов: Динамическое изменение выделенных ресурсов (добавление/удаление ОЗУ, CPU) для оптимизации производительности или масштабирования также может вызвать деактивацию лицензии.
   • Автоматическое развертывание: В облачных или частных облачных средах, где виртуальные машины создаются, уничтожаются и переконфигурируются автоматически, программные лицензии становятся совершенно непригодными.
2. Трудоемкость администрирования: Каждая деактивация лицензии требует повторной активации с использованием резервных ПИН-кодов. Количество резервных ПИН-кодов ограничено, и их исчерпание может привести к невозможности запуска системы. Это значительно увеличивает нагрузку на системных администраторов и приводит к простоям в работе пользователей.
3. Ненадежность системы: Постоянная угроза деактивации лицензии делает всю систему 1С крайне ненадежной и непредсказуемой в динамических средах.

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

3. Особенности использования файловых баз на терминальных серверах

При работе с файловыми информационными базами 1С:Предприятия через терминальный доступ (например, по протоколу RDP) возникает специфическая проблема, связанная с потреблением лицензий.

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

В то же время, при использовании аппаратного USB-ключа, воткнутого либо напрямую в терминальный сервер, либо доступного по сети (через nethasp.ini), один сеанс пользователя на терминальном сервере, запускающий несколько файловых баз, будет потреблять только одну клиентскую лицензию из USB-ключа. Это делает использование программных лицензий экономически невыгодным и технически неоптимальным для компаний, активно работающих с множеством файловых баз в терминальном режиме.

Мы наблюдаем следующее поведение:

1. Пользователь подключается к терминальному серверу.
2. Запускает первую файловую базу 1С — потребляется 1 лицензия (программная или аппаратная).
3. Запускает вторую файловую базу 1С в том же терминальном сеансе:
   • При использовании программных лицензий: может быть потреблена вторая лицензия.
   • При использовании аппаратных USB-ключей: не потребляется дополнительная лицензия (или потребляется только одна на сеанс/рабочее место).

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

4. Отказоустойчивые кластеры и резервирование

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

1. Невозможность автоматической активации на резервном узле: Программная лицензия привязана к конкретному серверу. При переключении на резервный сервер, на котором лицензия не активирована, система не сможет запуститься. Активация же программной лицензии требует ручного вмешательства и наличия ПИН-кодов.
2. Простои при переключении: Если резервный сервер должен быть запущен автоматически при выходе из строя основного, ручная активация программной лицензии на нем сводит на нет все преимущества отказоустойчивости, приводя к неизбежным простоям.
3. Использование резервных ПИН-кодов: Частые переключения между серверами (например, в ходе тестирования или планового обслуживания) могут быстро исчерпать ограниченное количество резервных ПИН-кодов, что сделает дальнейшую активацию лицензий невозможной.

Аппаратный USB-ключ, напротив, легко переносится или пробрасывается в резервный узел кластера. Мы можем настроить систему так, чтобы при переключении на резервный сервер USB-ключ был немедленно доступен (например, через сетевой ключ HASP) или переподключен. Это обеспечивает истинную отказоустойчивость без необходимости ручной переактивации и связанных с ней рисков и простоев.

5. Требования службы безопасности и политики ИТ

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

• Запрет на использование ПО, требующего периодического подключения к внешним серверам для валидации (аналогично аргументу про закрытый контур, но может быть применимо и к сетям с доступом в интернет).
• Требования к физическому контролю над лицензионными активами, что лучше обеспечивается физическими ключами.
• Сложности с аудитом и контролем программных лицензий, разбросанных по множеству серверов и виртуальных машин.

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

6. Упрощение администрирования при замене оборудования и в сложных гетерогенных средах

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

1. Замена вышедшего из строя оборудования: При выходе из строя сервера, на котором была активирована программная лицензия, процесс ее восстановления на новом оборудовании может быть длительным и трудоемким. Мы вынуждены связываться с техподдержкой, предоставлять обоснования, использовать резервные ПИН-коды, что может вызвать длительные простои. USB-ключ же просто переставляется в новый сервер, и система продолжает работать без задержек.
2. Плановое обновление оборудования: Аналогично предыдущему пункту, плановое обновление серверов также влечет за собой необходимость переактивации программных лицензий, что требует дополнительных временных и человеческих ресурсов.
3. Сложные гетерогенные среды: В компаниях со сложной ИТ-инфраструктурой, включающей множество серверов, филиалов, удаленных подразделений и различные операционные системы, управление парком программных лицензий (отслеживание активаций, хранение ПИН-кодов и резервных ПИН-кодов) становится чрезвычайно громоздкой задачей. Физический USB-ключ, установленный на центральном сервере лицензирования, представляет собой единую, легко контролируемую точку управления лицензиями.

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

Пример гибридной системы распределения лицензий

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

1. Мы используем файл nethasp.ini для настройки поиска сетевых HASP-ключей. Этот файл позволяет указать IP-адреса серверов, на которых доступны аппаратные ключи.
2. Клиенты 1С сначала пытаются получить лицензию через сетевой HASP-сервер, используя настройки из nethasp.ini. Это обеспечивает приоритет для аппаратных ключей.
3. Если по какой-то причине лицензия через HASP не найдена (например, все HASP-лицензии заняты или HASP-сервер недоступен), клиент автоматически обращается к серверу 1С:Предприятия.
4. Сервер 1С:Предприятия выдает программные лицензии (если они есть) или лицензии со своих подключенных аппаратных ключей (если они имеются) для тех клиентов, которые не смогли получить лицензию напрямую.

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

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