Tìm hiểu và triển khai hệ thống cân bằng tải và chịu lỗi trên môi trường Linux Đề tài nghiên cứu khoa học

HỌC VIỆN KỸ THUẬT MẬT MÃ
KHOA CÔNG NGHỆ THÔNG TIN

ĐỀ TÀI THỰC TẬP CƠ SỞ

TÌM HIỂU VÀ TRIỂN KHAI HỆ
THỐNG CÂN BẰNG TẢI VÀ CHỊU
LỖI TRÊN MÔI TRƯỜNG LINUX
Cán bộ hướng dẫn: Nguyễn Hồng Việt
Sinh viên thực hiện:
- Phạm Quốc Đạt
- Nguyễn Việt Tiến
- Hoàng Quang Thụy
Lớp: AT9A

HÀ NỘI 2015


HỌC VIỆN KỸ THUẬT MẬT MÃ
KHOA CÔNG NGHỆ THÔNG TIN

ĐỀ TÀI THỰC TẬP CƠ SỞ

TÌM HIỂU VÀ TRIỂN KHAI HỆ
THỐNG CÂN BẰNG TẢI VÀ CHỊU
LỖI TRÊN MÔI TRƯỜNG LINUX
Nhận xét của cán bộ hướng dẫn: .....................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................
..........................................................................................................................................

Điểm chuyên cần: ............................................................................................................
Điểm báo cáo: ..................................................................................................................

Xác nhận của cán bộ hướng


LỜI MỞ ĐẦU
Trong thời đại bùng nổ của công nghệ thông tin như hiện nay, mạng máy tính
đóng vai trò ngày càng quan trọng hơn trong hoạt động của các doanh nghiệp, tổ
chức cũng như các cơ quan nhà nước. Thậm chí ở một số đơn vị, chẳng hạn như
các công ty hàng không hoặc ngân hàng lớn, mạng máy tính có thể ví như hệ thần
kinh điều khiển hoạt động của toàn doanh nghiệp. Sự ngừng hoạt động của mạng
máy tính hay sự hoạt động kém hiệu quả của mạng máy tính trong những cơ quan
này có thể làm tê liệt các hoạt động chính của đơn vị, và thiệt hại khó có thể lường
trước được.
Chúng ta đều biết các máy chủ là trái tim của mạng máy tính, nếu máy chủ
mạng hỏng, hoạt động của hệ thống sẽ bị ngưng trệ. Điều đáng tiếc là dù các hãng
sản xuất đã cố gắng làm mọi cách để nâng cao chất lượng của thiết bị, nhưng
những hỏng hóc đối với các thiết bị mạng nói chung và các máy chủ nói riêng là
điều không thể tránh khỏi. Do vậy, vấn đề đặt ra là có một giải pháp để đảm bảo
cho hệ thống vẫn hoạt động tốt ngay cả khi có sự cố xảy ra đối với máy chủ mạng.
Việc lựa chọn một server đơn lẻ có cấu hình cực mạnh để đáp ứng nhu cầu này sẽ
kéo theo chi phí đầu tư rất lớn và không giải quyết được các vấn đề đặt ra của tổ
chức. Giải pháp hiệu quả được đưa ra là sử dụng một nhóm server cùng thực hiện
một chức năng dưới sự điều khiển của một công cụ phân phối tải – Giải pháp cân
bằng tải. Có rất nhiều hãng đưa ra giải pháp cân bằng tải như Cisco, Coyote, Sun,
Microsystem... với nhiều tính năng phong phú. Tuy nhiên, về cơ bản, nguyên tắc
cân bằng tải vẫn xuất phát từ những quan điểm kỹ thuật khá tương đồng. Một kỹ
thuật cân bằng tải điển hình là RRDNS (Round Robin DNS). Với giải pháp này,
nếu một server trong nhóm bị lỗi. RRDNS sẽ vẫn tiếp tục gửi tải cho server đó cho

đến khi người quản trị mạng phát hiện ra lỗi và tách server này ra khỏi danh sách
địa chỉ DNS. Điều này sẽ gây ra sự đứt quãng dịch vụ. Sau những phát triển, từ
các thuật toán cân bằng tải tĩnh như Round Robin, Weighted Round Robin đến các
thuật toán cân bằng tải động như Least Connection, Weighted Least Connection,
Optimized Weighted Least Connection và Optimized Weighted Round Robin. Kỹ
thuật cân bằng tải hiện nay nhờ sự kết hợp các thuật toán trên ngày càng trở nên


hoàn thiện mặc dù nhược điểm vốn có như tạo điểm lỗi đơn bị và thắt nút cổ chai
do sử dụng bộ điều phối tập trung (centralized dispatcher) vẫn còn. Ngoài khả
năng áp dụng với Web server, kỹ thuật này còn có thể áp dụng với các hệ server
ứng dụng khác. SLB không chỉ làm nhiệm vụ phân phối tải cho các server mà còn
cung cấp cơ chế đảm bảo hệ thống server luôn khả dụng trước các client. SLB
không yêu cầu đặc biệt gì về phần cứng, bất cứ máy tính nào hợp chuẩn đều có thể
được sử dụng làm server. Chi phí triển khai nhờ đó giảm đáng kể. Kiến trúc phần
mềm phân tán của SLB cho phép cung cấp hiệu năng và tính khả dụng của kỹ
thuật này ở mức cao nhất.


Chương I.TỔNG QUAN VỀ CÂN BẰNG TẢI

1. Giới thiệu cân bằng tải
Cơ sở hạ tầng công nghệ thông tin đang giữ một nhiệm vụ ngày càng quan
trọng trong sự thành công của một doanh nghiệp. Thị phần,quý khách hàng hài
lòng với sản phẩm của công ty và hình ảnh công ty tất cả những thứ này có thể do
website của doanh nghiệp đó chiếm một phần quan trọng. Hệ thống các máy
chủ hiện nay thường xuyên được sử dụng để lưu trữ ERP, thương mại điện tử và vô
số các ứng dụng khác. Nền tảng của các webiste này, các chiến lược kinh doanh,
tính sẵn sàng cao, cơ sở hạ tầng tốt sẽ cung cấp hiệu suất cao và các giải pháp an
toàn và khả năng mở rộng để hỗ trợ tất cả các ứng dụng.

Bên cạnh đó, sự sẵn có của các ứng dụng này thường bị đe dọa bởi quá tải mạng
cũng như sự cố xảy ra trên các hệ thống máy chủ và các ứng dụng. Sử dụng tài
nguyên thường trong sự cân bằng, dẫn đến các nguồn lực hiệu suất thấp đang quá
tải với các yêu cầu, trong khi các nguồn lực hiệu suất cao vẫn nhàn rỗi. Server
Load Balancing (máy chủ cân bằng tải) là một giải pháp giúp cân bằng lại giữa các
nguồn lực và giúp tăng hiệu suất làm việc cho hệ thống mạng trong doanh nghiệp.

1.1.

Khái niệm cân bằng tải

Cân bằng tải là một phương pháp phân phối khối lượng tải trên nhiều máy
tính hoặc một cụm máy tính để có thể sử dụng tối ưu các nguồn lức, tối đa hóa
thông lượng, giảm thời gian đáp ứng và tránh tính trạng quá tải trên máy chủ. Là cơ
chế định tuyến các gói tin qua các đường metric bằng nhau. Cân bằng tải dùng để
chia sẻ dữ liệu truyền trên mạng giúp cho việc truyền tải thông suốt, không bị
nghẽn mạng do quá tải hay do một sự cố nào đó. Hoặc khi có một máy server nào
đó bị trục trặc thì sẽ có máy server khác thay thế để giúp nhận dữ liệu thay thế cho


server bị trục trặc đó, giúp cho việc truyền tải không bị ngừng do máy server bị lỗi
đó gây ra.
1.2. Lợi ích cân bằng tải

- Tăng khả năng đáp ứng, tránh tình trạng quá tải trên máy chủ, đảm bảo tính
linh hoạt và mở rộng hệ thống.
Nhiều ứng dụng chuyên sâu có quy mô lớn, vì vậy đòi hỏi các máy chủ phải có
sự cân bằng tải cho nhau mới có thể chạy tốt các ứng dụng như vậy. Vì vậy cần
sự linh hoạt để triển khai thêm các máy chủ một cách nhanh chóng và minh
bạch để đáp ứng được nhu cầu xử lý công việc.

Server Load Balancing (máy chủ cân bằng tải) làm cho nhiều máy chủ xuất hiện
như là một máy chủ duy nhất, một dịch vụ đơn ảo, phân phối các yêu cầu người
sử dụng trong các máy chủ.
- Tăng độ tin cậy và nâng cao hiệu suất hệ thống: Hiệu suất cao nhất là đạt được
khi sức mạnh xử lý của máy chủ được sử dụng thông minh. Nâng cao cân bằng
tải máy chủ có thể trực tiếp yêu cầu dịch vụ người dùng cuối để các máy chủ xử
lý công việc được đồng đều nhau và do đó khả năng cung cấp nhanh nhất thời
gian để đáp ứng. Nhất thiết, các thiết bị cân bằng tải phải có khả năng xử lý lưu
lượng tổng hợp của nhiều máy chủ. Nếu một thiết bị cân bằng tải máy chủ trở
thành một “nút cổ chai” nó không còn là một giải pháp, nó chỉ là một vấn đề bổ
sung
- Tăng tính sẵn sàng ứng dụng: Nếu một ứng dụng hoặc máy chủ không thành
công, cân bằng tải có thể tự động phân phối lại yêu cầu dịch vụ người dùng cuối
để các máy chủ khác trong một nhóm các máy chủ hoặc tới các máy chủ trong
một địa điểm. Máy chủ cân bằng tải cũng có kế hoạch ngăn ngừa sự cố cho phần
mềm hoặc bảo trì phần cứng bằng các dịch vụ.
- Tăng tính bảo mật hệ thống: Khi người dùng gửi yêu cầu dịch vụ đến hệ thống,
yêu cầu đó sẽ được xử lý trên bộ cân bằng tải, sau đó thành phần cân bằng tải
mới chuyển tiếp yêu cầu cho các máy chủ bên trong. Quá trình trả lời cho khách
hàng cũng thông qua thành phần cân bằng tải, vì vậy mà người dùng không thể
biết được chính xác các máy chủ bên trong cũng như phương pháp phân tải


được sử dụng. Bằng cách này có thể ngăn chặn người dùng giao tiếp trực tiếp
với các máy chủ, ẩn các thông tin và cấu trúc mạng nội bộ, ngăn ngừa các cuộc
tấn công trên mạng hoặc các dịch vụ không liên quan đang hoạt động trên các
cổng khác.
1.3.

So sánh hệ thống cân bằng tải server và hệ thống thông thường

Kịch bản A

Kịch bản B

Tính sẵn sàng cao

Có

Không

Tính mở rộng

Có

Không

Ứng dụng

Xử lý đa nhiệm

Xử lý nhanh đơn nhiệm

Hình 2.1. So sánh hệ thống cân bằng tải server và hệ thống thông thường
Ưu điểm của cân bằng tải:
- Tính mở rộng: thêm hoặc bỏ bớt server một cách dễ dàng.
- Tính sẵn sàng cao do hệ thống dùng nhiều Server Vì vậy hệ thống có tính dự phòng.
- Tính quản lý: Theo dõi và quản lý tập trung hệ thống Server, bảo dưỡng hệ thống
server mà không cần tắt các dịch vụ.
- Có thể tách các ứng dụng khỏi server.

- Làm việc được với nhiều hệ điều hành.
- Hiệu suất cao.
- Server được nhóm lại thực hiện đa nhiệm vụ tốt hơn.
- Tất cả Server đều hoạt động đúng công suất không có tình trạng một Server làm việc
quá tải trong khi server khác lại đang “nhàn rỗi”.
Những tổ chức nào cần có giải pháp cân bằng tải ?


- Các doanh nghiệp
- Nhà cung cấp dịch vụ ISP
- Trung tâm xử lý dữ liệu
- Chính phủ
- Phòng thí nghiệm
- Trường đại học, viện nghiên cứu…

2. Kỹ thuật cân bằng tải
Như chúng ta đã biết, bộ cân bằng tải có nhiệm vụ kết nối giữa người dùng và server, do
đó nó có thể hoạt động như một proxy hoặc gateway. Một proxy có nhiệm vụ luân chuyển
yêu cầu và dữ liệu đáp trả giữa người dùng và server, trong khi đó một gateway chỉ có
nhiệm vụ tạo ra một kết nối hai đối tượng này và không làm gì thêm. Có thể sử dụng phần
cứng hoặc phần mềm được cài đặt trên một front server, hoặc trên chính web server.
Thêm nữa, khi số lượng người dùng tăng lên, để tránh SPOF [1], cần thiết phải cài đặt 2 bộ
cân bằng tải song song, hoạt động theo cơ chế active-active hoặc active-standby.

2.1. Kiểm tra trạng thái server
Để chọn được server phù hợp để gửi request, bộ cân bằng tải cần phải biết được
server nào đang có sẵn. Vì vậy, nó cần phải dùng biện pháp nào đó để kiểm tra trạng thái
của server, chằng hạn như gửi lệnh ping, các yêu cầu, thử kết nối hay bất cứ phương pháp
nào mà người quản trị nghĩ là dùng được. Kỹ thuật kiểm tra này thường được gọi là
“health checks”.

Một server bị down có thể trả lời lệnh ping nhưng không thể trả lời các kết nối
TCP, một server bị treo có khả năng trả lời kết nối TCP nhưng không thể trả lời các yêu
cầu HTTP. Khi một ứng dụng web nhiều lớp được kích hoạt, một số yêu cầu HTTP có thể
trả lời ngay lập tức trong khi số khác sẽ thất bại.
Chính vì thế, việc chọn một phương pháp test phù hợp được chấp nhận bởi ứng
dụng web và bộ cân bằng tải là rất thú vị. Một số test đôi khi phải cần truy xuất dữ liệu
database nhằm đảm bảo rằng toàn bộ quá trình của nó là đúng. Hạn chế lớn nhất là những
phương pháp kiểm tra này sẽ chiếm tài nguyên của hệ thống như là CPU, threads…
1

[1] SPOF(Single point of failure): Một điểm trong hệ thống mà nếu nó ngừng hoạt động, toàn bộ hệ thống
sẽ bị tê liệt


Do đó, cân bằng thời gian kiểm tra chính là vấn đề khó nhất trong kỹ thuật lựa
chọn server. Khoảng thời gian giữa 2 lần test liên tiếp phải đủ dài để không tốn quá nhiều
tài nguyên của hệ thống và cũng cần đủ ngắn để nhanh chóng phát hiện ra những server
“chết”. Vì “health checks” là một trong những khía cạnh phức tạp nhất của kỹ thuật cân
bằng tải, nên thường sau một vài kiểm tra, các nhà phát triển ứng dụng sẽ thực thi một
yêu cầu đặc biệt dành riêng cho bộ cân bằng tải, giúp cho nó thực hiện một số kiểm tra
nội bộ.
Phần mềm cân bằng tải có khả năng cung cấp scripting, do đó nó đạt được độ linh
hoạt rất cao. Thêm nữa, nếu như một bài kiểm tra nào đó đòi hỏi phải chỉnh sửa code, nó
có thể thực hiện trong một khoảng thời gian ngắn.

2.2. Lựa chọn server tốt nhất
Phương pháp dễ nhất và thường được sử dụng nhất trong các hệ thống nhỏ là
Round Robin, các server được lựa chọn quay vòng, tuy nhiên phương pháp này có nhược
điểm là 2 requests liên tục từ một người dùng sẽ vào 2 servers khác nhau, thông tin giữa 2
yêu cầu liên tiếp sẽ bị mất, như vậy sẽ không thể tối ưu hóa được sử dụng tài nguyên. Đặc

biệt là khi cần phải cài đặt kết nối cho các phiên chạy - ví dụ như SSL key negociation sẽ rất tốn thời gian.
Một cách khắc phục nhược điểm này là sử dụng một hàm băm theo địa chỉ IP, như
vậy requests từ cùng một địa chỉ IP sẽ chỉ vào một server duy nhất. Tuy vậy phương pháp
này đòi hỏi người dùng phải có IP tĩnh. Vậy thì cách khắc phục cho những hạn chế trên là
gì? Đó chính là kỹ thuật Persistence.

2.3. Kỹ thuật Session Persistence
Như đã đề cập ở trên, vấn đề cần giải quyết chính là làm sao để giữ cho các yêu
cầu của một người dùng được gửi vào một máy duy nhất trong suốt phiên làm việc của
người đó. Tất cả các yêu cầu của người dùng này cần phải được chuyển vào cùng một
server. Nếu server bị chết, hoặc ngừng để bảo trì, cần phải có cơ chế để chuyển session
của người dùng này sang máy server khác. Đó chính là kỹ thuật Session Persistence.
Có một số giải pháp được đưa ra để tiếp cận kỹ thuật này, chẳng hạn như sử dụng
một respone HTTP 302 hay tạo ra liên kết giữa người dùng – server. Tuy vậy 2 phương
pháp này đều có những hạn chế, sử dụng HTTP 302 sẽ khiến người dùng luôn luôn tìm


cách kết nối với một server duy nhất, kể cả khi server này đã “chết”. Dùng cách tạo liên
kết đòi hỏi user phải có IP tĩnh trong suốt phiên làm việc.
Vậy thì câu trả lời cuối cùng là gì? Đó chính là sử dụng cookie. Cookie là một đối tượng
được điều khiển bởi Web Servers. Trong kết quả trả về cho người dùng web servers sẽ
chèn thêm một số thông tin. Những yêu cầu tiếp theo của người dùng gửi đến server sẽ
chứa thêm thông tin của cookie này, server sẽ đọc các cookie và biết phải làm gì với các
yêu cầu này.


2.4. Cookie
Một cookie được định nghĩa bằng cặp tên=giá trị (name=value). Hình 1.1 miêu tả
hoạt động của cookie với cặp user=1, cho biết tên cookie là user và giá trị của nó là 1.
Bên phía người dùng, cookie được điều khiển bởi trình duyệt và “trong suốt” đối với

người dùng.

Hình 1.1. Cách làm việc của cookie user=1
Trong thiết kế của bộ cân bằng tải, có 3 cách để sử dụng cookie: Cookie chỉ đọc
(Cookie-Read), bộ cân bằng tải chèn cookie nhằm chứng thực server (Cookie-Insert) và
ghi đè cookie (Cookie-Rewrite).
+ Cookie-Read
Cách thức hoạt động của cookie-read được mô tả trong hình 1.2 dưới đây. Khi người
dùng lần đầu tiên gửi yêu cầu đến server, do không có cookie trong yêu cầu, nên nó sẽ
được phân tải đến server RS1 (1). Server RS1 sẽ tạo và đặt cookie server=1 vào trong dữ
liệu trả về cho người dùng (2). Trình duyệt của người dùng sẽ nhận trả về này, đọc thấy
cookies và lưu trữ nó vào trong đĩa cứng (3). Sau đó người dùng có thể đóng trình duyệt
hoặc ngắt kết nối (giả sử rằng trình duyệt của người dùng không tự động xóa cookie sau
khi đóng). Một thời gian sau người dùng kết nối lại và gửi yêu cầu đến bộ cân bằng tải .
Sau khi kết nối được thiết lập, trình duyệt người dùng sẽ gửi cookie server=1 như là một
phần của yêu cầu HTTP (4). Bộ cân bằng tải sẽ đọc được cookie này, và do đó sẽ chuyển
yêu cầu của người dùng vào server RS1. Như vậy người dùng sẽ luôn được kết nối vào
server 1 cho đến khi nào cookie còn tồn tại, cho dù người dùng có thể vào website từ các
địa chỉ IP khác nhau.


Hình 1.2. Cookie read
Ưu điểm của phương pháp cookie-read là nó không đòi hỏi bộ cân bằng tải phải
làm việc nhiều, chỉ cần đọc cookie được tạo ra từ phía web-server và từ yêu cầu của
người dùng. Nhược điểm của phương pháp này là ứng dụng ở server phải tạo ra một
cookie, điều này không khó khăn lắm, nhưng nó sẽ khiến nhà phát triển ứng dụng phải
thay đổi mã nguồn chương trình. Khi một server mới được lắp đặt, người quản trị hệ
thống phải sửa đổi hoặc đặt thêm thông số server vào file cấu hình của bộ cân bằng tải.
+ Cookie-Insert
Phương pháp này được mô tả trong hình 1.3. Trong phương pháp này, ứng dụng ở

server sẽ không làm gì cả. Kịch bản diễn ra tương tự như cookie-read, nhưng ở đây, khi
server trả về dữ liệu cho người dùng (2), bộ cân bằng tải sẽ xem là server nào trả về dữ
liệu, và chèn vào đó một cookie chứa thông tin về server này, chẳng hạn như cookie
server=1 trong hình vẽ. Khi người dùng kết nối lần tiếp theo, bộ cân bằng tải sẽ đọc thông
tin về cookie này, và chuyển hướng yêu cầu của người dùng vào đúng server RS1.


Hình 1.3. Cookie-insert
Ưu điểm của phương pháp này là nó “trong suốt” đối với ứng dụng được cài đặt
trên server, hay nói cách khác ứng dụng server sẽ không cần phải tạo ra một cookie hay
không cần quan tâm xem cookie là gì. Khi 1 server được thêm mới hoặc xóa bỏ, hoặc khi
file cấu hình của bộ cân bằng tải bị thay đổi, người quản trị hệ thống sẽ không cần phải lo
lắng về việc cập nhập file cấu hình cho server. Nhược điểm của phương pháp này là có
thể gây ra quá tải ở bộ cân bằng tải. Chúng ta có thể thấy rõ số lượng công việc mà bộ cân
bằng tải phải làm khi chèn 1 cookie trong hình 1.4. Vì cần phải chèn dữ liệu nên gói dữ
liệu trả về phải được sao lại 1 phần, vì vậy tăng dung lượng bộ nhớ cần thiết ở phía bộ cân
bằng tải, thêm vào đó còn tăng dung lượng gói tin trả về cho người dùng, có thể khiến gói
tin bị chia đôi, dẫn đến mất dữ liệu.
.

Hình 1.4 Bộ cân bằng tải chèn một cookie
+ Cookie-Rewrite


Phương pháp cookie-read không đòi hỏi bộ cân bằng tải phải làm quá nhiều việc
như cookie-insert, trong khi đó cookie-insert lại không yêu cầu ứng dụng phía server phải
tạo cookie còn cookie-read lại cần. Cần phải có một phương pháp dung hòa ưu và nhược
điểm của 2 phương pháp trên. Đó chính là phương pháp ghi đè cookie.
Nhược điểm lớn nhất trong cookie-insert là cần phải có một bộ nhớ phức tạp, và
thêm nữa có thể khiến gói tin bị chia thành 2 (do dung lượng vượt quá giá trị lớn nhất của

gói tin được chấp nhận ở Ethernet) và dẫn đến mất dữ liệu. Chuyện gì sẽ xảy ra nếu như
chúng ta tạo một chỗ trống ở gói tin để lưu giá trị cookie, và bộ cân bằng tải chỉ cần đặt
vào đó giá trị cần thiết. Trong phương pháp ghi đè cookie, được mô tả như hình 1.5 ở
dưới, ứng dụng sẽ chèn vào gói tin trả về một cookie server=XXX. Tất cả những gì bộ
cân bằng tải phải làm là tìm kiếm đoạn server=XXX này và thay “XXX” bằng giá trị ID
của server, chẳng hạn như server=001.

Hình 1.5 Bộ cân bằng tải ghi đè một cookie
Ưu điểm của phương pháp này là tránh cho bộ cân bằng tải làm việc quá mức và
tránh cho gói tin bị chia nhỏ. Bên cạnh đó nó cũng khắc phục được nhược điểm của
phương pháp cookie-read. Nó là phương pháp tốt nhất trong 3 phương pháp đã được đề
cập ở trên và thường được chọn để dùng trong các bộ cân bằng tải.


