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.

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

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