المقدمة
يصف هذا المستند إجراء إدارة عقدة المحكم في مجموعة النسخ المتماثلة ل Cisco Policy Suite (CPS).
المتطلبات الأساسية
المتطلبات
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
ملاحظة: توصي Cisco بأن يكون لديك حق الوصول إلى جذر الامتياز إلى واجهة سطر الأوامر (CLI) ل CPS.
المكونات المستخدمة
تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:
- CPS 20.2
- نظام الحوسبة الموحدة (UCS)-B
- MongoDB الإصدار 3.6.17 و V3.4.16
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
معلومات أساسية
يستخدم مكتب خدمات الرقابة الداخلية قاعدة بيانات MongoDB لتشكيل هيكل قاعدة البيانات الأساسية. وهو يحتوي على مجموعات نسخ متماثلة متعددة لأغراض مختلفة: Admin ومستودع ملف تعريف المشترك (SPR) والرصيد والجلسة وإعداد التقارير والمراجعة.
مجموعة النسخ المتماثلة في MongoDB هي مجموعة من العمليات أحادية الإتجاه التي تحافظ على نفس مجموعة البيانات. توفر مجموعات النسخ المتماثلة التكرار والتوفر العالي (HA). ومع وجود نسخ متعددة من البيانات على خوادم DB مختلفة، فإنها تسمح بعمليات قراءة LoadShare.
في بعض الظروف (مثل أن لديك مركز رئيسي وآخر ثانوي ولكن قيود التكلفة تمنع إضافة مركز ثانوي آخر)، يمكنك إختيار إضافة مثيل لآلهة واحدة إلى مجموعة مماثلة كحكم للتصويت في الانتخابات. والحكم لديه صوت انتخابي واحد بالضبط. وبشكل افتراضي، يكون للمحكم الأولوية 0.
التحكيم هي مثيلات أحادية الإتجاه تشكل جزءا من مجموعة نسخ متماثلة ولكنها لا تحتوي على بيانات (مما يعني أنها لا توفر بيانات مكررة). ولكن يمكنهم المشاركة في الانتخابات. ويشارك محكم في الانتخابات بالنسبة للأساسي، ولكن المحكم لا يملك نسخة من مجموعة البيانات ولا يمكنه أن يصبح محكما أوليا.
يحتاج المحكمون إلى الحد الأدنى من الموارد ولا يحتاجون إلى أجهزة مخصصة. يمكنك نشر وسيط على خادم تطبيق أو مضيف يراقب الشبكة فقط.
لا يخزن المحكم البيانات، ولكن إلى أن تضاف عملية حكم الأحادية إلى مجموعة النسخ المتماثلة، يتصرف المحكم مثل أي عملية أخرى من عمليات الإله الأحادي ويبدأ في مجموعة من ملفات البيانات ومجلة كاملة الحجم.
هذه عينة من مجموعة النسخ المتماثلة، وهي set07
.
| SET NAME - PORT : IP ADDRESS - REPLICA STATE - HOST NAME - HEALTH - LAST SYNC -PRIORITY
|----------------------------------------------------------------------------------------------------------------------------------------|
| SESSION:set07 |
| Status via arbitervip:27727 sessionmgr01:27727 sessionmgr02:27727 |
| Member-1 - 27727 : - SECONDARY - sessionmgr01 - ON-LINE - 0 sec - 2 |
| Member-2 - 27727 : 192.168.10.146 - ARBITER - arbitervip - ON-LINE - -------- - 0 |
| Member-3 - 27727 : - PRIMARY - sessionmgr02 - ON-LINE - -------- - 3 |
|----------------------------------------------------------------------------------------------------------------------------------------|
المشكلة
لنفترض أن هناك مشكلة مع وسيط أو متطلب لتغيير الحكم في مجموعة نسخ متماثلة، ثم يجب إزالة المحكم الحالي وإضافة وسيط جديد إلى مجموعة النسخ المتماثلة.
إجراء إدارة المحكم في مجموعة النسخ المتماثلة
الخطوة 1. تحقق من إصدار shell الأحادي في CPS والحكم الجديد. قم بتشغيل هذا الأمر من جلسة العمل الأساسية في مجموعة النسخ المتماثلة وعقدة المحكم الجديد.
نموذج إخراج من sessionMgr:
[root@sessionmgr02 ~]# mongo --version
MongoDB shell version v3.6.17
إذا كان إصدار shell mongo هو نفسه في كل من Primary SessionMgr و Arbiter جديد أو إذا كان إصدار Arbiter Mongo Shell الجديد أعلى، بعد ذلك انتقل إلى الخطوة 6.
وإلا إذا كان إصدار المحكم الجديد من قشرة مونغو أقل، فيجب عليك تعيين featureCompatibilityVersion
كقيمة أقل في قاعدة بيانات المسؤول لمجموعة النسخ المتماثلة مع الخطوات التالية.
نموذج حالة حيث يكون إصدار Unicgo Shell الجديد أقل من إصدار CPS SessionMgr:
[root@pcrfclient02 ~]# mongo --version
MongoDB shell version v3.4.16
الخطوة 2. قم بتسجيل الدخول إلى مثيل مونغو الأساسي لمجموعة النسخ المتماثلة.
Command template:
#mongo --host <sessionmgrXX> --port <Replica Set port>
Sample command:
#mongo --host sessionmgr02 --port 27727
الخطوة 3. قم بتشغيل هذا الأمر لعرض الحالي featureCompatibilityVersion
في قاعدة بيانات المسؤول لمجموعة النسخ المتماثلة.
set07:PRIMARY> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
{
"featureCompatibilityVersion" : {
"version" : "3.6"
},
"ok" : 1,
"operationTime" : Timestamp(1663914140, 1),
"$clusterTime" : {
"clusterTime" : Timestamp(1663914140, 1),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}
set07:PRIMARY>
الخطوة 4. تشغيل هذا الأمر إلى setfeatureCompatibilityVersion
ك 3.4 في قاعدة بيانات المسؤول لمجموعة النسخ المتماثلة.
set07:PRIMARY> db.adminCommand( { setFeatureCompatibilityVersion: "3.4" } )
{ "ok" : 1 }
set07:PRIMARY>
الخطوة 5. قم بتشغيل هذا الأمر للتحقق من ذلك featureCompatibilityVersion
تم التغيير إلى 3.4 في قاعدة بيانات المسؤول لمجموعة النسخ المتماثلة.
set07:PRIMARY> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
{ "featureCompatibilityVersion" : { "version" : "3.4" }, "ok" : 1 }
set07:PRIMARY>
الخطوة 6. قم بتسجيل الدخول إلى "إدارة نظام المجموعة" وقم بتعديل /var/qps/config/deploy/csv/AdditionalHosts.csv
ملف بتفاصيل وسيط جديد.
#vi /var/qps/config/deploy/csv/AdditionalHosts.csv
Provide new arbiter details in this format:
Host Alias IP Address
new-arbiter new-arbiter xx.xx.xx.xx
الخطوة 7. إستيراد تكوين CSV.
#/var/qps/install/current/scripts/import/import_deploy.sh
الخطوة 8. التحقق من الصحة /etc/hosts
التي تم تحديثها بمعلومات المحكمين الجدد.
#cat /etc/hosts | grep arbiter
الخطوة 9. تشغيل هذا الأمر للمزامنة /etc/hosts
.
#/var/qps/bin/update/synchosts.sh
Syncing to following QNS Servers:
lb01 lb02 sessionmgr01 sessionmgr02 qns01 qns02 pcrfclient01 pcrfclient02
Do you want to Proceed? (y/n):y
lb01
lb02
sessionmgr01
sessionmgr02
qns01
qns02
pcrfclient01
pcrfclient02
الخطوة 10. تحقق من إيقاف برامج MON_DB النصية على VMs ل PCRFCLIENT.
#monsum | grep mon_db_for
إن توقف، هذا هو المخرج:
mon_db_for_lb_failover Not monitored Program
mon_db_for_callmodel Not monitored Program
إذا لم يتم إيقاف، هذا هو المخرج:
mon_db_for_lb_failover OK Program
mon_db_for_callmodel OK Program
ملاحظة: إذا لم يتم إيقاف برامج MON_DB النصية، فقم بتشغيل هذه الأوامر على أجهزة VM الخاصة ب pcfClient لإيقافها يدويا.
#monit stop mon_db_for_lb_failover
#monit stop mon_db_for_callmodel
الخطوة 11. قم بتشغيل هذا الأمر من pcrfclient01 لإزالة الوسيط الحالي من مجموعة النسخ المتماثلة (المجموعة 07 هي مثال في هذه الخطوة).
#build_set.sh --session --remove-members --setname set07
Please enter the member details which you going to remove from the replica-set
Member:Port --------> arbitervip:27727
arbitervip:27727
Do you really want to remove [yes(y)/no(n)]: y
الخطوة 12. قم بتشغيل هذا الأمر من "إدارة نظام المجموعة" للتحقق مما إذا كان قد تم إزالة الوسيط من set07
، ومخرج set07
لا يمكن أن يكون له الحكم الحالي فيها.
#diagnostics.sh --get_replica_status
Expected output:
----------|
|----------------------------------------------------------------------------------------------------------------------------------------|
| SESSION:set07 |
| Status via sessionmgr01:27727 sessionmgr02:27727 |
| Member-1 - 27727 : - SECONDARY - sessionmgr01 - ON-LINE - 0 sec -|
| Member-2 - 27727 : - PRIMARY - sessionmgr02 - ON-LINE - -------- -|
|----------------------------------------------------------------------------------------------------------------------------------------|
الخطوة 13. تحديث mongoConfig.cfg
الملف الذي يحتوي على المحكم المناسب في مجموعة النسخ المتماثلة المعدلة. استعاض عن المحكم الحالي (المحكم = المحكم) بالمحكم الجديد (المحكم = الجديد). قم بتشغيل هذا الأمر من إدارة نظام المجموعة.
#vi /etc/broadhop/mongoConfig.cfg
التكوين الحالي:
[SESSION-SET2]
SETNAME=set07
OPLOG_SIZE=5120
ARBITER=arbitervip:27727
ARBITER_DATA_PATH=/var/data/sessions.7
MEMBER1=sessionmgr02:27727
MEMBER2=sessionmgr01:27727
DATA_PATH=/var/data/sessions.1/2
[SESSION-SET2-END]
التكوين المطلوب:
[SESSION-SET2]
SETNAME=set07
OPLOG_SIZE=5120
ARBITER=new-arbiter:27727
ARBITER_DATA_PATH=/var/data/sessions.7
MEMBER1=sessionmgr02:27727
MEMBER2=sessionmgr01:27727
DATA_PATH=/var/data/sessions.1/2
[SESSION-SET2-END]
الخطوة 14. نسخ المحدث mongoConfig.cfg
ملف إلى كل VMs. قم بتشغيل هذا الأمر من إدارة نظام المجموعة.
#copytoall.sh /etc/broadhop/mongoConfig.cfg /etc/broadhop/mongoConfig.cfg
الخطوة 15. قم بإضافة عضو حكم جديد لتعيين 07. من Cluster Manager، شغل /var/qps/install/current/scripts/build/build_etc.sh
أمر من أجل بناء /etc/directory
.
الخطوة 16. تحقق من إضافة عضو المحكم الجديد إلى مجموعة النسخ المتماثلة بعد تشغيل build_etc.sh
برنامج نصي، الآن يجب عليك الانتظار حتى يقوم خادم AIDO بإنشاء/تحديث مجموعات النسخ المتماثلة مع الوسيط الجديد.
#diagnostics.sh --get_replica_status
Expected Output:
| SET NAME - PORT : IP ADDRESS - REPLICA STATE - HOST NAME - HEALTH - LAST SYNC -PRIORITY
|----------------------------------------------------------------------------------------------------------------------------------------|
| SESSION:set07 |
| Status via arbitervip:27727 sessionmgr01:27727 sessionmgr02:27727 |
| Member-1 - 27727 : - SECONDARY - sessionmgr01 - ON-LINE - 0 sec - 2 |
| Member-2 - 27727 : xx.xx.xx.xx - ARBITER - new-arbiter - ON-LINE - -------- - 0 |
| Member-3 - 27727 : - PRIMARY - sessionmgr02 - ON-LINE - -------- - 3 |
|-------------------------------------------|
ملاحظة: إذا لم تتم إضافة عضو المحكم الجديد، فتابع الخطوات التالية. انتقل أيضا إلى الخطوة 18.
الخطوة 17. قم بتشغيل هذا الأمر من مدير نظام المجموعة لإضافة عضو وسيط جديد بقوة.
#build_set.sh --DB_NAME --add-members --setname Setxxx --force
الخطوة 18. إذا لم يكن منفذ المحكم قيد التشغيل بعد، فقم بتشغيل هذا الأمر من عقدة المحكم الجديد لبدء التشغيل نفسه.
Command syntax:
#/etc/init.d/sessionmgr-XXXXX start
Sample command:
#/etc/init.d/sessionmgr-27727 start
الخطوة 19. تحقق من إضافة المحكم الجديد بنجاح.
#diagnostics.sh --get_replica_status
الخطوة 20. قم بتشغيل هذا الأمر من "إدارة المجموعة" لتحديث أولوية DB وفقا لذلك.
# cd /var/qps/bin/support/mongo/
# ./set_priority.sh --db session
# ./set_priority.sh --db spr
# ./set_priority.sh --db admin
# ./set_priority.sh --db balance
# ./set_priority.sh --db audit
# ./set_priority.sh --db report
الخطوة 21. قم بتشغيل هذا الأمر من "إدارة نظام المجموعة" للتحقق من التغييرات في مجموعة النسخ المتماثلة.
#diagnostics.sh --get_replica_status
Expected Output:
| SET NAME - PORT : IP ADDRESS - REPLICA STATE - HOST NAME - HEALTH - LAST SYNC -PRIORITY
|----------------------------------------------------------------------------------------------------------------------------------------|
| SESSION:set07 |
| Status via arbitervip:27727 sessionmgr01:27727 sessionmgr02:27727 |
| Member-1 - 27727 : - SECONDARY - sessionmgr01 - ON-LINE - 0 sec - 2 |
| Member-2 - 27727 : xx.xx.xx.xx - ARBITER - new-arbiter - ON-LINE - -------- - 0 |
| Member-3 - 27727 : - PRIMARY - sessionmgr02 - ON-LINE - -------- - 3 |
|-------------------------------------------|
الخطوة 22. تحقق من إستعادة برامج MON_DB النصية على VMs ل PCRFCLIENT. وإذا لم يكن الأمر كذلك، فيجب عليك بدء تشغيلها يدويا.
#monsum | grep mon_db_for
لتمكين البرنامج النصي mon_db، قم بتسجيل الدخول إلى جميع الأجهزة الافتراضية (VMs) الخاصة ب pcrfClient وقم بتشغيل الأوامر التالية:
# monit start mon_db_for_lb_failover
# monit start mon_db_for_callmodel