Cơ chế quyết định cân bằng tải giữa các bộ điều khiển trong mô hình SDN phân tán

ĐẠI HỌC QUỐC GIA TP. HCM
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

BÁO CÁO TỔNG KẾT
ĐỀ TÀI KHOA HỌC VÀ CÔNG NGHỆ SINH VIÊN NĂM 2019

Tên đề tài tiếng Việt:

CƠ CHẾ QUYẾT ĐỊNH CÂN BẰNG TẢI GIỮA CÁC BỘ ĐIỀU
KHIỂN TRONG MƠ HÌNH SDN PHÂN TÁN
Tên đề tài tiếng Anh:

LOAD BALANCING DECISION MAKING MECHANISM FOR
CONTROLLERS IN DISTRIBUTED SDN ARCHITECTURE
Khoa: Mạng máy tính và truyền thơng
Thời gian thực hiện: 06 tháng
Cán bộ hướng dẫn: ThS. Phan Thế Duy
TT

Họ và tên, MSSV

Chịu trách
nhiệm

Điện thoại

Email

1

Huỳnh Phú Quí

0903026931



2

Trần Minh Khoa

0354653773




Thành phố Hồ Chí Minh – Tháng

07 /2019


ĐẠI HỌC QUỐC GIA TP. HCM
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

Ngày nhận hồ sơ
Mã số đề tài
(Do CQ quản lý ghi)

BÁO CÁO TỔNG KẾT

Tên đề tài tiếng Việt:

CƠ CHẾ QUYẾT ĐỊNH CÂN BẰNG TẢI GIỮA CÁC BỘ ĐIỀU
KHIỂN TRONG MƠ HÌNH SDN PHÂN TÁN
Tên đề tài tiếng Anh:

LOAD BALANCING DECISION MAKING MECHANISM FOR
CONTROLLERS IN DISTRIBUTED SDN ARCHITECTURE

Ngày tháng năm 2019
Cán bộ hướng dẫn
(Họ tên và chữ ký)

Ngày tháng năm 2019
Sinh viên chủ nhiệm đề tài
(Họ tên và chữ ký)



THƠNG TIN KẾT QUẢ NGHIÊN CỨU

1. Thơng tin chung:
- Tên đề tài: Cơ chế quyết định cân bằng tải giữa các bộ điều khiển trong mơ hình SDN
phân tán.
- Chủ nhiệm: Huỳnh Phú Q
- Cơ quan chủ trì: Trường Đại học Công nghệ Thông tin.
- Thời gian thực hiện: 06 tháng
2. Mục tiêu
2.1. Lý do chọn đề tài
SDN (Software-Defined Networks) nhận được sự quan tâm to lớn trong những năm
gần đây. Đối với kiến trúc mạng SDN chỉ có duy nhất một bộ điều khiển, điểm yếu của
nó nằm ở các vấn đề về khả năng mở rộng và độ tin cậy. Từ đó, các kiến trúc mạng

SDN với bộ điều khiển phân tán xuất hiện. Tuy nhiên, một hạn chế chính của bộ điều
khiển phân tán là việc ánh xạ giữa thiết bị chuyển mạch và bộ điều khiển được cấu hình
tĩnh, từ đó gây ra sự phân phối tải không đồng đều giữa các bộ điều khiển.
2.2. Mục tiêu tổng quan
Mục tiêu của khóa luận là nhằm để xây dựng cơ chế trao đổi, xử lý thông tin tải, ra
quyết định phân phối tải cân bằng giữa các controller trong kiến trúc mạng SDN với
bộ điều khiển phân tán nhằm đảm bảo hệ thống mạng SDN hoạt động một cách tối ưu.
Đề tài sẽ tập trung trong việc tính tốn tải và tìm ra giá trị ngưỡng phù hợp để đưa đến
quyết định cân bằng tải. Bên cạnh đó cũng tối ưu trong việc lựa chọn switch và
controller đích nhằm tối ưu hiệu suất và thời gian cân bằng tải.
2.3. Mục tiêu cụ thể
Mục tiêu 1: Hiểu được cách thức vận hành của mạng SDN, có thể cài đặt và chạy với
mơ hình cơ bản.
Mục tiêu 2: Tìm ra các vấn đề liên quan còn tồn đọng trong những nghiên cứu trước
đó, đưa ra những giải pháp cụ thể cho những vấn đề đó và lựa chọn mơi trường phù
hợp để tiến hành hiện thực hóa giải pháp.
Mục tiêu 3: Xây dựng được mơ hình các controller có thể tương tác trao đổi dữ liệu với
nhau. Tìm ra được giá trị ngưỡng hợp lý và chọn ra được controller phù hợp để xử lý
các traffic đến từ controller bị quá tải.
Trang 1


Mục tiêu 4: Nhìn nhận lại giải pháp đề ra. Đưa ra tác động của giải pháp đối với những
vấn đề trước đó và những hạn chế của giải pháp hiện tại.
3. Tính mới và sáng tạo
3.1. Phân tích hiện trạng
Hiện nay các nghiên cứu về viêc quyết định cân bằng tải có thể chia làm 2 loại: quyết
định tập trung và quyết định phân tán. Đối với quyết định tập trung thì cần phải thực
hiện qua 2 bước: đầu tiên phải thu thập thông tin tải của tất cả controller, sau đó gửi
quyết định cân bằng tải đến controller đang quá tải. Bài báo “A Load Balancing

Mechanism for multiple SDN Controllers based on Load Informing Strategy” đã đề
xuất cơ chế cân bằng tải dựa trên quyết định phân tán. Giải pháp của bài báo đã đạt
được 2 mục đích là cân bằng tải giữa những controller và giảm thời gian cân bằng. Tuy
nhiên giải pháp trên chỉ mới thực nghiệm trên hai controller nên không chắc chắn hiệu
suất đảm bảo khi số lượng controller tăng lên.
Ở bài báo “Load Balancing for Multiple Controllers in SDN Based on Switches Group”
, giải pháp được đề xuất là mơ hình cân bằng tải dựa trên một nhóm switch nhắm tới
việc giải quyết vấn đề biến động tải và cải thiện thời gian cân bằng tải. Phương pháp
quyết định cân bằng tải được sử dụng trong bài báo trên là quyết định tập trung và cũng
chỉ áp dụng trên hai controller. Do chỉ tập trung vào việc tối ưu trong việc lựa chọn
switch và controller đích để chuyển tải đến nên vấn đề khi nào cần phải cân bằng tải
chưa được nói rõ.
3.2. Phân tích các cơng nghệ
Cả hai bài báo đề cập ở trên “A Load Balancing Mechanism for multiple SDN
Controllers based on Load Informing Strategy” và “Load Balancing for Multiple
Controllers in SDN Based on Switches Group” đều sử dụng Mininet để mô phỏng môi
trường với các switch chạy giao thức OpenFlow và Floodlight Controller một bộ điều
khiển SDN mã nguồn mở được xây dựng trên nền tảng Java. Ngoài ra cả hai bài báo
cịn sử dụng Cbench để đo số gói PACKET_IN tối đa mà Controller có thể xử lý được
và Hping để buộc switch tạo ra gói PACKET_IN gửi đến Controller. Và để đảm bảo
các Controller khác nhau có thể giao tiếp được với nhau thì những bài báo nêu trên sử
dụng jGroup để giao tiếp với nhau.
Nhóm cũng sử dụng các công cụ tương tự như trên để tiến hành nghiên cứu tuy nhiên
nhóm khơng sử dụng jGroup mà sử dụng Apache Zookper để làm trung gian giao tiếp
giữa những Controller. Với Zookper có thể hỗ trợ được trên nhiều ngơn ngữ khác trong
khi đó jGroup chỉ hỗ trợ trên Java.
3.3. Tính mới và sáng tạo của đề tài
Vấn đề cân bằng tải giữa những controller vẫn còn nhiều khía cạnh để khai thác. Các
cơng trình trước đây đã đề xuất các phương pháp cân bằng tải bằng cách chuyển các
Trang 2

thiết bị chuyển mạch sang bộ điều khiển khác để giải quyết vấn đề này. Tuy nhiên, các
cơng trình trước đây chỉ mới đưa ra ý tưởng hoặc chỉ hiện thực hóa với mơ hình có hai
controller. Việc chỉ có hai controller trong mơ hình sẽ khiến cho cơ chế chuyển đổi
switch gặp nhiều hạn chế và thiếu sự lựa chọn.
Nội dung mà đề tài hướng đến là xây dựng mơ hình hoạt động với nhiều controller hơn
và áp dụng phương thức quyết định tập trung. Trong khóa luận này, nhóm sinh viên sử
dụng mơ hình mạng SDN với bốn controller kèm theo tính tốn giá trị mất cân bằng
tải để đưa ra quyết định thực hiện cân bằng tải hay không. Nếu quyết định sẽ thực hiện
cân bằng tải, switch đang gây quá tải sẽ được chuyển sang controller khác để cân bằng
tải cho mạng SDN.
Đề tài sẽ tập trung trong việc tính tốn tải và tìm ra giá trị ngưỡng phù hợp để đưa đến
quyết định cân bằng tải. Bên cạnh đó cũng tối ưu trong việc lựa chọn switch và
controller đích nhằm tối ưu hiệu suất và thời gian cân bằng tải.
4. Tóm tắt kết quả nghiên cứu:
4.1. Đặc tả kỹ thuật
Nhóm xây dựng mơ hình mạng tập trung về mặt logic với 4 controller phân tán về mặt
vật lý. Ý tưởng ban đầu mạng sẽ gồm tất cả 12 switch được nối với nhau và mỗi
controller sẽ có vai trị là MASTER của 3 switch và là SLAVE của 9 switch còn lại.
Và trong 4 controller sẽ có 1 controller đóng vai trị là supreme, nhóm chọn là controller
1 (C1), controller này sẽ giữ nhiệm vụ chính trong việc thu thập và đưa ra quyết định
cân bằng tải.
Thông tin cụ thể mô tả trong bảng sau:

