Inhoud

Inleiding

Problemen oplossen

Procedures voor herstel van sessieManager

Session Manager uit de SHUTOFF-staat inschakelen

Alle instanties uit de staat FOUTMER herstellen

Session Manager/MongoDB-herstel

Lidstaat van de Kopie in de offline-staat

Lid(s) van dublo’s die zich gedurende lange tijd in de opstartstaat bevinden

Heropbouw van replica-sets

De database terugzetten vanaf back-uppostset

Inleiding

Dit document beschrijft de Session Manager-herstelprocedure die is toegepast voor Ultra-M/OpenStack-implementaties.

Problemen oplossen

Procedures voor herstel van sessieManager

Session Manager uit de SHUTOFF-staat inschakelen

Als een geval zich in de SHUTOFF-staat bevindt als gevolg van een geplande sluiting of een andere reden, gebruik dan deze procedure om de instantie te starten en ITß€™s monitoring in ESC mogelijk te maken.

1. Controleer de staat van voorbeeld via OpenStack

source /home/stack/destackovsrc-Pcrf

nova list --fields name,host,status | grep sm-s1

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | destackovs-compute-2  | SHUTOFF|

2. Controleer of de computer beschikbaar is en zorg ervoor dat de status omhoog is.

source /home/stack/destackovsrc

nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’

| state                     | up                                       |

| status                    | enabled                                  |

3. Meld u aan bij Elastic Services Controller (ESC) Master as Admin user en controleer de status van de instantie in opgegevens.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep sm-s1_0

SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 VM_ERROR_STATE

4. Inschakelen uit openstack

source /home/stack/destackovsrc-Pcrf

nova start SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226
.

5. Wacht vijf minuten om bijvoorbeeld op te starten en actief te zijn.

source /home/stack/destackovsrc-Pcrf

nova list –fields name,status | grep sm-s1_0

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | ACTIVE |

6. VM Monitor in ESC inschakelen nadat deze optie actief is.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

Voor de verdere invordering van bijvoorbeeld configuraties, zie bijvoorbeeld specifieke procedures die in de volgende paragraaf worden beschreven.

Alle instanties uit de staat FOUTMER herstellen

Deze procedure kan worden gebruikt als de status van CPS-instantie in openstack FOUT is:

1. Controleer de staat van voorbeeld in OpenStack.

source /home/stack/destackovsrc-Pcrf

nova list --fields name,host,status | grep sm-s1

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | destackovs-compute-2  | ERROR|

2. Controleer of de computer beschikbaar is en werkt prima.

source /home/stack/destackovsrc

nova hypervisor-show destackovs-compute-2 | egrep â€˜status|stateâ€™

| state                     | up                                       |

| status                    | enabled                                  |

3. Meld u aan bij ESC Master als beheerder en controleer de status van een voorbeeld in de bestandsindeling.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata | grep sm-s1_0

SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 VM_ERROR_STATE

4. Zet de staat van instantie terug om de instantie terug te dwingen naar een actieve staat in plaats van naar een staat van de fout, herstart uw instantie zodra deze klaar is.

source /home/stack/destackovsrc-Pcrf

nova reset-state â€“active SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

nova reboot â€“-hard  SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

5. Wacht vijf minuten voordat de instantie opstart en naar de actieve toestand komt.

source /home/stack/destackovsrc-Pcrf

nova list â€“fields name,status | grep sm

| c5e4ebd4-803d-45c1-bd96-fd6e459b7ed6 | SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226 | ACTIVE |

6. Als Cluster Manager na de herstart de status van ACTIEF verandert, schakelt u VM-monitor in ESC in nadat Cluster Manager-instantie actief is.

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action ENABLE_MONITOR SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

Na herstel naar actieve/actieve staat, raadpleeg instantie type specifieke procedure om configuratie/gegevens van back-up te herstellen.

Session Manager/MongoDB-herstel

Session Manager biedt de Databaselaag aan Cluster Policy Suite in deze sectie, wordt het herstel van databases op een recent teruggevonden exemplaar van sessiebeheerder besproken:

Lidstaat van de Kopie in de offline-staat

Indien lid(en) van een replica-set in offline staat zijn, gebruik dan deze procedure:

1. Controleer de status van replica met deze opdracht op Cluster Manager.

diagnostics.sh --get_replica_status

2. Geef alle OFF-LIJNleden op in alle replica-sets.

3. Start de opdracht op Cluster Manager.

cd /var/qps/bin/support/mongo

build_set.sh --all --create-scripts

4. Bevestig de schelp aan de sessionhouder en start het mongoproces.

ssh sessionmgrXX

/etc/init.d/sessionmgr-XXXXX start

Lid(s) van dublo’s die zich gedurende lange tijd in de opstartstaat bevinden

Als lid(en) van een replica-set vastzit in opstart2 of als de primaire stand beschikbaar is in replica-set, gebruik dan deze procedure:

1. Controleer de status van replica met deze opdracht op Cluster Manager.

diagnostics.sh --get_replica_status

2. Lijst alle leden in alle replica-sets.

3. Beveiliging van de schelp aan de sessionhouder VM(s) en zorg voor de opslaglocatie van het mongoproces.Zoals in het voorbeeld wordt getoond, is dbpath /var/data/sessies.1/b voor het mongoproces dat loopt op sessionhouder01 in poort 37717.

ssh sessionmgr01

ps -ef | grep mongo | grep 37717

root      2572     1 25 Feb11 ?        24-11:43:43 /usr/bin/mongod --ipv6 --nojournal --storageEngine mmapv1 --noprealloc --smallfiles --port 37717 --dbpath=/var/data/sessions.1/b --replSet set01b --fork --pidfilepath /var/run/sessionmgr-37717.pid --oplogSize 5120 --logpath /var/log/mongodb-37717.log --logappend --quiet --slowms 500

4. Stop het mongoproces en reinig de inhoud in dbpath:

/etc/init.d/sessionmgr-xxxxx stop

rm -rf /var/data/sessions.1/b/*

5. Start het mongoproces, dit veroorzaakt het replica set lid om alle gegevens uit de primaire database te synchroniseren en niet het oplog.

/etc/init.d/sessionmgr-xxxxx start

Stap 5 kan een aanzienlijke tijd in beslag nemen om alle gegevens vanaf de basis te synchroniseren, afhankelijk van de grootte van de database.

Heropbouw van replica-sets

Door een aantal uitval kan het nodig zijn om een aantal of alle replica-sets te herbouwen. Voordat echter wordt besloten om een aantal of alle replica-sets te herbouwen, kan worden opgemerkt dat alle gegevens in deze replica-sets verloren kunnen gaan. De beschikbaarheid van back-ups moet voor deze databases onderling worden gecontroleerd:

- Admin (in het algemeen op 27721)

- Balans (in het algemeen over haven 27718)

- SPR (in het algemeen op haven 27720)

Zodra back-ups kruisgecontroleerd zijn en er een beslissing wordt genomen voor het opnieuw genereren van de database replica-sets, gebruikt u deze procedure:

1. Controleer de inhoud van /etc/broadhop/mongoConfig.cfg, LLD moet informatie hebben over welke configuratie in dit bestand aanwezig moet zijn of u kunt een back-upbestand gebruiken.

2. De opdracht building_set.sh —<db-name> — moet uitvoeren op Cluster Manager, wat afhankelijk is van de database die u wilt herbouwen. Het creëert alle replica-sets met betrekking tot die DB.

Opmerking: De opdracht om alle dbs in een replica-set te maken, reinigt de database. Alle inhoud van de replica-set zou verloren gaan.

3. Als u een specifieke replica-set voor één database wilt herbouwen, gebruikt u deze opdracht:

build_set.sh --

--create --setname

4. Als u alle replica-sets voor alle databases wilt herbouwen, gebruikt u deze opdracht:

build_set.sh --all --create

De database terugzetten vanaf back-uppostset

Zodra alle leden van replica-set online zijn en één van de leden primair is, kan mongoDB door deze procedure worden hersteld.

1. Om alle DB's van back-up te herstellen gebruikt u deze opdracht:

config_br.py --action import --mongo-all  /mnt/backup/

2. Om een specifieke DB van back-up terug te zetten door configuratie_br.py zijn deze opties beschikbaar:

- SPR

config_br.py --action import --mongo-all --spr /mnt/backup/

- Beheer

config_br.py --action import  --mongo-all --admin  /mnt/backup/

- saldo

config_br.py --action import  --mongo-all --balance  /mnt/backup/

- Rapportage

config_br.py --action import  --mongo-all --report  /mnt/backup/

Als mongodump wordt gebruikt voor back-up databases, verklaart dit het gebruik dat je maakt door middel van mongo-restauratie:

1. Trek het reservekopie tar.gz bestand uit.

tar -zxf /mnt/backup/

2. Zoek de map met mongostort van de database die u wilt herstellen en verander folder om deze in te voeren.

ls -ltr  /mnt/backup/cd /mnt/backup/27721_backup_$(date +\%Y-\%m-\%d)/dump

3. Zet de replica-set terug van de back-up.

mongorestore --host

--port

4. Optioneel om een specifieke verzameling of een DBB te herstellen, gebruikt u deze opdracht:

mongorestore --host

--port

--db

--