2.5. Cân bằng tải sử dụng phần cứng
Bộ cân bằng tải bằng phần cứng sẽ thể hiện một địa chỉ IP ảo đối với mạng bên
ngoài, địa chỉ này bản đồ hóa đến các địa chỉ của mỗi máy trong một cluster. Chính vì vậy
toàn bộ các máy tính trong cluster sẽ chỉ được xem như là một máy duy nhất đối với thế
giới bên ngoài. Bộ cân bằng tải sử dụng phần cứng thường hoạt động ở tầng mạng và hoạt
động dựa trên sự định tuyến, sử dụng một trong các phương pháp: Định tuyến trực tiếp
(direct routing), tunnelling, IP address translation (NAT).
Khi một request đến bộ cân bằng tải, nó sẽ ghi lại header của request để trỏ đến các
máy khác trong cluster. Nếu một máy nào đó bị gỡ bỏ từ cluster thì request sẽ không chạy
một cách rủi ro việc “hit” vào máy server đã chết này, vì tất cả các máy server khác trong
cluster xuất hiện đều có cùng địa chỉ IP. Địa chỉ này duy trì giống nhau thậm chí nếu một
nút nào đó trong cluster bị hỏng. Khi một đáp trả được trả về, client sẽ xem đáp trả đang
đến từ bộ cân bằng tải phần cứng. Hay nói theo cách khác thì người dùng sẽ xử lý với một
máy tính đó là bộ cân bằng tải sử dụng phần cứng.

Hình 1.6 Cân bằng tải sử dụng phần cứng

Ưu điểm của phương pháp này là:


• Mối quan hệ giữa các máy chủ. Bộ cân bằng tải phần cứng đọc cookie hoặc các
URL đang được đọc trên mỗi một request bởi máy khách. Dựa trên các thông tin này, nó
có thể ghi lại các thông tin header và gửi request đến nút thích hợp trong cluster, nơi
session của nó được duy trì.
Các bộ cân bằng tải này có thể cung cấp mối quan hệ giữa các máy server trong
truyền thông HTTP, nhưng không thông qua kênh an toàn như HTTPS. Trong kênh an
toàn, các thông báo được mã hóa SSL và có thể tránh bộ cân bằng tải đọc các thông tin
session.
• Khả năng có sẵn cao thông qua hệ thống tự động chuyển đổi dự phòng. Việc
chuyển đổi dự phòng xảy ra khi một nút trong cluster không thể xử lý một request và
chuyển hướng nó đến một nút khác. Có hai kiểu tự động chuyển đổi dự phòng:
 Yêu cầu mức chuyển đổi dự phòng. Khi một nút trong cluster không thể xử lý một
request (thường là vì bị hỏng) thì nó sẽ chuyển request này sang một nút khác.
 Chuyển đổi dự phòng session một cách trong suốt. Khi một lời triệu gọi thất bại,
nó sẽ được định tuyến một cách trong suốt đến một nút khác trong cluster để hoàn
tất công việc.
Bộ cân bằng kiểu này cung cấp chuyển đổi dự phòng mức request; tức là khi nó
phát hiện có một nút nào đó bị sự cố thì bộ cân bằng này sẽ chuyển hướng tất cả các
request theo sau được gửi đến nút này sang một nút tích cực khác trong cluster. Mặc dù
vậy, bất kỳ một thông tin session nào trên nút chết sẽ bị mất khi các request được chuyển
hướng đến một nút mới.
Chuyển đổi dự phòng session trong suốt yêu cầu một số kiến thức về sự thực thi
cho một quá trình trong một nút, vì bộ cân bằng tải phần cứng chỉ có thể phát hiện các
vấn đề mức mạng, không có lỗi. Để thực thi một cách trong suốt về vấn đề chuyển đổi dự
phòng, các nút trong cluster phải kết hợp với các nút khác và có vùng bộ nhớ chia sẻ hoặc
cơ sở dữ liệu chung để lưu tất cả các dữ liệu session. Cũng chính vì vậy nếu một nút trong
cluster có vấn đề thì một session có thể tiếp tục trong một nút khác.

• Metrics. Vì tất cả các yêu cầu tới một ứng dụng web đều phải qua hệ thống cân
bằng tải, hệ thống có thể quyết định số lượng session hoạt động, số lượng session hoạt
động được kết nối trong các trường hợp khác nhau, các khoảng thời gian đáp ứng, thời
gian tối đa điện áp, số lượng session trong suốt khoảng tối đa điện áp, số lượng session
trong suốt khoảng tối thiểu điện áp… Tất cả các thông tin kiểm định này được sử dụng để
tinh chỉnh toàn bộ hệ thống nhằm tối ưu hiệu suất.


2.6. Cân bằng tải sử dụng phần mềm
Kết hợp nhiều server một cách chặt chẽ tạo thành một server ảo (virtual server).
Các hệ điều hành cho máy chủ thế hệ mới của các hãng Microsoft, IBM, HP... hầu hết đều
cung cấp khả năng này, một số hãng phần mềm khác như Veritas(Symantec) cũng cung
cấp giải pháp theo hướng này. Các giải pháp thuộc nhóm này có ưu điểm là quen thuộc
với những nhà quản trị chuyên nghiệp, có thể chia sẻ được nhiều tài nguyên trong hệ
thống, theo dõi được trạng thái của các máy chủ trong nhóm để chia tải hợp lý. Tuy nhiên,
do sử dụng phần mềm trên server, tính phức tạp cao nên khả năng mở rộng của giải pháp
này bị hạn chế, phức tạp khi triển khai cũng như khắc phục khi xảy ra sự cố, có rào cản về
tính tương thích, khó có được những tính năng tăng tốc và bảo mật cho ứng dụng.

2.7. Cân bằng tải với proxy
Nhóm này thường tận dụng khả năng chia tải sẵn có trên phần mềm proxy như ISA
Proxy của Microsoft hay Squid phần mềm mã nguồn mở cài trên máy phổ dụng. Proxy
này sẽ thực hiện nhiệm vụ chia tải trên các server sao cho hợp lý. Giải pháp này vì hoạt
động ở mức ứng dụng nên có khả năng caching (là công nghệ lưu trữ cục bộ dữ liệu được
truy cập với tần suất cao) và khả năng firewall ở tầng ứng dụng. Vì sử dụng máy phổ
dụng nên giải pháp này có ưu điểm là chi phí thấp, khả năng mở rộng tốt vì cài đặt trên
một máy độc lập, dễ quản trị. Tuy nhiên, cũng vì chỉ hoạt động ở mức ứng dụng nên hiệu
năng không cao, vì sử dụng máy phổ dụng nên không được tối ưu, dễ tồn tại nhiều lỗi hệ
thống, vì cài đặt trên một máy độc lập nên việc theo dõi trạng thái của các máy chủ gặp
khó khăn. Nhược điểm lớn nhất của các giải pháp này thường có tính ổn định kém, hiệu

