Cách giám sát sức khỏe ổ cứng trên VPS hiệu quả

Giám sát sức khỏe ổ cứng trên VPS thực sự thấy được những gì

Việc giám sát sức khỏe ổ cứng trên VPS bắt đầu bằng một thực tế mà hầu hết các hướng dẫn đều bỏ qua: ổ cứng đó không thuộc về bạn. Hệ điều hành khách (guest) của bạn chỉ nhìn thấy một thiết bị khối ảo (virtual block device). Ổ cứng vật lý và mọi bộ đếm lưu trữ trên đó đều thuộc về máy chủ vật lý (host). smartctl /dev/vda không thất bại vì bạn gõ sai lệnh. Nó thất bại vì không có gì đằng sau thiết bị đó có thể trả lời câu hỏi của bạn.

SMART (công nghệ tự giám sát, phân tích và báo cáo) là một bảng các bộ đếm được lưu trên chính ổ cứng: các sector được cấp phát lại (reallocated sectors), các sector đang chờ xử lý (pending sectors), số giờ hoạt động và lỗi phương tiện. Việc đọc bảng đó cần một đường dẫn để các lệnh ATA hoặc NVMe (non-volatile memory express) truyền đến phần cứng thực. Một ổ đĩa ảo hóa (paravirtual disk) không cung cấp đường dẫn này, vì vậy hệ điều hành khách nhận được bộ lưu trữ đã bị lược bỏ các dữ liệu đo lường (telemetry).

Người thuê (tenant) chỉ giám sát các hiệu ứng, không phải phần cứng. Có bốn tín hiệu có thể nhìn thấy từ bên trong hệ điều hành khách: lỗi I/O (input/output) trong log của kernel, hệ thống file tự chuyển sang chế độ chỉ đọc (read-only), độ trễ (latency) tăng dần và hết dung lượng lưu trữ. Cả bốn tín hiệu này đều có thể được thiết lập cảnh báo ngay hôm nay và tất cả đều xuất hiện trước khi người dùng kịp phàn nàn. Hãy ưu tiên thiết lập các cảnh báo này trước. Việc phân chia trách nhiệm nằm ở phần cuối, vì nó thay đổi nơi bạn nên tập trung nỗ lực.

Kiểm tra những gì máy chủ của bạn đang phơi bày

Đừng giả định trường hợp của bạn là gì. Hãy kiểm tra, sau đó đọc phần tương ứng.

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

virtio-blk, loại đĩa KVM (kernel-based virtual machine) thông thường. Thiết bị là /dev/vda và smartctl dừng lại trước khi gửi bất kỳ lệnh nào:

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

virtio-blk là một giao thức paravirtual không hỗ trợ tập lệnh ATA hoặc SCSI, vì vậy không có kênh nào để truyền yêu cầu SMART. -d sat và -d scsi đều thất bại theo cùng một cách, vì vấn đề nằm ở giao thức vận chuyển chứ không phải ở flag.

Đĩa SATA hoặc SCSI giả lập. Thiết bị là /dev/sda và smartctl có thể chạy đủ xa để nhận diện nó. Dòng model hiển thị QEMU HARDDISK. Chuỗi đó tự trả lời câu hỏi: bạn đang đọc một thiết bị do trình giả lập tạo ra và nó không báo cáo khả năng SMART nào có thể sử dụng được.

NVMe namespace. sudo nvme smart-log /dev/nvme0n1 trả về một log đầy đủ, đây là nơi mọi người thường bị đánh lừa. Hãy kiểm tra định danh controller trước bằng sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)'. Một số model number có tên của các sản phẩm lưu trữ mạng nghĩa là controller đó là phần mềm, vì vậy percentage_used và media_errors mô tả sự giả lập đó thay vì bộ nhớ flash chứa dữ liệu của bạn. Nếu bạn muốn biết bộ lưu trữ của mình thực sự là gì, hãy xác minh đĩa NVMe trên Linux thay vì tin vào mô tả trong kế hoạch.

Container, ví dụ như LXC (Linux containers) hoặc OpenVZ. Bạn không sở hữu thiết bị block nào của riêng mình. lsblk hiển thị các thiết bị của máy chủ vật lý (host) hoặc không hiển thị gì cả, và smartctl bị từ chối vì container không nắm giữ CAP_SYS_RAWIO:

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

Một cảnh báo về trường hợp nó hoạt động. Nếu smartctl trên một VPS trả về bảng thuộc tính đầy đủ, hãy đọc số serial trước khi thực hiện bất kỳ hành động nào. Một số nhà cung cấp host phơi bày một node thiết bị passthrough, và các bộ đếm đó thuộc về phần cứng được chia sẻ bởi mọi tenant trên máy chủ đó. Một giá trị Reallocated_Sector_Ct đang tăng lên ở đó là vấn đề cần gửi ticket hỗ trợ. Nó không phản ánh tình trạng dữ liệu của bạn.

Tín hiệu 1: Lỗi I/O trong kernel log

Đây là tín hiệu có giá trị cao nhất mà một tenant có được và không cần cài đặt 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'

Một yêu cầu thất bại từ ổ đĩa ảo sẽ trông như thế này:

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

Block layer đã yêu cầu host thực hiện một thao tác ghi nhưng host trả về lỗi. Trên một VPS, điều này hiếm khi là do chip nhớ flash bị hỏng. Thông thường, lỗi nằm ở tầng lưu trữ của host hoặc đường truyền mạng đến thiết bị lưu trữ gắn ngoài (network attached storage), vì vậy đây là sự cố từ phía nhà cung cấp. Hãy sao chép timestamp, tên thiết bị và sector vào ticket của bạn, vì đây là những thông tin mà đội ngũ lưu trữ có thể dùng để đối chiếu với log của họ.

Chuỗi log ext4 quan trọng nhất là cặp dòng sau:

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

Dòng thứ hai là dòng gây hại, vì máy chủ vẫn hoạt động. Nó vẫn phản hồi ping, vẫn phản hồi SSH, nhưng mọi thao tác ghi đều thất bại. Một bài kiểm tra HTTP đơn giản vẫn báo thành công trong khi ứng dụng của bạn văng lỗi ở mọi yêu cầu.

XFS thì sẽ ngắt filesystem ngay lập tức:

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 chỉ đọc log của lần boot hiện tại trừ khi journal được lưu trên đĩa, và nhiều image mặc định sử dụng journal tạm thời nằm trên RAM. Hãy bật tính năng lưu trữ bền vững (persistence), nếu không các bằng chứng sẽ biến mất ngay tại thời điểm bạn reboot để xử lý sự cố.

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

Sau lần reboot tiếp theo, journalctl --list-boots sẽ liệt kê nhiều hơn một lần boot. Ngay cả khi đã bật tính năng lưu trữ bền vững, một filesystem đã chuyển sang trạng thái read-only cũng không thể ghi lại những gì xảy ra sau đó, đây là lý do xác đáng để đẩy log ra khỏi máy chủ.

Tín hiệu 2: phát hiện mount read-only

Hãy làm cho lỗi trở nên rõ ràng trước khi bạn cố gắng phát hiện nó.

findmnt -no SOURCE,FSTYPE,OPTIONS /

Tìm errors=remount-ro trong các tùy chọn. Các cloud image của Ubuntu và Debian thiết lập nó trong /etc/fstab, vì vậy lỗi metadata sẽ khiến filesystem chuyển sang chế độ read-only thay vì tiếp tục chạy trên dữ liệu bị hỏng. Nếu thiếu, hãy thêm nó vào mục root trong /etc/fstab, hoặc thiết lập trong superblock bằng sudo tune2fs -e remount-ro /dev/vda1. Dừng lại ngay lập tức tốt hơn là để dữ liệu bị hỏng âm thầm.

Một mount flag không phải là bằng chứng. Hãy kiểm tra bằng cách ghi file:

touch /var/tmp/.disk-probe

Trên một root filesystem read-only, lệnh đó in ra chính xác:

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

Sử dụng /var/tmp, đừng dùng /tmp. Trên hầu hết các image, /tmp là một tmpfs nằm trên RAM, vì vậy việc ghi thành công ở đó không chứng minh được gì về ổ đĩa của bạn.

Kết hợp bài kiểm tra ghi file với kiểm tra dung lượng, và chỉ gửi heartbeat khi mọi kiểm tra đều vượt qua:

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 ở dòng cuối cùng có nghĩa là toàn bộ chuỗi lệnh hoạt động. set -eu khiến bất kỳ kiểm tra nào thất bại cũng sẽ thoát với mã lỗi khác 0 trước khi dòng curl chạy, do đó không có heartbeat nào được gửi đi. Sự đảo ngược đó chính là mục đích: monitor chuyển sang màu đỏ vì không có dữ liệu gửi đến, và một máy chủ không thể ghi dữ liệu thì không thể tin tưởng để mô tả vấn đề của chính nó. Các thao tác đọc vẫn hoạt động trên filesystem read-only, nên bản thân script vẫn khởi chạy được.

Chạy nó từ một 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 sẽ hiển thị unit với thời gian NEXT còn dưới năm phút. Một lần chạy thất bại sẽ xuất hiện trong journalctl -u disk-probe.service cùng với văn bản lỗi của shell, vì vậy bạn có thể phân biệt filesystem read-only với filesystem đầy mà không cần phải đăng nhập vào máy.

URL push đó là một push monitor của Uptime Kuma. Hãy tạo một monitor loại Push, copy token của nó vào script, và đặt khoảng thời gian heartbeat của monitor dài hơn một chút so với khoảng thời gian của timer để một lần chạy chậm không làm bạn bị báo động lúc 03:00. Nếu bạn chưa có trang trạng thái, một instance Uptime Kuma tự host là nơi rẻ nhất để đặt kiểm tra này.

Hai giới hạn thực tế. Bài kiểm tra xác nhận rằng thao tác ghi đã được chấp nhận, chứ không phải các byte đã đến được bộ nhớ bền vững, vì dữ liệu đọc lại có thể được phục vụ từ page cache. Và nó chạy trên chính máy chủ mà nó giám sát, nên một máy chủ bị treo hoàn toàn sẽ im lặng thay vì báo cáo chẩn đoán.

Tín hiệu 3: xu hướng độ trễ và thông lượng

sudo apt install -y sysstat
iostat -xdz 5 3

Trước tiên hãy đọc r_await và w_await. Đây là số mili giây trung bình cho một thao tác đọc hoặc ghi, bao gồm cả thời gian chờ trong hàng đợi. Tiếp theo, hãy xem aqu-sz, số lượng yêu cầu trung bình đang được xử lý. Hãy bỏ qua %util trên ổ đĩa ảo: nó chỉ có nghĩa là hàng đợi không trống, và một thiết bị phục vụ nhiều yêu cầu song song có thể đạt gần 100 phần trăm trong khi vẫn chưa chạm tới giới hạn của nó. await là con số phản ánh trải nghiệm thực tế của người dùng.

Các giá trị tuyệt đối không quan trọng bằng đường cơ sở (baseline) của chính bạn, vì vậy hãy ghi lại số liệu trong một giờ tải thấp và lưu giữ nó. /proc/diskstats là nguồn dữ liệu thô nếu bạn muốn tự thu thập các bộ đếm.

Để đo lường một cách chủ động:

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

Hãy đọc khối clat percentiles, đặc biệt là giá trị thứ 99. --direct=1 bỏ qua page cache của bạn. Nó không bỏ qua cache của host, vì vậy kết quả mô tả toàn bộ đường đi từ tiến trình của bạn xuống đến bộ lưu trữ của nền tảng. Hãy chạy nó khi server đang rảnh, vì nó sẽ cạnh tranh tài nguyên với workload của chính bạn.

Chỉ số await tăng cao mà không có lỗi trong kernel log thường không phải do ổ đĩa bị hỏng. Đó là sự tranh chấp tài nguyên trên host, tương tự như khái niệm CPU steal time từ một hàng xóm ồn ào nhưng dành cho lưu trữ. Nếu tình trạng này lặp lại vào cùng một giờ mỗi ngày và ticket hỗ trợ của bạn không tìm ra lỗi, giải pháp là chuyển sang một gói dịch vụ có I/O không bị chia sẻ, đây chính là trường hợp của một storage VPS so với một VPS thông thường khi workload bị giới hạn bởi tốc độ đĩa.

Tín hiệu 4: kiểm tra filesystem khi đang mount

ext4 lưu bộ đếm lỗi trong superblock, giá trị này vẫn tồn tại sau khi reboot ngay cả khi log của bạn đã bị xóa.

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

Một filesystem khỏe mạnh sẽ in ra Filesystem state: clean và FS Error count: 0. clean with errors và một giá trị khác 0 nghĩa là kernel đã gặp lỗi metadata tại một thời điểm nào đó, ngay cả khi không ai nhận ra và log đã bị ghi đè. Lệnh đó nên được đưa vào lịch kiểm tra hàng tuần.

Bạn không thể fsck một root filesystem đang được mount, và e2fsck -n trên một filesystem đang hoạt động chỉ báo cáo các vấn đề do dữ liệu thay đổi liên tục bên dưới. Để thực hiện kiểm tra thực sự, hãy thêm fsck.mode=force fsck.repair=yes vào dòng lệnh kernel cho một lần boot từ console của nhà cung cấp. systemd-fsck sau đó sẽ chạy kiểm tra trước khi root được mount ở chế độ read-write.

XFS không có tính năng kiểm tra online. xfs_repair -n /dev/vda1 từ chối chạy trên một filesystem đang được mount, vì vậy nó chỉ dùng được trong rescue mode. Bù lại, XFS xử lý lỗi rất quyết liệt: nó sẽ shutdown filesystem ngay khi gặp lỗi metadata thay vì tiếp tục chạy.

Trên Btrfs, các bộ đếm được tích hợp sẵn và có tính bền vững.

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

write_io_errs hoặc corruption_errs lớn hơn 0 là một sự kiện thực tế, và các bộ đếm này giữ nguyên giá trị qua các lần reboot cho đến khi bạn reset chúng. scrub sẽ đọc lại từng block và xác minh checksum của nó, đây là cách gần nhất với việc kiểm tra media trên một virtual disk. Nó tiêu tốn nhiều I/O, vì vậy hãy lên lịch chạy vào giờ thấp điểm.

Tín hiệu 5: dung lượng trống, bao gồm cả các phần mà df ẩn đi

Hết dung lượng sẽ làm hỏng server giống như lỗi ổ cứng, và tình trạng này xảy ra thường xuyên hơn nhiều.

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

No space left on device trong khi df -h hiển thị dung lượng trống nghĩa là bạn đã hết inode thay vì hết byte, và df -i hiển thị IUse% ở mức 100 phần trăm. Hàng triệu file nhỏ trong thư mục cache hoặc mail spool gây ra tình trạng này, và việc xóa các file lớn sẽ không có tác dụng.

Dung lượng không được giải phóng sau khi xóa thường là do một file đã xóa nhưng vẫn đang được một tiến trình chạy ngầm giữ lại. sudo lsof +L1 liệt kê các file có số lượng liên kết (link count) đã về 0. Khởi động lại tiến trình đang giữ file đó sẽ giải phóng dung lượng.

Journal là một thành phần tiêu tốn dung lượng âm thầm phổ biến. journalctl --disk-usage báo cáo dung lượng mà nó đang chiếm giữ. Hãy giới hạn nó bằng SystemMaxUse=200M trong /etc/systemd/journald.conf, theo sau là sudo systemctl restart systemd-journald, và thu hồi dung lượng ngay lập tức bằng sudo journalctl --vacuum-size=200M.

Có một trường hợp trông giống như lỗi nhưng thực tế không phải. Trên các hệ thống lưu trữ thin provisioned, pool của host có thể bị đầy trong khi df của bạn vẫn hiển thị còn trống hàng gigabyte. Các thao tác ghi của bạn sau đó sẽ thất bại với lỗi I/O trong kernel log mà không có cảnh báo hết dung lượng nào bên trong guest. Các lỗi xảy ra mà filesystem không đầy là sự kết hợp cần phải gửi ticket hỗ trợ ngay trong giờ đó.

Kết nối các tín hiệu vào một metrics agent

Một push probe chỉ trả về kết quả có hoặc không. Các xu hướng cần một metrics agent, và Prometheus node_exporter đã xuất sẵn mọi thông tin trên mà không cần cấu hình thêm. Các tên metric cần dựa vào:

• node_filesystem_readonly chuyển sang 1 khi mount ở chế độ read-only, đây là cảnh báo remount của bạn.
• node_filesystem_avail_bytes và node_filesystem_files_free bao phủ riêng biệt cho bytes và inodes.
• node_disk_io_time_seconds_total và node_disk_read_time_seconds_total cung cấp thời gian bận (busy time) và độ trễ (latency) dưới dạng các bộ đếm để bạn vẽ biểu đồ.

Hai quy tắc sau đây bắt được các trường hợp thực sự cần gửi thông báo (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

Quy tắc thứ hai kích hoạt khi xu hướng hiện tại chạm mức 0 trong vòng bốn ngày, giúp bạn nhận cảnh báo trước vài ngày thay vì đợi đến khi đầy 95 phần trăm, lúc đó bạn chỉ còn vài phút để xử lý.

Trách nhiệm của mỗi bên

Nhà cung cấp sở hữu các ổ cứng vật lý. Họ đọc thông số SMART, vận hành mảng lưu trữ và thay thế ổ cứng khi có các sector bị lỗi (reallocated sectors) mà thường không thông báo cho bạn, vì mảng RAID đã tự xử lý sự cố đó. Đó là mục đích của RAID 10 trên VPS của bạn: một ổ cứng hỏng chỉ dẫn đến quá trình rebuild thay vì gây ra gián đoạn dịch vụ. Bạn không thể thấy bất kỳ điều gì trong số đó, và việc trả phí cho sự trừu tượng hóa này chính là lý do chính khi thuê máy chủ ảo.

Bạn sở hữu dữ liệu của mình, và dữ liệu đo từ xa (telemetry) của ổ cứng dù sao cũng không bảo vệ được dữ liệu đó. Những sự kiện thực sự phá hủy dữ liệu của người dùng là lệnh rm sai lầm, một bản deploy lỗi, kẻ xâm nhập có được SSH key của bạn, và sự cố nền tảng làm hỏng toàn bộ mảng lưu trữ. Các thuộc tính SMART không dự đoán được bất kỳ điều nào trong số đó.

Vì vậy, sự bảo vệ thực sự của người dùng là một bản backup nằm ngoài máy chủ và một quy trình restore mà bạn đã tự thực hiện. Snapshot của nhà cung cấp rất tiện lợi nhưng chúng nằm trên cùng nền tảng với thứ mà chúng bảo vệ, đó là lý do tại sao snapshot và backup là các hình thức bảo vệ khác nhau. Hãy lên lịch diễn tập: mỗi quý một lần, hãy restore bản backup mới nhất vào một VPS mới, khởi động ứng dụng và ghi lại thời gian thực hiện. Con số đó chính là thời gian phục hồi thực tế của bạn. Lần diễn tập đầu tiên luôn chậm hơn so với dự đoán của bất kỳ ai.

Khi nào SMART áp dụng cho bạn

Các hướng dẫn dạy về smartctl là chính xác và chúng áp dụng ngay khi phần cứng thực sự thuộc về bạn:

• Máy chủ chuyên dụng (dedicated) hoặc bare metal, nơi sudo smartctl -a /dev/sda trả về bảng thuộc tính đầy đủ và smartd có thể gửi email cho bạn khi một thuộc tính thay đổi.
• Các gói lưu trữ cho phép truyền trực tiếp ổ đĩa vật lý vào guest. Các nhà cung cấp ghi rõ điều này vì đây là một điểm bán hàng.
• Phần cứng bạn sở hữu, tại nhà hoặc trong không gian rack bạn thuê.
• Ổ đĩa nằm sau RAID controller, có thể truy cập bằng sudo smartctl -a -d megaraid,0 /dev/sda, hoặc vỏ USB hỗ trợ -d sat.

Trên NVMe thực tế, sudo smartctl -a -d nvme /dev/nvme0 và sudo nvme smart-log /dev/nvme0n1 báo cáo critical_warning và percentage_used trực tiếp từ ổ đĩa. Trên SATA thực tế, các thuộc tính dự đoán lỗi là Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) và Reported_Uncorrect (187). Bất kỳ thuộc tính nào trong số này khác không đều có nghĩa là bạn cần lên kế hoạch thay thế. Các nghiên cứu quy mô lớn về ổ đĩa đều chỉ ra danh sách ngắn gọn này, hầu hết các thuộc tính khác chỉ là nhiễu.

Hãy chạy daemon thay vì kiểm tra thủ công.

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

Log tự kiểm tra (self-test log) sẽ hiển thị Completed without error cho lần chạy bạn vừa bắt đầu. Ubuntu và Debian phát hành /etc/smartd.conf với dòng DEVICESCAN, cập nhật đến tháng 8 năm 2026, vì vậy daemon sẽ tự động nhận diện mọi ổ đĩa nó thấy và gửi email cho root khi có thay đổi. Không có tính năng nào trong số này hoạt động trên ổ đĩa ảo, đó là lý do tại sao phần còn lại của hướng dẫn này tồn tại.

FAQ

Tại sao smartctl không hoạt động trên VPS của tôi?

Vì ổ đĩa là ảo hóa. Trên một KVM guest sử dụng virtio-blk, smartctl -a /dev/vda sẽ in ra /dev/vda: Unable to detect device type, do ổ đĩa paravirtual không hỗ trợ kênh lệnh ATA hoặc SCSI để truyền yêu cầu SMART. Trên ổ đĩa giả lập, bạn chỉ tiếp cận được thiết bị có model là QEMU HARDDISK, không có dữ liệu SMART hữu dụng phía sau. Bên trong container, smartctl bị từ chối thẳng thừng do thiếu CAP_SYS_RAWIO. Đây không phải là lỗi cấu hình và không có flag -d nào có thể khắc phục được.

Làm sao để biết ổ đĩa VPS của tôi đang bị lỗi?

Hãy theo dõi các tác động thay vì phần cứng. Kiểm tra sudo journalctl -k -p err -b để tìm các dòng blk_update_request: I/O error và Remounting filesystem read-only. Chạy sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' để tìm các lỗi mà log đã bỏ lỡ. Theo dõi r_await từ iostat -xdz 5 so với mức cơ sở bạn đã ghi lại khi hệ thống còn hoạt động tốt. Trên VPS, lỗi I/O thường là vấn đề lưu trữ của host thay vì ổ đĩa vật lý bị hỏng, vì vậy hãy gửi ticket hỗ trợ kèm theo timestamp và sector bị lỗi.

Tôi nên thiết lập cảnh báo gì cho sức khỏe ổ đĩa VPS?

Có bốn cảnh báo cần thiết. Một là mount read-only, phát hiện từ node_filesystem_readonly == 1 hoặc một lệnh ghi bị thất bại. Hai là dung lượng trống và inode trống đang tiến dần về 0. Ba là bất kỳ I/O error nào của kernel trong khoảng thời gian gần nhất. Bốn là heartbeat từ server, để hệ thống cảnh báo khi máy chủ ngừng phản hồi. Bỏ qua mọi thứ liên quan đến SMART, vì trên ổ đĩa ảo, các giá trị đó hoặc là không tồn tại, hoặc chỉ mô tả sự giả lập của hypervisor.

Tại sao filesystem của tôi tự remount sang read-only?

ext4 được mount với errors=remount-ro sẽ chủ động làm điều này khi gặp lỗi metadata: nó ngừng ghi thay vì tiếp tục làm hỏng dữ liệu. Nguyên nhân nằm trong kernel log ngay phía trên dòng remount, thường là một EXT4-fs error về việc hủy journal sau khi thiết bị bên dưới trả về lỗi I/O. Việc remount sang read-write mà không kiểm tra filesystem chỉ che giấu triệu chứng chứ không giải quyết nguyên nhân. Hãy lưu lại log, sau đó unmount filesystem và kiểm tra từ chế độ rescue bằng e2fsck -fy /dev/vda1.

Tôi có thể đọc dữ liệu SMART trên server ảo không?

Trong một số trường hợp cụ thể là có. Các server dedicated và bare metal cung cấp cho bạn các thuộc tính thực. Các gói lưu trữ cho phép passthrough ổ đĩa vật lý vào guest cũng vậy, và bất kỳ host nào bạn tự sở hữu cũng tương tự. Một số nền tảng cung cấp controller NVMe cho guest và nvme smart-log trả về log, vì vậy hãy chạy sudo nvme id-ctrl /dev/nvme0 trước: nếu model number đặt tên theo một dịch vụ lưu trữ mạng, nghĩa là các bộ đếm đó đến từ một software controller. Và ở nơi mà node passthrough hiển thị bộ đếm thực trên máy chủ dùng chung, chúng mô tả phần cứng chia sẻ với các khách hàng khác, nên hành động hữu ích duy nhất là gửi ticket hỗ trợ.