Желі бойынша бэкап терезесін есептеу: формулалар мен түнгі мысал

Неліктен бэкап түнде үлгермейді

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

Мәселе көбінесе «мегабиттер жеткіліксіз» дегенде емес. Канал жылдамдығы қағазда көрсетілгендей нақты бэкап тасымалындағы жылдамдықтан жиі өзгереді. Оған протоколдардың оверхедтері, шифрлау, бәсекелес трафик, кешігулер мен жоғалтулар, сондай‑ақ бэкап жүйесінің деректерді қалай оқитыны және сақтау ішіне қалай жазады әсер етеді. Тіпті линк 1 Гбит/с болса да, бэкапқа пайдалы шынайы жылдамдық 2–5 есе төмен болуы мүмкін.

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

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

Жылдам әсер көбіне қарапайым шаралардан шығады: жылдамдықты шектеу және трафикке приоритет қою, инкременттік схемаларға көшу, нақты тиімді жерлерде дедупликация мен сығымдауды қосу, ауыр тапсырмаларды (мысалы, дерекқорлар мен файл шарлары) уақыт бойынша бөлу, сондай‑ақ сақтау мен серверлердегі тар жерлерді жою, сол жалғында желі бос тұрсын.

Практикалық мысал: филиал түнгі бэкапты орталық ЦОД-қа жібереді. Канал формалды 200 Мбит/с, бірақ күндіз ол бизнес трафигіне толы, ал түнде шифрлау мен шамадан тыс жүктелген сақтау себебінен жылдамдық төмендейді. Нәтижесінде бэкап «есепте болады», бірақ іс жүзінде үзіледі. Мұнда сәттілік емес, есептеу мен болжамдарды тексеру шешеді.

Бэкап терезесі деген не және қандай шектеулер бар

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

Терезе екі мақсатпен байланысты. RPO — егер қателік болса, қанша деректі жоғалтуға дайынсыз (мысалы, максимум 1 сағат өзгерістер). RTO — қалпына келтіру үшін қанша уақыт керек (мысалы, сервис 2 сағат ішінде қалпына келуі тиіс). RPO кіші болса, жиі бэкап қажет. RTO кіші болса, көшірме тез қалпына келуі керек.

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

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

Қарапайым мысал: егер түнде 6 сағат бар болса, бірақ 02:00–03:00 арасында банкпен алмасу болса, онда «шынайы» терезе 5 сағат немесе одан аз. Және оны толық пайдалануға болмайды: ретрайлар, тексерістер және күтпеген шыңдарға резерв керек.

Қандай бастапқы деректерді жинау керек

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

Алдымен нақты қорғалатын деректер көлемін анықтаңыз. Маңыздысы — жалпы көлем ғана емес (мысалы, файл шарлары мен VM-да 80 ТБ), сонымен қатар күнделікті өзгерістер: дерекқорлар мен пошталық жүйелерде бұл тәулігіне 5–20% болуы мүмкін, ал архивтерде дерлік нөл. Егер статистика жоқ болса, бэкап жүйесінің логтарын пайдаланып немесе 7–14 күн өсімді өлшеңіз.

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

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

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

Желінің өткізу қабілеті: нақты санды қалай алу керек

Порттағы номиналдық 1 Гбит/с бэкап үшін жиі 1 Гбит/с пайдалы тасымалға айналмайды. Желілік терезені есептеу үшін дәл түнгі уақытта тұрақты көретін жұмыс жылдамдығы қажет, паспорттағы емес.

Ең қарапайым бағалау былай басталады: канал жылдамдығын мегабайт/с‑ке аударып, оверхедке түзетулер енгізіңіз. Жылдам конверсия: 1 Гбит/с = 1000 Мбит/с = 125 МБ/с (идеал жағдайда). Сосын түзетулер қолданыңыз.

Пайдалы жылдамдық (МБ/с) = Номинал (МБ/с) × Kреал × (1 - Оверхед)

Мұнда Kреал — бэкаппен нақты пайдаланылатын бөлік (мысалы, 0,6 болса, бэкапқа 60% берілген), ал оверхед TCP/IP, VPN, шифрлау және көп кіші файлдармен жұмыстан келетін шығындарды қамтиды. VPN мен шифрлау үшін көбінесе 10–30% шығын қою орынды, ал көп кіші объектілер кезінде тағы да жоғары болуы мүмкін.

Тіпті жоғары жылдамдықты каналдарда RTT пен жоғалтулар TCP жылдамдығын қатты төмендетуі мүмкін. Ұзын желілер мен алаңдар арасында сол бірдей полоса әртүрлі нәтиже береді: RTT өсімі және 0,1–1% жоғалтулар тасымалдауды құлатады және «пила тәрізді» жылдамдыққа әкеледі.

Нақты сан алу үшін өлшеу маңызды:

• iperf тестін жүгіртіңіз (дерек қайдан қайда бара жатқан уақытта).
• коммутаторлар мен маршрутизаторлардағы порт статистикасын қараңыз: жүктеме, қателер, дроптар.
• бэкап‑жұмыстардың орташа жылдамдығын бірнеше түнге (кемінде 3) алыңыз.
• RTT пен пакеттердің жоғалуын тексеріңіз (ping/мониторинг), әсіресе филиалдар арасындағы VPN үшін.
• жолдағы QoS немесе rate‑limit әсерін бөлек бағалаңыз.

Кішкентай мысал: канал 1 Гбит/с (125 МБ/с), бэкапқа 50% шектеу (Kреал = 0,5), оверхед 20%. Сонда пайдалы жылдамдық: 125 × 0,5 × 0,8 = 50 МБ/с. Осы саннан әрі қарай түнде қанша ГБ шығады анықтайды.

Дедупликация мен сығымдау: желідегі көлемді қалай өзгертеді

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

Сығымдау блокты азайтады. Ол мәтіндерде, логтарда, офис құжаттарында, кей VM образдарында жақсы жұмыс істейді. Ал алдын ала сығылған деректерде әсері жоқ: видео, JPEG/PNG, ZIP/RAR, көптеген база көшірмелері.

Дедупликация қайталануларды жояды. Оның қай жерде жүзеге асырылатыны маңызды:

• Қайнарда (client-side): желіге көбінесе тек уникальды блоктар шығады — терезе нақты қысқарады.
• Қабылдауда (target-side): желіге толық поток шығады, үнемдеу сақтау жағында көрінеді.

Желі үшін ең маңыздысы — бірінші жағдай. Сондықтан есептеуде дедупликация мен сығымдау қай жерде қолданылатынын және қандай тәртіппен екенін нақтылаңыз.

Ыңғайлы тәжірибе — тиімді жіберілетін көлемді есептеу:

V_сеть = V_измен / (K_dedupe × K_comp)

Мұндағы K_dedupe және K_comp — поток қаншаға дейін кішірейеді (мысалы, 2 — «2 есе аз»). Егер әсер жоқ болса, коэффициент 1 тең. Егер дедупликация тек қабылдауда болса, желі үшін K_dedupe = 1 алыңыз.

Коэффициенттерді болжамдамай қойған жөн: оларды өткен жұмыстың есептерінен немесе типтік деректерде қысқа тесттен алу жақсы.

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

Трафик приоритеті мен лимиттер: бизнесті қалай қорғау

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

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

QoS жай ғана сөзбен

QoS — желі ережелері, жол толғанда кім бірінші өтетінін шешеді. Трафикті класстарға бөліп, әрқайсына приоритет қояды.

Көбінесе 3–4 класс жеткілікті: критикалық (дауыстар/видео, транзакциялар), маңызды (бизнес‑қосымшалар), қалыпты (веб), фондық (бэкап). Бэкапты фондық кезекке қойып, жылдамдық шектеу қойсаңыз, бизнес трафигі пайда болғанда бэкап дереу орынды босатуы тиіс.

Қауіпсіз лимитті қалай таңдау және тексеру

Консервативті лимиттен бастаңыз және 2–3 түн пилотынан нақтылаңыз:

• түнгі канал үлесін бэкапқа беріңіз (көбінесе нақты қолжетімдідің 20–40%)
• cap қойып, бэкап классы үшін QoS қосыңыз
• таңертең метрикаларды тексеріңіз: кешігулер, жоғалтулар, пайдаланушылардың шағымдары, бэкап аяқталу уақыты
• лимитті қадаммен (мысалы, +10%) өсіріп, бірінші әсерді байқасаңыз тоқтаңыз
• маңызды жүйелер үшін ерекшеліктерді бекітіңіз

Мини-сценарий: филиал 100 Мбит/с канал, түнде орталық дерекқормен алмасу бар. Бэкапқа 30 Мбит/с бөліп, фонға қоясыз. Егер таңертең дерекқор кешігулер артса, cap‑ты 20 Мбит/с‑ке азайтасыз немесе кей тапсырмаларды басқа терезеге тасымалдаасыз.

Қадамдық есептеу: қарапайым формулалар

Бэкаптардың түнде тұрақты аяқталуы үшін жалпы сақтау көлемін емес, шынайы терезеге жіберілетін деректер көлемін есептеу пайдалы.

Есептеу қадамдары

1. Терезе бойынша өзгерістер көлемін анықтаңыз. Инкременттік үшін бұл әдетте тәуліктік өсім (немесе 8–10 сағат ішіндегі өсім). Белгілеңіз: Vизмен (ГБ).

2. Дедупликация мен сығымдау әсерін қосыңыз. Олар дәл желі арқылы жіберілетін көлемді азайтады. Kdedup — дедупликацияның қысқартуы (2:1 үшін Kdedup = 2), Kcomp — сығымдаудың қысқартуы (1,5:1 үшін Kcomp = 1,5). Сонда жіберілетін көлем:

Vперед = Vизмен / (Kdedup × Kcomp)

3. Номиналдан емес, пайдалы жылдамдықты есептеңіз. Номинал TCP, шифрлау және протоколдық шығындардан, сондай‑ақ QoS лимиттерінен төмендейді. Белгілеңіз:

Sполез = Sном × Koverhead × Klimit

мұндағы Koverhead әдетте 0,7–0,9 (оверхедтен кейін), ал Klimit — бэкапқа нақты бөлінетін бөлік (мысалы, 0,3).

Бөлуде бірліктерге назар аударыңыз:

• 1 байт = 8 бит
• 1 МБ/с = 8 Мбит/с
• 1 ГБ = 1024 МБ

4. Пики мен сюрприздарға запас қосыңыз: желідегі ретрайлар, верификация, параллельді тапсырмалар, диск пен репозиторий бәсекелестігі. Практикалық запас — 20–40%.

Жалпы уақыт формуласы

Уақыт (сек) = (Vперед (МБ) / Sполез (МБ/с)) × Kзапас

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