Xây dựng công cụ quản lý ứng dụng chia sẻ thông tin về dữ liệu địa lý

Tuy nhiên cũng như rất nhiều ứng dụng khác, việc quản lý và giám sát không được quan tâm trong quá trình phân tích và thiết kế ứng dụng Sea Portal, nó chỉ nảy sinh khi ứng dụng bước vào

CÔNG TRÌNH ĐƯỢC HOÀN THÀNH TẠI TRƯỜNG ĐẠI HỌC BÁCH KHOA ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC BÁCH KHOA

PHAN QUANG THIỆN

XÂY DỰNG CÔNG CỤ QUẢN LÝ ỨNG DỤNG CHIA SẺ THÔNG TIN VỀ DỮ LIỆU ĐỊA LÝ

Chuyên ngành:KHOA HỌC MÁY TÍNH

LUẬN VĂN THẠC SĨ

TP HỒ CHÍ MINH – 07/2010

ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH

Cán bộ hướng dẫn khoa học : TS Thoại Nam

Cán bộ chấm nhận xét 1: TS Nguyễn Đức Cường

Cán bộ chấm nhận xét 2 : TS Trần Viết Huân

Luận văn thạc sĩ được bảo vệ tại Trường Đại học Bách Khoa, ĐHQG Tp HCM ngày

25 tháng 08 năm 2010

Thành phần Hội đồng đánh giá luận văn thạc sĩ gồm:

1 TS Lê Ngọc Minh - Chủ tịch hội đồng

2 TS Nguyễn Đức Cường - Giáo viên phản biện 1

3 TS Trần Viết Huân - Giáo viên phản biện 2

4 TS Thoại Nam - Ủy viên

PHÒNG ĐÀO TẠO SĐH Độc lập – Tự do – Hạnh phúc

Tp HCM, ngày25 tháng 08 năm 2010

NHIỆM VỤ LUẬN VĂN THẠC SĨ

Họ tên học viên: PHAN QUANG THIỆN Phái: Nam

Ngày, tháng, năm sinh: 27/07/1984 Nơi sinh: Lâm Đồng

Chuyên ngành: Khoa Học Máy Tính MSHV: 00708209

I-TÊN ĐỀ TÀI: Xây dựng công cụ quản lý ứng dụng chia sẻ thông tin dữ liệu địa lý II-NHIỆM VỤ VÀ NỘI DUNG:

- Đề ra một giải pháp để quản lý ứng dụng chia sẻ thông tin dữ liệu địa lý

- Phân tích, thiết kế một công cụ quản lý ứng dụng chia sẻ thông tin dữ liệu địa

lý dựa trên giải pháp đề ra

- Từ bảng phân tích, thiết kế thực hiện một công cụ để quản lý ứng dụng này

III-NGÀY GIAO NHIỆM VỤ: 01/02/2010

IV-NGÀY HOÀN THÀNH NHIỆM VỤ: 02/07/2010

V-CÁN BỘ HƯỚNG DẪN: TS Thoại Nam

Nội dung và đề cương luận văn thạc sĩ đã được Hội Đồng Chuyên Ngành thông qua

QL CHUYÊN NGÀNH

TS Thoại Nam

Tôi xin gửi lời cám ơn chân thành đến thầy Thoại Nam Thầy đã cho tôi những lời khuyên và rất tận tình hướng dẫn tôi trong suốt quá trình thực hiện luận văn này Tôi cũng xin cám ơn những thầy cô của khoa Khoa Học Máy Tính trường Đại học Bách Khoa TPHCM đã cho tôi kiến thức trong những năm đại học cũng như những năm cao học, những kiến thức này là nền tảng để tôi có thể hoàn thành luận văn này

Tôi cũng xin chân thành cám ơn bạn bè đã giúp đỡ, động viên tôi trong suốt quá trình thực hiện luận văn

Và cuối cùng, tôi muốn dành những kết quả đạt được như là món quà gửi đến Cha Mẹ và gia đình Những người đã nuôi dạy tôi, luôn là chỗ dựa về mặt vật chất cũng như về mặt tinh thần để tôi có thể đạt được những kết quả của ngày hôm nay

Sea Portal là phân hệ quản lý và trao đổi thông tin metadata, được xây dựng nhằm quản lý dữ liệu không gian trong lĩnh vực GIS Do nhu cầu phát triển lâu dài, ứng dụng cần có một công cụ quản lý, giám sát để đánh giá được chất lượng của ứng dụng, cũng như xác định được nhu cầu của người dùng Hiện tại việc quản lý ứng dụng thường được xây dựng dành riêng và tích hợp vào trong ứng dụng Tuy nhiên giải pháp này có những hạn chế là khó xây dựng được đầy đủ các chức năng của một

hệ thống như ứng dụng, cơ sở dữ liệu, máy chủ ứng dụng v.v được quản lý rời rạc Trong luận văn này, tôi xin trình bày một giải pháp quản lý ứng dụng Sea Portal dựa trên các phần mềm và công nghệ quản lý mã nguồn mở nhằm hạn chế phần nào những nhược điểm trong cách quản lý các ứng dụng hiện nay

Nội dung luận văn gồm có 3 phần chính

• Trình bày một giải pháp quản lý ứng dụng theo kiến trúc quản lý agent” sử dụng phần mềm quản lý mã nguồn mở Hyperic HQ và công nghệ JMX để hiện thực kiến trúc này

“manager-• Trình bày việc áp dụng giải pháp quản lý này vào việc quản lý và giám sát ứng dụng Sea Portal

• Trình bày cách hiện thực việc quản lý theo giải pháp đưa ra cho từng chức năng của ứng dụng Sea Portal

Mục lục

Chương 1 Đặt vấn đề 8

1.1 Giới thiệu 8

1.2 Mục tiêu của luận văn 9

1.3 Đối tượng và phạm vi nghiên cứu của luận văn 9

1.4 Kết quả của luận văn 10

1.5 Tổ chức của luận văn 10

Chương 2 Tổng quan về quản lý hệ thống và ứng dụng 11

2.1 Quản lý hệ thống là gì 11

2.2 Kiến trúc quản lý 11

2.2.1 Tài nguyên quản lý (managed resource) 12

2.2.2 Tác nhân (agent) 13

2.2.3 Tác nhân phụ (subagent) 13

2.2.4 Tầng quản lý mức ở giữa (midlevel manager) 13

2.2.5 Hệ thống quản lý 14

2.3 Vai trò, giá trị của giám sát ứng dụng 14

2.3.1 Phát hiện và ngăn ngừa lỗi xảy ra 15

2.3.2 Quản lý hiệu quả tài nguyên 15

2.3.3 Đánh giá chất lượng, hiệu quả của ứng dụng 15

2.3.4 Giám sát khuynh hướng phát triển của ứng dụng 16

2.4 Phân loại 16

2.4.1 Quản lý hạ tầng 16

2.4.2 Quản lý ứng dụng 17

2.5 Những thách thức trong giám sát ứng dụng 18

2.5.1 Xác định ngưỡng cần giám sát 18

2.5.2 Độ phức tạp của ứng dụng 19

2.5.3 Ứng dụng triển khai trên môi trường chia sẻ tài nguyên 19

2.5.4 Ứng dụng triển khai trên hệ thống cluster 19

2.6 Các công nghệ quản lý 19

2.6.1 SNMP(Simple Network Management Protocol) 19

2.6.2 CMIP(Common Management Information Protocol) 20

2.6.3 CIM/WBEM 20

2.6.4 JMX(Java Management Extension) 20

2.7 Các công trình nghiên cứu về quản lý, giám sát ứng dụng 21

Chương 3 Phần mềm quản lý hạ tầng Hyperic HQ 25

3.1 Giới thiệu 25

3.2 Kiến trúc quản lý của Hyperic HQ 26

3.3 Mô hình quản lý tài nguyên 27

3.4 Các chức năng chính của Hyperic HQ 28

3.5 Khả năng mở rộng 32

3.6 Công nghệ JMX 33

3.6.1 MBean chuẩn (standard mbean) 34

3.6.2 Mô hình thông báo JMX 36

3.6.3 MBean Server 37

3.6.4 Bộ kết nối (connector) và bộ tương thích giao thức (protocol adaptor) 38

3.7 Xây dựng plugin tài nguyên tương thích JMX 39

Chương 4 Giám sát ứng dụng Sea Portal 42

4.1 Giới thiệu ứng dụng Sea Portal 42

4.1.1 Metadata 42

4.1.2 Các chức năng chính của ứng dụng Sea Portal 44

4.2 Giải pháp giám sát ứng dụng Sea Portal 47

4.3 Xây dựng công cụ quản lý ứng dụng Sea Portal 49

4.3.1 Quản lý bộ nhớ của ứng dụng Sea Portal 49

4.3.2 Quản lý cơ sở dữ liệu của ứng dụng 54

4.3.3 Quản lý chức năng tìm kiếm metadata 57

4.3.4 Quản lý chức năng hiệu chỉnh metadata 60

4.3.5 Quản lý chức năng thu thập metadata 64

4.3.6 Quản lý chức năng cho phép thu thập metadata 68

Chương 5 Đánh giá công cụ quản lý 73

5.1 Tài nguyên tiêu thụ bởi công cụ quản lý 73

5.2 Ảnh hưởng của việc giám sát đến hiệu suất ứng dụng Sea Portal 75

