Giải pháp và thiết kế

Một phần của tài liệu Tiểu luận môn học tính toán lưới TÌM HIỂU P2P CLOUD (Trang 38)

2. Peer-to-Peer Cloud

2.3.Giải pháp và thiết kế

Các dịch vụ P2P Cloud hiện nay đa số chỉ thuần túy là dịch vụ lưu trữ, ở đây ta sẽ xem xét những giải pháp cho cả hai vấn đề lưu trữ và tính toán

2.3.1. Mô hình hệ thống

Hệ thống gồm tập lớn các nút được nối mạng với nhau. Mỗi nút gồm có một bộ xử lý, RAM, không gian lưu trữ - những khả năng này của mỗi nút không yêu cầu như nhau.

Các users của hệ thống này (là những người sở hữu các nút nút này) sẽ chia sẻ các resources (CPU, RAM, không gian lưu trữ) cho nhau. Một phần mềm được cài đặt trên các máy này sẽ đảm trách nhiệm vụ liên kết các nút, xử lý các yêu cầu resources cũng như việc on/off của các nút có thể xảy ra vào bất cứ thời điểm nào (churn – p2p). Phần mềm này có hai interface chính: một là user interface – thông qua interface này users có thể gửi các truy vấn yêu cầu cho hệ thống, và một là

Hoạt động quan trọng nhất được cung cấp bởi hệ thống P2P Cloud này chính là việc quản lý các phân vùng (cloud con). Tức là một user có thể yêu cầu một phần resources cho một hoạt động nào đó của mình bằng cách gửi một truy vấn cho hệ thống (chẳng hạn như cần 10 nút có CPU có tốc độ 2.5Ghz và RAM 8 GB). Hệ thống sẽ phải kiểm tra xem liệu truy vấn này có thể đáp ứng được không – nếu được thì sẽ cấp phát một cloud cho yêu cầu của user. Nói cách khác cloud toàn cục ở đây sẽ gồm nhiều cloud con mà được gán theo các yêu cầu của users và những cloud con này sẽ là động do các users có thể yêu cầu lại các lát (partitions) lớn hơn hoặc nhỏ lại.

Mỗi khi một phân vùng đã được setup thì owner (user thực hiện truy vấn) có thể tải lên và thực thi những ứng dụng của mình hay là những images của máy ảo (tùy thuộc mức hỗ trợ của cloud) lên trên những nút đó. Các API này sẽ được gọi thông qua user interface tương tự như các IaaS Cloud API thông thường như

Amazon EC2 hay Amazon S3.

Chú ý rằng những nút này được quản lý bởi chính các users đã thực hiện những truy vấn , do đó không có một sự đảm bảo QoS nào được cung cấp ở đây. Vì vậy users phải biết xử lý những kết quả bị fail do những nút bị crash - thông thường điều này tương tự như những đám mây IaaS.

Tuy nhiên hệ thống đám mây P2P đảm bảo liên kết giữa đám mây toàn cục và những phân vùng con. Điều này có nghĩa là trong một phân vùng xảy ra trường hợp có nhiều nút bị fail thì những nút còn lại vẫn thuộc phân vùng đó vẫn có thể tương tác với nhau và cả đám mây toàn cục.

Có thể hình dung đám mây này như những giọt nước – những giọt nước tham gia vào hay rời đi làm đám mây thường xuyên bị thay đổi nhưng vẫn có một hình dạng nhất định. Hay nói cách khác một đám mây P2P là một tập các resources có thể biến đổi liên tục mà được hợp với nhau bằng các giao thức gossip, epidemic.

2.3.2. Kiến trúc

Phần này tập trung vào các thuật toán và giao thức. Hệ thống P2P Cloud được hiện thực bằng một tập các processes tương tác với nhau đồng nhất, mỗi process được chạy trên một host riêng biệt. Tức là một phần mềm gồm các modules (tổ chức theo cấu trúc như hình sau) sẽ được chạy trên mỗi nút (màu xám là những modules mà tác giả đã implemented).

Peer Sampling Service (PSS)

Module này sẽ cung cấp cho mỗi nút một danh sách các peers để mà có thể giao tiếp trao đổi với nhau. PSS được implemented theo kiểu giao thức gossip [5]. Giao thức này đơn giản như sau:

Mỗi nút sẽ có một danh sách k nút hàng xóm, gọi là local view. Mỗi phần tử (hàng xóm) trong local view này sẽ có một ID (chẳng hạn như địa chỉ IP) và nhãn thời gian cho biết thời điểm được thêm vào local view. Sau một khoảng thời gian, những hàng xóm này sẽ trao đổi thông tin local view của chúng với nhau và hợp

lại với nhau, bằng cách loại bỏ đi những hàng xóm nào mà có nhãn thời gian cũ nhất để giữ cho số lượng hàng xóm của mỗi nút luôn bằng k. Do đó, tập hàng xóm của mỗi nút luôn luôn động và bằng giao thức gossip này thì PSS luôn giữ được một sự kết nối giữa các nút – cập nhật cho hiện tượng tham gia và bỏ đi liên tục của các nút vào hệ thống.

Tuy nhiên vào lúc ban đầu thì các peer không biết không thể xác định được các nút khác trong Cloud – tức là ai là hàng xóm của mình. Do đó Bootstrpping Service [6] sẽ đảm trách vấn đề này, thường thì sử dụng một file chứa danh sách các địa chỉ IP của các nút để boot (dịch vụ này còn hay được gọi là “cold boot”).

