MỘT SỐ GIẢI PHÁP SDN - - VnPro

MỘT SỐ GIẢI PHÁP SDN

Phần thứ hai giới thiệu ba giải pháp lập trình mạng SDN.

• Bộ điều khiển OpenDaylight
• ACI
• APIC-EM

OpenDaylight và OpenFlow

Một hình thức phổ biến của SDN đến từ Open Networking Foundation (ONF) và được gọi là Open SDN. Mô hình Open SDN tập trung hầu hết các chức năng của control plane.

Điều khiển OpenDaylight

Bộ điều khiển SDN nguồn mở OpenDaylight là một trong những nền tảng bộ điều khiển SDN thành công xuất hiện trong những năm 2010. OpenDaylight đã sử dụng nhiều nguyên tắc nguồn mở giống nhau được sử dụng với Linux, với ý tưởng rằng nếu có đủ các nhà cung cấp làm việc cùng nhau trên một bộ điều khiển nguồn mở chung, thì tất cả sẽ có lợi. Tất cả các nhà cung cấp sau đó có thể sử dụng bộ điều khiển nguồn mở làm cơ sở cho các sản phẩm của riêng họ, với mỗi nhà cung cấp tập trung vào phần khác biệt của sản phẩm, hơn là các tính năng cơ bản. Kết quả là vào giữa những năm 2010, bộ điều khiển SDN OpenDaylight (www.opendaylight.org) đã ra đời. OpenDaylight (ODL) bắt đầu như một dự án riêng biệt nhưng bây giờ tồn tại dưới dạng một dự án được quản lý bởi Linux Foundation.

Hình 16-8 cho thấy một phiên bản tổng quát của kiến ​​trúc ODL. Cụ thể, lưu ý nhiều loại SBI được liệt kê: OpenFlow, NetConf, PCEP, BGP-LS và OVSDB.

Cisco ACI

Thật thú vị, nhiều dịch vụ SDN đã bắt đầu với nghiên cứu loại bỏ nhiều mô hình mạng cũ trong nỗ lực tạo ra một cái gì đó mới và tốt hơn. Ví dụ, OpenFlow đến từ dự án nghiên cứu Clean Slate của Đại học Stanford. Cisco đã thực hiện một lộ trình nghiên cứu tương tự, nhưng công việc của Cisco đã phát sinh từ các nhóm khác nhau, mỗi nhóm tập trung vào các phần khác nhau của mạng: trung tâm dữ liệu, campus và mạng WAN. Các nghiên cứu đó đã dẫn đến việc ra đời các kiến truc ACI trong trung tâm dữ liệu, SDA trong campus doanh nghiệp và SD-WAN trong mạng doanh nghiệp.

Khi mô phỏng lại mạng cho trung tâm dữ liệu, các nhà thiết kế đã tập trung vào các ứng dụng chạy trong trung tâm dữ liệu và những gì họ cần. Kết quả là, họ đã xây dựng các khái niệm mạng xung quanh các kiến ​​trúc ứng dụng. ACI thiết lập để tạo kết nối mạng trung tâm dữ liệu với tính linh hoạt và tự động hóa được tích hợp trong mô hình hoạt động.

Thiết kế vật lý ACI: Spine and Leaf

Cisco ACI sử dụng một cấu trúc liên kết chuyển đổi vật lý cụ thể được gọi là spine and leaf. Mặc dù các phần khác của mạng có thể cần cho phép nhiều cấu trúc liên kết vật lý khác nhau, trung tâm dữ liệu có thể được tạo thành tiêu chuẩn và nhất quán. Nhưng những cấu trúc liên kết tiêu chuẩn và nhất quán nào?

Hình 16-9 Sơ đồ thiết kế mạng Spine - Leaf

Tất cả các điểm đầu cuối đó đều không kết nối với các switch chính (spine) mà chỉ duy nhất kết nối các con Switch phụ (leaf).

Hình 16-10 Các điểm đầu cuối được tìm thấy duy nhất trên các con switch leaf

Mô hình mà Cisco định nghĩa cho ACI bằng việc sử dụng các khái niệm về các điểm đầu cuối (endpoints) và chính sách (policies). Các điểm đầu cuối (endpoints) là các máy ảo, bộ lưu trữ, hoặc có thể là các server truyền thống chạy trực tiếp HĐH trên thiết bị phần cứng. ACI hiện sử dụng một số cấu trúc cụ thể như thực hiện thông qua the Application Policy Infrastructure Controller (APIC), các phần mềm sử dụng như bộ điều khiển trung tâm cho ACI.

