المحتويات

المقدمة

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

المتطلبات

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

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

المشكلة

إجراء إدارة المحكم في مجموعة النسخ المتماثلة

المقدمة

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

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

المتطلبات

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

- لينكس

- CPS

- مونغو دي بي

ملاحظة: توصي 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