S1, S2, S3
S4, S5, S6
S7, S8, S9
S10, S11,
S12

Controller 1
(C1)
MASTER
SLAVE
SLAVE
SLAVE

Controller 2
(C2)
SLAVE
MASTER
SLAVE
SLAVE

Controller 3
(C3)
SLAVE
SLAVE
MASTER
SLAVE

Controller 4
(C4)
SLAVE
SLAVE
SLAVE
MASTER

4.2. Thiết kế hệ thống

Để giải quyết vấn đề cân bằng tải nhóm đề xuất xây dựng một mơ-đun gọi là Load
Balancing Module. Mô-đun này sẽ gồm 5 phương thức chính là Load Measurement,
Load Informing, Load Gathering, Load Balancing Decision Maker, Switch Migration.
Load Measurement đảm nhiệm vai trị tính tốn tải trên từng controller và sử dụng
phương thức Load Informing để thơng báo giá trị tải này cho Controller chính thơng
qua trung gian. Và ở controller chính lấy giá trị mà các Controller khác thông báo đến
qua một bên thứ ba bằng phương thức Load Gathering. Tại đây phương thức Load
Trang 3


Balancing Decision Maker đóng vai trị tính tốn các giá trị thu thập được dựa trên
thuật toán được thiết lập sẵn sẽ đưa ra quyết định cân bằng tải. Nếu phải cân bằng thì
phương thức Switch Migration sẽ đảm nhiệm vai trị thực hiện q trình cân bằng. Mối
quan hệ giữa những mơ-đun này được thể hiện trong Hình 1. Kiến trúc đề xuất thực
hiện quá trình cân bằng tải.
4.3. Thiết kế chi tiết
 Tính tốn và trao đổi thơng tin tải:
Mỗi controller có nhiệm vụ tính tốn tải của từng switch kết nối tới controller thông qua
phương thức Load Measurement và định kỳ các thông tin này được gửi đến hệ thống
giao tiếp trung gian thông qua phương thức Load Informing. Đối với phương thức Load
Gathering có nhiệm vụ thu thập tải bằng cách lấy giá trị mà các controller khác đã gửi
đến hệ thống giao tiếp trung gian.
Trong mạng SDN, việc xử lý gói PACKET_IN chiếm lượng tải trọng yếu của controller.
Vì vậy, nhóm nghiên cứu sẽ sử dụng số lượng gói PACKET_IN mà một switch gửi đến
controller để đại diện cho tải của switch và tổng số tải các switch nối đến controller đại
diện cho tải của controller đó. Tuy nhiên vì một controller sẽ kết nối với nhiều switch
nhưng với vai trò khác nhau nên tải của controller là tổng tải của các switch mà
controller giữ vai trị MASTER đối với switch đó. Việc tính tốn tải này được thực hiện
định kỳ với chu kỳ có giá trị là timeInterval.
Ký hiệu trong các công thức bên dưới được chú thích trong bảng sau:

Ký hiệu
𝑳(𝑪𝒊 )
𝑺𝒊,𝒋

Chú thích
Tải hiện tại của controller thứ i
Số PACKET_IN mà switch thứ j gửi đến controller i đó để yêu
cầu xử lý
Mức độ chịu tải của controller thứ i
𝑷𝒓⁡(𝑪𝒊 )
𝒕𝒊𝒎𝒆𝑰𝒏𝒕𝒆𝒓𝒗𝒂𝒍 Chu kỳ thực hiện tính tốn tải
Tải tối đa Controller có thể xử lý mỗi giây, đơn vị là pps
𝑪𝒊,𝒎𝒂𝒙
̅̅̅̅
Mức độ chênh lệch giữa tải ở thời điểm hiện tại và trước đó
𝑨𝑭
Tải của controller thứ i tại thời điểm hiện tại
𝑳(𝑪𝒊𝒕 )
Tải của controller thứ i tại thời điểm trước đó
𝑳(𝑪𝒊𝑻 )
𝒋=𝒏

𝑳(𝑪𝒊 ) = ∑ 𝑳⁡(𝑺𝒊,𝒋 ) ⁡⁡⁡(𝟏)
𝒊,𝒊=𝟏

Trong đó L(C_i ) là tải hiện tại của controller thứ i, S_(i,j) là số PACKET_IN mà switch
thứ j gửi đến controller i đó để yêu cầu xử lý.

Trang 4

𝑷𝒓⁡(𝑪𝒊 ) = ⁡

𝑳(𝑪𝒊 )/𝒕𝒊𝒎𝒆𝑰𝒏𝒕𝒆𝒓𝒗𝒂𝒍
⁡⁡⁡(𝟐)
𝑪𝒊,𝒎𝒂𝒙

Trong đó 𝑷𝒓⁡(𝑪𝒊 ) là mức độ chịu tải của controller thứ i, 𝑪𝒊,𝒎𝒂𝒙 là tải tối đa Controller
có thể xử lý mỗi giây, đơn vị là pps.
Giá trị timeInterval sẽ có biến đổi trong trường hợp số lượng tải tăng lên nhanh khiến
việc cân bằng cần phải nhanh chóng được gọi thực thi. Việc điều chỉnh giá trị này dựa
trên mức độ chênh lệch giữa tải ở thời điểm hiện tại và trước đó. Cơng thức tính tốn
như sau:
𝒏

𝟏
̅̅̅̅ = ⁡ ⁡ × ∑(𝑳 (𝑪𝒊𝒕 ) − 𝑳(𝑪𝒊𝑻 ))⁡(𝟑)
𝑨𝑭
𝒏
𝒊=𝟏

Trong đó 𝑳(𝑪𝒊𝒕 ) là tải của controller thứ i tại thời điểm hiện tại, 𝑳(𝑪𝒊𝑻 ) là tải của
controller thứ i tại thời điểm trước đó.
 Đưa ra quyết định cân bằng tải
Phương thức Load Balancing Decision Maker đảm nhiệm vai trò xử lý các giá trị tải
thu được và đưa ra quyết định cân bằng tải. Phương thức này sẽ đưa ra quyết định cân
̅.
bằng dựa trên việc tính tốn hai giá trị IB và 𝑪
Ký hiệu trong các công thức bên dưới được chú thích trong bảng sau:
Ký hiệu

Chú thích
Giá trị mất cân bằng tải
IB
𝒎𝒂𝒙(𝑳(𝑪𝒊 )) Tải của controller có tải lớn nhất
̅
Giá trị tải trung bình
𝑪
Ngưỡng giá trị tải của switch. Dùng để quyết định sẽ chọn switch
Pthress
này để chuyển đi nhằm cân bằng tải hay không
Mức độ chênh lệch tải giữa controller có tải lớn nhất với controller
∆𝑳𝒊
Ci
𝟏 𝒏
∑𝒊=𝟏 𝑳(𝑪𝒊 )
𝑰𝑩 = ⁡ 𝒏
⁡(𝟒)
𝒎𝒂𝒙(𝑳(𝑪𝒊 ))
Trong đó 𝒎𝒂𝒙(𝑳(𝑪𝒊 )) là tải của controller có tải lớn nhất.
Giá trị 𝑰𝑩 này khi ở một ngưỡng nhất định sẽ thể hiện sự mất cân bằng tải đang diễn ra
giữa những controller, nhóm gọi giá trị ngưỡng này là 𝑰𝑩𝒕𝒉𝒓𝒆𝒔𝒔 .
Giá trị IB chỉ thể hiện đang có sự chênh lệch tải chưa đủ điều kiện để quyết định cân bằng
tải. Trong trường hợp tải của những Controller thấp nhưng vẫn dẫn đến sự chênh lệch tải
thì cân bằng là việc khơng cần thiết. Việc tính tốn giá trị tải trung bình sẽ giúp giải quyết
trường hợp trên. Cơng thức tính giá trị tải trung bình như sau:
𝒏

𝟏
̅ = ⁡ × ∑ 𝑳(𝑪𝒊 ) ⁡(𝟓)
𝑪

𝒏
𝒊=𝟏

Trang 5


Khi giá trị tải trung bình tính từ cơng thức (5) đạt một ngưỡng nhất định thì mới bắt đầu
̅𝒕𝒉𝒓𝒆𝒔𝒔 .
cân bằng, gọi giá trị ngưỡng này là 𝑪
Đối với mơ hình gồm N controller. Giả sử CN là controller có tải lớn nhất, khi đó cơng
thức (4) trở thành:
𝟏 𝑵
∑𝒊=𝟏 𝑳(𝑪𝒊 ) 𝟏 ∑𝑵
𝒊=𝟏 𝑳(𝑪𝒊 )
𝑵
𝑰𝑩 = ⁡
= ∗⁡
⁡
𝑳(𝑪𝑵 )
𝒎𝒂𝒙(𝑳(𝑪𝒊 )) 𝑵

Hiển nhiên giá trị ∑𝑵
𝒊=𝟏 𝑳(𝑪𝒊 ) luôn ln lớn hơn giá trị 𝑳(𝑪𝑵 ) nên ta có
đó, IB >

∑𝑵
𝒊=𝟏 𝑳(𝑪𝒊 )
𝑳(𝑪𝑵 )

> 𝟏. Do

𝟏
𝑵
𝟏

Theo công thức (4) giá trị 𝑰𝑩 luôn luôn lớn hơn . Vậy để đưa ra quyết định cân bằng tải
𝑵

cần thỏa mãn 2 điều kiện là

𝟏
𝑵

̅>𝑪
̅𝒕𝒉𝒓𝒆𝒔𝒔 .
< 𝑰𝑩 < 𝑰𝑩𝒕𝒉𝒓𝒆𝒔𝒔 ⁡ và 𝑪

Từ đó, ta có sơ đồ thuật tốn như Hình 2. Thuật toán đưa ra quyết định cân bằng tải.
Sau khi đã đưa ra quyết định cân bằng tải, việc tiếp theo cần xem xét là quyết định switch
quá tải sẽ được chuyển quyền quản lý cho controller nào. Nhóm dựa theo mức độ chênh
lệch tải giữa controller đích với tải trung bình của các controller. Giá trị này sẽ được tính
theo cơng thức sau:
̅⁡(𝟔)
∆𝑳𝒊 = 𝑳(𝑪𝒊 ) − ⁡ 𝑪
Controller thứ i nào có giá trị ∆𝑳𝒊 ⁡nhỏ nhất sẽ được chọn làm controller đích để chuyển
switch đang quá tải đến.
Tiếp theo, ta cần chọn switch phù hợp thuộc controller đang quá tải để chuyển sang cho
controller khác quản lý. Controller quá tải này sẽ được chọn dựa trên Controller có giá
trị 𝑷𝒓⁡(𝑪𝒊 ) lớn nhất. Switch có tải lớn nhất trong Controller quá tải sẽ được ưu tiên chuyển
đi nhưng nếu tải của switch chiếm trên Pthress tải của Controller q tải thì khơng được

chọn. Bên cạnh đó nếu tải cịn lại của Controller sau khi chuyển switch có tải lớn nhất đi
mà nhỏ hơn tải của Controller có tải nhỏ nhất hiện tại thì switch đó cũng khơng được
chọn mà ưu tiên cho switch có tải lớn tiếp theo.
Đối với mơ hình gồm N controller, giả sử Cx là controller có load cao nhất, Cy là controller
sẽ được chuyển đến. Trước cân bằng ta có:
𝟏 𝑵
𝟏 𝑵
∑𝒊=𝟏 𝑳(𝑪𝒊 )
∑𝒊=𝟏 𝑳(𝑪𝒊 )
𝑵
𝑵
𝑰𝑩𝟏 = ⁡
=
⁡(∗)
𝑳 (𝑪 𝒙 )
𝒎𝒂𝒙(𝑳(𝑪𝒊 ))
Khi thực hiện cân bằng, ta sẽ tiến hành chuyển switch S có L(S) = P * L(Cx) (với P được
tính bằng đơn vị %) từ Cx sang Cy.
Khi đó giá trị IB mới sẽ được tính như sau:
𝟏 𝑵
𝟏 𝑵
∑𝒊=𝟏 𝑳(𝑪𝒊 )
∑ 𝑳(𝑪𝒊 )
𝑵 𝒊=𝟏
𝑰𝑩𝟐 = ⁡ 𝑵
=
⁡(∗∗)
𝒎𝒂𝒙(𝑳(𝑪𝒊 )) 𝑳(𝑪𝒚 ) + 𝑷 ∗ 𝑳(𝑪𝒙 )
Sau khi cân bằng thì giá trị IB sẽ được cải thiện. Từ (*) và (**), ta có:
𝑳(𝑪𝒚 ) + 𝑷 ∗ 𝑳(𝑪𝒙 ) < ⁡⁡𝑳(𝑪𝒙 )

Hay 𝑷 < 𝟏 −

𝑳(𝑪𝒙 )

.

𝑳(𝑪𝒚 )

Trang 6


Do đó, max(Pthress) = 𝟏 −

𝑳(𝑪𝒙 )
𝑳(𝑪𝒚 )

với Cx là controller quá tải và Cy là controller sẽ chuyển

switch đến.
Sơ đồ thuật tốn như Hình 3 .Thuật tốn chọn và chuyển đổi switch.
 Thực hiện chuyển đổi switch
Sau khi đã chọn được switch cần chuyển và controller đích, Switch Migration đảm nhiệm
vai trị chuyển switch này đến controller đích. Q trình này thực chất chỉ là chuyển đổi
quyền từ MASTER thành SLAVE đối với controller bị chuyển và SLAVE thành
MASTER đối với controller đích chuyển đến.
Giả sử switch 4 (S4) được quản lý bởi controller 2 (C2) cần chuyển đến cho controller 3
(C3). C2 sẽ gửi thông báo chuyển đổi switch tới C3. Sau khi C3 nhận được nó sẽ gửi
ROLE_REQUEST đến S4 để yêu cầu chuyển quyền thành EQUAL. Sau đó S4 sẽ gửi
ROLE_REPLY tới C3 và C3 thơng báo cho C2 là quá trình chuyển đổi quyền đã hồn
thành. Tuy nhiên khơng thể chuyển C2 thành SLAVE ngay lập tức vì chưa nhận được

phản hồi về việc chuyển đổi từ C3. Vì vậy C3 tiếp tục giao tiếp với S4 để giải quyết
những việc chưa hoàn thành cho đến khi nó gửi thơng điệp kết thúc chuyển đổi tới C3.
Sau khi nhận được thông điệp này C3 sẽ thay đổi quyền từ EQUAL thành MASTER bằng
việc gửi thông điệp ROLE_REQUEST tới S4. Và S4 sẽ thiết lập C2 thành SLAVE. Q
trình chuyển đổi kết thúc.
4.4. Tích hợp hệ thống và kiểm thử
Mơ hình mạng triển khai như Hình 4. Môi trường triển khai gồm 06 máy ảo giả lập bằng
vSphere 6.5. Cấu hình của sáu máy ảo như sau:
MÁY 01, 02, 03, 04
Chức năng

Dùng làm controller

Cấu hình máy

2 CPU, 4GB RAM

Hệ điều hành

Ubuntu 16.04 LTS
Floodlight Master
Eclipse Photon 06/2018

Phiên bản phần mềm

MÁY 05
Chức năng

Giúp controller giao tiếp và đồng bộ với nhau.

Cấu hình máy

2 CPU, 4GB RAM

Hệ điều hành

Centos 7.6 minimal

Phiên bản phần mềm

Apache Zookeeper 3.5.5

Trang 7


MÁY 06
Chức năng

Chạy mininet mơ phỏng mơ hình mạng

Cấu hình máy

2 CPU, 4GB RAM

Hệ điều hành

Ubuntu 16.04 LTS

Phiên bản phần mềm

Mininet 2.2.1

Để xây dựng mơ-đun nhóm sử dụng cơng cụ Eclipse Photon để thuận lợi trong q trình
làm việc. Nhóm xây dựng một mô-đun gọi là Load Balancing Module bên trong
controller, để chạy mô-đun này chỉ cần khai báo tên trong danh sách các mô-đun được
tải của controller và tự động chúng sẽ được thực thi khi controller khởi chạy. Ở Zookeeper
sẽ tạo 4 node tương ứng với 4 controller để lưu trữ các thông điệp mà controller gửi đến.
Mô-đun sẽ định nghĩa một tiến trình để gửi nhận thơng điệp cũng như xử lý và thực hiện
quá trình cân bằng tải. Tiến trình này chạy theo chu kỳ và có thể thay đổi tùy vào độ
chênh lệch tải giữa 2 chu kỳ tính tốn.
Để kiểm thử các trường hợp mất cân bằng tải nhóm đã sử dụng cơng cụ hping3 để tăng
tải mà các controller phải xử lý. Ở đây nhóm sẽ dùng một host bất kỳ gửi 100000 packet
với kích thước 1000bytes với tốc độ 500 packet mỗi giây cho một host khác trong cùng
controller quản lý. Dựa vào số lượng controller quá tải nhóm tạm chia thành 4 trường
hợp kiểm thử như sau:
Trường hợp 1: Tăng tải trên một controller bất kỳ.
Trường hợp 2: Tăng tải trên hai controller bất kỳ, cụ thể là controller 2 và controller 4.
Trường hợp 3: Tăng tải trên ba controller bất kỳ, cụ thể là controller 2, contronller 3 và
controller 4.
Trường hợp 4: Tăng tải lên tất cả controller.
4.5. Kết quả nghiên cứu
 Tải tối đa bộ điều khiển xử lý
