ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

_________________________

Hoàng Tuấn Hùng

CÂN BẰNG TẢI TRONG MẠNG TRUNG TÂM DỮ LIỆU

SDN SỬ DỤNG OPENDAYLIGHT CONTROLLER

KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Công nghệ kỹ thuật điện tử, truyền thông

HÀ NỘI – 2019

 ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Hoàng Tuấn Hùng

CÂN BẰNG TẢI TRONG MẠNG TRUNG TÂM DỮ LIỆU

SDN SỬ DỤNG OPENDAYLIGHT CONTROLLER

KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Công nghệ kỹ thuật điện tử, truyền thông

Cán bộ hướng dẫn: PGS. TS. Nguyễn Nam Hoàng

HÀ NỘI – 2019

 LỜI CAM ĐOAN
Trong quá trình làm đồ án này tôi đã đọc và tham khảo rất nhiều tài liệu khác nhau
từ giáo trình, sách tham khảo cho tới rất nhiều các bài báo uy tín được đăng tải trong và
ngoài nước. Tôi xin cam đoan những gì tôi viết dưới đây là hoàn toàn chính thống, chân
thực. Những kết quả đo đạc mô phỏng đã đạt được trong khóa luận không sao chép từ bất
kì tài liệu nào dưới mọi hình thức. Những kết quả đó là những gì tôi đã nghiên cứu, tích
lũy được trong quá trình làm khóa luận này.
Tôi xin hoàn toàn chịu trách nhiệm nếu có bất kì dấu hiệu nào của sự sao chép kết
quả từ các tài liệu khác.
Hà Nội, ngày … tháng … năm 2019
Sinh viên

Hoàng Tuấn Hùng

i
 LỜI CẢM ƠN
Tôi muốn dành lời cảm ơn đặc biệt đến người thầy giám sát của mình, PGS.TS Nguyễn
Nam Hoàng bởi những chia sẻ kiến thức chuyên môn của thầy trong lĩnh vực này và sự
giúp đỡ, hỗ trợ liên tục của thầy trong quá trình thực hiện khóa luận. Cảm ơn thầy, không
chỉ vì sự giúp đỡ mà còn là vì sự tin tưởng và hướng dẫn tận tình của thầy trong quá trình
sửa đổi, hoàn thiện khóa luận.
Tôi cũng muốn bày tỏ sự kính trọng và lời cảm ơn của mình với Tiến sĩ Lâm Sinh
Công, thông qua ý tưởng, đề xuất và lời khuyên của thầy tôi đã cải thiện nghiên cứu này.
Tôi xin chân thành cảm ơn tất cả các thầy cô, bạn bè của Trường Đại học Công nghệ
nói chung và khoa Điện tử - Viễn thông nói riêng, đã góp phần làm cho khoảng thời gian
học tập trên giảng đường cũng như thực hiện khóa luận này trở thành một trải nghiệm vô
cùng đáng nhớ và thú vị.
Cuối cùng, tôi cảm ơn gia đình tôi, những người đã không ngừng ủng hộ và khuyến
khích tôi trong suốt quá trình học tập.
Tôi xin chân thành cảm ơn!
Hà Nội, ngày … tháng … năm 2019
Sinh viên

Hoàng Tuấn Hùng

ii
 MỤC LỤC
LỜI CAM ĐOAN ........................................................................................................... i
LỜI CẢM ƠN ................................................................................................................ ii
DANH MỤC BẢNG ..................................................................................................... vi
DANH MỤC HÌNH ẢNH ........................................................................................... vii
DANH MỤC TỪ VIẾT TẮT ..................................................................................... viii
TÓM TẮT ...................................................................................................................... 1
1. CHƯƠNG 1 ........................................................................................................... 2
GIỚI THIỆU ................................................................................................................. 2
1.1. Lời mở đầu ...................................................................................................... 2
1.2. Vấn đề đặt ra ................................................................................................... 3
1.3. Đề xuất giải pháp............................................................................................. 3
1.4. Phương pháp luận ............................................................................................ 4
1.5. Mục đích khóa luận ......................................................................................... 4
1.6. Outlines ........................................................................................................... 4
2. CHƯƠNG 2 ........................................................................................................... 5
TỔNG QUAN VỀ SDN VÀ LOAD BALANCING ...................................................... 5
2.1. Giới thiệu ........................................................................................................ 5
2.2. Hạn chế mạng truyền thống ............................................................................. 5
2.3. Software-Defined Networking (SDN) ............................................................. 6
2.3.1. Kiến trúc SDN .......................................................................................... 7
2.3.2. Lợi thế của công nghệ SDN ...................................................................... 8
2.3.3. Các ứng dụng SDN ................................................................................... 9
2.4. Giao thức OpenFlow ....................................................................................... 9
2.4.1. Lợi ích của SDN trên cơ sở OpenFlow.................................................... 10
2.4.2. Ứng dụng của OpenFlow ........................................................................ 11
2.5. Cân bằng tải trọng mạng (Network load balancing) ....................................... 12
2.5.1. Lập lịch Round Robin ............................................................................. 12
2.5.2. Cách tiếp cận thời gian phụ thuộc ........................................................... 12
2.5.3. Phương pháp sử dụng thuật toán băm (Hashing) ..................................... 12

iii
 2.5.4. Định tuyến lưu lượng theo các tham số liên quan đến QoS ..................... 13
2.6. Kết nối liên mạng .......................................................................................... 13
2.6.1. Mô hình liên kết mạng fat-tree ................................................................ 13
2.7. Thuật toán Dijkstra ........................................................................................ 14
2.8. Thuật toán cân bằng tải động trong mạng SDN ............................................. 15
2.8.1. Flow ....................................................................................................... 15
2.8.2. Flows Collection ..................................................................................... 16
2.8.3. Path ........................................................................................................ 16
2.8.4. Paths Collection ...................................................................................... 16
2.9. Các nghiên cứu khoa học liên quan ............................................................... 17
3. CHƯƠNG 3 ..........................................................................................................18
PHƯƠNG PHÁP LUẬN ..............................................................................................18
3.1. Giới thiệu ...................................................................................................... 18
3.2. Mô tả thuật toán ............................................................................................ 18
3.3. Tiến trình thực hiện cài đặt thử nghiệm ......................................................... 19
3.4. Công cụ phần mềm ........................................................................................ 20
3.4.1. Mininet ................................................................................................... 20
3.4.2. Dự án OpenDaylight (ODL) ................................................................... 21
3.4.3. iPerf ........................................................................................................ 21
3.4.4. Ngôn ngữ lập trình: Python ..................................................................... 22
4. CHƯƠNG 4 ..........................................................................................................23
KẾT QUẢ THỬ NGHIỆM VÀ ĐÁNH GIÁ HIỆU SUẤT .........................................23
4.1. Giới thiệu ...................................................................................................... 23
4.2. Network Topology ........................................................................................ 23
4.3. Các bước mô phỏng....................................................................................... 23
4.4. Kịch bản test ................................................................................................. 27
4.4.1. Kịch bản 1: Đo lường hiệu suất mạng khi thực hiện cân bằng tải ở lớp
Aggregation........................................................................................................... 27
4.4.2. Kịch bản 2: Đo lường hiệu suất mạng khi thực hiện cân bằng tải có sự
tham gia của lớp Core............................................................................................ 32

iv
 4.4.3. Nhận xét ................................................................................................. 36
KẾT LUẬN VÀ ĐỊNH HƯỚNG NGHIÊN CỨU TRONG TƯƠNG LAI .................37
TÀI LIỆU THAM KHẢO: ...........................................................................................38
PHỤ LỤC......................................................................................................................40

v
 DANH MỤC BẢNG
Bảng 1: Các tham số của bộ điều khiển OpenDaylight: ................................................... 24
Bảng 2. Bảng tổng hợp kết quả kịch bản 1 ...................................................................... 31
Bảng 3. Bảng tổng hợp kết quả kịch bản 2 ...................................................................... 34

vi
 DANH MỤC HÌNH ẢNH
Chương 2:
Hình 2.1 Mô hình mạng SDN ........................................................................................... 6
Hình 2.2 Kiến trúc SDN.................................................................................................... 7
Hình 2.3 Cấu trúc một thiết bị sử dụng OpenFlow .......................................................... 10
Hình 2.4 Mô hình mạng fat-tree ...................................................................................... 14
Chương 3:
Hình 3.1 Flow Chart thuật toán cân bằng tải ................................................................... 18
Hình 3.2 Cài đặt thử nghiệm ........................................................................................... 20
Hình 3.3 Kiến trúc OpenDaylight ................................................................................... 21
Hình 3.4 Công cụ đo băng thông iPert ............................................................................ 22
Chương 4:
Hình 4.1 Mô hình mạng cho thử nghiệm ......................................................................... 23
Hình 4.2 Chạy chương trình dựng Topo mạng ................................................................ 24
Hình 4.3 Giao diện hiển thị của ODL controller .............................................................. 25
Hình 4.4 Thống kê các tham số trên mỗi node ................................................................ 25
Hình 4.5 API request ...................................................................................................... 26
Hình 4.6 Chạy chương trình cân bằng tải ........................................................................ 26
Hình 4.7 Đường đi của gói trước cân bằng tải ................................................................. 27
Hình 4.8 Đường đi của gói sau khi chạy chương trình cân bằng tải ................................. 29
Hình 4.9 Ping từ h1 tới h3 trước cân bằng tải .................................................................. 29
Hình 4.10 Ping từ h1 tới h4 trước cân bằng tải ................................................................ 30
Hình 4.11 Ping từ h1 tới h4 sau cân bằng tải ................................................................... 30
Hình 4.12 So sánh kết quả thông lượng kịch bản 1 ......................................................... 31
Hình 4.13 So sánh tham số QoS kịch bản 2 ..................................................................... 32
Hình 4.14 Sơ đồ minh họa cho kịch bản 2 ....................................................................... 32
Hình 4.15 Ping từ h1 tới h7 trước cân bằng tải ................................................................ 33
Hình 4.16 Ping từ h1 tới h8 trước cân bằng tải ................................................................ 33
Hình 4.17 Ping từ h1 tới h8 sau cân bằng tải ................................................................... 34
Hình 4.18 So sánh kết quả thông lượng kịch bản 2 ......................................................... 35
Hình 4.19 So sánh tham số QoS kịch bản 2 ..................................................................... 35

vii
 DANH MỤC TỪ VIẾT TẮT
ACL Access Control List Danh sách kiểm soát truy cập
API Application Program Interface Giao diện lập trình ứng dụng
CAPEX Capital Expenditure Chi phí đầu tư
CPU Central Processing Unit Khối xử lý trung tâm
FSM Finite State Machine Máy trạng thái hữu hạn
HPC High-Performance Computing Điện toán hiệu suất cao
ICMP Internet Control Message Protocol Giao thức bản tin kiểm soát Internet
IP Internet Protocol Giao thực Internet
IPv4 Internet Protocol version 4 Giao thức Internet version 4
IPv6 Internet Protocol version 6 Giao thức Internet version 6
Intermediate System to Giao thức định tuyến nội IGP
IS-IS
Intermediate System
IT Information Technology Công nghệ thông tin
LAN Local Area Network Mạng cục bộ
LLB Link Load Balancing Cân bằng tải liên kết
MAC Media Access Control Kiểm soát phương tiện truy cập
MPLS Multi-Protocol Label Switching Chuyển mạch nhãn đa giao thức
NE Network Elements Thành phần mạng bên dưới
ODL OpenDaylight Dự án mã nguồn mở OpenDaylight
ONF Open Networking Foundation Tổ chức mở ONF
OPEX Operational Expenditure Chi phí vận hành
OS Operating System Hệ điều hành
OSPF Open Shortest Path First Giao thức định tuyến đường đi ngắn nhất
QoE Quality Of Experience Chất lượng trải nghiệm
QoS Quality Of Service Chất lượng dịch vụ
SDN Software Defined Networking Mạng điều khiển bằng phần mềm
TCP Transmission Control Protocol Giao thức truyền dữ liệu tin cậy TCP
UDP User Datagram Protocol Giao thức phi kết nối UDP

viii
 TÓM TẮT
Tóm tắt: Kiến trúc mạng truyền thống có nhiều hạn chế đáng kể cần phải được khắc phục để đáp
ứng các yêu cầu CNTT hiện đại. Một trong những vấn đề chính của mạng truyền thống là chúng
sử dụng các bộ chuyển mạch tĩnh dẫn đến hiệu quả sử dụng tài nguyên mạng kém. Một vấn đề
khác là mất gói tin và trễ, trong trường hợp bộ chuyển mạch bị hỏng, phải mất một khoảng thời
gian thực hiện quá trình hội tụ. Để khắc phục những hạn chế này, các kỹ sư mạng đã áp dụng các
phương pháp cân bằng tải trong thiết kế các thuật toán chuyển mạch và định tuyến. Tuy nhiên, yêu
cầu cân bằng tải trong mạng không thể được thỏa mãn hoàn toàn bằng các phương pháp truyền
thống. Nền tảng Software Defined Neworking (SDN) xuất hiện như một cách tiếp cận mới. Khóa
luận của tôi đề xuất triển khai thuật toán cân bằng tải động cho mạng trung tâm dữ liệu dựa trên
nền tảng SDN, để khắc phục các vấn đề còn tồn tại trong mạng trung tâm dữ liệu. Việc kiểm tra
hiệu quả của chương trình cân bằng tải đã được triển khai bằng phần mềm Mininet để mô phỏng
mạng và nền tảng OpenDaylight (ODL) làm bộ điều khiển SDN. Ngôn ngữ lập trình Python được
sử dụng để viết chương trình mô tả cấu trúc liên kết mạng fat-tree và viết chương trình thuật toán
cân bằng tải. Công cụ iPerf và jPerf được sử dụng để kiểm tra, đánh giá hiệu suất mạng. Hiệu suất
của mạng được kiểm tra trước và sau khi chạy thuật toán cân bằng tải. Việc thử nghiệm tập trung
vào một số tham số Quality of Service (QoS) của mạng như thông lượng, băng thông, độ trễ, jitter
và mất gói giữa cặp host nguồn-đích trong mô hình mạng fat-tree. Trong hai kịch bản đề xuất, kết
quả đánh giá cho thấy thuật toán tăng thông lượng và cải thiện hiệu quả sử dụng mạng. Tuy nhiên,
trong quy mô mạng lớn (yêu cầu lưu lượng chảy qua các Switch lõi) jitter và mất gói tin tăng lên.
Từ khóa: SDN, OpenFlow, Loadbalancing, DCN

1
 1. CHƯƠNG 1
GIỚI THIỆU

1.1. Lời mở đầu

Kiến trúc mạng truyền thống có nhiều hạn chế đáng kể phải được khắc phục để đáp
ứng các yêu cầu công nghệ thông tin hiện đại. Để khắc phục những hạn chế này, Software
Defined Networking (SDN) [1] đang xuất hiện như một cách tiếp cận mạng mới.
Hệ thống mạng truyền thống có mặt phẳng điều khiển và mặt phẳng dữ liệu trên cùng
một phần cứng. Trong khi cách tiếp cận SDN xây dựng một mạng máy tính phân tách và
trừu tượng mạng thành hai mặt phẳng: mặt phẳng điều khiển và mặt phẳng dữ liệu. Mặt
phẳng dữ liệu thực hiện thao tác chuyển các gói tin thông qua mạng. Không giống như các
mạng truyền thống, các thiết bị chuyển mạch bên dưới không thực hiện mặt phẳng điều
khiển. Mặt phẳng điều khiển phần mềm tách ra khỏi mặt phẳng dữ liệu với có thể điều
khiển các mặt phẳng dữ liệu qua các giao diện API.
Mặt phẳng điều khiển là một phần mềm hoặc thực thể logic, xử lý tất cả các quyết
định định tuyến và được thực hiện bởi mặt phẳng dữ liệu. Do đó, mạng có thể lập trình trực
tiếp và phản ứng nhanh với các thay đổi trong mạng [2].
OpenFlow là giao thức phổ biến nhất được sử dụng trong các mạng SDN, được sử
dụng để giao tiếp giữa bộ điều khiển với tất cả các thành phần mạng bên dưới (Network
Element). Đó là một chuẩn mở cung cấp tiêu chuẩn cho phép các nhà nghiên cứu chạy thử
nghiệm mà không yêu cầu các nhà cung cấp phải trưng ra hoạt động bên trong của các thiết
bị mạng của họ [2].
OpenFlow thường bị nhầm lẫn với chính khái niệm SDN, nhưng đó là những khái
niệm khác nhau. Trong khi SDN là kiến trúc phân chia các lớp, OpenFlow chỉ là một giao
thức được đề xuất để truyền tải các thông tin từ lớp điều khiển đến các thành phần mạng.
Có một loạt các dự án dựa trên OpenFlow, bao gồm các bộ điều khiển, các bộ chuyển mạch
ảo hóa và các ứng dụng thử nghiệm [2].
Để tăng băng thông khả dụng, tối đa hóa thông lượng và thêm các liên kết dự phòng,
phải sử dụng cân bằng tải trong mạng. Cân bằng tải mạng là khả năng cân bằng lưu lượng
trên nhiều kết nối Internet. Khả năng này cân bằng các phiên mạng như Web, Email, ... qua
nhiều kết nối để phân chia lượng băng thông được sử dụng bởi mỗi người dùng LAN, do

2
đó làm tăng lượng băng thông có sẵn. Cân bằng tải thường liên quan đến phần mềm hoặc
phần cứng chuyên dụng, chẳng hạn như cân bằng tải liên kết.
Bộ cân bằng tải liên kết, còn được gọi là bộ cân bằng liên kết, là một thiết bị mạng
phân phối lưu lượng truy cập trong và ngoài miền mạng, đến từ nhiều liên kết Internet. Các
bộ cân bằng tải liên kết thường được đặt giữa các Router Gateway và tường lửa. Các phương
pháp cân bằng tải có thể áp dụng cho cân bằng tải liên kết (LLB) là round robin, phương
pháp băm địa chỉ IP đích, phương pháp băng thông tối thiểu và gói tin tối thiểu [2].
1.2. Vấn đề đặt ra
Mạng hiện tại cần có sự quản lý tài nguyên linh hoạt để có hiệu suất sử dụng tài nguyên
cao và độ trễ truyền dữ liệu thấp trong mạng.
Mạng trung tâm dữ liệu được thiết kế để đáp ứng nhu cầu truyền dữ liệu của các máy
chủ được kết nối một cách dày đặc trong trung tâm dữ liệu. Cấu trúc liên kết mạng và cơ
chế chuyển mạch/định tuyến có thể ảnh hưởng đáng kể đến hiệu suất và độ trễ. Ngày nay,
mô hình mạng fat-tree là một trong những cấu trúc liên kết được sử dụng rộng rãi nhất cho
mạng trung tâm dữ liệu. Tuy nhiên mô hình này sử dụng các thiết bị chuyển mạch tĩnh, cả
mặt phẳng điều khiển và mặt phẳng chuyển tiếp được đặt trên một phần cứng. Vấn đề với
các mạng này là mỗi luồng dữ đi theo một đường dẫn được xác định trước thông qua mạng.
Trong trường hợp bộ chuyển mạch bị lỗi, các gói dữ liệu có xu hướng giảm cho đến khi
một đường dẫn khác được chọn. Một vấn đề khác là việc sử dụng tài nguyên mạng kém,
khi các liên kết thay thế đến đích không hoạt động, trong khi một số liên kết phải chịu tải
lớn.
1.3. Đề xuất giải pháp
Các kỹ sư mạng đã áp dụng các phương pháp cân bằng tải trong thiết kế các thuật toán
chuyển mạch và định tuyến. Tuy nhiên, yêu cầu cân bằng tải trong các mạng fat-tree không
thể được thỏa mãn hoàn toàn bằng các phương pháp truyền thống. Lý do chính là thiếu các
cách hiệu quả để có được số liệu thống kê lưu lượng truy cập mạng từ mỗi thiết bị mạng.
Như một giải pháp, giao thức OpenFlow cho phép giám sát thống kê lưu lượng truy cập
bằng bộ điều khiển tập trung. Để đạt được hiệu suất cao và độ trễ thấp, khóa luận đề xuất
một bộ cân bằng tải được triển khai trong bộ điều khiển SDN, thực hiện cân bằng tải cho
các mạng trung tâm dữ liệu dựa trên OpenFlow. Nhiệm vụ của thuật toán là phân phối luồng
lưu lượng sắp đến và luồng lưu lượng trong mạng và làm cho mỗi đường dẫn thay thế nhận

3
được lượng tải lưu lượng bằng nhau, qua đó đạt được hiệu quả sử dụng tài nguyên tốt nhất
có thể cho từng liên kết trong mạng. Nó có thể được tiếp tục áp dụng cho các mạng quy mô
lớn và lên lịch các luồng dữ liệu một cách linh hoạt. Kết quả khóa luận chứng minh rằng
thuật toán định tuyến cân bằng tải động được đề xuất vượt trội hơn thuật toán cân bằng tải
tĩnh.
1.4. Phương pháp luận
Để thực hiện kiểm tra, đánh giá hiệu suất của thuật toán, nền tảng mã nguồn mở
OpenDaylight (ODL) controller được sử dụng làm bộ điều khiển SDN, mô hình mạng được
mô phỏng bằng phần mềm Mininet. Mục tiêu là đo các tham số QoS: thông lượng, độ trễ
và mất gói từ đó xác định xem thuật toán được chọn có cung cấp hiệu suất tốt hơn trên
mạng hay không.
1.5. Mục đích khóa luận
Mục đích của khóa luận này là triển khai thuật toán cân bằng tải động Naya Seth trong
các mạng trung tâm dữ liệu dựa trên nền tảng SDN để phân tích các khả năng đạt được hiệu
suất tốt hơn [12].
Mục đích của khóa luận là đánh giá và xác nhận khả năng cân bằng tải của thuật toán
cân bằng tải đề xuất.
1.6. Outlines
Khóa luận được tổ chức như sau: Chương hai cung cấp kiến thức cơ bản liên quan đến
nền tảng SDN và cân bằng tải trong mạng. Chương ba mô tả phương pháp luận của các
thuật toán cân bằng tải và trình bày các thành phần được sử dụng trong khóa luận để thực
hiện thử nghiệm. Chương bốn mô tả các kịch bản được đề xuất, trình bày đánh giá kết quả
thực hiện. Cuối cùng là rút ra kết luận và định hướng cho công việc trong tương lai.

4
 2. CHƯƠNG 2
TỔNG QUAN VỀ SDN VÀ LOAD BALANCING

2.1. Giới thiệu

Chương này cung cấp một nền tảng chung và tổng quan về khái niệm Software
Defined Networking, giao thức OpenFlow, cân bằng tải mạng, thuật toán của Dijkstra, các
thông tin liên quan tới chủ đề của khóa luận này. Sau đó là đưa ra một bản tóm tắt ngắn gọn
về tổng quan tài liệu khoa học được đề cập tới để phát triển nghiên cứu này.
2.2. Hạn chế mạng truyền thống
Kiến trúc mạng truyền thống có những hạn chế đáng kể phải được khắc phục để đáp
ứng các yêu cầu công nghệ thông tin hiện đại. Ngày nay, mạng phải mở rộng quy mô để
phù hợp với khối lượng tải ngày càng tăng cùng với đó là độ linh hoạt cao hơn, đồng thời
giữ chi phí ở mức tối thiểu. Cách tiếp cận truyền thống có những hạn chế đáng kể như [3]:
 Độ phức tạp: Sự đa dạng của các giao thức và dịch vụ trong mạng cho các trường
hợp sử dụng cụ thể đã làm tăng đáng kể độ phức tạp của mạng. Các công nghệ cũ thường
được dùng lại để tạo các bản sửa lỗi nhanh để giải quyết các yêu cầu mới của doanh nghiệp.
Các tính năng cụ thể của nhà cung cấp hoặc được triển khai thông qua các lệnh độc quyền.
Vì vậy kiến trúc mạng hiện tại rất phức tạp.
 Các chính sách không nhất quán: Chính sách bảo mật và chất lượng dịch vụ (QoS)
