RTO-ի և RPO-ի հաշվարկը առաքելության համար կարևոր տվյալների բազաների համար. DBA-ի ուղեցույց

DevOps ինժեներների, տվյալների բազայի ադմինիստրատորների (DBA) և ՏՏ համակարգերի ճարտարապետների համար Վերականգնման ժամանակի նպատակը (RTO) և Վերականգնման կետի նպատակը (RPO) ավելին են, քան պարզապես բիզնեսի շարունակականության մասին հնչեղ բառեր՝ դրանք խիստ ինժեներական սահմանափակումներ են: Առաքելության համար կարևոր տվյալների բազաները կառավարելիս այս չափանիշները ճշգրիտ հաշվարկելու, դրանց համար ճարտարապետություն մշակելու և վավերացնելու ձախողումը կարող է հանգեցնել աղետալի տվյալների կորստի և երկարատև պարապուրդի:

Ժամանակակից ձեռնարկատիրական միջավայրերում RTO-ի և RPO-ի հաշվարկը պահանջում է տվյալների բազայի ներքին կառուցվածքի, պահեստավորման I/O-ի, ցանցի թողունակության և գործարքների մատյանների (transaction logs) մեխանիզմների խորը ըմբռնում: Այս ուղեցույցը ուսումնասիրում է արտադրական տվյալների բազայի համակարգերի համար RTO-ի և RPO-ի հաշվարկման, փորձարկման և օպտիմալացման տեխնիկական մեթոդաբանությունները:

RPO-ի (Վերականգնման կետի նպատակ) ապակառուցումը տվյալների բազայի համակարգերում

RPO-ն սահմանում է տվյալների կորստի առավելագույն ընդունելի քանակը՝ չափված ժամանակով: Եթե ձեր RPO-ն 15 րոպե է, ապա ժամը 12:00-ին տեղի ունեցած աղետը նշանակում է, որ դուք պետք է կարողանաք վերականգնել բոլոր հաստատված գործարքները առնվազն մինչև 11:45-ը:

Տվյալների բազաների համար RPO-ն թելադրվում է ձեր գործարքների մատյանների կառավարման ռազմավարությամբ (WAL՝ PostgreSQL-ում, Redo Logs՝ Oracle-ում, Transaction Logs՝ SQL Server-ում):

Տվյալների կորստի և մատյանների գեներացման մեխանիզմները

Հասանելի RPO-ն հաշվարկելու համար նախ պետք է հասկանալ ձեր տվյալների բազայի գործարքների մատյանների գեներացման արագությունը: Եթե դուք յուրաքանչյուր 15 րոպեն մեկ մատյանները ուղարկում եք պահուստային պահոց, բայց ձեր ցանցը չի կարող այդ ժամանակահատվածում փոխանցել 15 րոպեի մատյանները, ձեր իրական RPO-ն անընդհատ կվատթարանա:

Դուք կարող եք հիմք ընդունել մատյանների գեներացման ձեր արագությունը՝ օգտագործելով SQL-ի բնիկ հրամանները: Օրինակ՝ PostgreSQL-ում (տարբերակ 10+) կարող եք չափել Write-Ahead Log (WAL) գեներացման արագությունը որոշակի ընդմիջումով.

-- Գործարկեք սա T=0 պահին
SELECT pg_current_wal_lsn() AS start_lsn;

-- Սպասեք ուղիղ 5 րոպե (300 վայրկյան), այնուհետև գործարկեք.
SELECT pg_current_wal_lsn() AS end_lsn,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), 'START_LSN_VALUE')) AS wal_generated_size,
       pg_wal_lsn_diff(pg_current_wal_lsn(), 'START_LSN_VALUE') / 300 AS bytes_per_second;

Եթե այս հարցումը ցույց է տալիս, որ առավելագույն ծանրաբեռնվածության ժամանակ դուք գեներացնում եք 50 ՄԲ/վրկ WAL տվյալներ, ապա 15-րոպեանոց RPO-ն պահանջում է 45 ԳԲ մատյանի տվյալների փոխանցում ձեր պահուստային պահոց: Ձեր ցանցը և պահեստավորման թիրախները պետք է աջակցեն 50 ՄԲ/վրկ-ից ավելի կայուն գրելու արագությանը՝ այս RPO-ն պահպանելու համար:

Սինխրոն և ասինխրոն ռեպլիկացիայի ազդեցությունը

Շատ DBA-ներ RPO-ն բավարարելու համար ապավինում են բարձր հասանելիության (HA) ռեպլիկացիային: Այնուամենայնիվ, ռեպլիկացիան պահուստային պատճեն չէ: Հեռացված աղյուսակը (DROP TABLE users;) ակնթարթորեն ռեպլիկացվում է:

Աղետների վերականգնման (DR) համար ռեպլիկացիա օգտագործելիս ռեպլիկացիայի ռեժիմն ուղղակիորեն ազդում է RPO-ի վրա.
* Սինխրոն ռեպլիկացիա. Երաշխավորում է զրոյական RPO (RPO=0): Հիմնական տվյալների բազան չի հաստատի գործարքը, քանի դեռ սպասողական (standby) սերվերը չի հաստատել ստացումը: Փոխզիջումը հիմնական գրելու գործողությունների ժամանակ ուշացման ավելացումն է:
* Ասինխրոն ռեպլիկացիա. Առաջացնում է ռեպլիկացիայի ուշացում: Ձեր RPO-ն փաստացի հավասար է ձեր ընթացիկ ռեպլիկացիայի ուշացմանը:

PostgreSQL-ում ասինխրոն ռեպլիկացիայի ուշացումը վերահսկելու համար օգտագործեք.

SELECT application_name,
       client_addr,
       state,
       sync_state,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replication_lag_bytes
FROM pg_stat_replication;

RTO-ի (Վերականգնման ժամանակի նպատակ) ապակառուցումը լայնամասշտաբ տվյալների բազաների համար

RTO-ն պարապուրդի առավելագույն տանելի տևողությունն է: Տվյալների բազայի RTO-ի հաշվարկը հայտնի է իր բարդությամբ, քանի որ այն պարզապես ֆայլերը սերվեր վերադարձնելու ժամանակը չէ:

RTO-ի հաշվարկի մաթեմատիկական մոդելը

Տվյալների բազայի RTO-ի իրատեսական հաշվարկը պետք է հաշվի առնի չորս հստակ փուլ.

RTO = T(ենթակառուցվածք) + T(փոխանցում) + T(վերականգնում) + T(վերականգնում_բազայի)

1. T(ենթակառուցվածք) – Ենթակառուցվածքի տրամադրում. Հաշվողական հզորությունների և պահեստավորման փոխարինման ժամանակը: (Կարող է լինել զրոյին մոտ՝ նախապես տրամադրված DR կայքերի կամ Infrastructure-as-Code խողովակաշարերի դեպքում):
2. T(փոխանցում) – Տվյալների փոխանցում. Պահուստային պատճենը պահոցից տվյալների բազայի սերվեր տեղափոխելու ժամանակը:
3. T(վերականգնում) – Ֆիզիկական վերականգնում. Տվյալների ֆայլերը թիրախային սկավառակի վրա գրելու ժամանակը:
4. T(վերականգնում_բազայի) – Տվյալների բազայի վթարային վերականգնում. Տվյալների բազայի շարժիչի կողմից գործարքների մատյանները վերարտադրելու, հաստատված գործարքները առաջ տանելու և չհաստատվածները հետ շրջելու ժամանակը:

Փոխանցման և վերականգնման ժամանակների հաշվարկը

T(փոխանցում) և T(վերականգնում) հաշվարկելու համար դուք պետք է հիմք ընդունեք ձեր ցանցի թողունակությունը և սկավառակի IOPS/թողունակությունը: Մի ապավինեք տեսական առավելագույն արժեքներին. փորձարկեք ձեր իրական ենթակառուցվածքը:

Օգտագործեք iperf3-ը՝ ձեր պահուստային պահոցի և տվյալների բազայի սերվերի միջև ցանցի թողունակությունը ստուգելու համար.

# Պահուստային պահոցում (սերվեր)
iperf3 -s

# Տվյալների բազայի սերվերում (հաճախորդ)
iperf3 -c <backup_repo_ip> -t 60 -P 4

Օգտագործեք fio-ն՝ ձեր տվյալների բազայի պահեստավորման ծավալների հաջորդական գրելու արդյունավետությունը ստուգելու համար՝ սիմուլյացնելով տվյալների բազայի վերականգնման գործողությունը.

fio --name=restore_sim --ioengine=libaio --rw=write --bs=1M --size=10G --numjobs=4 --iodepth=32 --direct=1 --filename=/var/lib/postgresql/data/testfile

Եթե ձեր տվյալների բազան 5 ՏԲ է, և ձեր fio թեստերը ցույց են տալիս 500 ՄԲ/վրկ առավելագույն կայուն գրելու արագություն, ապա ձեր բացարձակ նվազագույն T(վերականգնում)-ը մոտավորապես 2.8 ժամ է: Եթե ձեր բիզնես SLA-ն պահանջում է 1-ժամյա RTO, ավանդական հոսքային վերականգնումները կձախողվեն: Դուք պետք է ձեր ճարտարապետությունը փոխեք դեպի պահեստավորման մակարդակի սնապշոթներ (snapshots) կամ բլոկային մակարդակի ռեպլիկացիա:

Թաքնված թակարդը՝ T(վերականգնում_բազայի)

Ամենահաճախ թերագնահատվող փոփոխականը T(վերականգնում_բազայի)-ն է: Եթե դուք վերականգնում եք շաբաթական ամբողջական պահուստային պատճենը և պետք է կիրառեք 6 օրվա գործարքների մատյաններ՝ ձեր RPO-ին հասնելու համար, տվյալների բազայի շարժիչը պետք է հաջորդաբար վերարտադրի յուրաքանչյուր գործարք:

500 ԳԲ գործարքների մատյանների վերարտադրումը կարող է տևել ժամեր՝ խիստ սահմանափակված միահոսքային CPU-ի արդյունավետությամբ և պահեստավորման IOPS-ով: T(վերականգնում_բազայի)-ն նվազագույնի հասցնելու համար ավելացրեք ձեր ամբողջական կամ դիֆերենցիալ պահուստային պատճենների հաճախականությունը:

Բացը կամրջելը. RTO-ն և RPO-ն վավերացնելու գործնական քայլեր

Տեսական RTO-ի և RPO-ի հաշվարկը միայն առաջին քայլն է: Առաքելության համար կարևոր միջավայրերը պահանջում են շարունակական վավերացում:

Քայլ 1. Իրականացրեք շարունակական արխիվացում

Առանց սինխրոն ռեպլիկացիայի արդյունավետության կորստի մեկ րոպեից պակաս RPO-ներ ստանալու համար իրականացրեք մատյանների շարունակական արխիվացում: Մատյանի ֆայլի լցվելուն սպասելու փոխարեն (ինչը կարող է ժամեր տևել ցածր երթևեկության ժամանակ), պարբերաբար հարկադրեք մատյանների փոխարկում:

SQL Server-ում կարող եք ավտոմատացնել գործարքների մատյանների հաճախակի պահուստավորումը.

BACKUP LOG [MissionCriticalDB] 
TO DISK = N'\BackupRepoSQLMissionCriticalDB_Log.trn' 
WITH NOFORMAT, NOINIT, 
NAME = N'MissionCriticalDB-Transaction Log Backup', 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;

Լավագույն փորձ. Պլանավորեք այս աշխատանքը՝ կախված ձեր RPO պահանջներից, յուրաքանչյուր 1-5 րոպեն մեկ գործարկելու համար:

Քայլ 2. Ավտոմատացրեք վերականգնման թեստավորումը

Չփորձարկված պահուստային պատճենը պարզապես տեսական հասկացություն է: Ձեր հաշվարկված RTO-ն երաշխավորելու համար դուք պետք է կատարեք ավտոմատացված վերականգնման թեստավորում:

CloudSave-ի նման ձեռնարկատիրական պահուստային հարթակները պարզեցնում են սա՝ ապահովելով ավտոմատացված, մեկուսացված վերականգնման թեստավորում: CloudSave-ը կարող է ավտոմատ կերպով գործարկել sandbox միջավայր, տեղադրել վերջին պահուստային պատճենը, կատարել տվյալների բազայի ամբողջական վերականգնում և գործարկել հատուկ վավերացման սկրիպտներ (օրինակ՝ DBCC CHECKDB SQL Server-ի համար)՝ ճշգրիտ RTO-ն չափելու և տվյալների ամբողջականությունը ապահովելու համար: Սա RTO-ն հաշվարկված ենթադրությունից վերածում է ապացուցված, հաշվետու չափանիշի:

Քայլ 3. Վերահսկեք և ահազանգեք SLA-ի խախտումների մասին

Ձեր մոնիտորինգի համակարգը (Prometheus, Datadog, Zabbix) պետք է ակտիվորեն հետևի այն չափանիշներին, որոնք սպառնում են ձեր RTO/RPO SLA-ներին: Ահազանգման կանոնները պետք է կազմաձևվեն հետևյալի համար.
* Պահուստավորման աշխատանքի ձախողումներ. Անմիջական սպառնալիք RPO-ին:
* Մատյանների փոխանցման ուշացում. Եթե մատյանների փոխանցումը տևում է ավելի երկար, քան գեներացման ընդմիջումը:
* Պահեստավորման IOPS-ի սահմանափակում. Ամպային մատակարարները (ինչպիսիք են AWS EBS-ը) սահմանափակում են IOPS-ը, եթե պայթյունային վարկերը (burst credits) սպառված են, ինչը իրական արտակարգ իրավիճակի ժամանակ լուռ կոչնչացնի ձեր RTO-ն:

Տվյալների բազայի պահուստավորման ճարտարապետության օպտիմալացում՝ խիստ SLA-ներին համապատասխանելու համար

Երբ մաթեմատիկական հաշվարկները ցույց են տալիս, որ ձեր ընթացիկ ճարտարապետությունը չի կարող բավարարել բիզնես SLA-ները, դուք պետք է օպտիմալացնեք ձեր պահուստավորման ռազմավարությունը:

1. Օգտագործեք բլոկային մակարդակի ինկրեմենտալ պահուստային պատճեններ

Տվյալների բազայի ավանդական դամփերը (տրամաբանական պահուստային պատճեններ, ինչպիսիք են pg_dump-ը կամ mysqldump-ը) չափազանց դանդաղ են առաքելության համար կարևոր RTO-ների համար: Օգտագործեք ֆիզիկական, բլոկային մակարդակի պահուստային պատճեններ: Բլոկային մակարդակի ինկրեմենտալ պահուստային պատճենները պատճենում են միայն այն սկավառակի բլոկները, որոնք փոխվել են վերջին պահուստավորումից հետո՝ կտրուկ նվազեցնելով T(փոխանցում)-ը և ցանցի ծանրաբեռնվածությունը:

2. Օգտագործեք պահեստավորման սնապշոթներ

Բազմատերաբայթանոց տվյալների բազաների համար, որոնք պահանջում են 15 րոպեից պակաս RTO, ֆայլերի ավանդական պատճենումը ստանդարտ ցանցերով ֆիզիկապես անհնար է: SAN-ի կամ ամպային պահեստավորման սնապշոթների (օրինակ՝ AWS EBS Snapshots, Pure Storage) հետ ինտեգրումը թույլ է տալիս հասնել գրեթե ակնթարթային T(վերականգնում)-ի: Տվյալների բազայի շարժիչը այնուհետև պետք է միայն վթարային վերականգնում կատարի սնապշոթի վրա:

3. Իրականացրեք զուգահեռականություն

Համոզվեք, որ ձեր պահուստավորման և վերականգնման գործիքներն օգտագործում են բազմահոսքային աշխատանք: pgbackrest-ի միջոցով PostgreSQL տվյալների բազան կամ SQL Server տվյալների բազան վերականգնելիս հստակ սահմանեք զուգահեռ աշխատող հոսքեր՝ ձեր հասանելի ցանցի և սկավառակի թողունակությունը հագեցնելու համար:

# pgBackRest-ում զուգահեռ վերականգնման օրինակ
pgbackrest --stanza=prod_db --process-max=8 restore

Եզրակացություն

Առաքելության համար կարևոր տվյալների բազաների համար RTO-ի և RPO-ի հաշվարկը համակարգային ճարտարագիտության խիստ վարժություն է: Այն պահանջում է, որ DBA-ները դուրս գան պահուստավորման լռելյայն կազմաձևերից և մաթեմատիկորեն մոդելավորեն իրենց պահեստավորման I/O-ն, ցանցի հզորությունը և տվյալների բազայի վերականգնման մեխանիզմները:

Մատյանների գեներացման արագությունները հիմք ընդունելով, տվյալների բազայի վերականգնման հստակ փուլերը հասկանալով և CloudSave-ի նման հզոր հարթակների միջոցով ավտոմատացված թեստավորում իրականացնելով՝ ՏՏ թիմերը կարող են վստահորեն երաշխավորել իրենց աղետների վերականգնման SLA-ները: Հիշեք. տվյալների բազայի կառավարման ոլորտում հույսը ռազմավարություն չէ, իսկ չփորձարկված պահուստային պատճենները՝ պարտավորություն:

Իմացեք, թե ինչպես DevOps ինժեներները և DBA-ները կարող են ճշգրիտ հաշվարկել, փորձարկել և օպտիմալացնել RTO-ն և RPO-ն առաքելության համար կարևոր տվյալների բազաների համար՝ օգտագործելով վերականգնման առաջադեմ մեխանիզմներ, CLI գործիքներ և ավտոմատացված թեստավորում: