CÔNG NGHỆ GRID COMPUTING VÀ ỨNG DỤNG THỬ NGHIỆM TRONG BÀI TOÁN QUẢN TRỊ MẠNG - 7 ppsx

Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2
- 124 -
các yêu cầu cần thiết về môi trường thực thi của ứng dụng để tìm các host thích
hợp. Các nhà phát triển cũng nên quan tâm đến các yếu tố như về môi trường thực
thi, tính khả chuyển của ngôn ngữ lập trình, hệ điều hành, … để tăng số lượng các
host mà ứng dụng có thể thực thi.
4
4
.
.
2
2
.
.
1
1
0
0
.
.

Đ
Đ
ị
ị
n
n
h
h


d
d
ạ
ạ
n
n
g
g


f
f
i
i
l
l
e
e

Các thông tin về định dạng file rất hữu ích khi kết quả của ứng dụng chạy trên
một host được truy xuất bởi ứng dụng chạy trên một host khác. Các host có thể chạy
các nền tảng phần mềm khác nhau, do đó nên sử dụng định dạng XML để trao đổi
dữ liệu.
4
4
.
.
2
2
.
.
1
1
1
1
.
.




V
V
i
i
ệ
ệ
c

c


c
c
à
à
i
i


đ
đ
ặ
ặ
t
t


h
h
ệ
ệ


t
t
h
h
ố

ố
n
n
g
g


Một giải pháp Grid cần đưa ra một cách thức cài đặt dễ dàng, tự động cho những
người không chuyên về kỹ thuật với các khả năng chỉnh sửa các kịch bản (script),
biên dịch lại phần mềm, … Quá trình cài đặt nên được thiết kế giống nhau bất chấp
khả năng phải cài đặt trên các tài nguyên đa dạng hỗn tạp về hệ điều hành hoặc cấu
hình.
4
4
.
.
2
2
.
.
1
1
2
2
.
.

V
V
ấ
ấ
n
n


đ
đ
ề
ề


t
t
h
h
ô
ô
n
n
g
g


t
t
i
i

n
n


G
G
r
r
i
i
d
d


Trạng thái của Grid phải luôn được cung cấp để theo dõi, kiểm soát các hoạt
động của Grid. Việc này có thể bao gồm các chỉ số cho biết tải hiện hành, mức độ
sử dụng tài nguyên, số lượng công việc đang chạy, số lượng công việc trong hàng
đợi, trạng thái các host, số tài nguyên hiện còn, các tài nguyên đã được giữ chỗ, có
thể thông báo các nút cổ chai, các điểm xảy ra vấn đề, …
4
4
.
.
2
2
.
.
1
1
3

3
.
.




T
T
í
í
n
n
h
h


t
t
i
i
ệ
ệ
n
n


d
d
ụ

ụ
n
n
g
g


Mặc dù phần lớn các giải pháp Grid đều tập trung vào cơ sở hạ tầng và các
middleware, nhưng cũng rất hữu ích khi quan tâm đến khía cạnh sử dụng của giải
pháp trong khi thiết kế.
+ Các yêu cầu truyền thống về tính tiện lợi








Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2
- 125 -
Các yêu cầu này tập trung vào các tiêu chí giúp người dùng sử dụng hệ thống
dễ dàng, thuận tiện hơn. Các tiêu chí này bao gồm các hoạt động giao tiếp người
dùng, hiển thị, các hoạt động khác cho phép người dùng làm việc hiệu quả, thoả
mãn với hệ thống.
Một số yêu cầu về tính tiện dụng cơ bản của một giải pháp công nghệ thông
tin bao gồm :
¾ Tính tuỳ biến : Cho phép người dùng khả nă
ng tuỳ biến giao diện và
các thành phần của nó để tối ưu việc sử dụng dựa theo dạng công việc, sở

thích cá nhân, kinh nghiệm sử dụng, ngôn ngữ,…
¾ Tính hiệu quả : Đơn giản hóa các thao tác của từng tác vụ, tạo điều
kiện cho người dùng hoàn thành tác vụ càng nhanh càng tốt.
+ Các yêu cầu về tính tiện dụng của một giải pháp Grid
Một giải pháp Grid phải đạt được các yêu cầu về tính tiện dụng cho nhiều
loại người dùng khác nhau như :
¾ Người dùng cuối : Đăng nhập vào Grid, gọi thực thi ứng dụng, truy
vấn các trạng thái, và xem kết quả trả về.
¾ Chủ/người dùng của các máy tính tham gia Grid.
¾ Các nhà quản trị hệ thống.
4
4
.
.
3
3
.
.


T
T
h
h
i
i
ế
ế
t
t

k
k
ế
ế


t
t
ổ
ổ
n
n
g
g


q
q
u
u
a
a
n
n


Sau khi xem xét, đặc tả các yêu cầu cần thiết của một ứng dụng Grid, cần thiết
phải phân tích, xây dựng một mô hình tổng quan hệ thống nhằm xác định các thành

phần cơ bản của hệ thống. Khi đã chọn việc xây dựng hệ thống với Globus Toolkit,
thiết kế nên tận dụng triệt để các chức năng đã được cung cấp sẵn của bộ toolkit.
Nhà phát triển chỉ cần xây dựng các chức năng của ứng dụng trên các chức năng có
sẵn của Globus.
Phần này trình bày các vấn đề cơ bản trong thiết kế ứng dụng với GT3 theo mô
hình OGSA. Như đã biết, GT3 cũng cung cấp các chức năng để xây dựng ứng dụng
không theo chuẩn OGSA, việc xây dựng ứng dụng với các chức năng này cũng có
thể tham khảo các thông tin trình bày trong phần này và các phần sau đó.








Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2
- 126 -
Để xây dựng ứng dụng, trước hết cần xác định hết tất cả các service của hệ
thống, bao gồm các service cần cung cấp ra bên ngoài, các service hỗ trợ hoạt động
của hệ thống. Cần xác định hết các phương thức (tham số và kiểu trả về), dữ liệu
của service (SDE), các cơ chế thông báo, chu kỳ sống của service cũng như các kịch
bản trao đổi, sử dụng giữ
a các service. Khi đã có mô hình các service và cách thức
liên lạc giữa chúng, cần kiểm tra, chỉnh sửa để mô hình đáp ứng được các yêu cầu
chức năng, phi chức năng của ứng dụng.
Sau khi hoàn thành mô hình tổng quan, việc tiếp theo là thiết kế chi tiết hoạt
động của các service.
4
4

.
.
4
4
.
.


M
M
ộ
ộ
t
t


s
s
ố
ố


