Лицензирование СУБД для кластера высокой доступности: бюджет

В чем проблема: HA-кластер и неожиданные расходы на лицензии

Кластер высокой доступности (HA) покупают ради простого обещания: если один сервер или узел упадет, сервис продолжит работать. Для бизнеса это меньше простоев и потерь данных, спокойнее дежурства и понятнее SLA.

Но у HA часто есть сюрприз: лицензии на СУБД могут стоить заметно дороже, чем ожидают. Причина в том, что многие вендоры считают не только «производительность», но и «готовность к запуску». Резервный узел, который кажется бесплатной страховкой, в правилах лицензирования может считаться полноценной вычислительной мощностью, которую тоже нужно покрыть лицензиями.

Путаница усиливается тем, что цели у архитектур разные. Отказоустойчивость отвечает на вопрос «как не упасть», а масштабирование - «как выдержать больше нагрузки». Active-passive обычно про непрерывность, когда второй узел ждет аварии. Active-active чаще про нагрузку и скорость, когда оба узла работают и делят трафик. Бюджет на лицензии при этом может отличаться в разы.

Типичный сценарий: компания закупает два сервера под базу данных (часто вместе с обновлением парка оборудования). ИТ закладывает стоимость СУБД «как за один сервер», потому что второй «простой». На этапе запроса коммерческого предложения выясняется, что правила требуют лицензировать оба узла, весь пул ресурсов или еще и право на перенос нагрузки при сбое.

До разговора с вендором полезно прояснить пять вещей: цель проекта (только failover или еще рост производительности), режим работы (active-passive или active-active), метрику лицензирования (ядра, сокеты, пользователи), планируемые операции (миграции, тестовые переключения, плановые простои) и требования к размещению и поддержке. Чем точнее ответы, тем меньше шанс, что HA станет дорогой неожиданностью уже после выбора архитектуры.

Термины без путаницы: что считать кластером и где он работает

Базовые понятия

В лицензировании СУБД больше всего ошибок возникает из-за слов. Документация может называть «кластером» и пару серверов, и группу виртуальных машин, и весь пул хостов. Поэтому сначала договоритесь о терминах именно в контексте вашей схемы.

Минимум, который стоит различать:

• Узел (node) - отдельный сервер или ВМ, где может запускаться СУБД.
• Инстанс (instance) - запущенный экземпляр СУБД (службы и процессы), который обслуживает базы.
• База данных - набор данных и объектов, который использует приложение.
• Реплика - копия базы (или журнала), поддерживаемая синхронно или асинхронно.
• Кворум (quorum) - механизм, который решает, кто «главный» при сбое, чтобы не случилось двойной записи.

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

Active-passive и active-active простыми словами

Active-passive: один узел обслуживает нагрузку, второй стоит в резерве и должен быстро принять роль основного при сбое.

Active-active: нагрузка распределена между двумя (или более) узлами одновременно, каждый реально работает.

Для бюджета это ключевой водораздел. В active-passive часто пытаются «не лицензировать простаивающий узел». В active-active почти всегда нужно закладывать лицензии на все узлы, которые выполняют рабочие операции.

Переключения и география

Failover - аварийное переключение при сбое. Switchover - плановое переключение (например, для обновления ОС или СУБД). Для лицензий важно, как часто и куда вы переключаетесь: некоторые правила допускают кратковременный запуск на резерве без отдельной оплаты, но плановые переключения могут считаться обычной эксплуатацией.

Если узлы стоят в разных локациях (геокластер) или есть отдельный DR-сайт, это уже не «просто HA». Для DR часто считают лицензии отдельно, потому что появляется еще одна площадка, где СУБД может быть запущена (пусть даже редко). Например, два сервера в основном ЦОД и еще один на резервной площадке - это уже три потенциальных места запуска, и это нужно явно фиксировать в расчете.

От чего зависит цена: тип лицензии и единицы измерения

Стоимость почти всегда упирается не в «саму СУБД», а в то, как в договоре считается право на запуск.

Метрики лицензирования, которые встречаются чаще всего

У разных вендоров правила отличаются, но обычно встречаются три схемы:

• По ядрам (core-based): платите за количество ядер, доступных СУБД на хосте или в виртуальной среде.
• По сокетам (socket-based): платите за процессоры, а не за ядра.
• По пользователям или устройствам (user/device): платите за доступ, а не за железо.

Есть деталь, которая часто «съедает» бюджет: минимальный порог лицензирования на сервер. Даже если у узла мало ядер или вы выделили СУБД небольшой лимит в ВМ, контракт может требовать лицензировать не меньше установленного минимума.

Виртуализация, контейнеры и фиксация того, что вы используете

Виртуализация может менять расчет. Иногда лицензируется конкретная ВМ с закрепленными ядрами, иногда - весь физический хост, на котором ВМ может оказаться из-за миграций. Для HA это критично: если кластер умеет «перекинуть» нагрузку на любой узел, вендор может потребовать лицензии на все узлы, даже если обычно работает только один.

Простой пример: у вас 2 хоста по 16 ядер, а СУБД запускается в ВМ с лимитом 8 ядер. В одном договоре достаточно лицензировать 8 ядер ВМ, в другом - все 32 ядра обоих хостов, потому что ВМ может мигрировать.

Чтобы не спорить с аудитом, заранее решите, чем вы подтверждаете фактическое использование. Обычно хватает схемы кластера с перечнем узлов, настроек закрепления CPU (если применимо), правил миграции и ограничений размещения ВМ, а также отчетов из SAM/систем учета.

Active-passive: за что платят, если второй узел простаивает

Active-passive кажется понятным способом сэкономить: один узел обслуживает пользователей, второй ждет аварии. Но в лицензировании слово «пассивный» часто трактуется строже, чем в архитектуре. Для бюджета важно заранее понять, что именно делает резервный узел в обычный день.

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

Ключевой момент: считается ли узел действительно пассивным. Как только на нем появляется полезная нагрузка, он перестает быть «бесплатным резервом». Частая ловушка - реплика «только для чтения»: отчеты, BI-дашборды, выгрузки для аналитики. Даже регулярные проверки целостности или обслуживание индексов могут трактоваться как активное использование.

Перед закупкой стоит письменно уточнить у вендора:

• можно ли держать установленный экземпляр СУБД на резервном узле без отдельной лицензии и при каких условиях;
• считаются ли бэкапы, мониторинг, задачи обслуживания и read-only запросы активной нагрузкой;
• есть ли ограничения по времени работы резервного узла в активной роли;
• как трактуются плановые переключения для обновлений;
• нужна ли отдельная лицензия для тестовых фейловеров.

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

Практичное правило: если резервный узел, кроме ожидания аварии, еще обслуживает отчеты (пусть даже ночью), бюджет лучше считать так, как будто это второй рабочий экземпляр. Если же узел действительно молчит и нужен только для failover, шанс сэкономить есть, но только при точном совпадении с условиями конкретного вендора.

Active-active: почему лицензии обычно дороже и как это обосновать

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

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

Чаще всего к «использованию» относят клиентские подключения, чтение с реплики, отчеты и аналитику, запись (в multi-master сценариях), обработку очередей и штатный роутинг трафика на узел.

По бюджету это чувствуется быстро. При лицензировании по ядрам рост почти линейный: больше активных узлов и больше ядер на каждом - больше лицензий. Два сервера по 16 ядер: в active-active обычно нужно считать 32 ядра сразу. Добавили третий узел - счет уже на 48.

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

Переплата чаще получается, если второй узел нужен только «на всякий случай» и почти не несет полезной работы. Тогда active-passive с четкими правилами фейловера дает сопоставимый уровень доступности при более понятном бюджете.

Топологии и режимы работы, которые меняют расчет

Даже если вы разобрались с active-passive и active-active, итоговая сумма зависит от того, как кластер будет жить в реальности. Почти всегда всплывает вопрос: сколько узлов могут одновременно выполнять рабочую нагрузку - в том числе временно.

Самый частый вариант - 2 узла. Но в проектах быстро появляются 3 узла (для кворума), схема N+1 (один запасной на несколько рабочих) или растянутый кластер между площадками. Каждый такой шаг меняет расчет, потому что во многих правилах важнее не «сколько серверов стоит», а «сколько может быть активно» и «где именно это может произойти».

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

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

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

Отдельно рассмотрите standby для DR (резервной площадки). Это не то же самое, что HA внутри одной площадки: DR-узел может запускаться редко, но при реальной катастрофе работать неделями. По лицензиям это иногда трактуется как «холодный резерв» с послаблениями, а иногда - как полноценный второй контур, который должен быть лицензирован почти так же, как основной.

Как посчитать бюджет: пошаговый подход до закупки

Начните не с прайса на СУБД, а с того, какую доступность вы реально покупаете. Два кластера с одинаковыми узлами могут отличаться по стоимости лицензий в разы, потому что по-разному определяется, что считается «используемым» в штатном режиме и при аварии.

Пошаговая схема расчета

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

• Определите RTO и RPO и допустимые простои. Уточните, допускается ли ручное переключение или нужно автоматическое.
• Опишите режим работы: какие узлы активны в обычный день и что происходит при отказе. Отдельно укажите, делает ли резервный узел отчеты, бэкапы, тесты, обслуживание.
• Выберите метрику лицензирования и подготовьте цифры: для ядер - модели CPU, число сокетов и ядер на каждом узле; для user/device - оценку активных пользователей и пиков.
• Учтите виртуализацию и ограничения ресурсов. Заранее решите, что именно лицензируется по правилам вендора: весь хост, закрепленные ядра или конкретные ВМ. Добавьте план роста на 12-36 месяцев.
• Посчитайте 2-3 варианта архитектуры и сравните общую стоимость: лицензии, поддержка/подписка, опции для HA, тестовая среда и требования к DR.

Полезно делать расчет через мини-сценарий. Например, два сервера по 16 ядер: в active-passive часто пытаются заложить лицензии только на один узел, но если резервный используется для отчетов или прогрева, расчет легко превращается «как за два». В active-active почти всегда считаются оба узла как продуктивные, зато такую стоимость проще объяснить бизнесу через производительность и меньший риск деградации.

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

Частые ошибки и ловушки, из-за которых бюджет раздувается

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

Чаще всего ошибаются так:

• Путают HA и DR. Для DR часто действуют другие условия (в том числе ограничения по времени работы и отдельные правила для «холодного» сайта).
• Считают пассивный узел бесплатным «по умолчанию». У одних вендоров льгота возможна только при строгих условиях, у других ее нет.
• Не замечают нагрузку на реплике. Чтение, отчеты, проверки целостности, бэкапы, сканирование, индексация, мониторинг и ETL могут превратить «пассивный» узел в рабочий.
• Не учитывают рост числа ядер при обновлении серверов. Переезд на новое поколение CPU часто делает модель «по ядрам» заметно дороже.
• Покупают лицензии под текущую схему без плана масштабирования. Через 6-12 месяцев добавляют узлы или меняют топологию и докупают в спешке.

Небольшой пример: компания берет два узла для active-passive и планирует экономить, делая бэкапы на втором узле, чтобы не тормозить основной. На бумаге это «простой» узел, а по факту он регулярно выполняет рабочие операции и может потребовать полноценной лицензии.

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

Быстрый чеклист перед согласованием закупки

Перед тем как подписывать счет, зафиксируйте, как кластер будет работать в обычный день, а не только «при аварии». От этого чаще всего зависит итоговый бюджет.

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

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

Короткая проверка перед закупкой:

• Есть ли реплики для чтения, и кто к ним подключается (приложения, отчеты, аналитика).
• Какая метрика лицензии выбрана и что именно считается «ядром» или «пользователем» по договору.
• Есть ли лимиты по пользователям/подключениям, включая сервисные аккаунты.
• Есть ли виртуализация и как закреплены ресурсы (фиксированные vCPU/ядра или «плавающие»).
• Зафиксированы ли правила переноса ВМ/узла на другое железо при аварии.

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

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

Пример сценария: сравнение active-passive и active-active для бюджета

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

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

Вариант B: active-active. Оба узла принимают запросы, и переключение проходит мягче. Почти всегда это означает лицензирование обоих узлов, потому что они выполняют полезную работу. Стоимость выше, но ее проще защитить перед бизнесом: вы покупаете производительность и меньшую деградацию во время инцидента.

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

Чтобы расчет не разъехался с фактом, заранее задайте вендору вопросы и попросите ответ письменно:

• считается ли пассивный узел лицензируемым, если он только для failover;
• разрешены ли регулярные тестовые переключения без доплат;
• требует ли лицензии реплика для отчетов или резервного копирования;
• как считаются лицензии при виртуализации и миграции ВМ между хостами;
• что меняется в правилах при добавлении DR (cold/warm/hot).

Следующие шаги: как подготовиться к внедрению и не переплатить

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

Сделайте одностраничное описание целевой архитектуры. Достаточно схемы из блоков: узлы, роли (кто активен), способ репликации, где хранятся данные, что считается отказом и как происходит переключение. Добавьте цифры: число сокетов или ядер, ожидаемое число пользователей, среды (prod/test/dev) и требования к RPO/RTO.

Дальше запланируйте пилот и тесты переключений. Часто выясняется, что «пассивный» узел не такой уж пассивный: на нем крутятся бэкапы, отчеты, мониторинг, или он временно обслуживает чтение. Это может лишить льгот для standby и заметно повлиять на стоимость.

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

Последовательность, которая обычно экономит время и деньги:

• Описать архитектуру на 1 странице и утвердить ее с ИТ и безопасностью.
• Провести пилот и тесты failover с фиксацией реальной нагрузки узлов.
• Получить у вендора СУБД подтверждение правил для standby, реплик и DR.
• Разнести лицензии по средам (prod/test/dev) и заложить рост на 12-24 месяца.
• Параллельно проверить платформу: серверы, сеть, СХД, резервирование питания и охлаждения.

Если проект включает поставку железа и интеграцию под HA и дата-центр, заранее обсудите платформу с интегратором. Например, GSE.kz (gse.kz) как производитель и системный интегратор в Казахстане может помочь подобрать серверы под целевую топологию (в том числе линейки S200) и собрать решение с учетом требований к поддержке 24/7, чтобы архитектура и лицензии не расходились с реальной эксплуатацией.