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

سرور ابری چیست؟ سرور ابری (Cloud Server) یک ماشین مجازی است که آن را از پلتفرم ابری یک ارائه‌دهنده، هر وقت لازم داشتید، خودتان می‌سازید، بزرگ یا کوچک می‌کنید یا حذف می‌کنید و معمولاً به اندازهٔ مدت استفاده هزینه‌اش را می‌دهید. این راهنما تعریف دقیق، تفاوت با سرور مجازی و اختصاصی، روش خواندن برگهٔ مشخصات و چک‌لیست خرید را یک‌جا توضیح می‌دهد.

واژهٔ «ابری» در بازار میزبانی معنای ثابتی ندارد و گاهی با ادعای «هیچ‌وقت قطع نمی‌شود» فروخته می‌شود. اینجا با تکیه بر تعریف رسمی و مستندات ارائه‌دهندگان بزرگ می‌بینید کدام ویژگی‌ها جزو تعریف‌اند و برای پروژهٔ شما چه چیزی کافی است.

به‌طور خلاصه: سرور ابری یعنی ماشین مجازی درخواستی از یک پلتفرم ابری، با سلف‌سرویس، معمولاً API و پرداخت بر اساس مصرف؛ از نظر فنی نوعی سرور مجازی است و تفاوت در امکانات پلتفرم است، نه در نام. محل دیسک، مهاجرت زنده (Live Migration)، Snapshot و رفتار هنگام خرابی میزبان در هر ارائه‌دهنده فرق می‌کند. یک سرور ابری تنها هم با خرابی ناگهانی میزبانش، دست‌کم تا روشن شدن دوباره، قطع می‌شود؛ دسترس‌پذیری بالا از طراحی چندسروری می‌آید. برای بیشتر سایت‌ها یک سرور مجازی با اندازهٔ درست کافی است و سرور ابری برای بار پرنوسان، سرورهای کوتاه‌مدت و خودکارسازی می‌ارزد.

سرور ابری چیست؟

سرور ابری ماشین مجازی‌ای است که خودتان، به‌صورت سلف‌سرویس، روی پلتفرم یک ارائه‌دهنده می‌سازید و مدیریت می‌کنید؛ معمولاً API دارد و بر اساس مصرف حساب می‌شود. این تعریف بر پایهٔ سند NIST SP 800-145 از مؤسسهٔ ملی استاندارد و فناوری آمریکا است که رایانش ابری را این‌طور تعریف می‌کند: مدلی برای دسترسی شبکه‌ای و درخواستی به استخری مشترک از منابع پیکربندی‌پذیر، مثل سرور، فضای ذخیره‌سازی و شبکه، که با کمترین کار مدیریتی یا تعامل با ارائه‌دهنده سریع تحویل داده و آزاد می‌شوند. پنج ویژگی اساسی این تعریف در سرور ابری این‌طور دیده می‌شود:

• سلف‌سرویس درخواستی (On-demand Self-service): سرور را خودتان از پنل یا API می‌سازید، بدون اینکه کارمند ارائه‌دهنده کاری انجام دهد.
• دسترسی گسترده از شبکه (Broad Network Access): سرور و پنلش از راه شبکه و با ابزارهای استاندارد در دسترس‌اند.
• استخر منابع (Resource Pooling): منابع چند سرور فیزیکی بین مشتریان زیادی تقسیم می‌شود و شما معمولاً فقط کشور یا دیتاسنتر را انتخاب می‌کنید، نه خود سرور فیزیکی را.
• کشسانی سریع (Rapid Elasticity): منابع سریع، و گاهی خودکار، اضافه و کم می‌شوند؛ مثلاً در چند دقیقه سرور تازه‌ای می‌سازید.
• سرویس اندازه‌گیری‌شده (Measured Service): مصرف اندازه‌گیری و گزارش می‌شود و معمولاً هزینه هم بر اساس همان گرفته می‌شود.

در مدل‌های خدمت NIST، سرور ابری زیرساخت به‌عنوان سرویس (IaaS) است: سیستم‌عامل و نرم‌افزارها با شماست و سخت‌افزار و لایهٔ مجازی‌سازی با ارائه‌دهنده؛ در PaaS فقط برنامهٔ خودتان را مستقر می‌کنید و در SaaS نرم‌افزار آماده را به کار می‌برید. تعریف NIST نمی‌گوید دیسک روی چند سرور تکرار شود، سرور هنگام خرابی خودکار جابه‌جا شود یا Snapshot داشته باشید؛ این‌ها امکانات پلتفرم هر ارائه‌دهنده‌اند. برخی ارائه‌دهندگان سرور فیزیکی را هم به همین شکل درخواستی می‌فروشند (Bare Metal)؛ موضوع این مقاله ماشین مجازی است.

