Резервтік көшіру лицензиялары: деректердің өсуіне сәйкес таңдау

Лицензиялардың деректер өсімімен неге қиындық тудыруы мүмкін

Резервтік көшіру лицензиялары көбіне деректерден жылдамырақ қымбаттайды. Жұмыс жүйелерінің көлемі 20% өссе де, бэкапқа төлем екі есе артуы мүмкін. Себеп әдетте «таза терабайттарда» емес: сіз инфрақұрылым қалай құрылғанына, қанша объект қорғалатынына және көшірмелерді қанша уақыт сақтайтынына да төленесіз.

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

Инфрақұрылым кеңейген кезде практикалық сұрақтар туындайды:

• Төлем неге негізделеді: серверге, сокетке, виртуалдық машинаға немесе деректер көлеміне?\n- Егер тағы бір гипервизор хосты немесе екінші сайт пайда болса, не өзгереді?\n- Ретеншн мен сақтау жиілігін көбейту қаншаға түседі?\n- Тестілеу ортасы мен уақытша жобалар қалай есептеледі?

Ең қауіпті жағдай — лицензияны «на толқында» алу, 1–3 жылдық болжамсыз. Бірнеше айдан кейін сіз аз тиімді бағада қосымша сатып алып, аралас лицензиялар жинап алуыңыз мүмкін немесе есептеуде шектеулерге кезігесіз. Бюджет болжамсыз болады, және жеткізушімен талқылаулар үнемі қайта есептеумен өтеді.

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

Үш лицензия моделі: қысқа және нақты

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

Per workload — қорғалатын бірлік үшін төлейсіз: виртуалдық машина, физикалық сервер немесе қосымша (мысалы, дерекқор). Қорғалатын объектілердің санына қарай төлем жасалады.

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

Per TB — деректер көлеміне қарай төлейсіз. Маңызды сұрақ — қай көлем: бастапқы деректер, дедупликация/сығудан кейінгі көлем немесе репозиторийдегі орын.

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

Жиі қате — не лицензияға кіретіні, не бөлек сатып алынатынын шатастыру. Кейбір вендорларда қосымша опциялар ретінде ұзартылған ретеншн, бұлтқа көшіру, шифрлау, белгілі гипервизорларды қолдау, таспалар, сайттар арасында репликация немесе 24/7 қолдау бөлек сатылады.

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

Простой мысал: екі хосттағы 20 ВМ. Per workload бойынша 20 объект үшін төлейсіз, per socket бойынша — шамамен 4 сокет үшін, ал per TB кезінде бәрі деректер өсімі мен сақтау мерзіміне тәуелді болады.

Per workload моделі: артықшылықтары мен кемшіліктері

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

Артықшылығы — "қанша бірлік қорғалады" деген деңгейде болжамдылық. Мысалы, 80 кіші ВМ бар және 90 болады деп түсінсеңіз, бюджетті есептеу оңайырақ.

Кемшілігі — ВМ және сервистер саны өссе, шығын тез өседі. Деректер көлемі шамалы өзгергенімен, 20 жаңа кіші ВМ қоссаңыз, лицензия шығыны едәуір ұлғаюы мүмкін.

Сатып аларда не нақты бір жүктеме деп есептелетінін анықтаңыз. Әдетте сұрақтар дерекқорлар мен қосымшалар айналасында туындайды (олар бөлек есептеледі ме), контейнерлер мен Kubernetes, файл ресурстары мен NAS (сервер бойынша, шар бойынша немесе көлем бойынша), сондай‑ақ клондар, шаблондар мен уақытша орталар туралы болады.

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

Мысал: 40 ВМ бастап, бір жыл ішінде витрина, бірнеше сервис пен тест контур қосылып — 75 ВМ болды. Деректер орташа өсті, бірақ per workload шығындары екі есеге жуық өсті. Бұл модельде прод пен тесті айқын бөліп бақылайтындар жеңіске жетеді.

Per socket моделі: виртуализацияда қалай жұмыс істейді

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

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

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

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

Сатып алмас бұрын ережелерді нақтылаңыз:

