VPS-এ disk health কীভাবে monitor করবেন

VPS-এ disk health monitoring বাস্তবে কী দেখতে পারে

VPS-এ disk health monitoring শুরু হয় এমন একটি সত্য দিয়ে, যা অধিকাংশ গাইড এড়িয়ে যায়: disk-টি আপনার নয়। আপনার guest একটি virtual block device দেখতে পায়। physical drive এবং তাতে সংরক্ষিত প্রতিটি counter host-এর মালিকানাধীন। smartctl /dev/vda ব্যর্থ হয় না কারণ আপনি command ভুল লিখেছেন। এটি ব্যর্থ হয় কারণ device-এর পেছনে থাকা কোনো উপাদান প্রশ্নটির উত্তর দিতে পারে না।

SMART (self-monitoring, analysis and reporting technology) হলো drive-এর ভেতরেই সংরক্ষিত counter-এর একটি table: reallocated sectors, pending sectors, power-on hours এবং media errors। এই table পড়তে ATA বা NVMe (non-volatile memory express) command বাস্তব hardware-এ পৌঁছানোর একটি পথ প্রয়োজন। paravirtual disk এমন কোনো পথ সরবরাহ করে না। তাই guest telemetry বাদ দেওয়া storage পায়।

একজন tenant hardware নয়, তার প্রভাব monitor করতে পারে। guest-এর ভেতর থেকে চারটি signal দেখা যায়: kernel log-এ I/O (input/output) error, read-only অবস্থায় remount হওয়া filesystem, ক্রমশ বেড়ে যাওয়া latency এবং শেষ হয়ে আসা space। চারটির জন্যই এখন alert সেট করা যায়। কোনো user অভিযোগ করার আগেই চারটিই দেখা দিতে পারে। প্রথমে এগুলো সেট up করুন। দায়িত্বের বিভাজন শেষে ব্যাখ্যা করা হবে, কারণ এর ওপর নির্ভর করে কোথায় আপনার effort দেওয়া উচিত।

আপনার নিজস্ব সার্ভার কী প্রকাশ করছে তা প্রমাণ করুন

আপনি কোন পরিস্থিতিতে আছেন তা ধরে নেবেন না। আগে পরীক্ষা করুন, তারপর যে অংশটি আপনার পরিস্থিতির সঙ্গে মেলে সেটি পড়ুন।

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 request বহন করার কোনো channel নেই। -d sat এবং -d scsi একইভাবে ব্যর্থ হয়, কারণ সমস্যা transport-এ, flag-এ নয়।

Emulated SATA বা SCSI ডিস্ক। ডিভাইসটি হলো /dev/sda এবং smartctl ডিভাইসটি শনাক্ত করার মতো দূর পর্যন্ত এগোয়। Model line-এ লেখা থাকে QEMU HARDDISK। এই string-ই প্রশ্নের উত্তর দেয়: আপনি এমন একটি ডিভাইস পড়ছেন, যা emulator তৈরি করেছে, এবং সেটি কোনো ব্যবহারযোগ্য SMART capability প্রকাশ করে না।

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-based। তাই percentage_used এবং media_errors আপনার data থাকা flash-এর পরিবর্তে সেই emulation-এর বর্ণনা দেয়। আপনার storage প্রকৃতপক্ষে কী, তা জানতে plan description-এর ওপর নির্ভর না করে Linux-এ NVMe disk যাচাই করুন।

একটি container, যেমন LXC (Linux containers) বা OpenVZ। আপনার নিজস্ব কোনো block device নেই। lsblk host-এর device দেখায়, অথবা কিছুই দেখায় না। container-এর কাছে CAP_SYS_RAWIO না থাকায় smartctl-এর অনুরোধ প্রত্যাখ্যাত হয়:

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

এটি কাজ করলে যে পরিস্থিতি তৈরি হয়, সে বিষয়ে একটি সতর্কতা আছে। VPS-এ smartctl একটি পূর্ণ attribute table ফেরত দিলে কোনো পদক্ষেপ নেওয়ার আগে serial number পড়ুন। কিছু host passthrough device node প্রকাশ করে, এবং ওই counter-গুলো সেই মেশিনের সব tenant-এর ব্যবহৃত hardware-এর। সেখানে Reallocated_Sector_Ct বাড়লে support ticket খুলতে হবে। এটি আপনার data সম্পর্কে কোনো বক্তব্য নয়।

Kernel log-এ I/O error

এটি tenant-এর জন্য সবচেয়ে গুরুত্বপূর্ণ signal, এবং এর জন্য কোনো 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 operation চেয়েছিল, কিন্তু host failure ফেরত দিয়েছে। VPS-এ এর কারণ সাধারণত নষ্ট flash cell নয়। বেশিরভাগ ক্ষেত্রে কারণ হয় host-এর storage layer অথবা network attached storage-এ যাওয়ার network path। তাই এটি provider-side event। আপনার ticket-এ timestamp, device name এবং sector লিখুন। Storage team তাদের নিজস্ব log-এর সঙ্গে এই তথ্য মিলিয়ে দেখতে পারবে।

সবচেয়ে গুরুত্বপূর্ণ 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 বন্ধ করে দেয়।

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-এর log পড়ে। অনেক image-এ volatile journal থাকে, যা RAM-এ সংরক্ষিত হয়। Persistence চালু করুন। তা না হলে troubleshooting-এর সময় যে reboot করবেন, ঠিক সেই reboot-এই প্রমাণ হারিয়ে যাবে।

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-এ একটির বেশি boot দেখানোর কথা। Persistence চালু থাকলেও read-only হয়ে যাওয়া filesystem পরের ঘটনাগুলো record করতে পারে না। তাই log server-এর বাইরে পাঠানোই সঠিক ব্যবস্থা।

শুধু-পাঠযোগ্যভাবে remount হওয়া শনাক্ত করা

শনাক্ত করার চেষ্টা করার আগে ব্যর্থতাটি স্পষ্টভাবে প্রকাশ করুন।

findmnt -no SOURCE,FSTYPE,OPTIONS /

options-এ errors=remount-ro আছে কি না দেখুন। Ubuntu এবং Debian cloud image-গুলো এটি /etc/fstab-এ সেট করে। তাই metadata error হলে ক্ষতিগ্রস্ত অবস্থায় কাজ চালিয়ে যাওয়ার বদলে filesystem শুধু-পাঠযোগ্য হয়ে যায়। এটি না থাকলে /etc/fstab-এর root entry-তে যোগ করুন, অথবা sudo tune2fs -e remount-ro /dev/vda1 দিয়ে superblock-এ সেট করুন। নীরবে corruption চলতে দেওয়ার চেয়ে স্পষ্টভাবে থামা ভালো।

Mount flag থাকা প্রমাণ নয়। লিখে পরীক্ষা করুন:

touch /var/tmp/.disk-probe

শুধু-পাঠযোগ্য root-এ এটি ঠিক এই output দেখায়:

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

/tmp নয়, /var/tmp ব্যবহার করুন। অধিকাংশ image-এ /tmp হলো memory-তে থাকা tmpfs। তাই সেখানে সফলভাবে লিখতে পারা আপনার disk সম্পর্কে কিছুই প্রমাণ করে না।

লেখার পরীক্ষা এবং অবশিষ্ট স্থান পরীক্ষা একসঙ্গে চালান। সব পরীক্ষা সফল হলেই 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 কোনো পরীক্ষা ব্যর্থ হলে curl line চালানোর আগেই non-zero status-এ exit করায়। ফলে heartbeat পাঠানো হয় না। এটাই এই উল্টো যুক্তির উদ্দেশ্য: কিছু না পৌঁছালে monitor red দেখায়। যে server লিখতে পারে না, নিজের সমস্যার বিবরণ দেওয়ার ক্ষেত্রে তাকে বিশ্বাস করা যায় না। শুধু-পাঠযোগ্য filesystem-এ read এখনও কাজ করে। তাই 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 time-সহ unit-টি দেখা উচিত। কোনো run ব্যর্থ হলে journalctl -u disk-probe.service-এ shell-এর নিজস্ব error text দেখা যাবে। ফলে login না করেই শুধু-পাঠযোগ্য filesystem এবং সম্পূর্ণ disk-এর মধ্যে পার্থক্য বোঝা যায়।

ওই push URL হলো Uptime Kuma push monitor-এর URL। Push type-এর একটি monitor তৈরি করুন, token-টি script-এ কপি করুন, এবং monitor-এর heartbeat interval timer interval-এর চেয়ে সামান্য বেশি রাখুন, যাতে একটি ধীর run-এর জন্য 03:00-এ page না যায়। আপনার status page না থাকলে self-hosted Uptime Kuma instance-এ এই check রাখাই সবচেয়ে কম খরচের উপায়।

দুটি সীমাবদ্ধতা মনে রাখুন। এই probe নিশ্চিত করে যে write গ্রহণ করা হয়েছে। কিন্তু bytes durable storage-এ পৌঁছেছে কি না তা নিশ্চিত করে না, কারণ read-back page cache থেকে আসতে পারে। এটি যে machine-কে monitor করে, সেই machine-এই চলে। তাই সম্পূর্ণভাবে অচল server diagnosis পাঠানোর বদলে নীরব হয়ে যায়।

লেটেন্সি এবং থ্রুপুটের প্রবণতা

sudo apt install -y sysstat
iostat -xdz 5 3

প্রথমে r_await এবং w_await দেখুন। এগুলো হলো একটি read বা write সম্পন্ন হতে লাগা গড় মিলিসেকেন্ড, যার মধ্যে queue-তে অপেক্ষার সময়ও অন্তর্ভুক্ত। এরপর aqu-sz দেখুন, এটি flight অবস্থায় থাকা অনুরোধের গড় সংখ্যা। virtual disk-এ %util উপেক্ষা করুন: এটি শুধু বোঝায় যে queue খালি ছিল না। অনেক অনুরোধ parallelভাবে সেবা দিতে পারে এমন device তার সীমার কাছাকাছি না গিয়েও 100 percent-এর কাছাকাছি থাকতে পারে। ব্যবহারকারীরা যা অনুভব করেন, তা অনুসরণ করার জন্য await-ই গুরুত্বপূর্ণ সংখ্যা।

আপনার নিজস্ব baseline-এর তুলনায় absolute value কম গুরুত্বপূর্ণ। তাই একটি শান্ত সময়ের মাপ record করে সংরক্ষণ করুন। আপনি নিজে counter সংগ্রহ করতে চাইলে /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 পর্যন্ত পুরো পথের চিত্র দেয়। server idle থাকা অবস্থায় এটি চালান, কারণ এটি আপনার নিজের workload-এর সঙ্গে প্রতিযোগিতা করে।

kernel log-এ কোনো error না থাকলেও await বেড়ে গেলে সাধারণত drive নষ্ট হচ্ছে না। এটি host-এ contention। storage-এর ক্ষেত্রে এটি noisy neighbour-এর CPU steal time-এর সমতুল্য। প্রতিদিন একই সময়ে এটি ফিরে আসে এবং আপনার ticket-এর ফলাফল স্বাভাবিক থাকে, তাহলে এমন একটি plan নেওয়াই সমাধান যার I/O একইভাবে shared নয়। disk-bound workload-এর ক্ষেত্রে regular VPS-এর পরিবর্তে storage VPS-এ এটাই ঘটে।

মাউন্ট করা অবস্থায় চালানো যায় এমন filesystem check

ext4 superblock-এ একটি error counter সংরক্ষণ করে। লগ না থাকলেও এই 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 এবং শূন্যের বেশি count-এর অর্থ হলো কোনো সময় kernel metadata error শনাক্ত করেছে, যদিও কেউ তা লক্ষ্য না করে থাকতে পারেন এবং log ইতিমধ্যে rotate হয়ে যেতে পারে। সাপ্তাহিক check-এর অংশ হিসেবে এই command চালান।

