Thiết kế bộ phân tải cho các cụm máy chủ trang web lớn đảm bảo khả năng nhanh chóng mở rộng hệ thống

Khả năng mở rộng – Scalability Trong số tất cả những lý do cho việc sử dụng các giải pháp cân bằng tải, việc tập trung vào khả năng mở rộng tương ứng với nhu cầu người dùng trên các dịch

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

-

Họ và tên tác giả luận văn KIỀU THÀNH CHUNG

TÊN ĐỀ TÀI LUẬN VĂN

Thiết kế bộ phân tải Cho các cụm máy chủ trang Web lớn Đảm bảo khả năng nhanh chóng mở rộng hệ thống

Chuyên ngành : CÔNG NGHỆ THÔNG TIN

MỤC LỤC

MỤC LỤC 3

DANH MỤC HÌNH VẼ MINH HỌA 5

DANH MỤC CÁC BẢNG MINH HỌA 5

LỜI CAM ĐOAN 6

PHẦN MỞ ĐẦU 7

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

2 Lịch sử nghiên cứu: 9

3 Mục tiêu chính: 10

4 Sơ lược luận văn 11

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

PHẦN NỘI DUNG 12

CHƯƠNG I: CÂN BẰNG TẢI LƯU LƯỢNG WEB 12

1.1 Giới thiệu 12

1.2 Phân loại cân bằng tải 13

1.3 Khả năng mở rộng – Scalability 15

1.4 Cân bằng tải không nhận biết nội dung 16

1.4.1 Chuyển tiếp lớp 2 17

1.4.2 Chuyển tiếp lớp 3 18

1.4.3 Các chính sách phân phối yêu cầu không nhận biết nội dung 21

1.5 Cân bằng tải nhận biết nội dung 22

1.5.1 Kiến trúc hai chiều 24

1.5.1.1 Ràng buộc kết nối TCP - TCP Connection Binding 24

1.5.1.2 Ghép nối TCP - TCP Splicing 26

1.5.1.3 Các luồng chuyển hướng - Redirect Flows 26

1.5.2 Kiến trúc một chiều 27

1.5.2.1 Chuyển giao TCP - TCP Hand-Off 27

1.5.2.2 Di trú trạng thái TCP của gói tin tới bộ lọc gói tin 29

1.5.2.3 Nhân bản Socket – Socket Clonning 30

1.5.2.4 Ràng buộc kết nối một chiều - One-way Connection Binding 32

1.5.2.5 Tái thiết TCP – TCP Rebuilding 32

1.5.3 Các chính sách phân phối yêu cầu nhận biết nội dung 33

1.5.3.1 Các giải pháp nhận biết địa phương 33

1.5.3.2 Các giải pháp không nhận biết địa phương 37

1.6 Tổng kết chương I 40

CHƯƠNG II: ĐIỀU KHIỂN TRUY NHẬP VÀ BURSTINESS TRONG HỆ THỐNG WEB44 2.1 Giới thiệu 44

2.2 Các ảnh hưởng của lưu lượng đối với Web Server 45

2.3 Tính truyền loạt (Burstiness) trên Internet 46

2.3.1 Phát hiện tính truyền loạt dựa trên lưu lượng mạng 46

2.3.2 Phát hiện tính truyền loạt dựa trên giao thức TCP 47

2.3.3 Phát hiện tính truyền loạt trong cơ sở dữ liệu 48

2.3.4 Phát hiện tính truyền loạt theo số lần phục vụ 48

2.4 Các chính sách điều khiển truy nhập 48

2.4.1 Các chính sách lập lịch nhận biết chất lượng dịch vụ (QoS) 48

2.4.2 Các chính sách điều khiển truy nhập cổ điển 49

2.4.3 Các chính sách truy nhập thương mại điện tử 49

2.4.4 Các chính sách truy nhập dựa trên cụm Web 51

2.4.5 Các chính cách khác .52

2.5 Tổng kết 54

CHƯƠNG III: PHÁT HIỆN VÀ GIÁM SÁT BURSTINESS 58

3.1 Giới thiệu 58

3.2 Giám sát Khe thời gian 60

3.3 Các yếu tố Burstiness 61

3.3.1 BF1 62

3.3.2 BF2 63

3.3.3 BF3 64

3.3.4 BF4 66

3.3.5 BF5 66

3.3.6 BF6 67

3.4 Lập khe thời gian thích nghi 68

CHƯƠNG IV: THUẬT TOÁN CÂN BẰNG TẢI VÀ ĐIỀU KHIỂN TRUY NHẬP 71

4.1 Giới thiệu 72

4.2 Tối thiểu hóa chi phí 73

4.3 Tổng quan về thuật toán 75

4.3.1 Kiến trúc hệ thống 75

4.3.2 Nhận biết chất lượng dịch vụ (QoS) 76

4.3.3 Các tham số sử dụng trong thuật toán 76

4.4 Dự báo thông lượng 78

4.4.1 P1: Dựa trên quá trình lọc 78

4.4.2 P2: Dựa trên tính burstiness 79

4.4.3 P3: Dựa trên bộ lọc và tính truyền loạt 80

4.4.4 P4: Dựa trên bình phương trung bình nhỏ nhất 80

4.4.5 P5: NLMS – Dựa trên bình phương trung bình nhỏ nhất thông thường 81

4.4.6 Các kết quả dự đoán thông lượng 81

4.5 Phân bổ tài nguyên 82

4.6 Kỹ thuật cân bằng tải 85

PHẦN KẾT LUẬN & HƯỚNG PHÁT TRIỂN 86

1 Kết luận 86

2 Hướng phát triển 88

TÀI LIỆU THAM KHẢO 90

Tài liệu tiếng Anh 90

Tài liệu tiếng Việt 91

DANH MỤC CÁC TỪ VIẾT TẮT 92

DANH MỤC HÌNH VẼ MINH HỌA

Hình 1.1: Tổ chức các giải pháp cân bằng tải web 14

Hình 1.2: Ví dụ về thực thi chuyển tiếp layer-2 17

Hình 1.3: Thực thi chuyển tiếp layer-3 trong kiến trúc hai chiều (two-ways) 19

Hình 1.4 Thiết lập kết nối TCP khi sử dụng NAT và IPTun 20

Hình 1.5: Cân bằng tải theo kiến trúc 2 chiều layer-7 22

Hình 1.6: Các kỹ thuật cân bằng tải Layer-7 trong kiến trúc hai chiều: 25

Hình 1.7: Chuyển giao TCP và Di trú trạng thái TCP của gói tin 28

Hình 1.8: Socket Cloning và TCP Rebuilding trong kiến trúc một chiều 31

Hình 3.1: Dự kiến tỷ lệ giám sát sau các lần quan sát khác nhau 61

Hình 3.2 Tỉ lệ đến và các yếu tố Burstiness 65

Hình 3.3: Giám sát theo lập khe thời gian thích nghi và một số khe sử dụng BF1 70

Hình 4.1: Các dự đoán thông lượng 82

DANH MỤC CÁC BẢNG MINH HỌA Bảng 2.1 Các giải pháp cân bằng tải không nhận biết nội dung 16

Bảng 2.2: Các giải pháp cân bằng tải nhận biết nội dung 23

Bảng 2.3: Các đặc điểm chính sách phân phối yêu cầu nhận biết nội dung 43

Bảng 3.1: Các đặc điểm chính của các chính sách điều khiển truy nhập 57

LỜI CAM ĐOAN

Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi, không sao chép của

ai Nội dung của luận văn có tham khảo các thông tin được đăng tải trên các bài báo, trang web theo danh mục tài liệu tham khảo của luận văn

Tôi xin chân thành cảm ơn Tiến sĩ Nguyễn Khanh Văn đã hướng dẫn tôi thực hiện

đề tài này Mọi góp ý, bổ sung về nội dung cũng như hình thức của đề tài này xin gửi

về địa chỉ email: kieuthanhchung@gmail.com

Tôi xin chân thành cảm ơn tới các giảng viên trong Viện Công nghệ thông tin đã nhiệt tình hướng dẫn giúp đỡ tôi trong thời gian học tập, nghiên cứu tại Trường Đại học Bách khoa Hà nội!

Tôi cũng xin chân thành cảm ơn Trung tâm Công nghệ - Công ty Cổ phần Đầu tư phát triển công nghệ VTC đã giúp đỡ tôi trong quá trình tìm hiểu, nghiên cứu công trình này

Tôi xin chân thành cảm ơn!

Tác giả luận văn

Kiều Thành Chung

PHẦN MỞ ĐẦU

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

Một trong những đặc thù nổi bật của cuộc cách mạng thông tin đang diễn ra hiện này là sự phát triển vũ bão của Internet với các ứng dụng phong phú dựa trên nền Web Hiện tại thế giới đã chứng kiến những dịch vụ thông tin nền Web với số lượng người

sử dụng khổng lồ tính bằng hàng triệu, ví dụ như Google, Facebook, Youtube, … Đương nhiên, việc làm sao đáp ứng được số lượng người dùng đồng thời lớn như thế là

cơ sở của nhiều vấn đề kỹ thuật nóng bỏng nhất hiện nay Cung cấp dịch vụ cho 1 tập thể đã nghiên cứu rõ ràng (một doanh nghiệp chẳng hạn) có thể là một việc quen thuộc trong quá khứ, nhưng cung cấp dịch vụ cho toàn bộ công chúng, trong đó số người sử dụng đồng thời có thể lớn không lường trước được, là một thách thức mới: làm sao để đảm bảo không xảy ra tắc nghẽn và tối ưu hiệu quả hệ thống

