» Công Nghệ Thông Tin

» Quản trị mạng

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

Chia sẻ: Cao Tt | Ngày: | Loại File: PDF | Số trang:23

0

Báo xấu

114
lượt xem 21
download

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

Mô tả tài liệu

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: CÔNG NGHỆ GRID COMPUTING VÀ ỨNG DỤNG THỬ NGHIỆM TRONG BÀI TOÁN QUẢN TRỊ MẠNG - 6

Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2 * 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 - 101 -
Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2 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() Tạo/Huỷ cổng kết nối để nhận các globus_gram_client_callback_disallow() 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() Đăng ký và huỷ đăng với job globus_gram_client_job_callback_unregister() 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_*() Quản lý các công việc con của một globus_duroc_runtime_intra_subjob_*() 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* Tìm kiếm máy tính trong hệ thống filterstring, …) 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. - 102 -
Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2 - 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. - 103 -
Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2 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. - 104 -
Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2 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. - 105 -
Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2 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. - 106 -
Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2 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. 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. - 107 -
Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2 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). 3.4.3.2. Pre-WS Information Service (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) - 108 -
Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2 + 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 đó. - 109 -
Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2 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). - 110 -
Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2 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 - 111 -
Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2 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. 3.4.3.3. WS Information Service (Index Service) 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. - 112 -
Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2 + 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). 3.4.4. Data Management 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. - 113 -
Chương 3. Giới thiệu bộ Globus Toolkit phiên bản 3.2 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. 3.4.5. Thành phần mới trong GT3 3.4.5.1. GT3 Core Các thành phần của GT Core được tóm tắt như sau: Triển khai cài đặt tất cả các interface do OGSI xác định. OGSI Spec Implementation Thành phần này hỗ trợ bảo mật cấp thông điệp, chứng thực Security và phân quyền dựa trên gridmap file. Bảo mật cấp thông Infrastructure đ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ử System level dụng bởi tất cả các Grid service khác. Hiện tại có 3 loại services service: Ping service Sử dụng để "ping" một hosting environment. Logging Cho phép sửa đổi các log filter và Management nhóm các thông tin log để dễ theo dõi Service và quản lý. Management Cung cấp một interface để theo dõi Service 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 - 114 -
Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2 Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2 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. 4.1. Khởi đầu dự án 4.1.1. Định hướng phát triển hệ thống 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 - 115 -
Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2 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 - 116 -
Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2 dựng các module thành các Grid service đơn nhiệm và triển khai chúng trên Grid. 4.1.2. Đánh tính khả thi của ứng dụng khi chạy trên Grid 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. … - 117 -
Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2 Đó 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. 4.2. Các yêu cầu cần quan tâm khi xây dựng ứng dụng 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. 4.2.1. Khả năng mở rộng (Scalability) 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. 4.2.2. Bảo mật 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 - 118 -
Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2 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,… 4.2.3. Tính mềm dẻo của ứng dụng (Flexibility) 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. 4.2.4. Các kết nối với bên ngoài 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. - 119 -
Chương 4. Phát triển ứng dụng với bộ Globus Toolkit 3.2 4.2.5. Hiệu suất ứng dụng(Performance) 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 - 120 -

CÓ THỂ BẠN MUỐN DOWNLOAD

THÔNG TIN

TRỢ GIÚP

HỖ TRỢ KHÁCH HÀNG

Theo dõi chúng tôi

Chịu trách nhiệm nội dung:

Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA

LIÊN HỆ

Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM

Hotline: 093 303 0098

Email: support@tailieu.vn

Giấy phép Mạng Xã Hội số: 670/GP-BTTTT cấp ngày 30/11/2015 Copyright © 2009-2019 TaiLieu.VN. All rights reserved.