BI және DWH үшін Microsoft SQL Server лицензиясы: реплика, тест

Неліктен контурларды қосу лицензияға бірден әсер етеді

BI мен DWH әлі кішкентай болуы мүмкін, сондықтан оларды көбінесе бір SQL Server-де ұстайды: бір база, бір сервер, бір жауапкершілік нүктесі. Дегенмен деректер, есептер және қолжетімділік талаптары өсген сайын архитектура жылдам күрделене түседі. Сол сияқты SQL Server лицензиясы да күрделенеді: қосымша түйіндер, әртүрлі сценарийлер және қосылымдар пайда болады.

Көбінесе бірінші қадам — реплика немесе standby, ол үзілістер мен жаңартуларды ұзақ тосын күтусіз өткізу үшін қажет. Одан кейін тесттік контур бөледі: ETL өзгерістері, схема түзетулері мен есептердегі эксперименттерді продте орындау қауіпті. Сонымен қатар бөлек есептік сервер логикалық түрде туындайды, егер Power BI, SSRS немесе ad hoc аналитика ауыр сұраныстар жасап, түнгі жүктемелерге кедергі жасаса.

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

Осы кезеңде әдетте сұрақтар туындайды:

• Репликадан есептер оқылатын болса, оны екінші прод есептеуге бола ма?
• Тесттік контурды арзандата аламыз ба, егер оған кейде бизнес-пайдаланушылар кірсе?
• Бөлек есептік серверді лицензиялау керек пе, егер ондағы деректер тек оқылады?
• Виртуализация және бірнеше SQL-инстанс бір хостта болғанда ережелер қалай өзгереді?

Жауаптарды шамамен есептеу үшін алдын ала деректер жинаңыз: SQL Server редакциялары, лицензия моделі (Server+CAL немесе Core), физикалық ядрола саны немесе ВМ параметрлері, әр сервердің рөлі (жазады ма, оқиды ма, пассивті ме), кім және қалай қосылады, сондай-ақ Software Assurance бар-жоғы (ол отказоустойчивость және жылжыту құқықтарына әсер етеді). Егер DWH арнайы серверде орналастырылса (мысалы, GSE S200 Series қатарлы стойкалық серверлер), бұл ақпарат спецификацияда бар болады. Осы деректерді нақты пайдалану сценариімен байланыстыру маңызды.

SQL Server лицензиясының модельдері қарапайым тілмен

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

Ең жиі кездесетін екі модель: Core (ядро бойынша) және Server+CAL.

Core моделінде сервердің есептеу қуатына төленеді, ал оған шексіз пайдаланушылар мен жүйелер қосыла алады. Server+CAL модельінде сервер лицензияланып, содан кейін SQL Server-ге қосылатын пайдаланушыларға немесе құрылғыларға CAL сатып алыңыз. BI және DWH үшін көбіне Core таңдайды: сақтау жүйесіне адамдардан басқа сервистер, интеграциялар, есептер, ETL қосылады және CAL санын есептеу қиын.

Терминдерді ажыратқан ыңғайлы:

• Сервер — SQL Server орнатылған физикалық машина немесе виртуалдық машина.
• Инстанс — сол сервердегі бөлек SQL Server орнатылымы (инстанстар бірнеше болуы мүмкін).
• Дерекқор — инстанстағы нақты сақтау орны (дерекқорлар көп болуы мүмкін).

Мұндағы негізгі жайт: лицензия әдетте серверге (және егер Core болса — оның ядроларына) «байланады», ал дерекқорлар санына емес. Сондықтан бір сервер техникалық тұрғыдан DWH, есептік сервер және витриналарға қызмет ете алады. Бұл ыңғайлы, бірақ есепті қиындатады: жүктеме араласады, ал прод, реплика, тест сияқты орта талаптары соңғы есепке әсер етеді.

BI/DWH үшін лицензияларды есептегенде негізгідан бастаңыз: прод-жүктемені шын мәнінде қанша бөлек сервер (немесе ВМ) қамтамасыз етеді және қай модель (Core немесе Server+CAL) сіздің қолжетімділік түріңізге сәйкес келеді.

BI және DWH-та қандай серверлер болады және жүктеме қайда түседі

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