v
v
ấ
ấ
n
n

đ
đ
ề
ề


c
c
ầ
ầ
n
n


q
q
u
u
a
a
n
n


t
t
â
â
m
m

t
t
r
r
o
o
n
n
g
g


t
t
h
h
i
i
ế
ế
t
t


k
k
ế
ế

c
c
h
h
i
i


t
t
i
i
ế
ế
t
t


v
v
à
à


v
v
i
i

ế
ế
t
t


m
m
ã
ã


Việc thiết kế, viết mã cho ứng dụng Grid cũng tương tự như cho các ứng dụng
truyền thống. Phần này trình bày một số vấn đề cần quan tâm khi thiết kế chi tiết
hoạt động, viết mã của một ứng dụng Grid. Dưới đây là một số khái niệm được
dùng trong phần này:

¾ Ứng dụng Grid (Grid Application) : Là một tập các công việc để giải quyết
các vấn
đề cụ thể hoặc để đạt đến một kết quả mong đợi bằng các sử dụng hạ
tầng Grid.
¾ Công việc (Job): Là một đơn vị cơ sở trong ứng dụng Grid, thường được
yêu cầu thực thi trên một node của Grid, có các tập dữ liệu đầu vào và đầu ra
cùng với các yêu cầu về môi trường thực thi để hoàn thành nhiệm vụ của nó.
Một công việc có thể
chạy một hay nhiều tiến trình trên một host.
¾ Trình sản xuất/tiêu thụ dữ liệu (Data Producer/Consumer) : Các công
việc tạo ra dữ liệu kết quả được gọi là trình sản xuất dữ liệu, và các công việc
nhận vào dữ liệu được gọi là trình tiêu thụ dữ liệu.

Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2
- 127 -
4
4
.
.
4
4
.
.
1
1
.
.




K
K
i
i
ế

ế
n
n


t
t
r
r
ú
ú
c
c


ứ
ứ
n
n
g
g


d
d
ụ
ụ
n
n
g

g


Phần này sẽ xem xét các luồng công việc trong một ứng dụng Grid. Một ứng
dụng Grid có thể có rất nhiều công việc. Các ứng dụng truyền thống được thực thi
trong một môi trường với các tài nguyên đã biết trước, ở đây chúng ta sẽ xem xét
việc một ứng dụng chạy trong một môi trường nơi mà các tài nguyên được cấp phát
động theo nhu cầu. Nếu muốn sử dụng đồng loạt các tài nguyên Grid, chúng ta cần
xem xét vi
ệc xử lý dữ liệu có thể được thực hiện song song hay không, hay phải
thực hiện tuần tự và một công việc có cần phải chờ lấy dữ liệu từ một công việc
khác hay không. Kết quả là chúng ta sẽ có một mạng các tiến trình trong ứng dụng.
Khi thiết kế cần xem xét các luồng công việc mà chọn giải pháp thiết kế tối ưu.
Ở đây chúng ta cần phân biệt hai khái niệm : luồng
ứng dụng (application flow)
và luồng công việc (job flow). Luồng ứng dụng là trình tự thực thi các công việc tạo
nên ứng dụng, trình tự thực thi các xử lý trong nội bộ công việc được gọi là luồng
công việc. Có 3 kiểu luồng ứng dụng cơ bản : Song song, tuần tự và mạng.
+ Luồng song song (parallel flow)
Nếu một ứng dụng có nhiều công việc có thể được thực thi song song, một
Grid rất thích hợp để thực thi ứng dụng hiệu quả trên các node dành riêng, đặc biệt
trong trường hợp không có (hoặc có rất ít) việc trao đổi dữ liệu của các công việc.
Từ một công việc khởi đầu, các công việc sẽ đồng loạt được gửi đi và yêu cầu thực
thi trên các node được chọn trước hoặ
c được cấp phát động trong Grid. Mỗi công
việc có thể nhận các dữ liệu dành riêng cho mình, thực hiện tính toán một cách độc
lập rồi gửi kết quả về. Các kết quả được tập hợp bởi một công việc khác hay lưu trữ
vào cơ sở dữ liệu. Các dịch vụ của Grid như broker hay trình lập lịch, có thể được
sử dụng để gửi thực thi mỗi công việc vào th
ời điểm và địa điểm tốt nhất trong

Grid. Hình 4-1 mô tả luồng ứng dụng song song :









Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2
- 128 -

Hình 4-1 Luồng ứng dụng song song.
Với một vấn đề hay một ứng dụng, rất hữu ích khi tách nó ra thành các đơn
vị độc lập nhỏ hơn. Để tận dụng được ích lợi của việc thực thi song song, khi thiết
kế, nên phân tích các nhiệm vụ trong ứng dụng xem chúng có thể tách thành các
đơn vị cơ sở có thể chạy như các công việc được không. Các trường hợp như có thể
tách nhỏ tập dữ liệu của m
ột công việc và việc xử lý tập con này không phụ thuộc
và tập con khác hoặc khi có một công việc không cần kết quả từ công việc khác
cũng thuộc dạng luồng song song.
+ Luồng tuần tự (Serial flow)
Trái ngược với luồng ứng dụng song song. Trong trường hợp này, như trên
hình 4-2, chỉ có một dãy các công việc, mỗi công việc phải chờ công việc trước đó
kết thúc và sử dụng kết quả từ công việc trước.


Hình 4-2 Luồng ứng dụng tuần tự.
Trong trường hợp này, lợi ích của việc thực thi ứng dụng trên Grid không

phải là sử dụng song song nhiều tài nguyên, mà là khả năng sử dụng các tài nguyên
có sẵn, thích hợp cho từng công việc. Lưu ý rằng mỗi công việc không cần phải
thực thi trên các tài nguyên giống nhau, do đó, nếu có một công việc đòi hỏi phải sử








Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2
- 129 -
dụng một tài nguyên đặc biệt nào đó, nó có thể được cung cấp tài nguyên đặc biệt
đó trong khi các công việc khác có thể được thực thi trên các tài nguyên bình
thường có chi phí thấp.
Khả năng thực thi các công việc trên nhiều tài nguyên khác nhau cũng làm
tăng tính sẵn sàng và độ tin cậy của ứng dụng. Bên cạnh đó, cũng làm tăng khả
năng chịu đựng của ứng dụng thông qua việc có thể sử dụng các tài nguyên cần
thiết theo nhu c
ầu.
+ Luồng mạng (Networked Flow)
Trong nhiều trường hợp, mọi thứ phức tạp hơn rất nhiều. Các công việc cụ
thể có thể thực thi song song nhưng cũng vẫn có sự phụ thuộc giữa chúng, như thấy
trên hình 4-3. Các kỹ thuật sau có thể áp dụng để giải quyết vấn đề.

Hình 4-3 Luồng ứng dụng mạng.

1. Loose coupling (Giảm bớt sự phụ thuộc)
Kỹ thuật này cần có thêm một dịch vụ quản lý luồng ứng dụng để đồng

bộ các công việc, sẽ làm giảm việc trao đổi liên tiến trình và làm giảm quá tải
trên Grid.
Với những ứng dụng dạng này, cần phân tích kỹ để xác định cách tốt nhất
để tách ứng dụng thành các công việc nhỏ hơn nhằm tăng tính song song. Ở đây
cũng cần phải đưa vào Grid các dịch vụ mới như broker hay trình lập lịch. Có
thể phải tốn thêm chi phí bước đầu, nhưng khi mọi thứ đã ổn định, ứng dụng có
thể được hưởng lợi lớn từ một môi trường tính toán ảo mềm dẻo và tối ưu.
2. Jobs and sub-jobs (Công việc và các công việc con)








Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2
- 130 -
Một hướng tiếp cận khác để làm đơn giản việc quản lý các công việc
trong một ứng dụng là sử dụng mô hình phân cấp các công việc. Một công việc
có thể sử dụng các dịch vụ của Grid để thực thi các công việc con của mình. Với
dạng này, ứng dụng nên được phân hoạch và thiết kế sao cho các công việc cấp
cao có các khả năng tìm kiếm tài nguyên và thực thi các công việc con của mình
một cách tối ư
u nhất. Sẽ có rất nhiều lợi ích đối với các ứng dụng lớn, phức tạp
khi phân lập và chuyển quyền điều khiển, quản trị các nhiệm vụ cụ thể cho các
thành phần độc lập.
4
4
.

.
4
4
.
.
2
2
.
.




X
X
e
e
m
m


x
x
é
é
t
t


s

s
ử
ử


d
d
ụ
ụ
n
n
g
g


n
n
g
g
ô
ô
n
n


n
n
g
g
ữ

ữ


l
l
ậ
ậ
p
p


t
t
r
r
ì
ì
n
n
h
h


Khi một ứng dụng được phát triển, câu hỏi nên sử dụng ngôn ngữ lập trình nào
được đặt ra. Trong môi trường Grid, cần thực hiện thêm một số cân nhắc. Các công
việc dành cho tính toán toán hiệu năng cao (high-performance computing) thường
được viết bằng ngôn ngữ C hoặc Fortran. Thời gian thực thi của các công việc này
không đóng vai trò quan trọng trong ứng dụng, nhưng toàn bộ nội dung và các
nhiệm vụ quan trọng thường được viết bằng các ngôn ngữ khác như Java hay các
ngôn ng

ữ kịch bản như Perl.
Trong Grid, có thể lựa chọn các ngôn ngữ khác nhau để xây dựng các phần của
ứng dụng, dựa trên các yêu cầu của từng công việc và tính sẵn sàng của tài nguyên.
Một số tiêu chí chủ yếu cần quan tâm :
+ Tính khả chuyển qua các nền tảng khác
Bao gồm việc tương thích mã thực thi trên các nền tảng mà Java là một ví dụ
tốt, một chương trình nhị phân có thể thực thi trên bất kỳ nền tảng nào hỗ trợ máy
ảo Java (Java Virtual Machine). Các ngôn ngữ thông dịch như Perl cũng có tính khả
chuyển, cho phép ứng dụng chạy mà không cần biết đến nền tảng thực thi. Tính khả
chuyển trong mã nguồn cũng nên được chú ý. Ví dụ, trong trường hợp phải phát
triển ứng d
ụng bằng ngôn ngữ C, sau đó biên dịch nhiều lần trên các môi trường
khác nhau, do đó cần phải tương thích với trình biên dịch khác nhau.
+ Các thư viện/module thực thi








Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2
- 131 -
Dựa theo ngôn ngữ và cách liên kết chương trình, có thể có các yêu cầu về sự
tồn tại các thư viện liên kết động hay các module khác trong thời gian thực thi công
việc. Do đó cần đảm bảo các thư viện, module cần thiết phải nằm trên tài nguyên
đích.
+ Giao diện giao tiếp với hạ tầng Grid
Nếu công việc cần giao tiếp với hạ tầng Grid, như Globus Toolkit, việc lựa

chọn ngôn ngữ phụ thuộc vào ngôn ngữ được hạ tầng Grid hỗ trợ. Lúc đầu GT chỉ
hỗ trợ ngôn ngữ C, nhưng hiện nay thông qua dự án CoG Kit, đã có các hàm API hỗ
trợ các ngôn ngữ khác như Java, Perl, …
4
4
.
.
4
4
.
.
3
3
.
.




V
V
ấ
ấ
n
n


đ
đ
ề

ề


p
p
h
h
ụ
ụ


t
t
h
h
u
u
ộ
ộ
c
c


c
c
ủ
ủ
a
a

c
c
ô
ô
n
n
g
g


v
v
i
i
ệ
ệ
c
c


v
v
à
à
o
o


m

m
ô
ô
i
i


t
t
r
r
ư
ư
ờ
ờ
n
n
g
g


h
h
ệ
ệ


t
t
h

h
ố
ố
n
n
g
g


Một ứng dụng Grid có thể không cần môi trường thực thi đa dạng hỗn tạp, tuy
nhiên cần xem xét một số vấn đề để có thể triển khai tốt nhất hệ thống. Với mỗi
công việc, các yếu tố môi trường sau đây có thể ảnh hưởng đến hoạt động. Khi phát
triển một ứng dụng, cần xem xét các yếu tố này để thiết kế càng độc lập càng tố
t với
các yếu tố này.
¾ Yếu tố quan trọng nhất là phiên bản hệ điều hành, các thiết lập
tham số cần thiết để thực thi công việc, việc phụ thuộc vào các dịch vụ hệ
thống hay các chương trình phụ trợ khác như registry. Cần xem xét liệu
ứng dụng Grid có khả năng chạy các công việc của nó trên bất kỳ node
nào với các hệ điều hành khác nhau hay bị giớ
i hạn trên một hệ điều hành
nhất định.
¾ Kích thước bộ nhớ chính cần thiết cho công việc có thể giới hạn số
lượng các node có khả năng thi nó. Kích thước bộ nhớ có sẵn không
những phụ thuộc vào kích thước vật lý của nó trên node, mà còn phụ
thuộc vào kích thước mà hệ điều hành cho phép trong thời gian thực thi.
¾ Các thư viện liên kết động (DLL) được liên kết với công vi
ệc cần
phải có sẵn trên node hoặc có thể được di chuyển đến và cài đặt trên node
trước khi công việc được thực thi.

Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2
- 132 -
¾ Các cấu hình trình biên dịch trên các node có thể rất khác nhau. ví
dụ các hệ thống khác nhau có thể sử dụng định dạng số khác nhau như
thứ tự các bit, số byte dùng để biểu diễn số nguyên và số thực khác nhau
trên các hệ thống có thể khiến công việc không thể thực thi được.
¾ Cần phải có môi trường thực thi sẵn sàng để thực thi công việc. Ví
dụ, việc triển khai phiên bản JDK cần thiết cầ
n phải được lên kế hoạch và
thực hiện.
¾ Các công việc có thể cần các thiết bị phần cứng để thực thi nhiệm
vụ của mình. Ví dụ, các yêu cầu về thiết bị lưu trữ, đo đạc và các thiết bị
đầu cuối khác cần phải được xem xét khi xây dựng ứng dụng và lên kế
hoạch cho hạ tầng Grid.
¾ …
Khi phát triển ứng dụng, các yếu t
ố trên cần phải được xem xét để tránh quá
nhiều các giới hạn khi thực thi công việc. Có một lượng lớn các giới hạn cũng có
nghĩa là số lượng các node mà công việc có thể thực thi trên đó ít đi. Do đó cần phải
loại bỏ các giới hạn trên càng nhiều càng tốt để công việc có thể chạy trên môi
trường càng tổng quát càng tốt.
4

4
.
.
4
4
.
.
4
4
.
.




Đ
Đ
ồ
ồ


h
h
ì
ì
n
n
h
h

c
c
ô
ô
n
n
g
g


v
v
i
i
ệ
ệ
c
c


Cần phải có các thiết kế về kiến trúc để giải quyết vấn đề về đồ hình công việc
và dữ liệu. Khi xem xét, một số yếu tố chính sau đây cần phải được chú ý:

¾ Các công việc có thể hoặc phải chạy ở đâu ?
¾ Làm sao để có thể phân tán và triển khai chúng thông qua hệ thống mạng ?
¾ Làm sao đóng gói chúng với các dữ liệu cần thiết ?
¾ Nơi nào trong mạng lưu trữ mã thực thi của công việc ?
¾ Làm sao để xác định được node thích hợp để có thể thực thi các công việc cụ
thể?

¾ Vị trí của của dữ liệu và các
điều kiện truy xuất cho công việc.
¾ Kích thước dữ liệu được công việc xử lý.
¾ Các giao diện cần thiết để tương tác với các thiết bị.








Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2
- 133 -
¾ Các liên lạc liên tiến trình cần thiết để công việc có thể hoàn thành nhiệm vụ
của mình.
¾ Tính sẵn sàng và các giá trị hiệu năng của mỗi node trong thời gian thực thi.
¾ Kích thức mã thực thi của công việc và khả năng di chuyển chúng trong hệ
thống.
¾ …
Khi phát triển ứng dụng Grid, có thể không cần biết hết tất cả các thông tin về
đồ hình Grid, tuy nhiên, đặc biệt là trong trường hợp một IntraGrid c
ần phải được
xây dựng để hỗ trợ một nhóm các ứng dụng đặc biệt, các thông tin này có thể rất
cần thiết. Nhờ đó, có thể kiến trúc ứng dụng và hạ tầng Grid để tối ưu hoá môi
trường thực thi bằng các xem xét đến vị trí các tài nguyên, dữ liệu, và tập các node
mà ứng dụng có thể thực thi.
4
4
.

.
5
5
.
.


T
T
r
r
i
i
ể
ể
n
n


k
k
h
h
a
a
i
i


c

c
à
à
i
i


đ
đ
ặ
ặ
t
t


c
c
á
á
c
c


G
G
r
r
i
i
d

d


S
S
e
e
r
r
v
v
i
i
c
c
e
e


Sau khi có bản thiết kế chi tiết các hoạt động và liên lạc của các service trong hệ
thống, đến bước viết mã thực thi, ở đây trình bày việc viết mã cho các Grid Service.
Phần này trình bày các bước cần thiết để viết một OGSI-service cùng với các kỹ
thuật cài đặt cụ thể với GT3.
Việc phát triển, phân phối một Grid service với GT3 tuân theo 5 bước sau (lưu
ý, các bước này cùng với các công cụ liên quan có thể thay đổi trong các phiên bản
sau của GT):
1. Đị
nh nghĩa service interface (sử dung ngôn ngữ đặc tả GWSDL).
2. Viết mã thực thi cho service (sử dụng ngôn ngữ lập trình Java).
3. Định nghĩa các tham số triển khai service (sử dụng ngôn ngữ đặc tả

WSDD).
4. Biên dịch và phát sinh các file GAR (sử dụng công cụ Ant).
5. Triển khai service (sử dụng công cụ Ant).
Các phần dưới đây sẽ trình bày chi tiết các bước và các kỹ thuật cài đặt các cơ
chế của Grid service. Để cụ thể và dễ hiểu hơn, việ
c trình bày sử dụng lại ví dụ
MathService được nhóm phát triển Globus đưa ra, có thể tìm thấy trong website :








Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2
- 134 -
. Ở đây chúng ta cần xây dựng một Grid service cho
phép người thực hiện các chức năng cộng, trừ đơn giản, có tên là MathService.
4
4
.
.
5
5
.
.
1
1
.

.




C
C
á
á
c
c


b
b
ư
ư
ớ
ớ
c
c


x
x
â
â
y
y

d
d
ự
ự
n
n
g
g


v
v
à
à


t
t
r
r
i
i
ể
ể
n
n


k

k
h
h
a
a
i
i


G
G
r
r
i
i
d
d


S
S
e
e
r
r
v
v
i
i
c

c
e
e


Bước 1 : Định nghĩa service interface
Ở đây chúng ta đã xác định các chức năng cần có của MathService (là cung
cấp khả năng cộng và trừ 2 số). Chúng ta cần định nghĩa một interface cho
MathService, interface này sẽ chứa các phương thức cần thiết cung cấp cho người
dùng. Lưu ý service interface còn được gọi là portType. Việc định nghĩa interface ở
đây sử dụng ngôn ngữ đặc tả GWSDL, một phiên bản mở rộng của WSDL cho Grid
service. Có 2 cách để định nghĩa interface cho MathService :
+ Tự
viết file GWSDL đặc tả.
+ Sử dụng công cụ tự động phát sinh file GWSDL từ giao diện lớp
của Java.
Mỗi cách đều có những ưu khuyết điểm riêng, nếu phát sinh từ khai báo lớp Java
thì chúng ta chỉ cần khai báo :

