முக்கியமான தரவுத்தளங்களுக்கான RTO மற்றும் RPO-வை கணக்கிடுதல்: ஒரு DBA-வின் வழிகாட்டி

DevOps பொறியாளர்கள், தரவுத்தள நிர்வாகிகள் (DBAs) மற்றும் IT சிஸ்டம் ஆர்க்கிடெக்டர்களுக்கு, மீட்பு நேர இலக்கு (RTO) மற்றும் மீட்பு புள்ளி இலக்கு (RPO) ஆகியவை வணிகத் தொடர்ச்சி தொடர்பான வெறும் வார்த்தைகள் மட்டுமல்ல—அவை கடுமையான பொறியியல் கட்டுப்பாடுகள். முக்கியமான தரவுத்தளங்களை நிர்வகிக்கும்போது, இந்த அளவீடுகளைத் துல்லியமாகக் கணக்கிடத் தவறுவது, அதற்கான கட்டமைப்பை உருவாக்கத் தவறுவது மற்றும் அவற்றைச் சரிபார்க்கத் தவறுவது பேரழிவுகரமான தரவு இழப்பு மற்றும் நீண்ட கால வேலையில்லா நேரத்திற்கு (downtime) வழிவகுக்கும்.

நவீன நிறுவனச் சூழல்களில், 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-க்கு மேல் நீடித்த எழுதும் வேகத்தை ஆதரிக்க வேண்டும்.

ஒத்திசைவான (Synchronous) மற்றும் ஒத்திசைவற்ற (Asynchronous) பிரதிபலிப்பின் தாக்கம்

பல DBAs RPO-வை பூர்த்தி செய்ய உயர் கிடைக்கும் தன்மை (HA) பிரதிபலிப்பை நம்பியிருக்கிறார்கள். இருப்பினும், பிரதிபலிப்பு என்பது காப்புப்பிரதி அல்ல. நீக்கப்பட்ட ஒரு அட்டவணை (DROP TABLE users;) உடனடியாகப் பிரதிபலிக்கப்படும்.

பேரிடர் மீட்புக்கு (DR) பிரதிபலிப்பைப் பயன்படுத்தும்போது, பிரதிபலிப்பு முறை நேரடியாக RPO-வை பாதிக்கிறது:
* ஒத்திசைவான பிரதிபலிப்பு (Synchronous Replication): பூஜ்ஜிய RPO-வை (RPO=0) உறுதி செய்கிறது. முதன்மை தரவுத்தளம் ஸ்டேண்ட்பை தரவுத்தளம் ரசீதை உறுதிப்படுத்தும் வரை ஒரு பரிவர்த்தனையை உறுதிப்படுத்தாது. இதன் விலை முதன்மை எழுதும் செயல்பாடுகளில் தாமதம் அதிகரிப்பதாகும்.
* ஒத்திசைவற்ற பிரதிபலிப்பு (Asynchronous Replication): பிரதிபலிப்பு தாமதத்தை (lag) அறிமுகப்படுத்துகிறது. உங்கள் 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)

1. T(infra) – உள்கட்டமைப்பு ஏற்பாடு: மாற்று கணினி மற்றும் சேமிப்பகத்தை உருவாக்குவதற்கான நேரம். (முன்கூட்டியே வழங்கப்பட்ட DR தளங்கள் அல்லது உள்கட்டமைப்பு-குறியீடு குழாய்கள் மூலம் இது பூஜ்ஜியத்திற்கு அருகில் இருக்கலாம்).
2. T(transfer) – தரவு பரிமாற்றம்: காப்புப்பிரதி தரவை களஞ்சியத்திலிருந்து தரவுத்தள சர்வருக்கு நகர்த்தும் நேரம்.
3. T(restore) – இயற்பியல் மீட்பு: தரவு கோப்புகளை இலக்கு வட்டில் எழுதும் நேரம்.
4. 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-வைக் கோரினால், பாரம்பரிய ஸ்ட்ரீமிங் மீட்புகள் தோல்வியடையும். நீங்கள் உங்கள் கட்டமைப்பை சேமிப்பக-நிலை ஸ்னாப்ஷாட்கள் அல்லது பிளாக்-நிலை பிரதிபலிப்புக்கு மாற்ற வேண்டும்.

மறைந்திருக்கும் ஆபத்து: T(recovery)

அடிக்கடி குறைத்து மதிப்பிடப்படும் மாறி T(recovery) ஆகும். நீங்கள் வாராந்திர முழு காப்புப்பிரதியை மீட்டெடுத்து, உங்கள் RPO-வை அடைய 6 நாட்களுக்கான பரிவர்த்தனை பதிவுகளைப் பயன்படுத்த வேண்டியிருந்தால், தரவுத்தள இயந்திரம் ஒவ்வொரு பரிவர்த்தனையையும் வரிசையாக மீண்டும் இயக்க வேண்டும்.

500 GB பரிவர்த்தனை பதிவுகளை மீண்டும் இயக்குவதற்கு பல மணிநேரம் ஆகலாம், இது ஒற்றை-திரிக்கப்பட்ட CPU செயல்திறன் மற்றும் சேமிப்பக IOPS ஆகியவற்றால் பெரிதும் பாதிக்கப்படும். T(recovery)-ஐக் குறைக்க, உங்கள் முழு அல்லது வேறுபட்ட காப்புப்பிரதிகளின் அதிர்வெண்ணை அதிகரிக்கவும்.

இடைவெளியைக் குறைத்தல்: RTO மற்றும் RPO-வைச் சரிபார்க்க நடைமுறை நடவடிக்கைகள்

கோட்பாட்டு ரீதியான RTO மற்றும் RPO-வைக் கணக்கிடுவது முதல் படி மட்டுமே. முக்கியமான சூழல்களுக்குத் தொடர்ச்சியான சரிபார்ப்பு தேவை.

படி 1: தொடர்ச்சியான காப்பகத்தை (Continuous Archiving) செயல்படுத்துதல்

ஒத்திசைவான பிரதிபலிப்பின் செயல்திறன் குறைபாடு இல்லாமல் நிமிடத்திற்கு குறைவான RPO-க்களை அடைய, தொடர்ச்சியான பதிவு காப்பகத்தை செயல்படுத்தவும். ஒரு பதிவு கோப்பு நிரம்பும் வரை காத்திருப்பதற்குப் பதிலாக (குறைந்த போக்குவரத்து காலங்களில் இதற்கு பல மணிநேரம் ஆகலாம்), வழக்கமான இடைவெளியில் பதிவு மாற்றங்களை கட்டாயமாக்குங்கள்.

SQL Server-இல், நீங்கள் அடிக்கடி பரிவர்த்தனை பதிவு காப்புப்பிரதிகளை தானியக்கமாக்கலாம்:

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 தானாகவே ஒரு சாண்ட்பாக்ஸ் சூழலை உருவாக்கி, சமீபத்திய காப்புப்பிரதியை மவுண்ட் செய்து, முழு தரவுத்தள மீட்பைச் செய்து, தனிப்பயன் சரிபார்ப்பு ஸ்கிரிப்ட்களை (உதாரணமாக, SQL Server-க்கு DBCC CHECKDB) இயக்கி, சரியான RTO-வை அளவிடவும் தரவு ஒருமைப்பாட்டை உறுதிப்படுத்தவும் முடியும். இது RTO-வை ஒரு கணக்கிடப்பட்ட யூகத்திலிருந்து நிரூபிக்கப்பட்ட, அறிக்கையிடக்கூடிய அளவீடாக மாற்றுகிறது.

படி 3: SLA மீறல்களைக் கண்காணித்தல் மற்றும் எச்சரித்தல்

உங்கள் கண்காணிப்பு அடுக்கு (Prometheus, Datadog, Zabbix) உங்கள் RTO/RPO SLA-க்களை அச்சுறுத்தும் அளவீடுகளைத் தீவிரமாகக் கண்காணிக்க வேண்டும். இதற்கான எச்சரிக்கை விதிகள் கட்டமைக்கப்பட வேண்டும்:
* காப்புப்பிரதி வேலை தோல்விகள்: RPO-க்கு உடனடி அச்சுறுத்தல்.
* பதிவு அனுப்பும் தாமதம்: பதிவு பரிமாற்றம் உருவாக்கும் இடைவெளியை விட அதிக நேரம் எடுத்தால்.
* சேமிப்பக IOPS த்ரோட்லிங்: கிளவுட் வழங்குநர்கள் (AWS EBS போன்றவை) பர்ஸ்ட் கிரெடிட்கள் தீர்ந்துவிட்டால் IOPS-ஐக் கட்டுப்படுத்துவார்கள், இது உண்மையான அவசரநிலையின் போது உங்கள் RTO-வை அமைதியாக அழித்துவிடும்.

கடுமையான SLA-க்களைப் பூர்த்தி செய்ய தரவுத்தள காப்புப்பிரதி கட்டமைப்பை மேம்படுத்துதல்

கணிதக் கணக்கீடுகள் உங்கள் தற்போதைய கட்டமைப்பு வணிக SLA-க்களைப் பூர்த்தி செய்ய முடியாது என்பதைக் காட்டும்போது, உங்கள் காப்புப்பிரதி உத்தியை நீங்கள் மேம்படுத்த வேண்டும்.

