VPSలో డిస్క్ ఆరోగ్యాన్ని ఎలా పర్యవేక్షించాలి

VPSలో డిస్క్ ఆరోగ్య పర్యవేక్షణ వాస్తవంగా ఏమి చూడగలదు

VPSలో డిస్క్ ఆరోగ్య పర్యవేక్షణ ఒక ముఖ్యమైన వాస్తవంతో ప్రారంభమవుతుంది: ఆ డిస్క్ మీది కాదు. మీ guestకు కనిపించేది ఒక virtual block device మాత్రమే. భౌతిక drive మరియు దానిలో నిల్వైన ప్రతి counter hostకు చెందుతాయి. smartctl /dev/vda విఫలమవడం మీరు commandను తప్పుగా టైప్ చేసినందువల్ల కాదు. ఆ device వెనుక ఉన్నదేదీ ఆ ప్రశ్నకు సమాధానం ఇవ్వలేకపోవడం వల్ల అది విఫలమవుతుంది.

SMART (self-monitoring, analysis and reporting technology) అనేది driveలోనే నిల్వ ఉండే counters పట్టిక. ఇందులో reallocated sectors, pending sectors, power-on hours, media errors ఉంటాయి. ఆ పట్టికను చదవాలంటే ATA లేదా NVMe (non-volatile memory express) commands నిజమైన hardwareకు చేరే మార్గం ఉండాలి. Paravirtual disk అలాంటి మార్గాన్ని అందించదు. అందువల్ల guestకు telemetry తొలగించబడిన storage మాత్రమే లభిస్తుంది.

Tenant hardwareను కాకుండా దాని ప్రభావాలను పర్యవేక్షిస్తాడు. Guestలో నుంచి నాలుగు signals కనిపిస్తాయి: kernel logలో I/O (input/output) errors, read-onlyగా remount అయ్యే 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) disk. device /dev/vda గా ఉంటుంది. smartctl ఏదైనా పంపకముందే ఆగిపోతుంది:

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

virtio-blk అనేది వెనుక ATA లేదా SCSI command set లేని paravirtual transport. అందువల్ల SMART అభ్యర్థనను మోసుకెళ్లే channel ఉండదు. -d sat మరియు -d scsi కూడా ఇదే విధంగా విఫలమవుతాయి. కారణం flag కాదు, transport సమస్య.

Emulated SATA లేదా SCSI disk. device /dev/sda గా ఉంటుంది. smartctl దానిని గుర్తించేంత వరకు ముందుకు వెళ్తుంది. model line ఇలా ఉంటుంది: QEMU HARDDISK. ఆ string తోనే సమాధానం తెలుస్తుంది: మీరు emulator సృష్టించిన device ను చదువుతున్నారు. అది ఉపయోగించగల SMART సామర్థ్యం లేదని నివేదిస్తుంది.

NVMe namespace. sudo nvme smart-log /dev/nvme0n1 పూర్తి log ను చూపిస్తుంది. ఇక్కడే చాలామంది తప్పుదారి పడతారు. ముందుగా sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)' తో controller identity ను పరిశీలించండి. Network storage product పేరును సూచించే model number ఉంటే controller software ఆధారితమని అర్థం. అందువల్ల percentage_used మరియు media_errors మీ data ఉన్న flash గురించి కాకుండా ఆ emulation గురించి వివరిస్తాయి. మీ storage వాస్తవంగా ఏమిటో తెలుసుకోవాలంటే plan description ను నమ్మకుండా Linuxలో NVMe diskను నిర్ధారించండి.

LXC (Linux containers) లేదా OpenVZ వంటి container. మీకు స్వంత block device ఉండదు. lsblk host devices ను చూపిస్తుంది లేదా ఏదీ చూపించదు. Container వద్ద CAP_SYS_RAWIO లేకపోవడంతో smartctl అభ్యర్థన తిరస్కరించబడుతుంది:

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