public interface Math
{
public void add(int a);
public void subtract(int a);
public int getValue();
}

Tuy nhiên, khi phát sinh bằng cách này sẽ không tận dụng hết tất cả các sức
mạnh của GWSDL. Do đó nên tự viết các đặc tả interface cho service bằng
GWSDL. Chi tiết về cách viết một tài liệu GWSDL xin tham khảo thêm trong phụ
lục B – Định dạng file GWSDL. Lưu ý, ở đây các hàm add() và substract() chỉ có

một tham số, chúng ta muốn thực hiện cộng dồn các số và chỉ gửi kết quả đến người
dùng khi cần thiết, qua hàm getValue(). Ví dụ này muốn cho thấy Grid service là
một thực thể có trạng thái (stateful), nó tự lưu trữ các kết quả qua một biến cục bộ
và chỉ xuất ra khi cần thiết, đây là một tính chất mới mà một Web service truyền
thống không có đượ
c.








Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2
- 135 -
Dưới đây là đặc tả (đã được rút gọn) của file GWSDL, chi tiết nằm trong
file:
$GRIDSER_DEMO/schema/progtutorial/MathService/Math.gwsdl

<definitions
…………………………………………
name="MathService"


…………………………………………
<! Khai bao namespace >
<! Khai bao cac thanh phan >
………………………………………………………
<! Dinh nghia cac message trao doi cac tham so cho cac phuong thuc >

<message name="AddInputMessage">
<part name="parameters" element="tns:add"/>
</message>
<message name="AddOutputMessage">
<part name="parameters" element="tns:addResponse"/>
</message>
<message name="SubtractInputMessage">
<part name="parameters" element="tns:subtract"/>
</message>
<message name="SubtractOutputMessage">
<part name="parameters" element="tns:subtractResponse"/>
</message>
<message name="GetValueInputMessage">
<part name="parameters" element="tns:getValue"/>
</message>
<message name="GetValueOutputMessage">
<part name="parameters" element="tns:getValueResponse"/>
</message>

<! Dinh nghia portType va cac phuong thuc (operation) >
<gwsdl:portType name="MathPortType"
extends="ogsi:GridService">
<operation name="add">
<input message="tns:AddInputMessage"/>
<output message="tns:AddOutputMessage"/>
<fault name="Fault" message="ogsi:FaultMessage"/>
</operation>
<operation name="subtract">
<input message="tns:SubtractInputMessage"/>
<output message="tns:SubtractOutputMessage"/>

<fault name="Fault" message="ogsi:FaultMessage"/>
</operation>
<operation name="getValue">
<input message="tns:GetValueInputMessage"/>
<output message="tns:GetValueOutputMessage"/>
<fault name="Fault" message="ogsi:FaultMessage"/>
</operation>
</gwsdl:portType>
</definitions>









Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2
- 136 -
Mặc dù GWSDL là độc lập với ngôn ngữ lập trình, tuy nhiên cũng cần phải
tham khảo đặc tả này khi lập trình với ngôn ngữ cụ thể (ở đây là Java), điều này
được thực hiện thông qua các lớp cuống (stub class, khái niệm này được thừa kế từ
Web service), các lớp cuống này được phát sinh tự động bởi các công cụ GT3. Việc
cần làm là thực hiện ánh xạ giữa không gian tên(namespace) của GWSDL với các
gói(package) của Java, thông qua một file ánh x
ạ (mapping file) như sau :
File :
$GRIDSER_DEMO/namespace2package.mappings

http\://www.globus.org/namespaces/2004/02/progtutorial/MathService=
org.globus.progtutorial.stubs.MathService

http\://www.globus.org/namespaces/2004/02/progtutorial/MathService/bindings=
org.globus.progtutorial.stubs.MathService.bindings

http\://www.globus.org/namespaces/2004/02/progtutorial/MathService/service=
org.globus.progtutorial.stubs.MathService.service

Bước 2 : Viết mã thực thi cho service
Sau khi định nghĩa interface cho service, bước tiếp theo là thực hiện cài đặt
interface trong một ngôn ngữ lập trình cụ thể (Java). GT3 cung cấp 2 cách để thực
hiện việc cài đặt một interface cho service:
+ Viết một lớp kế thừa từ lớp GridServiceImpl, đây là lớp cơ sở của tất cả
các Grid Service, lớp kế thừa chỉ cần cài đặt tất cả các phương thức định nghĩa
trong file GWSDL. Lớp này cũng có thể
có các phương thức, thuộc tính riêng
của mình.
+ Sử dụng khả năng ủy quyền để viết các lớp cài đặt interface của
service. Kỹ thuật này sẽ được trình bày chi tiết trong phần sau : Operation
Provider.
Phần này trình bày kỹ thuật cài đặt sử dụng tính kế thừa. Mã nguồn của file :
$GRIDSER_DEMO/org/globus/progtutorial/services/core/first/impl/Ma
thImpl.java
package org.globus.progtutorial.services.core.first.impl;

import org.globus.ogsa.impl.ogsi.GridServiceImpl;
import org.globus.progtutorial.stubs.MathService.MathPortType;
import java.rmi.RemoteException;

Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2
- 137 -

public class MathImpl extends GridServiceImpl implements MathPortType
{
private int value = 0; //Bien luu tru ket qua

public MathImpl() //constructor
{
super("Simple MathService"); //Goi constructor cua cha
}
public void add(int a) throws RemoteException
{
value = value + a;
}
public void subtract(int a) throws RemoteException
{
value = value - a;
}
public int getValue() throws RemoteException
{
return value;
}

}

Lưu ý
:
+ Lớp MathImpl kế thừa từ lớp GridServiceImpl, lớp GridServiceImpl
cài đặt tất cả các phương thức được khai báo trong portType GridService theo
định nghĩa của OGSI.
+ Interface của chúng ta có tên là MathPortType, được khai báo trong
phần portType của file GWSDL.

Bước 3 : Cấu hình quá trình triển khai service với Web Service
Deployment Descriptor (WSDD)
Tới thời điểm này, chúng ta đã thực hiện xong hai phần quan trọng nhất của
service là interface và mã cài đặt của interface. Bây giờ, chúng ta sẽ ghép các phần
này lại với nhau và đưa chúng ra thế giới bên ngoài thông qua một Web server hỗ
trợ Grid service (Grid service container). Quá trình được gọi là quá trình triển khai
(deployment) Grid service.
Một trong những thành phần chính yếu của bước này là bản mô tả triển khai
(deployment descriptor). Đây là một file đặc tả viết dưới dạng WSDD để hướng dẫn








Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2
- 138 -
cho Web server cách xuất bản (publish) Grid service. Bản mô tả triển khai của

