1. Trang chủ
  2. » Luận Văn - Báo Cáo

Khóa luận tốt nghiệp Mạng máy tính và truyền thông dữ liệu: Thiết kế và triển khai giao diện liên cụm cho bộ điều khiển mạng khả lập trình

59 6 0
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Thiết kế và triển khai giao diện liên cụm cho bộ điều khiển mạng khả lập trình
Tác giả Trần Hoàng Long
Người hướng dẫn ThS. Nguyễn Khánh Thuật
Trường học Đại học Công nghệ Thông tin
Chuyên ngành Mạng máy tính và truyền thông
Thể loại khóa luận tốt nghiệp
Năm xuất bản 2024
Thành phố TP. Hồ Chí Minh
Định dạng
Số trang 59
Dung lượng 55,59 MB

Nội dung

Tác giả dự kiến cơ sở thông tin mạng giữa hai cụm sẽ được đồng bộ, và các hệ thống điều khiển mạng trên các cụm có thể nhìn thấy vùng mạng của nhau.. Mặc dù mục đích ban đầu của SDN bao

Trang 1

ĐẠI HỌC QUOC GIA THÀNH PHO HO CHÍ MINH

TRƯỜNG DAI HỌC CONG NGHỆ THONG TIN KHOA MẠNG MAY TÍNH VÀ TRUYEN THONG

TRAN HOANG LONG - 20520625

KHOA LUAN TOT NGHIEP

DESIGNING AND DEPLOYING AN INTER-CLUSTER INTERFACE FOR

THE SOFTWARE DEFINED NETWORK CONTROLLER.

CỬ NHÂN NGÀNH MẠNG MAY TÍNH VA TRUYEN THONG DU LIEU

GIANG VIÊN HƯỚNG DẪN ThS Nguyễn Khánh Thuật

TP HO CHÍ MINH, 2024

Trang 2

LỜI CẢM ƠN

Trong quá trình nghiên cứu và hoàn thành đồ án, tác giả đã được thầy NguyễnKhánh Thuật định hướng, giúp đỡ và cho ý kiến đóng góp trong suốt thời gian lên ýtưởng và thực hiện bài khoá luận này Đồng thời, sự hộ trợ và các nguồn thông tin

từ các anh/chi/ban đang công tác va học tập tại Phòng thí nghiệm Mang máy tính và

truyền thông đã tạo điều kiện cho quá trình thực hiện khóa luận của tôi.

Bên cạnh đó, tôi vô cùng biết ơn gia đình, người thân và bạn bè đã là nguồn độngviên và chỗ dựa về mặt tinh thần trong suốt khoảng thời gian này

Tôi cũng chân thành cảm ơn các quý thầy cô trường Đại học Công nghệ Thôngtin - ĐHQG TP.HCM, đặc biệt là các thầy cô thuộc khoa Mạng máy tính và truyền

thông đã giúp đồ tôi.

Trần Hoàng Long

li

Trang 3

TOM TAT

Software Define Networking (SDN) là hướng tiếp cận mang mới, cho phép táchtầng điều khiển khỏi tầng dữ liệu Trong khi đó, kiến trúc vi dịch vụ cho phép táchứng dụng thành các thành phần nhỏ hơn, giúp tăng sự linh hoạt trong triển khai cũng

như khả năng dự phòng của hệ thống Cả hai khái niệm trên hiện tại đã được ứng dụng rộng rãi trên các nền tảng đám mây cũng như hệ thống phân tán.

Để tăng tính phân tán của hệ thống, khóa luận dé xuất việc triển khai giao diệnliên cụm cho mạng khả lập trình trên các nền tảng điều phối vi dịch vụ Phươngpháp tập trung vào việc hợp nhất đầu vào các không gian lưu trữ thuộc hai miền

mạng, nhân bản và phân bố đều lưu lượng mạng từ các dịch vụ điều khiển đến các không gian lưu trữ này Tác giả dự kiến cơ sở thông tin mạng giữa hai cụm sẽ được đồng bộ, và các hệ thống điều khiển mạng trên các cụm có thể nhìn thấy vùng mạng

của nhau Thông qua đánh giá từ mô hình này, tác giả đưa ra các đề xuất và hướngphát triển tiếp theo cho đề tài

1H

Trang 4

MỤC LỤC

Thông tin hội đồng bảo vệ khóa luận i

Lời cảm on ii

Tóm tat iii

Muc luc iv

Danh muc cac bang viii

Danh mục các hình vẽ và đồ thị ix

Danh mục từ viết tat Xx

Chương1 Mở dau 1

11 Lýdochọnđểtài 1

1.2 Tính khoa học và tnhmới - 2

1.3 Mục tiêu, đối tượng và phạm vi nghiên cứu 2

1.3.1 Mục tiêunghiên cỨu 2

1.3.2 Đối tượng và phạm vi nghiên cứu 2

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

1.4.1 Nội dung 1: Tìm hiểu về kiến trúc SDN, uONOS, Docker va Kubernetes ee ee 2 1.4.2 Nội dung 2: Xác định mô hình giao tiếp giữa các cụm Kuber-meteS Ắa TT 3 1.4.3 Nội dung 3: Thiết kế mô hình trao đổi giữa các cụm HONOS 3 1.4.4 Nội dung 4: Hiện thực hoá dưới dang ứng dụng hoặc dich vụ 4 1.4.5 Nội dung 5: Triển khai thực nghiệm, đánh giá và báo cáo 4

1.5 Cac đóng góp chính của đềtài - 5

1.6 Cấu trúc Khoá luận tốtnghiệp - 5

Chương 2 Cơ sở lý thuyết 6 2.1 Mạng khả lập trình (Software-Defined Network,SDN) 6

