شرح حمل خادم VPN: المستخدمون أم المعالج أم رابط الرفع؟
قد يعني انخفاض درجة الحمل أن المستخدمين خاملون أو أن المعالج فائض أو أن رابط الرفع واسع. اقرأ loadavg وعدادات الواجهة وملف الحالة قبل أن تصفه بالسرعة.
قد تظل بوابة عند حمل 0.4 تزحف أمام كل مستخدم خلفها. يحسب متوسط الحمل المهام القابلة للتشغيل أو العالقة في نوم غير قابل للمقاطعة، وعلى مضيف بأربع أنوية يكفي عملية واحدة مشبعة لدفعه نحو 1.0 بينما تجلس ثلاث أنوية عاطلة. وقراءة ذلك الرقم كسعة فائضة هي أكثر خطأ شائع في اختيار نقاط النهاية. وما يقيّد النفق فعليًا هو عادة أحد أربعة أشياء: نواة واحدة مشغولة، أو رابط الرفع، أو الطابور أمامه، أو سياسة لكل جلسة لم يوثقها أحد.
متوسط الحمل يحسب المهام لا الإنتاجية
تأخذ النواة عينات من طابور التشغيل ومن عدد المهام المنتظرة على الإدخال والإخراج، ثم تملّس الاثنين على مدى دقيقة وخمس دقائق وخمس عشرة دقيقة. ولا شيء في ذلك التعريف يذكر البايتات أو الحزم أو الأنفاق. فالمضيف الذي علق تخزينه قد يبلّغ عن حمل مرتفع مع حركة تكاد لا تذكر، والمضيف الذي يدفع غيغابت عبر مسار بيانات في النواة قد يبلّغ عن حمل مريح.
لذا فإن ربط الحمل بأداء النفق يحتاج إلى نظرة لكل نواة على حدة. وإذا كانت نواة واحدة مشدودة، فستظل النسبة الإجمالية على لوحة المعلومات تبدو جيدة:
cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20الأمر الثالث هو الأهم على مضيفات VPN. فمعالجة الحزم في مساحة المستخدم في OpenVPN 2.x تتسلسل إلى حد كبير لكل عملية، لذلك قد يصبح خيط واحد مشغول سقف الأداء بينما تبلّغ لوحة المعلومات عن سعة عاطلة وفيرة. وإذا كان خيط واحد يستهلك معظم نواة خلال فترة البطء لديك، فالمضيف ليس ناقص التجهيز إجمالًا؛ بل هو مقيّد في البعد الذي يهم فعلاً.
لاحظ التوقيت أيضًا. متوسطات خمس عشرة دقيقة تخفي الانفجار الذي أفسد مكالمة، لذا فإن لقطة شاشة تُؤخذ بعد الشكوى دليل ضعيف. خذ العينات أثناء المشكلة، واحتفظ بالطابع الزمني مع المخرجات.
رابط الرفع والطابور أمامه
عدادات الواجهة تجيب عن سؤال النطاق الترددي الذي لا تستطيع أرقام المعالج الإجابة عنه. وهي تفصل أيضًا بين السعة والفقد، وهما فشلان مختلفان بعلاجات مختلفة:
ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmitالرابط القريب من معدله المخصص أثناء اختبارك هو التفسير، ولا يغيّره أي قدر من المعالج الفائض. ويضيف سطر qdisc التفصيل المهم للحركة التفاعلية: التراكم والفقد يخبرانك هل تنتظر الحزم في طابور قبل مغادرتها. والطابور الذي يمتلئ أثناء رفع كبير ينتج بالضبط العَرَض الذي يلوم الناس عليه الخادم البعيد، أي مكالمات بطيئة على اتصال لا يزال يحقق أرقامًا جيدة في القياس.
عدادات إعادة الإرسال تلتقط الحالة التي تغادر فيها الحزم لكنها لا تصل أبدًا بشكل سليم. فإذا ارتفعت إعادات الإرسال خلال نافذة البطء وكانت الواجهة بعيدة كل البعد عن السعة، فالمشكلة في المسار لا في المضيف، ولن يساعد الانتقال إلى نقطة نهاية أخرى في المدينة نفسها.
أعداد الجلسات تصف الطلب لا السعة الفائضة
كل دليل عام يعرض عددًا ما من المستخدمين المتصلين، ولا يكاد أي منها يخبرك بما يفعل هؤلاء المستخدمون. عشرون جلسة تعمل عملاً تفاعليًا وأربع جلسات تسحب ملفات كبيرة تنتج حملًا مختلفًا جدًا على العتاد نفسه. والنمط الثاني غير مرئي في عدد المستخدمين، وهو الذي يفسد أمسية كاملة. لذا يُقرأ رقم الجلسات على أفضل وجه كتلميح إلى الطلب، لا كبيان عن السعة الفائضة.
| Number on the page | What it is really measuring | What it cannot tell you |
|---|---|---|
| Connected users | How many sessions hold an address | How much each one is transferring |
| Load or score | Whatever the operator chose to publish | Whether that definition matches your task |
| Uptime | How long since the process started | Current capacity, queue depth or packet loss |
| Distance or ping | Round-trip time on a small probe | Throughput under sustained transfer |
على مضيف تتحكم فيه، يمنحك ملف الحالة البعد المفقود. يكتب OpenVPN لقطة دورية تتضمن عدادات بايتات لكل عميل، وهذا يكفي لترى هل جلسة واحدة مسؤولة عن رابط الرفع بأكمله:
status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.statusعينتان تفصل بينهما عشر ثوانٍ تحوّلان تلك العدادات التراكمية إلى معدل لكل عميل. هذا هو القياس الذي يقوم عدد المستخدمين مقامه، وهو أيضًا كيف تكتشف أن عميلًا واحدًا سيئ الضبط يشبع الرابط كل ليلة في الساعة نفسها.
حدود كل جلسة مخبأة في السياسة
قد يكون الخادم عاطلًا ويرفض مع ذلك أن يمنحك نطاقًا تردديًا. فحدود المعدل وسقوف النطاق لكل عميل وتشكيل الحركة تُطبّق غالبًا لكل اسم شائع أو لكل مجموعة عناوين، لذا قد يحصل مستخدمان على البوابة نفسها على نتائج متباينة جدًا. والآلية ليست خفية، لكنها غير مرئية من الخارج لأن النفق يعمل بشكل طبيعي في الحالتين.
ابحث عن التشكيل على واجهة النفق لا على الواجهة الفيزيائية. وتحقّق مما إذا كان الحد يتبع المستخدم أو الشهادة أو مجموعة العناوين. وإذا وقع حساب اختبارك في المجموعة غير المقيّدة، فستستنتج أن الخادم سليم وأن المستخدم المشتكي مخطئ. وهذا الاستنتاج أسوأ من عدم الاستنتاج، لأنه يغلق التذكرة.
قارن نقطتي نهاية بمهمة واحدة ثابتة
لا يزال التجربة من جهة العميل تستحق التنفيذ، لكن فقط إذا ثُبّتت المتغيرات. استخدم الجهاز نفسه وشبكة الوصول نفسها والبروتوكول نفسه وملف الوجهة نفسه، ثم كرّر ضد نقطة نهاية ثانية على مسافة مشابهة. وأي شيء يتغير بين التشغيلات، بما في ذلك وقت اليوم، يلوّث النتيجة.
سجّل الإخفاقات بعناية مثل النجاحات. سلسلة تعمل فيها ثلاث نقاط نهاية وتنتهي مهلة واحدة أكثر إفادة من أربعة أرقام سرعة، لأنها تشير إلى مشكلة مسار أو سياسة لا إلى مشكلة سعة. شغّل كل حالة مرتين على الأقل؛ عينة بطيئة واحدة لا تثبت شيئًا على شبكة مشتركة.
أخيرًا، احتفظ بالأرقام التي جمعتها مع الادعاء الذي تدعمه. "هذه النقطة أنجزت النقل في النافذة نفسها التي توقفت فيها الأخرى" دفاع مقبول، أما "هذه النقطة أسرع" فيستدعي جدالًا لا يمكنك كسبه بدرجة من الصفحة الرئيسية. ويأتي دليل OpenVPN 2.6 موثّقًا لملف الحالة وخيارات التشكيل إن كنت تحتاج التوجيهات الدقيقة من جهة المضيف.