Đầu tiên để tính tốn giá trị 𝑪𝒊,𝒎𝒂𝒙 có thể sử dụng Cbench [6] để tính tốn nhưng đặt
trong trường hợp cụ thể của mơ hình đề xuất giá trị này khơng thể được đo bằng Cbench.
Nhóm đã sử dụng cơng cụ hping3 tiến hành giả lập tấn công buộc switch tạo ra gói
PACKET_IN gửi đến Controller để tìm ra giá trị 𝑪𝒊,𝒎𝒂𝒙 .
Số liệu đo được mô tả trong bảng sau đơn vị là pps:
 Bảng 0-1 Tính tốn giá trị tải tối đa trên từng controller
Lần 1
Lần 2

Lần 3

Controller 1
10064
12409
11973

Controller 2
9545
9772
11857

Controller 3
11481
13141
8229

Controller 4
11220
8846
9636
Trang 8


Trung
bình

11482

10392

10905

9900

 Giá trị ngưỡng gây mất cân bằng tải
Nhóm tính toán theo 4 trường hợp kiểm thử đề xuất trước đó, gồm:
Trường hợp 1: Tăng tải trên một controller bất kỳ.
 Bảng Tính tốn giá trị IB khi tăng tải trên một controller
Tải của
Thời
Controller 1
điểm
(gói)
14s
4
28s
8
42s
4
56s
4
70s
0

Tải của
Controller 2
(gói)
4
8

4
4
0

Tải của
Controller 3
(gói)
9992
19079
47158
31610
51397


Tải của
Controller 4
(gói)
4
4
4
8
4

IB
0.25030023
0.25026208
0.25006363
0.25012654
0.25001946

Trường hợp 2: Tăng tải trên hai controller bất kỳ, cụ thể là controller 2 và controller 4.
Bảng 0-1 Tính toán giá trị IB khi tăng tải trên hai controller
Tải của
Tải của
Tải của
Tải của
Thời
Controller Controller
Controller Controller
IB
điểm
1 (gói)
2 (gói)
3 (gói)
4 (gói)
14s
12
8763
8
22538
0.34742436
28s
4
43477
4
5997
0.28452975
42s
4
43115

8
34089
0.4477328
56s
4
20473
4
37918
0.3850348
70s
0
14235
4
11551
0.45293292
Trường hợp 3: Tăng tải trên ba controller bất kỳ, cụ thể là controller 2, contronller 3 và
controller 4
Bảng 0-2 Tính toán giá trị IB khi tăng tải trên bacontroller
Tải của
Tải của
Tải của
Tải của
Thời
Controller 1 Controller 2 Controller 3 Controller 4 IB
điểm
(gói)
(gói)
(gói)
(gói)
14s

0
29820
23780
10780
0.5397384
28s
4
34003
5889
12224
0.38320148
42s
4
6458
31444
15783
0.42686203
56s
4
4080
21855
12068
0.43476322
70s
4
29995
5165
12728
0.39916652
Trường hợp 4: Tăng tải lên tất cả controller

Bảng 0-3 Tính tốn giá trị IB khi tăng tải trên tất cả controller
Trang 9


Thời
điểm
14s
28s
42s
56s
70s

Tải của
Controller 1
(gói)
21610
5551
20922
21837
7347

Tải của
Controller 2
(gói)
1275
18402
8638
27213
29649

Tải của
Controller 3
(gói)
20908
5457
13577
32497
7257

Tải của
Controller 4
(gói)
9824
15028
5652
24443
13002

IB
0.62027997
0.6035757
0.58298683
0.81538296
0.48277345

Từ những số liệu đo đạc trên mơ hình đề xuất, nhóm nhận thấy khi giá trị nằm trong
khoảng từ (0.25 - 0.54) là khoảng giá trị chứng tỏ đang có sự chênh lệch tải giữa những
controller trong mạng.
 Ngưỡng giá trị tải trung bình
Để tìm được giá trị này cũng xét các trường hợp tương tự như ở phần trước đã đề cập.

Bảng Tính giá trị ngưỡng trung bình (đơn vị: pps)
Thời
Trường hợp 1
Trường hợp 2
Trường hợp 3
Trường hợp 4
điểm
14s
178.64285
559.3036
1149.6428
957.4464
28s
341.05356
883.6071
930.7143
793.3571
42s
842.3214
1378.8572
958.7321
871.2321
56s
564.75
1042.8392
678.6964
1892.6786
70s
917.875
460.5357

855.2143
1022.4107
Trung 568.928562
865.02856
914.59998
1107.42498
bình
̅𝒕𝒉𝒓𝒆𝒔𝒔 ⁡sẽ có giá trị là 889 pps, thức là trung bình của các
Từ những số liệu đo đạc, 𝑪
trường hợp ở trên.
 Điều chỉnh thời gian thu thập tải
Như đã nói ở trên, giá trị timeInterval sẽ có biến đổi trong trường hợp số lượng tải tăng
lên nhanh khiến việc cân bằng cần phải nhanh chóng được gọi thực thi. Việc điều chỉnh
giá trị này dựa trên mức độ chênh lệch giữa tải ở thời điểm hiện tại và trước đó. Cơng
thức tính tốn như sau:
𝒏

𝟏
̅̅̅̅
𝑨𝑭 = ⁡ ⁡ × ∑(𝑳 (𝑪𝒊𝒕 ) − 𝑳(𝑪𝒊𝑻 ))⁡(𝟑)
𝒏
𝒊=𝟏

Trong đó 𝑳(𝑪𝒊𝒕 ) là tải của controller thứ i tại thời điểm hiện tại, 𝑳(𝑪𝒊𝑻 ) là tải của
controller thứ i tại thời điểm trước đó.
Việc giảm giá trị timeInterval có mục đích giúp quá trình thu thập tải sẽ bắt đầu sớm
hơn thường lệ trong trường hợp tải trong mạng tăng lên nhanh, từ đó q trình cân bằng
tải sẽ được thực hiện sớm hơn thường lệ.
Trang 10

Giá trị 𝑪𝒊,𝒎𝒂𝒙 vào khoảng 10000pps, với timeInterval ban đầu được thiết lập là 14 giây,
̅̅̅̅ như sau:
giá trị timeInterval này sẽ được thay đổi tùy thuộc vào sự tăng giảm của 𝑨𝑭

̅̅̅̅
𝑨𝑭

Thời gian giảm

(0,1000)

0 giây

(1000,2000)

1 giây

(2000,3000)

2 giây

(3000,4000)

3 giây

(4000,5000)

4 giây

(5000,6000)

5 giây

(6000,7000)

6 giây

(7000,8000)

7 giây

(8000,9000)

8 giây

(9000,10000)

9 giây

Lưu ý:
Trước mỗi lần giảm giá trị này lại được trả về mặc định tức là 14 giây.
Cột ̅̅̅̅
𝑨𝑭 thể hiện một khoảng giá trị. Khi ̅̅̅̅
𝑨𝑭 đạt giá trị trong khoảng, timeInterval sẽ
giảm theo giá trị tương ứng ở cột Thời gian giảm.
5. Tên sản phẩm
6. Hiệu quả, phương thức chuyển giao kết quả nghiên cứu và khả năng áp dụng
Trường hợp 1: Controller 3 đang quá tải.
Bảng 6-1 Kết quả sau khi cân bằng khi tăng tải trên một controller

Controller Controller Controller Controller
IB
1 (gói)
2 (gói)
3 (gói)
4 (gói)
Trước khi
4
4
47158
4
0.25006363
cân bằng
Sau khi
28265
4
18897
4
0.41721201
cân bằng
Trường hợp 2: Tăng tải trên hai controller bất kỳ, cụ thể là Controller 2 và Contronller
4.
Trang 11


Bảng 6-2 Kết quả sau khi cân bằng khi tăng tải trên hai controller
Controller Controller Controller Controller
IB
1 (gói)
2 (gói)

3 (gói)
4 (gói)
Trước khi
4
43477
4
5997
0.28452975
cân bằng
Sau khi
25781
17700
4
5997
0.4798301
cân bằng
Trường hợp 3: Tăng tải trên ba controller cụ thể là Controller 2, Controller 3 và
Controller 4
Bảng 6-3 Kết quả sau khi cân bằng khi tăng tải trên ba controller
Controller Controller 2 Controller 3 Controller 4
IB
1 (gói)
(gói)
(gói)
(gói)
Trước khi
4
34003
5889
12224

0.38320148
cân bằng
Sau khi
29006
5001
5889
12224
0.45
cân bằng
Trường hợp 4: Tăng tải trên tất cả Controller
Bảng 6-4 Kết quả sau khi cân bằng khi tăng tải trên tất cả controller
Controller Controller 2 Controller 3 Controller 4
1 (gói)
(gói)
(gói)
(gói)
Trước khi
7347
29649
7257
13002
cân bằng
Sau khi
7347
24068
12838
13002
cân bằng

IB

0.48277345
0.59472120

Sau q trình cân bằng, giá trị IB tăng cao hơn so với trước khi cân bằng ở cả 4 trường
hợp.
7. Hình ảnh, sơ đồ minh họa chính

Trang 12


Hiǹ h 1 Kiến trúc đề xuất thực hiện quá trình cân bằng tải

Hình 1 Thuật tốn đưa ra quyết định cân bằng tải.

Trang 13


Hình 2 Thuật toán chọn và chuyển đổi switch.

Trang 14


Hiǹ h 0 Mơ hình mạng đề xuất.

Cơ quan Chủ trì
(ký, họ và tên, đóng dấu)

Chủ nhiệm đề tài
(ký, họ và tên)

Trang 15