Сервер лицензирования 1С на 12 тыс. пользователей: настройка, мониторинг, резервирование

Доклад основан на реальной истории. Его задача – помочь кому-то из вас пройти этот путь с меньшими затратами времени и нервов.

Небольшой план доклада, о чем поговорим:

• Немного расскажу о себе и своей команде.

• Потом мы рассмотрим постановку задачи, которую нужно было решить с учетом высоких требований по доступности систем.

• Поговорим о резервировании лицензий.

• И я дам детальный план по настройке серверов лицензирования.

Для начала пару слов о себе.

У меня больше 15 лет опыта в разработке на 1С. За это время была возможность поработать в фирме-франчайзи, организовать свой франч и даже поучаствовать в проекте внедрения ERP на ракетном заводе.

Но мне всегда была интересна именно экспертная тема – оптимизация запросов, работа СУБД и расследование нестандартного поведения платформы.

И для этого у меня сейчас есть все возможности – больше года я руковожу командой эксплуатации платформы 1С в «Билайне».

У нас один из самых высоконагруженных проектов на 1С в России:

• В основной системе 1CRetail, которая является фронтом для всех точек продаж, работает больше 5000 пользователей в одной базе.

• Территориально офисы у нас расположены от Калининграда до Владивостока, что обусловливает режим работы с базой 24/7.

• Размер базы уже порядка 11 терабайт.

• SLA 99,98.

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

1. Администрирование серверов.

2. Контроль за производительностью систем.

3. Проведение нагрузочного тестирования.

4. Развитие DevOps-практик в департаменте разработки розничных решений.

Основная же наша задача – это все-таки стараться ничего не уронить на проде, либо максимально быстро поднять то, что уже упало. Время реакции на аварию у нас не превышает пяти минут – такой экстремальный траблшутинг.

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

Перейдем к теме доклада – расскажу, что такое сервис лицензирования и для чего он нужен.

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

Выделение сервиса лицензирования на отдельную машину удобно, потому что:

1. это повышает надежность системы в целом;

2. если у вас несколько систем или даже несколько кластеров, использование лицензий оптимизируется;

3. большое количество лицензий удобно хранить физически в одном месте.

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

1. Берем сервер.

2. Добавляем его в кластер.

3. Открываем для сервера «Требования назначения функциональности» и добавляем туда две строчки:

   • «Сервис лицензирования – Назначать»,

   • «Для всех – Не назначать».

Применяем настройки и, бинго, – ваш сервер лицензирования готов.

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

1. 5 кластеров;

2. разные версии платформы в продуктах;

3. работает в совокупности больше 8000 пользователей;

4. уровень критичности основной системы – Mission critical, это максимальный уровень критичности для бизнеса;

5. SLA, который мы должны обеспечивать – 99,98, это максимум 80 минут недоступности в год;

6. плюс мы участвуем в проекте бета-тестирования платформы, и это тоже добавляет рисков.

Для чего нам понадобился выделенный сервер лицензирования?

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

В 2022 году кластер нашей основной системы 1CRetail выглядел следующим образом:

• В кластере было 6 рабочих серверов в двух физически распределенных ЦОДах.

• 2 из этих серверов были центральные.

• На одном из этих центральных серверов было активировано 8000 лицензий – это весь наш пул лицензий.

• В пике с системой работает порядка 5500 пользователей.

• Версия платформы на тот момент была – 8.3.22.1529.

Небольшая предыстория. После полугода работы разработчиком в продуктовой команде мне предложили занять вакантное место эксперта, тимлида команды эксплуатации. На тот момент в бэклоге уже довольно долго лежала задача с названием «Единый центр лицензирования 1С». Задача, видимо, не срочная, раз она там уже полгода лежала. Скажу честно, тогда было совсем не до лицензий – нужно было разобраться со всей инфраструктурой, кластерами и прочим.

Прошло 1,5 месяца, я пошла в отпуск. Август, Крым, море и утро – в принципе, ничего не предвещало беды.

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

Я пытаюсь подключиться по RDP к основному центральному серверу – в ответ тишина.

Стало очевидно, что у нас авария. Единственное, что мы увидели – это всплеск нагрузки на центральном сервере по процессору до 100%. А поскольку все лицензии были активированы именно на этом сервере, единственным решением была перезагрузка.

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

В деньгах – это 1 миллион рублей потерянной прибыли.

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

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

