提高遠端聯網設備管理效能　ACS負載平衡/排程須兼備

隨著網際網路飛速的發展，家用聯網設備也跟著日益增加，ACS在管理上的負擔也相對沉重，通常ACS管理的家用聯網設備數目可達數萬甚至數十萬台。特別是因應ISP或是家用聯網設備廠商的需求，通常會在短時間內對大量家用聯網設備進行管理，而這類短時間龐大處理量的需求，極有可能導致ACS負載過重，造成ACS故障無法提供正常服務的情況。

圖1　ACS系統架構

也因此，為了提供穩定而平順的服務，可考慮採取多台ACS組成分散式架構來達到負載平衡(Load Balance)。如在Linux環境下，Linux虛擬伺服器(Linux Virtual Server, LVS)就提供負載平衡的解決方法。  

LVS演算法有效提升運算效能  

LVS達到負載平衡的方式可分為兩種，一種在應用層(Application-level)，另一種在IP層(IP-level)。一般多採用IP層負載平衡，因為IP層負載平衡的反應速度較快，對於LVS的負擔較低，LVS只須進行封包分配及繞送的工作，不用拆解到應用層的封包或修改任何封包，又加上ACS可將回應直接傳給家用聯網設備端，因此IP層負載平衡在效能以及速度上會比應用層負載平衡好很多。  

LVS提供三種IP負載平衡技術，依據使用者網路環境及需求來選擇：Virtual Server via Network Address Translation(VS/NAT)、Virtual Server via IP Tunneling(VS/TUN)與Virtual Server via Direct Routing(VS/DR)。  

決定好IP負載平衡技術，再來是決定工作排程演算法(Job Scheduling Algorithm)，當家用聯網設備要與ACS連結時，會先連上LVS，LVS則依據選定的排程演算法，把家用聯網設備端收到的封包分配到相對應的ACS(圖2)，達到負載平衡的目的。LVS提供八種排程演算法：循環式排程演算法(Round Robin Scheduling)、加權循環式排程演算法(Weighted Round Robin Scheduling)、最小連結數排程演算法(Least Connection Scheduling)、加權最小連結數排程演算法(Weighted Least Connection Scheduling)、基於位置最少連線排程演算法(Locality-Based Least Connection Scheduling)、帶複製的基於位置最少連線排程演算法(Locality-Based Least Connections with Replication Scheduling)、目地雜湊排程演算法(Destination Hashing Scheduling)、來源雜湊排程演算法(Source Hashing Scheduling)。

圖2　負載平衡架構示意圖

除了以上八種演算法，尚可以依據需求，修改Linux核心(Kernel)來編寫新的演算法，例如透過家用聯網設備的 媒體存取控制位址(MAC Address)提供給LVS，依據新的演算法做排程分配。  

記憶體資料庫加速存取  

即使網路流量達到負載平衡，大量家用聯網設備與ACS溝通的過程中，對於後端資料庫(PostgreSQL)的存取是非常頻繁的，因此後端資料庫會成為系統中的瓶頸所在。所以在各台ACS上採用記憶體資料庫(In-memory Database)，依據LVS所使用的工作排程演算法，可預先將相對應的家用聯網設備資料從後端資料庫搬進記憶體資料庫內，因此在ACS與家用聯網設備的交談中，ACS可以直接存取記憶體資料庫內的資料，不但加快家用聯網設備與ACS間的處理速度，也減少對於後端資料庫的過度存取。而ACS也會週期性地將記憶體資料庫內的資料更新回後端資料庫，並從後端資料庫抓取新加入的家用聯網設備資料寫回記憶體資料庫。  

目前網路上開放原始碼(Open Source)的記憶體資料庫有很多，在此僅列出以下幾種：FastDB、MonetDB、H2、HSQLDB。其中H2及HSQLDB是以Java撰寫而成的，對於ACS來說，同是使用Java作為開發工具，相容性較高，使用較為簡便。  

依據前述的負載平衡架構，在LVS後方建置了兩台ACS來達到負載平衡，其中LVS以及後端資料庫位於同一台伺服器。而各台伺服器規格如表1。在負載平衡架構下，模擬處理兩千五百個家用聯網設備的TR-069連線，可測得相關數據如表2～表4。

表1　伺服器規格
機型	規格內容	數量
IU Server Barebones	Tyan B5377	1
Memory	DDR2-667 DIMM, Registered ECC, 2GB	8
CPU	Intel Xeon E5430	1
HDD	320GB 16MB SATA2 7200rpm	2

由表2、表3可以比較出使用記憶體資料庫與否的差異，使用記憶體資料庫之後每秒ACS可處理的連線量會多出十個左右。

表2　單台ACS使用後端資料庫(PostgreSQL)
Label	取樣數	平均值	最小值	最大值	錯誤率	處理量
HTTP要求	2,500	1,714	578	10,656	0.00%	27.4/sec
總計	2,500	1,714	578	10,656	0.00%	27.4/sec

表3　單台ACS並啟用(In-memory)資料庫
Label	取樣數	平均值	最小值	最大值	錯誤率	處理量
HTTP要求	2,500	1,179	578	6,235	0.00%	38.7/sec
總計	2,500	1,179	578	6,235	0.00%	38.7/sec

而在啟用了負載平衡架構之後，整個系統(兩台ACS)可處理的連線數達到將近兩倍的單台ACS可處理連線數，如表4。

表4　負載平衡架構下，兩台ACS達到負載平衡
Label	取樣數	平均值	最小值	最大值	錯誤率	處理量
HTTP要求	2,500	793	547	2,062	0.00%	60.2/sec
總計	2,500	793	547	2,062	0.00%	60.2/sec

備援機制以備不時之需  

依照前述的負載平衡架構以及測試結果，當家用聯網設備成長到一定數目，可以彈性地增加一台新的ACS到負載平衡架構內，而每增加一台ACS，整個系統可處理的連線量也將跟著增加將近一倍，藉以分擔各台ACS的沉重壓力，以達負載平衡。  

由於所有的家用聯網設備都會經過LVS分配，再與相對應的ACS進行溝通，所以即使LVS只有封包分配及繞送，但處理數量驚人的封包也有可能導致LVS故障；此時就需要一台備援LVS隨時地偵測主LVS是否正常運作，若是主LVS故障，備援LVS要能馬上接管主LVS的工作。  

而ACS也有可能會故障，所以LVS也必須監視著ACS，動態的將故障的ACS從負載平衡架構內移除，避免將家用聯網設備端傳來的封包分配到故障的ACS。等到故障的ACS恢復正常運作再將ACS加入負載平衡架構。  

ACS排程有效管理家用聯網設備  

接下來介紹ACS排程技術。首先，先來探究為何須要排程。前文曾述及，ACS的主要用途在於讓管理者透過ACS所提供的圖形化管理介面，對家用聯網設備進行有效管理，ACS可管理、設定與供裝(Provisioning)家用聯網設備，並對此設備進行故障檢測排除與韌體升級。另外，ACS也可藉由北向介面(Northbound Interface)，提供給商務/營運支持系統(BSS/OSS)有關ACS運作期間所產生的統計數據與重要事件(Event)。也因此，為了符合經濟效益，ACS須盡快處理龐大工作，故ACS須要考慮周詳的排程設計，以兼顧穩定與效率，在最短時間內有效率地將所有工作處理完畢。  

一般來說，排程處理器有兩種，分別為TR-069排程處理器與WT-132排程處理器，其主要目的分別為讓ACS管理為數眾多的家用聯網設備、讓ACS透過北向介面，主動通知商務/營運支援系統，回報ACS在供裝管理家用聯網設備過程中，所發生的特殊事件與統計數據(圖3)。

圖3　排程處理器所在位置

而排程的基本處理流程為：排程處理器(Scheduler)將所有待處理的工作分門別類，依據性質區分輕重緩急，排定最佳執行順序；再產生預備執行清單，並交給ACS；ACS則依序通知家用聯網設備或商務/營運支援系統，要求主動連線至ACS，將該工作處理完畢。  

