Module quản lý Proxy

3.4.4.1 Yêu cầu cho module quản lý proxy

Module quản lý Proxy trong LindaX phải đảm bảo các yêu cầu sau:

 Tại một thời điểm chỉ có duy nhất một đối tƣợng cho giấy ủy quyền (GSSCredential) trong hệ thống.

 Tại một thời điểm chỉ có một tiến trình java quảy lý module.

 Module có thể chạy ngầm định để tạo proxy định kỳ, hoặc đƣợc chạy khi có yêu cầu.

 Các tham số cho module quản lý proxy (username và password, máy chủ MyProxy) có thể đƣợc thay đổi khi ứng dụng đang chạy mà không làm gián đoạn hoạt động của hệ thống.

 Cung cấp giao diện thông tin và quản lý proxy.

3.4.4.2 Thiết kế module quản lý proxy

Hình 3.9 – Biểu đồ use-case cho module quản lý proxy

# Mã Tên Parent Mô tả

1 UC_01 Proxy Service Administrator Management

Dịch vụ cho phép hiển thị thông tin của proxy và cung cấp những nghiệp vụ cơ bản thao tác với dịch vụ quản lý giấy ủy quyền (chạy/dừng) và cá thao tác với giấy ủy quyền (thêm/xóa). 2 UC_02 Tạo proxy (create

Proxy)

Administrator Management

Chức năng cho phép tạo mới proxy và lƣu vào vùng nhớ chia sẻ của ứng

dụng. 3 UC_03 Xóa proxy (delete

Proxy)

Administrator Management

Chức năng cho phép xóa một proxy đƣợc lƣu trong bộ nhớ của ứng dụng. 4 UC_04 Đọc proxy (read

Proxy)

Administrator Management

Chức năng chop phép đọc proxy từ bộ nhớ, đƣờng dẫn tới file proxy đƣợc xác định dựa vào tên mặc định cho từng ngƣời dùng lƣới.

5 UC_05 Dừng dịch vụ (stop Service)

Administrator Management

Chức năng cho phép quản trị viên dừng dịch vụ quản lý proxy. 6 UC_06 Khởi động dịch vụ quản lý proxy (start Service) Administrator Management

Khởi động dịch vụ quản lý proxy (trong trƣờng hợp dịch vụ đang tạm dừng).

Ví dụ Usecase UC_01:

Mã : UC_01 Proxy Service (quản lý giấy uỷ quyền).

Mức độ ưu tiên: Độ phức tạp: Mục đích

Use-case này hiển thị thông tin của giấy ủy quyền của hệ thống, đồng thời chứa liên kết tới các chứng năng quản lý proxy (đọc, xóa, tạo).

Tác nhân

Chính Quản trị viên

Khác

Điều kiện trước

Use-case này đƣợc bắt đầu khi quản trị viên truy cập vào giao diện

“Quản trị hệ thống” và lựa chọn chức năng “Quản trị dịch vụ tạo giấy ủy quyền”.

Điều kiện sau Thành công Không thành công Luồng chính Bước Ngƣời dùng Hệ thống 1

Quản trị viên truy cập vào giao diện

“Quản trị hệ thống” và lựa chọn chức năng “Quản trị dịch vụ tạo giấy ủy quyền”.

Hiển thị các chức năng hệ thống dành cho ngƣời quản trị và thông tin proxy.

Luồng rẽ nhánh 1 Nếu quản trị viên chọn chức năng “create proxy”, module sẽ tạo ra một proxy và load lại trang hiện tại.

Luồng rẽ nhánh 2 Nếu quản trị viên chọn chức năng “delete proxy”, module sẽ xóa proxy trong hệ thống.

Luồng rẽ nhánh 3

Nếu quản trị viên chọn chức năng “read proxy”, module sẽ đọc proxy từ ổ cứng (đƣờng dẫn là mặc định cho từng ngƣời dùng lƣới).

Đối tượng SHARED_MEMORY

Các thao tác truy cập thƣờng xuyên tới cơ sở dữ liệu đối với các thông tin có tần suất thay đổi thấp (nhƣ thông tin về máy chủ chứa proxy, danh sách các Datanode…) thƣờng lặp lại không cần thiết và làm cho hệ thống quá tải. Hơn nữa, các thông tin này cần phải đƣợc quản lý tập trung để giải quyết vấn đề toàn vẹn và các vấn đề đồng bộ.

Để giải quyết những ràng buộc này, LindaX đƣợc thiết kế với một vùng nhớ đƣợc chia sẻ giữa các servlet/action struts. Mọi thao tác thay đổi trên cơ sở dữ liệu sẽ đƣợc cập nhật tƣơng ứng trên vùng nhớ chia sẻ. Các module, các servlet sử dụng thông tin trên vùng nhớ đƣợc chia sẻ bằng cách tạo các tham chiếu tới vùng này.

Vùng nhớ chia sẻ đƣợc quản lý bởi đối tƣợng của lớp SHARED_MEMORY:

Với việc sử dụng đối tƣợng duy nhất cho vùng nhớ chia sẻ, hệ thống đã giải quyết đƣợc các yêu cầu:

 Tại một thời điểm chỉ có duy nhất một đối tƣợng cho giấy ủy quyền (GSSCredential) trong hệ thống.

Đối tượng PROXY_SERVICE_MONITOR

Hình 3.11 – Lớp PROXY_SERVICE_MONITOR

Việc lƣu trữ đối tƣợng PROXY_SERVICE_MONITOR đảm bảo các yêu cầu cho module quản lý proxy:

 Tại một thời điểm chỉ có một tiến trình java quản lý module.

 Cung cấp giao diện thông tin và quản lý proxy (lấy trạng thái từ trƣờng status).

 Module có thể chạy ngầm định để tạo proxy định kỳ, hoặc đƣợc chạy khi có yêu cầu (gọi phƣơng thức wakeup())..

3.4.4.3 Kết luận

Hệ thống đƣợc triển khai với Headnode đặt tại bkluster.hut.edu.vn (202.191.56.48) với máy chủ MyProxy: bkluster.hut.edu.vn, Port: 7512

Module hoạt động ổn định và đảm bảo đƣợc các yêu cầu:

 Tại một thời điểm chỉ có duy nhất một đối tƣợng cho giấy ủy quyền (GSSCredential) trong hệ thống.

 Tại một thời điểm chỉ có một tiến trình java quản lý module.

 Module có thể chạy ngầm định để tạo proxy định kỳ, hoặc đƣợc chạy khi có yêu cầu.

 Các tham số cho module quản lý proxy (username và password, máy chủMyProxy) có thể đƣợc thay đổi khi ứng dụng đang chạy mà không làm gián đoạn hoạt động của hệ thống.

 Cung cấp giao diện quản lý proxy.

3.4.5 Nút lưu trữ (DataNode)

DataNode chính là các máy trực tiếp lƣu trữ dữ liệu. Số lƣợng các DataNode là không hạn chế và có thể là rất lớn. Máy lƣu trữ làm nhiệm vụ lƣu trữ dữ liệu của ngƣời dùng, nhận các tệp tin đƣợc upload trực tiếp từ ngƣời dùng, sau khi đƣợc HeadNode chỉ định. Đồng thời, DataNode cũng đƣợc cài đặt các cơ chế cho phép ngƣời dùng download dữ liệu về. Để một máy trở thành DataNode thì nó phải đảm bảo

 Cài đặt hệ điều hành Linux/Unix

 Globus Toolkit đƣợc cài đặt mặc định (phiên bản 3.0 trở về sau)

 Máy đƣợc tham gia vào cùng một lƣới tính toán với một trong các HeadNode và đƣợc HeadNode đó xác thực.

Vì các DataNode nằm rải rác trên lƣới, cách xa nhau về địa lý và đƣợc sử dụng đồng thời bởi nhiều ứng dụng của những ngƣời dùng lƣới khác nhau, nên hệ thống cần có một module quản lý thông tin tài nguyên hiệu quả về trạng thái của các DataNode.

Đối với hệ thống lƣu trữ và chia sẻ dữ liệu LindaX, tài nguyên trên các DataNode bao gồm:

 Tài nguyên lƣu trữ: dung lƣợng ổ cúng có thể sử dụng để lƣu trữ.

 Băng thông mạng: hạ tầng mạng mà các DataNode đƣợc đặt trên.

 Tài nguyên CPU.

 Sổ lƣợng ngƣời dùng đang upload/download dữ liệu.