5.3 Ảnh hưởng của công cụ quản lý đến hành vi của ứng dụng 76

5.4 Khả năng tích hợp của công cụ giám sát và ứng dụng Sea Portal 77

5.5 Khả năng mở rộng của công cụ giám sát 78

5.5.1 Mở rộng thay đổi giao diện của công cụ giám sát 78

5.5.2 Mở rộng các thuộc tính và các hoạt động điều khiển của mỗi chức năng 79

5.5.3 Mở rộng khả năng giám sát các chức năng của ứng dụng Sea Portal 80

5.6 Phạm vi triển khai, áp dụng của công cụ 80

Chương 6 Tổng kết và hướng mở rộng luận văn 81

6.1 Tổng kết 81

6.2 Hướng mở rộng của luận văn 82

6.2.1 Tìm hiểu cách mở rộng giao diện Hyperic HQ 82

6.2.2 Tìm hiểu giải pháp tách rời mã nguồn xử lý logic quản lý và mã nguồn ứng dụng 82

Tài liệu tham khảo 84

Phụ lục 1: Hướng dẫn cài đặt demo để quản lý ứng dụng Sea Portal 86

Danh mục hình

Hình 2.1.Kiến trúc quản lý manager-agent 12

Hình 2.2.Mô hình giám sát hệ thống Linux/Unix của Nagios 21

Hình 3.1.Kiến trúc quản lý của Hyperic HQ 26

Hình 3.2.Giao diện giám sát thuộc tính 28

Hình 3.3.Giám sát thuộc tính dạng biểu đồ 29

Hình 3.4.Giao diện hiển thị thông báo và sự kiện của tài nguyên 30

Hình 3.5.Cấu hình quản lý tài nguyên 30

Hình 3.6.Giao diện định nghĩa cảnh báo 31

Hình 3.7.Giao diện điều khiên tài nguyên 32

Hình 3.8.Kiến trúc JMX 34

Hình 3.9.Giao diện quản lý MyClassMBean 35

Hình 3.10.MBean chuẩn MyClass 36

Hình 3.11.MBean Server 37

Hình 3.12.Bộ kết nối 38

Hình 3.13.Bộ tương thích giao thức 38

Hình 3.14.Plugin JMX cho tài nguyên dịch vụ 40

Hình 4.1.Metadata 43

Hình 4.2.Chức năng tìm kiếm metadata của ứng dụng Sea Portal 44

Hình 4.3 .Mạng lưới trao đổi thông tin metadata 45

Hình 4.4.Danh sách các ứng dụng có thể thu thập metadata 46

Hình 4.5 Quản lý metadata 46

Hình 4.6.Quản trị người dùng của ứng dụng Sea Portal 47

Hình 4.7.Mô hình quản lý ứng dụng Sea Portal 48

Hình 4.8.Các thế hệ của vùng nhớ 51

Hình 4.9.Vùng nhớ thế hệ trẻ 51

Hình 4.10.Plugin quản lý bộ nhớ 53

Hình 4.11.Giao diện giám sát thuộc tính của bộ nhớ 54

Hình 4.12.Cấu hình cơ sở dữ liệu cần quản lý 56

Hình 4.13.Giám sát thuộc tính của một bảng trong cơ sở dữ liệu Sea Portal 56

Hình 4.14.Các hoạt động điều khiển cơ sở dữ liệu Sea Portal 57

Hình 4.15.Giao diện quản lý chức năng tìm kiếm metadata 58

Hình 4.16.Plugin hỗ trợ quản lý chức năng tìm kiếm metadata 59

Hình 4.17.Giao diện giám sát thuộc tính chức năng tìm kiếm metadata 60

Hình 4.18.Giao diện quản lý chức năng hiệu chỉnh metadata 61

Hình 4.19.Plugin hỗ trợ giám sát chức năng hiệu chỉnh metadata 62

Hình 4.20.Giám sát thuộc tính của chức năng hiệu chỉnh metadata 63

Hình 4.21.Các hoạt động điều khiển chức năng hiệu chỉnh metadata 63

Hình 4.22.Thông báo metadata bị hiệu chỉnh 64

Hình 4.23.Giao diện quản lý chức năng thu thập metadata 65

Hình 4.24.Plugin hỗ trợ quản lý chức năng thu thập metadata 67

Hình 4.25.Giám sát thuộc tính chức năng thu thập metadata 68

Hình 4.26.Giao diện quản lý chức năng cho phép thu thập metadata 69

Hình 4.27.Plugin hỗ trợ quản lý chức năng cho phép thu thập metadata 71

Hình 4.28.Giám sát thuộc tính chức năng cho phép thu thập metadata 72

Hình 4.29.Giao diện điều khiển hoạt động chức năng cho phép thu thập metadata 72

Hình 5.1.Giám sát các thuộc tính của HQ Agent 74

Hình 5.2.JConsole 79

Danh mục bảng

Bảng 3.1.Các thẻ thường sử dụng trong plugin JMX 39

Bảng 5.1.Thời gian tìm kiếm khi chưa tích với logic quản lý 75

Bảng 5.2.Thời gian tìm kiếm khi đã tích hợp logic quản lý 75

Bảng 5.4.Bảng mô tả số dòng lệnh thêm vào mã nguồn của mỗi chức năng 78

Danh mục từ viết tắt

HTTP : Hypertext Transfer Protocol

SNMP : Simple Network Management Protocol

XML : eXtensible Markup Language

SSL : Secure Sockets Layer

JMX : Java Management Extension

J2EE : Java 2 Platform Enterprise Edition

UUID : Universal Unique Identifier

RMI : Remote Method Invocation

Chương 1 Đặt vấn đề

1.1 Giới thiệu

Phân hệ trao đổi chia sẻ thông tin về dữ liệu không gian là ứng dụng được xây dựng nhằm quản lý dữ liệu không gian trong lĩnh vực GIS (Geographic information system), phân hệ này có tên là Sea Portal Chúng ta có thể tham khảo một trong những triển khai của ứng dụng tại địa chỉ [12] Hiện nay ứng dụng mới được triển khai trong giai đoạn thử nghiệm trên một số tỉnh thành tại Việt Nam Mục tiêu lâu dài của ứng dụng là triển khai trên tất cả tỉnh thành trong cả nước, như vậy ứng dụng sẽ còn một chặng đường dài để phát triển Trong giai đoạn thử nghiệm này, một trong những mong muốn của những người xây dựng ứng dụng là phát hiện các lỗi có thể xảy ra với ứng dụng, đánh giá được chất lượng của ứng dụng, đồng thời xác định được nhu cầu của người dùng Những thông tin này sẽ là cơ sở để những người quản lý nâng cấp và hoàn thiện ứng dụng trước khi được triển khai cho các tỉnh thành khác trong cả nước Những mong muốn đó làm nảy sinh nhu cầu cần phải có một công cụ quản lý, giám sát ứng dụng Sea Portal

Tuy nhiên cũng như rất nhiều ứng dụng khác, việc quản lý và giám sát không được quan tâm trong quá trình phân tích và thiết kế ứng dụng Sea Portal, nó chỉ nảy sinh khi ứng dụng bước vào giai đoạn triển khai bởi vì trong giai đoạn này người quản lý ứng dụng thường muốn thay đổi cấu hình thực thi, xem xét một số thuộc tính của ứng dụng, theo dõi hiệu suất của các chức năng, xác định nguyên nhân gây ra lỗi v.v Do đó việc quản lý và giám sát ứng dụng sẽ trở nên khó khăn hơn bởi vì những vấn đề liên quan đến việc tích hợp giữa công cụ giám sát và ứng dụng, sử ảnh hưởng về hiệu suất của công cụ giám sát lên ứng dụng và thậm chí công cụ quản lý có thể gây nên những thay đổi về hành vi của ứng dụng

Việc quản lý và giám sát hệ thống, ứng dụng đã được nghiên cứu rất nhiều Do đó hiện tại có rất nhiều công nghệ và công cụ hỗ trợ việc này Ví dụ SNMP là một công nghệ quản lý rất phổ biến hiện nay, hầu như tất cả các thiết bị TCP/IP đều hỗ trợ công nghệ này hoặc Nagios là một công cụ quản lý và giám sát hạ tầng được sử dụng rộng rãi hiện nay Tuy nhiên những công cụ này chủ yếu quản lý hạ tầng của hệ thống như bộ nhớ, CPU, mạng máy tính v.v….hoặc cung cấp một cơ chế để người dùng có thể mở rộng khả năng quản lý theo nhu cầu chứ nó không thể nào quản lý những vấn đề liên quan đến nghiệp vụ của một ứng dụng cụ thể

Một giải pháp rất hay được sử dụng trong các ứng dụng hiện này là xây dựng thêm một module quản lý, module này chỉ có những người sử dụng có tài khoản là người quản trị mới có thể nhìn thấy Tuy nhiên giải pháp này có các hạn chế chính như sau:

 Xây dựng module quản lý với các chức năng như cảnh báo, điều khiển, báo cáo, giám sát từ xa… đòi hỏi rất nhiều thời gian và công sức mà hiệu suất cũng như những ảnh hưởng của module này đến ứng dụng chưa đánh giá được

 Khó nâng cấp, mở rộng khả năng quản lý của công cụ

 Một hệ thống không đơn thuần chỉ có ứng dụng chúng ta xây dựng mà còn có máy chủ ứng dụng (application server), máy chủ web (web sever) và cơ sở dữ liệu (database server) Đối với máy chủ ứng dụng, máy chủ web hoặc cơ sở dữ liệu người ta lại thường sử dụng các công cụ quản lý đi kèm với chúng Điều này dẫn đến hạn chế là cùng một hệ thống mà người quản trị phải sử dụng nhiều công cụ khác nhau để giám sát các bộ phận của hệ thống

