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 đó 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 của các hãng khác.
Hệ thống SDN sử dụng mã nguồn mở đã phát triển được tính năng cho phép tích hợp với các cụm Cloud đang cung cấp dịch vụ, ứng dụ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 cụm Cloud mới.
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 phụ 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 củ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 cụm Cloud có quy mô 125 Compute
host (tương đương cụ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 đó chi phí nghiên cứu, phát triển giải pháp SDN sử dụ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 rủi ro, đặc biệt như đã thấy rõ 4 điểm hạn chế được chỉ ra trong phần đánh giá giải pháp tại mụ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 phục. Với ưu điểm củ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 sẽ 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 của các nhà cung cấp dịch vụ viễn thông và CNTT hiện nay.
KẾT LUẬN
Những đóng góp của luận văn:
Với mụ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 dụng SDN đến phân tích đánh giá giải pháp củ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 dụ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 dụng SDN. - Nêu được phương pháp, các giai đoạn triển khai giải pháp ứng dụ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, rủi ro khi mở rộng (hạ tầng cụm triển khai sử dụ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 tục khắc phụ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 dụng cung cấp các dịch vụ 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; …).
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
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)
8 Virtual IP tracking for clustering Monitor ability of traffic to track a VIP or cluster address that moves between VMs on a layer 2 network
9 Service Function Chaining (SFC)
10 TF metadata agent 11 Security groups (adsbygoogle = window.adsbygoogle || []).push({});
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
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 củ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 sẽ nhận IP cấp tự động từ DHCP Kết quả:
Enable feature DHCP trên Network, tạo VM mới, VM sẽ tự động nhận IP DHCP
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ả:
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ả:
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ả:
Testcase Service function chaining (SFC)
Trạng thái Pass (adsbygoogle = window.adsbygoogle || []).push({});
Yêu cầu: Tạo chuỗi dịch vụ 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ả:
Khi Launch instance, trong mục Metadata có thể tùy chọn package để cài đặt vào VM
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 đó thuộc Security group nào
Kết quả:
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
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ả:
Testcase SNAT to underlay (PAT)
Trạng thái Pass Yêu cầu:
Kết quả:
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 thủ công bằng Script, sau khi sử dụng Script chuỗi dịch vụ được tạo tự động, traffic được điều hướng theo yêu cầu.
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 (adsbygoogle = window.adsbygoogle || []).push({});
Trạng thái Chưa Pass
Yêu cầu: Tạo QoS cho dịch vụ
Kết quả: thực hiện cấu hình trên giao diện tuy nhiên, QoS không khả dụng, cần tìm hiểu thêm.
Testcase Statistics retrieval
Trạng thái Pass
Yêu cầu: Truy xuất thông tin trên giao diện của hệ thống Yêu cầu:
Kết quả:
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ả:
Testcase Virtual to Physical VLAN interworking through TOR (Switch L3
cissco) Trạng thái Chưa Pass
Yêu cầu: thông kết nối từ VM sử dụ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
Testcase Throughput performance test Trạng thái Pass
Yêu cầu: Thoughput giữa các compute Kết quả:
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 củ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 sẽ 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ả:
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 của các network cần kết nối vào router
Testcase Delete VM (adsbygoogle = window.adsbygoogle || []).push({});
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
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ả:
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ả:
Testcase Service function chaining (SFC) Trạng thái Fail
Yêu cầu: Tạo chuỗi dịch vụ 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ả:
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 đó thuộc Security group nào
Kết quả:
Chọn create security group
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 (adsbygoogle = window.adsbygoogle || []).push({});
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ả:
Testcase QoS – rate limiting Trạng thái fail
Mô tả: Tạo QoS cho dịch vụ 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 của hệ thống Kết quả:
Testcase Threshold Crossing Alerts Trạng thái Fail
Yêu cầu: Kết quả:
Testcase Virtual to Physical VLAN interworking through TOR (Switch L3
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ả:
ĐẠ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
Hà Nội, ngày thá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ệ đã có 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 Hó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 (có biên bản kèm theo). Theo Quyết nghị củ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 phục một số lỗi trình bày do Hội đồng đã chỉ ra, cụ thể như sau: - Các tiểu mụ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 vẽ, bảng cũng nên đánh theo chương cho tiện theo dõ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ử dụng một hình vẽ (Chương 2 – Tiểu mục 2.2.1: trang 36).
2. Phần thử nghiệm cần trình bày rõ 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 rõ đóng góp của mình (Phần Mở đầu: trang 12). 4. Trong luận văn có nêu sử dụng nguồn mở cho SDN có ưu điểm là giảm chi
phí đến 80% và không phụ thuộc vào hãng cung cấp. Điều này có thực sự là ưu điểm hay không? Nhược điểm của việc sử dụng nguồn mở là gì?
(Chương 3- Tiểu mục 3.5: trang 45, 46 và Tiểu mục 3.8: trang 48, 49). 5. Bổ sung mục tiêu thử nghiệm giải pháp mã nguồn mở tự phát triển (Chương
3 – Tiểu mục 3.1: trang 39).
6. Xem xét triển khai backup 1+1 đối với SDN controller (Phần Kết luận: trang 50). (adsbygoogle = window.adsbygoogle || []).push({});
Ngày 21 tháng 7 năm 2021, học viên đã nộp bản luận văn có chỉnh sửa. Chúng tôi nhận thấy rằng nội dung, hình thức của luận văn và tóm tắt luận văn đã được sửa chữa, bổ sung theo các điểm trên của Quyết nghị.
Đề nghị Trường Đại học Công nghệ, ĐHQG HN cho phép học viên được làm các thủ tụ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