Để đáp ứng được số lượng người dùng đồng thời cao, đương nhiên tài nguyên tính toán (số lượng máy chủ) phải lớn, nhưng không phải cứ đầu tư nhiều vào thiết bị là giải quyết được vấn đề Ở đây ta cần nhấn mạnh đến tính hiệu quả trong việc tổ chức

sử dụng các thiết bị: nếu không có các giải pháp hợp lý, xử lý thông minh, các thiết bị tốn kém vẫn không hoạt động đúng công suất, gây lãng phí lớn và tắc nghẽn vẫn xảy

ra Yếu tố hệ thống thường được biết đến với tên gọi “khả năng mở rộng hệ thống”, hay nói tắt “khả mở” (scalability) Với việc thiết kế hệ thống kém, những điểm ách tắc (bottleneck) cố hữu làm hệ thống khó mở rộng khả năng đáp ứng nhu cầu người dùng,

dù được tăng cường số lượng máy chủ lớn Đây là hiện tượng xảy ra khá phổ biến ở Việt nam, khi các mạng xã hội nhỏ lẻ, các dịch vụ game-online mở ra khá tự phát, không được đầu tư kỹ về thiết kế Ban đầu các doanh nghiệp này nhanh chóng phát triển với một lượng người sử dụng (NSD) không lớn nào đó, nhưng cũng sẽ nhanh chóng đạt đến điểm tới hạn (khoảng cỡ trăm nghìn NSD) không thể vượt quá nếu không có cải tổ kỹ thuật triệt để

Câu chuyện về sự ra đời và phát triển của các mạng xã hội quen biết trên thế giới cho chúng ta những bài học, những dẫn chứng tốt về việc đảm bảo tính khả mở, tức là nhanh chóng mở rộng dich vụ Mạng xã hội xuất hiện lần đầu tiên năm 1995 với sự ra đời của trang Classmate với mục đích kết nối bạn học, tiếp theo là sự xuất hiện của SixDegrees vào năm 1997 với mục đích giao lưu kết bạn dựa theo sở thích Các mạng này tuy nhiên chưa có tính thu hút mạnh do giới hạn bởi công nghệ Internet lúc đó Năm 2002, Friendster trở thành một trào lưu mới tại Hoa Kỳ với hàng triệu thành viên ghi danh Tuy nhiên sự phát triển quá nhanh này cũng là con dao hai lưỡi: server của Friendster thường bị quá tải mỗi ngày, gây bất bình cho rất nhiều thành viên Năm

2004, MySpace ra đời với các tính năng như phim ảnh (embedded video) và nhanh chóng thu hút hàng chục ngàn thành viên mới mỗi ngày, các thành viên cũ của Friendster cũng lũ lượt chuyển qua MySpace và trong vòng một năm, MySpace trở thành mạng xã hội đầu tiên có nhiều lượt xem hơn cả Google và được tập đoàn News Corporation mua lại với giá 580 triệu USD Năm 2006, sự ra đời của Facebook đánh dấu bước ngoặt mới cho hệ thống mạng xã hội trực tuyến với nền tảng lập trình

"Facebook Platform" cho phép thành viên tạo ra những công cụ (apps) mới cho cá nhân mình cũng như các thành viên khác dùng Facebook Platform nhanh chóng gặt hái được thành công vược bậc, mang lại hàng trăm tính năng mới cho Facebook và đóng góp không nhỏ cho con số trung bình 19 phút mà các thành viên bỏ ra trên trang này mỗi ngày

Để đáp ứng đảm bảo khả năng mở rộng (scalability), một bộ phận hệ thống chủ chốt không thể thiếu được trong các dịch vụ web lớn là hệ thống tự động phân tải (Load-balancer) Đây là thiết bị và phần mềm làm nhiệm vụ đón yêu cầu của tất cả NSD rồi “phân việc” cho một trong số các máy chủ (server) xủ lý thông tin cụ thể Để đảm bảo tối ưu hiệu quả sử dụng của toàn bộ hệ thống các máy chủ, bộ phận phân tải phải làm việc “công minh” và khéo léo, tìm giao việc cho “người” vừa đang nhẹ tải

tình hình của các máy chủ, vừa nhanh chóng nắm được bản chất của dòng các yêu cầu

xử lý đang được gửi đến liên tục

Luận văn cao học này đặt mục tiêu nghiên cứu tìm hiểu sâu các kỹ thuật cơ bản trong thiết kế các hệ phân tải đảm bảo khả năng mở rộng hệ thống (scalability) của các dịch vụ mạng với số lượng NSD lớn Cụ thể hơn, luận văn sẽ tìm hiểu và tổng hợp

có hệ thống các phương pháp phân tải phong phú đã được biết tới lâu này, trong thực tế cũng như trong những nghiên cứu lý thuyết mới nhất Luận văn cũng đưa ra các phân tích so sánh dựa vào đặc điểm riêng của hoàn cảnh sử dụng của các phương pháp phổ biến Đây là một lĩnh vực kỹ thuật còn được biết tới chưa nhiều ở Việt nam, nên tác giả

hy vọng sẽ tìm thấy những phân tích kỹ thuật và khuyến nghị sử dụng hợp lý, mới mẻ cho các nhà xây dựng và cung cấp dịch vụ lớn trong nước Một trong những mục tiêu

cụ thể là tìm và áp dụng những kỹ thuật tiên tiến và hợp lý nhất cho các hệ thống dịch

vụ game-online đang được cung cấp bởi tổng công ty VTC, môi trường công tác của tác giả

2 Lịch sử nghiên cứu:

Việc sử dụng Internet tại tất cả các lĩnh vực của đời sống đã và đang phát triển rất đáng kể trong thập kỷ qua Internet đã thực sự trở thành một công cụ cần thiết cho cuộc sống của nhân loại và hiển nhiên rằng nó đã không ngừng phát triển như nó vẫn có thể được cải thiện trong nhiều khía cạnh kiến trúc của nó

Khi hệ thống cơ sở hạ tầng mạng chưa đạt được những thành tựu nhất định, ví dụ như tốc độ truyền qua đường Dial up chậm, số lượng web ít, số lượng server phục vụ web ít, chủ yếu là các trang web tĩnh,…thì vấn đề tải trong hệ thống mạng chưa được quan tâm Tuy nhiên, khi cơ sở hạ tầng mạng được nâng cấp, chất lượng và số lượng web phát triển nhanh gây ra tắc nghẽn trên một số mạng nhất định

Bước đầu trong lịch sử, người ta đã nghiên cứu các giải pháp cân bằng tải đơn giản, chủ yếu phục vụ cho hệ thống web tĩnh và hệ thống máy chủ đồng bộ Tuy nhiên,

khi công nghệ ứng dụng dựa trên web thay đổi, việc tìm kiếm hay đưa ra các giải pháp cân bằng tải là cần thiết để đảm bảo đáp ứng sự đa dạng về nội dung, sự phát triển các loại yêu cầu khác nhau, với thời đáp ứng các yêu cầu khác nhau

Nhiều nhóm nghiên cứu trên toàn thế giới tiếp tục nghiên cứu Internet của họ đang cố gắng tăng tốc độ giao thức truyền thông và nâng cao hiệu quả hoạt động ở cấp

độ ứng dụng web Ngoài ra các ứng dụng mới đang được phát triển để được thực hiện qua kết nối Internet như Voice Over Internet Protocol (VOIP) điện thoại, trò chơi trực tuyến và các mạng xã hội

3 Mục tiêu chính:

Trên cơ sở nghiên cứu các giải pháp, mục tiêu của luận văn là đánh giá các giải pháp cân bằng tải đã và đang sử dụng trong hệ thống Web Nghiên cứu các yếu tố tác động vào tải của hệ thống web Qua đó, nghiên cứu cách giải quyết các bài toán tắc nghẽn Mục đích cuối cùng là dựa trên các đánh giá cụ thể các giải pháp cân bằng tải nhằm tìm kiếm giải pháp thích hợp để áp dụng vào thực tiễn hệ thống Web hiện nay tại Việt nam

Đối tượng chính của luận văn chính là các giải pháp cân bằng tải Đặc biệt là giải pháp cân bằng tải nhận biết nội dung với sự phân tích đánh giá các yếu tố burstiness thông qua việc thiết lập các khe thời gian thích ứng Ngoài ra, luận văn cũng mô tả các giải pháp khác như là các giải pháp cân bằng tải không nhận biết nội dung, các giải pháp cân bằng tải nhận biết QoS Thông qua các đối tượng đó, để đánh giá khả năng đáp ứng và khả năng mở rộng của hệ thống Web khi số lượng người truy nhập tăng đột biến hay quá lớn

Do đối tượng nghiên cứu khá nhiều, nên phạm vi nghiên cứu khá lớn Tuy nhiên, trong khuôn khổ của luận văn này, phạm vi nghiên cứu là các hệ thống Web Game lớn

4 Sơ lược luận văn

Để thực hiện mục tiêu trên, luận văn này sẽ được chia thành hai phần chính:

Phần nội dung gồm các chương

- Chương 1: Khái niệm và phân loại cân bằng tải; Khả năng mở rộng Scalability; Các kiến trúc ứng dụng cân bằng tải; Các chính sách phân phối yêu cầu;

- Chương 2: Các ảnh hưởng của lưu lượng đối với máy chủ Web; Tính truyền loạt – burstiness; Các chính sách điều khiển truy nhập;

- Chương 3: Phát hiện và giám sát burstiness; Giám sát khe thời gian; Các yếu tố burstiness; Lập khe thời gian thích nghi

- Chương 4: Thuật toán cân bằng tải và điều khiển truy nhập; Mục tiêu tối thiểu hóa chi phí thực hiện; Tổng quan về thuật toán; Dự báo thông lượng; Phân bổ tài nguyên; Kỹ thuật cân bằng tải

Phần kết luận và hướng phát triển: gồm các kết luận và hướng phát triển nghiên cứu lý thuyết cũng như định hướng ứng dụng

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

Phương pháp nghiên cứu chủ yếu của luận văn là tổng hợp các nguồn tài liệu trên Internet, tạp chí và một số tài liệu khác Qua đó, đánh giá các giải pháp cân bằng tải nhằm đưa ra giải pháp thích hợp mang tính ứng dụng đối với hệ thống web

PHẦN NỘI DUNG CHƯƠNG I: CÂN BẰNG TẢI LƯU LƯỢNG WEB

Cân bằng tải cải thiện khả năng mở rộng của một ứng dụng hoặc cụm máy chủ bằng cách phân phối tải trên nhiều máy chủ Cân bằng tải cũng có thể hướng lưu lượng truy nhập đến các máy chủ khác, nếu một máy chủ hoặc ứng dụng không hoạt động (lỗi) Khả năng duy trì dịch vụ không bị ảnh hưởng trong một số kịch bản thất bại được gọi là sẵn sàng Khả năng quản lý được cải thiện bằng cân bằng tải theo nhiều cách cho phép các quản trị mạng và quản trị máy chủ để di chuyển một ứng dụng từ một máy chủ đến một máy chủ khác một cách dễ dàng Cân bằng tải cung cấp các giải pháp cải thiện an toàn bằng cách bảo vệ các cụm máy chủ với nhiều hình thức của tấn công từ chối dịch vụ: Denial-of-Service (DoS)

Chương này được tổ chức như sau:

- 1.2 Phân loại cân bằng tải: sắp xếp các giải pháp cân bằng tải

- 1.3 Khả năng mở rộng – scalability: tính mở rộng hệ thống trong giải pháp cân bằng tải

- 1.4 Cân bằng tải không nhận biết nội dung: giải pháp thực hiện cân bằng lưu lượng nhưng không dựa trên nội dung cụ thể

- 1.5 Cân bằng tải nhận biết nội dung: giải pháp thực hiện cân bằng lưu lượng dựa trên nội dung cụ thể

1.2 Phân loại cân bằng tải

• Cân bằng tải phụ thuộc vào nguyên tắc phân loại của các kiến trúc máy chủ web,

sự phân biệt được thực hiện theo cách tiếp cận local scale-out hay global scale-out Sự

khác biệt chính bao gồm các vị trí địa lý, nơi đặt các node máy chủ cư trú Trong phương pháp tiếp cận global scale-out, các nodes được đặt tại các địa điểm khác nhau

về địa lý, trong khi các node nằm cùng một vị trí trong kiến trúc local scale-out Một ví

dụ về tổ chức global scale-out là mạng lưới phân phối nội dung (CDNs - Content Distribution Networks) Kiến trúc local scale-out còn được gọi là các hệ thống web

phân tán cục bộ

• Cân bằng tải phụ thuộc vào địa chỉ IP: Sự khác biệt có thể được thực hiện trong nhóm này phụ thuộc vào các địa chỉ IP tường minh của hệ thống web hiển thị cho

khách hàng Các node máy chủ web của hệ thống web phân tán Distributed Web

System hiển thị IP cho các khách hàng Kiến trúc là hệ thống web dựa trên Cluster Cluster-based Web System (or Web cluster) cho phép các ứng dụng của client có thể

nhìn thấy địa chỉ IP ảo của thiết bị front-end của hệ thống web

• Cân bằng tải phụ thuộc vào nơi quyết định phân phối định tuyến yêu cầu tới một

máy chủ của một hệ thống web server phân tán cục bộ: dựa trên client (client-based), dựa trên DNS (Domain Name System (DNS)-based), dựa trên bộ điều phối (dispatcher-

based) and dựa trên máy chủ (server-based)

• Cân bằng tải phụ thuộc vào mức áp dụng: mức phần cứng (về cơ bản cho các sản phẩm thương mại), mức phần mềm hệ thống, mức phần mềm trung gian (phần mềm kết nối giữa client và databases) và mức phần mềm ứng dụng

• Cân bằng tải cụm web, giải pháp cân bằng tải tùy thuộc vào lớp giao thức OSI tại cân bằng tải, còn được gọi là bộ chuyển web hoặc thiết bị front-end

• Cũng đề cập đến cân bằng tải cụm web, có một phân nhóm khác tùy thuộc vào cách trả dữ liệu về của các đối tượng máy chủ tới khách hàng Những phản hồi từ máy chủ hoặc có thể đi qua các cân bằng tải (kiến trúc hai chiều – two ways), hoặc có thể theo một đường thay thế trực tiếp cho client tránh đi qua bộ cân bằng tải (kiến trúc một chiều – one way hay cân bằng tải máy chủ một chiều) Đó là vấn đề chọn đường khác của lưu lượng luồng dữ liệu từ máy chủ tới client hơn là chuyển qua bộ cân bằng tải để tránh một node cổ chai có thể xảy ra ngay trong bộ cân bằng tải

1.3 Khả năng mở rộng – Scalability

Trong số tất cả những lý do cho việc sử dụng các giải pháp cân bằng tải, việc tập trung vào khả năng mở rộng tương ứng với nhu cầu người dùng trên các dịch vụ Web tiếp tục phát triển và hệ thống máy chủ Web ngày càng trở nên quá tải, chịu áp lực càng ngày càng cao Hơn nữa, hoạt động và hiệu năng của ứng dụng không dừng lại trên một máy chủ đơn Do đó, cân bằng tải tránh ràng buộc này bởi khả năng phát triển

số lượng các máy chủ lưu trữ ứng dụng

Mặc dù cả năng lực mạng và năng lực của máy chủ đã được cải tiến trong những năm gần đây và các kiến trúc mới đã được phát triển, tuy nhiên vẫn còn một số vấn đề cần được giải quyết theo quan điểm của người sử dụng theo khía cạnh thời gian phản hồi nhận được Khi một máy chủ bị tắc nghẽn, thời gian phản hồi thu được bởi sự gia tăng người sử dụng và điều này có thể dẫn đến một hoạt động mua bán trực tuyến bị thất bại trên trang thương mại điện tử Vì vậy thời gian đáp ứng tiếp tục thách thức hệ thống máy chủ và nghiên cứu liên quan đến cụm máy chủ

Luận văn này tập trung vào cơ sở hạ tầng hệ thống web như một thành phần được kiểm soát trực tiếp của quản trị trang web trong một hệ thống mạng phân tán như Internet Các thành phần khác cấu thành mạng như các hệ thống như là DNS, các mạng Backbone (mạng xương sống) và các router (bộ định tuyến) không được điều khiển bởi một tổ chức duy nhất và vượt ra khỏi phạm vi của nghiên cứu này

Kiến trúc hệ thống web, bao gồm một tập các máy chủ phân tán cục bộ và được kết nối thông qua một mạng tốc độ cao Kiến trúc này cung cấp một giao diện đơn để truy xuất ra bên ngoài, do đó, nó có thể được xem như một Host đơn Những người dùng không biết tên và địa chỉ của các máy chủ hợp thành cấu trúc web, họ truy nhập vào các ứng dụng được lưu trữ trong hệ thống mà chuyển các yêu cầu của họ tới địa chỉ VIP (Virtual IP) tương ứng với thiết bị đóng vai trò như một thiết bị front-end của kiến

trúc Web Loại kiến trúc này được đặt tên là hệ thống web dựa trên Cluster based Web System)

