معالجة جلسة المشترك في حالة تعيين نسخة متماثلة لجلسة العمل في CPS

المقدمة

يصف هذا المستند معالجة جلسة المشترك في حالة تعيين نسخة متماثلة للجلسة في مجموعة سياسات Cisco (CPS).

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

المتطلبات

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

• لينكس
• CPS
• مونغو دي بي

ملاحظة: cisco يوصي أن أنت ينبغي يتلقى امتياز جذر وصول إلى CPS CLI.

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

تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:

• CPS 20.2
• نظام الحوسبة الموحدة (UCS)-B
• MongoDB-V3.6.17

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

معلومات أساسية

يستخدم CPS MongoDB حيث يتم تشغيل العمليات أحادية الإتجاه على الأجهزة الافتراضية (VMs) ل SESSIONmgr لتكوين بنية قاعدة البيانات الأساسية الخاصة به.

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

يمكنك التحقق في /etc/broadhop/mongoConfig.cfg لتكوين مجموعة النسخ المتماثلة لإعداد CPS الخاص بك.

[SESSION-SET1]
SETNAME=set01a 
OPLOG_SIZE=5120
ARBITER1=arbitervip:27717
ARBITER_DATA_PATH=/var/data/sessions.27717
MEMBER1=sessionmgr01:27717
MEMBER2=sessionmgr02:27717
DATA_PATH=/var/data/sessions.1/d
SHARD_COUNT=4
SEEDS=sessionmgr01:sessionmgr02:27717
[SESSION-SET1-END]

[SESSION-SET7]
SETNAME=set01g
OPLOG_SIZE=5120
ARBITER1=arbitervip:37717
ARBITER_DATA_PATH=/var/data/sessions.37717
MEMBER1=sessionmgr02:37717
MEMBER2=sessionmgr01:37717
DATA_PATH=/var/data/sessions.1/g
SHARD_COUNT=2
SEEDS=sessionmgr02:sessionmgr01:37717
[SESSION-SET7-END]

لدى MongoDB مفهوم آخر يسمى Sharding والذي يساعد التكرار والسرعة لمجموعة. تقوم الحزم بفصل قاعدة البيانات إلى مجموعات مفهرسة مما يتيح سرعة أكبر للكتابة مما يحسن الأداء العام لقاعدة البيانات. غالبا ما يتم إعداد قواعد البيانات التي تم توضيحها بحيث تكون كل حاوية مجموعة نسخ متماثلة.

• تمييز جلسة العمل: بذور نشرات جلسات العمل وقواعد بياناتها:

osgi> listshards

Shard Id Mongo DB State Backup DB Removed Session Count

1 sessionmgr01:27717/session_cache online false false 109306
2 sessionmgr01:27717/session_cache_2 online false false 109730
3 sessionmgr01:27717/session_cache_3 online false false 109674
4 sessionmgr01:27717/session_cache_4 online false false 108957

• تمييز المفتاح الثانوي: يقدم المفتاح الثانوي البذور وقواعد بياناته:
  

osgi> listskshards

Shard Id Mongo DB State Backup DB Removed Session Count

2 sessionmgr02:37717/sk_cache online false false 150306
3 sessionmgr02:37717/sk_cache_2 online false false 149605

المشكلة

الإصدار 1. النمو المضطرد في إستهلاك ذاكرة عضو البيانات بسبب فشل عضو واحد.

عند انخفاض عضو حامل بيانات في 3 أعضاء (2 حامل بيانات + 1 وسيط)، يستمر العضو الوحيد المتبقي الحامل للبيانات في أداء دور المجموعة الأساسية والقابلة للنسخ المتماثل، ولكن مع التحميل الثقيل ومجموعة النسخ المتماثلة دون أي تكرار DB. وببنية PSA مكونة من ثلاثة أعضاء، يزداد ضغط التخزين المؤقت في حالة انخفاض أي عقدة تحمل بيانات. ويؤدي ذلك إلى زيادة ثابتة في إستهلاك الذاكرة للعقدة المتبقية حاملة البيانات (أساسي)، مما قد يؤدي إلى فشل العقدة بسبب استنفاد الذاكرة المتاحة إذا تركت غير مراقبة ويتسبب في نهاية المطاف في فشل مجموعة النسخ المتماثلة.

------------------------------------------------------------------------------------------------
|[SESSION:set01a]|
|[Status via sessionmgr02:27717 ]|
|[Member-1 - 27717 : 192.168.29.100 - ARBITER - arbitervip - ON-LINE
|[Member-2 - 27717 : 192.168.29.35  - UNKNOWN - sessionmgr01 - OFF-LINE 19765 days 
|[Member-3 - 27717 : 192.168.29.36  - PRIMARY - sessionmgr02 - ON-LINE
------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------
|[SESSION:set01g]|
|[Status via sessionmgr02:37717 ]|
|[Member-1 - 37717 : 192.168.29.100 - ARBITER - arbitervip - ON-LINE
|[Member-2 - 37717 : 192.168.29.35  - UNKNOWN - sessionmgr01 - OFF-LINE 19765 days 
|[Member-3 - 37717 : 192.168.29.36  - PRIMARY - sessionmgr02 - ON-LINE
------------------------------------------------------------------------------------------------

الإصدار 2. التأثير على معالجة جلسة العمل بسبب فشل العضو المزدوج.

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

Current setup have problem while connecting to the server on port : 27717

Current setup have problem while connecting to the server on port : 37717

ينتج عن فشل مجموعة النسخ المتماثلة هذه فشل إستدعاء في حالة مجموعات النسخ المتماثلة للجلسة، حيث يتعذر على عمليات معالجة المكالمات ل CPS (عمليات Quantum Network Suite (QNS)) الوصول إلى الجلسات التي تم تخزينها بالفعل في مجموعة النسخ المتماثلة الفاشلة هذه.

الحل

الاقتراب 1. فشل عضو واحد.

يجب أن تكون قادرا على إعادة عضو مجموعة النسخ المتماثلة الفاشل في بنية Primary-Secondary-Arbiter (PSA) مع فترة زمنية قصيرة. في حال استغرق إستعادة عضو تحميل البيانات الفاشل في بنى PSA وقتا، يجب عليك إزالة الفشل.

الخطوة 1.1. حدد عضو تحميل البيانات الفاشلة في مجموعة النسخ المتماثلة المحددة ببنية PSA المكونة من ثلاثة أعضاء. قم بتشغيل هذا الأمر من إدارة نظام المجموعة.

  #diagnostics.sh --get_r

الخطوة 1.2. قم بإزالة البيانات الفاشلة التي تحتوي على عضو من مجموعة النسخ المتماثلة المحددة.

 Syntax:

 Usage: build_set.sh <--option1> <--option2> [--setname SETNAME] [--help]

 option1: Database name
 option2: Build operations (create, add or remove members)

 Example:

 #build_set.sh --session --remove-failed-members --setname set01a --force
 #build_set.sh --session --remove-failed-members --setname set01g --force

الخطوة 1.3. تحقق من إزالة العضو الذي فشل من مجموعة النسخ المتماثلة.

 #diagnostics.sh --get_r

الاقتراب 2. فشل الاعضاء المزدوج.

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

الخطوة 2.1. بما أن مجموعات النسخ المتماثلة للجلسة يتم تخفيضها حيث أن SessionMgr09 و SessionMgr10 معطلة، فيجب عليك إزالة إدخالات مجموعات النسخ المتماثلة هذه من إدخالات سرد جلسة العمل والتقلص من وحدة تحكم OSGI:

#telnet qns0x 9091

osgi> listshards

Shard Id Mongo DB State Backup DB Removed Session Count

1 sessionmgr01:27717/session_cache online false false 109306
2 sessionmgr01:27717/session_cache_2 online false false 109730
3 sessionmgr01:27717/session_cache_3 online false false 109674
4 sessionmgr01:27717/session_cache_4 online false false 108957

osgi> listskshards

Shard Id Mongo DB State Backup DB Removed Session Count
2 sessionmgr02:37717/sk_cache online false false 150306
3 sessionmgr02:37717/sk_cache_2 online false false 149605

الخطوة 2.2. أزل شظايا الجلسة التالية:

 osgi> removeshard 1
 osgi> removeshard 2
 osgi> removeshard 3
 osgi> removeshard 4

الخطوة 2.3. أزل هذه القطع:

osgi> removeskshard 2
osgi> removeskshard 3

الخطوة 2.4.قبل إجراء إعادة التوازن، تحقق من DB المسؤول (تحقق من أن إصدار المثيل مطابق لجميع QNS VMs):

 #mongo sessionmgrxx:xxxx/sharding.     [Note: use the primary sessionmgr hostname and respective port for login]

 #set05:PRIMARY>  db.instances.find()
 { "_id" : "qns02-1", "version" : 961 }
 { "_id" : "qns07-1", "version" : 961 }
 { "_id" : "qns08-1", "version" : 961 }
 { "_id" : "qns04-1", "version" : 961 }
 { "_id" : "qns08-1", "version" : 961 }
 { "_id" : "qns05-1", "version" : 961 }

Note: if the sharding versions (previous output) are different for some QNS instances. For example, if you see:

{ "_id" : "qns08-1", "version" : 961 }
{ "_id" : "qns04-1", "version" : 962 }

قم بتشغيل هذا الأمر على DB الخاص بتوضيح المسؤول (باستخدام اسم المضيف المناسب):

ملاحظة: إذا كنت على عضو ثانوي، فاستخدم rs.slaveOk() للتمكن من تشغيل الأوامر.

[root@casant01-cm csv]#  mongo sessionmgr01:27721/shardin
set05:PRIMARY>
set05:PRIMARY> db.instances.remove({ “_id” : “$QNS_hostname”})


Example:

set05:PRIMARY> db.instances.remove({ “_id” : “qns04-1”})
set05:PRIMARY> exit

الخطوة 2.5. الآن شغل جلسة إعادة التوازن.

Login to osgi console.

#telnet qns0x 9091

osgi>listshards

osgi>rebalance

osgi>rebalancestatus

Verify shards:

osgi>listshards

الخطوة 2.6. قم بتشغيل إعادة توازن القطع الصلبة:

Login to osgi console.

#telnet qns0x 9091

osgi>listskshard

osgi>rebalancesk

osgi>rebalanceskstatus

Verify shards:

osgi>listshards

الخطوة 2.7. قم بإزالة مجموعة النسخ المتماثلة set01a و set01g (تشغيل على نسخ):

#build_set.sh --session --remove-replica-set --setname set01a --force
#build_set.sh --session --remove-replica-set --setname set01g --force

الخطوة 2.8. قم بإعادة تشغيل خدمة QNS (تشغيل على Cluman):

#restartall.sh

الخطوة 2.9. قم بإزالة خطوط set01a و set01g من ملف mongoConfig.cfg. تشغيل هذا على إدارة نظام المجموعة:

#cd /etc/broadhop/
#/bin/cp -p mongoConfig.cfg mongoConfig.cfg_backup_
#vi mongoConfig.cfg

[SESSION-SET1]
SETNAME=set01a 
OPLOG_SIZE=5120
ARBITER1=arbitervip:27717
ARBITER_DATA_PATH=/var/data/sessions.27717
MEMBER1=sessionmgr01:27717
MEMBER2=sessionmgr02:27717
DATA_PATH=/var/data/sessions.1/d
SHARD_COUNT=4
SEEDS=sessionmgr01:sessionmgr02:27717
[SESSION-SET1-END]

[SESSION-SET7]
SETNAME=set01g
OPLOG_SIZE=5120
ARBITER1=arbitervip:37717
ARBITER_DATA_PATH=/var/data/sessions.37717
MEMBER1=sessionmgr02:37717
MEMBER2=sessionmgr01:37717
DATA_PATH=/var/data/sessions.1/g
SHARD_COUNT=2
SEEDS=sessionmgr02:sessionmgr01:37717
[SESSION-SET7-END]

الخطوة 2.10. بعد إزالة الأسطر، احفظ وأخرج.

قم بتشغيل build_etc على Cluster Manager.

#/var/qps/install/current/scripts/build/build_etc.sh

الخطوة 2.11. تحقق من إزالة مجموعة النسخ المتماثلة Set01d من خلال التشخيصات.

#diagnostics.sh --get_r