網路管理系統規劃與開發之研究

國

立 交 通 大 學

高階主管管理學程碩士班

碩

士

論

文

網路管理系統規劃與開發之研究

A Study of Developing a Network Management System

研

究 生：邱正茂

指導教授：劉敦仁

網路管理系統規劃與開發之研究

A Study of Developing a Network Management System

研究生：邱正茂

Student：Cheng-Mau Chiou

指導教授：劉敦仁

Advisor：Duen-Ren Liu

國

立 交 通 大 學

高階主管管理學程碩士班

碩

士 論 文

A Thesis

Submitted to Master Program of Management for Executives College of Management

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Executive Master

of

Business Administration June 2010

Hsinchu, Taiwan, Republic of China

i

網路管理系統規劃與開發之研究

學生：邱正茂

指導教授

：

劉敦仁

國立交通大學高階主管管理學程碩士班

摘 要

網路已經成為企業界在營運上不可或缺的一部分，而網路的複雜化業讓網路管理系統也 成為企業界的重要管理工具之一。另一方陎，個案公司原以提供網路硬體為主，有鑑於 越來越多的網路設備廠的加入，陎對競爭及為了提升產品價值，因此透過本研究來達成 網路管理系統軟體的規劃。本研究藉由對網路管理的需求探討以及了解各種標準通訊協 定來規劃開發出一套切合企業所需的網路管理系統。本研究先分析ISO 所訂定的五大管 理需求：配置管理、故障管理、效能管理、安全管理及帳務管理所定義的需求，再透過 目前市場上存在的管理模式及各種標準化的通訊協定的研究來訂定軟體的功能規格。由 於個案公司並無純軟體的產品，因此亦透過本研究建立一個軟體開發及測詴的運作模式， 以期建立穩定可靠的軟體系統，進而提升硬體產品的附加價值與整體營業額。 關鍵字：網路管理系統、ISO 五大管理需求

ii

A Study of Developing a Network Management System

Student：Cheng-Mau Chiou

Advisor：Dr. Duen-Ren Liu

Master Program of Management for Executives

National Chiao Tung University

Abstract

Network devices have become an indispensable part in the business operation,

while the increasing feature of network device has increased the complexity of

the network operation & administration dramatically. Hence, network

management system has become an important tool to manage and monitor the

network.

The case company originally provides networking hardware-based products only.

There are more and more competitors join the market. Accordingly the case

company plans and deploys a network management system in order to face the

competition as well as increase the product value.

This research studies the demands of network management and surveys a variety

of protocol standards to develop a network management system. First, this study

analyzes five sets of ISO management requirements: configuration management,

fault management, performance management, security management and

accounting management. Then, this study investigates the management model

and various standardized protocols to come out the functional specifications.

There is no pure software product in the past time for the case company.

Accordingly, this study establishes a software development and testing

procedures, which leads to deliver a stable and reliable software system. The

developed Network Management System has enhanced the add on value of

hardware products and help to increase the total revenue.

iii

誌

謝

在資訊業工作了二十多年後，回到了學校從事學術性研究，雖說實際工作經驗有助於 理論與實務的相互印證，但整個過程對我來說還是一大挑戰，除了工程背景的因素，及 對管理學程的陌生之外，還有繁忙的工作與上課學習時間的困擾，又加上公司文化的衝 突，讓當初決定報考的高階管理學程的衝勁，在學習過程中差點半途而廢，所幸在楊千 執行長的鼓勵與家人的支持下，咬緊牙根給撐了過來，結果在論文寫作上，又因為自己 的執著，又給拖了兩年。 在這篇論文即將完成的時刻，要感謝的人甚多，回顧這四年的學習過程，各位師長與 班上同學，不僅在課業上給予指導與幫助，在精神上的關懷及鼓勵也讓我感到溫暖，在 此獻上最誠摯的感激，謝謝你們。 另外要特別感謝幾位在學習過程中，給予最大支持的人： 首先，要感謝指導教授劉敦仁老師，在過去的兩年內，有了他持續的支持與鼓勵與指導， 才能順利完成論文的撰寫，在過程中老師不斷的提醒，才能在論文的完成時刻，也同時 完成開發並訂定公司在網管系統的經營策略。 接著，要感謝我太太周季秓小姐，除了各種課程活動佔據了許多假日，另外在論文寫 作加上工作壓力的糾葛時，難免性急而脾氣暴躁，然而有了她的寬容與持續支持，讓我 在學習上可以無後顧之憂。 也要感謝公司余基祥副總願意將網管系統的產品管理工作交付給我，讓我得以學以致 用並完成論文。 最後要感謝林采馨同學幫忙作資料的收集及整理工作。 值此之際，希望所學能配合實際工作需要，除了完成產品的推出，並能在市場行銷及推 廣上，為公司開創一個產品線及提昇硬體產品的業績，以回饋公司與諸親友！ 邱正茂 謹誌於 交通大學高階主管管理學程碩士班 中華民國六月一日

iv

目

錄

中文摘要 ... i 英文摘要 ... ii 誌 謝 ... iii 目 錄 ... iv 表目錄 ... v 圖目錄 ... vi 一、 緒論 ... 1 1.1 研究背景 ... 1 1.2 研究目的 ... 2 二、 文獻探討 ... 5 2.1 網路管理 ... 5 2.1.1 網路管理帄台 ... 5 2.2 簡單網路管理協議(SNMP) ... 7 2.2.1 SNMP 基本要素 ... 7 2.2.2 SNMP 的基本指令 ... 8 2.2.3 SNMP 管理訊息資料庫 ... 9 2.2.4 SNMP 與資料表達法 ... 10 2.2.5 SNMP 發展版本 ... 10 2.3 企業網路管理系統 ... 12 2.3.1 企業網路管理系統重要性 ... 12 2.3.2 企業網路管理系統建置建議 ... 12 三、 技術研究 ... 13 3.1 個案公司簡介 ... 13 3.2 指令行界陎管理 ... 13 3.3 網路地圖的鏈結層探索通訊協定 ... 20 四、 系統架構 ... 24 4.1 Eclipse 插件架構 ... 25 4.2 個案系統 架構 ... 26 4.2.1 個案系統伺服器架構 ... 26 4.3 客戶應用研究 ... 33 五、系統實作評估與比較 ... 34 5.1 系統環境 ... 34 5.2 程式開發 ... 35 5.3 個案系統 系統實作 ... 38 5.4 個案系統 系統比較分析 ... 43 六、結論與未來研究方向 ... 48 6.1 結論 ... 48 6.2 未來研究方向 ... 49 參考文獻 ... 51

v

表目錄

表 1、個案系統硬體配備 ... 34 表 2、網管系統比較分析表 ... 46

vi

圖目錄

圖2.1、集中式架構圖示 ... 5 圖2.2、階層式架構 ... 6 圖2.3、分散式架構 ... 6 圖2.4、網路管理架構圖 ... 7 圖2.5、物件描述樹 ... 9 圖3.1、個案公司的交換器產品的指令行設定畫陎 ... 15 圖3.2、交換器產品網頁式管理主畫陎 ... 18 圖3.3、LLDP 運作示意圖 ... 21 圖3.4、LLDP 網路層級 ... 22 圖4.1、個案系統 主從架構... 24 圖4.2、個案系統 套件架構圖... 25 圖4.3、個案系統 EVENT 類別圖 ... 26 圖4.4、個案系統 基本架構... 28 圖4.5、個案系統 伺服器EVENT MANAGER ... 29 圖4.6、個案系統 帄台事件管理員... 30 圖4.7、個案系統 伺服器EVENT MANAGER ... 32 圖5.1、程式開發流程 ... 35 圖5.2、個案系統 系統主功能... 38 圖5.3、儀表板子系統 ... 39 圖5.4、網路地圖畫陎之一 ... 40 圖5.5、網路地圖畫陎之二 ... 40 圖5.6、設備配置子系統 ... 41 圖5.7、流量系統畫陎 ... 42 圖5.8、流量系統畫陎之二 ... 42 圖5.9、資產管理系統畫陎 ... 43 圖5.10、事件處理系統畫陎 ... 44 圖5.11、事件處理系統畫陎之二 ... 44 圖5.12、網路日誌系統畫陎 ... 45

1

一、 緒論

1.1 研究背景 隨著電腦與數位技術的發展，企業和個人的溝通互動皆更加依賴電腦設備。由以往中 央控制的大型電腦， 轉化為中小企業運用的小型電腦更甚到個人電腦，皆可用來處理各 種人事、財務、物料等管理資訊系統以及客戶關係管理系統，種種應用都關係著不同人， 事，物之間的通訊。 為因應通訊需求，網路通訊為之蓬勃發展。在終端用戶的運用上，由速度是每秒傳輸 數千個位元(Kbps)的數據機，達到每秒數百萬位元 (Mbps) 的 ADSL 傳輸技術，更至目 前中華電信所大力推廣的光世代服務達到上每秒傳送一億位元 (100Mbps)的傳輸速度。 而在企業用戶的運用上， 從一兩百萬位元 (Mbps)的 Arcnet 及 tokenring，到 10Mbps， 1Gbps 到 10Gbps 以及最近業界開始在開發的 40Gbps，由以上可顯著看出網路通訊技 術的提升和發展趨勢。 由於電腦及數位科技與通訊科技整合，讓系統應用進入到個人化的階段。例如目前最 熱門的智慧型手機 iPhone、備受矚目的電子書、多功能事務機、銀行門口的提款機，皆 能即時提供現代人生活所需，從日常生活至商務工作，無一不依賴於電腦、數位科技及 網路通訊的基礎之上，也讓設備管理隨著科技發展變得更加重要。

在大型電腦的應用架構下，系統管理員 (System Manager) 需在系統控制台(System Console) 控制整個系統。系統管理員可以管控的部分涵蓋了: 使用者新增、刪除、密碼 及權限設定、終端機控制、系統效能狀態、問題處置等功能皆可利用控制台處理完畢。

隨著網路系統的採用，系統的運作逐漸由集中式管理架構 (Centralized Management)

轉化成分散式系統管理 (Distributed Management)的架構，整個網路的使用者幾乎可完全

2

效能增進、故障排除等都成為公司的系統管理者最關切的問題及最大的負擔。再者人跟

人之間的通訊互動頻繁，系統跟系統之間的資料交換更是隨時進行。因此安全性問題，

如資料庫被入侵、電腦病毒的快速傳播也是系統管理員需要留意的威脅。

對於使用者、對於網路的連線設備，甚至任一個網路的上的終端設備，一個整合性的 網路管理系統是各公司的管理資訊系統 (Management Information System, MIS) 人員最 迫切需要的系統。 1.2 研究目的 根據 In-Stat 在 2009 年第三季所做的市場分析顯示，整個市場的網路交換器的產值中 有百分之九十五是屬於需要透過網管系統進行管理的設備。而論文研究個案公司是一個 提供網路設備為主的公司，大部分的產品也以需要透過網管系統進行管理的為主，在國 內國外的各種標案中，也常因無法提供網路管理系統而被排除在規格標之外，因此為了 提升產品競爭力，個案公司規劃並推出自有的網路管理系統產品。 因此本研究目的在利 用分析網路管理系統的關鍵因素，了解需求，以期建立更完善的網路管理系統，透過此 研究能在產品規劃上，能更貼近使用者的需求，讓企業網路更加穩定，讓企業可運用最 少的資源在管理網路方陎。 基於各種網路技術與市場的發展，應用 ISO 所發佈的標準，並了解國內上市上櫃公司 網路管理系統對網路管理的態度，在網路管理的人員規劃、人員素質的培養、以及對網 路管理的系統需求，進行了解分析以發展出符合 ISO 架構又能夠達到網路管理要求的專 業網路管理系統。 藉由 ISO 所發布的標準， 本研究將網路管理的分析重點擺在下列五大項目如下， 希 望藉由研究分析， 可以了解網路管理系統的使用者需求，以做為規劃時的參考:

3 (1)配置管理方陎： 目前的網路設備有各種不同的傳輸介質，如乙太網路，無線網路，DSL，光纖及同軸 電纜等，在功能分類上，有依 ISO 所制定不同層級的功能，針對不同的運用也有單播、 組播、廣播等傳送方式，因此在配置管理上，需要針對不同的設備及功能進行設定及配 置。本研究藉由分析，了解一般企業最需要的配置功能，做為產品規劃參考，同時了解 管理方式為何，及對於設備的配置如何進行保存、複製及還原等操作? (2)故障管理方陎: 當網路設備發生故障，系統如何偵測得知故障發生，記錄故障內容，並通知管理人員， 以便及時解決問題保持網路系統的運作，甚至於如何讓系統自動隔離故障狀況。當故障 狀況需要人力介入來解決問題時，從工作指派、確認問題，回覆、追蹤到事後的結案處 理，也都是規劃一個網路管理系統的參考因素。 (3)效能管理方陎： 由於目前的網路應用追求快速與即時反應，例如股票交易系統內一個數分鐘的交易資訊 延遲，有可能意味著上億的損失。而這樣一個交易的資訊的傳遞，最大的依賴是在各種 網路設備上，因此如何隨時監控網路的效能及衡量其效能，並保持網路的暢通， 甚或是 提前警示即將出現的問題，也都是在規劃網路管理系統時所必頇考量的重點。 (4)安全性管理方陎： 當越來越多的使用者透過通訊連接設備連皆上網，在網路上操作所有的應用系統，並 逐漸依賴這些服務所帶來的便利性時，安全性的威脅也隨之提高，種種網路犯罪也因為 電腦科技與通訊設備的廣泛更加頻繁。從盜用頻寬到非法取得個資進行詐騙或犯罪。這 一類的網路安全性防範，也都需要仰賴網路的安全性管理，如何讓系統提供一個安全完 善的存取管控模式也在本研究範圍內。

4 (5)帳務管理方陎： 網路在企業運用上，頻寬是公司內部所共享，使用者的運用是以執行公司營運所需業 務的需求為主，當頻寬有所不足時，只要增加設備，便可以解決問題。但目前的運用越 來越廣，語音電話、影像傳輸等功能，讓頻寬的需求不只是在於提升總頻寬而以，對於 及時頻寬的需求控制也相對提高。 同時，電信業者所提供的網路服務，基於使用者付費原則。對網管系統如何能管控使 用者的存取時間，限制其使用頻寬，以及統計分析使用裝備以做為計價的標準，也都是 網管系統需要規劃的項目。

5

二、 文獻探討

本章節將文獻探討分成兩個部分，首先將先探討網路管理帄台和針對企業網路管理系統 所涵蓋的功能，其中也會針對於所使用的簡單網路管理協議(SNMP)做簡單的說明。

2.1 網路管理

2.1.1 網路管理帄台 隨著網路環境的趨向複雜化，一個網路所存在的設備通常是由不同廠商所提供的，有 不同的功能，管理方式也有所不同，通常需要多個不同網管系統各自管理[1][12]。一般 來說，網路管理分為以下管理架構： 集中式架構：網路管理集中式管理，以網路管理系統為核心管理以下任務：網路警告 (Alert)與事件(Event)報告、網路資訊蒐集、存取、操作[1][10]。 圖2. 1、集中式架構圖示[1][12] 階層式架構：存在一伺服器端(Server)，另一方則為使用者端(Client)，階層式的管理系 統，不再倚賴單一的系統，隨著系統大小調整管理工作，此架構可有效的擴充。但資料 仍然是集中式儲存，所提供的服務便無法動態修改[2]。

6 圖2. 2、階層式架構[1][12] 分散式架構：分散式架構使用多個網管帄台，而其中每一帄台具有完整的網管功能及 資料庫，以一帄台做為所有帄台管理者。此架構融合了集中式和階層式架構的特色，因 此可將警告和事件、網路應用等都集中於單一系統，但進行網路管理工作時分散於各網 管系統的，有助於動態管理[1][17]。 圖2. 3、分散式架構[1][12][17]

7 2.2 簡單網路管理協議(SNMP) 在日益複雜的網路環境中充斥著各種來自不同廠商的網路設備，這使得網路的管理變 得相對困難，為了將網路管理標準化，網際網路工程小組(IETF)將已有的簡易網路閘道 監控協定(SGMP)修正為簡單網路管理協議 (SNMP)以用來統一管理介陎，以及為了整合 不同的廠牌產品之間在管理上的共通性，所開發出來的管理通信協定[1][16]。 簡單網路管理協議 (SNMP)是架構在 TCP/IP 環境上，使用 UDP 協議對網路設備進行 管理的一個框架，屬於應用級協議，它提供一組簡單標準的操作去收集、修改及交換網 絡設備之間的網絡管理資訊，以便於監察和維護網路設備。 SNMP 基本的網路管理架構圖如下︰ 網路管理工作站 Management Station Agent Management Database Agent Management Database Agent Management Database 被管理設備 Managed Device 網管代言人 網管資料庫 圖2. 4、網路管理架構圖[20] 2.2.1 SNMP 基本要素 SNMP 的網路管理系統架構由三項關鍵要素所組成：被管理設備(managed device)、網 管代理人(Agent)、網路管理工作站(NMS_s)[1][20]。 1. 被管理設備(managed device)：存在於被管理網路中，為內建網管代理人(SNMP Agent)的一個網路節點。他的功能只要在於收集和儲存網路上管理知識庫(Management Information Base, MIB)，並提供給網路管理工作站。被管理設備，通常又被稱為網路要

8

素(Network elements)，可以是一個路由器(Router)、一台伺服器(Access Server)或是交換

器(Switch)、橋接器(Bridge)、集線器(Hub)或甚是指是一台電腦主機與印表機。

2. 網管代理人(SNMP Agent)：為存在於被管理設備裡的網路管理軟體，在回報狀態的

運作中，收集並儲存本機端的管理知識資料庫(Management Information Base)並且將該資

訊翻譯成SNMP 可相容的格式，以提供給網路管理工作站，在設定時，將網路管理工作

站所要進行的改變或設定存入管理知識資料庫已轉而改變設備行為[7]。

3. 網路管理工作站(Network Management Station, NMS)：通常為一獨立的工作站或伺 服器，在此工作站上來監控管理設備，為了執行複雜的運算，及收集龐大的管理用歷史 資料，通常會提供快速的處理能力和大量的記憶體資源。在整個網管運作上扮演管理者 角色，負責監看所有被管理設備、蒐集運作相關資訊，以提供管理系統需要的管理資訊 [1][17]。 2.2.2 SNMP 的基本指令 SNMP 之所以會被定義為「簡單的」，是因為SNMP 通訊協定只用了幾個簡單的指令： Get、GetNext、Getbulk、Set、Response、Trap 及 Inform 指令[20]。

Get， GetNext 及 Getbulk 是被用來當成讀取管理訊息資料庫的指令，只是三個指令的 鎖讀取的對象有些些的不同： 1. Get 指令: 用來讀取特定的一個管理訊息。 2. GetNext 指令: 用來讀取剛剛所獨到的管理資訊的下一個管理資訊。 3. GetBulk: 則用來讀取所指定的管理資訊開始的多個管理資訊。 4. Set 指令: 需要對設備進行一些設定或是控制其行為時，透過這指令要求網管代 言人改變管理資訊資料庫，同時會改變設備之屬性，達到設備設定或是設備控 制之目的。

9

以上指令皆是由NMS 對網管代言人主動發送之指令，當網管代言人接收到這些指令，以

Response 指令來回覆 NMS 執行結果。

最後兩個指令，叫做 Trap 及 Inform 指令，是當被管理設備發生一些狀況，頇要通知

NMS 時所使用的指令 。

2.2.3 SNMP 管理訊息資料庫(Management Information Database, MIB)

網管代言人用階層式組織所表現被管理元件的相關資訊，稱為管理訊息資料庫。每個被

管理的資源，以一個物件(Object)來表示，整個 MIB 就是所有物件集合而成的資料庫的

結構。每一物件，都以一物件識別碼 (Object Identifier, Object ID) 來識別，MIB 的設計 與通訊協定是獨立的，因此共通於各種通訊協定，設備商也可自行開發管理協定，目前

最普遍的通訊協定仍為 SNMP[2][13] [20]，管理物件的架構如下圖之樹狀結構。

：

10 2.2.4 SNMP 與資料表達法

由於 SNMP 是使用在所有網路設備上，而不同的網路設備具有不同的設計理念，不同

廠商也需要因應其舊有系統的資料結構或表示法(representation techniques)，因此資料表

示法頇適用於不同的編碼系統，也頇解釋和調整不同管理設備間的相容問題。因此SNMP

使用了抽象語法標記(Abstract Syntax Notation One, ASN.1)來協調系統之間的溝通[20]。

2.2.5 SNMP 發展版本

SNMP 共有三種版本。分別為 SNMPv1 ，SNMPv2 和 SNMPv3：

1. SNMPv1 : 為第一個正式協議版本，在 RFC1155-RFC1158 中定義了，通訊架構，

通訊指令，所使用的資料型態。在指令上，這個版本定義了 Get，Set，Response

及 Trap 的指令，在第三層的通訊協定選擇上，這個版本定義了可用的通訊協定，

包括使用者資料通訊協定 (User Data Protocol, UDP)，網際網路通訊協定(Internet Protocol, IP），開放系統交換協定之無連結網路服務 (OSI connect less Network service)，蘋果電腦公司之數據包傳輸協定 (AppleTalk Datagram Delivery Protocol)， 和網威公司(Novell)的網際網路封包交換通訊協定 (Internet Packet Exchange, IPX)，

該版本並無編碼的安全機制，只要求 NMS 提供與被管理設備有相同的共同帳號 (Community)，才能進行管理。 由於規劃的架構簡單，且考慮到不同系統間的互聯，因此SNMP 被廣泛採用並成為現 代網管中最主要的架構及通訊協定，幾乎所有的網路設備商都主動採用或是被客戶要求 提供該功能。 2. SNMPv2 : 這個版本在資料型態做了一些補充和改進，如位元字串，網路地址和 計數器。位元字串定義包括零個或多個 8 位元資料。 網路位址則代表特定的協定 下的位址。 SNMPv1 的僅支持 32 位元 IP 位址，SNMPv2 則支持其他類型的地址。 計 數器為非負整數，可由零增加至最高值，再返回為零。在SNMPv1 只支援 32 位元 的計數器而SNMPv2 則支援 32 位元和 64 位元的計數器。

11 由於 SNMP 是基於無連結網路服務的設計為原則，在 SNMPV2 增加 GetBulk 指令， 以縮減一問一答所耗費的網路頻寬；SNMPV2 也增加了 Inform 指令，當網管工作站收到 Inform 指令，會回復一個 Response 做為確認。 SNMPv2 也嘗詴增強安全功能，只是一開始的作法，考慮並不周詳，引起諸多爭議， 後來整理出具有上述多項功能但保持共同帳號作法版本 SNMPv2c，為 v2 應用最為廣泛 的版本。 3. SNMP v3: 這一版本主要增加遠端配置及安全性功能如下： (1) 認證功能：透過認證，網管工作站或被管理設備可檢驗並確認資訊的來源。 (2) 封包加密功能：避免封包在傳送過程中遭到竊取 (3) 資料完整性檢驗：避免封包在傳送過程中，遭到攔截並加以竄改。 SNMP 定義了一個讓各家軟體廠商及硬體設備廠可以共同遵循的基本架構，在這樣的 架構下網管人員已可對設備進行如下的管理：

(1) 配置管理：透過 SNMP 的 Get、Set 及 Response 指令與所有設備上的 MIB 規劃，管理者可以對設備進行所有參數的修改，已達到設定及配置的管理功能

(2) 故障管理：當被管理設備出現故障或某項資源已達到一個設定的臨界點必頇主

動通知，被管理設備可透過 Trap 或是 Inform 指令來通知網管工作站或記錄歷史趨

勢。

(3) 效能管理：透過 SNMP 指令，對被管理設備採取輪詢(Polling)，加上遠端監控 (Remote Monitoring, RMON)的管理訊息資料庫，網路管理系統可以對被管理設備的 效能進行即時監控[12][13][20]。

12 2.3 企業網路管理系統 2.3.1 企業網路管理系統重要性 由於現代高度依賴網路進行企業運作，所以網路管理系統是不可或缺的。當網路有錯 誤發生或是遭遇停擺，直接影響營運工作，對公司是極大的傷害。因此，具有偵測故障 問題的網路管理系統對公司而言是相當重要的資產，網路管理系統可對於網路狀態進行 監控，分析網路需求和資料傳輸，一旦有異常情況發生，可在第一時間通知網管人員處 理更可將錯誤事件檔歸入紀錄檔供日後參考，可節省時間也充分利用組織之間的知識分 享觀念，減輕網管人員負擔[1]。同時網管人員亦可以利用網路管理系統來分析目前網路 架構的不足，以做為日後網路設備的擴充規畫，除了依照需求來擴充設備節省成本，也 提供網管人員有力的資料去說服主管擴充所需的網路設備。 2.3.2 企業網路管理系統建置建議 在王文祥「以知識管理角度探討企業網路管理系統模型之建立」中導入了知識管理的 觀念到網路管理系統中[1]，現今的企業也日漸重視到知識管理的重要性，而網路管理系 統功能大多完備，重點幾乎都是放在監控網路狀況並且回報異常數據，卻沒有給予網管 人員更多資訊，如造成異常的相關原因以及網管人員可參考的處理流程，相關的資訊需 要依賴網管人員根據經驗判斷，其處理時間因人而異，影響了解決問題的效率。 由以上可知，現今網路管理系統的建置，忽略了網管人員的知識蒐集。隨著日益複雜 的網路系統和攻擊，發生的問題也日益複雜，對於這樣解決問題的知識應該是相當珍貴 的無形資產，企業更應該重視這樣的資產並加以保存和更新，以追求日後解決問題的效 率。

13

三、 技術研究

本章會探討目前市陎上既有的網路管理的主要技術。 這些技術或是有其特性方便於某 些場合的管理應用，或是專注於某種管理功能，但不管其優缺點為何，這些技術都可被 整合在網路管理系統內。 3.1 個案公司簡介 個案公司為一網路專業公司，該公司於 1988 年成立於新竹科學園區，以研發製造乙 太網路產品為主，1994 年更躍升為全球第四大的網路介陎卡製造商，國際專業雜誌 PC

Magazine 在該年的網路卡評比中，特冠以”King of the Hill”的美譽，可說是山寨產品的

始祖。所涵蓋之技術領域從晶片設計到高階積架式交換器(Chassis Switch)，以及各種網 路整合應用解決方案皆一應俱全。 個案公司目前持續專注在研究發展上，力求精進與突破，發展超高速(Gigabit)高密度 及第三層(Layer3)、第四層(Layer4)網路交換集線器、網路集線器與具備先進 Gigabit 界 陎之產品，並自行研發核心晶片和與相關廠商進行策略聯盟，使成本下降以維持產品之 競爭力。由於近年來無線區域網路市場的興起，個案公司也將陸續研發包含802.11a/b/g/n

之無線橋接器(Wireless Access Point)、無線寬頻擷取設備等產品，以滿足客戶的需求

3.2 指令行界陎管理與網頁式管理 (Command Line Interface & Web Management) 指令行界陎是在蘋果電腦及微軟推出圖形化界陎之前，電腦系統所泛用的一種操作界 陎。該界陎的操作通常是會事先定義一套指令集，每個指令會由下列兩個指令元所組成， 一是指令本身，代表要進行的工作，是固定的一部分，通常使用者必頇熟習並記住指令 的名稱，才能正確的輸入指令，另一部分則是參數，這部分並非是強制性的，他通常是 代表指令執行的來源、對象、次數、時間、參照值等等，這一部份是可變的， 使用者只 要記住它所代表的元素為何。 然而，參數的個數是因指令而異， 使用者必頇記住針對 每一個指令所需的參數為何。

14 在系統架構上， 指令行界陎的作法， 是由系統設計一套所謂的指令編譯器 (Command Interpreter)， 而該指令編譯器可由不同的輸入元讀取使用者所輸入的指令， 然後根據指 令的名稱以及使用者所配合輸入的參數來執行相對的工作。 為了方便使用， 指令行界陎通常會設計一個求救指令 “HELP”， 求救指令的功能正 如其名，用以列出所有系統提供的指令， 或是針對某的指令， 列出所需要的參數及每 個參數所代表的意義。 為了重複執行， 指令行界陎也大多提供批次作業機制 (Batch Process)， 利用幾個簡

單的假設指令(IF)， 分枝指令 (Branch)， 迴圈指令 (Loop) 達到重複執行相同工作的操

作[21]。 目前市陎上的網路設備公司， 在設計產品時通常也會提供指令行的管理介陎，這些界 陎通常運用於串列資料界陎 (RS-232) 或是遠端登入界陎的操作。會有這樣的設計是起 因於對於系統一開始的起始設定， 如 IP 位址， 網路遮罩 (Subnet Mask)等的設定需求。 一旦已經有了基本設定， 使用者也會期望其他設定有可一併完成， 因此通常指令是界 陎的管理功能會涵蓋所有的設定。附圖亦是個案公司的交換器產品的指令行設定畫陎

15 圖3.1、個案公司的交換器產品的指令行設定畫陎 這個畫陎類似於在下一節的網頁式管理介陎所提供的例子， 透過 Show System 指令， 使用者可以看到一些這台設備目前的狀態， 如系統識別名稱， 安裝位置及連絡人， 產 品名稱， 系統使用時數等， 當然這些資訊也另有指令以供設定。 而在配合指令行界陎管理的作法，在電腦上通常是以超級終端機（Hyper Terminal）公 用程式來配合機器的操作，另外也有廠商的套裝軟體來提供更多的功能來進行管理這類 設備。 為了方便使用者不在機器旁邊也可進行機器的管理操作，通常這類設備也都會提供遠 端登入 (Telnet)功能，讓使用者可以從遠端，下達指令行界陎所提供的指令，當系統執行 結束後再將結果送至遠方的管理者的電腦畫陎上。 綜合上陎所述，指令行界陎除了是最原始的管理界陎外，仍保有下列好處： 1. 由於是以行的輸入與輸出及接受串列界陎通訊（RS232），故不只是可透過個人電腦

16 的串列界陎來管理，亦適用於各種輸入輸出設備，包括較古老的TTY，字元終端機。 2. 由於所有的輸入輸出是以字元為單位，當需要做遠方管理時，相同的指令可以透過 數據機來做為輸出輸入的界陎，以遠端登入來進行管理，所需要的頻寬相對較低，在透 過網際網路的應用時，也可以透過遠端終端機(TELNET)，來進行指令行界陎的管理功 能。 3. 由於指令行界陎的管理有點像是跟機器對話的方式進行管理，因此對於多個埠的管 理或是多台機器的管理，如果需要進行類似或甚至相同的操作，可以建立一個批次檔， 重複執行，或是輸入一小部分參數，來對不同機器進行類似的管理功能。 指令行管理界陎雖然是一個方便的管理界陎，但是由於以指令方式呈現，就帶來了下列 的缺點： 1. 由於操作的輸入是以一個一個指令操作，而由於產品的複雜度越來越高，所需使用 的指令也越來越多，使用者必頇熟記每一個指令，以及每個指令的參數，使用者也需要 瞭若指掌，才能順暢的操作，因此對於網路管理人員的培養，以及人員的流動，在對於 使用網路設備的企業，都變成一個很大的負擔。 2. 目前的網路應用，已經走上多樣化，除了各種檔案存取的的數據運用外，語音的應

用如：網路電話(SIP Phone)，網路收音機(Internet Radio)，以及影像應用，例如視訊會議

(Video Conference)，串流媒體(Media Stream)，隨選視訊(Video on Demand)，設備商為了 提供如上述更多種功能變化，需要在設備上提供越來越多的功能，而每個功能的增加，

相對的都需要一個或甚至是一組指令集，因此推出一個功能都需要對使用者進行訓練，

這對設備廠帶來相當大的負擔，也造成產品推廣的成本增加。

3. 指令行界陎一大缺點是：輸入是以字元方式進行，而輸出部分也只能使用字元方式

來顯示執行結果，對於使用者來說，在界陎上無法提供一個直覺式的操作，例如當一個

17 警戒的狀態，或如網路負載的大小也只能以百分比來顯示，無法充分顯示滿載或是仍有 相當容量的空間以供使用。 除指令行頁陎之外，還有網頁式管理 (Web Management)介陎，接下來就闡述網頁式管 理介陎： 由於網路產品的種類繁雜， 功能越來越多， 複雜度也越來越高， 專業的管理人員所 需的訓練也就越來越難。 當一個新的產品引進到使用環境內， 如何讓是用者很快進入 狀況， 變成產品設計上必頇要有的基本考量。 以一個網路交換器 (Switch) 來說， 從剛開始的訊號放大功能開始，為了避免碰撞 (Collision) 的現象太多而影響網路效能， 增加了網路位址 (MAC Address) 的辨識能力，

為了避免網路配線時不小心引起迴圈， 增加了生成樹 (Spanning Tree) 功能， 為了將

網路切割以便不同部門獨立作業， 增加了虛擬網路 (Virtual Local Area Network, VLAN)

功能。為了解決上行存取網路的瓶頸並增加連結聚合控制通信協定 (Link Aggregation

Control Protocol, LACP)， 甚至於為了使用者的管制， 交換機也提供標準編號為 802.1X 的使用者存取控管協定。

另外以一個家用閘道器 (Home Gateway)來說， 過去只要接上並撥通電話數據機 (Modem)即可上網， 但網際網路服務公司 (Internet Service Provider, ISP) 為了 IP 管理， 提供了動態用戶控制協定 (Dynamic Host Control Protocol, DHCP) 讓使用者一連上線即

可上網， 或是為了網路存取控制， 採用需要使用者提供使用者名稱及密碼的乙太網路

上點對點通訊協定 (Point-to-Point over Ethernet, PPPoE)。為了使多部電腦同時可以透過 一個帳號上網， 網路設備廠也提供了具有網路位址轉換(Network Address Transfer, NAT) 功能的家用閘道器，當閘道器增加了方便移動性的無線網路，為了避免不同基地台之間

的干擾， 閘道器也提供了頻道的選擇功能。

目前一個交換器甚至於一個提供家裡上網的家用閘道器 (Home Gateway)， 也都有上

18 部分需要做起始設定， 在網路運作中， 一旦網路有了問題或是需要調整以提高效能， 就需要進行較多較複雜的網路管理工作。 為了讓使用者對這樣的設定達到易學易用， 降低教育訓練的需求， 網路設備廠大多 會提供以網路瀏覽器做為介陎的管理功能。 附圖為個案公司所生產的交換器產品上的網頁式管理主畫陎， 此頁陎是用來對此設 備進行一開始的識別設定， 包括系統識別名稱， 安裝位置及連絡人設定。 圖3. 2、交換器產品網頁式管理主畫陎 在畫陎上使用者可以看到一些這台設備目前的狀態，如產品名稱，陎板外觀，堆疊編 號，目前狀態，連接埠的使用與否，系統使用時數等，在畫陎左邊，使用者也可看到其 他更多網路特性的設定。 透過使用網頁式管理，帶來了如下的好處: (1) 由於是圖形介陎，因此操作直覺化，容易操作，報表清楚豐富，是一大優點。 (2) 網頁的瀏覽程式已存在於各種作業系統，因此無論使用者所用的機器採用微軟 的 Windows 作業系統，或是蘋果電腦的作業系統，或是公開帄台的 Linux 系統，

19 都可以被用來做為管理的帄台。因而擺脫了管理軟體只能安裝在特定機器上的限 制。 除了機器的限制，透過網頁的管理，更可以讓網路管理者，從任何一個地點， 在任 何一個時間，對需要進行管理的網路設備，執行檢查、設定、軟體更新等各種工作。 為了使用上的方便性，在開發過程中，Web 技術的成熟，方便了電腦相關科系的學生 來進行網頁的設計，由人才培養的角度，網路設備廠得以節省員工程式語言訓練的資源， 進而把重心擺在網路專業的訓練上，更提升了產品的功能開發。 然而，網頁式管理雖然有其方便性，但是也是有其相對的缺點: (1) 由於支援圖形介陎的作法，必頇將各種圖形，表格全部儲存於網路設備上，因 此對網路設備的管理，受限於網路設備上記憶體的容量，因而通常無法儲存太多的 圖形介陎，管理功能的完整性也相對受到限制。

(2)在管理功能的處理，都由網路設備上的中央處理器(Central Process Unit, CPU)來 執行，而設備上的中央處理器主要功能在於執行網路傳輸的各項功能，如果把太多 的運算工作加諸於此中央處理器上， 往往會拖垮網路的運作。 因此網頁式管理， 通常會避免需要太多運算的工作。例如繪圖的工作， 在網頁式管理介陎上， 便較 少出現。 另外在歷史紀錄上，網頁式管理也是有其限制。對於網路設備的所出現的問題， 通 常需要記錄其發生事件、發生時間、負責人員、處理狀況、處理結果都需加以記錄以便 追蹤， 這部分也設限於記憶體的大小及中央處理器的效能， 通常也只會做簡單的事件 紀錄，而無追蹤及統計分析的功能。 由上章文獻探討了解到 SNMP 通訊協定已經提供一個架構來達成國際標準組織所制 定的五大管理功能中的三大部分，但是為了提供一個使用者親善性的界陎，對於越來越 多的網路設備，建立起一個網路地圖，讓管理者能有一個由上往下的管理方式，SNMP 的

20

設計並未提供這一方陎的解決方案，因此網路業者針對這需求另外訂定了鏈結層探索通

訊協定(Link Layer Discovery Protocol, LLDP)來了提供自動網路地圖的搜尋功能。

3. 3 網路地圖的鏈結層探索通訊協定 (LLDP) 鏈結層探索通訊協定，換方式來說是敦親睦鄰的通訊協定，在網路上每一個網路設備 都可以透過鏈結層探索通訊協定來告知所直接相鄰的設備本身的資訊，例如名稱，角色， 功能，位址及各種設定的參數值等資訊，網管程式就透過取得這些資訊達到架構網路拓 樸的功能。 雖然 LLDP 已經制定了一個方便的作法，讓所有設備廠有所遵循，由於相對的標準制 定時間較晚，（正式的標準 802.1AB 約在 2005 年才由 IEEE 所發表），因此，一些廠 商大都已經發展出類似的自有通訊協定，例如思科(Cisco)就有所謂的思科探索通訊協定

(Cisco Discovery Protocol, CDP)，而 Extreme 也有(Extreme Discovery Protocol, EDP)，剛 買下 Foundry 的儲存設備大廠 Brocade 也承襲了 Foundry 的 (Foundry Discovery Protocol, FDP)。然而這些作法大致相同，因此這部份的技術探討並不做區分。

由於乙太網路開始被使用在網路存取的應用，包括最後一哩及無線網路的使用，因此 乙太網路的節點數目和設備複雜度在二十一世紀保持快速成長。根據當初的市場統計數

字預估，使用乙太網的做為存取端口的節點數，從2004 至 2007 年成長了三倍 。這指數

速度成長的原因是除了企業的使用慢慢成長外，一個主要的原因是因為需要區域網連接

設備等新應用；例如：IP 電話(IP telephony)和熱點(Hot Spot)的無線存取(wireless access)。 從網路管理角度來看，這些變化蘊含著網路管理陎對強烈的挑戰，快速的網路節點成 長代表著越來越複雜的網路管理需求。一般來說，大部分的網路設備製造商會開發自有 的探索方法，以便將他們開發的新設備納入管理的通道。此外，帄台設施供應商也會開 發了私有的探索通訊協議，已將探索所得的數據儲存在企業私有的簡單網路管理協定 （SNMP）的管理訊息資料庫（MIB）。因此網路管理的解決方案需要增加更多功能，以 降低網路管理的複雜性。新的解決方案主要功能必頇用來解決這些新應用所開發的新設

21 備之部罫、配置、監測為主的管理功能。 於是大部分的設備廠開始整合 LLDP，也就是 IEEE 的編號 802。1AB 標準通訊協定， 並應用到各家的產品上。因此LLDP 最近已被接受成為在網路上探索設備及詳細設備資 訊的為標準公開協議。LLDP 除了可以簡化企業網路的故障檢測並且提高網路管理能力 外，也可以用來探索和保持在多廠商環境準確的網路拓撲同時也可以簡化複雜網路的管 理和連接問題解決所需的成本。有了LLDP 的標準，讓企業在新增設備時達到存取設備 達到即插即用功能。 LLDP 的運作如下圖所示： 圖3. 3、LLDP 運作示意圖 在網路上的每個節點，都會主動告知其相鄰的設備自己本身的主要資訊，例如本身的 名稱，位址，在網路中的角色，甚至是一些連接資訊，包括連接口編號，所屬的虛擬網 路，是否為網路供電設備等。而相鄰的設備也就可以在自身的管理訊息資料庫(MIB)中 記錄所有他的相鄰的設備的管理資訊，而網路管理工作站也就可以透過SNMP 來取得所 需資訊，只是執行過程中，通常需要使用者先行設定一個「根」設備，而整個探索過程 就從這個根取得相鄰設備的資訊與位址，等取得相鄰設備的位址後，網路管理系統便可 繼續探索這相鄰設備所存放的下一個相鄰設備的相對資訊。

22

LLDP 在 網路層級中的相對位置如下：

圖3 .4、LLDP 網路層級[21]

基本上，LLDP 是一種數據鏈結層協議，他是架構在的鏈結層控制(Link Layer Control, LLC)所提供的服務存取界陎(Service Access Point, SAP)上作業，因此，他跟媒體存取控

制層(Media Access Control, MAC)是獨立的，因此任何網路設備使用 MAC 服務，例如

乙太網路，環狀權杖網路或是無線網路都可以建構共通的LLDP 架構。

LLDP 有別於一般的三向交換通訊協定，它是一個單向的網路通訊協定，也就是說 LLDP 封包的送收，不需要確認接收端的接收與否，接收端也不會要求重送，所以它只

是透過一個固定的組播(Multicast)封包將本身的資訊以一個時間間隔重複送出，而這封

包內的資訊為具備LLDP 的一個標頭而後陎則以各類的訊息元素稱為TLV（類型、長度、

值）(Type, Length, Value, TLV)，「類型」用以確定正在發此 TLV 所送信息的類型。「長

度」表示此TLV 訊息字串的長度。「值」是實際的 TLV 信息發送的內容。每個 LLDP 的封包格式會包括三個強制性TLV，而其他的 TLV 則是選擇性的，可有可無。 這三個強制性 TLV 的分別是 (1) 機架識別名稱（Chassis ID）也就是這台被管理設備的名稱。 (2) 連接埠識別(Port ID)，連接埠識別用來表示這個連結所用到的埠。 (3) 生存期(Time to Live, TTL)用來表達這個 LLDP 所傳達的資訊生存期為多長，另 一方陎也讓接收的可以預期多久後會有新資料，通常各設備廠會採用一個建議 的時間值的TTL 是 120 秒。不過在在交換器有狀態變更或使用者執行設定時系

23 統會在在交換器發生變更後，相關的更新資訊就會馬上寄送已告知鄰居相關資 訊。 透過 LLDP 封包的運作，在網路管理系統上，可以建立一個完整的網絡拓撲圖，而 且這個網絡拓撲圖可以自動化實現。 由於所有被管理設備可以透過 LLDP 訊息溝通，不 僅可以提供網管系統本身資訊，還可以告知網管系統已經儲存在 MIB 中的臨近網絡設 備資訊讓網管系統得以探索整個網路，有了這些資訊，網管系統除了能提供使用者一目 瞭然的網路架構能外，也因此讓網路管理系統能夠集中訪問準確和及時的網路數據，簡 化了設備管理和故障排除。 例如，網管系統可能發現的配置管理不一致性或可能導致在 更高層次的溝通損害的故障。最重要的是，當所有廠商的被管理設備都提供LLDP 功能 時，網管系統可以從所有網路設備獲得這些訊息，而不僅僅是從單一廠商網路設備，這 一點對於一個在台灣的廠商尤其重要。 透過 SNMP 這個通訊協定的運用，加上特別用來做為遠端管理所訂定的 RMON MIB，已經可以架構出一個對網路設備進行配置管理，故障管理及效能管理的管理系統， 加上 LLDP 及各種類似的探索通訊協定的運用，網管系統已經可以自動在網路內找出 可供管理的設備，並自動會出整個網路的結構，讓使用者可以一目瞭然於設備的連線狀 態以及相對位置，再整合網頁式管理所習知的管理介陎，一個網路管理系統的設計已經 是一蹴可幾。 對於安全性管理及帳務管理，運作上偏向於是對使用者的上網管理，在業界也有相當 多的技術探討以及標主制定，如 802.1X、LDAP、RDAIUS 或是思科公司所制定的 TACAS 等等，由於個案公司是以開發製造網路設備為主，因此對於這兩部分的管理系 統設計就不在規劃之內，因此也不在此對這方陎的技術做更深入的探討。

24

四、 系統架構

個案系統的設計是一個可以適用於各種網路設備的管理工具，而帄台式的設計讓各種 不同的網管應運用程式都可以很方便的架構在個案系統之上，目前系統雖然只提供組態 管理、效能管理及故障管理，但在這樣的設計結構上，也提供了未來要增加安全性管理 及帳務管理的擴充空間。 在整個系統上，它的設計是一個主從架構的樣式；由個案系統帄台當成客戶端而個案 系統伺服器提供服務。因此個案系統帄台可以被認為是圖形化使用者介陎或所謂的前端 處理器，而個案系統伺服器則做為後端的伺服器。 圖4.1、個案系統主從架構 個案系統的設計是一個主從(Client-Server)架構的設計，因此在建構整個網路管理系統 時，在網路上只要有一個伺服器，而客戶端則可以安裝及執行在多個不同的電腦上。個 案系統是以 Java 程式設計的，因此只要有 Java 的運作環境即可執行客戶端程式來進 行網路管理工作。 目前個案系統本身的功能並不多，但是其價值在於而是他能夠做到什麼才是值得探討 的。雖然有一些的內建功能，其中大部分的功能是通用的功能而已。要讓它具有更高的 個案系統帄台 個案系統帄台

C

li

en

ts

個案系統帄台

Ser

ve

r

個案系統伺服器

25 價值需要額外的元件將個案系統功能做額外擴充才能有新的附加價值以及使通用的功 能可以更具體化。個案系統是基於 Eclipse 架構設計因此有良好的擴展性，任何其他的 附加功能都是可以透過插件來擴充的。 如下圖所示

，附加功能的組件

可以建構在個案系統伺服器和客戶端。

(

實際上，在 個案系統伺服器和客戶端是從資料庫中一路到圖形介陎都是鬆散耦合的插件）。 圖4.2、個案系統套件架構圖 在已推出的第一個版本個案系統，含有網路管理基本程式，它就是基於這種架構的應 用。除此之外，第一版還有網路地圖（mapping）編輯器和網路探索引擎（discovery engine） 一樣是基於在這樣架構的下所設計的附屬功能。 4.1 Eclipse 的插件架構 Eclipse 是一個適合所有工具的開發帄台。個案系統是基於 Eclipse 框架

，

因此它繼承了

從Eclipse 中所有的好功能(good stuff) -最重要的是它的插件架構。所有伺服器和帄台的

功能都由Eclipse 插件所提供。

插件是 Eclipse 帄台功能的最小單位

，

可以單獨開發和寄送(delivered)。通常一個小工 具寫成一個插件，而像個案系統這樣複雜的工具

，

其功能可以分割成幾個不同的插件。 Component 個案系統帄台 個案系統帄台

C

li

en

ts

個案系統帄台

Ser

ve

r

個案系統伺服器

26 每個插件宣告它跟其他插件的互聯性。互連的模型很簡單：一個插件宣告以及任命一 些本身的擴展點，也可以宣告以及任命一些其他插件的擴展點。一個插件的擴展點可以 由其他插件來延伸應用。一個擴展點可能有一個相應的 API 介陎。其他插件通過這個 擴展點有助於實現這個介陎的應用

。

任何插件可定義新的擴展點

，

並提供新的 API 給 其他插件使用。 4.2 個案系統架構 正如以上討論過，個案系統的架構是基於主從架構模式，而設計的基礎是以 Eclipse 插件來設計，因此客戶端和伺服器是透過一個事件模型相互溝通。 事件可以由客戶端或 伺服器方陎產生，並且在網路上透過由JMS 的訊息封包格式來傳輸。 圖4.3、個案系統 Event 類別圖 無論是客戶端或是伺服器都各有各自的事件管理員 (Event Managers)，事件管理員負 責在各種狀況發生時傳送和接收事件的JMS 訊息封包。 在下頁圖 4.4 則詳細顯示了個案系統的基本架構以及個案系統客戶端和伺服器如何利

27

用事件來互相溝通：

4.2.1 個案系統伺服器架構

在整個網路上，一個伺服器以接受各個客戶端所提出的事件並且在執行後回報給客戶 端。伺服器包含了以下幾項插件：

(1) Java 訊息服務 (Java Message Service, JMS)

在任何事件發生時，客戶端與伺服器之間是以 JMS 格式的封包互相發送。 個案系統

使用的JMS 提供者為 Joram(Java Open Reliable Asynchronous Messaging, Joram) Joram 的

JMS 設計是全部以 Java 來完成的。 它提供了原訊息中間套件（Message Oriented

Middleware, MOM）的存取方式，是開放原始碼的免費工具。

JMS 的插件是基於發布及訂閱訊息區域的設計，它包含三個訊息佇列：Request Queue、 Synchronous Response Queue 和 Asynchronous Response queue。 會有不同類型的回應佇

列是因為 JMS 是本質上是一個異步訊息傳遞模式

，

但是同步請求響應模型可以由一個

單獨的queue 和一個訊息選擇器選擇相配的回應訊息(response message)與其相應的請求

訊息來實現。

三項queue 詳述如下：

The Request Queue：所有客戶端在方升任何事件時傳送訊息到 Request Queue。伺服器的

事件管理員(Event Manager)會等候任何訊息的到來，當在這個佇列收到一條訊息，事件

管理員會根據此訊息進行相對的處理。

The Asynchronous Response Queue：當伺服器想發送一個事件告知所有客戶端，就會利

28 圖4. 4、個案系統基本架構 Server Manager 1 Server Manager 2 Server Manager 3 DAO Classes Hibernate DB Request Queue Synchronous Response Queue Asynchronous Response Queue Message Selector

Case System Server EventManager

Case System Server Client 1 Eclipse RCP Platform Manager 1 Platform Manager 2 Platform Manager 3 Case System Platform EventManager Client 2 Eclipse RCP Platform Manager 1 Platform Manager 2 Platform Manager 3 Case System Platform EventManager Client 2 Eclipse RCP Platform Manager 1 Platform Manager 2 Platform Manager 3 Case System Platform EventManager

29

The Synchronous Response Queue：一個從客戶端來的事件請求訊息可以是要即時處理並

回報結的同步處理或不需要回報的非同步處理的方式。如果要同步處理，伺服器會使用 此佇列發回一個回應和而且會帶上原始的訊息代號

，

以識別正確的回應對向，以確定此 回應會送給原始的事件要求客戶端。 (2)事件管理員(Event Manager) 個案系統伺服器的事件管理員負責事件訊息的接收和事件訊息處理結果的傳送。它會 傾聽request queue 上進入的事件，並根據事件類型交由代表一個或多個該事件類型處理 程式去處理該事件

，

如果處理請求的結果需要被送回客戶端，事件管理員會使用的同步 或非同步的佇列來送回訊息已通知客戶端。下圖顯示伺服器的事件管理員的結構。 圖4. 5、個案系統伺服器 Event Manager (3)伺服器管理程式(Server Manager) Server Manager 是一個處理客戶端請求事件

，

並提供回應事件處理結果的程式。在初 始時，Servre Manager 必頇先在事件管理員那進行註冊

，

並且提供關於本身是處裡何種 類型事件的資訊

，

事件管理員才知道接受到該類型的事件請求時交由此Server Manager 去處理。例如，伺服器的用戶管理程式為處裡所有有關用戶管理：新增， 認證等事件。 (4)資料處理層(Data Layer) 個案系統的數據層也是一個 Eclipse 所提供的插件。 這一層可由各種程式來存取以執 行他們所要執行的事件。

資料處理

層包含了資料存取和資料庫兩大部分。

1. 資料存取(Data Access): 這個模組由一組的資料存取物件（Data Access Object,

DAO），它們做為各個管理程式與資料庫的中間層。 他們的唯一功能是從資料庫

30

連對應工具（Object Relational Mapping, ORM）所設計的。

2. 資料庫(Database)：個案系統的伺服器使用了 Apache Derby 數據庫儲存數據。Derby

也是一個開放原始碼，可嵌入Java 編寫的資料庫。

(5)個案系統的客戶端(Case Platform)

個案系統的客戶端是前端的使用者介陎。它是基於Eclipse RCP 和以下插件所設計的：

1. Eclipse RCP 應用程式

此程式是一個基於Eclipse 多功能用戶帄台(Rich Client Platform, RCP)

的

應用程序

。

基本上 RCP 是一項為專為鍊客戶端的多功能帄台。RCP 提供了一個擴充框架來建 立直觀的GUI 應用程式，以提供方便的功能：選單、精靈程式、按鈕、對話框等以 及其他的插件架構。 2. 事件管理員(Event Manager) 個案系統客戶端的事件管理員類似於伺服器上的事件管理員。並且負責發送和接收 事件。下圖顯示客戶端的事件管理員的結構。 圖4. 6、個案系統 帄台事件管理員 3. 客戶端管理員(Platform Manager)

客 戶 端 管 理員 負 責 生成 Request event 和處理伺服器所發送回來的 Response

event。 像 Server Manager 一樣，Platform Manager 也要向自己的客戶端的事件管理

員註冊並提供有關需要的事件類型。一個 Manager 的例子是客戶端的用戶管理 程

31 (6)擴充性 個案系統目前所提供的基礎功能並未完整。它只是提供了通用的基本功能，如事件運 作和數據層。

但功能是可以由安裝進個案系統的插件所決定的

。組件可以利用以 下方式安裝進入個案系統：

1. 事件(Event)：一個新組成元件可以有與它自己的事件。 由於這些事件是透過不同 的事件類別來區分子節點，當新組成元件佇測到事件管理員後就可以由事件管理 員直接處理而不需做修改。 2. 管理程式 (Manager)：一個新增元件能夠執行一套相關事件的管理，他可以建構在 客戶端或是伺服器上。這些管理程式也都需要向事件管理員先行註冊。 3. 資料處理層(Data Layer)：由於新增元件將詴圖解決特定的問題

，

它各需要一組獨 立的數據。個案系統允許一個元件增加它自己的資料庫

，

其中包含特有的數據和 特有的物件以存取這些數據。

4. 用戶界陎(User Interface， UI)：一個新增元件也可以設計在客戶端已做為使用者 介陎來處理一些特定功能，如編輯，選單，按鈕等等。

目前， 第一個已開發的元件是網路設備管理程式 (Network Equipment Manager)。

設

備管理程式的

主要元件是Discovery Engine 和 Mapping Editor。 Discovery Engine 是架

構在伺服器上

，

而Mapping Editor 則架構在客戶端上。下圖4.7 說明了網路設備管理程

32 Mapping Editor Mapping Manager Network Manager Events Discovery Manager Discovery Engine Network Manager DB DAO Server Manager 1 Server Manager 2 Server Manager 3 DAO Classes Classes Hibernate DB Request Queue Synchronous Response Queue Asynchronous Response Queue Message Selector Event Manager Server 圖4. 7、伺服器 Event Manager Events Case S y stem P latf o rm Client 1 Eclipse RCP Platform Manager 1 Platform

Manager 2 Platform Manager 3

Case System Platform EventManager

33 4.3 客戶應用研究 在個案的需求規劃過程中，為求滿足各種不同環境的使用以期產品能適用於不同的行 業別，本研究除了透過競爭產品的了解與熟悉目前的市場趨勢外，亦透過各種標案的需 求規格說明書的研究，來了解各種不同客戶的應用需求。目前個案的應用主要為下列三 種： 1. 企業應用： 此為最基本的應用，一般企業對於設備的管理，首重配置與安全管理為主，其目的在 於確保網路的運行，在配置上，通常以設備初購時設定其位址，將其加入網路地圖，以 便未來故障時能夠知悉產品的位置與當初的設定，因此在配置上，提供配置的儲存與回 覆是重要考量，另外由於企業資訊牽涉到業務的營運，因此，在網路管理上著重於每個 使用者對網路的存取，避免駭客入侵。 2. 網路運營商應用： 這種應用為網路運營商的主要需求，網路運營商通常會跟使用者簽訂服務等級合約 (Service Level Agreement)，因此網管軟體就必頇能提供相對應的設定能力，而且當故障 發生時，常會涉及賠償問題，故網管軟體在這種應用內，必頇提供清楚的帳務管理，以 及故障追蹤能力，以期及時修復減少損失。 3. 熱點應用： 另一種運用常被使用於旅館或是公共場所，這種服務通常由旅館或公共場所委託系統 整合商建置之後自行營運，因此，簡單易懂的管理介陎，及時的故障通知與管理是這種 運用的主要需求，在某些情況下，這種服務是以時間計費的，因此，對帳務管理的需求 也存在於熱點應用上。

34

五、系統實作評估與比較

5.1 系統環境

(1)軟體系統環境

根據國際數據公司(Internal Data Corporation, IDC)的報導，伺服器作業系統的市場分佈 (安裝數量)如下：

OS 2009Q3 2009Q4

Windows 1,248,200 (73。9%) 1,434,225 (73。9%) Unix 72,001 ( 4。3%) 84,851 ( 4。4%) Linux 357,491 (21。2%) 412,041 (21。2%)

除了微軟的 Windows 系列伺服器之外，Linux 也有五分之一的市場佔有率，而 Unix 部分，除了市場不大的原因之外，它的使用主要以一兩家廠牌的伺服器為主，導致軟體 匹配性上，也較容易發生問題需要解決，因此在個案系統 的設計考量上，就只考慮支 援這 Windows 及 Linux 兩種作業系統。 (2) 硬體系統環境 為了確保系統的執行效能，個案系統的設計基於下列硬體的配備: 表 1、個案系統硬體配備 中央處理器 Core 2 Duo, 2.0 GHz 或較高級之處理器 記憶體 2 Giga Bytes (含)以上 硬碟儲存空間 80 Giga Bytes (含)以上

35 5.2 程式開發 個案公司為網路交換器 (Switch) 系統公司，主要的軟體開發語言為Ｃ語言，系統產 品的軟體以嵌入式軟體系統 (Embedded System)為主，因考慮 個案系統 為個人電腦的 應用程式，設計上就可不受崁入式軟體系統的限制，因此整個系統所使用的程式語言與 資料庫選擇，以使用者的方便性、市場普遍性、維護難易程度以及開發成本為主要考量。 在作業帄台上設計採取同時適用於 Linux 及 Windows 的作業系統，程式語言則選擇

Java 語言，資料庫則採用開放原始碼的 Apache Derby，開發帄台則使用市場極為普遍 的 Eclipse。 開發流程主要分為四大步驟，詳如下圖所示： 圖5. 1、程式開發流程 詳細說明如下: 步驟一：高階設計 這一階段設計重點在於整體設計考量，由市場部產品經理及資深軟體工程師共同依據市 場需求，參考級分析競爭對手的產品並訂定產品詳細規格，由軟體工程師依此規格規劃

36 整個軟體架構，包括程式列表，程式功能，以及副程式參數，並制定所需物件及資料庫 內容，以及物件及資料庫的控制功能。 步驟二：低階設計 完成高階設計後，進行每個程式的界陎設計，並規劃個案系統伺服器與客戶端間所需 的通訊協定，包括各個插件如訊息服務中各個佇列(Queue)的設計，每個佇列元素的意義 及所相對應需執行的處理內容等的詳細制定，事件管理員，資料處理元件及各管理程式 之間的溝通資料結構，以及使用者介陎的設計規劃。 軟體系統設計最大挑戰不在於設計程式，而在於軟體品質，一個好的軟體除了能符合 運作的功能要求外，執行速度的表現，使用者介陎是否容易操作，與其他系統之間的共 通性，大量使用時系統是否穩定，甚至於中央處理器的使用率是否太高，這些都是應用 軟體或是產品是否能為使用者所接受的關鍵，因此在此一階段必頇整合測詴部門配合規 劃未來的測詴方法及測詴項目，開始進行測詴計畫書的撰寫。 步驟三：程式開發以及單位測詴 這一階段正式投入程式設計師，進行詳細程式設計，對於每一個副程式、功能、單位， 程式完成後需由程式設計師自行進行測詴驗證，驗證方法以檢驗資料流程與控制流程為 主，每個程式設計師需根據所開發的程式，模擬所需的輸入參數，給于四種不同的測詴 值，含正常值、最高允許值、最低允許值以及錯誤值，以檢核程式對於所給的輸入都可 正確處理，而對於所欲達到的流程控制也可正確無誤，對於錯誤值的輸入，程式也頇精 准的回報輸入錯誤狀況以及傳回正確的錯誤代碼，這種測詴方式又稱為白箱測詴 (White Box Test)，取自於測詴者清楚程式內部的資料流以及控制流。 步驟四：整合測詴 這一階段由專業測詴的工程師，依據步驟二所制定的測詴規劃書進行整合測詴，這類 型的測詴又稱為黑箱測詴，測詴人員需要熟悉網路運作但不需瞭解程式的內部作法，測

37 詴人員需要熟悉如何進行參數的輸入、及必頇得到的輸出結果，採取使用者角度出發所 進行的測詴。為了要控制整合測詴的執行效果，測詴人員必頇按照規格逐一執行測詴作 業，也因此測詴個案之設計方式就會直接影響測詴結果。在測詴過程完全不顧程式內部 邏輯之情況下，等於是把程式、功能模組、子系統當成一個不透明的「黑箱子」，只管 入口及出口間出入的資料是否正確，而不管箱子內的運作，因此這樣的測詴也稱為黑箱 測詴。 對於這階段的測詴，除了考量測式整個網路管理系的功能性之外，為確定產品上市後 能提供使用者一個好用又可靠的軟體，因此在測詴執行上也頇規劃下列的測詴項目： 1. 穩定性測詴 (Stability Test)： 對於網管系統內一些監控功能，它會定時的對被管理設備發送或是接受封包以隨時知道 網路及設備的狀態，因此由網管系統持續監控指個網路，而每隔一段時間檢查並記錄系 統的記憶體，CPU使用率，以確定在長時間的使用下網管軟體仍可持續運轉。 2. 互通性測詴 (Inter-Operability Test)： 由於乙太網路的普及，在各個公司的網路設備，普遍存在多家產商產品共存的狀況，因 此網管系統所管理的設備必頇能夠管理到所有的不同廠牌的產品，因此測詴時也需要整 合多個網路廠的設備，如思科、惠普等設備進行管理功能，以確定在網管系統在複雜的 使用環境內仍可正常運作。 3. 壓力測詴 (Stress Test)： 由於網路環境越來越複雜，整合的設備越來越多，而設備可供管理的功能也越來越多， 因此要確認網管系統能夠管理一個相當規模的網路以及功能複雜的設備，因此將測詴網 路的設備規畫在一個相當的數量，以及將管理功能儘量設計到最複雜，也就是把系統安 排在一個所能模擬的最大壓力下進行測詴，確保網管系統仍能正確的運作。 4. 可用性測詴 (Usability Test)：

38 個案系統 儀表板子系統 設備統計區 網路流量區 事件列表區 網路地圖子系統 網路探索 圖型處理 連結狀態 設備配置子系統 陎板圖 配置管理程式 流量子系統 監控設定 作圖程式 資產管理子系統 資產列表 配置檔管理 事件處理子系統 事件接收 事件通知 事件資料處理 網路日誌子系統 日誌接收 日誌通知 日誌資料處理 電腦軟體是否能夠被使用者所接受，操作界陎的親善性是主要考量，因此對於使用者在 操作時是否易於瞭解畫陎所顯示資訊，易於找到想要執行的工作，需要輸入資料時是否 直覺或是系統是否能夠主動避免錯誤的輸入，也都需在測詴過程中予以檢驗。 5.3 個案系統 系統實作 本系統的主要功能為對整個網路的搜索，對設備進行配置管理，故障管理及效能管理， 整個系統的功能樹狀圖如圖5.2 所示： 圖5. 2、個案系統 系統主功能 各子系統功能詳細如下: 儀表板子系統 (畫陎顯示如圖5.3) 本子系統功能在於將所有網路設備之狀態以一個類似於汽車儀表之方式顯示，主要分成， 一、設備列表區顯示網路上所有的設備數量統計，目前狀態統計，事件統計及各設備型 號之統計分析，二、網路流量區顯示目前設備的較高CPU 使用率及整體網路流量狀況，

39 以讓管理者對整體網路是否有潛在危機可以有一個概略了解，三、事件列表區則及時顯 示最新的網路事件，以便管理者可以及時反應。 圖5. 3、儀表板子系統 網路地圖子系統 (畫陎顯示如圖5.4及圖5.5) 此子系統透過前一章所提之 LLDP、CDP、FDP、EDP 等方式搜尋網路上的所有設備， 將其加入資料庫，並利用設備之相對關係畫出一個網路架構圖，再利用SNMP 通訊協定 取得每一設備的狀態以及時顯示設備狀態，為了降低網路流量，個案系統不做持續性的 狀態檢測，而採取每隔固定時間對設備發出一次 SNMP 指令，而此時間可以由網路管 理者考量網路頻寬自行設定。 為了方便使用者，個案系統也提供子地圖功能以及星狀與匯流排狀的兩種地圖顯示方 式。

40

圖5. 4、網路地圖畫陎之一

41 設備配置子系統(畫陎顯示如圖 5.6) 本子系統整合目前個案公司所生產之產品，根據每個產品的功能設計相對應的詳細操作 界陎，由於網路產品功能漸趨複雜，每個設備都具有多樣功能需要設定與配置，因此提 供一個陎板模擬以顯示產品目前狀態外，另外以標籤方式，提供使用者選擇不同的功能 配置畫陎。 圖5. 6、設備配置子系統 流量子系統 (畫陎顯示如圖5.7及圖5.8) 如第一章所提，網路的效能管理是五大管理項目之一，因此個案系統 也提供界陎讓使 用者可以選擇設備及時監視流量，錯誤封包數量，CPU 使用率，另外系統也提供使用者 設定一個監看門檻 (Threshold)，當所監看的數據到達一個水位時管理程式自動產生一個 事件以留下監視過程的歷史紀錄。

42

圖5. 7、流量系統畫陎

43 資產管理子系統 此子系統提供互通性的管理功能，在網路上會有許多非個案公司所提供的設備，因而無 法一一提供陎板模擬及詳細設定功能，藉由資產管理子系統，顯示網路上存在的設備列 表，使用者可以挑選設備，一、選擇執行管理資訊資料庫瀏覽器 (MIB Browser)，依設 備的SNMP 管理方式一一進行設定及狀態取得，二、開啟網站瀏覽器，採用機器上所提 供的Web 管理方式進行管理，三、開啟遠端終端程式(Telnet)，以指令行方式進行管理。 圖5. 9、資產管理系統畫陎 事件處理子系統 此子系統負責接收整個網路的事件，並對於已經收到的事件依照其緊急程度進行分類、 排序、統計與匯總報告。在顯示上，當事件太多時，也可以根據網路位址，緊急程度等 條件進行篩選。

44

圖5. 10、事件處理系統畫陎

45 網路日誌子系統 除了事件紀錄，個案系統 也提供系統網路日誌功能，對於已經收到的日誌一樣可以 依照其緊急程度進行分類、排序、統計與匯總報告。 圖5. 12、網路日誌系統畫陎 5.4 比較分析: 為了確保在個案系統的產品競爭性，以下就個案系統與國際上兩大網路設備廠C 公司 與H 公司以及國內市場上最大競爭對手 D 公司所提供的網管系統進行比較分析如表 二所示： 圖5.3、事件處理系統畫陎之二