1. பிளாக்-நிலை அதிகரிப்பு காப்புப்பிரதிகளைப் பயன்படுத்துதல்

பாரம்பரிய தரவுத்தள டம்ப்கள் (pg_dump அல்லது mysqldump போன்ற தர்க்கரீதியான காப்புப்பிரதிகள்) முக்கியமான RTO-க்களுக்கு மிகவும் மெதுவானவை. இயற்பியல், பிளாக்-நிலை காப்புப்பிரதிகளைப் பயன்படுத்தவும். பிளாக்-நிலை அதிகரிப்பு காப்புப்பிரதிகள் கடைசி காப்புப்பிரதிக்குப் பிறகு மாறிய வட்டு பிளாக்குகளை மட்டுமே நகலெடுக்கின்றன, இது T(transfer) மற்றும் நெட்வொர்க் சுமையைக் கணிசமாகக் குறைக்கிறது.

2. சேமிப்பக ஸ்னாப்ஷாட்களைப் பயன்படுத்துதல்

15 நிமிடங்களுக்கும் குறைவான RTO தேவைப்படும் பல-டெராபைட் தரவுத்தளங்களுக்கு, சாதாரண நெட்வொர்க்குகளில் பாரம்பரிய கோப்பு நகலெடுப்பு உடல் ரீதியாக சாத்தியமற்றது. SAN அல்லது கிளவுட்-நேட்டிவ் சேமிப்பக ஸ்னாப்ஷாட்களுடன் (உதாரணமாக, AWS EBS Snapshots, Pure Storage) ஒருங்கிணைப்பு உடனடி T(restore)-க்கு அனுமதிக்கிறது. தரவுத்தள இயந்திரம் பின்னர் ஸ்னாப்ஷாட்டில் செயலிழப்பு மீட்பை மட்டுமே செய்ய வேண்டும்.

3. இணையாகச் செயல்படுத்துதல் (Parallelism)

உங்கள் காப்புப்பிரதி மற்றும் மீட்பு கருவிகள் பல-திரிபுகளை (multi-threading) பயன்படுத்துவதை உறுதி செய்யவும். pgbackrest அல்லது SQL Server தரவுத்தளத்தைப் பயன்படுத்தி PostgreSQL தரவுத்தளத்தை மீட்டெடுக்கும்போது, உங்கள் கிடைக்கக்கூடிய நெட்வொர்க் மற்றும் வட்டு அலைவரிசையை முழுமையாகப் பயன்படுத்த இணையாகச் செயல்படும் பணியாளர்களை (parallel worker threads) வரையறுக்கவும்.

# pgBackRest-இல் இணையான மீட்புக்கான உதாரணம்
pgbackrest --stanza=prod_db --process-max=8 restore

முடிவு

முக்கியமான தரவுத்தளங்களுக்கான RTO மற்றும் RPO-வைக் கணக்கிடுவது சிஸ்டம்ஸ் இன்ஜினியரிங்கில் ஒரு கடுமையான பயிற்சியாகும். இது DBAs இயல்புநிலை காப்புப்பிரதி கட்டமைப்புகளைத் தாண்டி, தங்கள் சேமிப்பக I/O, நெட்வொர்க் திறன் மற்றும் தரவுத்தள மீட்பு இயக்கவியலை கணித ரீதியாக மாதிரியாக்க வேண்டும்.

பதிவு உருவாக்கும் விகிதங்களை அடிப்படையாகக் கொண்டு, தரவுத்தள மீட்பின் தனித்துவமான நிலைகளைப் புரிந்துகொண்டு, CloudSave போன்ற வலுவான தளங்கள் மூலம் தானியங்கி சோதனையைச் செயல்படுத்துவதன் மூலம், IT குழுக்கள் தங்கள் பேரிடர் மீட்பு SLA-க்களை நம்பிக்கையுடன் உறுதிப்படுத்த முடியும். நினைவில் கொள்ளுங்கள்: தரவுத்தள நிர்வாகத்தில், நம்பிக்கை என்பது ஒரு உத்தி அல்ல, மேலும் சோதிக்கப்படாத காப்புப்பிரதிகள் ஒரு பொறுப்பு (liability) ஆகும்.

DevOps பொறியாளர்கள் மற்றும் DBAs மேம்பட்ட மீட்பு இயக்கவியல், CLI கருவிகள் மற்றும் தானியங்கி சோதனையைப் பயன்படுத்தி முக்கியமான தரவுத்தளங்களுக்கான RTO மற்றும் RPO-வை எவ்வாறு துல்லியமாகக் கணக்கிட, சோதிக்க மற்றும் மேம்படுத்தலாம் என்பதை அறிக.