วิธีตรวจสอบสุขภาพดิสก์บน VPS เมื่อ SMART ใช้งานไม่ได้

สิ่งที่การตรวจสอบสุขภาพดิสก์บน VPS สามารถมองเห็นได้จริง

การตรวจสอบสุขภาพดิสก์บน VPS เริ่มต้นจากข้อเท็จจริงที่คู่มือส่วนใหญ่หลีกเลี่ยง นั่นคือดิสก์ไม่ใช่ของคุณ ระบบ guest ของคุณมองเห็นเพียง virtual block device เท่านั้น ส่วนไดรฟ์จริงและตัวนับทุกค่าที่จัดเก็บอยู่บนนั้นเป็นของโฮสต์ smartctl /dev/vda ไม่ได้ล้มเหลวเพราะคุณพิมพ์คำสั่งผิด แต่ล้มเหลวเพราะไม่มีสิ่งใดหลังอุปกรณ์นั้นสามารถตอบคำถามได้

SMART (self-monitoring, analysis and reporting technology) คือตารางตัวนับที่เก็บไว้บนตัวไดรฟ์เอง เช่น reallocated sectors, pending sectors, power-on hours และ media errors การอ่านตารางดังกล่าวต้องอาศัยเส้นทางสำหรับคำสั่ง ATA หรือ NVMe (non-volatile memory express) เพื่อเข้าถึงฮาร์ดแวร์จริง ดิสก์แบบ paravirtual ไม่ได้จัดเตรียมเส้นทางนี้ไว้ ดังนั้น guest จึงได้รับพื้นที่จัดเก็บข้อมูลที่ถูกตัดข้อมูล telemetry ออกไป

ผู้เช่าจะตรวจสอบผลกระทบ ไม่ใช่ฮาร์ดแวร์ มีสัญญาณ 4 ประการที่มองเห็นได้จากภายใน guest ได้แก่ ข้อผิดพลาด I/O (input/output) ใน kernel log, ระบบไฟล์ที่ remount เป็นแบบ read-only, ค่า latency ที่ค่อยๆ สูงขึ้น และพื้นที่จัดเก็บข้อมูลที่เต็ม ทั้ง 4 สัญญาณนี้สามารถตั้งค่าการแจ้งเตือนได้ในปัจจุบัน และทั้งหมดจะปรากฏขึ้นก่อนที่ผู้ใช้จะร้องเรียน ให้ตั้งค่าสิ่งเหล่านี้ก่อน ส่วนการแบ่งความรับผิดชอบนั้นเป็นเรื่องท้ายสุด เพราะมันจะเปลี่ยนจุดที่คุณควรทุ่มเทความพยายามลงไป

ตรวจสอบสิ่งที่เซิร์ฟเวอร์ของคุณเปิดเผยออกมา

อย่าเพิ่งด่วนสรุปว่าคุณอยู่ในกรณีใด ให้ตรวจสอบก่อนแล้วจึงอ่านส่วนที่ตรงกับสถานการณ์ของคุณ

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 ที่ไม่มีชุดคำสั่ง ATA หรือ SCSI รองรับ จึงไม่มีช่องทางสำหรับส่งคำขอ SMART ได้ -d sat และ -d scsi จะล้มเหลวในลักษณะเดียวกัน เนื่องจากปัญหาอยู่ที่ตัวการขนส่ง ไม่ใช่ที่ flag

ดิสก์แบบจำลอง SATA หรือ SCSI อุปกรณ์คือ /dev/sda และ smartctl สามารถทำงานได้ไกลพอที่จะระบุตัวตนอุปกรณ์ได้ บรรทัดรุ่น (model line) จะแสดงเป็น QEMU HARDDISK ข้อความนั้นตอบคำถามได้ด้วยตัวเองว่า คุณกำลังอ่านอุปกรณ์ที่ตัวจำลอง (emulator) สร้างขึ้นมา และมันไม่ได้รายงานความสามารถ SMART ที่ใช้งานได้จริง

