Лицензирование 1С и SQL Server на сервере: как не переплатить

В чем обычно проблема при связке 1С и SQL Server

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

Обычно это всплывает при замене CPU, росте числа ядер или переходе в виртуальную среду, потому что часть лицензий привязана к серверу или считается от «мощности». Старый сервер мог быть на 8 ядрах, новый - на 24, и у SQL Server это часто меняет математику. Если вместо одной физической машины появляется несколько виртуальных, добавляются правила по размещению, переносам и правам на запуск.

Дорожает, как правило, не один пункт, а сразу несколько:

• SQL Server - модель «по ядрам» или «Server + CAL», плюс правила виртуализации.
• Windows Server - лицензирование по ядрам и отдельные CAL.
• 1С - серверная лицензия и клиентские лицензии (в зависимости от схемы доступа).
• Удаленный доступ - RDS CAL и другие права, если люди работают через терминал.

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

Еще одна типичная ошибка - не разделять «что нужно технически» и «что разрешено лицензией». Лицензирование в связке 1С и SQL Server - это про права и ограничения, которые меняются вместе с архитектурой. Если сначала обновить железо, а потом разбираться с лицензиями, почти всегда получается самый дорогой вариант.

Из чего состоит лицензирование в связке 1С + SQL Server

Здесь важно сразу разделить, что именно вы покупаете: права на 1С, права на СУБД (SQL Server), права на ОС (обычно Windows Server) и права на удаленный доступ, если пользователи работают через терминал. Ошибка начинается там, где все это считают «одним пакетом».

Разложите роли по факту. Сервер 1С (кластер 1С) может стоять на одной машине, SQL Server - на другой, а удаленная работа пользователей - идти через отдельный терминальный сервер. Иногда все живет на одном хосте, но лицензирование от этого не становится проще - оно просто становится многослойным.

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

В этой связке есть разные модели, и именно из-за этого при апгрейде появляются неожиданные суммы:

• 1С чаще всего упирается в количество пользователей (клиентские лицензии) и выбранный вариант серверной части.
• SQL Server может считаться как «Server + CAL» или «по ядрам» (зависит от редакции и сценария).
• Windows Server имеет собственную схему и отдельные CAL, если пользователи получают доступ к сервисам Windows.
• Терминальный доступ (RDS) обычно требует отдельных RDS CAL.

То, что лицензируется «по пользователям», не становится дешевле от нового железа. А то, что считается «по ядрам», почти всегда чувствительно к апгрейду CPU.

Учитывайте виртуализацию и то, что реально используется

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

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

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

Лицензии 1С: что влияет на стоимость и риски

В связке «1С + SQL Server» часто думают только про SQL, но именно лицензии 1С нередко дают неожиданные расходы. Причина простая: стоимость зависит не от «мощности сервера», а от того, как пользователи подключаются и сколько окружений у вас реально работает.

Ключевой вопрос - какая у вас модель доступа. В клиент-серверном варианте обычно важны два слоя: сервер 1С (где работают службы/кластер) и клиентские лицензии (по пользователям или по устройствам - зависит от вашей схемы). Если добавили терминальный сервер, VDI или просто стало больше рабочих мест, потребность в клиентских лицензиях может вырасти, даже если сотрудников столько же.

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

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

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

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

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

SQL Server: где чаще всего возникает «неожиданное подорожание»

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

1) Ядра или доступы (CAL): что выбрать и что уточнить

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

Перед расчетом уточните четыре вещи: сколько у вас реальных пользователей и устройств, есть ли внешние пользователи (клиенты, подрядчики), будет ли рост в течение года, и какой вариант проще администрировать. Модель с CAL часто кажется дешевле на старте, но становится дороже, когда число пользователей растет или доступ нужен не только из 1С.

2) Апгрейд железа: ядра и сокеты меняют математику

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

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

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

3) Виртуализация: платите за хост, за ВМ или за все сразу

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

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

4) Редакции: чтобы не купить лишнее или неподходящее

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

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

Замена сервера: перенос прав и ограничения, о которых забывают

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

Для SQL Server спорные моменты обычно связаны с лицензированием по ядрам и виртуализацией. Лицензия назначается конкретному серверу, и у многих редакций есть правило reassignment: переносить назначение можно не чаще одного раза в 90 дней (если нет отдельных прав, например по Software Assurance). Если вы рассчитываете «перекинуть» лицензию на время миграции туда-сюда, это может оказаться нарушением.

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

