Нақты деректердегі резервтік көшірмелер дедупликациясы

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

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

Көлем емес, қайталану орын үнемдейді

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

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

Үш шаманы бөлек ұстаған дұрыс:

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

Дедупликация коэффициенті әдетте логикалық көлемнің бірегей деректер көлеміне қатынасы ретінде есептеледі. 100 ТБ логикалық көшірме 20 ТБ бірегей блокқа айналса, коэффициент 5:1, ал орын үнемі 80 пайыз болады. «Бес есе аз орын» деген түсінікті, бірақ қаржылық модельге физикалық сыйымдылық керек. 5:1 коэффициенті сатып алынған 20 ТБ-ны соңғы байтына дейін толтыруға болады деген сөз емес. Индекске, қоқыс жинауға, уақытша операцияларға және жаңа деректердің өсуіне қор қажет.

Microsoft компаниясының Data Deduplication құжаттамасы виртуалдандыру кітапханалары үшін жоғары, ал пайдаланушы файлдары үшін біршама төмен аралықтарды көрсетеді. Бұл нәтиженің дерек түріне тәуелді екенін жақсы көрсетеді, бірақ басқа жүйенің сметасына нашар негіз болады. Онда Windows Server жүйесінің нақты механизмі, оның фрагмент өлшемдері, файл таңдау ережелері және өзінің сығуы сипатталған. Кестедегі санды басқа платформаға, басқа сақтау саясатына және шифрланған резервтік ағынға көшіруге болмайды.

Тағы бір шатастыратын тұс бар: жіберілетін деректерді қысқарту мен дискідегі орынды қысқарту әрдайым бір нәрсе емес. Дереккөз жағындағы дедупликация қайталанатын блоктарды желі арқылы жібермеуі мүмкін. Тек мақсатты құрылғыда істейтін дедупликация толық ағынды қабылдап, орынды қабылдау кезінде немесе одан кейін үнемдейді. Филиал мен орталық арасындағы тар арна үшін бұлар екі бөлек архитектура, бірақ коммерциялық сипаттамада екеуі де бір атаумен берілуі мүмкін.

Ұқсас нұсқалар ең үлкен ұтыс береді

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

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

Жақсы үміткерлер әдетте мыналар:

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

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

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

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

Сығылған және шифрланған ағындар сирек қайталанады

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

Шифрлау бұдан да қатты әсер етеді. Дұрыс жасалған шифрлау нәтижені кездейсоқ дерекке ұқсатады. Жаңа инициализация векторы, nonce немесе тұз бастапқы ашық мазмұн бірдей болса да басқа шифрмәтін жасайды. Қолданба әр резервтік көшірмені мақсатты құрылғы көргенге дейін шифрласа, сыртқы дедупликация әдетте сәйкестіктерді жоғалтады. Бұл криптографияның кемшілігі емес, күтілетін қасиеті.

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

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

Мына жинақтардан да төмен нәтиже күтіңіз:

• мазмұнның әр бөлігі жаңа болатын бейнебақылау жазбалары мен медиатекалар;
• қолданба әр жолы қайта жинайтын ZIP, 7z және басқа контейнерлер;
• жіберуге дейін шифрланған клиенттік резервтік көшірмелер;
• бір кезеңде беттерінің көбі өзгеретін жүктемесі жоғары дерекқорлар;
• бірегей мәндер ағыны үлкен журналдар, телеметрия және ғылыми деректер.

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

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

Фрагмент шекаралары нәтижені өзгертеді

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

Айнымалы өлшемді бөлу шекараны мазмұнның өзінен іздейді. Қосымшадан кейін синхрондау әдетте қайта орнығып, келесі фрагменттердің көбі тағы сәйкес келеді. Microsoft өз Data Deduplication іске асыруында айнымалы фрагменттерді сипаттайды. Бұл блоктық механизм өзгеретін файлдарда үнемді неге сақтай алатынын түсіндіреді, бірақ нақты коэффициентке кепілдік бермейді. Фрагменттің ең төменгі және орташа өлшемі, шекара таңдау алгоритмі және индекс аумағы жүйелерде әртүрлі.

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

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

Салыстыру терезесінің өлшемі фрагмент өлшеміндей маңызды. Бір файл ішіндегі жергілікті терезеге жаһандық индекс көп керек емес, бірақ ол серверлер арасындағы көшірмелерді жіберіп алады. Бір тапсырмалық терезе көбірек табады. Бүкіл кластерге ортақ индекс көп жылғы тарихты салыстыра алады, бірақ оған жад, метадерек үшін жылдам тасымалдағыш және ойластырылған масштабтау керек. Шекке жеткенде кей жүйе жаңа домен жасайды, содан кейін ескі және жаңа деректер бір-бірімен дедупликацияланбайды.

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

Процессор мен жад әр өткізілген блок үшін төлейді

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

«Бір терабайт дискіге осынша гигабайт RAM» деген әмбебап формула жоқ. Жад шығыны физикалық сыйымдылықтан гөрі бірегей фрагменттер саны мен индекс құрылымына тәуелді. Орташа фрагмент 64 КиБ болса, орау мен метадеректі есептемегенде 1 ТиБ бірегей дерекке шамамен 16 миллион фрагмент келеді. Ондаған миллион жазба бүкіл индекс үнемі RAM ішінде тұруы керек деген сөз емес, бірақ міндет ауқымын көрсетеді. Ұсақтау бөлу мен үлкен бірегей жинақ талапты арттырады.

Нақты бағдар ретінде Microsoft өзінің Data Deduplication қызметіне оңтайлы жағдайда 1 ТБ логикалық дерекке шамамен 1 ГБ жад ұсынады, ал құжатталған ең төменгі формуласы бұдан аз. Бұл санды аппараттық дедупликаторға немесе басқа бағдарламаға көшіруге болмайды. Ол өндірушінің ең жоғары өнімділікті елеулі жад көлемімен байланыстыратынын және ең аз ресурсты режимді баяуырақ деп тікелей сипаттайтынын еске салады.

Жүктеме әр жерде пайда болуы мүмкін:

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

Inline өңдеу кіріс ағынға ілесуі керек. Массив 4 ГБ/с қабылдап, дедупликатор 1,5 ГБ/с өңдесе, бүкіл жүйенің пайдалы жылдамдығы төмен санға тең. Диск қосу хеш есептеу немесе индекс тар жерін түземейді. Кейінгі өңдеу сызбасы деректі жылдамырақ қабылдауы мүмкін, бірақ оңтайландыру біткенше көбірек орын алады және жаңа тапсырмалармен I/O үшін таласады.

Қоқыс жинауды да ұмытпаңыз. Ескі қалпына келтіру нүктесін жою көбіне сілтемелерді алып тастайды, ал бірегей фрагменттерді бөлек үдеріс босатады. Ол аяқталғанша алынған орын азаймауы мүмкін. Толық қоқыс жинау, тұтастықты тексеру және индексті қайта құру қалыпты жазудың әдемі графигінде көрінбейтін жүктеме туғызады. Microsoft толық қоқыс жинау өнімділік мәселесін тудыруы мүмкін екенін бөлек ескертеді және қалыпты режим пайдаланылмайтын орынның көп бөлігін қайтаратынын айтады. Іс жүзіндегі қорытынды анық: бір сәтті кешті емес, бір апталық қызмет көрсету циклін өлшеңіз.

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

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

Бір шағын қалпына келтіруде кеш көбіне шығынды жасырады. Жиі қолданылатын блоктар қайта оқылып, жадта қалады, сондықтан бір виртуалды машина тез оралуы мүмкін. Бүкіл торапты немесе алаңды апаттан қалпына келтіру басқаша жүреді: жүйе бір уақытта көптеген бірегей блок пен метадеректі сұрайды, дерек пен индекс I/O үшін таласады, ал процессор ағынды ашады. RTO-мен дәл осы сценарийді салыстыру керек, зертханадағы бір файлды емес.

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

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

Қалпына келтіру сынағы төрт сұраққа жауап беруі керек:

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

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

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

Өз деректеріңіздегі пилот шынайы коэффициент береді

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

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

Windows Server Data Deduplication үшін бастапқы күй мен нәтижені мынадай пәрмендермен түсіруге болады:

Get-DedupStatus | Select-Object Volume,Capacity,FreeSpace,SavedSpace,SavingsRate,OptimizedFilesCount,InPolicyFilesCount
Get-DedupJob
Get-DedupMetadata D:

Бірінші жол шығысының пішіні мынадай, сіздің жүйедегі мәндер басқа болады:

Volume Capacity FreeSpace SavedSpace SavingsRate OptimizedFilesCount InPolicyFilesCount
D:     ...      ...       ...        ...         ...                 ...

Пәрмен сақталған орынды, үнем үлесін және өңделген файл санын бөліп көрсеткендіктен пайдалы. Есепке көп нүктені нөл ретінде көшірмеңіз. Әр тапсырмадан және қызмет көрсетуден кейін нақты мәндерді экспорттаңыз. Басқа өнімде соған сәйкес есептегіштерді қолданыңыз, бірақ өрістердің мағынасын сақтаңыз.

Өлшеу жоспары бес әрекеттен тұрады:

1. Жүктеуге дейін физикалық алынған орынды, логикалық көлемді және бос сыйымдылықты тіркеңіз.
2. Бір толық көшірме жасап, таңдалған сақтау циклі біткенше қалыпты тапсырмаларды орындаңыз.
3. Кіріс көлемін, жаңа бірегей деректі, CPU, RAM ең жоғары мәнін, желілік трафикті және әр тапсырма ұзақтығын жазыңыз.
4. Мерзімі өткен нүктені жойып, қалыпты қоқыс жинауды күтіңіз де, физикалық орынды қайта өлшеңіз.
5. Салқын кешпен бір файлды, бір ірі жүйені және бірнеше жүйені қатар қалпына келтіріңіз.

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

Есептеу ресурсының бағасын бөлек санаңыз. Дедупликация 40 ТБ диск үнемдегенімен, оған лицензия, қосымша 256 ГБ RAM, қуаттырақ CPU және талап етілген жылдамдық үшін екінші торап керек болса, иеленудің толық құнын салыстырыңыз. Оған электр қуаты, қолдау, қызмет көрсету кезіндегі қор сыйымдылық және оператор уақыты кіреді. Кейде бірегей медиа ағынды дедупликациясыз тығыз дискілерде сақтау, ал механизмді тек виртуалды машиналарға қолдану арзанырақ.

Басқару тақтасы жоғары коэффициент көрсетіп, қалпына келтіру RTO-ға сыймаса, пилот сәтсіз. Жүйе өндірістік тапсырмалар тоқтағанда ғана деректі өңдеп үлгерсе немесе томды қауіпсіз шектен артық толтыру қажет болса да, нәтиже сәтсіз. Сыйымдылық үнемі қалпына келмейтін көшірмені ақтамайды.

Қаржылық модель күнделікті өсімнен басталады

Сатып алуды тәулігіне келетін жаңа бірегей дерек пен сақтау мерзіміне қарай есептеу керек. Дереккөздер тәулігіне 8 ТБ жіберіп, дедупликация мен сығудан кейін физикалық өсім 1,6 ТБ болсын. Қазіргі қысқарту коэффициенті 5:1. Күнделікті 30 нүкте сақталса, осы ағынға шамамен 48 ТБ жұмыс сыйымдылығы керек, бірақ оған бастапқы жинақ, метадерек, қызмет көрсету қоры және өсу де қосылады.

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

Үш сценарий қолданыңыз: өлшенген қалыпты күн, ірі жаңартулар айы және коэффициент төмендейтін нашар жағдай. Әрқайсысында қорды ескеріп, жұмыс сыйымдылығы қашан таусылатынын тексеріңіз. Логикалық алдыңғы көлемді дисктердің пайдалы сыйымдылығымен араластырмаңыз және өндіруші деректерді қысқартуды бағасына қосып қойған болса, коэффициентті қайта қолданбаңыз.

Сақтау мерзімінің әсері сызықтық емес. Алғашқы бірнеше ұқсас нүкте жинақталған коэффициентті тез жақсартады, кейін әр жаңа күн азырақ ортақ блок және өзінің бірегей өзгерістерін қосады. Сақтауды 30 күннен 90 күнге ұзарту міндетті түрде үш есе көп физикалық орын сұрамайды, бірақ тегін де емес. Ай сайынғы мұрағат көшірмелері күнделікті нүктелерде қалмаған ескі бірегей нұсқаларды ұстай алады.

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

Тәуекел бағасы да модельге кіреді. Бір ортақ бірегей блоктар пулы мен бір индекске неғұрлым көп логикалық дерек тәуелді болса, бұзылу салдары соғұрлым үлкен. Тұтастықты тексеру, басқа ақау доменіндегі көшірме және тұрақты қалпына келтіру қажет. Дедупликация тәуелсіз көшірмелер ережесін алмастырмайды және жоюдан, бопсалаушы бағдарламадан немесе әкімші қатесінен қорғамайды. Ол байттарды орналастыру тәсілін ғана өзгертеді.

Архитектураны қалпына келтіруге қарай таңдаңыз

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

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

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

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

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