1 前言
HLR作為移動核心網中所有業務的基礎支撐網元，負責全網用戶數據的存儲，其中不僅包括用戶的靜態數據（用戶識別碼IMSI、移動設備碼、接入的優先級、預定業務類型以及保密參數等），還包括用戶位置更新、補充業務激活狀態等動態數據。HLR的穩定性與否直接關系到網絡的正常運營，因此是GSM網絡中的關鍵節點。
隨著移動用戶的迅猛增長，現網中HLR的容量越來越大，而一旦大容量的HLR出現故障，HLR業務中斷將直接對網絡質量和用戶感知度產生巨大的影響，同時給運營商帶來巨大的經濟損失；此外，自然災害（火災、地震等）或人為原因造成的故障，也對網絡的安全性與穩定性帶來較大的影響。
為進一步提高網絡安全性、保障漫游功能和來話呼叫成功率，對HLR進行整機的冗余備份是非常必要的。
2 容災方式介紹
HLR的容災備份方式分為實時備份（靜態數據和動態數據的實時備份）和非實時備份（靜態數據的實時備份）：
實時備份方式主要用于主用HLR與容災HLR為同廠家設備的容災，需要容災HLR實時同步備份主用HLR的靜態數據和動態數據。由于靜態數據和動態數據都做到了主用HLR與容災HLR實時的同步，因此，主用HLR宕機后，容災HLR能實時接管，業務不受影響。
非實時備份方式多用于主用HLR與容災HLR為不同廠家設備的容災，對于靜態數據的備份與實時備份方式一致。由于不同廠家設備數據格式不一致，實時同步動態數據較為困難，因此在主用HLR宕機后，容災HLR接管主用HLR業務時，必須發送HLR RESET消息到所有VLR，強制用戶進行位置更新。由于此刻容災HLR中沒有用戶的最新位置信息，因此在一段時間內用戶做被叫不能成功，業務會受到影響。
3 容災方式的同步機制
3.1 靜態數據同步
靜態數據包括現網HLR用戶的靜態數據和后期增量用戶的靜態數據。對于現網HLR用戶靜態數據的備份，前期需一次性備份現有主用HLR用戶靜態數據到備份HLR。對于后期的增量數據，日常維護中利用BOSS系統實時同步相應主用HLR的靜態用戶數據，存在同構方式和異構方式兩種情況。在同構方式中，BOSS系統將用戶數據通過營業廳接口發到主用HLR，主用HLR通過IP連接主動將靜態數據同步到容災HLR，見圖1。
圖1 同構方式靜態數據同步
在異構方式中，BOSS系統在對主用HLR操作成功后，把相應的指令轉換成容災HLR的指令格式文件，再發送給容災HLR，實現主備用HLR增量用戶靜態數據的同步，見圖2。
圖2 異構方式靜態數據同步
3.2 動態數據同步
動態數據的同步目前只存在于同構方式中，在主用HLR通過MAP消息收到用戶動態數據變化后，主用HLR設備在修改自身數據庫的同時把這些更新匯總到容災HLR中，實現對用戶動態數據的實時備份。對于動態數據的同步方式，不同廠家的采取的方式不盡相同，基本可以歸結為兩類，一類是在主用HLR和容災HLR之間利用信令網絡建立信令通道，主用HLR利用MAP信令將動態數據實時地傳到容災HLR中進行數據同步；另一類是組建群內局域網絡，通過IP接口以IP數據包的形式同步動態數據，實現動態數據的實時備份，見圖3。
圖3 動態數據同步方式
4 容災切換及恢復
4.1 容災切換
由于HLR對外主要有兩類接口：信令接口和BOSS接口，所以容災切換分為信令切換和BOSS切換兩種。
（1）信令切換
LSTP/MSC與主用HLR、容災HLR都有直連鏈路連接，并預先在H/LSTP中設置主備用信令路由選擇方式：將至主用HLR的路由設為主用路由，而至容災HLR的路由設為備用路由。正常情況下使用到主用HLR的路由進行信令交互，主用HLR故障時，到容災HLR的信令路由激活：
·MSC發起的對原主用HLR的查詢、位置更新等操作，通過LSTP轉發到容災HLR上；
·H/LSTP收到的查詢、位置更新等請求，根據SCCP層的備用路由配置，將原來發送到主用HLR的的信令轉發到容災HLR上。
容災切換組網示意圖見圖4。
圖4容災切換組網示意圖
（2）BOSS切換
BOSS系統分別和主用HLR、容災HLR進行連接，正常情況下BOSS系統和容災HLR的連接處于阻斷狀態；容災切換時需要斷開BOSS系統和主用HLR的連接，激活與容災HLR的連接。
4.2 容災恢復
（1）從容災HLR中的相應數據反向同步到恢復后的主用HLR中；
（2）信令切回到恢復后的主用HLR；
（3）BOSS切回到恢復后的主用HLR。
5 容災方式選擇
就網絡安全考慮，實時備份容災方式完全優于非實時備份容災方式；但是由于各省內網元情況不盡相同，同一省內存在多廠家HLR網元，完全采用實時備份方式將增加運營商的建設成本。因此在網絡安全建設的初期，應結合設備情況、投資情況，合理選擇容災方式。
（1）方式一：同構實時備份方式
同構方式適合于省內用戶較大、省內HLR廠家相對數量較少、投資相對寬裕、對HLR安全級別要求較高的省份。針對省內所有HLR分廠家進行備份，備份方式建議采用N+1方式進行，N臺主用HLR容量之和不超過1500萬（備份HLR靜態容量為N臺主用HLR容量之和，動態容量不低于N臺主用HLR中的最大者）。
圖5 同構方式網絡拓撲圖
（2）方式二：異構非實時備份方式
異構方式是在省內引入新的廠家HLR作為容災HLR對現有的主用HLR進行備份。該方式從投資角度看，通過招標形式可以節約一定投資；但是由于只能做到靜態數據的實時同步，無法做到真正意義上的實時接管，用戶在主用HLR宕機后，被叫業務在一段時間內受到影響。由于該方式網絡安全級別較低，不建議采用。
圖6 異構方式網絡拓撲圖
（3）方式三：兼容方式
兼容方式是指同構方式和異構方式的結合，在省內引入現有主用HLR廠家中的容災HLR，對同廠家的主用HLR實施靜態數據和動態數據的實時備份，對其他廠家主用HLR實施靜態數據的實時備份。因此，建議在網絡安全規劃的初期、投資不足的情況下考慮采用。
6 規劃中的要點
通過上的面分析，可以看出在規劃設計時不僅要合理選擇容災方式，更需要在容災方式確定之后注意以下幾點：
（1）現有HLR中用戶的靜態數據前期需要一次性導入到備份HLR數據庫，采用異構或者兼容式容災方式時，則需要考慮在將主用數據導入到備用HLR過程中的數據格式轉換問題。
（2）采用異構或者兼容式容災時，由于發送到主用HLR的指令與備用HLR的指令不同，需要考慮BOSS系統的改造。
在無任何主用HLR發生故障的情況下：
·BOSS系統收集市場部用戶管理的信息，將用戶業務變化的信息實時傳送至任何一個主用HLR，開戶或者修改用戶信息。
·主用HLR開戶或者修改用戶信息成功后，再向備份HLR進行開戶。BOSS的前置機在通信中作為CLIENT端，負責將用戶變化的信息轉化為備份HLR人機命令的格式，并寫入基于SOCKET協議的數據包中，發往備份HLR。備份HLR在通信中作為SERVER端，實時監聽提供給BOSS前置機的端口，接收前置機發來的基于SOCKET協議的數據包，并給予響應；同時根據收到的用戶變化的信息，更新備份數據庫。
當BOSS接到某一主用HLR發生故障的消息后：
·BOSS系統將停止向發生故障的主用HLR發送的用戶指令；
·在備用HLR完全接管故障HLR后，啟動BOSS與容災HLR的聯接；
·將發往故障主用HLR的用戶指令改向發往容災HLR；
·在故障期間，BOSS需要保存向容災HLR發的所有用戶指令的log，以便故障主用HLR恢復后，將此用戶數據重寫入該主用HLR。
（3）在同步數據同步時，無論是采用信令鏈路方式還是IP網絡方式，都應該確保鏈路的數量和帶寬滿足動態數據的傳輸需求。
現網主用HLR設備到備份HLR的帶寬需求可以分成兩個階段：第一階段是進行用戶數據初始化，第二階段是實時備份階段，而通常第一階段的帶寬需求比第二階段要大。
7 結束語
HLR容災的重要性已經不言而喻，在方案規劃時要結合各省的實際情況，選擇符合各省特點的容災技術，并充分考慮不同廠家的設備技術要求，規劃出合理的、可實施的設計方案。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://m.hanmeixuan.com/
本文標題：HLR容災技術及規劃要點
相關文章
