FlashArray//X қысу және снапшоттардың тиімділігін бағалау

Қысу мен снапшоттардағы «тиімділікті» неден санау керек

FlashArray//X туралы айтқанда жиі бір әдемі коэффициент көрсетіледі. Практикада маңыздысы — ол нақты немен дәлелденуі керек: қазіргі сыйымдық үнемдеу ме, 3–5 жылға арналған өсімді болжау ма, әлде кеңейтулерді ескерген жалпы иемдену құны ма.

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

Синтетикалық тесттер қауіпті, себебі олар сіздің деректер құрылымын сирек қайталайды: нақты дерекқорлар, пайдаланушы профильдері, пошта, виртуалды дискілер, журналдар. Синтетика "әдемі" сандар береді, бірақ күнделікті өзгерістер, индекстерді қайта құру немесе жаппай жаңартулар кезінде снапшоттардың сыйымдылық өсімін көрсетпейді.

Сатып алудан бұрын қандай сұрақтарға жауап беру керектігін келісіп алыңыз:

• бастапқы және 12, 36 және 60 айдан кейін қанша физикалық сыйымдық қажет;\n- қысу қосылғанда және снапшоттар белсенді болғанда өнімділік қалай өзгереді;\n- қандай мақсатты RPO/RTO-ны растайсыз (снапшот жиілігі, сақтау тереңдігі, қалпына келтіру уақыты);\n- churn, клондар, тест орталар және мерзімсіз жаппай операциялар салдарынан "күтпеген" өсім қатері қандай.

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

Терминдер мен өлшем бірліктері — сөзге таласпаңыз үшін

"Тиімділік" туралы дауда көбіне сандар емес, анықтамаларға келіспеушілік шығады. Тест алдында терминдерге және қай көрсеткіштерді жазатыныңызға келісіңіз.

Логикалық сыйымдылық (logical, host) — хост көретін нәрсе: LUN/томның өлшемі және ОС бойынша жазылған деректер көлемі. Физикалық сыйымдылық (physical, array) — массивте барлық үнемдеу технологиялары мен қызметтік накладті есепке алғандағы нақты флеште алынған орын. Есептерде екі көрсеткішті қатар ұстап, әрқашан уақыт нүктесін көрсетіңіз.

Массивтегі үнемдеу әдетте бірнеше әсерден құралады және оларды бір "сиқырлы қысу" астында араластыруға болмайды:

• Thin provisioning: том 10 ТБ деп берілген болуы мүмкін, бірақ қазірге дейін 2 ТБ жазылған болса, физикалық тұрғыда шамамен 2 ТБ орын алады;\n- Дедупликация: бірдей блоктар бір рет сақталады (VDI, клондар, бірдей ОС кезінде өте айқын);\n- Қысу (compression): блоктардың мазмұнын сығып, әсері деректер түріне байланысты (мәтіндер, БД, журналдар көбіне жақсы сығылады, ал медиа, бэкаптар және шифрланған деректер — нашар);\n- Zero elimination: нөлдік блоктар дерлік орын алмайды, сондықтан "бос" файлдармен тесттер көбіне шындыққа жатпайтын коэффициенттер береді.

Снапшоттар жайлы есте сақтау керек: снапшот томды толық көшірмелей бермейді. Ол базалық нүктеге қатысты айырмашылықтар (changed blocks) қана сақтайды. Сондықтан сыйымдылық өсімін churn пен сақтау мерзімі анықтайды. Егер жазу томның бірдей аймақтарына жиі жүрсе, ескі блок нұсқалары жиналып, снапшоттар тез "қалыңдайды".

Сонымен қатар накладтік шығындар бар: метадеректер, қызметтік аймақтар, garbage collection (GC) үшін резерв және ішкі қайта құрылымдау. Кішкентай тестте олар байқалмауы мүмкін, ал жоғары толтырылған ортада маңызды болады. Методикада бастан "пайдалы" сыйымдылық пен массивтің толық физикалық тұтынуын не деп есептейтіндігіңізді айқындаңыз.

Продқа ұқсас тесттік датасетті қалай жинау керек

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

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

Практикалық "корзина" жиынтығы, әдетте реалистік микс береді:

• офис файлдары мен жалпы қалталар;\n- дерекқорлар және олардың бэкаптары;\n- VDI немесе виртуалдық машиналар имидждері;\n- суреттер және медиа;\n- журналдар және телеметрия.

