VPS أم VDS: الفرق الحقيقي وكيف تختار

متجر إلكتروني على خادم افتراضي يرد في 120 ميلي ثانية صباحاً، ثم يقفز زمن استجابته إلى ثانية كاملة في التاسعة مساءً، مع أن استهلاك المعالج داخل الخادم لا يتجاوز 40%. السبب في أغلب الحالات ليس الكود ولا قاعدة البيانات، بل الأنوية الفيزيائية التي يتقاسمها خادمك مع خوادم أخرى على الجهاز نفسه. هنا يكمن الفرق الحقيقي بين الخادم الافتراضي الخاص (VPS) والخادم الافتراضي المخصص (VDS): ليس في نظام التشغيل ولا في صلاحيات root، بل في سؤال واحد: هل دورات المعالج مضمونة لك أم لا؟

01الفرق في جملتين

كلا النوعين جهاز افتراضي يعمل فوق مشرف افتراضي مثل KVM، بنواة نظام تشغيل مستقلة وقرص افتراضي وعنوان IP خاص به. في الـ VPS تحصل على أنوية افتراضية (vCPU) تُجدوَل زمنياً على أنوية فيزيائية يشاركك فيها غيرك، وفي الـ VDS تُخصَّص لك أنوية أو خيوط فيزيائية بعينها لا يُجدوَل عليها أحد سواك.

والمصطلحان غير موحّدين في السوق: بعض المزودين يسمّي أي خادم KVM باسم VDS، وبعضهم يبيع VPS بأنوية مخصصة. لذلك لا تحكم من الاسم، واقرأ مواصفات الخطة: هل تذكر vCPU مشتركة أم أنوية مخصصة (Dedicated vCPU)؟ وهل يعلن المزود نسبة الحجز الزائد على المعالج؟

02ما الذي يحدث تحت الغطاء

المعالج

في الخادم الفيزيائي الحديث عشرات الأنوية. في نموذج الـ VPS يبيع المزود أنوية افتراضية أكثر من الأنوية الفيزيائية المتاحة، بنسب مثل 1:4 أو أكثر، معتمداً على أن الخوادم لا تستهلك معالجها كاملاً في اللحظة نفسها. ما دام الحمل الكلي معتدلاً لن تشعر بشيء. لكن حين يرتفع حمل الجيران معاً، تنتظر نواتك الافتراضية دورها، ويظهر هذا الانتظار في مؤشر وقت السرقة.

في الـ VDS تُثبَّت أنويتك الافتراضية على أنوية فيزيائية محددة (CPU pinning) فلا تُباع لغيرك. والنتيجة أداء متوقع، وزمن استجابة أثبت في النسب العليا مثل p95 وp99، وهي النسب التي يشعر بها المستخدم فعلاً.

الذاكرة

في المحاكاة الافتراضية الكاملة مثل KVM تُحجز الذاكرة عادةً لكل خادم في النوعين كليهما. بعض المزودين يستخدم تقنيات مثل Memory Ballooning لاسترداد الذاكرة غير المستخدمة، فاسأل عنها إن كانت تطبيقاتك حساسة لحجم الذاكرة المتاحة.

التخزين والشبكة

هنا التباس شائع: كلمة «مخصص» في الـ VDS تعني المعالج والذاكرة في الغالب، لا القرص ولا الشبكة. مصفوفة التخزين وبطاقة الشبكة تبقيان مشتركتين في الحالتين، مع سقف لعمليات القراءة والكتابة (IOPS) ولسرعة النقل لكل خادم. فإن كانت مشكلتك بطء القرص، فالانتقال إلى VDS وحده لن يحلها.

03مقارنة مباشرة

04العزل والأمان: أين الفرق فعلاً؟

يشيع أن الـ VDS أكثر أماناً من الـ VPS. والأدق أن العزل الأساسي واحد: في المحاكاة الكاملة يملك كل خادم نواته وذاكرته المحجوزة، ولا يرى ملفات جاره ولا عملياته. الفرق الأمني الحقيقي يظهر في موضعين:

• نوع المحاكاة: بعض العروض الرخيصة باسم VPS تعتمد على الحاويات (مثل OpenVZ أو LXC)، فتتشارك كل الخوادم نواة الجهاز المضيف. هذا عزل أضعف بكثير من KVM، ويقيّدك في تحميل وحدات النواة وتشغيل Docker.
• القنوات الجانبية: حين تتشارك الخوادم الأنوية الفيزيائية وذاكرتها المخبئية، تبقى هجمات القنوات الجانبية من فئة Spectre ممكنة نظرياً بين الجيران. الأنوية المخصصة تقلّص هذا السطح، وهذا يهم الأنظمة التي تعالج بيانات مالية أو صحية وتخضع لتدقيق امتثال.

أما أمان خادمك اليومي فيتوقف على إعداداتك أكثر من نوع الخادم: مفاتيح SSH بدل كلمات المرور، وجدار حماية يغلق كل منفذ لا تحتاجه، وتحديثات أمنية منتظمة.

05كيف تقيس ما تحصل عليه فعلاً

لا تعتمد على اسم الخطة. ثلاثة قياسات في نصف ساعة تخبرك بما يجري على خادمك. ثبّت الأدوات أولاً على Ubuntu أو Debian، ثم ابدأ بالمعالج:

sudo apt install -y sysstat sysbench fio# نوع المعالج وعدد الأنوية التي يراها نظامكlscpu | grep -E "Model name|Thread|Core|Socket"# وقت السرقة لكل نواة (العمود %steal)، كل ثانية لمدة دقيقةmpstat -P ALL 1 60# أداء المعالج: شغّله صباحاً ثم في الذروة وقارن الرقمينsysbench cpu --threads=$(nproc) --time=30 run

# زمن انتظار القرص (العمودان r_await وw_await بالميلي ثانية)iostat -x 1 10# قراءة عشوائية بحجم 4K وعمق طابور 32 لمدة دقيقة، ثم حذف ملف الاختبارfio --name=randread --rw=randread --bs=4k --iodepth=32 --size=1G --runtime=60 --time_based --direct=1 --ioengine=libaio --group_reportingrm -f randread.0.0

وهكذا تقرأ النتائج:

• وقت السرقة: قيمة دون 1% ممتازة. وإن بقيت فوق 5% في ساعات الذروة، فخادمك ينتظر دوره على المعالج الفيزيائي.
• ثبات الأداء: فرق يتجاوز 10 إلى 15% بين نتيجة sysbench صباحاً ونتيجته مساءً علامة على جيران مزدحمين.
• التخزين: إن ارتفع %iowait في mpstat ومعه r_await أو w_await في iostat، فالعنق في القرص لا في المعالج.

06أيهما يناسب حملك؟

وقبل أن تقرر، تأكد أن المشكلة التي تعالجها هي المعالج فعلاً. هذه أعراض شائعة وما يكمن خلفها:

المشكلةالموقع يبطؤ مساءً رغم أن استهلاك المعالج داخل الخادم منخفض

الحلافحص %steal بـ mpstat في الوقت نفسه. إن كان مرتفعاً، فاطلب من المزود نقلك إلى جهاز أقل ازدحاماً، أو انتقل إلى أنوية مخصصة.

المشكلةترقية الخطة إلى أنوية أكثر لم تحسّن زمن الاستجابة

الحلتطبيقات PHP وNode.js تعالج الطلب الواحد على نواة واحدة. حلّل الطلبات البطيئة وفعّل التخزين المؤقت قبل شراء أنوية إضافية.

المشكلةقاعدة البيانات بطيئة في الكتابة

الحلراقب w_await في iostat. إن كان العنق في القرص، فالحل في التخزين أو في ضبط قاعدة البيانات، لا في نوع الخادم.

07توصية عملية

ابدأ بخادم VPS لمعظم المشاريع، وراقب وقت السرقة وزمن الاستجابة p95 أسبوعين تحت حمل حقيقي. إن بقيت الأرقام مستقرة فلا داعي لدفع ثمن الأنوية المخصصة. وإن تجاوز وقت السرقة 5% في الذروة، أو صار زمن استجابة قاعدة البيانات يخرق ما وعدت به عملاءك، فهذا وقت الانتقال.

وإن كنت تبدأ على CoreVPS، فخوادمه تعمل بمحاكاة افتراضية كاملة على معالجات AMD EPYC 9454P وذاكرة DDR5 ECC وتخزين NVMe بمصفوفة RAID 10. شغّل القياسات الثلاثة في يومك الأول، واحفظ نتائجها مرجعاً تقارن به كلما شككت في الأداء.