Trong phần này hi vọng sẽ giúp bạn hiểu được một số khái niệm tổng quan bên trong ACI, hơn là phải tiếp xúc với tất cả các tính năng. Để làm được điều đó hãy xem lại một tí về các kiến trúc ứng dụng của các ứng dụng web thường thấy của doanh nghiệp. Phần lớn những người quan sát thông thường sẽ nghĩ là các ứng dụng web chỉ có một thực thể, nhưng một ứng dụng web thường tồn tại như là ba server riêng biệt:

• Web server: người dùng từ bên ngoài data center kết nối tới web server thì web server sẽ gửi các nội dụng của trang web đó tới cho người dùng.
• App (Application) server: phần lớn các trang web chứa các nội dung động, các App server sẽ thực hiện quá trình xây dựng trang web tiếp theo cho các người dùng cụ thể dựa trên thông tin của người dùng và các hoạt động, nhập liệu mới nhất.
• DB (Database) server: rất nhiều các hoạt động của app server yêu cầu dữ liệu; DB server khôi phục và lưu trữ các dữ liệu theo yêu cầu của app server.

Để hiểu các định nghĩa trên, ACI sử dụng mô hình intent-based networking (IBN). Với mô hình đó, các kĩ sư hoặc các chương trình tự động hóa, định nghĩa các chính sách và yêu cầu cho các điểm đầu cuối nào được phép giao tiếp còn điểm đầu cuối nào không được phép. Sau đó bộ điều khiển sẽ xác định các điểm cần thiết cho mạng này ngay lập tức phụ thuộc vào vị trí của các điểm đầu cuối lúc đó.

Ví dụ, khi khởi động các máy ảo cho ứng dụng này, phần mềm ảo hóa có thể tạo ra (thông qua APIC) một số endpoint groups (EPGs) được thể hiện ở hình 16-11. Bộ điều khiển đồng thời phải chỉ ra các chính sách cần thiết để truy cập để chỉ ra EPGs nào có thể giao tiếp (và EPGs nào không được phép) có thể hiểu hình bằng các dòng mũi tên. Ví dụ, Router kết nối với mạng nằm bên ngoài data center nên được có khả năng gửi các gói tin đến tất cả web servers nhưng không được đến các app server hoặc các DB server.

Hình 16-11 Endpoint Groups (EGPS) và các chính sách (Policies)

Để mọi thứ hoạt động, ACI sử dụng bộ điều khiển trung tâm được gọi là the Application Policy Infrastructure Controller (APIC), để thể hiện ở hình 16-12. Trong trường hợp này chính cái tên đã định nghĩa chức năng: là bộ điều khiển tạo ra các chính sách ứng dụng cho các cơ sở hạ tầng của data center. APIC nhận các yêu cầu (EPGs, các chính sách, v.v) làm thay đổi hoàn toàn các mô hình vận hành từ cách cấu hình VLANs, trunks, EtherChannels, ACLs, v.v.

Hình 16-12 Góc nhìn cấu trúc của ACI với APIC đẩy các yêu cầu tới Switch Control Plane

Dĩ nhiên, APIC có giao diện GUI tiện lợi nhưng sức mạnh tới từ phần mềm điều khiển, đó chính là khả năng lập trình của mạng. Phần mềm ảo hóa giống nhau hoặc là phần mềm đám mây hoặc phần mềm tự động hóa, dù chương trình được viết bởi kĩ sư mạng đều có thể định nghĩa các endpoint groups, các chính sách (policies) đến được với APIC. Nhưng tất cả người dùng truy cập vào hệ thống ACI bằng cách kết nối đến với APIC như được miêu tả ở hình 16-13: kĩ sư mạng không còn phải kết nối tới từng switch và cấu hình bằng CLI commands nữa.

Hình 16-13 Điều khiển ACI Data Center Network bằng cách sử dụng APIC

Ví dụ tiếp theo của giải pháp Cisco SDN trong mục này được gọi là APIC Enterprise Module (APIC-EM) để giải quyết các vấn đề khác nhau.