NVMe namespace sudo nvme smart-log /dev/nvme0n1 จะส่งคืน log ฉบับเต็ม ซึ่งเป็นจุดที่ทำให้หลายคนเข้าใจผิด ให้ตรวจสอบตัวตนของคอนโทรลเลอร์ก่อนด้วย sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)' หากหมายเลขรุ่นระบุชื่อผลิตภัณฑ์จัดเก็บข้อมูลบนเครือข่าย แสดงว่าคอนโทรลเลอร์นั้นเป็นซอฟต์แวร์ ดังนั้น percentage_used และ media_errors จึงเป็นการอธิบายถึงการจำลองนั้น ไม่ใช่หน่วยความจำแฟลชที่เก็บข้อมูลของคุณ หากคุณต้องการทราบว่าที่เก็บข้อมูลของคุณคืออะไรกันแน่ ให้ ตรวจสอบดิสก์ NVMe บน Linux แทนการเชื่อตามรายละเอียดในแผนผัง

คอนเทนเนอร์ เช่น LXC (Linux containers) หรือ OpenVZ คุณไม่มีอุปกรณ์บล็อก (block device) เป็นของตัวเอง lsblk จะแสดงอุปกรณ์ของโฮสต์หรือแสดงผลเป็นค่าว่าง และ smartctl จะถูกปฏิเสธเนื่องจากคอนเทนเนอร์ไม่มีสิทธิ์เข้าถึง CAP_SYS_RAWIO:

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

คำเตือนประการหนึ่งสำหรับกรณีที่โปรแกรมทำงานได้ หาก smartctl บน VPS ส่งคืนตารางคุณลักษณะ (attribute table) ออกมาเต็มรูปแบบ ให้ตรวจสอบหมายเลขซีเรียลก่อนที่คุณจะดำเนินการใดๆ โฮสต์บางแห่งเปิดเผยโหนดอุปกรณ์แบบ passthrough และตัวนับเหล่านั้นเป็นของฮาร์ดแวร์ที่ผู้เช่าทุกคนบนเครื่องนั้นใช้งานร่วมกัน หากค่า Reallocated_Sector_Ct เพิ่มสูงขึ้น นั่นหมายถึงคุณต้องเปิด support ticket มันไม่ใช่ข้อมูลที่บ่งชี้สถานะของข้อมูลของคุณโดยตรง

สัญญาณที่ 1: ข้อผิดพลาด I/O ใน kernel log

นี่เป็นสัญญาณที่มีคุณค่าสูงสุดที่ผู้เช่ามี และไม่จำเป็นต้องใช้ 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 จะมีลักษณะดังนี้:

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

block layer ได้ร้องขอการเขียนข้อมูลไปยัง host แต่ host ส่งค่าความผิดพลาดกลับมา ในกรณีของ VPS นี่แทบจะไม่ใช่ปัญหาจาก flash cell ที่เสื่อมสภาพ แต่มักเป็นปัญหาที่ storage layer ของ host หรือเส้นทางเครือข่ายที่เชื่อมต่อไปยัง network attached storage ซึ่งถือเป็นเหตุการณ์ที่เกิดขึ้นจากฝั่งผู้ให้บริการ ให้คัดลอก timestamp, ชื่ออุปกรณ์ และ sector ลงใน ticket ของคุณ เนื่องจากข้อมูลเหล่านี้คือสิ่งที่ทีมจัดเก็บข้อมูลสามารถนำไปตรวจสอบกับ log ของพวกเขาได้

ลำดับของ 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 จะอ่านเฉพาะการบูตปัจจุบันเท่านั้น เว้นแต่ว่า journal จะถูกจัดเก็บไว้บนดิสก์ ซึ่ง image จำนวนมากมักตั้งค่าให้ journal เป็นแบบ volatile ที่อยู่ใน RAM ให้เปิดใช้งานการบันทึกแบบถาวร (persistence) มิฉะนั้นหลักฐานจะหายไปทันทีที่คุณทำการ 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 ควรจะแสดงรายการการบูตมากกว่าหนึ่งรายการ แม้ว่าจะเปิดใช้งาน persistence แล้ว แต่ filesystem ที่เปลี่ยนสถานะเป็น read-only จะไม่สามารถบันทึกสิ่งที่เกิดขึ้นหลังจากนั้นได้ ซึ่งเป็นเหตุผลสำคัญที่ควรส่ง log ออกไปเก็บไว้นอกเครื่อง (off-box)

สัญญาณที่ 2: การตรวจจับการ remount เป็นแบบ read-only

ทำให้ความล้มเหลวปรากฏชัดเจนก่อนที่คุณจะพยายามตรวจพบมัน

findmnt -no SOURCE,FSTYPE,OPTIONS /

มองหา errors=remount-ro ในตัวเลือกการ mount อิมเมจระบบคลาวด์ของ Ubuntu และ Debian จะตั้งค่านี้ไว้ใน /etc/fstab เพื่อให้ข้อผิดพลาดของ metadata ทำให้ระบบไฟล์เปลี่ยนเป็น read-only แทนที่จะปล่อยให้ทำงานต่อไปบนความเสียหาย หากไม่มีค่านี้ ให้เพิ่มลงในรายการ root ใน /etc/fstab หรือตั้งค่าใน superblock ด้วย sudo tune2fs -e remount-ro /dev/vda1 การหยุดทำงานอย่างชัดเจนดีกว่าการปล่อยให้ข้อมูลเสียหายอย่างเงียบเชียบ

flag ของ mount ไม่ใช่หลักฐานที่ยืนยันได้ทั้งหมด ให้ทดสอบด้วยการเขียนข้อมูล:

touch /var/tmp/.disk-probe

บน root ที่เป็น read-only คำสั่งนี้จะแสดงผลลัพธ์ว่า:

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

ใช้ /var/tmp อย่าใช้ /tmp บนอิมเมจส่วนใหญ่ /tmp เป็น tmpfs ที่อยู่ในหน่วยความจำ ดังนั้นการเขียนข้อมูลสำเร็จที่นั่นไม่ได้พิสูจน์อะไรเกี่ยวกับดิสก์ของคุณ

รวมการทดสอบการเขียนเข้ากับการตรวจสอบพื้นที่ว่าง และส่ง 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 ทำให้การตรวจสอบที่ล้มเหลวส่งค่า exit code ที่ไม่ใช่ศูนย์ก่อนที่บรรทัด curl จะทำงาน ดังนั้นจึงไม่มี heartbeat ถูกส่งออกไป การกลับตรรกะนี้คือหัวใจสำคัญ: ระบบมอนิเตอร์จะเปลี่ยนเป็นสีแดงเพราะไม่มีข้อมูลส่งมา และเซิร์ฟเวอร์ที่ไม่สามารถเขียนข้อมูลได้ย่อมไม่สามารถเชื่อถือได้ในการรายงานปัญหาของตัวเอง การอ่านข้อมูลยังคงทำได้บนระบบไฟล์แบบ read-only ดังนั้นสคริปต์จึงยังคงเริ่มต้นทำงานได้

รันสคริปต์นี้ผ่าน 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 ที่เหลือไม่ถึงห้านาที การรันที่ล้มเหลวจะปรากฏใน journalctl -u disk-probe.service พร้อมข้อความแสดงข้อผิดพลาดของ shell ทำให้คุณสามารถแยกแยะระหว่างระบบไฟล์แบบ read-only กับระบบไฟล์ที่เต็มได้โดยไม่ต้องล็อกอินเข้าไป

URL ที่ใช้ push คือ Uptime Kuma push monitor ให้สร้างมอนิเตอร์ประเภท Push คัดลอก token มาใส่ในสคริปต์ และตั้งค่า heartbeat interval ของมอนิเตอร์ให้ยาวกว่า interval ของ timer เล็กน้อย เพื่อป้องกันไม่ให้การรันที่ช้าเพียงครั้งเดียวแจ้งเตือนคุณตอนตี 3 หากคุณยังไม่มีหน้าสถานะ Uptime Kuma ที่โฮสต์เอง เป็นจุดที่ประหยัดที่สุดในการวางการตรวจสอบนี้

มีข้อจำกัดที่ต้องทราบสองประการ: การทดสอบนี้ยืนยันว่าการเขียนข้อมูลได้รับการยอมรับ ไม่ใช่ว่าข้อมูลถูกเขียนลงสื่อบันทึกถาวรแล้ว เพราะการอ่านกลับอาจถูกดึงมาจาก page cache และสคริปต์นี้รันบนเครื่องที่ถูกตรวจสอบ ดังนั้นหากเซิร์ฟเวอร์ค้างอย่างสมบูรณ์ มันจะเงียบไปแทนที่จะรายงานการวินิจฉัย

สัญญาณที่ 3: แนวโน้มของ latency และ throughput

sudo apt install -y sysstat
iostat -xdz 5 3

ให้อ่าน r_await และ w_await ก่อน ค่าเหล่านี้คือค่าเฉลี่ยของเวลาที่ใช้ในการอ่านหรือเขียนข้อมูลในหน่วยมิลลิวินาที ซึ่งรวมถึงเวลาที่ต้องรอในคิวด้วย จากนั้นให้อ่าน aqu-sz ซึ่งเป็นจำนวนคำขอเฉลี่ยที่กำลังประมวลผลอยู่ ไม่ต้องสนใจ %util บน virtual disk เพราะค่านี้บ่งบอกเพียงว่าคิวไม่ว่างเปล่าเท่านั้น อุปกรณ์ที่รองรับการประมวลผลหลายคำขอพร้อมกันมักจะมีค่าเข้าใกล้ 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 --direct=1 จะข้ามการทำงานของ page cache ของคุณไป แต่มันไม่ข้าม cache ของโฮสต์ ดังนั้นผลลัพธ์ที่ได้จะอธิบายเส้นทางทั้งหมดตั้งแต่กระบวนการของคุณลงไปจนถึงที่เก็บข้อมูลของแพลตฟอร์ม ให้รันคำสั่งนี้ในขณะที่เซิร์ฟเวอร์ว่างงาน เนื่องจากมันจะแย่งทรัพยากรกับภาระงานของคุณเอง

หาก await เพิ่มสูงขึ้นโดยไม่มีข้อผิดพลาดใน kernel log มักไม่ได้หมายความว่าไดรฟ์กำลังจะเสีย แต่เป็นปัญหาการแย่งชิงทรัพยากรบนโฮสต์ ซึ่งเปรียบได้กับ CPU steal time จากเพื่อนบ้านที่ส่งเสียงดัง ในบริบทของที่เก็บข้อมูล หากปัญหานี้เกิดขึ้นในเวลาเดิมทุกวันและตั๋วแจ้งปัญหาของคุณได้รับคำตอบว่าระบบปกติ ทางออกคือการวางแผนใช้ที่เก็บข้อมูลที่ไม่มีการแชร์ทรัพยากรในลักษณะเดียวกัน ซึ่งเป็นกรณีของ storage VPS เมื่อเทียบกับ VPS ปกติ ในสถานการณ์ที่ภาระงานของคุณเน้นการใช้งานดิบเป็นหลัก

สัญญาณที่ 4: การตรวจสอบระบบไฟล์ขณะ mount อยู่

ext4 เก็บตัวนับข้อผิดพลาดไว้ใน superblock ซึ่งข้อมูลนี้จะยังคงอยู่แม้ผ่านการ reboot ไปแล้ว ในขณะที่ log ของคุณอาจถูกลบไปก่อนหน้า

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

ระบบไฟล์ที่สมบูรณ์จะแสดงผลเป็น Filesystem state: clean และ FS Error count: 0 หากพบ clean with errors และค่าตัวเลขที่ไม่ใช่ศูนย์ แสดงว่า kernel เคยพบข้อผิดพลาดของ metadata ณ จุดใดจุดหนึ่ง แม้ว่าจะไม่มีใครสังเกตเห็นและ log ได้ถูกหมุนเวียนออกไปแล้วก็ตาม คำสั่งนี้ควรถูกนำไปรวมอยู่ในรายการตรวจสอบประจำสัปดาห์

คุณไม่สามารถรัน fsck บนระบบไฟล์ root ที่กำลัง mount อยู่ได้ และการรัน e2fsck -n บนระบบไฟล์ที่ใช้งานจริงจะรายงานปัญหาที่เกิดจากการเปลี่ยนแปลงข้อมูลในขณะนั้นเท่านั้น หากต้องการบังคับให้มีการตรวจสอบจริง ให้เพิ่ม fsck.mode=force fsck.repair=yes ลงใน kernel command line สำหรับการบูตหนึ่งครั้งผ่าน console ของผู้ให้บริการ จากนั้น systemd-fsck จะดำเนินการตรวจสอบก่อนที่ root จะถูก mount ในโหมดอ่าน-เขียน