năng thấp, dễ mắc lỗi. Đây là điều không thể chấp nhận được đối với các hệ thống đòi hỏi
tính sẵn sàng cao như ngân hàng, tài chính.

2.8. Cân bằng tải với thiết bị kết nối
Nhóm này thường sử dụng các mođun cắm thêm trên các thiết bị chuyên dụng như
Bộ định tuyến (Router) hay hay bộ chuyển mạch (Switch) để chia tải theo luồng, thường
hoạt động từ layer 4 trở xuống. Vì sử dụng thiết bị chuyên dụng nên có hiệu năng cao,
tính ổn định cao, khả năng mở rộng tốt hơn nhưng khó phát triển được tính năng bảo mật
phức tạp như giải pháp proxy, thường thuật toán chia tải rất đơn giản như DNS round-


robin (đây là thuật toán chia tải phổ biến nhất và đơn giản, tuy nhiên cứng nhắc và hiệu
quả thấp. Với thuật toán này các yêu cầu về IP của một tên miền ứng với nhiều server sẽ
được biên dịch thành địa chỉ IP của các server đó theo thứ tự quay vòng. Nhóm này có
khả năng chia tải động kém, không theo dõi được trạng thái của máy chủ, xử lý kết nối ở
mức ứng dụng rất kém, dễ gây lỗi ứng dụng và giá thành cao. Cách thức này cũng hoàn
toàn không phù hợp đối với các hệ thống yêu cầu tính chuẩn xác của các hoạt động giao
dịch như tài chính, ngân hàng.
Như vậy, giải pháp có khả năng theo dõi trạng thái ứng dụng tốt thì mở rộng, tăng
tốc, bảo mật kém(GP dùng phần mềm). Giải pháp mở rộng, tăng tốc, bảo mật tốt, thì theo
dõi trạng thái ứng dụng kém, không ổn định, hiệu năng thấp(GP sử dụng proxy), giải
pháp hiệu năng cao, ổn định, mở rộng tốt thì kém thông minh, dễ gây lỗi ứng dụng, tăng
tốc kém(GP chia tải nhờ thiết bị chia kết nối). Trong khi đó, tất cả các yêu cầu về hiệu
năng cao, ổn định, mở rộng tốt, tăng tốc tốt và bảo mật là rất quan trọng đối với các hoạt
động của ngân hàng, chứng khoán và các nhà cung cấp dịch vụ. GP sẵn có của các hãng
chỉ đáp ứng được một phần trong các yêu cầu trên như Module CSS của Cisco, ISA của
Microsoft, hay Netscaler của Citrix).

2.9. Xử lý các yêu cầu kết nối tập trung
Thay vì ủy quyền cho DNS việc phân phối những yêu cầu đến các server riêng lẻ

trong một cluster, phuơng pháp xử lý các yêu cầu kết nối tập trung (Centrallized
Connection Routing - CCR) sử dụng một router cục bộ để thực hiện chức năng này.

Hình 1.7. Xử lý các yêu cầu kết nối tập trung


Router hoạt động như một bảng chuyển mạch, phân phối các yêu cầu dịch vụ đến các
node riêng lẻ trong cluster.
Ưu điểm của kĩ thuật CCR:
•

•

Việc định huớng lại cho các kết nối Client đến các server thích hợp trong hệ thống
là hoàn toàn trong suốt với người dùng.
Tính linh hoạt cao: khi phát hiện một node bị chết, local router sẽ chuyển tất cả các
yêu cầu kế tiếp đến node khác đang hoạt động.

Nhuợc điểm của kĩ thuật CCR:
•

•
•

Khi kết nối từ client đến routẻ tăng cao toàn bộ hệ thống sẽ gặp tình trạng nút cổ
chai ngay tại thiết bị này.
Thiết bị router là thiết bị phần cứng nên giá thành cao.
Khi thiết bị trung tâm hong toàn bộ hệ thống sẽ ngưng hoạt động do đó tính chịu
lỗi thấp.

Tóm lại, kỹ thuật xử lý các yêu cầu kết nối tập trung rõ ràng đã giải quyết được vấn đề
cân bằng tải trên mạng. Tuy nhiên kỹ thuật này có tính chịu lỗi thấp và chi phí cao.

3. Các thuật toán cân bằng tải
3.1. Thuật toán ngẫu nhiên (random)

Trong thuật toán random, tải sẽ được phân phối một cách ngẫu nhiên vào
trong các web server. Web server được chọn dựa trên một hàm chọn số ngẫu nhiên,
sau đó yêu cầu hiện tại từ phía người dùng sẽ được chuyển vào server này.
Thuật toán này có thể thực hiện như sau:
arrayServer [] == list_of_server ();
int n = number_of_active_server;


int i = get_random_number (n);
proxy ->server = arrayServer [i];
Thuật toán này hầu như không dùng đến trong các bộ phận cân bằng tải mặc
dù nó được cài đặt sẵn, nó chỉ thường thấy trong các gói phần mềm lớn mà trong đó
cân bằng tải chỉ được đưa ra như một chức năng.

3.2. Thuật toán Round Robin (RR)

RR là thuật toán được dùng thường xuyên nhất trong các hệ thống vừa và
nhỏ, có ít đòi hỏi về khả năng mở rộng. Một kết nối mới sẽ được gửi đến server kế
tiếp trong cụm server, và cứ quay vòng như vậy. RR làm việc tốt trong mọi cấu
hình, nhưng sẽ tốt hơn nếu như các trang thiết bị đang được cân bằng tải khác nhau
về tốc độ xử lý, tốc độ kết nối hoặc bộ nhớ.
Một cách để thực thi thuật toán này là sử dụng một server_map. Bộ cân bằng
tải sẽ được khai báo như một con trỏ proxy, nó sẽ có biến server_map là một mảng
các server và biến srv_rr_idx để chỉ định server tiếp theo trong chu kỳ round robin.

