تفاوت سرور مجازی و سرور ابری و اختصاصی در عمل به سه پرسش برمیگردد: سختافزار زیر پای شما با چند نفر دیگر تقسیم میشود، مرز این تقسیم را چه چیزی نگه میدارد، و صورتحساب بر مبنای «داشتن» بسته میشود یا «مصرفکردن». بیشتر مقایسهها یا آنقدر کلیاند که به درد تصمیم نمیخورند، یا آنقدر فنی که آدم را گیجتر میکنند. اینجا هر سه مدل را با دستورهای واقعیِ تشخیص، جدول مقایسه و اقلام پنهان صورتحساب باز میکنیم و در پایان یک چارچوب تصمیمگیری ساده میدهیم تا بدانید پولتان را کجا بگذارید.
سرور مجازی (VPS) چیست و هایپروایزر چه میکند؟
اگر بخواهیم به پرسش «vps چیست» یک جواب یکخطی بدهیم: تکهای از یک سرور فیزیکی قدرتمند که با نرمافزار مجازیساز به یک سرور مستقل تبدیل شده است. سختافزار واقعی — پردازنده، رم و دیسک — در دیتاسنتر نصب است و یک لایهی نرمافزاری به نام Hypervisor آن را بین چند مشتری تقسیم میکند. هر مشتری سیستمعامل و دسترسی root کامل خودش را دارد و از دید نرمافزارها، صاحب یک ماشین کامل است.
کیفیت این تقسیمبندی به نوع مجازیسازی بستگی دارد. در مجازیسازی KVM — که استاندارد صنعت است — رم و هستههای پردازنده در سطح سختافزار ایزوله میشوند؛ یعنی همسایهی پرمصرف نمیتواند رم شما را «قرض» بگیرد. این پاسخِ عملی به پرسش «سرور مجازی چیست» است: ماشینی مستقل با منابع تضمینشده، روی سختافزاری مشترک.
KVM ماژولی داخل هستهی لینوکس است که از افزونههای سختافزاری پردازنده — Intel VT-x یا AMD-V — استفاده میکند؛ یعنی جداسازی حافظه در مدار پردازنده انجام میشود، نه با یک قرارداد نرمافزاری. در مقابل، خانوادهی دیگری از «سرور مجازی» در واقع کانتینر است — OpenVZ، Virtuozzo و LXC — که همهی مشتریها یک هستهی مشترک را اجرا میکنند: کرنل را نمیتوانید عوض کنید و بیشفروشی سادهتر است، چون منابع متعهدشده میتواند از منابع فیزیکی بیشتر باشد.
systemd-detect-virt
kvm
systemd-detect-virt --container
none
# exit=1
خروجی kvm یعنی ماشین مجازی کامل. اگر دستور دوم چیزی مثل lxc یا openvz برگرداند، شما روی کانتینر نشستهاید نه ماشین مجازی؛ و اگر دستور اول none چاپ کند و با کد خروج غیرصفر تمام شود، هیچ مجازیسازیای در کار نیست — یعنی سختافزار فیزیکی.
سرور ابری چیست و چه فرقی با VPS سنتی دارد؟
اینجا جایی است که بیشترین سوءتفاهم وجود دارد. از نظر فنیِ محض، یک cloud server هم غالباً همان ماشین مجازی KVM است؛ پس «سرور ابری چیست» و چرا اسم جدایی دارد؟ تفاوت در سه چیز است که هیچکدام داخل سرور نیست، بلکه دور آن است — و اختراع بازار هم نیست: سند مرجع NIST SP 800-145 رایانش ابری را با پنج ویژگی تعریف میکند که سهتایشان — سلفسرویس بنا به تقاضا، کشسانی سریع و سرویسِ اندازهگیریشده — همانهاییاند که VPS سنتی ندارد.
۱) مدل پرداخت
VPS سنتی را ماهانه یا سالانه اجاره میکنید؛ سرور ابری را بهاندازهی مصرف. کیف پول را شارژ میکنید و فقط ساعتهایی که سرور وجود دارد هزینه کسر میشود. برای محیط تست، پروژهی کوتاهمدت یا یادگیری، این یعنی چند برابر صرفهجویی.
۲) تحویل آنی و خودکار
در مدل سنتی، سفارش میدهید و منتظر میمانید تا کسی سرور را آماده کند. در مدل ابری، ساخت سرور یک عملیات خودکار است: سیستمعامل را انتخاب میکنید و کمتر از یک دقیقه بعد، آیپی و دسترسی SSH در دست شماست. حذف هم همینقدر ساده است — و از لحظهی حذف، هزینه صفر میشود. ارزش واقعی این خودکار بودن آنجاست که سرور را «مصرفشدنی» میکند نه «دارایی»: بهجای تعمیر یک ماشین نیمهجان، یکی تازه میسازید و قبلی را حذف میکنید.
۳) مقیاسپذیری
پیک فروش دارید؟ در VPS سنتی معمولاً باید پلن را برای کل دوره عوض کنید؛ در cloud server رم و پردازنده را از پنل زیاد میکنید و نرخ جدید از همان لحظه اعمال میشود. اما یک واقعیت را صادقانه بگوییم که در تبلیغها گم میشود: مقیاسپذیری عمودی معمولاً یکطرفه است. بزرگکردن ساده است، ولی کوچککردن دیسک تقریباً هیچجا ممکن نیست. پس اگر انتظار دارید بعد از پیک به پیکربندی قبلی برگردید، راه واقعی ساختن سرور دوم و پخش بار بین آنهاست، نه بزرگ و کوچک کردن یک ماشین.
خلاصه: «ابری» یک فناوری جادویی جدا نیست؛ همان مجازیسازی است بهعلاوهی صورتحساب مصرفی، تحویل آنی و انعطاف در منابع. سرورهای مهران هاست دقیقاً با همین منطق کار میکنند: KVM و دیسک NVMe در دیتاسنتر ایران، با کسر ساعتی از کیف پول ریالی.
سرور اختصاصی: کی واقعاً میصرفد؟
سرور اختصاصی (Dedicated) یعنی کل سختافزار فیزیکی مال شماست؛ نه Hypervisor در کار است و نه همسایه. این بیشترین توان خام و کاملترین کنترل را میدهد، اما بهایش را هم دارد: هزینهی ماهانهی چند برابری، زمان تحویل طولانیتر، و این واقعیت که ارتقای سختافزار یعنی باز کردن کیس، نه کلیک در پنل.
سرور اختصاصی وقتی انتخاب درستی است که حداقل یکی از اینها دربارهی شما صادق باشد:
- بار سنگین و دائمی — دیتابیسی که ۶۴ گیگ رم را واقعاً پر میکند، یا پردازشی که همهی هستهها را ۲۴ ساعته درگیر نگه میدارد؛
- الزامات خاص سختافزاری — کارت گرافیک، دیسکهای خاص، یا لایسنسهایی که به سختافزار فیزیکی گره خوردهاند؛
- الزامات انطباق — سیاستهایی که صراحتاً میگویند داده نباید روی زیرساخت اشتراکی باشد.
در عوض یک هزینهی پنهان دارد: خرابی سختافزار دیگر مسئلهی ارائهدهنده نیست، مسئلهی زمانِ شماست. سوختن یک ماژول رم یعنی کسی باید فیزیکی سراغ دستگاه برود، و تا آن لحظه شما پایین هستید. به همین دلیل RAID، دسترسی مدیریت خارج از باند (IPMI/iDRAC/iLO) و یک نسخهی پشتیبانِ آزموده اینجا اختیاری نیستند.
htop میبینند مصرف واقعیشان زیر ۲۰٪ است. قبل از پرداخت چند برابری، یک هفته روی سرور ابری بار واقعیتان را اندازه بگیرید؛ عدد، بهتر از حدس تصمیم میگیرد.تفاوت سرور مجازی و سرور اختصاصی در یک نگاه
این جدول سه گزینه را از زاویههایی مقایسه میکند که در عمل تصمیم شما را میسازند: هزینه، سرعت تغییر، رفتار در خرابی و توان خام.
| معیار | سرور مجازی سنتی | سرور ابری | سرور اختصاصی |
|---|---|---|---|
| هزینهی شروع | کم (ماهانه) | خیلی کم (ساعتی) | زیاد |
| مدل پرداخت | ماهانه/سالانه ثابت | بهاندازهی مصرف | ماهانه ثابت و سنگین |
| زمان تحویل | دقیقهها تا ساعتها | زیر یک دقیقه | ساعتها تا روزها |
| دو برابر کردن رم | تعویض پلن، معمولاً با مهاجرت | چند کلیک و یک ریاستارت | سفارش قطعه و مراجعهی فیزیکی |
| کوچککردن منابع | تعویض پلن | رم و CPU معمولاً بله، دیسک خیر | عملاً بیمعنا |
| ایزوله بودن | در سطح KVM | در سطح KVM | کامل (سختافزار مجزا) |
| هنگام خرابی سختافزار | وابسته به سیاست میزبان | معمولاً جابهجایی روی نود سالم | انتظار تا تعویض فیزیکی قطعه |
| دسترسی هنگام قطعی شبکه | معمولاً کنسول مجازی | کنسول از پنل | نیازمند IPMI/iLO |
| توان خام | خوب، متناسب با پلن | خوب، قابلرشد | حداکثری |
| مناسب برای | سایت با بار ثابت | اغلب پروژهها، بار متغیر، تست | بار سنگین دائمی، سختافزار خاص |
چطور بفهمم همین حالا روی کدامیک نشستهام؟
پیش از هر مقایسهای وضعیت فعلی را قطعی کنید. سه دستور کوتاه، بعد از اتصال با SSH، هر ادعایی را که در صفحهی فروش خواندهاید راستیآزمایی میکند:
lscpu | grep -Ei '^(hypervisor|virtualization|model name|cpu\(s\))'
CPU(s): 4
Model name: AMD EPYC-Rome Processor
Hypervisor vendor: KVM
Virtualization type: full
سطر Hypervisor vendor فقط روی ماشین مجازی ظاهر میشود و مقدار full یعنی مجازیسازی کامل — همان چیزی که KVM میدهد. حالا دیسک و رم:
lsblk -d -o NAME,ROTA,SIZE
NAME ROTA SIZE
sda 0 76.3G
sr0 1 1024M
free -h
total used free shared buff/cache available
Mem: 7.3Gi 3.3Gi 485Mi 126Mi 3.6Gi 3.6Gi
Swap: 8.0Gi 1.6Gi 6.4Gi
ستون ROTA یعنی «چرخان»: مقدار 0 دیسک غیرچرخان (SSD یا NVMe) است و 1 هارد مکانیکی. در خروجی رم هم ستونی که باید بخوانید available است نه free؛ لینوکس رم بلااستفاده را عمداً کش میکند و free پایین نشانهی کمبود نیست. تفسیر کامل این اعداد در آموزش مانیتورینگ سرور لینوکس آمده است.
پیش از انتخاب، مصرف واقعی خودتان را اندازه بگیرید
بیشترِ پولی که در این بازار هدر میرود، بابت منابعی است که هرگز مصرف نمیشوند. یک هفته اندازهگیری، ارزانترین مشاورهای است که میتوانید بخرید. سه عدد را دنبال کنید.
Load average. دستور uptime میانگین بار یک، پنج و پانزده دقیقه را میدهد و معیار سنجشش تعداد هستههای شماست: روی سرور چهارهستهای، بار پایدارِ ۴ یعنی پردازنده دقیقاً اشباع است و بار ۰٫۲۵ یعنی حدود شش درصد ظرفیت.
Steal time. مهمترین عدد در بحث سرور مجازی. طبق مستند proc این فیلد «زمانی است که در محیط مجازی صرف سیستمعاملهای دیگر شده» — مدتی که هستهی مجازی شما آمادهی کار بوده اما هایپروایزر پردازندهی فیزیکی را به کس دیگری داده. ستون st در خروجی vmstat همین است — در نسخههای تازهی procps-ng یک ستون gu هم بعد از آن آمده، پس ستون را با نامش پیدا کنید نه با جایگاهش:
vmstat 1 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 1718016 497208 96064 3653092 0 1 22 17 5 5 3 1 96 0 0
0 0 1718016 498020 96064 3653100 0 0 0 0 1696 2151 4 1 95 0 0
1 0 1718016 498556 96064 3653100 0 0 60 0 1611 2023 4 1 95 0 0
روی سرور سالم این عدد صفر یا نزدیک صفر میماند؛ اگر پایدار دو رقمی شد، پول یک هسته را دادهاید و کسری از آن را نمیگیرید — همان چیزی که «بیشفروشی» نام دارد. ستون wa هم درصد زمانی است که پردازنده منتظر دیسک نشسته؛ عدد بالای پایدار در آن یعنی گلوگاه شما دیسک است نه CPU، و پاسخش خریدن هستهی بیشتر نیست. تستهایی که اورسل را مستند میکند در ۹ تست عملی سنجش کیفیت سرور آمده است.
اوج مصرف، نه میانگین. آنچه اندازهی سرور را تعیین میکند بدترین ساعت هفته است. اگر شنبهها ساعت ده صبح رم به سقف میخورد و بقیهی هفته نصف است، یا سرور را با همان ساعت اندازه بگیرید یا فقط همان ساعتها ظرفیت اضافه بگیرید — کاری که مدل ساعتی ارزان میکند و مدل ماهانه گران.
هزینهی واقعی: نقطهی سربهسر و اقلام پنهان صورتحساب
مقایسهی «قیمت ساعتی» با «قیمت ماهانه» بدون حسابوکتاب بیمعناست. فرمول ساده است و روی هر ارائهدهندهای کار میکند:
break-even hours = monthly price / hourly price
اگر تعداد ساعتهایی که سرور واقعاً باید روشن باشد کمتر از این عدد است، مدل ساعتی ارزانتر تمام میشود. برای سروری که ۲۴ ساعته بالاست دو مدل به هم میرسند و ملاک انتخاب دیگر قیمت نیست، بلکه انعطاف است؛ محاسبه با الگوهای مصرف مختلف در مقایسهی سرور ساعتی و ماهانه آمده است. اما تلهی اصلی جای دیگری است: قیمتِ صفحهی فروش همهی صورتحساب نیست.
- ترافیک. چه مقدار در ماه رایگان است و بعد هر گیگابایت چند؟ در بعضی مدلها فقط ترافیک خروجی حساب میشود و در بعضی هر دو جهت.
- آیپی اضافه. معمولاً هزینهی جداگانه دارد و گاهی حداقل دورهی نگهداری، یعنی پسدادن سریعش ممکن نیست.
- پشتیبانگیری خودکار. تقریباً همیشه افزودنی جدا با هزینهی مستقل است، نه بخشی از پلن پایه.
- لایسنس. ویندوز و کنترلپنل تجاری روی صورتحساب سوارند و در مقایسهی «فقط سختافزار» دیده نمیشوند.
- سرور خاموش. خاموشکردن هزینه را صفر نمیکند؛ دیسک و آیپی همچنان رزرو است. چیزی که هزینه را صفر میکند حذف سرور است.
روی سرور اختصاصی یک قلم دیگر هم هست که در فاکتور نمیآید: زمان شما — پایش سلامت دیسکها، تعویض قطعه و هماهنگی با دیتاسنتر.
کدام مدل کمتر میخوابد؟ واقعیت دربارهی پایداری
یک باور غلط رایج این است که «ابری یعنی همیشه بالا». نه — یک ماشین مجازی ابری هم مثل هر سرور دیگری یک تکنقطهی خرابی است. آنچه ابر میدهد ابزارِ ساختنِ افزونگی است، نه خودِ افزونگی؛ و تفاوت واقعی سه مدل در زمان بازگشت است، نه در احتمال خرابی:
- روی زیرساخت مجازی، خرابی سختافزار میزبان معمولاً با راهاندازی مجدد ماشین روی نود سالم جمع میشود و شما یک ریاستارت غیرمنتظره میبینید.
- روی سرور فیزیکی، همان خرابی یعنی انتظار برای مداخلهی انسانی در دیتاسنتر — ساعتها، و اگر قطعه موجود نباشد بیشتر.
- در هر دو حالت، خرابیِ سطح اپلیکیشن — دیسک پر، حافظهی تمامشده، کانفیگ خراب — ربطی به نوع سرور ندارد و وظیفهی شماست.
اگر واقعاً به دسترسپذیری بالا نیاز دارید، پاسخ در نام پلن نیست؛ در معماری است: دو سرور در دو نقطه و سازوکاری که مقصد خراب را از چرخه خارج کند — در سطح DNS با چند رکورد A زیر یک نام و بررسی سلامت.
همسایهی پرمصرف، ایزولهسازی و امنیت
پرسش قدیمی «آیا همسایه میتواند به من آسیب بزند؟» جواب دقیقتری از بله و خیر دارد. در KVM رم شما در سطح سختافزار جدا شده و همسایه نمیتواند آن را بگیرد یا بخواند. اما سه منبع ذاتاً مشترک میمانند و کیفیت مدیریت میزبان تعیین میکند چقدر منصفانه تقسیم شوند: زمان پردازنده که اثرش را در همان steal time میبینید، ورودی/خروجی دیسک که در ستون wa ظاهر میشود، و پهنای باند پورت نود.
سرور اختصاصی هر سه را حذف میکند و برای الزامات انطباقی که زیرساخت اشتراکی را رد میکنند تنها گزینه است. اما روراست باشیم: نفوذهایی که به سرورهای ایرانی میبینیم تقریباً هرگز از راه همسایه نیست — از راه رمز ضعیف SSH، افزونهی بهروزنشده و پورت بازِ فراموششده است، و سرور اختصاصی هیچکدام را درمان نمیکند. در هر سه مدل، امنیت سرور لینوکس وظیفهی خود شماست.
چارچوب تصمیمگیری: سه سؤال بپرسید
- بار من دائمی است یا متغیر؟ اگر مصرف در طول شبانهروز و ماه بالا و پایین میرود، مدل ابری تقریباً همیشه برنده است. اگر بار، سنگین و یکنواخت است، بین VPS بزرگ و اختصاصی مقایسهی قیمت کنید — با همهی اقلام پنهان بالا، نه فقط عدد درشت صفحهی فروش.
- آیا منابع یک سرور فیزیکی کامل را واقعاً پر میکنم؟ تا وقتی جواب «نه» است، تفاوت سرور مجازی و سرور اختصاصی برای شما عمدتاً تفاوت قیمت است، نه کارایی؛ ایزولهسازی KVM همان تضمین منابع را با هزینهی بسیار کمتر میدهد. معیار «پر کردن» هم حدس نیست: بار پایدار نزدیک به تعداد هستهها، و available رمی که مدام ته میکشد.
- چقدر به سرعت تغییر نیاز دارم؟ اگر امروز نمیدانید سه ماه دیگر چه منابعی لازم دارید — که برای پروژههای در حال رشد طبیعی است — گزینهای را بگیرید که تغییرش چند کلیک باشد، نه چند روز. هزینهی اشتباه در مدل ساعتی چند ساعت اجاره است؛ در مدل اختصاصی، یک قرارداد.
جمعبندی صادقانه: برای اکثریت قاطع سایتها، اپلیکیشنها و پروژههای در حال رشد، سرور ابری نقطهی شروع درست است؛ اختصاصی را وقتی بخرید که دادهی مصرف واقعی، لزومش را نشان داده باشد. اشتباهبودن این تصمیم هم فاجعه نیست: مهاجرت بین سه مدل تقریباً یکسان است، چون آنچه جابهجا میشود داده و پیکربندی است نه ماشین — ترتیب درست کار در راهنمای انتقال سایت بدون قطعی آمده است. و اگر هنوز روی هاست اشتراکی هستید و مطمئن نیستید وقت مهاجرت رسیده یا نه، نشانههای عبور از هاست اشتراکی نقطهی شروع بهتری از این مقایسه است.
در مهران هاست چه چیزی هست و چه چیزی نیست
از این سه مدل، آنچه امروز خودکار و از خود سایت قابل سفارش است میزبانی وب اشتراکی روی cPanel یا DirectAdmin و سرور ابری KVM با دیسک NVMe است — در دیتاسنتر ایران، با تحویل خودکار و کسر ساعتی از کیف پول ریالی. برای مخاطب خارج از کشور هم سرور ابری در دیتاسنترهای هتزنر با همان کیف پول سفارش داده میشود.
سرور فیزیکی اختصاصی (Bare Metal) امروز بهصورت پلن آماده ارائه نمیشود. اگر بار شما واقعاً به سختافزار اختصاصی نیاز دارد، مسیر درست صفحهی راهکار سازمانی است تا در یک گفتگو مشخص شود چه چیزی و با چه زمانبندی قابل تأمین است — این را ترجیح میدهیم به گذاشتن چیزی در جدول قیمت که پشتش ظرفیت آماده نیست.
روی خود سرور ابری هم چند نکته را صادقانه بدانید. تغییر منابع از پنل فقط افزایشی است: رم، پردازنده و دیسک را میشود بالا برد و نرخ جدید از همان لحظه اعمال میشود، برای اعمال کامل فضای دیسک باید یک بار ریاستارت کنید، و کاهش منابع — بهویژه دیسک — ممکن نیست. پشتیبانگیری خودکار افزودنی جداست که خودتان روشنش میکنید و ساعتی حساب میشود، و بازگردانی نسخه چون کل دیسک را بازنویسی میکند از طریق تیکت انجام میشود. آیپی اضافه هم تا دو هفته پس از خرید قابل حذف نیست.
در مقابل، سه چیز کار را راحت میکند: نمودار مصرف پردازنده و رم و ترافیک روزانه داخل پنل هست، پس همان اندازهگیریای که توصیه کردیم را از صفر نمیسازید؛ کنسول گرافیکی (VNC) داخل همان پنل باز میشود و حتی وقتی شبکهی سرور قطع است کار میکند — همان نقش IPMI روی سرور فیزیکی؛ و اگر DNS دامنهتان اینجا مدیریت شود، کنار هر رکورد A یک کلید CDN هست که آیپی مبدأ را پنهان میکند و ترافیک را از نودهای لبه در ایران، اروپا و آمریکا سرو میکند، بدون هزینهی جداگانه.
سؤالات پرتکرار
تفاوت سرور مجازی و سرور ابری و اختصاصی در یک جمله چیست؟
سرور مجازی تکهای ایزوله از یک سرور فیزیکی است که ماهانه اجاره میشود؛ سرور ابری از نظر فنی همان ماشین مجازی است اما با تحویل خودکار، تغییر منابع در چند کلیک و صورتحساب بر مبنای ساعت مصرف؛ و سرور اختصاصی یعنی کل سختافزار فقط مال شماست، با بیشترین توان خام، بیشترین هزینه و کندترین تغییر. انتخاب را الگوی بار و سرعت تغییر تعیین میکند، نه قدرت خام.
آیا سرور مجازی از سرور اختصاصی کندتر است؟
روی سختافزار همرده و با مجازیسازی KVM سربار معمولاً چند درصد بیشتر نیست، چون جداسازی حافظه و پردازنده با کمک افزونههای سختافزاری خود پردازنده انجام میشود. کندیهایی که به اسم «مجازی بودن» شناخته میشوند تقریباً همیشه نتیجهی پلن کوچک، دیسک کند یا میزبان بیشفروشیشدهاند. راه تشخیص عددی است: ستون steal time در خروجی vmstat اگر پایدار دو رقمی باشد، مشکل از میزبان است نه از فناوری.
فرق سرور ابری و سرور مجازی فقط اسم است؟
نه. فناوری زیرین میتواند یکسان باشد، اما تجربه فرق میکند: پرداخت مصرفی بهجای اجارهی ثابت، ساخت و حذف آنی بهجای انتظار، و تغییر منابع بدون جابهجایی. سند مرجع NIST هم رایانش ابری را با همین ویژگیها تعریف میکند: سلفسرویس بنا به تقاضا، کشسانی سریع و سرویس اندازهگیریشده. اگر ارائهدهندهای فقط اسم پلنهایش را «ابری» گذاشته ولی این ویژگیها را ندارد، در واقع همان VPS سنتی را میفروشد.
خاموشکردن سرور ابری هزینه را صفر میکند؟
خیر. در تقریباً همهی ارائهدهندهها سرور خاموش همچنان دیسک، آیپی و جای رم را روی نود اشغال میکند و بخش عمدهی صورتحساب سر جایش میماند؛ چیزی که هزینه را واقعاً صفر میکند حذف سرور است. پس اگر الگوی کار شما «چند روز روشن، چند هفته خاموش» است، روش درست گرفتن یک نسخهی پشتیبان کامل و حذف سرور است و ساختن دوبارهاش هنگام نیاز.
میشود از سرور ابری شروع کرد و بعداً به اختصاصی مهاجرت کرد؟
بله و این مسیر پیشنهادی است. روی سرور ابری راه بیفتید، یک تا دو هفته مصرف واقعی را ثبت کنید و اوج مصرف را ملاک بگیرید نه میانگین را. اگر داده نشان داد به سقف یک ماشین رسیدهاید، مهاجرت سختی ندارد: سرور مقصد را کامل بالا میآورید، داده را با rsync و دامپ دیتابیس منتقل میکنید، پیش از تغییر DNS با فایل hosts تست میکنید و TTL را یک روز قبل پایین میآورید.