Другие системы на поддержке

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

Помимо основной системы 1CRetail, в этом проекте участвовал еще ряд систем, которые были у нас на поддержке. Расскажу про их особенности.

Первая система – WIIC, система для внутренних заказчиков:

• Под нее в кластере использовалось два виртуальных сервера.

• Один из серверов на тот момент уже был сервером лицензирования – на нем было активировано 1500 лицензий.

• В системе работало 400-500 пользователей.

• SLA тут помягче – 99,5.

• Версия платформы на тот момент была 8.3.21.1302.

Следующая система – это Web1С, база мобильного приложения 1CRetail:

• Эта система занимала два физических сервера.

• Для нее было активировано 1500 лицензий.

• При этом в самой системе работало не больше 200 пользователей – был большой запас по лицензиям.

• Версия платформы – 8.3.22.1529 (такая же, как на продуктиве основной системы 1CRetail).

И последняя система – это WorkOrder, система для учета оборудования и недвижимости:

• Здесь у нас было 2 кластера с виртуальными серверами – в совокупности 3 сервера.

• Под эту систему у нас активировано 1500 лицензий.

• Сейчас в ней работает 500-600 пользователей, но в ближайшее время мы ожидаем рост активных пользователей там до 2000.

• Версии платформы тут были 8.3.21.1302 и ранняя сборка из 8.3.22.923.

Железо VS Виртуальная машина

Первый вопрос, который нужно было решить, это какое оборудование выбрать под выделенный сервер лицензирования – виртуалку либо физическую машину?

Первый вариант, который мы рассматривали – это виртуальная машина. Ее плюсы:

• Современно, быстро, удобно и в некотором плане надежно: если на одном хосте упало, на другом тут же поднялось.

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

• В качестве операционной системы для виртуальной машины под выделенный сервер лицензирования мы по совету наших виртуальщиков рассматривали Linux как наиболее надежный вариант. В фирме «1С» нам подтвердили, что проблем при использовании в кластере серверов с разными операционными системами возникнуть не должно – это вполне рабочий вариант.

• Но тут один большой минус – для такого сервера нам могли гарантировать SLA только 99%, и то при отсутствии полноценного DR-решения. Понятно, что с нашим SLA это никак не бьется, тем не менее мы решили попробовать.

В общем, пока мы решали бюрократические вопросы – выбирали ЦОД, в котором будем разворачивать виртуалку, потом заводили RFC на перезаливку операционной системы – за этот промежуток времени на наших внутренних виртуальных платформах произошло 4 аварии. Стало понятно, что SLA действительно вряд ли будет выше 99%. Поэтому, немного подумав, мы решили все-таки свернуть с этого пути в сторону более традиционного для 1С железа.

Особенности железного сервера:

• С ним все привычно и понятно.

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

• Мы у себя нашли два физических сервера с процессором на 12 ядер и 64 ГБ памяти – при таком железе загрузка у нас не превышала 5-10%.

• Причем здесь было достаточно гораздо меньшей мощности – вполне хватит 4 ядра процессора и 16 ГБ памяти.

Upd. В 2024 году вся инфраструктура 1С билайна (кроме СУБД) переехала в корпоративное облако в новом ЦОДе.

Практическая часть: настройка служб

С оборудованием мы определились. Дальше нужно было разобраться, как с одного сервера раздать лицензии на несколько кластеров. Здесь тоже ничего сложного:

• Для каждого кластера нужно поднять свою службу сервера 1С на своем диапазоне портов.

• Запуск этих служб должен быть настроен под той техучеткой, от которой работает кластер.

• Активировать лицензии вручную или скриптом.

• И добавить серверы лицензирования в кластер.

В принципе, на этом все – пока не начинаешь это делать на проде, выглядит совсем несложно.

Если кто-то переживает по поводу серверных лицензий, то для сервера лицензирования она не нужна, как и для других сервисов кластера, кроме клиентских соединений.

Тесты: проверка на прочность

Перед тем, как настраивать сервер лицензирования на продуктиве, мы решили провести некоторые тесты. В нашем распоряжении был кластер нагрузочного стенда. Он по конфигурации похож на кластер основной системы 1CRetail. Плюс у нас было 2 маленькие лицензии на 10 и 30 пользователей.

Мы проверяли работу сервиса при различных нештатных ситуациях и пытались разобраться, как технически сервис лицензирования работает.

