Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 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

ct
t
h
h
à
à
n
n
h
hp
p
h
h
ầ
ầ
n
nc
c
h
h
í

c
u
u
r
r
i
i
t
t
y
yI
I
n
n
f
f
r
r
a
a
s
s
t
t
r
r
u
G
G
i
i
ớ
ớ
i
it
t
h
h
i
i
ệ
ệ
u
u

Trong GT, việc bảo mật Grid được đảm trách bởi module Grid Security Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 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.
3
3
.
.
4
4
.
.
1
1
.
.
2
2
.
.

v
v
à
àk
k
h
h
á
á
i
in
n
i
i
ệ
ệ
m
mc
c
m
m
ậ
ậ
t
tG
G
r
r
i
i
d
d1. 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

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.

+ 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. Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 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.

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

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 Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 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ỏ


C
C
ơ
ơc
c
h
h
ế
ếh
h
o
o
ạ
ạ
t
tđ
đ
ộ
ộ
n

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.
Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 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). Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 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

4
4
.
.
1
1
.
.
4
4
.
.
S
S
ử
ửd
d
ụ
ụ
n
n

$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ụ Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 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

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
3
3
.
.
4
4
.
.
2
2
.

a
g
g
e
e
m
m
e
e
n
n
t
t3
3
.
.
4
4
.
.
2
2
.
.
1
1
.


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.
Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 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

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
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: Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2
- 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

2
.
.
P
P
r
r
e
e
-
-
W
W
S
SG
G
R
R
A
A
M

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