Orgl8 10

  • автор:

HASP License менеджер и usb-ключ HASP сервер под Windows Server 2012

Есть «железный» HASP-ключ на 100 пользователей. Стоит в сервере под ОС Windows server 2003, там же установлен HASP License менеджер, который раздает эти лиценции пользователям сети. В сети есть сервер 1с 8.2, а также сервер 1с 8.3, соответственно часть баз используется под одним сервером, часть под другим.
Появилась острая необходимость перенести HASP-ключ на другой сервер. А в сети для этой цели доступен только сервер под Windows Server 2012.
Был скачан драйвер Sentinel HASP/LDK Windows GUI Run-time Installer версии 6.60 отсюда
HASP License менеджер и драйвер нормально встали под Windows Server 2012. AKS Monitor видит HASP License менеджер. При вставке ключа в сервер, ключ загорается как надо, устанавливается в Диспетчере устройств.
Но при запуске базы, работающей под сервером 1с 8.2 (запускал 2 базы, одна в режиме совместимости 8.1, другая без режима совместимости, обе под толстым клиентом) возникает сообщение о том, что недоступна лицензия и конце концов можно получить сообщение от базы:
Не найдена лицензия. Не обнаружен ключ защиты программы или полученная программная лицензия!
по причине:
Поиск лицензии на клиенте:
nethasp.ini: C:/Program Files/1cv82/conf/nethasp.ini, прочитан успешно, ORGL8 Сетевой, установлен
Поиск лицензии на сервере:
ORGL8 Сетевой, установлен, неисправен или не подходит для 1С:Предприятия
Файл программной лицензии не найден
ORGL8 Локальный, не установлен
ORG8A Локальный, не установлен
ORG8B Локальный, не установлен
nethasp.ini: C:/Program Files (x86)/1cv82/conf/nethasp.ini, прочитан успешно, ошибка соединения с менеджером лицензий: Net Status=0, System Error=0, Warning=129, ORG8A Сетевой, не установлен
nethasp.ini: C:/Program Files (x86)/1cv82/conf/nethasp.ini, прочитан успешно, ошибка соединения с менеджером лицензий: Net Status=0, System Error=0, Warning=129, ORG8B Сетевой, не установлен
Конфигурация не является базовой
Экпериментировал с различными конфигурациями nethasp.ini:
-полностью закомментированным;
-с приведенными ниже строками, которые раскомментированы

NH_TCPIP = Enabled ; or Disabled ; Use the TCP/IP protocol

NH_SERVER_ADDR = 192.168.0.1 ;<Addr1>, <Addr2> ; IP addresses of all the NetHASP
NH_TCPIP_METHOD = TCP ; or UDP ; Send a TCP packet or UDP packet
где 192.168.0.1 это ip-адрес Windows Server 2012;
В случае же запуска базы, работающей под сервером 1с 8.3 (запускаются под тонким клиентом) все запускается и AKS Monitor видит подключенные к HASP License менеджеру сеансы. Кстати, при любых конфигурациях nethasp.ini, упомянутых выше.
Что можно предпринять, чтобы HASP License менеджер под Windows Server 2012 раздавал клиентские лицензии всем без проблем?

Защита системы «1С:Предприятие» может быть построена на использовании сетевой системы защиты HASP4 Net. Подсчет пользователей при этом, может осуществляться либо серверной частью «1С:Предприятия», либо специальной программой — HASP License Manager. Эта статья посвящена установке HASP License Manager и настройке системы «1С:Предприятие» для работы с ним.

Ключи защиты и их маркировка

Аппаратные ключи защиты HASP4 Net подключаются к USB-портам компьютера. Общее количество пользователей, которые могут работать с системой «1С:Предприятие» равняется сумме доступных лицензий со всех компьютеров в сети, к которым подключены аппаратные ключи и настроен HASP License Manager.

Аппаратные ключи похожи на USB-флеш-накопитель и выглядят примерно вот так:

Многопользовательский клиентский ключ H4 NET5 ORGL8

Они могут различаться цветом и маркировкой. По маркировке можно определить что это за ключ: для каких программных продуктов он подходит и сколько лицензий предоставляет.

  • ORGL8 — Локальный клиентский ключ;
  • NET5 ORGL8 — Многопользовательский клиентский ключ на 5 пользователей;
  • NET10 ORGL8 — Многопользовательский клиентский ключ на 10 пользователей;
  • NET20 ORGL8 — Многопользовательский клиентский ключ на 20 пользователей;
  • NET50 ORGL8 — Многопользовательский клиентский ключ на 50 пользователей;
  • NET100 ORGL8 — Многопользовательский клиентский ключ на 100 пользователей;
  • NET250+ ORG8A — Многопользовательский клиентский ключ на 300 пользователей;
  • NET250+ ORG8B — Многопользовательский клиентский ключ на 500 пользователей;
  • ENSR8 — Локальный ключ 32-разрядного сервера;
  • EN8SA — Локальный ключ 64-разрядного сервера.