سرور ابری چطور کار می‌کند؟

پشت هر سرور ابری چهار لایه هست:

1. میزبان‌ها (Hosts): سرورهای فیزیکی که با Hypervisor، مثل KVM، ماشین‌های مجازی را اجرا می‌کنند.
2. ذخیره‌سازی: دیسک محلی خود میزبان یا ذخیره‌ساز شبکه‌ای جدا.
3. شبکه: IP عمومی و اغلب شبکهٔ خصوصی بین سرورها، فایروال ابری و توزیع‌کنندهٔ بار (Load Balancer).
4. لایهٔ کنترل (Control Plane): نرم‌افزاری که درخواست پنل یا API را می‌گیرد، میزبانی با ظرفیت آزاد پیدا می‌کند، دیسک را از ایمیج (Image) سیستم‌عامل می‌سازد، ماشین را روشن می‌کند و کنتور صورت‌حساب را راه می‌اندازد.

در اولین بوت، ابزاری مثل cloud-init شبکه و کلید SSH را تنظیم می‌کند؛ کل مسیر خودکار است و سرور معمولاً چند دقیقه بعد از درخواست آماده می‌شود.

«ابری» یعنی «همیشه روشن» نیست

مستندات خود ارائه‌دهندگان نشان می‌دهد ادعای «اگر یک سرور خراب شود، سرور دیگری بی‌وقفه جایش را می‌گیرد» همیشه درست نیست:

• دیسک محلی یا شبکه‌ای: در AWS، دیسک‌های Instance Store به خود میزبان وصل‌اند و داده‌شان با خاموش کردن (Stop) سرور پاک می‌شود؛ اما EBS دیسکی جدا از میزبان است که داخل همان Availability Zone خودکار تکرار می‌شود. محل دیسک اصلی، روی NVMe یا SSD خود میزبان یا روی ذخیره‌ساز شبکه‌ای، در هر ارائه‌دهنده فرق می‌کند. دیسک محلی سریع است، اما اگر میزبان از کار بیفتد، سرور معمولاً تا تعمیر آن یا بازگردانی از بکاپ بالا نمی‌آید.
• مهاجرت زنده: طبق مستندات Google Compute Engine، هنگام تعمیرات برنامه‌ریزی‌شدهٔ میزبان، ماشینِ روشن بدون ری‌استارت به میزبان دیگری در همان Zone می‌رود، اگر سیاست نگهداری میزبان (Host Maintenance Policy) آن Migrate باشد. این پیش‌فرض بیشتر ماشین‌هاست، اما ماشین‌های Spot به‌طور پیش‌فرض و ماشین‌های دارای GPU یا TPU به‌جای مهاجرت متوقف می‌شوند. با خرابی ناگهانی و کامل سخت‌افزار هم ماشین متوقف و خودکار دوباره روشن می‌شود.

تعهد دسترس‌پذیری هم همین را نشان می‌دهد: توافق‌نامهٔ سطح خدمات (SLA) سرویس EC2 در AWS برای هر سرور ۹۹٫۵ درصد دسترس‌پذیری ماهانه تعهد می‌کند و ۹۹٫۹۹ درصد را فقط برای سرورهایی که هم‌زمان در دست‌کم دو Availability Zone یک Region اجرا می‌شوند. با حساب ساده، ۹۹٫۵ درصد یعنی AWS در ماه ۳۰ روزه تا حدود ۳ ساعت و ۳۶ دقیقه قطعی یک سرور را نقض این تعهد نمی‌داند. پس دسترس‌پذیری بالا (HA) ویژگی یک سرور نیست، طراحی شماست: دست‌کم دو سرور در دو محل جدا، داده‌ای که بینشان همگام می‌ماند و Load Balancer یا روشی دیگر برای فرستادن ترافیک به سرور سالم.

تفاوت سرور ابری با سرور مجازی، اختصاصی و هاست ابری

جزئیات به ارائه‌دهنده بستگی دارد؛ این دو جدول حالت رایج را نشان می‌دهند. اگر تفاوت VPS و VDS هم برایتان سؤال است، مقالهٔ تفاوت بین VPS، VDS و Dedicated Server را ببینید.

