Дискілерді шифрлеуді сынақтан өткізу жоспары: BitLocker және LUKS СУБД‑те

Тесттің міндеті: қандай цифрлар қажет

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

• оқу және жазу IOPS қалай өзгереді;
• латенттіктер (латенттік), әсіресе p95 және p99 қалай өседі;
• шифрлеу қанша қосымша CPU алады.

Әдістеме болмаса нәтижелер салыстыруға келмейді. Бүгін сіз орташа латентті қарайсыз, ертең — 95-ші перцентиль. Бір іске қосуда кэш қосылған, екіншісінде жоқ. Бір күні серверде фондық тапсырмалар бар, екіншісінде «таза». Соңында цифрлар BitLocker немесе LUKS-тен нақты не өзгергенін емес, шуды көрсетеді.

Бастап-ақ келісіп қойыңыз: сіздің СУБД және SLA үшін қандай деградация қабылданады. OLTP үшін көбіне IOPS емес, «хвосттар» маңызды: оқу p95 5-тен 8 мс-қа өсуі IOPS-тың -10% болуынан маңыздырақ болуы мүмкін. Есептік жүктемелерде түнгі терезеге сыйса — кейде -15% өткізу қабілеті де қабылданады.

Ыңғайлы әдіс — «ауру шегі» мен шешім форматын алдын ала бекіту. Мысалы:

• IOPS: оқу және жазуда X%-дан артық төмендеме болмауы тиіс;
• Латенттілік: p95 және p99 Y мс (немесе Y%)-тан артық өспеуі тиіс;
• CPU: орташа жүктеме және CPU steal/ready Z%-дан артық өспеуі тиіс;
• Тұрақтылық: ұзақ прогон соңында «пила», құлдырау немесе деградация болмауы.

Тест нәтижесінде шешім жиі «қосу/қоспау» сияқты қарапайым болмайды. Көбінесе нәтиже: шифрлеуді қосамыз, бірақ жылдам NVMe-ге ауысамыз, CPU ядроларын қосамыз, шифрлау режимін өзгертеміз, журналды бөлек томға шығарамыз немесе СУБД лимиттерін қарастырамыз. Маңыздысы — әр әрекет өлшенген IOPS, латенттіктер мен CPU-ға негізделуі керек, сезімге емес.

Тестке дейін не жазып алу керек: аппарат, ОС және СУБД параметрлері

BitLocker пен LUKS-ты әділ салыстыру үшін бастапқы шарттарды жазып алыңыз. Бұл қадам жиі тесттің тағдырын шешеді. Драйвер, контроллер кэші немесе flush-параметр өзгерсе, цифрлар «секіріп» кетеді және салыстыру мәнсіз болады.

Бастап аппараттан бастаңыз. Есепте сервердің «паспортын» көрсетіңіз: модель, CPU (ұрпақ, жиілік), RAM көлемі, диск-конфигурация және контроллер. Жоғарыда шифрлеу қай деңгейде екенін де айтыңыз: ОС деңгейінде RAID үстінде ме, SAN-дағы бөлек LUN ба, әлде әр жергілікті диск пе.

Төмендегі нені жазып, прогона арасында өзгертпеу керек:

• CPU: модель, ядро/ағын саны, Turbo және үнемдеу режимдері қосылған ба;
• RAM: жалпы көлем және жүктеме демалыс күйінде (жүктеме басталардан бұрын);
• Жинақтау: NVMe/SATA SSD/SAN, RAID/HBA, кэш және жазу саясаты;
• Сақтау жолы (егер SAN болса): өткізу қабілеті, multipath, латенттіктер;
• Температура және троттлинг: қуат немесе салқындатуда шектеулер бар ма.

Одан әрі ОС-ты жазыңыз: Windows нұсқасы немесе Linux дистрибутиві, ядро нұсқасы, накопитель драйверлері мен контроллер драйверлері, патчтар. Жазуды әсер ететін параметрлер: кэш саясаты, Linux-та scheduler/queue depth, Windows-та Storport және драйвер параметрлері.

