HPE Alletra 6000 all-flash СХД: ұсыныстарды цифр бойынша қалай салыстыруға болады

Міндет: коммерциялық ұсыныстарды әдемі сандарға емес, фактілерге сүйеніп салыстыру

Сіз бірдей all-flash СХД (мысалы, HPE Alletra 6000) үшін бірнеше коммерциялық ұсыныс сұраған кезде «бетті-бетке» салыстыру жиі сәтсіздікке ұшырайды. Бір жеткізуші «миллиондаған IOPS» деп жазады, екіншісі «міндетті төмен кешігу» уәде етеді, үшіншісі «4:1 үнем» деп ерекшеленеді. Бірақ осы цифрлардың артында түрлі допущения тұрады: блок өлшемі, жүктеме түрі, шкафтардың құрамы, снапшоттар мен репликация қосылған ба, SSD түрі, контроллерлер саны, желі.

Мәселе цифрдың «жалғандығында» емес — олар көбіне сіздің негізгі сауалыңызға жауап бермейді: нақты эксплуатацияда сервис қалай жұмыс істейді. Қысқа тесттегі «пик IOPS» тәулігіне 24/7 тұрақты жұмысқа тең емес. «0,2 мс кешігу» шарттарсыз (кезектер, оқу/жазу қатынасы, пулдың толтырылуы, қосылған функциялар) шамалы ақпарат береді. «Тиімді сыйымдылық» көбіне оптимистік деректер профиліне негізделеді, өсу мен шығындарды ескерілмей қалуы мүмкін.

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

КП-ларды салыстыру алдында ойын ережесін бекітіңіз. Көбіне жеткілікті болып табылады:

• жұмыс кешігуін (орташа және p95/p99) бекіту, тек «минимум» емес;
• тұрақты режимдегі өнімділік (ондаған минуттар және сағаттар), burst емес;
• I/O профилі: оқу/жазудың үлесі, блок өлшемі, кездейсоқ/үздіксіз қатынау;
• шарттар: пулдың толтырылу пайызы, қосылған функциялар (снапшоттар, репликация, шифрлау);
• қатесіздік критерийлері және қалпына келтіру уақыты.

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

Сіз нені сатып аласыз: short про all-flash класы және Alletra 6000

All-flash СХД — деректер SSD-ларда сақталатын жүйе, жұмыс пулында «баяу» HDD жоқ. Түсінікті мысал — бағдаршамсыз жол: кешігу аз, жауап тұрақты, шыңдармен күресу жеңілірек. Гибридті жүйелерде кей деректер HDD-ға кетеді және шынайы өмірде сіз жиі «пик IOPS»-пен емес, кешігулер мен тұрып қалулармен ұшырасыз.

HPE Alletra 6000 all-flash класы әдетте жауап тұрақтылығы маңызды болған жерлерге қарайды: виртуализация (VMware/Hyper-V), деректер базалары, бизнес жүйелері (ERP/CRM), көп шағын операциялары бар критикалы сервис. Егер сервис кешігулерге сезімтал болса (мысалы, база + қосымша + көп қолданушы), all-flash жиі кэшпен ойнауды азайтып, айқын нәтиже береді.

КП-ны дұрыс салыстыру үшін сатып алуға дискілерден басқа не кіретінін бірден бекіту пайдалы. Типтік конфигурацияда маңызды:

• контроллерлер мен қатесіздік схемасы (екі контроллерлі, ауыстыру/шолып өту варианттары);
• желі порттары мен қосылу түрі (Ethernet немесе Fibre Channel), контроллердегі порттар саны мен жылдамдығы;
• дерек функциялары жиынтығы: снапшоттар, репликация, шифрлау, QoS, гипервизормен интеграция;
• лицензиялау: базада не кіреді, не қосымша ақыға түсетінін;
• мониторинг: кешігу мен жүктемені қалай өлшейтіні, SLA-ны растауға жарайтын есептер бар ма.

Бастапқыда анықтау қажет үш шектеу бар:

Біріншісі — протоколдар: хосттарыңызға қандай қажет (FC, iSCSI, NFS/SMB, NVMe-oF) және таңдалған конфигурацияда не қолдау табатынын анықтаңыз.

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

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

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

Өнімділік метрикалары: нақты салыстыруға болатын көрсеткіштер

All-flash СХД бойынша КП-де жиі әсерлі сандар көрсетіледі. Критикалы сервис үшін рекордтар емес, жүйенің болжамдылығы және жұмыс істейтін шекаралар маңызды.