ఇది పనిచేసే పరిస్థితి గురించి ఒక హెచ్చరిక. VPSలో smartctl పూర్తి attribute table ను చూపిస్తే, దాని ఆధారంగా చర్య తీసుకునే ముందు serial number ను చదవండి. కొన్ని hosts passthrough device node ను బయటపెడతాయి. అలాంటి counters ఆ machineలోని ప్రతి tenant పంచుకునే hardwareకు చెందినవి. అక్కడ పెరుగుతున్న Reallocated_Sector_Ct support ticket కు కారణం. అది మీ data గురించి చేసిన నిర్ధారణ కాదు.

కెర్నల్ log లో I/O errors: సంకేతం 1

ఇది tenant వద్ద ఉండే అత్యంత విలువైన సంకేతం. దీనికి agent అవసరం లేదు.

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 నుండి విఫలమైన request ఇలా కనిపిస్తుంది:

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

block layer host ను write కోసం అడిగింది. Host వైఫల్యాన్ని తిరిగి పంపింది. VPS లో ఇది చనిపోతున్న flash cell వల్ల కలగడం అరుదు. సాధారణంగా host storage layer లేదా network attached storage కు వెళ్లే network path కారణం అవుతుంది. అందువల్ల ఇది provider వైపు జరిగిన సంఘటన. మీ ticket లో timestamp, device name, sector నమోదు చేయండి. Storage team తమ logs లో వీటితో సరిపోల్చగలదు.

ముఖ్యమైన ext4 sequence లో ఈ జంట ఉంటుంది:

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

రెండవ line అత్యంత తీవ్రమైనది. ఎందుకంటే machine నడుస్తూనే ఉంటుంది. ఇది ping కు సమాధానం ఇస్తుంది, SSH కు సమాధానం ఇస్తుంది, కానీ ప్రతి write విఫలమవుతుంది. సాధారణ HTTP check విజయవంతమవుతూనే ఉంటుంది, అయితే మీ application ప్రతి request పై error చూపిస్తుంది.

XFS బదులుగా filesystem ను shutdown చేస్తుంది:

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

journal disk పై నిల్వ చేయబడకపోతే journalctl -k ప్రస్తుత boot ను మాత్రమే చదువుతుంది. అనేక images RAM లో ఉండే volatile journal తో విడుదలవుతాయి. Persistence ను enable చేయండి. లేకపోతే troubleshooting సమయంలో మీరు చేసే reboot వద్దే evidence అదృశ్యమవుతుంది.

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

తదుపరి reboot తర్వాత journalctl --list-boots ఒకటి కంటే ఎక్కువ boots ను చూపాలి. Persistence enable చేసినా, read-only గా మారిన filesystem తరువాత జరిగిన విషయాలను record చేయలేరు. అందుకే logs ను server వెలుపలికి పంపడం సరైనది.

చిహ్నం 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 లో సెట్ చేయండి. నిశ్శబ్ద corruption కంటే స్పష్టమైన stoppage మంచిది.

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 గురించి ఏమీ నిర్ధారించదు.

Write test ను space check తో కలిపి అమలు చేయండి. ప్రతి 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 మొత్తం chain విజయవంతంగా పనిచేస్తోందని సూచిస్తుంది. set -eu వల్ల ఏదైనా check విఫలమైతే curl పంక్తి అమలు కావడానికి ముందే non-zero తో exit అవుతుంది. అందువల్ల heartbeat పంపబడదు. ఈ inversion ఉద్దేశం ఇదే: ఏదీ చేరకపోవడంతో 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 ఐదు నిమిషాల కంటే తక్కువ సమయం దూరంలో ఉన్న NEXT సమయంతో unit ను చూపాలి. విఫలమైన run journalctl -u disk-probe.service లో shell యొక్క స్వంత error text తో కనిపిస్తుంది. అందువల్ల login చేయకుండానే filesystem read-only గా మారిందా లేదా full అయిందా తెలుసుకోవచ్చు.

ఆ push URL ఒక Uptime Kuma push monitor కు చెందినది. Push రకంతో monitor సృష్టించి, దాని token ను script లో copy చేయండి. ఒక slow run వల్ల 03:00 గంటలకు మీకు page రాకుండా, monitor heartbeat interval ను timer interval కంటే కొద్దిగా ఎక్కువగా సెట్ చేయండి. ఇంకా status page లేకపోతే, self-hosted Uptime Kuma instance ఈ check ఉంచడానికి తక్కువ ఖర్చుతో కూడిన స్థలం.

ఇక్కడ రెండు పరిమితులు ఉన్నాయి. Probe write అంగీకరించబడిందని మాత్రమే నిర్ధారిస్తుంది. Bytes durable storage కు చేరాయని నిర్ధారించదు, ఎందుకంటే read back ను page cache నుంచి అందించవచ్చు. అదనంగా, ఇది పర్యవేక్షిస్తున్న machine పైనే నడుస్తుంది. అందువల్ల పూర్తిగా స్పందించకుండా నిలిచిపోయిన server diagnosis పంపకుండా నిశ్శబ్దంగా ఉంటుంది.

లేటెన్సీ మరియు throughput ధోరణులు

sudo apt install -y sysstat
iostat -xdz 5 3

ముందుగా r_await మరియు w_await ను చూడండి. ఇవి read లేదా write పూర్తవడానికి పట్టిన సగటు milliseconds. Queueలో వేచి ఉన్న సమయం కూడా ఇందులో ఉంటుంది. తరువాత aqu-sz ను చూడండి. ఇది in-flight requests యొక్క సగటు సంఖ్య. Virtual disk పై %util ను పట్టించుకోండి: దీని అర్థం queue ఖాళీగా లేదని మాత్రమే. అనేక requests ను parallelగా నిర్వహించే device, తన పరిమితికి చాలా దూరంగా ఉన్నప్పటికీ, 100 percentకు సమీపంలో ఉండవచ్చు. వినియోగదారులకు అనిపించే పనితీరును కొలిచే సంఖ్య await.

మీ స్వంత baselineతో పోలిస్తే absolute valuesకు తక్కువ ప్రాధాన్యత ఉంటుంది. అందువల్ల ప్రశాంతంగా ఉన్న ఒక గంటలో విలువలను నమోదు చేసి, దాన్ని baselineగా ఉంచండి. Countersను మీరే సేకరించాలనుకుంటే /proc/diskstats అనేది raw source.

కొలతను ఉద్దేశపూర్వకంగా తీసుకోవడానికి:

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 blockను చదవండి. ముఖ్యంగా 99th percentileను పరిశీలించండి. --direct=1 మీ page cacheను దాటిస్తుంది. అయితే host cacheను దాటించదు. అందువల్ల మీ process నుంచి platform storage వరకు ఉన్న మొత్తం pathను ఈ ఫలితం వివరిస్తుంది. Server idleగా ఉన్నప్పుడు దీన్ని నడపండి, ఎందుకంటే ఇది మీ workloadతో resources కోసం పోటీపడుతుంది.

Kernel logలో errors లేకుండా await పెరుగుతుంటే, సాధారణంగా drive విఫలమవుతోందని అర్థం కాదు. ఇది hostపై contention. Storage సందర్భంలో ఇది పక్కనున్న అధిక లోడ్ tenant వల్ల ఏర్పడే CPU steal time కు సమానం. ప్రతిరోజూ అదే గంటలో ఈ సమస్య తిరిగి కనిపించి, మీ ticketకు ఎటువంటి సమస్య లేదనే సమాధానం వస్తే, I/Oను అదే విధంగా share చేయని planను ఎంచుకోవాలి. Workload disk boundగా ఉన్నప్పుడు సాధారణ VPSకు బదులుగా storage VPS ఇందుకు ఉదాహరణ.

మౌంట్‌లో ఉన్నప్పుడు అమలు చేయగల filesystem తనిఖీలు

ext4 తన superblock లో error counter ను నిల్వ చేస్తుంది. మీ logs అందుబాటులో లేకపోయినా, ఈ counter 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 మరియు zero కాని count ఉంటే, ఎవరూ గుర్తించకపోయినా, log తొలగిపోయినా, ఏదో సమయంలో kernel metadata error ను ఎదుర్కొందని అర్థం. ఆ ఒక్క command ను వారానికొకసారి చేసే తనిఖీలో చేర్చాలి.

మౌంట్‌లో ఉన్న root filesystem పై fsck అమలు చేయలేరు. Live filesystem పై e2fsck -n అమలు చేస్తే, తనిఖీ సమయంలో డేటా మారుతున్నందువల్ల కలిగే సమస్యలను మాత్రమే చూపిస్తుంది. నిజమైన తనిఖీని బలవంతంగా చేయడానికి, మీ provider console నుంచి ఒక boot కోసం kernel command line కు fsck.mode=force fsck.repair=yes ను జోడించండి. అప్పుడు root ను read-write గా మౌంట్ చేయడానికి ముందు systemd-fsck తనిఖీని అమలు చేస్తుంది.

XFS కు online check లేదు. xfs_repair -n /dev/vda1 మౌంట్‌లో ఉన్న filesystem పై అమలు కావడానికి నిరాకరిస్తుంది. అందువల్ల దీన్ని rescue mode లో అమలు చేయాలి. దీనికి బదులుగా XFS స్పష్టమైన ప్రవర్తనను చూపిస్తుంది: metadata error వచ్చినప్పుడు కొనసాగకుండా filesystem ను shutdown చేస్తుంది.

Btrfs లో counters అంతర్గతంగా ఉంటాయి. అవి persistent గా కూడా ఉంటాయి.

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

zero కంటే ఎక్కువగా ఉన్న write_io_errs లేదా corruption_errs నిజంగా జరిగిన సంఘటనను సూచిస్తుంది. మీరు వాటిని reset చేసే వరకు ఈ counters reboot ల తర్వాత కూడా తమ విలువలను అలాగే ఉంచుతాయి. scrub ప్రతి block ను మళ్లీ చదివి, దాని checksum ను నిర్ధారిస్తుంది. Virtual disk లో అందుబాటులో ఉన్న media test కు ఇది అత్యంత సమీపమైన విధానం. దీనికి ఎక్కువ I/O అవసరం. కాబట్టి దీన్ని తక్కువ వినియోగం ఉన్న సమయంలో schedule చేయండి.

సంకేతం 5: df చూపని భాగాలతో సహా ఖాళీ స్థలం

ఖాళీ స్థలం పూర్తిగా అయిపోతే, చెడ్డ డిస్క్ వల్ల కలిగే విధంగానే సర్వర్ పనిచేయడం ఆగిపోతుంది. ఇది డిస్క్ సమస్యకన్నా చాలా తరచుగా జరుగుతుంది.

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

No space left on device సమయంలో df -h ఖాళీ స్థలం ఉందని చూపిస్తే, bytes కాకుండా inodes అయిపోయాయని అర్థం. అలాగే df -i లో IUse% 100 శాతంగా చూపిస్తుంది. cache directory లేదా mail spool లో లక్షలాది చిన్న files ఉండటం దీనికి కారణం కావచ్చు. పెద్ద files తొలగించినా సమస్య పరిష్కారం కాదు.

File తొలగించిన తర్వాత కూడా స్థలం తిరిగి అందుబాటులోకి రాకపోతే, సాధారణంగా running process ఆ file ను ఇంకా open గా ఉంచుతుంది. sudo lsof +L1 లో link count సున్నాకు చేరిన files జాబితా కనిపిస్తుంది. ఆ file ను పట్టుకుని ఉన్న process ను restart చేస్తే స్థలం విడుదల అవుతుంది.

journal సాధారణంగా నిశ్శబ్దంగా స్థలాన్ని వినియోగించే అంశం. దాని వినియోగాన్ని journalctl --disk-usage చూపిస్తుంది. /etc/systemd/journald.conf లో SystemMaxUse=200M ను అమలు చేసిన తరువాత sudo systemctl restart systemd-journald తో పరిమితి విధించండి. ప్రస్తుతం స్థలాన్ని తిరిగి పొందడానికి sudo journalctl --vacuum-size=200M అమలు చేయండి.

ఒక సందర్భం bug లాగా కనిపిస్తుంది, కానీ అది bug కాదు. thin provisioned host storage పై, మీ df ఇంకా gigabytes ఖాళీగా ఉన్నట్లు చూపుతున్నప్పటికీ host యొక్క storage pool పూర్తిగా నిండిపోవచ్చు. అప్పుడు మీ writes విఫలమై, kernel log లో I/O errors కనిపిస్తాయి. guest లో ఎక్కడా space warning కనిపించకపోవచ్చు. పూర్తి filesystem లేకపోయినా errors కనిపిస్తే, అదే గంటలో ticket నమోదు చేయాల్సిన ముఖ్యమైన పరిస్థితి.

సంకేతాలను metrics agent కు అనుసంధానించడం

Push probe అవును లేదా కాదు అనే సమాధానం ఇస్తుంది. Trends కోసం metrics agent అవసరం. Prometheus node_exporter అదనపు configuration లేకుండానే పై అంశాలన్నింటినీ ఇప్పటికే export చేస్తుంది. ఆధారంగా ఉపయోగించాల్సిన metric names:

• node_filesystem_readonly mount read-only అయినప్పుడు 1 అవుతుంది. ఇదే remount alarm.
• 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 ను graph చేయగల counters గా అందిస్తాయి.

వాస్తవంగా page చేసే పరిస్థితులను రెండు rules గుర్తిస్తాయి:

- 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

ప్రస్తుత trend నాలుగు రోజుల్లో సున్నాకు చేరుకున్నప్పుడు రెండో rule trigger అవుతుంది. అందువల్ల filesystem 95 percent నిండినప్పుడు, మీకు ఇంకా కొన్ని నిమిషాలే మిగిలి ఉన్న సమయంలో కాకుండా, కొన్ని రోజుల ముందుగానే హెచ్చరిక అందుతుంది.

ఏ బాధ్యత ఎవరిది

మీ provider physical drives కు బాధ్యత వహిస్తారు. వారు SMART ను చదువుతారు, array ను నిర్వహిస్తారు, reallocated sectors పెరుగుతున్న drive ను భర్తీ చేస్తారు. సాధారణంగా దీనిని మీకు తెలియజేయరు, ఎందుకంటే array ఆ failure ను తట్టుకుంటుంది. మీ VPS కింద ఉన్న RAID 10 ఉపయోగం ఇదే: dead drive వల్ల outage కాకుండా rebuild జరుగుతుంది. వీటిలో ఏదీ మీకు కనిపించదు. Virtual server ను అద్దెకు తీసుకోవడంలో ఈ abstraction కోసం చెల్లించడం ప్రధాన కారణాల్లో ఒకటి.

మీ data కు మీరు బాధ్యత వహిస్తారు. Drive telemetry మీ data ను రక్షించదు. Tenant data ను వాస్తవంగా నాశనం చేసే సంఘటనలు తప్పుగా చేసిన rm, తప్పు deploy, మీ SSH key కలిగిన intruder, అలాగే array ను కూడా ప్రభావితం చేసే platform incident. SMART attributes వీటిలో ఏదీ ముందుగా గుర్తించలేవు.

