Виртуализацияға арналған all-flash СҚЖ үшін коммерциялық ұсыныстағы (КП) қандай проблема бар

All-flash сақтау жүйелері бойынша коммерциялық ұсыныстардың басты мәселесі — олар көбіне баға тізімдері сияқты салыстырылады: модель, сыйымдылық, «X IOPS дейін» және баға. Виртуализация жағдайында бұл сатып алғаннан кейін жағымсыз тосынсыйларға әкеледі. Себебі «жаман адам» бар деп емес, КП‑да көрсетілген көрсеткіштерді алу шарттары аз жазылады.

IOPS пен latency брошюрада контекссіз көп нәрсе бермейді. Бір өндірушінің «1 млн IOPS» көрсеткіші 4K блоктарда, 100% оқу, кезек ұзындығы 128, компрессия қосылған, қысқа лабораториялық тестте алынған болуы мүмкін. Басқа өндіруші — аралас профиль 70/30 және нақты кешігулермен, бірақ IOPS төмен. Нәтижесінде сіз жүйелерді емес, маркетингті салыстырасыз. Huawei OceanStor Dorado сияқты платформа үшін бұл әсіресе маңызды: жүйе мықты, бірақ дұрыс салыстыру сұраған параметрлерге және жасалған қабылдауларға байланысты.

Тағы бір типтік мәселе — КП‑ға шешімнің «құрдас» бөліктері кірмейді, олар кейін нәтижеге СҚЖ‑дан гөрі көбірек әсер етуі мүмкін. Мысалы, сіз 1–2 мс күтесіз, бірақ шын мәнінде 8–12 мс алады, себебі тар жерде желі немесе хосттар болып шықты.

КП‑да көбінесе жеткіліксіз көрсетілетіндер:

Тестілеу шарттары: блок өлшемі, оқу/жазу профилі, кезек ұзындығы, ұзақтығы, дедупликация мен компрессия қосылған ба.
Нақты конфигурация: қанша контроллер, қандай дисктар/кластар, RAID/erasure coding, кэш көлемі, жеделдету лицензиялары.
Порттар және жылдамдық «дана‑дана»: қанша 16/32G FC немесе 25/100GbE нақты орнатылады, «қолдануға болады» емес.
Қоршаған орта талаптары: хосттардағы HBA/NIC, MPIO/ALUA баптаулары, фабрика немесе коммутатор схемасы.
Функционал шектеулері: снапшоттар, репликация, шифрлау, QoS қосылғанда өнімділік не болады.

Виртуализациядан мысал: компания 6 хосттан тұратын кластер және 400 VDI жоспарлайды. КП‑да тек сыйымдылық пен «шыққандағы IOPS» салыстырылған. Іске қосқаннан кейін нақты жұмыс істеу үшін СҚЖ мен әр хостқа қосымша FC порттар және қажетті репликация лицензиясы қажет екені анықталды. СҚЖ өзі күшейеді, бірақ жоба қымбаттайды және мерзімдер өзгеріледі.

Салыстыру әділ болуы үшін бірнеше шешімді алдын ала қабылдап, сұранымда бекіту керек: қай гипервизор және оның нұсқасы, қандай протоколдарды дәл қолдануға дайынсыз (FC/iSCSI/NVMe over Fabrics), қай жүктеме профилін «өздікі» деп санайсыз (VDI, деректер базасы, файлдық сервистер), және қай метрикалар маңызды — 95/99 перцентиль бойынша тұрақты latency ме әлде пиктегі максимум IOPS па. Бұны КП алынбас бұрын жасау кейінгі цифрларды нақты талқылауды және қабылдау сынақтарын оңайлатады.

Дұрыс салыстыру үшін КП‑ға дейін нені сипаттау керек

All‑flash СҚЖ‑ды адал салыстыру үшін алдымен виртуалдық ортаңызды сипаттау маңызды. Әйтпесе жеткізушілер әсем, бірақ салыстыруға келмейтін сандар жібереді: біреуі «жеңіл» профильге есептесе, екіншісі «ауыр» профильге және екеуі де формальды түрде дұрыс болады.

