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.
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:
Để 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:
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.
