從訂閱伺服器重建CUCM發佈伺服器

簡介

本檔案介紹如何從使用者資料庫中還原Cisco Unified Communications Manager(CUCM)發佈伺服器節點，而無需事先備份。

背景

在CUCM的早期版本中，發佈者節點被認為是結構化查詢語言(SQL)資料庫的唯一權威源。

因此，如果發佈伺服器節點由於硬體故障或檔案系統損壞而丟失，恢復它的唯一方法是重新安裝資料庫並從災難恢復系統(DRS)備份中恢複資料庫。

某些客戶沒有保留正確的備份，或者備份已過期，因此唯一的選擇是重建並重新配置發佈伺服器節點。 

在CUCM版本8.6(1)中，引入了一個新功能以便從使用者資料庫恢復發佈者資料庫。

本文檔介紹如何利用此功能從訂閱伺服器成功還原發佈伺服器DB。

思科強烈建議您保留整個群集的完整災難恢復框架(DRF)備份。

由於此過程僅恢復CUCM DB配置，因此不會恢復其他資料，如證書、保留音樂(MoH)和TFTP檔案。為了避免這些問題，請保持完整群集DRF備份。

附註：思科建議您開始之前，先檢視並熟悉本文所述的整個流程。

收集群集資料

在重新安裝發佈器之前，請務必收集有關上一個發佈器的相關詳細資訊。這些詳細資訊必須與原始發佈伺服器安裝相匹配：

• IP 位址
• 主機名
• 域名
• 安全密碼
• 精確CUCM版本
• 已安裝Cisco Options Package(COP)檔案

若要檢索清單中的前三個專案，請在當前訂閱伺服器節點CLI上輸入show network cluster命令：

admin:show network cluster
172.18.172.213 cucm911ccnasub1  Subscriber authenticated
172.18.172.212 cucm911ccnapub  Publisher not authenticated - INITIATOR
 since Tue Dec 3 12:43:24 2013
172.18.172.214 cucm911ccnasub2  Subscriber authenticated using TCP since
 Sun Dec 1 17:14:58 2013

在這種情況下，IP地址為172.18.172.212，主機名為cucm911ccnapub，且沒有為發佈伺服器配置域名。   

從站點文檔中檢索安全密碼（清單中的第四項）。

如果您不確定安全密碼，請盡最大努力猜測，然後根據CUCM版本嘗試根據需要驗證和更正該密碼。

如果安全密碼不正確，則需要群集中斷才能糾正這種情況。 

為了檢索準確的CUCM版本和已安裝的COP檔案（清單中的最後兩項），請從show version active命令收集系統輸出：

admin:show version active
Active Master Version: 9.1.2.10000-28
Active Version Installed Software Options:
No Installed Software Options Found.

在本例中，版本9.1.2.10000-28安裝時沒有附加的COP檔案。 

附註：可能以前有些COP檔案安裝在發佈伺服器上，但沒有安裝在訂閱伺服器上，反之亦然。僅將此輸出用作指南。

停止所有訂閱伺服器上的複製

安裝發佈伺服器時，複製功能無法設定和刪除當前訂閱伺服器DB至關重要。若要防止發生這種情況，請在所有訂閱伺服器上輸入utils複製停止命令：

admin:utils dbreplication stop

********************************************************************************
This command can delete the marker file(s) so that automatic replication setup
is stopped
It can also stop any replication setup currently executing
********************************************************************************

Deleted the marker file, auto replication setup is stopped

Service Manager is running
Commanded Out of Service
A Cisco DB Replicator[NOTRUNNING]
Service Manager is running
A Cisco DB Replicator[STARTED]

Completed replication process cleanup

Please run the command 'utils dbreplication runtimestate' and make sure all nodes
are RPC reachable before a replication reset is executed

安裝CUCM Publisher

收集相應版本的可啟動映像，並在升級到相應版本後執行安裝。

附註：大多數CUCM工程特別計畫(ES)版本已經可以啟動。

安裝發佈伺服器，並為前面提到的IP地址、主機名、域名和安全密碼指定正確的值。 

更新發佈伺服器上的進程節點值

附註：發佈伺服器必須知道至少一個訂閱伺服器，才能從該訂閱伺服器還原資料庫。思科建議您新增所有訂戶。 

要檢索節點清單，請在當前訂閱伺服器的CLI上輸入run sql select name，description，nodeid from processnode命令。

名稱值可以是主機名、IP地址或完全限定域名(FQDN)。

如果運行CUCM版本10.5(2)或更高版本，則必須先在發佈器CLI上運行utils disaster_recovery prepare restore pub_from_sub命令，然後才能繼續將節點新增到System > Server:

警告：許多使用CUCM版本10.5(2)或更高版本的人跳過utils disaster_recovery prepare restore pub_from_sub命令；但是，這是一個關鍵命令。請勿跳過本檔案中的任何步驟。