• Барлық кластер хосттары лицензиялануы керек пе, әлде нақты қорғалатын ВМ бар хосттар ғана ма?\n- Резервтік және DR‑хосттар есептеледі ме?\n- Сокетқа ядро бойынша шектеулер бар ма немесе жоғары CPU тығыздығы үшін қосымша төлемдер бар ма?\n- Сервер ауыстырғанда лицензияларды көшіруге бола ма және қаншалықты жиі?

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

Per TB моделі: түсінікті, бірақ ретеншнге сезімтал

Per TB сатып алушыларға түсінікті: сіз деректер көлемі үшін төлейсіз, сокеттер немесе «ворклоадтар» үшін емес. Бюджетке қарағанда бұл мөлдір көрінеді, бірақ тек нақты «TB» нені білдіретінін келіссеңіз ғана.

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

Per TB‑ті тез өсіретін не нәрсе

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

Қай жерде жиі дау шығады

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

Практикалық мысал: ұйымда 50 TB жұмыс дерегі бар. 30 күн ретеншн және сағат сайынғы инкременттер кезінде, репозиторий көлемі деректер белсенді өзгеріп, дедупликация әлсіз болса, 120–180 TB‑қа дейін өсуі мүмкін. Сондықтан per TB таңдағанда есептеу әдісін алдын ала бекіту және ретеншн мен қосымша көшірмелер әсерін бөлек бағалау маңызды.

Қарапайым математикасыз өсу мөлшерін бағалау

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

Үш өлшем жеткілікті: қазіргі қорғалған көлем, орташа айлық өсім және шың айлар. Шыңдар көбіне орташа көрсеткіштен маңызды: тоқсанның жабылуы, жылдың соңы, үлкен экспорттар, есептер іске қосу немесе жаңа камералар.

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

Одан кейін ретеншн‑нің көлемті қалай көбейтетінін бағалаңыз. Қалпына келтіру нүктелерін неғұрлым ұзақ сақтасақ, per TB модельі өзгерістерге соғұрлым сезімтал болады. 7 күннен 30 күнге көшу де «тірі» деректердің өсуіне қарағанда үлкен әсер беруі мүмкін.

Жай ғана тез схема:

• Қорғауға нақты қандай деректер кіретінін бекітіңіз.\n- Орташа және ең нашар айлық өсімді қараңыз.\n- Үлкен болашақ қосымшаларды (жобалар, филиалдар, қызметтер) бөлек жазыңыз.\n- Ретеншн‑ды тексеріңіз: 7, 30, 180 күн және архивті нүктелер (қажет болса).\n- Миграциялар, біріктірулер және реттеуші талаптар сияқты өсімді тездететін оқиғаларды белгілеңіз.

Мысал: ұйымда 80 TB бар, ай сайын 2 TB өсім, бірақ үш айдан кейін 40 камера қосылып, қосымша 30 TB пайда болады. Егер ретеншн 14 күннен 90 күнге өссе, «сюрприз» 2 TB‑тан гөрі сақтау саясатының өзгерісінде болады.

Нақты өсуге сай лицензия моделін кезең бойынша таңдау

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

Кіріске не бар екенін жинаңыз: қандай жүйелер қорғалады (ВМ, физикалық серверлер, дерекқорлар), олар қайда орналасқан (бір сайт па әлде бірнеше) және қандай қалпына келтіру түрі жиі қажет (файлдар, толық ВМ, жеке дерекқорлар).

Кейін қарапайым тәртіп көмектеседі:

1. Бүгінгі қорғаныстың құрамын бекітіңіз: ВМ саны, физикалық хосттар, маңызды базалар, деректер көлемі және күнделікті өзгеріс жылдамдығы.\n2) Жоспарлау мерзімін таңдаңыз: әдетте 12–24 ай — төтенше режимде қосымша сатып алудың алдын алу үшін.\n3) 2–3 өсу сценариін сипаттаңыз: базалық, орташа және стресс (жұмысшылар саны тез өсуі, видео басталуы, жаңа сервиске көшу).\n4) Сценарийлерді лицензия драйверімен салыстырыңыз: \n - жүйелер саны өссе — per workload жиі тиімді;\n - хосттар мен сокеттер өссе — per socket;\n - егер объектілер аз, ал терабайттар тез өссе — per TB.\n5) Есеп ережелері мен шектеулерді тексеріңіз: workload не есептеледі, сокеттер қалай саналады, per TB үшін қандай көлем алынады және ретеншн неге әсер етеді.

