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 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.. Giớ
Trang 1* 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
Trang 2LDAP 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
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
3.4.2.3 WS-GRAM
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
Trang 3- 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
Trang 45 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
Trang 5Dướ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
Trang 64 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ộ
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
Trang 7Cá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
3.4.3 Information Service
3.4.3.1 Giới thiệu
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.
Trang 8Mô 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)
3.4.3.2 Pr -WS Information Se vic (MDS2)
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)
Trang 9+ 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 đó
Trang 10Hì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)
Trang 11Hì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
Trang 12Thự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
3.4.3.3 WS Information Service (Index Se vice)
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