Так, на фотографии выше представлен многопользовательский клиентский ключ на 5 пользователей.Нужно отметить, что на одном компьютере может работать только один ключ каждой серии (ORGL8, ORG8A и ORG8B). Если подключить к одному компьютеру несколько ключей одинаковой серии, то будет задействован только один из них, выбранный произвольно.

Установка драйвера защиты

HASP Device Driver требуется установить на тех компьютерах к которым непосредственно подключены аппаратные ключи защиты. Этот драйвер входит в комплект поставки «1С:Предприятия» и его можно установить из меню «Пуск»:

Установка драйвера защиты из меню «Пуск»

Или из командной строки:

C:\>»Program Files\1cv8\common\haspdinst.exe» -i

Для ОС Linux нужно скачать драйвер с сайта компании SafeNet. Скачанный архив содержит DEB-пакет для Ubuntu/Debian, RPM-пакет для RedHat/SuSE и скрипт для автоматической установки. Попробуем вариант со скриптом, для этого скачаем и распакуем нужный архив. Далее сделаем исполняемым файл dinst и запустим его:

sudo chmod +x ./dinst

sudo ./dinst .

Результат будет выглядеть примерно так:

Установка драйвера в ОС Linux

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

Установка HASP License Manager

Дистрибутив HASP License Manager можно найти на сайте компании SafeNet. При установке в ОС Windows нужно будет выбрать вариант установки — приложение или служба, обычно выбирают службу:

Установка HASP License Manager

В ОС Linux установка HASP LM выглядит немного сложнее. Архив с сайта SafeNet содержит два RPM-пакета для RedHat и SuSE (вероятно, для этих систем установка HASP LM достаточно проста) и запакованный файл hasplm для всего остального. Следуя инструкции с сайта ИТС у меня не получилось запустить файл hasplm на Ubuntu 16.04.

Поэтому пришлось воспользоваться решением от компании Etersoft. Идем на FTP компании и находим нужную версию. Для моей 64-х битной Ubuntu 16.04 я выбрал эту версию: http://ftp.etersoft.ru/pub/Etersoft/HASP/stable/x86_64/Ubuntu/16.04/. Скачиваем файлы и в начале устанавливаем необходимые пакеты, в моем случае потребовалось установить пакет make:

sudo apt-get install make

и пакет libc6-i386 (несмотря на то, что я скачал 64-х битную версию HASP LM, он, по сути, остается 32-х битным приложением и ему требуются 32-х битные библиотеки):

sudo apt-get install libc6-i386

после этого устанавливаем пакеты HASP LM:

sudo dpkg -i haspd_7.60-eter1ubuntu_amd64.deb

sudo dpkg -i haspd-modules_7.60-eter1ubuntu_amd64.deb

Перезапускаем сервис:

sudo service haspd restart

HASP LM на Ubuntu 16.04

Как видно из скриншота, файл с настройками находится тут: /etc/haspd/hasplm.conf.

Настройка

nhsrv.ini

В ОС Windows файл nhsrv.ini может располагаться в различных местах:

Для ОС Linux файл настроек указывается при помощи параметра «-c» и его название и местоположение по умолчанию не определено.

Настройка HASP LM задаются значениями параметров секции файла nhsrv.ini:

  • NHS_IP_LIMIT — определяет диапазон IP-адресов, обслуживаемых HASP LM. Например: 192.168.*.*, 192.168.1.1/24.
  • NHS_ADAPTER — определяет IP-адрес одной или более сетевых карт, которые будут обслуживать HASP LM. Применяется при использовании HASP LM с Win32. Например: 10.1.1.111, 255.255.0.0.
  • NHS_USERLIST — определяет максимальное количество пользователей, одновременно подключенных к HASP LM Значение по умолчанию: 250 (важно для ключей на 300 и 500 пользователей).

nethasp.ini

Для настройки взаимодействия системы «1С:Предприятия» с HASP LM используется конфигурационный файл nethasp.ini. Несмотря на то, что в большинстве случаев никакая дополнительная настройка не требуется полезно иметь представление о возможностях предлагаемых этим файлом.

Файл nethasp.ini, в ОС Windows, обычно располагается в каталоге 1С (например C:\Program Files\1cv8\conf), а в ОС Linux он может находиться в домашнем каталоге пользователя или в каталоге /etc.

В примере ниже указывается, что сервер защиты находится по адресу 192.168.0.12 и запрещается широковещательный механизм TCP/IP.

NH_TCPIP=Enabled

NH_SERVER_ADDR=192.168.0.12
NH_USE_BROADCAST=Disabled

Далее рассмотрим прочие параметры, доступные в файле nethasp.ini.

Секция

  • NH_IPX — использовать или не использовать протокол IPX для связи с HASP LM, варианты: Enabled, Disabled (по умолчанию Enabled);
  • NH_NETBIOS — использовать или не использовать протокол NetBIOS для связи с HASP LM, варианты: Enabled, Disabled (по умолчанию Enabled);
  • NH_TCPIP — использовать или не использовать протокол TCP/IP для связи с HASP LM, варианты: Enabled, Disabled (по умолчанию Enabled);
  • NH_SESSION — задает интервал в секундах, в течение которого программа пытается установить соединение с HASP LM (по умолчанию 2 секунды);
  • NH_SEND_RCV — устанавливает для HASP LM максимальное время получения или отправки пакета (по умолчанию 1 секунда).

Последние два параметра могут быть использованы во всех секциях.

  • NH_USE_SAP — использовать или не использовать службу SAP для поиска в сети HASP LM, варианты: Enabled, Disabled (по умолчанию Enabled);
  • NH_USE_BROADCAST — использовать только механизм Broadcast для поиска в сети HASP LM, варианты: Enabled, Disabled (по умолчанию Enabled);
  • NH_BC_SOCKET_NUM — определяет номер сокета (число в шестнадцатеричном виде) для широковещательного механизма (по умолчанию: 7483Н);
  • NH_SERVER_NAME — определяет, будет ли приложение обмениваться данными только с HASP LM, находящимся в локальной сети, или с любыми другими HASP LM, варианты: localnet, Internet (по умолчанию Internet);
  • NH_DATFILE_PATH — путь, по которому будет производиться поиск файлов haspaddr.dat и newhaddr.dat, содержащих сетевой адрес HASP LM.
  • NH_NBNAME — задает имя HASP LM (не более 8 символов);
  • NH_USELANANUM — устанавливает номер коммуникационного канала.
  • NH_SERVER_ADDR — устанавливает IP-адреса серверов HASP LM (количество адресов не ограниченно);
  • NH_SERVER_NAME — обменивается данными с HASP LM с определенным именем (максимум 6 имен, каждое не более 7-ми символов);
  • NH_PORT_NUMBER — устанавливает номер сетевого порта (по умолчанию 475);
  • NH_TCPIP_METHOD — посылает пакет TCP или UDP, обращение к HASP LM всегда выполняется по UDP, независимо от значения этого параметра;
  • NH_USE_BROADCAST — использовать широковещательный механизм UDP, варианты: Enabled, Disabled (по умолчанию Enabled).

На этом все, надеюсь, что данная статья была Вам полезна.

Если Вы нашли ошибку или неточность, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Маркировка ключей защиты 1С:Предприятия

Для 1С 8 в настоящий момент используется 4 типа ключей:
— Однопользовательский. Это HASP HL Basic. Ключ синего цвета, не имеет внутренней памяти и персонального номера.
— Сетевой. HASP HL Net. Ключ красного цвета, имеет персональный номер и внутреннюю память в которой записано количество лицензий.
— Ключ на 32х битный сервер 1С:Предприятие. HASP HL Pro.У ключа есть маркировка ENSR8 Ключ фиолетового цвета, с внутренней памятью (фактически не используется) и уникальным идентификатором.
— Ключ на 64х битный сервер 1С:Предприятие. HASP HL Max. Ключ зеленого цвета. У ключа есть маркировка EN8SA, при этом данный ключи поддерживает 32-битный сервер (если у клиента есть лицензия на 64-битный сервер, он может, не меняя ключа, использовать также и 32-битную версию). C внутренней памятью (фактически не используется) и уникальным идентификатором.
Разобрались с цветами, попытаемся понять буковки:
В первой строчке ключа его тип и максимальное количество лицензий.
Hasp4 или Н4 — тип ключа.
М1 — локальный с памятью 112 байт
NetXX — сетевой, где ХХ — количество лицензий.
Других 1С пока не использует.
Во второй строчке первые пять знаков — код разработчика (заказчика) ключа.
В приложении к 1С — это назначение ключа.
ORGL8 — пользовательский от восьмерки.
ENSR8 — сервер предприятия восьмерки 32x.
EN8SA — сервер предприятия восьмерки 64x.
Остальные знаки никакого интереса не представляют.
Подробнее:
Серверные ключи:
1С:Предприятие 8.0 (8.1, 8.2) Лицензия на сервер (х32) маркируется «H4 M1 Pro ENSR8» (фиолетовый цвет ключа)
1С:Предприятие 8.0 (8.1, 8.2) Лицензия на сервер (x64) маркируется «H4 M1 Max EN8SA» (зеленый цвет ключа)
Однопользовательские ключи: (синий цвет ключа)
Ключи для всех версий программ маркируются «H4 M1 ORGL8»
Сетевые (многопользовательские) ключи: (красный цвет ключа)
Ключи маркируются в зависимости от числа клиентских лицензий:
Программы группы «1С:Бухгалтерия 8» маркируются «H4 NET5 ORGL8»
Ключи на 5 пользователей маркируются «H4 NET5 ORGL8»
Ключи на 10 пользователей маркируются «H4 NET10 ORGL8»
Ключи на 20 пользователей маркируются «H4 NET20 ORGL8»
Ключи на 50 пользователей маркируются «H4 NET50 ORGL8»
Ключи на 100 пользователей маркируются «H4 NET100 ORGL8»
Ключи на 300 пользователей маркируются «NET250+ ORG8A»
Ключи на 500 пользователей маркируются «NET250+ ORG8B»
Комплекты ключей:
Комплект из 2 ключей «1С:Предприятие 8 Управление производственным предприятием» на 10 пользователй + сервер, а так же комплект из 2 ключей «1С:Предприятие 8 Комплексная автоматизация» на 10 пользователей + сервер, ключи маркируются «H4 NET10 ORGL8» и «H4 M1 ENSR8»
Комплект из 2 ключей «1С:Предприятие 8 Учебный комлект» на 20 пользователей + сервер, ключи маркируются «H4 NET20 ORGL8» и «H4 M1 ENSR8»
Данная система маркировки была введена для удобства идентификации ключа разработчиками и пользователями программного обеспечения.
Для установки однопользовательского и серверного ключей достаточно установить драйвер ключа защиты и вставить ключ защиты в порт.
Для установки многопользовательского ключа защиты требуется определить, какая из машин в сети будет являться сервером. Далее нужно установить на этот компьютер драйвер ключа защиты (HASP4_driver_setup.zip) и службу ключа защиты (HASP_LM_setup.zip), после чего вставить ключ защиты в порт.
Для 1С 7
Сетевые ключи — Красные
Локальные — Серые
+ на ключе шла расшифровка ACC- Бухгалтерия, TRD- Торговля, SAL — Зарплата
Программы однопользовательской группы:
Программы группы «1С:Бухгалтерия 7.7» маркируются «H4 M1 ACCNT»
Программы группы «1С:Зарплата и кадры 7.7» маркируются «H4 M1 QXDXD»
Программы группы «1С:Торговля и склад 7.7» маркируются «H4 M1 WRBQB»
Программы группы «1С:Предприятие 7.7 Комплексная» маркируются «H4 M1 WRBQB»
Программы сетевой (многопользовательской) группы:
Программы группы «1С:Предприятие 7.7 Бухгалтерский учет» маркируются «H4 Net5 ACCNT»
Программы группы «1С:Предприятие 7.7 Зарплата + Кадры» маркируются «H4 Net5 QXDXD»
Программы группы «1С:Предприятие 7.7 Торговля + Склад» маркируются «H4 Net5 WRBQB»
Программы группы «1С:Предприятие 7.7 Комплексная поставка» маркируются «H4 Net5 WRBQB»
Программы группы «1С:Предприятие 7.7 Налогоплательщик» маркируются «H4 Net5 TAXPR»
Программы группы «1С:Предприятие 7.7 Небольшая фирма» маркируются «ACCNT» / «WRBQB» / «QXDXD»
Программы группы «1С:Предприятие 7.7 Управление распределенными информационными базами» маркируются «H4 Net5 DISTR»
Программы группы «1С:Предприятие 7.7 Web-расширение» маркируются «H4 Net5 W31CK»

Выделенный сервер лицензирования «1C»

Выделенный сервер лицензирования «1C»

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