MathService như sau:
File :
$GRIDSER_DEMO/org/globus/progtutorial/services/core/first/server-
deploy.wsdd

<?xml version="1.0"?>
<deployment name="defaultServerConfig"
xmlns="
xmlns:java="

<!—-Vi tri Grid service, lien ket URL cua Web server se tao thanh mot
GSH hoan chinh >
<service name="progtutorial/core/first/MathService"
provider="Handler"
style="wrapped">

<!—Ten dung de mo ta service >
<parameter name="name" value="MathService"/>
<parameter name="className"
value="org.globus.progtutorial.stubs.MathService.MathPortType"/>

<! Tham khao den cac lop trien khai interface cua service,luu y
file Math_service.wsdl la file WSDL chuan duoc phat sinh tu dong boi
GT3 tu file Math.gwsdl
>
<parameter name="baseClassName"
value="org.globus.progtutorial.services.core.first.impl.MathImpl
"/>
<parameter name="schemaPath"
value="schema/progtutorial/MathService/Math_service.wsdl"/>

<!—Cac tham so chung cho hau het Grid service >
<parameter name="allowedMethods" value="*"/>
<parameter name="persistent" value="true"/>
<parameter name="handlerClass"
value="org.globus.ogsa.handlers.RPCURIProvider"/>
</service>
</deployment>

Bước 4 : Tạo file GAR với công cụ Ant
Đến lúc biên dịch và đóng gói các file đã tạo ra ở trên để có thể xuất bản ra
thế giới bên ngoài. Tất cả các file và các thông tin cần thiết để một Grid service
container có thể triển khai Grid service đều được đưa một vào một file Grid
Archive, hay file GAR.
Việc tạo một file GAR bao gồm các bước sau:
+ Chuyển đổi file GWSDL thành file WSDL.








Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2
- 139 -
+ Tạo các lớp cuống (stub class) từ file WSDL.
+ Biên dịch các lớp cuống.
+ Biên dịch các mã cài đặt của service.
+ Sắp xếp các file trong một cấu trúc thư mục đặc biệt.

Các bước này có thể làm bằng tay, tuy nhiên đã có một công cụ rất mạnh để
tự động thực hiện việc này, đó là Ant. Ant sử dụng các hướng dẫn trong một build
file (giống như Makefile trong các dự án phần mềm trên Linux) để thực hiện các
công vi
ệc của mình. Hình 4-4 cho thấy các file mà Ant sử dụng để phát sinh file
GAR :


Hình 4-4 Các file cần thiết để triển khai Grid Service với Ant.

Ant sử dụng các file của GT3, các file do chúng ta tạo ra và file build.xml
(file hướng dẫn của Ant) để phát sinh ra file GAR. Chi tiết về Ant, xin tham khảo
tại website : .
Trong ví dụ này có thể thực hiện lệnh sau đây để phát sinh file GAR.
Vào thư mục :
$GRIDSER_DEMO Thực hiện lệnh :
./tutorial_build.sh \
org/globus/progtutorial/services/core/first \
schema/progtutorial/MathService/Math.gwsdl









Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2
- 140 -

Sau khi biên dịch thành công, chúng ta sẽ có file GAR :
$GRIDSER_DEMO/build/lib/org_globus_progtutorial_services_core_first.gar
Bước 5 : Triển khai Grid service trên một Grid service container
Chúng ta chỉ cần thực hiện lệnh sau:
ant deploy \ -
Dgar.name=$GRIDSER_DEMO/build/lib/org_globus_progtutorial_services_core_first.
gar

Đến đây chúng ta đã có thể xây dựng và triển khai một Grid service hoàn
chỉnh. Tiếp theo chúng sẽ xây dựng một client đơn giản để sử dụng service
MathService.
4
4
.
.
5
5
.
.
2
2
.
.




X
X
â

â
y
y


d
d
ự
ự
n
n
g
g


c
c
l
l
i
i
e
e
n
n
t
t


Client chúng ta xây dựng là một chương trình chạy trên console, với 2 tham số

đầu vào là:
+ GSH của Grid service instance
+ Giá trị cần cộng vào.
Dưới đây là mã nguồn của file client :
$GRIDSER_DEMO/org/globus/progtutorial/clients/MathService/Client.j
ava
package org.globus.progtutorial.clients.MathService;
import
org.globus.progtutorial.stubs.MathService.service.MathServiceGridLocat
or;
import org.globus.progtutorial.stubs.MathService.MathPortType;
import java.net.URL;
public class Client
{
public static void main(String[] args)
{
try
{
// Lay cac tham so dong lenh
URL GSH = new java.net.URL(args[0]);
int a = Integer.parseInt(args[1]);

// Lay GSR cua service instance
MathServiceGridLocator mathServiceLocator = new
MathServiceGridLocator();
MathPortType math = mathServiceLocator.getMathServicePort(GSH);
// Goi phuong thuc o xa 'add'
math.add(a);

Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2
- 141 -
System.out.println("Added " + a);

// Lay gia tri hien hanh cua service qua phuong thuc 'getValue'
int value = math.getValue();
System.out.println("Current value: " + value);
}catch(Exception e)
{
System.out.println("ERROR!");
e.printStackTrace();
}
}
}

Việc xây dựng một client rất đơn giản và dễ hiểu.

Trên đây, chúng ta xem xét các bước xây dựng một Grid service với GT3. Về
các kỹ thuật cài đặt các cơ chế của một Grid Service, xin xem thêm trong phần Phụ
lục D – Kỹ thuật cài đặt các cơ chế của Grid Service. Từ đây, chúng ta đã có thể xây
dựng các ứng dụng Grid với các Grid service. GT3 cũng cung cấp giao diện lập
trình để sử dụng các service có sẵn như WS-GRAM, GSI,… Việc lập trình sử dụng
các service này chưa được trình bày ở đây, nhưng với các kỹ thuật đã có, cùng với
việc tham khảo tài liệu về API của GT trên website : www.globus.org

sẽ là tiền đề
thuận lợi để sử dụng hiệu quả các service này.









Chương 5. Quản trị mạng và các hệ thống quản trị
- 142 -
C
C
h
h
ư
ư
ơ
ơ
n
n
g
g


5
5
.

.




Q
Q
u
u
ả
ả
n
n


t
t
r
r
ị
ị


m
m
ạ
ạ
n
n
g

g


v
v
à
à


c
c
á
á
c
c


h
h
ệ
ệ


t
t
h
h
ố
ố
n

n
g
g


q
q
u
u
ả
ả
n
n


t
t
r
r
ị
ị


5
5
.
.
1
1
.

.


Q
Q
u
u
ả
ả
n
n


t
t
r
r
ị
ị


m
m
ạ
ạ
n
n
g
g

Những năm đầu 1980, các mạng máy tính bắt đầu phát triển và được kết nối với
nhau. Kích thước các mạng ngày càng lớn và do đó càng trở nên khó quản lý và bảo
trì. Từ đó, nhu cầu quản trị mạng được đặt ra.
5
5
.
.
1
1
.
.
1
1
.
.




K
K
h
h
á
á
i
i

n
n
i
i
ệ
ệ
m
m


Khái niệm Quản trị mạng (network management) được hiểu theo nhiều cách
khác nhau tuỳ mỗi người và vị trí của họ. Trong một số trường hợp, nó có thể là
hình ảnh một người tư vấn đang theo dõi các hoạt động mạng với một chương trình
phân tích protocol (protocol analyser). Một trường hợp khác, Quản trị mạng liên
quan đến một cơ sở dữ liệu phân tán, tự động thăm dò các thiết bị mạng, các máy
trạm để phát sinh những mô hình đồ hoạ thời gian thực về lưu thông trên mạng hay
những thay đổi trong đồ hình mạng (network topology).
Nói chung, “Quản trị mạng là một dịch vụ sử dụng kết hợp nhiều công cụ,
ứng dụng, và thiết bị để hỗ trợ những người quản trị mạng trong việc kiểm
tra, theo dõi, điều khiển, bảo trì các hệ thống mạng”.
5
5
.
.
1
1
.
.
2
2

.
.




C
C
á
á
c
c


l
l
ĩ
ĩ
n
n
h
h


v
v
ự
ự
c
c

q
q
u
u
ả
ả
n
n


t
t
r
r
ị
ị


m
m
ạ
ạ
n
n
g
g

Tổ chức International Organization for Standardization đã đưa ra một mô hình
khái niệm diễn tả 5 lĩnh vực chức năng chính của công việc quản trị mạng là quản lý
hiệu năng, quản lý cấu hình, quản lý sử dụng, quản lý lỗi và quản lý bảo mật. Dưới
đây giới thiệu sơ nét một số lĩnh vực cần quan tâm.
5
5
.
.
1
1
.
.
2
2
.
.
1
1
.
.






Q
Q
u
u

ả
ả
n
n


l
l
ý
ý


h
h
i
i
ệ
ệ
u
u


n
n
ă
ă
n
n
g
g

(
(
P
P
e
e
r
r
f
f
o
o
r
r
m
m
a
a
n
n
c
c
e
e


M
M

a
a
n
n
a
a
g
g
e
e
m
m
e
e
n
n
t
t
)
)


Mục tiêu của performance management(quản lý hiệu năng mạng) là đo lường,
thiết lập các thông số và từ đó, nâng cao tính sẵn sàng, chất lượng dịch vụ (QoS)

Chương 5. Quản trị mạng và các hệ thống quản trị
- 143 -
của hệ thống mạng. Các thông số về hiệu năng có thể là tải của mạng, thời gian đáp
ứng người dùng, …
Quá trình quản lý hiệu năng bao gồm 3 bước:
1. Trước hết, các dữ liệu về hiệu năng mạng được thu thập theo chủ ý của
người quản trị mạng.
2. Tiếp đó, dữ liệu được phân tích để xác định mức cơ bản của các thông s
ố
về hiệu năng có thể chấp nhận được.
3. Cuối cùng, các giá trị thích hợp của các thông số quan trọng về hiệu năng
mạng được xác định để khi các giá trị này bị vượt qua sẽ cho thấy một vấn đề về hệ
thống mạng cần phải chú ý.
Module quản trị theo dõi liên tục các thông số hiệu năng này, khi một giá trị
hiệu năng bị vượt qua, thì sẽ
thực hiện báo động cho hệ thống quản trị mạng.
Trên đây là quá trình thiết lập một hệ thống phản ứng bị động, quản lý hiệu năng
còn cho phép thực hiện các phương pháp chủ động như: Giả lập hệ thống mạng để
kiểm tra xem việc mở rộng hệ thống mạng sẽ ảnh hưởng như thế nào đến hiệu năng
của toàn mạng, từ đó người quản trị mạng có thể biết những nguy cơ tiềm ẩn để
khắc phục trước khi nó xảy ra.
5
5
.
.
1
1
.

.
2
2
.
.
2
2
.
.






Q
Q
u
u
ả
ả
n
n


l
l
ý
ý

l
l
ỗ
ỗ
i
i


h
h
ệ
ệ


t
t
h
h
ố
ố
n
n
g
g


(
(
F

F
a
a
u
u
l
l
t
t


M
M
a
a
n
n
a
a
g
g
e
e
m
m
e
e
n
n
t

t
)
)


Mục tiêu của Fault Management là phát hiện, ghi nhận, thông báo cho người
quản trị và tự động sửa chữa các hư hỏng để hệ thống mạng có thể hoạt động hiệu
quả. Vì các hư hỏng có thể làm mất hoàn toàn chức năng của hệ thống mạng, nên
Fault Management có thể được xem là quan trọng nhất trong mô hình quản trị mạng
ISO.
Fault Management bao gồm việc xác định các khả năng gây lỗi và phân lập lỗi.
Sau
đó là khắc phục lỗi và kiểm tra giải pháp phục hồi trên các hệ thống con quan
trọng. Cuối cùng, tài liệu về phát hiện và khắc phục lỗi được lưu lại.
Để làm được như vậy, fault management phải sử dụng các cơ chế để:
+ Thông báo khi có lỗi xảy ra.
+ Thực hiện các kiểm tra chuẩn đoán trên hệ thống
+ Tự động (nếu có thể) khắc phục lỗi.








Chương 5. Quản trị mạng và các hệ thống quản trị
- 144 -
5
5

.
.
1
1
.
.
2
2
.
.
3
3
.
.






Q
Q
u
u
ả
ả
n
n

l
l
ý
ý


b
b
ả
ả
o
o


m
m
ậ
ậ
t
t


(
(
S
S
e
e
c
c

u
u
r
r
i
i
t
t
y
y


M
M
a
a
n
n
a
a
g
g
e
e
m
m
e
e
n
n

t
t
)
)


