العودة إلى المقالات

الحزم لا الميغابت: كيف تحسب موارد سيرفر VPN

الحزم لا الميغابت: كيف تحسب موارد سيرفر VPN | مرام هوست - الحزم لا الميغابت: كيف تحسب موارد سيرفر VPN

يسأل كثيرون: كم نواة أحتاج لتمرير نصف جيجابت عبر VPN؟ والجواب الصادق: يعتمد على نوع الحركة. فنصف جيجابت من تحميل ملفات يختلف كثيراً عن نصف جيجابت من ألعاب ومكالمات وطلبات صغيرة، رغم أن عداد الميغابت يعرض الرقم نفسه.

السبب أن السيرفر لا يعمل بالميغابت، بل بالحزم. في هذا المقال نشرح كيف تحسب عدد الحزم في الثانية (PPS)، وكيف تقرأ حمل المعالج دون أن يخدعك المتوسط، ثم كيف تحوّل ذلك إلى قرار شراء معقول.

لماذا الحزم أهم من الميغابت؟

كل حزمة تكلّف المعالج عملين: عملاً ثابتاً مهما كان حجمها، مثل استقبالها وتحديد مسارها وفحصها في جدار النار، وعملاً يكبر مع حجمها وهو التشفير. فكلفة الحركة تقريباً:

كلفة المعالج ≈ (عدد الحزم × كلفة الحزمة الثابتة) + (عدد البايتات × كلفة التشفير)

مع الحزم الكبيرة يغلب الجزء الثاني، ومع الحزم الصغيرة يغلب الجزء الأول. لذلك تضغط الحزم الصغيرة السيرفر عند ميغابتات أقل مما تتوقع.

احسب الحزم من الميغابت

المعادلة بسيطة:

الحزم في الثانية = (السرعة بالميغابت × 1,000,000) ÷ (8 × متوسط حجم الحزمة بالبايت)

لنطبّقها على سرعة واحدة، 500 Mbps، بأحجام افتراضية. هذا حساب رياضي وليس قياساً لشبكة معينة:

متوسط حجم الحزمة (افتراضي)طبيعة الحركةالحزم في الثانية عند 500 Mbps
1400 بايتتحميل ملفات وفيديونحو 44,600
500 بايتحركة مختلطة125,000
100 بايتطلبات صغيرة وأصوات وألعاب625,000
أعمدة تبين عدد الحزم في الثانية عند سرعة واحدة مع ثلاثة أحجام حزمة
السرعة نفسها في الصفوف الثلاثة، لكن عدد الحزم يتضاعف كلما صغر حجمها: هذا ما يراه المعالج فعلاً

الفرق بين الصف الأول والأخير نحو أربعة عشر ضعفاً، بالسرعة نفسها. لهذا فسؤال «كم ميغابت؟» وحده لا يكفي. ولا تفترض حجم الحزمة؛ احسبه من شبكتك:

# rxpck/s و txpck/s هما الحزم، و rxkB/s و txkB/s هما الحجم
sar -n DEV 1 10

# متوسط حجم الحزمة بالبايت = (kB/s × 1000) ÷ pck/s

شغّل القياس في الذروة. في تجربتنا تقع ذروة شبكات العراق ظهراً ومن المساء إلى منتصف الليل، وأدنى حمل يكون فجراً.

من الحزم إلى الأنوية

أفضل طريقة هي استخراج كلفتك من بيئتك: قِس الأنوية المستهلكة عند سرعة معروفة، ثم اقسم:

الأنوية المطلوبة ≈ (الذروة المتوقعة ÷ 100 Mbps) × الأنوية المقيسة لكل 100 Mbps × (1 + هامش النمو)

مثال افتراضي بهامش مفترض 30% وذروة 500 Mbps، باستخدام قياس داخلي تقديري يختلف حسب البيئة: نحو 0.3 نواة لكل 100 Mbps في حاوية LXC تعطي قرابة 2 نواة، ونحو 1.2 نواة في جهاز KVM متداخل تعطي قرابة 7.8 نواة. وهذا تقدير أولي، فنوع حركتك قد يغيّره، ولا يصلح رقم مقيس على حركة كبيرة الحزم لحركة صغيرة الحزم.

ثم افحص سقف النفق الواحد

عدد الأنوية الإجمالي ليس كل القصة، لأن النفق الواحد لا يتوزّع جيداً عليها. سرعة تشفير ChaCha20-Poly1305 الخام للنواة الواحدة نحو 23.3 Gbps على AMD EPYC 9655، ونحو 10.7 Gbps على EPYC 7452، وإنتاجية WireGuard الفعلية نحو 10–15% من ذلك. وسقف النفق الواحد على 7452 نحو 1–1.5 Gbps. فإن تجاوزت ذروتك هذا السقف، فأنت تحتاج نواة أسرع أو عدة أنفاق، لا مزيداً من الأنوية فقط.

لا تثق بمتوسط المعالج

على سيرفر بعدد كبير من الأنوية، قد تمتلئ نواة واحدة ويبقى المتوسط منخفضاً جداً. فمن 32 نواة، نواة ممتلئة وحدها تساوي نحو 3% فقط من المتوسط، بينما النفق متوقف عند سقفه فعلاً.

أعمدة لثماني أنوية إحداها ممتلئة والبقية منخفضة مع متوسط منخفض
رسم توضيحي لا قياس: المتوسط يبدو مريحاً، بينما النواة الأولى هي التي تحدد سرعة النفق
صفحة ملخص حاوية في Proxmox تعرض حالة التشغيل واستخدام المعالج والذاكرة ورسم CPU Usage
رسم CPU Usage في ملخص الضيف مفيد للاتجاه العام، لكنه رقم إجمالي للضيف، فاستعمل mpstat -P ALL 1 لرؤية كل نواة

إذا كانت النواة الأكثر انشغالاً هي نواة استقبال الحزم، فجرّب توزيع الحزم (RPS) قبل تغيير الخدمة. على كرت بطابور واحد خفّض ذلك النواة الأكثر انشغالاً من نحو 84% إلى 74% بلا توقف. وراقب أيضاً ضياع الحزم:

nstat -az UdpRcvbufErrors

إن ارتفع هذا العدّاد فقد يكون هناك مبرر لمراجعة rmem وbacklog. وإن بقي صفراً، فلا تلمسها.

سجّل كل هذه القراءات في جدول صغير: الوقت، والميغابت، والحزم، والنواة الأكثر انشغالاً، وعدّاد الأخطاء. بعد أسبوع سترى كيف تتحرك الأرقام معاً، وستعرف أي الموردين يقترب من سقفه أولاً.

ماذا عن بقية الموارد؟

  • الذاكرة: لا يستهلك النفق نفسه كثيراً، لكن جداول الاتصال والخدمات الإضافية تكبر مع عدد الجلسات.
  • التخزين: لا يؤثر في مسار الحزم، لكنه يهم إن شاركت السيرفر تطبيقات وقواعد بيانات.
  • المنفذ والخط: احسب حركة الدخول والخروج معاً، ولا تنسَ أن التغليف يضيف حجماً إلى كل حزمة.

وتذكّر عند المفاضلة بين عروض الاستضافة أن المسافة تكلّف عشرات الملّي ثانية والعتاد الضعيف يكلّف آلافاً: زمن الشبكة في العراق 70–150ms، وتوليد الصفحة من 150ms إلى أكثر من ثانيتين حسب العتاد. اسأل عن المعالج والتخزين لا عن المدينة وحدها.

لمن تناسب هذه الخدمة؟

  • من يمرّر حركة صغيرة الحزم مثل الألعاب والمكالمات ويرى المعالج يختنق قبل امتلاء الخط.
  • مزوّد إنترنت يخطط لزيادة عدد المشتركين عبر النفق.
  • مسؤول شبكة يريد رقماً مبنياً على القياس لتبرير الترقية.

للأحمال المتوسطة ابدأ من سيرفر WireGuard. وعندما تصبح سرعة النواة الواحدة هي القيد، فاطّلع على سيرفرات Turin السحابية وراجع مواصفات كل باقة في صفحتها. ولإعداد النفق بنفسك على Proxmox يفيدك دليل خادم WireGuard على Proxmox.

أخطاء شائعة

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

أسئلة شائعة

ما الأداة الأبسط لقياس الحزم في الثانية؟

الأمر sar -n DEV 1 من حزمة sysstat يكفي، وهو يعرض الحزم والحجم لكل واجهة في الثانية.

هل يحسّن تصغير MTU الأداء؟

لا تغيّره بهدف الأداء. اضبطه ليناسب المسار، فمع mtu=1420 أكبر حمولة ping هي 1392 بايت. والحزم الأصغر تعني عدداً أكبر منها لنقل البيانات نفسها.

متى أرقّي الخدمة؟

عندما تقترب النواة الأكثر انشغالاً من الامتلاء في الذروة بشكل متكرر، بعد أن تستبعد الأسباب القابلة للضبط مثل توزيع الحزم وإعداد الكرت.

احسب، ثم اختر

اجمع ثلاثة أرقام من ذروتك: الميغابت، والحزم في الثانية، وحمل أكثر نواة انشغالاً. بهذه الأرقام يصبح اختيار السيرفر قراراً محسوباً. راجع صفحة سيرفر WireGuard، أو تواصل مع فريق المبيعات ومعك هذه الأرقام.

Powered by WHMCompleteSolution