అందువల్ల tenant కు వాస్తవ రక్షణ server వెలుపల ఉండే backup మరియు మీరు స్వయంగా నిర్వహించిన restore. Provider snapshots సౌకర్యవంతంగా ఉంటాయి. అయితే అవి రక్షించే వస్తువు ఉన్న అదే platform పై ఉంటాయి. అందుకే snapshots మరియు backups వేర్వేరు రక్షణలు. Calendar లో ఒక drill ను నమోదు చేయండి: ప్రతి quarter కు ఒకసారి తాజా backup ను కొత్త VPS లో restore చేసి, application ను ప్రారంభించి, దానికి పట్టిన సమయాన్ని రాసుకోండి. ఆ సంఖ్యే మీ వాస్తవ recovery time. మొదటి drill ఎల్లప్పుడూ ఎవరైనా ఊహించిన దానికంటే ఎక్కువ సమయం పడుతుంది.

మీకు SMART వర్తించే సందర్భాలు

smartctl గురించి వివరించే మార్గదర్శకాలు సరైనవే. హార్డ్‌వేర్ వాస్తవంగా మీ సొంతమైన వెంటనే అవి వర్తిస్తాయి:

• Dedicated లేదా bare metal server, ఇందులో sudo smartctl -a /dev/sda పూర్తి attribute table ను చూపుతుంది మరియు ఏదైనా attribute మారినప్పుడు smartd మీకు email పంపగలదు.
• Physical disk ను guest కు నేరుగా అందించే storage plans. Providers దీనిని స్పష్టంగా documentation లో పేర్కొంటారు, ఎందుకంటే ఇది వారి సేవలోని ముఖ్యమైన selling point.
• ఇంట్లో లేదా మీరు అద్దెకు తీసుకున్న rack space లో ఉన్న మీ సొంత హార్డ్‌వేర్.
• RAID controller వెనుక ఉన్న disk, దీనిని sudo smartctl -a -d megaraid,0 /dev/sda ద్వారా యాక్సెస్ చేయవచ్చు, లేదా -d sat ఉన్న USB enclosure.

నిజమైన NVMeలో, drive నుంచే sudo smartctl -a -d nvme /dev/nvme0 మరియు sudo nvme smart-log /dev/nvme0n1 వరుసగా critical_warning మరియు percentage_used ను report చేస్తాయి. నిజమైన SATAలో, drive failure ను ముందుగా సూచించే attributes Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198), మరియు Reported_Uncorrect (187). వీటిలో ఏదైనా zero నుంచి మారితే replacement కోసం ప్రణాళిక రూపొందించండి. Large-scale drive studies నిరంతరం ఇదే చిన్న జాబితాను నిర్ధారిస్తున్నాయి. ఇతర attributes లో చాలావరకు ఉపయోగకరమైన సమాచారం ఉండదు.

చేతితో తనిఖీ చేయడం బదులుగా daemon ను నడపండి.

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

మీరు ఇప్పుడే ప్రారంభించిన run కోసం self-test log లో Completed without error కనిపించాలి. Ubuntu మరియు Debian, August 2026 నాటికి ప్రస్తుతమైన DEVICESCAN line తో /etc/smartd.conf ను అందిస్తాయి. అందువల్ల daemon కనిపించే ప్రతి disk ను పర్యవేక్షించి, మార్పు వచ్చినప్పుడు root కు email పంపుతుంది. Virtual disk పై ఇవేవీ పనిచేయవు. అందుకే ఈ guide లో మిగిలిన భాగం అవసరం.

FAQ

smartctl నా VPSలో ఎందుకు పనిచేయడం లేదు?

డిస్క్ 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 గా కనిపించే deviceను మాత్రమే చేరుకోగలరు; దాని వెనుక ఉపయోగించగల SMART data ఉండదు. Containerలో CAP_SYS_RAWIO లేకపోవడం వల్ల smartctl నేరుగా తిరస్కరించబడుతుంది. ఇవేవీ misconfiguration కావు. -d flag ఉపయోగించినా వీటిని పరిష్కరించలేరు.