Hình 3.13 – Cây thư mục trên DataNode

DataNo de Data user files Logs Scripts resourcemon itor.sh rsl

Trong đó

 Thƣ muc Data: chứa các tệp tin ngƣời dùng upload lên hệ thống.

 Thƣ mục Logs: chứa các file log của hệ thống.

 Thƣ mục Scripts: chứa các script cài đặt các dịch vụ trên DataNode (nhƣ resourcemonitor.sh giúp giám sát tài nguyên của DataNode).

3.4.6 Module quản lý tài nguyên

3.4.6.1 Các mô hình quản lý tài nguyên

Một module quản lý tài nguyên không những có khả năng xác định những thành phần của hệ thống gặp lỗi, mà còn có khả năng thu nhận các thông tin về trạng thái của các thành phần. Trong một hệ thống thƣờng có 3 thành phần chính:

 Đối tƣợng yêu cầu: là đối tƣợng có nhu cầu nắm bắt về trạng thái của một đối tƣợng nào đó.

 Đối tƣợng theo dõi: là đối tƣợng thực hiện việc thu thập thông tin trạng thái của đối tƣợng đƣợc theo dõi, cung cấp thông tin này cho đối tƣợng yêu cầu.

 Đối tƣợng đƣợc theo dõi: là đối tƣợng đƣợc “quan tâm” của đối tƣợng yêu cầu và đối tƣợng theo dõi.

a) Mô hình Push

Hình 3.14 – Mô hình Push

Theo mô hình Push, đối tƣợng đƣợc theo dõi gửi thông điệp một cách định kỳ đến đối tƣợng theo dõi để báo rằng “trạng thái hiện tại của tôi là…”. Nếu trong một khoảng thời gian ràng buộc nào đó, đối tƣợng theo dõi không nhận đƣợc thông điệp từ đối tƣợng đƣợc theo dõi thì nó bắt đầu nghi ngờ đối tƣợng này. Việc truyền thông điệp giữa các đối tƣợng là theo một chiều.

Hình 3.15 – Phát hiện lỗi trong mô hình Push

Hình 3.11 minh hoạ về cách thức trao đổi tín hiệu giữa các đối tƣợng. Cần phân biệt rằng: việc truyền thông điệp giữa đối tƣợng theo dõi cho đối tƣợng yêu cầu và việc truyền thông điệp giữa đối tuợng đƣợc theo dõi cho đối tƣợng theo dõi là khác nhau. Đối tƣợng theo dõi chỉ truyền thông điệp tới đối tƣợng yêu cầu khi đối tƣợng đƣợc theo dõi “có vấn đề” trong khi đối tƣợng yêu cầu cần định kì gửi thông điệp tới đối tƣợng theo dõi. Mô hình này nói chung đơn giản do chỉ gửi thông điệp theo một hƣớng do vậy giảm đƣợc chi phí tài nguyên đƣờng truyền.

b) Mô hình Pull

Hình 3.16 – Mô hình Pull

Trong mô hình Pull, đối tƣợng theo dõi theo định kì gửi thông điệp “hỏi thăm” tới đối tƣợng đƣợc theo dõi. Nếu đối tƣợng đƣợc theo dõi trả lời lại thì có nghĩa rằng đối tƣợng đó còn sống. Hình 3.16 minh hoạ việc truyền thông điệp giữa các đối tƣợng trong mô hình Pull. Theo định kì, đối tƣợng theo dõi gửi thông điệp hỏi thăm tới đối tƣợng đƣợc theo dõi và đợi trả lời. Nếu không nhận đƣợc thông điệp trả lời trong một khoảng thời gian cho phép thì đối tƣợng đuợc theo dõi sẽ bị nghi nghi ngờ.

Mô hình Pull phức tạp hơn mô hình Push do có sự trao đổi thông điệp qua lại giữa các đối tƣợng, tuy nhiên lại có ƣu điểm là dễ dàng cho ngƣời phát triển ứng dụng. Đối tƣợng đƣợc theo dõi ở thế bị động do vậy nó không cần phải biết về thời gian phải gửi thông điệp cũng nhƣ thứ tự thông điệp gửi tới đối tƣợng theo dõi.

