VM-herstel van probleemoplossing voor PCRF-sessiebeheer - OpenStack

Downloadopties

  • PDF     (158.2 KB)
    Met Adobe Reader op diverse apparaten bekijken
  • ePub     (86.4 KB)
    Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
  • Mobi (Kindle)     (75.5 KB)
    Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken
Bijgewerkt:4 september 2018
Document-id:213624

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

    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

      

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

    2. Start de opdracht op Cluster Manager.
    cd /var/qps/bin/support/mongo
build_set.sh --all --create-scripts
    1. 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

      

    1. Lijst alle leden in alle replica-sets.
    1. 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

       

    1. Stop het mongoproces en reinig de inhoud in dbpath:
    /etc/init.d/sessionmgr-xxxxx stop
rm -rf /var/data/sessions.1/b/*
    1. 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.
    1. 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.

    1. Als u een specifieke replica-set voor één database wilt herbouwen, gebruikt u deze opdracht:
    build_set.sh --
       
       
         --create --setname

      

    1. 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/
    1. 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 
            
              --
    TAC Authored

    Bijgedragen door Cisco-engineers

    • Nitesh Bansal
      Cisco geavanceerde services

    Was dit document nuttig?

    FeedbackFeedback

    Contact Cisco

    Dit document is van toepassing op deze producten