నా VPS disk విఫలమవుతోందని ఎలా తెలుసుకోవాలి?

Hardwareను కాకుండా దాని ప్రభావాలను గమనించండి. sudo journalctl -k -p err -b లోని blk_update_request: I/O error lines మరియు Remounting filesystem read-only కోసం పరిశీలించండి. Logsలో ఇప్పటికే కనిపించకుండా పోయిన errorsను కనుగొనడానికి sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' అమలు చేయండి. వ్యవస్థ సరిగ్గా పనిచేసినప్పుడు నమోదు చేసిన baselineతో iostat -xdz 5 నుంచి వచ్చే r_await ను పోల్చుతూ పర్యవేక్షించండి. VPSలో I/O error సాధారణంగా drive పాడవడం కంటే host storage సమస్యను సూచిస్తుంది. అందువల్ల timestamp మరియు sector వివరాలతో support ticket నమోదు చేయాలి.

VPS disk health కోసం దేనిపై alert ఇవ్వాలి?

నాలుగు alerts సరిపోతాయి. node_filesystem_readonly == 1 వల్ల లేదా విఫలమైన write probe వల్ల ఏర్పడిన read-only mount. సున్నా వైపు తగ్గుతున్న free space మరియు free inodes. చివరి intervalలో వచ్చిన ఏదైనా kernel I/O error. Server నుంచి heartbeat, తద్వారా server స్పందించడం ఆపితే silence ఆధారంగా page అందుతుంది. SMART నుంచి ఉత్పన్నమయ్యే దేనినీ ఉపయోగించవద్దు, ఎందుకంటే virtual diskలో ఆ values లేకపోవచ్చు లేదా hypervisor emulationను మాత్రమే వివరించవచ్చు.

నా filesystem read-onlyగా ఎందుకు remount అయింది?

errors=remount-ro తో mount చేసిన ext4 metadata errorను ఎదుర్కొన్నప్పుడు ఉద్దేశపూర్వకంగా ఇలా చేస్తుంది. Damageపై మరింతగా రాయడం కొనసాగించకుండా writingను ఆపుతుంది. Remount lineకు కొద్దిగా ముందు kernel logలో trigger ఉంటుంది. సాధారణంగా underlying device I/O errorను తిరిగి ఇచ్చిన తర్వాత journal ఆగిపోయిందని తెలిపే EXT4-fs error కనిపిస్తుంది. Filesystemను తనిఖీ చేయకుండా read-writeగా remount చేస్తే symptom దాగిపోతుంది, కానీ cause అలాగే ఉంటుంది. ముందుగా logను capture చేయండి. తరువాత rescue mode నుంచి filesystem unmountedగా ఉన్నప్పుడు e2fsck -fy /dev/vda1 తో తనిఖీ చేయండి.

Virtual serverలో SMART dataను ఎప్పుడైనా చదవగలనా?

కొన్ని నిర్దిష్ట సందర్భాల్లో అవును. Dedicated మరియు bare metal servers మీకు నిజమైన attributesను అందిస్తాయి. Physical diskను guestకు pass through చేసే storage plans కూడా అలాగే పనిచేస్తాయి. మీరు స్వయంగా నిర్వహించే hostలలోనూ ఇది సాధ్యమే. కొన్ని platforms guestకు NVMe controllerను అందిస్తాయి, అప్పుడు nvme smart-log ఒక logను తిరిగి ఇవ్వవచ్చు. అందువల్ల ముందుగా sudo nvme id-ctrl /dev/nvme0 అమలు చేయండి. Network storage service పేరును చూపించే model number ఉంటే, ఆ counters software controller నుంచి వస్తున్నాయి. Passthrough node shared machineలో నిజమైన countersను అందించినా, అవి ఇతర tenantsతో పంచుకున్న hardwareను వివరిస్తాయి. అందువల్ల ఉపయోగకరమైన ఏకైక చర్య support ticket నమోదు చేయడం.