收到節點清單後，導航到System > Server，然後將除EnterpriseWideData之外的所有名稱值新增到Publisher Server Unified CM Administration頁。

名稱值必須對應於System > Server選單上的Host Name/IP Address欄位。

admin:run sql select name,description,nodeid from processnode
name               description     nodeid
================== =============== ======
EnterpriseWideData                 1
172.18.172.212     CUCM901CCNAPub  2
172.18.172.213     CUCM901CCNASub1 3
172.18.172.214     CUCM901CCNASub2 4

附註：預設安裝會將發佈伺服器主機名新增到processnode表中。如果name列列出發佈伺服器的IP地址，則可以將其更改為IP地址。在這種情況下，不要刪除發佈者條目，而是開啟和修改當前的主機名/IP地址欄位。 

重新啟動發佈伺服器節點

要在processnode更改完成後重新啟動發佈伺服器，請輸入utils system restart命令：

admin:utils system restart
Do you really want to restart ?
Enter (yes/no)? yes

Appliance is being Restarted ...
Warning: Restart could take up to 5 minutes.

Shutting down Service Manager. Please wait...
 \Service Manager shutting down services... Please Wait

Broadcast message from root (Tue Dec  3 14:29:09 2013):

The system is going down for reboot NOW!
Waiting .

Operation succeeded

驗證群集身份驗證

發佈伺服器重新啟動後，如果更改正確且安全密碼正確，則群集必須處於已驗證狀態。若要驗證這一點，請輸入show network cluster 指令：

admin:show network cluster
172.18.172.212 cucm911ccnapub  Publisher authenticated
172.18.172.213 cucm911ccnasub1  Subscriber authenticated using TCP since
 Tue Dec 3 14:24:20 2013
172.18.172.214 cucm911ccnasub2  Subscriber authenticated using TCP since
 Tue Dec 3 14:25:09 2013

附註：如果訂閱者未顯示為authenticated，請參閱本文檔的疑難解答部分以解決此問題，然後繼續。

執行新備份

如果沒有可用的先前備份，請在DRS頁面上執行群集備份。

附註：雖然可以使用訂戶DB進行還原，但還原非DB元件仍需要備份。

如果沒有可用的備份，則執行一個新備份；如果備份已存在，則可以跳過此部分。

新增備份裝置

使用導航選單導航到災難恢復系統，並新增備份裝置。

啟動手動備份

新增備份裝置後，啟動手動備份。

附註：發佈伺服器節點已註冊CCMDB元件非常重要。

從訂閱伺服器DB恢復發佈伺服器

在「災難恢復系統」頁上，導航到還原>還原嚮導。

如果當前備份可用，並且已跳過上一節，請選中「選擇功能」部分中的所有功能覈取方塊：Enterprise License Manager(ELM)、CDR_CAR和Unified Communications Manager(UCM)。

如果您使用在上一部分中執行的備份，請只選中UCM覈取方塊：

按「Next」（下一步）。選中publisher node覈取方塊(CUCM911CCNAPUB)，並選擇從中進行恢復的使用者DB。然後，按一下Restore。

還原狀態

當恢復到達CCMDB元件時，「狀態」文本必須顯示為從訂閱伺服器備份還原發佈伺服器:

對發佈伺服器資料庫運行健全性檢查

在重新啟動並設定複製之前，最好檢驗恢復是否成功，以及發佈伺服器資料庫是否包含所需資訊。

繼續之前，請確保這些查詢在發佈伺服器和訂閱伺服器節點上返回相同的值：

• 從裝置運行sql select count(*)
• 從終端使用者運行sql select count(*)

重新啟動群集

恢復完成後，在每個節點上輸入utils system restart命令。從發佈者開始，然後是每個訂閱者。

admin:utils system restart
Do you really want to restart ?
Enter (yes/no)? yes

 Appliance is being Restarted ...
Warning: Restart could take up to 5 minutes.

Shutting down Service Manager. Please wait...
 \ Service Manager shutting down services... Please Wait

Broadcast message from root (Tue Dec  3 14:29:09 2013):

The system is going down for reboot NOW!
Waiting .

Operation succeeded

驗證複製設定要求

導航到Cisco Unified Reporting頁面並生成Unified CM資料庫狀態報告。

複製可能尚未設定，但必須確保Unified CM主機、Unified CM Rhosts和Unified CM Sqlhosts檔案與發佈者匹配。

如果不匹配，則需要重新引導不匹配的節點。如果這些檔案不匹配，則不要繼續執行下一步或重置複製。

複製設定

複製無法自動設定，具體取決於版本。若要檢查此情況，請等待所有服務啟動，然後輸入utils復製程式runtimestate命令。

狀態值0表示正在進行設定，而值2表示已成功為該節點設定複製。

此輸出表示複製設定正在進行中(對於兩個節點，狀態顯示為0):

此輸出表示複製設定成功：

如果出現任何狀態值為4的節點，或者複製在幾小時後未成功設定，請從發佈伺服器節點輸入utils複製重置all命令。

如果複製繼續失敗，請參閱排除Linux裝置型號思科中的CUCM資料庫複製故障一文，瞭解有關如何解決此問題的詳細資訊。 

還原後

由於資料庫恢復不會恢復所有以前的元件，因此必須手動安裝或恢復許多伺服器級別的專案。

啟用服務

DRF恢復不會啟用任何服務。導航到Tools > Service Activation，然後根據統一可維護性頁面中的站點文檔啟用發佈者必須運行的所有必要服務：

安裝未還原的資料

如果沒有完全備份，您必須複製某些手動配置。尤其是那些涉及證書和TFTP功能的配置：

• MoH檔案
• 裝置包
• 撥號計畫(用於非北美編碼計畫(NANP)撥號)
• 區域設定
• 任何其他雜項締約方會議檔案
• 以前手動上傳到發佈者（如果是TFTP伺服器）的所有檔案
• 簡易網路管理通訊協定(SNMP)社群字串
• 批次證書匯出適用於跨集群分機移動(EMCC)、集群間位置頻寬管理器(LBM)和集群間查詢服務(ILS)
• 安全中繼、網關和會議網橋的證書交換

附註：對於混合模式群集，必須再次運行證書信任清單(CTL)客戶端。

疑難排解

本節介紹可能導致此過程失敗的各種方案。

群集未進行身份驗證

如果群集未進行身份驗證，則兩個最常見的原因是不匹配的安全密碼和TCP埠8500上的連線問題。

若要驗證群集安全密碼是否匹配，請在兩個節點的CLI上輸入utils create report platform命令，然後檢查platformConfig.xml檔案中的雜湊值。發佈者和訂閱者節點上的這些內容必須匹配。

  <IPSecSecurityPwCrypt>
    <ParamNameText>Security PW for this node</ParamNameText>
    <ParamDefaultValue>password</ParamDefaultValue><ParamValue>0F989713763893AC831812812AB2825C8318
    12812AB2825C831812812AB2825C </ParamValue>
  </IPSecSecurityPwCrypt>

如果兩者相符，請確認連線埠8500上的TCP連線。如果它們不匹配，則嘗試修復密碼時可能會遇到困難，因為圍繞該過程的CUCM代碼中存在多個缺陷：

• 思科錯誤ID CSCtn79868 - pwrecovery tool僅重置sftpuser密碼
• 思科錯誤ID CSCug92142 - pwrecovery工具不會更新內部使用者密碼
• 思科漏洞ID CSCug97360 — 在pwrecovery實用程式中拒絕使用
• 思科錯誤ID CSCts10778 — 為安全密碼恢復過程引發Denials
• 思科漏洞ID CSCua09290 - CLI「set password user security」未設定正確的應用密碼
• 思科錯誤ID CSCtx45528 - pwd reset cli返回good，但不會更改密碼
• 思科錯誤ID CSCup30002 — 在CUCM 10.5上更改安全密碼後，資料庫服務已關閉
• 思科漏洞ID CSCus13276 - CUCM 10.5.2安全密碼恢復導致資料庫無法在重新啟動時啟動

如果CUCM版本包含所有這些問題的修復程式，最簡單的解決方案是在所有節點上完成Cisco Unified Communications Operating System Administration Guide， Release 10.0(1)中詳述的密碼恢復過程。

如果CUCM版本不包含這些問題的修復程式，則思科技術支援中心(TAC)可以根據情況執行變通辦法。 

恢復不處理CCMDB元件

如果恢復未列出資料庫元件，則備份本身可能不包含資料庫元件。確保發佈伺服器DB運行並且可以接受查詢，並執行新的備份。

複製失敗

請參閱排除Linux裝置型號Cisco中的CUCM資料庫複製故障一文，以排除複製故障。

電話未註冊或無法訪問服務

因為資料庫恢復不會恢復任何證書，所以如果發佈伺服器是主TFTP伺服器，則簽名者會有所不同。

如果電話信任訂戶信任驗證服務(TVS)證書，並且電話和TVS伺服器之間開啟了TCP埠2445，則必須自動解決此問題。

因此，思科建議您維護完整群集DRF備份。 

由於Cisco錯誤ID CSCtn50405,8.6版之前的CUCM版本也可能出現證書問題，即使先前備份成功。

附註：請參閱Communications Manager Security Default and ITL Operation and Troubleshooting Cisco文章，瞭解有關如何對初始信任清單(ITL)檔案進行故障排除的其他資訊。