6. Bố cục luận văn
3.1.5. Cấu hình kết nối cho hệ thống mô phỏng
Do hạn chế về hiệu năng thiết bị, tôi không thể mô phỏng một hệ thống với toàn bộ các thiết bị hỗ trợ OpenFlow. Mô hình tôi xây dựng sẽ gồm 2 khu vực tại lớp chuyển tiếp dữ liệu Data Plane là khu vực mô phỏng bằng Vmware (02 thiết bị) và khu vực mô phỏng bằng GNS3 (02 thiết bị).
Lớp điều khiển sử dụng một máy ảo (sử dụng Vmware Workstation) và cài đặt bộ điều khiển Floodlight. Trong quá trình làm việc máy ảo này luôn phải kết nối với 02 máy ảo giả lập thiết bị định tuyến hỗ trợ OpenFlow do đó tôi sử dụng mạng ảo Vmnet0 (192.168.10.0/24) dành cho kết nối của các thiết bị hỗ trợ OpenFlow.
Kết nối giữa VR01 – VR02; VR02 – VR03 và VR02 – VR04 tôi sử dụng lần lượt các mạng ảo Vmnet1 (10.0.12.0/24); Vmnet2 (10.0.23.0/24) và Vmnet3 (10.0.24.0/24).
Hai thiết bị định tuyến VR03 và VR04 được giả lập bằng GNS3 và được kết nối với nhau qua mạng 10.0.34.0/24 đồng thời VR03 được kết nối với Vmnet2 và VR04 được kết nối với Vmnet3.
Dưới đây là mô hình kết nối giữa các thiết bị trong mô hình giả lập tôi xây dựng:
Hình 3.4. Mô hình kết nối thiết bị mô phỏng 3.1.6. Cấu hình GNS3
Trong mô hình dưới đây, cloud được cấu hình với hai card mạng kết nối với Vmnet2 và Vmnet3 để kết nối hai thiết bị VR03 và VR04 với VR02. Trên các thiết bị VR03 và VR04 tôi chỉ cấu hình các cổng giao tiếp và giao thức định tuyến OSPF:
Hình 3.5. Mô hình mạng sử dụng GNS3
Các cấu hình trên GNS3 đã quá quen thuộc nên tôi sẽ không đưa vào trong nội dung luận văn của mình.
3.2. Phát triển thêm tính năng ứng dụng
Để việc hỗ trợ việc quản lý, thiết lập, thay đổi policy based routing cho các thiết bị thuộc lớp chuyển tiếp dữ liệu (Data Plane) tôi đã phát triển một ứng dụng (thuộc lớp Application Plane). Ứng dụng này sẽ thông qua Floodlight Controller để đẩy các Policy xuống các thiết bị theo thời gian đã được thiết lập, qua đó việc thiết lập, thay đổi Policy sẽ được tự động hóa theo thời gian.
Ứng dụng của tôi được phát triển dựa trên chương trình Avior, một dự án mã nguồn mở được phát triển bởi nhóm nghiên cứu OpenFlow trường Marist/IBM. Tôi đã kế thừa, sửa một số lỗi nhỏ, chỉnh sửa lại giao diện và thêm vào một thành phần chức năng cho chương trình gốc.
Để làm rõ nội dung phát triển thêm, trước hết tôi sẽ mô tả qua về Avior và các tính năng của phần mềm này.
3.2.1. Giới thiệu ứng dụng Avior
Là sản phẩm của một dự án mã nguồn mở để tạo ra ứng dụng hỗ trợ quản trị viên trong việc giám sát, điều hành hệ thống. Avior cung cấp cho quản trị viên giao diện sử dụng khá tiện dụng và dễ hiểu:
Hình 3.6. Giao diện ứng dụng Avior
Qua giao diện này quản trị viên có thể dễ dàng nắm bắt được thông tin hệ thống như thông tin về tình trạng Controller hiện tại, thông tin về số thiết bị kết nối đến Controller và một tính năng hỗ trợ điều khiển hệ thống là Flow Manager. Flow Manager cho phép quản trị viên theo dõi và điều khiển các Flow đã được đẩy xuống các thiết bị ở lớp chuyển tiếp dữ liệu (Data Plane).
Tiếp theo là các Package và Class quan trọng của úng dụng Avior: avior: Hàm chính, nhận giá trị đầu vào và chạy chương trình
view: contains two classes:
o GUI: Giao diện của chương trình chính
o Startup: Chạy chương trình khi không có giá trị đầu vào
Hình 3.7. Giao diện công cụ quản lý, điều khiển luồng (Flow Manager)
controller.floodlight: Lấy thông tin từ Floodlight Controller controller.overview.table: Gồm 04 Class:
o Device: Thông tin về các thiết bị kết nối với Controller
o Flow: Đưa ra thông tin về một Flow
o Port: Đưa ra list Port trên Switch
o Switch: Đưa ra thông tin về các Switch trong danh sách Switch kết nối với Controller
controller.flowmanager.table: Gồm 3 Class:
o Match: Xác định sự phù hợp với yêu cầu
o Action: Thu thập thông tin và định dạng lại nó để có thể hiển thị trên bảng thông tin
o Flow: Đưa các thông tin Flow ra bảng hiển thị model.overview: Gồm 3 Class:
o DeviceSummary: Chức năng điều khiển và hiển thị thông tin tổng quan của các thiết bị
o Port: Chức năng điều khiển và hiển thị thông tin trạng thái các cổng giao tiếp
o Switch: Chức năng điều khiển và hiển thị thông tin trạng thái các Switch model.flowmanager: Gồm 3 Class:
o Match: Quản lý chức năng để phù hợp với các thành phần trong công cụ điều khiển luồng (Flow)
o Action: Quản lý chức năng để thêm, bớt, chỉnh sửa trong công cụ điều khiển luồng (Flow)
o Flow: Quản lý chức năng để xử lý với các luồng trong công cụ điều khiển luồng (Flow)
model.flowmanager.push: Gồm 3 Class:
o Match: Cung cấp chức năng để phù hợp với các thành phần trong công cụ điều khiển luồng (Flow)
o Action: Cung cấp chức năng để thêm, bớt, chỉnh sửa trong công cụ điều khiển luồng (Flow)
o Flow: Cung cấp chức năng để đẩy các luồng hoặc xóa luồng trong công cụ điều khiển luồng (Flow)
view.util: Thư viện chưa những công cụ nhỏ để sử dụng trong View part.
controller.util: Thư viện chưa những công cụ nhỏ được sử dụng trong thành phần điều khiển.
org.eclipse.wb.swt: Standard Widget Toolkit of Eclipse IDE
3.2.2. Tính năng phát triển thêm (Schedule)
Như đã trình bày, mục tiêu lớn nhất trong đồ án của tôi là lập lịch thiết lập, thay đổi policy based routing tự động theo thời gian, mục tiêu này được cụ thể hóa bằng chức năng phát triển thêm của tôi là “Schedule”, một chức năng bổ sung cho công cụ quản lý, điều khiển luồng để đặt lịch đẩy các Flow từ controller xuống các thiết bị.
Ý tưởng thiết kế chức năng:
Người dùng được cung cấp một cửa sổ nhập liệu, trong đó có hai trường thông tin chính là thời gian chạy và đường dẫn các file cấu hình thiết bị. Sau khi người dùng hoàn tất việc nhập liệu, các thông tin này sẽ được lưu vào file “time-schedule.config” theo định dạng:
Time 1 (hh:mm:ss) ; <Config File Path 1> Time 2 hh:mm:ss) ; <Config File Path 2> …
Time n (hh:mm:ss) ; <Config File Path n>
Chương trình sẽ đọc file “time-schedule.config”, nếu thời gian được thiết lập trùng với thời gian hiện tại thì file cấu hình tương ứng sẽ được đẩy xuống thiết bị thông qua Controller.
Giao diện của chức năng Schedule:
Hình 3.9. Giao diện chức năng Schedule
Các Package và class của chức năng Schedule: view.Schedule: Gồm 5 Class:
o AddScheduleDialog: Chức năng tạo bảng nhập thông tin thời gian và đường dẫn file thiết lập Flow;
o ConfigUtil: Đọc thông tin từ file cấu hình “time-schedule.config” và xử lý file cấu hình;
o ScheduleModel: Tạo các đối tượng để làm việc và thuận lợi cho việc tái sử dụng.
o TaskConfigScheduleTable: Tạo bảng tổng hợp những Schdule đã nhập để tiện theo dõi;
o TimeTask: Chạy file cấu hình trong đường dẫn vào thời điểm đã được thiết lập.
3.3. Kết quả thực hiện
Sử dụng tính năng Schdule mới phát triển để giải quyết bài toán điều khiển tuyến đường đi từ VR01 đến VR04 theo thời gian trên môi trường giả lập:
Hình 3.10. Thiết lập thời gian đổi policy based routing trên VR02
Ta thu được kết quả theo mô phỏng như sau:
Hình 3.11. Tuyến đường VR01 VR04 khi tự động đổi policy based routing trên VR02
Như vậy tuyến đường từ VR01 đến VR04 đã tự động chuyển từ VR01
Chương 4. Đánh giá hiệu quả
Để tăng tính chính xác cho quá trình đánh giá hiệu quả của việc sử dụng kiến trúc mạng mới SDN so với kiến trúc mạng phổ biến hiện nay trong việc giải quyết bài toán thiết lập, thay đổi policy based routing tự động theo thời gian, tôi sẽ thực hiện so sánh hai trường hợp dựa trên 4 tiêu chí (Thời gian cài đặt, triển khai; Số lượng nhân sự duy trì; Tính đồng bộ về thời gian; Tính linh hoạt) với các mô hình mạng khác nhau như sau:
4.1. So sánh việc giải quyết bài toán trong các mô hình mạng khác nhau 4.1.1. Mô hình mạng vừa và nhỏ 4.1.1. Mô hình mạng vừa và nhỏ
Mô hình mạng vừa và nhỏ có một số đặc điểm chính sẽ ảnh hưởng đến quá trình so sánh như sau:
- Số lượng thiết bị không lớn
- Không nhiều chủng loại thiết bị khác nhau
Bảng 4.1. So sánh việc giải quyết bài toán trong mô hình mạng vừa và nhỏ Kiến trúc
Tiêu chí
SDN Mạng truyền thống
Chú thích/Diễn giải
Thời gian cài đặt, triển khai
Thấp Thấp - Đối với hệ thống mạng sử dụng kiến trúc SDN: Cài đặt bộ điều khiển (Controller) lên 01 máy chủ; Cài đặt phần mềm hỗ trợ thiết lập, thay đổi policy based routing tự động theo thời gian; Cấu hình địa chỉ IP Controller cho các thiết bị trong hệ thống.
- Đối với hệ thống mạng thông dụng hiện nay: Cài đặt, cấu hình policy based routing tự động theo thời gian cho từng thiết bị trong hệ thống, tuy nhiên do số lượng thiết bị không lớn
Kiến trúc Tiêu chí
SDN Mạng truyền thống
Chú thích/Diễn giải
nên thời gian cài đặt, triển khai hệ thống là thấp.
Số lượng nhân sự duy trì
Thấp Thấp Đối với mô hình mạng vừa và nhỏ, do đặc trưng về số lượng và chủng loại thiết bị không lớn nên không cần nhiều nhân sự duy trì hệ thống. Tính đồng bộ
về thời gian
Cao Cao Đối với hệ thống sử dụng kiến trúc SDN thì các policy được phần mềm hỗ trợ từ lớp ứng dụng thông qua Controller đẩy xuống các thiết bị nên thời gian áp dụng policy cho các thiết bị trong hệ thống là đồng nhất.
Ngược lại, với hệ thống mạng thông dụng hiện nay, mỗi thiết bị được cấu hình thời gian riêng biệt nên chắc chắn sẽ có sai số về thời gian áp dụng policy cho các thiết bị, tuy nhiên với hệ thống mạng vừa và nhỏ sai số này là không đáng kể và dễ dàng hiệu chỉnh.
Tính linh hoạt Cao Trung bình Khi muốn thay đổi policy based routing tự động theo thời gian cho các thiết bị trong hệ thống, nếu sử dụng hệ thống sử dụng kiến trúc SDN chỉ cần thao tác trên phần mềm hỗ trợ, ngược lại nếu sử dụng hệ thống mạng thông
Kiến trúc Tiêu chí
SDN Mạng truyền thống
Chú thích/Diễn giải
dụng hiện nay phải cấu hình trên từng thiết bị.
4.1.2. Mô hình mạng có quy mô lớn tập trung
Mô hình quy mô lớn tập trung có một số đặc điểm chính sẽ ảnh hưởng đến quá trình so sánh như sau:
- Số lượng thiết bị lớn
- Nhiều chủng loại thiết bị khác nhau - Các thiết bị tập trung tại một khu vực
Bảng 4.2. So sánh việc giải quyết bài toán trong mô hình mạng có quy mô lớn tập trung Kiến trúc Tiêu chí SDN Mạng truyền thống Chú thích/Diễn giải
Thời gian cài đặt, triển khai
Thấp Trung bình - Đối với hệ thống mạng sử dụng kiến trúc SDN: Cài đặt bộ điều khiển (Controller) lên 01 máy chủ; Cài đặt phần mềm hỗ trợ thiết lập, thay đổi policy based routing tự động theo thời gian; Cấu hình địa chỉ IP Controller cho các thiết bị trong hệ thống.
- Đối với hệ thống mạng thông dụng hiện nay: Cài đặt, cấu hình policy based routing tự động theo thời gian cho từng thiết bị trong hệ thống, trong mô hình mạng này số lượng thiết bị lớn nhưng tập trung tại một địa điểm nên thời gian cài đặt sẽ không quá lớn.
Kiến trúc Tiêu chí SDN Mạng truyền thống Chú thích/Diễn giải Số lượng nhân sự duy trì
Thấp Trung bình - Với hệ thống sử dụng kiến trúc SDN: Toàn bộ hệ thống được quản lý bởi Controller và các thiết bị được tập trung trong một khu vực do đó việc duy trì hoạt động cho hệ thống sẽ rất thuận lợi, số lượng nhân sự cần thiết để duy trì hệ thống không lớn.
- Với hệ thống mạng phổ biến hiện nay: Các thiết bị được tập trung trong một khu vực tuy nhiên không có công cụ quản lý tập trung tất cả các thiết bị nên các công việc cài đặt, cấu hình vẫn phải thực hiện trên từng thiết bị riêng lẻ, do đó số lượng nhân sự để duy trì hệ thống sẽ khá lớn.
Tính đồng bộ về thời gian
Cao Trung bình - Đối với hệ thống sử dụng kiến trúc SDN: Các policy được phần mềm hỗ trợ từ lớp ứng dụng thông qua
Controller đẩy xuống các thiết bị nên thời gian áp dụng policy cho các thiết bị trong hệ thống là đồng nhất.
- Với hệ thống mạng thông dụng hiện nay: Mỗi thiết bị được cấu hình thời gian riêng biệt nên chắc chắn sẽ có sai số về thời gian áp dụng policy cho các thiết bị, số lượng thiết bị trong
Kiến trúc Tiêu chí
SDN Mạng truyền thống
Chú thích/Diễn giải
hệ thống lớn nên việc hiệu chỉnh sẽ khó khăn hơn.
Tính linh hoạt Cao Thấp Với hệ thống sử dụng kiến trúc SDN thì việc thay đổi policy based routing tự động theo thời gian cho các thiết bị được thực hiện rất linh hoạt và dễ dàng thông qua Controller.
Ngược lại, với hệ thống mạng thông dụng hiện nay ta cần cấu hình trên từng thiết bị, trong mô hình mạng này số lượng thiết bị lớn nên tính linh hoạt sẽ thấp.
4.1.3. Mô hình mạng quy mô lớn phân bố rộng
Mô hình quy mô lớn phân bố rộng có một số đặc điểm chính sẽ ảnh hưởng đến quá trình so sánh như sau:
- Số lượng thiết bị lớn
- Nhiều chủng loại thiết bị khác nhau - Phân bố trên nhiều khu vực khác nhau
Bảng 4.3. So sánh việc giải quyết bài toán trong mô hình mạng có quy mô lớn phân bố rộng Kiến trúc Tiêu chí SDN Mạng truyền thống Chú thích/Diễn giải
Thời gian cài đặt, triển khai
Trung bình
Cao - Đối với hệ thống mạng sử dụng kiến trúc SDN: Cài đặt bộ điều khiển (Controller) lên 01 máy chủ; Cài đặt phần mềm hỗ trợ thiết lập, thay đổi
Kiến trúc Tiêu chí
SDN Mạng truyền thống
Chú thích/Diễn giải
policy based routing tự động theo thời gian; Cấu hình địa chỉ IP Controller cho các thiết bị trong hệ thống, trong mô hình này số lượng thiết bị lớn và phân tán nên quá trình cài đặt ban đầu sẽ mất nhiều thời gian hơn.
- Đối với hệ thống mạng thông dụng hiện nay: Cài đặt, cấu hình policy based routing tự động theo thời gian cho từng thiết bị trong hệ thống, trong mô hình mạng này số lượng thiết bị lớn phân tán tại nhiều địa điểm nên sẽ mất rất nhiều thời gian cho việc cài đặt, cấu hình hệ thống.
Số lượng nhân sự duy trì
Trung bình
Cao - Với hệ thống sử dụng kiến trúc SDN: Toàn bộ hệ thống được quản lý bởi Controller do đó thông thường việc duy trì hoạt động cho hệ thống sẽ rất thuận lợi, tuy nhiên cần thêm một số nhân sự để đảm bảo hoạt động của các thiết bị ở các địa điểm khác khi có sự cố.
- Với hệ thống mạng phổ biến hiện nay: Các thiết bị phân tán, các công việc cài đặt, cấu hình phải thực hiện trên từng thiết bị riêng lẻ, do đó số
Kiến trúc Tiêu chí
SDN Mạng truyền thống
Chú thích/Diễn giải
lượng nhân sự để duy trì hệ thống sẽ rất lớn.
Tính đồng bộ về thời gian
Cao Thấp - Đối với hệ thống sử dụng kiến trúc SDN: Các policy được phần mềm hỗ trợ từ lớp ứng dụng thông qua
Controller đẩy xuống các thiết bị nên thời gian áp dụng policy cho các thiết bị trong hệ thống là đồng nhất.
- Với hệ thống mạng thông dụng hiện nay: Mỗi thiết bị được cấu hình thời gian riêng biệt nên chắc chắn sẽ có sai số về thời gian áp dụng policy cho các thiết bị, số lượng thiết bị trong hệ thống lớn và phân tán nên việc hiệu chỉnh sẽ rất khó khăn.
Tính linh hoạt Cao Thấp Với hệ thống sử dụng kiến trúc SDN thì việc thay đổi policy based routing