c) Sử dụng kết hợp hai mô hình Push và Pull

Có thể dùng mô hình kết hợp của mô hình Push và Pull để thu đƣợc những ƣu điểm trong cả hai mô hình này.

Hình 3.18 – Sử dụng kết hợp hai mô hình Push và Pull

Hình 3.18 minh hoạ cơ chế truyền thông điệp trong mô hình kết hợp Push-Pull. Nhƣ ta thấy, có hai đối tƣợng đƣợc theo dõi là M1 và M2. Trong pha thứ nhất, M1 và M2 hoạt động theo mô hình Push. Tuy nhiên chỉ có M1 gửi thông điệp tới đối tƣợng theo dõi, M2 không gửi. Sau thời gian T1 cho pha thứ nhất, mô hình chuyển sang hoạt động theo pha thứ hai: gửi thông điệp hỏi thăm tới M2 (vì đã không nhận đƣợc tín hiệu của M2 trong pha thứ nhất) và đã nhận đƣợc thông điệp trả lời. Sau thời gian T2, mô hình lại chuyển sang hoạt động theo pha thứ nhất. Trong pha tiếp theo này cả M1 và M2 đều không gửi thông điệp tới đối tƣợng theo dõi (M1 bị lỗi). Do vậy tiếp theo khi chuyển sang pha 2, đối tƣợng theo dõi gửi thông điệp hỏi thăm tới cả M1 và M2. Chỉ M2 trả lời và do đó M1 bị nghi ngờ.

3.4.6.2 Yêu cầu cho module quản lý tài nguyên của LindaX

Module quản lý tài nguyên trong LINDAX đƣợc quản lý bởi một tuyến viết bằng java chạy ngầm định. Để tối ƣu hiệu năng và đảm bảo tính nhất quán trong thông tin thu thập đƣợc, module đƣợc thiết kế để đảm bảo các yêu cầu:

 Là hệ thống quản lý tập trung, độc lập với chính sách quản lý tài nguyên của từng DataNode. Để thực hiện yêu cầu này, module đƣợc thiết kế tập trung theo mô hình pull. Thành phần chính điều khiển quá trình xác định trạng thái của các DataNode đƣợc đặt trên Headnode. Trên mỗi DataNode chứa các thành phần lấy thông tin và đƣợc thực thi khi có yêu cầu từ Headnode.

 Chỉ có duy nhất một tuyến quản lý module tại mỗi thời điểm: Nếu vì một lý do nào đó, có hai tuyến trong hệ thống cùng thực hiện một công việc thì trạng thái của các DataNode có thể không nhất quán. Do trạng thái của các DataNode đƣợc lƣu bởi một đối tƣợng trong vùng bộ nhớ chia sẻ của chƣơng trình, rất có thể một thành phần của trạng thái đƣợc cập nhật bởi một tuyến còn thành phần khác đƣợc cập nhật bởi tuyến khác.

 Chỉ có duy nhất một tuyến cho mỗi DataNode tại mỗi thời điểm. Để đảm bảo yêu cầu này, trƣớc tiên phải đảm bảo chỉ có một tuyến cho module quản lý tài nguyên, ngoài ra cần phải xác định thời gian time-out cho từng tuyến.

 Module có hai chế độ chạy: module có thể hoạt động định kỳ, sau mỗi khoảng thời gian cập nhật thông tin trạng thái mới cho mỗi DataNode. Hoặc module có thể đƣợc các module khác yêu cầu update tại bất cứ thời điểm nào.

 Module có khả năng tự động cập nhật thông tin về cách thành phần mới đƣợc thêm vào hệ thống mà không phải khởi động lại.

 Có khả năng mở rộng: khi hệ thống có yêu cầu lấy các trạng thái mới, module có khả năng thực hiện yêu cầu mà không phải khởi động lại.

 Cung cấp thông tin hoạt động của module, giao diện để khởi động lại module.

3.4.6.3 Thiết kế module quản lý tài nguyên

a) Mô hình vật lý

 Module quản lý tài nguyên đƣợc thiết kế theo mô hình Pull.

 Module đƣợc quản lý tập trung.

