منطق موازنة التحميل على خادم الاجتماعات من Cisco

المقدمة

يصف هذا المستند منطق موازنة الأحمال لخادم الاجتماعات (CMS) من Cisco (المعروف سابقا باسم منتج Acano) الذي تتم تغطيته على التقرير الرسمي لموازنة الأحمال. يوضح هذا المستند هذه العملية في مخطط انسيابي ويذهب بمزيد من التفاصيل حول خوارزمية التحديد.

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• مكون Cisco Meeting Server Call Bridge (وتجميعها)
• تكوين واجهة برمجة التطبيقات (API) لخادم الاجتماعات من Cisco

المكونات المستخدمة

أسست المعلومة في هذا وثيقة على cisco إجتماع نادل، صيغة 2.4.x.

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

ما هي خوارزمية موازنة التحميل الخاصة ب CMS؟

تم إدخال موازنة الأحمال في الإصدار 2.1 من CMS من أجل الاستخدام الفعال لموارد المؤتمرات. وهو يحاول تقليل عدد مكالمات التوزيع بين "جسور الاتصال" التي تستضيف نفس المساحة. تستند هذه الآلية إلى رأس "الاستبدال" في بروتوكول بدء جلسة عمل (SIP) ويتم دعمها في Cisco Unified Communications Manager (CUCM) كعنصر تحكم في المكالمات. كما يتم دعمه بإصدار ExpressWay X8.11 (أو إصدار أحدث)، بالإضافة إلى إصدار CMS 2.4 أو إصدار أحدث. يمكن أن تكون إستدعاءات CMA (من نوع العميل السميك و WebRTC) متوازنة الأحمال كذلك من الإصدار 2.3 من CMS وما بعده.

ملاحظة: موازنة حمل مكالمات Lync/Skype غير معتمدة في أي إصدار CMS في هذه اللحظة من الوقت وبالتالي لا ينطبق مخطط التدفق هذا.

ملاحظة: ينطبق منطق موازنة الأحمال فقط على المكالمات في مساحات CMS، وبالتالي ليس لاستدعاءات العبارة (مكالمات P2P) أو مكالمات المنزل المزدوج في هذه اللحظة من الوقت.

يتم تمييز عملية موازنة الأحمال في التقرير الرسمي في القسم كيف يستخدم موازنة الأحمال الإعدادات ضمن تكوين "جسور المكالمات" لموازنة حمل المكالمات الواردة. ويتم عرضه بتنسيق نصي ويتم تصوره هنا في المخطط الانسيابي (تنزيل).

يستخدم المخطط الانسيابي بعض الاختصارات والمصطلحات:

• CB = جسر المكالمات
• ExistingConferenceLoadLimit = existingConferenceLoadLimitBasisPoints * loadLimit
  (بشكل افتراضي ال existingConferenceLoadLimitBasePoints تساوي 8000، أي 80٪)
• NewConferenceLoadLimit = newConferenceLoadLimitBasisPoints * loadLimit
  (بشكل افتراضي يساوي NewConferenceLoadLimitBasisPoints 5000، وهو ما يماثل 50٪)

إذا تمت الإشارة إلى MediaProcessingLoad، فإنه ينظر إليه فيما يتعلق بجسر الاتصال المحدد حيث تم توصيل المكالمة. يمكن التحقق من قيمة الحمل هذه باستخدام واجهة برمجة تطبيقات API Access على /system/load في الوقت الفعلي وتعطي تمثيلا للحمولة الفعلية التي تمت معالجتها بواسطة "جسر الاتصال" هذا في تلك اللحظة من الوقت.

إذا انتهيت من إجراء مكالمتك في المربع الموجود في أقصى اليمين، فإنه يعيد توجيه المكالمة إلى الخادم مع إعطاء الأولوية القصوى. قد يكون هذا خادم Call Bridge نفسه أو خادم آخر ضمن مجموعة Call Bridge التي تم الاتصال بها. في حالة عدم إتخاذ أي قرار بناء على الحمل وما إذا كانت المساحة نشطة بالفعل على جسر الاتصال، فهناك إرتباط مع العديد من جسور الاتصال. في هذه الحالة، يتم إتخاذ القرار النهائي بناء على تفضيل "جسر الاستدعاء" الافتراضي الذي يتم تعيينه لكل مساحة. يتم تخصيص تفضيل "جسر الاستدعاء" هذا عند إنشاء المساحة تلقائيا ولا يمكن تكوينه لأنه يستند إلى قيم التجزئة لعدة سمات. وهذا يؤدي إلى توزيع متساوي (عشوائي) للفراغات المختلفة عبر جميع جسور الاتصال.

لعرض تفضيل "جسر المكالمة" لمساحة معينة، ستحتاج إلى التحقق من ذلك في سجل أحداث CMS كما هو موضح في هذه الأمثلة.

أمثلة لخوارزمية موازنة التحميل

يحتوي هذا القسم على أمثلة لسيناريوهات محتملة وكيفية إظهار سجل الأحداث الخاص ب CMS حيث تم الوصول إلى المكالمة لعملية موازنة الأحمال كما هو منصوص عليه في المخطط الانسيابي.

ولهذه الأمثلة، تم إستخدام إعداد مختبر مع مجموعة "جسر الاتصال" المكونة من ثلاثة جسور اتصال. تم تعيين تكوينات ConferenceLoadLimitBasePoints وnewConferenceLoadLimitBasePoints إلى قيمها الافتراضية المقابلة ل 80٪ و 50٪ على التوالي من قيمة loadLimit.

للتحقق من MediaProcessingLoad الحالي على "جسر اتصال" خاص، يمكنك الاستعراض إلى https://<ip-or-fqdn-of-callbridge>:<webadmin-port>/api/v1/system/load وتسجيل الدخول باستخدام حساب API أو المسؤول كما هو معروض على الصورة.

مثال 1: لا يوجد حمل على أي جسر مكالمات

في هذا المثال، لا توجد مكالمات نشطة في أي من جسور الاتصال. وبالتالي فإن MediaProcessingLoad لكافة الخوادم يساوي صفرا.

عند إجراء مكالمة على أحد جسور الاتصال (المجموعة 1 هنا) (مع تمكين موازنة الأحمال على كل من CMS وأجهزة التحكم في المكالمات)، يمكنك مشاهدة سجل الأحداث على جسر الاتصال حيث تم الوصول:

2018-12-29  10:51:29.490  Info     call 75: incoming SIP call from "sip:1060@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  10:51:29.565  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  10:51:29.712  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 0, conference is running: 0)
2018-12-29  10:51:29.717  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 0, conference is running: 0)
2018-12-29  10:51:29.717  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using remote server 'cluster3' (priority: 0, load level: 0, conference is running: 0)
2018-12-29  10:51:29.717  Info     replacing call 'f8eeea46e0f0790a@10.10.50.13' to conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93 on server 'cluster3'
2018-12-29  10:51:29.876  Info     call 75: ending; remote SIP cancel (remote cancel) - not connected after 0:00

التي يمكنك فيها رؤية بنود إستبدال الاستعلام لكل من "جسور المكالمة" في مجموعة "جسر المكالمة" التي تعرض لنا خوارزمية موازنة التحميل التي يتم تقسيمها في ثلاثة أقسام:

• الأولوية - تفضيل جسر الاتصال لهذا المكان
• مستوى التحميل - مستوى حمل الاتصال في تلك اللحظة من الوقت
• المؤتمر قيد التشغيل - تحديد ما إذا كانت المساحة نشطة على جسر الاتصال هذا

وبما أنه لم يتم إجراء أي مكالمات في ذلك الوقت داخل النظام، فلا يوجد أي حمل على أي من الأنظمة (جميعها صفر) ولا يعمل المؤتمر في أي مكان (جميعها صفر). وفي هذا الصدد، يتخذ القرار النهائي استنادا إلى تفضيل المكان على جسر الاتصال. يتم تفضيل أولوية أقل، وبالتالي يتم إستبدال المكالمة هنا لاستدعاء Bridge باسم Cluster3 كما هو موضح من قبل سطر الاستدعاء البديل.

في "نظام المجموعة 3 ل Call Bridge"، يمكنك مشاهدة بنود سجل الأحداث التي تشير إلى إستدعاء الاستبدال هذا (بالإضافة إلى ما هو اتصال Bridge الذي جاء منه (نظام المجموعة 1 هنا) ونفس معرف المؤتمر ومعرف المكالمة):

2018-12-29  10:51:29.784  Info     replacing call 'f8eeea46e0f0790a@10.10.50.13' from server 'cluster1' into conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93
2018-12-29  10:51:29.787  Info     call 193: outgoing SIP call to "1060@steven.lab" from space "Steven Janssens's space"
2018-12-29  10:51:29.792  Info     call 193: setting up UDT RTP session for DTLS (combined media and control)
2018-12-29  10:51:29.909  Info     call 193: compensating for far end not matching payload types
2018-12-29  10:51:29.911  Info     participant "1060@steven.lab" joined space bc218bfb-3bda-44f6-89a7-80d8dd616a80 (Steven Janssens's space)

في حالة هبوط المكالمة بالفعل على "جسر الاتصال" مع أقل قيمة أولوية (نظام المجموعة 3 هنا لهذه المساحة)، لا يزال بإمكانك رؤية نفس أسطر الاستعلام للاستبدال في سجل الأحداث ولكن يشير الآن إلى أنه يستخدم الخادم المحلي ولا يوجد سطر اتصال بديل:

2018-12-29  11:05:25.202  Info     call 194: incoming SIP call from "sip:1060@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  11:05:25.233  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 0, conference is running: 0)
2018-12-29  11:05:25.376  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 0, conference is running: 0)
2018-12-29  11:05:25.378  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  11:05:25.378  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using local server 'cluster3' (priority: 0, load level: 0, conference is running: 0)
2018-12-29  11:05:25.380  Info     call 194: setting up UDT RTP session for DTLS (combined media and control)
2018-12-29  11:05:25.404  Info     participant "1060@steven.lab" joined space bc218bfb-3bda-44f6-89a7-80d8dd616a80 (Steven Janssens's space)

مثال 2: يوجد بالفعل مشاركون على المساحة في مجموعة جسر الاتصال

في هذا المثال، تكون المساحة نشطة بالفعل داخل مجموعة جسر الاتصال كنقطة نهاية 1060@steven.lab يتم استدعاؤها إلى المساحة كما هو موضح في المثال 1.

في هذه الحالة حالتان:

1. يحتوي "جسر الاتصال" الذي يستضيف هذه المساحة على حمل أقل من حد المؤتمرات الحالي وبالتالي فهو قادر على قبول المكالمة.

2. يحتوي Call Bridge الذي يستضيف هذه المساحة على حمل أعلى من عتبة المؤتمر الحالية، ومن ثم تحاول CMS إستبدال الاستدعاء إلى "جسر اتصال" آخر.

السيناريو 1. مساحة نشطة وتحميل أقل من حد المؤتمرات الموجود (80٪)

في حالة هبوط المكالمة على "جسر الاتصال" حيث لم تكن المساحة نشطة بعد، يظهر سجل الأحداث الآن أن المساحة نشطة على "جسر المكالمة" باستخدام مجموعة الأسماء 3. ونظرا لأن المساحة نشطة هناك وأن الحمل على ذلك الخادم أقل من الحد الحالي (مستوى التحميل: 0)، يتم إستبدال الاستدعاء.

2018-12-29  11:48:17.419  Info     call 82: incoming SIP call from "sip:800999@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  11:48:17.477  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  11:48:17.607  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 0, conference is running: 0)
2018-12-29  11:48:17.607  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 0, conference is running: 1)
2018-12-29  11:48:17.607  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using remote server 'cluster3' (priority: 0, load level: 0, conference is running: 1)
2018-12-29  11:48:17.607  Info     replacing call '4c28197eaebba178@10.10.2.250' to conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93 on server 'cluster3'

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

السيناريو 2. مساحة نشطة وتحميل أعلى من حد المؤتمرات الموجود (80٪)

في هذه الحالة، لا يتم إستبدال المكالمة ب "جسر الاتصال" هذا، ولكنها تبحث عن "جسر اتصال" آخر داخل المجموعة التي لا تزال تتوفر لديها بعض الموارد. فهي أولا تتحقق من وجود جسور اتصال يقل حمولها عن 50٪ (عتبة مؤتمرات جديدة) وتحملها أولا. وإذا لم يكن هناك أي منها تحت هذه العتبة، فإنه يتحقق مما إذا كانت لا تزال متوفرة تحت 80٪ (حد المؤتمرات الحالي).

إذا تم التحقق من الحمل على مجموعة Call Bridge 3 بعد إستدعاءات الأمثلة 1 و 2 (السيناريو 1)، فإنه يعرض حمل من 2000.

بافتراض تعيين LoadLimit لمجموعة Call Bridge 3 هذه على 2250 (كمثال فقط)، فيكون Call Bridge هذا أعلى من حد المؤتمرات الحالي حيث يتم حسابه على أنه 0.80 * 2250 = 1800

ولا تزال هناك حالتان يتعين التفريق بينهما في هذا السيناريو.

الحالة 1: لا يزال عدد من الخوادم في المجموعة يقل حملها عن الحد الأدنى لعقد المؤتمرات الجديد (50٪)

لا يوجد لدى الخادمين الآخرين في المجموعة أية مكالمات تتم معالجتها حتى الآن، لذلك لا يزال الحمل عند 0 وبالتالي يمكن لكلا الخادمين معالجة المكالمة. يتم إتخاذ قرار النهاية بناء على تفضيل "جسر الاتصال" لهذا الحيز. نظرا لأن نظام المجموعة 3 من Call Bridge ممتلئ بالفعل، تختار الأنظمة أقل أولوية من نظام المجموعة 1 ونظام المجموعة 2، وهما نظام المجموعة 1 في هذه الحالة.

2018-12-29  12:11:03.211  Info     call 86: incoming encrypted SIP audio call from "sip:2001@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  12:11:03.263  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  12:11:03.405  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 0, conference is running: 0)
2018-12-29  12:11:03.412  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 2, conference is running: 1)
2018-12-29  12:11:03.412  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using local server 'cluster1' (priority: 1, load level: 0, conference is running: 0)
2018-12-29  12:11:03.415  Info     call 86: setting up UDT RTP session for DTLS (combined media and control)
2018-12-29  12:11:03.434  Info     participant "2001@steven.lab" joined space bc218bfb-3bda-44f6-89a7-80d8dd616a80 (Steven Janssens's space)

لاحظ أن مستوى التحميل: 2 على Cluster3 Call Bridge يشير إلى أنه تجاوز عتبة المؤتمرات الحالية، لذا فعلى الرغم من أن المساحة كانت نشطة هناك، فإن المكالمة لا يتم تحميلها بشكل متوازن إلى ذلك الخادم. وبدلا من ذلك، يبحث في أدنى أولوية لمساحة جسور الاتصال الأخرى ذات مستوى التحميل: 0 (أي أقل من 50٪ إستخدام)، وهو المجموعة 1 في هذه الحالة.

الحالة 2: خادم واحد فقط في مجموعة ذات حمل أقل من حد المؤتمرات الجديد (50٪) أو حد المؤتمرات الحالي (80٪)

بعد الاستدعاء الأخير (والاستدعاءات لمساحة أخرى إلى المجموعة 2)، تم مشاهدة الأحمال الموضحة على جسور الاتصال:

• المجموعة 1 - 1200
• المجموعة 2 - 400
• المجموعة 3 - 4000

بافتراض الآن أن LoadLimit كما تم تعيينه على Cluster1 Call Bridge سيكون 1300، ثم أن Call Bridge هذا يتجاوز عتبة المؤتمرات الجديدة حيث يتم حسابه على أنه 0.50 * 1300 = 650 وكذلك فوق عتبة المؤتمرات الحالية التي تبلغ 0.80 * 1300 = 1040.

في حالة ظهور إستدعاء جديد ل WebRTC الآن على Call Bridge Cluster3 لنفس المساحة، فإن المساحة نشطة على كل من المجموعة 1 والمجموعة 3 ولكن كلاهما يتجاوز عتبة المؤتمرات الحالية ومن ثم فإنه يبحث عن خادم آخر تحت عتبة المؤتمرات الجديدة (50٪) أو عتبة المؤتمرات الحالية (80٪). وفي هذه الحالة، فإن المجموعة 2 فقط هي التي تظل تحت عتبة المؤتمرات الحالية، ولكنها تتجاوز عتبة المؤتمرات الجديدة بالفعل بسبب إستدعاء آخر إلى مساحة أخرى تتم معالجتها على Cluster2 Call Bridge.

2018-12-29  12:45:33.162  Info     instantiating user "guest1685904798@cluster.steven.lab"
2018-12-29  12:45:33.162  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 2, conference is running: 1)
2018-12-29  12:45:33.299  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster1' (priority: 1, load level: 2, conference is running: 1)
2018-12-29  12:45:33.299  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 1, conference is running: 0)
2018-12-29  12:45:33.299  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using remote server 'cluster2' (priority: 2, load level: 1, conference is running: 0)

تم إعداد نظام المجموعة 2 بقيمة loadLimit 600 هنا. ومع وجود 400 حمل حالي قبل أن تصل الدعوة الجديدة، فإنه يتجاوز عتبة المؤتمر الجديدة 0.5 * 600 = 300، ولكنه لا يزال تحت الحد الحالي للمؤتمرات وهو 0.8 * 600 = 480. وبالتالي يظهر هذا في الاستعلام إستبدال على أنه مستوى حمل: 1 (بدلا من 2 عندما يكون Call Bridge أعلى من الحد البالغ 80٪).

المثال 3: الاتصال بهبوط على جسر فوق عتبة المؤتمرات الحالية

في هذه الحالة، لا تتم خوارزمية موازنة التحميل حيث إنه من الأفضل إرسال إستجابة رقم 488 مرة أخرى إلى جهاز التحكم في المكالمات الذي يمكن أن يقرر بعد ذلك محاولة توجيه المكالمة إلى "جسر اتصال" مختلف داخل المجموعة (والذي يمكن أن يكون أقل من حد 80٪) أو حتى توجيهها إلى مجموعة "جسر اتصال" مختلفة إذا كانت المجموعة الحالية خارج الموارد (كخيار إحتياطي).

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

2018-12-29  12:49:13.352  Info     call 88: incoming encrypted SIP call from "sip:2020@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  12:49:13.399  Info     call 88: ending; local teardown, system participant limit reached - not connected after 0:00

بمجرد إرسال المكالمة إلى "جسر اتصال" مختلف يمكنه معالجة الحمل (نظام المجموعة 2 على سبيل المثال)، يتم عرض نفس خوارزمية موازنة الأحمال:

2018-12-29  12:49:13.434  Info     call 624: incoming encrypted SIP call from "sip:2020@steven.lab" to local URI "sip:stejanss.space@cluster.steven.lab"
2018-12-29  12:49:13.475  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster2' (priority: 2, load level: 1, conference is running: 0)
2018-12-29  12:49:13.614  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: response from 'cluster3' (priority: 0, load level: 2, conference is running: 1)
2018-12-29  12:49:13.614  Info     replace query for conference 4d2542b2-8e72-45f5-a66c-f8a95f355f93: using local server 'cluster2' (priority: 2, load level: 1, conference is running: 0)
2018-12-29  12:49:13.618  Info     call 624: setting up UDT RTP session for DTLS (combined media and control)
2018-12-29  12:49:13.621  Info     call 624: starting DTLS UDT media negotiation (as initiator)
2018-12-29  12:49:13.640  Info     participant "2020@steven.lab" joined space bc218bfb-3bda-44f6-89a7-80d8dd616a80 (Steven Janssens's space)

ملاحظة: في حالة مكالمات العبارة، ترجع CMS رسالة خطأ SIP رقم 486 بدلا من ذلك. بشكل افتراضي، يقوم CUCM بإيقاف التوجيه وفقا لمعلمة الخدمة الخاصة بإيقاف التوجيه على علامة "مشغول المستخدم" لذلك قد ترغب في تغيير هذا الإعداد للسماح باستدعاءات العبارة إلى CallBridges الأخرى الخاصة بك.