Мысал: 40 ВМ екі хостта, бір жылдан соң 80 ВМ болады, бірақ көлем тек 20% өседі. Сонда per socket тиімді көрінуі мүмкін, егер хосттар мен сокеттер саны өзгермесе; per workload болса ВМ санына байланысты өседі. Егер бизнес ұзақ сақтау талап етсе, per TB ретеншн нәтижесінде қымбаттауы мүмкін.

Серверлер немесе СХД жаңарту жоспарланса, болашақ өсімді закуптар жоспарына байлау пайдалы — сол кезде өсім нақты жобаларға байланысты және дәл есептеледі.

Бэкап лицензиясын таңдағанда жиі кездесетін қателер

Ең қымбат қате — «бәрі қазіргідей болады» деп ойлау. Бэкап тек жаңа файлдардан ғана өспейді: сақтау саясаты, тесттік көшірмелер мен қолжетімділік талаптары шығынды арттыра алады.

Қате 1: тек қазіргі көлемді есептеу және ретеншнды ұмыту

Команда: «бізде 60 TB дерек бар» — сол бойынша бюджет жасайды. Бір жарым жылда ретеншнді 90 күнге көтеріп, ай сайын архивтік нүктелер қосқанда есеп сәйкес келмейді. Деректер жақын тұрса да, қалпына келтіру нүктелері көбейеді.

Қате 2: тестілік және резервтік сайттарды ескермеу

Тек басты сайт лицензиясын алдық деп ойлап, кейін DR‑сайт, тестілік қалпына келтіру орны немесе жаңарту стенді туралы ұмытып қалады. Кейбір вендорлар реплика үшін де, екінші сервер үшін де, немесе қалпына келтіру кезінде орналастырылған ворклоадтар үшін де лицензия талап етеді.

Ереже: егер сайт қорғау немесе қалпына келтіру процесіне қатысса — лицензия қалай есептелетінін тексеріңіз.

Қате 3: «шикі» көлем мен «эффективті» көлемді араластыру

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

Қате 4: тек көлем өсімін есептеп, жүйелер санының өсуін ескермей қою

Егер сіз «көлденең» өсіп — ВМ, базалар, сервистер, филиалдар көбейсеңіз, per workload және per socket модельдері TB‑қосымсыз да қымбаттауы мүмкін. Бұл әсіресе жаңа қолданбалар пайда болғанда айқын көрінеді.

Қате 5: есеп жүргізу ережелерін құжаттамай қою

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

Минимум бекіту керек нәрселер:

• қай модель мен метрика қолданылады (workload, socket, TB);\n- қандай есеп «шынайы» сан деп есептеледі (нақты есеп/выгрузка);\n- тесттік және резервтік сайттар, уақытша қалпына келтіру қалай есептеледі.

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

Команда ішінде не есептелетінін және кім жауапты екенін келісіңіз — сол кезде модель қағазда ғана емес, күнделікті жұмыста да қолайлы болады.

Не тез өсетінін бағалаңыз: TB немесе workloads саны. Егер жаңа ВМ, базалар мен сервистер үнемі қосылса, объектілер саны жиі «жарылып» өседі. Егер сервистер аз, бірақ көлемдер тез өссе (логтар, видео, аналитика), онда басты драйвер — TB.

12–24 ай горизонтына инфрақұрылымды тексеріңіз. Per socket үшін кластердегі физикалық хосттардың саны мен әрқайсыдағы сокеттер саны маңызды. Ловушка мынада: «хосттар саны сақталады», бірақ жабдық өзгеріп, лицензия қайта есептеледі.

Ретеншнды бөлек бекітіңіз: ішкі талаптар мен салалық талаптарға сай қанша сақтау міндетті. Ұзақ сақтау, immutable көшірмелер немесе жиі нүктелер болса — per TB күтпеген түрде қымбаттауы мүмкін.

Және DR‑ды ұмытпаңыз: екінші ЦОД, резервтік сайт, бұлтқа көшірме немесе басқа қаладағы копия кейде сақтау көлемін екі еселейді немесе лицензияға қосымша объектілер енгізеді.

