Thiết kế tổng quan

Một phần của tài liệu Phát triển công cụ giả lập hệ thống content delivery netwwork (Trang 44 - 49)

CHƯƠNG 4 : THIẾT KẾ CỦA BỘ GIẢ LẬP

4.2 Thiết kế tổng quan

Cơng cụ giả lập gồm bốn module chính: Main Module, Server Module, Client Module và Content Provider Module. Hình 7 minh họa thiết kế tổng quan của hệ

thống. Về mặt tổng quát, quá trình chạy bộ giả lập có thể chia thành 3 giai đoạn chính:

khởi tạo, mơ phỏng và đánh giá.

4.2.1 Main Module

Tại giai đoạn khởi tại, bộ giả lập đọc và trích xuất thơng tin như: network topology, các tham số về tài nguyên mạng, chiến lượng caching và các thiết lập khác từ một file thiết lập JavaScript Object Notation (JSON). Main Module sẽ có nhiệm vụ xây dựng mạng ảo, và khởi tạo các replica servers dựa trên thông tin từ file thiết lập. Sau khi đã khởi tạo xong hệ thống CDN và các servers, phụ thuộc vào thiết lập mà cơ chế định tuyến tĩnh hay động sẽ được triển khai cho các routers. Đối với bảng định tuyến tĩnh, công cụ sẽ xây dựng dựa trên giải thuật Dijkstra có trọng số để tìm đường đi ngắn nhất giữa các routers. Trọng số của các đường dẫn được xác định dựa trên bandwidth và delay của nó. Chiến lược định tuyến ở đây được triển khai ở các routers và dùng để mô phỏng cách định tuyến gói tin của nhà mạng ISP. Module này cũng có trách nhiệm giám sát trạng thái của mạng ảo và tổng hợp, đánh giá kết quả thu được sau khi kết thúc q trình mơ phỏng.

4.2.2 Server Module

Server Module đóng vai trị là các replica server trong mạng ảo. Một hệ thống CDN gồm nhiều replica servers. Bên cạnh cơ chế định tuyến ở routers như đã đề cập ở phần trước, một cơ chế định tuyến khác nhằm chuyển hướng yêu cầu của người dùng khi một replica server hiện tại khơng có nội dung được yêu cầu. Thư viện Containernet cung cấp interface kết hợp Docker container với máy ảo của Mininet. Nhờ vào cơ chế này, bộ giả lập có thể triển khai lại các ứng dụng tương tự như trong hệ thống thực.

Tuy nhiên, một điểm cần lưu ý là nếu đây là một ứng dụng CPU-bound và tốn nhiều thời gian để xử lý, nó có thể ảnh hưởng đến khả năng mô phỏng của công cụ. Cụ thể hơn, trên cùng một phần cứng, nếu có nhiều ứng dụng CPU-bound nặng, nó sẽ hạn chế số lượng máy ảo và kích thước mạng ảo mà cơng cụ có thể mơ phỏng trên phần cứng đó. Bên cạnh đó, các ứng dụng HTTP service phổ biến hiện nay như

Apache, Nginx,... thường rất hạn chế trong việc tùy chỉnh và cồng kềnh. Luận văn này cũng phát triển một chế độ khác cho Server Module là một HTTP server tùy chỉnh và

Hybrid Cache [52]. Bên cạnh đó, nó cũng hỗ trợ 2 chiến lược định tuyến cơ bản là: chiến lược đường đi ngắn nhất tới Origin Server và chiến lược color-based [52]. Mỗi

replica server này sẽ có một bảng đổi hướng gói tin và có thể dễ dàng tùy chỉnh bảng

này cho phù hợp chiến lược của hệ thống CDN. Hình 8 minh họa hai loại Server Module như đã mô tả ở trên.

Hình 8: Hai lựa chon cho Server Module

4.2.3 Client Module

Client Module được sử dụng để mô phỏng các hoạt động của người dùng thực. Do hạn chế về mặt tài nguyên phần cứng, một số đặc trưng hành vi của hệ thống thực không thể được mơ phỏng trong mơi trường ảo. Một ví dụ điển hình là cường độ yêu cầu gửi từ người dùng. Nhiều người dùng có thể đồng thời gửi yêu cầu tới hệ thống CDN tại nhiều replica servers. Để có thể xấp xỉ hành vi này, bộ giả lập cung cấp cơ chế bất đồng bộ khi gửi yêu cầu tới hệ thống. Cơ chế này được hiện thực với đa luồng nhằm tăng tốc độ chạy quá trình mơ phỏng. Cơ chế này gồm 4 bước chính sau:

Bước 1: Để mô phỏng hành vi của người dùng, đầu tiên ta cần phải trích xuất

thơng tin và hoạt động của họ từ log file của hệ thống thực. Thông tin địa chỉ IP sẽ được trích xuất thành thơng tin địa lý. Thơng tin về thời gian gửi tin nhắn sẽ được trích xuất theo đơn vị giây.

Bước 2: Với log file thực có thể có tới hàng chục nghìn người dùng hoạt động

cùng một lúc trong mỗi giờ trong ngày. Việc tạo ra hàng chục nghìn Client ảo là khơng thực tế trong mơi trường giả lập hạn chế. Do đó, người dùng sẽ được gom cụm dựa vào thông tin về địa chỉ IP và vị trí địa lý của họ và một số lượng

của họ theo thông tin thời gian gửi thành từng nhóm. Mỗi nhóm sẽ tương ứng với một khoảng thời gian nhỏ T.

Bước 3: Các Client ảo sẽ gửi song song và bất đồng bộ tất cả yêu cầu của một

khoảng T và đợi phản hồi từ hệ thống CDN.

Bước 4: Sau khi đã nhận đủ phản hồi hoặc hết thời gian timeout, các Client sẽ thực hiện lại bước 3.

4.2.4 Content Provider Module

Các ứng dụng thực của nhà cung cấp nội dung như là ứng dụng xử lý video, hình ảnh, hay các dịch vụ web cồng kềnh không thể được tái triển khai trên môi trường mô phỏng với hạn chế tài nguyên. Thay vào đó, luận văn phát triển một module ít tốn tài ngun và có khả năng mơ phỏng những chức năng chính của nhà cung cấp nội dung. Cụ thể hơn, những servers của nhà cung cấp nội dung được mô phỏng bởi một Origin Server đa luồng có trách nhiệm tạo nội dung. Khi một Client

yêu cầu một nội dung, yêu cầu đó sẽ chứa cả thơng tin về kích thước và loại nội dung.

Origin Server sẽ chịu trách nhiệm tạo nội dung phù hợp dựa trên thông tin mà yêu cầu

gửi tới.

4.2.5 Tài nguyên mạng

Một vấn đề khác về sự khác biệt giữa môi trường thực và môi trường mô phỏng là tài nguyên mạng. Trong môi trường thực, các đường mạng có thể có bandwidth cao như trong hệ thống CDN của Việt Nam [4]. Trong khi đó, mơi trường mơ phỏng vì sự hạn chế của thư viện Mininet. Mỗi đường dẫn chỉ có thể có bandwidth tối đa 1Ghz. Vậy nên ta cần có một cơ chế điều chỉnh bandwidth và traffic thích hợp để có thể giảm tài nguyên mạng nhưng vẫn có thể mơ phỏng chính xác nhất hành vi của hệ thống.

Cụ thể hơn, ta kí hiệu α là trọng số tỉ lệ giữa bandwidth thực và bandwidth ảo. Trọng số này có thể điều chỉnh tùy thuộc vào sức mạnh phần cứng và quy mô của hệ thống cần giả lập. RLCi và VLCi lần lượt là bandwidth của đường dẫn i trong môi

cầu. Các thơng tin về kích thước nội dung, tài ngun mạng trong mơi trường thực đã được trích xuất từ log file. Để tính kích thước nội dung, tài ngun mạng trong mơi trường ảo ta có cơng thức sau:

4.2.6 Dashboard

Bộ giả lập này cung cấp một dashboard thời gian thực hỗ trợ cho việc giám sát hệ thống mạng, tài nguyên của các Client hay Server trong hệ thống CDN. Dashboard này được phát triển dựa trên công cụ Netdata [53]. Trong phiên bản hiện tại, bộ giả lập chỉ hỗ trợ giám sát cho từng máy ảo riêng lẻ và chưa hỗ trợ tính năng giám sát tổng hợp. Hình 9 minh họa một ví dụ về việc giám sát traffic tại nút router1. Phần trên và dưới của hình 9 tuần tự là traffic vào và ra tại interface eth1 của router1. Những

thông tin này được cập nhật theo thời gian thực.

Một phần của tài liệu Phát triển công cụ giả lập hệ thống content delivery netwwork (Trang 44 - 49)

Tải bản đầy đủ (PDF)

(84 trang)