(Cluster-1.4 Cân bằng tải không nhận biết nội dung

Các giải pháp cân bằng tải được đề cập đến trong phần này được gọi là cân bằng tải không nhận biết nội dung vì bộ cân bằng tải không nhận biết thông tin của ứng dụng chứa trong các yêu cầu gửi đến Các bộ cân bằng tải thực hiện nội dung định tuyến mù thường được nhắc tới như là các bộ cân bằng tải ở layer-4 Việc lựa chọn của máy chủ đích tham dự các yêu cầu được thực hiện dựa trên những thông tin có trong các gói tin TCP SYN ở bộ cân bằng tải Lớp OSI, được sử dụng để chuyển tiếp các gói dữ liệu tới đến các máy chủ đích, có thể là lớp liên kết hay lớp mạng

Kiến trúc một chiều Direct Routing IP Tunneling

Bảng 2.1 Các giải pháp cân bằng tải không nhận biết nội dung

Tương ứng với bảng minh họa trên, phần này sẽ được phân thành các phần nhỏ dưới đây:

- Cân bằng tải chuyển tiếp lớp 2, sử dụng thiết bị front-end để chuyển tiếp các gói

1.4.1 Chuyển tiếp lớp 2

Chuyển tiếp Layer-2 (hoặc chuyển tiếp Server Load Balancing (SLB)) là một giải pháp đơn giản nhất đối với cân bằng tải và có thể được xem xét khi tất cả các giao diện của các kiến trúc hệ thống web đều trong cùng một mạng LAN ảo (VLAN) và mạng

IP, bao gồm cả bộ định tuyến client Không cần phải thay đổi topology của mạng, cũng không cần xác định lại các bản đồ địa chỉ IP Cần thiết một thiết bị cầu nối giữa bộ định tuyến client-side và bộ định tuyến phía của máy chủ (server-side)

Về cơ bản, client thiết lập một kết nối TCP với máy chủ mà sẽ tham dự các yêu cầu của nó thông qua VIP của trang web Nhiệm vụ của thiết bị front-end, hoạt động như bộ cân bằng tải, là để chọn những máy chủ và dịch địa chỉ đích Media Access Control (MAC) mà không để lại dấu vết trên thiết bị trung gian trong truyền thông

Hình 1.2: Ví dụ về thực thi chuyển tiếp layer-2

Hình 1.2: ví dụ về chuyển tiếp layer-2, mô tả vai trò của bộ cân bằng tải mà đã ghi lại các địa chỉ đích layer-2 đến địa chỉ MAC của máy chủ Web được lựa chọn và sau

đó chuyển tiếp yêu cầu đến tới máy chủ đó Đảo ngược bản dịch được thực hiện khi phản hồi được gửi lại cho web client Bộ cân bằng tải không thay đổi địa chỉ IP của yêu cầu gửi đến, vì tất cả các thiết bị trong mạng con IP (bộ cân bằng tải và các máy chủ) chia sẻ cùng một địa chỉ IP Do đó, không cần phải thay đổi các thông tin mạng của gói tin và do đó, không cần phải tính toán kiểm tra lại IP, có nghĩa là chi phí thực hiện ít Điều quan trọng là phải vô hiệu giao thức chuyển đổi địa chỉ (ARP- Address Resolution Protocol) khi sử dụng chuyển tiếp layer-2 để tránh khả năng xung đột bởi vì cùng một địa chỉ IP được ấn định cho tất cả các node của hệ thống Bộ cân bằng tải layer-2 sử dụng địa chỉ MAC sẵn có trong thông tin của Data link layer để xác định các cổng giao tiếp đầu ra cho gói tin đó

Chuyển tiếp Layer-2 đã được sử dụng rộng rãi trong các giải pháp thương mại trong phiên bản kiến trúc một chiều (one-way), và thường được đặt tên là chuyển mạch

layer-4 với chuyển tiếp gói tin layer-2 (layer-4 switching with layer-2 packet forward)

(L4/2) hoặc định truyến trực tiếp (DR-Direct Routing) Cùng địa chỉ IP được ấn định cho tất cả các thiết bị của mạng con, các gói tin truy xuất có thể được gửi trực tiếp từ máy chủ đến client mà không cần qua bộ cân bằng tải Hình 1.4 cho thấy việc thiết lập kết nối TCP với kỹ thuật DR

Một số mẫu thử nghiệm triển khai đầu tiên của cân bằng tải L4/2 là ONE-IP và LSMAC Nortel Networks ứng dụng kỹ thuật này trong các bộ chuyển ứng dụng của Nortel (Nortel Application Switches) Linux Virtual Server (LVS) là một giải pháp cân bằng tải layer-4 mà được triển khai trong một dự án mã nguồn mở Nó được cấu hình

hỗ trợ DR, và cũng như các kỹ thuật chuyển tiếp khác đề cập trong các phần kế tiếp

1.4.2 Chuyển tiếp lớp 3

Chuyển tiếp Layer-3 (còn gọi là định tuyến SLB) khác với cầu nối SLB (bridging SLB) trong đó router clientside có thể trong VLAN khác nhau và các mạng

của các kiến trúc hệ thống web có vai trò định tuyến hơn là vai trò cầu nối các khung giữa máy khách và máy chủ Hình 1.3 minh hoạ một ví dụ về chuyển tiếp layer-3 và cho thấy rằng một bộ cân bằng tải layer-3 (de-encapsulates có thể hiểu là giải phóng gói tin) giải phóng gói dữ liệu đến network layer để xác định nơi để gửi gói tin

Hình 1.3: Thực thi chuyển tiếp layer-3 trong kiến trúc hai chiều (two-ways)

Hai kỹ thuật chuyển tiếp đã được thực hiện trong cụm web dựa trên bộ gửi

(dispatcher) với định tuyến layer-3: Dịch Địa chỉ Mạng (NAT Network Address

Translation (NAT) and IP Tunneling (IPTun)) và IP Tunneling (IPTun) NAT là kỹ

thuật đơn giản nhất và nó thực hiện viết lại các địa chỉ đích layer-3 của gói tin tới đến địa chỉ IP của máy chủ thực sự được lựa chọn bởi bộ cân bằng tải

Hình 1.3 biểu diễn thực hiện NAT Trong khi NAT được thực hiện trong kiến trúc

2 chiều, IPTun được thực hiện trong kiến trúc một chiều Điều này có nghĩa là phản hồi

từ các máy chủ web được chọn đi trực tiếp tới client IPTun chứa các đóng gói của các

gói IP trong khối tin IP với địa chỉ IP nguồn và địa chỉ IP đích xác định địa chỉ VIP của

hệ thống và địa chỉ IP của máy chủ mục tiêu tương ứng

Hình 1.4 Thiết lập kết nối TCP khi sử dụng NAT và IPTun

Giải pháp chuyển tiếp layer-3 dựa trên NAT được phân nhóm như là chuyển đổi

layer-4 với chuyển tiếp gói tin layer-3 (layer-4 switching with layer-3 packet

forwarding) (L4/3) Nhược điểm chính của cách tiếp cận này: bộ cân bằng tải có thể trở

thành node nghẽn cổ chai của hệ thống khi tải hệ thống tăng cao Do phải tính lại IP đối với mọi gói tin đi qua bộ cân bằng tải trong cả 2 chiều

Phần lớn thiết bị thương mại chuyển mạch nhận biết nội dung hiện nay đang có trên thị trường đều cung cấp chuyển tiếp NAT, ví dụ 11.500 CSS Series Chuyển mạch dịch vụ nội dung của Cisco System, Inc, chuyển mạch layer4-7 ServerIron của Foundry Networks và Nortel Layer 2/7 Gigabit Ethernet Module (GbESM) cho IBM Blade Center Các framework phần mềm của Linux, LVS, cũng được cấu hình để hỗ trợ NAT

và IPTun nhưng kỹ thuật hiệu quả nhất là DR Microsoft cũng thực hiện kỹ thuật chuyển tiếp layer-3 có tên Network Load Balancing (NLB) được tích hợp trong họ Windows Server 2003

1.4.3 Các chính sách phân phối yêu cầu không nhận biết nội dung

Cân bằng tải không nhận biết nội dung cho phép thiết bị front-end nhận biết về các kết nối TCP giữa các client và server Do đó, bộ cân bằng tải gửi đi các yêu cầu theo địa chỉ IP và cổng TCP Một số chính sách lập lịch cân bằng tải thường được sử dụng trong bộ cân bằng tải không nhận biết nội dung Một số ví dụ về các chính sách:

• Thuật toán Round Robin (RR): Các kết nối TCP được ấn định trên cơ sở RR, với kết nối đầu tiên sẽ đến máy chủ 1, kết nối thứ hai đến server 2, v.v Các kết nối đó được ấn định tuần tự đến các máy chủ, mỗi máy chủ nhận được cùng một số kết nối qua thời gian một cách độc lập về tốc độ nhanh nhất có thể để xử lý chúng Vì lý do này, RR là một trong những phương pháp tốt nhất cho các máy chủ đồng bộ, trừ khi được sử dụng với đơn vị máy chủ (per-server weghting) tải lớn, RR kém hiệu quả trong các môi trường các máy chủ là không đồng bộ

• Thuật toán RR có trọng số - Weighted Round Robin (WRR): lưu lượng sẽ được

ấn định cho các máy chủ theo khả năng cấu hình liên quan của chúng, trong trường hợp

mà các máy chủ là không đồng bộ (thường là phổ biến) Các quản trị viên xác định tỷ

lệ phần trăm của lưu lượng truy nhập để được dẫn đến từng máy chủ

• Thuật toán kết nối ít nhất - Least Connection(LC): Các kết nối được gán cho

máy chủ với số lượng ít nhất các kết nối Đây là một thuật toán lập lịch động mà nó làm việc như bộ cân bằng tải cần đếm số lượng kết nối được thành lập giữa client và với mỗi máy chủ web trong cluster

• Thuật toán kết nối ít nhất có trọng số - Weighted Least-Connection (WLC):

Tương tự như LC, trong thuật toán này ngoài việc đếm số lượng kết nối, tải được ấn định cho mỗi máy chủ liên quan Các máy chủ với trọng số cao hơn sẽ nhận được một

tỷ lệ các kết nối lớn hơn các máy chủ còn lại

• Thuật toán Tải ít nhất - Least Loaded (LL): Các bộ gửi (dispatcher) chỉ định yêu

cầu tiếp theo tới máy chủ có tải thấp nhất Trong trường hợp này là một tác nhân (hay công cụ nào đó) trên máy chủ giữ cân bằng tải được cập nhật hiệu năng và năng lực của máy chủ Các kết nối được ấn định cho các máy chủ có khả năng dư thừa nhất Nó cũng được gọi là thuật toán đường cơ sở

• Thuật toán lựa chọn máy chủ ngẫu nhiên - Random Server Selection: Các kết nối được ấn định thống nhất giữa các máy chủ nhưng không phải tuân một trình tự xác định mà được chọn ngẫu nhiên

1.5 Cân bằng tải nhận biết nội dung

Bộ cân bằng tải nhận biết nội dung làm việc tại lớp ứng dụng, nó nhận biết các nội dung ứng dụng của các yêu cầu tới Đầu tiên, kết nối TCP phải được thiết lập giữa client và thiết bị front-end của hệ thống web, sau đó nhận được yêu cầu HyperText Transfer Protocol (HTTP) và phân tích nội dung của nó (xem hình 1.5)

Điều này làm cho việc định tuyến nhận biết nội dung cụ thể hơn đối với các ứng dụng có thể cung cấp các dịch vụ khác biệt, nhưng phức tạp hơn so với phương pháp tiếp cận không nhận biết nội dung Mặc dù một số giải pháp thương mại cân bằng tải nhận biết nội dung đã được triển khai, tuy nhiên vẫn là chủ đề cần được nghiên cứu HTTP/1.1 cho phép các kết nối duy trì (keep-alive) Một số yêu cầu HTTP từ client có thể đi qua cùng kết nối TCP Làm giảm thời gian phản hồi, chi phí hoạt động máy chủ và chi phí hoạt động mạng của HTTP Để tận dụng những lợi ích này, một số thay đổi giao thức TCP được phát triển để cho phép tính phân chia yêu cầu của HTTP trong cân bằng tải nhận biết nội dung, thay vì tính phân chia kết nối Những thay đổi

đó phụ thuộc vào kiến trúc một chiều hoặc kiến trúc hai chiều của web cluster

Bảng 2.2 Tóm tắt các giải pháp có tính phân chia yêu cầu sử dụng HTTP/1.1

TCP Splicing TCP Connection Binding Kiến trúc hai chiều

Redirect Flows

TCP Hand-off Multi Connection TCP Hand-Off

TCP Connection Hop One-Packet TCP State Migration to

Packet Filter

Socket Cloning Multiple TCP Rebuilding Kiến trúc một chiều

TCP Rebuilding One-way Connectiong Binding

Bảng 2.2: Các giải pháp cân bằng tải nhận biết nội dung

Với kiến trúc một chiều và kiến trúc hai chiều mô tả tác động TCP của chúng để biết cách cân bằng tải được thực hiện Do đó, phần này được chia thành các phần sau:

- Kiến trúc hai chiều: cách trả dữ liệu phản hồi qua bộ cân bằng tải

- Kiến trúc một chiều: cách trả dữ liệu phản hồi trực tiếp tới client

- Các chính sách cân bằng tải nhận biết nội dung

1.5.1 Kiến trúc hai chiều

Phần này giới thiệu ba kỹ thuật định tuyến các yêu cầu từ bộ cân bằng tải cho máy

chủ web mục tiêu trong kiến trúc hai chiều, đó là: TCP Connection Binding, TCP

Splicing và Redirect Flows.

1.5.1.1 Ràng buộc kết nối TCP - TCP Connection Binding

Ràng buộc kết nối còn được gọi là “Cổng TCP – TCP GateWay”, hoặc Relaying

front-end hoặc Relaying with Packet Rewriting Về cơ bản, ràng buộc kết nối duy trì

hai kết nối TCP: kết nối thứ nhất giữa client và bộ cân bằng tải và kết nối thứ hai giữa

bộ cân bằng tải và máy chủ Web

Trước khi nhận được bất cứ yêu cầu nào, bộ cân bằng tải thiết lập một kết nối duy trì với mỗi máy chủ web Khi bộ cân bằng tải nhận được một yêu cầu từ một client, một trong những kết nối TCP, đã được thiết lập trước đó, được sử dụng để chuyển các yêu cầu cho máy chủ mục tiêu đã chọn

Ưu điểm chính của đề xuất này là nó cho phép phân phối dựa trên nội dung theo tính phân chia (granularity) các yêu cầu riêng lẻ vì các kết nối duy trì giữa bộ cân bằng tải và các máy chủ back-end không phụ thuộc vào lưu lượng truy nhập tới

Kỹ thuật TCP Connection Binding và TCP Splicing Binding, được thực hiện trên nền tảng Java Vấn đề chính của cách tiếp cận này là các gói tin cần phải được phân

tích thông tin trên lớp ứng dụng của chúng khi đi qua bộ cân bằng tải Chi phí hoạt động có thể giảm được bởi các kỹ thuật khác được mô tả dưới đây

Hình 1.6 cho thấy thủ tục ràng buộc kết nối TCP, chi tiết số Initial Send Sequence (ISS) của client và số Initial Receive Sequence (IRS) của bộ cân bằng tải được sử dụng trong bắt tay ba bước của kết nối client với bộ cân bằng Các số khác nhau, ISS2 và IRS2, được sử dụng trong kết nối tiền chia (pre-forked) giữa bộ cân bằng tải và máy chủ Web Tất cả những con số này không cần phải có bất kỳ mối quan hệ nào với nhau

và bộ cân bằng tải chịu trách nhiệm về việc thay đổi ISS và số trường tiêu đề IRS TCP phụ thuộc vào kết nối nào được sử dụng để truyền các gói tin

Hình 1.6: Các kỹ thuật cân bằng tải Layer-7 trong kiến trúc hai chiều:

IBM Network Dispatcher là một ví dụ về một ràng buộc kết nối TCP, nhưng đã được thương mại hóa từ một vài năm trước đây

1.5.1.2 Ghép nối TCP - TCP Splicing

Kỹ thuật ghép nối tương tự như kỹ thuật ràng buộc kết nối TCP, nhưng hiệu suất được cải thiện do kết nối TCP client và kết nối TCP máy chủ với bộ cân bằng tải được ghép nối với nhau (tại tầng TCP) và tất cả công việc có thể được thực hiện trực tiếp do

hệ thống hoạt động chuyển tiếp dữ liệu ở mức IP Hình 1.6 cũng cho thấy ví dụ về chi tiết hóa ghép nối TCP ISS và số trường tiêu đề IRS TCP của cả hai kết nối

Một số cải tiến khả năng chia tách điểm nối ghép trong các máy chủ web và gửi phản hồi trực tiếp cho client Điều này cho phép áp dụng kiến trúc một chiều khi sử dụng giao thức TCP Splicing Tái ghép nối kết nối TCP đã được thiết lập với máy chủ

để tham dự một yêu cầu đến (có thể thích hợp hơn) máy chủ mục tiêu khác, có tính chia tách yêu cầu trong cân bằng tải thay vì tính chia tách kết nối TCP khi sử dụng giao thức HTTP / 1.1

Các kỹ thuật tương tự đối với TCP Splicing được triển khai ở một số giải pháp thương mại nhận biết nội dung như CSS của Cisco 11500 Series Content Services Switch, F5's BIG-IP, Foundry’s ServerIron layer 4-7 switches, Radware Ondemand switchs và Nortel Layer 2/7 Gigabit Ethernet Module (GbESM) cho IBM Blade Center Ngoài ra, các framework của Linux đã được phát triển để hỗ trợ giao thức TCP Splicing gọi là chuyển mạch Linux Layer7 (L7SW)

1.5.1.3 Các luồng chuyển hướng - Redirect Flows

Redirect Flows là kỹ thuật hai chiều, rất giống với các phương pháp tiếp cận TCP Splicing nhưng dựa trên kiến trúc NAT

Đó là một kỹ thuật độc quyền của Arrowpoint Communications Inc, một công ty được mua lại bởi Cisco Systems Inc trong năm 2000

1.5.2 Kiến trúc một chiều

Những bất lợi chính của các đề xuất kiến trúc hai chiều là phản hồi dữ liệu phải được chuyển tiếp theo cân bằng tải, mà có thể trở thành node cổ chai của hệ thống khi khối lượng lưu lượng cao cần phải được xử lý

Phần này mô tả các phương pháp tiếp cận cho phép các máy chủ Web trả lại phản hồi trực tiếp tới các client Một số kỹ thuật đã được đề xuất để định tuyến các yêu cầu

từ máy chủ web mục tiêu tới client trong kiến trúc một chiều: TCP Hand-off,

One-packet TCP State Migration to Packet Filter, TCP Connection Hop, Socket Cloning, One-way Connection Binding và TCP Rebuilding.

1.5.2.1 Chuyển giao TCP - TCP Hand-Off

Các giải pháp phổ biến nhất cho kiến trúc cụm Web một chiều layer-7 là giao quyền TCP hay chuyển giao TCP Nó đòi hỏi một số thay đổi trong hệ điều hành của

bộ cân bằng tải và các máy chủ web, vì một khi kết nối TCP giữa client và bộ cân bằng tải được thiết lập thì điểm kết thúc kết nối cuối cùng của bộ cân bằng tải được chuyển giao cho máy chủ được chọn, như minh họa trong hình 1.7

Hình 1.7: Chuyển giao TCP và Di trú trạng thái TCP của gói tin

Số IRS của kết nối đầu tiên và địa chỉ IP của client được gửi đến máy chủ web vì kết nối chuyển giao giữa bộ cân bằng tải và máy chủ web phải có được một bản sao kết nối của client để cho phép các máy chủ web gửi những phản hồi trực tiếp cho client

Do đó, cùng các số ISS và IRS có thể được sử dụng trong cả hai kết nối

Một số thay đổi đối với kỹ thuật chuyển giao TCP cho phép tính chia tách của các yêu cầu cá nhân khi sử dụng các kết nối liên tục HTTP/1.1 Gồm chuyển giao TCP đa

kết nối (Multiple Connection TCP Hand-off) và các kỹ thuật chuyển tiếp yêu cầu end (Back-end Request Forwarding)

Back-Chuyển giao TCP đa kết nối cho phép các yêu cầu được truyền (pipelined) đến để

được tham dự của các máy chủ web khác nhau bằng cách di chuyển các kết nối giữa các máy chủ Chuyển tiếp yêu cầu Back-end (Back-end Request Forwarding) tránh chi

phí hoạt động như Multiple Connection TCP Hand-off bằng cách cho phép chuyển

hướng các yêu cầu từ một máy chủ sang máy chủ khác sau khi có quyết định của bộ cân bằng tải Chuyển giao đơn giản được sử dụng khi một yêu cầu kết nối TCP mới

đến bộ cân bằng tải Back-end Request Forwarding có hiệu năng tốt hơn để đáp ứng quy mô nhỏ, Multiple Connection TCP Hand-off là tốt hơn cho những phản hồi lớn

TCP Hand-off có khả năng mở rộng với số lượng các máy chủ web tại các cụm

Kỹ thuật chuyển giao TCP có khả năng mở rộng giới hạn kích thước tối đa lên đến bốn cụm máy chủ Web, mặc dù kỹ thuật này thực thi trên kiến trúc một chiều

Giải pháp cân bằng tải phân tán thay thế với thiết bị front-end tại layer-4, nơi tập trung một node gọi là bộ gửi (dispatcher), điều khiển các quyết định cân bằng tải và chi phí hoạt động, được thực hiện bởi một vài nodes phân phối được kết nối trong mạng, khi chúng phân phối các yêu cầu của client đến các máy chủ web được lựa chọn bởi chuyển giao các kết nối

1.5.2.2 Di trú trạng thái TCP của gói tin tới bộ lọc gói tin

Di trú trạng thái TCP của gói tin tới bộ lọc gói tin - One-packet TCP State Migration to Packet Filter

Kỹ thuật thứ hai, sự di trú trạng thái TCP của một gói tin tới bộ lọc gói tin Một quá trình lọc gói trong mỗi máy chủ web để chặn các kết nối từ bộ cân bằng tải mà không sửa đổi nhân hệ điều hành Giản đồ tiền phân bố được sử dụng để cung cấp khả năng mở rộng hơn trong trường hợp đó Nó thiết lập kết nối TCP với máy chủ web khi nhận được SYN đầu tiên (đóng vai trò là bộ cân bằng tải không nhận biết nội dung)

Một khi các yêu cầu HTTP được nhận, bộ cân bằng tải sẽ xác định xem máy chủ được lựa chọn là chính xác hay không Nếu máy chủ hoạt động tốt (sẵn sàng kết nối), thì yêu cầu được tham dự Nếu sai (có thể nội dung được yêu cầu cho khách hàng không được lưu giữ tại máy chủ chọn) thì cân bằng tải chuyển hướng yêu cầu tới một máy chủ thích hợp hơn, sau khi thiết lập kết nối bắt tay ba bước như minh họa trong

hình 1.7 Một gói RST được gửi đến máy chủ trước đó để giữ nguyên kết nối này

Các kết nối TCP duy trì cũng được hỗ trợ Khi một kết nối được sử dụng trước đó,

mà cần sử dụng lần nữa, kỹ thuật bắt tay ba bước được sử dụng để tránh phải thiết lập lại, vì kết nối đã được thiết lập trước đó và đang trong một tình trạng chờ sau RST

1.5.2.3 Nhân bản Socket – Socket Clonning

Socket Clonning là kỹ thuật chuyển hướng việc xử lý yêu cầu của client từ một máy chủ này tới máy chủ khác, bằng cách di trú một socket mở Kỹ thuật này được đặt tên theo Socket Cloning (nhân bản Socket) Bộ cân bằng tải được xem xét là bộ cân bằng tải chuyển mạch layer-4 với chuyển tiếp layer-2, chúng tạo ra các quyết định phân phối khi gói SYN của client là được nhận Nếu quyết định không chính xác và yêu cầu phải được tham dự của các máy chủ khác, thì socket được nhân bản tới máy chủ đó Do vậy, Socket Cloning hỗ trợ các kết nối HTTP/1.1 duy trì (xem hình 1.8 trang bên)

Hình 1.8: Socket Cloning và TCP Rebuilding trong kiến trúc một chiều

Một quy trình đồng bộ giữa bản socket gốc và socket nhân bản cần phải được thực hiện nhằm cập nhật các trình tự và các số ACK sau gói tin phản hồi được gửi Quá trình đồng bộ hóa này được thực hiện bởi các bộ định tuyến gói dữ liệu, do đó không liên quan đến liên việc bổ sung các giao tiếp giữa các node (inter-node communication) Việc thực hiện Socket Cloning đòi hỏi một số thay đổi đối với nhân

hệ điều hành (OS kernel)

Một kỹ thuật tương tự Socket Clonning sử dụng kỹ thuật chuyển tiếp NAT layer-3

để thực hiện cân bằng tải layer-7 cung cấp chuyển hướng phiên TCP giữa các máy chủ web cấu thành Web cluster, gọi là di trú TCP (TCP-migration) Phần vật lý được tách thành hai phần riêng biệt là chuyển tiếp gói tin và gửi yêu cầu (request dispatching)

1.5.2.4 Ràng buộc kết nối một chiều - One-way Connection Binding

Kỹ thuật ràng buộc kết nối một chiều có một số điểm tương đồng với ràng buộc kết nối TCP (TCP Connection Binding) được mô tả trong phần trước (xem hình 1.6)

Kỹ thuật này giải quyết vấn đề kết nối duy trì trong các kỹ thuật định tuyến nhận biết nội dung bằng cách thiết lập các kết nối dài (long-lived) ở phía máy chủ Khi một yêu cầu đến thiết bị front-end của hệ thống, kết nối phía client được ràng buộc với kết nối của máy chủ thích hợp và yêu cầu được gửi đến máy chủ để được tham dự

Kết nối phía máy chủ được tái sử dụng bởi các yêu cầu khác tránh việc kết thúc

và di chuyển kết nối mà có thể yêu cầu thực hiện cơ chế bắt đầu chậm (slow-start), và

do đó kéo theo việc giảm hiệu năng

1.5.2.5 Tái thiết TCP – TCP Rebuilding

Kỹ thuật TCP Rebuilding được thực hiện trong một nền tảng LVS-Content-Aware Dispatching (CAD) (điều này được mô tả trong phần 1.5.3) Hình 1.8 mô tả chi tiết thủ tục của nó: khi kết nối giữa client và bộ cân bằng tải được thiết lập và các yêu cầu HTTP đã đến bộ cân bằng tải, kết nối đó được gửi đến máy chủ web được lựa chọn, máy chủ đó bắt đầu xây dựng lại các kết nối TCP mà không cần thêm bất kỳ sự trao đổi bất kỳ gói tin nào

Theo cách đó, máy chủ web đoán trình tự và số ACK được sử dụng trong kết nối của client Các Maximum Segment Size (MSS) được thiết lập theo giá trị tiêu chuẩn

1460 Kỹ thuật multipe TCP Rebuilding được sử dụng để xử lý các kết nối duy trì HTTP/1.1 Vì LVS không thể thực hiện phân phối nhận biết nội dung, nên mô-đun bắt tay TCP nhanh (fast TCP module handshaking) trong IP-layer của thiết bị front-end được sử dụng cho việc thiết lập kết nối với client để biết loại của yêu cầu

1.5.3 Các chính sách phân phối yêu cầu nhận biết nội dung

Sau khi nghiên cứu các kiến trúc cân bằng tải nhận biết nội dung, chúng ta hãy phân tích chi tiết hơn các chính sách phân phối yêu cầu nhận biết nội dung, được đề xuất trong các tài liệu gần đây Chúng ta xem xét sự phân biệt giữa các chính sách cố gắng khai thác các bộ nhớ cache của hệ thống, được gọi là các giải pháp nhận biết vùng hoặc địa phương (locality-aware), những chính sách không bao gồm các hoạt động bộ nhớ cache trong việc đánh giá, gọi là giải pháp không nhận biết địa phương (non locality-aware) Bảng 2.3 tổng kết, theo thứ tự, các chính sách được mô tả trong phần này bao gồm một số đặc điểm quan trọng nhất của chúng

1.5.3.1 Các giải pháp nhận biết địa phương

Một số giải pháp nhận biết địa phương đã được đề xuất như các chính sách phân phối trong thiết kế cân bằng tải nhận biết nội dung Mục đích của các chính sách này là khai thác bộ nhớ cache địa phương của các máy chủ web bằng cách gửi các yêu cầu đề nghị trang web xác định máy chủ mà có thể có trong module bộ nhớ cache Điều đó có thể được quan sát trong Bảng 2.3, hầu hết các giải pháp được đưa ra giữa những năm 1998-2001 cải thiện hiệu quả của các cụm web ngày càng tăng số cache hits trong các node máy chủ Web

Các chính sách nhận biết địa phương đối phó với các hoạt động mà thông thường liên quan đến các trang Web tĩnh Vì vậy, để tăng hiệu suất bằng cách cải thiện tỷ lệ cache hit và nếu tập hoạt động là quá lớn để phù hợp trong một bộ nhớ cache của máy chủ, tập đó phải được phân chia giữa các node của cluster Đây là ý tưởng đã giới thiệu

trong chiến lược phân phối LARD Ý tưởng này xác định tập các nodes phục vụ cho tập file đích, và thay đổi các thiết lập động tùy theo số lượng kết nối hoạt động của các nodes Bộ cân bằng tải nhận biết nội dung gửi yêu cầu đến node có tải ít nhất trong tập

đó Chúng thực hiện các giao thức chuyển giao TCP để gửi các kết nối từ thiết bị end tới thiết bị back-end của node được chọn

front-Phần mở rộng của LARD (extLARD) cho phép LARD đối phó với các kết nối duy trì Ngoài ra, LARD được sử dụng để đánh giá mẫu thử nghiệm thực hiện quản lý tài nguyên cho các cụm máy chủ Web-based gọi là cụm dự trữ (cluster reserves) Điều này cho phép cô lập hiệu suất của các nguồn tài nguyên của máy chủ khác nhau để tăng hiệu quả dự trữ chúng cho các loại dịch vụ khác nhau

Một cơ chế thay thế sử dụng chuyển giao TCP, trong đó giới thiệu một chi phí quan trọng trong Web Switch, là cơ sở hạ tầng DNS FLEX được xem như là một giải

pháp nhận biết địa phương hai chiều mà không yêu cầu bất kỳ sự thay đổi trong giao thức cũng như sự thay đổi hỗ trợ phần cứng đặc biệt Nó chủ yếu dựa trên một cơ sở hạ tầng DNS mà phân bổ các trang web khác nhau đến các node của cluster Căn cứ vào các tỉ lệ truy nhập và kích thước của các tập tin, tập hoạt động (working) được phân chia tự động giữa các máy chủ như nhau

Giám sát định kỳ cho phép phát hiện những thay đổi trong mô hình truy nhập và

phân vùng lại của tập hoạt động Kỹ thuật WARD, phân phối nhận biết địa phương định

nghĩa lõi của các tập tin có chứa các tập tin thường xuyên được truy xuất Những tập tin này có thể được phục vụ bởi bất kỳ node trong cluster, trong khi phần còn lại của tập hoạt động được chia trong số tất cả các node Trong trường hợp đó, đa chuyển giao TCP được sử dụng khi yêu cầu phải được gửi từ một máy chủ này đến máy chủ khác Kích thước tối ưu của các lõi được xác định bởi thuật toán xét theo tải trọng, Random Access Memory (RAM) của cluster, xét theo chi phí của hoạt động chuyển giao TCP,

và truy nhập ổ đĩa

Các đề xuất khác gồm các tập tin được truy nhập nhiều nhất sẽ được lưu trữ trong tất cả các máy chủ. Một chính sách tìm nạp trước được gọi là: truy nhập và thời gian

dựa trên xác suất tìm nạp trước - Time and Access Probabilitybased Prefetch (TAP2)

được đề xuất Nó dự báo các yêu cầu Web tiếp theo mà các client sẽ yêu cầu bằng cách

xem xét các chi phí tìm nạp trước và xác suất của đối tượng web được yêu cầu, và nếu

có giá trị, nó tìm nạp các đối tượng được yêu cầu từ các đĩa lưu trữ địa phương

Một phiên giao dịch của client được ấn định cho một máy chủ back-end bởi chính sách RR, và kết nối TCP giữa chúng vẫn lưu vết trong tất cả các phiên Một chính sách phân phối dựa trên (nhân bản Socket) Socket Cloning mà sử dụng thiết bị front-end

L4/2, được đặt tên là Cyclone Chúng cũng chọn các tập tin thường xuyên được yêu

cầu để phục vụ, trong trường hợp này, bởi một tập các máy chủ, được lưu trữ trong một bảng băm trong mỗi máy chủ Các bản sao của các tập tin được thực hiện dần dần làm tăng tính tham khảo Do đó, nếu số tham chiếu của một tập tin đạt đến một mức độ nào

đó, tập tin kết thúc nhân rộng trong cache của tất cả các node

Một cơ chế hợp tác trong bộ nhớ đệm được dùng để sao chép các tập tin yêu cầu nhiều nhất trong tất cả các node của cluster Chúng phân phối các yêu cầu từ chuyển mạch layer-4 đến các máy chủ bằng thuật toán RR Khi yêu cầu cần phải được chuyển tới một máy chủ Web khác, nó được thực hiện bằng cách sử dụng chuyển giao TCP Dựa trên chính sách WARD, thực hiện hai chính sách phân phối (Phân phối yêu cầu nhận biết tải dựa trên nội dung với sự sao chép lõi - Content-based Workload-Aware

Request Distribution with Core Replication (CWARD/CR) và phân phối yêu cầu nhận

biết tải dựa trên nội dung với sự sao chép thường xuyên - Content-based

Workload-Aware Request Distribution with Frequency-based Replication (CWARD/FR)) trong

cụm có tên LVSCAD/FC (LVS với Content-Aware Dispatching và File Caching) Tất

cả các node tìm nạp các tập tin thường xuyên truy nhập nhất và các tập tin truy nhập ít thường xuyên sẽ được phân chia giữa các node trong chính sách CWARD/CR Trong khi ở chính sách CWARD/FR, các bản sao của các file trong các node là tỉ lệ thuận với tần suất truy nhập của chúng Trong cả hai trường hợp, các yêu cầu được ấn định cho các máy chủ dựa trên chính sách RR trong số các máy chủ đó có các tập tin yêu cầu nhân rộng Kết quả cho thấy CWARD/FR nhanh hơn so CWARD/CR

Các kết nối duy trì không được xem xét đến bởi vì chúng làm tăng chi phí khi phân phối tải dựa trên tính chất địa phương, cũng như kết nối được di trú từ máy chủ đến máy chủ khác Những chi phí đáng kể khả năng di chuyển của các kết nối TCP giữa các máy chủ Web Để khắc phục điều đó, giải pháp Press với hai phương thức hoạt động mang đến chi phí chuyển giao TCP hợp lý hơn Chuyển giao TCP được sử dụng khi có yêu cầu để được phục vụ bởi một máy chủ khác trong cluster Khả năng di chuyển cần được đẩy mạnh ở các cụm truyền thông nhanh (fast communication) với chi phí thấp về hiệu suất, nhưng hiệu quả cần phải được đẩy mạnh trong cụm truyền chậm (slow communication), chi phí cao trong trường hợp khả năng di chuyển được Một chính sách khác có tên EQUIDLOAD dựa trên kích cỡ của văn bản được yêu cầu bằng việc chia các kích thước của working set thành nhiều thành một số tập con (tương tự số lượng các máy chủ trong cluster) Cải tiến của EQUILOAD tránh biết trước sự phân bố kích thước working set Giải pháp sửa đổi, ADAPTLOAD, các tập (sets) động các giới hạn mờ dựa trên kinh nghiệm (empirically-based fuzzy boundaries) đối với độ lớn của khoảng thời gian đáp ứng

Mặc dù EQUILOAD và ADAPTLOAD không được thiết kế như kỹ thuật nhận biết địa phương, chúng cũng có những lợi ích của bộ nhớ đệm khi chúng luôn hướng các yêu cầu cho cùng một tài liệu vào cùng máy chủ EQUILOAD và ADAPTLOAD chỉ xét lưu lượng truy nhập web tĩnh Ngoài ra, ADAPTLOAD V2 được thử nghiệm với một khối lượng tải với nội dung Web động Vì ADAPTLOAD V2 không thể biết kích thước của nội dung động được yêu cầu, và phân phối các yêu cầu động dựa trên chính sách “hàng đợi tham gia ngắn nhất” (Join Shortest Queue - JSQ) Phiên bản ADAPTLOAD v2 được biểu diễn trong Bảng 2.3

Cũng xem xét lưu lượng động, Harvard Array of Clustered Computers (HACC)

là một phân phối yêu cầu được phát triển bởi tác giả Zhang, đề xuất tự động chia toàn

bộ working set giữa các số node/s trong cluster Cân bằng tải theo đề xuất này dựa trên kiến trúc hai chiều mà không xét đến các kết nối liên tục

Trong một nghiên cứu gần đây, tái xây dựng đa TCP – Multiple TCP Rebuilding

được thực hiện tại nền tảng LVS và được đặt tên như LVS-CAD LVS không thể thực

hiện phân phối nhận biết nội dung, một mô-đun TCP bắt tay nhanh (fast TCP module

handshaking) đã được giới thiệu trong layer-IP của thiết bị front-end để thiết lập kết

nối với client Tác giả Liu mô tả ba chính sách phân phối khác nhau: Tải có ít trọng số

nhận biết nội dung - Content-Aware Weighted Least Load (CAWLL), phân phối yêu cầu nhận biết vùng mở rộng với chính sách sao chép - Extended Locality-Aware

Request Distribution with Replication Policy (xLARD/R) và phân phối yêu cầu ghép

nhận biết nội dung - Content-Aware Hybrid Request Distribution (CAHRD) CAWLL

không phải là chính sách nhận biết địa phương, nó chọn back-end server có tải ít nhất xLARD/R là một phần mở rộng của LARD, xem xét bổ sung chi phí để ước tính tải tại các node back-end khi quyết định cân bằng tải CAHRD kết hợp cả CAWLL và xLARD/R Nó chuyển sang CAWLL khi một yêu cầu động đến, và sang xLARD/R khi thực hiện yêu cầu tĩnh Kết luận, kỹ thuật nhận biết địa phương phù hợp hơn đối với các yêu cầu tĩnh hơn so với yêu cầu động như CAWLL Do đó, CAHRD thực hiện tốt hơn xLARD/R khi hơn 30% tổng khối lượng tải tương ứng với nội dung web động

1.5.3.2 Các giải pháp không nhận biết địa phương

Từ năm 2001, ngày càng nhiều các giải pháp không nhận biết địa phương được đề xuất Chúng không xem xét số truy nhập bộ nhớ cache trong việc đánh giá hiệu suất của hệ thống web Do đó, các yếu tố khác được đề cập đến trong các chính sách này như đánh giá mức độ sử dụng tài nguyên của các loại yêu cầu khác nhau, việc đưa ra tiêu chuẩn QoS trong việc cung cấp dịch vụ, hoặc việc kiểm soát truy nhập trong giải pháp cân bằng tải

Khi chỉ xét nội dung của các yêu cầu gửi đến, chính sách nhận biết client (CAP Client-aware Policy), thu được kết quả hiệu suất tốt khi phục vụ nội dung và bảo mật Web động Khi các yêu cầu được phân loại phụ thuộc vào tác động dự kiến sẽ có trên các tài nguyên máy chủ, CAP sẽ phân phối các quyết định tùy thuộc vào loại dịch vụ theo yêu cầu của chúng Trạng thái của các máy chủ không được tính đến trong giải pháp này Tất cả máy chủ của cluster cung cấp cho các loại hình dịch vụ được xem xét

Chính sách thích ứng nhận biết thông điệp Message-Aware Adaptive (MAA) xét

nội dung của các yêu cầu đến và lấy một số số liệu từ các chuyển mạch web cho phép

để ước tính tải của các máy chủ web Đây là một chính sách lập lịch được phát triển để thực hiện trong mạng hướng ứng dụng - Application Oriented Networking (AON) - sản phẩm của Cisco Systems Chính sách này phân biệt giữa các loại thông điệp và cân bằng tải dựa trên tiêu thụ tài nguyên của chúng Do đó, khi yêu cầu đến hệ thống, sự ước lượng thời gian hoàn thành sẽ được tính toán và máy chủ có thời gian phục vụ ít nhất sẽ được chọn để phục vụ yêu cầu

Chính sách khác giám sát thông tin thu được từ các máy chủ web của cluster để

có quyết định phân phối Đây là trường hợp của sự phân phối yêu cầu thích ứng mờ -

Fuzzy Adaptive Request Distribution (FARD) Đây là một kỹ thuật cân bằng tải nhận biết nội dung ước lượng thời gian phản ứng của từng yêu cầu trong mỗi máy chủ của cluster bằng cách sử dụng kỹ thuật ước lượng mờ Dự đoán này dựa trên một số số liệu thu được từ các máy chủ, như CPU, đĩa và tải liên kết truyền thông Chính sách FARD chọn máy chủ với thời gian phản ứng được ước tính thấp nhất để tham dự các yêu cầu

So với LARD và WRR trong một mẫu thử nghiệm, FARD cải thiện hiệu suất hơn, đặc biệt trong môi trường không đồng nhất

Một nghiên cứu khác cũng lấy được thông tin hiệu suất bằng cách giám sát các

ứng dụng chạy trên các node là kỹ thuật cân bằng tải thích ứng - Adaptive Load

tính mở rộng trong một hệ thống đa cluster Thiết bị front-end của hệ thống là chuyển mạch Web layer-4 mà cân bằng tải bằng cách sử dụng DR và NAT, phân phối nhận biết nội dung được thực hiện từ các node của cluster ALBM được so sánh với LVS sử dụng RR, LC và các thuật toán lập lịch WLC

Các yêu cầu QoS trong một số chính sách lấy được thông tin giám sát từ các máy

chủ Web Chiến lược cân bằng tải nhận biết QoS mang tên Extended Fewest Server

Processes First (E-FSPF) Chúng kết hợp chính sách lập tiến trình trong các máy chủ

web, có xem xét mức độ ưu tiên của các yêu cầu, với kỹ thuật cân bằng tải ở thiết bị front-end của hệ thống, sẽ gửi yêu cầu đến máy chủ web với số ít nhất các tiến trình có mức độ ưu tiên cao hơn hoặc bằng

Một hệ thống phân phối web khác có tên Gage cân tải trong một tập hợp các máy

chủ web và hỗ trợ QoS Sử dụng một thiết bị front-end ghép kết nối TCP với máy chủ được lựa chọn trong kiến trúc một chiều Chiếm dụng tài nguyên được xem như là thước đo QoS và đảm bảo SLA bằng việc phân bổ các nguồn tài nguyên đa hệ thống Các yêu cầu được phân phối theo thuật toán WRR

Khi cân bằng tải theo QoS, thông thường các chính sách điều khiển truy nhập áp dụng để tránh sự sụp đổ đột ngột của các máy chủ do sự gia tăng yêu cầu Thuật toán cân bằng tải nhận biết nội dung kiểm soát truy nhập nhận biết QoS được đặt tên IQRD Giám sát các máy chủ web để tự động tính toán năng lực còn lại của hệ thống web Các yêu cầu được phân loại phụ thuộc vào nguồn tài nguyên mà chúng chiếm dụng tại các node máy chủ và được gán cho các node dựa trên tình trạng tải của các máy chủ đó So sánh IQRD với CAP và WRR, mặc dù IQRD có chi phí hoạt động cao hơn, nó vẫn cải thiện hiệu suất của hệ thống về thời gian phản ứng và băng thông

ADAPTLOAD xem xét lưu lượng động Theo chính sách ADAPTLOAD, không

có các xử lý ban đầu cho các yêu cầu động, nghiên cứu ảnh hương của sự tự tương quan (autocorrelation) đến quá trình hiệu suất của các chính sách cân bằng tải và đề

xuất một kỹ thuật không cân bằng tải, cố gắng giảm bớt sự tự tương quan của các kích

thước tập tin được yêu cầu Chính sách đó gọi là D_EQAL Trong trường hợp này, mục

tiêu cho nhận biết địa phương ít rõ ràng hơn trong ADAPTLOAD, đây là lý do để xem

D_EQAL như giải pháp không nhận biết địa phương

Vì nó không thể biết được tải khi thực hiện các kịch bản (script) liên quan đến

việc cải tiến máy chủ web, giám sát tải của các máy chủ thông qua thuật toán hoạt động trong chuyển mạch Web layer-4 Nếu các máy chủ đang tham dự cùng một số yêu cầu thì chuyển mạch web cân bằng các yêu cầu theo thuật toán RR Bộ chuyển sẽ gửi các yêu cầu kế tiếp tới máy chủ ít tải nhất trong cluster khi các giá trị tải của các máy chủ không bằng nhau Các kết nối duy trì khi sử dụng HTTP/1.1 được xem xét đến, vì thế trong trường hợp máy chủ mục tiêu đối với một yêu cầu là máy chủ khác thích hợp hơn máy chủ đang được kết nối thì giao thức chuyển giao TCP được sử dụng để di chuyển các kết nối đến máy chủ thích hợp đảm bảo khả năng mở rộng và QoS

1.6 Tổng kết chương I

Chương I tổng kết các kỹ thuật cân bằng tải đã được phát triển và phân loại cân bằng tải dựa trên các giao thức OSI Các kỹ thuật cân bằng tải không nhận biết nội dung đã được phát triển rộng rãi và cũng đã được coi là các sản phẩm thương mại (một

số đã được rút khỏi thị trường)

Các giải pháp cân bằng tải nhận biết nội dung phổ biến hơn (chủ yếu là vì chúng giới thiệu sự khác biệt nhiều trong khối lượng tải và phân phối chính xác hơn đối với các yêu cầu), khắc phục những nhược điểm của chúng Một số các hạn chế liên quan

đến khả năng mà chuyển mạch Web layer-7 sẽ trở thành node cổ chai “bottleneck” của

hệ thống và cũng như là các khó khăn phân tách các yêu cầu khi sử dụng giao thức HTTP/1.1 Những vấn đề này được giải quyết bằng cách sử dụng chuyển mạch web nội dung mù và chuyển giao nhiệm vụ phân phối đến các node của máy chủ Web

Các chính sách nhận biết địa phương đã được nghiên cứu rộng rãi trong những năm đầu của thập niên 2000, với mục đích khai thác các lợi ích hiệu suất bộ nhớ cache trong các máy chủ Web Hầu hết các thuật toán chỉ xem xét nội dung web tĩnh Khối lượng nội dung trang Web động khá phức tạp đối với cân bằng tải tương tự như việc không dễ đoán trước số lần phục vụ các kịch bản có thể tạo ra nội dung động Ngoài ra chi phí tạo ra một trang web động là tốn kém hơn về hiệu suất hơn so với chi phí phục

vụ các trang web tĩnh và rất khó để đo lường hoặc dự đoán Điều này vẫn là một trong những vấn đề mở cần nghiên cứu thêm

Tính chất mới “Freshness” của các thông tin thu được từ các máy chủ web mà thuật toán sử dụng để đưa ra quyết định cân bằng tải cũng là một vấn đề đã được nghiên cứu kỹ hơn, như hầu hết các đề xuất được mô tả ở đây không xem xét các khả năng thông tin tải là cũ