So Sánh Các Tính Năng Sdn Opensource Với Truyền Thống

STT

Tiêu chí

Truyền thống

SDN controller

2

Hỗ trợ VxLan

Hiệu năng thấp, sử

dụng VLAN

Hiệu năng cao

3

Hỗ trợ quản lý Multi platform

Không hỗ trợ

Hỗ trợ nhiều Platform khác nhau (Openstack, Vmware,

K8s..)

4

Quản lý các hạ tầng phân tán

Không hỗ trợ

5

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

Không hỗ trợ

6

Service function Chain

Không hỗ trợ

Hỗ trợ đối với cả VNF và PNF

7

Giám sát, tự động xây dựng Topology quản lý tập trung hạ tầng Overlay và Underlay

Không hỗ trợ

8

Quản lý và cấu hình tự động thiết bị mạng của nhiều hãng

Không hỗ trợ

Có thể bạn quan tâm!

Xem toàn bộ 48 trang tài liệu này.

Bảng 3.2 - Đánh giá 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 vụ đ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 đó là cho phé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 vụ 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 vụ.

Tuy nhiên, trong quá trình triển khai hệ thống, giải pháp SDN mã nguồn mở củ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ử dụ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 hó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 khó 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 của OpenStack (~6 tháng/lần).

- Do sử dụ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 tụ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 phụ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ử dụ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 mục 3.5, nó còn cho phé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 có 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 có, có 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.

Cụ thể, đối với mô hình 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 (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 1

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

nghiệm của luận văn này có 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 cụ mô hình hóa lan truyền bệnh dịch (khối III) với nhiệm vụ 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

mây theo nhu cầu cho các công cụ và chương trình ứng dụng kỹ thuật tự động hóa của điện toán tự trị.

Phương pháp nghiên cứu triển khai sẽ sử dụ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 phóng tài nguyên hiện có (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 có (theo chiều dọc). Phương pháp này có thể được thực hiện dễ dàng trên giao diện của SDN controller với việc tạo/mở rộng/thu hẹp tài nguyên của các máy ảo (VM) trên hạ tầng Cloud hiện có phục vụ nhu cầu tài nguyên tính toán linh hoạt.

Dịch vụ củ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 cụ mô phỏng của toàn hệ thống với việc chạy thử nghiệm kết hợp các công cụ mô hình hó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 cụ 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í củ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

Để có được nhận định cụ thể về những ưu/nhược điểm củ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 của các testcase này sẽ 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.

Cụ thể kết quả đánh giá tính năng tại Bảng 3.4:

STT

Tiêu chí

Truyền thống

Sau khi tích hợp SDN controller

1

Upload glance image

2

Create/Delete VM

3

Reboot/Shutdown/Start VM

4

Rename/Resize/Rebuild VM

5

Access to console

6

Snapshot VM

7

Manage keypair

8

Migrate VM

9

Live Migrate VM

10

Launch VM from Snapshot

11

Manage Data volume

12

Manage boot volume

13

Manage volume backup

14

Manage volume snapshot

15

Save image from volume

16

Manage Provider network

STT

Tiêu chí

Truyền thống

Sau khi tích hợp SDN controller

17

Manage Self-service network

18

Manage Router

19

Manage port

20

Manage activity of Server/Switch/VM/Service/Component

on the Dashboard

21

Hỗ trợ VxLan

Ít sử dụng

Hiệu năng cao

22

Hỗ trợ Multi-platform

Không hỗ trợ

Hỗ trợ nhiều Platform khác nhau (Openstack,

Vmware, Kubernet…)

23

Quản lý các hạ tầng phân tán

Không hỗ trợ

24

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

Không hỗ trợ

25

Service function Chain

Không hỗ trợ

Hỗ trợ đối với cả VNF và

PNF

26

Giám sát, tự động xây dựng Topology quản lý tập trung hạ tầng Overlay và

Underlay

Không hỗ trợ

27

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

mạng của nhiều hãng

Không hỗ trợ

Bảng 3.3 - Đánh giá 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 đó chính là SDN có khả năng điểu khiển lưu lượng tự động đi qua các chuỗi dịch vụ (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 đó 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

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

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 2Testcase VM interface configuration with DHCP Trạng thái Pass Yêu cầu Khi tạo VM mới VM 3

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

54

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 4

Testcase Inter VMs connectivity Trạng thái Pass Yêu cầu Các VM có thể Ping thông tới 5

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 Testcase Delete VM Trạng thái Pass Yêu cầu Có thể Xóa VM Kết quả Testcase VM 6

55 Testcase Delete VM Trạng thái Pass Yêu cầu Có thể Xóa VM Kết quả Testcase VM 7

55

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 Testcase Virtual IP Trạng thái Pass Yêu cầu Thiết lập Virtual IP cho các VM backup 8

56 Testcase Virtual IP Trạng thái Pass Yêu cầu Thiết lập Virtual IP cho các VM backup 9

56

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

Testcase

Service function chaining (SFC)

Trạng thái

Pass

Yêu cầu: Tạo chuỗi dịch vụ liền mạch, cấu hình tự động

Kết quả:

58

59

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

Khi Launch instance trong mục Metadata có thể tùy chọn package để cài đặt vào VM 10

60

Xem tất cả 48 trang.

Ngày đăng: 15/04/2022