Лицензиялау модельдерін салыстыру: per user, per device, per core, per server

Лицензиялау модельдерін неге түсіну керек

Лицензиялау модельдерін салыстыру тек бухгалтерия үшін емес. Бұл сіз нені төлеп жатқанңызды анықтайды: адамға (per user), құрылғыға (per device), серверге (per server) немесе есептеу қуатына — ядра бойынша (per core). Мұнда қателесу көбіне артық төлемге немесе тексеру кезінде дау-дамайға әкеледі.

Бір жүйенің бағасы оны қалай пайдаланатыңызға байланысты әртүрлі болуы мүмкін. Қысқа мысал: кеңседе 30 қызметкер кезектесіп 10 жалпы ПК-те жұмыс істейді. Per user бойынша сіз 30 үшін төлейсіз, per device бойынша — 10 үшін. Ал егер сервер бөлігі виртуалды машиналармен және өсіп келе жатқан жүктемемен байланысты болса, per core көбіне адал шешім болады: баға қуатқа байланысты және сокеттер, виртуализация шектеулері сияқты шектеулерге жасырынбайды.

Жеткізушімен сөйлесер алдында негізгі сандарды жинаңыз. Бұл уақытты үнемдейді және «артықпен» сатып алудан қорғайды — кейін ол өзін ақтамай қалуы мүмкін.

Бастапқы сұрақтар: нақты қанша пайдаланушыңыз бар (оның қанша қашықтан немесе бірнеше құрылғыдан жұмыс істейтінін есептеңіз), қанша құрылғы арқылы қол жеткізу беріледі (сменалы жұмыс орындары бар ма), қанша сервер және олар қайда орналасқан (физикалық па, виртуалды ма, түрлі алаңдарда ма), серверлердегі CPU қандай және қанша ядра нақты пайдаланылатыны. Сондай-ақ 6–12 айға өсу болжамын жасап алыңыз: адамдар, құрылғылар, ядралар.

Компания өскенде және қашықтан жұмыс көбейгенде «көзбен бағалау» өте қауіпті. Бүгін қызметкер бір офис ПК-мен «бір құрылғы» сияқты көрінуі мүмкін, ал ертең оның ноутбугы, үйдегі ПК және терминалдан қосылуы пайда болуы мүмкін. Сонда per device күтпеген өсімге әкелсе, per user есеп жүргізуді жеңілдетеді. Сервер жағында керісінше болуы мүмкін: узелдер қосылып немесе ядрлар саны ұлғайғанда per server схемасы тиімділігін жоғалтады.

Алдын ала қол жеткізу схемасын және жүктемені білгенде лицензиялау жұмбақ емес, қарапайым есепке айналады.

Қысқа анықтамалар: per user, per device, per core, per server

Бір принцип есте болсын: сіз неге төлейсіз — "кім қолданады" ма, әлде "қайдан қолданады" ма, әлде "қанша қуат" па, әлде "қанша сервер" ме. Тек есеп бірлігі өзгереді.

Per user (пайдаланушыға)

Лицензия адамға (қызметкерге, есептік жазбаға) байланады. Әдетте бір адам бірнеше құрылғыдан жұмыс істегенде ыңғайлы: офис ПК, ноутбук, телефон, үйдегі компьютер. Маңыздысы — пайдаланушы қалай есептелетіні: атымен (named user) бе, әлде бір уақытта қосылған сессиялармен (concurrent user) бе.

Per device (құрылғыға)

Лицензия нақты құрылғыға байланады: жұмыс орны, терминал, касса, палатадағы планшет, тонкий клиент. Егер құрылғы ортақ және оны бірнеше адам кезектесіп қолданса, per device есептеу жеңілірек болады.

Per core (ядраға)

Есептеу қуатына — процессор ядраларының санына — байланысты лицензиялану. Кейде процессорға немесе серверге минималды талаптар қойылады. Бұл сервер өнімдері мен виртуализация үшін жиі қолданылады: пайдаланушылар санына қарамастан баға жабдыққа тәуелді.

