2. Peer-to-Peer Cloud
2.3.3. Đáp ứng resources với thời gian dà
Tuy nhiên hệ thống ở trên vẫn chưa nói rõ giải pháp để giải quyết vấn đề cung cấp resources tin cậy trong thời gian dài (chẳng hạn như 2 tháng) cho users trong khi các peers tham gia vào đám mây P2P được phép online/offline một cách tùy ý và thường thời gian online của các peers là ngắn.
Một giao thức được đề xuất để giải quyết vấn đề này là P3R3O.KOM [2]. Cốt
lõi của giao thức để giải quyết vấn đề trên chính là cấp phát resources dư thừa ra hay có thể hiểu là có thêm các bản backup. Cụ thể hơn diễn ra trong 2 bước như sau:
• Quản lý đặt chỗ: có một tập các peers sẽ đứng ra quản lý trạng thái của tập các providers (một provider ở đây là một bản sao resources – gồm nhiều peers) đang cung cấp resources để mà thích ứng kịp thời với trường hợp churn. Điều này được thực hiện bằng cách dự đoán thời gian sống của các
providers đang cung cấp resources và ngoài ra cũng ước lượng tỉ lệ thành công khi có một peer trong tập peers quản lý này vẫn còn sống cho tới lượt kiểm tra kế tiếp.
• Thực thi đặt chỗ các resources mà user mong muốn với nhiều bản backup.
Các thành phần trong giao thức dùng để khởi tạo, duy trì và phục vụ một yêu cầu resources của user
1) Khởi tạo một yêu cầu: một user sẽ thực hiện một yêu cầu về resources bao gồm các điều kiện về resources như CPU, RAM, … Ở đây có thêm hai tham số là thời gian đặt chỗ resources là bao lâu và mức độ dư thừa (xác suất mà tất cả providers không bị down cùng một lúc). Yêu cầu này sẽ được chuyển tới một peer mà sẽ đảm trách nhiệm vụ quản lý các providers. Peer này là peer đầu tiên trong tập các peer quản lý providers được gọi là peer quản lý chính.
2) Tập quản lý: là các peers quản lý trạng thái các providers. Chúng cũng được lưu trữ dư thừa để phòng ngừa trường hợp peer quản lý chính rời khỏi network. Theo chu kỳ peer quản lý chính này sẽ kiểm tra các peers bản sao còn sống hay không hoặc chọn một peer quản lý chính mới. Peer quản lý chính mới được chọn bằng cách sử dụng chức năng tìm kiếm peer với yêu cầu là thời gian online lâu (chẳng hạn như SkyEye.KOM [7] sử dụng
distributed hash table để lưu trữ các nút và key-based routing để định
tuyến). Về thời gian online của mỗi peers có thể được tính theo xác suất dựa trên một kết quả nghiên cứu thời gian sống của các peers [8] với kết luận rằng thời peer online càng lâu thì xác suất peer vẫn tiếp tục online càng cao. Tương tự như vậy theo chu kỳ các peers bản sao cũng kiểm tra peer quản lý chính còn sống hay không để cập nhật peer quản lý chính mới.
3) Tính xác suất thành công cho một lượt: thành phần này sẽ được peer quản lý chính sử dụng để tính xác suất các providers sẽ online vào lượt kế tiếp
(sau mỗi chu kỳ thời gian sẽ tính xác suất này). Trong trường hợp mà xác suất thành công của providers nhỏ hơn mức độ dư thừa cho trước thì peer quản lý chính phải chọn một tập peers phù hợp khác thêm vào tập providers (4)để đảm bảo xác suất thành công của providers lớn hơn hoặc bằng với mức độ dư thừa. Ngược lại thì chờ tới lượt kế tiếp để tính lại (3).
4) Thêm các providers mới vào. Trước tiên cần phải tính số lượng providers thiếu hụt sau đó sử dụng tính năng tìm kiếm peers dựa yêu cầu như SkyEye.KOM chẳng hạn. Đối với việc tinh số lượng providers thiếu hụt để thêm vào có 2 cách tiếp cận:
o Redundant Peer Approach (RPA): thêm vào một số providers Nbuff theo công thức sau:
o Probalility Buffer Approach (PBA): thêm vào một số providers để mức dư thừa tăng vượt mức 1 chút :
là số providers cần thêm vào để xác suất thành công Psucc (ít nhất một provider vẫn còn sống sau một lượt) lớn hơn RsvDR (tỉ lệ ít nhất một provider vẫn còn sống sau một lượt cho trước) 1 chút.
là hàm đi từ [0, 1] để tính số providers cần thiết để Psucc RsvDR.
Kết quả thử nghiệm của tác giả khá quả quan khi đạt được 100% đáp ứng yêu cầu của user (500MB lưu trữ với 200kb/s upload trong vòng 200 ngày, RsvDR = 0.9) với RPA là 5 hay 6 providers thêm vào và sau 50 phút kiểm tra 1 lần. Kết quả được thử nghiệm trong môi trường 1000/2000/4000 nút với chi phí traffic là rất thấp.
KẾT LUẬN
Bài thu hoạch này em đã giới thiệu điện toán đám mây là gì, đặc biệt tại sao điện toán đám mây lại bùng nổ trong thời điểm hiện nay qua các đặc tính cũng như mô hình dịch vụ.
Sự tăng trưởng nhanh chóng của các thiết bị tính toán cũng như sức mạnh bộ xử lý, băng thông và các tính chất đặc trưng riêng của P2P Cloud đã làm cho chúng trên đà phát triển. Trong P2P Cloud có hai vấn đề chính cần được xem xét đó là làm sao cân bằng resources cho các users cũng như tìm được các peers thích hợp nhất và vấn đề churn. Trong bài đã giới thiệu một thiết kế P2P Cloud của Ozalp Babaoglu, Moreno Marzolla và Michele Tamburini [1]. Tuy nhiên họ không nói rõ cách đối phó với vấn đề đáp ứng resources một cách tin cậy trong thời gian dài do đó cần xem xét một giải pháp bằng cách cung cấp resources dư thừa [2]. Giải pháp này dựa trên một kết quả nghiên cứu là những nút có thời gian online lâu thì đáng tin cậy [8]. Mặc dù thế giải pháp có hạn chế với những yêu cầu resources ngắn hạn. Một giải pháp khác có thể xem xét cho vấn đề tin cậy [9] thông qua một thuật toán dự đoán đơn giản dựa trên dữ liệu sẵn sàng của một nhóm các nút để dự đoán mức tin cậy của một nút.
Mặc dù thế thì việc xử lý resources đặc biệt là các resources về tính toán khi một peer hay nhiều peers bị down vẫn phụ thuộc rất nhiều vào xử lý của users. Do đó những ứng dụng của users cũng như các hệ thống P2P Cloud cần có khả năng đàn hồi để hỗ trợ lẫn nhau.
