DevOps инженерүүд, Мэдээллийн сангийн администраторууд (DBA) болон IT системийн архитекторуудын хувьд Сэргээх хугацааны зорилт (RTO) болон Сэргээх цэгийн зорилт (RPO) нь зөвхөн бизнесийн тасралтгүй байдлын талаарх нэр томьёо төдий бус, харин инженерийн хатуу хязгаарлалтууд юм. Чухал ач холбогдолтой мэдээллийн сангуудыг удирдахдаа эдгээр хэмжигдэхүүнийг нарийн тооцоолох, архитектурыг зөв төлөвлөх, баталгаажуулахгүй байх нь өгөгдөл алдагдах болон удаан хугацааны зогсолт үүсэх зэрэг сүйрлийн үр дагаварт хүргэж болзошгүй.
Орчин үеийн байгууллагын орчинд RTO болон RPO-г тооцоолохын тулд мэдээллийн сангийн дотоод бүтэц, хадгалах сангийн I/O, сүлжээний дамжуулах чадвар болон гүйлгээний бүртгэлийн (transaction log) механизмыг гүнзгий ойлгох шаардлагатай. Энэхүү гарын авлагад үйлдвэрлэлийн мэдээллийн сангийн системүүдийн RTO болон RPO-г тооцоолох, турших, оновчтой болгох техникийн аргачлалуудыг авч үзнэ.
Мэдээллийн сангийн систем дэх RPO (Сэргээх цэгийн зорилт)-г задлан шинжлэх нь
RPO нь цаг хугацаагаар хэмжигдэх өгөгдлийн алдагдлын хамгийн их зөвшөөрөгдөх хэмжээг тодорхойлдог. Хэрэв таны RPO 15 минут бол 12:00 цагт гарсан гамшгийн үед та 11:45 цаг хүртэлх бүх баталгаажсан гүйлгээг сэргээх чадвартай байх ёстой.
Мэдээллийн сангийн хувьд RPO нь таны гүйлгээний бүртгэлийг удирдах стратегиас (PostgreSQL-д WAL, Oracle-д Redo Logs, SQL Server-д Transaction Logs) хамаардаг.
Өгөгдлийн алдагдал ба бүртгэл үүсгэх механизм
Боломжит RPO-г тооцоолохын тулд эхлээд мэдээллийн сангийнхаа гүйлгээний бүртгэл үүсгэх хурдыг ойлгох хэрэгтэй. Хэрэв та бүртгэлүүдийг 15 минут тутамд нөөц хадгалах сан руу илгээдэг боловч таны сүлжээ 15 минутын бүртгэлийг тухайн хугацаанд дамжуулж чадахгүй бол таны бодит RPO тасралтгүй муудах болно.
Та SQL командуудыг ашиглан бүртгэл үүсгэх хурдаа суурь үзүүлэлт болгон тогтоож болно. Жишээлбэл, PostgreSQL (10+ хувилбар)-д та Write-Ahead Log (WAL) үүсгэх хурдыг тодорхой хугацаанд хэмжиж болно:
-- Үүнийг T=0 үед ажиллуулна
SELECT pg_current_wal_lsn() AS start_lsn;
-- Яг 5 минут (300 секунд) хүлээгээд дараахыг ажиллуулна:
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;
Хэрэв энэ асуулга нь ачааллын оргил үед 50 MB/s WAL өгөгдөл үүсгэж байгааг харуулбал, 15 минутын RPO-г хадгалахын тулд 45 GB бүртгэлийн өгөгдлийг нөөц хадгалах сан руу шилжүүлэх шаардлагатай болно. Таны сүлжээ болон хадгалах сангийн зорилтот төхөөрөмжүүд энэ RPO-г хадгалахын тулд 50 MB/s-ээс дээш бичих хурдыг дэмжих ёстой.
Синхрон ба Асинхрон хуулбарлалтын (Replication) нөлөө
Олон DBA-ууд RPO-г хангахын тулд Өндөр бэлэн байдлын (HA) хуулбарлалтад найддаг. Гэсэн хэдий ч хуулбарлалт нь нөөц хуулбар биш юм. Устгагдсан хүснэгт (DROP TABLE users;) тэр даруй хуулбарлагдана.
Гамшгаас сэргээх (DR)-д хуулбарлалтыг ашиглах үед хуулбарлалтын горим нь RPO-д шууд нөлөөлдөг:
* Синхрон хуулбарлалт: Тэг RPO-г (RPO=0) баталгаажуулдаг. Үндсэн мэдээллийн сан нь туслах мэдээллийн сан хүлээн авснаа баталгаажуулах хүртэл гүйлгээг баталгаажуулдаггүй. Үүний хариуд үндсэн бичих үйлдлийн хоцрогдол нэмэгддэг.
* Асинхрон хуулбарлалт: Хуулбарлалтын хоцрогдлыг үүсгэдэг. Таны RPO нь үндсэндээ таны одоогийн хуулбарлалтын хоцрогдолтой тэнцүү байна.
PostgreSQL-д асинхрон хуулбарлалтын хоцрогдлыг хянахын тулд дараахыг ашиглана уу:
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 (Сэргээх хугацааны зорилт)-г задлан шинжлэх нь
RTO нь зогсолтын хамгийн их зөвшөөрөгдөх хугацаа юм. Мэдээллийн сангийн RTO-г тооцоолох нь маш төвөгтэй, учир нь энэ нь зөвхөн файлыг сервер рүү буцааж хуулахад зарцуулагдах хугацаа биш юм.
RTO тооцооллын математик загвар
Мэдээллийн сангийн бодит RTO тооцоолол нь дөрвөн өөр үе шатыг харгалзан үзэх ёстой:
RTO = T(infra) + T(transfer) + T(restore) + T(recovery)
- T(infra) – Дэд бүтцийн хангамж: Орлуулах тооцоолох хүчин чадал болон хадгалах санг ажиллуулах хугацаа. (Урьдчилан бэлтгэсэн DR сайт эсвэл Дэд бүтэц-код (IaC) дамжуулах хоолойтой бол бараг тэг байж болно).
- T(transfer) – Өгөгдөл шилжүүлэлт: Нөөц хуулбарыг хадгалах сангаас мэдээллийн сангийн сервер рүү зөөх хугацаа.
- T(restore) – Физик сэргээлт: Өгөгдлийн файлуудыг зорилтот диск рүү бичих хугацаа.
- T(recovery) – Мэдээллийн сангийн ослын дараах сэргээлт: Мэдээллийн сангийн хөдөлгүүр гүйлгээний бүртгэлийг дахин тоглуулах, баталгаажсан гүйлгээг урагшлуулах, баталгаажаагүй гүйлгээг буцаах хугацаа.
Шилжүүлэлт болон сэргээх хугацааг тооцоолох
T(transfer) болон T(restore)-г тооцоолохын тулд та сүлжээний зурвасын өргөн болон дискний IOPS/дамжуулах чадварыг суурь үзүүлэлт болгон тогтоох ёстой. Онолын дээд хязгаарт бүү найд; өөрийн бодит дэд бүтцээ туршиж үзээрэй.
Нөөц хадгалах сан болон мэдээллийн сангийн серверийн хоорондох сүлжээний дамжуулах чадварыг шалгахын тулд iperf3 ашиглана уу:
# Нөөц хадгалах сан дээр (сервер)
iperf3 -s
# Мэдээллийн сангийн сервер дээр (клиент)
iperf3 -c <backup_repo_ip> -t 60 -P 4
Мэдээллийн сангийн сэргээх үйлдлийг дуурайлган, мэдээллийн сангийн хадгалах сангийн дараалсан бичих гүйцэтгэлийг шалгахын тулд fio ашиглана уу:
fio --name=restore_sim --ioengine=libaio --rw=write --bs=1M --size=10G --numjobs=4 --iodepth=32 --direct=1 --filename=/var/lib/postgresql/data/testfile
Хэрэв таны мэдээллийн сан 5 TB бөгөөд таны fio тестүүд 500 MB/s-ийн хамгийн их тогтвортой бичих хурдыг харуулж байвал таны T(restore)-ийн үнэмлэхүй доод хэмжээ ойролцоогоор 2.8 цаг байна. Хэрэв таны бизнесийн SLA 1 цагийн RTO шаарддаг бол уламжлалт дамжуулалтын сэргээлт амжилтгүй болно. Та архитектураа хадгалах сангийн түвшний агшин зуурын зураг (snapshot) эсвэл блок түвшний хуулбарлалт руу шилжүүлэх ёстой.
Нуугдмал урхи: T(recovery)
Хамгийн их дутуу үнэлэгддэг хувьсагч бол T(recovery) юм. Хэрэв та долоо хоног бүрийн бүтэн нөөц хуулбарыг сэргээж, RPO-доо хүрэхийн тулд 6 хоногийн гүйлгээний бүртгэлийг хэрэглэх шаардлагатай бол мэдээллийн сангийн хөдөлгүүр гүйлгээ бүрийг дарааллаар нь дахин тоглуулах ёстой.
500 GB гүйлгээний бүртгэлийг дахин тоглуулахад хэдэн цаг зарцуулагдаж болох бөгөөд энэ нь CPU-ийн нэг урсгалт гүйцэтгэл болон дискний IOPS-оос ихээхэн хамаарна. T(recovery)-г багасгахын тулд бүтэн эсвэл ялгавартай нөөц хуулбарын давтамжийг нэмэгдүүлээрэй.
Зөрүүг арилгах нь: RTO болон RPO-г баталгаажуулах практик алхамууд
Онолын RTO болон RPO-г тооцоолох нь зөвхөн эхний алхам юм. Чухал ач холбогдолтой орчинд тасралтгүй баталгаажуулалт шаардлагатай.
Алхам 1: Тасралтгүй архивлахыг хэрэгжүүлэх
Синхрон хуулбарлалтын гүйцэтгэлийн алдагдалгүйгээр минутаас бага RPO-д хүрэхийн тулд тасралтгүй бүртгэл архивлахыг хэрэгжүүлээрэй. Бүртгэлийн файлыг дүүртэл хүлээхийн оронд (энэ нь ачаалал багатай үед хэдэн цаг зарцуулж болзошгүй), тогтмол хугацаанд бүртгэлийн шилжүүлэлтийг албадан хийгээрэй.
SQL Server-д та Гүйлгээний бүртгэлийн (Transaction Log) нөөц хуулбарыг байнга автоматжуулж болно:
BACKUP LOG [MissionCriticalDB]
TO DISK = N'\BackupRepoSQLMissionCriticalDB_Log.trn'
WITH NOFORMAT, NOINIT,
NAME = N'MissionCriticalDB-Transaction Log Backup',
SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10;
Шилдэг туршлага: Энэ ажлыг таны RPO шаардлагаас хамааран 1-5 минут тутамд ажиллахаар төлөвлөөрэй.
Алхам 2: Сэргээх туршилтыг автоматжуулах
Туршигдаагүй нөөц хуулбар бол зөвхөн онолын ойлголт юм. Тооцоолсон RTO-гоо баталгаажуулахын тулд та автоматжуулсан сэргээх туршилтыг хийх ёстой.
CloudSave зэрэг байгууллагын нөөц хуулбарын платформууд нь автоматжуулсан, тусгаарлагдсан сэргээх туршилтыг хангах замаар үүнийг хялбаршуулдаг. CloudSave нь автоматаар sandbox орчинг үүсгэж, хамгийн сүүлийн нөөц хуулбарыг холбон, мэдээллийн сангийн бүрэн сэргээлтийг хийж, RTO-г яг таг хэмжиж өгөгдлийн бүрэн бүтэн байдлыг хангахын тулд захиалгат баталгаажуулалтын скриптүүдийг (жишээ нь, SQL Server-д DBCC CHECKDB) ажиллуулдаг. Энэ нь RTO-г тооцоолсон таамаглалаас батлагдсан, тайлагнах боломжтой хэмжигдэхүүн болгон хувиргадаг.
Алхам 3: SLA зөрчлийг хянах, сэрэмжлүүлэх
Таны хяналтын систем (Prometheus, Datadog, Zabbix) таны RTO/RPO SLA-д заналхийлж буй хэмжигдэхүүнүүдийг идэвхтэй хянах ёстой. Сэрэмжлүүлгийн дүрмүүдийг дараах тохиолдолд тохируулах хэрэгтэй:
* Нөөц хуулбарын ажлын алдаа: RPO-д шууд заналхийлнэ.
* Бүртгэл дамжуулах хоцрогдол: Хэрэв бүртгэл дамжуулах нь үүсгэх интервалаас удаан үргэлжилбэл.
* Хадгалах сангийн IOPS хязгаарлалт: Үүлэн үйлчилгээ үзүүлэгчид (AWS EBS гэх мэт) хэрэв burst кредит дуусвал IOPS-ийг хязгаарладаг бөгөөд энэ нь яаралтай үед таны RTO-г чимээгүйгээр сүйтгэх болно.
Хатуу SLA-г хангахын тулд мэдээллийн сангийн нөөц хуулбарын архитектурыг оновчтой болгох
Математик тооцоолол нь таны одоогийн архитектур бизнесийн SLA-г хангаж чадахгүй байгааг харуулбал та нөөц хуулбарын стратегиа оновчтой болгох ёстой.
1. Блок түвшний нэмэгдэл (Incremental) нөөц хуулбарыг ашиглах
Уламжлалт мэдээллийн сангийн дампуу (pg_dump эсвэл mysqldump гэх мэт логик нөөц хуулбарууд) нь чухал RTO-д хэтэрхий удаан байдаг. Физик, блок түвшний нөөц хуулбарыг ашиглаарай. Блок түвшний нэмэгдэл нөөц хуулбарууд нь зөвхөн сүүлийн нөөц хуулбараас хойш өөрчлөгдсөн дискний блокуудыг хуулбарладаг тул T(transfer) болон сүлжээний ачааллыг эрс багасгадаг.
2. Хадгалах сангийн агшин зуурын зургийг (Snapshots) ашиглах
15 минутаас бага RTO шаарддаг олон терабайтын мэдээллийн сангийн хувьд уламжлалт файл хуулах нь стандарт сүлжээгээр физикийн хувьд боломжгүй юм. SAN эсвэл үүлэн төрлийн хадгалах сангийн агшин зуурын зурагтай (жишээ нь, AWS EBS Snapshots, Pure Storage) нэгтгэх нь T(restore)-ийг бараг агшин зуур гүйцэтгэх боломжийг олгодог. Дараа нь мэдээллийн сангийн хөдөлгүүр зөвхөн агшин зуурын зураг дээр ослын дараах сэргээлтийг хийх шаардлагатай болно.
3. Зэрэгцээ ажиллагааг (Parallelism) хэрэгжүүлэх
Таны нөөц хуулбар болон сэргээх хэрэгслүүд олон урсгалт (multi-threading) ашиглаж байгаа эсэхийг шалгаарай. PostgreSQL мэдээллийн санг pgbackrest ашиглан эсвэл SQL Server мэдээллийн санг сэргээхдээ сүлжээ болон дискний боломжит зурвасын өргөнийг бүрэн ашиглахын тулд зэрэгцээ ажиллах урсгалуудыг тодорхой зааж өгнө үү.
# pgBackRest-д зэрэгцээ сэргээх жишээ
pgbackrest --stanza=prod_db --process-max=8 restore
Дүгнэлт
Чухал ач холбогдолтой мэдээллийн сангуудын RTO болон RPO-г тооцоолох нь системийн инженерийн нарийн дасгал юм. Энэ нь DBA-уудаас нөөц хуулбарын үндсэн тохиргооноос илүү гарч, хадгалах сангийн I/O, сүлжээний хүчин чадал, мэдээллийн сангийн сэргээх механизмыг математикийн хувьд загварчлахыг шаарддаг.
Бүртгэл үүсгэх хурдыг суурь үзүүлэлт болгон тогтоох, мэдээллийн сангийн сэргээлтийн үе шатуудыг ойлгох, CloudSave зэрэг хүчирхэг платформуудаар дамжуулан автоматжуулсан туршилтыг хэрэгжүүлснээр IT багууд гамшгаас сэргээх SLA-гаа итгэлтэйгээр баталгаажуулж чадна. Санаж яваарай: мэдээллийн сангийн удирдлагын салбарт найдвар бол стратеги биш, харин туршигдаагүй нөөц хуулбар бол хариуцлага алдалт юм.
DevOps инженерүүд болон DBA-ууд дэвшилтэт сэргээх механизм, CLI хэрэгслүүд болон автоматжуулсан туршилтыг ашиглан чухал мэдээллийн сангуудын RTO болон RPO-г хэрхэн нарийн тооцоолох, турших, оновчтой болгох талаар суралцаарай.
