Procedure om Arbiter Node te beheren in CPS Replica Set

Inleiding

Dit document beschrijft de procedure voor het beheer van de Arbiter-knooppunt in Cisco Policy Suite (CPS) Replica Set.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Linux
• CPS
• Mongo DB

Opmerking: Cisco raadt aan dat u bevoorrechte toegang tot CPS CLI moet hebben.

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• COPS 20,2
• Unified Computing System (UCS)-B
• MongoDB v3.6.17 en v3.4.16

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

CPS maakt gebruik van MongoDB om de basisdatabase (DB) structuur te vormen. Het beschikt over meerdere replica sets voor verschillende doeleinden: ADMIN, Subscriber Profile Repository (SPR), Balance, Session, Reporting, en AUDIT.

Een replicaset in MongoDB is een groep van monochroom processen die dezelfde dataset onderhouden. Replica sets bieden redundantie en hoge beschikbaarheid (HA). Met meerdere kopieën van gegevens op verschillende DB-servers, maakt het loadshare leesbewerkingen mogelijk.

In sommige omstandigheden (zoals je hebt een primaire en een secundaire maar kosten beperkingen verbieden de toevoeging van een andere secundaire), kunt u ervoor kiezen om een goed voorbeeld toe te voegen aan een replica geplaatst als een arbiter om te stemmen in verkiezingen. Een arbiter heeft precies 1 stem. Standaard heeft een arbiter prioriteit 0.

Arbiters zijn goede instanties die deel uitmaken van een replicaset maar geen gegevens bevatten (wat betekent dat ze geen data-redundantie leveren). Ze kunnen echter wel deelnemen aan verkiezingen. Een scheidsrechter neemt deel aan de verkiezingen voor de eerste scheidsrechter, maar een scheidsrechter heeft geen kopie van de gegevensverzameling en kan geen eerste scheidsrechter worden.

Arbiters hebben minimale resourcevereisten en hebben geen speciale hardware nodig. U kunt een scheidsrechter inzetten op een toepassingsserver of een host die alleen het netwerk controleert.

Een arbiter slaat geen gegevens op, maar totdat het arbiter mongod-proces is toegevoegd aan de replica-set, handelt de arbiter als elk ander monogod-proces en start-up met een set van gegevensbestanden en een full-size tijdschrift.

Hier is een voorbeeldreplica, dat is 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 |
|----------------------------------------------------------------------------------------------------------------------------------------|

Probleem

Stel dat er een probleem is met een arbiter of een vereiste om de arbiter in een replicaset te wijzigen, dan moet u de huidige arbiter verwijderen en een nieuwe arbiter aan de replicaset toevoegen.

Procedure om scheidsrechter in een Replica Set te beheren

Stap 1. Controleer de mongo shell versie in CPS en de nieuwe arbiter. Voer deze opdracht uit vanaf de primaire sessiemigr in de replicaset en de nieuwe arbiter-knooppunt.

Voorbeelduitvoer van sessionmgr:

[root@sessionmgr02 ~]# mongo --version
MongoDB shell version v3.6.17

Als de mongo shell versie hetzelfde is in zowel primaire sessionmgr als nieuwe arbiter of als de nieuwe arbiter mongo shell versie hoger is, dan navigeer naar Stap 6.

Anders als de nieuwe versie van de arbiter mongo shell lager is, dan moet u instellen featureCompatibilityVersion als de lagere waarde in de admin database van de replica ingesteld met de volgende stappen.

Steekproef geval waar nieuwe arbiter mongo shell versie lager is dan die van CPS sessionmgr:

[root@pcrfclient02 ~]# mongo --version
MongoDB shell version v3.4.16

Stap 2. Log in op de primaire mongo-instantie van de replicaset. 

Command template:
#mongo --host <sessionmgrXX> --port <Replica Set port>

Sample command:
#mongo --host sessionmgr02 --port 27727

Stap 3. Voer deze opdracht uit om de huidige featureCompatibilityVersion in de admin database van de replica set.

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> 

Stap 4. Deze opdracht uitvoeren op setfeatureCompatibilityVersion als 3.4 in de admin database van de replica set.

set07:PRIMARY> db.adminCommand( { setFeatureCompatibilityVersion: "3.4" } )
{ "ok" : 1 }
set07:PRIMARY> 

Stap 5. Voer deze opdracht uit om te controleren of featureCompatibilityVersion is veranderd in 3.4 in de admin database van de replica set.

set07:PRIMARY> db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
{ "featureCompatibilityVersion" : { "version" : "3.4" }, "ok" : 1 }
set07:PRIMARY> 

Stap 6. Meld u aan bij Cluster Manager en wijzig de /var/qps/config/deploy/csv/AdditionalHosts.csv bestand met nieuwe arbiter details.

#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

Stap 7. Importeer de CSV-configuratie.

#/var/qps/install/current/scripts/import/import_deploy.sh

Stap 8. Verifiëren /etc/hosts die werden bijgewerkt met de informatie van de nieuwe arbiters.

#cat /etc/hosts | grep arbiter

Stap 9. Voer deze opdracht uit op sync /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

Stap 10. Controleer of mon_db-scripts worden gestopt op pcrfclient-VM's.

#monsum | grep mon_db_for

Indien gestopt, is dit het resultaat:

mon_db_for_lb_failover Not monitored Program 
mon_db_for_callmodel Not monitored Program

Indien niet gestopt, is dit de output:

mon_db_for_lb_failover OK Program 
mon_db_for_callmodel OK Program

Opmerking: Als mon_db-scripts niet worden gestopt, voert u deze opdrachten uit op de betreffende pcffclient-VM's om ze handmatig te stoppen.

#monit stop mon_db_for_lb_failover 
#monit stop mon_db_for_callmodel

Stap 11. Start deze opdracht vanuit pcrfclient01 om de huidige arbiter uit de replicaset te verwijderen (set07 is een voorbeeld in deze stap).

#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

Stap 12. Voer deze opdracht uit in Cluster Manager om te controleren of de arbiter is verwijderd uit set07, de output van set07 kan de huidige arbiter er niet in hebben.

#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 - -------- -|
|----------------------------------------------------------------------------------------------------------------------------------------|

Stap 13. Werk de mongoConfig.cfg bestand om de juiste arbiter in de aangepaste replicaset te hebben. Vervang de huidige arbiter (ARBITER=arbiter) door de nieuwe arbiter (ARBITER=new-arbiter). Voer deze opdracht uit vanuit Cluster Manager.

#vi /etc/broadhop/mongoConfig.cfg

Huidige configuratie:

[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]

Vereiste configuratie:

[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]

Stap 14. Kopieert de bijgewerkte informatie mongoConfig.cfg bestand op alle VM's. Voer deze opdracht uit vanuit Cluster Manager.

#copytoall.sh /etc/broadhop/mongoConfig.cfg /etc/broadhop/mongoConfig.cfg

Stap 15. Voeg een nieuw arbiter lid toe om te zetten07. Vanuit Cluster Manager uitvoeren /var/qps/install/current/scripts/build/build_etc.sh opdracht om de /etc/directory.

Stap 16. Controleer of het nieuwe arbiter lid wordt toegevoegd aan de replica die is ingesteld nadat u de build_etc.sh script, nu moet u wachten tot de AIDO-server de replica-sets maakt/bijwerkt met de nieuwe arbiter.

#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 |
|-------------------------------------------|

Opmerking: als het nieuwe arbiter-lid niet wordt toegevoegd, gaat u verder met de volgende stappen. Ga verder naar Stap 18.

Stap 17. Voer deze opdracht uit vanuit de Cluster Manager om een nieuw arbiter lid krachtig toe te voegen.

#build_set.sh --DB_NAME --add-members --setname Setxxx --force

Stap 18. Als de arbiter poort nog niet omhoog is, voer dit commando uit de nieuwe arbiter knooppunt om hetzelfde te starten.

Command syntax:
#/etc/init.d/sessionmgr-XXXXX start

Sample command:
#/etc/init.d/sessionmgr-27727 start

Stap 19. Controleer dat de nieuwe Arbiter met succes wordt toegevoegd.

#diagnostics.sh --get_replica_status

Stap 20. Voer deze opdracht uit vanuit Cluster Manager om de DB-prioriteit dienovereenkomstig bij te werken.

# 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

Stap 21. Voer deze opdracht uit vanuit Cluster Manager om de wijzigingen in de replicaset te verifiëren.

#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 |
|-------------------------------------------|

Stap 22. Controleer of mon_db-scripts worden teruggezet op de pcrfclient-VM's. Als dit niet het geval is, moet u deze handmatig starten.

#monsum | grep mon_db_for

Log in op alle phecfclient-VM's om het mon_db-script in te schakelen en voer de volgende opdrachten uit:

# monit start mon_db_for_lb_failover 
# monit start mon_db_for_callmodel