মাউন্ট করা root filesystem-এ fsck চালানো যায় না। এছাড়া, live filesystem-এ e2fsck -n চালালে এমন সমস্যা রিপোর্ট হতে পারে, যেগুলো মূলত data পরিবর্তনের কারণে তৈরি হয়েছে। প্রকৃত check চালাতে provider-এর console থেকে একটি boot-এর জন্য kernel command line-এ fsck.mode=force fsck.repair=yes যোগ করুন। এরপর root read-write হিসেবে মাউন্ট হওয়ার আগে systemd-fsck check চালাবে।

XFS-এর জন্য online check নেই। xfs_repair -n /dev/vda1 মাউন্ট করা filesystem-এর বিরুদ্ধে চলতে অস্বীকার করে। তাই এটি rescue mode-এ চালাতে হয়। এর পরিবর্তে XFS metadata error হলে filesystem বন্ধ করে দেয়। সমস্যা থাকা সত্ত্বেও কাজ চালিয়ে যায় না।

Btrfs-এ counter অন্তর্নির্মিত এবং persistent।

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

write_io_errs অথবা corruption_errs শূন্যের বেশি হলে সেটি একটি প্রকৃত ঘটনা। reset না করা পর্যন্ত reboot-এর পরও counter-এর মান সংরক্ষিত থাকে। scrub প্রতিটি block পুনরায় পড়ে এবং তার checksum যাচাই করে। virtual disk-এ media test-এর সবচেয়ে কাছাকাছি এটিই। এতে I/O load বেশি হয়, তাই কম ব্যস্ত সময়ের জন্য এটি schedule করুন।

Signal 5: free space, including the parts df hides

ডিস্কে জায়গা শেষ হয়ে গেলে খারাপ ডিস্কের মতোই সার্ভার অচল হয়ে পড়ে। এটি খারাপ ডিস্কের সমস্যার তুলনায় অনেক বেশি ঘটে।

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

No space left on device-এ IUse% 100 শতাংশ হলেও df -h-এ ফাঁকা জায়গা দেখা গেলে বুঝতে হবে byte নয়, inode শেষ হয়ে গেছে। df -i 100 শতাংশে পৌঁছালে IUse% এই অবস্থা দেখায়। Cache directory বা mail spool-এ লক্ষ লক্ষ ছোট file থাকলে এমন হয়। বড় file মুছে ফেললেও এতে সমাধান হয় না।

কোনো file মুছে ফেলার পরও space ফিরে না এলে সাধারণত সেটি কোনো চলমান process-এর কাছে open অবস্থায় থাকে। sudo lsof +L1 এমন file-এর তালিকা দেখায়, যেগুলোর link count শূন্যে নেমেছে। যে process file-টি ধরে রেখেছে সেটি restart করলে space মুক্ত হয়।

Journal প্রায়ই নীরবে disk space ব্যবহার করে। journalctl --disk-usage এটি কতটা space ধরে রেখেছে তা দেখায়। /etc/systemd/journald.conf-এ SystemMaxUse=200M ব্যবহার করে সীমা নির্ধারণ করুন, তারপর sudo systemctl restart systemd-journald চালিয়ে এখনই space পুনরুদ্ধার করুন। sudo journalctl --vacuum-size=200M

একটি পরিস্থিতি bug-এর মতো দেখায়, কিন্তু আসলে তা নয়। Thin-provisioned host storage-এ আপনার df-এ এখনও gigabytes পরিমাণ free space দেখা গেলেও host-এর pool পূর্ণ হয়ে যেতে পারে। এরপর আপনার write operation ব্যর্থ হয় এবং kernel log-এ I/O error দেখা যায়, কিন্তু guest-এর ভেতরে কোথাও space শেষ হওয়ার warning থাকে না। Filesystem পূর্ণ না থাকা অবস্থায় error দেখা দিলে একই ঘণ্টায় ticket খোলা উচিত।

signals-গুলো metrics agent-এ সংযুক্ত করা

একটি push probe শুধু yes অথবা no ফল দেয়। Trend পর্যবেক্ষণের জন্য metrics agent দরকার, এবং Prometheus node_exporter অতিরিক্ত configuration ছাড়াই উপরের সব তথ্য export করে। যে metric name-গুলোর ওপর ভিত্তি করে কাজ করবেন:

• 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 counter হিসেবে দেয়, যেগুলো graph-এ দেখাতে পারেন।

যে ঘটনাগুলোতে বাস্তবে page পাঠানো দরকার, সেগুলো ধরতে দুটি rule যথেষ্ট:

- 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

দ্বিতীয় rule-টি তখন fire করে, যখন বর্তমান trend চার দিনের মধ্যে শূন্যে পৌঁছানোর পূর্বাভাস দেয়। ফলে filesystem 95 percent পূর্ণ হওয়ার সময়, যখন হাতে মাত্র কয়েক মিনিট থাকে, তার বদলে কয়েক দিন আগেই সতর্কতা পাবেন।

কোন কাজের দায়িত্ব কার

আপনার provider physical drive-এর মালিক। তারা SMART পড়ে, array পরিচালনা করে এবং reallocated sector বাড়তে থাকা drive প্রতিস্থাপন করে। সাধারণত তারা আপনাকে জানায় না, কারণ array failure সামলে নেয়। এটাই আপনার VPS-এর অধীনে RAID 10 ব্যবহারের উদ্দেশ্য: drive নষ্ট হলে outage-এর পরিবর্তে rebuild হয়। এর কোনো কিছুই আপনি দেখতে পান না। একটি virtual server ভাড়া নেওয়ার খরচের বড় অংশই এই abstraction-এর জন্য।

আপনার data-এর দায়িত্ব আপনার। Drive telemetry আপনার data সুরক্ষিত করত না। Tenant data ধ্বংসের প্রকৃত কারণ হলো ভুল rm, ত্রুটিপূর্ণ deploy, আপনার SSH key ব্যবহারকারী intruder এবং এমন platform incident যা array-সহ সবকিছু অচল করে দেয়। SMART attribute এসবের কোনোটি পূর্বাভাস দিতে পারে না।

তাই tenant-এর প্রকৃত সুরক্ষা হলো server-এর বাইরে থাকা একটি backup এবং আপনার নিজে সম্পন্ন করা একটি restore। Provider snapshot সুবিধাজনক। তবে এটি যে জিনিসটিকে সুরক্ষিত করে, সেই একই platform-এ থাকে। এ কারণেই snapshot এবং backup আলাদা সুরক্ষা ব্যবস্থা। 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 আপনাকে ইমেইল করতে পারে।
• এমন storage plan, যেখানে guest-এর কাছে একটি physical disk সরাসরি pass-through করা হয়। Provider-রা এটি স্পষ্টভাবে উল্লেখ করে, কারণ এটি তাদের একটি বিক্রয়যোগ্য সুবিধা।
• আপনার মালিকানাধীন hardware, সেটি বাড়িতে থাকুক বা আপনার ভাড়া করা rack space-এ থাকুক।
• একটি RAID controller-এর পেছনে থাকা disk, যা sudo smartctl -a -d megaraid,0 /dev/sda দিয়ে access করা যায়, অথবা -d sat-যুক্ত একটি USB enclosure।

প্রকৃত NVMe-তে sudo smartctl -a -d nvme /dev/nvme0 এবং sudo nvme smart-log /dev/nvme0n1 drive থেকেই critical_warning ও percentage_used report করে। প্রকৃত SATA-তে failure পূর্বাভাস দেয় এমন attribute হলো Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) এবং Reported_Uncorrect (187)। এগুলোর যেকোনো একটি zero থেকে পরিবর্তিত হলে replacement-এর পরিকল্পনা করুন। বড় পরিসরের drive study-গুলো বারবার একই সংক্ষিপ্ত তালিকায় পৌঁছেছে, এবং অধিকাংশ অন্যান্য attribute কেবল noise।

হাতে পরীক্ষা না করে 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-কে ইমেইল করে। Virtual disk-এ এর কোনোটিই কাজ করে না। এই কারণেই এই গাইডের বাকি অংশ প্রয়োজন।

