Nghiên cứu ứng dụng và phát triển ứng dụng trên nền tảng floodlight controller của chuẩn mở open flow

Hệ thống thiết bị mạng phổ biến hiện nay được sản xuất trên quan điểm là gắn lớp điều khiển phần mềm điều hành và lớp chuyển tiếp dữ liệu với nhau trên cùng một thiết bị, do đó mỗi thiết

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

-

PHẠM HOÀNG HÙNG

NGHIÊN CỨU VÀ PHÁT TRIỂN ỨNG DỤNG TRÊN NỀN TẢNG FLOODLIGHT CONTROLLER CỦA CHUẨN MỞ OPEN FLOW

Chuyên ngành: Kỹ thuật máy tính và Truyền thông

LUẬN VĂN THẠC SĨ KỸ THUẬT

Người hướng dẫn khoa học PGS TS Ngô Hồng Sơn

Hà Nội – Năm 2014

LỜI CAM ĐOAN

Tôi xin cam đoan đây là công trình nghiên cứu do tôi thực hiện, các kết quả,

số liệu, mô hình trong luận văn là trung thực và và chưa từng được công bố trong bất kỳ công trình nào khác

Nếu có bất kỳ sai sót nào, tôi xin chịu hoàn toàn trách nhiệm

Tác giả Luận văn

Phạm Hoàng Hùng

MỤC LỤC

Trang phụ bìa………

Lời cam đoan………

Mục lục………

Danh mục các ký hiệu, các chữ viết tắt………

Danh mục các hình vẽ, sơ đồ………

MỞ ĐẦU 1

1 Lý do chọn đề tài 1

2 Quá trình nghiên cứu 2

3 Mục đích, đối tượng, phạm vi nghiên cứu 2

4 Tóm tắt kết quả 2

5 Phương pháp nghiên cứu 3

6 Bố cục luận văn 3

NỘI DUNG LUẬN VĂN 4

Chương 1 Hiện trạng hệ thống mạng và xu hướng công nghệ 4

1.1 Mạng truyền thống và những vấn đề còn tồn tại 4

1.1.1 Khó khăn cho quá trình cài đặt, quản lý 5

1.1.2 Thiếu linh hoạt trong việc thay đổi policy based routing (Policy based routing) hoặc mô hình hệ thống 5

1.1.3 Phụ thuộc vào hãng sản xuất thiết bị 6

1.1.4 Khó khăn trong việc sửa lỗi hệ thống 6

1.1.5 Khó khăn trong việc mở rộng và chia sẻ tài nguyên 6

1.1.6 Vòng đời thiết bị thấp 7

1.1.7 Sự cần thiết của một kiến trúc mới 7

1.2 SDN – Kiến trúc mạng tương lai 7

1.2.1 Định nghĩa 7

1.2.2 Kiến trúc SDN 7

1.2.3 Các thành phần trong kiến trúc SDN 8

1.2.4 Ưu điểm của kiến trúc SDN 10

1.3 Đặt vấn đề, định hướng giải pháp 11

1.3.1 Thiết lập, thay đổi policy based routing based routing tự động theo thời gian 11 1.3.2 Định hướng giải pháp 12

1.3.3 Phương pháp thử nghiệm giải pháp 13

Chương 2 Lựa chọn công nghệ 15

2.1 Lựa chọn giải pháp ảo hóa 15

2.1.1 Ảo hóa một phần (Para-virtualization) 15

2.1.2 Ảo hóa hoàn toàn (Full-virtualization) 15

2.1.3 Ảo hóa mức hệ điều hành (OS-level virtualization) 16

2.1.4 Phương án lựa chọn 17

2.2 Lựa chọn thành phần điều khiển (Controller) 18

2.2.1 OpenDaylight 18

2.2.2 Floodlight 19

2.2.3 Giải pháp lựa chọn 19

2.3 Lựa chọn công nghệ cho lớp chuyển tiếp dữ liệu 19

2.3.1 Lựa chọn phần mềm định tuyến 20

2.3.2 Lựa chọn phần mềm chuyển tiếp dữ liệu 21

2.3.3 Giải pháp kết nối nội bộ 21

Chương 3 Quá trình thực hiện 23

3.1 Xây dựng môi trường giả lập 23

3.1.1 Quá trình cài đặt Floodlight Controller 23

3.1.2 Cài đặt và cấu hình cho Bird 25

3.1.3 Cài đặt OpenvSwitch 27

3.1.4 Cấu hình kết nối trong thiết bị định tuyến ảo 29

3.1.5 Cấu hình kết nối cho hệ thống mô phỏng 32

3.1.6 Cấu hình GNS3 33

3.2 Phát triển thêm tính năng ứng dụng 34

3.2.1 Giới thiệu ứng dụng Avior 34

3.2.2 Tính năng phát triển thêm (Schedule) 37

3.3 Kết quả thực hiện 40

Chương 4 Đánh giá hiệu quả 41

4.1 So sánh việc giải quyết bài toán trong các mô hình mạng khác nhau 41

4.1.1 Mô hình mạng vừa và nhỏ 41

4.1.2 Mô hình mạng có quy mô lớn tập trung 43

4.1.3 Mô hình mạng quy mô lớn phân bố rộng 45

4.2 Đánh giá hiệu quả và khả năng ứng dụng thực tế 48

KẾT LUẬN 49

1 Kết quả đã đạt được 49

2 Nhược điểm còn tồn tại 49

3 Phạm vi ứng dụng 49

4 Định hướng nghiên cứu phát triển 50

DANH MỤC TÀI LIỆU THAM KHẢO 51

DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT

DANH MỤC CÁC HÌNH VẼ, SƠ ĐỒ

Hình 1.1: Mô hình chức năng thiết bị mạng truyền thống 4

Hình 1.2: Kiến trúc SDN 8

Hình 1.3: Mô hình mạng thử nghiệm 13

Hình 2.1: Mô hình ảo hóa một phần (Para-virtualization) 15

Hình 2.2: Mô hình ảo hóa hoàn toàn (Full-virtualization) 16

Hình 2.3: Mô hình ảo hóa mức hệ điều hành (OS-level virtualization) 17

Hình 2.4: Mô hình ảo hóa thiết bị lớp chuyển tiếp dữ liệu (Data Plane) 20

Hình 2.5: Mô hình kết nối nội bộ thiết bị định tuyến ảo 22

