Mục đích nghiên cứu: Tìm hiểu khả năng ứng dụ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. Tóm tắt các kết quả của luận văn: Tìm hiểu kiến trúc, hiệu quả lợi ích giải pháp ứng dụ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 của hệ thống, các công nghệ, giao thức hoạt động trong quá trình vận hành của hệ thống trên hạ tầng mạng truyền tải, các ưunhược điểm giải pháp ứng dụng của các hãngphá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 của các nhà cung cấpmã nguồn mở khác nhau để định hướng lựa chọn giải pháp phù hợp và phương án kỹ thuật phục vụ lộ trình ứng dụng trên mạng truyền tải.
Trang 1TRƯỜ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
Trang 2ĐẠ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
Trang 3LỜ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
Trang 4LỜ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 củ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 rõ ràng từ danh mục tài liệu tham khảo trong luận văn Trong luận văn, không có việc sao chép tài liệu, công trình nghiên cứu của người khác mà không chỉ rõ về tài liệu tham khảo
Hà nội, ngày 15 tháng 3 năm 2021
Học viên
Hoàng Văn Dũng
Trang 5MỤ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 của SDN 18
1.4 Tiềm năng ứng dụng và xu hướng triển khai 19
1.4.1 Đánh giá tiềm năng ứng dụ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 dụng của Nokia và Juniper 23
2.1.1 Nghiên cứu giải pháp SDN của Nokia – Hệ thống Nuage 23
2.1.1.1 Các dịch vụ ảo hóa VSD 24
2.1.1.2 Bộ điều khiển dịch vụ ả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 vụ 27
2.1.2 Giải pháp SDN củ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 dụng SDN mã nguồn mở 36
2.2.1 Giải pháp của Tungsten Fabric (TF) 36
2.2.2 Giải pháp của OpenDaylight (ODL) 37
2.2.3 So sánh giải pháp củ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 Mụ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
Trang 63.3.2.1 Cài đặt, tích hợp SDN controller 42
3.3.2.2 Công cụ 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 vụ 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 dụ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
Trang 7DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT
STT Ký hiệu/
1 ACL Access Control List (Danh sách điều khiển truy nhập)
2 API Application Programming Interface (Giao diện lập trình ứng
dụ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)
6 CAGR Compounded Annual Growth Rate (Tốc độ tăng trưởng hằng
năm ké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)
9 CSP Communication Service Provider (Các nhà cung cấp dịch vụ
truyền thông)
10 DHCP Dynamic Host Configuration Protocol (Giao thức cấu hình
máy chủ động)
11 DPI Deep Packet Inspection (Kiểm tra chuyên sâu gói tin)
12 FIB Forwarding Information Base (Cơ sở thông tin chuyển
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)
15 IF-MAP Interface for Metadata Access Points (Giao diện cho các điểm
truy cập siêu dữ liệu)
16 IP Internet Protocol (Giao thức Internet)
17 IPS Intrusion Prevention System (Hệ thống phòng chống xâm
nhập)
18 KVM Kernel-based Virtual Machine (Công nghệ ảo hóa phần cứng
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)
21 MPLS Multiprotocol Label Switching (Chuyển mạch nhãn đa giao
thức)
Trang 8STT Ký hiệu/
22 MPLSoGRE MPLS over Generic Routing Encapsulation (Giao thức đóng
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)
24 NFV Network functions virtualization (Công nghệ ảo hóa chức
năng mạng)
25 NFVI Network Functions Virtualization Infrastructure (Hạ tầng ảo
hóa chức năng mạng)
26 NGINX Máy chủ web kiến trúc đơn luồng, hướng sự kiện
27 ONF Open Networking Foundation (Tổ chức phát triển SDN thông
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ở
29 OPNFV Open Platform for NFV (Nền tảng mã nguồn mở cho Công
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)
33 OVSDB Open vSwitch Database Management Protocol (Giao thức
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 vụ)
35 RESTful
Ứng dụng sử dụng kiến trúc REST (REpresentational State Transfer - Chuyển trạng thái đại diện) là một chuẩn thiết kế API cho Web services
36 SDN Software Defined Networking (Mạng điều khiển bằng phần
mềm)
37 SROS Service Routing Operation System (Hệ điều hành định tuyến
dịch vụ)
38 TCP/IP Transmission Control Protocol/ Internet Protocol - Giao thức
điều khiển truyền nhận/ Giao thức liên mạng
39 UDP User Diagram Protocol (Giao thức truyền gói dữ liệu người
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)
Trang 9STT Ký hiệu/
44 VPLS Virtual Private LAN Service (Dịch vụ mạng LAN riêng ảo)
45 vPort Virtual Ports (Cổng giao tiếp ảo)
46 VRS Virtual Routing and Switching (Chuyển mạch và định tuyến
ảo)
47 VSC Virtualized Services Controller (Bộ điều khiển dịch vụ ảo)
48 VSD Nuage Virtualized Services Directory (Thư mục dịch vụ ảo
của Nuage)
49 VSG Virtualized Services Gateway (Cổng dịch vụ ảo)
50 VSN Virtualized Services Node (Node dịch vụ ảo)
51 VSP Virtualized Services Platform (Nền tảng dịch vụ ảo hóa)
52 VTEP VXLAN Tunnel endpoint (Điểm đầu/cuối của VXLAN
tunnel)
53 VXLAN Virtual Extensible LAN
54 XMPP Extensible Messaging and Presence Protocol (Giao thức mở
và dựa trên nền tảng XML dùng trong nhắn tin nhanh)
Trang 10DANH 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
Trang 11DANH 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 vụ 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 vụ ảo hóa VSD 24
Hình 2.3 – Bộ điều khiển dịch vụ ả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 cụ Skydive 45
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 đàn gia súc 47
Trang 12MỞ ĐẦ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 sẽ 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 dụ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 mục tiêu ảo hó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 sẽ tăng trưởng với tốc độ tăng trưởng ké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 vụ 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ử dụng các giao thức khác nhau, như OpenFlow hoặc các biến thể khác củ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 củ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 của các phân đoạn này Tuy nhiên, nhiều CSP vẫn đang theo dõi sự phát triển SDN, dự kiến sẽ 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 tục phát triển công nghệ SDN Cũng có một số cộng đồng mã nguồn mở phát triển phần mềm SDN theo cách riêng củ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 vụ không đầy đủ, 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 thủ và bảo mật củ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 dụng SDN quy mô lớn Bất chấp những rào cản này, các dịch vụ truyền thông đang tiến lên với việc triển khai SDN vì lợi ích của SDN vượt xa các vấn đề tiềm
ẩn nói trên
Việc nghiên cứu, ứng dụng công nghệ mới nó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 nói riêng luôn là thách thức mà đội ngũ kỹ 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 chủ công nghệ mới SDN là một trong những ứng dụ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 vụ 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 dụng và dịch vụ mạng Đây là hệ thống quan trọng mà đội ngũ kỹ thuật Viettel đã nghiên cứu, ứng dụ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
Trang 13triể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 dụ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 củ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 mụ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 dụ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 của hệ thống, các công nghệ, giao thức hoạt động trong quá trình vận hành củ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 dụng củ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 củ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 kỹ thuật phục vụ lộ trình ứng dụng trên mạng truyền tải
Mục đích nghiên cứu: Tìm hiểu khả năng ứng dụ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 của các hãng Nokia và Juniper
Giải pháp SDN mã nguồn mở Tungsten Fabric và OpenDayLight
Ứng dụng giải pháp trên mạng truyền tải trong các Telco Cloud Data Center
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 mục tiêu là hiểu được nền tảng cơ bản
Nghiên cứu giải pháp SDN của Nokia và Juniper với mục tiêu là hiểu và triển khai được công nghệ
Trang 14 Nghiên cứu giải pháp SDN mã nguồn mở Tungsten Fabric và OpenDayLight với mụ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 dụng
Tìm hiểu về các phần tử liên quan trên mạng lưới (thiết bị, ứng dụng trên mạng truyền tải hiện tại) với mục tiêu lựa chọn các testcase, đánh giá, lựa chọn giải pháp kỹ 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 có phục vụ cho việc đánh giá các testcase theo mụ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ị:
Chủ 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 của giải pháp; test thử nghiệm giải pháp củ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 mục tiêu xác định cụ thể như trên, kết quả của luận văn dự kiến sẽ đưa ra được lựa chọn giải pháp ứng dụ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 của giải pháp ứng dụng SDN cũng như tiềm năng và xu hướng triển khai củ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 dụng SDN củ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 dụng phù hợp củ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 dụ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 dụng hiệu quả trên diện rộng trong mạng truyền tải của Viettel, ngoài việc tối ưu lại hệ thống thì còn phải phát
Trang 15triể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 củ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, sẽ 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 đóng gó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 của đội dự án
Trang 16CHƯƠ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 có 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 khó 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 của các dịch vụ đám mây và nhu cầu phát triển của các nhà khai thác băng thông dịch vụ đư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à ở đó nhiệm vụ đ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 đó có thể tác động tới phần cứng, bộ nhớ và các chức năng của các thiết bị định tuyến (router), chuyển mạch (switch)
để đạt được mục đích của người sử dụng Do đó, mạng lưới trở nên linh hoạt hơn, hiệu suất sử dụ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 có 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 phép việc điều khiển mạng có 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 dụng và dịch vụ mạng
Một cách định nghĩa khác theo quan điểm củ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 phép khả năng lập trình của các phần tử mạng Do đó, các nhà cung cấp dịch vụ có 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 vụ 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 phé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
Trang 17Để hiểu rõ sự khác biệt giữa SDN và mạng truyền thống, chúng ta sẽ xem xét trên 2 khía cạnh: kiến trúc và tính năng củ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í dụ các chức năng củ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ỉ có nhiệm vụ chuyển tiếp gói tin do đó sự khác biệt giữa các nhà sản xuất sẽ 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 củ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 có khả năng truy cập và sử dụ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 dụ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
Có 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 cụ
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
Trang 18 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, nó đượ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 dụ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à thủ công Trong khi đối với SDN, mạng sẽ được lập trình bởi các ứng dụ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 có 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 đó dưới sự chỉ huy củ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 có thể lập trình cấu hình trên đó thay vì phải thực hiện thủ 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 dụng mới
và các dịch vụ mạng một cách nhanh chó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 phé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ử dụ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ử dụ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 dụng có thể lập trình trực tiếp mạng, trái ngược với việc sử dụng các giao thức được yêu cầu bởi mạng truyền thống
SDN cho phép người dùng sử dụng phần mềm để cung cấp các thiết bị mới thay vì
sử dụng cơ sở hạ tầng vật lý, do đó, quản trị viên có thể định tuyến đường truyền, lưu lượng cũng như chủ động lập lịch cho các dịch vụ mạng Không giống như các thiết bị chuyển mạch truyền thống, SDN còn có khả năng giao tiếp tốt hơn với các thiết bị sử dụng mạng
Ảo hó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 hóa toàn bộ mạng, nó sẽ tạo một bản sao của mạng vật lý và cho phé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ý của mặt phẳng điều khiển (nằm phân tán trên các thiết bị mạng) sẽ cản trở khả năng quản trị viên có thể kiểm soát luồng lưu lượng
Trang 19Với SDN, mặt phẳng điều khiển được xây dựng dựa trên phần mềm, cho phé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 phé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 phép người dùng kiểm soát tốt hơn cách thức hoạt động củ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 có 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ì nó cho phé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 có thể tó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 gõ 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 dụ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 sẽ liên kết
với nhau thông qua giao thức hoặc các API (Hình 1.2)
Lớp ứng dụ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 dụng API, cho phép lớp ứng dụng lập trình (cấu hình) mạng (ví dụ 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 của mạng lưới theo một yêu cầu cụ thể của người quản trị Ngoài ra, các ứng dụng sẽ đư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 mục đích ra quyết định Các ứng dụng này có thể bao gồm quản
lý mạng, phân tích hoặc các ứng dụng kinh doanh được sử dụng để chạy các trung tâm
Hình 1.2 - Kiến trúc SDN
Trang 20dữ liệu lớn Ví dụ: Một ứng dụng phân tích có thể được xây dựng để nhận ra hoạt động mạng đáng ngờ vì mụ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 hóa) thực hiện việc chuyển tiếp gói tin dưới sự điều khiển của Lớp điểu khiển Một thiết bị mạng có thể hoạt động theo sự điều khiển của nhiều controller khác nhau, điều này giúp tăng cường khả năng ảo hóa của mạng
Lớp điều khiển là trung tâm của kiến trúc mạng SDN Nó 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 Nó cung cấp một giao diện Northbound API cho việc giao tiếp với lớp ứng dụ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)
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 kỹ thuật bảo mật
SDN controller sử dụ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 có 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 có thể sử dụ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 sẽ phân tích tiềm năng của SDN trong tương lai bằng việc phân tích biểu
đồ Hype Cycle củ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 củ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 dụng SDN thành công và thất bại của các nhà cung cấp dịch vụ, 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 vụ 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)
Hình 1.3 - Lớp điều khiển SDN
Trang 21Các nhà cung cấp dịch vụ 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ử dụng trong triển khai SDN, chúng có thể được lập trình để sử dụng các giao thức khác nhau, như OpenFlow hoặc các biến thể khác củ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 củ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 của các phân đoạn này Tuy nhiên, nhiều CSP vẫn đang theo dõi sự phát triển SDN
và dự kiến sẽ 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 tục phát triển công nghệ SDN Cũng có một số cộng đồng mã nguồn mở phát triển phần mềm SDN theo cách riêng củ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 vụ không đầy đủ, 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 thủ và bảo mật củ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 dụng SDN quy mô lớn Bất chấp những rào cản này, các dịch vụ truyền thông đang tiến lên với việc triển khai SDN vì lợi ích của SDN vượt xa các vấn đề tiềm ẩn nói
trên
Theo khuyến nghị củ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 nó có 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 đề cụ thể bằng công nghệ SDN Trong ngắn hạn,
Hình 1.4 - Biểu đồ Hype Cycle cho vận hành cung cấp dịch vụ truyền thông 2019
Trang 22các CSP nên có đượ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 nó 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 có thể có tác động cơ bản đến các mối quan hệ củ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 của họ để hỗ trợ ảo hóa các chức năng mạng, họ nên đánh giá công nghệ SDN về khả năng ứng dụ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 của họ CSP có 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 có thể triển khai công nghệ SDN trong mạng truyền tải cáp quang thế hệ tiếp theo củ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 vụ SD-WAN sử dụ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 sẽ 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ử dụ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 hóa các thành phần điều khiển như AT&T đưa ra mục tiêu ảo hó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
Trang 23Global 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 sẽ 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 của các nhà cung cấp dịch vụ viễn thông để giải quyết các thách thức củ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 vụ 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 củ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 dụ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 củ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 dụng các công nghệ SDN Khung OpenFlow là tiêu chuẩn được sử dụng phổ biến nhất trong bối cảnh SDN Khung có 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 củ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 có Hơn nữa, việc chưa thể cung cấp khả năng điều khiển thiết bị đầy đủ (đ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 của thị trường SDN
Trang 24CHƯƠ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 của các hãng, giải pháp mã nguồn mở từ đó đư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ề kỹ 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ư có cái nhìn khách quan trong xu thế phát triển chung của giải pháp ứng dụng này trên thế giới Bản thân tác giả là người chủ 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 của dự án Trong phần này, tác giả sẽ 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 dụng SDN củ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 củ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 vụ ảo hóa VSP [6] VSP thực hiện việc triển khai, xử lý các mặt phẳng của mô hình SDN như sau:
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 của Nokia, nó định nghĩa và giám sát các policy củ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 của các VM truy nhập vào các
Hình 2.1 - Kiến trúc hệ thống Nuage Nokia
Trang 25Hypervisor 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 rõ ràng và đưa xuống VRS
Mặt phẳng dữ liệu: Virtual Routing and Switching (VRS) thực hiện đó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 hóa chính:
VSD (Thư mục dịch vụ ảo): chứa các chuẩn dịch vụ mạng và chính sách
VSC (Bộ điều khiển dịch vụ ả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 chủ
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 vụ 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ử dụ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ử dụ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 chủ 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 vụ bằng cách xác định nhóm dịch vụ mạng (hình 2.2)
Hình 2.2 - Các dịch vụ ảo hóa VSD
Trang 26Định nghĩa dịch vụ bao gồm Domain, Zone, Subnet, Policy templates Một Domain Templates cũng có thể bao gồm các chính sách (ví dụ: chuyển tiếp, QoS, …) được áp dụng ở các mức khác nhau (vPort, Subnet, Zone, Domain) VSD sử dụng giao thức XMPP để giao tiếp với VSC VSD cũng chứa một công cụ phân tích mạnh mẽ (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ý của nhà cung cấp đám mây dịch vụ
Cá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 có thể giao tiếp với nhau Người dùng CSP Root có thể tạo domain cho tất cả các doanh nghiệp Người dùng nhóm quản trị viên và người vận hành mạng có thể tạo domain cho doanh nghiệp củ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 Có 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, nó hoạt động sao cho tất cả các điểm cuối trong Zone tuân thủ 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 cụ thể Mạng con này được khởi tạo như một dịch vụ 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 phé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 nó tồn tại trên hypervisor hoặc Gateway Các cổng kết nối máy chủ Bare Metal với lớp Overlay cũng được gọi là vPort
Một số thành phần của VSD:
Công cụ quản lý chính sách (Policy Management DB)
VSD mediator: Là một giao diện hướng nam của VSD được sử dụ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 chủ XMPP hoặc các cụm máy chủ
Công cụ 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 vụ ảo hóa VSC đó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ử dụ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ế
Trang 27độ chờ (VRS có 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ử dụng cổng TCP 6633 và nó được sử dụ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, đóng gói trong OVA (vCenter) hoặc QCOW2 (KVM) VSC có giao diện điều khiển được kết nối với lớp Underlay Nó dựa trên hệ điều hành định tuyến dịch vụ 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, có 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 có 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 của mô hình SDN, thực hiện chuyển tiếp, đóng gói mở gó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ử dụ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
Trang 28- Nuage Networks sử dụ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ử dụng để cấu hình vSwitch Được sử dụng cho Linux Network và là một phần của Linux Kernel
- Mạng Overlay: Ảo hóa trên cơ sở hạ tầng mạng vật lý Các máy chủ không biết về lớp phủ 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ữ của nó thuộc về Để thực hiện việc này, VTEP sẽ được chỉ định một địa chỉ MAC và địa chỉ IP trong mỗi mạng con đó
- 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 có 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 vụ ảo, bao gồm 1 VSC và nhó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)
Trang 29Hình 2.5 – Cơ chế làm việc chính sách bảo mật
- Ví dụ: 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 chủ 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 chủ 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 đó có 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 vụ 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 vụ Nuage hỗ trợ thiết bị/cụ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 có khả năng mở rộng lớn Các mạng ảo giúp chúng ta có khả năng khai thác đám mây cho các ứng dụng và dịch vụ mạng Contrail là một mô hình giải pháp mạng mã nguồn mở có 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 đề khó khăn của mạng Private và Public cloud [8]
Contrail có 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 đề của mạng một cách tự động Với kiến trúc của Contrail có 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,
Trang 30load 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 Nó cho phé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 có thông tin trạng thái của máy ảo, khách hàng, ứng dụng mà chỉ tham gia vào việc định tuyến lưu lượng từ một máy chủ sang máy chủ khác Hệ thống contrail sẽ giải quyết vấn đề một cách linh hoạt, cho phép tự động hóa dịch vụ 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 đóng vai trò là các thiết bị chuyển mạch mềm được triển khai trên hypervisor của các máy chủ ảo đa chức năng Contrail SDN Controller cung cấp giao diện northbound REST API được sử dụng cho lớp ứng dụng để mở rộng hệ thống điều phối
đám mây Được sử dụng bởi Openstack thông qua Neutron, OSS/BSS hoặc GUI (Hình
2.6)
Hệ thống Contrail cung cấp 3 giao diện interface Northbound REST API được
sử dụng giao tiếp giữa hệ thống điều phối và các ứng dụng Southbound interface được
sử dụ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ử dụng để kết nối với các Controller khác East-West interface là chuẩn BGP XMPP là southbound
Hình 2.6 – Kiến trúc Contrail - Juniper
Trang 31interface cho Contrail vRouter BGP và NETCONF là southbound interface củ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).
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 dụng có thể sử dụng Analytics node giao tiếp với các ứng dụng sử dụng giao diện phía bắc REST API, với các analytics node khác sử dụng các kỹ 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 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 cụ thể
Hình 2.7 – Contrail SDN controller
Trang 32 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
kỹ 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 Hình 2.8 - Analytics Node
Trang 33Configuration node cung cấp dịch vụ Discovery cho khách hàng sử dụng có thể định
vị các nhà cung cấp dịch vụ Ví dụ khi vRouter agent trong compute node kết nối với một control node Nó sử dụng dịch vụ Discovery để khám phá địa chỉ IP của các control node Máy khách có thể dử dụng để cấu hình cục bộ DHCP hoặc SDN để xác định vị trí củ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 đó 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ử dụ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ử dụng BGP và cũng có thể gửi trạng thái cấu hình sử dụ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, đó là: Computer Node, Gateway node và Service node:
Trang 34 Compute node là các server ảo hóa lưu trữ các VM Các VM này có thể sử dụng để
cho thuê chạy các ứng dụng hoặc có thể là các máy ảo dịch vụ chạy các dịch vụ 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 củ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 Nó chịu
trách nhiệm chuyển tiếp các gó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 dụng cá nhân như Web server, database server, các ứng
dụng doanh nghiệp hoặc các dịch vụ ảo để tạo chuỗi dịch vụ 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 cụ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ử dụ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 củ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 Đóng gói mở gó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
Trang 35o 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 Nó 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 gói tin đúng tới đích Việc định tuyến có thể thực hiện ở Layer 3 IP hoặc Layer 2 MAC
o Các chính sách chuyển tiếp có thể được ứng dụng cho các flow table
o Match các gói tin với flow table và ứng dụng các flow action
o Gửi các gó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 gó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à đóng gó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à có 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 vụ mạng như DPI,
IDP, IPS, tối ưu WAN và cân bằng tải Chuỗi dịch vụ có thể bao gồm nhiều dịch vụ ảo như triển khai VM trong compute node và dịch vụ vật lý như lưu trữ trên các node dịch
IF-MAP cung cấp giao diện giữa Metadata Access Point (MAPs), một database server đó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 của kiến trúc kết nối mạng đáng tin cậy
IF-MAP cung cấp các kỹ 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ử dụ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ử dụ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ử dụ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
Trang 36 Contrail sử dụ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ử dụ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 củ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 của 2 nhà cung cấp Juniper (Contrail) và Nokia (Nuage) có thể đưa ra một số nhận định và lợi ích nổi bật, cụ thể như sau:
- Với việc sử dụ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 vụ, 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 chóng đưa dịch vụ đến khách hàng
- Các tác vụ trong quản lý, vận hành hệ thống thực hiện tập trung và được đơn giản hó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 hóa để có 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 rõ ưu/nhược điểm của từng giải pháp, ta đưa ra bảng so sánh chi tiết trong bảng sau:
- Kết quả test case: tốt
- Triển khai end to end trong DC: tốt
- Nuage hỗ trợ giao thức VXLAN, MPLSL3, L2VPNS, GRE, BGP
- Contrail hỗ trợ mạnh mẽ cho Openstack và ảo hóa dựa trên container: Kubernetes và Openshift
- Contrail hỗ trợ giao thức VXLAN, MPLSL3, L2VPNS, GRE, BGP
Trang 37Giải pháp Nuage Nokia Contrail Juniper
- VSC hỗ trợ một số bộ chuyển mạch vật lý từ Arista, DELL, HPE, Nokia và bare metal network (VRS-G)
- Công cụ chính sách mạnh mẽ dựa trên
hệ thống quản lý bảo mật
- Contrail có thể cấu hình mạng vật lý của Juniper để hỗ trợ kết nối giữa SDN và các mạng ngoài
Hạn chế
-VSC không kết hợp với NSX của Vmware cho VTEP hoặc các bộ chuyển mạch phân tán của Vmware
- Cạnh tranh trực tiếp với Cisco và Vmware trong DC SDN
- Hệ sinh thái trung tâm dữ liệu không
đa dạng
- Thị trường hạn chế
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 của Juniper và Nuage của Nokia cho Telco Cloud Data Center có rất nhiều ưu điểm nổi bật, phù hợp với nhu cầu của mạng truyền tải của hầu hết các nhà cung cấp dịch vụ 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 vụ 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 xé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 củ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 củ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, nhó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ử dụng củ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 củ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 hó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, nó được thiết kế phục vụ cho mạng đa người dùng trong môi trường lớn, sử dụ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 vụ mạng ảo và không ảo tới các mạng ảo thông qua một Gateway router
Trang 38 Service chaining: Điểu khiển lưu lượng tự động đi qua các chuỗi dịch vụ 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ã hó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 của các phần
tử củ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 dụ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 đó 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 dụng có thể sử dụng
Bên cạnh vRouter đóng vai trò là các thiết bị chuyển mạch mềm được triển khai trên hypervisor của các máy chủ ả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 hóa
và tự dộng hó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 đã có 10 bản phát hành, là Open source SDN controller được sử dụ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 dụng của các hãng như XNC của Cisco, SDN controller của ADVA…
Nền tảng ODL được xây dựng để cho phép người dùng, nhà cung cung cấp giải pháp có thể tự xây dựng Controller một cách linh hoạt nhất phụ thuộc vào nhu cầu củ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 vụ mong muốn
Trang 39 Có thể kết hợp nhiều giao thức và dịch vụ để 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 dụng một nền tảng chung được chia sẻ
OpenDayLight hỗ trợ người dùng:
Phân phối dịch vụ tự động: Cung cấp các dịch vụ on-demand được điều khiển bằng end user và service provider ví dụ như lên lịch băng thông, dịch vụ VPN tự động…
Cloud và NFV: Phân phối dịch vụ 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 vụ 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 tụ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 của SDN (Hình 2.12):
- Network Apps & Orchestration: Là lớp trên cùng của giải pháp bao gồm các ứng
dụ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 dụ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 dụng NFV
- Controller Platform: Lớp thứ hai của giải pháp, nó cung cấp nhiều API phổ biến để
giao tiếp với lớp ứng dụng/Orchestrator Nó cũng có 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 phục vụ việc quản lý, giám sát, cấu hình các thiết bị mạng
Hình 2.12 - Kiến trúc OpenDayLight
Trang 40- Physical & Virtual Network Devices: Là lớp cuối cùng củ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ế của 2 giải pháp cơ bản như sau:
- Đánh giá Tungsten Fabric:
+ Tungsten Fabric hỗ trợ giao diện quản lý Trên giao diện Web UI của Tungsten Fabric cung cấp đủ 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… củ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 của hãng
- Đánh giá 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à sẽ 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 vụ 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á có 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ở của Tungsten Fabric trên hạ tầng Cloud hiện có sẽ được trình bày chi tiết tại Chương 3 của luận văn