Кратко

  • В историческом учебном примере Meraki добавление двух годовых лицензий на коммутаторы переносит общую дату окончания с 16 апреля на 14 марта 2017 года — на 33 дня раньше.
  • В модели Co-Term дата зависит от лицензированного лимита и взвешенных сроков. Число реально подключённых устройств, добавление новых лицензий и продление имеющихся требуют раздельного учёта.

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

В подробном объяснении алгоритма этот эпизод находится в примере C. На 31 марта 2015 года у описанной организации остаётся 747 дней. К ней добавляют два коммутатора MS42P с годовыми лицензиями. Опубликованный результат — 714 оставшихся дней: вместо 16 апреля 2017 года общей датой становится 14 марта.

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

Покупка входит в общий календарь

Co-Termination объединяет лицензии одной организации общей датой окончания. Обзор модели описывает её как взвешенное усреднение. Организация здесь — административная группа Meraki, внутри которой применяется лицензирование.

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

Для добавленных устройств из нового срока сначала вычитают оставшийся срок организации. Затем разницу взвешивают по типам и количеству лицензий и распределяют по общему весу пула. Отрицательная разница даёт отрицательную прибавку к календарю. В этом и состоит объяснение примера с двумя коммутаторами.

Длинная новая лицензия может двигать общий конец в противоположную сторону. Поэтому слово «добавить» само по себе мало говорит о дате. Нужны срок добавки и состояние того пула, куда она попадёт. Календарь реагирует на состав лицензий, а не на настроение закупки.

Выключенный ящик не останавливает часы

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

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

Это особенно важно при обновлении парка. Удалённое устройство может освободить место в текущем счёте, но сама эта запись не возвращает время. Сколько оборудования сейчас работает и на какой срок рассчитано лицензирование, приходится проверять отдельно.

Отложенное применение купленной лицензии также не даёт паузы. Обзор указывает, что время начинает расходоваться с момента обработки лицензии, а ожидание её добавления в Dashboard не переносит старт. Решение «сначала купить, а активировать позже» должно учитывать уже идущий срок.

Продление меняет не только дату

Добавить лицензии для новых устройств и применить ключ как продление — разные действия. Для продления без добавления устройств подробный FAQ использует полный купленный срок. Для новых устройств в расчёт входит разница между новым и оставшимся временем.

Кроме того, операция Renew my Dashboard license приводит лицензированные количества в соответствие с новым ключом. Обзор приводит ещё один пример: организация с покрытием пяти точек доступа применяет трёхлетнее продление лишь на две. Прежнее оставшееся время сохраняется, но покрытие теперь рассчитано на две точки. Если продолжают работать все пять, три окажутся сверх лимита.

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

Для Co-Term обзор описывает 30-дневный льготный период при превышении лимитов или окончании лицензий. Без исправления состояния организация будет отключена. Превышение количества можно исправить удалением лишних устройств из сетей либо добавлением нужного покрытия; при истёкшем сроке требуется новое лицензирование активного парка. Удаление может решить вопрос количества, сохранив дату прежней.

Сначала определить модель

Текущий общий FAQ разделяет Co-Term, Subscription и прежнюю Per-Device Licensing. В одной организации используется одна модель. Subscription и Co-Term доступны, а новые переходы на PDL уже не поддерживаются.

Правило общей даты относится к организации на Co-Term. Подписочная модель имеет собственное устройство лицензирования. FAQ допускает переход с Co-Term на Subscription, но обратный переход к Co-Term или прежней PDL не поддерживается. Это отдельное решение о дальнейшей работе организации.

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

Пример Meraki хорош своей прямотой: закупка состоялась в учебном расчёте, покрытие добавилось, общий срок сократился. Для покупателя полезный итог заказа включает новую дату всего пула. Иначе коммутаторы получит один участок бизнеса, а более ранний разговор о продлении достанется всем.