При проведении аудитов инфраструктуры у наших клиентов мы часто даем рекомендацию выделить отдельный сервер для задач лицензирования (такая настройка возможна при использовании требований назначения функциональности платформы 8.3). А также часто сталкиваемся с тем, что не все знают про эту замечательную возможность, предоставленную нам платформой «1С:Предприятие», дающую следующие преимущества:

  • Все имеющиеся программные лицензии можно активировать в едином месте на отдельном (обычно — виртуальном) сервере с минимальными характеристиками по оборудованию — достаточно всего 2-х ядер процессора и около 2–4 Гб оперативной памяти. Единое место размещения программных лицензий упрощает их обслуживание. При необходимости для выделенного сервера можно выполнять полное резервное копирование после каждой активации лицензий, это позволит быстро восстановить работоспособность сервера лицензирования на другом оборудовании. В том числе, например, в удаленном дата-центре, в который доставить аппаратные ключи может быть проблематично.
  • Сам сервер лицензирования не использует (не занимает) серверную лицензию, поэтому для его организации не требуется больше лицензий, чем уже используется при эксплуатации системы.
  • Сервер может раздавать один и тот же набор программных лицензий (и даже одну и ту же программную лицензию) в несколько различных кластеров «1С» (в том числе с различными версиями платформы). В этом случае лицензии занимаются и освобождаются в порядке поступления соответствующих запросов от всех кластеров «1С».
  • Все имеющиеся сервера приложений «1С» могут получать как серверные, так и многопользовательские клиентские лицензии с выделенного сервера лицензирования.
  • Клиентские лицензии будут получаться с единого сервера лицензирования, тем самым обеспечивается более рациональное их использование. Например, исключена ситуация, когда при активации каждой отдельной клиентской лицензии на отдельном сервере «1С» они могут закончиться на одном сервере, но еще могут быть доступны на другом.
  • Становится доступной схема апгрейда, позволяющая заплатить за лицензии меньше, например, условно, приобрести вместо пяти многопользовательских клиентских лицензий на 100 пользователей — одну на 500 пользователей.
  • Любое переконфигурирование имеющихся серверов приложений «1С» в плане виртуального или физического оборудования освободит от необходимости выполнять процедуру повторной активации лицензий. Вам необходимо сохранять постоянной конфигурацию только одного сервера лицензирования, что намного проще. В документации даже прямо говорится об этом: «Чтобы избежать повторной активации (лицензии) рекомендуется использовать сервис лицензирования, установленный на физическом компьютере или на виртуальной машине с фиксированными характеристиками».

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

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

Постановка задачи

В качестве примера рассмотрим следующую исходную ситуацию: у нас есть кластер «1С» , состоящий из одного рабочего сервера SRV1, на версии платформы 8.3.8.2088 (-regport 2041 -port 2040 -range 2060:2091). Все сервисы исполняются на нём, на нем же активирована серверная и многопользовательская программная лицензия.

А также есть еще один кластер, состоящий из одного рабочего сервера SRV2, на версии платформы 8.3.9.1850 (-regport 3041 -port 3040 -range 3060:3091). На нём также исполняются все сервисы, и также активирована серверная и многопользовательская программная лицензия.

Описание параметров портов (report, port, range) приведено .

Требуется вынести сервисы лицензирования с обоих серверов на отдельный сервер лицензирования SrvLic, то есть активировать две серверные и две многопользовательские лицензии на этом сервере и обеспечить их выдачу в оба кластера «1С».

Порядок действий

Все действия для настройки выделенного сервера лицензирования лучше разбить на два этапа:

  • подготовительный — подготовка сервера лицензирования: разворачивание служб «1С» , добавление его в список рабочих серверов в каждом кластере «1С» , проверка активности (доступности для использования);
  • заключительный — активация лицензий на выделенном сервере лицензирования и применение настроек по переносу на него сервиса лицензирования каждого из кластеров «1С».

Такой подход позволит минимизировать общее время простоя системы и устранить возможные проблемы вне этого периода.

Подготовительный этап

Для подготовительного этапа последовательность действий для настройки сервиса лицензирования на выделенном сервере SRVLic будет следующей:

  1. На сервере SRVLic устанавливаем компоненты сервера «1С:Предприятия» 8.3.8.2088 и 8.3.9.1850 (более подробная информация по установке сервера доступна в документации ).

Мы рекомендуем при установке «1С:Предприятие» снять опцию «Установить сервер „1С:Предприятие 8“ как сервис Windows». Это позволит выполнять установку и удаление версий платформы без необходимости остановки служб на сервере.

  1. Развертывание служб «1С» на сервере SrvLic осуществляем с помощью скриптов. Подробное рассмотрение вопросов развертывания разных служб на одном сервере рассматривается в статье «Как правильно обновить платформу „1С“ и запустить несколько служб „1С“ на одном сервере?» по .

Здесь мы ограничимся готовыми скриптами для нашего примера.

Служба «1C» для сервера Srv1:

sc create «1C:Enterprise SrvLic1» binpath= «\»C:\Program Files\1cv8\8.3.8.2088\bin\ragent.exe\» -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d \»C:\Program Files\1cv8\srvinfo_srvlic1\»» displayname= «Агент сервера 1C:Предприятие SrvLic1» obj= «domain\USR1CV8» password= «password» start= disabled depend= Dnscache/Tcpip/lanmanworkstation/lanmanserver,

где

  • domain\USR1CV8 — пользователь от имени которого осуществляется запуск службы (в качестве пользователя желательно использовать доменную учетную запись, обладающую правом запуска служб и полными правами к каталогу указанному в параметре «-d»).
  • password — пароль пользователя, указанного в параметре «obj».

