Grid computing va quan tri mang

TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN TP.HCM

KHOA 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 0112132 Nguyễn Đăng Thành 0112280

TTÌÌMM HHIIỂỂUU CCÔÔNNGG NNGGHHỆỆ GGRRIIDD CCOOMMPPUUTTIINNGG

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

TTRROONNGG BBÀÀII TTOOÁÁNN QQUUẢẢNN TTRRỊỊ 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 em

xin 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ông

nghệ 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.

Lời nói đầu

- iii -

Với tinh thần tham gia nghiên cứu, học hỏi công nghệ, đề tài luận văn “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 nhằm đi những bước đầu tiên trong quá trình nghiên cứu,

phát triển, ứng dụng Grid vào thực tế. Luận văn nghiên cứu các vấn đề chung của

công nghệ Grid Computing, bộ Globus Toolkit, tiến hành cài đặt một môi trường

Grid với bộ Globus Toolkit, đề xuất mô hình và cài đặt thử nghiệm ứng dụng hỗ trợ

quản trị mạng trên nền Grid.

Luận văn được trình bày gồm 8 chương với nội dung như sau:

Chương 1. Đặt vấn đề : Giới thiệu sơ lược về công nghệ Grid

Computing và lĩnh vực quản trị mạng, đồng thời xác định mục tiêu của đề tài.

Chương 2. Tổng quan về công nghệ Grid Computing : Giới thiệu các

vấn đề của công nghệ Grid Computing, tìm hiểu và so sánh các phần mềm nền

tảng Grid để có cái nhìn khá toàn diện về công nghệ Grid Computing hiện nay.

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

hình và các cơ chế hoạt động của các thành phần trong bộ Globus Toolkit 3.2. Ở

đây không thiên về giới thiệu chi tiết các triển khai cụ thể, điều này có thể tham

khảo từ các tài liệu hướng dẫn sử dụng.

Chương 4. Phát triển ứng dụng với Globus Toolkit 3.2 : Giới thiệu các

vấn đề cần quan tâm khi xây dựng một ứng dụng Grid với bộ Globus Toolkit

3.2.

Chương 5. Quản trị mạng và các hệ thống quản trị : Giới thiệu tổng

quan về lĩnh vực quản trị mạng cũng như các hệ thống quản trị mạng.

Chương 6. Hệ thống quản trị Grid NetManager : Giới thiệu mô hình

hệ thống quản trị mạng dựa trên nền công nghệ tính toán Grid Computing.

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

NetManager.

Chương 8. Kết luận : Là chương cuối cùng của luận văn, tóm lại các vấn

đề đã nghiên cứu tìm hiểu, đề ra hướng phát triển trong tương lai.

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) ..............................................................1 1.2. Vấn đề quản trị mạng..................................................................................................3 1.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 ...........................................................................................................5 2.1.1. Theo dòng lịch sử ................................................................................................5 2.1.2. Khái niệm.............................................................................................................6 2.1.3. Tài nguyên của Grid ............................................................................................7

2.2. Phân loại Grid & Grid Topology ................................................................................9 2.2.1. Các kiểu Grid .......................................................................................................9 2.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............................................................15 2.3.1. Quản lý tài nguyên (Resource Management) ....................................................15 2.3.2. Bảo mật (Security) .............................................................................................17 2.3.3. Quản lý thông tin ...............................................................................................19 2.3.4. Quản lý dữ liệu ..................................................................................................20 2.3.5. Phát triển ứng dụng............................................................................................20 2.3.6. Các vấn đề khác .................................................................................................20 2.3.7. Các việc cần làm................................................................................................21

2.4. Ích lợi & Ứng dụng...................................................................................................22 2.5. Các thành phần cơ bản của một hệ thống cơ sở hạ tầng Grid...................................24 2.6. Kiến trúc Grid ...........................................................................................................27

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

2.7. Chuẩn hoá Grid.........................................................................................................36 2.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 ................................................................................................................43 2.8.4. GridBus..............................................................................................................45 2.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 ..................................................................................................................52 3.1.1. Giới thiệu ...........................................................................................................52 3.1.2. Lịch sử phát triển ...............................................................................................53

3.2. Các công nghệ, chuẩn liên quan ...............................................................................53 3.2.1. Service Oriented Architeture (SOA)..................................................................53 3.2.2. Web Service.......................................................................................................56 3.2.3. OGSA.................................................................................................................58 3.2.4. OGSI và Grid Service ........................................................................................65

3.3. Kiến trúc Globus Toolkit ..........................................................................................74 3.3.1. Mô hình kiến trúc GT2 ......................................................................................75 3.3.2. Mô hình kiến trúc GT3 ......................................................................................76

3.4. Các thành phần chính................................................................................................79 3.4.1. Sercurity Infrastructure ......................................................................................79 3.4.2. Resource Management.......................................................................................94 3.4.3. Information Service .........................................................................................107 3.4.4. Data Management ............................................................................................113 3.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........................................................................................................115 4.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.........................................117

4.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).......................................................................118 4.2.2. Bảo mật ............................................................................................................118 4.2.3. Tính mềm dẻo của ứng dụng (Flexibility) .......................................................119 4.2.4. Các kết nối với bên ngoài ................................................................................119 4.2.5. Hiệu suất ứng dụng(Performance) ...................................................................120 4.2.6. Độ tin cậy (Reliability) ....................................................................................121 4.2.7. Quản trị hệ thống (Management).....................................................................122 4.2.8. Đồ hình hệ thống (System Topology)..............................................................123 4.2.9. Môi trường đa nền tảng....................................................................................123 4.2.10. Định dạng file ................................................................................................124 4.2.11. Việc cài đặt hệ thống .....................................................................................124 4.2.12. Vấn đề thông tin Grid ....................................................................................124 4.2.13. Tính tiện dụng................................................................................................124

4.3. Thiết kế tổng quan ..................................................................................................125 4.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 ..........................................................................................127 4.4.2. Xem xét sử dụng ngôn ngữ lập trình ...............................................................130 4.4.3. Vấn đề phụ thuộc của công việc vào môi trường hệ thống..............................131 4.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................................................134 4.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 .........................................................................................................142 5.1.1. Khái niệm.........................................................................................................142 5.1.2. Các lĩnh vực quản trị mạng..............................................................................142

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

5.3. Hệ thống Intrusion Detection System (IDS)...........................................................149 5.3.1. Khái niệm.........................................................................................................149 5.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 ............................................................................................................150 5.4.2. Snort.................................................................................................................152

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

6.1. Giới thiệu ý tưởng...................................................................................................153 6.2. Yêu cầu chức năng của một hệ thống quản trị mạng..............................................154 6.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 .........................................................................................155 6.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.........................................................158 6.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 .................................................................................................................161 7.1.1. Ngữ cảnh hệ thống...........................................................................................161 7.1.2. Lược đồ Use Case ............................................................................................162 7.1.3. Đặc tả Use Case ...............................................................................................163 7.1.4. Mô tả các dòng sự kiện ....................................................................................167

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

7.3. Cài đặt & Triển khai ...............................................................................................183 7.3.1. Công cụ và môi trường phát triển ứng dụng....................................................183 7.3.2. Mô hình cài đặt ................................................................................................184 7.3.3. Mô hình triển khai............................................................................................184 7.3.4. Thử nghiệm......................................................................................................185

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

8.1. Đánh giá..................................................................................................................186 8.1.1. Về luận văn ......................................................................................................186 8.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.....................................................................................................187 8.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.............................................189 B. Định dạng file GWSDL ............................................................................................191 C. 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...................................................................193 C.2. Thêm thành phần dữ liệu (Service Data Element (SDE))..................................196 C.3. Cài đặt cơ chế Notification.................................................................................199 C.7. Cài đặt kỹ thuật tạo service động (Transient service) ........................................202 C.5. Kỹ thuật Logging (Ghi vết)................................................................................205 C.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 ........................................................................208 E. 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á. ................................................................................................................9 Hình 2-2 Hình thức hoạt động của Grid Tính toán..............................................................10 Hình 2-3 Các đồ hình Grid. .................................................................................................11 Hình 2-4 Đồ hình SimpleGrid .............................................................................................12 Hình 2-5 Đồ hình IntraGrid .................................................................................................13 Hình 2-6 Đồ hình ExtraGrid ................................................................................................14 Hình 2-7 Các minh họa về đồ hình InterGrid. .....................................................................15 Hình 2-8 Kiến trúc Grid tổng quát.......................................................................................29 Hình 2-9 Quan điểm của các lập trình viên về kiến trúc Grid. ...........................................34 Hình 2-10 Kiến trúc Grid trong thực tế với các thành phần. ...............................................35 Hình 2-11 Các dự án Grid tương ứng với các tầng..............................................................36 Hình 2-12 Mối quan hệ giữa các chuẩn về Grid Service.....................................................39 Hình 2-13 Mô hình kiến trúc hoạt động của UNICORE .....................................................41 Hình 2-14 Kiến trúc của Legion. .........................................................................................44 Hình 2-15 Kiến trúc GridBus...............................................................................................46 Hình 2-16 So sánh giữa UNICORE, Globus, Legion và GridBus. .....................................49 Hình 3-1 Các thành phần của kiến trúc SOA.......................................................................54 Hình 3-2 Kiến trúc của bộ Globus Toolkit. .........................................................................75 Hình 3-3 Mô hình các thành phần của một hệ thống sử dụng GT2.....................................76 Hình 3-4 Mô hình tổ chức các thành phần GT3. .................................................................77 Hì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.......................................................................87 Hình 3-7 Thủ tục chứng thực và phân quyền với GSI.........................................................88 Hình 3-8 Cơ chế ủy quyền trong GSI. .................................................................................89 Hình 3-9 Thủ tục uỷ quyền của một proxy trong GSI. ........................................................90 Hình 3-10 Kiến trúc quản lý tài nguyên trong Globus Toolkit............................................95 Hình 3-11 Các trạng thái của một công việc. ......................................................................98 Hình 3-12 Các thành phần và cơ chế hoạt động của pre-WS GRAM .................................99 Hình 3-13 Cơ chế hoạt động có DUROC trong pre-WS GRAM. .....................................101 Hình 3-14 Các thành phần và cơ chế hoạt động của WS-GRAM. ...................................105 Hình 3-15 Mô hình quản lý thông tin trong Grid của Globus Toolkit...............................107 Hì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. ..............................................110 Hình 3-18 Các thành phần và cơ chế hoạt động của MDS2.............................................111 Hình 4-1 Luồng ứng dụng song song. ...............................................................................128 Hình 4-2 Luồng ứng dụng tuần tự. ....................................................................................128 Hình 4-3 Luồng ứng dụng mạng........................................................................................129 Hình 4-4 Các file cần thiết để triển khai Grid Service với Ant. ........................................139 Hình 5-1 Mô hình hệ thống quản trị mạng ........................................................................144 Hình 5-2 Màn hình giao diện Ethereal...............................................................................151 Hình 6-1 Mô hình thành phần ứng dụng Grid NetManager. .............................................155 Hình 6-2 Mô hình các thành phần của ứng dụng Grid NetManager thử nghiệm. .............160 Hì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 hình

- ix -

Hình 7-3 Sơ đồ lớp cài đặt lớp đối tượng. .........................................................................179 Hình 7-4 Màn hình chính ứng dụng Grid NetManager thử nghiệm..................................181 Hình 7-5 Màn hình Packet Capture Configue ...................................................................182 Hình 7-6 Mô hình cài đặt. ..................................................................................................184 Hình 7-7 Sơ đồ triển khai ứng dụngGrid NetManager thử nghiệm...................................184 Hình 7-8 Mô hình cài đặt thử nghiệm................................................................................185 Hình 8-1 Lớp triển khai interface của Grid service bằng kỹ thuật kế thừa........................194 Hình 8-2 Cài đặt intrface củaGrid service bằng kỹ thuật Operation Provider...................194 Hình 8-3 Ví dụ về SDE của MathService..........................................................................196 Hình 8-4 Sơ đồ hoạt động của cơ chế Notification trong GT3..........................................200 Hình 8-5 Cấu trúc một chứng chỉ điện tử. .........................................................................211

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

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

Service data Thành phần dữ liệu của một Service Site 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ụ Grid Virtual 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 Authority DN Distinguished Name EJB Enterprise JavaBeans GGF Global Grid Forum GSH Grid Service Handle GSI Grid Security Infrastructure GSR Grid Service Referance GT{x} Globus Toolkit Version x GWSDL Grid Web Services Description Language MDS Metacomputing Directory Service OGSA Open Grid Services Architecture OGSI Open Grid Services Infrastructure PKI Public Key Infrastructure RA Registrant Authority SDE Service Data Element SOA Service Oriented Architeture SSL Secure Sockets Layer URI Uniform Resource Indicator WSDL Web Services Description Language WSRF 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, ứng dụ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

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

- xiv -

• Hệ điều hành và môi trường mạng Linux Redhat 9.0 • Môi trường lập trình C/C++ trong Linux với thư viện giao diện đồ hoạ

GTK. • Bộ Globus Toolkit 3.2 và phát triển ứng dụng với nó.

Chương 1. Mở đầu

- 1 -

CChhưươơnngg 11.. MMởở đđầầuu

11..11.. CCôônngg nngghhệệ GGrriidd CCoommppuuttiinngg ((ttíínnhh ttooáánn llưướớii)) Với những tiến bộ trong nền công nghiệp sản xuất phần cứng máy tính, các thế

hệ máy tính ngày nay đã trở nên mạnh và rẻ hơn rất nhiều so với các thế hệ trước

đó. Cùng với sự hữu ích, máy tính đã trở nên phổ dụng khắp nơi trên thế giới, đi sâu

vào mọi công việc của con người, từ công việc hàng ngày, công sở, kinh doanh đến

sản xuất, nghiên cứu khoa học. Do đó số lượng máy tính hiện nay trên thế giới là rất

lớn với tổng cộng năng lực xử lý và lưu trữ khổng lồ.

Tuy nhiên, các ứng dụng ngày nay chỉ mới sử dụng được một phần rất nhỏ năng

lực xử lý và lưu trữ do các ứng dụng chỉ chạy trên các máy tính cục bộ, đơn lẻ, phân

tán khắp nơi theo địa lý. Từ đó dẫn đến lãng phí rất lớn. Một câu hỏi được đặt ra là

làm sao tận dụng tốt hơn năng lực của máy tính.

Mặt khác, theo đà phát triển, con người càng ngày càng đối mặt với nhiều vấn

đề lớn, phức tạp trong khoa học, thương mại đòi hỏi năng lực xử lý tính toán, lưu

trữ lớn :

- Trong khoa học :

Cách đây 10 năm các nhà sinh học đã rất vui mừng khi họ có thể giả

lập một đơn phân tử trên máy tính, ngày nay họ muốn giả lập hàng ngàn

phân tử thuốc, protein và tác dụng tương hỗ giữa chúng để tạo ra các loại

thuốc mới.

Để nghiên cứu các hạt cơ bản và tương tác giữa chúng, hàng năm

ngành Vật lý Năng lượng cao (High Energy Physics) tạo ra khoảng 10

Petabytes (dung lượng của khoảng 20 triệu đĩa CD-ROM) dữ liệu. Hay các

nhà vật lý địa cầu thực hiện theo dõi bầu khí quyển, tầng ozone, hàng ngày

phải lưu trữ và phân tích khoảng 100 Gigabytes dữ liệu ảnh chụp từ vệ tinh.

Ở đây cho thấy cần phải có năng lực lưu trữ rất lớn.

Việc phân tích, giải mã bộ gen người, các dự án nghiên cứu vũ trụ,…

cũng cần năng lực xử lý rất lớn.


- 2 -

Vấn đề hợp tác giữa hàng ngàn nhà khoa học trên toàn thế giới, hỗ trợ

việc chia sẻ một lượng lớn dữ liệu, thực hiện các tính toán phức tạp trực

tuyến trên các dữ liệu đó.

- Trong thương mại:

Các bài toán phân tích xử lý số liệu kinh tế của các quốc gia, các công

ty đa quốc gia, …

Các công ty cung cấp dịch vụ mạng cho hàng triệu người dùng trên

toàn thế giới.

Các bài toán mô phỏng, giả lập trong thiết kế sản phẩm công

nghiệp…

Bài toán xử lý thông tin trong quản trị mạng, các hệ thống phát hiện

tấn công, xâm nhập mạng.

…..

Một máy tính đơn, một nhóm các máy tính(cluster) hay thậm chí một siêu máy

tính chuyên dụng cũng không thể đáp ứng được nhu cầu tính toán, lưu trữ ngày

càng lớn như vậy. Một số bài toán cũng có thể được giải quyết nhưng rất khó khăn,

với chi phí rất cao mà không phải quốc gia, tổ chức nào cũng thực hiện được (đặc

biệt là các nước đang phát triển), còn những bài toán khác có thể nói là không thể

giải quyết được với công nghệ tính toán hiện nay.

Thực tế khiến người ta nảy sinh ý tưởng phải kết hợp các máy tính phân tán

khắp nơi trên thế giới trở thành một siêu máy tính khổng lồ nhằm tận dụng năng lực

tính toán, lưu trữ hiện đang lãng phí để giải quyết các bài toán phức tạp trên đây với

chi phí thấp hơn.

Trước đây, khi các công nghệ mạng chưa phát triển thì ý tưởng trên hầu như

chưa thực hiện được. Nhưng hiện nay, các công nghệ mạng máy tính đã phát triển

vượt bậc, hiệu năng mạng tăng gấp đôi sau mỗi 9 tháng, ý tưởng về “siêu máy tính”

toàn cầu đã có cơ sở để trở thành hiện thực. Đến những năm cuối thế kỷ XX, các dự

án nghiên cứu đầu tiên về lĩnh vực này đã khai sinh ra công nghệ Grid Computing.

Công nghệ Grid Computing ra đời được dự đoán là công nghệ nền tảng của thế

kỷ XXI, làm thay đổi cách thức chúng ta tính toán, giống như Internet đã từng làm


- 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 ttrrịị 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


- 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ổng

quan 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ệệ GGrriidd

CCoommppuuttiinngg

22..11.. KKhhááii nniiệệmm GGrriidd

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ấp

nă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ết

hợ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


- 6 -

Laboratory) và Carl Kesselman (University of Southern California) năm 1998. Ian

Foster đã từng tham gia dự án I-WAY, Carl Kesselman là người tham gia dự án

Globus Toolkit, một dự án nền tảng của công nghệ Grid và Metacomputing.

Từ đó đến nay, việc phát triển công nghệ Grid trở nên rất sôi động với sự tham

gia nghiên cứu, đầu tư của nhiều tổ chức, tập đoàn công nghệ thông tin, nhiều quốc

gia, và đã thu được những thành tựu bước đầu.

Có thể nói, việc phát triển và xây dựng hệ thống Grid là sự kế thừa và phát triển

các ý tưởng, các công nghệ hiện hành ở mức cao hơn. Sự phát triển không ngừng

của cơ sở hạ tầng, phần cứng máy tính, mạng đã giúp các hệ thống Grid ngày nay

thực hiện được nhiều điều hơn những ý tưởng trước đây.

22..11..22.. KKhhááii nniiệệmm

Một định nghĩa về Grid khá hoàn chỉnh được đưa ra bởi tiến sỹ Ian Foster như

sau :

“Grid là một loại hệ thống song song, phân tán cho phép chia sẻ, lựa

chọn, kết hợp các tài nguyên phân tán theo địa lý, thuộc nhiều tổ chức khác nhau

dựa trên tính sẵn sàng, khả năng, chi phí của chúng và yêu cầu về chất lượng

dịch vụ (QoS) của người dùng để giải quyết các bài toán, ứng dụng có quy mô

lớn trong khoa học, kỹ thuật và thương mại. Từ đó hình thành nên các “tổ chức

ảo” (Virtual Organization (VO)), các liên minh tạm thời giữa các tổ chức và tập

đoàn, liên kết với nhau để chia sẻ tài nguyên và/hoặc kỹ năng nhằm đáp ứng tốt

hơn các cơ hội kinh doanh hoặc các dự án có nhu cầu lớn về tính toán và dữ

liệu, toàn bộ việc liên minh này dựa trên các mạng máy tính”

Một hệ thống Grid có những đặc trưng sau:

1. Có sự kết hợp, chia sẻ các tài nguyên không được quản lý tập trung

Grid tích hợp và phối hợp tài nguyên, người dùng thuộc nhiều vùng

quản lý khác nhau, nhiều đơn vị khác nhau trong một tổ chức, hay nhiều tổ chức

khác nhau. Công nghệ Grid tập trung giải quyết các vấn đề về bảo mật, chính sách

quản trị, chi phí, thành viên,… nảy sinh trong quá trình chia sẻ và sử dụng tài

nguyên.


- 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 đơn

vị 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


- 8 -

dụng, trong khi các thiết bị lưu trữ ngoài có thể được sử dụng để tăng không gian

lưu trữ, tăng hiệu suất, khả năng chia sẻ và đảm bảo tính tin cậy của dữ liệu.

22..11..33..33.. PPhhưươơnngg ttiiệệnn lliiêênn llạạcc

Khả năng liên lạc giữa các máy tính phát triển nhanh chóng đã giúp cho công

nghệ Grid trở nên hiện thực, do đó đây cũng là một tài nguyên quan trọng. Ở đây

bao gồm việc liên lạc, trao đổi dữ liệu giữa các thành phần trong Grid và giao tiếp

giữa Grid với bên ngoài. Một số công việc đòi hỏi một lượng dữ liệu lớn nhưng các

dữ liệu này thường không nằm trên máy đang thực thi công việc. Khả năng về băng

thông trong những trường hợp như vậy là một tài nguyên then chốt, ảnh hưởng đến

khả năng của Grid.

Việc giao tiếp với bên ngoài được thực hiện thông qua mạng Internet. Grid có

thể sử dụng các kết nối Internet để liên lạc giữa các node. Vì các kết nối này không

chia sẻ một đường truyền nên làm tăng băng thông truy cập Internet.

Các đường truyền dự phòng đôi khi cần thiết để giải quyết tốt hơn các vấn đề về

hư hỏng mạng và truyền dữ liệu lớn.

22..11..33..44.. PPhhầầnn mmềềmm,, ứứnngg ddụụnngg

Grid có thể được cài đặt các phần mềm mà có thể quá mắc để cài trên tất cả mọi

máy tính trong Grid. Các phần mềm này chỉ cần được cài trên một số node. Thông

qua Grid, khi một công việc cần đến chúng, nó sẽ gửi dữ liệu đến node đã được cài

đặt phần mềm và cho thực thi. Đây có thể là một giải pháp tốt để tiết kiệm chi phí

về bản quyền phần mềm.

22..11..33..55.. CCáácc tthhiiếếtt bbịị đđặặcc bbiiệệtt

Là các thiết bị dùng trong khoa học, kỹ thuật như kính viễn vọng, các bộ cảm

biến (sensor),… Các thiết bị này chủ yếu thu thập các dữ liệu khoa học, phục vụ cho

các bước phân tích, xử lý sau này.

Ghi chú: Các tài nguyên trên đây đến từ nhiều nguồn khác nhau, có thể không

thuộc quyền quản lý của một tổ chức, của một đơn vị mà có thể thuộc nhiều tổ


- 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ột

khố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 GGrriidd && GGrriidd TTooppoollooggyy

22..22..11.. CCáácc kkiiểể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ục

cho 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ới

thiệ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ệu

nhạ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án

theo đị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ách

hà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ệệ GGrriidd