IOPS (операциялар в секунду) — кішкентай блоктардағы жүктеме үшін пайдалы (көбінесе деректер базалары). Бірақ IOPS контекстсіз көп дерек бермейді: бір жүйе 4K және 64K блокта, 70% оқу мен 50% жазуда, әртүрлі кезек тереңдігінде өзгеше көрсеткіш береді. IOPS‑ті тек бірдей жүктеме профилінде салыстыруға болады.

Кешігү (latency) — қосымшалар мен қолданушылар үшін негізгі көрсеткіш. Орташа ғана емес, p95 және p99 көрсеткіштерін сұраңыз. Орташа оң көрінуі мүмкін, ал минут сайын болатын «пауза» транзакция қатарына және «тоқтап қалуларға» әкелуі мүмкін. Сондықтан сирек шыңдар маңызды.

Өткізу қабілеті (GB/s) — деректер ағынымен жұмыс істегенде маңызды: резервтік көшіру, аналитика, VDI, файл сервистер. Мұнда да тест шарттары міндетті: блок өлшемі, жазу үлесі, ағындар саны.

Арнайы бағалаңыз — жүктеме артқанда жүйенің тұрақтылығы. Жақсы СХД кешігуін тар шектерде ұстайды, ал шектен өткенде «құламауы» керек. Alletra 6000 және кез келген бәсекелестің жағдайында цифрларды шарттар тең болғанда жан-жақты салыстыруды талап етіңіз.

Әділ салыстыру үшін КП-ларда келесі шарттар сәйкестенуі қажет:

• жүктеме профилі (блок мөлшері, % оқу/жазу, кезек тереңдігі);
• кешігудің p95 (жақсы p99) және өлшеу шарттары;
• сол профилдегі IOPS пен GB/s;
• тест ұзақтығы және прогрев («алғашқы 30 секунд» емес);
• киімнің құрамы (контроллерлер, дискілер, желі, протокол).

Жай мысал: екі КП 200k IOPS көрсетеді. Бірінде p99 кешігу 1,2 мс, екіншісінде 8 мс сол жазу 30% үшін. Қағазда IOPS бірдей, ал екінші жағдайда база мен қолданба ұзақ тұрып қалулар береді.

КП-дегі «кепілдендірілген өнімділік»-ті қалай тексеруге болады

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

КП-да бірінші болуы тиіс нәрсе — IOPS және кешігу алынған жүктеме профилі. Бұл болмаса салыстыру мағынасыз: 200 000 IOPS 4K және 70/30 read/write үшін алынғаны 8K және 50/50 үшін алынғанымен бірдей емес. «Үздіксіз оқу» әдетте «кездейсоқ жазудан» жақсы көрінеді.

Одан кейін көрсетілген сандар қандай шартта алынғанын нақтылаңыз. Өнімділік әдетте төмендейді, егер жүйе толтырылған, қорғаныс қосылған және өндірістік қатесіздік схемасы жұмыс істесе. Бір ұсыныста сандар бос жүйе мен шығындарсыз берілсе, ал екіншісінде — 70–80% толтыруда және қорғаныс қосылғанда, онда сіз әртүрлі режимдерді салыстырдыңыз.

КП-ға міндетті енгізуді талап етуге болатын тексеру пункттері (барлық жеткізушілер үшін бірдей):

• Профиль: блок өлшемі, read/write, кездейсоқ немесе үздіксіз жүктеме.
• Шарттар: пул толтырылған пайызы, қосылған дерек қорғау, RAID/erasure coding схемасы.
• Кешігу шегі: latency бойынша уәде бар ма (мысалы, X мс-тан аспайды) немесе тек IOPS пе.
• Бірліктер және конфигурация: көрсеткіштер нақты контроллерлер, SSD саны және желімен байланысқан конфигурацияға тәуелді.

Мини-сценарий: екі КП бір модельге бірдей IOPS береді. Біреуінде кешігу «орташа» деп көрсетілген және 20% толтыруда, екіншісінде latency шегі 80% толтыруда және қорғаныс қосылғанда жазылған. Критикалы сервис үшін екінші нұсқа өндірістік ортаға жақынырақ болғандықтан құндырақ.

Жеткізушінің жүктеме профилі мен шарттарды КП-да жазып қоюға дайын болуы жақсы белгі — бұл көбіне кез келген «пиктерден» маңызды.

Компрессия және дедупликация: «4:1»-ден иллюзиясыз қалай салыстыру керек

«4:1» деген сан көбіне мінсіз жағдайға қатысты. КП‑да «сырая сыйымдылық» (SSD физикалық көлемі) мен «тиімді сыйымдылық» (деректерді үнемдеп қанша орын болатыны) арасын ажырату маңызды. «Тиімді ТБ»-ларды жеткізушілер арасында салыстыру тек бірдей допущениялар болғанда ғана мүмкін.

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

Қандай допущения көрсетілуі тиіс

Жеткізуші уәде еткен үнемділік қандай деректерде алынғанын қысқаша сипаттасын: әдетте жеткілікті:

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

Alletra 6000-ті альтернативалармен салыстырғанда бір формат сұрату ыңғайлы: «сырая сыйымдылық → шығындар → тапсырыс берушінің деректеріндегі күтілетін үнемдеу». Сол арқылы нақты есеп пен жарнамалық формуланың шекарасын көруге болады.

Өнімділік әдемі коэффициенттен маңыздырақ

Компрессия «тегін» болмайды. КП‑да үнемдеу қосылған кездегі кешігу және IOPS/өткізу қабілеті көрсетілуі керек, тек «таза» режим емес. Критикалы сервис үшін p95/p99 маңызды — орташа көрсеткіш емес.

Сонымен қатар резервтерді ұмытпаңыз: RAID/erasure coding резерві, метадеректер, жүйелік қажеттіліктер, ақаудан кейінгі қайта құру үшін сақталған орын. Мысалы, виртуализацияға 200 VM үшін 4:1 үміт етілсе де, нақты деректер бірегей болса, компрессия 1.5:1 береді. Егер қайта құру резерві мен снапшоттар ескерілмесе, пайдалы сыйымдылық жоспарланғаннан аз болады және сіз SSD емес, критикалы сервис тоқтау қаупіне тап боласыз.

Қолдау саясаты мен SLA: КП-да не жазылуы тиіс

Критикалы сервис үшін қолдау көбіне IOPS айырмашылығынан маңыздырақ. КП‑да «премиум сервис» емес, нақты өлшенетін міндеттемелер болуын сұраңыз.

SLA тексерілетін болуы керек. Осыған минимальды жиынтықты талап еткен жөн:

• қолдау режимі: 8x5 немесе 24x7, «жұмыс уақыты» қалай анықталатыны;
• жауап беру уақыты және қалпына келтіру уақыты: критикалық және критикалық емес оқиғалар үшін бөлек;
• келу және ауыстыру: инженердің келу уақыты, компонентті ауыстыру мерзімі, advance replacement шарттары;
• ПО жаңартулары: патчтар пен апдейттер кіре ме, кім орындайды, қызмет көрсету терезелері және қайтару мүмкіндігі бар ма;
• запас бөлшектер: қайда қойма, сіздің қалаға қалай жеткізеді, дефицит немесе логистика кешігу жағдайында не болады.

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

КП‑ның бөлек бөлімі — өмірлік цикл: СХД ОС-ының қолдау мерзімі, EOS/EOL саясаты, және 2–3 жылдан кейін апгрейд қажет болғанда не болады. SLA деңгейі сақталады ма? Компоненттер "тек бар кезде" сатылымға шығарылмай ма?

Мысал: Алматыдағы банк үшін төлемдер — критикалы сервис. «24/7» деп жазылған КП, бірақ қалпына келтіру уақыты және запчастылардың аймақтағы жеткізілім шарттары көрсетілмесе, бір тәулік бойы тоқтап қалу тәуекелі бар. Керісінше, бір сағат ішінде қашықтан диагностика, 4 сағат ішінде келу, жергілікті қоймада контроллер бар болғанда сол күні ауыстыру сияқты нақты жазылған құжат сенімді.

КП-ларды салыстырудың қадамдық әдісі: барлық жеткізушілер үшін бір шаблон

HPE Alletra 6000 all-flash СХД және баламаларды нақты салыстыру үшін әдемі сандарды орталықтан шығарып тастаңыз. Бір шаблон дайындап, барлығынан оны бірдей шарттармен толтыруды талап етіңіз. Сонда айырмашылықтар даулы емес, айқын болады.

5 қадамдық салыстыру шаблоны

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

2. Әр КП‑ны бір түрге келтіріңіз: контроллерлер құрамы, SSD түрі мен көлемі, шкаф(тар), пайдалы сыйымдылық, RAID/EC, снапшоттар/репликация, порттар мен желі жылдамдығы, лицензиялар және шектеулер.

3. Өнімділікті бір профильге нормаландырыңыз: блокты (мысалы, 8K), оқу/жазуды (мысалы, 70/30 немесе сіздің профиль), кезек тереңдігін, томдар санын, снапшоттар мен репликация қосылған ба екенін бекітіңіз. Егер «кепіл» болса, оның қай шартта жұмыс істейтіні мен шарт бұзылса не болатынын сұраңыз.

4. Қолдауды «03:00‑де ақау» сценарийімен салыстырыңыз: кім қабылдайды, қанша минутта жауап береді, қанша уақыт ішінде инженер келеді, жергілікті запчастылар бар ма. Қалпына келтіру деп нені есептейтінін де айқындаңыз: жай массивті қосу ма, әлде мақсатты өнімділікті қайтару ма.

5. 3–5 жылға TCO есептеңіз: қолдау, кеңейту сыйымдылығы мен порттар, апгрейдтер, электр шығындары және ең бастысы — тоқтап қалудың құны. Бастапқысы арзан ұсыныс тәуекелдер мен қолдау арқасында қымбатқа түсуі мүмкін.

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

All-flash СХД таңдауда жиі жасалатын қателіктер

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

Өнімділік пен сыйымдылықтағы қателіктер

1. Пиковые IOPS‑ті салыстырады, бірақ кешігу мен жүктеме профилін қарамайды. Критикалы сервис үшін қай IOPS мақсатты кешігу кезінде ұсталады (мысалы, 1–2 мс) және қай блокта (4K, 8K), оқу/жазу қатынасы мен кезек тереңдігі маңызды.

2. «Тиімді сыйымдылыққа» шартсыз сенеді. Бұл сан thin provisioning, дедупликация және компрессияны оптимистік деректерде есептеген болуы мүмкін. Егер КП‑да деректер түрі мен қолданылу шекарасы көрсетілмесе, салыстыру негізсіз.

3. Функциялардың әсерін ұмытады. Репликация, шифрлау, снапшоттар, бүтіндік бақылау, фондық тапсырмалар өнімділікті азайтып, сыйымдылықты арттыруы мүмкін. КП‑да көрсеткіштер функция қосылғанда не қосылмағанда алынғаны айқын көрсетілуі тиіс.

Жылдам тексеріс үшін әр жеткізушіден бір профиль бойынша есеп сұраңыз: «80/20 оқу/жазу, 8K, мақсатты кешігу 1 мс дейін, снапшоттар мен шифрлау қосылған». Осыдан Alletra 6000 мен баламаларды шынайы салыстыруға болады.

Инфрақұрылым мен қолдаудағы қателіктер

Көбіне желіні ұмытып кетеді, кейін «ақырындап» порттар немесе қатесіздік жетіспей қалады. КП‑да нақты жазылуы тиіс: СХД‑да қандай порттар мен жылдамдықтар қажет, сервер жағы қандай, қандай коммутаторлар/оптика/патч-кордтар мен лицензиялар талап етіледі, резервтеу схемасы (2 коммутатор, 2 жол, MPIO) және үйлесімділік шектеулері (FC/iSCSI, ОС пен гипервизор версиялары).

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

Қысқа чек-лист: шешім қабылдаудан бұрын 6 тексеріс

КП-ларды салыстырмас бұрын бірдей ережелер орнатыңыз. Әйтпесе сіз жүйелерді емес, тест сценарийлерін және допущенияларды салыстырып жатасыз.

Басты 5 тексеріс:

• Жүктеме профилі бірдей: блок өлшемі (мысалы, 4K/8K/64K), оқу/жазу үлесі, кездейсоқ немесе үздіксіз қатынау. Егер профильдер әртүрлі болса, IOPS пен GB/s салыстыра алмайсыз.
• Кешігуді тек орташа емес, p95 немесе p99 көрсетіңіз және өлшеу шарттарын (кезек, ағындар, қосылған функциялар) көрсетіңіз. Критикалы сервис үшін шыңдар маңызды.
• Өнімділік нақты конфигурацияға байланған: қандай контроллерлер, қанша диск, қандай желі мен протокол, снапшоттар мен репликация қосылған ба. «Кепілдеме» сөзінен бұрын стенд құрамы болуы тиіс.
• «Тиімді» сыйымдылық допущениямен расталған: деректер түрі, дедупликация/компрессия күтілімі, бірегей блоктар үлесі, шифрлау әсері.
• Қолдау пункттер бойынша жазылған: не кіреді (ПО, прошивка, ауыстыру, выезд), жауап және қалпына келтіру уақыты, режим 24/7 немесе 8/5, кім орындайды.

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

Алтыншы тексеріс, ол 2–3 жылдық бюджетіңізді қорғайды:

• Өсу жоспары мен кеңею құны: сыйымдылық пен өнімділікті қосу қанша тұрады (контроллерлер, лицензиялар, шкафтар, порттар), жеткізу мерзімдері. Жақсы КП бұл сұраққа алдын ала жауап береді.

Қазақстанда сатып алу кезінде интегратор осы тармақтарды бір шаблонда бекітіп, КП қосымшаларында растаса ыңғайлы. Мысалы, GSE.kz (gse.kz) сияқты интегратор дизайн, жеткізу және тәулік бойғы қолдауды өз мойнына алуы мүмкін — осылайша тәуекелдер аппарат пен эксплуатация арасында «айналмайды».

Мысал: практикалық түрде екі КП-ны қалай салыстыру

Типтік картинка: деректер базасына негізделген ERP, қолданбалар үшін виртуализация кластері және құжаттар үшін файл сервистері. Деректер жылына шамамен 20% өседі, ал тоқтап қалу екі СХД арасындағы баға айырмасынан қымбатқа түседі.

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

Бастапқы деректер жиынтығы әдетте:

• қазір және 3 жылнан кейінгі деректер көлемі (өсу ескеріліп);
• кездейсоқ операциялар үлесі (мысалы, 70% random) және оқу/жазу қатынасы (мысалы, 60/40);
• мақсатты кешігулер: ERP және виртуализация үшін бөлек (мс);
• пик: айдың соңында/кварталда жүктеме қанша есе өседі;
• тоқтап қалу талаптары: RTO/RPO және қызмет көрсету терезесі.

Екі КП бар: A нұсқасы «4:1 компрессия» деп арзанырақ, B нұсқасы қолдауды қатаң шартпен: жауап уақыты, 24/7, контроллерді міндетті түрде мерзімде ауыстыру және айқын исключениялар. Екеуі де бір модельді ұсынады, бірақ салыстыру тек сіздің жүктемеңізге негізделіп жасалуы тиіс.

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

1. A-дан екі режимдегі сыйымдылық есебін сұраңыз: 1:1 (үлгісіз) және жарнамаланған компрессиямен, және допущения тізімін беруді талап етіңіз. Егер допущения сіздің деректерге сай болмаса, коэффициент пайдалы емес.

2. Өнімділік бойынша сіздің профилге арналған IOPS, өткізу қабілеті, кешігу көрсеткіштері және деградацияда не болатыны (бір түйін/контроллер істен шыққанда, rebuild кезінде) сұраңыз.

3. Қолдау бойынша қағаздағы SLA-ларды салыстырыңыз: жұмыс уақыты, жауап уақыты, қалпына келтіру уақыты, запчастыларды қалай жеткізеді, жергілікті қойма бар ма, исключениялар.

Егер негізгі мақсат — тоқтап қалуды азайту болса, жиі B нұсқасы жеңеді, тіпті сыйымдылық қымбат болса да: тәуекелдер анық және басқарылатын. Егер бюджет басты фактор болса, A мүмкін, бірақ компрессия сіздің деректерге тест арқылы расталмаса және КП‑да «нашар коэффициент» үшін резерв пен кеңейту құны жазылмаса, тәуекелдер үлкен болады.

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

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

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

Кілт томдар мен сервистер бойынша қажетті мәліметтерді алыңыз:

• кешігу (орташа және 95%-тік перцентиль);
• пик IOPS және өткізу қабілеті;
• контроллер/порт жүктемесі және хосттардағы кезек саны;
• резервтік көшіру терезелері және тұрақты ауыр тапсырмалар (ETL, есептер, антивирус);
• деректер өсімі және 12–24 айға болжау.

Содан кейін бизнес талаптарын SLA-ға аударыңыз, ал SLA‑ны СХД талаптарына және қолдауға айналдырыңыз. Мысалы, «поликлиника жазылу порталы пайдаланушы үшін 200 мс-тан төмен жауап беруі тиіс» деген талап: «база үшін 95%-тік перцентиль latency X мс-тан артық болмауы тиіс, жүктеме Y IOPS, инцидент бойынша қалпына келтіру Z сағаттан аспауы тиіс» сияқты тексерілетін талаптарға ауыстырылады. Бұл талапты КП мен пилотта тексеру оңай.

Пилотты сіздің профиліңізде және деректеріңізбен жүргізуді талап етіңіз. Синтетикалық тесттер әдемі IOPS көрсете алады, бірақ аралас оқу/жазу және кішкентай блоктар кезіндегі кешігуді нашар көрсетеді.

Пилотта алдын ала талап етуге болатындар:

• жүктеме профилінің сипаттамасы (блок, % оқу, кезек) және оны қалай репродукциялайтындары;
• кешігудің бөлек көрсеткіштері (орташа және p95), тек IOPS емес;
• компрессия/дедупликация тиімділігінің сіздің деректердегі есебі;
• пилот уақытында қолдау шарттары: кім жауап береді және қанша уақытта.

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