سرویس	چه می‌گیرید	دسترسی و مسئولیت	تغییر منابع
هاست ابری	حساب هاست با کنترل پنل روی چند سرور به‌هم‌پیوسته	کنترل پنل؛ نگهداری سرور معمولاً با ارائه‌دهنده	معمولاً بدون انتقال سایت
سرور مجازی (VPS)	ماشین مجازی با منابع مشخص	root یا Administrator؛ سیستم‌عامل با شما	ارتقای پلن، معمولاً با یک ری‌استارت
سرور ابری	ماشین مجازی درخواستی از پلتفرم ابری	root یا Administrator، اغلب همراه API	از پنل یا API، معمولاً با خاموش و روشن شدن
سرور اختصاصی	کل یک سرور فیزیکی	root و در صورت ارائه، دسترسی IPMI	افزودن یا تعویض قطعه، معمولاً با توقف

سرویس	مدل پرداخت رایج	اگر سرور میزبان خراب شود
هاست ابری	ماهانه یا سالانه	اگر HA فعال باشد، معمولاً چند دقیقه قطعی
سرور مجازی (VPS)	ماهانه یا بلندمدت	بسته به زیرساخت ارائه‌دهنده
سرور ابری	ساعتی یا ثانیه‌ای، گاهی با سقف ماهانه	بسته به پلتفرم: روشن شدن دوباره روی میزبان دیگر یا انتظار تا تعمیر
سرور اختصاصی	ماهانه یا بلندمدت	توقف تا تعمیر یا تعویض قطعه، مگر سرور دوم داشته باشید

مرز سرور ابری و سرور مجازی کجاست؟

سرور ابری به معنای رایجش نوعی سرور مجازی است: هر دو ماشین مجازی روی Hypervisor یک میزبان‌اند و سیستم‌عامل و دسترسی root با شماست (تعریف و کاربردهای سرور مجازی در مقالهٔ سرور مجازی چیست؟ آمده است). تفاوت در پلتفرم دور ماشین است: سلف‌سرویس کامل، API، صورت‌حساب مصرفی و سرویس‌هایی مثل Volume، Snapshot، شبکهٔ خصوصی و Load Balancer.

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

1. دیسک اصلی روی خود میزبان است یا روی ذخیره‌ساز شبکه‌ای و چندنسخه‌ای؟
2. با خرابی میزبان، سرور خودکار روی میزبان دیگری بالا می‌آید و در تعمیرات برنامه‌ریزی‌شده مهاجرت زنده دارد؟
3. تغییر اندازه از پنل است یا با درخواست، با چه مدت توقف، و برگشت به پلن کوچک‌تر ممکن است؟
4. پرداخت ماهانه است یا ساعتی، و سرور خاموش هم هزینه دارد؟

ابر عمومی، خصوصی و ترکیبی

NIST چهار مدل استقرار (Deployment Model) تعریف می‌کند و سرور ابری‌ای که از یک ارائه‌دهنده می‌خرید تقریباً همیشه در ابر عمومی است.

ابر عمومی (Public Cloud): زیرساختی برای استفادهٔ عموم، در محل ارائه‌دهنده؛ بدون خرید سخت‌افزار شروع می‌کنید، اما سخت‌افزار و قوانین سرویس دست ارائه‌دهنده است.

ابر خصوصی (Private Cloud): زیرساختی فقط برای یک سازمان، در محل خودش یا بیرون از آن، که خود سازمان، شرکتی دیگر یا هر دو با هم اداره‌اش می‌کنند؛ مثلاً سازمانی که روی سرورهای خودش با نرم‌افزاری مثل OpenStack به تیم‌هایش امکان ساخت سلف‌سرویس ماشین مجازی می‌دهد. چند سرور مجازی‌سازی‌شده بدون سلف‌سرویس و اندازه‌گیری مصرف، طبق تعریف NIST ابر نیست.

ابر ترکیبی (Hybrid Cloud): دو یا چند زیرساخت ابری جدا، مثلاً ابر خصوصی سازمان و یک ابر عمومی، که مستقل می‌مانند، اما طوری به هم وصل‌اند که داده و برنامه بینشان جابه‌جا شود؛ مثل فرستادن بار اضافهٔ ساعت‌های اوج به ابر عمومی (Cloud Bursting). مدل چهارم، ابر اجتماعی (Community Cloud)، زیرساختی ویژهٔ گروهی از سازمان‌ها با دغدغه‌های مشترک است، مثل الزامات امنیتی یکسان.

مزایا و محدودیت‌های سرور ابری

سرور ابری به کار چه کسی می‌آید؟

