Виртуализацияға арналған орташа деңгейлі сақтау жүйелері: MSA, ME, ETERNUS

Виртуализацияға арналған сақтау жүйелері туралы талқылау

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

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

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

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

Мысалы: 30–50 ВМ бар кластерде бәрі тыныш болады, тек пайдаланушылардың таңғы кірісуі, жаңартулар, антивирус тексерісі және бэкап басталғанда. Бұл сәтте «көлем» емес, шың жазбалар мен кішкентай кездейсоқ операциялар байқалады.

Сондықтан HPE MSA, Dell PowerVault ME және Fujitsu ETERNUS арасындағы таңдау көбіне бренд туралы емес, бір жылдан кейін қандай жүктеме болатынын және қайда қор қалдыруды қалайтыныңыз туралы болады — кідіріс бойынша, кеңейту бойынша немесе кэш бойынша.

Салыстыру үшін қажет метрикалар

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

IOPS, MB/s және кідіріс әр түрлі сұрақтарға жауап береді:

• IOPS — көптеген кішкентай операцияларға маңызды (виртуалды машиналар мен дерекқорларға тән);
• MB/s — деректер ағынының жылдамдығын көрсетеді, мысалы бэкаптар немесе үлкен файлдар үшін;
• Кідіріс (latency) көбіне ең маңызды: тіпті жақсы IOPS болса да, егер жауап уақыты шыңда секірсе, пайдаланушылар ренжиді.

Қосымша тұзақ — кезек тереңдігі. Нәтижелер кезек тереңдігіне қатты тәуелді: ол жоғары болған сайын IOPS-ты «жеделдету» оңай, бірақ бұл VMware немесе Hyper-V-дағы мінезге ұқсамайтын шығар. Виртуализация үшін әдетте төмен және тұрақты кідіріс при умеренной очереди маңыздырақ, рекорды емес.

RAID пен диск түрлері картинаны түбегейлі өзгертеді. SSD мен HDD айырмашылығы анық, бірақ RAID 5/6-ның «жазуға салған айыппұлын» ұмытпаңыз: жазу қымбаттайды, сондықтан кідіріс өседі. Контроллер кэші шыңдарды тегістей алады, бірақ RAID математикасын және дискілерге қойылған шектеулерді жоя алмайды.

Солайша тар жер жиі дискіде емес, «обвязкада»: контроллерлер, порттар, хост-интерфейстер және multipath баптауында болады.

MSA, ME және ETERNUS-ты салыстырмас бұрын бірдей шарттарды тіркеу керек: жүктеме профилі (оқу/жазу пайызы және блок көлемі), шың кезіндегі рұқсат етілген кідіріс, кезек тереңдігі және ағындар саны, RAID және диск түрі, жазуды кэштеу бар ма, сондай-ақ СЖ және хосттар жағындағы порттар жылдамдығы мен саны.

Осы параметрлер бірдей болса, сандар салыстырмалы болады, ал таңдау айтарлықтай оңайырақ.

IOPS шектері: қанша жеткілікті екенін қалай түсіну

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

Ең алдымен сан қалай алынғанын сұраңыз. Бір және сол массив 4K оқуында «әдемі» IOPS көрсете алады, ал 8K–16K блоктарда, аралас оқу/жазу кезінде немесе ағын саны аз болғанда айтарлықтай төмендеуі мүмкін. Виртуализация үшін маңызды сценарийлер — «кездейсоқ қатынау + 60/40 немесе 70/30 оқу/жазу» және сіз қонақ ОС-тарында көтере алатын кідірісті өлшеу.

Вендордан немесе пилот есебінен сұрауға тұратын нәрселер:

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

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

Практикалық ереже: ағымдағы хосттардан IOPS пен кідірісті өлшеп, ВМ санының өсу болжамын қосып, запас қойыңыз. Көп жағдайда 30–50% өсу запас пен rebuild, жаңарту сияқты «жаман күндерге» бөлек резерв жеткілікті.

Полкпен және сыйымдылықпен өсу: қалай жоспарлау керек

Орташа деңгейлі сақтау жүйесін таңдағанда дау көбіне IOPS туралы, бірақ сатып алу көбіне сыйымдылық өсімімен «сақталады». Әрбір модельде (HPE MSA, Dell PowerVault ME, Fujitsu ETERNUS) полкілер санына шектеу бар, бірақ шындықта масштабтауды спецификациядағы сандар ғана емес, басқа факторлар да шектейді.

«Таза» терабайттар жиі пайдалы сыйымдылыққа тең емес. RAID қорғанысы орын алады, жиі hot spare қажет, сонымен қатар snapshot, репликация және пулдың қалыпты жұмысы үшін әуес орын керек. Егер пулды 95% толтыруды жоспарласаңыз, проблемалар күтіңіз: жылдамдық төмендейді, кідіріс өседі, ал қызмет көрсету виртуалды машиналарға айтарлықтай кедергі жасайды.

Пулды кеңейткенде әдетте екі нәрсенің бірі болады. Немесе массив уақытша деректерді қайта орналастырады (және бұл кідірісті көтереді), немесе сіз жаңа пул құрып, жүктемелерді қолмен көшіресіз. Екінші нұсқа жиі бақылауға оңай. Полкі қосу тек сыйымдылық қана емес, өнімділік береді (диск саны көбейеді немесе SSD қосылады). Бірақ егер сіз контроллерлерге, кэшке немесе порттарға жабысып қалсаңыз, жаңа дискілер көмектеспейді.

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

Жоспарды қарапайым ұстаңыз:

• пайдалы сыйымдылықты есептеңіз: RAID + hot spare + кемінде 20–30% бос орын;
• алдын ала шешіңіз, қалай кеңейтесіз: сол типтегі дискпен немесе бөлек пулмен;
• қызмет көрсетудің шыдамдылығын тексеріңіз: үлкен дискілердегі rebuild ұзақ болуы мүмкін;
• шкаф бойынша запас қалдырыңыз: RU, полкі салмағы, кабельдерге орын;
• инженерлік шарттарды анықтаңыз: қуат (A/B), PDU, салқындату және шу.

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

Кэш пен контроллерлер: қашан шын маңызды

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

Жауаптың жақсаруына әсер ететін негізгі режим — write-back. Бұл режимде жазба кэшке түскеннен кейін дереу расталады, ал дискіге деректер кейінірек жазылады. Бұл кідірісті азайтады және кішігірім жазбалардағы IOPS-ты көтереді, бірақ қуат өшуінсіз кэштің жоғалуына қарсы қорғаныс қажет. Сондықтан батарея немесе суперконденсатор (кейде энергонезависимая жадымен бірге) маңызды.

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

Кэш дискілер мен тактылық жиынтық жүктеме кэшке сыйып кетсе ғана көмектеседі; ол көмектеспейді, егер диск жүктемесі желіде немесе контроллер CPU-да болса, немесе жұмыс жиынтығы кэштен үлкен болса. Мұндай сценарийлерде ұзақ оқу, бір реттік үлкен ағындар немесе барлық жерде SSD болғанымен кідіріс кезектер мен контроллер CPU-дан анықталады.

Модельдің сипаттамасында ең пайдалысы — нақты деректер: контроллердегі кэш көлемі және оның қанша бөлігі нақты қолжетімді; write-back әдепкі қосылған ба және оны не өшіреді; қуат өшіру кезінде кэш қалай қорғалады; кэштің айнаға алынуы бар ма; контроллердердің істен шыққан кездегі мінезі және ауысу жылдамдығы.

Интерфейстер және қосылу: IOPS қайда жоғалады

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

FC, iSCSI, SAS: қайсысы жеңіл және қайсысы кідіріс бойынша тиімді

FC әдетте тұрақты кідіріс береді және жалпы трафиктен аз әсерленеді, бірақ FC-коммутаторлар мен зонирлеуді қажет етеді. iSCSI енгізуге оңайрақ, өйткені Ethernet үстінде жұмыс істейді, бірақ ол мұқият желіні талап етеді (жылдамдық, буферлер, jumbo frames, артық маршрутизация болмауы). SAS қосылу «қысқа және қарапайым» көрінеді, бірақ масштабтауда икемсіз және көбіне топологиямен шектеледі.

Практикада айырмашылық тез байқалады: eгер iSCSI-де сақтау мен қалыпты желіні араластырып жіберсеңіз, кідірістің өсуі SSD артықшылығын «жоюы» мүмкін. FC-де тамаша цифр ала аласыз, бірақ оларды қате зонирлеу немесе ISL-дардың шамадан тыс жүктелуі бұзады.

Қанша порт керек және неге MPIO міндетті

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

Практикалық бастапқы схема: екі сегмент (A және B) немесе екі тәуелсіз коммутатор; әр хостта сақтау үшін кемінде 2 порт және әр контроллерде 2 порт; хосттарда MPIO, балансинг саясаты айқын; жолдарды әртүрлі NIC/HBA, коммутаторлар және VLAN/VSAN бойынша бөлу.

MPIO тек төзімділік үшін емес. Ол порттарды тең жүктеуге көмектеседі, бір ғана жол «тұраққа» айналып, IOPS пен кідірісті нашарлатпау үшін.