Служба «1C» для сервера Srv2:

sc create «1C:Enterprise SrvLic2» binpath= «\»C:\Program Files\1cv8\8.3.9.1850\bin\ragent.exe\» -srvc -agent -regport 1641 -port 1640 -range 1660:1691 -d \»C:\Program Files\1cv8\srvinfo_srvlic2\»» displayname= «Агент сервера 1C:Предприятие SrvLic2» obj= «domain\USR1CV8» password= «password» start= disabled depend= Dnscache/Tcpip/lanmanworkstation/lanmanserver

Необходимо обратить внимание, что для каждой вновь создаваемой службы должны быть заданы различные каталоги в параметре «–d».

Обратите внимание, что при выборе портов для запуска службы следует учитывать их доступность (это порты не должны быть заняты другими службами или приложениями). Для первой службы мы выбрали диапазон 1560:1591, для второй — 1660:1691. Кроме того, данные порты нужно добавить в разрешенные порты межсетевых экранов.

  1. На сервере SRVLic создаем каталоги служб «1С» и даем на них полные права пользователю «domain\USR1CV8»:

C:\Program Files\1cv8\srvinfo_srvlic1
C:\Program Files\1cv8\srvinfo_srvlic2

  1. Включаем и запускаем службы.

После запуска служб убеждаемся, что они работают, через команду консоли служб «Действия → Обновить»

  1. Удаляем автоматически созданные локальные кластеры «1С» через консоль администрирования серверов «1С» :Предприятие. Для этого регистрируем и запускаем консоль версии 8.3.8.2088:

«C:\Program Files (x86)\1cv8\8.3.8.2088\bin\RegMSC.cmd» (запуск от имени Администратора)

«C:\Program Files (x86)\1cv8\common\1CV8 Servers.msc»

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

«C:\Program Files (x86)\1cv8\8.3.9.1850\bin\RegMSC.cmd» (от имени Администратора)
«C:\Program Files (x86)\1cv8\common\1CV8 Servers.msc»

И также удаляем «Локальный кластер»:

  1. Для функционирования системы программного лицензирования необходимо, чтобы на компьютере SrvLic была запущена служба WMI (Windows Management Instrumentation, http://msdn.microsoft.com/en-us/library/aa394582.aspx). Нужно проверить, что данная служба запущена, если нет — запустить ее (в документации данное требование описано ).
  2. Возвращаемся на сервер SRV1, в консоли администрирования серверов «1С:Предприятие» которого создаем (добавляем) новый рабочий сервер:

  1. Указываем для него имя, например, «Сервер лицензирования», сетевое имя сервера — SRVLic, порт, на котором работает служба «1С» версии 8.3.8.2088, у нас был задан порт 1540, и диапазон портов, который будет использоваться для процессов этой службы, для этой версии был задан — 1560:1591. Остальные параметры оставляем без изменений (большинство из них использоваться не будут).

Здесь нужно обратить внимание, что при добавлении нового рабочего сервера поле «Порт главного менеджера кластера» не доступен для редактирования.

Так как кластер сервера Srv1 развернут на 2041 порту…

… то в настройках добавленного рабочего сервера SrvLic нужно изменить порт главного менеджера кластера с 1541 на 2041. Для этого нужно повторно открыть свойства рабочего сервера SrvLic

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

Для того, чтобы сервисы не начали перераспределяться на только что добавленный сервер SrvLic, нужно сразу создать правило требований назначения функциональности, запрещающее абсолютно всё:

И применить требование назначения функциональности:

  1. Выполняем действия с 7 по 9 пункт для сервера Srv2. Напомним, что порт агента «1С» для добавленного сервера лицензирования SrvLic, на котором работает служба «1С» версии 8.3.9.1850 у нас был задан 1640, а диапазон портов — 1660:1691, порт главного менеджера кластера нужно установить в соответствии с принципами, изложенными в 7 пункте.
  2. Выполним настройку требований назначения функциональности для переноса сервиса лицензирования в добавленный сервер SrvLic. Откроем консоль администрирования серверов для сервера Srv1. В ветке «Рабочие серверы» переходим (раскрываем) добавленный сервер SRVLic, далее у него переходим (раскрываем) ветку «Требования назначения функциональности». Настраиваем требования назначения функциональности на добавленном рабочем сервере SRVLic следующим образом:
    • Требование 1:
      • Объект требования: Сервис лицензирования.
      • Тип требования: Назначать.
      • Имя ИБ: не указывается (оставить поле пустым)
      • Значение дополнительного параметра: не указывается (оставить поле пустым).
    • Требование 2:
      • Объект требования: Любой объект требования.
      • Тип требования: Не назначать.
      • Имя ИБ: не указывается (оставить поле пустым).
      • Значение дополнительного параметра: не указывается (оставить поле пустым).

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

Поясним немного выполненные действия. Требование 1 обеспечит функционирование сервиса лицензирования на сервере SRVLic, а Требование 2 обеспечит функционирование на сервере SRVLic только сервиса лицензирования. То есть на сервере SRVLic не будут функционировать другие сервисы кластера и на него не будут назначаться клиентские соединения.

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

Выполняем эти же действия по настройке требований назначения функциональности для сервера Srv2.

Заключительный этап

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

Проверяем, что сервис лицензирования «переехал» на выделенный сервер лицензирования SRVLic:

На этом всё — после выполнения указанных действий все лицензии можно активировать только на сервере SrvLic, который будет раздавать их в кластера Srv1 и Srv2.

Укажем еще на некоторые моменты и приведем ссылки на документацию:

Стоит обратить внимание, что для надежного получения лицензий из сервиса лицензирования, процессы rphost и rmngr сервера «1С:Предприятия» должны иметь права на создание, чтение и изменение данных в файле 1cv8conn.pfl. Файл содержит список центральных серверов кластера в разрезе информационных баз, а также другую информацию, используемую клиентскими и серверными приложениями платформы «1С:Предприятие». Для надежной работы требуется, чтобы пользователи, от имени которых запускаются приложения системы «1С:Предприятие», имели права на создание, чтение и изменение данных в этом файле. В документации была допущена опечатка относительно места расположения этого файла, которую в ближайшее время исправят или уже исправили. Правильное расположение файла для ОС Windows: %ALLUSERSPROFILE%\1C\1cv8.

Более подробная информация о сервисах кластера есть в документации .

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

В заключение отметим, что несмотря на то, что чисто технически, одну установленную на сервере SRVLic службу «1С» можно использовать для разных независимых кластеров «1С» , выполняя в каждом из них шаги с 6 по 12, мы рекомендуем разворачивать для каждого кластера свою отдельную службу «1С», соответственно на отдельных портах. В случае необходимости, это позволит перезапускать полностью все сервисы кластера, в том числе и сервер лицензирования, причем для каждого кластера (центрального сервера «1С») это можно будет сделать отдельно, независимо от других служб (других кластеров), и таким образом обеспечит более надежное и независимое функционирование ваших систем. Кроме этого, это позволит использовать различные версии платформы «1С:Предприятия» в различных кластерах, и сервер лицензирования никак не будет мешать организации такой схемы работы (именно такой случай мы и рассматривали в этой статье). При этом такая настройка никак не ограничивает и не изменяет механизм использования самих лицензий — по-прежнему, даже один файл программной лицензии (многопользовательский) может использоваться несколькими службами сервера SRVLic и раздаваться в различные кластера «1С» (в том числе в кластера разных версий платформы «1С:Предприятие 8.3»).

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

Дано: сервер, на котором активированы лицензии 1С (или планируется устанавливать лицензии на нем и использовать его в качестве сервера лицензирования), а также имеются сервера, где установлены 1С кластеры, которым требуются лицензии.
Задача: распределение 1С лицензий по разным серверам (кластерам). Например, если на сервере лицензирования активирована одна лицензия на 50 пользователей, то нужно, чтобы этими лицензиями могли пользоваться различные 1С серверы/кластеры.
Помните, что для каждого кластера потребуется серверная лицензия (может быть активирована также на сервере лицензирования), т.е. сколько кластеров, столько и серверных лицензий.
Сам сервер лицензирования лицензии не требует.
В данной статье и в видео будут следующие условные наименования серверов:
Сервер лицензирования — SRV-DB1
Сервер 1С (с установленным кластером) — SRV-NODE-B

  • Как получать лицензии с другого сервера (сервера лицензирования)
  • Как настроить сервер лицензирования
  • Как активировать лицензию на сервере лицензирования

Как получать лицензии с другого сервера (сервера лицензирования)
Если сервер лицензирования (SRV-DB1) уже существует и настроен, то настройка любого другого сервера 1С (в этом примере, SRV-NODE-B) на получение лицензий с сервера SRV-DB1 делается довольно легко. Подробнее смотрите видео ниже.
Краткое описание (все действия выполняем в локальном кластере на 1С-сервере (SRV-NODE-B)):

  1. В рабочие серверы добавляем сервер лицензирования (SRV-DB1).
  2. В блоке рабочего сервера SRV-DB1 добавляем две функциональности в требования назначения функциональности.
  3. В блоке рабочего сервера SRV-NODE-B добавляем две функциональности в требования назначения функциональности.
  4. На локальном кластере делаем полное применение требований функциональности.
  5. Перезагружаем службу 1С.

После этого сервер SRV-NODE-B начнет получать лицензии с сервера SRV-DB1. Т.е. как серверные, так и клиентские лицензии нужно активировать на сервере лицензирования (о том, как активировать читайте ниже).
Посмотреть, как это делалось, можно в следующем видео-ролике:

Подробное описание:
(все действия выполняем в локальном кластере на 1С-сервере (SRV-NODE-B)):
1) В рабочие серверы добавляем сервер лицензирования (SRV-DB1):

