Dell PowerProtect DD: сақтық көшірме репозиторийін таңдау және модель есептеу

Репозиторийден нендей талап күту керек

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

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

Көбіне сақтаудан үш нәрсе күтіледі: жылдамдық, сақтау мерзімі және сенімділік.

Жылдамдық — бэкап терезесі түнде немесе демалыс күндері аяқталсын үшін қажет. Сақтау мерзімі — қажет ретеншнге жеткілікті орын болсын (мысалы, күнделікті 30–90 күн және бірнеше айлық нүктелер). Сенімділік — қалпына келтіру лотореяға ұқсамайтындай, диск немесе контроллер істен шықса аптадағы жұмыс жоғалмасын.

Бір репозиторияда әртүрлі типтегі деректер болады: виртуалдық машиналар, дерекқорлар, файлдық шаралар, пошта, бизнес-қосымшалар. Әр профильдің өз «геометриясы» бар. ВМ-дер көп параллель ағын берсе, дерекқорлар журналдар үшін жиі бэкап талап етеді. Файлдық жиындар кейде нашар дедупликацияланады, әсіресе архивтер мен медиа көп болса.

Сондықтан модель таңдағанда тек терабайттарды ғана емес, екі негізгі параметрге назар аударыңыз: жазу ағыны (ingest) және қалпына келтіру кезіндегі оқу ағыны.

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

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

Таңдауда шатастыратын терминдер

Dell PowerProtect DD-ні репозитори ретінде қарастырсаңыз, алдымен терминдерді келісіп алған дұрыс. Әйтпесе біреу сыйымдылықты есептейді, басқасы жылдамдықты айтады, нәтижесінде дұрыс емес нәрсе алынады.

Күнделікті жазылып жатқан бэкап түрлері

Полный (толық) бэкап — таңдалған деректердің толық көшірмесі. Ең түсінікті, бірақ көлемі мен жүктемесі бойынша ауыр.

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

Синтетикалық полный — репозиторий немесе бэкап-софт жағында толық пен инкременттерден жинақталып жасалатын «толық», продакшннен бәрін қайта оқымайды. Терезені қысқартады, бірақ ішкі оқу/жазу операцияларын көбейтеді.

Жылдамдық пен уақыт: ағым және терезе

Бэкап ағымы — деректер репозиторийге қандай жылдамдықпен жазылуы тиіс (TB/сағ немесе MB/с). Бэкап терезесі — SLA-ға сай қанша сағат бар.

Негізгі формула: түндегі көлем / терезе = минималды қажет ағым. Сосын «нашар күндерге» запас қосыңыз: көбірек өзгеріс, қайта жүгіртулер, параллель тапсырмалар.

Ретеншн — қанша уақыт нүктелер сақталады (мысалы, 14, 30 күн немесе 12 апта). Маңыздысы тек мерзім емес, жиілік те: күнделікті, апталық, айлық көшірмелер әртүрлі ережеде сақталуы мүмкін.

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

Есепке кіріспес бұрын қысқаша бекітіңіз:

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

Есептеуге дейін жинайтын бастапқы мәліметтер

Dell PowerProtect DD-ні күтпеген жағдайсыз таңдау үшін бастапқы цифрларды жинаңыз. Олардысыз есептеу болжауға айналады. Кейін компромистер болады: ретеншн қысқарту, терезені ұзарту немесе қалпына келтірулерді кейінге қалдыру.

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

Келесі — қорғалған деректердің логикалық көлемі және өсім болжамы. «Дискілер көлемін» емес, бэкапқа түсер нақты деректі алыңыз. Ай сайынғы өсімді бөліп көрсетіңіз (пайызбен немесе ГБ) және күтілетін секірістер: маусымдық закрытия, есептілік, оқу кампаниялары.

Мини-чеклист (әдетте жеткілікті):

