Oracle Database лицензиялау: Processor және NUP есептеу үшін қажетті деректер

Есептеу міндеті: қандай деректер керек және не үшін

Oracle Database лицензиялау көбіне екі сұраққа келіп тіреледі: қанша лицензия қажет және қай модель бойынша есептеу — Processor немесе Named User Plus (NUP). Қателер әдетте формулада емес, бастапқы деректерде болады: аппараттық сипаттамалар, виртуализация мен Oracle қай жерде тұрғаны туралы толық емес ақпарат.

Processor есептеу — есептеу ресурстарынан (процессорлар, ядролар және коэффициенттер) басталады. NUP — базаны тікелей немесе жанама түрде пайдалану құқығы бар адамдар мен жүйелерден есептеледі. Бірақ тіпті NUP үшін де алдымен Oracle қай серверлерде жұмыс істейтіні және қандай минималды шектер қолданылатынын түсіну керек. Сондықтан екі модельде де бәрі нақты орнатулардың инвентаризациясынан басталады.

Oracle әдетте бір ғана «мәліметтер базасы бар серверде» тұрмайды. Көбіне бұл орталар жиынтығы: физикалық хосттар, виртуалды кластерлер, тест және прод, репликация тораптары, кейде бөлек DR-площадка. Сондай-ақ виртуализация әсер етеді: бір жерде бөлінген ресурстарды есептеп жеткілікті болады, ал басқа жерде барлық кластерді ескеру қажет болуы мүмкін.

Ақпаратты екі қабатқа бөліп сақтау ыңғайлы:

• Бастапқы деректер: Oracle қайда орнатылған, CPU сипаттары (модель, сокеттер, ядрoлар), виртуализация түрі және кластер шекарасы, ортаға (prod, dev, test, DR) қатыстылығы, пайдаланушылар мен интеграциялар туралы мәліметтер.
• Есеп нәтижесі: Core Factor ескерілген Processor лицензиялары саны, NUP саны (минимумдармен тексерілген), лицензиялауға кірген тораптар мен орталардың тізімі.

Егер бастапқыда сізде тек "4 сервер және шамамен 200 қолданушы" ғана болса, нақты есеп шықпайды. Қай хосттарда Oracle нақты іске қосылғаны, қанша ядро бар және виртуализация қалай ұйымдастырылғаны керек. Сол кезде есеп қайталанатын және тексерілетін болады.

Қысқаша: модельдер — Processor және Named User Plus

Oracle-де Oracle Database үшін екі негізгі модель бар: Processor және Named User Plus (NUP). Таңдау деректерді қандай жинау керектігі мен оларды қалай өңдеу керектігін анықтайды. Сандар құжаттар мен выгрузкалармен расталатындай болуы маңызды, "шамалап" емес.

Processor: «қуат бойынша» лицензия

Processor лицензиясы процессорлар мен ядролар бойынша және CPU архитектурасына байланысты Core Factor коэффициентін ескере отырып есептеледі. Oracle-ға неғұрлым көп есептеу ресурсы бөлінсе, соғұрлым көп лицензия қажет болады, тіпті пайдаланушылар аз болса да.

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

Named User Plus: «адамдар/құрылғылар бойынша» лицензия

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

Кездесетін айырмашылықтардың бір себебі — NUP минимумы процессорға қатысты. Тіпті сізде 10 пайдаланушы болса да, ережелер бойынша сервердің қуатына байланысты көбірек шығуы мүмкін. Сондықтан NUP көбіне процессордан шығатын минимумдарды параллель тексеруді талап етеді.

Processor мен NUP дұрыс салыстыру үшін алдын ала дайындаңыз:

• Oracle орнатуларының инвентаризациясы (қай серверлер, қай жерде, қандай инстанстар);
• CPU және конфигурация туралы деректер (виртуализациямен байланыстырылған);
• орта(лар) туралы ақпарат (prod, test, dev, DR) және олардың жұмыс режимі;
• пайдаланушылар мен қолжетімділік тәсілдері (қосымшалар, интеграциялар, сервис-аккаунттар);
• растайтын материалдар: инвентаризация есептері, гипервизордан выгрузкалар, архитектура сипаттамалары.

Осы деректер дәл жиналса, есептеу механикаға айналады, болжамға емес.

1-қадам: жүйелер мен орнату нүктелерінің тізімін жинау

Бірінші қауіп — сіз дұрыс ортаны есептемей қаласыз. Сондықтан ядролар мен коэффициенттерден бастамай, Oracle нақты орнатылған немесе болуы мүмкін барлық орындардың тізімінен бастаңыз (әкімшілердің уақытша орнатуларын қоса).

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

Әрі қарай Oracle компоненттері қандай қолданылатынын белгілеңіз. Редакцияларды (EE немесе SE) бөлек көрсетіп, уақытша қосылған опциялар мен пакеттерді (мысалы, тест үшін қосылған опция) тіркеу маңызды — қысқа мерзімде қосылған опция да есептеуге әсер етуі мүмкін.

Орталарыңызды белгілеңіз: prod, test, dev, stage және DR. Мақсат — бір база екі түрлі атаумен екі рет есепке түспесін және DR қарапайым тест стенді ретінде «жасырынбасын».

Деректерге жауапты тұлғаларды тағайындаңыз. Жауапты адамдарсыз инвентаризация болжамдар жиынтығына айналады. Әдетте жеткілікті болады:

• қосымша немесе сервис иесі;
• ОС немесе платформа виртуализациясының әкімшісі;
• DBA немесе БД иесі;
• инфрақұрылым иесі (кластер, СХД, площадка).

Бірдей кесте форматын таңдап, жинау кезінде оны өзгертпеңіз. Міндетті бағандар:

• жүйе (сервер немесе ВМ), площадка, орта;
• рөл (DB, app, standby, DR);
• Oracle өнімі мен редакциясы;
• опциялар мен пакеттер тізімі (пайдалану фактісі ретінде);
• орнату нүктесі (host, VM, cluster), иесі және контакт.

Мысал: «DB-PROD-01» — vSphere кластеріндегі ВМ, орта prod, Oracle Database EE, Diagnostic Pack қысқа уақыт қосылған, иесі — ERP командасы. Мұндай деңгей жеткілікті, сол кезде CPU бойынша деректер жинауға көшуге болады.

2-қадам: процессорлар мен ядролар бойынша деректерді дұрыстап алу

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

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

Hyper-Threading (SMT) бөлек көрсетілуі тиіс. Ол логикалық ағындарды көбейтеді, бірақ физикалық ядролар санын өзгертпейді. Сондықтан операциялық жүйенің «логикалық процессорлар» туралы көрсеткіштері адастыруы мүмкін: 16 ядролық процессор HT қосулы кезде 32 ретінде көрінуі мүмкін, бірақ әдетте Processor есептеу физикалық ядролардан басталады.

Платформа түрін нақтылаңыз: rack-сервер, blade, HCI-тоқсан немесе арнайы жүйе. Бұл физикалық хост шекарасын кластер немесе шассиге шатастырмауға көмектеседі.

Екі тәуелсіз растауды болдырған жөн:

• BIOS/UEFI-ден алынған деректер (CPU модельі, сокеттер, ядролар);
• инвентаризация есебі (CMDB, есептеу жүйелері, актілер);
• жеткізу сипаттамасы немесе жабдық паспорты;
• сервердің сериялы нөмірі мен моделі.

Өлшем бірліктерін бөлек тіркеңіз: физикалық ядролар, логикалық ағындар, vCPU. ВМ-де 8 vCPU болуы мүмкін, бірақ хостта — 2 сокет, әрқайсысында 12 ядро. Processor есептеуі физикадан басталады, ал vCPU виртуализация шекараларын сипаттауға қажет.

3-қадам: Core Factor коэффициенттері және CPU-ға байланыстырылуы

Core Factor — Processor моделінде физикалық ядроларды Processor лицензияларына аудару үшін Oracle қолданатын коэффициент. Ол Oracle Core Factor Table-дағы белгілі платформалар мен CPU модельдері үшін қолданылады. Егер коэффициент жоқ болса (немесе сіздің платформаңызға жеке ереже қолданылса), есептеу басқаша болады. Сондықтан қай құжатты дереккөз ретінде пайдаланатыныңызды бірден анықтаңыз.

