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 2LỜ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 3TOM 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 4MỤ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 5MỤ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 6MỤ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 7MỤ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 84.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 9DANH 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 10DANH MỤC TU VIET TAT
giao dién mang container (container network interface) giao dién runtime cho container (container runtime inter- face)
Trang 11Chươ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 12CHƯƠ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 13CHUONG 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 15CHƯƠ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 16Chươ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 17CHƯƠ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 18CHƯƠ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 19CHƯƠ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 20CHƯƠ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 21CHƯƠ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 22CHƯƠ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 23CHƯƠ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 24CHƯƠ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 25CHƯƠ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 26CHƯƠ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 27CHƯƠ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 28CHƯƠ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 29CHƯƠ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