Ինչու՞ VM պատկերները (snapshots) անվտանգ չեն տրանզակցիոն տվյալների բազաների համար. DBA-ի ուղեցույցը տվյալների ամբողջականության վերաբերյալ

DevOps ինժեներների և համակարգային ադմինիստրատորների համար վիրտուալ մեքենաների (VM) սնեփշոթները (snapshots) հիմնարար գործիք են: Դրանք ապահովում են սերվերի վիճակը արագ և հարմարավետ կերպով ֆիքսելու հնարավորություն՝ նախքան ռիսկային թարմացումները, կոնֆիգուրացիայի հիմնարար փոփոխությունները կամ հավելվածների տեղադրումը: Եթե ինչ-որ բան սխալ է ընթանում, վերականգնումը տևում է վայրկյաններ:

Այնուամենայնիվ, երբ նույն մեթոդաբանությունը կիրառվում է տրանզակցիոն տվյալների բազաների նկատմամբ՝ ինչպիսիք են PostgreSQL-ը, MySQL-ը, Oracle-ը կամ Microsoft SQL Server-ը, VM սնեփշոթները անվտանգության բարձիկից վերածվում են «ժամանակային ռումբի»:

Տվյալների բազաների պահուստավորման համար հիպերվայզերի ստանդարտ սնեփշոթների վրա հույս դնելը տվյալների կոռուպցիայի, «պատռված» էջերի (torn pages) և արտադրական համակարգերի անվերականգնելի խափանումների ամենատարածված պատճառներից է: Այս հոդվածում մենք կուսումնասիրենք հիպերվայզերների և տվյալների բազայի շարժիչների միջև ճարտարապետական հակասությունը, սնեփշոթների ժամանակ տվյալների կոռուպցիայի մեխանիզմները և ինժեներական այն լավագույն փորձը, որն անհրաժեշտ է վիրտուալացված տվյալների բազաները անվտանգ պահուստավորելու համար:

Ճարտարապետական հակասություն. Հիպերվայզերներն ընդդեմ տվյալների բազայի շարժիչների

Հասկանալու համար, թե ինչու են VM սնեփշոթները վտանգում տվյալների բազաները, մենք նախ պետք է քննենք, թե ինչպես են երկու համակարգերն էլ կառավարում վիճակը և I/O (մուտքային/ելքային) գործողությունները:

Ինչպես են հիպերվայզերներն իրականացնում սնեփշոթները

Երբ հիպերվայզերը (օրինակ՝ VMware ESXi, Microsoft Hyper-V կամ KVM) սնեփշոթ է անում, այն չի պատճենում սկավառակը: Փոխարենը, այն սառեցնում է ընթացիկ վիրտուալ սկավառակի ֆայլը (օրինակ՝ .vmdk կամ .vhdx) «միայն կարդալու» (read-only) վիճակում և ստեղծում է նոր դելտա-սկավառակ (տարբերակող սկավառակ): Հետագա բոլոր գրառումները ուղղվում են դեպի այս դելտա-սկավառակ:

Երբ սնեփշոթը ջնջվում է, հիպերվայզերը պետք է կատարի դելտա-սկավառակի տվյալների միավորումը (consolidate) բազային սկավառակի հետ: Ստանդարտ սնեփշոթները ընդհանրապես տեղյակ չեն հյուր օպերացիոն համակարգում աշխատող հավելվածների մասին: Նրանք ֆիքսում են սկավառակի վիճակը հենց այնպես, ինչպես այն գոյություն ունի այդ միկրովայրկյանին:

Ինչպես են տրանզակցիոն տվյալների բազաները կառավարում վիճակը

Տրանզակցիոն տվյալների բազաները նախագծված են ACID հատկությունների շուրջ (Ատոմականություն, Հետևողականություն, Մեկուսացում, Երկարակեցություն): Բարձր արդյունավետության հասնելու և միաժամանակ ACID-ի պահանջներին համապատասխանելու համար տվյալների բազաները յուրաքանչյուր տրանզակցիա անմիջապես չեն գրում սկավառակի հիմնական տվյալների ֆայլերի մեջ: Փոխարենը, նրանք օգտագործում են բարդ, բազմաշերտ ճարտարապետություն.

1. Buffer Pool / Shared Buffers: Տվյալները կարդացվում և փոփոխվում են համակարգային հիշողության մեջ:
2. Write-Ahead Log (WAL) / Redo Logs: Փոփոխությունները հաջորդաբար գրվում են սկավառակի վրա գտնվող բարձր օպտիմիզացված լոգ-ֆայլի մեջ՝ երկարակեցությունն ապահովելու համար:
3. Checkpoints / Lazy Writers: Պարբերաբար տվյալների բազան հիշողությունից փոփոխված (կեղտոտ) էջերը տեղափոխում է սկավառակի վրա գտնվող իրական տվյալների ֆայլեր:

Այս ճարտարապետության պատճառով սկավառակի վրա գտնվող ֆիզիկական տվյալների ֆայլերը գրեթե միշտ համաժամանակյա չեն տվյալների բազայի իրական վիճակի հետ: Տվյալների բազայի իրական վիճակը գոյություն ունի միայն սկավառակի տվյալների ֆայլերի, WAL/Redo լոգերի և հիշողության մեջ ներկայումս գտնվող տվյալների համակցության տեսքով:

Վտանգավոր գոտի. Ի՞նչ է տեղի ունենում VM սնեփշոթի ժամանակ

Երբ դուք անում եք տվյալների բազայի սերվերի ստանդարտ VM սնեփշոթ, դուք ֆիքսում եք վթարային հետևողական (crash-consistent) վիճակ:

Վթարային հետևողականությունն ընդդեմ հավելվածային հետևողականության

Վթարային հետևողական սնեփշոթը համարժեք է ֆիզիկական սերվերի հոսանքի լարը պոկելուն: Սկավառակի վիճակը ֆիքսվում է, բայց այն ամենը, ինչ գտնվում էր հիշողության մեջ, կորչում է, իսկ այն, ինչ գտնվում էր պահեստավորման կոնտրոլերին ուղարկվելու ճանապարհին, կտրուկ ընդհատվում է:

Թեև ժամանակակից տվյալների բազաները նախագծված են անսպասելի հոսանքազրկումից հետո վերականգնվելու համար՝ Write-Ahead Log-ը վերարտադրելու միջոցով, վթարային վերականգնման վրա որպես հիմնական պահուստավորման ռազմավարություն հույս դնելը չափազանց վտանգավոր է: Եթե ձեր տվյալների բազան ընդգրկում է բազմաթիվ վիրտուալ սկավառակներ (օրինակ՝ տվյալների ֆայլերը D: սկավառակի վրա, իսկ WAL-ը՝ E: սկավառակի վրա), հիպերվայզերը կարող է երկու սկավառակներն էլ սնեփշոթ չանել ճիշտ նույն միկրովայրկյանին: Եթե WAL սկավառակի սնեփշոթը ֆիքսվում է տվյալների սկավառակի սնեփշոթից նույնիսկ մեկ վայրկյանի մի մաս հետո, տվյալների բազան չի կարող վերականգնման ժամանակ համաձայնեցնել հաջորդականության համարները, ինչը կհանգեցնի ճակատագրական կոռուպցիայի:

«VM Stun» էֆեկտը բարձր տրանզակցիոն համակարգերում

Սնեփշոթի ստեղծման գործընթացը, և ավելի կարևորը՝ սնեփշոթի համախմբման (consolidation) գործընթացը, առաջացնում է մի երևույթ, որը հայտնի է որպես «VM Stun» (վիրտուալ մեքենայի սառեցում):

I/O-ն բազային սկավառակից դեպի դելտա-սկավառակ անվտանգ անցկացնելու համար հիպերվայզերը պետք է կարճ ժամանակով դադարեցնի (սառեցնի) վիրտուալ մեքենան: Թույլ ծանրաբեռնված վեբ-սերվերի համար այս սառեցումը կարող է տևել 10-50 միլիվայրկյան և աննկատ մնալ: Սակայն, հսկայական I/O ունեցող բարձր թողունակությամբ տվյալների բազայի համար մեծ դելտա-սկավառակի համախմբումը կարող է VM-ը սառեցնել մի քանի վայրկյանով:

VM սառեցման ընթացքում՝
* Ցանցային կապերը ընդհատվում են, ինչը հանգեցնում է հավելվածների ժամանակի սպառման (timeouts):
* Բարձր հասանելիության կլաստերները (ինչպիսիք են SQL Server Always On-ը, PostgreSQL Patroni-ն կամ MySQL Galera-ն) բաց են թողնում սրտի զարկերի (heartbeat) ստուգումները:
* Կլաստերը կարող է ենթադրել, որ սառեցված հանգույցը մեռած է, ինչը կհանգեցնի ավելորդ և խափանարար ֆեյլովերի (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-ը ստանդարտ VM սնեփշոթից վերականգնելը հաճախ հանգեցնում է կասկածելի տվյալների բազաների և կոտրված լոգ-շղթաների, ինչը ոչնչացնում է ձեր Point-in-Time Recovery (PITR) հնարավորությունները:

Վիրտուալացված տվյալների բազաների անվտանգ պահուստավորման լավագույն փորձը

Տրանզակցիոն տվյալների բազաները պաշտպանելու համար դուք պետք է անցնեք վթարային հետևողական պահուստավորումից դեպի հավելվածային հետևողական (application-consistent) պահուստավորում: Սա պահանջում է, որ պահուստավորման մեխանիզմը հաղորդակցվի տվյալների բազայի շարժիչի հետ՝ ստիպելով նրան հիշողությունը դատարկել սկավառակի վրա և ժամանակավորապես դադարեցնել 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. Իրականացրեք Point-in-Time Recovery (PITR) լոգերի արխիվացման միջոցով

Ամենօրյա սնեփշոթը կամ ամբողջական պահուստավորումը ձեզ պաշտպանում է միայն մինչև այն պահը, երբ այն կատարվել է: Եթե ձեր տվյալների բազան խափանվում է ժամը 16:00-ին, իսկ ձեր վերջին սնեփշոթը եղել է առավոտյան 02:00-ին, դուք կորցնում եք 14 ժամվա տրանզակցիոն տվյալներ:

Իրական ձեռնարկատիրական կայունության հասնելու համար դուք պետք է համատեղեք ամբողջական հավելվածային հետևողական պահուստավորումները շարունակական լոգերի արխիվացման հետ (WAL-ի, Redo Logs-ի կամ Transaction Logs-ի պահուստավորումը ամեն մի քանի րոպեն մեկ): Սա թույլ է տալիս DBA-ներին վերականգնել տվյալների բազան կոնկրետ րոպեի կամ նույնիսկ աղետից առաջ կատարված կոնկրետ տրանզակցիայի ID-ի:

Ձեռնարկատիրական պահուստավորման ռազմավարություններ CloudSave-ի հետ

Տասնյակ տվյալների բազայի սերվերների վրա հատուկ pre-freeze սկրիպտների, բնիկ դամփերի համար cron job-երի և լոգերի փոխանցման կառավարումը DevOps թիմերի համար օպերացիոն մղձավանջ է: Այստեղ է, որ CloudSave-ի նման ձեռնարկատիրական մակարդակի հարթակը դառնում է կրիտիկական:

CloudSave-ը կամրջում է վիրտուալացման և տվյալների բազայի ճարտարապետության միջև եղած բացը: Հիպերվայզերի կույր սնեփշոթների վրա հույս դնելու փոխարեն, CloudSave-ն օգտագործում է հավելվածային գիտակից գործակալներ, որոնք բնիկ կերպով ինտեգրվում են SQL Server-ի, PostgreSQL-ի, MySQL-ի և Oracle-ի հետ:

Երբ CloudSave-ը նախաձեռնում է պահուստավորում՝
1. Այն ուղղակիորեն հաղորդակցվում է տվյալների բազայի շարժիչի հետ բնիկ API-ների միջոցով (ինչպիսիք են VSS-ը Windows-ի համար կամ բնիկ WAL հոսքը Linux-ի համար):
2. Այն կազմակերպում է հիշողության բուֆերների դատարկումը սկավառակի վրա՝ առանց VM-ի խափանարար սառեցումների:
3. Այն ապահով կերպով ֆիքսում է տվյալների ֆայլերը և ավտոմատ կերպով կառավարում է տրանզակցիոն լոգերի կրճատումը:
4. Այն շարունակաբար պահուստավորում է տրանզակցիոն լոգերը՝ հնարավորություն տալով մի քանի կտտոցով իրականացնել հատիկավոր Point-in-Time Recovery (PITR):

Հավելվածային հետևողականության բարդությունը CloudSave-ին փոխանցելով՝ DBA-ները և համակարգային ադմինիստրատորները կարող են երաշխավորել տվյալների ամբողջականությունը՝ առանց զոհաբերելու իրենց արտադրական կլաստերների արդյունավետությունը կամ հասանելիությունը:

Եզրակացություն

Վիրտուալ մեքենաների սնեփշոթները ենթակառուցվածքների կառավարման անհավանական գործիք են, սակայն դրանք հիմնովին անհամատեղելի են տրանզակցիոն տվյալների բազաների ACID պահանջների հետ: Վթարային հետևողական հիպերվայզերի սնեփշոթների վրա հույս դնելը ձեր կազմակերպությանը ենթարկում է պատռված էջերի, կոտրված ռեպլիկացիոն շղթաների և տվյալների աղետալի կորստի վտանգին:

Ձեր առաքելության համար կրիտիկական տվյալները պաշտպանելու համար դուք պետք է իրականացնեք հավելվածային գիտակից սառեցում, օգտագործեք տվյալների բազայի պահուստավորման բնիկ մեթոդաբանություններ և պահպանեք տրանզակցիոն լոգերի շարունակական արխիվներ: Ընդունելով նպատակային ձեռնարկատիրական պահուստավորման լուծումներ՝ դուք կարող եք ապահովել, որ ձեր տվյալների բազաները մնան բարձր հասանելի, լիովին վերականգնելի և ամբողջությամբ անվտանգ: