Fehlerbehebung PCRF Session Manager VM-Wiederherstellung - OpenStack

Einführung

In diesem Dokument wird das Session Manager Recovery-Verfahren beschrieben, das auf Ultra-M/OpenStack-Bereitstellungen bereitgestellt wird.

Fehlerbehebung

Wiederherstellungsverfahren für Instanzen des Sitzungsmanagers

Einschalten des Sitzungsmanagers im SHUTOFF-Status

Wenn sich eine Instanz aufgrund eines geplanten Abschaltvorgangs oder aus einem anderen Grund im SHUTOFF-Zustand befindet, verwenden Sie dieses Verfahren, um die Instanz zu starten und die Überwachung von it’s im ESC zu aktivieren.

1. Überprüfen Sie den Status der Instanz über 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. Überprüfen Sie, ob der Computer verfügbar ist, und stellen Sie sicher, dass der Status aktiv ist.
   
   

   source /home/stack/destackovsrc
   nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’
   | state                     | up                                       |
   | status                    | enabled                                  |

3. Melden Sie sich als Admin-Benutzer beim Elastic Services Controller (ESC) Master an, und überprüfen Sie den Zustand der Instanz in opdata. 
   
   

   /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. Einschalten der Instanz vom OpenStack
   
   

   source /home/stack/destackovsrc-Pcrf
   nova start SVS1-tmo_sm-s1_0_2e5dbff5-a324-42ea-9a65-bebf005a4226

   .
5. Warten Sie beispielsweise fünf Minuten, bis der Startvorgang abgeschlossen ist und der aktive Status erreicht ist.
   
   

   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. Aktivieren Sie VM Monitor im ESC, nachdem die Instanz im aktiven Zustand ist.

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

Weitere Informationen zur Wiederherstellung von Instanzkonfigurationen finden Sie im nächsten Abschnitt unter Instanztypspezifische Verfahren.

Stellen Sie alle Instanzen aus dem FEHLERzustand wieder her.

Dieses Verfahren kann verwendet werden, wenn der Zustand der CPS-Instanz in OpenStack FEHLER ist:

1. Überprüfen Sie den Status der Instanz 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. Überprüfen Sie, ob der Computer verfügbar ist und fehlerfrei ausgeführt wird.
   
   

   source /home/stack/destackovsrc
   nova hypervisor-show destackovs-compute-2 | egrep ‘status|state’
   | state                     | up                                       |
   | status                    | enabled                                  |

3. Melden Sie sich als Admin-Benutzer beim ESC Master an, und überprüfen Sie den Zustand der Instanz in opdata.
   
   

   /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. Setzen Sie den Status der Instanz zurück, um die Instanz wieder in einen aktiven Zustand zu versetzen, anstatt einen Fehlerzustand. Starten Sie anschließend die Instanz neu.
   
   

   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. Warten Sie fünf Minuten, bis die Instanz gestartet ist, und gehen Sie in den aktiven Zustand über.
   
   

   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. Wenn Cluster Manager den Status nach dem Neustart in AKTIV ändert, aktivieren Sie VM Monitor im ESC, nachdem die Cluster Manager-Instanz im aktiven Zustand ist.

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

Verwenden Sie nach der Wiederherstellung in den aktiven Status bzw. in den Ausführungsstatus die Prozedur für den Instanztyp, um Konfigurationen/Daten aus der Sicherung wiederherzustellen.

Session Manager/MongoDB Recovery

Der Sitzungsmanager stellt in diesem Abschnitt die Datenbankschicht der Cluster Policy Suite zur Verfügung. Die Wiederherstellung von Datenbanken auf einer kürzlich wiederhergestellten Instanz des Sitzungsmanagers wird behandelt:

Mitglied der Replica Set in Offline State

Wenn sich Mitglieder eines Replikationssatzes im Offlinemodus befinden, gehen Sie folgendermaßen vor:

1. Überprüfen Sie den Status der Replikationsgruppe mit diesem Befehl im Cluster Manager.

diagnostics.sh --get_replica_status

2. Listen Sie alle OFF-LINE-Member in allen Replikatsätzen auf.
   
   
3. Führen Sie den Befehl auf Cluster Manager aus.

cd /var/qps/bin/support/mongo
build_set.sh --all --create-scripts

4. Sichern Sie die Shell auf die sessionmgr VM(s), und starten Sie den Mongo-Prozess.

ssh sessionmgrXX
/etc/init.d/sessionmgr-XXXXX start

Mitglied(e) der Replica Set Stuck in Startup2/Recover State for a Long Time State

Wenn Mitglieder eines Replikationssatzes im Startzustand2 oder im Wiederherstellungszustand stecken und der primäre in Replikatsatz verfügbar ist, gehen Sie folgendermaßen vor:

1. Überprüfen Sie den Status der Replikationsgruppe mit diesem Befehl im Cluster Manager.

diagnostics.sh --get_replica_status

2. Listen Sie alle Mitglieder in allen Replikationssätzen auf.

3. Sichern Sie die Shell auf die sessionmgr VM(s), und rufen Sie den Speicherort des Mongo-Prozesses ab.Wie im Beispiel dbpath gezeigt, ist /var/data/sessions.1/b für den Mongo-Prozess, der auf sessionMgr01 an Port 37717 ausgeführt wird.

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. Beenden Sie den Mongo-Prozess, und bereinigen Sie den Inhalt in dbpath:

/etc/init.d/sessionmgr-xxxxx stop
rm -rf /var/data/sessions.1/b/*

5. Starten Sie den Mongo-Prozess. Dies veranlasst den Replikations-Set-Member, alle Daten aus der primären Datenbank und nicht aus dem oplog zu synchronisieren.

/etc/init.d/sessionmgr-xxxxx start

In Schritt 5 kann die Synchronisierung aller Daten aus dem primären Datenspeicher je nach Datenbankgröße sehr lange dauern.

Replikationssätze wiederherstellen

Aufgrund einiger Ausfälle kann es erforderlich sein, einige oder alle Replikate wiederherzustellen. Bevor jedoch beschlossen wird, einige oder alle Replikate neu zu erstellen, kann festgestellt werden, dass alle Daten in diesen Replikatsätzen verloren gehen könnten. Die Verfügbarkeit von Backups muss für diese Datenbanken überprüft werden:

• Administrator (in der Regel auf 27721)
• Saldo (in der Regel auf Port 27718)
• SPR (in der Regel auf Port 27720)

Wenn Backups überprüft wurden und Entscheidungen zum Wiederherstellen von Datenbankreplikationssätzen getroffen werden, gehen Sie folgendermaßen vor:

1. Überprüfen Sie den Inhalt von /etc/broadhop/mongoConfig.cfg, LLD muss Informationen darüber enthalten, welche Konfiguration in dieser Datei vorhanden sein muss, oder Sie können eine gesicherte Datei verwenden.
   

2. Der Befehl build_set.sh —<db-name> —create muss auf Cluster Manager ausgeführt werden, was von der Datenbank abhängt, die Sie neu erstellen möchten. Es werden alle Replikationssätze erstellt, die sich auf diese DB beziehen.

Hinweis: Durch den Befehl zum Erstellen aller Pfeile in einer Replikationseinrichtung wird die Datenbank gelöscht. Der gesamte Inhalt des Replikationssatzes geht verloren.

3. Wenn Sie einen bestimmten Replikationssatz für eine Datenbank neu erstellen möchten, verwenden Sie den folgenden Befehl:

build_set.sh --
       
       
         --create --setname 
         
       

4. Wenn Sie alle Replikationssätze für alle Datenbanken neu erstellen möchten, verwenden Sie den folgenden Befehl:

build_set.sh --all --create 

Stellen Sie die Datenbank aus dem Backup-Replikationssatz wieder her.

Sobald alle Mitglieder des Replikations-Sets online sind und eines der Mitglieder der primäre ist, kann mongoDB von der Sicherung durch dieses Verfahren wiederhergestellt werden.

1. Um alle DBs von der Datensicherung wiederherzustellen, verwenden Sie den folgenden Befehl:

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

2. Um eine bestimmte DB aus der Sicherung über config_br.py wiederherzustellen, stehen folgende Optionen zur Verfügung:

• SPR

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

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

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

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

mongorestore --host 
          
          
            --port 
           
             --db 
            
              --