• بار پرنوسان: فروش فصلی یا کمپینی که چند روز ترافیک چندبرابر می‌آورد؛ چند سرور اضافه پشت Load Balancer می‌گذارید و بعد حذفشان می‌کنید، به شرطی که برنامه روی چند سرور اجرا شود و فایل‌های آپلودشده و نشست‌ها (Session) روی یک سرور نمانند.
• سرورهای کوتاه‌مدت: آزمایش نسخهٔ جدید، پردازشی چندساعته یا محیط آموزشی؛ با پرداخت ساعتی فقط همان چند ساعت را می‌پردازید، به شرط اینکه سرور را بعد از کار حذف کنید.
• تیم‌هایی که خودکارسازی می‌کنند: ساخت و حذف سرور با API یا ابزارهای زیرساخت به‌عنوان کد (Infrastructure as Code) مثل Terraform، مثلاً در خط CI/CD.
• بازیابی پس از حادثه (Disaster Recovery): نسخه‌ای کوچک و آماده در لوکیشنی دیگر که فقط هنگام نیاز بزرگ می‌شود.

محدودیت‌ها و هزینه‌های پنهان

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

وقتی یک سرور مجازی کافی است

منصفانه بگوییم: بیشتر سایت‌ها و پروژه‌ها به خوشهٔ ابری نیاز ندارند. سایت وردپرسی یا فروشگاه، یک API با دیتابیسش، ربات یا سرور ترید روی یک سرور مجازی با اندازهٔ درست، کش مناسب و بکاپ بیرونی به‌خوبی اجرا می‌شود. برای سروری که تمام ماه روشن است، پرداخت ساعتی مزیتی ندارد و کیفیت منابع، لوکیشن و پشتیبانی مهم‌تر است. برای سایت کوچک، هاست اشتراکی هم کافی است.

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

خواندن برگهٔ مشخصات سرور ابری

هر خط برگهٔ مشخصات (Spec Sheet) پرسشی پشت خود دارد. نمونهٔ فرضی زیر شبیه پلن‌های رایج است:

Plan:     4 vCPU (shared), 8 GB RAM
Disk:     160 GB NVMe
Network:  1 Gbit/s port, 4 TB/month outbound
IPv4:     1 included
Billing:  hourly, capped at the monthly price
Backups:  optional add-on

پردازنده: vCPU مشترک، اختصاصی یا سهمیه‌ای

vCPU معمولاً یک هستهٔ کامل نیست؛ طبق مستندات DigitalOcean هر vCPU یک رشتهٔ پردازشی (Hyper-thread) از یک هستهٔ فیزیکی است. سه حالت رایج:

• مشترک (Shared): رشتهٔ شما ممکن است با ماشین‌های دیگر همان میزبان تقسیم شود و دسترسی به کل آن همیشگی نیست؛ برای بار کم تا متوسط مناسب است.
• اختصاصی (Dedicated): رشته همیشه فقط مال شماست؛ برای دیتابیس، پردازش مداوم و کارهایی که نوسان کارایی را تحمل نمی‌کنند.
• سهمیه‌ای (Burstable): مثل نوع T در AWS: پلن یک سطح پایه (Baseline) دارد و بالاتر رفتن از آن اعتبار پردازنده (CPU Credit) مصرف می‌کند. طبق مستندات AWS، در حالت Standard با تمام شدن اعتبار، CPU به‌تدریج تا سطح پایه پایین می‌آید و در حالت پیش‌فرض نسل‌های جدیدتر مثل T3، مصرف طولانی بالاتر از سطح پایه هزینهٔ اضافه دارد؛ پس برای سروری که مدام زیر بار است مناسب نیست.

مدل و نسل پردازنده را هم بپرسید؛ ۴ vCPU از نسل جدید با ۴ vCPU از پردازنده‌ای ده‌ساله برابر نیست.

دیسک: نوع، محل و سقف سرعت

• نوع و محل: NVMe از SSD ساتا سریع‌تر است و هر دو از HDD بسیار سریع‌ترند. دیسک محلی تأخیر کمتری دارد و دیسک شبکه‌ای چندنسخه‌ای در برابر خرابی یک میزبان مقاوم‌تر است، اما هر خواندن و نوشتنش از شبکه می‌گذرد. مطمئن شوید دیسک اصلی موقتی نیست، یعنی داده‌اش با خاموش کردن سرور پاک نمی‌شود.
• سقف عملیات در ثانیه (IOPS): بسیاری از ابرها برای هر دیسک یا سرور سقف IOPS و توان انتقال دارند؛ عدد را بپرسید و بعد از تحویل بسنجید.
• دیسک اضافه (Volume): فضای جدایی که دیسک اصلی را بزرگ نمی‌کند و معمولاً جداگانه هزینه دارد.

شبکه، ترافیک و IP

• سرعت پورت در برابر ترافیک: «1 Gbit/s» سقف سرعت لحظه‌ای است و «4 TB/month» حجمی که در ماه منتقل می‌کنید. بپرسید ترافیک ورودی هم شمرده می‌شود و مازاد چطور حساب می‌شود؛ مثلاً در DigitalOcean ترافیک ورودی رایگان است و خروجیِ بیش از سهمیه به ازای هر گیگابایت هزینه دارد.
• IPv4: در قیمت هست؟ در AWS هر IPv4 عمومی ساعتی هزینهٔ جداگانه دارد و با خاموش و روشن کردن سرور عوض می‌شود، مگر IP ثابت (Elastic IP) گرفته باشید. اگر IP در DNS، فایروال سرویسی دیگر یا لایسنس نرم‌افزار ثبت شده، بپرسید با خاموش و روشن شدن، تغییر پلن یا نصب دوبارهٔ سیستم‌عامل ثابت می‌ماند یا نه.
• شبکهٔ خصوصی: در چندسروری، ارتباط برنامه و دیتابیس باید از شبکهٔ خصوصی برود، نه از اینترنت.

تغییر اندازه و صورت‌حساب

«مقیاس‌پذیری با یک کلیک» معمولاً یعنی خاموش و روشن شدن. طبق مستندات تغییر اندازه در DigitalOcean، پیش از تغییر اندازه از پنل باید سرور را خاموش کنید و چون سرور ممکن است به میزبان دیگری برود و داده از راه شبکه منتقل شود، مدت توقف به حجم دادهٔ دیسک بستگی دارد؛ برآورد خود DigitalOcean حدود یک دقیقه برای هر گیگابایت پرشده است و معمولاً کمتر می‌شود. تغییر فقط CPU و رم برگشت‌پذیر است، اما افزایش دیسک نه، چون دیسک کوچک نمی‌شود. در AWS هم برای تغییر نوع سرور باید آن را Stop کنید.

در صورت‌حساب ساعتی یا ثانیه‌ای سه نکته را بخوانید؛ نمونه‌های زیر مربوط به زمان نگارش این مطلب (آبان ۱۴۰۵) است:

• واحد و حداقل: DigitalOcean برای Dropletها و AWS برای Amazon Linux، Ubuntu، RHEL و ویندوز ثانیه‌ای حساب می‌کنند، با حداقل ۶۰ ثانیه.
• سقف ماهانه: برخی پلتفرم‌ها هزینه را به قیمت ماهانهٔ پلن محدود می‌کنند؛ مثلاً DigitalOcean مصرف Dropletهای پلن ثابت (Bundled) را حداکثر ۶۷۲ ساعت (۲۸ روز) در ماه حساب می‌کند، اما همهٔ انواع Droplet این سقف را ندارند.
• سرور خاموش: در DigitalOcean سرور خاموش هم هزینه دارد و فقط حذفش صورت‌حساب را متوقف می‌کند؛ در AWS سرور Stopشده هزینهٔ پردازش ندارد، اما دیسک‌های EBS و IPهای ثابت آن هزینه دارند.

بکاپ، Snapshot و SLA

• بکاپ: بکاپ خودکار معمولاً سرویسی اختیاری با هزینهٔ جداگانه است، مثل بکاپ Dropletها در DigitalOcean. اگر در مشخصات چیزی دربارهٔ بکاپ نیامده، فرض کنید کار خود شماست.
• Snapshot: برای برگشت سریع پیش از تغییر پرخطر، مثل ارتقای سیستم‌عامل، مفید است، اما جای بکاپ بیرونی را نمی‌گیرد. بپرسید کجا ذخیره می‌شود و با حذف سرور می‌ماند یا نه.
• SLA: درصد، روش اندازه‌گیری و جبران را بخوانید. در SLA سرویس EC2، تنها جبران، اعتبار (Service Credit) به‌صورت درصدی از صورت‌حساب همان ماه است، نه پرداخت خسارت کسب‌وکار شما.

تست سرور ابری بعد از تحویل

در ساعت‌های اول، مشخصات واقعی را با سفارش مقایسه کنید. دستورها برای Ubuntu 24.04 و 26.04 است و در Debian 13 هم کار می‌کند (اگر sudo نصب نیست، دستورها را با کاربر root و بدون sudo اجرا کنید):