Những khó khăn trên là động lực để tôi nghiên cứu, đề ra giải pháp và hiện thực một công cụ giám sát hiệu quả và phù hợp cho ứng dụng Sea Portal

1.2 Mục tiêu của luận văn

Mục tiêu chính của luận văn là đưa ra giải pháp và hiện thực được một công cụ quản lý

và giám sát ứng dụng Sea Portal Ngoài ra các kết quả có được trong luận văn sẽ giúp cho tác giả có những bước khởi đầu trong lĩnh vực nghiên cứu về quản lý và giám sát ứng dụng Các công việc cụ thể để hoàn thành mục tiêu luận văn như sau:

 Tìm hiểu cơ sở lý thuyết của việc quản lý và giám sát ứng dụng

 Tìm hiểu các công nghệ và công cụ quản lý hiện có

 Tìm hiểu nhu cầu quản lý của ứng dụng Sea Portal

 Đề ra một giải pháp để quản lý ứng dụng Sea Portal

 Dựa trên giải pháp đề ra, hiện thực một công cụ để quản lý ứng dụng Sea Portal

 Đánh giá và xem xét sự ảnh hưởng của công cụ quản lý đến ứng dụng

1.3 Đối tượng và phạm vi nghiên cứu của luận văn

Trong luận văn này tôi chỉ tập trung xây dựng một công cụ để đáp ứng các nhu cầu giám sát cho ứng dụng cụ thể là Sea Portal

Hướng nghiên cứu của luận văn là tìm hiểu các phần mềm quản lý mã nguồn mở hiện

có Đánh giá, chọn một phần mềm phù hợp với ứng dụng Sea Portal Sau đó nghiên cứu cách thay đổi, mở rộng phần mềm quản lý được chọn để nó có thể đáp ứng được các yêu cầu quản lý của ứng dụng Sea Portal

1.4 Kết quả của luận văn

Luận văn đã hoàn thành được các mục tiêu đề ra bao gồm trình bày được một giải pháp

để quản lý ứng dụng Sea Portal, xây dựng được một công cụ giám sát ứng dụng Sea Portal dựa trên phần mềm mã nguồn mở Hyperic HQ, và luận văn cũng đưa ra được nhiều cách đánh giá khác nhau về công cụ

1.5 Tổ chức của luận văn

Phần còn lại của luận văn được tổ chức như sau:

 Chương 2: Trình bày các lý thuyết cơ sở của việc quản lý, giám sát hệ thống và ứng dụng Các công nghệ và các công trình nghiên cứu liên quan đến việc quản

lý và giám sát hệ thống

 Chương 3: Trình bày phần mềm mã nguồn mở Hyperic HQ được dùng để xây dựng công cụ quản lý và giám sát cho ứng dụng Sea Portal Chương này cũng giới thiệu một số khái niệm về công nghệ JMX được sử dụng trong luận văn

 Chương 4: Trình bày ứng dụng Sea Portal, giới thiệu các chức năng của ứng dụng Chương này cũng trình bày các yêu cầu quản lý của ứng dụng Sea Portal, giải pháp và cách hiện thực công cụ để đáp ứng nhu cầu đó

 Chương 5: Đánh giá ưu điểm, khuyết điểm của công cụ, xem xét khả năng tích hợp của công cụ giám sát và ứng dụng Sea Portal, đánh giá các ảnh hưởng khác nhau của công cụ quản lý đến ứng dụng

 Chương 6: Tổng kết lại các công việc đã làm và đề ra hướng phát triển của luận văn

Chương 2 Tổng quan về quản lý hệ thống và ứng dụng

Chương này trình bày các lý thuyết về quản lý và giám sát hệ thống Các cộng nghệ và các hướng nghiên cứu hiện tại trong lĩnh vực này

2.1 Quản lý hệ thống là gì

Hoạt động quản lý hệ thống và ứng dụng nói chung bao gồm 3 hình thức sau đây:

 Giám sát: là khả năng nắm bắt những thông tin liên quan các giá trị thuộc tính, các hoạt động của tài nguyên cần giám sát, những thông tin này được sử dụng để gửi thông báo hoặc báo cáo đến những người liên quan

 Theo dõi: là khả năng quan sát một số khía cạnh của một công việc nào đó, hoặc quan sát một tiến trình đang thực thi mà tiến trình này có liên quan đến nhiều thành phần khác nhau (ví dụ theo dõi những thông điệp trao đổi giữa người gửi và người nhận)

 Điều khiển: là khả năng thay thế ở thời gian thực thi hành vi của thành phần cần giám sát Thay đổi cầu hình hoặc thay đổi giá trị các tham số mặc định là những ví

dụ của việc quản lý điều khiển

2.2 Kiến trúc quản lý

Kiến trúc quản lý gồm có 4 thành phần chính như sau:

 Mô hình tổ chức: định nghĩa thực thể và các vai trò khác nhau trong kiến trúc quản

lý Hầu hết tất cả các hệ thống quản lý hiện nay đều sử dụng mô hình agent‟, mô hình này có thể bao gồm 5 vai trò sẽ được trình bày trong phần sau

„manager- Mô hình thông tin: định nghĩa cấu trúc của thông tin quản lý để các thực thể khác

có thể hiểu được giao diện quản lý thể hiện ra bên ngoài, từ giao diện quản lý này các thực thể này sẽ xây dựng chương trình quản lý cho giao diện quản lý đó

 Mô hình giao tiếp: định nghĩa các hoạt động và giao thức cho việc truy xuất mô hình thông tin

 Mô hình chức năng: định nghĩa những dịch vụ quản lý chung Những dịch vụ này

có thể được sử dụng để quản lý bất kỳ tài nguyên nào

Kiến trúc giám sát được sử dụng phổ biến hiện nay bởi hầu hết các hệ thống quản lý là

„manager-agent‟ Kiến trúc quản lý „manager-agent‟ luôn bao gồm 3 vai trò chính là tài nguyên quản lý (managed resource), tác nhân (agent) và hệ thống quản lý (management system) Ngoài ra các vai trò „tác nhân phụ‟ (subagent) và „Tầng quản lý mức giữa‟ (midlevel manager) cũng là những vai trò thường thấy trong kiến trúc quản lý

Hình 2.1.Kiến trúc quản lý manager-agent

2.2.1 Tài nguyên quản lý (managed resource)

Hệ thống máy tính, mạng hoặc các thành phần ứng dụng cần được quản lý được gọi là tài nguyên quản lý Không phải tất cả tài nguyên trong môi trường IT đều cần được quản

lý và một số nhóm tài nguyên thường được quản lý theo đơn vị chức năng hơn là từng cá nhân Ví dụ trong công nghệ Java, tài nguyên quản lý có thể là ứng dụng desktop, ứng dựng client-server, ứng dụng web Nhưng những thành phần chức năng của các ứng dụng này như máy ảo Java, Servlet, Enterprise JavaBeans cũng có thể được quản lý

Tài nguyên quản lý chịu trách nhiệm chuyển những dữ liệu cho phép quản lý thành mô hình thông tin mà hệ thống quản lý hỗ trợ để truy xuất những dữ liệu đó Tài nguyên quản

lý có thể đưa ra những thông tin mô tả về tài nguyên , dữ liệu cấu hình, các chỉ số về hiệu suất và trạng thái của tài nguyên thông qua mô hình thông tin

Tài nguyên quản lý cũng chịu trách nhiệm giao tiếp với hệ thống quản lý thông qua tác nhân sử dụng mô hình thông tin, hoạt động và các giao thức mà tác nhân và hệ thống quản lý hỗ trợ Hoạt động giao tiếp bao gồm gửi trả lời các yêu cầu trả lời hoặc gửi các thông báo về các sự kiện cho hệ thống quản lý Những yêu cầu gửi đi từ tác nhân có thể

là lấy dữ liệu, thay đổi cấu hình hoặc thực thi một hoạt động Tài nguyên quản lý sẽ quyết định loại yêu cầu và mức hỗ trợ khi có yêu cầu được gửi tới

2.2.2 Tác nhân (agent)

Tác nhân quản lý được cung cấp bởi hệ thống quản lý và hỗ trợ mô hình thông tin và

mô hình giao tiếp của hệ thống quản lý Tác nhân quản lý giao tiếp với cả hệ thống quản

lý và tài nguyên quản lý Nó thường được chạy trên cùng môi trường triển khai của tài nguyên cần quản lý Một tác nhân có thể hỗ trợ một hoặc nhiều tài nguyên, những tác nhân gắn liền với tài nguyên thì chỉ có thể hỗ trợ một thực thể của tài nguyên đó

Tác nhân gửi dữ liệu và sự kiện từ tài nguyên đến hệ thống quản lý, đồng thời nó cũng chuyển những yêu cầu truy xuất dữ liệu và các câu lệnh từ hệ thống quản lý đến tài nguyên Tác nhân thường cung cấp một giao diện lập trình thể hiện ra bên ngoài hoặc bao đóng mô hình thông tin để tài nguyên quản lý có thể giao tiếp với nó Một số tác nhân cũng đòi hỏi tài nguyên quản lý phải hiện thực một giao diện lập trình nào đó để tác nhân

có thể gọi và gửi các yêu cầu của hệ thống quản lý

2.2.3 Tác nhân phụ (subagent)

Tác nhân phụ được sử dụng trong kiến trúc quản lý mà một tác nhân có thể hỗ trợ nhiều tài nguyên quản lý Tác nhân phụ kết hợp chặt chẽ với tài nguyên hoặc nó có thể được gắn vào bên trong tài nguyên Tác nhân phụ đăng ký sự hiện diện và sự sẵn sàng của nó với tác nhân, sau khi đã đăng ký nó sẽ làm nhiệm vụ giao tiếp giữa tài nguyên quản lý và tác nhân Tác nhân phụ thông thường cung cấp 2 giao diện lập trình: một là để giao tiếp với tài nguyên và cái còn lại dùng để giao tiếp với tác nhân Tác nhân phụ có thể chuyển đổi dữ liệu của tài nguyên quản lý ở dạng tự nhiên sang mô hình thông tin mong muốn bởi tác nhân và hệ thống quản lý

2.2.4 Tầng quản lý mức ở giữa (midlevel manager)

Kiến trúc quản lý „manager-agent‟ ban đầu có những vấn đề liên quan đến việc một lượng lớn tài nguyên quản lý có thể gửi dữ liệu hoặc báo cáo đến một hệ thống quản lý đơn Việc nhiều tài nguyên gửi dữ liệu đến cùng một lúc sẽ làm cho hệ thống quản lý bị quá tải Tầng quản lý ở giữa được giới thiệu vào trong kiến trúc, đóng vai trò làm giảm lượng dữ liệu, cũng như các sự kiện gửi đến hệ thống quản lý

Tầng quản lý ở giữa giao tiếp với một tập các tác nhân và hệ thống quản lý Tầng quản

lý ở giữa chịu trách nhiệm tổng hợp và lọc các thông tin từ tài nguyên quản lý, sau đó chuyển những thông tin ngắn gọn, hữu ích cho hệ thống quản lý Nó cũng thực hiện việc thăm dò các tài nguyên quản lý để kiểm tra tính sẵn sàng và chuyển những thông tin này

về cho ứng dụng quản lý Tầng quản lý ở giữa giúp tăng chất lượng thông tin, đồng thời giảm tỉ lệ và số lượng các thông điệp mà hệ thống quản lý phải xử lý

Trong kiến trúc miền sử dụng, tầng quản lý ở giữa cho phép các tài nguyên có thể được quản lý như là một nhóm luận lý dựa trên đặc điểm vật lý như vị trí, loại hoặc đặc điểm nghiệp vụ như phòng ban hoặc ứng dụng nghiệp vụ Kiến trúc quản lý sử dụng tầng quản

lý ở giữa còn được gọi là kiến trúc quản lý phân cấp

Hệ thống quản lý chịu trách nhiệm cung cấp hạ tầng và giao diện người dùng để quản

lý tài nguyên Hệ thống quản lý thông thường nhận sự kiện từ tác nhân, hiển thị lên giao diện người dùng và tự động thực hiện một hành động nào đó tương ứng với sự kiện Hệ thống quản lý yêu cầu dữ liệu từ tác nhân ( yêu cầu này sẽ được tác nhân gửi cho tài nguyên) để thăm dò, giám sát, xác định khuynh hướng hoặc xác định nguyên nhân lỗi Các hệ thống quản lý cao cấp còn có thể sử dụng những công nghệ quản lý phổ biến như SNMP để tự động khám phá ra tài nguyên nhằm giảm bớt những yêu cầu cấu hình cho hệ thống quản lý

Hệ thống quản lý nói chung thường cho phép các dịch vụ quản lý của nó thay đổi theo nhu cầu Ví dụ người dùng có thể thay đổi câu lệnh, các số liệu thống kê, ngưỡng giá trị được sử dụng để chỉ ra vấn đề, các hành động được thực hiện tự động v.v

2.3 Vai trò, giá trị của giám sát ứng dụng

Giám sát ứng dụng tuy chưa được chú ý nhiều trong quá trình xây dựng dự án, nhưng một công cụ giám sát ứng dụng hiệu quả sẽ đóng góp rất nhiều cho sự thành công của dự

án trong giai đoạn triển khai, bảo trì ứng dụng

Việc xây dựng chương trình giám sát ứng dụng tuy phải tốn thêm chi phí ở giai đoạn thiết kế và thực thi, nhưng nếu xét tổng quan thì nhưng giá trị mà một công cụ giám sát ứng dụng nếu xây dựng thành công mang lại sẽ lớn hơn rất nhiều so với chi phí xây dựng

nó

2.3.1 Phát hiện và ngăn ngừa lỗi xảy ra

Mặc dù các ứng dụng đã được kiểm tra kỹ trước khi người dùng sử dụng, nhưng quá trình kiểm tra này chỉ được thực hiện trên dữ liệu mẫu hoặc trong điều kiện tài nguyên thuận lợi, do đó lỗi xảy ra khi người dùng sử dụng ứng dụng là điều hoàn toàn có thể xảy

ra Nếu như một ứng dụng web đơn giản thì có thể chỉ gây bất tiện cho người sử dụng, nhưng nếu đó là một ứng dụng ngân hàng hoặc một ứng dụng giao dịch trực tuyến thì vấn đề sẽ trở nên phức tạp hơn bởi vì nếu có lỗi xảy ra, thì không những ảnh hưởng đến việc sử dụng ứng dụng của người dùng mà còn có thể ảnh hưởng đến những lợi ích kinh

tế Do đó việc giám sát phát hiện và ngăn ngừa lỗi xảy ra có vai trò hết sức quan trọng trong những ứng dụng này

2.3.2 Quản lý hiệu quả tài nguyên

Mỗi ứng dụng khi thực thi sẽ được cấp tài nguyên từ hệ thống, làm sao để việc cấp tài nguyên được hiệu quả, nếu cấp quá ít thì hiệu suất của ứng dụng sẽ giảm hoặc có thể gây

ra lỗi, nếu cấp quá nhiều thì sẽ gây lãng phí, hơn nữa việc sử dụng tài nguyên của ứng dụng cũng khác nhau phụ thuộc rất nhiều yếu tố như số lượng người dùng, thời gian vấn đề sẽ này sẽ rõ ràng hơn khi ứng dụng được triển khai trên cơ sở hạ tầng của một dịch vụ theo mô hình Cloud, trong mô hình này thì tài nguyên cũng cấp cho ứng dụng là

vô hạn nhưng ứng dụng phải trả phí cho tài nguyên mình sử dụng, một công cụ giám sát hiệu quả sẽ giúp cho ứng dụng đánh giá được chính xác nhu cầu tài nguyên của ứng dụng, đảm bảo được hoạt động của ứng dụng nhưng vẫn tiết kiệm được chi phí

2.3.3 Đánh giá chất lượng, hiệu quả của ứng dụng

Chất lượng của những chức năng của ứng dụng phụ thuộc vào nhiều yếu tố và chỉ có thể đánh giá được trong quá trình thực thi ứng dụng Tìm kiếm là chức năng phổ biến trong các ứng dụng, một trong những mong muốn của người dùng với chức năng này là tốc độ tìm kiếm, tốc độ này phụ thuộc vào rất nhiều yếu tố như số lượng yêu cầu của người dùng, tài nguyên của hệ thống do đó thời gian đáp ứng của chức năng sẽ khác nhau tùy thời điểm, việc giám sát ứng dụng sẽ giúp phát hiện và cảnh báo khi thời gian tìm kiếm vượt quá một ngưỡng quy định, việc cảnh báo sẽ giúp cho những bộ phận liên quan có những hành động kịp thời nhằm đảm báo chất lượng của ứng dụng

Mỗi ứng dụng sẽ cung cấp nhiều chức năng cho người dùng Nhưng chức năng nào được sử dụng nhiều, chức năng nào ít đươc sử dụng Những câu hỏi này không thể được trả lời chính xác khi phát triển ứng dụng, mà chỉ có những công cụ giám sát việc sử dụng các chức năng ứng dụng của người dùng khi ứng dụng thực thi mới có thể trả lời được những câu hỏi này Dựa trên những thông tin này người quản lý ứng dụng sẽ có những hành động thích hợp để ứng dụng được phát triển tốt hơn

2.3.4 Giám sát khuynh hướng phát triển của ứng dụng

Một trong những vai trò quan trong của việc giám sát ứng dụng là khả năng quản lý khuynh hướng phát triển theo thời gian của ứng dụng Một ứng dụng sẽ trải qua những chu kỳ phát triển, những phiên bản khác nhau, mỗi phiên bản sau sẽ có những chức năng mới hoặc sửa chữa nâng cấp chức năng cũ.Việc giám sát ứng dụng là một cách để đánh giá liệu sự thay đổi có phù hợp, có ảnh hưởng đến hiệu suất của ứng dụng hay không và quan trọng hơn là nó ảnh hưởng như thế nào đến ứng dụng Ví dụ nếu việc sửa chữa chức năng cũ làm cho thời gian đáp ứng của hệ thống giảm thì người quản lý hệ thống có thể đặt câu hỏi liệu việc sửa chữa đã được hiện thực hợp lý hay chưa

2.4 Phân loại

Việc quản lý hệ thống, ứng dụng có thể được phân loại theo nhiều cách khác nhau như dựa trên loại hệ thống, ứng dụng cần quản lý, dựa trên cách thức quản lý v.v Trong phần này chúng ta sẽ xem một cách phân loại việc quản lý hệ thống nói chung bao gồm hai hình thức sau đây:

Các tài nguyên thường được giám sát trong giám sát hạ tầng ứng dụng là:

2.4.2 Quản lý ứng dụng

Một người quản lý cấp cao có thể không quan tâm đến vấn đề, ứng dụng sử dụng CPU thế nào, sử dụng bao nhiêu bộ nhớ, mà họ quan tâm đến chức năng nào của ứng dụng được sử dụng nhiều, chức năng nào ít sử dụng đây là một trong những nhiệm vụ của giám sát ứng dụng

Giám sát ứng dụng quan tâm đến việc theo dõi các chức năng của ứng dụng, hiệu suất của những ứng dụng Việc giám sát ứng dụng là khác nhau tùy thuộc vào loại ứng dụng, cũng như nhu cầu của người quản lý

Việc giám sát ứng dụng sẽ dựa trên việc giám sát hạ tầng Những kết quả của việc giám sát hạ tầng sẽ được tổng hợp để có được thông tin ở mức trừu tượng cao hơn Chúng ta sẽ trình bày một số vần đề thường được quan tâm trong quản lý, giám sát ứng dụng trong phần tiếp theo sau đây

2.4.2.1 Giám sát sức khỏe ứng dụng

Sức khỏe ứng dụng phải được giám sát đều đặn để phát hiện ra những vấn đề của ứng dụng trước khi nó trở nên trầm trọng, trong những ứng dụng ngân hàng hoặc giao dịch trực tuyến thì những vấn đề xảy ra với ứng dụng không những ảnh hưởng đến việc sử dụng ứng dụng mà còn có những ảnh hưởng về kinh tế do đó nhiệm vụ giám sát và cảnh báo trước khi khi có những vấn đề xảy ra với ứng dụng là nhiệm vụ hết sức quan trọng Cách đơn giản nhất của loại giám sát này, là lấy các giá trị tham số của hệ thống, ứng dụng ở một thời điểm, so sánh với các giá trị chuẩn Giám sát tư động các tham số là cách tốt nhất để đảm bảo tính sẵn sàng cao của một môi trường ứng dụng

2.4.2.2 Giám sát lỗi

Lỗi trong bất kỳ ứng dụng nào cũng sẽ ảnh hưởng rất lớn đến việc sử dụng ứng dụng của người dùng Lỗi xảy ra có thể là vì vấn đề phần mềm liên quan tới code của ứng dụng, máy chủ web, máy chủ ứng dụng, máy chủ database hoặc có thể là những vấn đề phần cứng liên quan đến bộ nhớ, bộ xử lý, dung lượng đĩa cứng, hoặc là những vấn đề về mạng

Những loại lỗi này được giám sát khác nhau, lỗi ứng dụng hầu như được giám sát bằng cách phân tích ứng dụng, phân tích máy chủ web, hoăc log của máy chủ ứng dụng, hiểu được thông báo lỗi và sử dụng thông báo lỗi đó để tìm ra bản chất của vấn đề

2.4.2.3 Giám sát hiệu suất

Hiệu suất của ứng dụng đánh giá dựa trên thời gian đáp ứng của ứng dụng đối với những yêu cầu của người dùng và số lượng yêu cầu mà ứng dụng có thể xử lý được Một ứng dụng đáp ứng yêu cầu của người dùng ngay tức thì sẽ làm cho người dùng thích thú,

đánh giá cao hơn ứng dụng đáp ứng yêu cầu người dùng trong vài giây hoặc vài phút Do

đó việc giám sát hiệu suất sẽ để đảm bảo rằng ứng dụng luôn đáp ứng yêu cầu của người dùng nhanh nhất có thể

Hiệu suất của ứng dụng phụ thuộc vào code của ứng dụng, sự hỗ trợ của phần cứng Giám sát ứng dụng có thể tiếp cận dựa vào log của ứng dụng, log ứng dụng cung cấp

dữ liệu về thời gian xử lý thực sự mà người dùng trải qua, hoặc có thể tiếp cận bằng cách giả lập yêu cầu người dùng bằng cách gửi yêu cầu đến ứng dụng từ những vị trí khác nhau và đo thời gian đáp ứng của ứng dụng trong thực tế

2.4.2.4 Giám sát cấu hình

Sự thay đổi của mỗi phiên bản và sự thay đổi hệ điều hành có thể ảnh hưởng đến cấu hình phần cứng và phần mềm của ứng dụng Cách tốt nhất để giám sát cấu hình là thông qua một quá trình điều khiển sự thay đổi cấu hình Quá trình này sẽ ghi lại tất cả những

sự thay đổi và cho phép giám sát sự thay đổi bởi những người dùng chịu trách nhiệm của ứng dụng

2.5.2 Độ phức tạp của ứng dụng

Một ứng dụng sẽ trở nên phức tạp hơn khi ứng dụng đó được sử dụng bởi những người dùng trên toàn cầu Ứng dụng phải hỗ trợ đa ngôn ngữ, đa văn hóa và đa tiền tệ Ứng dụng có thể có nhiều thực thể nằm ở những vùng khác nhau trên thế giới, sử dụng những múi thời gian khác nhau Để giám sát hiệu quả những ứng dụng toàn cầu, người xây dựng chương trình ứng dụng phải hiểu được các thực thể ứng dụng, sự kết nối, cách phối hợp giữa các thực thể và có thể phải phụ thuộc vào những đội ngũ phát triển ở từng vùng

2.5.3 Ứng dụng triển khai trên môi trường chia sẻ tài nguyên

Ứng dụng thường được triển khai trên một hệ thống chia sẻ tài nguyên để tận dụng hết khả năng của phần cứng, tuy nhiên cơ chế này tạo ra những thách thức cho việc giám sát ứng dụng Đối với hệ thống ứng dụng đơn , việc theo dõi những tài nguyên như bộ nhớ, CPU, đĩa cứng, băng thông mạng là dễ dàng những trong hệ thống chia sẽ việc giám sát tài nguyên sẽ trở nên phức tạp hơn bởi vì khả năng xảy ra xung đột trong việc sử dụng tài nguyên giữa các ứng dụng trong hệ thống

2.5.4 Ứng dụng triển khai trên hệ thống cluster

Trong môi trường cluster với các máy có thể ở trong những mạng và vị trị khác nhau Khi một ứng dụng triển khai trong môi trường này, thì việc giám sát để phát hiện ra lỗi của ứng dụng rất khó khăn Chương trình giám sát phải theo dấu của những yêu cầu, theo dấu log lỗi ở những thành phần khác nhau của cluster để có thể cô lập và phát hiện điểm gây ra lỗi

2.6 Các công nghệ quản lý

2.6.1 SNMP(Simple Network Management Protocol)

SNMP là một giao thức mạng dựa trên UDP (User Datagram Protocol), nó được sử dụng nhiều trong các hệ thống quản lý giám sát các thiết bị gắn vào trong mạng SNMP được định nghĩa bởi tổ chức IETF( Internet Engineering Task Force) vào năm 1989, chuẩn SNMP được mô tả trong tài liệu RFC 1098

SNMP bao gồm một tập các giao thức và chức năng quản lý mạng, nó có thể giao tiếp

sử dụng chồng IP (Internet Protocol) SNMP cho phép hệ thống quản lý cô lập, khắc phục lỗi trên một mạng gồm nhiều thiết bị từ các nhà cung cấp khác nhau, cấu hình thiết bị trên mạng, cũng như giám sát hiệu suất và trạng thái mạng Chúng ta có thể xem chi tiết về công nghệ này trong RFC 1098

Hệ thống quản lý dựa trên SNMP sử dụng kiến trúc „manager-agent‟, bao gồm cả vai trò „tác nhân phụ‟ và „tầng quản lý ở giữa‟ đã trình bày ở trên

2.6.2 CMIP(Common Management Information Protocol)

CMIP được phát triển bởi tổ chức chuẩn hóa quốc tế (International Standard Organization) nhằm cạnh tranh với giao thức SMNP Hệ thống quản lý dựa trên CMIP cũng thường sử dụng kiến trúc quản lý „manager-agent‟

CMIP có nhiều chức năng hơn SMNP Ví dụ SNMP chỉ định nghĩa một tập các hành động để thay thế trạng thái của thiết bị quản lý trong khi CMIP cho phép định nghĩa bất

kỳ loại hành động nào Tuy nhiên hiện này trên internet hầu như các thiết bị TCP/IP đều

hỗ trợ SMNP chứ không hỗ trợ CMIP Nguyên nhân là do độ phức tạp và những yêu cầu

về tài nguyên của tác nhân CMIP và hệ thống quản lý CMIP chỉ được hỗ trợ chính trong các thiết bị viễn thông

2.6.3 CIM/WBEM

