6. Bố cục luận văn
3.1.3. Cài đặt OpenvSwitch
Như đã mô tả, OpenvSwitch là một thành phần chuyển mạch được xây dựng trên nhân Linux, ngoài tính năng giả lập một Switch thông thường OpenvSwitch hỗ trợ một số tính năng nâng cao, một trong số đó là hỗ trợ chuẩn mở OpenFlow, nó cho phép Switch nhận lệnh điều khiển từ bộ điều khiển trong tâm (Floodlight Controller). Tương tự với tất cả các phần mềm cài đặt trên nền tảng Linux, ta có thể cài đặt OpenvSwitch theo hai cách là tải gói cài đặt từ trang chủ http://openvswitch.org hoặc cài đặt qua dòng lệnh. Để cập nhật phiên bản mới nhất ta nên sử dụng phương pháp thứ nhất, phương pháp thứ hai đơn giản hơn ta có thể sử dụng những lệnh sau:
# Cài đặt những phần mềm hỗ trợ
# Thêm source cho Ubuntu
$ add-apt-repository ppa:mighost/ppa # Cập nhật source mới
$ apt-get update
# Cài đặt các gói OpenvSwitch
$ apt-get install openvswitch-common openvswitch-datapath-dkms openvswitch-switch
Để kiểm tra phiên bản OpenvSwitch đã cài đặt ta có thể sử dụng lệnh:
$ ovs-vsctl show
Sau khi cài đặt xong OpenvSwitch, để bắt đầu làm việc ta cần tạo Bridge cho Switch và gán các port lên Bridge đó, trong trường hợp mô phỏng của mình, với mỗi Bridge tôi cần một cổng kết nối với Floodlight Controller, do đó trên các máy chủ cài đặt OpenvSwitch tôi sẽ gán eth0 mặc định cho Bridge, còn các cổng vật lý khác sẽ được thiết lập và gán thêm vào Bridge theo yêu cầu của mô hình giả lập, quá trình tạo Bridge và gán cổng vật lý cho Bridge được thực hiện bằng cách chỉnh sửa file text “/etc/network/interfaces” với nội dung như sau:
auto br0 # Tạo Bridge và cấu hình địa chỉ IP
iface br0 inet static # Lựa chọn cấu hình IP tĩnh
address 192.168.10.x network 192.168.10.0 netmask 255.255.255.0
bridge_ports eth0 # Gán cổng eth0 cho Bridge
bridge_fd 9 bridge_hello 2 bridge_maxage 12
# bridge_stp off # Tùy chọn: Nếu topo sử dụng loop thì tắt
Ngoài ra, ta cũng có thể sử dụng các dòng lệnh sau:
$ ovs-vsctl add-br br0 # Thêm Bridge cho OvS
$ ovs-vsctl add-port br0 eth0 # Gán cổng eth0 cho Bridge
$ ifconfig br0 192.168.1.208 netmask 255.255.255.0 # Cấu hình IP cho Bridge
Cấu trúc lệnh “ovs-vsctl add-port br0 <Interface add to Bridge>” sẽ được sử dụng nhiều để thêm các cổng (vật lý và ảo) cho Bridge trong các mục tiếp theo. Sau các bước cấu hình cơ bản và gán cổng cho Bridge, ta cần cung cấp địa chỉ bộ điều khiển trung tâm (Floodlight Controller) cho Bridge trên OpenvSwitch bằng câu lệnh:
$ ovs-vsctl set-controller br0 tcp:192.168.10.3:6633
Dưới đây là mô hình kết nối giữa Floodlight và OpenvSwitch được thiết lập trong giả lập của tôi:
Hình 3.2. Mô hình kết nối Floodlight - OvS 3.1.4. Cấu hình kết nối trong thiết bị định tuyến ảo
Như đã trình bày trong mục 3.3, để mô phỏng một thiết bị định tuyến hỗ trợ OpenFlow ta cần cài đặt OpenvSwitch và Bird lên cùng một máy chủ Linux (Ubuntu 64bit), trong mục 3.3.3 chúng ta cũng đã đưa ra giải pháp để kết hợp OpenvSwitch và Bird trên cùng một máy chủ linux sử dụng các cổng giao tiếp ảo.
Hình 3.3: Kết nối nội bộ thiết bị định tuyến ảo
Trong mục này chúng ta sẽ cụ thể hóa giải pháp đã đưa ra bằng cách cấu hình trên OpenvSwitch và Bird như sau:
a. Gán các cổng cho Bridge (thuộc OvS)
OpenvSwitch là một thiết bị chuyển mạch ảo, như đã trình bày, để OpenvSwitch hoạt động trước hết cần tạo các bridge trên OpenvSwitch sau đó gán các cổng vào Bridge, dưới đây là dòng lệnh để gán các cổng cho Bridge:
$ ovs-vsctl add-port <bridge name> <port name> -- set Interface <port name> ofport_request=<port number>
“Bridge name": Là tên của Bridge đã được tạo trên OpenvSwitch (Trong mô hình của tôi là br0)
“Port name”: Là cổng giao tiếp muốn gán vào cho Bridge, như hình minh họa chúng ta sẽ gán các cổng eth* và OvsVeth* lên Bridge.
“Port number”: Là số hiệu cổng giao tiếp để OpenvSwitch và Floodlight Controller sử dụng để gọi đến cổng giao tiếp đó, nếu không gán các số hiệu thì OpenvSwitch sẽ tự động chọn ngẫu nhiên số hiệu cổng giao tiếp. Trong trường hợp mô phỏng của mình tôi tự cấu hình “Port number” để dễ dàng quản lý trong quá trình thao tác tiếp theo.
Trong mô phỏng của mình tôi gán “Port number” cho các cổng Eth‘n’ là 1n và các cổng OvsVeth‘n’ là n. Dưới đây là ví dụ lệnh gán port tôi sử dụng trong mô phỏng của mình:
$ ovs-vsctl add-port br0 ovs-veth1 -- set Interface ovs-veth1 ofport_request=1 $ ovs-vsctl add-port br0 eth1 -- set Interface eth1 ofport_request=11
b. Cấu hình địa chỉ IP cho các cổng veth* và cấu hình Bird
Theo sơ đồ kết nối mô phỏng trên, lớp Routing (Bird) sẽ kết nối trực tiếp với các cổng Veth*, do đó ta sẽ cấu hình địa chỉ IP cho các cổng Veth*, các cổng đã gán cho Bridge không cần cấu hình địa chỉ IP vì các thao tác xử lý trên Bridge không cần sử dụng đến địa chỉ lớp 3. Câu lệnh để cấu hình địa chỉ IP cho các cổng Veth* đơn giản như sau:
$ ifconfig veth‘n’ <ip address> netmask <…>
Trên Bird ta chỉ cần cấu hình các giao thức định tuyến chạy trên các cổng Veth* trong file bird.conf:
interface "veth*"{
c. Tạo các cặp kết nối Veth* OvsVeth*
Sau khi hoàn thành hai bước cấu hình trên thì coi như ta đã hoàn thành việc cấu hình cơ bản cho hai lớp định tuyến và lớp chuyển mạch, tuy nhiên nhiệm vụ chính là kết nối hai lớp này vẫn chưa hoàn thành. Để kết nối hai lớp này và đảm bảo các
thiết bị hoạt động chính xác ta cần kết nối các cặp cổng tương ứng với nhau. Như mô tả tại sơ đồ, giao tiếp giữa hai lớp được tạo nên bởi các cặp cổng giao tiếp Veth* và OvsVeth*, cấu hình cụ thể như sau:
Trên máy chủ cài đặt Bird và OpenvSwitch:
$ ip link add veth1 type veth peer name ovs-veth1
Đồng thời cần thiết lập các Flow và thông qua Floodlight Controller đẩy xuống OpenvSwitch để thiết lập chính xác các luồng dữ liệu như sau:
"ingress-port":"1" "actions":"output=11" "ingress-port":"11" "actions":"output=1" "ingress-port":"2" "actions":"output=12" "ingress-port":"12" "actions":"output=2" "ingress-port":"3" "actions":"output=13" "ingress-port":"13" "actions":"output=3"
Sau khi hoàn thành các bước cấu hình và các Flow được đẩy xuống OpenvSwitch ta có thể mô tả luồng dữ liệu đến thiết bị như sau:
Data Eth* OvsVeth* Veth* Bird
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