Жүктемелерді инвентаризациялаудан бастаңыз. Бастапқыда қанша виртуалдық машина болады және олар қандай типте: VDI, деректер базасы, файлдық сервистер, терминалдық серверлер, қолданбалы жүйелер. Қай VM‑лар жауап беру уақыты жағынан маңызды, қайсысы кідірістерге шыдайтынын көрсетіңіз. Huawei OceanStor Dorado‑ға арналған виртуализация үшін бұл аса маңызды: СҚЖ‑ның мінез-құлқы сізде қандай жүктеме жүретініне қатты байланысты.

Кейін I/O профилін шамамен сипаттау қажет. Оқу және жазу үлесі (мысалы, 70/30), типтік блок өлшемі (4K, 8K, 64K) және пиктер: қашан және қаншалықты жүктеме өседі (таңертең, ай соңында, түнгі бэкап, есептеулер). Нақты метрикалар болмаса, гипервизор мониторингінен деректер алып немесе жұмыс күнінде қысқа өлшеу жасауға болады.

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

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

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

Жүктеме типтері тізімі және старттағы VM саны
I/O профилі: оқу/жазу, блок өлшемдері, пиктер
Ақау сценарийлері және рұқсат етілген тоқтау уақыты
Стойка, қуат, салқындату және ағымдағы желі шектеулері
1–3 жылға өсу жоспары: сыйымдылық, өнімділік, порттар

Қарапайым мысал: 250 VM, оның 120‑сы VDI, 20‑сы деректер базасы, қалғаны файлдық және қолданбалы сервистер. Күндіз көп 4K операциялар, кешкі уақытта — резервтеу және жазу өсімі. Бұны сипаттамасаңыз, КП күндізгі профильге «оптимизация» жасап, түнгі жағымсыз тосынсыйға әкелуі мүмкін.

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

Порттар мен интерфейстер: ең алдымен не салыстыру керек

All‑flash СҚЖ бойынша КП‑да ең оңай жеңуге болатын нәрсе — қосылу әдісін нақтыламау. Виртуализация үшін бұл шешуші: ең жылдам жүйе де желі, HBA/NIC немесе коммутаторларда «шектеліп» қалуы мүмкін, сондықтан latency жоғарылайды дискілер себеп емес.

Алдымен фронтенд қосылым түрін анықтаңыз. SAN үшін әдетте FC (16/32Gb) және Ethernet арқылы iSCSI/NVMe over RoCE (10/25/40/100GbE) салыстырылады. Конвергентті нұсқалар да болуы мүмкін, бірақ сіздің ағымдағы стек (коммутаторлар, сервердегі карталар, гипервизор лицензиялары, қауіпсіздік саясаттары) бұл шын мәнінде қолдайтынын тексеріңіз. Huawei OceanStor Dorado үшін «FC/Ethernet порттары бар ма» деп емес, қандай модульдер, әрқайсысында қанша порт және олар контроллерлер бойынша қалай бөлінгенін нақтылаңыз.

Жылдамдық сәйкестігі қарапайым көрінуі мүмкін, бірақ тәжірибеде жоспарларды бұзады. Мысалы, СҚЖ‑да 100GbE бар деп тиімді болмайды, егер хосттарда 2x25GbE болса және коммутаторлар жеткілікті аплинктерге ие болмаса. FC‑де де солай: СҚЖ‑дағы 32Gb FC хосттардағы кейбір HBA‑лар 16Gb болса пайдасын бермейді — жылдамдық төмендетуге тура келеді. Оптика немесе мыс, трансивер типтері мен кабель ұзындықтарын монтаждауды күте тұрып анықтаңыз.

Резервтеу схемасын «2 контроллер» деп жазып қою жеткіліксіз. Қалыпты унитазды қамтамасыз ету үшін әдетте екі тәуелсіз коммутатор (fabric A/B) қажет, ал СҚЖ порттары контроллерлер бойынша әрі осы екі фабрикасына таралуы керек. Әйтпесе бір контроллер немесе бір коммутатор құлаған кезде жолдардың жартысы жоғалып, latency секіріп кетуі мүмкін.

Қай жерде жиі өнімділік шегі шығады

Практикада шектеулер тек СҚЖ порттарында ғана емес. Жиі кінәлілер: шамадан тыс жүктелген коммутаторлар, хосттардағы порттардың жетіспеушілігі, multipath қателіктері немесе белсенді жолдардың аздығы (кейбір қосылымдар бекітілмей жатады).

Мысалы: 6 хосттан тұратын кластерде әрқайсысында 2x25GbE бар. Егер сіз СҚЖ‑ны әр контроллерге бар болғаны екі 25GbE портпен ғана қостыңыз, пиковые бэкаптар мен VM миграциялары кезінде фронтендке урау түсіп, СҚЖ‑ның «миллиондаған IOPS» қағаздағы көрсеткіші пайдасыз болады.

КП‑да бұл қалай бекітіледі

Қабылдауға тексеруге болатын нақтылықты сұраңыз:

Фронтенд‑модульдердің нақты модельдері, модуль саны және әрқайсысындағы порт саны.
Порттардың жылдамдығы және жұмыс режимдері (мысалы, 25/100GbE, 16/32Gb FC), орта түрі (оптика/мыс) және трансивер талаптары.
Қосылым схемасы: контроллерлер мен екі коммутатор бойынша таралым, әр хостқа қанша актив жол болатыны.
Шектеулер мен тұжырымдамалар: қанша порт «апгрейд лицензиясы/модулі»сыз қолжетімді, қай порттар репликация немесе сервис желілері үшін босатылған.
Хостқа ұсынылатын NIC/HBA саны және минимал коммутатор талаптары, осылайша көрсетілген latency мен IOPS қолжетімді болады.

Осы пункттер КП‑да нақты жазылса, салыстыру әділ болады: сіз маркетингтік сандар емес, нақты фронтенд мүмкіндіктерін салыстырасыз.

Протоколдар және гипервизормен интеграция: енгізу кезінде тосынсый болмайтындай

Тіпті ең жақсы all‑flash СҚЖ де виртуализацияда әртүрлі нәтиже беруі мүмкін — протоколға және ол сіздің гипервизормен қалай «жұмыстасатынына» байланысты. Сондықтан КП‑да тек «iSCSI/FC қолдайды» деп емес, нақты қосылу схемасын, нұсқаларды және шектеулерді көрсету маңызды.

Протокол таңдау: КП‑да нені нақтылау керек

Алдымен не пайдаланатыныңызды бекітіңіз: iSCSI, Fibre Channel немесе NVMe over Fabrics. Содан кейін «біздің ортада қалай болады» форматында параметрлерді сипаттауды талап етіңіз.

Мысалы, iSCSI үшін маңызды: 10/25/40/100GbE, контроллерде қанша физикалық порт, трафик қалай бөлінеді (storage үшін бөлек VLAN), қандай MTU жоспарланады, және коммутаторларға қандай талаптар (DCB, PFC — егер олар қажет деп көрсетілсе). FC үшін — 16/32G жылдамдық, қанша FC порт, A/B фабрикалар қалай құрылады және FC‑порттарды немесе протоколды «қосу» үшін бөлек лицензия қажет пе.

Гипервизормен интеграция: нұсқалар мен «кішігірім талаптар»

КП‑да «VMware vSphere X.Y / Hyper‑V (Windows Server YYYY) / KVM (дистрибутив және нұсқа)» сияқты нақты жол болуы керек, «VMware supported» деп жалпылама жазбау керек. Нұсқалар арасындағы ұсақ айырмашылықтар драйверлар, плагиндер және multipath мінезіне үлкен әсер етуі мүмкін.

Multipath баптауы қалай болатынын көрсетуді сұраңыз: қандай механизм (мысалы, VMware үшін NMP/PSP немесе vendor‑плагин), баланстау саясаты (Round Robin және параметрлері), ALUA‑ның қалай жұмыс істейтіні (active/optimized жолдар). Бұлар себеп болып кейде тосын latency секірістері мен өнімділік ауытқуларға әкеледі.

КП‑да күтілетін схеманы бекітіңіз: әр LUN/томға қанша жол, хосттағы қанша инициатор және бір контроллердің, порттың немесе коммутатордың ақауы кезінде мінез‑құлқы. Жай тәсіл — « қалыпты жағдайда » және «ақау кезінде» екі абзацпен сипаттауды сұрау.

Виртуализация функциялары: не шын мәнінде әсер етеді

VMware үшін VAAI (offload‑клонирование, zeroing‑жылдамдату, hardware assisted locking) қолдауын және оны қосу шарттарын нақтылаңыз. Бұл функциялар VM‑ларды клондағандағы, Storage vMotion мен шаблоннан орналастырғанда хосттар мен желіге түсетін жүктемені азайтады.

Егер vVols пайдалансаңыз, КП‑да vSphere нұсқасына сәйкес vVols қолдау бар‑жоғын, бөлек VASA Provider қажет пе, оны қалай орналастыру және оның қолжетімділігі кімге тәуелді екенін сұраңыз. Сондай‑ақ шектеулер маңызды: максималды vVol саны, снапшоттар және массивтегі объектілер саны.

Лицензиялар мен шектеулерді алдын ала табу

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

Тексеруге қосуға тұрарлықтар:

Протоколдар (iSCSI/FC/NVMe‑oF): порттар қосылған ба және активация керек пе.
Интеграциялық плагиндер/MPIO: хостқа не орнатылады, кім жаңартады, ОС/ESXi бойынша шектеулер бар ма.
VAAI/vVols/VASA: базада бар ма, объектілер саны бойынша шектеулер бар ма.
Репликация/снапшоттар/клондар: бөлек лицензиялауға тіркелген бе және өнімділікке әсері қандай.

Егер шешімді интегратор арқылы алсаңыз, КП‑да «үйлесімділік үшін жауапкершілік» талап етіңіз: гипервизор‑нұсқа, HBA/NIC, драйверлер мен прошивкалар үйлесімділігін кім растайды және қабылдау кезінде мәселе шықса оны кім шешеді.

Кэш және ішкі архитектура: СҚЖ‑ның мінезін түсіну үшін не сұрау керек

КП‑да «кэш 128 ГБ» деп ғана жазылса, бұл all‑flash массивтің нақты мінезін аз айтады. Виртуализацияда маңыздысы — қандай жады түрлері пайдаланылатыны, онда не сақталатыны және жазулардың пик кезінде латенттілікпен не болатынын білу.

«Кэш» деп нақты не айтылады

«Кэш» сөзі әртүрлі қабаттарды жасыруы мүмкін:

DRAM — «ыстық» деректер мен метадеректер үшін
энергия үнемдетілмейтін жады (NVRAM/SCM) — жазуды растау үшін
SSD‑де SLC‑буфер ретінде уақытша жазбалар үшін
метадеректерге арналған бөлек аймақтар (дедупликация кестелері, блок карталары, снапшоттар)

КП‑да кэшті түрлері мен тағайындалуы бойынша бөлуін сұраңыз. Huawei OceanStor Dorado үшін бұл VDI, деректер базасы және файлдық сервистердің аралас жүктемесінде latency тұрақтылығына тікелей әсер етеді.

Жазуды қалай растауы мәселесі бөлек. Егер массив «write acknowledged» деп жауап берсе де, деректер қорғалған аймақта және айнада сақталмай тұрып жауап берілсе, қуат жоғалған жағдайда жағымсыз салдар болуы мүмкін. Ал егер жазу қорғалған аймаққа сақталмайынша расталмаса, latency жоғары болуы мүмкін, бірақ мінез‑құлқы болжаулы болады. КП‑да қандай сценарий қолданылатыны және қандай қорғаныс механизмдері бар екені жазылуы тиіс.

Компрессия, дедупликация, RAID және «жасырын» шығындар

Деректерді қысу жерде TB бағасын әдемі көрсетуі мүмкін, бірақ latency‑ге әсер етеді. Қай жерде дедупликация мен компрессия орындалатынын (inline немесе post‑write), белгілі LUN/datastore үшін оларды өшіруге бола ма және қандай деректер түрлері көбіне қысылмайтынын (мысалы, бұрыннан сығылған бэкаптар, видео, шифрланған томдар) нақтылаңыз. Сондай‑ақ вендордың кепілдік берген IOPS пен latency қандай шартпен алынғанын (оптимизация қосылған/өшірілген) сұраңыз.

RAID/erasure coding және диск топтарының ені жазуға және rebuild‑қа әсер етеді. Топ кең болған сайын жазуға «жаза төлем» жоғары және диск шыққан жағдайда қалпына келтіру ұзақ болады. Бұл әсіресе пиковые уақыттарда, бір уақытта снапшоттар мен бэкаптар жүріп жатқанда байқалады.

КП‑да барлығына бірдей сұрақ қойыңыз:

Кэш неден тұрады (DRAM/NVRAM/SCM/SSD‑буфер) және әр қабатта не сақталады?
Жазу қалай расталады және қуат жоғалған кезде деректер қалай қорғалады?
Дедупликация/компрессия: режимі (inline/post), гранулярлығы, жанр бойынша өшіру мүмкіндігі, latency‑ге әсері?
Деректерді қорғау схемасы (RAID/EC), топ ені, есептік rebuild уақыты және өнімділікке әсері?
Снапшоттар мен клондар: қанша жоспарланады, орын мен өнімділікке қандай overhead бар, көп жойылғанда не болады?

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

Latency, IOPS және өткізу қабілеті: сандарды өз-өзін алдамастан қалай оқу керек

All‑flash СҚЖ‑ға қатысты сандар әдемі көрінгенмен, көбіне сізге ұқсамайтын тест сипаттарымен берілген. Әділ салыстыру үшін IOPS пен GB/s‑тен бөлек, бұл сандар алынған шарттарды талап етіңіз. Ең маңыздысы — орташа latency‑ді емес, «құйрықтарды» (tails) бағалау.

Қандай метрикаларды сұрау керек және неге «орташа» алдайды

Виртуализация үшін latency‑нің тұрақтылығы маңызды. Орташа latency 0.5 мс болуы мүмкін, бірақ 1% операция 10–20 мс‑ке секірсе, пайдаланушылар «тоқтап қалуларды» сезеді.

КП‑да сұраңыз:

latency: орташа, 95‑ші және 99‑шы перцентиль, сонымен қатар максимум
IOPS және өткізгіштік, олар қандай latency кезінде алынғаны көрсетілген түрде
оқу/жазу бөлінісі (мысалы, 70/30), «оқудағы пиковый IOPS» деп жазбай

Қысқа мысал: VDI таңертең көп кіші оқулар мен логиндер, күндіз фондық жаңартулар, кешке бэкаптар. Мұндай миксте 99‑шы перцентиль I/O үшін маңыздырақ, рекордтық IOPS емес.

Өлшеу шарттары: оларсыз сандарды салыстыру мүмкін емес

Бірдей массивтер түрлі методикада «асқақтап» немесе «орташа» нәтиже көрсетуі мүмкін. Сондықтан нақтылау керек:

блок өлшемі (VM үшін жиі 4K–32K, бірақ профильге байланысты)
read/write қатынасы және жүктеме түрі (кездейсоқ/реттелген)
queue depth және ағындар саны (QD‑ны асыра көбірсе IOPS өседі, бірақ latency да өседі)
тест ұзақтығы және прогрев (warm‑up)
дедупликация/компрессия қосылған ба және деректер түрі (кездейсоқ деректер қысылмайды)

Егер КП‑да «1 000 000 IOPS» болса, бірақ блок, R/W, QD және latency көрсетілмесе, бұл виртуализациядағы өнімділік емес, жарнамалық сан.

Steady state: толтыру мен прогревтен кейін өлшеңіз

All‑flash жүйелерде маңыздысы — алғашқы 5 минуттағы нәтиже емес, апта бойы нақты жүктемедегі мінез. Steady state нәтижелерін сұраңыз: пул толтырылып (мысалы 60–80%) және кэш/метадеректер прогрелгеннен кейін алынған деректер.

Неліктен: «бос» массив және салқын деректерде latency жұмыс режиміне қарағанда төмен болуы мүмкін. Кейбір сценарийлерде тар шекара SSD емес, контроллерлер, кэш, ішкі кезектер және деректер сервистері жұмысы болып шығады.

Аралас жүктеме және SLA‑ға сәйкестік

Бір синтетикалық тест виртуализациядағы көріністі сирек көрсетеді. Аралас профиль болуы тиіс: кішкентай блоктар + оқу/жазудың араласы + фондағы операциялар (снапшоттар, репликация, антивирустық сканерлер, бэкап).

Сандарды түсінікті SLA‑ға дейін азайтыңыз:

VDI және файлдық сервистер үшін әдетте кішкентай блоктарда тұрақты төмен latency маңызды
Деректер базасы үшін «құйрықтар» (99p) маңызды, өйткені сирек latency‑нің секіруі транзакцияларды баяулатады
Бэкаптар мен үлкен көшірулер үшін өткізгіштік маңызды, бірақ бұл өндірістік VM‑ларды «жоюға» жол бермеуі керек

Алдын ала мақсатты мәндер жазсаңыз (мысалы: «99p latency Y мс‑ден жоғары болмайды Z IOPS кезінде, профиль 70/30, блок 8K»), сізде КП‑ны адал салыстыруға және кейінгі қабылдауды өткізуге негіз бар.

КП‑да сұрау керек тармақтар: салыстыруды айқын ету үшін

Huawei OceanStor Dorado‑ны басқа all‑flash СҚЖ‑мен адал салыстыру үшін КП‑да «X миллион IOPS дейін» емес, бірдей бастапқы шарттар мен жеткізілімнің толық құрамы болуы тиіс. Әйтпесе сіз маркетингті салыстырасыз, шешімді емес.

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

Минималды талаптар тізімі:

Конфигурация және сыйымдылық: raw және usable (RAID/erasure coding көрсетілген), контроллер саны, полкалар, дискілер, қуат блоктары мен желдеткіштер, және сенімділік схема.
Порттар мен қосылым: жеткізілімдегі нақты порттар саны мен түрі (FC/iSCSI/NVMe), жылдамдық, хосттар үшін қанша порт қолжетімді, қанша порт ішкі байланыстарға (межконтроллер) бөлінген.
Өнімділік шарттарымен: блок өлшемі, read/write профиль, p95/p99 latency, кезек ұзындығы, массив толтыру (мысалы 70–80%), қосылған функциялар (қысу, дедупликация, шифрлау, снапшоттар).
Бағаға не кіреді: снапшоттар, репликация, QoS, мультипасинг/плагиндер лицензиялары, сондай‑ақ қолдау (мерзімі, жауап уақыты), енгізу және оқыту.
Масштабтау: максималды полка мен диск саны, порттар шектері, контроллерлерді жаңарту опциялары және тоқтатпай кеңейту мүмкіндігі (не істеу қажет екені).

«Инфрақұрылым талаптары» бөлек бөлімінде нақты модельдер немесе минималды сипаттамаларды көрсетуді сұраңыз: коммутаторлар, трансиверлер мен кабельдер, HBA/NIC талаптары, гипервизор нұсқалары және қосымша ПО. Көпіршіктік тұзақ: КП‑дағы цифрлар бір желі түріне негізделіп берілуі мүмкін, ал сіздің серверлік бөлмеде басқа болуы ықтимал.

Соңында КП‑ға қабылдау құжаттарын қосуды талап етіңіз: сынақ әдістемесі, өту критерийлері (мысалы p95 latency белгіленген мәннен жоғары болмауы), есеп форматы (графиктер, логтар), және жеткізуші тарапынан протоколға кім қол қоятыны. Егер жүйелі интегратор арқылы алсаңыз (мысалы, GSE.kz сияқты), алдын ала кім стенд дайындайтынын және тестті қай тарап қайталанатын етіп қамтамасыз ететінін келісіңіз.

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

All‑flash СҚЖ‑ны виртуализация үшін қабылдау тесті — синтетикалық рекордтар үшін емес, сіздің нақты жүктемеңіздегі болжамды latency мен тұрақтылықты растау үшін қажет. Huawei OceanStor Dorado үшін бұл аса маңызды: КП‑дағы сандар жиі «идеал» стендте алынған, ал жоба барысында нұсқалар, баптаулар және фондық операциялар анықтайды.

1) Алдын ала бекіту қажет нәрсе

Стендті қайталанатын ету үшін бәрін жазып қойыңыз. Серверлердің модельдері, HBA және коммутаторлар, FC немесе Ethernet жылдамдығы, қосылу схемасы, гипервизор нұсқасы, драйверлер, multipath және кезек (queue depth) баптаулары. SAN болса, зонирлеу мен жол балансталу саясаты да жазылсын.

Содан кейін жүктеме сценарийлерін келісіңіз. Профиль (кездейсоқ/реттелген, оқу/жазу, блок 4K/8K/64K), прогрев ұзақтығы және тест ұзақтығы, пул толтыру (мысалы 70–80%), және фондық тапсырмалар: снапшоттар, клондау, VM миграциялары, бэкаптар, мүмкін репликация.

Сақтауды конфигурациялау ережелерін де жазып қойыңыз: пулдар мен томдар қалай жасалады, қосылатын саясаттар (thin/thick, дедупликация/қысу, QoS, шифрлау), stripe/segment өлшемі, қанша диск шынайы қатысады. Әдепкі қосылған функциялар да міндетті түрде көрсетілуі керек, әйтпесе нәтижелер салыстырылмайды.

2) Сынақты қалай өткізу керек

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

Стенд пен нұсқаларды бекіту: гипервизор, драйверлер, multipath, желі немесе FC, қосылу схемасы және порт жылдамдықтары.
СҚЖ‑ны дайындау: пулдар, LUN/томдар, саясаттар, қосылған функциялар, мақсатты пул толтыру және тест датасторлары жиынтығы.
Келісілген жүктемелерді іске қосу: синтетика (мысалы, 4K random read/write) және «тірі» VM шаблондары (VDI, SQL, файлдық сервистер), прегревпен және бірдей ұзақтықта.
Метрикаларды жазу: latency (орташа және 95/99 перцентиль), IOPS, өткізу қабілеті, кезек ұзындығы, контроллер жүктемесі, кэш промахтары, снапшоттар және миграциялар кезіндегі үзілістер.
Тұрақтылық пен пиктерді бағалау: latency белгіленген шектеуде ме, latency‑де «пила» жоқ па, бір жол немесе контроллер ақауы кезінде failover қалай өтеді және қалпына келтіргендегі мінезі.

Критерийлер «IOPS X‑тен кем болмауы» емес, «99p latency Y мс‑ден аспауы Z IOPS кезінде келісілген профиль мен фондық тапсырмалар қосылғанда» сияқты болу керек. Бұл орташа сандар әдемі, бірақ пайдаланушылар нақты кішкентай тұрақсыз «тоқтауларды» сезінуі мүмкін жағдайдан қорғайды.

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

All‑flash СҚЖ таңдау және қабылдаудағы жиі қателіктер

Ең жиі кездесетін себеп — тестте прод ортада жұмыс істейтін конфигурация емес нәрсені тексеру. All‑flash СҚЖ стендте жақсы көрсеткіш көрсете алады, бірақ нақты жерде желі, HBA/NIC, драйверлер немесе multipath баптауларына «тап болуы» мүмкін. Соның нәтижесінде даулар СҚЖ туралы емес, шарттардың әртүрлі болуына қатысты болады.

Типтік қателік — «вакуумда тест». Мысалы, OceanStor Dorado тек екі хостқа тік жалғанған, ал жобада коммутаторлар, басқа SFP, басқа оптика ұзындығы және басқа ақаулыққа төзімділік схемасы жоспарланған. Виртуализация кішкентай детальдарға сезімтал: жолдардың теңгерімі бұзылған, таймауттар әртүрлі, ALUA/UA өшірілген, HBA‑дағы кезектер басқа — және latency секіріп кетеді, тіпті паспорттағы деректер бойынша бәрі жақсы болуы тиіс.

