Серверлік лицензиялар және жабдықты жаңарту: қалай артық төлемеске болады

Неліктен серверді жаңарту лицензияны күрт қымбаттатуы мүмкін

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

Ең жиі себебі — лицензиялау ережелерінің автоматты қайта есептелуі. Сіз процессорды жаңа модельге ауыстырған кезде ядролар саны өседі, екінші сокет пайда болуы мүмкін немесе виртуализация шарттары өзгереді. IT үшін «жабдық жақсарды», ал лицензия үшін — «метрика көбейді».

Әдетте қайта есептеуді келесі өзгерістер іске қосады: физикалық ядролардың көбеюі, сол сокетте көп ядролы CPU-ға өту, екінші процессорды қосу, кластерді кеңейту және виртуализация шарттарындағы өзгерістер (әсіресе ВМ кез келген хостқа миграциялана алса).

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

Апгрейд бюджетке соққанын болдырмау үшін жауапкершілікті алдын ала бөліңіз. Әдетте мына байланыс жұмыс істейді: IT мақсатты архитектураны (түйіндер, ВМ, миграциялар, резерв) сипаттайды, сатып алу лицензияланатын метрикаларды бекітеді және шарттарды тексереді, қаржы өсім сценарийлерін (минимум, жоспар, қор) қарастырады, ал интегратор нақты конфигурация мен эксплуатация схемасына сай есептерді дәлелдейді.

Тәжірибеден мысал: ұйым бір серверді тығыздығы жоғары CPU-ға жаңартты, кабинета үнемдеу үшін. Қосымшалардың жұмыс өнімділігі айтарлықтай өзгермеді, бірақ ядролар саны өсті, сондай-ақ сенімділік үшін екінші түйін қосылды — және ядролар немесе хосттар бойынша лицензиялау жабдықтың өзінен әлдеқайда қымбатқа түсе бастады.

Ең жиі кездесетін лицензиялау модельдері

Бюджет жоспарламас бұрын нақты қандай модель бойынша баға есептелетінін анықтау пайдалы. Мұнда қате «аздап жылдамдау» пен лицензия шотының «жаңа жоба сияқты өсуіне» әкелуі мүмкін.

Көбінесе кездесетін бес схема бар: физикалық серверге бекітілген фиксирленген лицензия; CPU (сокет) бойынша лицензия; физикалық ядролар бойынша лицензиялау; виртуалдық машиналарға лицензия (ВМ саны, vCPU немесе функциялар бойынша); виртуализация хосттарына лицензия (түйін немесе оның ресурстары, ВМ іске қосуға құқықпен).

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

Тоқтамалы тақырып — жазылым (подписка) немесе өмірлік лицензия. Жазылым бастапқы бюджет үшін тиімді болуы мүмкін, бірақ кластер ұлғайған сайын өсімді дереу және жыл сайын төлеуге тура келеді. Өмірлік лицензия ұзақ мерзімде артықшылық беруі мүмкін, бірақ қолдау болмаса жаңа нұсқаларға құқықтар шектеулі болуы ықтимал.

Қолдау және продление — жиі «жасырын» шығын. Сметада біржолғы төлем мен жыл сайынғы шығындарды бөлек көрсету артық болмайды: техподдержка мен жаңартулар, жазылымды жаңарту, құқықтарды кеңейту (инстанстар, функциялар), сондай-ақ метрикаларға сәйкес аудит пен верификация төлемдері (ядролар, түйіндер, ВМ).

Мысал: компания сенімділік үшін екінші сервер қосады. Жабдық «сығымды» етіп алынады, кейін анықталады: лицензия ВМ-дердің қай хостқа өту мүмкіндігіне қарай барлық хосттарға есептеледі. Резервтік түйін негізгіге теңдей лицензия талап етеді.

CPU және сокеттер: қай өзгерістер бағаны ең қатты өсіреді

Лицензияларда жиі «атқылайтын» көрсеткіш — процессордың жиілігі мен кэші емес, сокеттер мен процессор пакеттер деңгейіндегі конфигурация өзгерісі.