nproc
lscpu | grep -E '^(CPU\(s\)|Model name|Thread\(s\) per core|Hypervisor vendor):'
free -h
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
df -h /

نمونهٔ فرضی خروجی lscpu روی سروری با ۲ vCPU (وقتی خروجی به grep می‌رود، سطرها تورفتگی ندارند):

CPU(s):                               2
Model name:                           AMD EPYC-Rome Processor
Thread(s) per core:                   1
Hypervisor vendor:                    KVM

عدد CPU(s) باید با vCPU پلن برابر باشد. اگر Model name نامی کلی مثل QEMU Virtual CPU نشان داد، مدل واقعی پردازنده به ماشین مجازی نشان داده نمی‌شود؛ نسل آن را از ارائه‌دهنده بپرسید. ستون total در free -h معمولاً کمی کمتر از رم پلن است، چون طبق راهنمای free، کد کرنل و بخش‌های رزروشده از آن کم می‌شود. روی ویندوز سرور، پردازنده و رم را در Task Manager، سربرگ Performance، ببینید.

رقابت بر سر پردازنده را با vmstat ببینید (۱۰ گزارش با فاصلهٔ یک ثانیه؛ سطر اول میانگین از زمان بوت است و ملاک نیست):

vmstat 1 10

ستون st (Steal) درصد زمانی است که ماشین شما آمادهٔ اجرا بوده، اما Hypervisor پردازنده را به ماشین دیگری داده است. در vCPU اختصاصی معمولاً نزدیک صفر است؛ در vCPU مشترک کمی steal طبیعی است، اما اگر در ساعت‌های عادی پایدار بالا بماند (قاعدهٔ سرانگشتی، نه عدد رسمی: بیش از ۱۰ درصد)، احتمالاً میزبان شلوغ است و خروجی را برای پشتیبانی بفرستید.

سرعت واقعی دیسک را با fio بسنجید. این تست فایلی آزمایشی ۲ گیگابایتی در /root می‌سازد و ۶۰ ثانیه از آن تصادفی می‌خواند؛ روی فایل‌های دیگر یا مستقیم روی دستگاه دیسک (مثل /dev/vda) چیزی نمی‌نویسد. اگر df -h / کمتر از ۵ گیگابایت فضای آزاد نشان داد، --size را کوچک‌تر کنید؛ سطر آخر، فایل آزمایشی را پاک می‌کند:

sudo apt update
sudo apt install fio
sudo fio --name=randread --filename=/root/fio.test --size=2G --rw=randread --bs=4k \
    --iodepth=32 --numjobs=4 --ioengine=libaio --direct=1 \
    --runtime=60 --time_based --group_reporting
sudo rm /root/fio.test

عدد IOPS در خط read: را با سقف اعلام‌شده مقایسه کنید. از داخل سرور نمی‌شود با اطمینان فهمید دیسک محلی است یا شبکه‌ای؛ این را از ارائه‌دهنده بپرسید. در پایان، کنسول وب پنل (VNC یا مشابه آن) را یک بار باز کنید تا مطمئن شوید اگر SSH قطع شد، راه ورود دیگری دارید.

چک‌لیست خرید سرور ابری

برای هر پیشنهاد به این پرسش‌ها جواب بدهید و هرچه در مشخصات نیامده، پیش از پرداخت کتبی بپرسید:

1. پردازنده: vCPU مشترک، اختصاصی یا سهمیه‌ای؟ مدل و نسل پردازنده؟
2. رم: برای سیستم‌عامل، برنامه‌ها و اوج مصرف کافی است؟
3. دیسک: NVMe یا SSD؟ روی میزبان یا شبکه‌ای؟ سقف IOPS؟ امکان افزودن Volume؟
4. شبکه: سرعت پورت، سهمیهٔ ترافیک ماهانه، شمارش ترافیک ورودی، هزینهٔ مازاد و رفتار ارائه‌دهنده هنگام حملهٔ DDoS (مثلاً قطع موقت IP).
5. لوکیشن: نزدیک کاربران؛ تأخیر را پیش از خرید از شبکهٔ کاربران واقعی بسنجید.
6. IPv4: تعداد و هزینه، و ثابت ماندن با خاموش و روشن شدن، تغییر پلن یا نصب دوبارهٔ سیستم‌عامل.
7. سیستم‌عامل: ایمیج‌های آماده، نصب از ISO دلخواه و وضعیت لایسنس ویندوز.
8. کنسول: کنسول وب و حالت نجات (Rescue) برای وقتی SSH یا ریموت دسکتاپ کار نمی‌کند.
9. تغییر اندازه: از پنل یا با درخواست؟ با چه مدت توقف؟ برگشت‌پذیر است؟
10. صورت‌حساب: ماهانه، ساعتی یا ثانیه‌ای؟ سقف ماهانه؟ هزینهٔ سرور خاموش؟
11. خرابی میزبان: راه‌اندازی خودکار روی میزبان دیگر، مهاجرت زنده در تعمیرات و SLA مکتوب.
12. بکاپ: بکاپ کار خود شماست، مگر سرویس بکاپ با دوره، محل نگهداری و روش بازگردانی روشن ارائه شود؛ Snapshot و بکاپ را جدا بپرسید.
13. خودکارسازی و قوانین: API و محدود کردن دسترسی توکن‌ها، اگر خودکارسازی می‌کنید؛ و کاربردهای ممنوع در قوانین سرویس.

سرور ابری برای کاربران ایرانی

AWS، Azure و Google Cloud

این سه ابر تابع قوانین تحریم و کنترل صادرات آمریکا هستند. قرارداد مشتری AWS در بخش رعایت مقررات تجاری (Trade Compliance) هر دو طرف را به رعایت این قوانین ملزم می‌کند و از مشتری می‌خواهد اعلام کند خودش و مؤسسه‌های مالی‌اش زیر تحریم نیستند. مایکروسافت در پرسش‌های متداول صادرات، ایران را جزو کشورهایی نام برده که محصولاتش بدون مجوز دولت آمریکا به آن‌ها صادر نمی‌شود و طبق متن همان پرسش، دسترسی به سرویس‌های ابری‌اش از آنجا مجاز نیست. شرایط Google Cloud هم به گوگل اجازه می‌دهد در صورت نقض قوانین کنترل صادرات و تحریم، از جمله تحریم‌های OFAC، قرارداد را فوراً فسخ کند.

در نتیجه، در زمان نگارش این مطلب (آبان ۱۴۰۵)، این سه ابر به مشتریان داخل ایران خدمات نمی‌دهند. حسابی که با اطلاعات نادرست ساخته شود، طبق همین شرایط ممکن است تعلیق یا بسته شود و سرورها و داده‌هایش از دسترس خارج شوند؛ زیرساخت کسب‌وکار را روی چنین حسابی نسازید.

سرور داخل ایران یا خارج؟

در ایران هم چند ارائه‌دهندهٔ سرور ابری با پنل سلف‌سرویس و پرداخت ساعتی یا روزانه فعال‌اند. انتخاب بین داخل و خارج به این‌ها بستگی دارد:

• محل نگهداری داده: اگر طبق قرارداد، مقررات حوزهٔ کاری یا سیاست سازمان داده باید داخل ایران بماند، فقط سرور یا ابر داخلی گزینهٔ شماست.
• اختلال اینترنت بین‌الملل: در دوره‌های اختلال، که در سال‌های اخیر چند بار تکرار شده، سرویس‌های میزبانی‌شده در ایران معمولاً برای کاربران داخلی در دسترس می‌مانند، اما سرور خارج ممکن است برایشان قطع یا بسیار کند شود. اگر مخاطب اصلی داخل ایران است، سروری در ایران، مثل سرور مجازی ایران، منطقی‌تر است.
• سرویس‌های خارجی: در زمان نگارش این مطلب، Docker Hub و برخی سرویس‌های Google درخواست از IP ایران را به‌دلیل تحریم رد می‌کنند و تلگرام در ایران فیلتر است؛ پروژه‌ای که به این‌ها وابسته است، مثل ربات تلگرام، روی سرور خارج راه می‌افتد. اما سرویسی مثل OpenAI که ایران را در فهرست کشورهای پشتیبانی‌شده ندارد، با سرور خارج هم مجاز نمی‌شود.
• سرویس‌های داخلی: برخی درگاه‌های پرداخت و پنل‌های پیامک فقط درخواست از IP ایران یا IPهای ثبت‌شده را می‌پذیرند.

دسترسی از ایران را پیش از خرید بسنجید

اگر ارائه‌دهنده IP آزمایشی یا Looking Glass دارد، از همان اینترنتی که کاربران‌تان دارند، ثابت و همراه، تأخیر و پایداری مسیر را بسنجید. IP نمونه را با IP آزمایشی عوض کنید؛ pathping در ویندوز چند دقیقه طول می‌کشد:

# Windows (Command Prompt)
ping -n 20 203.0.113.10
pathping 203.0.113.10

# Linux or macOS
ping -c 20 203.0.113.10

# Linux (Ubuntu/Debian): loss and latency per hop
sudo apt install mtr-tiny
mtr -rwc 50 203.0.113.10

به میانگین زمان رفت‌وبرگشت و درصد بسته‌های گم‌شده (Packet Loss) نگاه کنید. در mtr، ستون Loss% سطر آخر، یعنی خود مقصد، ملاک است؛ گم شدن بسته فقط در یک هاپ میانی معمولاً یعنی آن روتر به پینگ اولویت پایینی می‌دهد. چند درصد بستهٔ گم‌شده تا مقصد در ساعت‌های عادی نشانهٔ مسیر ناپایدار است؛ آزمون را در ساعت‌های شلوغ عصر هم تکرار کنید.

اشتباه‌های رایج و امنیت حساب ابری

اشتباه	پیامد	راه درست
Snapshot و بکاپ همان پلتفرم را تنها نسخه دانستن	با تعلیق یا بسته شدن حساب یا حذف اشتباهی، همه با هم از دست می‌روند	یک نسخه بیرون از همان حساب و ارائه‌دهنده
خاموش کردن سرور آزمایشی به‌جای حذف	ادامهٔ صورت‌حساب در برخی پلتفرم‌ها	حذف سرور بعد از کار، در صورت نیاز پس از گرفتن Snapshot
ثبت IP متغیر در DNS یا فایروال‌ها	قطع سرویس بعد از خاموش و روشن کردن	IP ثابت (Reserved یا Elastic IP)

حساب پنل از خود سرور حساس‌تر است

هر کس به حساب پنل ابری دست پیدا کند، می‌تواند سرورها، Snapshotها و بکاپ‌های همان حساب را یک‌جا حذف کند. ورود دومرحله‌ای پنل را روشن کنید، توکن API را مثل رمز root نگه دارید، در کد و گیت نگذارید و اگر پلتفرم اجازه می‌دهد، دسترسی هر توکن را محدود کنید. فایروال ابری (اگر هست) و فایروال سیستم‌عامل را هر دو تنظیم کنید، با کلید SSH وارد شوید و هشدار هزینه (Budget Alert) را فعال کنید تا سرور فراموش‌شده یا توکن لورفته زود معلوم شود.

سرور مجازی و سرور ابری در هاکان سرور

اگر بعد از این چک‌لیست دیدید یک سرور با اندازهٔ مناسب برای پروژه‌تان کافی است، که برای بیشتر سایت‌ها همین‌طور است، صفحهٔ خرید سرور مجازی را ببینید. سرور مجازی هاکان سرور در ۵۲ لوکیشن ارائه می‌شود. سیستم‌عامل‌های قابل تحویل بسته به لوکیشن فرق می‌کند؛ لینوکس روی همهٔ لوکیشن‌ها هست و اگر ویندوز یا سیستم‌عامل خاصی لازم دارید، پیش از خرید با تیکت بپرسید. تحویل سرویس خودکار و کمتر از یک ساعت است. ارتقای منابع سرویس با ثبت تیکت انجام می‌شود و IP سرویس تا زمانی که سرویس تمدید شود ثابت می‌ماند. تهیهٔ بکاپ بر عهدهٔ کاربر است و با ثبت تیکت هم قابل درخواست است.

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

پرسش‌های متداول

تفاوت سرور ابری و سرور مجازی چیست؟

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

آیا سرور ابری هیچ‌وقت قطع نمی‌شود؟

نه. یک سرور ابری تنها روی یک میزبان اجرا می‌شود و با خرابی ناگهانی آن، دست‌کم تا روشن شدن دوباره قطع می‌شود؛ SLA سرویس EC2 در AWS هم برای هر سرور ۹۹٫۵ درصد است. سرویسی که نباید قطع شود، دو سرور در دو محل جدا و Load Balancer می‌خواهد.

سرور ابری ارزان‌تر است یا سرور مجازی؟

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

آیا می‌توان از AWS، Azure یا Google Cloud در ایران استفاده کرد؟

در زمان نگارش این مطلب (آبان ۱۴۰۵) نه. این سه ارائه‌دهنده تابع قوانین تحریم و کنترل صادرات آمریکا هستند و به مشتریان داخل ایران خدمات نمی‌دهند.

آیا برای سایت وردپرسی سرور ابری لازم است؟

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

جمع‌بندی

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

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