Tại Headnode sử dụng các lớp GramJob, GassServer, chuỗi RSL để điều khiển thu nhận trạng thái các DataNode trên lƣới.

Tại DataNode đƣợc cài đặt shell resourcemonitor.sh để thu nhận thông tin và trả về Headnode.

#!/bin/bash ################## # LINDAX project # hpc-hut centre # hungdh ################# echo "bkluster" disk=`df -hk $HOME` disk=${disk% *} disk=${disk% *} disk=${disk% *} #get available disk Avail=${disk##* } echo $Avail

#get used disk disk=${disk% *} disk=${disk% *} Used=${disk##* } echo $Used #get Total #disk=${disk% *} disk=${disk% *} Total=${disk##* } echo $Total

Quá trình thu nhận tài nguyên từ Headnode đƣợc mô tả thông qua chuỗi RSL sau:

RSL = "&(rsl_substitution=(GLOBUSRUN_GASS_URL " + gServer.getURL() + "))" + "(executable=" + dataNode.getHome() + "/" + dataNode.getScript() + "/" + "monitorservice.sh" + ")(directory="+ dataNode.getHome() + "/" + "gramjob" + ")(stdout=$(GLOBUSRUN_GASS_URL)/dev/stdout-" + jobID + ")";

Hình 3.20 – Biểu đồ use-case của module quản lý tài nguyên

Đối tượng RESOURCE_MONITOR_OBJECT

Hình 3.21 - Lớp RESOURCE_MONITOR_OBJECT

Việc lƣu trữ đối tƣợng RESOURCE_MONITOR_OBJECT đảm bảo các yêu cầu cho module quản lý proxy:

 Tại một thời điểm chỉ có một tuyến quảy lý module.

 Cung cấp giao diện thông tin và quản lý module (lấy trạng thái từ trƣờng status).

 Module có thể chạy ngầm định hay có thể chạy khi có yêu cầu của ngƣời quản trị.

3.4.6.4 Kết luận

Module đƣợc thử nghiệm và đảm bảo các yêu cầu:

 Là hệ thống quản lý tập trung, độc lập với chính sách quản lý tài nguyên của từng DataNode

 Chỉ có duy nhất một tuyến quản lý module tại mỗi thời điểm

 Module có khả năng tự động cập nhật thông tin về cách thành phần mới đƣợc thêm vào hệ thống mà không phải khởi động lại.

 Có khả năng mở rộng: khi hệ thống có yêu cầu lấy các trạng thái mới, module có khả năng thực hiện yêu cầu mà không phải khởi động lại.

 Cung cấp thông tin hoạt động của module, giao diện để khởi động lại module.

quá trình xây dựng tầng lƣu trữ và tầng ứng dụng web, cũng nhƣ việc kết nối giữa hai tầng này cũng đã đƣợc đề cập chi tiết. Dựa theo kịch bản sử dụng, hệ thống LindaX đã đƣợc triển khai thực tế. Chƣơng này đi sâu vào việc triển khai tầng lƣu trữ lƣới và tầng ứng dụng web cụ thể nhƣ thế nào để có đƣợc hệ thống lƣu trữ và chia sẻ dữ liệu LindaX.

4.1 Triển khai và thử nghiệm

4.1.1 Kịch bản triển khai

Hình 4.1 – Kịch bản triển khai LindaX 4.1.2 Ứng dụng web

Máy chủ ứng dụng web có các lớp nghiệp vụ nhƣ sau: Tầng ứng dụng web

Tầng lƣu trữ lƣới

202.191.56.49

202.191.56.48

4.1.2.1 Lớp biên

# Tên Thư mục File Mô tả

1 UserManagePage Web Manage_user.jsp Lớp giao diện quản lý ngƣời dùng. 2 SupplierManagePage Web Manage-

supplier.jsp

Lớp giao diện quản lý nhà cung cấp.

3 SearchPage Web Search.jsp Lớp giao diện tìm kiếm. 4 FileManagePage Web Manage_file.jsp Lớp giao diện quản lý tệp. 5 UploadPage Web Homepage.jsp Lớp giao diện upload tệp.

Dịch vụ định vị bản sao RLS

Chỉ mục định vị bản sao RLI