SQL Server Core или Server+CAL: расчет для 50-1000 пользователей

В чем задача: выбрать модель и не переплатить при росте

Один и тот же SQL Server может оказаться «дорогим» или вполне разумным по бюджету только из-за выбранной модели лицензирования. На старте Core и Server+CAL часто выглядят сопоставимо, но при росте пользователей, устройств и филиалов итоговая сумма расходится в разы.

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

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

Обычно всплывают такие вопросы:

• Считать по пользователям или по устройствам, если у сотрудника ноутбук и телефон?
• Как учитывать общие рабочие места, смены и стойки регистрации?
• Что делать с внешними подрядчиками, аудиторами и временными сотрудниками?
• Как считать доступ через терминальный сервер, VPN и из филиалов?

Где чаще всего переплачивают: покупают «с запасом» без понятной модели роста. Например, планируют 200 пользователей «на всякий случай», хотя реально будет 80, но с быстрым ростом по филиалам через год. Или наоборот - берут минимум CAL, а потом докупают рывками, попадая на неудобные сроки закупки и согласований.

Практичный подход: сначала описать, как именно люди и системы будут подключаться сейчас и через 6-12 месяцев, и только потом выбирать модель. Для организаций в Казахстане это особенно важно, когда закупки идут по плану и нужно заранее обосновать расширение. Дальше разберем расчет по шагам и дадим ориентиры для 50, 200 и 1000 пользователей.

Core и Server+CAL простыми словами

У SQL Server есть две популярные модели лицензирования: Core и Server+CAL. Выбор влияет не только на цену сейчас, но и на то, как расходы будут расти, когда добавятся филиалы, удаленные сотрудники или новые системы.

Core устроена просто: вы платите за вычислительные ресурсы сервера, то есть за количество ядер (по правилам Microsoft есть нюансы, но смысл в этом). Кто и сколько подключается к базе, обычно отдельно не считают. Такой вариант удобен, когда подключений много и их трудно контролировать.

Server+CAL состоит из двух частей: лицензия на сам сервер плюс лицензии CAL на доступ. CAL бывает двух типов:

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

CAL простыми словами - это «пропуск» на подключение к SQL Server. Если у вас 200 сотрудников, которым нужен доступ к базе, это часто означает до 200 CAL (или меньше, если доступ есть не у всех, или если выгоднее считать по устройствам).

Главная ловушка в том, что Core и Server+CAL нельзя сравнить «на глаз». Два предложения с похожей ценой сегодня могут дать противоположную итоговую стоимость через год. В Server+CAL каждый новый филиал и каждое новое рабочее место часто добавляют CAL. В Core рост пользователей почти не меняет лицензии, пока вы не наращиваете сервер.

Пример: в головном офисе 50 пользователей и один сервер. Через полгода открылись 5 филиалов и появилось еще 150 сотрудников, которые заходят в учетную систему. При Server+CAL вы почти наверняка докупаете CAL под новых пользователей или устройства. При Core вы чаще думаете о мощности сервера и нагрузке, а не о количестве подключений.

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

Какие исходные данные собрать перед расчетом

Перед тем как выбирать Core или Server+CAL, полезно собрать факты, а не предположения. Лицензирование обычно «ломается» не на цифре пользователей, а на том, как люди и системы реально подключаются.

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

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

Чтобы не упустить детали, соберите минимум:

• Серверы и инстансы: сколько сейчас, сколько добавится через год, где будет продуктив, тест и резерв.
• Процессоры и ядра: число физических ядер по каждому серверу, есть ли гипервизор и сколько ВМ под SQL Server.
• Кто и как подключается: офис, филиалы, удаленка (VPN/RDP), терминальные серверы, подрядчики.
• Устройства: сколько устройств на человека (ПК, ноутбук, планшет), есть ли общие ПК на сменах.
• Интеграции и «промежуточные» системы: 1С/CRM/BI, веб-приложения, мобильный доступ, сервисные учетные записи.

Короткий пример: если у вас 50 сотрудников, но 10 филиалов подключаются к общей базе через терминальный сервер, а еще есть веб-кабинет для партнеров, «50 пользователей» перестает быть понятной цифрой. Заранее выпишите всех, кто инициирует подключение к SQL Server, и по какому пути он идет. Это дает основу для расчета и защищает от переплаты при росте.

Как посчитать Server+CAL: пошаговая схема

Модель Server+CAL обычно выгодна, когда серверов SQL немного, а число людей, которые реально подключаются к базе, предсказуемо. Логика простая: вы покупаете лицензию на сам SQL Server (на каждый сервер/экземпляр) и отдельные CAL для пользователей или устройств.

Чтобы расчет не превратился в угадайку, идите по шагам.

Шаг 1. Описать доступ к SQL. Кто подключается из головного офиса, кто из филиалов, есть ли удаленка (VPN/RDP), общие рабочие места (касса, стойка регистрации, терминалы), интеграции (1С, BI, веб-портал) и кто ими пользуется.

Шаг 2. Посчитать CAL в двух вариантах.

• Per User CAL: считайте людей, которым нужен доступ с любого устройства (ноутбук, домашний ПК, телефон, тонкий клиент).
• Per Device CAL: считайте устройства, с которых подключаются разные люди (общие ПК в сменах).

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

Шаг 3. Добавить серверные лицензии. Лицензия SQL Server нужна на каждый сервер, где установлен SQL Server. Если планируется тестовый/резервный сервер или второй узел для отказоустойчивости, заранее уточните, потребует ли он отдельной лицензии в вашем сценарии.

Шаг 4. Заложить рост. Минимум: +20% к числу пользователей или устройств. Отдельной строкой - новые филиалы и новые общие рабочие места. Хороший тест: что будет с бюджетом, если через год появится еще 2 филиала и две смены вместо одной.

Шаг 5. Сравнить с Core на тех же вводных. Версия SQL Server, схема доступа и прогноз роста должны быть одинаковыми. Тогда сравнение будет честным.

Небольшой пример: в поликлинике 60 сотрудников, но подключаются к системе в основном 25 врачей и регистратура с 6 общих ПК в две смены. Per User может быть выгоднее для врачей, а Per Device - для регистратуры. Смешивать типы CAL нельзя, поэтому важно выбрать один вариант, который лучше отражает реальный доступ.

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

Как посчитать Core: пошаговая схема

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

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

Дальше решите, будет ли SQL Server в виртуальных машинах. Если да, важно понимать, где они будут работать (на одном хосте или на разных) и будут ли мигрировать между хостами.

Практичная схема подсчета выглядит так:

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

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

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

Быстрые ориентиры для 50, 200 и 1000 пользователей

Единого «правильного» ответа нет, но для первичной оценки помогает простая логика: Server+CAL чаще выгоднее, когда пользователей и точек доступа немного и их легко посчитать. Core чаще выигрывает, когда подключений много и контроль размывается.

50 пользователей. Имеет смысл честно сравнить оба варианта. Если у вас 1-2 сервера, доступ только из офиса, пользователей немного и они «именные», Server+CAL часто выглядит дешевле. Но если часть сотрудников работает через общие терминалы, есть подрядчики или планируется быстрый рост, Core обычно проще в сопровождении.

200 пользователей. Стоимость CAL начинает заметно давить. На итог сильнее всего влияют филиалы и удаленный доступ: чем больше точек входа и смен, тем выше риск недосчитать реальных пользователей и докупать CAL в спешке. На этом масштабе компании нередко переходят к Core, особенно если база обслуживает несколько систем сразу.

1000 пользователей. Core часто становится естественным выбором, потому что считать и контролировать CAL сложно, а подключений обычно много. Но если архитектура централизованная, доступ строго ограничен, а пользователей реально мало (например, только узкая группа операторов), Server+CAL все еще может быть конкурентным.

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

Сильнее всего меняют расчет такие вопросы:

• Сколько реальных точек доступа к базе (офисы, филиалы, удаленка, подрядчики)?
• Пользователи именные или работают посменно с общих устройств?
• Сколько систем и интеграций ходят в SQL Server помимо людей?
• Планируется ли рост числа филиалов в ближайшие 12-18 месяцев?
• Как быстро вы сможете докупить лицензии без остановок закупок и проектов?

Как филиалы и удаленный доступ меняют расчет

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

В Server+CAL вы лицензируете право доступа. Если один сотрудник подключается с ноутбука, телефона и домашнего ПК, это все равно одна User CAL. Но если к базе ходят десятки людей с одного общего компьютера (например, склад в две смены), Device CAL может оказаться выгоднее, потому что лицензируется устройство, а не каждый человек.

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

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

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

Частые ошибки, из-за которых переплачивают

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

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

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

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

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

Быстрая самопроверка перед покупкой

• Кто кроме штата будет подключаться: подрядчики, аудиторы, временные роли?
• Сколько устройств и сколько людей реально используют доступ, есть ли смены?
• Планируются ли апгрейды CPU/ядер в ближайшие 12-18 месяцев?
• Какие системы и приложения ходят в SQL, есть ли сервисные учетные записи?
• Какая архитектура: один сервер, несколько ВМ, кластер, тестовые среды?

Если архитектура не зафиксирована (например, SQL «переедет» в виртуализацию или появится кластер), считать на глаз особенно рискованно.

Короткий чек-лист перед покупкой лицензий

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

Сначала соберите полную картину по серверам SQL: текущие характеристики и план изменений на 12-24 месяца. Если лицензирование будет по Core, планы по CPU и ядрам напрямую меняют итоговую сумму.

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

Отдельно отметьте общие рабочие места (сменные посты в колл-центре, регистратура, склад). В таких местах Server+CAL часто считают по устройствам, и это меняет арифметику.

Коротко зафиксируйте план роста: когда открываются филиалы, сколько людей добавится по кварталам, будет ли сезонность (например, приемная кампания в вузе или пики в рознице). Это помогает заранее понять, в какой момент Server+CAL начнет «догонять» Core по стоимости.

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

Пример: сеть филиалов и рост с 50 до 200 пользователей

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

Вариант 1: Server+CAL (и где легко ошибиться)

Сейчас кажется логичным считать «по устройствам»: 50 сотрудников, но в филиалах 30-35 общих рабочих мест, плюс несколько ПК в офисе. В такой картине Device CAL выглядят дешевле.

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

Еще один риск - «скрытый доступ»: люди заходят в учетную систему, а она обращается к SQL Server от их имени. По правилам лицензирования доступ все равно считается.

Вариант 2: Core (и где риск при апгрейде)

В модели Core вы лицензируете ядра на сервере, и CAL не нужны. Например, если SQL стоит на сервере с 16 физическими ядрами, нужно покрыть лицензиями все 16.

Риск другой: если через год вы решите ускориться и заменить CPU на более многопоточный или добавить второй процессор, число ядер может вырасти до 24-32. Тогда придется докупать лицензии на дополнительные ядра, и экономия по сравнению с Server+CAL может исчезнуть.

Как принять решение без гаданий

Сравните оценку на 2 года, а не «на сегодня». Удобно сделать таблицу допущений и посчитать оба сценария.

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

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

Чтобы решение не «поплыло» через полгода, закрепите его коротким документом на 1-2 страницы: какие допущения вы приняли, на какой срок планируете и кто отвечает за учет. Это спасает от сюрпризов, когда открывается новый филиал или резко растет удаленная работа.

Сделайте два параллельных расчета - Core и Server+CAL - на 12 и 24 месяца. Допущения должны быть одинаковыми: одна и та же версия SQL Server, одинаковые правила доступа, одинаковый прогноз роста пользователей и устройств.

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

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

Если вы планируете обновление железа, лицензии стоит считать вместе с конфигурацией серверов и рабочих мест. На практике именно изменения в инфраструктуре часто сдвигают границу, где выгоднее Core, а где Server+CAL. Если нужна помощь с проектированием такой схемы под рост филиалов, это обычно делают в рамках системной интеграции: например, в GSE.kz (gse.kz) можно параллельно спланировать серверную конфигурацию, точки доступа и поддержку, чтобы выбранная модель лицензирования опиралась на реальную архитектуру, а не на предположения.