A DevOps mérnökök és rendszergazdák számára a virtuális gép (VM) pillanatképek (snapshotok) alapvető eszköznek számítanak. Gyors és kényelmes módot biztosítanak a szerver állapotának rögzítésére egy kockázatos javítás, jelentős konfigurációs változtatás vagy alkalmazástelepítés előtt. Ha valami balul sül el, a visszaállítás másodpercek alatt elvégezhető.
Azonban, amikor ugyanezt a módszert tranzakciós adatbázisokra – például PostgreSQL, MySQL, Oracle vagy Microsoft SQL Server – alkalmazzák, a VM pillanatképek biztonsági hálóból ketyegő időzített bombává válnak.
A szabványos hipervizor pillanatképekre való támaszkodás az adatbázis-mentéseknél az adatkorrupció, a „törött” lapok (torn pages) és a helyreállíthatatlan éles leállások egyik leggyakoribb oka. Ebben a cikkben megvizsgáljuk a hipervizorok és az adatbázis-motorok közötti építészeti ütközést, a pillanatképek készítése közbeni adatkorrupció mechanizmusát, valamint azokat a mérnöki bevált gyakorlatokat, amelyek szükségesek a virtualizált adatbázisok biztonságos mentéséhez.
Az építészeti ütközés: Hipervizorok vs. Adatbázis-motorok
Ahhoz, hogy megértsük, miért veszélyeztetik a VM pillanatképek az adatbázisokat, először meg kell vizsgálnunk, hogyan kezelik mindkét rendszer az állapotot és az I/O műveleteket.
Hogyan hajtják végre a hipervizorok a pillanatképeket
Amikor egy hipervizor (például VMware ESXi, Microsoft Hyper-V vagy KVM) pillanatképet készít, nem másolja le a lemezt. Ehelyett befagyasztja az aktuális virtuális lemezfájlt (pl. .vmdk vagy .vhdx) írásvédett állapotba, és létrehoz egy új delta lemezt (különbözeti lemezt). Minden ezt követő írási művelet erre a delta lemezre irányul.
Amikor a pillanatképet törlik, a hipervizornak véglegesítenie (konszolidálnia) kell az adatokat a delta lemezről vissza az alaplemezre. A szabványos pillanatképek teljesen figyelmen kívül hagyják a vendég operációs rendszeren futó alkalmazásokat. A lemez állapotát pontosan úgy rögzítik, ahogy az abban a mikroszekundumban létezik.
Hogyan kezelik az állapotot a tranzakciós adatbázisok
A tranzakciós adatbázisokat az ACID tulajdonságok (Atomicitás, Konzisztencia, Izoláció, Tartósság) köré tervezték. A nagy teljesítmény elérése és az ACID-megfelelőség fenntartása érdekében az adatbázisok nem írnak minden tranzakciót azonnal közvetlenül az elsődleges adatfájlokba a lemezen. Ehelyett egy komplex, többrétegű architektúrát használnak:
- Buffer Pool / Shared Buffers: Az adatok beolvasása és módosítása a rendszermemóriában történik.
- Write-Ahead Log (WAL) / Redo Logs: A változások szekvenciálisan egy erősen optimalizált naplófájlba íródnak a lemezen a tartósság biztosítása érdekében.
- Checkpoints / Lazy Writers: Az adatbázis időszakosan kiírja a módosított (piszkos) lapokat a memóriából a lemezen lévő tényleges adatfájlokba.
Emiatt az architektúra miatt a lemezen lévő fizikai adatfájlok szinte mindig nincsenek szinkronban az adatbázis aktuális állapotával. Az adatbázis valódi állapota csak a lemezen lévő adatfájlok, a WAL/Redo naplók és a memóriában éppen tárolt adatok kombinációjaként létezik.
A veszélyzóna: Mi történik egy VM pillanatkép készítésekor
Amikor egy adatbázis-szerverről szabványos VM pillanatképet készít, egy összeomlás-konzisztens (crash-consistent) állapotot rögzít.
Összeomlás-konzisztencia vs. Alkalmazás-konzisztencia
Az összeomlás-konzisztens pillanatkép egyenértékű azzal, mintha kihúzná a tápkábelt a fizikai szerverből. A lemez állapota rögzítésre kerül, de ami a memóriában volt, az elveszik, és ami éppen a tárolóvezérlő felé tartott, az hirtelen megszakad.
Bár a modern adatbázisokat úgy tervezték, hogy a Write-Ahead Log visszajátszásával helyreálljanak a váratlan áramkimaradásokból, a helyreállításra mint elsődleges mentési stratégiára támaszkodni rendkívül veszélyes. Ha az adatbázisa több virtuális lemezen terül el (pl. adatfájlok a D: meghajtón és WAL az E: meghajtón), előfordulhat, hogy a hipervizor nem ugyanabban a mikroszekundumban készít pillanatképet mindkét lemezről. Ha a WAL lemez pillanatképe akár egy töredékmásodperccel később készül el, mint az adatlemezé, az adatbázis a visszaállításkor nem tudja egyeztetni a sorszámokat, ami végzetes korrupcióhoz vezet.
A „VM Stun” hatás a nagy tranzakciós rendszereken
A pillanatkép létrehozásának folyamata – és ami még fontosabb, a pillanatkép konszolidációja – egy „VM Stun” (virtuális gép lefagyás) néven ismert jelenséget okoz.
Ahhoz, hogy az I/O-t biztonságosan átkapcsolja az alaplemezről a delta lemezre, a hipervizornak rövid időre szüneteltetnie (lefagyasztania) kell a virtuális gépet. Egy alacsony terhelésű webszervernél ez a lefagyás 10-50 milliszekundumig tarthat, és észrevétlen maradhat. Azonban egy hatalmas I/O-val rendelkező, nagy áteresztőképességű adatbázisnál egy nagy delta lemez konszolidációja több másodpercre is lefagyaszthatja a VM-et.
A VM lefagyása alatt:
* A hálózati kapcsolatok megszakadnak, ami alkalmazás-időtúllépéseket okoz.
* A magas rendelkezésre állású fürtök (mint az SQL Server Always On, PostgreSQL Patroni vagy MySQL Galera) elmulasztják a szívverés-ellenőrzéseket.
* A fürt azt feltételezheti, hogy a lefagyott csomópont halott, ami szükségtelen és zavaró feladatátvételt (split-brain forgatókönyv) indíthat el.
Törött lapok és I/O eltolódás
Az adatbázis-motorok általában meghatározott lapméretekben (pl. 8KB a PostgreSQL és SQL Server esetében, 16KB az InnoDB-nél) írják az adatokat. Azonban az alapul szolgáló operációs rendszer és a tárolótömbök kisebb blokkokban (pl. 4KB vagy 512 bájt) dolgozzák fel az I/O-t.
Ha egy hipervizor pontosan akkor készít pillanatképet, amikor az adatbázis egy 8KB-os lapot ír, a pillanatkép rögzítheti az új adat első 4KB-ját és a régi adat utolsó 4KB-ját. Ez egy törött lapot (torn page) hoz létre. Amikor megpróbálja visszaállítani a pillanatképet, az adatbázis beolvassa a lapot, a checksum-ellenőrzés sikertelen lesz, és az adatbázist korruptnak jelöli.
Valós következmények konkrét adatbázis-motoroknál
A különböző adatbázis-motorok eltérően reagálnak az összeomlás-konzisztens pillanatképekre, de egyikük sem kezeli azokat megfelelően éles környezetben.
- PostgreSQL: A PostgreSQL nagymértékben támaszkodik a
pg_walkönyvtárra. Ha egy pillanatkép az adatkönyvtárat ($PGDATA) és a WAL-t nem szinkronban rögzíti, a PostgreSQL nem indul el, ésPANIC: could not locate a valid checkpoint recordhibaüzenetet dob. - MySQL/InnoDB: Az InnoDB egy „doublewrite buffer”-t használ a törött lapok megelőzésére, ami némi védelmet nyújt az összeomlás-konzisztens állapotok ellen. Azonban, ha az
ibdata1fájl és azib_logfilenem szinkronban kerül rögzítésre, az InnoDB motor összeomlik a helyreállításkor. - Microsoft SQL Server: Az SQL Server rendkívül érzékeny az I/O lefagyasztására. Megfelelő VSS (Volume Shadow Copy Service) integráció nélkül az SQL Server szabványos VM pillanatképből történő visszaállítása gyakran „gyanús” (suspect) adatbázisokhoz és megszakadt naplóláncokhoz vezet, tönkretéve az időpontra történő helyreállítási (PITR) képességeit.
Bevált gyakorlatok a virtualizált adatbázisok biztonságos mentéséhez
A tranzakciós adatbázisok védelme érdekében az összeomlás-konzisztens mentésekről át kell térnie az alkalmazás-konzisztens mentésekre. Ehhez a mentési mechanizmusnak kommunikálnia kell az adatbázis-motorral, kényszerítve azt a memória lemezre történő kiírására és az I/O műveletek pillanatnyi szüneteltetésére, amíg a pillanatkép elkészül.
1. Alkalmazás-tudatos nyugtatás (VSS és fsfreeze) használata
Windows (SQL Server) esetén:
Mindig győződjön meg arról, hogy a mentési megoldása használja a Microsoft Volume Shadow Copy Service-t (VSS). Amikor egy VSS-tudatos mentés elindul, az SQL Server VSS Writer lefagyasztja az adatbázis I/O-t, kiírja a függőben lévő tranzakciókat a lemezre, és biztosítja, hogy a pillanatkép tökéletesen alkalmazás-konzisztens legyen.
Linux (PostgreSQL / MySQL) esetén:
A Linuxnak nincs natív megfelelője a VSS-nek. Az alkalmazás-konzisztencia eléréséhez a hipervizor vendégeszközeivel (pl. VMware Tools) együttműködve „pre-freeze” és „post-thaw” szkripteket kell használnia.
Íme egy példa egy VMware pre-freeze-script-re PostgreSQL 15+ verzióhoz, amely biztonságosan előkészíti az adatbázist a pillanatképhez:
#!/bin/bash
# /usr/sbin/pre-freeze-script
# Győződjön meg róla, hogy a szkript futtatható (chmod +x)
# 1. Utasítsa a PostgreSQL-t a mentésre való felkészülésre
su - postgres -c "psql -c "SELECT pg_backup_start('vm_snapshot', true);""
# 2. Fájlrendszer-pufferek kiírása a lemezre
sync
# 3. Fájlrendszer lefagyasztása (feltételezve, hogy az adatok a /var/lib/pgsql könyvtárban vannak)
fsfreeze -f /var/lib/pgsql
És a megfelelő post-thaw-script a műveletek folytatásához:
#!/bin/bash
# /usr/sbin/post-thaw-script
# 1. Fájlrendszer lefagyasztásának feloldása
fsfreeze -u /var/lib/pgsql
# 2. Értesítse a PostgreSQL-t, hogy a mentés befejeződött
su - postgres -c "psql -c "SELECT pg_backup_stop();""
2. Natív adatbázis-mentési segédprogramok használata
Bár az alkalmazás-konzisztens pillanatképek jobbak, mint a szabványosak, továbbra is fennáll a VM lefagyás kockázata. Az adatbázis-mentések legbiztonságosabb módja a natív, streamelő mentési segédprogramok használata, amelyek a hipervizortól függetlenül működnek.
PostgreSQL (pg_basebackup):
pg_basebackup -h localhost -U replication_user -D /mnt/backups/pg_backup -Ft -z -P
MySQL/MariaDB (Percona XtraBackup / Mariabackup):
Ezek az eszközök „hot”, nem blokkoló mentéseket készítenek az adatfájlok másolásával és a redo logban történő változások egyidejű követésével.
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. Időpontra történő helyreállítás (PITR) megvalósítása naplóarchiválással
A napi pillanatkép vagy teljes mentés csak az elkészítésének pillanatáig nyújt védelmet. Ha az adatbázisa 16:00-kor omlik össze, és az utolsó pillanatképe 02:00-kor készült, 14 órányi tranzakciós adatot veszít.
A valódi vállalati rugalmasság eléréséhez kombinálnia kell a teljes alkalmazás-konzisztens mentéseket a folyamatos naplóarchiválással (a WAL, Redo naplók vagy tranzakciós naplók néhány percenkénti mentésével). Ez lehetővé teszi az adatbázis-adminisztrátorok számára, hogy az adatbázist egy adott percre vagy akár egy konkrét tranzakcióazonosítóra állítsák vissza a katasztrófa előtt.
Vállalati mentési stratégiák a CloudSave-vel
Az egyedi „pre-freeze” szkriptek, a natív dumpokhoz tartozó cron jobok és a naplók továbbításának kezelése több tucat adatbázis-szerveren rémálom a DevOps csapatok számára. Itt válik kritikussá egy vállalati szintű platform, mint a CloudSave.
A CloudSave áthidalja a szakadékot a virtualizáció és az adatbázis-architektúra között. Ahelyett, hogy vak hipervizor pillanatképekre támaszkodna, a CloudSave alkalmazás-tudatos ügynököket használ, amelyek natívan integrálódnak az SQL Serverrel, PostgreSQL-lel, MySQL-lel és Oracle-lel.
Amikor a CloudSave elindít egy mentést:
1. Közvetlenül kommunikál az adatbázis-motorral natív API-kon keresztül (mint a VSS Windows esetén vagy natív WAL streamelés Linux esetén).
2. Megszervezi a memóriapufferek lemezre történő kiírását anélkül, hogy zavaró VM lefagyásokat okozna.
3. Biztonságosan rögzíti az adatfájlokat és automatikusan kezeli a tranzakciós naplók csonkolását.
4. Folyamatosan menti a tranzakciós naplókat, lehetővé téve a részletes időpontra történő helyreállítást (PITR) néhány kattintással.
Az alkalmazás-konzisztencia komplexitásának CloudSave-re történő áthárításával az adatbázis-adminisztrátorok és rendszergazdák garantálhatják az adatok integritását anélkül, hogy feláldoznák az éles fürtjeik teljesítményét vagy rendelkezésre állását.
Következtetés
A virtuális gép pillanatképek hihetetlen eszközök az infrastruktúra-kezeléshez, de alapvetően összeegyeztethetetlenek a tranzakciós adatbázisok ACID követelményeivel. Az összeomlás-konzisztens hipervizor pillanatképekre való támaszkodás törött lapoknak, megszakadt replikációs láncoknak és katasztrofális adatvesztésnek teszi ki a szervezetét.
A kritikus fontosságú adatok védelme érdekében alkalmazás-tudatos nyugtatást kell bevezetnie, natív adatbázis-mentési módszertanokat kell alkalmaznia, és folyamatos tranzakciós naplóarchívumokat kell fenntartania. A célzott vállalati mentési megoldások alkalmazásával biztosíthatja, hogy adatbázisai továbbra is magas rendelkezésre állásúak, teljes mértékben helyreállíthatóak és teljesen biztonságosak maradjanak.
