مفاهیم پایه

KVM و NVMe به زبان ساده — چرا این دو کلمه در خرید سرور مهم‌اند؟

تصویر شاخص مقاله KVM و NVMe در خرید سرور مجازی؛ نمایش هایپروایزر KVM با منابع رزروشده در کنار دیسک NVMe و صف‌های موازی فرمان، همراه با دستورهای بررسی نوع مجازی‌سازی و سنجش IOPS دیسک سرور

وقتی می‌خواهید سرور مجازی بخرید، دو کلمه بیشتر از بقیه در برگه‌ی مشخصات تکرار می‌شود: KVM و NVMe. اولی تعیین می‌کند منابعی که پولش را می‌دهید واقعاً مال شماست یا فقط روی کاغذ؛ دومی تعیین می‌کند دیتابیس و سایت‌تان چقدر سریع نفس می‌کشند. مشکل این است که نوشتن این دو کلمه روی صفحه‌ی فروش هیچ هزینه‌ای برای فروشنده ندارد. اینجا می‌بینیم مجازی‌سازی KVM چیست، NVMe چه فرقی با SSD معمولی دارد، چرا نام دیسک چیزی را لو نمی‌دهد و با چند دستور چطور بفهمید همان را تحویل گرفته‌اید که قولش داده شده.

مجازی‌سازی KVM چیست و چرا برای خریدار مهم است؟

KVM مخفف Kernel-based Virtual Machine است: ماژول مجازی‌سازی داخل خودِ هسته‌ی لینوکس که با کمک قابلیت‌های سخت‌افزاری پردازنده (Intel VT-x یا AMD-V) ماشین‌های مجازی «واقعی» می‌سازد. کلمه‌ی واقعی اینجا بار فنی دارد: هر سرور KVM یک کامپیوتر کامل است — پردازنده‌ی مجازی، رم اختصاصی، دیسک و کارت شبکه‌ی خودش را دارد و مهم‌تر از همه، کرنل خودش را بوت می‌کند.

نتیجه‌ی عملی سه چیز است:

  • رم اختصاصی: ۴ گیگ رم یعنی ۴ گیگ رم؛ در لحظه‌ی ساخت ماشین برای شما رزرو می‌شود، نه اینکه «تا سقف ۴ گیگ اگر بقیه استفاده نکنند».
  • کرنل مستقل: می‌توانید ماژول کرنل بارگذاری کنید — یعنی WireGuard، Docker، فایل‌سیستم‌های خاص و هر چیزی که به کرنل دست می‌زند بدون بهانه کار می‌کند.
  • هر سیستم‌عاملی: اوبونتو، دبیان، آلما، حتی BSD یا ویندوز. چون سخت‌افزار مجازی است، سیستم‌عامل مهمان محدودیتی ندارد.

و یک نکته‌ی تاریخی: از بهمن ۱۳۸۵ و نسخه‌ی ۲٫۶٫۲۰ هسته‌ی لینوکس، KVM جزئی از خود کرنل است، نه لایه‌ای جانبی که کنارش نصب شود.

زیر پوست KVM: هسته، QEMU و درایورهای virtio

KVM فقط بخش سختِ ماجرا را برعهده دارد: اجرای مستقیم دستورهای مهمان روی پردازنده‌ی واقعی و مدیریت حافظه. شبیه‌سازی قطعات — دیسک، کارت شبکه، کارت گرافیک — کار برنامه‌ای در فضای کاربر است که معمولاً QEMU نام دارد.

اگر QEMU یک دیسک IDE قدیمی یا کارت شبکه‌ی e1000 را کامل شبیه‌سازی کند، هر دسترسی به رجیسترهای آن قطعه اجرای ماشین مجازی را متوقف می‌کند و این توقف‌ها زیر بار جمع می‌شوند. راه‌حل استاندارد virtio است: دستگاه‌های شبه‌مجازی که درایور مهمانشان می‌داند مجازی است و به‌جای تقلید سخت‌افزار از حلقه‌ی حافظه‌ی مشترک با میزبان استفاده می‌کند. بررسی‌اش یک دستور است:

lspci | grep -i virtio

00:03.0 Ethernet controller: Red Hat, Inc. Virtio network device
00:04.0 SCSI storage controller: Red Hat, Inc. Virtio block device

اگر به‌جای این دو خط چیزی مثل Intel Corporation 82540EM Gigabit Ethernet یا کنترلر IDE دیدید، سرور روی دستگاه‌های شبیه‌سازی‌شده است و بخشی از کارایی را از دست می‌دهد. تأیید سمت کرنل:

lsmod | grep virtio

virtio_net             57344  0
virtio_blk             20480  3
virtio_pci             28672  0
💡 یک برداشت عملی: «KVM» روی برگه‌ی مشخصات فقط نوع هایپروایزر را می‌گوید، نه کیفیت پیکربندی آن؛ دو سرور KVM با رم و CPU یکسان می‌توانند به‌خاطر درایور دیسک اختلاف چشمگیری در کارایی داشته باشند.

تفاوت KVM و OpenVZ — و ماجرای اورسلینگ

روش دوم مجازی‌سازی کانتینری است: OpenVZ و LXC. اینجا هیچ ماشین مجازی‌ای در کار نیست؛ همه‌ی «سرور»ها پارتیشن‌هایی از یک سیستم‌عامل مشترک‌اند و کرنل میزبان را قرض می‌گیرند. سبک‌تر است و سربار کمتری دارد — اما بهایش را شما می‌پردازید:

  • کرنل انتخابی نیست: اگر میزبان کرنل قدیمی داشته باشد، شما هم دارید. نصب داکر روی سرور ابری یا راه‌اندازی وی‌پی‌ان کرنلی روی OpenVZ قدیمی معمولاً به دیوار می‌خورد.
  • منابع «مشترکِ قابل قرض» هستند: رمی که می‌بینید اغلب burst است، نه رزروشده.
  • اورسلینگ آسان می‌شود: چون منابع رزرو نمی‌شوند، فروشنده می‌تواند روی سروری با ۶۴ گیگ رم، مثلاً ۲۰۰ گیگ رم «بفروشد» — با این شرط که همه هم‌زمان مصرف نکنند.

علامت‌های کلاسیک اورسلینگ آشناست: سرور ظهرها پرواز می‌کند و شب‌ها به زانو می‌افتد؛ یا free رم خالی نشان می‌دهد ولی پروسه‌ها با خطای کمبود حافظه کشته می‌شوند. در KVM این بازی سخت‌تر است، چون رم هر ماشین از قبل کنار گذاشته شده. تفاوت KVM و OpenVZ در یک جمله: یکی خانه‌ی مستقل با سند است، دیگری اتاقی در خانه‌ی صاحب‌خانه.

تفاوت کم‌تر گفته‌شده اینکه در کانتینر، آنچه free و top نشان می‌دهند ممکن است اعداد کل میزبان باشد نه سهم شما؛ در KVM کرنل مستقل است و همان اعداد، اعداد سرور شمایند. اگر بین انواع سرویس مردد هستید، مقایسه‌ی سرور مجازی، اختصاصی و ابری مرزها را دقیق‌تر می‌کشد.

💡 نکته: CPU حتی در KVM هم بین ماشین‌ها به اشتراک گذاشته می‌شود (و طبیعی است)؛ چیزی که KVM تضمین می‌کند رزرو رم و استقلال کرنل است. فروشنده‌ی منصف نسبت اشتراک CPU را هم معقول نگه می‌دارد.

استیل‌تایم چیست و چطور اورفروشی CPU را لو می‌دهد؟

