DevOps inženieriem un sistēmu administratoriem virtuālo mašīnu (VM) momentuzņēmumi (snapshots) ir būtisks rīks. Tie nodrošina ātru un ērtu veidu, kā fiksēt servera stāvokli pirms riskanta ielāpa uzstādīšanas, būtiskām konfigurācijas izmaiņām vai lietotnes izvietošanas. Ja kaut kas noiet greizi, atgriešanās iepriekšējā stāvoklī aizņem tikai dažas sekundes.
Tomēr, ja šī pati metodoloģija tiek piemērota transakciju datubāzēm — piemēram, PostgreSQL, MySQL, Oracle vai Microsoft SQL Server —, VM momentuzņēmumi no drošības spilvena pārvēršas par laika bumbu.
Paļaušanās uz standarta hipervizora momentuzņēmumiem datubāžu dublēšanai ir viens no biežākajiem datu bojājumu, nepilnīgu lapu (torn pages) un neatgriezenisku ražošanas dīkstāvju cēloņiem. Šajā rakstā mēs izpētīsim arhitektūras konfliktu starp hipervizoriem un datubāžu dzinējiem, datu bojājumu mehāniku momentuzņēmumu laikā un inženiertehniskās labākās prakses, kas nepieciešamas, lai droši dublētu virtualizētas datubāzes.
Arhitektūras konflikts: Hipervizori pret datubāžu dzinējiem
Lai saprastu, kāpēc VM momentuzņēmumi apdraud datubāzes, vispirms ir jāaplūko, kā abas sistēmas pārvalda stāvokli un I/O (ievades/izvades) operācijas.
Kā hipervizori izpilda momentuzņēmumus
Kad hipervizors (piemēram, VMware ESXi, Microsoft Hyper-V vai KVM) izveido momentuzņēmumu, tas nekopē disku. Tā vietā tas iesaldē pašreizējo virtuālā diska failu (piemēram, .vmdk vai .vhdx) tikai lasīšanas režīmā un izveido jaunu delta disku (atšķirību disku). Visas turpmākās rakstīšanas operācijas tiek novirzītas uz šo delta disku.
Kad momentuzņēmums tiek dzēsts, hipervizoram ir jāapvieno (jākonsolidē) dati no delta diska atpakaļ pamatdiskā. Standarta momentuzņēmumi pilnībā nezina par lietotnēm, kas darbojas viesoperētājsistēmā. Tie fiksē diska stāvokli tieši tādu, kāds tas ir konkrētajā mikrosekundē.
Kā transakciju datubāzes pārvalda stāvokli
Transakciju datubāzes ir izstrādātas, balstoties uz ACID īpašībām (Atomitāte, Konsekvence, Izolācija, Izturība). Lai sasniegtu augstu veiktspēju, vienlaikus saglabājot ACID atbilstību, datubāzes neieraksta katru transakciju tieši primārajos datu failos uz diska uzreiz. Tā vietā tās izmanto sarežģītu, daudzlīmeņu arhitektūru:
- Buferu kopas / Koplietojamie buferi: Dati tiek nolasīti un modificēti sistēmas atmiņā.
- Iepriekšējas rakstīšanas žurnāls (WAL) / Redo žurnāli: Izmaiņas secīgi tiek rakstītas augsti optimizētā žurnālfailā uz diska, lai nodrošinātu izturību.
- Kontrolpunkti / “Lazy Writers”: Periodiski datubāze iztukšo modificētās (netīrās) lapas no atmiņas uz faktiskajiem datu failiem uz diska.
Šīs arhitektūras dēļ fiziskie datu faili uz diska gandrīz vienmēr nav sinhronizēti ar faktisko datubāzes stāvokli. Patiesais datubāzes stāvoklis pastāv tikai kā datu failu uz diska, WAL/Redo žurnālu un atmiņā esošo datu kombinācija.
Bīstamā zona: Kas notiek VM momentuzņēmuma laikā
Veidojot standarta VM momentuzņēmumu datubāzes serverim, jūs fiksējat avārijas konsekventu (crash-consistent) stāvokli.
Avārijas konsekvence pret lietotnes konsekvenci
Avārijas konsekvents momentuzņēmums ir līdzvērtīgs strāvas vada izraušanai no fiziskā servera. Diska stāvoklis tiek fiksēts, bet viss, kas atradās atmiņā, tiek zaudēts, un viss, kas bija ceļā uz krātuves kontrolieri, tiek pēkšņi pārtraukts.
Lai gan mūsdienu datubāzes ir izstrādātas tā, lai atgūtos no negaidīta strāvas zuduma, atkārtojot iepriekšējas rakstīšanas žurnālu, paļaušanās uz avārijas atkopšanu kā galveno dublēšanas stratēģiju ir ļoti bīstama. Ja jūsu datubāze aptver vairākus virtuālos diskus (piemēram, datu faili uz D: diska un WAL uz E: diska), hipervizors var neizveidot abu disku momentuzņēmumu vienā un tajā pašā mikrosekundē. Ja WAL diska momentuzņēmums tiek fiksēts kaut vai sekundes daļu pēc datu diska momentuzņēmuma, datubāze pēc atjaunošanas nevar saskaņot secības numurus, kas izraisa fatālus bojājumus.
“VM Stun” efekts sistēmās ar augstu transakciju skaitu
Momentuzņēmuma izveides process — un vēl svarīgāk, momentuzņēmuma konsolidācijas process — izraisa parādību, ko sauc par “VM Stun” (virtuālās mašīnas apstādināšanu).
Lai droši pārslēgtu I/O no pamatdiska uz delta disku, hipervizoram ir uz īsu brīdi jāpauzē (jāapstādina) virtuālā mašīna. Viegli noslogotam tīmekļa serverim šī pauze var ilgt 10–50 milisekundes un palikt nepamanīta. Tomēr datubāzei ar augstu caurlaidspēju un masīvu I/O, liela delta diska konsolidācija var apstādināt VM uz vairākām sekundēm.
VM pauzes laikā:
* Tīkla savienojumi pārtrūkst, izraisot lietotņu taimautus.
* Augstas pieejamības klasteri (piemēram, SQL Server Always On, PostgreSQL Patroni vai MySQL Galera) palaiž garām “heartbeat” pārbaudes.
* Klasteris var pieņemt, ka apstādinātais mezgls ir miris, izraisot nevajadzīgu un traucējošu failover (split-brain scenārijs).
Nepilnīgas lapas (Torn Pages) un I/O nesaskaņotība
Datubāžu dzinēji parasti raksta datus noteiktos lapu izmēros (piemēram, 8KB PostgreSQL un SQL Server, 16KB InnoDB). Tomēr pamatā esošā operētājsistēma un krātuves masīvi apstrādā I/O mazākos blokos (piemēram, 4KB vai 512 baiti).
Ja hipervizors izveido momentuzņēmumu tieši brīdī, kad datubāze raksta 8KB lapu, momentuzņēmums var fiksēt pirmos 4KB jauno datu un pēdējos 4KB veco datu. Tas rada nepilnīgu lapu (torn page). Mēģinot atjaunot momentuzņēmumu, datubāze nolasīs lapu, neizturēs kontrolsummas validāciju un atzīmēs datubāzi kā bojātu.
Reālās sekas konkrētiem datubāžu dzinējiem
Dažādi datubāžu dzinēji uz avārijas konsekventiem momentuzņēmumiem reaģē dažādi, taču neviens no tiem to neapstrādā korekti ražošanas vidē.
- PostgreSQL: PostgreSQL lielā mērā paļaujas uz
pg_waldirektoriju. Ja momentuzņēmums fiksē datu direktoriju ($PGDATA) un WAL nesinhroni, PostgreSQL neizdosies startēt, izmetot kļūduPANIC: could not locate a valid checkpoint record. - MySQL/InnoDB: InnoDB izmanto “doublewrite buffer”, lai novērstu nepilnīgas lapas, kas sniedz zināmu aizsardzību pret avārijas konsekventiem stāvokļiem. Tomēr, ja
ibdata1fails unib_logfiletiek fiksēti nesinhroni, InnoDB dzinējs pēc atkopšanas avarēs. - Microsoft SQL Server: SQL Server ir ļoti jutīgs pret I/O iesaldēšanu. Bez pienācīgas VSS (Volume Shadow Copy Service) integrācijas, SQL Server atjaunošana no standarta VM momentuzņēmuma bieži vien noved pie “suspect” datubāzēm un bojātām žurnālu ķēdēm, iznīcinot jūsu Point-in-Time Recovery (PITR) iespējas.
Labākā prakse virtualizētu datubāžu drošai dublēšanai
Lai aizsargātu transakciju datubāzes, jums ir jāpāriet no avārijas konsekventiem dublējumiem uz lietotnes konsekventiem (application-consistent) dublējumiem. Tas prasa, lai dublēšanas mehānisms sazinātos ar datubāzes dzinēju, liekot tam iztukšot atmiņu uz disku un uz brīdi pauzēt I/O operācijas, kamēr tiek veikts momentuzņēmums.
1. Izmantojiet lietotnes atpazīšanas iesaldēšanu (VSS un fsfreeze)
Windows (SQL Server):
Vienmēr pārliecinieties, ka jūsu dublēšanas risinājums izmanto Microsoft Volume Shadow Copy Service (VSS). Kad tiek aktivizēts VSS atpazīstošs dublējums, SQL Server VSS Writer iesaldē datubāzes I/O, iztukšo neizpildītās transakcijas uz disku un nodrošina, ka momentuzņēmums ir pilnībā lietotnes konsekvents.
Linux (PostgreSQL / MySQL):
Linux nav natīva VSS ekvivalenta. Lai panāktu lietotnes konsekvenci, jums jāizmanto “pre-freeze” un “post-thaw” skripti kopā ar hipervizora viesrīkiem (piemēram, VMware Tools).
Šeit ir piemērs VMware pre-freeze-script priekš PostgreSQL 15+, kas droši sagatavo datubāzi momentuzņēmumam:
#!/bin/bash
# /usr/sbin/pre-freeze-script
# Pārliecinieties, ka šis skripts ir izpildāms (chmod +x)
# 1. Lieciet PostgreSQL sagatavoties dublējumam
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""
# 2. Iztukšojiet failu sistēmas buferus uz disku
sync
# 3. Iesaldējiet failu sistēmu (pieņemot, ka dati atrodas /var/lib/pgsql)
fsfreeze -f /var/lib/pgsql
Un atbilstošais post-thaw-script darbību atsākšanai:
#!/bin/bash
# /usr/sbin/post-thaw-script
# 1. Atsaldējiet failu sistēmu
fsfreeze -u /var/lib/pgsql
# 2. Paziņojiet PostgreSQL, ka dublējums ir pabeigts
su - postgres -c "psql -c "SELECT pg_backup_stop();""
2. Izmantojiet natīvās datubāzes dublēšanas utilītas
Lai gan lietotnes konsekventi momentuzņēmumi ir labāki par standarta momentuzņēmumiem, tie joprojām rada VM pauzes risku. Drošākā pieeja datubāžu dublēšanai ir izmantot natīvas, straumējošas dublēšanas utilītas, kas darbojas neatkarīgi no hipervizora.
PostgreSQL (pg_basebackup):
pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P
MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Šie rīki veic “karstos”, nebloķējošos dublējumus, kopējot datu failus un vienlaikus izsekojot izmaiņām redo žurnālā.
mariabackup --backup --target-dir=/mnt/backups/mysql_backup --user=root --password=SecurePass
SQL Server (T-SQL):
BACKUP DATABASE [ProductionDB]
TO DISK = N'Z:BackupsProductionDB.bak'
WITH NOFORMAT, NOINIT, NAME = N'ProductionDB-Full Backup',
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;
GO
3. Ieviesiet Point-in-Time Recovery (PITR), izmantojot žurnālu arhivēšanu
Ikdienas momentuzņēmums vai pilns dublējums aizsargā jūs tikai līdz brīdim, kad tas tika veikts. Ja jūsu datubāze avarē plkst. 16:00 un pēdējais momentuzņēmums bija plkst. 02:00, jūs zaudējat 14 stundu transakciju datus.
Lai sasniegtu patiesu uzņēmuma līmeņa noturību, jums ir jāapvieno pilni lietotnes konsekventi dublējumi ar nepārtrauktu žurnālu arhivēšanu (WAL, Redo žurnālu vai transakciju žurnālu dublēšana ik pēc dažām minūtēm). Tas ļauj datubāžu administratoriem atjaunot datubāzi uz konkrētu minūti vai pat konkrētu transakcijas ID pirms katastrofas.
Uzņēmuma līmeņa dublēšanas stratēģijas ar CloudSave
Pielāgotu “pre-freeze” skriptu, cron darbu natīvām izgāztuvēm un žurnālu sūtīšanas pārvaldība desmitiem datubāžu serveru ir operatīvs murgs DevOps komandām. Šeit kļūst kritiska uzņēmuma līmeņa platforma, piemēram, CloudSave.
CloudSave aizpilda plaisu starp virtualizāciju un datubāžu arhitektūru. Tā vietā, lai paļautos uz aklajiem hipervizora momentuzņēmumiem, CloudSave izmanto lietotnes atpazīstošus aģentus, kas natīvi integrējas ar SQL Server, PostgreSQL, MySQL un Oracle.
Kad CloudSave uzsāk dublēšanu:
1. Tā sazinās tieši ar datubāzes dzinēju, izmantojot natīvās API (piemēram, VSS Windows vai natīvo WAL straumēšanu Linux).
2. Tā organizē atmiņas buferu iztukšošanu uz disku, neizraisot traucējošas VM pauzes.
3. Tā droši fiksē datu failus un automātiski pārvalda transakciju žurnālu saīsināšanu.
4. Tā nepārtraukti dublē transakciju žurnālus, nodrošinot granulāru Point-in-Time Recovery (PITR) ar dažiem klikšķiem.
Atslogojot lietotnes konsekvences sarežģītību uz CloudSave, datubāžu administratori un sistēmu administratori var garantēt datu integritāti, neupurējot savu ražošanas klasteru veiktspēju vai pieejamību.
Secinājums
Virtuālo mašīnu momentuzņēmumi ir neticams rīks infrastruktūras pārvaldībai, taču tie ir fundamentāli nesaderīgi ar transakciju datubāžu ACID prasībām. Paļaušanās uz avārijas konsekventiem hipervizora momentuzņēmumiem pakļauj jūsu organizāciju nepilnīgu lapu, bojātu replikācijas ķēžu un katastrofāla datu zuduma riskam.
Lai aizsargātu savus kritiski svarīgos datus, jums ir jāievieš lietotnes atpazīstoša iesaldēšana, jāizmanto natīvas datubāžu dublēšanas metodoloģijas un jāuztur nepārtraukti transakciju žurnālu arhīvi. Pieņemot īpaši izstrādātus uzņēmuma līmeņa dublēšanas risinājumus, jūs varat nodrošināt, ka jūsu datubāzes paliek augsti pieejamas, pilnībā atjaunojamas un pilnīgi drošas.
