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

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

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.








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


C
C
á
á
c

c


t
t
h
h
à
à
n
n
h
h


p
p
h
h
ầ
ầ
n
n


c
c
h
h
í

í
n
n
h
h


3
3
.
.
4
4
.
.
1
1
.
.




S
S
e
e
r
r
c

c
u
u
r
r
i
i
t
t
y
y


I
I
n
n
f
f
r
r
a
a
s
s
t
t
r
r
u

u
c
c
t
t
u
u
r
r
e
e


3
3
.
.
4
4
.
.
1
1
.
.
1
1
.
.

G
G
i
i
ớ
ớ
i
i


t
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

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

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

C
C
á
á
c
c


n
n
g
g
u
u
y
y
ê
ê
n
n


t
t
ắ
ắ
c
c

v
v
à
à


k
k
h
h
á
á
i
i


n
n
i
i
ệ
ệ
m
m


c
c

ơ
ơ


b
b
ả
ả
n
n


t
t
r
r
o
o
n
n
g
g


b
b
ả
ả
o
o

m
m
ậ
ậ
t
t


G
G
r
r
i
i
d
d


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.








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

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








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.

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








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








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








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ỏ

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

C
C
ơ
ơ


c
c
h
h
ế
ế


h
h
o
o
ạ
ạ
t
t


đ
đ
ộ
ộ
n

n
g
g


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.









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

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

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

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

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








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

4
4
.
.
1
1
.
.
4
4
.
.






S
S
ử
ử


d
d
ụ
ụ
n
n

g
g


G
G
S
S
I
I


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








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

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








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

.




R
R
e
e
s
s
o
o
u
u
r
r
c
c
e
e


M
M
a
a
n
n
a

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


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

.






G
G
i
i
ớ
ớ
i
i


t
t
h
h
i
i
ệ
ệ
u
u


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.









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

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.








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

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








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

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








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

2
.
.






P
P
r
r
e
e
-
-
W
W
S
S


G
G
R
R
A
A
M

M


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









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