VPS-ல் வட்டு ஆரோக்கியத்தை கண்காணிப்பது எப்படி?

VPS-ல் வட்டு ஆரோக்கிய கண்காணிப்பு (Disk health monitoring) எதை உண்மையில் பார்க்கிறது

VPS-ல் வட்டு ஆரோக்கிய கண்காணிப்பு என்பது பெரும்பாலான வழிகாட்டிகள் தவிர்க்கும் ஒரு உண்மையிலிருந்து தொடங்குகிறது: அந்த வட்டு உங்களுடையது அல்ல. உங்கள் guest ஒரு virtual block device-ஐ மட்டுமே பார்க்கிறது. அந்த physical drive மற்றும் அதில் சேமிக்கப்பட்டுள்ள ஒவ்வொரு counter-ம் host-க்கு சொந்தமானது. smartctl /dev/vda கட்டளையை நீங்கள் தவறாகத் தட்டச்சு செய்ததால் அது தோல்வியடைவதில்லை. அந்த device-க்கு பின்னால் உள்ள எதனாலும் அந்த கேள்விக்கு பதில் அளிக்க முடியாததால் அது தோல்வியடைகிறது.

SMART (self-monitoring, analysis and reporting technology) என்பது drive-லேயே பராமரிக்கப்படும் counter-களின் அட்டவணை ஆகும்: reallocated sectors, pending sectors, power-on hours, media errors. அந்த அட்டவணையைப் படிக்க ATA அல்லது NVMe (non-volatile memory express) கட்டளைகள் உண்மையான hardware-ஐச் சென்றடைய ஒரு பாதை தேவை. ஒரு paravirtual disk அத்தகைய பாதையை வழங்குவதில்லை, எனவே guest-க்கு telemetry நீக்கப்பட்ட storage மட்டுமே கிடைக்கிறது.

ஒரு tenant hardware-ஐ அல்ல, அதன் விளைவுகளை மட்டுமே கண்காணிக்க முடியும். guest-க்குள் இருந்து நான்கு சமிக்ஞைகளை (signals) பார்க்க முடியும்: kernel log-ல் உள்ள I/O (input/output) பிழைகள், read-only ஆக மாறும் filesystem, படிப்படியாக அதிகரிக்கும் latency, மற்றும் தீர்ந்துபோகும் space. இந்த நான்கிற்கும் இப்போதே எச்சரிக்கைகளை (alerts) அமைக்கலாம், மேலும் பயனர் புகார் அளிப்பதற்கு முன்பே இவை நான்கும் வெளிப்படும். முதலில் இவற்றை அமைக்கவும். பொறுப்புகளின் பிரிவினை இறுதியில் வருகிறது, ஏனெனில் அது நீங்கள் எதில் அதிக கவனம் செலுத்த வேண்டும் என்பதை மாற்றுகிறது.

உங்கள் சொந்த server எதை வெளிப்படுத்துகிறது என்பதை நிரூபித்தல்

நீங்கள் எந்த நிலையில் இருக்கிறீர்கள் என்று ஊகிக்க வேண்டாம். முதலில் கவனியுங்கள், பிறகு பொருத்தமான பகுதியை வாசியுங்கள்.

sudo apt update && sudo apt install -y smartmontools nvme-cli
lsblk -o NAME,TYPE,SIZE,MODEL,TRAN
sudo smartctl -a /dev/vda

virtio-blk, வழக்கமான KVM (kernel-based virtual machine) வட்டு. சாதனம் /dev/vda ஆக உள்ளது மற்றும் smartctl எதையும் அனுப்புவதற்கு முன்பே நின்றுவிடுகிறது:

/dev/vda: Unable to detect device type
Please specify device type with the -d option.

virtio-blk என்பது ஒரு paravirtual transport ஆகும், இதன் பின்னால் ATA அல்லது SCSI கட்டளைத் தொகுப்பு (command set) இல்லை, எனவே SMART கோரிக்கையை எடுத்துச் செல்ல வழி இல்லை. -d sat மற்றும் -d scsi ஆகியவையும் அதே காரணத்தால் தோல்வியடைகின்றன, ஏனெனில் சிக்கல் transport-ல் உள்ளது, flag-ல் இல்லை.

ஒரு emulated SATA அல்லது SCSI வட்டு. சாதனம் /dev/sda ஆக உள்ளது மற்றும் smartctl அதை அடையாளம் காணும் அளவுக்குச் செயல்படுகிறது. மாதிரி வரி (model line) QEMU HARDDISK என்று காட்டுகிறது. அந்த string-ஏ கேள்விக்கு விடையளிக்கிறது: நீங்கள் emulator உருவாக்கிய ஒரு சாதனத்தை வாசிக்கிறீர்கள், அது பயன்படுத்தக்கூடிய SMART திறனை எதையும் கொண்டிருக்கவில்லை.

ஒரு NVMe namespace. sudo nvme smart-log /dev/nvme0n1 முழுமையான log-ஐத் தருகிறது, இதுவே மக்களை ஏமாற்றுகிறது. முதலில் sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)' மூலம் controller அடையாளத்தைச் சரிபார்க்கவும். ஒரு network storage தயாரிப்பின் பெயரைக்கொண்ட மாதிரி எண் (model number) இருந்தால், அந்த controller மென்பொருள் சார்ந்தது என்று அர்த்தம், எனவே percentage_used மற்றும் media_errors ஆகியவை உங்கள் தரவுகளுக்கு அடியில் உள்ள flash-ஐக் காட்டிலும் அந்த emulation-ஐயே விவரிக்கின்றன. உங்கள் storage உண்மையில் என்ன என்பதை அறிய விரும்பினால், திட்ட விளக்கத்தை நம்புவதற்குப் பதிலாக Linux-ல் NVMe வட்டைச் சரிபார்க்கவும்.

ஒரு container, உதாரணமாக LXC (Linux containers) அல்லது OpenVZ. உங்களுக்கென்று சொந்த block device இல்லை. lsblk host-ன் சாதனங்களைக் காட்டுகிறது அல்லது எதையும் காட்டாது, மேலும் container-ல் CAP_SYS_RAWIO இல்லாததால் smartctl மறுக்கப்படுகிறது:

Smartctl open device: /dev/sda failed: Permission denied

இது வேலை செய்யும் சூழல் குறித்து ஒரு எச்சரிக்கை. ஒரு VPS-ல் smartctl முழுமையான attribute அட்டவணையைத் தந்தால், நடவடிக்கை எடுப்பதற்கு முன் serial number-ஐ வாசிக்கவும். சில host-கள் passthrough device node-ஐ வெளிப்படுத்துகின்றன, அந்த counters அந்த machine-ல் உள்ள ஒவ்வொரு tenant-ம் பகிரும் வன்பொருளுக்குச் சொந்தமானவை. அங்கே Reallocated_Sector_Ct அதிகரிப்பது ஒரு support ticket-க்கான விஷயம். அது உங்கள் தரவு குறித்த அறிக்கை அல்ல.

சிக்னல் 1: கர்னல் பதிவுகளில் I/O பிழைகள்

இது ஒரு வாடிக்கையாளருக்குக் கிடைக்கும் மிக முக்கியமான சிக்னல் ஆகும், இதற்கு எந்தவொரு ஏஜென்ட்டும் தேவையில்லை.

sudo journalctl -k -p err -b
sudo journalctl -k --since "7 days ago" | grep -iE 'i/o error|remount|ext4-fs error|buffer i/o'

மெய்நிகர் வட்டில் (virtual disk) இருந்து வரும் தோல்வியுற்ற கோரிக்கை இவ்வாறு இருக்கும்:

blk_update_request: I/O error, dev vda, sector 2101248 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0

பிளாக் லேயர் (block layer) ஹோஸ்டிடம் ஒரு எழுதும் கோரிக்கையை (write request) அனுப்பியது, அதற்கு ஹோஸ்ட் தோல்வியைத் திரும்ப அளித்தது. ஒரு VPS-ல் இது அரிதாகவே ஃபிளாஷ் செல் (flash cell) பழுதடைவதால் நிகழ்கிறது. இது பொதுவாக ஹோஸ்ட் ஸ்டோரேஜ் லேயர் அல்லது நெட்வொர்க் இணைக்கப்பட்ட ஸ்டோரேஜுக்கான நெட்வொர்க் பாதையில் ஏற்படும் சிக்கலாகும், எனவே இது சேவை வழங்குநர் தரப்பில் ஏற்படும் நிகழ்வாகும். நேர முத்திரை (timestamp), சாதனத்தின் பெயர் மற்றும் செக்டார் (sector) ஆகியவற்றை உங்கள் டிக்கெட்டில் நகலெடுக்கவும், ஏனெனில் இவற்றை வைத்துதான் ஸ்டோரேஜ் குழுவினர் தங்கள் பதிவுகளுடன் ஒப்பிட்டுப் பார்க்க முடியும்.

ext4 வரிசையில் மிக முக்கியமானவை இந்த ஜோடி வரிகள்:

EXT4-fs error (device vda1): ext4_journal_check_start:83: comm cron: Detected aborted journal
EXT4-fs (vda1): Remounting filesystem read-only

இரண்டாவது வரிசைதான் பாதிப்பை ஏற்படுத்துகிறது, ஏனெனில் கணினி தொடர்ந்து இயங்கிக்கொண்டே இருக்கும். அது ping-க்கு பதிலளிக்கும், SSH-க்கு பதிலளிக்கும், ஆனால் ஒவ்வொரு எழுதும் கோரிக்கையும் தோல்வியடையும். உங்கள் அப்ளிகேஷன் ஒவ்வொரு கோரிக்கையிலும் பிழையை வெளிப்படுத்தினாலும், சாதாரண HTTP சோதனை தொடர்ந்து வெற்றிகரமாகவே காட்டும்.

XFS கோப்பு முறைமையை (filesystem) முடக்கிவிடும்:

XFS (vda1): metadata I/O error in "xfs_trans_read_buf_map+0x1c0/0x2e0" at daddr 0x2 len 1 error 5
XFS (vda1): I/O Error Detected. Shutting down filesystem

journalctl -k கட்டளையானது ஜர்னல் வட்டில் சேமிக்கப்பட்டிருந்தால் ஒழிய, தற்போதைய பூட் (boot) பதிவுகளை மட்டுமே வாசிக்கும். பல இமேஜ்கள் RAM-ல் இயங்கும் நிலையற்ற ஜர்னலை (volatile journal) கொண்டுள்ளன. பதிவுகளை நிலைத்திருக்கச் செய்யுங்கள் (persistence), இல்லையெனில் நீங்கள் சரிசெய்யும் போது செய்யும் ரீபூட்-ன் போதே ஆதாரங்கள் அழிந்துவிடும்.

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
journalctl --list-boots

உங்கள் அடுத்த ரீபூட்-க்கு பிறகு, journalctl --list-boots ஒன்றுக்கும் மேற்பட்ட பூட் பதிவுகளைக் காட்ட வேண்டும். நிலைத்தன்மை (persistence) ஆன் செய்யப்பட்டிருந்தாலும், ரீட்-ஒன்லி (read-only) நிலைக்குச் சென்ற கோப்பு முறைமையால் அதற்குப் பிறகு என்ன நடந்தது என்பதைப் பதிவு செய்ய முடியாது. இதனால்தான் பதிவுகளை சர்வரை விட்டு வெளியே அனுப்புவது (shipping logs off the box) அவசியமான வாதமாகிறது.

சிக்னல் 2: read-only remount-ஐக் கண்டறிதல்

பிழையைக் கண்டறிய முயற்சிக்கும் முன், அது வெளிப்படையாகத் தெரியும்படிச் செய்யுங்கள்.

findmnt -no SOURCE,FSTYPE,OPTIONS /

Options-ல் errors=remount-ro உள்ளதா என்று பாருங்கள். Ubuntu மற்றும் Debian cloud images-ல் இது /etc/fstab-ல் அமைக்கப்பட்டுள்ளது, எனவே metadata பிழை ஏற்பட்டால், சேதமடைந்த நிலையில் தொடர்ந்து இயங்காமல் filesystem-ஐ read-only நிலைக்கு மாற்றும். இது இல்லையென்றால், /etc/fstab-ல் உள்ள root entry-ல் இதைச் சேர்க்கவும், அல்லது sudo tune2fs -e remount-ro /dev/vda1 மூலம் superblock-ல் அமைக்கவும். அமைதியாகச் சிதைவதை விட, சத்தமாக நின்றுவிடுவது சிறந்தது.

Mount flag மட்டும் ஆதாரமாகாது. எழுதுவதன் மூலம் சோதிக்கவும்:

touch /var/tmp/.disk-probe

Read-only root-ல் இது சரியாக இதைக் காட்டும்:

touch: cannot touch '/var/tmp/.disk-probe': Read-only file system

/tmp-க்கு பதிலாக /var/tmp-ஐப் பயன்படுத்தவும். பெரும்பாலான images-ல் /tmp என்பது memory-ல் உள்ள tmpfs ஆகும், எனவே அங்கு வெற்றிகரமாக எழுதுவது உங்கள் disk-ஐப் பற்றி எதையும் நிரூபிக்காது.

எழுதும் சோதனையை space check-உடன் சேர்த்து, அனைத்து சோதனைகளும் தேர்ச்சி பெற்றால் மட்டுமே heartbeat அனுப்பவும்:

sudo tee /usr/local/sbin/disk-probe >/dev/null <<'EOF'
#!/bin/sh
set -eu
probe=/var/tmp/.disk-probe
echo ok > "$probe"
test "$(cat "$probe")" = ok
rm -f "$probe"
used=$(df --output=pcent / | tail -n1 | tr -dc '0-9')
test "$used" -lt 90
inodes=$(df --output=ipcent / | tail -n1 | tr -dc '0-9')
test "$inodes" -lt 90
curl -fsS --max-time 10 "https://status.example.com/api/push/REPLACE_TOKEN?status=up&msg=OK" >/dev/null
EOF
sudo chmod 755 /usr/local/sbin/disk-probe
sudo /usr/local/sbin/disk-probe && echo probe-ok

கடைசி வரியில் உள்ள probe-ok என்பது முழு சங்கிலியும் வேலை செய்கிறது என்று பொருள். set -eu, ஏதேனும் ஒரு சோதனை தோல்வியுற்றால் curl வரி இயங்குவதற்கு முன்பே non-zero exit-ஐக் கொடுக்கும், எனவே heartbeat அனுப்பப்படாது. இந்த தலைகீழ் மாற்றமே இதன் நோக்கம்: எதுவும் வராததால் monitor சிவப்பு நிறத்திற்கு மாறும்; எழுத முடியாத server தனது சொந்தப் பிரச்சினையை விவரிக்க நம்பகமானது அல்ல. Read-only filesystem-லும் reads வேலை செய்யும், எனவே script தானாகவே தொடங்கும்.

இதை systemd timer மூலம் இயக்கவும்.

# /etc/systemd/system/disk-probe.service
[Unit]
Description=Disk writability and space probe

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/disk-probe

# /etc/systemd/system/disk-probe.timer
[Unit]
Description=Run the disk probe every five minutes

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now disk-probe.timer
systemctl list-timers disk-probe.timer
journalctl -u disk-probe.service -n 20 --no-pager

systemctl list-timers, unit-ஐ NEXT நேரத்துடன் ஐந்து நிமிடங்களுக்குள் காட்ட வேண்டும். தோல்வியுற்ற run, journalctl -u disk-probe.service-ல் shell-ன் பிழைச் செய்தியுடன் தோன்றும், எனவே நீங்கள் login செய்யாமலேயே filesystem முழுமையாக உள்ளதா அல்லது read-only ஆக உள்ளதா என்பதை அறியலாம்.

அந்த push URL என்பது Uptime Kuma push monitor ஆகும். Push வகை monitor ஒன்றை உருவாக்கி, அதன் token-ஐ script-ல் நகலெடுத்து, monitor-ன் heartbeat interval-ஐ timer interval-ஐ விடச் சற்று அதிகமாக அமைக்கவும், அப்போதுதான் ஒரு மெதுவான run உங்களை அதிகாலை 03:00 மணிக்கு எழுப்பாது. உங்களிடம் இன்னும் status page இல்லையென்றால், சுயமாக இயங்கும் Uptime Kuma instance இந்தச் சோதனையைச் செய்ய மலிவான வழியாகும்.

இரண்டு உண்மையான வரம்புகள் உள்ளன. இந்த probe, ஒரு எழுத்து ஏற்றுக்கொள்ளப்பட்டதை உறுதிப்படுத்துமே தவிர, bytes பாதுகாப்பான சேமிப்பகத்தை (durable storage) அடைந்ததை உறுதிப்படுத்தாது, ஏனெனில் read back என்பது page cache-லிருந்து வரக்கூடும். மேலும், இது கண்காணிக்கும் machine-லேயே இயங்குவதால், முழுமையாக முடங்கிய server நோயறிதலைத் தெரிவிக்காமல் அமைதியாகிவிடும்.

சிக்னல் 3: லேட்டன்சி (latency) மற்றும் த்ரூபுட் (throughput) போக்குகள்

sudo apt install -y sysstat
iostat -xdz 5 3

முதலில் r_await மற்றும் w_await ஆகியவற்றை வாசிக்கவும். இவை ஒரு ரீட் (read) அல்லது ரைட் (write) செயல்பாட்டிற்கு எடுத்துக்கொண்ட சராசரி மில்லிசெகண்டுகள் ஆகும்; இதில் வரிசையில் (queue) காத்திருந்த நேரமும் அடங்கும். அடுத்து, செயல்பாட்டில் உள்ள கோரிக்கைகளின் சராசரி எண்ணிக்கையான aqu-sz-ஐ கவனிக்கவும். விர்ச்சுவல் டிஸ்க்கில் %util-ஐ புறக்கணிக்கவும்: இது வரிசை காலியாக இல்லை என்பதை மட்டுமே குறிக்கும். பல கோரிக்கைகளை இணையாகச் செயல்படுத்தும் ஒரு சாதனம், அதன் உச்ச வரம்பை எட்டாத நிலையிலும் 100 சதவீதத்திற்கு அருகில் காட்டக்கூடும். பயனர்கள் உணரும் அனுபவத்தை அளவிடும் எண் await ஆகும்.

முழுமையான மதிப்புகளை விட உங்கள் சொந்த அடிப்படை அளவீடுகளே (baseline) முக்கியம், எனவே அமைதியான நேரத்தில் ஒரு அளவீட்டை எடுத்து வைத்துக்கொள்ளுங்கள். நீங்களே கவுண்டர்களைச் சேகரிக்க விரும்பினால், அதற்கான மூலத் தரவு /proc/diskstats-ல் உள்ளது.

திட்டமிட்ட அளவீட்டிற்கு:

sudo apt install -y fio
fio --name=readlat --filename=/var/tmp/fio.probe --size=512M --rw=randread --bs=4k --iodepth=1 --direct=1 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fio.probe

clat percentiles தொகுப்பை, குறிப்பாக 99-வது சதவீதத்தை (99th percentile) வாசிக்கவும். --direct=1 உங்கள் பேஜ் கேச்-ஐ (page cache) தவிர்க்கும். இது ஹோஸ்டின் கேச்-ஐத் தவிர்க்காது, எனவே இதன் முடிவு உங்கள் ப்ராசஸிலிருந்து பிளாட்ஃபார்ம் ஸ்டோரேஜ் வரையிலான முழு பாதையையும் விவரிக்கிறது. சர்வர் சும்மா இருக்கும்போது இதை இயக்கவும், ஏனெனில் இது உங்கள் பணிச்சுமையுடன் போட்டியிடும்.

கர்னல் லாக்-ல் பிழைகள் ஏதுமின்றி await அதிகரிப்பது, பொதுவாக டிரைவ் பழுதடைந்ததைக் குறிப்பதில்லை. இது ஹோஸ்டில் ஏற்படும் நெரிசல் ஆகும்; இது CPU steal time from a noisy neighbour என்பதன் ஸ்டோரேஜ் பதிப்பாகும். இது தினமும் ஒரே நேரத்தில் நிகழ்ந்து, உங்கள் டிக்கெட்டிற்குத் தீர்வு கிடைக்கவில்லை என்றால், I/O பகிரப்படாத ஒரு பிளானைத் தேர்ந்தெடுப்பதே தீர்வாகும். பணிச்சுமை டிஸ்க் சார்ந்ததாக இருக்கும்போது, a storage VPS over a regular VPS இதற்குச் சிறந்த உதாரணம்.

Signal 4: mount செய்யப்பட்டிருக்கும்போது இயக்கக்கூடிய filesystem சோதனைகள்

ext4, தனது superblock-ல் பிழை எண்ணிக்கையை (error counter) வைத்திருக்கிறது. உங்கள் logs அழிந்தாலும், reboot செய்த பிறகும் இந்த எண்ணிக்கை நீடிக்கும்.

sudo dumpe2fs -h /dev/vda1 2>/dev/null | grep -iE 'filesystem state|error count|first error|last error'

ஆரோக்கியமான filesystem Filesystem state: clean மற்றும் FS Error count: 0 ஆகியவற்றை வெளியிடும். clean with errors மற்றும் பூஜ்ஜியம் அல்லாத எண்ணிக்கை இருந்தால், ஏதோ ஒரு கட்டத்தில் kernel ஒரு metadata பிழையைச் சந்தித்துள்ளது என்று அர்த்தம்; யாரும் கவனிக்காவிட்டாலும் அல்லது log கோப்புகள் அழிந்திருந்தாலும் இது பதிவாகியிருக்கும். இந்த ஒரு கட்டளையை வாராந்திர சோதனையில் சேர்த்துக்கொள்ள வேண்டும்.

Mount செய்யப்பட்ட root filesystem-ஐ fsck செய்ய முடியாது. இயங்கிக்கொண்டிருக்கும் filesystem-ல் e2fsck -n கட்டளையை இயக்கினால், தரவுகள் தொடர்ந்து மாறிக்கொண்டிருப்பதால் தவறான முடிவுகளே கிடைக்கும். உண்மையான சோதனையை மேற்கொள்ள, உங்கள் provider-ன் console மூலம் ஒருமுறை boot செய்யும்போது kernel command line-ல் fsck.mode=force fsck.repair=yes என்பதைச் சேர்க்கவும். அப்போது root filesystem read-write முறையில் mount செய்யப்படுவதற்கு முன்பே systemd-fsck சோதனையை நடத்திவிடும்.

XFS-ல் online சோதனை வசதி இல்லை. xfs_repair -n /dev/vda1 கட்டளை mount செய்யப்பட்ட filesystem-ல் இயங்க மறுத்துவிடும், எனவே இதை rescue mode-ல் மட்டுமே செய்ய முடியும். XFS-ன் சிறப்பு என்னவென்றால், metadata பிழை ஏற்பட்டால் அது தொடர்ந்து இயங்காமல், உடனடியாக filesystem-ஐ நிறுத்திவிடும் (shut down).

Btrfs-ல் இத்தகைய counters உள்ளமைக்கப்பட்டவை மற்றும் நிரந்தரமானவை.

sudo btrfs device stats /
sudo btrfs scrub start -B /

write_io_errs அல்லது corruption_errs ஆகியவற்றின் மதிப்பு பூஜ்ஜியத்திற்கு மேல் இருந்தால், அது ஒரு உண்மையான நிகழ்வாகும். நீங்கள் அவற்றை reset செய்யும் வரை, reboot செய்தாலும் இந்த counters மதிப்புகளைத் தக்கவைத்துக் கொள்ளும். scrub ஒவ்வொரு block-ஐயும் மீண்டும் படித்து அதன் checksum-ஐச் சரிபார்க்கும்; இது virtual disk-ல் செய்யக்கூடிய media test-க்கு இணையானது. இது அதிக I/O-வை எடுத்துக்கொள்ளும் என்பதால், பயன்பாடு குறைவாக இருக்கும் நேரத்தில் இதைத் திட்டமிடுங்கள்.

சிக்னல் 5: காலியான இடம், df மறைக்கும் பகுதிகள் உட்பட

வட்டு பழுதடைவது போலவே, சேமிப்பக இடம் தீர்ந்துபோவதும் server-ஐ முடக்கும்; ஆனால் இதுவே அடிக்கடி நிகழ்கிறது.

df -h /
df -i /
sudo du -xh --max-depth=1 / | sort -h | tail -n 20

No space left on device இயங்கும்போது df -h காலியான இடத்தைக் காட்டுகிறது என்றால், நீங்கள் பைட்டுகளை விட inodes-ஐ தீர்த்துவிட்டீர்கள் என்று அர்த்தம். அப்போது df -i ஆனது IUse% 100 சதவீதத்தில் இருப்பதைக் காட்டும். cache directory அல்லது mail spool-ல் உள்ள லட்சக்கணக்கான சிறிய கோப்புகள் இதற்கு காரணமாகும்; பெரிய கோப்புகளை நீக்குவதால் எந்தப் பயனும் இருக்காது.

கோப்புகளை நீக்கிய பிறகும் இடம் திரும்பக் கிடைக்கவில்லை என்றால், ஏதோ ஒரு இயங்கும் process அந்த நீக்கப்பட்ட கோப்பை இன்னும் திறந்து வைத்திருக்கிறது என்று அர்த்தம். sudo lsof +L1 கட்டளை, link count பூஜ்ஜியத்தை எட்டிய கோப்புகளைப் பட்டியலிடும். அந்த கோப்பை வைத்திருக்கும் process-ஐ restart செய்தால் மட்டுமே இடம் விடுவிக்கப்படும்.

Systemd journal பெரும்பாலும் அமைதியாக இடத்தைப் பிடிக்கும். journalctl --disk-usage கட்டளை அது எவ்வளவு இடத்தைப் பிடித்துள்ளது என்பதைக் காட்டும். /etc/systemd/journald.conf கோப்பில் SystemMaxUse=200M மூலம் அதன் அளவைக் கட்டுப்படுத்தவும், பின் sudo systemctl restart systemd-journald கட்டளையை இயக்கவும். இப்போது sudo journalctl --vacuum-size=200M மூலம் அந்த இடத்தை மீட்டெடுக்கலாம்.

ஒரு சூழல் பிழை போலத் தோன்றும், ஆனால் அது பிழை அல்ல. Thin provisioned host storage-ல், உங்கள் df காலியான gigabytes-ஐக் காட்டினாலும், host-ன் pool நிரம்பியிருக்கலாம். அப்போது உங்கள் எழுதும் செயல்பாடுகள் (writes) kernel log-ல் I/O பிழைகளைத் தரும், ஆனால் guest-க்குள் எந்த இடப்பற்றாக்குறை எச்சரிக்கையும் இருக்காது. கோப்பு முறைமை (filesystem) நிரம்பாத நிலையில் இத்தகைய பிழைகள் ஏற்பட்டால், உடனடியாக ticket பதிவு செய்ய வேண்டும்.

Metrics agent-ல் சிக்னல்களை இணைத்தல்

ஒரு push probe ஆம் அல்லது இல்லை என்று மட்டுமே பதிலளிக்கும். போக்குகளை (trends) கண்காணிக்க ஒரு metrics agent தேவை. Prometheus node_exporter ஏற்கனவே மேலே உள்ள அனைத்தையும் எந்த கூடுதல் அமைப்பும் இன்றி ஏற்றுமதி செய்கிறது. நாம் பயன்படுத்த வேண்டிய metric பெயர்கள்:

• node_filesystem_readonly என்பது mount read-only நிலையில் இருக்கும்போது 1 என மாறும், இதுவே உங்கள் remount எச்சரிக்கை.
• node_filesystem_avail_bytes மற்றும் node_filesystem_files_free ஆகியவை முறையே bytes மற்றும் inodes-ஐக் குறிக்கின்றன.
• node_disk_io_time_seconds_total மற்றும் node_disk_read_time_seconds_total ஆகியவை busy time மற்றும் latency ஆகியவற்றை வரைபடமாக்க உதவும் counters-ஆக வழங்குகின்றன.

உண்மையான எச்சரிக்கைகளை (page) தூண்டும் இரண்டு விதிகள் கீழே உள்ளன:

- alert: FilesystemReadOnly
  expr: node_filesystem_readonly{fstype!~"tmpfs|overlay"} == 1
  for: 2m
- alert: FilesystemFillingUp
  expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 4*24*3600) < 0
  for: 30m

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

யாருடைய பொறுப்பு என்ன

உங்களது service provider இயற்பியல் ரீதியான drives-க்கு உரிமையாளர். அவர்களே SMART தரவுகளைக் கண்காணித்து, array-ஐ நிர்வகித்து, reallocated sectors அதிகரிக்கும் போது drives-ஐ மாற்றுகிறார்கள். array அந்தப் பாதிப்பைத் தாங்கிக்கொள்வதால், பெரும்பாலும் உங்களுக்குத் தெரிவிக்காமலேயே இதைச் செய்கிறார்கள். இதற்காகத்தான் RAID 10 under your VPS பயன்படுகிறது: ஒரு drive பழுதடைந்தால், அது சேவை முடக்கத்திற்குப் பதிலாக rebuild செயலாக மாறுகிறது. உங்களால் இதைப் பார்க்க முடியாது, இந்த abstraction-க்காகக் கட்டணம் செலுத்துவதே virtual server வாடகைக்கு எடுப்பதன் முக்கிய நோக்கமாகும்.

உங்கள் தரவுகளுக்கு நீங்களே உரிமையாளர், drive telemetry-ஆல் தரவுகளைப் பாதுகாக்க முடியாது. வாடிக்கையாளரின் தரவுகளை அழிக்கும் நிகழ்வுகள் என்பவை: தவறுதலாகச் செய்யப்படும் rm, தவறான deploy, உங்கள் SSH key-ஐக் கைப்பற்றிய ஊடுருவல்காரர், மற்றும் array-ஐயே பாதிக்கும் platform incident போன்றவை ஆகும். SMART attributes இவற்றில் எதையும் முன்கூட்டியே கணிக்காது.

எனவே, ஒரு வாடிக்கையாளரின் உண்மையான பாதுகாப்பு என்பது server-க்கு வெளியே இருக்கும் backup மற்றும் நீங்களே செய்து பார்த்த restore செயல்முறை மட்டுமே. Provider snapshots வசதியானவை, ஆனால் அவை பாதுகாக்க வேண்டிய அதே platform-ல் இருப்பதால், snapshots and backups are different protections என்பதை நினைவில் கொள்ளவும். காலண்டரில் ஒரு பயிற்சியைக் குறித்துக்கொள்ளுங்கள்: காலாண்டுக்கு ஒருமுறை, புதிய VPS-ல் சமீபத்திய backup-ஐ restore செய்து, application-ஐத் தொடங்கி, அதற்கு எவ்வளவு நேரம் ஆனது என்பதைக் குறித்துக்கொள்ளுங்கள். அந்த நேரமே உங்கள் உண்மையான recovery time ஆகும். முதல்முறை செய்யும் பயிற்சி எப்போதும் அனைவரும் எதிர்பார்த்ததை விட மெதுவாகவே இருக்கும்.

SMART உங்களுக்கு எப்போது பொருந்தும்

smartctl-ஐக் கற்பிக்கும் வழிகாட்டிகள் சரியானவை, வன்பொருள் (hardware) முழுமையாக உங்கள் கட்டுப்பாட்டில் வந்தவுடன் அவை பொருந்தும்:

• பிரத்யேக அல்லது bare metal server, இதில் sudo smartctl -a /dev/sda முழுமையான பண்புக்கூறு அட்டவணையை (attribute table) வழங்கும் மற்றும் ஒரு பண்புக்கூறு மாறும்போது smartd உங்களுக்கு மின்னஞ்சல் அனுப்பும்.
• ஒரு இயற்பியல் வட்டை (physical disk) guest-க்கு வழங்கும் சேமிப்பகத் திட்டங்கள் (storage plans). இது ஒரு விற்பனை அம்சம் என்பதால், வழங்குநர்கள் இதைத் தெளிவாக ஆவணப்படுத்துவார்கள்.
• நீங்கள் சொந்தமாக வைத்திருக்கும் வன்பொருள், வீட்டில் அல்லது நீங்கள் வாடகைக்கு எடுத்த rack space-ல் உள்ளவை.
• RAID controller-க்கு பின்னால் உள்ள வட்டு, இதை sudo smartctl -a -d megaraid,0 /dev/sda மூலம் அணுகலாம், அல்லது -d sat கொண்ட USB enclosure.

உண்மையான NVMe-ல், sudo smartctl -a -d nvme /dev/nvme0 மற்றும் sudo nvme smart-log /dev/nvme0n1 ஆகியவை வட்டில் இருந்தே critical_warning மற்றும் percentage_used ஆகியவற்றைத் தெரிவிக்கின்றன. உண்மையான SATA-வில், செயலிழப்பைக் கணிக்கும் பண்புக்கூறுகள் Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) மற்றும் Reported_Uncorrect (187) ஆகும். இவற்றில் ஏதேனும் ஒன்று பூஜ்ஜியத்திலிருந்து மாறினால், வட்டை மாற்றத் திட்டமிடுங்கள். பெரிய அளவிலான வட்டு ஆய்வுகள் இந்தச் சிறிய பட்டியலையே மீண்டும் மீண்டும் உறுதிப்படுத்துகின்றன, மற்ற பண்புக்கூறுகள் பெரும்பாலும் தேவையற்ற தரவுகளே (noise).

கைமுறையாகச் சரிபார்ப்பதை விட, daemon-ஐ இயக்குவது சிறந்தது.

sudo systemctl enable --now smartd
sudo smartctl -t short /dev/sda
sudo smartctl -l selftest /dev/sda

சுய-சோதனைப் பதிவேடு (self-test log), நீங்கள் இப்போது தொடங்கிய சோதனைக்கு Completed without error என்பதைக் காட்ட வேண்டும். Ubuntu மற்றும் Debian ஆகியவை /etc/smartd.conf-ஐ DEVICESCAN வரியுடன் வழங்குகின்றன, இது ஆகஸ்ட் 2026 நிலவரப்படி புதுப்பிக்கப்பட்டது. எனவே, daemon தனக்குத் தெரியும் ஒவ்வொரு வட்டியையும் கண்டறிந்து, மாற்றம் ஏற்படும்போது root-க்கு மின்னஞ்சல் அனுப்பும். virtual disk-ல் இவை எதுவும் வேலை செய்யாது, அதனால்தான் இந்த வழிகாட்டியின் மீதமுள்ள பகுதிகள் தேவைப்படுகின்றன.

FAQ

எனது VPS-ல் ஏன் smartctl வேலை செய்யவில்லை?

ஏனெனில் வட்டு (disk) மெய்நிகரானது (virtual). virtio-blk பயன்படுத்தும் KVM guest-ல், smartctl -a /dev/vda கட்டளை /dev/vda: Unable to detect device type என்று வெளியிடும். ஏனெனில், ஒரு paravirtual disk-ல் SMART கோரிக்கையை அனுப்ப ATA அல்லது SCSI கட்டளை வழித்தடம் (command channel) இருக்காது. ஒரு emulated disk-ல் நீங்கள் அணுகும் சாதனத்தின் மாதிரி (model) QEMU HARDDISK என்று இருக்கும், அதன் பின்னால் பயன்படுத்தக்கூடிய SMART தரவுகள் இருக்காது. ஒரு container-க்குள், CAP_SYS_RAWIO இல்லாததால் smartctl நேரடியாக மறுக்கப்படும். இவை எதுவும் தவறான கட்டமைப்பு (misconfiguration) அல்ல, எந்த -d flag-ஐயும் பயன்படுத்தி இதைச் சரிசெய்ய முடியாது.

எனது VPS வட்டு பழுதடைகிறதா என்பதை எப்படி அறிவது?

வன்பொருளை விட விளைவுகளைக் கவனியுங்கள். blk_update_request: I/O error வரிகள் மற்றும் Remounting filesystem read-only உள்ளதா என sudo journalctl -k -p err -b-ஐச் சரிபார்க்கவும். பதிவுகளில் விடுபட்ட பிழைகளைக் கண்டறிய sudo dumpe2fs -h /dev/vda1 | grep -i 'error count'-ஐ இயக்கவும். கணினி ஆரோக்கியமாக இருந்தபோது நீங்கள் பதிவு செய்த அடிப்படை அளவுகளுடன் (baseline), iostat -xdz 5-லிருந்து r_await-ஐ ஒப்பிட்டுப் பார்க்கவும். VPS-ல் ஒரு I/O பிழை என்பது பொதுவாக வட்டு பழுதடைவதை விட, host storage சிக்கலையே குறிக்கும். எனவே, நேர முத்திரை (timestamp) மற்றும் sector விவரங்களுடன் இதை support ticket-ஆக அனுப்பவும்.

VPS வட்டு ஆரோக்கியத்திற்காக எவற்றிற்கு எச்சரிக்கை (alert) அமைக்க வேண்டும்?

நான்கு எச்சரிக்கைகள் போதுமானவை. node_filesystem_readonly == 1 அல்லது தோல்வியுறும் write probe மூலம் கண்டறியப்படும் read-only mount. பூஜ்ஜியத்தை நோக்கிச் செல்லும் free space மற்றும் free inodes. கடந்த இடைவெளியில் ஏற்பட்ட ஏதேனும் kernel I/O error. சர்வர் பதிலளிக்காதபோது உங்களை எச்சரிக்க, சர்வரிலிருந்து வரும் heartbeat. SMART-லிருந்து பெறப்படும் எதையும் தவிர்க்கவும், ஏனெனில் மெய்நிகர் வட்டில் அந்த மதிப்புகள் ஒன்று இல்லை அல்லது hypervisor-ன் emulation-ஐ விவரிக்கின்றன.

எனது filesystem ஏன் read-only ஆக மாறியது?

errors=remount-ro உடன் mount செய்யப்பட்ட ext4, metadata பிழையைச் சந்திக்கும்போது வேண்டுமென்றே இவ்வாறு செய்யும்: சேதத்தை மேலும் அதிகரிக்காமல் இருக்க அது எழுதுவதை நிறுத்திவிடும். இதற்கான காரணம் remount வரிக்கு சற்று மேலே kernel log-ல் இருக்கும். பொதுவாக, underlying device ஒரு I/O பிழையைத் திருப்பி அனுப்பிய பிறகு, aborted journal பற்றிய EXT4-fs error பிழை அங்கு இருக்கும். filesystem-ஐச் சரிபார்க்காமல் மீண்டும் read-write ஆக மாற்றுவது அறிகுறியை மறைக்கும், ஆனால் காரணத்தை அப்படியே வைத்திருக்கும். log-ஐச் சேகரித்து, rescue mode-ல் filesystem-ஐ unmount செய்து e2fsck -fy /dev/vda1 மூலம் சரிபார்க்கவும்.

மெய்நிகர் சர்வரில் எப்போதாவது SMART தரவுகளைப் படிக்க முடியுமா?

குறிப்பிட்ட சூழல்களில், முடியும். Dedicated மற்றும் bare metal சர்வர்கள் உண்மையான பண்புகளை (attributes) வழங்கும். ஒரு physical disk-ஐ guest-க்கு நேரடியாக வழங்கும் storage திட்டங்கள் மற்றும் நீங்கள் சொந்தமாக வைத்திருக்கும் host-களிலும் இது சாத்தியம். சில தளங்கள் NVMe controller-ஐ guest-க்கு வழங்கும், அப்போது nvme smart-log ஒரு log-ஐத் திருப்பித் தரும். எனவே முதலில் sudo nvme id-ctrl /dev/nvme0-ஐ இயக்கவும்: network storage சேவையின் மாதிரி எண் (model number) இருந்தால், அந்த counters மென்பொருள் controller-லிருந்து வருகின்றன என்று அர்த்தம். ஒரு shared machine-ல் passthrough node உண்மையான counters-ஐக் காட்டினாலும், அவை மற்ற பயனர்களுடன் பகிரப்பட்ட வன்பொருளை விவரிக்கும். எனவே, support ticket அனுப்புவதே ஒரே பயனுள்ள வழி.