CIM(Common Information Model) được định nghĩa bởi tổ chức DMTF(distributed management task force) như là một mô hình thông tin chuẩn để mô tả dữ liệu quản lý về thiết bị, mạng, hệ thống và các ứng dụng của hệ thống máy tính Tác nhân hỗ trợ mô hình thông tin này được gọi là CIMOM (CIM object manager) Tổ chức DMTF cũng định nghĩa mô hình giao tiếp là WBEM (Web-Based Enterprise Management), mô hình này định nghĩa những hoạt động CIM là giao diện của nó và một dạng biểu diễn XML (CIM.DTD) được sử dụng để biễu diễn mô hình CIM dưới dạng XML, một ánh xạ để vận chuyển hoạt động CIM với dữ liệu mô hình CIM dưới dạng XML qua giao thức HTTP Toàn bộ sự kết hợp CIM và giao thức dựa trên XML đến CMOM được gọi chung là CIM/WBEM

Hệ thống CIM/WBEM nhìn chung được thực thi theo kiến trúc quản lý agent‟ nhưng không sử dụng vai trò „tầng quản lý ở giữa‟

„manager-2.6.4 JMX(Java Management Extension)

JMX định nghĩa một công nghệ Java hỗ trợ các dịch vụ quản lý bằng cách định nghĩa

sự mở rộng của ngôn ngữ Java để cho phép bất kỳ tài nguyên nào dựa trên công nghệ Java cũng có thể quản lý được

Hệ thống quản lý dựa trên JMX theo đặc tả hiện tại hỗ trợ kiến trúc quản lý agent‟ cơ bản Không như SMNP và CIM/WBEM, JMX không định nghĩa mô hình thông tin quản lý mà nó chỉ cung cấp một thành phần là tác nhân JMX Bộ tương thích JMX là một thành phần trong tác nhân JMX, tùy thuộc vào những bộ tương thích có sẵn trong tác nhân JMX mà nó có thể đóng vai trò là tác nhân hoặc tác nhân phụ trong kiến trúc quản

„manager-lý Nếu bộ tương thích JMX giao tiếp trực tiếp với hệ thống quản lý thì nó sẽ hoạt động như một tác nhân Nếu bộ tương thích JMX giao tiếp với một tác nhân của hệ thống quản

lý thì nó đóng vai trò là tác nhân phụ JMX API là mô hình giao tiếp, cung cấp giao diện được sử dụng bởi các tài nguyên quản lý, đồng thời cũng được sử dụng bởi các hệ thống quản lý để giao tiếp với tác nhân quản lý

JMX là một trong những công nghệ được sử dụng để hiện thực công cụ quản lý ứng dụng Sea Portal nên chúng ta sẽ được tìm hiểu kỹ hơn về công nghệ này trong chương sau

2.7 Các công trình nghiên cứu về quản lý, giám sát ứng dụng

Nagios là một phần mềm quản lý hệ thống mã nguồn mở nổi tiếng mà chúng ta không thể không nhắc tới khi nghiên cứu về quản lý và giám sát ứng dụng Nagios được phát triển bởi Ethan Galstad vào năm 1996 Đây là một phần mềm giám sát hạ tầng ứng dụng

có số lượng người dùng nhiều nhất hiện nay Ban đầu nó được thiết kế để chạy trên hệ điều hành Linux, tuy nhiên hiện nay nó có thể được chạy trên nhiều hệ điều hành khác nhau

Nagios cũng quản lý hệ thống ứng dụng dựa trên kiến trúc quản lý „manager-agent‟ Hình 2.2 là một ví dụ về việc giám sát một máy chủ Linux/Unix dựa trên kiến trúc

„manager-agent‟ với đầy đủ 5 vai trò của Nagios

Hình 2.2.Mô hình giám sát hệ thống Linux/Unix của Nagios

Nagios giám sát các dịch vụ, giám sát máy chủ thông qua các plugin, mỗi dịch vụ sẽ có một plugin tương ứng giám sát, hiện tại Nagios đã xây dựng rất nhiều plugin chuẩn để giám sát nhiều dịch vụ khác nhau như plugin để giám sát các dịch vụ trên máy chủ Window, plugin để giám sát các dịch vụ trên máy chủ Linux, plugin để giám sát router và switch, plugin để giám sát các dịch vụ mạng… Sức mạnh chủ yếu của Nagios chính là việc cho phép người dùng có thể xây dựng plugin thực hiện bất kỳ việc gì mình muốn với bất kỳ ngôn ngữ nào, sau đó Nagios sẽ cung cấp một cơ chế để người dùng có thể tích hợp plugin mình xây dựng vào trong Nagios Tuy nhiên Nagios có một số đặc điểm không phù hợp để dùng làm việc xây dựng công cụ cho ứng dụng Sea Portal như sau:

 Sea Portal là một ứng dụng được xây dựng dựa trên công nghệ Java Để có thể quản lý, giám sát ứng dụng này, theo kiến trúc quản lý „manager-agent‟ chúng ta cần phải có một mô hình thông tin và một mô hình giao tiếp để chuyển những

dữ liệu cần quản lý từ tài nguyên quản lý là Sea Portal cho hệ thống quản lý ví

dụ Nagios JMX là một công nghệ được sử dụng bởi rất nhiều ứng dụng Java và cũng là công nghệ được sử dụng trong luận văn để làm việc này Tuy nhiên, Nagios chỉ mới vừa hỗ trợ một plugin cho JMX khi luận văn này đang thực hiện, hơn nữa plugin này vẫn còn đang trong quá trình kiểm tra, đánh giá Đây là nguyên nhân chính tôi không sử dụng Nagios cho việc quản lý ứng dụng Sea Portal

 Một nguyên nhân nữa là mặc dù hiện nay Nagios có thể được triển khai trên nhiều hệ điều hành khác nhau, tuy nhiên Nagios chủ yếu vẫn được dùng để triển khai trong môi trường Unix/Linux có rất nhiều tài liệu hướng dẫn việc cài đặt, triển khai và xây dựng các plugin trên môi trường này Trong khi ứng dụng Sea Portal thường được triển khai trên môi trường Window Server 2003 và nếu công

cụ xây dựng trong luận văn được triển khai để quản lý ứng dụng Sea Portal thì

nó cũng sẽ được triển khai trên môi trường này

Về mặt nghiên cứu, theo những gì tôi tìm hiểu thì hiện tại có nhiều bài báo tập trung nghiên cứu 2 vần đề sau đây

 Quản lý web service

 Đánh giá chất lượng của các ứng dụng quản lý

Mặc dù web service là một công nghệ được sử dụng phổ biến cung cấp các dịch vụ độc lập với platform cho người dùng, nhưng sức mạnh thật sự của công nghệ này là dựa trên việc tổng hợp các web service để xây dựng những quy trình nghiệp vụ phức tạp, tích hợp các thành phần phần mềm không đồng nhất hoặc các hệ thống tính toán của những công

ty khác nhau Một quy trình nghiệp vụ phức tạp sẽ được chia ra thành nhiều thành phần nhỏ hơn, mỗi thành phần sẽ do một web service xử lý, việc tổng hợp các web service làm những công việc nhỏ thành một web service mới giải quyết được công việc lớn hơn gọi là web service tổng hợp Vấn đề đối với web service tổng hợp chính là việc quản lý và giám sát chất lượng, bởi vì chất lượng của web service tổng hợp sẽ phụ thuộc vào chất lượng các web service nhỏ hơn, cũng như cách kết hợp các web service nhỏ này Do đó hiện tại

có rất nhiều bài báo nghiên cứu về việc quản lý và giám sát web service tổng hợp, việc nghiên cứu tập trung vào 2 vấn đề chính :

 Quản lý tự động web service tổng hợp được mô tả bằng ngôn ngữ BPEL(Web Service – Business Process Excution Language)

WS- Quản lý chất lượng của web service tổng hợp, để đảm bảo cam kết dịch vụ (service level agreement)

Trong tài liệu tham khảo [1], tác giả bài báo đã đề xuất một giải pháp quản lý tự động web service tổng hợp gồm có 3 bước:

 Định nghĩa các luật giám sát, và đưa chúng tự động vào trong các quy trình liên quan đến các luật này

 Sử dụng một proxy để hỗ trợ việc chọn tự động và thực thi các luật trong quá trình chạy các quy trình liên quan đến luật

 Sử dụng một ngôn ngữ hướng người dùng như Anna (Annotated Ada) để tích hợp những ràng buộc dữ liệu vào trong các luật

[8] cũng hướng đến việc quản lý tự động các web service tổng hợp, nhưng tác giả bài báo khai thác những kỹ thuật dựa trên các cách tiếp cận „Planning as Model Checking‟ (xem tham khảo [9]) để tự động tạo ra web service và tổng hợp các thành phần giám sát [6,11] đề xuất một khung sườn (framework) hỗ trợ tự động việc giám sát cam kết chất lượng dịch vụ (SLA) giữa người cung cấp web service và người sử dụng web service Khung sườn này giám sát chất lượng dịch vụ trên cả 2 phía là máy khách (client) và máy chủ (server) Nó được xây dựng dựa vào quy trình xử lý sự kiện để thông báo cho người dùng những giá trị liên quan đến chất lượng dịch vụ và những vi phạm đối với cam kết dịch vụ Những sự kiện này có thể kích hoạt những hành vi tương ứng như thay thế một thực thể mới nếu chất lượng dịch vụ không như mong muốn

[2] đưa ra một cách giám sát chất lượng dịch vụ dựa trên việc xây dựng một khái niệm gọi là thỏa thuận mềm (soft contract) Đây là một bước tiếp cận dựa trên xác suất, thông thường các cam kết chất lượng dịch vụ giữa nhà cung cấp và người sử dụng là „cứng‟ ví

dụ thời gian đáp ứng của một dịch vụ nào đó phải ít hơn một giá trị nhất định Tuy nhiên trong thức tế, các ràng buộc mềm như thời gian đáp ứng phải nhỏ hơn T miligiay trong 95% trường hợp sẽ tự nhiên và phù hợp hơn Trong bài báo này tác giả trình bày 2 phần chính là khái niệm về thỏa thuận mềm dựa trên xác suất và 2 kỹ thuật giám sát thống kê dùng để quản lý những cam kết dựa trên những thỏa thuận mềm

Một số bài báo tập trung nghiên cứu vấn đề đánh giá chất lượng và những ảnh hưởng của công cụ giám sát lên ứng dụng

[5] trình bày vấn đề ảnh hưởng việc quản lý sử dụng JMX lên hiệu suất của tài nguyên cần quản lý Trong bài báo này tác giả đưa ra chỉ số MIM (Management Impact Metric)

đánh giá sự ảnh hưởng bằng cách thay đổi một hoặc một vài nhân tố liên quan đến hệ thống quản lý

[7] trình bày một phương pháp luận để nghiên cứu khả năng mở rộng của một hệ thống quản lý tài nguyên dựa trên việc đánh giá chi phí Nội dung bài báo gồm có 3 phần chính là:

 Trình bày mô hình hiệu suất cho hệ thống quản lý phân bố

 Dựa vào mô hình hiệu suất, tác giả trình bày một chỉ số được dùng để lượng hóa khả năng mở rộng của hệ thống quản lý

 Mô hình giả lập được dùng để áp dụng chỉ số đo khả năng mở rộng đề nghị lên trên một số hệ thống quản lý tài nguyên

Chương 3 Phần mềm quản lý hạ tầng Hyperic HQ

Chương này tập trung giới thiệu về phần mềm mã nguồn mở Hyperic HQ Đây là phần mềm được chọn để nghiên cứu, mở rộng nhằm đáp ứng các yêu cầu về quản lý, giám sát của ứng dụng Sea Portal Nội dung của chương này gồm có

 Giới thiệu về Hyperic HQ

để xây dựng công cụ quản lý ứng dụng Sea Portal

 Hyperic HQ dành cho thương mại Phiên bản này có đầy đủ các chức năng của Hyperic HQ mã nguồn mở kèm theo các chức năng về điều khiển, tư động để quản lý các ứng dụng web

Hyperic HQ là một ứng dụng phân bố J2EE chạy trên nền máy chủ ứng dụng mã nguồn

mở Jboss Nó được phát triển bằng ngôn ngữ Java và các đoạn mã C khả chuyển (portable C) Do đó Hyperic HQ có thể chạy trên nhiều hệ điều hành khác nhau Đây là một trong những đặc điểm chính mà Hyperic HQ được chọn để hiện thực công cụ quản lý trong luận văn này

3.2 Kiến trúc quản lý của Hyperic HQ

Hyperic HQ quản lý tài nguyên theo kiến trúc „manager-agent‟ như hình 3.1 bên dưới

Hình 3.1.Kiến trúc quản lý của Hyperic HQ

HQ Agent đóng vai trò như tác nhân trong kiến trúc „manager agent‟, HQ Agent được cài đặt ở máy mà người dùng muốn giám sát bởi Hyperic HQ, chương trình này khi khởi động nó sẽ tự động khám phá các phần mềm chạy trên máy cần giám sát HQ Agent sẽ thu thập thông tin về tính sẵn sàng, thông tin về việc sử dụng bộ xử lý, bộ nhớ, thông tin

về hiệu suất v v… và chương trình cũng có khả năng điều khiển các phần mềm ứng dụng như bật , tắt máy chủ web và máy chủ ứng dụng Sau khi thu thập dữ liệu, HQ Agent sẽ gửi dữ liệu này về chương trình trung tâm HQ server Việc giao tiếp giữa HQ Agent và

HQ Server có hỗ trợ giao thức SSL (Secure Socket Layer)

HQ Server đóng vai trò là hệ thống quản lý trong kiến trúc quản lý „manager-agent‟

HQ server là trung tâm của phần mềm HQ server giao tiếp với HQ Agent nhận các thông tin của máy cần giám sát từ HQ Agent và lưu trữ những thông tin này trong HQ Database HQ server cung cấp những tiện ích để quản lý hiệu quả các tài nguyên của máy cần giám sát, gom nhóm các tài nguyên để làm dễ dàng quá trình quản lý và giám sát HQ Server sẽ phát hiện khi có cảnh báo xảy ra, và thực hiện những thông báo hoặc những hành động do người dùng định nghĩa

Giao diện của Hyperic HQ được xây dựng dựa trên công nghệ web portal Mỗi trang giao diện là tổng hợp từ nhiều portlet khác nhau Người dùng hoàn toàn có thể thay đổi

giao diện bằng cách thêm, xóa, chỉnh sửa các portlet hoặc có thể viết thêm các portlet và tích hợp vào hệ thống

3.3 Mô hình quản lý tài nguyên

Hyperic HQ chia tài nguyên quản lý thành 3 loại chính

 Nền tảng (platform) : là hệ thống thực thi các ứng dụng, các dịch vụ máy chủ Ví

dụ Window Server 2003 là tài nguyên được Hyperic HQ phân loại là nền tảng

 Dịch vụ máy chủ (server): dịch vụ máy chủ là một phần mềm chạy trên nền tảng Ví dụ dịch vụ máy chủ web Tomcat, dịch vụ máy chủ ứng dụng JBoss v.v

 Dịch vụ (service): là các thành phần phần mềm chạy trên dịch vụ máy chủ Ví

dụ ứng dụng Sea Portal được triển khai trên dịch vụ máy chủ web Tomcat sẽ được phân loại là dịch vụ trong mô hình quản lý tài nguyên của Hyperic HQ Hyperic HQ tự động khám phá được các tài nguyên thuộc một trong 3 loại trên Ngoài

3 loại tài nguyên mà Hyperic HQ có thể tự động khám phá như đã nói ở trên, Hyperic HQ còn cho phép người sử dụng quản lý các dịch vụ thuộc cùng một ứng dụng, hoặc các tài nguyên có cùng thuộc tính bằng cách gom các dịch vụ này lại thành những loại sau:

 Nhóm: là một khái niệm trong Hyperic HQ cho phép người dùng có thể gom các dịch vụ có các thuộc tính giống nhau hoặc các dịch vụ thuộc cùng một chức năng vào trong một nhóm Khái niệm nhóm còn được phân ra thành 2 loại sau

o Nhóm tương thích: là tập hợp các dịch vụ có các thuộc tính giám sát giống hệt nhau về mặt số lượng, kiểu giá trị, tên v.v Ví dụ mỗi bảng trong một cơ sở dữ liệu đều có đúng 3 thuộc tính cần giám sát là kích thước bảng, số lượng hàng được thêm vào, số lượng hàng bị xóa bỏ thì các bảng náy có thể gom vào nhóm tương thích Nhóm tương thích thuận lợi khi người dùng muốn so sánh hoặc điều khiển nhiều dịch vụ có cùng tính chất

o Nhóm không tương thích: là tập hợp các dịch vụ có các thuộc tính giám sát khác nhau, nhưng người dùng muốn gom chung vào một nhóm vì mục đích nào đó chẳng hạn các dịch vụ này thuộc cùng một chức năng

 Ứng dụng: đây là một khái niệm trong Hyperic HQ cho phép người dùng có thể gom các dịch vụ hoặc các nhóm vào trong ứng dụng Việc chọn các dịch vụ hoặc các nhóm để gom lại là tùy mục đích người dùng Ví dụ người dùng có thể gom các dịch vụ các nhóm cùng chung một hệ thống để có thể dễ dàng giám sát toàn bộ hệ thống

3.4 Các chức năng chính của Hyperic HQ

Cũng như rất nhiều hệ thống quản lý khác Hyperic HQ hỗ trợ đầy đủ các chức năng

chính của một hệ thống quản lý như sau:

 Tổ chức : Những thông tin về tài nguyên được lưu trữ trong cơ sở dữ liệu theo

mô hình quản lý tài nguyên của Hyperic HQ

 Giám sát: giám sát các thuộc tính của tài nguyên

 Điều khiển: điều khiển tài nguyên thông qua các phương thức, các hoạt động

 Cảnh báo, thông báo

 Hiển thị, phân tích, báo cáo

Các chức năng này đã được trình bày đầy đủ trong tài liệu tham khảo [13] Trong phần

này chúng ta chỉ giới thiệu qua các chức năng chính được được dùng để quản lý tài

nguyên trong Hyperic HQ

Một tài nguyên cần quản lý có thể tương ứng với một nền tảng, một máy chủ hoặc một

dịch vụ trong Hyperic HQ Tuy nhiên tất cả các tài nguyên đều có một cách quản lý

giống nhau trong Hyperic HQ Mỗi tài nguyên sẽ được quản lý với các chức năng tương

ứng trong 5 thẻ „Monitor‟, „Inventory‟, „Alert‟, „Control‟ và „View‟ như hình bên dưới

Hình 3.2.Giao diện giám sát thuộc tính

Hình 3.2 là giao diện quản lý của một tài nguyên có tên là „MyClass MBean‟, đây là tài nguyên thuộc loại dịch vụ chạy trên dịch vụ máy chủ Apache Tomcat 6.0 Giao diện hiển thị trong hình trên tương ứng với việc chọn thẻ „Monitor‟ trên giao diện quản lý của dịch

vụ Giao diện này giám sát các giá trị thuộc tính của tài nguyên cần quản lý, để có thể hiển thị trên giao diện này các thuộc tính phải được mô tả trong plugin tương ứng với tài nguyên, cách xây dựng plugin sẽ được trình bày trong những phần sau Mỗi thuộc tính giám sát sẽ có 4 giá trị như sau

 LOW: Giá trị nhỏ nhất của thuộc tính trong tất cả các lần quan sát

 AVG: Giá trị này bằng tổng các giá trị trong các lần quan sát chia cho số lần quan sát

 PEAK: Giá trị lớn nhất của thuộc tính trong tất cả các lần quan sát

 LAST: Giá trị của thuộc tính trong lần quan sát gần nhất

Cột „Collection interval‟ thể hiện khoảng thời gian giữa 2 lần gọi, trong ví dụ trên thì

cứ 1 phút Hyperic HQ sẽ quan sát giá trị thuộc tính một lần Người dùng có thể thay đổi khoảng thời gian này bằng cách chọn thuộc tính cần thay đổi và nhập khoảng thời gian vào ô „Collection interval for Selected‟ Một hạn chế của Hyperic HQ trong phần này là

nó chưa hỗ trợ việc giám sát các thuộc tính theo kiểu chuỗi

Ngoài việc hiển thị theo dạng văn bản như trên Hyperic HQ còn hỗ trợ xem giá trị các thuộc tính theo dạng biểu đồ bằng cách nhấp chuột vào thẻ „INDICATORS‟ (trong vòng tròn màu xanh trên hình 3.2)

Hình 3.3.Giám sát thuộc tính dạng biểu đồ

Việc xem các giá trị thuộc tính ở dạng biểu đồ còn cho phép chúng ta có thể xem được các hành động hoặc các thông báo gửi đến tài nguyên bằng cách nhấp chuột vào các vòng tròn nhỏ màu tím trên thanh thời gian (trong vòng tròn màu xanh hình 3.3), khi nhấp chuột vào vòng tròn màu tím này các thông báo hoặc các hành động theo thời gian liên quan đến tài nguyên sẽ xuất hiện như hình bên dưới

Hình 3.4.Giao diện hiển thị thông báo và sự kiện của tài nguyên

Thẻ „Inventory‟ dùng để cấu hình việc quản lý tài nguyên Các cấu hình sẽ được khai báo trong plugin tương ứng với tài nguyên

Hình 3.5.Cấu hình quản lý tài nguyên

Thẻ „Alert‟ hiển thị các cảnh báo liên quan đến tài nguyên, đồng thời cũng cho phép người dùng có thể định nghĩa các cảnh báo cho tài nguyên

Hình 3.6.Giao diện định nghĩa cảnh báo

Hyperic cho phép người dùng có thể định nghĩa điều kiện cảnh báo dựa trên ngưỡng của giá trị thuộc tính, các hoạt động điều khiển hoặc dựa trên những thông báo mà tài nguyên nhận được như trên hình 3.6 Trong quá trình quản lý, khi có một điều kiện cảnh báo nào đó thỏa mãn, Hyperic HQ sẽ gửi một cảnh báo tương ứng với điều kiện đó đến tài nguyên, người dùng có thể xem danh sách các cảnh báo của tài nguyên trong thẻ

„Alert‟ này

Đối với thẻ „Control‟ thì những tài nguyên nào cho phép điều khiển thì người dùng mới nhìn thấy thẻ này trên giao diện tương ứng với tài nguyên đó

Hình 3.7.Giao diện điều khiên tài nguyên

Hình 3.7 là giao diện cho phép người dùng có thể thực hiện các hoạt động điều khiển tài nguyên Các hoạt động có thể được dùng để điều khiển tài nguyên sẽ xuất hiện trong hộp danh sách „Control Action‟, chúng ta có thể thêm, xóa, chỉnh sửa danh sách này từ plugin tương ứng với tài nguyên sẽ trình bày trong phần 3.7 Các tham số tương ứng với hoạt động điều khiển được nhập vào trong trường „Control Argument (optional)‟, các tham số cách nhau bằng dấu phẩy Trong ví dụ trên thì tài nguyên có thể được điều khiển thông qua 2 phương thức là „SetState‟ và „Reset‟

Thẻ „View‟ cho phép người dùng có thể xem một số thông tin về tài nguyên trong thời gian thức, các giá trị thuộc tính mà chúng ta quan sát trong những phần trình bày ở trên chỉ là những giá trị được lấy lên từ cơ sở dữ liệu của Hyperic HQ, những giá trị đó thường là giá trị ở lần quan sát cuối cùng chứ không phải là giá trị trong thời gian thực của thuộc tính Tuy nhiên thẻ này không được sử dụng để quản lý các tài nguyên của ứng dụng Sea Portal trình bày trong luận văn này

3.5 Khả năng mở rộng

Hyperic HQ cung cấp cho người dùng 2 khả năng mở rộng

 Mở rộng khả năng quản lý: việc mở rộng khả năng quản lý được hiện thông qua việc xây dựng plugin tài nguyên (resource plugin) HQ Agent sử dụng plugin tài nguyên để khám phá, giám sát và điều khiển các phần phần mềm tương ứng với

plugin Như vậy để Hyperic HQ có thể quản lý được ứng dụng Sea Portal, chúng

ta cần xây dựng các plugin tài nguyên cho ứng dụng này Tuy nhiên tùy thuộc vào

mô hình giao tiếp mà plugin tài nguyên sẽ được xây dựng khác nhau Hiện tại Hyperic HQ hỗ trợ các mô hình giao tiếp chính sau:

o Giao tiếp thông qua script

o Giao tiếp thông qua JMX

o Giao tiếp thông qua SQL

o Giao tiếp thông qua giao thức SNMP

 Mở rộng giao diện: giao diện Hyperic HQ được mở rộng thông qua plugin mở rộng (extension plugin) hoặc xây dựng các web service để giao tiếp với các hệ thống quản lý khác

Giao diện hiện tại của Hyperic HQ đã đáp ứng được các yêu cầu về quản lý của ứng dụng Sea Portal nên trong luận văn này chúng ta sẽ không sử dụng khả năng mở rộng giao diện

JMX là công nghệ được sử dụng để xây dựng mô hình giao tiếp giữa tài nguyên quản

lý Sea Portal và hệ thống quản lý Hyperic HQ nên trong luận văn này tôi chỉ xin giới thiệu về plugin quản lý tài nguyên thực thi việc giao tiếp thông qua JMX Tuy nhiên để

có thể hiểu rõ hơn cách xây dựng plugin tài nguyên JMX, cùng ta cần tìm hiểu một số khái niệm được dùng trong luận văn về công nghệ này trước, nếu bạn đọc đã nắm được công nghệ này có thể bỏ qua phần giới thiệu về JMX ngay sau đây để đọc các phần tiếp theo

có thể giám sát, điều khiển được tài nguyên thông qua các thuộc tính hoặc phương thức của những đối tượng Java đại diện cho chúng

JMX là một công nghệ Java hỗ trợ việc quản lý tài nguyên thông qua vai trò là mô hình giao tiếp trong kiến trúc „manager-agent‟

Việc quản lý và giám sát tài nguyên sử dụng công nghệ JMX được thực hiện như sau: Mỗi tài nguyên bao gồm phần cứng hoặc phần mềm sẽ được ánh xạ thành một lớp Java gọi là MBean Các thuộc tính của MBean tương ứng với các thuộc tính của tài nguyên,

các hoạt động của tài nguyên tương ứng với các phương thức của MBean và đồng thời công nghệ JMX cung cấp một cơ chế để MBean có thể phát tán một thông báo tương ứng với một sự kiện nào đó xảy ra trong tài nguyên quản lý Các MBean được đăng ký vào trong thành phần đăng ký MBean Server để các hệ thống quản lý thông qua MBean Server có thể truy xuất đến các MBean JMX hỗ trợ việc giao tiếp giữa các hệ thống quản

lý và MBean Server thông qua các kết nối (connector) hoặc bộ tương thích giao thức (protocol adapter)

Kiến trúc của JMX được chia làm 3 mức:

 Mức đo đạc (instrumentation level)

 Mức tác nhân (agent level)

 Mức dịch vụ phân bố (distributed services level)

Hình 3.8.Kiến trúc JMX

Trong phần tiếp chúng ta sẽ xem qua một số khái niệm chính của công nghệ JMX được

sử dụng nhiều trong luận văn để hiện thực công cụ quản lý ứng dụng Sea Portal

3.6.1 MBean chuẩn (standard mbean)

MBean là một thành phần ở mức đo đạc trong kiến trúc JMX MBean chính là kết quả của việc ánh xạ tài nguyên quản lý vào trong một đối tượng Java MBean được chia ra làm nhiều loại khác nhau tùy theo chức năng của nó trong phần này chúng ta chỉ tìm hiểu một loại MBean được sử dụng trong luận văn là MBean chuẩn