Типтік қателіктер: iSCSI-ді QoS жоқ жүктелген коммутатор арқылы өткізу, "барлық үшін бір үлкен VLAN", әр түрлі MTU мәндері, қате LACP баптаулары. FC-де жиі кездесетіндер: барлық хосттарды бір зонаға қосу немесе тым күрделі схема, диагностика қиын.

Қадамдар: MSA, ME және ETERNUS арасында қалай таңдау

HPE MSA, Dell PowerVault ME және Fujitsu ETERNUS таңдау жиі бренд емес, нақты конфигурацияның сіздің жүктемеңізді қаншалықты ұстай алатынына тіреледі. Орташа деңгейлі сақтау жүйесі үшін тең шарттарда салыстыру маңызды: сол дискілер, сол RAID, сол полкі саны және сол қосылу ені.

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

Кейін қарапайым алгоритм көмектеседі:

• ағымдағы ортадан деректер жинаңыз: орташа және шың IOPS, оқу/жазу, блок көлемі, датасторларға қатысты кідіріс, толтыру және өсу қарқыны;
• негізгі сервистер үшін мақсатты кідірісті қойыңыз (дерекқорлар мен «қарапайым» ВМ үшін бөлек);
• бірдей пайдалы сыйымдылық пен қорғаныс деңгейіне сәйкес 2–3 кандидат конфигурация жинаңыз;
• масштабтау шектерін тексеріңіз: максималды полкі, дискілер, кэш, порттар және өсу кезінде өнімділік не болады;
• бір сценарий бойынша тест салыстырыңыз: сол ВМ-дер, сол профильдер, сол шың уақыттары.

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

Және қабылдау критерийлерін алдын ала бекітіңіз: шыңдағы шекті кідіріс, өсуге запас (мысалы, 30–40%), RAID және hot spare есепке алынған пайдалы сыйымдылық, анық кеңейту сценарийі және іске қосқаннан кейін бақылау мен нәтижені растау әдісі.

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

Виртуализациядағы типтік жүктемелер және олар сақтау жүйесін қалай шектейді

Бір сақтау жүйесі жүктемеге қарай әр түрлі жүреді. Сондықтан жүйелерді тек «прайстегі IOPS» бойынша салыстыру қауіпті: виртуализацияда жиі аралас оқу/жазу мен кездейсоқ пен үздіксіз операциялар араласады.

Кластердегі ең жиі профильдер:

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

«Орташа температура» проблемасы: 80% уақытта бәрі тыныш, ал 20% уақытта сақтау жүйесі шектеледі және пайдаланушылар кешігуді сезінеді. Күн бойы орташа кідіріс қалыпты көрінуі мүмкін, бірақ 95-ші немесе 99-шы процентильдегі қысқа шыңдар VDI мен дерекқорларды шыдамсыз етеді. Сондықтан орташа көрсеткішпен бірге 95/99-й процентильдерді бақылаңыз.

Төзімділік үшін орташа деңгейде минимум қажет: массивте екі контроллер, хосттарға екі тәуелсіз жол (multipath) және екі коммутатор (немесе FC үшін екі тәуелсіз fabric). «Екінші жолдан» үнемдеу кішігірім мәселені ірі тоқтауға айналдырады.

Снапшоттар мен репликация да ресурсты алады. Алдын ала қарап шығыңыз: snapshot қайда сақталады және белсенді жазу кезінде қалай өседі, қаншалықты жиі жасалады және қанша уақыт сақталады, репликация мен бэкап қандай уақытта өтеді және сізге не маңызды: RPO/RTO немесе күн ортасында тұрақты өнімділік.

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

Практикалық мысал: ұйымдағы виртуализация кластері

Орташа кейс: компанияда 2–3 кластер бар (прод, тест, критикалық қызметтер үшін бөлек), барлығы 40–80 виртуалды машина. Екі сервис «бизнеске тіреу» береді (мысалы, 1С дерекқоры және пошта), тағы пилоттық VDI 20–30 орын үшін жүр.

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

Шешімге нақты әсер ететін сұрақтар:

• IOPS пен кідіріс сыңуы қашан болады (таңертең, ай аяқтауы, реттеу жұмыстары)?
• «Шу шығарушы көршілер» бар ма — кей ВМ-дар уақытша диск ресурсын жұта ма (антивирус, индексация, есептер)?
• бэкап қалай ұйымдастырылған (snapshot, репликация, түнгі толық көшірмелер)?
• 12–24 айда ВМ саны мен деректер саны қанша өседі?
• VDI үшін бөлек аймақ керек пе, ол маңызды сервистерге әсер етпесін үшін?

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

Компромисстер бренд емес, приоритеттер бойынша шешіледі: NL-SAS-та көбірек сыйымдылық (арзан, бірақ шыңда кідіріс тәуекелі жоғары), көбірек SSD (жылдамырақ, бірақ өсу бақылауын талап етеді), максималды полкі «болашаққа» (кеңейту артықшылығы, бірақ қуат пен орын шығындары), кэш пен екінші контроллер (қымбаттау, бірақ аралас жүктемеде тұрақтылықты арттырады).

Таңдау және сатып алудағы жиі қателіктер

Ең жиі қате — IOPS-ты «оқшауланған сан» ретінде салыстыру. Бір вендор 100% оқу тестін көрсетеді, екіншісі 70/30, үшіншісі кезек тереңдігін арттырған. Виртуализация үшін маңызды — аралас жүктеме кезінде кідіріс пен оның тұрақтылығы.

Екінші қате — сыйымдылықты «тартылып» алу. RAID-та диск бөліктері қорғаныс үшін кетеді, сондай-ақ rebuild, snapshot және метадеректер үшін орын керек. Қазір толтыруға теңеп сатып алсаңыз, бірнеше айдан кейін шектеулер басталады: кеңейту ауыр және апат кезінде орын аз.

Көп жағдайда бір пулға продуктив пен бэкапты араластыру болжамды болжай білуді бұзады. Түнгі бэкап көп ағынмен кезекті «жеп», ВМ-дерге кідіріс секірістерін береді. Үздік тәжірибе — пулдарды бөлу немесе көшіру тапсырмаларына шектеулер қою.

Тағы бір тұзақ — желіге үнемдеу. Шешім көбіне сақтау жүйесінде емес, бір коммутаторда не бірнеше 10GbE порттың жеткіліксіздігінен, дұрыс емес MTU-дан, multipath жоқтығынан немесе хосттағы iSCSI/FC баптары қателігінен туындайды. Нәтижесінде массив әлсіз көрінуі мүмкін, ал мәселе мүлде басқада.

Сатып алудан бұрын бес пунктті тексеріңіз:

• тест шарттары: блок, профиль, кезек, оқу/жазу үлесі және мақсатты кідіріс;
• сыйымдылық есептеуі RAID, hot spare, snapshot және өсу запасын ескеріп жасалған ба;
• продуктив томдар мен бэкап мақсаттарын бөлу немесе түсінікті лимиттер бар ма;
• желінің өткізу қабілеті мен төзімділігі (порттар, жолдар, баптаулар);
• үйлесімділік: прошивкалар, MPIO/DSM, драйверлер және сіздің VMware немесе Hyper-V нұсқасы қолдау табады ма.

Соңғы таңдау алдындағы чеклист және келесі қадам

Сатып алуға дейін бір бетке ең маңызды талаптарды жинап алу пайдалы — жобада қай жерде MSA, ME немесе ETERNUS сіздің схемада шектелетінін тез көруге көмектеседі.

Ең алдымен қолданбалар мен бизнестен талаптарды өлшенетін түрде тіркеңіз:

• жұмыс уақытындағы және шың кезіндегі мақсатты кідіріс (әр түрлі критикалық ВМ-дар үшін бөлек);
• 12–24 айға сыйымдылық өсуі және кеңейту кезінде рұқсат етілген тоқтау терезелері;
• ең сезімтал сервистер (VDI, дерекқорлар, файлдық, бэкап) және олардың оқу/жазу профилі;
• RPO/RTO талаптары және «қалпына келтірілген» деп не есептелетіні;
• орын шектеулері: қуат, шкафтар, қолжетімді SAN/LAN порттары.

Содан кейін таңдалған конфигурацияның ертерек «аяқталмауын» тексеріңіз. Мұнда тек дискілер ғана емес маңызды:

• бақылаңыз: қанша полкі шын мәнінде қосуға болады контроллер ауыстырмай, порттарда қанша бос орын қалады;
• пулдар, RAID-группалар, thin, snapshot, репликация шектеулері бар ма;
• өнімділік резерві: деградацияда (1 контроллер, rebuild, диск қолданыстан шығып) не болады;
• хосттан СЖ-ға дейін екі тәуелсіз жол (мультипасинг) және мониторинг бар ма;
• қызмет көрсету рәсімі: дискілерді, контроллерлерді, батарейкаларды немесе кэш модульдерін кім және қалай ауыстырады.

Іске қосу жоспары да алдын ала жазылуы керек: алдымен жаңа СЖ-ны тест хостқа қосып, сіздің «дүйсенбі 10:00»-ге ұқсас жүктемені жүргізіп, содан кейін ғана продуктивті миграция жасау. Қабылдау критерийлері қарапайым: мақсатты кідіріске жеттік пе, шыңдегі IOPS-ты сақтадық па, авариялық сценарийлер рәсім бойынша өтіп жатыр ма.

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