Маңызды сәт — процессордың дәл моделі. «2 сокет және 16 ядро» деген жалпы жазба жеткіліксіз: әр түрлі CPU отбасыларында Core Factor әртүрлі болуы мүмкін. Инвентаризацияда кемінде келесі деректер болсын: CPU өндірушісі, нақты моделі (ОС немесе BIOS шығаратындай жазылуынша), сокеттер саны, әр сокеттегі ядролар саны.

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

Бір серверде әр түрлі CPU болуы мүмкін (сирек, но ауыстырудан кейін болады) — орташа мән алмаңыз. Серверді CPU топтарына бөліп, әр топқа коэффициентті жеке қолданыңыз.

Есепті тексеруге болатын ету үшін кесте бағандары:

• хост/сервер, рөл;
• CPU model, сокеттер, cores per socket, жалпы cores;
• Core Factor (дереккөз көрсетілген);
• итог Processor = cores x Core Factor (есептеу ережелері бойынша дөңгелектелген).

Осылайша басты дау себебін — процессор моделі мен коэффициентті әртүрлі түсіндіруді алдын ала жоясыз.

4-қадам: виртуализацияны сипаттау және лицензиялау шекаралары

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

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

Виртуал орта бойынша не тіркеу керек

Барлық платформа детальдарын сипаттауға тырыспаңыз. Лицензия шекарасына әсер ететін минималды деректер жинаңыз:

• виртуализация технологиясы және миграция режимдері (live migration бар ма, ВМ қайда көшеді);
• кластер құрамы: Oracle ВМ іске қосылуы мүмкін хосттардың тізімі;
• ВМ ресурстары шектері: vCPU, лимиттер/резервациялар, қатаң байлану бар ма;
• орналастыру ережелері: DRS/автораспределение, affinity/anti-affinity;
• CPU бекіту (pinning, processor affinity) егер оны техникалық шекара ретінде қолдансаңыз.

Есеп кестесіне негізгі сұрақ: «Осы Oracle-ды іске қосатын ВМ ешқандай қолмен қайта орнатусыз және саясатты бұзусыз басқа хостқа ауыса ала ма?» Егер иә болса, шекара әдетте сол ВМ-нің мүмкін болатын барлық хосттарына дейін кеңейтіледі.

Қателеспеу үшін мысал

DB-PROD ВМ-і VMware-да бар. Қазір ол Host-03-та жұмыс істейді, бірақ кластер 8 хосттан тұрады және автоматты тасымалдау қосулы. Бастапқы деректерде шекара «8 хосттан тұратын кластер (тізімі)» ретінде көрсетілуі тиіс, Oracle DB-PROD орнатылған және кез келген кластер хостына көшуі мүмкін деп жазылады. Егер қатаң pinning екі хостқа орнатылған болса, оны баптаулардан растап жазу керек, әйтпесе есеп күмәнді болады.

Ауызша келісімдерге сенбеңіз. Лицензия шекаралары платформа конфигурациясымен расталуы тиіс және келесі айда немесе бір жылдан кейін кестені тексеретін адамға түсінікті болуы керек.

5-қадам: орталар, DR және есептеу ережелері

Есептеу алдында сіз не «орта» деп атайтыныңызды бекітіңіз. Әдетте орта: prod, test, dev, training және DR. Осы қадамдағы қате сандарды шындыққа сәйкес келмейтін етеді: әркім бірдей ұғымды әртүрлі түсінуі мүмкін.

Әр орта үшін оның мақсатын қарапайым тілмен сипаттаңыз: не үшін бар, иесі кім (бөлім және жауапты), қашан жұмыс істейді (24/7 немесе жұмыс уақыты), кімнің қолжетімділігі бар (әкімшілер, әзірлеушілер, мердігерлер), қатынас шектеулері бар ма.

DR-ды бөлек белгілеңіз: ыстық па, суық па, қаншалықты жиі іске қосылады, тест жоспары бар ма. Мысалы: "суық DR, апатта ғана іске қосылады, тоқсан сайын 4 сағаттық тест" немесе "ыстық DR, синхронды репликация, ай сайын ауыстыру тесті". Бұл болмаса біреу DR-ды толық прод деп есептейтін, ал басқасы өшірілген қор деп есептейтін жағдайлар болады.

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

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

• prod, test, dev, training, staging, dr-hot, dr-cold;
• бірдей формат: жүйе-орта-локация (мысалы, fin-prod-ast);
• CMDB мен есеп кестесінде аттар сәйкес болуы тиіс.