trong các mạng hiện tại cần được cấu hình thủ công hoặc viết kịch bản trên hàng trăm hoặc
hàng nghìn thiết bị mạng. Yêu cầu này làm cho các thay đổi chính sách trở nên cực kỳ phức
tạp đối với các tổ chức khi thực hiện, vì ban đầu không đầu tư vào các kỹ năng hoặc công
cụ ngôn ngữ để có thể tự động thay đổi cấu hình theo yêu cầu. Cấu hình thủ công cũng dễ
bị lỗi và có thể dẫn đến hàng giờ để khắc phục sự cố để tìm ra dòng nào của chính sách bảo
mật hoặc danh sách kiểm soát truy cập (ACL) được nhập không chính xác trên một thiết bị
nhất định. Ngoài ra, khi các ứng dụng bị xóa, gần như không thể xóa tất cả các chính sách
liên quan khỏi tất cả các thiết bị, làm tăng thêm độ phức tạp.
 Không có khả năng mở rộng: Khi khối lượng dữ liệu của ứng dụng thay đổi và nhu
cầu về băng thông mạng tăng lên, hạ tầng CNTT cần phải đáp ứng được quy mô mạng vượt
quá mức hoặc cần phát triển theo yêu cầu của tổ chức. Thật không may, phần lớn các mạng

5
truyền thống được cung cấp thụ động theo cách là tăng số lượng điểm cuối, vì vậy dịch vụ
hoặc băng thông đòi hỏi phải lập kế hoạch thiết kế lại mạng.
Các kiến trúc mạng truyền thống không phù hợp để đáp ứng các yêu cầu của các doanh
nghiệp, nhà mạng và người dùng cuối ngày nay. Nhờ nỗ lực của tổ chức mở Open
Networking Foundation (ONF, SDN đang chuyển đổi kiến trúc mạng [1].
2.3. Software-Defined Networking (SDN)
SDN là một kiến trúc mạng mới xuất hiện trong đó phần điều khiển mạng được tách
rời khỏi phần chuyển tiếp và được lập trình trực tiếp. Việc di chuyển mặt phẳng điều khiển
này, trong khi trước đây bị ràng buộc chặt trong các thiết bị mạng riêng lẻ, vào các thiết bị
tính toán có thể truy cập cho phép cơ sở hạ tầng bên dưới được trừu tượng hóa cho các ứng
dụng và dịch vụ mạng, có thể coi mạng lúc này là một thực thể logic hoặc ảo. Do đó, các
doanh nghiệp và nhà mạng đạt được khả năng lập trình, tự động hóa và kiểm soát mạng
chưa từng có, cho phép họ xây dựng các mạng linh hoạt, có khả năng mở rộng cao, dễ dàng
thích ứng với nhu cầu doanh nghiệp thay đổi [1][4].
SDN được điều khiển bởi các ứng dụng phần mềm và bộ điều khiển SDN thay vì các
bảng điều khiển quản lý mạng truyền thống và các lệnh đòi hỏi nhiều chi phí quản trị và
dài dòng, phức tạp khi quản lý trên quy mô lớn [4].

Hình 2.1 Mô hình mạng SDN [4]

6
2.3.1. Kiến trúc SDN
Ý tưởng chính của SDN là tách mặt phẳng điều khiển khỏi mặt phẳng chuyển tiếp dữ
liệu, tính thông minh của mạng (về mặt logic) được tập trung trong các phần mềm của bộ
điều khiển SDN, giúp nó duy trì cái nhìn tổng thể về mạng. Do đó, mạng xuất hiện cung
cấp các ứng dụng và công cụ chính sách dưới dạng một chuyển đổi logic duy nhất. Với
SDN, các doanh nghiệp và nhà mạng có được quyền kiểm soát độc lập với nhà cung cấp
đối với toàn bộ mạng từ một nơi duy nhất, giúp đơn giản hóa rất nhiều việc thiết kế và vận
hành mạng. SDN cũng đơn giản hóa rất nhiều các thiết bị mạng, vì chúng không còn cần
phải hiểu và xử lý hàng ngàn tiêu chuẩn giao thức mà chỉ chấp nhận các hướng dẫn từ bộ
điều khiển SDN. Hình dưới đây mô tả kiến trúc SDN cơ bản [1].

Hình 2.2 Kiến trúc SDN [1]

Kiến trúc SDN hỗ trợ một tập API cho phép triển khai các dịch vụ mạng phổ biến,
bao gồm định tuyến, multicast, bảo mật, kiểm soát truy cập, quản lý băng thông, kỹ thuật
lưu lượng, chất lượng dịch vụ, tối ưu hóa bộ xử lý và lưu trữ, sử dụng năng lượng hiệu quả
và tất cả các hình thức chính sách quản lý, tùy chỉnh phù hợp để đáp ứng mục đích doanh
nghiệp. Ví dụ, kiến trúc SDN giúp dễ dàng xác định và thực thi các chính sách nhất quán
trên cả kết nối có dây và không dây trong một miền mạng.

7
2.3.2. Lợi thế của công nghệ SDN
OpenFlow là giao diện tiêu chuẩn đầu tiên được thiết kế dành riêng cho SDN, cung
cấp kiểm soát lưu lượng một cách chi tiết, hiệu quả cao trên nhiều thiết bị mạng của nhà
cung cấp. SDN dựa trên OpenFlow hiện đang được triển khai trong nhiều thiết bị và phần
mềm mạng, mang lại lợi ích đáng kể cho cả doanh nghiệp và nhà mạng, bao gồm [3]:

 Quản lý và kiểm soát tập trung các thiết bị mạng từ nhiều nhà cung cấp. Cải thiện
tự động hóa và quản lý bằng cách sử dụng các API phổ biến để mô tả một cách chi
tiết mạng bên dưới từ lớp orchestration, các hệ thống và ứng dụng.
 Thay đổi nhanh chóng thông qua khả năng cung cấp các chức năng và dịch vụ
mạng mới mà không cần phải cấu hình các thiết bị riêng lẻ hoặc chờ các nhà cung
cấp thực hiện.
 Khả năng lập trình của các nhà vận hành, doanh nghiệp, nhà cung cấp phần mềm
độc lập và người dùng (không chỉ nhà sản xuất thiết bị) sử dụng môi trường lập
trình chung, mang đến cho tất cả các bên cơ hội mới để thúc đẩy doanh thu và sự
khác biệt.
 Tăng độ tin cậy và bảo mật mạng do quản lý tập trung và tự động các thiết bị mạng,
đảm bảo chính sách thống nhất và ít lỗi cấu hình hơn.
 Kiểm soát mạng chi tiết hơn với khả năng áp dụng các chính sách toàn diện và
rộng khắp ở cấp độ phiên, người dùng, thiết bị và ứng dụng.
 Trải nghiệm người dùng cuối tốt hơn khi các ứng dụng khai thác thông tin trạng
thái mạng tập trung để điều khiển liền mạch hành động mạng theo nhu cầu của
người dùng.
 Giảm CapEx: SDN giúp giảm thiểu các yêu cầu mua phần cứng theo mục đích xây
dựng các dịch vụ, phần cứng mạng trên cơ sở ASIC, và hỗ trợ mô hình pay as-you
grow (trả những gì bạn dùng) để loại bỏ lãng phí cho việc dự phòng.
 Giảm OpEx: thông qua các phần tử mạng đã được gia tăng khả năng lập trình,
SDN giúp dễ dàng thiết kế, triển khai, quản lý và mở rộng mạng. Khả năng phối
hợp và dự phòng tự động không những giảm thời gian quản lý tổng thể, mà còn
giảm xác suất lỗi do con người tới việc tối ưu khả năng và độ tin cậy của dịch vụ.

8
2.3.3. Các ứng dụng SDN
SDN được ứng dụng rộng rãi trong mạng, danh sách dưới đây đã đề cập đến một số
ứng dụng có liên quan [5].

 Công nghệ ảo hóa thiết bị mạng NFV: Tường lửa, cân bằng tải và các gateway, bộ
định tuyến và chuyển mạch ảo. Điều khiển mạng ảo trên cơ sở hạ tầng dùng chung,
tự động hóa, mạng nhiều bên thuê và API.
 Đảm bảo dịch vụ: Định tuyến lưu lượng cụ thể theo nội dung cho chất lượng trải
nghiệm tối ưu (QoE), kiểm soát tắc nghẽn dựa trên các điều kiện mạng, kỹ thuật
lưu lượng dựa trên chính sách động.
 Phân biệt dịch vụ: Các tính năng dịch vụ bổ sung, các tính năng yêu cầu băng thông
trên nhiều mạng, thêm/thay đổi dịch vụ.
 Tăng tốc độ của dịch vụ: Virtual edge, môi trường thử nghiệm ứng dụng phân tán,
quy trình phát triển ứng dụng.
 Chức năng của mặt phẳng điều khiển truyền thống: Phát hiện mạng, tính toán
đường dẫn, tối ưu hóa và duy trì, bảo vệ và phục hồi.
 Cải thiện ứng dụng: Ứng dụng SDN cụ thể, băng thông dành riêng cho nhu cầu
ứng dụng, các ứng dụng phân tán, đáp ứng nhanh cho nhu cầu ứng dụng.
2.4. Giao thức OpenFlow
OpenFlow là giao diện truyền thông tiêu chuẩn đầu tiên được xác định giữa lớp điều
khiển và lớp chuyển tiếp dữ liệu của kiến trúc SDN. OpenFlow cho phép truy cập trực tiếp
và thao tác trên mặt phẳng chuyển tiếp của các thiết bị mạng như bộ chuyển mạch và bộ
định tuyến, cả vật lý và ảo (dựa trên nền tảng ảo hóa). Chính vì không có một giao diện mở
cho mặt phẳng chuyển tiếp đã dẫn đến đặc điểm của các thiết bị mạng ngày nay là nguyên
khối, đóng và giống như máy tính lớn. Vì vậy giao thức OpenFlow là cần thiết để chuyển
phần điều khiển mạng ra khỏi các bộ chuyển mạch mạng sang phần mềm điều khiển tập
trung logic duy nhất [1].
OpenFlow sử dụng khái niệm các “flow” (luồng) để nhận dạng lưu lượng mạng trên
cơ sở định nghĩa trước các qui tắc phù hợp (được lập trình tĩnh hoặc động bởi phần mềm
điều khiển SDN). Giao thức này cũng cho phép định nghĩa cách mà lưu lượng phải được
truyền qua các thiết bị mạng trên cơ sở các tham số, chẳng hạn như mô hình lưu lượng sử
dụng, ứng dụng, và tài nguyên đám mây. Do đó OpenFlow cho phép mạng được lập trình

9
trên cơ sở luồng lưu lượng. Một kiến trúc SDN trên cơ sở OpenFlow cung cấp điều khiển
ở mức cực kỳ chi tiết, cho phép mạng phản hồi sự thay đổi theo thời gian thực của ứng
dụng, người dùng và mức phiên [3].
Một thiết bị OpenFlow bao gồm ít nhất 3 thành phần [3]:

 Secure Channel: kênh kết nối thiết bị tới bộ điều khiển (controller), cho phép các
lệnh và các gói tin được gửi giữa bộ điều khiển và thiết bị.
 OpenFlow Protocol: giao thức cung cấp phương thức tiêu chuẩn và mở cho một
bộ điều khiển truyền thông với thiết bị.
 Flow Table: một liên kết hành động với mỗi luồng, giúp thiết bị xử lý các luồng
thế nào.

Hình 2.3 Cấu trúc một thiết bị sử dụng OpenFlow [3]

2.4.1. Lợi ích của SDN trên cơ sở OpenFlow
Những lợi ích mà các doanh nghiệp và nhà khai thác mạng có thể đạt được thông qua
kiến trúc SDN trên cơ sở OpenFlow bao gồm [3]:
 Tập trung hóa điều khiển trong môi trường nhiều nhà cung cấp thiết bị: phần mềm
điều khiển SDN có thể điều khiển bất kỳ thiết bị mạng nào cho phép OpenFlow
từ bất kỳ nhà cung cấp thiết bị nào, bao gồm Switch, Router, và các Switch ảo.
 Giảm sự phức tạp thông qua việc tự động hóa: kiến trúc SDN trên cơ sở OpenFlow
cung cấp một framework quản lý mạng tự động và linh hoạt. Từ framework này

10
 có thể phát triển các công cụ tự động hóa các nhiệm vụ hiện đang được thực hiện
bằng tay.
 Đáp ứng nhanh với thay đổi trong mạng: việc áp dụng OpenFlow cho phép các
nhà khai thác mạng lập trình lại mạng trong thời gian thực để đạt được các nhu
cầu kinh doanh và yêu cầu người dùng cụ thể khi có sự thay đổi.
 Gia tăng độ tin cậy và khả năng an ninh của mạng: các nhân viên IT có thể định
nghĩa các trạng thái cấu hình và chính sách ở mức cao, và áp dụng tới cơ sở hạ
tầng thông qua OpenFlow. Kiến trúc SDN trên cơ sở OpenFlow cung cấp điều
khiển và tầm nhìn hoàn chỉnh trên mạng, nên có thể đảm bảo điều khiển truy nhập,
định hình lưu lượng, QoS, an ninh, và các chính sách khác được thực thi nhất
quán trên toàn bộ cơ sở hạ tầng mạng không dây và có dây, bao gồm cả các văn
phòng chi nhánh, các cơ sở chính và trung tâm dữ liệu.

2.4.2. Ứng dụng của OpenFlow

OpenFlow đươc ứng dụng rộng rãi, trong đó việc sử dụng OpenFlow có thể cải thiện
hiệu suất toàn bộ hệ thống. Danh sách một số ứng dụng của OpenFlow [3]:
 Network slicing: Cơ sở hạ tầng mạng có thể được chia thành các lát cắt logic (ví dụ:
sử dụng phần mềm FlowVisor). Do đó, các dịch vụ khác nhau có thể được ánh xạ tới các
lát mạng khác nhau và lưu lượng có thể được xử lý theo cách tương ứng.
 Cân bằng tải: Toàn bộ mạng có thể được xem như một bộ chuyển mạch cân bằng
tải phần mềm thay vì triển khai các bộ chuyển mạch phần cứng cân bằng tải đắt tiền.
 Giảm chi phí CAPEX/OPEX cho các công ty viễn thông: kết hợp công nghệ ảo hóa
cho phép giảm chi phí phần cứng, vận hành đơn giản hơn cho phép giảm chi phí vận hành.
 Giảm mức tiêu thụ năng lượng: Có thể ngắt các liên kết không sử dụng, do đó cần
ít năng lượng hơn để chạy, ví dụ như trong mạng trung tâm dữ liệu.
 Kiểm soát luồng lưu lượng một cách linh hoạt: OpenFlow có thể giúp tiết kiệm tài
nguyên (CPU, bảng định tuyến) hoặc quản lý mạng dễ dàng hơn.
 Cung cấp dịch vụ MPLS: OpenFlow có thể đơn giản hóa việc triển khai các dịch vụ
MPLS mới (ví dụ: các đường hầm mới bao gồm các điều chỉnh về dành trước băng thông
của chúng).

11
2.5. Cân bằng tải trọng mạng (Network Load Balancing)
Cân bằng tải rất quan trọng trong việc xây dựng mạng tốc độ cao và cũng để đảm bảo
hiệu suất cao trong mạng trục.
Ý tưởng chính của cân bằng tải là điều khiển một phần lưu lượng từ các đường có tải
nặng sang một số đường có tải nhẹ hơn để tránh tắc nghẽn trong tuyến đường ngắn nhất và
tăng mức sử dụng mạng và thông lượng mạng [2].
Cân bằng tải có một số cách tiếp cận như sau [6]:
2.5.1. Lập lịch Round Robin
Lập lịch round robin là có điểm mạnh chỉ khi tất cả các đường dẫn có chi phí như
nhau. Nếu không, sự xáo trộn gói sẽ diễn ra, xuất hiện tín hiệu tắc nghẽn sai (bởi vì, khi
một tiến trình sử dụng hết thời gian quantum mà nó được cấp phát, thì dù vẫn còn phải xử
lý tiếp, phần dư của nó cũng sẽ được chuyển về phía sau trong danh sách hàng đợi). Điều
này sẽ dẫn đến sự giảm thông lượng mạng không cần thiết vì một số liên kết không được
sử dụng trong khi các liên kết khác bị sử dụng quá mức [2].
2.5.2. Cách tiếp cận thời gian phụ thuộc
Cân bằng lưu lượng trên cơ sở khoảng thời gian dài theo trạng thái của lưu lượng
trong mạng. Cách tiếp cận phụ thuộc thời gian sẽ thay đổi lưu lượng trên cơ sở các biến thể
của lưu lượng trong một khoảng thời gian dài. Các loại phương pháp này không nhạy với
mạng có nhiều lưu lượng truy cập động, vì khi đó các trạng thái trong mạng rất phức tạp,
khó kiểm soát [7].
2.5.3. Phương pháp sử dụng thuật toán băm (Hashing)
Các cách tiếp cận sử dụng phương pháp băm là một cách tiếp cận trạng thái không ổn
định, áp dụng hàm băm trên tập hợp con của năm bộ dữ liệu (địa chỉ nguồn, địa chỉ đích,
cổng nguồn, cổng đích và ID giao thức). Kiểu phân chia lưu lượng này khá dễ tính toán.
Mặc dù vậy, nó vẫn duy trì phân chia lưu lượng dựa trên luồng nhưng theo phương thức
này, lưu lượng luôn được phân phối đều trên các liên kết. Và hơn thế nữa vì trạng thái
không ổn định định nên kỹ thuật lưu lượng động không thể áp dụng cho các loại phương
pháp này. Phương pháp này không có tính linh hoạt [2].

12
2.5.4. Định tuyến lưu lượng theo các tham số liên quan đến QoS
Các tác giả khác nhau đã đề xuất kỹ thuật lưu lượng với một số số liệu được tính toán
như độ trễ gói hoặc mất gói, ... và áp dụng chúng để phân chia lưu lượng. Phương pháp này
rất thuận lợi nếu tính toàn vẹn của luồng được duy trì và nếu chi phí tính toán số liệu không
đáng kể [2].
2.6. Kết nối liên mạng
Theo truyền thống, kết nối các mạng với nhau được định nghĩa là các mạng kết nối
nhiều bộ xử lý. Tuy nhiên, các mạng kết nối đã phát triển mạnh mẽ trong 20 năm qua và
hiện đóng một vai trò quan trọng trong các lĩnh vực Data Center hoặc Hight Performance
Computing (HPC) [8].
Các cấu trúc liên kết cho các mạng kết nối có thể được phân thành bốn nhóm chính:
shared-bus networks, direct network, indirect network và hybrid network [8]. Lựa chọn cấu
trúc liên kết là một trong những bước quan trọng nhất khi xây dựng mạng kết nối. Cấu trúc
liên kết được chọn kết hợp với thuật toán định tuyến và khối lượng dữ liệu của ứng dụng
quyết định việc phân phối lưu lượng trong mạng [9].
2.6.1. Mô hình liên kết mạng fat-tree
Mô hình mạng fat-tree được sử dụng rộng rãi để xây dựng các mạng có quy mô vừa
và lớn [10]. Mô hình được tạo ra bởi Charles E. Leiserson của Viện Công nghệ
Massachusetts năm 1985.
Mô hình mạng fat-tree gồm nhiều liên kết giữa các host cho phép cung cấp băng thông
khả dụng cao hơn so với single-path tree có cùng số nút. Mô hình này có dạng một cây
phân cấp 3 lớp bao gồm các bộ chuyển mạch trên lớp core, lớp aggregation và lớp edge.
Các host kết nối với các bộ chuyển mạch trên lớp Edge. Tính năng đa đường của mạng fat-
tree cho phép phân phối lưu lượng dữ liệu trên các thành phần mạng khác nhau.

13
 Hình 2.4 Mô hình mạng fat-tree [9]
Mô hình liên kết mạng fat-tree có 3 đặc điểm khiến mô hình này có thể cung cấp các
kết nối hiệu suất cao [9]:
a) Loại bỏ hiện tượng deadlock, việc sử dụng cấu trúc cây định tuyến fat-tree mà
không cần sử dụng các kênh ảo để tránh deadlock.
b) Có khả năng chống lỗi, sự dự phòng của nhiều đường giữa các cặp nguồn-đích
riêng lẻ giúp xử lý lỗi mạng dễ dàng hơn.
c) Băng thông chia đôi đầy đủ, mạng có thể duy trì liên lạc tốc độ đầy đủ giữa hai
nửa của mạng.
Mặc dù fat-tree topology cung cấp kết nhiều kết nối dự phòng, nhưng chỉ mỗi cấu trúc
liên kết fat-tree thì không đảm bảo hiệu suất mạng cao: cơ chế định tuyến cũng đóng một
vai trò quan trọng. Trong lịch sử, định tuyến thích ứng tự động xây dựng đường dẫn cho
gói dựa trên các điều kiện mạng, đã được sử dụng với cấu trúc liên kết fat-tree để đạt được
cân bằng tải trong mạng. Tuy nhiên, việc định tuyến trong hầu hết hệ thống mạng khu vực
hiện nay mang tính quyết định. Đối với hệ thống mạng khu vực dựa trên fat-tree với định
tuyến xác định, điều quan trọng là sử dụng sơ đồ định tuyến cân bằng tải hiệu quả để khai
thác triệt để nhiều kết nối được cung cấp bởi cấu trúc liên kết của fat-tree [10].
2.7. Thuật toán Dijkstra
Thuật toán của Dijkstra, được tìm ra bởi nhà khoa học máy tính người Hà Lan Edsger
Dijkstra vào năm 1956 và được công bố vào năm 1959, là một thuật toán tìm kiếm đồ thị
tìm đường đi ngắn nhất từ nguồn tới đích với chi phí đường nhỏ nhất, tạo ra cây đường đi
ngắn nhất [11].

14
 Thuật toán này thường được sử dụng trong định tuyến và là một chương trình con
trong các thuật toán đồ thị khác. Đối với một đỉnh nguồn (nút) nhất định trong biểu đồ,
thuật toán tìm đường đi có chi phí nhỏ nhất (đường dẫn ngắn nhất) giữa đỉnh đó và mọi
đỉnh khác [11].
Thuật toán cũng có thể được sử dụng để tìm chi phí của các đường đi ngắn nhất từ
một đỉnh đơn đến một đỉnh đích duy nhất bằng cách dừng thuật toán khi đường dẫn ngắn
nhất tới đỉnh đích được xác định. Ví dụ: nếu các đỉnh của biểu đồ biểu thị các thành phố và
chi phí đường dẫn biểu thị khoảng cách lái xe giữa các cặp thành phố được kết nối bằng
một con đường trực tiếp, thuật toán của Dijkstra có thể được sử dụng để tìm tuyến đường
ngắn nhất giữa một thành phố với tất cả các thành phố khác. Do đó, đường đi ngắn nhất
đầu tiên được sử dụng rộng rãi trong các giao thức định tuyến mạng, đáng chú ý nhất là IS-
IS và OSPF [7].
2.8. Thuật toán cân bằng tải động trong mạng SDN
Thuật toán cân bằng tải này áp dụng các ưu điểm và tính năng của SDN. Bởi vì SDN
controller có thể nhận biết trạng thái của từng thành phần trên mạng từ đó đưa ra hành động
tiếp theo [1].
Để mô tả thuật toán, các kiểu cấu trúc dữ liệu khác nhau được định nghĩa. Các cấu
trúc này đặc trưng cho các thành phần khác nhau đã được tính đến để đạt được sự cân bằng
tải hiệu quả, đồng thời để giảm càng nhiều chi phí tính toán và thời gian càng tốt [2].
Các cấu trúc dữ liệu chính được giải thích bao gồm [17][18]:
2.8.1. Flow
Thuật toán cung cấp cân bằng tải dựa trên các luồng, nên cần xác định một cấu trúc
để mô tả từng luồng khác nhau với các tham số đặc biệt.
Thuật toán tính đến việc sử dụng IP của các Port để tính toán luồng, nhưng khi sử
dụng OpenFlow, có thể xác định chính xác hơn từng luồng với bất kỳ trường tiêu đề nào.
Cấu trúc Flow xác định một luồng lưu lượng cụ thể từ host này sang host khác.
Flow= {<FlowID>, <SrcIP>, <DstIP>, <SrcPort>, <DstPort>, <usedBandference>}
FlowID: Một ID duy nhất xác định mỗi luồng.
SrcIP: Trường này chứa IPv4 của host nguồn đã khởi tạo luồng.
DstIP: IPv4 của host đích.
SrcPort: Số cổng của nguồn.

15
 DstPort: Số cổng của đích.
UseBandwidth: Tốc độ truyền của một luồng cụ thể, đơn vị Mbps.
2.8.2. Flows Collection
Các luồng có đặc điểm chung được đặt cùng trong một tập hợp (ví dụ: các luồng đi
qua cùng một liên kết).
FlowsCollection = {<Flow 1>, <Flow2> ... <Flow n>}
2.8.3. Path
Cấu trúc Path giữ thông tin về mỗi tuyến giữa mỗi cặp host, điều này rất quan trọng
để chuyển hướng các luồng theo các điều kiện mạng hiện tại. Để thực hiện theo dõi, một
cấu trúc dữ liệu thể hiện cho từng đường dẫn đã được thiết kế.
Cấu trúc Path chứa thông tin về một đường dẫn chính xác giữa hai host và nó được
cấu tạo như bên dưới:
Path = {<PathID>, <Hops>, <Links>, <Ingress>, <Egress>, <Capacity>, < Flows>,
<UseBandwidth>, <FreeCapacity>}
PathID: Một ID duy nhất xác định đường dẫn khả dụng.
Hops: Chứa một định danh của mỗi bộ chuyển mạch trong đường dẫn.
Links: Danh sách tất cả các liên kết bên trong đường dẫn. Mỗi liên kết được tạo bởi
một cặp định danh Switch-Port.
Ingress: Một định danh của bộ chuyển mạch, host nguồn được kết nối tới Ingress này.
Egress: Một định danh của bộ chuyển mạch, host đích được kết nối tới Egress này.
Capacity: Chỉ định tải tối đa của đường dẫn. Nó chính là tải của liên kết có dung lượng
nhỏ nhất dọc theo đường dẫn.
Flows: Danh sách các luồng được định tuyến qua đường dẫn này.
UseBandwidth: Tổng lưu lượng của tất cả các luồng đang sử dụng đường dẫn này,
tính bằng Mbps.
Free Capacity: Dung lượng còn khả dụng trong đường dẫn này.
2.8.4. Paths Collection
Path Collection chứa danh sách tất cả các đường dẫn khả thi của các host được kết nối
với nhau và thông tin về từng đường dẫn [1].
PathsCollection = {<Path 1>, <Path 2> ... <Paht n>}

16
2.9. Các nghiên cứu khoa học liên quan
Vào năm 2015, Yuanhao Zhou, Li Ruan, Limin Xiao và Rui Liu công bố bài báo “A
Method for Load Balancing based on Software-Defined Network”. Bài viết trình bày một
phương pháp cân bằng tải dựa trên nền tảng SDN. Nó thực hiện cân bằng tải theo bộ điều
khiển PyResonance. PyResonance là một nền tảng điều khiển thực hiện kiểm soát mạng
theo sự kiện. Nó thực hiện mô hình Finite State Machine (FSM) để xác định chính sách
mạng. Bài báo cho thấy lưu lượng truy cập có thể được phân phối hiệu quả và dễ dàng hơn
với sự trợ giúp của giải pháp đề xuất [12].
Vào đầu năm 2017, A. A. Neghabi, N. J. Navimipour, M. Hosseinzadeh, and A.
Rezaee đã công bố bài báo “Load balancing mechanisms in the software defined networks”.
Trong bài báo này, mạng Software Defined Networking sử dụng giao thức OpenFlow đã
được triển khai để cải thiện hiệu quả cân bằng tải trong các mạng doanh nghiệp. Bằng cách
sử dụng kỹ thuật này, mạng có thể lập trình trực tiếp và thay đổi nhanh với các thay đổi
trong mạng. Ở đây, các http request từ các máy khách khác nhau sẽ được chuyển đến các
máy chủ http được xác định trước dựa trên lập lịch Round-Robin. Lập lịch Round-Robin
rất dễ thực hiện và rất tốt để được sử dụng trong các máy chủ web phân tán theo địa lý [2].
Vào năm 2018, S. Patil công bố bài báo “Load Balancing Approach for Finding Best
Path in SDN”. Bài báo cho thấy các hạn chế chính là mặt phẳng chuyển tiếp được cấu hình
tĩnh và cân bằng tải không đồng đều giữa các bộ điều khiển trong mạng. Bài báo đã đề xuất
Bộ cân bằng tải động giúp tự động chuyển tải sang đường dẫn ngắn nhất khác khi nó có
băng thông lớn hơn liên kết hiện tại. Bằng phân tích thử nghiệm, bài báo đã kết luận rằng
phương pháp đề xuất cho kết quả tốt hơn về mặt phản hồi/giây và hiệu quả so với thuật toán
cân bằng tải Round-Robin hiện có [13].

17
 3. CHƯƠNG 3
PHƯƠNG PHÁP LUẬN
3.1. Giới thiệu
Chương ba mô tả thuật toán được thiết kế để thực hiện một hệ thống cân bằng tải
động, trình bày các thành phần và công cụ phần mềm được sử dụng trong khóa luận này để
cài đặt thử nghiệm.
3.2. Mô tả thuật toán
Như đã giải thích từ trước, thuật toán phân phối lưu lượng của các luồng lưu lượng
mạng sắp tới và các luồng lưu lượng trong mạng để đạt được hiệu quả sử dụng tài nguyên
tốt nhất có thể cho mỗi liên kết trong mạng. Để đạt được mục tiêu, chương trình cần phải
theo dõi tình trạng hiện tại của mạng. Hình 3-1 minh họa các bước của thuật toán cân bằng
tải [14].

Hình 3.1 Flow Chart thuật toán cân bằng tải

18
 Ý tưởng cơ bản: sử dụng các REST API có sẵn của controller (OpenDaylight
controller) để thu thập thông tin hoạt động trong mô hình liên kết mạng và thông tin về các
thiết bị của mạng.
Các bước thực hiện:
1. Đầu tiên thuật toán sẽ thu thập thông tin hoạt động của cấu trúc liên kết mạng và
các thiết bị của nó. Chẳng hạn như địa chỉ IP, địa chỉ MAC, Ports, Connections, …
2. Tiếp theo là tìm thông tin tuyến đường dựa trên thuật toán của Dijkstra, mục đích
là thu hẹp tìm kiếm vào một phân đoạn mạng nhỏ của cấu trúc liên kết mạng fat-tree
và để tìm các đường dẫn ngắn nhất từ host nguồn đến host đích (là các host được
thực hiện cân bằng tải).
3. Tìm tổng chi phí liên kết cho tất cả các đường dẫn giữa máy chủ nguồn và đích.
Các API request được thực hiện để tính toán chi phí này.
4. Khi chi phí của các liên kết được tính toán, các luồng được tạo tùy thuộc vào chi
phí tối thiểu của các liên kết tại thời điểm đã cho.
5. Dựa trên chi phí, đường dẫn tốt nhất được chọn và các luồng lưu lượng được đẩy
vào từng bộ chuyển mạch trong đường dẫn tốt nhất này. Cùng với đó, các bộ chuyển
mạch trong đường dẫn đã chọn sẽ có các mục lưu lượng cần thiết để thực hiện giao
tiếp giữa hai điểm cuối.
6. Cuối cùng, chương trình tiếp tục cập nhật thông tin này mỗi phút do đó làm cho nó
linh hoạt đối với các thay đổi xảy ra trong mạng.
3.3. Tiến trình thực hiện cài đặt thử nghiệm
Trong khóa luận này, thử nghiệm được triển khai trong môi trường Linux, sử dụng
phần mềm Mininet để mô phỏng mạng, nền tảng OpenDaylight mã nguồn mở (ODL) được
dùng làm bộ điều khiển SDN và ngôn ngữ lập trình Python để xác định cấu trúc liên kết
của fat-tree, viết chương trình cân bằng tải, và iPerf, jPerf để kiểm tra hiệu năng mạng. Sơ
đồ sau minh họa các bước thiết kế.

19
 Hình 3.2 Cài đặt thử nghiệm
3.4. Công cụ phần mềm
3.4.1. Mininet
Mininet là trình giả lập mạng cho phép tạo mạng trên một máy tính. Nó có thể chạy
một tập hợp các máy chủ, bộ chuyển mạch, bộ định tuyến và các liên kết trên một nhân
Linux. Nó sử dụng ảo hóa để làm cho một hệ thống giống như một mạng hoàn chỉnh, chạy
cùng một kernel, cùng một hệ thống và người dùng.
Ưu điểm chính của Mininet:
1. Mininet là một dự án mã nguồn mở.
2. Có thể tạo ra các cấu trúc liên kết tùy chỉnh.
3. Mininet chạy các chương trình thực.
4. Việc chuyển tiếp gói có thể được tùy chỉnh.
So với các trình giả lập khác, Mininet chạy trên hệ thống thực, dễ dàng kết nối với các
mạng thực, dễ dàng sử dụng.

20
3.4.2. Dự án OpenDaylight (ODL)
Dự án OpenDaylight (ODL) là một module bộ điều khiển đa giao thức, có tính khả
dụng cao, có thể mở rộng, được xây dựng để triển khai nền tảng SDN trên các mạng đa nhà
cung cấp. ODL cung cấp một nền tảng trừu tượng hóa dịch vụ theo mô hình cho phép người
sử dụng viết các ứng dụng hoạt động dễ dàng trên nhiều loại phần cứng khác nhau cũng
như các giao thức phía Nam khác nhau [15].
Hơn nữa, nó chứa các plugin bên trong cho phép cung cấp thêm các dịch vụ và chức
năng cho mạng. Ví dụ, ODL controller có các plugin động cho phép thu thập số liệu thống
kê mạng để có được cấu trúc liên kết của mạng [15].

Hình 3.3 Kiến trúc OpenDaylight [15]

3.4.3. iPerf
iPerf là một công cụ kiểm tra mạng thường được sử dụng để đo hiệu suất băng thông
của giao thức TCP (Transmission Control Protocol), UDP (User Datagram Protocol) và
chất lượng của các liên kết mạng. Bằng cách điều chỉnh các tham số khác nhau liên quan
đến thời gian, các bộ đệm và giao thức (TCP, UDP, SCTP với IPv4 và IPv6), người dùng
có thể thực hiện một số bài kiểm tra cung cấp cái nhìn chi tiết về băng thông khả dụng,

21
thông lượng, độ trễ, jitter và mất dữ liệu của mạng. iPerf là một phần mềm mã nguồn mở
và chạy trên nhiều nền tảng khác nhau bao gồm Linux, UNIX và Windows [16].

Hình 3.4 Công cụ đo băng thông iPerf [16]

3.4.4. Ngôn ngữ lập trình: Python
Ngôn ngữ Python đã được sử dụng trong Mininet để xác định cấu trúc liên kết fat-
tree, Python cũng được sử dụng để viết chương trình thuật toán cân bằng tải.
Python là một ngôn ngữ hướng đối tượng, phù hợp cho nhiều mục đích lập trình. Nó
có cú pháp rõ ràng, trực quan, cấu trúc dữ liệu cấp cao mạnh mẽ và hệ thống kiểu động linh
hoạt. Python có thể được sử dụng trong các kịch bản độc lập, cho các chương trình lớn hoặc
làm ngôn ngữ mở rộng cho các ứng dụng hiện hiện tại. Ngôn ngữ này hiện chạy trên các
hệ điều hành Linux, Macintosh và Windows.
Python có thể dễ dàng mở rộng thông qua các module được viết bằng C hoặc C ++ và
cũng có thể nhúng chúng trong các ứng dụng dưới dạng thư viện. Python cũng có một số
phần mở rộng dành riêng cho hệ thống. Một thư viện lớn các module chuẩn được viết bằng
Python có sẵn để sử dụng.
So với C, các chương trình Python ngắn hơn, do đó viết đơn giản và nhanh hơn nhiều.
So với Perl, mã Python dễ đọc, dễ viết và dễ bảo trì hơn. Đối với TCL, Python cũng phù
hợp hơn cho các chương trình lớn hơn hoặc phức tạp hơn [17].

22
 4. CHƯƠNG 4
KẾT QUẢ THỬ NGHIỆM VÀ ĐÁNH GIÁ HIỆU SUẤT
4.1. Giới thiệu
Chương 4 mô tả các kịch bản được đề xuất, sau đó trình bày và giải thích các kết quả
thu được với các kịch bản được đề xuất.
4.2. Network Topology
Cấu trúc liên kết mạng được sử dụng trong khóa luận này là cấu trúc liên kết Data
Center fat-tree ba cấp. Nó bao gồm 8 Server, 4 Switch biên, 4 Switch gom và 2 Switch lõi.
Như được trình bày trong hình.

Hình 4.1 Mô hình mạng cho thử nghiệm

4.3. Các bước mô phỏng
Mục tiêu của thuật toán cân bằng tải được đề xuất là cải thiện quản lý lưu lượng trong
mạng trung tâm dữ liệu (Data Center) khi tắc nghẽn xảy ra. Ban đầu, các bộ chuyển mạch
và liên kết thực hiện chuyển tiếp gói thông thường (không áp dụng cân bằng tải) được theo
dõi và ghi lại ở giai đoạn trước cân bằng tải (BLB). Sau đó, khi các đường dẫn bị tắc nghẽn,
thuật toán cân bằng tải được áp dụng. Một lần nữa, các bộ chuyển mạch và liên kết được
theo dõi để đánh giá hiệu suất của thuật toán để quản lý lưu lượng ở giai đoạn sau cân bằng
tải (ALB).
Thực hiện kết nối bộ điều khiển OpenDaylight với Mininet thông qua cổng 6653 đã
được định rõ. Mô hình liên kết mạng DC được tạo với 8 host, 10 bộ chuyển mạch và 20

23
liên kết bằng cách chạy chương trình được viết bằng Python trong Mininet, như trong hình.
Lệnh pingall được thực thi để kiểm tra xem tất cả các host trong mạng được thông hay
chưa.

Hình 4.2 Chạy chương trình dựng Topo mạng

Tham số Bộ điều khiển

Địa chỉ IP 192.168.56.101

Port 6653

CLI Có

Phiên bản OpenFlow 1.3

Giao thức TCP

Switch OVS

Bảng 1: Các tham số của bộ điều khiển OpenDaylight:

24
 Thực hiện chạy chương trình mô hình mạng fat-tree, trên giao diện của ODL controller
sẽ hiển thị như sau:

Hình 4.3 Giao diện hiển thị của ODL controller

API REST thu thập thông tin về các host và các bộ chuyển mạch như địa chỉ IP, Địa
chỉ MAC, Port, tốc độ bit liên kết, tốc độ truyền, tốc độ nhận, … về mạng để quản lý lưu
lượng. Các API REST thể hiện chúng dưới dạng định dạng dữ liệu json hoặc html trên cổng
8181.

Hình 4.4 Thống kê các tham số trên mỗi node

25
 Hình 4.5 API request
Chạy thuật toán cân bằng tải viết bằng Python và lấy thông tin đường dẫn để thực hiện
quản lý lưu lượng. Tổng chi phí liên kết và các đường dẫn ngắn nhất được tính cho tất cả
các đường dẫn này giữa các host.

Hình 4.6 Chạy chương trình cân bằng tải

Các luồng được sắp xếp dựa trên mức độ ưu tiên và chi phí truyền tối thiểu (bit/s) của
các liên kết tại thời điểm đã cho. Khi tắc nghẽn xảy ra trong một đường dẫn, đường dẫn tốt

26
nhất thay thế được quyết định dựa trên khoảng cách tối thiểu và chi phí liên kết. Các luồng
sau đó được đẩy vào từng bộ chuyển mạch theo đường dẫn tốt nhất được chọn. Thông tin
như In-Port, Out-Port, IP nguồn, IP đích, MAC nguồn, MAC đích được cung cấp cho các
luồng. Cân bằng tải trở nên linh hoạt với thay đổi trong mạng khi chương trình liên tục chạy
thuật toán để cập nhật thông tin.
4.4. Kịch bản test
4.4.1. Kịch bản 1: Đo lường hiệu suất mạng khi thực hiện cân bằng tải ở lớp
Aggregation
Thuật toán cân bằng tải có thể chạy giữa bất kỳ host nào trong mạng đã xác định. Để
hiểu rõ về tiến trình này ta thực hiện cân bằng tải giữa host nguồn: host 1 và host đích: host
3 và host 4.
Như được trình bày trong hình dưới đây: host 1 truyền các gói thông qua OpenvSwitch
(OVS) s1-eth1 (Switch SW1 Port 1); Switch SW1 sau đó chuyển tiếp các gói tới host 3 và
host 4 thông qua s1-eth3 (Switch SW1 Port 3). Wireshark được sử dụng để chụp các đường
dẫn mà s1 chọn để đến đích.

Hình 4.7 Đường đi của gói trước cân bằng tải

Các luồng lưu lượng từ host 1 đến host 3 và host 4 chỉ được chuyển qua Switch SW1
qua Port 3 (s1-eth3), không có luồng nào trong SW1 qua Port 4 (s1-eth4). Lưu lượng truy
cập nhỏ được hiển thị trong cổng 4 (s1-eth4) là do các gói DLDP (giao thức phát hiện liên
kết thiết bị) được gửi thường xuyên từ API REST để thu thập số liệu thống kê.

27
Các bước thực hiện kiểm tra kết quả mô phỏng:
1. Trong console đầu tiên của h1, ping 10.0.0.3
2. Trong console thứ hai của h1, ping 10.0.0.4
3. Chạy wireshark
4. Trong wireshark, đi đến Capture-> Interfaces, chọn s1-eth3 và bắt đầu chụp.
5. Trong phần filter của wireshark, gõ ip.addr == 10.0.0.3 và kiểm tra xem có gói
tin truyền từ h1 -> h3 không. Tương tự cho h1-> h4. Ta có thể thấy rằng đây là
đường dẫn tốt nhất.
6. Để xác nhận lại, ta lặp lại hai bước trên cho s1-eth4 và thấy rằng không có gói
nào được truyền đến cổng này. Chỉ các gói nó sẽ multicast phát đa hướng.
7. Tiếp theo, trong cosole thứ hai của h1, dừng ping h4. Mục tiêu của ta là tạo ra
tắc nghẽn trên con đường tốt nhất của h1-> h3, h1-> h4 qua giao diện s1-eth4,
chỉ cần h1 ping h3 là đủ.
8. Chuyển đến Terminal và chạy code cân bằng tải.
9. Cung cấp các đối số đầu vào như host 1, host 2 và hàng xóm của host 2.
10. Chương trình cân bằng tải thực hiện các yêu cầu REST API. Sau khi kích hoạt
thống kê, phải mất một thời gian để thu thập thông tin. Khi nó bắt đầu cập tốc độ
truyền, ta sẽ có được đường dẫn tốt nhất và các luồng cho đường dẫn tốt nhất sẽ
được đẩy đến tất cả các bộ chuyển mạch cho tuyến tốt nhất tìm được. Ở đây tuyến
đường tốt nhất là cho h1-> h4 và ngược lại
11. Để kiểm tra các luồng, thực hiện yêu cầu REST GET tới
http://127.0.0.1:8080/wm/core/switch/all/flow/json
12. Trên console thứ hai của h1 gõ ping 10.0.0.4
13. Đi tới wireshark và theo dõi giao diện s1-eth4 với bộ lọc ip.addr == 10.0.0.x
trong đó x là 3 và 4. Bạn sẽ tìm thấy các gói 10.0.0.3 nhưng không có gói 10.0.0.4
14. Dừng chụp ở trên và bây giờ thực hiện chụp trên s1-eth3, s21-eth1, s21-eth2, s2-
eth3 với bộ lọc ip.addr == 10.0.0.x trong đó x là 3 và 4. Bạn sẽ tìm thấy 10.0. 0,4
gói nhưng không có gói 10.0.0.3

28
 Hình 4.8 Đường đi của gói sau khi chạy chương trình cân bằng tải
Các tham số hiệu suất mạng được kiểm tra trước và sau khi chạy thuật toán cân bằng
tải. Việc kiểm tra tập trung vào một số tham số QoS như thông lượng, độ trễ, jitter và mất
gói giữa hai Server trong mô hình mạng fat-tree.

Hình 4.9 Ping từ h1 tới h3 trước cân bằng tải

29
Hình 4.10 Ping từ h1 tới h4 trước cân bằng tải

Hình 4.11 Ping từ h1 tới h4 sau cân bằng tải

30
4.4.1.1. Kiểm tra kết quả của kịch bản 1
Thực hiện kiểm tra mười lần trước và sau khi chạy thuật toán cân bằng tải, để nghiên
cứu bất kỳ hành vi bất thường, đưa ra kết quả trung bình. Bảng dưới đây minh họa các kết
quả thu được.

Ping từ h1 tới h3 Ping từ h1 tới h4

Transfer Throughput Transfer Throughput
(Mbytes) (Mbits/s) (Mbytes) (Mbits/s)
Trước cân bằng tải 158.777 131 196.8 161.5
Sau cân bằng tải 461 381 475.5 392.4

Bảng 2. Bảng tổng hợp kết quả kịch bản 1

4.4.1.2. Phân tích đánh giá hiệu quả thuật toán
Kết quả kiểm tra mạng đã cho thấy một hiệu suất tốt hơn sau khi chạy chương trình
cân bằng tải. Thông lượng mạng trung bình trước khi cân bằng tải là 219,5 Mbits/s và trở
thành 25,4 Mbits/s sau khi cân bằng tải. Độ trễ trung bình đã giảm 73,36% sau khi cân bằng
tải với mức trung bình là 0,1372 ms, jitter đã giảm 94.17% và tỷ lệ mất gói đã giảm 4.37%.

Hình 4.12 So sánh kết quả thông lượng kịch bản 1

31
 Hình 4.13 So sánh tham số QoS kịch bản 2
4.4.2. Kịch bản 2: Đo lường hiệu suất mạng khi thực hiện cân bằng tải có sự tham gia
của lớp Core
Trong kịch bản thứ 2, thực hiện cân bằng tải giữa host 1 và host 7. Trong kịch bản
này, lưu lượng sẽ phải đi qua các Switch lõi để đến đích. Hình 4-8 dưới đây cho thấy các
host được chọn và các đường dẫn lưu lượng có thể đi qua.

Hình 4.14 Sơ đồ minh họa cho kịch bản 2

32
 Các tham số của mạng đã được kiểm tra trước và sau khi chạy thuật toán cân bằng tải.
Việc kiểm tra tập trung vào một số tham số QoS như thông lượng, trễ, jitter và mất gói giữa
hai host 1 và host 7 trong mạng fat-tree.

Hình 4.15 Ping từ h1 tới h7 trước cân bằng tải

Hình 4.16 Ping từ h1 tới h8 trước cân bằng tải

33
 Hình 4.17 Ping từ h1 tới h8 sau cân bằng tải
4.4.2.1. Kiểm tra kết quả kịch bản 2
Việc kiểm tra được thực hiện 10 lần trước và sau khi chạy chương trình cân bằng tải.
Bảng dưới đây minh họa các kết quả thu được
Bảng tổng hợp kết quả:
Ping từ h1 tới h7 Ping từ h1 tới h8
Transfer Throughput Transfer Throughput
(Mbytes) (Mbits/s) (Mbytes) (Mbits/s)
Trước cân bằng tải 138.57 124.7 153.3 126
Sau cân bằng tải 409.5 338 422.3 343.6

Bảng 3. Bảng tổng hợp kết quả kịch bản 2

4.4.2.2. Phân tích đánh giá hiệu quả thuật toán
Trong kịch bản thứ hai, kết quả kiểm tra hiệu suất mạng cho thấy hiệu suất tốt sau khi
chạy chương trình cân bằng tải. Thông lượng mạng trung bình trước khi chạy cần bằng tải
là 125,35 Mbits/giây và trở thành 342 Mbits/giây sau khi cân bằng tải với tỷ lệ tăng 2.5 lần.
Độ trễ trung bình đã giảm 10.8% sau khi cân bằng tải với mức trung bình là 0,5391 ms.
Nhưng jitter trung bình đã tăng từ 0,3736 ms lên 1,891 ms sau khi cân bằng tải, và mất gói
cũng tăng 4,9%.

34
Biểu đồ minh họa kết quả:

Hình 4.18 So sánh kết quả thông lượng kịch bản 2

Hình 4. 19 So sánh tham số QoS kịch bản 2

35
4.4.3. Nhận xét
Chương trình cân bằng tải đã giúp tăng thông lượng mạng trong cả hai kịch bản. Nó
cho thấy một hiệu suất tuyệt vời khi thực hiện cho phân đoạn nhỏ (lớp 2 của mô hình fat-
tree), nhưng khi mạng phát triển lớn hơn và các Switch lõi tham gia định tuyến, mất gói và
jitter tăng (hiện tượng này xảy ra khi lưu lượng đi qua nhiều Switch).
Trước khi áp dụng thuật toán cân bằng tải, ta đã quan sát lưu lượng giữa host 1 là
nguồn, host 3 và host 4 là đích. Mặc dù có sẵn nhiều đường đi trong mô hình mô phỏng cấu
trúc liên kết fat-tree, các luồng lưu lượng từ bộ chuyển mạch SW1 sang bộ chuyển mạch
SW2 chỉ sử dụng cùng một đường dẫn qua s1-eth3 thay vì sử dụng đường dẫn thứ hai có
cùng chi phí (s1-eth4). Do đó, một vài liên kết chịu tải nặng sẽ tắc nghẽn trong khi phần
lớn các liên kết khả dụng vẫn chưa được sử dụng đúng mức dẫn đến tải lưu lượng không
cân bằng.
Chương trình sẽ tự động thu thập dữ liệu và thống kê liên kết từ các yêu cầu API
REST theo các liên kết có sẵn, tốc độ truyền của mỗi host và bộ chuyển mạch. Nó tìm thấy
đường dẫn ngắn nhất với chi phí và tải ít nhất và cập nhật vào bảng chuyển tiếp với các quy
tắc luồng mới. Trong quá trình mô phỏng, thuật toán cân bằng tải đã đẩy các luồng qua giao
diện s1-eh4 để tới được host 4 khi liên kết s1-eh3 đang chịu mức độ tải sử dụng cao hơn.
Do đó, thuật toán cân bằng tải thay thế đường dẫn cũ bằng đường dẫn thay thế tốt với chi
phí liên kết tối thiểu và chia sẻ lưu lượng đồng đều giữa các đường dẫn ngắn nhất khác
nhau.
Kết quả mô phỏng cho thấy thuật toán cân bằng tải xử lý chuyển tiếp gói tốt hơn,
thuật toán cân bằng tải cho phép độ trễ thấp hơn bằng cách giảm thời gian khứ hồi, thông
lượng cao hơn bằng cách tăng băng thông liên kết có sẵn và mất gói tin thấp hơn. Khóa
luận này chỉ ra rằng thuật toán cân bằng tải động được đề xuất có thể nâng cao chất lượng
trải nghiệm của người dùng cuối và cho phép sử dụng tối ưu hơn cơ sở hạ tầng bên dưới.

36
 KẾT LUẬN VÀ ĐỊNH HƯỚNG NGHIÊN CỨU TRONG TƯƠNG LAI
Mạng trung tâm dữ liệu (DCN) là mạng trục của các dịch vụ Internet. Giờ đây, với sự
xuất hiện của nền tảng SDN và công nghệ NFV đã đơn giản hóa đáng kể và cải thiện quản
lý DCN. Hiệu suất của các mạng trung tâm dữ liệu phụ thuộc vào việc sử dụng tài nguyên
mạng một cách phù hợp và kịp thời cho các dịch vụ của người dùng cuối. Việc quản lý tải
truyền thống được sử dụng trong DCN gặp phải hiện tượng một số liên kết gặp chịu sự quá
tải trong khi các liên kết còn lại không được sử dụng đúng mức. Các kỹ thuật quản lý lưu
lượng trong mạng trung tâm dữ liệu dựa trên SDN cung cấp quản lý lưu lượng tối ưu hơn.
Khóa luận này thực hiện triển khai thuật toán cân bằng tải động để phân phối hiệu quả
các luồng lưu lượng trong mô hình mạng fat-tree thông qua nhiều đường dẫn khác nhau
giữa một cặp host nguồn-đích. Các tham số liệu quan đến hiệu suất của mạng đã được kiểm
tra trước và sau khi chạy thuật toán cân bằng tải. Việc thử nghiệm tập trung vào một số
tham số QoS như thông lượng, độ trễ và mất gói giữa hai máy chủ trong mô hình mạng fat-
tree, tính toán chi phí của mỗi liên kết cùng với xem xét mức độ ưu tiên của luồng. Khi tắc
nghẽn xảy ra, nó thay thế đường dẫn cũ bằng tuyến đường mới tốt nhất với chi phí liên kết
tối thiểu và khoảng cách ngắn nhất. Chương trình sẽ liên tục chạy để cập nhật các thay đổi
trong mạng, do đó sẽ cải thiện hiệu suất cân bằng tải với độ trễ giảm và băng thông tăng
một cách linh hoạt với thay đổi. Kết quả phân tích đánh giá đã cho thấy hiệu suất mạng đã
tăng lên sau khi chạy chương trình thuật toán cân bằng tải, thuật toán có thể tăng thông
lượng và cải thiện hiệu suất sử dụng mạng. Tuy nhiên, trong các mạng lớn, tỷ lệ mất gói và
jitter tăng lên.
Về hướng nghiên cứu trong tương lai, các đề xuất phát triển thuật toán tiếp theo có
thể như sau:
- Nghiên cứu hoạt động của chương trình cân bằng tải động trên các bộ điều khiển
SDN phổ biến khác, như Tungsten fabric, Floodlight, Beacon, NOX/POX, ... và so sánh
kết quả.
- Nghiên cứu đánh giá hiệu suất của thuật toán trong các cấu trúc liên kết mạng khác
nhau ngoài cấu trúc fat-tree, với các quy mô mạng khác nhau. Để có đánh giá, kiểm tra,
khắc phục các hạn chế của thuật toán.
- Cuối cùng là mở rộng thuật toán sang các mạng truyền thống, hoặc các mạng lai có
cả bộ chuyển mạch OpenFlow và các bộ chuyển mạch thông thường.

37
 TÀI LIỆU THAM KHẢO:
[1] D. Kreutz, F. M. V. Ramos, P. E. Verissimo, C. E. Rothenberg, S. Azodolmolky,
and S. Uhlig, “Software-defined networking: A comprehensive survey,” Proc.
IEEE, vol. 103, no. 1, pp. 14–76, 2015.
[2] A. A. Neghabi, N. J. Navimipour, M. Hosseinzadeh, and A. Rezaee, “Load
balancing mechanisms in the software defined networks : a systematic and
comprehensive review of the literature,” vol. 3536, no. c, 2018.
[3] T. D. Nadeau and K. Gray, T.D. Nadeau and Ken Gray, “Centralized and
distributed Control and Data Plane” in Software Defined Networks, Sebastopol:
O’REILLY, 2013. .
[4] IPknowledge, “Traditional vs Software Defined Networking,” 2014.
[5] W. Braun and M. Menth, “Software-Defined Networking Using OpenFlow:
Protocols, Applications and Architectural Design Choices,” Futur. Internet, vol. 6,
no. 2, pp. 302–336, 2014.
[6] R. Kumar Singh, N. S. Chaudhari, and K. Saxena, “Load Balancing in IP/MPLS
Networks: A Survey,” Commun. Netw., vol. 04, no. 02, pp. 151–156, 2012.
[7] W. Yahya, A. Basuki, and J.-R. Jiang, “The extended dijkstra’s-based load
balancing for OpenFlow network,” Int. J. Electr. Comput. Eng., vol. 5, no. 2, pp.
289–296, 2015.
[8] O. Engineering and C. Bhubaneswar, “Fault Tolerance in Interconnection Network-
a Survey Laxminath Tripathy , 2 Devashree Tripathy and 3 C . R . Tripathy Central
Electronics Engineering Research Institute ( CEERI ) Pilani , India Sambalpur
University , Sambalpur , Odisha , India,” vol. 11, no. 2, pp. 198–214, 2015.
[9] Y. H. Lo, Y. Zhang, Y. Chen, H. L. Fu, and W. S. Wong, “The Global Packing
Number of a Fat-Tree Network,” IEEE Trans. Inf. Theory, vol. 63, no. 8, pp. 5327–
5335, 2017.
[10] X. Yuan, W. Nienaber, Z. Duan, and R. Melhem, “Oblivious routing in fat-tree
based system area networks with uncertain traffic demands,” IEEE/ACM Trans.
Netw., vol. 17, no. 5, pp. 1439–1452, 2009.
[11] M. Yan, “DIJKSTRA ’ S ALGORITHM.”
[12] Y. Zhou, L. Ruan, L. Xiao, and R. Liu, “A Method for Load Balancing based on
Software-Defined Network,” vol. 45, no. Cca, pp. 43–48, 2015.
[13] S. Patil, “Load Balancing Approach for Finding Best Path in SDN,” Proc. Int. Conf.
Inven. Res. Comput. Appl. ICIRCA 2018, no. Icirca, pp. 612–616, 2018.
[14] T. Huang, “Path Computation Enhancement in SDN Networks,” 2015.
[15] S. Badotra and J. Singh, “OpenDaylight as a controller for Software Defined

38
 Networking,” Int. J. Adv. Res. Comput. Sci., vol. 8, no. 5, p. 7, 2017.
[16] T. O. F. Contents, “Iperf Bandwidth Performance.”
[17] G. Van Rossum, “An introduction to Python for UNIX/C programmers,” Proc.
NLUUG najaarsconferentie, pp. 1–8, 1993.

39
 PHỤ LỤC

A. Mô hình mạng trên Mininet

#!/usr/bin/python
from mininet.node import CPULimitedHost, Host, Node
from mininet.node import OVSKernelSwitch
from mininet.topo import Topo

class fatTreeTopo(Topo):

"Fat Tree Topology"

def __init__(self):
"Create Fat tree Topology"

Topo.__init__(self)

#Add hosts
h7 = self.addHost('h7', cls=Host, ip='10.0.0.7', defaultRoute=None)
h8 = self.addHost('h8', cls=Host, ip='10.0.0.8', defaultRoute=None)
h1 = self.addHost('h1', cls=Host, ip='10.0.0.1', defaultRoute=None)
h2 = self.addHost('h2', cls=Host, ip='10.0.0.2', defaultRoute=None)
h4 = self.addHost('h4', cls=Host, ip='10.0.0.4', defaultRoute=None)
h3 = self.addHost('h3', cls=Host, ip='10.0.0.3', defaultRoute=None)
h5 = self.addHost('h5', cls=Host, ip='10.0.0.5', defaultRoute=None)
h6 = self.addHost('h6', cls=Host, ip='10.0.0.6', defaultRoute=None)

#Add switches
s10 = self.addSwitch('s10', cls=OVSKernelSwitch)
s3 = self.addSwitch('s3', cls=OVSKernelSwitch)
s17 = self.addSwitch('s17', cls=OVSKernelSwitch)
s4 = self.addSwitch('s4', cls=OVSKernelSwitch)
s18 = self.addSwitch('s18', cls=OVSKernelSwitch)
s1 = self.addSwitch('s1', cls=OVSKernelSwitch)
s11 = self.addSwitch('s11', cls=OVSKernelSwitch)
s21 = self.addSwitch('s21', cls=OVSKernelSwitch)
s22 = self.addSwitch('s22', cls=OVSKernelSwitch)
s2 = self.addSwitch('s2', cls=OVSKernelSwitch)

#Add links
self.addLink(h1, s1)
self.addLink(h2, s1)

40
self.addLink(h3, s2)
self.addLink(h4, s2)
self.addLink(h5, s3)
self.addLink(h6, s3)
self.addLink(h7, s4)
self.addLink(h8, s4)
self.addLink(s1, s21)
self.addLink(s21, s2)
self.addLink(s1, s10)
self.addLink(s2, s10)
self.addLink(s3, s11)
self.addLink(s4, s22)
self.addLink(s11, s4)
self.addLink(s3, s22)
self.addLink(s21, s17)
self.addLink(s11, s17)
self.addLink(s10, s18)
self.addLink(s22, s18)

topos = { 'mytopo': (lambda: fatTreeTopo() ) }

41
 B. Chương trình cân bằng tải
#!/usr/bin/env python

import requests
from requests.auth import HTTPBasicAuth
import json
import unicodedata
from subprocess import Popen, PIPE
import time
import networkx as nx
from sys import exit

# Method To Get REST Data In JSON Format

def getResponse(url,choice):

response = requests.get(url, auth=HTTPBasicAuth('admin',

'admin'))

if(response.ok):
jData = json.loads(response.content)
if(choice=="topology"):
topologyInformation(jData)
elif(choice=="statistics"):
getStats(jData)
else:
response.raise_for_status()

def topologyInformation(data):
global switch
global deviceMAC
global deviceIP
global hostPorts
global linkPorts
global G
global cost

for i in data["network-topology"]["topology"]:
for j in i["node"]:
# Device MAC and IP

42
 if "host-tracker-service:addresses" in j:
for k in j["host-tracker-service:addresses"]:
ip = k["ip"].encode('ascii','ignore')
mac = k["mac"].encode('ascii','ignore')
deviceMAC[ip] = mac
deviceIP[mac] = ip

# Device Switch Connection and Port

if "host-tracker-service:attachment-points" in j:

for k in j["host-tracker-service:attachment-
points"]:
mac = k["corresponding-
tp"].encode('ascii','ignore')
mac = mac.split(":",1)[1]
ip = deviceIP[mac]
temp = k["tp-
id"].encode('ascii','ignore')
switchID = temp.split(":")
port = switchID[2]
hostPorts[ip] = port
switchID = switchID[0] + ":" +
switchID[1]
switch[ip] = switchID

# Link Port Mapping

for i in data["network-topology"]["topology"]:
for j in i["link"]:
if "host" not in j['link-id']:
src = j["link-
id"].encode('ascii','ignore').split(":")
srcPort = src[2]
dst = j["destination"]["dest-
tp"].encode('ascii','ignore').split(":")
dstPort = dst[2]
srcToDst = src[1] + "::" + dst[1]
linkPorts[srcToDst] = srcPort + "::" + dstPort
G.add_edge((int)(src[1]),(int)(dst[1]))

def getStats(data):

43
 print "\nCost Computation....\n"
global cost
txRate = 0
for i in data["node-connector"]:
tx = int(i["opendaylight-port-statistics:flow-capable-
node-connector-statistics"]["packets"]["transmitted"])
rx = int(i["opendaylight-port-statistics:flow-capable-
node-connector-statistics"]["packets"]["received"])
txRate = tx + rx
#print txRate

time.sleep(2)

response = requests.get(stats, auth=HTTPBasicAuth('admin',

'admin'))
tempJSON = ""
if(response.ok):
tempJSON = json.loads(response.content)

for i in tempJSON["node-connector"]:
tx = int(i["opendaylight-port-statistics:flow-capable-
node-connector-statistics"]["packets"]["transmitted"])
rx = int(i["opendaylight-port-statistics:flow-capable-
node-connector-statistics"]["packets"]["received"])
cost = cost + tx + rx - txRate

#cost = cost + txRate

#print cost

def systemCommand(cmd):
terminalProcess = Popen(cmd, stdout=PIPE, stderr=PIPE,
shell=True)
terminalOutput, stderr = terminalProcess.communicate()
print "\n*** Flow Pushed\n"

def pushFlowRules(bestPath):

44
 bestPath = bestPath.split("::")

for currentNode in range(0, len(bestPath)-1):

if (currentNode==0):
inport = hostPorts[h2]
srcNode = bestPath[currentNode]
dstNode = bestPath[currentNode+1]
outport = linkPorts[srcNode + "::" + dstNode]
outport = outport[0]
else:
prevNode = bestPath[currentNode-1]
#print prevNode
srcNode = bestPath[currentNode]
#print srcNode
dstNode = bestPath[currentNode+1]
inport = linkPorts[prevNode + "::" + srcNode]
inport = inport.split("::")[1]
outport = linkPorts[srcNode + "::" + dstNode]
outport = outport.split("::")[0]

xmlSrcToDst = '\'<?xml version=\"1.0\" encoding=\"UTF-8\"

standalone=\"no\"?><flow
xmlns=\"urn:opendaylight:flow:inventory\"><priority>32767</priority>
<flow-name>Load Balance 1</flow-name><match><in-port>' + str(inport)
+'</in-port><ipv4-destination>10.0.0.1/32</ipv4-destination><ipv4-
source>10.0.0.4/32</ipv4-source><ethernet-match><ethernet-
type><type>2048</type></ethernet-type></ethernet-
match></match><id>1</id><table_id>0</table_id><instructions><instruc
tion><order>0</order><apply-actions><action><order>0</order><output-
action><output-node-connector>' + str(outport) +'</output-node-
connector></output-action></action></apply-
actions></instruction></instructions></flow>\''

xmlDstToSrc = '\'<?xml version=\"1.0\" encoding=\"UTF-8\"

standalone=\"no\"?><flow
xmlns=\"urn:opendaylight:flow:inventory\"><priority>32767</priority>
<flow-name>Load Balance 2</flow-name><match><in-port>' +
str(outport) +'</in-port><ipv4-destination>10.0.0.4/32</ipv4-
destination><ipv4-source>10.0.0.1/32</ipv4-source><ethernet-
match><ethernet-type><type>2048</type></ethernet-type></ethernet-
match></match><id>2</id><table_id>0</table_id><instructions><instruc
tion><order>0</order><apply-actions><action><order>0</order><output-

45
action><output-node-connector>' + str(inport) +'</output-node-
connector></output-action></action></apply-
actions></instruction></instructions></flow>\''

flowURL =
"http://127.0.0.1:8181/restconf/config/opendaylight-
inventory:nodes/node/openflow:"+ bestPath[currentNode]
+"/table/0/flow/1"

command = 'curl --user "admin":"admin" -H "Accept:

application/xml" -H "Content-type: application/xml" -X PUT ' +
flowURL + ' -d ' + xmlSrcToDst
systemCommand(command)

flowURL =
"http://127.0.0.1:8181/restconf/config/opendaylight-
inventory:nodes/node/openflow:"+ bestPath[currentNode]
+"/table/0/flow/2"

command = 'curl --user "admin":"admin" -H "Accept:

application/xml" -H "Content-type: application/xml" -X PUT ' +
flowURL + ' -d ' + xmlDstToSrc

systemCommand(command)

srcNode = bestPath[-1]
prevNode = bestPath[-2]
inport = linkPorts[prevNode + "::" + srcNode]
inport = inport.split("::")[1]
outport = hostPorts[h1]

xmlSrcToDst = '\'<?xml version=\"1.0\" encoding=\"UTF-8\"

standalone=\"no\"?><flow
xmlns=\"urn:opendaylight:flow:inventory\"><priority>32767</priority>
<flow-name>Load Balance 1</flow-name><match><in-port>' + str(inport)
+'</in-port><ipv4-destination>10.0.0.1/32</ipv4-destination><ipv4-
source>10.0.0.4/32</ipv4-source><ethernet-match><ethernet-
type><type>2048</type></ethernet-type></ethernet-
match></match><id>1</id><table_id>0</table_id><instructions><instruc
tion><order>0</order><apply-actions><action><order>0</order><output-
action><output-node-connector>' + str(outport) +'</output-node-
connector></output-action></action></apply-
actions></instruction></instructions></flow>\''

46
 xmlDstToSrc = '\'<?xml version=\"1.0\" encoding=\"UTF-8\"
standalone=\"no\"?><flow
xmlns=\"urn:opendaylight:flow:inventory\"><priority>32767</priority>
<flow-name>Load Balance 2</flow-name><match><in-port>' +
str(outport) +'</in-port><ipv4-destination>10.0.0.4/32</ipv4-
destination><ipv4-source>10.0.0.1/32</ipv4-source><ethernet-
match><ethernet-type><type>2048</type></ethernet-type></ethernet-
match></match><id>2</id><table_id>0</table_id><instructions><instruc
tion><order>0</order><apply-actions><action><order>0</order><output-
action><output-node-connector>' + str(inport) +'</output-node-
connector></output-action></action></apply-
actions></instruction></instructions></flow>\''

flowURL = "http://127.0.0.1:8181/restconf/config/opendaylight-
inventory:nodes/node/openflow:"+ bestPath[-1] +"/table/0/flow/1"

command = 'curl --user \"admin\":\"admin\" -H \"Accept:

application/xml\" -H \"Content-type: application/xml\" -X PUT ' +
flowURL + ' -d ' + xmlSrcToDst

systemCommand(command)

flowURL = "http://127.0.0.1:8181/restconf/config/opendaylight-
inventory:nodes/node/openflow:"+ bestPath[-1] +"/table/0/flow/2"
command = 'curl --user "admin":"admin" -H "Accept:
application/xml" -H "Content-type: application/xml" -X PUT ' +
flowURL + ' -d ' + xmlDstToSrc

systemCommand(command)

# Main

# Stores H1 and H2 from user

global h1,h2,h3

h1 = ""
h2 = ""

print "Enter Host 1"

h1 = int(input())
print "\nEnter Host 2"

47
h2 = int(input())
print "\nEnter Host 3 (H2's Neighbour)"
h3 = int(input())

h1 = "10.0.0." + str(h1)
h2 = "10.0.0." + str(h2)
h3 = "10.0.0." + str(h3)

flag = True

while flag:

#Creating Graph
G = nx.Graph()

# Stores Info About H3 And H4's Switch

switch = {}

# MAC of Hosts i.e. IP:MAC

deviceMAC = {}

# IP of Hosts i.e. MAC:IP

deviceIP = {}

# Stores Switch Links To H3 and H4's Switch

switchLinks = {}

# Stores Host Switch Ports

hostPorts = {}

# Stores Switch To Switch Path

path = {}
# Stores Link Ports
linkPorts = {}
# Stores Final Link Rates
finalLinkTX = {}
# Store Port Key For Finding Link Rates
portKey = ""
# Statistics
global stats
stats = ""

48
 # Stores Link Cost
global cost
cost = 0

try:
# Device Info (Switch To Which The Device Is Connected &
The MAC Address Of Each Device)
topology =
"http://127.0.0.1:8181/restconf/operational/network-
topology:network-topology"
getResponse(topology,"topology")

# Print Device:MAC Info

print "\nDevice IP & MAC\n"
print deviceMAC

# Print Switch:Device Mapping

print "\nSwitch:Device Mapping\n"
print switch

# Print Host:Port Mapping

print "\nHost:Port Mapping To Switch\n"
print hostPorts

# Print Switch:Switch Port:Port Mapping

print "\nSwitch:Switch Port:Port Mapping\n"
print linkPorts

# Paths
print "\nAll Paths\n"
#for path in nx.all_simple_paths(G, source=2, target=1):
#print(path)
for path in nx.all_shortest_paths(G,
source=int(switch[h2].split(":",1)[1]),
target=int(switch[h1].split(":",1)[1]), weight=None):
print path

# Cost Computation
tmp = ""

49
 for currentPath in nx.all_shortest_paths(G,
source=int(switch[h2].split(":",1)[1]),
target=int(switch[h1].split(":",1)[1]), weight=None):
for node in range(0,len(currentPath)-1):
tmp = tmp + str(currentPath[node]) + "::"
key = str(currentPath[node])+ "::" +
str(currentPath[node+1])
port = linkPorts[key]
port = port.split(":",1)[0]
port = int(port)
stats =
"http://localhost:8181/restconf/operational/opendaylight-
inventory:nodes/node/openflow:"+str(currentPath[node])+"/node-
connector/openflow:"+str(currentPath[node])+":"+str(port)
getResponse(stats,"statistics")
tmp = tmp + str(currentPath[len(currentPath)-1])
tmp = tmp.strip("::")
finalLinkTX[tmp] = cost
cost = 0
tmp = ""

print "\nFinal Link Cost\n"

print finalLinkTX

shortestPath = min(finalLinkTX, key=finalLinkTX.get)

print "\n\nShortest Path: ",shortestPath

pushFlowRules(shortestPath)

time.sleep(60)
except KeyboardInterrupt:
break
exit

50