В итоге будет два рабочих сервера SRV-NODE-B и SRV-DB1:

2) В блоке рабочего сервера (сервера лицензирования) SRV-DB1 добавляем две функциональности в требования назначения функциональности.

Функциональности должны быть именно в указанной последовательности.
Добавляем сначала:
Любой объект требования (Для всех) — Не назначать

Затем:
Сервис лицензирования — Назначать

В таком случае они «встанут» в нужной последовательности, иначе придется менять приоритет.
Этим мы говорим, что этот сервер готов выдавать лицензии и будет отклонять любые другие запросы.
3) В блоке рабочего сервера кластера SRV-NODE-B также добавляем две функциональности в требования назначения функциональности.

Функциональности должны быть именно в указанной последовательности.
Добавляем сначала:
Сервис лицензирования — Не назначать

Затем:
Клиентское соединение с ИБ — Назначать

Этим мы говорим, что этот сервер готов отвечать на клиентские вызовы, но лицензии он не содержит.
4) На локальном кластере делаем полное применение требований функциональности.
5) Перезагружаем службу 1С.
Также нужно не забыть про настройки локального FireWall — на сервере 1С (SRV-NODE-B) разрешить входящие-исходящие соединения для сервера лицензирования (SRV-DB1).
Как мы делали сервер лицензирования?
Первоначально у нас был один виртуальный сервер, на котором был установлен 1С кластер. На нем были активированы программная серверная лицензия и программная лицензия на 50 пользователей (соответственно в кластере в информационной базе было указано, чтобы клиентские лицензии выдавались с сервера).
Затем понадобился перенос сервера на другую физическую площадку и было также решено выделить под кластер более производительную виртуальную машину. Поэтому существующий сервер оставили в качестве сервера лицензирования, и создали новый виртуальный сервер под 1С кластер.
Как из обычного сервера сделать сервер лицензирования? Если на нем не будут подключаться информационные базы и он будет использоваться только для лицензий, то в дополнению к вышеуказанным инструкциям нужно сделать только одно действие: удалить локальный кластер на сервере лицензирования (не саму программную серверную компоненту 1С, а именно локальный кластер в оснастке кластера, чтобы в списке кластеров было пусто — это видно на скриншотах и видеоролике, что на сервере лицензирования нет кластеров):
Если это сделать, то сервер лицензирования не будет «отъедать» серверную лицензию (т.е. ему самому вообще никаких лицензий не нужно, он только их хранит для других серверов).
Как активировать лицензию в случае сервера лицензирования?
Для этого на клиенте в любой базе (хоть локальной) зайти в конфигуратор, перейти на интерфейс ввода лицензии, нажать Дополнительно и ввести адрес сервера лицензирования.
Активация ключа на сервере:
В этом случае активация произойдет на сервере лицензирования.
После можно проверить, появился ли файл лицензии в папке на сервере (рекомендуется записать, что за файл — эта информация может понадобиться при восстановлении лицензии — см. статью Восстановление по пин-коду).
UPDATE 16.07.2019
Обнаружилась одна неприятная особенность. По крайне мере быстро решить эту проблему не смогли.
Не удается получить лицензии с выделенного сервера лицензирования в случае, если на серверах стоят платформы разной разрядности (битности).

В нашем случае на сервере лицензирования установлена платформа x64 и с этого сервера успешно получают программные серверные и клиентские лицензии два других сервера с 1С-кластерами, на которых также установлена платформа x64.
На третьем кластере установлена платформа x86, по причине того, что он использует аппаратный серверный ключ, предназначенный только для x86 1с-сервера. Клиентские лицензии он брал по сети с аппаратного ключа.
Было решено настроить его на получение программных клиентских лицензий с сервера лицензирования по аналогии с другими серверами. Однако при абсолютно такой же настройке кластер ни в какую не захотел получать лицензии.
При подключении клиентам выдавалось сообщение: Поиск лицензии в сервисе лицензирования: Ошибка вызова сервиса лицензирования: Не найдено ни одного сервера с размещенным сервисом serviceName=LicenseService.
Напишем запрос в 1С, чтобы получить официальный ответ, а пока пришлось вернуться к использованию аппаратного ключа с клиентскими лицензии на этом x86 кластере.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *