СХД-ге арналған сақтау желісі: iSCSI, FC немесе NVMe-oF — мифтерсіз

Неліктен дәл сақтау желісін таңдау керек, жай ғана барға қосылмай\n\nСХД үшін желіні «мода үшін» немесе ең жылдам протокол үшін таңдамайды. Оны сол кезде таңдайды, коли бизнестен болжамды кешігулер, түсінікті сенімділік және жүктеме астында тұрақты жұмыс талап етіледі. Бір массив тестте жақсы көрінуі мүмкін, бірақ өндірісте серверден СХД-ға дейінгі жолдың қалай құрылғанына байланысты күтпеген түрде төмендеуі мүмкін.\n\nСақтау жүйесі көбінесе оқшауланбаған. Нәтижеге свитчтер, кезектер мен буферлер, порттардың шамадан тыс жүктелуі, әдеттегі трафикпен бәсекелестік және серверлер мен гипервизордың сұрауларды қалай жасайтыны әсер етеді. Сондықтан «бізде 10/25/100G бар — бәрі жылдам болады» логикасы жиі жұмыс істемейді. Өткізу қабілеті мен кешігулер — әр түрлі ұғым, ал сақтауда әдетте кешігулер маңыздырақ.\n\nСондай-ақ сенімділік факторы бар. Қалыпты корпоративтік желіде ақау «бір-екі секунд байланыс жоқ» ретінде көрінуі мүмкін. Ал сақтау үшін бұл ілігіп қалған виртуалдық машиналар, ұзақ rebuild-тар, файлдық жүйе қателері және күйзелісті техникалық терезелерге айналуы мүмкін. Сондықтан iSCSI vs Fibre Channel туралы пікірталастар жиі «қайсысы жақсы» туралы емес, желіден қандай деңгейдегі болжамдылық пен жауапкершілікті күтесіз деген сұрақ туралы.\n\nТаңдамас бұрын басымдықтарды анықтау пайдалы. Көбіне енгізу жеңілдігі, иеліктің құны (жел hardware, лицензиялар, қолдау, оқыту), шың уақытындағы кешігулерге қатысты SLA, 2-3 жылға масштабтау жоспары және жергілікті мамандардың қолжетімділігі маңызды болады.\n\nОңай мысал: екі бөлімше бір Ethernet-желіні бөліседі. Күні бойы резервтік көшірулер мен бейнебақылау іске қосылады, және СХД-дегі база баяу жауап бере бастайды, ал массив сау. Формально проблема «желіден», бірақ бизнес үшін бұл әлі де сақтау мәселесі. Сондықтан СХД үшін транспортты архитектураның бір бөлігі ретінде таңдаған жөн, «бар тұрғанға қосамыз» принципімен емес.\n\nИнтеграциялық жобаларда өсу және қатал қолдау талаптары бар кезде алдын ала таңдалған желі моделі қайта құрулардың алдын алады. Сіз бірден түсінесіз: команда қандай нәрсені өз күшімен ұстай алады, және қай жерде тар мамандық пен жоғары деңгейлі сервис қажет болады.\n\n## Үш нұсқа қысқаша: iSCSI, Fibre Channel, NVMe-oF\n\nКөбінесе үш тәсіл салыстырылады: iSCSI, Fibre Channel және NVMe-oF. Барлығы бір міндетті шешеді: серверлер мен массив арасында блочтық деректерді сенімді жеткізу. Айырмашылықтар — қандай ортада жұмыс істейтіні, қандай жабдық қажет және қолдауға қанша күш кететіні.\n\n### iSCSI: Ethernet арқылы блочтық қолжетімділік\n\niSCSI — бұл SCSI-командаларының TCP/IP-қа оралған түрі, Ethernet арқылы жіберіледі. Артықшылығы анық: таныс коммутаторлар, кабельдер және желі админдерінің дағдыларын қолдануға болады. Кемшілігі де анық: кешігулер мен тұрақтылық желінің конфигурациясына (шамадан тыс жүктелулер, кезектер, пакет жоғалтулар) қатты тәуелді. Сондықтан iSCSI үшін жиі бөлек VLAN немесе тіпті бөлек физикалық желі бөледі.\n\nТиптік сценарийлер: шағын және орташа виртуализация, VM үстіндегі файлдық сервистер, резервтік көшірулер, тестілік контурлар. Дерекқорларға iSCSI жарайды, бірақ көбіне трафикті оқшаулау мен жүктеме астындағы кешігулерді тексеруді талап етеді.\n\n### Fibre Channel: арнайы SAN ретінде тәртіп\n\nFibre Channel (FC) — сақтау үшін арнайы желі: өз коммутаторлары, адаптерлері (HBA) және өз терминологиясы (WWPN, zoning). FC-дің оқшаулануы арқасында өндірісте кешігулерді тұрақты ұстап тұру оңайырақ, әсіресе көптеген хосттар және критикалық сервистер болғанда.\n\nFC үлкен виртуализация кластерлері, транзакциялық дерекқорлар, жоғары I/O шыңдары бар VDI үшін жиі таңдалады. Бастапқы шығындар әдетте жоғары, себебі FC-коммутаторлар мен HBA қажет, бірақ барлығы ережеге сай құрастырылса тосын жағдайлар аз болады.\n\n### NVMe-oF: желі арқылы NVMe қолжетімділігі\n\nNVMe-oF NVMe-дегі қолжетімділікті бір серверден тыс шығаруға мүмкіндік береді. Транспорт әр түрлі болуы мүмкін (мысалы, RoCE немесе TCP), сондықтан жиі шатасу болады: NVMe-oF — бір желі емес, бірнеше нұсқалардың жиынтығы. Оны минималды кешігулер мен жоғары IOPS қажет болғанда, және жылдам SSD-массивтер үшін өсу жоспары болғанда таңдайды.\n\nАжырату үшін ыңғайлы үш деңгейді қарастыру:\n\n- Протокол: iSCSI, FC, NVMe-oF (сервер мен СХД не «айтады").\n- Транспорт: Ethernet (TCP/RDMA) немесе Fibre Channel.\n- Архитектура және төзімділік: екі тәуелсіз желі/фабрика, СХД-ға бірнеше жол, MPIO, коммутаторлар, порттар, кабельдер және қоректендірудің дубляжы.\n\nИнтеграциялық жобаларда әдетте аттары емес, жүктеме профилі мен 2-3 жылға қажетті өсім қоры туралы сұрақтан бастайды. Сол кезде iSCSI, FC және NVMe-oF арасындағы таңдау практикалық сипатқа ие болады, діни сенім тәрізді емес.\n\n## Кешігулер мен өнімділік: адал салыстыру қалай жүргізіледі\n\nЖеліні таңдарда көптеген адамдар «максималды IOPS» және «Гбит/с-дағы жылдамдыққа» қарайды. СХД үшін маңызды — жүйенің кіші операцияларға нақты және болжамды түрде қалай жауап беретіні.\n\nКешігулер тек желіден ғана тәуелді емес. Оларға блоктың өлшемі (4K, 8K, 64K), кезектің тереңдігі (queue depth) және жүктеме профилі (оқу/жазу, кездейсоқ/секвенциалды) әсер етеді. Бір массив 4K random read-та жоғары IOPS көрсетіп, 70/30 аралас жүктемеде әлсіреуі мүмкін, өйткені жазу «қауырғағырақ», кезектер өседі және шекті кешігулер ұзартады.\n\nОрташа кешігулерге емес, тұрақтылыққа қараңыз. Орташа көрсеткішті «әдемі» ету оңай, егер кейде сирек бірақ ұзақ үзілістер болса. Пайдаланушылар дәл соларды байқайды: база ілініп қалуы, VDI лагтері, файл ашуда кешігулер. Сондықтан p95 және p99 көрсеткіштеріне бағыттаңыз және олар жүктеме кезінде қалай өзгеретінін тексеріңіз.\n\nЖелінің әдетте проблемалар енгізетін үш жері бар: шамадан тыс жүктелу, пакет жоғалту және буфердегі кезектер. Шамадан тыс жүктелу көбіне аплинктер жіңішке болғанда (oversubscription) пайда болады. Пакет жоғалту мен қайта жіберу кешігулердің шегін айтарлықтай ұзартады, тіпті порттардың орташа жүктемесі қалыпты болып көрінсе де. Ал тым үлкен буферлер кейде мәселені жасырып, күту кезегін қалыптастырып, сіз микросекундтық күтуді күткен жерге миллисекундтар қосады.\n\nТаңдамас бұрын интегратордан сіздің типтік сценарийіңіз бен серверлеріңізде (CPU және драйверлер) өлшеулерді сұраңыз: хосттағы CPU және драйверлер iSCSI және NVMe/TCP үшін әсіресе маңызды. Сұралатын минималды өлшеулер тізімі:\n\n- бірнеше жүктеме деңгейінде оқу және жазу үшін p95/p99 кешігулер\n- блок өлшемі мен кезек тереңдігін көрсетіп IOPS және өткізу қабілеті\n- коммутатор порттарының жүктемесі және дроптар/қателер бар-жоқтығы\n- хосттар мен контроллерлердегі CPU жүктемесі\n- порт жазылымының схемасы (аплинктерде тар жер бар ма)\n\nМысал: база мен виртуализация кластерде жұмыс істейді. Егер жүктеме өсіп, p99 1-2 мс-тен 10-20 мс-ке көтерілсе, пайдаланушылар «жүгіру» сезінеді, тіпті орташа кешігу төмен қала берсе де. Адал салыстыру кешігулердің шеттері мен шыңдағы мінез-құлқына негізделуі керек, бір рекордтық санға емес.\n\n## Құн: тек порттар мен кабельдер бағасынан басқа не есептеу керек\n\nСақтау желісінің құны сирек «коммутатор + кабельдер» сомасына тең болады. Қанша жобаны бастайтыныңызға, 3-5 жылда қалай өмір сүретініңізге және порттар мен өткізу қабілеті таусылғанда қалай кеңейтетініңізге байланысты тосын жағдайлар шығады.\n\n### Бастапқы төлем: бюджетті не қалыптастырады\n\nБастауда ақша тек жабдыққа ғана емес, үйлесімділікке, қолдауға және тез өсетін «кіші-пайдалануларға» кетеді:\n\n- хосттар үшін адаптерлер (NIC/HBA) және сенімділік үшін олардың саны\n- коммутаторлар, порттар саны, жылдамдық, резервтеу (екі фабрика/екі коммутатор)\n- оптика мен трансиверлер, патч-кордтар, кросс, кейде трассалар мен монтаж\n- лицензиялар мен қолдау келісімдері (СХД және коммутатор жағында)\n- пусконаладка: жобалау, multipath, тесттер, құжаттама\n\nЕгер стойкаларда бұрыннан дамыған Ethernet болса, iSCSI-ға (және Ethernet үстіндегі кей NVMe-oF варианттарына) кіріс деңгейі жиі төмен болады. FC бастапқыда жиі қымбат, себебі бөлек инфрақұрылым қажет, бірақ ол қажет жерлерде эксплуатацияның болжамдылығын береді.\n\n### Эксплуатацияда не қымбат болады\n\nЭксплуатацияда порт бағасындағы айырмашылық жиі тоқтаулар мен ұзақ диагностикадан жоғары шығын әкеледі. Қымбат болатын — «жаттық уақыттағы» деградация мен себебін анықтау уақыты.\n\nӘдетте шығындар тоқтауларда, мәселені табудың қиыншылығында (егер команда сирек көрген SAN-технологиясы болса), порттар мен өткізуге резервтің болмауында және сервис шығындарында (модульдер мен оптиканы ауыстыру уақыты мен құны, жергілікті қолдаудың болуы) шоғырланады.\n\nПростой мысал: дәл қазіргі порттарға сай коммутатор сатып алды. Бір жылдан кейін бірнеше сервер мен полка қосқанда бос порттар жоқ. Коммутаторды ауыстыруға немесе екіншісін сатып алуға тура келді, ал миграция мен жұмыс терезелері бірден қосымша шығын әкелді. Ал егер бастапқыда резерв болысатын болса, бұл әлдеқайда арзан болар еді.\n\n### Қай жерде үнемдеуге болады қауіпсіз түрде және өсімді қалай есептеу керек\n\nҚауіпсіз үнемдеу — көбіне стандарттау және жоспарлауда, резервтен бас тартуда емес. Әдеттегі нұсқалар: егер кабель инфрақұрылымы жылдамдық пен сапа бойынша жарайтын болса, оны пайдалану; Ethernet-жабдықты стандарттау, егер бұл сенімділікті төмендетпесе; және кеңею жолын алдын ала келісу.\n\nӨсу кезінде сіз тек сатып алуды емес, «кеңейтудің бағасын» да есептеңіз: жаңа түйіндер мен ёмкілікті қосқанда желіні толық қайта конфигурацияламай, ұзақ тоқтатусыз жасай аласыз ба. Екі кезеңді жоспар сұрау пайдалы: бастапқы конфигурация және порттар, жылдамдықтар, резерв пен жұмыс терезелері бойынша анық кеңейту сценарийі. Сондай-ақ сервис моделін алдын ала талқылаңыз: кім запчастыларды ұстайды, кім барып жөндейді және серверден СХД-ға дейінгі бүкіл тізбек үшін кім жауап береді.\n\n## Мамандар мен қолдау қолжетімділігі: жергілікті шынайылық\n\nСақтау технологиясы кешігулерден басқа, қолдануға болатын мамандарға да әсер етеді. Тіпті сандық көрсеткіштері мінсіз архитектура да инцидент кезінде ешкім «қай жерде ақау» екенін жылдам түсінбесе, проблемаға айналады: коммутатор ма, массив пе, хост па, әлде конфигурация ма.\n\nӘдетте үш рөль қажет: желі инженері (VLAN/VRF, QoS, MTU, жоғалтылар мен кешігулер диагностикасы), СХД инженері (multipath, саясаттар, алертер) және виртуализация админі (datastore/volume, үйлесімділік, жаңартулар). Шағын командада бұл бір адам болуы мүмкін, бірақ компетенциялар сақталуы тиіс.\n\nНарықта Ethernet-та тәжірибесі бар мамандарды табу әдетте оңай, ал FC бойынша тар мамандар аз. iSCSI көбіне қалыптасқан процестерге тез еніп кетеді: сол коммутаторлар, сол мониторинг құралдары. FC SAN-да жұмыс істеу дағдыларын (zoning, WWN, FC-коммутаторлар мен HBA-лар) талап етеді. NVMe-oF — «жаңа әрі жылдам» тарихы, сондықтан мамандар аз, жобалау тәртібі маңыздырақ.\n\nСирек мамандарға тәуелділікті азайту үшін стандартизация көмектеседі: типтік төзімділік схемалары, конфигурация шаблондары, атау ережелері, кезекшіге арналған runbook және нақты құжаттама.\n\nҚолдауды жабдық сияқты қатаң талқылау керек. Сюрприздерді азайтатын сұрақтар:\n\n- 24/7 кім қабылдайды және критикалық инциденттерге қанша уақытта кіріседі\n- эскалация қалай ұйымдастырылған және вендорларды кім қосады\n- қолдау не қамтиды (жаңартулар, health-check, кеңейту көмегі, инцидент талдауы)\n- жауапкершілік шекарасы қай жерде: желі, СХД, гипервизор, қосымшалар\n- апаттан кейін қандай есептер беріледі (себеп, әрекеттер, профилактика)\n\nЕгер жергілікті және тәулік бойы қолдау маңызды болса, уәде емес, нақты кезекшілік моделін және сервис желісін тексеріңіз. Мысалы, GSE.kz тәулік бойы техникалық қолдауды және Қазақстан бойынша сервис бөлімшелер желісін ұсынады — өңірлік нысандар үшін бұл қағаздағы микросекундтар айырмашылығынан гөрі маңызды болуы мүмкін.\n\n## Практикалық таңдау алгоритмі: артық теориясыз қадамдар\n\nТаңдау сирек протоколдан басталады. Ол сізге не керек екенінен басталады: тұрақты кешігулер, болжамды өсу, түсінікті қызмет көрсету және жұмыс істейтін төзімділік.\n\n1) Жүктемелерді қарапайым тілмен сипаттаңыз. VM үшін тұрақтылық пен шыңдардағы мінез-құлық маңызды, дерекқорлар p95/p99-қа сезімтал, файлдық сервистерге әдетте өткізу қабілеті мен сыйымдылық маңызды. Белгілеп қойыңыз, қанша тоқтау рұқсат етіледі және бір жолдың сәтсіздігін не басынан өткізеді.\n\n2) Қазіргі көрсеткіштерді жинаңыз, әйтпесе салыстыру миф деңгейінде болады. IOPS пен MB/s керек, бірақ жүктеме астындағы кешігулермен бірге.\n\nБастапқы үшін минималды метрикалар:\n\n- шыңда және әдеттегі күнде IOPS пен өткізу қабілеті\n- оқу мен жазуға арналған p95 кешігулер\n- блоктың өлшемі мен түрі (4K, 8K, 64K)\n- ай сайынғы деректер мен жүктемелер өсуі\n- қазір қанша хост бар және 2-3 жылдан кейін қанша болады\n\n3) Төзімділік талаптарын бекітіңіз. Шынайы өмірде бұл әдетте екі тәуелсіз жол: екі коммутатор немесе екі фабрика, хосттарда multipath, тоқтаусыз жаңарту сценариі және міндетті отказ тестілері.\n\n4) Мақсатты архитектураны таңдаңыз және масштабтауды жоспарлаңыз. Желінің толық ауыстырусыз кеңейетініне көз жеткізіңіз: порттарды қосу, жылдамдықтарды апгрейдтау, екінші коммутатор, серверлерге қосымша адаптер орнату.\n\n5) Пилот жасаңыз және қабылдау критерийлерін алдын ала келісіңіз. 2-3 типтік VM мен тестілік дерекқор көтеріп, шың уақыттағы жүктемені жіберіп, p95/p99, бір линк/свитч/контроллер сәтсіздігі кезіндегі мінез-құлық пен қалпына келу уақытын тексеріңіз.\n\nЕгер интеграторға «жылдам істегіміз келеді» деген арыз емес, нақты метрикалар мен қабылдау критерийлерін берсеңіз, iSCSI vs FC vs NVMe-oF талқылауы анағұрлым нәтижелі болады. Мұндай жобаларда серверлік бөлік, интеграция және қолдауды бір орында жаба алатын мердігер ыңғайлы — мысалы, GSE.kz жабдық өндірушісі әрі жүйелік интегратор ретінде осы қызметті ұсынады.\n\n## Қашан iSCSI, қашан Fibre Channel, қашан NVMe-oF таңдау керек\n\n«Әдепкі таңдау» жоқ: шешім сіз қандайды енгізіп, ұстай алатыныңызға және тосын жағдайсыз кеңейте алатыныңызға тәуелді.\n\niSCSI — таныс Ethernet-те жылдам іске қосу қажет болғанда таңдалады. Орташа масштабтағы виртуализация, файлдық сервистер, резервтік көшірулер, тест орталар мен филиалдар үшін жиі қолайлы. Трафиктің дұрыс сегментациясы және желі тәртібі болғанда жақсы жұмыс істейді.\n\nFibre Channel — болжамдылық пен оқшаулануы маңызды, және тоқтау қымбат болғанда таңдалады. Қаржы, медицина, мемлекеттік қызметтер сияқты критикалық жүйелер үшін типтік шешім.\n\nNVMe-oF — жылдам массивтер мен минималды кешігулер қажет болғанда орынды: жоғары жүктемелі дерекқорлар, аналитика, тығыз VDI-кластерлері, кейбір AI және деректерге бағытталған тапсырмалар. Бірақ ол тек инфрақұрылым мен команда дайын болғанда ғана мағыналы болады.\n\nЖедел таңдау бойынша нұсқаулық: \n\n- жылдам старт пен біртұтас желі қажет болса — көбіне iSCSI\n- максималды болжамдылық пен оқшаулау керек болса — көбіне Fibre Channel\n- шың кешігулер керек болса — көбіне NVMe-oF\n\nСатып алудан бұрын тікелей сұрақтар қойыңыз, сонда «жеткізілгеннен кейін үйлеспейді» дегенді болдырмайсыз:\n\n- қандай хосттар мен ОС қолданылады (драйверлар, firmware нұсқалары)\n- multipath қалай ұйымдастырылады және серверлерде баптау кімнің жауапкершілігінде\n- коммутаторлар, HBA/NIC және СХД үйлесімділігі бойынша қандай шектеулер бар және олар қалай расталған\n- нәтижені қандай метрикалармен өлшейсіз (кешігулер, IOPS, тест профилі)\n- 12-24 айға өсім жоспары қалай көрінеді (порттар, жылдамдықтар, миграциясыз кеңейту)\n\nҚазақстанда жұмыс істесеңіз, шешімді жергілікті кім қолдайтынын және инженерлер қаншалықты тез келетінін бөлек анықтаңыз. Интеграциялық жобаларда бұл көбіне қағаздағы сандардан маңыздырақ.\n\n## SAN енгізудегі жиі қателіктер және оларды қалай болдырмау керек\n\nSAN-тағы қателіктер сирек «барлығы бірден бұзылды» деген түрде болады. Көбіне бұл тұрақсыз кешігулер, шыңдағы тосқауылдар және ұзақ уақыт анықталатын апаттар.\n\n### 1) Трафикті араластырып, оны бақыламаған\n\nСақтау офис желісімен бірдей коммутаторларда және VLAN-дарда тұрса, және сол жерде бэкаптар, жаңартулар мен репликациялар жүрсе, буферлер мен өткізуге бәсекелестік басталады. Шешімі — тәртіп: сақтау үшін бөлек сегмент, iSCSI үшін айқын QoS саясаты, бэкаптарға шектеулер мен терезелер, және сақтау сегментіне артық трафиктің түспеуін тексеру.\n\n### 2) Төзімділікті «ауызша» жоспарлау\n\nБір коммутатор немесе бір жол ғана бар, немесе жолдар бар, бірақ олар ешқашан нақты отказ кезінде тексерілмеген. Екі тәуелсіз жол, коммутаторлар мен қуат бойынша бөліну, хосттарда дұрыс multipath және міндетті отказ тестілеулерін жалғыз сөзбен емес нақты іске асырыңыз.\n\n### 3) Таңдау презентацияларға қарап, өз метрикаларға емес\n\nСлайдтағы IOPS пен микросекундтар сіздің профильді ескермеуі мүмкін: блок өлшемі, жазудың үлесі, кезек тереңдігі, виртуализация мен көрші тапсырмалардың әсері. Өзіңіздің өлшенген мақсаттарыңызға сүйеніңіз және қысқа пилот жасаңыз немесе ағымдағы жүйеден адекватты статистиканы жинаңыз.\n\n### 4) Өсімді ойламаған\n\nSAN жиі порттар, лицензиялар, стойкадағы орын, оптика түрлері немесе HBA/NIC-тың PCIe-слоттарының шектеуіне ұшырайды. Жаңа хосттарды алдын ала қосу жоспары болсын.\n\nҚысқа тексеру алдын ала:\n\n- 30-50% өсімге арналған порттар мен аплинктер запасы бар ма\n- хосттарды жүйені тоқтатпай қалай қосуға болатыны анықталған ба\n- кабельдер/оптика талаптары және үйлесімділік бекітілген бе\n- бэкап пен репликация үшін терезелер мен лимиттер келісілген бе\n- отказ сценарийлері (порт, свитч, контроллер, линк) тестіленген бе\n\n### 5) Баптап қойып, құжаттама жасамаған\n\nАлты айдан соң әкімші ауысады да, ешкім қайда қандай WWPN/IQN, VLAN, зоналар, firmware нұсқалары және multipath неге осылай бапталғанын білмейді. Бұл кез-келген апаттың уақытын ұзартады.\n\nШынымен көмектесетін минималды құжаттама:\n\n- қосылым схемасы (физикалық және логикалық) және порттар тізімі\n- хосттар кестесі: IQN/WWPN, IP, VLAN, рөлдер\n- zoning/masking ережелері және атау принциптері\n- firmware, драйвер нұсқалары, multipath параметрлері\n- тест нәтижелері: кешігулер өлшемдері және отказ сценарийлері\n\nПрактикалық мысал: ауруханада түнгі бэкаптар өткізілуге тартып, таңертең VDI баяулаған. Мәселені массив ауыстыру арқылы емес, сақтау сегментін бөлу, бэкапқа лимит қою және бірқатар хосттарда multipath қате бапталғанын анықтайтын отказ тесті арқылы шешті.\n\n## Интеграторға сатып алудан бұрын сұрау керек сұрақтар чек-листі\n\nИнтегратор «әдеттегідей жасайды» емес, нақты жүктеме мен өсуге сай шешім ұсынуы үшін талаптарды сұрақтар арқылы бекітіңіз.\n\n### Жүктеме, SLA және архитектура туралы\n\n- қандай қосымшалар мен I/O профилдері есепке алынған және олармен қалай расталған (өлшеулер, пилот, гипервизор статистикасы)\n- бастау кезінде қанша хост пен массив болады және 24-36 айға болжам қандай (көлем, IOPS, өткізу қабілеті, порттар)\n- қандай SLA қажет: рұқсат етілген тоқтау уақыты, тоқтаусыз қызмет көрсету, RPO/RTO, қандай отказ түрлері өтуі тиіс (порт, свитч, контроллер, ғимарат)\n- LAN-нан физикалық оқшаулау керек пе немесе логикалық сегментация жеткілікті ме және шекараны кім бақылайды\n- қанша жол (multipath), қандай жылдамдықтар мен порт типтері хосттар мен СХД-да, қай жерде тар шеңберлер болуы мүмкін (PCIe, oversubscription, лицензиялар)\n\n### Эксплуатация, тесттер және жеткізу туралы\n\n- енгізуден кейін шешімді кім қолдайды және тапсырыс берушінің тарапындағы қандай компетенциялар керек\n- не мониторингтеледі (порттар, кезектер, кешігулер, жоғалту, қателер), апат шектері қандай және кім жауап береді\n- авариялық сценарийлер қалай тексеріледі (линк, свитч, контроллер, жаңартулар) және тест жоспарымен қабылдау акты беріле ме\n- елде запчастылар бар ма және қолдау режимі қандай (24/7, жауап уақыты, қалпына келтіру уақыты)\n- 2-3 жылға жаңарту және кеңейту жоспары қалай: нұсқалардың үйлесімділігі, жұмыс терезелері, кезең-кезеңімен кеңейту тоқтаусыз\n\nЕгер мердігер интегратор және өндіруші рөлін бірлесіп атқаратын болса (GSE.kz сияқты), запчастылар, шығу және бүкіл тізбекті қолдау кімде екендігін бөлек келісіңіз, «жиһаздар бойынша» емес, толық жауапкершілік ретінде.\n\n## Мысал таңдау: инфрақұрылымды кеңейту және ауыртпалықсыз миграция жоспары\n\nСценарий: өңірлік мемлекеттік орган немесе банк виртуализацияны кеңейтеді, жаңа сервистер (VDI, базалар, файлдық шейрлар) іске қосады, ал ескі сақтау жүйесі кешігулер мен қызмет көрсету терезелерінде шектеліп қалды. Талап күшейіп, тоқтаулар мен деректер жоғалуы қабылданбайды.\n\nШектеулер көбіне практикалық: бюджет бекітілген, мерзім тығыз, және кей технология бойынша (әсіресе FC немесе NVMe-oF) штатта мамандар жоқ. Сол уақытта 24/7 қолдау және 2-3 жылдық өсім жоспары қажет, сонда сақтау желісін жарты жылдан кейін қайта құру қажет болмайды.\n\nПрактикалық жол — қабылдау критерийлері алдын ала бекітілген қысқа пилот. Мысалы: шың сағаттағы 95-перцентиль кешігу, бэкаптар кезінде елеулі тереңдетулер болмауы, бір линк/свитч/контроллер отказында мінез-құлық және эксплуатация күрделілігі, команда біліктілігінің талаптары.\n\nОдан әрі нұсқалар миграция тәуекелдері бойынша салыстырылады. Егер қазір iSCSI болса және жұмыс істеп тұрса, алдымен оны түзету (сегментация, резервтеу, QoS, тексерілген коммутаторлар) ақылға қонымды; NVMe-oF келесі кезең ретінде қарастырылсын — минималды кешігулер бойынша нақты қажеттілік пен команда дайын болған кезде. FC мағынасы бар егер сізде осы тәжірибе мен процестер болса және оқшаулану мен болжамдылық икемділіктен маңыздырақ болса.\n\nМиграцияның ауыртпасыз болуы үшін екі қадамдық жоспар жасаңыз: алдымен сыналмаған емес жүктемелерді көшіру, сосын критикалық жүйелерді кезең-кезеңімен көшіру және откат терезесін ұстау. Алдын ала жауапкершілік шекарасын келісіп қойыңыз: СХД, желі, гипервизор, multipath, мониторинг.\n\nӘдетте апталарды үнемдейтін әрекеттер: өлшенетін критерийлері бар ТЗ дайындау, мақсатты архитектураны мақұлдау және өндірістік жүйеге ұқсас тест стенд жинау. Осы кезеңде өндіруші мен интеграторды бірлесіп тарту ыңғайлы: серверлер мен СХД-ны жүктеме профиліне сай таңдап, желіні жобалап, кейінгі қолдауды қамтамасыз ету. Қазақстанда мұндай форматты көп жағдайда GSE.kz жүйелік интегратор және сервер өндірушісі ретінде іске асырады — жеткізу мен сервисті бір жауапкершілік аясында қалдыру үшін.