Sample code:
/*Kiểm tra xem có server nào sẵn có không bằng cách kiểm tra kích thước
server_map*/
If (srv_map_size = 0)
Return NULL;
If (srv_rr_idx > proxy->srv_map_size)
/*Nếu đến cuối mảng srv_map, update lại giá trị srv_rr_idx */
Srv_rr_idx = 0;
Int newidx = px->srv_rr_idx;
Do {
Srv = proxy ->srv_map [newidx++];
/*Trả về server và update lại giá trị srv_rr_idx*/
return srv;
proxy->srv_rr_idx = newidx;
} while (newidx !=srv_rr_idx)
/*Thực hiện cho đến khi lấy được server tiếp theo*/


RR hoạt động tốt khi các server có khả năng xử lý (cấu hình) tương tự nhau,
tuy nhiên sẽ có hiện tượng mất cân bằng khi các server đang nhiều hơn hẳn một
server khác, nhưng lượng kết nối tiếp theo mà các server này nhận được vẫn bằng
nhau. Do đó một số server sẽ phải xử lý nhiều hơn hẳn các server khác. Tuy vậy, vì
tính đơn giản của nó, nên nó hoạt động rất hiệu quả (không phải mất thêm thời gian
tính toán các thông số khác nên việc phân tải diễn ra rất nhanh). Nếu các server
hoạt động bình thường và không xảy ra sự cố thì sử dụng RR rất tốt.
Điểm yếu của RR là 2 yêu cầu liên tục từ phía một người dùng có thể sẽ được
gửi vào 2 server khác nhau. Điều này không tốt vì khi người dùng đang được kết
nối vào một server, thông tin mà họ cần đang ở server đó, nếu kết nối tiếp theo vẫn
được server đó xử lý thì sẽ góp phần tăng tốc độ đáp ứng cho người dùng. Do đó
thuật toán RR thường được cài đặt cùng với các phương pháp duy trì session như

sử dụng cookie.
3.3. Thuật toán Weighted Round Robin (Ratio)

Nguyên lý hoạt động của thuật toán WRR cũng giống như thuật toán RR, yêu
cầu từ phía người dùng sẽ được bộ cân bằng tải chuyển đến các server theo thứ tự
xoay vòng. Sự khác biệt duy nhất ở đây là thuật toán WRR còn quan tâm đến khả
năng xử lý (cấu hình) của các server. Trong cùng một chu kỳ, 1 server có khả năng
xử lý gấp đôi server khác sẽnhận được gấp đôi số yêu cầu từ phía bộ cân bằng tải.
Giả sử chúng ta có 4 server A, B, C, D có cấu hình khác nhau, A và B có cấu
hình giống nhau, C và D có cấu hình mạnh gấp đôi A. Vậy chúng ta có thể đánh
trọng số cho A và B là 1, C và D là 2. Khi đó theo thuật toán WRR, thứ tự server
nhận yêu cầu từ phía bộ cân bằng tải sẽ là ABCDCD.
Thuật toán này có thể được thực thi như sau: Giả sử chúng ta một hàng đợi để
chứa các server sẽ nhận request. Nếu như 1 server trọng số n, trong hàng đợi sẽ có
n chỉ mục (entry) của cùng 1 server này, chẳng hạn như ở ví dụ trên, mỗi server A,
B sẽ có 1 chỉ mục, mỗi server C, D sẽ có 2 chỉ mục. Với cách lưu chỉ mục như vậy
trong hàng đợi, các server trong WRR sẽ được lấy ra theo thứ tự hoàn toàn giống
như RR.


Thuật toán WRR hoạt động tốt hơn RR khi các server trong cluster có cấu
hình khác nhau. Tuy nhiên sử dụng thuật toán này có thểdẫn tới sự mất cân bằng tải
động nếu như tải của các yêu liên tục thay đổi trong một khoảng rộng (ví dụ như
các yêu cầu xem video hoặc tải các file có dung lượng lớn xen kẽ với các yêu cầu
đọc thông tin...). Trong một khoảng thời gian ngắn, hoàn toàn có khả năng phần lớn
các yêu cầu có tải cao sẽ được chuyển hướng đến cùng một server.
3.4. Thuật toán Dynamic Round Robin (DRR)

Thuật toán DRR hoạt động gần giống với WRR, điểm khác biệt là trọng số ở
đây dựa trên sự kiểm tra server một cách liên tục, do đó trọng số liên tục thay đổi.

Đây là một thuật toán động (khác với các thuật toán đã trình bàyở trên đều là thuật
toán tĩnh), việc chọn server sẽ dựa trên rất nhiều khía cạnh trong việc phân tích
hiệu năng của server dựa trên thời gian thực, chẳng hạn như số kết nối hiện tại đang
có trên các server hoặc server trả lời nhanh nhất. Thuật toán này thường không thấy
trong các bộ cân bằng tải đơn giản, nó được sử dụng trong các sản phẩm cân bằng
tải của F5 Network.
Nhóm chưa tìm hiểu được cách thức để thực thi thuật toán này, tuy vậy
không thể sử dụng WRR và xây dựng lại hàng đợi dựa trên trọng số thay đổi của
các server, có thể dùng một con trỏ cấu trúc để lưu lại các server, mỗi lần tạo một
kết nối mới cho server nào đó, chúng ta sẽ tính toán lại vị trí của nó trong struct.
3.5. Thuật toán Fastest

Thuật toán fastest chọn server dựa trên thời gian đáp ứng của mỗi server
(response time), thuật toán sẽ chọn server nào có thời gian đáp ứng nhanh nhất.
Thời gian đáp ứng được xác định bởi khoảng thời gian giữa thời điểm gửi một gói
tin đến server và thời điểm nhận gói tin trả lời. Việc gửi nhận này sẽ được bộ cân
bằng tải đảm nhiệm, dựa trên thời gian đáp ứng, bộ cân bằng tải sẽ biết chuyển yêu
cầu tiếp theo đến server nào.


Thuật toán fastest thường được dùng khi mà các server được cài đặt dọc theo
các mạng logic khác nhau, nghĩa là server được đặt ở nhiều nơi khác nhau. Như
vậy người dùng ở gần server nào, thì thời gian đáp ứng đến server đó chắc chắn sẽ
nhanh nhất, và server đó sẽ được chọn để phục vụ. Thuật toán này cũng giống như
chuyển hướng yêu cầu dựa trên địa chỉ IP. Chẳng hạn như khi người dùng truy cập
vào site youtube.com, nếu IP của người dùng đến từ Việt Nam, yêu cầu sẽ được
chuyển vào server ở Việt Nam xử lý, điều này sẽ giúp cho tiết kiệm băng thông
quốc tế và cải thiện tốc độ đường truyền.

3.6. Thuật toán Least Connections (LC)

Trong thuật toán LC, yêu cầu từ phía người dùng sẽ được chuyển vào server
có ít kết nối nhất trong hệ thống tại thời điểm đó. Thuật toán này được coi như
thuật toán động, vì nó cần phải đếm số kết nối "đang hoạt động" của các server.
Với một hệ thống có các server gần giống nhau về cấu hình, LC có khả năng hoạt
động tốt ngay cả khi tải của các kết nối biến thiên trong một khoảng lớn. Do đó sử
dụng LC sẽ khắc phục được nhược điểm của RR.
Giả sử chúng ta có n server Si, i = 1, 2,...n. Số lượng connections đang hoạt
động là Ci với i = (1, 2,...,n). ALL_CONNECTIONS là tổng Ci.
Yêu cầu tiếp theo sẽ được chuyển đến server j, trong đó:
Cj/ALL_CONNECTIONS = min {Ci/ALL_CONNECTIONS },
i = (1, 2,...,n).
Vì giá trị ALL_CONNECTIONS là không đổi tại thời điểm tính nên chúng
ta có thể chọn server Cj theo công thức:
Cj = min {Ci}, i = (1, 2,...,n).
Nhìn bên ngoài có vẻ như LC cũng có khả năng hoạt động tốt khi các server
có cấu hình biến thiên khác nhau, trên thực tế điều đó là không đúng. Vậy thì
nguyên nhân ở đâu? Đó chính là do trạng thái TIME_WAIT của TCP.
TIME_WAIT này thường được đặt là 2 phút, trong 2 phút đó một website "bận
rộn" có thể nhận tới hàng chục ngàn kết nối liên tục, giả sử như server A có khả
năng xử lý gấp đôi server B, server A đang xử lý hàng ngàn yêu cầu và giữ những


yêu cầu này trong trạng thái TIME_WAIT của TCP, trong khi đó server cũng phải
xử lý hàng ngàn yêu cầu như server A, nhưng vì cấu hình server B yếu hơn nên sẽ
chậm chạp hơn rất nhiều. Như vậy, thuật toán LC hoạt động không tốt khi các
server có cấu hình khác nhau.
3.7. Thuật toán Observed

Observed là sự kết hợp giữa Least Connections và Fastest Response, nó chỉ

tồn tại trong các giải pháp của F5-Network. Ở đây người phát triển hệ thống sẽ phải
cân bằng giữa 2 yếu tố: số kết nối đến một server và thời gian đáp ứng giữa chúng.
Nghĩa là, cũng giống như đánh trọng số cho các server, 2 yếu tố này sẽ có những
trọng số nhất định giữa trên nhận định của người phát triển hệ thống hoặc nhà quản
trị. Một phép toán số học dựa trên số kết nối của một server, thời gian đáp ứng và
các trọng số sẽ đưa ra cho mỗi server một giá trị. Dựa trên giá trịđó, bộ cân bằng tải
sẽ chọn được server phù hợp.
Nếu như được thiết kế tốt, Observed sẽ khắc phục được nhược điểm của cả
Least Connections và Fastest Response. Thuật toán Least Connections không chú
trọng vào “không gian” nghĩa là một người dùng truy cập ở Hà Nội có thể được kết
nối vào serverở T.P Hồ Chí Minh, vì số kết nối ở đó đang ít nhất. Như vậy là không
cần thiết, vì nếu chuyển kết nối người dùng này vào server Hà Nội thì thời gian
phục vụ sẽ giảm xuống và sẽ tiết kiệm được rất nhiều băng thông. Trong khi đó
Fastest Response sẽ đưa người dùng vào server có thời gian đáp ứng tốt nhất bất kể
số kết nối tại đó nhiều hay ít, nếu như máy chủ đó sắp quá tải, có thể sẽ dẫn đến bị
treo nếu như quá nhiều người ở địa điểm đó truy cập vào. Sự cân bằng giữa số kết
nối và thời gian đáp ứng sẽ giúp cho bộ cân bằng tải chọn được server phù hợp
nhất.
Observed được đưa ra bởi F5-Network, và hầu như không tồn tại trong các
phần mềm cân bằng tải mã nguồn mở hay các phần mềm nhỏ.


3.8. Thuật toán Predictive

Là sự phát triển tiếp theo của Observed, nhưng trong thuật toán Predictive,
hệ thống sẽ phân tích trạng thái của các server theo thời gian, xác định xem thời
điểm nào thì hiệu năng của server đang tăng lên, thời điểm nào đang giảm xuống.
Như vậy, giả sử như 2 server theo đánh giá của thuật toán Observed là tương đương
nhau, server nào có hiệu năng biến đổi theo chiều hướng tốt hơn sẽ được chọn.
3.9. Thuật toán Weights Least Connection

Bản chất giống thuật toán Least Connection, nhưng chúng ta có thể cấu hình ưu
tiên cho một máy chủ trong cụm máy chủ hoạt động.

3.10. Thuật toán Least Response Time.
Đây là thuật toán sử dụng phương pháp thời gian đáp ứng ít nhất, lựa chọn dịch vụ
trên máy chủ với thời gian đáp ứng là thấp nhất.
Ngoài ra còn có rất nhiều thuật toán cân bằng tải khác tùy theo phần mềm hoặc phần cứng
cân bằng tải được sử dụng.

3.11. Hàm băm
Hàm băm làm giải thuật nhằm sinh ra các giá trị băm tương ứng với mỗi database
server. Giá trị băm đóng vai trò gần như một khóa để phân biệt các database server. Cũng
giống với giải thuật Round Robin, hàm băm chỉ định server trả lời truy vẫn cho client mà
không quan tâm đến trạng thái hiện tại của server đó (có ít hay nhiều truy vấn).

3.12. Giải thuật xác định tổng số kết nối nhỏ nhất.
Giải thuật này xác định tổng số kết nối hiện tại trên các database server, nếu server
nào có tổng kết nối nhỏ nhất thì server đó sẽ được chỉ định là trả lời truy vấn tiếp theo của
client. Trong giải thuật này có quan tâm đến trạng thái của server. Đây là một giải thuật