Herstel van configuratie-DBB mislukt in vManager Cluster DR Setup

Downloadopties

  • PDF     (206.9 KB)
    Met Adobe Reader op diverse apparaten bekijken
  • ePub     (176.2 KB)
    Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
  • Mobi (Kindle)     (189.9 KB)
    Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken
Bijgewerkt:1 september 2020
Document-id:215982

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 een probleem met configuratie-DBR-herstel, dat niet in vManager D.-instellingen wordt uitgevoerd.

    Probleem

    vManager NMS herstellen van back-up: restauratie van configuratie-db mislukt in beheer van teruggestelde cluster

    Gebruik de CLI-opdracht voor het herstellen van pad door de applicatie-db van de request-nms te gebruiken. Deze opdracht herstelt de configuratiedatabase uit het bestand dat datapath vindt. In dit voorbeeld is de bestemming de stand-by vManager NMS. Start deze opdrachten op de stand-by vManager NMS:

    vmanage-1# request nms configuration-db restore path /home/admin/cluster-backup.tar.gz
    Configuration database is running in a cluster mode
    !
    !
    !
    line omitted
    !
    !
    !


    .................... 80%
    .................... 90%
    .................... 100%
    Backup complete.
    Finished DB backup from: 30.1.1.1
    Stopping NMS application server on 30.1.1.1
    Stopping NMS application server on 30.1.1.2
    Stopping NMS application server on 30.1.1.3
    Stopping NMS configuration database on 30.1.1.1
    Stopping NMS configuration database on 30.1.1.2
    Stopping NMS configuration database on 30.1.1.3
    Reseting NMS configuration database on 30.1.1.1
    Reseting NMS configuration database on 30.1.1.2
    Reseting NMS configuration database on 30.1.1.3
    Restoring from DB backup: /opt/data/backup/staging/graph.db-backup
    cmd to restore db: sh /usr/bin/vconfd_script_nms_neo4jwrapper.sh restore /opt/data/backup/staging/graph.db-backup
    Successfully restored DB backup: /opt/data/backup/staging/graph.db-backup
    Starting NMS configuration database on 30.1.1.1
    Waiting for 10s before starting other instances...
    Starting NMS configuration database on 30.1.1.2
    Waiting for 120s for the instance to start...
    NMS configuration database on 30.1.1.2 has started.
    Starting NMS configuration database on 30.1.1.3
    Waiting for 120s for the instance to start...
    NMS configuration database on 30.1.1.3 has started.
    NMS configuration database on 30.1.1.1 has started.
    Updating DB with the saved cluster configuration data
    Successfully reinserted cluster meta information
    Starting NMS application-server on 30.1.1.1
    Waiting for 120s for the instance to start...
    Starting NMS application-server on 30.1.1.2
    Waiting for 120s for the instance to start...
    Starting NMS application-server on 30.1.1.3
    Waiting for 120s for the instance to start...
    Removed old database directory: /opt/data/backup/local/graph.db-backup
    Successfully restored database
    vmanage-1#


    Stap 1. Config-db moet met deze logbestanden herstellen, maar er is een scenario waar de reservekopie van Config_db met deze foutmeldingen mislukt.

    vmanage-1# request nms configuration-db restore path /home/admin/cluster-backup.tar.gz
    Configuration database is running in a cluster mode
    !
    !
    line ommited
    !
    !
    2020-08-09 17:13:48.758+0800 INFO [o.n.k.i.s.f.RecordFormatSelector] Selected RecordFormat:StandardV3_2[v0.A.8] record format from store /opt/data/backup/local/graph.db-backup
    2020-08-09 17:13:48.759+0800 INFO [o.n.k.i.s.f.RecordFormatSelector] Format not configured. Selected format from the store: RecordFormat:StandardV3_2[v0.A.8]
    .................... 10%
    .................... 20%
    .................... 30%
    .................... 40%
    .................... 50%
    .................... 60%
    .................... 70%
    ...............Checking node and relationship counts
    .................... 10%
    .................... 20%
    .................... 30%
    .................... 40%
    .................... 50%
    .................... 60%
    .................... 70%
    .................... 80%
    .................... 90%
    .................... 100% Backup complete.
    Finished DB backup from: 30.1.1.1
    Stopping NMS application server on 30.1.1.1
    Stopping NMS application server on 30.1.1.2
    Could not stop NMS application-server on 30.1.1.2
    Failed to restore the database

    Stap 2. In de genoemde mislukking, scenario Onder clusterbeheer pagina in beheer, navigeer naar beheerder > Cluster beheer > Selecteren buurmodel (...) > Bewerken

    Terwijl vManager in clusterbeheer wordt bewerkt, wordt de ontvangen fout: "Ophalen lijst van geconfigureerde IPS - Verificatie mislukt""

    Oplossing

    Tijdens het configuratie-db herstel de handeling in een vManager-cluster, is het vereist om de services op de externe knooppunten te starten/stoppen. Dit wordt gedaan door Netconf verzoeken die aan het verre knooppunt in het cluster worden gemaakt.

    Als de control-verbinding tussen vbeheer's in het cluster bestaat, probeer dan het externe knooppunt te authentiseren met de openbare sleutel van het externe knooppunt om het NetConf-verzoek voor te bereiden, dat gelijk is aan de control-verbindingen tussen apparaten. Als dat niet het geval is, valt het terug naar de in de database opgeslagen geloofsbrieven die werden gebruikt om het cluster te vormen.

    Het probleem dat we hebben ondervonden is dat het wachtwoord wijzigingen heeft gekregen via CLI maar het wachtwoord voor clusterbeheer in de database is niet bijgewerkt. Dus wanneer we het wachtwoord van de netadmin account wijzigen dat gebruikt wordt om de cluster te maken, moet je het wachtwoord bijwerken met behulp van de werking van clusterbeheer ook. Dit zijn de extra stappen die u moet ondernemen.

    1. Meld u aan bij elke GUI.
    2. Navigeer naar beheerder > Cluster Management > selecteer respectievelijke vManager (...) > Bewerken, zoals in de afbeelding weergegeven.
    3. Wachtwoord bijwerken vergelijkbaar met CLI.
    •  vManager1 30.1.1.1

    • vManager 30.1.1.2

    • vManager3 30.1.1.3

    Opmerking: Het terugdraaien van het wachtwoord van CLI is in dit scenario niet mogelijk van de CLI.

    Best Practice

    De beste praktijk om het wachtwoord voor vManager in het cluster te wijzigen is om naar beheerder > Gebruikers beheren > Wachtwoord bijwerken.

    Deze procedure werkt ook het wachtwoord in alle 3 vManages in de cluster en het wachtwoord voor clusterbeheer bij.

    Gerelateerde informatie

    TAC Authored

    Bijgedragen door Cisco-engineers

    • Vijeth Kumar
      Cisco TAC-ingenieur

    Was dit document nuttig?

    FeedbackFeedback

    Contact Cisco

    Dit document is van toepassing op deze producten