Luận văn Tìm hiểu công nghệ grid computing và ứng dụng thử nghiệm trong bài toán quản trị mạng

rid 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.. + 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” Ví dụ : “/C=VN/O=HCMUNS/OU=FIT/CN=NMDzung/USERID=Dzung” root 3.4.1.3. Cơ chế hoạt động 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.4.1.4. Sử dụng GSI + 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.4.2. Resource Management 3.4.2.1. Giới thiệ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á