1V

Trang 5

MỤC LỤC

2.1.1 Tổng quan về Mang khả lập trình (Software-Defined Network,

2.1.2 Các thành phần của Mạng khả lập trình (Software-Defined

2.1.3 Phan tán tầng điều khiển - §

2.2 Nhân bản dữ liệu và đồng bộ dữ liệu 9

2.2.1 Nhân bản dữliệu 9

2.2.2 Đồng bộ dữliệu - 9

2.2.3 Một số mô hình nhân bản và đồng bộ 10

2.2.3.1 Gửi trực tiếp nhiều bản sao đến các cơ sở dữ liệu 10

2.2.3.2 Sao chép lưu lượng bằng thành phan mạng trung gian 11 2.2.3.3 Đồng bộ nganghàng 12

2.2.3.4 Các cơ sở dữ liệu (CSDL) đồng bộ theo cấp 13

2.3 Thuật toán đồngthuận - 14

2.3.1 Paxos i vs à ì\ / 15

2.3.2 Raft? gue yep VW | / 17

2.3.3 Multi-Raft 2.2 0 ee eee 20 2.4 Kiến trúc vi dịch vụ (Micro-services architecture) 21

2.4.1 Tổng quan kiến trúc vidichvu - 21

2.4.2 Điều phối container - Kubernetes - 21

2.5 Cân bằng tải và nhân bản lưu lượng - 24

2.5.1 Cân bằng tải eee 24 2.52 Nhân bản lưu lượng 25

2.6 Các công trình lên quan Ặ 26 Chương 3 Thiết kế hệ thong 27 3.1 Thiếtkếhệthống cSẶẶSẶV 27 3.1.1 Bộ điều khẩểnmạng 28

3.1.2 Hệ thống lưutrữ 29

3.1.3 Giao diện mang Container cho kiến trúc vi dịch vụ 30

3.1.4 Giao tiếp liên cụm với Cilium ClusterMesh 31

Trang 6

MỤC LỤC

3.2 Triển khaihệthống - 32

3.2.1 Cài đặt môi trường 32

3.2.2 Phân bố các dịch vụ trên Kubernetes 33 3.2.3 Cauhinh Ặ Q Q Q Q HQ HQ ee 33

Chương 4 Thực nghiệm, đánh giá và thảo luận 36

4.2.1.3 Mức tiêu thụ CPU trung bình của từng dịch vụ (%) 38

4.2.1.4 Mức tiêu thụ bộ nhớ trung bình của từng dịch vụ (MB) 38

4.2.1.5 Tỉ lệ mất gói tin khi bộ điều khiển gặp sự cố(%) 384.2.1.6 Thời gian phục hồi dữ liệu sau sự cố (giây) 39

4.2.2 Các công cụ đánh giá 39

423 Kẩqu GP SA'S /, Ố ee 39

4.2.3.1 Độ trễ thiết lập luồng 39 4.2.3.2 _ Độ trễ phát hiện thay đổi mạng 40

4.2.3.3 Mức tiêu thụ CPU trung bình của từng dịchvụ 40

4.2.3.4 Mức tiêu thụ bộ nhớ trung bình của từng dich vu 4l

4.2.3.5 Tỉ lệ mất gói tin khi bộ điều khiển gặp sự cố 41 4.2.3.6 Thời gian phục hồi dữ liệu sau sựcố 42

4.2.4 Nhận định chung về kếtquả - 42

Chương 5 Kết luận và hướng phát triển 43

51 Kếtluận ẶẶ Qua 43

53 Hướng pháttriển ẶẶcẶQso 44

Tài liệu tham khảo 47

Phụ lục A Cài đặt môi trường triển khai 48

VI

Trang 7

MỤC LỤC

A.1 Phiénban Linux ẶẶ KV Ặ Ặ So 48

A.2 Cài đặtDocker Ặ.Ặ.ẶẶẶẶ Q ee eee 48

A.3 Cài đặt kind và kubectl Ặ.Ặ 48 A.4 Cài đặtHelm Ặ.Ặ ẶQẶ Q QQ Q Sc 49

A.5 Cài đặt và cấu hình công cu Wireshark 49

vil

Trang 8

4.1

4.2

4.3

4.4

4.5

4.6

DANH MUC CAC BANG

So sánh Raft và Paxos Q Q ee ee es 19

Độ trễ thiết lập luồng - 39

Độ trễ phát hiện thay đổ mạng 40

Mức tiêu thụ CPU trung bình của từng dịch vụ 41

Mức tiêu thu RAM trung bình của từng dịchvụ 41

Ti lệ mat gói tin khi bộ điều khiển gặp sựcỗố 42

Thời gian phục hồi dữ liệu sausựcỗố - 42

VII

Trang 9

DANH MỤC CÁC HÌNH VẼ VÀ ĐỒ THỊ

2.1 Mô hình kiến trúc một Mang khả lập trình (Software-Defined

2.2 Mô hình tầng điều khiển SDN phẳng [5]} 9

2.3 Mô hình tầng điều khiển SDN phẳng [5] - 10

2.4 Bên gửi gửi nhiều ban sao đến các cơ sở dữ ligu(CSDL) 10

2.5 Sao chép lưu lượng qua bằng thành phần mạng trung gian 12

2.6 Hai cơ sở dữ liệu (CSDL) đồng bộ ngang hàng với nhau 13

2.7 Hai cơ sở dit liệu (CSDL) thành viên cùng kết nối với cơ sở dữ liệu (CSDL) trungtâm ẶẶẶ.Ặ 14 2.8 Các vai trò trong Paxos: các Proposer dé xuất giá tri tới các Acceptor; các Learner học các giá trị được chấp nhận bởi Acceptor! 16

2.9 Quá trình chon leader củaRaf?7 18

2.10 Multi-Raft với 4 nút và4 nhóm _ - 20

2.11 So sánh kiến trúc container (trái) và máy ảo (phải)* 22

2.12 Kiến trúc kubernetesŠ 22

2.13 Cơ chế nhân bản lưu lượng 25

3.1 Mô hình kiến trúc tổng quát - 27

3.2 Các thành phan quan trọng của Micro-.ONOS_ 29

3.3 Chia sé dịch vụ giữa các cụm với Cluster Mesh” 31

3.4 Cấu trúcmạng mô phỏng - 33

3.5 Phân bố các dịch vụ trên cum Kubernetes - 34

3.6 Dịch vụ cân bằng tải được đặt ở giữa ONOS và Atomix 34

3.7 gRPCRoute giúp định tuyến dich vụ đi vào dich vụ RaftLB 35

3.8 Cấu hình CoreDNS nhằm tìm tên miền thuộc cụm khác 35

4.1 Giao diện web của Micro-.ONOS 36

4.2 Giao diện dòng lệnh của Micro-ONOS khi thêm thiếtbj 36

4.3 Mô phỏng các thiết bị Stratum qua giao diện FabricSimulator 37

4.4 Cấu hình giao tiếp được hỗ trợ bởi thiếtbj 37

1X

Trang 10

DANH MỤC TU VIET TAT

giao dién mang container (container network interface) giao dién runtime cho container (container runtime inter- face)

Trang 11

Chương 1 MỞ ĐẦU

1.1 Lý do chọn dé tài

Mạng khả lập trình (Software-Defined Network, SDN) là một công nghệ mạng

mới, ra đời vào đầu thế kỷ 21, và được xem như một sự cải tiến, cách mạng cho côngnghệ mạng truyền thống SDN ban đầu được xác định bởi: ¡ Sự tách tầng điều khiển(quyết định cách lưu lượng được xử lý) khỏi tầng dữ liệu (chuyển tiếp lưu lượng dựatrên sự quyết định của tầng điều khiển); ii Sự hợp nhất tầng điều khiển, cho phép

một phần mềm điều khiển tác động lên nhiều thành phần thuộc tầng dữ liệu thông

qua các API.

Mặc dù mục đích ban đầu của SDN bao gồm việc tập trung tầng điều khiển thành

một khối, việc tạo ra tầng điều khiển tập trung về vật lý có một số nhược điểm: một

bộ điều khiển SDN cho toàn mạng đồng nghĩa nó là điểm chịu lỗi duy nhất của hệthống; bộ điều khiển duy nhất cho một mạng lớn dễ bị quá tải trước số lượng yêucầu lớn, khiến nó trở thành nút cổ chai trong hệ thống mạng

Vì các lý do trên, các ý tưởng cho mô hình đa điều khiển đã ra đời Tuy nhiên, các mô hình đa điều khiển vẫn không đảm bảo hoàn toàn tính phân tán của lớp điều

khiển bởi một vấn đề: phần lớn các nền tảng điều khiển SDN hiện nay vẫn đượctriển khai ở thể nguyên khối Với mỗi bản sao của bộ điều khiển, toàn bộ tài nguyênphần cứng và phần mềm được yêu cầu phải được triển khai giống các bản còn lại

nhằm đảm bảo tính nhất quán Việc này gây lãng phí tài nguyên tính toán và hạn chế

hiệu suất của lớp điều khiển Một giải pháp được đưa ra là chia nhỏ bộ điều khiển

thành các vi địch vụ theo chức năng và triển khai chúng dưới dạng các container.

Khoá luận tập trung giải quyết van dé kết nối giữa nhiều vùng địa lý đối với bộđiều khiển uONOS (Micro-ONOS) Đây là bộ điều khiển mới, cho phép sử dụng

các giao diện điều khiển và cấu hình mang mới (chang hạn, P4/P4Runtime,

gN-MI/OpenConfig, gNOI, ), cũng như kiến trúc vi dịch vụ.

Trang 12

CHƯƠNG I MỞ ĐẦU

1.2 Tính khoa học và tính mới

1.3 Mục tiêu, đối tượng và phạm vi nghiên cứu

1.3.1 Mục tiêu nghiên cứu

¢ Hiểu và áp dụng thuật toán về đồng thuận dữ liệu, các thành phần mang máy

tính và SDN.

* Triển khai SDN với bộ điều khiển thế hệ mới pONOS.

» Xây dựng mô hình trao đổi dữ liệu giữa các miền địa lý, thiết kế hệ thống mạng

dịch vụ sử dụng công nghệ Kubernetes.

1.3.2 Đối tượng và phạm vi nghiên cứu

Đối tượng nghiên cứu: SDN, Cơ sở dữ liệu phân tán, Thuật toán đồng thuận,Kiến trúc mạng dịch vụ Kubernetes

Phạm vi nghiên cứu: Trao đổi dữ liệu giữa hai hệ thống thuộc tầng điều khiển

SDN đặt ở hai vị trí địa lý khác nhau.

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

1.4.1 Nội dung 1: Tìm hiểu về kiến trúc SDN, uONOS, Docker và Kubernetes

Mục tiêu:

¢ Hiểu được kiến trúc và phạm vi ứng dụng SDN

» Hiểu được kiến trúc bộ điều khiển uONOS

¢ Hiểu được các khái niệm, kiến trúc và cách vận hành của Docker và

Kuber-netes.

Phuong phap:

» Kế thừa kiến thức từ đồ án chuyên ngành

* Tìm hiểu mã nguồn của WONOS.

s Tìm thêm các tài liệu chính thức về Docker và Kubernetes.

2

Trang 13

CHUONG 1 MỞ ĐẦU

1.4.2 Nội dung 2: Xác định mô hình giao tiếp giữa các cụm Kubernetes

Mục tiêu:

« Đánh giá các giải pháp giao tiếp liên cụm Kubernetes sẵn có

* Ap dụng hoặc thiết kế mô hình giao tiếp liên cum Kubernetes

Phương pháp:

* Đọc các công trình và khảo sát liên quan

* Tìm hiểu tài liệu kỹ thuật chính thức của các giải pháp nếu đã có sản phẩm

* Tham khảo các kết quả so sánh và đánh giá sẵn có

* Bổ sung và cải tiến nếu cần thiết

* Dựng lại sơ đồ cho mô hình sẽ được sử dụng

1.43 Noi dung 3: Thiết kế mô hình trao đổi giữa các cụm ONOS

Mục tiêu:

* Phác hoạ được cấu trúc dữ liệu cần trao đổi, đường truyền liên cụm, nơi tiếp

nhận, xử lý và lưu trữ thông tin mạng liên miền từ các cụm uONOS khác

« Xây dựng được sơ đồ cho các quá trình gửi, nhận và xử lý các gói tin và quy

tắc, quá trình đồng bộ thông tin trạng thái lớp dữ liệu giữa các cụm điều khiển

Phương pháp:

* Sử dụng các mô hình kiến trúc HONOS và kiến trúc giao tiếp liên cum

Kuber-netes từ các nội dung trước làm ngữ cảnh thiết kế

s Phân tích mã nguồn pONOS và tham khảo các tài liệu liên quan

« Phác hoạ mô hình dưới dạng sơ đồ và thể hiện mối liên hệ cùng các tương tác

giữa các thành phần trao đổi liên cụm với nhau cũng như các thành phần còn

lai trong cụm HONOS

Trang 14

* Viết mã nguồn chương trình bằng ngôn ngữ Go (được dự án uONOS sử dụng)

» Đóng gói phần mềm thành một hoặc nhiều vi dịch vụ chạy trong các Docker

container

* Viét kịch bản triển khai (các) vi dịch vụ thành pod trên Kubernetes.

1.4.5 Nội dung 5: Triển khai thực nghiệm, đánh giá và báo cáo

Mục tiêu:

* Chạy được phần mềm đã xây dựng trên cụm uONOS, đảm bảo các tính năng

trao đối thông tin liên cum

« Đánh giá hiệu năng, xác định được ưu, nhược điểm và hướng phát triển

¢ Hoàn thành khoá luận và báo cáo

Phương pháp:

« Triển khai các cụm uONOS bằng Kubernetes

* Do các hiệu suất xử lý gói tin vào bằng iperf

* Do thời gian trao đổi các gói tin liên quan tới tương tác cụm bằng wireshark

¢ Do thời gian ping giữa hai máy ở hai cụm khác nhau

* Do lượng tài nguyên tính toán được sử dụng

Trang 15

CHƯƠNG I MỞ ĐẦU

1.5 Các đóng góp chính của đề tài

* Tổng hợp một số van dé đã có của tầng điều khiển SDN

* Phân tích các thuật toán đồng thuận và ứng dụng trong các cơ sở dữ liệu phân

tán.

* Đánh giá kiến trúc mang dich vu được sử dụng để triển khai các chức năng của

tầng điều khiển.

1.6 Cấu trúc Khoá luận tốt nghiệp

Khóa luận với đề tài "THIẾT KẾ VÀ TRIỂN KHAI GIAO DIỆN LIÊN CỤM CHO BỘ ĐIỀU KHIỂN MẠNG KHẢ LẬP TRÌNH" được trình bày bao gồm 5

chương Nội dung tóm tắt từng chương được trình bày như sau:

* Chương 1: Mở đầu.

* Chương 2: Cơ sở lý thuyết.

» Chương 3: Phương pháp thực hiện.

« Chương 4: Thực nghiệm, đánh giá va thảo luận.

* Chương 5: Kết luận và hướng phát triển.

Trang 16

Chương 2 CƠ SỞ LÝ THUYET

Trong chương này, tôi sẽ trình bày các nền tảng lý thuyết được vận dụng trongquá trình thực hiện khóa luận Các nền tảng này bao gồm các khái niệm, nguyên

lý cùng các thuật toán Các nội dung sẽ được trình bày bao gồm: SDN, giao thức

gMNI và gNOI, mạng container và kiến trúc vi dịch vụ, Docker và Kubernetes, các giao thức định tuyến liên cụm Kubernetes

2.1 SDN

2.1.1 Tong quan ve SDN

Ý tưởng về một mạng có thé được lập trình được dé xuất từ giữa thập niên 1990,

khi Internet bắt đầu bùng nổ Vào khoảng thời gian ấy, các nhà nghiên cứu đã nhận

thấy rằng, các mô hình mạng truyền thống rất thiếu linh hoạt và cần rất nhiều bước

để xây dựng, thử nghiệm, phát triển và chuẩn hóa các ý tưởng mới Do đó, một sốnhà nghiên cứu đã theo đuổi một hướng tiếp cận mới, gọi là Active Networking (Mô

hình mạng chủ động) Y tưởng của Active Networking là cài đặt một giao diện lập

trình lên thiết bị mạng, cho phép người lập trình tương tác với một số tài nguyên

va thay đổi các chức năng xử lý gói tin [1] Active Networking cũng cho phép tích

hợp một cách đồng nhất các dịch vụ trung gian như tường lửa, proxy, giúp đơn

giản hóa việc triển khai và quản lý các dịch vụ Các ý tưởng cho Active Networking

chính là tiền đề cho quá trình phát triển SDN từ giữa những năm 2000, bắt đầu với

sự phát triển của giao thức điều khiển thiết bị mạng OpenFlow

Có nhiều cách định nghĩa khác nhau cho SDN Trong khóa luận, người thực hiện

sử dụng các định nghĩa được nêu trong sách Software-Defined Networks: A Systems

Aproach [2] và được Tổ chức Mạng Mở (ONF) chấp nhận:

* "Software Define Networking là một cách tiếp cận về cách triển khai mạng "

* “Software-Defined Network là mạng với tầng điều khiển được tách khỏi tang

chuyển tiếp gói tin về mặt vật lý, và một tầng điều khiển duy nhất điều khiển

nhiều thiết bị chuyển tiếp gói tin."

Vì sự ngắn gọn của định nghĩa, SDN về cơ bản giống như một ý tưởng, một

Trang 17

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT

hướng tiếp cận để giải quyết các van dé trong mang máy tính Cũng vì thế, có nhiều

phương pháp khác nhau để hiện thực hóa SDN Tuy vậy, chúng đều có điểm chung:

cho phép sử dụng các phần mềm tại tầng điều khiển để tương tác với toàn bộ hạ tầng

mạng thông qua các giao diện chuyên dụng Ngoài ra, khác với các mô hình mạng

truyền thống chỉ sử dung các thiết bị cứng (switch, router, ) trên mạng vật lý, SDN

cho phép điều khiển cả mạng vật lý lẫn mạng ảo

2.1.2 Các thành phần của SDN

Theo Liang và Li [3], một mang SDN có thể được chia thành năm thành phần

như sau: tầng ứng dụng (application plane), giao diện northbound, tầng điều khiển

(control plane), giao diện southbound, và tầng dữ liệu (data plane) (Hình 2.1) Bộ

điều khiển SDN là chương trình thuộc tầng điều khiển SDN, được xem là đầu não

của toàn mạng SDN, với chức năng quản lý và điều khiển các thiết bị dựa trên các

quy tắc về luồng thông tin Nó sử dụng các giao thức đặc biệt để giao tiếp và gửi

thông báo đến các thiết bị mạng - thành phần trực tiếp chuyển tiếp các gói tin

Hình 2.1 Mô hình kiến trúc một SDN [3]

Các bộ điều khiển SDN điều hướng lưu lượng truy cập theo chính sách được thiết

đặt bởi quản trị viên của mạng, do đó giảm thiểu được việc cấu hình thủ công cho

từng thiết bị mạng riêng lẻ Bằng cách loại bỏ phần mềm điều khiển khỏi phần cứng

7

img/Chap2/SDN/The-typical-logical-SDN-architecture - JP9

Trang 18

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT

mạng và đặt tại vùng xử lý riêng, SDN tạo điều kiện cho việc quản lý mạng tự động

và khiến việc tích hợp và quản lý các ứng dụng nghiệp vụ của tổ chức trở nên dễ dàng hơn Trên thực tế, bộ điều khiển SDN hoạt động như một loại hệ điều hành

cho toàn mạng.

Bộ điều khiển giao tiếp với các ứng dụng thông qua các giao điện northbound

và giao tiếp vói các thiết bi mạng riêng lẻ thông qua các giao diện đầu southbound.Hiện tại, một số giao thức được chấp nhận cho các giao diện southbound bao gồm:

OpenFlow, gRPC Network Management Interface (gNMI)/gRPC Network

Opera-tion Interface (gNOD, P4, v.v

2.1.3 Phân tán tang điều khiển

Theo định nghĩa, mạng SDN có một tầng điều khiển duy nhất Tuy nhiên, ta cóthể hiểu sự duy nhất ở đây theo nghĩa logic Như vậy, một tầng điều khiển có thể

gồm nhiều nút được triển khai phân tán, song vẫn đồng nhất về mặt dữ liệu và do đó

có thé xem như một khối thong nhất [4] Trên thực tế, việc triển khai một trung tâm duy nhất cho hệ thống nói chung hạn chế khả năng mở rộng, tính sẵn sàng và khả

năng chịu lỗi Do vậy, việc triển khai phân tán là cần thiết Các mô hình lớp điềukhiển SDN phân tán có thể chia ra thành mô hình phẳng và mô hình phân cấp

Trong mô hình phẳng, các bộ điều khiển ngang hàng nhau và kiểm soát các vùng

mạng khác nhau Việc đồng bộ thông tin mạng được thực hiện qua sự đồng thuận

giữa các bộ điều khiển Mô hình phẳng cho phép chịu lỗi tốt hơn vì không có điểm

lỗi duy nhất, song lại có cách triển khai phức tap hơn va chi phí vận hành lớn hơn

khi mô hình mở rộng với nhiều thành viên

Trong mô hình phân cấp, một bộ điều khiển được xem là trung tâm, đóng vai tròlưu trữ thông tin toàn cục, cập nhật dữ liệu và phân phối đến các bộ điều khiến thứcáp với vai trò trực tiếp điều khiển các vùng Mô hình này, tuy đảm bảo tính nhất

quán cao và dễ triển khai hơn, lại dễ gặp lỗi và mắt tính đồng bộ khi nút chủ gặp sự

cô.

Trang 19

CHƯƠNG 2 CƠ SỞ LÝ THUYET

img/Chap2/SDN/flat.jpg

Hình 2.2 Mô hình tầng điều khiển SDN phẳng [5]

2.2 Nhân bản dữ liệu và đồng bộ dữ liệu

Để đảm bảo tính phân tán cao của toàn hệ thống, lưu trữ phân tán cũng là mộtthành phần quan trọng Nhân bản và đồng bộ dữ liệu là một phần không thể thiếuđối với hệ lưu trữ này

2.2.1 Nhân bản dw liệu

Nhân bản dữ liệu tạo ra các ban sao giống nhau của các bản cập nhật dữ liệu và

lưu trữ chúng tại các vị trí khác nhau Nhân bản giúp tăng độ sẵn sàng và khả năng

dự phòng cho di liệu, cho phép truy cập nhanh hơn tại các vị trí khác nhau và bảo vệ

dữ liệu khỏi mất mát hoặc hư hỏng Tuy nhiên, thao tác này chưa thể đảm bảo tính nhất quán ngay lập tức khi các bản cập nhật có thể cần các khoảng thời gian khác nhau để đến các bản sao dữ liệu.

2.2.2 Đồng bộ dữ liệu

Đồng bộ dif liệu đảm bao sự nhất quán giữa các bản sao dữ liệu Trong quá trình

này, những thay đổi được áp dụng cho nơi lưu trữ chính được lan truyền hiệu quả

đến các nơi lưu trữ còn lại Đồng bộ hóa giảm thiểu sự khác biệt và cho phép cậpnhật theo hoặc gần thời gian thực trên nhiều nơi lưu trữ

Trang 20

CHƯƠNG 2 CƠ SỞ LÝ THUYET

img/Chap2/SDN/Hierarchical.jpg

Hinh 2.3 M6 hinh tang diéu khién SDN phang [5]

2.2.3 Một số mô hình nhân ban và đồng bộ

Các mô hình sau đây có các ưu và nhược điểm, cũng như có thể được sử dụng

kết hợp với nhau để tạo ra mô hình nhân bản và đồng bộ tối ưu:

2.2.3.1 Gửi trực tiếp nhiều ban sao đến các cơ sở dữ liệu

img/Chap2/data_sync/Replica.jpg

Hình 2.4 Bên gửi gửi nhiều ban sao đến các cơ sở dữ liệu (CSDL)

10

Trang 21

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT

Trong mô hình này, bên gửi tạo các bản sao cho bản cập nhật dif liệu rồi gửi đến

các nơi lưu trữ tương ứng Hình 2.4 thể hiện một mô hình đơn giản với bên gửi và

hai cơ sở dữ liệu (CSDL) A và B đóng vai trò như các nơi lưu trữ, song mô hình này

cũng có thể áp dụng với nhiều bên gửi và CSDL.

° Uu điểm:

- Phòng tránh mất mát trong quá trình truyền dữ liệu nhờ tạo nhiều bản sao

từ nguồn.

¢ Nhược điểm:

- Không đảm bảo hoàn toàn tính nhất quán giữa nhiều cơ sở dữ liệu

- Cần can thiệp và chỉnh sửa trực tiếp mã nguồn phần mềm, không thích hợpvới các phần mềm mã nguồn đóng, hoặc mã nguồn quá phức tạp để (bên thứ

ba) chỉnh sửa

- Yêu cầu nhiều tài nguyên từ bên gửi khi số CSDL đích tăng cao

2.2.3.2 Sao chép lưu lượng bằng thành phần mạng trung gian

Trong mô hình này, bên gửi chỉ cần gửi một bản dữ liệu duy nhất đến một thành

phần trung gian mạng (có thể là gateway, bộ cân bằng tải hoặc một máy chủ) Thành

phần này đóng vai trò sao chép lưu lượng tuân theo chính sách đã xác định thành các

bản sao, sau đó định tuyến chúng đến các CSDL

° Uu điểm:

- Ít yêu cầu lập trình phần mềm, thích hợp khi không thể chỉnh sửa mã nguồn

- Bên gửi ít sử dụng tài nguyên hơn so với phương pháp trực tiếp tạo nhiều

Trang 22

CHƯƠNG 2 CƠ SỞ LÝ THUYET

img/Chap2/data_sync/Proxy jpg

Hình 2.5 Sao chép lưu lượng qua bằng thành phần mang trung gian

- Cần các chính sách mạng thích hợp để đảm bảo việc nhân bản và định tuyến

- Không đảm bảo hoàn toàn tính nhất quán giữa nhiều cơ sở dữ liệu

° Uu điểm:

- Đảm bảo tính sẵn sàng, khả năng chịu lỗi và phục hồi cao

- Trao đổi dữ liệu trực tiếp giữa các nút lưu trữ, giảm một số độ trễ không cần thiết

- Tránh tình trạng "điểm lỗi đơn"

» Nhược điểm:

12

Trang 23

CHƯƠNG 2 CƠ SỞ LÝ THUYET

img/Chap2/data_sync/PeerSync jpg

Hình 2.6 Hai CSDL đồng bộ ngang hàng với nhau

- Thuật toán đồng thuận có thể phức tạp và khó triển khai

- Cần can thiệp trực tiếp vào mã nguồn phần mềm, không thích hợp với phầnmềm mã nguồn đóng hoặc một số lý do khác không thể sửa mã nguồn

- Độ trễ và chi phí tính toán tăng khi số nút lưu trữ tăng

2.2.3.4 Các CSDL đồng bộ theo cấp

Mô hình này bao gồm một CSDL trung tâm (gọi là csdl chủ, cho phép đọc vàghi) và các CSDL thành viên Khi bên gửi gửi cập nhật dữ liệu đến một thành viênbất kỳ trong hệ thống các CSDL, bản cập nhật sẽ được định tuyến về phía CSDLtrước khi được quảng bá xuống các CSDL thành viên còn lại

° Uu điểm:

- Quy trình và thuật toán đơn giản hơn mô hình ngang hàng

- Đảm bảo tính tập trung và nhất quán cao

¢ Nhược điểm:

- Có thể xảy ra tình trạng "điểm lỗi đơn"

13

Trang 24

CHƯƠNG 2 CƠ SỞ LÝ THUYET

img/Chap2/data_sync/Hiera.jpg

Hình 2.7 Hai CSDL thành viên cùng kết nối với CSDL trung tâm

- Cần can thiệp trực tiếp vào mã nguồn phần mềm, không thích hợp với phần mềm mã nguồn đóng hoặc một số lý do khác không thể sửa mã nguồn

Khóa luận kết hợp sử dụng mô hình đồng bộ ngang hàng và nhân bản lưu lượng

vì sự đơn giản, dễ triển khai cũng như có nhiều công cụ.

2.3 Thuật toán đồng thuận

Các thuật toán đồng thuận là những cơ chế được sử dụng trong các hệ thống máytính phân tán nhằm đạt được thỏa thuận về giá trị hoặc trạng thái duy nhất giữa các

máy, kể cả khi hệ thống xảy ra sự cố Các thuật toán đồng thuận được dùng trong

các hệ cơ sở dữ liệu phân tán nhằm đảm bảo tính nhất quán của dữ liệu trong hệ.Theo [6], một thuật toán đồng thuận phải thỏa mãn 4 tính chất:

¢ Tinh chấm dứt (Termination): các tiến trình hợp lệ (hoạt động đúng) sẽ dần

đưa ra giá trị quyết định.

* Tính toàn ven (Integrity): các tiến trình hợp lệ quyết định một và chỉ một giá

trị Néu một tiến trình quyết định một giá trị v, giá trị v phải được dé xuất bởi một tiến trình đúng khác.

14

Trang 25

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT

« Thỏa thuận (Agreement): nếu một tiến trình hợp lệ chọn giá trị v, thì mọi

tiễn trình hợp lệ khác cũng phải chọn giá trị v

* Tính hiệu lực (Validity): nếu tat cả các tiến trình dé xuất giá trị v, mọi tiến

trình chạy đúng phải chấp nhận giá trị v

Đồng thời, một định lý quan trọng đối với các thuật toán đồng thuật, Impossbility, phát biểu như sau: Trong hệ thống mạng bát đồng bộ, khi các tin nhắn có thể trì hoãn vô thời hạn nhưng không bao giờ thất lạc, không tôn tại thuật toán dong thuận nào dam bảo kết thúc trong mọi khả năng thực thi với mọi cầu hình

FLP-ban đầu, nêu tôn tại ít nhất một máy tính bị lỗi và không thể hoạt động [7]

Dựa trên các các giả định của định lý trên, các thuật toán đồng thuận trên thực tế

không tuân theo định lý một cách chặt chẽ và chấp nhận một số thay đổi, chẳng hạn:

* Thay đổi mô hình ban đầu: Thay vì dựa trên giả định mạng bat đồng bộ, ta giả

định rằng mạng đồng bộ

* Ndi lỏng yêu cầu đầu ra thuật toán: thay vì toàn bộ các máy trong mạng cần

đồng thuận trên cùng một giá trị, ta có thể chỉ cần sự đồng thuật vượt qua hơn

số lượng máy xác định Hoặc chấp nhận một khả năng rất nhỏ thuật toán không

thể hoàn thành.

« Giảm nhẹ một số yêu cau và đồng thời tăng mạnh một số yêu cầu khác (ví dụ:

giảm yêu cầu mạng - tăng yêu cầu chịu lỗi, v.v.)

Hiện tại hai thuật toán phổ biến nhất là Raft [8] và Paxos [9] Khóa luận chọn thuậttoán Raft vì tính dễ hiểu, cũng như vẫn được áp dụng rộng rãi và cải tiền liên tục

2.3.1 Paxos

Được đề xuất bởi Leslie Lamport, Paxos [9] là một trong những thuật toán đồngthuận đầu tiên được sử dụng cho hệ phân tán Một hệ tính toán dựa trên Paxos chia

các nút làm ba vai tro sau:

* Nút đề xuất (Proposer): Nút này bắt đầu quá trình đồng thuận bằng cách dé

xuất một giá trị Giá trị này có thể là mục nhập dữ liệu mới hoặc thay đổi cấu

hình.

15

Trang 26

CHƯƠNG 2 CƠ SỞ LÝ THUYET

img/Chap2/paxos-diagram.png

Hình 2.8 Các vai trò trong Paxos: các Proposer dé xuất giá trị tới các Acceptor; các

Learner học các giá tri được chấp nhận bởi Acceptor!.

* Nút chấp nhận (Acceptor): Các nút có vai trò này tham gia vào quá trình đồng

thuận bằng cách phản hồi các đề xuất từ (các) nút đề xuất Nút chấp nhận đóng

một vai trò quan trọng trong việc xác nhận các dé xuất và đảm bảo các cập nhật được chấp thuận.

* Nút hoc (Learner): Nút có vai trò này quan sát quá trình đồng thuận để dan

tìm ra giá trị quyết định Đây không phải vai trò luôn được xác định rõ trong tất cả các biến thể của Paxos Nút học có thể là bất kỳ nút nào trong hệ thống

cần được cập nhật với giá trị đã thỏa thuận

Quá trình hoạt động của Paxos được chia làm ba pha:

* Pha chuẩn bị: Nut đề xuất thiết lập thời điểm bắt đầu vòng đời (văn bản gốc sử

dung generation (thé hệ)) và đề xuất một giá trị, đồng thời gửi yêu cầu đến các

nút khác trong cụm để đảm bảo chúng cam kết nhận giá trị đã đề xuất.

* Pha đồng ý: Nút dé xuất gửi giá trị đã đề xuất ở pha chuẩn bị và chờ sự đồng ý

của các nút còn lại trong cụm Nếu đa số các nút đồng ý giá trị đã đề xuất, giá

trị này sẽ được áp dụng cho toàn bộ cụm.

¢ Pha xác nhận: Nút đề xuất xác nhận giá trị đã đồng ý ở pha trước lên toàn cụm

‘https://www.scylladb.com/glossary/paxos-consensus-algorithm/

16

Trang 27

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT

Nguyên lý cơ bản nhất của Paxos có thể được giải thích một cách tóm gọn như

trên Tuy nhiên, một hệ thống sử dụng Paxos thực tế phức tạp và cần nhiều cơ chế khác đi kèm (trao đổi tin, chịu lỗi, v.v ) Đồng thời, Paxos có nhiều biến thể khác nhau, khiến việc áp dụng và triển khai trở nên khó khăn.

nút còn lại trong cụm Raft và thông báo với chúng khi nào an toàn để áp dụng các

dữ liệu đầu vào này và cập nhật lại cơ sở Việc có nút leader giúp đơn giản hóa việcquản lý bản sao log Thuật toán Raft sử dụng mức quá bán (hơn một nửa số máyđồng thuận) làm điều kiện đồng thuận cho hệ thống

Trong trường hợp bình thường, khi người dùng gửi request ghi tới nút leader, quy

trình thực thi sẽ là:

° API gọi xuống Raft module

* Raft module sẽ thêm yêu cầu vào log module, sau đó gửi nó ra toàn bộ mạng

« Leader chờ quá bán câu trả lời “đồng ý” từ các máy tinh trong mạng (gồm

chính leader) sau đó trả về FSM ESM sẽ cập nhật bản ghi và trả kết quả cho

người sử dụng.

Việc bầu chọn leader có thể tóm gọn như sau:

* Khi hệ thống khởi động, các nút sẽ bắt đầu ở trạng thái follower Sau một thời

gian timeout khi không nhận được tín hiệu từ leader, nút sẽ tự chuyển từ trạng

thai follower qua candidate (ứng cử trở thành leader).

¢ Candidate sé tang term hiện tại lên 1, sau đó gửi request RequestVote cho toàn

bộ các nút khác trong hệ thống nhằm kiểm tra các điều kiện để xem candidate

có thể trở thành leader được hay khôn

17

Trang 28

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT

» Nếu term trả về lớn hơn term hiện tại, nút sẽ chuyển về trạng thái follower, đợi

leader đồng ý để tăng lên 1

img/Chap2/data_sync/raft/voting-diagram.png

Hình 2.9 Quá trình chon leader của Raft 7

Từ đây sẽ có 2 khả năng cho các kết quả trả về:

* Nếu timeout nhưng không nhận đủ quá bán số bầu chọn: term hiện tại đã

không nhận được đủ số đồng thuận, candidate liền tiếp tục tăng term lên 1 và

bắt đầu lại quá trình bầu chọn leader

« Nếu dat được quá bán số bầu chọn: chuyển từ trạng thái Candidate sang Leader,

gửi yeu cau “PING” ra toàn mạng, bắt đầu quá trình nhân bản các ghi chép và

cho phép nhận yêu cầu từ phía khách

Bảng 2.1 chỉ ra một số sự khác biệt về tính chất giữa hai thuật toán

Trong bài viết [10], các kết quả đo các thông số trên từng nút của các cụm Paxos

và Raft cho thấy:

* Bằng cách tăng khối lượng yêu cầu, độ trễ yêu cầu ghi trong Paxos đạt khoảng

4000 ms/yêu cầu, trong khi độ trễ tối đa trong Raft là khoảng 20 ms/yêu cầu

« Giá trị tối đa cho độ trễ yêu cầu đọc trong Paxos là khoảng 4,5 ms/op, lớn hơn

nhiều so với Raft (khoảng 2,2 ms/op)

*https:raft.github.ioslidesuiuc2016.pdf

18

Trang 29

CHƯƠNG 2 CƠ SỞ LÝ THUYET

Đảm bảo leader duy

Dam bao leader mới

giữ mọi mục log

Follower chỉ vote khi candidate có độ mới của

Log từ các chu kỳ trước

được tổng hợp chung với

triển khai triển khai hơn

từ chu kỳ trước thay đổi số chu kỳ, chỉ log của leader trong chu

xác nhận khi đã nhận kỳ hiện tại.

phản hồi với số chu kỳ

Ưu tiên cập nhật dữ liệu

kể cả khi xảy ra lỗi và dữ

* Mức tải tối đa của Paxos và Raft lần lượt là khoảng 2 và 0,4, điều này cho thay

hiệu quả cua Raft khi so sánh với Paxos.

« Raft giữ chu kỳ gửi và nhận dữ liệu đều hơn so với Paxos khi khối lượng yêu

cầu tăng cao

* Yêu cầu ghi trung bình trong Paxos có xu hướng tăng dan theo khối lượng yêu

cầu Nhưng Raft vẫn giữ sự ổn định Số lượng yêu cầu ghi tối đa trong Paxos

lên tới 14 yêu cầu/giây, trong khi thông số này chỉ đạt 11 yêu cầu/giây trong

Raft.

Vì sự phức tạp và ít hiệu quả của Paxos trong khổi lượng công việc lớn Raft và

19

Ngày đăng: 06/12/2024, 15:34

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN