File Noi Dung TOAN VAN - Luan Van CH Hoang Van Dung K25

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
HOÀNG VĂN DŨNG
NGHIÊN CỨU, ĐÁNH GIÁ ỨNG DỤNG GIẢI PHÁP SDN

CHO HẠ TẦNG MẠNG TRUYỀN TẢI TRONG CÁC TELCO
CLOUD DATA CENTER
LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN
Hà Nội - 2021
1
ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
HOÀNG VĂN DŨNG
NGHIÊN CỨU, ĐÁNH GIÁ ỨNG DỤNG GIẢI PHÁP SDN

CHO HẠ TẦNG MẠNG TRUYỀN TẢI TRONG CÁC TELCO
CLOUD DATA CENTER
Ngành: Công nghệ thông tin

Chuyên ngành: Hệ thống thông tin
Mã số: 8480104.01
LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN
NGƯỜI HƯỚNG DẪN KHOA HỌC: TS PHẠM MẠNH LINH
Hà Nội - 2021
2
LỜI CẢM ƠN
Lời đầu tiên, tôi xin bày tỏ lòng biết ơn sâu sắc tới Tiến sĩ Phạm Mạnh Linh, đã tận
tình hướng dẫn và chỉ bảo tôi trong suốt quá trình nghiên cứu và thực hiện luận văn tốt
nghiệp.
Tôi xin chân thành cảm ơn các thầy cô trường Đại học Công nghệ - Đại học Quốc
gia Hà Nội đã truyền đạt cho tôi nền tảng kiến thức thức quý báu, tư duy khoa học và
tạo mọi điều kiện thuận lợi trong quá trình học tập, nghiên cứu.
Tôi xin cảm ơn lãnh đạo đơn vị nơi công tác đã tạo điều kiện rất tốt cho tôi hoàn
thành khóa học và luận văn tốt nghiệp. Tôi xin cảm ơn các bạn đồng nghiệp, đặc biệt là
các bạn trong đội dự án đã hỗ trợ rất nhiệt tình, giúp tôi tháo gỡ các vướng mắc khó
khăn trong thời gian tôi xây dựng và hoàn thiện luận văn tốt nghiệp.
Cuối cùng, tôi xin được gửi lời cám ơn tới gia đình và các bạn trong lớp Cao học Hệ
thống thông tin K25 đã luôn bên cạnh, giúp đỡ, động viên tôi trong quá trình học tập
cũng như trong suốt quá trình thực hiện luận văn.
Công trình này được tài trợ từ đề tài KHCN cấp ĐHQGHN, Mã số đề tài: QG.20.55.
Tôi xin chân thành cảm ơn!
Hà Nội, ngày 15 tháng 3 năm 2021
Học viên
Hoàng Văn Dũng

3
LỜI CAM ĐOAN

Tôi xin cam đoan các kết quả nghiên cứu, thực nghiệm được trình bày trong luận
văn này do tôi đề ra và thực hiện dưới sự hướng dẫn của TS. Phạm Mạnh Linh và được
thực hiện trong quá trình hợp tác nghiên cứu giữa Tổng Công ty Mạng lưới Viettel và
các đối tác.
Tất cả những tham khảo từ các nghiên cứu liên quan đều được nêu nguồn gốc một
cách rõ ràng từ danh mục tài liệu tham khảo trong luận văn. Trong luận văn, không có
việc sao chép tài liệu, công trình nghiên cứu của người khác mà không chỉ rõ về tài liệu
tham khảo.
Hà nội, ngày 15 tháng 3 năm 2021.
Học viên
Hoàng Văn Dũng

4
MỤC LỤC
CHƯƠNG 1: TỔNG QUAN ........................................................................................ 15
1.1. Tổng quan về Mạng định nghĩa mềm SDN – Software Defined Networking ... 15
1.2. Sự khác biệt giữa SDN với mạng truyền thống ................................................. 15
1.2.1. Về kiến trúc ..................................................................................................... 16
1.2.2. Về tính năng .................................................................................................... 17
1.3. Tìm hiểu kiến trúc của SDN ............................................................................... 18
1.4. Tiềm năng ứng dụng và xu hướng triển khai ..................................................... 19
1.4.1. Đánh giá tiềm năng ứng dụng ......................................................................... 19
1.4.2. Xu hướng triển khai ........................................................................................ 21
CHƯƠNG 2: NGHIÊN CỨU, THỬ NGHIỆM SDN CỦA CÁC HÃNG VÀ MÃ
NGUỒN MỞ ................................................................................................................ 23
2.1. Nghiên cứu các giải pháp ứng dụng của Nokia và Juniper ................................ 23
2.1.1. Nghiên cứu giải pháp SDN của Nokia – Hệ thống Nuage ............................. 23
2.1.1.1. Các dịch vụ ảo hóa VSD.............................................................................. 24
2.1.1.2. Bộ điều khiển dịch vụ ảo hóa VSC ............................................................. 25
2.1.1.3. Bộ định tuyến, chuyển mạch ảo VRS .......................................................... 26
2.1.1.4. Chính sách bảo mật và chuỗi dịch vụ .......................................................... 27
2.1.2. Giải pháp SDN của Juniper - Contrail ............................................................ 28
2.1.2.1. Kiến trúc Contrail ........................................................................................ 29
2.1.2.2. Contrail SDN controller............................................................................... 30
2.1.2.3. Contrail vRouter .......................................................................................... 32
2.1.2.4. Các giao thức quản lý và điều khiển............................................................ 34
2.1.3. So sánh giải pháp giữa Nuage Nokia và Contrail Juniper .............................. 35
2.2. Nghiên cứu các giải pháp ứng dụng SDN mã nguồn mở ................................... 36
2.2.1. Giải pháp của Tungsten Fabric (TF) ............................................................... 36
2.2.2. Giải pháp của OpenDaylight (ODL) ............................................................... 37
2.2.3. So sánh giải pháp của Tungsten Fabric (TF) và OpenDaylight (ODL) .......... 39
CHƯƠNG 3: TRIỂN KHAI GIẢI PHÁP TỰ PHÁT TRIỂN ..................................... 40
3.1. Mục tiêu triển khai ............................................................................................. 40
3.2. Phạm vi triển khai............................................................................................... 40
3.3. Tổ chức triển khai ............................................................................................... 40
3.3.1. Quy hoạch đấu nối và triển khai lắp đặt thiết bị ............................................. 40
3.3.2. Cài đặt, tích hợp SDN controller .................................................................... 42
5
3.3.2.1. Cài đặt, tích hợp SDN controller ................................................................. 42

3.3.2.2. Công cụ Skydive .......................................................................................... 42
3.3.3. Đồng bộ tài nguyên ......................................................................................... 43
3.3.4. Triển khai cắt chuyển VM sang hạ tầng SDN ................................................ 43
3.4. Kết quả triển khai ............................................................................................... 44
3.4.1. Triển khai hệ thống ......................................................................................... 44
3.4.2. Kiểm tra tính năng, test dịch vụ và đảm bảo điều kiện đổ tải......................... 45
3.4.3. Tích hợp, đổ tải và đánh giá ............................................................................ 45
3.5. Đánh giá hệ thống sau khi tích hợp SDN Controller. ........................................ 45
3.6. Đánh giá tiềm năng ứng dụng ............................................................................ 47
3.7. So sánh các tính năng SDN Opensource với truyền thống ................................ 48
3.8. So sánh các SDN Opensource với sản phẩm thương mại .................................. 49
KẾT LUẬN .................................................................................................................. 51
TÀI LIỆU THAM KHẢO ............................................................................................ 52
PHỤ LỤC 1: Kết quả thử nghiệm tại Lab với giải pháp Tungsten Fabric và Opendaylight
...................................................................................................................................... 53
6
DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT
Ký hiệu/
STT Ý nghĩa
chữ viết tắt
1 ACL Access Control List (Danh sách điều khiển truy nhập)
Application Programming Interface (Giao diện lập trình ứng

2 API
dụng)
3 ARP Address Resolution Protocol (Giao thức phân giải địa chỉ)
4 BGP Border Gateway Protocol (Giao thức định tuyến liên vùng)
5 BSS Business Support System (Hệ thống hỗ trợ kinh doanh)
Compounded Annual Growth Rate (Tốc độ tăng trưởng hằng
6 CAGR
năm kép)
7 CLI Command Line Interface (Giao diện dòng lệnh)
8 CMS Cloud Management System (Hệ thống quản lý đám mây)
Communication Service Provider (Các nhà cung cấp dịch vụ
9 CSP
truyền thông)
Dynamic Host Configuration Protocol (Giao thức cấu hình
10 DHCP
máy chủ động)
11 DPI Deep Packet Inspection (Kiểm tra chuyên sâu gói tin)
Forwarding Information Base (Cơ sở thông tin chuyển

12 FIB
tiếp/Bảng thông tin chuyển tiếp)
13 GUI Graphical User Interface (Giao diện đồ họa người dùng)
Interface for Metadata Access Points (Giao diện cho các điểm
15 IF-MAP
truy cập siêu dữ liệu)
16 IP Internet Protocol (Giao thức Internet)

Intrusion Prevention System (Hệ thống phòng chống xâm
17 IPS
nhập)
Kernel-based Virtual Machine (Công nghệ ảo hóa phần cứng
18 KVM
trên mã nguồn mở tích hợp trong Linux)
19 MAC Media Access Control (Địa chỉ vật lý)
20 MDNS Multicast Domain Name System (Quảng bá tên miền)
Multiprotocol Label Switching (Chuyển mạch nhãn đa giao

21 MPLS
thức)
7
Ký hiệu/
STT Ý nghĩa
chữ viết tắt
MPLS over Generic Routing Encapsulation (Giao thức đóng
22 MPLSoGRE
gói nhiều loại giao thức lớp network)
23 NETCONF Network Configuration Protocol (Giao thức cấu hình mạng)
Network functions virtualization (Công nghệ ảo hóa chức

24 NFV
năng mạng)
Network Functions Virtualization Infrastructure (Hạ tầng ảo
25 NFVI
hóa chức năng mạng)
26 NGINX Máy chủ web kiến trúc đơn luồng, hướng sự kiện
Open Networking Foundation (Tổ chức phát triển SDN thông
27 ONF
qua việc nghiên cứu các tiêu chuẩn mở)
28 ONOS Open Network Operating System (Hệ điều hành mạng mở
Open Platform for NFV (Nền tảng mã nguồn mở cho Công
29 OPNFV
nghệ ảo hóa chức năng mạng)
30 OSS Operations Support System (Hệ thống hỗ trợ vận hành mạng)
31 OVA Open Virtualization Format (Định dạng ảo hóa mở)
32 OVS Open vSwitch (Chuyển mạch ảo)
Open vSwitch Database Management Protocol (Giao thức
33 OVSDB
quản lý cơ sở dữ liệu bộ chuyển mạch ảo)
34 QoS Quality of Service (Chất lượng dịch vụ)

Ứng dụng sử dụng kiến trúc REST (REpresentational State
35 RESTful Transfer - Chuyển trạng thái đại diện) là một chuẩn thiết kế
API cho Web services
Software Defined Networking (Mạng điều khiển bằng phần
36 SDN
mềm)
Service Routing Operation System (Hệ điều hành định tuyến
37 SROS
dịch vụ)
Transmission Control Protocol/ Internet Protocol - Giao thức
38 TCP/IP
điều khiển truyền nhận/ Giao thức liên mạng
User Diagram Protocol (Giao thức truyền gói dữ liệu người
39 UDP
dùng)
40 UI User Interface (Giao diện người dùng)
41 VLAN Virtual Local Area Network (Mạng LAN ảo)

42 VM Virtual Machine (Máy ảo)
43 VNI Virtual Network Identifier (Định danh mạng ảo)
8
Ký hiệu/
STT Ý nghĩa
chữ viết tắt
44 VPLS Virtual Private LAN Service (Dịch vụ mạng LAN riêng ảo)
45 vPort Virtual Ports (Cổng giao tiếp ảo)
Virtual Routing and Switching (Chuyển mạch và định tuyến
46 VRS
ảo)
47 VSC Virtualized Services Controller (Bộ điều khiển dịch vụ ảo)
Nuage Virtualized Services Directory (Thư mục dịch vụ ảo
48 VSD
của Nuage)
49 VSG Virtualized Services Gateway (Cổng dịch vụ ảo)
50 VSN Virtualized Services Node (Node dịch vụ ảo)

51 VSP Virtualized Services Platform (Nền tảng dịch vụ ảo hóa)
VXLAN Tunnel endpoint (Điểm đầu/cuối của VXLAN
52 VTEP
tunnel)
53 VXLAN Virtual Extensible LAN
Extensible Messaging and Presence Protocol (Giao thức mở

54 XMPP
và dựa trên nền tảng XML dùng trong nhắn tin nhanh)
9
DANH MỤC CÁC BẢNG

Bảng 2.1 - So sánh giải pháp giữa Nokia và Juniper..................................................... 36
Bảng 3.1 - Quy hoạch đấu nối ....................................................................................... 41
Bảng 3.2 - Đánh giá hệ thống trước và sau khi tích hợp SDN ......................................46
Bảng 3.3 - Đánh giá tính năng giải pháp SDN mã nguồn mở tự phát triển ..................49
10
DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ
Hình 1.1 - So sánh kiến trúc mạng truyền thống và SDN .............................................16
Hình 1.2 - Kiến trúc SDN .............................................................................................. 18
Hình 1.3 - Lớp điều khiển SDN .................................................................................... 19
Hình 1.4 - Biểu đồ Hype Cycle cho vận hành cung cấp dịch vụ truyền thông 2019 ....20
Hình 1.5 - Dự báo quy mô thị trường SDN 2019-2025 ................................................21
Hình 2.1 - Kiến trúc hệ thống Nuage Nokia..................................................................23
Hình 2.2 - Các dịch vụ ảo hóa VSD ..............................................................................24
Hình 2.3 – Bộ điều khiển dịch vụ ảo hóa VSC ............................................................. 26
Hình 2.4 – Bộ định tuyến và chuyển mạch ảo............................................................... 26
Hình 2.5 – Cơ chế làm việc chính sách bảo mật ........................................................... 28
Hình 2.6 – Kiến trúc Contrail - Juniper .........................................................................29
Hình 2.7 – Contrail SDN controller ..............................................................................30
Hình 2.8 - Analytics Node ............................................................................................. 31
Hình 2.9 - Configuration Node ...................................................................................... 31
Hình 2.10 – Control Node ............................................................................................. 32
Hình 2.11 – Computer Node ......................................................................................... 33
Hình 2.12 - Kiến trúc OpenDayLight ............................................................................38
Hình 3.1 - Sơ đồ lắp đặt .................................................................................................41
Hình 3.2 - Mô hình cắt chuyển ...................................................................................... 42
Hình 3.3 – Các bước cắt chuyển.................................................................................... 44
Hình 3.4 - Giám sát bằng công cụ Skydive ...................................................................45
Hình 3.5- Sơ đồ kiến trúc tổng thể của hệ thống dịch vụ phân tích cảnh báo lan truyền
dịch bệnh trên đàn gia súc ............................................................................................. 47
11
MỞ ĐẦU
Trên thế giới, SDN đang là xu hướng công nghệ quan trọng mà tất cả các Tier 1
Operator theo đuổi (Gartner một công ty tư vấn công nghệ hàng đầu thế giới đã chỉ ra
rằng trong 05 năm nữa SDN sẽ chín muồi) [1]. Một trong những môi trường thuận lợi
và dễ triển khai SDN nhất là các Cloud Data Center. Hiện nay, các nhà cung cấp nội
dung lớn như Google, Facebook, Amazon đã ứng dụng triển khai SDN vào trong các
Data Center. Các Tier 1 Operator cũng đã từng bước đưa SDN vào Data Center và thực
hiện ảo hóa các thành phần điều khiển, như AT&T đưa ra mục tiêu ảo hóa được 75%
các phần tử trong mạng vào năm 2020.
Global Market Insights dự báo quy mô thị trường SDN được dự báo lên đến 100 tỷ
USD vào năm 2025 và ước tính sẽ tăng trưởng với tốc độ tăng trưởng kép hàng năm
(CAGR) hơn 40% trong khoảng thời gian dự báo 2019-2025 [6].
Nhìn chung, các nhà cung cấp dịch vụ truyền thông (CSP) hàng đầu trên thế giới đã
đưa vào triển khai SDN trong những năm gần đây. Các thiết bị chuyển mạch hộp trắng
(white-box switches) được lựa chọn bởi chúng có thể được lập trình để linh hoạt sử dụng
các giao thức khác nhau, như OpenFlow hoặc các biến thể khác của southbound API để
tạo các kết nối định tuyến. Các CSP triển khai SDN trong các phân đoạn khác nhau trên
cơ sở hạ tầng của họ tùy thuộc vào các mong muốn triển khai tập trung vào tự động hóa
hoạt động của các phân đoạn này. Tuy nhiên, nhiều CSP vẫn đang theo dõi sự phát triển
SDN, dự kiến sẽ mất nhiều năm trước khi triển khai SDN với quy mô lớn. Một số nhà
cung cấp sản phẩm đã được hình thành và một số nhà cung cấp mới nổi tiếp tục phát
triển công nghệ SDN. Cũng có một số cộng đồng mã nguồn mở phát triển phần mềm
SDN theo cách riêng của họ. Việc thiếu các tiêu chuẩn chung, các vấn đề về khả năng
tương tác đa tầng, các tính năng kiểm soát dịch vụ không đầy đủ, quá tập trung các chức
năng kiểm soát và dẫn đến sự thiếu hiệu quả với lưu lượng kiểm soát và những lo ngại
về việc tuân thủ và bảo mật của các bộ điều khiển SDN tập trung là những rào cản lớn
đối với việc áp dụng SDN quy mô lớn. Bất chấp những rào cản này, các dịch vụ truyền
thông đang tiến lên với việc triển khai SDN vì lợi ích của SDN vượt xa các vấn đề tiềm
ẩn nói trên.
Việc nghiên cứu, ứng dụng công nghệ mới nói chung và nhất là các công nghệ liên
quan đến tự động hóa, thông minh hạ tầng mạng truyền tải viễn thông và CNTT nói
riêng luôn là thách thức mà đội ngũ kỹ thuật Viettel luôn nỗ lực vượt qua để bắt kịp xu
hướng phát triển và tiến tới làm chủ công nghệ mới. SDN là một trong những ứng dụng
phổ biến đối với mạng truyền tải hiện nay mà các nhà cung cấp dịch vụ viễn thông định
hướng triển khai, với việc phân tách phần điều khiển mạng (Control Plane) và chức năng
vận chuyển dữ liệu (Forwarding Plane/Data Plane), SDN cho phép việc điều khiển mạng
có thể lập trình được dễ dàng và cơ sở hạ tầng mạng độc lập với các ứng dụng và dịch
vụ mạng. Đây là hệ thống quan trọng mà đội ngũ kỹ thuật Viettel đã nghiên cứu, ứng
dụng trên cơ sở hợp tác với các nhà cung cấp Nokia và Juniper và định hướng tự phát
12
triển nền tảng mã nguồn mở để triển khai cho hạ tầng mạng truyền tải trong các Telco
Cloud Data center và mạng Metro trong tương lai gần.
Bản thân là một trong những thành viên tham gia dự án nghiên cứu ứng dụng SDN
vào mạng lưới Viettel, tôi xin giới thiệu đề tài: " NGHIÊN CỨU, ĐÁNH GIÁ ỨNG
DỤNG GIẢI PHÁP SDN CHO HẠ TẦNG MẠNG TRUYỀN TẢI TRONG CÁC
TELCO CLOUD DATA CENTER". Với mong muốn hiểu được cơ chế hoạt động của
mạng điều khiển bằng phần mềm và bản thân có thể triển khai thiết lập được hệ thống
khi đưa vào mạng thật, tôi đã đặt mục tiêu nghiên cứu các nội dung sau đây:
Tổng quan về vấn đề nghiên cứu:
 Tìm hiểu kiến trúc, hiệu quả lợi ích giải pháp ứng dụng SDN đối với mạng truyền
tải trong các Telco Cloud Data Center, làm rõ cơ chế phân tách phần điều khiển
mạng và chức năng vận chuyển dữ liệu của hệ thống, các công nghệ, giao thức hoạt
động trong quá trình vận hành của hệ thống trên hạ tầng mạng truyền tải, các
ưu/nhược điểm giải pháp ứng dụng của các hãng/phát triển từ mã nguồn mở.
 Tổ chức triển khai thử nghiệm, đánh giá so sánh giải pháp của các nhà cung cấp/mã
nguồn mở khác nhau để định hướng lựa chọn giải pháp phù hợp và phương án kỹ
thuật phục vụ lộ trình ứng dụng trên mạng truyền tải.
Mục đích nghiên cứu: Tìm hiểu khả năng ứng dụng giải pháp SDN cho mạng truyền
tải, đánh giá các tính năng giải pháp SDN (Feature test) cung cấp cho Cloud Data Center,
khả năng làm việc liên mạng (interworking) với Cloud ecosystem (Open Stack, servers,
storage, hypervisors, …) và các thiết bị IP thông qua giải pháp overlay.
Đối tượng nghiên cứu:
 Giải pháp SDN của các hãng Nokia và Juniper.
 Giải pháp SDN mã nguồn mở Tungsten Fabric và OpenDayLight.
 Ứng dụng giải pháp trên mạng truyền tải trong các Telco Cloud Data Center.
Phạm vi nghiên cứu:
 Tổng quan về SDN.
 Giải pháp SDN của Nokia và Juniper, giải pháp SDN mã nguồn mở Tungsten
Fabric và OpenDayLight.
 Triển khai thử nghiệm: Thiết kế hệ thống, xây dựng kịch bản thử nghiệm, tổ chức triển
khai lắp đặt, tích hợp, cấu hình hệ thống và đánh giá tính năng, độ ổn định, khả năng
làm việc interworking với nhiều phần cứng khác nhau để đề xuất lộ trình ứng dụng trên
mạng lưới.
Phương pháp nghiên cứu:
 Nghiên cứu lý thuyết về SDN cho mạng truyền tải trong các Telco Cloud Data
Center với mục tiêu là hiểu được nền tảng cơ bản.
 Nghiên cứu giải pháp SDN của Nokia và Juniper với mục tiêu là hiểu và triển khai
được công nghệ.
13
 Nghiên cứu giải pháp SDN mã nguồn mở Tungsten Fabric và OpenDayLight với
mục tiêu là hiểu và triển khai được công nghệ.
 Tổng hợp, so sánh, đánh giá, đưa ra nhận định, đề xuất lộ trình ứng dụng.
 Tìm hiểu về các phần tử liên quan trên mạng lưới (thiết bị, ứng dụng trên mạng
truyền tải hiện tại) với mục tiêu lựa chọn các testcase, đánh giá, lựa chọn giải pháp
kỹ thuật tối ưu phù hợp.
Phương pháp thực nghiệm: Xây dựng lab thử nghiệm trên nền tảng do đối tác cung
cấp/tự phát triển và thiết bị hiện có phục vụ cho việc đánh giá các testcase theo mục tiêu
kịch bản đã xây dựng.
Vai trò tác giả trong dự án nghiên cứu, thực nghiệm tại đơn vị:
 Chủ trì tổ chức nghiên cứu, lựa chọn giải pháp thử nghiệm giai đoạn 1 (nghiên cứu
xu thế, tiềm năng của giải pháp; test thử nghiệm giải pháp của các hãng và giải
pháp mã nguồn mở).
 Tổ chức thiết lập, cấu hình, tích hợp Lab thử nghiệm; tham gia test thử nghiệm và
nghiệm thu giải pháp tự phát triển.
Với các mục tiêu xác định cụ thể như trên, kết quả của luận văn dự kiến sẽ đưa ra
được lựa chọn giải pháp ứng dụng phù hợp cho mạng truyền tải trong các Telco Cloud
Data Center và lộ trình triển khai trên mạng thật cũng như định hướng xây dựng nền
tảng tự phát triển trong tương lai.
Luận văn được cấu trúc như sau:
CHƯƠNG 1: TỔNG QUAN.
Chương này trình bày các khái niệm cơ bản về SDN, so sánh khác biệt giữa SDN và
công nghệ mạng truyền thống về cấu trúc và tính năng. Tìm hiểu kiến trúc của giải pháp
ứng dụng SDN cũng như tiềm năng và xu hướng triển khai của các nhà mạng trên thế
giới.
CHƯƠNG 2: THỬ NGHIỆM GIẢI PHÁP SDN CỦA CÁC HÃNG VÀ MÃ
NGUỒN MỞ
Chương 2 được trình bày qua 2 phần. Phần thứ nhất giới thiệu các giải pháp ứng
dụng SDN của Nokia và Juniper cho mạng truyền tải trong các Telco Cloud Data Center.
Phần thứ hai trình bày về nội dung nghiên cứu và kết quả thử nghiệm trên Lab giải pháp
mã nguồn mở Tungsten Fabric và OpenDayLight cũng như so sánh, phân tích đánh giá
tính ứng dụng phù hợp của 2 giải pháp này.
CHƯƠNG 3: TRIỂN KHAI GIẢI PHÁP TỰ PHÁT TRIỂN
Chương 3 là chương chuyển thể các kiến thức nghiên cứu, test thử nghiệm trên lab
và giải pháp tự phát triển hệ thống SDN Opensource thành nội dung ứng dụng thực tế
trên mạng thật. Chương này đưa ra thực nghiệm tích hợp giải pháp tự phát triển vào hệ
thống Private Cloud DC.
Tuy nhiên, để kết quả thực nghiệm là một giải pháp ứng dụng hiệu quả trên diện
rộng trong mạng truyền tải của Viettel, ngoài việc tối ưu lại hệ thống thì còn phải phát
14
triển bổ sung các tính năng nâng cao nhằm đáp ứng nhu cầu không chỉ cho mạng truyền
tải Telco Cloud Data Center mà còn đối với mạng truyền tải IP.
Trên đây là giới thiệu cơ bản nội dung về luận văn tốt nghiệp của bản thân. Nội dung
thực hiện chỉ mới là quan điểm và tư duy cá nhân, sẽ còn nhiều tồn tại và thiết sót. Do
vậy, rất mong quý thầy cô, bạn học và nhất là các thầy cô giáo trong hội đồng bảo vệ tốt
nghiệp cho ý kiến đóng góp để luận văn được hoàn thiện. Kết quả luận văn là kết quả
triển khai dự án thực tế tại Viettel mà bản thân tác giả là một thành viên của đội dự án.
15
CHƯƠNG 1: TỔNG QUAN

1.1. Tổng quan về Mạng định nghĩa mềm SDN – Software Defined Networking
1.1.1. Nhu cầu và nguyên nhân ra đời
Mạng định nghĩa bằng phần mềm (SDN) là một công nghệ mới giúp nâng cao hiệu
quả và giảm chi phí cho việc vận hành và quản trị hệ thống mạng cho các tổ chức doanh
nghiệp.
Đối với một kiến trúc mạng truyền thống, mặt phẳng dữ liệu và mặt phẳng điều khiển
đều cùng nằm trên một thiết bị vật lý và mỗi thiết bị độc lập về mặt chức năng với nhau,
các chính sách chuyển tiếp lưu lượng hoạt động trên trên mỗi thiết bị riêng và không có
giao diện có khả năng hiển thị toàn bộ mạng.
Khi số lượng thiết bị trên mạng lưới càng nhiều, thì càng gây nên sự phức tạp trong
mạng và làm khó khăn cho người quản trị mạng trong quá trình vận hành và điều khiển.
Cùng với các thay đổi về mô hình mạng, sự gia tăng của các dịch vụ đám mây và nhu
cầu phát triển của các nhà khai thác băng thông dịch vụ đưa ra một yêu cầu cần phải
phát triển một giải pháp mới.
Các nhà nghiên cứu đã phát triển một kiến trúc mạng mà ở đó nhiệm vụ điều khiển
mạng được xử lý bởi các bộ điều khiển và các bộ điều khiển đó có thể tác động tới phần
cứng, bộ nhớ và các chức năng của các thiết bị định tuyến (router), chuyển mạch (switch)
để đạt được mục đích của người sử dụng. Do đó, mạng lưới trở nên linh hoạt hơn, hiệu
suất sử dụng cao hơn và dễ quản lý hơn.
1.1.2. Khái niệm về mạng SDN
Trên thế giới hiện có nhiều định nghĩa về mạng SDN nhưng theo tổ chức ONF (Open
Networking Foundation – một tổ chức hỗ trợ phát triển SDN thông qua việc nghiên cứu
các tiêu chuẩn mở phù hợp) thì mạng định nghĩa bằng phần mềm (SDN) là một kiểu
kiến trúc mạng mới, năng động, dễ quản lý, chi phí hiệu quả, dễ thích nghi và rất phù
hợp với nhu cầu mạng ngày càng tăng hiện nay. Kiến trúc này phân tách chức năng điều
khiển mạng (Control Plane) và chức năng vận chuyển dữ liệu (Forwarding Plane/Data
Plane), điều này cho phép việc điều khiển mạng có thể lập trình được dễ dàng và hạ tầng
mạng vật lý độc lập với các ứng dụng và dịch vụ mạng.
Một cách định nghĩa khác theo quan điểm của chuyên gia phân tích Ramesh
Marimuthu và Amresh Nandan (Gartner): Mạng được định nghĩa bằng phần mềm (SDN)
là một cách tiếp cận kiến trúc để thiết kế, xây dựng và vận hành mạng và cho phép khả
năng lập trình của các phần tử mạng. Do đó, các nhà cung cấp dịch vụ có thể đạt được
sự linh hoạt và tăng trưởng kinh doanh thông qua các sản phẩm dịch vụ mới với thời
gian nhanh hơn để tiếp thị cùng với các hoạt động tự động và hiệu quả về chi phí. SDN
tách mặt phẳng điều khiển khỏi mặt phẳng chuyển tiếp, sự tách biệt này cho phép khả
năng lập trình các chức năng điều khiển mạng độc lập với hạ tầng bên dưới [1].
1.2. Sự khác biệt giữa SDN với mạng truyền thống
16
Để hiểu rõ sự khác biệt giữa SDN và mạng truyền thống, chúng ta sẽ xem xét trên 2
khía cạnh: kiến trúc và tính năng của chúng.
1.2.1. Về kiến trúc
Đối với hệ thống mạng truyền thống, các thiết bị mạng lớp 2 và lớp 3 phải đảm nhận
nhiều chức năng để đảm bảo hoạt động, ví dụ các chức năng của Layer switch hiện nay
như VLAN, Spanning tree, Quality of Service, Security… và đa số các thiết bị mạng và
các giao thức này hoạt động độc lập với nhau vì mỗi nhà sản xuất thiết bị cung cấp các
giải pháp mạng khác nhau. Điều này tạo ra sự phân mảnh đối với toàn bộ hệ thống mạng
đồng thời làm giảm hiệu năng hoạt động.
Đối với mạng điều khiển bằng phần mềm SDN, việc điều khiển được tập trung tại
lớp Controller Layer, các thiết bị mạng chỉ có nhiệm vụ chuyển tiếp gói tin do đó sự
khác biệt giữa các nhà sản xuất sẽ không ảnh hưởng tới toàn hệ thống mạng. Điều này
tương tự như sự phát triển của máy tính hiện nay, mỗi máy tính được sản xuất và cung
cấp bởi các hãng khác nhau (như Dell, HP, IBM, Apple, Google...) và chạy các hệ điều
hành khác nhau (như Windows, MacOS, Linux, Unix, …) nhưng đều có khả năng truy
cập và sử dụng internet dựa trên giao thức mạng TCP/IP [2].
Về phía người quản trị mạng, họ không cần trực tiếp làm việc tại các thiết bị mạng để
cấu hình, tích hợp vào hệ thống mà chỉ cần thông qua các API đã được cung cấp cùng
với kiến thức cơ bản về TCP/IP đều có thể xây dựng ứng dụng cho toàn hệ thống
mạng. Với khả năng quản lý tập trung, SDN mang lại nhiều lợi ích tuy nhiên cũng mở
ra nhiều nguy cơ về bảo mật hơn so với hệ thống mạng truyền thống.
Có thể thấy sự khác biệt cơ bản (Hình 1.1) giữa mạng truyền thống và mạng SDN cụ
thể qua 3 điểm sau:
Hình 1.1 - So sánh kiến trúc mạng truyền thống và SDN

17
 Chức năng điều khiển và chức năng chuyển tiếp dữ liệu trên mạng truyền thống đều
được tích hợp trong cùng một thiết bị mạng trong khi trong mạng SDN, phần điều
khiển được tách riêng khỏi thiết bị mạng và được chuyển đến một thiết bị được gọi
là bộ điều khiển SDN.
 Chức năng thu thập và xử lý các thông tin: Đối với mạng truyền thống, chức năng
này được thực hiện ở tất cả các phần tử trong mạng còn trong mạng SDN, nó được
xử lý tập trung tại bộ điều khiển SDN.
 Mạng truyền thống không thể được lập trình bởi các ứng dụng. Việc cấu hình các
thiết bị mạng được thực hiện một cách riêng lẻ và thủ công. Trong khi đối với SDN,
mạng sẽ được lập trình bởi các ứng dụng, bộ điều khiển SDN có thể tương tác đến
tất cả các thiết bị trong mạng.
Phần điều khiển được tách rời và được tập trung ở bộ điều khiển SDN. Điều này có
nghĩa là các thiết bị mạng ở lớp thiết bị phần cứng không cần phải hiểu và xử lý các giao
thức phức tạp mà chúng chỉ nhận và vận chuyển dữ liệu theo một đường nào đó dưới sự
chỉ huy của bộ điều khiển SDN. Dựa vào bộ điều khiển SDN mà các nhà khai thác và
quản trị mạng có thể lập trình cấu hình trên đó thay vì phải thực hiện thủ công hàng ngàn
câu lệnh cấu hình trên các thiết bị riêng lẻ. Điều này giúp triển khai các ứng dụng mới
và các dịch vụ mạng một cách nhanh chóng.
1.2.2. Về tính năng
Sự khác biệt căn bản nhất giữa SDN và mạng truyền thống là SDN dựa trên phần
mềm trong khi mạng truyền thống thường dựa trên phần cứng. Do dựa trên phần mềm,
SDN linh hoạt hơn, cho phép người dùng kiểm soát tốt hơn và dễ dàng quản lý tài nguyên
hầu như trên chỉ trên mặt phẳng điều khiển. Ngược lại, các mạng truyền thống sử dụng
các bộ chuyển mạch, bộ định tuyến và cơ sở hạ tầng vật lý khác để tạo kết nối và giao
tiếp trên mạng [3].
Bộ điều khiển SDN sử dụng giao diện giao tiếp với các API. Với giao diện này, các
nhà phát triển ứng dụng có thể lập trình trực tiếp mạng, trái ngược với việc sử dụng các
giao thức được yêu cầu bởi mạng truyền thống.
SDN cho phép người dùng sử dụng phần mềm để cung cấp các thiết bị mới thay vì
sử dụng cơ sở hạ tầng vật lý, do đó, quản trị viên có thể định tuyến đường truyền, lưu
lượng cũng như chủ động lập lịch cho các dịch vụ mạng. Không giống như các thiết bị
chuyển mạch truyền thống, SDN còn có khả năng giao tiếp tốt hơn với các thiết bị sử
dụng mạng.
Ảo hóa là điển hình cho sự khác biệt chính giữa SDN và mạng truyền thống. Khi
SDN ảo hóa toàn bộ mạng, nó sẽ tạo một bản sao của mạng vật lý và cho phép cung cấp
tài nguyên từ một vị trí tập trung. Ngược lại, với một mạng truyền thống, vị trí vật lý
của mặt phẳng điều khiển (nằm phân tán trên các thiết bị mạng) sẽ cản trở khả năng
quản trị viên có thể kiểm soát luồng lưu lượng.
18
Với SDN, mặt phẳng điều khiển được xây dựng dựa trên phần mềm, cho phép truy
cập thông qua một thiết bị được kết nối. Quyền truy cập này cho phép quản trị viên quản
lý lưu lượng từ giao diện người dùng tập trung (UI) với độ chi tiết và chính xác cao. Vị
trí tập trung này cho phép người dùng kiểm soát tốt hơn cách thức hoạt động của mạng
và cách cấu hình mạng. Khả năng xử lý nhanh các cấu hình mạng khác nhau từ giao
diện người dùng tập trung đặc biệt có lợi thế trong việc phân tách và quản lý các node
mạng.
SDN trở thành một giải pháp thay thế phổ biến cho mạng truyền thống vì nó cho
phép các quản trị viên quản lý tập trung và cung cấp tài nguyên, băng thông khi cần mà
không cần đầu tư thêm cơ sở hạ tầng vật lý. Mạng truyền thống đòi hỏi phần cứng mới
để tăng dung lượng mạng. Mô hình cho SDN so với kết nối mạng truyền thống có thể
tóm tắt đơn giản như việc với một cái thì yêu cầu nhiều thiết bị hơn để mở rộng và cái
còn lại chỉ cần gõ phím và thao tác trên một màn hình!
1.3. Tìm hiểu kiến trúc của SDN
Về cơ bản, SDN được chia làm ba lớp: lớp ứng dụng (Application Layer), lớp điều
khiển (Control Layer) và lớp thiết bị hạ tầng (Infrastructure Layer). Các lớp sẽ liên kết
với nhau thông qua giao thức hoặc các API (Hình 1.2).
Hình 1.2 - Kiến trúc SDN

Lớp ứng dụng SDN là các chương trình giao tiếp với bộ điều khiển SDN thông qua
các giao diện lập trình ứng dụng API, cho phép lớp ứng dụng lập trình (cấu hình) mạng
(ví dụ như điều chỉnh các tham số trễ, băng thông, định tuyến, …) qua lớp điều khiển
để tối ưu hoạt động của mạng lưới theo một yêu cầu cụ thể của người quản trị. Ngoài ra,
các ứng dụng sẽ đưa ra mô hình trực quan về mạng lưới bằng cách thu thập thông tin từ
bộ điều khiển cho các mục đích ra quyết định. Các ứng dụng này có thể bao gồm quản
lý mạng, phân tích hoặc các ứng dụng kinh doanh được sử dụng để chạy các trung tâm
19
dữ liệu lớn. Ví dụ: Một ứng dụng phân tích có thể được xây dựng để nhận ra hoạt động
mạng đáng ngờ vì mục đích bảo mật.
Lớp thiết bị hạ tầng (Infrastructure Layer) bao gồm các thiết bị mạng (thiết bị vật lý
hoặc ảo hóa) thực hiện việc chuyển tiếp gói tin dưới sự điều khiển của Lớp điểu khiển.
Một thiết bị mạng có thể hoạt động theo sự điều khiển của nhiều controller khác nhau,
điều này giúp tăng cường khả năng ảo hóa của mạng.
Lớp điều khiển là trung tâm của kiến trúc mạng SDN. Nó cung cấp cho người quản
trị tổng quát về toàn mạng, quyết định triển khai các chính sách và điều khiển toàn bộ
các thiết bị trong hạ tầng mạng. Nó cung cấp một giao diện Northbound API cho việc
giao tiếp với lớp ứng dụng. Thực hiện các chính sách quyết định liên quan tới định tuyến,
chuyển tiếp, redirect, cân bằng tải, hoặc tương tự (Hình 1.3).
Hình 1.3 - Lớp điều khiển SDN

 Bên trong SDN controller chưa các module giúp quản lý topo mạng, quản lý trạng
thái, quản lý các thiết bị, quản lý các cảnh báo, tính toán đường đi ngắn nhất và cung
cấp các kỹ thuật bảo mật.
 SDN controller sử dụng giao điện Southbound để giao tiếp với các thiết bị lớp hạ
tầng. Các giao thức phổ biến là Openflow, OVSDB, ForCES, OF-Config... Thông
qua các giao thức này SDN controller có thể cấu hình và thu thập các thông tin trạng
thái trên thiết bị.
 Nền tảng SDN có thể sử dụng để triển khai trên nhiều mô hình khác nhau như trong
các Data center, Lan, Wan, Telecom, Enterprise…
1.4. Tiềm năng ứng dụng và xu hướng triển khai
1.4.1. Đánh giá tiềm năng ứng dụng
Chúng ta sẽ phân tích tiềm năng của SDN trong tương lai bằng việc phân tích biểu
đồ Hype Cycle của Gartner – một công ty nghiên cứu và tư vấn công nghệ thông tin
hàng đầu thế giới.
Theo nghiên cứu của Gartner [1] SDN hiện tại đang trong quá trình thứ 2 – Đỉnh kỳ
vọng (Peak of Inflated Expectations) với việc giới truyền thông đưa tin về một số sản
phẩm ứng dụng SDN thành công và thất bại của các nhà cung cấp dịch vụ, các Tier 1
Operator đã đưa ra các hành động, còn hầu hết thì không hoặc chỉ đang trong giai đoạn
nghiên cứu, tìm hiểu để triển khai thử nghiệm. Phần lớn các nhà cung cấp dịch vụ vẫn
đang thận trọng tìm hướng tiếp cận phù hợp, chiêu mộ nhân tài và lên kế hoạch đầu tư
trong tương lai (Hình 1.4).
20
Hình 1.4 - Biểu đồ Hype Cycle cho vận hành cung cấp dịch vụ truyền thông 2019
Các nhà cung cấp dịch vụ truyền thông (CSP) hàng đầu đã triển khai SDN trong
những năm gần đây. Các thiết bị chuyển mạch hộp trắng (white-box switches) thường
được sử dụng trong triển khai SDN, chúng có thể được lập trình để sử dụng các giao
thức khác nhau, như OpenFlow hoặc các biến thể khác của southbound API để tạo các
kết nối định tuyến. Các CSP triển khai SDN trong các phân đoạn khác nhau trên cơ sở
hạ tầng của họ tùy thuộc vào các mong muốn triển khai tập trung vào tự động hóa hoạt
động của các phân đoạn này. Tuy nhiên, nhiều CSP vẫn đang theo dõi sự phát triển SDN
và dự kiến sẽ mất nhiều năm trước khi triển khai SDN với quy mô lớn. Một số nhà cung
cấp sản phẩm được hình thành và một số nhà cung cấp mới nổi tiếp tục phát triển công
nghệ SDN. Cũng có một số cộng đồng mã nguồn mở phát triển phần mềm SDN theo
cách riêng của họ. Việc thiếu các tiêu chuẩn chung, các vấn đề về khả năng tương tác
đa tầng, các tính năng kiểm soát dịch vụ không đầy đủ, quá tập trung các chức năng
kiểm soát và dẫn đến sự thiếu hiệu quả với lưu lượng kiểm soát và những lo ngại về việc
tuân thủ và bảo mật của các bộ điều khiển SDN tập trung là những rào cản lớn đối với
việc áp dụng SDN quy mô lớn. Bất chấp những rào cản này, các dịch vụ truyền thông
đang tiến lên với việc triển khai SDN vì lợi ích của SDN vượt xa các vấn đề tiềm ẩn nói
trên.
Theo khuyến nghị của Gartner, lãnh đạo đơn vị kinh doanh công nghệ không nên bị
cuốn vào sự cường điệu xung quanh SDN. Nhưng đồng thời, họ không nên bỏ qua công
nghệ đột phá này bởi nó có thể biến đổi hoàn toàn kiến trúc mạng lưới trong tương lai.
CSP nên tập trung giải quyết các vấn đề cụ thể bằng công nghệ SDN. Trong ngắn hạn,
21
các CSP nên có được kinh nghiệm với các công nghệ và phương pháp tiếp cận mới đối
với thiết kế và vận hành mạng bằng cách triển khai nó trong các lĩnh vực không quan
trọng. Điều quan trọng đối với các CSP là phân bổ thời gian và nguồn lực để đánh giá
SDN và các công nghệ liên quan khác như các kiến trúc mạng tự động mã nguồn mở,
chuyển mạch phân tán, các hệ điều hành mạng mã nguồn mở và các nhà cung cấp hiện
tại. Những cách tiếp cận mới này có thể có tác động cơ bản đến các mối quan hệ của
nhà cung cấp và mô hình kinh doanh trong mạng lưới và các thị trường liên quan. Khi
các CSP xây dựng các trung tâm dữ liệu thế hệ tiếp theo của họ để hỗ trợ ảo hóa các
chức năng mạng, họ nên đánh giá công nghệ SDN về khả năng ứng dụng trong các trung
tâm dữ liệu mới. CSP cũng nên đánh giá công nghệ SDN trong quá trình xây dựng mạng
thế hệ tiếp theo của họ. CSP có cơ hội triển khai SDN trong việc triển khai mạng 5G,
mạng dành riêng cho IoT và mạng 4G tiên tiến. CSP cũng có thể triển khai công nghệ
SDN trong mạng truyền tải cáp quang thế hệ tiếp theo của họ bằng các giải pháp SDN
truyền tải. Một mạng lưới truyền tải cáp quang mới là cần thiết để hỗ trợ các nhu cầu
backhaul/front-haul để triển khai các hệ thống điều khiển lưu lượng LTE, 5G, Edge, IoT
và drone tiên tiến. CSP đã triển khai các sản phẩm và dịch vụ SD-WAN sử dụng một số
khái niệm công nghệ SDN.
1.4.2. Xu hướng triển khai
Trên thực tế, SDN đang là xu hướng công nghệ quan trọng mà tất cả các Tier 1
Operator đang theo đuổi (và theo Gartner chỉ ra rằng trong 05 năm nữa SDN sẽ chín
muồi). Một trong những môi trường thuận lợi và dễ triển khai SDN, đặc biệt là với Cloud
Data Center. Hiện nay các nhà cung cấp nội dung lớn như (Google, Facebook, Amazon)
đã thực hiện sử dụng SDN trong các Data Center. Các Tier 1 Operator đã từng bước đưa
SDN vào Data Center và thực hiện ảo hóa các thành phần điều khiển như AT&T đưa ra
mục tiêu ảo hóa được 75% các phần tử trong mạng vào năm 2020.
Hình 1.5 - Dự báo quy mô thị trường SDN 2019-2025

22
Global Market Insights dự báo quy mô thị trường SDN được ước tính lên đến 100 tỷ
USD vào năm 2025 và ước tính sẽ tăng trưởng với tốc độ hơn 40% trong khoảng thời
gian dự báo 2019-2025 (Hình 1.5) [4].
Những nỗ lực tích cực của các nhà cung cấp dịch vụ viễn thông để giải quyết các
thách thức của mạng truyền thống đang phát triển vô số con đường mới cho thị trường
mạng được xác định bằng phần mềm. Trong năm năm qua, các dịch vụ viễn thông cung
cấp đang ráo riết tìm kiếm các công nghệ mới phát sinh từ các nỗ lực chung của cộng
đồng và ngành công nghiệp nguồn mở. Họ đã thử nghiệm các giải pháp từ dự án nền
tảng mở cho dự án NFV (OPNFV), hệ điều hành mạng mở (ONOS) và các dự án như
OpenDaylight. Những nỗ lực này thúc đẩy việc áp dụng các công nghệ mạng thế hệ tiếp
theo như SDN để cải thiện hiệu quả, tính linh hoạt, khả năng mở rộng và khả năng lập
trình của mạng viễn thông.
Việc thiếu các tiêu chuẩn để kiểm soát toàn bộ thiết bị đang cản trở việc áp dụng các
công nghệ SDN. Khung OpenFlow là tiêu chuẩn được sử dụng phổ biến nhất trong bối
cảnh SDN. Khung có một giao thức cập nhật bảng chuyển tiếp đơn hướng, xác định
trạng thái của các thiết bị được kết nối. Tuy nhiên, khung OpenFlow không thể thực
hiện thiết lập thiết bị cơ bản, hạn chế khả năng tương thích với các công nghệ mạng
truyền thống hiện có. Hơn nữa, việc chưa thể cung cấp khả năng điều khiển thiết bị đầy
đủ (điều kiện tiên quyết cho hầu hết các hệ thống mạng) đang hạn chế sự tăng trưởng
của thị trường SDN.
23
CHƯƠNG 2: NGHIÊN CỨU, THỬ NGHIỆM SDN CỦA CÁC HÃNG VÀ

MÃ NGUỒN MỞ
2.1. Nghiên cứu các giải pháp ứng dụng của Nokia và Juniper
Phương pháp nghiên cứu, thực nghiệm dựa trên nguyên tắc so sánh, đánh giá và lựa
chọn giải pháp của các hãng, giải pháp mã nguồn mở từ đó đưa ra nhận định lựa chọn
giải pháp phù hợp với hiện trạng, nhu cầu mạng truyền tải trong các Telco Cloud Data
Center đảm bảo tính khả thi về kỹ thuật cũng như hiệu quả về chi phí.
Nokia và Juniper là 2 hãng công nghệ mạng hàng đầu trên thế giới, việc lựa chọn
nghiên cứu, thử nghiệm, đánh giá giải pháp SDN theo định hướng này giúp đội dự án
tiếp cận nhanh với công nghệ cũng như có cái nhìn khách quan trong xu thế phát triển
chung của giải pháp ứng dụng này trên thế giới. Bản thân tác giả là người chủ trì tìm
hiểu, nghiên cứu giải pháp và đề xuất đưa vào triển khai theo lộ trình này của dự án.
Trong phần này, tác giả sẽ trình bày chi tiêt kết quả đạt được trong quá trình nghiên
cứu cấu trúc, tính năng giải pháp ứng dụng SDN của Nokia và Juniper.
2.1.1. Nghiên cứu giải pháp SDN của Nokia – Hệ thống Nuage
Xuất phát từ ý tưởng của SDN là tách mặt phẳng điều khiển khỏi mặt phẳng dữ liệu
và cung cấp một mặt phẳng quản lý duy nhất thông qua các API, Nokia đã phát triển
nền tảng Nuage triển khai theo mô hình tương tự (Hình 2.1) [5]. Nuage tạo ra một nền
tảng dịch vụ ảo hóa VSP [6]. VSP thực hiện việc triển khai, xử lý các mặt phẳng của mô
hình SDN như sau:
Hình 2.1 - Kiến trúc hệ thống Nuage Nokia

 Mặt phẳng quản lý Nuage Virtualized Services Directory (VSD) và Hệ thống quản
lý đám mây CMS (OpenStack, CloudStack, v.v.) có chức năng quản lý VSP của Nokia,
nó định nghĩa và giám sát các policy của mạng lưới. Nó bao gồm một kiến trúc VSD và
một giao diện web thân thiện người dùng để cấu hình và giám sát VSD.
 Mặt phẳng điều khiển: Nuage Virtualized Services Controller (VSC) có chức năng
tự động phát hiện các thông số mạng khác nhau của các VM truy nhập vào các
24
Hypervisor và lập trình các tham số (tại chuyển mạch lớp 2, định tuyến lớp 3, QoS, bảo
mật, …) một cách rõ ràng và đưa xuống VRS.
 Mặt phẳng dữ liệu: Virtual Routing and Switching (VRS) thực hiện đóng và mở gói
dữ liệu người dùng trước khi gửi ra mạng vật lý. Nó thực thi các chính sách về lưu lượng
truy nhập lớp 2 và lớp 4 đã được định nghĩa bởi VSD.
- VSP bao gồm ba thành phần ảo hóa chính:
 VSD (Thư mục dịch vụ ảo): chứa các chuẩn dịch vụ mạng và chính sách.
 VSC (Bộ điều khiển dịch vụ ảo): là bộ điều khiển SDN giao tiếp với các Hypervisor
 VRS Agent (Bộ định tuyến và chuyển mạch ảo): Nằm trong Hypervisor trên phần
cứng máy chủ.
Những giao thức truyền thông được triển khai giữa các thành phần VSP khác nhau:
 Giao tiếp giữa CMS (Hệ thống quản lý đám mây, như OpenStack, CloudStack,
vCenter, vCloud, ...) và VSD được thực hiện thông qua API RESTful. Các API này cho
phép cấu hình Nền tảng dịch vụ Nuage - VSP.
 Giao tiếp giữa VSD và VSC thông qua giao thức được chuẩn hóa XMPP (Extensible
Messaging and Presence Protocol), sử dụng để quản lý mạng.
 Giao tiếp giữa VSC và các Hypervisor (bao gồm VRS) thông qua OpenFlow, sử
dụng cho lớp cơ sở hạ tầng Underlay.
 Tích hợp nền tảng ảo hóa với Bare metal (các máy chủ và thiết bị không ảo hóa),
Nuage Networks cũng cung cấp giải pháp Gateway: cổng VRS dựa trên phần mềm
(VRS-G) và 7850 VSG dựa trên phần cứng.
2.1.1.1. Các dịch vụ ảo hóa VSD
VSD (Virtualized Services Directory) là nơi nhà quản lý thực hiện định nghĩa các
dịch vụ bằng cách xác định nhóm dịch vụ mạng (hình 2.2).
Hình 2.2 - Các dịch vụ ảo hóa VSD

25
Định nghĩa dịch vụ bao gồm Domain, Zone, Subnet, Policy templates. Một Domain
Templates cũng có thể bao gồm các chính sách (ví dụ: chuyển tiếp, QoS, …) được áp
dụng ở các mức khác nhau (vPort, Subnet, Zone, Domain). VSD sử dụng giao thức
XMPP để giao tiếp với VSC. VSD cũng chứa một công cụ phân tích mạnh mẽ (tùy chọn,
tìm kiếm linh hoạt). VSD hỗ trợ API RESTful để liên lạc với các hệ thống quản lý của
nhà cung cấp đám mây dịch vụ.
Các phân vùng dịch vụ ảo hóa VSD:
- Domain: Một doanh nghiệp chứa một hoặc nhiều tên miền. Một miền là một không
gian Layer 3, bao gồm một hoặc nhiều mạng con có thể giao tiếp với nhau. Người dùng
CSP Root có thể tạo domain cho tất cả các doanh nghiệp. Người dùng nhóm quản trị
viên và người vận hành mạng có thể tạo domain cho doanh nghiệp của họ.
- Domain layer 2: bao gồm định tuyến giữa các mạng con, là một cơ chế để cung cấp
miền quảng bá L2 duy nhất trong trung tâm dữ liệu. Có thể mở rộng miền quảng bá vào
mạng LAN hoặc VLAN kế thừa
- Zone: Các Zone được xác định trong một miền. Một Zone không ánh xạ trực tiếp
tới mạng, nó hoạt động sao cho tất cả các điểm cuối trong Zone tuân thủ cùng một bộ
chính sách.
- Subnet: Subnet được xác định trong một Zone. Một Subnet là một mạng con IP cụ
thể. Mạng con này được khởi tạo như một dịch vụ LAN riêng ảo được định tuyến (R ‐
VPLS). Một mạng con là duy nhất trong một Domain (các mạng con trong một miền
không được phép chồng lấn hoặc chứa các mạng con khác theo các định nghĩa Subnet
IP tiêu chuẩn).
- vPorts: Cổng được cấu hình và liên kết với một cổng VM (hoặc cổng Gateway)
trước khi nó tồn tại trên hypervisor hoặc Gateway. Các cổng kết nối máy chủ Bare Metal
với lớp Overlay cũng được gọi là vPort.
Một số thành phần của VSD:
 Công cụ quản lý chính sách (Policy Management DB).
 VSD mediator: Là một giao diện hướng nam của VSD được sử dụng để liên lạc với
VSC. Nó nhận các yêu cầu về thông tin và cập nhật chính sách từ VSC, đồng thời gửi
các bản cập nhật chính sách cho VSC. Bản thân VSD là một máy khách XMPP: nó giao
tiếp với máy chủ XMPP hoặc các cụm máy chủ.
 Công cụ thống kê (Statistics Engine).
 REST API.
2.1.1.2. Bộ điều khiển dịch vụ ảo hóa VSC
Bộ điều khiển dịch vụ ảo hóa VSC đóng vai trò như là bộ điều khiển SDN, điều
khiển mạng, giao tiếp với Hypervisor và thu thập thông tin liên quan đến VM như địa
chỉ MAC và IP. VSC sử dụng OpenFlow để điều khiển VRS. Trên mỗi VRS, đều xác
định VSC (Virtualized Services Controller) nào đang hoạt động và VSC nào đang ở chế
26
độ chờ (VRS có thể định cấu hình với các VSC hoạt động khác nhau để cân bằng tải,
backup dữ liệu). OpenFlow sử dụng cổng TCP 6633 và nó được sử dụng để tải FIB
L2/L3 về các bộ chuyển mạch ảo trên Hypervisor (Hình 2.3)
Hình 2.3 – Bộ điều khiển dịch vụ ảo hóa VSC

- VSC được cài đặt như là một máy ảo, đóng gói trong OVA (vCenter) hoặc QCOW2
(KVM) VSC có giao diện điều khiển được kết nối với lớp Underlay. Nó dựa trên hệ điều
hành định tuyến dịch vụ Nokia (SROS).
- Bộ điều khiển hoạt động như mặt phẳng điều khiển, định tuyến được thiết lập giữa
VSC và các bộ định tuyến khác để thực hiện Data Center Interconnect. VSC dùng giao
thức định tuyến, có thể là ISIS, OSPF hoặc các tuyến tĩnh. MP-BGP EVPN cũng cần
được thiết lập giữa tất cả các VSC để cập nhật các thông tin liên quan trong mạng. VSC
có ba kết nối trực tiếp: Đến VSD qua XMPP; giữa các VSC, đến VRS.
2.1.1.3. Bộ định tuyến, chuyển mạch ảo VRS
Bên trong Hypervisor, trong mặt phẳng chuyển tiếp dữ liệu của mô hình SDN, thực
hiện chuyển tiếp, đóng gói mở gói lưu lượng người dùng bằng VXLAN trước khi gửi ra
mạng vật lý, thực hiện chính sách lưu lượng L2-L4 được định nghĩa bởi VSD (Hình
2.4). Một VRS (Virtual Routing and Switching) kết nối tới nhiều VSC khác nhau để dự
phòng, cân bằng tải và mỗi VRS thiết lập phiên OpenFlow sử dụng mạng Underlay,
thông qua cổng TCP 6633.
Hình 2.4 – Bộ định tuyến và chuyển mạch ảo

27
- VRS bao gồm hai thành phần chính:

 VRS Agent, giao tiếp với VSC bằng OpenFlow. Chịu trách nhiệm lập trình FIB
L2/L3 và trả lời tất cả ARP.
 Open vSwitch (OVS), cung cấp các thành phần chuyển mạch và định tuyến và
đường hầm (tunnel) để chuyển tiếp lưu lượng.
- VRS hỗ trợ một loạt các phương thức đóng gói L2 và L3 (VXLAN, Vlan,
MPLSoGRE) để nó có thể giao tiếp với một loạt các điểm cuối mạng bên ngoài (các bộ
định tuyến khác, bộ định tuyến dựa trên IP hoặc MPLS).
- Nuage Networks sử dụng các mã nguồn mở, như libvert, OVS và OpenFlow:
 Virt-Manager: Dành cho GUI
 Virsh: Các lệnh (CLI)
- Open vSwitch (OVS) thực hiện kết nối L2 và học địa chỉ MAC. OpenFlow được sử
dụng để cấu hình vSwitch. Được sử dụng cho Linux Network và là một phần của Linux
Kernel.
- Mạng Overlay: Ảo hóa trên cơ sở hạ tầng mạng vật lý. Các máy chủ không biết về
lớp phủ. VXLAN: VXLAN dùng 24 bit để đánh số VLAN ID (so với VLAN là 12 bit
tạo ra 4096 VLAN ID), cho phép 16 triệu ID người thuê khác nhau.
- Tất cả các VTEP trong mặt phẳng điều khiển VXLAN cần kết nối IP. VTEP vai trò
là cổng mặc định cho tất cả các mạng con mà VM được lưu trữ của nó thuộc về. Để thực
hiện việc này, VTEP sẽ được chỉ định một địa chỉ MAC và địa chỉ IP trong mỗi mạng
con đó.
- BGP EVPN là một họ địa chỉ có thể bao gồm cả địa chỉ IP và MAC cho một end
point. Các bảng chuyển tiếp trên mỗi hypervisor chứa thông tin về tất cả các VM trong
tất cả các mạng con (mỗi mạng con tương ứng với một thể hiện EVPN khác nhau). Các
đường hầm VXLAN tồn tại để tới được các mạng con trên tất cả các hypervisor.
- VRS ở lớp mạng underlay, OVS ở lớp mạng overlay. Tất cả Hypervisor cần giao
diện kết nối tới mạng underlay. Cũng có thể gán VTEP tới ToR Switch thay cho một
Hypervisor.
- VSG (Virtual Services Gateway) cho phép kết nối giữa miền vật lý và miền ảo hóa.
Chuyển tiếp dựa trên VLAN to VxLAN (VxLAN hướng tới lớp overlay mạng Nuage,
VLAN tới lớp cơ sở hạ tầng. Có hai phiên bản Nuage (cho vật lý và ảo hóa), một phiên
bản cho “White Boxes” [7].
- VSN là node dịch vụ ảo, bao gồm 1 VSC và nhóm các VRS. VSC điều khiển các
VRS (các hypervisor). VSN cung cấp cho các nhà điều hành mạng một cái nhìn toàn
diện về tất cả thành phần mạng.
2.1.1.4. Chính sách bảo mật và chuỗi dịch vụ
- Chính sách bảo mật được định nghĩa ở Domain, chuyển tới các Zone, Subnet (Hình
2.5).
28
Hình 2.5 – Cơ chế làm việc chính sách bảo mật

- Ví dụ: INGRESS là cổng mà lưu lượng đi vào OVS, EGRESS là cổng mà lưu lượng
đi ra khỏi OVS.
- Tại thời điểm tạo, một Policy Group Type được gán cho từng chính sách bảo mật:
Phần cứng: dành cho máy chủ và cầu nối vPort được lưu trữ trong Nuage VSG / VSA
Gateways và phần mềm: VRS và VRS-G lưu trữ vPort, bao gồm VM, máy chủ lưu trữ
và cầu nối vPort.
- Tính năng ACL Sandwich cho phép quản trị viên mạng xác định danh sách lưu
lượng truy cập. Người dùng cuối sở hữu tên miền sau đó có thể kết hợp các quy tắc ACL
thành các ACL được xác định ở cấp thể hiện tên miền.
- Chuỗi dịch vụ VSP cung cấp chính sách chuyển tiếp để kiểm soát việc chuyển hướng
các gói, là chuỗi dịch vụ. Nuage hỗ trợ thiết bị/cụm thiết bị ảo L4-7 vật lý và ảo làm
đích chuyển hướng và nó cung cấp tùy chọn tạo chính sách chuyển hướng nâng cao,
cung cấp tùy chọn chuyển hướng lưu lượng truy cập đến một cổng TCP/UDP nhất định.
2.1.2. Giải pháp SDN của Juniper - Contrail
Juniper Network Contrail là một giải pháp SDN mã nguồn mở tự động điều phối,
tạo các mạng ảo có khả năng mở rộng lớn. Các mạng ảo giúp chúng ta có khả năng khai
thác đám mây cho các ứng dụng và dịch vụ mạng. Contrail là một mô hình giải pháp
mạng mã nguồn mở có thể tích hợp với các router và switch vật lý giúp giải quyết các
vấn đề khó khăn của mạng Private và Public cloud [8].
Contrail có thể làm việc với các thiết bị mạng vật lý bên trong mạng truyền thống
giúp giải quyết các vấn đề của mạng một cách tự động. Với kiến trúc của Contrail có
thể giúp giảm chi phí đầu tư ban đầu. Tất cả các chức năng mạng như switching, routing,
29
load balancing được chuyển từ các phần cứng vật lý trở thành các phần mềm chạy trên
nền hypervisor kernel được quản lý bởi hệ thống điều phối trung tâm. Nó cho phép hệ
thống giảm chi phí đầu tư hạ tầng chuyển mạch vật lý khi mở rộng. Các phần cứng
chuyển mạch không có thông tin trạng thái của máy ảo, khách hàng, ứng dụng mà chỉ
tham gia vào việc định tuyến lưu lượng từ một máy chủ sang máy chủ khác. Hệ thống
contrail sẽ giải quyết vấn đề một cách linh hoạt, cho phép tự động hóa dịch vụ mạng và
tích hợp với các hệ thống điều phối đám mây như OpenStack và CloudStack bằng Rest
API.
2.1.2.1. Kiến trúc Contrail
Hệ thống Contrail gồm 2 phần: Contrail SDN controller và những Contrail
vRouter đóng vai trò là các thiết bị chuyển mạch mềm được triển khai trên hypervisor
của các máy chủ ảo đa chức năng. Contrail SDN Controller cung cấp giao diện
northbound REST API được sử dụng cho lớp ứng dụng để mở rộng hệ thống điều phối
đám mây. Được sử dụng bởi Openstack thông qua Neutron, OSS/BSS hoặc GUI (Hình
2.6).
Hình 2.6 – Kiến trúc Contrail - Juniper

Hệ thống Contrail cung cấp 3 giao diện interface. Northbound REST API được
sử dụng giao tiếp giữa hệ thống điều phối và các ứng dụng. Southbound interface được
sử dụng để truyền thông giữa các phần tử mạng ảo như Contrail vRouter hoặc các phần
tử mạng vật lý như gateway router và switch. East-West interface được sử dụng để kết
nối với các Controller khác. East-West interface là chuẩn BGP. XMPP là southbound
30
interface cho Contrail vRouter. BGP và NETCONF là southbound interface của gateway
router và switch.
2.1.2.2. Contrail SDN controller
Contrail SDN controller bao gồm 3 thành phần chính (Hình 2.7).
Hình 2.7 – Contrail SDN controller
 Analytics node chịu trách nhiệm thu thập dữ liệu từ các phần tử mạng và mô tả
chúng vào một form thích hợp để lớp ứng dụng có thể sử dụng. Analytics node giao tiếp
với các ứng dụng sử dụng giao diện phía bắc REST API, với các analytics node khác sử
dụng các kỹ thuật đồng bộ, với các phần tử khác trong control và configuration node
bằng XML (Hình 2.8).
Chức năng Analytics node:
o Trao đổi bản tin Sandesh (Sandesh là một giao thức dựa trên XML-based để báo
cáo thông tin phân tích) với các thành phần trong control node và configuration
node thu thập thông tin phân tích.
o NoSQL database lưu trữ thông tin đó.
o Các quy tắc tự động thu thập trạng thái hoạt động khi xảy ra các sự kiện cụ thể.
31
Hình 2.8 - Analytics Node

 Configuration node chịu trách nhiệm biên dịch mô hình dữ liệu mức cao thành mức
thấp hơn phù hợp để tương tác với các phần tử mạng. Configuration node giao tiếp với
hệ thống điều phối thông qua giao diện REST. Với các Configuration node khác bằng
kỹ thuật đồng bộ phân phối. Và với control node thông qua IF-MAP (Hình 2.9).
Hình 2.9 - Configuration Node

32
Configuration node cung cấp dịch vụ Discovery cho khách hàng sử dụng có thể định
vị các nhà cung cấp dịch vụ. Ví dụ khi vRouter agent trong compute node kết nối với
một control node. Nó sử dụng dịch vụ Discovery để khám phá địa chỉ IP của các control
node. Máy khách có thể dử dụng để cấu hình cục bộ DHCP hoặc SDN để xác định vị trí
của service discovery server.
Configuration node bao gồm các thành phần:
o REST API server.
o Một bus bản tin Redis.
o Cassandra database.
o Schema transformer.
o Server IF-MAP.
o Zookeeper.
 Control node chịu trách nhiệm truyền đạt các dữ liệu trạng thái mức thấp đó tới các
phần tử mạng và kết nối với các hệ thống khác một cách nhất quán.
Control node giao tiếp với nhiều node khác nhau (Hình 2.10):
Hình 2.10 – Control Node

o Nhận trạng thái cấu hình từ configuration node sử dụng giao thức if-map
o Trao đổi định tuyến với các control node khác bằng giao thức iBGP
o Trao đổi định tuyến với các vRouter agent trong compute node bằng giao thức
XMPP
o Trao đổi định tuyến với gateway node sử dụng BGP và cũng có thể gửi trạng thái
cấu hình sử dụng NETCONF
2.1.2.3. Contrail vRouter
Ngoài 3 thành phần chính trình bày ở trên, Contrail SDN controller còn bao gồm 3
phần tử quan trọng khác, đó là: Computer Node, Gateway node và Service node:
33
 Compute node là các server ảo hóa lưu trữ các VM. Các VM này có thể sử dụng để
cho thuê chạy các ứng dụng hoặc có thể là các máy ảo dịch vụ chạy các dịch vụ mạng
như Load Balancer, virtual firewall. Mỗi Compute node chứa một Contrail vRouter thực
hiện việc chuyển tiếp và phân phối một phần của lớp điều khiển.
Contrail vRouter là các phần tử mạng được triển khai bằng phần mềm. Nó chịu
trách nhiệm chuyển tiếp các gói tin từ một VM tới các VM khác thông qua đường kết
nối giữa các server. Bản chất Contrail vRouter là một server x86 chứa các máy ảo. Các
VM này được chạy các ứng dụng cá nhân như Web server, database server, các ứng
dụng doanh nghiệp hoặc các dịch vụ ảo để tạo chuỗi dịch vụ. Contrail vRouter bao
gồm vRouter forwarding plane (mặt phẳng chuyển tiếp) nằm trên Linux kernel, và
vRouter agent là Local forwarding plane (mặt phẳng điểu khiển cục bộ). Hai khối
trong Compute node tạo lên Contrail vRouter là vRouter agent và vRouter forwarding
plane (Hình 2.11)
Hình 2.11 – Computer Node

 vRouter agent thực hiện các chức năng:
o Trao đổi trạng thái điều khiển như định tuyến với control node sử dụng XMPP.
o Nhận các trạng thái cấu hình cấp thấp như trường hợp định tuyến và nhận chính
sách chuyển tiếp từ control node qua giao thức XMPP
o Báo cáo các phân tích trạng thái như logs, statics, các sự kiện tới analytics nodes.
o Thiết lập trạng thái chuyển tiếp vào lớp chuyển tiếp.
o Phát hiện sự tồn tại và thuộc tính của các máy ảo khi kết hợp với Nova agent.
o Mỗi vRouter agent kết nối với ít nhất 2 control node để dự phòng.
 vRouter forwarding plane thực hiện các chức năng:
o Đóng gói mở gói tin được gửi đi hoặc nhận từ overlay network
o Các gói tin nhận được từ overlay network được chỉ định tới 1 trường hợp định tuyến
trên cơ sở nhãn MPLS hoặc VNI-virtual network identifier.
34
o Là giao diện ảo cho các máy ảo nhảy tới các trường hợp định tuyến.
o Nó thực hiện tìm kiếm địa chỉ đích trong cơ sở dữ liệu chuyển tiếp (FIB) tương tự
như các bảng chuyển tiếp để chuyển tiếp gói tin đúng tới đích. Việc định tuyến có
thể thực hiện ở Layer 3 IP hoặc Layer 2 MAC.
o Các chính sách chuyển tiếp có thể được ứng dụng cho các flow table.
o Match các gói tin với flow table và ứng dụng các flow action.
o Gửi các gói tin không match với flow table tới vRouter agent để cài đặt rule mới
vào flow table.
o Gửi các gói tin như DHCP, ARP, MDNS tới vRouter agent để proxying
o Mặt phẳng chuyển tiếp hỗ trợ MPLS dưới GRE/UDP và đóng gói VXLAN ở
Overlay. Mặt phẳng chuyển tiếp hỗ trợ cả chuyển tiếp layer 3 và layer 2. Hiện tại
mặt phẳng chuyển tiếp vRouter hỗ trợ Ipv4 và có thể hỗ trợ Ipv6 trong tương lai.
 Gateway node là các gateway router hoặc switch vật lý kết nối các máy ảo hoặc
mạng ảo tới mạng vật lý như internet, VPN cá nhân, các data center khác hoặc các server
không phải ảo hóa.
 Service node là các thành phần mạng vật lý cung cấp các dịch vụ mạng như DPI,
IDP, IPS, tối ưu WAN và cân bằng tải. Chuỗi dịch vụ có thể bao gồm nhiều dịch vụ ảo
như triển khai VM trong compute node và dịch vụ vật lý như lưu trữ trên các node dịch
vụ.
2.1.2.4. Các giao thức quản lý và điều khiển
 Giao thức IF-MAP
 IF-MAP: giao diện truy cập Metadata là một giao thức giữa máy chủ và máy khách
tiêu chuẩn mở được phát triển bởi Trusted Computing Group (TCG) là một trong
những giao thức cốt lõi của kiến trúc kết nối mạng mở đáng tin cậy.
 IF-MAP cung cấp giao diện giữa Metadata Access Point (MAPs), một database
server đóng vai trò trao đổi thông tin về các sự kiện bảo mật, thiết bị bảo mật và các
thành phần khác của kiến trúc kết nối mạng đáng tin cậy.
 IF-MAP cung cấp các kỹ thuật mở rộng để định nghĩa mô hình dữ liệu. Định nghĩa
giao thức để công bố, mô tả, tìm kiếm trong nơi lưu trữ dữ liệu.
 Contrail sử dụng IF-MAP để phân phối thông tin cấu hình từ Configuration node
tới Control node.
 Giao thức XMPP
 Là một giao thức truyền thông cho bản tin định hướng trung gian dựa trên XML.
XMPP ban đầu được đặt tên là Jabber được sử dụng để nhắn tin tức thì, hiện diện
thông tin, và bảo trì danh sách liên lạc.
 Contrail sử dụng XMPP làm bus thông tin giữa các compute node và control node
để trao đổi thông tin bao gồm routes, configuration, operational state, statistics, logs
và các sự kiện.
 Giao thức BGP
35
 Contrail sử dụng BGP (RFC 4271) để trao đổi thông tin định tuyến giữa các control
node. BGP cũng có thể được sử dụng để trao đổi thông tin định tuyến giữa control
node và gateway node.
 Giao thức Sandesh
 Sandesh là một giao thức dựa trên XML để báo cáo thông tin phân tích. Các thành
phần của mọi node đều kết nối với analytics node và trao đổi thông tin thông qua
bản tin Sandesh.
2.1.3. So sánh giải pháp giữa Nuage Nokia và Contrail Juniper
Đánh giá kết quả nghiên cứu, thử nghiệm giải pháp SDN cho Telco Cloud Data
Center của 2 nhà cung cấp Juniper (Contrail) và Nokia (Nuage) có thể đưa ra một số
nhận định và lợi ích nổi bật, cụ thể như sau:
- Với việc sử dụng công nghệ VXLAN giúp số lượng VLAN ID tăng lên 16 triệu, kết
quả này giải quyết vấn đề nhu cầu tăng trưởng kết nối giữa các Data center trong
tương lai.
- Quá trình quy hoạch, cấp phát, thu hồi tài nguyên IP trong DC được thực hiện tự
động, dễ dàng tạo các chuỗi dịch vụ, tự động đấu nối liên kết các tài nguyên hạ tầng
mạng (Switch, Router, Firewall, Load Balancer…) giúp giảm đánh kể thời gian triển
khai, nhanh chóng đưa dịch vụ đến khách hàng.
- Các tác vụ trong quản lý, vận hành hệ thống thực hiện tập trung và được đơn giản
hóa giúp giảm yêu cầu về nhân lực vận hành, cũng như giảm chi phí vận hành mạng
lưới.
- Một số thiết bị, chức năng mạng như Switch, Router, Firewall, Load balancer… được
ảo hóa để có thể triển khai trên White box hoặc máy ảo giúp giảm chi phí đầu tư hạ
tầng mạng.
Để làm rõ ưu/nhược điểm của từng giải pháp, ta đưa ra bảng so sánh chi tiết trong
bảng sau:
Giải pháp Nuage Nokia Contrail Juniper
- Triển khai end to end trong DC: tốt - Triển khai end to end trong DC: tốt
- Khả năng cài đặt: tốt - Khả năng cài đặt: tốt
Đánh giá - Khả năng tùy biến hệ thống: rất tốt - Khả năng tùy biến hệ thống: tốt
- Tốc độ thực hiện: tốt - Tốc độ thực hiện: tốt
- Kết quả test case: tốt - Kết quả test case: chưa hoàn thiện
- Mở rộng hỗ trợ cả phần cứng và môi - Contrail hỗ trợ mạnh mẽ cho
trường ảo hóa bao gồm Docker, KVM, Openstack và ảo hóa dựa trên
Điểm
Microsoft, Openstack, và Vmware container: Kubernetes và Openshift
mạnh
- Nuage hỗ trợ giao thức VXLAN, - Contrail hỗ trợ giao thức VXLAN,
MPLSL3, L2VPNS, GRE, BGP MPLSL3, L2VPNS, GRE, BGP
36
Giải pháp Nuage Nokia Contrail Juniper
- VSC hỗ trợ một số bộ chuyển mạch - Contrail có thể cấu hình mạng vật lý
vật lý từ Arista, DELL, HPE, Nokia và của Juniper để hỗ trợ kết nối giữa
bare metal network (VRS-G) SDN và các mạng ngoài.
- Công cụ chính sách mạnh mẽ dựa trên
hệ thống quản lý bảo mật.
-VSC không kết hợp với NSX của
Vmware cho VTEP hoặc các bộ chuyển - Hệ sinh thái trung tâm dữ liệu không
Hạn chế mạch phân tán của Vmware. đa dạng
- Cạnh tranh trực tiếp với Cisco và - Thị trường hạn chế
Vmware trong DC SDN
Bảng 2.1 - So sánh giải pháp giữa Nokia và Juniper
2.2. Nghiên cứu các giải pháp ứng dụng SDN mã nguồn mở
Giải pháp SDN Contrail của Juniper và Nuage của Nokia cho Telco Cloud Data
Center có rất nhiều ưu điểm nổi bật, phù hợp với nhu cầu của mạng truyền tải của hầu
hết các nhà cung cấp dịch vụ viễn thông và CNTT. Tuy nhiên, việc triển khai SDN hiện
đang gặp trở ngại trong vấn đề hiệu quả chi phí đầu tư cũng như định hướng phát triển
mở rộng, nâng cao tính năng hệ thống.
Đối với các nhà cung cấp dịch vụ viễn thông & CNTT, vấn đề tối ưu chi phí cũng
như hiệu quả đầu tư cực kỳ quan trọng và luôn xem xét hướng đến tìm kiếm một giải
pháp không những đáp ứng được hầu hết những lợi ích tương đương từ giải pháp của
các hãng mang lại, có khả năng tùy biến linh hoạt phù hợp nhất với hiện trạng hạ tầng
mạng lưới của họ, đồng thời cũng phải đảm bảo chi phí đầu tư ban đầu cũng như vận
hành hệ thống tối ưu nhất.
Theo quan điểm này, nhóm dự án đã tập trung nghiên cứu, thử nghiệm 2 giải pháp
SDN mã nguồn mở Tungsten Fabric và OpenDayLight để so sánh đánh giá tính năng,
hiệu năng sử dụng của giải pháp, đánh giá khả năng tương thích hệ thống. Đây cũng là
định hướng để xây dựng giải pháp SDN theo nhu cầu của Viettel dựa trên các giải pháp
mã nguồn mở trong tương lai.
2.2.1. Giải pháp của Tungsten Fabric (TF)
Tungsten Fabric là một nền tảng mạng ảo hóa mã nguồn mở được phát triển trên
nền tảng giải pháp Juniper Contrail, với khả năng mở rộng cao, nó được thiết kế phục
vụ cho mạng đa người dùng trong môi trường lớn, sử dụng đồng thời nhiều Orchestrator
[9]. Tungsten Fabric triển khai 3 chức năng chính:
 Multi-tenancy
 Gateway function: Kết nối các mạng ảo hóa tới các mạng vật lý, kết nối các dịch vụ
mạng ảo và không ảo tới các mạng ảo thông qua một Gateway router.
37
 Service chaining: Điểu khiển lưu lượng tự động đi qua các chuỗi dịch vụ trong mạng
ảo hóa và vật lý như firewall, load balancer.
Ngoài ra Tungsten Fabric cũng cung cấp các chức năng khác như mã hóa bảo
mật, theo dõi giám sát hoạt động, topo, hiệu năng hệ thống. Cung cấp các chức năng
mạng Routing&Switching, Load balancing. Cung cấp các APIs, Orchestrations, WebUI
hỗ trợ việc quản lý vận hành. Tungsten Fabric gồm có thành thành phần chính
Thành phần chính Tungsten Fabric là Controller có chức năng tự động tính toán,
cấu hình cho các thiết bị ở lớp chuyển tiếp đáp ứng yêu cầu, chính sách cuả nhà điều
phối. Ngoài ra chúng còn tự động thu thập thông tin, trạng thái hoạt động của các phần
tử của hệ thống thông qua bản tin Sandesh lưu trữ trong Cassandra database. Nhà vận
hành có thể truy cập để lấy các thông tin đã được lưu trong các form thông qua REST
API để dễ dàng nhanh chóng xây dựng các ứng dụng giám sát và phân tích hoạt động
hệ thống. Controller bao gồm 3 node chính (Hình 2.6):
 Configuration node chịu trách nhiệm biên dịch mô hình dữ liệu mức cao thành mức
thấp hơn phù hợp để tương tác với các phần tử mạng.
 Control node chịu trách nhiệm truyền đạt các trạng thái mức thấp đó tới các phần tử
mạng và kết nối với các hệ thống khác một cách nhất quán.
 Analytics node chịu trách nhiệm thu thập dữ liệu từ các phần tử mạng và mô tả chúng
vào một form thích hợp để lớp ứng dụng có thể sử dụng.
Bên cạnh vRouter đóng vai trò là các thiết bị chuyển mạch mềm được triển khai trên
hypervisor của các máy chủ ảo đa chức năng, Tungsten Fabric có các giao diện giao tiếp
giữa các lớp bao gồm:
- Northbound interface: REST API
- Southbound interface: XMPP, BGP, NETCONF
- East&West interface: BGP
2.2.2. Giải pháp của OpenDaylight (ODL)
OpenDaylight là một nền tảng SDN đã xuất hiện và khá thành công trong những
năm 2010. OpenDayLight (ODL) là một nền tảng mô đun mở hỗ trợ việc cá nhân hóa
và tự dộng hóa mạng ở nhiều kích cỡ. ODL tập trung vào khả năng lập trình mạng. ODL
đến nay đã có 10 bản phát hành, là Open source SDN controller được sử dụng phổ biến
nhất với một cộng đồng rộng khắp trên thế giới [10].
ODL code đã được liên kết và nhúng vào hơn 35 giải pháp và ứng dụng của các
hãng như XNC của Cisco, SDN controller của ADVA…
Nền tảng ODL được xây dựng để cho phép người dùng, nhà cung cung cấp giải
pháp có thể tự xây dựng Controller một cách linh hoạt nhất phụ thuộc vào nhu cầu của
bản thân. ODL là nền tảng hỗ trợ nhiều giao thức nhất trong những nền tảng SDN như
Openflow, OVSDB, NETCONF, BGP…
Với khả năng module hóa, ODL cho phép nhà phát triển và người dùng:
 Chỉ cần cài đặt giao thức và dịch vụ mong muốn.
38
 Có thể kết hợp nhiều giao thức và dịch vụ để có sự linh hoạt nhất.
 Tăng cường sự hợp tác phát triển nền tảng mã nguồn mở
 Nhanh chóng phát triển các tính năng cá nhân, gia tăng giá trị, tận dụng một nền
tảng chung được chia sẻ
OpenDayLight hỗ trợ người dùng:
 Phân phối dịch vụ tự động: Cung cấp các dịch vụ on-demand được điều khiển bằng
end user và service provider ví dụ như lên lịch băng thông, dịch vụ VPN tự động…
 Cloud và NFV: Phân phối dịch vụ trên hạ tầng Cloud nhanh chóng cho cả enterprise
và service provider. Các thiết bị mạng Underlay và dịch vụ mạng có thể được triển
khai bằng NFV.
 Tối ưu các nguồn lực mạng: Tự động tối ưu mạng dựa vào tải và các trạng thái cho
phép tối ưu gần như thời gian thực cho lưu lượng, topo, thiết bị.
 Khả năng quan sát và điều khiển: Cho phép quản lý mạng tập trung qua giao diện
trực quan.
Cộng đồng ODL cung cấp sự nâng cấp liên tục trong các vấn đề liên quan tới bảo
mật, khả năng mở rộng, sự hoạt động ổn định và hiệu suất. OpenDayLight tuân theo
kiến trúc chung của SDN (Hình 2.12):
Hình 2.12 - Kiến trúc OpenDayLight

- Network Apps & Orchestration: Là lớp trên cùng của giải pháp bao gồm các ứng
dụng logic mạng và kinh doanh, cho phép việc điều khiển và giám sát hành vi mạng.
Ngoài ra các ứng dụng có thể phối hợp với các giải pháp khác nếu cần để quản lý
Cloud, các ứng dụng NFV.
- Controller Platform: Lớp thứ hai của giải pháp, nó cung cấp nhiều API phổ biến để
giao tiếp với lớp ứng dụng/Orchestrator. Nó cũng có thể triển khai một hoặc nhiều
giao thức cho việc điều khiển các thiết bị mạng vật lý. Bên trong Controller cũng
chứa các module phục vụ việc quản lý, giám sát, cấu hình các thiết bị mạng.
39
- Physical & Virtual Network Devices: Là lớp cuối cùng của giải pháp ODL, bao gồm
các thiết bị mạng vật lý và ảo hóa, switch, router… Chúng được điều khiển, cấu hình
bởi SDN controller.
2.2.3. So sánh giải pháp của Tungsten Fabric (TF) và OpenDaylight (ODL)
Căn cứ vào kết quả nghiên cứu, tìm hiểu cũng như test thử nghiệm tính năng tại Lab
(tham chiếu tại Phụ lục 1: Kết quả thử nghiệm tại Lab) có thể đưa ra một số nhận định
đánh giá và so sánh ưu điểm/hạn chế của 2 giải pháp cơ bản như sau:
- Đánh giá Tungsten Fabric:
+ Tungsten Fabric hỗ trợ giao diện quản lý. Trên giao diện Web UI của Tungsten Fabric
cung cấp đủ các tính năng giúp nhà vận hành giám sát quản lý, cấu hình chính sách, truy
xuất thông tin về số lượng, hiệu năng, luồng traffic… của từng phần tử trong hệ thống.
Tất cả các công việc vận hành hệ thống SDN đều có thể thực hiện trên giao diện Web
UI.
+ Các tính năng Tungsten Fabric cung cấp trong quá trình thử nghiệm vận hành ổn định,
không phát sinh lỗi hệ thống, đáp ứng được yêu cầu vận hành khi triển khai thực tế.
+ Trên thực tế, việc thử nghiệm chưa thể đánh giá hoàn chỉnh Testcase “SFC interwork
với Firewall và Load balancer” do chưa đảm bảo được thiết bị hỗ trợ và tư vấn từ chuyên
gia của hãng.
- Đánh giá OpenDayLight:
+ Về giao diện do trong cộng đồng không còn tổ chức nào đứng ra phát triển phần giao
diện cho OpenDayLight (ODL) nên ODL hỗ trợ giao diện rất nghèo nàn và không thân
thiện với người vận hành khai thác. Việc thao tác trên giao diện phức tạp và kết quả đem
lại không mang nhiều giá trị. Ở các bản Release sau này ODL đã bỏ phần giao diện và
sẽ không còn giao diện hỗ trợ việc vận hành nữa.
+ ODL cung cấp rất nhiều tính năng hữu ích, nhưng khi thử nghiệm hệ thống thường
xuyên gặp lỗi có thể kể đến như là VM không nhận IP, mất IP, interface kết nối tới
Router từ các network bị disable hàng loạt… không đảm bảo dịch vụ khi triển khai thực
tế.
Kết luận: Sự lựa chọn giải pháp Tungsten Fabric để triển khai cho hạ tầng Cloud
là phù hợp và tối ưu hơn so với giải pháp OpenDayLight, đây là quan điểm đánh giá có
tính chất tham khảo quan trọng cho định hướng lựa chọn giải pháp chính thức đưa vào
triển khai thực tế trong tương lai. Chi tiết quá trình phát triển và triển khai thí điểm giải
pháp mã nguồn mở của Tungsten Fabric trên hạ tầng Cloud hiện có sẽ được trình bày
chi tiết tại Chương 3 của luận văn.
40
CHƯƠNG 3: TRIỂN KHAI GIẢI PHÁP TỰ PHÁT TRIỂN

3.1. Mục tiêu triển khai
Qua 2 giai đoạn nghiên cứu, thử nghiệm SDN cho hạ tầng Cloud Data Center: Giai
đoạn 1 nhằm tìm hiểu tính năng vai trò của SDN với sản phẩm SDN của Nokia (hệ thống
Nuage) và Juniper (hệ thống Contrail); Giai đoạn 2 nhằm đánh giá tính năng, khả năng
đáp ứng nhu cầu cho hệ thống Cloud Data Center của giải pháp SND mã nguồn mở
Tungsten Fabric và OpenDaylight, nhóm dự án đã có góc nhìn khá toàn diện về giải
pháp đối với mạng truyền tải trong Cloud Data Center và đi đến quyết định lựa chọn
giải pháp mã nguồn mở Tungsten Fabric với những ưu điểm nổi trội và được cộng đồng
hỗ trợ mạnh làm nền tảng để phát triển và triển khai thí điểm.
Mục tiêu giai đoạn này là đánh giá khả năng tích hợp SDN mã nguồn mở sử dụng
nguồn Tungsten Fabric vào hệ thống Cloud Data Center; đánh giá các tính năng, mức
độ hoàn thiện trong vận hành khai thác và khả năng hoạt động ổn định của hệ thống. Từ
đó hoàn thiện sản phẩm và đưa vào triển khai ở quy mô lớn.
3.2. Phạm vi triển khai
Phạm vi triển khai là cụm Private Cloud cung cấp hạ tầng Cloud cho các đơn vị nội
bộ Viettel chạy các ứng dụng ít quan trọng và các ứng dụng thử nghiệm. Cụm Cloud có
quy mô: 81 Compute node, tổng số có 2552 CPU, 15 TB Ram, 244TB Storage, cung
cấp hạ tầng cho khoảng 400 VM (máy ảo). Việc triển khai thí điểm SDN trên cụm Cloud
này đảm bảo yêu cầu test tích hợp và vận hành trên hệ thống Cloud mang tải thật của
Viettel đồng thời hạn chế ảnh hưởng trong trường hợp xảy ra sự cố không mong muốn.
3.3. Tổ chức triển khai
Quá trình triển khai được phân thành 4 giai đoạn:
- Khảo sát, quy hoạch đấu nối và lắp đặt bổ sung thiết bị.
- Cài đặt tích hợp SDN Controller.
- Đồng bộ tài nguyên.
- Cắt chuyển VM từ OpenStack sang hạ tầng SDN.
Ứng với mỗi giai đoạn sẽ có các yêu cầu đảm bảo cũng như các bước thực hiện sẽ
được tác giả trình bày chi tiết trong từng phần sau:
3.3.1. Quy hoạch đấu nối và triển khai lắp đặt thiết bị
Sơ đồ lắp đặt thực hiện trên cụm Cloud có sẵn có quy mô triển khai như đã nêu tại
mục trên (mục 3.2), để cung cấp tính năng VxLAN cho cụm Cloud, nhóm triển khai
quay hoạch đấu nối và lắp đặt, tích hợp bổ sung 1 cặp Switch Leaf HP 5940 (Hình 3.1).
41
Hình 3.1 - Sơ đồ lắp đặt

Quy hoạch đấu nối chi tiết: Cụm Cloud, thiết bị hiện tại và thiết bị lắp đặt bổ sung
(1 cặp Switch Leaf HP 5940) được quy hoạch vị trí lắp đặt và đấu nối chi tiết tại Bảng
3.2. Cụ thể như sau:
STT Switch Port Switch Port Location
XGigabitE
HLC9205CLO Ten
1 thernet1/1/ HLC9105IT.CLO SPHL07_RACK19
UD.CR01 1/0/48
0/30 UD.LEAF.01
XGigabitE
HLC9205CLO HLC9105IT.CLO Ten
2 thernet2/1/ SPHL07_RACK19
UD.CR02 UD.LEAF.01 2/0/48
0/30
XGigabitE
0/8
XGigabitE
0/8
M-
HLC9105IT.CL HLC102DCN.N3
5 GigabitEth Eth1/39
OUD.LEAF.01 K.AC05
ernet0/0/0
Bảng 3.1 - Quy hoạch đấu nối
42
3.3.2. Cài đặt, tích hợp SDN controller

3.3.2.1. Cài đặt, tích hợp SDN controller
Đối với các hạ tầng mới, việc cài đặt và tích hợp hệ thống SDN controller diễn ra
song song trong quá trình cài đặt NFVI (Openstack, VMware...) Nhưng đối với Viettel,
hệ thống Cloud đã tồn tại và đang vận hành. Để tích hợp SDN controller cần phải cắt
chuyển các VM từ hạ tầng Cloud đơn thuần sang hạ tầng Cloud có cài đặt SDN controller
(Hình 3.1).
Hình 3.2 - Mô hình cắt chuyển

Cụ thể như sau:
- Dồn dịch tài nguyên tạo ra các compute trống.
- Cài đặt SDN controller trên 1 compute trống riêng.
- Các compute trống còn lại cài đặt thành phần vRouter.
- Cắt chuyển VM từ hạ tầng cũ sang hạ tầng được quản lý bởi SDN controller.
3.3.2.2. Công cụ Skydive
Skydive là công cụ giám sát topology mã nguồn mở, công cụ này được nhóm dự án
phát triển do nhu cầu giám sát hạ tầng Cloud Underlay và Overlay trên 1 giao diện duy
nhất, với các tính năng chính như sau:
- Phát hiện và mô phỏng topo mạng chứa các thiết bị vật lý bao gồm các switch, máy
chủ và các cổng mạng vật lý, cũng như các thiết bị ảo như các máy ảo, containers,
các cổng mạng ảo và các liên kết vật lý cũng như các liên kết ảo giữa chúng.
- Giám sát trạng thái hoạt động của từng nút mạng, giám sát thông số lưu lượng thời
gian thực đi qua từng liên kết mạng.
- Nhanh chóng phát hiện vị trí của các nút mạng dựa trên địa chỉ IP và đường đi (nếu
có) giữa hai địa chỉ IP bất kỳ.
Công cụ Skydive được phát triển dựa trên sử dụng các ngôn ngữ Golang (phát triển
thành phần Agents và Analyzers), ngôn ngữ TyperScript triển khai dưới dạng NGINX
43
web server (phát triển giao diện người dùng) và sử dụng cơ sở dữ liệu Elasticsearch
(phát triển cơ sở dữ liệu đồ thị). Tất cả các dịch vụ nói trên đều được đóng gói trong các
Docker containers và triển khai trên các máy chủ một cách tự động thông qua Ansible.
Skydive được thiết kế bao gồm bốn thành phần chính:
- Agents: Được triển khai trên các máy chủ vật lý, đảm nhiệm vai trò phát hiện và giám
sát trạng thái của các thực thể hoạt động trên máy chủ, bao gồm các cổng mạng, các
máy ảo và containers.
- Analyzers: Tổng hợp các thông tin phát hiện được bởi agent thành một đồ thị thống
nhất thể hiện một cách tổng thể topo mạng. Analyzer còn thực hiện truy vấn thông
tin từ những thực thể bên ngoài (các switch vật lý, các API giám sát v.v.) để làm giàu
thông tin cho đồ thị.
- Cơ sở dữ liệu: Lưu trữ đồ thị dưới dạng các nút và liên kết cũng như metadata tương
ứng cho từng nút và liên kết.
- Giao diện người dùng web: Trực quan hóa topo mạng trên một giao diện người dùng
thống nhất.
Việc sử dụng Skydive khá đơn giản, người sử dụng chỉ cần mở giao diện web đăng
nhập tài khoản, mật khẩu (truy nhập OpenStack trước đó), sau đó có thể xem các thông
số trạng thái hoặc vào các nút mạng để mở rộng để quan sát các thành phần con.
3.3.3. Đồng bộ tài nguyên
Giai đoạn đồng bộ tài nguyên được thực hiện với mục đích đảm bảo các tài
nguyên mạng bên OpenStack được đồng bộ sang Tungsten Fabric và thực hiện chạy dữ
liệu một lần.
Khi chuyển dịch từ hạ tầng Cloud cũ sang hạ tầng Cloud sử dụng SDN controller,
do trong thông tin của SDN controller là Tungsten Fabric chưa có các thông tin về
network của hạ tầng Cloud cũ nên những tài nguyên liên quan đến server như network,
subnet, port, security group cần được đồng bộ sang SDN controller. Quá trình đồng bộ
phải đảm bảo triển khai được cho tất cả các server đang chạy trên cụm hạ tầng cloud
thực nghiệm, bao gồm server Ubuntu, CentOS và Windows.
Để đảm bảo cắt chuyển một server thành công, cần đảm bảo những điều kiện các
tài nguyên liên quan đến server như network, subnet, port, security group phải được
đồng bộ sang Tungsten Fabric SDN controller.
Có 5 bước thực hiện đồng bộ tài nguyên được thực hiện lần lượt như sau:
 Bước 1: Login vào server và vào quyền root.
 Bước 2: Run container convert-script để convert các tài nguyên network.
 Bước 3: Chuyển đến thư mục tf-script và cập nhật code mới nhất
 Bước 4: Chỉnh sửa thông tin authentication
 Bước 5: Thực hiện convert các tài nguyên mạng từ OpenStack sang TF.
3.3.4. Triển khai cắt chuyển VM sang hạ tầng SDN
44
Quá trình cắt chuyển VM sang hạ tầng SDN được thực hiện qua 5 bước (Hình 3.2). Cụ
thể như sau:
 Bước 1: Kiểm tra tình trạng hoạt động của VM, đơn vị quản lý vận hành VM.
 Bước 2: Chạy tool đồng bộ, trích suất thông tin từ OpenStack sang SDN
controller.
 Bước 3: Thực hiện cắt chuyển VM sang hạ tầng SDN, sau khi cắt chuyển kiểm
tra theo các Checklist.
 Bước 4: Liên hệ đơn vị đang quản lý VM, phối hợp kiểm tra hoạt động của VM
sau khi cắt chuyển.
 Bước 5: Nếu các dịch vụ chạy trên VM hoạt động bình thường thì hoàn thành.
Trong trường hợp xảy ra bất cứ lỗi hay hiệu năng không đạt sẽ thực hiện Roll
Back lại hạ tầng cũ.
Hình 3.3 – Các bước cắt chuyển

3.4. Kết quả triển khai
3.4.1. Triển khai hệ thống
- Lắp đặt, cấu hình và tích hợp cặp Switch Leaf HP 5940 vào hạ tầng cụm vCloud
hiện hữu, hệ thống phần cứng tương thích, hoạt động ổn định.
- Dồn dịch tài nguyên và cài đặt SDN controller trong cụm vCloud thành công, cài
đặt Plugin trên OpenStack controller kết nối được 2 hệ thống OpenStack và SDN.
- Nhóm dự án đã phát triển được công cụ Skydive cho phép giám sát hạ tầng Cloud
Underlay và Overlay trên 1 giao diện duy nhất.
45
3.4.2. Kiểm tra tính năng, test dịch vụ và đảm bảo điều kiện đổ tải
- Thực hiện được các testcase đánh giá tính năng của hệ thống SDN.
- Test khả năng Live migrate các máy ảo sang hạ tầng quản lý bởi SDN. Các VM hoạt
động bình thường sau khi cắt chuyển.
- Phát triển công cụ Network Resource Synchronization Tool cho phép tự động đồng
bộ tài nguyên sang SDN trước khi cắt chuyển máy ảo, công cụ cho phép migrate tài
nguyên của 1 Network trong khoảng 5 phút thay vì 1 ngày theo cách làm thủ công.
- Xây dựng kịch bản cắt chuyển và Rollback khi có sự cố.
3.4.3. Tích hợp, đổ tải và đánh giá
- Tích hợp SDN controller vào Cloud của Viettel thành công.
- Cắt chuyển 80/80 máy ảo mang tải thật để đánh giá hoạt động của hệ thống và các
máy ảo sau khi cắt chuyển.
- Sau khi triển khai, công cụ Skydive cho phép giám sát các kết nối của thiết bị Switch,
Server, máy ảo trong cụm Cloud, giúp việc giám sát trở nên thuận tiện hơn (Hình
3.3).
Hình 3.4 - Giám sát bằng công cụ Skydive

Việc triển khai, tích hợp giải pháp SDN do đội dự án tự phát triển vào hạ tầng
Cloud của Viettel không gây ảnh hưởng đến công tác vận hành và hoạt động của các
VM đang chạy.
3.5. Đánh giá hệ thống sau khi tích hợp SDN Controller.
Kết quả đánh giá tính năng hệ thống trước và sau khi tích hợp SDN controller
được tóm tắt qua Bảng 3.3, cụ thể như sau:
STT Tiêu chí Truyền thống SDN controller
Đáp ứng các tính năng về quản
1 lý, cấp phát tài nguyên trên Có Có
Cloud
46
STT Tiêu chí Truyền thống SDN controller

Hiệu năng thấp, sử
2 Hỗ trợ VxLan Hiệu năng cao
dụng VLAN
Hỗ trợ nhiều Platform khác
3 Hỗ trợ quản lý Multi platform Không hỗ trợ nhau (Openstack, Vmware,
K8s..)
4 Quản lý các hạ tầng phân tán Không hỗ trợ Có
Thiết lập policy điều khiển

5 Không hỗ trợ Có
chung
Hỗ trợ đối với cả VNF và
6 Service function Chain Không hỗ trợ
PNF
Giám sát, tự động xây dựng
7 Topology quản lý tập trung hạ Không hỗ trợ Có
tầng Overlay và Underlay
Quản lý và cấu hình tự động

thiết bị mạng của nhiều hãng
Bảng 3.2 - Đánh giá hệ thống trước và sau khi tích hợp SDN
Hệ thống sau khi tích hợp SDN controller, hệ thống cho phép mở rộng tài nguyên
vào hạ tầng Cloud đã tồn tại và có dịch vụ đang chạy. Bên cạnh khả năng mở rộng số
lượng network có thể cung cấp lên đến 16 triệu, gấp 4.000 lần hạ tầng cũ, đáp ứng nhu
cầu mở rộng mạng trong tương lai, hệ thống còn cho phép quản lý tập trung, đồng thời
nhiều platform ảo hóa hạ tầng mạng khác nhau như OpenStack, K8S, VMware… Một
tính năng quan trọng nổi bật đó là cho phép quản lý topology Overlay và Underlay trên
cùng một giao diện. Ngoài ra, hệ thống còn có khả năng tự động tạo chuỗi dịch vụ tự
động (SFC) giúp tự động cấu hình các node mạng vật lý và ảo hóa, giảm thời gian triển
khai dịch vụ.
Tuy nhiên, trong quá trình triển khai hệ thống, giải pháp SDN mã nguồn mở của
Tungsten Fabric (TF) vẫn còn một số hạn chế sau:
- Giải pháp chỉ hỗ trợ 4 nền tảng đang được sử dụng phổ biến hiện nay gồm:
Openstack, K8s, VMware, Redhat Openshift, trong khi một số hãng đang cung cấp
các VNF trên nền tảng ảo hóa tự phát triển như Nokia phát triển nền tảng CBIS cho
vEPC hoặc Casa dùng Wind River cho vBRAS. Với các nền tảng ảo hóa này, thường
không được cộng đồng mã nguồn mở hỗ trợ, phát triển nếu cần tích hợp với SDN.
- Các phiên bản mới từ TF thường yêu cầu nâng cấp OS, không tương thích ngược với
OS cũ gây khó khăn nếu muốn bổ sung, nâng cấp các tính năng mới cho hệ thống,
cũng như tốn kém thời gian trong quá trình thử nghiệm các phiên bản mới. Ngoài ra,
các bản TF mới thường ra chậm hơn so với các cập nhật của OpenStack (~6
tháng/lần).
47
- Do sử dụng mã nguồn mở nên không tránh được các lỗi phát sinh trong quá trình
vận hành khai thác cần nhiều thời gian để theo dõi, phát hiện kịp thời trong quá trình
khai thác và hoàn thiện sản phẩm trước khi nhân rộng.
- Khi tích hợp với hạ tầng Cloud là hạ tầng cũ, thiết bị mạng chưa theo kiến trúc
Spine/Leaf nên gặp nhiều vấn đề liên quan đến giao tiếp VLAN với VxLAN, MTU,
NIC, Kennel. Nhóm triển khai đã phải nâng cấp hệ thống cũng như phải liên tục trao
đổi, cập nhật từ cộng đồng mã nguồn mở và thường mất nhiều thời gian để khắc
phục, xử lý.
3.6. Đánh giá tiềm năng ứng dụng
Với việc tích hợp SDN mã nguồn mở sử dụng nguồn TF vào hệ thống Cloud Data
Center ngoài ưu điểm nổi bật về chức năng quản lý tài nguyên mạng lưới như đã phân
tích tại mục 3.5, nó còn cho phép quản lý, khai thác hạ tầng phân tán, thiết lập chính
sách điều khiển chung đối với tài nguyên trên Cloud. Với ưu điểm này, hạ tầng Cloud
hiện tại có thể cung cấp giải pháp xử lý các bài toán mô phỏng cảnh báo lan truyền dịch
bệnh trên đàn gia súc từ những nguồn dữ liệu không đồng nhất.
Hệ thống Cloud được tích hợp SDN mã nguồn mở với thế mạnh hiện có, có thể
giải quyết được các bài toán mô phỏng sự lan truyền dịch bệnh để đưa ra các kết quả
làm cơ sở phân tích, đánh giá và cảnh báo dịch bệnh.
Cụ thể, đối với mô hình kiến trúc tổng thể của hệ thống dịch vụ phân tích cảnh
báo lan truyền dịch bệnh trên đàn gia súc (Hình 3.4), các kết quả nghiên cứu và thực
Hình 3.5- Sơ đồ kiến trúc tổng thể của hệ thống dịch vụ phân
tích cảnh báo lan truyền dịch bệnh trên đàn gia súc
nghiệm của luận văn này có thể cung cấp giải pháp và tài nguyên để tổ chức điều phối
các chương trình và công cụ mô hình hóa lan truyền bệnh dịch (khối III) với nhiệm vụ
cấp phát một cách tối ưu tài nguyên tính toán phân tán và môi trường thực thi trên đám
48
mây theo nhu cầu cho các công cụ và chương trình ứng dụng kỹ thuật tự động hóa của
điện toán tự trị.
Phương pháp nghiên cứu triển khai sẽ sử dụng phương pháp co dãn tài nguyên
đảm bảo hiệu năng tính toán bao gồm mở rộng/thu hẹp tài nguyên bằng cách nhân
bản/giải phóng tài nguyên hiện có (theo chiều ngang) và thêm/bớt mịn một phần dung
lượng vào/ra khỏi tài nguyên hiện có (theo chiều dọc). Phương pháp này có thể được
thực hiện dễ dàng trên giao diện của SDN controller với việc tạo/mở rộng/thu hẹp tài
nguyên của các máy ảo (VM) trên hạ tầng Cloud hiện có phục vụ nhu cầu tài nguyên
tính toán linh hoạt.
Dịch vụ của giải pháp SDN trên hạ tầng Cloud chính là điều phối cấp phát tài
nguyên điện toán đám mây phù hợp bám sát nhu cầu thực tế để tối ưu hiệu năng xử lý
các chương trình/công cụ mô phỏng của toàn hệ thống với việc chạy thử nghiệm kết hợp
các công cụ mô hình hóa khác nhau trên một số đối tượng vật nuôi là đàn bò/đàn lợn với
các loại dịch bệnh cụ thể. Kết hợp thu thập kết quả đầu ra và đo kiểm các thông số về
hiệu năng, chi phí của hệ thống được vận hành.
3.7. So sánh các tính năng SDN Opensource với truyền thống
Để có được nhận định cụ thể về những ưu/nhược điểm của giải pháp mã nguồn
mở do Viettel tự phát triển và các giải pháp mã nguồn mở (như TF và ODL) cũng như
giải pháp quản lý tài nguyên mạng lưới truyền thống, việc xây dựng các test case và
đánh giá khả năng hoạt động của các testcase này sẽ là cơ sở quan trọng đưa ra định
hướng phát triển mở rộng giải pháp mã nguồn mở tự phát triển trong tương lai.
Cụ thể kết quả đánh giá tính năng tại Bảng 3.4:
Truyền Sau khi tích hợp SDN
STT Tiêu chí
thống controller
1 Upload glance image Có Có
2 Create/Delete VM Có Có
3 Reboot/Shutdown/Start VM Có Có
4 Rename/Resize/Rebuild VM Có Có
5 Access to console Có Có
6 Snapshot VM Có Có
7 Manage keypair Có Có
8 Migrate VM Có Có
9 Live Migrate VM Có Có
10 Launch VM from Snapshot Có Có
11 Manage Data volume Có Có
12 Manage boot volume Có Có
13 Manage volume backup Có Có
14 Manage volume snapshot Có Có
15 Save image from volume Có Có
16 Manage Provider network Có Có
49
Truyền Sau khi tích hợp SDN

STT Tiêu chí
thống controller
17 Manage Self-service network Có Có
18 Manage Router Có Có
19 Manage port Có Có
Manage activity of
20 Server/Switch/VM/Service/Component Có Có
on the Dashboard
21 Hỗ trợ VxLan Ít sử dụng Hiệu năng cao
Hỗ trợ nhiều Platform
22 Hỗ trợ Multi-platform Không hỗ trợ khác nhau (Openstack,
Vmware, Kubernet…)
23 Quản lý các hạ tầng phân tán Không hỗ trợ Có
24 Thiết lập policy điều khiển chung Không hỗ trợ Có
Hỗ trợ đối với cả VNF và
25 Service function Chain Không hỗ trợ
PNF
Giám sát, tự động xây dựng Topology
26 quản lý tập trung hạ tầng Overlay và Không hỗ trợ Có
Underlay
Quản lý và cấu hình tự động thiết bị
mạng của nhiều hãng
Bảng 3.3 - Đánh giá tính năng giải pháp SDN mã nguồn mở tự phát triển
Qua bảng so sánh ta có thể thấy rõ ngoài những tiêu chí cơ bản, giải pháp SDN mã
nguồn mở có những tính năng nổi trội như khả năng mở rộng số lượng network có thể
cung cấp lên đến 16 triệu (gấp 4.000 lần) hạ tầng truyền thống nhờ công nghệ VXLAN,
hỗ trợ nhiều nền tảng khác nhau, hỗ trợ các hạ tầng phân tán trong khi các chính sách
điều khiển, giám sát có thể được quản lý tập trung và cấu hình tự động (cho cả hạ tầng
Overlay và Underlay). Một tính năng khác biệt nữa đó chính là SDN có khả năng điểu
khiển lưu lượng tự động đi qua các chuỗi dịch vụ (Service function Chain) trong mạng
ảo hóa và vật lý như firewall, load balancer.
3.8. So sánh các SDN Opensource với sản phẩm thương mại
Hệ thống SDN mã nguồn mở do đội dự án Viettel tự phát triển cho phép tích hợp và
cấu hình tự động với thiết bị mạng từ nhiều hãng khác nhau. Trong khi đó với các hệ
thống SDN thương mại phần lớn vẫn giữ “lock in vendor” để hạn chế triển khai cho
thiết bị mạng của các hãng khác.
Hệ thống SDN sử dụng mã nguồn mở đã phát triển được tính năng cho phép tích hợp
với các cụm Cloud đang cung cấp dịch vụ, ứng dụng đang chạy, trong khi các sản phẩm
thương mại thường yêu cầu phải triển khai trên cụm Cloud mới.
50
Giảm thiểu chi phí lên đến 80% so với đầu tư mua sắm, triển khai các hệ thống
thương mại, tránh phụ thuộc vào các hãng cung cấp. Điều này có thể được chỉ rõ thông
qua số liệu phân tích và tính toán như sau:
Theo phân tích của ZK research. Tổng chi phí triển khai giải pháp SDN với giải pháp
ACI (Cisco) hoặc NSX (VMware) cho 1 cụm Cloud có quy mô 125 Compute host
(tương đương cụm vCloud Huawei đang triển khai) ~ 1.118.300 USD. Đây là chi phí
đầu tư mua sắm giải pháp SDN không bao gồm chi phí đầu tư hạ tầng phần cứng và nền
tảng ảo hóa. Trong khi đó chi phí nghiên cứu, phát triển giải pháp SDN sử dụng mã
nguồn mở Tungsten Fabric (bao gồm nghiên cứu, thử nghiệm, tối ưu hệ thống và phát
triển các tính năng) chỉ vào khoảng 130.000 USD.
Mặc dù triển khai SDN mã nguồn mở còn tiềm ẩn nhiều rủi ro, đặc biệt như đã thấy
rõ 4 điểm hạn chế được chỉ ra trong phần đánh giá giải pháp tại mục 3.5, tuy nhiên những
vấn đề này đang dần được nhóm dự án từng bước khắc phục. Với ưu điểm của bản thân
giải pháp, tính hiệu quả về mặt đầu tư, giải pháp SDN mã nguồn mở tự phát triển sẽ là
lựa chọn ưu tiên cho lộ trình tự động hóa mạng truyền tải trong Cloud Data Center của
các nhà cung cấp dịch vụ viễn thông và CNTT hiện nay.
51
KẾT LUẬN
Những đóng góp của luận văn:
Với mục tiêu" NGHIÊN CỨU, ĐÁNH GIÁ ỨNG DỤNG GIẢI PHÁP SDN CHO
HẠ TẦNG MẠNG TRUYỀN TẢI TRONG CÁC TELCO CLOUD DATA CENTER".
Luận văn đã nghiên cứu từ tổng quan giải pháp ứng dụng SDN đến phân tích đánh giá
giải pháp của các nhà cung cấp và lựa chọn, triển khai thực nghiệm giải pháp tự phát
triển. Những kết quả trên là căn cứ để định hướng phát triển giải pháp và đưa vào ứng
dụng thực tiễn trên mạng lưới.
Những kết quả chính đã đạt được trong luận văn:
- Khái quát được một số vấn đề về lý thuyết và kiến trúc giải pháp ứng dụng SDN.
- Nêu được phương pháp, các giai đoạn triển khai giải pháp ứng dụng SDN cho hạ
tầng mạng truyền tải trong các Telco Cloud Data Center.
Hướng phát triển của luận văn:
- Hiện tại giải pháp SDN tự phát triển còn bộc lộ một số hạn chế như: Lỗi phát sinh
về phần mềm (như: quá trình live migrate VM từ vrouter sang openvswitch hay quá
trình migrate/rebuid/resize VM từ openvswitch sang vrouter và ngược lại), lỗi
network (lỗi trên Leaf HP gây duplicate gói tin), các ảnh hưởng về hiệu năng, rủi ro
khi mở rộng (hạ tầng cụm triển khai sử dụng NIC cũ, lỗi thời, không hỗ trợ các
offload tính checksum (tx offload), phân đoạn TCP (TSO), tunnel offload,… MTU
trên các lớp switch chuyển tiếp nên để jumbo frame, các interface trên server triển
khai SDN cần cấu hình tối thiểu 2.000 byte để đảm bảo gói tin không bị phân mảnh.
Đội dự án vẫn đang tiếp tục khắc phục các lỗi phát sinh này cũng như cập nhật phiên
bản OpenStack release 6 tháng/lần để hoàn thiện hệ thống.
- Mở rộng phạm vi ứng dụng cung cấp các dịch vụ thử nghiệm để đánh giá hiệu năng
hệ thống, so sánh với hệ thống hiện tại để có cách nhìn tổng quan, định hướng hoàn
thiện hệ thống trong tương lai.
- Quy hoạch đồng bộ mạng truyền tải cho các Data Center, tính toán và đưa vào triển
khai phương án backup tối thiểu 1+1 cả về hạ tầng phần cứng và phần mềm cho hệ
thống SDN controller. Thiết lập kết nối và đồng bộ với các hệ thống quản lý, giám
sát, vận hành mạng lưới đang dùng cho mạng truyền tải (hệ thống tác động; hệ thống
quản lý, cấu hình tự động node mạng; hệ thống quản lý tài nguyên mạng; hệ thống
cảnh báo sớm; …).
52
TÀI LIỆU THAM KHẢO
[1] Hype Cycle for Communications Service Provider Operations, 2019, July 2019
[2] https://tek4.vn/tong-quan-ve-mang-dinh-nghia-mem-sdn-software-defined-
networks/
[3] https://www.ibm.com/services/network/sdn-versus-traditional-networking
[4] https://www.gminsights.com/industry-analysis/software-defined-networking-
sdn-market
[5] https://www.nuagenetworks.net/
[6] https://www.nokia.com/networks/solutions/virtualized-services-platform/
[7] https://www.nuagenetworks.net/blog/software-defined-love-nuage-networks-
7850-virtualized-services-gateway-vsg/
[8] https://www.juniper.net/us/en/products-services/sdn/contrail/
[9] https://tungsten.io/opencontrail-is-now-tungsten-fabric/
[10] https://www.opendaylight.org
53
PHỤ LỤC 1: Kết quả thử nghiệm tại Lab với giải pháp Tungsten Fabric và
Opendaylight
1. Danh mục các Testcase
No Testcase
1 VM Instantiation
2 VM interface Configuration with DHCP
3 VM interface Configuration with static IP
4 Inter VMs connectivity
5 Delete VM
6 VM host migration (inter-VM)
7 VM host migration (VM-with-Policy)
Virtual IP tracking for clustering Monitor ability of traffic to track a VIP

8
or cluster address that moves between VMs on a layer 2 network
9 Service Function Chaining (SFC)

10 TF metadata agent
11 Security groups
12 Multi-VIP support via Allowed Address Pairs
13 Floating IP (FIP)
14 SNAT to underlay (PAT)
15 SFC interwork với Firewall và Load balancer
16 Expose TF-managed subnets to OpenStack
17 QoS - rate limiting
18 Statistics retrieval
19 Threshold Crossing Alerts
20 Virtual to physical VLAN Interworking through TOR (Switch L3 Cisco)
21 TF throughput performance test
53
54
2. Kết quả thực hiện các Testcase với Tungsten Fabric

Testcase VM Instantiation
Trạng thái Pass
Yêu cầu: VM xuất hiện trên giao diện quản lý mạng của SDN
Kết quả:
Testcase VM interface configuration with DHCP

Trạng thái Pass
Yêu cầu: Khi tạo VM mới, VM sẽ nhận IP cấp tự động từ DHCP
Kết quả:
Enable feature DHCP trên Network, tạo VM mới, VM sẽ tự động nhận IP DHCP
54
55
Testcase VM interface configuration with static IP

Trạng thái Pass
Yêu cầu: Có thể gán IP mặc định cho VM
Kết quả:
Testcase Inter VMs connectivity

Trạng thái Pass
Yêu cầu: Các VM có thể Ping thông tới nhau
Kết quả:
55
56
Testcase Delete VM
Trạng thái Pass
Yêu cầu: Có thể Xóa VM
Kết quả:
Testcase VM host migration (inter-VM)

Trạng thái Pass
Yêu cầu: VM được di chuyển giữa 2 compute với độ trễ nhỏ
Kết quả:
56
57
Testcase Virtual IP
Trạng thái Pass
Yêu cầu: Thiết lập Virtual IP cho các VM backup cho nhau
Kết quả:
57
58
Testcase Service function chaining (SFC)

Trạng thái Pass
Yêu cầu: Tạo chuỗi dịch vụ liền mạch, cấu hình tự động
Kết quả:
58
59
59
60
Testcase Metadata
Trạng thái Pass
Yêu cầu: Khi tạo VM mới, có thể chọn các package để cài đặt bổ sung cho VM
Kết quả:
Khi Launch instance, trong mục Metadata có thể tùy chọn package để cài đặt vào
VM
60
61
Testcase Security group

Trạng thái Pass
Yêu cầu: Tạo được các Security group khác nhau. Khi tạo VM có thể chọn VM
đó thuộc Security group nào
Kết quả:
61
62
Testcase Multi-Virtual IP
Trạng thái Pass
Yêu cầu: Gán nhiều Virtual IP cho các VM back up cho nhau
Kết quả: Tương tự như VIP
62
63
Testcase Floating IP
Trạng thái Pass
Yêu cầu: Tạo được IP public pool và associate cho VM internal, VM internal có
thể giao tiếp các VM external thông qua IP public được gán.
Kết quả:
63
64
64
65
Testcase SNAT to underlay (PAT)

Trạng thái Pass
Yêu cầu:
Kết quả:
65
66
Testcase SFC interwork with Firewall and Load balancer

Trạng thái Pass
Mô tả: SDN controller có khả năng cấu hình điều hướng traffic từ overlay
network xuống underlay network qua các thiết bị trung gian như Firewall, LB vật
lý, traffic sau khi đi qua thiết bị có thể quay trở lại overlay network.
Yêu cầu: thông traffic từ overlay xuống underlay, traffic được điều hướng theo
cấu hình
Kết quả: Thực hiện thủ công bằng Script, sau khi sử dụng Script chuỗi dịch vụ
được tạo tự động, traffic được điều hướng theo yêu cầu.
66
67
Testcase Expose TF-managed subnets to Openstack

Trạng thái Pass
Yêu cầu: Thông tin trên Tungsten Fabric và Openstack đồng bộ nhau mỗi khi có
sự thay đổi.
Kết quả:
Testcase QoS – rate limiting

Trạng thái Chưa Pass
Yêu cầu: Tạo QoS cho dịch vụ
Kết quả: thực hiện cấu hình trên giao diện tuy nhiên, QoS không khả dụng, cần
tìm hiểu thêm.
67
68
Testcase Statistics retrieval

Trạng thái Pass
Yêu cầu: Truy xuất thông tin trên giao diện của hệ thống
Yêu cầu:
Kết quả:
68
69
Testcase Threshold Crossing Alerts

Trạng thái Pass
Yêu cầu: Thiết lập ngưỡng cảnh báo cho hệ thống
Kết quả:
Virtual to Physical VLAN interworking through TOR (Switch L3

Testcase
cissco)
Trạng thái Chưa Pass
Yêu cầu: thông kết nối từ VM sử dụng overlay network ra under network
Kết quả: chưa thực hiện được do thiết bị không hỗ trợ OVSDB
69
70
Testcase Throughput performance test

Trạng thái Pass
Yêu cầu: Thoughput giữa các compute
Kết quả:
70
71
3. Kết quả thực hiện các Testcase với OpenDaylight

Testcase VM Instantiation
Trạng thái Pass
Yêu cầu: VM xuất hiện trên giao diện quản lý mạng của SDN
Kết quả:
71
72
Testcase VM interface configuration with DHCP

Trạng thái Pass
Yêu cầu: Khi tạo VM mới, VM sẽ nhận IP cấp tự động từ DHCP
Kết quả:
Enable feature DHCP trên Network
Testcase VM interface configuration with static IP

Trạng thái Pass
Yêu cầu: Có thể gán IP mặc định cho VM
Kết quả:
72
73
Testcase Inter VMs connectivity

Trạng thái Pass
Yêu cầu: Các VM có thể Ping thông tới nhau
Kết quả:
Tạo router và add interface của các network cần kết nối vào router
73
74
Testcase Delete VM
Trạng thái Pass
Yêu cầu: Có thể Xóa VM
Kết quả:
Chọn VM cần xóa và chọn Delete instance
74
75
Testcase VM host migration (inter-VM)

Trạng thái Pass
Yêu cầu: VM được di chuyển giữa 2 compute với độ trễ nhỏ
Kết quả:
75
76
Testcase VM host migration (VM with policy)

Trạng thái Fail
Yêu cầu: VM được migrate tự động khi không đáp ứng điều kiệns
Kết quả:
Testcase Virtual IP
Trạng thái Fail
Yêu cầu: Thiết lập Virtual IP cho các VM backup cho nhau
Kết quả:
76
77
Testcase Service function chaining (SFC)

Trạng thái Fail
Yêu cầu: Tạo chuỗi dịch vụ liền mạch, cấu hình tự động
Kết quả:
Testcase Metadata
Trạng thái Pass
Yêu cầu: Khi tạo VM mới, có thể chọn các package để cài đặt bổ sung cho
VM
Kết quả:
77
78
Testcase Security group

Trạng thái Pass
Yêu cầu: Tạo được các Security group khác nhau. Khi tạo VM có thể chọn VM
đó thuộc Security group nào
Kết quả:
Chọn create security group
Sau khi tạo thì sửa rule của group đó

79
Add rule
80
Khi tạo vm mới ngoài default group có sẵn còn có group 1 mới tạo
81
Testcase Multi-Virtual IP
Trạng thái Fail
Yêu cầu: Gán nhiều Virtual IP cho các VM back up cho nhau
Kết quả:
Testcase Floating IP
Trạng thái Fail
Yêu cầu: Tạo được IP public pool và associate cho VM internal, VM internal có
thể giao tiếp các VM external thông qua IP public được gán.
Kết quả:
Testcase SNAT to underlay (PAT)

Trạng thái Fail
Yêu cầu:
Kết quả:
Testcase SFC interwork with Firewall and Load balancer

Trạng thái Fail
Yêu cầu:
Kết quả:
Testcase Expose TF-managed subnets to Openstack

Trạng thái Fail
Yêu cầu: Thông tin trên Tungsten Fabric và Openstack đồng bộ nhau mỗi khi có
sự thay đổi.
Kết quả:
82
Testcase QoS – rate limiting

Trạng thái fail
Mô tả: Tạo QoS cho dịch vụ
Kết quả:
Testcase Statistics retrieval

Trạng thái Fail
Yêu cầu: Truy xuất thông tin trên giao diện của hệ thống
Kết quả:
Testcase Threshold Crossing Alerts

Trạng thái Fail
Yêu cầu:
Kết quả:
Virtual to Physical VLAN interworking through TOR (Switch L3

Testcase
cissco)
Trạng thái fail
Yêu cầu:
Kết quả:
Testcase Throughput performance test

Trạng thái fail
Yêu cầu:
Kết quả:
83
ĐẠI HỌC QUỐC GIA HÀ NỘI CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Độc lập - Tự do - Hạnh phúc
Hà Nội, ngày tháng năm 2021
BẢN XÁC NHẬN ĐÃ SỬA CHỮA CÁC THIẾU SÓT CỦA LUẬN VĂN
Trường Đại học Công nghệ đã có Quyết định số 414/QĐ-ĐT ngày 27 tháng 5
năm 2021 về việc thành lập Hội đồng chấm luận văn Thạc sĩ cho học viên Hoàng
Văn Dũng, sinh ngày 15/10/2985, tại Thanh Hóa, chuyên ngành Hệ thống thông tin,
ngành Hệ thống thông tin.
Ngày 10 tháng 7 năm 2021, Trường Đại học Công nghệ (ĐHCN) đã tổ chức
cho học viên bảo vệ luận văn Thạc sĩ trước Hội đồng chấm (có biên bản kèm theo).
Theo Quyết nghị của Hội đồng chấm luận văn Thạc sĩ, học viên phải bổ sung và sửa
chữa các điểm sau đây trước khi nộp quyển luận văn cuối cùng cho Nhà trường để
hoàn thiện hồ sơ sau bảo vệ:
1. Khắc phục một số lỗi trình bày do Hội đồng đã chỉ ra, cụ thể như sau:
- Các tiểu mục trong một chương nên đánh theo số chương, thay vì mỗi
chương lại đánh lại từ 1,2,3…
- Các hình vẽ, bảng cũng nên đánh theo chương cho tiện theo dõi.
- Hình 11 cho giải pháp Juniper và hình 17 cho giải pháp Tungsten fabric
giống nhau nên chỉ sử dụng một hình vẽ (Chương 2 – Tiểu mục 2.2.1: trang
36).
2. Phần thử nghiệm cần trình bày rõ ràng hơn: tổ chức, triển khai và đánh giá.
(trang 39 – trang 50).
3. Đề nghị học viên nêu rõ đóng góp của mình (Phần Mở đầu: trang 12).
4. Trong luận văn có nêu sử dụng nguồn mở cho SDN có ưu điểm là giảm chi
phí đến 80% và không phụ thuộc vào hãng cung cấp. Điều này có thực sự là
ưu điểm hay không? Nhược điểm của việc sử dụng nguồn mở là gì?
(Chương 3- Tiểu mục 3.5: trang 45, 46 và Tiểu mục 3.8: trang 48, 49).
5. Bổ sung mục tiêu thử nghiệm giải pháp mã nguồn mở tự phát triển (Chương
3 – Tiểu mục 3.1: trang 39).
6. Xem xét triển khai backup 1+1 đối với SDN controller (Phần Kết luận: trang
50).
7. Dịch chữ vendor sang tiếng Việt.
84
Ngày 21 tháng 7 năm 2021, học viên đã nộp bản luận văn có chỉnh sửa. Chúng
tôi nhận thấy rằng nội dung, hình thức của luận văn và tóm tắt luận văn đã được sửa
chữa, bổ sung theo các điểm trên của Quyết nghị.
Đề nghị Trường Đại học Công nghệ, ĐHQG HN cho phép học viên được làm
các thủ tục khác để được công nhận và cấp bằng Thạc sĩ.
Xin trân trọng cảm ơn!
XÁC NHẬN CỦA THÀNH VIÊN HỘI ĐỒNG/HỘI ĐỒNG

ĐỀ NGHỊ HỌC VIÊN SỬA CHỮA LUẬN VĂN
HỌC VIÊN CÁN BỘ HƯỚNG DẪN XÁC NHẬN CỦA CƠ SỞ ĐÀO TẠO
85
86
87
88
89

File Noi Dung TOAN VAN - Luan Van CH Hoang Van Dung K25

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

File Noi Dung TOAN VAN - Luan Van CH Hoang Van Dung K25

Uploaded by

Copyright:

Available Formats

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

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

HOÀNG VĂN DŨNG

NGHIÊN CỨU, ĐÁNH GIÁ ỨNG DỤNG GIẢI PHÁP SDN

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

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

HOÀNG VĂN DŨNG

NGHIÊN CỨU, ĐÁNH GIÁ ỨNG DỤNG GIẢI PHÁP SDN

Ngành: Công nghệ thông tin

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS PHẠM MẠNH LINH

Hà Nội, ngày 15 tháng 3 năm 2021

Hoàng Văn Dũng

LỜI CAM ĐOAN

Hoàng Văn Dũng

3.3.2.1. Cài đặt, tích hợp SDN controller ................................................................. 42

DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT

Application Programming Interface (Giao diện lập trình ứng

Forwarding Information Base (Cơ sở thông tin chuyển

13 GUI Graphical User Interface (Giao diện đồ họa người dùng)

16 IP Internet Protocol (Giao thức Internet)

19 MAC Media Access Control (Địa chỉ vật lý)

20 MDNS Multicast Domain Name System (Quảng bá tên miền)

Multiprotocol Label Switching (Chuyển mạch nhãn đa giao

23 NETCONF Network Configuration Protocol (Giao thức cấu hình mạng)

Network functions virtualization (Công nghệ ảo hóa chức

34 QoS Quality of Service (Chất lượng dịch vụ)

41 VLAN Virtual Local Area Network (Mạng LAN ảo)

49 VSG Virtualized Services Gateway (Cổng dịch vụ ảo)

50 VSN Virtualized Services Node (Node dịch vụ ảo)

53 VXLAN Virtual Extensible LAN

Extensible Messaging and Presence Protocol (Giao thức mở

DANH MỤC CÁC BẢNG

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ

CHƯƠNG 1: TỔNG QUAN

Hình 1.1 - So sánh kiến trúc mạng truyền thống và SDN

Hình 1.2 - Kiến trúc SDN

Hình 1.3 - Lớp điều khiển SDN

Hình 1.5 - Dự báo quy mô thị trường SDN 2019-2025

CHƯƠNG 2: NGHIÊN CỨU, THỬ NGHIỆM SDN CỦA CÁC HÃNG VÀ

Hình 2.1 - Kiến trúc hệ thống Nuage Nokia

Hình 2.2 - Các dịch vụ ảo hóa VSD

Hình 2.3 – Bộ điều khiển dịch vụ ảo hóa VSC

Hình 2.4 – Bộ định tuyến và chuyển mạch ảo

- VRS bao gồm hai thành phần chính:

Hình 2.5 – Cơ chế làm việc chính sách bảo mật

Hình 2.6 – Kiến trúc Contrail - Juniper

Hình 2.7 – Contrail SDN controller

Hình 2.8 - Analytics Node

Hình 2.9 - Configuration Node

Hình 2.10 – Control Node

Hình 2.11 – Computer Node

Giải pháp Nuage Nokia Contrail Juniper

Hình 2.12 - Kiến trúc OpenDayLight

CHƯƠNG 3: TRIỂN KHAI GIẢI PHÁP TỰ PHÁT TRIỂN

Hình 3.1 - Sơ đồ lắp đặt

3.3.2. Cài đặt, tích hợp SDN controller

Hình 3.2 - Mô hình cắt chuyển

Hình 3.3 – Các bước cắt chuyển

Hình 3.4 - Giám sát bằng công cụ Skydive

STT Tiêu chí Truyền thống SDN controller

Thiết lập policy điều khiển

Quản lý và cấu hình tự động