Mục tiêu của Security Management (quản lý bảo mật) là kiểm soát việc truy cập
đến các tài nguyên mạng dựa trên các chính sách cục bộ để ngăn chặn các hành
động phá hoại hệ thống mạng (vô tình hay cố ý) và truy cập trái phép đến các dữ
liệu nhạy cảm.
Các vấn đề về bảo mật mạng đã được trình bày nhiều trong các tài liệu khác, ở
không sâu vào chi tiết.
5
5
.
.
2
2
.
.


H
H
ệ
ệ


t
t

h
h
ố
ố
n
n
g
g


q
q
u
u
ả
ả
n
n


t
t
r
r
ị
ị


m
m

ạ
ạ
n
n
g
g


5
5
.
.
2
2
.
.
1
1
.
.




M
M
ô
ô

h
h
ì
ì
n
n
h
h


v
v
à
à


h
h
o
o
ạ
ạ
t
t


đ
đ
ộ
ộ

n
n
g
g


Hầu hết các mô hình quản trị mạng đều sử dụng cùng kiến trúc và nguyên tắc
hoạt động cơ bản.
+ Mô hình:
Dưới đây là sơ đồ một mô hình hệ thống quản trị mạng:

Hình 5-1 Mô hình hệ thống quản trị mạng
Mô hình trên gồm các thành phần:
1. Network Management Station(s)








Chương 5. Quản trị mạng và các hệ thống quản trị
- 145 -
Chạy module quản trị mạng thu thập thông tin về các thiết bị cần quản trị
từ các agent. Module này thường phải xử lý một lượng rất lớn dữ liệu, phản ứng
lại các sự kiện, chuẩn bị các thông tin cần thiết để xuất ra màn hình. Nó thường
có một trình điều khiển với giao diện đồ họa cho phép các nhà quản trị xem xét
một cách trực quan trạng thái hệ thống,
điều khiển các thiết bị, cấu hình lại hệ

thống. Một số module quản trị mạng còn cho phép lập trình để phản ứng lại các
thông tin thu thập từ các agent và/hoặc thiết lập các định mức hoạt động
2. Thiết bị bị quản trị (Managed Devices)
Là bất kỳ một thiết bị nào đó trong mạng chịu sự quản lý, điều khiển của
module quản tr
ị, ví dụ như : máy tính, máy in, router, switch,… Các thiết bị này
thường chứa một agent.
3. Agent
Thường trú trên thiết bị cần quản trị. Cung cấp thông tin về thiết bị cần
quản trị cho ứng dụng quản trị mạng và có thể tiếp nhận và thực hiện các thông
tin điều khiển. Các chức năng cơ bản của một agent:
+ Cung cấp thông tin trạng thái của thiết bị.
+ Số liệu th
ống kê về các network interface của thiết bị.
+ Cung cấp một giao diện để cấu hình thiết bị.
+ Có khả năng phát hiện lỗi trên thiết bị và báo cáo cho module quản trị.
+ Có khả xác nhận người dùng và bảo mật để đảm bảo chỉ có module
quản trị với các quyền thích hợp mới có thể thực hiện các chức năng trên.
4. Proxy
Là các thực thể cho phép quản lý thông tin của các thực thể khác, có vai
trò là người đại diện cho các thực thể khác trước module quản trị.
5. Network management protocol
Protocol dùng để trao đổi thông tin giữa module quản trị và agent. Hai
protocol được sử dụng nhiều nhất trong hệ thống mạng:
+ Simple NetworkManagement Protocol (SNMP) : sử dụng rộng rãi
trong môi trường mạng LAN

Chương 5. Quản trị mạng và các hệ thống quản trị
- 146 -
+ Common Management Information Protocol : sử dụng trong môi
trường WAN, khi mà các hệ thống mạng trở nên lớn, phức tạp hơn.
6. Management Information.
Thông tin đổi giữa module quản trị và agent để thực hiện theo dõi và điều
khiển các thiết bị bị quản trị.
+
Hoạt động :
Khi các agent phát hiện ra vấn đề cần quan tâm (khi một người dùng cố gắng
thử rất nhiều mật khẩu khác nhau trên hệ thống, một lỗi phần cứng, …), sẽ gửi các
thông báo về module quản trị thông qua protocol quy ước.
Dựa trên các thông báo nhận được, module quản trị được lập trình tự động sẽ
phản ứng bằng cách thực thi các hành động thích hợp để giải quyết vấn đề, thông
báo cho người qu
ản trị, phục hồi hệ thống,…
Module quản trị cũng có thể thực hiện truy vấn (để cung cấp thông tin cập
nhật trạng thái hệ thống) đến các thiết bị bị quản trị để kiểm tra tình trạng hiện tại
của hệ thống. Các agent sẽ trả lời các câu truy vấn này.
Agent sẽ lưu thông tin của thiết bị nó đang quản lý vào cơ sở dữ liệ
u, rồi sau
đó cung cấp cho module quản trị khi cần thiết.
5
5
.
.

2
2
.
.
2
2
.
.




M
M
ộ
ộ
t
t


s
s
ố
ố


c
c
h
h

ứ
ứ
c
c


n
n
ă
ă
n
n
g
g


c
c
ơ
ơ


b
b
ả
ả
n
n

c
c
ủ
ủ
a
a


m
m
ộ
ộ
t
t


h
h
ệ
ệ


t
t
h
h
ố
ố
n
n

g
g


q
q
u
u
ả
ả
n
n


t
t
r
r
ị
ị


m
m
ạ
ạ
n
n
g
g

Trong phần này, chúng ta sẽ điểm qua một vài chức năng cơ bản mà một hệ
quản trị mạng cần phải có.
+ Polling
Đây là đặc trưng cơ bản của tất cả các hệ quản trị mạng. Polling là khái niệm
chỉ việc module quản trị thực hiện truy vấn định kỳ các thiết bị đang quản lý để xác
định trạng thái hiện hành của chúng.
Vấn đề là phải xác định thời gian giữa các lần truy vấn cho hợp lý, bởi vì
trong một hệ thống mạng lớn, có hàng ngàn thiết bị cần quản lý, lưu lượng thông tin
phục vụ quản lý sẽ rất lớn, có thể ảnh hưởng đến hoạt động của hệ thống, tuy nhiên
nếu thời gian giữa các lần quá lâu, khi một thiết bị hỏng, sẽ không phát hiện được
trong thời gian cho phép. Vấn đề trên có thể được khắc phục bằng kỹ thuật trap-