رزرو CPU در هیچ مدلی تضمین‌شده نیست و لینوکس برای همین شاخصی دارد: استیل‌تایم یا ستون st — درصد زمانی که پردازنده‌ی مجازی شما کار آماده‌ی اجرا داشته اما هایپروایزر هسته‌ی فیزیکی را به ماشین دیگری داده بود. این نه بی‌کاری است و نه انتظار دیسک؛ یعنی نوبت شما نشد. روی سرور فیزیکی همیشه صفر است.

vmstat 1 5

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 612344  84120 1204880    0    0    41   126  384  702 11  3 85  1  1
 2  0      0 612344  84120 1204880    0    0     3    18  212  398  9  2 88  0  1
 1  0      0 611980  84120 1204884    0    0     0     0  198  361  7  1 91  0  1
 3  0      0 611704  84120 1204884    0    0     0    24  241  452 12  3 84  0  1
 1  0      0 611704  84120 1204884    0    0     0     8  205  377  8  2 89  0  1

عدد آخر هر سطر همان استیل‌تایم است — با این یادآوری که خط اولِ vmstat میانگین از زمان بوت است و باید از خط دوم به بعد را خواند. قاعده‌ی سرانگشتی: زیر یک درصد عادی، یک تا پنج درصد قابل‌تحمل و بالای ده درصدِ پایدار یعنی میزبان شلوغ است. همین عدد در top انتهای سطر %Cpu(s) با برچسب st می‌آید و mpstat -P ALL 1 آن را به تفکیک هسته نشان می‌دهد.

نکته‌ی کلیدی: افزایش هسته‌های مجازی استیل‌تایم را درمان نمی‌کند — گاهی بدترش می‌کند، چون ماشینی با هسته‌های بیشتر برای زمان‌بند میزبان سخت‌تر جا می‌شود. برای ثبت مداوم این عدد، ابزارهای راهنمای مانیتورینگ سرور لینوکس کار را ساده می‌کنند.

NVMe چیست؟ سه نسل دیسک در یک نگاه

حالا کلمه‌ی دوم. هارد مکانیکی (HDD) برای هر خواندنِ پراکنده باید هد فیزیکی را جابه‌جا کند — چند میلی‌ثانیه برای هر حرکت. SSD قطعه‌ی متحرک ندارد، اما SSDهای معمولی هنوز از رابط SATA حرف می‌زنند؛ پروتکلی که برای هاردهای مکانیکی طراحی شده، سقف نظری‌اش ۶۰۰ مگابایت بر ثانیه است (در عمل حدود ۵۵۰) و فقط یک صف فرمان دارد. NVMe از اول برای فلش نوشته شده و مستقیم روی PCIe می‌نشیند: ده‌ها هزار صف موازی، تأخیر در حد میکروثانیه.

این تفاوت در خود استاندارد عدد دارد: رابط AHCI — همان که پشت SATA می‌نشیند — یک صف فرمان با حداکثر ۳۲ فرمان دارد، در حالی که NVMe تا ۶۵٬۵۳۵ صف و تا ۶۵٬۵۳۶ فرمان در هر صف را مجاز می‌داند. یعنی وقتی ده‌ها فرایند هم‌زمان از دیسک می‌خواهند — وضعیت وب‌سرور شلوغ — SATA همه را در یک صف باریک می‌چیند و NVMe واقعاً موازی پیش می‌برد.

نوع دیسکIOPS تصادفی (۴K)تأخیر معمولپهنای باندصف فرمان
HDD (۷۲۰۰ دور)حدود ۷۵ تا ۸۰۵ تا ۱۰ میلی‌ثانیهحدود ۱۶۰ مگابایت/ثانیهیک صف، ۳۲ فرمان
SATA SSD۵۰ تا ۱۰۰ هزارحدود ۰٫۱ میلی‌ثانیهتا ۵۵۰ مگابایت/ثانیهیک صف، ۳۲ فرمان
NVMe۲۰۰ هزار تا بیش از ۱ میلیون۲۰ تا ۱۰۰ میکروثانیهچند گیگابایت/ثانیهتا ۶۵٬۵۳۵ صف

این اعداد برای سایت شما یعنی چه؟

بار واقعی یک سرور وب، خواندن‌های کوچک و پراکنده است — همان‌جا که ستون IOPS حرف اول را می‌زند، نه پهنای باند. یک صفحه‌ی وردپرس ده‌ها کوئری اجرا می‌کند و هر کوئری چند خواندن کوچک از دیسک است. روی HDD هر خواندن چند میلی‌ثانیه طول می‌کشد و جمعشان بخش بزرگی از زمان پاسخ را می‌بلعد؛ روی NVMe همان خواندن‌ها در حد میکروثانیه جواب می‌گیرند و آنچه می‌ماند اجرای PHP است، نه انتظار دیسک. همین اثر را در ایمپورت دیتابیس، بکاپ‌گیری، apt upgrade و بیلد پروژه هم لمس می‌کنید.

بار کاری‌ای که تفاوت را بی‌رحمانه‌تر نشان می‌دهد نوشتن با fsync است: هر بار که دیتابیس تراکنشی را «قطعی» اعلام می‌کند باید مطمئن شود داده روی حافظه‌ی پایدار نشسته — روی HDD یعنی انتظار برای جابه‌جایی هد و چرخش صفحه، روی NVMe چند ده میکروثانیه. حساب سرانگشتی گویاست: دیسکی که در ثانیه ۱۰۰ بار fsync را تمام می‌کند، برای ایمپورتی با ۱۰۰ هزار تراکنش نزدیک به ۱۷ دقیقه منتظر دیسک می‌ماند؛ با تأخیر ۱۰۰ میکروثانیه همان کار حدود ۱۰ ثانیه است.

چرا اسم دیسک سرورم vda است، نه nvme0n1؟

داخل یک سرور مجازی KVM، خروجی lsblk معمولاً چنین است:

lsblk -d -o NAME,ROTA,TYPE,SIZE,MODEL

NAME ROTA TYPE  SIZE MODEL
vda     0 disk   40G

نام vda یعنی دستگاه از طریق درایور virtio-blk ارائه شده و ستون MODEL خالی است، چون virtio مدلی برای اعلام‌کردن ندارد. با virtio-scsi نام sda و مدل QEMU HARDDISK را می‌بینید. در هر دو حالت، آنچه می‌بینید یک دستگاه مجازی است، نه دیسک فیزیکی میزبان.

پیامدش این است: ندیدن nvme0n1 ثابت نمی‌کند دیسک زیرین NVMe نیست — و برعکس، دیدن nvme0n1 هم چیزی را تضمین نمی‌کند، چون هایپروایزر می‌تواند کنترلر NVMe را شبیه‌سازی کند و در پلتفرم‌های بزرگ ابری دیسک‌های شبکه‌ای هم با همین نام معرفی می‌شوند. ستون ROTA هم فقط ادعای هایپروایزر است؛ صفر بودنش یعنی کرنل مهمان دیسک را غیرچرخشی می‌بیند، نه اینکه پشتش حتماً فلش نشسته باشد.

⚠️ به همین دلیل nvme smart-log یا خواندن سلامت دیسک با smartctl داخل یک سرور مجازی معمولی جواب نمی‌دهد: مسیر /dev/nvme0 وجود ندارد. هر راهنمایی که این را پیشنهاد می‌دهد، برای سرور فیزیکی نوشته شده است.

چطور بفهمیم واقعاً چه چیزی تحویل گرفته‌ایم؟

لازم نیست به بروشور فروشنده اعتماد کنید؛ چند دستور کافی است. اول با SSH وارد سرور شوید.

۱) نوع مجازی‌سازی

systemd-detect-virt

kvm

اگر خروجی kvm بود، سرور KVM دارید؛ خروجی openvz یا lxc یعنی کانتینر و خروجی none یعنی سرور فیزیکی. تأیید دوم:

lscpu | grep -i -E 'hypervisor|virtualization'

Hypervisor vendor:      KVM
Virtualization type:    full

در سرور KVM باید Hypervisor vendor: KVM را ببینید و full یعنی مجازی‌سازی کامل. دو راه پشتیبان برای وقتی systemd نیست:

grep -o hypervisor /proc/cpuinfo | head -1
hypervisor

sudo dmidecode -s system-product-name
Standard PC (Q35 + ICH9, 2009)

۲) نوع دیسک

lsblk -d -o NAME,ROTA,TYPE,MODEL

نام nvme0n1 یعنی کرنل مهمان کنترلر NVMe می‌بیند (چه واگذاری مستقیم، چه شبیه‌سازی). نام vda یا sda با ROTA صفر یعنی دیسک مجازی غیرچرخشی — رایج‌ترین حالت، که چیزی درباره‌ی سخت‌افزار پشتش ثابت نمی‌کند. ROTA برابر یک یعنی هایپروایزر دیسک را چرخشی معرفی کرده؛ فرار کنید.

۳) تست سرعت واقعی با fio

apt install -y fio
fio --name=quicktest --filename=fio-test --size=256M --rw=randread --bs=4k --iodepth=32 --ioengine=libaio --direct=1 --runtime=15 --time_based --group_reporting
rm fio-test

عدد IOPS خروجی را با جدول بالا مقایسه کنید: زیر چند صد یعنی هارد مکانیکی، چند ده هزار یعنی SATA SSD و بالای صد هزار یعنی NVMe سالم. در سرورهای ابری معمولاً سقف منصفانه‌ای روی IOPS هر ماشین هست تا یک همسایه دیسک را قبضه نکند؛ عدد ثابت و تکرارپذیر مهم‌تر از رکوردشکنی است.

گزینه‌ی --direct=1 را دست نزنید: کش صفحه‌ی لینوکس را دور می‌زند و بدون آن دارید سرعت رم را می‌سنجید، نه دیسک. روی کرنل‌های جدید --ioengine=io_uring سربار کمتری دارد.

⚠️ تست را با randread و فایل کوچک انجام دهید و فایل تست را حذف کنید. تست‌های نوشتنِ سنگین و طولانی هم عمر فلش را می‌خورند و هم سرویسِ در حال کار را کند می‌کنند. بهترین زمان این آزمون، ساعت اول عمر سرور تازه است.

خروجی fio را چطور بخوانیم؟

خروجی fio طولانی است، اما فقط چند عددش به کار تصمیم‌گیری می‌آید:

quicktest: (groupid=0, jobs=1): err= 0: pid=2841
  read: IOPS=118k, BW=460MiB/s (482MB/s)(6899MiB/15001msec)
    slat (nsec): min=1500, max=98000, avg=2400.11
    clat (usec): min=45, max=2210, avg=268.55, stdev=91.30
     lat (usec): min=48, max=2213, avg=271.02, stdev=91.35
    clat percentiles (usec):
     |  1.00th=[  135], 50.00th=[  260], 95.00th=[  420],
     | 99.00th=[  545], 99.90th=[  865], 99.99th=[ 1418]

IOPS تعداد عملیات در ثانیه است؛ اینجا ۱۱۸ هزار، یعنی در کلاس NVMe. clat تأخیر تکمیل هر عملیات برحسب میکروثانیه است. اما مهم‌ترین بخش سطر درصدک‌هاست: میانه ۲۶۰ میکروثانیه است، ولی 99.99th می‌گوید یکی از هر ده هزار درخواست ۱۴۱۸ میکروثانیه طول کشیده. کاربر میانگین را حس نمی‌کند، دُم توزیع را حس می‌کند.

یک محاسبه کمک می‌کند خروجی را باور کنید: میانگین تأخیر تقریباً برابر است با عمق صف تقسیم بر IOPS — ۳۲ تقسیم بر ۱۱۸٬۰۰۰ می‌شود حدود ۲۷۱ میکروثانیه، همان عدد سطر lat. برای سنجش تأخیر خالص، تست را با عمق صف یک تکرار کنید:

fio --name=lat --filename=fio-test --size=256M --rw=randread --bs=4k \
    --iodepth=1 --ioengine=psync --direct=1 --runtime=15 --time_based
rm fio-test

میانگین clat زیر ۲۰۰ میکروثانیه نشانه‌ی دیسک NVMe سالم است، حدود یک میلی‌ثانیه بوی SATA می‌دهد و چند میلی‌ثانیه یعنی هارد مکانیکی یا استوریج شبکه‌ای پرتأخیر. تست را در دو ساعت متفاوت تکرار کنید؛ تفاوت زیاد بین ظهر و نیمه‌شب خودش گویاترین نتیجه است.

سرور کند است؛ تقصیر CPU است، رم است یا دیسک؟

پیش از عوض‌کردن سرور، گلوگاه واقعی را پیدا کنید:

نشانهعلت محتملدستور بررسی
سایت در ساعت‌های خاصی کند می‌شودرقابت بر سر CPU روی میزبانvmstat 1 و نگاه به ستون st
مصرف CPU پایین است ولی همه‌چیز کندانتظار برای ورودی/خروجی دیسکستون wa در vmstat و iostat -x 1
پروسه‌ها کشته می‌شوند در حالی که رم خالی استسقف حافظه‌ی کانتینر یا OOM killerdmesg -T | grep -i oom
ایمپورت دیتابیس بی‌پایان طول می‌کشدکندی نوشتن با fsyncتست fio با --rw=randwrite --fsync=1 --iodepth=1
IOPS در ساعات شلوغ نصف می‌شودسقف‌گذاری یا همسایه‌ی پرمصرف روی استوریجتکرار همان تست fio در ساعات مختلف
شبکه سریع است ولی TTFB بالاستگلوگاه در PHP یا کوئری، نه دیسکcurl -w '%{time_starttransfer}\n' -o /dev/null -s https://example.ir/

iostat بخشی از بسته‌ی sysstat است و خواندن خروجی‌اش یک تله دارد: ستون %util فقط روی دستگاه‌هایی که درخواست‌ها را پشت سر هم اجرا می‌کنند معنای اشباع می‌دهد. روی SSD و NVMe که چند صف موازی دارند، این ستون می‌تواند صد درصد باشد بی‌آنکه دیسک به سقفش رسیده باشد — هشداری که در راهنمای خود iostat هم آمده. معیار درست‌تر، ستون‌های تأخیر (r_await و w_await) و طول صف (aqu-sz) است.

NVMe کجا معجزه نمی‌کند؟

NVMe فقط وقتی تفاوت محسوسی می‌سازد که گلوگاه شما دیسک باشد. سه موقعیت رایج هست که ارتقای دیسک در آن‌ها هیچ چیزی را عوض نمی‌کند.

اول، وقتی داده‌ی فعال در رم جا می‌شود. لینوکس هر چیزِ خوانده‌شده را در کش صفحه نگه می‌دارد؛ با دیتابیس دو گیگابایتی روی سرور هشت گیگابایتی تقریباً همه‌ی خواندن‌ها از رم پاسخ می‌گیرند و گلوگاه واقعی سرعت تک‌هسته‌ی پردازنده است.

دوم، وقتی زمان پاسخ صرف پردازش می‌شود نه خواندن. صفحه‌ای با سی افزونه‌ی وردپرس و یک کوئری بدون ایندکس، روی سریع‌ترین دیسک دنیا هم کند است؛ راه‌حل آنجا کش و اصلاح کوئری است — همان چیزهایی که در راهنمای افزایش سرعت وردپرس آمده.

سوم، وقتی مشکل فاصله‌ی شبکه است. اگر بازدیدکننده در ایران و سرور در اروپا باشد، هر رفت‌وبرگشت بسته ده‌ها میلی‌ثانیه هزینه دارد و هیچ دیسکی جبرانش نمی‌کند؛ آنجا محل سرور و شبکه توزیع محتوا اثر دارد. اول اندازه بگیرید، بعد خرج کنید.

چک‌لیست خریدار: قبل از پرداخت این ۷ مورد را بپرسید

  1. نوع مجازی‌سازی صریح نوشته شده؟ کلمه‌ی «KVM» را در مشخصات پیدا کنید؛ «سرور مجازی پرقدرت» بدون ذکر تکنولوژی، علامت سؤال است.
  2. رم اختصاصی است یا burst؟ در KVM جواب پیش‌فرض «اختصاصی» است؛ در OpenVZ حتماً بپرسید.
  3. دیسک دقیقاً چیست؟ اگر فقط نوشته «SSD»، به احتمال زیاد SATA است. NVMe را با اسم می‌نویسند، چون مزیت رقابتی است.
  4. سقف IOPS اعلام شده است؟ وجود سقف بد نیست و نشانه‌ی مدیریت منصفانه‌ی استوریج است؛ نبودِ هر عددی یعنی هیچ تعهدی هم نیست.
  5. می‌توانید ارزان تست کنید؟ بزرگ‌ترین مزیت پرداخت ساعتی همین است: در مهران هاست می‌توانید یک سرور KVM با دیسک NVMe بسازید، همین دستورها را اجرا کنید و اگر اعداد راضی‌تان نکرد، سرور را حذف کنید — کل هزینه‌ی آزمایش، چند ساعت است نه یک ماه. فقط بدانید خاموش‌کردن سرور نرخ ساعتی را کم می‌کند اما صفر نمی‌کند؛ ساعت‌شمار فقط با حذف سرور می‌ایستد.
  6. مسیر ارتقا روشن است؟ بپرسید افزایش منابع چطور انجام می‌شود و آیا کاهش بعداً ممکن است — در بیشتر پلتفرم‌ها کاهش دیسک ممکن نیست.
  7. بعد از تحویل، حرف فروشنده را چک کنید. systemd-detect-virt، lsblk و یک اجرای پانزده‌ثانیه‌ای fio روی هم کمتر از دو دقیقه وقت می‌گیرند.

KVM و NVMe در مهران هاست چطور ارائه می‌شود؟

سرور ابری مهران هاست ماشین KVM با دیسک NVMe در دیتاسنتر ایران است و صورتحساب آن ساعتی از کیف پول کسر می‌شود. ساخت آن خودکار است: منابع و سیستم‌عامل را انتخاب می‌کنید و ماشین معمولاً در کمتر از یک دقیقه با دسترسی کامل root تحویل داده می‌شود.

در پنل فارسی هر سرور چند بخش دارد: نمای کلی با مصرف لحظه‌ای منابع، روشن/خاموش و ریبوت، کنسول تحت وب VNC که حتی وقتی SSH خراب شده کار می‌کند، بازسازی سیستم‌عامل (با تأیید تایپی)، ارتقاء منابع و پشتیبان‌گیری. دو نکته هنگام خرید مهم‌اند: منابع فقط افزایش‌پذیرند و کاهش — به‌ویژه دیسک — ممکن نیست؛ و پشتیبان‌گیری افزودنی جداست که هزینه‌ی ماهانه‌اش ساعتی محاسبه می‌شود و سقف مشخصی برای تعداد نسخه‌ها دارد.

سرور در دیتاسنترهای هتزنر با پرداخت ریالی هم سفارش‌پذیر است و اگر پروژه‌تان سرور اختصاصی لازم ندارد، هاست اشتراکی روی cPanel و DirectAdmin ساده‌تر است.

حالا که می‌دانید مجازی‌سازی KVM چیست و پشت اعداد IOPS چه خبر است، هیچ برگه‌ی مشخصاتی گیجتان نمی‌کند: KVM یعنی منابع واقعی، NVMe یعنی دیسکی که دیتابیس را معطل نمی‌کند و fio یعنی ابزاری که هر دو ادعا را در پانزده ثانیه می‌سنجد. برای محک‌زدن یک سرور ساعتی بسازید و همین دستورها را اجرا کنید؛ مدل پرداخت ساعتی در راهنمای سرور ابری ساعتی توضیح داده شده.

سؤالات پرتکرار

مجازی‌سازی KVM چیست و چه فرقی با کانتینر دارد؟

KVM یا Kernel-based Virtual Machine ماژولی داخل هسته‌ی لینوکس است که با کمک قابلیت‌های سخت‌افزاری پردازنده ماشین مجازی کامل می‌سازد؛ هر ماشین کرنل مستقل خودش را بوت می‌کند و رم برایش رزرو می‌شود. در مجازی‌سازی کانتینری مثل OpenVZ و LXC همه‌ی سرورها کرنل میزبان را به اشتراک می‌گذارند. نتیجه اینکه فقط روی KVM هر سیستم‌عاملی نصب می‌شود و ماژول کرنل هم بارگذاری می‌شود.

تفاوت NVMe و SSD معمولی در چیست؟

هر دو حافظه‌ی فلش‌اند و قطعه‌ی متحرک ندارند، اما با پروتکل متفاوتی حرف می‌زنند. SSD معمولی از رابط SATA استفاده می‌کند که برای هارد مکانیکی طراحی شده بود: یک صف فرمان با حداکثر ۳۲ فرمان و سقف حدود ۵۵۰ مگابایت بر ثانیه. NVMe مستقیم روی PCIe می‌نشیند و تا ۶۵٬۵۳۵ صف موازی را مجاز می‌داند — و برای وب‌سروری با ده‌ها درخواست کوچک هم‌زمان، همین موازی‌بودن از پهنای باند مهم‌تر است.

چطور بفهمم سرور مجازی من KVM است یا کانتینر؟

دستور systemd-detect-virt را روی سرور اجرا کنید: خروجی kvm یعنی ماشین مجازی کامل، lxc یا openvz یعنی کانتینر و none یعنی سرور فیزیکی. برای تأیید دوم خروجی lscpu را ببینید؛ روی ماشین KVM سطر Hypervisor vendor: KVM ظاهر می‌شود. هر دو در چند ثانیه اجرا می‌شوند.

چرا داخل سرور مجازی، دیسک با نام nvme دیده نمی‌شود؟

چون سیستم‌عامل مهمان یک دستگاه مجازی می‌بیند، نه دیسک فیزیکی میزبان. در بیشتر سرورهای KVM دیسک از طریق درایور virtio ارائه می‌شود و نامش vda یا sda است، حتی وقتی پشت آن NVMe واقعی نشسته باشد. پس نام دستگاه چیزی را اثبات یا رد نمی‌کند و تنها راه معتبر، اندازه‌گیری IOPS و تأخیر با ابزاری مثل fio است؛ خواندن SMART دیسک هم داخل چنین سروری ممکن نیست.

استیل‌تایم بالا یعنی چه و چه کاری باید بکنم؟

استیل‌تایم درصد زمانی است که پردازنده‌ی مجازی شما کار آماده داشته اما هایپروایزر هسته‌ی فیزیکی را به ماشین دیگری داده است؛ آن را در ستون st خروجی vmstat 1 می‌بینید. زیر یک درصد طبیعی است و بالای ده درصدِ پایدار یعنی میزبان شلوغ است. افزودن هسته‌ی مجازی این مشکل را حل نمی‌کند؛ چند روز اندازه بگیرید و در صورت تداوم موضوع را با ارائه‌دهنده مطرح کنید.

آموزش‌های مرتبط

آماده‌ی تمرین عملی هستید؟

سرور ابری ساعتی مهران هاست در ۶۰ ثانیه تحویل می‌شود — تمرین کنید و فقط بابت همان ساعت‌ها پرداخت کنید. هزینه را پیش از ثبت‌نام با محاسبه‌گر برآورد کنید.