Деректерді "сығымдалатындығына" қарай бөлуге болады. Минимум үш подвыборка: жақсы сығылатындар (мәтін, CSV, "қайнатылмаған" дамп), нашар сығылатындар (ішінара сығылған форматтар) және дерлік сығылмайтындар (архивтер, JPEG/MP4, шифрланған файлдар). Осылай массив қай жерде пайда әкеліп, қай жерде жоқ екенін байқайсыз және нәтижелерді араластырмайсыз.

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

Мысалы, 300 пайдаланушыдан тұратын бөлім үшін 2–3 ТБ файлдық деректер, 1 ТБ VDI имидждері және 1 ТБ дерекқор деректерін алып, содан кейін 3–5 күн типтік өзгерістерді имитациялау (күнделікті имидж жаңартулары, журналдардың өсуі, түнгі бэкап және ескі снапшоттарды сақтау саясаты бойынша өшіру) жеткілікті болады.

Тесттің көлемі мен құрылымы — цифрлар "айналмасын" үшін

FlashArray//X тесттеріндегі жиі қате — өте кішкентай немесе "стерильді" датасет. Сол кезде дедупликация мен қысу коэффициенттері өте «керемет» немесе керісінше шындыққа сай келмей көрінеді. Нәтиже тұрақты болу үшін тест жеткілікті үлкен және сіздің продқа ұқсас болуы тиіс.

Көлем: қанша дерек керек

Мақсат қарапайым: СХД-да заңдылықтар қалыптассын, ал кездейсоқтық емес. Көп жағдайда оннан бірнеше онбайт ТБ логикалық деректерді мақсат етуге болады, 1–2 ТБ емес. Минимум — қайталануды (бірдей ОС, VDI, типтік базалар) және бірегейлікті (журналдар, архивтер, медиа) айқын көрсететін көлем болуы тиіс, әрі тест бірнеше жазу/қайта жазу және деректер өшіру циклін өткені жөн.

Егер прод 200 ТБ болса, 5 ТБ тест нәтижілері көп жағдайда шуды көрсетеді. Көбіне 20–40 ТБ логикасы жақсырақ, физикалық тұрғыда үнемдеу салдарынан көлем азайғанымен.

Құрылым және churn: ішінде не болуы керек

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

Екінші ось — churn, күнделікті өзгерістер долясы. Реалистік ағымдарды жоспарлаңыз: файлдық және пошта кешендері үшін күніне шамамен 2–5% немесе VDI және белсенді журналдар үшін 10–20%. Нақтысы — дәл осы churn жиі снапшоттарды 7, 14 немесе 30 күн сақтағанда қанша орын алатынын анықтайды.

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

FlashArray//X-тегі қадамдық тест әдістемесі ("сиқырсыз")

Шынайы бағалау үшін тест алдында қандай метрикаларды қарайтыныңызға (физикалық және логикалық тұтыну, Data Reduction, снапшоттардан өсім), қандай интервалда және қандай жүктеме кезінде өлшейтініңізге келісіңіз. Әртынша бірдей сценараны әр іске қосуда жүргізіңіз.

Тест қадамдары

1. Бастапқы нүктені бекіту. Массив "таза" болуы тиіс: ескі томдар, снапшоттар және қалдық деректер болмауы тиіс. Purity нұсқасын, том параметрлерін (өлшем, thin/thick), компрессия/дедупликация саясаттарын және қызметтік резервтердің көлемін жазып алыңыз.

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

3. Типтік жұмыспен «прогрейт» жасап, өлшеніңіз. Продқа ұқсас операцияларды орындаңыз: қайталау оқулары, блоктардың бір бөлігін қайта жазу, кіші объектілерді құру/жою. Бірдей терезелерде көрсеткіштерді алыңыз (мысалы, жазғаннан кейін 2–4 сағаттан кейін).

4. Churn және снапшот кестесін қосыңыз. Өзгерістер сценарийін іске қосыңыз (мысалы, күніне 5–15%) және нақты өмірге жақын частотада снапшоттар жасаңыз (15 минут сайын, сағат сайын, күн сайын). Снапшоттармен бірге физикалық тұтынудың өсімін және белсенді қайта жазуы бар кезде өсу жылдамдығы қалай өзгеретінін жеке тіркеңіз.

5. Нәтижелерді бірдей уақыт нүктелерінде салыстырыңыз. "Ең жақсы сәтті" емес, бірдей сатыларды салыстырыңыз: жазғаннан кейін дереу, прогрейттен кейін, N сағат churn және N снапшоттан кейін. Есепте сыйымдылық пен өнімділікті қатар ұстаңыз, себебі жоғары қысу жиі кешігулермен жасырына алады.

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

Қысу мен дедупликацияны қалай өлшеу: метрикалар және өлшеу уақыты

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

Бастапқы және жазу соңындағы минималды жиынтық:

• логикалық жазылған (logical used);\n- физикалық тұтынылған (physical used);\n- Data Reduction (жалпы үнемдеу коэффициенті);\n- бөлек Dedupe Ratio және Compression Ratio (бар болса);\n- "оптимизациядан кейін" және "процесте" күйі, егер жүйе әлі фондық қайта өңдеу жүргізіп жатса.

Дедупликацияны қысудан айыру үшін екі прогон жасаңыз. Біріншісінде барынша уникалды деректерді пайдаланыңыз (қайталанатын блоктар жоққа тән): дедупликацияның үлесі минималды болады және таза қысуды көресіз. Екіншісінде әдейі қайталанатын деректер қосып (мысалы, бір VM шаблонының 10–20 көшірмесі) тек dedupe Ratio қалай өзгеретін салыстырыңыз.

Деректер түрлері бойынша салыстырыңыз. Мәтіндік журналдар мен офис құжаттары жиі жақсы қысылады, ал JPEG/MP4/ZIP дерлік қысылмайды. Дерекқорларда жағдай схемаға, жазу паттерніне және қосымша деңгейіндегі сығуға байланысты.

Өлшеу уақыты шешуші. Жазғаннан кейін дереу алынған сандарға сенбеңіз: фондық оптимизациялар жүктемені жеуін жалғастыруы мүмкін. Показательдерді дереу, 24 сағаттан кейін және тұрақты жүктеме кезінде 72 сағаттан кейін тағы қайталап алыңыз. Егер коэффициент тек түнде «жақсарып» немесе жұмыс күнінен кейін «құлап» жатса, бұл сигнал: сыйымдылық моделінде шынайы жазу режимін ескеру керек, зертханалық түсірілімге сүйенуге болмайды.

Снапшоттарды тексеру: сыйымдылық өсімі, churn және сақтау мерзімі

Снапшоттар әдетте томның толық көлемін алып қоймайды — олар тек нүктелік өзгерістерді сақтайды. Сондықтан тексеру бір сұраққа келіп тіреледі: таңдалған частота және сақтау мерзімінде сіздің churn қанша физикалық сыйымдылық қосады.

Практикалық әдіс: "1% өзгерістің құнын" өлшеу

1-2 типтік том алыңыз да, оларды тұрақты деңгейге толтырыңыз (мысалы, 60–80%). Сосын "алды/кейін" өлшеулерін жүргізіңіз:

1. Базалық снапшот (S0) жасаңыз және массивтің физикалық тұтынуын тіркеңіз.\n2) Churn-ді имитациялап, томдағы X% деректі өзгертіңіз (нақты қайта жазу маңызды).\n3) Снапшот (S1) жасап, физикалық тұтынуды қайта өлшеңіз.\n4) Циклды 5–10 рет қайталап, 1% churn-нің орташа «бағасын» ГБ-мен есептеңіз.\n5) "Жиі әрі қысқа" (мысалы, әр сағатта 48 сағат) және "сырақ әрі ұзақ" (мысалы, күн сайын 30 күн) сақтау профильдерін іске қосып, өсу қисықтарын салыстырыңыз.

Егер 1% churn кезінде физикалық өсім байқалса да, кейде жоғалатын болса — тест тым қысқа немесе деректер тым «ойыншықтық» деген сигнал.

Клондар мен тест орталар: параллель көшірмелер

Команда снапшот алып, одан 3–5 клон көтерсе не болатынын тексеріңіз. Бастапқыда клондар шамамен ештеңе тұтынбауы мүмкін, бірақ әр ортаның өзінің churn-і оларды кейін тез "кеңейтеді". Бір клон өзгермесе, екіншісі белсенді жаңартылса, үшіншісі компиляция мен артефакт жинаса — бір тәуліктен кейін әрқайсысының физикалық өсімін салыстырыңыз.

Жою және орынды қайтару

Снапшоттар мен клондарды жойғаннан кейін орын қашан босайтынын өлшеңіз. Орынды қайтару фондық процестерге байланысты бірден болмаса да кешігеді. Есептеуді бірден орны қайтаратыны ретінде емес, кешігу ретінде ескерген жөн.

Басқа есептердегі қызыл флагтер: «снапшоттар тегін» деп айтады; өсім логикалық көлемнен есептеледі; churn әдетте 1% деп алынады; клондарды снапшоттармен бірдей есептейді, олардың белсенділігі ескерілмейді; және орынның бірден қайтарылады деп уәде береді.

Нәтижелерді сыйымдылық моделіне қалай аудару — накладтік шығындарды ұмытпау

Тест нәтижесін түсінікті сыйымдылық моделіне айналдыру үшін үш деңгейді қатар ұстаңыз:

• Raw — физикалық дискілік сыйымдылық;\n- Usable — дерек қорғау және қызметтік резервтер шегерілгеннен кейінгі пайдалануға жарамды бөлініс;\n- Effective — дедупликация, қысу және снапшоттарды есептеп, шын мәнінде орналастыра алатын логикалық деректер көлемі.

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

Жай есеп схемасы (тест цифрларына не қосу керек)

Тесттен алынған measured reduction-ды (дедуп+қысу) тек сол профильге сай томдарға қолданыңыз. Содан кейін жиі ұмытылады және есепке қосылуы керек нәрселер:

• деректерді қорғау (RAID/erasure) және rebuild үшін резерв;\n- массивтің қызметтік резервы (тұрақты жұмыс, метадеректер, ішкі операциялар үшін бос орын);\n- снапшоттар мен клондар (churn мен сақтау мерзімін есепке алыңыз);\n- маусымдық және «нашар апта» үшін буфер;\n- thin provisioning-ды компрессиямен шатастырмау.

Практикалық формула: алдымен raw-тен usable есептеңіз (қорғау мен резервтерді шегеру), содан соң effective = usable * деректер коэффициенті — сақтау мерзіміне байланысты снапшоттардан күтілетін churn шығынын шегеру логикасында.

Тәуелсіз көздер бойынша тексеру

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

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

Провайдердің презентацияларындағы қызыл тулар: қайсысына назар аудару керек

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

Қандай нәрсе дереу алаңдатады

"Әрдайым 4:1" сияқты нақты коэффициент профилсіз ұсынылса — бұл тәуекел. Бірдей массив VDI, файл шаруашылығы және шифрланған базаларда әртүрлі нәтиже береді.

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

Снапшоттар: қай жерде үнемдеу көбінесе сызылады

"Снапшоттар дерлік тегін" деген сөздер тек өзгерістер аз және сақтау қысқа болғанда дұрыс. Есепте күнделікті неше дерек өзгеретіні, снапшоттар қаншалықты жиі алынатыны, оларды қанша күн сақтау керектігі және клондау бар ма — барлығы нақты моделденуі тиіс. Егер "Күнделікті 5% өзгеріс және 30 күн сақтау" сұрағына жауап жоқ болса — есеп өндірістік режимге дайын емес.

Накладтік шығындарды елемеу

Көп құжаттарда эксплуатация резервтері: тұрақты жұмыс үшін бос орын, метадеректер өсімі, ребилдке резерв және пиктік жазу ескерілмейді. Сондай-ақ коэффициенттердің уақыт өте төмендеуі мүмкін екенін айта кетпейді, себебі деректер әртектеніп, churn өседі.

Тағы бір флаг — салыстыру әртүрлі шарттарда жүргізілген басқа шешіммен. Егер шарттар теңгерілмесе, салыстыру маркетингке айналады.

Қысқа сүзгі: кіріс допущенияларын (деректер түрі, churn, retention, бақылау терезесі) және күндер бойынша шикі метрикаларды сұраңыз; егер бермесе — есеп тексерілмейді.

Цифрларға сенер алдында чеклист

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

Тест сипаттамасы қайталанатын болуы тиіс: көлем, деректер түрлері (VM-дискілер, БД, файлдық деректер), churn және ұзақтығы. Мысал формулировкасы жеткілікті: "10 ТБ виртуал дискілер, 2 ТБ SQL, churn 5%/күн, 14 күн, күнделікті снапшоттар, 7 сақтау нүктесі".

Сатып алу кезінде raw және usable, сондай-ақ physical және logical мәндер бекітілсін. Сондай-ақ "қорғау" және "накладтік шығындар" не қамтиды — RAID/erasure, spare, метадеректер, снапшоттар, репликация (бар болса) — бәрі нақты көрсетілуі тиіс.