所謂ACS所處理的工作，可以視為是一群任務(Task)的組合。任務是ACS最基本的處理單位，而任務基本由三個構成要項組成，分別是執行對象、執行內容與預定執行時間，以下再分別針對各要項進行介紹：

‧

執行對象

當ACS要執行一件任務時，必須先知道此任務所作用的目標物件，這就是執行對象。就TR-069排程處理器而言，執行對象為家用聯網設備，可以是單台，也可以是數量龐大的多台(群組)。群組可以分成固定與動態，所謂的固定式群組，就是組成成員為固定；與固定式相對的是動態式群組，它採用家用聯網設備某個或多個特殊參數值，來當作選取組成成員的條件。但組成成員的數量是動態變化，在命令發布之初與實際執行的時間點，組成成員可能不相同。 舉例來說，使用家用聯網設備廠商識別碼(OUI)來當作擷取條件，則有相同廠商識別碼的家用聯網設備都會被歸類到此動態式群組，但一段時間後，可能有新的家用聯網設備被ACS納入管理，或是原有的家用聯網設備被ACS從管理清單中移除，則此動態式群組的成員也會隨之自動改變。 雖然動態式群組運用的場合較為廣泛，但對於WT-132排程處理器而言，由於執行對象多為商務/營運支援系統端，因此在實務上仍很少使用動態式群組。

‧	執行內容
	當ACS要執行一件任務時，真正要做的事情，就定義在執行內容。就TR-069排程處理器而言，執行內容就是由單個或多個遠端程序呼叫方法(RPC Method)組成。遠端程序呼叫方法是TR-069客戶端(家用聯網設備)所支援的遠端服務，這些遠端服務的具體內容包含有取得/設定參數(Parameter)值、新增/刪除物件(Object)與檔案的上傳/下載等。 就WT-132排程處理器而言，執行內容也是由單個或多個遠端程序呼叫方法組成，這些遠端程序呼叫方法是定義在WT-132客戶端(商務/營運支援系統)，但是目前數位用戶迴路論壇(DSL Forum)尚未在WT-132定義這些遠端程序呼叫方法，所以在實務上，ACS開發廠商只能依據WT-131所描述的運作需求模仿TR-069，自行定義這些遠端程序呼叫方法，然後實作在自家的ACS產品裡。

‧	預定執行時間
	這項要素主要討論的是ACS預計要執行一件任務的時間。一般來說，若沒有特別指定預定執行時間，則表示ACS須盡可能在最短時間內執行。若是指定一個已經逾期的時間，則這件任務將被保留、不被執行，但仍可藉由重新指定新的預定執行時間，再次執行此一任務。

可靠性至上 週期性排程處理受歡迎

依據TR-069規範，ACS與家用聯網設備之間的連線，永遠都是家用聯網設備主動發起連線，ACS只能被動接受連線。但若ACS需要家用聯網設備執行任務，該如何進行？按照TR-069的規範，ACS須要經由TCP/UDP發送連線要求(Connection Request)給家用聯網設備，在該設備收到連線要求後，就會在最短的時間內，主動連線至ACS執行相關任務(圖4)。由上述可知，發送連線要求是排程處理器最核心的部分，設計優劣攸關整體系統的穩定度與效能。因此，有兩種思考方向：即週期性發送連線要求及任務取向發送連線要求。

圖4　ACS發送連線要求架構

在週期性發送連線要求部分，ACS每隔一段時間就去檢查目前是否有任務須要執行；若有，就對所有的任務對象發送連線要求。這種設計比較簡單，所以相對地比較穩定可靠。但效能較差。當多台任務對象須要同時執行任務時，ACS可多工同時進行，此時的處理時間通常會超過週期性的間隔時間，所以在第一波連線要求發出後，第二波會緊接著發出，中間沒有間隔時間，整體效能不受影響。真正受影響的是單台任務對象執行多筆任務，此時所有任務是依序執行，間隔時間長短與前項任務結束的時間有關。但在實務上，這並不是效能的重點，效能指標著重於前述多台多工執行。