Ең типтік триггер — бір серверде 1 CPU-дан 2 CPU-ға өту. Екінші процессор «болашаққа» арналған болса да, көптеген өнімдер лицензияны сокеттер бойынша немесе барлық орнатылған CPU-лардың суммарлық ядролары бойынша есептейді. Төлеу қазір-ақ қажет болуы мүмкін.

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

CPU-ның жаңа ұрпағына өту де бюджетке соққы беруі мүмкін: вендор ережелерді өзгерте алады — коэффициенттер, ядро минимумдары, редакциялар мен виртуализацияға құқықтар өзгереді. Қағазда бұл «жабдық жаңарды», ал іс жүзінде сіз жаңа шарттарға түсіп қалдыңыз.

Кластерде тағы бір проблема — аралас конфигурациялар. Түйіндер CPU-лары жағынан (ұрпақ, ядролар саны, сокеттер) әр түрлі болса, лицензия жиі ең қуатты түйінге қарай теңестірілуі керек болады, солайша ВМ миграциясын жүзеге асыру құқығын сақтау және аудит кезінде даулардан аулақ болу үшін.

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

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

Ядролар және өнімділік: қайда қосымша шығындар жасырынады

Ең жиі кездесетін тосынсый — физикалық ядролар. Өнім ядролар бойынша лицензияланса, ядролар санының өсуі көбіне бағаның өсуіне әкеледі. Типтік сценарий: 16-дан 32 ядроға өту «қор үшін» жасалады, ал лицензиялар екі есеге өседі. Ал қосымшаның жылдамдығы жады, диск немесе желі шектеулеріне байланысты әлдеқайда азырақ өседі.

Тағы бір тұзақ — минимумдар мен округтаулар. Көп вендорларда «сокетке не серверге минимум N ядро» сияқты ережелер бар, ал лицензия пакеттермен сатылады (2 немесе 4 ядроға көбейткіші). Соның нәтижесінде 1–2 ядро қосқанда толық пакет сатып алу қажет болады. Екісокетті жүйелерде бұл әсіресе сезіледі, себебі минимум әр CPU-ға қолданылады.

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

Гиперпоточность (Hyper-Threading/SMT) есептеулерді жиі шатастырады. Көп жағдайда лицензия физикалық ядролар бойынша есептеледі, логикалық ағындар есепке алынбайды. Бірақ бұл нақты ПО шарттарына сәйкес тексеруді талап етеді.

«Артық» ядролар сатып алмау үшін апгрейдты 12–24 айға жоспарлап, нақты не өсетінін (пайдаланушылар, дерекқорлар, ВМ саны, кластер түйіндері) алдын ала шешіңіз — сонда қор мағынасыз болмайды.

Кішігірім мысал: стойкадағы GSE S200 деңгейіндегі серверлерге кластер кеңейтіледі. Қосымша түйін қосудың орнына әр серверге көп ядролы CPU ауыстыруды таңдайды. Жабдық бойынша апгрейд тиімді көрінсе де, ядролар бойынша лицензия бүкіл түйіндерге қайта есептеліп, нәтижесінде бір түйін қосуға қарағанда қымбатқа түсіп кетуі мүмкін.

Сатып алу алдында төрт нәрсені тексеріңіз: лицензия метрикасы (физикалық ядролар, сокеттер, VM, хост), минимумдар мен округтаулар, ВМ ауысуы және түйіндер қосылғанда есептеу тәртібі, және 12–24 ай мерзімінде нақты қанша өсім қажет болатынын анықтау (артық қор қоспау).

Виртуализация және кластер: түйіндер қосқанда және миграция кезінде не өзгереді

Виртуализацияда лицензиялар көбінесе жаңа ВМ-дерден емес, ВМ-дердің қай жерде іске қосыла алатынынан өседі. Сіз сенімділік үшін түйін қосқаннан кейін лицензиялау бүкіл кластерге немесе ВМ-дердің миграциясы мүмкін барлық хосттарға созылуы мүмкін.

