تفاوت سرور مجازی و اختصاصی؛ کی باید مهاجرت کنی

ساعت دو نیمه‌شب است، صفحه کند بالا می‌آید، و تو همین هفته رم و هسته‌ی سرور مجازی را یک پله برده‌ای بالا. فرق محسوسی نکرد. حالا می‌پرسی آیا به سقف «مجازی» رسیده‌ای و باید سراغ سرور اختصاصی بروی.

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

یک جدول مرجع، قبل از جزئیات

هر ردیف یک نشانه است، دستوری که اندازه‌اش می‌گیرد، و آستانه‌ای که یعنی روی سخت‌افزار مشترک به تنگنا خورده‌ای.

نشانهدستورعددی که یعنی وقتش رسیده
فشار همسایه روی CPU	`top` / `mpstat -P ALL`	ستون `st` دو رقمی و پایدار بیش از ۲۰ دقیقه
دیسک مشترک ناپایدار	`fio` 4k randread + `iostat -x`	نوسان IOPS دو تا سه برابر، `await` بالا، `%util` نزدیک ۱۰۰
دیتابیس بزرگ‌تر از رم	`vmstat 1`، hit ratio دیتابیس	`si`/`so` پیوسته بالای چند صد کیلوبایت بر ثانیه؛ hit ratio زیر ۹۵٪
مجازی‌سازی تودرتو	`ls /dev/kvm`، پرچم‌های CPU	نبود `/dev/kvm` یا خروجی `N`

نشانه ۱: steal time بالا یعنی داری بهای همسایه را می‌دهی

وقتی هسته‌ی مجازی‌ات آماده‌ی اجراست ولی هایپروایزر پردازنده‌ی فیزیکی را به مهمان دیگری داده، آن زمان به‌عنوان «steal» ثبت می‌شود. تعریف top دقیقاً همین است: زمانی که هایپروایزر از ماشین مجازی می‌دزدد (به‌نقل از opensource.com). این مستقیم‌ترین اثر قابل‌اندازه‌گیری «همسایه‌ی پرمصرف» روی یک میزبان مشترک است.

ببینش:

top -bn1 | grep '%Cpu'

یک خروجی نمونه:

%Cpu(s): 2.1 us, 0.5 sy, 0.0 ni, 88.2 id, 0.0 wa, 0.0 hi, 0.0 si, 9.2 st

آن 9.2 st یعنی حدود ۹ درصد زمان، هسته‌ی مجازی‌ات منتظر مانده چون هسته‌ی فیزیکی دست کسی دیگر بوده. برای دیدن توزیع روی هسته‌ها و دنبال‌کردن در زمان:

mpstat -P ALL 2 5

به ستون %steal نگاه کن. vmstat 1 5 هم همین عدد را در ستون آخر (st) می‌دهد.

قاعده‌ی عملی: st تک‌رقمیِ گذرا عادی است. st دو رقمی که بیش از بیست دقیقه ثابت بماند، در حالی که اپ کند است، یعنی پردازنده‌ات را همسایه‌ها می‌بلعند. opensource.com آستانه‌ی عددی نمی‌دهد ولی نشانه‌ی مکمل را می‌گوید: در steal بالا هیچ‌کدام از vCPUها به نزدیک ۱۰۰٪ نمی‌رسند.

این نشانه چه چیزی را رد می‌کند؟ اگر st نزدیک صفر بود ولی اپ باز هم کند است، مشکلت رقابت همسایه بر سر CPU نیست. سراغ دیسک یا رم برو، نه سخت‌افزار جدید.

نکته‌ای که اغلب از قلم می‌افتد: راه‌حل همیشه پرش به یک باکس اختصاصی نیست. روی یک پلن با هسته‌ی اختصاصی، steal باید نزدیک صفر بماند چون هسته‌ها بین مهمان‌ها تقسیم نمی‌شوند. اگر فقط مشکل CPU داری، ارتقا به یک پلن هسته‌اختصاصی در سرور مجازی انگلستان steal را حذف می‌کند و کسری از هزینه‌ی سرور اختصاصی است.

نشانه ۲: IOPS ناپایدار، نه فقط کند

دیسک کند یک چیز است، دیسک ناپایدار چیز دیگر. روی ذخیره‌سازی مشترک، همسایه‌ی پرمصرف باعث می‌شود IOPS از ساعتی به ساعت دیگر نوسان کند. یک تست ثابت بگیر و در چند ساعت مختلف تکرارش کن.

fio --name=randread --ioengine=libaio --direct=1 --rw=randread \

--bs=4k --iodepth=32 --numjobs=1 --size=1G --runtime=60 \

--time_based --group_reporting

تست random read با بلوک 4k همان چیزی را شبیه‌سازی می‌کند که دیتابیس انجام می‌دهد: خواندن‌های کوچک و پراکنده. خروجی چیزی شبیه این است (اعداد نمونه‌اند، برای نشان‌دادن قالب):

read: IOPS=18.2k, BW=71.1MiB/s (74.6MB/s)

clat percentiles (usec):

| 50.00th=[ 260], 95.00th=[ 620], 99.00th=[ 1340]

دو عدد مهم‌اند: IOPS و درصدک ۹۹ تأخیر (clat 99.00th). همان تست را سه بار در ساعت‌های شلوغ و خلوت بگیر. اگر IOPS دو تا سه برابر بالا و پایین شد و p99 منفجر شد، روی دیسک مشترکِ پرازدحام نشسته‌ای. برای تأیید زنده:

iostat -x 1

به %util نگاه کن که نزدیک ۱۰۰ می‌ماند یا نه و به await (تأخیر هر درخواست بر حسب میلی‌ثانیه). %util بالا با await بالا یعنی صف دیسک پر است.

تفاوت با نشانه‌ی قبل: اگر st پایین است ولی await بالا و IOPS پرنوسان، گلوگاهت ذخیره‌سازی است نه پردازنده. اینجا یک پلن با دیسک NVMe اختصاصی‌تر جواب می‌دهد، و اگر نیاز به IOPS پایدار و تضمین‌شده حیاتی است، سرور اختصاصی صف دیسک را تنها مال تو می‌کند.

نشانه ۳: دیتابیس در رم جا نمی‌شود

وقتی مجموعه‌ی کاری دیتابیس از رم بزرگ‌تر شود، هر کوئری به دیسک می‌خورد و سرور شروع به swap می‌کند. اختلاف تأخیرِ خواندن از رم و از دیسک صد تا هزار برابر است. دو جا اندازه‌اش بگیر.

اول، فشار حافظه در سطح سیستم:

vmstat 1

ستون‌های si (swap-in) و so (swap-out) مقدار داده‌ای است که بین رم و swap جابه‌جا می‌شود. به‌گفته‌ی مرجع vmstat فدورا، مقدار کل swap مهم نیست، نرخ مهم است. اگر si و so پیوسته بالای چند صد کیلوبایت بر ثانیه بمانند، سیستم در حال thrashing است و رم برای نگه‌داشتن مجموعه‌ی کاری کم آورده.

دوم، در خود دیتابیس. برای MySQL/InnoDB نرخ برخورد buffer pool را بگیر:

SELECT (1 - (

SELECT VARIABLE_VALUE FROM performance_schema.global_status

WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads'

) / (

SELECT VARIABLE_VALUE FROM performance_schema.global_status

WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests'

)) * 100 AS hit_ratio_pct;

طبق راهنمای اندازه‌گذاری buffer pool در netdata، یک OLTP سالم باید بالای ۹۹٫۵٪ باشد؛ زیر ۹۵٪ یعنی buffer pool کوچک است. اگر hit ratio پایین است و بزرگ‌کردن innodb_buffer_pool_size دیگر جا ندارد چون رم کل سرور پر است، به عددی رسیده‌ای که سخت‌افزار باید حلش کند، نه کانفیگ.

اینجا تصمیم ساده می‌شود. اگر مجموعه‌ی کاری‌ات مثلاً ۴۰ گیگ است، در هیچ پلن سرور مجازی انگلستان (سقف رم ۱۲ گیگ در UK-P4) جا نمی‌شود. اینجا دقیقاً جایی است که یک سرور اختصاصی با ۱۲۸ یا ۲۵۶ گیگ رم ECC مسئله را از ریشه حل می‌کند؛ کل مجموعه‌ی کاری در رم می‌نشیند و دیسک از مسیر کوئری خارج می‌شود.

نشانه ۴: به مجازی‌سازی تودرتو نیاز داری

اگر می‌خواهی داخل سرور مجازی خودت هایپروایزر اجرا کنی (KVM تودرتو، Hyper-V، WSL2 ویندوز، یا بعضی اجراکننده‌های CI که ماشین مجازی می‌سازند)، باید مجازی‌سازی تودرتو در دسترس باشد. سه چیز را چک کن:

egrep -c '(vmx|svm)' /proc/cpuinfo

ls -l /dev/kvm

cat /sys/module/kvm_intel/parameters/nested # روی AMD: kvm_amd

دستور اول تعداد هسته‌هایی را می‌دهد که پرچم مجازی‌سازی (vmx اینتل یا svm ای‌ام‌دی) را می‌بینند؛ صفر یعنی مهیا نیست. دوم باید فایل دستگاه /dev/kvm را نشان دهد. سوم طبق راهنمای OSTechNix اگر Y یا 1 برگرداند یعنی تودرتو فعال است و N یا 0 یعنی خیر.

اینجا صادق باشیم: اگر داخل یک مهمان نشسته‌ای و /dev/kvm نیست یا پرچم‌ها دیده نمی‌شوند، از سمت تو قابل‌رفع نیست. فعال‌کردن مجازی‌سازی تودرتو تصمیم میزبان است، نه مهمان. وقت‌ات را صرف دستکاری کانفیگ داخل ماشین نکن. این یک نشانه‌ی سختِ عبور به سخت‌افزار واقعی است، چون روی یک سرور اختصاصی لایه‌ی هایپروایزر مال خودت است و می‌توانی هر طور خواستی مجازی‌سازی را سوار کنی.

هزینه‌ی واقعی را کنار هم بگذار

حالا که عددها را داری، هزینه را هم با عدد مقایسه کن، نه با حس. این قیمت‌ها از صفحه‌ی همان محصول‌اند و ممکن است تغییر کنند؛ قبل از خرید صفحه را ببین.

گزینهمشخصاتقیمت ماهانه
UK-D2 (هسته اختصاصی)	۲ هسته اختصاصی، ۸ گیگ رم، ۱۰۰ گیگ NVMe	۱٬۹۹۰٬۰۰۰ تومان
UK-P4 (هسته اختصاصی)	۶ هسته اختصاصی، ۱۲ گیگ رم، ۶۰ گیگ NVMe	۲٬۰۰۰٬۰۰۰ تومان
سرور اختصاصی UK (Plan 3)	۴۰ هسته / ۸۰ ترد، ۱۲۸ گیگ رم ECC، ۲ ترابایت NVMe	۵۰٬۰۰۰٬۰۰۰ تومان

فاصله زیاد است. پرش از یک سرور مجازی هسته‌اختصاصی به یک سرور اختصاصی کامل حدود بیست‌وپنج برابر هزینه دارد. برای همین بیشترِ پرونده‌های «از سرور مجازی عبور کرده‌ام» با مهاجرت از هسته‌ی اشتراکی به هسته‌ی اختصاصی حل می‌شوند، نه با یک باکس اختصاصی. عددها را خواندی: اگر فقط steal بالاست، یک پلن هسته‌اختصاصی کافی است. سرور اختصاصی وقتی صرف می‌کند که رمِ بیش از ۱۲ گیگ، دیسک چندترابایتی، یا مجازی‌سازی تودرتو لازم داری.

کدام را انتخاب کنم

قاعده‌ی تصمیم ساده است. اگر st پایین و await پایین است و اپ فقط به رم یا هسته‌ی بیشتر نیاز دارد، در خانواده‌ی مجازی بمان و یک پلن هسته‌اختصاصی در سرور مجازی انگلستان بگیر. اگر مجموعه‌ی کاری دیتابیس از رم هر پلن مجازی بزرگ‌تر است، IOPS تضمین‌شده می‌خواهی، یا مجازی‌سازی تودرتو لازم داری، آن‌وقت یک سرور اختصاصی با رم ECC بالا و NVMe اختصاصی پاسخ درست است. بگذار عددهای top، fio و vmstat تصمیم بگیرند، نه حدس شبانه.

منابع

پرسش‌های پرتکرار

تفاوت سرور مجازی و اختصاصی در یک جمله چیست؟

در سرور مجازی هسته و دیسک و گاهی رم بین چند مشتری روی یک میزبان تقسیم می‌شود، و در سرور اختصاصی کل سخت‌افزار فقط مال توست. اثر این فرق را با steal time، نوسان IOPS و فشار swap می‌توان اندازه گرفت.

چطور بفهمم همسایه‌ی پرمصرف دارد منابعم را می‌خورد؟

با دستور top یا mpstat -P ALL ستون st (steal) را ببین. اگر st دو رقمی و بیش از بیست دقیقه ثابت بماند در حالی که اپ کند است، پردازنده‌ات را مهمان‌های دیگر روی همان میزبان می‌بلعند. روی پلن هسته‌اختصاصی این عدد باید نزدیک صفر باشد.

چطور تست کنم که IOPS دیسکم پایدار است یا نه؟

با fio یک تست random read بلوک 4k بگیر و در چند ساعت مختلف تکرارش کن. اگر IOPS دو تا سه برابر نوسان کرد و درصدک ۹۹ تأخیر بالا رفت، روی ذخیره‌سازی مشترک پرازدحام هستی. با iostat -x هم %util و await را زنده ببین.

دیتابیسم بزرگ شده؛ سرور مجازی بزرگ‌تر بگیرم یا اختصاصی؟

اول با vmstat ستون‌های si/so و با کوئری hit ratio دیتابیس را چک کن. اگر hit ratio زیر ۹۵٪ است و مجموعه‌ی کاری از رمِ هر پلن مجازی بزرگ‌تر است، سرور اختصاصی با رم ECC بالا جواب می‌دهد. وگرنه ارتقای رم روی سرور مجازی کافی است.

آیا مهاجرت به سرور اختصاصی همیشه صرف می‌کند؟

نه. فاصله‌ی قیمت یک سرور مجازی هسته‌اختصاصی و یک سرور اختصاصی کامل چند ده برابر است. تنها وقتی صرف می‌کند که رم بیش از سقف پلن‌های مجازی، دیسک چندترابایتی، IOPS تضمین‌شده یا مجازی‌سازی تودرتو لازم داشته باشی.

سرور مجازی یا سرور اختصاصی؛ کِی نیاز به سرور اختصاصی هست