FAQ

smartctl আমার VPS-এ কাজ করে না কেন?

কারণ disk-টি virtual। virtio-blk ব্যবহার করা KVM guest-এ smartctl -a /dev/vda চালালে /dev/vda: Unable to detect device type দেখায়, কারণ paravirtual disk-এ SMART request পাঠানোর মতো ATA বা SCSI command channel থাকে না। Emulated disk-এ এমন একটি device-এ পৌঁছানো যায়, যার model হিসেবে QEMU HARDDISK দেখা যায়, কিন্তু এর পেছনে ব্যবহারযোগ্য 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 line এবং Remounting filesystem read-only আছে কি না পরীক্ষা করুন। লগ থেকে ইতিমধ্যে হারিয়ে যাওয়া error খুঁজতে sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' চালান। স্বাস্থ্যকর অবস্থায় record করা baseline-এর সঙ্গে iostat -xdz 5 থেকে r_await মিলিয়ে দেখুন। VPS-এ I/O error সাধারণত drive নষ্ট হওয়ার বদলে host storage-এর সমস্যা বোঝায়। তাই timestamp ও sector সংযুক্ত করে support ticket জমা দিন।

VPS disk-এর health-এর জন্য কোন alert সেট করা উচিত?

চারটি alert যথেষ্ট। Read-only mount হলে alert দিন, তা node_filesystem_readonly == 1 থেকে হোক বা ব্যর্থ write probe থেকে। Free space এবং free inode শূন্যের দিকে যাচ্ছে কি না দেখুন। শেষ interval-এ কোনো kernel I/O error হয়েছে কি না পরীক্ষা করুন। Server-এর heartbeat রাখুন, যাতে server উত্তর দেওয়া বন্ধ করলে silence আপনাকে alert করে। SMART থেকে তৈরি কোনো metric ব্যবহার করবেন না, কারণ virtual disk-এ এই value হয় অনুপস্থিত, নয়তো hypervisor-এর emulation সম্পর্কে তথ্য দেয়।

আমার filesystem read-only হিসেবে remount হলো কেন?

errors=remount-ro দিয়ে mount করা ext4 metadata error পেলে ইচ্ছাকৃতভাবে এমন করে। Damage-এর ওপর লেখা চালিয়ে যাওয়ার বদলে এটি writing বন্ধ করে। Remount line-এর ঠিক আগের kernel log-এ সাধারণত কারণটি থাকে। Underlying device I/O error ফেরত দেওয়ার পর aborted journal সম্পর্কে একটি EXT4-fs error message দেখা যায়। Filesystem পরীক্ষা না করে read-write হিসেবে remount করলে symptom আড়ালে থাকে এবং মূল কারণ থেকেই যায়। Log সংরক্ষণ করুন। এরপর rescue mode থেকে filesystem unmounted অবস্থায় e2fsck -fy /dev/vda1 দিয়ে পরীক্ষা করুন।

Virtual server-এ কি কখনও SMART data পড়া যায়?

নির্দিষ্ট ক্ষেত্রে যায়। Dedicated এবং bare metal server-এ প্রকৃত attribute পাওয়া যায়। Guest-এর কাছে physical disk pass through করা storage plan-এও তা পাওয়া যায়। আপনি নিজে মালিক এমন host-এও পাওয়া যায়। কিছু platform guest-এর কাছে NVMe controller উপস্থাপন করে এবং nvme smart-log একটি log ফেরত দেয়। তাই আগে sudo nvme id-ctrl /dev/nvme0 চালান। Network storage service-এর নাম উল্লেখ করা model number থাকলে বুঝতে হবে, এই counter-গুলো software controller থেকে এসেছে। আর passthrough node কোনো shared machine-এ প্রকৃত counter প্রকাশ করলেও, সেগুলো অন্য tenant-এর সঙ্গে ভাগ করা hardware-এর তথ্য। তাই কার্যকর পদক্ষেপ একমাত্র support ticket জমা দেওয়া।