Түйін қосылды — хосттар бойынша лицензия өсті

Көп модельдерде ереже қарапайым: егер ВМ хостқа көшсе, сол хостта лицензия болуы керек. Сондықтан жаңа түйін кластерді ғана емес, лицензия жинағын да қымбаттатып жіберуі мүмкін, егер лицензия ядроларға, сокеттерге немесе хосттарға есептелсе.

Автоматты миграциялар (мысалы, балансировка) қосылған сценарийлерді бөлек тексеріңіз — олар лицензияланатын серверлер тізімін кеңейтеді.

Ресурс пулдары, миграция және лицензия «шекаралары"

ВМ нақты хостқа байланған кезде есептеу оңай. Бірақ ортақ ресурс пулын жасап, переносқа рұқсат берсеңіз, шекаралар бұлыңғырланады. Миграция «сирек» жоспарланған болса да, техникалық мүмкіндігі лицензияны алдын ала талап етуі мүмкін.

Оған ұқсас жағдай — виртуализация тығыздығын арттыру. Егер өнім ВМ саны немесе белсенді инстанстар бойынша лицензияланса, қуатты жабдық шектеуді тез жейді: ВМ саны өседі, және шот та өседі.

Жобалау алдында анықтаңыз: өнім нақты қай жерде лицензиялауды талап етеді (әр хостта, кластерде, ВМ саны бойынша немесе ядролар бойынша), лицензия мобильдігі рұқсат етілген бе (хосттар арасында перенос), уақытша бекіту мерзімдері бар ма, резервтік түйіндер лицензиялануы керек пе (N+1), миграция кезінде потенциалдық ВМ іске қосылу қалай есептеледі және аралас хосттар кезінде есептеу қандай болады.

Тағы бір өсу көзі — платформаны қоса лицензияланатын функциялар: басқару, бэкап, мониторинг, репликация, оркестрация. Олар көбіне кластермен бірге масштабталады.

Мысал: ұйым виртуалды кластерін кеңейтіп, ыңғайлылық үшін тағы бір GSE S200 серверін қосады. Жабдық жоспар бойынша сатып алынады, бірақ гипервизор мен басқару лицензиялары бүкіл кластерге қайта есептеледі, ал бэкап ВМ саны бойынша есептеледі — олардың саны виртуализацияның тығыздығы артуымен көбейді. Нәтижесінде бюджет сервердің бағасынан қатты өзгереді.

HA және DR: резервтеу неге шотты жиі ұлғайтады

HA (жоғары қолжетімділік) және DR (апаттық қалпына келтіру) көбіне жай ғана екінші комплект жабдықты ғана емес, лицензияға да көңіл талап етеді. Серверлер «қай жерге сақтаулы болса да» көптеген вендорлар үшін бұл қолданылу ретінде есептеледі.

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

Резервтеу схемалары тез арада қосынды әсерін тудырады. 1+1 сценарийінде көбіне екі набор құқықтары үшін төлеуге тура келеді, ал N+1 схемасы — резерв түйіні өндірістік сипаттағымен тең болғанда шот ойнап шығады. Гео-резервте екінші алаңда үйлесімді қуаттар қажет, және ядролар немесе сокеттер өсімі лицензия құнын автоматты түрде көтереді.

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

DR алаңына арналған бюджетте алдын ала енгізіңіз: екінші алаңның есептеу ресурстарына арналған лицензиялар немесе көшіру құқықтары, HA/кластерлік функциялар үшін доплаталар, басқару (менеджерлер, агенттер, бэкап), лицензияларды көшіретін терезелер мен шектеулер, нұсқалардың үйлесімділігі мен қолдауға төлем, және вендормен лицензиялау моделін келісу уақыты.

Артық төлем болдырмас үшін жұмыс режимдерін құжаттаңыз: қандай түйіндер активті, ауыстырып қосулар жиілігі, тесттер қай жерде жүргізіледі және RTO/RPO талаптары. Бұл параметрлер резервтің «суық», «жылы» немесе «ыстық» екендігін анықтайды және қажет лицензия түрін көрсетеді.

Апгрейдтің лицензияға әсерін бағалау: кезеңдік әдіс

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

Бастапқы инвентаризациядан бастаңыз: өнімдер тізімі және нақты қосылған функциялар. Көп вендорларда қосымша опциялар — отказоустойчивость, репликация, бэкап, шифрлау, қосымша коннекторлар немесе менеджмент — бөлек лицензияланады.

Келесі қадам — ағымдағы лицензия метрикасын тіркеу. Бірдей ПО әртүрлі жағдайларда ядролар, сокеттер, хосттар, ВМ саны, пайдаланушылар немесе комбинация бойынша есептелуі мүмкін. Нақты қандай «өлшем бірлігі» екенін және қандай минимумдар бар екенін жазып алу маңызды.

Практикалық жұмыс тәртібі:

• Қолданылып жүрген ПО-лар мен жеке лицензияланатын модульдер тізімін жинаңыз.
• Ағымдағы метрика мен ережелерді жазыңыз: ядролар, CPU, хосттар, ВМ, пайдаланушылар, минималды пакеттер.
• Апгрейд жоспарын сипаттаңыз: жаңа CPU, ядролар санының өсуі, түйіндер қосу, кластер өзгерістері, ВМ миграциялары.
• 2–3 архитектуралық вариантты есептеңіз: «жоғарылау» (хостта ресурстарды көбейту) және «кеңейту» (көп хост қосу) және лицензия бойынша салыстырыңыз.
• Өзгерістерді бақылауды тағайындаңыз: кім апгрейдті бекітеді және кім лицензияларды қайта есептеуге міндетті.

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

Лицензиялардың қымбаттауына әкелетін жиі қателіктер

Ең ауыр жағдай: жабдық сатып алынды, жұмыстар жоспарланды, ал бағдарламалық қамтамасыз ету сатып алу кезеңінде лицензиялар 1,5–2 есе көп екенін көрсетеді. Бұл көбіне «адал емес бағалар» емес, болжамдағы қате.

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

Екінші тұзақ — кластер және виртуализация. Қосымша түйінді «қор үшін» қостың немесе миграцияларды жеңілдеттің, бірақ ережелер лицензияны барлық ықтимал хосттарға таратады.

Үшінші қате — прод пен тест ортаны бір кластерде біріктіру. Тест ВМ-дерін ұмытып кету оңай, бірақ кей вендорлар үшін бұл лицензия талабының өзгеруіне әкеледі.

Тағы бір шығын көзі — қосалқы компоненттерді толық есепке алмау. Көптеген ұйымдар тек негізгі лицензияны есептеп, басқару, бэкап, мониторинг, агенттер, коннекторлар және қосымша модульдерді ұмытады.

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

Қысқа тізім — жиі ұмытылатындар:

• Ядролардың өсуі және CPU/сокеттердің өзгеруі метриканы қайта есептемей.
• Кластер түйіндерінің өсуі және ВМ миграция аймағының кеңеюі.
• Прод, тест және dev орталарды бірдей хосттарда біріктіру.
• «Көрінбейтін» лицензиялар: басқару, бэкап, мониторинг, плагиндер.
• Процеске иесі тағайындамау: өзгерістерді тіркейтін және лицензияларды сатып алудан бұрын қайта есептейтін адам.

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

CPU, ядро немесе кластер апгрейд алдында жылдам чек-лист

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

1) Лицензия қалай есептелетінін нақтылаңыз

Сіздің шарттарыңызға сай метрика мен егжей-тегжейін тіркеңіз:

• Метрика: ядролар, сокеттер/CPU, хост, ВМ, пайдаланушылар.
• Минимумдар: мысалы, сокетке не серверге минимум ядролар.
• Округтау: лицензиялар пакеттермен сатылады (2 немесе 4 ядроға көбейткіші).
• "Сервер" деп не саналады: бір түйін, бүкіл кластер немесе ВМ-нің миграциясы мүмкін кез келген хост.
• Басқару, резервтік көшіру, мониторинг үшін бөлек лицензиялар қажет пе.

2) Апгрейд кезінде нақты не өзгереді — жазып алыңыз

"CPU-ны қуаттырақ қоямыз" деген жалпылама формула жеткіліксіз. Ескі мен жаңа конфигурацияны нақты сандармен салыстырыңыз: сокеттер, физикалық ядролар (әр CPU мен жалпы), кластердегі түйіндер саны, миграцияға қатысатын хосттар және ВМ санының өзгерісі.

Жақсы тәжірибе — бір кесте «до/кейін» және сол жағында вендор формуласы бойынша лицензия есебі.

3) Миграциялар мен екінші алаңды тексеріңіз

Ең жағымсыз тосынсыйлар — ВМ-дер қайда көшетінінен пайда болады. Егер live migration, балансировка, failover немесе DR алаңы бар болса, лицензия потенциалды хосттарды талап етуі мүмкін. ВМ сирек баратынын айтсаңыз да, техникалық мүмкіндік көбіне лицензияны талап етеді.

4) Орталарыңызды бөлек ұстаңыз: прод, тест, резерв

Орталары қалай бөлінетінін бекітіңіз. Егер тест немесе резерв прод-пен бірдей хосттарда тұрса, көптеген вендорлар оны бір лицензия аймағы деп санайды. Егер орталар физикалық түрде бөлек (әрқайсысында жеке хосттар немесе бөлек кластер болса), есептеу әдетте қарапайым әрі болжамды болады.

5) "Хвост" шығындарын ұмытпаңыз

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

6) Кім есептейді және кім бекітеді

Жауапты адамдар мен әрекет тәртібін тағайындаңыз. Қарапайым процесс: Инициатор апгрейдтің «до/кейінін» береді (CPU, ядра, түйіндер, миграциялар, алаңдар), лицензиялау маманы есептейді және болжамдарды жазады, бюджет иесі бекітеді.

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

Практикалық мысал және жобаның келесі қадамдары

Компания есеп жүйесін жаңартады: пайдаланушылар есепті өңдеудің баяулығын шағымдайды. IT жабдық арқылы жылдамдау үшін CPU-ларды көп ядролы модельге ауыстыруды шешеді. Бірнеше айдан кейін кластерге тағы бір түйін қосылады.

Инфрақұрылым деңгейінде бәрі логикалық көрінеді, бірақ лицензиялар метрика ауысуынан қымбаттайды.

Ядролар бойынша лицензиялағанда CPU-ны ауыстыру ең күшті өсімді береді. Мысал: 2 сокет x 12 ядро (24 ядро/хост) болды, 2 сокет x 24 ядро (48 ядро) болды — лицензияланатын ядролар екі есе өсті. Кейін үшінші түйін қосылса, лицензиялар көбіне барлық хосттарға есептеледі.

Егер сокеттер бойынша лицензияланса, CPU-ны сол сокеттер шегінде ауыстыру бағаны аз өзгертуі мүмкін, бірақ жаңа түйін қосу (қосымша сокеттер) бағаны айқын өсіреді.

Хосттар бойынша лицензияланса, негізгі оқиға — кластерді кеңейту. Мұнда вендордың ВМ миграциясын қалай түсінетіні өте маңызды — кейде автоматты миграция мүмкіндігі барлық хосттарды лицензиялауды талап етеді.

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

Сатып алудан бұрын кіріс деректер жинаңыз: сервер инвентаризациясы (сокеттер, ядролар, CPU модельдері), ПО тізімі және қазіргі лицензия шарттары, кластер схемасы мен ВМ орналастыру жоспары, HA/DR талаптары және миграция сценарийлері, 12–36 айға өсу болжауы (пайдаланушылар, ВМ, түйіндер).

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

Архитектураны лицензия метрикасына сәйкестендіріп құру көмектеседі — керісінше емес. GSE S200 деңгейіндегі серверлер мен кластерлерді қолданатын жобаларда алдын ала ойластырылған апгрейд жоспары ядролар немесе түйіндер қосылғанда бағаның түсе қалуын азайтады.