Lợi ích của việc kiến trúc controller-based mang lợi là gì nếu các thiết bị trong mạng lưới không có tính năng nào mới? Thêm vào bộ điều khiển trung tâm với northbound APIs toàn diện mở ra nhiều khả năng cho khách hàng/người vận hành đồng thời cũng tạo ra thế giới mà ở đó Cisco và đối tác có thể mang đến những ứng dụng quản lí mới mẻ và thú vị đến với thị trường. Nó bao gồm các ứng dụng sao được miêu tả ở hình 16-14:

• Topology map: ứng dụng sẽ khám phá và hiển thị các topology của mạng lưới
• Path Trace: người dùng cung cấp thiết bị nguồn và thiết bị đích đến và các ứng dụng chỉ ra đường đi thông qua mạng lưới kèm theo đó là các thông tin chi tiết về quyết định forwarding trong từng bước
• Plug and Play: các ứng dụng cung cấp Day 0 installation hỗ trợ vì thế người dùng có thể mở hộp các thiết bị mới và thiết lập IP thông qua hệ thống tự động hóa trong bộ điều khiển
• Easy QoS: với một vài quyết định cơ bản ở bộ điều khiển, người dùng có thể cấu hình tính năng QoS phức tạp ở từng thiết bị

Hình 16-14 APIC-EM Controller Model

APIC – EM không lập trình trực tiếp luồng dữ liệu hoặc control planes nhưng nó tương tác với management plane thông qua Telnet, SSH, và/ hoặc là SNMP, kết quả là APIC – EM không tác động trực tiếp lên luồng dữ liệu và control planes. Bộ điều khiển APIC – EM không lập trình luồng dữ liệu vào bảng hoặc yêu cầu control plane trong các thiết bị thay đổi cách các thiết bị vận hành. Nhưng nó có thể hỏi và học trạng thái cấu hình và trạng thái vận hành của từng thiết bị và nó có thể cấu hình lại từng thiết bị vì thế thay đổi cách hoạt động của control và data plane đã được phân bố.

Bảng 16-2 Bảng so sánh về OpenFlow, ACI và APIC Enterprise

Nội dung tiêu chí	OpenFlow	ACI	APIC Enterprise
Thay đổi cách the control plan thiết bị hoạt động với mạng truyền thống	Có	Có	Không
Tạo ra các điểm tập trung từ chỗ người dùng và các thiết bị tự động hóa điều khiển mạng	Có	Có	Có
Xếp hạng kiến trúc tập trung the control plane	Hầu như	Một phần	Không có
Sử dụng SBIs	OpenFlow	OpFlex	CLI, SNMP
Bộ điều khiển đề cập trong chương này	OpenDaylight	APIC	APIC – EM
Tổ chức là nhà sở hữu chính	ONF	Cisco	Cisco

Nếu bạn muốn học thêm về các giải pháp của Cisco, ví dụ như sử dụng cả Cisco DevNet (the Cisco Developer Network) và dCloud (Demo cloud). Cisco cung cấp trang về DevNet (https://developer.cisco.com) cho những ai hứng thú với lập trình mạng, và trang về Demo Cloud (https://dcloud.cisco.com) cho những ai muốn trải nghiệp hoặc chạy thử các sản phẩm Cisco. DevNet đã có rất nhiều lab về APIC – EM, trong khi cả 2 trang về DevNet và DemoCloud đều có rất nhiều bài labs sử dụng ACI làm nền.

Thông tin khác

• » CÁC THÀNH PHẦN TRONG CISCO SD-WAN (16.02.2021)
• » Giới thiệu về Mạng dựa trên controller (16.02.2021)
• » LAB 8: VIẾT POLICY HUB AND SPOKE TRONG CISCO SD-WAN (14.02.2021)
• » GIỚI THIỆU VỀ CISCO SD-WAN (10.02.2021)
• » LAB 7: VIẾT POLICY NAT CHO SERVICE VPN VỚI CENTRALIZED DATA POLICY (05.02.2021)
• » LAB 6: VIẾT TEMPLATE CẤU HÌNH OSPF CHO vEDGE TRONG CISCO SD-WAN (03.02.2021)
• » LAB 5: VIẾT CÁC TEMPLATE CƠ BẢN CHO VSMART VÀ ĐẨY CẤU HÌNH CHO VSMART (01.02.2021)
• » LAB 4: VIẾT CÁC TEMPLATE CƠ BẢN CHO VEDGE VÀ ĐẨY CẤU HÌNH CHO CÁC WAN VEDGE (28.01.2021)