Перед работами снимите «паспорт» текущего окружения. Достаточно базовых данных, но без них легко промахнуться с расчетом:

• модель CPU и количество физических ядер;
• сколько сокетов занято, включен ли Hyper-Threading (важно не путать потоки с ядрами);
• какая платформа виртуализации и есть ли выделенные ресурсы для VM;
• роли: где стоит SQL Server, где сервер 1С, где файловые сервисы и бэкапы;
• текущие редакции и версии (SQL Server, Windows Server, 1С).

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

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

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

Апгрейд сервера для 1С часто начинают с выбора CPU и RAM, а заканчивают ростом бюджета на лицензии. Чтобы сумма не стала сюрпризом, действуйте по простому плану.

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

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

Затем смоделируйте целевую схему после апгрейда: один физический сервер или виртуализация, отдельные ВМ под SQL и под 1С, нужен ли резервный узел, планируется ли рост пользователей.

5 шагов, которые стоит пройти до закупки

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

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

Мини-сценарий

Было: 8 ядер и 60 активных пользователей. Стало: 16 ядер и добавили вторую ВМ для отчетности. Если пересчет сделать после покупки, SQL по ядрам и дополнительные доступы могут резко увеличить бюджет. Если сделать заранее, можно выбрать другую конфигурацию (например, меньше ядер, но выше частота) или иначе распределить роли.

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

Частые ошибки и ловушки при лицензировании и миграции

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

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

Где чаще всего ошибаются

Проблемы обычно складываются из мелких решений:

• Берут сервер «с запасом» по ядрам, не прикидывая, как это отразится на лицензиях SQL Server.
• Смешивают продуктив, тест и разработку на одном сервере, считая, что «раз железо одно, то и лицензии одни».
• Не описывают каналы доступа к 1С: толстый клиент, веб-клиент, терминал, интеграции.
• Начинают перенос без инвентаризации: где ключи, какие договоры, какие регистрационные данные, кто ответственный.

Почему миграция часто «ломает» расчеты

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

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

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

Если сервер закупается у системного интегратора, полезно просить не только спецификацию железа, но и письменные допущения по лицензиям. Например, при поставках серверов и инфраструктуры у производителей уровня GSE.kz это помогает заранее увидеть, где появится рост затрат.

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

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

5 вопросов, которые стоит зафиксировать заранее

• Какая версия и редакция 1С, и как распределены клиентские лицензии: по пользователям, по устройствам, через терминал или смешанно.
• Как используется SQL Server: одна база или несколько, один инстанс или несколько, где он запущен (физически или в ВМ).
• Сколько физических ядер будет в новом сервере и в каких процессорах.
• Нужна ли параллельная работа старого и нового сервера на время переезда.
• Есть ли отдельные контуры тест и разработка, и кто к ним имеет доступ.

Мини-проверка перед счетом

Соберите короткую таблицу: текущий сервер (ядра, где крутится SQL, сколько пользователей 1С) и будущий сервер (ядра, план виртуализации, срок параллельной работы). Потом задайте вопрос: что именно меняется с точки зрения правил, а не производительности.

Реалистичный пример: обновили железо и получили другой счет

Компания на 60 сотрудников использует 1С:Предприятие с SQL Server. Раньше все работало на одном физическом сервере: 8 ядер, 64 ГБ RAM. В 1С было куплено 50 клиентских лицензий, пользователи подключались тонким клиентом, база была одна, без сложной кластеризации.

Через пару лет стало тесно: отчеты тормозят, бэкапы растут, появились требования к отказоустойчивости. Решили обновить железо и перейти в виртуализацию: купить сервер на 32 ядра, поднять на нем две виртуальные машины - отдельно 1С и отдельно SQL Server. На бумаге все выглядело просто: переносим базы, выделяем больше ресурсов и работаем дальше.

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

Бюджет «вылез» не из-за 1С, а из-за неверного допущения про SQL. Ошибка была в том, что никто не пересчитал модель лицензирования до закупки.

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

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

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

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

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

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

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

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

Если нужен новый сервер под 1С и SQL, выбирайте конфигурацию не только по производительности, но и по тому, как она повлияет на лицензии. В таких проектах удобно, когда поставщик и интегратор могут закрыть и железо, и проектирование. Например, GSE.kz как производитель и системный интегратор обычно помогает спланировать инфраструктуру (в том числе на серверах S200 Series) и заранее проверить, что выбранная архитектура не конфликтует с лицензионными ограничениями.

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