Эффектілерді бөліңіз: актив томдарға арналған дедуп+қысуды жеке көрсетуді, ал снапшоттар мен клондарға бөлек есеп беруді сұраңыз. Жалпы "5:1" сияқты мәннің ішкі құрылымын сұраңыз — әдетте снaпшоттар үнемдеудің жартысын жеп қоюы мүмкін.

Уақытты тексеріңіз. Бір тәулік ішіндегі өлшеу көбіне эффектті асыра көрсетеді. Нормалды нәтиже — минимум 1–2 апта қайталанған өлшеу немесе эквивалентті прогон сол churn және снапшот кестесімен.

Ең маңыздысы — допущения. Есепте деректер өсімі, снапшоттардың retention-ы, орталардың саны (prod, test, dev), не клонирланатыны және қай жиілікпен — бәрі жазылуы тиіс. Егер допущениялар жоқ болса, сыйымдылық моделі тексерілмейді және оған сенуге болмайды.

Тест сценарийінің мысалы: аралас жүктеме және түсінікті қорытынды

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

Үш деректер пулын бөлек томдарда қарастырыңыз: виртуализация (VM), файлдық шаруашылық және дерекқор. Хосттардан бастапқы жазба көлемі: 30 ТБ VM (көп бірдей ОС), 20 ТБ файлдар (құжаттар, архивтер, медиа аралас), 10 ТБ дерекқор (кестелер, индекстер, журналдар). Деректер түрін алдын ала бекіткен жақсы: егер үлкен бөлігі алдын-ала сығылған форматта болса, қысудан «керемет» күту қате болады.

Реалистік churn орнату үшін "күн оқиғаларын" қосыңыз:

• VM: апта сайынғы ОС патчтары және күнделікті қосымша жаңартулар (күн сайын 1–3% өзгеріс);\n- Файлдар: күнделікті есептер мен құжат алмасу, аптада бір үлкен выгрузка (0.5–2%/күн, шыңдарда 5%);\n- Дерекқор: күнделікті жүктеулер және индекстерді қайта құру (күн сайын 2–8%, сіздің модельге байланысты).

Снапшоттарды продтағыдай орнатыңыз: мысалы, VM және дерекқор үшін сағаттық, файлдарға күнделікті; сағаттықтар 24 сағат, күндіктілер 14 күн сақталсын. Тест кем дегенде 5–7 күн жүруі керек, әйтпесе жинақталу мен сыйымдылықтың «жылдамдалуын» көре алмайсыз.

Нәтижені оқу: data reduction және снапшоттардан туындаған қосымша тұтынуды бөлек қараңыз. Егер жалпы коэффициент жоғары, бірақ тұтыну күтілгеннен тез өсіп жатса — әдетте бұл churn жоғары екенін немесе ауыр индекстер/журналдар бар екенін білдіреді. Жақсы белгі — 2–3 күннен кейін өсім графигі тұрақтанады және 2 аптаға шыққан болжам жүйені толтыру қатеріне жатқызбайды.

Провайдерден не сұрау керек: нақты метрикаларыңызға негізделген сыйымдылық моделін қайта есептеу (VM, файлдар, дерекқор бойынша бөлек), сіздің снапшот кестеңіз және нақты churn пайыздарыңызбен, және екі сценарий — "қалыпты" және "шықтық" (патчинг, есептер кезеңі, жаппай выгрузка).

Келесі қадамдар: PoC қалай ұйымдастыру және нәтижені бекіту

PoC тек кіріс шарттар продқа жақын болғанда мәні бар. Екі нәрсені бекітіп бастаңыз: деректер құрамы (қандай файл түрлері, қандай БД, алдын-ала сығылған форматтардың үлесі) және снапшот кестесі (жиілік, retention, клондар саны, қалпына келтіру сынақтары). Бұл сіздің "реалдылық келісімшартыңыз" болады.

Бастамас бұрын PoC нәтижесі жай слайд емес, нақты нәтиже болатынын келісіңіз. Ыңғайлысы — есеп құрылымы мен бастапқы өлшеулер форматын алдын ала бекіту.

PoC үшін минималды келісімдер пакеті

Бір бетке бекітіңіз:

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

Егер сіздің ортаңыз VDI мен файлдардан тұратын болса, тестке пайдаланушылардың бір апталық «өмірі» мен 2–3 бақылау қалпына келтіруді қосыңыз. Сонда снапшоттар бойынша алынған цифрлар статикалық көшіруден әлдеқайда шынайы болады.

Нәтижені бекіту және бір айдан кейін жойып алмау

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

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