6-қадам: Named User Plus үшін деректерді қалай жинау

NUP есептеу үшін "шамалау" емес, расталатын бастапқы деректер жинау маңызды. Әдетте есептеуге тек тікелей БД-ға кіретін қызметкерлер ғана емес, қосымша арқылы қолжеткізетіндер де кіреді. Техникалық есептік жазбалар да дерекке қол жеткізсе, оларды бөлек санаған жөн.

Біріншіден, сіздің жағдайда "пайдаланушы" анықтамасын келісіңіз. Тікелей қолжеткізу бар ма (SQL-клиенттер, әкімші құралдары), қосымша арқылы ма (ERP/CRM/веб-портал), сервис интеграциялар (шина деректері, ETL, мониторинг), ортақ логиндер бар ма — бәрін тексеріңіз.

Пайдалы бастапқы дереккөздер:

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

Косвенный қолжетімділік — қауіпті тұс. Егер 500 адам қосымшада жұмыс істесе, ал қосымша БД-ға бір жалпы логинмен қосылса, бұл 500 адамды 1 NUP-қа айналдырмайды. Қосымшадағы «кіру топтарын» тіркеп, оларды Oracle-ден дерек ала алатын адамдармен салыстырыңыз.

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

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

Мысал: сатылым бөлімі үшін CRM-де 120 пайдаланушы бар, CRM Oracle-ға бір есептік жазбамен қосылады, плюс 3 интеграция (ETL, есептілік, мониторинг). Бастапқы деректерде 120 — қосымша пайдаланушылары ретінде және 3 сервис-аккаунт ретінде бөлек жазылады, кейін минимум тексеріліп үлкен мән қабылданады.

Қателер, олардың себебінен есеп бұзылады

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

Ең жиі шатасу — vCPU мен физикалық ядроларды араластыру. Виртуализация есептерінде vCPU-ды көру оңай, ал Processor әдетте хосттың физикалық сипаттамалары мен процессор моделіне сүйенеді. Егер процессор моделі жоқ болса, қажетті коэффициентті сенімді түрде таңдай алмайсыз.

Инфрақұрылым бойынша қателер

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

Тағы бір жиі жағдай — «қоғамда ВМ бекітілген», бірақ іс жүзінде DRS немесе әкімшілер оны барлық нодтарға таратады. Расталған шектеулер мен дәлелдерсіз есеп таласқа түседі.

Пайдаланушылар мен орталар бойынша қателер

NUP үшін жиі жасалатын қателік — пайдаланушыларды белсенді сессиялар бойынша санау. Әдетте есепке тек қазір кіріп тұрғандар ғана емес, базаға қолжеткізуі мүмкін барлық адамдар кіреді (қосымша арқылы және сервис-аккаунттар арқылы).

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

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

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

Инвентаризация мен техника тексеру

Егер бір хост тізімнен тыс қалса, есеп әдетте төмендетілген болады.

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

Виртуализация, орталар және NUP тексеру

Алгоритм алдын ала келісілген ережелерге сүйеніп ғана жұмыс істесін.

• Виртуализация және лицензия шекаралары сипатталған: ВМ қайда миграция жасай алады, қандай хосттар мүмкін пулға кіреді.
• Барлық орталар барлық дереккөздерде бірдей аталған (prod, test, dev, DR) және иелерімен расталған, соның ішінде дау туғызатын жағдайлар (мысалы, кейде продқа айналатын тест).
• DR үшін: ыстық па, суық па, қаншалықты жиі іске қосылады, репликация бар ма және режимді кім растайды — көрсетілген.
• NUP үшін есеп әдісі және дереккөздер бекітілген: IAM/AD, HR, қосымшалар реестрі, қолжетімділік есептері.
• Oracle опциялары мен пакеттерінің нақты қолданылуы (жәй ғана орнатылған емес) бөлектелген. Мысалы, Partitioning немесе Diagnostics қосулы болса, бұл нәтижеге әсер етуі мүмкін.

Өзіңіз тексеріңіз: бір кестені ашып, кез келген сервер бойынша 30 секунд ішінде "қай CPU моделі, қанша ядро, қандай factor, кластер шекарасы қайда, орта қандай және дереккөз қай" деп жауап бере алсаңыз, деректер дайын.