7064436 Tim Hieu Cong Nghe Grid Computing Va Ung Dung

8/6/2019 7064436 Tim Hieu Cong Nghe Grid Computing Va Ung Dung

http://slidepdf.com/reader/full/7064436-tim-hieu-cong-nghe-grid-computing-va-ung-dung 1/231

TR ƯỜ NG ĐẠI HỌC KHOA HỌC TỰ NHIÊN TP.HCMKHOA CÔNG NGHỆ THÔNG TIN

BỘ MÔN CÔNG NGHỆ PHẦN MỀM

SINH VIÊN THỰ C HIỆN

Nguyễn Mạnh Dũng 0112132Nguyễn Đăng Thành 0112280

TTÌÌMM HHIIỂỂUU CCÔÔNNGG NNGGHHỆỆ GGR R IIDD CCOOMMPPUUTTIINNGG

VVÀÀ Ứ Ứ NNGG DDỤỤNNGG TTHHỬ Ử NNGGHHIIỆỆMM

TTR R OONNGG BBÀÀII TTOOÁÁNN QQUUẢẢNN TTR R ỊỊ

MMẠẠNNGG

LUẬN VĂN CỬ NHÂN TIN HỌC

GIÁO VIÊN HƯỚ NG DẪN

TThhầầyy CCaaoo ĐĐăănngg TTâânn

TP. HỒ CHÍ MINH, 12/2005



Lờ i cảm ơ n

- i -

LLờờii ccảảmm ơơnn

Nhóm thực hiện xin bày tỏ lòng biết ơ n và tri ân sâu sắc đến tất cả mọi ngườ i

đã giúp đỡ , hỗ tr ợ thực hiện luận văn này, một điểm mốc r ất quan tr ọng trong cuộc

đờ i và sự nghiệ p của chúng em.

Chúng em xin cảm ơ n Khoa Công nghệ Thông tin tr ườ ng Đại học Khoa học

Tự nhiên TP.HCM đã cho phép và tạo điều kiện để chúng em thực hiện luận văn

này.

Luận văn này sẽ không thể hoàn thành nếu không có sự giúp đỡ và chỉ bảo

tận tình của thầy Cao Đăng Tân, ngườ i thầy hướ ng dẫn của chúng em. Chúng emxin chân thành biết ơ n về những chỉ bảo, định hướ ng nghiên cứu thực hiện, hỗ tr ợ ,

tạo những điều kiện tốt nhất cho chúng em trong suốt quá trình thực hiện đề tài.

Chúng con xin bày tỏ lòng biết ơ n sâu sắc đến Bố, Mẹ, những bậc sinh thành

đã chịu thươ ng, chịu khó nuôi dưỡ ng, hỗ tr ợ , động viên, ủng hộ chúng con trong

những lúc khó khăn để chúng con có đượ c như ngày hôm nay.

Chúng em xin chân thành cảm ơ n tất cả quý thầy cô trong khoa Công nghệ

Thông tin đã tận tình chỉ bảo, rèn luyện, truyền đạt những tri thức, k ỹ năng, kinh

nghiệm quý báu cho chúng em trong suốt 4 năm ở giảng đườ ng đại học. Đây là

những hành trang quý giá để chúng em vững bướ c vào đờ i.

Nhóm thực hiện xin chân thành cảm ơ n tất cả các anh chị, bạn bè, đặc biệt là

các thầy cô Phòng máy Mạng, thầy Tr ần Minh Triết, thầy Lu Boun Vinh, đã nhiệt

tình động viên, ủng hộ, chia sẻ những kinh nghiệm, kiến thức quý báu, tài liệu, hỗ

tr ợ không những trong quá trình thực hiện luận văn mà còn trong suốt thờ i gian học

tậ p dướ i mái tr ườ ng này.

Mặc dù đã hết sức nỗ lực và cố gắng, nhưng luận văn chắc chắn không tránh

khỏi những thiếu sót. Chúng em kính mong nhận đượ c sự cảm thông và tận tình chỉ

bảo, góp ý của quý Thầy Cô và các bạn. Một lần nữa xin gửi đến tất cả mọi ngườ i

lờ i cảm ơ n chân thành nhất. Xin cảm ơ n !.

Nhóm thực hiện

Nguyễn Mạnh Dũng & Nguyễn Đăng Thành



Lờ i nói đầu

- ii -

LLờờii nnóóii đđầầuu

Công nghệ Grid Computing ra đờ i đánh dấu một bướ c phát triển mớ i trong

l ĩ nh vực điện toán hiệu năng cao. Nó cho phép tận dụng năng lực xử lý, lưu tr ữ

cùng các tài nguyên nhàn r ỗi khác để cung cấ p một môi tr ườ ng tính toán có năng

lực xử lý lớ n, khả năng lưu tr ữ dồi dào để giải quyết các bài toán phức tạ p - khó có

thể giải quyết đượ c vớ i các công nghệ hiện hành hoặc giải quyết đượ c nhưng vớ i

chi phí r ất cao - trong khoa học, thươ ng mại. Grid Computing giúp tận dụng tối đa

tài nguyên, tăng cườ ng hợ p tác, giảm chi phí đầu tư trong khi vẫn cung cấ p năng lực

tính toán như mong muốn. Trong những năm vừa qua, nhiều tổ chức, tậ p đoàn côngnghệ thông tin lớ n đã chọn công nghệ Grid Computing làm chiến lượ c phát triển

của mình, đã đầu tư nghiên cứu nhằm sớ m đưa công nghệ Grid Computing vào thực

tế. Công nghệ này đang ngày càng thu hút đượ c sự quan tâm chú ý từ khắ p nơ i trên

thế giớ i. Có thể nói công nghệ Grid Computing là một xu hướ ng phát triển mớ i

trong ngành công nghệ thông tin.

Hiện nay, đất nướ c ta đang thực hiện công cuộc công nghiệ p hoá, hiện đại

hóa, trong đó việc rút ngắn sự tụt hậu, phát triển về khoa học công nghệ là yếu tố

then chốt quyết định đến thành công của công cuộc đổi mớ i. Song song vớ i quá

trình phát triển, ngày càng có nhiều bài toán mớ i, đòi hỏi năng lực xử lý lớ n xuất

hiện trong khoa học, thươ ng mại và quản lý đất nướ c. Các công nghệ tính toán hiện

hành cũng đượ c áp dụng nhưng không thể triển khai r ộng rãi để có thể giải quyết

hết các nhu cầu do chi phí đầu tư quá lớ n. Việc nghiên cứu, áp dụng công nghệ Grid

Computing là một giải pháp tốt để giải quyết các tình huống này. Hơ n nữa, công

nghệ Grid Computing hiện nay còn khá mớ i mẻ, đang trong giai đoạn hoàn thiện,

việc cùng tham gia nghiên cứu vớ i cộng đồng thế giớ i sẽ giúp chúng ta học hỏi kinh

nghiệm, tiến tớ i làm chủ công nghệ, từ đó có thể phát triển theo hướ ng đi của riêng

mình, đáp ứng nhu cầu tính toán hiệu năng cao ngày càng tăng của đất nướ c.





Mục lục

- iv -

MMụụcc llụụcc

Lờ i cảm ơ n .........................................................................................................i Lờ i nói đầu ........................................................................................................ii

Mục lục.............................................................................................................iv

Danh sách hình...............................................................................................viii

Danh sách bảng .................................................................................................x

Một số thuật ngữ ..............................................................................................xi

Các chữ viết tắt................................................................................................xii

Tóm tắt luận văn.............................................................................................xiii Chươ ng 1. Mở đầu..........................................................................................1

1.1. Công nghệ Grid Computing (tính toán lướ i) ..............................................................11.2. Vấn đề quản tr ị mạng..................................................................................................31.3. Mục tiêu đề tài ............................................................................................................4

Chươ ng 2. Tổng quan về công nghệ Grid Computing...................................5

2.1. Khái niệm Grid ...........................................................................................................52.1.1. Theo dòng lịch sử ................................................................................................52.1.2. Khái niệm.............................................................................................................62.1.3. Tài nguyên của Grid ............................................................................................7

2.2. Phân loại Grid & Grid Topology ................................................................................92.2.1. Các kiểu Grid .......................................................................................................92.2.2. Đồ hình Grid (Grid Topology)...........................................................................11

2.3. Các thách thức, yêu cầu của công nghệ Grid............................................................152.3.1. Quản lý tài nguyên (Resource Management) ....................................................152.3.2. Bảo mật (Security).............................................................................................172.3.3. Quản lý thông tin ...............................................................................................192.3.4. Quản lý dữ liệu ..................................................................................................202.3.5. Phát triển ứng dụng............................................................................................20

2.3.6. Các vấn đề khác .................................................................................................202.3.7. Các việc cần làm................................................................................................212.4. Ích lợ i & Ứ ng dụng...................................................................................................222.5. Các thành phần cơ bản của một hệ thống cơ sở hạ tầng Grid...................................242.6. Kiến trúc Grid ...........................................................................................................27

2.6.1. Bản chất Kiến trúc Grid .....................................................................................272.6.2. Chi tiết Kiến trúc Grid tổng quát .......................................................................282.6.3. Kiến trúc Grid trong thực tế...............................................................................35

2.7. Chuẩn hoá Grid .........................................................................................................362.8. Giớ i thiệu các dự án Grid middleware chính............................................................40

2.8.1. UNICORE..........................................................................................................40

2.8.2. Globus................................................................................................................43



Mục lục

- v -

2.8.3. Legion ................................................................................................................432.8.4. GridBus..............................................................................................................452.8.5. So sánh...............................................................................................................48

Chươ ng 3. Giớ i thiệu bộ Globus Toolkit phiên bản 3.2...............................52

3.1. Giớ i thiệu ..................................................................................................................523.1.1. Giớ i thiệu ...........................................................................................................523.1.2. Lịch sử phát triển ...............................................................................................53

3.2. Các công nghệ, chuẩn liên quan ...............................................................................533.2.1. Service Oriented Architeture (SOA)..................................................................533.2.2. Web Service.......................................................................................................563.2.3. OGSA.................................................................................................................583.2.4. OGSI và Grid Service ........................................................................................65

3.3. Kiến trúc Globus Toolkit ..........................................................................................743.3.1. Mô hình kiến trúc GT2 ......................................................................................75

3.3.2. Mô hình kiến trúc GT3 ......................................................................................763.4. Các thành phần chính................................................................................................793.4.1. Sercurity Infrastructure......................................................................................793.4.2. Resource Management.......................................................................................943.4.3. Information Service .........................................................................................1073.4.4. Data Management............................................................................................1133.4.5. Thành phần mớ i trong GT3 .............................................................................114

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

4.1. Khở i đầu dự án........................................................................................................1154.1.1. Định hướ ng phát triển hệ thống.......................................................................115

4.1.2. Đánh tính khả thi của ứng dụng khi chạy trên Grid.........................................1174.2. Các yêu cầu cần quan tâm khi xây dựng ứng dụng ................................................118

4.2.1. Khả năng mở r ộng (Scalability).......................................................................1184.2.2. Bảo mật............................................................................................................1184.2.3. Tính mềm dẻo của ứng dụng (Flexibility).......................................................1194.2.4. Các k ết nối vớ i bên ngoài ................................................................................1194.2.5. Hiệu suất ứng dụng(Performance)...................................................................1204.2.6. Độ tin cậy (Reliability) ....................................................................................1214.2.7. Quản tr ị hệ thống (Management).....................................................................1224.2.8. Đồ hình hệ thống (System Topology)..............................................................1234.2.9. Môi tr ườ ng đa nền tảng....................................................................................1234.2.10. Định dạng file ................................................................................................1244.2.11. Việc cài đặt hệ thống .....................................................................................1244.2.12. Vấn đề thông tin Grid ....................................................................................1244.2.13. Tính tiện dụng................................................................................................124

4.3. Thiết k ế tổng quan ..................................................................................................1254.4. Một số vấn đề cần quan tâm trong thiết k ế chi tiết và viết mã ...............................126

4.4.1. Kiến trúc ứng dụng ..........................................................................................1274.4.2. Xem xét sử dụng ngôn ngữ lậ p trình ...............................................................1304.4.3. Vấn đề phụ thuộc của công việc vào môi tr ườ ng hệ thống..............................1314.4.4. Đồ hình công việc............................................................................................132

4.5. Triển khai cài đặt các Grid Service.........................................................................133



Mục lục

- vi -

4.5.1. Các bướ c xây dựng và triển khai Grid Service................................................1344.5.2. Xây dựng client................................................................................................140

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

5.1. Quản tr ị mạng .........................................................................................................1425.1.1. Khái niệm.........................................................................................................1425.1.2. Các l ĩ nh vực quản tr ị mạng..............................................................................142

5.2. Hệ thống quản tr ị mạng ..........................................................................................1445.2.1. Mô hình và hoạt động ......................................................................................1445.2.2. Một số chức năng cơ bản của một hệ thống quản tr ị mạng .............................1465.2.3. Hệ thống quản tr ị mạng trong thực tế ..............................................................148

5.3. Hệ thống Intrusion Detection System (IDS)...........................................................1495.3.1. Khái niệm.........................................................................................................1495.3.2. Các hướ ng tiế p cận ..........................................................................................149

5.4. Giớ i thiệu một số công cụ hỗ tr ợ quản tr ị mạng .....................................................150

5.4.1. Ethereal ............................................................................................................1505.4.2. Snort.................................................................................................................152

Chươ ng 6. Hệ thống quản tr ị Grid NetManager.........................................153

6.1. Giớ i thiệu ý tưở ng...................................................................................................1536.2. Yêu cầu chức năng của một hệ thống quản tr ị mạng..............................................1546.3. Mô hình thành phần và hoạt động của hệ thống.....................................................155

6.3.1. Mô hình thành phần .........................................................................................1556.3.2. Cách thức hoạt động ........................................................................................157

6.4. Phân tích và định hướ ng phát triển ứng dụng.........................................................1586.5. Giớ i hạn vấn đề thực hiện của luận văn..................................................................159

Chươ ng 7. Phân tích, thiết k ế và cài đặt thử nghiệm ứng dụng .................161

7.1. Phân tích .................................................................................................................1617.1.1. Ngữ cảnh hệ thống...........................................................................................1617.1.2. Lượ c đồ Use Case............................................................................................1627.1.3. Đặc tả Use Case ...............................................................................................1637.1.4. Mô tả các dòng sự kiện....................................................................................167

7.2. Thiết k ế ...................................................................................................................1797.2.1. Sơ đồ các đối tượ ng cài đặt..............................................................................1797.2.2. Thiết k ế giao diện ............................................................................................180

7.3. Cài đặt & Triển khai ...............................................................................................1837.3.1. Công cụ và môi tr ườ ng phát triển ứng dụng....................................................1837.3.2. Mô hình cài đặt ................................................................................................1847.3.3. Mô hình triển khai............................................................................................1847.3.4. Thử nghiệm......................................................................................................185

Chươ ng 8. K ết luận.....................................................................................186

8.1. Đánh giá..................................................................................................................1868.1.1. Về luận văn ......................................................................................................1868.1.2. Về ứng dụng.....................................................................................................186

8.2. Hướ ng phát triển, mở r ộng của luận văn ................................................................187

8.2.1. Về luận văn ......................................................................................................187



Mục lục

- vii -

8.2.2. Về ứng dụng.....................................................................................................1878.3. Lờ i k ết.....................................................................................................................188

Phụ lục...........................................................................................................189

A. Các tiêu chí đánh giá tính khả khi của một dự án Grid.............................................189B. Định dạng file GWSDL ............................................................................................191C. K ỹ thuật cài đặt các chức năng cơ bản của Grid Service..........................................193

C.1. K ỹ thuật cài đặt Operation Provider...................................................................193C.2. Thêm thành phần dữ liệu (Service Data Element (SDE))..................................196C.3. Cài đặt cơ chế Notification.................................................................................199C.7. Cài đặt k ỹ thuật tạo service động (Transient service)........................................202C.5. K ỹ thuật Logging (Ghi vết)................................................................................205C.6. K ỹ thuật quản lý chu trình sống của service (Lifecycle Management)..............206

D. Các interface của một OGSI Service ........................................................................208E. Cấu trúc một chứng chỉ điện tử .................................................................................211

Tài liệu tham khảo.........................................................................................213

Các Website...................................................................................................216



Danh sách hình

- viii -

DDaannhh ssáácchh hhììnnhh

Hình 2-1 Tài nguyên Grid dướ i quan điểm của ngườ i dùng, là một khối thống nhất có đượ c

nhờ sự ảo hoá. ................................................................................................................9Hình 2-2 Hình thức hoạt động của Grid Tính toán..............................................................10Hình 2-3 Các đồ hình Grid. .................................................................................................11Hình 2-4 Đồ hình SimpleGrid .............................................................................................12Hình 2-5 Đồ hình IntraGrid .................................................................................................13Hình 2-6 Đồ hình ExtraGrid ................................................................................................14Hình 2-7 Các minh họa về đồ hình InterGrid......................................................................15Hình 2-8 Kiến trúc Grid tổng quát.......................................................................................29Hình 2-9 Quan điểm của các lậ p trình viên về kiến trúc Grid............................................34Hình 2-10 Kiến trúc Grid trong thực tế vớ i các thành phần. ...............................................35Hình 2-11 Các dự án Grid tươ ng ứng vớ i các tầng..............................................................36Hình 2-12 Mối quan hệ giữa các chuẩn về Grid Service.....................................................39Hình 2-13 Mô hình kiến trúc hoạt động của UNICORE .....................................................41Hình 2-14 Kiến trúc của Legion. .........................................................................................44Hình 2-15 Kiến trúc GridBus...............................................................................................46Hình 2-16 So sánh giữa UNICORE, Globus, Legion và GridBus. .....................................49Hình 3-1 Các thành phần của kiến trúc SOA.......................................................................54Hình 3-2 Kiến trúc của bộ Globus Toolkit. .........................................................................75Hình 3-3 Mô hình các thành phần của một hệ thống sử dụng GT2.....................................76Hình 3-4 Mô hình tổ chức các thành phần GT3. .................................................................77Hình 3-5 Các thành phần của GSI. ......................................................................................80

Hình 3-6 Quy trình khở i tạo để sử dụng GSI.......................................................................87Hình 3-7 Thủ tục chứng thực và phân quyền vớ i GSI.........................................................88Hình 3-8 Cơ chế ủy quyền trong GSI. .................................................................................89Hình 3-9 Thủ tục uỷ quyền của một proxy trong GSI.........................................................90Hình 3-10 Kiến trúc quản lý tài nguyên trong Globus Toolkit............................................95Hình 3-11 Các tr ạng thái của một công việc. ......................................................................98Hình 3-12 Các thành phần và cơ chế hoạt động của pre-WS GRAM .................................99Hình 3-13 Cơ chế hoạt động có DUROC trong pre-WS GRAM. .....................................101Hình 3-14 Các thành phần và cơ chế hoạt động của WS-GRAM. ...................................105Hình 3-15 Mô hình quản lý thông tin trong Grid của Globus Toolkit...............................107Hình 3-16 Ví dụ tổ chức dữ liệu của MDS2. .....................................................................109

Hình 3-17 Mô hình tổ chức dữ liệu phân cấ p trong MDS2...............................................110Hình 3-18 Các thành phần và cơ chế hoạt động của MDS2.............................................111Hình 4-1 Luồng ứng dụng song song. ...............................................................................128Hình 4-2 Luồng ứng dụng tuần tự. ....................................................................................128Hình 4-3 Luồng ứng dụng mạng........................................................................................129Hình 4-4 Các file cần thiết để triển khai Grid Service vớ i Ant. ........................................139Hình 5-1 Mô hình hệ thống quản tr ị mạng ........................................................................144Hình 5-2 Màn hình giao diện Ethereal...............................................................................151Hình 6-1 Mô hình thành phần ứng dụng Grid NetManager. .............................................155Hình 6-2 Mô hình các thành phần của ứng dụng Grid NetManager thử nghiệm. .............160Hình 7-1 Ngữ cảnh hệ thống..............................................................................................161

Hình 7-2 Sơ đồ Usecase ứng dụng Grid NetManager thử nghiệm....................................162





Danh sách bảng

- x -

DDaannhh ssáácchh bbảảnngg

Bảng 2-1 Các đặc tính của tài nguyên. ................................................................................16

Bảng 2-2 Bảng so sánh các đặc tính của các middleware ...................................................50Bảng 3-1 Bảng các interface chuẩn quy định bở i OGSA. ...................................................61Bảng 3-2 Các thuộc tính cơ bản của một service data.........................................................72Bảng 3-3 Các file cấu hình GSI của GT3. ...........................................................................92Bảng 3-4 Bảng các công cụ cấu hình GSI. ..........................................................................93Bảng 3-5 Bảng các hàm API về GSI của GT3 ....................................................................94Bảng 3-6 Bảng các hàm API của pre-WS GRAM.............................................................102Bảng 3-7 Các thành phần của GT Core .............................................................................114Bảng 6-1 Các thành phần của ứng dụng Grid NetManager...............................................156Bảng 7-1 Danh sách các actor............................................................................................162Bảng 7-2 Danh sách các usecase .......................................................................................162Bảng 7-3 Danh sách các đối tượ ng cài đặt. .......................................................................180Bảng 7-4 Danh sách các giao diện.....................................................................................180Bảng 7-5 Mô tả màn hình chính. .......................................................................................182Bảng 7-6 Mô tả màn hình cấu hình bắt packet. .................................................................183Bảng 7-7 Các thành phần triển khai...................................................................................184Bảng 8-1 Các tiêu chí đánh giá tính khả thi của ứng dụng Grid........................................190Bảng 8-2 Các hàm callback trong GT3. ............................................................................206Bảng 8-3 Các interface của một OGSI Service .................................................................211



Một số thuật ngữ

- xi -

MMộộtt ssốố tthhuuậậtt nnggữữ

Capture filter Các tiêu chuẩn lọc packet.Client Máy khách, sử dụng dịch vụ.Factory Là một thành phần tạo lậ p và quản lý các Grid

service instance.Grid Là một hệ thống tính toán sử dụng công nghệ

Grid ComputingGrid Computing Công nghệ tính toán lướ i.Grid service instance Một thể hiện của Grid service.Hosting environment Môi tr ườ ng mà trên đó các Grid Service có thể

thực thi.

Interface (OGSA) Giao diện của một OGSA Service.Lifecyle Chu trình sống của Grid ServiceMiddleware Là phần mềm cho phép tổ chức, tích hợ p các tài

nguyên và các chức năng vào GridNode, Host Là một nút của Grid, có thể là các máy tính hay

các thiết bị tính toán khác.Protocol Các giao thức quy định các thức liên lạc giữa các

thành phần thông qua hệ thống mạng.Proxy Là một thành phần đại diện cho ngườ i dùng Grid

thực thi các tác vụ.Server Máy chủ, cung cấ p dịch vụ.Service, Gridservice(OGSA),

Một dịch vụ Grid theo khái niệm đưa ra bở iOGSA.

Service data Thành phần dữ liệu của một ServiceSite Là một đơ n vị tham gia đóng góp tài nguyên cho

Grid, có hệ thống quản tr ị riêng.User Ngườ i sử dụng dịch vụ GridVirtual Organization Tổ chức ảo, là một liên minh tạm thờ i giữa các tổ

chức trong Grid dùng để chia sẽ tài nguyên.



Các chữ viết tắt

- xii -

CCáácc cchhữữ vviiếếtt ttắắtt

CA Certificate AuthorityDN Distinguished NameEJB Enterprise JavaBeansGGF Global Grid ForumGSH Grid Service HandleGSI Grid Security InfrastructureGSR Grid Service ReferanceGT{x} Globus Toolkit Version xGWSDL Grid Web Services Description LanguageMDS Metacomputing Directory ServiceOGSA Open Grid Services ArchitectureOGSI Open Grid Services InfrastructurePKI Public Key InfrastructureRA Registrant AuthoritySDE Service Data ElementSOA Service Oriented ArchitetureSSL Secure Sockets Layer URI Uniform Resource Indicator WSDL Web Services Description LanguageWSRF Web Services Resource Framework



Tóm tắt luận văn

- xiii -

TTóómm ttắắtt lluuậậnn vvăănn

1. Thông tin chung về đề tài:

Tên đề tài :“Tìm hiểu công nghệ Grid Computing và ứ ng dụng thử nghiệm

trong bài toán quản trị mạng”GVHD: Thầy CAO ĐĂNG TÂN.

Sinh viên thự c hi ệ n:

1. MSSV : 0112132 Họ và tên : Nguyễn Mạnh Dũng.2. MSSV : 0112280 Họ và tên : Nguyễn Đăng Thành.

2. Tóm tắt nội dung luận văn Luận văn thực hiện nghiên cứu tìm hiểu các vấn đề chung của công nghệ Grid

Computing như bản chất, các thách thức, yêu cầu, kiến trúc, ích lợ i, các chuẩn liên

quan, cũng như các dự án chính về cơ sở hạ tầng Grid nhằm đưa ra một tầm nhìn

tổng quan về công nghệ Grid Computing hiện nay.

Tìm hiểu về mô hình, hoạt động các thành phần, chi tiết các chuẩn sử dụng, một

số vấn đề khi phát triển ứng dụng Grid vớ i bộ Globus Toolkit phiên bản 3.2.

Nghiên cứu, tìm hiểu l ĩ nh vực quản tr ị mạng và các hệ thống quản tr ị, các hệ

thống phát hiện xâm nhậ p, từ đó đề xuất mô hình ứng dụng hệ thống quản tr ị mạng

sử dụng công nghệ Grid Computing làm nền tảng tính toán và tiến hành cài đặt thử

nghiệm một số chức năng của ứng dụng.

3. Một số từ khoá liên quan đến tài

Grid, Grid computing, Globus, Grid sevice, network management, tính toán

lướ i, …

4. L ĩ nh vự c áp dụng

Tính toán lướ i.

Quản tr ị mạng.

5. Các thuật toán, phươ ng pháp, quy trình chính đượ c nghiên cứ u, ứ ngdụng trong đề tài

6. Các công cụ, công nghệ chính đượ c nghiên cứ u, ứ ng dụng trong đề tài









Chươ ng 1. Mở đầu

- 3 -

thay đổi cách thức trao đổi thông tin trong thế k ỷ XX. Công nghệ Grid Computing

đã mở ra cơ hội mớ i cho các nướ c không có nền công nghiệ p thiết k ế, chế tạo phần

cứng máy tính mạnh, tạo ra các siêu máy tính để giải quyết các bài toán của riêng

mình vớ i chi phí thấ p và độ làm chủ cao. Ở Việt Nam, nhu cầu ứng dụng công nghệ

thông tin vào các hoạt động nghiên cứu Khoa học-K ỹ thuật, quản lý Kinh tế-Xã hội

ngày càng cao, đòi hỏi phải xử lý những khối lượ ng dữ liệu lớ n, khối lượ ng tính

toán khổng lồ vớ i chi phí thấ p (vì chúng ta còn nghèo, kinh phí đầu tư cho ngành

Công nghệ thông tin chưa cao). Do đó, việc nghiên cứu, phát triển ứng dụng công

nghệ Grid Computing vào thực tế đượ c xem là một giải pháp quan tr ọng để giải

quyết các bài toán trên. Hiện nay, chúng ta mớ i đang đi những bướ c đầu tiên…

11..22.. VVấấnn đđềề qquuảảnn ttr r ịị mmạạnngg

Ngày nay, mạng máy tính đã tr ở nên phổ biến khắ p nơ i vớ i quy mô ngày càng

lớ n. Do đó, công việc của bộ phận quản tr ị hệ thống mạng, đảm bảo cho hệ thống

hoạt động ổn định, hiệu năng cao, đáp ứng nhu cầu ngườ i dùng là một công việc hết

sức khó khăn. Để thực hiện tốt công việc của mình, bộ phận quản tr ị cần một hệ

thống theo dõi, giám sát các hoạt động trên mạng nhằm :

Xác định các lỗi thiết bị, cấu hình trong hệ thống mạng.

Tối ưu, quản lý hiệu quả tài nguyên mạng

Lậ p tài liệu về các mức độ đe doạ đối vớ i hệ thống, để lậ p k ế hoạch đối

phó, giảm thiểu nguy cơ hệ thống bị xâm hại.

Quản lý thông tin hoạt động của ngườ i dùng, phát hiện và ngăn chặn các

hoạt động xâm phạm hệ thống mạng.

Công việc quản lý trên đòi hỏi không những phải phân tích dữ liệu chạy trong hệ

thống mạng theo thờ i gian thực mà còn phải phân tích các dữ liệu ghi vết (log) về

các hoạt động trong hệ thống. Hiện nay, lượ ng dữ liệu lưu thông trong mạng máy

tính là r ất lớ n, nên 1 máy tính PC không thể thu thậ p và xử lý đượ c mà cần một máy

lớ n hoặc các thiết bị chuyên dụng hơ n. Việc đưa vào sử dụng các thiết bị chuyên

dụng có chi phí r ất cao, không thích hợ p cho các hệ thống mạng vừa và nhỏ. Do đó,

hướ ng tiế p cận sử dụng công nghệ Grid Computing để tận dụng thờ i gian nhàn r ỗi



Chươ ng 1. Mở đầu

- 4 -

của các máy PC trong hệ thống mạng để xử lý thông tin, hỗ tr ợ các nhà quản tr ị

mạng đượ c đưa ra.

11..33.. MMụụcc ttiiêêuu đđềề ttààii Nhằm tìm hiểu, góp phần vào việc phát triển và ứng dụng công nghệ Grid

Computing vào thực tiễn, đề tài:

“Tìm hiểu công nghệ Grid Computing và ứ ng dụng thử nghiệm trong

bài toán quản trị mạng”

đượ c thực hiện vớ i một số mục tiêu:

+ Tìm hiểu về công nghệ Grid Computing hiện nay để có một bức tranh tổngquan về công nghệ, các vấn đề, các hướ ng giải quyết chủ yếu của nó nhằm làm tiền

đề tham khảo cho việc ứng dụng, phát triển công nghệ Grid trong tươ ng lai.

+ Cài đặt, tìm hiểu mô hình, kiến trúc, môi tr ườ ng, cách thức lậ p trình và

phát triển ứng dụng của bộ Globus Toolkit, một bộ công cụ xây dựng Grid hàng đầu

hiện nay.

+ Tìm hiểu về quản tr ị mạng và các hệ thống quản tr ị mạng.

+ Nghiên cứu và đề xuất mô hình hệ thống quản tr ị mạng trên nền tảng công

nghệ Grid Computing. Xây dựng thử nghiệm một số chức năng điển hình của hệ

thống quản tr ị để hiểu biết thêm về k ỹ thuật xây dựng và phát triển ứng dụng Grid.

Hệ thống quản tr ị mạng chỉ là một công cụ hỗ tr ợ , việc sử dụng thông tin, thiết lậ p

các chiến lượ c, chính sách quản tr ị là nhiệm vụ của các nhà quản tr ị mạng.

Các chươ ng tiế p theo trình bày những vấn đề đã nghiên cứu, tìm hiểu đượ c.



Chươ ng 2. Tổng quan về công nghệ Grid Computing

- 5 -

CChhưươơnngg 22.. TTổổnngg qquuaann vvềề ccôônngg nngghhệệ GGr r iidd

CCoommppuuttiinngg 22..11.. KKhhááii nniiệệmm GGr r iidd

22..11..11.. TThheeoo ddòònngg llịịcchh ssử ử

Mặc dù công nghệ Grid Computing đượ c nhắc đến r ất nhiều trong thờ i gian gần

đây, nhưng thực ra nhiều ý tưở ng cơ bản về Grid đã xuất hiện dướ i dạng này hay

dạng khác trong lịch sử tính toán.

Ví dụ như ý tưở ng “chia sẻ năng lực tính toán” đã xuất hiện từ những năm 60-

70 của thế k ỷ XX, lúc đó toàn bộ năng lực tính toán đượ c chia sẻ từ các máy

mainframe.

Năm 1965, những ngườ i phát triển hệ điều hành Multics (tiền thân của hệ điều

hành Unix) đã đề cậ p đến việc sử dụng năng lực tính toán như là một tiện ích, một

quan điểm r ất gần vớ i quan điểm về Grid hiện nay. Đó là một hệ thống cung cấ pnăng lực tính toán tươ ng tự như hệ thống cung cấ p điện, nướ c hiện đang đượ c sử

dụng trong cuộc sống hàng ngày. Ngườ i dùng khi muốn sử dụng tài nguyên tính

toán để xử lý công việc, chỉ cần cắm thiết bị vào hệ thống cung cấ p, sử dụng và tr ả

tiền giống như khi cắm thiết bị điện vào lướ i điện.

Tuy tr ướ c đó đã có nhiều ý tưở ng về Grid nhưng nguồn gốc của Grid chính thức

đượ c xác định vào năm 1990, khi thuật ngữ “siêu tính toán” (metacomputing) ra

đờ i, dùng để mô tả các dự án k ết nối các trung tâm siêu máy tính của Mỹ nhằm k ếthợ p sức mạnh xử lý của nhiều siêu máy tính lại vớ i nhau.

Đến năm 1995, 2 dự án siêu tính toán quan tr ọng, ảnh hưở ng lớ n đến các công

nghệ nền tảng trong các dự án Grid ngày nay là FAFNER (Factoring via

Network-Enabled Recursion) và I-WAY(Information Wide Area Year) ra đờ i.

Khái niệm Grid ra đờ i ở phòng thí nghiệm Argonne National Laboratory vào

tháng 7/1997, sau đó đượ c đưa vào quyển sách "The Grid: Blueprint for a New

Computing Infrastructure" viết bở i tiến sỹ Ian Foster (Argonne National






- 7 -

2. Sử dụng các giao diện và giao thứ c chuẩn, mang tính mở , đa dụng.

Grid đượ c xây dựng trên các giao thức và giao diện tổng quát, đa dụng để

giải quyết các vấn đề cơ bản như chứng thực ngườ i dùng, phân quyền, tìm kiếm và

truy xuất tài nguyên.

3. Đáp ứ ng yêu cầu cao về chất lượ ng dịch vụ.

Grid cho phép sử dụng phối hợ p các tài nguyên để cung cấ p nhiều loại

dịch vụ vớ i các mức chất lượ ng khác nhau, liên quan đến ví dụ như thờ i gian đáp

ứng, hiệu suất, tính sẵn sàng, bảo mật, cho phép k ết hợ p nhiều kiểu tài nguyên để

đáp ứng nhu cầu phức tạ p của ngườ i dùng. Mục tiêu là phải phối hợ p làm sao để

khả năng của hệ thống sau khi k ết hợ p phải lớ n hơ n hẳn tổng khả năng của từng đơ nvị cấu thành nên Grid.

22..11..33.. TTààii nngguuyyêênn ccủủaa GGrriidd

Các tài nguyên của Grid bao gồm các loại sau

22..11..33..11.. TTààii nngguuyyêênn ttí í nnhh ttooáánn

Đây là tài nguyên phổ biến nhất, là các chu k ỳ tính toán (computing cycles)đượ c cung cấ p bở i bộ vi xử lý của các thiết bị trong Grid. Các bộ vi xử lý không cần

phải cùng loại mà có thể có tốc độ, kiến trúc, chạy phần mềm khác nhau.

Có 3 cách để khai thác tài nguyên tính toán của Grid:

1. Cách đơ n giản nhất là chạy các ứng dụng hiện có trên một node của Grid

thay vì chạy trên máy tính cục bộ.

2. Thiết k ế ứng dụng, tách các công việc thành các phần riêng r ẽ để có thể

thực thi song song trên nhiều bộ xử lý khác nhau.

3. Chạy ứng dụng thực thi nhiều lần trên nhiều node khác nhau trong Grid.

22..11..33..22.. TTààii nngguuyyêênn llư ư uu ttrrữ ữ

Tài nguyên phổ biến thứ nhì trong Grid là tài nguyên lưu tr ữ. Mỗi thiết bị trong

Grid thườ ng cung cấ p một số dung lượ ng lưu tr ữ phục vụ cho việc thực thi ứng

dụng trên Grid. Tài nguyên lưu tr ữ có thể là bộ nhớ trong, ổ đĩ a cứng hoặc các thiết

bị lưu tr ữ khác. Bộ nhớ trong thườ ng dùng để lưu tr ữ dữ liệu tạm thờ i cho ứng






- 9 -

chức, ở nhiều nơ i khác nhau. Một số tài nguyên có thể đượ c sử dụng tự do, trong

khi một số khác đượ c sử dụng dướ i những chính sách nhất định. Các tài nguyên

đượ c “ảo hóa” (virtualize) để che dấu sự phức tạ p, đa dạng nhằm đưa ra một cái

nhìn thống nhất, đơ n giản về toàn bộ tài nguyên trên Grid sao cho dướ i mắt của

ngườ i dùng, các tài nguyên Grid là một khối thống nhất. Hình 2-1 minh hoạ ý tưở ng

này.

Hình 2-1 Tài nguyên Grid dướ i quan điểm của ngườ i dùng, là mộtkhối thống nhất có đượ c nhờ sự ảo hoá.

Các tài nguyên ảo đượ c tổ chức lại thành các “tổ chức ảo”, đến lượ t nó, các tổ

chức ảo lại thực hiện chia sẻ tài nguyên của mình để hình thành Grid lớ n hơ n, tạo

thành một kho tài nguyên khổng lồ.

22..22.. PPhhâânn llooạạii GGr r iidd && GGr r iidd TTooppoollooggyy

22..22..11.. CCáácc k k iiểểuu GGrriidd

Công nghệ Grid Computing có thể đượ c sử dụng theo nhiều cách khác nhau để

giải quyết các loại yêu cầu ứng dụng. Thông thườ ng Grid đượ c phân loại bở i kiểu

của ứng dụng cần giải quyết. Có 3 loại Grid như trình bày dướ i đây. Tuy nhiên

không có ranh giớ i phân biệt rõ ràng giữa các loại Grid và trong thực tế, các giải

pháp Grid thườ ng là sự k ết hợ p 2 hay nhiều loại khác nhau.




- 10 -

22..22..11..11.. GGrriidd TTí í nnhh ttooáánn ((CCoommppuuttaattiioonn GGrriidd))

Loại Grid này tậ p trung chủ yếu vào việc sử dụng năng lực tính toán. Ở dạng

Grid này, phần lớ n các node là các máy tính hay các nhóm máy tính(cluster) cónăng lực xử lý, tính toán r ất lớ n.

Hình thức thực hiện là chia tác vụ tính toán lớ n thành nhiều công việc nhỏ thực

thi song song trên các node của Grid. Việc phân tán các tác vụ tính toán trong Grid

sẽ làm giảm r ất đáng k ể toàn bộ thờ i gian xử lý và tăng khả năng tận dụng hệ thống.

Thông thườ ng một hệ thống chính sẽ chia khối dữ liệu cần xử lý thành các phần

nhỏ, sau đó phân phối đến các node trên Grid. Mỗi node sẽ thực hiện xử lý dữ liệu

và tr ả k ết quả về hệ thống chính để hệ này tổng hợ p và trình diễn k ết quả toàn cụccho ngườ i dùng. Hình 2-2 minh họa quá trình này.

Hình 2-2 Hình thứ c hoạt động của Grid Tính toán

22..22..11..22.. GGrriidd DDữ ữ lliiệệuu ((DDaattaa GGrriidd))

Ở đây, không gian lưu tr ữ là tài nguyên. Một Grid Dữ liệu chịu trách nhiệm

lưu tr ữ và cung cấ p khả năng truy cậ p dữ liệu cho nhiều tổ chức khác nhau. Ngườ i

dùng không cần biết chính xác vị trí dữ liệu khi thao tác vớ i dữ liệu.

Các cơ sở dữ liệu, đặc biệt các cơ sở dữ liệu liên hợ p, đóng vai trò quan

tr ọng trong các Grid Dữ liệu, nhất là khi có nhiều nguồn dữ liệu và xuất hiện nhu

cầu k ết hợ p các thông tin từ các nguồn dữ liệu này.




- 11 -

Các Grid Dữ liệu có thể đượ c sử dụng trong l ĩ nh vực khai thác dữ liệu(data

mining) hoặc các hệ thống thươ ng mại thông minh. Trong tr ườ ng hợ p này, không

chỉ có hệ thống file hay các cơ sở dữ liệu mà toàn bộ dữ liệu của tổ chức cần tậ p

hợ p lại. Ở đây có thể phải k ết hợ p giữa Grid Dữ liệu và Grid Tính toán.

22..22..11..33.. SSccaavveennggiinngg GGrriidd

Một Scavenging Grid thườ ng đượ c dùng vớ i một lượ ng lớ n các máy tính để

bàn. Các máy tính thườ ng đượ c kiểm tra định k ỳ để xem khi nào bộ xử lý và các tài

nguyên khác r ảnh r ỗi để thực hiện các tác vụ Grid. Chủ nhân của máy để bàn

thườ ng có quyền xác định khi nào thì chia sẻ chiếc máy của mình.

22..22..22.. ĐĐồồ hh ì ìnnhh GGrriidd ((GGrriidd TTooppoollooggyy))

Grid có thể đượ c xây dựng theo nhiều kích cỡ khác nhau, từ một nhóm vài máy

tính đặt trong một phòng ban đến hàng tr ăm nhóm máy tính tổ chức theo kiểu phân

cấ p tr ải r ộng khắ p thế giớ i. Đồ hình Grid đơ n giản nhất là SimpleGrid, chỉ bao gồm

một số máy tính đồng nhất ở cùng một vị trí. Độ phức tạ p của đồ hình Grid tươ ng

ứng vớ i số lượ ng tổ chức tham gia Grid và các ràng buộc về địa lý. Phần này sẽ giớ ithiệu sơ nét về một số đồ hình Grid cơ bản. Hình 2-3 cho thấy độ lớ n của các đồ

hình Grid.

Hình 2-3 Các đồ hình Grid.




- 12 -

22..22..22..11.. SSiimmpplleeGGrriidd

Hình 2-4 Đồ hình SimpleGrid

Như trên hình 2-4, một SimpleGrid chỉ bao gồm vài máy tính, tất cả đều có cùng

kiến trúc phần cứng, chạy cùng một hệ điều hành, k ết nối vào mạng cục bộ. Dạng

Grid này sử dụng các hệ thống đồng nhất nên ít phức tạ p, thườ ng chỉ dùng để thử nghiệm, làm quen vớ i các phần mềm Grid. Các máy tính thuộc một phòng ban trong

tổ chức nên việc sử dụng chúng cho Grid không cần các chính sách đặc biệt về quản

lý cũng như bảo mật. Các máy tính chạy cùng hệ điều hành, cùng kiến trúc phần

cứng nên việc chọn các phần mềm ứng dụng khá đơ n giản, dễ dàng. Đồ hình này

khiến ngườ i ta liên tưở ng đến các cluster hơ n là Grid.




- 13 -

22..22..22..22.. IInnttrraaGGrriidd

Hình 2-5 mô tả một Intra Grid.

Hình 2-5 Đồ hình IntraGrid

Mở r ộng hơ n một chút so vớ i SimpleGrid là IntraGrid. Lúc này xuất hiện các hệ

thống không đồng nhất, nhiều loại tài nguyên mớ i trong Grid. Sử dụng cùng một

chính sách bảo mật, sử dụng mạng nội bộ để k ết nối các hệ thống trong Grid là các

đặc tính quan tr ọng của đồ hình này.

Hệ thống Grid cần có các module lậ p lịch. Việc chia sẻ file có thể sử dụng các

hệ thống file mạng (network filesytem). Các máy tính tham gia Grid có thể thuộc

nhiều phòng ban khác nhau nhưng vẫn trong cùng một tổ chức.

Khi Grid mở r ộng ra nhiều phòng ban, các chính sách mớ i về cách sử dụng Grid

cần phải đượ c xác lậ p và áp dụng. Ví dụ: cần phải có chính sách quy định những

công việc nào đượ c thực hiện trên Grid, vào thờ i điểm nào; độ ưu tiên của các

phòng ban,… Bên cạnh đó vấn đề bảo mật cũng cần đượ c quan tâm, các dữ liệunhạy cảm của một phòng ban cần đượ c bảo vệ khỏi sự truy cậ p từ các công việc của

các phòng ban khác.

Các máy tính dành riêng cho Grid bắt đầu đượ c đưa vào để làm tăng chất lượ ng

dịch vụ của Grid, thay vì phải trông chờ vào các tài nguyên r ảnh r ỗi.




- 14 -

22..22..22..33.. EExxttrraaGGrriidd

Vẫn trong cùng một tổ chức, ExtraGrid là sự k ết hợ p 2 hay nhiều IntraGrid. Như

trong hình 2-6, ExtraGrid liên quan đến nhiều vùng quản lý khác nhau, phân tántheo địa lý, sử dụng các k ết nối truy cậ p từ xa hay WAN, do đó độ phức tạ p trong

quản lý tăng lên r ất nhiều. Đối vớ i ExtraGrid, các tài nguyên mang tính động hơ n,

Grid cần phải linh động trong việc quản lý các tài nguyên, cần có cơ chế kiểm soát

và phục hồi lỗi.

Cần có các dịch vụ cung cấ p thông tin (information service) để tìm kiếm tài

nguyên.

Hình 2-6 Đồ hình ExtraGrid

22..22..22..44.. IInntteerrGGrriidd

Theo thờ i gian, các Grid mở r ộng ra khỏi một tổ chức và bắt đầu liên k ết nhiều

tổ chức vớ i nhau, đượ c dùng để phối hợ p giữa các tổ chức trong các dự án lớ n. Một

InterGrid đòi hỏi việc liên k ết động các ứng dụng, tài nguyên và dịch vụ. Kháchhàng hay bất k ỳ tổ chức hợ p lệ nào khác đều có thể truy cậ p Grid thông qua các k ết

nối Internet và WAN.

Trong dạng Grid này, cấ p độ bảo mật cao nhất cần đượ c áp dụng để ngăn ngừa

các khả năng bị tấn công và gián điệ p. InterGrid cung cấ p khả năng trao đổi, mua

bán, tìm kiếm tài nguyên ở mức toàn cầu. Các tài nguyên có thể đượ c mua từ các

nhà cung cấ p tin cậy.

Hình 2-7 minh hoạ các InterGrid.




- 15 -

Hình 2-7 Các minh họa về đồ hình InterGrid.

22..33.. CCáácc tthháácchh tthhứứcc,, yyêêuu ccầầuu ccủủaa ccôônngg nngghhệệ GGr r iidd

22..33..11.. QQuuảảnn llýý ttààii nngguuyyêênn ((R R eessoouurrccee MMaannaaggeemmeenntt))

Mục tiêu của công nghệ Grid Computing là chia sẻ, phối hợ p, sử dụng hiệu quả

nhiều loại tài nguyên đến từ nhiều nguồn khác nhau. Để thực hiện đượ c điều đó, cần

phải giải quyết các thách thức và yêu cầu chính sau đây:

1. Tài nguyên thuộc nhiều vùng quản trị khác nhau

Các tài nguyên Grid phân tán theo địa lý qua nhiều vùng quản tr ị và đượ c sở

hữu và quản lý bở i nhiều tổ chức khác nhau. Không thể chờ đợ i một sự thống nhất

chung về các chính sách sử dụng, chia sẻ, bảo mật giữa các tổ chức. Grid cần phải

tôn tr ọng, tươ ng thích vớ i các chính sách quản tr ị và sử dụng tài nguyên cục bộ.

Cần có một cơ chế chia sẻ có tính mềm dẻo cao, từ mô hình client-server

đến peer-to-peer để kiểm soát chi tiết, chính xác cách sử dụng các tài nguyên chia

sẻ, bao gồm kiểm soát truy cậ p, ủy quyền, áp dụng các chính sách cục bộ và toàn

cục; để chia sẻ nhiều loại tài nguyên khác nhau từ các chươ ng trình, file, dữ liệu đến

các máy tính, sensor,…; và cho nhiều phươ ng thức sử dụng khác nhau từ đơ n ngườ i

dùng đến đa ngườ i dùng, từ hướ ng hiệu suất đến hướ ng chi phí, từ đó đưa ra mô

hình chất lượ ng dịch vụ, lậ p lịch, phối hợ p cấ p phát tài nguyên và thanh toán chi

phí.




- 16 -

Cần có cơ chế dàn xế p việc chia sẻ tài nguyên giữa các bên tham gia (bên

cung cấ p và bên sử dụng) hợ p lý. Việc chia sẻ này phải đượ c quản lý chặt chẽ và

đặc tả rõ ràng giữa các bên cung cấ p và sử dụng về những gì đượ c chia sẻ, ai đượ c

phép chia sẻ, ở điều kiện nào thì việc chia sẻ đượ c thực hiện.

2. Tài nguyên đa dạng, hỗn tạp

Grid phải quản lý nhiều tài nguyên không đồng nhất về bản chất, sử dụng

nhiều công nghệ, các hệ thống quản lý tài nguyên cục bộ khác nhau. Ngay cả khi có

2 site cùng sử dụng một công nghệ, một hệ quản lý tài nguyên cục bộ nhưng có cấu

hình khác nhau cũng dẫn đến có các chức năng khác nhau.

Dướ i đây là bảng đặc tính các đối tượ ng cần quản lý cho thấy sự phức tạ ptrong quản lý tài nguyên:

STT Đối Tượ ng Đặc tính

1. Ngườ i dùng, Ngườ icung cấ p

Phân tán theo địa lý

2. Tài nguyên Đa dạng, phân tán theo địa lý, thuộc nhiều vùng quảntr ị, sở hữu khác nhau.

3. Tính sẵn sàng vàkhả năng của tàinguyên

Thay đổi theo thờ i gian

4. Các chính sách vàchiến lượ c sử dụng

Đa dạng và không tậ p trung, nhà cung cấ p và ngườ idùng có các mục tiêu và chiến lượ c chia sẻ, sử dụngkhác nhau.

5. Yêu cầu chất lượ ngdịch vụ

Đa dạng

6. Chi phí/Giá cả Thay đổi tuỳ theo tài nguyên, ngườ i dùng, thờ i gian.7. Yêu cầu của ứng

dụng

Đa dạng về tốc độ xử lý, bộ nhớ , đòi hỏi về năng lực

lưu tr ữ, năng lực mạng.

Bảng 2-1 Các đặc tính của tài nguyên.

3. Việc tồn tại của tài nguyên trong Grid thay đổi theo thờ i gian

Trong Grid, các tài nguyên có thể xuất hiện hoặc biến mất mà không hề báo

tr ướ c do nhiều nguyên do khác nhau như lỗi hệ thống, lỗi mạng, các chính sách chia

sẻ của nhà cung cấ p,…Đây cũng là một thách thức lớ n để đảm bảo tính tin cậy của




- 17 -

hệ thống. Cần có các cơ chế tìm kiếm, xác định tài nguyên, phát hiện và phục hồi

lỗi.

4. Vấn đề phối hợ p cấp phát tài nguyên

Các ứng dụng có nhiều đòi hỏi về tài nguyên mà chỉ có thể đáp ứng bằng

cách sử dụng song song các tài nguyên trên nhiều site khác nhau. Các chính sách

quản tr ị cục bộ của các site cùng vớ i khả năng bị lỗi trong quá trình cấ p phát tài

nguyên đòi hỏi phải có các cơ chế đặc biệt để phối hợ p cấ p phát nhiều tài nguyên,

khở i tạo các quá trình tính toán, theo dõi, và quản lý chúng trên các tài nguyên.

5. Vấn đề điều khiển trự c tuyến, theo thờ i gian thự c (online)

Cần có cơ chế cho phép thoả thuận sử dụng tài nguyên trong thờ i gian thựcthi để đáp ứng nhu cầu của ứng dụng, nhất là trong tr ườ ng hợ p các yêu cầu và tính

chất các tài nguyên thay đổi trong quá trình thực thi.

22..33..22.. BBảảoo mmậậtt ((SSeeccuurriittyy))

Các hệ thống Grid cần phải cung cấ p đầy đủ các chức năng bảo mật truyền

thống như chứng thực, phân quyền, bảo vệ thông điệ p, toàn vẹn dữ liệu, … ngoài ra

cần đáp ứng các yêu cầu sau:

1. Đăng nhập một lần (Single sign-on)

Một tính toán đơ n giản cũng cần phải sử dụng nhiều tài nguyên khác nhau, vì

thế nếu cứ mỗi lần truy xuất tài nguyên lại cần phải chứng thực ngườ i dùng là điều

không thực tế và không thể chấ p nhận đượ c. Thay vào đó, hệ thống Grid cần có cơ

chế cho phép ngườ i dùng chỉ cần chứng thực một lần mà có thể sử dụng nhiều tài

nguyên khác nhau.2. Cho phép ủy quyền

Đây là một yêu cầu quan tr ọng, để thực hiện đượ c yêu cầu “đăng nhậ p một

lần” thì cần phải có sự uỷ quyền. Ngườ i dùng cần có khả năng uỷ quyền cho các

chươ ng trình sử dụng các quyền của mình, để chươ ng trình có thể truy cậ p đến các

tài nguyên đượ c phép khác của ngườ i dùng. Và chươ ng trình, đến lượ t nó cũng cần

có khả năng ủy quyền cho các chươ ng trình khác.

3. Có khả năng tích hợ p đượ c vớ i các chính sách bảo mật cục bộ




- 18 -

Mỗi site hoặc nhà cung cấ p tài nguyên đều có chính sách bảo mật riêng của

mình. Do đó, các giải pháp bảo mật trên Grid cần phải liên k ết đượ c vớ i các giải

pháp cục bộ, không đượ c thay thế toàn bộ các giải pháp này mà cho phép k ế thừa,

sử dụng lại.

4. Sử dụng các quan hệ tin cậy lẫn nhau dự a theo ngườ i dùng

Để cho phép ngườ i dùng sử dụng k ết hợ p tài nguyên từ nhiều nhà cung cấ p

khác nhau, hệ thống bảo mật không đượ c yêu cầu các nhà cung cấ p phải hợ p tác,

liên lạc vớ i nhau để thiết lậ p môi tr ườ ng bảo mật. Ví dụ, nếu ngườ i dùng có quyền

sử dụng 2 site A và B, thì ngườ i dùng cũng có thể sử dụng k ết hợ p 2 site A, B cùng

lúc mà không cần các chuyên gia bảo mật của site A, B liên lạc vớ i nhau.5. Hỗ trợ bảo mật liên lạc nhóm

Một quá trình tính toán đượ c cấu thành từ nhiều tiến trình khác nhau, những

tiến trình này cần phải liên lạc vớ i nhau theo từng nhóm. Các nhóm có thể thay đổi

trong suốt quá trình tính toán. Grid cần có giải pháp để thực hiện bảo mật cho các

nhóm này.

6. Đảm bảo tính riêng tư

Một trong những khả năng của Grid là cho phép xử lý dữ liệu trên máy tính ở

xa. Từ đây cũng nảy sinh vấn đề cần bảo vệ tính riêng tư của dữ liệu, sao cho các

ngườ i dùng hay nhà quản tr ị trên máy tính ở xa không thể xâm nhậ p, sử dụng các

dữ liệu đang đượ c xử lý trên máy tính của mình.

7. Cho phép có nhiều cài đặt khác nhau

Các giải pháp bảo mật không nên chỉ tậ p trung vào một cài đặt cụ thể mà nên

cài đặt theo nhiều công nghệ khác nhau dựa trên một nền tảng chung. Điều này đảm bảo tính tươ ng thích vớ i nhiều hệ thống khác nhau.

Ghi chú: Các giải pháp bảo mật trên Grid cũng nên cung cấ p sự hỗ tr ợ mềm dẻo

cho công tác bảo vệ liên lạc (ví dụ như điều khiển đượ c mức độ bảo vệ, bảo vệ các

gói dữ liệu trong các protocol không đảm bảo tính tin cậy (UDP), hỗ tr ợ các

protocol vận chuyển tin cậy khác ngoài TCP,…) và cho phép các nhà cung cấ p ra

quyết định về phân quyền cũng như hạn chế ủy quyền theo nhiều cách khác nhau.




- 19 -

22..33..33.. QQuuảảnn llýý tthhôônngg ttiinn

Hệ thống thông tin Grid cần có các cơ chế hỗ tr ợ việc truy cậ p, tìm kiếm

thông tin các loại về hệ thống Grid một cách nhanh chóng, chính xác. Cần có cácchức năng để xác định đặc tính phần cứng, phần mềm cũng như các thông tin tr ạng

thái như tải hiện tại và tr ạng thái hàng đợ i trong tr ườ ng hợ p tài nguyên đượ c lậ p lịch

sử dụng và có các cơ chế cung cấ p các thông tin này gần như theo thờ i gian thực.

Hệ thống thông tin cần hỗ tr ợ theo dõi thông tin của một lượ ng r ất lớ n các

thành phần, cho phép nhiều loại thực thể truy cậ p, tìm kiếm thông tin trong khi

giảm thiểu các chi phí về công sức và tài nguyên cần thiết để tạo lậ p, cậ p nhật các

thông tin cả ở từng site lẫn toàn bộ Grid.

Một trong những mục tiêu của hệ thống thông tin là đơ n giản hoá việc tìm

kiếm thông tin để ra các quyết định sử dụng tài nguyên thích hợ p, do đó hệ thống

thông tin cần phải đượ c xây dựng theo mô hình dữ liệu đơ n nhất (uniform), cung

cấ p một giao diện chung để truy xuất nhiều thông tin khác nhau,

Mô hình quản lý thông tin cần đủ bao quát để biểu diễn các cấu trúc thông tin

trong môi tr ườ ng tính toán phân tán. Một trong những thách thức là biểu diễn đượ c

các thuộc tính liên quan đến nhiều site cùng lúc (ví dụ như : băng thông liên lạc

giữa các site).

Do tài nguyên của Grid r ất đa dạng, có thể đượ c thêm bớ t theo thờ i gian, do

đó khả năng tích hợ p thêm các thông tin mớ i vào hệ thống là r ất quan tr ọng. Các hệ

thống thông tin Grid cần phải có khả năng này.

Các hệ thống thông tin Grid cần có khả năng phát sinh thông tin từ nhiều

nguồn khác nhau để cung cấ p các thông tin tổng hợ p về hệ thống. Đưa ra các cách thức truy xuất mềm dẻo đến hệ thống thông tin, ngườ i dùng

cần có khả năng đọc, cậ p nhật cùng vớ i khả năng tìm kiếm, định vị thông tin.

Hệ thống thông tin chỉ có thể hữu dụng khi nó đượ c triển khai r ộng rãi, do đó

cần có những k ỹ thuật cho phép cài đặt, triển khai, bảo trì dễ dàng trên các site khác

nhau.

Cần có mô hình quản lý thông tin phân tán, nên cho phép uỷ quyền tạo lậ p

và quản lý thông tin tài nguyên cho các site.




- 20 -

22..33..44.. QQuuảảnn llýý ddữ ữ lliiệệuu

Cần có mô hình quản lý dữ liệu phân tán, cho phép k ết hợ p dữ liệu từ nhiều

nơ i khác nhau, hệ thống quản lý dữ liệu cần có các cơ chế quản lý sao cho có thể che đi sự phức tạ p của dữ liệu, cung cấ p cho ngườ i dùng cách thức truy cậ p đơ n

giản, hiệu quả thông qua một giao diện chung mà không cần biết đến vị trí của dữ

liệu.

Cho phép sắ p xế p các vị trí dữ liệu và có cơ chế lậ p lịch truy xuất dữ liệu tối

ưu nhằm nâng cao hiệu suất của Grid.

Cần có cơ chế di chuyển dữ liệu đến nơ i xử lý mà không tạo ra hiệu ứng cổ

chai trong hệ thống mạng hoặc các vấn đề về truy xuất dữ liệu khác.

Cần có các cơ chế truyền file hiệu suất cao, đọc ghi một loạt các file hoặc các

chức năng chọn lựa, tinh giảm dữ liệu từ xa, các cơ chế điều khiển việc cấ p phát tài

nguyên phục vụ truyền dữ liệu (không gian, băng thông, CPU).

22..33..55.. PPhháátt ttrriiểểnn ứ ứ nngg ddụụnngg

Việc xây dựng Grid gặ p khó khăn hơ n nhiều so vớ i các ứng dụng bình

thườ ng hiện nay, cần phải đưa ra các mô hình, phươ ng pháp giải quyết các vấn đề

như chia sẻ, chia nhỏ, phân tích, di chuyển , bảo mật, quản lý, dữ liệu, đồng bộ hoá

các tiến trình, công việc,… nhằm tận dụng tối đa khả năng của hệ thống.

Cần xây dựng các mô hình, các môi tr ườ ng lậ p trình, các bộ công cụ phát

triển ứng dụng cho Grid nhằm đơ n giản hóa việc phát triển ứng dụng, tạo điều kiện

đưa công nghệ Grid Computing vào thực tế.

22..33..66.. CCáácc vvấấnn đđềề k k hháácc

Khi kích cỡ Grid tăng lên, chi phí quản lý cũng tăng theo, hiệu suất của Grid

cũng giảm xuống, do đó khi xây dựng các công nghệ Grid cần tính toán khả năng

mở r ộng của hệ thống.

Cần có các cơ chế quản lý tiến trình để đặt chỗ tr ướ c trên tài nguyên, khở i

động, kiểm soát, điều khiển việc thực thi của các tiến trình.




- 21 -

Về mã thực thi ứng dụng, dạng đặc biệt của tài nguyên lưu tr ữ này đòi hỏi

các cơ chế để quản lý phiên bản mã nguồn và mã thực thi của các đối tượ ng để đảm

bảo tính tươ ng thích.

Nguờ i dùng mong muốn có thể dùng môi tr ườ ng ảo của Grid vớ i chất lượ ng

gần giống như trên hệ thống cục bộ. Do đó, Grid cần phải cung cấ p các công cụ đơ n

giản để hỗ tr ợ ngườ i dùng để xác định các dịch vụ, số lượ ng và chất lượ ng (QoS )

của chúng, chất lượ ng trong tr ườ ng hợ p này liên quan đến khả năng truy cậ p dịch

vụ một cách nhanh chóng thông qua các giao diện hoàn hảo, các hệ thống chứng

thực thông minh và các đườ ng truyền tốc độ cao.

Cần có một hệ thống quản lý phân phối hợ p lý giữa các nhu cầu của ngườ idùng vớ i khả năng của tài nguyên, theo dõi việc sử dụng các dịch vụ, và cung cấ p

các dịch vụ cộng thêm khác như quản lý tài nguyên cục bộ, quản lý hiệu suất, tr ạng

thái tài nguyên, quản lý đăng nhậ p và bảo mật.

Cần có một giao diện chuẩn để chuyển các yêu cầu của ngườ i dùng và khả

năng của tài nguyên thành một ngôn ngữ duy nhất bất k ể nền tảng phần cứng, phần

mềm của mỗi tài nguyên phân tán nhằm mục đích phối hợ p hoạt động.

22..33..77.. CCáácc vviiệệcc ccầầnn llààmm

Các bướ c chung trong quá trình hiện thực hoá Grid:

1. Tích hợ p các thành phần phần cứ ng và phần mềm đơ n lẻ thành tài

nguyên k ết hợ p thông qua hệ thống mạng.

2. Xây dự ng và triển khai

+ Middleware cấ p thấ p để cung cấ p môi tr ườ ng truy cậ p bảo mật và trong

suốt đến các tài nguyên.

+ Middleware cấ p cao và các công cụ phục vụ k ết hợ p các tài nguyên

phân tán và phát triển ứng dụng.

3. Phát triển và tối ư u hoá các ứ ng dụng phân tán để tận dụng khả năng

tài nguyên và cơ sở hạ thầng.




- 22 -

22..44.. ÍÍcchh llợợii && ỨỨnngg ddụụnngg

Một số ích lợ i khi sử dụng công nghệ Grid Computing

1. Khai thác, tận dụng các tài nguyên nhàn rỗi. Hầu hết các tổ chức đều có một lượ ng lớ n các tài nguyên tính toán nhàn r ỗi,

các máy tính cá nhân thườ ng chỉ sử dụng hết 5% thờ i gian xử lý CPU, ngay cả các

server cũng thườ ng “r ảnh r ỗi”. Grid có thể tối ưu sử dụng các tài nguyên nhàn r ỗi

này theo nhiều cách khác nhau, ví dụ, gửi một công việc trên một máy tính đang

bận r ộn đến một máy khác r ảnh r ỗi hơ n để xử lý, hoặc phân nhỏ một công việc r ồi

gửi các công việc con đến các máy tính nhàn r ỗi khác cho xử lý song song,…

Grid cho phép k ết hợ p nhiều không gian lưu tr ữ nhàn r ỗi để tạo thành một

không gian lưu tr ữ lớ n hơ n, đượ c cấu hình để tăng hiệu suất, độ tin cậy hơ n so vớ i

các máy đơ n lẻ thông qua các cơ chế quản lý dữ liệu.

Một chức năng của Grid nữa là cân bằng sử dụng tài nguyên tốt hơ n. Một tổ

chức thườ ng gặ p các vấn đề không mong đợ i khi các hoạt động đòi hỏi thêm nhiều

tài nguyên hơ n. Vớ i Grid, có thể chuyển hoạt động đến các tài nguyên nhàn r ỗi

khác, hoặc có thể thêm các tài nguyên mớ i một cách dễ dàng, từ đó làm tăng khả năng chịu đựng của hệ thống. Grid có thể quản lý nhiều loại tài nguyên, do đó có

thể cho phép theo dõi tổng quan về các hoạt động sử dụng tài nguyên trong các tổ

chức lớ n, hỗ tr ợ hoạch định các chiến lượ c sử dụng tài nguyên.

2. Sử dụng CPU song song

Khả năng sử dụng các CPU song song là một đặc tính tuyệt vờ i của Grid,

ngoài việc hỗ tr ợ các nhu cầu tính toán của các nhà khoa học, sức mạnh tính toán do

Grid cung cấ p có thể giúp giải quyết các bài toán đòi hỏi năng lực xử lý lớ n trong

các ngành khác như y dượ c, tính toán tài chính, kinh tế, khai thác dầu hoả, dự báo

thờ i tiết, công nghiệ p vũ tr ụ, thiết k ế sản phẩm, … và r ất nhiều l ĩ nh vực khác.

3. Cho phép hợ p tác trên toàn thế giớ i

Một trong những đóng góp quan tr ọng của công nghệ Grid Computing là cho

phép và đơ n giản hoá hợ p tác chia sẻ, làm việc giữa một cộng đồng r ộng lớ n trên

toàn thế giớ i. Các công nghệ tính toán phân tán tr ướ c đây cũng cho phép hợ p tácnhưng chỉ trong một phạm vi nhỏ, còn Grid cho phép mở r ộng trên phạm vi toàn




- 23 -

cầu khi đưa ra những chuẩn quan tr ọng cho phép các hệ thống không đồng dạng làm

việc chung vớ i nhau để tạo nên một hệ thống tính toán ảo cung cấ p r ất nhiều dạng

tài nguyên khác nhau.

4. Cho phép chia sẻ, sử dụng tất cả các loại tài nguyên

Không chỉ cho phép chia sẻ các chu k ỳ tính toán, dữ liệu, Grid có thể cho

phép chia sẻ tất cả các loại tài nguyên mà tr ướ c đây chưa đượ c chia sẻ, như băng

thông mạng, các thiết bị đặc biệt, phần mềm, bản quyền, các dịch vụ,… Ví dụ, nếu

một ngườ i dùng muốn tăng băng thông k ết nối Intenet của mình lên để thực hiện

một ứng dụng khai thác dữ liệu, ứng dụng đó có thể đượ c gửi đến nhiều máy tính

trong Grid có các k ết nối Internet riêng, từ đó băng thông truy cậ p Internet của anhta tăng lên r ất nhiều lần,…

5. Tăng tính tin cậy cho các hệ thống máy tính.

Hiện nay, các hệ thống tính toán sử dụng các phần cứng chuyên dụng, đắt đỏ

để tăng độ tin cậy. Ví dụ, có thể sử dụng các “chip” có các mạch dự phòng để có thể

phục hồi lỗi khi có sự cố về phần cứng. Một máy tính có thể sử dụng các bộ vi xử lý

đôi, cho phép “cắm nóng”, để khi có một vi xử lý bị hỏng, có thể thay thế cái khác

mà không làm ngưng hoạt động của hệ thống. Các giải pháp này làm tăng độ tin cậy

của hệ thống, tuy nhiên vớ i chi quá đắt khi phụ kiện đi kèm cũng phải nhân lên.

Trong tươ ng lai, các hướ ng tiế p cận mớ i để giải quyết vấn đề độ tin cậy dựa

nhiều hơ n vào các công nghệ phần mềm hơ n là các phần cứng đắt tiền. Grid là sự

khở i đầu cho các công nghệ đó. Các hệ thống trong Grid thườ ng r ẻ và phân tán theo

địa lý, do đó, nếu có sự cố về nguồn điện hay các lỗi hệ thống khác tại một vị trí,

toàn bộ phần còn lại không bị ảnh hưở ng. Các phần mềm quản tr ị Grid có khả năngthực thi lại công việc trên một node khác khi phát hiện có lỗi hệ thống. Nếu quan

tr ọng hơ n nữa, trong các hệ thống theo thờ i gian thực, nhiều bản dự phòng của các

các công việc quan tr ọng có thể đượ c chạy trên nhiều máy tính khác nhau trong

Grid để đảm bảo độ tin cậy tối đa.

6. Tăng khả năng quản trị các hệ thống

Mục tiêu ảo hoá tất cả các tài nguyên và cung cấ p giao diện quản lý đơ n nhất

các hệ thống hỗn tạ p đem lại những cơ hội mớ i để quản tr ị tốt hơ n trong các cơ sở




- 24 -

hạ tầng công nghệ thông tin lớ n, phân tán. Bên cạnh đó, đối vớ i tầm quản lý v ĩ mô,

có nhiều dự án sử dụng cơ sở hạ tầng công thông tin, Grid cho phép quản lý độ ưu

tiên sử dụng tài nguyên của các dự án này. Tr ướ c đây, mỗi dự án thườ ng chịu trách

nhiệm quản lý một số tài nguyên, thườ ng xảy ra tình tr ạng các tài nguyên của dự án

này đang nhàn r ỗi trong khi dự án khác đang gặ p vấn đề, thiếu tài nguyên do gặ p

các sự kiện không lườ ng tr ướ c. Vớ i tầm nhìn r ộng hơ n do Grid cung cấ p, các tình

huống trên có thể đượ c giải quyết dễ dàng.

Trên đây giớ i thiệu một số ích lợ i khi sử dụng công nghệ Grid Computing, Grid

còn mang lại r ất nhiều lợ i ích khác mà không thể k ể hết ở đây, tuỳ vào tình huống

cụ thể mà đem lại các lợ i ích khác nhau. Vấn đề là phải hiểu rõ bản chất Grid, sử dụng tốt các công cụ nhằm khai khác tốt nhất trong các tình huống cụ thể.

Công nghệ Grid Computing có thể đượ c ứng dụng trong các bài toán trong khoa

học lẫn thươ ng mại:

+ Đòi hỏi năng lự c xử lý lớ n (High-performance computing), yêu cầu rút

ngắn thờ i gian hoàn thành k ết quả càng nhanh càng tốt.

+ Hướ ng dữ liệu, đòi hỏi phải thu thập, lư u trữ , phân tích một lượ ng lớ n

dữ liệu, mang tính phân tán.

+ Cần sự hợ p tác, chia sẻ giữ a các cộng đồng.

22..55.. CCáácc tthhàànnhh pphhầầnn ccơơ bbảảnn ccủủaa mmộộtt hhệệ tthhốốnngg ccơơ

ssởở hhạạ ttầầnngg GGr r iidd

Một cơ sở hạ tầng (infrastructure) là một công nghệ cho phép chúng ta thực hiện

các hoạt động của mình, ví dụ hệ thống đườ ng giao thông cho phép đi lại bằng xe,hệ thống ngân hàng cho phép chuyển tiền một các nhanh chóng. Để có thể hữu

dụng, cơ sở hạ tầng cần phải đượ c triển khai r ộng rãi, điều đó cũng có ngh ĩ a là nó

phải đơ n giản hoặc có giá tr ị to lớ n hoặc cả hai. Do đó, cơ sở hạ tầng Grid cần phải

vừa đơ n giản, vừa hỗ tr ợ đượ c nhiều dạng tài nguyên khác nhau.

Phần này sẽ giớ i thiệu tổng quan về các thành phần chính yếu của một môi

tr ườ ng Grid. Tuỳ theo thiết k ế và cách sử dụng Grid, một số thành phần có thể




- 25 -

không cần thiết và đôi khi trong một số tr ườ ng hợ p, có thể k ết hợ p nhiều thành phần

lại thành một thành phần phức hợ p.

1. Portal/Giao diện ngườ i dùng

Truy cậ p thông tin trên Grid là việc r ất quan tr ọng, thành phần giao diện

ngườ i dùng đảm nhiệm chức năng này. Giao diện ngườ i dùng thuộc một trong 2

dạng:

+ Giao diện cung cấ p bở i ứng dụng đang chạy của ngườ i dùng.

+ Giao diện cung cấ p bở i các nhà quản tr ị Grid giống như portal cho phép

khả năng truy xuất đến các ứng dụng và tài trong Grid như trong một không gian ảo

duy nhất.. Một Grid portal đưa ra một giao diện cho ngườ i dùng để chạy các ứngdụng sử dụng các tài nguyên và dịch vụ của Grid. Giao diện kiểu portal cũng có thể

giúp ngườ i dùng học cách sử dụng Grid.

2. Bảo mật

Các máy tính trong Grid đều đượ c nối mạng và chạy các ứng dụng; chúng có

thể phải xử lý các dữ liệu nhạy cảm hoặc có giá tr ị lớ n, do đó thành phần bảo mật

của Grid là hết sức quan tr ọng. Ở mức cơ sở , bất k ỳ môi tr ườ ng Grid nào cũng phải

có các cơ chế bảo mật.

3. Broker

Khi đã đượ c chứng thực, ngườ i dùng sẽ thực thi ứng dụng. Tùy thuộc vào

ứng dụng và các thông số cung cấ p bở i ngườ i dùng, bướ c tiế p theo là phải xác định

đượ c các tài nguyên thích hợ p để sử dụng. Việc này đòi hỏi các chức năng của một

broker.

4. Bộ lập lịch (scheduler)Khi các tài nguyên đã đượ c xác định và cấ p phát, bướ c tiế p theo là lậ p lịch

điều phối các công việc chạy trên đó. Cần có các bộ lậ p lịch để xác định các node

thực thi ứng dụng và gửi các công việc đượ c yêu cầu đến các node. Việc này có thể

đơ n giản là lấy tài nguyên sẵn sàng tiế p theo trong hệ thống, nhưng thườ ng thì nó

liên quan đến các hàng đợ i công việc ưu tiên, quản lý tải, tìm kiếm các tài nguyên

đã đăng ký sử dụng, theo dõi tiến trình. Nếu có một tậ p các công việc riêng lẻ,

không phụ thuộc vào nhau thì không cần các bộ lậ p lịch phức tạ p. Tuy nhiên, nếu




- 26 -

muốn giữ chỗ các tài nguyên đặc biệt hay chắc chắn r ằng các công việc chạy song

song thì nên sử dụng các bộ lậ p lịch để phối hợ p hoạt động của các công việc. Lưu

ý, các cluster có thể đượ c xem là một tài nguyên đơ n lẻ, chúng có bộ lậ p lịch riêng

để quản lý các node của nó. Một bộ lậ p lịch cấ p cao hơ n dùng để quản lý các công

việc cần thực hiện trên cluster trong khi bộ lậ p lịch cục bộ của cluster sẽ điều phối

các công việc cụ thể trên từng máy tính con.

5. Thành phần quản lý dữ liệu (Data management)

Nếu bất cứ dữ liệu nào, bao gồm cả các module thực thi của ứng dụng, cần

phải di chuyển thì cần phải có các phươ ng pháp an toàn, tin cậy để di chuyển các

file và dữ liệu qua lại giữa các node trong Grid. Do đó, cần phải có thành phần này.6. Thành phần quản lý công việc và tài nguyên (Job and resource

management)

Sau khi đã có các tiện nghi như trên, việc tiế p theo là xây dựng các dịch vụ

hỗ tr ợ việc thực hiện các công việc thật sự trong môi tr ườ ng Grid. Để giải quyết các

tác vụ nòng cốt như khở i chạy ứng dụng vớ i các tài nguyên cụ thể, theo dõi tr ạng

thái các công việc, nhận k ết quả, hệ thống Grid cần có thành phần quản lý công việc

và tài nguyên.

7. Các thành phần khác

Còn có nhiều thành phần khác để đưa vào môi tr ườ ng Grid và cần đượ c xem

xét khi thiết k ế và cài đặt ứng dụng. Ví dụ : Các tiện ích như liên lạc giữa các tiến

trình (Inter Process Communication) và các dịch vụ hỗ tr ợ tính toán chi phí và chi

tr ả là những tiện ích đượ c yêu cầu nhiều nhất.

Trên đây là giớ i thiệu vắn tắt và tổng quan về các thành phần chính của môi

tr ườ ng Grid. Tuỳ thuộc vào việc triển khai Grid và các yêu cầu của ứng dụng, có

nhiều cách khác nhau để k ết hợ p các thành phần này lại vớ i nhau để tạo nên một

giải pháp Grid.






- 28 -

Để giải quyết vấn đề “liên k ết hoạt động”, việc xây dựng các protocol là quan

tr ọng. Vì protocol xác định cách các thành phần phân tán trao đổi vớ i nhau để đạt

đượ c một mục đích nào đó, xác định các cấu trúc thông tin cần thiết trong quá trình

trao đổi. Các VO thườ ng hay thay đổi, nên các cơ chế xác định, chia sẻ và sử dụng

tài nguyên cần phải mềm dẻo, gọn nhẹ, để các thỏa thuận chia sẻ tài nguyên có thể

đượ c thiết lậ p, thay đổi một cách nhanh chóng. Các cơ chế chia sẻ không đượ c ảnh

hưở ng đến các chính sách cục bộ, và phải cho phép các thành viên quản lý đượ c các

tài nguyên của họ. Vì các protocol quy định việc giao tiế p giữa các thành viên chứ

không quy định thành viên đó phải như thế nào, nên khi dùng các protocol, các

chính sách cục bộ đượ c giữ lại. Do đó các protocol đượ c cần đến.Khi đã có các protocol, thì việc xây dựng các service là cần thiết và quan tr ọng,

các service là bản cài đặt cụ thể của các protocol. Việc xây dựng các service cơ bản

phục vụ truy cậ p đến tài nguyên tính toán, dữ liệu, tìm kiếm tài nguyên, lậ p lịch và

đồng bộ hoá, sao chép dữ liệu,… cho phép xây dựng các service cao cấ p hơ n cho

ứng dụng đồng thờ i tr ừu tượ ng hoá các chi tiết về tài nguyên.

Cũng cần phải xây dựng các bộ API và SDK, vì các nhà phát triển ứng dụng cần

phải có công cụ để hỗ tr ợ phát triển các ứng dụng phức tạ p trong môi tr ườ ng Grid,

ngườ i dùng cũng phải có khả năng thực thi đượ c các ứng dụng này. Sức mạnh, tính

đúng đắn của ứng dụng, chi phí phát triển và bảo trì là những mối quan tâm quan

tr ọng. Các API và SDK có thể giúp tăng tốc việc phát triển mã, cho phép chia sẻ

mã, tăng tính khả chuyển cho ứng dụng. Tất nhiên, API và SDK chỉ hỗ tr ợ thêm chứ

không thể thay thế các protocol đượ c.

22..66..22.. CChhii ttiiếếtt K K iiếếnn ttrrúúcc GGrriidd ttổổnngg qquuáátt

Sau gần 10 năm tậ p trung nghiên cứu, phát triển, tích luỹ kinh nghiệm, các nhà

phát triển công nghệ Grid đã có những thống nhất đáng k ể về kiến trúc Grid. Một

trong những kiến trúc Grid đượ c chấ p nhận nhiều nhất đượ c đưa ra bở i Ian Foster,

phần dướ i đây sẽ giớ i thiệu về kiến trúc này.

Kiến trúc Grid, theo Ian Foster, là một kiến trúc phân tầng như trong hình 2-8.

Các thành phần trong một tầng có chung đặc điểm, tính chất, có thể đượ c xây dựng






- 30 -

của tầng Fabric càng mạnh, càng nhiều sẽ cho phép các hoạt động chia sẻ phức tạ p,

phong phú hơ n. Kinh nghiệm cho thấy, việc quản lý tài nguyên ở tầng này ít nhất

cũng phải có cơ chế cung cấ p thông tin để xác đượ c cấu trúc, tr ạng thái, năng lực

của tài nguyên và cơ chế điều khiển chất lượ ng dịch vụ.

22..66..22..22.. TTầầnngg CCoonnnneeccttiivviittyy

Tầng Connectivity định ngh ĩ a các protocol liên lạc và chứng thực cơ bản cần

thiết cho các giao dịch mạng đặc tr ưng của Grid. Các protocol liên lạc cho phép trao

đổi dữ liệu giữa các tài nguyên tầng Fabric. Các protocol chứng thực xây dựng trên

các dịch vụ liên lạc nhằm cung cấ p các cơ chế mã hóa, bảo mật, xác minh và nhận

dạng các ngườ i dùng và tài nguyên. Việc liên lạc đòi hỏi các công việc như vận

chuyển, định tuyến, đặt tên. Trong tươ ng lai, việc liên lạc của Grid có thể cần các

protocol mớ i, nhưng hiện nay nên xây dựng trên các protocol có sẵn của bộ TCP/IP

protocol stack, cụ thể là các tầng Network (IP và ICMP), Transport (TCP,UDP) và

Application (DNS,OSPF,…).

Về khía cạnh bảo mật của tầng Connectivity, các giải pháp phải dựa trên các

chuẩn bảo mật hiện hành khi có thể. Cũng giống như liên lạc, r ất nhiều chuẩn bảomật đã đượ c phát triển vớ i bộ Internet protocol có thể áp dụng đượ c.

Việc chứng thực, phân quyền trong môi tr ườ ng Grid là r ất phức tạ p. Các công

nghệ bảo mật truyền thống chủ yếu tậ p trung bảo vệ các giao dịch giữa các máy

client và server. Trong Grid, việc phân biệt client/server không tồn tại, vì các mỗi

tài nguyên trong một lúc nào đó có thể là server (khi nó nhận yêu cầu), một lúc khác

lại là client (khi nó đề xuất yêu cầu đến các tài nguyên khác). Do đó, các giải pháp

chứng thực cho các môi tr ườ ng VO nên đạt đượ c các yêu cầu về bảo mật trong Grid

như đã giớ i thiệu ở trên.

22..66..22..33.. TTầầnngg R R eessoouurrccee

Tầng Resource dựa trên các protocol liên lạc và chứng thực của tầng

Connectivity để xây dựng các protocol, API và SDK nhằm hỗ tr ợ việc thươ ng

lượ ng, khở i tạo, theo dõi, điều khiển, tính toán chi phí và chi tr ả cho các hoạt động

chia sẻ trên từng tài nguyên riêng lẻ một cách an toàn. Bản cài đặt các protocol của




- 31 -

tầng Resource sẽ gọi các chức năng của tầng Fabric để truy cậ p và điều khiển các

tài nguyên cục bộ.

Các protocol tầng Resource tậ p trung toàn bộ vào các tài nguyên riêng lẻ, không

quan tâm đến tr ạng thái toàn cục và các hoạt động trong các tậ p tài nguyên phân

tán.

Các protocol tầng Resource đượ c phân thành 2 dạng chính như sau:

+ Các protocol thông tin

Sử dụng để thu thậ p thông tin về cấu trúc và tr ạng thái các tài nguyên ví

dụ như cấu hình hiện tại, tải hiện tại, chính sách sử dụng,…

+ Các protocol quản lý Sử dụng để thượ ng lượ ng truy xuất đến một tài nguyên chia sẻ, xác định

rõ, ví dụ, các yêu cầu về tài nguyên (bao gồm luôn việc giữ chỗ tài nguyên và

chất lượ ng dịch vụ) và các thao tác cần đượ c thực hiện như tạo tiến trình, hoặc

truy xuất dữ liệu. Do các protocol quản lý chịu trách nhiệm đại diện cho các

quan hệ chia sẻ, đảm bảo các hoạt động sử dụng tài nguyên phải phù hợ p vớ i các

chính sách chia sẻ tài nguyên, bao gồm luôn việc tính toán và chi tr ả chi phí.

Mỗi protocol cũng nên hỗ tr ợ việc theo dõi tr ạng thái và điều khiển các hoạt

động.

Vớ i những yêu cầu như vậy, tậ p các protocol tầng Resource (và Connectivity)

nên nhỏ gọn và tậ p trung. Các protocol này chỉ nên đáp ứng đượ c các cơ chế chia sẻ

vớ i nhiều loại tài nguyên khác nhau (ví dụ, các hệ thống quản lý tài nguyên cục bộ

khác nhau) là đủ.Các chức năng chính của tầng Resource cũng giống như của tầng Fabric cộng

thêm nhiều ngữ ngh ĩ a mớ i vớ i cơ chế báo lỗi tin cậy khi hoạt động không thành

công.

22..66..22..44.. TTầầnngg CCoolllleeccttiivvee

Trong khi tầng Resource tậ p trung vào các tài nguyên đơ n lẻ, tầng Collective

chứa các protocol, service, API, SDK không liên hệ đến bất k ỳ một tài nguyên cụ




- 32 -

thể nào mà thực hiện quản lý toàn cục, tậ p trung vào các giao tác giữa các tậ p tài

nguyên.

Tầng Collective có thể bổ sung thêm nhiều loại hoạt động chia sẻ mớ i ngoài

những gì đã có từ tầng Resource mà không cần bổ sung thêm các yêu cầu mớ i cho

các tài nguyên đang đượ c chia sẻ. Ví dụ:

+ Directory service

Cho phép các thành phần tham gia VO phát hiện sự tồn tại và/hoặc đặc

tính của các tài nguyên trong VO. Một directory service có thể cho phép ngườ i

truy vấn tài nguyên qua tên và/hay các thuộc tính như kiểu, khả năng, tải, …

+ Co-allocation, scheduling, và broker service Cho phép các thành phần tham gia VO yêu cầu cấ p phát các tài nguyên

cho các mục đích cụ thể và lậ p lịch cho các tác vụ trên các tài nguyên tươ ng

ứng.

+ Monitoring ang dianostics sevice

Hỗ tr ợ việc kiểm soát các tài nguyên của VO, kiểm tra xem có bị lỗi, bị

tấn công, bị quá tải,… hay không.

+ Data replication service

Hỗ tr ợ quản lý tài nguyên lưu tr ữ của VO để tối ưu hiệu suất truy cậ p dữ

liệu theo các độ đo như thờ i gian đáp ứng, tính toàn vẹn, tin cậy, chi phí,…

+ Grid-enable programming system

Cho phép các sử dụng các mô hình lậ p trình hiện tại trong môi tr ườ ng

Grid, sử dụng nhiều loại dịch vụ Grid để giải quyết các vấn đề như phát hiện,

tìm kiếm tài nguyên, bảo mật, cấ p phát tài nguyên,…+ Workload management system and collaboration framework

Cung cấ p khả năng đặc tả, sử dụng, quản lý các luồng công việc đa thành

phần, bất đồng bộ và qua nhiều bướ c.

+ Software discovery service

Tìm kiếm và chọn ra các cài đặt phần mềm tốt nhất và môi tr ườ ng thực

thi dựa theo ứng dụng cần đượ c giải quyết.

+ Community authorization server






- 34 -

Ví dụ : một chươ ng trình phân tích bộ gen ngườ i cần phải chạy hàng ngàn tác vụ

độc lậ p, mỗi tác vụ cần nhiều file chứa thông tin từng phần của bộ gen có thể sử

dụng các chức năng Grid sau:

+ Lấy các thông tin, thẻ chứng thực (các protocol tầng Connectivity).

+ Truy vấn hệ thống thông tin Grid và các danh mục để tìm các tài nguyên

thích hợ p và vị trí các file dữ liệu đầu vào. (các dịch vụ tầng Collective).

+ Gửi các yêu cầu đến các tài nguyên để thực hiện tính toán, di chuyển dữ

liệu,… và kiểm soát quá trình thực thi công việc, thông báo cho ngườ i dùng khi mọi

thứ hoàn tất, dò tìm và phản ứng vớ i các điều kiện gây lỗi (tầng Resource).

Hình 2-9 Quan điểm của các lập trình viên về kiến trúc Grid.

Giải thích hình 2-9 : Các hàm API đượ c cài đặt bằng các bộ công cụ phát triển phần mềm (SDK), tớ i

lượ t nó, các bộ SDK sử dụng các Grid protocol để giao tiế p vớ i các service cung cấ p các chức năng cho

ngườ i dùng cuối. Các SDK cấ p cao có thể cung cấ p các chức năng mà không gọi tr ực tiế p một protocol cụ

thể nào, chúng có thể k ết hợ p nhiều hoạt động của các prtocol khác nhau bằng các gọi các hàm API cũng như

cài đặt các chức năng cục bộ. Các mũi tên đặc đại diện cho các lờ i gọi tr ực tiế p, các mũi tên ngắt quãng đại

diện cho việc giao tiế p giữa các protocol.

Các tầng trong kiến trúc trên có thể đượ c hiện thực hóa bằng nhiều sản phẩm

khác nhau, đượ c phát triển bở i nhiều nhà phát triển phần mềm, các tổ chức, cộng

đồng mã nguồn mở , các nhà sản xuất máy tính trên khắ p thế giớ i.






- 36 -

Tận dụng các giao diện ở tầng Core Middleware để cung cấ p các dịch vụ có

mức độ tr ừu tượ ng cao hơ n. Tầng này bao gồm các môi tr ườ ng phát triển phần

mềm, công cụ lậ p trình, resource broker, bộ lậ p lịch,…

+ Tầng Application và Portal (Application)

Giống như tầng Fabric trong kiến trúc tổng quát.

Dướ i đây là một số dự án Grid tươ ng ứng vớ i các tầng khác nhau.

Hình 2-11 Các dự án Grid tươ ng ứ ng vớ i các tầng.

22..77.. CChhuuẩẩnn hhooáá GGr r iidd

Một trong những vấn đề lớ n của bất k ỳ công nghệ tính toán nào là làm sao để

các thành phần khác nhau có thể “nói chuyện” đượ c vớ i nhau. Không có gì quan

tr ọng hơ n việc làm cho các nền tảng khác nhau giao tiế p đượ c vớ i nhau. Đây cũng

là một trong những thách thức của công nghệ Grid Computing. Bở i vì công nghệ

Grid computing cần phải đáp ứng nhiều nhu cầu khác nhau, hỗ tr ợ nhiều loại công

nghệ, tài nguyên, tr ải r ộng khắ p thế giớ i, do nhiều tổ chức tham gia xây dựng, nên

để các thành phần Grid, ứng dụng Grid tươ ng thích đượ c vớ i nhau cần phải có một

chuẩn chung, một ngôn ngữ chung thống nhất cho toàn bộ nền công nghệ.

Trong công nghệ Grid Computing, việc thiếu chuẩn hóa sẽ dẫn đến toàn bộ cáccông ty, tổ chức, nhà phát triển xây dựng, phát triển công nghệ vớ i các k ỹ thuật và




- 37 -

giải pháp khác nhau. Trong thế giớ i riêng của mỗi nhóm phát triển Grid thì có thể

không là vấn đề lớ n, nhưng khi mở r ộng môi tr ườ ng Grid, liên k ết các nhóm vào thế

giớ i r ộng hơ n thì đây lại là vấn đề lớ n, nó sẽ gây ra sự chia cắt, bất đồng và nhiều

hạn chế khác.

Việc xây dựng và áp dụng các chuẩn trong Grid mang lại lợ i ích r ất lớ n, cơ bản

nhất là mang lại khả năng mở r ộng các số lượ ng tài nguyên sẵn sàng cho Grid. Bên

cạnh đó, còn mang lại nhiều lợ i ích khác như :

+ Liên k ết hoạt động

Cho phép các hệ thống Grid có thể đượ c thiết k ế và phát triển theo nhiều

ngôn ngữ lậ p trình, nhiều môi tr ườ ng, nhiều nền tảng khác nhau một cách dễ dàngvà hiệu quả.

+ Tăng tính mềm dẻo

Vớ i sự chuẩn hóa, ngườ i dùng có thể chuyển đổi qua lại giữa các hệ thống

Grid, có nhiều lựa chọn hơ n trong việc xây dựng các dự án.

+ Tăng năng lự c của Grid

Khi có nhiều môi tr ườ ng và nền tảng đượ c hỗ tr ợ hơ n, khả năng phát hành

các dịch vụ sẽ dễ dàng hơ n, và từ đó sẽ làm tăng năng lực của hệ thống Grid.

+ Tăng tốc độ phát triển ứ ng dụng

Sử dụng các bộ toolkit đượ c chuẩn hóa sẽ làm giảm thờ i xây dựng, phát

triển các hệ thống Grid. Thay vì dành nhiều thờ i gian cho việc xây dựng các chức

năng giao tiế p, các hệ thống quản lý, vớ i việc sử dụng các hệ thống chuẩn hoá có

sẵn, các nhà phát triển ứng dụng sẽ có nhiều thờ i gian hơ n để tối ưu các chức năng

xử lý dữ liệu.Phân tích như trên cho thấy việc xây dựng các chuẩn là cần thiết. Để đáp ứng

nhu cầu đó, tổ chức Global Grid Forum(GGF) ra đờ i vớ i thành viên là hầu hết các

nhà nghiên cứu, các tổ chức hàng đầu trong việc xây dựng công nghệ Grid

Computing. GGF đã và đang phát triển các chuẩn về Grid Computing như : Open

Grid Services Architecture (OGSA), Open Grid Services Infrastructure (OGSI),

Web Services Resource Framework (WSRF).




- 38 -

Các chuẩn trên đây cũng là chuẩn duy nhất hiện nay trong ngành công nghệ Grid

Computing. Các chuẩn này vẫn trong giai đoạn phát triển.

Mục tiêu của OGSA và OGSI nhằm xây dựng một nền tảng để hỗ tr ợ việc xây

dựng một tậ p các dịch vụ có thể đượ c tìm thấy và đượ c gọi bở i bất k ỳ hệ thống nào

trong Grid. Mục tiêu chính là định ngh ĩ a đượ c các giao diện dịch vụ(service

interface) hoàn toàn độc lậ p vớ i các cài đặt cụ thể bên dướ i, điều đó sẽ giúp cung

cấ p các dịch vụ OGSA trên bất k ỳ thiết bị tính toán nào k ết nối vớ i Grid.

1. Open Grid Services Architecture (OGSA)

Chuẩn Open Grid Services Architecture (OGSA) xác định toàn bộ các k ết

cấu, cấu trúc, dịch vụ cơ bản của một ứng dụng Grid và có thể đượ c áp dụng trong bất k ỳ một hệ thống Grid nào. Về thực chất, OGSA định ngh ĩ a các dịch vụ Grid

(Grid service) là gì, chúng cần có những khả năng gì, đượ c xây dựng trên những

công nghệ nào. Nó cũng xác định mô hình lậ p trình cho Grid service. Tuy nhiên,

OGSA không đi sâu vào mặt k ỹ thuật của vấn đề, nó chỉ giúp phân biệt cái gì là

Grid và cái gì không phải.

OGSA xác định Grid service phải đượ c xây dựng dựa trên các chuẩn về Web

service hiện hành, xem Grid service như là các Web service đượ c chỉnh sửa để đáp

ứng các yêu cầu mớ i. Ví dụ, bản thân các Grid service đượ c định ngh ĩ a bằng chuẩn

WSDL (Web Services Definition Language) vớ i một số mở r ộng. Điều này r ất quan

tr ọng, vì nó cung cấ p một loạt các công nghệ dựa theo một chuẩn chung và mở để

truy cậ p nhiều loại Grid service dựa trên các chuẩn hiện hành như SOAP, XML, và

WS-Security. Vớ i điều kiện như vậy, có thể thêm và tích hợ p các Grid service mớ i

một cách đơ n giản, dễ dàng. Nó cung cấ p một phươ ng pháp chung nhất để tìmkiếm, xác định, sử dụng các service mớ i khi chúng có mặt. Từ đó, giải quyết đượ c

vấn đề liên k ết hoạt động giữa các Grid và các tài nguyên.

2. Open Grid Services Infrastructure (OGSI) phiên bản 1.0

OGSI là một bản đặc tả chính thức các khái niệm đượ c mô tả trong OGSA.

OGSI version 1.0 xác định một một tậ p các service cơ bản, xác định cách xây dựng

một Grid service, định ngh ĩ a các hoạt động chung nhất của tất cả các Grid service,




- 39 -

vạch ra các cơ chế để tạo lậ p; quản lý các Grid service, cơ chế trao đổi thông tin

giữa các Grid service.

Chuẩn OGSI dựa trên các chuẩn khác như XML, Web service, WSDL, … do

đó, nó cũng là một chuẩn mở .

3.Web Services Resource Framework (WSRF)

Là một bướ c phát triển của OGSI, nó k ết hợ p kiến trúc Grid vào công nghệ

Web service hiện hành. Thay vì xây dựng một kiểu Grid service mớ i, những đặc tả

này cho phép các service xác định trong OGSI đượ c xây dựng hoàn toàn dựa trên

Web service.

Tóm l ại , các hệ thống Grid đều cần phải đượ c xây dựng trên một chuẩn chung.Hiện nay chỉ có một chuẩn chung đang đượ c phát triển và đượ c khuyến cáo là nên

sử dụng khi xây dựng các hệ thống Grid. Chuẩn đó là OGSA và bản đặc tả của nó,

OGSI. Theo chuẩn OGSA, các hệ thống Grid đượ c xây dựng xung quanh khái niệm

Grid service. Grid service cần phải xây dựng dựa trên các công nghệ chuẩn hiện

hành, do đócông nghệ Web service đượ c chọn trong hàng loạt các công nghệ như

CORBA, RMI, RPC,… Và hiện nay, toàn bộ bản đặc tả OGSI version 1.0 đã đượ c

cài đặt cụ thể trong bộ Globus Toolkit từ version 3.0 tr ở đi, và UNICORE cũng bắt

đầu cài đặt lại theo OGSA, OGSI.

Hình 2-12 tóm tắt mối quan hệ giữa các chuẩn trên:

Hình 2-12 Mối quan hệ giữ a các chuẩn về Grid Service. Giải thích hình 2-12: OGSA định ngh ĩ a và dựa trên Grid service, OGSI đặc tả Grid service

theo OGSA, Grid service lả một mở r ộng của Web service, một công nghệ cho phép các thành

phần phân tán giao tiế p vớ i nhau, GT là một bản cài đặt hoàn chỉnh OGSI vớ i ngôn ngữ Java.




- 40 -

Chi tiết về các chuẩn sẽ đượ c giớ i thiệu cụ thể hơ n trong phần sau, khi giớ i thiệu

về bộ Globus Toolkit.

22..88.. GGiiớớii tthhiiệệuu ccáácc ddựự áánn GGr r iidd mmiiddddlleewwaar r ee cchhíínnhh

Ứ ng vớ i từng tầng trong kiến trúc Grid, có r ất nhiều dự án phát triển bở i nhiều

nhà nghiên cứu, tổ chức, tậ p đoàn thươ ng mại lớ n nhằm đưa Grid tr ở thành hiện

thực. Để hoàn thành đượ c các mục tiêu của Grid, các phần mềm Grid middleware

cần phải giải quyết đượ c các vấn đề cơ bản của Grid. Grid middleware là phần mềm

cho phép tổ chức, tích hợ p các tài nguyên và các chức năng vào Grid, nhiệm vụ chính của là thực hiện tự động hóa các “thỏa thuận giữa máy vớ i máy”(machine-to-

machine negotiation) để ghép mọi thứ lại vớ i nhau. Đã có r ất nhiều nỗ lực từ khắ p

nơ i trong việc thiết k ế và cài đặt các phần mềm middleware để xây dựng Grid. Hiện

nay đã có nhiều gói phần mềm triển khai thành công, có thể xây dựng đượ c các

Grid vượ t ra khỏi giớ i hạn mạng cục bộ.

Phần này sẽ giớ i thiệu 4 dự án Grid middleware phổ biến hiện nay là

UNICORE, Globus, Legion và Gridbus.

22..88..11.. UUNNIICCOOR R EE

UNICORE là một môi tr ườ ng Grid tích hợ p theo chiều thẳng đứng nhằm hỗ tr ợ :

+ Khả năng truy cậ p tài nguyên một cách đơ n giản, an toàn, bảo mật, tr ực

quan trong môi tr ườ ng phân tán cho ngườ i dùng.

+ Tích hợ p các cơ chế chứng thực trong các thủ tục quản tr ị, nhằm giảm chi

phí đào tạo và hỗ tr ợ cho các Grid site.

+ Phân phối dễ dàng các công việc trên nhiều nền tảng khác nhau.

1. Kiến trúc của UNICORE

Là kiến trúc 3 tầng (three-tier) như hình 2-13. Bao gồm một client chạy trên

một máy tr ạm hoặc PC có hỗ tr ợ Java; nhiều thể hiện của Network Job Supervisors

(NJS) chạy trên các server dành riêng; và nhiều thể hiện của Target System




- 41 -

Interfaces (TSI) chạy trên các node để cung cấ p giao diện sử dụng các hệ quản tr ị

tài nguyên cục bộ như các hệ điều hành, các hệ xử lý theo lô,…

Hình 2-13 Mô hình kiến trúc hoạt động của UNICORE

Theo quan điểm của ngườ i dùng, UNICORE là một hệ thống dựa trên mô hình

client-server có 3 lớ p.+ Lớ p ngườ i dùng : Ngườ i dùng chạy UNICORE Client trên máy tr ạm cục

bộ hoặc PC.

Giao diện của UNICORE Client gồm 2 thành phần : JPA (Job Preparation

Agent) và JMC (Job Monitor Component). Các công việc đượ c xây dựng bằng JPA,

tr ạng thái và k ết quả các công việc đượ c lấy từ JMC. Các công việc và các truy vấn

về tr ạng thái, k ết quả của chúng đượ c định dạng bằng Abstract Job Object (AJO).

+ Lớ p server : Ở mức cao nhất, mỗi trung tâm máy tính thành viên phải xác

định một hoặc nhiều UNICORE Grid site (USite) để ngườ i dùng k ết nối vào.

+ Lớ p Target System : Một Usite cho phép truy cậ p đến các tài nguyên tính

toán và lưu tr ữ. Chúng đượ c tổ chức thành các site ảo (Vsite) đại diện cho các hệ

thống thực thi và/hoặc lưu tr ữ trong trung tâm máy tính. Một UNICORE VSite cũng

gồm 2 thành phần: NJS (Network Job Supervisor) and TSI (Target System

Interface). NJS Server quản lý tất cả các công việc UNICORE và thực hiện phânquyền bằng cách tìm ánh xạ tươ ng ứng giữa chứng chỉ ngườ i dùng và tài khoản






- 43 -

+ Hỗ trợ các công việc k ế thừ a lại

UNICORE hỗ tr ợ công nghệ xử lý theo lô truyền thống bằng cách cho

phép ngườ i dùng đính kèm các công việc tr ướ c đó vào công việc hiện hành.

+ Có hệ thống quản lý tài nguyên

Ngườ i dùng chọn các hệ thống đích và xác định các yêu cầu tài nguyên.

Hệ thống UNICORE Client sẽ kiểm tra tính đúng đắn của các công việc, báo lỗi

ngay lậ p tức và thực hiện cấ p phát tài nguyên.

22..88..22.. GGlloobbuuss

Dự án Globus cung cấ p một bộ toolkit mã nguồn mở , có thể đượ c sử dụng để xây dựng các Grid Tính toán và các ứng dụng dựa trên Grid. Nó cho phép chia sẻ

năng lực tính toán, dữ liệu, các công cụ khác một cách bảo mật, an toàn tr ực tuyến

giữa các tậ p đoàn, viện nghiên cứu mà không cần loại bỏ các chính sách quản tr ị

cục bộ. Các service, interface, protocol nền tảng trong bộ Globus Toolkit cho phép

ngườ i dùng truy cậ p đến các tài nguyên ở xa một cách đơ n giản trong khi vẫn giữ

đượ c quyền điều khiển cục bộ cho phép ai đượ c dùng tài nguyên và khi nào.

Chi tiết về Globus Toolkit sẽ đượ c trình bày trong chươ ng sau.

22..88..33.. LLeeggiioonn

Legion là một middleware ch phép k ết hợ p một lượ ng r ất lớ n các host, hệ thống

lưu tr ữ dữ liệu, các mã thực thi và các đối tượ ng hỗn tạ p đượ c quản lý độc lậ p thành

một nền tảng tính toán chặt chẽ thống nhất. Legion có khả năng gom nhóm các

thành phần r ải rác này thành một siêu máy tính dựa trên đối tượ ng (object-based

metacomputer), đưa ra mức độ cao hơ n về tính mềm dẻo và tự tr ị.

Hình 2-14 cho thấy kiến trúc của Legion. Nó đượ c cấu trúc như là một hệ thống

các “đối tượ ng phân tán” – các tiến trình hoạt động giao tiế p vớ i nhau sử dụng một

dịch vụ gọi hàm từ xa thống nhất. Tất cả các tài nguyên phần cứng và phần mềm

trong hệ thống Grid đều đượ c đại diện bở i các đối tựơ ng Legion. Mô hình đối tượ ng

cơ sở của Legion đượ c mô tả bở i ngôn ngữ đặc tả giao diện (interface description

language (IDL)), và đượ c dịch và liên k ết vớ i ngôn ngữ lậ p trình đượ c chọn.




- 44 -

Hướ ng tiế p cận này cho phép liên k ết hoạt động các thành phần của nhiều ngôn

ngữ lậ p trình khác nhau, trên nhiều nền tảng thực thi khác nhau. Khi tất cả các thành

phần trong hệ thống đều là các đối tượ ng, chúng có thể giao tiế p vớ i nhau không

phân biệt chi tiết về vị trí, cài đặt.

Một “đối tượ ng lớ p” (class object) đượ c sử dụng để định ngh ĩ a và quản lý các

Legion object tươ ng ứng. Class object đượ c gán các trách nhiệm cấ p hệ thống; nó

điều khiển việc tạo lậ p các thực thể (instance) mớ i, lậ p lịch thực thi, kích hoạt và

huỷ kích hoạt các thực thể, cung cấ p các thông tin về vị trí hiện tại của nó cho các

đối tượ ng client muốn liên lạc vớ i các thực thể. Nói một cách khác, các lớ p hoạt

động như là nhà quản lý và hoạch định chính sách cho hệ thống. Các siêu lớ p(metaclass) đượ c sử dụng để định ngh ĩ a các thực thể lớ p.

Hình 2-14 Kiến trúc của Legion.

Legion định ngh ĩ a một tậ p các kiểu đối tượ ng nòng cốt cung cấ p các dịch vụ cơ

bản của hệ thống như đặt tên và k ết nối, tạo lậ p, kích hoạt, huỷ kích hoạt và xoá các

đối tượ ng. Những đối tượ ng này đưa ra các cơ chế giúp cho các lớ p triển khai các

chính sách thích hợ p cho các thực thể của chúng. Legion cũng cho phép ngườ i dùng

định ngh ĩ a và xây dựng các “đối tượ ng lớ p” của riêng mình.

Một số đối tượ ng nòng cốt :

+ Host object : đại diện cho các bộ xử xý.

+ Vault object : đại diện cho hệ thống lưu tr ữ ngoài.




- 45 -

+ Context object : Ánh xạ “context name” vào LOID (Legion Object

Identifiers).

+ Binding Agents : Ánh xạ LOID vào LOA (Legion Object Address).

+ Implement object : duy trì như một file thực thi mà host object có thể thực

thi đượ c khi nó nhận đượ c một yêu cầu hay tạo ra một object.

Host object cung cấ p một giao diện thống nhất để tạo lậ p các đối tượ ng (nhiệm

vụ), Vault object cung cấ p một giao diện thống nhất để cấ p phát tài nguyên lưu tr ữ,

mặc dù có nhiều cài đặt khác nhau cho mỗi loại.

Legion sử dụng hệ thống tên 3 cấ p. Các chuỗi ký tự, đượ c gọi “context name”,

tạo điều kiện thuận lợ i cho ngườ i dùng sử dụng một dải r ộng lớ n các tài nguyên, ở cấ p cao nhất. Context object ánh xạ context name vào LOID là cấ p tiế p theo. LOID

độc lậ p vớ i vị trí, do đó không thể sử dụng để thực hiện giao tiế p. Vì vậy, LOID tiế p

tục đượ c chuyển thành LOA phục vụ giao tiế p. LOA là một địa chỉ vật lý (hoặc tậ p

các địa chỉ vật lý trong tr ườ ng hợ p có các đối tượ ng nhân bản) chứa các thông tin

cần thiết cho phép các đối tượ ng giao tiế p đượ c vớ i nhau.

22..88..44.. GGrriiddBBuuss Dự án Gridbus là một dự án mã nguồn mở , thuộc nhiều cơ quan dẫn đầu bở i

GRIDS Lab thuộc University of Melbourne, Australia. Nó là cho phép k ết hợ p các

cluster hướ ng dịch vụ (service-oriented cluster) vớ i các Grid middleware để hỗ tr ợ

các ứng dụng eScience và eBusiness. Nó k ết hợ p các phần mềm liên quan và đưa ra

một tầng tr ừu tượ ng nhằm che đi tính đa dạng, hỗn tạ p của các tài nguyên và các

công nghệ middleware tầng thấ p từ góc nhìn của các nhà phát triển ứng dụng. Bên

cạnh đó, nó tậ p trung hiện thực hoá mô hình tính toán tiện ích (ultility computing)

tr ải dài từ các cluster đến Grid và các hệ thống tính toán ngang hàng (peer-to-peer).

Gridbus sử dụng mô hình kinh tế trong việc quản lý các tài nguyên chia sẻ và nâng

cao tính tiện nghi của các dịch vụ. Từ đó làm tăng khả năng thươ ng mại của các

dịch vụ Grid, cho phép quản lý hiệu quả việc cung và cầu tài nguyên.

Gridbus hỗ tr ợ các tiện nghi ở nhiều mức khác nhau:

+ Mức tài nguyên thô (ví dụ : bán các chu k ỳ CPU và tài nguyên lưu tr ữ)










- 49 -

các dịch vụ theo chiều sâu và có sự k ết hợ p chặt chẽ giữa các thành phần client và

server. Globus đi theo hướ ng tiế p cận “túi dịch vụ” (bag of service), cung cấ p một

tậ p các công cụ cơ bản phong phú để có thể chọn lựa nhằm xây dựng các hệ thống

Grid. Các thành phần của Gridbus tr ải r ộng hết toàn bộ kiến trúc Grid, mà không

liên k ết, tích hợ p chặt chẽ như UNICORE và Legion, chúng có thể đượ c sử dụng

độc lậ p vớ i nhau.

Hình 2-16 So sánh giữ a UNICORE, Globus, Legion và GridBus.

Bảng 2-2 so sánh các middleware dựa theo kiến trúc, mô hình cài đặt,…

Thuộc tính\Middleware

UNICORE Globus Legion Gridbus

Tập trung vào Mô hình lậ p trìnhcấ p cao Các service cấ pthấ p Mô hình lậ ptrình cấ p cao Tr ừu tượ ng hoávà các mô hìnhthị tr ườ ng tínhtoán

L ĩ nh vự c Tậ p trung vào thựcthi và kiểm soát job.

Mô hình tínhtoán chung, tổngquát



Kiến trúc Hệ thống đa tầngtheo chiều sâu

Bộ toolkit có phân tầng vàmodule hoá

Hệ thống tíchhợ p theo chiềosâu.

Hệ thống cácthành phân tầng.

Chuẩn sử dụng Mớ i bắt đầu áp dụngOGSA, OGSI vào

phiên bản hiện đang phát triển.

OGSA,OGSI. Không có Không có.OGSA,OGSI

nếu sử dụng vớ iGlobus

Mô hình triểnkhai

Abstract Job Object Mô hình đồng hồ cát ở mức độ hệ thống

Siêu hệ thốnghướ ng đối tượ ng

Mô hình đồng hồ cát ở mức độ hệ thống

Công nghệ càiđặt

Java C và Java C++ C, Java, C# vàPerl

Nền tảng thự cthi

Unix Unix Unix Unix vàWindows vớ i.NET

Môi trườ ng lập

trình

Môi tr ườ ng

workload

Thay thế các thư

viện của Unix vàC. Các thư viện

Legion API và

các công cụ command line.

Broker Java API,

Ngôn ngữ thamsố dựa trên




- 50 -

MPI đặc biệt(MPICH-G),CoG(Commodity

Grid) kits vớ iJava, Python,CORBA,Matlab, JavaServer Pages,Perl và WebServices

XML.Mô hình GridThread trongAlchemi.

Mô hình phânphối

Mã nguồn mở Mã nguồn mở Mã nguồn đóng,có các phiên bảnthươ ng mại.

Mã nguồn mở

Sử dụng trong

một số ứ ngdụng và ngườ i

dùng

+EuroGrid

+GridInteroperabilityProject (GRIP)+OpenMolGrid+ Japanese NAREGI

+ AppLeS

+ Ninf + Nimrod-G+ NASA IPG+ Condor-G+ GridbusBroker + UK eScienceProject+ GriPhyN+ EU Data Grid.

+ NPACI

Testbed+ Nimrod-L+NCBioGrid.

+ ePhysics

Portal + BelleAnalysis DataGrid+ NeuroGrid+ NaturalLanguageEngineering+HydroGrid+AmsterdamPrivate Grid.

Quản lý tàinguyên

Không có Có broker service

Có broker service

Gridbus broker

Cách thứ c liênlạc

Mô hình AJO, khônghỗ tr ợ chuyểnmessage đồng bộ.

Thư viện Nexus Hỗ tr ợ nhiều loạigiao tiế p RMIthông qua LOID

Không có thôngtin

Bảo mật Sử dụng SecureSocket Layer (SSL)

protocol và chứngchỉ chứng thựcX.509V3.

Thông qua GSI,cũng dựa trênSSL và X.509V3

Không có thôngtin

+Dựa trên GSIcủa Globus+ Sử dụng cácchức năng bảomật củaMicrosoft .NETFramework (Alchemi).

Bảng 2-2 Bảng so sánh các đặc tính của các middleware

Tóm lại :

Trên đây vừa giớ i thiệu một số middleware chính để xây dựng các hệ thống

Grid. Các middleware này cũng đã giải quyết cơ bản các vấn đề một hệ thống Grid

đặt ra, theo các cách khác nhau. Hiện nay bộ Globus Toolkit đang vươ n lên và tr ở

thành chuẩn thực tế (de factor standard), tr ở thành nền tảng để xây dựng các hệ

thống Grid trong khoa học và thươ ng mại. Globus đượ c xây dựng trên các chuẩn

chung về hệ thống Grid như OGSA, OGSI,…(do tổ chức Global Grid Forum xây




- 51 -

dựng), đượ c sự hỗ tr ợ và tài tr ợ của nhiều tổ chức, tậ p đoàn công nghệ thông tin lớ n

trên thế giớ i. Vớ i mục đích nghiên cứu về công nghệ Grid Computing, bộ Globus

Toolkit đượ c chọn để nghiên cứu vớ i mục đích tìm hiểu và nắm vững nền tảng xây

dựng các hệ thống Grid, làm điều kiện để xây dựng các dịch vụ, ứng dụng tầng cao

hơ n của riêng mình. Do đó, toàn bộ phần sau của luận văn sẽ trình bày về Grid

trong ngữ cảnh là bộ Globus Toolkit.



Chươ ng 3. Giớ i thiệu bộ Globus Toolkit phiên bản 3.2

- 52 -

CChhưươơnngg 33.. GGiiớớii tthhiiệệuu bbộộ GGlloobbuuss TToooollkkiitt pphhiiêênn

bbảảnn 33..22 33..11.. GGiiớớii tthhiiệệuu

33..11..11.. GGiiớ ớ ii tthhiiệệuu

Globus Toolkit là một bộ toolkit mã nguồn mở đượ c sử dụng để xây dựng các hệ

thống và các ứng dụng Grid. Globus Toolkit hiện đang đượ c phát triển bở i tổ chức

Globus Alliance và nhiều tổ chức khắ p nơ i trên thế giớ i. Globus Alliance là một

cộng đồng các cá nhân và tổ chức tham gia phát triển các công nghệ nền tảng cho

Grid.

Globus Toolkit cho phép hiện thực hoá các ý tưở ng, mục tiêu đằng sau khái

niệm Grid. Bộ toolkit bao gồm các dịch vụ và thư viện phục vụ việc bảo mật, hạ

tầng thông tin Grid, quản lý tài nguyên, quản lý dữ liệu, liên lạc, phát hiện lỗi,... Nó

đượ c đóng gói như một tậ p các thành phần có thể sử dụng độc lậ p hoặc k ết hợ p vớ inhau. Mỗi tổ chức đều có những hoạt động, chính sách khác nhau, việc k ết hợ p,

chia sẻ tài nguyên từ nhiều tổ chức bị cản tr ở bở i tính không tươ ng thích giữa các tài

nguyên. Globus Toolkit đượ c xây dựng để loại bỏ những tr ở ngại này. Các service,

interface, và protocol của nó cho phép ngườ i dùng truy cậ p đến các tài nguyên ở xa

như thể nó đang nằm trong máy tính của họ trong khi vẫn cho phép các tổ chức thiết

lậ p các chính sách cục bộ của mình như quản lý việc ai đượ c phép dùng tài nguyên

và khi nào,..Mặc dù Globus đượ c phát triển để phục vụ các dự án về khoa học và k ỹ thuật,

nhưng hiện nay Globus cũng đã đượ c áp dụng vào l ĩ nh vực thươ ng mại. Từ năm

2000, Các công ty hàng đầu thế giớ i trong l ĩ nh vực công nghệ thông tin như Avaki,

DataSynapse, Entropia, Fujitsu, Hewlett-Packard, IBM, NEC, Oracle, Platform, Sun

và United Devices, Microsoft đã bắt đầu xây dựng các chiến lượ c về Grid

Computing trên nền tảng Globus.




- 53 -

33..11..22.. LLịịcchh ssử ử pphháátt ttrriiểểnn

Cuối năm 1994, Rick Stevens ( Argonne National Laboratory) và Tom DeFanti

(Electronic Visualization Laboratory, University of Illinois, Chicago) đề nghị tạomột đườ ng k ết nối tạm thờ i giữa 11 mạng nghiên cứu tốc độ cao để tạo ra một Grid

xuyên quốc gia (I-WAY) trong 2 tuần tr ướ c và trong hội nghị Supercomputing ’95.

Một đội ngũ phát triển nhỏ đứng đầu là tiến sỹ Ian Foster (Argonne National

Laboratory) đã tạo nên các protocol cho phép ngườ i dùng của I-WAY chạy các ứng

dụng trên các máy tính nằm r ải rác khắ p nướ c Mỹ. Thành công này đã đượ c sự tài

tr ợ của tổ chức Defense Advanced Research Projects Agency (DARPA) để tiế p tục

nghiên cứu và phát triển.

Đến năm 1997, phiên bản đầu tiên của Globus Toolkit ra đờ i.

R ồi tiế p theo là sự phát hành của Globus Toolkit Version 1 (GT1-1998), Globus

Toolkit Version 2 (GT2-2002), Globus Toolkit Version 3 (GT3-2003) và hiện nay

là Globus Toolkit Version 4 (GT4-2005). GT1 và GT2 là các phiên bản xây dựng

theo các mô hình và giao thức độc quyền của tổ chức Globus, đến GT3, GT4 thì

chuyển sang xây dựng các Grid service theo các chuẩn OGSA và OGSI.

Luận văn này giớ i thiệu về bộ Globus Toolkit version 3.2. Các thành phần cấu

thành bộ GT 3.2 đượ c phát triển dướ i 2 hình thức khác nhau, giữ lại toàn bộ các

thành phần của GT2 nhằm đảm bảo tính tươ ng thích, phát triển mớ i các thành phần

dựa trên các chuẩn OGSA, OGSI và Web service vớ i mô hình kiến trúc Service

Oriented Architeture (SOA). Bộ GT3.2 là một bướ c trung gian để chuyển từ mô

hình cũ sang mô hình mớ i. Tiế p theo dướ i đây là một số công nghệ, chuẩn làm nền

tảng cho GT3.

33..22.. CCáácc ccôônngg nngghhệệ,, cchhuuẩẩnn lliiêênn qquuaann

33..22..11.. SSeerrvviiccee OOrriieenntteedd AArrcchhiitteettuurree ((SSOOAA))

Phần này giớ i thiệu đôi nét về một số khái niệm và thành phần cơ bản của kiến

trúc Service Oriented Architecture (SOA). SOA là kiến trúc của Web service và sau

đó là Grid Service.




- 54 -

33..22..11..11.. GGiiớ ớ ii tthhiiệệuu SSOOAA

SOA là một hướ ng tiế p cận mớ i trong kiến trúc phần mềm ứng dụng, trong đó,

một ứng dụng đượ c cấu thành từ một tậ p các thành phần độc lậ p, phân tán, phối hợ p

hoạt động vớ i nhau đượ c gọi là các service. Các service có thể đượ c phân tán bất cứ

nơ i nào, cả bên trong và ngoài một tổ chức. Xa hơ n nữa, các thành phần service có

thể tồn tại trên nhiều nền tảng khác nhau, và có thể đượ c cài đặt bở i các ngôn ngữ

lậ p trình khác nhau.

Điểm mấu chốt của SOA là các chức năng của service đượ c công bố dướ i dạng

một giao diện chuẩn. Chi tiết cài đặt cụ thể các chức năng đượ c che dấu, và ngườ i

dùng service cũng không cần quan tâm đến; ngườ i dùng chỉ gọi sử dụng các chức

năng của service thông qua các phươ ng thức công bố trên giao diện. Có thể thấy

tính đóng gói này đượ c k ế thừa từ phươ ng pháp lậ p trình hướ ng đối tượ ng.

Cùng vớ i sự hỗ tr ợ của các service cơ bản như lậ p lịch truy xuất tài nguyên

(scheduler service), chỉ mục (index service), tìm kiếm tài nguyên (discovery

service),…, ứng dụng có thể xác định trong thờ i gian thực thi các service có chứcnăng giống nhau từ nhiều nguồn, từ đó chọn ra service tốt nhất để sử dụng, đáp ứng

nhu cầu của ứng dụng.

33..22..11..22.. K K iiếếnn ttrrúúcc ccủủaa SSOOAA

Gồm các thành phần và các thông điệ p hoạt động trao đổi giữa chúng.

1. Các thành phần

SOA có 3 thành phần cơ bản là : Service Provider, Service Requestor và

Service Registry như trên hình 3-1.

Hình 3-1 Các thành phần của kiến trúc SOA.




- 55 -

+ ServiceProvider

Chịu trách nhiệm xây dựng các service, tạo các bản mô tả cho chúng, đăng

ký bản mô tả các service cho một hoặc nhiều ServiceRegistry; tiế p nhận, xử lý các

thông điệ p yêu cầu sử dụng service từ các ServiceRequestor.

+ ServiceRequestor

Là các thực thể sử dụng các service cung cấ p bở i ServiceProvider.

ServiceRequestor tìm kiếm các bản đặc tả service trong các ServiceRegistry, lựa

chọn service cần thiết và thích hợ p, r ồi sau đó k ết nối đến ServiceProvider và sử

dụng service mong muốn.

+ ServiceRegistryChịu trách nhiệm quảng bá các service do các ServiceProvider đăng ký cho

nó, và cho phép các ServiceRequestor tìm kiếm các đặc tả service trong danh sách

đăng ký của nó.

Lư u ý, một thành phần của ứng dụng có thể đóng một hay nhiều vai trò trên.

2. Các hoạt động chính

SOA có 3 loại hoạt động chính giữa các thành phần trên : Publish, Find và Bind.

+ Public

Là hoạt động giữa ServiceProvider và ServiceRegistry. ServiceProvider thực

hiện đăng ký giao diện service nó cung cấ p cho ServiceRegistry thông qua phươ ng

thức Public.

+ Find

Là hoạt động giữa ServiceRequestor và ServiceRegistry. ServiceRequestor sử dụng phươ ng thức Find để lấy danh sách service và ServiceProvider thoả mãn

các yêu cầu của nó. Có thể có nhiều điều kiện tìm kiếm trong phươ ng thức Find,

ServiceRegistry sẽ tìm trong danh sách các ServiceProvider r ồi tr ả về thông tin

thích hợ p.

+ Bind

Là hoạt động giữa ServiceRequestor và ServiceProvider. Nó cho phép

ServiceRequestor thực hiện k ết nối đến ServiceProvider tr ướ c khi thực hiện các lờ i




- 56 -

gọi sử dụng service. Cho phép ServiceRequestor khở i tạo proxy phía client cho

service cung cấ p bở i ServiceProvider. Thao tác k ết nối này có thể thực hiện động

hay t ĩ nh. Trong tr ườ ng hợ p k ết nối động, ServiceRequestor phát sinh proxy dựa trên

các thông tin lấy đượ c từ ServiceRegistry, trong tr ườ ng hợ p còn lại, proxy đượ c

phát sinh trong lúc phát triển ứng dụng.

33..22..22.. WWeebb SSeerrvviiccee

Web Service là một công nghệ đượ c sử dụng r ộng rãi để triển khai mô hình

SOA vào thực tế, nó đưa ra mô hình liên lạc, trao đổi giữa ứng dụng vớ i ứng dụng

trên cơ sở ngôn ngữ đặc tả XML. Web Service là nền tảng của Grid Service (sẽ giớ ithiệu sau).

Web Service sử dụng ngôn ngữ Web Services Description Language (WSDL)

để mô tả nội dung và cách sử dụng service; sử dụng protocol SOAP để trao đổi các

thông điệ p giữa các Web service; sử dụng ngôn ngữ đặc tả Universal Description,

Discovery and Integration (UDDI) để cho phép các nhà cung cấ p Web service đăng

ký service của mình và cho phép ngườ i sử dụng Web service tìm đượ c nhà cung cấ p

thỏa điều kiện mong muốn. Ngoài ra, còn một số chuẩn về định ngh ĩ a và triển khai

chất lượ ng dịch vụ của Web service đang đượ c xây dựng như WS-Security, WS-

Reliable Messaging, WS-Coordination, và WS-Transaction,…

Về bản chất, Web service cũng là một công nghệ tính toán phân tán như các

công nghệ CORBA, RMI, EJB, … Tuy nhiên, Web service có một số lợ i điểm mà

các công nghệ khác không có:

+ Web service độc lậ p vớ i ngôn ngữ lậ p trình, độc lậ p vớ i nền tảng thực thi

ứng dụng do đượ c xây dựng trên chuẩn XML. Đây cũng là lý do chính để chọn

công nghệ Web service làm nền tảng cho Grid service để giải quyết thách thức lớ n

nhất của công nghệ Grid computing là quản lý và sử dụng các tài nguyên phân tán,

đa dạng, phức tạ p, trên nhiều nền tảng khác nhau.

+ Hầu hết các Web service đều sử dụng protocol HTTP để truyền thông điệ p

(các yêu cầu service và k ết quả tr ả về từ service), nên hỗ tr ợ xây dựng các ứng dụng

tầm cỡ toàn cầu qua nhiều site, nhiều vùng bảo mật, nhiều vùng quản tr ị khác nhau




- 57 -

trên nền tảng Internet, do các lưu thông dạng HTTP thườ ng không bị chặn lại khi

gặ p firewall hoặc proxy. Trong khi đó, việc truyền thông của các công nghệ khác

thườ ng gặ p vấn đề vớ i firewall.

+ Một sự khác biệt nữa là, các công nghệ như CORBA và EJB hướ ng đến

các hệ thống phân tán có độ k ết hợ p cao (highly coupled), trong đó client và server

phải phụ thuộc chặt chẽ vào nhau. Các công nghệ này thườ ng lý tưở ng cho các ứng

dụng trong mạng cục bộ. Còn vớ i công nghệ Web service thì ngượ c lại hoàn toàn,

client không cần biết thông tin về server và service cho đến khi nó thực sự cần sử

dụng service. Do đó, công nghệ Web service thườ ng thích hợ p nhất để xây dựng các

ứng dụng có phạm vi r ộng trên Internet, như các ứng dụng hướ ng Grid. Công nghệ Web service có thể đượ c sử dụng để quản lý tài nguyên thay đổi động theo thờ i

gian.




- 58 -

33..22..33.. OOGGSSAA

33..22..33..11.. GGiiớ ớ ii tthhiiệệuu Dựa trên những kinh nghiệm có đượ c khi phát triển bộ GT đến phiên bản 2.0 hỗ

tr ợ việc xây dựng các hệ thống, ứng dụng Grid cùng vớ i việc phân tích các khía

cạnh k ỹ thuật và lợ i ích của công nghệ Web Service, tổ chức Globus Alliance, sau

đó là cùng vớ i tổ chức Global Grid Forum(GGF) đã xây dựng, phát triển các mô

hình và giải pháp để giải quyết các vấn đề, các thách thức của công nghệ Grid

Computing. Chuẩn OGSA ra đờ i từ những nỗ lực trên. Tổng quan về OGSA đã

đượ c giớ i thiệu trong chươ ng 2, phần này giớ i thiệu sâu vào chi tiết của chuẩn

OGSA.

Tư tưở ng chủ đạo của mô hình giải pháp OGSA là xem Grid như là một tậ p hợ p

có thể mở r ộng các Grid service, các Grid service này có thể đượ c k ết hợ p theo

nhiều cách khác nhau để thỏa mãn nhu cầu của các VO, và đến lượ t chúng, các VO

này lại đượ c xác định bằng các service mà chúng cung cấ p và chia sẻ.

Việc tiế p cận hướ ng service (service orientation) giúp giải quyết gần như tr ọn

vẹn các thách thức về quản lý, sử dụng tài nguyên, về liên k ết hoạt động trong Grid.

Nhờ tiế p cận theo hướ ng này, vấn đề liên k ết hoạt động có thể đượ c chia thành 2

vấn đề nhỏ hơ n là định ngh ĩ a giao diện của service và xây dựng các protocol để gọi

sử dụng một service cụ thể.

Việc tiế p cận hướ ng service còn làm đơ n giản quá trình ảo hóa, có ngh ĩ a là gói

gọn các cài đặt cụ thể tuỳ môi tr ườ ng, tuỳ nền tảng, … trong một giao diện chung.

Quá trình ảo hoá đưa ra một cách thức sử dụng tài nguyên cố định, chung nhất trêncác tài nguyên khác nhau, đa dạng về nền tảng, cho phép ánh xạ nhiều thực thể tài

nguyên logic trên cùng một tài nguyên vật lý. Việc ảo hoá còn cho phép k ết hợ p các

service cấ p thấ p thành các service cấ p cao có chức năng phức tạ p hơ n mà không cần

quan tâm đến chi tiết cài đặt của các service cấ p thấ p.






- 60 -

Grid service có thể đượ c nâng cấ p trong thờ i gian sống của nó, ví dụ để hỗ tr ợ

một phiên bản mớ i của protocol hoặc thêm các protocol thay thế. GSH không mang

thông tin xác định về protocol hay thông tin đặc biệt của instance như địa chỉ mạng

và các protocol hiện đang liên k ết (binding) vớ i nó. Thay vào đó, thông tin này

đượ c đóng gói cùng vớ i các thông tin khác cần thiết để liên lạc vớ i một instance

vào một thực thể tr ừu tượ ng đơ n lẻ, Grid service reference (GSR). Không giống như

GSH luôn cố định, GSR có thể đượ c thay đổi trong thờ i gian sống của instance. Một

GSR chỉ tồn tại trong một khoảng thờ i gian cụ thể, hoặc có thể tr ở nên không hợ p lệ

trong bất k ỳ thờ i điểm nào trong quá trình sống của instance. OGSA đã định ngh ĩ a

một số cơ chế, sẽ trình bày sau, để lấy một GSR đã cậ p nhật. Lưu ý r ằng, khi cóGSR cũng chưa chắc có thể truy cậ p đến Grid service instance, các chính sách cục

bộ hoặc các ràng buộc truy cậ p có thể ngăn chặn các yêu cầu sử dụng dịch vụ.

Mọi thứ trong OGSA đều là service nên cần phải xây dựng các Grid service thực

hiện quản lý các Grid service khác. Các tác giả OGSA đã xây dựng một tậ p các

interface cơ bản, mềm dẻo, các interface này sau đó có thể đượ c k ết hợ p theo nhiều

cách khác nhau để tạo ra một lượ ng phong phú các Grid service. Bảng … cho biết

tên và mô tả của các interface đượ c định ngh ĩ a cho đến hiện tại (06/2002).

Một lưu ý là : OGSA xác định các ngữ cảnh của một Grid service instance như

cách nó đượ c tạo ra, đượ c đặt tên, cách quản lý thờ i gian sống, cách liên lạc vớ i một

instance,… Tuy vậy, OGSA không giải quyết vấn đề cài đặt chúng như thế nào, ví

dụ về mô hình lậ p trình, ngôn ngữ lậ p trình, môi tr ườ ng thực thi,… Trong thực tiễn,

các Grid service đượ c tạo ra trong các môi tr ườ ng thực thi cụ thể hay hosting

environment (môi tr ườ ng chủ). Một hosting environment cụ thể xác định không

những các mô hình lậ p trình, ngôn ngữ lậ p trình, các công cụ phát triển, gỡ r ối, …

mà còn cách một cài đặt của Grid service thỏa mãn các quy định của nó để cung cấ p

chức năng của mình. Các ứng dụng hiện nay đang dựa vào các tiến trình của các hệ

điều hành cụ bộ như là hosting environment của mình, ví dụ việc tạo ra một service

instance liên quan đến việc tạo ra một tiến trình trong hệ thống.




- 61 -

33..22..33..33.. CCáácc iinntteerrf f aaccee cchhuuẩẩnn

Bảng 3-1 là danh sách các interface (trong WSDL là portType) định ngh ĩ a nên

một Grid service. Lưu ý, chỉ có interface GridService là phải đượ c cài đặt bở i tất cả

các Grid service, còn các interface khác là tuỳ chọn. Các interface phục vụ phân

quyền, quản lý chính sách, và các mục đích khác hiện đang đượ c xây dựng.

PortType Phươ ng thứ c Mô tả FindServiceData Truy vấn hàng loạt các thông tin về các Grid

service instance, bao gồm các thông tin cơ bản nội bộ (GSH, GSR, khóa chính,…) , các

thông tin về interface, các thông cụ thể củatừng instance… Hỗ tr ợ nhiều ngôn ngữ truyvấn khác nhau.

SetTerminationTime Thiết lậ p (Lấy) thờ i gian hủy bỏ của Gridservice instance.

GridService

Destroy Hủy bỏ một Grid service instance. Notification-Source

SubscribeTo- NotificationTopic

Yêu cầu thông báo về các sự kiện liên quanđến service. Cho phép phân phối thông quacác hệ thống chuyển thông điệ p bên thứ ba.

Notification-

Sink

DeliverNotification Tiến hành phân phối bất đổng bộ các thông

điệ p thông báo.RegisterService Thực hiện đăng ký một GSHRegistryUnregisterService Huỷ đăng ký một GSH

Factory CreateService Tạo một service instance mớ i.HandleMap FindByHandle Tr ả về GSR hiện đang liên k ết vớ i GSH đượ c

cung cấ p.

Bảng 3-1 Bảng các interface chuẩn quy định bở i OGSA.

33..22..33..44.. MMộộtt ssốố ccơ ơ cchhếế ccủủaa OOGGSSAA

1. Tạo các service ngắn hạn : Factory

OGSA định ngh ĩ a một lớ p các Grid service triển khai một interface phụ trách

việc tạo lậ p các Grid service instance. Interface này đượ c gọi là Factory và service

triển khai interface này là một factory (nhà máy). Phươ ng thức CreateService của

interface Factory tạo mọt instance của service đượ c yêu cầu, tr ả về GSH và khở i tạo

GSR cho service instance mớ i.

Interface Factory không xác định cách thức cụ thể để tạo ra service instance.

Một cách chung nhất, interface Factory đượ c triển khai trong các host environment






- 63 -

xuất hiện vấn đề mớ i, đó là làm sao lấy đượ c một GSR hợ p lệ khi GSR khở i đầu hết

hạn, Vấn đề trên có thể phát biểu lại như sau : Bằng cách nào có thể giao tiế p vớ i

một Grid service instance khi chỉ biết GSH của nó.

OGSA tiế p cận theo hướ ng xây dựng một interface ánh xạ từ GSH sang GSR

(HandleMap). Các phươ ng thức cung cấ p bở i interface này sẽ lấy một GSH và tr ả

về một GSR hợ p lệ tươ ng ứng. Các phươ ng thức này có thể đượ c áp dụng các chính

sách quản lý truy cậ p và do đó, các yêu cầu sử dụng có thể bị từ chối. Một bản cài

đặt của interface HandleMap có thể theo dõi xem Grid service instance nào hiện còn

đang tồn tại và sẽ không tr ả về GSR của instance mà nó biết hiện đã k ết thúc. Lưu ý

là khi có một GSR hợ p lệ trong tay cũng chưa chắc là có thể liên lạc đượ c vớ i Gridinstance, nó có thể không hoạt động, hoặc k ết thúc trong khoảng thờ i gian từ lúc

đưa ra GSR đến lúc lấy đượ c GSR.

Tiế p theo, khi đã có interface HandleMap, việc giải quyết vấn đề làm sao lấy

đượ c GSR theo GSH sẽ dẫn đến việc cần phải giải quyết 2 vấn đề nhỏ hơ n:

+ Xác định service handleMap nào đang chứa GSH cần tìm.

+ Liên lạc vớ i handleMap để lấy đượ c GSR tươ ng ứng.

Cách giải quyết 2 vấn đề trên như sau:

Để đảm bảo luôn luôn ánh xạ đượ c từ GSH sang GSR, yêu cầu tất cả các

Grid service instance phải đượ c đăng ký vớ i ít nhất một handleMap, đượ c gọi là

home handleMap. Việc đưa vào GSH mã nhận dạng của handleMap giúp dễ dàng

trong việc xác định handleMap nào phải liên lạc để lấy đượ c GSR. Làm sao để xác

định home handleMap cho GSH? Bất k ỳ service triển khai interface HandleMap

cũng là Grid service, và cũng có GSH, nếu vớ i cách khở i tạo như trên, sẽ tr ở lại vấn

đề là phải cố gắng lấy đượ c GSR liên k ết vớ i GSH handleMap service. Để giải

quyết triệt để vấn đề này, cần phải có một cách lấy đượ c GSR của handleMap mà

không cần một handleMap khác. Để giải quyết đượ c, tất cả các home handleMap

service đều đượ c xác định bở i một URL và phải hỗ tr ợ liên lạc vớ i cùng một

protocol chuẩn mà ai cũng biết, ví dụ HTTP. Lúc đó, thay vì phải dùng GSR để xác

định protocol liên lạc vớ i handleMap service, sẽ sử dụng phươ ng thức GET của






- 65 -

5. Notification

OGSA notification framework cho phép client đăng ký nhận các thông tin

cần đượ c thông báo từ các service instance và hỗ tr ợ việc phân phối bất đồng bộ,

một chiều từ nguồn đến đích (client) các thông báo cần thiết. Để có thể nhận các

thông điệ p, client thực hiện đăng ký GSH của mình và các thông tin cần đượ c thông

báo cho service instance nguồn, sau đó nguồn sẽ gửi các thông điệ p về các thông tin

đượ c yêu cầu cho client, trong khi client gửi các thông điệ p định k ỳ để báo cho nơ i

gửi biết là mình vẫn còn cần nhận thông tin.

33..22..44.. OOGGSSII vvàà GGrriidd SSeerrvviiccee

Như đã biết, OGSA không đi sâu vào việc đặc tả các Grid Service. Nó chỉ cơ

bản phác thảo một mô hình của các hệ thống Grid vớ i các Grid Service và phác thảo

những thứ mà một Grid Service cần phải có. OGSI là một chuẩn nhằm triển khai cụ

thể các khái niệm đưa ra bở i OGSA, nó đưa ra các đặc tả chính thức mang tính k ỹ

thuật về Grid Service dựa trên công nghệ Web service. Nói một cách khác, OGSI là

một chuẩn để xây dựng các Grid Service. Theo OGSI, Grid Service Chuẩn OGSI

1.0 ra đờ i vớ i các mục đích cụ thể:

+ Giớ i thiệu các quy ướ c dựa theo WSDL đượ c sử dụng trong các đặc tả về

Grid service, các quy ướ c này hiện đã đượ c tích hợ p trong WSDL 1.2 (đang phát

triển).

+ Định ngh ĩ a service data, đưa một cách thức chuẩn để trình bày và truy vấn

các siêu dữ liệu (metadata) và các thông tin tr ạng thái của các service instance.

+ Giớ i thiệu các thuộc tính chính, cơ bản của một Grid service, bao gồm:

Định ngh ĩ a Grid service description và Grid service instance.

Định ngh ĩ a cách tính thờ i gian của mô hình OGSI.

Định ngh ĩ a Grid Service Handle và Grid Service Reference.

Định ngh ĩ a một hướ ng tiế p cận chung để chuyển các thông tin lỗi từ

các hoạt động. Hướ ng tiế p cận này xây dựng một lượ c đồ XML và các ngữ

ngh ĩ a liên quan cho các thông điệ p lỗi WSDL để hỗ tr ợ một cách hiểu chung.








- 68 -

instance, nó có thể tr ở nên không hợ p lệ tại bất k ỳ thờ i điểm nào. Việc kiểm tra xem

một GSR có hợ p lệ hay không là trách nhiệm của client. Khi một GSR không hợ p

lệ, client phải lấy một GSR mớ i thông qua GSH.

Dướ i đây định ngh ĩ a của GSH và GSR đướ i dạng XML:

+ Định ngh ĩ a GSH

+ Định ngh ĩ a GSR

Tài liệu WSDL biểu diễn thông tin GSR chỉ cần chứa các thông tin cần thiết

nhất để có thể liên lạc vớ i một service instance cụ thể, định dạng như sau:

+ Service Locator

targetNamespace = http://www.gridforum.org/namespaces/2003/03/OGSI

<xsd:element name="handle" type="ogsi:HandleType"/>

<xsd:simpleType name="HandleType">

<xsd:restriction base="xsd:anyURI"/></xsd:simpleType>


<xsd:element name="reference" type="ogsi:ReferenceType"/>

<xsd:complexType name="ReferenceType" abstract="true">

<xsd:attribute ref="ogsi:goodFrom" use="optional"/>

<xsd:attribute ref="ogsi:goodUntil" use="optional"/></xsd:complexType>

targetNamespace = http://www.gridforum.org/namespaces/2003/03/OGSI ”

<xsd:complexType name="WSDLReferenceType">

<xsd:complexContent>

<xsd:extension base="ogsi:ReferenceType"><xsd:sequence>

<xsd:any namespace=”http://schemas.xmlsoap.org/wsdl/”

minOccurs="1" maxOccurs="1" processContents="lax"/>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>




- 69 -

Là một cấu trúc k ết hợ p không hoặc nhiều GSH, không hoặc nhiều GSR,

không hoặc nhiều interface (portType) QName, dùng để k ết hợ p GSH, GSR,

interface lại thành một đơ n vị cơ bản để dễ sử dụng. Service Locator có thể đượ c sử

dụng trong bất cứ phươ ng thức nào chấ p nhận GSH hoặc GSR. Định ngh ĩ a service

locator như sau:

33..22..44..44.. IInntteerrf f aaccee

OGSI mở r ộng khái niệm portType của WSDL để hiện thực hoá khái niệm

interface đượ c đề cậ p đến trong OGSA. Trong OGSI, wsdl:portType đượ c địnhngh ĩ a lại thành interface của Grid service (gwsdl:portType) như sau:


<xsd:element name="locator" type="ogsi:LocatorType"/>

<xsd:complexType name="LocatorType">

<xsd:sequence>

<xsd:element ref="ogsi:handle"

minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="ogsi:reference"minOccurs="0" maxOccurs="unbounded"/>

<xsd:element name=”interface” type=”QName”


</xsd:sequence>

</xsd:complexType>

…

targetNamespace=

http://www.gridforum.org/namespaces/2003/03/gridWSDLExtensions

xmlns:gwsdl=

http://www.gridforum.org/namespaces/2003/03/gridWSDLExtensions

…

<element name="portType" type="gwsdl:portTypeType"/>

<complexType name="portTypeType">

<complexContent><extension base="wsdl:portTypeType">

<sequence>

<any namespace="##other"


</sequence>

<attribute name=”extends” use=”optional”>

<simpleType>

<list itemType=”QName”/>

</simpleType>

</attribute>

<anyAttribute namespace="##other"/>

</extension>

</complexContent></complexType>




- 70 -

Thuộc tính extends trong gwsdl:portType là một danh sách các QName, mỗi

QName là một wsdl:portType hoặc gwsdl:portType. Việc định ngh ĩ a các phươ ng

thức trên interface đượ c k ế thừa lại từ wsdl:portTypeType.

Về chi tiết các interface của Grid service định ngh ĩ a bở i OGSI 1.0, xin xem

thêm trong Phụ lục D – “Các interface của một OGSI Service”

33..22..44..55.. SSeerrvviiccee ddaattaa

Service data là một tậ p các thông tin có cấu trúc về Grid service instance nhằm

cung cấ p các thông tin tr ạng thái của nó theo yêu cầu. Grid service đượ c phân loại

và chỉ mục theo các thông tin trong service data. Mỗi instance của Grid service đều

có một tậ p các service data chứa các thành phần Service Data Element (SDE), các

SDE có thuộc nhiều loại khác nhau, nhưng các SDE cùng loại thì luôn chứa cùng

một loại thông tin.

Ý tưở ng biểu diễn các thuộc tính của service instance như là service data đượ c

k ế thừa từ ý tưở ng của lậ p trình hướ ng đối tượ ng, các service data chỉ đượ c truy vấn

và thao tác bở i các phươ ng thức định ngh ĩ a trong interface. Chỉ các thông tin cầncung cấ p cho bên ngoài mớ i đượ c khai báo như là service data, còn các thông tin

nội bộ của service thì không đượ c khai báo.

Các SDE có thể là t ĩ nh (khai báo trong khi định ngh ĩ a service interface) hoặc

động (đượ c thêm vào service instance trong thờ i gian chạy). Client có thể sử dụng

phươ ng thức findServiceData của interface GridService để lấy danh sách các SDE

của service instance.

+ Cấu trúc của một Service Data

Một service data có các thuộc tính cơ bản sau: name, type, minOccurs,

maxOccurs, nillable, mutability, và modifiable. Định ngh ĩ a XML của chúng xin

tham khảo tài liệu [6].




- 71 -

Tên Kiểu giá trị Tập giá trịGiá trị default

Diễn giải

name NCName and

{targetnamespace}

Tên của serviceData

type QName Xác định kiểu XMLSchema quy định giá tr ị của SDE.

minOccurs nonNegativeInteger

unbounded(không giớ ihạn)

1 Xác định số giá tr ị SDEnhỏ nhất xuất hiện trongserviceDataValues hoặcstaticServiceDataValues,nếu là 0 là tuỳ chọn

maxOccurs nonNegativeInteger unbounded 1 Xác định số giá tr ị SDElớ n nhất xuất hiện trongserviceDataValues hoặcstaticServiceDataValues

nillable boolean true/false false Có cho phép SDE có giátr ị nil (là một giá tr ị cóthuộc tính xsi:nil vớ ivalue=“true”).

mutability “static”,“constant”,

“extendable”, “mutable”

“extenda ble”

Quy định cách thức thayđổi một SDE.

+ “static” : giá tr ị củaSDE đượ c xác định trongthành phầnstaticServiceDataValuesvà đượ c giữ lại trong bấtcứ instance nào có

portType chứa SDE đó.+ “constant” : giá tr ị củaSDE đượ c gán trong lúctạo instance và đượ c giữ

không đổi trong suốt thờ igian sống của instance.+ “extendable” : Cho

phép thêm các thành phầnmớ i vào SDE trong thờ igian chạy, các thành phầnmớ i khi đã đượ c thêm vàosẽ không thể loại bỏ khỏiSDE đượ c nữa.+ “mutable” : tất cả các

thành phần của SDE cóthể đượ c thêm vào hay




- 72 -

loại bỏ bất cứ lúc nào.modifiable boolean true/false false Nếu true, cho phép client

cậ p nhật tr ực tiế p giá tr ị SDE thông qua phươ ngthức setServiceData.

Các thuộc tính khác không cótrong namespace

Bảng 3-2 Các thuộc tính cơ bản của một service data.

+ Mở rộng portType để hỗ trợ Service Data

OGSI định ngh ĩ a thêm một thành phần con của portType có tên là

serviceData, đượ c sử dụng để khai báo các thành phần serviceData (SDE) đi kèm

vớ i portType đó. Các giá tr ị khở i tạo cho serviceData đượ c xác định bằng thành

phần staticServiceDataValues của portType. Dướ i đây là định ngh ĩ a

Ví dụ dướ i đây khai báo một portType vớ i 2 thành phần serviceData vớ i tên là

“Host” và “CPU Architecture” và khở i tạo giá tr ị Host=“GLOBUSTEST”.Mọi

service instance triển khai portType này phải có thông tin về Host và

CPUArchitecture.

<gwsdl:portType name="NCName"> *

<wsdl:documentation … /> ?

<wsdl:operation name="NCName"> … </wsdl:operation> ?

…………

<sd:serviceData name="NCName" … /> *<sd:staticServiceDataValues>?

<some element>*</sd:staticServiceDataValues>

……………

<wsdl:definitions xmlns:tns=”xxx” targetNamespace=”xxx”>

<gwsdl:portType name="ServiceDataExample"> *

<wsdl:operation name=…> … </wsdl:operation>

…

<sd:serviceData name="Host" type=”xsd:String” mutability=”static”/>

<sd:serviceData name="CPUArchitecture" type=”tns:SomeComplexType”/>…<sd:staticServiceDataValues>

<tns:Host>GLOBUSTEST</tns:Host></sd:staticServiceDataValues>

</gwsdl:portType>




- 73 -

33..22..44..66.. LLiif f eeccyyccllee

Tất cả các thực thể đều có một chu trình sống của mình, chu trình sống là các

bướ c chuyển tr ạng thái từ lúc thực thể đượ c tạo ra đến khi bị huỷ đi. Việc quản lýchu trình sống của service instance r ất quan tr ọng nhất là khi service cần phải hỗ tr ợ

khả năng phục hồi hoạt động vớ i các giá tr ị và tr ạng thái khi server hoặc container

khở i động lại. Các cơ chế cài đặt cụ thể để quản lý chu trình sống của service

instance tùy thuộc vào host environment, OGSI không quy định các cơ chế này, tuy

nhiên OGSI định ngh ĩ a các interface cho phép client thao tác vớ i các sự kiện trong

chu trình sống của service instance một cách tổng quát.

+ Về tạo lập service instance

Client có thể gọi phươ ng thức createService của một service instance có cài

đặt interface Factory để tạo một service instance mớ i.

+ Về huỷ bỏ service instance

Client có thể yêu cầu huỷ service instance một cách tườ ng minh bằng cách

gọi phươ ng thức destroy của interface GridService mà service instance nào cũng cài

đặt; hay quy định thờ i gian sống cho service instance (qua các phươ ng thức

requestTerminationBefore/After của interface GridService) , sau thờ i gian đó mà

service instance không nhận đượ c yêu cầu gia hạn từ các client, thì service instance

sẽ tự huỷ. Service instance đượ c phép quyết định khi nào thì sẽ kéo dài thờ i gian

sống hoặc khi nào sẽ k ết thúc (ví dụ : service instance có thể k ết thúc tr ướ c thờ i hạn

do không còn tài nguyên,…)

Bên cạnh đó, các service instance có thể cung cấ p khả năng thông báo về các

sự kiện liên quan đến các chu trình sống của mình thông qua cơ chế Notificationchuẩn (các phươ ng thức của các interface NotificationSource/Sink/Subscription)

33..22..44..77.. NNoottiif f iiccaattiioonn

Là một cơ chế cho phép nguồn thông báo (notification source) phân phối các

thông điệ p đến các nơ i yêu cầu (notification sink). Một số khái niệm liên quan:

+ Notification source




- 74 -

Là một service instance có cài đặt interface NotificationSource, và là nơ i gửi

thông báo đến các Notification sink

+ Notification sink

Là một service instance nhận các thông báo từ nhiều Notification source

khác nhau. Một sink phải cài đặt interface NotificationSink để nhận đượ c các thông

báo.

+ Notification message

Là một thông điệ p XML đượ c gửi từ Notification source đến sink. Kiểu của

thông điệ p đượ c xác định bở i Subscription expression.

+ Subscription expression Là một lượ c đồ XML mô tả thông điệ p nào và khi nào thông điệ p đượ c gửi

đi, dựa trên sự thay đổi các giá tr ị SDE của service instance.

+ Hoạt động

1. Để thiết lậ p quá trình gửi nhận thông điệ p, một yêu cầu cần nhận thông

điệ p chứa Subscription expression, vị trí của Notification sink, và khoảng thờ i gian

trong đó cần nhận thông điệ p đượ c gửi đến Notification source.

2. Yêu cầu này có thể dẫn đến việc tạo một service instance, gọi là

Subscription, có cài đặt interface NotificationSource. Và instance này sẽ chịu trách

nhiệm trao đổi các thông báo.

Ghi chú : Để có thể hiểu rõ hơ n về Grid service và các cơ chế của nó, xin xem

thêm trong phụ lục C - “K ỹ thuật cài đặt các cơ chế của Grid Service”

33..33.. KKiiếếnn ttr r úúcc GGlloobbuuss TToooollkkiitt

Bộ Globus Toolkit giải quyết các vấn đề của công nghệ Grid Computing dựa

trên 4 thành phần chính. 3 thành phần Resource Management, Information Service,

Data Management liên k ết hoạt động trên nền tảng bảo mật chung, Sercurity

Infrastructure. Ngoài ra, GT còn cung cấ p một bộ các hàm API và SDK nhằm giúp

phát triển, xây dựng các ứng dụng Grid.






- 76 -

Hình 3-3 Mô hình các thành phần của một hệ thống sử dụng GT2

33..33..22.. MMôô hh ì ìnnhh k k iiếếnn ttrrúúcc GGTT33

Mô hình GT3 hơ i khác biệt hơ n mô hình GT2, cũng 4 thành phần đó, nhưng các

thành phần này đượ c thiết k ế để tr ở thành các OGSI Grid service, đượ c truy xuất

thông qua một giao diện chung, điều này giúp việc các ứng dụng sử dụng các

service dễ dàng hơ n.

Dướ i đây là mô hình tổ chức các thành phần của GT3 :




- 77 -

Hình 3-4 Mô hình tổ chứ c các thành phần GT3.

Các khung có nền tr ắng là các thành phần cung cấ p bở i GT3 Core. Chúng là các

khối cơ bản để xây dựng các Grid service. Thành phần OGSI Reference

Implementation cài đặt cho tất cả các interface xác định bở i OGSI cũng như các

hàm API và công cụ để phát triển các OGSI Grid service. Thành phần Security

Infrastructure cung cấ p các dịch vụ truyền thông SOAP cũng như thực hiện bảo vệ

các thông điệ p, chứng thực hai chiều (mutual authentication), và đăng nhậ p một lần;

thiết k ế lại nền tảng GSI trong GT2 để hoạt động trong môi tr ườ ng OGSI. Hai khối

cơ bản này không cung cấ p các service thực thi đượ c nhưng như là cơ sở của tất cả

các service khác. Tuy nhiên, GT3 Core cũng có một số service có khả năng thực thi

nền tảng đủ tổng quát để đượ c sử dụng và liên k ết vớ i tất cả các Grid service khác.

Những service này đượ c gọi là System-Level Service, đượ c xây dựng trên cơ sở

OGSI Reference Implementation và Security Infrastructure. GT3 cũng cung cấ p

một số service cấ p cao hơ n, Base Service, như các service quản lý tài nguyên

(MMJFS) , quản lý dữ liệu (RFT), các service cung cấ p thông tin (Index service).

Khái niệm User-Defined Service dùng để chỉ các service cấ p cao hơ n nữa, không

cung cấ p bở i GT3, đượ c xây dựng trên tất cả thành phần của GT3 bao gồm luôn

Base Service.

Tất cả các service và các thành phần cơ bản tươ ng tác vớ i một môi tr ườ ng thực

thi OGSI ảo, gọi là Grid Service Container. Mục đích của container là làm lớ p phân






- 79 -

33..44.. CCáácc tthhàànnhh pphhầầnn cchhíínnhh

33..44..11.. SSeerrccuurriittyy IInnf f rraassttrruuccttuurree

33..44..11..11.. GGiiớ ớ ii tthhiiệệuu

Trong GT, việc bảo mật Grid đượ c đảm trách bở i module Grid Security

Infrastructure (GSI). Như đã biết, yêu cầu về bảo mật, an toàn là một trong những

vấn đề chính trong các thiết k ế Grid. Các thành phần bảo mật cơ sở của GT đã đưa

ra các cơ chế khá tốt để thực hiện việc chứng thực, phân quyền, bảo mật liên lạc

giữa các node trong Grid.GSI là một sự mở r ộng các protocol và API của các chuẩn về bảo mật hiện hành.

GSI đượ c xây dựng trên các công nghệ, các chuẩn như :

+ Mô hình mã hoá khóa công khai (public key infrastructure(PKI))

+ X.509 certificate

+ Protocol Secure Sockets Layer (SSL)

Tất cả các k ết nối liên lạc trong Grid đều đượ c mã hoá theo công nghệ

RSA 1024 bit và truyền tải vớ i protocol SSL.

+ Generic Security Service API (GSS-API)

Toàn bộ phần cài đặt của GSI đều tuân theo GSS-API (là một bộ API

chuẩn dành cho các hệ thống bảo mật đượ c tổ chức Internet Engineering

Task Force (IETF) đưa ra).

GSI đã mở r ộng các chuẩn này để cung cấ p thêm chức năng đăng nhậ p một lần

(single sign-on), ủy quyền (delegation), identity mapping (ánh xạ thực thể).

Một số chức năng chính của GSI

+ Chứ ng thự c một/hai chiều (Single/Mutual authentication)

+ Có cơ chế truyền thông an toàn.

+ Có cơ chế chứ ng thự c.

+ Có cơ chế uỷ quyền.

Hình 3-5 tóm tắt cấu trúc và chức năng các thành phần của GSI




- 80 -

Hình 3-5 Các thành phần của GSI.

Dướ i đây giớ i thiệu một số khái niệm và cơ chế chủ yếu của GSI.

33..44..11..22.. CCáácc nngguuyyêênn ttắắcc vvàà k k hhááii nniiệệmm ccơ ơ bbảảnn ttrroonngg bbảảoo mmậậtt GGrriidd

1. Các nguyên tắc cơ bản

L ĩ nh vực bảo mật bao gồm 3 dịch vụ cơ bản : chứng thực (authentiacation),

phân quyền (authorization) và mã hoá (encryption). Một tài nguyên Grid phải đượ c

chứng thực tr ướ c tiên nhằm xác định các hoạt động nào đượ c phép trong Grid. Khi

các tài nguyên Grid đã đượ c chứng thực, Grid user có thể đượ c cấ p các quyền thích

hợ p để sử dụng các tài nguyên. Tuy nhiên, các việc này vẫn chưa bảo vệ đượ c dữ

liệu trong quá trình trao đổi giữa các node. Do đó, cần phải cần thêm dịch vụ mã

hoá dữ liệu.

Tổ chức International Organization for Standardization (ISO) đã đưa ra danh

sách các dịch vụ cơ bản trong các hệ thống bảo mật hiện đại, trong các tài liệu ISO

7498-2 (OSI Security Architecture) và ISO 10181 (OSI Security Frameworks). Một

số dịch vụ liên quan đến bảo mật Grid đượ c giải thích dướ i đây:

+ Authentication (chứ ng thự c)Là quá trình xác minh tính hợ p lệ của một cá nhân, và xác định ngườ i đó

là ai. Không chỉ có con ngườ i mớ i cần đượ c chứng thực, các service, ứng

dụng, và các thực thể khác cũng cần đượ c chứng thực trong hệ thống Grid.

+ Access control

Đảm bảo mỗi ngườ i dùng hay máy tính sử dụng service đượ c phép thực

hiện những gì anh ta muốn làm. Quá trình phân quyền thườ ng đượ c dùng

đồng ngh ĩ a vớ i access control.




- 81 -

+ Data integrity

Đảm bảo dữ liệu không bị thay đổi hay phá hủy bở i các hoạt động trái

phép.

+ Data confidentiality

Đảm bảo các thông tin nhạy cảm không đượ c tiết lộ cho các tổ chức

không liên quan. Data confidentiality còn đượ c gọi là sự riêng tư (privacy)

+ Key management

Liên quan đến việc phát sinh, phân phối, chứng thực, lưu tr ữ một cách an

toàn các khóa sử dụng trong quá trình mã hóa, giải mã các thông điệ p.

GSI cùng vớ i Public Key Infrastructure(PKI) cung cấ p một framework (baogồm các protocol, service, và các chuẩn) nhằm hỗ tr ợ Grid vớ i 5 dịch vụ trên.

2. Các khái niệm quan trọng trong bảo mật Grid và GSI

+ Symmetric Encryption

Mã hoá kiểu Symmetric dựa trên việc sử dụng một khoá bí mật để thực hiện

mã hoá và giải mã dữ liệu. Để đảm bảo dữ liệu chỉ đượ c đọc bở i bên gửi và bên

nhận, khoá đượ c trao đổi một cách bí mật giữa 2 bên. Nếu ai đó lấy đượ c khóa bí

mật đã sử dụng để mã hoá, họ có thể giải mã đượ c thông tin.

Phươ ng pháp mã hoá này kém an toàn nhưng tốc độ mã hóa/giải mã lại

nhanh hơ n dạng mã hoá Asymmetric trình bày dướ i dây.

+ Asymmetric Encryption

Phươ ng pháp này đượ c gọi là phươ ng pháp mã hoá khoá công khai, cũng

đượ c sử dụng r ất thườ ng xuyên. Phươ ng pháp này sử dụng một cặ p khoá để mã hóa

(đượ c gọi là khóa công khai (public key) và khóa bí mật (private key)). Khóa để mãhoá khác vớ i khoá đượ c sử dụng để giải mã. Phươ ng pháp mã hoá khóa công khai

yêu cầu các bên phải bảo vệ k ỹ các khóa bí mật của mình, trong khi khóa công khai

của họ không cần đượ c bảo vệ, có thể đượ c công bố r ộng rãi trong cộng đồng.

Thông thườ ng, khóa công khai đượ c để trong các chứng chỉ điện tử (digital

certificate) đượ c cấ p bở i Certificate Authority, nơ i chịu trách nhiệm quản lý các

khóa công khai và ngườ i chủ của khóa công khai tươ ng ứng.






- 83 -

Khi một thực thể trong Grid muốn bắt đầu một phiên làm việc vớ i đối tác

nào đó, nó sẽ đính kèm chứng chỉ điện tử của mình vào thông điệ p thay vì khóa

công khai. Bên nhận kiểm tra chữ ký của CA trong chứng chỉ vừa nhận đượ c. Nếu

chữ ký đó là của một CA mà bên nhận tin tưở ng, thì nó có thể chấ p nhận và tin

tưở ng r ằng khóa công khai trong chứng chỉ thực sự đến từ nơ i gửi (thao tác này đề

phòng tr ườ ng hợ p giả danh ngườ i chủ của khóa công khai). Sau đó, bên nhận sẽ sử

dụng khóa công khai của bên gửi để giải mã SSL session ID, SSL ID này dùng để

mã hoá tất cả các dữ liệu truyền thông giữa 2 bên.

Các chứng chỉ điện tử của GSI dựa định dạng chứng chỉ X.509, một định

dạng chuẩn về chứng chỉ điện tử do tổ chức Internet Engineering Task Force (IETF)đưa ra. Những chứng chỉ này có thể dùng đượ c vớ i các phần mềm dựa trên PKI

khác bao gồm các trình duyệt web của Microsoft, Netscape.

Về cấu trúc và quá trình cấ p một chứng chỉ điện tử, xin xem trong phụ lục E-

Cấu trúc chứng chỉ điện tử.

* Các loại chứ ng chỉ điện tử

Có 2 loại chứng chỉ khác nhau đượ c dùng trong môi tr ườ ng Grid. Loại

thứ nhất là chứng chỉ dành cho ngườ i dùng (user certificate) và chứng chỉ

dành cho các Grid server (Server certificate).

- User certificate

Một ngườ i dùng sẽ cần một user certificate để đại diện cho mình,

chứng chỉ này xác định tên ngườ i dùng thực sự của Grid chứ không phải

tên một server hay tên máy tr ạm. Ví dụ, có một ai đó tên Bobby, thì trong

chứng chỉ điện tử của anh ta có thể có một distinguished name như sau:

“/O=Grid/O=GridTest/OU=test.domain.com/CN=Bobby"

- Server certificate

Nếu một ngườ i dùng muốn chạy các ứng dụng yêu cầu chứng thực

trên server, sẽ cần phải có một server certificate. Server certificate sẽ ghi

fully-qualified domain name của server vào user certificate của ngườ i đó.

Để user certificate có hiệu lực, full-qualified DNS name của ngườ i đó




- 84 -

phải giống như trong user certificate. Ví dụ : nếu tên server là “Darksky”,

tên trong server certificate có thể là :

/CN=Service/Darksky.<domain>.<com>

+ Certificate Authority (CA)

Việc bảo mật trong Grid đượ c xác lậ p thông qua việc sử dụng các chứng chỉ

ở mức host và ngườ i dùng, các chứng chỉ này sau đó đượ c ánh xạ vào các ngườ i

dùng cục bộ trên host. Để có đượ c các chứng chỉ này, các bản yêu cầu xin cấ p

chứng chỉ đượ c tạo ra, gửi đến một CA tin cậy, CA này sẽ thực hiện ký xác nhận

vào chứng chỉ và gửi lại ngườ i yêu cầu.

Một CA đúng ngh ĩ a có nhiều trách nhiệm khác nhau trong môi tr ườ ng Grid.Các trách nhiệm chính của một CA tốt bao gồm :

- Xác định đượ c các thực thể đang yêu cầu cấ p chứng chỉ.

- Cấ p phát, loại bỏ và lưu tr ữ các chứng chỉ.

- Bảo vệ các CA server.

- Quản lý không gian tên cho các chủ sở hữu chứng chỉ.

- Theo dõi các hoạt động.

Trong một số môi tr ườ ng PKI, có thêm một Registrant Authority (RA) hoạt

động liên k ết vớ i CA để thực hiện các nhiệm vụ trên. RA chịu trách nhiệm kiểm tra

và đảm bảo các thông tin ngườ i dùng là đúng đắn và hợ p lệ, chấ p thuận hay từ chối

các yêu cầu cấ p chứng chỉ tr ướ c khi chuyển yêu cầu đến CA. Globus Toolkit có

cung cấ p một module simple CA để phục vụ cho việc thử nghiệm các ứng dụng

trong một tr ườ ng Grid. Trong tr ừơ ng hợ p này, simple CA kiêm luôn chức năng của

CA và RA. Khi số lượ ng chứng chỉ tăng lên, thườ ng sẽ tách thành 2 nhóm CA vàRa riêng lẻ.

Một vấn đề then chốt trong môi tr ườ ng PKI là đảm bảo tính tin cậy, có thể

tin tưở ng của hệ thống. Tr ướ c khi một CA có thể ký, đóng dấu và cấ p chứng chỉ cho

các thực thể khác, nó cũng phải làm một việc tươ ng tự cho chính nó, để bản thân

CA có thể đượ c đại diện bằng chứng chỉ của mình. Điều đó có ngh ĩ a CA cần phải

làm các công việc sau:

1. CA phát sinh ngẫu nhiên cặ p khóa cho nó.




- 85 -

2. CA lưu tr ữ bảo mật khóa bí mật của nó.

3. CA tự tạo ra chứng chỉ cho chính mình.

4. CA ký xác nhận chứng chỉ đó bằng khóa bí mật của mình.

Một số lưu ý vớ i CA:

- Khóa bí mật của CA là một trong những phần qua trong nhất trong toàn

bộ môi tr ườ ng PKI. Nó đượ c dùng để ký xác nhận các chứng chỉ trong môi

tr ườ ng Grid, do đó, nếu có ai lấy đượ c khóa bí mật của CA thì họ sẽ có thể

giả danh bất cứ ai trong môi tr ườ ng Grid. Do đó cần thực hiện tất cả các giải

pháp bảo mật có thể để bảo vệ khóa bí mật của CA.

- Thông thườ ng, trong một môi tr ườ ng Grid đơ n lẻ, một CA sẽ cung cấ pchứng chỉ cho một nhóm cố định các ngườ i dùng. Tuy nhiên, nếu có 2 công

ty hoặc VO cần phải liên lạc vớ i nhau, và cần phải tin tưở ng đối tác của

mình. Điều này yêu cầu cả hai CA phải tin tưở ng lẫn nhau hay cùng tham gia

vào một vùng cho phép sử dụng chéo chứng chỉ (cross certification). Ví dụ :

Alice, một nhân viên thuộc một tổ chức vớ i CA riêng của mình, muốn thực

thi một công việc trên một máy tính thuộc Grid của Mike, nằm ngoài tổ chức

và thuộc về một CA khác. Để có thể thực hiện đượ c điều đó, các điều sau cần

đượ c xem xét:

_Alice và Mike cần một cách để có thể lấy đượ c khóa công khai chứng

chỉ của đối tác.

_Mike cần phải chắc chắn là có thể tin tưở ng đượ c CA của Alice và

ngượ c lại.

Các máy tính trong Grid, đến từ nhiều vùng bảo mật hay các VO khác

nhau, cần phải tin tưở ng vào chứng chỉ của đối tác, do đó, các vai trò và các

mối quan hệ giữa các CA cần phải đượ c xác định. Điều này có thể thực hiện

bằng cách mở r ộng môi tr ườ ng PKI trên toàn cầu.

+ Gridmap File

Sau khi đã có các chứng chỉ, một thực thể Grid cần phải biết ngườ i dùng nào

có chứng chỉ nào đượ c phép truy cậ p đến các tài nguyên của nó. Điều này đượ c

thực hiện bằng một file Grid map. File Grid map là một file trên tài nguyên đầu




- 86 -

cuối, thực hiện ánh xạ các DN vào các ngườ i dùng cục bộ trên tài nguyên. Sau khi

đượ c ánh xạ, một DN có thể sử dụng tài nguyên trên host như là một ngườ i dùng

cục bộ, tức DN có toàn quyền của ngườ i dùng cục bộ. Điều này cho phép phân cho

các ngườ i dùng Grid khác nhau các quyền khác nhau trên tài nguyên thông qua các

ngườ i dùng cục bộ đượ c ánh xạ. Để từ chối truy cậ p đối vớ i một DN, chỉ cần loại bỏ

DN đó ra khỏi Grid map file.

Trong GT, trên hệ thống Linux, Grid map file đượ c lưu trong file :

/etc/security/gridmap-file. Gridmap-file là một file text, mỗi dòng là một ánh xạ

giữa DN và user cục bộ, có dạng như sau:

“DN” <user cục bộ> Ví dụ :

“/C=VN/O=HCMUNS/OU=FIT/CN=NMDzung/USERID=Dzung” root

33..44..11..33.. CCơ ơ cchhếế hhooạạtt đđộộnngg

Chúng ta vừa tìm hiểu một số khái niệm cơ bản về bảo mật trong Grid, trong

phần này sẽ tìm hiểu các cơ chế hoạt động của các thành phần của GSI để có thể

cung cấ p các dịch vụ bảo mật.+ Quy trình chuẩn bị để có thể sử dụng Grid

Hình 3-6 giớ i thiệu quy trình khở i tạo cho phép một ngườ i dùng Grid (có thể

là ngườ i hay host) sử dụng GSI để tham gia vào Grid, gồm các bướ c sau:

1. Sao chép khóa công khai của CA về host.

2. Tạo khóa bí mật và một bản yêu cầu chứng nhận chứng chỉ.

3. Gửi bản yêu cầu chứng nhận đến CA qua email hay theo một cách an

toàn nào đó.

4. CA ký tên chứng nhận vào bản yêu cầu để tạo thành một chứng chỉ và

gửi lại user.




- 87 -

Hình 3-6 Quy trình khở i tạo để sử dụng GSI

Quy trình trên k ết thúc khi user nhận đượ c chứng chỉ của mình, lúc này trên

host của user sẽ có 3 thứ quan tr ọng:

1. Khóa công khai của CA

2. Khóa bí mật của Grid host

3. Chứng chỉ điện tử của Grid host

Để có thể thực hiện các việc chứng thực và giao tiế p cho Grid host một cách

an toàn, không đượ c để bất cứ ai truy cậ p đượ c khóa bí mật của mình. GSI cung cấ p

thêm một tầng bảo mật nữa để đảm bảo an toàn cho khóa bí mật, đó là sử dụng thêmmột passphrase (mật khẩu) bí mật nữa khi sử dụng khóa bí mật cùng vớ i chứng chỉ

điện tử. Điều này ngăn không cho một ai sau khi lấy đượ c chứng chỉ điện tử và

khóa bí mật có thể sử dụng chúng để truy cậ p đến các tài nguyên Grid.

+ Quy trình chứ ng thự c và phân quyền

Hình 3-7 mô tả quy trình chứng thực và phân quyền của GSI. Ở đây, mô tả

các bướ c để Grid host B chứng thực và phân quyền sử dụng cho Grid host A.

1. Grid host A gửi user certificate đến host B, yêu cầu muốn mở k ết nối

đến host B để sử dụng tài nguyên của B, ví dụ vậy.

2. Host B sẽ bắt đầu thực hiện chứng thực host A. Host B lấy khóa công

khai và subject (DN) của ngườ i dùng từ user certificate bằng cách sử dụng

khóa công khai của CA.

3. Host B tạo một số ngẫu nhiên (X) và gửi lại cho host A.

4. Khi host A nhận đượ c số X, sẽ mã hoá số X bằng khóa bí mật của

ngườ i dùng. Số X sau khi mã hoá (Y) sẽ đượ c gửi lại cho host B.




- 88 -

5. Host B sẽ giải mã Y bằng khóa công khai của user lấy đượ c trong bướ c

2, và so sánh k ết quả sau khi giải mã vớ i số X đã gửi đi tr ướ c đó. Nếu giống,

tức là chứng chỉ điện tử host B nhận đượ c chính là của ngườ i dùng trên host

A, bở i vì chỉ ngườ i dùng trên host A mớ i có thể mã hoá số X bằng khóa bí

mật của mình.

6. Chứng chỉ của ngườ i dùng trên host A đã đượ c host B chứng thực, sau

đó, host B sẽ ánh xạ subject (là một dạng của DN, là tên đượ c sử dụng bở i

LDAP để phân biệt các điểm vào trong directory service) lấy đượ c trong

bướ c 2 vào ngườ i dùng cục bộ thông qua gridmap-file.

Hình 3-7 Thủ tục chứ ng thự c và phân quyền vớ i GSI.

Lúc này, ngườ i dùng trên host A đã đượ c cho phép hoạt động như một ngườ i

dùng cục bộ trên host B.

Trong môi tr ườ ng Grid, một host có vai trò là client trong một số tr ườ ng hợ p,

có thể là server trong một số tr ườ ng hợ p khác, do đó host có thể phải chứng thực

một host khác và đượ c chứng thực bở i host kia tại cùng một thờ i điểm. Trong

tr ườ ng hợ p này có thể sử dụng chức năng mutual authentication của GSI. Chức

năng sẽ đượ c giớ i thiệu chi tiết hơ n ở phần sau.




- 89 -

+ Cơ chế uỷ quyền (delegation)

Cơ chế uỷ quyền trong GSI giải quyết yêu cầu về đăng nhậ p một lần (single

sign-on) của một hệ thống Grid. Đây là một sự mở r ộng của protocol SSL nhằm

giảm số lần phải gõ passphrase của ngườ i dùng khi sử dụng nhiều tài nguyên Grid

có yêu cầu chứng thực. Ngườ i dùng không cần phải gõ lại passphrase bằng cách tạo

ra một proxy và ủy quyền cho nó.

Một proxy bao gồm một chứng chỉ mớ i (có đính kèm khóa công khai mớ i

của proxy) và một khóa bí mật mớ i. Chứng chỉ mớ i chứa định danh của ngườ i chủ

proxy, đượ c sửa lại để cho biết đó là một proxy. Chứng chỉ mớ i đượ c ký bở i ngườ i

chủ sở hữu thay vì CA. Trong proxy certificate có chứa thêm thờ i gian sống của proxy, khi hết thờ i gian sống, proxy sẽ tr ở nên không hợ p lệ, thườ ng thì thờ i gian

sống của proxy r ất ngắn.

Các proxy lại có thể tạo ra và uỷ quyền cho các proxy khác tạo thành một

chuỗi các đại diện cho ngườ i dùng trên các tài nguyên (như trên hình 3-8), từ đó cho

phép ngườ i dùng có thể sử dụng nhiều tài nguyên khác nhau mà chỉ cần đăng nhậ p

một lần.

Hình 3-8 Cơ chế ủy quyền trong GSI. Cơ chế uỷ quyền đượ c mô tả trong hình 3-9. Cơ chế gồm 2 bướ c chính: khở i

tạo proxy trên host ở xa (host B) và chứng thực proxy trên một host khác (host C).




- 90 -

Hình 3-9 Thủ tục uỷ quyền của một proxy trong GSI.

Bướ c 1 : Khở i tạo proxy

Để khở i tạo một proxy:

1. Một k ết nối tin cậy phải đượ c tạo ra giữa host A và host B (thực hiệnquy trình chứng thực trên host B như ở trên).

2. Ngườ i dùng trên host A gửi yêu cầu host B tạo một proxy để đại diện

cho mình.

3. Host B tạo một bản yêu cầu cho proxy certificate của ngườ i dùng và

gửi yêu cầu này về host A.

4. Host A sử dụng khóa bí mật của ngườ i dùng để ký xác nhận vào bản

yêu cầu proxy certificate và gửi nó lại cho host B.

5. Host A gửi chứng chỉ của ngườ i dùng cho host B.

Bướ c 2 : Chứ ng thự c proxy

Lúc này proxy trên host B đã đượ c ngườ i dùng uỷ quyền, proxy trên host

B có thể liên lạc và đượ c chứng thực và phân quyền trên host C như thể là

user trên host A.

Tr ướ c khi có thể gửi yêu cầu thực hiện công việc trên host C, proxy cần

đượ c chứng thực trên host C. Quy trình thực hiện như sau :




- 91 -

6. Proxy của ngườ i dùng trên host B gửi user certificate và proxy

certificate đến host C.

7. Host C lấy khóa công khai của proxy thông qua thủ tục “path

validation”:

7.1. Host C sử dụng khóa công khai của CA để lấy subject và khóa

công khai của ngườ i dùng trong user certificate.

7.2. Host C sử dụng khóa công khai của ngườ i dùng để lấy subject và

khóa công khai của proxy trong proxy certificate.

7.3. Giả sử subject của ngườ i dùng là :“/O=Grid/O=GridTest/OU=test.domain.com/CN=GreenStar"

Subject của proxy certificate cũng giống như subject của ngườ i tạo

ra nó (ở đây là ngườ i dùng trên host A) và có dạng như sau:

“/O=Grid/O=GridTest/OU=test.domain.com/CN=GreenStar/CN=proxy"

Do đó, để kiểm tra tính hợ p lệ của proxy, host C chỉ cần kiểm tra

phần chuỗi còn lại trong proxy subject sau khi loại bỏ “/CN=proxy”

xem có giống vớ i subject của user không, nếu đúng là hợ p lệ. Nếu hợ plệ, proxy đã đượ c chứng thực bở i host C và có thể hoạt động như một

đại diện vớ i tất cả các quyền của ngườ i dùng trên host A.

8. Proxy mã hoá thông điệ p yêu cầu thực hiện công việc bằng khóa bí mật

của mình, và gửi đến host C.

9. Host C sử dụng khóa công khai của proxy để giải mã thông điệ p và lấy

yêu cầu của proxy.

10. Host C thực hiện ánh xạ proxy subject vào ngườ i dùng cục bộ thông

qua Grid-mapfile, và thực thi công việc dướ i quyền của ngườ i dùng cục bộ.

Thủ tục trên cho phép uỷ quyền từ xa, trong đó một ngườ i dùng tạo proxy

trên host ở xa. Ngoài ra, Globus Toolkit còn cho phép uỷ quyền cục bộ, trong đó

ngườ i dùng tạo proxy ngay trên host của mình, thông qua lệnh Grid-proxy-init.

Lư u ý:

Khi tạo một proxy trên host ở xa, khóa bí mật của proxy sẽ nằm trên host đó,nên ngườ i quản tr ị của host đó có thể lấy khóa bí mật của proxy và thực hiện các






- 93 -

GT3 cung cấ p các công cụ cho phép ngườ i dùng có thể cấu hình GSI, đăng

nhậ p và sử dụng tài nguyên Grid.

Tên công cụ Các tham số Diễn giải & Ví dụ Grid-cert-request Sử dụng để tạo một cặ p khóa công khai/bí

mật và một bản yêu cầu cấ p chứng chỉ trong

thư mục ~/.globus/

Grid-cert-info -all -startdate

-subject -

enddate

-issuer -help

Lấy thông tin về chứng chỉ. Ví dụ :

$ Grid-cert-info –subject

“/O=Grid/O=GridTest/OU=test.domain.com/CN=GreenStar"

Grid-proxy-init -hours

-bits

-help

Thực hiện khở i tạo proxy và đăng nhậ p vào

Grid.

Grid-proxy-destroy

Logout khỏi Grid, thực hiện hủy proxy cục bộ. Lưu ý, các proxy ở xa không bị huỷ.

Grid-proxy-info -subject -issuer

-type -timeleft

-strength -help

Lấy thông tin về proxy

Bảng 3-4 Bảng các công cụ cấu hình GSI.




- 94 -

+ Một số hàm API quan trọng

GT3 có r ất nhiều hàm API phục vụ lậ p trình vớ i GSI, Bảng … giớ i thiệu một

số hàm API quan tr ọng. Các hàm API đượ c viết theo chuẩn GSS-API. Mọi chi tiết

xin tham khảo tài liệu về các hàm API trên website : www.globus.org

Tên hàm Diễn giải

gss_acquire_cred() Nạ p các chứng chỉ (credential) bảo mật vào chươ ngtrình, bao gồm user proxy certificate và khóa bímật.

gss_release_cred() Giải phóng các credential.gss_inquire_cred() Lấy các thông tin về các credential.gss_wrap() Tính checksum và mã hoá trên vùng đệm nhậ p của

ngườ i dùng. Phát sinh thông điệ p đã mã hoá để gửiđi.

gss_unwrap() Lấy thông điệ p đã mã hoá bằng gss_wrap(), kiểmtra checksum và giải mã nó, đưa vào vùng đệmxuất của ngườ i dùng.

gss_{import,export}_name() Đưa vào / xuất ra một subject name.gss_{init,accept}_delegation() Thực hiện ủy quyền và chấ p nhận ủy quyền, cho

phép thêm các ràng buộc vào việc uỷ quyền.…

Bảng 3-5 Bảng các hàm API về GSI của GT3

33..44..22.. R R eessoouurrccee MMaannaaggeemmeenntt


1. Kiến trúc quản lý tài nguyên của Globus

Như đã biết, vấn đề quản lý tài nguyên là một thách thức lớ n cho công nghệ

Grid Computing. Nhóm phát triển Globus Toolkit đã đưa ra một giải pháp khá hoànchỉnh để giải quyết vấn đề quản lý và chia sẻ tài nguyên trong Grid. Giải pháp này

đượ c thể hiện trong hình 3-10.








- 97 -

thái và tiến độ của các công việc đang thực hiện. Nó cũng thực hiện cậ p nhật các

thông tin về khả năng và tính sẵn sàng của các tài nguyên đang quản lý cho module

Information Service.

GT3.2 chứa 2 bản cài đặt GRAM, một bản xây dựng trên các protocol riêng

của Globus (trong GT2) đượ c gọi là Pre-WS GRAM, và một bản mở r ộng của Pre-

WS GRAM, xây dựng theo chuẩn OGSI, đượ c gọi là WS-GRAM.

GRAM cung cấ p các hàm API, các dịch vụ để yêu cầu hoặc huỷ bỏ việc thực

thi các công việc cũng như kiểm tra tr ạng thái của các công việc đang thực thi. Các

yêu cầu đượ c đặc tả bở i ngôn ngữ đặc tả tài nguyên (Resource Specification

Language (RSL)). Resource Specification Language (RSL) là một ngôn ngữ có cấutrúc đượ c sử dụng để đặc tả các yêu cầu tài nguyên và các thông số cần thiết để thực

thi một công việc. Trong WS-GRAM, RSL đượ c viết lại dướ i dạng XML.

GRAM giảm thiểu các cơ chế cần thiết để sử dụng tài nguyên ở xa. Các hệ

thống cục bộ ở xa có thể sử dụng nhiều cơ chế quản lý tài nguyên khác nhau (như

sử dụng hệ thống lậ p lịch, hệ thống hàng đợ i, hệ thống giữ chỗ, các giao diện điều

khiển khác nhau), nhưng ngườ i dùng và các nhà phát triển ứng dụng chỉ cần sử

dụng một cơ chế, một giao diện duy nhất (của GRAM) để yêu cầu và sử dụng các

tài nguyên này.

Hiện nay GRAM không có khả năng lậ p lịch và tìm kiếm để tìm các tài

nguyên và để tự động gửi các công việc đến các hệ thống thích hợ p, không có các

chức năng k ế toán và tính toán chi phí. Thay vào đó, nó cung cấ p các công cụ và

giao diện để xây dựng các chức năng trên. Các chức năng này đượ c bổ sung bằng

các dự án khác đượ c xây dựng trên nền tảng GRAM như Condor-G, Gridbus,...

Hiện nay, GRAM đã đượ c thiết k ế để tươ ng thích và sử dụng đượ c vớ i 6 bộ

lậ p lịch cục bộ : Condor, Load Sharing Facility (LSF), Network Queuing

Environment (NQE), Fork, EASY, và LoadLeveler.

+ Các trạng thái của một công việc trong GRAM:

Khi một ngườ i dùng hoặc một resource broker gửi một yêu cầu thực thi công

việc, nó sẽ đi qua các tr ạng thái khác nhau theo sơ đồ tr ạng thái sau:




- 98 -

Hình 3-11 Các trạng thái của một công việc.

1. UnSubmittedCông việc chưa đượ c gửi cho bộ lậ p lịch cục bộ. Các lờ i gọi callback

về tr ạng thái công việc sẽ không bao giờ đượ c thực hiện.

2. StageIn

Tr ạng thái khở i tạo, chuẩn bị thực thi, đọc, nhậ p các file dữ liệu cho

job. Một số công việc có thể không có tr ạng thái này.

3. Pending

Công việc đã đượ c gửi đến bộ lậ p lịch cục bộ, nhưng chưa cấ p phát tài

nguyên cho nó.

4. Active

Công việc đã nhận đủ các tài nguyên cần thiết và đang đượ c thực thi.

5. Suspended

Công việc đã bị ngừng tạm thờ i bở i bộ lậ p lịch. Chỉ có một số bộ lậ p

lịch cho phép công việc vào tr ạng thái Suspended.6. StageOut

Trình quản lý công việc gửi các file dữ liệu k ết quả đến các kho lưu

tr ữ ở xa. Một số công việc có thể không có tr ạng thái này.

7. Done

Công việc đã thực hiện xong và thành công.

8. Failed




- 99 -

Công việc k ết thúc tr ướ c khi hoàn thành, do một lỗi hay do yêu cầu

hủy của ngườ i dùng hoặc hệ thống.

33..44..22..22.. PPrree--WWSS GGR R AAMM

1. Các đặc điểm chính

- Cung cấ p các dịch vụ không theo chuẩn OGSI phục vụ thực thi các công

việc trên các site ở xa.

- Sử dụng ngôn ngữ RSL để trao đổi các yêu cầu về thực thi công việc.

- Các công việc ở xa thực thi dướ i quyền của user cục bộ.

- Việc uỷ quyền, chứng thực giữa client và dịch vụ phải thông qua thành phần thứ ba (gatekeeper).

2. Mô hình hoạt động tổng quan của pre-WS GRAM

Kiến trúc các thành phần và cơ chế hoạt động của Pre-WS GRAM như sau:

Hình 3-12 Các thành phần và cơ chế hoạt động của pre-WS GRAM




- 100 -

Như trên hình vẽ, các thành phần chủ yếu của pre-WS GRAM là : GRAM

client library, gatekeeper, RSL parsing library, Job manager và GRAM Reporter.

GSI đượ c sử dụng để chứng thực và phân quyền cho ngườ i dùng.

* GRAM client library đượ c sử dụng bở i các ứng dụng hay một co-

allocator đại diện cho ứng dụng. Nó giao tiế p vớ i GRAM gatekeeper trên site

ở xa để thực hiện mutual authentication và gửi một yêu cầu gồm có bản đặc

tả tài nguyên, các yêu cầu về callback, và một số thành phần khác.

* Gatekeeper là một thành phần khá đơ n giản, chịu trách nhiệm đáp ứng

lại yêu cầu từ GRAM client bằng cách thực hiện 3 việc sau: thực hiện mutual

authentication vớ i user và tài nguyên, ánh xạ user name cục bộ cho user ở xa,khở i động một Job manager. Job manager này sẽ chạy trên hệ thống như là

một user cục bộ, và thực sự xử lý các yêu cầu.

* Một Job manager chịu trách nhiệm tạo lậ p các tiến trình (process)

đượ c yêu cầu bở i ngườ i dùng. Thông thườ ng nhiệm vụ này đượ c thực hiện

bằng cách gửi các yêu cầu cấ p phát tài nguyên đến hệ thống quản lý tài

nguyên cục bộ của site. Khi các tiến trình đượ c tạo ra, Job manager còn chịu

trách nhiệm theo dõi tr ạng thái của chúng, thông báo callback các thay đổi

tr ạng thái, triển khai các thao tác điều khiển tiến trình như tạm dừng, kích

hoạt, k ết thúc tiến trình. Hoạt động của Job manager k ết thúc khi công việc

nó quản lý k ết thúc.

Một Job manager có 2 thành phần :

- Common Component : chuyển thông điệ p nhận đượ c từ gatekeeper

và client thành các lờ i gọi đến các API của Machine-Specific Component

(MSC). Nó cũng biên dịch các yêu cầu thông báo thông tin callback của

MSC thành các thông điệ p gửi về client.

- Machine-Specific Component : chứa các mã cài đặt cụ thể của các

hàm API trên các môi tr ườ ng cục bộ khác nhau. Đây là phần thay đổi duy

nhất trong GRAM để tươ ng thích vớ i các môi tr ườ ng cục bộ. Mã cài đặt

bao gồm các lờ i gọi hàm đến hệ thống cục bộ, các thông báo đến trình

theo dõi tài nguyên (MDS).




- 101 -

* GRAM reporter chịu trách nhiệm gửi các thông tin về cấu trúc (như

khả năng giữ chỗ, số lượ ng hàng đợ i,… ) và tr ạng thái (như số lượ ng các

node, số node đang đang sẵn sàng, các công việc đang thực hiện, ….) của bộ

lậ p lịch cục bộ cho hệ thống Information Service (ở đây là MDS).

Pre-WS GRAM có thể sử dụng module Global Access to Secondary Storage

(GASS) để truyền các file dữ liệu và k ết quả về client. Cơ chế này đượ c sử dụng

trong lệnh globusrun, gatekeeper và job manager.

Ngườ i dùng có thể sử dụng cơ chế co-allocator Dynamically-Updated

Request Online Coallocator (DUROC) để yêu cầu thực hiện công việc trên nhiều job manager ở cùng một host hay ở nhiều host khác nhau (Xem hình 3-13).

Hình 3-13 Cơ chế hoạt động có DUROC trong pre-WS GRAM.

Các script RSL chứa cú pháp DUROC sẽ đượ c phân tích (parse) ở GRAM

client và phân phối đến nhiều job manager.

3. Các hàm API

GT3 cung cấ p các hàm API hỗ tr ợ lậ p trình vớ i RSL, GRAM, DUROC,

LDAP protocol và chúng đượ c chia thành các nhóm hàm:globus_rsl : Module gồm các thực hiện thao tác vớ i các đặc tả RSL, có

thể sử dụng xây dựng các broker mớ i.

globus_gram_client : Dùng để phát triển các ứng dụng client, yêu cầu

thực hiện, quản lý công việc,…

globus_gram_myjob : Dùng để quản lý các tiến trình riêng lẻ trong các

công việc.

globus_duroc_control/runtime : Các hàm giao tiế p vớ i DUROC






- 103 -

- Sử dụng ngôn ngữ RSL-2 (các đặc tả RSL theo định dạng XML) để trao

đổi các yêu cầu về thực thi công việc.

- Các công việc ở xa thực thi dướ i quyền của user cục bộ.

- Việc uỷ quyền, chứng thực giữa client và service không cần thông qua

thành phần thứ ba.

2. Mô hình thành phần và hoạt động

Vớ i GT3, ngườ i dùng đã có thể gọi thực thi các công việc thông qua các Grid

service. Kiến trúc GRAM đượ c thiết k ế lại theo OGSA thông qua 5 service và một

số module:

1. Master Managed Job Factory Service (MMJFS)Chịu trách nhiệm phát hành các service GRAM ảo cho thế giớ i bên

ngoài. MMJFS sử dụng Service Data Aggregator để thu thậ p và phát sinh các

Service Data Element cục bộ, chứa thông tin về tr ạng thái các scheduler cục bộ

(như tổng các node, các node hiện đang sẵn sàng) và các thông tin về host (host,

kiểu CPU, host OS).

MMJFS thực hiện cấu hình Redirector để giải quyết các lờ i gọi

createService đến nó qua Startup UHE. Redirector đượ c hướ ng dẫn để chuyển

các lờ i gọi createService đến hosting environment của ngườ i dùng.

2. Managed Job Factory Service (MJFS)

Chịu trách nhiệm tạo lậ p một instance MJS mớ i. Nó chỉ phát hành một

Service Data Element đơ n nhất, là một mảng các GSH của tất cả các instance

MJS đang hoạt động.

3. Managed Job Service (MJS)Là một OGSA service thực hiện gửi công việc đến các scheduler cục bộ,

theo dõi tr ạng thái của công việc, và gửi các thông báo. MJS sẽ khở i động 2

service File Streaming Factory Services làm stdout và stderr cho công việc.

Những GSH của 2 service này đượ c lưu tr ữ trong MFS Service Data Element.

4. File Stream Factory Service

Chịu trách nhiệm tạo các instance mớ i của File Stream Service.




- 104 -

5. File Stream Service

Là một OGSA service sử dụng một địa chỉ URL đưa vào để chuyển k ết

quả từ các file cục bộ tạo ra bở i factory đại diện cho các luồng stdout, stderr đến

host có URL đó.

6. Virtual Host Environment Redirector

Nhận tất cả các thông điệ p SOAP và chuyển chúng đến User Host

Environment (UHE).

7. Starter UHE

Đượ c sử dụng bở i Redirector để giải quyết các lờ i gọi đến một UHE. File

gridmap đượ c sử dụng để lấy tên ngườ i dùng cục bộ tươ ng ứng vớ i subject DNcủa ngườ i dùng Grid và để đảm bảo chỉ có một UHE trên một ngườ i dùng chạy

trên một máy.

Việc ánh xạ tên ngườ i dùng đến số hiệu cổng (port number) của UHE của

ngườ i dùng đó đượ c quản lý trong một file cấu hình.

Khi có một yêu cầu về URL đến và có một điểm nhậ p(entry) trong file

cấu hình, URL đích sẽ đượ c xây dựng và tr ả về cho Redirector. Nếu UHE ở

cổng đó chưa đượ c khở i động, module setuid/launch đượ c sử dụng để khở i động

UHE cho user. Nếu một điểm nhậ p chưa tồn tại trong file cấu hình, một cổng

chưa sử dụng đượ c chọn, module setuid/launch đượ c sử dụng để khở i động UHE

trên cổng đượ c chọn và tr ả về URL cho Redirector, sau khi chắc chắn r ằng UHE

đã đượ c chạy. File cấu hình cũng đượ c cậ p nhật thêm điểm nhậ p này.

8. Launch UHE

Dùng để khở i động một hosting environment mớ i dướ i user account.




- 105 -

Dướ i đây là mô hình phối hợ p hoạt động của các thành phần và service để

giải quyết yêu cầu thực thi công việc của ngườ i dùng Grid.

Hình 3-14 Các thành phần và cơ chế hoạt động của WS-GRAM. 1. Tr ướ c hết MMJFS đượ c cấu hình để sử dụng Redirector để chuyển

hướ ng các lờ i gọi đến nó và sử dụng Starter UHE để khở i động một UHE nếu

chưa có UHE cho ngườ i dùng. Sau này, khi có một lờ i gọi createService

MMJFS sẽ sử dụng Redirector để gọi Starter UHE và khở i động một UHE.

2. MMJFS phát hành GSH của nó đến một Registry ở xa. (Có thể không

có bướ c này)

3. Một ngườ i dùng (client) khở i tạo một proxy và gửi một yêu cầu

createService đến server thông qua proxy của mình. Yêu cầu này sẽ đượ c tiế p

nhận bở i Redirector.




- 106 -

4. Redirector gọi Starter UHE để thực hiện phân quyền cho yêu cầu của

ngườ i dủng thông qua Grid-mapfile để xác định tên ngườ i dùng cục bộ và cổng

đượ c sử dụng, từ đó xây dựng nên một URL đích.

5. Redirector cố gắng chuyển tiế p lờ i gọi của ngườ i dùng đến URL đích

vừa đượ c xây dựng. Nếu nó không thể chuyển tiế p đượ c lờ i gọi bở i vì UHE

chưa chạy, module Launch UHE sẽ đượ c gọi.

6. Launch UHE tạo một tiến trình mớ i UHE dướ i tên ngườ i dùng cục bộ

đã đượ c chứng thực.

7. Starter UHE sẽ chờ cho đến khi UHE đượ c khở i tạo hoàn toàn thông

qua cơ chế “ping loop” và tr ả về URL đích cho Redirector.8. Redirector chuyển lờ i gọi createService đến MJFS và ở đây sẽ thực

hiện quá trình chứng thực hai chiều và phân quyền.

9. MJFS tạo một MJS mớ i

10. MJS gửi công việc đượ c yêu cầu đến hệ thống lậ p lịch cục bộ.

11. Các lờ i gọi tiế p theo đến MJS từ client sẽ đượ c chuyển đến MJS

thông qua Redirector.

12. RIPS cung cấ p các dữ liệu liên quan đến các thực thể MJS và

MMJFS. Nó thu thậ p thông tin từ hệ thống lậ p lịch cục bộ, hệ thống file, thông

tin về host,…

13. Các lờ i gọi FindServiceData sẽ đượ c giải quyết bằng cách tr ả về một

SDE (phát sinh bở i Service Data Aggregate) hoặc đượ c chuyển đến MJFS liên

quan.

14. Để gửi các luồng stdout/stderr về client, MJS sẽ tạo ra 2 FSFS, một

cho stdout, một cho stderr.

15. Sau đó, MJS tạo các thực thể FSS như xác định trong yêu cầu về công

việc.

16. Một trình quản lý GRIM chạy trong UHE để tạo một host certificate.

Chứng chỉ này đượ c sử dụng trong quá trình chứng thực hai chiều giữa MJS và

client.




- 107 -

Các đặc tả yêu cầu tài nguyên và công việc trong GT3 đượ c viết bằng ngôn

ngữ RSL mớ i. Ngôn ngữ RSL mớ i cũng vẫn có các chức năng tươ ng tự như trong

GT2 nhưng đượ c định ngh ĩ a lại dướ i dạng XML.

GT3 vẫn cung cấ p các hàm API dướ i ngôn ngữ C và Java để xây dựng các

client sử dụng các dịch vụ GRAM cùng vớ i các API mớ i phục vụ việc chuyển đổi

định dạng RSL của GT2 sang định dạng của GT3.

33..44..33.. IInnf f oorrmmaattiioonn SSeerrvviiccee


Grid Information Service (GIS) chịu trách nhiệm cung cấ p các thông tin động và

t ĩ nh về tính sẵn sàng và khả năng hiện hành của các tài nguyên cũng như các thông

tin khác về toàn bộ hệ thống Grid. Các thông tin này sẽ đượ c dùng để xác định vị trí

các tài nguyên theo những tiêu chí cụ thể, để xác định các trình quản lý liên k ết vớ i

tài nguyên, để xác định các tính chất của tài nguyên, xác định chiến lượ c sử dụng

hiệu quả tài nguyên, và phục vụ nhiều mục đích khác trong quá trình chuyển các

đặc tả về tài nguyên cấ p cao của ứng dụng thành các yêu cầu cụ thể đến từng trìnhquản lý tài nguyên.

Mô hình quản lý thông tin Grid sau đượ c đề xuất để giải quyết các thách thức và

yêu cầu của một hệ thống GIS.

Hình 3-15 Mô hình quản lý thông tin trong Grid của Globus Toolkit.




- 108 -

Mô hình có các thành phần cơ bản:

+ Một tậ p r ất lớ n các nhà cung cấ p thông tin (Resource Description Service)

phân tán cho phép truy cậ p thông tin chi tiết, mang tính động về các tài nguyên cụ

thể, thông qua các hoạt động cục bộ hoặc là gateway cho các nguồn thông tin khác

(như các truy vấn SNMP,…).

+ Các service cấ p cao hơ n có nhiệm vụ thu thậ p, quản lý, chỉ mục và/hoặc

hồi đáp các thông tin cung cấ p bở i một hay nhiều nhà cung cấ p thông tin. Các

service này đượ c gọi chung là Aggregate Directory Service, hỗ tr ợ việc tìm kiếm

tài nguyên, và theo dõi cho các VO bằng cách triển khai các góc nhìn (view) cụ thể

và tổng quát và các thao tác tìm kiếm tậ p các tài nguyên. Các service cấ p cao hơ ncó thể sử dụng các thông tin này cùng vớ i/hoặc các thông tin lấy tr ực tiế p từ các nhà

cung cấ p thông tin để phục vụ các công tác brokering, theo dõi, loại bỏ lỗi,…

+ Các protocol : Việc tươ ng tác giữa các service cấ p cao hoặc ngườ i dùng

vớ i các nhà cung cấ p thông tin đượ c định ngh ĩ a trong 2 protocol cơ bản : protocol

thực hiện đăng ký tài nguyên (GRid Registration Protocol (GRRP)) để đăng ký các

tài nguyên tham gia hệ thống, và protocol yêu cầu thông tin (GRid Information

Protocol (GRIP)) dùng để lấy các thông tin về tài nguyên thông qua việc truy vấn

hoặc yêu cầu thông báo định k ỳ. Một cách đơ n giản, một nhà cung cấ p thông tin sẽ

sử dụng GRRP để thông báo cho các service cấ p cao về sự tồn tại của mình. Một

service cấ p cao sẽ sử dụng GRIP để lấy các thông tin về các thực thể từ các nhà

cung cấ p thông tin, r ồi sau đó tổng hợ p lại để phục vụ mục đích xác định.

Hệ thống thông tin GIS đượ c tích hợ p vớ i hệ thống bảo mật GSI để quản lý truy

cậ p và bảo vệ thông tin.

Trong GT2, dịch vụ information service đượ c triển khai trong thành phần

Metacomputing Directory Service (MDS).

33..44..33..22.. PPrree--WWSS IInnf f oorrmmaattiioonn SSeerrvviiccee ((MMDDSS22))

MDS có các thành phần tươ ng ứng vớ i mô hình quản lý thông tin đượ c giớ i

thiệu ở trên:

+ Resource Description Service: Information Provider và Grid ResourceInformation Service (GRIS)




- 109 -

+ Aggregate Directory Service: Grid Index Information Service (GIIS)

+ MDS Client

+ Mô hình tổ chứ c, quản lý, truy vấn thông tin trong hệ thống MDS

Vì các nhà cung cấ p thông tin có thể cung cấ p thông tin của một hay nhiều

thực thể, nên GRIP phải hỗ việc tìm kiếm và truy vấn. Ngườ i dùng có thể liên lạc

vớ i nhà cung cấ p thông tin để tìm ra một tậ p các thực thể thỏa điều kiện, r ồi sau đó

thực hiện truy vấn tr ực tiế p các thuộc tính của từng thực thể tìm thấy.

GRIP đượ c k ế thừa lại từ protocol chuẩn Lightweight Directory Access

Protocol (LDAP) về mô hình tổ chức dữ liệu, ngôn ngữ truy vấn, và các protocol

truyền thông.Mô hình tổ chức dữ liệu ví dụ như hình 3-16 :

Hình 3-16 Ví dụ tổ chứ c dữ liệu của MDS2.

Mô hình thông tin của GRIP biểu diễn thông tin về tài nguyên bằng một tậ p

các đối tượ ng đại diện có tên đượ c tổ chức thành một hệ thống không gian tên phân

cấ p (hierarchical namespace) trong mỗi nhà cung cấ p thông tin. Mỗi đối tượ ng

thuộc một hoặc nhiều kiểu để xác định kiểu tài nguyên. Mỗi đối tượ ng chứa các cặ p

thuộc tính – giá tr ị tươ ng ứng vớ i kiểu đối tượ ng để biểu diễn tr ạng thái hiện tại của

tài nguyên. Ở đây sử dụng mô hình đặt tên phân cấ p tươ ng tự hệ thống tên DNS,

các tên đượ c quản lý trong phạm vi của từng nhà cung cấ p thông tin hay aggregate

directory cụ thể, điều này giúp dễ dàng hơ n trong quản tr ị, tìm kiếm thông tin. Các

tên phạm vi toàn cục đượ c k ết hợ p từ tên nhà cung cấ p thông tin vớ i tên tài nguyên

trong nội bộ nhà cung cấ p đó.






- 111 -

Hình 3-18 Các thành phần và cơ chế hoạt động của MDS2

1. Resource information

Các thông tin động và t ĩ nh về tài nguyên đượ c chứa trong các đối tượ ng

quản lý bở i MDS

2. Grid Resource Information Service (GRIS) GRIS là nơ i chứa các thông tin lấy đượ c từ các Information Provider. Các

thông tin quản lý bở i GRIS đượ c cậ p nhật khi có yêu cầu truy xuất, và đượ c lưu

lại trong một khoảng thờ i gian time-to-live (TTL). Nếu hết TTL mà không có

truy vấn nào, thông tin sẽ bị xoá. Nếu sau đó, có yêu cầu truy vấn đượ c gửi tớ i,

GRIS sẽ gọi Information Provider thích hợ p để lấy các thông tin mớ i nhất.

3. Grid Index Information Service (GIIS)

GIIS là nơ i chứa các chỉ mục đến các thông tin tài nguyên đăng ký bở i

GRIS và các GIIS khác. Nó đượ c xem là một server cung cấ p thông tin toàn

Grid. Các GIIS cũng đượ c tổ chức như hệ thống DNS, và mỗi GIIS đều có tên

riêng. Các GIIS cấ p thấ p sẽ đăng ký thông tin của mình cho GIIS cấ p cao hơ n.

Các MDS Client có thể xác định tên của một node GIIS để thực hiện truy vấn

thông tin về bất cứ tài nguyên nào trong Grid.

4. Information provider




- 112 -

Thực hiện chuyển đổi các thông tin về thuộc tính và tr ạng thái của các tài

nguyên cục bộ sang định dạng xác định bở i các lượ c đồ dữ liệu (như giớ i thiệu ở

trên) và các file cấu hình. Để thêm tài nguyên mớ i vào hệ quản lý MDS, chúng

ta cần tạo hoặc xác định một information provider để chuyển đổi các thuộc tính

và tr ạng thái cho GRIS.

5. MDS client

Dựa trên lệnh LDAP client, ldapsearch, để tìm kiếm thông tin tài nguyên

trong Grid.

Ghi chú: Thông tin chi tiết và lậ p trình vớ i MDS, xin tham khảo tài liệu [22],

[35] và website : www.globus.org.

33..44..33..33.. WWSS IInnf f oorrmmaattiioonn SSeerrvviiccee ((IInnddeexx SSeerrvviiccee))

Hệ thống quản lý thông tin tài nguyên Grid trong GT3 đã có nhiều đổi khác so

vớ i GT2. Index Service cũng có các chức năng tươ ng tự như MDS, nhưng nó cung

cấ p thông tin về các Grid Service dướ i các định dạng XML. Không giống như GT2,

thành phần GRIS bị loại bỏ vì mỗi Grid Service đều có một tậ p các thông tin liênquan của riêng nó. Các thông tin này đã đượ c lưu tr ữ theo một cách thức đã đượ c

chuẩn hoá, đã có các cách thức dễ dàng để truy vấn và hiểu các các dữ liệu của

service thông qua các interface chuẩn của một Grid service. Các service đượ c yêu

cầu phải thông báo các thông tin cơ bản của mình, cho phép ngườ i dùng lấy thông

tin từ bất cứ Grid service nào.

Index Service đóng vai trò của một GIIS trong mô hình quản lý thông tin Grid,

là một trong những GT3 Base Services. Nó thực hiện thu thậ p, tổng hợ p và truy

vấn các Service Data, theo dõi quá trình điền dữ liệu; tạo Service Data theo yêu cầu.

Nó có thể đượ c sử dụng cho để xây dựng các Service Data chỉ mục mang các thông

tin tr ạng thái từ nhiều service instance phục vụ việc khám phá, lựa chọn và tối ưu

hoá việc sử dụng tài nguyên.

Index Service hiện có các chức năng sau :

+ Tạo và quản lý các Service Data động thông qua các trình Service Data

Provider.




- 113 -

+ Tổng hợ p Service Data từ nhiều Grid service instance.

+ Đăng ký các Grid service instance sử dụng port type Service Group.

Mô hình quản lý thông tin của Index Service đượ c k ế thừa lại từ mô hình của

Web service. Các protocol truyền thông của Web service (SOAP) đượ c sử dụng

thay thế cho các protocol phục vụ đăng ký, truy vấn (GRRP, GRIP).

33..44..44.. DDaattaa MMaannaaggeemmeenntt

Có 2 thành phần chính phục vụ quản tr ị dữ liệu trong GT:

+ Thành phần phục vụ truyền và truy cập dữ liệu.

+ Thành phần nhân bản và quản trị dữ liệu.Để thực hiện nhiệm vụ truy cậ p, truyền dữ liệu cấ p cơ sở , GT đưa ra module

Globus Access to Secondary Storage (GASS), cho phép ứng dụng truy cậ p đến dữ

liệu ở xa bằng các địa chỉ URL. GASS là một module truyền dữ liệu trên nhiều

protocol khác nhau, đượ c tích hợ p trong GRAM. Mục tiêu của GASS là cung cấ p

cách thức đơ n giản cho phép ứng dụng nạ p và truy xuất dữ liệu một cách an toàn

đến các file server thông qua các hàm API độc lậ p vớ i các protocol truyền dữ liệu

bên dướ i. Các chức năng của GASS đượ c sử dụng thông qua các câu đặc tả RSL.

Để phục vụ truyền và truy cậ p đến các dữ liệu bên thứ ba (third party), GT đưa

ra protocol GridFTP, protocol này dựa theo protocol FTP truyền thống đưa ra bở i tổ

chức IETF, và mở r ộng thêm các chức năng phân mảnh file, truyền file song song,

điều khiển bộ đệm TCP, theo dõi tiến độ, phục hồi lỗi khi truyền, cho phép truyền

các file dữ liệu giữa các máy nhanh hơ n, hiệu quả hơ n, bảo mật và mạnh mẽ hơ n,

đồng thờ i cung cấ p khả năng quản lý quá trình truyền file.

GridFTP đi kèm trong bộ GT bao gồm một trình server, một client (lệnh globus-

url-copy trong GT2 hay dịch vụ Reliable File Transfer Service (RFT) trong GT3) và

một bộ các thư viện phát triển ứng dụng hỗ tr ợ ngôn ngữ C.

GT hiện không phát triển các dịch vụ quản tr ị dữ liệu cao cấ p hơ n. Các dự án

Grid có thể sử dụng protocol GridFTP làm nền tảng để phát triển các dịch vụ quản

tr ị dữ liệu cho riêng mình.




- 114 -

Ghi chú: Chi tiết về các thành phần quản tr ị dữ liệu cũng các hàm API và cách

thức lậ p trình sử dụng chúng xin tham khảo tài liệu : [22], [34] và website :

www.globus.org.

33..44..55.. TThhàànnhh pphhầầnn mmớ ớ ii ttrroonngg GGTT33

33..44..55..11.. GGTT33 CCoorree

Các thành phần của GT Core đượ c tóm tắt như sau:

OGSI SpecImplementation

Triển khai cài đặt tất cả các interface do OGSI xác định.

SecurityInfrastructure

Thành phần này hỗ tr ợ bảo mật cấ p thông điệ p, chứng thựcvà phân quyền dựa trên gridmap file. Bảo mật cấ p thôngđiệ p bao gồm bảo mật trên toàn bộ session (GSI-SecureConversation) cũng như trên từng thông điệ p (GSI-SecureMessage).

Là các Grid service tươ ng thích OGSI chung nhất để sử dụng bở i tất cả các Grid service khác. Hiện tại có 3 loại

service:

Ping service Sử dụng để "ping" một hostingenvironment.

LoggingManagementService

Cho phép sửa đổi các log filter vànhóm các thông tin log để dễ theo dõivà quản lý.

System levelservices

Management

Service

Cung cấ p một interface để theo dõi

tr ạng thái và tải hiện tại của cácservice, cho phép huỷ, kích hoạt cácservice instance.

Bảng 3-7 Các thành phần của GT Core



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

- 115 -

CChhưươơnngg 44.. PPhháátt ttr r iiểểnn ứứnngg ddụụnngg vvớớii bbộộ

GGlloobbuuss TToooollkkiitt 33..22 Quy trình phát triển các ứng dụng Grid cũng tuân theo các quy trình áp dụng

trong các dự án phần mềm thông thườ ng khác, cũng tr ải qua các pha như thu thậ p

yêu cầu, phân tích thiết k ế, viết mã, kiểm thử, và triển khai. Chươ ng này chỉ giớ i

thiệu một số vấn đề đặc tr ưng của việc phát triển một ứng dụng Grid.

44..11.. KKhhởởii đđầầuu ddựự áánn

44..11..11.. ĐĐịịnnhh hhư ư ớ ớ nngg pphháátt ttrriiểểnn hhệệ tthhốốnngg

Về mặt k ỹ thuật, tr ướ c khi bắt đầu dự án, cần quan tâm lựa chọn định hướ ng

phát triển hệ thống.Thông thườ ng vớ i các ứng dụng Grid có 2 cách để khở i đầu một

dự án:

Phát triển một hệ thống mớ i hoàn toàn dựa trên Grid.

Sử dụng lại các hệ thống có sẵn và sửa chữa để có thể thực thi đượ c trênGrid.

Hầu hết các nhà phát triển đều thích xây dựng ứng dụng lại từ đầu để có thể

kiểm soát hoàn toàn quá trình thiết k ế và phát triển. Tuy nhiên, hiện nay có r ất nhiều

hệ thống đã tồn tại r ất lâu trong các tổ chức, việc thay mớ i hoàn toàn các hệ thống

này là không khả thi, do đó vấn đề sử dụng lại hệ thống đượ c đặt ra. Dướ i đây phân

tích một số khía cạnh ảnh hưở ng đến quyết định lựa chọn việc khở i đầu dự án xây

dựng ứng dụng Grid.

+ Nếu phát triển hệ thống mớ i, nhà phát triển đượ c tự do lựa chọn các môi

tr ườ ng, ngôn ngữ, công cụ lậ p trình, các bộ công cụ hỗ tr ợ tốt nhất, và kiểm soát

đượ c việc thiết k ế hệ thống, tuy nhiên vẫn có các ràng buộc cụ thể cho ứng dụng

như phải quản các k ết nối đến các cơ sở dữ liệu có sẵn, đọc ghi các định dạng dữ

liệu hiện tại, hay đáp ứng các chính sách quản lý hiện tại,…

+Việc sử a chữ a các hệ thống có sẵn để đưa chúng vào hoạt động trong môi

tr ườ ng Grid thì phức tạ p, khó khăn hơ n r ất nhiều. Vì bộ Globus Toolkit hiện nay tậ p




- 116 -

trung phát triển các công nghệ dựa trên ngôn ngữ Java (mặc dù cũng có các thư viện

và hàm API cho ngôn ngữ C), nên nếu muốn phát triển ứng dụng trên nền GT, các

nhà phát triển cần quan tâm đến một số tình huống sau:

Nếu hệ thống có sẵn đượ c viết bằng Java, tình huống này khá dễ dàng

để đưa ứng dụng chạy trên Grid, nhà phát triển có thể xây dựng các lớ p mớ i vớ i

một số phươ ng thức, các phươ ng thức này sẽ thực hiện các thao tác cần thiết cho

phép chuyển các tham số, gọi các hàm hệ thống có sẵn và tr ả về các k ết quả cần

thiết.

Nếu hệ thống có sẵn không đượ c viết bằng Java, có thể sử dụng công

nghệ Java Native Interface (JNI), tuy nhiên hệ thống chỉ giớ i hạn chạy trên mộthệ điều hành cụ thể, ví dụ hệ thống cũ cần gọi các hàm trong thư viện DLL của

Windows hay Linux, thì ứng dụng cũng chỉ có thể triển khai trên hệ thống toàn

máy Windows hay Linux mà thôi. Đây không phải là một vấn đề lớ n nếu hệ

thống Grid là đơ n nhất và đồng dạng. Vớ i các hệ thống hỗn tạ p, cũng có thể giải

quyết bằng cách xây dựng các Grid service (thực chất là Web service) bao bọc

hệ thống cũ nếu ngôn ngữ lậ p trình tạo ra nó có hỗ tr ợ Web service, bằng cách

sử dụng chuẩn đang phát triển Webservices Resource Framework (WSRF).

Nếu hệ thống có sẵn nhỏ và đóng gói tốt, đây là tr ườ ng hợ p r ất tốt, nhà

phát triển có thể xây dựng các Grid service đơ n nhiệm và triển khai chúng trong

hệ thống Grid, các Grid service dạng này thườ ng là một tiến trình yêu cầu năng

lực xử lý lớ n, nhận vào một tậ p dữ liệu, thực hiện xử lý và tr ả về tậ p k ết quả khi

k ết thúc.

Nếu hệ thống có sẵn lớ n, phứ c tạp, có nhiều k ết nối, thì việc có nên

đưa nó chạy trên Grid cần phải đượ c xem xét và cân nhắc k ỹ lưỡ ng. Các Grid

node cần phải có năng lực đủ mạnh để xử lý các công việc lớ n, phức tạ p, thỏa

mãn các yêu cầu về hiệu năng. Nếu ứng dụng có nhiều k ết nối đến các hệ thống

khác, phải truyền các tậ p dữ liệu lớ n, mà không thể thực hiện song song, thì có

thể tạo ra hiệu ứng cổ chai, không tận dụng đượ c các ưu thế của Grid. Để sử

dụng lại hệ thống, cần phải tổ chức lại mã, phân chia chúng thành các module,

loại bỏ các ràng buộc phụ thuộc giữa chúng càng nhiều càng tốt, sau đó xây




- 117 -

dựng các module thành các Grid service đơ n nhiệm và triển khai chúng trên

Grid.

44..11..22.. ĐĐáánnhh ttí í nnhh k k hhảả tthhii ccủủaa ứ ứ nngg ddụụnngg k k hhii cchhạạyy ttrrêênn GGrriidd Một vấn đề quan tr ọng tr ướ c khi bắt đầu dự án xây dựng ứng dụng trong Grid là

đánh giá xem ứng dụng có thích hợ p, cần thiết để chạy trên Grid hay không. Không

phải tất cả các ứng dụng đều có thể triển khai thành công và tiết kiệm chi phí trên

Grid. Ví dụ, một ứng dụng xử lý tuần tự cũng có thể cho thực thi trên Grid, tuy

nhiên sẽ không tận dụng đượ c các ích lợ i của Grid mà có thể ảnh hưở ng đến hiệu

suất ứng dụng do có thêm các chi phí quản lý Grid. Tậ p đoàn IBM đã đưa ra mộtdanh sách tham khảo các tiêu chí cần thiết để đánh giá khả năng triển khai một ứng

dụng trên Grid. Các chi tiết, xin xem thêm trong phần Phụ lục A – Các tiêu chí đánh

giá tính khả thi của một ứng dụng Grid. Dướ i đây là một số vấn đề quan tr ọng có

thể gây cản tr ở việc triển khai một ứng dụng trên Grid, cần cân nhắc k ỹ :

Ứ ng dụng có số lượ ng hoạt động liên lạc liên tiến trình (inter-process

communication) nhiều, lớ n nhưng không có các chuyển mạch tốc độ cao, điều

này sẽ làm chậm việc thực thi ứng dụng.

Ứ ng dụng có các yêu cầu lậ p lịch khắt khe dựa trên nguồn dữ liệu đượ c

cung cấ p không ổn định, không thể đoán tr ướ c.

Không thể giải quyết các tr ở ngại khi xây dựng hệ thống mạng thoả yêu

cầu về băng thông của ứng dụng.

Các giớ i hạn về môi tr ườ ng thực thi công việc.

Các yêu cầu về các giao dịch thươ ng mại an toàn trên Grid, hiện nay chưa

có một chuẩn nào phục vụ các giao dịch này.

Vấn đề phụ thuộc giữa các công việc, thể hiện ở việc quản lý các luồng

công việc phức tạ p ở máy chủ, và dẫn đến yêu cầu liên lạc giữa các tiến trình

lớ n.

Các protocol phục vụ các công việc không đượ c hỗ tr ợ bở i các tườ ng lửa,

proxy sẽ dẫn đến việc ngăn chặn việc thực thi của các công việc.

…




- 118 -

Đó là một số vấn đề cần quan tâm khi xem xét tính khả thi để ứng dụng chạy

trên Grid.

44..22.. CCáácc yyêêuu ccầầuu ccầầnn qquuaann ttââmm kkhhii xxââyy ddựựnngg ứứnngg ddụụnngg

Ngoài các yêu cầu về chức năng của ứng dụng, đượ c đặc tả bở i các sơ đồ

usecase, và các yêu cầu phi chức năng cần thiết như trong các dự án phát triển ứng

dụng truyền thống, các nhà phát triển cần quan tâm đến các yêu cầu phi chức năng

đặc tr ưng của một ứng dụng Grid để phân tích, đưa ra các giải pháp thích hợ p. Dướ i

đây, chúng ta sẽ xem xét một số yêu cầu chính cùng vớ i một số gợ i ý giải quyết.

44..22..11.. K K hhảả nnăănngg mmở ở rrộộnngg ((SSccaallaabbiilliittyy))

Khi có nhiều công việc gửi đến hệ thống, mức độ sử dụng tài nguyên sẽ tăng lên

cho đến khi hệ thống không thể xử lý nổi. Hệ thống sẽ ngừng hoạt động hoặc hoạt

động thiếu chính xác. Một thiết k ế hệ thống tốt cần cho phép thêm tài nguyên một

cách dễ dàng để giải quyết các yêu cầu phát sinh mà không cần phải thiết k ế lại hệ

thống. Ứ ng dụng và các trình chủ của nó nên đượ c xây dựng để có thể triển khai

trên nhiều node khác nhau. Trong nhiều tr ườ ng hợ p, có thể có nhiều thể hiện trình

chủ tồn tại song song trên một node mà không làm tê liệt node đó, điều này giúp

cho việc sử dụng tài nguyên một cách tối ưu, giảm chi phí toàn hệ thống, chỉ khi

một node bị quá tải thì mớ i thêm một node mớ i.

44

.

.22

.

.22

.

. BBảả

oo

mmậậ

tt

Bảo mật là một vấn đề phức tạ p, quan tr ọng nhưng đôi khi không đượ c quan tâm

đúng mức khi phát triển ứng dụng. Các nhà phát triển nên xem xét các vấn đề dướ i

đây để có thể phát triển một ứng dụng an toàn về bảo mật.

+ Chứ ng thự c

Ngườ i dùng phải đăng nhậ p tr ướ c khi sử dụng các chức năng khác.

+ Phân quyền






- 120 -

44..22..55.. HHiiệệuu ssuuấấtt ứ ứ nngg ddụụnngg((PPeerrf f oorrmmaannccee))

Trong khi xem xét việc đưa ứng dụng thực thi trong môi tr ườ ng Grid, hiệu suất

của Grid cũng như các yêu cầu về hiệu suất của ứng dụng cần phải đượ c cân nhắc.Các nhà sử dụng dịch vụ thườ ng quan tâm đến chất lượ ng dịch vụ, bao gồm thờ i

gian chờ và thực thi có thể chấ p nhận đượ c. Còn về phía ngườ i cung cấ p các ứng

dụng trên Grid như là các dịch vụ thì quan tâm đến việc tối ưu sử dụng tài nguyên

và nâng cao năng lực của hệ thống càng nhiều càng tốt. Các mục tiêu về hiệu suất

hệ thống trên hai khía cạnh trên đượ c trình bày dướ i đây.

+ Về phía nhà cung cấp dịch vụ

Quan tâm đến việc tối ưu hoá việc sử dụng các tài nguyên khác nhau để đạt

đến hiệu suất cao nhất. Các tài nguyên không chỉ giớ i hạn ở các chu k ỳ CPU, bộ

nhớ , không gian lưu tr ữ, các cơ sở dữ liệu, hay xử lý ứng dụng. Việc cân bằng tải

công việc (workload balancing) và các cơ chế lậ p lịch cũng đượ c sử dụng để đạt các

mục tiêu hiệu suất hệ thống. Ứ ng dụng có thể tận dụng nhiều tài nguyên một lúc

bằng cách chia thành các thực thể nhỏ hơ n và thực thi phân tán trong Grid. Mục

tiêu để sử dụng Grid là tăng hiệu suất của toàn bộ ứng dụng.+ Về phía nhà sử dụng dịch vụ

Quan tâm đến thờ i gian thực thi hệ thống. Thờ i gian thực thi của ứng dụng

trên Grid có thể thay đổi r ất lớ n tuỳ thuộc vào kiểu của tài nguyên đượ c sử dụng và

các chính sách về chất lượ ng dịch vụ của nhà cung cấ p. Ví dụ, một công việc có thể

đượ c khở i động ngay lậ p tức và đượ c ưu tiên sử dụng tài nguyên, hoặc cũng vớ i

công việc đó có thể đượ c lậ p lịch để chạy vào ban đêm khi các yêu cầu tài nguyên

giảm xuống. Nhà cung cấ p dịch vụ có thể đưa ra các mức giá khác nhau cho hai loại

hình chất lượ ng dịch vụ trên. Nếu ứng dụng có thể có nhiều công việc con độc lậ p

có thể đượ c lậ p lịch để thực thi song song, thờ i gian thực thi có thể giảm đáng k ể

bằng cách thực thi các công việc trên các node khác nhau.

Các yếu tố ảnh hưở ng đến thờ i gian thực thi ứng dụng:

1. Thờ i gian trễ trong liên lạc/truy cập dữ liệu Tốc độ, băng thông và độ tr ễ của hệ thống mạng máy tính có thể ảnh

hưở ng r ất lớ n đến hiệu suất của ứng dụng nếu nó cần phải trao đổi vớ i một ứng






- 122 -

cố gắng dự đoán hết các khả năng gây lỗi và đưa ra các cơ chế thích hợ p để giải

quyết chúng. Thườ ng các khả năng gây lỗi là do lỗi của host và của hệ thống mạng.

Dướ i đây là một số cơ chế kiểm soát các lỗi này.

+ Checkpoint-restart

Khi công việc đang thực thi, các tr ạng thái của nó sẽ đượ c lưu lại theo từng

khoảng thờ i gian xác định. Khi máy tính thực thi công việc bị hỏng, công việc có

thể đượ c khở i động lại trên một máy khác vớ i tr ạng thái thực thi gần nhất đượ c lưu

lại và chạy tiế p. Bằng cách này, các công việc dài ngày có thể chạy trong nhiều

tháng hoặc cả năm ngay cả khi các hệ thống bị hỏng thườ ng xuyên.

+ Persistent storage Các tr ạng thái liên quan của mỗi công việc đượ c lưu tr ữ trong các vùng lưu

tr ữ lâu dài bở i trình quản lý Grid để đối phó vớ i các hư hỏng cục bộ. Khi máy tính

cục bộ khở i động lại, các thông tin tr ạng thái của các công việc đượ c lấy lại, k ết nối

đến trình quản lý công việc đượ c thiết lậ p lại và công việc tiế p tục đượ c thực thi.

+ Heartbeat monitoring

Ở tr ạng thái bình thườ ng, các thông điệ p thăm dò đượ c gửi đến các tiến trình,

và tiến trình tr ả lờ i lại. Nếu tiến trình không tr ả lờ i thông điệ p trong một khoảng

thờ i gian xác định, thông điệ p sẽ đượ c gửi đến một tiến trình thay thế khác, tiến

trình này có thể đượ c dùng để xác định tr ạng thái của tiến trình đầu tiên và có thể

khở i động lại nó. Tuy nhiên, nếu tiến trình thứ hai cũng không thể tr ả lờ i thông

điệ p, có thể là do hư hỏng hệ thống máy tính cục bộ, hoặc mạng, trong tr ườ ng hợ p

này thì phải chờ cho đến khi k ết nối đượ c thiết lậ p lại.

44..22..77.. QQuuảảnn ttrrịị hhệệ tthhốốnngg ((MMaannaaggeemmeenntt))

Tất cả các hệ thống đều cần một bộ các công cụ đế quản tr ị và điều khiển. Nếu

thiếu các công cụ này, sẽ r ất khó theo dõi tình tr ạng hoạt động hiện hành của hệ

thống Grid. Nên sử dụng một mạng phụ, dành riêng trong hệ thống để thực hiện các

chức năng quản tr ị và điều khiển để không ảnh hưở ng đến hiệu suất của Grid.






- 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.

44..22..1100.. ĐĐịịnnhh ddạạnngg f f iillee

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.

44..22..1111.. VViiệệcc ccààii đđặặtt hhệệ tthhốốnngg

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.

44..22..1122.. VVấấnn đđềề tthhôônngg ttiinn GGrriidd

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 đề, …

44..22..1133.. TTí í nnhh ttiiệệnn ddụụnngg

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




- 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ềukiệ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.

44..33.. TThhiiếếtt kkếế ttổổnngg qquuaann

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 đó.








- 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ử




- 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ấytrê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ảitrê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)




- 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.

44..44..22.. XXeemm xxéétt ssử ử ddụụnngg nnggôônn nnggữ ữ llậậpp ttrr ì ìnnhh

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




- 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, …

44..44..33.. VVấấnn đđềề pphhụụ tthhuuộộcc ccủủaa ccôônngg vviiệệcc vvààoo mmôôii ttrrư ư ờ ờ nngg hhệệ tthhốốnngg

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.




- 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.

44..44..44.. ĐĐồồ hh ì ìnnhh ccôônngg vviiệệcc

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ị.




- 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ôitr ườ 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.

44..55.. TTr r iiểểnn kkhhaaii ccààii đđặặtt ccáácc GGr r iidd SSeer r vviiccee

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 :




- 134 -

http://www.casa-sotomayor.net. Ở đâ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.

44..55..11.. CCáácc bbư ư ớ ớ cc xxââyy ddự ự nngg vvàà ttrriiểểnn k k hhaaii GGrriidd SSeerrvviiccee 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 Gridservice. 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.






- 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ựchiệ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;




- 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




- 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="http://xml.apache.org/axis/wsdd/"

xmlns:java="http://xml.apache.org/axis/wsdd/providers/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"/>



<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.




- 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 : http://ant.apache.org.

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




- 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.

44..55..22.. XXââyy ddự ự nngg cclliieenntt

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);




- 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 -

CChhưươơnngg 55.. QQuuảảnn ttr r ịị mmạạnngg vvàà ccáácc hhệệ tthhốốnngg

qquuảảnn ttr r ịị 55..11.. QQuuảảnn ttr r ịị mmạạnngg

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.

55..11..11.. K K hhááii nniiệệmm 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 haynhữ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”.

55..11..22.. CCáácc ll ĩ ĩ nnhh vvự ự cc qquuảảnn ttrrịị mmạạnngg

Tổ chức International Organization for Standardization đã đưa ra một mô hìnhkhá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.

55..11..22..11.. QQuuảảnn llýý hhiiệệuu nnăănngg ((PPeerrf f oorrmmaannccee MMaannaaggeemmeenntt))

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)




- 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.

55..11..22..22.. QQuuảảnn llýý llỗỗii hhệệ tthhốốnngg ((FFaauulltt MMaannaaggeemmeenntt))

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.




- 144 -

55..11..22..33.. QQuuảảnn llýý bbảảoo mmậậtt ((SSeeccuurriittyy MMaannaaggeemmeenntt))

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.

55..22.. HHệệ tthhốốnngg qquuảảnn ttr r ịị mmạạnngg

55..22..11.. MMôô hh ì ìnnhh vvàà hhooạạtt đđộộnngg

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)




- 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àythườ 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




- 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.

55..22..22.. MMộộtt ssốố cchhứ ứ cc nnăănngg ccơ ơ bbảảnn ccủủaa mmộộtt hhệệ tthhốốnngg qquuảảnn ttrrịị mmạạnngg

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-




- 147 -

based polling. Vớ i k ỹ thuật này, khi một thiết bị hỏng, agent sẽ cố gắng gửi thông

báo (trap) về module quản tr ị, module này sẽ thực hiện truy vấn đến thiết bị đó để

xác định chi tiết của vấn đề. Đây là một hướ ng tiế p cận tốt nhằm giảm thiểu lưu

lượ ng thông tin quản lý.

+ Auto Discovery

Ý tưở ng đằng sau khái niệm này là chúng ta chỉ cần cài đặt module quản tr ị

r ồi ra lệnh cho nó, nó sẽ tự động gửi các truy vấn (và các agent) đến các thiết bị

trong mạng r ồi tự động xây dựng một bản đồ hay một cơ sở dữ liệu về hệ thống dựa

trên các thông tin tr ả lờ i. Có nhiều cơ chế để thực hiện việc này, tuỳ thuộc vào các

protocol quản tr ị, tuy nhiên đến nay chức năng trong các hệ quản tr ị chưa hoạt độngnhư ý muốn do tính phức tạ p của hệ thống.

+ Device Configuration

Đây là một chức năng cần thiết để có thể cấu hình các thiết bị trong hệ thống

từ trình giao diện điều khiển, không cần phải đi đến tận nơ i đặt thiết bị, điều này r ất

quan tr ọng, hỗ tr ợ r ất nhiều cho ngườ i quản tr ị vớ i một mạng lớ n, khoảng cách xa.

Vấn đề là phải có các agent và cơ chế cấu hình thích hợ p cho từng thiết bị

+ Graphical Mapping

Các hệ thống quản tr ị mạng ngày nay cần phải có một hệ giao diện đồ hoạ

tốt. Nó giúp cho việc theo dõi hệ thống mạng dễ dàng hơ n, nhất là trong các hệ

thống mạng phức tạ p ngày nay.

+ Trapping Events

Như đã đượ c đề cậ p trên đây, “trap” là một phươ ng thức quan tr ọng để agent

báo cho module quản tr ị biết có sự cố bất thườ ng xảy ra. Trap không phải là một bản báo cáo, nó chỉ chứa đủ thông tin để module quản tr ị biết chuyện gì đã xảy ra.

Ví dụ, khi một interface bị “down” hoặc “up” lại, hay một ai đó thử xâm nhậ p trái

phép vào thiết bị,...

+ Event Logging

Cho phép thu thậ p, lưu tr ữ lại các k ết quả truy vấn, báo cáo từ các agent để

phục vụ cho việc phân tích sau này. Hệ quản tr ị cần phải cho phép cấu hình những

sự kiện nào cần đượ c lưu lại, bở i vì một hệ thống mạng lớ n sẽ phát sinh ra r ất nhiều




- 148 -

sự kiện, nếu không lọc lại sẽ dẫn đến tình tr ạng tràn vùng lưu tr ữ trong một thờ i

gian ngắn. Hệ quản tr ị nên có cơ chế lưu tr ữ xoay vòng .

+ Protocol Analysis

Có thể là công cụ mạnh mẽ nhất trong một hệ quản tr ị. Cho phép bắt và phân

tích đến mức chi tiết từng packet lưu thông trên mạng sẽ giúp ngườ i quản tr ị xác

định đượ c sự cố mạng một cách nhanh chóng (nếu đượ c cấu hình đúng).

55..22..33.. HHệệ tthhốốnngg qquuảảnn ttrrịị mmạạnngg ttrroonngg tthhự ự cc ttếế

Các hệ thống quản tr ị mạng luôn đượ c xây dựng dựa trên các protocol quản tr ị

cụ thể. Hầu hết các hệ thống sử dụng các protocol mở , tuy nhiên vẫn có một số hệ thống sử dụng protocol đặc biệt của nhà cung cấ p. Các hệ thống quản tr ị mạng hiện

nay thườ ng thiếu các chức năng cần thiết để quản lý hiệu quả một hệ thống mạng,

do tính phức tạ p của các hệ thống mạng cũng như do các protocol sử dụng thiếu các

hỗ tr ợ cần thiết.

Hiện nay có r ất nhiều gói phần mềm quản tr ị hệ thống mạng đến từ nhiều nhà

cung cấ p khác nhau, một số chỉ cung cấ p các chức năng đơ n giản để quản lý một

mạng nhỏ, trong khi một số khác thì phức tạ p hơ n.Việc lựa chọn các hệ thống quản

tr ị phụ thuộc các tiêu chí như môi tr ườ ng mạng(độ lớ n, bản chất hệ thống) , các yêu

cầu quản tr ị, chi phí, các hệ điều hành,… nhưng thườ ng phải dùng phối hợ p nhiều

gói phần mềm khác nhau để đáp ứng nhu cầu quản tr ị. Các hệ thống quản tr ị mạng

hiện nay chủ yếu tậ p trung vào l ĩ nh vực bảo mật. Trong l ĩ nh vực bảo mật mạng, bên

cạnh việc sử dụng các hệ thống bảo vệ truyền thống như firewall, proxy,… ngày

nay ngườ i ta thườ ng sử dụng thêm các hệ thống thông minh hơ n, đó là các hệ thống

phát hiện xâm nhậ p (Intrusion Detection System(IDS)). Mặc dù các hệ thống IDS

chuyên sâu về l ĩ nh vực bảo mật mạng, nhưng các ý tưở ng, k ỹ thuật sử dụng trong

các hệ thống IDS cũng có thể sử dụng trong các l ĩ nh vực quản tr ị mạng khác. Phần

dướ i đây giớ i thiệu đôi nét về các hệ thống IDS.




- 149 -

55..33.. HHệệ tthhốốnngg IInnttr r uussiioonn DDeetteeccttiioonn SSyysstteemm ((IIDDSS))

55..33..11.. K K hhááii nniiệệmm

IDS là một hệ thống phòng thủ, có nhiệm vụ phát hiện các hoạt động trái phép,

có khả năng gây nguy hiểm cho hệ thống mạng đượ c bảo vệ và phát sinh các phản

ứng thích hợ p.

55..33..22.. CCáácc hhư ư ớ ớ nngg ttiiếếpp ccậậnn

Một hệ thống IDS cần phải có khả năng phân biệt giữa các hoạt động bình

thườ ng và bất bình thườ ng của ngườ i dùng để phát hiện các nguy cơ tiềm ẩn. Cómột số hướ ng tiế p cận truyển thống để giải quyết vấn đề này là anomal detection và

signature detection.

1. Anomal detection

IDS dạng này xây dựng các tậ p dữ liệu về hoạt động bình thườ ng của ngườ i

dùng và hệ thống, sau đó sử dụng các tậ p dữ liệu này để so sánh vớ i các hoạt động

hiện tại nhằm phát hiện ra các hoạt động bất bình thườ ng. Khi có một tậ p dữ liệu

các hoạt động bình thườ ng thì tất cả các hành động trong mạng không có trong tậ p

dữ liệu này đều đượ c xem là bất bình thườ ng.

Một trong những ưu điểm lớ n nhất của hướ ng tiế p cận này là có thể phát hiện

các hành động phạm pháp mớ i chưa từng đượ c biết đến, tuy nhiên nhượ c điểm của

nó là tỷ lệ phát hiện sai cũng lớ n nếu tậ p dữ liệu không chứa đầy đủ các hoạt động

bình thườ ng.

2. Signature detection IDS dạng này sử dụng tậ p dữ liệu về hoạt động phạm pháp đã biết (ví dụ như

các mẫu tấn công, các chuỗi ký tự nguy hiểm,…) để phát hiện các hoạt động bất

bình thườ ng.

Hướ ng tiế p cận này có độ chính xác cao, tỷ lệ phát hiện sai thấ p, các thuật

toán xử lý đơ n giản, dễ xây dựng các tậ p dữ liệu, tuy nhiên khuyết điểm lớ n nhất là

có thể để “lọt” qua các hoạt động phạm pháp chưa đượ c biết đến, phải liên tục cậ p

nhật các tậ p dữ liệu.




- 150 -

Các hướ ng tiế p cận trên đượ c sử dụng trong hầu hết các hệ thống IDS hiện nay,

tuy nhiên các hướ ng tiế p cận trên có giớ i hạn r ất lớ n do phụ thuộc vào kiến thức

hiện có về hệ thống hoặc l ĩ nh vực bảo mật của các nhà xây dựng ứng dụng, do đó

khó thích nghi vớ i các hệ thống mạng mớ i, phức tạ p, các kiểu tấn công mớ i,…

Hiện nay, trên thế giớ i xuất hiện các hướ ng tiế p cận mớ i nhằm đưa khả năng

thông minh nhân tạo vào các hệ thống IDS, nâng cao tính chính xác, tuỳ biến của

các hệ thống này. Công nghệ Data mining (khai thác dữ liệu) là công nghệ cơ bản

trong các hướ ng tiế p cận này. Công nghệ khai thác dữ liệu đượ c sử dụng để phân

tích, trích ra các thông tin chưa đượ c biết đến nhưng r ất hữu dụng từ một tậ p r ất lớ ncác gói dữ liệu, các thông tin theo dõi của hệ thống (log file), để huấn luyện hệ

thống hay tạo ra các tậ p dữ liệu sử dụng trong các hướ ng tiế p cận trên. Đã có nhiều

k ỹ thuật khai thác dữ liệu đượ c nghiên cứu, nhưng chưa thể áp dụng trong thực tế

do một nguyên nhân quan trong là trong thực tế, các hệ thống mạng thiếu các thiết

bị có năng lực xử lý lớ n để xử lý một khối lượ ng khổng lồ dữ liệu thông tin mạng.

Các thông tin chi tiết về các hệ thống IDS và tiế p cận Khai thác dữ liệu trong các

hệ thống IDS, xin xem thêm trong tài liệu tham khảo.

55..44.. GGiiớớii tthhiiệệuu mmộộtt ssốố ccôônngg ccụụ hhỗỗ ttr r ợợ qquuảảnn ttr r ịị

mmạạnngg

Như đã trình bày ở trên, để có một hệ thống quản tr ị tốt hiện nay, cần sử dụng

k ết hợ p nhiều loại công cụ khác nhau. Dướ i đây xin giớ i thiệu một số công cụ cần

thiết:

55..44..11.. EEtthheerreeaall

Ethereal, là một phần mềm mã nguồn mở , bắt và phân tích packet theo các

protocol mạng, có tất cả các chức năng cần thiết của một chươ ng trình phân tích

packet. Ethereal là phần mềm đượ c sử dụng r ộng rãi nhất bở i các chuyên gia mạng

trong việc phân tích, gỡ r ối, phát triển các protocol mạng, xem xét các packet lưu




- 151 -

thông trong hệ thống mạng, từ đó có thể cung cấ p các thông tin hữu ích trong việc

quản tr ị mạng.

Hình 5-2 Màn hình giao diện Ethereal.

Một số chức năng chính:

+ Cho phép bắt các packet lưu thông trong hệ thống mạng theo một bộ lọc

(capture filters) đặc tả bở i nhà quản tr ị, lưu xuống file dữ liệu.

+ Hỗ tr ợ r ất nhiều định dạng file packet khác nhau, như Sniffer™ Pro, AIX's

iptrace, Microsoft's Network Monitor, Novell's LANalyzer, RADCOM's

WAN/LAN Analyzer, Cisco Secure IDS iplog, … ,hỗ tr ợ định dạng file XML. Do

đó tươ ng thích vớ i nhiều phần mềm khác.

+ Bắt packet trên nhiều chuẩn mạng khác nhau như Ethernet, FDDI, PPP,

Token-Ring, IEEE 802.11, Classical IP over ATM, và loopback interfaces.+ Hiện có khả năng phân tích packet theo khoảng 530 protocol mạng thông

dụng.

+ Các thông tin của các packet đượ c hiển thị theo nhiều dạng khác nhau trên

giao diện đồ họa, sử dụng các bộ lọc hiển thị (display filter) để lựa chọn các packet

cần theo dõi, tô màu các thông tin hữu ích.

+ …





Chươ ng 6. Hệ thống quản tr ị Grid NetManager

- 153 -

CChhưươơnngg 66.. HHệệ tthhốốnngg qquuảảnn ttr r ịị GGr r iidd

NNeettMMaannaaggeer r

66..11.. GGiiớớii tthhiiệệuu ýý ttưưởởnngg

Như đã biết ở phần trên, ngày nay bộ phận quản tr ị mạng phải phân tích, xử lý

một khối lượ ng thông tin khổng lồ nhằm đưa ra các giải pháp, phản ứng theo thờ i

gian thực để đảm bảo cho các hệ thống mạng hoạt động thông suốt, tin cậy, an toàn.

Để có thể thực hiện tốt công việc của mình, bộ phận quản tr ị mạng cần phải có

những công cụ phân tích, cung cấ p thông tin hoạt động của hệ thống mạng mạnhmẽ. Trên thế giớ i cũng đã có nhiều hướ ng tiế p cận, đã có các công cụ hỗ tr ợ khá

mạnh. Tuy nhiên, chúng vẫn còn một số giớ i hạn như về giá cả, năng lực xử lý,

chưa tích hợ p đầy đủ về các chức năng,…

Sau một thờ i gian tìm hiểu và nghiên cứu, công nghệ Grid Computing đượ c

chọn ứng dụng vào bài toán phân tích, cung cấ p thông tin hỗ tr ợ quản tr ị mạng vớ i

hy vọng tận dụng đượ c năng lực xử lý nhàn r ỗi hiện có trong các hệ thống mạng để

giải quyết bài toán hiệu quả hơ n, trong giớ i hạn chi phí có thể chấ p nhận đượ c. Mục

tiêu lâu dài là xây dựng một hệ thống nhằm hỗ tr ợ bộ phận quản tr ị mạng trong các

l ĩ nh vực: quản lý hiệu năng, quản lý lỗi và bảo mật. Đưa các công nghệ khai thác dữ

liệu (data mining) và trí tuệ nhân tạo vào hệ thống để phân tích các dữ liệu thu

đượ c, tìm ra các quy luật sử dụng của ngườ i dùng, các quy luật tấn công, … nhằm

huấn luyện hệ thống có thể tự động nhận dạng các mối nguy hiểm và đưa ra các

phản ứng thích hợ p, hiệu quả. Hệ thống là cũng một sự tích hợ p của nhiều gói phầnmềm hiện có trong một thể thống nhất nhằm đơ n giản hoá công việc cũng như thỏa

mãn các nhu cầu quản tr ị. Ứ ng dụng k ế thừa ý tưở ng của các hệ thống IDS nhưng

mở r ộng ra các l ĩ nh vực khác ngoài bảo mật. Hệ thống có thể theo dõi, xử lý thông

tin trên toàn bộ hệ thống mạng chứ không phải chỉ trên một lối ra vào hệ thống

mạng như các hệ thống IDS hiện nay.




- 154 -

66..22.. Y Yêêuu ccầầuu cchhứứcc nnăănngg ccủủaa mmộộtt hhệệ tthhốốnngg qquuảảnn ttr r ịị

mmạạnngg Hệ thống quản tr ị mạng gồm các chức năng chính:

+ Bắt và lưu tr ữ thông tin về các packet lưu thông trên mạng trong các cơ sở

dữ liệu phục vụ cho việc phân tích, xử lý và khai thác dữ liệu. Cho phép lọc các dữ

liệu cần thiết theo yêu cầu nhằm làm giảm kích thuớ c lưu tr ữ.

+ Cho phép xử lý, lưu tr ữ, quản lý dữ liệu phân tán.

+ Cung cấ p thông tin về nhiều khía cạnh khác nhau của hệ thống mạng dựa

trên các câu truy vấn.

+ Tính toán, cung cấ p các chỉ số thống kê về hệ thống mạng

+ Tự động tổng hợ p các thông tin, vẽ sơ đồ thờ i gian thực các lưu thông trên

mạng, phát hiện các thay đổi trong đồ hình mạng.

+ Cho phép quản lý, điều khiển các thiết bị trong hệ thống mạng.

+ Thực hiện “khai thác dữ liệu”, tìm ra các luật theo yêu cầu ngườ i quản tr ị,

cho phép nhậ p, quản lý các đặc tả về luật và các phản ứng tươ ng ứng để theo dõi,giám sát toàn bộ hệ thống về nhiều l ĩ nh vực.

+ Dựa trên các luật đượ c mô tả, thực hiện theo dõi toàn bộ hệ thống và phát

sinh phản ứng thích hợ p khi một hiện tượ ng bất thườ ng xảy ra.




- 155 -

66..33.. MMôô hhììnnhh tthhàànnhh pphhầầnn vvàà hhooạạtt đđộộnngg ccủủaa hhệệ

tthhốốnngg

66..33..11.. MMôô hh ì ìnnhh tthhàànnhh pphhầầnn

Hình 6-1 Mô hình thành phần ứ ng dụng Grid NetManager.




- 156 -

Giải thích

STT Tên Nhiệm vụ

1. Module Presentation Là giao diện đồ họa, có nhiệm vụ nhận các lệnhtừ nhà quản tr ị mạng, cấu hình và điều khiển cácmodule khác hoạt động, thu nhận, tổng hợ p cácthông tin từ các module và k ết xuất k ết quả chonhà quản tr ị.

2. Module Sensor Bắt, lọc, lưu tr ữ các packet vào cơ sở dữ liệu.3. Module

AnalyzerAndMiner Thực hiện phân tích các dữ liệu từ cơ sở dữ liệuđể cung cấ p thông tin cần thiết cho nhà quản tr ị;khai thác dữ liệu, phát sinh các luật.

4. Module RuleManager Cung cấ p các chức năng quản lý, lưu tr ữ, truy vấn

tậ p luật.5. Module Monitoring Thực hiện lấy các luật và theo dõi, phân tính các

packet theo thờ i gian thực để phát hiện các hiệntượ ng bất thườ ng, từ đó dựa vào các đặc tả phảnứng mà phát sinh các hành động thích hợ p, có thể là thông báo cho nhà quản tr ị, lưu xuống file loghay phát sinh các lệnh điều khiển thích hợ p đếncác module DeviceAgent.

6. Module DeviceAgent Nhận các lệnh điều khiển và để điều khiển và cấuhình các thiết bị nhằm thực hiện điều khiển hệ thống mạng có các hành động phù hợ p để đápứng các sự kiện.

7. Module GridManager Thực hiện tất cả chức năng để quản lý, điều khiểnGrid.

8. PacketDatabase Cơ sở dữ liệu thông tin các packet. Có thể lưudướ i dạng packet thô, cơ sở dữ liệu quan hệ, cáccấu trúc dữ liệu tiền xử lý cho các chức năng củahệ thống.

9. RuleDatabase Cơ sở dữ liệu các luật.

10. Log files Các file ghi vết các sự kiện xảy ra trong hệ thốngdo các module Monitoring ghi nhận đượ c.11. PreprocessingData Lưu tr ữ các dữ liệu tiền xử lý phục vụ việc phân

tích dữ liệu và phát sinh các luật.

Bảng 6-1 Các thành phần của ứ ng dụng Grid NetManager.

Các module trên đượ c thiết k ế để hoạt động tách biệt, mỗi module có thể chạy

trên nhiều máy tính, thiết bị khác nhau, trên một máy có thể có nhiều module, mỗi

module có thể nhiều thực thể thực thi song song vớ i nhau nhằm tận dụng các tài




- 157 -

nguyên. Các dữ liệu cũng đượ c lưu tr ữ phân tán trong Grid. Việc cấu hình vị trí các

module, dữ liệu có thể thực hiện tự động hoặc bằng tay theo ý của nhà quản tr ị.

66..33..22.. CCáácchh tthhứ ứ cc hhooạạtt đđộộnngg Một hệ thống mạng máy tính lớ n thườ ng đượ c chia thành nhiều mạng con (các

vùng broadcast domain, trong phạm vi luận văn này đượ c gọi là các LAN Segment).

Trên mỗi LAN Segment, có thể đặt một hay nhiều module Sensor trên các máy tính

khác nhau nhằm bắt các packet đang lưu thông trong LAN Segment theo các tiêu

chí khác nhau và lưu tr ữ các packet này xuống các cơ sở dữ liệu (PacketDatabases),

các cơ sở dữ liệu này có thể đượ c lưu tr ữ cục bộ hay phân tán trên các máy tínhkhác dựa trên khả năng lưu tr ữ hiện có, mỗi cơ sở dữ liệu chỉ chứa thông tin về các

packet lưu thông trong một LAN segment. Các tiêu chí để bắt các packet là các câu

mô tả về thông tin của các packet bao gồm (loại packet, các tr ườ ng và các giá tr ị

tươ ng ứng k ết hợ p vớ i các phép toán so sánh >,<,=,…, các phép toán logic AND,

OR, NOT,…).

Các cơ sở dữ liệu đượ c sử dụng bở i module AnalyzerAndMiner khi có yêu cầu

từ module Presentation. Các module AnalyzerAndMiner có thể chạy song song trên

nhiều máy tính khác nhau, phân tích dữ liệu trên các cơ sở dữ liệu theo yêu cầu

nhằm cung cấ p thông tin đa dạng; khai thác dữ liệu, phát sinh các luật; và gửi tr ả k ết

quả về cho module Presentation. Quá trình phân tích, khai thác dữ liệu có thể phát

sinh các dữ liệu trung gian, chúng có thể đượ c lưu tr ữ phân tán trong các file dữ liệu

PreprocessingData. Các luật có thể là các quy luật, dấu hiệu tấn công, các hoạt động

của ngườ i dùng, các định mức hoạt động, các lỗi hệ thống,… Mỗi luật có các phản

ứng đi kèm như thông báo, ghi nhận, báo động, ngắt nguồn gây lỗi, ngăn chặn hoạt

động, cấu hình lại thiết bị mạng, … đượ c quy định bở i nhà quản tr ị. Các luật đượ c

lưu tr ữ dướ i dạng các đặc tả, lưu tr ữ trong các cơ sở dữ liệu luật quản lý bở i module

RuleManager. Hệ thống có các module Monitoring cũng chạy song song trên nhiều

máy khác nhau, sử dụng các luật và các dữ liệu trong các cơ sở dữ liệu để phát hiện

ra các hoạt động mạng đúng vớ i các luật (cũng có ngh ĩ a đó là những hoạt động tiềm

ẩn nguy hiểm), dựa trên các phản ứng đượ c quy định, phát sinh các lệnh điều khiển




- 158 -

gửi đến các module DeviceAgent để các module này điều khiển các thiết bị tươ ng

ứng nhằm có những hoạt động ngăn chặn thích hợ p. Đồng thờ i, module Monitoring

cũng phát sinh ra các thông báo, lưu tr ữ trong các Log file.

Tất cả các hoạt động quản lý, lưu tr ữ dữ liệu phân tán, gọi thực thi các module

đều đượ c thực hiện thông qua module GridManager, nó đóng vai trò là một cầu nối

giữa các phần ứng dụng vớ i hạ tầng Grid.

Module Presentation cung cấ p giao diện ngườ i dùng, cho phép nhà quản tr ị quản

lý, cấu hình, điều khiển tất cả các module toàn hệ thống, thu nhận tổng hợ p các

thông tin tr ả về từ các module và trình diễn cho nhà quản tr ị.

66..44.. PPhhâânn ttíícchh vvàà đđịịnnhh hhưướớnngg pphháátt ttr r iiểểnn ứứnngg ddụụnngg

Như giớ i thiệu trên đây, về bản chất đây là một ứng dụng phân tích và xử lý một

lượ ng r ất lớ n dữ liệu. Một máy tính không thể xử lý lượ ng dữ liệu này trong thờ i

gian cho phép, đặc biệt là theo thờ i gian thực. Các dữ liệu packet của toàn hệ thống

cần lưu tr ữ phân tán, đượ c phân thành các cơ sở dữ liệu độc lậ p vớ i nhau (mỗi cơ sở

dữ liệu lưu thông tin về một LAN segment), r ất thích hợ p để xử lý đồng thờ i các cơ

sở dữ liệu, đây là một dạng của luồng ứng dụng song song. Các module có thể đượ c

xem là một công việc độc lậ p, nhận các tậ p dữ liệu đầu vào, xử lý và tr ả k ết quả.

Các module tươ ng đối độc lậ p vớ i nhau, nhu cầu liên lạc giữa các module trong khi

hoạt động ít. Để giải quyết vấn đề truyền dữ liệu giữa các module, có thể thiết lậ p

một mạng LAN riêng giữa trên các máy tính chạy các module vớ i chi phí không cao

(chỉ cần gắn thêm cho mỗi máy tính một card mạng nữa và thêm một thiết bị mạng

như hub hay switch). Vớ i một số phân tích ban đầu như vậy, cho thấy ứng dụng có

thể hoạt động hiệu quả trên môi tr ườ ng Grid. Bộ Globus Toolkit đượ c chọn làm

nền tảng Grid vì GT là một middle-ware mã nguồn mở , hàng đầu trong trong l ĩ nh

vực Grid Computing, có nhiều chức năng thích hợ p để xây dựng ứng dụng.

Ứ ng dụng đòi hỏi khả năng bắt các packet lưu thông trong mạng, phân tích các

thông tin trong từng packet, phát sinh, quản lý các tậ p luật. Hiện nay trên thế giớ i có

2 phần mềm r ất tốt để thực hiện các chức năng này là Ethereal và Snort như đã giớ i




- 159 -

thiệu ở chươ ng tr ướ c. Cả hai phần mềm đều là phần mềm mã nguồn mở , nên có thể

k ế thừa và sử dụng lại mã nguồn, giảm bớ t chi phí xây dựng ứng dụng.

Tóm lại, định hướ ng phát triển ứng dụng là xây dựng ứng dụng trên nền tảng

công nghệ Grid Computing vớ i bộ Globus Toolkit; các chức năng của ứng dụng,

các mã phân tích, xử lý của các module đượ c k ế thừa và phát triển từ các chức năng,

mã xử lý của các phần mềm Ethereal, Snort.

66..55.. GGiiớớii hhạạnn vvấấnn đđềề tthhựựcc hhiiệệnn ccủủaa lluuậậnn vvăănn

Trên đây là giớ i thiệu về một ứng dụng quản tr ị mạng hoàn chỉnh, là mục tiêu để

đạt đượ c trong tươ ng lai, cùng vớ i một số định hướ ng về phát triển ứng dụng. Tuynhiên trong giớ i hạn của luận văn này, nhóm thực hiện chỉ xây dựng một số chức

năng của hệ thống, tậ p trung vào việc xây dựng các chức năng sử dụng bộ Globus

Toolkit, vớ i mục đích áp dụng thử nghiệm công nghệ Grid Computing vào bài toán

quản tr ị mạng. Hệ thống có tên là “Grid NetManager” hiện tại đượ c xây dựng vớ i

các chức năng như sau :

1. Bắt packet (Capture packet) trên nhiều LAN Segment

Hệ thống cho phép bắt các packet lưu thông trong các LAN segment theo

nhiều tiêu chí và lưu xuống các file dữ liệu phân tán. Vị trí các file này đượ c xác

định bở i nhà quản tr ị, có thể nằm ở bất cứ máy tính nào trong hệ thống Grid. Các

tiêu chí đượ c đặc tả dướ i dạng các chuỗi capture filter của Ethereal.

Hệ thống sẽ tự động tìm kiếm các máy tính thỏa yêu cầu trong hệ thống Grid

đưa ra cho nhà quản tr ị. Nhà quản tr ị chỉ cần chọn các máy tính để thực thi module

Sensor, hệ thống sẽ tự động gửi các module này và yêu cầu thực thi.2. Truy xuất thông tin trong các file dữ liệu phân tán

Cho phép tìm kiếm các packet thỏa điều kiện cho tr ướ c trong các file dữ liệu

thông qua các câu truy vấn. Hệ thống cho phép các module Xử lý truy vấn và tìm

kiếm thông tin chạy song song trên nhiều máy khác nhau thỏa yêu cầu.

3. Các chứ c năng tươ ng tự phần mềm Ethereal

Do các module phân tích, tổng hợ p thông tin k ế thừa lại từ phần mềm

Ethereal nên hệ thống có đầy đủ các chức năng của Ethereal, chỉ khác ở chỗ tậ p dữ





Chươ ng 7. Phân tích, thiết k ế và cài đặt thử nghiệm ứng dụng

- 161 -

CChhưươơnngg 77.. PPhhâânn ttíícchh,, tthhiiếếtt kkếế vvàà ccààii đđặặtt tthhửử

nngghhiiệệmm ứứnngg ddụụnngg Phần này sẽ trình bày bướ c phân tích, thiết k ế, cài đặt trong quá trình phát triển

ứng dụng.

77..11.. PPhhâânn ttíícchh

77..11..11.. NNggữ ữ ccảảnnhh hhệệ tthhốốnngg

Ngữ cảnh hệ thống xem toàn bộ hệ thống như một hệ thống đơ n nhất và xác

định các sự kiện, các dữ liệu vào ra hệ thống

Hình 7-1 Ngữ cảnh hệ thống.




- 162 -

77..11..22.. LLư ư ợ ợ cc đđồồ UUssee CCaassee

77..11..22..11.. MMôô hh ì ìnnhh

Capture

Ethereal Use Cases

Configure Packet Capturing

Query Packet Infomation

Nha quan tri

Search Nodes

Hình 7-2 Sơ đồ Usecase ứ ng dụng Grid NetManager thử nghiệm.

Danh sách Actor

STT Tên Actor Ý ngh ĩ a

1. Nha quan tri Nhà quản tr ị sử dụng các chức năng của hệ thống

Bảng 7-1 Danh sách các actorDanh sách các Usecase

STT Tên UseCase Ý ngh ĩ a

1. Search nodes Tìm kiếm các máy thỏa điều kiện

2. Configure Packet

Capturing

Cấu hình các module Sensor

3. Capture Thực hiện bắt packet theo cấu hình đã định tr ướ c.

4. Query Packet

Information

Truy vấn thông tin về các packet trong các file dữ

liệu

5. Ethereal Usecases Các Usecase cung cấ p bở i phần mềm Ethereal.

Bảng 7-2 Danh sách các usecase




- 163 -

77..11..33.. ĐĐặặcc ttảả UUssee CCaassee

77..11..33..11.. ĐĐặặcc ttảả UUssee ccaassee ““SSeeaarrcchh NNooddeess””

7.1.3.1.1. Tóm t ắ t Use case này cho phép nhà quản tr ị nhậ p vào tên máy chủ quản lý tr ạng thái

hệ thống (MDS GIIS Server), và tìm kiếm tất cả các máy trong hệ thống Grid hiện

tại theo một tiêu chuẩn về tr ạng thái đượ c qui định tr ướ c.

7.1.3.1.2. Dòng sự ki ệ n+ Dòng sự kiện chính

- Use case bắt đầu khi nhà quản tr ị nhậ p vào tên máy chủ quản lý tình tr ạng

hệ thống.

- Ngườ i dùng nhấn nút “Nodes” sau đó chươ ng trình tự động tìm kiếm

thông tin về tình tr ạng các máy tính trong hệ thống Grid và hiển thị lên

màn hình chính.

+ Các dòng sự kiện khác

Máy ngườ i dùng nhập máy tính sai Nếu ngườ i dùng nhậ p tên một máy tính không nằm trong hệ thống

Grid vào textbox “mds_server_name” thì chươ ng trình sẽ thông báo vớ i

ngườ i dùng và usecase k ết thúc

7.1.3.1.3. Post conditions

Nếu thông tin về mds_server_name ngườ i dùng nhậ p vào hợ p lệ thì hệ thốngxuất ra tất cả các máy tính thỏa điều kiện tìm kiếm.

77..11..33..22.. ĐĐặặcc ttảả UUssee ccaassee ““CCoonnf f iigguurree PPaacck k eett CCaappttuurriinngg””

7.1.3.2.1. Tóm t ắ t Use case này cho phép nhà quản tr ị cấu hình các module Sensor trong các

LAN segment và tổ chức việc lưu dữ liệu trong Grid. Việc cấu hình bao gồm chọn

các máy tính có thể thực thi module Sensor, chọn vị trí lưu các file trong Grid, cấu

hình các capture filter cho từng module.

7.1.3.2.2. Dòng sự ki ệ n




- 164 -

+ Dòng sự kiện chính

- Use case bắt đầu khi nhà quản tr ị chọn chức năng cấu hình bắt packet.

- Chươ ng trình tự động lấy thông tin về các máy tính trong hệ thống Grid

đã đượ c tìm ra trong use case “Search Grid node”.

- Đối vớ i mỗi máy tính thực thi cần cấu hình nơ i lưu tr ữ dữ liệu (packet),

capture filter trên từng máy. Yêu cầu các máy tính thực thi phải thuộc

LAN segment muốn bắt packet.

- Module Presentation lưu lại cấu hình vừa đượ c chọn.

+ Các dòng sự kiện khác

Máy ngườ i dùng nhập máy tính sai Nếu ngườ i dùng nhậ p vào một máy tính không nằm trong hệ thống

Grid thì thông báo vớ i ngườ i dùng và usecase k ết thúc

7.1.3.2.3. Post conditions

Nếu thông tin ngườ i dùng cấu hình hợ p lệ thì hệ thống sẽ có các cấu hình

module Sensor mớ i.

77..11..33..33.. ĐĐặặcc ttảả UUssee ccaassee ““CCaappttuurree””

7.1.3.3.1. Tóm t ắ t Use case này cho phép ngườ i dùng tiến hành và ngừng theo dõi packet trong

các LAN segment và hiển thị lên màn hình các packet k ết quả theo dõi đượ c từ các

module.

7.1.3.3.2. Dòng sự ki ệ n

- Use case bắt đầu khi nhà quản tr ị ra lệnh theo dõi/ngừng theo dõi Packet.

- Khi nhà quản tr ị ra lệnh theo dõi packet, Module GridManager sẽ tự động

gửi các module Sensor đến các máy tính thực thi (nếu chưa tồn tại trên

máy đích) và gọi thực thi các module theo cấu hình đã đượ c chọn trong

usecase Configure Packet Capturing.

- Khi nhà quản tr ị ra lệnh ngừng theo dõi packet, Module GridManager sẽ

tự động yêu cầu các module Sensor ngừng hoạt động.




- 165 -

- Trong thờ i gian theo dõi packet, Các packet sẽ đượ c tự động gửi về cho

module Presentation hiển thị ra màn hình.

- Ngườ i dùng có thể chọn theo dõi các packet trên các Sensor nào, hoặc

trên tất cả các Sensor.

7.1.3.3.3. Các đ i ề u ki ệ n tiên quyế t Phải có cấu hình các module Sensor bằng usecase Configure Packet

Capturing

77..11..33..44.. ĐĐặặcc ttảả UUssee ccaassee ““QQuueerryy””

7.1.3.4.1. Tóm t ắ t Use case này có mục đích chuẩn bị dữ liệu packet phục vụ cho các use case

phân tích, tổng hợ p dữ liệu của Ethereal. Use case này cho phép ngườ i dùng lấy

thông tin các packet trong các file dữ liệu theo các câu truy vấn.

Use case này cho phép ngườ i quản tr ị mạng nhậ p vào một chuỗi truy vấn

(theo định dạng display filter của Ethereal), hệ thống sẽ thực hiện truy vấn trên các

file dữ liệu phân tán, r ồi chọn ra các packet thoả điều kiện, tổng hợ p lại dướ i dạng

các packet mà các chức năng của Ethereal có thể phân tích đượ c.

7.1.3.4.2. Dòng sự ki ệ n- Use case bắt đầu khi nhà quản tr ị nhậ p câu truy vấn.

- Hệ thống lấy câu truy vấn, tự động cấu hình và gửi các module

PacketInfoProvider đến các máy tính thích hợ p và cho thực thi.

- Các module này dựa trên câu truy vấn, tìm các packet thỏa điều kiện

trong các file dữ liệu r ồi tr ả về. Sau khi hoàn thành nhiệm vụ, các module

này tự động k ết thúc.

- Module GridManager thực hiện tổng hợ p các packet lấy đượ c từ các

module PacketInfoProvider, đưa lên cho module Presentation xuất ra màn

hình.

7.1.3.4.3. Các đ i ề u ki ệ n tiên quyế t

Phải có các file dữ liệu trên các máy tính do usecase Capture bắt đượ c.






- 167 -

77..11..44.. MMôô ttảả ccáácc ddòònngg ssự ự k k iiệệnn

77..11..44..11.. UUssee ccaassee ““SSeeaarrcchh nnooddeess””

7.1.4.1.1. Search nodes - basic sequence diagram

: NodesInfo: Nha quan tri : Mai nForm : SearchNodesCtrl

// Enter GIIS Server name

// Search nodes information from GI IS server // Call search nodes

// Search information

// Compare with condition search

// Nodes satisfy condi tion search

All of nodes

satisfy condition

search from user

will be di splay in

combo box

7.1.4.1.2. Search colaboration diagram

: NodesInfo

: Nha quan tri

: Mai nForm

: SearchNodesCtrl

5: // Compare with condition search

1: // Enter GIIS Server name

2: // Search nodes information from GIIS server

3: // Call search nodes

6: // Nodes satisfy conditi on search

4: // Search information




- 168 -

7.1.4.1.3. Search nodes - GIIS server not found sequence diagram

: Nha quan tri : M ainForm : SearchNodesCtrl : NodesInfo : MessageBox

// Enter GIIS server name

// Search nodes information i n GIIS server

// Call search no des // Search information

// GIIS server not found

// Show me ssage box ("GIIS not server found")

7.1.4.1.4. Search nodes - GIIS server not found colaboration diagram

: Nha quan tri

: Mai nForm : Sea rchNodesCtrl

: NodesInfo

: MessageBox

1: // En ter GIIS server name

2: // Search nodes information i n GIIS server

3: // Call search nodes

4: // Search information

5: // GIIS server not found

6: // Show message box ("GIIS not server found")




- 169 -

77..11..44..22.. UUssee ccaassee CCoonnf f iigguurree PPaacck k eett CCaappttuurriinngg

7.1.4.2.1. Add Configuration Capturing sequence diagram

: MainForm: Nha quan tri : ConfigureForm : ConfigureCtrl : ConfigureEntity

// Call ConfigureForm // Show

// Enter conf iguration f or node

// Add a c onfiguration node

// Verify add a conf iguration

// Add conf iguration




- 170 -

7.1.4.2.2. Add Configuration Capturing colaboration diagram

3: // Enter configuration for node

: Nha quan tri

: MainForm

: ConfigureCtrl : ConfigureEntity

: ConfigureForm

1: // Call ConfigureForm

4: // Add a configuration node

2: // Show

5: // Verify add a configuration

6: // Add configuration




- 171 -

7.1.4.2.3. Update Configuration Capturing sequence diagram

: Nha quan tri : MainForm : Conf igureForm : C onfigureCtrl : ConfigureEntity

// Call ConfigureForm // Show

// Change conf iguration f or node

// Update a conf iguration node

// Verify update a configuration

// Change conf iguration

7.1.4.2.4. Update Configuration Capturing colaboration diagram

5: // Verify update a configuration

: Nha quan tri : Main Form

: ConfigureEntity

: ConfigureForm: ConfigureCtrl


3: // Change configuration for node

4: // Update a configuration node

2: // Show

6: // Change configuration




- 172 -

7.1.4.2.5. Remove Configuration Capturing sequence diagram

: MainForm: Nha quan tri : C onfigureForm : Conf igureCtrl : ConfigureEntity

// C all ConfigureForm // Show

// Remov e conf iguration f or node

// Remov e a conf iguration node

// Verify remove a configuration

// Remov e configuration

7.1.4.2.6. Remove Configuration Capturing colaboration diagram

: MainForm: Nha quan tri

: ConfigureForm : Conf igureCtrl

: ConfigureEntity

2: // Show


3: // Remov e conf iguration f or node

4: // Remove a conf iguration node

5: // Verify remove a conf iguration

6: // Remov e configuration




- 173 -

77..11..44..33.. UUssee ccaassee ““CCaappttuurree””

7.1.4.3.1. Capture - Start Basic Flow sequence diagram

: Display

Thread: Nha quan tri : M ainForm : CaptureCtrl

: StartCapture

Thread

// Start capture // Call capture

// Create thread Start

// Show packet

// Create thread Display

// send content o f packet

7.1.4.3.2. Capture – Start Basic Flow colaboration diagram

: CaptureCtrl

: Nha quan tri : Mai nForm

: Sta rtCapture

Thread

: Display

Thread

1: // Sta rt capture

2: // Call capture

6: // Show packet

3: // Create thread Start

4: // Create thread Displ ay

5: // send content o f packet




- 174 -

7.1.4.3.3. Capture - Start Error Flow sequence diagram

: StartCapture

Thread: Nha quan tri : MainForm : CaptureCtrl : MessageBox

// Start capture // Call capture

// C reate thread Start

// Notify result

// Show error message

7.1.4.3.4. Capture – Start Error Flow colaboration diagram

: Nha quan tri : MainForm

: CaptureCtrl

: StartCapture

Thread

: MessageBox

1: // Start capture

2: // Call capture

3: // Create thread Start

4: // Noti fy result

5: // Show error message




- 175 -

7.1.4.3.5. Capture - Start Stop Flow sequence diagram

: Nha quan tri : Mai nForm : CaptureCtrl: StartCapture

Thread: MessageBox

// Stop capture // Call stop

// Create th read Stop

// Message back

// Show message

7.1.4.3.6. Capture – Start Stop Flow colaboration diagram


: StartCapture

Thread : M essageBo x

: CaptureCtrl

1: // Stop capture

2: // Call stop

3: // Create thread Stop

4: // M essage b ack

5: // Show me ssage




- 176 -

7.1.4.3.7. Capture – Start Error Flow sequence diagram

: MessageBox: StartCapture

Thread: Nha quan tri : Mai nForm : CaptureCtrl

// Stop capture // Call stop

// Create thread Stop

// Message back

// Show message Error

7.1.4.3.8. Capture – Start Error Flow colaboration diagram


: CaptureCtrl: MessageBox

: StartCaptureThread

1: // Stop capture

2: // Cal l stop

3: // Create thread Stop

4: // Message back

5: // Show message Error




- 177 -

77..11..44..44.. UUssee ccaassee ““QQuueerryy””

7.1.4.4.1. Query - Basic Flow sequence diagram

: Nha quan tri : MainForm : Fil terCtrl: Fil terThread

// Call Filter // Submit Filter // Create Filter Thread

// Content o f packet return

// Show content of message

7.1.4.4.2. Query - Basic Flow colaboration diagram


: FilterCtrl

: FilterThread

1: // Call Filter

2: // Submit Filter

5: // Sho w content of m essage

3: // Create Filter Thread

4: // Content of packet return




- 178 -

7.1.4.4.3. Query - Error Flow sequence diagram

: F ilterThread: Nha quan tri : MainForm : F ilterCtrl : MessageBox

// Call Filter // Submit Filter

// Create Filter Thread

// Error return

// Show message error

7.1.4.4.4. Query - Error Flow sequence diagram


: Fil terThread

: MessageBox

: Fil terCtrl

1: // Call Filter

2: // Submit Filter

3: // Create Filter Thread

4: // Error return

5: // Show message error




- 179 -

77..22.. TThhiiếếtt kkếế

77..22..11.. SSơ ơ đđồồ ccáácc đđốốii ttư ư ợ ợ nngg ccààii đđặặtt

Vì khi cài đặt phải k ết hợ p vớ i mã nguồn của Ethereal (viết theo ngôn ngữ C) và

sử dụng các thư viện không hướ ng đối tượ ng nên chỉ có thể phát triển theo hướ ng

đối tượ ng một số xử lý liên quan đến Globus.

1. Sơ đồ các lớ p đối tượ ng module GridManager

GL_GRAM_JOBS_CALLBACK

JobsTableMutex : glo bus_mutex_t

JobTable : map <string,GL_GRAM_JOB>

callback_contact : char *

Add(... : string, .... : GL_GRAM_JOB *) : void

Remove(... : char*) : void

GetURL() : char *

GetJob(... : char *) : GL_GRAM_JOB *

Lock()

UnLock()

GL_CB

mutex : gl obus_mutex_t

cond : glo bus_cond_t

done : globus_bool_t

IsDone()

SetDone()

Continue()

Wait()

GL_GLOBUS_FTP_CLIENT

fd : FILE *

buffer : gl obus_byte_t

handle : globus_ftp_client_handle_t

StartTransfer()

Transfer()

Host

hostName : string

cpu : long

GetHostName() : string

GetCPU() : Long

GL_GRAM_JOB

failed : globus_bool_t

jobcontact : char *

callback : GL_GRAM_JOBS_CALLBACK

HasFailed() : globus_bool_t

SetFailed()

Submit(... : ...)

Cancel()

SetJobContact(... : ...)

Wait()

1

name

1

name

11

Broker

GetLinuxNodes()

Hình 7-3 Sơ đồ lớ p cài đặt lớ p đối tượ ng.




- 180 -

2. Danh sách các lớ p đối tượ ng

STT Tên lớ pLoại đốitượ ng

Diễn giải

1. GL_CB Control Lớ p cung cấ p các hàm gọicho việc bắt đầu, chờ đợ ivà k ết thúc của một côngviệc

2. GL_GRAM_JOBS_CALLBACK

Control Lớ p quản lý việc gọi thựchiện một danh sách cáccông việc thông qua địnhdanh của công việc

3. GL_GRAM_JOB Control Lớ p chịu quản lý việc thựcthi và k ết thúc một công

việc.4. GL_GLOBUS_FTP_CLIENT Control Lớ p chịu trách nhiệm quảnlý truyền dữ liệu vớ iGridFTP.

5. GL_BROKER Control Tìm kiếm thông tin về cácmáy trong hệ thống Grid

Bảng 7-3 Danh sách các đối tượ ng cài đặt.

77..22..22.. TThhiiếếtt k k ếế ggiiaaoo ddiiệệnn

77..22..22..11.. DDaannhh ssáácchh ccáácc mmàànn hh ì ìnnhh

Giao diện ứng dụng Grid NetManager thử nghiệm ngoài sử dụng lại các giao

diện của Ethereal, có thêm một số điểm mớ i sau:

STTTên màn

hìnhDiễn giải

1. GridNetManager

Sử dụng lại màn hình chính của Ethreal, thêm cácchức năng mớ i, thể hiện của các usecase Capture,Query Packet Information, Search nodes, cho phéptìm kiếm các máy tính thỏa các điều kiện yêu cầu về tài nguyên, cho phép nhậ p câu truy vấn các thông tinvề packet và xuất k ết quả ra màn hình, cho phép khở itạo và k ết thúc quá trình bắt packet. Màn hình nàycho phép sử dụng lại các chức năng phân tích củaEthereal.

2. PacketCaptureConfigure

Thể hiện usecase Configure Packet Capturing, cho phép ngườ i dùng cấu hình các thông tin phục vụ bắt packet như node thực thi, tên file lưu tr ữ, node lưu dữ liệu, capture filter.

Bảng 7-4 Danh sách các giao diện.




- 181 -

77..22..22..22.. CChhii ttiiếếtt ccáácc mmàànn hh ì ìnnhh

7.2.2.2.1. Màn hình Grid NetManager

Hình 7-4 Màn hình chính ứ ng dụng Grid NetManager thử nghiệm

Mô tả màn hình (danh sách các control đượ c thêm vào màn hình chính

cùa ethereal)

STT Tên control

Têntrêngiaodiện

Kiểu Diễn giải

1. mds_server_te MDSServer

Textbox Cho phép nhậ p vào tên của MDSServer đang quản lý thông tin củahệ thống Grid

2. filter_te Filter Textbox Chứa nội dung truy vấn cơ sở dữ liệu. Sau khi nhận đầy đủ câu truyvấn, hệ thống sẽ cho gọi thực thimodule PacketInfoProvider trên cácmáy ở xa, chờ nhận k ết quả và xuấtra màn hình.

3. node_cb Nodes Combo Chứa danh sách Node thoả điềukiện tìm kiếm hiện đang có trongGrid.

4. nodes_bt Nodes Button Thực hiện tìm kiếm các Node thỏa

điều kiện yêu cầu về tài nguyên từ MDS server và đưa ra cboNodes




- 182 -

5. Start_bt Start Button Bắt đầu quá trình bắt packet trên cácnode.

6. stop_bt Stop Button K ết thúc quá trình bắt packet.

Bảng 7-5 Mô tả màn hình chính.

7.2.2.2.2. Màn hình Packet Capture Configure

Hình 7-5 Màn hình Packet Capture Configue

Mô tả màn hình (danh sách các control)

STT Tên control

Tên trên

giaodiện

Kiểu Diễn giải

1. clist_Node Listbox Hiện thị các chọn lựa cấu hình bắt packet của ngườ i dùng.

2. file_te File Textbox Chứa tên file lưu tr ữ dữ liệu khi bắtxuống.

3. filter_te Argument Textbox Chứa nội dung cấu hình bắt packetcủa từng module Sensor.

4. computer_cb Sensor Combo Chứa danh sách Node thoả điều kiệntìm kiếm tài nguyên, hiện đang cótrong Grid, dùng để chọn máy thực




- 183 -

thi module Sensor.5. store_cb Database

Computer Combo Chứa danh sách Node thoả điều kiện

tìm kiếm tài nguyên, hiện đang cótrong Grid, dùng để chọn máy lưutr ữ dữ liệu.

6. btnOK OK Button Lưu lại cấu hình các module.7. btnAdd Add Button Thêm cấu hình cho một module mớ i8. btnUpdate Update Button Cậ p nhật lại cấu hình của một

module.9. btnRemove Remove Button Loại bỏ một cấu hình module.

Bảng 7-6 Mô tả màn hình cấu hình bắt packet.

77..33.. CCààii đđặặtt && TTr r iiểểnn kkhhaaii

77..33..11.. CCôônngg ccụụ vvàà mmôôii ttrrư ư ờ ờ nngg pphháátt ttrriiểểnn ứ ứ nngg ddụụnngg

Ứ ng dụng “Grid NetManager” đượ c xây dựng trên môi tr ườ ng và công cụ sau:

+ Công cụ phân tích thiết k ế : Rational Rose 2000, Microsoft Visio 2003.

+ Môi tr ườ ng xây dựng và thực thi : Linux Redhat 9.0 (kernel 2.4.20-8).

+ Ngôn ngữ lậ p trình : C/C++

+ Môi tr ườ ng phát triển ứng dụng :

Editor : KDevelop 2.1.

Compiler : GCC, G++

Debugger : GDB.

+ Môi tr ườ ng Grid : Globus Toolkit 3.2. và các phần mềm đi kèm.

+ Sử dụng mã nguồn Ethereal 0.10.0a

+ Sử dụng các thư viện:

Thư viện giao diện đồ họa : GTK+ 1.2

Các thư viện phát triển ứng dụng của GT3.2 : GSI, pre-WS GRAM, pre-

WS MDS, GridFTP, …




- 184 -

77..33..22.. MMôô hh ì ìnnhh ccààii đđặặtt

1. Mô hình

TETHEREAL

(File chuong trinh thuc thi)

Grid NetManager

(Module Quan tri)

Hình 7-6 Mô hình cài đặt.

2. Diễn giải

STT Tên thành phần Ý ngh ĩ a

1. tEthereal Là file chươ ng trình tethereal, chươ ng trình tetherealđượ c sử dụng thực thi chức năng của 2 module

Sensor và module PacketInfoProvider.

2. GridNetManager

Là file chươ ng trình thực thi chức năng quản tr ị và

trình diễn.

Bảng 7-7 Các thành phần triển khai.

77..33..33.. MMôô hh ì ìnnhh ttrriiểểnn k k hhaaii

Hệ thống có thể đượ c triển khai trong hệ thống mạng máy tính cần quản tr ị vớ i

cấu hình như sau:

Hình 7-7 Sơ đồ triển khai ứ ng dụngGrid NetManager thử nghiệm.




- 185 -

Giải thích:

Các máy tính tham gia Grid đều đượ c cài đặt bộ Globus Toolkit 3.2, các máy

tính này không cần phải dành riêng cho Grid mà có thể sử dụng cho các ứng dụng

khác. Ứ ng dụng sẽ tự động hoặc cho nhà quản tr ị chọn các máy tính “r ảnh r ỗi”(theo

một tiêu chí nào đó) để thực thi các module. Nên có một mạng cục bộ dành riêng

cho Grid (Grid Network) để không ảnh hưở ng đến năng lực mạng của tổ chức. Các

máy tính Grid ngoài việc k ết nối vớ i mạng nội bộ của tổ chức, có thêm một k ết nối

đến mạng Grid dành riêng. Các máy tính chạy module Sensor nhất thiết phải k ết nối

vớ i một LAN segment cần bắt packet, một LAN segment chỉ cần một máy chạy

module Sensor là đủ. Nhà quản tr ị sử dụng một máy tính Grid chạy gói Quản tr ị (gồm module Presentation và PacketInfoManager) để quản tr ị toàn hệ thống.

77..33..44.. TThhử ử nngghhiiệệmm

77..33..44..11.. MMôô hh ì ìnnhh tthhử ử nngghhiiệệmm

Hình 7-8 Mô hình cài đặt thử nghiệm

Các máy tính thử nghiệm đượ c triển khai như hình 7-8. Đã thử nghiệm thànhcông chức năng gửi và thực thi công việc trên máy tính ở xa, chức năng bắt packet,xử lý truy vấn.



Chươ ng 8. K ết luận

- 186 -

CChhưươơnngg 88.. KKếếtt lluuậậnn

88..11.. ĐĐáánnhh ggiiáá

88..11..11.. VVềề lluuậậnn vvăănn

Ở mức luận văn, nhóm thực hiện đã thu đượ c những k ết quả sau :

+ Tìm hiểu khá chi tiết, tổng quan về các khía cạnh nền tảng công nghệ Grid

Computing hiện nay như bản chất khái niệm, các thách thức và yêu cầu, lợ i ích và

ứng dụng, mô hình kiến trúc, các chuẩn hiện nay, tìm hiểu và so sánh cácmiddleware Grid phổ biến hiện nay.

+ Tìm hiểu khá đầy đủ, tổng quan về bộ Globus Toolkit 3.2 về mô hình,

cách thức giải quyết các thách thức cơ bản của công nghệ Grid, các dịch vụ cơ bản,

các yêu cầu, lưu ý khi xây dựng các dự án ứng dụng Grid vớ i bộ Globus Toolkit.

+ Bên cạnh đó, các vấn đề cơ bản về quản tr ị mạng, hệ thống quản tr ị mạng,

hệ thống Intrusion Detection System, cũng đã đượ c tìm hiểu, làm cơ sở để đưa ra

mô hình ứng dụng Grid NetManager.

Các kiến thức ở đây có thể đượ c sử dụng để định hướ ng tìm hiểu, nghiên cứu

sâu hơ n về công nghệ Grid Computing và bộ Globus Toolkit, cũng như sử dụng để

phát triển ứng dụng Grid. Hướ ng tiế p cận sử dụng công nghệ Grid Computing vào

bài toán quản tr ị mạng là một hướ ng mớ i, hiện chưa có dự án nào đượ c công bố.

88..11..22.. VVềề ứ ứ nngg ddụụnngg

Dựa trên những k ết quả nghiên cứu, tìm hiểu từ công nghệ Grid Computing và

các hệ thống quản tr ị mạng, nhóm thực hiện đã đạt đượ c những k ết quả sau :

+ Đề xuất mô hình hệ thống quản tr ị mạng dựa trên nền công nghệ Grid

Computing, đưa ra định hướ ng xây dựng ứng dụng.

+ Đọc hiểu và sửa chữa mã nguồn phần phần mềm Ethereal cho phù hợ p vớ i

các tính năng mớ i.

+ Cài đặt và cấu hình thành công bộ Globus Toolkit 3.2 trên môi tr ườ ngmạng máy tính Linux, cho phép thực thi các ứng dụng Grid.




- 187 -

+ Thiết k ế và cài đặt các chức năng tìm kiếm máy tính trong Grid, gửi và

thực thi các module bắt packet (Sensor), xử lý truy vấn trên các node

(PacketInfoProvider), lấy thông tin từ các file dữ liệu.

Việc cài đặt thử nghiệm một số chức năng cho thấy tính khả thi của mô hình và

khả năng cài đặt thành công của ứng dụng trong môi tr ườ ng Grid vớ i middleware

Globus Toolkit.

Ứ ng dụng Grid NetManager là một dự án lớ n, đòi hỏi đầu tư nhiều về công sức

và thờ i gian. Trong quá trình làm luận văn, do phải dành thờ i gian tìm hiểu công

nghệ và làm quen vớ i các môi tr ườ ng mớ i (hệ điều hành Linux, công cụ phát triển

ứng dụng,…) nên những k ết quả trên đây mớ i chỉ là bướ c đầu, việc phát triển ứngdụng đòi hỏi có những nghiên cứu, phân tích, thiết k ế, cài đặt k ỹ lưỡ ng hơ n trong

các giai đoạn sau.

88..22.. HHưướớnngg pphháátt ttr r iiểểnn,, mmởở r r ộộnngg ccủủaa lluuậậnn vvăănn

88..22..11.. VVềề lluuậậnn vvăănn

Thực hiện các nghiên cứu sâu hơ n về công nghệ Grid Computing và bộ GlobusToolkit, về mã nguồn các module, các thuật toán để ứng dụng tốt hơ n trong

thực tế, từ đó có thể phát triển, xây dựng các thành phần Grid hoặc tham gia các dự

án nghiên cứu và triển khai ứng dụng Grid, tiến tớ i làm chủ công nghệ Grid

Computing, đưa sức mạnh tính toán lớ n vớ i chi phí thấ p vào các dự án nghiên cứu

khoa học, kinh tế, thươ ng mại của đất nướ c, thực hiện theo chủ tr ươ ng “đi tắt đón

đầu”, góp phần phát triển nền khoa học công nghệ nướ c nhà.

88..22..22.. VVềề ứ ứ nngg ddụụnngg

Hiện tại ứng dụng mớ i chỉ dừng lại ở mức thử nghiệm, trong tươ ng lai dự định

sẽ phát triển tiế p thành một ứng dụng hoàn chỉnh để có thể áp dụng vào thực tế:

+ Phát triển các chức năng còn thiếu của các module hiện tại.

+ Thiết k ế, cài đặt các module còn lại trong mô hình ứng dụng.

+ Phát triển các chức năng quản lý dữ liệu, quản lý Grid để nâng cao hiệu suấtGrid.




- 188 -

+ Cài đặt ứng dụng theo mô hình Grid Service để tận dụng các khả năng của

công nghệ mớ i.

88..33.. LLờờii kkếếtt Trong thờ i gian có hạn, chúng em mớ i chỉ nghiên cứu đượ c một phần nhỏ về

công nghệ Grid Computing, một l ĩ nh vực mớ i mẻ và đượ c xem là công nghệ tính

toán nền tảng trong tươ ng lai. Có thể những kiến thức chúng em thu nhận đượ c từ

công nghệ chưa nhiều nhưng trong thờ i gian làm luận văn, nhờ những k ỹ năng và

kiến thức chúng em thu nhận, rèn luyện đượ c qua quá trình học tậ p ở tr ườ ng Đại

học, chúng em đã phát triển đượ c nhiều k ỹ năng mớ i như : k ỹ năng tìm kiếm thôngtin, k ỹ năng phân tích và xử lý vấn đề (trouble shooting), tinh thần vượ t qua khó

khăn, khả năng phối hợ p làm việc, khả năng thích nghi vớ i môi tr ườ ng và công

nghệ hoàn toàn mớ i (Linux và công nghệ Grid Computing) trong thờ i gian ngắn,…,

tạo điều kiện để có những phát triển trong sắ p tớ i. Chúng em ngh ĩ những gì đã đạt

đượ c r ất quý cho chúng em sau này và tin r ằng việc trang bị những k ỹ năng thực tế

cũng là một mục đích quan tr ọng của việc làm luận văn. Chúng em r ất vui và hạnh

phúc khi đã đượ c thực hiện luận văn này. Xét về các mục tiêu đặt ra ban đầu, các

k ết quả đạt đượ c cùng vớ i những nỗ lực, cố gắng trong thờ i gian làm luận văn,

chúng em xin tự đánh giá hoàn thành khá xuất sắc luận văn.



Phụ lục

- 189 -

PPhhụụ llụụcc

AA.. CCáácc ttiiêêuu cchhíí đđáánnhh ggiiáá ttíínnhh kkhhảả kkhhii ccủủaa mmộộtt ddựự áánn

GGr r iidd

Lượ c đồ đánh giá tính khả khi của ứng dụng đượ c trình bày trong hình 0-1. Nóđưa ra các tiêu chí và các yêu cầu cần thiết của một giải pháp Grid, qua quá trìnhlượ ng giá các tiêu chí sẽ cho biết tính khả thi của ứng dụng có cao hay không.

Ứ ng vớ i mỗi tiêu chí có các cột sau:+ Tầm vự c : Tổng k ết các khả năng có thể của tiêu chí.

+ Độ quan trọng : Tr ọng số cho biết mức độ quan tr ọng của tiêu chí khi sosánh vớ i các yêu cầu của ứng dụng.+ Nỗ lự c : Tr ọng số cho biết mức độ nỗ lực cần thiết để đạt đượ c tiêu chí đó.+ K ỹ năng : Tr ọng số cho biết trình độ hiện tại của đội ngũ phát triển.+ Tài nguyên : Tr ọng số cho biết khả năng và các kiểu của tài nguyên Grid.+ Các ghi chú :

Mỗi tiêu chí cần đượ c đánh giá và cho điểm tươ ng ứng theo một độ đo nào đó.Ở đây đề nghị độ đo vớ i các giá tr ị H (cao), M(vừa), L (thấ p), cũng có thể sử dụngcác độ đo khác. Lưu ý, có thể thêm các tiêu chí khác vào bảng để đánh giá cho phù

hợ p vớ i tình hình thực tế.

Tiêu chí Trọng số (H-M-L)STT

MụcTầm vự c (tăng dần

theo nỗ lự c)

Độ quantrọng

Nỗ lự c

K ỹ năng

Tàinguyên

Ghichú

1. Luồng côngviệc

Song song -> Mạng ->Tuần tự

2. Số côngviệc khác

nhau

Một công việc -> nhiềucông việc.

3. Độ sâu củacác côngviệc con.

Không có công việccon -> R ất sâu

4.Kiểu côngviệc

Theo lô -> Đơ n giản ->Song song -> Dựa trênEJB -> Phức tạ p

5. Mứ c độ phụ thuộcHệ điềuhành

Độc lậ p -> Phụ thuộcchặt chẽ.

6. Dung lượ ngbộ nhớ cho

Nhỏ -> Lớ n





Phụ lục

- 191 -

BB.. ĐĐịịnnhh ddạạnngg f f iillee GGWWSSDDLL

Phần này giớ i thiệu các bướ c cơ bản để viết một tài liệu GWSDL đặc tả Grid

Service, việc viết một đặc tả GWSDL cũng tươ ng tự như viết một tài liệu WSDLkhi phát triển các Web service, gồm các bướ c:1. Viết thành phần gốc : <definitions>.2. Viết đặc tả <gwsdl:PortType>.3. Viết các đặc tả <message> nhập xuất cho các phươ ng thứ c của

PortType.4. Viết thành phần <types>.

Chi tiết các bướ c sẽ đượ c trình bày dướ i đây thông qua một ví dụ nhỏ, viết Gridservice MathService vớ i các chức năng đã đượ c giớ i thiệu ở phần Triển khai cài đặt

các Grid Service Bướ c 1: Viết thành phần gốc <definitions>

<?xml version="1.0" encoding="UTF-8"?>

<definitions name="MathService"targetNamespace="http://www.globus.org/namespaces/2004/02/progtutorial/MathService"xmlns:tns="http://www.globus.org/namespaces/2004/02/progtutorial/MathService"xmlns:ogsi="http://www.gridforum.org/namespaces/2003/03/OGSI"xmlns:gwsdl="http://www.gridforum.org/namespaces/2003/03/gridWSDLExtensions"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns="http://schemas.xmlsoap.org/wsdl/">

</definitions>

Thành phần <definitions> có 2 thuộc tính:+ name : Tên của file GWSDL, không liên quan đến tên service.+ targetNamspace : Khai báo không gian tên của file GWSDL. Điều này có

ngh ĩ a là tất cả các portType và phươ ng thức khai báo ở đây đều thuộc không giantên này.

Thành phần này cũng đượ c dùng để khai báo tất cả các không gian tên sử dụngtrong tài liệu GWSDL.

Tiế p theo, phải khai báo import file OSGI GWSDL chức các khai báo, địnhngh ĩ a sẽ sử dụng trong phần sau.

<import location="../../ogsi/ogsi.gwsdl"

namespace="http://www.gridforum.org/namespaces/2003/03/OGSI"/>

Bướ c 2 : Định ngh ĩ a portType vớ i tag <gwsdl:portType>

<definitions ... ">

<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>



Phụ lục

- 192 -

<operation name="subtract">

<input message="tns:SubtractInputMessage"/>

<output message="tns:SubtractOutputMessage"/>


</operation>

<operation name="getValue">

<input message="tns:GetValueInputMessage"/>

<output message="tns:GetValueOutputMessage"/>


</operation>

</gwsdl:portType

Tag <gwsdl:portType> có 2 thuộc tính:+ name : tên của portType+ extends : Đây là một sự khác biệt đối vớ i một file WSDL truyền thống.

Thuộc tính này cho phép chúng ta mở r ộng từ một portType có sẵn, ở đâyMathService đượ c mở r ộng từ portType GridService chuẩn.

Bên trong tag <gwsdl:portType> chứa tag <operation> cho phép định ngh ĩ a các phươ ng thức của portType các tham số đầu vào (tag <input>), các giá tr ị tr ả về (tag<output>), các giá tr ị lỗi (<fault>). Lưu ý, tất cả đều có thuộc tính <message>, đượ cđịnh ngh ĩ a dướ i đây, xác định những gì cần trao đổi trong lúc gọi phươ ng thức.

Bướ c 3 : Viết đặc tả <message> nhập xuất

<?xml version="1.0" encoding="UTF-8"?>

<definitions ... >

< message name="AddInputMessage">

< part name="parameters" element="tns:add"/> </message>

<message name="AddOutputMessage">

<part name="parameters" element="tns:addResponse"/>

</message>



</definitions>

Lưu ý, tên của message phải trùng vớ i tên đã đượ c khai báo trong phươ ng thức(trong thuộc tính message của các tag <input>, <output>).

Mỗi message gồm nhiều phần <part>, mỗi <part> có một kiểu đại diện cho kiểucủa giá tr ị, đượ c định ngh ĩ a ở bướ c sau.

Bướ c 4 : Viết các thành phần <type>

types>

<xsd:schema

targetNamespace="http://www.globus.org/namespaces/2004/02/progtutorial/MathService"

attributeFormDefault="qualified"

elementFormDefault="qualified"

xmlns="http://www.w3.org/2001/XMLSchema">

<xsd:element name="add"><xsd:complexType>



Phụ lục

- 193 -

<xsd:sequence><xsd:element name="value" type="xsd:int"/>

</xsd:sequence></xsd:complexType>

</xsd:element>

<xsd:element name="addResponse"><xsd:complexType/>

</xsd:element>

</xsd:schema>

</types>

&lt!-- Messages -->

&lt!-- PortType -->

</definitions>

Ở đây định ngh ĩ a các kiểu của các thành phần add và addResponse.

Trên đây vừa trình bày sơ nét về cấu trúc cơ bản của file GWSDL, có thể thêmcác kiểu mớ i, mở r ộng bằng cách tham khảo các không gian tên đã đượ c định ngh ĩ asẵn.

CC.. KKỹỹ tthhuuậậtt ccààii đđặặtt ccáácc cchhứứcc nnăănngg ccơơ bbảảnn ccủủaa GGr r iidd

SSeer r vviiccee

CC..11.. K K ỹỹ tthhuuậậtt ccààii đđặặtt OOppeerraattiioonn PPrroovviiddeerr Như đã giớ i thiệu, GT3 hỗ tr ợ 2 cách cài đặt interface trong ngôn ngữ lậ p trình,

cách thứ nhất là k ỹ thuật sử dụng tính k ế thừa, ở đây lớ p MathImpl k ế thừa từ lớ pGridServiceImpl, do GridServiceImpl có tất cả các chức năng cơ bản nên MathImplchỉ cần cài đặt tất cả các phươ ng thức của Math portType là đủ. Như trên hình 0-1,lớ p MathImpl chứa tất cả các hàm cài đặt cho các phươ ng thức của portType (Lưuý, ở đây có nhiều hàm hơ n). Tuy nhiên, cài đặt tất cả các phươ ng thức của portTypechỉ trong một lớ p có thể gây ra nhiều bất tiện đặc biệt là đối vớ i các portType lớ n,có nhiều phươ ng thức. Và k ỹ thuật này, đối vớ i Java, lớ p MathImpl không thể k ế

thừa từ một lớ p nào nữa, điều này hạn chế việc tái sử dụng mã.



Phụ lục

- 194 -

Hình 8-1 Lớ p triển khai interface của Grid service bằng k ỹ thuật k ế thừ a. GT3 đưa một hướ ng tiế p cận mớ i để giải quyết khuyết điểm của k ỹ thuật sử

dụng tính k ế thừa, đó là k ỹ thuật uỷ quyền. Hướ ng tiế p cận này cho phép phân táncác nhóm phươ ng thức vào các lớ p khác nhau, các lớ p này đượ c gọi là OperationProvider. Như trên hình 0-2, có thể chia lớ p MathImpl thành 3 lớ p, ứng vớ i từngnhóm phươ ng thức.

Hình 8-2 Cài đặt intrface củaGrid service bằng k ỹ thuật Operation Provider Lưu ý là 3 lớ p này không thừa k ế từ lớ p nào hết, chúng chỉ cài đặt một interface

tên là Operation Provider. Lúc này các chức năng của lớ p GridServiceImpl khôngđượ c k ế thừa từ đây mà đượ c yêu cầu Grid service container cung cấ p thông qua

bản đặc tả triển khai. Khi tiến hành cài đặt theo cách tiế p cận này, có một số thayđổi nhỏ so vớ i k ỹ thuật sử dụng tính k ế thừa, như trình bày dướ i đây.

Lớ p cung cấ p hoạt động (Operation Provider) ở đây gọi là MathProvider cũnggiống như các lớ p của MathImpl tr ướ c đây, chỉ khác là ở đây cài đặt thêm interfaceOperationProvider, file :$GRIDSER_DEMO/org/globus/progtutorial/services/core/providers/impl

/MathProvider.java



Phụ lục

- 195 -

package org.globus.progtutorial.services.core.providers.impl;

import org.globus.ogsa.GridServiceBase;

import org.globus.ogsa.GridServiceException;

import org.globus.ogsa.OperationProvider;import java.rmi.RemoteException;

import javax.xml.namespace.QName;//Luu y o day cai dat OperationProvider

public class MathProvider implements OperationProvider

{

// Cac thuoc tinh cua Operation provider

//Khai bao namespace

private static final String namespace ="http://www.globus.org/namespaces/2004/02/progtutorial/MathService";

//Khai bao ten cac phuong thuc duoc cung cap, tuong ung voi file GWSDL

private static final QName[] operations =new QName[]{ new QName(namespace, "add"),

new QName(namespace, "subtract"),new QName(namespace, "getValue") };

private GridServiceBase base;

// Cac phuong thuc cua Operation Provider

public void initialize(GridServiceBase base) throws GridServiceException {this.base = base;

} public QName[] getOperations() {

return operations;}

//Cai dat

private int value = 0;

public void add(int a) throws RemoteException{

value = value + a;

}

//-------- tuong tu MathImpl----------

}

File đặc tả triển khai cũng có một số thay đổi, file : $GRIDSER_DEMO/org/globus/progtutorial/services/core/providers/serv

er-deploy.wsdd

<?xml version="1.0"?><deployment



<parameter name="schemaPath"




<parameter name="className"value="org.globus.progtutorial.stubs.MathService.MathPortType"/>



<parameter name="baseClassName"value="org.globus.ogsa.impl.ogsi.GridServiceImpl"/>



Phụ lục

- 196 -

<parameter name="operationProviders"value="org.globus.progtutorial.services.core.providers.impl.Math

Provider"/>

<!—Tuong tu tren -->

</deployment>

Các thao tác khác để triển khai service hoàn toàn tươ ng tự như đã giớ i thiệu ở trên.

CC..22.. TThhêêmm tthhàànnhh pphhầầnn ddữ ữ lliiệệuu ((SSeerrvviiccee DDaattaa EElleemmeenntt ((SSDDEE))))

Như đã biết, mỗi Grid service đều có các SDE của riêng mình, phần này sẽ xemxét k ỹ thuật thêm SDE cho một service. Ở đây chúng ta thêm một SDE có tên làMathData chứa các thông tin như giá tr ị hiện tại (value), phép toán thực hiện cuốicùng (lastOp), số phép toán đã thực hiện (numOp), MathData chỉ có một và chỉ mộtgiá tr ị (cardinality = 1..1) đượ c mô tả trên hình 0-3:

Hình 8-3 Ví dụ về SDE của MathService

+ Đặc tả SDE Việc định ngh ĩ a một SDE cho một service thông qua file đặc tả GWSDL, tuy

nhiên MathData là một kiểu phức tạ p nên mặc dù có thể đặc tả kiểu này trong file

GWSDL, chúng ta có thể đặc tả trong một file khác. File :$GRIDSER_DEMO/schema/progtutorial/MathService_sd/MathSDE.xsd

<complexType name="MathDataType"><sequence>

<element name="value" type="int"/><element name="lastOp" type="string"/><element name="numOps" type="int"/>

</sequence>

</complexType>



Phụ lục

- 197 -

Bây giờ , chúng ta sẽ đặc tả lại inteface của service bằng cách tạo một fileGWSDL mớ i, file này có nội dung và cấu trúc gần giống vớ i file GWSDL cũ, mộtsố phần thay đổi đượ c trình bày ở đây. File :$GRIDSER_DEMO/schema/progtutorial/MathService_sd/Math.gwsdl.

+ Xác định lại namespace, <definitions name="MathService"

targetNamespace="http://www.globus.org/namespaces/2004/02/progtutorial/MathService_sd"

xmlns:tns="http://www.globus.org/namespaces/2004/02/progtutorial/MathService_sd"

xmlns:data="http://www.globus.org/namespaces/2004/02/progtutorial/MathService_sd/MathSDE"

xmlns:ogsi="http://www.gridforum.org/namespaces/2003/03/OGSI"

xmlns:gwsdl="http://www.gridforum.org/namespaces/2003/03/gridWSDLExtensions"

xmlns:sd="http://www.gridforum.org/namespaces/2003/03/serviceData"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns="http://schemas.xmlsoap.org/wsdl/">

+ Nhập file MathSDE.xsd định ngh ĩ a MathData vào <import location="MathSDE.xsd"

namespace="http://www.globus.org/namespaces/2004/02/progtutorial/MathService_sd/ MathSDE"

/>

+ Khai báo SDE trong đặc tả interface

<gwsdl:portType name="MathPortType" extends="ogsi:GridService">



<sd:serviceData name="MathData"type="data:MathDataType" minOccurs="1" maxOccurs="1" mutability="mutable" modifiable="false"nillable="false">

</sd:serviceData>

</gwsdl:portType>

+ Cài đặt SDE File :

$GRIDSER_DEMO/org/globus/progtutorial/services/core/servicedata/im

pl/MathImpl.java

Ở đây khai báo lớ p không thay đổi: public class MathImpl extends GridServiceImpl implements MathPortType

Lớ p cài đặt này có thêm 2 thuộc tính private mớ i :private ServiceData mathDataSDE; //La SDE

private MathDataType mathDataValue; //Chua gia tri cua SDE



Phụ lục

- 198 -

Việc tạo lậ p các SDE nằm trong hàm postCreate, ở đây chúng ta có thể để các giá tr ị khở i tạo cho SDE.

public void postCreate(GridContext context) throws

GridServiceException

{// Goi ham postCreate lop co so

super.postCreate(context);

//Duoi day la cac buoc tao mot SDE va dua vao Service Data Set// Tao Service Data Element

mathDataSDE = this.getServiceDataSet().create("MathData");

// Tao mot doi tuong MathDataType va khoi tao cac gia tri

mathDataValue = new MathDataType(); mathDataValue.setLastOp("NONE"); mathDataValue.setNumOps(0); mathDataValue.setValue(0);

// Dua cac gia tri vao doi tuong MathDataType

mathDataSDE.setValue(mathDataValue);

// Them SDE vao Service Data Set

this.getServiceDataSet().add(mathDataSDE);

}

Các hàm add(), substract() có thêm các lệnh mớ i để cậ p nhật lại SDE:


{//Cac ham setLastOp(),setValue(),setNumOps(), getNumOps() duoc tu

//dong phat sinh tu file dac ta MathSDE.xsd

mathDataValue.setLastOp("Addition");

incrementOps();

mathDataValue.setValue(mathDataValue.getValue() + a);

}

// Ham nay cap nhat MathData SDE tang so phep toan len 1

private void incrementOps()

{

int numOps = mathDataValue.getNumOps();

mathDataValue.setNumOps(numOps + 1);}

+ Đặc tả cài đặt Trong file đặc tả chỉ cần thay đổi lại các giá tr ị tươ ng ứng tên các file mớ i

vừa tạo ra.<parameter name="baseClassName"

value="org.globus.progtutorial.services.core.servicedata.impl.MathImpl"/>

<parameter name="className"value="org.globus.progtutorial.stubs.MathService_sd.MathPortType

"/>



Phụ lục

- 199 -

<parameter name="schemaPath"value="schema/progtutorial/MathService_sd/Math_service.wsdl"/>

+ Client truy xuất SDE //Khai bao import giong nhu tren

//-----------------------------

public class Client

{

public static void main(String[] args)

{

try

{

// Lay tham so dong lenh



// Lay GSR cua Math PortType

MathServiceGridLocator mathServiceLocator = newMathServiceGridLocator();

MathPortType math = mathServiceLocator.getMathServicePort(GSH);

// Lay SDE "MathData", su dung phuong thuc findServiceData cuaGridServiceImpl

ExtensibilityType extensibility = math.findServiceData(QueryHelper.getNamesQuery("MathData"));

ServiceDataValuesType serviceData = AnyHelper.getAsServiceDataValues(extensibility);

MathDataType mathData =(MathDataType) AnyHelper.getAsSingleObject(serviceData,

MathDataType.class);

// Xuat cac gia tri cua SDE ra man hinh System.out.println("Value: " + mathData.getValue());System.out.println("Previous operation: " + mathData.getLastOp());System.out.println("# of operations: " + mathData.getNumOps());

// Goi phuong thuc cua service.

math.add(a);

}catch(Exception e)

{

System.out.println("ERROR!");

e.printStackTrace();

}

}}

CC..33.. CCààii đđặặtt ccơ ơ cchhếế NNoottiif f iiccaattiioonn

Như đã biết, cơ chế Notification cho phép client biết đượ c những gì đang xảy raở một Grid service instance. Cơ chế Notification liên quan mật thiết đến các SDEcủa service. Trong GT3, cơ chế Notification hoạt động theo sơ đồ sau vớ i các bướ c:



Phụ lục

- 200 -

Hình 8-4 Sơ đồ hoạt động của cơ chế Notification trong GT3. 1. addListener : Các client yêu cầu service thông báo cho mình khi có sự

thay đổi của SDE xác định trong lờ i gọi.

2. notifyChange : Khi có sự thay đổi, MathService sẽ yêu cầu SDE tươ ngứng gửi thông báo cho các client đã yêu cầu.

3. deliverNotification : SDE thông báo cho client. Ở đây các giá tr ị của SDEđượ c gửi về cho client, do đó client không cần thực hiện thêm bất cứ truy vấn nàonữa.

Có thể thấy đây là cơ chế “push” notification, GT3 chỉ hỗ tr ợ duy nhất dạngnày. Dướ i đây, chúng ta sẽ xem xét chi tiết k ỹ thuật cài đặt notification này trongGT3 vớ i MathService.

+ Khai báo sử dụng Notification trong portType

Thêm cơ chế Notification ảnh hưở ng đến interface do chúng ta cần cung cấ pmột số phươ ng thức mớ i ra bên ngoài. Tất nhiên, chúng ta không cần cài đặt các

phươ ng thức này mà chỉ cần khai báo sử dụng lại portType NotificationSource cósẵn, portType này chứa đầy đủ các phươ ng thức liên quan đến cơ chế Notification.Do đó file GWSDL ở trên chỉ cần sửa lại như sau: File :$GRIDSER_DEMO/schema/progtutorial/MathService_sd_notif/Math.gwsdl



gwsdl:portType name="MathPortType" extends="ogsi:GridService

ogsi:NotificationSource">





</gwsdl:portType>

+ Cài đặtChúng ta chỉ cần thêm một lệnh duy nhất trong các hàm cài đặt. File :

$GRIDSER_DEMO/org/globus/progtutorial/services/core/notifications/ impl/MathImpl.java

public void add(int a) throws RemoteException{



Phụ lục

- 201 -

mathDataValue.setLastOp("Addition");

incrementOps();

mathDataValue.setValue(mathDataValue.getValue() + a);

//Yeu cau thong bao cho cac client mathDataSDE.notifyChange();

}

+ Đặc tả cài đặt Hoàn toàn giống như tr ướ c, chỉ thêm một dòng mớ i. File:

$GRIDSER_DEMO/org/globus/progtutorial/core/notifications/server-config.wsdd

<deployment<!—Khai bao tuong tu tren, dong duoi day duoc them moi -->

<parameter name="operationProviders"

value="org.globus.ogsa.impl.ogsi.NotificationSourceProvider"/> <!—-Tuong tu tren -->

</deployment>

+ Client Client ở đây phức tạ p hơ n so vớ i các ví dụ tr ướ c. Client trong Java (hay đúng

hơ n là lớ p nhận các thông báo) phải cài đặt phươ ng thức deliverNotification, phươ ng thức này sẽ đượ c Grid service gọi khi có sự thay đổi trong SDE của mình.Mã nguồn client như sau, file :$GRIDSER_DEMO/org/globus/progtutorial/clients/MathService_sd_notif /ClientListener.java

//Cac khai bao import

public class ClientListener

extends ServicePropertiesImpl implements NotificationSinkCallback {

public static void main(String[] args)

{


HandleType GSH = new HandleType(args[0]);

ClientListener clientListener = new ClientListener(GSH);

}

public ClientListener(HandleType GSH) throws Exception

{

// Bat dau dang ky va lang nghe MathService NotificationSinkManager notifManager =

NotificationSinkManager.getManager();

notifManager.startListening(NotificationSinkManager.MAIN_THREAD);

String sink = notifManager.addListener("MathData", null, GSH, this);

System.out.println("Listening...");

// Cho nguoi dung nhan phim

System.in.read();

// Ket thuc lang nghenotifManager.removeListener(sink);

notifManager.stopListening(); System.out.println("Not listening anymore!");



Phụ lục

- 202 -

}

//Khi co thay doi trong SDE,ham nay se duoc Grid service goi, se xuat ra man

// hinh cac gia tri cua SDE

public void deliverNotification(ExtensibilityType any) throws

RemoteException{try{// SDE da thay doi, lay gia tri moiServiceDataValuesType serviceData =

AnyHelper.getAsServiceDataValues(any); MathDataType mathData = (MathDataType)

AnyHelper.getAsSingleObject(serviceData, MathDataType.class);

// Xuat ra man hinh System.out.println("Current value: " + mathData.getValue());System.out.println("Previous operation: " + mathData.getLastOp());System.out.println("# of operations: " + mathData.getNumOps());

}catch(Exception exc)

{System.out.println("ERROR!");exc.printStackTrace();

}}

}

CC..77.. CCààii đđặặtt k k ỹỹ tthhuuậậtt ttạạoo sseerrvviiccee đđộộnngg ((TTrraannssiieenntt sseerrvviiccee))

Làm cho một service có khả năng đượ c tạo lậ p một cách động (chuyển servicethành transient service) là một trong những việc dễ dàng nhất trong GT3, chúng takhông cần thay đổi portType cũng như cài đặt của nó. Mọi thứ cần làm là sửa lạifile đặc tả cài đặt.

+ Đặc tả cài đặt Để có thể thấy rõ hơ n về sự thay đổi, chúng ta xem lại file WSDD cũ:





<service

name="progtutorial/core/first/MathService" provider="Handler"style="wrapped">

<parameter name="name" value="MathService"/>

<parameter name="baseClassName"value="org.globus.progtutorial.services.core.first.impl.MathImpl"/>

<parameter name="className"value="org.globus.progtutorial.stubs.MathService.MathPortType"/>

<parameter name="schemaPath"value="schema/progtutorial/MathService/Math_service.wsdl"/>

<!—Cac tham so chung -->

<parameter name="allowedMethods" value="*"/>


<parameter name="handlerClass"value="org.globus.ogsa.handlers.RPCURIProvider"/>



Phụ lục

- 203 -

</service>

</deployment>

Dướ i đây là file WSDD đã sửa đổi theo mô hình tạo service động vớ i mộtfactory. Lưu ý, chúng ta sẽ khai báo một service factory t ĩ nh (persistent service) để chịu trách nhiệm tạo ra các MathService instance động (transient service). File :$GRIDSER_DEMO/org/globus/progtutorial/services/core/first/server-deploy.wsdd





<service name="progtutorial/core/first/MathFactoryService"

provider="Handler"

style="wrapped">

<parameter name="name" value="MathService Factory"/>

<parameter name="instance-name" value="MathService Instance"/><parameter name="instance-schemaPath"


<parameter name="instance-baseClassName"

value="org.globus.progtutorial.services.core.first.impl.MathImpl"/>

<parameter name="instance-className"

value="org.globus.progtutorial.stubs.MathService.MathPortType"/>

<!—Cac tham so chung --><parameter name="allowedMethods" value="*"/>


<parameter name="handlerClass"

value="org.globus.ogsa.handlers.RPCURIProvider"/>

<parameter name="className"value="org.gridforum.ogsi.Factory"/>

<parameter name="baseClassName"value="org.globus.ogsa.impl.ogsi.GridServiceImpl"/>

<parameter name="schemaPath"value="schema/ogsi/ogsi_factory_service.wsdl"/>

<parameter name="operationProviders"value="org.globus.ogsa.impl.ogsi.FactoryProvider"/>

<parameter name="factoryCallback"

value="org.globus.ogsa.impl.ogsi.DynamicFactoryCallbackImpl"/>

</service>

</deployment>

Một chút khác biệt giữa 2 bản đặc đặc tả:+ Tr ướ c hết, chúng ta đã thêm tiền tố “instance-” vào name, schemaPath,

baseClassName, và className, bằng cách này, chúng ta cho container biết đâylà những tham số để truyền vào khi tạo các instance MathService thông qua

Factory.



Phụ lục

- 204 -

+ Sau đó chúng ta thêm các tham số mớ i vào “khối tham số chung”, để ýlúc này, schemaPath, baseClassName, và className tham khảo đến mã thực thicủa Factory (cung cấ p bở i GT3), không phải bất cứ mã thực thi nào do chúng tatạo ra.

+ Có thể thấy, việc thêm khả năng tạo lậ p động cho bất k ỳ service nào,đơ n giản chỉ gồm 2 bướ c, thêm các tiền tố “instance-” và sửa lại “khối tham số chung”

+ Đối vớ i client Có thể sử dụng lại các client cũ. Ở đây, chúng ta viết một client để demo khả

năng tạo lậ p, sử dụng và huỷ một service instance thông qua Factory.File :$GRIDSER_DEMO/org/globus/progtutorial/clients/MathService/FactoryC lient.java

package org.globus.progtutorial.clients.MathService;

import org.gridforum.ogsi.OGSIServiceGridLocator;

import org.gridforum.ogsi.Factory;

import org.gridforum.ogsi.LocatorType;

import org.globus.ogsa.utils.GridServiceFactory;

import

org.globus.progtutorial.stubs.MathService.service.MathServiceGridLocator;

import org.globus.progtutorial.stubs.MathService.MathPortType;

import java.net.URL;

public class FactoryClient

{public static void main(String[] args)

{

try

{




// Lay GSR cua MathService Factory OGSIServiceGridLocator gridLocator = new OGSIServiceGridLocator();Factory factory = gridLocator.getFactoryPort(GSH);GridServiceFactory mathFactory = new GridServiceFactory(factory);

// Tao mot MathService instance moi va lay GSR cua no LocatorType locator = mathFactory.createService();

MathServiceGridLocator mathLocator = new MathServiceGridLocator();

MathPortType math = mathLocator.getMathServicePort(locator);

// Goi phuong thuc Add()

math.add(a);

System.out.println("Added " + a);

int value = math.getValue();

System.out.println("Current value: " + value);

// Huy service instance sau khi su dung math.destroy();

}catch(Exception e)

{

System.out.println("ERROR!");e.printStackTrace();



Phụ lục

- 205 -

}

}

}

CC..55.. K K ỹỹ tthhuuậậtt LLooggggiinngg ((GGhhii vvếếtt))

Logging là một k ỹ thuật quan tr ọng trong phát triển và bảo trì phần mềm, cho phép theo dõi các sự kiện đặc biệt của hệ thống, các sự kiện ghi nhận có thể đượ ck ết xuất ra màn hình. GT3 cung cấ p khả năng logging theo mô hình Apache JakartaCommons Logging (http://jakarta.apache.org/commons/logging/). Mô hình này đưara 6 cấ p độ thông tin logging, gồm Debug, Trace, Info, Warn, Error, Fatal. Việcquyết định thông tin nào ở mức độ nào là tuỳ thuộc vào ngườ i lậ p trình ứng dụng.

Ở đây chúng ta sẽ thêm tính năng logging vào MathService, sử dụng lại ví dụ

đầu tiên. Khi thêm tính năng logging, chúng ta không cần sửa lại portType, chỉ cầnthêm các lệnh cần thiết vào mã cài đặt portType.+ Cài đặt

File:$GRIDSER_DEMO/org/globus/progtutorial/services/core/logging/impl/M athImpl.java

// ...

import org.apache.commons.logging.Log;import org.apache.commons.logging.LogFactory;

// ...

public class MathImpl extends GridServiceImpl implements MathPortType

{

// Tao logger cho class nay static Log logger = LogFactory.getLog(MathImpl.class.getName());

// ...


{

logger.info("Addition invoked with parameter a=" + String.valueOf(a));if (a==0)logger.warn("Adding zero doesn't modify the internal value!");

value = value + a;

}//...

public int getValue() throws RemoteException

{

logger.info("getValue() invoked");

return value;

}

}

+ Xem các k ết xuất log Để xem k ết xuất log của MathService, thêm dòng sau vào cuối file:

$GLOBUS_LOCATION/ogsilogging.properties( Đ ây là file c ấu hình Log

c ủ a GT3)



Phụ lục

- 206 -

#Cho biet can xuat cac log o cap do Info ra man hinh console, co the

sua #lai cac cap do khac, va ghi ra file

org.globus.progtutorial.services.core.logging.impl.MathImpl=console,info

CC..66.. K K ỹỹ tthhuuậậtt qquuảảnn llýý cchhuu ttrr ì ìnnhh ssốốnngg ccủủaa sseerrvviiccee ((LLiif f eeccyyccllee

MMaannaaggeemmeenntt))

Như đã biết việc quản lý chu trình sống của các service instance đượ c tạo lậ pđộng r ất quan tr ọng. GT3 cung cấ p các công cụ hữu ích để quản lý các service như

phươ ng thức callback (callback method), theo dõi chu trình sống (lifecyclemonitor). Ở đây chúng ta sẽ sử dụng lại các ví dụ trong phần transient service vàlogging để demo 2 k ỹ thuật trên.

+ K ỹ thuật Callback method. Một cách đơ n giản để quản lý chu trình sống bằng callback method (tươ ng tự

các hàm sự kiện khi lậ p trình vớ i MS Windows). Các phươ ng thức callback đượ cgọi trong một số thờ i điểm xác định trong chu trình sống của service. GT3 hỗ tr ợ các hàm callback sau:

Hàm Thờ i điểm đượ c gọi

preCreate Khi quá trình tạo lậ p Grid Service bắt đầu, lúc này tất cả cấu hìnhchưa đượ c nạ p.

postCreate Khi serviceđã đượ c tạo ra và cấu hình service đã đượ c tạo lậ p.activate Tất cả Grid service đều mặc định ở tr ạng thái “không kích

hoạt”(deactivated), hàm này đượ c gọi khi service đượ c kích hoạt.deactivate Khi service tr ở về tr ạng thái “không kích hoạt”

preDestroy Ngay tr ướ c khi service bị huỷ.

Bảng 8-2 Các hàm callback trong GT3.

File :$GRIDSER_DEMO/org/globus/progtutorial/services/core/lifecycle/impl/MathImpl.java

// ...

import org.globus.ogsa.GridServiceCallback;

// ...

public class MathImpl extends GridServiceImpl

implements MathPortType, GridServiceCallback

{

// ...

// Cai dat cac phuong thuc Callback, chi can su dung lai cac ham cai san cualop cha GridServiceImpl

public void preCreate(GridServiceBase base) throws GridServiceException{super.preCreate(base);logger.info("Instance is going to be created (preCreate)");

} public void postCreate(GridContext context) throws GridServiceException{



Phụ lục

- 207 -

super.postCreate(context);logger.info("Instance has been created (postCreate)");

}

public void activate(GridContext context) throws GridServiceException

{super.activate(context);logger.info("Instance has been activated (activate)");

} public void deactivate(GridContext context) throws GridServiceException{super.deactivate(context);logger.info("Instance has been deactivated (deactivate)");

} public void preDestroy(GridContext context) throws GridServiceException{super.preDestroy(context);logger.info("Instance is going to be destroyed (preDestroy)");

}

}

+ K ỹ thuật Lifecycle MonitorK ỹ thuật Callback Method khá tốt, tuy nhiên nó khó có thể sử dụng lại. Giả

sử chúng ta có 2 hàm preCreate() và postCreate() và muốn sử dụng lại trong tất cả các Grid Service, vớ i k ỹ thuật Callback Method, chỉ có cách đưa nó vào một lớ pcha, r ồi cho tất cả các lớ p Grid Service khác thừa k ế từ nó. Tất nhiên đây có sự hạnchế như đã giớ i thiệu trong phần Operation Provider.

GT3 đưa ra giải pháp mớ i là Lifecycle Monitor. Một lifecycle monitor là mộtlớ p triển khai interface ServiceLifeCycleMonitor, một interface vớ i các hàm

callback đượ c gọi tại các thờ i điểm quan tr ọng trong thờ i gian sống của Gridservice. Chúng ta không cần k ế thừa hay tham thảo interface này tr ực tiế p từ mãnguồn. Chúng ta chỉ cần thêm một dòng vào bản đặc tả triển khai yêu cầu lớ plifecycle monitor phải đượ c gọi khi có sự kiện đặc biệt xảy ra. Do đó, chúng ta cóthể dùng cùng một lifecycle monitor cho nhiều Grid service khác nhau.

Dướ i đây là một lớ p lifecycle monitor đơ n giản, file :$GRIDSER_DEMO/org/globus/progtutorial/services/core/lifecycle/impl/MathLifecycleMonitor.java

package org.globus.progtutorial.services.core.lifecycle.impl;

import org.globus.ogsa.GridServiceException;

import org.globus.ogsa.ServiceLifecycleMonitor;

import org.globus.ogsa.GridContext;

import org.apache.commons.logging.Log;

import org.apache.commons.logging.LogFactory;

public class MathLifecycleMonitor implements ServiceLifecycleMonitor{

// Tao logger cho lop

static Log logger = LogFactory.getLog(MathLifecycleMonitor.class.getName());

//Cac phuong thuc can callback

public void create(GridContext context) throws GridServiceException{

logger.info("Instance is going to be created (create)");}



Phụ lục

- 208 -

public void destroy(GridContext context) throws GridServiceException{

logger.info("Instance is going to be destroyed (destroy)");

}

public void preCall(GridContext context) throws GridServiceException{

logger.info("Service is going to be invoked (preCall)");

}

public void postCall(GridContext context) throws GridServiceException

{

logger.info("Service invocation has finished (postCall)");

}

public void preSerializationCall(GridContext context){

logger.info("Input parameters are going to be deserialized

(preSerializationCall)");

}

public void postSerializationCall(GridContext context){

logger.info("Input parameters have been deserialized(postSerializationCall)");

}

}

Và thêm dòng sau vào file đặc tả triển khai (.WSDD)

<parameter name="lifecycleMonitorClass"value="org.globus.progtutorial.services.core.lifecycle.impl.MathLifecycleMonitor"/>

DD.. CCáácc iinntteer r f f aaccee ccủủaa mmộộtt OOGGSSII SSeer r vviiccee

Bảng 0-3 tóm tắt các interface của một Grid Service đượ c định ngh ĩ a trongOGSI 1.0:

Interface Loại Tên chi tiết Diễn giải

Định ngh ĩ a các ứng xử cơ bản của một service.interface Danh sách tên (QName) cácinterface của service.

serviceDataName Danh sách tên (QName) cácSDE của service (động vàt ĩ nh)

factoryLocator Vị trí (ogsi:LocatorType) củafactory tạo ra service instancenày

gridServiceHandle Zero hoặc nhiều GSH củaservice instance

GridService SDE

gridServiceReference Một hoặc nhiều GSR củaservice instance



Phụ lục

- 209 -

findServiceDataExtensibility Tậ p các phươ ng thức mở r ộng của phươ ng thứcfindServiceData

setServiceDataExtensibility Tậ p các phươ ng thức mở

r ộng của phươ ng thứcsetServiceData

terminationTime Thờ i gian dự kiến k ết thúccủa service instance.

findServiceData Truy vấn thông tin củaservice.

setServiceData Cho phép thay đổi giá tr ị cácSDE đượ c phép thay đổi giátr ị. (modifiable= “true”)

requestTerminationAfter Yêu cầu thay đổiterminationTime của serviceinstance. Phươ ng thức nàyxác định thờ i gian k ết thúcsớ m nhất có thể đượ c.

requestTerminationBefore Yêu cầu thay đổiterminationTime của serviceinstance. Phươ ng thức nàyxác định thờ i gian k ết thúc tr ễ nhất có thể đượ c.

Phươ ngthức

destroy Huỷ tườ ng minh service

instance.Thực hiện ánh xạ từ GSH sang GSR

handleResolverScheme Tậ p các URI xác định lượ cđồ GSH sử dụng để phân giảithành GSR.

SDE

HandleResolver

Phươ ngthức

findByHandle Tr ả về vị trí(ogsi:LocatorType) chức cácGSR tươ ng vớ i GSH đươ cyêu cầu.

Cho phép các client đặt các yêu cầu cung cấ p các thông báonotifiableServiceDataName Tậ p các QName của SDE

đượ c yêu cầu thông báo mỗikhi có sự thay đổi.

subscribeExtensibility Tậ p các phươ ng thức mở r ộng của phươ ng thứcsubscribe

SDE

NotificationSource

Phươ ngthức

subscribe Yêu cầu phải đượ c thông báomỗi khi có sự thay đổi củacác SDE xác định trong

notifiableServiceDataName.Định ngh ĩ a phươ ng thức phân phối các thông điệ p



Phụ lục

- 210 -

Định ngh ĩ a phươ ng thức phân phối các thông điệ pSDE Không cóNotification

Sink Phươ ngthức

deliverNotification Phân phối các thông báo.

Xác định mối quan hệ giữa một cặ p NotificationSource và NotificationSink

subscriptionExpressionsinkLocator

SDENotificationSubscription

Phươ ngthức

Không có

Cung cấ p các cách thức chuẩn để tạo các service instancecreateServiceExtensibility Tậ p các phươ ng thức mở

r ộng của phươ ng thức

createService

SDE

Factory

Phươ ngthức

createService Tạo service instance mớ i.

Cho phép client quản lý một nhóm các service.membershipContentRule Là một cấu trúc liên k ết một

portType vớ i một tậ p cácQName. Mỗi service instancenếu muốn là thành viên củanhóm phải có một hoặc nhiềuinterface xác định trong SDEnày.

SDE

entry Biểu diễn thông tin về mộtthành viên của ServiceGroup.

Service

Group

Phươ ngthức

Không có

Cho phép thêm và loại bỏ các Grid service instance trong cácServiceGroup,

addExtensibility Tậ p các phươ ng thức mở r ộng của phươ ng thức add

removeExtensibility Tậ p các phươ ng thức mở

r ộng của phươ ng thứcremove

SDE

add Tạo một ServiceGroupEntryvà đưa vào ServiceGroup.

ServiceGroupRegistration

Phươ ngthức

remove Loại bỏ ServiceGroupEntrythoả yêu cầu đưa vào.

Định ngh ĩ a mối quan hệ thành viên của service instance vớ i ServiceGroup.ServiceGroupEntry

SDE memberServiceLocator Chứa vị trí(ogsi:LocatorType) củaservice instance đượ c thamkhảo đến.



Phụ lục

- 211 -

content Cung cấ p một số thông tin về service instance đang chứa.

Phươ ng

thức

Không có

Bảng 8-3 Các interface của một OGSI Service

EE.. CCấấuu ttr r úúcc mmộộtt cchhứứnngg cchhỉỉ đđiiệệnn ttửử

Một chứng chỉ điện tử bao gồm các phần chính : một subject (distinguishedname (DN)) duy nhất trong không gian tên của hệ thống Grid xác định ngườ i hoặcđối tượ ng mà chứng chỉ đại diện, một khóa công khai đi kèm vớ i subject, phần nhậndạng CA thực hiện ký chứng nhận chứng chỉ, chữ ký của CA và phần mở r ộng chứa

thông tin về cá nhân hay host đượ c chứng nhận. Một số thông tin có thể là địa chỉ email, tên tổ chức, …Hình vẽ sau mô tả chi tiết cấu trúc một chứng chỉ điện tử:

Hình 8-5 Cấu trúc một chứ ng chỉ điện tử .

* Việc lấy chứ ng nhận cho một ngườ i dùng (lư u ý có thể là ngườ i dùngthật sự hay host) trong Grid bao gồm các bướ c:

1. Ngườ i dùng Grid phát sinh một cặ p khoá (khóa bí mật và khóa côngkhai tươ ng ứng), và một bản yêu cầu chứng nhận chứa khoá công khai và cácthông tin cần thiết theo yêu của CA.



Phụ lục

- 212 -

2. Sau đó, ngườ i dùng gửi bản yêu cầu đến CA. Còn khóa bí mật đượ cgiữ lại và lưu tr ữ một cách cẩn thận.

3. CA (hay mở r ộng ra là RA) thực hiện xác minh thông tin trong bản yêucầu là đúng sự thật, tức là tìm cách chứng minh user gửi yêu cầu chính là chủ

sở hữu của khóa công khai trong bản yêu cầu. Việc này có thể thực hiện bằngnhiều cách khác nhau, có thể thông qua điện thoại, email, hay bằng conđườ ng tiế p xúc tr ực tiế p giữa hai bên,…

4. Sau khi kiểm tra xong, CA tạo một chứng chỉ bằng cách ký tên vào bảnyêu cầu, và gửi chứng chỉ này lại cho ngườ i dùng đã yêu cầu chứng nhận.

Việc yêu cầu chứng thực trên trên đây chỉ cần thực hiện một lần duy nhất,từ khi nhận đượ c chứng chỉ, ngườ i dùng có thể dùng nó đế đại diện cho mìnhkhi giao tiế p vớ i bất k ỳ hệ thống nào có yêu cầu chứng thực.



Phụ lục

- 213 -

TTààii lliiệệuu tthhaamm kkhhảảoo

[1] Ian Foster, The Grid , CLUSTERWORLD, vol 1, no.1, 2001,pp. 1-2

[2] Ian Foster, Carl Kesselman, Steven Tuecke, The Anatomy of Grid , Intl J.Supercomputer Applications, 2001.

[3] Ian Foster, What is the Grid? A Three Point Checklist , Argonne NationalLaboratory & University of Chicago, 20/06/2002.

[4] Ian Foster,Carl Kesselman, Jeffrey M. Nick, Steven Tuecke, The Physiology of

the Grid - An Open Grid Services Architecture for Distributed Systems

Integration, Version: 6/22/2002.

[5] I. Foster, D. Gannon, H. Kishimoto, The Open Grid Services Architecture,GLOBAL GRID FORUM, 10/03/2004, http://forge.gridforum.org/projects/ogsa-wg

[6] S. Tuecke, K. Czajkowski, I. Foster, J. Frey, S. Graham, C. Kesselman, T.Maquire, T. Sandholm, D. Snelling, P. Vanderbilt, Open Grid Services

Infrastructure (OGSI) Version 1.0, GLOBAL GRID FORUM, 27/06/2003,http://www.ggf.org/ogsi-wg

[7] Mark Baker, Rajkumar Buyya, Domenico Laforenza, Grids and Grid technologies for wide-area distributed computing , John Wiley & Sons Ltd, 2002

[8] Steven Fitzgerald, Ian Foster, Carl Kesselman, Gregor von Laszewski,Warren Smith, Steven Tuecke, A Directory Service for Configuring

High-Performance Distributed Computations, 1997,http://www.globus.org

[9] Ian Foster, Carl Kesselman , Globus: A Metacomputing Infrastructure Toolkit ,http://www.globus.org

[10] Karl Czajkowski, Steven Fitzgerald, Ian Foster, Carl Kesselman, Grid

Information Services for Distributed Resource Sharing , Proc. 10th IEEEInternational Symposium on High-Performance Distributed Computing (HPDC-10), IEEE Press, 2001.

[11] Karl Czajkowski, Ian Foster, Nicholas Karonis, Carl Kesselman, Stuart Martin, Warren Smith, Steven Tuecke, A Resource Management

Architecture for Metacomputing Systems , 1997, www.globus.org

[12] Sam Lang, Sam Meder, Security and Credential Management on the Grid ,CLUSTERWORLD volume 1 no 2 , pp. 8-11, 02/2004

[13] Von Welch, Frank Siebenlist, Ian Foster, John Bresnahan,Karl Czajkowski, Jarek Gawor, Carl Kesselman, Sam Meder,





Phụ lục

- 215 -

[27] Parvin Asadzadeh, Rajkumar Buyya1, Chun Ling Kei, Deepa Nayar, Srikumar Venugopal, Global Grids and Software Toolkits: A Study of Four Grid

Middleware Technologies, Grid Computing and Distributed Systems (GRIDS)Laboratory, The University of Melbourne, Australia

[28] Matthew Strebe, Network Security JumpStart , SYBEX Inc., 2002

[29] James Stanger, Patrick Lane, Tim Crothers, CIW:Security Professional

Study Guide, SYBEX Inc., 2002, www.sybex.com

[30] Wenke Lee, Salvatore J. Stolfo, Kui W. Mok, Adaptive Intrusion Detection: a

Data Mining Approach, Kluwer Academic Publishers, 2000.

[31] John McHugh, Alan Christie, Julia Allen, Defending Yourself: The Role of

Intrusion Detection Systems, IEEE SOFTWARE, 10/2000.

[32] Thomas H. Ptacek, Timothy N. Newsham, Insertion, Evasion, and Denial of

Service:Eluding Network Intrusion Detection, Secure Networks Inc.,01/1998

[33] Detmar Liesen, Requirements for Enterprise-Wide Scaling Intrusion Detection

Products, 2002

[34] William Allcock, Programming with GridFTP Client Library, CLUSTERWORLD volume 2 no 9 , pp. 1-6, 10/2004

[35] Globus Alliance, MDS ver 2.2 User’s Guide, Globus Aliance, www.globus.org,3/10/2003.

[36] William Allcock, GridFTP: Protocol Extensions to FTP for the Grid, Argonne National Laboratory, 03/2003

[37] Snort Project, Snort Users Manual 2.3.2, www.snort.org, 10/032005



Phụ lục

CCáácc WWeebbssiittee

STT Tổ chứ c Website1. Globus Alliance http://www.globus.org2. IBM http://www.ibm.com3. Global Grid Forum http://www.globalgridforum.org4. GridCafe http://gridcafe.web.cern.ch/gridcafe5. NSF MIDDLEWARE http://www.nsf-middleware.org

Documents

7064436 Tim Hieu Cong Nghe Grid Computing Va Ung Dung