Деректерді сақтау жүйесін таңдау: NAS, SAN немесе объектілік сақтау

Таңдау неден басталады: тапсырма — жүйе түрінен маңыздырақ

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

Жай тілмен айтсақ, деректерді сақтау мен беру үшін үш тәсіл бар.

Файлдық сақтау (NAS) ортақ қалтаға ұқсайды: қолданушылар мен қосымшалар файлдар мен каталогтар арқылы жұмыс істейді. Блочный (SAN) серверге берілетін бөлек диск сияқты, сервер өзі файлдық жүйені жасайды және қолжетімділікті басқарады. Объектілік сақтау деректерді метадеректермен бірге «объект» ретінде сақтайды: үлкен көлемдерге, бэкап пен архивке ыңғайлы, бірақ төмен кідіріс пен диск секілді таныс жұмысты талап ететін жерлерге әрдайым сай емес.

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

СҚЖ: NAS, SAN немесе объектілік сақтау таңдамас бұрын жүктеме туралы минимум деректер жинаңыз. Бірнеше сұраққа жауап беру жеткілікті:

• Қазір қанша дерек бар және 1–3 жылда өсу қандай болмақ?
• Бір уақытта қанша қолданушы немесе сервер жұмыс істейді?
• Не маңыздырақ: жауап беру уақыты ма әлде терабайтқа баға ма?
• Қандай тоқтап қалу қабылданады және екі контроллер, репликация, кластерлер керек пе?
• Бэкап қалай ұйымдастырылған: жиілігі, көшіру терезесі, сақтау мерзімі?

Қарапайым мысал: мектепте немесе ауруханада құжаттар үшін ортақ қалталар, виртуализация сервері және зерттеулердің ұзақ архиві болуы мүмкін. Қалталарға көбіне NAS жеткілікті, VM-ға SAN тиімдірек, ал архив пен бэкапқа объектілік сақтау үнемдірек. Интеграторлар, соның ішінде GSE.kz, әдетте тапсырмалар бойынша дәл осылай бөліп алып, одан кейін платформа, желі және бюджет таңдайды.

NAS, SAN және объектілік: терминдерсіз қысқа салыстыру

Үшеуі де бір сұраққа жауап береді: деректерді қайда сақтау керек. Айырмашылық — қосымшалар олармен қалай жұмыс істейді және қандай желі керек. «СҚЖ таңдау: NAS, SAN немесе объектілік сақтау» тақырыбында атауларға емес, сценарийлерге көңіл бөлу пайдалы.

NAS: ортақ файлдар үшін ең оңай

NAS-ты көбіне адамдар мен бөлімдер үшін ортақ қалталар қажет болғанда таңдайды: құжаттар, жобалар, сканерленген файлдар, медиа. Оның артықшылығы — түсінікті баптау және жылдам іске қосылу.

Шектеу — өте сұранысты жүктемелерде NAS әрқашан жақсы көрінбеуі. Көптеген кішкентай операциялар мен жоғары бәсекелестік болса, бұл әсіресе білінеді. Критикалық VM немесе ауыр дерекқорларды ұстаған кезде бұл проблема орын алуы ықтимал.

SAN: тұрақты жылдамдық пен кідіріс маңызды болғанда

SAN көбіне виртуализация және дерекқорлар үшін таңдалады, себебі ол болжамды кідірістер мен 24/7 жоғары жүктеме үшін жасалған. Бірақ енгізу құны әдетте жоғары: желі күрделі, баптауларға талап көп, тәжірибесіз адам қателесу ықтималы жоғары.

Объектілік: үлкен көлемдерге жақсы, бірақ бәріне жарамайды

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

Практикалық бағдар:

• Файлдар мен ортақ қалталар — көбіне NAS.
• VM және дерекқорлар — көбіне SAN.
• Бэкаптар — көбіне объектілік немесе NAS (егер көлем аз болса).
• Жылдарға арналған архив — көбіне объектілік.

Мысал: клиникада суреттер, құжаттар және виртуалдық серверлер бар. Суреттер мен қалталар NAS-та жақсы, виртуализация мен халықтық жазба базасын SAN-да ұстау логикалық, ал резервтік көшірулер мен ескі зерттеулер архивке жіберіледі — бұл қымбат «ыстық» орынды босатады.

Файлдар мен ортақ қалталар: NAS қайда жақсы

Егер басты тапсырма — құжаттар, жобалар мен медиа үшін ортақ қалталар болса, NAS әдетте ең түсінікті нұсқа. Қолданушылар файлдарды кәдімгі желі дискісі сияқты ашады, сақтайды, іздейді, ал ИТ құқықтарды топтар мен бөлімдер бойынша баптайды.

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

NAS жүктеме теңсіз және кең көлемде болғанда оңай баяулайды. Типтік сигналдар: мыңдаған кішкентай файлдар (сканерлер, логтар, код), көптеген бір уақытта қосылған клиенттер, белсенді іздеу мен индексация, жиі атауды ауыстыру, көшіру және архивтерді ашу операциялары.

Осындайда тек қуаттырақ NAS емес, деректерді бөлу көмектеседі. Практикалық тәсіл: NAS-та «ыстық» жұмыс қалталарын қалдыру, «суық» файлдарды (ескі жобалар, медіатека, архив) объектілік сақтауға ауыстыру. Объектілік үлкен көлемдер мен ұзақ сақтау мерзімін жеңіл қабылдайды, қолжетімділікті сақтау саясаттары мен рөлдер арқылы ұйымдастыруға болады.

Егер мемлекеттік орган, мектеп немесе клиника үшін инфрақұрылым сатып алсаңыз, NAS-тың жергілікті қолдау және сервистік талаптарға сай келетініне алдын ала көз жеткізіңіз. Қазақстанда бұл жиі техникалық сипаттамадан маңыздырақ болады.

VM және дерекқорлар: неге көбіне SAN басым

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

SAN мұндай сценарийлерде жиі жеңіске жетеді, өйткені ол бастапқыдан блочный қолжетімділік пен басқарылатын өнімділік үшін ойластырылған. Сақтау трафигін негізгі желіден бөлу оңай, жүктемені тұрақты ұстау оңайырақ, өсу жоспарын дәлірек құруға болады. Сондықтан критикалық VM, кластерлер және дерекқорлар көбінесе SAN-да «жаңбырдай» тыныш жұмыс істейді.

Адамдар жиі ұмытатын бағдар: өткізу қабілеті (MB/s) үлкен ретті операциялар үшін маңызды, ал IOPS пен кідіріс — көптеген кішкентай операциялар үшін. Дерекқорлар мен «тірі» VM көбіне IOPS пен кідірісте шектеледі, тіпті MB/s көрсеткіштері жеткілікті көрінсе де.

NAS те VM үшін нұсқа болуы мүмкін, бірақ әдетте белгілі компромистермен. Бұл жүктеме орташа деңгейде болғанда, кідіріс талаптары қатты болмағанда немесе жеңіл пайдалану маңызды болғанда жұмыс істейді. Мұндайда желіні мұқият баптап, шыңдардағы мінез-құлықты тексеру маңызды.

Өзіңізге сұрақ қойыңыз:

• Шаршаған шақтарда болжамды кідіріс керек пе, әлде төмендеу рұқсат етіле ме?
• Бұл көп кішкентай операциялар ма (IOPS) немесе негізінен үлкен файлдар ма (MB/s)?
• Виртуализация хосттары қанша және VM саны қаншалықты тез өседі?
• Сақтау трафигін бөлек желіге оқшаулау мүмкін бе?

Мысал: егер сізде 3–5 хост виртуализация болса, оларға бухгалтерия, пошта және 1С базасы тұрса, таңдау көбіне жұмыс сағаттарында төмен кідірісті қамтамасыз ете аласыз ба деген сұраққа келеді. Мұндай жағдайда SAN болжамдылықты көбірек береді, ал NAS желіге мұқият қарауды және жүктемеге шыдамдылықты талап етеді.

Бэкаптар: резервтеу үшін сақтау қалай таңдалуы керек

Резервтік көшіру үшін СҚЖ түрін сәнге қарап емес, күнделікті жазу қалай жүретініне және қалай қалпына келетіндігіне қарай таңдайды. Бэкаптар үшін рекордтық кідіріс емес, жазудың болжамдылығы, үлкен сыйымдылық, сенімділік және копияларды «өндірістен» оқшаулау маңызды.

СҚЖ таңдамас бұрын мына сұрақтарға жауап беріңіз:

• Түнде қанша дерек жазылады және нақты қандай бэкап терезесі бар?
• Қай қалпына келтіру сценарийі жиі: файл, толық VM, дерекқор ма?
• Копияларды қанша күн/ай сақтау керек және қанша толық нұсқалар қажет?
• Өзгерте алмайтындық (шифрлаушыдан қорғану) керек пе?
• Екінші көшірме қайда: басқа сайт, оқшауланған контур, офлайн ма?

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

NAS бэкаптар үшін ыңғайлы, егер SMB/NFS арқылы репозиторийді тез қою керек болса (офис файлдары немесе шағын VM үшін). Негізгі қауіп — «прод» және копияларды бір контурда араластыру: бір домен, бір құқық жүйесі, бір желі сегменті. Инфекция немесе қате кезінде мұндай копиялар жиі зақымданады.

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

Архив пен ұзақ мерзімді сақтау: объектілік неге тиімді

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

Объектілік сақтау архив үшін ең ыңғайлы опциялардың бірі: көлем өссе де басқару және сақтау саясаттары оңай ұйымдастырылады. Мұнда сақтау түрін жылдамдықпен емес, деректердің өмір сүру мерзімі мен ұстап тұру ережелерімен таңдайды.

Неліктен объектілік архив үшін ыңғайлы

Объектілік тәсілде деректер метадеректермен бірге тәуелсіз объектілер ретінде сақталады. Бұл ұзақ мерзімді сақтау мен саясаттарды басқаруды жеңілдетеді: не 1 жыл ұсталады, не 5 жыл, не жоюға тыйым салу деген сияқты ережелерді енгізу оңай.

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

Архив «жүйесіз қоймаға» айналмауы үшін алдын ала не ойластыру керек

Мәселе жиі құннан емес, деректерді ұйымдастырудан басталады. Архивті іске қоспас бұрын тексеріңіз:

• Қалай іздейсіз: ат бойынша, күн бойынша, келісім нөмірі, пациент немесе жоба бойынша?
• Қандай метадеректер міндетті және кім толтырады?
• Жою және ұстап тұру саясаты: мерзімдер, жоюға тыйым кезеңі, кім тыйымды алып тастай алады?
• Реттеуші талаптар мен аудит: кім және қашан қол жеткізді, не өзгертілді, бүтіндік қалай расталады?
• Шығарудың уақыты: минут не сағатпен есептеледі ме, және шұғыл қажет болса не істеу керек?

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

Желі талаптары: жылдамдық, кідіріс және трафик оқшаулауы

Желі жиі сол тар шеңберге айналады, сондықтан СҚЖ баяулайтын сияқты көрінеді, бірақ мәселе дискіде емес болуы мүмкін. NAS-та өткізу қабілеті мен коммутаторлардың жүктемесі шектейді. SAN-та ең ауыр әсер — кідіріс пен пакет жоғалтулар. Объектілік сақтау үлкен көлемдегі кішкентай операцияларда және ортақ желі арқылы жұмыс істегенде жылдамдықтан тартылады.

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

• 1 GbE — шағын файлдық тапсырмалар мен сирек бэкаптар үшін жарайды, бірақ оңай толады.
• 10 GbE — көп жағдайда NAS пен бэкап үшін негізгі деңгей.
• 25 GbE — NAS-та виртуализация, жылдам бэкап пен репликация үшін жақсы теңгерім.
• 40/100 GbE — көп хосттар, жоғары VM тығыздығы, ірі дерекқорлар немесе бірнеше бэкап ағымдары болғанда қажет.

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

Сақтау, бэкаптар мен қалыпты трафикті VLAN арқылы бөлу немесе бөлек желі жасау көбіне өзіне ақтайды — бұл болжамдылықты береді. Бұл әсіресе бірнеше түрлі жүктемелер үшін NAS, SAN және объектілік араласатын кезде байқалады.

Практикалық кеңестер:

• Сақтау, бэкап және «қалыпты» трафикті VLAN арқылы бөлу.
• Критикалық VM мен ДҚ үшін QoS/приоритетті қосу.
• Қажет жерлерде екі жол, екі коммутатор арқылы резервтеу.
• NIC параметрлері мен MTU-ны тексеріп, CPU-ға қосымша жүктеме келтірмеу.
• Өсуге орын қалдыру: бастапта порт қосу кейінірек «көшіп кетуден» оңай.

Мысал: күндіз қолданушылар NAS-та файлдармен белсенді жұмыс істейді, ал түнде толық бэкап жүреді. Бэкап трафигін оқшаулау немесе оған терезе мен лимит қою жақсырақ, әйтпесе күнделікті файлдар мен қалпына келтіру зардап шегуі мүмкін.

Пайдалану құны: адал салыстыру қалай жүргізіледі

Құнын төлемге шыққан аппараттық шот әдетте нақты шығынға тең емес. Адал салыстыру үшін екі бөлікке бөлінгенді есте сақтаңыз: CAPEX (бір реттік сатып алу) және OPEX (жылдық/айлық шығындар), әсіресе сіз 3–5 жылға таңдау жасасаңыз.

CAPEX — контроллерлер, дисктер, шкафтар, опциялар, кейде бастапқы лицензиялар. OPEX — электр, салқындату, қолдау, дисктерді ауыстыру, әкімші жұмысы және егер архитектура қате болса пайда болатын тоқтап қалулар.

Көбінесе ұмытылатындар: желі (коммутаторлар, порттар, оптика/кабель), лицензиялар мен жазылымдар, стойка мен ИБП, іске қосу және деректер миграциясы, әкімшілік пен мониторинг.

Масштабтау әртүрлі есептеледі. NAS-та дисктер қосып, пулды кеңейту оңай, бірақ бір контроллер шектеуі болуы мүмкін. SAN-та полкаларды кеңейту мен өнімділікті арттыру оңай, бірақ желіні де жаңарту қажет болуы мүмкін. Объектілік сақтау сыйымдылық бойынша көбіне оңай масштабталады (нүктелер қосылды), бірақ орын, қуат және желі жоспарлау қажет.

«Шикі ТБ үшін баға» емес, екі көрсеткішті салыстырыңыз: «пайдалы» ТБ-ге баға және қажетті өнімділікке баға. Пайдалы ТБ — RAID/EC, резервтер, снапшоттар мен нақты дедупликация нәтижесін ескергеннен кейінгі сыйымдылық.

Мысал: сізге бэкаптар үшін 200 ТБ және VM үшін 30 ТБ жылдам дискі қажет. Тек сатып алу сомасына қарағанда «универсалды» SAN ыңғайлы көрінуі мүмкін. Бірақ SSD, порттар мен қолдауға кеткен шығындарды есептеген соң, бэкаптар объектілік немесе бөлек NAS-қа ауыстыру тиімдірек, ал SAN-ды виртуализацияға қалдыру — экономикалық тұрғыдан әділ шешім.

Қалай таңдау керек: ИТ пен бизнестің қадамдық жоспары

Дұрыс таңдау деректер күнделікті қалай қолданылатынынан басталады. ИТ пен бизнес бір тілде сөйлесуі үшін қарапайым ережелерге келісып, оларды нақты тапсырмаларға тексеріңіз.

5 қадамдық жоспар

1. Барлық жүктемелерді жинап, оларды «температураға» бөлу: күнделікті тез қажет ("ыстық"), әлде арзан әрі сирек қолданылатын ("суық").

2. Қалпына келтіру талаптарын қарапайым сөзбен бекітіңіз (RPO/RTO мәндері): қанша деректі жоғалтуға болады және апаттан кейін қанша уақытта қызмет қалпына келуі керек.

3. 1–3 жыл ішіндегі деректер өсімін және сақтау ережелерін есептеңіз: бэкаптардың неше күн/жыл сақталатыны, құжаттарды қанша жыл сақтау керек, ненің жоюға тыйым салынатыны және ненің архивке ауыстырылатыны.

4. Архитектураны таңдаңыз (бір тип пе әлде гибрид) және желіні тексеріңіз: қай жерде кідіріс маңызды, қай жерде құқықтар ыңғайлығы маңызды, қай жерде сыйымдылық пен көшіру терезелері шешеді.

5. Сатып алудан бұрын тест өткізіңіз. 2–3 типтік сценарийді тексеріңіз: VM іске қосу, ірі файл топтарын көшіру, түнгі бэкап және қалпына келтіру. Мысалы, аурухана немесе мемлекеттік орган үшін критикалық жүйені қаншалықты жылдам көтеруге болатынын және жұмыс сағаттарында желінің қалай мінез көрсететінін тексеру логикалық.

Интеграторлар сияқты GSE.kz мұндай пилотты сіздің сценарийіңіз бойынша ұйымдастырғанда, шешім қағаздағыдай емес, нақты жұмыс істейтінін көруге болады.

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

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

Қате 1: архив пен бэкап үшін «ең жылдам» сақтау

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

Қате 2: бәрін бір массивке жинау

VM, ортақ қалталар және бэкап бір жерде болғанда қақтығыстар пайда болады: түнгі бэкап IOPS-ты жұлып алып, таңертең қолданушылар баяулайды, ал дерекқор кідірістен зардап шегеді. Егер бәрін бірге ұстайтын болсаңыз, басымдықтар, лимиттер мен бөлек пулдар қоюды алдын ала жоспарыңыз және шарықтау уақытына қалай реакция беретініне тексеріңіз.

Қарапайым ереже: критикалық сервистер (VM, ДҚ) бэкаптың не істеп жатқандығына тәуелді болмауы тиіс.

Қате 3: желіні бағаламау

«Бізде 10GbE бар» — қағаздағы жылдамдық өмірдегі тұрақты өткізу қабілетіне тең емес. Төмендеулер коммутаторлардың шамадан тыс жүктелуінен, пайдаланушылардың жалпы трафигінен, қате MTU-дан, резервтеу жолдарының болмауынан туындайды. SAN пен виртуализация үшін кідіріс пен болжамдылық әсіресе маңызды.

Қате 4: өсімге жоспар жоқ

Сақтау жиі «керекше» таңдалады, ал бір жылдан кейін камералар, жаңа VM, көп көшірмелер және сақтау мерзімі ұлғаяды. Өсім жоспары жоқ кезде архитектураны ауыстырып, деректерді көшіру және қызметтерді тоқтату қатері ұлғаяды. Алдын ала минимум: сыйымдылық өсуі, IOPS өсуі және неше көшірме/нұсқа нақты сақталатындығын есептеу.

Қате 5: бэкаптар бар, бірақ қалпына келтіру тексерілмейді

Көшірмелер айлар бойы сәтті жасалуы мүмкін, бірақ қалпына келтіру кезінде істен шығуы мүмкін. Ереже енгізіңіз: қалпына келтіруді тұрақты тексеру (кемінде таңдап алынған түрде) және RPO/RTO бақылауы. Оңай сценарий: айына бір рет тестілік VM-ды бэкаптан көтеріп, қызметтің шынайы іске қосылатынын тексеріңіз.

Жылдам чек-лист, мысал және келесі қадамдар

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

• Тапсырмалар: файлдар, VM, ДҚ, бэкаптар, архив — қайсысы жылдамдықты талап етеді, ал қайсысы тек сенімді сақтауды қажет етеді.
• Көлем және өсу: қазір қанша ТБ, 12–24 айда қанша болады, қолданушылар немесе VM саны қалай өзгереді.
• RPO/RTO: қанша деректі жоғалтуға болады және қанша уақытта қалпына келу қажет.
• Желілік мүмкіндіктер: сақтау үшін бөлек желі/порттар бар ма, қандай жылдамдықтар, төмен кідіріс маңызды ма.
• Эксплуатация: лицензиялар, дисктер, кепілдік/сервис, кеңейту қоры, кім күтіп ұстайды.

Мысал: орташа ұйымда бөлімдер үшін ортақ қалталар, 2–3 виртуализация хосты 30–60 VM үшін, күнделікті бэкаптар және құжаттардың 5 жыл архиві бар. Мұнда көбіне бір тип емес, комбинация шығады: NAS ортақ қалталарға, виртуализация үшін NAS немесе SAN (кідіріс талаптарына байланысты), ал бэкап пен архив үлкен көлемде экономиканы жақсарту үшін объектілік сақтау пайдаланады.

Шешімді іске асыру үшін:

• енгізу деректерін жинаңыз: ағымдағы жүктемелер, өсу болжамы, RPO/RTO, желі және орын (стойка, қуат) шектеулері;
• мақсатты архитектураны сызбаға түсіріңіз: не қайда орналасады, қандай желілік арналар қажет, қай жерде трафик оқшауланады;
• СҚЖ-ның пайдалану құнын салыстырыңыз: «железо» + желі, қолдау, кеңейту қоры, персонал талаптары;
• тәуекелдерді тексеріңіз: бір нүктелі ақаулар, шифрлаудан кейін қалпына келтіру, бөлшектерді ауыстыру мерзімі.

Егер таңдау мен жобалау кезеңінде көмек қажет болса, GSE.kz жүйелік интегратор ретінде сақтау және желі архитектурасын талқылауға және стойкалық серверлер S200-ді қоса ұсынуға дайын.