Типтік картина: продте негізгі хранилище (DWH) бар, жанында staging — шикі деректер қабылдайтын аймақ, ETL/ELT процестері, витриналар (data marts) және есептер қабаты. Кейде есептер сол серверде болады, кейде жүктемені азайту үшін бөлек шығарылады.

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

Практикада рөлдер жиі былай көрінеді:

• DWH-ядро: фактілер мен өлшемдерді сақтау, күрделі трансформациялар, индексация.
• Staging: деректерді қабылдап, жүктеуге дайындау.
• Витриналар және семантика: есептерге арналған деректер, оқу көп, жазу аз.
• Есептер: ad hoc сұраныстар, экспорттар, дашбордтар, жұмыс уақытында шапшаң конкуренция.
• Реплика: апаттық резервтен оқылатын түйінге дейін, есептер мен экспорттарға арналған оқылатын нұсқалар.

Репликаға қатысты шынайы жауапты беру маңызды: ол тек апатқа күту үшін тұр ма, әлде онда нақты сұраныстар орындала ма? Оқылатын реплика есептер мен экспорттарға қызмет етсе, ол тағы бір жұмыс контурына айналады.

Тесттік орталарда терминдер де жиі шатастырылады. Dev — код пен схеманы өзгертетін орын. Test — тест-сценарийлер бойынша дұрыстығын және жүктемесін тексеретін орын. Preprod — продке барынша ұқсас орта, релизді нақты параметрлерде тексеру үшін. Егер preprod-та продке ұқсас тапсырмалар орындалса, ол бөлек өндірістік сервер саналады және лицензиялау қаталдығы артады.

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

Реплика және failover: қашан ол резерв, қашан екінші прод

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

Пассивті failover әдетте былай түсініледі: екінші сервер синхрондалады, бірақ пайдалы жүктеме орындамайды және тек апат жағдайында қосылады. Мұндай пассивті түйінге құқықтар Software Assurance және бағдарламалық шарттарға байланысты берілуі мүмкін. Бұл сатып алу алдында тексеруді талап етеді.

Оқылатын реплика есептер немесе экспорттар үшін қолданылса — бұл жұмыс жүктемесі. Тіпті "тек қарау" болса да, SQL Server CPU, жад және диск ресурстарын пайдаланады, сондықтан бұл екінші өндіріс ретінде қарастырылуы мүмкін. Сол сияқты репликада регулярлы бақылаулар, ауыр салыстырулар немесе сыртқы командаларға қолжетімділік болса, оны тағы да есепке алу қажет.

Резервті «жұмысшыдан» ажырату үшін тез тексеріңіз:

• репликада пайдаланушы қосылымдары бар ма (Power BI, Excel, SSRS, экспорттар);
• онда SQL Agent jobs, ETL, пересчеттер немесе сапа тексерістері орындала ма;
• оны негізгі түйінді жеңілдету үшін бэкаптар немесе қызметтер үшін қолданасыз ба (reindex, CHECKDB);
• оны үнемі оқуға ашып ұстайсыз ба, тек апатқа қалдыру емес пе.

Шекара көбіне «тек апатта» және «продакшнға кедергі келтірмеу үшін» деген формулировкамен бөлінеді. Екіншісі көбіне реплика лицензиялауда қосымша талаптар туғызады.

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

Тесттік контур: практикалық жағынан не есептеледі

BI және DWH-та тесттік контур ETL өзгерістері, витрина схемаларын және есептеулерді қауіпсіз тексеруге арналған. Артында тұрған дерекқорда кішкентай түзету толық апта немесе ай бойына деректерді бұрмалауы мүмкін. Сондықтан бөлек тест қателерді пайдаланушыларға жетпей бұрын ұстап қалуға көмектеседі.

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

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

Виртуализация жағдайында да айырмашылық бар. Егер SQL Server ВМ-і хосттар арасында еркін көшіп жүрсе (vMotion/Live Migration), лицензияларды қай жерде бекіту керектігін ескеру қажет. Көп жағдайда лицензияны физикалық серверлер арасында жылжытудың 90 күн ережесі немесе Software Assurance арқылы жеңілдетілген механизмдер бар. Бұл тесттік ВМ-нің де лицензия талап етуі мүмкін екенін білдіреді, егер оны нақты хостқа бекітпесеңіз.