Per server (серверге)

Лицензия бір серверге (физикалық немесе виртуалдық) сатып алынады. Бұл кіші контурлар үшін, серверлер аз және конфигурация тұрақты болса, жеңілірек.

"Пайдаланушылар пулі" және "құрылғылар пулі" деген терминдер — лицензияланатын бірліктің тізімі: кімге рұқсат бар (қызметкерлер/аккаунттар тізімі) және қай құрылғылардан кіре алады (ПК/терминалдар тізімі). Әдетте маңыздысы — бүгін кім кірді емес, пулге кім қосылғаны. Пул өзгерісі (жаңа адамдар, жаңа жұмыс орындары) көбіне қосымша шығын туғызады.

Мини-мысал: 30 қызметкер 10 кассада сменамен жұмыс істесе, per user бойынша 30 лицензия, per device бойынша — 10. Per core кезінде кассалар саны шығынға әсер етпейді, бірақ сервер конфигурациясына тәуелді болады.

Қашан per user таңдаған дұрыс: типтік жағдайлар және мысалдар

Per user әдетте «мән» адамда жатқанда тиімді: бір адам бірнеше құрылғыдан жүйеге кіреді және пайдаланушыларды дұрыс есептеу мүмкін болғанда.

Көп жағдайда per user тиімді, егер:

• қызметкерде 2–3 құрылғы болса (офис ПК, ноутбук, телефон);
• қашықтан жұмыс немесе гибридті кесте бар;
• пайдаланушылар аты-жөні бойынша бекітілген және есеп жүргізу бар (AD/SSO, корпоративтік пошта);
• "басқа құрылғыдан кіріп жұмысын жалғастыру" сияқты сценарийлерді шектеу қажет емес.

Мысал: жобаның менеджері офис ПК-де жұмыс істейді, кешкісін үйдегі ноутбукпен тапсырмаларды тексереді, күн ішінде телефоннан құжаттарды бекітеді. Per device моделінде бірнеше құрылғы есепке алынатын еді, ал per user бір адамды жабады.

Сменалы командаларда жағдай басқа. Бір ПК-де бірнеше адам кезектесіп жұмыс істесе (тіркеу, операторлық, сыныптар), per user қымбатқа түседі — сонда per device ұтымдырақ.

Мердігерлер мен уақытша қызметкерлер — жеке тәуекел. Олардың пайдаланушы ретінде есептелетінін алдын ала шешіңіз. Егер сыртқы мамандар өз есептік жазбаларымен жүйеге кірсе, формальды түрде оларға per user лицензия қажет болуы мүмкін. Практикалық ереже: логині бар және жүйеге қол жеткізу мүмкіндігі бар кез келген адам пайдаланушы саналады.

Айта кететін нәрсе — "сирек пайдаланушылар": бухгалтер айына бір рет кірсе, басшы кварталда есепті ашса. Мұндай рольдер тексеруде жиі байқалады. Оларды алдын ала есепке алу немесе техникалық түрде қолжетімділікті жауып қою ұтымды.

Қашан per device таңдау керек: жұмыс орындары мен сменалы командалар

Per device моделі бір құрылғыны бірнеше адам қолданатын жерде тиімді. Сіз кіру нүктесіне төлейсіз, әр адам үшін емес. Бұл сменалы жұмыс пен жалпы жұмыс орындарына сәйкес келеді.

Типтік мысалдар: рецепция, оқу сыныбы, зертхана, 2–3 сменалы операторлық, отыру орындары бар колл-центр. Егер адамдардан көп құрылғылар бар және олар кестеге сай ауысып жатса, per device жиі түсінікті.