СУБД бойынша нұсқасын және маңызды параметрлерді жазыңыз: буфер/кэш көлемі, журнал моделі, flush параметрлері (fsync/flush), чекпоинт жиілігі, сондай-ақ деректер көлемі (жалпы көлем, жұмыс жиынтығы және «ыстық» кестелер/индекстер үлесі).

Мысал: егер сіз стендтік GSE S200 Series серверінде локальды NVMe-ді тексеріп жатсаңыз, контроллер кэшінің қосылғанын және СУБД буферінің RAM көлемімен сәйкес екенін нақты көрсетіңіз. Әйтпесе бір прогон «RAM-тесті», ал екіншісі — диск тесті болып шығып, шифрлеуді салыстыру қате болады.

Метрикалар: IOPS, латенттіктер мен CPU-ны шатастырмай қалай бағалау

Тесті нақты цифр берсін десеңіз, метрикаларды және оларды қалай есептейтіндікті алдын ала келісіңіз. Әйтпесе жеңіл-желпі «жақсарған» көрініс шығады, себебі бір прогонда орташа қаралды, екіншісінде — шыңдар.

Не жазып алу керек

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

Кемінде келесілерді жазыңыз:

• Оқу және жазу бойынша IOPS (мүмкін болса — кездейсоқ және тізбекті бөлек);
• Латенттіктер: орташа және перцентильдер p95 және p99. Перцентильдер орташаға қарағанда жиі маңызды, өйткені дәл «хвосттар» СУБД-те тежелістер тудырады;
• Өткізу қабілеті (MB/s) оқу және жазу бойынша бөлек. Бұл IOPS төмендегенде де өсу мүмкін, сондықтан оларды араластыруға болмайды;
• CPU: жалпы жүктеме, сондай-ақ user және system. Қуатты бөлу үшін прерыванияларды (interrupts) бөлек қарау пайдалы, себебі шифрлеу мен I/O көбінесе оларды ұлғайтады;
• I/O-ға ұрыну белгілері: кезек ұзындығы және iowait/диск күтуі.

Әділ салыстыру қалай жүргізіледі

Бірдей жүктемені бірдей жағдайларда салыстырыңыз. Шифрлеу орташа жауапты аз өзгертсе де p99-ды айтарлықтай нашарлатуы мүмкін. Бұл СУБД үшін транзакциялардың «жабысып қалуын» және жауап уақытында секірістерді тудырады.

Нәтиже тұрақты болу үшін:

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

BitLocker немесе LUKS қосылғаннан кейін IOPS шамамен өзгермесе, бірақ p99 пен system CPU өссе — жүйе шифрлеуге емес, болжамдылық пен процессор уақытына «төлем» төлеп тұрғаны болады.

Эксперимент дизайны: тест матрицасы және салыстыру ережелері

Дизайн мақсаты өте қарапайым: шифрлеу ғана өзгере алатындай үш режимді салыстыру. Бірдей аппарат, бірдей ОС және СУБД параметрлері, бірдей жүктемелер және бірдей есептеу ережелері.

Тура үш конфигурацияны салыстырыңыз: шифрланбаған, BitLocker, LUKS (dm-crypt). Үш режимде де өндірісте қолдануды жоспарлаған шифр мен параметрлерді (мысалы, XTS-AES) қолданыңыз және оларды хаттамаға жазыңыз.

Жүктеме матрицасы

IOPS пен латенттіктер картасын көру үшін шектеулі, бірақ көрсеткіштер беретін тесттер жеткілікті. Логика: қатынасу түрі (кездейсоқ/тізбекті) x операция түрі (оқу/жазу) x блок өлшемі.

Реалистік минимум:

• Кездейсоқ 4K оқу және жазу (OLTP үшін типтік);
• Кездейсоқ 8K немесе 16K (деректерге көбірек сәйкес келеді);
• Тізбекті 128K оқу және жазу (бэкаптар, сканерлеулер);
• Аралас профиль 70/30 немесе 80/20 (сыйымдылықты көру үшін).

Егер СУБД-де деректер мен журнал бөлек томдарда болса — оларды жеке тесттеңіз. Журнал үшін тізбекті жазу мен p95/p99 маңызды; деректер үшін — кездейсоқ операциялар мен тұрақтылық.

Прогон тәртібі және қарапайым статистика

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

Практикалық ереже:

• 1 прогревтік іске қосу, содан кейін 5 өлшенетін;
• Метрика бойынша қорытынды медиана бойынша алынады, орташа емес;
• Шығарылымдарды тек нақты себеппен ғана алып тастаңыз (мысалы, жаңарту іске қосылды) және оны тіркеңіз;
• Көрнекілік үшін диапазон (min-max немесе p25-p75) қосыңыз.

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

Қоршаған ортаны дайындау: тест әділ әрі қайталанатын болу үшін

Дайындаудың мәні — «шифрланбаған» пен «шифрленген» режимдерді салыстыру, кэш, фондық тапсырмалар немесе SSD троттлинг сияқты кездейсоқ факторларды емес. Қоршаған ортаны бір күйге келтіріп, параметрлерді бекітіңіз.

Дискілер мен файлдық жүйе

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

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

Кэш пен фондық процесстер

Алдын ала шешіңіз: «суық кэш» (қайта жүктегеннен кейін) ме, әлде «ысыған кэш» (сағаттық жүктемеден кейін) ме тест жасайсыз. Екі режимді де жүргізіп, араластырмаңыз.

Шуды азайту үшін тест кезінде фондық әрекеттерді тоқтатыңыз: жаңартулар, жоспарлы тапсырмалар, антивирустық/EDR сканерлеулері, бэкаптар, снапшоттар, индекстеу, ауыр мониторинг сұраулары, миграциялар/репликациялар және СУБД-нің автотюнингі.

Температураға бөлек назар аударыңыз: NVMe мен CPU троттлингке түсіп қалуы мүмкін, сонда «шифрлеуден соң төмендеу» көрінісі жалған болады. Прогона арасында жүйені суытыңыз және температура мен жиіліктерді тіркеңіз.

Қайталанушылық үшін артефакттарды сақтаңыз: BitLocker/LUKS конфигурациясы (режим, алгоритм), шифрлеу күйі, ОС логтары (Event Log/journal), шикі тест нәтижелері және жүйелік счетчиктер (мысалы, PerfMon немесе iostat). Бұл қорғаныс және сатып алу алдында нәтижелерді дәлелдеу үшін маңызды.

Қадам бойынша: шифрланбаған базалық прогон

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

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

Демалыста тексеріңіз:

• CPU орташа жүктемесі және шыңдары (мысалы, 10–15 минут ішінде);
• диск белсенділігі: IOPS, латенттіктер, кезек ұзындығы;
• дискке жазатын фондық процестер;
• температура мен CPU жиіліктері;
• бос орын және томның толығу деңгейі.

Содан кейін екі тип прогон жасаңыз.

Біріншісі — синтетикалық I/O, барлық режимдер үшін бірдей параметрлер: блок өлшемі, оқу/жазу қатынасы, кезек тереңдігі, ағындар саны, мерзім. Мақсат — рекорд емес, қайталанатын нәтиже. p95/p99-ды міндетті түрде алыңыз.

Екіншісі — «СУБД-ге ұқсас» сценарий. Қысқа транзакциялар және жиі commit-тер, журналға көп шағын синхронды жазбалар мен оқулар. Егер база бар болса, типтік профильді қолданыңыз: 20–30 минут жүктеме, 5 минут үзіліс, қайталау.

Әр прогонынан кейін кем дегенде: жүктеме параметрлері мен басталу уақытын, CPU мен диск логтарын, диск/контроллер параметрлерін, FS және СУБД I/O әсер ететін параметрлерін сақтаңыз.

Әр тестті кемінде 3 рет қайталаңыз және baseline үшін медиананы алыңыз. Егер қайталamalar арасында шашу 5–10%-тан жоғары болса — алдымен себебін тауып жойыңыз, содан кейін ғана шифрлеуді қарастырыңыз.

Қадам бойынша: BitLocker-пен прогон

Бұл прогоның мақсаты — BitLocker қосып, жалғыз жаңа фактор ретінде шифрлеуді алу. Басқа барлық нәрсе (OS нұсқасы, драйверлер, қуат саясаты, СУБД параметрлері, деректер көлемі, жүктемелер) baseline-пен дәл бірдей болуы керек.

BitLocker баптауы (не жазып алу керек)

Қосу алдында келесі параметрлерді жазыңыз: шифрлеу режимі (мысалы, XTS-AES), кілт ұзындығы (128 немесе 256) және CPU-дағы аппараттық AES-тің болуы (әдетте AES-NI). Егер серверде SED (self-encrypting drive) бар болса, программалық BitLocker-пен аппараттық шифрлеуді араластырмайтыныңызды атап өтіңіз.

Кілт және ашу схемасын тестке бейтарап етіңіз: том өлшеулер басталардан бұрын ашық болуы тиіс. Қолмен пароль енгізуді немесе әкімші қатысуын талап ететін әрекеттерді тест сценарийіне қоспаңыз.

Шифрленгенін тексеріңіз

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

manage-bde -status
Get-BitLockerVolume | Select MountPoint, VolumeStatus, EncryptionMethod, EncryptionPercentage

EncryptionPercentage 100% болғанша күтіңіз. Содан кейін серверді бір рет бақылаулы түрде қайта іске қосып, том автоматты түрде ашылатынына көз жеткізіп, тек содан кейін тесттерді бастаңыз.

Содан кейін baseline-ды дәл қайталаңыз:

• бірдей синтетикалық тесттер;
• бірдей «СУБД-подобные» прогоны сол тәртіппен және ұзақтықпен;
• сол метрикалар, соның ішінде p95/p99;
• параллель CPU жинау (жалпы және ядро бойынша) және жүйелік I/O күтулер.

Егер IOPS ұқсас, бірақ p99 өссе — СУБД үшін бұл орташа мәннен гөрі маңызды сигнал болуы мүмкін.

Қадам бойынша: LUKS (dm-crypt)пен прогон

Мақсат — baseline-ды қайталау, бірақ тек шифрлеу қабатын өзгерту. Бұл жағдайда нәтижелерге сенуге болады.

Алдымен LUKS/dm-crypt қалай орнатылғанын нақты жазыңыз. Бұл есепте «шифрленді» деп жазудан гөрі маңызды.

Жазыңыз:

• ОС, ядро және cryptsetup нұсқалары;
• Параметрлер: LUKS1/LUKS2, шифр (мысалы, aes-xts-plain64), кілт ұзындығы (XTS үшін жиі 512), сектор өлшемі (512 немесе 4096);
• LUKS-тың стек ішіндегі орны: RAID → LUKS → LVM немесе LUKS → LVM → FS. Бір нұсқаны таңдап, өзгертпеңіз;
• Өнімділікке әсер ететін опциялар (мысалы, allow-discards) тек егер олар саналы түрде қажет болса және барлық режимдерде бірдей қолданылса ғана қосыңыз.

Аппараттық AES бар-жоғын тексеріңіз. Linux-та lscpu немесе /proc/cpuinfo арқылы aes флагын көруге болады. Қосымша ретінде cryptsetup benchmark жүргізіп, нәтижелерді сақтаңыз.

Томды baseline-пен дәл сол RAID, сол диск және сол файлдық жүйемен құрыңыз. Тек dm-crypt қабаты өзгереді.

Сосын сол тесттерді қайталаңыз: IOPS, латенттіктер (орташа, p95/p99), CPU жүктемесі (жалпы және ядро бойынша), кезек ұзындығы және I/O күтулері.

Интерпретация үшін үш қарапайым сигналды есте сақтаңыз:

• IOPS төмендейді, CPU өседі: шифрлеуде шекке тірелген болуы мүмкін;
• CPU айтарлықтай өзгермейді, бірақ латенттіктер мен кезек өседі: сақтау/контроллер шегінде болуы ықтимал;
• Орташа метрикалар ұқсас, бірақ p99 өседі: фондық процестерді, writeback пен кезек параметрлерін тексеріңіз.

Осылайша LUKS-тің СУБД серверіне әсері қай жерде көрінетінін анықтауға болады, мысалы GSE S200 Series негізіндегі хосттарда.

СУБД-ге ұқсас жүктемелер: синтетикадан басқа не тесттеу керек

Синтетика (мысалы, 4K random) пайдалы, бірақ нақты базаның мінезін көрсетпейді: аралас операциялар, шарықтау, фондық тапсырмалар. Сондықтан СУБД-ге ұқсас прогоны қосыңыз.

Үш профиль, жиі жағдайды өзгертетін

Үшеу жеткілікті. Барлық жағдайда синтетикадағыдай метрикаларды тіркеңіз: орташа латентті, p95/p99, IOPS/MB/s, CPU (user/system) және I/O күту.

• OLTP: көп шағын операциялар және жиі commit-тер. Мұнда «хвосттар» шешеді.
• Аналитика: ұзын оқу және сканерлер. Көбіне өткізу қабілеті төмендеуі мен CPU өсуі көрінеді.
• Қызмет көрсету: бэкап/қалпына келтіру, индексті қайта құру, vacuum/checkpoint тәрізді жұмыстар. Оларды әдетте түнде іске қосады және олар CPU немесе I/O-ны «жеп» жіберуі мүмкін.

Практикалық нұсқа — СУБД-ңізге стандартты бенчмаркті (мысалы, PostgreSQL үшін pgbench) алып, нақты сұраулардан тұратын қарапайым сценарий қосу.

Деректер мен журналды бөлек тесттеңіз

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

Типтік жағдайда журнал томы жазу p99-ының 2 мс-ден 6 мс-ге өсуін көрсетуі мүмкін — бұл OLTP-де TPS-тің айтарлықтай төмендеуіне әкелуі мүмкін, тіпті жалпы IOPS жақсарғандай көрінсе де.

Прогон ұзақтығы: 1–2 минут жеткіліксіз

Қысқа тесттер кэш жылдамдығын ғана көрсетеді. Практикалық ереже:

• 5–10 минут прогрев, нәтижелерді есепке алмау;
• 20–40 минут тұрақты режимде өлшеу;
• әр сценарий үшін кемінде 3 қайталау және медиана бойынша салыстыру.

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

Мысал сценарий: өлшеулерді бизнес шешіміне қалай айналдыру

Мысалы: серверде күндіз 300–500 белсенді қолданушы бар, түнде бэкаптар жүреді. Сұраныс — диск шифрлеуді қосу, SLA бұзбау және пик уақытында сұраныс кезегінің пайда болмауын қамтамасыз ету.

Төменде бірдей жүктемелер мен метрикалар бойынша мысал кесте көрсетілген.

Одан әрі бұл бизнеске түсінікті шешімге айналады. Мысалы: жазба p95 0,8–1,1 мс-ға өсті, CPU шыңдары 13–17 пайызға артты. Егер SLA-ңыз сезімтал операциялар үшін 5 мс-тан төмен болса, BitLocker әлі де қауіпсіз шекте болса, LUKS түнгі бэкап кезінде шекараға жақындайды.

Басқармаға ыңғайлы етіп ұсыныстарды былай құрыңыз:

• SLA бойынша p95/p99-ға сай келетін режимді таңдаймыз;
• CPU-ға «ұрып қалса» қосымша ядролар (+2–4) немесе ауыр тапсырмаларды басқа серверге ауыстыру қажет;
• Егер диск латенттігі шектесе — жылдамырақ SSD/массив немесе деректер мен журналды бөлу қарастырылады;
• Қайсы шығындарды (CPU, дискілер) қабылдайтынымызды және қандай тәуекелді (мәліметтердің ұрлануы/жоғалуы) азайтатынымызды бекітеміз.

Қате жиі кездесетін себептер — неге сандарға сенуге болмайды

Шифрлеу тестінің басты қатері — сіз BitLocker немесе LUKS емес, параметрлер арасындағы айырмашылықтарды өлшеп жатасыз. Сол кезде дәл жоспар да дау-дамайға ұласады: «кім не сезінді», метрикалар емес.

Аппарат пен сақтау салыстыруындағы қаталар

Ең көп кездесетіні — әртүрлі RAID және кэш режимдерін салыстыру. Мысалы, baseline-да контроллерде write-back қосылған, ал шифрлеу кезінде қауіпсіздік саясатына байланысты write-through қойылған. Графиктерде бұл «шифрлеу IOPS-ты өлтірді» сияқты көрінеді, бірақ шынын айту керек — кэш саясаты кінәлі.

