За DevOps инженерите и системните администратори, снимките (snapshots) на виртуални машини (VM) се основен инструмент. Тие обезбедуваат брз и удобен начин за снимање на состојбата на серверот пред ризична надградба, голема промена во конфигурацијата или распоредување на апликација. Ако нешто тргне наопаку, враќањето на претходната состојба трае неколку секунди.
Меѓутоа, кога оваа иста методологија се применува на трансакциски бази на податоци—како што се PostgreSQL, MySQL, Oracle или Microsoft SQL Server—снимките на виртуелни машини се трансформираат од безбедносна мрежа во темпирана бомба.
Потпирањето на стандардни хипервизорски снимки за резервни копии на бази на податоци е една од најчестите причини за оштетување на податоци, „искинати страници“ (torn pages) и неповратно паѓање на продукциските системи. Во оваа статија, ќе го истражиме архитектонскиот судир помеѓу хипервизорите и моторите на базите на податоци, механиката на оштетување на податоците за време на снимањето и инженерските најдобри практики потребни за безбедно правење резервни копии на виртуелизирани бази на податоци.
Архитектонски судир: Хипервизори наспроти мотори на бази на податоци
За да разбереме зошто снимките на виртуелни машини ги загрозуваат базите на податоци, прво мора да испитаме како двата системи управуваат со состојбата и I/O операциите.
Како хипервизорите извршуваат снимки
Кога хипервизорот (како VMware ESXi, Microsoft Hyper-V или KVM) прави снимка, тој не го копира дискот. Наместо тоа, ја замрзнува моменталната датотека на виртуелниот диск (на пр. .vmdk или .vhdx) во состојба „само за читање“ и создава нов делта диск (диск за разлики). Сите последователни запишувања се насочуваат кон овој делта диск.
Кога снимката ќе се избрише, хипервизорот мора да ги вметне (консолидира) податоците од делта дискот назад во основниот диск. Стандардните снимки се целосно несвесни за апликациите што работат во рамките на гостинскиот оперативен систем. Тие ја снимаат состојбата на дискот точно онака како што постои во таа микросекунда.
Како трансакциските бази на податоци управуваат со состојбата
Трансакциските бази на податоци се дизајнирани околу ACID својствата (Атомичност, Конзистентност, Изолација, Трајност). За да постигнат високи перформанси при одржување на ACID усогласеност, базите на податоци не ја запишуваат секоја трансакција директно во примарните датотеки со податоци на дискот веднаш. Наместо тоа, тие користат комплексна, повеќеслојна архитектура:
- Buffer Pool / Shared Buffers: Податоците се читаат и се менуваат во системската меморија.
- Write-Ahead Log (WAL) / Redo Logs: Промените секвенцијално се запишуваат во високо оптимизирана датотека со дневник на дискот за да се обезбеди трајност.
- Checkpoints / Lazy Writers: Периодично, базата на податоци ги исфрла изменетите (валкани) страници од меморијата во вистинските датотеки со податоци на дискот.
Поради оваа архитектура, физичките датотеки со податоци на дискот речиси секогаш не се синхронизирани со вистинската состојба на базата на податоци. Вистинската состојба на базата на податоци постои само како комбинација од датотеките со податоци на дискот, WAL/Redo дневниците и податоците што моментално се наоѓаат во меморијата.
Зона на опасност: Што се случува за време на снимка на виртуелна машина
Кога правите стандардна снимка на виртуелна машина на сервер со база на податоци, вие снимате состојба која е конзистентна при пад (crash-consistent).
Конзистентност при пад наспроти апликациска конзистентност
Снимката конзистентна при пад е еквивалентна на вадење на кабелот за напојување од физичкиот сервер. Состојбата на дискот е снимена, но сè што било во меморијата е изгубено, а сè што било на пат кон контролорот за складирање е нагло прекинато.
Иако модерните бази на податоци се дизајнирани да се опорават од неочекувано губење на напојувањето со повторно репродуцирање на Write-Ahead дневникот, потпирањето на закрепнување од пад како ваша примарна стратегија за резервна копија е многу опасно. Ако вашата база на податоци опфаќа повеќе виртуелни дискови (на пр. датотеки со податоци на Drive D: и WAL на Drive E:), хипервизорот можеби нема да ги сними двата диска во иста микросекунда. Ако снимката на WAL дискот е направена дури и дел од секундата по снимката на дискот со податоци, базата на податоци не може да ги усогласи секвенциските броеви при враќањето, што резултира со фатално оштетување.
Ефектот „VM Stun“ кај системи со високи трансакции
Процесот на создавање снимка—и уште поважно, процесот на консолидација на снимката—предизвикува феномен познат како „VM Stun“ (замрзнување на виртуелната машина).
За безбедно да го префрли I/O од основниот диск на делта дискот, хипервизорот мора накратко да ја паузира (замрзне) виртуелната машина. За веб-сервер со мало оптоварување, ова замрзнување може да трае 10-50 милисекунди и да остане незабележано. Меѓутоа, за база на податоци со голем проток и масивен I/O, консолидирањето на голем делта диск може да ја замрзне виртуелната машина неколку секунди.
За време на VM stun:
* Мрежните конекции паѓаат, предизвикувајќи истекување на времето (timeouts) на апликациите.
* Кластерите со висока достапност (како SQL Server Always On, PostgreSQL Patroni или MySQL Galera) ги пропуштаат проверките на „отчукувањата на срцето“ (heartbeat checks).
* Кластерот може да претпостави дека замрзнатиот јазол е мртов, предизвикувајќи непотребно и нарушувачко префрлување (failover) (сценарио на „split-brain“).
Искинати страници и I/O неусогласеност
Моторите на базите на податоци обично запишуваат податоци во специфични големини на страници (на пр. 8KB за PostgreSQL и SQL Server, 16KB за InnoDB). Сепак, основниот оперативен систем и низите за складирање обработуваат I/O во помали блокови (на пр. 4KB или 512 бајти).
Ако хипервизорот направи снимка токму додека базата на податоци запишува страница од 8KB, снимката може да ги сними првите 4KB од новите податоци и последните 4KB од старите податоци. Ова создава искината страница (torn page). Кога ќе се обидете да ја вратите снимката, базата на податоци ќе ја прочита страницата, нема да ја помине проверката на контролниот збир (checksum) и ќе ја означи базата на податоци како оштетена.
Последици во реалниот свет за специфични мотори на бази на податоци
Различните мотори на бази на податоци реагираат на снимки конзистентни при пад на различни начини, но ниту еден од нив не се справува со тоа грациозно во продукциска средина.
- PostgreSQL: PostgreSQL се потпира многу на директориумот
pg_wal. Ако снимката ги сними директориумот со податоци ($PGDATA) и WAL несинхронизирано, PostgreSQL нема да се стартува, исфрлајќи грешкаPANIC: could not locate a valid checkpoint record. - MySQL/InnoDB: InnoDB користи „doublewrite buffer“ за да спречи искинати страници, што нуди одредена заштита од состојби конзистентни при пад. Сепак, ако датотеката
ibdata1иib_logfileсе снимени несинхронизирано, моторот InnoDB ќе падне при закрепнувањето. - Microsoft SQL Server: SQL Server е многу чувствителен на замрзнување на I/O. Без соодветна VSS (Volume Shadow Copy Service) интеграција, враќањето на SQL Server од стандардна снимка на виртуелна машина често ќе резултира со сомнителни бази на податоци и прекинати синџири на дневници, уништувајќи ги вашите можности за враќање во одредена временска точка (PITR).
Најдобри практики за безбедно правење резервни копии на виртуелизирани бази на податоци
За да ги заштитите трансакциските бази на податоци, мора да преминете од резервни копии конзистентни при пад кон апликациски конзистентни резервни копии. Ова бара механизмот за резервна копија да комуницира со моторот на базата на податоци, принудувајќи го да ја исфрли меморијата на дискот и привремено да ги паузира I/O операциите додека се прави снимката.
1. Искористете го апликациски свесното замрзнување (VSS и fsfreeze)
За Windows (SQL Server):
Секогаш осигурувајте се дека вашето решение за резервна копија го користи Microsoft Volume Shadow Copy Service (VSS). Кога ќе се активира резервна копија свесна за VSS, SQL Server VSS Writer го замрзнува I/O на базата на податоци, ги исфрла трансакциите што се на чекање на дискот и осигурува дека снимката е совршено апликациски конзистентна.
За Linux (PostgreSQL / MySQL):
Linux нема вграден еквивалент на VSS. За да постигнете апликациска конзистентност, мора да користите скрипти за „pre-freeze“ и „post-thaw“ во комбинација со алатките за гости на хипервизорот (на пр. VMware Tools).
Еве пример за VMware pre-freeze-script за PostgreSQL 15+ кој безбедно ја подготвува базата на податоци за снимка:
#!/bin/bash
# /usr/sbin/pre-freeze-script
# Осигурете се дека оваа скрипта е извршна (chmod +x)
# 1. Кажете му на PostgreSQL да се подготви за резервна копија
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""
# 2. Исфрлете ги баферите на датотечниот систем на дискот
sync
# 3. Замрзнете го датотечниот систем (под претпоставка дека податоците се на /var/lib/pgsql)
fsfreeze -f /var/lib/pgsql
И соодветната post-thaw-script за продолжување на операциите:
#!/bin/bash
# /usr/sbin/post-thaw-script
# 1. Одмрзнете го датотечниот систем
fsfreeze -u /var/lib/pgsql
# 2. Кажете му на PostgreSQL дека резервната копија е завршена
su - postgres -c "psql -c "SELECT pg_backup_stop();""
2. Користете вградени алатки за резервна копија на базата на податоци
Иако апликациски конзистентните снимки се подобри од стандардните снимки, тие сè уште го носат ризикот од VM stun. Најбезбедниот пристап за резервни копии на бази на податоци е користење на вградени, стриминг алатки за резервна копија кои работат независно од хипервизорот.
PostgreSQL (pg_basebackup):
pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P
MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Овие алатки прават „жешки“, неблокирачки резервни копии со копирање на датотеките со податоци и истовремено следење на промените во redo дневникот.
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. Имплементирајте враќање во одредена временска точка (PITR) преку архивирање на дневници
Дневната снимка или целосната резервна копија ве заштитува само до минутата кога е направена. Ако вашата база на податоци падне во 16:00 часот, а вашата последна снимка била во 02:00 часот, губите 14 часа трансакциски податоци.
За да постигнете вистинска отпорност на претпријатиско ниво, мора да комбинирате целосни апликациски конзистентни резервни копии со континуирано архивирање на дневници (резервна копија на WAL, Redo дневници или трансакциски дневници на секои неколку минути). Ова им овозможува на администраторите на бази на податоци да ја вратат базата на податоци до одредена минута или дури до одреден ID на трансакција пред катастрофата.
Стратегии за резервни копии на претпријатиско ниво со CloudSave
Управувањето со прилагодени „pre-freeze“ скрипти, cron задачи за вградени dumps и пренос на дневници низ десетици сервери со бази на податоци е оперативен кошмар за DevOps тимовите. Тука станува критична платформа од претпријатиска класа како CloudSave.
CloudSave го премостува јазот помеѓу виртуелизацијата и архитектурата на базите на податоци. Наместо да се потпира на „слепи“ снимки на хипервизорот, CloudSave користи апликациски свесни агенти кои вградено се интегрираат со SQL Server, PostgreSQL, MySQL и Oracle.
Кога CloudSave иницира резервна копија:
1. Комуницира директно со моторот на базата на податоци преку вградени API-ја (како VSS за Windows или вграден WAL стриминг за Linux).
2. Го оркестрира исфрлањето на мемориските бафери на дискот без да предизвика нарушувачки VM stuns.
3. Безбедно ги снима датотеките со податоци и автоматски управува со скратувањето на трансакциските дневници.
4. Континуирано прави резервни копии на трансакциските дневници, овозможувајќи грануларно враќање во одредена временска точка (PITR) со неколку кликања.
Со префрлање на комплексноста на апликациската конзистентност на CloudSave, администраторите на бази на податоци и системските администратори можат да гарантираат интегритет на податоците без да ги жртвуваат перформансите или достапноста на нивните продукциски кластери.
Заклучок
Снимките на виртуелни машини се неверојатна алатка за управување со инфраструктурата, но тие се фундаментално некомпатибилни со ACID барањата на трансакциските бази на податоци. Потпирањето на снимки од хипервизорот конзистентни при пад ја изложува вашата организација на искинати страници, прекинати синџири на репликација и катастрофално губење на податоци.
За да ги заштитите вашите критични податоци, мора да имплементирате апликациски свесно замрзнување, да користите вградени методологии за резервна копија на бази на податоци и да одржувате континуирани архиви на трансакциски дневници. Со усвојување на наменски решенија за резервни копии на претпријатиско ниво, можете да се погрижите вашите бази на податоци да останат високо достапни, целосно обновливи и целосно безбедни.
