تفاوت سرور ابری و سرور مجازی؛ هنگام انتخاب چه چیزهایی را بررسی کنیم؟

تفاوت سرور ابری و مجازی را نمی‌توان فقط از نام دو سرویس فهمید. سرور مجازی یا VPS یک ماشین مجازی با سیستم‌عامل و منابع تخصیص‌یافته است؛ «ابری» بیشتر به شیوه ارائه و مدیریت زیرساخت اشاره دارد. بنابراین یک VPS می‌تواند روی زیرساخت ابری ارائه شود. برای انتخاب، باید ببینید سرویس مشخصی که می‌خرید چگونه ارتقا پیدا می‌کند، در خرابی چه رفتاری دارد، چه هزینه‌هایی ایجاد می‌کند و مدیریت کدام بخش‌ها با شماست.

اگر یک سایت یا نرم‌افزار دارید، نقطه شروع مناسب، نیاز همان برنامه است. اگر چند سرویس مرتبط دارید یا ظرفیت شما مرتب تغییر می‌کند، امکانات مدیریت منابع و شبکه اهمیت بیشتری پیدا می‌کند. در هر دو حالت، توضیح فنی و تعهدات ارائه‌دهنده از برچسب «ابری» یا «مجازی» تصمیم‌سازتر است.

چرا VPS و Cloud همیشه دو گزینه جدا نیستند؟

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

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

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

مقایسه را بر اساس ویژگی قابل‌تحویل انجام دهید

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

ارتقای منابع با افزایش خودکار ظرفیت فرق دارد

افزایش RAM یا CPU یک ماشین، ارتقای عمودی است. اضافه‌کردن ماشین‌های بیشتر برای تقسیم کار، توسعه افقی است. روش دوم به آمادگی برنامه هم وابسته است؛ برای مثال، اگر فایل‌های کاربران فقط روی دیسک یک ماشین باشند، افزودن ماشین دوم به‌تنهایی مسئله توزیع درخواست‌ها را حل نمی‌کند.

پیش از خرید، برای یک تغییر مشخص پاسخ بگیرید: «اگر حافظه بیشتری بخواهم، چه مراحلی لازم است؟» ممکن است افزایش منابع با خاموشی، تغییر پلن یا انتقال ماشین همراه باشد. کاهش ظرفیت نیز لزوماً مسیر معکوس همان عملیات نیست؛ به‌ویژه کاهش اندازه دیسک می‌تواند محدودیت جداگانه داشته باشد.

در ابر آراد، در سناریوهای پشتیبانی‌شده امکان افزایش CPU و RAM با Hot Add بدون خاموش‌کردن سرور وجود دارد. پیش از برنامه‌ریزی ارتقا، سازگاری سناریوی خود و شرایط افزایش هر منبع را بررسی کنید؛ این قابلیت به معنای افزایش خودکار ظرفیت برنامه یا حذف همه محدودیت‌های ارتقا نیست.

پایداری را در سه سطح بررسی کنید

سلامت زیرساخت و بازیابی ماشین

از ارائه‌دهنده بپرسید در خرابی میزبان فیزیکی چه اتفاقی می‌افتد: ماشین چگونه و در چه شرایطی دوباره اجرا می‌شود؟ داده‌ها از کجا در دسترس قرار می‌گیرند؟ اگر سرویس توافق‌نامه سطح خدمت دارد، دامنه آن و روش اندازه‌گیری را بخوانید. تعهد دسترس‌پذیری زیرساخت، تضمین کارکرد بی‌وقفه کد یا پایگاه داده شما نیست.

ادامه کار برنامه هنگام اختلال

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

حفظ داده و امکان بازگردانی

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

مدل پرداخت را از الگوی مصرف جدا نکنید

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

برای مقایسه، دو وضعیت خودتان را برآورد کنید: یک ماه عادی و یک دوره پرترافیک. هزینه مدیریت، پشتیبان‌گیری و ظرفیت آماده برای رشد را هم در نظر بگیرید. سرویس ارزان‌تر زمانی انتخاب مناسبی است که نیاز عملیاتی را پوشش دهد؛ در مقابل، امکاناتی که استفاده نمی‌کنید الزاماً پرداخت بیشتر را توجیه نمی‌کنند.

کدام انتخاب برای پروژه شما منطقی‌تر است؟

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

در مثال فرضی دیگر، فروشگاهی که کمپین فروش برگزار می‌کند باید پیش از کمپین ظرفیت و گلوگاه‌هایش را آزمایش کند. اگر مشکل از پایگاه داده یا کد باشد، تغییر نام سرویس به «ابری» کافی نیست. اگر نیاز به اضافه‌کردن ماشین و تقسیم کار تأیید شود، قابلیت‌های شبکه و مدیریت چند ماشین در انتخاب وزن بیشتری می‌گیرند.

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

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