22..33..11.. QQuuảảnn llýý ttààii nngguuyyêênn ((RReessoouurrccee 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ạp

trong quản lý tài nguyên:

STT Đối Tượng Đặc tính 1. Người dùng, Người

cung 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ản trị, sở hữu khác nhau.

3. Tính sẵn sàng và khả năng của tài nguyê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ười dùng có các mục tiêu và chiến lược chia sẻ, sử dụng khác nhau.

5. Yêu cầu chất lượng dị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ực

thi để đá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ác

chứ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 đđềề kkhháá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ười

dù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ác

như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 anh

ta 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ăng

thự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 GGrriidd 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 ứng

dụ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.


- 27 -

22..66.. KKiiếếnn ttrrúúcc GGrriidd

22..66..11.. BBảảnn cchhấấtt KKiiếếnn ttrrúúcc GGrriidd

“Tổ chức ảo”(VO) là đơn vị cơ bản quan trọng trong hệ thống Grid. Việc

thiết lập, quản lý, khai thác các quan hệ chia sẻ tài nguyên giữa các tổ chức ảo đòi

hỏi phải có kiến trúc hệ thống mới, kiến trúc Grid. Kiến trúc Grid dưới đây được

xây dựng dựa trên quan niệm “để các VO hoạt động hiệu quả đòi hỏi phải thiết

lập được các quan hệ chia sẻ với bất kỳ đơn vị tham gia tiềm năng nào”. Để làm

được điều này, vấn đề “liên kết hoạt động” (interoperability) cần phải được tập

trung giải quyết. Trong môi trường mạng, “liên kết hoạt động” đồng nghĩa với việc

sử dụng các protocol chung. Do đó, kiến trúc Grid sẽ là kiến trúc protocol, với các

protocol xác định các cơ chế nền tảng để người dùng và nhà cung cấp tài nguyên

thương lượng, thiết lập, quản lý và khai thác các mối quan hệ chia sẻ tài nguyên.

Kiến trúc Grid phải là kiến trúc dựa chuẩn, hướng mở, để dễ mở rộng, liên kết

hoạt động tốt, có tính khả chuyển (portability) cao. Các protocol chuẩn sẽ giúp định

nghĩa các service chuẩn, nhờ đó có thể xây dựng các service cao cấp hơn một cách

dễ dàng.

Sau khi có được kiến trúc Grid, việc tiếp theo là xây dựng các hàm API và các

bộ SDK để cung cấp các công cụ cần thiết để phát triển các ứng dụng chạy trên nền

Grid.

Sở dĩ vấn đề “liên kết hoạt động” được xem là vấn đề cơ bản vì các mối quan hệ

chia sẻ có thể phải được thiết lập giữa các bên tham gia khác nhau về các chính

sách, giữa các môi trường khác nhau về nền tảng, ngôn ngữ, môi trường lập

trình,…Nếu không có nó, các thành viên trong VO sẽ thực hiện các chính sách chia

sẻ song phương và không chắc rằng các cơ chế sử dụng cho 2 thành viên này sẽ mở

rộng được cho các thành viên khác. Điều này khiến cho việc thành lập các VO động

là không thể thực hiện hoặc cũng chỉ thành lập được VO theo một kiểu nào đó mà

thôi. Cũng giống như Web đã làm bùng nổ việc chia sẻ thông tin bằng cách cung

cấp các protocol và cú pháp chuẩn (HTTP và HTML) dùng cho việc trao đổi thông

tin, ở đây cũng cần các protocol và cú pháp chuẩn để chia sẻ tài nguyên.


- 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 KKiiếế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


- 29 -

từ bất cứ tầng dưới nào. Các thành phần được phân tầng dựa theo vai trò của chúng

trong hệ thống Grid. Đây là một kiến trúc mở.

Kiến trúc này chỉ quy định các yêu cầu chung nhất về thiết kế và triển khai với

mục đích chính là để tham khảo. Việc xây dựng, cài đặt cụ thể tuỳ thuộc vào từng

dự án, từng lĩnh vực ứng dụng.

Dưới đây là chi tiết của kiến trúc:

Hình 2-8 Kiến trúc Grid tổng quát.

22..66..22..11.. TTầầnngg FFaabbrriicc

Đây là tầng thấp nhất của kiến trúc, đại diện cho các thiết bị vật lý và toàn bộ tài

nguyên của Grid mà các tổ chức, người dùng muốn chia sẻ, sử dụng. Các tài nguyên

có thể tồn tại dưới dạng vật lý như các máy tính, hệ thống lưu trữ, các danh mục, tài

nguyên mạng, các loại sensor, cũng có thể là các thực thể logic - một thực thể trừu

tượng - đại diện cho một tập các tài nguyên vật lý, như hệ thống file phân tán, các

cluster,… Trong trường hợp các thực thể logic, việc triển khai có thể liên quan đến

các protocol cục bộ (ví dụ các protocol phục vụ dạng truy cập NFS, hoặc protocol

quản lý tài nguyên, tiến trình trong cluster,…) nhưng các protocol này không liên

quan đến kiến trúc Grid.

Các thành phần của tầng Fabric thực hiện các hoạt động cục bộ trên các tài

nguyên cụ thể (vật lý lẫn logic) như là bước tiếp sau của các hoạt động chia sẻ tài

nguyên của các tầng trên. Do đó, có một mối liên hệ phụ thuộc chặt chẽ giữa các

chức năng của tầng Fabric với các hoạt động chia sẻ được hỗ trợ. Các chức nă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ảo

mậ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 RReessoouurrccee

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


- 33 -

Thực hiện các chính sách công cộng quản lý truy cập tài nguyên, cho

phép các thành viên của cộng đồng truy cập đến các nguyên dùng chung. Các

server này sử dụng các dịch vụ xây dựng trên các protocol thông tin, quản lý tài

nguyên của tầng Resource và protocol bảo mật ở tầng Connectivity.

+ Community accounting and payment service

Thu thập các thông tin sử dụng tài nguyên để tính toán chi phí, thực hiện

chi trả và/hoặc giới hạn việc sử dụng tài nguyên của người dùng trong cộng

đồng.

+ Collaboratory service

Hỗ trợ việc trao đổi thông tin đồng bộ và bất đồng bộ trong cộng đồng

người dùng.

Các ví dụ trên đây cho thấy các protocol và dịch vụ tầng Collective rất phong

phú, đa dạng. Lưu ý rằng trong khi các protocol tầng Resource phải là các protocol

tổng quát và triển khai rộng rãi, thì các protocol tầng Collective có thể trải dài từ

việc phục vụ các vấn đề chung trong Grid đến việc phục vụ cho các lĩnh vực ứng

dụng cụ thể, có thể chỉ tồn tại trong các VO cụ thể. Theo nguyên tắc, càng phục vụ

nhiều người dùng thì các protocol và API của tầng Collective càng phải được dựa

theo chuẩn.

Các chức năng của tầng Collective có thể được cài đặt như các service (với các

protocol tương ứng), hay như các bộ SDK(với các API tương ứng) được thiết kế để

liên kết với ứng dụng. Trong cả hai trường hợp, các cài đặt này có thể được xây

dựng trên các protocol và API của tầng Resource và Connectivity.

22..66..22..55.. TTầầnngg AApppplliiccaattiioonn

Tầng trên cùng của kiến trúc Grid bao gồm các ứng dụng của người dùng chạy

trong một trường VO. Hình 2-9 minh hoạ quan điểm của các lập trình viên về kiến

trúc Grid. Các ứng dụng được xây dựng theo cách sẽ gọi các dịch vụ định nghĩa bởi

các tầng phía dưới.


- 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.


- 35 -

22..66..33.. KKiiếếnn ttrrúúcc GGrriidd ttrroonngg tthhựựcc ttếế

Trong thực tế, kiến trúc Grid tổng quan đã được cài đặt và xây dựng như hình

2-10. Kiến trúc gồm 4 tầng tương ứng với các tầng của kiến trúc tổng quát như sau:

Hình 2-10 Kiến trúc Grid trong thực tế với các thành phần.

+ Tầng Fabric (tầng Fabric)

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

+ Tầng Core Middleware (Connectivity và Resource và nửa dưới của

Collective)

Cung cấp các dịch vụ như quản lý tiến trình ở xa, kết hợp, phân phối các tài

nguyên, quản lý truy cập không gian lưu trữ, đăng ký và tìm kiếm thông tin, bảo

mật và các khía cạnh của QoS như đặt trước, mua bán và trao đổi tài nguyên,… Các

dịch vụ này là sự trừu tượng hoá tính phức tạp và đa dạng của các tài nguyên bằng

cách cung cấp một phương pháp chung để truy cập tài nguyên.

+ Tầng User-level Middleware (Collective)


- 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áá GGrriidd 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ác

cô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àng

và 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ìm

kiế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 GGrriidd mmiiddddlleewwaarree 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.. UUNNIICCOORREE

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ân

quyề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


- 42 -

đăng nhập trong UUDB (UNICORE User Data Base). NJS chuyển đổi các định

nghĩa AJO thành các lệnh tương ứng cho hệ thống thực thi được chọn dựa trên các

đặc tả trong Incarnation Data Base (IDB). UNICORE TSI chấp nhận các công việc

xây dựng bởi NJS và chuyển chúng cho hệ thống thực thi cục bộ để xử lý.

Client kết nối đến UNICORE USite gateway, đây là điểm vào duy nhất cho tất

cả các kết nối UNICORE đến USite. Nó cung cấp một địa chỉ IP và số hiệu cổng để

người dùng có thể kết nối vào thông qua protocol SSL.

2. Các chức năng và đặc tính chính của UNICORE:

+ Tạo lập và đệ trình các công việc hướng người dùng.

Cung cấp giao diện GUI hỗ trợ người dùng tạo những công việc phức tạp

có thể chạy trên bất kỳ UNICORE Site nào mà không cần thay đổi đặc tả công

việc.

+ Có hệ thống quản lý công việc

Cho phép người dùng toàn quyền điều khiển công việc và dữ liệu.

+ Có hệ thống quản lý dữ liệu

Trong quá trình tạo lập các công việc, người dùng có thể xác định các tập

dữ liệu đầu vào và đầu ra từ USpace (USpace là tập các file sẵn sàng cho một

công việc UNICORE) và các tập dữ liệu nào cần phải truyền qua lại giữa các

USpace. UNICORE sẽ thực hiện các việc di chuyển dữ liệu trong thời gian thi

hành mà không cần sự can thiệp của người dùng.

+ Hỗ trợ ứng dụng

Để hỗ trợ các ứng dụng khoa học đặc biệt của các nhà khoa học, giao

diện người của UNICORE được xây dựng dưới dạng mở để có thể thêm các

thành phần mới cho phép nhập liệu hướng ứng dụng.

+ Điều khiển luồng

Một công việc của người dùng có thể được mô tả dưới dạng một tập các

đồ thị có hướng không vòng.

+ Cho phép đăng nhập một lần

UNICORE cho phép đăng nhập một lần thông qua các chứng chỉ

X.509V3.


- 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ữ)


- 46 -

+ Mức ứng dụng (ví dụ : các hoạt động phân tích phân tử cho các ứng dụng

thiết kế thuốc).

+ Tập các dịch vụ đã được kết hợp (ví dụ : môi giới và bán lại các dịch vụ

qua nhiều vùng khác nhau).

Ý tưởng tính toán kinh tế (computational economy) giúp cho việc tạo nên kiến

trúc tính toán hướng dịch vụ trong đó, các người dùng dịch vụ phải trả tiền cho các

ứng dụng và nhà cung cấp dựa trên những yêu cầu nhất định, người dùng có thể tối

ưu hóa công việc bằng cách chọn các dịch vụ cần thiết trong một giới hạn về chi

phí.

Hình 2-15 mô tả kiến trúc Gridbus phân tầng:

Hình 2-15 Kiến trúc GridBus

Hình vẽ cho thấy các thành phần của Gridbus trong việc liên kết với các công

nghệ middleware khác như Globus, UNICORE và Alchemi. Gridbus cung cấp các

phần mềm trong các lĩnh vực sau :

• Enterprise Grid Infrastructure (Alchemi)

Mặc dù phần lớn các tính toán khoa học đều sử dụng các hệ điều hành

dòng Unix, nhưng phần lớn hạ tầng tính toán trong các tổ chức thương mại vẫn

còn dựa trên Microsoft Windows. Do đó, Alchemi được phát triển để phục vụ


- 47 -

nhu cầu thực hiện các giải pháp Grid tận dụng các khả năng tính toán dư thừa ở

các máy trạm và máy tính cá nhân chạy Windows trong các tổ chức. Alchemi

được xây dựng trên nền Microsoft .NET Framework, cung cấp khả năng xây

dựng các “desktop Grid”, nó cũng cung cấp mô hình lập trình hướng đối tượng

cùng với giao diện Web service cho phép truy cập đến các service từ bất kỳ môi

trường lập trình nào hỗ trợ SOAP và XML.

• Cluster Economy and Resource Allocation (Libra)

Libra là một hệ thống lập lịch cho cluster để đảm bảo rằng các tài nguyên

chia sẻ cho các công việc của người dùng để chúng có thể hoàn thành trong một

giới hạn về ngân sách do người dùng xác định.

• Grid Economy and Virtual Enterprise (Grid Market Directory,

Compute Power Market)

Đây có thể gọi là một thể hiện của cơ chế thị trường cho ngành tính toán

kinh tế. Grid Market Directory (GMD) là một dịch vụ đăng ký cho phép các nhà

cung cấp dịch vụ có thể đăng ký và phát hành các dịch vụ họ cung cấp và cho

phép người tiêu dùng có thể truy vấn để tìm ra dịch vụ phù hợp với nhu cầu.

Một số thuộc tính của dịch vụ là điểm truy cập(Access point), cơ chế đầu vào, và

chi phí khi sử dụng nó.

Compute Power Market (CPM) là một hệ thống lập lịch và quản lý tài

nguyên theo cơ chế thị trường. Nó cho phép trao đổi năng lực tính toán nhàn rỗi

trong mạng máy tính ngang hàng. Các thành phần của CPM đại diện cho thị

trường, nhà cung cấp và tiêu thụ là Market Server, Market Resource Agent, và

Market Resource Broker (MRB). Nó hỗ trợ nhiều mô hình kinh tế cho phép trao

đổi tài nguyên, tìm kiếm nhà phân phối và tiêu thụ, cho phép đưa vào nhiều cơ

chế lập lịch khác nhau.

• Grid Trading and Accounting Services (GridBank)

GridBank là một dịch vụ kế toán và chi trả trong Grid cung cấp một hạ

tầng bảo mật, an toàn cho phép người tiêu dùng dịch vụ (Grid Service

Consumers (GSC)) chi trả cho nhà cung cấp dịch vụ (Grid Service Providers

(GSP)) về việc sử dụng dịch vụ của mình.


- 48 -

• Grid Resource Brokering and Scheduling (Gridbus Broker)

Gridbus Resource Broker cung cấp một giao diện trừu tượng đối với sự

phức tạp của Grid bằng cách làm trong suốt quá trình truy cập tài nguyên để

thực thi công việc trên Grid. Nó sử dụng các yêu cầu của người dùng để tạo ra

một tập các công việc, tìm kiếm tài nguyên, lập lịch, thực thi và kiểm soát, và

lấy kết quả về khi các công việc kết thúc.

Gridbus broker có khả năng định vị và lấy các dữ liệu cần thiết từ nhiều

nguồn và chuyển tới nơi xử lý. Nó cũng có khả năng chọn lựa nơi chứa dữ liệu

tốt nhất trong nhiều site dựa trên sự có mặt của file và chất lượng đường truyền

dữ liệu.

• Grid Portals (GMonitor)

G-Monitor là một web-portal để kiểm soát và điều khiển tính toán trên

Grid. G-Monitor giao tiếp với các resource broker như Gridbus và Nimgrod-G

và sử dụng các dịch vụ của chúng để khởi tạo và kiểm soát việc thực thi ứng

dụng. Nó cung cấp các thông tin cập nhật về tiến trình thực thi từ mức chi tiết

các công việc đến mức tổng quát toàn bộ ứng dụng. Khi kết thúc, người dùng có

thể tập hợp các file kết quả thông qua G-Monitor.

• Grid Simulation (GridSim)

Bộ toolkit GridSim cung cấp các tiện ích cho việc mô hình, giả lập các tài

nguyên và kết nối mạng với các khả năng, cấu hình, vùng quản lý khác nhau. Nó

hỗ trợ các thành phần cơ bản xây dựng các ứng dụng, dịch vụ thông tin phục vụ

việc tìm kiếm tài nguyên, cung cấp giao diện phục vụ việc cấp phát tài nguyên

cho các tác vụ và quản lý việc thực thi. Nó cũng cung cấp một một giao diện mô

hình hoá trực quan để tạo các người dùng và tài nguyên. Các tính năng này có

thể được sử dụng để giả lập các hệ thống song song và phân tán như resource

broker hoặc Grid scheduler để lượng giá hiệu quả của các giải thuật lập lịch,…

22..88..55.. SSoo ssáánnhh

Hình 2-16 so sánh các middleware trên đây theo các dịch vụ được cung cấp

theo mô hình phân tầng kiến trúc Grid trong thực tế. UNICORE và Legion tích hợp


- 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ình

cấp cao Các service cấp thấp

Mô hình lập trình cấp cao

Trừu tượng hoá và các mô hình thị trường tính toán

Lĩnh vực

Tập trung vào thực thi và kiểm soát job.

Mô hình tính toán chung, tổng quát



Kiến trúc Hệ thống đa tầng theo chiều sâu

Bộ toolkit có phân tầng và module hoá

Hệ thống tích hợp theo chiềo sâu.

Hệ thống các thành phân tầng.

Chuẩn sử dụng Mới bắt đầu áp dụng OGSA, 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ới Globus

Mô hình triển khai

Abstract Job Object Mô hình đồng hồ cát ở mức độ hệ thống

Siêu hệ thống hướ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ực thi

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ữ tham số dựa trên


- 50 -

MPI đặc biệt (MPICH-G),CoG (Commodity Grid) kits với Java, Python, CORBA, Matlab, Java Server Pages, Perl và Web Services

XML. Mô hình Grid Thread trong Alchemi.

Mô hình phân phối

Mã nguồn mở Mã nguồn mở Mã nguồn đóng, có các phiên bản thương mại.

Mã nguồn mở

Sử dụng trong một số ứng

dụng và người dùng

+EuroGrid +Grid Interoperability Project (GRIP) +OpenMolGrid + Japanese NAREGI

+ AppLeS + Ninf + Nimrod-G + NASA IPG + Condor-G + Gridbus Broker + UK eScience Project + GriPhyN + EU Data Grid.

+ NPACI Testbed + Nimrod-L +NCBioGrid.

+ ePhysics Portal + Belle Analysis Data Grid + NeuroGrid + Natural Language Engineering +HydroGrid +Amsterdam Private Grid.

Quản lý tài nguyên

Không có Có broker service

Có broker service

Gridbus broker

Cách thức liên lạc

Mô hình AJO, không hỗ trợ chuyển message đồng bộ.

Thư viện Nexus Hỗ trợ nhiều loại giao tiếp RMI thông qua LOID

Không có thông tin

Bảo mật Sử dụng Secure Socket Layer (SSL) protocol và chứng chỉ chứng thực X.509V3.

Thông qua GSI, cũng dựa trên SSL và X.509V3

Không có thông tin

+Dựa trên GSI của Globus + Sử dụng các chức năng bảo mật của Microsoft .NET Framework (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ới

nhau. 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ạo

mộ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ức

nă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.. KKiiếế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.

+ ServiceRegistry

Chị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ới

thiệ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ên

cá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.


- 59 -

33..22..33..22.. MMôô hhììnnhh sseerrvviiccee OOGGSSAA

Trong mô hình OGSA, mọi thứ đều được đại diện bởi một service (là một thực

thể kết nối mạng cung cấp một số tính năng nào đó thông qua việc trao đổi các

thông điệp). Tất cả các tài nguyên đều là các service. Chi tiết hơn nữa, OGSA xem

mọi thứ như là một Grid service : là một Web service hỗ trợ các quy ước và

interface chuẩn mà mỗi Grid service cần phải có.

Các Grid service được phân loại bởi các khả năng mà chúng cung cấp. Một Grid

service có thể có một hoặc nhiều interface, mỗi interface định nghĩa một tập các

phương thức có thể được gọi thực hiện bằng cách trao đổi các thông điệp theo thứ

tự được xác định trước. Grid service interface tương ứng với portType trong

WSDL. Tập các portType cung cấp bởi Grid service cùng với các thông tin liên

quan như phiên bản được xác định trong serviceType (một thành phần mở rộng từ

WSDL) của Grid service.

Các Grid service có thể quản lý các thông tin trạng thái nội bộ của chúng trong

thời gian sống. Việc tồn tại các trạng thái khác nhau giúp phân biệt một thể hiện

(instance) của Grid service với một service khác có cùng interface. Ở đây sẽ sử

dụng khái niệm Grid service instance để chỉ một thể hiện cụ thể của Grid service.

Các service sẽ liên lạc với nhau bằng cách trao đổi các thông điệp. Trong môi

trường phân tán, phức tạp, không thể đảm bảo một thông điệp được gửi đi chắc

chắn đến nơi, do đó cần phải sử dụng một protocol đảm bảo thông điệp gửi đi và tới

nơi.

Các service có thể được tạo và huỷ một cách động. Service có thể bị huỷ tường

minh hoặc bị huỷ, không thể truy cập được do hư hỏng hệ thống, hết tài nguyên. Do

đó, Grid service có các interface để quản lý thời gian sống của mình. Vì các Grid

service được tạo và huỷ một cách động nên cần có cơ chế để phân biệt các instance

khác nhau được tạo ra. Mỗi Grid service instance được gán một tên duy nhất không

trùng với bất kỳ ai, Grid service handle (GSH), GSH dùng để phân biệt một Grid

service instance cụ thể với tất cả các instance khác đã tồn tại, hiện đang tồn tại, và

sẽ được tạo lập trong tương lai.


- 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 iinntteerrffaaccee 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ủa từng instance… Hỗ trợ nhiều ngôn ngữ truy vấn khác nhau.

SetTerminationTime Thiết lập (Lấy) thời gian hủy bỏ của Grid service 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 qua cá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 GSH Registry UnregisterService 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


- 62 -

cung cấp các cơ chế chuẩn để để tạo ra (và sau đó là quản lý) các service instance.

Hosting environment có thể quy định cách thức tạo service instance cụ thể, nhưng

điều này là trong suốt đối với các người dùng service trong OGSA, họ chỉ thấy

interface Factory mà thôi. Một cách khác, trong các môi trường Grid phức tạp, có

thể xây dựng hệ thống các factory phân cấp trong đó các factory cấp cao tạo ra các

service instance bằng cách uỷ quyền qiải quyết yêu cầu tạo lập cho các factory cấp

thấp hơn, để đạt được các yêu cầu cụ thể.

2. Quản lý thời gian sống của service

Việc đưa ra khái niệm các service instance ngắn hạn dẫn đến việc phải xác

định thời gian sống của service, có nghĩa là phải xác định khi nào thì có thể hoặc

cần phải kết thúc service để giải phóng các tài nguyên liên quan. Trong môi trường

hoạt động bình thường, các service instance ngắn hạn được tạo ra để thực hiện một

nhiệm vụ nào đó và kết thúc khi nhiệm vụ hoàn thành hoặc khi có yêu cầu từ client.

Tuy nhiên, trong các hệ thống phân tán, các thành phần có thể không hoạt động, các

thông điệp có thể bị mất nên service instance có thể không bao giờ nhận được thông

báo kết thúc, điều đó khiến nó tồn tại vĩnh viễn, gây lãng phí tài nguyên trong hệ

thống.

OGSA giải quyết vấn đề này bằng cách xác định một thời gian sống cụ thể

cho từng Grid service instance được tạo ra. Thời gian này có thể được mở rộng theo

yêu cầu của client hoặc một Grid service khác đại diện cho client. Nếu hết thời gian

sống mà không nhận được yêu cầu nào để kéo dài thời gian sống thì host

environment hoặc chính Grid service instance có toàn quyền tự kết thúc và giải

phóng tài nguyên.

Việc quản lý thời gian sống được thực hiện thông qua phương thức

SetTerminationTime trong interface GridService.

3. Quản lý các Handle và Reference

Như đã giới thiệu trên đây, factory sau khi tạo service instance sẽ trả về GSH

và GSR. Trong khi GSH là cố định thì GSR được tạo ra với một thời gian sống xác

định và có thể thay đổi trong thời gian sống của service. Trong khi chiến lược này

mang lại khả năng mềm dẻo trong việc xây dựng và bảo trì các service, nhưng cũng


- 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 Grid

instance, 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


- 64 -

HTTP đến URL của home handleMap và GSR của handleMap dưới dạng WSDL

được trả về.

Lưu ý về mối quan hệ giữa các interface HandleMap và Factory khi cài đặt.

GSH trả về từ một factory phải chứa URL của home handleMap service, và ánh xạ

GSH/GSR phải được đưa vào và cập nhật trong handleMap service. Factory cần có

trách nhiệm quyết định xem service nào sẽ là home handleMap.

4. Service Data và Service Discovery

Đi kèm với mỗi Grid service instance là một tập các service data, một tập các

thành phần XML được đóng gói như các thành phần dữ liệu của service. Mỗi thành

phần bao gồm một tên duy nhất trong toàn service instance, một kiểu, thông tin về

thời gian sống để sử dụng để quản lý thời gian sống.

Interface GridService định nghĩa hoạt động WSDL chuẩn, FindServiceData,

phục vụ việc truy vấn và lấy về các service data.

Bản đặc tả về Grid service xác định cho mỗi interface Grid service một tập

các thành phần service data phải được cài đặt trong bất cứ Grid service instance nào

hỗ trợ interface đó. Đi kèm với interface GridService, do đó cũng đi kèm với tất cả

các service instance một tập các thành phần chứa thông tin cơ bản về Grid service

instance, như GSH, GSR, khoá chính, home handleMap.

Một ứng dụng của phương thức FindServiceData là chức năng tìm kiếm

service (service discovery). Những gì được trình bày ở trên giả sử rằng một ai đó đã

có GSH của service mong muốn, làm sao chúng ta lấy được GSH mong muốn lúc

đầu tiên. Đã đến lúc cần dùng đến chức năng service discovery, là một quá trình xác

định một tập các GSH có các thuộc tính thỏa mãn các yêu cầu cụ thể của người

dùng như tải hiện hành, số lượng yêu cầu đã phục vụ, các chính sách hoạt động.

Grid service hỗ trợ chức năng service discovery được gọi là registry. Một

registry service được xác định bởi 2 thứ : một interface Registry, cung cấp các

phương thức để đăng ký các GSH, và các thành phần service data được dùng để lưu

trữ thông tin về các GSH đã đăng ký. Từ đó, interface Registry được sử dụng để

đăng ký một GSH và phương thức FindServiceData của interface GridService dùng

để lấy các thông tin về các GSH đã đăng ký.


- 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.


- 66 -

Hướng tiếp cận này chỉ đơn giản định nghĩa và các định dạng chuẩn cho các

thông điệp lỗi mà không thay đổi mô hình truyền thông điệp lỗi của WSDL.

Định nghĩa chu trình sống (lifecycle) của một Grid service instance.

Phần này sẽ giới thiệu một số điểm chính về các Grid Service được quy định

trong OGSI, các thông tin chi tiết xin xem trong tài liệu tham khảo ...

33..22..44..11.. GGrriidd SSeerrvviiccee DDeessccrriippttiioonn vvàà GGrriidd SSeerrvviiccee IInnssttaannccee

Trước hết cần phân biệt giữa 2 khái niệm service description và service instance

+ Grid Service Description (Bản mô tả về Grid service)

Là một tài liệu WSDL định nghĩa Grid service interface, mô tả cách thức một

client giao tiếp với các service instance, bao gồm các portType, phương thức, khai

báo serviceData, thông điệp, và kiểu. Lưu ý, trong tương lai, có thể sử dụng các

kiểu định dạng khác thay vì WSDL.

Một service description được sử dụng với 2 mục đích chính. Trước hết, với

vai trò một bản mô tả service interface, nó được sử dụng cho các công cụ tự động

phát sinh các client interface proxy, … Thứ hai, nó được sử dụng để tìm kiếm

service, ví dụ như tìm một service instance triển khai một service description nào

đó, hay tìm một factory có khả năng tạo ra các instance với một service description

cụ thể.

+ Grid Service Instance

Là một thể hiện của Grid Service Description như là một thực thể hoạt động.

Một Grid Service Description có thể được sử dụng trong nhiều instance. Mỗi

instance có:

Các trạng thái được mô tả trong service description.

Có một hoặc nhiều Grid Service Handle.

Có một hoặc nhiều Grid Service Reference tham khảo đến nó.

33..22..44..22.. TTiimmee MMooddeell

Do các thành phần tham gia hệ thống Grid có thể nằm trên nhiều vùng thời gian

khác nhau, sử dụng các định dạng biểu diễn thời gian khác nhau, nên cần phải có

mô hình biểu diễn thời gian thống nhất trong toàn bộ hệ thống để đảm bảo đồng bộ


- 67 -

về thời gian. Chuẩn GMT được chọn để sử dụng trong các Grid service, các hosting

environment và client được gợi ý dùng protocol Network Time Protocol (NTP)

hoặc các chức năng tương tự để đồng bộ hoá đồng hồ của mình với thời gian GMT.

Về định dạng biểu diễn thời gian trong các service và thông điệp, OGSI sử dụng

kiểu xsd:dateTime và mở rộng thêm kiểu ExtendedDateTimeType để thay thế

xsd:dateTime trong trường hợp biểu diễn thời gian không xác định.

Định nghĩa ExtendedDateTimeType như sau:

33..22..44..33.. GGrriidd SSeerrvviiccee NNaammiinngg

Chúng ta đã biết các Web service được định vị bằng các Unified Resource

Indicator (URI). Vì các Grid service cũng là Web service nên chúng cũng được xác

định bởi các URI, tuy nhiên trong OGSA, OGSI, một Grid Service URI được gọi là

Grid Service Handle (GSH). Một Grid service instance có một hoặc nhiều GSH.

GSH chỉ là một tên dưới dạng URI, không mang đủ thông tin để client có thể liên

lạc với service instance. Để có thể liên lạc, GSH cần phải được phân giải thành Grid

Service Reference (GSR).

Mỗi GSH phải duy nhất, toàn cục, vĩnh viễn cho một service instance trong hệ

thống Grid. Không thể có 2 service instance có cùng GSH.

GSR chứa tất cả các thông tin cần thiết để client liên lạc với service instance

thông qua một kết hợp của một hoặc nhiều protocol truyền thông mạng (protocol

binding). Cũng giống như URI, GSR có một lược đồ dữ liệu để chứa các thông tin

đặc biệt của mình. Để phân giải GSH thành GSR, client sử dụng cơ chế Handle

Resolver. GSR có thể có nhiều định dạng khác nhau tuỳ vào protocol liên lạc mà

client sử dụng, ví dụ khi sử dụng với RMI/IIOP, GSR có dạng của một IOR, khi sử

dụng với SOAP, GSR là có dạng một tài liệu WSDL. Một service instance cũng có

thể có nhiều GSR tham khảo tới nó, chu trình sống của GSR độc lập với service

… targetNamespace = http://www.gridforum.org/namespaces/2003/03/OGSI <simpleType name="ExtendedDateTimeType">

<union memberTypes="ogsi:InfinityType xsd:dateTime"/> </simpleType> <simpleType name="InfinityType">

<restriction base="string"> <enumeration value="infinity"/>

</restriction> </simpleType>


- 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>

targetNamespace = http://www.gridforum.org/namespaces/2003/03/OGSI <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.. IInntteerrffaaccee

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 định

nghĩa lại thành interface của Grid service (gwsdl:portType) như sau:

targetNamespace = http://www.gridforum.org/namespaces/2003/03/OGSI <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”

minOccurs="0" maxOccurs="unbounded"/> </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"

minOccurs="0" maxOccurs="unbounded"/> </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ần

cung 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 {target namespace}

Tên của serviceData

type QName Xác định kiểu XML Schema quy định giá trị của SDE.

minOccurs nonNegative Integer

unbounded (không giới hạn)

1 Xác định số giá trị SDE nhỏ nhất xuất hiện trong serviceDataValues hoặc staticServiceDataValues, nếu là 0 là tuỳ chọn

maxOccurs nonNegative Integer

unbounded 1 Xác định số giá trị SDE lớn nhất xuất hiện trong serviceDataValues hoặc staticServiceDataValues

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ới value=“true”).

mutability

“static”, “constant”, “extendable”, “mutable”

“extendable”

Quy định cách thức thay đổi một SDE. + “static” : giá trị của SDE được xác định trong thành phần staticServiceDataValues và được giữ lại trong bất cứ instance nào có portType chứa SDE đó. + “constant” : giá trị của SDE được gán trong lúc tạo instance và được giữ không đổi trong suốt thời gian sống của instance. + “extendable” : Cho phép thêm các thành phần mới vào SDE trong thời gian chạy, các thành phần mới khi đã được thêm vào sẽ không thể loại bỏ khỏi SDE đượ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ương thứ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.. LLiiffeeccyyccllee

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ế Notification

chuẩn (các phương thức của các interface NotificationSource/Sink/Subscription)

33..22..44..77.. NNoottiiffiiccaattiioonn

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 ttrrúú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.


- 75 -

GT3 được thiết kế lại để hỗ trợ hoàn toàn OGSI. Tuy nhiên, cần phải chú ý rằng

GT3 không chỉ là một bản cài đặt của OGSI. GT3 bao gồm rất nhiều các dịch vụ,

chương trình, công cụ,…. Một số trong chúng được xây dựng trên OGSI và được

gọi là WS (Web Services) components, một số khác không dựa trên OGSI, được gọi

là pre-WS components.

Bộ GT3, tồn tại song song 2 mô hình kiến trúc như trên hình 3-2. Các nhà phát

triển có thể sử dụng một trong hai mô hình để xây dựng các ứng dụng và các hệ

thống Grid của mình. Tuy nhiên, mô hình Grid service dựa theo OGSI được khuyến

khích sử dụng.

Hình 3-2 Kiến trúc của bộ Globus Toolkit.

33..33..11.. MMôô hhììnnhh kkiiếếnn ttrrúúcc GGTT22

Trong mô hình kiến trúc GT2, có thể thấy rõ ràng 4 thành phần của bộ GT,

GRAM đảm nhận phần Resource Management, MDS đảm nhận phần Information

Service, GridFTP đảm nhận phần Data management (phần truyền dữ liệu). 3 thành

phần này được xây dựng trên nền tảng bảo mật chung là Grid Sercurity

Infrastructure (GSI). Các thành phần được thiết kế theo module, có thể sử dụng độc

lập hoặc phối hợp với nhau thông qua giao diện riêng của từng thành phần.

Mô hình hệ thống Grid sử dụng GT2 như sau :


- 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 kkiiếế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


- 78 -

cách ứng dụng với các cấu hình môi trường thực thi cụ thể. Container cũng điều

khiển chu kỳ sống của các Grid service, và phân phối các yêu cầu đến các service

instance. Container mở rộng cũng như bao gồm các interface chuẩn của một Web

Service Engine (WSE), WSE chịu trách nhiệm xử lý các thông điệp XML.

Web Service Engine và Grid Service Container được đặt trong một Hosting

Environment, chịu trách nhiệm triển khai các chức năng của một Web Server truyền

thống như sử dụng protocol vận chuyển HTTP,… Hiện nay GT3 Service Container

có thể chạy trên các hosting environment sau:

+ Embedded Container: là một hosting environment được sử dụng chủ

yếu trong các client hay các server hạng nhẹ, cho phép tạo lập và quản lý các Grid

service instance.

+ Stand-alone Container: cơ bản dựa trên embedded hosting

environment cùng với một command-line đầu cuối, cho phép khởi động và kết thúc

hosting environment. GT3 có 2 lệnh để thực hiện việc này : globus-start-

container, globus-stop-container.

+ J2EE Web Container (Servlet) : Là embedded hosting environment

chạy trong một Java engine (Web container) như Tomcat. Web container này sử

dụng các Web service cung cấp bởi Java engine thay các service chuẩn cung cấp bởi

GT3.

+ J2EE Enterprise JavaBeans Container (EJB) : Là embedded

hosting environment chạy trong một EJB application server (EJB container) như

WebSphere Application Server.

Chi tiết các thành phần và sự khác biệt giữa cùng một thành phần trong 2 kiến

trúc sẽ được giới thiệu ở phần sau.


- 79 -

33..44.. CCáácc tthhàànnhh pphhầầnn cchhíínnhh

33..44..11.. SSeerrccuurriittyy IInnffrraassttrruuccttuurree


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àà kkhháá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 (bao

gồ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.


- 82 -

Hệ thống khoá công khai thực hiện bảo mật hai lần trên thông điệp trao đổi

giữa các bên. Trước hết, bên gửi sẽ mã hóa thông điệp bằng khóa bí mật của mình,

sau đó mã hoá tiếp lần nữa bằng khóa công khai của bên nhận. Khi nhận được thông

điệp, bên nhận sẽ thực hiện giải mã bằng khóa bí mật của mình trước, sau đó tiếp

tục giải mã bằng khóa công khai của bên gửi. Bằng cách này, không ai khác có thể

đọc được thông điệp trừ khi có được khóa bí mật của một bên, nhưng điều này rất

khó thực hiện được vì hai bên gửi và nhận không trao đổi khóa cho nhau, và khóa bí

mật được giữ ở mỗi bên.

Các thuật toán phát sinh khóa bí mật và khóa công khai được thiết kế sao cho

một thông điệp được mã hoá bởi một khoá thì chỉ có thể được giải mã bởi khoá còn

lại tương ứng, và không thể giải mã bởi khoá dùng để mã hoá. Các cặp khoá được

phát sinh bằng cách tìm 2 số nguyên tố cực lớn khác nhau. Ngay cả khi khóa công

khai được để công khai rộng rãi, cũng rất khó để các máy tính hiện nay có thể tìm ra

khóa bí mật từ khóa công khai. Các thuật toán này tăng độ tin cậy về bảo mật nhưng

lại tốn rất nhiều thời gian để mã hóa, đặc biệt là khi phải mã hóa một lượng lớn dữ

liệu. Do đó, trong thực tế, người chỉ dùng phương pháp public key encryption để

trao đổi khóa của phương pháp symmetric encryption giữa hai bên, và sau đó, việc

mã hoá/giải mã được sử dụng bằng khoá symmetric này.

+ Distinguished Name (DN)

Distinguished Name là một chuỗi ký tự duy nhất dùng để định danh người

dùng (người dùng có thể là một người hay một thực thể ) trong Grid, có thể nói DN

là một “Grid username”. DN là một thành phần của chứng chỉ điện tử. Phần lớn

thông tin trong DN là do CA cung cấp.

+ Digital certificates (Chứng chỉ điện tử)

Chứng chỉ điện tử là một tài liệu điện tử chứa thông tin định danh tài nguyên,

người dùng Grid và khóa công khai tương ứng. Một chứng chỉ điện tử là một cấu

trúc dữ liệu chứa khóa công khai và các thông tin chi tiết về chủ của khóa công khai

đó. Một chứng chỉ được xem như là một thẻ nhận dạng điện tử không thể làm giả

sau khi đã được đóng dấu bởi CA trong môi trường Grid.


- 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ấp

chứ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êm

mộ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ện

quy 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ợp

lệ, 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


- 92 -

công việc dưới tên của chủ proxy, đây có thể là một điểm yếu để khai thác, tấn

công. Do đó, để tránh việc tấn công kiểu giả dạng này, nên có những chính sách

giới hạn khả năng của proxy.

+ Cơ chế bảo mật liên lạc trong GSI

Việc bảo mật truyền thông trong GSI dựa trên hai công nghệ là : Mutual

authentication (chứng thực lẫn nhau) và SSL/TLS. Các chứng chỉ điện tử trên các

Grid host cho phép thực hiện chứng thực lẫn nhau giữa hai bên tham gia truyền

thông. Các chức năng SSL/TLS được cung cấp bởi OpenSSL được sử dụng để mã

hoá tất cả các dữ liệu vận chuyển qua lại giữa các host.

33..44..11..44.. SSửử ddụụnngg GGSSII

+ Các file quan trọng

Khi cài đặt GT3, có các file cấu hình quan trọng để sử dụng GSI như sau:

Thư mục File Diễn giải

hostcert.pem Là server certificate được sử dụng

trong mutual authentication

hostkey.pem Khóa bí mật tương ứng với server

certificate.

/etc/Grid-security

Grid-mapfile File ánh xạ giữa tên người dùng

Grid (subject hay DN) với người

dùng cục bộ.

CA certificate /etc/Grid-

security/certificates ca-signing-policy.conf

usercert.pem Certificate của người dùng (subject

name,khóa công khai, chữ ký của

CA)

$HOME/.globus

userkey.pem Khóa bí mật của user certificate

(được mã hóa bằng passphare).

Bảng 3-3 Các file cấu hình GSI của GT3.

+ Các công 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ương

trì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ểm tra checksum và giải mã nó, đưa vào vùng đệm xuấ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.. RReessoouurrccee 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àn

chỉ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.


- 95 -

Hình 3-10 Kiến trúc quản lý tài nguyên trong Globus Toolkit.

Trong kiến trúc này, ngôn ngữ Resource Specification Language (RSL),

được sử dụng để trao đổi các yêu cầu về tài nguyên giữa các thành phần: từ ứng

dụng (application) đến resource broker, resource co-allocator và resource manager.

Tại mỗi bước của quá trình này, các thông tin về yêu cầu tài nguyên được đặc tả

trong chuỗi RSL của ứng dụng hay được xây dựng lại bởi một hay nhiều resource

broker và co-allocator. Thông tin về khả năng, tính sẵn sàng, tính chất của các tài

nguyên có thể lấy từ một Information service

Resource broker chịu trách nhiệm chuyển đổi từ một đặc tả RSL cấp cao

thành các đặc tả RSL chi tiết hơn qua quá trình chi tiết hoá. Nhiều broker có thể

phối hợp với nhau để cùng giải quyết một yêu cầu về tài nguyên, một số broker

chuyển các yêu cầu của ứng dụng thành các yêu cầu chi tiết hơn về tài nguyên, rồi

một số broker khác định vị các tài nguyên thoả yêu cầu. Bản đặc tả chi tiết về vị trí

các tài nguyên, có thể được chuyển cho một resource co-allocator, đây là module

chịu trách nhiệm phối hợp và quản lý tài nguyên trên nhiều site.

Resource co-allocator thực hiện chia nhỏ các yêu cầu tài nguyên trên nhiều

site thành từng thành phần nhỏ và chuyển chúng đến resource manager thích hợp.

Mỗi Resource manager trong hệ thống chịu trách nhiệm lấy yêu cầu trong

RSL và chuyển nó thành các thao tác thực hiện trên hệ thống quản lý tài nguyên cục

bộ của site.


- 96 -

Information service chịu trách nhiệm cung cấp khả năng truy cập hiệu quả

và rộng khắp đến các thông tin về khả năng và tính sẵn sàng hiện tại của các tài

nguyên. Thông tin này dùng để định vị các tài nguyên với các đặc tính cụ thể, để

xác định Resource Manager liên kết với tài nguyên, xác định tính chất của tài

nguyên, và phục vụ cho rất nhiều mục đích trong quá trình biên dịch từ đặc tả yêu

cầu tài nguyên cấp cao thành các yêu cầu đến các resource manager cụ thể. Thành

phần Information Service sẽ được giới thiệu cụ thể ở phần sau.

Mô hình trên đã giải quyết được các vấn đề:

1. Quản lý được các tài nguyên không đồng nhất, đa dạng trong nhiều

vùng quản trị khác nhau, thông qua module Resource Manager. Resource

Manager một mặt cung cấp một giao diện chung thống nhất để sử dụng tài

nguyên, che đi sự phức tạp của tài nguyên; một mặt tương thích với từng

công cụ quản lý tài nguyên, các chính sách, các cơ chế bảo mật cục bộ.

2. Để điều khiển trực tuyến và mở rộng các chính sách, RSL được định

nghĩa để hỗ trợ trao đổi, tìm kiếm giữa các thành phần khác nhau trong kiến

trúc.

3. Sử dụng các resource broker để thực hiện chuyển đổi, ánh xạ các yêu

cầu cấp cao của ứng dụng thành các yêu cầu cụ thể đến các resource

manager. Điều này giảm bớt độ phức tạp cho người dùng khi đặc tả các tài

nguyên cần dùng.

4. Giải quyết vấn đề phối hợp cấp phát (co-allocation) bằng cách xác định

nhiều chiến lược khác nhau, gói gọn, tích hợp trong các resource co-

allocator.

2. GRAM

Grid Resource Allocation and Management (GRAM) là thành phần ở tầng

thấp nhất trong mô hình trên, thành phần quản lý tài nguyên cục bộ (resource

management). GRAM giúp đơn giản hoá việc sử dụng các hệ thống, tài nguyên ở xa

bằng cách cung cấp một giao diện chuẩn, đơn giản để yêu cầu và sử dụng các tài

nguyên để thực thi các công việc. GRAM xử lý các yêu cầu về tài nguyên để thực

thi các ứng dụng từ xa, cấp phát các tài nguyên cần thiết, thực thi và quản lý trạng


- 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ấu

trú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. UnSubmitted

Cô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 GGRRAAMM

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


- 102 -

LDAP protocol : Cung cấp các hàm giao tiếp với hệ thống quản lý tài

nguyên thông qua GIIS Server

Tên hàm Diễn giải globus_gram_client_job_request() Yêu cầu thực hiện một công việc

trên tài nguyên ở xa. globus_gram_client_job_status() Kiểm tra trạng thái của công việc. globus_gram_client_job_cancel() Huỷ công việc. globus_gram_client_job_signal() Gửi các tín hiệu điều khiển job

manager globus_gram_client_callback_allow() globus_gram_client_callback_disallow()

Tạo/Huỷ cổng kết nối để nhận các thông tin callback.

globus_gram_client_callback_check() Thực hiện gọi hàm cục bộ khi có thông tin callback.

globus_gram_client_job_callback_register() globus_gram_client_job_callback_unregister()

Đăng ký và huỷ đăng với job manager để nhận thông tin callback.

globus_duroc_runtime_barrier()

Tất cả các tiến trình trong một công việc của DUROC đều phải gọi hàm này, nó chờ cho đến khi tất cả các tiến trình được giải phóng.

globus_duroc_runtime_inter_subjob_*() globus_duroc_runtime_intra_subjob_*()

Quản lý các công việc con của một DUROC công việc .

ldap_open (string server, int port) Mở một kết nối theo LDAP protocol

ldap_search_s(ldapsever, …, char* filterstring, …)

Tìm kiếm máy tính trong hệ thống thỏa điều kiện trong câu truy vấn filterstring

… Bảng 3-6 Bảng các hàm API của pre-WS GRAM.

Ghi chú: Thông tin chi tiết về lập trình với preWS-GRAM, xin tham khảo tài

liệu [22] và website : www.globus.org.

33..44..22..33.. WWSS--GGRRAAMM

1. Các đặc điểm chính

- Cung cấp các service theo chuẩn OGSI phục vụ thực thi các công việc trên

các site ở xa.


- 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 DN

củ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.. IInnffoorrmmaattiioonn 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ình

quả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ơn

có 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 IInnffoorrmmaattiioonn 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 Resource

Information 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 đó.


- 110 -

Hình 3-19 là một ví dụ:

Hình 3-17 Mô hình tổ chức dữ liệu phân cấp trong MDS2.

Giải thích hình 3-17: Ở đây, có 2 trung tâm và một cá nhân (O1,O2,R) đang đóng góp

tài nguyên vào một VO, có 3 Aggregate Directory Service tạo nên một dịch vụ thư mục phân cấp

để thể hiện cấu trúc logic này. Lưu ý về cách đặt tên tài nguyên, cho phép tìm kiếm toàn cục lẫn

cục bộ.

Ngôn ngữ truy vấn giúp tìm kiếm, tra cứu, và yêu cầu cung cấp thông tin

định kỳ dài hạn về tài nguyên. Một bộ lọc luôn luôn được sử dụng để xác định các

tiêu chí cần thoả, từ đó chỉ có một tập nhỏ các thuộc tính cần thiết được lấy về, giúp

giảm thiểu thông tin cần truyền trên mạng.

MDS sử dụng các chuẩn định dạng dữ liệu và các hàm API của LDAP để

giải quyết vấn đề quản lý thông tin tài nguyên. Hình 3-18 mô tả hoạt động tổng quát

của các thành phần MDS. Như hình vẽ, các thông tin về tài nguyên được lấy bởi các

Information Provider và được chuyển đến GRIS. Sau đó GRIS sẽ đăng ký các thông

tin về tài nguyên đang quản lý cho GIIS, GIIS này cũng có thể đăng ký thông tin

cho GIIS cấp cao hơn và cứ thế. Các MDS client có thể lấy thông tin trực tiếp từ

GRIS (đối với các tài nguyên cục bộ) và/hoặc từ GIIS (cho các tài nguyên trải rộng

trong Grid).


- 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 IInnffoorrmmaattiioonn 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ên

quan 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 Spec Implementation

Triển khai cài đặt tất cả các interface do OGSI xác định.

Security Infrastructure

Thành phần này hỗ trợ bảo mật cấp thông điệp, chứng thực và 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 hosting environment.

Logging Management Service

Cho phép sửa đổi các log filter và nhóm các thông tin log để dễ theo dõi và quản lý.

System level services

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ác service, cho phép huỷ, kích hoạt các service 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 ttrriiểể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ên

Grid.

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ột

hệ đ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 kkhhảả tthhii ccủủaa ứứnngg ddụụnngg kkhhii 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ột

danh 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.. KKhhảả 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


- 119 -

Cần phải có các chính sách phân quyền để cho phép người dùng chỉ thực

hiện được các hoạt động được quy định trước. Việc này có thể thực hiện bằng cách

viết mã trong ứng dụng hay ủy quyền cho một hệ thống phân quyền khác.

+ Mã hóa dữ liệu

Các thông tin nhạy cảm kể cả các thông tin người dùng đều phải được mã

hóa trước khi truyền đi. Có thể sử dụng lại các chức năng của một hệ thống PKI có

sẵn.

+ Logging và báo động

Cần phải ghi lại các sự kiện quan trọng trong quá trình hoạt động của ứng

dụng. Việc phân tích các thông tin này theo thời gian thực hay sau đó rất hữu ích để

phát hiện các lỗi của ứng dụng, các cố gắng tấn công hệ thống,…

44..22..33.. TTíínnhh mmềềmm ddẻẻoo ccủủaa ứứnngg ddụụnngg ((FFlleexxiibbiilliittyy))

Một hệ thống hầu như sẽ không bao giờ được viết lại, để đáp ứng nhu cầu vá lỗi,

hoặc thêm các chức năng mới, ứng dụng cần phải được thiết kế với tầm nhìn hướng

tới tương lai, để khi cần thực hiện các công việc trên thì sẽ không ảnh hưởng nhiều

đến thiết kế hệ thống hiện tại. Nên sử dụng các mẫu thiết kế hướng đối tượng, tận

dụng các khả năng của phương pháp lập trình hướng đối tượng, thiết kết hỗ trợ khả

năng plug-in để giải quyết yêu cầu này.

44..22..44.. CCáácc kkếếtt nnốốii vvớớii bbêênn nnggooààii

Hầu hết các hệ thống đều cần thực hiện kết nối đến các hệ thống khác để trao đổi

dữ liệu. Nếu các vấn đề trao đổi dữ liệu không được định nghĩa rõ ràng, chính xác,

sẽ ảnh hưởng rất lớn đến việc thực thi cũng như hiệu năng của hệ thống. Trước khi

phát triển ứng dụng, cần phải lập danh sách các hệ thống bên ngoài cần giao tiếp và

thỏa thuận với các bên liên quan nhằm xác định các phương thức liên lạc, định dạng

gói dữ liệu, các vấn đề chứng thực, phân quyền, … Khi các bên đều đồng ý về tất cả

các khía cạnh cần thiết thì mới phát triển ứng dụng.


- 120 -

44..22..55.. HHiiệệuu ssuuấấtt ứứnngg ddụụnngg((PPeerrffoorrmmaannccee))

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


- 121 -

dụng đang chạy trên một máy ở xa. Do đó cần tính toán đến việc để các ứng

dụng cần trao đổi “gần” với nhau, và các ứng dụng “gần” với dữ liệu cần xử lý

(“gần” theo nghĩa khoảng cách trong mạng) cùng với xem xét về tốc độ, độ trễ

và năng lực của hệ thống mạng khi phát triển ứng dụng.

2. Thiếu tối ưu trong ứng dụng

Việc tối ưu hiệu suất ứng dụng có thể thực hiện được bằng cách chuyển

đổi và tối ưu ứng dụng trên các hệ điều hành và cấu hình phần cứng cụ thể. Việc

này có thể giải quyết bằng cách các nhà cung cấp dịch vụ thỏa thuận với các nhà

cung cấp tài nguyên để cung cấp các tài nguyên và cấu hình tối ưu nhất cho việc

thực thi ứng dụng.

3. Tranh giành tài nguyên

Việc tranh giành tài nguyên thường là một vấn đế đối với các tài nguyên

chia sẻ. Nếu việc này ảnh hưởng nghiêm trong đến hiệu suất ứng dụng thì cần

phải đưa thêm các tài nguyên vào hệ thống. Ví dụ như khi một cơ sở dữ liệu là

mục tiêu của việc tranh giành thì cơ chế nhân bản thêm một cơ sở dữ liệu có thể

được áp dụng để giải quyết vấn đề. Việc tối ưu chia sẻ có thể đạt được bằng cách

sử dụng các thuật toán lập lịch và cân đối tải công việc thích hợp.

4. Độ tin cậy của hệ thống mạng

Việc hư hỏng các tài nguyên Grid và hệ thống mạng có thể gây trễ vô

thời hạn. Để đảo bảo thực thi công việc một các tin cậy, ứng dụng cần phải có

các cơ chế phục hồi lỗi để đối phó với các hư hỏng khác nhau.

Vì các thành phần hình thành nên Grid có thể thay đổi trong thời gian thực thi,

nên sẽ rất khó khăn trong việc dự đoán thời gian đáp ứng yêu cầu, do đó cần thực

hiện trao đổi thảo luận giữa các bên để đưa ra các yêu cầu hiệu suất cụ thể có thể

chấp nhận được.

44..22..66.. ĐĐộộ ttiinn ccậậyy ((RReelliiaabbiilliittyy))

Độ tin cậy của ứng dụng là một vấn đề của các công nghệ tính toán, và với Grid

cũng không là ngoại lệ. Phương pháp tốt nhất để giải quyết vấn đề khó khăn này là


- 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.


- 123 -

44..22..88.. ĐĐồồ hhììnnhh hhệệ tthhốốnngg ((SSyysstteemm TTooppoollooggyy))

Grid có bản chất là phân tán, mở rộng trên nhiều tổ chức, nhiều vùng địa lý khác

nhau, nhất là khi chuyển từ đồ hình IntraGrid lên InterGrid, độ phức tạp tăng lên rất

nhiều. Do đó, cần phải quan tâm đến đồ hình hệ thống để có thể đưa ra thiết kế tốt.

Dưới đây là một số vấn đề cần xem xét:

+ Đồ hình mạng

Đồ hình mạng trong một hệ thống Grid có thể có nhiều hình dạng khác nhau.

Các thành phần mạng có thể đại diện cho mạng LAN, các kết nối trong một tổ chức,

hay các kết nối WAN giữa các mạng Grid. Hệ thống mạng chịu trách nhiệm cung

cấp băng thông cần thiết cho các hệ thống Grid. Cũng như các thành phần khác, hệ

thống mạng cũng có thể được cấu hình để hoạt động tốt hơn. Thiết kế đồ hình mạng

chịu ảnh hưởng của các giới hạn về bảo mật và mô hình triển khai hệ thống. Ví dụ,

với Data Grid, có các tài nguyên lưu trữ trải rộng, vấn đề thiết kế hệ thống mạng để

hỗ trợ tải một lưu lượng lớn dữ liệu là một yêu cầu then chốt để đảm bảo thành công

của toàn hệ thống. Các xem xét khi phát triển ứng dụng nên bao gồm các chiến lược

giảm thiểu các lưu thông mạng và độ trễ của mạng.

+ Đồ hình dữ liệu

Mục tiêu của thiết kế cần phải cố gắng để các công việc thực thi gần với dữ

liệu cần xử lý nhất có thể được. Điều này sẽ làm giảm các lưu thông mạng.

Dữ liệu thì cần các vùng lưu trữ, nên thiết kế để Grid có khả năng lưu trữ liên

tục. Hệ thống lưu trữ cần phải được quản lý, bảo vệ, sao lưu dự phòng và/hoặc nhân

bản mới. Trong thiết kế, cần phải đảm bảo dữ liệu luôn luôn sẵn sàng cho các công

việc cần đến nó. Bên cạnh đó, cần phải tăng hiệu suất truy cập dữ liệu, điều này

thường dựa trên băng thông mạng và khoảng cách đến nguồn dữ liệu. Đối với các

ứng dụng liên quan nhiều đến dữ liệu, nên tập trung nhiều nỗ lực vào thiết kế vị trí

các tài nguyên lưu trữ, cũng như nâng cao khả năng dự phòng, chịu đựng lỗi.

44..22..99.. MMôôii ttrrưườờnngg đđaa nnềềnn ttảảnngg

Môi trường Grid là một tập hợp các host hỗn tạp với nhiều loại hệ điều hành,

phần mềm khác nhau. Để thực thi một ứng dụng, cơ sở hạ tầng Grid cần phải biết


- 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 ffiillee

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ều

kiện cho người dùng hoàn thành tác vụ càng nhanh càng tốt.

+ Các yêu cầu về tính tiện dụng của một giải pháp Grid

Một giải pháp Grid phải đạt được các yêu cầu về tính tiện dụng cho nhiều

loại người dùng khác nhau như :

Người dùng cuối : Đăng nhập vào Grid, gọi thực thi ứng dụng, truy

vấn các trạng thái, và xem kết quả trả về.

Chủ/người dùng của các máy tính tham gia Grid.

Các nhà quản trị hệ thống.

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 đó.


- 126 -

Để xây dựng ứng dụng, trước hết cần xác định hết tất cả các service của hệ

thống, bao gồm các service cần cung cấp ra bên ngoài, các service hỗ trợ hoạt động

của hệ thống. Cần xác định hết các phương thức (tham số và kiểu trả về), dữ liệu

của service (SDE), các cơ chế thông báo, chu kỳ sống của service cũng như các kịch

bản trao đổi, sử dụng giữa các service. Khi đã có mô hình các service và cách thức

liên lạc giữa chúng, cần kiểm tra, chỉnh sửa để mô hình đáp ứng được các yêu cầu

chức năng, phi chức năng của ứng dụng.

Sau khi hoàn thành mô hình tổng quan, việc tiếp theo là thiết kế chi tiết hoạt

động của các service.

44..44.. MMộộtt ssốố vvấấnn đđềề ccầầnn qquuaann ttââmm ttrroonngg tthhiiếếtt kkếế cchhii

ttiiếếtt vvàà vviiếếtt mmãã Việc thiết kế, viết mã cho ứng dụng Grid cũng tương tự như cho các ứng dụng

truyền thống. Phần này trình bày một số vấn đề cần quan tâm khi thiết kế chi tiết

hoạt động, viết mã của một ứng dụng Grid. Dưới đây là một số khái niệm được

dùng trong phần này:

Ứng dụng Grid (Grid Application) : Là một tập các công việc để giải quyết

các vấn đề cụ thể hoặc để đạt đến một kết quả mong đợi bằng các sử dụng hạ

tầng Grid.

Công việc (Job): Là một đơn vị cơ sở trong ứng dụng Grid, thường được

yêu cầu thực thi trên một node của Grid, có các tập dữ liệu đầu vào và đầu ra

cùng với các yêu cầu về môi trường thực thi để hoàn thành nhiệm vụ của nó.

Một công việc có thể chạy một hay nhiều tiến trình trên một host.

Trình sản xuất/tiêu thụ dữ liệu (Data Producer/Consumer) : Các công

việc tạo ra dữ liệu kết quả được gọi là trình sản xuất dữ liệu, và các công việc

nhận vào dữ liệu được gọi là trình tiêu thụ dữ liệu.


- 127 -

44..44..11.. KKiiếếnn ttrrúúcc ứứnngg ddụụnngg

Phần này sẽ xem xét các luồng công việc trong một ứng dụng Grid. Một ứng

dụng Grid có thể có rất nhiều công việc. Các ứng dụng truyền thống được thực thi

trong một môi trường với các tài nguyên đã biết trước, ở đây chúng ta sẽ xem xét

việc một ứng dụng chạy trong một môi trường nơi mà các tài nguyên được cấp phát

động theo nhu cầu. Nếu muốn sử dụng đồng loạt các tài nguyên Grid, chúng ta cần

xem xét việc xử lý dữ liệu có thể được thực hiện song song hay không, hay phải

thực hiện tuần tự và một công việc có cần phải chờ lấy dữ liệu từ một công việc

khác hay không. Kết quả là chúng ta sẽ có một mạng các tiến trình trong ứng dụng.

Khi thiết kế cần xem xét các luồng công việc mà chọn giải pháp thiết kế tối ưu.

Ở đây chúng ta cần phân biệt hai khái niệm : luồng ứng dụng (application flow)

và luồng công việc (job flow). Luồng ứng dụng là trình tự thực thi các công việc tạo

nên ứng dụng, trình tự thực thi các xử lý trong nội bộ công việc được gọi là luồng

công việc. Có 3 kiểu luồng ứng dụng cơ bản : Song song, tuần tự và mạng.

+ Luồng song song (parallel flow)

Nếu một ứng dụng có nhiều công việc có thể được thực thi song song, một

Grid rất thích hợp để thực thi ứng dụng hiệu quả trên các node dành riêng, đặc biệt

trong trường hợp không có (hoặc có rất ít) việc trao đổi dữ liệu của các công việc.

Từ một công việc khởi đầu, các công việc sẽ đồng loạt được gửi đi và yêu cầu thực

thi trên các node được chọn trước hoặc được cấp phát động trong Grid. Mỗi công

việc có thể nhận các dữ liệu dành riêng cho mình, thực hiện tính toán một cách độc

lập rồi gửi kết quả về. Các kết quả được tập hợp bởi một công việc khác hay lưu trữ

vào cơ sở dữ liệu. Các dịch vụ của Grid như broker hay trình lập lịch, có thể được

sử dụng để gửi thực thi mỗi công việc vào thời điểm và địa điểm tốt nhất trong

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


- 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ấy

trên hình 4-3. Các kỹ thuật sau có thể áp dụng để giải quyết vấn đề.

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

1. Loose coupling (Giảm bớt sự phụ thuộc)

Kỹ thuật này cần có thêm một dịch vụ quản lý luồng ứng dụng để đồng

bộ các công việc, sẽ làm giảm việc trao đổi liên tiến trình và làm giảm quá tải

trên Grid.

Với những ứng dụng dạng này, cần phân tích kỹ để xác định cách tốt nhất

để tách ứng dụng thành các công việc nhỏ hơn nhằm tăng tính song song. Ở đây

cũng cần phải đưa vào Grid các dịch vụ mới như broker hay trình lập lịch. Có

thể phải tốn thêm chi phí bước đầu, nhưng khi mọi thứ đã ổn định, ứng dụng có

thể được hưởng lợi lớn từ một môi trường tính toán ảo mềm dẻo và tối ưu.

2. Jobs and sub-jobs (Công việc và các công việc con)


- 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ôi

trường thực thi bằng các xem xét đến vị trí các tài nguyên, dữ liệu, và tập các node

mà ứng dụng có thể thực thi.

44..55.. TTrriiểểnn kkhhaaii ccààii đđặặtt ccáácc GGrriidd SSeerrvviiccee 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 kkhhaaii 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 Grid

service. Có 2 cách để định nghĩa interface cho MathService :

+ Tự viết file GWSDL đặc tả.

+ Sử dụng công cụ tự động phát sinh file GWSDL từ giao diện lớp

của Java.

Mỗi cách đều có những ưu khuyết điểm riêng, nếu phát sinh từ khai báo lớp Java

thì chúng ta chỉ cần khai báo :

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

Tuy nhiên, khi phát sinh bằng cách này sẽ không tận dụng hết tất cả các sức

mạnh của GWSDL. Do đó nên tự viết các đặc tả interface cho service bằng

GWSDL. Chi tiết về cách viết một tài liệu GWSDL xin tham khảo thêm trong phụ

lục B – Định dạng file GWSDL. Lưu ý, ở đây các hàm add() và substract() chỉ có

một tham số, chúng ta muốn thực hiện cộng dồn các số và chỉ gửi kết quả đến người

dùng khi cần thiết, qua hàm getValue(). Ví dụ này muốn cho thấy Grid service là

một thực thể có trạng thái (stateful), nó tự lưu trữ các kết quả qua một biến cục bộ

và chỉ xuất ra khi cần thiết, đây là một tính chất mới mà một Web service truyền

thống không có được.


- 135 -

Dưới đây là đặc tả (đã được rút gọn) của file GWSDL, chi tiết nằm trong

file: $GRIDSER_DEMO/schema/progtutorial/MathService/Math.gwsdl

---------------- <definitions ………………………………………… name="MathService" http://www.globus.org/namespaces/2004/02/progtutorial/MathService …………………………………………   ………………………………………………………  <message name="AddInputMessage"> <part name="parameters" element="tns:add"/> </message> <message name="AddOutputMessage"> <part name="parameters" element="tns:addResponse"/> </message> <message name="SubtractInputMessage"> <part name="parameters" element="tns:subtract"/> </message> <message name="SubtractOutputMessage"> <part name="parameters" element="tns:subtractResponse"/> </message> <message name="GetValueInputMessage"> <part name="parameters" element="tns:getValue"/> </message> <message name="GetValueOutputMessage"> <part name="parameters" element="tns:getValueResponse"/> </message>  <gwsdl:portType name="MathPortType" extends="ogsi:GridService"> <operation name="add"> <input message="tns:AddInputMessage"/> <output message="tns:AddOutputMessage"/> <fault name="Fault" message="ogsi:FaultMessage"/> </operation> <operation name="subtract"> <input message="tns:SubtractInputMessage"/> <output message="tns:SubtractOutputMessage"/> <fault name="Fault" message="ogsi:FaultMessage"/> </operation> <operation name="getValue"> <input message="tns:GetValueInputMessage"/> <output message="tns:GetValueOutputMessage"/> <fault name="Fault" message="ogsi:FaultMessage"/> </operation> </gwsdl:portType> </definitions>


- 136 -

Mặc dù GWSDL là độc lập với ngôn ngữ lập trình, tuy nhiên cũng cần phải

tham khảo đặc tả này khi lập trình với ngôn ngữ cụ thể (ở đây là Java), điều này

được thực hiện thông qua các lớp cuống (stub class, khái niệm này được thừa kế từ

Web service), các lớp cuống này được phát sinh tự động bởi các công cụ GT3. Việc

cần làm là thực hiện ánh xạ giữa không gian tên(namespace) của GWSDL với các

gói(package) của Java, thông qua một file ánh xạ (mapping file) như sau :

File : $GRIDSER_DEMO/namespace2package.mappings

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

Bước 2 : Viết mã thực thi cho service

Sau khi định nghĩa interface cho service, bước tiếp theo là thực hiện cài đặt

interface trong một ngôn ngữ lập trình cụ thể (Java). GT3 cung cấp 2 cách để thực

hiện việc cài đặt một interface cho service:

+ Viết một lớp kế thừa từ lớp GridServiceImpl, đây là lớp cơ sở của tất cả

các Grid Service, lớp kế thừa chỉ cần cài đặt tất cả các phương thức định nghĩa

trong file GWSDL. Lớp này cũng có thể có các phương thức, thuộc tính riêng

của mình.

+ Sử dụng khả năng ủy quyền để viết các lớp cài đặt interface của

service. Kỹ thuật này sẽ được trình bày chi tiết trong phần sau : Operation

Provider.

Phần này trình bày kỹ thuật cài đặt sử dụng tính kế thừa. Mã nguồn của file : $GRIDSER_DEMO/org/globus/progtutorial/services/core/first/impl/Ma

thImpl.java

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


- 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.MathServiceGridLocator; 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 ttrrịị mmạạnngg vvàà ccáácc hhệệ tthhốốnngg

qquuảảnn ttrrịị

55..11.. QQuuảảnn ttrrịị 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.


Khái niệm Quản trị mạng (network management) được hiểu theo nhiều cách

khác nhau tuỳ mỗi người và vị trí của họ. Trong một số trường hợp, nó có thể là

hình ảnh một người tư vấn đang theo dõi các hoạt động mạng với một chương trình

phân tích protocol (protocol analyser). Một trường hợp khác, Quản trị mạng liên

quan đến một cơ sở dữ liệu phân tán, tự động thăm dò các thiết bị mạng, các máy

trạm để phát sinh những mô hình đồ hoạ thời gian thực về lưu thông trên mạng hay

những thay đổi trong đồ hình mạng (network topology).

Nói chung, “Quản trị mạng là một dịch vụ sử dụng kết hợp nhiều công cụ,

ứng dụng, và thiết bị để hỗ trợ những người quản trị mạng trong việc kiểm

tra, theo dõi, điều khiển, bảo trì các hệ thống mạng”.

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ình

khái niệm diễn tả 5 lĩnh vực chức năng chính của công việc quản trị mạng là quản lý

hiệu năng, quản lý cấu hình, quản lý sử dụng, quản lý lỗi và quản lý bảo mật. Dưới

đây giới thiệu sơ nét một số lĩnh vực cần quan tâm.

55..11..22..11.. QQuuảảnn llýý hhiiệệuu nnăănngg ((PPeerrffoorrmmaannccee 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 ttrrịị 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ày

thường chứa một agent.

3. Agent

Thường trú trên thiết bị cần quản trị. Cung cấp thông tin về thiết bị cần

quản trị cho ứng dụng quản trị mạng và có thể tiếp nhận và thực hiện các thông

tin điều khiển. Các chức năng cơ bản của một agent:

+ Cung cấp thông tin trạng thái của thiết bị.

+ Số liệu thống kê về các network interface của thiết bị.

+ Cung cấp một giao diện để cấu hình thiết bị.

+ Có khả năng phát hiện lỗi trên thiết bị và báo cáo cho module quản trị.

+ Có khả xác nhận người dùng và bảo mật để đảm bảo chỉ có module

quản trị với các quyền thích hợp mới có thể thực hiện các chức năng trên.

4. Proxy

Là các thực thể cho phép quản lý thông tin của các thực thể khác, có vai

trò là người đại diện cho các thực thể khác trước module quản trị.

5. Network management protocol

Protocol dùng để trao đổi thông tin giữa module quản trị và agent. Hai

protocol được sử dụng nhiều nhất trong hệ thống mạng:

+ Simple NetworkManagement Protocol (SNMP) : sử dụng rộng rãi

trong môi trường mạng LAN


- 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 động

như ý 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 IInnttrruussiioonn DDeetteeccttiioonn SSyysstteemm ((IIDDSS))


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ớn

cá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ỗỗ ttrrợợ qquuảảnn ttrrịị

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.

+ …


- 152 -

Ethereal hiện nay chỉ có thể bắt các packet lưu thông trong một segment mạng

(giữa các máy tính có cùng địa chỉ mạng con với máy tính chạy Ethereal), không

thể sử dụng phân tích, cung cấp thông tin trong các mạng lớn được.

Ghi chú: Thông tin chi tiết về Ethereal, xin tham khảo tại Website :

http://www.ethereal.com và tài liệu hướng dẫn sử dụng Ethereal [25] .

55..44..22.. SSnnoorrtt

Là một hệ thống IDS mã nguồn mở tốt nhất hiện nay, có khả năng thực hiện

phân tích và ghi nhận thông tin packet lưu thông trong hệ thống mạng theo thời gian

thực. Nó có thể thực hiện phân tích theo protocol và tìm kiếm nội dung để phát hiện

nhiều loại tấn công khác nhau như : làm tràn bộ đệm (buffer overflow), quét cổng

(scan port), khai thác điểm yếu hệ điều hành, tấn công từ chối dịch vụ và rất nhiều

dạng tấn công khác.

Snort sử dụng một ngôn ngữ đặc tả luật mềm dẻo để mô tả các lưu thông mạng

cần theo dõi. Snort có cơ chế báo động (alerting) theo thời gian thực khi phát hiện

có vấn đề khả nghi, kết hợp được với các cơ thế thông báo khác của hệ điều hành.

Các thông tin thông báo, báo động được lưu theo nhiều định dạng khác nhau, trong

nhiều dạng cơ sở dữ liệu khác nhau như SQL Server, Oracle, file text,... Các dữ liệu

này có thể được dùng trong các bước phân tích, khai thác dữ liệu sau này.

Ghi chú: Thông tin chi tiết về Snort, xin tham khảo tài liệu [37] và website :

www.snort.org.

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

- 153 -

CChhưươơnngg 66.. HHệệ tthhốốnngg qquuảảnn ttrrịị GGrriidd

NNeettMMaannaaggeerr

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ạnh

mẽ. 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ần

mề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.. YYêêuu ccầầuu cchhứứcc nnăănngg ccủủaa mmộộtt hhệệ tthhốốnngg qquuảảnn ttrrịị

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ệnh

từ nhà quản trị mạng, cấu hình và điều khiển các module khác hoạt động, thu nhận, tổng hợp các thông tin từ các module và kết xuất kết quả cho nhà 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ện tượ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 log hay phát sinh các lệnh điều khiển thích hợp đến các module DeviceAgent.

6. Module DeviceAgent Nhận các lệnh điều khiển và để điều khiển và cấu hì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ển Grid.

8. PacketDatabase Cơ sở dữ liệu thông tin các packet. Có thể lưu dưới dạng packet thô, cơ sở dữ liệu quan hệ, các cấu trúc dữ liệu tiền xử lý cho các chức năng của hệ 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ống

do 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ính

khá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 ttrriiểể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. Tuy

nhiê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ữ


- 160 -

liệu cần xử lý ở đây tổng hợp từ nhiều LAN segment khác nhau thay vì chỉ trong

một LAN segment như trước đây.

4. Mô hình thành phần ứng dụng

Hình 6-2 Mô hình các thành phần của ứng dụng Grid NetManager thử nghiệm.

Ý nghĩa các thành phần giống như trong mô hình tổng quan. Module

PacketInfoProvider thực hiện tìm kiếm thông tin trong các PacketDatabase theo các

câu truy vấn và trả về các kết quả. Module này có nhiều thể hiện chạy song song

nhằm tăng tốc quá trình tìm kiếm thông tin.

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 actor

Danh 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ống

xuấ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 ““CCoonnffiigguurree PPaacckkeett 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.


- 166 -

7.1.3.4.4. Post conditions Nếu use case thực hiện thành công, trong bộ nhớ sẽ có một danh sách các

packet thỏa điều kiện truy vấn, và danh sách packet này sẽ được xuất ra màn hình.

Nếu use case thực hiện không thành công, thông báo lỗi, các dữ liệu cũ

không bị mất.

77..11..33..55.. CCáácc UUssee ccaassee ccủủaa EEtthheerreeaall

7.1.3.5.1. Tóm tắt Đây là các use case sử dụng lại từ phần mềm Ethereal, với mục đích phân

tích và trình diễn thông tin cho người sử dụng. Vì không phát triển nên ở đây không

trình bày.

7.1.3.5.2. Điều kiện tiên quyết Phải chạy use case Capture trước, trong bộ nhớ phải có dữ liệu để phân tích.


- 167 -

77..11..44.. MMôô ttảả ccáácc ddòònngg ssựự kkiiệệnn

77..11..44..11.. UUssee ccaassee ““SSeeaarrcchh nnooddeess””

7.1.4.1.1. Search nodes - basic sequence diagram

: NodesInfo : Nha quan tri : MainForm : SearchNodesCtrl

// Enter GIIS Server name

// Search nodes information from GIIS server

// Call search nodes// Search information

// Compare with condition search

// Nodes satisfy condition search

All of nodes satisfy condition search from user will be display in combo box

7.1.4.1.2. Search colaboration diagram

: NodesInfo

: Nha quan tri

: MainForm

: SearchNodesCtrl

5: // Compare with condition search

1: // Enter GIIS Server name2: // Search nodes information from GIIS server

3: // Call search nodes

6: // Nodes satisfy condition search

4: // Search information


- 168 -

7.1.4.1.3. Search nodes - GIIS server not found sequence diagram

: Nha quan tri : MainForm : SearchNodesCtrl : NodesInfo : MessageBox

// Enter GIIS server name

// Search nodes information in GIIS server

// Cal l search nodes // Search information

// GIIS server not found

// Show message box ("GIIS not server found")

7.1.4.1.4. Search nodes - GIIS server not found colaboration diagram

: Nha quan tri

: MainForm : SearchNodesCtrl

: NodesInfo

: MessageBox

1: // Enter GIIS server name2: // Search nodes information in GIIS server

3: // Cal l 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 CCoonnffiigguurree PPaacckkeett CCaappttuurriinngg

7.1.4.2.1. Add Configuration Capturing sequence diagram

: MainForm : Nha quan tri : Conf igureForm : Conf igureCtrl : Conf igureEntity

// Call Conf igureForm // Show

// Enter conf iguration f or node

// Add a conf iguration node

// Verif y 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 : Conf igureCtrl : Conf igureEntity


// Change conf iguration f or node

// Update a conf iguration node

// Verif y update a conf iguration

// Change conf iguration

7.1.4.2.4. Update Configuration Capturing colaboration diagram

5: // Verify update a configuration

: Nha quan tri : MainForm

: ConfigureEntity

: ConfigureForm : ConfigureCtrl

1: // Call ConfigureForm

3: // Change configuration for node4: // Update a configuration node

2: // Show

6: // Change configuration


- 172 -

7.1.4.2.5. Remove Configuration Capturing sequence diagram

: MainForm : Nha quan tri : Conf igureForm : Conf igureCtrl : Conf igureEntity


// Remov e conf iguration f or node

// Remov e a conf iguration node

// Verif y remov e a conf iguration

// Remov e conf iguration

7.1.4.2.6. Remove Configuration Capturing colaboration diagram

: MainForm : Nha quan tri

: Conf igureForm : Conf igureCtrl

: Conf igureEntity

2: / / Show

1: // Call Conf igureForm

3: // Remov e conf iguration f or node4: // Remov e a conf iguration node

5: // Verif y remov e a conf iguration

6: // Remov e conf iguration


- 173 -

77..11..44..33.. UUssee ccaassee ““CCaappttuurree””

7.1.4.3.1. Capture - Start Basic Flow sequence diagram

: Display Thread : Nha quan tri : MainForm : CaptureCtrl : StartCapture

Thread

// Start capture // Call capture

// Create thread Start

// Show packet

// Create thread Display

// send content of packet

7.1.4.3.2. Capture – Start Basic Flow colaboration diagram

: CaptureCtrl


: StartCapture Thread

: Display Thread

1: // Start capture

2: // Cal l capture

6: // Show packet

3: // Create thread Start

4: // Create thread Display5: // send content of 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// Create thread Start

// Notif y result

// Show error message

7.1.4.3.4. Capture – Start Error Flow colaboration diagram


: CaptureCtrl


: MessageBox

1: // Start capture

2: // Call capture

3: // Create thread Start

4: // Notify result

5: // Show error message


- 175 -

7.1.4.3.5. Capture - Start Stop Flow sequence diagram

: Nha quan tri : MainForm : CaptureCtrl : StartCapture Thread : MessageBox

// Stop capture // Cal l stop

// Create thread Stop

// Message back

// Show message

7.1.4.3.6. Capture – Start Stop Flow colaboration diagram


: StartCapture Thread : MessageBox

: CaptureCtrl

1: // Stop capture

2: // Call stop

3: // Create thread Stop

4: // Message back

5: // Show message


- 176 -

7.1.4.3.7. Capture – Start Error Flow sequence diagram

: MessageBox : StartCapture

Thread : Nha quan tri : MainForm : CaptureCtrl

// Stop capture // Cal l stop

// Create thread Stop

// Message back

// Show message Error

7.1.4.3.8. Capture – Start Error Flow colaboration diagram


: CaptureCtrl : MessageBox


1: // Stop capture

2: // Call 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 : FilterCtrl : FilterThread

// Call Filter // Submit Filter // Create Filter Thread

// Content of 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: // Show content of message

3: // Create Filter Thread

4: // Content of packet return


- 178 -

7.1.4.4.3. Query - Error Flow sequence diagram

: FilterThread : Nha quan tri : MainForm : FilterCtrl : MessageBox

// Call Filter // Submit Filter

// Create Filter Thread

// Error return

// Show message error

7.1.4.4.4. Query - Error Flow sequence diagram


: Fi lterThread

: MessageBox

: Fi lterCtrl

1: // Call Fi lter

2: // Submit Filter

3: // Create Fi lter 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 : globus_mutex_tJobTable : map <string,GL_GRAM_JOB>

callback_contact : char *

Add(... : string, .... : GL_GRAM_JOB *) : voidRemove(... : char*) : void

GetURL() : char *GetJob(... : char *) : GL_GRAM_JOB *

Lock()UnLock()

GL_CB

mutex : globus_mutex_tcond : globus_cond_tdone : globus_bool_t

IsDone()SetDone()Continue()

Wait()

GL_GLOBUS_FTP_CLIENT

fd : FILE *buffer : globus_byte_t

handle : globus_ftp_client_handle_t

StartTransfer()Transfer()

Host

hostName : stringcpu : long

GetHostName() : stringGetCPU() : Long

GL_GRAM_JOB

failed : globus_bool_tjobcontact : char *

callback : GL_GRAM_JOBS_CALLBACK

HasFailed() : globus_bool_tSetFailed()

Submit(... : ...)Cancel()

SetJobContact(... : ...)Wait()

1name1name

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ớp Loại đối tượng Diễn giải

1. GL_CB Control Lớp cung cấp các hàm gọi cho việc bắt đầu, chờ đợi và kết thúc của một công việc

2. GL_GRAM_JOBS_CALLBACK

Control Lớp quản lý việc gọi thực hiện một danh sách các công việc thông qua định danh của công việc

3. GL_GRAM_JOB Control Lớp chịu quản lý việc thực thi 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ản lý truyền dữ liệu với GridFTP.

5. GL_BROKER Control Tìm kiếm thông tin về các má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 kkếế 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:

STT Tên màn hình Diễn giải

1. Grid NetManager

Sử dụng lại màn hình chính của Ethreal, thêm các chức năng mới, thể hiện của các usecase Capture, Query Packet Information, Search nodes, cho phép tì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 tin về packet và xuất kết quả ra màn hình, cho phép khởi tạo và kết thúc quá trình bắt packet. Màn hình này cho phép sử dụng lại các chức năng phân tích của Ethereal.

2. Packet Capture Configure

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ên trên giao diện

Kiểu Diễn giải

1. mds_server_te MDS Server

Textbox Cho phép nhập vào tên của MDS Server đang quản lý thông tin của hệ 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 truy vấn, hệ thống sẽ cho gọi thực thi module PacketInfoProvider trên các máy ở xa, chờ nhận kết quả và xuất ra màn hình.

3. node_cb Nodes Combo Chứa danh sách Node thoả điều kiện tìm kiếm hiện đang có trong Grid.

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ác node.

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

giao diệ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ắt xuống.

3. filter_te Argument Textbox Chứa nội dung cấu hình bắt packet của từng module Sensor.

4. computer_cb Sensor 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 thực


- 183 -

thi module Sensor. 5. store_cb Database

ComputerCombo 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ưu trữ 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 && TTrriiểể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(Fi le 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. Grid NetManager

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 kkhhaaii

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ành cô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ác

middleware 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ường

mạ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 ứng

dụ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 ttrriiểểnn,, mmởở rrộộ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ất

Grid.


- 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ông

tin, 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

GGrriidd 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ình lượ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 so

sá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ụng cá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ục Tầm vực (tăng dần

theo nỗ lực)

Độ quan trọng

Nỗ lực

Kỹ năng

Tài nguyên

Ghi chú

1. Luồng công việc

Song song -> Mạng -> Tuần tự

2. Số công việc khác nhau

Một công việc -> nhiều công việc.

3. Độ sâu của các công việc con.

Không có công việc con -> Rất sâu

4. Kiểu công việc

Theo lô -> Đơn giản -> Song song -> Dựa trên EJB -> Phức tạp

5. Mức độ phụ thuộc Hệ điều hành

Độc lập -> Phụ thuộc chặt chẽ.

6. Dung lượng bộ nhớ cho

Nhỏ -> Lớn

Phụ lục

- 190 -

từng công việc

7. Các DLL Có sẵn tại chỗ -> Cần có DLL đặc biệt

8. Cấu hình trình biên dịch

Không cần cấu hình -> Cấu hình chuẩn ->Cần cấu hình đặc biệt.

9. Môi trường thực thi.

Không cần -> Môi trường chuẩn ->Cần môi trường đặc biệt.

10. Server ứng dụng

Không cần -> JSP -> EJB -> server đặc biệt.

11. Ứng dụng bên ngoài

Không cần -> Ứng dụng chuẩn -> Đòi hỏi cấu hình/cài đặt đặc biệt

12. Mức độ phụ thuộc phần cứng

Không Cần -> Các Thiết Bị IT Chuẩn -> Các Thiết Bị IT Đặc Biệt -> Các thiết bị đặc biệt khác.

13. Thực thi dự phòng công việc

Không cần thiết -> Rất cần thiết.

14. Nhập/Xuất dữ liệu cho công việc.

Tham số dòng lệnh -> Hàng đợi thông điệp -> File dữ liệu -> Cơ sở dữ liệu -> APIs

15. Truy cập dữ liệu chi sẻ

RO file -> RO DBMS -> RW File -> RW DBMS

16. Không gian lưu trữ tạm thời

Nhỏ -> Không giới hạn

17. Băng thông mạng

Nhỏ -> LAN tốc độ cao -> WAN

18. Dữ liệu theo thời gian.

Dữ liệu luôn hợp lệ -> Dữ liệu thay đổi theo thời gian.

19.

Kiểu dữ liệu : Sử dụng bộ mã

Unicode thông thường trên mạng SBCS -> Các unicode khác nhau trên DBCS -> Bộ Mã ký tự không xác định được.

Bảng 8-1 Các tiêu chí đánh giá tính khả thi của ứng dụng Grid

Phụ lục

- 191 -

BB.. ĐĐịịnnhh ddạạnngg ffiillee 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 WSDL khi 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 Grid service 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 gian tê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ụng trong tài liệu GWSDL.

Tiếp theo, phải khai báo import file OSGI GWSDL chức các khai báo, định nghĩ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"/> <fault name="Fault" message="ogsi:FaultMessage"/> </operation> <operation name="getValue"> <input message="tns:GetValueInputMessage"/> <output message="tns:GetValueOutputMessage"/> <fault name="Fault" message="ogsi:FaultMessage"/> </operation> </gwsdl:portType

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, ở đây MathService đượ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ểu

củ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êm

cá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ĩa sẵn.

CC.. KKỹỹ tthhuuậậtt ccààii đđặặtt ccáácc cchhứứcc nnăănngg ccơơ bbảảnn ccủủaa GGrriidd

SSeerrvviiccee

CC..11.. KKỹỹ 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ớp GridServiceImpl, do GridServiceImpl có tất cả các chức năng cơ bản nên MathImpl chỉ 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 portType chỉ 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án cá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à Operation Provider. Như trên hình 0-2, có thể chia lớp MathImpl thành 3 lớp, ứng với từng nhó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ũng

giống như các lớp của MathImpl trước đây, chỉ khác là ở đây cài đặt thêm interface OperationProvider, 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/server-deploy.wsdd <?xml version="1.0"?> <deployment  <parameter name="schemaPath" value="schema/progtutorial/MathService/Math_service.wsdl"/>  <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.MathProvider"/> <!—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ẽ xem xé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ối cùng (lastOp), số phép toán đã thực hiện (numOp), MathData chỉ có một và chỉ một giá 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 file GWSDL mới, file này có nội dung và cấu trúc gần giống với file GWSDL cũ, một số 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/impl/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:

public void add(int a) throws RemoteException { //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 URL GSH = new java.net.URL(args[0]); int a = Integer.parseInt(args[1]); // Lay GSR cua Math PortType MathServiceGridLocator mathServiceLocator = new MathServiceGridLocator(); MathPortType math = mathServiceLocator.getMathServicePort(GSH); // Lay SDE "MathData", su dung phuong thuc findServiceData cua GridServiceImpl 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ếế NNoottiiffiiccaattiioonn

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 SDE củ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ào nữa.

Có thể thấy đây là cơ chế “push” notification, GT3 chỉ hỗ trợ duy nhất dạng này. Dưới đây, chúng ta sẽ xem xét chi tiết kỹ thuật cài đặt notification này trong GT3 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ấp

mộ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 đặt

Chú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) { // Lay tham so dong lenh 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 nghe notifManager.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 moi ServiceDataValuesType 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 kkỹỹ 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 service thành transient service) là một trong những việc dễ dàng nhất trong GT3, chúng ta khô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ại file đặ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ũ:

<?xml version="1.0"?> <deployment name="defaultServerConfig" xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"> <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="persistent" value="true"/> <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ột

factory. 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

<?xml version="1.0"?> <deployment name="defaultServerConfig" xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"> <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" value="schema/progtutorial/MathService/Math_service.wsdl"/> <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="persistent" value="true"/> <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 đây là 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 thi của Factory (cung cấp bởi GT3), không phải bất cứ mã thực thi nào do chúng ta tạ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/FactoryClient.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 tham so dong lenh URL GSH = new java.net.URL(args[0]); int a = Integer.parseInt(args[1]); // 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.. KKỹỹ 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ể được kết xuất ra màn hình. GT3 cung cấp khả năng logging theo mô hình Apache Jakarta Commons Logging (http://jakarta.apache.org/commons/logging/). Mô hình này đưa ra 6 cấp độ thông tin logging, gồm Debug, Trace, Info, Warn, Error, Fatal. Việc quyế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ần thê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/MathImpl.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()); // ... public void add(int a) throws RemoteException { 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.. KKỹỹ tthhuuậậtt qquuảảnn llýý cchhuu ttrrììnnhh ssốốnngg ccủủaa sseerrvviiccee ((LLiiffeeccyyccllee

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 (lifecycle monitor). Ở đâ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 được gọ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ình

chư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 cua lop 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 Monitor

Kỹ 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ớp cha, 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ạn chế 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ột lớ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 Grid service. 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ớp lifecycle 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 iinntteerrffaaccee ccủủaa mmộộtt OOGGSSII SSeerrvviiccee

Bảng 0-3 tóm tắt các interface của một Grid Service được định nghĩa trong OGSI 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ác interface của service.

serviceDataName Danh sách tên (QName) các SDE của service (động và tĩnh)

factoryLocator Vị trí (ogsi:LocatorType) của factory tạo ra service instance này

gridServiceHandle Zero hoặc nhiều GSH của service instance

Grid Service SDE

gridServiceReference Một hoặc nhiều GSR của service instance

Phụ lục

- 209 -

findServiceDataExtensibility Tập các phương thức mở rộng của phương thức findServiceData

setServiceDataExtensibility Tập các phương thức mở rộng của phương thức setServiceData

terminationTime Thời gian dự kiến kết thúc của service instance.

findServiceData Truy vấn thông tin của

service. setServiceData Cho phép thay đổi giá trị các

SDE được phép thay đổi giá trị. (modifiable= “true”)

requestTerminationAfter Yêu cầu thay đổi terminationTime của service instance. Phương thức này xác định thời gian kết thúc sớm nhất có thể được.

requestTerminationBefore Yêu cầu thay đổi terminationTime của service instance. Phương thức này xác định thời gian kết thúc trễ nhất có thể được.

Phương thứ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ải thành GSR.

SDE

Handle Resolver Phương

thức findByHandle Trả về vị trí

(ogsi:LocatorType) chức các GSR tương với GSH đươc yêu cầu.

Cho phép các client đặt các yêu cầu cung cấp các thông báo notifiableServiceDataName Tập các QName của SDE

được yêu cầu thông báo mỗi khi có sự thay đổi.

subscribeExtensibility Tập các phương thức mở rộng của phương thức subscribe

SDE

Notification Source

Phương thức

subscribe Yêu cầu phải được thông báo mỗi khi có sự thay đổi của cá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ệp SDE Không có Notification

Sink Phương thứ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

subscriptionExpression sinkLocator

SDE

Notification Subscription

Phương thức

Không có

Cung cấp các cách thức chuẩn để tạo các service instance createServiceExtensibility Tập các phương thức mở

rộng của phương thức createService

SDE

Factory

Phương thứ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ác QName. Mỗi service instance nếu muốn là thành viên của nhóm phải có một hoặc nhiều interface xác định trong SDE này.

SDE

entry Biểu diễn thông tin về một thành viên của ServiceGroup.

Service Group

Phương thức

Không có

Cho phép thêm và loại bỏ các Grid service instance trong các ServiceGroup,

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ức remove

SDE

add Tạo một ServiceGroupEntry

và đưa vào ServiceGroup.

Service Group Registration

Phương thức

remove Loại bỏ ServiceGroupEntry thoả 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. Service Group Entry

SDE memberServiceLocator Chứa vị trí (ogsi:LocatorType) của service instance được tham khả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 ttrrúú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 (distinguished

name (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ận dạ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ùng

thậ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ông

khai tương ứng), và một bản yêu cầu chứng nhận chứa khoá công khai và các thô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 được giữ 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êu cầ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ằng nhiề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ản yê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ình khi 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 National Laboratory & 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 IEEE International 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

- 214 -

Laura Pearlman, Steven Tuecke, Security for Grid Services, www.globus.org.

[14] Von Welch, Ian Foster, Carl Kesselman, Olle Mulmo, Laura Pearlman, Steven Tuecke, Jarek Gawor, Sam Meder, Frank Siebenlist, X.509 Proxy Certificates for Dynamic Delegation, www.globus.org.

[15] Ian Foster, Carl Kesselman, Gene Tsudik, Steven Tuecke, A Security Architecture for Computational Grids, 5th ACM Conference on Computer and Communication Security, www.globus.org

[16] Bart Jacob, How Grid infrastructure affects application design, RedBooks, IBM, 06/2003.

[17] Bart Jacob, Taking advantage of Grid computing for application enablement, RedBooks, IBM, 06/2003.

[18] Martin C. Brown, Grid computing -- moving to a standardized platform, RedBooks, IBM, 08/2003.

[19] IBM Corp. , The Era of Grid Computing: A new standard for successful IT strategies, 01/2004, www.ibm.com

[20] Viktors Berstis, Fundamentals of Grid Computing, Redbooks, IBM Corp, 2002, www.ibm.com/redbooks

[21] Luis Ferreira,Viktors Berstis, Jonathan Armstrong, Mike Kendzierski, Andreas Neukoetter, Introduction to Grid Computing with Globus, Redbooks,IBM Corp, 09/2003, www.ibm.com/redbooks

[22] Bart Jacob, Luis Ferreira, Norbert Bieberstein, Candice Gilzean, Jean-Yves Girard, Roman Strachowski, Seong (Steve) Yu, Enabling Applications for Grid Computing with Globus, Redbooks, IBM Corp, 06/2003, www.ibm.com/redbooks

[23] Luis Ferreira, Bart Jacob, Sean Slevin, Michael Brown, Srikrishnan Sundararajan, Jean Lepesant, Judi Bank, Globus Toolkit 3.0 Quick Start, Redbooks, IBM Corp, 09/2003, www.ibm.com/redbooks

[24] Borja Sotomayor, The Globus Toolkit 3 Programmer's Tutorial, 2003-2004. www.globus.org

[25] Richard Sharpe, Ed Warnicke, Ulf Lamping, Ethereal User's Guide: V2.00 for Ethereal 0.10.5, 2004, www.ethereal.com

[26] Luis Ferreira, Arun Thakore, Michael Brown, Fabiano Lucchese, Huang RuoBo, Linda Lin, Paul Manesco, Jeff Mausolf, Nasser Momtaheni, Karthik Subbian, Olegario, Hernandez, Grid Services Programming and Application Enablement, Redbooks,IBM Corp, 05/2004, www.ibm.com/redbooks

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

- 216 -

CCáácc WWeebbssiittee

STT Tổ chức Website 1. Globus Alliance http://www.globus.org 2. IBM http://www.ibm.com 3. Global Grid Forum http://www.globalgridforum.org 4. GridCafe http://gridcafe.web.cern.ch/gridcafe5. NSF MIDDLEWARE

INITIATIVE http://www.nsf-middleware.org

6. GRIDS http://www.grids-center.org 7. UNICORE http://www.unicore.org 8. Legion http://legion.virginia.edu 9. Gridbus http://www.gridbus.org 10. Ethereal http://www.ethereal.com 11. WindowSecurity http://www.WindowSecurity.com 12. SecurityFocus http://www.SecurityFocus.com 13. Cisco Corp. http://www.Cisco.com 14. Snort http://www.Snort.com

Documents

Grid computing va quan tri mang