DevOps inženieriem, datubāžu administratoriem (DBA) un IT sistēmu arhitektiem atjaunošanas laika mērķis (RTO) un atjaunošanas punkta mērķis (RPO) ir kas vairāk nekā tikai biznesa nepārtrauktības žargons — tie ir stingri inženiertehniskie ierobežojumi. Pārvaldot kritiski svarīgas datubāzes, nespēja precīzi aprēķināt, izstrādāt arhitektūru un validēt šos rādītājus var izraisīt katastrofālu datu zudumu un ilgstošu dīkstāvi.
Mūsdienu uzņēmumu vidēs RTO un RPO aprēķināšanai ir nepieciešama padziļināta izpratne par datubāzes iekšējo darbību, krātuves I/O, tīkla caurlaidspēju un transakciju žurnālu mehāniku. Šajā rokasgrāmatā ir aplūkotas tehniskās metodoloģijas RTO un RPO aprēķināšanai, testēšanai un optimizēšanai ražošanas datubāžu sistēmām.
RPO (atjaunošanas punkta mērķa) dekonstrukcija datubāžu sistēmās
RPO nosaka maksimālo pieļaujamo datu zuduma apjomu, kas mērīts laikā. Ja jūsu RPO ir 15 minūtes, katastrofa, kas notiek plkst. 12:00, nozīmē, ka jums ir jāspēj atjaunot visas apstiprinātās transakcijas vismaz līdz plkst. 11:45.
Datubāzēm RPO nosaka jūsu transakciju žurnālu pārvaldības stratēģija (WAL PostgreSQL, Redo žurnāli Oracle, transakciju žurnāli SQL Server).
Datu zuduma un žurnālu ģenerēšanas mehānika
Lai aprēķinātu sasniedzamo RPO, vispirms ir jāsaprot jūsu datubāzes transakciju žurnālu ģenerēšanas ātrums. Ja jūs sūtāt žurnālus uz rezerves kopiju repozitoriju ik pēc 15 minūtēm, bet jūsu tīkls nespēj pārsūtīt 15 minūšu žurnālus šajā logā, jūsu faktiskais RPO pastāvīgi pasliktināsies.
Jūs varat noteikt žurnālu ģenerēšanas ātruma bāzes līniju, izmantojot SQL komandas. Piemēram, PostgreSQL (versija 10+) varat izmērīt Write-Ahead Log (WAL) ģenerēšanas ātrumu noteiktā intervālā:
-- Izpildiet šo pie T=0
SELECT pg_current_wal_lsn() AS start_lsn;
-- Pagaidiet tieši 5 minūtes (300 sekundes), tad izpildiet:
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;
Ja šis vaicājums atklāj, ka maksimālās slodzes laikā jūs ģenerējat 50 MB/s WAL datu, 15 minūšu RPO prasa pārsūtīt 45 GB žurnālu datu uz jūsu rezerves krātuvi. Jūsu tīklam un krātuves mērķiem ir jāatbalsta pastāvīgs rakstīšanas ātrums, kas pārsniedz 50 MB/s, lai saglabātu šo RPO.
Sinhronās un asinhronās replikācijas ietekme
Daudzi DBA paļaujas uz augstas pieejamības (HA) replikāciju, lai izpildītu RPO. Tomēr replikācija nav rezerves kopija. Izdzēsta tabula (DROP TABLE users;) tiek replicēta acumirklī.
Izmantojot replikāciju katastrofu atkopšanai (DR), replikācijas režīms tieši ietekmē RPO:
* Sinhronā replikācija: Garantē nulles RPO (RPO=0). Primārā datubāze neapstiprinās transakciju, kamēr gaidstāves (standby) datubāze neapstiprinās tās saņemšanu. Kompromiss ir palielināta latentuma pakāpe primārajās rakstīšanas operācijās.
* Asinhronā replikācija: Ievieš replikācijas aizkavi. Jūsu RPO faktiski ir vienāds ar jūsu pašreizējo replikācijas aizkavi.
Lai uzraudzītu asinhronās replikācijas aizkavi PostgreSQL, izmantojiet:
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 (atjaunošanas laika mērķa) dekonstrukcija liela mēroga datubāzēm
RTO ir maksimālais pieļaujamais dīkstāves ilgums. Datubāzes RTO aprēķināšana ir ļoti sarežģīta, jo tas nav tikai laiks, kas nepieciešams failu kopēšanai atpakaļ uz serveri.
RTO aprēķināšanas matemātiskais modelis
Reālistiskā datubāzes RTO aprēķinā ir jāņem vērā četras atšķirīgas fāzes:
RTO = T(infra) + T(transfer) + T(restore) + T(recovery)
- T(infra) – Infrastruktūras nodrošināšana: Laiks, lai iedarbinātu aizstājējresursus un krātuvi. (Var būt tuvu nullei ar iepriekš nodrošinātām DR vietnēm vai Infrastructure-as-Code cauruļvadiem).
- T(transfer) – Datu pārsūtīšana: Laiks, lai pārvietotu rezerves kopijas datus no repozitorija uz datubāzes serveri.
- T(restore) – Fiziskā atjaunošana: Laiks, lai ierakstītu datu failus mērķa diskā.
- T(recovery) – Datubāzes avārijas atkopšana: Laiks, kas nepieciešams datubāzes dzinējam, lai atkārtoti atskaņotu transakciju žurnālus, veiktu apstiprināto transakciju izpildi un atceltu neapstiprinātās.
Pārsūtīšanas un atjaunošanas laiku aprēķināšana
Lai aprēķinātu T(transfer) un T(restore), jums ir jānosaka sava tīkla joslas platuma un diska IOPS/caurlaidspējas bāzes līnija. Nepaļaujieties uz teorētiskajiem maksimumiem; pārbaudiet savu faktisko infrastruktūru.
Izmantojiet iperf3, lai pārbaudītu tīkla caurlaidspēju starp jūsu rezerves kopiju repozitoriju un datubāzes serveri:
# Rezerves kopiju repozitorijā (serverī)
iperf3 -s
# Datubāzes serverī (klientā)
iperf3 -c <backup_repo_ip> -t 60 -P 4
Izmantojiet fio, lai pārbaudītu savu datubāzes krātuves sējumu secīgās rakstīšanas veiktspēju, simulējot datubāzes atjaunošanas operāciju:
fio --name=restore_sim --ioengine=libaio --rw=write --bs=1M --size=10G --numjobs=4 --iodepth=32 --direct=1 --filename=/var/lib/postgresql/data/testfile
Ja jūsu datubāze ir 5 TB un jūsu fio testi uzrāda maksimālo pastāvīgo rakstīšanas ātrumu 500 MB/s, jūsu absolūtais minimālais T(restore) ir aptuveni 2,8 stundas. Ja jūsu biznesa SLA pieprasa 1 stundas RTO, tradicionālā straumēšanas atjaunošana neizdosies. Jums ir jāmaina sava arhitektūra uz krātuves līmeņa momentuzņēmumiem vai bloku līmeņa replikāciju.
Slēptais slazds: T(recovery)
Visbiežāk nepienovērtētais mainīgais ir T(recovery). Ja atjaunojat iknedēļas pilno rezerves kopiju un jums ir jāpiemēro 6 dienu transakciju žurnāli, lai sasniegtu savu RPO, datubāzes dzinējam ir secīgi jāatskaņo katra transakcija.
500 GB transakciju žurnālu atskaņošana var aizņemt stundas, ko būtiski ierobežo vienas vītnes CPU veiktspēja un krātuves IOPS. Lai samazinātu T(recovery), palieliniet savu pilno vai diferenciālo rezerves kopiju biežumu.
Atšķirību mazināšana: praktiski soļi RTO un RPO validēšanai
Teorētiskā RTO un RPO aprēķināšana ir tikai pirmais solis. Kritiski svarīgām vidēm ir nepieciešama nepārtraukta validācija.
1. solis: Ieviesiet nepārtrauktu arhivēšanu
Lai sasniegtu zem minūtes RPO bez sinhronās replikācijas veiktspējas samazinājuma, ieviesiet nepārtrauktu žurnālu arhivēšanu. Tā vietā, lai gaidītu, līdz žurnāla fails aizpildās (kas var aizņemt stundas zemas trafika periodos), piespiedu kārtā veiciet žurnālu pārslēgšanu regulāros intervālos.
SQL Server varat automatizēt biežas transakciju žurnālu rezerves kopijas:
BACKUP LOG [MissionCriticalDB]
TO DISK = N'\BackupRepoSQLMissionCriticalDB_Log.trn'
WITH NOFORMAT, NOINIT,
NAME = N'MissionCriticalDB-Transaction Log Backup',
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;
Labākā prakse: Ieplānojiet šo uzdevumu izpildei ik pēc 1–5 minūtēm atkarībā no jūsu RPO prasībām.
2. solis: Automatizējiet atjaunošanas testēšanu
Nepārbaudīta rezerves kopija ir tikai teorētisks jēdziens. Lai garantētu savu aprēķināto RTO, jums ir jāveic automatizēta atjaunošanas testēšana.
Uzņēmumu rezerves kopiju platformas, piemēram, CloudSave, to vienkāršo, nodrošinot automatizētu, izolētu atkopšanas testēšanu. CloudSave var automātiski iedarbināt smilškastes vidi, uzstādīt jaunāko rezerves kopiju, veikt pilnu datubāzes atkopšanu un izpildīt pielāgotus validācijas skriptus (piemēram, DBCC CHECKDB SQL Server), lai izmērītu precīzu RTO un nodrošinātu datu integritāti. Tas pārvērš RTO no aprēķināta minējuma par pierādītu, atskaitāmu rādītāju.
3. solis: Uzraugiet un brīdiniet par SLA pārkāpumiem
Jūsu uzraudzības stakam (Prometheus, Datadog, Zabbix) ir aktīvi jāseko rādītājiem, kas apdraud jūsu RTO/RPO SLA. Brīdinājumu noteikumi jākonfigurē šādiem gadījumiem:
* Rezerves kopiju uzdevumu kļūmes: Tūlītēji draudi RPO.
* Žurnālu sūtīšanas latentums: Ja žurnālu pārsūtīšana aizņem ilgāku laiku nekā ģenerēšanas intervāls.
* Krātuves IOPS ierobežošana: Mākoņpakalpojumu sniedzēji (piemēram, AWS EBS) ierobežo IOPS, ja pārsniegti “burst” kredīti, kas ārkārtas situācijā klusi iznīcinās jūsu RTO.
Datubāzes rezerves kopiju arhitektūras optimizēšana, lai izpildītu stingrus SLA
Kad matemātiskie aprēķini atklāj, ka jūsu pašreizējā arhitektūra nespēj izpildīt biznesa SLA, jums ir jāoptimizē sava rezerves kopiju stratēģija.
1. Izmantojiet bloku līmeņa inkrementālās rezerves kopijas
Tradicionālās datubāžu izgāztuves (loģiskās rezerves kopijas, piemēram, pg_dump vai mysqldump) ir pārāk lēnas kritiski svarīgiem RTO. Izmantojiet fiziskās, bloku līmeņa rezerves kopijas. Bloku līmeņa inkrementālās rezerves kopijas kopē tikai tos diska blokus, kas ir mainījušies kopš pēdējās rezerves kopijas, būtiski samazinot T(transfer) un tīkla noslodzi.
2. Izmantojiet krātuves momentuzņēmumus
Datubāzēm ar vairākiem terabaitiem, kurām nepieciešams RTO, kas mazāks par 15 minūtēm, tradicionālā failu kopēšana pa standarta tīkliem ir fiziski neiespējama. Integrācija ar SAN vai mākoņa vietējiem krātuves momentuzņēmumiem (piemēram, AWS EBS Snapshots, Pure Storage) ļauj panākt gandrīz tūlītēju T(restore). Pēc tam datubāzes dzinējam ir jāveic tikai avārijas atkopšana no momentuzņēmuma.
3. Ieviesiet paralēlismu
Pārliecinieties, ka jūsu rezerves kopiju un atjaunošanas rīki izmanto vairākvītņu apstrādi. Atjaunojot PostgreSQL datubāzi, izmantojot pgbackrest, vai SQL Server datubāzi, skaidri definējiet paralēlos darba pavedienus, lai piesātinātu pieejamo tīkla un diska joslas platumu.
# Paralēlās atjaunošanas piemērs ar pgBackRest
pgbackrest --stanza=prod_db --process-max=8 restore
Secinājums
RTO un RPO aprēķināšana kritiski svarīgām datubāzēm ir rūpīgs sistēmu inženierijas vingrinājums. Tas prasa, lai DBA pārsniegtu noklusējuma rezerves kopiju konfigurācijas un matemātiski modelētu savu krātuves I/O, tīkla jaudu un datubāzes atkopšanas mehāniku.
Nosakot žurnālu ģenerēšanas ātruma bāzes līniju, izprotot atšķirīgās datubāzes atkopšanas fāzes un ieviešot automatizētu testēšanu, izmantojot stabilas platformas, piemēram, CloudSave, IT komandas var pārliecinoši garantēt savus katastrofu atkopšanas SLA. Atcerieties: datubāžu administrēšanas jomā cerība nav stratēģija, un nepārbaudītas rezerves kopijas ir risks.
Uzziniet, kā DevOps inženieri un DBA var precīzi aprēķināt, testēt un optimizēt RTO un RPO kritiski svarīgām datubāzēm, izmantojot uzlabotu atkopšanas mehāniku, CLI rīkus un automatizētu testēšanu.
