Ведомствоға арналған гиперконвергентті инфрақұрылым: СХД-пен салыстыру

Таңдау қайдан басталады: мәселе мен шектеулер

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

Сондықтан таңдау туындайды: гиперконвергентті инфрақұрылым (HCI) немесе классикалық "серверлер плюс СХД" схемасы. Қағазда екеуі де виртуализация мен сақтау мәселесін шешеді. Практикада оларды іске қосу жылдамдығы, қызмет көрсету құзыреттері және жүктеме өскендегі өмір сүруі бойынша айырмашылықтары болады.

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

Мысалы. Егер қысқа терезеде 60–80 виртуалдық машинаны миграциялауды жоспарласа және SAN-ға маманданған сирек кездесетін мамандарға тәуелді болғыңыз келмесе, HCI логикалық шешім сияқты көрінуі мүмкін. Егер СХД бойынша жетілген командаңыз бар және сақтау жүйесін есептеулерден бөлек масштабтағыңыз келсе, классика әдетте икемділікті көбірек береді.

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

HCI дегеніміз қарапайым тілмен

HCI — есептеулер, сақтау және виртуализация бір кластерде біріктірілген тәсіл. Жекелей серверлер мен бөлек СХД орнына бірнеше бірдей типтегі түйіндер қолданылады, олар виртуалдық машиналарға ортақ ресурстар пулын береді.

Типтік HCI жүйесі түйіндерден (CPU, RAM және дискілері бар серверлер), түйіндер арасындағы деректер алмасуға арналған желіден және басқару бағдарламалық қабатынан тұрады. Бұл қабат барлық түйіндердің дискілерін ортақ сақтау ретінде біріктіріп, бір консоль арқылы басқару ұсынады: қай жерде ВМ жұмыс істейді, қанша орын бос, қай түйін жүктелген.

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

HCI көбінесе типтік виртуалдық серверлер, VDI, тестілік және резервтік контурлар, шағын ведомстволық ЦОДтар және бөлек СХД командасы жоқ қашықтағы нүктелер үшін таңдалады.

Маңызды: HCI — бұл «сиқыр» емес, дәл сол ЦОД-ты басқа тәсілмен құрастыру. Процессорлар, жад, дискілер, желі және бағдарламалық платформа әлі де таңдалады, тек оларды бір кешен ретінде басқарады.

Классикалық «серверлер плюс СХД» схемасы: қалай ұйымдастырылған

Классикалық виртуалдық инфрақұрылым әдетте қабаттарға бөлінеді: есептеу, сақтау және желі. Серверлер виртуалдық машиналардың жұмысын қамтамасыз етеді, СХД деректерді сақтайды, ал коммутаторлар мен желілік баптаулар бәрін байланыстырады.

Типтік жинаққа гипервизор кластері, бөлек СХД, сақтау трафигі үшін бөлек желі (FC немесе iSCSI) және виртуализация мен бэкап құралдары кіреді.

Қабаттардың бөлінуіне байланысты жауапкершіліктер де бөлінеді: серверлер мен гипервизор администраторы, СХД администраторы, желі инженері, бэкап пен ИБ мамандары.

Классиканың күші ірі ортада байқалады, онда өнімділік пен сыйымдылықты ұсақ-түйек баптау қажет. Дискі жүйесін бөлек кеңейтуге, серверлерді бөлек жаңартуға, RAID деңгейлері мен кэштеуді әртүрлі жүйелерге сай таңдауға болады.

Көпшілік қиындықтар шеттерде басталады. Жаңа ВМ пулын көтеру үшін СХД-да LUN бөлу, зонирлеу немесе VLAN орнату, мультипасинг тексеру, қолжетімділік саясаттары, прошивка мен драйвер үйлесімдігін тексеру қажет, содан кейін сенімділік тесттерін өткізу керек. Қатысушылар мен баптаулар көп болған сайын рөлдер мен жұмыс жоспарын алдын ала бөлу маңызды.

Енгізу мерзімдері: қай жерде жылдам және неге

ИТ-жобаның күнтізбесін көбіне жабдық сатып алудан гөрі бірқатар қадамдар «ұсынғаны» жейді: жеткізу, орнату, қуат пен желіні қосу, баптау, тестілеу, енгізу және актілерді рәсімдеу. Мемлекеттік мекемеде бұған қосымша келісімдер, қауіпсіздік талаптары және формальды тексерістер бар.

HCI әдетте жылдамырақ іске қосылады, өйткені компоненттер аз және кейбір баптаулар шаблон бойынша жүреді. Бірақ бұл артықшылық желі дайын болғанда ғана сақталады: L2/L3 схемасы, VLAN, MTU, арналарды резервтеу және мекен-жай кеңістігі келісілген болуы тиіс. Егер бұлар жоқ болса, «жылдам» кластер бұл артықшылықты тез жоғалтуы мүмкін.

Классикалық схема көп жағдайда ұзаққа созылады: серверлер, СХД, SAN-желі бөлек, үйлесімділіктер мен жауапкершілік нүктелері көп. Тіпті жеткізу жақсы болса да уақыт «стыковкаға» және баптаулардағы ұсақ сәйкессіздіктерді түзетуге кетеді.

Күнтізбені бұзбау үшін не тексеру керек

Жобаны бастамас бұрын мына тармақтарды қарап өткен пайдалы:

• алаң дайындығы: порттар, стойкалар, қуат, салқындату;
• бекітілген желі схемалары, адресация, ИБ және қолжетімділік ережелері;
• миграция жоспары және жұмыс уақытындағы тоқтату терезесі;
• қабылдау-сертификаттау сценарийі және «енгізілді» критерийлері;
• интеграция және алғашқы аптадағы қолдау кімге тиесілі.

Егер өңірлік ведомство виртуалдық инфрақұрылымды 6–8 аптада енгізгісі келсе, желілер мен құжаттар дайын болғанда HCI жиі сәйкес келеді. SAN, зонирлеу және бөлек сақтау контурлары бар жобаларда классика мерзімдері көбіне созылады. Мұндай жобалардағы жеделдеу «желіні дайындау» мен құжаттардан басталады, әдетте «желіден» емес.

Қызмет көрсету және құзыреттер: кім қолдайды

Әдетте таңдау жасайтын факторлардың бірі — қолдау ұйымдастыру мүмкіндігі.

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

Классикада құзыреттер кеңірек. Виртуализациядан бөлек СХД туралы (RAID саясаттары, пулдар, өнімділік), SAN (FC/iSCSI), зонирлеу және жол диагностикасын білу қажет. Бұл қиын емес, бірақ тәжірибе мен уақыт қажет.

Қай нұсқада да негізгі рөлдерді алдын ала анықтау керек: виртуализация, желі, бэкап пен қалпына келтіру (тестілеумен), ИБ (контролдер, журналдар, сегментация), сондай-ақ инциденттер мен өзгерістер процесі.

Шағын ИТ-бөлімшеде HCI ұйымдастыру оңайырақ: бір контур, біркелкі жаңартулар, өсу схемасы түсінікті. Классикада бірнеше вендор мен мердігерге тәуелділік тез пайда болады: серверлер, СХД, желі — әрқайсысына бөлек қолдау қажет.

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

Масштабтау: жүктеме өскенде не болады

Ведомстводағы жүктеме өсуі әдетте жаңа жүйелердің қосылуы, пайдаланушылар санының артуы, мұрағаттар мен журналдардың өсуі және ауыр есептер пайда болуымен көрінеді. Нені өсіп жатқанын — есептеу, сақтау немесе сенімділік талаптары — анықтау маңызды.

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

Классикада өсу бөлек жүреді: қуат жетіспесе серверлерді сатып аласыз, сыйымдылық немесе IOPS жетпесе СХД-ны кеңейтесіз. Бұл өсім тең емес болғанда үнемді болуы мүмкін (мысалы, сақтау көлемі кенеттен артса, ал есептеу өзгермесе).

HCI-дегі жиі даулы мәселе — тек дискілерді көбірек қажет ету. Кей архитектураларда бұл қосымша CPU/RAM бар жаңа түйін сатып алуды талап етеді. Мұны дискіге басым конфигурациялармен немесе бөлек storage тегі түйіндермен шешуге болады, бірақ сатып алудан бұрын нақтылау керек.

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

Экономика және ведомствоға сатып алу: бағадан басқа неге назар аудару керек

HCI мен классиканы салыстырғанда жиі тек жабдық бағасына қарап қалады. Ведомство үшін маңыздысы жалпы иелену құны: енгізу, қызмет көрсету және тоқтаудың тәуекелдері.

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

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

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

Тәуелсіз тағы бір тармақ — жеткізу тізбегінің айқындылығы және ел бойынша сервис: болжамды мерзімдер, жабдықтың шығу тегі және істен шыққанда тез қалпына келу мүмкіндігі. Егер жергілікті құрам талаптары маңызды болса, өндірушінің статусы мен растайтын құжаттарды тексеріңіз. Қазақстанда бұл сатып алуда жиі маңызды: ресми отандық өндіруші мәртебесі мен сертификаттар (ISO 9001, ISO 14001, ISO 45001) бюрократия тәуекелдерін азайтады.

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

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

Мақсаттарды тексерілетін түрде тұжырымдаңыз: «60 ВМ-ді жаңа платформаға негізгі жүйелерді тоқтатпай көшіру», «N+1 деңгейінде сенімділік қамтамасыз ету», «типтік сервисті 1 күнде енгізуді қысқарту». Одан кейін қысқа реттілік:

• Жүктемелік профильді қарапайым метрикалармен сипаттау: ВМ саны, деректер көлемі, жылдық өсу, шың сағаттары, критикалық жүйелер үлесі.
• Шектеулерді бекіту: енгізу мерзімдері, штат пен құзыреттер, оқшаулану талаптары, рұқсат етілген тоқтау терезелері.
• Алдымен бэкап пен DR анықтау: көшірмелер қайда сақталады, қандай RPO/RTO қажет, сайт істен шыққанда қалпына келтіру қалай жүреді.
• 1–2 типтік сервис бойынша пилот өткізіп, тек жылдамдықты ғана емес, қызмет көрсетуді де бағалау: жаңартулар, диагностика, жауап уақыты.
• Қабылдау критерийлерін және миграция жоспарын кері қайтару тәртібімен рәсімдеу.

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

Сценарий мысалы: өңірлік ведомство және серверлік жаңарту

Өңірлік ведомство серверлік бөлмеде бірнеше негізгі сервис ұстайды: файл ресурстары, домен, пошта немесе коллаборация, 1–2 ведомстволық жүйе, есептілік дерекқоры және резервтік көшіру. Штат кішкентай: барлығы 2–3 администратор, желі мен жұмыс орындарын қоса алғанда. Бірнеше сағаттық тоқтау ауыр соққы, ал жұмыстар әдетте түнгі немесе демалыс күндерінде жүргізіледі.

A нұсқасы: HCI-кластер

Типтік бастама — кластерде 3 түйін: есептеу, сақтау және сенімділік бір контурда. Орнату көбіне қысқа жоспарға сыйып кетеді: орнату, кластер баптау, ВМ көшіру.

Жаңа сервис тез іске қосылуы керек болғанда (мысалы, өтініштер порталы немесе видеоконференция жүйесі), уақыт бойынша артықшылық айқын байқалады. Әдетте кластерде ресурстар бөліп, жаңа ВМ орнату жеткілікті, бөлек СХД-мен әуре болмайсыз.

B нұсқасы: серверлер плюс СХД

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

12–18 ай өткенде деректер өссе (скандар, мұрағаттар, базалар), HCI-ге әдетте 1–2 түйін қосып, дискі, CPU және RAM өсімін аласыз. Классикада тек СХД-ны кеңейтуге болады, есептеулерге қол тимей, бірақ лицензиялар, порттар, полкалар және кейде миграциялар жоспарлау керек.

Филиалдар мен қашықтағы нүктелер болғанда HCI-ні шағын кластерлерге көшіріп, басқаруды біркелкі ету оңайырақ. Классикада филиал көбіне бөлек мини-жинаққа айналып, қосымша қолдау ауыртпалығын тудырады.

HCI мен классиканың жиі қателері

Ең жиі кездесетін мәселе — шешімді жалпы уәделерге сүйеніп («HCI оңай» немесе «СХД сенімді») емес, нақты жүктемелер мен процестерге қарап қабылдау.

Жиі кездесетін қателер:

• HCI-ді сақтау профилін түсінбей таңдау. Егер ауыр дерекқорлар, журналдау және тез өсу көп болса, IOPS, кешігу, көлем немесе өсу қарқынының қайсысы маңызды екенін алдын ала анықтау керек.
• Желіні және сенімділік схемасын тексермеу. HCI түйіндері арасындағы дұрыс желі мен өткізу қабілеті тапшылығына өте сезімтал.
• Критикалық және тестілік жүйелерді ерекшелеусіз араластыру. Ресурстарды оқшауламай тест тапсырмалары күтпеген уақытта өнімділікті «жеп қоюы» мүмкін.
• Резервтік көшіруді "кейінге қалдыру". Бэкап терезелері, көшірмелерді сақтау және қалпына келтіру талаптары сатып алудан бұрын анық болуы керек.
• Тек жабдық бағасына қарап салыстыру және енгізу, оқыту мен қолдауды ұмыттыру.

Интегратормен жұмыс жасағанда презентация сұраудан гөрі қысқа жүктеме моделі мен миграция жоспарын сұраңыз. Бұл қауіпті тез анықтауға көмектеседі.

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

Таңдамас бұрын қағазға бірнеше нәрсені түсіру пайдалы. Әдетте 1–2 кездесу жеткілікті, бірақ бұл апталар бойы келісім мен түзетулерден үнемдейді.

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

Минималды тексеру жиынтығы:

• критикалық сервистер сипатталған және жаңарту терезесі бар;
• ағымдағы сыйымдықтар мен өсім болжамы анықталған (және шамамен болғаны жеткілікті);
• сенімділік талаптары бекітілген: түйіннің және сайттың істен шығуы;
• алаң дайын: желі, қуат (UPS, енгізулер), стойкалар және салқындату;
• резервтік көшіру сценарийі жазылған, жауапты тұлғалар мен тестілеу бар.

Рөлдерді бөлек келісіңіз: платформа әкімшілігін кім атқарады, 24/7 инциденттерді кім қабылдайды, вендормен байланыс пен компоненттерді ауыстыру мерзімін кім бақылайды. Мемлекеттік ұйымдарда мұндай келісімдерсіз енгізу жиі созылады.

Келесі қадамдар: жобаны қалай дайындап, енгізуді ұзартпау

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

Одан кейін 2–3 нұсқаны (HCI, классика, аралас) бір критерийлер кестесі бойынша салыстырыңыз: мерзімдер, тәуекелдер, қолдау, қуаттың қалай өсетіні.

Практикалық реттілік, уақыт үнемдеуге жиі көмектесетін:

• 2–3 жылға есептелген жүктеме профилін жинаңыз (CPU, RAM, дискілер, желі);
• қабылдау критерийлері мен өнімділік талаптарын келісіңіз;
• типтік сервистер бойынша пилотты жоспарлап, алдын ала өлшеулерді бекітіңіз;
• "толқындармен" миграция жоспарын және кері қайту тәртібін жасаңыз;
• қолдау үшін минималды контурды бекітіңіз: дежурстволар, мониторинг, жаңарту терезелері.

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