Hình 3.1 Giao diện ứng dụng theo dõi hệ thống dạng web của Floodlight 25

Hình 3.2 Mô hình kết nối Floodlight - OvS 29

Hình 3.3: Kết nối nội bộ thiết bị định tuyến ảo 30

Hình 3.4 Mô hình kết nối thiết bị mô phỏng 33

Hình 3.5 Mô hình mạng sử dụng GNS3 34

Hình 3.6 Giao diện ứng dụng Avior 35

Hình 3.7 Giao diện công cụ quản lý, điều khiển luồng (Flow Manager) 36

Hình 3.8 Giao diện công cụ quản lý, điều khiển luồng mới 38

Hình 3.9 Giao diện chức năng Schedule 39

Hình 3.10 Thiết lập thời gian đổi policy based routing trên VR02 40

Hình 3.11 Tuyến đường VR01  VR04 khi tự động đổi policy based routing trên VR02 40

DANH MỤC BẢNG BIỂU

Bảng 4.1 So sánh việc giải quyết bài toán trong mô hình mạng vừa và nhỏ 41 Bảng 4.2 So sánh việc giải quyết bài toán trong mô hình mạng có quy mô lớn tập trung 43 Bảng 4.3 So sánh việc giải quyết bài toán trong mô hình mạng có quy mô lớn phân

bố rộng 45

MỞ ĐẦU

1 Lý do chọn đề tài

Ảo hóa phần cứng đang trở thành một xu hướng trong lĩnh vực công nghệ thông tin, và các thiết bị mạng cũng không nằm ngoài xu hướng này Theo giải pháp tổng thể về ảo hóa phần cứng nói chung, trước hết chúng ta cần xây dựng hệ thống thiết bị tập trung sau đó sử dụng phần mềm để điều hành, quản lý hoạt động cho toàn

bộ hệ thống thiết bị đó

Hệ thống thiết bị mạng phổ biến hiện nay được sản xuất trên quan điểm là gắn lớp điều khiển (phần mềm điều hành) và lớp chuyển tiếp dữ liệu với nhau trên cùng một thiết bị, do đó mỗi thiết bị có hệ điều hành riêng, có tài nguyên hệ thống riêng và hầu hết là các thiết bị hoạt động độc lập Đối với hệ thống thiết bị như vậy, việc tập trung hóa và chia sẻ tài nguyên phần cứng là rất khó khăn, đây là một hạn chế rất lớn cho việc ảo hóa phần cứng

Như vậy, để thực hiện ảo hóa phần cứng hạ tầng mạng trước hết ta cần phải thay đổi tư duy thiết kế kiến trúc cho các thiết bị mạng hiện tại, tách biệt hai lớp điều khiển và chuyển tiếp dữ liệu, đây chính là khái niệm cơ bản về kiến trúc SDN (Software Define Network)

Trong quá trình học tập và làm việc, tôi thường xuyên được tiếp xúc với các công nghệ về ảo hóa, về điện toán đám mây và tôi tin tưởng ảo hóa là xu hướng bắt buộc cho tất cả các loại thiết bị trong tương lai Do đó, tôi đã bắt đầu tìm hiểu về ảo hóa phần cứng cho hạ tầng mạng và được PGS.TS Ngô Hồng Sơn định hướng nghiên cứu về kiến trúc SDN

Qua quá trình nghiên cứu ban đầu tôi nhận thấy SDN đang là kiến trúc được

hỗ trợ phát triển nhanh chóng và đưa ra những công nghệ mang tính xu thế cho lĩnh vực mạng Floodlight Controller và Open Flow là hai trong số đó, một phần mềm lõi điều hành hệ thống thiết bị trong mạng lưới và một chuẩn mở cho phép các đơn vị khai thác, vận hành giảm đáng kể sự phụ thuộc vào nhà cung cấp thiết bị

Vì xu hướng và khả năng phát triển lớn của kiến trúc và công nghệ này, tôi quyết định chọn đề tài “Nghiên cứu và phát triển ứng dụng trên nền tảng Floodlight Controller của chuẩn mở Open Flow” làm đề tài cho luận văn thạc sỹ của mình

2 Quá trình nghiên cứu

Chính thức được nhận đề tài từ ngày 14 tháng 5 năm 2013 nhưng tôi đã bắt đầu tìm hiểu về kiến trúc SDN, Floodlight Controller, Open Flow từ trước đó Trong quá trình tìm hiểu và nghiên cứu tôi thường xuyên trao đổi và làm việc với hai bạn sinh viên nghiên cứu cùng hướng đề tài và cùng được thầy Ngô Hồng Sơn hướng dẫn Trong thời gian đầu tôi tập trung tìm hiểu về kiến thức cơ bản, định hướng cho quá trình nghiên cứu tiếp theo Từ khoảng tháng 5 năm 2014 tôi bắt đầu phát triển ứng dụng (Phát triển thêm một tính năng cho một chương trình mã nguồn mở) và xây dựng môi trường giả lập để mô phỏng ứng dụng của mình, tôi đã hoàn thành công việc trong tháng 8 năm 2014

3 Mục đích, đối tượng, phạm vi nghiên cứu

Mục đích chính của tôi khi lựa chọn đề tài luận văn gồm:

- Nắm bắt được kiến trúc SDN và các thành phần trong kiến trúc này Sau quá trình tìm hiểu ban đầu tôi đã lựa chọn Floodlight Controller và OpenFlow làm hai công nghệ nền tảng cho quá trình nghiên cứu tiếp theo của mình

- Xây dựng hệ thống mô phỏng và phát triển một ứng dụng cụ thể phục vụ nghiên cứu

- Tìm hiểu các hướng để ứng dụng công nghệ kiến trúc SDN vào thực tế, phát triển các ứng dụng sử dụng công nghệ kiến trúc này

4 Tóm tắt kết quả

Trong quá trình thực hiện luận văn tôi đã thực hiện được các công việc sau:

- Nắm bắt được công nghệ kiến trúc SDN và các thành phần trong kiến trúc này (Tập trung chủ yếu vào Floodlight Controller, Open Flow và các ứng dụng hỗ trợ điều khiển luồng dữ liệu);

- Thiết lập được một mô hình giả lập, tuy còn đơn giản nhưng cũng có thể minh họa cho tiềm năng sử dụng của SDN;

- Phát triển thêm được thành phần chức năng thiết lập, thay đổi policy based routing tự động theo thời gian cho một phần mềm mã nguồn mở;

- So sánh, đánh giá hiệu quả việc thiết lập, thay đổi policy based routing tự động theo thời gian giữa hệ thống mạng sử dụng kiến trúc SDN và hệ thống mạng thông dụng hiện nay

5 Phương pháp nghiên cứu

Trong quá trình làm luận văn tôi sử dụng hai phương pháp nghiên cứu gồm:

Nghiên cứu lý thuyết

- Nghiên cứu các tài liệu, công nghệ liên quan

Nội dung chính luận văn của tôi bao gồm 04 chương:

 Chương 1: Hiện trạng hệ thống mạng và xu hướng công nghệ

 Chương 2: Lựa chọn công nghệ

 Chương 3: Quá trình thực hiện

 Chương 4: Đánh giá hiệu quả Luận văn được thực hiện dưới sự hướng dẫn của Phó Giáo sư, Tiến sĩ Ngô Hồng Sơn, xin chân thành cảm ơn thầy đã nhiệt tình hướng dẫn, đồng thời xin chân thành cảm ơn hai bạn sinh viên cùng nhóm nghiên cứu và các thành viên trong cộng đồng phát triển Floodlight đã giúp đỡ tôi trong trong quá trình thực hiện đề tài

NỘI DUNG LUẬN VĂN

Chương 1 Hiện trạng hệ thống mạng và xu hướng công nghệ

Chương này tôi sẽ đưa ra những khuyết điểm còn tồn tại của các hệ thống mạng phổ biến hiện nay để chỉ ra lý do cần phải có một kiến trúc mạng mới và giới thiệu tổng quan về kiến trúc SDN Sau đó tôi sẽ trình bày cụ thể về những vấn đề còn tồn tại với bài toán thiết lập, thay đổi policy based routing tự động theo thời gian trong hệ thống mạng phổ biến hiện nay và định hướng giải pháp cho bài toán này

1.1 Mạng truyền thống và những vấn đề còn tồn tại

Các hệ thống mạng phổ biến hiện nay chủ yếu được xây dựng dựa trên các thiết bị phần cứng riêng biệt, mỗi thiết bị có hệ điều hành, có bộ nhớ, có tài nguyên riêng và thông thường chỉ có khả năng xử lý một hoặc một vài chức năng nhất định Bản thân mỗi thiết bị sẽ có lớp điều khiển (Control Plane) để tự đưa ra quyết định xử

lý thông tin (như định tuyến, chặn, loại bỏ, …) cũng như lớp chuyển tiếp dữ liệu (Data Plane), hai lớp này được liên kết chặt chẽ với nhau

Hình 1.1: Mô hình chức năng thiết bị mạng truyền thống [13]

Tất nhiên, khi các thiết bị được tối ưu hóa cho các chức năng cụ thể, có tài nguyên phần cứng tốt đồng thời được cài đặt, cấu hình tối ưu thì chúng sẽ đảm bảo khả năng xử lý nhanh, ổn định, giảm thời gian trễ cho toàn hệ thống Tuy nhiên, hệ thống mạng này vẫn tồn tại nhiều khuyết điểm như sau:

1.1.1 Khó khăn cho quá trình cài đặt, quản lý

Với các hệ thống mạng phổ biến hiện nay, hầu hết các công việc cài đặt, quản

lý cho các thiết bị sẽ yêu cầu quản trị viên phải truy cập trực tiếp vào thiết bị để thao tác Đây không phải vấn đề quá lớn nếu số lượng thiết bị vừa phải và không nhiều loại thiết bị trong hệ thống, tuy nhiên với một hệ thống có số lượng thiết bị phần cứng lớn sẽ mất rất nhiều thời gian và dễ gây sai sót

Mặc dù các hãng sản xuất thiết bị mạng lớn trên thế giới đều tập trung phát triển những công cụ cho phép quản lý, cấu hình, cài đặt các thiết bị mạng của họ một cách thuận tiện hơn tuy nhiên với sự phát triển đa dạng của các loại thiết bị mạng, các công nghệ mới của các hãng sản xuất thiết bị khác nhau phát triển ngày càng nhiều thì chưa có sản phẩm nào có khả năng quản lý được toàn bộ các thiết bị trong một hệ thống mạng một cách đúng nghĩa

Ngoài ra, hệ thống có nhiều thiết bị phần cứng vật lý sẽ kéo theo chi phí cho việc quản lý, duy trì hệ thống rất tốn kém (Chi phí cho nhân sự duy trì, vận hành hệ thống; Chi phí điện năng duy trì, vận hành hệ thống; Chi phí linh kiện, thiết bị thay thế, bảo dưỡng hệ thống …)

1.1.2 Thiếu linh hoạt trong việc thay đổi policy based routing (Policy based routing) hoặc mô hình hệ thống

Một hệ thống mạng lớn có thể có hàng trăm, thậm chí hàng nghìn node mạng của nhiều hãng sản xuất thiết bị khác nhau, như đã trình bày ở phần trên, việc xây dựng và duy trì một hệ thống với quy mô lớn như vậy là không hề đơn giản

Với một hệ thống như vậy, khi xuất hiện những yêu cầu cần thay đổi kiến trúc mạng, thay đổi mô hình kết nối các thiết bị trong mạng sẽ dẫn đến một lượng công việc rất lớn và rất thiếu hiệu quả cũng như tỷ lệ lỗi cao khi phải thực hiện thủ công trên từng thiết bị vật lý trong hệ thống

Ngoài ra, đối với những hệ thống mạng lớn thường xuyên có những yêu cầu thay đổi policy based routing cho thiết bị chặt chẽ về thời gian, hoặc tính tự động hóa cao sẽ gây rất nhiều khó khăn cho cách vận hành hệ thống thủ công như hiện tại

1.1.3 Phụ thuộc vào hãng sản xuất thiết bị

Hiện tại, các thiết bị mạng hầu hết là sản phẩm tổng thể bao gồm phần cứng

và phần mềm của một hãng sản xuất nhất định, có thể hiểu đây là một sản phẩm

“đóng” và chỉ có những chức năng nhất định mà nếu muốn thay đổi thì gần như không

có cách nào khác ngoài chờ nhà sản xuất phát triển và mua sản phẩm từ họ Đây là một trở ngại rất lớn trong sự phát triển công nghệ

Ngoài ra, mỗi một tổ chức sẽ có một hệ thống mạng khác nhau và yêu cầu đặc thù khác nhau, sự phụ thuộc vào các hãng sản xuất dẫn tới sự thiếu linh động và hạn chế tính sáng tạo trong việc xây dựng các hệ thống mạng cũng như phát triển các tính năng, công nghệ mạng mới Người dùng không thể tùy biến các thiết bị mạng theo ý định sử dụng của mình cho phù hợp với thực tế mà chỉ có thể lựa chọn thiết bị đáp ứng gần nhất yêu cầu của hệ thống

Hơn nữa, trong các hệ thống mạng phổ biến hiện nay, mỗi hãng sản xuất sẽ sử dụng một cách thức khác nhau để cài đặt, cấu hình thiết bị của họ gây khó khăn cho người sử dụng Để cấu hình thiết bị của hãng Cisco thì cần đọc các tài liệu của Cisco, ngược lại để cấu hình thiết bị của Juniper thì cũng bắt buộc phải đọc tài liệu của Juniper hay các hãng khác cũng tương tự

1.1.4 Khó khăn trong việc sửa lỗi hệ thống

Với một hệ thống sử dụng các thiết bị mạng phổ biến hiện nay, khi gặp sự cố nhân viên quản trị mạng sẽ mất khá nhiều thời gian trong việc khoanh vùng xác định thiết bị lỗi, sau đó thực hiện kiểm tra và làm việc trực tiếp với thiết bị đó để sửa lỗi Quá trình này không những gây mất thời gian mà còn có khả năng làm ảnh hưởng tới tính ổn định của toàn bộ hệ thống mạng

1.1.5 Khó khăn trong việc mở rộng và chia sẻ tài nguyên

Đối với các thiết bị mạng phổ biến hiện nay, khi nói đến mở rộng thường đồng nghĩa với việc mua thêm thiết bị mới tương tự và cài đặt, cấu hình cho thiết bị mới chạy song song với thiết bị cũ trong hệ thống chứ không thể cấp phát thêm tài nguyên cho thiết bị để tăng cường hiệu năng thiết bị Trong thực tế, có rất nhiều trường hợp thiết bị ở vùng A của hệ thống sử dụng chưa hết hiệu năng trong khi thiết bị ở vùng

B lại trong tình trạng quá tải mà không thể chia sẻ tải nguyên lẫn nhau Đây chính là những hạn chế rất lớn của hệ thống mạng hiện tại do các thiết bị xử lý và làm việc hoàn toàn độc lập với nhau

1.1.6 Vòng đời thiết bị thấp

Khi xây dựng một hệ thống mạng sử dụng toàn bộ các thiết bị phần cứng có tài nguyên cố định chúng ta thường gặp vấn đề với policy based routing hỗ trợ sản phẩm của các hãng sản xuất thiết bị phần cứng Thông thường các hãng sản xuất thiết

bị phần cứng chỉ hỗ trợ phần mềm cho một dòng thiết bị trong một khoảng thời gian nhất định với lý do hiệu năng phần cứng thiết bị không đủ đáp ứng yêu cầu của phần mềm phiên bản mới

Ngoài ra, sử dụng một hệ thống gồm nhiều thiết bị phần cứng riêng lẻ sẽ làm tăng tỷ lệ lỗi thiết bị trong hệ thống làm giảm tính ổn định, tính sẵn sàng của toàn bộ

hệ thống mạng

1.1.7 Sự cần thiết của một kiến trúc mới

Với những khuyết điểm đã chỉ ra của các hệ thống mạng hiện nay, chúng ta cần sử dụng một kiến trúc mạng mới ít phụ thuộc hơn vào các thiết bị phần cứng của các hãng sản xuất thiết bị, một kiến trúc cho phép quản lý tập trung, tùy biến nhiều hơn, linh hoạt hơn trong quá trình vận hành sử dụng cũng như giảm khó khăn, chi phí cho việc duy trì

1.2 SDN – Kiến trúc mạng tương lai

1.2.1 Định nghĩa

SDN (Software Define Network) được tổ chức Open Networking Foundation định nghĩa là kiến trúc trong đó lớp điều khiển (Control Plane) được tách rời khỏi lớp chuyển tiếp dữ liệu (Data Plane) và có khả năng điều khiển nhiều thiết bị khác nhau [2]

1.2.2 Kiến trúc SDN

Như định nghĩa nói trên, trong kiến trúc SDN lớp điều khiển (Control Plane) được tách rời khỏi lớp chuyển tiếp dữ liệu (Data Plane), ngoài ra trong kiến trúc SDN

còn có lớp ứng dụng (Application Plane) để hỗ trợ người dùng hoặc quản lý thông qua tương tác với lớp điều khiển Dưới đây là sơ đồ mô tả kiến trúc SDN

Hình 1.2: Kiến trúc SDN 1.2.3 Các thành phần trong kiến trúc SDN

Như vậy, kiến trúc SDN gồm ba lớp chính (Lớp Ứng dụng; Lớp Điều khiển; Lớp Chuyển tiếp Dữ liệu) và hai lớp giao tiếp phần mềm trung gian giữa ba lớp chính nói trên Tiếp theo chúng ta sẽ đi vào làm rõ khái niệm từng lớp (Cả lớp chính và lớp giao tiếp), cụ thể như sau:

- Lớp chuyển tiếp dữ liệu: Lớp này bao gồm các thiết bị mạng trực tiếp xử

lý và chuyển tiếp các gói dữ liệu đến đích tiếp theo Có thể coi nó như một thiết bị mạng logic, với năng lực xử lý được tính bằng tập hợp tài nguyên của một nhóm thiết

bị vật lý

Lớp chuyển tiếp dữ liệu bao hàm một hoặc nhiều công nghệ chuyển tiếp dữ liệu và có thể bao hàm cả những chức năng xử lý dữ liệu Những công nghệ và chức năng này có thể là những công nghệ xử lý chuyển tiếp giữa các giao diện vật lý của

các thiết bị hoặc chức năng nội tại thiết bị Đây là thành phần duy nhất mà kiến trúc SDN vẫn còn phải phụ thuộc vào các hãng sản xuất thiết bị phần cứng

- Lớp điều khiển: Được xây dựng dựa trên phần mềm, ta có thể hiểu nó giống

như thành phần trung gian điều hành, đưa ra quyết định dựa trên trạng thái của thiết

bị tại lớp chuyển tiếp dữ liệu và yêu cầu đầu vào từ lớp ứng dụng để điều hành và quản lý toàn bộ hệ thống mạng

Lớp điều khiển tự thiết lập và định nghĩa sơ đồ kết nối của khu vực lân cận trong mạng lưới, kiểm tra các gói tin, giải mã các giao thức mã hóa, quyết định đích đến cho các gói tin cũng như cách thức xử lý với các chúng Lớp điều khiển liên tục tích lũy và cập nhật thông tin để thích nghi với những thay đổi trên mạng lưới trong trường hợp xảy ra sự cố, đảm bảo quá trình trao đổi dữ liệu diễn ra nhanh chóng và tin cậy Lớp điều khiển cũng liên tục trao đổi thông tin với các hệ thống khác để tự động cập nhật khi có sự thay đổi

Những quyết định của lớp điều khiển được đưa ra dựa trên thông tin tổng quan

về hệ thống mạng mà nó thu được Với SDN, về mặt logic lớp điều khiển hoạt động như một trung tâm điều hành mạng độc lập duy nhất trong cả việc lập kế hoạch, giải quyết xung đột tài nguyên cũng như giao tiếp với hai lớp còn lại Trong một số trường hợp, các thành phần của lớp điều khiển có thể được cài đặt trên các thiết bị vật lý khác nhau để tiện cho việc kiểm soát hệ thống mạng

- Lớp ứng dụng: Thông qua lớp điều khiển để đưa vào các yêu cầu tác động

đến các thiết bị mạng tại lớp chuyển tiếp dữ liệu Trong lớp ứng dụng có thể chia thành hai lớp nhỏ theo mục đích sử dụng là:

Lớp quản lý: Mục đích của lớp này hướng tới là các tính năng đặc biệt (Tường lửa, Load Balance, DdoS, Video …) đòi hỏi quá trình giám sát chặt chẽ và tập trung vào nhiệm vụ xử lý thông tin bên trong gói tin nhiều hơn là các nhiệm vụ chuyển mạch hay định tuyến

Lớp dịch vụ: Mục đích của lớp này hướng tới cấu hình các thiết bị ở lớp chuyển tiếp dữ liệu (Như cấu hình giao thức định tuyến, cấu hình luồng dữ liệu …), qua đó thiết lập các phương pháp tương tác mạng

- Lớp Southbound API: Là lớp giao tiếp phần mềm giữa lớp điều khiển và

lớp chuyển tiếp dữ liệu, nó cung cấp chương trình điều khiển của toàn bộ hoạt động chuyển tiếp dữ liệu Southbound API cung cấp một giao diện mở, tương thích với các hãng sản xuất trung gian, Open Flow được thể hiện tại lớp này trong kiến trúc SDN

Open Flow là một chuẩn mở hiện đang được quản lý và phát triển bởi Open Networking Foundation, nó định nghĩa các chức năng và giao thức được sử dụng để quản lý chuyển mạch tập trung thông qua bộ điều khiển trung tâm Open Flow hiện

đã và đang được ứng dụng bởi các hãng sản xuất thiết bị mạng lớn trên thế giới, hiện tại đã có nhiều loại thiết bị hỗ trợ Open Flow

Tuy kiến trúc SDN không quy định rõ ràng về chuẩn sử dụng tại Southbound API nhưng ta có thể tạm coi như sẽ sử dụng chuẩn mở OpenFlow cho Southbound API Open Flow sẽ định nghĩa một tập hợp các lệnh mở để chuyển tiếp dữ liệu Những lệnh này cho phép các thiết bị định tuyến để xây dựng topo mạng, các thiết bị chuyển mạch xác định được cổng ra, dựa trên các yêu cầu ứng dụng gửi từ lớp ứng dụng

- Lớp Northbound API: Là lớp giao tiếp phần mềm giữa lớp điều khiển và

lớp ứng dụng, lớp này thường bao gồm ứng dụng quản lý dữ liệu và cung cấp các tính năng mạng cơ bản như tính toán tuyến đường, bảo mật, định tuyến

Hiện nay, không có tiêu chuẩn chính thức nào được công nhận rộng rãi cho Northbound API, có tới hàng chục giao thức mở cũng như độc quyền đã và đang được phát triển cho Northbound API Việc thiếu một tiêu chuẩn API có thể do tính chất đa dạng của các ứng dụng đang được sử dụng trong lớp điều khiển

1.2.4 Ưu điểm của kiến trúc SDN

Ưu điểm lớn nhất của kiến trúc SDN cũng chính là đặc điểm chính của kiến trúc này đó là tách rời lớp điều khiển và lớp chuyển tiếp dữ liệu, do đó lớp điều khiển

có thể cùng lúc thực hiện điều hành nhiều thiết bị phần cứng thuộc lớp chuyển tiếp

dữ liệu Sự tách biệt này cho phép chúng ta can thiệp sâu hơn, tùy chỉnh nhiều hơn trong việc kiểm soát, điều hành hệ thống, đồng thời giảm thiểu sự phụ thuộc vào các hãng sản xuất thiết bị phần cứng

Ưu điểm thứ hai của kiến trúc SDN là tư tưởng xây dựng các phần mềm và các chuẩn giao tiếp mở, tạo điều kiện cho đa dạng đối tượng có thể tham gia vào phát triển và hoàn thiện

Ưu điểm thứ ba của kiến trúc SDN là hệ thống được quản lý tập trung tại Controller do đó thuận lợi hơn trong việc thay đổi policy based routing, sửa lỗi cũng như chia sẻ tài nguyên trong hệ thống

Kiến trúc SDN đã và đang được quan tâm hỗ trợ bởi rất nhiều chuyên gia trong lĩnh vực mạng cũng như các công ty sản xuất thiết bị mạng hàng đầu, hiện tại đã có nhiều thiết bị phần cứng được các hãng sản xuất thiết bị đưa ra hỗ trợ chuẩn mở Open Flow, trong tương lai đây sẽ là một xu hướng kiến trúc mạng phổ biến

1.3 Đặt vấn đề, định hướng giải pháp

Đối với một hệ thống mạng có quy mô lớn phổ biến hiện nay (Hệ thống sử dụng các thiết bị mạng phần cứng) thì việc thiết lập, thay đổi policy based routing tự động theo thời gian là một vấn đề khá phức tạp Do đó, tôi lựa chọn vấn đề này để chứng tỏ tính ưu việt của một hệ thống mạng sử dụng kiến trúc SDN so với hệ thống mạng truyền thống

Trong mục này tôi sẽ trình bày cụ thể hơn những nhược điểm của hệ thống mạng phổ biến hiện nay trong vấn đề thiết lập, thay đổi policy based routing based routing tự động theo thời gian, sau đó đề xuất giải pháp và đưa ra phương pháp thử nghiệm để chứng minh cho tính ưu việt của giải pháp

1.3.1 Thiết lập, thay đổi policy based routing based routing tự động theo thời gian

Khối lượng công việc lớn và phức tạp

Trong hệ thống mạng có quy mô lớn phổ biến hiện nay, các thiết bị được chuyên môn hóa xử lý một hoặc một vài chức năng cụ thể và thông thường một hệ thống sẽ bao gồm nhiều loại thiết bị của nhiều hãng sản xuất thiết bị khác nhau Do

đó, khi muốn thiết lập, thay đổi policy based routing tự động theo thời gian cho hệ thống ta cần thay đổi cấu hình trên từng thiết bị cụ thể dẫn tới một khối lượng công việc không hề nhỏ và dễ sai sót, gây ảnh hưởng tới tính ổn định của hệ thống

Khó kiểm soát

Với việc thiết lập policy based routing based routing phân tán trên từng thiết

bị khiến cho chúng ta khó có được cái nhìn tổng thể trên toàn hệ thống, khó kiểm soát được sự ảnh hưởng khi thay đổi policy based routing trên một thiết bị đến sự hoạt động của toàn bộ hệ thống

Sai lệch về thời gian áp dụng

Một số thiết bị trong hệ thống không hỗ trợ thiết lập, thay đổi policy based routing tự động theo thời gian, khi đó muốn thay đổi policy based routing thì quản trị viên bắt buộc phải cấu hình thủ công trên thiết bị Trường hợp này sẽ dẫn tới vấn đề thời gian trễ trong việc áp dụng policy based routing cho hệ thống

Ngoài ra, thời gian được thiết lập trên các thiết bị phần cứng khác nhau không đồng nhất nên khi đặt lịch trên hai thiết bị để xác định thời gian thực thi policy based routing cho thiết bị thì thời điểm thực thi sẽ có sự sai khác nhất định

Cả hai vấn đề này đều sẽ gây ảnh hưởng tới sự ổn định của toàn bộ hệ thống mạng trong khoảng thời gian trễ hoặc trong khoảng thời gian sai lệch giữa các thiết

bị phần cứng

1.3.2 Định hướng giải pháp

Tất cả các vấn đề đã đưa ra đều có thể được giải quyết khi sử dụng một giải pháp đồng bộ gồm kiến trúc SDN với ứng dụng thiết lập, thay đổi policy based routing cho các thiết bị trong hệ thống và các thiết bị mạng hỗ trợ kiến trúc này

Khi đó chúng ta có thể thông qua ứng dụng tác động vào controller để thiết lập, thay đổi policy based routing cho bất kỳ thiết bị nào trong hệ thống thiết bị mà Controller quản lý Việc thiết lập policy based routing cho một thiết bị, một nhóm thiết bị hay toàn bộ hệ thống sẽ đơn giản, đồng nhất về mặt thời gian áp dụng và hạn chế khả năng gây lỗi cho hệ thống

Đồng thời, Controller luôn luôn cập nhật trạng thái của các thiết bị trong mạng lưới mà nó quản lý, do đó ta luôn có được cái nhìn tổng quan về hệ thống cũng như các policy based routing trên toàn bộ hệ thống và sự ảnh hưởng khi thay đổi policy based routing trên một thiết bị đến sự hoạt động của toàn bộ hệ thống

Ứng dụng thiết lập, thay đổi policy based routing cho các thiết bị trong hệ thống sẽ được xây dựng trên nền tảng phần mềm mã nguồn mở để tận dụng các hàm, các phương thức đã có

1.3.3 Phương pháp thử nghiệm giải pháp

Để minh họa cho khả năng thiết lập, thay đổi policy based routing tự động theo thời gian cho các thiết bị khi sử dụng kiến trúc SDN với ứng dụng phù hợp và các thiết bị mạng hỗ trợ kiến trúc này tôi sẽ xây dựng một mô hình mạng giả lập với quy

mô nhỏ như sơ đồ dưới đây:

Hình 1.3: Mô hình mạng thử nghiệm

Do hiệu năng thiết bị phần cứng thực hiện giả lập không lớn nên tôi chỉ xây dựng mô hình mạng giả lập rất đơn giản, tuy nhiên mô hình mạng trên vẫn là một hệ thống sử dụng kiến trúc SDN đảm bảo đủ ba lớp gồm lớp ứng dụng, lớp điều khiển

và lớp chuyển tiếp dữ liệu

Lớp ứng dụng chỉ có một ứng dụng để thiết lập và quản lý policy based routing cho các thiết bị hỗ trợ kiến trúc SDN thuộc lớp chuyển tiếp dữ liệu

Lớp điều khiển sử dụng phần mềm điều hành hệ thống mã nguồn mở cài đặt trên máy chủ Linux để điều khiển, kiểm soát hệ thống dựa trên trạng thái của thiết bị tại lớp chuyển tiếp dữ liệu và yêu cầu đầu vào từ lớp ứng dụng

Lớp chuyển tiếp dữ liệu chứa các thiết bị định tuyến ảo hỗ trợ chuẩn mở Open Flow, cho phép giao tiếp với lớp điều khiển Ban đầu tôi dự định xây dựng mô hình giả lập với tất cả các thiết bị ở lớp chuyển tiếp dữ liệu (Data Plane) đều hỗ trợ Open Flow, tuy nhiên do hiệu năng thiết bị giả lập hạn chế nên tôi chỉ có thể thiết lập được

02 máy ảo giả lập thiết bị định tuyến hỗ trợ Open Flow (Virtual Router 01 – (VR01 – A), VR02 - B), hai thiết bị định tuyến còn lại tôi giả lập bằng GNS3 sử dụng IOS của Cisco (VR03 – C, VR04 – D)

Mục tiêu là sử dụng chức năng phần mềm (tự phát triển) được cài đặt trên máy chủ thuộc lớp ứng dụng (Application Plane) để thiết lập, thay đổi policy based routing

tự động theo thời gian cho các thiết bị thuộc lớp chuyển tiếp dữ liệu (Data Plane) sao cho đến thời điểm T nhất định thì tuyến đường của gói tin từ VR01 đến VR04 tự động thay đổi từ VR01  VR02  VR04 thành VR01  VR02  VR03  VR04

Chương 2 Lựa chọn công nghệ

Chương này tôi sẽ trình bày về quá trình lựa chọn công nghệ để giải quyết bài toán với mô hình và mục tiêu nói trên

2.1 Lựa chọn giải pháp ảo hóa

Mô hình tôi xây dựng chủ yếu dựa trên các thiết bị ảo, do đó lựa chọn giải pháp ảo hóa phù hợp là một yêu cầu rất quan trọng, dưới đây là những giải pháp ảo hóa tôi đã tìm hiểu trong quá trình lựa chọn giải pháp ảo hóa phù hợp nhất với quy

mô đồ án của mình:

2.1.1 Ảo hóa một phần (Para-virtualization)

Ảo hóa một phần (Para-virtualization) là công nghệ ảo hóa được hỗ trợ và điều khiển bởi một Hypervisor (phần mềm phía trên phần cứng nhằm tạo và quản lý các phân vùng tách biệt để cài đặt các máy ảo) nhưng các lệnh thực thi của các máy ảo không phải thông qua Hypervisor nên không bị hạn chế về quyền hạn

Hình 2.1: Mô hình ảo hóa một phần (Para-virtualization)

Nhược điểm của loại ảo hóa này là quá trình cài đặt, cấu hình khó khăn

2.1.2 Ảo hóa hoàn toàn (Full-virtualization)

Ảo hóa hoàn toàn (Full-virtualization) là công nghệ ảo hóa cho phép tạo ra các máy ảo tương tự như một máy thật hoàn chỉnh với đầy đủ các tính năng như điều

hành vào/ra, xử lý bộ nhớ, xử lý ngắt … Các hoạt động của máy ảo phải thông qua một trình quản lý máy ảo (Virtual Machines monitor hoặc Hypervisor) để tương tác đến tài nguyên hệ thống

Hình 2.2: Mô hình ảo hóa hoàn toàn (Full-virtualization)

Công nghệ ảo hóa này sẽ bị hạn chế bớt 1 số tính năng khi cần thực hiện thao tác trực tiếp từ CPU tuy nhiên sẽ an toàn và dễ dàng cấu hình, cài đặt hơn

2.1.3 Ảo hóa mức hệ điều hành (OS-level virtualization)

Ảo hóa mức hệ điều hành (OS-level virtualization) còn gọi là Containers Virtualization hay Isolation là công nghệ ảo hóa mới cho phép tạo và chạy được nhiều máy ảo cách ly và an toàn dùng chung một hệ điều hành

Hình 2.3: Mô hình ảo hóa mức hệ điều hành (OS-level virtualization)

Ưu điểm của công nghệ ảo hóa này là chi phí thấp và bảo trì nhanh chóng nên được ứng dụng rộng rãi trong các lĩnh vực ảo hóa desktop Loại ảo hóa Isolation này chỉ tồn tại trên hệ điều hành Linux

2.1.4 Phương án lựa chọn

Cả ba công nghệ ảo hóa nói trên đều có những ưu, nhược điểm nhất định, tuy nhiên để đơn giản cho việc cài đặt môi trường giả lập và ổn định trong quá trình thực hiện tôi lựa chọn công nghệ ảo hóa hoàn toàn (Full-virtualization)

Trong công nghệ ảo hóa hoàn toàn có một số sản phẩm phổ biến là VMWare workstation, Virtual Box, Microsoft Virtual Server Sau khi thử nghiệm các phần mềm ảo hóa này tôi quyết định sử dụng VMWare workstation làm công cụ ảo hóa vì những ưu điểm sau:

- Tính ổn định cao;

- Hỗ trợ lên đến 16 card mạng ảo;

- Nhiều tài liệu hướng dẫn hỗ trợ

2.2 Lựa chọn thành phần điều khiển (Controller)

Như đã mô tả trong các phần trước, lớp điều khiển đóng vai trò rất quan trọng trong kiến trúc SDN, có thể hiểu lớp điều khiển giống như một trung tâm điều hành toàn bộ hệ thống mạng tương tự vai trò của hệ điều hành đối với một máy tính Do

đó, việc tìm hiểu, lựa chọn thành phần điều khiển phù hợp đóng vai trò hết sức quan trọng và ảnh hưởng trực tiếp đến quá trình thực hiện đồ án của tôi, dưới đây là một

số tiêu chí tôi đặt ra cho việc lựa chọn thành phần điều khiển:

- Một sản phẩm mã nguồn mở cho phép tùy biến và điều chỉnh các chức năng của thành phần điều khiển

- Đã được xây dựng khá hoàn chỉnh và có các API hỗ trợ lập trình viên truy cập vào thao tác với các chức năng mà không làm thay đổi mã nguồn

- Cài đặt, triển khai không quá phức tạp

- Hoạt động ổn định và được cập nhật, phát triển thường xuyên

- Cộng đồng phát triển lớn với nhiều thành viên tham gia tích cực có chuyên môn sâu trong lĩnh vực mạng

- Tài liệu hướng dẫn phong phú

Trong số các Controller đã và đang được phát triển chỉ có hai sản phẩm đáp ứng được hầu hết các tiêu chí đưa ra là Floodlight được hỗ trợ phát triển bởi Bigswitch

và OpenDaylight được phát triển và hỗ trợ bởi nhiều công ty sản xuất thiết bị trong lĩnh vực mạng hàng đầu trên thế giới như Cisco, IBM, Brocade, Juniper … Tiếp theo tôi sẽ phân tích kỹ hơn về hai sản phẩm này để đưa ra lựa chọn thành phần điều khiển phù hợp nhất

2.2.1 OpenDaylight

Sản phẩm của một dự án xây dựng bộ điều khiển được sự hỗ trợ nghiên cứu phát triển của nhiều công ty sản xuất thiết bị lớn trên thế giới OpenDaylight là sản phẩm có đội ngũ nhân sự nghiên cứu, phát triển chuyên nghiệp từ các công ty lớn và

hệ thống tài liệu hỗ trợ phát triển phong phú, do đó các tính năng hỗ trợ điều khiển

hệ thống của OpenDaylight hoàn thiện hơn so với các sản phẩm điều khiển hệ thống

cùng loại khác Ngoài ra OpenDaylight cũng là một sản phẩm cung cấp các API hỗ trợ giao tiếp với bộ điều khiển rất tốt

Một nhược điểm của OpenDaylight là được phát triển bởi các công ty sản xuất thiết bị mạng lớn trên thế giới nên không thể tránh khỏi việc nó được phát triển “ưu ái” hơn cho lợi ích của các hãng sản xuất thiết bị này Cisco ngoài hỗ trợ dự án phát triển OpenDaylight họ cũng tự phát triển một bộ điều khiển hệ thống cho riêng mình dựa trên nền tảng OpenDaylight là XNC controller hỗ trợ tốt cho các thiết bị phần cứng của họ

2.2.2 Floodlight

Floodlight là sản phẩm của một dự án xây dựng bộ điều khiển được hỗ trợ phát triển bởi BigSwitch Network, công ty đi đầu trong lĩnh vực nghiên cứu và phát triển kiến trúc SDN Khác với OpenDaylight, cộng đồng phát triển Floodlight chủ yếu là những nhà phát triển phi lợi nhuận giống như hầu hết các dự án nguồn mở khác Floodlight hỗ trợ cộng đồng phát triển tiếp cận với các chức năng của nó thông qua REST API, đây cũng là một trong những dự án có cộng đồng phát triển và thư viện tài liệu hỗ trợ lớn nhất [7]

2.2.3 Giải pháp lựa chọn

Có thể nói hiện tại OpenDaylight là bộ điều khiển ưu việt hơn, với nhiều tính năng hỗ trợ hoàn thiện, lực lượng nghiên cứu và phát triển chuyên nghiệp, tài liệu hỗ trợ phong phú Tuy nhiên đây không hoàn toàn là một sản phẩm mã nguồn mở do có

sự can thiệp sâu của các hãng sản xuất thiết bị, do đó nếu xét trên tất cả các tiêu chí

đã đưa ra thì Floodlight là giải pháp phù hợp nhất với mô hình mà tôi xây dựng

2.3 Lựa chọn công nghệ cho lớp chuyển tiếp dữ liệu

Để mô phỏng một thiết bị định tuyến hỗ trợ chuẩn giao tiếp Open Flow trong lớp chuyển tiếp dữ liệu (Data Plane) tôi sẽ cài đặt một phần mềm giả lập thiết bị định tuyến và một phần mềm giả lập thiết bị chuyển mạch hỗ trợ Open Flow trên cùng một máy chủ Linux (Máy chủ ảo sử dụng hệ điều hành Ubuntu 64bit trên nền tảng ảo hóa VM-Ware Work Station), sau đó cấu hình luồng dữ liệu như mô hình dưới đây:

Hình 2.4: Mô hình ảo hóa thiết bị lớp chuyển tiếp dữ liệu (Data Plane)

Tiếp theo, tôi sẽ trình bày về quá trình lựa chọn phần mềm và cho việc mô phỏng thiết bị nói trên:

Bird là một phần mềm định tuyến ra đời sau, do đó nó được thiết kế khá tốt để tránh các lỗi của những phần mềm định tuyến thế hệ trước và hỗ trợ hầu hết các tính năng của một thiết bị định tuyến thông thường [4] Một số ưu điểm của Bird có lợi cho

mô hình giả lập của tôi là:

- Quá trình cài đặt và sử dụng dễ dàng;

- Hoạt động ổn định, thời gian đáp ứng nhanh và không yêu cầu cao về phần cứng thiết bị;

- Hỗ trợ hầu hết các giao thức định tuyến như Routing Information Protocol (RIPv2); Open Shortest Path First (OSPFv2, OSPFv3);

- Linh hoạt trong việc cấu hình thiết bị (bằng giao diện dòng lệnh hoặc chỉnh sửa file cấu hình)

Theo các thử nghiệm gần đây thì trong cùng một công việc Bird luôn có thời gian đáp ứng tốt hơn và tiêu tốn ít tài nguyên hệ thống hơn Quagga Với các ưu điểm như vậy tôi quyết định chọn Bird là phần mềm định tuyến cho mô phỏng của mình Bird hỗ trợ cả hai phiên bản IPv4 và IPv6, để tránh phức tạp tôi sẽ chỉ cài đặt và sử dụng phiên bản IPv4 cho mô hình của mình

2.3.2 Lựa chọn phần mềm chuyển tiếp dữ liệu

Phần mềm này ngoài chứng năng giả lập cách thức làm việc của một thiết bị chuyển mạch còn phải hỗ trợ chuẩn mở Open Flow để đảm bảo khả năng giao tiếp với bộ điều khiển Floodlight Controller đã chọn Các yêu cầu này phù hợp với tính năng của OpenvSwitch và gần như chỉ có OpenvSwitch đáp ứng được, do đó tôi quyết định chọn OpenvSwitch là phần mềm chuyển tiếp dữ liệu trong mô phỏng của mình

2.3.3 Giải pháp kết nối nội bộ

Sau khi cài đặt Bird và OpenvSwitch lên cùng một máy chủ Linux thì Bird sẽ nhận cổng giao tiếp của máy chủ làm cổng giao tiếp cho bản thân nó Ta cần cấu hình lại thiết bị để Bird phải thông qua OpenvSwitch để giao tiếp với các cổng giao tiếp của máy chủ Giải pháp đưa ra là tạo các cặp cổng giao tiếp ảo để kết nối giữa Bird

và OpenvSwitch như sau:

Bird: (Veth 1)  OpenvSwitch (Ovs Veth 1)

Bird: (Veth 2)  OpenvSwitch (Ovs Veth 2)

…

Bird: (Veth n)  OpenvSwitch (Ovs Veth n)

Sau đó cấu hình cho bird sử dụng các cổng Veth và gán các cổng Ovs Veth vào OpenvSwitch, ngoài ra để OpenvSwitch có thể nhận các cổng của máy chủ làm