متى تنتقل إلى KVM VPS؟

المؤشر 1: تحتاج root

إذا كان التثبيت أو التشغيل يتطلب حزم نظام أو إعداد خدمات أو تغييرات OS خارج ما توفره اللوحة المدارة فـKVM هو الطبقة المناسبة.

المؤشر 2: تحتاج خدمات نظام دائمة

بعض التطبيقات تحتاج workers أو queues أو runtimes مخصصة أو daemons تعمل باستمرار. إذا لم تدعم الخدمة المدارة هذا النموذج صراحة فانتقل إلى KVM بدلاً من إجبار التطبيق على cron أو web request.

المؤشر 3: ضغط موارد مستمر

استخدم القياس: تشبع CPU متكرر أو قيود ذاكرة/عمليات أو timeouts تحت حمل شرعي بعد تحسين التطبيق. حد CPU الابتدائي في shared يقارب 5% و يختلف حسب الخطة.

• افصل bot/attack traffic عن حمل العملاء.
• حلل استعلامات قاعدة البيانات قبل الترقية.
• استخدم cache للعمل المتكرر المكلف عندما يكون ذلك آمناً.
• إذا كان الحمل مستمراً بطبيعته فاختر حجم VPS بناءً على القياس.

المؤشر 4: متطلبات العزل و التحكم

المشاريع التي تحتاج إعداد نظام تشغيل خاصاً أو تحكم شبكة/خدمات أو غلاف موارد افتراضية مخصصاً تناسب KVM أكثر.

ما ليس مؤشراً

الحاجة إلى قدرة تطبيق واحدة لا تعني تلقائياً الحاجة إلى VPS. يمكن أن يعرض GreatHosts CP خدمات NodeJS و Redis و Memcached و Varnish و Supervisor كقدرات مشمولة أو قابلة للطلب حسب الخطة. استنفد هذا المسار الأبسط قبل تحمل عبء إدارة VPS.

• إنشاء الموقع بالذكاء الصناعي ليس سبباً للانتقال إلى VPS.
• الحاجة إلى NodeJS أو Redis أو Memcached أو Varnish أو Supervisor ليست سبباً بمفردها إذا أمكن إضافة الخدمة إلى الخطة المدارة.
• ارتفاع مؤقت في الزيارات لا يكفي وحده لاتخاذ القرار.
• تفضيل لوحة تحكم مألوفة هو خيار إعداد و ليس دليلاً على الحاجة إلى موارد خادم أكبر.

قائمة النقل

عامل النقل كتغيير منضبط.

• احتفظ بالملفات و قواعد البيانات و سجلات DNS و إعدادات التطبيق.
• و ثق إصدارات التشغيل و cron jobs.
• جهز KVM قبل تغيير DNS.
• اختبر عبر hostname مؤقت أو hosts file عندما يناسب.
• خفض DNS TTL قبل النقل إن كنت تتحكم به.
• اترك البيئة القديمة حتى يكتمل التحقق.

بعد النقل

راقب أخطاء التطبيق و زمن الاستجابة و CPU و الذاكرة و القرص و قاعدة البيانات. root يعطيك حرية أكبر لكنه يضيف مسؤوليات تحديث و أمان و إدارة خدمات.

الخدمات المرتبطة بهذا الدليل