Slicing Service (SS)

Service này dùng để xếp hạng các nút theo các tiêu chí nào đó và được sử dụng trong trường hợp users yêu cầu cung cấp một đám mây con theo các tiêu chí như cần 1% các nút có CPU nhanh nhất hay băng thông upload lớn hơn 100kbs, …

Aggregation Service (AS)

Service này sẽ tính các thông số toàn cục như số lượng nút trong đám mây, tải trung bình, số lượng đám mây con, … bằng cách sử dụng các thông điệp trao đổi giữa các nút với nhau, cụ thể như sau: mỗi nút p sẽ có một giá trị sp (giá trị này có

thể là giá trị đơn hay giá trị phức gồm có băng thông tải, số đám mây con, … của nút đó); sau mỗi khoảng thời gian nhất định thì sp sẽ được gửi đến cho tất cả hàng

xóm của p (sử dụng PSS). Khi đó một hàng xóm q nhận được giá trị sp này sẽ cập

nhật giá trị sq của mình sq UPDATE(sq , sp). Hàm UPDATE này tùy thuộc vào giá trị toàn cục muốn tính mà được implemented. Ví dụ như UPDATE(x, y) := (x +

y) / 2 tức là muốn tính giá trị trung bình của tất cả giá trị cục bộ, với x, y là giá trị

đơn của 2 nút.

Monitoring System

Monitoring System được implemented trên đỉnh của AS để cung cấp các giá trị toàn cục cho users thông qua một API. Ngoài ra API có hỗ trợ hai thao tác là start và stop cho việc hiển thị các giá trị toàn cục này đến users.

T-Man

T-Man cũng là một giao thức dạng gossip được dùng để tạo ra một network theo một đồ hình nào đó chẳng hạn như tree, ring, mesh, ... Ở đây hệ thống sử dụng T- Man để liên kết các nút trong cùng một phân vùng lại với nhau theo một đồ hình nào đó. Chú ý PSS liên kết các nút ban đầu theo một đồ hình ngẫu nhiên (không có quy tắc nào cả). Xem ví dụ hình phía dưới, ta có 9 nút kết nối với nhau được quản lý bởi PSS. Có một user yêu cầu tạo ra một đám mây con với 3 nút thì hệ thống sẽ chọn ra các nút theo đúng yêu cầu của user (như hình là nút 1, 2 và 4) và tạo ra một overlay theo đồ hình ring.

Khi có một nút trong phân vùng bị down thì T-Man sẽ loại nút đó ra khỏi ring và các nút còn lại sẽ được kết nối lại với nhau. (adsbygoogle = window.adsbygoogle || []).push({});

Dispatcher

Đơn giản là nhận các yêu cầu của users thông qua các user interface và chuyển các yêu cầu này đến đúng các lệnh của các giao thức gossip (những lệnh này sẽ gửi các thông điệp đến các nút khác)

Instance Management API

Là interface cho phép users quản lý các resources instances như tạo một instance mới, kết thúc một instance đang chạy hay liệt kê các chủ sở hữu những resources này, … Instance ở đây là những resources mà một user đã yêu cầu Cloud được tạo ra, instance có thể hiểu như là một server ảo để đáp ứng nhu cầu gì đó của user.

Storage SystemStorage API

Hệ thống này cũng giải quyết vấn đề với không gian lưu trữ thông qua 2 modules là Storage System và Storage API. Một số hệ thống dạng này với những đặc trưng riêng đã được đề cập tại đây [3]. Ở đây ta xem qua một số vấn đề trong thiết kế của hệ thống lưu trữ P2P:

o Tính đối xứng: với P2P thì vai trò mọi nút sẽ như nhau không như trong mô hình bất đối xứng là client-server.

o Tính phân tán: đây là bản chất của P2P do đó hệ thống có các cơ chế lưu trữ, xử lý phân tán. Với tính chất này thì hệ thống gia tăng tính mở rộng, đàn hồi (khả năng phục hồi lỗi) và tính sẵn sàng cao. Tuy nhiên như thế thì hành vi của hệ thống là bất định. Ngoài ra, khó khăn trong việc xác định,

view hệ thống ở mức toàn cục (ở trên đã có module giải quyết vấn đề này dựa theo giao thức gossip).

o Những peers không mong muốn. Một vấn về quan trọng trong hệ thống lưu trữ P2P là các nút có thể bị down bất cứ lúc nào và họ có thể xóa các file lưu trữ ra khỏi hệ thống. Do đó hệ thống cần phải được thiết kế đủ mạnh để chống lại vấn đề này (về mặt kỹ thuật lẫn chính sách).

o Một số vấn đề khác như làm cách nào xác định vị trí resources nhanh chóng hay cân bằng tải, … [3].

Authentication

Cuối cùng là tầng chứng thực để tăng cường một số vấn đề bảo mật và tính tin cậy của peers.

Ở trên các modules được tô đen là những modules đã được các tác giả implemented, còn lại những modules để trắng thì vẫn chưa. Source code có thể xem tại đây http://cloudsystem.googlecode.com/svn/trunk/source/

Một phần của tài liệu Tiểu luận môn học tính toán lưới TÌM HIỂU P2P CLOUD (Trang 38)