Контрольдық сұрақтар:

• Бізде не жылдам өседі: TB ма әлде workloads па?\n- 1–2 жылдан кейін хосттар мен сокеттер саны қандай болады?\n- Қандай ретеншн міндетті және кім оны бекітеді?\n- DR болады ма: екінші ЦОД немесе қосымша көшірме?\n- Лицензиялық лимиттерді кім ай сайын өлшеп, бақылайды?

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

Практикалық мысал: шешім өсім сценарийіне байланысты қалай өзгереді

Бастапқы сурет: 60 TB қорғалған, орташа өсім 3 TB/ай, ретеншн 30 күн. Бэкап виртуалды ортада жұмыс істейді және көшірмелер дисковый сақтауында сақталады. Мақсат — өсу тұрақты түрде қосымша шығынға айналмасын.

Сценарий 1: 20 ВМ және жаңа филиал қосылды (per workload)

Per workload бойынша шығындар қорғалатын бірліктер санына қарай өседі. Деректер көлемі орташа ғана өзгеруі мүмкін, бірақ ВМ паркі мен филиалдың қосылуы лицензия санын тез арттырады.

Сценарий 2: кластер кеңейіп, сокеттер саны өсті (per socket)

Per socket көп ВМ‑ді аз физикалық хостқа орналастыруда тиімді. Бірақ апгрейдке сезімтал: сокеттер қосылды немесе кластер ұлғайды — лицензия қымбаттайды, деректер көлемі аз өзгерсе де.

Сценарий 3: ретеншн 180 күнге ұзартылды (per TB)

Per TB алғашқыда қарапайым көрінеді, бірақ ретеншн өзгермесе ғана солай. 30 күннен 180 күнге өту сақтау терезесін алты есе ұзартады. Дедупликация болғанымен де инкременттер мен тізбектер көбейеді, көлем айтарлықтай өседі.

Егер нақты баға болмағанда шешім қабылдау қажет болса, қайда қаупі жоғары екенін қараңыз:

• Per workload — ВМ, сервистер мен филиал саны өссе тәуекел жоғары.\n- Per socket — кластерді кеңейту мен апгрейдте тәуекел бар.\n- Per TB — ретеншн мен қалпына келтіру тарихы ұзарса тәуекел жоғары.

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

Модель таңдағаннан кейін оны түсінікті ережелермен бекіту маңызды. Әйтпесе бірнеше айдан кейін деректер, жаңа сайттар немесе ретеншн өзгерісі сатып алуды тұрақты қосымша төлемге айналдырады.

Қарапайым тілмен не сақталатынын, қажетті RPO/RTO‑ны, көшірмелер қанша уақыт сақталатынын және қайда орналасатынын анықтаңыз (бір сайт па, екі сайт па, бұлт па, ұзақ сақтау үшін бөлек репозиторий бар ма). Бұл параметрлер соңғы бағасына тікелей әсер етеді.

Вендордан есеп ережелерінің қысқа сипаттамасын сұраңыз: қандай объект есептеледі, қай TB есептеледі, өсу қалай қарастырылады, узелдерді, сокеттерді немесе репозиторийлерді қосқанда не болады. Жақсы белгілер — сізге ұқсас сценарийлер бойынша 2–3 есеп мысалын ұсыну.

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

Минималды бекіту жоспары:

• Болжамдарды бекітіңіз: қазіргі көлем, күтілетін өсім, ретеншн, объектілер саны.\n- Есеп ережелерін бір тест пен бір өндірістік сценарийде тексеріңіз.\n- Қай кезде қайта қарау қажет екенін триггерлерге жазыңыз (мысалы, +20% деректер немесе жаңа жүйе іске қосылса).\n- Ай сайын мониторинг пен тоқсан сайынғы қайта қарау үшін жауапты тұлғаларды белгілеңіз.

Кешенді тәсіл қажет болса, GSE.kz‑пен бірге тек бағдарламалық бөлік емес, архитектураны да талқылау пайдалы: сервер платформа, сақтау, резервтік сайттар және интеграция. Есептеу, дискілер және сақтау саясаты алдын ала келісілгенде лицензиялау масштабтауда азырақ «қиынып», жылдық жоспарлауға ыңғайлырақ болады.