Một điểm mạnh trong OpenDaylight là bộ phần mềm được mô đun hóa và có tính linh hoạt cao. Tất cả các mã được thực hiện trong Java và được chứa trong Java Virtual Machine (JVM) của riêng nó. Như vậy, nó có thể được triển khai trên bất kỳ phần cứng và nền tảng hệ điều hành nào hỗ trợ Java.
5.3 REST
REpresentational State Transfer (REST) là một kiểu kiến trúc được sử dụng để xác định các APIs. REST đã trở thành một phương thức chuẩn để xây dựng API hướng Bắc cho bộ điều khiển SDN. Một API REST, hay một API được RESTful (tuân thủ các ràng buộc của REST) không phải là một giao thức, ngôn ngữ hoặc tiêu chuẩn đã được thiết lập. Có tất cả sáu yêu cầu cơ bản mà một API phải tuân theo để RESTful. Mục tiêu của những ràng buộc này là tối đa hóa khả năng mở rộng và độc lập/khả năng tương tác của các tương tác phần mềm và cung cấp một phương thức đơn giản để xây dựng các API.
REST giả định rằng các khái niệm về truy cập dựa trên web được sử dụng cho sự tương tác giữa ứng dụng và dịch vụ ở cả hai bên của API. REST không xác định các chi tiết cụ thể của API nhưng áp đặt các ràng buộc về bản chất của sự tương tác giữa ứng dụng và dịch vụ. Sáu yêu cầu REST bao gồm:
NHÓM 2
• Client-server
• Stateless
• Cache
• Giao diện thống nhất
• Hệ thống được phân lớp
• Mã hóa theo yêu cầu
5.4 Bộ điều khiển tập trung và phân tán
Một điểm quan trọng then chốt trong thiết kế kiến trúc là liệu một bộ điều khiển tập trung đơn lẻ hay bộ điều khiển phân tán sẽ được sử dụng để kiểm soát các switches trong mặt bằng dữ liệu.
Bộ điều khiển tập trung là một máy chủ duy nhất quản lý tất cả các switches trong mặt bằng dữ liệu trong mạng. Trong một mạng doanh nghiệp lớn, việc triển khai một bộ điều khiển duy nhất để quản lý tất cả các thiết bị mạng có thể dẫn đến khó sử dụng hoặc bất cập không mong muốn. Một kịch bản có khả năng hơn là nhà điều hành của một doanh nghiệp lớn hoặc mạng lưới các nhà cung cấp chia mạng lưới toàn bộ thành một số miền SDN không trùng lặp, còn được gọi là các “SDN islands” (Hình 3.9), được quản lý bởi các bộ điều khiển phân tán.
Hình 5.6: Cấu trúc miền SDN Lý do sử dụng miền SDN bao gồm những điều sau:
- Khả năng mở rộng: Số lượng thiết bị mà bộ điều khiển SDN có thể quản lí được một cách khả thi là có giới hạn. Do đó, một mạng lớn phù hợp có thể cần phải triển khai nhiều bộ điều khiển SDN.
- Độ tin cậy: Việc sử dụng nhiều bộ điều khiển tránh rủi ro khi một bộ điều khiển duy nhất xảy ra lỗi.
- Riêng tư: Nhà cung cấp dịch vụ có thể chọn thực hiện các chính sách bảo mật khác nhau trong các miền SDN khác nhau. Ví dụ: một miền SDN có thể được dành riêng cho
một nhóm khách hàng thực hiện chính sách bảo mật tùy chỉnh cao của riêng họ, yêu cầu không được tiết lộ một số thông tin mạng trong miền này (ví dụ topo mạng) cho một thực thể bên ngoài.
- Triển khai gia tăng: Mạng của một hãng truyền thông công cộng có thể bao gồm các phần của cơ sở hạ tầng kế thừa và không kế thừa. Chia mạng thành nhiều miền SDN có thể quản lý riêng lẻ cho phép triển khai gia tăng linh hoạt. Bộ điều khiển phân tán có thể được sắp xếp trong một khu vực nhỏ, hoặc phân tán rộng rãi, hoặc kết hợp cả hai. Các bộ điều khiển được đặt chặt chẽ cung cấp lưu lượng cao và thích hợp cho các trung tâm dữ liệu, trong khi các bộ điều khiển phân tán thích hợp với các mạng lưới nhiều điểm. Thông thường, bộ điều khiển được phân bố theo chiều ngang. Tức là, mỗi bộ điều khiển sẽ điều khiển một tập hợp con không chồng chéo của các switches trong mặt bằng dữ liệu.Trong một kiến trúc phân tán, cần một giao thức để truyền thông giữa các bộ điều khiển. Về nguyên tắc, một giao thức độc quyền có thể được sử dụng cho mục đích này mặc dù một giao thức mở hoặc chuẩn sẽ rõ ràng là thích hợp hơn cho các mục đích tương tác. Các chức năng liên quan đến giao diện hướng Đông/hướng Tây cho một kiến trúc phân tán bao gồm việc duy trì cơ sở dữ liệu được phân chia và nhân rộng về topo và các tham số mạng, và các chức năng giám sát/thông báo. Chức năng thứ hai bao gồm việc kiểm tra xem bộ điều khiển có còn hoạt động hay không và điều phối các thay đổi trong việc chuyển đổi các bộ điều khiển sang bộ điều khiển.
5.5 Opendaylight SDNi
IETF đã phát triển một bản đặc tả kỹ thuật định nghĩa các yêu cầu chung để thiết lập luồng lưu lượng ngang hàng và trao đổi thông tin về khả năng tiếp cận qua nhiều tên miền, gọi là SDNi (SDNi: Một giao thức trao đổi bản tin cho các mạng định nghĩa phần mềm qua nhiều tên miền, draft-yin-sdn-sdni-00 .txt, ngày 27 tháng 6 năm 2012). Đặc tả SDNi (SDNi specification) không định nghĩa giao thức SDN ở hướng Đông/Tây mà cung cấp một số nguyên tắc cơ bản được sử dụng để phát triển một giao thức như vậy. Chức năng SDNi được định nghĩa trong đặc tả bao gồm những điều sau:
• Thiết lập luồng lưu lượng ngang hàng bắt nguồn từ các ứng dụng, chứa thông tin như yêu cầu truy cập, QoS và các mức dịch vụ phù hợp trên nhiều tên miền SDN.
• Trao đổi thông tin về khả năng tiếp cận để định tuyến giữa các miền SDN. Điều này sẽ cho phép một luồng đơn duy đi qua các miền SDNs và mỗi bộ điều khiển
lựa chọn con đường thích hợp nhất trong số các đường dẫn khả dụng.
SDNi phụ thuộc vào các loại tài nguyên sẵn có và khả năng sẵn có được quản lý bởi các bộ điều khiển khác nhau trong mỗi miền. Do đó, điều quan trọng là phải thực hiện SDNi một phương thức mở để các khả năng mới được cung cấp bởi các loại bộ điều khiển khác nhau sẽ được hỗ trợ. Do SDN về bản chất cho phép thay đổi, dữ liệu trao đổi giữa
NHÓM 2
các bộ điều khiển sẽ có tính linh động. Vì vậy cần có một số trao đổi siêu dữ liệu (metadata) cho phép SDNi trao đổi thông tin về các khả năng không xác định.Các loại thông điệp cho SDNi dự kiến bao gồm:
• Cập nhật khả năng tiếp cận.
• Thiết lập/cập nhật yêu cầu (bao gồm cả yêu cầu về khả năng ứng dụng như QoS, tốc độ dữ liệu, độ trễ...
• Cập nhật khả năng (bao gồm các tính năng liên quan đến mạng, chẳng hạn như tốc độ dữ liệu và QoS, và khả năng hệ thống và phần mềm có sẵn bên trong miền).
Chứa trong kiến trúc OpenDaylight là một khả năng SDNi để kết nối nhiều bộ điều khiển liên kết OpenDaylight trong mạng và chia sẻ thông tin topology trong số chúng . Khả năng này phù hợp với đặc tả IETF cho một chức năng SDNi. Ứng dụng SDNi có thể triển khai trên bộ điều khiển OpenDaylight bao gồm ba thành phần.
• Trình kết hợp SDNi: Plug-in SDNi hướng Bắc hoạt động như một trình tổng hợp để thu thập thông tin mạng như topo, thống kê và định danh máy chủ lưu trữ.
• Plug-in này có thể phát triển để đáp ứng nhu cầu về dữ liệu mạng được yêu cầu chia sẻ qua các bộ điều khiển SDN liên kết.
• SDNi REST API: API SDNi REST thu thập thông tin tổng hợp từ plug-in hướng Bắc (trình kết hợp SDNi).
• SDNi Wrapper: Wrapper SDNi BGP có trách nhiệm chia sẻ và thu thập thông tin gửi/nhận từ các bộ điều khiển liên kết.
5.6 Triển khai OpenDaylight
Cài đặt môi trường Java JRE cho Ubuntu:
Các kiến trúc sư OpenDaylight đã thiết kế OpenDaylight cho hệ sinh thái Java. Lệnh cài đặt Java 8 JRE
$ sudo apt-get -y install openjdk-8-jre
Sử dụng lệnh cập nhật thay thế để đặt Java mặc định thành JAVA 8
$ sudo update-alternatives --config java
Truy xuất đường dẫn đầy đủ đến tệp thực thi JAVA
Đặt ( và duy trì ) giá trị của JAVA_HOME, chỉnh sửa tệp tài nguyên bash.
$ echo ‘export JAVA_HOME = /usr/lib/jvm/java-8-openjdk-amd64/jre’ >> ~/ . bashrc
$ source ~/.bashrc
NHÓM 2
Hình 5.7: Kích hoạt Java trong môi trường Ubuntu Lệnh echo $JAVA_HOME để kiểm tra lại $JAVA_HOME
Hình 5.8: Kiểm tra $JAVA_HOME
Dùng lệnh curl -XGET -O để tải file cài đặt OpenDaylight: curl -XGET -O
https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/ opendaylight/integration/karaf/0.8.4/karaf-0.8.4.zip
NHÓM 2
Hình 5.9: Cài đặt
OpenDayLight Giải nén tệp bằng lệnh unzip karaf-0.8.4.zip
Hình 5.10: Giải nén file bằng lệnh unzip
Khởi động OpenDaylight bằng lệnh:
~$ cd karaf-0.8.4/bin/ ~/karaf-0.8.4/bin$ ./karaf
NHÓM 2
Hình 5.11: Khởi động OpenDayLight
Cuối cùng ta dùng lệnh feature:install odl-dluxapps-applications odl-dluxapps- nodes odl-dluxapps-topology odl-dluxapps-yangui odl-dluxapps-yangvisualizer odl- dluxapps-yangutils odl-dlux-core (odl-dluxapps-applications odl-dluxapps-nodes odl- dluxapps-topology odl-dluxapps-yangui odl-dluxapps-yangvisualizer odl-dluxapps- yangutils odl-dlux-core là tên của các tính năng cần cài)
Hình 5.12: Cài đặt các tính năng
Để kiểm tra lại các tính năng đã được cài đặt hay chưa, ta dùng lệnh feature:list – installed
Sau khi cài đặt và khởi động OpenDayLight, ta tiến hành kết nối topo mạng 3 switch 4 host với bộ điều khiển OpenDayLight:
Trên Terminal của Ubuntu dùng lệnh ssh -X mininet@192.168.254.143 để kết nối tới mininet-vm có địa chỉ IP là 192.168.254.143, sau bước này ta có command line của mininet-vm trên Ubuntu
NHÓM 2
Hình 5.13: Command line của mininet-vm trên ubuntu
Đăng nhập OpenDayLight trên trình duyệt 192.168.254.137:8181/index.html (trong đó 192.168.254.137 là địa chỉ ip của Ubuntu, 8181 là cổng điều khiển)
Hình 5.14: Đăng nhập OpenDayLight
Tại mininet-vm, ta dùng lệnh cd mininet/custom để đi đến file topo mạng 3 switch 4 host đã được tạo.
Sau đó ta gõ lệnh sudo mn --controller=remote,ip=192.168.254.137,port=6633 -- custom topo-3sw-4h.py --topo tp --mac để nối bộ điều khiển với topo mạng (trong đó ip=192.168.254.137 là địa chỉ ip của máy ảo Ubuntu chứa bộ điều khiển OpenDaylight, controller của Ubuntu ở cổng 6633, topo-3sw-4h.py là file topo mạng 3 switch 4 host)
NHÓM 2
Hình 5.15: Kết nối bộ điều khiển OpenDayLight với topo mạng
Dùng lệnh pingall và quay lại giao diện OpenDayLight vào thẻ Topology bấm Reload, trên màn hình sẽ hiển thị mô hình mạng SDN mà ta đã tạo
Hình 5.16: Mô hình mạng SDN sử dụng controller OpenDayLight
Vậy là ta đã xây dựng xong topo mạng SDN 3 switch 4 host dùng bộ điều khiển OpenDayLight
NHÓM 2
Tài liệu tham khảo
[1] Bài giảng chuyên đề SDN, Nguyễn Xuân Khánh, Tháng 03/2021
NHÓM 2