Арнайы жағдай — терминалдар мен киоскылар. Егер құрылғы көп адамды немесе қызметкерлерді күнде қабылдайтын болса, "орынға" лицензия байлау бақылауды және бюджетті жеңілдетеді. Мысалы, поликлиникадағы инфокиоск немесе тіркеу жұмыс орны жүздеген адамды қызмет көрсете алады — онда пайдаланушыларға байланысты лицензиялау мәнсіз болуы мүмкін.

Алдын ала не құрылғы саналатынын келіскен дұрыс. Әдетте есепке офис ПК, моноблоктар, тонкий клиенттер, терминалдық станциялар, планшеттер (қолжетімді болса), кассалық станциялар және POS-терминалдар кіреді.

Резервтік ПК және жөндеу сценарийін ойластырыңыз. Филиалда 1–2 алмастырғыш құрылғы болса, олар жиі есепте ұмытылады. Лицензияны ауыстыру ережелерін алдын ала бекітіңіз: бүлініп қалғанда лицензия қалай беріледі және қанша рет рұқсат етіледі — әйтпесе "бір рольге екі лицензия" жағдайы пайда болуы мүмкін.

Per device-тың басты тәуекелі — құрылғылар санының байқалмай өсуі. Қызмет көрсету терезесін ашсаңыз, қосымша касса қойып, жаңа филиалда бірнеше ПК орнатсаңыз — шығындар құрылғылар санына сәйкес өседі. Бұл модельді таңдасаңыз, 6–12 айға өсу жоспарын бекітіңіз және жаңа құрылғылардың лицензия талаптарына назар аудару үшін жауапты тағайындаңыз.

Қашан per core таңдау керек: серверлер мен виртуализацияда тосын сый болмайтын жағдайлар

Per core серверлік өнімдерде жиі қолданылады, баға есептеу қуатына байланысты. Егер жүктеме пайдаланушылар санынан гөрі CPU жұмысына тәуелді болса — сұраулар, есептеулер, параллель тапсырмалар — онда есептілік нақты қанша физикалық ядра қолданылатынына келіп саяды.

Есептің "жылжымай қалмауы" үшін алдымен жабдық жөніндегі деректерді жинаңыз. Сокеттер, ядралар мен ағындар арасындағы шатасу бюджетті артығынан көбейтеді.

Тексеріңіз:

• процессор моделі (SKU);
• сервердегі сокеттер саны;
• әр сокеттегі физикалық ядра саны;
• гиперпоточылық қосылған ба (оны ядрамен шатастырмаңыз);
• алдағы 12–24 айда CPU-ны жаңарту жоспары.

Виртуализацияда нюанстар бар. Лицензия хосттың ядрасына, кластердегі ядраға немесе нақты VM-ге бөлінген ядраға байланысты есептелуі мүмкін — әр вендордың ережесі әртүрлі. Көбінесе қате — ағымдағы VM-ге сәйкес минималды лицензия алу, ал кейін VM басқа хостқа көшкенде қосымша ядра қажет болғанын білу.

Per core тұрақты жоғары жүктеме бар жүйелерде тиімді: дерекқорлар, транзакциялық жүйелер, аналитика, қалың виртуализация (көп VM бір хостта). Мұнда пайдаланушылар саны өзгерсе де, баға ресурстарға байланысты анық болады.

Практикалық мысал: 2-сокеттік сервер дерекқорға орнатылды және өсу жоспарланған. Бүгін 16 ядра жеткілікті болса, бір жылдан кейін 32 қажет болуы мүмкін. Per core кезінде CPU жаңартуы лицензиялық талаптарды көбейтеді — сондықтан өсуге бюджетті алдын ала қосыңыз. Егер жобаға арналған стояк сияқты типтік rack-серверлер (S200 түрі) сатып алынса, конфигурация мен VM миграция ережелерін сатып алудан бұрын бекітіңіз — масштабтау кезінде тосын сый азаяды.

Қашан per server таңдау керек: шағын серверлік контурлар

Per server қарапайым және болжамды сценарийлерге сай: әр рөл үшін 1–2 сервер (файл, принт, шағын дерекқор, домен контроллері), өзгерістер аз және миграциялар сирек. Бұл кезде шешетін сұрақ — алдағы бір жылда контурда қанша сервер болатыны.

Дәрігер: "сервер" дегеннің физикалық машина ма, виртуалдық машина ма, әлде хост па — әр вендор әртүрлі анықтайды, бір сөйлем келісімде тиімді схеманы қымбатқа айналдыра алады.

Қай кезде per server per core-дан тиімді

Per server шағын CPU (мысалы, 1 сокет және аз ядра) болғанда және серверлер саны аз деп сенімді болғанда тиімді. Мысалы, бөлімде бір қосымша сервер және бір дерекқор сервері бар және олар тұрақты. "Серверге" арналған лицензия жиі аппаратты жад немесе диск арқылы жаңартып, қосымша лицензия алмай жүктемені көтеруге мүмкіндік береді — егер шын мәнінде ережелер ядраға байланысты болмаса.

Резерв, тест және өсу

Резерв және тест орталары туралы сұраңыз. Кейде cold standby (сөндірілген резерв) қосымша лицензия талап етпейді, кейде резерв толық сервер ретінде есептеледі. Бастапқыда міндетті түрде бекітіңіз:

• өндіріс, тест және резервте қанша сервер болады;
• "сервер" не деп есептеледі: физика, VM немесе хост;
• миграция немесе ауыстыру кезінде лицензияны ауыстыруға бола ма;
• кластерлер мен авариялық қалпына келтіру қалай лицензияланады;
• қосымша рөлдер қосылғанда не болады (тағы бір сервер).

Per server-дің басты тәуекелі — қосымша VM-лер, кезектер, кэш және мониторинг үшін жаңа тораптар қосылған сайын серверлер саны байқалмай өсуі. Егер тез өсу күтілсе, per core немесе басқа схема ұзақ мерзімде тыныш болады. Ал 1–2 серверлік шағын контур үшін per server көбіне бюджетті айқын етіп, тосын сыйларды азайтады.

5 қадамда модельді қалай таңдау керек

Даудың алдын алу және «осы жолы арзан» сияқты пікірталастар болмас үшін бірдей бастапқы деректерді бекітіп, бес қадамды орындаңыз.

1. Сценарийлерді сипаттаңыз. Жүйені кім қолданады: офис қызметкерлері, жолға шығатын инженерлер, сменалы операторлар, сыртқы мердігерлер. Қайдан кіреді (кеңседен, үйден, терминалдардан) және бір адам бірнеше құрылғыдан жұмыс істей ала ма.

2. Рөлдер бойынша пайдаланушылар мен құрылғыларды есептеңіз. Бірегей пайдаланушылар мен нақты қолжетімділік нүктелерін бөлек санаңыз. Бір адам ноутбук, смартфон және үйдегі ПК қолданса, per user әдетте түсінікті. Керісінше, көп адам бір ПК-ді кезектесіп қолданса — per device жиі ұтымды.

3. Сервер бөлігін сипаттаңыз. Қанша сервер, қандай процессорлар және қанша ядра, виртуализация бар ма, қанша VM жоспарланған. Мұнда қате оңай шығады: өсу кезінде per core жиі болжамдырақ, ал "серверлер бойынша санау" кейде қате тұжырымға әкеледі, әсіресе серверлер қуатты немесе жабдықты жиі ауыстырса.

4. 12–36 айға өсу бағасын жасаңыз. Штат, филиалдар, жаңа сервистер мен қашықтан жұмыс жоспарын қосыңыз. Жақсы модель өсу кезінде бір өзгерістен (мысалы, сменаның қосылуы немесе жаңа VM) шығындар күрт артпайтын болуы керек.

5. Бірдей деректер бойынша 2–3 моделді салыстырыңыз. Қазіргі және 1, 3 жылға болжамды есептеп, өсім кезінде ең тегіс нәтижені беретін нұсқаны таңдаңыз, бүгінгі ең арзан нұсқаны емес.

Мини-сценарий: колл-центре 60 оператор 3 сменада және 25 жұмыс орны болса — көбіне per device логикасы келеді. Ал 40 қызметкері бар сату командасында әрқайсысы ноутбук пен телефон қолданса — per user ыңғайлырақ.

Жиі қателіктер және қай жерде көбіне артық төлейді

Лицензиялаудағы қателер көбінесе бірдей көрінеді: лицензияны «көзбен бағалап» сатып алады, ал ережелер басқа есептейді. Соңында артық төлем немесе тексеруде тәуекел пайда болады.

Ең кең тараған тарих — тек ағымдағы штатты санау. Жобаға маусымдық қызметкерлер, мердігерлер, тағылымдамашылар қосылады. Per user болса, олар да есепке іленуі мүмкін, тіпті қысқа мерзім үшін.

Екінші қазан — "пайдаланушы" мен "есептік жазба"-ны шатастыру. Кей жүйелер адамды лицензиялайды, басқалар — белсенді аккаунтты, тағы басқалар — бір уақытта қосылған сессияны. Мысалы, HR тестілеу және интеграциялар үшін бөлек аккаунттар сұраса, олар күтпеген түрде лицензияны «жеп» бастайды.

Сменалық жұмыс та есепті жиі өзгертеді. Зауытта 3 смена бір ПК-де жұмыс істесе, per device тиімдірек көрінеді. Кеңседе бір адам стационарлық ПК мен ноутбук қолданса, per device per user-дан қымбатырақ болуы мүмкін.

Серверлерде артық төлем көбіне ядраның өсуі мен виртуализациядан келеді. «Ағымдағы серверге» сай лицензия алып, кейін CPU жаңартқанда, сокеттер қосқанда немесе жаңа VM-лер орнатқанда per core ережелері күтпеген талаптар қояды. Сол сияқты физикалық инфрақұрылым мен виртуализация ережелерін араластыру да шатасуға әкеледі.

Сатып алудан бұрын қағазға нақты не лицензияланатынын бекітіңіз:

• пайдаланушы кім болып есептеледі (адам, аккаунт, бір уақытта қосылған сессия);
• құрылғы не болып саналады (ПК, тонкий клиент, терминал);
• ядра/процессор қалай есептеледі (минимумдар, дөңгелектеу, гиперпоточылық);
• виртуализация қалай есептеледі (хост, кластер, миграциялар);
• өсу кезінде не болады (апгрейд, сервер қосу, уақытша қолжетімділіктер).

Қарапайым мысал: клиника кешкі сменаны қосып, мердігерге есептерге қол жеткізу бергенде, егер бұл per user болып есептелсе және келісімде анықтығы жоқ болса, артық аккаунттар шотты кескіндейді. Инфрақұрылымды жеткізетін және қолдайтын интегратор болса, бұл ережелерді спецификацияда алдын ала келісіп, өсу кезінде артық төлемнен құтылуға болады.

Салалар бойынша типтік жүктеме мысалдары

Төменде төрт жиі кездесетін сценарий бар. Бұл «қалай болса да арзан ету» туралы емес, қай көрсеткіш негізгі болып табылатынын — адамдарды, құрылғыларды немесе есептеу қуатын — анықтау туралы.

Поликлиника (тіркеу, жалпы ПК, сменалар). Негізгі көрсеткіш — жұмыс орындары (құрылғылар), өйткені бір компьютерді көп адам кестеге сай қолданады. Көбіне per device жарайды: құқық нақты ПК-ге байланады және сменалық жұмыс қосымша төлемге айналмайды.

Банк (кейбір қызметкерлер ноутбукпен, қашықтан қосылу бар). Негізгі көрсеткіш — пайдаланушылар, себебі бір адам ноутбук, үйдегі ПК және телефон арқылы қосылуы мүмкін. Мұндайда per user жиі тиімді, әсіресе қолжетімділік жеке адамға керек болса.

Университет (компьютерлік сыныптар және оқытушылар). Әдетте екі ағымды бөледі. Сыныптар үшін негізгі көрсеткіш — компьютерлер саны (per device). Оқытушылар мен қызметкерлер үшін, жеке ноутбукпен және үйден жұмыс істейтіндер үшін — адамдар саны (per user). Көбіне аралас схема шығады, бірақ логика айқын болады.

Кәсіпорын (виртуалды машиналары бар сервер және өсу). Мұнда негізгі көрсеткіш — ядра/қуат, себебі VM саны мен пайдаланушылар өзгеруі мүмкін, ал сервер ресурстары өседі. Per core көбіне аз тосын сый береді: VM қосылғанда немесе жүктеме ұлғайғанда талаптар айқын.

Егер күмәніңіз болса, бір сұрақтан бастаңыз: сізде не жиі өзгереді — адамдар, құрылғылар немесе сервер ресурстары? Осы жауап модельді таңдауға жиі көмектеседі.

Сатып алудан бұрын жылдам чек-лист

Сатып алуға кіріспес бұрын бір бетке цифрларды жинаңыз. Бұл қате модель таңдау және кейінгі қосымша төлем тәуекелін азайтады.

Бастапқыда нақты пайдалану көрсеткішін жазып алыңыз: ай ішінде қанша бірегей пайдаланушы жүйеге шынымен кіреді, "теорияда қанша адам кіре алады" емес. Компанияларда маусымдық қызметкерлер, мердігерлер және сирек кіретін рольдер болады — олар үшін шарттар бөлек болуы мүмкін.

Кейін кіру нүктелерін есептеңіз: жүйеге қанша құрылғы қол жеткізеді, соның ішінде жалпы ПК, терминалдар, жолға арналған ноутбуктар, резервтік жұмыс орындары және тесттік машиналар. Егер сменалы командалар болса, бұл per user мен per device таңдауын түбірімен өзгертеді.

Жекелеп серверлік контурды келесі жылға дейін сипаттаңыз — «қазір қандай» емес, жоспарланғаны бойынша: қанша сервер қосылады, қандай CPU орнатылған (сокеттер мен ядра), жаңа рөлдер пайда бола ма (ДБ, қосымшалар, виртуализация). Per core пен per server үшін осы мәліметтер бағаға қатты әсер етеді.

Виртуализация мен миграцияларды тексеріңіз. Егер VM-лер хосттар арасында көшсе, лицензиялау нақты хост бойынша ма, пул бойынша ма, әлде әрбір ядра бойынша ма — осыны білу маңызды. Әйтпесе тосын сыйлар іске қосқаннан кейін шығады.

Өсу қарқынын бағалаңыз: филиалдар қаншалықты тез ашылады, жұмыс орындары қаншалықты өседі және ішкі сервистер қалай көбейеді. Қарапайым ереже: егер өсу тез және теңсіз болса, лицензиялау модельін өшірмей масштабтауға болатын, яғни шығынды күрт арттырмайтын модель таңдаңыз.

Және жауапты белгілеңіз: кім лицензия реестрін ұстайды, құжаттарды сақтайды, инфрақұрылымдағы өзгерістерді бақылайды және ішкі тексеруге материал дайындайды. Бұл жауап болмаса, тіпті дұрыс таңдалған модель уақыт өте шығынға айналуы мүмкін.

Қысқа практикалық тексеру: егер сіз сенімді түрде айта алмасаңыз "пайдаланушылар, құрылғылар, серверлер/ядралар, виртуализация, өсу, жауапты" — сатып алуға асықпаңыз, алдымен осы алты сұраққа жауап жинаңыз.