PCRF會話管理器虛擬機器恢復故障排除 — Openstack

簡介

本文檔介紹在Ultra-M/Openstack部署上部署的會話管理器恢復過程。

疑難排解

會話管理器例項恢復過程

從關閉狀態開啟會話管理器

如果任何例項由於計畫關閉或其他原因而處於SHUTOFF狀態，請使用此過程啟動該例項並啟用ESC中的â0s監™。

1. 通過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. 檢查電腦是否可用並確保狀態為up。
   
   

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

3. 以管理員使用者身份登入到Elastic Services Controller(ESC)Master，並檢查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. 從openstack開啟例項電源
   
   

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

   .
5. 等待五分鐘以等待例項啟動並進入活動狀態。
   
   

   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. 在例項處於活動狀態後在ESC中啟用VM監視器。

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

有關例項配置的進一步恢復，請參閱下一節中提供的特定於例項型別的過程。

從錯誤狀態中恢復任何例項

如果openstack中CPS例項的狀態為ERROR:

1. 檢查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. 檢查電腦是否可用且運行正常。
   
   

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

3. 以管理員使用者身份登入到ESC主裝置，並檢查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. 重置例項狀態以強制例項返回活動狀態而不是錯誤狀態，一旦完成將重新啟動例項。
   
   

   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. 等待五分鐘，以便例項啟動並進入活動狀態。
   
   

   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. 如果，Cluster Manager在重新引導後將狀態更改為ACTIVE，則在Cluster Manager例項處於活動狀態後在ESC中啟用VM監視器。

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

將恢復為運行/活動狀態後，請參閱例項型別特定的過程，以從備份中恢復配置/資料。

會話管理器/MongoDB恢復

Session Manager在本節中提供了Database layer to Cluster Policy Suite，其中討論了在會話管理器最近恢復的例項上恢複資料庫的問題：

處於離線狀態的副本集的成員

如果複製副本集的成員處於離線狀態，請執行以下過程：

1. 在群集管理器上使用此命令檢查複製副本集的狀態。

diagnostics.sh --get_replica_status

2. 列出所有副本集中的所有OFF-LINE成員。
   
   
3. 在群集管理器上運行命令。

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

4. 將shell保護到sessionmgr虛擬機器並啟動mongo進程。

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

副本整合員在Startup2/Recovery狀態下長期停滯

如果複製副本集的成員停滯在startup2或recovering狀態，並且複製副本集中的primary可用，請執行以下過程：

1. 在群集管理器上使用此命令檢查複製副本集的狀態。

diagnostics.sh --get_replica_status

2. 列出所有副本集中的所有成員。

3. 將shell安全連線到sessionmgr虛擬機器並獲取mongo進程的儲存位置。如示例dbpath所示，對於埠37717處在sessionmgr01上運行的mongo進程，dbpath為/var/data/sessions.1/b。

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. 停止mongo進程並清理dbpath中的內容：

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

5. 啟動mongo進程，這會使副本整合員同步主資料庫中的所有資料，而不是同步日誌。

/etc/init.d/sessionmgr-xxxxx start

步驟5可能需要相當長的時間來同步主節點的所有資料，這取決於資料庫大小。

重建複製副本集

由於某些中斷，可能需要重建部分或全部副本集。但是，在決定重建部分或全部副本集之前，可能會注意到這些副本集中的所有資料可能丟失。必須交叉驗證以下資料庫的備份可用性：

• Admin(通常為27721)
• 平衡(通常在連線埠27718上)
• SPR(通常在埠27720上)

在交叉驗證備份並做出重新建立資料庫副本集的決策後，請使用以下過程：

1. 請檢查/etc/broadhop/mongoConfig.cfg的內容，LLD必須瞭解有關此檔案中必須存在哪些配置的資訊，或者您可以使用備份的檔案。
   

2. build_set.sh —<db-name> —create命令必須在Cluster Manager上運行，具體取決於要重建的資料庫。它會建立與該資料庫相關的所有副本集。

附註：在副本集中建立所有dbs的命令將清除資料庫。副本集的所有內容都將丟失。

3. 如果要為一個資料庫重建特定複製副本集，請使用以下命令：

build_set.sh --
     
     
       --create --setname 
       
     

4. 如果要為所有資料庫重建所有複製副本集，請使用以下命令：

build_set.sh --all --create 

從備份後副本集恢複資料庫

一旦副本集的所有成員都處於聯機狀態，並且其中一個成員為主成員，就可以通過此過程從備份恢復mongoDB。

1. 要從備份還原所有資料庫，請使用以下命令：

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

2. 要通過config_br.py從備份還原特定資料庫，以下選項可用：

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