یک فروشگاه از هاست اشتراکی به سرور اختصاصی مهاجرت میکند، اما در نخستین کمپین دوباره ۵۰۳ میدهد. CPU آزاد است؛ صف PHP پر شده، Query کند دیتابیس باقی مانده و تیمی هم برای هشدار و Rollback ندارد. سختافزار گرانتر شده، ولی گلوگاه و مرز مسئولیت عوض نشده است.
در مقایسه هاست اشتراکی، VPS و سرور اختصاصی، نام محصول پاسخ نیست. باید دو چیز را جداگانه بسنجید: زیرساخت و میزان اشتراک منابع، و سطح خدمتی که Provider واقعاً مدیریت میکند. سپس گزینهها را با Workload، SLO، ظرفیت، امنیت، Recovery، توان تیم و TCO خود آزمایش کنید.
پاسخ کوتاه: Shared برای Workload ساده و کمریسک، با محدودیت شفاف و پشتیبانی خوب میتواند کافی باشد. VPS زمانی ارزش دارد که به تنظیمات، ایزولیشن یا مسیر رشد بیشتری نیاز دارید و مسئولیت سیستمعامل را میپذیرید یا میخرید. Dedicated وقتی قابل دفاع است که نیاز پایدار به کل Host، سختافزار/مجوز خاص یا جداسازی فیزیکی مستند دارید. هیچکدام بهتنهایی سرعت، امنیت یا High Availability را تضمین نمیکنند.
ابتدا دو محور انتخاب هاست را از هم جدا کنید
Shared، VPS و Dedicated درباره نحوه تخصیص یک زیرساخت صحبت میکنند. Managed و Unmanaged درباره اینکه چه کسی آن را اداره میکند. ترکیب این دو محور، محصول واقعی را میسازد.
| محور | گزینهها | پرسش تصمیم |
|---|---|---|
| زیرساخت | Shared، VPS/VM، Dedicated | چه چیزی با دیگران مشترک است و Limit چگونه اعمال میشود؟ |
| مدیریت | Unmanaged، Managed infrastructure، Managed application | چه کسی Patch، Hardening، Backup، Restore و Incident را انجام میدهد؟ |
| معماری | Single node، چند Node، سرویسهای جدا، Active/Passive | خرابی یک Host یا دیتابیس چه Blast radiusی دارد؟ |
| تجاری | سقف ثابت، Pay-as-you-go، Add-on، Fair use | هزینه Base، Peak، Failure و Exit چیست؟ |
پس «VPS مدیریتشده» و «VPS خام» را یک گزینه حساب نکنید. همچنین Managed WordPress یک Service model تخصصی است، نه مترادف Shared؛ مقایسه دقیق آن در راهنمای Managed WordPress در برابر VPS آمده است. راهنمای حاضر فقط تصمیم بین سه Substrate و پیامدهای عملی آن را مالک است.
Shared، VPS و Dedicated واقعاً چه میدهند؟
هاست اشتراکی: سرویس محدودشده روی بستر مشترک
در Shared hosting چند مشتری از Host و معمولاً Stack مدیریتشده مشترک استفاده میکنند. کاربر معمولاً Root ندارد و از Control panel، Runtime و Policy ازپیشتعریفشده استفاده میکند. مزیت اصلی، انتقال بخشی از عملیات روز دوم به Provider است؛ محدودیت اصلی، کنترل کمتر و قرارداد منابع پیچیدهتر.
Shared الزاماً کند یا ناامن نیست. Provider میتواند Tenantها را با Account، Process، Filesystem و Resource controller جدا کند. اما کیفیت این جداسازی، Patch، مانیتورینگ و واکنش به Abuse باید با Evidence سنجیده شود. راهنمای تخصصی امنیت هاست اشتراکی همین مرز را عمیق بررسی میکند.
VPS: ماشین مجازی با Guest مستقل، نه سختافزار اختصاصی قطعی
VPS معمولاً یک VM روی Hypervisor است: سیستمعامل Guest و بخشی از CPU، Memory، Storage و Network به شما ارائه میشود. NIST توضیح میدهد Hypervisor دسترسی VMها به منابع فیزیکی و ایزولیشن زمان اجرا را میان آنها میانجیگری میکند. این یعنی VPS مرز قویتری نسبت به یک Account معمولی میسازد، اما همچنان Host، Hypervisor، Storage یا Network میتواند مشترک باشد.
عبارت «۴ vCPU و ۸ GB RAM» هنوز قرارداد کامل نیست. vCPU ممکن است Share، Weight، Quota یا Burst داشته باشد؛ Storage ممکن است IOPS یا Latency متغیر داشته باشد؛ و Oversubscription میتواند در Peak نمایان شود. VPS تنها زمانی «قابل پیشبینیتر» است که حدها، Baseline و رفتار هنگام Contention روشن و آزمایششده باشد.
سرور اختصاصی: یک Host برای شما، نه یک سرویس بیخطا
در Dedicated server کل Host فیزیکی به یک مشتری تخصیص مییابد. برای بار پایدار، نیاز به Local disk/accelerator، مجوز وابسته به Core، کنترل Firmware یا الزام جداسازی فیزیکی مستند میتواند مناسب باشد. در عوض Provision، تعویض سختافزار و Scale معمولاً کندتر و مسئولیت عملیات بیشتر است.
یک Dedicated منفرد همچنان یک Failure domain است: Power supply، Disk controller، NIC، Mainboard، Rack یا OS میتواند سرویس را متوقف کند. «اختصاصی» با High Availability، Backup، DDoS protection، Monitoring یا Secure configuration مترادف نیست.
قبل از پلن، Workload Contract بنویسید
تعداد بازدید ماهانه معیار ظرفیت نیست. همان ۱۰۰هزار بازدید میتواند مقاله Cacheable یا Checkout پویا با Search، Session، Payment callback و Cron باشد. این کارت را با داده فعلی و سناریوی رشد کامل کنید:
business_journeys: browse | search | login | cart | checkout | admin | API
traffic_shape: baseline_rps | peak_rps | burst_duration | concurrency
cacheability: public_hit_ratio | dynamic_routes | invalidation_rate
writes_and_state: orders | sessions | uploads | queues | cron
dependencies: database | payment | sms | search | object_storage
data_size_and_growth: db | files | logs | backup
criticality: impact_of_slow | impact_of_down | impact_of_data_loss
team: skills | on_call | change_window | incident_authority
constraints: runtime | root | module | location | license | complianceاگر هنوز این پروفایل را ندارید، راهنمای عمومی انتخاب هاست برای Workload، Criticality، Service model، Provider و Pilot نقطه شروع است. این صفحه پس از آن، مقایسه سه بستر را دقیقتر میکند.
برچسب منابع را به Resource Contract تبدیل کنید
مستندات رسمی Linux cgroup v2 نشان میدهد Limit، Protection و Weight مفاهیم متفاوتاند و حتی مجموع Limitهای فرزند میتواند Overcommit شود. محصول Hosting الزاماً cgroup v2 نیست، اما این تفکیک نشان میدهد چرا عدد خام CPU/RAM کافی نیست.
| منبع | سؤال قراردادی | شاهد هنگام Pilot |
|---|---|---|
| CPU | Core یا vCPU؟ Share/Weight/Quota/Burst؟ مدت Burst؟ رفتار Contention؟ | Utilization، Run queue، Steal/Ready، Throttling، CPU/request |
| Memory | Reservation یا سقف؟ Swap/Balloon؟ OOM policy؟ | Working set، Pressure، Swap، OOM و Restart |
| Storage | نوع Volume، IOPS/Throughput/Latency، Burst و Queue؟ | p95/p99 latency، Queue depth و آزمون DB/Backup |
| Network | Port، Baseline/Burst، Transfer/Egress، PPS، DDoS scope؟ | Latency/Loss/Throughput از چند ISP و زمان اوج |
| Application | PHP worker، Process، Entry process، DB connection، Cron limit؟ | Queue، max-children، 5xx، Timeout و Job lag |
| Storage capacity | فضای DB/File/Log/Backup جداست؟ Inode و Overage؟ | Growth rate، Cleanup، Full-disk alert و Restore space |
اگر CPU بالا میرود، قبل از خرید Core بیشتر، CPU time را از Wall time و گلوگاه DB/Disk/Network جدا کنید. روش تشخیص Saturation، PHP-FPM، Cache، Profiling و Load test در راهنمای CPU هاست آمده است.
SLO را به معیار پذیرش تبدیل کنید
عبارتهای «سریع»، «پایدار» و «منابع تضمینی» قابل آزمون نیستند. Google SRE، SLO را مقدار یا بازه هدف برای یک SLI تعریف میکند. هدف را از Journey مهم کاربر شروع کنید، نه از Metric راحت Provider.
SLI: نسبت checkoutهای معتبر که در کمتر از ۲.۵ ثانیه پاسخ موفق میگیرند
SLO: حداقل ۹۹.۵٪ در پنجره ۲۸روزه
validity: به تفکیک mobile/desktop و با حذف bot تأییدشده
evidence: synthetic + RUM + server trace + order reconciliation
response: alert, owner, mitigation, scale/rollback thresholdSLA تجاری ممکن است Availability را در سطح Infrastructure و با Exclusionهای فراوان بسنجد؛ این با SLO سفر خرید یکی نیست. همچنین Average، Peak را پنهان میکند. برای Latency، Error و Resource saturation از p50/p95/p99 و بازه زمانی صریح استفاده کنید.
ماتریس انتخاب Shared، VPS و Dedicated
| معیار | Shared | VPS | Dedicated |
|---|---|---|---|
| کنترل OS/Runtime | کم؛ Policy مشترک | زیاد در Unmanaged، قراردادی در Managed | زیاد؛ Firmware/Host هم ممکن است در Scope باشد |
| ایزولیشن | Account/Process/Policy؛ وابسته به Provider | VM/Hypervisor؛ Host و لایههای پایینتر ممکن است مشترک | Host فیزیکی برای یک مشتری؛ شبکه/رک/Control plane ممکن است مشترک |
| پیشبینی منابع | از محدود تا مناسب، کاملاً قراردادی | معمولاً بهتر؛ وابسته به Reservation/Quota/Oversubscription | ظرفیت Host قابل مشاهدهتر؛ همچنان محدود به معماری و قطعه |
| Scale عمودی | تغییر Plan | اغلب سریع، گاهی Restart/Host move | تعویض/افزودن سختافزار؛ زمانبرتر |
| Scale افقی | اغلب محدود به محصول | ممکن، اگر State جدا و Load balancer آماده باشد | ممکن، اما نیازمند چند Host و معماری |
| عملیات | بخش بیشتری با Provider | از کامل با مشتری تا Managed | بیشترین Scope بالقوه؛ Managed قابل خرید است |
| Fit رایج | سایت Cacheable و کمریسک با محدودیت قابل قبول | Workload روبهرشد، تنظیم سفارشی، App/Worker یا Root | مصرف پایدار Host، سختافزار/مجوز خاص یا Isolation requirement |
این جدول Ranking نیست. Shared با Provider خوب ممکن است برای یک سایت محتوا نتیجه بهتری از VPS خامِ بدون Patch و مانیتورینگ بدهد. Dedicated هم اگر بیشتر زمان Idle باشد و تیم نتواند آن را اداره کند، صرفاً ظرفیت گران و ریسک عملیاتی تولید میکند.
امنیت و Compliance از نام پلن نتیجه نمیشوند
VPS و Dedicated مرزهای متفاوتی میسازند، ولی سطح امنیت نهایی حاصل Threat model، Hardening، IAM، Patch، Secret، Network policy، Logging، Backup، Restore و Incident response است. NIST برای Hypervisor بر Secure execution و ایزولیشن VMهای مقیم تأکید میکند؛ این خود یک Control plane است که باید امن و پایش شود.
Shared Responsibility را فیلدبهفیلد بنویسید
| کنترل | Provider | مشتری | شاهد پذیرش |
|---|---|---|---|
| Host/Hypervisor/Firmware | معمولاً مالک | بررسی Scope و اطلاعیه | Patch policy، Advisory، Incident process |
| Guest OS | فقط اگر صریحاً Managed | در VPS/Dedicated خام مالک | Inventory، Patch SLA، EOL report |
| Application/Plugin/Code | ممکن است محدود یا کمکی | معمولاً مالک | Update/rollback test و Owner |
| Backup | زیرساخت یا Add-on | سیاست، نسخه مستقل و Restore | Restore زماندار و Integrity check |
| Monitoring/Incident | Platform scope | Journey و Business correctness | Alert، Severity، Escalation و Runbook |
برای فروشگاه نیز «حداقل VPS» قانون امنیت یا پرداخت نیست. PCI SSC در راهنمای فعلی خود مسئولیتهای Merchant و Third party را حتی در Outsourcing حذفشده نمیداند و بر تعریف مسئولیت مشترک تأکید دارد. دامنه PCI باید با Acquirer/Payment brand یا متخصص مربوط تعیین شود؛ نوع Hosting بهتنهایی Compliance نمیسازد.
Reliability را با Failure domain و Recovery بسنجید
یک پلن بزرگتر ممکن است Capacity بدهد، ولی Reliability به حذف Single point of failure و توان بازیابی بستگی دارد. برای هر گزینه این زنجیره را رسم کنید:
user → DNS → CDN/WAF → network → host/hypervisor
→ web/runtime → database → storage → queue → third partiesبرای هر Node بنویسید: اگر از کار افتاد چه Journey میشکند، Detection چقدر طول میکشد، چه کسی تصمیم میگیرد، RTO/RPO چیست و Recovery قبلاً آزمایش شده یا فقط وعده است. Snapshot روی همان Account یا Storage، نسخه مستقل محسوب نمیشود. Dedicated واحد بدون Spare/Failover ممکن است Restore کندتری از VPS با Image و Automation داشته باشد؛ عکس آن نیز ممکن است درست باشد.
Managed بودن را با RACI و عملیات روز دوم بخرید
واژه Managed استاندارد واحد ندارد. Provider ممکن است فقط Network و Power را مدیریت کند، یا OS/PHP/MySQL/WordPress/Plugin و Restore را هم بپذیرد. یک RACI برای این کارها بخواهید:
- Provision و Secure baseline؛
- Patch اضطراری و عادی OS/Runtime؛
- Monitoring سرویس، Log و Alert؛
- Backup consistency، Retention و Restore؛
- Certificate، DNS، CDN/WAF و DDoS؛
- Capacity review و تغییر Plan؛
- Malware/Incident/Forensics و ارتباط اضطراری؛
- Migration، Export، حذف امن و Revocation هنگام Exit.
«پشتیبانی ۲۴/۷» بدون Severity، کانال، First response، زمان حل، Escalation و اختیار اقدام، SLO عملیاتی نیست. در Pilot یک Ticket واقعیِ کمخطر و یک Restore زماندار اجرا کنید.
TCO را در چهار سناریو محاسبه کنید
قیمت ماهانه تنها یک جزء است. برای Shared ممکن است Add-on، محدودیت یا مهاجرت زودرس هزینه پنهان باشد؛ برای VPS و Dedicated، زمان Admin، License، Monitoring، Backup، Security و On-call غالب شود.
TCO = plan_or_hardware
+ storage + backup + transfer/egress + IP/CDN/WAF
+ panel/runtime/database/license
+ monitoring/logging
+ admin/on_call/security
+ migration/downtime/incident
+ exit_and_recovery_reserveBase، Peak، Failure و Exit را جدا بسازید. قیمت ارزی، تمدید، نرخ تبدیل، مالیات، ظرفیت رزرو، Overages و هزینه انتقال داده را تاریخدار کنید. مدل مالی کاملتر در راهنمای TCO دامنه و هاست آمده است.
ادعای Provider را با Pilot نماینده آزمایش کنید
Benchmark مصنوعی CPU بهتنهایی سایت شما را نمایندگی نمیکند. یک Clone پاکسازیشده یا Dataset ساختگی با شکل مشابه بسازید و مسیرهای واقعی را در Cache گرم و سرد اجرا کنید.
پروتکل ۱۴روزه
- روز ۱–۲: Limit، RACI، SLA، Backup، Location، Exit و دسترسی Support را مستند کنید.
- روز ۳–۴: Workload نماینده، داده امن، Synthetic و Server metrics را آماده کنید.
- روز ۵–۷: Browse، Search، Login، Cart، Checkout، API، Cron و Backup را با Open model اجرا کنید.
- روز ۸–۹: Spike، Soak، Cache cold، Disk pressure و Downstream کند را آزمایش کنید.
- روز ۱۰–۱۱: Restore، Patch، Rollback و Escalation پشتیبانی را تمرین کنید.
- روز ۱۲–۱۳: SLO، Saturation، Error، Queue، Cost و Business correctness را تطبیق دهید.
- روز ۱۴: Scale / Hold / Reject را با شواهد و Risk باقیمانده ثبت کنید.
Load generator نباید خودش اشباع شود. تست مخرب را روی Production یا سرویس ثالث بدون مجوز اجرا نکنید. برای رویداد پرترافیک، Cache/State/DB/Headroom و Failure test را با راهنمای هاست سایت پرترافیک کامل کنید.
چه زمانی از Shared به VPS یا از VPS به Dedicated برویم؟
مهاجرت را با «ترافیک زیاد» یا یک خطای ۵۰۳ آغاز نکنید. ابتدا علت را طبقهبندی کنید؛ ۵۰۳ میتواند Limit، Deployment، Maintenance، Queue، Origin، Database یا سرویس پاییندست باشد.
Triggerهای قابل دفاع
- SLO در Workload معتبر شکسته و Saturation منبع مشخص همزمان دیده میشود؛
- تنظیم Runtime، Extension، Worker، Queue یا Network مورد نیاز در Plan فعلی ممنوع است؛
- Blast radius یا Isolation فعلی با Risk ثبتشده سازگار نیست؛
- بار پایدار و پیشبینیپذیر، Dedicated را پس از محاسبه TCO اقتصادی میکند؛
- Support/Recovery/Exit Provider آزمون را رد میکند و تغییر Tier مشکل را حل نمیکند؛
- Headroom برای Campaign یا Failure mode پس از Optimization کافی نیست.
ترتیب تصمیم معمولاً چنین است: Diagnose → Optimize/Cache → Tune limit/worker → Scale up → Separate bottleneck → Scale out → Change substrate. مهاجرت خود یک ریسک State/DNS است؛ Runbook کامل در راهنمای مهاجرت هاست بدون Downtime محسوس قرار دارد.
ملاحظات انتخاب هاست برای کاربران ایران
برچسب «ایران» یا «خارج» کیفیت End-to-end را اثبات نمیکند. با چند ISP ثابت و همراه، شهر و ساعت، مسیر واقعی Journey را بسنجید. راهنمای موقعیت دیتاسنتر اثر Route، Cache، Origin، SEO، Resilience و TCO را جدا میکند.
| ریسک | آزمون پیش از خرید | برنامه جایگزین |
|---|---|---|
| کیفیت مسیر | Latency/Loss/TTFB از چند ISP و ساعت | CDN، Origin جایگزین یا مسیر انتقال |
| Control plane خارجی | Panel/API/Console/Support از شبکههای واقعی | Break-glass، Automation و Export آفلاین |
| پرداخت و تمدید | Entity/KYC/روش پرداخت/Grace/تعلیق تاریخدار | هشدار تمدید، ذخیره FX و Provider قابل مهاجرت |
| License/Update | اصالت و دسترسی Repository/Registry | Artifact کنترلشده و مسیر Patch اضطراری |
| پشتیبانی | Ticket Severity واقعی، تماس اضطراری و اختیار اقدام | Runbook داخلی و Vendor دوم |
| داده و قرارداد | Location واقعی Primary/Backup/Log و Subprocessor | Requirement حقوقی تاریخدار و Exit test |
هیچ حکم عمومی درباره الزام نگهداری داده در داخل یا خارج برای همه کسبوکارها ندهید. نوع داده، قرارداد، صنعت و قانون قابل اعمال را با مالک حقوقی تعیین و تاریخ بازبینی را ثبت کنید.
سه سناریوی انتخاب
سایت محتوایی شرکتی با تغییر کم
اگر صفحات عمدتاً Cacheable، فرمها محدود، Recovery ساده و SLO متوسط است، Shared با Limit شفاف، Backup مستقل و Support آزموده میتواند انتخاب اقتصادی باشد. VPS خام صرفاً برای «حرفهایتر بودن» ارزش اضافه نمیکند.
فروشگاه ووکامرس در حال رشد
Browse ممکن است Cache شود، اما Search، Cart، Checkout، Callback، Cron و Admin پویا هستند. ابتدا PHP/DB/Queue و وضعیت سفارش را اندازه بگیرید. Managed WordPress یا Managed VPS هر دو میتوانند مناسب باشند؛ تصمیم را با Worker/DB limit، Restore، Update workflow و Pilot بگیرید، نه نام محصول.
پردازش پایدار یا نیاز سختافزاری خاص
اگر مصرف CPU/IO پایدار به بخش بزرگی از Host میرسد، Local storage latency یا Device/License خاص لازم است و تیم Day-two آماده است، Dedicated میتواند TCO و Predictability بهتری بدهد. برای Availability همچنان به Node دوم، Replication، Failover و Restore نیاز دارید.
پرسشهای متداول مقایسه هاست
هاست اشتراکی بهتر است یا VPS؟
برای سایت ساده و کمریسک، Shared مدیریتشده با محدودیت شفاف ممکن است بهتر و کمهزینهتر باشد. VPS برای Root، Runtime سفارشی، Worker/Queue، ایزولیشن یا ظرفیت بیشتر مناسبتر است؛ به شرطی که مدیریت OS و Recovery مالک مشخص داشته باشد.
آیا VPS منابع کاملاً اختصاصی دارد؟
نه لزوماً. Guest و سهمی از منابع جدا میشود، اما Host، Hypervisor، Storage و Network میتواند مشترک باشد. Reservation، Quota، Weight، Burst، Oversubscription و رفتار هنگام Contention را از Provider بپرسید و در Peak آزمایش کنید.
آیا سرور اختصاصی سریعتر و امنتر است؟
بهطور خودکار خیر. Dedicated ظرفیت و جداسازی Host میدهد، اما App/DB بد، تنظیم ناامن، Patch عقبافتاده یا نبود Monitoring همچنان مشکلساز است. سرعت و امنیت باید با Workload و Controlهای واقعی تأیید شود.
برای فروشگاه اینترنتی حداقل VPS لازم است؟
قانون عمومی وجود ندارد. تعداد محصول، Journey پویا، Worker/DB، Peak، Risk، Scope پرداخت، Recovery و Support تعیینکنندهاند. Shared باکیفیت میتواند برای شروع کافی باشد؛ VPS بدمدیریتشده نیز میتواند پرریسکتر باشد.
از کجا بفهمیم زمان ارتقای هاست رسیده است؟
وقتی SLO در تست یا ترافیک معتبر میشکند و شواهد Saturation یا محدودیت محصول علت را نشان میدهد؛ یا Isolation، Recovery و Control فعلی Risk را پوشش نمیدهد. ابتدا گلوگاه را تشخیص دهید و سپس مناسبترین تغییر را Pilot کنید.
منابع و دامنه اعتبار
- NIST SP 800-125A Rev. 1 برای نقش Hypervisor در میانجیگری منابع، ایزولیشن و امنیت VM؛
- Linux Kernel cgroup v2 documentation برای تفکیک Limit، Protection، Weight و کنترل CPU/Memory/IO؛
- Google SRE: Service Level Objectives برای SLI/SLO و آغاز معیار از نیاز کاربر؛
- PCI SSC FAQ 1092 برای مسئولیت Merchant و Third party و ضرورت تعریف Shared responsibility.
جمعبندی: Shared، VPS و Dedicated سه پله ثابت از «ضعیف» به «قوی» نیستند. هرکدام بستهای از Isolation، Control، Capacity، Failure domain و مسئولیت است. Workload و SLO را بنویسید، Resource contract و RACI را از Provider بگیرید، Recovery و Support را در Pilot آزمایش کنید و فقط زمانی مهاجرت کنید که شواهد نشان دهد تغییر Substrate مسئله واقعی را حل میکند.