至於任務取向發送連線要求，是當有任務產生時，ACS就會產生一個連線要求放入佇列(Queue)中，然後依序在最短時間內發出。雖然理論上此設計會有最佳效能；但在實務上，由於家用聯網設備有些會自行定時連線，連線時會一併執行任務，此時的連線要求就會變成多餘；而且家用聯網設備在執行完任務後，有時需要一段時間套用參數值的改變，無法立即執行下個任務，反而需要額外的緩衝控制。在尖峰負載的多工多台環境下，發送連線要求的效率不是重點，反而須要控制速度。所以此種設計效能表現並不出色，且在穩定可靠性上，明顯不如週期性發送。  

因應實務面　特殊設計問世  

另外，為了因應實際運作上的不同需求，也有一些特殊設計陸續問世，舉例來說，包括重新嘗試連線機制、權重機制、動態任務內容與任務回收機制都是一例。  

在重新嘗試連線機制上，當ACS發送連線要求後，有可能會收不到任何回應；也有可能收到回應後，家用聯網設備卻沒有主動發起連線，兩者任務都算失敗。會發生這種情況，有時是因為前一個任務設定了重要的參數內容值，且家用聯網設備需要一段時機來套用；有時是因為家用聯網設備此時正在進行韌體更新，回應很不穩定。然而，不管是哪種情形，家用聯網設備都會在很短的時間回復可執行任務的狀態，所以ACS在不確定家用聯網設備是否斷線或是故障的情況下，須要在一段時間內重複嘗試發送連線要求，並盡可能將任務付諸執行。  

至於權重機制，是由於對單台執行對象而言，若有許多任務須要馬上執行，如何從中選擇一個最佳的任務來執行，其挑選原則並不是依照任務產生時間，而是依照任務重要性，也就是權重指數。舉例來說，管理者所交付的任務，相對於ACS系統為了收集統計數據所自動產生出來的維護用任務，前者權重值就會比較高，將會優先被執行。  

當ACS處理比較複雜的任務時，任務內容可能需要某種程度的彈性，才能依照不同的情況給予最佳的處理。比方說，在進行家用聯網設備供裝時，ACS須要事先檢查某個物件是否存在，若不存在，則要先進行新增物件，然後才能順利設定在此物件下的參數。另外一個例子是，若是對家用聯網設備進行IP Ping的診斷工作，ACS會自動衍生一個後續單獨任務，作用是取回之前的IP Ping診斷結果，這些都隸屬於動態任務內容。  

關於任務回收機制，由於整個任務執行過程中，在ACS與任務對象的交互作用過程裡，可能會發生一些目前尚未發現的錯誤，或是無法妥善處理的錯誤，此時就需要任務回收機制不斷掃描還在活動中的任務，將異常的任務標記為錯誤，視情況安排重新執行或是永久放棄。  

排程處理器決定ACS效能  

ACS的處理能力主要取決於硬體設備的整體能力，中央處理器的處理速度與記憶體的數量尤其占有重要角色。一般說來，資料庫連線數量、HTTP伺服器所允許的最大連線數與Java虛擬機器所使用的記憶體數量等三處都是主要瓶頸所在。  

若是能依據累積的經驗，適度調整這些數值，則ACS的處理能力就能達到最佳化。同時，也會得到一個處理能力數值，表示ACS在尖峰負載運行下，所能處理最大的會談(Session)數目。  

將這個處理能力數值設定給排程處理器的演算法公式，則排程處理器在運作時，會不斷監視目前ACS中正在處理的會談數目(圖5)。若是會談數目增加得很快，則排程處理器會加大發送連線要求的間隔時間，以減緩數量上升的速度；反之，若是目前會談數量不多，則會適度縮減發送連線要求的間隔時間。最終目的在於讓ACS在尖峰負載運行下，以不超過最大處理能力為前提，能夠處理最多的會談，從而使其效能發揮到極致。

圖5　ACS內部所處理的會談數目會依時間有所變化

總結來說，正確地使用ACS將可以讓網路服務供應商或家用聯網設備製造商高效率管理家用聯網設備，並適時因應環境變化進行調整。  

(本文作者任職於資策會網多所)