Сондай-ақ драйверлер, фримвар, қуат саясаты немесе CPU governor-дың прогонын аралығында өзгеруі нәтижелерге үлкен әсер етуі мүмкін.

Жүктеме методикасындағы қателер

СУБД кэштің артында проблемаларды жасыруы мүмкін. Бір прогон «суық» буфер кэшінде, екіншісі «ысыған» кэштен жасалса — орташа латентті өте түрлі болады. Сондай-ақ фондық чекпоинттер, автотыңдырғыштар, файл өсуі мен индекстің қайта құрылуы шу қосады.

Көбінесе журнал профилін ұмытып кетеді. База үшін маңыздысы — жазуды жылдам растау (fsync/flush). Егер сіз тек үлкен тізбекті жазуларды fsyncсіз тесттесеңіз — ең сезімтал бөліксіз қаласыз.

Қысқа тізім — цифрларды сенімсіз ететін ең жиі нәрселер:

• түрлі кэш/RAID саясаттары немесе ОС деңгейіндегі кэш деңгейінің айырмашылығы;
• «суық» пен «ысыған» кэштi араластыру;
• тек орташа латенттікті бағалау, p95/p99-сыз;
• журнал үшін fsync/flush-пен бөлек тесттің болмауы;
• бірден бірнеше параметрді өзгерту, сосын себепті анықтау мүмкін болмауы.

Практикалық мысал: команда LUKS қосып, p95 екі есеге өсіп кетті деп ойлап, шифрлеуді кінәлайды. Кейін белгілі болды: сол прогон кезінде CPU-да агрессивті үнемдеу қосылған болған. Егер факторларды бір-бірлеп өзгертіп, перцентильдерді тіркесе — дау тез аяқталар еді.

Чек-лист, есеп және тесттен кейінгі қадамдар

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

Бастамас бұрын:

• Конфигурацияны бекітіңіз: CPU, RAM, диск/RAID, ОС нұсқасы, СУБД нұсқасы, шифрлеу параметрлері (BitLocker немесе LUKS, режим, сектор өлшемі).
• CPU жиіліктері, NUMA режимдері және қуат жоспарлағышты тексеріңіз.
• I/O жасайтын фондық тапсырмаларды өшіріңіз және стендте тыныштық келісіңіз.
• Кэштерді қалай есепке алатыныңызды анықтаңыз: ОС, контроллер, СУБД.
• Прогон критериясын белгілеңіз: прогрев қанша минут, өлшеу қанша минут, қайталанулар саны.

Әр прогон кезінде:

• Жүктеме параметрлерін (блок өлшемі, оқу/жазу қатынасы, кездейсоқ/тізбекті, кезек тереңдігі, ағындар саны) нақты жазыңыз;
• Кэш күйін тіркеңіз (қайта жүктелгеннен кейін ме әлде прогретен кейін ме) және салыстыру үшін бірдей күй болуын қадағалаңыз;
• IOPS, орташа және p95/p99 латенттіктері, CPU (user/system/iowait) және I/O күтуін алыңыз;
• Температураларды, троттлингті және ОС/СУБД логтарындағы ескертулерді белгілеңіз.

Есепті бір файлда ұстаған ыңғайлы: режимдер бойынша нәтиже кестесі, p99 графиктері мен CPU, кэштiң және параметрлер тізімі, тәуекелдер және қорытынды «не жоғалтып, не аламыз».

Келесі қадам — пилот: бастап стендте, содан кейін шифрлеуді бір бөлікке (мысалы, репликалар немесе жеке базалар) қосып, сандардың қайталануын тексеріңіз. Егер CPU немесе латентті «хвосттар» шекке тірелсе — сервер конфигурациясын талқылап, енгізу жоспарын даярлаңыз. Мұндай жобаларда көп жағдайда интеграторлар көмектеседі — аппарат пен СУБД тәжірибесі бар, мысалы, GSE.kz (GSE) сияқты өндірушілер мен жүйелік интеграторлар.