Тағы бір тұзақ — салыстырылмайтындарды салыстыру. Бүгін 4K random тест, ертең 8K mixed, кейін 64K sequential. Қосымша пул толтыру деңгейі маңызды: бос жүйе жиі 70–80% толған жүйеден жылдамырақ. Huawei OceanStor Dorado‑ны бәсекелестермен салыстырғанда шарттарды келісімшарт түрінде бекітіңіз: блок, профиль, кезек ұзындығы, VM саны, пул толтыру және қосылған функциялар.

Үшінші қате — пиктегі IOPS‑қа үмтылу орнына тұрақты latency‑ге назар аудармау. Пайдаланушыларға миллиондар IOPS емес, 95 және 99 перцентиль бойынша latency‑дің тұрақтылығы маңызды.

Еңбек үнемдеу туралы «сәттілік»: компрессия мен дедупликация әдемі KPI‑ларды көрсетіп береді, бірақ контроллер CPU‑сына және latency‑ге қалай әсер ететінін тексермей қояды. Синтетикада бәрі жақсы көрінуі мүмкін, ал нақты деректер базасы немесе VDI кезінде күтпеген шыңдар пайда болады.

Қабылдауда жиі деградацияларды тексеруді ұмытады. Шынайы өмірде сынып шығатындар — порт, линк, коммутатор, контроллер, диск немесе жол. Минималды түрде мына жағдайларды тексеріңіз:

бір порт/линк ақауы және VM‑лардың тоқтатылмай қалуы
коммутатор немесе бір fabric ақауы және multipath‑тың дұрыс жұмысы
rebuild/ресинк кезінде деградация және фондық тапсырмалар әсері
пул толтырылғанда және белсенді снапшоттар болғанда мінез
аралас жүктемедегі latency перцентилдерінің тұрақтылығы

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

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

Huawei OceanStor Dorado сатыптаудан бұрын бір бетке не салыстырып, қалай қабылдайтыныңызды жазып қойыңыз. Бұл порттар, сенімділік және latency бойынша «ұқсас» конфигурацияның шын мәнінде өзгеше болу тәуекелін төмендетеді.

Қысқа чеклист, оны КП сұранымына және қабылдау жоспарына қосуға ыңғайлы:

Нақты конфигурацияны бекітіңіз: контроллерлер, лицензиялар, порттар түрлері мен жылдамдықтары, модульдер, дискілер, полкалар және метрикалар өлшенген шарттар (деректер көлемі, пул толтырылуы, дедупликация/қысу қосылған ба, жүктеме профилі).
Протоколдар мен резервтеу схемасын сипаттаңыз: екі FC фабрика немесе екі тәуелсіз IP‑желі, бөлек VLAN, гипервизорда multipath, зонирлеу ережелері және баптаулар үшін жауаптылар.
Қабылдау KPI‑ларын алдын ала келісіңіз: тек орташа latency емес, 95 және 99 перцентильдер, мақсатты өткізу қабілеті мен IOPS, пиктердегі мінез (кезектер, latency‑құйрықтары, деградация VM саны артқанда).
Ақау сценарийлерін қосыңыз: бір контроллер, бір жол, бір коммутатор/fabric ақауы, түйінді қайта жүктеу, диск деградациясы. Әр сценарийге өту критерийлері (ауыстыру уақыты, VM тоқтаусыз болуы, latency‑дің рұқсат етілген өсуі) көрсетілген болуы керек.
Сынақ протоколының шаблонын және артефакттар тізімін дайындаңыз: СҚЖ баптаулар экспорты, multipath параметрлері, прошивка нұсқалары, қосылу схемалары, логтар, скриншоттар, шикі тест нәтижелері және қысқаша қорытынды «өтті/өтпеді».

Келесі тиімді қадамдар: сіздің типтік VM жиынтығыңыз бойынша қысқа PoC өткізу және алдын ала келісілген протокол бойынша қабылдау. Егер ішкі ресурстарыңыз аз болса, жүйелік интеграторды тартыңыз, ол талаптарды құрудан бастап PoC‑ны ұйымдастыруға дейін жобаны толық алып, вендор‑нейтралды түрде көмектесе алады: мысалы, GSE.kz сияқты жүйелік интегратор алғашқы талаптарды дайындап, KPI‑ларды келісіп, PoC ұйымдастырып, қабылдауды құжаттармен өткізе алады.