مستخدمون أم إنتاجية؟ تحجيم خادم VPN للحمل الفعلي
أعداد الحسابات لا تحدّد حجم البوابة؛ العمل المتداخل هو ما يحدّده. قارن النقل المتزامن وحمل المعالج لكل نواة والانتظار في الطوابير، ثم اكتب الحمل على الورق.
عشرة حسابات خاملة تكلّف أقل من نسخة احتياطية ليلية واحدة تُشبع النفق، وعدد المستخدمين لا يكشف الفرق. تحجيم خادم VPN مقارنة بين رقمين: التزامن الذي تحمله فعلاً والمورد الذي ينفد أولاً. معظم أخطاء السعة تأتي من اختيار الرقم الأول وعدم قياس الثاني أبداً. افعل الاثنين بهذا الترتيب، فيتوقف قرار العتاد عن كونه تخميناً.
قارن عدد الحسابات بساعة الذروة
عدد الحسابات رخصة وحدّ للدعم؛ أما ساعة الذروة فهي حمل. اسرد الأعمال المتداخلة في تلك الساعة: المكالمات والإدارة عن بُعد والتنزيلات الكبيرة والنسخ الاحتياطية وطلبات التطبيقات الخاصة التي تُبقي الناس منتظرين. ثم حدّد لكل بند ما إذا كان يعبر البوابة وفي أي اتجاه. المكالمات متناظرة وحساسة للتأخير، أما النسخة الاحتياطية فباتجاه واحد وتتحمل بداية بطيئة، لذا تضغطان على أجزاء مختلفة من المسار.
الاتجاه يحدد أي وصلة تهم. وصلة المنزل نادراً ما تكون متناظرة، والفرع الذي ينزّل طوال اليوم يصل إلى حدّه الأدنى قبل أن تشعر البوابة بأي إجهاد. اكتب الاتجاه ونطاق النفق بجوار كل بند، لأن بوابة تحمل وجهات خاصة فقط وأخرى تحمل كل حركة الإنترنت مسألتان مختلفتان في التحجيم.
أضف الحمل الخلفي في صف مستقل: تحديثات العملاء والقياس عن بُعد وكل ما يفعله المضيف إلى جانب التمرير. من السهل نسيان هذه البايتات، والواجهة نفسها هي التي تحسبها.
اعثر على المورد الذي ينفد قبل الوصلة
الوصلة مرشح واحد فقط. عمل التشفير في نفق واحد قد يشغل نواة واحدة بينما تبقى الواجهة نصف خاملة، وقد يجعل طابور مشبع المكالمات غير قابلة للاستخدام عند إنتاجية تبدو متوسطة على الرسم. الوجهة التي تبعد مساراً بطيئاً واحداً قد تبدو أيضاً ضعفاً في البوابة من مقعد العميل. ثلاث ملاحظات تفصل هذه الحالات، ولا تحتاج أي منها إلى اختبار اندفاع.
| Observation | What to inspect |
|---|---|
| one core busy, bytes steady | per-core CPU, implementation, offload status |
| calls degrade during transfers | queueing and the access link |
| one remote destination slow | that route and its service |
قِس بنقل يُسمح لك بتشغيله، وأضف العمل المتزامن على خطوات بدلاً من دفعة واحدة. اقرأ المعدل المستمر والاستجابة التفاعلية معاً، لأن اختبار الذروة وحده يخفي جلسة أصبحت غير قابلة للاستخدام. البوابة التي تحقق أقصى إنتاجية بينما تتقطع المكالمات لم تنجح في الاختبار.
ثم أعد التشغيل مع إيقاف الأحمال الاختيارية. الحدّ الذي يتحرك عندما تتوقف النسخة الاحتياطية لم يكن يوماً حدّ البوابة.
حوّل المقارنة إلى رقم يمكنك الدفاع عنه
اختر المورد الذي نفد وعبّر عن المتطلب بوحداته: أنوية عند نسبة استغلال مستهدفة خلال ساعة الذروة، أو بتات في الثانية في كل اتجاه، أو جلسات متزامنة تحت حدّ تأخير. اترك مجالاً للتحديثات والتشخيص والتعافي، لأن خادماً يجلس على سقفه المقاس لم يبقَ لديه شيء للعمل الذي يُبقيه يعمل. ثم اكتب الأرقام بجانب التهيئة التي أنتجتها، بما في ذلك عدد العملاء والاختبار المستخدم.
رقم المستخدمين لكل نواة هو أقل الأرقام قابلية للنقل في هذا التمرين، لأنه يفترض مزيج بروتوكولات وملف أجهزة لا يشاركه الموقع التالي. احتفظ بالقياس وأسقط الصيغة. عندما يطلب أحدهم سعة لخمسين مستخدماً إضافياً، فإن الإجابة الصادقة هي ملف ساعة الذروة لهؤلاء الخمسين، لا عملية ضرب.
سجّل زمن الاستجابة إلى جانب الإنتاجية. السعة التي تحافظ على النقل الكمي فقط ليست سعة للناس في المكالمات، والمراجعة القادمة ستسأل عن الفرق.
اختر بين التوسع رأسياً وتقسيم الدور
حين يكون الحدّ المقاس نواة واحدة، فقد لا تساعد أنوية أكثر بالسرعة نفسها؛ وقد تساعد نواة أسرع أو نموذج عامل مختلف. وحين يكون الحدّ إجمالي وحدة المعالجة المركزية، فإن نسخة أكبر هي الحل المباشر. وحين يكون الحدّ وصلة الوصول، لا يساعد أي تغيير في الخادم وتنتهي المقارنة عند المزود. تقسيم دوري الويب وVPN على مضيفين منفصلين يشتري العزل بثمن سطح إدارة ثانٍ.
قارن تلك الخيارات بالرقم المسجّل لا ببعضها. التغيير الذي يضاعف مورداً لم يكن هو القيد هو تكلفة بلا فائدة، والسجل هو ما يتيح لك قول ذلك دون جدال. أعد القياس بعد التغيير بالحمل نفسه، وإلا فقد استبدلت تخميناً بآخر.