Жоғары қолжетімділік кластеріне арналған СУБД лицензиясы: бюджет

Мәселе неде: HA-кластер және лицензияларға күтпеген шығындар

Жоғары қолжетімділік (HA) кластерін әдетте бір ғана уәде үшін алады: егер бір сервер немесе түйін құлса, сервис жұмысын жалғастырады. Бизнес үшін бұл жұмыс уақытын ұзарту, деректер жоғалтпау, біркелкі дежурство және түсінікті SLA дегенді білдіреді.

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

Араласу тағы да өседі, себебі архитектураның мақсаты әр түрлі. Қалпына келу сенімділігі «қалай құламасқа» дегенге жауап береді, ал масштабтау - «қалай көбірек жүктемені көтеруге». Active-passive әдетте үздіксіздікке бағытталған: екінші түйін апат кезінде қосылады. Active-active жиі жүктемені бөлуге, жылдамдық пен өнімділікке арналған: екі түйін бір уақытта жұмыс істейді. Осы режимдер лицензия бюджетінде үлкен айырмашылық тудыруы мүмкін.

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

Вендормен келіссөзге дейін бес нәрсені айқындап алған жөн: жобаның мақсаты (тек 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 үшін бұл шешуші: егер кластер жүктемені кез келген түйінге ауыстыра алса, вендор барлық түйіндерге лицензия талап етуі мүмкін, әдетте біреуі ғана жұмыс істейтін болса да.

Жай мысал: екі хост бар, әрқайсысы 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 және нақты failover ережелері бар сценарий бюджетті ұтымдырақ етіп сақтайды.

Топологиялар мен жұмыс режимдері, есепті өзгертетіндер

Active-passive және active-active анық болса да, соңғы баға кластердің нақты өмір сүру режиміне тәуелді. Көбінесе ең маңызды сұрақ: қанша түйін бір уақытта жұмыс істей алады — уақытша да болса.

Ең жиі вариант — 2 түйін. Бірақ жобаларда тез 3 түйін (кворум үшін), N+1 схемасы (бір резерв бірнеше жұмысшыға) немесе бірнеше алаңға созылған кластер пайда болады. Әр қадам есепті өзгертеді, себебі көп ережелерде маңыздысы «қанша сервер тұр» емес, «қанша сервер белсенді болуы мүмкін» және «олар қай жерде болуы мүмкін».

Жоспарлы миграциялар мен жаңартулар көбіне «біреуі жұмыс істейді, екіншісі простаивает» деген схеманы бұзады. Әдетте әкімшілер техникалық қызмет көрсету үшін переключады, откатты тестілейді, кэшті «жылытады» және кейде уақытша екі түйінді белсенді күйде ұстайды. Егер лицензиялық саясат бұл параллельді жұмысты белсенді деп санаса, бюджет оны көтере білуі тиіс.

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

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

DR-үстіндегі standby-ді бөлек қарастырыңыз. Бұл бір площадка ішіндегі 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 бетке сипаттап, IT және қауіпсіздікпен бекіту;
• Failover тесттерін өткізіп, түйіндердің нақты жүктемесін жазбаша тіркеу;
• Вендордан standby, реплика және DR ережелерін жазбаша алу;
• Лицензияларды ортаға (prod/test/dev) бөлу және 12–24 айға өсу жоспарлау;
• Платформаны тексеру: серверлер, желі, СХД, қуат және салқындатуды резервтеу.

Егер жоба жабдық жеткізу мен HA интеграциясын қамтыса, интегратормен платформа туралы алдын ала келісіңіз. Мысалы, GSE.kz (gse.kz) — Қазақстандағы өндіруші және жүйелік интегратор, S200 желісін және 24/7 қолдауды есепке ала отырып серверлерді таңдап, лицензия мен архитектура үйлесімді болуын қамтамасыз ете алады.