Бөлек есептік сервер: нені лицензиялау керек

Есептерді бөлек серверге шығару — DWH ауыр сұраныстан тежеліп қалған кезде жиі қолданылатын шешім. Есте сақтаңыз: лицензияланатын элемент — есеп интерфейсі емес, сол серверде іске қосылған SQL Server компоненттері және олар сұраныстарға қызмет көрсетеді.

Егер есептік сервер тек есепті көрсетсе, ал барлық сұраныстар прод DWH-да орындалса, онда сіздің негізгі назарларыңыз прод DWH лицензиясында болады. Бірақ маңызды сәт: егер есептік серверде SQL Server Reporting Services немесе басқа SQL Server компоненттері орнатылған болса, аудитте ол да SQL Server орнатылған сервер ретінде қарастырылып, лицензия талап етуі мүмкін.

Егер есептер репликадан немесе бөлек витринадан оқылса, лицензиялау сол жерде сұраныстар орындайтын SQL Server инстансына қатысты болады. Реплика немесе витрина бөлек серверге шығарылған болса — ол тағы да толыққанды жұмыс түйіні болып, лицензиялануы мүмкін.

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

Есептеу алдында анықтаңыз:

• Қандай SQL Server компоненттері қай серверде іске қосылған (движок, SSRS және т.б.);
• Деректер қайдан оқылады (прод DWH, реплика, витрина);
• Есептерге қанша пайдаланушы/құрылғы қосылады (Server+CAL үшін маңызды);
• Есептік серверде жергілікті дерекқорлар бар ма (кэш, витрина);
• Қандай шапшаңдықтар күтіледі: қанша бір уақытта сессия және есептер қаншалықты жиі жаңартылады.

Бұл жауаптар әдетте айтады: бұл «жәй визуализация қабаты ма» немесе қосымша SQL Server түйіні ме.

Қадаммен: өз схемасына лицензияны қалай бағалау

Мақсат — бастапқы бағалау алу, дау туындаған жерлерді серіктеспен немесе келісім шартпен тексеру. BI/DWH-та реплика, тест және есептік серверлер «бір SQL Server»-ді бірнеше түйінге айналдыра алады.

Қадам 1. Нақты сервер картасын сызыңыз

Логикалық рөлдер емес, нақты машиналар мен инстанстарды белгілеңіз: қай жерде SQL Server орнатылған, ETL қайда тұр, есептер қайда. Физикалық серверлер, ВМ және кластерлерді бір тізімде ұстап қойыңыз.

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

Қадам 2. Реплика мен тесттің нақты қолданылуын сипаттаңыз

Пайдалану шешеді. Тез тексеріңіз:

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

Қадам 3. Модельді таңдап, кестеге салыңыз

Содан кейін Core немесе Server+CAL таңдап, қолданыстың түріне қарай есептеңіз. Қолданушылар көп және өзгермелі болса, сервистер өте көп болса Core қарапайым әрі болжамды болады. Егер пайдаланушылар аз және анықталған болса — Server+CAL тиімді болуы мүмкін.

Барлығын кестеге түсіріп, қандай сценарийлер «жеңілдіктен» толық лицензияға оңай ауысып кететінін көрсетіңіз:

Инфрақұрылымды жаңарту жоспарланған кезде (мысалы, дерекқор мен есептер үшін бөлек серверлер) бірден ВМ-дердің қай жерде тұратынын және SQL Server үшін қанша ядро бөлінетінін көрсете отырып бекітіңіз. Бұл көбінесе «тағы бір сервер» ойынан гөрі нақты әсер етеді.

Жиі қателіктер және тұзақтар

Ең қымбат қателік — лицензияларды «деректер бойынша» есептеу. Негізгі нәрсе — SQL Server қандай есептеулер орындайды, сұраныстар қайда жүреді және кім (адамдар мен сервистер) қосылады.

Репликалар бойынша жиі қателеседі. Егер реплика шынымен "жылы резерв" болып, онда жұмыс жүктеме болмаса — бәрі жақсы. Бірақ есептер, экспорттар, түнгі сапа тексерістері немесе аналитиктердің уақытша қолжетімділігі іске қосылғанда реплика жұмыс түйініне айналады.

Екінші тұзақ — қызметтік қосылымдар. Интеграциялар, ETL, жоспарлаушылар, сервистік есептік жазбалар мен коннекторлар көбіне "пайдаланушылар" тізіміне кірмейді. Ал Server+CAL моделінде дәл сол қосылымдар күтпеген CAL санын талап етуі мүмкін.

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

Виртуализацияны бөлек тексеріңіз: ВМ SQL Server хосттар арасында миграцияланса, лицензиялардың қай жерде болатынын және тасымалдау құқықтарын анықтау қажет.

Қысқа тексеріс тізімі:

• Қай түйінде есептер мен ауыр сұраныстар орындалатынын бекітіңіз, соның ішінде реплика.
• Барлық қосылымдарды тізіп шығыңыз: адамдар, сервистер, интеграциялар.
• Dev/test, UAT және preprod орталарын рұқсаттар мен мақсат бойынша бөлу.
• Виртуализация мен ВМ миграциясын сипаттаңыз.
• Лицензияны деректер санына емес, ядроларға немесе қолжетімділікке (CAL) есептеңіз.

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

Бюджетті есептемес бұрын фактикалық схеманы жазыңыз: қай SQL Server инстанстары қай жерде, кім қосылады және қандай тапсырмалар орындалады. Осындай детальдар көбіне соңғы санды өзгертеді.

Тексеріңіз:

• Реплика шынымен тек «апатқа ғана» ме, әлде онда есептер, экспорттар, салыстырулар немесе ad hoc анализдар жүреді ме?
• Тесттік контурға кімнің қолы бар (тек әзірлеушілер ме, әлде аналитиктер, мердігерлер де бар ма)? Онда деректер бар ма және оны тұрақты түрде пайдалануға әдеттенкен бе?
• Қай түйінде есептер шынымен іске қосылады: продте, репликада немесе бөлек түйінде/витринада?
• Әр түйін үшін ядролар мен виртуализация: сервердегі физикалық ядролар саны, әр ВМ-нің vCPU саны, ВМ тасымалдау құқығы бар ма?
• 6–12 айға жоспар бар ма: екінші түйін, тағы реплика, витриналарды кеңейту, пайдаланушылардың өсуі?

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

Сценарий мысалы: DWH + реплика + тест + бөлек есептік сервер

Мысал ретінде: продовый DWH сервері бар, жанында реплика, бөлек тесттік контур және пайдаланушылар (Power BI, Excel, SSRS және т.б.) қосылатын бөлек есептік сервер бар делік.

Бастапқы шарттар: прод DWH ETL жүктемелерін және сұраныстарды қабылдайды, реплика отказоустойчивость үшін, тест әзірлеушілер үшін, есептік сервер DWH-ны тежемеу үшін бөлінген.

Егер есептер прод DWH-тан репликаға ауысса, реплика «жұмысқа» көшіп, оны прод ретінде есептеу керек болады.

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

Матрица мысалы:

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

Келесі қадамдар: талаптарды бекітіп, сатып алуға дайындау

Редакция мен лицензияларды таңдаудан бұрын фактілерді жинаңыз. BI/DWH-та жиі кездесетін нюанс — реплика оқылатын болады, тест пен есептер бөлек түйінге шығады. Есептеу нақты схемаға және 6–12 айға арналған жоспарға қарай жүргізіледі.

Бастапқы проработкаға әдетте мына деректер жеткілікті:

• SQL Server инстанстары тізімі және олардың рөлдері (прод, реплика, тест, есептер);
• Серверлердің ағымдағы және жоспарлы ресурстары (CPU, RAM, дискілер) және виртуализация;
• Қайсы пайдаланушылар/сервистер қалай және қаншалықты жиі қосылады (интерактивті, қосымшалар арқылы, BI арқылы);
• Қолжаттылық талаптары (RPO/RTO) және қызметке енгізу мерзімі;
• Уақыттық шектеулер (қашан іске қосу керек).

Содан кейін инфрақұрылымның ролдерін бөлу жеткілікті ме тексеріңіз. Көбіне қателік — репликаны және есептерді «қалдық принципі» бойынша орналастыру, ал кейін түйіндер ресурстар үшін бәсекелес бола бастайды.

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