DevOps inžinieriams, duomenų bazių administratoriams (DBA) ir IT sistemų architektams atkūrimo laiko tikslas (RTO) ir atkūrimo taško tikslas (RPO) yra daugiau nei tik verslo tęstinumo terminai – tai griežti inžineriniai apribojimai. Valdant kritinės svarbos duomenų bazes, nesugebėjimas tiksliai apskaičiuoti, suplanuoti ir patikrinti šių rodiklių gali sukelti katastrofišką duomenų praradimą ir ilgalaikę prastovą.
Šiuolaikinėje įmonių aplinkoje RTO ir RPO skaičiavimui reikia gilaus duomenų bazių vidinės struktūros, saugyklų I/O, tinklo pralaidumo ir operacijų žurnalo mechanikos išmanymo. Šiame vadove nagrinėjami techniniai metodai, skirti apskaičiuoti, išbandyti ir optimizuoti RTO ir RPO gamybinėse duomenų bazių sistemose.
RPO (atkūrimo taško tikslo) išskaidymas duomenų bazių sistemose
RPO apibrėžia maksimalų priimtiną duomenų praradimo kiekį, matuojamą laiku. Jei jūsų RPO yra 15 minučių, tai reiškia, kad įvykus nelaimei 12:00 val., privalote sugebėti atkurti visas patvirtintas operacijas bent iki 11:45 val.
Duomenų bazėms RPO diktuoja jūsų operacijų žurnalo valdymo strategija (WAL „PostgreSQL“, „Redo Logs“ „Oracle“, operacijų žurnalai „SQL Server“).
Duomenų praradimo ir žurnalų generavimo mechanika
Norėdami apskaičiuoti pasiekiamą RPO, pirmiausia turite suprasti savo duomenų bazės operacijų žurnalo generavimo greitį. Jei žurnalus į atsarginių kopijų saugyklą siunčiate kas 15 minučių, bet jūsų tinklas negali per tą laiką perkelti 15 minučių žurnalų, jūsų faktinis RPO nuolat blogės.
Galite nustatyti savo žurnalo generavimo greičio bazinį lygį naudodami vietines SQL komandas. Pavyzdžiui, „PostgreSQL“ (10 ir naujesnėse versijose) galite išmatuoti „Write-Ahead Log“ (WAL) generavimo greitį per tam tikrą intervalą:
-- Paleiskite tai esant T=0
SELECT pg_current_wal_lsn() AS start_lsn;
-- Palaukite lygiai 5 minutes (300 sekundžių), tada paleiskite:
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;
Jei ši užklausa rodo, kad piko metu generuojate 50 MB/s WAL duomenų, 15 minučių RPO reikalauja perkelti 45 GB žurnalo duomenų į atsarginių kopijų saugyklą. Jūsų tinklas ir saugyklos tikslai turi palaikyti pastovų rašymo greitį, viršijantį 50 MB/s, kad būtų išlaikytas šis RPO.
Sinchroninės ir asinchroninės replikacijos poveikis
Daugelis DBA pasikliauja didelio pasiekiamumo (HA) replikacija, kad patenkintų RPO. Tačiau replikacija nėra atsarginė kopija. Ištrinta lentelė (DROP TABLE users;) replikuojama akimirksniu.
Naudojant replikaciją atkūrimui po nelaimės (DR), replikacijos režimas tiesiogiai veikia RPO:
* Sinchroninė replikacija: Garantuoja nulinį RPO (RPO=0). Pagrindinė duomenų bazė nepatvirtins operacijos, kol budinti duomenų bazė nepatvirtins jos gavimo. Kompromisas – padidėjęs vėlavimas atliekant pagrindines rašymo operacijas.
* Asinchroninė replikacija: Įveda replikacijos vėlavimą. Jūsų RPO faktiškai yra lygus jūsų dabartiniam replikacijos vėlavimui.
Norėdami stebėti asinchroninės replikacijos vėlavimą „PostgreSQL“, naudokite:
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 (atkūrimo laiko tikslo) išskaidymas didelio masto duomenų bazėms
RTO yra maksimali toleruotina prastovos trukmė. Duomenų bazės RTO skaičiavimas yra itin sudėtingas, nes tai nėra tik laikas, reikalingas failams nukopijuoti atgal į serverį.
Matematinis RTO skaičiavimo modelis
Realistinis duomenų bazės RTO skaičiavimas turi apimti keturias skirtingas fazes:
RTO = T(infra) + T(transfer) + T(restore) + T(recovery)
- T(infra) – Infrastruktūros paruošimas: Laikas, skirtas pakeičiamai skaičiavimo ir saugojimo įrangai paleisti. (Gali būti beveik nulinis naudojant iš anksto paruoštas DR svetaines arba „Infrastructure-as-Code“ vamzdynus).
- T(transfer) – Duomenų perdavimas: Laikas, skirtas perkelti atsarginės kopijos duomenis iš saugyklos į duomenų bazės serverį.
- T(restore) – Fizinis atkūrimas: Laikas, skirtas duomenų failams įrašyti į tikslinį diską.
- T(recovery) – Duomenų bazės atkūrimas po avarijos: Laikas, per kurį duomenų bazės variklis pakartoja operacijų žurnalus, įvykdo patvirtintas operacijas ir atšaukia nepatvirtintas.
Perdavimo ir atkūrimo laiko skaičiavimas
Norėdami apskaičiuoti T(transfer) ir T(restore), turite nustatyti savo tinklo pralaidumo ir disko IOPS/pralaidumo bazinį lygį. Nepasikliaukite teoriniais maksimumais; išbandykite savo faktinę infrastruktūrą.
Naudokite iperf3 tinklo pralaidumui tarp atsarginių kopijų saugyklos ir duomenų bazės serverio patikrinti:
# Atsarginių kopijų saugykloje (serveris)
iperf3 -s
# Duomenų bazės serveryje (klientas)
iperf3 -c <backup_repo_ip> -t 60 -P 4
Naudokite fio duomenų bazės saugyklos tomų nuoseklaus rašymo našumui patikrinti, imituojant duomenų bazės atkūrimo operaciją:
fio --name=restore_sim --ioengine=libaio --rw=write --bs=1M --size=10G --numjobs=4 --iodepth=32 --direct=1 --filename=/var/lib/postgresql/data/testfile
Jei jūsų duomenų bazė yra 5 TB, o fio testai rodo maksimalų pastovų rašymo greitį 500 MB/s, jūsų absoliutus minimalus T(restore) yra maždaug 2,8 valandos. Jei jūsų verslo SLA reikalauja 1 valandos RTO, tradiciniai srautinio atkūrimo metodai neveiks. Turite pakeisti savo architektūrą į saugyklos lygio momentines kopijas (snapshots) arba blokinio lygio replikaciją.
Paslėpti spąstai: T(recovery)
Dažniausiai neįvertinamas kintamasis yra T(recovery). Jei atstatote savaitinę pilną atsarginę kopiją ir turite pritaikyti 6 dienų operacijų žurnalus, kad pasiektumėte savo RPO, duomenų bazės variklis turi nuosekliai pakartoti kiekvieną operaciją.
500 GB operacijų žurnalų pakartojimas gali užtrukti valandas, o tai labai riboja vienos gijos procesoriaus našumas ir saugyklos IOPS. Norėdami sumažinti T(recovery), padidinkite pilnų arba diferencinių atsarginių kopijų dažnumą.
Spragos užpildymas: praktiniai žingsniai RTO ir RPO patvirtinimui
Teorinio RTO ir RPO skaičiavimas yra tik pirmas žingsnis. Kritinės svarbos aplinkoms reikalingas nuolatinis patvirtinimas.
1 žingsnis: Įdiekite nuolatinį archyvavimą
Norėdami pasiekti mažesnį nei minutės RPO be sinchroninės replikacijos našumo nuostolių, įdiekite nuolatinį žurnalų archyvavimą. Užuot laukę, kol žurnalo failas užsipildys (kas mažo srauto laikotarpiais gali užtrukti valandas), priverskite žurnalus persijungti reguliariais intervalais.
„SQL Server“ galite automatizuoti dažną operacijų žurnalo atsarginių kopijų kūrimą:
BACKUP LOG [MissionCriticalDB]
TO DISK = N'\BackupRepoSQLMissionCriticalDB_Log.trn'
WITH NOFORMAT, NOINIT,
NAME = N'MissionCriticalDB-Transaction Log Backup',
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;
Geriausia praktika: Suplanuokite šią užduotį kas 1–5 minutes, atsižvelgiant į jūsų RPO reikalavimus.
2 žingsnis: Automatizuokite atkūrimo testavimą
Neišbandyta atsarginė kopija yra tik teorinė koncepcija. Norėdami garantuoti savo apskaičiuotą RTO, privalote atlikti automatizuotą atkūrimo testavimą.
Įmonių atsarginių kopijų platformos, tokios kaip „CloudSave“, supaprastina šį procesą, suteikdamos automatizuotą, izoliuotą atkūrimo testavimą. „CloudSave“ gali automatiškai paleisti smėlio dėžės (sandbox) aplinką, prijungti naujausią atsarginę kopiją, atlikti pilną duomenų bazės atkūrimą ir vykdyti pasirinktinius patvirtinimo scenarijus (pvz., DBCC CHECKDB „SQL Server“), kad išmatuotų tikslų RTO ir užtikrintų duomenų vientisumą. Tai paverčia RTO iš apskaičiuoto spėjimo į įrodytą, ataskaitose pateikiamą rodiklį.
3 žingsnis: Stebėkite ir įspėkite apie SLA pažeidimus
Jūsų stebėjimo sistema („Prometheus“, „Datadog“, „Zabbix“) turėtų aktyviai sekti rodiklius, kurie kelia grėsmę jūsų RTO/RPO SLA. Įspėjimo taisyklės turėtų būti sukonfigūruotos šiems atvejams:
* Atsarginių kopijų kūrimo užduočių nesėkmės: Tiesioginė grėsmė RPO.
* Žurnalų siuntimo vėlavimas: Jei žurnalų perkėlimas trunka ilgiau nei generavimo intervalas.
* Saugyklos IOPS ribojimas: Debesijos paslaugų teikėjai (pvz., AWS EBS) riboja IOPS, jei išnaudojami „burst“ kreditai, o tai avarijos metu tyliai sugriaus jūsų RTO.
Duomenų bazių atsarginių kopijų architektūros optimizavimas siekiant atitikti griežtus SLA
Kai matematiniai skaičiavimai rodo, kad jūsų dabartinė architektūra negali atitikti verslo SLA, turite optimizuoti savo atsarginių kopijų strategiją.
1. Naudokite blokinio lygio papildomas (incremental) atsargines kopijas
Tradiciniai duomenų bazių išrašai (loginės atsarginės kopijos, pvz., pg_dump arba mysqldump) yra per lėti kritinės svarbos RTO. Naudokite fizines, blokinio lygio atsargines kopijas. Blokinio lygio papildomos atsarginės kopijos kopijuoja tik tuos disko blokus, kurie pasikeitė nuo paskutinės atsarginės kopijos, drastiškai sumažindamos T(transfer) ir tinklo apkrovą.
2. Naudokite saugyklos momentines kopijas (snapshots)
Kelių terabaitų duomenų bazėms, kurioms reikalingas mažesnis nei 15 minučių RTO, tradicinis failų kopijavimas per standartinius tinklus yra fiziškai neįmanomas. Integracija su SAN arba debesijos saugyklų momentinėmis kopijomis (pvz., AWS EBS Snapshots, „Pure Storage“) leidžia pasiekti beveik momentinį T(restore). Tada duomenų bazės varikliui tereikia atlikti atkūrimą po avarijos iš momentinės kopijos.
3. Įdiekite lygiagretumą
Užtikrinkite, kad jūsų atsarginių kopijų kūrimo ir atkūrimo įrankiai naudotų daugiagijį apdorojimą. Atkurdami „PostgreSQL“ duomenų bazę naudodami pgbackrest arba „SQL Server“ duomenų bazę, aiškiai apibrėžkite lygiagrečias darbo gijas, kad išnaudotumėte turimą tinklo ir disko pralaidumą.
# Lygiagretaus atkūrimo pavyzdys naudojant pgBackRest
pgbackrest --stanza=prod_db --process-max=8 restore
Išvada
RTO ir RPO skaičiavimas kritinės svarbos duomenų bazėms yra griežtas sistemų inžinerijos pratimas. Tai reikalauja, kad DBA peržengtų numatytųjų atsarginių kopijų konfigūracijų ribas ir matematiškai modeliuotų savo saugyklos I/O, tinklo pajėgumus ir duomenų bazės atkūrimo mechaniką.
Nustatydamos žurnalų generavimo greičio bazinius lygius, suprasdamos skirtingas duomenų bazės atkūrimo fazes ir įdiegdamos automatizuotą testavimą per patikimas platformas, tokias kaip „CloudSave“, IT komandos gali užtikrintai garantuoti savo atkūrimo po nelaimės SLA. Atminkite: duomenų bazių administravimo srityje viltis nėra strategija, o neišbandytos atsarginės kopijos yra rizika.
Sužinokite, kaip DevOps inžinieriai ir DBA gali tiksliai apskaičiuoti, išbandyti ir optimizuoti RTO ir RPO kritinės svarbos duomenų bazėms naudodami pažangią atkūrimo mechaniką, CLI įrankius ir automatizuotą testavimą.