XFS ไม่มีการตรวจสอบแบบออนไลน์ คำสั่ง xfs_repair -n /dev/vda1 จะปฏิเสธการทำงานกับระบบไฟล์ที่กำลัง mount อยู่ ดังนั้นจึงต้องทำในโหมด rescue เท่านั้น XFS ชดเชยจุดนี้ด้วยการแจ้งเตือนที่ชัดเจน โดยจะสั่งปิดระบบไฟล์ทันทีเมื่อพบข้อผิดพลาดของ metadata แทนที่จะทำงานต่อไป

สำหรับ Btrfs ตัวนับข้อผิดพลาดจะถูกฝังอยู่ในระบบและคงอยู่ถาวร

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

หากค่า write_io_errs หรือ corruption_errs มากกว่าศูนย์ แสดงว่ามีเหตุการณ์เกิดขึ้นจริง และตัวนับจะคงค่าไว้แม้ผ่านการ reboot จนกว่าคุณจะรีเซ็ตค่าเหล่านั้น คำสั่ง scrub จะทำการอ่านทุก block ใหม่และตรวจสอบ checksum ซึ่งถือเป็นการทดสอบสื่อบันทึกข้อมูลที่ใกล้เคียงที่สุดสำหรับ virtual disk การทำงานนี้ใช้ I/O สูง จึงควรตั้งเวลาดำเนินการในช่วงที่มีการใช้งานน้อย

สัญญาณที่ 5: พื้นที่ว่าง รวมถึงส่วนที่ df ซ่อนไว้

การที่พื้นที่จัดเก็บข้อมูลเต็มจะทำให้เซิร์ฟเวอร์หยุดทำงานในลักษณะเดียวกับดิสก์เสีย และเหตุการณ์นี้เกิดขึ้นบ่อยกว่ามาก

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

การที่ No space left on device แสดงว่ามีพื้นที่ว่าง แต่ df -h แสดงว่าเต็ม หมายความว่าคุณใช้ inode หมดแทนที่จะเป็นไบต์ และ df -i จะแสดง IUse% ที่ 100 เปอร์เซ็นต์ สาเหตุเกิดจากไฟล์ขนาดเล็กจำนวนหลายล้านไฟล์ในไดเรกทอรีแคชหรือ mail spool ซึ่งการลบไฟล์ขนาดใหญ่ทิ้งจะไม่ช่วยแก้ปัญหานี้

พื้นที่ที่ไม่คืนกลับมาหลังจากลบไฟล์ มักเกิดจากไฟล์ที่ถูกลบไปแล้วแต่ยังมีกระบวนการทำงาน (process) ที่เปิดใช้งานอยู่ sudo lsof +L1 จะแสดงรายการไฟล์ที่ค่า link count เป็นศูนย์ การรีสตาร์ทกระบวนการที่ถือครองไฟล์นั้นอยู่จะเป็นการคืนพื้นที่ดังกล่าว

journal มักเป็นตัวการที่กินพื้นที่อย่างเงียบๆ journalctl --disk-usage จะรายงานว่ามันใช้พื้นที่ไปเท่าใด คุณสามารถจำกัดขนาดได้ด้วย SystemMaxUse=200M ในไฟล์ /etc/systemd/journald.conf ตามด้วย sudo systemctl restart systemd-journald และเรียกคืนพื้นที่ทันทีด้วย sudo journalctl --vacuum-size=200M

กรณีหนึ่งที่ดูเหมือนบั๊กแต่ไม่ใช่ คือการใช้ thin provisioned storage บนโฮสต์ ซึ่ง pool ของโฮสต์อาจเต็มในขณะที่ df ของคุณยังแสดงว่ามีพื้นที่ว่างเหลืออยู่หลายกิกะไบต์ การเขียนข้อมูลของคุณจะล้มเหลวพร้อมข้อผิดพลาด I/O ใน kernel log โดยไม่มีการแจ้งเตือนพื้นที่เต็มภายใน guest หากพบข้อผิดพลาดโดยที่ระบบไฟล์ยังไม่เต็ม นี่คือสถานการณ์ที่ควรเปิด ticket แจ้งปัญหาทันทีภายในชั่วโมงนั้น

การเชื่อมต่อสัญญาณเข้ากับ metrics agent

push probe จะตอบเพียงใช่หรือไม่ใช่เท่านั้น แต่การดูแนวโน้มจำเป็นต้องใช้ metrics agent ซึ่ง Prometheus node_exporter จะส่งออกข้อมูลทั้งหมดข้างต้นโดยไม่ต้องตั้งค่าเพิ่มเติม โดยมีชื่อ metric ที่ใช้เป็นฐานดังนี้:

• node_filesystem_readonly จะมีค่าเป็น 1 เมื่อ mount point อยู่ในสถานะ read-only ซึ่งเป็นสัญญาณเตือนให้คุณทำการ 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 ในรูปแบบ counter ที่คุณสามารถนำไปสร้างกราฟได้

กฎสองข้อต่อไปนี้จะช่วยตรวจจับกรณีที่ส่งผลกระทบต่อระบบจริง:

- 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

กฎข้อที่สองจะทำงานเมื่อแนวโน้มปัจจุบันบ่งชี้ว่าจะเต็มภายใน 4 วัน ทำให้คุณได้รับคำเตือนล่วงหน้าหลายวัน แทนที่จะรอให้ถึงระดับ 95 เปอร์เซ็นต์ซึ่งเหลือเวลาจัดการเพียงไม่กี่นาที

ความรับผิดชอบของแต่ละฝ่าย

ผู้ให้บริการของคุณเป็นเจ้าของฮาร์ดแวร์ดิสก์ พวกเขาทำหน้าที่อ่านค่า SMART, ดูแลอาร์เรย์ และเปลี่ยนดิสก์ที่มีจำนวน reallocated sectors เพิ่มสูงขึ้น โดยปกติแล้วพวกเขาจะไม่แจ้งให้คุณทราบเนื่องจากอาร์เรย์สามารถรองรับความเสียหายนั้นได้ นี่คือเหตุผลที่มี RAID 10 ภายใต้ VPS ของคุณ: เมื่อดิสก์เสีย ระบบจะทำการสร้างข้อมูลใหม่ (rebuild) แทนที่จะเกิดการหยุดชะงักของบริการ คุณไม่สามารถมองเห็นกระบวนการเหล่านี้ได้ และการจ่ายเงินเพื่อซื้อความสะดวกสบายจากนามธรรม (abstraction) นี้คือเหตุผลหลักของการเช่าเซิร์ฟเวอร์เสมือน

คุณเป็นเจ้าของข้อมูลของคุณเอง และข้อมูล telemetry ของดิสก์ก็ไม่สามารถปกป้องข้อมูลเหล่านั้นได้ เหตุการณ์ที่ทำลายข้อมูลของผู้เช่าจริง ๆ คือการใช้คำสั่ง rm ผิดพลาด, การ deploy ที่มีปัญหา, ผู้บุกรุกที่ขโมย SSH key ของคุณไป และเหตุการณ์ระดับแพลตฟอร์มที่ทำให้อาร์เรย์เสียหาย ซึ่งค่า SMART ไม่สามารถทำนายเหตุการณ์เหล่านี้ได้เลย

ดังนั้น การปกป้องที่แท้จริงของผู้เช่าคือการสำรองข้อมูลที่เก็บไว้นอกเซิร์ฟเวอร์และการทดสอบกู้คืนข้อมูลด้วยตนเอง Snapshot ของผู้ให้บริการนั้นสะดวกสบาย แต่ก็จัดเก็บอยู่บนแพลตฟอร์มเดียวกับสิ่งที่มันปกป้อง ซึ่งเป็นเหตุผลว่าทำไม snapshot และการสำรองข้อมูลจึงเป็นการปกป้องที่แตกต่างกัน ให้กำหนดตารางเวลาไว้: ทุกไตรมาส ให้กู้คืนข้อมูลสำรองล่าสุดลงใน VPS เครื่องใหม่ เริ่มการทำงานของแอปพลิเคชัน และจดบันทึกว่าใช้เวลานานเท่าใด ตัวเลขนั้นคือระยะเวลาการกู้คืนจริงของคุณ การซ้อมครั้งแรกมักจะใช้เวลานานกว่าที่ทุกคนคาดการณ์ไว้เสมอ

เมื่อใดที่ SMART มีผลกับคุณ

คู่มือที่สอนเรื่อง smartctl นั้นถูกต้อง และมีผลทันทีที่คุณเป็นเจ้าของฮาร์ดแวร์นั้นจริงๆ:

• เซิร์ฟเวอร์แบบ dedicated หรือ bare metal ซึ่ง sudo smartctl -a /dev/sda จะแสดงตาราง attribute ทั้งหมด และ smartd สามารถส่งอีเมลแจ้งเตือนคุณเมื่อมี attribute เปลี่ยนแปลง
• แผนบริการจัดเก็บข้อมูลที่ส่งผ่าน physical disk ไปยัง guest โดยตรง ผู้ให้บริการจะระบุเรื่องนี้ไว้อย่างชัดเจนเพราะเป็นจุดขาย
• ฮาร์ดแวร์ที่คุณเป็นเจ้าของ ไม่ว่าจะอยู่ที่บ้านหรือในพื้นที่ rack ที่คุณเช่า
• ดิสก์ที่อยู่หลัง RAID controller ซึ่งสามารถเข้าถึงได้ด้วย sudo smartctl -a -d megaraid,0 /dev/sda หรือเคส USB ที่รองรับ -d sat

สำหรับ NVMe ของจริง sudo smartctl -a -d nvme /dev/nvme0 และ sudo nvme smart-log /dev/nvme0n1 จะรายงาน critical_warning และ percentage_used จากตัวไดรฟ์โดยตรง สำหรับ SATA ของจริง attribute ที่ใช้ทำนายความล้มเหลวคือ Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) และ Reported_Uncorrect (187) หากค่าใดก็ตามเปลี่ยนจากศูนย์ ให้วางแผนเปลี่ยนอุปกรณ์ทันที การศึกษาไดรฟ์ในระดับสเกลใหญ่ต่างชี้ไปที่รายการสั้นๆ นี้ และ attribute อื่นส่วนใหญ่ถือเป็นสัญญาณรบกวน

ให้รัน daemon แทนการตรวจสอบด้วยตนเอง

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

log ของการทดสอบตัวเองควรแสดง Completed without error สำหรับการทดสอบที่คุณเพิ่งเริ่ม Ubuntu และ Debian มีการติดตั้ง /etc/smartd.conf มาพร้อมกับบรรทัด DEVICESCAN ซึ่งเป็นค่าล่าสุด ณ เดือนสิงหาคม 2026 ดังนั้น daemon จะตรวจพบทุกดิสก์ที่มองเห็นและส่งอีเมลแจ้ง root เมื่อมีการเปลี่ยนแปลง สิ่งเหล่านี้จะไม่ทำงานบน virtual disk ซึ่งเป็นเหตุผลว่าทำไมคู่มือส่วนที่เหลือจึงจำเป็นต้องมีอยู่

FAQ

ทำไม smartctl ถึงใช้งานไม่ได้บน VPS ของฉัน?

เพราะดิสก์เป็นแบบเสมือน ในกรณีของ KVM guest ที่ใช้ virtio-blk นั้น smartctl -a /dev/vda จะแสดงผลเป็น /dev/vda: Unable to detect device type เนื่องจากดิสก์แบบ paravirtual ไม่มีช่องทางส่งคำสั่ง ATA หรือ SCSI สำหรับการร้องขอข้อมูล SMART หากเป็นดิสก์แบบจำลอง คุณจะพบกับอุปกรณ์ที่มีชื่อรุ่นเป็น QEMU HARDDISK ซึ่งไม่มีข้อมูล SMART ที่ใช้งานได้อยู่เบื้องหลัง ส่วนภายในคอนเทนเนอร์ smartctl จะถูกปฏิเสธการทำงานโดยตรงเนื่องจากขาด CAP_SYS_RAWIO ทั้งหมดนี้ไม่ใช่การตั้งค่าที่ผิดพลาด และไม่มี flag -d ใดที่จะแก้ไขปัญหาเหล่านี้ได้

ฉันจะทราบได้อย่างไรว่าดิสก์ VPS ของฉันกำลังจะเสีย?

ให้สังเกตผลกระทบที่เกิดขึ้นแทนการดูที่ตัวฮาร์ดแวร์ ตรวจสอบ sudo journalctl -k -p err -b เพื่อหาบรรทัด blk_update_request: I/O error และ Remounting filesystem read-only เรียกใช้ sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' เพื่อค้นหาข้อผิดพลาดที่อาจตกหล่นไปจาก log ติดตาม r_await จาก iostat -xdz 5 เทียบกับค่ามาตรฐานที่คุณบันทึกไว้ในตอนที่ระบบยังทำงานปกติ บน VPS ข้อผิดพลาดด้าน I/O มักหมายถึงปัญหาจาก storage ของโฮสต์มากกว่าตัวไดรฟ์ที่กำลังจะเสีย ดังนั้นควรแจ้ง support ticket พร้อมระบุเวลาและ sector ที่เกิดปัญหา

ฉันควรตั้งค่าการแจ้งเตือนเรื่องสุขภาพดิสก์ของ VPS อย่างไร?

การแจ้งเตือน 4 รายการนี้ครอบคลุมปัญหาทั้งหมด: การที่ filesystem ถูก mount เป็นแบบ read-only ซึ่งตรวจสอบได้จาก node_filesystem_readonly == 1 หรือการทดสอบเขียนข้อมูลแล้วล้มเหลว, พื้นที่ว่างและ inodes ที่มีแนวโน้มลดลงจนใกล้ศูนย์, ข้อผิดพลาด I/O error ของ kernel ในช่วงเวลาที่ผ่านมา และการทำ heartbeat จากเซิร์ฟเวอร์เพื่อให้ระบบแจ้งเตือนเมื่อเซิร์ฟเวอร์ไม่ตอบสนอง ให้ข้ามการแจ้งเตือนที่อ้างอิงจาก SMART ทั้งหมด เพราะบนดิสก์เสมือนค่าเหล่านั้นมักไม่มีอยู่จริงหรือเป็นเพียงการจำลองจาก hypervisor เท่านั้น

ทำไม filesystem ของฉันถึงถูก remount เป็น read-only?

ext4 ที่ mount ด้วย errors=remount-ro จะทำเช่นนี้โดยเจตนาเมื่อพบข้อผิดพลาดของ metadata เพื่อหยุดการเขียนข้อมูลแทนที่จะปล่อยให้ความเสียหายลุกลาม สาเหตุจะปรากฏอยู่ใน kernel log เหนือบรรทัดที่แจ้งการ remount มักเป็น EXT4-fs error เกี่ยวกับการยกเลิก journal หลังจากอุปกรณ์ต้นทางส่งข้อผิดพลาด I/O กลับมา การ remount กลับเป็น read-write โดยไม่ตรวจสอบ filesystem จะเป็นการซ่อนอาการโดยที่สาเหตุยังคงอยู่ ให้บันทึก log ไว้ จากนั้นตรวจสอบ filesystem ในขณะที่ unmount แล้วผ่านโหมด rescue ด้วย e2fsck -fy /dev/vda1

ฉันสามารถอ่านข้อมูล SMART บนเซิร์ฟเวอร์เสมือนได้บ้างหรือไม่?

ในบางกรณีทำได้ เซิร์ฟเวอร์แบบ dedicated และ bare metal จะให้ค่า attribute ที่เป็นจริง รวมถึงแผนการจัดเก็บข้อมูลที่ส่งผ่านดิสก์จริง (passthrough) ไปยัง guest และโฮสต์ที่คุณเป็นเจ้าของเอง บางแพลตฟอร์มจะแสดง NVMe controller ให้ guest เห็นและ nvme smart-log จะส่งคืน log ดังนั้นให้รัน sudo nvme id-ctrl /dev/nvme0 ก่อน หากชื่อรุ่นระบุว่าเป็นบริการ network storage แสดงว่าตัวนับเหล่านั้นมาจาก software controller และในกรณีที่โหนดแบบ passthrough แสดงตัวนับจริงบนเครื่องที่ใช้งานร่วมกัน ข้อมูลเหล่านั้นจะอ้างอิงถึงฮาร์ดแวร์ที่แชร์กับผู้เช่ารายอื่น ดังนั้นการดำเนินการเดียวที่มีประโยชน์คือการส่ง support ticket