• не сақтаймыз және қанша (ВМ, физика, БД, файлдар);
• қазір қанша дерек қорғалған және қалай өседі;
• қалай жиі көшірме жасаймыз (толық, инкремент, журнал) және қанша нүкте сақтаймыз;
• бэкап терезесі және сайттар арасындағы желі шектеулері;
• RPO және RTO талаптары қарапайым тілде.

RPO және RTO-ны «адамша» жазған жөн: мысалы, «1 сағаттан көп дерек жоғалтуға болмайды» және «сервис 4 сағатта тұруы тиіс». Бұл бэкап жиілігіне, жазу жылдамдығына және қабылдауда қандай қалпына келтірулерді тексеру керек екенін анықтайды.

Мини-үлгі: 80 ВМ, 6 физика, 45 ТБ дерек, өсім 3%/ай, түнгі терезе 8 сағат, сайттар арасындағы канал 300 Мбит/с, күнделікті көшірме + әр сағат журналдар, ретеншн 30 күн. Осындай бастапқы деректермен ағымды және сыйымдылықты есептеп болады.

Қажетті жазу ағынын қалай есептеу: қадамдар

Жазу ағыны — репозиторийге терезе ішінде жазылуы тиіс деректер жылдамдығы. Dell PowerProtect DD үшін бұл есеп сыйымдылықтан да маңызды: өнімділік жетпесе, бэкаптар жұмыс уақытында «сырғығыш болады».

Есептің қадамдары

1. Жүйелер бойынша күнделікті өзгерістер (change rate) дерегін жинаңыз. Бэкап-софт немесе сақтау статистикасынан алу жақсы. ВМ, БД, VDI, файлдық жинақтар әртүрлі профильге ие.

2. Өзгерістер мөлшерін жазу жылдамдығына аударыңыз:

Поток (ТБ/сағ) = Күнделікті өзгерістер (ТБ) / Бэкап терезесі (сағ).

Мысалы, терезе 10 сағат болса, өзгеріс 6 ТБ — базалық ағым 0.6 ТБ/сағ.

3. Параллельділікті есепке алыңыз. Барлығы «қанша» емес, қанша тапсырма бір уақытта жазады және олардың түрі (толық, инкремент, синтетика) маңызды.

4. Пик күндерге запас қосыңыз. Апталық толықтар, айлық закрытия, тоқсандық есептер — жиі кездесетін пиковое жүктеме. Практикада 20–40% запас қосады, ауыр жүйелер үшін үлкен коэффициент пайдаланылуы мүмкін.

Қабылдауда тексеруге арналған мәндер

Терезе, күнделікті өзгерістер саны, максималь параллельдік, мақсатты жалпы жазу ағымы және «пик» сценарийін санмен белгілеңіз. Осы мәндерді кейін job-тардың фактілік метрикаларымен салыстыруға болады.

Ретеншн мен дедупликацияға арналған сыйымдылықты қалай есептеу

Репозиторийдегі сыйымдылық көбіне бір үлкен толық бэкаппен емес, ретеншн кезеңіндегі барлық қалпына келтіру нүктелерінің қосындысымен «жіңішке» кетеді. Сондықтан терабайттар туралы емес, restore point саны мен өлшемі туралы ойлау керек.

Дедупликация: әсері әр деректе әртүрлі

Дедупликация коэффициенті деректер типіне және бэкап әдісіне тәуелді.

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

Бір «әсерлі» коэффициентке сенбеңіз — дереккөздерді 3–4 топқа бөліп, әрқайсысы үшін сыйымдылық есептеңіз.

Ретеншн: күндер санын емес, нүктелерді санаңыз

Негізгі әдіс:

1. Әр топ үшін толық бэкаптың көлемін және орташа күндік өсімді анықтаңыз;
2. Кестені белгілеңіз (аптасына бір толық, күнделікті инкремент және т.б.);
3. Қай нүктелер қанша уақыт сақталатынын есептеңіз (мысалы, 30 күндік күнделікті және 12 апталық);
4. Барлық «шикі» көлемдерді қосып, кейін нақты дедупликацияны қолданыңыз.

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

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

Жоспарды «жабық» етіп жасамаңыз: деректердің 12–18 ай өсімі мен техникалық запас 20–30% ұстаңыз, солайша пики мен саясат өзгерістерін өтесіз.

Бэкап-софтпен интеграция және желі талаптары

PowerProtect DD-ні әртүрлі жолмен жалғауға болады, бұл жылдамдыққа, бэкап-сервердің жүктемесіне және желі талабына әсер етеді. Бірдей дерек әртүрлі архитектурада әртүрлі ресурстарды пайдалануы мүмкін: бір жерде бэкап-сервер көбірек жүктемені көтерсе, басқа жерде репозиторийтің өзінде оптимизациялар орын алады.

Жиі қолданылатын тәсілдер:

• NFS/CIFS: тез бастау, бірақ көбіне көбірек трафик «қалай бар солай» өтеді, бэкап-серверге жүктеме жоғары;
• VTL (виртуалды кітапхана): лента логикасы қажет жүйелерге ыңғайлы, бірақ ағын саны шектеулі болуы мүмкін;
• Boost (қосымша деңгейлік интеграция): әдетте желі мен CPU тиімділігі жоғары, өйткені оптимизация бэкап-софтпен үйлеседі.

Интеграция тәсілі «пайдалы» ағымды өзгертеді. Мысалы, бірдей 20 параллель тапсырма NFS арқылы бэкап-сервердің CPU мен желісін шектеп қалуы мүмкін. Boost арқылы тар шектеу жиі диск пен DD ресурсына ауысады, желіде аз дерек өтеді.

Желілік бағдар: 10G — кіші және орташа орталарға жиі жеткілікті; 25G — параллелизм өскенде және күнделікті инкременттер үлкен болғанда қажет; 40/100G — ірі орталарға тән. Бірақ порт жылдамдығы бэкап жылдамдығының синонимі емес: коммутаторлар, MTU, кезектер және нақты тар нүкте маңызды.

Мүмкін болса, трафикті бөліңіз: бэкап деректері бөлек, әкімшілік және мониторинг бөлек. Солай жаңарту немесе лог жинау терезені «жеп кетпейді».

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

Модельді таңдау: қарапайым логика

Модельді екі шектеуге қарай таңдаңыз: жазу ағымы (ingest) және пайдалы сыйымдылық (ретеншн).

Есептелген мәндеріңізді алыңыз және қайсысында шекке ұшырайтыныңызды қараңыз. Егер ағым бойынша шектелсе — «жылдамырақ» модель керек. Егер ретеншн сыйымдылық жетпесе — «ірірек» модель қажет. Практикалық ұстаным: ағым мен сыйымдылыққа 20–30% запас ұстаңыз.

Одан кейін не маңыздырақ екенін анықтаңыз: жылдам жазу ма әлде жылдам оқу ма. Апатта оқу мен параллельдік маңызды; егер қатал RTO бар болса, таңдалған модельдегі оқу жылдамдығын, бір мезгілде қанша қалпына келтіру көтере алатынын және желінің бұл артықшылығын «жеейтінін» тексеріңіз.

Аралас жүктемелер есепті күрделендіріп жібереді. Көп кіші тапсырмалар жоғары параллельділікті талап етеді, ал бірнеше үлкен тапсырма жоғары шыңды жылдамдық пен үлкен желілік порттарды қажет етеді. Сондықтан тек жалпы MB/s-ке қарамай, қанша тапсырма бір уақытта жүретінін есептеңіз.

Жедел кездесу үшін қарапайым матрица көмектеседі:

• терезе жабылмай жатса — ingest және ағым лимиттеріне басымдылық беріңіз;
• ретеншн сыймай жатса — пайдалы сыйымдылыққа басымдық беріңіз;
• RTO ең маңызды — оқу жылдамдығы мен параллельділікке басымдық беріңіз;
• өсу бар — қалай масштабталатынын және бұл тұрақтылыққа қалай әсер ететінін алдын ала шешіңіз;
• репликация/екінші сайт бар — қосымша ағымды және репликация терезесін есептеңіз.

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

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

Dell PowerProtect DD-ден көңілі қалу жиі дұрыс емес есептеулерден басталады. «Орташа күнге» сай модель алып, кейін кез келген пік немесе өсім кезінде терезелердің бұзылуын, кезектер мен баяу қалпына келтіруді көреді.

Көбіне кездесетін қателіктер:

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

Мысалы: ұйым күнделікті инкремент жасайды, аптасына бір толық. Модельді апталық емес күндердегі орташа ағымға сай алады. Аптада толық болған кезде терезе бұзылады, дүйсенбіде ашылмаған джобтар қалып, инкремент тізбегі өсіп, қалпына келтіру күрделенеді.

Сатып алу алдында ТЗ-да ең ауыр күн қандай, ағымға қанша запас керегі, дедупликацияның ең нашар коэффициенті жағдайында не болатыны, қай 2–3 қалпына келтіру сценарийі критикалық және желі/бэкап-сервер қажетті параллельділікті көтеретіндігі секілді сұрақтарға жауаптар бекітілген болсын.

Интегратор арқылы сатып алынса (GSE.kz мысалы), осы тармақтарды қабылдау бағдарламасына алдын ала қосу пайдалы — эксплуатацияда қажетті нәтиже бермейтін «дұрыс модель» сатып алудан сақтанады.

Қабылдауда міндетті қалпына келтіру бақылаулары

PowerProtect DD қабылдауы — тек «бэкап өтті» емес, қалпына келтіру нақты жұмыс істейтінін дәлелдеу. Қалпына келтіру RTO-ға сай және қайталанатын болуы тиіс.

Міндетті тесттер жиынтығы

Ең алдымен 1–2 критикалық сервисті бақылау қалпына келтіруін жасаңыз. Бизнес дәл сезінетін нәрсені таңдаңыз: мысалы, қосымшасы бар виртуалдық машина және бөлек дерекқор немесе файл сервері. Мақсат — «жұмыс істейді және қолжетімді», жай «қате жоқ» емес.

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

Қалпына келтіру уақытын өлшеп, мақсатты RTO-мен салыстырыңыз. Уақытқа тек деректер көшіруді емес, нүктені табу, дайындық, қалпына келтіру және іске қосу тексерісін қосыңыз. Көп жағдайда «жылдам көшіру» бірақ ұзақ қолжетімділік күтуі болады.

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

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

Құжаттамаға не рәсімдеу керек

Қабылдауды дау туғызбайтын ету үшін келесі артефакттарды бекітіңіз:

• әр тест бойынша хаттамалар (күн, сценарий, қалпына келтіру нүктесі, нәтиже, ескертулер);
• метрикалар (фактілік RTO, қалпына келтірілген дерек көлемі, жылдамдық, желі/хост жүктемесі);
• бэкап-софт пен PowerProtect DD логтары, операцияларды растайтын жазбалар;
• жауапкершілік матрицасы (кім тестті іске қосады, кім сервис жұмысын растайды, кім актіні қол қояды).

Қарапайым сценарий бойынша есеп және қабылдау жоспары

Сценарий: 200 ВМ және 2 дерекқор. Түнгі бэкап терезесі 8 сағат. Ретеншн 30 күн. Репозиторий — Dell PowerProtect DD.

Шамалау үшін күнідегі өзгерістер маңыздырақ, жалпы көлем емес. Мысалы, орташа ВМ көлемі 150 ГБ, күнде 3% өзгереді. Дерекқорлар 2 ТБ әрқайсысы, күнде 5% өзгереді.

Жазуды бағалау:

• ВМ: 200 x 150 ГБ x 3% = 900 ГБ/күн;
• Дерекқорлар: 2 x 2 ТБ x 5% = 200 ГБ/күн;
• Жалпы: шамамен 1,1 ТБ/күн жазылуы тиіс;
• 8 сағат терезеде: 1,1 ТБ / 8 сағат ≈ 140 ГБ/сағ, бұл орташа шамамен 40 МБ/с.

Пиктер мен накладные шығындарды ескеріңіз — әдетте есепті 2–3 есе көбейтуге тура келеді. Осы мысалда мақсаттық жазу 80–120 МБ/с шамасында болады.

Содан кейін таңдалған модельдің апталық толықтар, параллель тапсырмалар, синтетика және ішкі операциялар кезіндегі шыңды көтере алатынын тексеріңіз. 30–50% запас пен бір жылға 20–30% өсу жоспарлаңыз. Егер бүгінге 120 МБ/с қажет болса, жыл соңына 150–180 МБ/с құрауы мүмкін.

Ретеншн бойынша ескерту: 30 күн = 30 ТБ деген емес. Дедупликация мен компрессиядан кейінгі нәтиже дерек типіне және сақталу схемасына байланысты. Қабылдауда тек жылдамдықты ғана емес, нақты деректердегі қысқару коэффициентін де растайтын тест жасаңыз.

Қабылдауға міндетті үш қалпына келтіру:

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

Нәтиже қабылданған саналады егер қалпына келтіру қатесіз өтсе, RTO талаптарға сай болса және типтік сценарийлерде (мысалы, бір уақытта қалпына келтіру және түнгі бэкап) жылдамдықтар қатты төмендемесе.

Сатып алуға дейін және орнатқаннан кейінгі келесі қадамдар

Dell PowerProtect DD таңдауында тек есептік цифрларды емес, жүйені дәлелімен қалай тексеретініңізді де алдын ала бекітіңіз.

Сатып алуға дейін

Барлық бастапқы деректерді бір құжатқа жинаңыз. Тіпті бір беттік кесте де пайдалы, егер сандар жүйе иелерімен келісілген болса.

Қысқаша дайындалатындар: change rate негізгі жүйелер бойынша, толық және инкремент көлемдері, бэкап терезесі; ретеншн, RPO/RTO қарапайым тілде; өсу болжамы және кеңейту жоспары; орналастыру шектеулері (қуат, стойка, салқындату); интеграциялар тізімі (қандай бэкап-софт, қандай протоколдар қажет, каталог пен басқару қай жерде).

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

Орнатқаннан кейін

Қабылдау қалпына келтіруді тексеруі тиіс, тек «бэкап сәтті» деп жазылмауы керек. Сценарийлер мен метрикаларды алдын-ала бекітіңіз.

Минималды жұмыс жиынтығы: файл, VM және дерекқорды қалпына келтіру тесті (әрқайсысы нақты мысалмен) және уақытты өлшеу; бүтіндік бақылауы; пиковый терезеде бэкап өткізу және бір-екі параллель қалпына келтіруді өткізіп көру; ретеншнді практикада тексеру (нүктелерді жою, толу болжамы); операциялық процедуралар (алармдарға кім жауап береді, тест-restore қаншалықты жиі жүргізіледі, хаттамалар қайда сақталады).

Тәртіпті ұстанатын қарапайым әдіс: аптасына 1–2 критикалық сервисті жоспарлы қалпына келтіру және ай сайын кеңейтілген тест, RTO/RPO-ны бекітумен.

Егер толық «ключке» жоба қажет болса (интеграция, репозиторийге арналған инфрақұрылым, енгізу, қабылдау және 24/7 қолдау), оны бір орында жүргізген ыңғайлы болады. Мысалы, GSE.kz жүйелік интеграторы осындай кешенді қызметтерді, соның ішінде ЦОД инфрақұрылымы бойынша қолдауды ұсынады.