CHƢƠNG 2 GIỚI THIỆU OPENSTACK VÀ OPENVSWITCH
2.2 OpenvSwitch
2.2.4 SoftwareDefined Network (SDN)
Nhiều công ty trực tuyến và đám mây lớn đang chuyển các trung tâm dữ liệu của họ sang ảo hóa để có đƣợc lợi ích từ QoS và khả năng dự đoán. Tƣơng tự nhƣ vậy, mạng có độ an toàn cao và chi phí thấp là rất quan trọng. Do đó, các nhà cung cấp dịch vụ và các công ty mạng cần một giải pháp thay thế để sử dụng một cách thông minh và hiệu quả. SDN, còn đƣợc gọi là Software Defined Network đƣợc phát triển, nó là công nghệ mạnh mẽ có khả năng xử lý các ứng dụng thông minh cũng nhƣ nên tảng phát triển mạnh mẽ cho các mạng trong tƣơng lai đồng thời giảm chi phí vận hành chỉ bằng cách thay đổi phần cứng và phần mềm, tăng cƣờng và đơn giản hóa việc quản lý mạng bằng phần mềm [36]. Tổng quan về kiến trúc của SDN đƣợc hiển thị trong hình 2.9 [40]
Thiết lập một mạng bao gồm cài đặt và cấu hình phức tạp của bộ định tuyến, bộ chuyển mạch và các thiết bị mạng khác và đòi hỏi một kỹ sƣ đƣợc đào tạo và có kỹ năng cao để giải quyết thực hiện. Cách tiếp cận này là cách tiếp cận dựa trên hệ thống và dựa trên nhà cung cấp và nó sẽ làm tăng chi phí cung cấp, chi phí nhân lực trong việc quản lý mạng đa cấp và đa nhà cung cấp và giảm doanh thu. Đây là lúc các nhà cung cấp dịch vụ đầu tƣ mạnh mẽ vào các giải pháp thay thế nhƣ SDN giúp tăng khả năng quản lý mạng và giảm chi phí cung cấp [1]. Software Defined Networking (SDN) là thuật ngữ xuất hiện và đƣợc đặt ra gần đây nhƣng khái niệm về SDN xuất phát từ năm 1996. Nhiều công ty bắt đầu xây dựng và triển khai SDN để biến điều này thành hiện thực và các công ty đứng đằng sau SDN là Ipsilon, Internet Engineering Task Force (IETF), OpenDaylight, Open Networking Foundation (ONF), Ethane và OpenFlow... [36]. Đôi khi mọi ngƣời gọi SDN là OpenFlow nhƣng thực tế, OpenFlow chỉ là một API cho SDN [36].
Software Defined Networking cho phép quản trị viên mạng thích ứng nhanh theo môi trƣờng kinh doanh năng động và có thể điều khiển mạng từ một vị trí tập trung đƣợc gọi là bảng điều khiển mà không cần chạm vào bảng điều khiển riêng cho bộ định tuyến hoặc bộ chuyển mạch hoặc các thiết bị mạng khác, có thể cung cấp dịch vụ nhanh chóng và hỗ trợ xử lý mạng mà không cần biết máy chủ hoặc bộ định tuyến cụ thể đƣợc kết nối với các thiết bị khác nhƣ thế nào [37-38].
nh 2.9: Tổng quan kiến trúc SDN
2.2.4.1 Why SDN?
Động lực chính đứng sau SDN là nâng cao hiệu năng của mạng, cung cấp và triển khai mạng bằng cách tách control và data plane, cho phép lập trình các thiết bị mạng và cho phép các kỹ sƣ mạng thực hiện một hoạt động mạng từ một bảng điều khiển mà không cần biết kết nối phức tạp thực tế. Thông thƣờng, việc cấu hình các thiết bị mạng đòi hỏi một kỹ sƣ mạng đƣợc đào tạo chuyên sâu và các thiết bị dựa trên nhà cung cấp yêu cầu đào tạo đặc biệt để thực hiện cùng một nhiệm vụ khác nhau trên các máy khác nhau, điều này làm tăng chi phí. SDN cung cấp giải pháp nguồn mở cho vấn đề trên khiến các hoạt động mạng đƣợc sắp xếp hợp lý [37-38]. SDN đƣợc thiết kế để mang lại sự linh hoạt hơn và hỗ trợ ảo hóa. Nó tách biệt công cụ điều khiển và công
cụ chuyển tiếp, cho phép khả năng lập trình trong công cụ điều khiển cũng nhƣ trừu tƣợng hóa cơ sở hạ tầng khỏi các ứng dụng và các dịch vụ khác [37-38].
nh 2.10: Phương pháp tiếp cận Computing và Networking
Software defined networking chia mạng ra thành 3 thành phần chính gồm lớp ứng dụng, lớp điều khiển và lớp cơ sở hạ tầng. Mỗi SDN đều có một Controller, Northbound API và Southbound API.
Lớp ứng dụng chứa các ứng dụng hoặc chức năng mạng điển hình mà các tổ chức sử dụng, có thể bao gồm các hệ thống phát hiện xâm nhập, cân bằng tải hoặc tƣờng lửa. Trong một mạng truyền thống sẽ sử dụng các thiết bị chuyên dụng, nhƣ tƣờng lửa hoặc cân bằng tải, SDN sẽ thay thế thiết bị đó bằng một ứng dụng sử dụng bộ điều khiển để quản lý “hành vi” của data plane.
Controller tập trung hoạt động nhƣ bộ não của SDN. Bộ điều khiển này nằm trên một máy chủ và quản lý các chính sách và luồng lƣu lƣợng trên toàn mạng.
Northbound API đƣợc sử dụng để giao tiếp với lớp trên cùng và cho phép kỹ sƣ mạng có thể triển khai các dịch vụ và điều khiển lƣu lƣợng theo hƣớng lập trình. Các API này cũng tích hợp một lớp thấp hơn đƣợc gọi là controller để các nhà phát triển mạng và thực hiện thay đổi một cách thực tế, đồng thời cung cấp một sự trừu tƣợng hóa cho lớp trên.
Southbound API đƣợc sử dụng để chuyển tiếp lƣu lƣợng đến các bộ định tuyến và chuyển mạch trong forwarding plane (lớp cơ sở hạ tầng). OpenFlow đƣợc coi là SDN nhƣng nó chỉ là Southbound API [38]. Southbound API cho phép kỹ sƣ mạng thực hiện các thay đổi đối với SDN controller liên quan đến nhu cầu khi đang di chuyển. ONF phát triển OpenFlow, là một Southbound API tiếng cho SDN.
nh 2.11: Mạng truyền thống vs mạng SDN
2.2.4.2 Sự phát triển của SDN
Các ứng dụng CNTT thông thƣờng yêu cầu tính toán, lƣu trữ và tài nguyên mạng. Theo truyền thống, cơ sở hạ tầng máy chủ và lƣu trữ đƣợc cài đặt và định cấu hình bởi quản trị viên hệ thống và sau đó đƣợc tách ra, quản trị viên mạng đƣợc sử dụng để kết nối máy chủ và cấu hình mạng. Cách tiếp cận silo-based này không cho phép mở rộng cho các nhu cầu triển khai ứng dụng theo yêu cầu và tự động hóa ngày nay. Hơn nữa, kiến trúc mạng truyền thống đƣợc thiết kế cho một môi trƣờng ứng dụng tĩnh, trong khi tính linh hoạt là nhu cầu theo hàng giờ.
Đây là nguyên nhân tại sao SDN xuất hiện. SDN làm cho cơ sở hạ tầng mạng dễ dàng quản lý và tích hợp với máy chủ và cơ sở hạ tầng lƣu trữ. Do đó, các tài nguyên cần thiết để triển khai ứng dụng có thể đƣợc cung cấp một cách nhanh nhẹn nhƣng linh hoạt.
SDN ban đầu đƣợc chuẩn hóa vào năm 2011 bởi Open Networking Foundation (ONF), một tổ chức hƣớng ngƣời dùng với mục đích nhằm thúc đẩy và áp dụng SDN, và triển khai SDN thông qua các tiêu chuẩn mở, để thúc đẩy ngành công nghiệp mạng phát triển [25]. ONF là tổ chức đằng sau việc tiêu chuẩn hóa giao thức OpenFlow, một trong những phƣơng pháp đƣợc sử dụng hàng đầu để triển khai SDN. ONF định nghĩa SDN nhƣ sau: [50]
"Software Defined Networking (SDN) là một kiến trúc mới nổi, năng động, dễ quản lý, tiết kiệm chi phí và dễ thích ứng, làm cho nó trở nên lý tưởng cho tính linh động, băng thông cao của các ứng dụng ngày nay. Kiến trúc này tách riêng các chức
năng điều khiển và chuyển tiếp mạng cho phép điều khiển mạng được lập trình trực tiếp và cơ sở hạ tầng bên dưới được trừu tượng hóa cho các ứng dụng và dịch vụ mạng. Giao thức OpenFlow là một yếu tố nền tảng để xây dựng các giải pháp SDN"
Các thành phần của mạng truyền thống
Để đi sâu vào SDN, tôi sẽ xem xét ra các thành phần của thiết bị mạng. Chức năng mạng có thể chia thành 3 plane. Bao gồm:
Data plane: Hành động di chuyển các bit cấu thành gói từ một cổng đến sang một cổng đi là trách nhiệm của data plane. Đây còn đƣợc gọi là forwarding
plane. Ví dụ, trong các bộ chuyển mạch Ethernet, các gói đến từ một cổng đƣợc
chuyển tiếp qua một hoặc nhiều cổng còn lại.
Control plane: Sử dụng ví dụ trƣớc đó, để chuyển tiếp gói đến cổng gửi chính xác, data plane có thể cần thêm thông tin. Trong trƣờng hợp chuyển mạch Ethernet, cổng đi đƣợc xác định bằng cách sử dụng địa chỉ MAC đích đƣợc học bởi Switch. Hành động học hỏi và xây dựng thông tin nhận thức về mạng này là trách nhiệm của control plane. Control planc tìm hiểu và thu thập thông tin về mạng bằng các giao thức khác nhau. Trong một Switch, các vòng lặp mạng đƣợc phát hiện bằng giao thức spanning tree. Trong Router, giao thức OSPF giúp cấu trúc liên kết mạng đƣợc học. Điều quan trọng ở đây là data plane tận dụng thông tin đƣợc xây dựng bởi control plane.
Management plane: Trong khi các mạng thực hiện công việc xử lý và chuyển tiếp lƣu lƣợng dữ liệu, vấn đề quan trọng là phải theo dõi trạng thái của chúng và cấu hình chúng cho phù hợp với nhu cầu của bạn. Khả năng quản lý và điều khiển thiết bị mạng này là trách nhiệm của management plane. Các cơ chế phổ biến để quản lý mạng bao gồm giao diện dòng lệnh (CLI), giao thức SNMP, v.v. API RESTful sử dụng HTTP đã trở nên phổ biến nhƣ một giao thức management plane gần đây. Thông thƣờng, quản trị viên mạng là ngƣời có khả năng sử dụng management plane.
Sơ đồ sau mô tả ba plane của mạng. Management plane đƣợc đại diện bởi các nhà điều hành. Control plane bao gồm nhiều hơn một thiết bị mạng, trong khi phạm vi chức năng của data plane đƣợc giới hạn ở mỗi thiết bị mạng:
nh 2.12: Networking planes
Các khía cạnh chính của networking plane
Để hiểu các yếu tố thúc đẩy đằng sau SDN, điều quan trọng là phải hiểu một số khía cạnh chính của ba mặt phẳng của mạng:
Các quyết định chuyển tiếp đƣợc thực hiện cục bộ trong một thiết bị mạng và các quyết định đó dựa trên control plane.
Việc thực thi các gói chuyển tiếp trong thực tế phải nhanh, để đáp ứng các yêu cầu về hiệu suất mạng. Điều này đƣợc thực hiện bằng phần cứng chuyên dụng dựa trên ASIC và ngụ ý rằng các thực thể data plane tồn tại trên mỗi thiết bị mạng vật lý.
Trong hầu hết các tình huống phổ biến việc cập nhật control plane liên quan đến nhiều hơn một thiết bị mạng nhƣ bộ chuyển mạch và bộ định tuyến. Nó tƣơng đối chậm hơn nhiều so với forwarding plane.
Tất cả các thiết bị mạng phải hỗ trợ các giao thức chuẩn để tìm hiểu chính xác cấu trúc liên kết mạng, kết nối và thông tin liên quan. Điều này, về bản chất, có nghĩa là các thực thể control plane phải tồn tại trên mỗi thiết bị.
Trong trƣờng hợp có nhiều nhà cung cấp, khả năng tƣơng tác giữa control plane và management plane là rất quan trọng cho mạng hoạt động trơn tru.
Các phần của giao thức management plane nhƣ SNMP đƣợc yêu cầu để chạy trên các thiết bị mạng. Tuy nhiên, vấn đề quan trọng nhất của quản lý là các
chức năng tập trung đƣợc cung cấp bởi Network Management Systems (EMS và NMS).
Những thách thức mà các mạng truyền thống phải đối mặt
Nhƣ đã thấy trƣớc đó, các mạng truyền thống đƣợc xây dựng và vận hành dựa trên ba networking plane. Các mạng có bản chất tĩnh và đƣợc cấu hình thủ công dựa trên các yêu cầu dịch vụ. Tiếp theo chúng ta hãy xem những thách thức phải đối mặt trong kiến trúc truyền thống của các mạng. [51]
Thách thức của Control plane:
- Vấn đề rõ ràng nhất phải đối mặt trong control plane là khả năng tương tác.
Mặc dù các tiêu chuẩn tồn tại cho hầu hết các giao thức, sự hỗ trợ của mỗi nhà cung cấp cho các tiêu chuẩn có thể khác nhau. Và ngay cả đối với cùng một nhà cung cấp, hành vi giao thức có thể khác nhau giữa các bản phát hành. Điều này sẽ dẫn đến sự không tƣơng thích và hạn chế sự thông minh có thể đƣợc xây dựng bằng control plane. Để tối ƣu hóa chi phí cũng nhƣ tính linh hoạt, các nhà khai thác đám mây không muốn khóa nhà cung cấp đơn lẻ. Do đó, control plane phải có thêm nhiều tính năng và mạnh mẽ cho toàn bộ đám mây.
- Một vấn đề khác mà control plane phải đối mặt là mở rộng quy mô. Tôi đã thấy rằng các thực thể control plane (giao thức và các thành phần khác) chạy trên các thiết bị mạng. Các thiết bị này có tài nguyên tính toán hạn chế và đối với các mạng quy mô lớn, việc xử lý control plane có thể bị gặp khó khăn vì điều này. Các phƣơng pháp truyền thống để mở rộng control plane là nâng cấp phần cứng của thiết bị hoặc ít nhất là thẻ nhớ bộ xử lý control plane trên thiết bị mạng. Trong triển khai đám mây, đây sẽ là một thách thức rất lớn, đặc biệt là vì các ứng dụng và khối lƣợng công việc ảo hóa là tăng hoặc giảm dựa trên nhu cầu.
Thách thức của Management plane:
- Trong khi control plane có các giao thức chuẩn đảm bảo khả năng tƣơng tác cơ bản, management palne có thể đƣợc thực hiện với các tiêu chuẩn hoàn toàn độc quyền. Các giao thức nhƣ SNMP rất hữu ích, nhƣng để có trải nghiệm ngƣời dùng tốt hơn, hầu hết các nhà cung cấp đều thực hiện CLI và/hoặc Hệ thống quản lý phần tử (EMS - Element Management Systems) của riêng họ. Điều này làm cho việc quản lý mạng nhiều nhà cung cấp rất cồng kềnh.
- Triển khai ứng dụng dựa trên đám mây và cơ sở hạ tầng tƣơng ứng cần có tính
co giãn cao. Điều này có nghĩa là các tài nguyên cần đƣợc phân bổ và loại bỏ
dựa theo yêu cầu. Các nền tảng đám mây nhƣ OpenStack yêu cầu cung cấp tài nguyên phải có sẵn thông qua các API lập trình. Điều này cho phép tính toán,
lƣu trữ và tài nguyên mạng đƣợc phân bổ linh hoạt và tối ƣu. Khả năng lập trình trong các mạng truyền thống đƣợc hỗ trợ bằng cách tự động hóa các lệnh CLI hoặc thông qua các giao diện North-bound khác. Nhƣng do cách tiếp cận dựa trên silo, rất khó để tích hợp các API này với API tính toán và lƣu trữ.
- Các ứng dụng truyền thống yêu cầu phần cứng mạng chuyên dụng nhƣ bộ cân bằng tải, tƣờng lửa, v.v. Khi các ứng dụng trở nên ảo hóa, điều bắt buộc là các chức năng mạng chuyên dụng cũng có sẵn trong yếu tố hình thức ảo. Xu hƣớng này thƣờng đƣợc gọi là ảo hóa chức năng mạng (NFV - Network Function Virtualization). Điều này có nghĩa là các khả năng kết nối mạng có thể đƣợc khởi tạo và triển khai nhƣ các ứng dụng phần mềm, độc lập với phần cứng thực tế. Để hỗ trợ khả năng này, các nền tảng đám mây yêu cầu các mạng phải đƣợc xác định bằng cách sử dụng trừu tƣợng hóa. Cách này cho phép toàn bộ các ứng dụng và các tài nguyên liên quan đƣợc xác định là các thực thể phần mềm. Và nền tảng đám mây có thể phối hợp hoặc khởi tạo các thực thể này theo yêu cầu.
Kiến trúc SDN
Sơ đồ sau mô tả kiến trúc SDN đơn giản hóa trong đó control plane đƣợc tập trung vào controller. Nó cũng coi OpenFlow là giao thức giữa control plane tập trung và data plane phân tán. Trong khi OpenFlow là giao thức SDN phổ biến nhất giữa control plane và data plane, các nền tảng SDN nhƣ OpenContrail sử dụng XMPP và BGP làm giao thức control plane.
Cải tiến Control plane với SDN
Trong các mạng truyền thống control plane đƣợc phân phối và chạy trên mỗi thiết bị mạng. Mô hình SDN là mô hình control plane tập trung. Control plane tập trung này là một thực thể phần mềm thƣờng đƣợc gọi là SDN Controller. Bằng cách tập trung vào control plane, vấn đề tƣơng tác đƣợc giải quyết ở mức độ lớn. Control plane tập trung lập trình thiết bị sử dụng các công nghệ nhƣ OpenFlow. Tất cả các nhà cung cấp hỗ trợ các giao thức nhƣ OpenFlow có thể dễ dàng đƣợc tích hợp vào các SDN Controller. Hơn nữa, data plane của các thiết bị mới có thể đƣợc lập trình dễ dàng dựa trên thông tin control plane có sẵn.
Vấn đề về mở rộng quy mô cũng đƣợc giải quyết dễ dàng hơn với controller tập trung. Hầu hết các nhà cung cấp mạng chạy các thực thể control plane trên phần cứng chung. Tƣơng tự, controller tập trung cũng đƣợc thiết kế để chạy trên các nền tảng phần cứng phổ biến. Cũng có thể chạy controller nhƣ máy ảo. Điều này cho phép