ניטור בריאות דיסק ב-VPS: מה אפשר לנטר באמת?

מה ניתן לראות בפועל מניטור בריאות דיסק ב-VPS

ניטור בריאות דיסק ב-VPS מתחיל בעובדה שרוב המדריכים מתעלמים ממנה: הדיסק אינו שייך לכם. המערכת האורחת שלכם רואה התקן בלוקים וירטואלי. הכונן הפיזי, וכל מונה שנשמר עליו, שייכים למארח. smartctl /dev/vda לא נכשל בגלל שהקלדתם את הפקודה בצורה שגויה. הוא נכשל מכיוון ששום דבר מאחורי ההתקן הזה לא יכול לענות על השאלה.

SMART (טכנולוגיית ניטור עצמי, ניתוח ודיווח) היא טבלה של מונים שנשמרת על הכונן עצמו: סקטורים שהוקצו מחדש, סקטורים ממתינים, שעות עבודה, ושגיאות מדיה. קריאת הטבלה הזו דורשת נתיב עבור פקודות ATA או NVMe (זיכרון לא נדיף מהיר) כדי להגיע לחומרה האמיתית. דיסק פארא-וירטואלי אינו מספק נתיב כזה, ולכן האורח מקבל אחסון ללא טלמטריה.

דייר מנטר השפעות, לא חומרה. ארבעה אותות גלויים מתוך המערכת האורחת: שגיאות I/O (קלט/פלט) בלוג הליבה, מערכת קבצים שנטענת מחדש במצב לקריאה בלבד, שיהוי (latency) שזוחל כלפי מעלה, ואזלן של שטח האחסון. ניתן להגדיר התראות על כל ארבעת האותות הללו כבר היום, וכולם מופיעים לפני שמשתמש מתלונן. הגדירו אותם תחילה. חלוקת האחריות מגיעה בסוף, מכיוון שהיא משנה את המקום שבו עליכם להשקיע מאמץ.

הוכחת החשיפה של השרת שלך

אל תניח באיזה מצב אתה נמצא. בדוק, ולאחר מכן קרא את הסעיף התואם.

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 הוא תעבורה פארא-וירטואלית ללא סט פקודות ATA או SCSI מאחוריו, לכן אין ערוץ להעברת בקשת SMART. -d sat ו--d scsi נכשלים באותה צורה, כיוון שהבעיה היא בתעבורה ולא בדגל.

כונן SATA או SCSI מדומה. ההתקן הוא /dev/sda ו-smartctl מצליח להגיע מספיק רחוק כדי לזהות אותו. שורת הדגם מציגה QEMU HARDDISK. מחרוזת זו עונה על השאלה בעצמה: אתה קורא התקן שהאמולטור המציא, והוא אינו מדווח על יכולת SMART שמישה.

מרחב שמות NVMe. sudo nvme smart-log /dev/nvme0n1 מחזיר לוג מלא, וזה המקום שבו אנשים נופלים בפח. בדוק תחילה את זהות הבקר באמצעות sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)'. מספר דגם שנוקב בשם של מוצר אחסון רשתי אומר שהבקר הוא תוכנה, לכן percentage_used ו-media_errors מתארים את האמולציה הזו ולא את ה-flash שמתחת לנתונים שלך. אם ברצונך לדעת מהו האחסון שלך באמת, אמת את כונן ה-NVMe בלינוקס במקום לסמוך על תיאור התוכנית.

מכולה (Container), כגון LXC (Linux containers) או OpenVZ. אין לך התקן בלוק (block device) משלך. lsblk מציג את ההתקנים של המארח או שאינו מציג דבר כלל, ו-smartctl מסורב כיוון שהמכולה אינה מחזיקה ב-CAP_SYS_RAWIO:

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

אזהרה אחת לגבי המקרה שבו זה כן עובד. אם smartctl ב-VPS מחזיר טבלת מאפיינים מלאה, קרא את המספר הסידורי לפני שתפעל על פיו. מארחים מסוימים חושפים צומת התקן (device node) בגישת passthrough, והמונים הללו שייכים לחומרה שמשותפת לכל הדיירים על אותה מכונה. Reallocated_Sector_Ct עולה שם הוא עילה לכרטיס תמיכה. זו אינה הצהרה לגבי הנתונים שלך.

סימן 1: שגיאות קלט/פלט (I/O) בלוג הליבה (kernel log)

זהו הסימן בעל הערך הגבוה ביותר העומד לרשות הדייר, והוא אינו דורש סוכן.

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'

בקשה שנכשלה מהדיסק הווירטואלי נראית כך:

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

שכבת הבלוקים ביקשה מהמארח לבצע כתיבה, והמארח החזיר שגיאה. בשרת VPS, זה כמעט אף פעם לא נובע מתא זיכרון פלאש גוסס. בדרך כלל מדובר בשכבת האחסון של המארח או בנתיב הרשת לאחסון המקושר לרשת (NAS), ולכן מדובר באירוע בצד הספק. העתיקו את חותמת הזמן, שם ההתקן והסקטור לתוך כרטיס התמיכה שלכם, שכן אלו הנתונים שצוות האחסון יכול להצליב מול הלוגים שלהם.

רצף ה-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 מבצעת כיבוי (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

journalctl -k קורא רק את האתחול הנוכחי אלא אם כן הלוג (journal) נשמר על הדיסק, ודימויים (images) רבים מגיעים עם לוג תנודתי שחי ב-RAM. הפעילו שמירה קבועה (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 אמור להציג יותר מאתחול אחד. גם עם שמירה קבועה, מערכת קבצים שעברה למצב קריאה בלבד (read-only) לא יכולה לתעד מה קרה לאחר מכן, וזו הסיבה המוצדקת לשליחת לוגים אל מחוץ לשרת.

סימן 2: זיהוי טעינה מחדש במצב לקריאה בלבד (read-only)

הפכו את הכשל לרועש לפני שאתם מנסים לזהות אותו.

findmnt -no SOURCE,FSTYPE,OPTIONS /

חפשו את errors=remount-ro באפשרויות. תמונות ענן של Ubuntu ו-Debian מגדירות זאת ב-/etc/fstab, כך ששגיאת מטא-דאטה הופכת את מערכת הקבצים ל-read-only במקום להמשיך לעבוד על גבי נזק. אם האפשרות חסרה, הוסיפו אותה לרשומה של ה-root ב-/etc/fstab, או הגדירו אותה ב-superblock באמצעות sudo tune2fs -e remount-ro /dev/vda1. עצירה רועשת עדיפה על שחיתות שקטה.

דגל 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 גורם לכל בדיקה שנכשלה להחזיר קוד יציאה שאינו אפס לפני שהשורה של curl רצה, כך שלא נשלח אות חיים. ההיפוך הזה הוא העיקר: הניטור הופך לאדום כי שום דבר לא הגיע, ושרת שלא יכול לכתוב לא יכול להיחשב אמין בתיאור הבעיה של עצמו. פעולות קריאה עדיין עובדות במערכת קבצים מסוג 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 אמור להציג את היחידה עם זמן NEXT שקרוב לחמש דקות מהרגע הנוכחי. הרצה שנכשלה תופיע ב-journalctl -u disk-probe.service עם טקסט השגיאה של ה-shell עצמו, כך שתוכלו להבדיל בין מערכת קבצים ב-read-only לבין מערכת מלאה מבלי להתחבר לשרת.

כתובת ה-push URL הזו היא עבור ניטור מסוג Push ב-Uptime Kuma. צרו ניטור מסוג Push, העתיקו את ה-token שלו לתוך הסקריפט, והגדירו את מרווח ה-heartbeat של הניטור להיות ארוך במעט ממרווח ה-timer, כדי שהרצה איטית אחת לא תקפיץ אתכם ב-03:00. אם אין לכם עדיין דף סטטוס, מופע Uptime Kuma מאוחסן עצמית הוא המקום הזול ביותר להציב בו את הבדיקה הזו.

שתי מגבלות כנות. הבדיקה מאשרת שכתיבה התקבלה, לא שהבתים הגיעו לאחסון עמיד, כיוון שהקריאה החוזרת יכולה להתבצע מתוך ה-page cache. והיא רצה על המכונה שהיא מנטרת, כך ששרת שנתקע לחלוטין ישתוק במקום לדווח על אבחנה.

אות 3: מגמות שיהוי ותפוקה

sudo apt install -y sysstat
iostat -xdz 5 3

קראו תחילה את r_await ואת w_await. אלו הם מספר המילי-שניות הממוצע שנדרש לביצוע פעולת קריאה או כתיבה, כולל הזמן שהושקע בהמתנה בתור. לאחר מכן קראו את 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. --direct=1 מדלג על ה-page cache שלכם. הוא אינו מדלג על ה-cache של המארח (host), לכן התוצאה מתארת את כל הנתיב מהתהליך שלכם ועד לאחסון של הפלטפורמה. הריצו זאת בזמן שהשרת אינו עמוס, כיוון שהפעולה מתחרה בעומס העבודה שלכם.

עלייה ב-await ללא שגיאות ב-kernel log בדרך כלל אינה מעידה על כונן תקול. מדובר בתחרות על משאבים במארח, הגרסה של עולם האחסון ל-זמן גניבת מעבד משכן רועש. אם הבעיה חוזרת באותה שעה בכל יום והכרטיס שפתחתם נסגר ללא ממצאים, הפתרון הוא תוכנית שבה ה-I/O אינו משותף באותה צורה, כפי שקורה ב-אחסון VPS לעומת VPS רגיל כאשר עומס העבודה מוגבל על ידי הדיסק.

בדיקות מערכת קבצים שניתן להריץ בזמן שהן מותקנות (mounted)

מערכת הקבצים ext4 שומרת מונה שגיאות בתוך ה-superblock, והוא נשמר גם לאחר אתחול, גם כאשר הלוגים שלכם כבר אינם זמינים.

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 בנקודה כלשהי, גם אם איש לא הבחין בכך והלוג כבר התחלף. פקודה זו צריכה להיות חלק מבדיקה שבועית.

לא ניתן להריץ fsck על מערכת קבצים ראשית (root) כשהיא מותקנת, והרצת e2fsck -n על מערכת קבצים פעילה תדווח על בעיות שנובעות רק מהשינויים בנתונים בזמן אמת. כדי לאלץ בדיקה אמיתית, הוסיפו את fsck.mode=force fsck.repair=yes לשורת הפקודה של ה-kernel עבור אתחול אחד דרך ה-console של ספק השרת. לאחר מכן, systemd-fsck יריץ את הבדיקה לפני שה-root מותקן במצב read-write.

ל-XFS אין בדיקה מקוונת (online). הפקודה xfs_repair -n /dev/vda1 מסרבת לרוץ על מערכת קבצים מותקנת, לכן יש להריץ אותה במצב rescue. XFS מפצה על כך בכך שהיא "רועשת": היא משביתה את מערכת הקבצים במקרה של שגיאת metadata במקום להמשיך לעבוד.

ב-Btrfs המונים מובנים וקבועים.

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

ערכים של write_io_errs או corruption_errs הגבוהים מאפס הם אירוע ממשי, והמונים שומרים על ערכיהם גם לאחר אתחול עד שתאפסו אותם. הפקודה scrub קוראת מחדש כל בלוק ומאמתת את ה-checksum שלו, וזהו הדבר הקרוב ביותר לבדיקת מדיה שזמין בדיסק וירטואלי. הפעולה יוצרת עומס 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 מציג שטח פנוי, פירוש הדבר הוא שאזלו ה-inodes ולא הבייטים, ו-df -i מציג IUse% ב-100 אחוז. מיליוני קבצים קטנים בתיקיית cache או ב-mail spool גורמים לכך, ומחיקת קבצים גדולים לא תפתור את הבעיה.

שטח שלא מתפנה לאחר מחיקה שייך בדרך כלל לקובץ שנמחק אך עדיין פתוח על ידי תהליך פעיל. sudo lsof +L1 מציג קבצים שמספר ה-links שלהם הגיע לאפס. הפעלה מחדש של התהליך שמחזיק בקובץ תשחרר את השטח.

ה-journal הוא צרכן שקט ונפוץ. journalctl --disk-usage מדווח על השטח שהוא תופס. ניתן להגביל אותו באמצעות SystemMaxUse=200M בתוך /etc/systemd/journald.conf ולאחר מכן sudo systemctl restart systemd-journald, ולפנות את השטח באופן מיידי בעזרת sudo journalctl --vacuum-size=200M.

מקרה אחד נראה כמו באג אך אינו כזה. באחסון מסוג thin provisioned, ה-pool של המארח עלול להתמלא בעוד ה-df שלכם עדיין מציג גיגה-בייטים פנויים. כתיבות שלכם ייכשלו עם שגיאות I/O ב-kernel log ללא כל התרעת שטח בתוך ה-guest. שגיאות ללא מערכת קבצים מלאה הן מצב שמחייב פתיחת כרטיס תמיכה באופן מיידי.

חיבור האותות לסוכן מדדים

בדיקת דחיפה (push probe) מספקת תשובה של כן או לא. מגמות דורשות סוכן מדדים, ו-Prometheus node_exporter כבר מייצא את כל הנתונים לעיל ללא צורך בתצורה נוספת. שמות המדדים שעליהם ניתן להתבסס:

• node_filesystem_readonly הופך ל-1 כאשר נקודת עיגון (mount) היא לקריאה בלבד, וזהו ההתראה שלכם ל-remount.
• node_filesystem_avail_bytes ו-node_filesystem_files_free מכסים בתים ו-inodes בנפרד.
• node_disk_io_time_seconds_total ו-node_disk_read_time_seconds_total מספקים זמן עבודה (busy time) ושיהוי (latency) כמונים שניתן להציג בגרפים.

שני כללים תופסים את המקרים שבאמת דורשים התראה:

- 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 אחוז תפוסה, מצב שבו נותרות לכם דקות בודדות.

חלוקת אחריות

ספק השרתים שלכם הוא הבעלים של הכוננים הפיזיים. הוא מנטר נתוני SMART, מנהל את מערך האחסון (array), ומחליף כונן שבו מזוהה עלייה במספר הסקטורים שהוקצו מחדש (reallocated sectors), לרוב מבלי לעדכן אתכם, שכן המערך סופג את הכשל. זו בדיוק המטרה של RAID 10 בשרת ה-VPS שלכם: כונן תקול מוביל לתהליך שחזור (rebuild) במקום להשבתת השירות. אינכם יכולים לראות את הפעולות הללו, והתשלום עבור ההפשטה הזו הוא חלק מהותי מהשכרת שרת וירטואלי.

אתם הבעלים של הנתונים שלכם, וטלמטריה של כוננים לא תגן עליהם בכל מקרה. האירועים שבאמת גורמים לאובדן נתונים של לקוח הם הרצה שגויה של rm, פריסה (deploy) כושלת, חדירה של גורם עוין באמצעות מפתח ה-SSH שלכם, או תקלה בתשתית שמשביתה את מערך האחסון כולו. נתוני SMART אינם חוזים אף אחד מהתרחישים הללו.

לכן, ההגנה האמיתית של הלקוח היא גיבוי שנשמר מחוץ לשרת ותהליך שחזור שביצעתם בעצמכם. צילומי מצב (snapshots) של הספק הם נוחים, אך הם מאוחסנים על אותה תשתית שהם אמורים להגן עליה; זו הסיבה ש-צילומי מצב וגיבויים הם אמצעי הגנה שונים. קבעו תרגול ביומן: אחת לרבעון, שחזרו את הגיבוי העדכני ביותר לשרת VPS חדש, הריצו את היישום, ותעדו כמה זמן התהליך ארך. המספר הזה הוא זמן ההתאוששות האמיתי שלכם. התרגול הראשון תמיד אורך זמן רב יותר ממה שמישהו העריך.

מתי SMART רלוונטי עבורך

מדריכים המלמדים smartctl הם נכונים, והם תקפים ברגע שהחומרה היא באמת בבעלותך:

• שרת ייעודי או bare metal, שבו sudo smartctl -a /dev/sda מחזיר את טבלת המאפיינים המלאה ו-smartd יכול לשלוח לך דוא"ל כאשר מאפיין משתנה.
• תוכניות אחסון המעבירות דיסק פיזי ישירות למערכת האורחת. ספקי שירות מתעדים זאת במפורש, כיוון שמדובר בנקודת מכירה.
• חומרה שבבעלותך, בבית או בשטח ארון תקשורת ששכרת.
• דיסק מאחורי בקר RAID, שניתן להגיע אליו עם 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 אמיתיים, המאפיינים המנבאים כשל הם Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) ו-Reported_Uncorrect (187). כל שינוי שלהם מערך אפס מחייב תכנון החלפה. מחקרי כוננים רחבי היקף מצביעים שוב ושוב על אותה רשימה קצרה, ורוב המאפיינים האחרים הם רעש בלבד.

הריצו את ה-daemon במקום לבצע בדיקות ידניות.

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

יומן ה-self-test אמור להציג Completed without error עבור הבדיקה שהרצת זה עתה. הפצות Ubuntu ו-Debian מספקות את /etc/smartd.conf עם שורת DEVICESCAN, נכון לאוגוסט 2026, כך שה-daemon מזהה כל דיסק שהוא יכול לראות ושולח דוא"ל ל-root בכל שינוי. שום דבר מזה לא עובד על דיסק וירטואלי, וזו הסיבה ששאר המדריך הזה קיים.

FAQ

מדוע smartctl לא עובד ב-VPS שלי?

מכיוון שהדיסק וירטואלי. במכונה וירטואלית מסוג KVM המשתמשת ב-virtio-blk, הפקודה smartctl -a /dev/vda מציגה /dev/vda: Unable to detect device type, כיוון שדיסק פארא-וירטואלי אינו כולל ערוץ פקודות ATA או SCSI שדרכו יכולה לעבור בקשת SMART. בדיסק מדומיין אתם מגיעים להתקן שהדגם שלו מופיע כ-QEMU HARDDISK, ללא נתוני SMART שמישים מאחוריו. בתוך מכולה (container), הגישה ל-smartctl נחסמת כליל בשל היעדר CAP_SYS_RAWIO. אף אחד מאלו אינו מהווה הגדרה שגויה, ושום דגל -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' כדי למצוא שגיאות שהלוגים כבר איבדו. עקבו אחר r_await מתוך iostat -xdz 5 אל מול קו בסיס שתיעדתם כשהמערכת הייתה תקינה. ב-VPS, שגיאת I/O מעידה בדרך כלל על בעיית אחסון במארח ולא על כונן גוסס, לכן יש לדווח על כך בכרטיס תמיכה בצירוף חותמת זמן וסקטור.

על אילו מדדי בריאות דיסק ב-VPS כדאי להתריע?

ארבע התראות מכסות זאת. mount במצב לקריאה בלבד (read-only), מזוהה על ידי node_filesystem_readonly == 1 או בדיקת כתיבה שנכשלת. שטח פנוי ו-inodes פנויים שמתקרבים לאפס. כל I/O error של ה-kernel במרווח הזמן האחרון. דופק (heartbeat) מהשרת, כך ששתיקה תפעיל התראה כאשר השרת מפסיק להגיב. דלגו על כל מה שנגזר מ-SMART, כיוון שבדיסק וירטואלי ערכים אלו חסרים או מתארים את האמולציה של ה-hypervisor.

מדוע מערכת הקבצים שלי עברה ל-mount במצב לקריאה בלבד?

מערכת ext4 שמוגדרת עם errors=remount-ro מבצעת זאת במכוון כאשר היא נתקלת בשגיאת metadata: היא מפסיקה לכתוב במקום להמשיך ולגרום לנזק. הגורם מופיע בלוג ה-kernel ממש מעל שורת ה-remount, בדרך כלל כ-EXT4-fs error על יומן (journal) שבוטל לאחר שההתקן שמתחת החזיר שגיאת I/O. ביצוע remount למצב קריאה-כתיבה ללא בדיקת מערכת הקבצים מסתיר את הסימפטום ומשאיר את הבעיה. שמרו את הלוג, ולאחר מכן בדקו את מערכת הקבצים כשהיא מנותקת (unmounted) ממצב rescue באמצעות e2fsck -fy /dev/vda1.

האם אני יכול לקרוא נתוני SMART בשרת וירטואלי?

במקרים מסוימים, כן. שרתים ייעודיים (dedicated) ושרתי bare metal מספקים מאפיינים אמיתיים. כך גם תוכניות אחסון המעבירות דיסק פיזי ישירות לאורח (passthrough), וכל מארח שבבעלותכם. פלטפורמות מסוימות מציגות בקר NVMe לאורח ו-nvme smart-log מחזיר לוג, לכן הריצו תחילה את sudo nvme id-ctrl /dev/nvme0: מספר דגם המציין שירות אחסון רשתי אומר שהמונים הללו מגיעים מבקר תוכנה. ובמקום שבו צומת passthrough אכן חושף מונים אמיתיים במכונה משותפת, הם מתארים חומרה המשותפת לדיירים אחרים, לכן הפעולה המועילה היחידה היא פתיחת כרטיס תמיכה.