Какие результаты мы в итоге получили:

1. Одна многопользовательская лицензия спокойно используется несколькими менеджерами кластера – они используют общий пул лицензии совместно в рамках ее лимита. И вообще никаких проблем не возникает.

2. Следующий момент более интересный с точки зрения отказоустойчивости. Проверка лицензий выполняется только при начале клиентского сеанса. Клиент подключается, получает программную лицензию, и может жить на этой лицензии даже несмотря на возможную недоступность сервера лицензирования. Понятно, что новые при этом подключиться не могут, но существующие продолжают работать.

3. С новыми подключениями тоже есть небольшой нюанс, связанный с файлом профиля пользователя 1cv8conn.pfl – он позволяет получить лицензию с последнего успешно работавшего сервера в течение небольшого промежутка времени (на ИТС заявлено 20 секунд, на практике – дольше).

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

Резервирование: поиски обхода

Давайте чуть подробнее рассмотрим тему резервирования.

У нас в наличии было 12 000 лицензий.

При этом активных пользователей – 8 000 (если считать с небольшим запасом – 9 000).

А для полноценного резервирования лицензий должно быть в два раза больше – в нашем случае, 18 000 лицензий, стоимость которых больше имеющихся 12 000 примерно на 42 млн. рублей. Поскольку никто тогда не горел желанием выделять бюджет на дополнительные лицензии 1С, первое, с чего мы начали – это попытались найти возможность обмануть систему.

Сначала посмотрим на то, какие возможности и ограничения нам предоставляет сама платформа:

1. Сервис лицензирования может жить только на одном рабочем сервере в кластере. Раздавать лицензии с двух серверов вы совершенно точно не сможете.

2. Как я уже говорила, есть 24 часа на то, чтобы переактивировать лицензию, если у вас изменилось железо.

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

Какие варианты мы рассматривали?

• Вариант №1. Мы все-таки хотели попробовать использовать одинаковые файлы лицензии и положить их на основной и резервный сервер. Подразумевалось, что поскольку сервис может жить только на одном рабочем сервере в кластере, то, по идее, факта использования одинаковых файлов с двух разных компьютеров возникнуть не должно. Но это в теории. Как показали тесты на практике, лицензия на самом деле блокируется.

• Вариант №2. Привязать все программные лицензии к USB-ключу. Здесь есть особенность: если у вас сломался ключ USB, это то же самое, что изменилась конфигурация железа. У вас есть те же 24 часа на то, чтобы решить эту проблему или переактивировать лицензии – а для нас было главное, что недоступности быть не должно. Но тут, наверное, сыграл свою роль наш негативный опыт по работе с ключом USB на тестовой среде – где-то раз в 3-4 месяца этот ключ перестает определяться системой, и помогает только перезагрузка сервера, на котором этот ключ установлен. Понятно, что для продуктива критичной системы такая ситуация недопустима. Поэтому этот вариант мы тоже отложили.

Рабочий вариант

К чему мы пришли:

• Изначально мы вообще хотели активировать весь пул лицензий на основном сервере, а в случае аварии быстро переносить их на резервный сервер каким-нибудь способом – например, скриптом. Но в итоге, поскольку у нас был небольшой запас по лицензиям, мы решили все-таки разбить пул лицензий на основной и резервный: 8000 мы активировали на основном и 4000 на резервном.

• Требования назначения функциональности у кластеров мы настроили с учетом SLA и уровня критичности этих систем:

  • Для основной системы 1CRetail мы добавили основной и резервный сервер в кластер:

    • на основном сервере установили ТНФ: «Сервис лицензирования – Назначать» с приоритетом 1;

    • на резервном сервере установили ТНФ: «Сервис лицензирования – Назначать» с приоритетом 0.

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

Что нам это дало? Какой план на случай аварии мы получили?

• При недоступности основного сервера сервис лицензирования автоматически переезжает на резервный сервер, но выдает лицензии он только для критичной системы 1CRetail. На резервном сервере у нас есть 4000 лицензий, поэтому недоступности не возникает. Причем, как показали тесты, работать смогут не только 4000 пользователей, потому что существующие на момент аварии подключения так и будут продолжать жить на лицензиях, которые получили с упавшего сервера. Но новых мы сможем подключить еще 4000.

• После того как мы выиграли немного времени, нам нужно перенести эту дельту лицензий с основного сервера на резервный – в нашем случае это 8 лицензий по 500 пользователей. Как можно быстро перенести, переактивировать эти 8 лицензий? Понятно, что вариант с конфигуратором и отправкой писем в центр лицензирования 1С нам не очень подходит. Поэтому мы решили использовать консольную утилиту ring, которая умеет в программном режиме управлять лицензиями.

• После того, как лицензии переактивированы, мы меняем требование назначения функциональности для остальных систем, где у нас резервный сервер лицензирования фактически был отключен – поднимаем приоритет ТНФ для сервиса лицензирования.

• Дальше мы разбираемся с причинами недоступности основного сервера, чиним его.

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

Немного devops

Пару слов о скрипте. Как я уже сказала, он использует утилиту ring:

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

• Написан он на powershell.

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

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

• Мы у себя запускаем этот скрипт вручную. Для удобства добавили его в ЦКК – у нас там два сценария: один для основного сервера, второй для резервного.

• По нашим замерам время на активацию одной лицензии порядка 10 секунд. У нас 8 лицензий, 1,5 минуты – время более чем приемлемое.

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

Скрипт выложен на GitHub, можно скачать по ссылке https://github.com/prom07/lic_activation.

Возможные ошибки

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

• У первой ошибки несколько причин:

  • Например, у вас может быть закрыт доступ к центру лицензирования 1С.

  • Либо проблема связана с Java, которая не видит системные настройки прокси – их нужно прописать вручную в переменной окружения RING_OPTS.
    На слайде приведен пример, как должна выглядеть такая настройка.

• Вторая ошибка, с которой мы столкнулись: центр лицензирования 1С перегружен. Здесь могу дать только один совет – не ждать 15 минут, скорее всего со второй попытки запрос будет обработан успешно.

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

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

• При экстренном переносе серверной лицензии на центральный сервер мы поймали для нее блокировку. Нам для решения оказалось достаточно удалить файлы профиля пользователя 1cv8conn.pfl и conn8211.pfl из каталога системной учетной записи. Но здесь может быть несколько вариантов – на слайде я привела ответ от техподдержки фирмы «1С»: нужно удалить все файлы 2*.lic от старых лицензий, которые используются, плюс еще файлы профиля пользователя.

• Нужно обязательно знать ваши регистрационные данные для лицензии, которые вы указывали при первой ее активации. Изменить их нельзя. В нашем случае лицензия была активирована на сотрудника, который в компании уже не работает. Тем не менее все равно пришлось указывать его данные, потому что, как оказалось, ничего поменять уже нельзя. Это важно для скрипта активации лицензии, потому что даже один символ, лишний пробел или другой регистр буквы вам просто не даст перенести эти лицензии на резервный сервер.

• Не знаю почему, но я была уверена, что приоритет в требовании назначения функциональности 1 ниже, чем 0. Чтение ИТС в этом понимании мне не помогло. Если вы тоже так думаете, то это работает по-другому: сервер, где для сервиса установлен приоритет 1 – будет считаться для него основным. А сервер, где этот же сервис указан с приоритетом 0 – будет резервным.

• И еще одна проблема, которую мы поймали, была связана с сетевым доступом к серверу. Она была именно на тех серверах, которые находились в DMZ-зоне. Там были закрыты порты для тех служб по лицензированию, которые мы разворачивали именно для сервиса лицензий. Здесь остается только открывать порты и договариваться с безопасниками.

Финальный план настройки

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

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

План тоже выложен на GitHub рядом со скриптом.

Понятно, что он не гарантирует, что у вас все получится с первого раза. Но, тем не менее, от наших ошибок он точно защитит.

Процесс эксплуатации

Переходим к финальной части – к процессу эксплуатации.

Здесь важно настроить мониторинг и алертинг.

• Для стандартного набора мониторинга по железу мы используем Prometheus.

• Для визуализации – Grafana.

• Performance Monitor мы используем дублирующей системой по сбору метрик для расследования аварий.

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

• По техжурналу – на серверах лицензирования мы анализируем только ошибки EXCP. Для парсинга файлов техжурнала используем Filebeat, все данные грузим в Elasticsearch.

И алертинг – на что мы реагируем:

• Стандартный алертинг Zabbix – он информирует нас о превышении пороговых значений по загрузке железа.

• Мы контролируем отсутствие запущенных процессов ragent и rmngr кластера 1С.

• И контролируем наличие дампов процессов.

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

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

Опыт эксплуатации

В качестве положительного опыта эксплуатации расскажу еще одну историю об аварии. Она уже посвежее, произошла в августе 2023 года.

• Симптомы – количество транзакций и чеков упало до критичных значений, сработали соответствующие алармы.

• Признаками проблемы было зависание приложения – пользователи при входе в 1С и при работе с ней получали зависание.

• Подозрение сразу пало на центральный сервер, что с ним что-то не так. Я также попыталась к нему подключиться – он не подключается, но при этом пингуется, т.е. с сетевой связностью никаких проблем нет.

• Было принято решение просто вручную вывести его из кластера, поскольку лицензий на нем уже нет, и он в принципе не является незаменимым узлом – второй центральный сервер у нас вполне работоспособен. Как только применили настройки, система тут же ожила, проблема устранилась, пользователи начали нормально работать.

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

• Причина была связана с тем, что произошла резкая деградация производительности дисковой подсистемы. Но поскольку физически сервер был доступен, механизмы отказоустойчивости платформы не сработали. Если бы сервер умер совсем, ситуация была бы гораздо лучше – мы бы недоступности точно не получили. Тем не менее 8 минут против 30 в прошлом году при похожих симптомах – думаю, эффект хороший.

Заключение

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

Вопросы и ответы

Почему вы с помощью сервера лицензирования не раздаете серверные лицензии для ваших рабочих серверов?

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

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

Смысл в том, что теперь у нас ни один сервер в кластере не является незаменимым. До этого у нас лицензии были на центральном сервере, и мы не могли с ним ничего сделать. Например, в прошлом году мы были не готовы переносить лицензии вручную и переактивировать их. А сейчас мы можем любой сервер кластера просто выкинуть из кластера. И проблем не возникнет.

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

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

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

Потому что гипервизор дает 99% SLA, а нам для работы нужно 99,98%. Это большая разница.

Насколько я помню, Ring раньше позволял активировать лицензию 3 раза?

Это серьезное и массовое заблуждение, что у программной лицензии есть всего 3 пин-кода. Нет, у программной лицензии бесконечное количество пин-кодов – мы на тестовой среде активировали очень много раз.

Другое дело, что по истечении первых трех, которые вам сразу даны, можно получить только один. Вы его получили, активировали, сразу запрашиваете еще один. И так бесконечно. Нельзя получить еще миллион. Можно получать по одному, но бесконечно. Но при этом текущий, последний, у вас должен быть уже активирован.

Этот дополнительный пин-код вы получаете вручную?

Да.

А это можно как-то автоматизировать?

Мы спрашивали у фирмы «1С», вариантов это автоматизировать нет. Но можно для автоматизации написать скрипт, который просто будет отправлять письмо на lic@1c.ru, а потом парсить ответ.

Что выгоднее: держать один большой файл с 10000 лицензий? Или кучу файликов на маленькое количество?

Вообще разницы нет, кроме того, что вы будете гораздо быстрее переактивировать одну лицензию, чем 50 по 20.

И купить выгоднее одну лицензию на 1000 пользователей, чем 50 по 20 – это просто дешевле.

Но вообще лицензий на 10000 пользователей нет. Максимум на тысячу.

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

У нас клиенты работают по всей России, проблем с клиентскими лицензиями ни разу не было.

А все эти методики со включением второго сервера в кластер для лицензий ПРОФ вообще работают, или это только для КОРП?

Разницы нет. Это решается через ТНФ. Практически все ТНФ работают на ПРОФ. На КОРП просто более тонкая настройка возможна.

Для мониторинга лицензий и вывода в Grafana вы используете утилиту RAS?

Да. Там о лицензиях вся информация есть, там и номера, и количество использованных лицензий.

Вы в докладе сказали, что сервер лицензирования может неожиданно переключиться. Это как?

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

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

Обращайте внимание, у кого кластер, правила ребута серверов в кластере очень жесткие. Сначала должны встать в строй все не центральные сервера. И только потом централки. Чтобы, когда централки встали и начали применять ТНФ на кластер, у него в наличии было все, что у вас описано в ТНФ. Иначе может случиться вот такое.

Чтобы это вернуть, не надо перезагружать сервера. Надо просто по кластеру правой кнопочкой применить «Полное». Когда вы применяете «Полное», кластер перечитывает ТНФ и применяет их заново.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT.